From vgaburici at gmail.com Mon Sep 1 00:26:57 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Mon, 1 Sep 2008 03:26:57 +0300 Subject: Very nice of you to write the tl2rpm converter In-Reply-To: References: Message-ID: Actually, the main problem I see with that single spec is update handling. When a single source of those many thousands changes, you'd have to rebuild all the binary rpms, and they'll all get a new release number. Unless there's some hack to avoid this, the Fedora user would have to update all the texlive rpms every time, thus negating any benefit of having TL split in those packages. Also, I think you need a way patch that spec after it's generated or perhaps as it is generated. Some reasons to do this: * packaging the TeX OpenType fonts only for TeX is a no-no these days * some TL packages have incorrect/missing license. For instance glyphlist, which contains Adobe's glyphlist.txt, (which is taken from lcdf-typetools in TL2008) and IMHO needs "Redistributable, no modification permitted". BTW, in TL2008 that file is required by lcdf-typetools and dvipdfmx, but in Fedora's TL 2007, dvipdfmx includes Adobe's file in its own rpm, so the rpm probably has an incomplete license field because of it; should add "... and Redistributable, no ..." like poppler has. * some packages should probably not be built from TeXLive, so you probably need blacklist. Examples: - The Gyre fonts (currenly) have a licensing issue. - Some packages like lcdf-typetools (in which all programs except one don't actually need TeX at all) are probably better built outside of TeXLive (with subpackages in this case). - You probably want to disable tlmgr. Unless you can patch it to install rpms instead, of course, but that seem difficult to hack... * the TL2008 texmf.cnf file uses $SELFAUTOPARENT. This can cause trouble with binaries sitting outside its tree. If the user installs any binaries of its own (say in /usr/local/bin), they won't work with the default cnf. See: http://tug.org/pipermail/tex-live/2008-August/017338.html As matter of approach, packaging TL binaries surely is convenient, but there are some potential problems: * odd shared libraries used. For instance TL2008's lcdf-typetools did not work on Fedora 9 out of the box because of missing libstdc++.so.5 (granted it's in a compat package, so when the RPM is built the right dependency would probably get added), but that dependency is gratuitous in this case. * TL builds a lot of stuff statically liked. A prime example is XeTeX. This one is tricky because it uses modified versions of some libraries (ICU), some libraries which don't have any modifications but are also included in XeTeX tree. Hope this helps, Vasile On Mon, Sep 1, 2008 at 2:16 AM, Vasile Gaburici wrote: > It would have been even nicer had you cc'd fedora-devel-list... > > For those that don't read the tex-live at tug list, or the ambassadors' > list, here's the tl2rpm (prototype) announcement: > http://tug.org/pipermail/tex-live/2008-August/017190.html > > My main concern is that %post actions will turn out quite hairy, see > below (you were probably on vacation then): > > ---------- Forwarded message ---------- > From: Vasile Gaburici > Date: Sun, Aug 10, 2008 at 8:19 AM > Subject: Re: TeXLive 2008 in F10? > To: Jonathan Underwood , Patrice Dumas > , Development discussions related to Fedora > > > > Initially I thought we could do without their installer, because I > found only 4 types of "execute", i.e. post install script actions in > the master texlive.tlpdb on CTAN. Then I had a look at their new > packager's sources: > http://www.tug.org/svn/texlive/trunk/Master/tlpkg/TeXLive/. Besides > the 4 generic "execute" types, there are plenty of hardcoded > package-specific things in TLPostActions.pm. > > So, I don't see an easy way of dealing with this. Duplicating all that > stuff in rpm post scriptlets would be highly unmaintanable. The only > sane way would be to install their packager library first, and to > execute post actions from there as needed, which needs at least a > wrapper script since that code is Perl. It's more than I have time for > this weekend... > From jantill at redhat.com Mon Sep 1 05:30:58 2008 From: jantill at redhat.com (James Antill) Date: Mon, 01 Sep 2008 01:30:58 -0400 Subject: using yum/repoquery to provide dependency trees In-Reply-To: <5256d0b0808311646k498879f7x6f910a6f6da93ffa@mail.gmail.com> References: <5256d0b0808311646k498879f7x6f910a6f6da93ffa@mail.gmail.com> Message-ID: <1220247058.3862.194.camel@code.and.org> On Mon, 2008-09-01 at 00:46 +0100, Peter Robinson wrote: > Anyway I'm wondering if there's a way to some dep tree style bits with > packages that are installed to see what causes the dependencies of > what is actually installed. EG if I do a 'yum remove perl' it > basically wants to uninstall gnome and a lot more but it would be nice > to be able to see exactly what installed packages depend on perl or > perl-Pop-Simple for example. There are a couple of things I think you might find useful (off the top of my head): repoquery --alldeps --whatrequires package-cleanup --leaves pkg-deps-tree-view.py --limit-installed (or *, for everything) ...the later? is probably closest to what you want, I think, as it will spit out deps. into a tree like format and then you can browse it. ? http://fedorapeople.org/~james/yum/commands/pkg-deps-tree-view.py -- James Antill Red Hat From j.w.r.degoede at hhs.nl Mon Sep 1 07:28:16 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 01 Sep 2008 09:28:16 +0200 Subject: Problems with kernel-2.6.26 and 2.6.27-0.x.rc2 In-Reply-To: <1220218562.15187.33.camel@optimus> References: <5f6f8c5f0808281513l53c7a302u31f1b53e6955cb29@mail.gmail.com> <5f6f8c5f0808292331v1eee5802o9fb0f5a37dca20@mail.gmail.com> <1220218562.15187.33.camel@optimus> Message-ID: <48BB9990.7040601@hhs.nl> Dave Airlie wrote: > > So you have two problems.. one is a kernel module is loading and hanging > the boot process, this is usually blamed on udev, the fact that hitting > a key helps implies some interrupt handling problem maybe.. > > The other is the graphical boot not working properly on your card, for > that you can boot with nomodeset on the command line, if udev hangs that > is the other problem. For the graphical boot, I'd need to know the > graphics card and type of card, agp pci etc. and type of display plugged > in. > Hi Dave, I'm seeing problems with graphical boot too, I haven't been reporting them sofar as things are still somewhat in flux with regards to kernel mode setting. But since you asked: 00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2) 03:00.0 VGA compatible controller: ATI Technologies Inc RV570 [Radeon X1950 Pro] (rev 9a) 03:00.1 Display controller: ATI Technologies Inc RV570 [Radeon X1950 Pro] (secondary) (rev 9a) dual core x86_64 system running: kernel-2.6.27-0.290.rc5.fc10.x86_64 Using an analog vga attached 1280x1024 lcd screen Graphical boot worked a couple of times but the last 2 boots it hanged with a black screen when the mode got set (I'm now running aan older kernel). When graphical boot did work, X was slow as molasses, Xorg.log provided no clues (I could find), but this may be because I was only running the latest kernel and my xorg and libdrm are about 2 weeks old. Let me know if you want this in bugzilla and what more I can do to test. I must say that plymouth looked good when it worked. Regards, Hans From bsingharora at gmail.com Mon Sep 1 07:29:28 2008 From: bsingharora at gmail.com (Balbir Singh) Date: Mon, 1 Sep 2008 12:59:28 +0530 Subject: CONFIG_CGROUP_MEM_RES_CTLR Message-ID: <661de9470809010029h1ef32ae7h35b6a2dfe2d13c3@mail.gmail.com> While trying to build the memory resource controller with the latest kernel source, I saw the following in config-generic #NOTE: Before changing the size below, take notice that page struct will grow past a cacheline on 32 bit. I am running F10-alpha 32 bit version, on which I see Linux localhost.localdomain 2.6.27-0.166.rc0.git8.fc10.i686 #1 SMP Mon Jul 21 20:51:26 EDT 2008 i686 i686 i386 GNU/Linux sizeof(vma)=84 bytes sizeof(page)=56 bytes sizeof(inode)=608 bytes sizeof(dentry)=160 bytes sizeof(ext3inode)=860 bytes sizeof(buffer_head)=56 bytes sizeof(skbuff)=184 bytes sizeof(task_struct)=6056 bytes With size at 56 bytes, I don't think adding 4 bytes will affect the growth beyond cacheline size. I suspect that there are a few debugging options turned on, that are causing either spinlock_t to bloat or something that CONFIG_PAGE_OWNER is turned on. Are these debugging options going to go away as we head towards F10 release? Balbir From ivazqueznet at gmail.com Mon Sep 1 09:06:38 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 01 Sep 2008 05:06:38 -0400 Subject: wirteable config files path In-Reply-To: <48BA8734.2030809@x-tnd.be> References: <48BA8734.2030809@x-tnd.be> Message-ID: <1220259998.17290.82.camel@ignacio.lan> On Sun, 2008-08-31 at 13:57 +0200, Johan Cwiklinski wrote: > BackupPC provides a web interface that needs write access to its config > files (actually located under /etc/BackupPC). Are they then actually config files, or are they state files? -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From billcrawford1970 at gmail.com Mon Sep 1 09:40:33 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Mon, 1 Sep 2008 10:40:33 +0100 Subject: Time to resurrect multi-key signatures in RPM? In-Reply-To: References: <1219715812.7925.59.camel@shrek.rexursive.com> <20080826030941.GC1572107@hiwaay.net> <1219725335.12096.53.camel@rosebud> <1219750681.12096.56.camel@rosebud> Message-ID: <544eb990809010240p1546c34k4a6d8d813745f112@mail.gmail.com> On 30/08/2008, Bojan Smojver wrote: > Just for completeness, yum could alternatively accept say 5 keys from the > pool > (but no Fedora key), so that any compromise of the central key does not > cause > the current "change the Fedora key" hoopla. Simply resign by others and > continue. What might be good, is only signing packages with one or two keys, but only allowing those keys' public parts to be updated in rpm database (or wherever) if signed by a much larger number of keys, which would be owned by some trusted people from the fedora project. Then automated rollover could be done by simply providing a new "keyring" in updates. From casimiro.barreto at gmail.com Mon Sep 1 09:48:19 2008 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Mon, 01 Sep 2008 06:48:19 -0300 Subject: Time to resurrect multi-key signatures in RPM? In-Reply-To: <544eb990809010240p1546c34k4a6d8d813745f112@mail.gmail.com> References: <1219715812.7925.59.camel@shrek.rexursive.com> <20080826030941.GC1572107@hiwaay.net> <1219725335.12096.53.camel@rosebud> <1219750681.12096.56.camel@rosebud> <544eb990809010240p1546c34k4a6d8d813745f112@mail.gmail.com> Message-ID: <48BBBA63.8060400@gmail.com> Bill Crawford escreveu: > On 30/08/2008, Bojan Smojver wrote: > > >> Just for completeness, yum could alternatively accept say 5 keys from the >> pool >> (but no Fedora key), so that any compromise of the central key does not >> cause >> the current "change the Fedora key" hoopla. Simply resign by others and >> continue. >> > > What might be good, is only signing packages with one or two keys, but > only allowing those keys' public parts to be updated in rpm database > (or wherever) if signed by a much larger number of keys, which would > be owned by some trusted people from the fedora project. Then > automated rollover could be done by simply providing a new "keyring" > in updates. > > BTW, updates are still frozen. What's the schedule for the normalization of yum services? Will it be necessary a special procedure to be adopted by users? Best regards, CdAB -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From dholwerda at gmail.com Mon Sep 1 09:49:05 2008 From: dholwerda at gmail.com (Dan Holwerda) Date: Mon, 1 Sep 2008 17:49:05 +0800 Subject: NetworkManager-pptp In-Reply-To: <16de708d0808301502w5b435684r7b4cf268af1616f7@mail.gmail.com> References: <9497e9990808300831t150c6036ydf4c453f3c822d48@mail.gmail.com> <16de708d0808301502w5b435684r7b4cf268af1616f7@mail.gmail.com> Message-ID: <921dc0110809010249x501a1993r6ba4efc62c5a942@mail.gmail.com> mine works fine on x86 - although selinux will stop it when in enforcing mode On Sun, Aug 31, 2008 at 6:02 AM, Arthur Pemberton wrote: > On Sat, Aug 30, 2008 at 10:31 AM, Mat Booth wrote: >> I was pleased to see this package hanging out in Koji today. Thanks >> Dan for packaging it, I've been looking forward to seeing this in >> Fedora. >> >> I've installed the x86_64 package from Koji to try it out on my F9 >> machine. Am I being too eager? :-) >> >> Anyway, I've configured up my VPN connection but I can't get it to >> work. Whatever I try, I always get the following: >> >> Aug 30 16:05:40 sd NetworkManager: Starting VPN service >> 'org.freedesktop.NetworkManager.pptp'... >> Aug 30 16:05:40 sd NetworkManager: VPN service >> 'org.freedesktop.NetworkManager.pptp' started >> (org.freedesktop.NetworkManager.pptp), PID 6587 >> Aug 30 16:05:40 sd NetworkManager: vpn_service_watch_cb(): VPN >> service 'org.freedesktop.NetworkManager.pptp' exited with error: 1 >> Aug 30 16:05:45 sd NetworkManager: VPN service >> 'org.freedesktop.NetworkManager.pptp' did not start in time, >> cancelling connections >> >> Currently, I connect to the VPN with this script (login details >> censored, obviously): >> >> http://www.matbooth.co.uk/lwd/start-vpn >> >> Which works reasonably well. How can I make NetworkManager-pptp >> connect using the settings I use in that script? What's the best way >> to go about debugging this? >> >> Regards, >> Mat >> > > > Many thanks. I will sure to try this on my dev box this weekend. > > Thanks Dan. > > > -- > Fedora 7 : sipping some of that moonshine > ( www.pembo13.com ) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From nicolas.mailhot at laposte.net Mon Sep 1 10:47:01 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 01 Sep 2008 12:47:01 +0200 Subject: system autodeath In-Reply-To: <1219333387.3407.3.camel@localhost.localdomain> References: <1219258637.8530.43.camel@rosebud> <48AC6CCE.6020009@fedoraproject.org> <200808211439.m7LEdGFM011821@laptop14.inf.utfsm.cl> <20080821152108.GC28415@angus.ind.WPI.EDU> <1219333387.3407.3.camel@localhost.localdomain> Message-ID: <1220266021.2047.10.camel@rousalka.okg> Le jeudi 21 ao?t 2008 ? 11:43 -0400, Tom "spot" Callaway a ?crit : > On Thu, 2008-08-21 at 18:38 +0300, Vasile Gaburici wrote: > > You're probably unaware (because you haven't read my emails to this > > list) that with the 2008 edition TeXLive changed their packaging > > system significantly. They now allow incremental upgades of their > > packages. > > You may be unaware of how long it takes to legally audit TeXLive before > we can let it into Fedora. Last time, the number of things which were > not kosher were in the double digits. > > With all the other fires that I've had to put out lately, I haven't had > time to even start on TeXLive 2008, which is the primary roadblock to > inclusion in F10. This is one more reason to modularise this beast in separate packages, so the legal problems can be isolated and not block the rest from updating -- 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 pbrobinson at gmail.com Mon Sep 1 10:47:38 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 1 Sep 2008 11:47:38 +0100 Subject: using yum/repoquery to provide dependency trees In-Reply-To: <1220247058.3862.194.camel@code.and.org> References: <5256d0b0808311646k498879f7x6f910a6f6da93ffa@mail.gmail.com> <1220247058.3862.194.camel@code.and.org> Message-ID: <5256d0b0809010347l3e280b51i3cf92ac43a81b323@mail.gmail.com> On Mon, Sep 1, 2008 at 6:30 AM, James Antill wrote: > On Mon, 2008-09-01 at 00:46 +0100, Peter Robinson wrote: > >> Anyway I'm wondering if there's a way to some dep tree style bits with >> packages that are installed to see what causes the dependencies of >> what is actually installed. EG if I do a 'yum remove perl' it >> basically wants to uninstall gnome and a lot more but it would be nice >> to be able to see exactly what installed packages depend on perl or >> perl-Pop-Simple for example. > > There are a couple of things I think you might find useful (off the top > of my head): > > repoquery --alldeps --whatrequires > package-cleanup --leaves > pkg-deps-tree-view.py --limit-installed (or *, for everything) > > ...the later? is probably closest to what you want, I think, as it will > spit out deps. into a tree like format and then you can browse it. Thanks James that looks like its exactly what I want. Cheers, Peter > ? http://fedorapeople.org/~james/yum/commands/pkg-deps-tree-view.py > From mlichvar at redhat.com Mon Sep 1 11:20:53 2008 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Mon, 1 Sep 2008 13:20:53 +0200 Subject: using yum/repoquery to provide dependency trees In-Reply-To: <5256d0b0808311646k498879f7x6f910a6f6da93ffa@mail.gmail.com> References: <5256d0b0808311646k498879f7x6f910a6f6da93ffa@mail.gmail.com> Message-ID: <20080901112053.GA16086@localhost> On Mon, Sep 01, 2008 at 12:46:15AM +0100, Peter Robinson wrote: > Anyway I'm wondering if there's a way to some dep tree style bits with > packages that are installed to see what causes the dependencies of > what is actually installed. EG if I do a 'yum remove perl' it > basically wants to uninstall gnome and a lot more but it would be nice > to be able to see exactly what installed packages depend on perl or > perl-Pop-Simple for example. You may also want to try rpmreaper. It's an interactive tool designed for browsing dependencies and removing packages. -- Miroslav Lichvar From jos at xos.nl Mon Sep 1 12:55:51 2008 From: jos at xos.nl (Jos Vos) Date: Mon, 01 Sep 2008 14:55:51 +0200 Subject: nspluginwrapper and nppdf.so (Adobe Acrobat) Message-ID: <200809011255.m81CtqSi031735@jasmine.xos.nl> Hi, It seems that nspluginwrapper is standard installed in F9, also on 32-bit systems. But it looks it does not work well with nppdf.so (Adobe Acrobat 8.1.2), at least not on 32-bit systems. Is this a known issue? When I add "nppdf*" to IGNORE_WRAP in /etc/sysconfig/nspluginwrapper (and run "mozilla-plugin-confg -r" so that the symlinks will be recreated at the next firefox start), everything seems to work ok. But when I use the wrapper with nppdf.so, firefox starts behaving problematic most times when opening a PDF link (it often more or less freezes for that tab). Thanks, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From txtoth at gmail.com Mon Sep 1 14:25:48 2008 From: txtoth at gmail.com (Xavier Toth) Date: Mon, 1 Sep 2008 09:25:48 -0500 Subject: [PATCH] yum: make transaction results available to plugins Message-ID: Put the result of the transaction in the TranactionData object so that it is available to plugins. --- yum-3.2.19/yum/transactioninfo.py 2008-08-12 08:54:00.000000000 -0500 +++ yum-3.2.19.new/yum/transactioninfo.py 2008-08-31 10:00:22.000000000 -0500 @@ -63,7 +63,8 @@ self.depremoved = [] self.depinstalled = [] self.depupdated = [] - + self.transaction_result = None + def __len__(self): return len(self.pkgdict) @@ -459,6 +460,12 @@ result.update(self.getNewRequires(name, flag, version)) return result + def getTransactionResult(self): + return self.transaction_result + + def setTransactionResult(self, result): + self.transaction_result = result + class ConditionalTransactionData(TransactionData): """A transaction data implementing conditional package addition""" def __init__(self): --- yum-3.2.19/yum/__init__.py 2008-08-26 14:37:17.000000000 -0500 +++ yum-3.2.19.new/yum/__init__.py 2008-08-31 09:59:40.000000000 -0500 @@ -799,6 +799,8 @@ else: raise Errors.YumBaseError, errors + self.tsInfo.setTransactionResult(resultobject) + if not self.conf.keepcache: self.cleanUsedHeadersPackages() From clydekunkel7734 at cox.net Mon Sep 1 14:50:29 2008 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Mon, 01 Sep 2008 10:50:29 -0400 Subject: Problems with kernel-2.6.26 and 2.6.27-0.x.rc2 In-Reply-To: <48BB9990.7040601@hhs.nl> References: <5f6f8c5f0808281513l53c7a302u31f1b53e6955cb29@mail.gmail.com> <5f6f8c5f0808292331v1eee5802o9fb0f5a37dca20@mail.gmail.com> <1220218562.15187.33.camel@optimus> <48BB9990.7040601@hhs.nl> Message-ID: <48BC0135.2030506@cox.net> Hans de Goede wrote: > > > > Graphical boot worked a couple of times but the last 2 boots it hanged > with a black screen when the mode got set (I'm now running aan older > kernel). > > When graphical boot did work, X was slow as molasses, Xorg.log provided > no clues (I could find), but this may be because I was only running the > latest kernel and my xorg and libdrm are about 2 weeks old. > > Let me know if you want this in bugzilla and what more I can do to test. > I must say that plymouth looked good when it worked. > > Regards, > > Hans > I reverted gdm to remedy this problem. -- --------------------------------- Regards, Old Fart From skvidal at fedoraproject.org Mon Sep 1 15:00:12 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 01 Sep 2008 11:00:12 -0400 Subject: [PATCH] yum: make transaction results available to plugins In-Reply-To: References: Message-ID: <1220281212.8829.0.camel@rosebud> On Mon, 2008-09-01 at 09:25 -0500, Xavier Toth wrote: > Put the result of the transaction in the TranactionData object so that > it is available to plugins. > What is this for? What's the use case? -sv > --- yum-3.2.19/yum/transactioninfo.py 2008-08-12 08:54:00.000000000 -0500 > +++ yum-3.2.19.new/yum/transactioninfo.py 2008-08-31 10:00:22.000000000 -0500 > @@ -63,7 +63,8 @@ > self.depremoved = [] > self.depinstalled = [] > self.depupdated = [] > - > + self.transaction_result = None > + > def __len__(self): > return len(self.pkgdict) > > @@ -459,6 +460,12 @@ > result.update(self.getNewRequires(name, flag, version)) > return result > > + def getTransactionResult(self): > + return self.transaction_result > + > + def setTransactionResult(self, result): > + self.transaction_result = result > + > class ConditionalTransactionData(TransactionData): > """A transaction data implementing conditional package addition""" > def __init__(self): > --- yum-3.2.19/yum/__init__.py 2008-08-26 14:37:17.000000000 -0500 > +++ yum-3.2.19.new/yum/__init__.py 2008-08-31 09:59:40.000000000 -0500 > @@ -799,6 +799,8 @@ > else: > raise Errors.YumBaseError, errors > > + self.tsInfo.setTransactionResult(resultobject) > + > if not self.conf.keepcache: > self.cleanUsedHeadersPackages() From txtoth at gmail.com Mon Sep 1 16:02:55 2008 From: txtoth at gmail.com (Xavier Toth) Date: Mon, 1 Sep 2008 11:02:55 -0500 Subject: [PATCH] yum: make transaction results available to plugins In-Reply-To: <1220281212.8829.0.camel@rosebud> References: <1220281212.8829.0.camel@rosebud> Message-ID: I have a number of rpms that install SELinux policy modules during the post install and I want yum to exit if there is any problem. I've written a plugin with a posttrans method that examines the result and exits if there was any problem. If there is another way to do this I'd be happy to hear about it. On Mon, Sep 1, 2008 at 10:00 AM, Seth Vidal wrote: > On Mon, 2008-09-01 at 09:25 -0500, Xavier Toth wrote: >> Put the result of the transaction in the TranactionData object so that >> it is available to plugins. >> > > > What is this for? What's the use case? > > -sv > > >> --- yum-3.2.19/yum/transactioninfo.py 2008-08-12 08:54:00.000000000 -0500 >> +++ yum-3.2.19.new/yum/transactioninfo.py 2008-08-31 10:00:22.000000000 -0500 >> @@ -63,7 +63,8 @@ >> self.depremoved = [] >> self.depinstalled = [] >> self.depupdated = [] >> - >> + self.transaction_result = None >> + >> def __len__(self): >> return len(self.pkgdict) >> >> @@ -459,6 +460,12 @@ >> result.update(self.getNewRequires(name, flag, version)) >> return result >> >> + def getTransactionResult(self): >> + return self.transaction_result >> + >> + def setTransactionResult(self, result): >> + self.transaction_result = result >> + >> class ConditionalTransactionData(TransactionData): >> """A transaction data implementing conditional package addition""" >> def __init__(self): >> --- yum-3.2.19/yum/__init__.py 2008-08-26 14:37:17.000000000 -0500 >> +++ yum-3.2.19.new/yum/__init__.py 2008-08-31 09:59:40.000000000 -0500 >> @@ -799,6 +799,8 @@ >> else: >> raise Errors.YumBaseError, errors >> >> + self.tsInfo.setTransactionResult(resultobject) >> + >> if not self.conf.keepcache: >> self.cleanUsedHeadersPackages() > > > -- > 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 Mon Sep 1 16:03:07 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 01 Sep 2008 11:03:07 -0500 Subject: rawhide report: 20080829 changes In-Reply-To: References: <20080829195754.07B211F8248@releng2.fedora.phx.redhat.com> <1220044676.9554.26.camel@luminos.localdomain> <20080831191730.GA7646@dhcp-lab-186.brq.redhat.com> <1220214626.29094.13.camel@luminos.localdomain> Message-ID: >>>>> "KK" == Kevin Kofler writes: KK> If it's so easy, then why has it been vetoed for some of our KDE KK> packages (like kdepimlibs for kdepimlibs-apidocs, kdeartwork for KK> the icon themes and other noarch data, ...)? What I find odd is that kdelibs does have a noarch subpackage. Now, kdelibs-apidocs is enormous (240MB compressed RPM) so I can understand the exception, but if there are rules about how much space needs to be saved or how large the noarch subpackage has to be then it would be nice to have them written down somewhere. It's not as if the extra-arches hack is difficult to set up, so I'd imagine that the threshold would be pretty low, but it's quite possible that there's some overhead or disadvantage I'm not aware of. - J< From mailings at x-tnd.be Mon Sep 1 16:12:09 2008 From: mailings at x-tnd.be (Johan Cwiklinski) Date: Mon, 01 Sep 2008 18:12:09 +0200 Subject: wirteable config files path In-Reply-To: <1220259998.17290.82.camel@ignacio.lan> References: <48BA8734.2030809@x-tnd.be> <1220259998.17290.82.camel@ignacio.lan> Message-ID: <48BC1459.9090309@x-tnd.be> Ignacio Vazquez-Abrams a ?crit : > On Sun, 2008-08-31 at 13:57 +0200, Johan Cwiklinski wrote: > >> BackupPC provides a web interface that needs write access to its config >> files (actually located under /etc/BackupPC). >> > > Are they then actually config files, or are they state files? > > I'll say the're config files ; but I'm not sur to understand what you mean by state files... There are several files : - hosts : lists hosts/ips/users to backup - config.pl : main BackupPC configuration file (what to backup, when to do it, which method should be used, etc...) - pc/*.pl : config files per hosts. These one p?rmit to ovverride some of confi.pl directives (what, when, method and do on). Hope this will be a little more clear. Regards, Johan From vgaburici at gmail.com Mon Sep 1 16:18:21 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Mon, 1 Sep 2008 19:18:21 +0300 Subject: rawhide report: 20080829 changes In-Reply-To: References: <20080829195754.07B211F8248@releng2.fedora.phx.redhat.com> <1220044676.9554.26.camel@luminos.localdomain> <20080831191730.GA7646@dhcp-lab-186.brq.redhat.com> <1220214626.29094.13.camel@luminos.localdomain> Message-ID: TeXLive 2007 documenation is in the same ballpark as KDE's. For TL2008, there's even more of it, but split in ~1500 sub-packages... On Mon, Sep 1, 2008 at 7:03 PM, Jason L Tibbitts III wrote: >>>>>> "KK" == Kevin Kofler writes: > > KK> If it's so easy, then why has it been vetoed for some of our KDE > KK> packages (like kdepimlibs for kdepimlibs-apidocs, kdeartwork for > KK> the icon themes and other noarch data, ...)? > > What I find odd is that kdelibs does have a noarch subpackage. Now, > kdelibs-apidocs is enormous (240MB compressed RPM) so I can understand > the exception, but if there are rules about how much space needs to be > saved or how large the noarch subpackage has to be then it would be > nice to have them written down somewhere. > > It's not as if the extra-arches hack is difficult to set up, so I'd > imagine that the threshold would be pretty low, but it's quite > possible that there's some overhead or disadvantage I'm not aware of. > > - J< > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From rjones at redhat.com Mon Sep 1 16:24:11 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 1 Sep 2008 17:24:11 +0100 Subject: Couple of review requests - haxe and nekovm - swapsies anyone? Message-ID: <20080901162411.GA29395@amd.home.annexia.org> https://bugzilla.redhat.com/show_bug.cgi?id=460779 nekovm - Neko embedded scripting language and virtual machine which is required by: https://bugzilla.redhat.com/show_bug.cgi?id=460780 haxe - Web programming language targeting Flash, Javascript, PHP haXe is quite a cool little web language which you can use as an alternative to ActionScript to compile Flash widgets. The neat part is that the same source code can be used to generate Javascript (drawing on a Firefox 3 ). Here's an example of a haXe-authored Flash widget (requires the Adobe Flash plugin [1]): http://www.annexia.org/tmp/phx.swf (Press keys 1 - 9 and try clicking the mouse to fire blocks) This is the Javascript equivalent built from the same source (requires Firefox 3 or another browser that supports the WHATWG canvas widget): http://www.annexia.org/tmp/phx.html As usual I can swap these reviews for any others that people might have. [1] haXe can also target Flash 8 and we checked that simple examples work with Gnash, but not this rather complicated demo. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From pertusus at free.fr Mon Sep 1 16:32:52 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 1 Sep 2008 18:32:52 +0200 Subject: rawhide report: 20080829 changes In-Reply-To: References: <20080829195754.07B211F8248@releng2.fedora.phx.redhat.com> <1220044676.9554.26.camel@luminos.localdomain> <20080831191730.GA7646@dhcp-lab-186.brq.redhat.com> <1220214626.29094.13.camel@luminos.localdomain> Message-ID: <20080901163252.GG4901@free.fr> On Mon, Sep 01, 2008 at 07:18:21PM +0300, Vasile Gaburici wrote: > TeXLive 2007 documenation is in the same ballpark as KDE's. For > TL2008, there's even more of it, but split in ~1500 sub-packages... It is not exactly the same since TeXLive doc was a real noarch package (something like texlive-texmf-doc) or the like. And most tex subpackages are noarch. -- Pat From dan at danny.cz Mon Sep 1 16:54:45 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Mon, 01 Sep 2008 18:54:45 +0200 Subject: Couple of review requests - haxe and nekovm - swapsies anyone? In-Reply-To: <20080901162411.GA29395@amd.home.annexia.org> References: <20080901162411.GA29395@amd.home.annexia.org> Message-ID: <1220288085.3536.14.camel@eagle.danny.cz> Richard W.M. Jones p??e v Po 01. 09. 2008 v 17:24 +0100: > https://bugzilla.redhat.com/show_bug.cgi?id=460779 > nekovm - Neko embedded scripting language and virtual machine > > which is required by: > > https://bugzilla.redhat.com/show_bug.cgi?id=460780 > haxe - Web programming language targeting Flash, Javascript, PHP I will do both. My review request is https://bugzilla.redhat.com/show_bug.cgi?id=452354 Dan -- Fedora and Red Hat package maintainer From jnovy at redhat.com Mon Sep 1 17:13:39 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 1 Sep 2008 19:13:39 +0200 Subject: Very nice of you to write the tl2rpm converter In-Reply-To: References: Message-ID: <20080901171339.GA17353@dhcp-lab-186.brq.redhat.com> Hi Vasile, On Mon, Sep 01, 2008 at 02:16:29AM +0300, Vasile Gaburici wrote: > It would have been even nicer had you cc'd fedora-devel-list... > > For those that don't read the tex-live at tug list, or the ambassadors' > list, here's the tl2rpm (prototype) announcement: > http://tug.org/pipermail/tex-live/2008-August/017190.html > > My main concern is that %post actions will turn out quite hairy, see > below (you were probably on vacation then): I was on PTO until the end of August. Thanks for heads-up. > ---------- Forwarded message ---------- > From: Vasile Gaburici > Date: Sun, Aug 10, 2008 at 8:19 AM > Subject: Re: TeXLive 2008 in F10? > To: Jonathan Underwood , Patrice Dumas > , Development discussions related to Fedora > > > > Initially I thought we could do without their installer, because I > found only 4 types of "execute", i.e. post install script actions in > the master texlive.tlpdb on CTAN. Yes, upstream has only four %post actions, two of them are trivial and is only adding maps or mixed maps to updmap.cfg. The third is just a generation of fmt files. But the last, addition of hyphenation paterns I still need to figure out. A good thing is that all of the data needed to do such %post actions are defined in a similar way as it is in spec so that it could be converted. Currently I'm playing with compiling binary TeX Live 2008. And it is needed to mention that Karl officially released TeX Live 2008 today. > Then I had a look at their new > packager's sources: > http://www.tug.org/svn/texlive/trunk/Master/tlpkg/TeXLive/. Besides > the 4 generic "execute" types, there are plenty of hardcoded > package-specific things in TLPostActions.pm. Right, this needs to be rewritten in something different than perl. Hopefully it won't be that hard since we can ignore the win32 stuff, which seems to be most tricky. > So, I don't see an easy way of dealing with this. Duplicating all that > stuff in rpm post scriptlets would be highly unmaintanable. TeX Live is released once per year and the set of things that need to be run in %post seems to be quite consistent during the year, so it shouldn't be a maintenance nightmare. But it definitely becomes a downstream packaging nightmare next year. > The only > sane way would be to install their packager library first, and to > execute post actions from there as needed, which needs at least a > wrapper script since that code is Perl. It's more than I have time for > this weekend... I'm not too good in perl so even if I have time through weekend I can't do that :) Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From vgaburici at gmail.com Mon Sep 1 17:31:27 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Mon, 1 Sep 2008 20:31:27 +0300 Subject: Very nice of you to write the tl2rpm converter In-Reply-To: <20080901171339.GA17353@dhcp-lab-186.brq.redhat.com> References: <20080901171339.GA17353@dhcp-lab-186.brq.redhat.com> Message-ID: On Mon, Sep 1, 2008 at 8:13 PM, Jindrich Novy wrote: > > TeX Live is released once per year and the set of things that need to > be run in %post seems to be quite consistent during the year, so it > shouldn't be a maintenance nightmare. But it definitely becomes a > downstream packaging nightmare next year. Actually, it seems that the whole point of the new packaging architecture is to provide frequent updates. The updates have been frequent up to the official release of today anyway. Karl said something about freezing the updates while the official DVDs get burned, but they plan to resume them shortly after that (sorry I don't have the email handy, but it was on tex-live at tug). I don't know how often the updates will happen, better ask Karl about that, but my guess is there will be more frequent updates than the once-a-year of the past. So, there needs to be a way to rebuild just some of the rpms. The modularity of TL itself is a bit misleading however. I've never seen a single binary, say pdftex, getting updated. Instead the updates that touch core binaries are full recompilation of all the core binaries. But the arch-independent packages were updated in a fine-grained manner. As far as updating the installer itself, well that happened too. I'm sure of it because on Windows they make you run a separate script to finish updating files that are normally locked while tlmgr is running (this includes all the Perl modules it uses). As you put it, hopefully that won't happen too often. Thanks, Vasile From forum at ru.bir.ru Mon Sep 1 17:31:27 2008 From: forum at ru.bir.ru (forum) Date: Mon, 01 Sep 2008 21:31:27 +0400 Subject: Thunderbird 3.0 Message-ID: <48BC26EF.7070700@ru.bir.ru> Do anybody make package of the Thunderbird 3.0 *Shredder? Now alpha 2 released. And would it be present in Fedora 10? * From jnovy at redhat.com Mon Sep 1 17:39:19 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Mon, 1 Sep 2008 19:39:19 +0200 Subject: Very nice of you to write the tl2rpm converter In-Reply-To: References: Message-ID: <20080901173919.GB17353@dhcp-lab-186.brq.redhat.com> On Mon, Sep 01, 2008 at 03:26:57AM +0300, Vasile Gaburici wrote: > Actually, the main problem I see with that single spec is update > handling. When a single source of those many thousands changes, you'd > have to rebuild all the binary rpms, and they'll all get a new release > number. The tl2rpm is able to produce separate specs per one TeXLive package. But it would lead to a huge number of packages around 4000 that we would need to add into Fedora. It is simply not a way to go. So I was thinking about schemes and collections that could be packaged separately. The schemes would only be a metapackages dependent on collections and collections would be sets of packages with one spec that would cover a particular part of TeX Live (like ConTeXt, langpacks, etc.) what is actually realizable since it would need about 400 packages. This looks like an optimal granularity for it since collections contain largest possible TeX Live bits that don't yet conflicts. But the review process for 400 generated specs quite scares me. > Unless there's some hack to avoid this, the Fedora user would > have to update all the texlive rpms every time, thus negating any > benefit of having TL split in those packages. This is "solved" by splitting it into collections. > > Also, I think you need a way patch that spec after it's generated or > perhaps as it is generated. Some reasons to do this: It is expected. Basically the main spec could be a maintainable template which %includes other specs for %post, %filelist and pakcge definitions and descriptions what could be automatically generated. The plan is to only touch the main spec. > > * packaging the TeX OpenType fonts only for TeX is a no-no these days > * some TL packages have incorrect/missing license. For instance > glyphlist, which contains Adobe's glyphlist.txt, (which is taken from > lcdf-typetools in TL2008) and IMHO needs "Redistributable, no > modification permitted". BTW, in TL2008 that file is required by > lcdf-typetools and dvipdfmx, but in Fedora's TL 2007, dvipdfmx > includes Adobe's file in its own rpm, so the rpm probably has an > incomplete license field because of it; should add "... and > Redistributable, no ..." like poppler has. > * some packages should probably not be built from TeXLive, so you > probably need blacklist. Examples: > - The Gyre fonts (currenly) have a licensing issue. > - Some packages like lcdf-typetools (in which all programs except > one don't actually need TeX at all) are probably better built outside > of TeXLive (with subpackages in this case). Blacklists will be very hard to do since it could break dependencies generated from the TeX Live metadata. > - You probably want to disable tlmgr. Unless you can patch it to > install rpms instead, of course, but that seem difficult to hack... > * the TL2008 texmf.cnf file uses $SELFAUTOPARENT. This can cause > trouble with binaries sitting outside its tree. If the user installs > any binaries of its own (say in /usr/local/bin), they won't work with > the default cnf. See: > http://tug.org/pipermail/tex-live/2008-August/017338.html > > As matter of approach, packaging TL binaries surely is convenient, but > there are some potential problems: I wouldn't package the precompiled TeX Live 2008 binaries. Currently I'm trying to build them from sources. It is still work in progress. > * odd shared libraries used. For instance TL2008's lcdf-typetools did > not work on Fedora 9 out of the box because of missing libstdc++.so.5 > (granted it's in a compat package, so when the RPM is built the right > dependency would probably get added), but that dependency is > gratuitous in this case. > * TL builds a lot of stuff statically liked. A prime example is XeTeX. > This one is tricky because it uses modified versions of some libraries > (ICU), some libraries which don't have any modifications but are also > included in XeTeX tree. + optflags we set in Fedora which would get ignored. > Hope this helps, > Vasile > > On Mon, Sep 1, 2008 at 2:16 AM, Vasile Gaburici wrote: > > It would have been even nicer had you cc'd fedora-devel-list... > > > > For those that don't read the tex-live at tug list, or the ambassadors' > > list, here's the tl2rpm (prototype) announcement: > > http://tug.org/pipermail/tex-live/2008-August/017190.html > > > > My main concern is that %post actions will turn out quite hairy, see > > below (you were probably on vacation then): > > > > ---------- Forwarded message ---------- > > From: Vasile Gaburici > > Date: Sun, Aug 10, 2008 at 8:19 AM > > Subject: Re: TeXLive 2008 in F10? > > To: Jonathan Underwood , Patrice Dumas > > , Development discussions related to Fedora > > > > > > > > Initially I thought we could do without their installer, because I > > found only 4 types of "execute", i.e. post install script actions in > > the master texlive.tlpdb on CTAN. Then I had a look at their new > > packager's sources: > > http://www.tug.org/svn/texlive/trunk/Master/tlpkg/TeXLive/. Besides > > the 4 generic "execute" types, there are plenty of hardcoded > > package-specific things in TLPostActions.pm. > > > > So, I don't see an easy way of dealing with this. Duplicating all that > > stuff in rpm post scriptlets would be highly unmaintanable. The only > > sane way would be to install their packager library first, and to > > execute post actions from there as needed, which needs at least a > > wrapper script since that code is Perl. It's more than I have time for > > this weekend... > > -- Jindrich Novy http://people.redhat.com/jnovy/ From pbrobinson at gmail.com Mon Sep 1 17:43:02 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 1 Sep 2008 18:43:02 +0100 Subject: Thunderbird 3.0 In-Reply-To: <48BC26EF.7070700@ru.bir.ru> References: <48BC26EF.7070700@ru.bir.ru> Message-ID: <5256d0b0809011043w27fb2badi9c9b3d0d32249e01@mail.gmail.com> > Do anybody make package of the Thunderbird 3.0 *Shredder? Now alpha 2 > released. > > And would it be present in Fedora 10? I think it will be more likely for Fedora 11 than Fedora 10 as its due to be based on gecko 1.9.1 (IE Firefox 3.1) which isn't due until November so I don't think TB3 is due until January. FF3.1 snapshots haven't started to show up in rawhide yet and that would be a start. Peter From tim.lauridsen at googlemail.com Mon Sep 1 18:20:55 2008 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Mon, 01 Sep 2008 20:20:55 +0200 Subject: [PATCH] yum: make transaction results available to plugins In-Reply-To: References: <1220281212.8829.0.camel@rosebud> Message-ID: <48BC3287.8090708@googlemail.com> Xavier Toth wrote: > I have a number of rpms that install SELinux policy modules during the > post install and I want yum to exit if there is any problem. I've > written a plugin with a posttrans method that examines the result and > exits if there was any problem. If there is another way to do this I'd > be happy to hear about it. > def postresolve_hook(conduit): txmbrs = conduit.getTsInfo().getMembers() # Do your actions on txmbrs This shoud give you the result of the transaction after depsolve. Tim From nicolas.mailhot at laposte.net Mon Sep 1 18:32:08 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 01 Sep 2008 20:32:08 +0200 Subject: Very nice of you to write the tl2rpm converter In-Reply-To: <20080901173919.GB17353@dhcp-lab-186.brq.redhat.com> References: <20080901173919.GB17353@dhcp-lab-186.brq.redhat.com> Message-ID: <1220293928.2037.3.camel@rousalka.okg> Le lundi 01 septembre 2008 ? 19:39 +0200, Jindrich Novy a ?crit : > This looks like an optimal granularity for it since collections > contain largest possible TeX Live bits that don't yet conflicts. But > the review process for 400 generated specs quite scares me. Just start by splitting out all the stuff useful to non-TEX users (ie fonts) and you'll find reviewers and possibly co-maintainers. I'd rather review a score of simple packages that follow standard templates than the horror the current mashup is. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From ville.skytta at iki.fi Mon Sep 1 18:41:00 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Mon, 1 Sep 2008 21:41:00 +0300 Subject: libdvdread slight API breakage In-Reply-To: <20080831114518.GF11794@mokona.greysector.net> References: <20080726223914.GC19598@mokona.greysector.net> <20080727221646.GB25605@mokona.greysector.net> <20080831114518.GF11794@mokona.greysector.net> Message-ID: <200809012141.00879.ville.skytta@iki.fi> On Sunday 31 August 2008, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 28 July 2008 at 00:16, Dominik 'Rathann' Mierzejewski wrote: > > On Sunday, 27 July 2008 at 11:11, Ville Skytt? wrote: > > > > > > Any ideas why they did that > > > > To avoid clash with MPlayer's internal libdvdread copy. I'm trying > > to convince Nico to reverse that and change MPlayer's internal copy > > instead (or remove it alltogether) before the next release. > > And I've been successful. Patch is already in SVN and the upcoming > 4.1.3 release will keep the old include paths. MPlayer has already > been fixed, too. > Sorry for the extra work it caused you. No problem, thanks for the report and for spending time to improve this! From vgaburici at gmail.com Mon Sep 1 18:55:16 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Mon, 1 Sep 2008 21:55:16 +0300 Subject: Very nice of you to write the tl2rpm converter In-Reply-To: <1220293928.2037.3.camel@rousalka.okg> References: <20080901173919.GB17353@dhcp-lab-186.brq.redhat.com> <1220293928.2037.3.camel@rousalka.okg> Message-ID: On Mon, Sep 1, 2008 at 9:32 PM, Nicolas Mailhot wrote: > Le lundi 01 septembre 2008 ? 19:39 +0200, Jindrich Novy a ?crit : > >> This looks like an optimal granularity for it since collections >> contain largest possible TeX Live bits that don't yet conflicts. But >> the review process for 400 generated specs quite scares me. > > Just start by splitting out all the stuff useful to non-TEX users (ie > fonts) and you'll find reviewers and possibly co-maintainers. I'd rather > review a score of simple packages that follow standard templates than > the horror the current mashup is. That can't be done by just grouping the TeXLive packages, you'd need some splitting as well. In TL 2008 each font package contains the fonts in a bunch of formats, some of which are useful only for TeX, some of general interest. Take for instance a simple font like cyklop (a relatively new titling font from GUST -- don't worry these are digitizations of old metal fonts, so no copyright issues), which has only a regular and italic variants. In the same package you find the two .otf files of general interest, two afm/pfb pairs of legacy interest, as well as a whole bunch of (La)TeX-specific files (.fd, .tfm, .enc, .map and a .sty) for various (La)TeX 8-bit encodings. As you know all these files are essentially only metrics and encoding vectors; TeX82 drivers and pdfTeX use the pfbs for the actual glyphs. There's no problem moving the otf files to the system font dir however. XeTeX can find them via fontconfig, and for LuaTeX you can set OSFONTDIR. Note that the LuaTeX that ships with TeXLive 2008 is hardly usable: it has bugs in it's font cache code, and it's installed (as in copied) but not really cofigured by TL (there's a page with instructions on contextgarden if you really want to use it), so don't worry too much about it. Anyone interested in LuaTeX uses the ConTeXt "minimals" distro these says --- LuaTeX doesn't currently support LaTeX or plain TeX. > > -- > Nicolas Mailhot > From vgaburici at gmail.com Mon Sep 1 19:18:26 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Mon, 1 Sep 2008 22:18:26 +0300 Subject: Very nice of you to write the tl2rpm converter In-Reply-To: References: <20080901173919.GB17353@dhcp-lab-186.brq.redhat.com> <1220293928.2037.3.camel@rousalka.okg> Message-ID: Alternatively, although Nicolas won't like it, one could just symlink texmf-dist/fonts/opentype/public under the system fonts dir. This is definitely less work than splitting every TL font package. OTOH, you could script the splitting easily enough since there are only otf files in those dirs and no otf files go anywhere else in the TL tree. Note that some fonts like Asana-Math (and probably others) are already included separately in Fedora. The situation is slightly more complicated with texmf-dist/fonts/truetype because pdftex can use those fonts directly, but it cannot find them via fontconfig (or any environment variable that I know of, but there may well be one). So, they'd have to be symlinked one way or the other in both the system fonts dir and the tex-live fonts dir. Nasty business these fonts are. ;) On Mon, Sep 1, 2008 at 9:55 PM, Vasile Gaburici wrote: > On Mon, Sep 1, 2008 at 9:32 PM, Nicolas Mailhot > wrote: >> Le lundi 01 septembre 2008 ? 19:39 +0200, Jindrich Novy a ?crit : >> >>> This looks like an optimal granularity for it since collections >>> contain largest possible TeX Live bits that don't yet conflicts. But >>> the review process for 400 generated specs quite scares me. >> >> Just start by splitting out all the stuff useful to non-TEX users (ie >> fonts) and you'll find reviewers and possibly co-maintainers. I'd rather >> review a score of simple packages that follow standard templates than >> the horror the current mashup is. > > That can't be done by just grouping the TeXLive packages, you'd need > some splitting as well. In TL 2008 each font package contains the > fonts in a bunch of formats, some of which are useful only for TeX, > some of general interest. > > Take for instance a simple font like cyklop (a relatively new titling > font from GUST -- don't worry these are digitizations of old metal > fonts, so no copyright issues), which has only a regular and italic > variants. In the same package you find the two .otf files of general > interest, two afm/pfb pairs of legacy interest, as well as a whole > bunch of (La)TeX-specific files (.fd, .tfm, .enc, .map and a .sty) for > various (La)TeX 8-bit encodings. As you know all these files are > essentially only metrics and encoding vectors; TeX82 drivers and > pdfTeX use the pfbs for the actual glyphs. > > There's no problem moving the otf files to the system font dir > however. XeTeX can find them via fontconfig, and for LuaTeX you can > set OSFONTDIR. > > Note that the LuaTeX that ships with TeXLive 2008 is hardly usable: it > has bugs in it's font cache code, and it's installed (as in copied) > but not really cofigured by TL (there's a page with instructions on > contextgarden if you really want to use it), so don't worry too much > about it. Anyone interested in LuaTeX uses the ConTeXt "minimals" > distro these says --- LuaTeX doesn't currently support LaTeX or plain > TeX. > >> >> -- >> Nicolas Mailhot >> > From joshuacov at googlemail.com Mon Sep 1 19:44:36 2008 From: joshuacov at googlemail.com (Joshua C.) Date: Mon, 1 Sep 2008 21:44:36 +0200 Subject: Problems with kernel-2.6.26 and 2.6.27-0.x.rc2 In-Reply-To: <1220218562.15187.33.camel@optimus> References: <5f6f8c5f0808281513l53c7a302u31f1b53e6955cb29@mail.gmail.com> <5f6f8c5f0808292331v1eee5802o9fb0f5a37dca20@mail.gmail.com> <1220218562.15187.33.camel@optimus> Message-ID: <5f6f8c5f0809011244w6c1f949di2df407fd35c5c66d@mail.gmail.com> 2008/8/31 Dave Airlie : > > So you have two problems.. one is a kernel module is loading and hanging > the boot process, this is usually blamed on udev, the fact that hitting > a key helps implies some interrupt handling problem maybe.. You were right. the problem with udev concerns the timer broadcast for the amd processors. the linux-2.6-x86-32-amd-c1e-force-timer-broadcast-late.patch corrected this. I tried it with 2.6.26.3-17.fc9 and 2.6.27-0.290.rc5.fc10 and everything is fine. the udev starts normally. so i can close the first bug. Now about the kernel modesetting: > > The other is the graphical boot not working properly on your card, for > that you can boot with nomodeset on the command line, if udev hangs that > is the other problem. For the graphical boot, I'd need to know the > graphics card and type of card, agp pci etc. and type of display plugged > in. > > Dave. with the patch applied and nomodeset at the command line the kernel loads fine until the time for the xserver to start. then i get a blank screen. just nothing. here are the specs for my card: integrated Radeon Xpress 1100 on acer aspire laptop. #lscpi -vvv 01:05.0 VGA compatible controller: ATI Technologies Inc RS485 [Radeon Xpress 1100 IGP] (prog-if 00 [VGA controller]) Subsystem: Acer Incorporated [ALI] Unknown device 010f Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- From pbrobinson at gmail.com Mon Sep 1 19:48:17 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 1 Sep 2008 20:48:17 +0100 Subject: rawhide? Message-ID: <5256d0b0809011248i4d87294eo4ec44fa8f884071f@mail.gmail.com> What's the plans for the rawhide push, I haven't seen one for a couple of days? Peter From naheemzaffar at gmail.com Mon Sep 1 20:01:11 2008 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Mon, 1 Sep 2008 21:01:11 +0100 Subject: Fedora 9.1? Message-ID: <3adc77210809011301g23b5fae7rf83e7f25941f05a6@mail.gmail.com> Are there any plans for a re-release of Fedora 9 with updated keys? From jonstanley at gmail.com Mon Sep 1 20:19:12 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Mon, 1 Sep 2008 16:19:12 -0400 Subject: Fedora 9.1? In-Reply-To: <3adc77210809011301g23b5fae7rf83e7f25941f05a6@mail.gmail.com> References: <3adc77210809011301g23b5fae7rf83e7f25941f05a6@mail.gmail.com> Message-ID: On Mon, Sep 1, 2008 at 4:01 PM, Naheem Zaffar wrote: > Are there any plans for a re-release of Fedora 9 with updated keys? Not as such, no. The current plan can be found at http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html, with the latest draft of the actual locations over at http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001635.html and ensuing discussion This plan already has FESCo buy-in, with whatever minor tweaks rel-eng might need to make, but this is the essence of what's going to happen. From valent.turkovic at gmail.com Mon Sep 1 20:28:42 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Mon, 1 Sep 2008 22:28:42 +0200 Subject: file system mount In-Reply-To: <604aa7910711011222t2fe12dfmd237998f759f4cee@mail.gmail.com> References: <47297920.60509@fedoraproject.org> <1193942501.7233.10.camel@localhost.localdomain> <604aa7910711011222t2fe12dfmd237998f759f4cee@mail.gmail.com> Message-ID: <64b14b300809011328v7597adf7t80f4448c1bc818e4@mail.gmail.com> On Thu, Nov 1, 2007 at 9:22 PM, Jeff Spaleta wrote: > On 11/1/07, David Zeuthen wrote: >> http://people.freedesktop.org/~david/polkit-gnome-authorizations.png >> >> but the UI is likely to change. >> >> Hope this helps. > > Is per device policy granting in the works? So that certain disks are > mountable but others aren't on a user by user basis? > > -jef"Idle thought: How well does policy granting work with sabayon?"spaleta > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Hi David, I saw this a bit older thread and looked at PolicyKit manual and if I'm not mistaken now you have the ability to make a more granual per-device policies, right? Have the talks with anaconda team continued? What is the verdict? UUID or back to labels? Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From lsof at nodata.co.uk Mon Sep 1 20:37:31 2008 From: lsof at nodata.co.uk (nodata) Date: Mon, 01 Sep 2008 22:37:31 +0200 Subject: Fedora 9.1? In-Reply-To: References: <3adc77210809011301g23b5fae7rf83e7f25941f05a6@mail.gmail.com> Message-ID: <1220301451.9881.0.camel@sb-home> Am Montag, den 01.09.2008, 16:19 -0400 schrieb Jon Stanley: > On Mon, Sep 1, 2008 at 4:01 PM, Naheem Zaffar wrote: > > Are there any plans for a re-release of Fedora 9 with updated keys? > > Not as such, no. The current plan can be found at > http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html, > with the latest draft of the actual locations over at > http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001635.html > and ensuing discussion > > This plan already has FESCo buy-in, with whatever minor tweaks rel-eng > might need to make, but this is the essence of what's going to happen. > "[The new] fedora-release is put into the OLD repo, signed by the OLD key." Isn't this counter-intuitive? From a.badger at gmail.com Mon Sep 1 20:49:59 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 01 Sep 2008 13:49:59 -0700 Subject: Fedora 9.1? In-Reply-To: <1220301451.9881.0.camel@sb-home> References: <3adc77210809011301g23b5fae7rf83e7f25941f05a6@mail.gmail.com> <1220301451.9881.0.camel@sb-home> Message-ID: <48BC5577.9050705@gmail.com> nodata wrote: > Am Montag, den 01.09.2008, 16:19 -0400 schrieb Jon Stanley: >> On Mon, Sep 1, 2008 at 4:01 PM, Naheem Zaffar wrote: >>> Are there any plans for a re-release of Fedora 9 with updated keys? >> Not as such, no. The current plan can be found at >> http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html, >> with the latest draft of the actual locations over at >> http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001635.html >> and ensuing discussion >> >> This plan already has FESCo buy-in, with whatever minor tweaks rel-eng >> might need to make, but this is the essence of what's going to happen. >> > > "[The new] fedora-release is put into the OLD repo, signed by the OLD > key." > > Isn't this counter-intuitive? > The idea is that fedora-release contains the new key and the new repository location. So it has to go in the old repository, signed with the old key so people hitting the old repository get those. Maybe we should have two new fedora-release packages. The lower NEVR one can go in the OLD repo and the newer one in the new repo. (That way we end up with 0 packages signed by the old key on the new system). -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From warren at togami.com Mon Sep 1 23:21:18 2008 From: warren at togami.com (Warren Togami) Date: Mon, 01 Sep 2008 19:21:18 -0400 Subject: Fedora 9.1? In-Reply-To: <48BC5577.9050705@gmail.com> References: <3adc77210809011301g23b5fae7rf83e7f25941f05a6@mail.gmail.com> <1220301451.9881.0.camel@sb-home> <48BC5577.9050705@gmail.com> Message-ID: <48BC78EE.3010300@togami.com> Toshio Kuratomi wrote: > nodata wrote: >> Am Montag, den 01.09.2008, 16:19 -0400 schrieb Jon Stanley: >>> On Mon, Sep 1, 2008 at 4:01 PM, Naheem Zaffar wrote: >>>> Are there any plans for a re-release of Fedora 9 with updated keys? >>> Not as such, no. The current plan can be found at >>> http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html, >>> with the latest draft of the actual locations over at >>> http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001635.html >>> and ensuing discussion >>> >>> This plan already has FESCo buy-in, with whatever minor tweaks rel-eng >>> might need to make, but this is the essence of what's going to happen. >>> >> "[The new] fedora-release is put into the OLD repo, signed by the OLD >> key." >> >> Isn't this counter-intuitive? >> > The idea is that fedora-release contains the new key and the new > repository location. So it has to go in the old repository, signed with > the old key so people hitting the old repository get those. > > Maybe we should have two new fedora-release packages. The lower NEVR > one can go in the OLD repo and the newer one in the new repo. (That way > we end up with 0 packages signed by the old key on the new system). > That is actually already in the plan as written. Warren From michel.sylvan at gmail.com Mon Sep 1 23:24:11 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Mon, 1 Sep 2008 19:24:11 -0400 Subject: Revert curl change made for flash In-Reply-To: <1218555969.10489.34.camel@localhost.localdomain> References: <1218543934.10489.17.camel@localhost.localdomain> <48A1A35D.6010705@togami.com> <1218555969.10489.34.camel@localhost.localdomain> Message-ID: On Tue, Aug 12, 2008 at 11:46 AM, Josh Boyer wrote: > If there are legitimate reasons to have the older soname library in > Fedora, it should be done properly as a compat-curl package. That is > what I am going to press for in the FESCo meeting tomorrow. > > (There is also the possibility to have compat-curl done as a subpackage > of curl. That might be acceptable but we'll see how the discussion goes > tomorrow.) > Now that the change has been undone, what is the plan for providing libcurl.so.3? Apologies if this has been asked before, but searching the archives did not show anything. No bugzilla review request either. (if anyone is talking to Adobe requesting a recompile, then the need for a compat library is moot, naturally) Thanks, -- Michel Salim http://hircus.jaiku.com/ From jonstanley at gmail.com Mon Sep 1 23:29:33 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Mon, 1 Sep 2008 19:29:33 -0400 Subject: Revert curl change made for flash In-Reply-To: References: <1218543934.10489.17.camel@localhost.localdomain> <48A1A35D.6010705@togami.com> <1218555969.10489.34.camel@localhost.localdomain> Message-ID: On Mon, Sep 1, 2008 at 7:24 PM, Michel Salim wrote: > Now that the change has been undone, what is the plan for providing > libcurl.so.3? Apologies if this has been asked before, but searching > the archives did not show anything. No bugzilla review request either. What has been undone? FESCo voted to leave this alone., So unless some other change has snuck in that I don't know about (I haven't looked), then this workaround is alive and well. From wtogami at redhat.com Mon Sep 1 23:30:08 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 01 Sep 2008 19:30:08 -0400 Subject: Revert curl change made for flash In-Reply-To: References: <1218543934.10489.17.camel@localhost.localdomain> <48A1A35D.6010705@togami.com> <1218555969.10489.34.camel@localhost.localdomain> Message-ID: <48BC7B00.6040302@redhat.com> Michel Salim wrote: > On Tue, Aug 12, 2008 at 11:46 AM, Josh Boyer wrote: > >> If there are legitimate reasons to have the older soname library in >> Fedora, it should be done properly as a compat-curl package. That is >> what I am going to press for in the FESCo meeting tomorrow. >> >> (There is also the possibility to have compat-curl done as a subpackage >> of curl. That might be acceptable but we'll see how the discussion goes >> tomorrow.) >> > Now that the change has been undone, what is the plan for providing > libcurl.so.3? Apologies if this has been asked before, but searching > the archives did not show anything. No bugzilla review request either. > > (if anyone is talking to Adobe requesting a recompile, then the need > for a compat library is moot, naturally) > Adobe said their next build will use either libcurl.so.3 or libcurl.so.4, whatever is available on the system. I suppose this means wait until their next public build. Warren From michel.sylvan at gmail.com Mon Sep 1 23:43:38 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Mon, 1 Sep 2008 19:43:38 -0400 Subject: Revert curl change made for flash In-Reply-To: References: <1218543934.10489.17.camel@localhost.localdomain> <48A1A35D.6010705@togami.com> <1218555969.10489.34.camel@localhost.localdomain> Message-ID: On Mon, Sep 1, 2008 at 7:29 PM, Jon Stanley wrote: > On Mon, Sep 1, 2008 at 7:24 PM, Michel Salim wrote: > >> Now that the change has been undone, what is the plan for providing >> libcurl.so.3? Apologies if this has been asked before, but searching >> the archives did not show anything. No bugzilla review request either. > > What has been undone? FESCo voted to leave this alone., So unless some > other change has snuck in that I don't know about (I haven't looked), > then this workaround is alive and well. > I've been excluding *curl* from my update ever since Rawhide went back live. The changelog for curl indicated that the change has been reverted by Spot: * Fri Aug 22 2008 Tom "spot" Callaway 7.18.2-5 - undo mini libcurl.so.3 But if as Warren said, Adobe is coming out with a new build, then as long as there is one that installs out of the box for Fedora 10 final, everything is fine. -- Michel Salim http://hircus.jaiku.com/ From tgl at redhat.com Tue Sep 2 00:30:14 2008 From: tgl at redhat.com (Tom Lane) Date: Mon, 01 Sep 2008 20:30:14 -0400 Subject: SGML support refactored in F-10? In-Reply-To: <1220015170.3980.43.camel@dhcp-lab-219.englab.brq.redhat.com> References: <17316.1219966344@sss.pgh.pa.us> <1219967329.6260.3.camel@localhost.localdomain> <1220015170.3980.43.camel@dhcp-lab-219.englab.brq.redhat.com> Message-ID: <907.1220315414@sss.pgh.pa.us> =?UTF-8?Q?Ond=C5=99ej_Va=C5=A1=C3=ADk?= writes: > Thanks for report. Looks like some kind of heavy-weight black magic. > Problems mentioned by Mathias were solved in mid July, it is not related > to the current troubles as those changes are completely same for rawhide > and F9. Actually everything is same, diff is showing the only difference > in requires for xml-common, release number, changelog changes and > switched position of CATALOG definition (just changing the position > didn't help). After usage of F-9 spec file (with devel changelog and > version) it seems to work properly again.It seems there is something > very fragile in docbook-dtds.spec and it was accidently broken. > http://koji.fedoraproject.org/koji/taskinfo?taskID=793167 > should work for you. At least it works for me... Thanks for trying, but it still fails with about the same symptoms: http://koji.fedoraproject.org/koji/taskinfo?taskID=799111 regards, tom lane From rjones at redhat.com Tue Sep 2 08:01:50 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 2 Sep 2008 09:01:50 +0100 Subject: wtf ... Something strips installed binaries??? Message-ID: <20080902080150.GA483@amd.home.annexia.org> I installed a binary from an RPM last night. Here's what I installed: # rpm -qlvp ~rjones/rpmbuild/RPMS/i386/ocsigen-1.1.0-3.fc10.i386.rpm | grep /usr/bin -rwxr-xr-x 1 root root 2294198 Sep 1 23:32 /usr/bin/ocsigen This morning: # ll /usr/bin/ocsigen -rwxr-xr-x 1 root root 298908 2008-09-01 23:32 /usr/bin/ocsigen This stipped binary is broken -- these binaries must NEVER be stripped! /var/log/prelink/prelink.log shows that prelink did something to the binary, but shows no errors. (1) What is stripping installed binaries? (2) How do I tell automated cron jobs NOT to interfere with installed binaries? Rich. PS. Personally I think the idea of having cronjobs which modify system files under /usr in-place is totally crack. If prelinking is genuinely useful, save the extra prelink data into a /var file. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From tmus at tmus.dk Tue Sep 2 09:01:43 2008 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 02 Sep 2008 07:01:43 -0200 Subject: wtf ... Something strips installed binaries??? In-Reply-To: <20080902080150.GA483@amd.home.annexia.org> References: <20080902080150.GA483@amd.home.annexia.org> Message-ID: Richard W.M. Jones wrote: > I installed a binary from an RPM last night. Here's what I installed: > > # rpm -qlvp ~rjones/rpmbuild/RPMS/i386/ocsigen-1.1.0-3.fc10.i386.rpm | grep /usr/bin > -rwxr-xr-x 1 root root 2294198 Sep 1 23:32 /usr/bin/ocsigen > > This morning: > > # ll /usr/bin/ocsigen > -rwxr-xr-x 1 root root 298908 2008-09-01 23:32 /usr/bin/ocsigen > > This stipped binary is broken -- these binaries must NEVER be stripped! > > /var/log/prelink/prelink.log shows that prelink did something to the > binary, but shows no errors. > > (1) What is stripping installed binaries? > > (2) How do I tell automated cron jobs NOT to interfere with installed > binaries? > > Rich. > > PS. Personally I think the idea of having cronjobs which modify system > files under /usr in-place is totally crack. If prelinking is > genuinely useful, save the extra prelink data into a /var file. > I wasn't even aware that prelinking actually changed the files. Isn't this kind of dangerous from a system-integrity point-of-view. How can we ever validate binaries if they are modified on purpose? /Thomas From foster at in.tum.de Tue Sep 2 09:03:53 2008 From: foster at in.tum.de (Mary Ellen Foster) Date: Tue, 2 Sep 2008 10:03:53 +0100 Subject: wtf ... Something strips installed binaries??? In-Reply-To: <20080902080150.GA483@amd.home.annexia.org> References: <20080902080150.GA483@amd.home.annexia.org> Message-ID: 2008/9/2 Richard W.M. Jones : > (2) How do I tell automated cron jobs NOT to interfere with installed > binaries? I can't comment on the other issues, but for this question, you probably want to drop a file into /etc/prelink.conf.d to "blacklist" the files you don't need prelinked. Based on the example that's there (nss-prelink.conf), you want to include lines like this: -b /pattern/that/matches/file* I once had a program that stopped working after prelink ran, but that's just because it checked its own md5sum and then "called home" to see if there was a newer version available. I've never seen it actually break anything about the executable itself. MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ Informatik 6: Robotics and Embedded Systems, Technische Universit?t M?nchen and ICCS, School of Informatics, University of Edinburgh From billcrawford1970 at gmail.com Tue Sep 2 09:05:25 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Tue, 2 Sep 2008 10:05:25 +0100 Subject: wtf ... Something strips installed binaries??? In-Reply-To: References: <20080902080150.GA483@amd.home.annexia.org> Message-ID: <544eb990809020205q4f0c7764ycfbbd5b2080c09fb@mail.gmail.com> Thomas M Steenholdt wrote: > I wasn't even aware that prelinking actually changed the files. Isn't this kind of dangerous from a system-integrity point-of-view. How can we ever validate binaries if they are modified on purpose? With "prelink --verify" ? From rc040203 at freenet.de Tue Sep 2 09:26:58 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 02 Sep 2008 11:26:58 +0200 Subject: wtf ... Something strips installed binaries??? In-Reply-To: <20080902080150.GA483@amd.home.annexia.org> References: <20080902080150.GA483@amd.home.annexia.org> Message-ID: <1220347618.2795.448.camel@beck.corsepiu.local> On Tue, 2008-09-02 at 09:01 +0100, Richard W.M. Jones wrote: > I installed a binary from an RPM last night. Here's what I installed: > > # rpm -qlvp ~rjones/rpmbuild/RPMS/i386/ocsigen-1.1.0-3.fc10.i386.rpm | grep /usr/bin > -rwxr-xr-x 1 root root 2294198 Sep 1 23:32 /usr/bin/ocsigen > > This morning: > > # ll /usr/bin/ocsigen > -rwxr-xr-x 1 root root 298908 2008-09-01 23:32 /usr/bin/ocsigen > > This stipped binary is broken -- these binaries must NEVER be stripped! Why? I for one consider applications which "must NEVER be stripped" to be "broken". > PS. Personally I think the idea of having cronjobs which modify system > files under /usr in-place is totally crack. Agreed. Ralf From berrange at redhat.com Tue Sep 2 09:48:55 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 2 Sep 2008 10:48:55 +0100 Subject: wtf ... Something strips installed binaries??? In-Reply-To: <20080902080150.GA483@amd.home.annexia.org> References: <20080902080150.GA483@amd.home.annexia.org> Message-ID: <20080902094855.GC29748@redhat.com> On Tue, Sep 02, 2008 at 09:01:50AM +0100, Richard W.M. Jones wrote: > > I installed a binary from an RPM last night. Here's what I installed: > > # rpm -qlvp ~rjones/rpmbuild/RPMS/i386/ocsigen-1.1.0-3.fc10.i386.rpm | grep /usr/bin > -rwxr-xr-x 1 root root 2294198 Sep 1 23:32 /usr/bin/ocsigen > > This morning: > > # ll /usr/bin/ocsigen > -rwxr-xr-x 1 root root 298908 2008-09-01 23:32 /usr/bin/ocsigen > > This stipped binary is broken -- these binaries must NEVER be stripped! Why mustn't it be stripped ? If it genuinely needs the symbol data, then adding the blacklist to prelink is reasonable. If it is merely that the strip binary is doing something wrong, then a BZ against strip is needed to get it fixed. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From rjones at redhat.com Tue Sep 2 09:57:12 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 2 Sep 2008 10:57:12 +0100 Subject: wtf ... Something strips installed binaries??? In-Reply-To: <20080902094855.GC29748@redhat.com> References: <20080902080150.GA483@amd.home.annexia.org> <20080902094855.GC29748@redhat.com> Message-ID: <20080902095712.GB483@amd.home.annexia.org> On Tue, Sep 02, 2008 at 10:48:55AM +0100, Daniel P. Berrange wrote: > On Tue, Sep 02, 2008 at 09:01:50AM +0100, Richard W.M. Jones wrote: > > > > I installed a binary from an RPM last night. Here's what I installed: > > > > # rpm -qlvp ~rjones/rpmbuild/RPMS/i386/ocsigen-1.1.0-3.fc10.i386.rpm | grep /usr/bin > > -rwxr-xr-x 1 root root 2294198 Sep 1 23:32 /usr/bin/ocsigen > > > > This morning: > > > > # ll /usr/bin/ocsigen > > -rwxr-xr-x 1 root root 298908 2008-09-01 23:32 /usr/bin/ocsigen > > > > This stipped binary is broken -- these binaries must NEVER be stripped! > > Why mustn't it be stripped ? If it genuinely needs the symbol data, then > adding the blacklist to prelink is reasonable. If it is merely that the > strip binary is doing something wrong, then a BZ against strip is needed > to get it fixed. Apparently it's because it appends bytecode to its own binary (which is a broken thing to do, but is now deprecated anyway[1]). Strip on the other hand ought to recognise that the binary is no longer a coherent ELF file and quit. So I'd agree this is really a bug against strip. Note that we found that strip also destroys MinGW (Windows) binaries. Again, it should give up on binaries that it doesn't understand, rather than destroying them. But is it /usr/bin/strip? Does prelink run /usr/bin/strip first? Do prelink and strip use a common ELF-manipulation library which is at fault? Really, cronjobs shouldn't be modifying files in /usr/bin. Save data in /var/, or modify the ELF format to make it more efficient so it doesn't need prelink. Rich. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256900#49 -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From jwboyer at gmail.com Tue Sep 2 11:59:15 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 2 Sep 2008 07:59:15 -0400 Subject: Revert curl change made for flash In-Reply-To: References: <1218543934.10489.17.camel@localhost.localdomain> <48A1A35D.6010705@togami.com> <1218555969.10489.34.camel@localhost.localdomain> Message-ID: <20080902115901.GA2218@yoda.jdub.homelinux.org> On Mon, Sep 01, 2008 at 07:29:33PM -0400, Jon Stanley wrote: >On Mon, Sep 1, 2008 at 7:24 PM, Michel Salim wrote: > >> Now that the change has been undone, what is the plan for providing >> libcurl.so.3? Apologies if this has been asked before, but searching >> the archives did not show anything. No bugzilla review request either. > >What has been undone? FESCo voted to leave this alone., So unless some >other change has snuck in that I don't know about (I haven't looked), >then this workaround is alive and well. Upstream curl pointed out that the ABI between .4 and .3 was not the same and that the soname change was done on purpose. Spot reverted this a week or so ago. josh From ndbecker2 at gmail.com Tue Sep 2 12:39:38 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 02 Sep 2008 08:39:38 -0400 Subject: dbus error from yum Message-ID: ERROR:dbus.connection:Unable to set arguments ('posttrans',) according to signature '': : Fewer items found in D-Bus signature than in Python arguments Unable to send message to PackageKit What does this mean? From bruno at wolff.to Tue Sep 2 12:41:23 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 2 Sep 2008 07:41:23 -0500 Subject: wtf ... Something strips installed binaries??? In-Reply-To: References: <20080902080150.GA483@amd.home.annexia.org> Message-ID: <20080902124123.GA2078@wolff.to> On Tue, Sep 02, 2008 at 07:01:43 -0200, Thomas M Steenholdt wrote: > > I wasn't even aware that prelinking actually changed the files. Isn't > this kind of dangerous from a system-integrity point-of-view. How can we > ever validate binaries if they are modified on purpose? I run rpmverify to check installed files and it seems to handle prelinked files reasonably. I don't know what it does to check them, but it does appear to be able to. From skvidal at fedoraproject.org Tue Sep 2 12:47:01 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 02 Sep 2008 12:47:01 +0000 Subject: dbus error from yum In-Reply-To: References: Message-ID: <1220359621.8829.10.camel@rosebud> On Tue, 2008-09-02 at 08:39 -0400, Neal Becker wrote: > ERROR:dbus.connection:Unable to set arguments ('posttrans',) according to signature '': : Fewer items found in D-Bus signature than in Python arguments > Unable to send message to PackageKit > > What does this mean? The error is from the packagekit plugin. It's reasonably harmless and should only show up that once. It's been fixed in PK already -sv From tmus at tmus.dk Tue Sep 2 13:07:45 2008 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 02 Sep 2008 11:07:45 -0200 Subject: wtf ... Something strips installed binaries??? In-Reply-To: <544eb990809020205q4f0c7764ycfbbd5b2080c09fb@mail.gmail.com> References: <20080902080150.GA483@amd.home.annexia.org> <544eb990809020205q4f0c7764ycfbbd5b2080c09fb@mail.gmail.com> Message-ID: Bill Crawford wrote: > Thomas M Steenholdt wrote: >> I wasn't even aware that prelinking actually changed the files. Isn't this kind of dangerous from a system-integrity point-of-view. How can we ever validate binaries if they are modified on purpose? > > With "prelink --verify" ? > I can't see how that would actually verify that the binary has not been modified by a rootkit or whatever? rpm -V should be able to detect this, on the other hand, but how it works in conjunction with prelinking I don't know... /Thomas From limb at jcomserv.net Tue Sep 2 13:11:17 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 2 Sep 2008 08:11:17 -0500 (CDT) Subject: Looking for new package owners In-Reply-To: <48B5AC38.4040300@ieee.org> References: <48ADBA3A.7070707@ieee.org> <3194.198.175.55.5.1219861519.squirrel@mail.jcomserv.net> <48B5AC38.4040300@ieee.org> Message-ID: <43563.198.175.55.5.1220361077.squirrel@mail.jcomserv.net> > Jon Ciesla wrote: >>> I can take autotrace and mftrace. I'm about to package more font >>> generation tools, i.e. mf2pt1 and metatype1. But I have yet to be >>> sponsored, so it will take a while... >>> >> >> Thanks Quentin! >> >> Vasile, my koji devel build of lilypond dies during an mftrace step. Do >> you have any insight? Might mftrace need a rebuild? A newer version is >> available anyway. . . >> http://koji.fedoraproject.org/koji/taskingo?taskID=789014 >> > > I did see this error before, and I seem to recall that it was an mftrace > problem, but I don't know why. I'll try upgrading mftrace and see if > that fixes it. > > Quentin > I saw the new mftrace in rawhide, and rebuilt lilypond. I confirmed that the new mftrace was used, but the build still failed. . . http://koji.fedoraproject.org/koji/taskinfo?taskID=799837 -- novus ordo absurdum From berrange at redhat.com Tue Sep 2 13:16:45 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 2 Sep 2008 14:16:45 +0100 Subject: wtf ... Something strips installed binaries??? In-Reply-To: References: <20080902080150.GA483@amd.home.annexia.org> <544eb990809020205q4f0c7764ycfbbd5b2080c09fb@mail.gmail.com> Message-ID: <20080902131645.GK29748@redhat.com> On Tue, Sep 02, 2008 at 11:07:45AM -0200, Thomas M Steenholdt wrote: > Bill Crawford wrote: > >Thomas M Steenholdt wrote: > >>I wasn't even aware that prelinking actually changed the files. Isn't > >>this kind of dangerous from a system-integrity point-of-view. How can we > >>ever validate binaries if they are modified on purpose? > > > >With "prelink --verify" ? > > > > I can't see how that would actually verify that the binary has not been > modified by a rootkit or whatever? It is explained in the manpage for prelink -y --verify Verifies a prelinked binary or library. This option can be used only on a single binary or library. It first applies an --undo operation on the file, then prelinks just that file again and compares this with the original file. If both are identical, it prints the file after --undo opera- tion on standard output and exits with zero sta- tus. Otherwise it exits with error status. Thus if --verify operation returns zero exit status and its standard output is equal to the content of the binary or library before prelinking, you can be sure that nobody modified the binaries or libraries after prelinking. Similarly with mes- sage digests and checksums (unless you trigger the improbable case of modified file and original file having the same digest or checksum). > rpm -V should be able to detect this, > on the other hand, but how it works in conjunction with prelinking I > don't know... IIRC, rpm -V is prelink aware, and calls out to prelink --verify rather than doing a blind checksum compare. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From tmus at tmus.dk Tue Sep 2 13:37:26 2008 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 02 Sep 2008 11:37:26 -0200 Subject: wtf ... Something strips installed binaries??? In-Reply-To: <20080902131645.GK29748@redhat.com> References: <20080902080150.GA483@amd.home.annexia.org> <544eb990809020205q4f0c7764ycfbbd5b2080c09fb@mail.gmail.com> <20080902131645.GK29748@redhat.com> Message-ID: <48BD4196.4060400@tmus.dk> Daniel P. Berrange wrote: > On Tue, Sep 02, 2008 at 11:07:45AM -0200, Thomas M Steenholdt wrote: >> Bill Crawford wrote: >>> Thomas M Steenholdt wrote: >>>> I wasn't even aware that prelinking actually changed the files. Isn't >>>> this kind of dangerous from a system-integrity point-of-view. How can we >>>> ever validate binaries if they are modified on purpose? >>> With "prelink --verify" ? >>> >> I can't see how that would actually verify that the binary has not been >> modified by a rootkit or whatever? > > It is explained in the manpage for prelink > > -y --verify > Verifies a prelinked binary or library. This > option can be used only on a single binary or > library. It first applies an --undo operation on > the file, then prelinks just that file again and > compares this with the original file. If both are > identical, it prints the file after --undo opera- > tion on standard output and exits with zero sta- > tus. Otherwise it exits with error status. Thus > if --verify operation returns zero exit status > and its standard output is equal to the content > of the binary or library before prelinking, you > can be sure that nobody modified the binaries or > libraries after prelinking. Similarly with mes- > sage digests and checksums (unless you trigger > the improbable case of modified file and original > file having the same digest or checksum). > >> rpm -V should be able to detect this, >> on the other hand, but how it works in conjunction with prelinking I >> don't know... > > IIRC, rpm -V is prelink aware, and calls out to prelink --verify rather than > doing a blind checksum compare. > > Daniel Does rpm -V use this trick to return sane results? /Thomas From txtoth at gmail.com Tue Sep 2 13:42:49 2008 From: txtoth at gmail.com (Xavier Toth) Date: Tue, 2 Sep 2008 08:42:49 -0500 Subject: [PATCH] yum: make transaction results available to plugins In-Reply-To: <48BC3287.8090708@googlemail.com> References: <1220281212.8829.0.camel@rosebud> <48BC3287.8090708@googlemail.com> Message-ID: On Mon, Sep 1, 2008 at 1:20 PM, Tim Lauridsen wrote: > Xavier Toth wrote: >> >> I have a number of rpms that install SELinux policy modules during the >> post install and I want yum to exit if there is any problem. I've >> written a plugin with a posttrans method that examines the result and >> exits if there was any problem. If there is another way to do this I'd >> be happy to hear about it. >> > > def postresolve_hook(conduit): > txmbrs = conduit.getTsInfo().getMembers() > # Do your actions on txmbrs > > > This shoud give you the result of the transaction after depsolve. > > Tim > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > The post install script has not been run at this point so this does not address the issue I have. From fche at redhat.com Tue Sep 2 13:44:39 2008 From: fche at redhat.com (Frank Ch. Eigler) Date: Tue, 02 Sep 2008 09:44:39 -0400 Subject: wtf ... Something strips installed binaries??? In-Reply-To: <20080902095712.GB483@amd.home.annexia.org> (Richard W. M. Jones's message of "Tue, 2 Sep 2008 10:57:12 +0100") References: <20080902080150.GA483@amd.home.annexia.org> <20080902094855.GC29748@redhat.com> <20080902095712.GB483@amd.home.annexia.org> Message-ID: "Richard W.M. Jones" writes: > [...] > Really, cronjobs shouldn't be modifying files in /usr/bin. Save data > in /var/, or modify the ELF format to make it more efficient so it > doesn't need prelink. (Fully successful prelinking is a function of the system-wide set of shared libraries, not of a single executable, so it's not quite that easy.) But another concern re. prelink doing this stripping is ... how does it know that the debug data it is losing is in fact expendable? What if someone installed an RPM or a hand-made executable that was built with CFLAGS=-g and without RPM-split debuginfo? That information would be totally lost. What does stripping have to do with prelinking anyway? Is this just mission creep? - FChE From dcbw at redhat.com Tue Sep 2 14:01:55 2008 From: dcbw at redhat.com (Dan Williams) Date: Tue, 02 Sep 2008 10:01:55 -0400 Subject: NetworkManager-pptp In-Reply-To: <921dc0110809010249x501a1993r6ba4efc62c5a942@mail.gmail.com> References: <9497e9990808300831t150c6036ydf4c453f3c822d48@mail.gmail.com> <16de708d0808301502w5b435684r7b4cf268af1616f7@mail.gmail.com> <921dc0110809010249x501a1993r6ba4efc62c5a942@mail.gmail.com> Message-ID: <1220364115.3176.15.camel@borkbork.foobar.com> On Mon, 2008-09-01 at 17:49 +0800, Dan Holwerda wrote: > mine works fine on x86 - although selinux will stop it when in enforcing mode Yeah, we'll need to get updated policy for it. I just built it last thing on Friday and haven't issued the update because there were a few things (like this) still to clear up. Dan > On Sun, Aug 31, 2008 at 6:02 AM, Arthur Pemberton wrote: > > On Sat, Aug 30, 2008 at 10:31 AM, Mat Booth wrote: > >> I was pleased to see this package hanging out in Koji today. Thanks > >> Dan for packaging it, I've been looking forward to seeing this in > >> Fedora. > >> > >> I've installed the x86_64 package from Koji to try it out on my F9 > >> machine. Am I being too eager? :-) > >> > >> Anyway, I've configured up my VPN connection but I can't get it to > >> work. Whatever I try, I always get the following: > >> > >> Aug 30 16:05:40 sd NetworkManager: Starting VPN service > >> 'org.freedesktop.NetworkManager.pptp'... > >> Aug 30 16:05:40 sd NetworkManager: VPN service > >> 'org.freedesktop.NetworkManager.pptp' started > >> (org.freedesktop.NetworkManager.pptp), PID 6587 > >> Aug 30 16:05:40 sd NetworkManager: vpn_service_watch_cb(): VPN > >> service 'org.freedesktop.NetworkManager.pptp' exited with error: 1 > >> Aug 30 16:05:45 sd NetworkManager: VPN service > >> 'org.freedesktop.NetworkManager.pptp' did not start in time, > >> cancelling connections > >> > >> Currently, I connect to the VPN with this script (login details > >> censored, obviously): > >> > >> http://www.matbooth.co.uk/lwd/start-vpn > >> > >> Which works reasonably well. How can I make NetworkManager-pptp > >> connect using the settings I use in that script? What's the best way > >> to go about debugging this? > >> > >> Regards, > >> Mat > >> > > > > > > Many thanks. I will sure to try this on my dev box this weekend. > > > > Thanks Dan. > > > > > > -- > > Fedora 7 : sipping some of that moonshine > > ( www.pembo13.com ) > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > From dcbw at redhat.com Tue Sep 2 14:04:55 2008 From: dcbw at redhat.com (Dan Williams) Date: Tue, 02 Sep 2008 10:04:55 -0400 Subject: NetworkManager-pptp In-Reply-To: <9497e9990808300831t150c6036ydf4c453f3c822d48@mail.gmail.com> References: <9497e9990808300831t150c6036ydf4c453f3c822d48@mail.gmail.com> Message-ID: <1220364295.3176.19.camel@borkbork.foobar.com> On Sat, 2008-08-30 at 16:31 +0100, Mat Booth wrote: > I was pleased to see this package hanging out in Koji today. Thanks > Dan for packaging it, I've been looking forward to seeing this in > Fedora. > > I've installed the x86_64 package from Koji to try it out on my F9 > machine. Am I being too eager? :-) > > Anyway, I've configured up my VPN connection but I can't get it to > work. Whatever I try, I always get the following: > > Aug 30 16:05:40 sd NetworkManager: Starting VPN service > 'org.freedesktop.NetworkManager.pptp'... > Aug 30 16:05:40 sd NetworkManager: VPN service > 'org.freedesktop.NetworkManager.pptp' started > (org.freedesktop.NetworkManager.pptp), PID 6587 > Aug 30 16:05:40 sd NetworkManager: vpn_service_watch_cb(): VPN > service 'org.freedesktop.NetworkManager.pptp' exited with error: 1 Could be SELinux policy if you're running in enforcing mode. I haven't talked to dwalsh yet to get that done. You can check this by running: sudo /usr/libexec/nm-pptp-service and seeing what error it spits out. Dan > Aug 30 16:05:45 sd NetworkManager: VPN service > 'org.freedesktop.NetworkManager.pptp' did not start in time, > cancelling connections > > Currently, I connect to the VPN with this script (login details > censored, obviously): > > http://www.matbooth.co.uk/lwd/start-vpn > > Which works reasonably well. How can I make NetworkManager-pptp > connect using the settings I use in that script? What's the best way > to go about debugging this? > > Regards, > Mat > > -- > Mat Booth > www.matbooth.co.uk > From ingvar at linpro.no Tue Sep 2 14:09:12 2008 From: ingvar at linpro.no (Ingvar Hagelund) Date: Tue, 02 Sep 2008 16:09:12 +0200 Subject: Heads up: varnish goes from 1.1.2 to 2.0-beta1 Message-ID: <48BD4908.3020402@linpro.no> varnish is a high performance http accelerator. As the long expected varnish-2.0 is not too far away, I'm starting the upgrade race now, and beta1 will hit rawhide soon. Those who can't wait can get srpm and specfile from http://init.linpro.no/ingvar/varnish/ For those running 1.1.2 or earlier, mark that there are changes in the vcl syntax, see excerpt from README.redhat below. For more information about varnish, see http://www.varnish-cache.org/ Ingvar Upgrading from 1.x to 2.0 ========================= There are a few changes in the vcl language from varnish-1.x to 2.0. Because of varnish' dynamic vcl loading feature, there is no way to guarantee that the vcl file in use actually exists on disk. Thus, there is no way to securely automate this process, and one must do the changes by hand. In vcl, the word "insert" has been replaced by "deliver". In the vcl declaration of backends, where one earlier used "set backend", backend parts are now just prefixed with a dot, so the default localhost configuration will look like this: backend default { .host = "127.0.0.1"; .port = "80"; } From laurent.rineau__fedora at normalesup.org Tue Sep 2 14:23:30 2008 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Tue, 2 Sep 2008 16:23:30 +0200 Subject: wtf ... Something strips installed binaries??? In-Reply-To: <48BD4196.4060400@tmus.dk> References: <20080902080150.GA483@amd.home.annexia.org> <20080902131645.GK29748@redhat.com> <48BD4196.4060400@tmus.dk> Message-ID: <200809021623.30179@rineau.tsetse> On Tuesday 02 September 2008 15:37:26 Thomas M Steenholdt wrote: > Daniel P. Berrange wrote: > > IIRC, rpm -V is prelink aware, and calls out to prelink --verify rather > > than doing a blind checksum compare. > > > > Daniel > > Does rpm -V use this trick to return sane results? Well, Daniel just told you that in the message you quoted! -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From fedora at matbooth.co.uk Tue Sep 2 15:20:04 2008 From: fedora at matbooth.co.uk (Mat Booth) Date: Tue, 2 Sep 2008 15:20:04 +0000 Subject: NetworkManager-pptp In-Reply-To: <1220364295.3176.19.camel@borkbork.foobar.com> References: <9497e9990808300831t150c6036ydf4c453f3c822d48@mail.gmail.com> <1220364295.3176.19.camel@borkbork.foobar.com> Message-ID: <9497e9990809020820m67361762n7ed5db1bf7ad7946@mail.gmail.com> On Tue, Sep 2, 2008 at 2:04 PM, Dan Williams wrote: > On Sat, 2008-08-30 at 16:31 +0100, Mat Booth wrote: >> Anyway, I've configured up my VPN connection but I can't get it to >> work. Whatever I try, I always get the following: >> >> Aug 30 16:05:40 sd NetworkManager: Starting VPN service >> 'org.freedesktop.NetworkManager.pptp'... >> Aug 30 16:05:40 sd NetworkManager: VPN service >> 'org.freedesktop.NetworkManager.pptp' started >> (org.freedesktop.NetworkManager.pptp), PID 6587 >> Aug 30 16:05:40 sd NetworkManager: vpn_service_watch_cb(): VPN >> service 'org.freedesktop.NetworkManager.pptp' exited with error: 1 > > Could be SELinux policy if you're running in enforcing mode. I haven't > talked to dwalsh yet to get that done. You can check this by running: > > sudo /usr/libexec/nm-pptp-service > > and seeing what error it spits out. > No, I run with SELinux disabled because of work. It doesn't spit out any message at all if I run it like that. -- Mat Booth www.matbooth.co.uk From dcbw at redhat.com Tue Sep 2 15:26:55 2008 From: dcbw at redhat.com (Dan Williams) Date: Tue, 02 Sep 2008 11:26:55 -0400 Subject: NetworkManager-pptp In-Reply-To: <9497e9990809020820m67361762n7ed5db1bf7ad7946@mail.gmail.com> References: <9497e9990808300831t150c6036ydf4c453f3c822d48@mail.gmail.com> <1220364295.3176.19.camel@borkbork.foobar.com> <9497e9990809020820m67361762n7ed5db1bf7ad7946@mail.gmail.com> Message-ID: <1220369215.8041.15.camel@borkbork.foobar.com> On Tue, 2008-09-02 at 15:20 +0000, Mat Booth wrote: > On Tue, Sep 2, 2008 at 2:04 PM, Dan Williams wrote: > > On Sat, 2008-08-30 at 16:31 +0100, Mat Booth wrote: > >> Anyway, I've configured up my VPN connection but I can't get it to > >> work. Whatever I try, I always get the following: > >> > >> Aug 30 16:05:40 sd NetworkManager: Starting VPN service > >> 'org.freedesktop.NetworkManager.pptp'... > >> Aug 30 16:05:40 sd NetworkManager: VPN service > >> 'org.freedesktop.NetworkManager.pptp' started > >> (org.freedesktop.NetworkManager.pptp), PID 6587 > >> Aug 30 16:05:40 sd NetworkManager: vpn_service_watch_cb(): VPN > >> service 'org.freedesktop.NetworkManager.pptp' exited with error: 1 > > > > Could be SELinux policy if you're running in enforcing mode. I haven't > > talked to dwalsh yet to get that done. You can check this by running: > > > > sudo /usr/libexec/nm-pptp-service > > > > and seeing what error it spits out. > > > > No, I run with SELinux disabled because of work. It doesn't spit out > any message at all if I run it like that. Ok, how about if you run it like that, then try to connect your VPN connection via the GUI? Dan From ndbecker2 at gmail.com Tue Sep 2 17:08:47 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Tue, 02 Sep 2008 13:08:47 -0400 Subject: telive 2008 released (in time for f10?) Message-ID: tl 2008 is released. Will it be part of f10? From michel.sylvan at gmail.com Tue Sep 2 17:25:01 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Tue, 2 Sep 2008 13:25:01 -0400 Subject: NetworkManager-pptp In-Reply-To: <1220364295.3176.19.camel@borkbork.foobar.com> References: <9497e9990808300831t150c6036ydf4c453f3c822d48@mail.gmail.com> <1220364295.3176.19.camel@borkbork.foobar.com> Message-ID: On Tue, Sep 2, 2008 at 10:04 AM, Dan Williams wrote: > On Sat, 2008-08-30 at 16:31 +0100, Mat Booth wrote: >> I was pleased to see this package hanging out in Koji today. Thanks >> Dan for packaging it, I've been looking forward to seeing this in >> Fedora. >> >> I've installed the x86_64 package from Koji to try it out on my F9 >> machine. Am I being too eager? :-) >> >> Anyway, I've configured up my VPN connection but I can't get it to >> work. Whatever I try, I always get the following: >> >> Aug 30 16:05:40 sd NetworkManager: Starting VPN service >> 'org.freedesktop.NetworkManager.pptp'... >> Aug 30 16:05:40 sd NetworkManager: VPN service >> 'org.freedesktop.NetworkManager.pptp' started >> (org.freedesktop.NetworkManager.pptp), PID 6587 >> Aug 30 16:05:40 sd NetworkManager: vpn_service_watch_cb(): VPN >> service 'org.freedesktop.NetworkManager.pptp' exited with error: 1 > > Could be SELinux policy if you're running in enforcing mode. I haven't > talked to dwalsh yet to get that done. You can check this by running: > > sudo /usr/libexec/nm-pptp-service > > and seeing what error it spits out. > When I try it on my computer (SELinux enabled, targeted mode), there is no error from running nm-pptp-service directly. It does not return either. Running it through the GUI fails, though: "the service terminated abruptly" (or something to that effect). Didn't have time to write it down, and after it fails once apparently any attempt to reconnect silently does nothing. -- Michel Salim http://hircus.jaiku.com/ From jkeating at redhat.com Tue Sep 2 18:23:02 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 02 Sep 2008 11:23:02 -0700 Subject: rawhide report: 20080829 changes In-Reply-To: References: <20080829195754.07B211F8248@releng2.fedora.phx.redhat.com> <1220044676.9554.26.camel@luminos.localdomain> <20080831191730.GA7646@dhcp-lab-186.brq.redhat.com> <1220214626.29094.13.camel@luminos.localdomain> Message-ID: <1220379782.29094.21.camel@luminos.localdomain> On Mon, 2008-09-01 at 11:03 -0500, Jason L Tibbitts III wrote: > It's not as if the extra-arches hack is difficult to set up, so I'd > imagine that the threshold would be pretty low, but it's quite > possible that there's some overhead or disadvantage I'm not aware of. Basically the problem is that it's a buildsystem level hack, one that can be easily forgotten and one that isn't easily reproduced on a user's system (rpmbuild foo.src.rpm won't produce the same output). That's why I'd rather see it done at the rpm level so that we don't have to have buildsystem level hacks that get forgotten over time. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Tue Sep 2 18:46:33 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 02 Sep 2008 13:46:33 -0500 Subject: [PATCH] yum: make transaction results available to plugins In-Reply-To: References: Message-ID: <1220381193.4415.1.camel@localhost.localdomain> On Mon, 2008-09-01 at 09:25 -0500, Xavier Toth wrote: > @@ -459,6 +460,12 @@ > result.update(self.getNewRequires(name, flag, version)) > return result > > + def getTransactionResult(self): > + return self.transaction_result > + > + def setTransactionResult(self, result): > + self.transaction_result = result > + > class ConditionalTransactionData(TransactionData): > """A transaction data implementing conditional package addition""" > def __init__(self): Getters and setters? In Python? http://dirtsimple.org/2004/12/python-is-not-java.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin at scrye.com Tue Sep 2 19:10:38 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Tue, 2 Sep 2008 13:10:38 -0600 Subject: Xfce SIG meeting today! Message-ID: <20080902131038.6897c93d@ohm.scrye.com> Greetings. We would like to try and get together interested folks for a Xfce SIG meeting, later today in a few hours at 21:00 UTC in the #fedora-meeting channel. Sorry for the late notice. We will mostly be going over some items for F10, and trying to finalize the Xfce spin for F10. All interested parties welcome! Thanks! kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From txtoth at gmail.com Tue Sep 2 19:20:11 2008 From: txtoth at gmail.com (Xavier Toth) Date: Tue, 2 Sep 2008 14:20:11 -0500 Subject: [PATCH] yum: make transaction results available to plugins In-Reply-To: <1220381193.4415.1.camel@localhost.localdomain> References: <1220381193.4415.1.camel@localhost.localdomain> Message-ID: 2008/9/2 Callum Lerwick : > On Mon, 2008-09-01 at 09:25 -0500, Xavier Toth wrote: >> @@ -459,6 +460,12 @@ >> result.update(self.getNewRequires(name, flag, version)) >> return result >> >> + def getTransactionResult(self): >> + return self.transaction_result >> + >> + def setTransactionResult(self, result): >> + self.transaction_result = result >> + >> class ConditionalTransactionData(TransactionData): >> """A transaction data implementing conditional package addition""" >> def __init__(self): > > Getters and setters? In Python? > > http://dirtsimple.org/2004/12/python-is-not-java.html > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > If the maintainer doesn't like the patch code they are welcome to change it all they want as long as there is a way to get the result of the transaction in a plugin that's all I care about. From bpepple at fedoraproject.org Tue Sep 2 19:21:09 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 02 Sep 2008 15:21:09 -0400 Subject: Plan for tomorrows (20080903) FESCO meeting Message-ID: <1220383269.6218.2.camel@truman> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Wednesday at 18:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCo-Meeting -- http://www.redhat.com/archives/fedora-devel-list/2008-August/msg00403.html - kanarip /topic FESCo-Meeting -- Setting up FESCo trac for issues that need FESCo's attention - nirik /topic FESCO-Meeting -- Features -- https://fedoraproject.org/wiki/Features/EvdevInputDriver /topic FESCO-Meeting -- Features -- https://fedoraproject.org/wiki/Features/EchoIconTheme /topic FESCO-Meeting -- Features -- https://fedoraproject.org/wiki/Features/EFI /topic FESCO-Meeting -- Features -- https://fedoraproject.org/wiki/Features/LXDE /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule. You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From loganjerry at gmail.com Tue Sep 2 19:26:13 2008 From: loganjerry at gmail.com (Jerry James) Date: Tue, 2 Sep 2008 13:26:13 -0600 Subject: Fedora rawhide rebuild in mock status 2008-08-28 In-Reply-To: <20080828104611.A16272@humbolt.us.dell.com> References: <20080828104611.A16272@humbolt.us.dell.com> Message-ID: <870180fe0809021226hebfa8b8r61074e7174b1004c@mail.gmail.com> On Thu, Aug 28, 2008 at 9:46 AM, Matt Domsch wrote: > idw-gpl-1.5.0-5.fc10 (build/make) jjames > jcip-annotations-0-20060626.4.fc10 (build/make) jjames Both of these are Java packages. Both fail in the same way. When javac is invoked, it says: java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory That library is at /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/jli/libjli.so on my x86_64 F9 machine, and is owned by the java-1.6.0-openjdk-1.6.0.0-0.16.b09.fc9.x86_64 package. Has the way in which I am supposed to express BuildRequires for Java packages changed? -- Jerry James http://loganjerry.googlepages.com/ From bkearney at redhat.com Tue Sep 2 19:24:54 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Tue, 02 Sep 2008 15:24:54 -0400 Subject: Plan for tomorrows (20080903) FESCO meeting In-Reply-To: <1220383269.6218.2.camel@truman> References: <1220383269.6218.2.camel@truman> Message-ID: <48BD9306.7070704@redhat.com> Brian Pepple wrote: > Hi, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Wednesday at 18:00 > UTC in #fedora-meeting on irc.freenode.org: > > /topic FESCo-Meeting -- > http://www.redhat.com/archives/fedora-devel-list/2008-August/msg00403.html - kanarip > > /topic FESCo-Meeting -- Setting up FESCo trac for issues that need > FESCo's attention - nirik > > /topic FESCO-Meeting -- Features -- > https://fedoraproject.org/wiki/Features/EvdevInputDriver > > /topic FESCO-Meeting -- Features -- > https://fedoraproject.org/wiki/Features/EchoIconTheme > > /topic FESCO-Meeting -- Features -- > https://fedoraproject.org/wiki/Features/EFI > > /topic FESCO-Meeting -- Features -- > https://fedoraproject.org/wiki/Features/LXDE > > /topic FESCo meeting -- Free discussion around Fedora > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule. You can also propose topics > in the meeting while it is in the "Free discussion around Fedora" phase. > > Later, > /B > Can we pleease add Trademark Approval for Fedora-AOS (aka, Does Fedora require SELinux?) Thank you! -- bk From tmus at tmus.dk Tue Sep 2 19:27:01 2008 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 02 Sep 2008 17:27:01 -0200 Subject: wtf ... Something strips installed binaries??? In-Reply-To: <200809021623.30179@rineau.tsetse> References: <20080902080150.GA483@amd.home.annexia.org> <20080902131645.GK29748@redhat.com> <48BD4196.4060400@tmus.dk> <200809021623.30179@rineau.tsetse> Message-ID: Laurent Rineau wrote: > On Tuesday 02 September 2008 15:37:26 Thomas M Steenholdt wrote: >> Daniel P. Berrange wrote: >>> IIRC, rpm -V is prelink aware, and calls out to prelink --verify rather >>> than doing a blind checksum compare. >>> >>> Daniel >> Does rpm -V use this trick to return sane results? > > Well, Daniel just told you that in the message you quoted! > Duh!!! My deepest apologies - I read that in a totally different way ;-) /Thomas From darrellpf at gmail.com Tue Sep 2 19:37:30 2008 From: darrellpf at gmail.com (darrell pfeifer) Date: Tue, 2 Sep 2008 12:37:30 -0700 Subject: Fedora rawhide rebuild in mock status 2008-08-28 In-Reply-To: <870180fe0809021226hebfa8b8r61074e7174b1004c@mail.gmail.com> References: <20080828104611.A16272@humbolt.us.dell.com> <870180fe0809021226hebfa8b8r61074e7174b1004c@mail.gmail.com> Message-ID: On Tue, Sep 2, 2008 at 12:26, Jerry James wrote: > On Thu, Aug 28, 2008 at 9:46 AM, Matt Domsch wrote: > > idw-gpl-1.5.0-5.fc10 (build/make) jjames > > > jcip-annotations-0-20060626.4.fc10 (build/make) jjames > > Both of these are Java packages. Both fail in the same way. When > javac is invoked, it says: > > java: error while loading shared libraries: libjli.so: cannot open > shared object file: No such file or directory > > That library is at > /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/jli/libjli.so > on my x86_64 F9 machine, and is owned by the > java-1.6.0-openjdk-1.6.0.0-0.16.b09.fc9.x86_64 package. Has the way > in which I am supposed to express BuildRequires for Java packages > changed? > I was getting that error in rawhide for the last several weeks when running the (sun) java command at the command line, on a 32 bit machine. Using the full path to the binary worked. With yesterday's rawhide update the problem has gone away. darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan at jonmasters.org Tue Sep 2 19:40:54 2008 From: jonathan at jonmasters.org (Jon Masters) Date: Tue, 02 Sep 2008 15:40:54 -0400 Subject: wtf ... Something strips installed binaries??? In-Reply-To: References: <20080902080150.GA483@amd.home.annexia.org> <20080902094855.GC29748@redhat.com> <20080902095712.GB483@amd.home.annexia.org> Message-ID: <1220384454.12421.19.camel@perihelion> On Tue, 2008-09-02 at 09:44 -0400, Frank Ch. Eigler wrote: > What does stripping have to do with prelinking anyway? Is this just > mission creep? It really does seem like it. But that's hardly too unusual :) Jon. From jakub at redhat.com Tue Sep 2 19:46:56 2008 From: jakub at redhat.com (Jakub Jelinek) Date: Tue, 2 Sep 2008 15:46:56 -0400 Subject: wtf ... Something strips installed binaries??? In-Reply-To: References: <20080902080150.GA483@amd.home.annexia.org> <20080902094855.GC29748@redhat.com> <20080902095712.GB483@amd.home.annexia.org> Message-ID: <20080902194656.GC32376@hs20-bc2-1.build.redhat.com> On Tue, Sep 02, 2008 at 09:44:39AM -0400, Frank Ch. Eigler wrote: > "Richard W.M. Jones" writes: > > [...] > > Really, cronjobs shouldn't be modifying files in /usr/bin. Save data > > in /var/, or modify the ELF format to make it more efficient so it > > doesn't need prelink. > > (Fully successful prelinking is a function of the system-wide set of > shared libraries, not of a single executable, so it's not quite that > easy.) > > But another concern re. prelink doing this stripping is ... how does > it know that the debug data it is losing is in fact expendable? What > if someone installed an RPM or a hand-made executable that was built > with CFLAGS=-g and without RPM-split debuginfo? That information > would be totally lost. Prelinking doesn't do stripping, it rewrites even the non-alloced sections like debugging sections and if it doesn't succeed rewriting them, it doesn't touch the binary (or library). Likely the binary has just some data appended to it and the authors haven't bothered to put it into a proper ELF non-allocated section instead, obviously both stripping and prelinking won't preserve randomly inserted data somewhere outside of the ELF sections. Both strip and prelink expect ELF objects, not some ad-hoc ELF plus something format. Jakub From loganjerry at gmail.com Tue Sep 2 20:02:37 2008 From: loganjerry at gmail.com (Jerry James) Date: Tue, 2 Sep 2008 14:02:37 -0600 Subject: Fedora rawhide rebuild in mock status 2008-08-28 In-Reply-To: References: <20080828104611.A16272@humbolt.us.dell.com> <870180fe0809021226hebfa8b8r61074e7174b1004c@mail.gmail.com> Message-ID: <870180fe0809021302k477fc4b1wbfd1151649c32558@mail.gmail.com> 2008/9/2 darrell pfeifer : > I was getting that error in rawhide for the last several weeks when running > the (sun) java command at the command line, on a 32 bit machine. > > Using the full path to the binary worked. > > With yesterday's rawhide update the problem has gone away. Thanks, Darrell. Then I'll do nothing and see if those packages disappear from Matt's report. -- Jerry James http://loganjerry.googlepages.com/ From joe at nall.com Tue Sep 2 19:49:19 2008 From: joe at nall.com (Joe Nall) Date: Tue, 2 Sep 2008 14:49:19 -0500 Subject: wtf ... Something strips installed binaries??? In-Reply-To: <1220384454.12421.19.camel@perihelion> References: <20080902080150.GA483@amd.home.annexia.org> <20080902094855.GC29748@redhat.com> <20080902095712.GB483@amd.home.annexia.org> <1220384454.12421.19.camel@perihelion> Message-ID: <2EC98CFE-8269-40EC-80DF-F5D8667FFB0F@nall.com> On Sep 2, 2008, at 2:40 PM, Jon Masters wrote: > On Tue, 2008-09-02 at 09:44 -0400, Frank Ch. Eigler wrote: > >> What does stripping have to do with prelinking anyway? Is this just >> mission creep? > > It really does seem like it. But that's hardly too unusual :) It appears to be removing file system capabilities too: https://bugzilla.redhat.com/show_bug.cgi?id=456105 joe From singularitaet at gmx.net Tue Sep 2 20:44:15 2008 From: singularitaet at gmx.net (Stefan Grosse) Date: Tue, 2 Sep 2008 22:44:15 +0200 Subject: Schedule for F9 updates? Message-ID: <20080902224415.7a597dbb@earth> Hi, I don't want to be pushy but is there any approximate time when the updates for fedora 9 are being resumed (with the new key)? Stefan From rjones at redhat.com Tue Sep 2 20:44:36 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 2 Sep 2008 21:44:36 +0100 Subject: wtf ... Something strips installed binaries??? In-Reply-To: <20080902194656.GC32376@hs20-bc2-1.build.redhat.com> References: <20080902080150.GA483@amd.home.annexia.org> <20080902094855.GC29748@redhat.com> <20080902095712.GB483@amd.home.annexia.org> <20080902194656.GC32376@hs20-bc2-1.build.redhat.com> Message-ID: <20080902204436.GA12289@amd.home.annexia.org> On Tue, Sep 02, 2008 at 03:46:56PM -0400, Jakub Jelinek wrote: > Likely the binary has just some data > appended to it and the authors haven't bothered to put it into a proper > ELF non-allocated section instead, obviously both stripping and prelinking > won't preserve randomly inserted data somewhere outside of the ELF sections. > Both strip and prelink expect ELF objects, not some ad-hoc ELF plus > something format. NekoVM which I'm packaging at the moment[1][2] does this with the Neko bytecode. I looked at the ELF format and it's actually way more difficult than I imagined to work out if a file has 'stuff' appended to it. In fact I don't think it's possible to distinguish this case from normal spare bytes at the end. So instead I'll raise this as a bug with NekoVM and see if they can just use a normal note section. (Probably not though, because they're mostly Windows programmers). Rich. [1] http://www.nekovm.org/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=460779 -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From wtogami at redhat.com Tue Sep 2 20:49:25 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 02 Sep 2008 16:49:25 -0400 Subject: Help Needed: Figure out F9 Updates PackageKit deps Message-ID: <48BDA6D5.1070504@redhat.com> Hi folks, Here is an easy task that someone could do to help us get new Fedora Updates flowing. http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html To aid in transition to the new key, Step 3 has the oldrepo of F9 Updates cleaned of all packages except tiny few to enable transition to the new key. The old F9 Updates repo is to contain the transitional fedora-release, and the current stable version of PackageKit, both signed by the old key and all other packages removed. The goal here is for any F9 pre-newkey install or Live install to be able to automatically upgrade into the new PackageKit. This is because the original PackageKit shipped in F9 was unable to ask the user if they want to import a new GPG key. Could someone figure out what is the minimum set of Fedora 9 packages needed to keep in the repo to allow an upgrade from F9 original release? Warren Togami wtogami at redhat.com From bruno at wolff.to Tue Sep 2 21:16:19 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 2 Sep 2008 16:16:19 -0500 Subject: Schedule for F9 updates? In-Reply-To: <20080902224415.7a597dbb@earth> References: <20080902224415.7a597dbb@earth> Message-ID: <20080902211619.GA23323@wolff.to> On Tue, Sep 02, 2008 at 22:44:15 +0200, Stefan Grosse wrote: > Hi, > > I don't want to be pushy but is there any approximate time when the updates for fedora 9 are being resumed (with the new key)? Based on teh estimae of several days late last week I would expect anytime now. If you are worried about something in particular, you can look at bodhi to see pending updates and updates-testing and get rpms from koji if there is something you want right now. If you have an FAS account you could even script something to do all of, say, the pending rpms requested for stable. It shouldn't be worth the trouble to do that, but it might be a fun exercise. From opensource at till.name Tue Sep 2 21:22:02 2008 From: opensource at till.name (Till Maas) Date: Tue, 02 Sep 2008 23:22:02 +0200 Subject: Schedule for F9 updates? In-Reply-To: <20080902211619.GA23323@wolff.to> References: <20080902224415.7a597dbb@earth> <20080902211619.GA23323@wolff.to> Message-ID: <200809022322.17803.opensource@till.name> On Tue September 2 2008, Bruno Wolff III wrote: > If you have an FAS account you could even script something to do all of, > say, the pending rpms requested for stable. It shouldn't be worth the > trouble to do that, but it might be a fun exercise. Afaik the FAS account is also needed to download the rpms via SSL from Koji because one needs a client SSL certificate. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Tue Sep 2 21:25:16 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 02 Sep 2008 14:25:16 -0700 Subject: Schedule for F9 updates? In-Reply-To: <200809022322.17803.opensource@till.name> References: <20080902224415.7a597dbb@earth> <20080902211619.GA23323@wolff.to> <200809022322.17803.opensource@till.name> Message-ID: <1220390716.30380.10.camel@luminos.localdomain> On Tue, 2008-09-02 at 23:22 +0200, Till Maas wrote: > > Afaik the FAS account is also needed to download the rpms via SSL from Koji > because one needs a client SSL certificate. I thought download-build was an anonymous action. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bruno at wolff.to Tue Sep 2 21:49:23 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 2 Sep 2008 16:49:23 -0500 Subject: Schedule for F9 updates? In-Reply-To: <1220390716.30380.10.camel@luminos.localdomain> References: <20080902224415.7a597dbb@earth> <20080902211619.GA23323@wolff.to> <200809022322.17803.opensource@till.name> <1220390716.30380.10.camel@luminos.localdomain> Message-ID: <20080902214923.GA7798@wolff.to> On Tue, Sep 02, 2008 at 14:25:16 -0700, Jesse Keating wrote: > On Tue, 2008-09-02 at 23:22 +0200, Till Maas wrote: > > > > Afaik the FAS account is also needed to download the rpms via SSL from Koji > > because one needs a client SSL certificate. > > I thought download-build was an anonymous action. I needed certs (two from fedora and mine) to get the bodhi client to work. I used this to grab a list of stable updates last week. This seemed easier than screen scraping html, which would have also worked. I didn't bother with ssl when grabbing them from koji. Lacking repo information makes it hard to totally automate. There were some kdeedu updates for which requirements hadn't had a requested push to stable. There were also some updates that had new dependencies that I didn't already have installed. From bruno at wolff.to Tue Sep 2 21:52:26 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 2 Sep 2008 16:52:26 -0500 Subject: Help Needed: Figure out F9 Updates PackageKit deps In-Reply-To: <48BDA6D5.1070504@redhat.com> References: <48BDA6D5.1070504@redhat.com> Message-ID: <20080902215226.GB7798@wolff.to> On Tue, Sep 02, 2008 at 16:49:25 -0400, Warren Togami wrote: > http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html > To aid in transition to the new key, Step 3 has the oldrepo of F9 > Updates cleaned of all packages except tiny few to enable transition to > the new key. The old F9 Updates repo is to contain the transitional > fedora-release, and the current stable version of PackageKit, both > signed by the old key and all other packages removed. > Could someone figure out what is the minimum set of Fedora 9 packages > needed to keep in the repo to allow an upgrade from F9 original release? If you are assuming that they already have PackageKit installed (and hence already have the dependencies installed), wouldn't you just need to include the new PackageKit (assuming there are no new dependencies) and the new Fedora-Release packages in the repo? From jkeating at redhat.com Tue Sep 2 21:52:09 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 02 Sep 2008 14:52:09 -0700 Subject: Fedora 10 Beta Freeze coming soon In-Reply-To: <1218474175.3398.46.camel@localhost.localdomain> References: <1218474175.3398.46.camel@localhost.localdomain> Message-ID: <1220392329.30380.14.camel@luminos.localdomain> On Mon, 2008-08-11 at 13:02 -0400, Jesse Keating wrote: > The Fedora 10 Beta freeze is scheduled for the 19th of Aug, one week and > one day away. I know it hasn't been very long since the Alpha release, > but that's how we roll here in the land of 6 month release cycles. > > Beta freeze also marks the Feature freeze, so it is very important that > you get your features into working, testable shape by then, or be > prepared to try your feature again for Fedora 11. > > We'd like to treat rawhide as a slushy freeze at this point, we'll be > doing full composes against rawhide to test for various things and be > ahead of the curve come actual freeze time, so we'd like you to not land > any really dangerous changes without extensive testing first, and > notification to the Fedora lists about your scary change. If we all > work together we can get through the beta freeze period quickly and be > on to the bugfixing mode after beta releases. > > http://fedoraproject.org/wiki/Releases/10/Schedule is the current > schedule, although releng/Fesco/Board has the ability to change the > schedule as needed. This week's meetings of the various boards, sigs, > groups, etc.. should focus on Beta readiness. It would be good to take > a moment to see what state your area of interest is in, and how likely > it would be that said area of interest will be in a "testable" shape by > the Beta freeze. If more (reasonable) time is needed, now is the time > to let the project know so that we can effectively manage the remainder > of our release schedule. > > Thanks for all your hard work in making Fedora 10 great! > Well, it's been an interesting couple of weeks to say the least. We moved our freeze date to reflect the situation. The new freeze date is Sept. 9, which is in 7 days. This is a friendly reminder that the freeze is coming up, and coming up quickly. I realize that rawhide has been less than great lately, and we're working quite hard to fix the issues. The installer images from the 30th may be of use in getting rawhide installed and then updating to what is in the public repos. See http://kojipkgs.fedoraproject.org/mash/rawhide-20080830/development/ (please only grab the installer images from there, not the entire tree) -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From opensource at till.name Tue Sep 2 22:00:21 2008 From: opensource at till.name (Till Maas) Date: Wed, 03 Sep 2008 00:00:21 +0200 Subject: Schedule for F9 updates? In-Reply-To: <1220390716.30380.10.camel@luminos.localdomain> References: <20080902224415.7a597dbb@earth> <200809022322.17803.opensource@till.name> <1220390716.30380.10.camel@luminos.localdomain> Message-ID: <200809030000.27162.opensource@till.name> On Tue September 2 2008, Jesse Keating wrote: > On Tue, 2008-09-02 at 23:22 +0200, Till Maas wrote: > > Afaik the FAS account is also needed to download the rpms via SSL from > > Koji because one needs a client SSL certificate. > > I thought download-build was an anonymous action. This does not work for me: wget --no-check-certificate "https://koji.fedoraproject.org/koji/getfile?taskID=800631&name=xorg-x11-server-Xdmx-1.4.99.906-10.fc10.jx.i386.rpm" But this does: wget --ca-certificate=fedora-server-ca.cert --certificate .fedora.cert --private-key .fedora.cert "https://koji.fedoraproject.org/koji/getfile?taskID=800631&name=xorg-x11-server-Xdmx-1.4.99.906-10.fc10.jx.i386.rpm" Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From wtogami at redhat.com Tue Sep 2 22:03:26 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 02 Sep 2008 18:03:26 -0400 Subject: Help Needed: Figure out F9 Updates PackageKit deps In-Reply-To: <20080902215226.GB7798@wolff.to> References: <48BDA6D5.1070504@redhat.com> <20080902215226.GB7798@wolff.to> Message-ID: <48BDB82E.6030705@redhat.com> Bruno Wolff III wrote: > On Tue, Sep 02, 2008 at 16:49:25 -0400, > Warren Togami wrote: >> http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html >> To aid in transition to the new key, Step 3 has the oldrepo of F9 >> Updates cleaned of all packages except tiny few to enable transition to >> the new key. The old F9 Updates repo is to contain the transitional >> fedora-release, and the current stable version of PackageKit, both >> signed by the old key and all other packages removed. > >> Could someone figure out what is the minimum set of Fedora 9 packages >> needed to keep in the repo to allow an upgrade from F9 original release? > > If you are assuming that they already have PackageKit installed (and hence > already have the dependencies installed), wouldn't you just need to include > the new PackageKit (assuming there are no new dependencies) and the new > Fedora-Release packages in the repo? It is possible, but I want someone to confirm and actually test this. Like install a fresh F9, and upgrade to a repo containing only the new PK. Warren From rc040203 at freenet.de Tue Sep 2 22:04:18 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 03 Sep 2008 00:04:18 +0200 Subject: Fedora 10 Beta Freeze coming soon In-Reply-To: <1220392329.30380.14.camel@luminos.localdomain> References: <1218474175.3398.46.camel@localhost.localdomain> <1220392329.30380.14.camel@luminos.localdomain> Message-ID: <1220393058.2795.554.camel@beck.corsepiu.local> On Tue, 2008-09-02 at 14:52 -0700, Jesse Keating wrote: > On Mon, 2008-08-11 at 13:02 -0400, Jesse Keating wrote: > > The Fedora 10 Beta freeze is scheduled for the 19th of Aug, one week and > > one day away. I know it hasn't been very long since the Alpha release, > > but that's how we roll here in the land of 6 month release cycles. > > > > Beta freeze also marks the Feature freeze, so it is very important that > > you get your features into working, testable shape by then, or be > > prepared to try your feature again for Fedora 11. > > > > We'd like to treat rawhide as a slushy freeze at this point, we'll be > > doing full composes against rawhide to test for various things and be > > ahead of the curve come actual freeze time, so we'd like you to not land > > any really dangerous changes without extensive testing first, and > > notification to the Fedora lists about your scary change. If we all > > work together we can get through the beta freeze period quickly and be > > on to the bugfixing mode after beta releases. > > > > http://fedoraproject.org/wiki/Releases/10/Schedule is the current > > schedule, although releng/Fesco/Board has the ability to change the > > schedule as needed. This week's meetings of the various boards, sigs, > > groups, etc.. should focus on Beta readiness. It would be good to take > > a moment to see what state your area of interest is in, and how likely > > it would be that said area of interest will be in a "testable" shape by > > the Beta freeze. If more (reasonable) time is needed, now is the time > > to let the project know so that we can effectively manage the remainder > > of our release schedule. > > > > Thanks for all your hard work in making Fedora 10 great! > > > > Well, it's been an interesting couple of weeks to say the least. > > We moved our freeze date to reflect the situation. The new freeze date > is Sept. 9, which is in 7 days. Provided FC8 and FC9 have been in deep freeze for 3-4 weeks and are still deep freeze, I would recommend to reconsider this decision above. Postponing F10 Beta Freeze by the same amount of time FC8 and FC9 don't receive updates, would seems more than appropriate to me. Ralf From ville.skytta at iki.fi Tue Sep 2 22:05:21 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Wed, 3 Sep 2008 01:05:21 +0300 Subject: Fedora rawhide rebuild in mock status 2008-08-28 In-Reply-To: <870180fe0809021302k477fc4b1wbfd1151649c32558@mail.gmail.com> References: <20080828104611.A16272@humbolt.us.dell.com> <870180fe0809021302k477fc4b1wbfd1151649c32558@mail.gmail.com> Message-ID: <200809030105.22111.ville.skytta@iki.fi> On Tuesday 02 September 2008, Jerry James wrote: > 2008/9/2 darrell pfeifer : > > I was getting that error in rawhide for the last several weeks when > > running the (sun) java command at the command line, on a 32 bit machine. > > > > Using the full path to the binary worked. > > > > With yesterday's rawhide update the problem has gone away. > > Thanks, Darrell. Then I'll do nothing and see if those packages > disappear from Matt's report. Some possibly related things Java packagers should be aware of, I ran into several issues earlier this week when rebuilding javasqlite in devel: javac->ecj symlinking may cause use of class libraries from wrong java: https://bugzilla.redhat.com/460761 Workaround: set up $PATH so that the pathless "java" invoked by /usr/bin/ecj corresponds to the "javac" you intended to run. I suppose generally this is a problem currently only with builds done with java-1.5.0-gcj's javac (which may end up using java-1.6.0-openjdk's class libs), and most packages probably don't have any problems with this. yum does something weird with "Requires: java-devel" on x86_64, resulting in the above issue being triggered pretty easily as well as possibly some other nasty arch mismatch issues: https://bugzilla.redhat.com/460783 Workaround: not sure; for javasqlite it went away when I added some a couple of java-devel build dependencies with explicit versions (not because of this - it was needed anyway for what I wanted to accomplish). I don't think these are actually anything new in Rawhide only, I see them in F-9 as well. From jkeating at redhat.com Tue Sep 2 22:06:27 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 02 Sep 2008 15:06:27 -0700 Subject: Schedule for F9 updates? In-Reply-To: <200809030000.27162.opensource@till.name> References: <20080902224415.7a597dbb@earth> <200809022322.17803.opensource@till.name> <1220390716.30380.10.camel@luminos.localdomain> <200809030000.27162.opensource@till.name> Message-ID: <1220393187.30380.18.camel@luminos.localdomain> On Wed, 2008-09-03 at 00:00 +0200, Till Maas wrote: > > > Afaik the FAS account is also needed to download the rpms via SSL > from > > > Koji because one needs a client SSL certificate. > > > > I thought download-build was an anonymous action. > > This does not work for me: > wget --no-check-certificate We're talking about two different things. You're using wget directly, whereas I'm talking about using download-build via koji. $ koji download-build --help Usage: koji download-build [options] (Specify the --help global option for a list of other help options) Options: -h, --help show this help message and exit --arch=ARCH Only download packages for this arch (may be used multiple times) --latestfrom=LATESTFROM Download the latest build from this tag --debuginfo Also download -debuginfo rpms --key=KEY Download rpms signed with the given key -q, --quiet Do not display progress meter -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From fedora at matbooth.co.uk Tue Sep 2 22:20:19 2008 From: fedora at matbooth.co.uk (Mat Booth) Date: Tue, 2 Sep 2008 23:20:19 +0100 Subject: NetworkManager-pptp In-Reply-To: <1220369215.8041.15.camel@borkbork.foobar.com> References: <9497e9990808300831t150c6036ydf4c453f3c822d48@mail.gmail.com> <1220364295.3176.19.camel@borkbork.foobar.com> <9497e9990809020820m67361762n7ed5db1bf7ad7946@mail.gmail.com> <1220369215.8041.15.camel@borkbork.foobar.com> Message-ID: <9497e9990809021520q6458cd39u3ff17f0144c8c5b6@mail.gmail.com> On Tue, Sep 2, 2008 at 4:26 PM, Dan Williams wrote: > On Tue, 2008-09-02 at 15:20 +0000, Mat Booth wrote: >> No, I run with SELinux disabled because of work. It doesn't spit out >> any message at all if I run it like that. > > Ok, how about if you run it like that, then try to connect your VPN > connection via the GUI? > > Dan > > After some experimenting (and by experimenting I mean mostly just dicking about with it :-), I may have made progress as now I'm getting different output in /var/log/messages to what I reported originally. (As an aside, I've been having trouble getting settings to "stick" when I change the VPN config. Often, after I hit ok and close and reopen the nm-connection-editor, the settings have gone back to the way they were before. I can't figure out a pattern to it yet, but I obviously can't be confident that the settings I've chosen is the config that's used. Could I be choosing some mutually exclusive options that are being silently rejected? Where are my settings stored on disk so I can verify them?) Here's what I'm seeing now (this seems to include the stdout from /usr/libexec/nm-pptp-service): Sep 2 23:03:45 sd NetworkManager: Starting VPN service 'org.freedesktop.NetworkManager.pptp'... Sep 2 23:03:45 sd NetworkManager: VPN service 'org.freedesktop.NetworkManager.pptp' started (org.freedesktop.NetworkManager.pptp), PID 11201 Sep 2 23:03:45 sd NetworkManager: VPN service 'org.freedesktop.NetworkManager.pptp' just appeared, activating connections Sep 2 23:03:45 sd NetworkManager: VPN plugin state changed: 3 Sep 2 23:03:45 sd NetworkManager: VPN connection 'Servelec' (Connect) reply received. Sep 2 23:03:45 sd pppd[11202]: Plugin /usr/lib64/pppd/2.4.4/nm-pptp-pppd-plugin.so loaded. Sep 2 23:03:45 sd pppd[11202]: pppd 2.4.4 started by root, uid 0 Sep 2 23:03:45 sd pppd[11202]: Using interface ppp0 Sep 2 23:03:45 sd pppd[11202]: Connect: ppp0 <--> /dev/pts/3 Sep 2 23:03:45 sd pptp[11203]: nm-pptp-service-11201 log[main:pptp.c:276]: The synchronous pptp option is NOT activated Sep 2 23:03:45 sd pptp[11210]: nm-pptp-service-11201 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request' Sep 2 23:03:45 sd pptp[11210]: nm-pptp-service-11201 log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply Sep 2 23:03:45 sd pptp[11210]: nm-pptp-service-11201 log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established. Sep 2 23:03:46 sd pptp[11210]: nm-pptp-service-11201 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request' Sep 2 23:03:46 sd pptp[11210]: nm-pptp-service-11201 log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply. Sep 2 23:03:46 sd pptp[11210]: nm-pptp-service-11201 log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 2560). Sep 2 23:03:46 sd pptp[11210]: nm-pptp-service-11201 log[ctrlp_disp:pptp_ctrl.c:949]: PPTP_SET_LINK_INFO received from peer_callid 0 Sep 2 23:03:46 sd pptp[11210]: nm-pptp-service-11201 log[ctrlp_disp:pptp_ctrl.c:952]: send_accm is 00000000, recv_accm is FFFFFFFF Sep 2 23:03:46 sd pptp[11210]: nm-pptp-service-11201 warn[ctrlp_disp:pptp_ctrl.c:955]: Non-zero Async Control Character Maps are not supported! Sep 2 23:03:46 sd pppd[11202]: LCP terminated by peer (^HM-WoM-^H^@ VPN plugin state changed: 6 Sep 2 23:03:49 sd NetworkManager: connection_state_changed(): Could not process the request because no VPN connection was active. Thanks for your help. Mat -- Mat Booth www.matbooth.co.uk From paul at all-the-johnsons.co.uk Tue Sep 2 22:25:46 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 02 Sep 2008 23:25:46 +0100 Subject: xmms heads up Message-ID: <1220394346.7539.3.camel@PB3.Linux> Hi, I've just built xmms-1.2.11-20071117cvs for rawhide. It should hit whenever there is a rawhide push (god knows when that will be ;-p). If you're using the livna mp3 plugin, you will not be able to update directly as that plugin required the old xmms-lib; if you download xmms from ftp though, you can install it with --no-deps and it works fine. I hope whoever looks after that for livna will be quick on the rebuild for it. Quite a few of the old patches have gone as they've made it to the 1.2.11 branch already. The only one which concerns me is the alsa-backport patch which looks like the functionality has been included in the new source. Any problems, bugzilla! TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From tmus at tmus.dk Tue Sep 2 22:27:19 2008 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 02 Sep 2008 20:27:19 -0200 Subject: Help Needed: Figure out F9 Updates PackageKit deps In-Reply-To: <48BDA6D5.1070504@redhat.com> References: <48BDA6D5.1070504@redhat.com> Message-ID: Warren Togami wrote: > Hi folks, > > Here is an easy task that someone could do to help us get new Fedora > Updates flowing. > > http://lists.fedoraproject.org/pipermail/rel-eng/2008-August/001627.html > To aid in transition to the new key, Step 3 has the oldrepo of F9 > Updates cleaned of all packages except tiny few to enable transition to > the new key. The old F9 Updates repo is to contain the transitional > fedora-release, and the current stable version of PackageKit, both > signed by the old key and all other packages removed. > > The goal here is for any F9 pre-newkey install or Live install to be > able to automatically upgrade into the new PackageKit. This is because > the original PackageKit shipped in F9 was unable to ask the user if they > want to import a new GPG key. > > Could someone figure out what is the minimum set of Fedora 9 packages > needed to keep in the repo to allow an upgrade from F9 original release? > > Warren Togami > wtogami at redhat.com > I guess the test packages (fedora-release and packagekit) can be found in koji, but I just want to make sure, the right version of the packages are being tested here. Which versions of these packages do you have in mind? /Thomas From wtogami at redhat.com Tue Sep 2 22:42:38 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 02 Sep 2008 18:42:38 -0400 Subject: Help Needed: Figure out F9 Updates PackageKit deps In-Reply-To: References: <48BDA6D5.1070504@redhat.com> Message-ID: <48BDC15E.5030006@redhat.com> Thomas M Steenholdt wrote: > > I guess the test packages (fedora-release and packagekit) can be found > in koji, but I just want to make sure, the right version of the packages > are being tested here. Which versions of these packages do you have in > mind? The latest PackageKit* in F9 updates now. Ignore fedora-release for now. Warren From m.a.young at durham.ac.uk Tue Sep 2 22:44:34 2008 From: m.a.young at durham.ac.uk (M A Young) Date: Tue, 2 Sep 2008 23:44:34 +0100 (BST) Subject: Help Needed: Figure out F9 Updates PackageKit deps In-Reply-To: <20080902215226.GB7798@wolff.to> References: <48BDA6D5.1070504@redhat.com> <20080902215226.GB7798@wolff.to> Message-ID: On Tue, 2 Sep 2008, Bruno Wolff III wrote: > If you are assuming that they already have PackageKit installed (and hence > already have the dependencies installed), wouldn't you just need to include > the new PackageKit (assuming there are no new dependencies) and the new > Fedora-Release packages in the repo? I don't think there is any substitute for testing it, preferably with the minimal install of Fedora that contains PackageKit. The rpms tell you that you definitely need yum-packagekit and PackageKit-libs but are there any other ones that also need updating or adding? For example if gnome-packagekit needs updating as well (though I don't think it does) you would have to make the package "unique" available somewhere because that dependency was added between the Fedora 9 release and the current version. Michael Young From opensource at till.name Tue Sep 2 22:45:04 2008 From: opensource at till.name (Till Maas) Date: Wed, 03 Sep 2008 00:45:04 +0200 Subject: Schedule for F9 updates? In-Reply-To: <1220393187.30380.18.camel@luminos.localdomain> References: <20080902224415.7a597dbb@earth> <200809030000.27162.opensource@till.name> <1220393187.30380.18.camel@luminos.localdomain> Message-ID: <200809030045.19651.opensource@till.name> On Wed September 3 2008, Jesse Keating wrote: > On Wed, 2008-09-03 at 00:00 +0200, Till Maas wrote: > > > > Afaik the FAS account is also needed to download the rpms via SSL > > > > from > > > > > > Koji because one needs a client SSL certificate. > > > > > > I thought download-build was an anonymous action. > > > > This does not work for me: > > wget --no-check-certificate > > We're talking about two different things. You're using wget directly, > whereas I'm talking about using download-build via koji. Maybe you missed this, but I am also talking about downloading packages from Koji via SSL. This is not enabled with the default koji config that is in the F9 koji package and which now seems to be /etc/koji.conf and it seems not to work when I use https for every url in that config file. I know that changing one url in ~/.koji/ made koji at least display some urls with https instead of http. I need to look into my backups to get the details, because the packager-setup-scripts wants to avoid confusion by silently deleting old user edited config files. Ah, I found a bug report that indicates that I changed every URL. I just checked that a scratch srpm build works, but download-build does not when all urls in /etc/koji.conf are https ones. Is download-build really meant to work somehow via SSL? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From overholt at redhat.com Tue Sep 2 23:50:42 2008 From: overholt at redhat.com (Andrew Overholt) Date: Tue, 2 Sep 2008 19:50:42 -0400 Subject: Fedora rawhide rebuild in mock status 2008-08-28 In-Reply-To: <870180fe0809021226hebfa8b8r61074e7174b1004c@mail.gmail.com> References: <20080828104611.A16272@humbolt.us.dell.com> <870180fe0809021226hebfa8b8r61074e7174b1004c@mail.gmail.com> Message-ID: <20080902235041.GB20797@redhat.com> * Jerry James [2008-09-02 15:27]: > > java: error while loading shared libraries: libjli.so: cannot open > shared object file: No such file or directory FYI: a recent glibc change caused this and was fixed. Andrew From jkeating at redhat.com Tue Sep 2 23:59:47 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 02 Sep 2008 16:59:47 -0700 Subject: Schedule for F9 updates? In-Reply-To: <200809030045.19651.opensource@till.name> References: <20080902224415.7a597dbb@earth> <200809030000.27162.opensource@till.name> <1220393187.30380.18.camel@luminos.localdomain> <200809030045.19651.opensource@till.name> Message-ID: <1220399987.30380.19.camel@luminos.localdomain> On Wed, 2008-09-03 at 00:45 +0200, Till Maas wrote: > Maybe you missed this, but I am also talking about downloading packages from > Koji via SSL. This is not enabled with the default koji config that is in the > F9 koji package and which now seems to be /etc/koji.conf and it seems not to > work when I use https for every url in that config file. No, I didn't miss it, which is why I stated we were talking about two different things. > > I know that changing one url in ~/.koji/ made koji at least display > some urls with https instead of http. I need to look into my backups to get > the details, because the packager-setup-scripts wants to avoid confusion by > silently deleting old user edited config files. Ah, I found a bug report that > indicates that I changed every URL. > > I just checked that a scratch srpm build works, but download-build does not > when all urls in /etc/koji.conf are https ones. Is download-build really > meant to work somehow via SSL? It's just plain not tested. Now you're testing it, finding it not to work, and now you know what comes next. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From tmus at tmus.dk Tue Sep 2 23:59:02 2008 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 02 Sep 2008 21:59:02 -0200 Subject: Help Needed: Figure out F9 Updates PackageKit deps In-Reply-To: <48BDC15E.5030006@redhat.com> References: <48BDA6D5.1070504@redhat.com> <48BDC15E.5030006@redhat.com> Message-ID: Warren Togami wrote: > Thomas M Steenholdt wrote: >> >> I guess the test packages (fedora-release and packagekit) can be found >> in koji, but I just want to make sure, the right version of the >> packages are being tested here. Which versions of these packages do >> you have in mind? > > The latest PackageKit* in F9 updates now. > > Ignore fedora-release for now. > > Warren > From at freshly installed F9 (i386, x86_64 = same result): yum update PackageKit\* (which is PackageKit and PackageKit-libs) pulls in the following packages: PackageKit (updates) PackageKit-libs (updates) gnome-packagekit (updates) yum-packagekit (updates) unique (updates) Since this was a fresh F9 installation, where PackageKit-cron and PackageKit-devel did not appear to be available, I thought this list might be useful too. yum install PackageKit\* (which is PackageKit, PackageKit-libs, PackageKit-cron and PackageKit-devel) pulls in the following packages: PackageKit (updates) PackageKit-libs (updates) PackageKit-cron (updates) PackageKit-devel (updates) gnome-packagekit (updates) yum-packagekit (updates) dbus-devel (fedora) sqlite-devel (fedora) unique (updates) As far as I am able to read this, not knowing if something else could potentially change the picture, what we need in the "crossover" repository for PackageKit appears to be: - PackageKit - PackageKit-libs - PackageKit-cron - PackageKit-devel - gnome-packagekit - yum-packagekit - unique Hope this helps. Let me know if something is off in whatever way. /Thomas P.S. I have an i386 and x86_64 version F9 freshly installed in vmware, so if you need anything else, let me know. From dennis at ausil.us Wed Sep 3 01:21:11 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 2 Sep 2008 20:21:11 -0500 Subject: Schedule for F9 updates? In-Reply-To: <1220399987.30380.19.camel@luminos.localdomain> References: <20080902224415.7a597dbb@earth> <200809030045.19651.opensource@till.name> <1220399987.30380.19.camel@luminos.localdomain> Message-ID: <200809022036.10370.dennis@ausil.us> On Tuesday 02 September 2008 06:59:47 pm Jesse Keating wrote: > On Wed, 2008-09-03 at 00:45 +0200, Till Maas wrote: > > Maybe you missed this, but I am also talking about downloading packages > > from Koji via SSL. This is not enabled with the default koji config that > > is in the F9 koji package and which now seems to be /etc/koji.conf and it > > seems not to work when I use https for every url in that config file. > > No, I didn't miss it, which is why I stated we were talking about two > different things. > > > I know that changing one url in ~/.koji/ made koji at least > > display some urls with https instead of http. I need to look into my > > backups to get the details, because the packager-setup-scripts wants to > > avoid confusion by silently deleting old user edited config files. Ah, I > > found a bug report that indicates that I changed every URL. > > > > I just checked that a scratch srpm build works, but download-build does > > not when all urls in /etc/koji.conf are https ones. Is download-build > > really meant to work somehow via SSL? > > It's just plain not tested. Now you're testing it, finding it not to > work, and now you know what comes next. possibly it worked in the past but since /packages/ is redirected to kojipkgs.fedoraproject.org now and it doesn't have https configured download-build will definitely not work if you use a https url in pkgurl in your koji config. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From mattdm at mattdm.org Wed Sep 3 02:01:01 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 2 Sep 2008 22:01:01 -0400 Subject: Fedora 10 Beta Freeze coming soon In-Reply-To: <1220392329.30380.14.camel@luminos.localdomain> References: <1218474175.3398.46.camel@localhost.localdomain> <1220392329.30380.14.camel@luminos.localdomain> Message-ID: <20080903020101.GA1577@jadzia.bu.edu> On Tue, Sep 02, 2008 at 02:52:09PM -0700, Jesse Keating wrote: > I realize that rawhide has been less than great lately, and we're > working quite hard to fix the issues. The installer images from the > 30th may be of use in getting rawhide installed and then updating to > what is in the public repos. See > http://kojipkgs.fedoraproject.org/mash/rawhide-20080830/development/ > (please only grab the installer images from there, not the entire tree) FWIW, I just did a net install from the F10 alpha images today with the rawhide repo enabled and that went without a hitch. -- Matthew Miller mattdm at mattdm.org From huzaifas at redhat.com Wed Sep 3 03:19:22 2008 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Wed, 03 Sep 2008 08:49:22 +0530 Subject: Fedora Security Tools spin Message-ID: <48BE023A.70703@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, I just came across a knoppix security tool live CD and thought it would be a good idea for a security tool fedora spin too. The tools are freely available at: http://knoppix-std.org/index.html and are all GPLed? Do you guys think this is a good idea, I am sure such a spin does not exists in Fedora yet. Thanks for your inputs in advance. - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFIvgI6zHDc8tpb2uURAmrzAJ4tx7cMrCd4LNczHZ6pRS2TQ60bGQCfVhYm aXLofMTIoK89NuDOQXjQmGI= =Ai3F -----END PGP SIGNATURE----- From jwilliam at xmission.com Wed Sep 3 03:23:50 2008 From: jwilliam at xmission.com (Jerry Williams) Date: Tue, 2 Sep 2008 21:23:50 -0600 Subject: Fedora 10 Beta Freeze coming soon In-Reply-To: <1220392329.30380.14.camel@luminos.localdomain> References: <1218474175.3398.46.camel@localhost.localdomain> <1220392329.30380.14.camel@luminos.localdomain> Message-ID: I am not sure how hard it is to make a spin, but it seems like there it too big of a gap between spins. I know that things have been rough for a lot of people with the problems with the Fedora site. To me it seems like there should be another alpha type spin before beta. My 2 cents, Jerry Williams > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- > bounces at redhat.com] On Behalf Of Jesse Keating > Sent: Tuesday, September 02, 2008 3:52 PM > To: fedora-devel-list at redhat.com > Cc: fedora-devel-announce at redhat.com > Subject: Re: Fedora 10 Beta Freeze coming soon > > On Mon, 2008-08-11 at 13:02 -0400, Jesse Keating wrote: > > The Fedora 10 Beta freeze is scheduled for the 19th of Aug, one week and > > one day away. I know it hasn't been very long since the Alpha release, > > but that's how we roll here in the land of 6 month release cycles. > > > > Beta freeze also marks the Feature freeze, so it is very important that > > you get your features into working, testable shape by then, or be > > prepared to try your feature again for Fedora 11. > > > > We'd like to treat rawhide as a slushy freeze at this point, we'll be > > doing full composes against rawhide to test for various things and be > > ahead of the curve come actual freeze time, so we'd like you to not land > > any really dangerous changes without extensive testing first, and > > notification to the Fedora lists about your scary change. If we all > > work together we can get through the beta freeze period quickly and be > > on to the bugfixing mode after beta releases. > > > > http://fedoraproject.org/wiki/Releases/10/Schedule is the current > > schedule, although releng/Fesco/Board has the ability to change the > > schedule as needed. This week's meetings of the various boards, sigs, > > groups, etc.. should focus on Beta readiness. It would be good to take > > a moment to see what state your area of interest is in, and how likely > > it would be that said area of interest will be in a "testable" shape by > > the Beta freeze. If more (reasonable) time is needed, now is the time > > to let the project know so that we can effectively manage the remainder > > of our release schedule. > > > > Thanks for all your hard work in making Fedora 10 great! > > > > Well, it's been an interesting couple of weeks to say the least. > > We moved our freeze date to reflect the situation. The new freeze date > is Sept. 9, which is in 7 days. This is a friendly reminder that the > freeze is coming up, and coming up quickly. > > I realize that rawhide has been less than great lately, and we're > working quite hard to fix the issues. The installer images from the > 30th may be of use in getting rawhide installed and then updating to > what is in the public repos. See > http://kojipkgs.fedoraproject.org/mash/rawhide-20080830/development/ > (please only grab the installer images from there, not the entire tree) > > -- > Jesse Keating > Fedora -- Freedom? is a feature! > identi.ca: http://identi.ca/jkeating From tmz at pobox.com Wed Sep 3 03:56:05 2008 From: tmz at pobox.com (Todd Zullinger) Date: Tue, 2 Sep 2008 23:56:05 -0400 Subject: Fedora Security Tools spin In-Reply-To: <48BE023A.70703@redhat.com> References: <48BE023A.70703@redhat.com> Message-ID: <20080903035605.GE25264@inocybe.teonanacatl.org> Huzaifa Sidhpurwala wrote: > I just came across a knoppix security tool live CD and thought it > would be a good idea for a security tool fedora spin too. > The tools are freely available at: > > http://knoppix-std.org/index.html > and are all GPLed? > > Do you guys think this is a good idea, I am sure such a spin does > not exists in Fedora yet. Do you mean something like Luke Macken put together? http://fedoraproject.org/wiki/LukeMacken/SecurityLiveCD -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A penny saved kills your career in government. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From huzaifas at redhat.com Wed Sep 3 05:24:37 2008 From: huzaifas at redhat.com (Huzaifa Sidhpurwala) Date: Wed, 03 Sep 2008 10:54:37 +0530 Subject: Fedora Security Tools spin In-Reply-To: <20080903035605.GE25264@inocybe.teonanacatl.org> References: <48BE023A.70703@redhat.com> <20080903035605.GE25264@inocybe.teonanacatl.org> Message-ID: <48BE1F95.2090509@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Todd Zullinger wrote: > Huzaifa Sidhpurwala wrote: >> I just came across a knoppix security tool live CD and thought it >> would be a good idea for a security tool fedora spin too. >> The tools are freely available at: >> >> http://knoppix-std.org/index.html >> and are all GPLed? >> >> Do you guys think this is a good idea, I am sure such a spin does >> not exists in Fedora yet. > > Do you mean something like Luke Macken put together? > > http://fedoraproject.org/wiki/LukeMacken/SecurityLiveCD > > Yeah but more tools and more bare bones, Perhaps i can assist Luke in this? - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org iD8DBQFIvh+UzHDc8tpb2uURAoSnAJ45Pj3rI4HxrliH/AqHJ09poZQqgACdF4/J Y7gjqUQJIHb0tGpFUJLLh0s= =/i75 -----END PGP SIGNATURE----- From alexl at users.sourceforge.net Wed Sep 3 05:28:43 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Tue, 02 Sep 2008 22:28:43 -0700 Subject: Fedora rawhide rebuild in mock status 2008-08-28 x86_64 In-Reply-To: <20080828104730.A16352@humbolt.us.dell.com> (Matt Domsch's message of "Thu\, 28 Aug 2008 10\:47\:30 -0500") References: <20080828104730.A16352@humbolt.us.dell.com> Message-ID: >>>>> "MD" == Matt Domsch writes: MD> Fedora Rawhide-in-Mock Build Results for x86_64 based on Rawhide MD> from 2008-08-12. MD> picard-0.9.0-6.fc9 (build/make) alexlan,jcollie Rebuilt now in rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=61367 MD> Miro-1.2.4-3.fc10 (build/make) tscherf,caillon,salimma,alexlan,wguaraldi MD> perl-bioperl-1.5.2_102-12.fc9 (patch_fuzz) alexlan,perl-sig Will try and work on these soon, but about to take a vacation, so may not get any time to get these ones done before I leave. Any co-maintainers (or indeed any Fedora contributors) are welcome and encouraged to step up to fix these if I'm unable to do so. Alex From wtogami at redhat.com Wed Sep 3 05:58:35 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 03 Sep 2008 01:58:35 -0400 Subject: Help Needed: Test pidgin-2.5.1 and Yahoo IM Message-ID: <48BE278B.6070001@redhat.com> Here is an opportunity for someone to test a failure that happened to me. Upstream requested more information about this and a good write-up for reproducing, but I cannot prioritize working on this now. (Working on getting Fedora Updates flowing...) If this is a real issue, upstream should know about it quickly. This 2.5.1 plus additional fixes is likely to become the next version in RHEL-5. https://admin.fedoraproject.org/updates/pidgin-2.5.1-1.fc9 * Install pidgin-2.5.1 on F-9. * Run pidgin with the -d option to get debugging output on the terminal. * Have someone else that you haven't talked to yet add you on Yahoo IM. Do you see the authorization confirmation request in your Buddy List? When you have both added each other, do you immediately see each other online? Or do you need to restart pidgin to see each other? * Is this reproducible by removing each other from respective Buddy Lists and repeating the procedure? Warren Togami wtogami at redhat.com From hughsient at gmail.com Wed Sep 3 07:38:01 2008 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 03 Sep 2008 08:38:01 +0100 Subject: Help Needed: Figure out F9 Updates PackageKit deps In-Reply-To: References: <48BDA6D5.1070504@redhat.com> <20080902215226.GB7798@wolff.to> Message-ID: <1220427481.3258.2.camel@hughsie-work> On Tue, 2008-09-02 at 23:44 +0100, M A Young wrote: > For example if gnome-packagekit needs updating as well (though I don't > think it does) Yes it does. gnome-packagekit versions are in lock-step with PackageKit versions. > you would have to make the package "unique" available > somewhere because that dependency was added between the Fedora 9 > release and the current version. Correct. I think you'll need: PackageKit, gnome-packagekit, unique Richard. From stransky at redhat.com Wed Sep 3 07:55:07 2008 From: stransky at redhat.com (Martin Stransky) Date: Wed, 03 Sep 2008 09:55:07 +0200 Subject: libmozembed In-Reply-To: <1220138837.31700.1.camel@PB3.Linux> References: <1220138837.31700.1.camel@PB3.Linux> Message-ID: <48BE42DB.5070306@redhat.com> libmozembed is provided by xulrunner-devel-unstable. thunderbird doesn't have any -devel package... Paul wrote: > Hi, > > Is there any chance of libmozembed being made a separate package? Both > monodevelop and mono-tools can make use of them but it seems a pain to > have to install thunderbird to get them. > > TTFN > > Paul > From paul at all-the-johnsons.co.uk Wed Sep 3 08:02:08 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 03 Sep 2008 09:02:08 +0100 Subject: Fedora rawhide rebuild in mock status 2008-08-28 x86_64 In-Reply-To: <20080828104730.A16352@humbolt.us.dell.com> References: <20080828104730.A16352@humbolt.us.dell.com> Message-ID: <1220428929.20088.4.camel@PB3.Linux> Hi, > mono-1.9.1-2.fc10 (patch_fuzz) laxathom,pfj,laxathom Mono 2.0-5 is in rawhide and happily it goes on! (It's been there for a while as well!) > xmms-1.2.10-38.fc9 (patch_fuzz) pfj xmms-1.2.11-1.20071117cvs was built happily for rawhide yesterday > xsp-1.9.1-2.fc10 (patch_fuzz) pfj xsp 2.0-2 (IIRC) is in rawhile as works nicely > monodevelop-0.19-6.fc9 [u'449441 ASSIGNED'] (build/make) pfj MD-1.9-5 is in rawhide and working.... TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From wolfy at nobugconsulting.ro Wed Sep 3 08:32:27 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Wed, 03 Sep 2008 11:32:27 +0300 Subject: Help Needed: Test pidgin-2.5.1 and Yahoo IM In-Reply-To: <48BE278B.6070001@redhat.com> References: <48BE278B.6070001@redhat.com> Message-ID: <48BE4B9B.9040802@nobugconsulting.ro> Warren Togami wrote: > Here is an opportunity for someone to test a failure that happened to > me. Upstream requested more information about this and a good > write-up for reproducing, but I cannot prioritize working on this > now. (Working on getting Fedora Updates flowing...) > > If this is a real issue, upstream should know about it quickly. This > 2.5.1 plus additional fixes is likely to become the next version in > RHEL-5. > > https://admin.fedoraproject.org/updates/pidgin-2.5.1-1.fc9 > > * Install pidgin-2.5.1 on F-9. > * Run pidgin with the -d option to get debugging output on the terminal. > * Have someone else that you haven't talked to yet add you on Yahoo IM. > Do you see the authorization confirmation request in your Buddy List? > When you have both added each other, do you immediately see each > other online? > Or do you need to restart pidgin to see each other? > * Is this reproducible by removing each other from respective Buddy > Lists and repeating the procedure? > > Warren Togami > wtogami at redhat.com > I've got no F9 around but I've just tested on F7 (recompiled from the latest available sources as downloaded from fedora cvs) and everything seems OK. For the record: Name : pidgin Relocations: (not relocatable) Version : 2.5.1 Vendor: (none) Release : 1.fc7 Build Date: Mon 01 Sep 2008 11:11:07 AM EEST Install Date: Mon 01 Sep 2008 11:17:17 AM EEST Build Host: wolfy.nobugconsulting.ro I can also rebuild and test on Centos 5 if this is useful. From paul at all-the-johnsons.co.uk Wed Sep 3 08:02:08 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 03 Sep 2008 09:02:08 +0100 Subject: Fedora rawhide rebuild in mock status 2008-08-28 x86_64 In-Reply-To: <20080828104730.A16352@humbolt.us.dell.com> References: <20080828104730.A16352@humbolt.us.dell.com> Message-ID: <1220428929.20088.4.camel@PB3.Linux> Hi, > mono-1.9.1-2.fc10 (patch_fuzz) laxathom,pfj,laxathom Mono 2.0-5 is in rawhide and happily it goes on! (It's been there for a while as well!) > xmms-1.2.10-38.fc9 (patch_fuzz) pfj xmms-1.2.11-1.20071117cvs was built happily for rawhide yesterday > xsp-1.9.1-2.fc10 (patch_fuzz) pfj xsp 2.0-2 (IIRC) is in rawhile as works nicely > monodevelop-0.19-6.fc9 [u'449441 ASSIGNED'] (build/make) pfj MD-1.9-5 is in rawhide and working.... TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From m.a.young at durham.ac.uk Wed Sep 3 08:39:44 2008 From: m.a.young at durham.ac.uk (M A Young) Date: Wed, 3 Sep 2008 09:39:44 +0100 (BST) Subject: Help Needed: Figure out F9 Updates PackageKit deps In-Reply-To: <1220427481.3258.2.camel@hughsie-work> References: <48BDA6D5.1070504@redhat.com> <20080902215226.GB7798@wolff.to> <1220427481.3258.2.camel@hughsie-work> Message-ID: On Wed, 3 Sep 2008, Richard Hughes wrote: > On Tue, 2008-09-02 at 23:44 +0100, M A Young wrote: >> For example if gnome-packagekit needs updating as well (though I don't >> think it does) > > Yes it does. gnome-packagekit versions are in lock-step with PackageKit > versions. Well the question is whether the old gnome-packagekit would work with the new PackageKit, but trying to downgrade gnome-packagekit shows you are indeed correct because the original gnome-packagekit wants libpackagekit.so.3 but but the current PackageKit-libs gives libpackagekit.so.4 >> you would have to make the package "unique" available >> somewhere because that dependency was added between the Fedora 9 >> release and the current version. > > Correct. I think you'll need: > > PackageKit, gnome-packagekit, unique plus of course PackageKit-libs and yum-packagekit which are direct requirements for PackageKit. Michael Young From nicolas.mailhot at laposte.net Wed Sep 3 08:56:10 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 03 Sep 2008 10:56:10 +0200 Subject: Fedora fonts SIG pre-freeze status Message-ID: <1220432170.3677.15.camel@rousalka.okg> Hi all, I've updated our status page http://fedoraproject.org/wiki/Fonts_inclusion_history While we've still not quite reached the F9 addition volume, things are starting to look not too bad. It would be nice to reach the 40 new packages mark by F10 release time. This page is intended to be referenced in release notes, so each new font needs to be described properly. Right now: ? icelandic fonts and smc fonts have no wiki page ? darkgarden, sportrop and thibault fonts have unfinished pages ? please fix Additionnaly the plan is still to bump fontforge to the latest version just before next week's freeze (and rebuild dependant fonts). Please make sure your packages are ready for rebuild by then. 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 nicu_fedora at nicubunu.ro Wed Sep 3 09:07:48 2008 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Wed, 03 Sep 2008 12:07:48 +0300 Subject: Help Needed: Test pidgin-2.5.1 and Yahoo IM In-Reply-To: <48BE278B.6070001@redhat.com> References: <48BE278B.6070001@redhat.com> Message-ID: <48BE53E4.3050800@nicubunu.ro> Warren Togami wrote: > Here is an opportunity for someone to test a failure that happened to > me. Upstream requested more information about this and a good write-up > for reproducing, but I cannot prioritize working on this now. (Working > on getting Fedora Updates flowing...) > > If this is a real issue, upstream should know about it quickly. This > 2.5.1 plus additional fixes is likely to become the next version in RHEL-5. > > https://admin.fedoraproject.org/updates/pidgin-2.5.1-1.fc9 > > * Install pidgin-2.5.1 on F-9. I installed the 386 build from there. > * Run pidgin with the -d option to get debugging output on the terminal. Did that > * Have someone else that you haven't talked to yet add you on Yahoo IM. I asked Manuel/wolfy (see the other mail in the thread) and he added me. > Do you see the authorization confirmation request in your Buddy List? Yes, I saw it and accepted. > When you have both added each other, do you immediately see each other > online? I saw him after about one second. > Or do you need to restart pidgin to see each other? No need for that. > * Is this reproducible by removing each other from respective Buddy > Lists and repeating the procedure? We deleted each other and I added him first, it worked fine. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From j.w.r.degoede at hhs.nl Wed Sep 3 09:28:21 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 03 Sep 2008 11:28:21 +0200 Subject: Fedora fonts SIG pre-freeze status In-Reply-To: <1220432170.3677.15.camel@rousalka.okg> References: <1220432170.3677.15.camel@rousalka.okg> Message-ID: <48BE58B5.6080603@hhs.nl> Nicolas Mailhot wrote: > Hi all, > > I've updated our status page > http://fedoraproject.org/wiki/Fonts_inclusion_history > > While we've still not quite reached the F9 addition volume, things are > starting to look not too bad. It would be nice to reach the 40 new > packages mark by F10 release time. > Excellent work guys! I want to use this opportunity to say a big thanks to all of you for all the hard work in getting top notch font support in Fedora! Regards, Hans From m.a.young at durham.ac.uk Wed Sep 3 10:22:59 2008 From: m.a.young at durham.ac.uk (M A Young) Date: Wed, 3 Sep 2008 11:22:59 +0100 (BST) Subject: Help Needed: Figure out F9 Updates PackageKit deps In-Reply-To: References: <48BDA6D5.1070504@redhat.com> <20080902215226.GB7798@wolff.to> <1220427481.3258.2.camel@hughsie-work> Message-ID: >From an x86_64 live CD - I am not sure how relevant the error at the end is. Michael Young [root at localhost ~]# yum update PackageKit Loaded plugins: refresh-packagekit updates | 2.3 kB 00:00 primary.sqlite.bz2 | 2.8 MB 00:04 fedora | 2.4 kB 00:00 primary.sqlite.bz2 | 7.6 MB 00:10 Setting up Update Process Resolving Dependencies --> Running transaction check --> Processing Dependency: PackageKit = 0.1.12-10.20080505.fc9 for package: PackageKit-libs ---> Package PackageKit.x86_64 0:0.2.4-4.fc9 set to be updated --> Processing Dependency: yum-packagekit = 0.2.4-4.fc9 for package: PackageKit --> Running transaction check ---> Package yum-packagekit.x86_64 0:0.2.4-4.fc9 set to be updated ---> Package PackageKit-libs.x86_64 0:0.2.4-4.fc9 set to be updated --> Processing Dependency: libpackagekit.so.3()(64bit) for package: gnome-packagekit --> Running transaction check ---> Package gnome-packagekit.x86_64 0:0.2.3-9.fc9 set to be updated --> Processing Dependency: unique >= 0.9.4 for package: gnome-packagekit --> Processing Dependency: libunique-1.0.so.0()(64bit) for package: gnome-packagekit --> Running transaction check ---> Package unique.x86_64 0:0.9.4-5.fc9 set to be updated --> Finished Dependency Resolution Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Updating: PackageKit x86_64 0.2.4-4.fc9 updates 563 k PackageKit-libs x86_64 0.2.4-4.fc9 updates 110 k gnome-packagekit x86_64 0.2.3-9.fc9 updates 1.1 M yum-packagekit x86_64 0.2.4-4.fc9 updates 10 k Installing for dependencies: unique x86_64 0.9.4-5.fc9 updates 33 k Transaction Summary ============================================================================= Install 1 Package(s) Update 4 Package(s) Remove 0 Package(s) Total download size: 1.8 M Is this ok [y/N]: y Downloading Packages: (1/5): yum-packagekit-0.2.4-4.fc9.x86_64.rpm | 10 kB 00:00 (2/5): PackageKit-libs-0.2.4-4.fc9.x86_64.rpm | 110 kB 00:00 (3/5): PackageKit-0.2.4-4.fc9.x86_64.rpm | 563 kB 00:01 (4/5): gnome-packagekit-0.2.3-9.fc9.x86_64.rpm | 1.1 MB 00:01 (5/5): unique-0.9.4-5.fc9.x86_64.rpm | 33 kB 00:00 Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing: unique ######################### [1/9] Updating : yum-packagekit ######################### [2/9] Updating : PackageKit ######################### [3/9] Updating : PackageKit-libs ######################### [4/9] Updating : gnome-packagekit ######################### [5/9] Cleanup : gnome-packagekit ######################### [6/9] Cleanup : PackageKit ######################### [7/9] Cleanup : PackageKit-libs ######################### [8/9] Cleanup : yum-packagekit ######################### [9/9] ERROR:dbus.connection:Unable to set arguments () according to signature u's': : More items found in D-Bus signature than in Python arguments Traceback (most recent call last): File "/usr/bin/yum", line 29, in yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 241, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 193, in main base.doTransaction() File "/usr/share/yum-cli/cli.py", line 432, in doTransaction self.runTransaction(cb=cb) File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 790, in runTransaction self.plugins.run('posttrans') File "/usr/lib/python2.5/site-packages/yum/plugins.py", line 175, in run func(conduitcls(self, self.base, conf, **kwargs)) File "/usr/lib/yum-plugins/refresh-packagekit.py", line 37, in posttrans_hook packagekit_iface.StateHasChanged('posttrans') File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 68, in __call__ return self._proxy_method(*args, **keywords) File "/usr/lib/python2.5/site-packages/dbus/proxies.py", line 140, in __call__ **keywords) File "/usr/lib/python2.5/site-packages/dbus/connection.py", line 597, in call_blocking message.append(signature=signature, *args) TypeError: More items found in D-Bus signature than in Python arguments From rjones at redhat.com Wed Sep 3 10:53:53 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 3 Sep 2008 11:53:53 +0100 Subject: wtf ... Something strips installed binaries??? In-Reply-To: References: <20080902080150.GA483@amd.home.annexia.org> <544eb990809020205q4f0c7764ycfbbd5b2080c09fb@mail.gmail.com> Message-ID: <20080903105353.GA15585@amd.home.annexia.org> On Tue, Sep 02, 2008 at 11:07:45AM -0200, Thomas M Steenholdt wrote: > Bill Crawford wrote: >> Thomas M Steenholdt wrote: >>> I wasn't even aware that prelinking actually changed the files. Isn't this kind of dangerous from a system-integrity point-of-view. How can we ever validate binaries if they are modified on purpose? >> >> With "prelink --verify" ? >> > > I can't see how that would actually verify that the binary has not been > modified by a rootkit or whatever? rpm -V should be able to detect this, > on the other hand, but how it works in conjunction with prelinking I > don't know... Another problem is that it prevents binaries from being verified from outside the machine. I've been looking at tools which verify binaries in a virtual machine, from outside the virtual machine (to ensure a high degree of integrity for the inspection tool). Same applies for AIDE (http://www.cs.tut.fi/~rammer/aide.html) if you run it from a CD-ROM or from the host on a virtual machine. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From jnovy at redhat.com Wed Sep 3 11:40:44 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 3 Sep 2008 13:40:44 +0200 Subject: telive 2008 released (in time for f10?) In-Reply-To: References: Message-ID: <20080903114044.GA30583@dhcp-lab-186.brq.redhat.com> Hi Neal, On Tue, Sep 02, 2008 at 01:08:47PM -0400, Neal Becker wrote: > tl 2008 is released. Will it be part of f10? > since the new TeX Live 2008 comes with lots of changes and it needs some time for testing (in Fedora land) I vote for letting TeX Live 2007 out with couple of updated packages (beamer, etc.) for F10 and having new TeX Live 2008 as an update after F10. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From fedora at leemhuis.info Wed Sep 3 12:06:58 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 03 Sep 2008 14:06:58 +0200 Subject: xmms heads up In-Reply-To: <1220394346.7539.3.camel@PB3.Linux> References: <1220394346.7539.3.camel@PB3.Linux> Message-ID: <48BE7DE2.4000401@leemhuis.info> On 03.09.2008 00:25, Paul wrote: > > If you're using the livna mp3 plugin, you will not be able to update > directly as that plugin required the old xmms-lib; if you download xmms > from ftp though, you can install it with --no-deps and it works fine. I > hope whoever looks after that for livna will be quick on the rebuild for > it. You could have mailed the Livna/RPM Fusion maintainers (CCed) in advance to coordinate things, then we could have prepared a update to release it in sync ;-) Sure, a mail on fedora-devel-list will often do the trick, but it's easily missed. Cu knurd From rawhide at fedoraproject.org Wed Sep 3 12:10:55 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Wed, 3 Sep 2008 12:10:55 +0000 (UTC) Subject: rawhide report: 20080903 changes Message-ID: <20080903121055.652E71F8251@releng2.fedora.phx.redhat.com> New package UnihanDb The Unihan character database in fifth normal form New package bti Bash Twitter Idiocy New package echo-artist Automation tools for echo-icon-theme artists New package enlightenment Enlightenment DR17 - a next generation desktop shell New package erlang-pgsql Erlang PostgreSQL interface New package google-gadgets Google Gadgets for Linux New package gupnp GUPnP is an framework for creating UPnP devices & control points New package hunspell-id Indonesian hunspell dictionaries New package ircd-ratbox Ircd-ratbox is an advanced, stable and fast ircd New package libUnihan C library for Unihan character database in fifth normal form New package pgbouncer Lightweight connection pooler for PostgreSQL New package python-storm An object-relational mapper (ORM) for Python New package qtoctave Frontend for Octave New package ratbox-services Service package for ircd-ratbox New package tangogps GTK+ mapping and GPS application New package teseq An utility for rendering terminal typescripts human-readable New package vttest Test the compatibility of so-called "VT100-compatible" terminals Updated Packages: Canna-3.7p3-25.fc10 ------------------- * Mon Sep 1 18:00:00 2008 Akira TAGOH - 3.7p3-25 - skk-dictionaries.patch: Updated. Django-1.0-0.1.rc1.fc10 ----------------------- * Tue Sep 2 18:00:00 2008 Michel Salim - 1.0-0.1.rc1.fc10 - CSRF security update: bz#460966 PerceptualDiff-1.0.2-3.fc10 --------------------------- * Mon Sep 1 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.0.2-3 - Re-introduce gcc43 patch * Mon Sep 1 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.0.2-2 - Add Missing BR freeimage-devel * Mon Sep 1 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.0.2-1 - Update to 1.0.2 SDL-1.2.13-6.fc10 ----------------- * Tue Sep 2 18:00:00 2008 Thomas Woerner 1.2.13-6 - dropped pulseaudio hack (rhbz#448270) - pulseaudio is now used by default - simplified spec file for new architecture support (rhbz#433618) apel-10.7-2.fc10 ---------------- * Mon Sep 1 18:00:00 2008 Akira TAGOH - 10.7-2 - Update the spec file. argyllcms-1.0.2-1.fc10 ---------------------- * Mon Sep 1 18:00:00 2008 Nicolas Mailhot - 1.0.2-1 ??? Bugfix release arj-3.10.22-5.fc10 ------------------ * Sat Aug 30 18:00:00 2008 Robert Scheck 3.10.22-5 - Corrected from %patch to %patch0 to make rpm > 4.4 happy aspell-0.60.6-3.fc10 -------------------- * Mon Sep 1 18:00:00 2008 Ivana Varekova - 12:0.60.6-3 - fix patch format at-spi-1.23.91-1.fc10 --------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 1.23.91-1 - Update to 1.23.91 audit-1.7.5-1.fc10 ------------------ * Mon Aug 25 18:00:00 2008 Steve Grubb 1.7.5-1 - Update system-config-audit to 0.4.8 - Whole lot of bug fixes - see ChangeLog for details - Reimplement auditd main loop using libev - Add TCP listener to auditd to receive remote events - Fix scheduler problem (#457061) bigboard-0.6.1-1.fc10 --------------------- * Tue Sep 2 18:00:00 2008 Owen Taylor - 0.6.1-1 - Update to 0.6.1 * Tue Sep 2 18:00:00 2008 Owen Taylor - 0.6.0-2 - Add missing BuildRequires on empathy-devel * Tue Sep 2 18:00:00 2008 Owen Taylor - 0.6.0-1 - Update to 0.6.0 binutils-2.18.50.0.9-1.fc10 --------------------------- * Sat Aug 30 18:00:00 2008 Jan Kratochvil 2.18.50.0.9-1 - Update to 2.18.50.0.9. - Drop the ppc-only spu target pre-build stage (BZ 455242). - Drop parsing elf64-i386 files for kdump PAE vmcore dumps (BZ 457189). - New .spec BuildRequires zlib-devel (/-static) for compressed sections. - Update .spec Buildroot to be more unique. bpython-0.7.0-1.fc10 -------------------- * Mon Sep 1 18:00:00 2008 Terje Rosten - 0.7.0-1 - 0.7.0 bug-buddy-2.23.91.1-1.fc10 -------------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 1:2.23.91.1-1 - Update to 2.23.91.1 bzip2-1.0.5-3.fc10 ------------------ * Mon Sep 1 18:00:00 2008 Ivana Varekova 1.0.5-3 - minor spec file changew cairo-dock-1.6.2.1-1.fc10 ------------------------- * Sat Aug 30 18:00:00 2008 Mamoru Tasaka - 1.6.2.1-1 - 1.6.2.1 camE-1.9-13 ----------- * Sat Aug 30 18:00:00 2008 Hans de Goede 1.9-13 - Add patch to use libv4l to support webcams which use custom video formats cheese-2.23.91-1.fc10 --------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen 2.23.91-1 - Update to 2.23.91 cobbler-1.2.1-1.fc10 -------------------- * Tue Sep 2 18:00:00 2008 Michael DeHaan - 1.2.1-1 - Upstream changes (see CHANGELOG) - Package unowned directories cyrus-imapd-2.3.12p2-1.fc10 --------------------------- * Mon Sep 1 18:00:00 2008 Dan Hor??k - 2.4.13-2.1 - Rebased to latest upstream version 2.4.13 dbxml-perl-2.0040013-0.fc10 --------------------------- * Sun Aug 31 18:00:00 2008 Milan Zazrivec - 2.0040013-0 - Rebased to latest dbxml upstream version (ver. 2.4.13) dovecot-1.1.3-1.fc10 -------------------- * Tue Sep 2 18:00:00 2008 Dan Horak - 1:1.1.3-1 - update to upstream version 1.1.3 dsniff-2.4-0.4.b1.fc10 ---------------------- * Sat Aug 30 18:00:00 2008 Robert Scheck 2.4-0.4.b1 - Re-diffed dsniff url log escaping patch for no fuzz dvb-apps-1.1.1-12.fc10 ---------------------- * Sat Aug 30 18:00:00 2008 Ville Skytt?? - 1.1.1-12 - Update tuning files to 20080830. - Convert data files to UTF-8. - Unfuzz optflags patch. edrip-fonts-20080826-1.fc10 --------------------------- * Mon Sep 1 18:00:00 2008 - 20080826-1 ?? Still more extended cyrillic coverage eel2-2.23.91-1.fc10 ------------------- * Tue Sep 2 18:00:00 2008 Tomas Bzatek - 2.23.91-1 - Update to 2.23.91 eggdrop-1.6.19-2.fc10 --------------------- * Sat Aug 30 18:00:00 2008 Robert Scheck 1.6.19-2 - Re-diffed eggdrop configuration patch for no fuzz elinks-0.12-0.4.pre1.fc10 ------------------------- * Mon Sep 1 18:00:00 2008 Ondrej Vasik 0.12-0.4.pre1 - upstream fix for bittorrent protocol - upstream fix for out of screen bittorrent dialog texts eog-2.23.91-1.fc10 ------------------ * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 epdfview-0.1.6-4.fc10 --------------------- * Sun Aug 31 18:00:00 2008 Michal Schmidt - 0.1.6-4 - Fix build with the new RPM. epiphany-2.23.91-1.fc10 ----------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 escape-200704130-9.fc10 ----------------------- * Sat Aug 30 18:00:00 2008 Adam Goode - 200704130-9 - RPM 4.6 fix for patch tag evince-2.23.91-1.fc10 --------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 * Thu Aug 28 18:00:00 2008 Michael Schwendt - 2.23.6-2 - Include %_libdir/evince directory. evolution-2.23.91-1.fc10 ------------------------ * Mon Sep 1 18:00:00 2008 Matthew Barnes - 2.23.91-1.fc10 - Update to 2.23.91 - Bump eds_version to 2.23.91 evolution-data-server-2.23.91-1.fc10 ------------------------------------ * Mon Sep 1 18:00:00 2008 Matthew Barnes - 2.23.91-1.fc10 - Update to 2.23.91 evolution-exchange-2.23.91-1.fc10 --------------------------------- * Mon Sep 1 18:00:00 2008 Matthew Barnes - 2.23.91-1.fc10 - Update to 2.23.91 - Add -Werror to CFLAGS. evolution-webcal-2.23.91-1.fc10 ------------------------------- * Sat Aug 30 18:00:00 2008 Matthew Barnes - 2.23.91-1.fc10 - Update to 2.23.91 - Add intltool build requirement. fedora-bookmarks-10-1 --------------------- * Tue Sep 2 18:00:00 2008 Tom "spot" Callaway 10-1 - fix bookmarks.html to not have embedded icons, they aren't usable under the GFDL. resolves bz 433471 file-browser-applet-0.5.8-1.fc10 -------------------------------- * Sat Aug 30 18:00:00 2008 Deji Akingunola - 0.5.8-1 - Update to 0.5.8 file-roller-2.23.91-1.fc10 -------------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 filezilla-3.1.2-1.fc10 ---------------------- * Mon Sep 1 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.1.2-1 - Update to 3.1.2 foomatic-3.0.2-64.fc10 ---------------------- * Tue Sep 2 18:00:00 2008 Tim Waugh 3.0.2-64 - Fixed typo in HP-Color_LaserJet_9500_MFP.xml. * Tue Sep 2 18:00:00 2008 Tim Waugh 3.0.2-63 - Avoid busy-looping when trying to shorten long PPD nicknames. * Tue Sep 2 18:00:00 2008 Tim Waugh 3.0.2-62 - Removed patch fuzz. - Fixed PPD generation for HP LaserJet 4345 MFP (bug #459847). fotoxx-5.2-1.fc10 ----------------- * Sun Aug 31 18:00:00 2008 Nicoleau Fabien - 5.2-1 * Rebuild for 5.2 fvwm-2.5.26-2.fc10 ------------------ * Sat Aug 30 18:00:00 2008 Adam Goode - 2.5.26-2 - RPM 4.6 fix for patch tag gcalctool-5.23.91-1.fc10 ------------------------ * Tue Sep 2 18:00:00 2008 Matthias Clasen - 5.23.91-1 - Update to 5.23.91 gconf-editor-2.23.91-1.fc10 --------------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 gdb-6.8-24.fc10 --------------- * Tue Sep 2 18:00:00 2008 Jan Kratochvil - 6.8-24 - Fix PIE patch regression for loading binaries from valgrind (BZ 460319). gedit-2.23.91-1.fc10 -------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 1:2.23.91-1 - Update to 2.23.91 gjots2-2.3.7-1.fc10 ------------------- * Mon Sep 1 18:00:00 2008 Radek Vok??l 2.3.7-1 - fix requires - update to 2.3.7 glib2-2.18.0-1.fc10 ------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.18.0-1 - Update to 2.18.0 glitz-0.5.6-6.fc10 ------------------ gmp-4.2.2-8.fc10 ---------------- * Thu Apr 24 18:00:00 2008 Tom "spot" Callaway 4.2.2-8 - add sparc/sparc64 support gmyth-0.7.1-7.fc10 ------------------ * Mon Sep 1 18:00:00 2008 - Bastien Nocera - 0.7.1-7 - Remove extraneous debug and warnings * Fri Aug 29 18:00:00 2008 Michael Schwendt - 0.7.1-6 - Include /usr/include/gmyth-upnp directory gnome-backgrounds-2.23.91-1.fc10 -------------------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 gnome-desktop-2.23.91-1.fc10 ---------------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 gnome-doc-utils-0.13.1-1.fc10 ----------------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 0.13.1-1 - Update to 0.13.1 gnome-games-extra-data-2.24.0-1 ------------------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 gnome-icon-theme-2.23.91-1.fc10 ------------------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 gnome-libs-1.4.2-10.fc10 ------------------------ * Fri Aug 29 18:00:00 2008 Paul Howarth 1:1.4.2-10 - Use %patch0 rather than %patch in %prep - Fix patches to work without fuzz gnome-mag-0.15.3-1.fc10 ----------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 0.15.3-1 - Update to 0.15.3 gnome-media-2.23.91-1.fc10 -------------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen 2.23.91-1 - Update to 2.23.91 * Mon Sep 1 18:00:00 2008 - Bastien Nocera 2.23.3-4 - Update description (#448399) gnome-menus-2.23.91-1.fc10 -------------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 gnome-power-manager-2.23.91-1.fc10 ---------------------------------- * Mon Sep 1 18:00:00 2008 Richard Hughes - 2.23.91-1 - Update to 2.23.91, which should some translation issues. gnome-session-2.23.91-1.fc10 ---------------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 gnome-settings-daemon-2.23.91-1.fc10 ------------------------------------ * Mon Sep 1 18:00:00 2008 - Bastien Nocera - 2.23.91-1 - Update to 2.23.91 gnome-system-monitor-2.23.91-1.fc10 ----------------------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 gnome-terminal-2.23.91-1.fc10 ----------------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 gnome-themes-2.23.91-1.fc10 --------------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 gok-2.23.91-1.fc10 ------------------ * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 gq-1.3.4-2.fc10 --------------- * Mon Sep 1 18:00:00 2008 Terje R??sten - 1.3.4-2 - adapt to new rpm patch macro policy granule-1.4.0-7.fc10 -------------------- * Sun Aug 31 18:00:00 2008 Vladislav Grinchenko - 1.4.0-6 - Fix config files installation. gssdp-0.6.2-1.fc10 ------------------ * Sun Aug 31 18:00:00 2008 Peter Robinson 0.6.2-1 - New upstream version gstreamer-plugins-good-0.10.10-2.fc10 ------------------------------------- * Sun Aug 31 18:00:00 2008 Hans de Goede 0.10.10-2 - Fix gst-plugins-good-0.10.9-libv4l.patch to not only patch configure.ac but also configure so that the libv4l code actually gets enabled gtk2-engines-2.15.4-1.fc10 -------------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.15.4-1 - Update to 2.15.4 gtkdatabox-0.9.0.0-1.fc10 ------------------------- * Mon Sep 1 18:00:00 2008 Eric Work 0.9.0.0-1 - new upstream version - new gtk-doc documentation - fix deprecated GTK_SIGNAL_FUNC gtkhtml3-3.23.91-1.fc10 ----------------------- * Mon Sep 1 18:00:00 2008 Matthew Barnes - 3.23.91-1.fc10 - Update to 3.23.91 - Add -Werror to CFLAGS. gtksourceview2-2.3.2-1.fc10 --------------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.3.2-1 - Update to 2.3.2 gucharmap-2.23.91-1.fc10 ------------------------ * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 guidance-power-manager-4.1.1-1.fc10 ----------------------------------- * Fri Aug 29 18:00:00 2008 Than Ngo 4.1.1 -1 - 4.1.1 gvfs-0.99.6-1.fc10 ------------------ * Tue Sep 2 18:00:00 2008 Tomas Bzatek - 0.99.6-1 - Update to 0.99.6 gwget-0.99-8.fc10 ----------------- * Sat Aug 30 18:00:00 2008 Christoph Wickert - 0.99-8 - Rebuild against epiphany 2.23 and already prepare for 2.24 gzip-1.3.12-7.fc10 ------------------ * Mon Sep 1 18:00:00 2008 Ivana Varekova - 1.3.12-7 - update patches hal-0.5.11-4.fc10 ----------------- * Tue Sep 2 18:00:00 2008 Richard Hughes - 0.5.11-4 - Rebuild for new udev (libvolume_id) homebank-3.8-2.fc10 ------------------- * Sat Aug 30 18:00:00 2008 Johan Cwiklinski 3.8-2 - patch for gtk deprecated methods (thanks to zebob) htmldoc-1.8.27-7.fc10 --------------------- * Sat Aug 30 18:00:00 2008 Adam Goode - 1.8.27-7 - RPM 4.6 fix for patch tag ibus-0.1.1.20080901-1.fc10 -------------------------- * Mon Sep 1 18:00:00 2008 Huang Peng - 0.1.1.20080901-1 - Update to 0.1.1.20080901. ibus-anthy-0.1.1.20080901-1.fc10 -------------------------------- * Mon Sep 1 18:00:00 2008 Huang Peng - 0.1.1.20080901-1 - Update to 0.1.1.20080901. ibus-chewing-0.1.1.20080901-1.fc10 ---------------------------------- * Tue Sep 9 18:00:00 2008 Huang Peng - 0.1.1.20080901-1 - Update to 0.1.1.20080901. ibus-hangul-0.1.1.20080901-1.fc10 --------------------------------- * Tue Sep 9 18:00:00 2008 Huang Peng - 0.1.1.20080901-1 - Update to 0.1.1.20080901. ibus-m17n-0.1.1.20080901-1.fc10 ------------------------------- * Mon Sep 1 18:00:00 2008 Huang Peng - 0.1.1.20080901-1 - Update to 0.1.1.20080901. ibus-pinyin-0.1.1.20080901-1.fc10 --------------------------------- * Mon Sep 1 18:00:00 2008 Huang Peng - 0.1.1.20080901-1 - Update version to 0.1.1.20080901. ibus-table-0.1.1.20080901-1.fc10 -------------------------------- * Mon Sep 1 18:00:00 2008 Huang Peng - 0.1.1.20080901-1 - Update to 0.1.1.20080901. ikarus-0.0.3-2.fc10 ------------------- * Mon Sep 1 18:00:00 2008 Michel Salim - 0.0.3-2 - Own documentation directory ikiwiki-2.62.1-1.fc10 --------------------- * Sat Aug 30 18:00:00 2008 Thomas Moschny - 2.62.1-1 - Update to 2.62.1. Add /etc/ikiwiki. iptraf-3.0.1-6.fc10 ------------------- * Tue Sep 2 18:00:00 2008 Zdenek Prikryl - 3.0.1-6 - Minor fixes in patches ipv6, incltypes and ifname irsim-9.7.68-1.fc10 ------------------- * Fri Aug 15 18:00:00 2008 Chitlesh Goorah - 9.7.68-1 - new upstream release 9.7.68 javasqlite-20080420-3.fc10 -------------------------- * Mon Sep 1 18:00:00 2008 Ville Skytt?? - 20080420-3 - Include JDBC 3 (Java 1.5.x) drivers. - Work around build setup issues #460761 and #460783. * Sun Aug 31 18:00:00 2008 Ville Skytt?? - 20080420-2 - Patch to output error message if loading the lib from a specified SQLite.library.path fails. - Patch test suite to exit with non-zero status on failures. - Run more tests during build, but not SQLite 2.x ones. jd-2.0.1-0.2.beta080901.fc10 ---------------------------- * Tue Sep 2 18:00:00 2008 Mamoru Tasaka - 2.0.1-0.2.beta080901 - 2.0.1 beta 080901 - Change default config in Fedora fonts: use Mona-VLGothic browser: use xdg-open joni-1.0.3-1.fc10 ----------------- * Sun Aug 31 18:00:00 2008 Conrad Meyer - 1.0.3-1 - Official 1.0.3 release. jpilot-1.6.0-2.fc10 ------------------- * Tue Sep 2 18:00:00 2008 Ivana Varekova - 1.6.0-2 - update patches kde-l10n-4.1.1-1.fc10 --------------------- * Fri Aug 29 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 kdeaccessibility-4.1.1-1.fc10 ----------------------------- * Fri Aug 29 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 kdeadmin-4.1.1-1.fc10 --------------------- * Fri Aug 29 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 kdeartwork-4.1.1-1.fc10 ----------------------- * Fri Aug 29 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 kdebase-runtime-4.1.1-2.fc10 ---------------------------- * Mon Sep 1 18:00:00 2008 Than Ngo 4.1.1-2 - fix #460710, knetattach is kio_remote's wizard program, don't show it in the menu. * Thu Aug 28 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 kdebase-workspace-4.1.1-2.fc10 ------------------------------ * Mon Sep 1 18:00:00 2008 Kevin Kofler 4.1.1-2 - show KCM icon in rootprivs patch (thanks to Harald Sitter "apachelogger") * Thu Aug 28 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 kdebindings-4.1.1-1.fc10 ------------------------ * Fri Aug 29 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 kdelibs-4.1.1-3.fc10 -------------------- * Mon Sep 1 18:00:00 2008 Than Ngo 4.1.1-3 - respun kdepimlibs-4.1.1-1.fc10 ----------------------- * Thu Aug 28 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 kdevelop-3.5.3-1.fc10 --------------------- * Sat Aug 30 18:00:00 2008 Kevin Kofler - 9:3.5.3-1 - update to 3.5.3 - drop svn patch (fixed upstream) kdewebdev-3.5.10-1.fc10 ----------------------- * Sat Aug 30 18:00:00 2008 Kevin Kofler - 6:3.5.10-1 - update to 3.5.10 kernel-2.6.27-0.297.rc5.git2.fc10 --------------------------------- * Tue Sep 2 18:00:00 2008 Kyle McMartin - hopefully fix the iwlwifi issues. - add an include to drm-nouveau to hopefully fix the build on powerpc64. * Tue Sep 2 18:00:00 2008 Dave Airlie - bring back nouveau yet again * Mon Sep 1 18:00:00 2008 Dave Jones - Always inline kzalloc. And drop busted rcu debug patch * Sat Aug 30 18:00:00 2008 Dave Jones - 2.6.27-rc5-git2 * Fri Aug 29 18:00:00 2008 Kristian H??gsberg - Fix a couple of merge bugs between DRI2 and KMS. * Fri Aug 29 18:00:00 2008 Dave Jones - 2.6.27-rc5-git1 * Fri Aug 29 18:00:00 2008 Chuck Ebbert - x86: add Presario F700 to io_delay quirk list. (F9#459546) kinput2-v3.1-39.fc10 -------------------- * Tue Sep 2 18:00:00 2008 Akira TAGOH - v3.1-39 - Fix a value type of lineSpace attribute. (#458650) klear-0.7.0-2.svn113.fc10 ------------------------- * Sat Aug 30 18:00:00 2008 Johan Cwiklinski - 0.7.0-2.svn113 - add a patch fo scons Chmod error - fix headers conflict (bz #440755) libbtctl-0.10.0-3.fc10 ---------------------- * Mon Sep 1 18:00:00 2008 Jiri Moskovcak - 0.10.0-3 - made doc subpackage to avoid conflict on multiarch env. - Resolves: #341931 libdvdnav-4.1.3-0.4.rc1.fc10 ---------------------------- * Sun Aug 31 18:00:00 2008 Dominik Mierzejewski 4.1.3-0.4.rc1 - update to 4.1.3rc1 - require libdvdread with fixed API libdvdread-4.1.3-0.3.rc1.fc10 ----------------------------- * Sun Aug 31 18:00:00 2008 Dominik Mierzejewski 4.1.3-0.3.rc1 - update to 4.1.3rc1 - fix include path libgnomecanvasmm26-2.23.1-1.fc10 -------------------------------- * Fri Aug 29 18:00:00 2008 Denis Leroy - 2.23.1-1 - Update to upstream 2.23.1 libgweather-2.23.91-1.fc10 -------------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen 2.23.91-1 - Update to 2.23.91 libical-0.32-1.fc10 ------------------- * Wed Sep 3 18:00:00 2008 Debarshi Ray - 0.32-1 - Version bump to 0.32. - Parallel build problems fixed. libnetfilter_log-0.0.14-3.fc10 ------------------------------ * Fri Aug 29 18:00:00 2008 Michael Schwendt - 0.0.14-3 - include /usr/include/libnetfilter_log directory libsoup-2.23.91-1.fc10 ---------------------- * Mon Sep 1 18:00:00 2008 Matthew Barnes - 2.23.91-1 - Update to 2.23.91 libv4l-0.4.2-1.fc10 ------------------- * Fri Aug 29 18:00:00 2008 Hans de Goede 0.4.2-1 - New upstream release 0.4.2 libwnck-2.23.91-1.fc10 ---------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 libxml2-2.7.1-1.fc10 -------------------- * Mon Sep 1 18:00:00 2008 Daniel Veillard 2.7.1-1.fc10 - fix python serialization which was broken in 2.7.0 - Resolve: rhbz#460774 * Sat Aug 30 18:00:00 2008 Daniel Veillard 2.7.0-1.fc10 - upstream release of 2.7.0 - switch to XML 1.0 5th edition - switch to RFC 3986 for URI parsing - better entity handling - option to remove hardcoded limitations in the parser - more testing - a new API to allocate entity nodes - and lot of fixes and clanups * Mon Aug 25 18:00:00 2008 Daniel Veillard 2.6.32-4.fc10 - fix for entities recursion problem - Resolve: rhbz#459714 lsdvd-0.16-10.fc10 ------------------ * Tue Sep 2 18:00:00 2008 Matthias Saou 0.16-10 - Update build patch for new s/dvdread/libdvdread/ include path. - Actually, drop patch entirely as latest libdvdread changes the path back and seems to include a fix for the missing include. man-1.6f-9.fc10 --------------- * Mon Sep 1 18:00:00 2008 Ivana Varekova - 1.6f-9 - update patches maxima-5.16.3-2.fc10 -------------------- * Tue Sep 2 18:00:00 2008 Rex Dieter - 5.16.3-2 - respin (sbcl) mc-4.6.2-6.pre1.fc10 -------------------- * Tue Sep 2 18:00:00 2008 Jindrich Novy 4.6.2-6.pre1 - do not change directory in panel to subshell directory when switched back from subshell (#460633) metacity-2.23.233-1.fc10 ------------------------ * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.233-1 - Update to 2.23.233 mlton-20070826-13.fc10 ---------------------- * Sat Aug 30 18:00:00 2008 Adam Goode - 20070826-13 - RPM 4.6 fix for patch tag - Update LaTeX build requires mono-2.0-5.fc10 --------------- * Fri Aug 29 18:00:00 2008 Paul F. Johnson 2.0-5 - moved libMonoPosixHelper back to the main package mousetweaks-2.23.91-1.fc10 -------------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 mozvoikko-0.9.5-2.fc10 ---------------------- * Sat Aug 30 18:00:00 2008 Ville-Pekka Vainio - 0.9.5-2 - Fix the xulrunner requires: - Add define gecko_ver 1.9.0.1 - Add Requires: gecko-libs = gecko_ver - Add BuildRequires: gecko-devel-unstable = gecko_ver - Remove all actual xulrunner requires - Redo the Makefile.xulrunner includes patch, we only need the stable and unstable header dirs in Fedora mtr-0.73-2.fc10 --------------- * Tue Sep 2 18:00:00 2008 Zdenek Prikryl - 2:0.73-2 - Minor fix in the patch underflow mythes-de-0.20080901-1.fc10 --------------------------- * Mon Sep 1 18:00:00 2008 Caolan McNamara - 0.20080901-1 - latest version namazu-2.0.18-5.fc10 -------------------- * Mon Sep 1 18:00:00 2008 Akira TAGOH - 2.0.18-5 - Update patch to fix a fuzz issue. nautilus-2.23.90-4.fc10 ----------------------- * Sat Aug 30 18:00:00 2008 Matthias Clasen - 2.23.90-4 - Plug a few small memory leaks * Thu Aug 28 18:00:00 2008 Matthias Clasen - 2.23.90-3 - Pull in split-off gvfs backends ncftp-3.2.2-1.fc10 ------------------ * Fri Aug 29 18:00:00 2008 Matthias Saou 2:3.2.2-1 - Update to 3.2.2. - Include no_lfs64_source from Gentoo to fix the build. nexuiz-2.4.2-3.fc10 ------------------- * Tue Sep 2 18:00:00 2008 Jon Ciesla - 2.4.2-3 - Fix .desktop category, BZ 460785. nip2-7.14.5-1.fc10 ------------------ * Sat Aug 30 18:00:00 2008 Adam Goode - 7.14.5-1 - New release - RPM 4.6 fix for patch tag ocaml-camlp5-5.09-1.fc10 ------------------------ * Sun Aug 31 18:00:00 2008 Richard W.M. Jones - 5.09-1 - New upstream version 5.09. ocaml-cil-1.3.6-7.fc10 ---------------------- * Tue Sep 2 18:00:00 2008 Richard W.M. Jones - 1.3.6-7 - Prevent unwanted bytecode stripping by RPM and prelink. - Place *.ml files into the -devel subpackage. ocaml-cryptokit-1.3-5.fc10 -------------------------- * Tue Sep 2 18:00:00 2008 Richard W.M. Jones - 1.3-5 - Install in cryptokit subdirectory. - Include a META file (from Debian) (resolves rhbz#460844). ocaml-curl-0.5.0-1.fc10 ----------------------- * Sun Aug 31 18:00:00 2008 Richard W.M. Jones - 0.5.0-1 - New upstream release 0.5.0. ocaml-dbus-0.07-1.fc10 ---------------------- * Sun Aug 31 18:00:00 2008 Richard W.M. Jones - 0.07-1 - New upstream release 0.07. - Remove rpath from shared object. ocaml-findlib-1.2.2-1.fc10 -------------------------- * Sun Aug 31 18:00:00 2008 Richard W.M. Jones - 1.2.2-1 - New upstream version 1.2.2. - Strip ocamlfind binary. - Remove zero-length file. ocaml-lacaml-4.3.3-1.fc10 ------------------------- * Sun Aug 31 18:00:00 2008 Richard W.M. Jones - 4.3.3-1 - New upstream version 4.3.3. ocaml-ocamlnet-2.2.9-7.fc10 --------------------------- * Tue Sep 2 18:00:00 2008 Richard W.M. Jones - 2.2.9-7 - Prevent RPM & prelink from stripping bytecode. ocaml-ounit-1.0.3-1.fc10 ------------------------ * Sun Aug 31 18:00:00 2008 Richard W.M. Jones - 1.0.3-1 - New upstream version 1.0.3. ocaml-pcre-5.15.0-1.fc10 ------------------------ * Sun Aug 31 18:00:00 2008 Richard W.M. Jones - 5.15.0-1 - New upstream release 5.15.0. ocaml-res-2.2.6-1.fc10 ---------------------- * Sun Aug 31 18:00:00 2008 Richard W.M. Jones - 2.2.6-1 - New upstream version 2.2.6. ocaml-sexplib-4.0.1-1.fc10 -------------------------- * Sun Aug 31 18:00:00 2008 Richard W.M. Jones - 4.0.1-1 - New upstream release 4.0.1. - Patch a build problem in the test suite. - ml file should be packaged in the -devel subpackage, not in main. ocaml-sqlite-1.2.0-1.fc10 ------------------------- * Sun Aug 31 18:00:00 2008 Richard W.M. Jones - 1.2.0-1 - New upstream version 1.2.0. ocaml-type-conv-1.6.1-1.fc10 ---------------------------- * Sun Aug 31 18:00:00 2008 Richard W.M. Jones - 1.6.1-1 - New upstream version 1.6.1. odt2txt-0.4-1.fc10 ------------------ * Sun Aug 31 18:00:00 2008 Michel Salim - 0.4-1 - Update to 0.4 online-desktop-0.3.0-1.fc10 --------------------------- * Tue Sep 2 18:00:00 2008 Owen Taylor - 0.3.0-1 - Update to 0.3.0 openct-0.6.15-1.fc10 -------------------- * Tue Sep 2 18:00:00 2008 Tomas Mraz - 0.6.15-1 - Update to latest upstream openldap-2.4.11-2.fc10 ---------------------- * Mon Sep 1 18:00:00 2008 Jan Safranek 2.4.11-2 - provide ldif2ldbm functionality for migrationtools - rediff all patches to get rid of patch fuzz openoffice.org-3.0.0-4.1.fc10 ----------------------------- * Fri Aug 29 18:00:00 2008 Caol??n McNamara - 1:3.0.0-4.1 - next milestone - writer2latex isn't really core enough to be hard required - smc-fonts-meera is a far better font than lohit-fonts-malayalam - Resolves: rhbz#460626 openoffice.org-3.0.0.ooo91924.svx.consistentordering.patch opensc-0.11.6-1.fc10 -------------------- * Tue Sep 2 18:00:00 2008 Tomas Mraz - 0.11.6-1 - Update to latest upstream, fixes CVE-2008-2235 * Thu Apr 10 18:00:00 2008 Hans de Goede - 0.11.4-5 - BuildRequire libassuan-devel instead of libassuan-static (bz 441812) orca-2.23.91-1.fc10 ------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 paps-0.6.8-7.fc10 ----------------- * Mon Sep 1 18:00:00 2008 Akira TAGOH - 0.6.8-7 - paps-langinfo.patch: Updated. - paps-exitcode.patch: Updated. pciutils-3.0.0-2.fc10 --------------------- * Mon Sep 1 18:00:00 2008 Harald Hoyer 3.0.0-2 - rebuild to eliminate fuzz patches perl-Config-Augeas-0.301-2.fc10 ------------------------------- * Mon Sep 1 18:00:00 2008 Alan Pevec 0.301-2 - fix test failure * Mon Sep 1 18:00:00 2008 Alan Pevec 0.301-1 - new upstream release 0.301 * lib/Config/Augeas.pm (move): New method for Augeas 0.3.0 aug_mv function. 'move' can also be called with 'mv' perl-IO-Socket-SSL-1.15-1.fc10 ------------------------------ * Sat Aug 30 18:00:00 2008 Paul Howarth - 1.15-1 - Update to latest upstream version: 1.15 - Add buildreq and req for perl(Net::LibIDN) to avoid croaking when trying to verify an international name against a certificate php-pear-HTTP-1.4.1-1.fc10 -------------------------- * Mon Sep 1 18:00:00 2008 Remi Collet 1.4.1-1 - update to 1.4.1 - add tests picard-0.10-2.fc10 ------------------ * Tue Sep 2 18:00:00 2008 Alex Lancaster - 0.10-2 - Update plugin versions to 0.10 where possible. - Temporarily disable the search plugins until they are ported to new API. * Sun Aug 31 18:00:00 2008 Alex Lancaster - 0.10-1 - Update to latest upstream (0.10). - Add patch to work around broken setup.py. - Fixed some spec file errors: duplicate sources. pidgin-2.5.1-1.fc10 ------------------- * Sun Aug 31 18:00:00 2008 Stu Tomlinson 2.5.1-1 - 2.5.1 plague-0.4.5-1.fc10 ------------------- * Tue Sep 2 18:00:00 2008 Dennis Gilmore - 0.4.5-1 - update to 0.4.5 lots of fixes * Thu May 22 18:00:00 2008 Seth Vidal - 0.4.4.1-6 - licensing tag fix * Tue Sep 18 18:00:00 2007 Michael Schwendt - 0.4.4.1-5 - Add dirs /etc/plague and /usr/share/plague to plague-common since "plague-builder" and "plague" use them (#233904). pnp4nagios-0.4.10-3.fc10 ------------------------ * Tue Sep 2 18:00:00 2008 Xavier Bachelot 0.4.10-3 - Fix logrotate conf (RHBZ#460861). procps-3.2.7-21.fc10 -------------------- * Mon Sep 1 18:00:00 2008 Tomas Smetana 3.2.7-21 - rebase patches - clear screen in top when switching windows - fix #435453 - errors with man -t formatting of ps man page pwlib-1.10.10-10.fc10 --------------------- * Sat Aug 30 18:00:00 2008 Hans de Goede 1.10.10-10 - Add patch to use libv4l to support webcams which generate custom video formats (bz 456868) pygobject2-2.15.3-1.fc10 ------------------------ * Sun Aug 31 18:00:00 2008 Matthew Barnes - 2.15.3-1.fc10 - Update to 2.15.3 python-GeoIP-1.2.2-1.fc10 ------------------------- * Sun Aug 31 18:00:00 2008 Michael Fleming 1.2.2-1 - Update to 1.2.2 - Drop ccodes patch as it's been accepted upstream - Change of license to LGPL python-nevow-0.9.31-1.fc10 -------------------------- * Tue Sep 2 18:00:00 2008 Matthias Saou 0.9.31-1 - Update to 0.9.31 (seems to fix tracebacks with Twisted 8). - Remove no longer included NEWS.txt. qmmp-0.2.2-1.fc10 ----------------- * Tue Sep 2 18:00:00 2008 Karel Volny 0.2.2-1 - new version ragel-6.3-1.fc10 ---------------- * Sat Aug 30 18:00:00 2008 Jeremy Hinegardner - 6.3-1 - update to 6.3 rarian-0.8.1-1.fc10 ------------------- * Mon Sep 1 18:00:00 2008 Matthew Barnes - 0.8.1-1 - Update to 0.8.1 * Sun May 4 18:00:00 2008 Matthias Clasen - 0.8.0-2 - Fix source url referencer-1.1.4-1.fc10 ----------------------- * Sat Aug 30 18:00:00 2008 Deji Akingunola - 1.1.4-1 - Update to latest release rlog-1.4-2.fc10 --------------- * Tue Sep 2 18:00:00 2008 Peter Lemenkov 1.4-2 - Fix build for F-8 - Fixed license header (LGLV21+ -> LGPLv2+) rpm-4.5.90-0.git8461.4 ---------------------- * Mon Sep 1 18:00:00 2008 Jindrich Novy - fix parsing of boolean expressions in spec (#456103) (unbreaks pam, jpilot and maybe other builds) rsyslog-3.21.3-3.fc10 --------------------- * Mon Sep 1 18:00:00 2008 Tomas Heinrich 3.21.3-3 - fix a wrong module name in the rsyslog.conf manual page (#455086) - expand the rsyslog.conf manual page (#456030) sbcl-1.0.20-1.fc10 ------------------ * Tue Sep 2 18:00:00 2008 Rex Dieter - 1.0.20-1 - sbcl-1.0.20 scummvm-0.12.0-1.fc10 --------------------- * Mon Sep 1 18:00:00 2008 Lucian Langa - 0.12.0-1 - new upstream 0.12.0 - drop 0.11.0 patches (fixed upstream) - drop 0.9.0 patch (fixed upstream) shadow-utils-4.1.2-6.fc10 ------------------------- * Tue Sep 2 18:00:00 2008 Peter Vrabec 2:4.1.2-6 - audit improvements, thnx. to sgrubb at redhat.com * Tue Sep 2 18:00:00 2008 Peter Vrabec 2:4.1.2-5 - fix groupmems issues (#459825) shared-mime-info-0.51-2.fc10 ---------------------------- * Mon Sep 1 18:00:00 2008 - Bastien Nocera - 0.51-2 - Use Firefox and not redhat-web as the default app for HTML files (#452184) sip-4.7.7-2.fc10 ---------------- * Tue Sep 2 18:00:00 2008 Than Ngo 4.7.7-2 - get rid of BR on qt soundconverter-1.3.2-1.fc10 --------------------------- * Mon Aug 25 18:00:00 2008 Denis Leroy - 1.3.2-1 - Update to upstream 1.3.2 - Fixed gnome-python2 BR sugar-toolkit-0.82.5-2.fc10 --------------------------- * Mon Sep 1 18:00:00 2008 Simon Schampijer - 0.82.5-2 - added the python-json dependency * Mon Sep 1 18:00:00 2008 Simon Schampijer - 0.82.5-1 - Translation updates - Add plural information for all languages - Fix plural form equations * Sun Aug 31 18:00:00 2008 Simon Schampijer - 0.82.4-1 - 8136 Do a more 'standard' system installation for bundlebuilder - 7837 Do not try to list the mimetypes directory if it does not exist - 8220 Ensure that the widget is fully onscreen before taking a screenshot system-config-printer-1.0.7-2.fc10 ---------------------------------- * Sat Aug 30 18:00:00 2008 Tim Waugh 1.0.7-2 - Handle IPP_FORBIDDEN (bug #460670). tinyerp-4.2.2-4.fc10 -------------------- * Mon Sep 1 18:00:00 2008 Dan Horak 4.2.2-4 - add patch for PostgreSQL 8.3 compatibility (from Pieter. J. Kersten) tinyproxy-1.6.4-2.fc10 ---------------------- * Sun Aug 24 18:00:00 2008 Jeremy Hinegardner - 1.6.4-2 - update to upstream 1.6.4 final * Sun Jun 22 18:00:00 2008 Jeremy Hinegardner - 1.6.4-1 - update to upstream candidate 1.6.4 totem-2.23.91-2.fc10 -------------------- * Mon Sep 1 18:00:00 2008 - Bastien Nocera - 2.23.91-2 - Remove unneeded scrollkeeper BR (#460344) tree-1.5.2.1-1.fc10 ------------------- * Tue Sep 2 18:00:00 2008 Tim Waugh 1.5.2.1-1 - Removed patch fuzz. - 1.5.2.1. udev-127-1.fc10 --------------- * Mon Sep 1 18:00:00 2008 Harald Hoyer 127-1 - version 127 up-imapproxy-1.2.6-2.fc10 ------------------------- * Thu Aug 28 18:00:00 2008 Rakesh Pandit 1.2.6-2 - fixed initscript to follow guidelines * Thu Aug 28 18:00:00 2008 Rakesh Pandit 1.2.6-1 - Update to 1.2.6 - Remove old patches (already upstream), Remove README.known_issues - Tidy init script (Tim Jackson) vinagre-2.23.91-1.fc10 ---------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 vino-2.23.91-1.fc10 ------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 vips-7.14.5-1.fc10 ------------------ * Sat Aug 30 18:00:00 2008 Adam Goode - 7.14.5-1 - New release waf-1.4.4-1.fc10 ---------------- * Sun Aug 31 18:00:00 2008 Thomas Moschny - 1.4.4-1 - Update to 1.4.4: - python 2.3 compatibility was restored - task randomization was removed - the vala tool was updated wavpack-4.50.1-2.fc10 --------------------- * Sat Aug 30 18:00:00 2008 Peter Lemenkov 4.50.1-2 - Fixes to meet the Fedora Packaging Guidelines wdaemon-0.15-1.fc10 ------------------- * Tue Sep 2 18:00:00 2008 Aristeu Rozanski 0.15-1 - updated to version 0.15 * Wed May 21 18:00:00 2008 Tom "spot" Callaway 0.14-2 - fix license tag * Wed Mar 12 18:00:00 2008 Aristeu Rozanski 0.14-1 - Updated to version 0.14 - Added fix for Z axis on newer tablets xenner-0.43-1.fc10 ------------------ * Mon Sep 1 18:00:00 2008 Gerd Hoffmann - 0.43-1.fc10 - update to version 0.43 xfce4-places-plugin-1.1.0-3.fc10 -------------------------------- * Sun Aug 31 18:00:00 2008 Christoph Wickert - 1.1.0-3 - Update xdg-userdir-compat.patch to use upstream's variable names xfdesktop-4.4.2-6.fc10 ---------------------- * Sun Aug 31 18:00:00 2008 Christoph Wickert - 4.4.2-6 - Update xdg-userdir-compat.patch to use upstream's variable names xgridfit-1.9-1.fc10 ------------------- * Mon Sep 1 18:00:00 2008 - 1.9-1 ??? Major update, many changes ??? Only package xsltproc support for now xmms-1.2.11-1.20071117cvs.fc10 ------------------------------ * Tue Sep 2 18:00:00 2008 Paul F. Johnson 1.2.11-20071117cvs-1 - Bump to 1.2.11 devel branch - Alter license - Removed unused patches - Fixed old patches to work with new version xmms-modplug-2.05-13.fc10 ------------------------- * Sat Aug 30 18:00:00 2008 Ville Skytt?? - 2.05-13 - Unfuzz patches. xorg-x11-drv-nouveau-0.0.11-1.20080902git6dd8ad4.fc10 ----------------------------------------------------- * Tue Sep 2 18:00:00 2008 Dave Airlie 0.0.11-1.20080902git6dd8ad4 - update to snapshot with new kernel interface 0.0.11 xorg-x11-drv-synaptics-0.15.0-4.fc10 ------------------------------------ * Tue Sep 2 18:00:00 2008 Peter Hutterer 0.15.0-4 - xf86-input-synaptics-0.15.0-dont-lose-buttonup.patch: force a click if middle button emulation times out during ReadInput cycle. RH #233717. yanone-kaffeesatz-fonts-20080723-1.fc10 --------------------------------------- * Mon Sep 1 18:00:00 2008 - 20080723-1 ??? Upstream stealth update yelp-2.23.91-1.fc10 ------------------- * Mon Sep 1 18:00:00 2008 Matthew Barnes - 2.23.91-1 - Update to 2.23.91 Summary: Added Packages: 17 Removed Packages: 0 Modified Packages: 214 Broken deps for i386 ---------------------------------------------------------- audacious-plugins-1.5.1-1.fc10.i386 requires libmtp.so.7 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 gfs-utils-2.99.08-1.fc10.i386 requires libvolume_id.so.0 gfs2-utils-2.99.08-1.fc10.i386 requires libvolume_id.so.0 grisbi-0.5.9-5.fc9.i386 requires tetex-unicode gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.11-1.fc10.i386 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.i386 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.i386 requires perl(MT::Entry) highlight-2.6.11-1.fc10.i386 requires perl(MT) highlight-2.6.11-1.fc10.i386 requires perl(MT::Template::Context) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 namazu-2.0.18-5.fc10.i386 requires perl(codeconv.pl) namazu-2.0.18-5.fc10.i386 requires perl(filter.pl) namazu-2.0.18-5.fc10.i386 requires perl(ooo.pl) namazu-2.0.18-5.fc10.i386 requires perl(mailnews.pl) namazu-2.0.18-5.fc10.i386 requires perl(zip.pl) namazu-2.0.18-5.fc10.i386 requires perl(html.pl) namazu-2.0.18-5.fc10.i386 requires perl(gfilter.pl) namazu-2.0.18-5.fc10.i386 requires perl(gettext.pl) perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so poker3d-1.1.36-10.fc10.i386 requires libosg.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgUtil.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgSim.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgTerrain.so.35 poker3d-1.1.36-10.fc10.i386 requires libOpenThreads.so.10 poker3d-1.1.36-10.fc10.i386 requires libosgGA.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgFX.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgManipulator.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgDB.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgParticle.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgViewer.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgText.so.35 qpidc-0.2.667603-2.fc10.i386 requires libxqilla.so.3 qpidc-perftest-0.2.667603-2.fc10.i386 requires libxqilla.so.3 qpidd-0.2.667603-2.fc10.i386 requires libxqilla.so.3 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for x86_64 ---------------------------------------------------------- audacious-plugins-1.5.1-1.fc10.x86_64 requires libmtp.so.7()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) gfs-utils-2.99.08-1.fc10.x86_64 requires libvolume_id.so.0()(64bit) gfs2-utils-2.99.08-1.fc10.x86_64 requires libvolume_id.so.0()(64bit) grisbi-0.5.9-5.fc9.x86_64 requires tetex-unicode gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Entry) highlight-2.6.11-1.fc10.x86_64 requires perl(MT) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Template::Context) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 namazu-2.0.18-5.fc10.x86_64 requires perl(filter.pl) namazu-2.0.18-5.fc10.x86_64 requires perl(ooo.pl) namazu-2.0.18-5.fc10.x86_64 requires perl(mailnews.pl) namazu-2.0.18-5.fc10.x86_64 requires perl(zip.pl) namazu-2.0.18-5.fc10.x86_64 requires perl(codeconv.pl) namazu-2.0.18-5.fc10.x86_64 requires perl(html.pl) namazu-2.0.18-5.fc10.x86_64 requires perl(gfilter.pl) namazu-2.0.18-5.fc10.x86_64 requires perl(gettext.pl) perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgFX.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgGA.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgTerrain.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosg.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgSim.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgText.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgDB.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libOpenThreads.so.10()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgManipulator.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgParticle.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgViewer.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgUtil.so.35()(64bit) qpidc-0.2.667603-2.fc10.i386 requires libxqilla.so.3 qpidc-0.2.667603-2.fc10.x86_64 requires libxqilla.so.3()(64bit) qpidc-perftest-0.2.667603-2.fc10.x86_64 requires libxqilla.so.3()(64bit) qpidd-0.2.667603-2.fc10.i386 requires libxqilla.so.3 qpidd-0.2.667603-2.fc10.x86_64 requires libxqilla.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for ppc ---------------------------------------------------------- audacious-plugins-1.5.1-1.fc10.ppc requires libmtp.so.7 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gfs-utils-2.99.08-1.fc10.ppc requires libvolume_id.so.0 gfs2-utils-2.99.08-1.fc10.ppc requires libvolume_id.so.0 grisbi-0.5.9-5.fc9.ppc requires tetex-unicode gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.11-1.fc10.ppc requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc requires perl(MT::Entry) highlight-2.6.11-1.fc10.ppc requires perl(MT) highlight-2.6.11-1.fc10.ppc requires perl(MT::Template::Context) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 namazu-2.0.18-5.fc10.ppc requires perl(codeconv.pl) namazu-2.0.18-5.fc10.ppc requires perl(filter.pl) namazu-2.0.18-5.fc10.ppc requires perl(ooo.pl) namazu-2.0.18-5.fc10.ppc requires perl(mailnews.pl) namazu-2.0.18-5.fc10.ppc requires perl(zip.pl) namazu-2.0.18-5.fc10.ppc requires perl(html.pl) namazu-2.0.18-5.fc10.ppc requires perl(gfilter.pl) namazu-2.0.18-5.fc10.ppc requires perl(gettext.pl) perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so poker3d-1.1.36-10.fc10.ppc requires libosg.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgUtil.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgSim.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgTerrain.so.35 poker3d-1.1.36-10.fc10.ppc requires libOpenThreads.so.10 poker3d-1.1.36-10.fc10.ppc requires libosgGA.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgFX.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgManipulator.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgDB.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgParticle.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgViewer.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgText.so.35 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires libbfd-2.18.50.0.8-2.fc10.so stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires libopcodes-2.18.50.0.8-2.fc10.so vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for ppc64 ---------------------------------------------------------- audacious-plugins-1.5.1-1.fc10.ppc64 requires libmtp.so.7()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gfs-utils-2.99.08-1.fc10.ppc64 requires libvolume_id.so.0()(64bit) gfs2-utils-2.99.08-1.fc10.ppc64 requires libvolume_id.so.0()(64bit) grisbi-0.5.9-5.fc9.ppc64 requires tetex-unicode gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Entry) highlight-2.6.11-1.fc10.ppc64 requires perl(MT) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Template::Context) livecd-tools-018-1.fc10.ppc64 requires yaboot mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 namazu-2.0.18-5.fc10.ppc64 requires perl(filter.pl) namazu-2.0.18-5.fc10.ppc64 requires perl(ooo.pl) namazu-2.0.18-5.fc10.ppc64 requires perl(mailnews.pl) namazu-2.0.18-5.fc10.ppc64 requires perl(zip.pl) namazu-2.0.18-5.fc10.ppc64 requires perl(codeconv.pl) namazu-2.0.18-5.fc10.ppc64 requires perl(html.pl) namazu-2.0.18-5.fc10.ppc64 requires perl(gfilter.pl) namazu-2.0.18-5.fc10.ppc64 requires perl(gettext.pl) perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 poker3d-1.1.36-10.fc10.ppc64 requires libosgFX.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgGA.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgTerrain.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosg.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgSim.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgText.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgDB.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libOpenThreads.so.10()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgManipulator.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgParticle.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgViewer.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgUtil.so.35()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 From triad at df.lth.se Wed Sep 3 12:30:48 2008 From: triad at df.lth.se (Linus Walleij) Date: Wed, 3 Sep 2008 14:30:48 +0200 (CEST) Subject: wtf ... Something strips installed binaries??? In-Reply-To: <20080902095712.GB483@amd.home.annexia.org> References: <20080902080150.GA483@amd.home.annexia.org> <20080902094855.GC29748@redhat.com> <20080902095712.GB483@amd.home.annexia.org> Message-ID: On Tue, 2 Sep 2008, Richard W.M. Jones wrote: > But is it /usr/bin/strip? Does prelink run /usr/bin/strip first? Do > prelink and strip use a common ELF-manipulation library which is at > fault? I bet both use libbfd from the binutils, strip surely does and prelink is statically linked so I cannot see right now. So the bug would be in binutils. Linus From triad at df.lth.se Wed Sep 3 12:31:24 2008 From: triad at df.lth.se (Linus Walleij) Date: Wed, 3 Sep 2008 14:31:24 +0200 (CEST) Subject: wtf ... Something strips installed binaries??? In-Reply-To: <20080902095712.GB483@amd.home.annexia.org> References: <20080902080150.GA483@amd.home.annexia.org> <20080902094855.GC29748@redhat.com> <20080902095712.GB483@amd.home.annexia.org> Message-ID: On Tue, 2 Sep 2008, Richard W.M. Jones wrote: > But is it /usr/bin/strip? Does prelink run /usr/bin/strip first? Do > prelink and strip use a common ELF-manipulation library which is at > fault? I bet both use libbfd from the binutils, strip surely does and prelink is statically linked so I cannot see right now. So the bug would be in binutils. Linus From triad at df.lth.se Wed Sep 3 12:33:41 2008 From: triad at df.lth.se (Linus Walleij) Date: Wed, 3 Sep 2008 14:33:41 +0200 (CEST) Subject: wtf ... Something strips installed binaries??? In-Reply-To: <20080902095712.GB483@amd.home.annexia.org> References: <20080902080150.GA483@amd.home.annexia.org> <20080902094855.GC29748@redhat.com> <20080902095712.GB483@amd.home.annexia.org> Message-ID: On Tue, 2 Sep 2008, Richard W.M. Jones wrote: > But is it /usr/bin/strip? Does prelink run /usr/bin/strip first? Do > prelink and strip use a common ELF-manipulation library which is at > fault? I bet both use libbfd from the binutils, strip surely does and prelink is statically linked so I cannot see right now. So the bug would be in binutils. Linus From jnovy at redhat.com Wed Sep 3 12:41:32 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 3 Sep 2008 14:41:32 +0200 Subject: rawhide report: 20080829 changes In-Reply-To: <1220214626.29094.13.camel@luminos.localdomain> References: <20080829195754.07B211F8248@releng2.fedora.phx.redhat.com> <1220044676.9554.26.camel@luminos.localdomain> <20080831191730.GA7646@dhcp-lab-186.brq.redhat.com> <1220214626.29094.13.camel@luminos.localdomain> Message-ID: <20080903124132.GB30583@dhcp-lab-186.brq.redhat.com> On Sun, Aug 31, 2008 at 01:30:26PM -0700, Jesse Keating wrote: > On Sun, 2008-08-31 at 21:17 +0200, Jindrich Novy wrote: > > > Kernel works around this by having an additional build put through of > > > arch "noarch", which is a setting at the koji level. We only ever get > > > one set of noarch build output. > > > > Would it be possible to teach koji the noarch subpackage paradigm so > > that only one build is made? Maybe koji could then collect all the > > binary rpms including noarchs and then compare contents of noarchs for all > > arches. If the contents are same the build would pass otherwise fail. > > I don't think that will be possible. We might be able to just import > the first produced noarch subpackage and skip all the others. This could be the easiest way to go. Packager would then be responsible for differences if the content of noarch subpackage is dependent on builder arch and affects somehow binary package functionality or e.g. generated documentation. Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From drepper at redhat.com Wed Sep 3 14:24:47 2008 From: drepper at redhat.com (Ulrich Drepper) Date: Wed, 03 Sep 2008 07:24:47 -0700 Subject: telive 2008 released (in time for f10?) In-Reply-To: <20080903114044.GA30583@dhcp-lab-186.brq.redhat.com> References: <20080903114044.GA30583@dhcp-lab-186.brq.redhat.com> Message-ID: <48BE9E2F.9060604@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jindrich Novy wrote: > since the new TeX Live 2008 comes with lots of changes and it needs > some time for testing (in Fedora land) Quite honestly, the current Texlive isn't that great. Some of the latter updates seem to have broken at least metapost. I haven't reported it yet since I didn't have time to track it down in detail. But at least for me this means going to TL2008 isn't _that_ big of a risk. - -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAki+ni8ACgkQ2ijCOnn/RHSpjgCgiBC5247KtzFxnmTv/YJ5ddmY lJQAoLJK/5id7u7o90UzB+gAyTArBL6v =Z4ah -----END PGP SIGNATURE----- From mschwendt at gmail.com Wed Sep 3 15:10:01 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 3 Sep 2008 17:10:01 +0200 Subject: xmms heads up In-Reply-To: <1220394346.7539.3.camel@PB3.Linux> References: <1220394346.7539.3.camel@PB3.Linux> Message-ID: <20080903171001.b9a403f7.mschwendt@gmail.com> On Tue, 02 Sep 2008 23:25:46 +0100, Paul wrote: > I've just built xmms-1.2.11-20071117cvs for rawhide. It should hit > whenever there is a rawhide push (god knows when that will be ;-p). You've reverted the licence fix in the spec file and removed also the corresponding changelog entry. Why? Also, are other external xmms plugins in Fedora affected by your update? From opensource at till.name Wed Sep 3 15:45:41 2008 From: opensource at till.name (Till Maas) Date: Wed, 03 Sep 2008 17:45:41 +0200 Subject: Using lzma compressed tarball as Source0 Message-ID: <200809031745.51330.opensource@till.name> Hiyas, are there some best practices or some secret macros I can redifine to use a lzma compressed tarball as Source0 for Fedora 8+ specs? It would help if I could pass --use-compress-program=lzma to the tar commandline that %setup uses. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From tibbs at math.uh.edu Wed Sep 3 15:53:24 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 03 Sep 2008 10:53:24 -0500 Subject: Using lzma compressed tarball as Source0 In-Reply-To: <200809031745.51330.opensource@till.name> References: <200809031745.51330.opensource@till.name> Message-ID: >>>>> "TM" == Till Maas writes: TM> Hiyas, are there some best practices or some secret macros I can TM> redifine to use a lzma compressed tarball as Source0 for Fedora 8+ TM> specs? Use %setup -T and call the unpacking command yourself? - J< From kevin.kofler at chello.at Wed Sep 3 15:54:37 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 3 Sep 2008 15:54:37 +0000 (UTC) Subject: rawhide report: 20080829 changes References: <20080829195754.07B211F8248@releng2.fedora.phx.redhat.com> <1220044676.9554.26.camel@luminos.localdomain> <20080831191730.GA7646@dhcp-lab-186.brq.redhat.com> <1220214626.29094.13.camel@luminos.localdomain> <20080903124132.GB30583@dhcp-lab-186.brq.redhat.com> Message-ID: Jindrich Novy redhat.com> writes: > This could be the easiest way to go. Packager would then be responsible for > differences if the content of noarch subpackage is dependent on > builder arch and affects somehow binary package functionality or e.g. > generated documentation. And that isn't really different from what currently happens with pure noarch packages, which are just built on a random arch and it's the packager's responsibility to make sure they're really arch-independent. Kevin Kofler From mschwendt at gmail.com Wed Sep 3 15:59:09 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 3 Sep 2008 17:59:09 +0200 Subject: Using lzma compressed tarball as Source0 In-Reply-To: <200809031745.51330.opensource@till.name> References: <200809031745.51330.opensource@till.name> Message-ID: <20080903175909.736e1f4f.mschwendt@gmail.com> On Wed, 03 Sep 2008 17:45:41 +0200, Till Maas wrote: > Hiyas, > > are there some best practices or some secret macros I can redifine to use a > lzma compressed tarball as Source0 for Fedora 8+ specs? > It would help if I could pass --use-compress-program=lzma to the tar > commandline that %setup uses. %setup -c -q -T and extract %{SOURCE0} manually. Does that help, too? From jkeating at redhat.com Wed Sep 3 16:05:28 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 03 Sep 2008 09:05:28 -0700 Subject: rawhide report: 20080829 changes In-Reply-To: References: <20080829195754.07B211F8248@releng2.fedora.phx.redhat.com> <1220044676.9554.26.camel@luminos.localdomain> <20080831191730.GA7646@dhcp-lab-186.brq.redhat.com> <1220214626.29094.13.camel@luminos.localdomain> <20080903124132.GB30583@dhcp-lab-186.brq.redhat.com> Message-ID: <1220457928.2795.7.camel@luminos.localdomain> On Wed, 2008-09-03 at 15:54 +0000, Kevin Kofler wrote: > > And that isn't really different from what currently happens with pure noarch > packages, which are just built on a random arch and it's the packager's > responsibility to make sure they're really arch-independent. To be fair though, making a subpackage noarch is slightly different. One could easily fall into the trap of assuming that the entire build set will be produced on the one arch, just like an rpmbuild on a local machine would do, and that the noarch subpackage would match the arch specific other subpackages. It is something to watch out for. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From opensource at till.name Wed Sep 3 16:06:59 2008 From: opensource at till.name (Till Maas) Date: Wed, 03 Sep 2008 18:06:59 +0200 Subject: Schedule for F9 updates? In-Reply-To: <1220399987.30380.19.camel@luminos.localdomain> References: <20080902224415.7a597dbb@earth> <200809030045.19651.opensource@till.name> <1220399987.30380.19.camel@luminos.localdomain> Message-ID: <200809031807.05196.opensource@till.name> On Wed September 3 2008, Jesse Keating wrote: > On Wed, 2008-09-03 at 00:45 +0200, Till Maas wrote: > > Maybe you missed this, but I am also talking about downloading packages > > from Koji via SSL. This is not enabled with the default koji config that > > is in the F9 koji package and which now seems to be /etc/koji.conf and it > > seems not to work when I use https for every url in that config file. > > No, I didn't miss it, which is why I stated we were talking about two > different things. Sorry, I misunderstood you. I understood that you meant "koji download-build" uses SSL (or can use SSL) and does not require the client certificate, but wget (or more precise: the URL I use with wget) needs the client certificate. > > I know that changing one url in ~/.koji/ made koji at least > > display some urls with https instead of http. I need to look into my > > backups to get the details, because the packager-setup-scripts wants to > > avoid confusion by silently deleting old user edited config files. Ah, I > > found a bug report that indicates that I changed every URL. > > > > I just checked that a scratch srpm build works, but download-build does > > not when all urls in /etc/koji.conf are https ones. Is download-build > > really meant to work somehow via SSL? > > It's just plain not tested. Now you're testing it, finding it not to > work, and now you know what comes next. Here is the bug report: https://fedorahosted.org/koji/ticket/106 Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From sandeen at redhat.com Wed Sep 3 16:19:04 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 03 Sep 2008 11:19:04 -0500 Subject: ext4 testing in the F10 release cycle Message-ID: <48BEB8F8.9050902@redhat.com> Hi all - Just my semiannual plea for some ext4 testing in the Fedora beta cycle. ext4 was a feature goal for F9, and it was close; it was relegated to a secret-anaconda-handshake "iamanext4developer" to enable it for install - largely due to lack of ext4 support in e2fsprogs. With the e2fsprogs-1.41.0 release in F10, we now have an ext4-capable e2fsprogs, with working fsck, debugfs, etc as well as mkfs.ext4 and mkfs.ext4dev to enable the new disk format features by default. For F10, the barrier to entry has been lowered by 14 characters - now all you have to type on the boot prompt is "ext4" :) and when you go to the custom partitioning screen, you'll get the option to create ext4 filesystems at install time. I'd appreciate any and all testing, benchmarking & feedback that people would be willing to do. Just getting more exposure in real-life scenarios would be great. As with any filesystem, I wouldn't put your only copy of your most precious data on it - use good sense about backups etc - but ext4 has made good progress since F9 on both stability and performance, so have at it! Thanks, -Eric From opensource at till.name Wed Sep 3 16:28:08 2008 From: opensource at till.name (Till Maas) Date: Wed, 03 Sep 2008 18:28:08 +0200 Subject: Using lzma compressed tarball as Source0 In-Reply-To: <20080903175909.736e1f4f.mschwendt@gmail.com> References: <200809031745.51330.opensource@till.name> <20080903175909.736e1f4f.mschwendt@gmail.com> Message-ID: <200809031828.13472.opensource@till.name> On Wed September 3 2008, Michael Schwendt wrote: > On Wed, 03 Sep 2008 17:45:41 +0200, Till Maas wrote: > > Hiyas, > > > > are there some best practices or some secret macros I can redifine to use > > a lzma compressed tarball as Source0 for Fedora 8+ specs? > > It would help if I could pass --use-compress-program=lzma to the tar > > commandline that %setup uses. > > %setup -c -q -T > > and extract %{SOURCE0} manually. Does that help, too? Thanks, the best solution I can think of with this %setup commandline is this: %setup -q -c -T lzma -c -d %SOURCE0 | tar -xvvf - -C .. Without the -C .. tar will create a new directory within the extracted source directory, e.g. foo-1.2/foo-1.2 which will break the remainder of the spec. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From opensource at till.name Wed Sep 3 16:36:01 2008 From: opensource at till.name (Till Maas) Date: Wed, 03 Sep 2008 18:36:01 +0200 Subject: Using lzma compressed tarball as Source0 In-Reply-To: References: <200809031745.51330.opensource@till.name> Message-ID: <200809031836.01943.opensource@till.name> On Wed September 3 2008, Jason L Tibbitts III wrote: > >>>>> "TM" == Till Maas writes: > > TM> Hiyas, are there some best practices or some secret macros I can > TM> redifine to use a lzma compressed tarball as Source0 for Fedora 8+ > TM> specs? > > Use %setup -T and call the unpacking command yourself? Only adding -T to %setup fails, because %setup wants to cd into the source directory that it previously removed. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pbrobinson at gmail.com Wed Sep 3 16:39:09 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 3 Sep 2008 17:39:09 +0100 Subject: ext4 testing in the F10 release cycle In-Reply-To: <48BEB8F8.9050902@redhat.com> References: <48BEB8F8.9050902@redhat.com> Message-ID: <5256d0b0809030939wf131878rcf8e433eb4e1444c@mail.gmail.com> > Just my semiannual plea for some ext4 testing in the Fedora beta cycle. > > ext4 was a feature goal for F9, and it was close; it was relegated to a > secret-anaconda-handshake "iamanext4developer" to enable it for install > - largely due to lack of ext4 support in e2fsprogs. > > With the e2fsprogs-1.41.0 release in F10, we now have an ext4-capable > e2fsprogs, with working fsck, debugfs, etc as well as mkfs.ext4 and > mkfs.ext4dev to enable the new disk format features by default. > > For F10, the barrier to entry has been lowered by 14 characters - now > all you have to type on the boot prompt is "ext4" :) and when you go to > the custom partitioning screen, you'll get the option to create ext4 > filesystems at install time. > > I'd appreciate any and all testing, benchmarking & feedback that people > would be willing to do. Just getting more exposure in real-life > scenarios would be great. > > As with any filesystem, I wouldn't put your only copy of your most > precious data on it - use good sense about backups etc - but ext4 has > made good progress since F9 on both stability and performance, so have > at it! Do you have recommended FS creation parameters for SSDs? Peter From tibbs at math.uh.edu Wed Sep 3 16:40:00 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 03 Sep 2008 11:40:00 -0500 Subject: Using lzma compressed tarball as Source0 In-Reply-To: <200809031836.01943.opensource@till.name> References: <200809031745.51330.opensource@till.name> <200809031836.01943.opensource@till.name> Message-ID: >>>>> "TM" == Till Maas writes: TM> Only adding -T to %setup fails, because %setup wants to cd into TM> the source directory that it previously removed. So add the option to make it not do that. http://www.rpm.org/max-rpm/s1-rpm-inside-macros.html - J< From sandeen at redhat.com Wed Sep 3 16:47:48 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 03 Sep 2008 11:47:48 -0500 Subject: ext4 testing in the F10 release cycle In-Reply-To: <5256d0b0809030939wf131878rcf8e433eb4e1444c@mail.gmail.com> References: <48BEB8F8.9050902@redhat.com> <5256d0b0809030939wf131878rcf8e433eb4e1444c@mail.gmail.com> Message-ID: <48BEBFB4.3050208@redhat.com> Peter Robinson wrote: > Do you have recommended FS creation parameters for SSDs? Not really; there has unfortunately been very little (or no) optimization of ext4 for SSDs at this point ... It'd probably be an allocator heuristic change but nobody's looked into that yet. Once we get ext4 raid-geometry-aware, we can probably use some of that geometry info to better match up with the erase block sizes on an SSD at least... -Eric > Peter > From rjones at redhat.com Wed Sep 3 16:53:54 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 3 Sep 2008 17:53:54 +0100 Subject: ext4 testing in the F10 release cycle In-Reply-To: <48BEB8F8.9050902@redhat.com> References: <48BEB8F8.9050902@redhat.com> Message-ID: <20080903165354.GA17011@amd.home.annexia.org> On Wed, Sep 03, 2008 at 11:19:04AM -0500, Eric Sandeen wrote: > I'd appreciate any and all testing, benchmarking & feedback that people > would be willing to do. Just getting more exposure in real-life > scenarios would be great. > > As with any filesystem, I wouldn't put your only copy of your most > precious data on it - use good sense about backups etc - but ext4 has > made good progress since F9 on both stability and performance, so have > at it! Persistent pre-allocation[1] is something that virt-manager could really use when it has to allocate multi-gigabyte images. A few questions about this feature though: (a) Is it exposed as a syscall anywhere? I don't see it in the header files of my Rawhide system (2.6.27). (b) Will preallocate "do the right thing" on filesystems that don't directly support it? (c) Does ext4 preallocate in the background? A synchronous preallocate call isn't much use to virt-manager. Rich. [1] http://en.wikipedia.org/wiki/Ext4#Persistent_pre-allocation -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From opensource at till.name Wed Sep 3 16:54:45 2008 From: opensource at till.name (Till Maas) Date: Wed, 03 Sep 2008 18:54:45 +0200 Subject: Using lzma compressed tarball as Source0 In-Reply-To: References: <200809031745.51330.opensource@till.name> <200809031836.01943.opensource@till.name> Message-ID: <200809031854.54947.opensource@till.name> On Wed September 3 2008, Jason L Tibbitts III wrote: > >>>>> "TM" == Till Maas writes: > > TM> Only adding -T to %setup fails, because %setup wants to cd into > TM> the source directory that it previously removed. > > So add the option to make it not do that. > http://www.rpm.org/max-rpm/s1-rpm-inside-macros.html I am not sure, what you are suggesting. Do you mean I should do the following? %prep rm -rf %{name}-%{version} lzma -c -d %SOURCE0 | tar xvvf - %setup -q -T -D Is it maybe ok to just skip %setup and only extract the sources manually? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From orion at cora.nwra.com Wed Sep 3 16:55:52 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 03 Sep 2008 10:55:52 -0600 Subject: SGML support refactored in F-10? In-Reply-To: <907.1220315414@sss.pgh.pa.us> References: <17316.1219966344@sss.pgh.pa.us> <1219967329.6260.3.camel@localhost.localdomain> <1220015170.3980.43.camel@dhcp-lab-219.englab.brq.redhat.com> <907.1220315414@sss.pgh.pa.us> Message-ID: <48BEC198.3080809@cora.nwra.com> Tom Lane wrote: > =?UTF-8?Q?Ond=C5=99ej_Va=C5=A1=C3=ADk?= writes: >> Thanks for report. Looks like some kind of heavy-weight black magic. >> Problems mentioned by Mathias were solved in mid July, it is not related >> to the current troubles as those changes are completely same for rawhide >> and F9. Actually everything is same, diff is showing the only difference >> in requires for xml-common, release number, changelog changes and >> switched position of CATALOG definition (just changing the position >> didn't help). After usage of F-9 spec file (with devel changelog and >> version) it seems to work properly again.It seems there is something >> very fragile in docbook-dtds.spec and it was accidently broken. >> http://koji.fedoraproject.org/koji/taskinfo?taskID=793167 >> should work for you. At least it works for me... > > Thanks for trying, but it still fails with about the same symptoms: > http://koji.fedoraproject.org/koji/taskinfo?taskID=799111 > > regards, tom lane > Problems for me too: /usr/bin/openjade:/usr/share/sgml/docbook/sgml-dtd-4.2-1.0-39.fc10/dbcentx.mod:308:0:E: cannot find "ent/iso-amsa.ent"; tried "/usr/share/sgml/docbook/sgml-dtd-4.2-1.0-39.fc10/ent/iso-amsa.ent", "/usr/share/sgml/ent/iso-amsa.ent", "/usr/share/xml/ent/iso-amsa.ent" and so on... find /usr/share -name iso-amsa.ent /usr/share/sgml/docbook/xml-dtd-4.2-1.0-39.fc10/ent/iso-amsa.ent /usr/share/sgml/docbook/xml-dtd-4.1.2-1.0-39.fc10/ent/iso-amsa.ent /usr/share/sgml/docbook/xml-dtd-4.3-1.0-39.fc10/ent/iso-amsa.ent -- 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 jwilson at redhat.com Wed Sep 3 16:57:23 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Wed, 3 Sep 2008 12:57:23 -0400 Subject: Using lzma compressed tarball as Source0 In-Reply-To: <200809031828.13472.opensource@till.name> References: <200809031745.51330.opensource@till.name> <20080903175909.736e1f4f.mschwendt@gmail.com> <200809031828.13472.opensource@till.name> Message-ID: <200809031257.23527.jwilson@redhat.com> On Wednesday 03 September 2008 12:28:08 Till Maas wrote: > On Wed September 3 2008, Michael Schwendt wrote: > > On Wed, 03 Sep 2008 17:45:41 +0200, Till Maas wrote: > > > Hiyas, > > > > > > are there some best practices or some secret macros I can redifine to > > > use a lzma compressed tarball as Source0 for Fedora 8+ specs? > > > It would help if I could pass --use-compress-program=lzma to the tar > > > commandline that %setup uses. > > > > %setup -c -q -T > > > > and extract %{SOURCE0} manually. Does that help, too? > > Thanks, the best solution I can think of with this %setup commandline is > this: > > %setup -q -c -T > lzma -c -d %SOURCE0 | tar -xvvf - -C .. > > Without the -C .. tar will create a new directory within the extracted > source directory, e.g. foo-1.2/foo-1.2 which will break the remainder of > the spec. Nb: coreutils uses an lzma-compressed tarball, with the following: %prep #do not unpack in setup because of lzma is not yet supported in setup macro %setup -q -c -T cd .. lzma -dc %SOURCE0 | tar xf - cd %name-%version ... -- Jarod Wilson jarod at redhat.com From mlichvar at redhat.com Wed Sep 3 16:58:35 2008 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Wed, 3 Sep 2008 18:58:35 +0200 Subject: Dependency loops considered harmful? Message-ID: <20080903165835.GA31342@localhost> Hi, I've noticed that we have quite a lot of dependency loops in repositories. The current i386 rawhide has 354 packages which are part of one or more loops. Is that ok? I've always thought it's something that should be avoided as it makes life harder for rpm, yum and users trying to manually install or remove rpms. I even remember few incidents where a loop caused serious troubles when installing packages with scriptlets. Full list of the packages is here: http://fedorapeople.org/~mlichvar/tmp/rawhide.i386.loops For example, why games data depend on binaries? What do you think? Are loops something that we should try to avoid? -- Miroslav Lichvar From limb at jcomserv.net Wed Sep 3 17:10:13 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 3 Sep 2008 12:10:13 -0500 (CDT) Subject: Dependency loops considered harmful? In-Reply-To: <20080903165835.GA31342@localhost> References: <20080903165835.GA31342@localhost> Message-ID: <9448.198.175.55.5.1220461813.squirrel@mail.jcomserv.net> > Hi, > > I've noticed that we have quite a lot of dependency loops in > repositories. The current i386 rawhide has 354 packages which are part > of one or more loops. > > Is that ok? I've always thought it's something that should be avoided > as it makes life harder for rpm, yum and users trying to manually > install or remove rpms. I even remember few incidents where a loop > caused serious troubles when installing packages with scriptlets. > > Full list of the packages is here: > http://fedorapeople.org/~mlichvar/tmp/rawhide.i386.loops > > For example, why games data depend on binaries? So that if we try to upgrade the version of the binaries and not the data, it will fail. We can still bump the release in most cases, allowing for minot fixes without requiring the user to download the same data again. > What do you think? Are loops something that we should try to avoid? > > -- > Miroslav Lichvar > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From limb at jcomserv.net Wed Sep 3 17:10:45 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 3 Sep 2008 12:10:45 -0500 (CDT) Subject: Dependency loops considered harmful? In-Reply-To: <20080903165835.GA31342@localhost> References: <20080903165835.GA31342@localhost> Message-ID: <11077.198.175.55.5.1220461845.squirrel@mail.jcomserv.net> > Hi, > > I've noticed that we have quite a lot of dependency loops in > repositories. The current i386 rawhide has 354 packages which are part > of one or more loops. > > Is that ok? I've always thought it's something that should be avoided > as it makes life harder for rpm, yum and users trying to manually > install or remove rpms. I even remember few incidents where a loop > caused serious troubles when installing packages with scriptlets. > > Full list of the packages is here: > http://fedorapeople.org/~mlichvar/tmp/rawhide.i386.loops > > For example, why games data depend on binaries? Sent too soon. It's also so when you remove the game, you remove the data. > What do you think? Are loops something that we should try to avoid? > > -- > Miroslav Lichvar > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From mschwendt at gmail.com Wed Sep 3 17:24:16 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 3 Sep 2008 19:24:16 +0200 Subject: Dependency loops considered harmful? In-Reply-To: <20080903165835.GA31342@localhost> References: <20080903165835.GA31342@localhost> Message-ID: <20080903192416.0774097a.mschwendt@gmail.com> On Wed, 3 Sep 2008 18:58:35 +0200, Miroslav Lichvar wrote: > For example, why games data depend on binaries? I've also questioned that before. It boils down to a matter of convenience. It's packagers who say that the data pkgs are not usable without the game program, and therefore they want to avoid the scenario where somebody installs a game data pkg that doesn't result in a working game in the desktop menu. Hence game data and game program are tied to eachother in both directions. > What do you think? Are loops something that we should try to avoid? Yes. IIRC, there are even some weird loops where after a package split a new sub-package depends on the main package and vice versa. From jspaleta at gmail.com Wed Sep 3 17:26:38 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 3 Sep 2008 09:26:38 -0800 Subject: Dependency loops considered harmful? In-Reply-To: <20080903165835.GA31342@localhost> References: <20080903165835.GA31342@localhost> Message-ID: <604aa7910809031026j1ebabc7fyf85307254f451fb6@mail.gmail.com> On Wed, Sep 3, 2008 at 8:58 AM, Miroslav Lichvar wrote: > What do you think? Are loops something that we should try to avoid? generally speaking...yes..make a reasonable effort to avoid loops. But that isn't a strict requirement. If a maintainer fills there is a good reason to have a loop, then they can do it. But we should probably ask them to document that reason in the spec file when they are making a deliberate decision to form a loop. Though I will say that loops that involve docs or devel subpackages are probably packaging errors and you could probably get them fixed up by talking with the maintainers. I would be surprised if a docs or devel subpackage was intended to be required with the main package. the -libs subpackage situations.. im not sure about. I think its case by case. Does kde3base-libs need kde3base? I dont know. Does oddjob-libs need oddjob? For the -libs circular loops I think some might be packaging errors and some might be deliberate choices. We should probably try to get the maintainers to make spec comment in the cases where its deliberate. the -data situations are probably deliberate, as a way to make sure that an application cleans up after itself when uninstalled. For the more complicated situations in your groupings.... that's definitely going to be case by case. I'm pretty sure the Xorg sitaution is deliberate to ensure some basic hardware support is installed. Things are broken out modularly as packages so individual drivers can be updated without pushing the whole Xorg tree as an update, but we still want some basic driver support always installed..hence the circular deps. But the zlib loop? It touches so many packages I'm not sure it could be deliberate decision. Can we avoid it? I don't know...it would require the maintainers of all the packages in the loop to talk about it. It is a bit of interesting analysis. -jef From j.w.r.degoede at hhs.nl Wed Sep 3 17:39:38 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 03 Sep 2008 19:39:38 +0200 Subject: Dependency loops considered harmful? In-Reply-To: <20080903192416.0774097a.mschwendt@gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> Message-ID: <48BECBDA.6090102@hhs.nl> Michael Schwendt wrote: > On Wed, 3 Sep 2008 18:58:35 +0200, Miroslav Lichvar wrote: > >> For example, why games data depend on binaries? > > I've also questioned that before. It boils down to a matter of > convenience. It's packagers who say that the data pkgs are not usable > without the game program, and therefore they want to avoid the > scenario where somebody installs a game data pkg that doesn't result > in a working game in the desktop menu. Hence game data and game > program are tied to eachother in both directions. > Actually its more about the removal scenario, lets say someone does: df yum install vegastrike (drags in vegastrike-data) df (who thats big) (hey that games sucks and eats up my HD-space) yum remove vegastrike df (WTF, why am I still missing 0.4 Gigs of HD-space ??) To avoid this the data packages depend upon the game binary, and vica versa the game binary depends upon the data so that the data will get dragged in when installing the game resulting in a working game. And no we will not just put them together, because re-releasing 300+ MB of gamedata because the binary needs recompiling for a new lib is not cool! >> What do you think? Are loops something that we should try to avoid? > > Yes. IIRC, there are even some weird loops where after a package split > a new sub-package depends on the main package and vice versa. > Generally I agree, but their are exceptions, like game-engine <-> data Regards, Hans From sandeen at redhat.com Wed Sep 3 17:36:55 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 03 Sep 2008 12:36:55 -0500 Subject: ext4 testing in the F10 release cycle In-Reply-To: <20080903165354.GA17011@amd.home.annexia.org> References: <48BEB8F8.9050902@redhat.com> <20080903165354.GA17011@amd.home.annexia.org> Message-ID: <48BECB37.6000807@redhat.com> Richard W.M. Jones wrote: > On Wed, Sep 03, 2008 at 11:19:04AM -0500, Eric Sandeen wrote: >> I'd appreciate any and all testing, benchmarking & feedback that people >> would be willing to do. Just getting more exposure in real-life >> scenarios would be great. >> >> As with any filesystem, I wouldn't put your only copy of your most >> precious data on it - use good sense about backups etc - but ext4 has >> made good progress since F9 on both stability and performance, so have >> at it! > > Persistent pre-allocation[1] is something that virt-manager could > really use when it has to allocate multi-gigabyte images. A few > questions about this feature though: > > (a) Is it exposed as a syscall anywhere? I don't see it in the header > files of my Rawhide system (2.6.27). Hm, I probably need to get the fallocate.h header file included if it's not so that sys_fallocate can be used directly, but it is also exposed via posix_fallocate in glibc - tested here on xfs just because xfs_bmap is a handy way to show that it actually works via glibc: [root at inode fallocate]# ./test_posix_fallocate testfile 0 16384 [root at inode fallocate]# xfs_bmap -vv testfile testfile: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLAGS 0: [0..31]: 138928..138959 0 (138928..138959) 32 10000 FLAG Values: 010000 Unwritten preallocated extent 001000 Doesn't begin on stripe unit 000100 Doesn't end on stripe unit 000010 Doesn't begin on stripe width 000001 Doesn't end on stripe width the ->fallocate op is hooked up for ext4, xfs, and ocfs2 at this time. > (b) Will preallocate "do the right thing" on filesystems that don't > directly support it? calling sys_fallocate() will give you -EOPNOTSUPP; using posix_fallocate() falls back to writing zeros IIRC. > (c) Does ext4 preallocate in the background? A synchronous > preallocate call isn't much use to virt-manager. It does not, but what is the concern? It doesn't take much time: (on ext4 this time): [root at inode test]# time test_posix_fallocate testfile 0 10737418240 real 0m0.009s user 0m0.000s sys 0m0.009s [root at inode test]# ls -lh testfile -rw-r--r-- 1 root root 10G 2008-09-03 12:30 testfile [root at inode test]# du -hc testfile 11G testfile 11G total -Eric > Rich. > > [1] http://en.wikipedia.org/wiki/Ext4#Persistent_pre-allocation > #define _LARGEFILE64_SOURCE #define _GNU_SOURCE #include #include #include #include #include #include #include int main(int argc, char **argv) { int fd; int ret; loff_t offset; loff_t len; char *fname; fname = argv[1]; offset = atoll(argv[2]); len = atoll(argv[3]); printf("file %s offset %llu (%s) length %llu (%s)\n", fname, offset, argv[2], len, argv[3]); fd = open(fname, O_CREAT|O_RDWR, 0666); if (fd < 0) { perror("Error opening file"); return 1; } ret = posix_fallocate64(fd, offset, len); if (ret < 0) perror("Error allocating space"); close(fd); return 0; } From mlichvar at redhat.com Wed Sep 3 18:02:24 2008 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Wed, 3 Sep 2008 20:02:24 +0200 Subject: Dependency loops considered harmful? In-Reply-To: <48BECBDA.6090102@hhs.nl> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> Message-ID: <20080903180224.GA13455@localhost> On Wed, Sep 03, 2008 at 07:39:38PM +0200, Hans de Goede wrote: > Actually its more about the removal scenario, lets say someone does: > df > yum install vegastrike (drags in vegastrike-data) > df (who thats big) > (hey that games sucks and eats up my HD-space) > yum remove vegastrike > df (WTF, why am I still missing 0.4 Gigs of HD-space ??) But that isn't much different from a case when I install any package with rich dependencies, say, gnome-session and after removing the package there will be dozens of packages left I didn't want. Actually, the loop may cause that I won't remove the game, because I forgot I've installed it and it doesn't show up as a leaf. Until yum or rpm is able to track packages installed only to satisfy dependencies, this will always be a problem. Why make the game data a special case? -- Miroslav Lichvar From sandeen at redhat.com Wed Sep 3 18:05:51 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 03 Sep 2008 13:05:51 -0500 Subject: ext4 testing in the F10 release cycle In-Reply-To: <48BECB37.6000807@redhat.com> References: <48BEB8F8.9050902@redhat.com> <20080903165354.GA17011@amd.home.annexia.org> <48BECB37.6000807@redhat.com> Message-ID: <48BED1FF.90800@redhat.com> Eric Sandeen wrote: > Richard W.M. Jones wrote: >> On Wed, Sep 03, 2008 at 11:19:04AM -0500, Eric Sandeen wrote: >>> I'd appreciate any and all testing, benchmarking & feedback that people >>> would be willing to do. Just getting more exposure in real-life >>> scenarios would be great. >>> >>> As with any filesystem, I wouldn't put your only copy of your most >>> precious data on it - use good sense about backups etc - but ext4 has >>> made good progress since F9 on both stability and performance, so have >>> at it! >> Persistent pre-allocation[1] is something that virt-manager could >> really use when it has to allocate multi-gigabyte images. A few >> questions about this feature though: >> >> (a) Is it exposed as a syscall anywhere? I don't see it in the header >> files of my Rawhide system (2.6.27). > > Hm, I probably need to get the fallocate.h header file included if it's > not so that sys_fallocate can be used directly, Ah, it should be there: [root at inode ~]# rpm -ql kernel-headers | grep falloc /usr/include/linux/falloc.h -Eric From mschwendt at gmail.com Wed Sep 3 18:14:07 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 3 Sep 2008 20:14:07 +0200 Subject: Dependency loops considered harmful? In-Reply-To: <48BECBDA.6090102@hhs.nl> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> Message-ID: <20080903201407.98db0d3d.mschwendt@gmail.com> On Wed, 03 Sep 2008 19:39:38 +0200, Hans de Goede wrote: > Actually its more about the removal scenario, lets say someone does: > df > yum install vegastrike (drags in vegastrike-data) > df (who thats big) > (hey that games sucks and eats up my HD-space) > yum remove vegastrike > df (WTF, why am I still missing 0.4 Gigs of HD-space ??) And what about the many libraries, sound fonts and stuff the game might have pulled in? "yum remove vegastrike" wouldn't remove them either. So, the dependency loop is just to work around yum remove's non-intuitiveness. That yum remove is not the reverse of yum install is a complaint in many comments about Fedora. If we had strict ("tight") dependencies down to the core groups of packages, we could fix yum remove. It would try to remove as many pkgs as possible, at least it would try to remove direct requirements of "vegastrike" unless they would break anything else. From sgallagh at redhat.com Wed Sep 3 18:12:10 2008 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 03 Sep 2008 14:12:10 -0400 Subject: Dependency loops considered harmful? In-Reply-To: <20080903180224.GA13455@localhost> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> Message-ID: <48BED37A.5020706@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Miroslav Lichvar wrote: > On Wed, Sep 03, 2008 at 07:39:38PM +0200, Hans de Goede wrote: >> Actually its more about the removal scenario, lets say someone does: >> df >> yum install vegastrike (drags in vegastrike-data) >> df (who thats big) >> (hey that games sucks and eats up my HD-space) >> yum remove vegastrike >> df (WTF, why am I still missing 0.4 Gigs of HD-space ??) > > But that isn't much different from a case when I install any package > with rich dependencies, say, gnome-session and after removing the > package there will be dozens of packages left I didn't want. > > Actually, the loop may cause that I won't remove the game, because I > forgot I've installed it and it doesn't show up as a leaf. > > Until yum or rpm is able to track packages installed only to satisfy > dependencies, this will always be a problem. Why make the game data a > special case? > A better move here would be to make better use of the yum "groups". Right now, they're next to worthless. You've got the KDE group, the Office group, etc. All of which install a ridiculous amount of software. Applications that consist of multiple packages, such as the game example, should be designated as a group rather than a looped dependency. Then you can add or remove all packages related to it. As a bonus, you can now allow games' data packages to be easily broken into smaller packages (maybe models, levels, etc.) so that individual components can be updated (if say, a single map is changed to eliminate an exploit). This would mean that only the map package would need to be updated (probably sub-1M) and not the entire data package (which could be many megabytes). - -- - -------------------- Stephen Gallagher RHCE 804006346421761 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAki+03YACgkQc7MaxVic+2pzXQCfSJBe8oa2GSbOB+AxKLDpiWUO lrcAn1HJEGlbhr0npjkShO3RUoXMf/9E =4BI+ -----END PGP SIGNATURE----- From mtasaka at ioa.s.u-tokyo.ac.jp Wed Sep 3 18:21:03 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 04 Sep 2008 03:21:03 +0900 Subject: Dependency loops considered harmful? In-Reply-To: <20080903180224.GA13455@localhost> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> Message-ID: <48BED58F.3080301@ioa.s.u-tokyo.ac.jp> Miroslav Lichvar wrote, at 09/04/2008 03:02 AM +9:00: > On Wed, Sep 03, 2008 at 07:39:38PM +0200, Hans de Goede wrote: >> Actually its more about the removal scenario, lets say someone does: >> df >> yum install vegastrike (drags in vegastrike-data) >> df (who thats big) >> (hey that games sucks and eats up my HD-space) >> yum remove vegastrike >> df (WTF, why am I still missing 0.4 Gigs of HD-space ??) > > But that isn't much different from a case when I install any package > with rich dependencies, say, gnome-session and after removing the > package there will be dozens of packages left I didn't want. > > Actually, the loop may cause that I won't remove the game, because I > forgot I've installed it and it doesn't show up as a leaf. > > Until yum or rpm is able to track packages installed only to satisfy > dependencies, this will always be a problem. Why make the game data a > special case? Umm... agreed. When I install some binary rpms rebuilt by koji scratch build to review the package it often pulls so many depdendencies, especially when they are Java packages. In such case I usually keep the log what yum installed to satisfies the dependencies, and when the review finishes, I remove all the rpms written in the yum log. So while I can understand the idea that game maintainers want yum to remove both program rpm and data rpm simultaneously, I don't think this is the strong support for making intentional depedency loop. Mamoru From mschwendt at gmail.com Wed Sep 3 18:30:32 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 3 Sep 2008 20:30:32 +0200 Subject: Dependency loops considered harmful? In-Reply-To: <9448.198.175.55.5.1220461813.squirrel@mail.jcomserv.net> References: <20080903165835.GA31342@localhost> <9448.198.175.55.5.1220461813.squirrel@mail.jcomserv.net> Message-ID: <20080903203032.c9b1f2e0.mschwendt@gmail.com> On Wed, 3 Sep 2008 12:10:13 -0500 (CDT), Jon Ciesla wrote: > > For example, why games data depend on binaries? > > So that if we try to upgrade the version of the binaries and not the data, > it will fail. Unconvincing. Why? Because the game program pkg could require a specific version of the data pkg to achieve the same. If game version gets bumped, dep would break, since you would need to update data pkg, too. Game requires compatible data. So far so good. However, if the data pkg requires the game pkg (versioned! or else it would not be strict enough for your needs), this only increases the risk that you need to bump'n'rebuild the data pkg if the game version is increased without needing any changed data. It's a superfluous dependency that only tries to enhance "yum remove" a bit. From jspaleta at gmail.com Wed Sep 3 18:31:45 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 3 Sep 2008 10:31:45 -0800 Subject: Dependency loops considered harmful? In-Reply-To: <48BED58F.3080301@ioa.s.u-tokyo.ac.jp> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED58F.3080301@ioa.s.u-tokyo.ac.jp> Message-ID: <604aa7910809031131q3b7613b7n2d965a68a81572dc@mail.gmail.com> On Wed, Sep 3, 2008 at 10:21 AM, Mamoru Tasaka wrote: > Umm... agreed. > When I install some binary rpms rebuilt by koji scratch build to review > the package it often pulls so many depdendencies, especially when they > are Java packages. What's the overall drive consumption when you do that? The issue isnt "number of packages" the issue is "amount of harddrive space." Game data make be exceptional in that that are typically as large or larger than 200M. Pulling in java deps might pollute your packagelist..but does it burn 200M+ of harddrive space? I hope the packagekit people are watching this discussion. The game data subpackaging issue should be right up their ally in terms of end-user ease of use issues. -jef From limb at jcomserv.net Wed Sep 3 18:36:41 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 3 Sep 2008 13:36:41 -0500 (CDT) Subject: Dependency loops considered harmful? In-Reply-To: <20080903203032.c9b1f2e0.mschwendt@gmail.com> References: <20080903165835.GA31342@localhost> <9448.198.175.55.5.1220461813.squirrel@mail.jcomserv.net> <20080903203032.c9b1f2e0.mschwendt@gmail.com> Message-ID: <12696.198.175.55.5.1220467001.squirrel@mail.jcomserv.net> > On Wed, 3 Sep 2008 12:10:13 -0500 (CDT), Jon Ciesla wrote: > >> > For example, why games data depend on binaries? >> >> So that if we try to upgrade the version of the binaries and not the >> data, >> it will fail. > > Unconvincing. > > Why? Because the game program pkg could require a specific version of > the data pkg to achieve the same. If game version gets bumped, dep > would break, since you would need to update data pkg, too. Game requires > compatible data. So far so good. > > However, if the data pkg requires the game pkg (versioned! or else it > would not be strict enough for your needs), this only increases the > risk that you need to bump'n'rebuild the data pkg if the game version > is increased without needing any changed data. It's a superfluous > dependency that only tries to enhance "yum remove" a bit. How? For game data, the convention is to require on name and version, but not release. If new data is required, it will change the version. If not, we only increment the binary rpm's release, so the data rpm matches on version and needs no rebuild. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From mtasaka at ioa.s.u-tokyo.ac.jp Wed Sep 3 18:45:30 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 04 Sep 2008 03:45:30 +0900 Subject: Dependency loops considered harmful? In-Reply-To: <604aa7910809031131q3b7613b7n2d965a68a81572dc@mail.gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED58F.3080301@ioa.s.u-tokyo.ac.jp> <604aa7910809031131q3b7613b7n2d965a68a81572dc@mail.gmail.com> Message-ID: <48BEDB4A.7000501@ioa.s.u-tokyo.ac.jp> Jeff Spaleta wrote, at 09/04/2008 03:31 AM +9:00: > On Wed, Sep 3, 2008 at 10:21 AM, Mamoru Tasaka > wrote: >> Umm... agreed. >> When I install some binary rpms rebuilt by koji scratch build to review >> the package it often pulls so many depdendencies, especially when they >> are Java packages. > > What's the overall drive consumption when you do that? The issue isnt > "number of packages" the issue is "amount of harddrive space." Game > data make be exceptional in that that are typically as large or larger > than 200M. Pulling in java deps might pollute your packagelist..but > does it burn 200M+ of harddrive space? One package I reviewed pulled 96M dependency rpms (and if they are expanded they gets larger) Mamoru From rjones at redhat.com Wed Sep 3 18:53:46 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 3 Sep 2008 19:53:46 +0100 Subject: ext4 testing in the F10 release cycle In-Reply-To: <48BECB37.6000807@redhat.com> References: <48BEB8F8.9050902@redhat.com> <20080903165354.GA17011@amd.home.annexia.org> <48BECB37.6000807@redhat.com> Message-ID: <20080903185346.GA17465@amd.home.annexia.org> On Wed, Sep 03, 2008 at 12:36:55PM -0500, Eric Sandeen wrote: > Hm, I probably need to get the fallocate.h header file included if it's > not so that sys_fallocate can be used directly, but it is also exposed > via posix_fallocate in glibc - tested here on xfs just because xfs_bmap > is a handy way to show that it actually works via glibc: Uh, stupid me - I was looking for the wrong call. Rawhide _does_ have it. > > (c) Does ext4 preallocate in the background? A synchronous > > preallocate call isn't much use to virt-manager. > > It does not, but what is the concern? It doesn't take much time: > (on ext4 this time): > > [root at inode test]# time test_posix_fallocate testfile 0 10737418240 > > real 0m0.009s > user 0m0.000s > sys 0m0.009s OK ... I'm assuming though that the zeroes aren't all written to disk in this time, so that is exactly what I wanted. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From rjones at redhat.com Wed Sep 3 18:55:41 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 3 Sep 2008 19:55:41 +0100 Subject: Dependency loops considered harmful? In-Reply-To: <20080903165835.GA31342@localhost> References: <20080903165835.GA31342@localhost> Message-ID: <20080903185541.GB17465@amd.home.annexia.org> On Wed, Sep 03, 2008 at 06:58:35PM +0200, Miroslav Lichvar wrote: > I've noticed that we have quite a lot of dependency loops in > repositories. The current i386 rawhide has 354 packages which are part > of one or more loops. > > Is that ok? I've always thought it's something that should be avoided > as it makes life harder for rpm, yum and users trying to manually > install or remove rpms. I even remember few incidents where a loop > caused serious troubles when installing packages with scriptlets. Currently MinGW has an unavoidable dependency loop, requiring you to start with a binary package. (Eventually you can build everything from source). Such loops are unavoidable where you have any sort of bootstrapping of compilers. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From mschwendt at gmail.com Wed Sep 3 19:07:16 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 3 Sep 2008 21:07:16 +0200 Subject: Dependency loops considered harmful? In-Reply-To: <12696.198.175.55.5.1220467001.squirrel@mail.jcomserv.net> References: <20080903165835.GA31342@localhost> <9448.198.175.55.5.1220461813.squirrel@mail.jcomserv.net> <20080903203032.c9b1f2e0.mschwendt@gmail.com> <12696.198.175.55.5.1220467001.squirrel@mail.jcomserv.net> Message-ID: <20080903210716.2ada82b2.mschwendt@gmail.com> On Wed, 3 Sep 2008 13:36:41 -0500 (CDT), Jon Ciesla wrote: > > > On Wed, 3 Sep 2008 12:10:13 -0500 (CDT), Jon Ciesla wrote: > > > >> > For example, why games data depend on binaries? > >> > >> So that if we try to upgrade the version of the binaries and not the > >> data, > >> it will fail. > > > > Unconvincing. > > > > Why? Because the game program pkg could require a specific version of > > the data pkg to achieve the same. If game version gets bumped, dep > > would break, since you would need to update data pkg, too. Game requires > > compatible data. So far so good. > > > > However, if the data pkg requires the game pkg (versioned! or else it > > would not be strict enough for your needs), this only increases the > > risk that you need to bump'n'rebuild the data pkg if the game version > > is increased without needing any changed data. It's a superfluous > > dependency that only tries to enhance "yum remove" a bit. > > How? For game data, the convention is to require on name and version, but > not release. If new data is required, it will change the version. If > not, we only increment the binary rpm's release, so the data rpm matches > on version and needs no rebuild. game-0.8 Requires game-data = 0.8 game-data-0.8 Requires game (which version? and why?) Case 1) game-data-0.8 Requires game = 0.8 What happens if game-1.0 is released with unchanged game-data? Then you need to update game-data for nothing else than the broken dep. Case 2) game-data-0.8 Requires game No version. Hence no dep breakage in all cases where you may update game without updating game-data. Instead, a strict dependency is installed in pkg game: game-%{version} Requires game-data = %{SOME_version} Here you can control the game-data version within pkg "game". Dep 1) is really just for "yum remove". From sandeen at redhat.com Wed Sep 3 19:09:01 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 03 Sep 2008 14:09:01 -0500 Subject: ext4 testing in the F10 release cycle In-Reply-To: <20080903185346.GA17465@amd.home.annexia.org> References: <48BEB8F8.9050902@redhat.com> <20080903165354.GA17011@amd.home.annexia.org> <48BECB37.6000807@redhat.com> <20080903185346.GA17465@amd.home.annexia.org> Message-ID: <48BEE0CD.1050500@redhat.com> Richard W.M. Jones wrote: > On Wed, Sep 03, 2008 at 12:36:55PM -0500, Eric Sandeen wrote: >> Hm, I probably need to get the fallocate.h header file included if it's >> not so that sys_fallocate can be used directly, but it is also exposed >> via posix_fallocate in glibc - tested here on xfs just because xfs_bmap >> is a handy way to show that it actually works via glibc: > > Uh, stupid me - I was looking for the wrong call. Rawhide _does_ have > it. > >>> (c) Does ext4 preallocate in the background? A synchronous >>> preallocate call isn't much use to virt-manager. >> It does not, but what is the concern? It doesn't take much time: > >> (on ext4 this time): >> >> [root at inode test]# time test_posix_fallocate testfile 0 10737418240 >> >> real 0m0.009s >> user 0m0.000s >> sys 0m0.009s > > OK ... I'm assuming though that the zeroes aren't all written to disk > in this time, so that is exactly what I wanted. No, zeros are never written to disk if the ->fallocate call is supported. They are allocated, but flagged on-disk as unwritten/uninitialized, so any read (before a write, of course) will return zeros without the need for all that pesky writing business.... -Eric From limb at jcomserv.net Wed Sep 3 19:10:47 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 3 Sep 2008 14:10:47 -0500 (CDT) Subject: Dependency loops considered harmful? In-Reply-To: <20080903210716.2ada82b2.mschwendt@gmail.com> References: <20080903165835.GA31342@localhost> <9448.198.175.55.5.1220461813.squirrel@mail.jcomserv.net> <20080903203032.c9b1f2e0.mschwendt@gmail.com> <12696.198.175.55.5.1220467001.squirrel@mail.jcomserv.net> <20080903210716.2ada82b2.mschwendt@gmail.com> Message-ID: <54421.198.175.55.5.1220469047.squirrel@mail.jcomserv.net> > On Wed, 3 Sep 2008 13:36:41 -0500 (CDT), Jon Ciesla wrote: > >> >> > On Wed, 3 Sep 2008 12:10:13 -0500 (CDT), Jon Ciesla wrote: >> > >> >> > For example, why games data depend on binaries? >> >> >> >> So that if we try to upgrade the version of the binaries and not the >> >> data, >> >> it will fail. >> > >> > Unconvincing. >> > >> > Why? Because the game program pkg could require a specific version of >> > the data pkg to achieve the same. If game version gets bumped, dep >> > would break, since you would need to update data pkg, too. Game >> requires >> > compatible data. So far so good. >> > >> > However, if the data pkg requires the game pkg (versioned! or else it >> > would not be strict enough for your needs), this only increases the >> > risk that you need to bump'n'rebuild the data pkg if the game version >> > is increased without needing any changed data. It's a superfluous >> > dependency that only tries to enhance "yum remove" a bit. >> >> How? For game data, the convention is to require on name and version, >> but >> not release. If new data is required, it will change the version. If >> not, we only increment the binary rpm's release, so the data rpm matches >> on version and needs no rebuild. > > game-0.8 Requires game-data = 0.8 > game-data-0.8 Requires game (which version? and why?) > > Case 1) > game-data-0.8 Requires game = 0.8 > What happens if game-1.0 is released with unchanged game-data? > Then you need to update game-data for nothing else than the broken dep. I've yet to see this happen. > Case 2) > game-data-0.8 Requires game > No version. Hence no dep breakage in all cases where you may update game > without updating game-data. Instead, a strict dependency is installed > in pkg game: game-%{version} Requires game-data = %{SOME_version} > Here you can control the game-data version within pkg "game". But then if I somehow manage to update the game data but not the binary rpm, and there's an incompatibility, Bad Things happen to the user. > > Dep 1) is really just for "yum remove". > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From mschwendt at gmail.com Wed Sep 3 19:13:39 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 3 Sep 2008 21:13:39 +0200 Subject: Dependency loops considered harmful? In-Reply-To: <604aa7910809031131q3b7613b7n2d965a68a81572dc@mail.gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED58F.3080301@ioa.s.u-tokyo.ac.jp> <604aa7910809031131q3b7613b7n2d965a68a81572dc@mail.gmail.com> Message-ID: <20080903211339.4ded9a8f.mschwendt@gmail.com> On Wed, 3 Sep 2008 10:31:45 -0800, Jeff Spaleta wrote: > On Wed, Sep 3, 2008 at 10:21 AM, Mamoru Tasaka wrote: > > Umm... agreed. > > When I install some binary rpms rebuilt by koji scratch build to review > > the package it often pulls so many depdendencies, especially when they > > are Java packages. > > What's the overall drive consumption when you do that? The issue isnt > "number of packages" the issue is "amount of harddrive space." Game > data make be exceptional in that that are typically as large or larger > than 200M. Pulling in java deps might pollute your packagelist.. It's more than packagelist pollution. With the frequent updates that are common in Fedora land, you need to download and update more and more packages as your packagelist gets longer. From j.w.r.degoede at hhs.nl Wed Sep 3 19:27:26 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 03 Sep 2008 21:27:26 +0200 Subject: Dependency loops considered harmful? In-Reply-To: <20080903210716.2ada82b2.mschwendt@gmail.com> References: <20080903165835.GA31342@localhost> <9448.198.175.55.5.1220461813.squirrel@mail.jcomserv.net> <20080903203032.c9b1f2e0.mschwendt@gmail.com> <12696.198.175.55.5.1220467001.squirrel@mail.jcomserv.net> <20080903210716.2ada82b2.mschwendt@gmail.com> Message-ID: <48BEE51E.9050605@hhs.nl> Michael Schwendt wrote: > On Wed, 3 Sep 2008 13:36:41 -0500 (CDT), Jon Ciesla wrote: > >>> On Wed, 3 Sep 2008 12:10:13 -0500 (CDT), Jon Ciesla wrote: >>> >>>>> For example, why games data depend on binaries? >>>> So that if we try to upgrade the version of the binaries and not the >>>> data, >>>> it will fail. >>> Unconvincing. >>> >>> Why? Because the game program pkg could require a specific version of >>> the data pkg to achieve the same. If game version gets bumped, dep >>> would break, since you would need to update data pkg, too. Game requires >>> compatible data. So far so good. >>> >>> However, if the data pkg requires the game pkg (versioned! or else it >>> would not be strict enough for your needs), this only increases the >>> risk that you need to bump'n'rebuild the data pkg if the game version >>> is increased without needing any changed data. It's a superfluous >>> dependency that only tries to enhance "yum remove" a bit. >> How? For game data, the convention is to require on name and version, but >> not release. If new data is required, it will change the version. If >> not, we only increment the binary rpm's release, so the data rpm matches >> on version and needs no rebuild. > > game-0.8 Requires game-data = 0.8 > game-data-0.8 Requires game (which version? and why?) > > Case 1) > game-data-0.8 Requires game = 0.8 > What happens if game-1.0 is released with unchanged game-data? > Then you need to update game-data for nothing else than the broken dep. > > Case 2) > game-data-0.8 Requires game > No version. Hence no dep breakage in all cases where you may update game > without updating game-data. Instead, a strict dependency is installed > in pkg game: game-%{version} Requires game-data = %{SOME_version} > Here you can control the game-data version within pkg "game". > PLease take an actual look at game spec files before making up all kinds of BS, its really easy: game Requires game-data = %{needed_data_version} game-data Requires game >= %{first game version which uses this data} Its as simple as that, as for this merely working around yum's broken remove, well here we can as there is a 1 on 1 relation, I agree there are other cases where deps get sucked in by an install and not removed by a remove. The fact that those other cases exist is not a good reason to not fix things for games. Game <-> data is a one on one relation, the Requires reflect that, nothing to see here move along. Regards, Hans From mschwendt at gmail.com Wed Sep 3 19:30:52 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 3 Sep 2008 21:30:52 +0200 Subject: Dependency loops considered harmful? In-Reply-To: <54421.198.175.55.5.1220469047.squirrel@mail.jcomserv.net> References: <20080903165835.GA31342@localhost> <9448.198.175.55.5.1220461813.squirrel@mail.jcomserv.net> <20080903203032.c9b1f2e0.mschwendt@gmail.com> <12696.198.175.55.5.1220467001.squirrel@mail.jcomserv.net> <20080903210716.2ada82b2.mschwendt@gmail.com> <54421.198.175.55.5.1220469047.squirrel@mail.jcomserv.net> Message-ID: <20080903213052.690aeb0d.mschwendt@gmail.com> On Wed, 3 Sep 2008 14:10:47 -0500 (CDT), Jon Ciesla wrote: > > game-0.8 Requires game-data = 0.8 > > game-data-0.8 Requires game (which version? and why?) > > > > Case 1) > > game-data-0.8 Requires game = 0.8 > > What happens if game-1.0 is released with unchanged game-data? > > Then you need to update game-data for nothing else than the broken dep. > > I've yet to see this happen. > > > Case 2) > > game-data-0.8 Requires game > > No version. Hence no dep breakage in all cases where you may update game > > without updating game-data. Instead, a strict dependency is installed > > in pkg game: game-%{version} Requires game-data = %{SOME_version} > > Here you can control the game-data version within pkg "game". > > But then if I somehow manage to update the game data but not the binary > rpm, and there's an incompatibility, Bad Things happen to the user. No, because you still have the strict dependency in pkg "game": game Requires game-data = %{some_specific_version} You cannot bump game-data to another major version without breaking this dep. From mschwendt at gmail.com Wed Sep 3 19:31:50 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 3 Sep 2008 21:31:50 +0200 Subject: Dependency loops considered harmful? In-Reply-To: <48BEE51E.9050605@hhs.nl> References: <20080903165835.GA31342@localhost> <9448.198.175.55.5.1220461813.squirrel@mail.jcomserv.net> <20080903203032.c9b1f2e0.mschwendt@gmail.com> <12696.198.175.55.5.1220467001.squirrel@mail.jcomserv.net> <20080903210716.2ada82b2.mschwendt@gmail.com> <48BEE51E.9050605@hhs.nl> Message-ID: <20080903213150.7adf3ed7.mschwendt@gmail.com> On Wed, 03 Sep 2008 21:27:26 +0200, Hans de Goede wrote: > > game-0.8 Requires game-data = 0.8 > > game-data-0.8 Requires game (which version? and why?) > > > > Case 1) > > game-data-0.8 Requires game = 0.8 > > What happens if game-1.0 is released with unchanged game-data? > > Then you need to update game-data for nothing else than the broken dep. > > > > Case 2) > > game-data-0.8 Requires game > > No version. Hence no dep breakage in all cases where you may update game > > without updating game-data. Instead, a strict dependency is installed > > in pkg game: game-%{version} Requires game-data = %{SOME_version} > > Here you can control the game-data version within pkg "game". > > > > PLease take an actual look at game spec files before making up all kinds of BS, No reason for such language. > its really easy: > > game Requires game-data = %{needed_data_version} > game-data Requires game >= %{first game version which uses this data} It doesn't explain why you need the dependency in game-data, as you only need it for yum remove -- and "yum install game-data" to pull in the game program. From mike at cchtml.com Wed Sep 3 19:29:09 2008 From: mike at cchtml.com (Mike Cronenworth) Date: Wed, 03 Sep 2008 14:29:09 -0500 Subject: Microsoft patent affect Fedora? Message-ID: <48BEE585.40906@cchtml.com> A few days ago Microsoft was granted a patent[1] on the functionality of page up and page down. Today was the first time I've heard of this and it seems that it's staying under the radar of most news sites. However this is very real, unless I, and others are mistaken. I know Fedora has an anti-patent stance on software included into itself, so what does this mean? Having Fun, Michael [1] http://news.zdnet.com/2424-9595_22-218626.html From loupgaroublond at gmail.com Wed Sep 3 19:41:35 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Wed, 3 Sep 2008 15:41:35 -0400 Subject: Microsoft patent affect Fedora? In-Reply-To: <48BEE585.40906@cchtml.com> References: <48BEE585.40906@cchtml.com> Message-ID: <7f692fec0809031241x6efa2d67haf78d89e67a08dc9@mail.gmail.com> On Wed, Sep 3, 2008 at 3:29 PM, Mike Cronenworth wrote: > A few days ago Microsoft was granted a patent[1] on the functionality of > page up and page down. Today was the first time I've heard of this and it > seems that it's staying under the radar of most news sites. However this is > very real, unless I, and others are mistaken. I know Fedora has an > anti-patent stance on software included into itself, so what does this mean? > > Having Fun, > Michael > > > [1] http://news.zdnet.com/2424-9595_22-218626.html > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > IANAL, but I think this affects keyboard and cell phone manufacturers far more than us. There are really so many targets to choose from. I doubt it is a short term problem. -Yaakov From mlichvar at redhat.com Wed Sep 3 19:46:38 2008 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Wed, 3 Sep 2008 21:46:38 +0200 Subject: Dependency loops considered harmful? In-Reply-To: <604aa7910809031026j1ebabc7fyf85307254f451fb6@mail.gmail.com> References: <20080903165835.GA31342@localhost> <604aa7910809031026j1ebabc7fyf85307254f451fb6@mail.gmail.com> Message-ID: <20080903194638.GA13211@localhost> On Wed, Sep 03, 2008 at 09:26:38AM -0800, Jeff Spaleta wrote: > But the zlib loop? It touches so many packages I'm not sure it could > be deliberate decision. Can we avoid it? I don't know...it would > require the maintainers of all the packages in the loop to talk about > it. This one is ugly. It could be reduced dramatically by removing bash -> mktemp and glibc-common -> /bin/{ba,}sh dependencies, only two small loops glibc-common <-> glibc and pam <-> coreutils would remain. -- Miroslav Lichvar From stlwrt at gmail.com Wed Sep 3 19:50:03 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Wed, 3 Sep 2008 22:50:03 +0300 Subject: Microsoft patent affect Fedora? In-Reply-To: <48BEE585.40906@cchtml.com> References: <48BEE585.40906@cchtml.com> Message-ID: They also hold patent for scrollbar and other stuff they didn't invent. On Wed, Sep 3, 2008 at 10:29 PM, Mike Cronenworth wrote: > A few days ago Microsoft was granted a patent[1] on the functionality of > page up and page down. Today was the first time I've heard of this and it > seems that it's staying under the radar of most news sites. However this is > very real, unless I, and others are mistaken. I know Fedora has an > anti-patent stance on software included into itself, so what does this mean? > > Having Fun, > Michael > > > [1] http://news.zdnet.com/2424-9595_22-218626.html > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From jnovy at redhat.com Wed Sep 3 20:01:30 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Wed, 3 Sep 2008 22:01:30 +0200 Subject: Using lzma compressed tarball as Source0 In-Reply-To: <200809031745.51330.opensource@till.name> References: <200809031745.51330.opensource@till.name> Message-ID: <20080903200130.GA10618@dhcp-lab-186.brq.redhat.com> Hi, On Wed, Sep 03, 2008 at 05:45:41PM +0200, Till Maas wrote: > Hiyas, > > are there some best practices or some secret macros I can redifine to use a > lzma compressed tarball as Source0 for Fedora 8+ specs? > It would help if I could pass --use-compress-program=lzma to the tar > commandline that %setup uses. Note that rawhide RPM (to be rpm-4.6) supports expansion of lzma tarballs without any macro magic. %setup -q should handle it just fine. what it basically does is: /usr/bin/lzma -dc %{SOURCE0} | /bin/tar -xf - Jindrich -- Jindrich Novy http://people.redhat.com/jnovy/ From dcbw at redhat.com Wed Sep 3 20:14:50 2008 From: dcbw at redhat.com (Dan Williams) Date: Wed, 03 Sep 2008 16:14:50 -0400 Subject: Dependency loops considered harmful? In-Reply-To: <48BECBDA.6090102@hhs.nl> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> Message-ID: <1220472891.28633.3.camel@borkbork.foobar.com> On Wed, 2008-09-03 at 19:39 +0200, Hans de Goede wrote: > Michael Schwendt wrote: > > On Wed, 3 Sep 2008 18:58:35 +0200, Miroslav Lichvar wrote: > > > >> For example, why games data depend on binaries? > > > > I've also questioned that before. It boils down to a matter of > > convenience. It's packagers who say that the data pkgs are not usable > > without the game program, and therefore they want to avoid the > > scenario where somebody installs a game data pkg that doesn't result > > in a working game in the desktop menu. Hence game data and game > > program are tied to eachother in both directions. > > > > Actually its more about the removal scenario, lets say someone does: > df > yum install vegastrike (drags in vegastrike-data) > df (who thats big) > (hey that games sucks and eats up my HD-space) > yum remove vegastrike > df (WTF, why am I still missing 0.4 Gigs of HD-space ??) > > To avoid this the data packages depend upon the game binary, and vica versa the > game binary depends upon the data so that the data will get dragged in when > installing the game resulting in a working game. > > And no we will not just put them together, because re-releasing 300+ MB of > gamedata because the binary needs recompiling for a new lib is not cool! Wouldn't binary deltas make this issue just go away? We could put everything in the same package then and we wouldn't have to care about update sizes like this. Basically, if the only reason the packages are split in the first place is so you don't have to download everything all over again for a small update, then it seems like the correct thing to do is to make the update smaller, not complicate the package set... Dan > >> What do you think? Are loops something that we should try to avoid? > > > > Yes. IIRC, there are even some weird loops where after a package split > > a new sub-package depends on the main package and vice versa. > > > > Generally I agree, but their are exceptions, like game-engine <-> data > > Regards, > > Hans > From dcbw at redhat.com Wed Sep 3 20:18:16 2008 From: dcbw at redhat.com (Dan Williams) Date: Wed, 03 Sep 2008 16:18:16 -0400 Subject: NetworkManager-pptp In-Reply-To: <9497e9990809021520q6458cd39u3ff17f0144c8c5b6@mail.gmail.com> References: <9497e9990808300831t150c6036ydf4c453f3c822d48@mail.gmail.com> <1220364295.3176.19.camel@borkbork.foobar.com> <9497e9990809020820m67361762n7ed5db1bf7ad7946@mail.gmail.com> <1220369215.8041.15.camel@borkbork.foobar.com> <9497e9990809021520q6458cd39u3ff17f0144c8c5b6@mail.gmail.com> Message-ID: <1220473096.28633.5.camel@borkbork.foobar.com> On Tue, 2008-09-02 at 23:20 +0100, Mat Booth wrote: > On Tue, Sep 2, 2008 at 4:26 PM, Dan Williams wrote: > > On Tue, 2008-09-02 at 15:20 +0000, Mat Booth wrote: > >> No, I run with SELinux disabled because of work. It doesn't spit out > >> any message at all if I run it like that. > > > > Ok, how about if you run it like that, then try to connect your VPN > > connection via the GUI? > > > > Dan > > > > > > After some experimenting (and by experimenting I mean mostly just > dicking about with it :-), I may have made progress as now I'm getting > different output in /var/log/messages to what I reported originally. > > (As an aside, I've been having trouble getting settings to "stick" > when I change the VPN config. Often, after I hit ok and close and > reopen the nm-connection-editor, the settings have gone back to the > way they were before. I can't figure out a pattern to it yet, but I > obviously can't be confident that the settings I've chosen is the > config that's used. Could I be choosing some mutually exclusive > options that are being silently rejected? Where are my settings stored > on disk so I can verify them?) You could be; there are probably some combinations the GUI doesn't yet recognize as mutually exclusive. I can stick some logging info in there to print out the command line that gets passed to ppp if you like. Dan > Here's what I'm seeing now (this seems to include the stdout from > /usr/libexec/nm-pptp-service): > > Sep 2 23:03:45 sd NetworkManager: Starting VPN service > 'org.freedesktop.NetworkManager.pptp'... > Sep 2 23:03:45 sd NetworkManager: VPN service > 'org.freedesktop.NetworkManager.pptp' started > (org.freedesktop.NetworkManager.pptp), PID 11201 > Sep 2 23:03:45 sd NetworkManager: VPN service > 'org.freedesktop.NetworkManager.pptp' just appeared, activating > connections > Sep 2 23:03:45 sd NetworkManager: VPN plugin state changed: 3 > Sep 2 23:03:45 sd NetworkManager: VPN connection 'Servelec' > (Connect) reply received. > Sep 2 23:03:45 sd pppd[11202]: Plugin > /usr/lib64/pppd/2.4.4/nm-pptp-pppd-plugin.so loaded. > Sep 2 23:03:45 sd pppd[11202]: pppd 2.4.4 started by root, uid 0 > Sep 2 23:03:45 sd pppd[11202]: Using interface ppp0 > Sep 2 23:03:45 sd pppd[11202]: Connect: ppp0 <--> /dev/pts/3 > Sep 2 23:03:45 sd pptp[11203]: nm-pptp-service-11201 > log[main:pptp.c:276]: The synchronous pptp option is NOT activated > Sep 2 23:03:45 sd pptp[11210]: nm-pptp-service-11201 > log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 > 'Start-Control-Connection-Request' > Sep 2 23:03:45 sd pptp[11210]: nm-pptp-service-11201 > log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection > Reply > Sep 2 23:03:45 sd pptp[11210]: nm-pptp-service-11201 > log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established. > Sep 2 23:03:46 sd pptp[11210]: nm-pptp-service-11201 > log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 > 'Outgoing-Call-Request' > Sep 2 23:03:46 sd pptp[11210]: nm-pptp-service-11201 > log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply. > Sep 2 23:03:46 sd pptp[11210]: nm-pptp-service-11201 > log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, > peer's call ID 2560). > Sep 2 23:03:46 sd pptp[11210]: nm-pptp-service-11201 > log[ctrlp_disp:pptp_ctrl.c:949]: PPTP_SET_LINK_INFO received from > peer_callid 0 > Sep 2 23:03:46 sd pptp[11210]: nm-pptp-service-11201 > log[ctrlp_disp:pptp_ctrl.c:952]: send_accm is 00000000, recv_accm is > FFFFFFFF > Sep 2 23:03:46 sd pptp[11210]: nm-pptp-service-11201 > warn[ctrlp_disp:pptp_ctrl.c:955]: Non-zero Async Control Character > Maps are not supported! > Sep 2 23:03:46 sd pppd[11202]: LCP terminated by peer > (^HM-WoM-^H^@ Sep 2 23:03:46 sd pptp[11210]: nm-pptp-service-11201 > log[ctrlp_disp:pptp_ctrl.c:949]: PPTP_SET_LINK_INFO received from > peer_callid 0 > Sep 2 23:03:46 sd pptp[11210]: nm-pptp-service-11201 > log[ctrlp_disp:pptp_ctrl.c:952]: send_accm is FFFFFFFF, recv_accm is > FFFFFFFF > Sep 2 23:03:46 sd pptp[11210]: nm-pptp-service-11201 > warn[ctrlp_disp:pptp_ctrl.c:955]: Non-zero Async Control Character > Maps are not supported! > Sep 2 23:03:47 sd pptp[11210]: nm-pptp-service-11201 > log[ctrlp_disp:pptp_ctrl.c:911]: Received Call Clear Request. > Sep 2 23:03:49 sd pppd[11202]: Connection terminated. > Sep 2 23:03:49 sd pppd[11202]: Modem hangup > Sep 2 23:03:49 sd pptp[11203]: nm-pptp-service-11201 > warn[decaps_hdlc:pptp_gre.c:197]: short read (-1): Input/output error > Sep 2 23:03:49 sd pptp[11203]: nm-pptp-service-11201 > warn[decaps_hdlc:pptp_gre.c:209]: pppd may have shutdown, see pppd log > Sep 2 23:03:49 sd pptp[11210]: nm-pptp-service-11201 > log[callmgr_main:pptp_callmgr.c:231]: Closing connection (unhandled) > Sep 2 23:03:49 sd pptp[11210]: nm-pptp-service-11201 > log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 > 'Call-Clear-Request' > Sep 2 23:03:49 sd pptp[11210]: nm-pptp-service-11201 > log[call_callback:pptp_callmgr.c:78]: Closing connection (call state) > Sep 2 23:03:49 sd pppd[11202]: Exit. > Sep 2 23:03:49 sd NetworkManager: VPN plugin state changed: 6 > Sep 2 23:03:49 sd NetworkManager: connection_state_changed(): > Could not process the request because no VPN connection was active. > > Thanks for your help. > Mat > > -- > Mat Booth > www.matbooth.co.uk > From dominik at greysector.net Wed Sep 3 20:37:03 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 3 Sep 2008 22:37:03 +0200 Subject: xmms heads up In-Reply-To: <20080903171001.b9a403f7.mschwendt@gmail.com> References: <1220394346.7539.3.camel@PB3.Linux> <20080903171001.b9a403f7.mschwendt@gmail.com> Message-ID: <20080903203702.GB10088@mokona.greysector.net> On Wednesday, 03 September 2008 at 17:10, Michael Schwendt wrote: > On Tue, 02 Sep 2008 23:25:46 +0100, Paul wrote: > > > I've just built xmms-1.2.11-20071117cvs for rawhide. It should hit > > whenever there is a rawhide push (god knows when that will be ;-p). > > You've reverted the licence fix in the spec file and removed also > the corresponding changelog entry. Why? I bet he used cvs-import.sh. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From csnook at redhat.com Wed Sep 3 20:59:17 2008 From: csnook at redhat.com (Chris Snook) Date: Wed, 03 Sep 2008 16:59:17 -0400 Subject: Dependency loops considered harmful? In-Reply-To: <9448.198.175.55.5.1220461813.squirrel@mail.jcomserv.net> References: <20080903165835.GA31342@localhost> <9448.198.175.55.5.1220461813.squirrel@mail.jcomserv.net> Message-ID: <48BEFAA5.7010001@redhat.com> Jon Ciesla wrote: >> Hi, >> >> I've noticed that we have quite a lot of dependency loops in >> repositories. The current i386 rawhide has 354 packages which are part >> of one or more loops. >> >> Is that ok? I've always thought it's something that should be avoided >> as it makes life harder for rpm, yum and users trying to manually >> install or remove rpms. I even remember few incidents where a loop >> caused serious troubles when installing packages with scriptlets. >> >> Full list of the packages is here: >> http://fedorapeople.org/~mlichvar/tmp/rawhide.i386.loops >> >> For example, why games data depend on binaries? > > So that if we try to upgrade the version of the binaries and not the data, > it will fail. We can still bump the release in most cases, allowing for > minot fixes without requiring the user to download the same data again. It sounds like people are using Requires: foo >= X where they should be using Conflicts: foo < X. There's no harm done if you install a game data file and the game isn't installed. Please don't create dependency loops. -- Chris From lmacken at redhat.com Wed Sep 3 21:00:44 2008 From: lmacken at redhat.com (Luke Macken) Date: Wed, 3 Sep 2008 17:00:44 -0400 Subject: Fedora Security Tools spin In-Reply-To: <48BE1F95.2090509@redhat.com> References: <48BE023A.70703@redhat.com> <20080903035605.GE25264@inocybe.teonanacatl.org> <48BE1F95.2090509@redhat.com> Message-ID: <20080903210044.GF3726@x300> On Wed, Sep 03, 2008 at 10:54:37AM +0530, Huzaifa Sidhpurwala wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Todd Zullinger wrote: > > Huzaifa Sidhpurwala wrote: > >> I just came across a knoppix security tool live CD and thought it > >> would be a good idea for a security tool fedora spin too. > >> The tools are freely available at: > >> > >> http://knoppix-std.org/index.html > >> and are all GPLed? > >> > >> Do you guys think this is a good idea, I am sure such a spin does > >> not exists in Fedora yet. > > > > Do you mean something like Luke Macken put together? > > > > http://fedoraproject.org/wiki/LukeMacken/SecurityLiveCD > > > > > Yeah but more tools and more bare bones, > Perhaps i can assist Luke in this? Absolutely! I'm in the process of rebasing the kickstart against the latest livecd base, and I will be pushing it through the New Spin Process soon. More tools? Yes. I want it to ship with every security tool in Fedora. If you know of any that are missing from the list, please let me know. More bare bones? The current livecd is based off of the minimal kickstart configuration, and uses openbox as opposed to GNOME. If you have any suggestions for making it more "bare bones", let me know. luke From james.antill at redhat.com Wed Sep 3 21:03:28 2008 From: james.antill at redhat.com (James Antill) Date: Wed, 03 Sep 2008 17:03:28 -0400 Subject: Dependency loops considered harmful? In-Reply-To: <604aa7910809031131q3b7613b7n2d965a68a81572dc@mail.gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED58F.3080301@ioa.s.u-tokyo.ac.jp> <604aa7910809031131q3b7613b7n2d965a68a81572dc@mail.gmail.com> Message-ID: <1220475808.3862.302.camel@code.and.org> On Wed, 2008-09-03 at 10:31 -0800, Jeff Spaleta wrote: > On Wed, Sep 3, 2008 at 10:21 AM, Mamoru Tasaka > wrote: > > Umm... agreed. > > When I install some binary rpms rebuilt by koji scratch build to review > > the package it often pulls so many depdendencies, especially when they > > are Java packages. > > What's the overall drive consumption when you do that? The issue isnt > "number of packages" the issue is "amount of harddrive space." Game > data make be exceptional in that that are typically as large or larger > than 200M. Pulling in java deps might pollute your packagelist..but > does it burn 200M+ of harddrive space? Err, so? 500GB drives are now like < $100, that's $1 == 5GB, ?10 == 500MB. So personally I'd argue that more packages are worse, even if you talk about bandwidth instead of storage ... the large collection of Java etc. is much more likely to get updates than the game data (and it's much easier to see the game data, if it does get an update). > I hope the packagekit people are watching this discussion. The game > data subpackaging issue should be right up their ally in terms of > end-user ease of use issues. It's unlikely to be a priority if the dep. loops are included, also the only obvious fix is to keep extra data outside of rpm/yum ... and if yum shouldn't be doing that to rpm then PK _really_ shouldn't be doing that. -- James Antill Red Hat -------------- 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 Sep 3 21:15:43 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 3 Sep 2008 13:15:43 -0800 Subject: Dependency loops considered harmful? In-Reply-To: <1220475808.3862.302.camel@code.and.org> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED58F.3080301@ioa.s.u-tokyo.ac.jp> <604aa7910809031131q3b7613b7n2d965a68a81572dc@mail.gmail.com> <1220475808.3862.302.camel@code.and.org> Message-ID: <604aa7910809031415p22bfda89s5d359f63ca712e18@mail.gmail.com> 2008/9/3 James Antill : > It's unlikely to be a priority if the dep. loops are included, also the > only obvious fix is to keep extra data outside of rpm/yum ... and if yum > shouldn't be doing that to rpm then PK _really_ shouldn't be doing that. I didnt say that PK should be doing it... I said that the PK developers should be aware of this discussion because it goes to the heart of PK's stated purpose. At some point someone is going to have to wade into rpm itself for ease of use of removals to get better. And this is what we are talking about here... ease of use on package removal. Something we don't do well with at all in any package removal situation. I am interesting in making sure that the people with the right motivation and the right skills find the right way to handle it. That's not going to happen just by telling the current maintainers who are abusing the available requires syntax that they are abusing the syntax and slapping their wrists. -jef From johannbg at hi.is Wed Sep 3 21:30:20 2008 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Wed, 03 Sep 2008 21:30:20 +0000 Subject: NetworkManager-pptp In-Reply-To: <1220473096.28633.5.camel@borkbork.foobar.com> References: <9497e9990808300831t150c6036ydf4c453f3c822d48@mail.gmail.com> <1220364295.3176.19.camel@borkbork.foobar.com> <9497e9990809020820m67361762n7ed5db1bf7ad7946@mail.gmail.com> <1220369215.8041.15.camel@borkbork.foobar.com> <9497e9990809021520q6458cd39u3ff17f0144c8c5b6@mail.gmail.com> <1220473096.28633.5.camel@borkbork.foobar.com> Message-ID: <48BF01EC.5000107@hi.is> I get authenticated and an IP address but no route/gateway seems to be set hence my connection breaks.. Sep 3 21:20:21 localhost NetworkManager: nm_device_wifi_get_ssid(): Couldn't get SSID: 7 Sep 3 21:20:27 localhost NetworkManager: nm_device_wifi_get_ssid(): Couldn't get SSID: 7 Sep 3 21:20:29 localhost NetworkManager: Starting VPN service 'org.freedesktop.NetworkManager.pptp'... Sep 3 21:20:29 localhost NetworkManager: VPN service 'org.freedesktop.NetworkManager.pptp' started (org.freedesktop.NetworkManager.pptp), PID 10774 Sep 3 21:20:29 localhost NetworkManager: VPN service 'org.freedesktop.NetworkManager.pptp' just appeared, activating connections Sep 3 21:20:29 localhost NetworkManager: VPN plugin state changed: 1 Sep 3 21:20:29 localhost NetworkManager: VPN plugin state changed: 3 Sep 3 21:20:29 localhost pppd[10777]: Plugin /usr/lib64/pppd/2.4.4/nm-pptp-pppd-plugin.so loaded. Sep 3 21:20:29 localhost pppd[10777]: pppd 2.4.4 started by root, uid 0 Sep 3 21:20:29 localhost NetworkManager: VPN connection 'H?sk?li ?slands' (Connect) reply received. Sep 3 21:20:29 localhost pppd[10777]: Using interface ppp0 Sep 3 21:20:29 localhost pppd[10777]: Connect: ppp0 <--> /dev/pts/0 Sep 3 21:20:29 localhost pptp[10778]: nm-pptp-service-10774 log[main:pptp.c:276]: The synchronous pptp option is NOT activated Sep 3 21:20:29 localhost pptp[10785]: nm-pptp-service-10774 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request' Sep 3 21:20:29 localhost pptp[10785]: nm-pptp-service-10774 log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply Sep 3 21:20:29 localhost pptp[10785]: nm-pptp-service-10774 log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established. Sep 3 21:20:30 localhost pptp[10785]: nm-pptp-service-10774 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request' Sep 3 21:20:30 localhost pptp[10785]: nm-pptp-service-10774 log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply. Sep 3 21:20:30 localhost pptp[10785]: nm-pptp-service-10774 log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 23552). Sep 3 21:20:30 localhost pppd[10777]: CHAP authentication succeeded Sep 3 21:20:30 localhost pppd[10777]: MPPE 128-bit stateless compression enabled Sep 3 21:20:30 localhost pppd[10777]: local IP address 130.208.179.98 Sep 3 21:20:30 localhost pppd[10777]: remote IP address 130.208.165.95 Sep 3 21:20:30 localhost pppd[10777]: primary DNS address 130.208.165.10 Sep 3 21:20:30 localhost pppd[10777]: secondary DNS address 130.208.165.82 Sep 3 21:20:30 localhost NetworkManager: VPN connection 'H?sk?li ?slands' (IP Config Get) reply received. Sep 3 21:20:30 localhost NetworkManager: VPN Gateway: 0.0.0.0 Sep 3 21:20:30 localhost NetworkManager: Tunnel Device: ppp0 Sep 3 21:20:30 localhost NetworkManager: Internal IP4 Address: 130.208.179.98 Sep 3 21:20:30 localhost NetworkManager: Internal IP4 Prefix: 32 Sep 3 21:20:30 localhost NetworkManager: Internal IP4 Point-to-Point Address: 0.0.0.0 Sep 3 21:20:30 localhost NetworkManager: Maximum Segment Size (MSS): 0 Sep 3 21:20:30 localhost NetworkManager: Internal IP4 DNS: 130.208.165.10 Sep 3 21:20:30 localhost NetworkManager: Internal IP4 DNS: 130.208.165.82 Sep 3 21:20:30 localhost NetworkManager: DNS Domain: '(none)' Sep 3 21:20:30 localhost NetworkManager: Login Banner: Sep 3 21:20:30 localhost NetworkManager: ----------------------------------------- Sep 3 21:20:30 localhost NetworkManager: (null) Sep 3 21:20:30 localhost NetworkManager: ----------------------------------------- Sep 3 21:20:30 localhost NetworkManager: VPN connection 'H?sk?li ?slands' (IP Config Get) complete. Sep 3 21:20:30 localhost NetworkManager: VPN plugin state changed: 4 Sep 3 21:20:33 localhost NetworkManager: nm_device_wifi_get_ssid(): Couldn't get SSID: 7 Sep 3 21:20:39 localhost NetworkManager: nm_device_wifi_get_ssid(): Couldn't get SSID: 7 ^C [root at localhost ~]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default dsldevice.lan 255.255.255.255 UGH 0 0 0 wlan0 192.168.1.0 * 255.255.255.0 U 0 0 0 wlan0 default * 0.0.0.0 U 0 0 0 ppp0 [root at localhost ~]# Everything working with the pptp-client.... Sep 3 21:24:33 localhost NetworkManager: nm_device_wifi_get_ssid(): Couldn't get SSID: 7 Sep 3 21:24:38 localhost pppd[11033]: pppd 2.4.4 started by root, uid 0 Sep 3 21:24:38 localhost pppd[11033]: Using interface ppp0 Sep 3 21:24:38 localhost pppd[11033]: Connect: ppp0 <--> /dev/pts/0 Sep 3 21:24:38 localhost pptp[11034]: anon log[main:pptp.c:276]: The synchronous pptp option is NOT activated Sep 3 21:24:38 localhost pptp[11041]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request' Sep 3 21:24:39 localhost pptp[11041]: anon log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply Sep 3 21:24:39 localhost pptp[11041]: anon log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established. Sep 3 21:24:39 localhost NetworkManager: nm_device_wifi_get_ssid(): Couldn't get SSID: 7 Sep 3 21:24:39 localhost pptp[11041]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request' Sep 3 21:24:40 localhost pptp[11041]: anon log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply. Sep 3 21:24:40 localhost pptp[11041]: anon log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 24064). Sep 3 21:24:40 localhost pppd[11033]: CHAP authentication succeeded Sep 3 21:24:40 localhost pppd[11033]: MPPE 128-bit stateless compression enabled Sep 3 21:24:40 localhost pppd[11033]: local IP address 130.208.179.22 Sep 3 21:24:40 localhost pppd[11033]: remote IP address 130.208.165.95 Sep 3 21:24:40 localhost pppd[11033]: primary DNS address 130.208.165.10 Sep 3 21:24:40 localhost pppd[11033]: secondary DNS address 130.208.165.82 Sep 3 21:24:45 localhost NetworkManager: nm_device_wifi_get_ssid(): Couldn't get SSID: 7 Sep 3 21:24:51 localhost NetworkManager: nm_device_wifi_get_ssid(): Couldn't get SSID: 7 ^C [root at localhost ~]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface hel.rhi.hi.is * 255.255.255.255 UH 0 0 0 ppp0 vpnx.rhi.hi.is rfc1918.rhi.hi. 255.255.255.255 UGH 0 0 0 wlan0 192.168.1.0 * 255.255.255.0 U 0 0 0 wlan0 default * 0.0.0.0 U 0 0 0 ppp0 [root at localhost ~]# Best regards Johann B. From dledford at redhat.com Wed Sep 3 22:20:44 2008 From: dledford at redhat.com (Doug Ledford) Date: Wed, 03 Sep 2008 18:20:44 -0400 Subject: Some initial discussions of a Fedora HPC SIG In-Reply-To: References: Message-ID: <1220480445.19330.11.camel@firewall.xsintricity.com> On Fri, 2008-08-29 at 09:44 -0700, Shawn Starr wrote: > Hello everyone, > > It would be great if we can kick off the SIG. > > 1) Which day and time would be good for the meetings in #fedora-meeting > > The available times are here: http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel I'm free most days after about 14:00 or 15:00UTC. > 2) Let's come up with an initial agenda. Defining what should be in a reasonably complete HPC Comps group Define a complete component list Pick which of those components should be default vs. optional Identify packages not yet in Fedora that are on the list and allow people to sign up to get them through a review process and in Fedora Identify any shortcomings in upstream standards for HPC packages (there's a lot here, eg. the upstream MPI groups don't have the faintest clue on how to get together and create a standard installation layout or anything else) Where upstream has no clue about doing things in a standard way, at least work to create one inside the framework of Fedora and attempt to push it to upstream if they are receptive of the idea. Identify packages in Fedora that need updating/changing to meet said standards Allow people to sign up to work those changes if the package maintainer is unable to do so Something along those lines ought to get things started. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From erik at vanpienbroek.nl Wed Sep 3 22:22:10 2008 From: erik at vanpienbroek.nl (Erik van Pienbroek) Date: Thu, 04 Sep 2008 00:22:10 +0200 Subject: Horrible memory leak in rawhide (kernel leak?) Message-ID: <1220480530.21146.32.camel@alguno.terneuzen.openftd.org> Hi, The last few days I've had a horrible memory leak on Rawhide. The problem is: I can't find out what's causing it. According to 'top' there aren't any userspace processes which are using lots of memory, but according to 'slabtop' there is 'kmalloc-32' which is using excessive amounts of memory. This looks like something in the kernel to me. Killing services or the whole X server don't help in getting the memory released. The strange thing is I'm having this leak on 2 individual computers with completely different hardware (one is a desktop, the other is a notebook). This leak makes my systems unusable after some time (due to all userspace processes being put in the swap). The leak itself seems to be dependent on the user activity. If I leave the computer mostly idle (just Evolution and X-Chat running in the background) the leak isn't as bad as when there's lots a activity. If I play a game (using wine) for example, I need to reboot after a few hours because there's no memory left for userspace processes (everything is being swapped). Is there anybody else here who is also encountering this strange leak? Of does anybody have an idea how to make a proper diagnosis about this problem? My desktop is an Pentium 4 2.4Ghz with 1GB ram $ lspci 00:00.0 Host bridge: Intel Corporation 82845 845 [Brookdale] Chipset Host Bridge (rev 11) 00:01.0 PCI bridge: Intel Corporation 82845 845 [Brookdale] Chipset AGP Bridge (rev 11) 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 81) 00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) 01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7800 GS] (rev a2) 02:03.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 02) 02:03.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 02) 02:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 02:05.0 Mass storage controller: Silicon Image, Inc. SiI 3112 [SATALink/SATARaid] Serial ATA Controller (rev 02) 02:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 02:09.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10) My notebook is an Asus F3SV, which contains an Intel C2D 2.0Ghz with 3GB RAM. $ lspci 00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 03) 00:01.0 PCI bridge: Intel Corporation Mobile PM965/GM965/GL960 PCI Express Root Port (rev 03) 00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03) 00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03) 00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03) 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03) 00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03) 00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 03) 00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03) 00:1c.5 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 6 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3) 00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03) 00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03) 00:1f.2 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA IDE Controller (rev 03) 01:00.0 VGA compatible controller: nVidia Corporation GeForce 8600M GS (rev a1) 02:00.0 Ethernet controller: Attansic Technology Corp. L1 Gigabit Ethernet Adapter (rev b0) 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) 09:01.0 FireWire (IEEE 1394): Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 05) 09:01.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 22) 09:01.2 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 12) 09:01.3 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 12) As you can see both the computers contain an nVidia video card. Before blaming the propetiary nVidia drivers, only my notebook uses those, so the problem probably isn't in those drivers. I've tried several different Rawhide kernels (from 2.6.27-0.208.rc1.git2 to the latest of today) but they all have the same problem. I've managed to save the output of slaptop and the contents of /proc/slabinfo when the memory usage was horrible again. Maybe someone can find some useful information in them. They are published at http://ftd4linux.nl/contrib/slabtop and http://ftd4linux.nl/contrib/slabinfo Kind regards, Erik van Pienbroek From jonathan at jonmasters.org Wed Sep 3 22:31:42 2008 From: jonathan at jonmasters.org (Jon Masters) Date: Wed, 03 Sep 2008 18:31:42 -0400 Subject: Horrible memory leak in rawhide (kernel leak?) In-Reply-To: <1220480530.21146.32.camel@alguno.terneuzen.openftd.org> References: <1220480530.21146.32.camel@alguno.terneuzen.openftd.org> Message-ID: <1220481102.18552.47.camel@jcmlaptop.bos.redhat.com> On Thu, 2008-09-04 at 00:22 +0200, Erik van Pienbroek wrote: > The last few days I've had a horrible memory leak on Rawhide. Haven't looked into this but cebbert mentioned a kernel memory leak has been fixed in rawhide as of today - I'd try again tomorrow or perhaps the day after unless you want to pull from koji directly. Jon. From erik at vanpienbroek.nl Wed Sep 3 22:45:14 2008 From: erik at vanpienbroek.nl (Erik van Pienbroek) Date: Thu, 04 Sep 2008 00:45:14 +0200 Subject: Horrible memory leak in rawhide (kernel leak?) In-Reply-To: <1220481102.18552.47.camel@jcmlaptop.bos.redhat.com> References: <1220480530.21146.32.camel@alguno.terneuzen.openftd.org> <1220481102.18552.47.camel@jcmlaptop.bos.redhat.com> Message-ID: <1220481914.21146.34.camel@alguno.terneuzen.openftd.org> Op woensdag 03-09-2008 om 18:31 uur [tijdzone -0400], schreef Jon Masters: > On Thu, 2008-09-04 at 00:22 +0200, Erik van Pienbroek wrote: > > > The last few days I've had a horrible memory leak on Rawhide. > > Haven't looked into this but cebbert mentioned a kernel memory leak has > been fixed in rawhide as of today - I'd try again tomorrow or perhaps > the day after unless you want to pull from koji directly. Hi, I just looked at the koji webinterface for the latest build of the kernel and this is 2.6.27-0.297.rc5.git2.fc10 which was already in todays push...And with this kernel I'm still having the leak. Regards, Erik van Pienbroek From kyle at mcmartin.ca Wed Sep 3 22:56:17 2008 From: kyle at mcmartin.ca (Kyle McMartin) Date: Wed, 3 Sep 2008 18:56:17 -0400 Subject: Horrible memory leak in rawhide (kernel leak?) In-Reply-To: <1220481914.21146.34.camel@alguno.terneuzen.openftd.org> References: <1220480530.21146.32.camel@alguno.terneuzen.openftd.org> <1220481102.18552.47.camel@jcmlaptop.bos.redhat.com> <1220481914.21146.34.camel@alguno.terneuzen.openftd.org> Message-ID: <20080903225617.GB20807@phobos.i.cabal.ca> On Thu, Sep 04, 2008 at 12:45:14AM +0200, Erik van Pienbroek wrote: > Op woensdag 03-09-2008 om 18:31 uur [tijdzone -0400], schreef Jon > Masters: > > On Thu, 2008-09-04 at 00:22 +0200, Erik van Pienbroek wrote: > > > > > The last few days I've had a horrible memory leak on Rawhide. > > > > Haven't looked into this but cebbert mentioned a kernel memory leak has > > been fixed in rawhide as of today - I'd try again tomorrow or perhaps > > the day after unless you want to pull from koji directly. > > Hi, > > I just looked at the koji webinterface for the latest build of the > kernel and this is 2.6.27-0.297.rc5.git2.fc10 which was already in > todays push...And with this kernel I'm still having the leak. > Are you using selinux? Try booting with selinux=0 (I know, the relabelling afterwards sucks...) and seeing if it still occurs. I believe someone tracked some bogosity into selinux, but hasn't been able to root-cause it yet. regards, Kyle From selinux at gmail.com Wed Sep 3 23:07:30 2008 From: selinux at gmail.com (Tom London) Date: Wed, 3 Sep 2008 16:07:30 -0700 Subject: Horrible memory leak in rawhide (kernel leak?) In-Reply-To: <20080903225617.GB20807@phobos.i.cabal.ca> References: <1220480530.21146.32.camel@alguno.terneuzen.openftd.org> <1220481102.18552.47.camel@jcmlaptop.bos.redhat.com> <1220481914.21146.34.camel@alguno.terneuzen.openftd.org> <20080903225617.GB20807@phobos.i.cabal.ca> Message-ID: <4c4ba1530809031607u5bf36591na6a7513b84fae4e9@mail.gmail.com> On Wed, Sep 3, 2008 at 3:56 PM, Kyle McMartin wrote: > On Thu, Sep 04, 2008 at 12:45:14AM +0200, Erik van Pienbroek wrote: >> Op woensdag 03-09-2008 om 18:31 uur [tijdzone -0400], schreef Jon >> Masters: >> > On Thu, 2008-09-04 at 00:22 +0200, Erik van Pienbroek wrote: >> > >> > > The last few days I've had a horrible memory leak on Rawhide. >> > >> > Haven't looked into this but cebbert mentioned a kernel memory leak has >> > been fixed in rawhide as of today - I'd try again tomorrow or perhaps >> > the day after unless you want to pull from koji directly. >> >> Hi, >> >> I just looked at the koji webinterface for the latest build of the >> kernel and this is 2.6.27-0.297.rc5.git2.fc10 which was already in >> todays push...And with this kernel I'm still having the leak. >> > > Are you using selinux? Try booting with selinux=0 (I know, the > relabelling afterwards sucks...) and seeing if it still occurs. > I believe someone tracked some bogosity into selinux, but hasn't been > able to root-cause it yet. > > regards, Kyle > > -- Could this be what you are experiencing: https://bugzilla.redhat.com/show_bug.cgi?id=460848 ? If so, there is a patch that "works for me". Expect this to be in rawhide soon. tom -- Tom London From seg at haxxed.com Wed Sep 3 23:16:06 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 03 Sep 2008 18:16:06 -0500 Subject: Dependency loops considered harmful? In-Reply-To: <48BED37A.5020706@redhat.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> Message-ID: <1220483766.4415.19.camel@localhost.localdomain> On Wed, 2008-09-03 at 14:12 -0400, Stephen Gallagher wrote: > Applications that consist of multiple packages, such as the game > example, should be designated as a group rather than a looped > dependency. Actually a proper fix is to implement the per-package "explicitly installed/pulled in as a dep" flag that has been discussed several times in the past, and is already implemented (thus proven) in the "aptitude" apt front end. We must address this user interface problem if Fedora is to be a shining beacon of open source light in the looming dark future of closed DRM-laden content delivery services such as Steam, Xbox Live and PlayStation Network. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From csnook at redhat.com Wed Sep 3 23:24:48 2008 From: csnook at redhat.com (Chris Snook) Date: Wed, 03 Sep 2008 19:24:48 -0400 Subject: ext4 testing in the F10 release cycle In-Reply-To: <48BEBFB4.3050208@redhat.com> References: <48BEB8F8.9050902@redhat.com> <5256d0b0809030939wf131878rcf8e433eb4e1444c@mail.gmail.com> <48BEBFB4.3050208@redhat.com> Message-ID: <48BF1CC0.9050406@redhat.com> Eric Sandeen wrote: > Peter Robinson wrote: > >> Do you have recommended FS creation parameters for SSDs? > > Not really; there has unfortunately been very little (or no) > optimization of ext4 for SSDs at this point ... > > It'd probably be an allocator heuristic change but nobody's looked into > that yet. > > Once we get ext4 raid-geometry-aware, we can probably use some of that > geometry info to better match up with the erase block sizes on an SSD at > least... In my testing (without a filesystem), raid-optimized access works quite well on SSDs, so that should carry over quite effortlessly. The places where we need work are: a) Make jbd do fewer small writes. b) Write a partitioning tool that doesn't suck the way fdisk and parted do, so we can partition properly for the geometry of modern storage. c) Put an alignment option in the installer, so people can optimize their partitions and filesystems for SSDs, RAID, and anything else where alignment matters. -- Chris From a.badger at gmail.com Wed Sep 3 23:41:56 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 03 Sep 2008 16:41:56 -0700 Subject: Dependency loops considered harmful? In-Reply-To: <1220483766.4415.19.camel@localhost.localdomain> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> Message-ID: <48BF20C4.4050500@gmail.com> Callum Lerwick wrote: > On Wed, 2008-09-03 at 14:12 -0400, Stephen Gallagher wrote: >> Applications that consist of multiple packages, such as the game >> example, should be designated as a group rather than a looped >> dependency. > > Actually a proper fix is to implement the per-package "explicitly > installed/pulled in as a dep" flag that has been discussed several times > in the past, and is already implemented (thus proven) in the "aptitude" > apt front end. > > We must address this user interface problem if Fedora is to be a shining > beacon of open source light in the looming dark future of closed > DRM-laden content delivery services such as Steam, Xbox Live and > PlayStation Network. > That works for a Mom and Pop desktop but doesn't work as a developer's workstation. When developing software you might need a library that does Foo. Look on the system, hey, I can use libFoo! A few weeks later, when you remove Gnome-Foo from your system because your shiny new application does the job, your app suddenly can't find libFoo.... (Worse is if your working on an app sporadically and have to figure out why it's broken not knowing when it became that way.) So if we track this some way, there needs to be a way to disable it. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From seandarcy2 at gmail.com Thu Sep 4 01:03:27 2008 From: seandarcy2 at gmail.com (sean darcy) Date: Wed, 03 Sep 2008 21:03:27 -0400 Subject: Help Needed: Figure out F9 Updates PackageKit deps In-Reply-To: <48BDC15E.5030006@redhat.com> References: <48BDA6D5.1070504@redhat.com> <48BDC15E.5030006@redhat.com> Message-ID: Warren Togami wrote: > Thomas M Steenholdt wrote: >> >> I guess the test packages (fedora-release and packagekit) can be found >> in koji, but I just want to make sure, the right version of the >> packages are being tested here. Which versions of these packages do >> you have in mind? > > The latest PackageKit* in F9 updates now. > ?? yum clean all Loaded plugins: refresh-packagekit Cleaning up Everything [root at notebook ~]# yum upgrade PackageKit* Loaded plugins: refresh-packagekit fedora | 2.4 kB 00:00 primary.sqlite.bz2 | 6.1 MB 00:24 updates | 2.3 kB 00:00 primary.sqlite.bz2 | 2.3 MB 00:08 Setting up Upgrade Process Could not find update match for PackageKit* No Packages marked for Update If it's in update how do you get it. fwiw, I also tried koji download-build PackageKit. sean From sandeen at redhat.com Thu Sep 4 01:04:34 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 03 Sep 2008 20:04:34 -0500 Subject: ext4 testing in the F10 release cycle In-Reply-To: <48BF1CC0.9050406@redhat.com> References: <48BEB8F8.9050902@redhat.com> <5256d0b0809030939wf131878rcf8e433eb4e1444c@mail.gmail.com> <48BEBFB4.3050208@redhat.com> <48BF1CC0.9050406@redhat.com> Message-ID: <48BF3422.5060601@redhat.com> Chris Snook wrote: > Eric Sandeen wrote: >> Peter Robinson wrote: >> >>> Do you have recommended FS creation parameters for SSDs? >> Not really; there has unfortunately been very little (or no) >> optimization of ext4 for SSDs at this point ... >> >> It'd probably be an allocator heuristic change but nobody's looked into >> that yet. >> >> Once we get ext4 raid-geometry-aware, we can probably use some of that >> geometry info to better match up with the erase block sizes on an SSD at >> least... > > In my testing (without a filesystem), raid-optimized access works quite well on > SSDs, so that should carry over quite effortlessly. The places where we need > work are: > > a) Make jbd do fewer small writes. > > b) Write a partitioning tool that doesn't suck the way fdisk and parted do, so > we can partition properly for the geometry of modern storage. parted and fdisk can do 512-byte sector granularity; what do you need here? > c) Put an alignment option in the installer, so people can optimize their > partitions and filesystems for SSDs, RAID, and anything else where alignment > matters. mkfs should be doing this, not the installer. mkfs.xfs does; mkfs.ext$FOO should too. -Eric > -- Chris > From sandeen at redhat.com Thu Sep 4 01:05:25 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 03 Sep 2008 20:05:25 -0500 Subject: ext4 testing in the F10 release cycle In-Reply-To: <48BF3422.5060601@redhat.com> References: <48BEB8F8.9050902@redhat.com> <5256d0b0809030939wf131878rcf8e433eb4e1444c@mail.gmail.com> <48BEBFB4.3050208@redhat.com> <48BF1CC0.9050406@redhat.com> <48BF3422.5060601@redhat.com> Message-ID: <48BF3455.6040509@redhat.com> Eric Sandeen wrote: > Chris Snook wrote: >> Eric Sandeen wrote: >>> Peter Robinson wrote: >>> >>>> Do you have recommended FS creation parameters for SSDs? >>> Not really; there has unfortunately been very little (or no) >>> optimization of ext4 for SSDs at this point ... >>> >>> It'd probably be an allocator heuristic change but nobody's looked into >>> that yet. >>> >>> Once we get ext4 raid-geometry-aware, we can probably use some of that >>> geometry info to better match up with the erase block sizes on an SSD at >>> least... >> In my testing (without a filesystem), raid-optimized access works quite well on >> SSDs, so that should carry over quite effortlessly. The places where we need >> work are: >> >> a) Make jbd do fewer small writes. >> >> b) Write a partitioning tool that doesn't suck the way fdisk and parted do, so >> we can partition properly for the geometry of modern storage. > > parted and fdisk can do 512-byte sector granularity; what do you need here? > >> c) Put an alignment option in the installer, so people can optimize their >> partitions and filesystems for SSDs, RAID, and anything else where alignment >> matters. > > mkfs should be doing this, not the installer. mkfs.xfs does; > mkfs.ext$FOO should too. > > -Eric > >> -- Chris >> > From sandeen at redhat.com Thu Sep 4 01:06:17 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 03 Sep 2008 20:06:17 -0500 Subject: ext4 testing in the F10 release cycle In-Reply-To: <48BF3422.5060601@redhat.com> References: <48BEB8F8.9050902@redhat.com> <5256d0b0809030939wf131878rcf8e433eb4e1444c@mail.gmail.com> <48BEBFB4.3050208@redhat.com> <48BF1CC0.9050406@redhat.com> <48BF3422.5060601@redhat.com> Message-ID: <48BF3489.6040505@redhat.com> Eric Sandeen wrote: > Chris Snook wrote: >> c) Put an alignment option in the installer, so people can optimize their >> partitions and filesystems for SSDs, RAID, and anything else where alignment >> matters. > > mkfs should be doing this, not the installer. mkfs.xfs does; > mkfs.ext$FOO should too. > > -Eric I should qualify that; "can" if it's on storage that can be queried (md, lvm, etc - but not some random hardware scsi lun ... for that case perhaps installer tweaks maybe, but how often do you really install onto these things at anaconda-time? -Eric From noriko at redhat.com Thu Sep 4 01:08:52 2008 From: noriko at redhat.com (Noriko Mizumoto) Date: Thu, 04 Sep 2008 11:08:52 +1000 Subject: F10 Schedule Message-ID: <48BF3524.4080805@redhat.com> Hi devel team I am Noriko Mizumoto, Fedora Japanese translator of Fedora Localization Project. Recently I've learnt that the F10 schedule has been delayed three weeks with some reason. And I believe that this must be a great chance to ask you to have a little more adjustment on the schedule, which we've been asking for long but never happened. Currently 'Feature freeze' and 'String freeze' are same day. This makes no room for translators to work. If we could have the string freeze 5 days before the feature freeze, all translators would be happy to complete their work. It would be much appreciated if you could once consider this matter. Thank you for listening to the end. noriko From csnook at redhat.com Thu Sep 4 01:18:35 2008 From: csnook at redhat.com (Chris Snook) Date: Wed, 03 Sep 2008 21:18:35 -0400 Subject: Microsoft patent affect Fedora? In-Reply-To: <48BEE585.40906@cchtml.com> References: <48BEE585.40906@cchtml.com> Message-ID: <48BF376B.3080307@redhat.com> Mike Cronenworth wrote: > A few days ago Microsoft was granted a patent[1] on the functionality of > page up and page down. Today was the first time I've heard of this and > it seems that it's staying under the radar of most news sites. However > this is very real, unless I, and others are mistaken. I know Fedora has > an anti-patent stance on software included into itself, so what does > this mean? > > Having Fun, > Michael > > > [1] http://news.zdnet.com/2424-9595_22-218626.html > Nothing, unless Legal says otherwise. -- Chris From fedora at slated.org Thu Sep 4 01:12:31 2008 From: fedora at slated.org (Keith G. Robertson-Turner) Date: Thu, 04 Sep 2008 02:12:31 +0100 Subject: Microsoft patent affect Fedora? In-Reply-To: <48BEE585.40906@cchtml.com> References: <48BEE585.40906@cchtml.com> Message-ID: <19p3p5-2ju.ln1@sky.matrix> Verily I say unto thee, that Mike Cronenworth spake thusly: > A few days ago Microsoft was granted a patent[1] on the functionality > of page up and page down ... so what does this mean? Like so many of the other completely bogus patents in the Vole's portfolio of stolen property ... absolutely nothing. I think you will find this particular "patent" is completely unenforceable. Microsoft is just being opportunistic and predatory ... as ever. -- Regards, Keith G. Robertson-Turner From katzj at redhat.com Thu Sep 4 02:13:58 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 03 Sep 2008 22:13:58 -0400 Subject: ext4 testing in the F10 release cycle In-Reply-To: <48BF3489.6040505@redhat.com> References: <48BEB8F8.9050902@redhat.com> <5256d0b0809030939wf131878rcf8e433eb4e1444c@mail.gmail.com> <48BEBFB4.3050208@redhat.com> <48BF1CC0.9050406@redhat.com> <48BF3422.5060601@redhat.com> <48BF3489.6040505@redhat.com> Message-ID: <1220494438.2102.74.camel@aglarond.local> On Wed, 2008-09-03 at 20:06 -0500, Eric Sandeen wrote: > Eric Sandeen wrote: > > Chris Snook wrote: > >> c) Put an alignment option in the installer, so people can optimize their > >> partitions and filesystems for SSDs, RAID, and anything else where alignment > >> matters. > > > > mkfs should be doing this, not the installer. mkfs.xfs does; > > mkfs.ext$FOO should too. > > I should qualify that; "can" if it's on storage that can be queried (md, > lvm, etc - but not some random hardware scsi lun ... for that case > perhaps installer tweaks maybe, but how often do you really install onto > these things at anaconda-time? mkfs should be able to query scsi info about a block device just as well as anaconda... Arguably it could be done in anaconda first just to show that it works nicely (as python is easier to hack on ;-) But it definitely should be "hardware as seen as blah, do the right thing" as opposed to "make the user figure it out". Also, there are some additional complications once you start thinking about things like the live install where we just dd over the filesystem and then resize rather than doing a whole new one. Jeremy From katzj at redhat.com Thu Sep 4 02:19:33 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 03 Sep 2008 22:19:33 -0400 Subject: Dependency loops considered harmful? In-Reply-To: <1220472891.28633.3.camel@borkbork.foobar.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <1220472891.28633.3.camel@borkbork.foobar.com> Message-ID: <1220494773.2102.78.camel@aglarond.local> On Wed, 2008-09-03 at 16:14 -0400, Dan Williams wrote: > On Wed, 2008-09-03 at 19:39 +0200, Hans de Goede wrote: > > And no we will not just put them together, because re-releasing 300+ MB of > > gamedata because the binary needs recompiling for a new lib is not cool! > > Wouldn't binary deltas make this issue just go away? We could put > everything in the same package then and we wouldn't have to care about > update sizes like this. It depends on if the update you're doing is actually usefully delta-able. Compression, which is often used on game data, tends to get in the way of delta algorithms unless the compression is "smart" with regards to the delta. Jeremy From sandeen at redhat.com Thu Sep 4 02:32:40 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Wed, 03 Sep 2008 21:32:40 -0500 Subject: ext4 testing in the F10 release cycle In-Reply-To: <1220494438.2102.74.camel@aglarond.local> References: <48BEB8F8.9050902@redhat.com> <5256d0b0809030939wf131878rcf8e433eb4e1444c@mail.gmail.com> <48BEBFB4.3050208@redhat.com> <48BF1CC0.9050406@redhat.com> <48BF3422.5060601@redhat.com> <48BF3489.6040505@redhat.com> <1220494438.2102.74.camel@aglarond.local> Message-ID: <48BF48C8.5070709@redhat.com> Jeremy Katz wrote: > On Wed, 2008-09-03 at 20:06 -0500, Eric Sandeen wrote: >> Eric Sandeen wrote: >>> Chris Snook wrote: >>>> c) Put an alignment option in the installer, so people can optimize their >>>> partitions and filesystems for SSDs, RAID, and anything else where alignment >>>> matters. >>> mkfs should be doing this, not the installer. mkfs.xfs does; >>> mkfs.ext$FOO should too. >> I should qualify that; "can" if it's on storage that can be queried (md, >> lvm, etc - but not some random hardware scsi lun ... for that case >> perhaps installer tweaks maybe, but how often do you really install onto >> these things at anaconda-time? > > mkfs should be able to query scsi info about a block device just as well > as anaconda... Arguably it could be done in anaconda first just to show > that it works nicely (as python is easier to hack on ;-) Well, I meant in some cases where you simply cannot query the device, then *if* you wish to make the fs via anaconda, you'd need some knobs to twiddle manually... > But it definitely should be "hardware as seen as blah, do the right > thing" as opposed to "make the user figure it out". > > Also, there are some additional complications once you start thinking > about things like the live install where we just dd over the filesystem > and then resize rather than doing a whole new one. in that case you really are probably not too worried about fs geometry and performance, I think. -Eric From bojan at rexursive.com Thu Sep 4 04:12:57 2008 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 4 Sep 2008 04:12:57 +0000 (UTC) Subject: Time to resurrect multi-key signatures in RPM? References: <1219715812.7925.59.camel@shrek.rexursive.com> <20080826030941.GC1572107@hiwaay.net> <1219725335.12096.53.camel@rosebud> <1219750681.12096.56.camel@rosebud> <544eb990809010240p1546c34k4a6d8d813745f112@mail.gmail.com> Message-ID: Bill Crawford gmail.com> writes: > What might be good, is only signing packages with one or two keys, but > only allowing those keys' public parts to be updated in rpm database > (or wherever) if signed by a much larger number of keys, which would > be owned by some trusted people from the fedora project. Then > automated rollover could be done by simply providing a new "keyring" > in updates. Exactly. Imagine if yum trusted fedora-release package signed by 5 keys of signatories from the pool. This could have been delivered immediately upon (potential) compromise, which would mean: - seamless transition to new Fedora key without ever trusting the old key - automatic delivery of revocation certificate for the old key - instant suitability of all packages to be resigned by the new key So, not only would attackers be unable to subvert the packages by stealing Fedora key (because they'd need other signatories to agree to sign bad packages), but any (potential) compromise would be quickly dealt with. -- Bojan From lyos.gemininorezel at gmail.com Thu Sep 4 04:36:07 2008 From: lyos.gemininorezel at gmail.com (Lyos Norezel) Date: Thu, 4 Sep 2008 00:36:07 -0400 Subject: Fedora fonts SIG pre-freeze status In-Reply-To: <1220432170.3677.15.camel@rousalka.okg> References: <1220432170.3677.15.camel@rousalka.okg> Message-ID: <45a5b7cc0809032136r5cab4486t48088f0d010a384a@mail.gmail.com> 2008/9/3 Nicolas Mailhot > ? darkgarden, sportrop and thibault fonts have unfinished pages > ? please fix DarkGarden and the 4 Thibault fonts pages have been updated/finished. Lyos Gemini Norezel -------------- next part -------------- An HTML attachment was scrubbed... URL: From tgl at redhat.com Thu Sep 4 06:44:45 2008 From: tgl at redhat.com (Tom Lane) Date: Thu, 04 Sep 2008 02:44:45 -0400 Subject: Microsoft patent affect Fedora? In-Reply-To: <7f692fec0809031241x6efa2d67haf78d89e67a08dc9@mail.gmail.com> References: <48BEE585.40906@cchtml.com> <7f692fec0809031241x6efa2d67haf78d89e67a08dc9@mail.gmail.com> Message-ID: <15615.1220510685@sss.pgh.pa.us> >> A few days ago Microsoft was granted a patent[1] on the functionality of >> page up and page down. Did anyone RTFP? http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1%3Cbr%20%3E%3C/a%3E%20&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=7,415,666.PN.&OS=PN/7,415%3Cbr%20/%3E%20,666&RS=PN/7,415,666 It looks to me that what is being claimed is one very specific formula for calculating *where to move to* in response to a page up or page down command. Hardly a generic patent on the concept of page up/down. Note how much detail is in claim 1. The normal process for predatory patents is to claim the moon, the sun, and the stars in claim 1, and then somewhere down around claim 10 get down to something narrow enough that it might survive a court challenge. This patent might be enforceable on claim 1 --- but by the same token it would be trivial to dodge. Just use a slightly different motion formula. regards, tom lane From seg at haxxed.com Thu Sep 4 07:23:11 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 04 Sep 2008 02:23:11 -0500 Subject: Dependency loops considered harmful? In-Reply-To: <48BF20C4.4050500@gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> Message-ID: <1220512991.4415.40.camel@localhost.localdomain> On Wed, 2008-09-03 at 16:41 -0700, Toshio Kuratomi wrote: > Callum Lerwick wrote: > > On Wed, 2008-09-03 at 14:12 -0400, Stephen Gallagher wrote: > >> Applications that consist of multiple packages, such as the game > >> example, should be designated as a group rather than a looped > >> dependency. > > > > Actually a proper fix is to implement the per-package "explicitly > > installed/pulled in as a dep" flag that has been discussed several times > > in the past, and is already implemented (thus proven) in the "aptitude" > > apt front end. > > > > We must address this user interface problem if Fedora is to be a shining > > beacon of open source light in the looming dark future of closed > > DRM-laden content delivery services such as Steam, Xbox Live and > > PlayStation Network. > > > That works for a Mom and Pop desktop but doesn't work as a developer's > workstation. When developing software you might need a library that > does Foo. Look on the system, hey, I can use libFoo! A few weeks > later, when you remove Gnome-Foo from your system because your shiny new > application does the job, Why would you do such a thing? > your app suddenly can't find libFoo.... > (Worse is if your working on an app sporadically and have to figure out > why it's broken not knowing when it became that way.) The solution to this is to RPM package your app. Apps on your system that are not tracked by RPM are a ticking time bomb of dependency breakage whether or not the "leaf culling" is performed manually or is assisted by a "pulled in as dep" flag. A package or distribution update could very well break your app too. > So if we track this some way, there needs to be a way to disable it. A developer presumably doesn't use the hypothetical simplified application installer. They use something more advanced. Like aptitude. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Thu Sep 4 07:26:12 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 4 Sep 2008 07:26:12 +0000 (UTC) Subject: F10 Schedule References: <48BF3524.4080805@redhat.com> Message-ID: Noriko Mizumoto redhat.com> writes: > Currently 'Feature freeze' and 'String freeze' are same day. This makes > no room for translators to work. If we could have the string freeze 5 > days before the feature freeze, all translators would be happy to > complete their work. You can get your translations in after the feature freeze. If you're quick and the maintainer is quick at updating the package, you can even get them tagged for the beta (ask rel-eng). Otherwise, they'll hit Rawhide just after the beta (or as soon as they're built if that's later) and make it into the RC and final release. The feature freeze is intended to apply to new features and to some extent new package versions (bugfix updates are OK after the freeze, major updates not really, especially for the packages at the core of the distribution), not translation updates. It also coincides with the beta freeze, but exemptions (i.e. tagging requests for the beta) are possible and missing the beta isn't that big a deal. Kevin Kofler From mschwendt at gmail.com Thu Sep 4 09:19:20 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 4 Sep 2008 11:19:20 +0200 Subject: Dependency loops considered harmful? In-Reply-To: <48BEFAA5.7010001@redhat.com> References: <20080903165835.GA31342@localhost> <9448.198.175.55.5.1220461813.squirrel@mail.jcomserv.net> <48BEFAA5.7010001@redhat.com> Message-ID: <20080904111920.965218a7.mschwendt@gmail.com> On Wed, 03 Sep 2008 16:59:17 -0400, Chris Snook wrote: > >> For example, why games data depend on binaries? > > > > So that if we try to upgrade the version of the binaries and not the data, > > it will fail. We can still bump the release in most cases, allowing for > > minot fixes without requiring the user to download the same data again. > > It sounds like people are using Requires: foo >= X where they should be using > Conflicts: foo < X. There's no harm done if you install a game data file and > the game isn't installed. Please don't create dependency loops. Exactly. And in this particular case, the foo >= X dep adds no value at all, because it's >= and that's not suitable for preventing accidental upgrades. The primary dependency in the main program package is foo-data = X. Strict and decisive. From hughsient at gmail.com Thu Sep 4 09:12:54 2008 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 04 Sep 2008 10:12:54 +0100 Subject: Dependency loops considered harmful? In-Reply-To: <604aa7910809031415p22bfda89s5d359f63ca712e18@mail.gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED58F.3080301@ioa.s.u-tokyo.ac.jp> <604aa7910809031131q3b7613b7n2d965a68a81572dc@mail.gmail.com> <1220475808.3862.302.camel@code.and.org> <604aa7910809031415p22bfda89s5d359f63ca712e18@mail.gmail.com> Message-ID: <1220519574.1233.1.camel@hughsie-work> On Wed, 2008-09-03 at 13:15 -0800, Jeff Spaleta wrote: > I am interesting in making sure that the people with the right > motivation and the right skills find the right way to handle it. > That's not going to happen just by telling the current maintainers who > are abusing the available requires syntax that they are abusing the > syntax and slapping their wrists. One thing I had considered for PK was running through a large "get-depends" output into the basename filter, so that the user only sees the "applications[1]" by default, rather than a huge list. Maybe one to play with. Richard. [1] well, the 'main' package generated from the srpm -- play with the basename filter in gpk-application for an example From mschwendt at gmail.com Thu Sep 4 09:32:10 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 4 Sep 2008 11:32:10 +0200 Subject: Dependency loops considered harmful? In-Reply-To: <1220512991.4415.40.camel@localhost.localdomain> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> Message-ID: <20080904113210.4d1b2c83.mschwendt@gmail.com> On Thu, 04 Sep 2008 02:23:11 -0500, Callum Lerwick wrote: > > That works for a Mom and Pop desktop but doesn't work as a developer's > > workstation. When developing software you might need a library that > > does Foo. Look on the system, hey, I can use libFoo! A few weeks > > later, when you remove Gnome-Foo from your system because your shiny new > > application does the job, > > Why would you do such a thing? Because developers build their app from local working-directories (or check-outs from source code management systems) and run the software from the same private path or install into /usr/local for testing. It's not unusual to install without using RPM. They would need a way to lock required packages, so the optional libfoo is never removed together with the request to uninstall the last app that depends on it. Even not touching -devel packages and all their dependencies upon package removal would not guarantee that something which is required by the developer is removed. The possibility to undo single transactions (but only the *new* pkgs a transaction added to the system) would be nice. From a.badger at gmail.com Thu Sep 4 09:43:25 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 04 Sep 2008 02:43:25 -0700 Subject: Dependency loops considered harmful? In-Reply-To: <1220512991.4415.40.camel@localhost.localdomain> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> Message-ID: <48BFADBD.6080103@gmail.com> Callum Lerwick wrote: > On Wed, 2008-09-03 at 16:41 -0700, Toshio Kuratomi wrote: >> Callum Lerwick wrote: >>> On Wed, 2008-09-03 at 14:12 -0400, Stephen Gallagher wrote: >>>> Applications that consist of multiple packages, such as the game >>>> example, should be designated as a group rather than a looped >>>> dependency. >>> Actually a proper fix is to implement the per-package "explicitly >>> installed/pulled in as a dep" flag that has been discussed several times >>> in the past, and is already implemented (thus proven) in the "aptitude" >>> apt front end. >>> >>> We must address this user interface problem if Fedora is to be a shining >>> beacon of open source light in the looming dark future of closed >>> DRM-laden content delivery services such as Steam, Xbox Live and >>> PlayStation Network. >>> >> That works for a Mom and Pop desktop but doesn't work as a developer's >> workstation. When developing software you might need a library that >> does Foo. Look on the system, hey, I can use libFoo! A few weeks >> later, when you remove Gnome-Foo from your system because your shiny new >> application does the job, > > Why would you do such a thing? > Hubris! One of the traits of a great programmer. >> your app suddenly can't find libFoo.... >> (Worse is if your working on an app sporadically and have to figure out >> why it's broken not knowing when it became that way.) > > The solution to this is to RPM package your app. Apps on your system > that are not tracked by RPM are a ticking time bomb of dependency > breakage whether or not the "leaf culling" is performed manually or is > assisted by a "pulled in as dep" flag. A package or distribution update > could very well break your app too. > If I'm developing an app, I'm going to be working on code, not taking time out to package the app as an rpm. Only after I'm ready to take the app and put it somewhere for other people to download and use am I going to start worrying about packaging. As a developer, a library can be just as valuable and interesting as an application. >> So if we track this some way, there needs to be a way to disable it. > > A developer presumably doesn't use the hypothetical simplified > application installer. They use something more advanced. Like aptitude. > Err.... You've totally lost me here. If we implement this, it needs to be at a low enough level that anyone installing packages on the system will be storing the information. That could mean rpm (since rpm is responsible for taking the package and turning it into files on the filesystem) or that could mean yum since yum is the one that actually knows whether a package is being installed due to depsolving or user request. Doing this at a higher level means that information gets lost (for instance, if you do this in PackageKit, there won't be any information about what anaconda chose to install due to chckboxes being clicked and which things were installed due to dependencies). With that said, there needs to be a way for a developer to tell yum not to prune away leaf packages if they want. (Also, we shouldn't assume that developers are system admins. There are plenty of programmers out there who can be productive coders running eclipse all day but won't know how to package, how to maintain their system, or why the libraries they need are getting pruned when they just wanted to uninstall Rhythmbox.) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From thomas.moschny at gmail.com Thu Sep 4 10:41:49 2008 From: thomas.moschny at gmail.com (Thomas Moschny) Date: Thu, 4 Sep 2008 12:41:49 +0200 Subject: Dependency loops considered harmful? In-Reply-To: <48BFADBD.6080103@gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> Message-ID: 2008/9/4 Toshio Kuratomi : > With that said, there needs to be a way for a developer to tell yum not > to prune away leaf packages if they want. % yum install libFoo this might look like a noop, because libFoo is already installed, but it would switch the bit for libFoo from 'installed-as-dependency' to 'first-class-installed'. - Thomas From mcepl at redhat.com Thu Sep 4 11:25:10 2008 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 04 Sep 2008 13:25:10 +0200 Subject: Dependency loops considered harmful? References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> Message-ID: On 2008-09-03, 23:41 GMT, Toshio Kuratomi wrote: > That works for a Mom and Pop desktop but doesn't work as > a developer's workstation. When developing software you might > need a library that does Foo. Look on the system, hey, I can > use libFoo! A few weeks later, when you remove Gnome-Foo from > your system because your shiny new application does the job, > your app suddenly can't find libFoo.... No, you would still find libFoo, because yum would still have recorded that libFoo was directly installed, and not just to satisfy dependency on Gnome-foo. Don't say it is not possible, when it was working (and I were using it) for years on Debian. Moreover, even if it didn't help your developer (and I claim that it would), I would still prefer solution which cures problems of at least normal users and wouldn't help developers (who should now how to fix their system). Mat?j From mcepl at redhat.com Thu Sep 4 11:16:38 2008 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 04 Sep 2008 13:16:38 +0200 Subject: Dependency loops considered harmful? References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> Message-ID: On 2008-09-03, 17:39 GMT, Hans de Goede wrote: > Actually its more about the removal scenario, lets say someone > does: > df > yum install vegastrike (drags in vegastrike-data) > df (who thats big) > (hey that games sucks and eats up my HD-space) > yum remove vegastrike > df (WTF, why am I still missing 0.4 Gigs of HD-space ??) And I am afraid there will be no real resolution of this problem, until yum will be able to do the same thing which aptitude on Debian was able to do for years -- remembering which package was installed because user wanted to do so, and which one was installed only to satisfy dependencies. Matej From mcepl at redhat.com Thu Sep 4 11:20:25 2008 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 04 Sep 2008 13:20:25 +0200 Subject: Dependency loops considered harmful? References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED58F.3080301@ioa.s.u-tokyo.ac.jp> <604aa7910809031131q3b7613b7n2d965a68a81572dc@mail.gmail.com> Message-ID: On 2008-09-03, 18:31 GMT, Jeff Spaleta wrote: > than 200M. Pulling in java deps might pollute your > packagelist..but does it burn 200M+ of harddrive space? Do you use Eclipse? Try it it for yourself (on system where java was never installed): df yum install -y eclipse-platform yum remove -y eclipse-platform df Don't tell me you weren't warned :-) Mat?j From mcepl at redhat.com Thu Sep 4 11:35:44 2008 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 04 Sep 2008 13:35:44 +0200 Subject: nspluginwrapper and nppdf.so (Adobe Acrobat) References: <200809011255.m81CtqSi031735@jasmine.xos.nl> Message-ID: On 2008-09-01, 12:55 GMT, Jos Vos wrote: > It seems that nspluginwrapper is standard installed in F9, also > on 32-bit systems. But it looks it does not work well with > nppdf.so (Adobe Acrobat 8.1.2), at least not on 32-bit systems. > Is this a known issue? > > When I add "nppdf*" to IGNORE_WRAP in > /etc/sysconfig/nspluginwrapper (and run "mozilla-plugin-confg > -r" so that the symlinks will be recreated at the next firefox > start), everything seems to work ok. But when I use the > wrapper with nppdf.so, firefox starts behaving problematic most > times when opening a PDF link (it often more or less freezes > for that tab). File a bug against nspluginwrapper, please. Thanks a lot, Mat?j From rawhide at fedoraproject.org Thu Sep 4 11:51:54 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Thu, 4 Sep 2008 11:51:54 +0000 (UTC) Subject: rawhide report: 20080904 changes Message-ID: <20080904115155.050661F8230@releng2.fedora.phx.redhat.com> New package blobwars Mission and Objective based 2D Platform Game New package freemarker FreeMarker template engine New package ini4j Java API for handling files in Windows .ini format New package iwl5000-firmware Firmware for Intel?? PRO/Wireless 5000 A/G/N network adaptors New package ocaml-lwt OCaml lightweight thread library New package perl-DateTime-Format-Pg Parse and format PostgreSQL dates and times New package sugar-terminal Terminal for Sugar New package un-core-fonts Un Core family of Korean TrueType fonts New package wordpress-mu WordPress-MU multi-user blogging software Updated Packages: argyllcms-1.0.3-1.fc10 ---------------------- * Wed Sep 3 18:00:00 2008 Nicolas Mailhot - 1.0.3-1 ??? Bugfix release bodhi-0.5.0-7.fc9 ----------------- bzr-1.6.1-0.1.rc2.fc10 ---------------------- * Wed Sep 3 18:00:00 2008 Toshio Kuratomi - 1.6.1-0.1.rc2 - New upstream bugfix release. bzr-gtk-0.95.0-1.fc10 --------------------- * Wed Sep 3 18:00:00 2008 Toshio Kuratomi 0.95.0-1 - New Upstream release for use with bzr >= 1.6. bzrtools-1.6.0-1.fc10 --------------------- * Wed Sep 3 18:00:00 2008 Toshio Kuratomi 1.6.0-1 - Update to 1.6.0 cheese-2.23.91-2.fc10 --------------------- * Wed Sep 3 18:00:00 2008 Hans de Goede 2.23.91-2 - Fix use with multiple v4l devices (rh 460956, gnome 546868, gnome 547144) cluster-2.99.08-3.fc10 ---------------------- * Wed Sep 3 18:00:00 2008 Jesse Keating - 2.99.08-3 - Rebuild for broken deps. - Pull in upstream patches for libvolume_id changes cmake-2.6.1-3.fc10 ------------------ * Tue Sep 2 18:00:00 2008 Orion Poplawski - 2.6.1-3 - Drop jni patch, applied upstream. colordiff-1.0.7-3 ----------------- * Thu Apr 10 18:00:00 2008 Ville Skytt?? - 1.0.7-3 - Patch to work around wget 1.11 regression, prefer curl over wget (#441862). - Drop disttag. cups-1.3.8-5.fc10 ----------------- * Wed Sep 3 18:00:00 2008 Tim Waugh 1:1.3.8-5 - The dnssd backend uses avahi-browse so require it (bug #458565). - New php sub-package (bug #428235). - cups-polld: reinit the resolver if we haven't yet resolved the hostname (bug #354071). curl-7.18.2-6.fc10 ------------------ * Wed Sep 3 18:00:00 2008 Warren Togami 7.18.2-6 - add thread safety to libcurl NSS cleanup() functions (#459297) cwdaemon-0.9.4-9.fc10 --------------------- * Wed Sep 3 18:00:00 2008 Lucian Langa - 0.9.4-9 - fix sysvinit script dejavu-fonts-2.26-2.fc10 ------------------------ * Wed Sep 3 18:00:00 2008 Nicolas Mailhot - 2.26-2 ??? Rebuild with pre-F10-freeze fontforge denemo-0.7.9-5.fc10 ------------------- * Wed Sep 3 18:00:00 2008 Roy Rankin - 0.7.9-5 -Add Patches assert undo crash, un-needed messages on start up eclipse-3.4.0-23.fc10 --------------------- * Tue Sep 2 18:00:00 2008 Andrew Overholt 3.4.0-23 - Use icu4j in its new place. edrip-fonts-20080826-2.fc10 --------------------------- * Wed Sep 3 18:00:00 2008 - 20080826-2 ??? Rebuild with pre-F10-freeze fontforge environment-modules-3.2.6-6.fc10 -------------------------------- * Wed Sep 3 18:00:00 2008 - Orion Poplawski - 3.2.6-6 - Change %patch -> %patch0 esound-0.2.40-1.fc10 -------------------- * Thu Sep 4 18:00:00 2008 Matthias Clasen 0 1:0.2.40-1 - Update to 0.2.40 flam3-2.7.15-1.fc10 ------------------- * Wed Sep 3 18:00:00 2008 Ian Weller 2.7.15-1 - Upstream updated: Added new interpolation types 'old' and 'older', for use in recreating old animations. 'linear' mode now does not rotate padded xforms (results in prettier symmetric singularities). switched to using a 'padding' flag instead of a 'just initialized' flag; padding flag used for implementation of 'old' and 'older' types. interpolation_space now deprecated, instead use interpolation_type. flam3_align is now idempotent (multiple applications do not change the control points.) Default number of temporal samples bumped to 1000. Removed CVS headers from source code (now using SVN). Default interpolation mode now log. Removed 'move' and 'split' vars. changes to flam3-genome: sequence mode now returns linear interpolation mode for all control points except first/last of edges - these cps will use the original interpolation mode; inter and rotate modes will now return padded genomes for all control points, all with linear interpolation specified. instead of centering sometimes reframe by golden mean plus noise. Release as 2.7.15. fontforge-20080828-1.fc10 ------------------------- * Wed Sep 3 18:00:00 2008 Kevin Fenzi - 20080828-1 - Upgrade to 20080828 - Add Requires on autotrace. Fixes 460668 - Confirm patch from 459451 is upstream here. freetalk-3.1-1.fc10 ------------------- * Wed Sep 3 18:00:00 2008 Debarshi Ray - 3.1-1 - Version bump to 0.32. - open(2) problem fixed by upstream. gifsicle-1.52-1.fc10 -------------------- * Wed Sep 3 18:00:00 2008 - Orion Poplawski - 1.52-1 - Update to 1.52 gitosis-0.2-6.20080825git.fc10 ------------------------------ * Tue Sep 2 18:00:00 2008 John A. Khvatov 0.2-6.20080825git - upstream update for compatibility with git 1.6. gnome-desktop-2.23.91-3.fc10 ---------------------------- * Wed Sep 3 18:00:00 2008 Soren Sandmann - 2.23.91-3 - Bump release number to make chain-build work * Wed Sep 3 18:00:00 2008 Soren Sandmann - 2.23.91-2 - Add patch to move clone mode enumeration to gnome-rr.c gnome-devel-docs-2.23.1-1.fc10 ------------------------------ * Thu Sep 4 18:00:00 2008 Matthias Clasen - 2.23.1-1 - Update to 2.23.1 gnome-keyring-2.23.91-1.fc10 ---------------------------- * Thu Sep 4 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 gnome-settings-daemon-2.23.91-3.fc10 ------------------------------------ * Wed Sep 3 18:00:00 2008 Soren Sandmann - 2.23.91-3 - Bump gnome-desktop requirement * Wed Sep 3 18:00:00 2008 Soren Sandmann - 2.23.91-2 - Add patch to do fn-f7 cycling goocanvasmm-0.9.0-1.fc10 ------------------------ * Wed Sep 3 18:00:00 2008 Denis Leroy - 0.9.0-1 - Update to upstream 0.9.0 gpsdrive-2.09-6.fc9 ------------------- * Tue Apr 8 18:00:00 2008 Kevin Fenzi - 2.09-6 - Add patch for gpsd arguments - bug 438615 - Add patch for mysql - bug 441179 gstreamermm-0.9.6-1.fc10 ------------------------ * Wed Sep 3 18:00:00 2008 Denis Leroy - 0.9.6-1 - Update to upstream 0.9.6 gwave-2-9.20070514snap.fc10 --------------------------- * Wed Sep 3 18:00:00 2008 Chitlesh Goorah - 2-9.20070514snap - rebuild due to segmentation fault * Fri Aug 29 18:00:00 2008 Chitlesh Goorah - 2-8.20070514snap - rebuild hamster-applet-2.23.91-1.fc10 ----------------------------- * Wed Sep 3 18:00:00 2008 Mads Villadsen - 2.23.91-1 - Update to latest upstream release hunspell-bn-20050726-3.fc10 --------------------------- * Tue Sep 2 18:00:00 2008 Caol??n McNamara - 20050726-3 - add bn_BD alias inconsolata-fonts-1.009-2.fc10 ------------------------------ * Wed Sep 3 18:00:00 2008 Nicolas Mailhot - 1.009-2 ??? Rebuild with pre-F10-freeze fontforge ircd-ratbox-2.2.8-2.fc10 ------------------------ kcoloredit-4.1.1-1.fc10 ----------------------- * Fri Aug 29 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 kde-i18n-3.5.10-1.fc10 ---------------------- * Wed Sep 3 18:00:00 2008 Than Ngo 3.5.10-1 - 3.5.10 kdebase-4.1.1-1.fc10 -------------------- * Fri Aug 29 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 * Fri Jul 25 18:00:00 2008 Kevin Kofler 4.1.0-1.1 - always check for Plasma actually being present (fixes F8 kdebase4 build) kdeedu-4.1.1-1.fc10 ------------------- * Fri Aug 29 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 kdegames-4.1.1-1.fc10 --------------------- * Fri Aug 29 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 kdegraphics-4.1.1-1.fc10 ------------------------ * Fri Aug 29 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 kdemultimedia-4.1.1-1.fc10 -------------------------- * Fri Aug 29 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 kdenetwork-4.1.1-1.fc10 ----------------------- * Fri Aug 29 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 kdepim-4.1.1-1.fc10 ------------------- * Fri Aug 29 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 kdeplasma-addons-4.1.1-1.fc10 ----------------------------- * Fri Aug 29 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 kdesdk-4.1.1-1.fc10 ------------------- * Fri Aug 29 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 kdetoys-4.1.1-1.fc10 -------------------- * Fri Aug 29 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 kdeutils-4.1.1-1.fc10 --------------------- * Fri Aug 29 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 * Tue Jul 29 18:00:00 2008 Rex Dieter 4.1.0-1.1 - omit printer_applet from F-9 build kiconedit-4.1.1-1.fc10 ---------------------- * Fri Aug 29 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 kompose-0.5.3-13.fc10 --------------------- * Wed Sep 3 18:00:00 2008 Orion Poplawski - 0.5.3-13 - Change %patch -> %patch0 ksynaptics-0.3.3-7.fc10 ----------------------- * Wed Sep 3 18:00:00 2008 Orion Poplawski - 0.3.3-6 - Change %patch -> %patch0 libaio-0.3.107-4.fc10 --------------------- * Wed Sep 3 18:00:00 2008 Jeff Moyer - 0.3.107-4 - Install to / instead of /usr for early users of libaio (Jeff Moyer) - Resolves: bz#459158 libgnomekbd-2.23.91-1.fc10 -------------------------- * Thu Sep 4 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 libgsf-1.14.9-1.fc10 -------------------- * Wed Sep 3 18:00:00 2008 Caol??n McNamara 1.14.9-1 - latest version with gio support libprelude-0.9.20-1.fc10 ------------------------ * Wed Sep 3 18:00:00 2008 Steve Grubb - 0.9.20-1 - New upstream release librra-0.11.1-1.fc9 ------------------- * Wed Jun 18 18:00:00 2008 Andreas Bierfert - 0.11.1-1 - version upgrade libsynaptics-0.14.6c-5.fc10 --------------------------- * Tue Aug 5 18:00:00 2008 Tom "spot" Callaway - 0.14.6c-4 - fix license tag * Tue Aug 5 18:00:00 2008 Orion Poplawski - 0.14.6c-5 - Change patch to patch0 linux-libertine-fonts-2.7.9-2.fc10 ---------------------------------- * Wed Sep 3 18:00:00 2008 Nicolas Mailhot - 2.7.9-2 ??? Rebuild with pre-F10-freeze fontforge lua-5.1.4-1.fc10 ---------------- * Wed Sep 3 18:00:00 2008 Tim Niemueller - 5.1.4-1 - New upstream release 5.1.4 mew-6.1.50-1.fc10 ----------------- * Thu Sep 4 18:00:00 2008 Akira TAGOH - 6.1.50-1 - New upstream release. namazu-2.0.18-6.fc10 -------------------- * Wed Sep 3 18:00:00 2008 Akira TAGOH - 2.0.18-6 - Fix a broken deps. netcdf-4.0.0-1.fc10 ------------------- * Wed Sep 3 18:00:00 2008 Orion Poplawski - 4.0.0-1 - Update to 4.0 final - Drop netcdf-3 symlink (bug #447158) - Update cstring patch, partially upstreamed nomarch-1.4-4.fc10 ------------------ * Wed Sep 3 18:00:00 2008 Nicolas Mailhot - 1.4-4 ??? Update URL perl-Crypt-OpenSSL-RSA-0.25-6.fc9 --------------------------------- * Wed Jun 18 18:00:00 2008 Wes Hardaker - 0.25-6 - Fix bug 451900: force-require the bignum module perl-DateTime-Format-DBI-0.031-4.fc10 ------------------------------------- * Wed Sep 3 18:00:00 2008 Chris Weyl 0.031-4 - add the dbd-specific DateTime::Format's as requires. Makes sense that installing this package should have stuff "just work". - patch for additional DBD support (just DB2 at this point) perl-QWizard-3.14-2.fc9 ----------------------- * Fri Jul 18 18:00:00 2008 Wes Hardaker - 3.14-2 - Version bump for build issues * Tue Apr 29 18:00:00 2008 Wes Hardaker - 3.14-1 - Update to latest upstream for bug fixes and minor new features plague-0.4.5.1-1.fc10 --------------------- * Wed Sep 3 18:00:00 2008 Michael Schwendt - 0.4.5-2 - add the patches from 0.4.5-0.4 (sqlite3, mock08, logtail) - merge more spec changes * Wed Sep 3 18:00:00 2008 Dennis Gilmore - 0.4.5.1-1 - update to 0.4.5.1 applying Michael schwendt's logging and mock patches - using pysqlite2 on fedora and python-sqlite on RHEL - requires mock > 0.8 - requires createrepo >= 0.4.7 player-2.1.1-5.fc10 ------------------- * Tue Sep 2 18:00:00 2008 Tim Niemueller - 2.1.1-5 - Added plugindir patch * Fri Aug 15 18:00:00 2008 Tim Niemueller - 2.1.1-4 - Changed norpath patch, fixes build problem on Fedora 8 - Added libtool BR - Added autotools BR, needed because for patches of .am files podsleuth-0.6.2-3.fc10 ---------------------- * Wed Sep 3 18:00:00 2008 Michel Salim - 0.6.2-3 - Manually requires sg3_utils-libs policycoreutils-2.0.55-2.fc10 ----------------------------- * Wed Sep 3 18:00:00 2008 Dan Walsh 2.0.55-2 - Add glob support to restorecond so it can check every file in the homedir postgresql-table_log-0.4.4-5.fc10 --------------------------------- * Tue Sep 2 18:00:00 2008 Michael Schwendt - 0.4.4-5 - Include unowned directories. pygobject2-2.15.4-1.fc10 ------------------------ * Wed Sep 3 18:00:00 2008 Matthew Barnes - 2.15.4-1.fc10 - Update to 2.15.4 pykickstart-1.43-1.fc10 ----------------------- * Wed Sep 3 18:00:00 2008 Chris Lumens - 1.43-1 - Revert "Do not include passphrases for encrypted block devices in anaconda-ks.cfg." (dlehman) - yum doesn't like when mirrorlist is "". (clumens) python-feedparser-4.1-4.fc10 ---------------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 4.1-4 - fix license tag python-irclib-0.4.6-6.fc10 -------------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway 0.4.6-6 - fix license tag python-isprelink-0.1.2-5.fc10 ----------------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.1.2-5 - fix license tag python-json-3.4-4.fc10 ---------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway 3.4-4 - fix license tag python-ldap-2.3.5-1.fc10 ------------------------ * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0:2.3.5-1 - fix license tag - update to 2.3.5 python-memcached-1.43-2.fc10 ---------------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway 1.43-2 - add BR: python-setuptools * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway 1.43-1 - fix license tag - update to 1.43 python-myghty-1.1-6.fc10 ------------------------ * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway 1.1-6 - fix license tag python-paramiko-1.7.4-2.fc10 ---------------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 1.7.4-2 - fix license tag python-protocols-1.0-0.8.a0dev_r2302.fc10 ----------------------------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 1.0-0.8.a0dev_r2302 - fix license tag python-psycopg-1.1.21-8.fc10 ---------------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 1.1.21-8 - fix license tag python-pydns-2.3.3-1.fc10 ------------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway 2.3.3-1 - fix license tag - update to 2.3.3 python-pyspf-2.0.5-1.fc10 ------------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway 2.0.5-1 - update to 2.0.5 - fix license tag python-qpid-0.2.668378-2.fc10 ----------------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.2.668378-2 - fix license tag python-ruledispatch-0.5a0-0.10.svnr2306.fc10 -------------------------------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway 0.5a0-0.10.svn2305 - fix license tag python-sexy-0.1.9-6.fc10 ------------------------ * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.1.9-6 - fix license tag python-tpg-3.1.2-2.fc10 ----------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 3.1.2-2 - drop ancient API Requires * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 3.1.2-1 - fix license tag - update to 3.1.2 python-vobject-0.7.1-2.fc10 --------------------------- * Wed Sep 3 18:00:00 2008 James Bowes - 0.7.1-2 - Add change_tz executable * Wed Sep 3 18:00:00 2008 James Bowes - 0.7.1-1 - Update to 0.7.1 python-xlib-0.14-2.fc10 ----------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.14-2 - fix license tag python-xmpp-0.4.1-3.fc10 ------------------------ * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.4.1-3 - fix license tag pyxmms-2.06-7.fc10 ------------------ * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 2.06-7 - fix license tag qa-assistant-0.4.90.5-4.fc10 ---------------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.4.90.5-4 - fix BR * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.4.90.5-3 - fix license tag qcad-2.0.5.0-9.fc10 ------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 2.0.5.0-9 - fix license tag qcomicbook-0.4.0-3.fc10 ----------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.4.0-3 - fix license tag qpidc-0.2.667603-3.fc10 ----------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.2.667603-3 - fix license tag quagga-0.99.10-2.fc10 --------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.99.10-2 - fix license tag quodlibet-1.0-4.fc10 -------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 1.0-4 - fix license tag radvd-1.1-5.fc10 ---------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 1.1-5 - fix license tag rarpd-ss981107-27.fc10 ---------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - ss981107-27 - fix license tag rb_libtorrent-0.13.1-3.fc10 --------------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.13.1-3 - fix license tag rcs-5.7-33.fc10 --------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 5.7-33 - fix license tag rdate-1.4-12.fc10 ----------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 1.4-12 - fix license tag rdesktop-1.6.0-2.fc10 --------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 1.6.0-2 - fix license tag readahead-1.4.5-2.fc10 ---------------------- * Wed Sep 3 18:00:00 2008 Harald Hoyer 1.4.5-2 - fixed compiling agaings audit-libs-devel-1.4.5 * Mon Sep 1 18:00:00 2008 Harald Hoyer 1.4.5-2 - moved readahead to /sbin (bug #460715) recordmydesktop-0.3.7.3-2.fc10 ------------------------------ * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.3.7.3-2 - fix license tag redhat-rpm-config-9.0.3-3.fc10 ------------------------------ * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 9.0.3-3 - fix license tag - nuke ancient conflicts reiserfs-utils-3.6.19-4.fc10 ---------------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 2:3.6.19-4 - fix license tag rhythmbox-0.11.6-8.fc10 ----------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway 0.11.6-8 - fix license tag * Mon Sep 1 18:00:00 2008 - Bastien Nocera 0.11.6-7 - Add wbur.org to the default playlist (#446791) rng-utils-2.0-2.fc10 -------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 1:2.0-2 - fix license tag rp-pppoe-3.8-5.fc10 ------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway 3.8-5 - fix license tag * Thu Apr 10 18:00:00 2008 Karsten Hopp 3.8-4 - Build with $RPM_OPT_FLAGS (#249978) (Ville Skytt??) rpld-1.8-0.4.beta1.fc10 ----------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 1.8-0.4.beta1 - fix license tag rsnapshot-1.3.1-1.fc10 ---------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway 1.3.1-1 - fix license tag - update to 1.3.1 - remove comment lines (more trouble than they're worth) rtorrent-0.7.8-4.fc10 --------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.7.8-4 - fix license tag ruby-ncurses-1.1-7.fc10 ----------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 1.1-7 - fix license tag ruby-postgres-0.7.1-10.fc10 --------------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.7.1-9 - fix license tag * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.7.1-10 - apply patch properly ruby-qpid-0.1-2.fc10 -------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.1-2 - fix license tag ruby-racc-1.4.5-3.fc10 ---------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 1.4.5-3 - fix license tag rubygems-0.9.4-2.fc10 --------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.9.4-2 - fix license tag rudeconfig-5.0.5-4.fc10 ----------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 5.0.5-4 - fix compile with gcc43 * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 5.0.5-3 - fix license tag * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 5.0.5-2 - Autorebuild for GCC 4.3 rzip-2.1-4.fc10 --------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 2.1-4 - fix license tag s3switch-0.0-11.20020912.fc10 ----------------------------- * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.0-11.20020912 - fix license tag sane-backends-1.0.19-11.fc10 ---------------------------- * Wed Sep 3 18:00:00 2008 Nils Philippsen - 1.0.19-11 - update glibc-2.7 patch to apply without fuzz scim-tables-0.5.8-7.fc10 ------------------------ * Thu Sep 4 18:00:00 2008 Caius Chance - 0.5.8-7.fc10 - Resolves: rhbz#461092 (Create specific CangJie 5 icon.) seahorse-2.23.91-1.fc10 ----------------------- * Thu Sep 4 18:00:00 2008 Matthias Clasen 2.23.91-1 - Update to 2.23.91 * Sat Aug 30 18:00:00 2008 Michel Salim 2.23.90-2 - Patch configure to detect gpg2 binary selinux-policy-3.5.6-1.fc10 --------------------------- * Wed Sep 3 18:00:00 2008 Dan Walsh 3.5.6-1 - Update to upstream - New handling of init scripts setup-2.7.3-1.fc10 ------------------ * Wed Sep 3 18:00:00 2008 Phil Knirsch 2.7.3-1 - Added SBinSanity patch as an approved feature (#458176) * Wed Aug 6 18:00:00 2008 Phil Knirsch 2.7.2-1 - Added uidgid pair for condor - Added uidgid pair for trousers sudo-1.6.9p17-2.fc10 -------------------- * Tue Sep 2 18:00:00 2008 Peter Vrabec 1.6.9p17-2 - adjust audit patch, do not scream when kernel is compiled without audit netlink support (#401201) sugar-0.82.2-2.fc10 ------------------- * Wed Sep 3 18:00:00 2008 Jeremy Katz - 0.82.2-2 - Require gstreamer-python and telepathy-python (rhbz#447589) sugar-toolkit-0.82.5-3.fc10 --------------------------- * Wed Sep 3 18:00:00 2008 Jeremy Katz - 0.82.5-3 - requires gettext for bundlebuilder synce-gnomevfs-0.11.1-1.fc9 --------------------------- * Wed Jun 18 18:00:00 2008 Andreas Bierfert - 0.11.1-1 - version upgrade synce-trayicon-0.11-1.fc9 ------------------------- * Wed Jun 18 18:00:00 2008 Andreas Bierfert - 0.11-1 - version upgrade tcsh-6.15-6.fc10 ---------------- * Wed Sep 3 18:00:00 2008 Vitezslav Crhonek - 6.15-6 - Fix UTF-8 Japanese character is garbled in tcsh script in a certain situation Related: #453785 - Fix calculation order of operators description in tcsh manpage Related: #442536 - Fix strings which begin with '0' are not recognized as octal numbers Related: #438109 - Fix memoryuse description in tcsh manpage Related: #437095 - Fix tcsh scripts with multiple case statement with end keywords break with error Related: #436956 - Fix description of builtin command 'set' in tcsh manpage Related: #430459 twinkle-1.3.2-1.fc10 -------------------- * Tue Sep 2 18:00:00 2008 Kevin Fenzi - 1.3.2-1 - Update to 1.3.2 vdr-sudoku-0.3.1-1.fc9 ---------------------- * Sat Aug 30 18:00:00 2008 Ville Skytt?? - 0.3.1-1 - 0.3.1, Finnish patch applied upstream. writer2latex-0.5.0.2-1.fc10 --------------------------- * Wed Sep 3 18:00:00 2008 Caolan McNamara 0.5.0.2-1 - latest version xmms-pulse-0.9.4-6.fc10 ----------------------- * Wed Sep 3 18:00:00 2008 Robin Norwood - 0.9.4-6 - Build against latest xmms xmms-sid-0.8.0-0.6.beta19.fc10 ------------------------------ * Wed Sep 3 18:00:00 2008 Michael Schwendt - 0.8.0-0.6.beta19 - update to beta19 xorg-x11-drv-i810-2.4.2-3.fc10 ------------------------------ * Wed Sep 3 18:00:00 2008 Dave Airlie 2.4.2-3 - intel-fix-irq.patch - Don't die on irq handler failure - I think krh DRI2 patches broke it. * Thu Aug 28 18:00:00 2008 Dave Airlie 2.4.2-2 - upgrade to git head - brings in modesetting + GEM bits - fix flip xorg-x11-proto-devel-7.4-3.fc10 ------------------------------- * Fri Aug 29 18:00:00 2008 Adam Jackson 7.4-3 - inputproto 1.4.4 xorg-x11-server-1.5.0-1.fc10 ---------------------------- * Wed Sep 3 18:00:00 2008 Adam Jackson 1.5.0-1 - xserver 1.5.0 - Revert to the EXA from 1.5.0, should be good enough one hopes. - Add .gitignore from git, so working with the artificial git tree is less flakey. yum-3.2.19-3.fc10 ----------------- * Wed Sep 3 18:00:00 2008 Seth Vidal - 3.2.19-3 - add patch to fix yum install name.arch matching Summary: Added Packages: 9 Removed Packages: 0 Modified Packages: 143 Broken deps for i386 ---------------------------------------------------------- audacious-plugins-1.5.1-1.fc10.i386 requires libmtp.so.7 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 grisbi-0.5.9-5.fc9.i386 requires tetex-unicode gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.11-1.fc10.i386 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.i386 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.i386 requires perl(MT::Entry) highlight-2.6.11-1.fc10.i386 requires perl(MT) highlight-2.6.11-1.fc10.i386 requires perl(MT::Template::Context) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so poker3d-1.1.36-10.fc10.i386 requires libosg.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgUtil.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgSim.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgTerrain.so.35 poker3d-1.1.36-10.fc10.i386 requires libOpenThreads.so.10 poker3d-1.1.36-10.fc10.i386 requires libosgGA.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgFX.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgManipulator.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgDB.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgParticle.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgViewer.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgText.so.35 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for x86_64 ---------------------------------------------------------- audacious-plugins-1.5.1-1.fc10.x86_64 requires libmtp.so.7()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) grisbi-0.5.9-5.fc9.x86_64 requires tetex-unicode gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Entry) highlight-2.6.11-1.fc10.x86_64 requires perl(MT) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Template::Context) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgFX.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgGA.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgTerrain.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosg.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgSim.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgText.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgDB.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libOpenThreads.so.10()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgManipulator.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgParticle.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgViewer.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgUtil.so.35()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for ppc ---------------------------------------------------------- audacious-plugins-1.5.1-1.fc10.ppc requires libmtp.so.7 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) grisbi-0.5.9-5.fc9.ppc requires tetex-unicode gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.11-1.fc10.ppc requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc requires perl(MT::Entry) highlight-2.6.11-1.fc10.ppc requires perl(MT) highlight-2.6.11-1.fc10.ppc requires perl(MT::Template::Context) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so poker3d-1.1.36-10.fc10.ppc requires libosg.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgUtil.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgSim.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgTerrain.so.35 poker3d-1.1.36-10.fc10.ppc requires libOpenThreads.so.10 poker3d-1.1.36-10.fc10.ppc requires libosgGA.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgFX.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgManipulator.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgDB.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgParticle.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgViewer.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgText.so.35 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires libbfd-2.18.50.0.8-2.fc10.so stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires libopcodes-2.18.50.0.8-2.fc10.so vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for ppc64 ---------------------------------------------------------- audacious-plugins-1.5.1-1.fc10.ppc64 requires libmtp.so.7()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) grisbi-0.5.9-5.fc9.ppc64 requires tetex-unicode gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Entry) highlight-2.6.11-1.fc10.ppc64 requires perl(MT) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Template::Context) livecd-tools-018-1.fc10.ppc64 requires yaboot mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 poker3d-1.1.36-10.fc10.ppc64 requires libosgFX.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgGA.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgTerrain.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosg.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgSim.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgText.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgDB.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libOpenThreads.so.10()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgManipulator.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgParticle.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgViewer.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgUtil.so.35()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 From tibbs at math.uh.edu Thu Sep 4 12:57:34 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 04 Sep 2008 07:57:34 -0500 Subject: nspluginwrapper and nppdf.so (Adobe Acrobat) In-Reply-To: References: <200809011255.m81CtqSi031735@jasmine.xos.nl> Message-ID: >>>>> "MC" == Matej Cepl writes: MC> File a bug against nspluginwrapper, please. I would be surprised if this wasn't already filed, since it looks like any of several open tickets. http://bugz.fedoraproject.org/nspluginwrapper - J< From pertusus at free.fr Thu Sep 4 13:08:22 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 4 Sep 2008 15:08:22 +0200 Subject: Dependency loops considered harmful? In-Reply-To: References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> Message-ID: <20080904130822.GA3366@free.fr> On Thu, Sep 04, 2008 at 01:25:10PM +0200, Matej Cepl wrote: > > Moreover, even if it didn't help your developer (and I claim that > it would), I would still prefer solution which cures problems of > at least normal users and wouldn't help developers (who should > now how to fix their system). It is not unusual, at least for me, to install a devel package for itself but also its dependencies, so for example I install libY-devel to have both libX-devel and libY-devel, with libX-devel depending on libY-devel. I wouldn't like to have libX-devel removed when I remove libY-devel. And it isn't necessarily only for -devel packages, it could also be for documentation/typesetting systems. -- Pat From subhodip at fedoraproject.org Thu Sep 4 14:31:45 2008 From: subhodip at fedoraproject.org (subhodip biswas) Date: Thu, 4 Sep 2008 20:01:45 +0530 Subject: query regarding placing a bug Message-ID: <539333cb0809040731m2a2fe3d0qc48a85f3f9389ac5@mail.gmail.com> hi ! i recently submitted this bug https://bugzilla.redhat.com/show_bug.cgi?id=461139 I built it for olpc3 in koji ..however what i want to know is that should this bug go to fedora container or fedora-olpc .. please suggest so that i can correct it . -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From notting at redhat.com Thu Sep 4 14:56:08 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 4 Sep 2008 10:56:08 -0400 Subject: F10 Schedule In-Reply-To: <48BF3524.4080805@redhat.com> References: <48BF3524.4080805@redhat.com> Message-ID: <20080904145608.GA8469@nostromo.devel.redhat.com> Noriko Mizumoto (noriko at redhat.com) said: > Currently 'Feature freeze' and 'String freeze' are same day. This makes > no room for translators to work. If we could have the string freeze 5 > days before the feature freeze, all translators would be happy to > complete their work. > > It would be much appreciated if you could once consider this matter. It's really best to bring this up when the schedule is made; at this point, you're essentially requesting that the feature freeze be two days ago, which isn't practical at this point. We'll keep this in mind and try and do this for future releases. A reminder during F11 planning can't hurt. Bill From ndbecker2 at gmail.com Thu Sep 4 14:56:36 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 04 Sep 2008 10:56:36 -0400 Subject: Can't tag package for EL-5 Message-ID: make tag build cvs tag -c mercurial-1_0_2-2_el5 key_read: uudecode AAAAB3NzaC1yc2EAAAABIwAAAQEAvl7zoOiRUqtNs2/Jiioeqyh+yHCfkHcWwcel8eNZmpz+j1emKglGxz2pj2nOPW+XnzG5cV35YV5c/ZUGHzKqCsTpWTQyM4a4tlLIwaSDCBPTrdISFRMnwVKbbxYVizuA17abA3SgRFS3SZ+4Hik/TwcPnXbKOwb6BX0R3hrNxzo47Lofxd8TqdaGJrB2OXpxxNnEoQaxGgsTiYTd2YbfftJKpKdzGn34QAWLnScsAMuY3Aro8H2324kicQI/oUFBnxfXlCO7HCznVenGMvezAB4eezsAXICkjD/iQdIA1S8FanXYa5cTGQJ/dEV1PBWLO7r87m79fFnVCgEMZrTcgw==adgcluster,10.32.111.50 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAs/CwACBvPb9ztp7saLE4ieltR1nEsAIWY/nDs2YUJjwsJE3SoERiC5UbBllIGBwLJ2eHO/fMXFZ+RllJP2Zqm7amM4tYXITGkB3I0+248RSPDt2H5CwzbZmMSDIg1R6xRDaPVgzrIv64Wios1Np0yKh00m60qCiPiBvE6DQiN94MPpGoTsDB/qkyLqtAtLxFQy1SF32ylpMCxL8+4gm9hkw7wUSvCKDbCDIUzoyk1EQRCMiexZOre4TqIcsuXoVp6ftT/4qRv48GcK9MsmHP5HlGKURIHwENtZPXCNtmWV4nUKy0OD8nXuHVzJbZiO/HUKKO4fs3LbBY5diaAPrsXQ== failed cvs tag: Tagging . T .cvsignore T Makefile T branch T mercurial.spec T sources Tagged with: mercurial-1_0_2-2_el5 /usr/bin/plague-client build mercurial mercurial-1_0_2-2_el5 el5 Traceback (most recent call last): File "/usr/bin/plague-client", line 420, in cli = PlagueClient(os.path.expanduser(cfg_file)) File "/usr/bin/plague-client", line 81, in __init__ self._email = self._get_user_email() File "/usr/bin/plague-client", line 138, in _get_user_email cert = OpenSSL.crypto.load_certificate(OpenSSL.crypto.FILETYPE_PEM, buf) OpenSSL.crypto.Error: [('PEM routines', 'PEM_read_bio', 'bad end line')] make: *** [plague] Error 1 From orion at cora.nwra.com Thu Sep 4 14:57:50 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 04 Sep 2008 08:57:50 -0600 Subject: Some initial discussions of a Fedora HPC SIG In-Reply-To: <1220480445.19330.11.camel@firewall.xsintricity.com> References: <1220480445.19330.11.camel@firewall.xsintricity.com> Message-ID: <48BFF76E.3070905@cora.nwra.com> Doug Ledford wrote: > On Fri, 2008-08-29 at 09:44 -0700, Shawn Starr wrote: >> Hello everyone, >> >> It would be great if we can kick off the SIG. >> >> 1) Which day and time would be good for the meetings in #fedora-meeting >> >> The available times are here: http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel > > I'm free most days after about 14:00 or 15:00UTC. Mon-Fri 15-18, 19-23 best for me. >> 2) Let's come up with an initial agenda. > > Defining what should be in a reasonably complete HPC Comps group > Define a complete component list > Pick which of those components should be default vs. optional > Identify packages not yet in Fedora that are on the list and > allow people to sign up to get them through a review process > and in Fedora > Identify any shortcomings in upstream standards for HPC > packages (there's a lot here, eg. the upstream MPI groups > don't have the faintest clue on how to get together and > create a standard installation layout or anything else) > Where upstream has no clue about doing things in a standard > way, at least work to create one inside the framework > of Fedora and attempt to push it to upstream if they are > receptive of the idea. > Identify packages in Fedora that need updating/changing to > meet said standards > Allow people to sign up to work those changes if the package > maintainer is unable to do so > > Something along those lines ought to get things started. Looks good to me. I haven't indicated my interest before, but I am. I maintain gridengine, paraview, hdf5, gdl and some others. -- 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 mschwendt at gmail.com Thu Sep 4 15:06:34 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 4 Sep 2008 17:06:34 +0200 Subject: Can't tag package for EL-5 In-Reply-To: References: Message-ID: <20080904170634.98834d2b.mschwendt@gmail.com> On Thu, 04 Sep 2008 10:56:36 -0400, Neal Becker wrote: > File "/usr/bin/plague-client", line 138, in _get_user_email > cert = OpenSSL.crypto.load_certificate(OpenSSL.crypto.FILETYPE_PEM, buf) > OpenSSL.crypto.Error: [('PEM routines', 'PEM_read_bio', 'bad end line')] > make: *** [plague] Error 1 Upgrade your plague-client (fetch a newer one in bodhi/koji). From stickster at gmail.com Thu Sep 4 15:44:53 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 04 Sep 2008 11:44:53 -0400 Subject: Fedora release time? Message-ID: <1220543093.7673.2.camel@localhost.localdomain> Historically, the release time on a given release date has been 10:00am Eastern time.[1] However, Jesse Keating, who's one of our release engineers, is now on Pacific time, which makes this 7:00am by his clock. Are we going to stay with 10:00am Eastern (1400 or 1500 UTC), or should we consider a change? = = [1] http://fedoraproject.org/wiki/Releases/10/Schedule -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Thu Sep 4 15:55:58 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 04 Sep 2008 11:55:58 -0400 Subject: Fedora release time? In-Reply-To: <1220543093.7673.2.camel@localhost.localdomain> References: <1220543093.7673.2.camel@localhost.localdomain> Message-ID: <1220543758.17785.14.camel@rosebud> On Thu, 2008-09-04 at 11:44 -0400, Paul W. Frields wrote: > Historically, the release time on a given release date has been 10:00am > Eastern time.[1] However, Jesse Keating, who's one of our release > engineers, is now on Pacific time, which makes this 7:00am by his clock. > Are we going to stay with 10:00am Eastern (1400 or 1500 UTC), or should > we consider a change? Jesse has a small child. He's up at 7am anyway.... -sv From pemboa at gmail.com Thu Sep 4 16:01:39 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 4 Sep 2008 11:01:39 -0500 Subject: Fedora release time? In-Reply-To: <1220543758.17785.14.camel@rosebud> References: <1220543093.7673.2.camel@localhost.localdomain> <1220543758.17785.14.camel@rosebud> Message-ID: <16de708d0809040901xe1d86e6re22ba4bba9ea4dc@mail.gmail.com> On Thu, Sep 4, 2008 at 10:55 AM, Seth Vidal wrote: > On Thu, 2008-09-04 at 11:44 -0400, Paul W. Frields wrote: >> Historically, the release time on a given release date has been 10:00am >> Eastern time.[1] However, Jesse Keating, who's one of our release >> engineers, is now on Pacific time, which makes this 7:00am by his clock. >> Are we going to stay with 10:00am Eastern (1400 or 1500 UTC), or should >> we consider a change? > > Jesse has a small child. > > He's up at 7am anyway.... > > -sv Will it help if we send him a six pack? Seems like a fair trade for a release. -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) From hughsient at gmail.com Thu Sep 4 16:05:43 2008 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 04 Sep 2008 17:05:43 +0100 Subject: Fedora release time? In-Reply-To: <16de708d0809040901xe1d86e6re22ba4bba9ea4dc@mail.gmail.com> References: <1220543093.7673.2.camel@localhost.localdomain> <1220543758.17785.14.camel@rosebud> <16de708d0809040901xe1d86e6re22ba4bba9ea4dc@mail.gmail.com> Message-ID: <1220544343.1233.7.camel@hughsie-work> On Thu, 2008-09-04 at 11:01 -0500, Arthur Pemberton wrote: > Will it help if we send him a six pack? Seems like a fair trade for a > release. I don't think anyone would mind slipping the release a few hours. Let's face it: 7am is no fun for most normal[1] people. Richard. [1] yes. From mike at miketc.net Thu Sep 4 16:10:18 2008 From: mike at miketc.net (Mike Chambers) Date: Thu, 04 Sep 2008 11:10:18 -0500 Subject: Fedora release time? In-Reply-To: <1220543093.7673.2.camel@localhost.localdomain> References: <1220543093.7673.2.camel@localhost.localdomain> Message-ID: <1220544618.9021.1.camel@scrappy.miketc.net> On Thu, 2008-09-04 at 11:44 -0400, Paul W. Frields wrote: > Historically, the release time on a given release date has been 10:00am > Eastern time.[1] However, Jesse Keating, who's one of our release > engineers, is now on Pacific time, which makes this 7:00am by his clock. > Are we going to stay with 10:00am Eastern (1400 or 1500 UTC), or should > we consider a change? Why not around 12pm EST? That would put PST around 9am and anywhere in between is still pretty close to 10 still, and Jessee can have cup or two of coffee at least by then. -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From pertusus at free.fr Thu Sep 4 16:11:51 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 4 Sep 2008 18:11:51 +0200 Subject: help needed for a failed build, libnc-dap C++ Message-ID: <20080904161151.GD3366@free.fr> Hello all, As a preamble, I am not very good in C++ but upstream are good C++ coders and they haven't found a solution so far. I have a package that fails to build since gcc 4.3, libnc-dap, and I am lost about what could be wrong. It is basically a library and a utility built on top of the library. When linking the utility, it gets: ../.libs/libnc-dap.so: undefined reference to `Connections::operator[](int)' However in Connections.cc, there is: template T & Connections::operator[](int i) { return _conns[i]; } which looks good. Any advice? koji failed build can be found at: http://koji.fedoraproject.org/koji/getfile?taskID=806722&name=build.log srpm built by koji is at: http://koji.fedoraproject.org/koji/getfile?taskID=806715&name=libnc-dap-3.7.0-11.fc10.src.rpm This is very annoying since this issue is also present in the latest libnc-dap version and it prevents from updating the whole libdap/OPeNDAP stack. Thanks in advance. -- Pat From ville.skytta at iki.fi Thu Sep 4 16:13:43 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 4 Sep 2008 19:13:43 +0300 Subject: Dependency loops considered harmful? In-Reply-To: <54421.198.175.55.5.1220469047.squirrel@mail.jcomserv.net> References: <20080903165835.GA31342@localhost> <20080903210716.2ada82b2.mschwendt@gmail.com> <54421.198.175.55.5.1220469047.squirrel@mail.jcomserv.net> Message-ID: <200809041913.43879.ville.skytta@iki.fi> On Wednesday 03 September 2008, Jon Ciesla wrote: > > Case 1) > > game-data-0.8 Requires game = 0.8 > > What happens if game-1.0 is released with unchanged game-data? > > Then you need to update game-data for nothing else than the broken dep. > > I've yet to see this happen. Not sure if you mean the whole scenario (including the dependency) above, but for example uqm is one game that has been updated with game data staying the same more than once. It does not have the "=" dep like the above though. From a.badger at gmail.com Thu Sep 4 16:20:40 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 04 Sep 2008 09:20:40 -0700 Subject: Dependency loops considered harmful? In-Reply-To: References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> Message-ID: <48C00AD8.8050202@gmail.com> Matej Cepl wrote: > On 2008-09-03, 23:41 GMT, Toshio Kuratomi wrote: >> That works for a Mom and Pop desktop but doesn't work as >> a developer's workstation. When developing software you might >> need a library that does Foo. Look on the system, hey, I can >> use libFoo! A few weeks later, when you remove Gnome-Foo from >> your system because your shiny new application does the job, >> your app suddenly can't find libFoo.... > > No, you would still find libFoo, because yum would still have > recorded that libFoo was directly installed, and not just to > satisfy dependency on Gnome-foo. Don't say it is not possible, > when it was working (and I were using it) for years on Debian. > You're misunderstanding the scenario. libFoo is not directly installed. It's installed to satisfy the dependency for Gnome-Foo. But after it's installed, I start looking for something that let's me develop a new program that does Foo. libFoo is installed on my system so I start using it to create my app. This is possibly more pronounced in the world of scripting languages where runtime and development bits are one and the same package. > Moreover, even if it didn't help your developer (and I claim that > it would), I would still prefer solution which cures problems of > at least normal users and wouldn't help developers (who should > now how to fix their system). > In my reply to Callum Lerwick I pointed out that this is a fallacy. Developers != System Administrators. Developers are end-users just like Mom and Pop firefox+openoffice users. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From vgaburici at gmail.com Thu Sep 4 16:23:32 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Thu, 4 Sep 2008 19:23:32 +0300 Subject: nspluginwrapper and nppdf.so (Adobe Acrobat) In-Reply-To: References: <200809011255.m81CtqSi031735@jasmine.xos.nl> Message-ID: I think it had some sort of memory leak when used with Adobe's Reader 8.1.2. On Thu, Sep 4, 2008 at 3:57 PM, Jason L Tibbitts III wrote: >>>>>> "MC" == Matej Cepl writes: > > MC> File a bug against nspluginwrapper, please. > > I would be surprised if this wasn't already filed, since it looks like > any of several open tickets. > http://bugz.fedoraproject.org/nspluginwrapper > > - J< > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From a.badger at gmail.com Thu Sep 4 16:31:11 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 04 Sep 2008 09:31:11 -0700 Subject: Dependency loops considered harmful? In-Reply-To: References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> Message-ID: <48C00D4F.2030004@gmail.com> Thomas Moschny wrote: > 2008/9/4 Toshio Kuratomi : >> With that said, there needs to be a way for a developer to tell yum not >> to prune away leaf packages if they want. > > % yum install libFoo > > this might look like a noop, because libFoo is already installed, but > it would switch the bit for libFoo from 'installed-as-dependency' to > 'first-class-installed'. > That's a good point. I'd much rather have a switch to turn the feature on or off per machine than to have to remember this per library, though. Apps can have a myriad of dependencies. Should the developer have to do sudo yum install libFoo for every one of these? Everytime he grows a new dependency? Everytime he tries out libFoo vs libUWFoo to do his dirty work? Much better to (1) get hit by this, (2) curse, (3) google, (4) flip one config file switch than to (1) get hit by this, (2) google, (3) yum install libFoo libBar, (4) add a new dependency to your package, (5) get hit by this, (6) yum install libBaz, (7) get hit by this, (8) curse, (9) switch to ArchLinux. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From mike at miketc.net Thu Sep 4 16:34:48 2008 From: mike at miketc.net (Mike Chambers) Date: Thu, 04 Sep 2008 11:34:48 -0500 Subject: Rawhide install traceback Message-ID: <1220546088.2809.7.camel@scrappy.miketc.net> Soon as the install starts (via netboot.iso) while getting/searching for the image, it tracebacks but I couldn't see it all or capture it. Caught last couple lines and showed "(d?)bus.py" couple time and I think "connect.py". Never saw the GUI screen itself or anything, rebooted, or was ready too. 386 type install btw. -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From nicolas.mailhot at laposte.net Thu Sep 4 16:44:07 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 04 Sep 2008 18:44:07 +0200 Subject: Dependency loops considered harmful? In-Reply-To: <48C00D4F.2030004@gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <48C00D4F.2030004@gmail.com> Message-ID: <1220546647.12846.22.camel@rousalka.okg> Le jeudi 04 septembre 2008 ? 09:31 -0700, Toshio Kuratomi a ?crit : > Thomas Moschny wrote: > > 2008/9/4 Toshio Kuratomi : > >> With that said, there needs to be a way for a developer to tell yum not > >> to prune away leaf packages if they want. > > > > % yum install libFoo > > > > this might look like a noop, because libFoo is already installed, but > > it would switch the bit for libFoo from 'installed-as-dependency' to > > 'first-class-installed'. > > > That's a good point. > > I'd much rather have a switch to turn the feature on or off per machine > than to have to remember this per library, though. Apps can have a > myriad of dependencies. Should the developer have to do sudo yum > install libFoo for every one of these? Everytime he grows a new > dependency? Quite frankly the argument that the developper could not write a spec file was already poor (because specs are a piece of cake next to makefiles and autofoo), but the argument he can not care about the deps his app uses is ridiculous (both from a technical and legal POW). Please don't take it bad, but developping is more than copying snippets of code, and a developper that can not care about his software environment is not worth the name. -- 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 dcantrell at redhat.com Thu Sep 4 16:47:32 2008 From: dcantrell at redhat.com (David Cantrell) Date: Thu, 4 Sep 2008 06:47:32 -1000 Subject: Rawhide install traceback In-Reply-To: <1220546088.2809.7.camel@scrappy.miketc.net> References: <1220546088.2809.7.camel@scrappy.miketc.net> Message-ID: <85D8E0E1-B1C5-4FA5-8D9A-9D54BA7B9467@redhat.com> On Sep 4, 2008, at 6:34 AM, Mike Chambers wrote: > Soon as the install starts (via netboot.iso) while getting/searching > for > the image, it tracebacks but I couldn't see it all or capture it. > Caught last couple lines and showed "(d?)bus.py" couple time and I > think > "connect.py". Never saw the GUI screen itself or anything, > rebooted, or > was ready too. 386 type install btw. Known. Working on it. If you can gather any more details and file a bug, it would help. It might get closed as a dupe of another, but it always helps to have other people collecting info and filing bugs. -- David Cantrell Red Hat / Honolulu, HI From clumens at redhat.com Thu Sep 4 16:47:49 2008 From: clumens at redhat.com (Chris Lumens) Date: Thu, 4 Sep 2008 12:47:49 -0400 Subject: Rawhide install traceback In-Reply-To: <1220546088.2809.7.camel@scrappy.miketc.net> References: <1220546088.2809.7.camel@scrappy.miketc.net> Message-ID: <20080904164749.GA4575@localhost.localdomain> > Soon as the install starts (via netboot.iso) while getting/searching for > the image, it tracebacks but I couldn't see it all or capture it. > Caught last couple lines and showed "(d?)bus.py" couple time and I think > "connect.py". Never saw the GUI screen itself or anything, rebooted, or > was ready too. 386 type install btw. https://bugzilla.redhat.com/show_bug.cgi?id=461071 - Chris From mike at miketc.net Thu Sep 4 17:05:02 2008 From: mike at miketc.net (Mike Chambers) Date: Thu, 04 Sep 2008 12:05:02 -0500 Subject: Rawhide install traceback In-Reply-To: <20080904164749.GA4575@localhost.localdomain> References: <1220546088.2809.7.camel@scrappy.miketc.net> <20080904164749.GA4575@localhost.localdomain> Message-ID: <1220547902.2809.8.camel@scrappy.miketc.net> On Thu, 2008-09-04 at 12:47 -0400, Chris Lumens wrote: > > Soon as the install starts (via netboot.iso) while getting/searching for > > the image, it tracebacks but I couldn't see it all or capture it. > > Caught last couple lines and showed "(d?)bus.py" couple time and I think > > "connect.py". Never saw the GUI screen itself or anything, rebooted, or > > was ready too. 386 type install btw. > > https://bugzilla.redhat.com/show_bug.cgi?id=461071 That would be the bug I saw, and added myself to the cc. Jesse already provided screen shot of what I saw as well. -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From fedora at leemhuis.info Thu Sep 4 17:15:18 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 04 Sep 2008 19:15:18 +0200 Subject: Fedora release time? In-Reply-To: <1220544343.1233.7.camel@hughsie-work> References: <1220543093.7673.2.camel@localhost.localdomain> <1220543758.17785.14.camel@rosebud> <16de708d0809040901xe1d86e6re22ba4bba9ea4dc@mail.gmail.com> <1220544343.1233.7.camel@hughsie-work> Message-ID: <48C017A6.6090902@leemhuis.info> On 04.09.2008 18:05, Richard Hughes wrote: > On Thu, 2008-09-04 at 11:01 -0500, Arthur Pemberton wrote: >> Will it help if we send him a six pack? Seems like a fair trade for a >> release. > I don't think anyone would mind slipping the release a few hours. It matters a whole lot for the press in Europe -- likely one of the reasons why big announcements from international companies based in the US often tend to be 10:00am Eastern time (+/- one hour) -- that way you get the press people from Europe (still working) and the US (started working) in one go and get more attention on the internet within a few hours. Two or three hours later than 10am EST most computer journalists in Europe likely are at home or on their way home; when they start working on the next day it's old news then and some might just drop it. IOW: My vote goes to stick to 10am EST, at least for the real Fedora releases. Cu knurd From mlichvar at redhat.com Thu Sep 4 17:30:48 2008 From: mlichvar at redhat.com (Miroslav Lichvar) Date: Thu, 4 Sep 2008 19:30:48 +0200 Subject: help needed for a failed build, libnc-dap C++ In-Reply-To: <20080904161151.GD3366@free.fr> References: <20080904161151.GD3366@free.fr> Message-ID: <20080904173048.GA32528@localhost> On Thu, Sep 04, 2008 at 06:11:51PM +0200, Patrice Dumas wrote: > I have a package that fails to build since gcc 4.3, libnc-dap, and I am > lost about what could be wrong. It is basically a library and a utility > built on top of the library. When linking the utility, it gets: > > ../.libs/libnc-dap.so: undefined reference to `Connections::operator[](int)' The problem is that the function isn't used only in Dnc.cc (where Connections.cc is included). Probably the easiest fix is to add the following line somewhere in Dnc.cc and make it visible for other modules. template NCConnect* & Connections::operator[](int i); -- Miroslav Lichvar From a.badger at gmail.com Thu Sep 4 18:01:26 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 04 Sep 2008 11:01:26 -0700 Subject: Dependency loops considered harmful? In-Reply-To: <1220546647.12846.22.camel@rousalka.okg> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <48C00D4F.2030004@gmail.com> <1220546647.12846.22.camel@rousalka.okg> Message-ID: <48C02276.2080708@gmail.com> Nicolas Mailhot wrote: > Le jeudi 04 septembre 2008 ? 09:31 -0700, Toshio Kuratomi a ?crit : >> Thomas Moschny wrote: >>> 2008/9/4 Toshio Kuratomi : >>>> With that said, there needs to be a way for a developer to tell yum not >>>> to prune away leaf packages if they want. >>> % yum install libFoo >>> >>> this might look like a noop, because libFoo is already installed, but >>> it would switch the bit for libFoo from 'installed-as-dependency' to >>> 'first-class-installed'. >>> >> That's a good point. >> >> I'd much rather have a switch to turn the feature on or off per machine >> than to have to remember this per library, though. Apps can have a >> myriad of dependencies. Should the developer have to do sudo yum >> install libFoo for every one of these? Everytime he grows a new >> dependency? > > Quite frankly the argument that the developper could not write a spec > file was already poor (because specs are a piece of cake next to > makefiles and autofoo), I disagree on several points: * If it was really so easy all upstreams would ship with a debian control script or a spec file or gentoo ebuild * I'm sure you've taken a look at the state of upstream's makefiles and autofoo. If they can get that wrong, then getting spec files horribly wrong is only one frustrating step more. * Not every set of build scripts is as hard to create as Makefile/autofoo. Some of them are very easy to setup compared to spec files. Even worse, some of these easy build script systems are inflexible which makes packaging harder. Some developers are good with build scripts. These developers would probably also make excellent packagers. Other developers want to stick strictly with the code they're building their app with. Those people are going to be unhappy enough creating Makefiles, let alone spec files. > but the argument he can not care about the deps > his app uses is ridiculous (both from a technical and legal POW). > I'm not talking about caring about the deps. I'm talking about record keeping for the deps. Sure I know that the app I'm developing requires Foo, Bar, Baz, and Brigit but I don't know which of those is going to disappear in the next round of leaf node pruning. Also, what happens when I start working collaboratively on a project? For instance I shift departments at my University and start working on a weather visualization app. I checkout the source from the department revision control and lo, everything works because I presently have all of the libraries installed. I start hacking away on the rendering portion of the app. I also add and remove application software from my system using the friendly and intuitive PackageKit interface. One day, auto-prune runs and removes a networking library since no presently installed package requires it. Unfortunately, the program requires that in order to run. Suddenly the app stops working for some reason I do not understand due to some segment of code I've never touched. > Please don't take it bad, but developping is more than copying snippets > of code, and a developper that can not care about his software > environment is not worth the name. But is such a developer worth less of our time than any other end-user who does not care about their environment and just wants things to work? I'd argue that having an app work one day and suddenly stop working the next is something we should *not* be striving to achieve even if said app is not packaged. It leads to the perception that our distribution is unreliable and breaks easily. This is an extension of the argument that we should not be upgrading library major versions in a released Fedora due to breakage in software outside our control. Now this is something of a UI issue -- I'm against pruning like this automatically with out a switch to turn it off. But auto pruning with an opt-out would be okay. Having to explicitly touch each library just strikes me as bad UI and a support nightmare. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From mw_triad at users.sourceforge.net Thu Sep 4 18:26:20 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 04 Sep 2008 13:26:20 -0500 Subject: Dependency loops considered harmful? In-Reply-To: <48BF20C4.4050500@gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> Message-ID: Toshio Kuratomi wrote: > Callum Lerwick wrote: >> On Wed, 2008-09-03 at 14:12 -0400, Stephen Gallagher wrote: >>> Applications that consist of multiple packages, such as the game >>> example, should be designated as a group rather than a looped >>> dependency. >> Actually a proper fix is to implement the per-package "explicitly >> installed/pulled in as a dep" flag that has been discussed several times >> in the past, and is already implemented (thus proven) in the "aptitude" >> apt front end. >> >> We must address this user interface problem if Fedora is to be a shining >> beacon of open source light in the looming dark future of closed >> DRM-laden content delivery services such as Steam, Xbox Live and >> PlayStation Network. >> > That works for a Mom and Pop desktop but doesn't work as a developer's > workstation. When developing software you might need a library that > does Foo. Look on the system, hey, I can use libFoo! A few weeks > later, when you remove Gnome-Foo from your system because your shiny new > application does the job, your app suddenly can't find libFoo.... This implies also that you installed Gnome-Foo-devel for whatever reason, and that it happened to require libFoo-devel. Otherwise you probably installed libFoo-devel by hand in order to use libFoo, and since libFoo-devel depends on libFoo, libFoo wouldn't be removed in this case. > (Worse is if your working on an app sporadically and have to figure out > why it's broken not knowing when it became that way.) Are link errors really that obtuse? > So if we track this some way, there needs to be a way to disable it. Naturally :-). -- Matthew This message represents the official view of the voices in my head. -- Unknown (found at http://goldmark.org/jeff/stupid-disclaimers/fun.html) From mw_triad at users.sourceforge.net Thu Sep 4 18:31:56 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 04 Sep 2008 13:31:56 -0500 Subject: Dependency loops considered harmful? In-Reply-To: <20080904113210.4d1b2c83.mschwendt@gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <20080904113210.4d1b2c83.mschwendt@gmail.com> Message-ID: Michael Schwendt wrote: > On Thu, 04 Sep 2008 02:23:11 -0500, Callum Lerwick wrote: > >>> That works for a Mom and Pop desktop but doesn't work as a developer's >>> workstation. When developing software you might need a library that >>> does Foo. Look on the system, hey, I can use libFoo! A few weeks >>> later, when you remove Gnome-Foo from your system because your shiny new >>> application does the job, >> Why would you do such a thing? > > Because developers build their app from local working-directories (or > check-outs from source code management systems) and run the software from > the same private path or install into /usr/local for testing. It's not > unusual to install without using RPM. ...which is, in a sense, the real problem. The issue as I see it is that rolling an RPM takes a *lot* more time and effort than 'make install', especially with CMake (2.6 does /very/ fast installs). It would be REALLY GOOD to install everything as an rpm (not least because this would clean up cruft from old builds!), but it needs to be fast, and it needs to be do-able without using root privilege. Otherwise I think the costs will outweigh the benefits for a lot of people. -- Matthew This message represents the official view of the voices in my head. -- Unknown (found at http://goldmark.org/jeff/stupid-disclaimers/fun.html) From seg at haxxed.com Thu Sep 4 18:36:09 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 04 Sep 2008 13:36:09 -0500 Subject: Dependency loops considered harmful? In-Reply-To: <48BFADBD.6080103@gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> Message-ID: <1220553370.4415.96.camel@localhost.localdomain> On Thu, 2008-09-04 at 02:43 -0700, Toshio Kuratomi wrote: > >> your app suddenly can't find libFoo.... > >> (Worse is if your working on an app sporadically and have to figure out > >> why it's broken not knowing when it became that way.) Is knowing how to use "yum whatprovides" really too much to ask? A developer who was hit by this would merely need to run "yum whatprovides libFoo.so", then install the necessary package with "yum install libfoo". Since they asked for it by name, it would not be flagged as a dep, and thus be immune from future package culling. And furthermore, a developer using libFoo would have to have libfoo-devel installed. Most likely libfoo-devel is a leaf itself, thus is there because the developer specifically installed it, making it immune from culling. Since -devel packages must depend on the main package, libfoo would remain pinned in the system as long as libfoo-devel is installed. libfoo would never disappear unless the user/developer started deliberately removing -devel packages. If they do such a thing without understanding the potential consequences to their un-packaged applications, they deserve what they get. And that is a problem that has little to do with the proposed auto-culling system. > If I'm developing an app, I'm going to be working on code, not taking > time out to package the app as an rpm. Only after I'm ready to take the > app and put it somewhere for other people to download and use am I going > to start worrying about packaging. Then you accept the consequences of such a development methodology. > >> So if we track this some way, there needs to be a way to disable it. > > > > A developer presumably doesn't use the hypothetical simplified > > application installer. They use something more advanced. Like aptitude. > > > Err.... You've totally lost me here. If we implement this, it needs to > be at a low enough level that anyone installing packages on the system > will be storing the information. This would be ideal, but not strictly necessary. If some tool doesn't know or care about the flag, it should default to "off", meaning "not pulled in as a dep", which would maximally prevent surprises. This is how aptitude works, it stores the "is a dep" flags in its own configuration. Any packages installed outside of aptitude are assumed to be explicitly installed. Yes, the flag should be stored in the RPM database itself, but it is not strictly necessary to implement a proof-of-concept, at say the yum level. Pretty much all our "official" tools are going through yum these days anyway... > That could mean rpm (since rpm is > responsible for taking the package and turning it into files on the > filesystem) or that could mean yum since yum is the one that actually > knows whether a package is being installed due to depsolving or user > request. Doing this at a higher level means that information gets lost > (for instance, if you do this in PackageKit, there won't be any > information about what anaconda chose to install due to chckboxes being > clicked and which things were installed due to dependencies). All the RPM database needs to do is store a single lousy bit of information per package. The "is a dep" flag. Presumably installing packages directly with rpm would not set this flag. Perhaps rpm could provide a command to toggle the flag. RPM itself would not care what the flag means. Giving it meaning happens at the dep solver level. (Aptitude has its own dep solver, which allows it to do the on-the-fly interactive dep-solving that makes it so awesome) > With that said, there needs to be a way for a developer to tell yum not > to prune away leaf packages if they want. An advanced front end, such as aptitude, allows you to manually toggle the "is a dep" flag with a single keystroke. And instantly shows you the effect of doing so. And makes you look at a detailed summary of every transaction before it is performed, giving you ample opportunity to reconsider what you're doing. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From stransky at redhat.com Thu Sep 4 18:52:54 2008 From: stransky at redhat.com (Martin Stransky) Date: Thu, 04 Sep 2008 20:52:54 +0200 Subject: nspluginwrapper and nppdf.so (Adobe Acrobat) In-Reply-To: References: <200809011255.m81CtqSi031735@jasmine.xos.nl> Message-ID: <48C02E86.4060400@redhat.com> Jason L Tibbitts III wrote: >>>>>> "MC" == Matej Cepl writes: > > MC> File a bug against nspluginwrapper, please. > > I would be surprised if this wasn't already filed, since it looks like > any of several open tickets. > http://bugz.fedoraproject.org/nspluginwrapper I don't see it filed anywhere. If you want me to take a look at it please file a BZ. From vgaburici at gmail.com Thu Sep 4 19:05:22 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Thu, 4 Sep 2008 22:05:22 +0300 Subject: Dependency loops considered harmful? In-Reply-To: <1220553370.4415.96.camel@localhost.localdomain> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <1220553370.4415.96.camel@localhost.localdomain> Message-ID: The problem with using rpm to install software you develop is that you need to do a *full build* every time whenever you change something. Even with a caching compiler, that can take a long time. Think Qt for instance. From jos at xos.nl Thu Sep 4 19:05:50 2008 From: jos at xos.nl (Jos Vos) Date: Thu, 4 Sep 2008 21:05:50 +0200 Subject: nspluginwrapper and nppdf.so (Adobe Acrobat) In-Reply-To: <48C02E86.4060400@redhat.com> References: <200809011255.m81CtqSi031735@jasmine.xos.nl> <48C02E86.4060400@redhat.com> Message-ID: <20080904190550.GA16325@jasmine.xos.nl> On Thu, Sep 04, 2008 at 08:52:54PM +0200, Martin Stransky wrote: > I don't see it filed anywhere. If you want me to take a look at it > please file a BZ. Well, at first sight this best seems to describe the problem: https://bugzilla.redhat.com/show_bug.cgi?id=456017 The behavior was a bit confusing, but IIRC obscuring was the start for several problems. And sometimes the initial window stayed blank too (not always, but that might be related to whether I switched to other virtual desktops in the meantime). If you want me to test something specific, I'll try do that tomorrow when I'm having access again to a F9 testsystem. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From vgaburici at gmail.com Thu Sep 4 19:11:58 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Thu, 4 Sep 2008 22:11:58 +0300 Subject: A couple of license-relate questions Message-ID: 1) If some files of a program are BSD and some are GPLv2, is it necessary to include the BSD license file in the rpm package (even if upstream doesn't)? 2) Can someone take a look at the Adobe Glyph List license [http://www.adobe.com/devnet/opentype/archives/glyphlist.txt] and determine what is the appropriate rpm license field for it? If you want more context, see: https://bugzilla.redhat.com/show_bug.cgi?id=458430 Thanks, Vasile From a.badger at gmail.com Thu Sep 4 19:21:56 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 04 Sep 2008 12:21:56 -0700 Subject: Dependency loops considered harmful? In-Reply-To: References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> Message-ID: <48C03554.7030303@gmail.com> Matthew Woehlke wrote: > Toshio Kuratomi wrote: >> Callum Lerwick wrote: >>> On Wed, 2008-09-03 at 14:12 -0400, Stephen Gallagher wrote: >>>> Applications that consist of multiple packages, such as the game >>>> example, should be designated as a group rather than a looped >>>> dependency. >>> Actually a proper fix is to implement the per-package "explicitly >>> installed/pulled in as a dep" flag that has been discussed several times >>> in the past, and is already implemented (thus proven) in the "aptitude" >>> apt front end. >>> >>> We must address this user interface problem if Fedora is to be a shining >>> beacon of open source light in the looming dark future of closed >>> DRM-laden content delivery services such as Steam, Xbox Live and >>> PlayStation Network. >>> >> That works for a Mom and Pop desktop but doesn't work as a developer's >> workstation. When developing software you might need a library that >> does Foo. Look on the system, hey, I can use libFoo! A few weeks >> later, when you remove Gnome-Foo from your system because your shiny new >> application does the job, your app suddenly can't find libFoo.... > > This implies also that you installed Gnome-Foo-devel for whatever > reason, and that it happened to require libFoo-devel. Otherwise you > probably installed libFoo-devel by hand in order to use libFoo, and > since libFoo-devel depends on libFoo, libFoo wouldn't be removed in this > case. > Not necessarily, as I pointed out here: https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00235.html """ This is possibly more pronounced in the world of scripting languages where runtime and development bits are one and the same package. """ -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From skvidal at fedoraproject.org Thu Sep 4 19:27:43 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 04 Sep 2008 15:27:43 -0400 Subject: Dependency loops considered harmful? In-Reply-To: <48C00D4F.2030004@gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <48C00D4F.2030004@gmail.com> Message-ID: <1220556463.17785.30.camel@rosebud> On Thu, 2008-09-04 at 09:31 -0700, Toshio Kuratomi wrote: > Thomas Moschny wrote: > > 2008/9/4 Toshio Kuratomi : > >> With that said, there needs to be a way for a developer to tell yum not > >> to prune away leaf packages if they want. > > > > % yum install libFoo > > > > this might look like a noop, because libFoo is already installed, but > > it would switch the bit for libFoo from 'installed-as-dependency' to > > 'first-class-installed'. > > > That's a good point. > Okay this is obviously just Proof code so take it as read - but grab this script: http://skvidal.fedorapeople.org/misc/remove-recurse.py and run it with one arg being the pkg you wish to remove. It will print out what it would end up doing if it was removed. for example: # python remove-recurse.py easytag remove easytag removing id3lib-3.8.3-20.fc9.i386 b/c it is not required by anything else removing libmp4v2-1.5.0.1-6.fc9.i386 b/c it is not required by anything else libmp4v2.i386 0-1.5.0.1-6.fc9 - e id3lib.i386 0-3.8.3-20.fc9 - e easytag.i386 0-2.1-5.fc9 - e It doesn't actually change anything, just prints out what would happen. then tell me which (and I'm sure there are many) cases it doesn't properly address. -sv From a.badger at gmail.com Thu Sep 4 20:07:15 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 04 Sep 2008 13:07:15 -0700 Subject: Dependency loops considered harmful? In-Reply-To: <1220556463.17785.30.camel@rosebud> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <48C00D4F.2030004@gmail.com> <1220556463.17785.30.camel@rosebud> Message-ID: <48C03FF3.9040903@gmail.com> Seth Vidal wrote: > Okay this is obviously just Proof code so take it as read - but grab > this script: > > http://skvidal.fedorapeople.org/misc/remove-recurse.py > > and run it with one arg being the pkg you wish to remove. It will print > out what it would end up doing if it was removed. > > for example: > > # python remove-recurse.py easytag > remove easytag > removing id3lib-3.8.3-20.fc9.i386 b/c it is not required by anything > else > removing libmp4v2-1.5.0.1-6.fc9.i386 b/c it is not required by anything > else > libmp4v2.i386 0-1.5.0.1-6.fc9 - e > id3lib.i386 0-3.8.3-20.fc9 - e > easytag.i386 0-2.1-5.fc9 - e > > > > It doesn't actually change anything, just prints out what would happen. > then tell me which (and I'm sure there are many) cases it doesn't > properly address. > -sv > > [badger at Clingman tmp]$ sudo ./remove-recurse.py yum [...] removing pygpgme-0.1-8.fc9.i386 b/c it is not required by anything else removing python-iniparse-0.2.3-3.fc9.noarch b/c it is not required by anything else As it turns out, I personally need both of these deps. I have a script in ~/bin/ that uses pygpgme. I also am working on fas in a local checkout which requires pygpgme. And I'm evaluating python-iniparse and python-configobj to see which one I'm going to be using for some fedora infrastructure scripts. So -- I like having a script that can remove things recursively. Even better if I could do: sudo remove-recurse.py yum --exclude pygpgme I just wouldn't want this kind of thing to be automatic or to be the default when I do "yum remove" -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From seg at haxxed.com Thu Sep 4 20:13:27 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 04 Sep 2008 15:13:27 -0500 Subject: Dependency loops considered harmful? In-Reply-To: References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <1220553370.4415.96.camel@localhost.localdomain> Message-ID: <1220559207.4415.105.camel@localhost.localdomain> On Thu, 2008-09-04 at 22:05 +0300, Vasile Gaburici wrote: > The problem with using rpm to install software you develop is that you > need to do a *full build* every time whenever you change something. > Even with a caching compiler, that can take a long time. Think Qt for > instance. This is going off on an unproductive tangent. No, I'm not saying use RPM packaging during your edit-compile-test loop. You do it for longer term testing and deployment. Why would you, in the middle of a development session, suddenly decide you need to remove Rhythmbox? Because you ran out of disk space? This corner case is getting increasingly obscure. Since you're in the middle of a development session, you'd notice right away your app just broke, and I'd hope you'd realize it was because of the thing you just did. If we allowed obscure corner cases to veto every engineering proposal, we'd never get anything done. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Thu Sep 4 20:32:29 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 04 Sep 2008 16:32:29 -0400 Subject: Dependency loops considered harmful? In-Reply-To: <48C03FF3.9040903@gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <48C00D4F.2030004@gmail.com> <1220556463.17785.30.camel@rosebud> <48C03FF3.9040903@gmail.com> Message-ID: <1220560349.17785.37.camel@rosebud> On Thu, 2008-09-04 at 13:07 -0700, Toshio Kuratomi wrote: > Seth Vidal wrote: > > Okay this is obviously just Proof code so take it as read - but grab > > this script: > > > > http://skvidal.fedorapeople.org/misc/remove-recurse.py > > > > and run it with one arg being the pkg you wish to remove. It will print > > out what it would end up doing if it was removed. > > > > for example: > > > > # python remove-recurse.py easytag > > remove easytag > > removing id3lib-3.8.3-20.fc9.i386 b/c it is not required by anything > > else > > removing libmp4v2-1.5.0.1-6.fc9.i386 b/c it is not required by anything > > else > > libmp4v2.i386 0-1.5.0.1-6.fc9 - e > > id3lib.i386 0-3.8.3-20.fc9 - e > > easytag.i386 0-2.1-5.fc9 - e > > > > > > > > It doesn't actually change anything, just prints out what would happen. > > then tell me which (and I'm sure there are many) cases it doesn't > > properly address. > > -sv > > > > > [badger at Clingman tmp]$ sudo ./remove-recurse.py yum > [...] > removing pygpgme-0.1-8.fc9.i386 b/c it is not required by anything else > removing python-iniparse-0.2.3-3.fc9.noarch b/c it is not required by > anything else > > As it turns out, I personally need both of these deps. I have a script > in ~/bin/ that uses pygpgme. I also am working on fas in a local > checkout which requires pygpgme. And I'm evaluating python-iniparse and > python-configobj to see which one I'm going to be using for some fedora > infrastructure scripts. > > So -- I like having a script that can remove things recursively. Even > better if I could do: > sudo remove-recurse.py yum --exclude pygpgme > > I just wouldn't want this kind of thing to be automatic or to be the > default when I do "yum remove" > I mostly agree. I sorta think that _maybe_ your case is becoming more of the edge case and a lot more folks want to remove all the things that just got dragged in when they ran: yum install this_really_cool_thing So, if there were an option to let you disable leaf removal would that work out? -sv From seg at haxxed.com Thu Sep 4 20:36:12 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 04 Sep 2008 15:36:12 -0500 Subject: Dependency loops considered harmful? In-Reply-To: <48C03FF3.9040903@gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <48C00D4F.2030004@gmail.com> <1220556463.17785.30.camel@rosebud> <48C03FF3.9040903@gmail.com> Message-ID: <1220560572.4415.121.camel@localhost.localdomain> On Thu, 2008-09-04 at 13:07 -0700, Toshio Kuratomi wrote: > [badger at Clingman tmp]$ sudo ./remove-recurse.py yum > [...] > removing pygpgme-0.1-8.fc9.i386 b/c it is not required by anything else > removing python-iniparse-0.2.3-3.fc9.noarch b/c it is not required by > anything else Using yum to remove yum? Talk about grasping for straw men. Can we argue realistic scenarios, please? > As it turns out, I personally need both of these deps. I have a script > in ~/bin/ that uses pygpgme. I also am working on fas in a local > checkout which requires pygpgme. And I'm evaluating python-iniparse and > python-configobj to see which one I'm going to be using for some fedora > infrastructure scripts. So pay attention to what you're doing and don't carelessly remove core tools. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Thu Sep 4 20:55:43 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 04 Sep 2008 15:55:43 -0500 Subject: Dependency loops considered harmful? In-Reply-To: <1220556463.17785.30.camel@rosebud> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <48C00D4F.2030004@gmail.com> <1220556463.17785.30.camel@rosebud> Message-ID: <1220561743.4415.129.camel@localhost.localdomain> On Thu, 2008-09-04 at 15:27 -0400, Seth Vidal wrote: > Okay this is obviously just Proof code so take it as read - but grab > this script: > > http://skvidal.fedorapeople.org/misc/remove-recurse.py > > and run it with one arg being the pkg you wish to remove. It will print > out what it would end up doing if it was removed. > It doesn't actually change anything, just prints out what would happen. > then tell me which (and I'm sure there are many) cases it doesn't > properly address. > -sv Neat. Here, for the sake of argument, here's the kind of use cases I have in mind: $ sudo ./remove-recurse.py inkscape remove inkscape Loaded plugins: fedorakmod, refresh-packagekit removing numpy-1.1.0-1.fc9.x86_64 b/c it is not required by anything else removing ImageMagick-perl-6.3.8.1-4.fc9.x86_64 b/c it is not required by anything else removing perl-XML-XQL-0.68-6.fc9.noarch b/c it is not required by anything else removing pstoedit-3.45-2.fc9.x86_64 b/c it is not required by anything else removing python-lxml-2.0.7-1.fc9.x86_64 b/c it is not required by anything else removing libEMF-1.0.3-7.fc9.x86_64 b/c it is not required by anything else removing ImageMagick-c++-6.3.8.1-4.fc9.x86_64 b/c it is not required by anything else removing plotutils-2.5-5.fc9.x86_64 b/c it is not required by anything else removing perl-Date-Manip-5.48-3.fc9.noarch b/c it is not required by anything else removing perl-Parse-Yapp-1.05-38.fc9.noarch b/c it is not required by anything else removing perl-XML-DOM-1.44-4.fc9.noarch b/c it is not required by anything else removing perl-XML-RegExp-0.03-4.fc9.noarch b/c it is not required by anything else pstoedit.x86_64 0-3.45-2.fc9 - e perl-XML-XQL.noarch 0-0.68-6.fc9 - e inkscape.x86_64 0-0.46-2.fc9 - e python-lxml.x86_64 0-2.0.7-1.fc9 - e ImageMagick-c++.x86_64 0-6.3.8.1-4.fc9 - e numpy.x86_64 0-1.1.0-1.fc9 - e perl-Date-Manip.noarch 0-5.48-3.fc9 - e perl-Parse-Yapp.noarch 0-1.05-38.fc9 - e plotutils.x86_64 0-2.5-5.fc9 - e perl-XML-RegExp.noarch 0-0.03-4.fc9 - e perl-XML-DOM.noarch 0-1.44-4.fc9 - e libEMF.x86_64 0-1.0.3-7.fc9 - e ImageMagick-perl.x86_64 0-6.3.8.1-4.fc9 - e $ sudo ./remove-recurse.py openoffice.org-core remove openoffice.org-core Loaded plugins: fedorakmod, refresh-packagekit removing bsh-1.3.0-12jpp.3.fc9.x86_64 b/c it is not required by anything else removing 1:hsqldb-1.8.0.9-2jpp.1.fc9.x86_64 b/c it is not required by anything else removing hyphen-en-2.3.1-2.fc9.x86_64 b/c it is not required by anything else removing liberation-fonts-1.04-1.fc9.noarch b/c it is not required by anything else removing hyphen-2.3.1-2.fc9.x86_64 b/c it is not required by anything else removing libtextcat-2.2-5.fc9.x86_64 b/c it is not required by anything else removing bsf-2.3.0-12jpp.2.fc9.x86_64 b/c it is not required by anything else removing tomcat5-jsp-2.0-api-5.5.26-1jpp.2.fc9.x86_64 b/c it is not required by anything else removing xalan-j2-2.7.0-7jpp.2.fc9.x86_64 b/c it is not required by anything else removing tomcat5-servlet-2.4-api-5.5.26-1jpp.2.fc9.x86_64 b/c it is not required by anything else bsf.x86_64 0-2.3.0-12jpp.2.fc9 - e hsqldb.x86_64 1-1.8.0.9-2jpp.1.fc9 - e tomcat5-jsp-2.0-api.x86_64 0-5.5.26-1jpp.2.fc9 - e hyphen-en.x86_64 0-2.3.1-2.fc9 - e openoffice.org-core.x86_64 1-2.4.1-17.4.fc9 - e bsh.x86_64 0-1.3.0-12jpp.3.fc9 - e libtextcat.x86_64 0-2.2-5.fc9 - e xalan-j2.x86_64 0-2.7.0-7jpp.2.fc9 - e openoffice.org-writer2latex.x86_64 0-0.5-2.fc9 - e tomcat5-servlet-2.4-api.x86_64 0-5.5.26-1jpp.2.fc9 - e openoffice.org-writer.x86_64 1-2.4.1-17.4.fc9 - e liberation-fonts.noarch 0-1.04-1.fc9 - e hyphen.x86_64 0-2.3.1-2.fc9 - e openoffice.org-calc.x86_64 1-2.4.1-17.4.fc9 - e $ sudo ./remove-recurse.py azureus remove azureus Loaded plugins: fedorakmod, refresh-packagekit removing bouncycastle-1.38-2.fc9.x86_64 b/c it is not required by anything else removing jakarta-commons-cli-1.0-7jpp_10.fc9.x86_64 b/c it is not required by anything else removing libgconf-java-2.12.4-10.fc9.x86_64 b/c it is not required by anything else removing 1:libswt3-gtk2-3.3.2-12.fc9.x86_64 b/c it is not required by anything else removing log4j-1.2.14-4jpp.1.fc9.x86_64 b/c it is not required by anything else removing libgtk-java-2.8.7-7.fc9.x86_64 b/c it is not required by anything else removing jakarta-commons-lang-2.3-2jpp.1.fc9.x86_64 b/c it is not required by anything else removing jakarta-commons-logging-1.0.4-7jpp.5.fc9.x86_64 b/c it is not required by anything else removing cairo-java-1.0.5-9.fc9.x86_64 b/c it is not required by anything else removing glib-java-0.2.6-12.fc9.x86_64 b/c it is not required by anything else jakarta-commons-logging.x86_64 0-1.0.4-7jpp.5.fc9 - e libgconf-java.x86_64 0-2.12.4-10.fc9 - e jakarta-commons-cli.x86_64 0-1.0-7jpp_10.fc9 - e log4j.x86_64 0-1.2.14-4jpp.1.fc9 - e libswt3-gtk2.x86_64 1-3.3.2-12.fc9 - e azureus.x86_64 0-3.0.4.2-14.fc9 - e cairo-java.x86_64 0-1.0.5-9.fc9 - e libgtk-java.x86_64 0-2.8.7-7.fc9 - e bouncycastle.x86_64 0-1.38-2.fc9 - e glib-java.x86_64 0-0.2.6-12.fc9 - e jakarta-commons-lang.x86_64 0-2.3-2jpp.1.fc9 - e Hey, how hard is it to mod the script to tell you how much space you'd be freeing up... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Thu Sep 4 20:54:52 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 04 Sep 2008 13:54:52 -0700 Subject: Dependency loops considered harmful? In-Reply-To: <1220560572.4415.121.camel@localhost.localdomain> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <48C00D4F.2030004@gmail.com> <1220556463.17785.30.camel@rosebud> <48C03FF3.9040903@gmail.com> <1220560572.4415.121.camel@localhost.localdomain> Message-ID: <48C04B1C.1040507@gmail.com> Callum Lerwick wrote: > On Thu, 2008-09-04 at 13:07 -0700, Toshio Kuratomi wrote: >> [badger at Clingman tmp]$ sudo ./remove-recurse.py yum >> [...] >> removing pygpgme-0.1-8.fc9.i386 b/c it is not required by anything else >> removing python-iniparse-0.2.3-3.fc9.noarch b/c it is not required by >> anything else > > Using yum to remove yum? Talk about grasping for straw men. > > Can we argue realistic scenarios, please? > Pardon, yum was just the first package I looked at since Seth was doing the asking. I can certainly go through and find something else that will cause the same sort of thing to happen but why bother? This is the technical point: If you are using your system to develop or otherwise work on unpackaged software (I hadn't thought about having small scripts in ~/bin earlier, for instance) then you will be caught out by this. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From mw_triad at users.sourceforge.net Thu Sep 4 20:55:53 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 04 Sep 2008 15:55:53 -0500 Subject: Dependency loops considered harmful? In-Reply-To: <1220559207.4415.105.camel@localhost.localdomain> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <1220553370.4415.96.camel@localhost.localdomain> <1220559207.4415.105.camel@localhost.localdomain> Message-ID: Callum Lerwick wrote: > On Thu, 2008-09-04 at 22:05 +0300, Vasile Gaburici wrote: >> The problem with using rpm to install software you develop is that you >> need to do a *full build* every time whenever you change something. >> Even with a caching compiler, that can take a long time. Think Qt for >> instance. > > This is going off on an unproductive tangent. No, I'm not saying use RPM > packaging during your edit-compile-test loop. You do it for longer term > testing and deployment. I don't consider it an unproductive tangent. I would actually *love* to be able to use rpm in the development process, but currently the problems with doing so make it impractical. -- Matthew This message represents the official view of the voices in my head. -- Unknown (found at http://goldmark.org/jeff/stupid-disclaimers/fun.html) From skvidal at fedoraproject.org Thu Sep 4 21:02:13 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 04 Sep 2008 17:02:13 -0400 Subject: Dependency loops considered harmful? In-Reply-To: <48C04B1C.1040507@gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <48C00D4F.2030004@gmail.com> <1220556463.17785.30.camel@rosebud> <48C03FF3.9040903@gmail.com> <1220560572.4415.121.camel@localhost.localdomain> <48C04B1C.1040507@gmail.com> Message-ID: <1220562133.17785.39.camel@rosebud> On Thu, 2008-09-04 at 13:54 -0700, Toshio Kuratomi wrote: > Callum Lerwick wrote: > > On Thu, 2008-09-04 at 13:07 -0700, Toshio Kuratomi wrote: > >> [badger at Clingman tmp]$ sudo ./remove-recurse.py yum > >> [...] > >> removing pygpgme-0.1-8.fc9.i386 b/c it is not required by anything else > >> removing python-iniparse-0.2.3-3.fc9.noarch b/c it is not required by > >> anything else > > > > Using yum to remove yum? Talk about grasping for straw men. > > > > Can we argue realistic scenarios, please? > > > Pardon, yum was just the first package I looked at since Seth was doing > the asking. I can certainly go through and find something else that > will cause the same sort of thing to happen but why bother? This is the > technical point: If you are using your system to develop or otherwise > work on unpackaged software (I hadn't thought about having small scripts > in ~/bin earlier, for instance) then you will be caught out by this. > Here's the same script as a more-proper yum-util script http://skvidal.fedorapeople.org/misc/yum-remove-with-leaves.py try it: yum-remove-with-leaves.py somepkg -sv From skvidal at fedoraproject.org Thu Sep 4 21:02:57 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 04 Sep 2008 17:02:57 -0400 Subject: Dependency loops considered harmful? In-Reply-To: <1220560572.4415.121.camel@localhost.localdomain> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <48C00D4F.2030004@gmail.com> <1220556463.17785.30.camel@rosebud> <48C03FF3.9040903@gmail.com> <1220560572.4415.121.camel@localhost.localdomain> Message-ID: <1220562177.17785.41.camel@rosebud> On Thu, 2008-09-04 at 15:36 -0500, Callum Lerwick wrote: > Using yum to remove yum? Talk about grasping for straw men. I don't think it's a straw man. It is a fairly obvious case where it'll remove something. I did my test by installing then using the command on eclipse. :) -sv From a.badger at gmail.com Thu Sep 4 21:42:50 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 04 Sep 2008 14:42:50 -0700 Subject: Dependency loops considered harmful? In-Reply-To: <1220560349.17785.37.camel@rosebud> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <48C00D4F.2030004@gmail.com> <1220556463.17785.30.camel@rosebud> <48C03FF3.9040903@gmail.com> <1220560349.17785.37.camel@rosebud> Message-ID: <48C0565A.5090906@gmail.com> Seth Vidal wrote: > On Thu, 2008-09-04 at 13:07 -0700, Toshio Kuratomi wrote: >> Seth Vidal wrote: >>> Okay this is obviously just Proof code so take it as read - but grab >>> this script: >>> >>> http://skvidal.fedorapeople.org/misc/remove-recurse.py >>> >>> and run it with one arg being the pkg you wish to remove. It will print >>> out what it would end up doing if it was removed. >>> >>> for example: >>> >>> # python remove-recurse.py easytag >>> remove easytag >>> removing id3lib-3.8.3-20.fc9.i386 b/c it is not required by anything >>> else >>> removing libmp4v2-1.5.0.1-6.fc9.i386 b/c it is not required by anything >>> else >>> libmp4v2.i386 0-1.5.0.1-6.fc9 - e >>> id3lib.i386 0-3.8.3-20.fc9 - e >>> easytag.i386 0-2.1-5.fc9 - e >>> >>> >>> >>> It doesn't actually change anything, just prints out what would happen. >>> then tell me which (and I'm sure there are many) cases it doesn't >>> properly address. >>> -sv >>> >>> >> [badger at Clingman tmp]$ sudo ./remove-recurse.py yum >> [...] >> removing pygpgme-0.1-8.fc9.i386 b/c it is not required by anything else >> removing python-iniparse-0.2.3-3.fc9.noarch b/c it is not required by >> anything else >> >> As it turns out, I personally need both of these deps. I have a script >> in ~/bin/ that uses pygpgme. I also am working on fas in a local >> checkout which requires pygpgme. And I'm evaluating python-iniparse and >> python-configobj to see which one I'm going to be using for some fedora >> infrastructure scripts. >> >> So -- I like having a script that can remove things recursively. Even >> better if I could do: >> sudo remove-recurse.py yum --exclude pygpgme >> >> I just wouldn't want this kind of thing to be automatic or to be the >> default when I do "yum remove" >> > > I mostly agree. I sorta think that _maybe_ your case is becoming more of > the edge case and a lot more folks want to remove all the things that > just got dragged in when they ran: yum install this_really_cool_thing > > So, if there were an option to let you disable leaf removal would that > work out? > Depends. I'd much rather have:: yum remove (-r|-R|--recursive) this_really_cool_thing than:: yum remove --no-recursive this_really_cool_thing But maybe that's just the positive me. If it goes in /etc/yum.conf then either one could be the default. A setting in a config file can be scripted in a kickstart, deployed by puppet, or set by an individual user once and then forgotten. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From a.badger at gmail.com Thu Sep 4 21:35:04 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 04 Sep 2008 14:35:04 -0700 Subject: Dependency loops considered harmful? In-Reply-To: <1220553370.4415.96.camel@localhost.localdomain> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <1220553370.4415.96.camel@localhost.localdomain> Message-ID: <48C05488.5060507@gmail.com> Callum Lerwick wrote: > On Thu, 2008-09-04 at 02:43 -0700, Toshio Kuratomi wrote: >>>> your app suddenly can't find libFoo.... >>>> (Worse is if your working on an app sporadically and have to figure out >>>> why it's broken not knowing when it became that way.) > > Is knowing how to use "yum whatprovides" really too much to ask? A > developer who was hit by this would merely need to run "yum whatprovides > libFoo.so", then install the necessary package with "yum install > libfoo". Since they asked for it by name, it would not be flagged as a > dep, and thus be immune from future package culling. > > And furthermore, a developer using libFoo would have to have > libfoo-devel installed. Most likely libfoo-devel is a leaf itself, thus > is there because the developer specifically installed it, making it > immune from culling. Since -devel packages must depend on the main > package, libfoo would remain pinned in the system as long as > libfoo-devel is installed. libfoo would never disappear unless the > user/developer started deliberately removing -devel packages. If they do > such a thing without understanding the potential consequences to their > un-packaged applications, they deserve what they get. And that is a > problem that has little to do with the proposed auto-culling system. > Both of these answered in other messages: yum install PACKAGE specifically to prevent this is badUI: https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00245.html Why -devel is not enough:: https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00235.html >> If I'm developing an app, I'm going to be working on code, not taking >> time out to package the app as an rpm. Only after I'm ready to take the >> app and put it somewhere for other people to download and use am I going >> to start worrying about packaging. > > Then you accept the consequences of such a development methodology. > Uhm... you realize that building an rpm every time you want to test a change as you develop an app is incredibly clunky? It really is not going to happen. Really. >>>> So if we track this some way, there needs to be a way to disable it. >>> A developer presumably doesn't use the hypothetical simplified >>> application installer. They use something more advanced. Like aptitude. >>> >> Err.... You've totally lost me here. If we implement this, it needs to >> be at a low enough level that anyone installing packages on the system >> will be storing the information. > > This would be ideal, but not strictly necessary. If some tool doesn't > know or care about the flag, it should default to "off", meaning "not > pulled in as a dep", which would maximally prevent surprises. > > This is how aptitude works, it stores the "is a dep" flags in its own > configuration. Any packages installed outside of aptitude are assumed to > be explicitly installed. > > Yes, the flag should be stored in the RPM database itself, but it is not > strictly necessary to implement a proof-of-concept, at say the yum > level. Pretty much all our "official" tools are going through yum these > days anyway... > This would work. >> That could mean rpm (since rpm is >> responsible for taking the package and turning it into files on the >> filesystem) or that could mean yum since yum is the one that actually >> knows whether a package is being installed due to depsolving or user >> request. Doing this at a higher level means that information gets lost >> (for instance, if you do this in PackageKit, there won't be any >> information about what anaconda chose to install due to chckboxes being >> clicked and which things were installed due to dependencies). > > All the RPM database needs to do is store a single lousy bit of > information per package. The "is a dep" flag. Presumably installing > packages directly with rpm would not set this flag. s/not// to match the behaviour you say aptitude has. > Perhaps rpm could > provide a command to toggle the flag. RPM itself would not care what the > flag means. Giving it meaning happens at the dep solver level. (Aptitude > has its own dep solver, which allows it to do the on-the-fly interactive > dep-solving that makes it so awesome) > >> With that said, there needs to be a way for a developer to tell yum not >> to prune away leaf packages if they want. > > An advanced front end, such as aptitude, allows you to manually toggle > the "is a dep" flag with a single keystroke. And instantly shows you the > effect of doing so. And makes you look at a detailed summary of every > transaction before it is performed, giving you ample opportunity to > reconsider what you're doing. > So -- I don't have anything against there being this interface. I just want to see a simple config change that can turn dep removal (not tracking, just removal) off. Developers can be good at coding and awful at system administration just like any other end-user. We shouldn't make them understand package deps and why different packages they need disappear out from under them when they remove an application package any more than we should go back to the time before depsolvers and make office workers understand package deps and why they need to install different packages in order to get openoffice to run. Why do I think a simple config change is the way to go? Because of the miscommunication factor: dev: Why'd Fedora uninstall python-foo when I removed gnome-foo? python-foo works fine without gnome-foo! fedora-sa: That's a new feature of F-10. dev: But I totally needed python-foo for the Uber-Duber-Mega-Foo we're building! fedora-sa: You can work around it by doing a yum install python-foo dev: And yum won't remove it again? fedora-sa: Right [days pass] dev: Fuck! Fedora uninstalled python-bar when I removed gnome-bar! fedora-sa: Did you yum install python-bar? dev: I thought you said yum wouldn't do this anymore! fedora-sa: I did? fedora-sa: Wait, I think that was for another package. dev: What's the difference? I just don't want yum to keep thinking it's smarter than me! fedora-sa: Well, you just have to yum install all the deps that your program has. dev: wtf You're kidding. fedora-sa: no. You should have all the deps, though. I mean, what are you going to tell people when the install it? [weeks pass] dev: yum did it again fedora-sa: What? dev: I just spent three hours figuring out why Uber-Duber-Mega-Foo started throwing exceptions when we try to save files on some of our Fedora boxes. dev: It turns out that code had a dependency on a module that yum automatically removed. fedora-sa: I thought I told you to install all those modules explicitly. dev: That's what I did. dev: But this dep was added by Greg after that. dev: It seems like this problem just refuses to go away. [dev and fedora-sa assume a passive aggressive stance towards each other, continuing to think the other is an idiot.] Now, here's the alternative: dev: Why'd Fedora uninstall python-foo when I removed gnome-foo? python-foo works fine without gnome-foo! fedora-sa: That's a new feature of F-10. dev: But I totally needed python-foo for the Uber-Duber-Mega-Foo we're building! fedora-sa: If you edit /etc/yum.conf fedora-sa: and add the line recursive-remove=no fedora-sa: that will turn off the feature dev: Cool. fedora-sa: And you'll have to yum install python-foo to get this particular library back, of course. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jspaleta at gmail.com Thu Sep 4 21:52:01 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 4 Sep 2008 13:52:01 -0800 Subject: Dependency loops considered harmful? In-Reply-To: <48C0565A.5090906@gmail.com> References: <20080903165835.GA31342@localhost> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <48C00D4F.2030004@gmail.com> <1220556463.17785.30.camel@rosebud> <48C03FF3.9040903@gmail.com> <1220560349.17785.37.camel@rosebud> <48C0565A.5090906@gmail.com> Message-ID: <604aa7910809041452v55d53532l7256b7cbd96c264@mail.gmail.com> 2008/9/4 Toshio Kuratomi : > If it goes in /etc/yum.conf then either one could be the default. A > setting in a config file can be scripted in a kickstart, deployed by > puppet, or set by an individual user once and then forgotten. As long as the 'normals' get access to it via packagekit. I expect the vast majority of people who care about your usage case will prefer using yum on the cmdline over packagekit. You might be able to argue that yum on the commandline should not default to leaf pruning on removal, but you would be hard pressed I think to make the same argument about packagekit's default setting. -jef From mw_triad at users.sourceforge.net Thu Sep 4 22:05:01 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 04 Sep 2008 17:05:01 -0500 Subject: Dependency loops considered harmful? In-Reply-To: <48C05488.5060507@gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <1220553370.4415.96.camel@localhost.localdomain> <48C05488.5060507@gmail.com> Message-ID: Toshio Kuratomi wrote: > Uhm... you realize that building an rpm every time you want to test a > change as you develop an app is incredibly clunky? It really is not > going to happen. Really. I still submit that this itself is a problem that should be worked on... Why must it be "too clunky"? Why can't we fix it so that expecting developers to install via rpm, even for incremental builds, is perfectly reasonable? Of course this process probably won't involve going through a full rpmbuild, just something that tracks the installed files in rpm's database along with updating the database for dependencies (i.e. it would replace 'make install' but not 'make all'). >>> That could mean rpm (since rpm is >>> responsible for taking the package and turning it into files on the >>> filesystem) or that could mean yum since yum is the one that actually >>> knows whether a package is being installed due to depsolving or user >>> request. Doing this at a higher level means that information gets lost >>> (for instance, if you do this in PackageKit, there won't be any >>> information about what anaconda chose to install due to chckboxes being >>> clicked and which things were installed due to dependencies). >> All the RPM database needs to do is store a single lousy bit of >> information per package. The "is a dep" flag. Presumably installing >> packages directly with rpm would not set this flag. > > s/not// to match the behaviour you say aptitude has. Eh? I would think that 'rpm -Uvh ' should result in being flagged as a non-candidate-for-culling (unless rpm is told otherwise). IOW, if I hand-installed some rpm, I don't want it auto-culled. Maybe there is some miscommunication? -- Matthew This message represents the official view of the voices in my head. -- Unknown (found at http://goldmark.org/jeff/stupid-disclaimers/fun.html) From vgaburici at gmail.com Thu Sep 4 22:08:48 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Fri, 5 Sep 2008 01:08:48 +0300 Subject: Dependency loops considered harmful? In-Reply-To: References: <20080903165835.GA31342@localhost> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <1220553370.4415.96.camel@localhost.localdomain> <48C05488.5060507@gmail.com> Message-ID: On Fri, Sep 5, 2008 at 1:05 AM, Matthew Woehlke wrote: > Toshio Kuratomi wrote: >> >> Uhm... you realize that building an rpm every time you want to test a >> change as you develop an app is incredibly clunky? It really is not >> going to happen. Really. > > I still submit that this itself is a problem that should be worked on... Why > must it be "too clunky"? Why can't we fix it so that expecting developers to > install via rpm, even for incremental builds, is perfectly reasonable? Of > course this process probably won't involve going through a full rpmbuild, > just something that tracks the installed files in rpm's database along with > updating the database for dependencies (i.e. it would replace 'make install' > but not 'make all'). This would be nice, but it is at odds with the idea of building from pristine (archived) sources. From jkeating at redhat.com Thu Sep 4 22:12:19 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 04 Sep 2008 15:12:19 -0700 Subject: Fedora release time? In-Reply-To: <1220543093.7673.2.camel@localhost.localdomain> References: <1220543093.7673.2.camel@localhost.localdomain> Message-ID: <1220566339.3575.4.camel@luminos.localdomain> On Thu, 2008-09-04 at 11:44 -0400, Paul W. Frields wrote: > Historically, the release time on a given release date has been 10:00am > Eastern time.[1] However, Jesse Keating, who's one of our release > engineers, is now on Pacific time, which makes this 7:00am by his clock. > Are we going to stay with 10:00am Eastern (1400 or 1500 UTC), or should > we consider a change? Staggering into the (home) office an hour earlier then I normally get up on release days isn't that big of a deal. I'd say we keep things as they are as it seems to work well with EU press (thanks for that info Thorsten!). But thanks for thinking of my sanity (: -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Thu Sep 4 22:13:04 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 04 Sep 2008 15:13:04 -0700 Subject: Fedora release time? In-Reply-To: <16de708d0809040901xe1d86e6re22ba4bba9ea4dc@mail.gmail.com> References: <1220543093.7673.2.camel@localhost.localdomain> <1220543758.17785.14.camel@rosebud> <16de708d0809040901xe1d86e6re22ba4bba9ea4dc@mail.gmail.com> Message-ID: <1220566384.3575.5.camel@luminos.localdomain> On Thu, 2008-09-04 at 11:01 -0500, Arthur Pemberton wrote: > Will it help if we send him a six pack? Seems like a fair trade for a > release. Depends on what it's a six pack of. Beer? Ok, Root Beer, better. Couches? not so much. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From vgaburici at gmail.com Thu Sep 4 22:13:27 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Fri, 5 Sep 2008 01:13:27 +0300 Subject: Dependency loops considered harmful? In-Reply-To: References: <20080903165835.GA31342@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <1220553370.4415.96.camel@localhost.localdomain> <48C05488.5060507@gmail.com> Message-ID: On Fri, Sep 5, 2008 at 1:08 AM, Vasile Gaburici wrote: > On Fri, Sep 5, 2008 at 1:05 AM, Matthew Woehlke > wrote: >> Toshio Kuratomi wrote: >>> >>> Uhm... you realize that building an rpm every time you want to test a >>> change as you develop an app is incredibly clunky? It really is not >>> going to happen. Really. >> >> I still submit that this itself is a problem that should be worked on... Why >> must it be "too clunky"? Why can't we fix it so that expecting developers to >> install via rpm, even for incremental builds, is perfectly reasonable? Of >> course this process probably won't involve going through a full rpmbuild, >> just something that tracks the installed files in rpm's database along with >> updating the database for dependencies (i.e. it would replace 'make install' >> but not 'make all'). > > This would be nice, but it is at odds with the idea of building from > pristine (archived) sources. More to the point: -ba --short-circuit is not allowed on purpose. From mw_triad at users.sourceforge.net Thu Sep 4 22:23:45 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 04 Sep 2008 17:23:45 -0500 Subject: Using rpm for incremental development builds? (was: Dependency loops considered harmful?) In-Reply-To: References: <20080903165835.GA31342@localhost> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <1220553370.4415.96.camel@localhost.localdomain> <48C05488.5060507@gmail.com> Message-ID: Vasile Gaburici wrote: > On Fri, Sep 5, 2008 at 1:05 AM, Matthew Woehlke > wrote: >> Toshio Kuratomi wrote: >>> Uhm... you realize that building an rpm every time you want to test a >>> change as you develop an app is incredibly clunky? It really is not >>> going to happen. Really. >> I still submit that this itself is a problem that should be worked on... Why >> must it be "too clunky"? Why can't we fix it so that expecting developers to >> install via rpm, even for incremental builds, is perfectly reasonable? Of >> course this process probably won't involve going through a full rpmbuild, >> just something that tracks the installed files in rpm's database along with >> updating the database for dependencies (i.e. it would replace 'make install' >> but not 'make all'). > > This would be nice, but it is at odds with the idea of building from > pristine (archived) sources. Hmm, true, but we're talking about something to make developers' jobs easier. And, like I mentioned, I'm thinking mainly along the lines of using rpm to track files from home-built software as well as dependency tracking. Also, it would be *really* nice to be able to build qt-copy and have it update rpm's database to "know" that I have qt4 already :-). I know, I can forge the db entries, but then if I ever try to back out qt-copy I'm in a bit of a pickle (because I have to remember to back our the rpm-db changes also). If I could install with rpm, backing out qt-copy would be as easy as 'rpm -e qt4-4.4.2-copy', which would undo the install, pester me about any packages that need qt4^1, and clean up the db in one shot. ...and I wouldn't have to occasionally 'rm -rf $KDEDIR' because rpm would be handling removal of stale files for me. (^1 ...which suggests another feature; if removing an orphaned package, i.e. something not in yum's repos^2, yum could ask me if I want to install a repo package to satisfy dependencies rather than remove dependent packages.) (^2 ...which I guess would mean using yum instead of rpm, but that should be ok.) -- Matthew This message represents the official view of the voices in my head. -- Unknown (found at http://goldmark.org/jeff/stupid-disclaimers/fun.html) From tcallawa at redhat.com Thu Sep 4 22:31:16 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Thu, 04 Sep 2008 18:31:16 -0400 Subject: A couple of license-relate questions In-Reply-To: References: Message-ID: <1220567476.7704.8.camel@localhost.localdomain> On Thu, 2008-09-04 at 22:11 +0300, Vasile Gaburici wrote: > 1) If some files of a program are BSD and some are GPLv2, is it > necessary to include the BSD license file in the rpm package (even if > upstream doesn't)? We don't require that you add any missing license files in these scenarios. You might want to recommend that upstream include a copy of the license, but as long as the license appears in the source code, this is not required (for BSD). The rule is: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package, must be included as documentation. See: http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#License_Text > 2) Can someone take a look at the Adobe Glyph List license > [http://www.adobe.com/devnet/opentype/archives/glyphlist.txt] and > determine what is the appropriate rpm license field for it? Need to run that one past the lawyers... it is worded strangely. ~spot From a.badger at gmail.com Thu Sep 4 22:32:38 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 04 Sep 2008 15:32:38 -0700 Subject: Dependency loops considered harmful? In-Reply-To: References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <1220553370.4415.96.camel@localhost.localdomain> <48C05488.5060507@gmail.com> Message-ID: <48C06206.9040702@gmail.com> Matthew Woehlke wrote: > Toshio Kuratomi wrote: >> Uhm... you realize that building an rpm every time you want to test a >> change as you develop an app is incredibly clunky? It really is not >> going to happen. Really. > > I still submit that this itself is a problem that should be worked on... > Why must it be "too clunky"? Why can't we fix it so that expecting > developers to install via rpm, even for incremental builds, is perfectly > reasonable? Here's the workflow: cvs co web-app cd web-app vim web-app.cfg ./start-web-app [hit web app in browser to make sure it runs] ^C vim web-app/do-something.py vim web-app/templates/do-something-page.html ./start-web-app [hit web-app in browser and find there's a problem] ^C vim TODO [write note to fix this as you've got to get some sleep, go to work, walk the dog, make dinner, kiss your wife, yum update, yum erase openoffice, yum install nethack, play nethack, go to sleep, get up and....] cat TODO vim web-app/do-something.py ./start-web-app [hit web-app in browser and find there's a problem] [wash rinse repeat] Now here's the same workflow with rpm building in there:: cvs co web-app cd web-app vim web-app.cfg python setup.py sdist mv dist/web-app-0.0.tar.gz .. cd .. rpmbuild -ba web-app.spec sudo rpm -Uvh web-app-0.0-0.noarch.rpm sudo /etc/init.d/web-app start [hit web app in browser to make sure it runs] cd web-app vim web-app/do-something.py vim web-app/templates/do-something-page.html python setup.py sdist mv dist/web-app-0.0.tar.gz .. cd .. vim web-app.spec rpmbuild -ba web-app.spec sudo rpm -e web-app sudo rpm -Uvh web-app-0.0-1.noarch.rpm sudo /etc/init.d/web-app start [hit web-app in browser and find there's a problem] ^C vim TODO [write note to fix this as you've got to get some sleep, go to work, walk the dog, make dinner, kiss your wife, yum update, yum erase openoffice, yum install nethack, play nethack, go to sleep, get up and....] cat TODO cd web-app vim web-app/do-something.py python setup.py sdist mv dist/web-app-0.0.tar.gz .. cd .. vim web-app.spec rpmbuild -ba web-app.spec sudo rpm -e web-app sudo rpm -Uvh web-app-0.0-1.noarch.rpm sudo /etc/init.d/web-app start [hit web-app in browser and find there's a problem] [wash rinse repeat] > Of course this process probably won't involve going through > a full rpmbuild, just something that tracks the installed files in rpm's > database along with updating the database for dependencies (i.e. it > would replace 'make install' but not 'make all'). > This is definitely not what rpm is designed to do. You could probably write a script that did it but you'd have to hook it up to all the dependency generating scripts and do minimal parsing of the spec file to get manually specified deps and you'd still have to work out how to do the make install step cleanly.... I don't see much return on investment here but YMMV. >>>> That could mean rpm (since rpm is >>>> responsible for taking the package and turning it into files on the >>>> filesystem) or that could mean yum since yum is the one that actually >>>> knows whether a package is being installed due to depsolving or user >>>> request. Doing this at a higher level means that information gets lost >>>> (for instance, if you do this in PackageKit, there won't be any >>>> information about what anaconda chose to install due to chckboxes being >>>> clicked and which things were installed due to dependencies). >>> All the RPM database needs to do is store a single lousy bit of >>> information per package. The "is a dep" flag. Presumably installing >>> packages directly with rpm would not set this flag. >> >> s/not// to match the behaviour you say aptitude has. > > Eh? I would think that 'rpm -Uvh ' should result in > being flagged as a non-candidate-for-culling (unless rpm > is told otherwise). IOW, if I hand-installed some rpm, I don't want it > auto-culled. Maybe there is some miscommunication? > Possibly. I interpret the "is a dep flag" to mean package Foo was installed as a dep of package Bar. Therefore, when package Foo is uninstalled, packages that depend on Bar and have "is a dep" set would be uninstalled. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From adi1981.2k5 at gmail.com Thu Sep 4 22:52:49 2008 From: adi1981.2k5 at gmail.com (Adrian Pilchowiec) Date: Fri, 5 Sep 2008 00:52:49 +0200 Subject: Fedora Security Tools spin In-Reply-To: <20080903210044.GF3726@x300> References: <48BE023A.70703@redhat.com> <48BE1F95.2090509@redhat.com> <20080903210044.GF3726@x300> Message-ID: <200809050052.49444.Adi1981.2k5@gmail.com> On Wednesday 03 of September 2008 23:00:44 Luke Macken wrote: > On Wed, Sep 03, 2008 at 10:54:37AM +0530, Huzaifa Sidhpurwala wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Todd Zullinger wrote: > > > Huzaifa Sidhpurwala wrote: > > >> I just came across a knoppix security tool live CD and thought it > > >> would be a good idea for a security tool fedora spin too. > > >> The tools are freely available at: > > >> > > >> http://knoppix-std.org/index.html > > >> and are all GPLed? > > >> > > >> Do you guys think this is a good idea, I am sure such a spin does > > >> not exists in Fedora yet. > > > > > > Do you mean something like Luke Macken put together? > > > > > > http://fedoraproject.org/wiki/LukeMacken/SecurityLiveCD > > > > Yeah but more tools and more bare bones, > > Perhaps i can assist Luke in this? > > Absolutely! > > I'm in the process of rebasing the kickstart against the latest livecd > base, and I will be pushing it through the New Spin Process soon. > > More tools? Yes. I want it to ship with every security tool in Fedora. > If you know of any that are missing from the list, please let me know. > Maybe it would be good to add OpenVAS [1] (free fork of nessus) to the spin ? [1] http://www.openvas.org/ From choeger at cs.tu-berlin.de Thu Sep 4 22:56:38 2008 From: choeger at cs.tu-berlin.de (=?ISO-8859-15?Q?Christoph_H=F6ger?=) Date: Fri, 05 Sep 2008 00:56:38 +0200 Subject: OT: This is for java geeks out there Message-ID: <48C067A6.3050506@cs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I do not know where to ask that, so I try it here: I want to load a (dynamically created) class via URL ClassLoader and then invoke a public static method on it. Here is the code: Class lexerDefs = Class.forName("parser.LexerDefs", true, loader); Method getLexerDefs = null; try { getLexerDefs = lexerDefs.getMethod("lexerDefs", new Class[] {}); } catch (NoSuchMethodException e) { fail("Class " + lexerDefs.getName() + " has no method lexerDefs()\n" + e.getMessage()); } parser.Options.inputFile = this.inputFile; System.err.println("invoking: " + getLexerDefs.toString()); Object retObject = getLexerDefs.invoke(null, new Object[0]); But all I get is: Class test.TestParserGenerator can not access a member of class parser.LexerDefs with modifiers "public static" So loading class seems to work, but I cannot invoke a _public_ method? Why? Anyone knows about reflection? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFIwGemhMBO4cVSGS8RAmZFAJ9NtL1izKhmj40HHM/Xv1MgB7l1GACeJqOa eTf9ku27xa1wBUAOyNQfxkg= =MOSM -----END PGP SIGNATURE----- From konrad at tylerc.org Thu Sep 4 23:11:52 2008 From: konrad at tylerc.org (Conrad Meyer) Date: Thu, 4 Sep 2008 16:11:52 -0700 Subject: A couple of license-relate questions In-Reply-To: <1220567476.7704.8.camel@localhost.localdomain> References: <1220567476.7704.8.camel@localhost.localdomain> Message-ID: <200809041611.55232.konrad@tylerc.org> Quoth Tom "spot" Callaway: > On Thu, 2008-09-04 at 22:11 +0300, Vasile Gaburici wrote: > > 2) Can someone take a look at the Adobe Glyph List license > > [http://www.adobe.com/devnet/opentype/archives/glyphlist.txt] and > > determine what is the appropriate rpm license field for it? > > Need to run that one past the lawyers... it is worded strangely. > > ~spot I thought you were the lawyers, spot! -- Conrad Meyer -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From mw_triad at users.sourceforge.net Thu Sep 4 23:25:58 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 04 Sep 2008 18:25:58 -0500 Subject: Dependency loops considered harmful? In-Reply-To: <48C06206.9040702@gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <1220553370.4415.96.camel@localhost.localdomain> <48C05488.5060507@gmail.com> <48C06206.9040702@gmail.com> Message-ID: Toshio Kuratomi wrote: > Matthew Woehlke wrote: >> Toshio Kuratomi wrote: >>> Uhm... you realize that building an rpm every time you want to test a >>> change as you develop an app is incredibly clunky? It really is not >>> going to happen. Really. >> I still submit that this itself is a problem that should be worked on... >> Why must it be "too clunky"? Why can't we fix it so that expecting >> developers to install via rpm, even for incremental builds, is perfectly >> reasonable? > > Here's the workflow: > [snip] Thanks, but I didn't need an analysis of the current problems. I know it's not practical right now, but that was the whole point I was trying to make! Here's what I'd like to see: Current workflow: svn up make make install some-app Proposed workflow: svn up make rpm-dev-install . some-app See how painless that was? And now, rather than 'make install' littering my drive with untracked files, the helper: - rolled an incremental RPM - updated the existing package - ...which removed any old files no longer there - ...and added/updated any modified files - updated the rpm database to note that some-app is now installed (if it wasn't) - ...which also means that if some-app uses libfoo-devel, rpm now knows this and won't remove libfoo-devel until I remove some-app >> Of course this process probably won't involve going through >> a full rpmbuild, just something that tracks the installed files in rpm's >> database along with updating the database for dependencies (i.e. it >> would replace 'make install' but not 'make all'). > > This is definitely not what rpm is designed to do. > > You could probably write a script that did it but you'd have to hook it > up to all the dependency generating scripts and do minimal parsing of > the spec file to get manually specified deps and you'd still have to > work out how to do the make install step cleanly.... I don't see much > return on investment here but YMMV. Yes, you'd probably need to write a spec file, and you might need to fiddle with the 'make' step as well to make it more rpmbuild-like. Of course, something like this could also be integrated with popular build systems (I'd mainly care about cmake). For that matter, rpmbuild might just work as-is if allowed to start with "dirty" source and build trees; you'd have to set things up carefully, but then it would be just a matter of having the source in a particular spot (which could be symlinked to get around any inconveniences there) and running rpmbuild instead of make. Then the trick is just making it work as not-root. What I *don't* get it what's so special about rpm generation that people seem to think this can't be done. Would it produce an rpm that is suitable according to Fedora's packaging guidelines? Of course not! But that's not the objective. Yes, there are reasons current rpmbuild works the way it does, and I don't think we should change that. I'm just after a way to allow "non-canon" rpm's rolled from incremental builds. Further, they should NOT be root-owned, they should be installable without needing to be root*, and they should stick out like sore thumbs if there is a conflict with repo packages (assuming they aren't installed "in addition", i.e. in /usr/local). (* There should be a way for root to flag a particular such package as being allowed to satisfy dependencies for other packages, that would be persistent across updates of the package. IOW, I can install qt-copy, become root and tell rpm to use qt-copy to satisfy dependencies, and then poppler-qt4 without having to install the repo qt4. Now, obviously, trying to remove qt-copy will refuse due to poppler-qt4 needing it until I use the magic incantation (e.g. '--force --nodeps' or something along those lines, which would of course break poppler-qt4, but I was warned ;-) )... unless I do it as root, which would just remove poppler-qt4.) >>>> All the RPM database needs to do is store a single lousy bit of >>>> information per package. The "is a dep" flag. Presumably installing >>>> packages directly with rpm would not set this flag. >>> s/not// to match the behaviour you say aptitude has. >> Eh? I would think that 'rpm -Uvh ' should result in >> being flagged as a non-candidate-for-culling (unless rpm >> is told otherwise). IOW, if I hand-installed some rpm, I don't want it >> auto-culled. Maybe there is some miscommunication? >> > Possibly. I interpret the "is a dep flag" to mean package Foo was > installed as a dep of package Bar. Therefore, when package Foo is > uninstalled, packages that depend on Bar and have "is a dep" set would > be uninstalled. Right, if those "is a dep" packages aren't needed by anything else (just to clarify; I'm sure that's what you meant). What I don't get: Callum said that "rpm -i blah.rpm" would mark "blah" as a non-dep, i.e. would not be auto-culled. As I understand, you said that it *would* mark it for auto-culling. It seems to me that the former behavior is preferable; anything I install by hand should be non-auto-culled unless I say otherwise, not the other way around. -- Matthew This message represents the official view of the voices in my head. -- Unknown (found at http://goldmark.org/jeff/stupid-disclaimers/fun.html) From skvidal at fedoraproject.org Thu Sep 4 23:35:47 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 04 Sep 2008 19:35:47 -0400 Subject: Dependency loops considered harmful? In-Reply-To: <48C0565A.5090906@gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <48C00D4F.2030004@gmail.com> <1220556463.17785.30.camel@rosebud> <48C03FF3.9040903@gmail.com> <1220560349.17785.37.camel@rosebud> <48C0565A.5090906@gmail.com> Message-ID: <1220571347.17785.44.camel@rosebud> On Thu, 2008-09-04 at 14:42 -0700, Toshio Kuratomi wrote: > Seth Vidal wrote: > > On Thu, 2008-09-04 at 13:07 -0700, Toshio Kuratomi wrote: > >> Seth Vidal wrote: > >>> Okay this is obviously just Proof code so take it as read - but grab > >>> this script: > >>> > >>> http://skvidal.fedorapeople.org/misc/remove-recurse.py > >>> > >>> and run it with one arg being the pkg you wish to remove. It will print > >>> out what it would end up doing if it was removed. > >>> > >>> for example: > >>> > >>> # python remove-recurse.py easytag > >>> remove easytag > >>> removing id3lib-3.8.3-20.fc9.i386 b/c it is not required by anything > >>> else > >>> removing libmp4v2-1.5.0.1-6.fc9.i386 b/c it is not required by anything > >>> else > >>> libmp4v2.i386 0-1.5.0.1-6.fc9 - e > >>> id3lib.i386 0-3.8.3-20.fc9 - e > >>> easytag.i386 0-2.1-5.fc9 - e > >>> > >>> > >>> > >>> It doesn't actually change anything, just prints out what would happen. > >>> then tell me which (and I'm sure there are many) cases it doesn't > >>> properly address. > >>> -sv > >>> > >>> > >> [badger at Clingman tmp]$ sudo ./remove-recurse.py yum > >> [...] > >> removing pygpgme-0.1-8.fc9.i386 b/c it is not required by anything else > >> removing python-iniparse-0.2.3-3.fc9.noarch b/c it is not required by > >> anything else > >> > >> As it turns out, I personally need both of these deps. I have a script > >> in ~/bin/ that uses pygpgme. I also am working on fas in a local > >> checkout which requires pygpgme. And I'm evaluating python-iniparse and > >> python-configobj to see which one I'm going to be using for some fedora > >> infrastructure scripts. > >> > >> So -- I like having a script that can remove things recursively. Even > >> better if I could do: > >> sudo remove-recurse.py yum --exclude pygpgme > >> > >> I just wouldn't want this kind of thing to be automatic or to be the > >> default when I do "yum remove" > >> > > > > I mostly agree. I sorta think that _maybe_ your case is becoming more of > > the edge case and a lot more folks want to remove all the things that > > just got dragged in when they ran: yum install this_really_cool_thing > > > > So, if there were an option to let you disable leaf removal would that > > work out? > > > Depends. I'd much rather have:: > yum remove (-r|-R|--recursive) this_really_cool_thing > > than:: > yum remove --no-recursive this_really_cool_thing > > But maybe that's just the positive me. > > If it goes in /etc/yum.conf then either one could be the default. A > setting in a config file can be scripted in a kickstart, deployed by > puppet, or set by an individual user once and then forgotten. > nod. The other option, given the code I just put in a separate script, is to make it a plugin to handle the above. It wouldn't be hard to do and then if you wanted leaf dep removal you could install/enable the plugin. -sv From dennisml at conversis.de Thu Sep 4 23:44:52 2008 From: dennisml at conversis.de (Dennis J.) Date: Fri, 05 Sep 2008 01:44:52 +0200 Subject: rawhide breakage Message-ID: <48C072F4.2010003@conversis.de> I just did an update to the latest rawhide an now my terminal keyboard is screwed up. I'm using an en_US.UTF-8 locale with a de-latin1-nodeadkeys keytable. One umlaut works while others show characters that aren't part of either the english or german regular layout. Also after logging into gdm it seem gnome has lost my settings. Here I get a regular us keyboard layout but other information like my theme and gnome-terminal configuration also is gone it seems. Right now I'm trying to get the keyboard in runlevel 3 to work correctly again and then work my way up to X11/gnome but I'm not sure what packages could be responsible for the regular terminal problem. I already reverted the following packages to their previous versions from koji: Sep 04 21:24:09 Updated: hal-libs-0.5.11-4.fc10.i386 Sep 04 21:24:10 Updated: libvolume_id-127-1.fc10.i386 Sep 04 21:24:14 Updated: udev-127-1.fc10.i386 Sep 04 21:24:17 Updated: hal-0.5.11-4.fc10.i386 Sep 04 21:24:18 Updated: hal-devel-0.5.11-4.fc10.i386 These are the other packages I updated before the breakage occured: Sep 04 21:18:22 Updated: rpm-libs-4.5.90-0.git8461.4.i386 Sep 04 21:18:26 Updated: rpm-4.5.90-0.git8461.4.i386 Sep 04 21:18:27 Updated: rpm-build-4.5.90-0.git8461.4.i386 Sep 04 21:18:28 Updated: rpm-devel-4.5.90-0.git8461.4.i386 Sep 04 21:18:28 Updated: rpm-python-4.5.90-0.git8461.4.i386 Sep 04 21:18:32 Updated: rpm-4.5.90-0.git8461.4.i386 Sep 04 21:21:00 Updated: yum-3.2.19-3.fc10.noarch Sep 04 21:27:49 Updated: python-protocols-1.0-0.8.a0dev_r2302.fc10.i386 Sep 04 21:27:50 Updated: python-sexy-0.1.9-6.fc10.i386 Sep 04 21:27:51 Updated: python-json-3.4-4.fc10.noarch Sep 04 21:27:53 Updated: python-qpid-0.2.668378-2.fc10.noarch Sep 04 21:27:55 Updated: python-ldap-2.3.5-1.fc10.i386 Sep 04 21:27:56 Updated: python-ruledispatch-0.5a0-0.10.svnr2306.fc10.i386 Sep 04 21:29:21 Updated: mono-data-2.0-5.fc10.i386 Sep 04 21:29:29 Updated: mono-core-2.0-5.fc10.i386 Sep 04 21:29:31 Updated: mono-winforms-2.0-5.fc10.i386 Sep 04 21:29:35 Updated: mono-web-2.0-5.fc10.i386 Sep 04 21:29:36 Updated: mono-extras-2.0-5.fc10.i386 Sep 04 21:29:37 Updated: mono-data-sqlite-2.0-5.fc10.i386 Sep 04 21:29:38 Updated: mono-nunit-2.0-5.fc10.i386 Sep 04 21:29:38 Updated: mono-data-postgresql-2.0-5.fc10.i386 Sep 04 21:29:39 Updated: mono-data-sybase-2.0-5.fc10.i386 Sep 04 21:29:39 Updated: mono-data-oracle-2.0-5.fc10.i386 Sep 04 21:29:39 Updated: mono-nunit-devel-2.0-5.fc10.i386 Sep 04 21:29:39 Updated: bytefx-data-mysql-2.0-5.fc10.i386 Sep 04 21:31:45 Updated: 6:kdelibs-common-4.1.1-3.fc10.i386 Sep 04 21:32:11 Updated: 6:kdelibs-4.1.1-3.fc10.i386 Sep 04 21:32:18 Updated: kdepimlibs-4.1.1-1.fc10.i386 Sep 04 21:32:26 Updated: kdebase-runtime-4.1.1-2.fc10.i386 Sep 04 21:32:27 Updated: 6:kdebase-libs-4.1.1-1.fc10.i386 Sep 04 21:32:28 Updated: kdesdk-libs-4.1.1-1.fc10.i386 Sep 04 21:32:35 Updated: 6:kdelibs-devel-4.1.1-3.fc10.i386 Sep 04 21:32:36 Updated: kdesdk-utils-4.1.1-1.fc10.i386 Sep 04 21:32:36 Updated: ksysguardd-4.1.1-2.fc10.i386 Sep 04 21:32:38 Updated: kdebase-workspace-libs-4.1.1-2.fc10.i386 Sep 04 21:33:15 Updated: kdebase-workspace-4.1.1-2.fc10.i386 Sep 04 21:33:31 Updated: kdesdk-4.1.1-1.fc10.i386 Sep 04 21:33:46 Updated: 6:kdebase-4.1.1-1.fc10.i386 Sep 04 21:33:49 Updated: kdebase-workspace-devel-4.1.1-2.fc10.i386 Sep 04 21:36:05 Updated: pygobject2-codegen-2.15.4-1.fc10.i386 Sep 04 21:36:06 Updated: pygobject2-doc-2.15.4-1.fc10.i386 Sep 04 21:36:09 Updated: pykickstart-1.43-1.fc10.noarch Sep 04 21:36:10 Updated: pygobject2-2.15.4-1.fc10.i386 Sep 04 21:36:12 Updated: pygobject2-devel-2.15.4-1.fc10.i386 Sep 04 21:37:36 Updated: rarian-0.8.1-1.fc10.i386 Sep 04 21:37:38 Updated: rarian-compat-0.8.1-1.fc10.i386 Sep 04 21:37:38 Updated: rtorrent-0.7.8-4.fc10.i386 Sep 04 21:37:39 Updated: 1:rng-utils-2.0-2.fc10.i386 Sep 04 21:37:43 Updated: rsyslog-3.21.3-3.fc10.i386 Sep 04 21:37:44 Updated: sip-4.7.7-2.fc10.i386 Sep 04 21:37:46 Updated: sudo-1.6.9p17-2.fc10.i386 Sep 04 21:37:48 Updated: shared-mime-info-0.51-2.fc10.i386 Sep 04 21:37:53 Updated: 2:shadow-utils-4.1.2-6.fc10.i386 Sep 04 21:37:53 Updated: rdate-1.4-12.fc10.i386 Sep 04 21:37:55 Updated: system-config-audit-0.4.8-1.fc10.i386 Sep 04 21:38:17 Updated: selinux-policy-3.5.6-1.fc10.noarch Sep 04 21:38:18 Updated: redhat-rpm-config-9.0.3-3.fc10.noarch Sep 04 21:38:26 Updated: rubygems-0.9.4-2.fc10.noarch Sep 04 21:38:30 Updated: setup-2.7.3-1.fc10.noarch Sep 04 21:38:55 Updated: selinux-policy-targeted-3.5.6-1.fc10.noarch Sep 04 21:41:53 Updated: xqilla-2.1.3-0.2.fc10.i386 Sep 04 21:41:55 Updated: qpidc-0.2.667603-3.fc10.i386 Sep 04 21:41:56 Updated: paps-libs-0.6.8-7.fc10.i386 Sep 04 21:41:56 Updated: wavpack-4.50.1-2.fc10.i386 Sep 04 21:41:57 Updated: pciutils-libs-3.0.0-2.fc10.i386 Sep 04 21:42:03 Updated: libpurple-2.5.1-1.fc10.i386 Sep 04 21:42:06 Updated: wavpack-devel-4.50.1-2.fc10.i386 Sep 04 21:42:16 Updated: qpidc-devel-0.2.667603-3.fc10.i386 Sep 04 21:42:17 Updated: podsleuth-0.6.2-3.fc10.i386 Sep 04 21:42:19 Updated: qpidd-0.2.667603-3.fc10.i386 Sep 04 21:42:19 Installed: libv4l-0.4.2-1.fc10.i386 Sep 04 21:42:21 Updated: pwlib-1.10.10-10.fc10.i386 Sep 04 21:42:23 Updated: procps-3.2.7-21.fc10.i386 Sep 04 21:42:23 Installed: perl-Net-LibIDN-0.10-2.fc9.i386 Sep 04 21:42:49 Updated: pidgin-2.5.1-1.fc10.i386 Sep 04 21:42:51 Updated: pciutils-3.0.0-2.fc10.i386 Sep 04 21:42:51 Updated: paps-0.6.8-7.fc10.i386 Sep 04 21:42:52 Updated: tree-1.5.2.1-1.fc10.i386 Sep 04 21:43:09 Updated: vino-2.23.91-1.fc10.i386 Sep 04 21:43:11 Updated: tcsh-6.15-6.fc10.i386 Sep 04 21:43:34 Updated: policycoreutils-2.0.55-2.fc10.i386 Sep 04 21:43:35 Updated: perl-IO-Socket-SSL-1.15-1.fc10.noarch Sep 04 21:43:36 Updated: totem-gstreamer-2.23.91-2.fc10.i386 Sep 04 21:44:04 Updated: totem-2.23.91-2.fc10.i386 Sep 04 21:44:06 Updated: totem-nautilus-2.23.91-2.fc10.i386 Sep 04 21:49:54 Updated: oxygen-icon-theme-4.1.1-2.fc10.noarch Sep 04 21:50:01 Updated: 1:openoffice.org-ure-3.0.0-4.1.fc10.i386 Sep 04 21:50:04 Updated: openldap-2.4.11-2.fc10.i386 Sep 04 21:50:05 Updated: openldap-clients-2.4.11-2.fc10.i386 Sep 04 21:50:17 Updated: orca-2.23.91-1.fc10.i386 Sep 04 21:50:21 Updated: openldap-devel-2.4.11-2.fc10.i386 Sep 04 21:51:31 Updated: 1:openoffice.org-core-3.0.0-4.1.fc10.i386 Sep 04 21:51:36 Updated: 1:openoffice.org-calc-core-3.0.0-4.1.fc10.i386 Sep 04 21:51:39 Updated: 1:openoffice.org-base-core-3.0.0-4.1.fc10.i386 Sep 04 21:51:45 Updated: 1:openoffice.org-brand-3.0.0-4.1.fc10.i386 Sep 04 21:51:50 Updated: 1:openoffice.org-impress-core-3.0.0-4.1.fc10.i386 Sep 04 21:52:05 Updated: 1:openoffice.org-presenter-screen-3.0.0-4.1.fc10.i386 Sep 04 21:52:10 Updated: 1:openoffice.org-impress-3.0.0-4.1.fc10.i386 Sep 04 21:52:11 Updated: 1:openoffice.org-calc-3.0.0-4.1.fc10.i386 Sep 04 21:55:38 Updated: libxml2-2.7.1-1.fc10.i386 Sep 04 21:55:39 Updated: libgsf-1.14.9-1.fc10.i386 Sep 04 21:55:41 Updated: libsoup-2.23.91-1.fc10.i386 Sep 04 21:55:42 Updated: libdvdread-4.1.3-0.3.rc1.fc10.i386 Sep 04 21:55:43 Updated: libdvdnav-4.1.3-0.4.rc1.fc10.i386 Sep 04 21:55:44 Updated: libcurl-7.18.2-6.fc10.i386 Sep 04 21:55:49 Updated: libwnck-2.23.91-1.fc10.i386 Sep 04 21:56:29 Updated: libgweather-2.23.91-1.fc10.i386 Sep 04 21:56:32 Updated: libgsf-gnome-1.14.9-1.fc10.i386 Sep 04 21:56:50 Updated: libgnomekbd-2.23.91-1.fc10.i386 Sep 04 21:56:53 Updated: libaio-0.3.107-4.fc10.i386 Sep 04 21:56:54 Updated: libwnck-devel-2.23.91-1.fc10.i386 Sep 04 21:56:57 Updated: libxml2-python-2.7.1-1.fc10.i386 Sep 04 21:57:01 Updated: libxml2-devel-2.7.1-1.fc10.i386 Sep 04 21:57:01 Updated: libdvdread-devel-4.1.3-0.3.rc1.fc10.i386 Sep 04 21:57:02 Updated: libdvdnav-devel-4.1.3-0.4.rc1.fc10.i386 Sep 04 21:57:04 Updated: libcurl-devel-7.18.2-6.fc10.i386 Sep 04 21:57:06 Updated: libgsf-devel-1.14.9-1.fc10.i386 Sep 04 21:57:07 Updated: libsoup-devel-2.23.91-1.fc10.i386 Sep 04 22:04:22 Updated: gvfs-0.99.6-1.fc10.i386 Sep 04 22:04:22 Updated: nautilus-extensions-2.23.90-4.fc10.i386 Sep 04 22:04:23 Updated: lua-5.1.4-1.fc10.i386 Sep 04 22:04:52 Updated: metacity-2.23.233-1.fc10.i386 Sep 04 22:04:53 Installed: gvfs-smb-0.99.6-1.fc10.i386 Sep 04 22:04:53 Updated: gvfs-fuse-0.99.6-1.fc10.i386 Sep 04 22:04:53 Installed: gvfs-gphoto2-0.99.6-1.fc10.i386 Sep 04 22:04:54 Installed: gvfs-archive-0.99.6-1.fc10.i386 Sep 04 22:05:24 Updated: nautilus-2.23.90-4.fc10.i386 Sep 04 22:05:24 Updated: gvfs-obexftp-0.99.6-1.fc10.i386 Sep 04 22:05:41 Updated: mousetweaks-2.23.91-1.fc10.i386 Sep 04 22:05:43 Updated: metacity-devel-2.23.233-1.fc10.i386 Sep 04 22:05:47 Updated: man-1.6f-9.fc10.i386 Sep 04 22:05:47 Updated: nautilus-devel-2.23.90-4.fc10.i386 Sep 04 22:05:48 Updated: gvfs-devel-0.99.6-1.fc10.i386 Sep 04 22:05:48 Updated: lsdvd-0.16-10.fc10.i386 Sep 04 22:05:49 Updated: 2:mtr-0.73-2.fc10.i386 Sep 04 22:05:49 Updated: lua-devel-5.1.4-1.fc10.i386 Sep 04 22:05:50 Updated: modplugplay-2.05-13.fc10.i386 Sep 04 22:08:41 Updated: audit-libs-1.7.5-1.fc10.i386 Sep 04 22:08:42 Updated: bzip2-libs-1.0.5-3.fc10.i386 Sep 04 22:08:43 Updated: 1:cups-libs-1.3.8-5.fc10.i386 Sep 04 22:08:45 Updated: 12:aspell-0.60.6-3.fc10.i386 Sep 04 22:08:49 Updated: gtksourceview2-2.3.2-1.fc10.i386 Sep 04 22:08:53 Updated: at-spi-1.23.91-1.fc10.i386 Sep 04 22:08:54 Installed: avahi-tools-0.6.22-11.fc10.i386 Sep 04 22:08:59 Updated: gtkhtml3-3.23.91-1.fc10.i386 Sep 04 22:09:00 Updated: gtk2-engines-2.15.4-1.fc10.i386 Sep 04 22:09:10 Updated: cobbler-1.2.1-1.fc10.noarch Sep 04 22:09:11 Updated: 1:cups-devel-1.3.8-5.fc10.i386 Sep 04 22:09:11 Updated: at-spi-python-1.23.91-1.fc10.i386 Sep 04 22:09:12 Updated: curl-7.18.2-6.fc10.i386 Sep 04 22:09:13 Updated: bzip2-1.0.5-3.fc10.i386 Sep 04 22:09:14 Updated: audit-1.7.5-1.fc10.i386 Sep 04 22:09:26 Updated: 1:cups-1.3.8-5.fc10.i386 Sep 04 22:09:26 Updated: bzip2-devel-1.0.5-3.fc10.i386 Sep 04 22:09:28 Updated: audit-libs-devel-1.7.5-1.fc10.i386 Sep 04 22:09:32 Updated: binutils-2.18.50.0.9-1.fc10.i386 Sep 04 22:09:32 Updated: 12:aspell-devel-0.60.6-3.fc10.i386 Sep 04 22:09:33 Updated: binutils-devel-2.18.50.0.9-1.fc10.i386 Sep 04 22:09:45 Updated: cmake-2.6.1-3.fc10.i386 Sep 04 22:09:45 Updated: audit-libs-python-1.7.5-1.fc10.i386 Sep 04 22:09:46 Updated: gtksourceview2-devel-2.3.2-1.fc10.i386 Sep 04 22:15:10 Updated: 1:esound-libs-0.2.40-1.fc10.i386 Sep 04 22:15:11 Updated: SDL-1.2.13-6.fc10.i386 Sep 04 22:15:13 Updated: eel2-2.23.91-1.fc10.i386 Sep 04 22:15:21 Updated: evolution-data-server-2.23.91-1.fc10.i386 Sep 04 22:15:43 Updated: foomatic-3.0.2-64.fc10.i386 Sep 04 22:16:26 Updated: evince-2.23.91-1.fc10.i386 Sep 04 22:16:27 Updated: 1:eclipse-swt-3.4.0-23.fc10.i386 Sep 04 22:16:41 Updated: file-roller-2.23.91-1.fc10.i386 Sep 04 22:16:42 Updated: 1:eclipse-ecj-3.4.0-23.fc10.i386 Sep 04 22:16:42 Updated: 1:esound-devel-0.2.40-1.fc10.i386 Sep 04 22:16:51 Updated: SDL-devel-1.2.13-6.fc10.i386 Sep 04 22:16:51 Updated: fedora-bookmarks-10-1.noarch Sep 04 22:16:53 Updated: elinks-0.12-0.4.pre1.fc10.i386 Sep 04 22:16:54 Updated: eel2-devel-2.23.91-1.fc10.i386 Sep 04 22:17:17 Updated: eog-2.23.91-1.fc10.i386 Sep 04 22:17:23 Updated: dejavu-fonts-2.26-2.fc10.noarch Sep 04 22:17:27 Updated: dejavu-lgc-fonts-2.26-2.fc10.noarch Sep 04 22:25:29 Updated: glib2-2.18.0-1.fc10.i386 Sep 04 22:25:52 Updated: gnome-icon-theme-2.23.91-1.fc10.noarch Sep 04 22:25:53 Updated: gnome-doc-utils-stylesheets-0.13.1-1.fc10.noarch Sep 04 22:26:01 Updated: gnome-doc-utils-0.13.1-1.fc10.noarch Sep 04 22:26:11 Updated: gnome-themes-2.23.91-1.fc10.noarch Sep 04 22:26:14 Updated: gnome-backgrounds-2.23.91-1.fc10.noarch Sep 04 22:26:31 Updated: gnome-keyring-2.23.91-1.fc10.i386 Sep 04 22:26:41 Updated: glib2-devel-2.18.0-1.fc10.i386 Sep 04 22:26:46 Updated: gnome-desktop-2.23.91-3.fc10.i386 Sep 04 22:26:47 Updated: gmyth-0.7.1-7.fc10.i386 Sep 04 22:26:49 Updated: gmp-4.2.2-8.fc10.i386 Sep 04 22:26:51 Updated: gnome-mag-0.15.3-1.fc10.i386 Sep 04 22:27:19 Updated: gnome-media-2.23.91-1.fc10.i386 Sep 04 22:27:37 Updated: gucharmap-2.23.91-1.fc10.i386 Sep 04 22:27:41 Updated: gnome-menus-2.23.91-1.fc10.i386 Sep 04 22:28:04 Updated: gnome-power-manager-2.23.91-1.fc10.i386 Sep 04 22:28:32 Updated: 1:gedit-2.23.91-1.fc10.i386 Sep 04 22:28:33 Updated: gmyth-devel-0.7.1-7.fc10.i386 Sep 04 22:28:37 Updated: gdb-6.8-24.fc10.i386 Sep 04 22:28:51 Updated: gstreamer-plugins-good-0.10.10-2.fc10.i386 Sep 04 22:28:52 Updated: gnome-keyring-devel-2.23.91-1.fc10.i386 Sep 04 22:29:10 Updated: gconf-editor-2.23.91-1.fc10.i386 Sep 04 22:29:12 Updated: gnome-keyring-pam-2.23.91-1.fc10.i386 Sep 04 22:29:13 Updated: gmp-devel-4.2.2-8.fc10.i386 Sep 04 22:29:31 Updated: gnome-settings-daemon-2.23.91-3.fc10.i386 Sep 04 22:29:34 Updated: gnome-desktop-devel-2.23.91-3.fc10.i386 Sep 04 22:29:35 Updated: gzip-1.3.12-7.fc10.i386 Sep 04 22:29:54 Updated: gnome-system-monitor-2.23.91-1.fc10.i386 Sep 04 22:30:15 Updated: gnome-terminal-2.23.91-1.fc10.i386 Sep 04 22:30:33 Updated: gnome-session-2.23.91-1.fc10.i386 Sep 04 22:30:45 Updated: gcalctool-5.23.91-1.fc10.i386 Sep 04 22:32:25 Updated: yelp-2.23.91-1.fc10.i386 Sep 04 22:32:26 Updated: iptraf-3.0.1-6.fc10.i386 Sep 04 22:35:59 Updated: xorg-x11-server-common-1.5.0-1.fc10.i386 Sep 04 22:36:00 Updated: kernel-firmware-2.6.27-0.297.rc5.git2.fc10.noarch Sep 04 22:36:53 Installed: kernel-devel-2.6.27-0.297.rc5.git2.fc10.i686 Sep 04 22:36:55 Updated: xorg-x11-proto-devel-7.4-3.fc10.noarch Sep 04 22:37:00 Updated: kernel-headers-2.6.27-0.297.rc5.git2.fc10.i386 Sep 04 22:37:02 Updated: xorg-x11-server-Xorg-1.5.0-1.fc10.i386 Sep 04 22:37:35 Installed: kernel-2.6.27-0.297.rc5.git2.fc10.i686 Sep 04 22:37:35 Updated: xorg-x11-drv-synaptics-0.15.0-4.fc10.i386 Sep 04 22:37:36 Updated: 1:xorg-x11-drv-nouveau-0.0.11-1.20080902git6dd8ad4.fc10.i386 Sep 04 22:38:19 Installed: kernel-2.6.27-0.297.rc5.git2.fc10.i686 Does anyone have an idea which of these packages could influence the keyboard configuration in a regular runlevel 3 terminal? Regards, Dennis From bpepple at fedoraproject.org Thu Sep 4 23:55:07 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Thu, 04 Sep 2008 19:55:07 -0400 Subject: FESCo Meeting Summary for 2008-09-03 Message-ID: <1220572507.18281.4.camel@kennedy> === Members Present === * Brian Pepple (bpepple) * Kevin Fenzi (nirik) * Jarod Wilson (j-rod) * Bill Nottingham (notting) * Jon Stanley (jds2001) * Dennis Gilmore (dgilmore) * Karsten Hopp (kick_) === Absent === * Josh Boyer (jwb) * David Woodhouse (dwmw2) == Summary == === Features === * FESCo approved the following feature for F10: * https://fedoraproject.org/wiki/Features/EvdevInputDriver * https://fedoraproject.org/wiki/Features/EFI * https://fedoraproject.org/wiki/Features/LXDE * https://fedoraproject.org/wiki/Features/EchoIconTheme * Note: FESCo did have some concerns whether the Echo icon set would meet the current icon coverage that the Mist icon set provides by the development freeze. === Are spins required to have SELinux enabled? === * FESCo would like the Spins SIG to work on a proposal to make their guidelines(1) meet the QA Release Criteria(2). 1. https://fedoraproject.org/wiki/SIGs/Spins/CommunitySpinGuidelines 2. http://fedoraproject.org/wiki/QA/ReleaseCriteria === CD Sets === * FESCo discussed briefly Jeroen van Meeuwen's (kanarip) e-mail(3) about installation CD sets, and felt more work needed to be done on it before they could take action. 1. http://www.redhat.com/archives/fedora-devel-list/2008-August/msg00403.html === FESCo Trac === * nirik has set up a trac instance for FESCo, so that community members can submit requests that needs FESCo's attention. This trac can be found at: https://fedorahosted.org/fesco/ IRC log can be found at: http://bpepple.fedorapeople.org/fesco/FESCo-2008-09-03.html Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From noriko at redhat.com Fri Sep 5 00:22:30 2008 From: noriko at redhat.com (Noriko Mizumoto) Date: Fri, 05 Sep 2008 10:22:30 +1000 Subject: F10 Schedule In-Reply-To: References: <48BF3524.4080805@redhat.com> Message-ID: <48C07BC6.50503@redhat.com> Kevin Kofler ????????: > Noriko Mizumoto redhat.com> writes: >> Currently 'Feature freeze' and 'String freeze' are same day. This makes >> no room for translators to work. If we could have the string freeze 5 >> days before the feature freeze, all translators would be happy to >> complete their work. > > You can get your translations in after the feature freeze. If you're quick and > the maintainer is quick at updating the package, you can even get them tagged > for the beta (ask rel-eng). Otherwise, they'll hit Rawhide just after the beta > (or as soon as they're built if that's later) and make it into the RC and final > release. Thanks Kevin We will try our best to be quick enough. However if the maintainer is not quick enough at updating with translation?, then our work would simply not be included. There are this much of languages for Fedora [1], and it should have some window for translation. [1]http://translate.fedoraproject.org/languages/ > > The feature freeze is intended to apply to new features and to some extent new > package versions (bugfix updates are OK after the freeze, major updates not > really, especially for the packages at the core of the distribution), not > translation updates. It also coincides with the beta freeze, but exemptions > (i.e. tagging requests for the beta) are possible and missing the beta isn't > that big a deal. > > Kevin Kofler The string freeze should be meant that the application is complete as far as translatable strings are concerned. I understand I come too late. I will join the discussion for F11. Thank you so much for all of your kind. noriko > From lmacken at redhat.com Fri Sep 5 00:23:09 2008 From: lmacken at redhat.com (Luke Macken) Date: Thu, 4 Sep 2008 20:23:09 -0400 Subject: Fedora Security Tools spin In-Reply-To: <200809050052.49444.Adi1981.2k5@gmail.com> References: <48BE023A.70703@redhat.com> <48BE1F95.2090509@redhat.com> <20080903210044.GF3726@x300> <200809050052.49444.Adi1981.2k5@gmail.com> Message-ID: <20080905002309.GN3726@x300> On Fri, Sep 05, 2008 at 12:52:49AM +0200, Adrian Pilchowiec wrote: > On Wednesday 03 of September 2008 23:00:44 Luke Macken wrote: > > On Wed, Sep 03, 2008 at 10:54:37AM +0530, Huzaifa Sidhpurwala wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Todd Zullinger wrote: > > > > Huzaifa Sidhpurwala wrote: > > > >> I just came across a knoppix security tool live CD and thought it > > > >> would be a good idea for a security tool fedora spin too. > > > >> The tools are freely available at: > > > >> > > > >> http://knoppix-std.org/index.html > > > >> and are all GPLed? > > > >> > > > >> Do you guys think this is a good idea, I am sure such a spin does > > > >> not exists in Fedora yet. > > > > > > > > Do you mean something like Luke Macken put together? > > > > > > > > http://fedoraproject.org/wiki/LukeMacken/SecurityLiveCD > > > > > > Yeah but more tools and more bare bones, > > > Perhaps i can assist Luke in this? > > > > Absolutely! > > > > I'm in the process of rebasing the kickstart against the latest livecd > > base, and I will be pushing it through the New Spin Process soon. > > > > More tools? Yes. I want it to ship with every security tool in Fedora. > > If you know of any that are missing from the list, please let me know. > > > > Maybe it would be good to add OpenVAS [1] (free fork of nessus) to the spin ? I added OpenVAS to the WishList, thanks! https://fedoraproject.org/wiki/SecuritySpin#Wishlist luke From jkeating at redhat.com Fri Sep 5 00:24:32 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 04 Sep 2008 17:24:32 -0700 Subject: F10 Schedule In-Reply-To: <48C07BC6.50503@redhat.com> References: <48BF3524.4080805@redhat.com> <48C07BC6.50503@redhat.com> Message-ID: <1220574272.3575.9.camel@luminos.localdomain> On Fri, 2008-09-05 at 10:22 +1000, Noriko Mizumoto wrote: > We will try our best to be quick enough. However if the maintainer is > not quick enough at updating with translation?, then our work would > simply not be included. > There are this much of languages for Fedora [1], and it should have some > window for translation. They do have time, from Beta until the final freeze. The translations don't have to be /done/ by Beta. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From noriko at redhat.com Fri Sep 5 01:13:37 2008 From: noriko at redhat.com (Noriko Mizumoto) Date: Fri, 05 Sep 2008 11:13:37 +1000 Subject: F10 Schedule In-Reply-To: <20080904145608.GA8469@nostromo.devel.redhat.com> References: <48BF3524.4080805@redhat.com> <20080904145608.GA8469@nostromo.devel.redhat.com> Message-ID: <48C087C1.3030809@redhat.com> Bill Nottingham ????????: > Noriko Mizumoto (noriko at redhat.com) said: >> Currently 'Feature freeze' and 'String freeze' are same day. This makes >> no room for translators to work. If we could have the string freeze 5 >> days before the feature freeze, all translators would be happy to >> complete their work. >> >> It would be much appreciated if you could once consider this matter. > > It's really best to bring this up when the schedule is made; at this point, > you're essentially requesting that the feature freeze be two days ago, > which isn't practical at this point. I did not know when the schedule was made. I started to subscribe this ML to notice the timing for F11. Please let me know if any other place I should participate. So that we can discuss and bring up if any in the future on time. > > We'll keep this in mind and try and do this for future releases. A reminder > during F11 planning can't hurt. > > Bill Thank you. It was very painful to see some translation work was not included in the previous release even though those translation was made on time of the string freeze. Thus this request is critical for all translators. All translators understand that many of maintainers are trying their best to include our translation. I really appreciate their effort to communicate us, thank you! So just for kind reminder, could you **all maintainers please make sure to re-package just after the string freeze date to include last minute translation? Thanks a lot noriko > From a.badger at gmail.com Fri Sep 5 01:00:31 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 04 Sep 2008 18:00:31 -0700 Subject: Dependency loops considered harmful? In-Reply-To: References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <1220553370.4415.96.camel@localhost.localdomain> <48C05488.5060507@gmail.com> <48C06206.9040702@gmail.com> Message-ID: <48C084AF.5050006@gmail.com> Matthew Woehlke wrote: > Toshio Kuratomi wrote: >> Matthew Woehlke wrote: >>> Toshio Kuratomi wrote: >>>> Uhm... you realize that building an rpm every time you want to test a >>>> change as you develop an app is incredibly clunky? It really is not >>>> going to happen. Really. >>> I still submit that this itself is a problem that should be worked on... >>> Why must it be "too clunky"? Why can't we fix it so that expecting >>> developers to install via rpm, even for incremental builds, is perfectly >>> reasonable? >> >> Here's the workflow: >> [snip] > > Thanks, but I didn't need an analysis of the current problems. I know > it's not practical right now, but that was the whole point I was trying > to make! Here's what I'd like to see: > > Current workflow: > svn up > make > make install > some-app > > Proposed workflow: > svn up > make > rpm-dev-install . > some-app > > See how painless that was? And now, rather than 'make install' littering > my drive with untracked files, the helper: > - rolled an incremental RPM > - updated the existing package > - ...which removed any old files no longer there > - ...and added/updated any modified files > - updated the rpm database to note that some-app is now installed (if it > wasn't) > - ...which also means that if some-app uses libfoo-devel, rpm now > knows this and won't remove libfoo-devel until I remove some-app > The thing is you missed that in my current workflow there is no make install. So the issues you have with it dirtying up the drive don't exist and all the work (or simply waiting for a package and install step to finish) between the make step and invocation of some-app are extra overhead. >>> Of course this process probably won't involve going through >>> a full rpmbuild, just something that tracks the installed files in rpm's >>> database along with updating the database for dependencies (i.e. it >>> would replace 'make install' but not 'make all'). >> >> This is definitely not what rpm is designed to do. >> >> You could probably write a script that did it but you'd have to hook it >> up to all the dependency generating scripts and do minimal parsing of >> the spec file to get manually specified deps and you'd still have to >> work out how to do the make install step cleanly.... I don't see much >> return on investment here but YMMV. > > Yes, you'd probably need to write a spec file, and you might need to > fiddle with the 'make' step as well to make it more rpmbuild-like. Of > course, something like this could also be integrated with popular build > systems (I'd mainly care about cmake). > > For that matter, rpmbuild might just work as-is if allowed to start with > "dirty" source and build trees; you'd have to set things up carefully, > but then it would be just a matter of having the source in a particular > spot (which could be symlinked to get around any inconveniences there) > and running rpmbuild instead of make. Then the trick is just making it > work as not-root. > > What I *don't* get it what's so special about rpm generation that people > seem to think this can't be done. Would it produce an rpm that is > suitable according to Fedora's packaging guidelines? Of course not! But > that's not the objective. Yes, there are reasons current rpmbuild works > the way it does, and I don't think we should change that. I'm just after > a way to allow "non-canon" rpm's rolled from incremental builds. > > Further, they should NOT be root-owned, they should be installable > without needing to be root*, and they should stick out like sore thumbs > if there is a conflict with repo packages (assuming they aren't > installed "in addition", i.e. in /usr/local). > > (* There should be a way for root to flag a particular such package as > being allowed to satisfy dependencies for other packages, that would be > persistent across updates of the package. IOW, I can install qt-copy, > become root and tell rpm to use qt-copy to satisfy dependencies, and > then poppler-qt4 without having to install the repo qt4. Now, obviously, > trying to remove qt-copy will refuse due to poppler-qt4 needing it until > I use the magic incantation (e.g. '--force --nodeps' or something along > those lines, which would of course break poppler-qt4, but I was warned > ;-) )... unless I do it as root, which would just remove poppler-qt4.) > This is getting really far from what rpm does. To do this without root access, you really need rpm to be able to merge the system rpm database with a per-user rpm database. And when you do that, you probably also want to make sure the per-user installed packages override the system-wide installs. And you also have to deal with setuid binaries and the places that random programming languages expect to load their libraries from. It all gets very complex very quickly and starts looking a lot less Unix-y. Certain aspects of what you want could be done (although they seem very out of line with rpm's goals so they'd have to be a separate program) but other aspects will need an entirely different conceptual framework. If you're interested, work on it, but it's not something that's going to be useful for Fedora without some paring down of the new features or a lot of other work. >>>>> All the RPM database needs to do is store a single lousy bit of >>>>> information per package. The "is a dep" flag. Presumably installing >>>>> packages directly with rpm would not set this flag. >>>> s/not// to match the behaviour you say aptitude has. >>> Eh? I would think that 'rpm -Uvh ' should result in >>> being flagged as a non-candidate-for-culling (unless rpm >>> is told otherwise). IOW, if I hand-installed some rpm, I don't want it >>> auto-culled. Maybe there is some miscommunication? >>> >> Possibly. I interpret the "is a dep flag" to mean package Foo was >> installed as a dep of package Bar. Therefore, when package Foo is >> uninstalled, packages that depend on Bar and have "is a dep" set would >> be uninstalled. > > Right, if those "is a dep" packages aren't needed by anything else (just > to clarify; I'm sure that's what you meant). > > What I don't get: Callum said that "rpm -i blah.rpm" would mark "blah" > as a non-dep, i.e. would not be auto-culled. As I understand, you said > that it *would* mark it for auto-culling. It seems to me that the former > behavior is preferable; anything I install by hand should be > non-auto-culled unless I say otherwise, not the other way around. > You're right. I've read that wrong several times now. Thanks for correcting me. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From dennisml at conversis.de Fri Sep 5 01:50:25 2008 From: dennisml at conversis.de (Dennis J.) Date: Fri, 05 Sep 2008 03:50:25 +0200 Subject: rawhide breakage In-Reply-To: <48C072F4.2010003@conversis.de> References: <48C072F4.2010003@conversis.de> Message-ID: <48C09061.3010305@conversis.de> Dennis J. wrote: > I just did an update to the latest rawhide an now my terminal keyboard > is screwed up. I'm using an en_US.UTF-8 locale with a > de-latin1-nodeadkeys keytable. One umlaut works while others show > characters that aren't part of either the english or german regular layout. > > Also after logging into gdm it seem gnome has lost my settings. Here I > get a regular us keyboard layout but other information like my theme and > gnome-terminal configuration also is gone it seems. The culprit for the gnome problem seems to be a bug in gnome-desktop triggered by the xrandr plugin in gnome-settings-daemon. I filed a bug with the details here: https://bugzilla.redhat.com/show_bug.cgi?id=461217 Still trying to figure out the runlevel 3 terminal keyboard layout weirdness though. Regards, Dennis From a.badger at gmail.com Thu Sep 4 21:01:34 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 04 Sep 2008 14:01:34 -0700 Subject: Outage Notification - 2008-09-05 01:00 UTC Message-ID: <48C04CAE.5090608@gmail.com> There will be an outage starting at Y2008-09-05 01:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2008-09-05 01:00 UTC' Affected Services: Websites Database Unaffected Services: CVS / Source Control Buildsystem DNS Mail Torrent Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/808 Reason for Outage: Need to perform maintenance on the db2 database server Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From poelstra at redhat.com Fri Sep 5 02:45:25 2008 From: poelstra at redhat.com (John Poelstra) Date: Thu, 04 Sep 2008 19:45:25 -0700 Subject: F10 Schedule In-Reply-To: <48C087C1.3030809@redhat.com> References: <48BF3524.4080805@redhat.com> <20080904145608.GA8469@nostromo.devel.redhat.com> <48C087C1.3030809@redhat.com> Message-ID: <48C09D45.507@redhat.com> Noriko Mizumoto wrote: > I did not know when the schedule was made. I started to subscribe this > ML to notice the timing for F11. Please let me know if any other place I > should participate. So that we can discuss and bring up if any in the > future on time. I'm sorry this has made your work difficult. To my knowledge this is the first time this issues has been raised as many of our past releases have followed the same schedule structure. https://fedoraproject.org/wiki/Releases/8/Schedule https://fedoraproject.org/wiki/Releases/9/Schedule The schedules on the wiki only show important milestones, but as you've pointed out there are important dependencies between tasks that can't be seen there. I would be glad to help build a focused schedule for translation and localization and have offered to do so in the past. https://www.redhat.com/archives/fedora-i18n-list/2007-December/msg00000.html All I need to build this in TaskJuggler is: a) series of tasks b) when the tasks start and end c) dependencies between the tasks in your work and other parts of the release. Some examples are here: http://poelstra.fedorapeople.org/schedules/f-10/f-10-docs-tasks.html http://poelstra.fedorapeople.org/schedules/f-10/f-10-releng-tasks.html http://poelstra.fedorapeople.org/schedules/f-10/f-10-quality-tasks.html John From noriko at redhat.com Fri Sep 5 02:55:39 2008 From: noriko at redhat.com (Noriko Mizumoto) Date: Fri, 05 Sep 2008 12:55:39 +1000 Subject: F10 Schedule In-Reply-To: <1220574272.3575.9.camel@luminos.localdomain> References: <48BF3524.4080805@redhat.com> <48C07BC6.50503@redhat.com> <1220574272.3575.9.camel@luminos.localdomain> Message-ID: <48C09FAB.5030502@redhat.com> Jesse Keating ????????: > On Fri, 2008-09-05 at 10:22 +1000, Noriko Mizumoto wrote: >> We will try our best to be quick enough. However if the maintainer is >> not quick enough at updating with translation?, then our work would >> simply not be included. >> There are this much of languages for Fedora [1], and it should have some >> window for translation. > > They do have time, from Beta until the final freeze. The translations > don't have to be /done/ by Beta. Oh, good thank you. I may not fully understand the process. I thought that the maintainers do not re-package after the beta string, but it is not correct :) But it also might be very hard for the maintainers to include the translation just done on the day before of the final freeze, no? Then by when the translation should be done to include F10 release? In other words, we like all maintainers check any updated translation and include them at some stage, making sure nothing behind. Otherwise, imagine the mess if more than say 30 translators of different languages start asking to the maintainer their work inclusion, and if it happens package to package... noriko From noriko at redhat.com Fri Sep 5 03:41:56 2008 From: noriko at redhat.com (Noriko Mizumoto) Date: Fri, 05 Sep 2008 13:41:56 +1000 Subject: F10 Schedule In-Reply-To: <48C09D45.507@redhat.com> References: <48BF3524.4080805@redhat.com> <20080904145608.GA8469@nostromo.devel.redhat.com> <48C087C1.3030809@redhat.com> <48C09D45.507@redhat.com> Message-ID: <48C0AA84.40101@redhat.com> John Poelstra ????????: > Noriko Mizumoto wrote: >> I did not know when the schedule was made. I started to subscribe this >> ML to notice the timing for F11. Please let me know if any other place >> I should participate. So that we can discuss and bring up if any in >> the future on time. > > I'm sorry this has made your work difficult. To my knowledge this is > the first time this issues has been raised as many of our past releases > have followed the same schedule structure. I am glad that all of you take this up. We might have some miscommunication. I would like to be a part of fixing this. > > https://fedoraproject.org/wiki/Releases/8/Schedule > https://fedoraproject.org/wiki/Releases/9/Schedule > > The schedules on the wiki only show important milestones, but as you've > pointed out there are important dependencies between tasks that can't be > seen there. > > I would be glad to help build a focused schedule for translation and > localization and have offered to do so in the past. > https://www.redhat.com/archives/fedora-i18n-list/2007-December/msg00000.html I missed it, sorry. I unsubscribed fedora-i18n-list sometime ago. All translators are living at fedora-trans-list. It would be nice if you can hop in there when we can help. http://www.redhat.com/mailman/listinfo/fedora-trans-list > > > All I need to build this in TaskJuggler is: > a) series of tasks Fedora modules, Fedora documentation and Fedora Web http://translate.fedoraproject.org/module/ > b) when the tasks start and end The tasks start soon as module/docs available, and end according to the freeze > c) dependencies between the tasks in your work and other parts of the > release Branch/version: the target branch/version to be translated for the release. The freeze date: such as string freeze which means module/docs available to complete translation. The translation freeze date: translation done by this date must be included in the release. I hope covering what you need. Thank you so much for your kind support! noriko > > Some examples are here: > http://poelstra.fedorapeople.org/schedules/f-10/f-10-docs-tasks.html > http://poelstra.fedorapeople.org/schedules/f-10/f-10-releng-tasks.html > http://poelstra.fedorapeople.org/schedules/f-10/f-10-quality-tasks.html > > John > From martin.langhoff at gmail.com Fri Sep 5 05:25:10 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Fri, 5 Sep 2008 17:25:10 +1200 Subject: Anaconda install - conflicts over ifcfg-eth0 Message-ID: <46a038f90809042225y329e915ej5b0048ade36ac86b@mail.gmail.com> Executive version: I am preparing a package that provides an ifcfg-eth0 file - and finding that Anaconda overwrites it... If the package says %config{noreplace} /etc/sysconfig/network-scripts/ifcfg-eth0 then anaconda installs the file as an .rpmnew file. On the other hand, if I remove the '{noreplace}' option, anaconda writes an .rpmorig file with its settings _and also_ overwrites the ifcfg-eth0 file. The result is that cmp ifcfg-eth0{,.rpmorig} is true. This looks to me like an anaconda bug :-/ Are there reasonable ways to make this work? Can I tell anaconda that the network config used during install is _not_ to be saved permanently? As a workaround, I can overwrite the file on %post but that gets nastier... Note! This package is not meant for Fedora proper, naturally. It is a configuration package for the OLPC School Server, with (mostly) good reasons to do the wild things it does :-) cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From a.badger at gmail.com Fri Sep 5 06:54:10 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 04 Sep 2008 23:54:10 -0700 Subject: Dependency loops considered harmful? In-Reply-To: <1220571347.17785.44.camel@rosebud> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <48C00D4F.2030004@gmail.com> <1220556463.17785.30.camel@rosebud> <48C03FF3.9040903@gmail.com> <1220560349.17785.37.camel@rosebud> <48C0565A.5090906@gmail.com> <1220571347.17785.44.camel@rosebud> Message-ID: <48C0D792.4040906@gmail.com> Seth Vidal wrote: > On Thu, 2008-09-04 at 14:42 -0700, Toshio Kuratomi wrote: >> If it goes in /etc/yum.conf then either one could be the default. A >> setting in a config file can be scripted in a kickstart, deployed by >> puppet, or set by an individual user once and then forgotten. >> > > nod. The other option, given the code I just put in a separate script, > is to make it a plugin to handle the above. > > It wouldn't be hard to do and then if you wanted leaf dep removal you > could install/enable the plugin. > That sounds ideal. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From dcantrell at redhat.com Fri Sep 5 08:18:17 2008 From: dcantrell at redhat.com (David Cantrell) Date: Thu, 4 Sep 2008 22:18:17 -1000 Subject: Anaconda install - conflicts over ifcfg-eth0 In-Reply-To: <46a038f90809042225y329e915ej5b0048ade36ac86b@mail.gmail.com> References: <46a038f90809042225y329e915ej5b0048ade36ac86b@mail.gmail.com> Message-ID: <0F0AC17B-E540-456B-B635-474484E5D716@redhat.com> On Sep 4, 2008, at 7:25 PM, Martin Langhoff wrote: > Executive version: I am preparing a package that provides an > ifcfg-eth0 file - and finding that Anaconda overwrites it... > > If the package says %config{noreplace} > /etc/sysconfig/network-scripts/ifcfg-eth0 then anaconda installs the > file as an .rpmnew file. On the other hand, if I remove the > '{noreplace}' option, anaconda writes an .rpmorig file with its > settings _and also_ overwrites the ifcfg-eth0 file. The result is that > cmp ifcfg-eth0{,.rpmorig} is true. > > This looks to me like an anaconda bug :-/ Are there reasonable ways to > make this work? Can I tell anaconda that the network config used > during install is _not_ to be saved permanently? > > As a workaround, I can overwrite the file on %post but that gets > nastier... > > Note! This package is not meant for Fedora proper, naturally. It is a > configuration package for the OLPC School Server, with (mostly) good > reasons to do the wild things it does :-) For what you are doing, you should look in to using kickstart to prepare a custom installation for your environment (if you haven't done that already). Anaconda always writes the ifcfg-DEVICE files based on the information provided during installation. If you need to override this, use %post in kickstart. http://fedoraproject.org/wiki/Anaconda/Kickstart -- David Cantrell Red Hat / Honolulu, HI From aph at redhat.com Fri Sep 5 09:22:25 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 05 Sep 2008 10:22:25 +0100 Subject: OT: This is for java geeks out there In-Reply-To: <48C067A6.3050506@cs.tu-berlin.de> References: <48C067A6.3050506@cs.tu-berlin.de> Message-ID: <48C0FA51.7070903@redhat.com> Christoph H?ger wrote: > Hi, > > I do not know where to ask that, so I try it here: > > I want to load a (dynamically created) class via URL ClassLoader and > then invoke a public static method on it. > > Here is the code: > > Class lexerDefs = Class.forName("parser.LexerDefs", true, loader); > > Method getLexerDefs = null; > > try { > getLexerDefs = lexerDefs.getMethod("lexerDefs", new Class[] {}); > } catch (NoSuchMethodException e) { > fail("Class " + lexerDefs.getName() + " has no method lexerDefs()\n" > + e.getMessage()); > } > > parser.Options.inputFile = this.inputFile; > > System.err.println("invoking: " + getLexerDefs.toString()); > > Object retObject = getLexerDefs.invoke(null, new Object[0]); > > But all I get is: > Class test.TestParserGenerator can not access a member of class > parser.LexerDefs with modifiers "public static" > > So loading class seems to work, but I cannot invoke a _public_ method? Why? > > Anyone knows about reflection? Yes. Does a public static method with that exact signature "()" exist? In the classpath? What if you call it directly? Andrew. From rjones at redhat.com Fri Sep 5 09:30:31 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 5 Sep 2008 10:30:31 +0100 Subject: MinGW on Fedora - an update Message-ID: <20080905093031.GA25404@amd.home.annexia.org> Dan Berrange (in particular) and myself (a little) have done quite a bit more work on mingw in Fedora. We now have: - automatic dependency generation - automatic stripping of binaries - a collection of RPM macros which simplify writing spec files - ~10 working libraries Anyway, check out the development repository: http://hg.et.redhat.com/misc/fedora-mingw--devel/ Please read the README file first! Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From lfarkas at lfarkas.org Fri Sep 5 09:54:16 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 05 Sep 2008 11:54:16 +0200 Subject: MinGW on Fedora - an update In-Reply-To: <20080905093031.GA25404@amd.home.annexia.org> References: <20080905093031.GA25404@amd.home.annexia.org> Message-ID: <48C101C8.1000806@lfarkas.org> Richard W.M. Jones wrote: > Dan Berrange (in particular) and myself (a little) have done quite a > bit more work on mingw in Fedora. > > We now have: > - automatic dependency generation > - automatic stripping of binaries > - a collection of RPM macros which simplify writing spec files > - ~10 working libraries > > Anyway, check out the development repository: > http://hg.et.redhat.com/misc/fedora-mingw--devel/ > > Please read the README file first! ETA into fedora? -- Levente "Si vis pacem para bellum!" From berrange at redhat.com Fri Sep 5 10:10:46 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 5 Sep 2008 11:10:46 +0100 Subject: MinGW on Fedora - an update In-Reply-To: <48C101C8.1000806@lfarkas.org> References: <20080905093031.GA25404@amd.home.annexia.org> <48C101C8.1000806@lfarkas.org> Message-ID: <20080905101045.GB22542@redhat.com> On Fri, Sep 05, 2008 at 11:54:16AM +0200, Farkas Levente wrote: > Richard W.M. Jones wrote: > > Dan Berrange (in particular) and myself (a little) have done quite a > > bit more work on mingw in Fedora. > > > > We now have: > > - automatic dependency generation > > - automatic stripping of binaries > > - a collection of RPM macros which simplify writing spec files > > - ~10 working libraries > > > > Anyway, check out the development repository: > > http://hg.et.redhat.com/misc/fedora-mingw--devel/ > > > > Please read the README file first! > > ETA into fedora? Too many unknowns to give any sensisble prediction. We're waiting on the releng/infrastructure guys to create a dedicated build root for mingw stuff, and set things to it publishes into a separate YUM repo as per earlier Fedora Board decision[1]. I've no idea how hard/complex this is, or how long it'll take. Once that's done then we need to bootstrap the build, and get all the packages through review. http://fedoraproject.org/wiki/Board/Meetings/2008-07-15 Be nice to have it all done for F10, but no idea if that is practical as the infrastructure team is very busy. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From mschwendt at gmail.com Fri Sep 5 11:25:13 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 5 Sep 2008 13:25:13 +0200 Subject: Dependency loops considered harmful? In-Reply-To: References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <1220553370.4415.96.camel@localhost.localdomain> Message-ID: <20080905132513.12347d4f.mschwendt@gmail.com> On Thu, 4 Sep 2008 22:05:22 +0300, Vasile Gaburici wrote: > The problem with using rpm to install software you develop is that you > need to do a *full build* every time whenever you change something. > Even with a caching compiler, that can take a long time. Think Qt for > instance. Not true. It's certainly not mandatory. You can simply tar your full development tree (including built object files) and only re-run make && make install in the spec file without starting from scratch. That's enough to package up the installed files with RPM. Off-topic, though. From rjones at redhat.com Fri Sep 5 11:33:03 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 5 Sep 2008 12:33:03 +0100 Subject: MinGW on Fedora - an update In-Reply-To: <48C101C8.1000806@lfarkas.org> References: <20080905093031.GA25404@amd.home.annexia.org> <48C101C8.1000806@lfarkas.org> Message-ID: <20080905113303.GA25742@amd.home.annexia.org> On Fri, Sep 05, 2008 at 11:54:16AM +0200, Farkas Levente wrote: > Richard W.M. Jones wrote: > > Dan Berrange (in particular) and myself (a little) have done quite a > > bit more work on mingw in Fedora. > > > > We now have: > > - automatic dependency generation > > - automatic stripping of binaries > > - a collection of RPM macros which simplify writing spec files > > - ~10 working libraries > > > > Anyway, check out the development repository: > > http://hg.et.redhat.com/misc/fedora-mingw--devel/ > > > > Please read the README file first! > > ETA into fedora? As Dan said, but don't let that stop you if you want to download and play with it, and send patches :-) It's currently buildable on Rawhide, and possibly on earlier versions of Fedora too. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 67 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From choeger at cs.tu-berlin.de Fri Sep 5 11:38:15 2008 From: choeger at cs.tu-berlin.de (=?ISO-8859-15?Q?Christoph_H=F6ger?=) Date: Fri, 05 Sep 2008 13:38:15 +0200 Subject: OT: This is for java geeks out there In-Reply-To: <48C0FA51.7070903@redhat.com> References: <48C067A6.3050506@cs.tu-berlin.de> <48C0FA51.7070903@redhat.com> Message-ID: <48C11A27.4000908@cs.tu-berlin.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Haley schrieb: > Christoph H?ger wrote: >> Hi, >> >> I do not know where to ask that, so I try it here: >> >> I want to load a (dynamically created) class via URL ClassLoader and >> then invoke a public static method on it. >> >> Here is the code: >> >> Class lexerDefs = Class.forName("parser.LexerDefs", true, loader); >> >> Method getLexerDefs = null; >> >> try { >> getLexerDefs = lexerDefs.getMethod("lexerDefs", new Class[] {}); >> } catch (NoSuchMethodException e) { >> fail("Class " + lexerDefs.getName() + " has no method lexerDefs()\n" >> + e.getMessage()); >> } >> >> parser.Options.inputFile = this.inputFile; >> >> System.err.println("invoking: " + getLexerDefs.toString()); >> >> Object retObject = getLexerDefs.invoke(null, new Object[0]); >> >> But all I get is: >> Class test.TestParserGenerator can not access a member of class >> parser.LexerDefs with modifiers "public static" >> >> So loading class seems to work, but I cannot invoke a _public_ method? Why? >> >> Anyone knows about reflection? > > Yes. Does a public static method with that exact signature "()" exist? > In the classpath? What if you call it directly? > > Andrew. > Hi, the problem is solved (thanks again to Alexei Mokeev who answered off list). My external class wasn't public enough ;). The error message confused me, as it stated it could not access the method and not the class. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFIwRonhMBO4cVSGS8RAiPrAKC9JiH5PlWyKayfyGP2E5fnUK+b4wCcDJqt eZiZncqIz31roLe335NUy0k= =wM50 -----END PGP SIGNATURE----- From rawhide at fedoraproject.org Fri Sep 5 11:39:51 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Fri, 5 Sep 2008 11:39:51 +0000 (UTC) Subject: rawhide report: 20080905 changes Message-ID: <20080905113951.CB3701F8230@releng2.fedora.phx.redhat.com> New package inetvis 3-D scatter-plot visualization for network traffic Updated Packages: NetworkManager-0.7.0-0.11.svn4022.1.fc10 ---------------------------------------- * Thu Sep 4 18:00:00 2008 Dan Williams - 1:0.7.0-0.11.svn4022.1 - Fix WPA Ad-Hoc connections R-multcomp-1.0-1.fc10 --------------------- * Thu Sep 4 18:00:00 2008 Orion Poplawski - 1.0-2 - Update to 1.0-2 R-mvtnorm-0.9-1.fc10 -------------------- * Thu Sep 4 18:00:00 2008 Orion Poplawski - 0.9-1 - Update to 0.9-2 R-zoo-1.5-5.fc10 ---------------- * Thu Sep 4 18:00:00 2008 Orion Poplawski 1.5-5 - Update to 1.5-4 afflib-3.3.2-2.fc10 ------------------- * Thu Sep 4 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.3.2-2 - Update gcc43 patch * Thu Sep 4 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.3.2-1 - Update to 3.3.2 - Remove Requires for ewftools from afftools - Qemu image support is disabled (experimental) * Mon Sep 1 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.3.1-1 - Update to 3.3.1 * Tue Jul 29 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.2.5-3 - Patch with fuzz 2 * Thu Jul 24 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.2.5-2 - Remove nos3 patch * Thu Jul 24 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.2.5-1 - Update to 3.2.5 aimage-3.1.2-1.fc10 ------------------- * Thu Sep 4 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.1.2-1 - Update to 3.1.2 apr-api-docs-1.3.3-1.fc10 ------------------------- * Fri Sep 5 18:00:00 2008 Bojan Smojver 1.3.3-1 - Bump up to 1.3.3 augeas-0.3.1-1.fc10 ------------------- * Thu Sep 4 18:00:00 2008 David Lutterkort - 0.3.1-1 - New version automoc-1.0-0.9.rc2.fc10 ------------------------ * Thu Sep 4 18:00:00 2008 Lorenzo Villani - 1.0-0.9.rc2 - automoc4-0.9.87 (1.0-rc2) bluez-libs-3.36-1.fc10 ---------------------- * Thu Sep 4 18:00:00 2008 - Lennart Poettering - 3.36-1 - Update to 3.36 bluez-utils-3.36-2.fc10 ----------------------- * Thu Sep 4 18:00:00 2008 - Lennart Poettering - 3.36-2 - Pass -x to hcid by default to make new BlueZ 4.x APIs available * Thu Sep 4 18:00:00 2008 - Lennart Poettering - 3.36-1 - Update to 3.36 cairo-dock-1.6.2.2-1.fc10 ------------------------- * Thu Sep 4 18:00:00 2008 Mamoru Tasaka - 1.6.2.2-1 - 1.6.2.2 eclipse-epic-0.6.25-1.fc10 -------------------------- * Thu Sep 4 18:00:00 2008 Mat Booth 0.6.25-1 - Updated to version 0.6.25. - New features: Persistent variables view options and Module::Starter integration. eclipse-photran-4.0.0-0.b4.fc10.2 --------------------------------- * Wed Sep 3 18:00:00 2008 Orion Poplawski - 4.0.0-0.b4.2 - Split out IBM XL Fortran support into sub-package * Thu Aug 28 18:00:00 2008 Orion Poplawski - 4.0.0-0.b4.1 - 4.0.0 Beta 4 - Update for building against Eclipse SDK 3.4 - Move everything to %{_libdir} empathy-2.23.91-1.fc10 ---------------------- * Thu Sep 4 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 fedora-ds-1.1.2-1.fc10 ---------------------- * Thu Sep 4 18:00:00 2008 Rich Megginson 1.1.2-1 - this is the 1.1.2 release - made noarch because Fedora is supposed to just "do the right thing" now - added fedora-ds-dsgw fedora-ds-admin-console-1.1.2-1.fc10 ------------------------------------ * Thu Jul 3 18:00:00 2008 Rich Megginson 1.1.2-1 - disable SSLv2 settings fedora-ds-console-1.1.2-2.fc10 ------------------------------ * Thu Sep 4 18:00:00 2008 Rich Megginson 1.1.2-2 - fixed incorrect source * Thu Jul 3 18:00:00 2008 Rich Megginson 1.1.2-1 - fix threading issues with create new ds instance dialog foomatic-3.0.2-65.fc10 ---------------------- * Thu Sep 4 18:00:00 2008 Tim Waugh 3.0.2-65 - Removed ampathxml and xml-cflags patches. - Updated db-hpijs to 20080904. - Updated db to 20080904. - Updated filters to 3.0-20080904. - Updated db-engine to 3.0-20080904. * Wed Sep 3 18:00:00 2008 Tim Waugh - Finally remove ppdload. gnome-applets-2.23.91-1.fc10 ---------------------------- * Thu Sep 4 18:00:00 2008 Matthias Clasen - 1:2.23.91-1 - Update to 2.23.91 gnome-desktop-2.23.91-4.fc10 ---------------------------- * Thu Sep 4 18:00:00 2008 Soren Sandmann - 2.23.91-4 - Fix bug 461152 gnome-media-2.23.91-2.fc10 -------------------------- * Thu Sep 4 18:00:00 2008 Matthias Clasen 2.23.91-2 - Fix a non-standard icon name gnome-panel-2.23.91-1.fc10 -------------------------- * Tue Sep 2 18:00:00 2008 Matthias Clasen - 2.23.91-1 - Update to 2.23.91 gnome-settings-daemon-2.23.91-4.fc10 ------------------------------------ * Thu Sep 4 18:00:00 2008 Soren Sandmann - 2.23.91-4 - Use the fn-F7 key, not the F7 key. gocr-0.45-4.fc10 ---------------- * Thu Sep 4 18:00:00 2008 Tomas Smetana - 0.45-4 - and obsolete the devel package * Thu Sep 4 18:00:00 2008 Tomas Smetana - 0.45-3 - remove the unusable devel package again (related #344721) gtk2-2.14.0-3.fc10 ------------------ * Fri Sep 5 18:00:00 2008 Matthias Clasen - 2.14.0-3 - Fix a greeter crash * Thu Sep 4 18:00:00 2008 Matthias Clasen - 2.14.0-2 - Fix a deadlock in pixbuf loader initialization * Thu Sep 4 18:00:00 2008 Matthias Clasen - 2.14.0-1 - Update to 2.14.0 idm-console-framework-1.1.2-1.fc10 ---------------------------------- * Wed Jul 2 18:00:00 2008 Rich Megginson 1.1.2-1 - numerous fixes for threading issues and help for debugging and eclipse iputils-20071127-5.fc10 ----------------------- * Fri Aug 15 18:00:00 2008 Jiri Skala - 20071127-5 - removed a dependency on libsysfs library in arping * Wed Aug 6 18:00:00 2008 Jiri Skala - 20071127-4 - Resolves: #455713 remove suid from ping - corrected typing error in man kdelibs-4.1.1-5.fc10 -------------------- * Wed Sep 3 18:00:00 2008 Luk???? Tinkl 4.1.1-5 - fixed crash on setting cookies on empty domains (like the file system), KDE bug #170147 - fix URL navigator focus in file dialogs, KDE bug #169497, #170211 * Tue Sep 2 18:00:00 2008 Than Ngo 4.1.1-4 - apply patch to fix regression in khtml kernel-2.6.27-0.305.rc5.git6.fc10 --------------------------------- * Fri Sep 5 18:00:00 2008 Dave Airlie - modesetting updates - fix AMD rs690 - roll in krh dri2 patch * Thu Sep 4 18:00:00 2008 David Woodhouse - 2.6.27-rc5-git6 * Wed Sep 3 18:00:00 2008 Roland McGrath - utrace update * Wed Sep 3 18:00:00 2008 Jarod Wilson - Another series of checkpatch cleanups to lirc code, courtesy of Janne Grunau. This stuff might actually finally get upstream soon... * Wed Sep 3 18:00:00 2008 Chuck Ebbert - 2.6.27-rc5-git5 kipi-plugins-0.2.0-0.1.beta1.fc10 --------------------------------- * Thu Sep 4 18:00:00 2008 Rex Dieter 0.2.0-0.1.beta1 - kipi-plugins-0.2.0-beta1, kde4 libXScrnSaver-1.1.3-1.fc10 -------------------------- * Thu Sep 4 18:00:00 2008 Adam Jackson 1.1.3-1 - libXScrnSaver 1.1.3 libXau-1.0.4-1.fc10 ------------------- * Thu Sep 4 18:00:00 2008 Adam Jackson 1.0.4-1 - libXau 1.0.4 libXft-2.1.13-1.fc10 -------------------- * Thu Sep 4 18:00:00 2008 Adam Jackson 2.1.13-1 - libXft 2.1.13 libXrandr-1.2.3-1.fc10 ---------------------- * Thu Sep 4 18:00:00 2008 Adam Jackson 1.2.3-1 - libXrandr 1.2.3 libXt-1.0.5-1.fc10 ------------------ * Thu Sep 4 18:00:00 2008 Adam Jackson 1.0.5-1 - libXt 1.0.5 libXv-1.0.4-1.fc10 ------------------ * Thu Sep 4 18:00:00 2008 Adam Jackson 1.0.4-1 - libXv 1.0.4 libXxf86vm-1.0.2-1.fc10 ----------------------- * Thu Sep 4 18:00:00 2008 Adam Jackson 1.0.2-1 - libXxf86vm 1.0.2 libmatthew-java-0.7.1-4.fc10 ---------------------------- * Thu Sep 4 18:00:00 2008 Omair Majid 0.7.1-4 - Added -j1 to disable parallel build. Fixes the race condition that resulted in class files of size 0 - Eliminated early_upstream.patch (patch was adapted by upstream) libtirpc-0.1.9-4.fc10 --------------------- * Thu Sep 4 18:00:00 2008 Steve Dickson 0.1.9-4 - Always make IPv6 sockets V6ONLY - Fix incorrect sizeof() in __rpc_getbroadifs lohit-fonts-2.3.0-1.fc10 ------------------------ * Wed Aug 20 18:00:00 2008 Rahul Bhalerao - 2.3.0-1 - Forked Lohit Hindi into Marathi, Maithili, Kashmiri, Konkani, Sindhi and Nepali. - Bug 215902: [hi_IN, mr_IN]Incorrect extent of 0x093f when attached to a composite character which has width greater than a single character (hi_IN & maybe others) - Bug 445176: [ml_IN] Conjuncts combining with 0D30 do not form the pre based glyph - Improved Anchoring(blwm Anchor-0) for Hindi font. - Corrected positioning of U+0953 for Hindi font. m17n-contrib-1.1.7-3.fc10 ------------------------- * Thu Sep 4 18:00:00 2008 Parag Nemade -1.1.7-3 - Resolves: rh# Bug 458264-Required Inscript map for Sindhi language mimedefang-2.65-1.fc10 ---------------------- * Thu Sep 4 18:00:00 2008 Robert Scheck 2.65-1 - Upgrade to 2.65 mock-0.9.11-1.fc10 ------------------ * Thu Sep 4 18:00:00 2008 Clark Williams - 0.9.11-1 - added workarounds for rawhide rpm (BZ 455387 and 458234) - disabled tmpfs plugin on epel-4-x86_64 - fixed autotools breakage in configure.ac nautilus-2.23.91-1.fc10 ----------------------- * Tue Sep 2 18:00:00 2008 Tomas Bzatek - 2.23.91-1 - Update to 2.23.91 openbox-3.4.7.2-5.fc10 ---------------------- * Thu Sep 4 18:00:00 2008 Miroslav Lichvar - 3.4.7.2-5 - Don't use --choose-session option in gnome session script perl-Font-TTF-0.45-2.fc10 ------------------------- * Thu Sep 4 18:00:00 2008 - 0.45-2 ??? ??? Artistic 2.0 perl-HTML-Table-2.08a-1.fc10 ---------------------------- * Thu Sep 4 18:00:00 2008 Orion Poplawski 2.08a-1 - Update to 2.08a perl-PDL-2.4.3-13.fc10 ---------------------- * Thu Sep 4 18:00:00 2008 Orion Poplawski - 2.4.3-13 - Add patch to add plparseopts function - Update URL pinfo-0.6.9-8.fc10 ------------------ * Thu Sep 4 18:00:00 2008 Miroslav Lichvar 0.6.9-8 - modify default search path for info pages so that current directory is searched last (#458633) plague-0.4.5.2-1.fc10 --------------------- * Thu Sep 4 18:00:00 2008 Dennis Gilmore - 0.4.5.2-1 - fix bug in find option to plague-user-manager python-bugzilla-0.4-0.rc1.fc10 ------------------------------ * Thu Sep 4 18:00:00 2008 Will Woods 0.4-0.rc1 - Update to python-bugzilla 0.4-rc1 - We now support upstream Bugzilla 3.x and Red Hat's Bugzilla 3.x instance - library saves login cookie in ~/.bugzillacookies - new 'bugzilla login' command to get a login cookie rusers-0.17-54.fc10 ------------------- * Thu Sep 4 18:00:00 2008 Jiri Moskovcak - 0.17-54 - modified truncate patch to work with fuzz=0 sane-backends-1.0.19-12.fc10 ---------------------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 1.0.19-12 - fix license tag sane-frontends-1.0.14-5.fc10 ---------------------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 1.0.14-5 - fix license tag schroedinger-1.0.5-2.fc10 ------------------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 1.0.5-2 - fix license tag scim-input-pad-0.1.1-9.fc10 --------------------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 0.1.1-9 - fix license tag scim-qtimm-0.9.4-11.fc10 ------------------------ * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 0.9.4-11 - fix license tag scim-tomoe-0.6.0-5.fc10 ----------------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 0.6.0-5 - fix license tag scmxx-0.9.0-2.fc10 ------------------ * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 0.9.0-2 - fix license tag scratchpad-0.3.0-5.fc10 ----------------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 0.3.0-5 - fix license tag scribes-templates-20070602-2.fc10 --------------------------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 20070602-2 - fix license tag seahorse-plugins-2.23.91-1.fc10 ------------------------------- * Thu Sep 4 18:00:00 2008 Matthias Clasen 2.23.91-1 - Update to 2.23.91 sec-2.4.1-2.fc10 ---------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 2.4.1-2 - fix license tag seedit-2.2.0-3.fc10 ------------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 2.2.0-3 - fix license tag selinux-policy-3.5.6-2.fc10 --------------------------- * Thu Sep 4 18:00:00 2008 Dan Walsh 3.5.6-2 - Add tinyxs-max file system support shapelib-1.2.10-18.20060304cvs ------------------------------ * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 1.2.10-18.20060304cvs - fix patch application * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 1.2.10-17.20060304cvs - fix license tag sharutils-4.7-3.fc10 -------------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 4.7-2 - forgot the new source * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 4.7-1 - update to 4.7 - fix license tag - package cleanups * Thu Sep 4 18:00:00 2008 Jason L Tibbitts III - 4.7-3 - Requires(pre) should be Requires(post). sinjdoc-0.5-7.fc10 ------------------ * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 0.5-7 - fix license tag sip-4.7.7-3.fc10 ---------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway 4.7.7-3 - fix license tag sipsak-0.9.6-4.fc10 ------------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway 0.9.6-4 - fix license tag skkdic-20080904-1.fc10 ---------------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 20080904-1 - fix license tag - update source files sloccount-2.26-8.fc10 --------------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway 2.26-8 - fix license tag smb4k-0.10.0-2.fc10 ------------------- * Thu Sep 4 18:00:00 2008 Marcin Garski 0.10.0-2 - Update to 0.10.0 smolt-1.1.1.1-5.fc10 -------------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway 1.1.1.1-5 - fix license tag socat-1.6.0.1-2.fc10 -------------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway 1.6.0.1-2 - forgot to upload new source * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway 1.6.0.1-1 - fix license tag - update to 1.6.0.1 sofsip-cli-0.13-6.fc10 ---------------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 0.13-6 - fix license tag sos-1.8-2.fc10 -------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway 1.8-2 - more cleanups to get this package building * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway 1.8-1 - fix license tag - undid stupid duplicate variable declarations (name, version, release) soundtracker-0.6.8-6.fc10 ------------------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 0.6.8-6 - fix license tag sox-14.1.0-3.fc10 ----------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway 14.1.0-3 - missed a few BR, this should be all of them * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway 14.1.0-2 - enable the full set of functionality with missing BR * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway 14.1.0-1 - fix license tag - update to 14.1.0 - disabled static libs (if something really needs them, re-enable them in a -static subpackage) * Wed Apr 16 18:00:00 2008 Jiri Moskovcak - 14.0.1-2 - enabled flac support - Resolves: #442703 spamassassin-3.2.5-2.fc10 ------------------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway 3.2.5-2 - fix license tag specspo-15-2 ------------ * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 15-2 - fix license tag specto-0.2.2-2.fc10 ------------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 0.2.2-2 - fix license tag spicctrl-1.9-7.fc10 ------------------- * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 1.9-7 - fix license tag wgrib-1.8.0.12u-1.fc10 ---------------------- * Thu Sep 4 18:00:00 2008 - Orion Poplawski - 1.8.0.12u-1 - Update to 1.8.0.12u xenner-0.44-1.fc10 ------------------ * Thu Sep 4 18:00:00 2008 Gerd Hoffmann - 0.44-1.fc10 - update to version 0.44 yakuake-2.9.4-1.fc10 -------------------- * Thu Sep 4 18:00:00 2008 Johan Cwiklinski - 2.9.4-1 - 2.9.4 - change BR from kdelibs4-devel to kdelibs-devel zaptel-1.4.12-1.fc10 -------------------- * Thu Sep 4 18:00:00 2008 Jeffrey C. Ollie - 1.4.12-1 - Update to 1.4.12 Summary: Added Packages: 1 Removed Packages: 0 Modified Packages: 88 Broken deps for i386 ---------------------------------------------------------- audacious-plugins-1.5.1-1.fc10.i386 requires libmtp.so.7 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 eclipse-photran-xlf-4.0.0-0.b4.fc10.2.i386 requires libvirt = 0:4.0.0 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 grisbi-0.5.9-5.fc9.i386 requires tetex-unicode gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.11-1.fc10.i386 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.i386 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.i386 requires perl(MT::Entry) highlight-2.6.11-1.fc10.i386 requires perl(MT) highlight-2.6.11-1.fc10.i386 requires perl(MT::Template::Context) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so poker3d-1.1.36-10.fc10.i386 requires libosg.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgUtil.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgSim.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgTerrain.so.35 poker3d-1.1.36-10.fc10.i386 requires libOpenThreads.so.10 poker3d-1.1.36-10.fc10.i386 requires libosgGA.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgFX.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgManipulator.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgDB.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgParticle.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgViewer.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgText.so.35 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for x86_64 ---------------------------------------------------------- audacious-plugins-1.5.1-1.fc10.x86_64 requires libmtp.so.7()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) eclipse-photran-xlf-4.0.0-0.b4.fc10.2.x86_64 requires libvirt = 0:4.0.0 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) grisbi-0.5.9-5.fc9.x86_64 requires tetex-unicode gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Entry) highlight-2.6.11-1.fc10.x86_64 requires perl(MT) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Template::Context) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgFX.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgGA.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgTerrain.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosg.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgSim.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgText.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgDB.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libOpenThreads.so.10()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgManipulator.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgParticle.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgViewer.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgUtil.so.35()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for ppc ---------------------------------------------------------- audacious-plugins-1.5.1-1.fc10.ppc requires libmtp.so.7 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 eclipse-photran-xlf-4.0.0-0.b4.fc10.2.ppc requires libvirt = 0:4.0.0 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) grisbi-0.5.9-5.fc9.ppc requires tetex-unicode gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.11-1.fc10.ppc requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc requires perl(MT::Entry) highlight-2.6.11-1.fc10.ppc requires perl(MT) highlight-2.6.11-1.fc10.ppc requires perl(MT::Template::Context) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so poker3d-1.1.36-10.fc10.ppc requires libosg.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgUtil.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgSim.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgTerrain.so.35 poker3d-1.1.36-10.fc10.ppc requires libOpenThreads.so.10 poker3d-1.1.36-10.fc10.ppc requires libosgGA.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgFX.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgManipulator.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgDB.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgParticle.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgViewer.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgText.so.35 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires libbfd-2.18.50.0.8-2.fc10.so stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires libopcodes-2.18.50.0.8-2.fc10.so vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for ppc64 ---------------------------------------------------------- audacious-plugins-1.5.1-1.fc10.ppc64 requires libmtp.so.7()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) grisbi-0.5.9-5.fc9.ppc64 requires tetex-unicode gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Entry) highlight-2.6.11-1.fc10.ppc64 requires perl(MT) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Template::Context) livecd-tools-018-1.fc10.ppc64 requires yaboot mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-Kwiki-0.39-3.fc9.noarch requires perl(HTTP::BrowserDetect) perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 poker3d-1.1.36-10.fc10.ppc64 requires libosgFX.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgGA.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgTerrain.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosg.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgSim.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgText.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgDB.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libOpenThreads.so.10()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgManipulator.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgParticle.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgViewer.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgUtil.so.35()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 From stefbon at gmail.com Fri Sep 5 11:54:05 2008 From: stefbon at gmail.com (Stef Bon) Date: Fri, 5 Sep 2008 13:54:05 +0200 Subject: A browseable networktree for access to SMB, FTP, SSH and other resources. Message-ID: <3c0132f00809050454j2ee0ed04r6931c5339bd90c29@mail.gmail.com> Hello all, I've been working on a construction to make access to networkresources easier, using autofs. The construction permits user access to networkresources like a Samba/Windows server with cifs, FTP servers using curlftpfs and SSH using sshfs (fuse), in one directory created with autofs. I'm sure more services like nfs and ipx are possible, but I did not test that. (in fact there should be a lookup utility, simular to nmblookup or nbtscan and a mount helper, and of course support in the kernel..) The construction creates a directory in your home directory like: /home/sbon/Global Network under which the different networks go: /home/sbon/Global Network/FTP SSH access Windows Network when browsing the Windows Network tree, you're able to select the workgroup, host and share. /home/sbon/Global Network/Windows Network/BONONLINE ROUTER bononline ftp public sbon CWWERKGROEP These shares are mounted when accessed, using cifs. The use of credentials is supported, guest access is the default. Cifs is supprting much more than the kioslaves or the Gnome VFS. For example oplocks, ACL's and inotify, which play an important role in the Windows networks, but I think you already know that... (and: a desktop manager should should not be involved with network services/filesystems) The tree is dynamically created using nbtscan (or nmblookup) and smbclient. I'm trying to write an article about this toppic, which should soon appear in the dutch Linux Magazine. What I'm asking is, are you interested in this construction? I'm very enthousiast about it, and I'm sure it has potential. Look for some information at the website: http://linux.bononline.nl/linux/automountsmbshares/index.php Information there is not ready yet, I'm working on that. Looking forward to your reply, Stef Bon Voorburg the Netherlands -------------- next part -------------- An HTML attachment was scrubbed... URL: From pertusus at free.fr Fri Sep 5 12:00:56 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 5 Sep 2008 14:00:56 +0200 Subject: A couple of license-relate questions In-Reply-To: References: Message-ID: <20080905120056.GA26218@free.fr> On Thu, Sep 04, 2008 at 10:11:58PM +0300, Vasile Gaburici wrote: > 1) If some files of a program are BSD and some are GPLv2, is it > necessary to include the BSD license file in the rpm package (even if > upstream doesn't)? No, it isn't, as Spot said. That's why I presented it only as a suggestion... -- Pat From pertusus at free.fr Fri Sep 5 12:15:32 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 5 Sep 2008 14:15:32 +0200 Subject: Dependency loops considered harmful? In-Reply-To: References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <20080904113210.4d1b2c83.mschwendt@gmail.com> Message-ID: <20080905121531.GC26218@free.fr> On Thu, Sep 04, 2008 at 01:31:56PM -0500, Matthew Woehlke wrote: > > ...which is, in a sense, the real problem. The issue as I see it is that > rolling an RPM takes a *lot* more time and effort than 'make install', > especially with CMake (2.6 does /very/ fast installs). It would be > REALLY GOOD to install everything as an rpm (not least because this > would clean up cruft from old builds!), but it needs to be fast, and it > needs to be do-able without using root privilege. Otherwise I think the > costs will outweigh the benefits for a lot of people. In many situations rolling a rpm doesn't make sense. An easy example is numerical models. You compile it, run it and there is absolutely no reason to make it a package. -- Pat From howard at cohtech.com Fri Sep 5 12:18:00 2008 From: howard at cohtech.com (Howard Wilkinson) Date: Fri, 05 Sep 2008 13:18:00 +0100 Subject: Kernel-headers from Fedora 8 updates missing ext3_fs.h Message-ID: <48C12378.1020900@cohtech.com> The build for kernel-headers from the latest Fedora 8 is missing linux/ext3_fs.h it would seem that the config in the i386 build does not pull it in. Does anybody know how I can alter the source RPM to get this and other missing headers loaded? From pertusus at free.fr Fri Sep 5 12:12:15 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 5 Sep 2008 14:12:15 +0200 Subject: help needed for a failed build, libnc-dap C++ In-Reply-To: <20080904173048.GA32528@localhost> References: <20080904161151.GD3366@free.fr> <20080904173048.GA32528@localhost> Message-ID: <20080905121215.GB26218@free.fr> On Thu, Sep 04, 2008 at 07:30:48PM +0200, Miroslav Lichvar wrote: > On Thu, Sep 04, 2008 at 06:11:51PM +0200, Patrice Dumas wrote: > > I have a package that fails to build since gcc 4.3, libnc-dap, and I am > > lost about what could be wrong. It is basically a library and a utility > > built on top of the library. When linking the utility, it gets: > > > > ../.libs/libnc-dap.so: undefined reference to `Connections::operator[](int)' > > The problem is that the function isn't used only in Dnc.cc (where > Connections.cc is included). Probably the easiest fix is to add the > following line somewhere in Dnc.cc and make it visible for other > modules. > > template NCConnect* & Connections::operator[](int i); Many thanks, it worked. Well, in fact I included the .cc file everywhere, now I'll let upstream do what they want to. -- Pat From stickster at gmail.com Fri Sep 5 12:53:42 2008 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 05 Sep 2008 12:53:42 +0000 Subject: Kernel-headers from Fedora 8 updates missing ext3_fs.h In-Reply-To: <48C12378.1020900@cohtech.com> References: <48C12378.1020900@cohtech.com> Message-ID: <1220619222.15437.28.camel@localhost.localdomain> On Fri, 2008-09-05 at 13:18 +0100, Howard Wilkinson wrote: > The build for kernel-headers from the latest Fedora 8 is missing > linux/ext3_fs.h it would seem that the config in the i386 build does not > pull it in. Does anybody know how I can alter the source RPM to get this > and other missing headers loaded? I think I answered this in the fedora-list thread: https://www.redhat.com/archives/fedora-list/2008-September/msg00559.html ...but not being much of a developer myself, would appreciate any other helpful advice. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lfarkas at lfarkas.org Fri Sep 5 13:40:59 2008 From: lfarkas at lfarkas.org (Farkas Levente) Date: Fri, 05 Sep 2008 15:40:59 +0200 Subject: MinGW on Fedora - an update In-Reply-To: <20080905113303.GA25742@amd.home.annexia.org> References: <20080905093031.GA25404@amd.home.annexia.org> <48C101C8.1000806@lfarkas.org> <20080905113303.GA25742@amd.home.annexia.org> Message-ID: <48C136EB.9000703@lfarkas.org> Richard W.M. Jones wrote: > On Fri, Sep 05, 2008 at 11:54:16AM +0200, Farkas Levente wrote: >> Richard W.M. Jones wrote: >>> Dan Berrange (in particular) and myself (a little) have done quite a >>> bit more work on mingw in Fedora. >>> >>> We now have: >>> - automatic dependency generation >>> - automatic stripping of binaries >>> - a collection of RPM macros which simplify writing spec files >>> - ~10 working libraries >>> >>> Anyway, check out the development repository: >>> http://hg.et.redhat.com/misc/fedora-mingw--devel/ >>> >>> Please read the README file first! >> ETA into fedora? > > As Dan said, but don't let that stop you if you want to download and > play with it, and send patches :-) It's currently buildable on > Rawhide, and possibly on earlier versions of Fedora too. actually we use and older version of mingw on rhel: http://www.lfarkas.org/linux/packages/redhat/5/i386/ which works, but i'd like to test these new packages too. for me it'd be much better if you can upload somewhere your src.rpm files and i can try to rebuild them on rhel-5 (and may be other win32 packages like openssl, gdk, glib, gtk, etc.). -- Levente "Si vis pacem para bellum!" From pertusus at free.fr Fri Sep 5 13:37:02 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 5 Sep 2008 15:37:02 +0200 Subject: Heads-up: libdap and libnc-dap updates Message-ID: <20080905133702.GF26218@free.fr> Hello, I would like to update libnc-dap to the latest version, and for that it requires a more recent libdap, which is both ABI and API incompatible. libnc-dap should be ABI compatible. My proposal, to avoid having to rebuild everything at once and provide for an easy upgrade path is to provide a compat package: http://www.environnement.ens.fr/perso/dumas/fc-srpms/libdap3710-3.7.10-1.fc10.src.rpm http://www.environnement.ens.fr/perso/dumas/fc-srpms/libdap3710.spec Does it looks good? I don't want to do devel compat package, I don't think it is needed, and this compat package should be removed in F12 or so. I will do the submission if no one raises issues. After that, it would be nice if application linked against libnc-dap would be rebuilt, since libnc-dap now uses pckgonfig and previously it was possible that it added spurious link on unneeded libraries, leading to unneeded dependencies. I cannot provide a list of packages dependent on libdap-devel and libc-dap-devel since repoquery crashes here. -- Pat From orion at cora.nwra.com Fri Sep 5 13:59:43 2008 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Fri, 5 Sep 2008 07:59:43 -0600 (MDT) Subject: rawhide report: 20080905 changes In-Reply-To: <20080905113951.CB3701F8230@releng2.fedora.phx.redhat.com> References: <20080905113951.CB3701F8230@releng2.fedora.phx.redhat.com> Message-ID: <2971.71.208.78.10.1220623183.squirrel@www.cora.nwra.com> > Broken deps for i386 > ---------------------------------------------------------- > eclipse-photran-xlf-4.0.0-0.b4.fc10.2.i386 requires libvirt = 0:4.0.0 ? Build logs are here: http://kojipkgs.fedoraproject.org/packages/eclipse-photran/4.0.0/0.b4.fc10.2/data/logs/i386/ No mention of libvirt.... - Orion From sandeen at redhat.com Fri Sep 5 14:04:20 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Fri, 05 Sep 2008 09:04:20 -0500 Subject: Kernel-headers from Fedora 8 updates missing ext3_fs.h In-Reply-To: <1220619222.15437.28.camel@localhost.localdomain> References: <48C12378.1020900@cohtech.com> <1220619222.15437.28.camel@localhost.localdomain> Message-ID: <48C13C64.6060806@redhat.com> Paul W. Frields wrote: > On Fri, 2008-09-05 at 13:18 +0100, Howard Wilkinson wrote: >> The build for kernel-headers from the latest Fedora 8 is missing >> linux/ext3_fs.h it would seem that the config in the i386 build does not >> pull it in. Does anybody know how I can alter the source RPM to get this >> and other missing headers loaded? > > I think I answered this in the fedora-list thread: > https://www.redhat.com/archives/fedora-list/2008-September/msg00559.html > ...but not being much of a developer myself, would appreciate any other > helpful advice. > > it's not in kernel-headers because it is not listed in the headers-y list in include/linux/Kbuild, i.e. not intended to be exporting anything for userspace use. /usr/include/ext2fs/ext2_fs.h from e2fsprogs-devel is likely what you really want. What do you need the ext3_fs.h header for? Thanks, -Eric From orion at cora.nwra.com Fri Sep 5 14:22:33 2008 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Fri, 5 Sep 2008 08:22:33 -0600 (MDT) Subject: Heads-up: libdap and libnc-dap updates In-Reply-To: <20080905133702.GF26218@free.fr> References: <20080905133702.GF26218@free.fr> Message-ID: <3090.71.208.78.10.1220624553.squirrel@www.cora.nwra.com> > Hello, > > I would like to update libnc-dap to the latest version, and for that it > requires a more recent libdap, which is both ABI and API incompatible. > libnc-dap should be ABI compatible. > > My proposal, to avoid having to rebuild everything at once and provide > for an easy upgrade path is to provide a compat package: > http://www.environnement.ens.fr/perso/dumas/fc-srpms/libdap3710-3.7.10-1.fc10.src.rpm > http://www.environnement.ens.fr/perso/dumas/fc-srpms/libdap3710.spec > > Does it looks good? > > I don't want to do devel compat package, I don't think it is needed, > and this compat package should be removed in F12 or so. > > I will do the submission if no one raises issues. > > After that, it would be nice if application linked against libnc-dap > would be rebuilt, since libnc-dap now uses pckgonfig and previously it > was possible that it added spurious link on unneeded libraries, leading > to unneeded dependencies. > > I cannot provide a list of packages dependent on libdap-devel and > libc-dap-devel since repoquery crashes here. Users: libdap: bes/bes.spec:BuildRequires: libdap-devel >= 3.7.10 dap-freeform_handler/dap-freeform_handler.spec:BuildRequires: libdap-devel >= 3.7.10 dap-hdf4_handler/dap-hdf4_handler.spec:BuildRequires: libdap-devel >= 3.7.5 hdf-devel dap-netcdf_handler/dap-netcdf_handler.spec:BuildRequires: libdap-devel >= 3.7.10 netcdf-devel dap-server/dap-server.spec:BuildRequires: libdap-devel >= 3.7.10 gdal/gdal.spec:BuildRequires: jasper-devel cfitsio-devel hdf-devel libdap-devel librx-devel libnc-dap/libnc-dap.spec:BuildRequires: libdap-devel >= 3.7.3 gcc-gfortran libnc-dap (shouldn't need work, right?): grads/grads.spec:BuildRequires: libnc-dap-devel ncl/ncl.spec:BuildRequires: g2clib-devel, libnc-dap-devel, librx-devel, atlas-devel nco/nco.spec:BuildRequires: netcdf-devel, libnc-dap-devel octave-forge/octave-forge.spec:BuildRequires: ImageMagick-c++-devel libnc-dap-devel pcre-devel gsl-devel Seems pretty small, and you already seem to maintain many (most) of them. How hard would it be to port to the new libdap and just skip the compat package? I've CC'ed Balint who maintains gdal. I maintain ncl. - Orion From mschwendt at gmail.com Fri Sep 5 14:24:10 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 5 Sep 2008 16:24:10 +0200 Subject: rawhide report: 20080905 changes In-Reply-To: <2971.71.208.78.10.1220623183.squirrel@www.cora.nwra.com> References: <20080905113951.CB3701F8230@releng2.fedora.phx.redhat.com> <2971.71.208.78.10.1220623183.squirrel@www.cora.nwra.com> Message-ID: <20080905162410.ebe44891.mschwendt@gmail.com> On Fri, 5 Sep 2008 07:59:43 -0600 (MDT), orion at cora.nwra.com wrote: > > Broken deps for i386 > > ---------------------------------------------------------- > > eclipse-photran-xlf-4.0.0-0.b4.fc10.2.i386 requires libvirt = 0:4.0.0 > > ? > > Build logs are here: > > http://kojipkgs.fedoraproject.org/packages/eclipse-photran/4.0.0/0.b4.fc10.2/data/logs/i386/ > > No mention of libvirt.... ? In the spec file: %package xlf Summary: IBM XL Fortran compiler support for Photran Group: Development/Libraries Requires: libvirt = %{version} %description xlf %{summary}. From pertusus at free.fr Fri Sep 5 14:32:20 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 5 Sep 2008 16:32:20 +0200 Subject: Heads-up: libdap and libnc-dap updates In-Reply-To: <3090.71.208.78.10.1220624553.squirrel@www.cora.nwra.com> References: <20080905133702.GF26218@free.fr> <3090.71.208.78.10.1220624553.squirrel@www.cora.nwra.com> Message-ID: <20080905143219.GG26218@free.fr> On Fri, Sep 05, 2008 at 08:22:33AM -0600, orion at cora.nwra.com wrote: > > libnc-dap (shouldn't need work, right?): No, but a rebuild should remove unneeded dependencies if there are some. However, if there is an (unneeded) dependency on libdap itself, which was the case before, they will need a rebuild if there is no compat package. > grads/grads.spec:BuildRequires: libnc-dap-devel > ncl/ncl.spec:BuildRequires: g2clib-devel, libnc-dap-devel, librx-devel, > atlas-devel > nco/nco.spec:BuildRequires: netcdf-devel, libnc-dap-devel > octave-forge/octave-forge.spec:BuildRequires: ImageMagick-c++-devel > libnc-dap-devel pcre-devel gsl-devel > > > Seems pretty small, and you already seem to maintain many (most) of them. > How hard would it be to port to the new libdap and just skip the compat > package? I've CC'ed Balint who maintains gdal. I maintain ncl. There is only gdal which is not maintained by me in the libdap dependencies. But I will need to rebuild deverything using make chain-build but this is not practical because there are many packages to update at once. Since this time it is more than a rebuild, I thought that doing a compat-package would be more convenient (I use that compat package locally since a long time now). -- Pat From orion at cora.nwra.com Fri Sep 5 14:36:51 2008 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Fri, 5 Sep 2008 08:36:51 -0600 (MDT) Subject: rawhide report: 20080905 changes In-Reply-To: <20080905162410.ebe44891.mschwendt@gmail.com> References: <20080905113951.CB3701F8230@releng2.fedora.phx.redhat.com> <2971.71.208.78.10.1220623183.squirrel@www.cora.nwra.com> <20080905162410.ebe44891.mschwendt@gmail.com> Message-ID: <3156.71.208.78.10.1220625411.squirrel@www.cora.nwra.com> > On Fri, 5 Sep 2008 07:59:43 -0600 (MDT), orion at cora.nwra.com wrote: > >> > Broken deps for i386 >> > ---------------------------------------------------------- >> > eclipse-photran-xlf-4.0.0-0.b4.fc10.2.i386 requires libvirt = 0:4.0.0 >> >> ? >> >> Build logs are here: >> >> http://kojipkgs.fedoraproject.org/packages/eclipse-photran/4.0.0/0.b4.fc10.2/data/logs/i386/ >> >> No mention of libvirt.... > > ? > > In the spec file: > > %package xlf > Summary: IBM XL Fortran compiler support for Photran > Group: Development/Libraries > Requires: libvirt = %{version} What's the emoticon for extreme embarassment? :-) Gah, what kind of vim buffer/brain fart did that come from? Thanks.... - Orion From howard at cohtech.com Fri Sep 5 14:48:58 2008 From: howard at cohtech.com (Howard Wilkinson) Date: Fri, 05 Sep 2008 15:48:58 +0100 Subject: Kernel-headers from Fedora 8 updates missing ext3_fs.h In-Reply-To: <48C13C64.6060806@redhat.com> References: <48C12378.1020900@cohtech.com> <1220619222.15437.28.camel@localhost.localdomain> <48C13C64.6060806@redhat.com> Message-ID: <48C146DA.9040303@cohtech.com> Eric Sandeen wrote: > Paul W. Frields wrote: > >> On Fri, 2008-09-05 at 13:18 +0100, Howard Wilkinson wrote: >> >>> The build for kernel-headers from the latest Fedora 8 is missing >>> linux/ext3_fs.h it would seem that the config in the i386 build does not >>> pull it in. Does anybody know how I can alter the source RPM to get this >>> and other missing headers loaded? >>> >> I think I answered this in the fedora-list thread: >> https://www.redhat.com/archives/fedora-list/2008-September/msg00559.html >> ...but not being much of a developer myself, would appreciate any other >> helpful advice. >> >> >> > > it's not in kernel-headers because it is not listed in the headers-y > list in include/linux/Kbuild, i.e. not intended to be exporting anything > for userspace use. > > /usr/include/ext2fs/ext2_fs.h from e2fsprogs-devel is likely what you > really want. > > What do you need the ext3_fs.h header for? > > Thanks, > > -Eric > > I am trying to rebuild the anaconda package and it uses ext3_fs.h! I have got around this by downgrading the kernel temporarily but that is obviously not a good idea! -------------- next part -------------- An HTML attachment was scrubbed... URL: From sandeen at redhat.com Fri Sep 5 15:44:18 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Fri, 05 Sep 2008 10:44:18 -0500 Subject: Kernel-headers from Fedora 8 updates missing ext3_fs.h In-Reply-To: <48C146DA.9040303@cohtech.com> References: <48C12378.1020900@cohtech.com> <1220619222.15437.28.camel@localhost.localdomain> <48C13C64.6060806@redhat.com> <48C146DA.9040303@cohtech.com> Message-ID: <48C153D2.1070207@redhat.com> Howard Wilkinson wrote: >> What do you need the ext3_fs.h header for? >> >> Thanks, >> >> -Eric >> >> > I am trying to rebuild the anaconda package and it uses ext3_fs.h! I > have got around this by downgrading the kernel temporarily but that is > obviously not a good idea! > bleah, well, it probably shouldn't. :) And recent anaconda doesn't seem to. FWIW I think it (isys.c) only needs it for this define: /usr/include/linux/ext2_fs.h:#define EXT3_FEATURE_COMPAT_HAS_JOURNAL 0x0004 which is also available from the "right" place :) -Eric From Matt_Domsch at dell.com Fri Sep 5 15:40:06 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 5 Sep 2008 10:40:06 -0500 Subject: Proposed removal of packages with long-standing FTBFS failures Message-ID: <20080905154006.GA23967@auslistsprd01.us.dell.com> The following 90 packages have had FTBFS (Fails to Build From Source) failures for several months, some as far back as February 2008. There are several "trivial" failures which could be addressed easily. 8 fail due to unpackaged files 6 fail due to patch fuzz 1 fails due to open() not passing a mode. http://fedoraproject.org/wiki/FTBFS describes the FTBFS process. As was proposed to FESCO, packages with unresolved FTBFS bugs immediately following the Alpha release will be removed from the distribution. Package owners may request that their package _not_ be removed provided they are actively working on resolving the FTBFS and have a plan to resolve the FTBFS before the Release Candidate release. FESCo has the final say of course, but these are the items on my candidate list. I'd prefer packages get fixed rather than removed. If you are the package owner, or are interested in the future of these packages, please investigate these build failures and fix them ASAP. aiksaurus-1.2.1-15.fc6 [u'434484 ASSIGNED'] (build/make) uwog astyle-1.21-6.fc8 [u'433971 ASSIGNED'] (build/make) addutko,mtasaka aterm-1.0.1-2.fc9 [u'440779 ASSIGNED'] (build/make) awjb bes-3.5.3-3.fc9 [u'434360 ASSIGNED'] (build/make) pertusus bitbake-1.8.8-1.fc8 [u'440562 ASSIGNED'] (build/make) ixs bmpx-0.40.14-5.fc9 [u'449431 ASSIGNED'] (patch_fuzz) akahl brltty-3.9-2.2.fc9 [u'449446 ASSIGNED'] (build/make) kasal brutus-keyring-0.9.0-6.fc8 [u'434007 ASSIGNED'] (build/make) bpepple,colding camstream-0.26.3-12.fc8 [u'434345 ASSIGNED'] (build/make) nomis80 coolkey-1.1.0-6.fc9 [u'440753 ASSIGNED'] (build/make) rrelyea,jmagne dap-freeform_handler-3.7.7-2.fc9 [u'434362 ASSIGNED'] (build/make) pertusus dap-hdf4_handler-3.7.7-3.fc9 [u'434363 ASSIGNED'] (build/make) pertusus djvulibre-3.5.20-2.fc9 [u'440910 ASSIGNED'] (build/make) thias elektra-0.6.10-6.fc9 [u'434364 ASSIGNED'] (build/make) pertusus,kwizart erlang-R12B-3.1.fc10 [u'449432 ASSIGNED'] (patch_fuzz) gemi fish-1.23.0-2.fc9 [u'440724 ASSIGNED'] (build/make) ascii,oliver fluxstyle-1.0.1-2.fc7 [u'440757 ASSIGNED'] (build/make) errr fonttools-2.0-0.11.20060223cvs.fc7 [u'434409 ASSIGNED'] (unpackaged_files/python-egg-info?) roozbeh,fonts-sig fontypython-0.2.0-6.fc7 [u'440756 ASSIGNED'] (build/make) cr33dog,fonts-sig fwbuilder-2.1.16-2.fc9 [u'440846 ASSIGNED'] (build/make) ertzing gauche-0.8.13-1.fc9 [u'449627 ASSIGNED'] (build/make) gemi gcl-2.6.7-18.fc9 [u'440913 ASSIGNED'] (build/make) gemi,green gdmap-0.7.5-6.fc6 [u'434529 ASSIGNED'] (build/make) splinux gpsim-0.22.0-5.fc8 [u'434061 ASSIGNED'] (build/make) dionysos gstm-1.2-6.fc7 [u'434531 ASSIGNED'] (build/make) splinux gtk-sharp-1.0.10-12.fc7 [u'434373 ASSIGNED'] (unpackaged_files/python-egg-info?) pfj guile-gnome-platform-2.15.93-6.fc8 [u'434289 ASSIGNED'] (build/make) laxathom g-wrap-1.9.9-5.fc9 [u'434278 ASSIGNED'] (patch_fuzz) laxathom HelixPlayer-1.0.9-4.fc10 [u'449474 ASSIGNED'] (patch_fuzz) abompard ht2html-2.0-5.fc6 [u'440916 ASSIGNED'] (build/make) ifoox itpp-4.0.0-2.fc9 [u'434076 ASSIGNED'] (build/make) edhill jabbin-2.0-0.6.beta2a.fc9 [u'440730 ASSIGNED'] (build/make) jgroups-2.2.9.2-3jpp.2 [u'434352 ASSIGNED'] (build/make) dbhole kdebluetooth-1.0-0.41.beta8.fc9 [u'449604 ASSIGNED'] (build/make) gilboa,scop ladspa-1.12-9.fc9 [u'449542 ASSIGNED'] (build/make) thomasvs libdap-3.7.10-2.fc9 [u'434366 ASSIGNED'] (build/make) pertusus libFoundation-1.1.3-11.fc9 [u'440564 ASSIGNED'] (build/make) athimm libfwbuilder-2.1.16-2.fc9 [u'449591 ASSIGNED'] (build/make) ertzing libnc-dap-3.7.0-9.fc9 [u'434367 ASSIGNED'] (build/make) pertusus libopensync-0.36-2.fc9 [u'449510 ASSIGNED'] (build/make) awjb libzzub-0.2.3-12.fc9 [u'449661 ASSIGNED'] (patch_fuzz) akahl,mtasaka lilypond-2.10.33-1.fc8 [u'434394 ASSIGNED'] (build/make) limb lineakd-0.9-5.fc6 [u'434523 ASSIGNED'] (build/make) xris lineak-defaultplugin-0.9-2.fc6 [u'434520 ASSIGNED'] (build/make) xris lineak-xosdplugin-0.9-2.fc6 [u'434522 ASSIGNED'] (build/make) xris linpsk-0.9-3.fc9 [u'440778 ASSIGNED'] (build/make) bjensen,sindrepb,sconklin linux-atm-2.5.0-5 [u'434069 ASSIGNED', u'449613 ASSIGNED'] (build/make) dwmw2 lostirc-0.4.6-3.fc8 [u'440921 ASSIGNED'] (build/make) splinux,splinux lrmi-0.10-4.fc9 [u'449509 ASSIGNED'] (build/make) pwouters mimetic-0.9.3-2.fc8 [u'434086 ASSIGNED'] (build/make) ensc mod_suphp-0.6.3-1.fc9 [u'449578 ASSIGNED'] (build/make) ixs monodevelop-0.19-6.fc9 [u'449441 ASSIGNED'] (build/make) pfj mosml-2.01-11.fc9 [u'449445 ASSIGNED'] (build/make) gemi moto4lin-0.3-6.fc7 [u'434135 ASSIGNED'] (build/make) jafo muine-scrobbler-0.1.8-5.fc9 [u'449482 ASSIGNED'] (build/make) sindrepb mx-2.0.6-3 [u'434325 ASSIGNED'] (unpackaged_files/python-egg-info?) misa mysql-gui-tools-5.0r12-8.fc9 [u'440734 ASSIGNED', u'433987 ASSIGNED'] (patch_fuzz) ausil ntfs-config-1.0-0.6.rc5.fc9 [u'449585 ASSIGNED'] (build/make) laxathom oggconvert-0.3.0-14.fc9 [u'440943 ASSIGNED'] (unpackaged_files/python-egg-info?) ngompa pan-0.132-2.fc8 [u'433970 ASSIGNED'] (build/make) adalloz,mpeters pcmanx-gtk2-0.3.5-9.336svn.fc7 [u'434299 ASSIGNED'] (open_missing_mode) leo pdsh-2.11-6.fc9 [u'440811 ASSIGNED'] (build/make) kg6fnk pekwm-0.1.5-5.fc7 [u'434089 ASSIGNED'] (build/make) errr perl-MIME-Lite-3.01-6.fc9 [u'449558 ASSIGNED'] (build/make) mmcgrath,perl-sig petitboot-0.0.1-7.fc8 [u'434071 ASSIGNED'] (build/make) dwmw2,jwboyer pic2aa-0.2.1-3.fc9 [u'440764 ASSIGNED'] (build/make) kurzawa pl-5.6.57-2.fc10 [u'434110 ASSIGNED'] (build/make) gemi,mef plotmm-0.1.2-6.fc9 [u'440563 ASSIGNED'] (build/make) hguemar plplot-5.9.0-1.fc9 [u'449488 ASSIGNED'] (build/make) orion python-durus-3.5-3.fc7 [u'434427 MODIFIED'] (build/make) shahms python-memcached-1.39-1.fc8 [u'440931 ASSIGNED'] (unpackaged_files/python-egg-info?) jafo python-pydns-2.3.0-5.fc7 [u'440912 ASSIGNED'] (unpackaged_files/python-egg-info?) jafo python-pyspf-2.0.3-1.fc8 [u'440793 ASSIGNED'] (unpackaged_files/python-egg-info?) jafo python-simpletal-4.1-5.fc7 [u'440930 ASSIGNED'] (build/make) shahms python-tpg-3.1.0-4.fc7 [u'440763 ASSIGNED'] (build/make) shahms qa-assistant-0.4.90.5-2.fc6 [u'440914 ASSIGNED'] (build/make) toshio qcad-2.0.5.0-8.fc9 [u'449636 ASSIGNED'] (build/make) gemi qps-1.9.19-0.2.b.fc7 [u'434312 ASSIGNED'] (build/make) makghosh qsynth-0.2.5-7.fc9 [u'440736 ASSIGNED'] (build/make) nando qtiplot-0.9-8.fc9 [u'434100 ASSIGNED'] (build/make) frankb R-Matrix-0.999375-4.fc9 [u'449530 ASSIGNED'] (build/make) tmoertel ruby-bdb-0.6.0-1.fc7 [u'434090 ASSIGNED'] (build/make) errr rudeconfig-5.0.5-1.fc7 [u'434131 ASSIGNED'] (build/make) homeless scim-skk-0.5.2-8.fc6 [u'434419 ASSIGNED'] (build/make) ryo sos-1.8-1.fc8 [u'440839 ASSIGNED'] (unpackaged_files/python-egg-info?) navid straw-0.27-12.fc9 [u'440806 ASSIGNED'] (build/make) subhodip svnmailer-1.0.8-3.fc7 [u'449666 ASSIGNED'] (build/make) mfleming xml-commons-resolver-1.1-1jpp.12 [u'434098 ASSIGNED'] (build/make) fnasser yoltia-0.22.1-2.fc9 [u'440935 ASSIGNED'] (build/make) kurzawa -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From berrange at redhat.com Fri Sep 5 15:55:39 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 5 Sep 2008 16:55:39 +0100 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <20080905155539.GP22542@redhat.com> On Fri, Sep 05, 2008 at 10:40:06AM -0500, Matt Domsch wrote: > The following 90 packages have had FTBFS (Fails to Build From Source) > failures for several months, some as far back as February 2008. > > There are several "trivial" failures which could be addressed easily. > 8 fail due to unpackaged files > 6 fail due to patch fuzz > 1 fails due to open() not passing a mode. > > http://fedoraproject.org/wiki/FTBFS describes the FTBFS process. > > As was proposed to FESCO, packages with unresolved FTBFS bugs > immediately following the Alpha release will be removed from the > distribution. Package owners may request that their package _not_ be > removed provided they are actively working on resolving the FTBFS and > have a plan to resolve the FTBFS before the Release Candidate > release. FESCo has the final say of course, but these are the items > on my candidate list. I'd prefer packages get fixed rather than > removed. If you are the package owner, or are interested in the > future of these packages, please investigate these build failures and > fix them ASAP. This list is far from complete - if you want to remove these 90, the dependancy chain ripple, will entail the removal of tonnes of other packages which depend on these. Any chance you can generate a report which shows the ripple effect for each proposed package. If something is just a leaf-node, it isn't very important to worry about, but if something triggers removal of 50 dependant packages that's pretty damn important to fix. This info would be useful in prioritizing which builds need fixing most urgently. > perl-MIME-Lite-3.01-6.fc9 [u'449558 ASSIGNED'] (build/make) mmcgrath,perl-sig Taking this one as an example on my f9 install # repoquery --whatrequires 'perl(MIME::Lite)' perl-Log-Dispatch-0:2.21-1.fc9.noarch perl-SOAP-Lite-0:0.710.07-1.fc9.noarch perl-SOAP-Lite-0:0.68-6.fc9.noarch perl-MIME-Lite-0:3.01-6.fc9.noarch Then picking one of those deps... # repoquery --whatrequires 'perl(SOAP::Lite)' mythweather-0:0.21-7.lvn9.i386 perl-bioperl-0:1.5.2_102-12.fc9.noarch openoffice.org-devel-1:2.4.0-12.8.fc9.i386 perl-SOAP-Lite-0:0.710.07-1.fc9.noarch perl-Apache2-SOAP-0:0.73-1.fc9.noarch perl-POE-Component-Server-SOAP-0:1.11-3.fc9.noarch openoffice.org-devel-1:2.4.1-17.4.fc9.i386 amtterm-0:1.0-2.fc9.i386 perl-SOAP-Lite-0:0.68-6.fc9.noarch ...and so on I don't think we can really kill off perl-MIME-Lite if it implies killing off openoffice via dependancies. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From ndbecker2 at gmail.com Fri Sep 5 15:55:55 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 05 Sep 2008 11:55:55 -0400 Subject: yum update problem from fresh F9-i386 Message-ID: Brand new install of F9-i386: yum update ... PackageKit-libs-0.1.12-10.20080505.fc9.i386 from installed has depsolving problems --> Missing Dependency: PackageKit = 0.1.12-10.20080505.fc9 is needed by package PackageKit-libs-0.1.12-10.20080505.fc9.i386 (installed) 1:perl-Pod-Escapes-1.04-20.fc9.i386 from installed has depsolving problems --> Missing Dependency: perl = 4:5.10.0-20.fc9 is needed by package 1:perl-Pod-Escapes-1.04-20.fc9.i386 (installed) 1:perl-Module-Pluggable-3.60-20.fc9.i386 from installed has depsolving problems --> Missing Dependency: perl = 4:5.10.0-20.fc9 is needed by package 1:perl-Module-Pluggable-3.60-20.fc9.i386 (installed) gnome-python2-bonobo-2.22.0-2.fc9.i386 from installed has depsolving problems --> Missing Dependency: gnome-python2 = 2.22.0-2.fc9 is needed by package gnome-python2-bonobo-2.22.0-2.fc9.i386 (installed) Error: Missing Dependency: perl = 4:5.10.0-20.fc9 is needed by package 1:perl-Pod-Escapes-1.04-20.fc9.i386 (installed) Error: Missing Dependency: PackageKit = 0.1.12-10.20080505.fc9 is needed by package PackageKit-libs-0.1.12-10.20080505.fc9.i386 (installed) Error: Missing Dependency: gnome-python2 = 2.22.0-2.fc9 is needed by package gnome-python2-bonobo-2.22.0-2.fc9.i386 (installed) Error: Missing Dependency: perl = 4:5.10.0-20.fc9 is needed by package 1:perl-Module-Pluggable-3.60-20.fc9.i386 (installed) From skvidal at fedoraproject.org Fri Sep 5 15:56:53 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 05 Sep 2008 11:56:53 -0400 Subject: yum update problem from fresh F9-i386 In-Reply-To: References: Message-ID: <1220630213.17785.62.camel@rosebud> On Fri, 2008-09-05 at 11:55 -0400, Neal Becker wrote: > Brand new install of F9-i386: > yum update > ... > PackageKit-libs-0.1.12-10.20080505.fc9.i386 from installed has depsolving problems > --> Missing Dependency: PackageKit = 0.1.12-10.20080505.fc9 is needed by package PackageKit-libs-0.1.12-10.20080505.fc9.i386 (installed) > 1:perl-Pod-Escapes-1.04-20.fc9.i386 from installed has depsolving problems > --> Missing Dependency: perl = 4:5.10.0-20.fc9 is needed by package 1:perl-Pod-Escapes-1.04-20.fc9.i386 (installed) > 1:perl-Module-Pluggable-3.60-20.fc9.i386 from installed has depsolving problems > --> Missing Dependency: perl = 4:5.10.0-20.fc9 is needed by package 1:perl-Module-Pluggable-3.60-20.fc9.i386 (installed) > gnome-python2-bonobo-2.22.0-2.fc9.i386 from installed has depsolving problems > --> Missing Dependency: gnome-python2 = 2.22.0-2.fc9 is needed by package gnome-python2-bonobo-2.22.0-2.fc9.i386 (installed) > Error: Missing Dependency: perl = 4:5.10.0-20.fc9 is needed by package 1:perl-Pod-Escapes-1.04-20.fc9.i386 (installed) > Error: Missing Dependency: PackageKit = 0.1.12-10.20080505.fc9 is needed by package PackageKit-libs-0.1.12-10.20080505.fc9.i386 (installed) > Error: Missing Dependency: gnome-python2 = 2.22.0-2.fc9 is needed by package gnome-python2-bonobo-2.22.0-2.fc9.i386 (installed) > Error: Missing Dependency: perl = 4:5.10.0-20.fc9 is needed by package 1:perl-Module-Pluggable-3.60-20.fc9.i386 (installed) try: yum update yum then do it again. -sv From mclasen at redhat.com Fri Sep 5 15:59:21 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 05 Sep 2008 11:59:21 -0400 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <1220630361.4220.12.camel@localhost.localdomain> On Fri, 2008-09-05 at 10:40 -0500, Matt Domsch wrote: > djvulibre-3.5.20-2.fc9 [u'440910 ASSIGNED'] (build/make) thias djvulibre-devel is a BuildRequires for evince. If you remove djvulibre, evince will become unbuildable. From orion at cora.nwra.com Fri Sep 5 15:59:15 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 05 Sep 2008 09:59:15 -0600 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <48C15753.7000500@cora.nwra.com> Matt Domsch wrote: > The following 90 packages have had FTBFS (Fails to Build From Source) > failures for several months, some as far back as February 2008. > plplot-5.9.0-1.fc9 [u'449488 ASSIGNED'] (build/make) orion I *am* working on this. plplot is crazy complex (something like 10 different language bindings, multiple output libraries). I am pretty close to a working version and a working version will be in by the freeze. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From jkeating at redhat.com Fri Sep 5 16:06:28 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 05 Sep 2008 09:06:28 -0700 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <1220630361.4220.12.camel@localhost.localdomain> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <1220630361.4220.12.camel@localhost.localdomain> Message-ID: <1220630788.4273.10.camel@luminos.localdomain> On Fri, 2008-09-05 at 11:59 -0400, Matthias Clasen wrote: > djvulibre-devel is a BuildRequires for evince. > If you remove djvulibre, evince will become unbuildable. Then perhaps you or somebody from your team should work on this package. If we have to do a chained rebuild for various reasons, evince would fail due to this package not building first. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kanarip at kanarip.com Fri Sep 5 16:06:33 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Fri, 05 Sep 2008 18:06:33 +0200 Subject: Kernel-headers from Fedora 8 updates missing ext3_fs.h In-Reply-To: <48C153D2.1070207@redhat.com> References: <48C12378.1020900@cohtech.com> <1220619222.15437.28.camel@localhost.localdomain> <48C13C64.6060806@redhat.com> <48C146DA.9040303@cohtech.com> <48C153D2.1070207@redhat.com> Message-ID: <48C15909.40509@kanarip.com> Eric Sandeen wrote: > Howard Wilkinson wrote: > >>> What do you need the ext3_fs.h header for? >>> >>> Thanks, >>> >>> -Eric >>> >>> >> I am trying to rebuild the anaconda package and it uses ext3_fs.h! I >> have got around this by downgrading the kernel temporarily but that is >> obviously not a good idea! >> > > bleah, well, it probably shouldn't. :) And recent anaconda doesn't > seem to. > Attached is a patch to the anaconda package applicable to the F-8 branch. This should make it build again. FWIW, there's more things in Fedora 8 fixed later in rawhide, but never ported back. See http://git.kanarip.com/?p=anaconda;a=shortlog;h=f8-branch-maintenance for more info (clone from git://git.kanarip.com/anaconda) Kind regards, Jeroen van Meeuwen -kanarip -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-includes.patch Type: text/x-patch Size: 489 bytes Desc: not available URL: From paul at city-fan.org Fri Sep 5 16:09:49 2008 From: paul at city-fan.org (Paul Howarth) Date: Fri, 05 Sep 2008 17:09:49 +0100 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905155539.GP22542@redhat.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <20080905155539.GP22542@redhat.com> Message-ID: <48C159CD.4000704@city-fan.org> Daniel P. Berrange wrote: > On Fri, Sep 05, 2008 at 10:40:06AM -0500, Matt Domsch wrote: >> The following 90 packages have had FTBFS (Fails to Build From Source) >> failures for several months, some as far back as February 2008. >> >> There are several "trivial" failures which could be addressed easily. >> 8 fail due to unpackaged files >> 6 fail due to patch fuzz >> 1 fails due to open() not passing a mode. >> >> http://fedoraproject.org/wiki/FTBFS describes the FTBFS process. >> >> As was proposed to FESCO, packages with unresolved FTBFS bugs >> immediately following the Alpha release will be removed from the >> distribution. Package owners may request that their package _not_ be >> removed provided they are actively working on resolving the FTBFS and >> have a plan to resolve the FTBFS before the Release Candidate >> release. FESCo has the final say of course, but these are the items >> on my candidate list. I'd prefer packages get fixed rather than >> removed. If you are the package owner, or are interested in the >> future of these packages, please investigate these build failures and >> fix them ASAP. > > This list is far from complete - if you want to remove these 90, the > dependancy chain ripple, will entail the removal of tonnes of other > packages which depend on these. > > Any chance you can generate a report which shows the ripple effect > for each proposed package. If something is just a leaf-node, it isn't > very important to worry about, but if something triggers removal > of 50 dependant packages that's pretty damn important to fix. This > info would be useful in prioritizing which builds need fixing most > urgently. > >> perl-MIME-Lite-3.01-6.fc9 [u'449558 ASSIGNED'] (build/make) mmcgrath,perl-sig > > Taking this one as an example on my f9 install > > # repoquery --whatrequires 'perl(MIME::Lite)' > perl-Log-Dispatch-0:2.21-1.fc9.noarch > perl-SOAP-Lite-0:0.710.07-1.fc9.noarch > perl-SOAP-Lite-0:0.68-6.fc9.noarch > perl-MIME-Lite-0:3.01-6.fc9.noarch > > Then picking one of those deps... > > # repoquery --whatrequires 'perl(SOAP::Lite)' > mythweather-0:0.21-7.lvn9.i386 > perl-bioperl-0:1.5.2_102-12.fc9.noarch > openoffice.org-devel-1:2.4.0-12.8.fc9.i386 > perl-SOAP-Lite-0:0.710.07-1.fc9.noarch > perl-Apache2-SOAP-0:0.73-1.fc9.noarch > perl-POE-Component-Server-SOAP-0:1.11-3.fc9.noarch > openoffice.org-devel-1:2.4.1-17.4.fc9.i386 > amtterm-0:1.0-2.fc9.i386 > perl-SOAP-Lite-0:0.68-6.fc9.noarch > > ...and so on > > I don't think we can really kill off perl-MIME-Lite if it implies killing > off openoffice via dependancies. Funny you should mention that particular one as it stood out for me too. It's fixed now. Paul. From berrange at redhat.com Fri Sep 5 16:10:08 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 5 Sep 2008 17:10:08 +0100 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <1220630788.4273.10.camel@luminos.localdomain> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <1220630361.4220.12.camel@localhost.localdomain> <1220630788.4273.10.camel@luminos.localdomain> Message-ID: <20080905161008.GQ22542@redhat.com> On Fri, Sep 05, 2008 at 09:06:28AM -0700, Jesse Keating wrote: > On Fri, 2008-09-05 at 11:59 -0400, Matthias Clasen wrote: > > djvulibre-devel is a BuildRequires for evince. > > If you remove djvulibre, evince will become unbuildable. > > Then perhaps you or somebody from your team should work on this package. > If we have to do a chained rebuild for various reasons, evince would > fail due to this package not building first. This is precisely why we need the FTBFS package list to show the list of dependant packages which will also be removed. You can't expect every package maintainer to recursively trace back all the deps of their packages to see if they might happen to be hit by removal of one of these. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From jkeating at redhat.com Fri Sep 5 16:09:10 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 05 Sep 2008 09:09:10 -0700 Subject: Fedora 8 and 9 updates status Message-ID: <1220630950.4273.14.camel@luminos.localdomain> As you well know, we have been working hard to get updates for 8 and 9 flowing again, complete with new package signing keys. Discussion has been somewhat quiet on this front as we've all had our heads down and have been working hard toward a solution, one that involves little to no manual effort on behalf of our users. Today we've reached a major milestone in this progress. We have done a successful compose of all the existing and as of yesterday pending updates for Fedora 8 and Fedora 9, all signed with our new keys. These updates will soon hit mirrors in a new set of directory locations. What we don't have quite yet is the updated fedora-release package in the old updates location that will get you the new keys and the new repo locations. The last mile testing of this update requires that new updates be live on the mirrors. Due to the size of the resigned updates, it may take a good while for our sync process. This may delay getting the new fedora-release out until tomorrow, but we'll be working hard on it. While we're working on this update, we'll also be drafting a FAQ page to explain to users what it is that we're doing, and hopefully answer some of the questions that will come up. This document will be living though, and as you encounter questions yourself, or questions via one of our many avenues of support (email, IRC, forums, LUGS, etc..) please help us in growing that document. Announcements regarding the location of said document and how to help with content will be coming shortly. We deeply appreciate the enormous magnitude of patience you the greater community has shown us the Fedora project as we work though these serious issues. It is a great testament to how wonderful it is to work in and with the Fedora community. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From rjones at redhat.com Fri Sep 5 16:12:30 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 5 Sep 2008 17:12:30 +0100 Subject: MinGW on Fedora - an update In-Reply-To: <48C136EB.9000703@lfarkas.org> References: <20080905093031.GA25404@amd.home.annexia.org> <48C101C8.1000806@lfarkas.org> <20080905113303.GA25742@amd.home.annexia.org> <48C136EB.9000703@lfarkas.org> Message-ID: <20080905161230.GA26724@amd.home.annexia.org> On Fri, Sep 05, 2008 at 03:40:59PM +0200, Farkas Levente wrote: > which works, but i'd like to test these new packages too. for me it'd be > much better if you can upload somewhere your src.rpm files and i can try > to rebuild them on rhel-5 (and may be other win32 packages like openssl, > gdk, glib, gtk, etc.). We don't have srpms right now. Will do later when we start getting packages ready for review. However the spec files + patches that you can find in the mercurial repository should be enough to rebuild everything. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From rjones at redhat.com Fri Sep 5 16:15:00 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 5 Sep 2008 17:15:00 +0100 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <48C15753.7000500@cora.nwra.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <48C15753.7000500@cora.nwra.com> Message-ID: <20080905161500.GB26724@amd.home.annexia.org> On Fri, Sep 05, 2008 at 09:59:15AM -0600, Orion Poplawski wrote: > Matt Domsch wrote: >> The following 90 packages have had FTBFS (Fails to Build From Source) >> failures for several months, some as far back as February 2008. > > >> plplot-5.9.0-1.fc9 [u'449488 ASSIGNED'] (build/make) orion > > > I *am* working on this. plplot is crazy complex (something like 10 > different language bindings, multiple output libraries). I am pretty > close to a working version and a working version will be in by the > freeze. I can vouch for this too. Orion has been asking me questions about the ocaml subpackage and I've been helping him this week. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From rjones at redhat.com Fri Sep 5 16:15:19 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 5 Sep 2008 17:15:19 +0100 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <1220630361.4220.12.camel@localhost.localdomain> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <1220630361.4220.12.camel@localhost.localdomain> Message-ID: <20080905161519.GC26724@amd.home.annexia.org> On Fri, Sep 05, 2008 at 11:59:21AM -0400, Matthias Clasen wrote: > On Fri, 2008-09-05 at 10:40 -0500, Matt Domsch wrote: > > > djvulibre-3.5.20-2.fc9 [u'440910 ASSIGNED'] (build/make) thias > > djvulibre-devel is a BuildRequires for evince. > If you remove djvulibre, evince will become unbuildable. Not all bad news then. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 67 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From limb at jcomserv.net Fri Sep 5 16:09:29 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 5 Sep 2008 11:09:29 -0500 (CDT) Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <51112.198.175.55.5.1220630969.squirrel@mail.jcomserv.net> > The following 90 packages have had FTBFS (Fails to Build From Source) > failures for several months, some as far back as February 2008. > > There are several "trivial" failures which could be addressed easily. > 8 fail due to unpackaged files > 6 fail due to patch fuzz > 1 fails due to open() not passing a mode. > > http://fedoraproject.org/wiki/FTBFS describes the FTBFS process. > > As was proposed to FESCO, packages with unresolved FTBFS bugs > immediately following the Alpha release will be removed from the > distribution. Package owners may request that their package _not_ be > removed provided they are actively working on resolving the FTBFS and > have a plan to resolve the FTBFS before the Release Candidate > release. FESCo has the final say of course, but these are the items > on my candidate list. I'd prefer packages get fixed rather than > removed. If you are the package owner, or are interested in the > future of these packages, please investigate these build failures and > fix them ASAP. > > aiksaurus-1.2.1-15.fc6 [u'434484 ASSIGNED'] (build/make) uwog > astyle-1.21-6.fc8 [u'433971 ASSIGNED'] (build/make) addutko,mtasaka > aterm-1.0.1-2.fc9 [u'440779 ASSIGNED'] (build/make) awjb > bes-3.5.3-3.fc9 [u'434360 ASSIGNED'] (build/make) pertusus > bitbake-1.8.8-1.fc8 [u'440562 ASSIGNED'] (build/make) ixs > bmpx-0.40.14-5.fc9 [u'449431 ASSIGNED'] (patch_fuzz) akahl > brltty-3.9-2.2.fc9 [u'449446 ASSIGNED'] (build/make) kasal > brutus-keyring-0.9.0-6.fc8 [u'434007 ASSIGNED'] (build/make) > bpepple,colding > camstream-0.26.3-12.fc8 [u'434345 ASSIGNED'] (build/make) nomis80 > coolkey-1.1.0-6.fc9 [u'440753 ASSIGNED'] (build/make) rrelyea,jmagne > dap-freeform_handler-3.7.7-2.fc9 [u'434362 ASSIGNED'] (build/make) > pertusus > dap-hdf4_handler-3.7.7-3.fc9 [u'434363 ASSIGNED'] (build/make) pertusus > djvulibre-3.5.20-2.fc9 [u'440910 ASSIGNED'] (build/make) thias > elektra-0.6.10-6.fc9 [u'434364 ASSIGNED'] (build/make) pertusus,kwizart > erlang-R12B-3.1.fc10 [u'449432 ASSIGNED'] (patch_fuzz) gemi > fish-1.23.0-2.fc9 [u'440724 ASSIGNED'] (build/make) ascii,oliver > fluxstyle-1.0.1-2.fc7 [u'440757 ASSIGNED'] (build/make) errr > fonttools-2.0-0.11.20060223cvs.fc7 [u'434409 ASSIGNED'] > (unpackaged_files/python-egg-info?) roozbeh,fonts-sig > fontypython-0.2.0-6.fc7 [u'440756 ASSIGNED'] (build/make) > cr33dog,fonts-sig > fwbuilder-2.1.16-2.fc9 [u'440846 ASSIGNED'] (build/make) ertzing > gauche-0.8.13-1.fc9 [u'449627 ASSIGNED'] (build/make) gemi > gcl-2.6.7-18.fc9 [u'440913 ASSIGNED'] (build/make) gemi,green > gdmap-0.7.5-6.fc6 [u'434529 ASSIGNED'] (build/make) splinux > gpsim-0.22.0-5.fc8 [u'434061 ASSIGNED'] (build/make) dionysos > gstm-1.2-6.fc7 [u'434531 ASSIGNED'] (build/make) splinux > gtk-sharp-1.0.10-12.fc7 [u'434373 ASSIGNED'] > (unpackaged_files/python-egg-info?) pfj > guile-gnome-platform-2.15.93-6.fc8 [u'434289 ASSIGNED'] (build/make) > laxathom > g-wrap-1.9.9-5.fc9 [u'434278 ASSIGNED'] (patch_fuzz) laxathom > HelixPlayer-1.0.9-4.fc10 [u'449474 ASSIGNED'] (patch_fuzz) abompard > ht2html-2.0-5.fc6 [u'440916 ASSIGNED'] (build/make) ifoox > itpp-4.0.0-2.fc9 [u'434076 ASSIGNED'] (build/make) edhill > jabbin-2.0-0.6.beta2a.fc9 [u'440730 ASSIGNED'] (build/make) > jgroups-2.2.9.2-3jpp.2 [u'434352 ASSIGNED'] (build/make) dbhole > kdebluetooth-1.0-0.41.beta8.fc9 [u'449604 ASSIGNED'] (build/make) > gilboa,scop > ladspa-1.12-9.fc9 [u'449542 ASSIGNED'] (build/make) thomasvs > libdap-3.7.10-2.fc9 [u'434366 ASSIGNED'] (build/make) pertusus > libFoundation-1.1.3-11.fc9 [u'440564 ASSIGNED'] (build/make) athimm > libfwbuilder-2.1.16-2.fc9 [u'449591 ASSIGNED'] (build/make) ertzing > libnc-dap-3.7.0-9.fc9 [u'434367 ASSIGNED'] (build/make) pertusus > libopensync-0.36-2.fc9 [u'449510 ASSIGNED'] (build/make) awjb > libzzub-0.2.3-12.fc9 [u'449661 ASSIGNED'] (patch_fuzz) akahl,mtasaka > lilypond-2.10.33-1.fc8 [u'434394 ASSIGNED'] (build/make) limb I JUST took over lilypond, and have been banging my head against an mftrace error for a few days. If anyone has time, could you take a peek and see if I'm missing something obvious? If I get it built, I can close several other bugs for lilypond.. . . http://koji.fedoraproject.org/koji/getfile?taskID=808519&name=build.log > lineakd-0.9-5.fc6 [u'434523 ASSIGNED'] (build/make) xris > lineak-defaultplugin-0.9-2.fc6 [u'434520 ASSIGNED'] (build/make) xris > lineak-xosdplugin-0.9-2.fc6 [u'434522 ASSIGNED'] (build/make) xris > linpsk-0.9-3.fc9 [u'440778 ASSIGNED'] (build/make) > bjensen,sindrepb,sconklin > linux-atm-2.5.0-5 [u'434069 ASSIGNED', u'449613 ASSIGNED'] (build/make) > dwmw2 > lostirc-0.4.6-3.fc8 [u'440921 ASSIGNED'] (build/make) splinux,splinux > lrmi-0.10-4.fc9 [u'449509 ASSIGNED'] (build/make) pwouters > mimetic-0.9.3-2.fc8 [u'434086 ASSIGNED'] (build/make) ensc > mod_suphp-0.6.3-1.fc9 [u'449578 ASSIGNED'] (build/make) ixs > monodevelop-0.19-6.fc9 [u'449441 ASSIGNED'] (build/make) pfj > mosml-2.01-11.fc9 [u'449445 ASSIGNED'] (build/make) gemi > moto4lin-0.3-6.fc7 [u'434135 ASSIGNED'] (build/make) jafo > muine-scrobbler-0.1.8-5.fc9 [u'449482 ASSIGNED'] (build/make) sindrepb > mx-2.0.6-3 [u'434325 ASSIGNED'] (unpackaged_files/python-egg-info?) misa > mysql-gui-tools-5.0r12-8.fc9 [u'440734 ASSIGNED', u'433987 ASSIGNED'] > (patch_fuzz) ausil > ntfs-config-1.0-0.6.rc5.fc9 [u'449585 ASSIGNED'] (build/make) laxathom > oggconvert-0.3.0-14.fc9 [u'440943 ASSIGNED'] > (unpackaged_files/python-egg-info?) ngompa > pan-0.132-2.fc8 [u'433970 ASSIGNED'] (build/make) adalloz,mpeters > pcmanx-gtk2-0.3.5-9.336svn.fc7 [u'434299 ASSIGNED'] (open_missing_mode) > leo > pdsh-2.11-6.fc9 [u'440811 ASSIGNED'] (build/make) kg6fnk > pekwm-0.1.5-5.fc7 [u'434089 ASSIGNED'] (build/make) errr > perl-MIME-Lite-3.01-6.fc9 [u'449558 ASSIGNED'] (build/make) > mmcgrath,perl-sig > petitboot-0.0.1-7.fc8 [u'434071 ASSIGNED'] (build/make) dwmw2,jwboyer > pic2aa-0.2.1-3.fc9 [u'440764 ASSIGNED'] (build/make) kurzawa > pl-5.6.57-2.fc10 [u'434110 ASSIGNED'] (build/make) gemi,mef > plotmm-0.1.2-6.fc9 [u'440563 ASSIGNED'] (build/make) hguemar > plplot-5.9.0-1.fc9 [u'449488 ASSIGNED'] (build/make) orion > python-durus-3.5-3.fc7 [u'434427 MODIFIED'] (build/make) shahms > python-memcached-1.39-1.fc8 [u'440931 ASSIGNED'] > (unpackaged_files/python-egg-info?) jafo > python-pydns-2.3.0-5.fc7 [u'440912 ASSIGNED'] > (unpackaged_files/python-egg-info?) jafo > python-pyspf-2.0.3-1.fc8 [u'440793 ASSIGNED'] > (unpackaged_files/python-egg-info?) jafo > python-simpletal-4.1-5.fc7 [u'440930 ASSIGNED'] (build/make) shahms > python-tpg-3.1.0-4.fc7 [u'440763 ASSIGNED'] (build/make) shahms > qa-assistant-0.4.90.5-2.fc6 [u'440914 ASSIGNED'] (build/make) toshio > qcad-2.0.5.0-8.fc9 [u'449636 ASSIGNED'] (build/make) gemi > qps-1.9.19-0.2.b.fc7 [u'434312 ASSIGNED'] (build/make) makghosh > qsynth-0.2.5-7.fc9 [u'440736 ASSIGNED'] (build/make) nando > qtiplot-0.9-8.fc9 [u'434100 ASSIGNED'] (build/make) frankb > R-Matrix-0.999375-4.fc9 [u'449530 ASSIGNED'] (build/make) tmoertel > ruby-bdb-0.6.0-1.fc7 [u'434090 ASSIGNED'] (build/make) errr > rudeconfig-5.0.5-1.fc7 [u'434131 ASSIGNED'] (build/make) homeless > scim-skk-0.5.2-8.fc6 [u'434419 ASSIGNED'] (build/make) ryo > sos-1.8-1.fc8 [u'440839 ASSIGNED'] (unpackaged_files/python-egg-info?) > navid > straw-0.27-12.fc9 [u'440806 ASSIGNED'] (build/make) subhodip > svnmailer-1.0.8-3.fc7 [u'449666 ASSIGNED'] (build/make) mfleming > xml-commons-resolver-1.1-1jpp.12 [u'434098 ASSIGNED'] (build/make) fnasser > yoltia-0.22.1-2.fc9 [u'440935 ASSIGNED'] (build/make) kurzawa > > -- > Matt Domsch > Linux Technology Strategist, Dell Office of the CTO > linux.dell.com & www.dell.com/linux > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From mw_triad at users.sourceforge.net Fri Sep 5 16:34:26 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 05 Sep 2008 11:34:26 -0500 Subject: Dependency loops considered harmful? In-Reply-To: <20080905121531.GC26218@free.fr> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <20080904113210.4d1b2c83.mschwendt@gmail.com> <20080905121531.GC26218@free.fr> Message-ID: Patrice Dumas wrote: > On Thu, Sep 04, 2008 at 01:31:56PM -0500, Matthew Woehlke wrote: >> ...which is, in a sense, the real problem. The issue as I see it is that >> rolling an RPM takes a *lot* more time and effort than 'make install', >> especially with CMake (2.6 does /very/ fast installs). It would be >> REALLY GOOD to install everything as an rpm (not least because this >> would clean up cruft from old builds!), but it needs to be fast, and it >> needs to be do-able without using root privilege. Otherwise I think the >> costs will outweigh the benefits for a lot of people. > > In many situations rolling a rpm doesn't make sense. An easy example is > numerical models. You compile it, run it and there is absolutely no reason > to make it a package. Sure, but if you didn't install it, you've obviated half the benefit anyway. I'm interested in things that get installed. -- Matthew On the internet, no one knows you're a cat... ...until you meow. MEOW! From mclasen at redhat.com Fri Sep 5 16:45:01 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 05 Sep 2008 12:45:01 -0400 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905161519.GC26724@amd.home.annexia.org> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <1220630361.4220.12.camel@localhost.localdomain> <20080905161519.GC26724@amd.home.annexia.org> Message-ID: <1220633101.22189.1.camel@localhost.localdomain> On Fri, 2008-09-05 at 17:15 +0100, Richard W.M. Jones wrote: > On Fri, Sep 05, 2008 at 11:59:21AM -0400, Matthias Clasen wrote: > > On Fri, 2008-09-05 at 10:40 -0500, Matt Domsch wrote: > > > > > djvulibre-3.5.20-2.fc9 [u'440910 ASSIGNED'] (build/make) thias > > > > djvulibre-devel is a BuildRequires for evince. > > If you remove djvulibre, evince will become unbuildable. > > Not all bad news then. Constructive comment, I apprecate that. Anyway, you rejoiced to early, dejavulibre builds fine in mock, and I've just sent it through koji, which seems to be going well, too. From pertusus at free.fr Fri Sep 5 16:56:57 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 5 Sep 2008 18:56:57 +0200 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <20080905165657.GJ26218@free.fr> On Fri, Sep 05, 2008 at 10:40:06AM -0500, Matt Domsch wrote: > bes-3.5.3-3.fc9 [u'434360 ASSIGNED'] (build/make) pertusus > dap-freeform_handler-3.7.7-2.fc9 [u'434362 ASSIGNED'] (build/make) pertusus > dap-hdf4_handler-3.7.7-3.fc9 [u'434363 ASSIGNED'] (build/make) pertusus > libdap-3.7.10-2.fc9 [u'434366 ASSIGNED'] (build/make) pertusus > libnc-dap-3.7.0-9.fc9 [u'434367 ASSIGNED'] (build/make) pertusus I am about to solve these, I have local builds and have made an annoucement on th elist. Still unsure about compat, or not. > elektra-0.6.10-6.fc9 [u'434364 ASSIGNED'] (build/make) pertusus,kwizart Hopefully Nicolas can take care of it... > fluxstyle-1.0.1-2.fc7 [u'440757 ASSIGNED'] (build/make) errr I may have a look, but it is possible that this package is abandonned. I'll try to contact th emaintainer when I have time. -- Pat From rjones at redhat.com Fri Sep 5 17:09:02 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Fri, 5 Sep 2008 18:09:02 +0100 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <1220633101.22189.1.camel@localhost.localdomain> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <1220630361.4220.12.camel@localhost.localdomain> <20080905161519.GC26724@amd.home.annexia.org> <1220633101.22189.1.camel@localhost.localdomain> Message-ID: <20080905170837.GA26967@amd.home.annexia.org> On Fri, Sep 05, 2008 at 12:45:01PM -0400, Matthias Clasen wrote: > On Fri, 2008-09-05 at 17:15 +0100, Richard W.M. Jones wrote: > > On Fri, Sep 05, 2008 at 11:59:21AM -0400, Matthias Clasen wrote: > > > On Fri, 2008-09-05 at 10:40 -0500, Matt Domsch wrote: > > > > > > > djvulibre-3.5.20-2.fc9 [u'440910 ASSIGNED'] (build/make) thias > > > > > > djvulibre-devel is a BuildRequires for evince. > > > If you remove djvulibre, evince will become unbuildable. > > > > Not all bad news then. > > Constructive comment, I apprecate that. Anyway, you rejoiced to early, > dejavulibre builds fine in mock, and I've just sent it through koji, > which seems to be going well, too. Joke, joke .. I actually like evince, the way it renders PDFs, it's just a bit slow on my old computer. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 67 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From mw_triad at users.sourceforge.net Fri Sep 5 17:12:43 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 05 Sep 2008 12:12:43 -0500 Subject: Dependency loops considered harmful? In-Reply-To: <48C084AF.5050006@gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <1220553370.4415.96.camel@localhost.localdomain> <48C05488.5060507@gmail.com> <48C06206.9040702@gmail.com> <48C084AF.5050006@gmail.com> Message-ID: Toshio Kuratomi wrote: > Matthew Woehlke wrote: >> Current workflow: >> svn up >> make >> make install >> some-app >> >> Proposed workflow: >> svn up >> make >> rpm-dev-install . >> some-app >> >> See how painless that was? And now, rather than 'make install' littering >> my drive with untracked files, the helper: >> - rolled an incremental RPM >> - updated the existing package >> - ...which removed any old files no longer there >> - ...and added/updated any modified files >> - updated the rpm database to note that some-app is now installed (if it >> wasn't) >> - ...which also means that if some-app uses libfoo-devel, rpm now >> knows this and won't remove libfoo-devel until I remove some-app > > The thing is you missed that in my current workflow there is no make > install. So the issues you have with it dirtying up the drive don't > exist and all the work (or simply waiting for a package and install step > to finish) between the make step and invocation of some-app are extra > overhead. Well, then, see my reply to Patrice, here: http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/91312 I'm not trying to solve the 'install-less' workflow; the benefit from that is IMO considerably less than the workflow *I* have, which I illustrated above. (In fact, the only benefit at that point is dependency marking. File tracking is irrelevant, and if you haven't installed, you aren't providing anything, so you have only one of the three benefits to rpm installs.) Specifically, I'm looking at development on interconnected packages where the bottom layers /must/ be trunk, and must be /installed/, in order to build the upper layers. IOW, running from the build dir would work for the endpoint applications, but /not/ the libraries they depend on. (Besides that I use KDE4 trunk for my daily desktop ;-), and am also building it as a user other than my logon user.) >> [snip my big long dissertation] > This is getting really far from what rpm does. To do this without root > access, you really need rpm to be able to merge the system rpm database > with a per-user rpm database. True, though what I was getting at was that the user database would be known only to the user, except as set up by root. So... hmm, yeah, I guess root would be allowed to break user rpm's (i.e. by removing dependencies), and I guess the root db /would/ need to know about user db's just so it can say 'user A has rpm B that depends on C, so better not auto-cull that'. And I guess that means a user can break things if they're providing a dependency, but then, if you're worried about that, you shouldn't have added a user db for dependency resolution. Fragile? Sure, but less so than not having any tracking at all. > And when you do that, you probably also > want to make sure the per-user installed packages override the > system-wide installs. ...which is already the case. I don't think there's anything special that needs to happen here; the user is responsible for setting PATH, etc, to use userland packages. > And you also have to deal with setuid binaries > and the places that random programming languages expect to load their > libraries from. Nope. Those things don't work *now* w/o 'sudo make install', so they shouldn't be expected to work under any newfangled rpm system either. Currently I install everything into (e.g.) /usr/local/myuser, which is of course writable by the user I'm building as. By doing so, I take responsibility for making my packages work when installed here in the current workflow. Bringing rpm into it wouldn't change that. Bringing rpm in would: - track the files, so update and remove work cleanly - track the 'provides' so yum doesn't try to install repo versions of the package - track the dependencies so they aren't gratuitously uninstalled Yes, the second point is fragile, but I don't think making user-installed rpms as robust as root-installed rpms is a desirable goal, nor as you have noted, is it realistic. They should be on par with user-'make install'd software plus db forging, just without the fragility of forging the rpm db. > Certain aspects of what you want could be done (although they seem very > out of line with rpm's goals so they'd have to be a separate program) > but other aspects will need an entirely different conceptual framework. > If you're interested, work on it, but it's not something that's going > to be useful for Fedora without some paring down of the new features or > a lot of other work. At the moment at least, I don't have time, but it's certainly something I'll keep in mind. From your comments, though, I wonder if you're trying to add features to what I have in mind, so it's maybe not as bad as you're thinking :-). >> What I don't get: Callum said that "rpm -i blah.rpm" would mark "blah" >> as a non-dep, i.e. would not be auto-culled. As I understand, you said >> that it *would* mark it for auto-culling. It seems to me that the former >> behavior is preferable; anything I install by hand should be >> non-auto-culled unless I say otherwise, not the other way around. > > You're right. I've read that wrong several times now. Thanks for > correcting me. Ok, then it seems we all agree on what's sensible behavior :-). Thanks for putting up with me getting that cleared up. -- Matthew On the internet, no one knows you're a cat... ...until you meow. MEOW! From ndbecker2 at gmail.com Fri Sep 5 17:23:29 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 05 Sep 2008 13:23:29 -0400 Subject: yum update problem from fresh F9-i386 References: <1220630213.17785.62.camel@rosebud> Message-ID: Seth Vidal wrote: > On Fri, 2008-09-05 at 11:55 -0400, Neal Becker wrote: >> Brand new install of F9-i386: >> yum update >> ... >> PackageKit-libs-0.1.12-10.20080505.fc9.i386 from installed has depsolving >> problems >> --> Missing Dependency: PackageKit = 0.1.12-10.20080505.fc9 is needed >> by package PackageKit-libs-0.1.12-10.20080505.fc9.i386 (installed) >> 1:perl-Pod-Escapes-1.04-20.fc9.i386 from installed has depsolving >> problems >> --> Missing Dependency: perl = 4:5.10.0-20.fc9 is needed by package >> 1:perl-Pod-Escapes-1.04-20.fc9.i386 (installed) >> 1:perl-Module-Pluggable-3.60-20.fc9.i386 from installed has depsolving >> problems >> --> Missing Dependency: perl = 4:5.10.0-20.fc9 is needed by package >> 1:perl-Module-Pluggable-3.60-20.fc9.i386 (installed) >> gnome-python2-bonobo-2.22.0-2.fc9.i386 from installed has depsolving >> problems >> --> Missing Dependency: gnome-python2 = 2.22.0-2.fc9 is needed by >> package gnome-python2-bonobo-2.22.0-2.fc9.i386 (installed) >> Error: Missing Dependency: perl = 4:5.10.0-20.fc9 is needed by package >> 1:perl-Pod-Escapes-1.04-20.fc9.i386 (installed) Error: Missing >> Dependency: PackageKit = 0.1.12-10.20080505.fc9 is needed by package >> PackageKit-libs-0.1.12-10.20080505.fc9.i386 (installed) Error: Missing >> Dependency: gnome-python2 = 2.22.0-2.fc9 is needed by package >> gnome-python2-bonobo-2.22.0-2.fc9.i386 (installed) Error: Missing >> Dependency: perl = 4:5.10.0-20.fc9 is needed by package >> 1:perl-Module-Pluggable-3.60-20.fc9.i386 (installed) > > try: > yum update yum > > then do it again. > Tried that already, yum is already updated (did that first). From vgaburici at gmail.com Fri Sep 5 17:25:37 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Fri, 5 Sep 2008 20:25:37 +0300 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905170837.GA26967@amd.home.annexia.org> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <1220630361.4220.12.camel@localhost.localdomain> <20080905161519.GC26724@amd.home.annexia.org> <1220633101.22189.1.camel@localhost.localdomain> <20080905170837.GA26967@amd.home.annexia.org> Message-ID: On Fri, Sep 5, 2008 at 8:09 PM, Richard W.M. Jones wrote: >> > > If you remove djvulibre, evince will become unbuildable. >> > >> > Not all bad news then. >> >> Constructive comment, I apprecate that. Anyway, you rejoiced to early, >> dejavulibre builds fine in mock, and I've just sent it through koji, >> which seems to be going well, too. > > Joke, joke .. I actually like evince, the way it renders PDFs, it's Except for the lack of minification of images in poppler's cairo backend. They need to "steal" that from (ghostscript's) MuPDF. > just a bit slow on my old computer. > > Rich. > > -- > Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones > Read my OCaml programming blog: http://camltastic.blogspot.com/ > Fedora now supports 67 OCaml packages (the OPEN alternative to F#) > http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From gemi at bluewin.ch Fri Sep 5 17:26:35 2008 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Fri, 05 Sep 2008 19:26:35 +0200 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <1220635595.27444.2.camel@localhost.localdomain> On Fri, 2008-09-05 at 10:40 -0500, Matt Domsch wrote: > gcl-2.6.7-18.fc9 [u'440913 ASSIGNED'] (build/make) gemi,green I would rather like to let die. It is a pain and does not build anymore on any architecture. Maybe someone have a try with it? From vgaburici at gmail.com Fri Sep 5 17:32:13 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Fri, 5 Sep 2008 20:32:13 +0300 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <1220635595.27444.2.camel@localhost.localdomain> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <1220635595.27444.2.camel@localhost.localdomain> Message-ID: On Fri, Sep 5, 2008 at 8:26 PM, G?rard Milmeister wrote: > On Fri, 2008-09-05 at 10:40 -0500, Matt Domsch wrote: >> gcl-2.6.7-18.fc9 [u'440913 ASSIGNED'] (build/make) gemi,green > I would rather like to let die. It is a pain and does not build > anymore on any architecture. Maybe someone have a try with it? According to Wikipedia, you should build from their CVS since they didn't have any releases since 2005. I am *not* volunteering 8) > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From gemi at bluewin.ch Fri Sep 5 17:49:18 2008 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Fri, 05 Sep 2008 19:49:18 +0200 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <1220635595.27444.2.camel@localhost.localdomain> Message-ID: <1220636958.27444.4.camel@localhost.localdomain> On Fri, 2008-09-05 at 20:32 +0300, Vasile Gaburici wrote: > On Fri, Sep 5, 2008 at 8:26 PM, G?rard Milmeister wrote: > > On Fri, 2008-09-05 at 10:40 -0500, Matt Domsch wrote: > >> gcl-2.6.7-18.fc9 [u'440913 ASSIGNED'] (build/make) gemi,green > > I would rather like to let die. It is a pain and does not build > > anymore on any architecture. Maybe someone have a try with it? > > According to Wikipedia, you should build from their CVS since they > didn't have any releases since 2005. I am *not* volunteering 8) Tried that too. However that Fedora memory management and security features get in the way. From vgaburici at gmail.com Fri Sep 5 17:56:29 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Fri, 5 Sep 2008 20:56:29 +0300 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: On Fri, Sep 5, 2008 at 6:40 PM, Matt Domsch wrote: > pan-0.132-2.fc8 [u'433970 ASSIGNED'] (build/make) adalloz,mpeters I've linked to a working srpm on the bug page like a month ago. My srpm still works for dist-f10: http://koji.fedoraproject.org/koji/taskinfo?taskID=809090 But I have no commit rights, so somebody else needs to do the honors. From subhodip at fedoraproject.org Fri Sep 5 18:24:11 2008 From: subhodip at fedoraproject.org (subhodip biswas) Date: Fri, 5 Sep 2008 23:54:11 +0530 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <539333cb0809051124g520b81c7x2e3d745738e454fa@mail.gmail.com> hi ! i was unable to track these for a long time , however my package straw can be build for F9 heres the koji build : http://koji.fedoraproject.org/koji/taskinfo?taskID=809096 -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From a.badger at gmail.com Fri Sep 5 18:27:57 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 05 Sep 2008 11:27:57 -0700 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <48C17A2D.4010004@gmail.com> Matt Domsch wrote: > As was proposed to FESCO, packages with unresolved FTBFS bugs > immediately following the Alpha release will be removed from the > distribution. Package owners may request that their package _not_ be > removed provided they are actively working on resolving the FTBFS and > have a plan to resolve the FTBFS before the Release Candidate > release. FESCo has the final say of course, but these are the items > on my candidate list. I'd prefer packages get fixed rather than > removed. If you are the package owner, or are interested in the > future of these packages, please investigate these build failures and > fix them ASAP. > qa-assistant-0.4.90.5-2.fc6 [u'440914 ASSIGNED'] (build/make) toshio spot was kind enough to have fixed this when he fixed the license tag in the spec. I'll close the FTBS ticket however, I've also orphaned this package so it will be blocked from F-10 unless someone wants to take it over. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From subhodip at fedoraproject.org Fri Sep 5 18:44:10 2008 From: subhodip at fedoraproject.org (subhodip biswas) Date: Sat, 6 Sep 2008 00:14:10 +0530 Subject: koji build failed due to python makefile Message-ID: <539333cb0809051144x4be4a405yefdc34777a795f61@mail.gmail.com> hi ! while building straw for F10 I get this error in koji : "invalid Python installation: unable to open /usr/lib/python2.5/config/Makefile (No such file or directory)" the whole log is here : http://koji.fedoraproject.org/koji/getfile?taskID=809186&name=build.log Why is it so ?.. what i am missing ? -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From a.badger at gmail.com Fri Sep 5 18:44:32 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 05 Sep 2008 11:44:32 -0700 Subject: Dependency loops considered harmful? In-Reply-To: References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <1220553370.4415.96.camel@localhost.localdomain> <48C05488.5060507@gmail.com> <48C06206.9040702@gmail.com> <48C084AF.5050006@gmail.com> Message-ID: <48C17E10.5090004@gmail.com> Matthew Woehlke wrote: > Toshio Kuratomi wrote: >> Matthew Woehlke wrote: >>> Current workflow: >>> svn up >>> make >>> make install >>> some-app >>> >>> Proposed workflow: >>> svn up >>> make >>> rpm-dev-install . >>> some-app >>> >>> See how painless that was? And now, rather than 'make install' littering >>> my drive with untracked files, the helper: >>> - rolled an incremental RPM >>> - updated the existing package >>> - ...which removed any old files no longer there >>> - ...and added/updated any modified files >>> - updated the rpm database to note that some-app is now installed (if it >>> wasn't) >>> - ...which also means that if some-app uses libfoo-devel, rpm now >>> knows this and won't remove libfoo-devel until I remove some-app >> >> The thing is you missed that in my current workflow there is no make >> install. So the issues you have with it dirtying up the drive don't >> exist and all the work (or simply waiting for a package and install step >> to finish) between the make step and invocation of some-app are extra >> overhead. > > Well, then, see my reply to Patrice, here: > http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/91312 > > I'm not trying to solve the 'install-less' workflow; the benefit from > that is IMO considerably less than the workflow *I* have, which I > illustrated above. (In fact, the only benefit at that point is > dependency marking. File tracking is irrelevant, and if you haven't > installed, you aren't providing anything, so you have only one of the > three benefits to rpm installs.) > Exactly! Which is why your solution isn't really an answer for pruning leaf packages. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jkeating at redhat.com Fri Sep 5 18:48:22 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 05 Sep 2008 11:48:22 -0700 Subject: koji build failed due to python makefile In-Reply-To: <539333cb0809051144x4be4a405yefdc34777a795f61@mail.gmail.com> References: <539333cb0809051144x4be4a405yefdc34777a795f61@mail.gmail.com> Message-ID: <1220640502.13594.1.camel@luminos.localdomain> On Sat, 2008-09-06 at 00:14 +0530, subhodip biswas wrote: > > Why is it so ?.. what i am missing ? Do you build-require python-devel ? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Fri Sep 5 18:49:38 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 05 Sep 2008 11:49:38 -0700 Subject: koji build failed due to python makefile In-Reply-To: <539333cb0809051144x4be4a405yefdc34777a795f61@mail.gmail.com> References: <539333cb0809051144x4be4a405yefdc34777a795f61@mail.gmail.com> Message-ID: <48C17F42.3050106@gmail.com> subhodip biswas wrote: > hi ! > > > while building straw for F10 > > I get this error in koji : "invalid Python installation: unable to > open /usr/lib/python2.5/config/Makefile (No such file or directory)" > > the whole log is here : > http://koji.fedoraproject.org/koji/getfile?taskID=809186&name=build.log > > Why is it so ?.. what i am missing ? > BuildRequires: python-devel -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From subhodip at fedoraproject.org Fri Sep 5 19:22:35 2008 From: subhodip at fedoraproject.org (subhodip biswas) Date: Sat, 6 Sep 2008 00:52:35 +0530 Subject: koji build failed due to python makefile In-Reply-To: <48C17F42.3050106@gmail.com> References: <539333cb0809051144x4be4a405yefdc34777a795f61@mail.gmail.com> <48C17F42.3050106@gmail.com> Message-ID: <539333cb0809051222s7a9814c1o7793fa93ef21190d@mail.gmail.com> hi ! 2008/9/6 Toshio Kuratomi : > subhodip biswas wrote: >> hi ! >> >> >> while building straw for F10 >> >> I get this error in koji : "invalid Python installation: unable to >> open /usr/lib/python2.5/config/Makefile (No such file or directory)" >> >> the whole log is here : >> http://koji.fedoraproject.org/koji/getfile?taskID=809186&name=build.log >> >> Why is it so ?.. what i am missing ? >> > BuildRequires: python-devel But build for F9 is not failing in koji ..heres the log http://koji.fedoraproject.org/koji/taskinfo?taskID=809096 > -Toshio > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From dbhole at redhat.com Fri Sep 5 19:36:42 2008 From: dbhole at redhat.com (Deepak Bhole) Date: Fri, 5 Sep 2008 15:36:42 -0400 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <20080905193642.GA4019@redhat.com> * Matt Domsch [2008-09-05 11:46]: > The following 90 packages have had FTBFS (Fails to Build From Source) > failures for several months, some as far back as February 2008. > > There are several "trivial" failures which could be addressed easily. > 8 fail due to unpackaged files > 6 fail due to patch fuzz > 1 fails due to open() not passing a mode. > > jgroups-2.2.9.2-3jpp.2 [u'434352 ASSIGNED'] (build/make) dbhole This is fixed now. From mschwendt at gmail.com Fri Sep 5 19:43:08 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 5 Sep 2008 21:43:08 +0200 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <20080905214308.944471ad.mschwendt@gmail.com> On Fri, 5 Sep 2008 10:40:06 -0500, Matt Domsch wrote: > ladspa-1.12-9.fc9 [u'449542 ASSIGNED'] (build/make) thomasvs FIXED as it's required by other packages. From kevin.kofler at chello.at Fri Sep 5 19:44:04 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 5 Sep 2008 19:44:04 +0000 (UTC) Subject: Heads-up: libdap and libnc-dap updates References: <20080905133702.GF26218@free.fr> Message-ID: Patrice Dumas free.fr> writes: > I don't want to do devel compat package, I don't think it is needed, > and this compat package should be removed in F12 or so. That makes no sense at all. Either the packages build against the new library, then they should simply be rebuilt, or they don't, in which case the -devel package for the compatibility library MUST be provided or the dependent packages don't rebuild anymore. We're trying hard to get FTBFS bugs fixed, intentionally causing new ones is a very bad idea. What if one of the dependent packages has a security issue? IMHO, compatibility libraries without a -devel package should be banned entirely. If the compatibility package is needed, so is the corresponding -devel package, unless the changes are strictly ABI-only with 100% source compatibility (usually they aren't)! And in that rare event, a mass rebuild is a better solution than a compatibility package. Kevin Kofler From paul at all-the-johnsons.co.uk Fri Sep 5 20:21:48 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Fri, 05 Sep 2008 21:21:48 +0100 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <1220646108.4331.2.camel@PB3.Linux> Hi, > gtk-sharp-1.0.10-12.fc7 [u'434373 ASSIGNED'] (unpackaged_files/python-egg-info?) pfj Does anything still rely on gtk-sharp? I know none of the packages I do uses it anymore (even Novell can't think of any!) > monodevelop-0.19-6.fc9 [u'449441 ASSIGNED'] (build/make) pfj This is a pain. Every time I've tried to build MD 1.0, koji has thrown a wobbler complaining that %{_libdir}/mono/gac can't be found! I will look at it again over this next week though. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dbhole at redhat.com Fri Sep 5 20:24:53 2008 From: dbhole at redhat.com (Deepak Bhole) Date: Fri, 5 Sep 2008 16:24:53 -0400 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <20080905202453.GB4019@redhat.com> * Matt Domsch [2008-09-05 11:46]: > xml-commons-resolver-1.1-1jpp.12 [u'434098 ASSIGNED'] (build/make) fnasser Fixed as well. Deepak From jos at xos.nl Fri Sep 5 20:36:59 2008 From: jos at xos.nl (Jos Vos) Date: Fri, 05 Sep 2008 22:36:59 +0200 Subject: F9 chkfontpath replacement? Message-ID: <200809052036.m85KaxLO006814@jasmine.xos.nl> Hi, I see that in F9 chkfontpath is gone. Is there a recommend way to perform a similar function? In some font rpms I'm maintaining, putting fonts in some specific directories, I used to call chkfontpath with a local font dir in %post. Thanks, -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From gnomeuser at gmail.com Fri Sep 5 20:47:36 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Fri, 5 Sep 2008 22:47:36 +0200 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <1220646108.4331.2.camel@PB3.Linux> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <1220646108.4331.2.camel@PB3.Linux> Message-ID: <1dedbbfc0809051347g383ccf70o1686a982388b685@mail.gmail.com> Den 5. sep. 2008 22.21 skrev Paul : > Hi, > > > monodevelop-0.19-6.fc9 [u'449441 ASSIGNED'] (build/make) pfj > > This is a pain. Every time I've tried to build MD 1.0, koji has thrown a > wobbler complaining that %{_libdir}/mono/gac can't be found! I will look > at it again over this next week though. > Didn't the wonderful Michel fix this recently, he cleaned up the spec and bumped us succesfully to 2.0 beta. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.a.young at durham.ac.uk Fri Sep 5 20:56:58 2008 From: m.a.young at durham.ac.uk (M A Young) Date: Fri, 5 Sep 2008 21:56:58 +0100 (BST) Subject: yum update problem from fresh F9-i386 In-Reply-To: References: <1220630213.17785.62.camel@rosebud> Message-ID: On Fri, 5 Sep 2008, Neal Becker wrote: >>> PackageKit-libs-0.1.12-10.20080505.fc9.i386 from installed has depsolving >>> problems >>> --> Missing Dependency: PackageKit = 0.1.12-10.20080505.fc9 is needed >>> by package PackageKit-libs-0.1.12-10.20080505.fc9.i386 (installed) >>> 1:perl-Pod-Escapes-1.04-20.fc9.i386 from installed has depsolving >>> problems >>> --> Missing Dependency: perl = 4:5.10.0-20.fc9 is needed by package >>> 1:perl-Pod-Escapes-1.04-20.fc9.i386 (installed) >>> 1:perl-Module-Pluggable-3.60-20.fc9.i386 from installed has depsolving >>> problems >>> --> Missing Dependency: perl = 4:5.10.0-20.fc9 is needed by package >>> 1:perl-Module-Pluggable-3.60-20.fc9.i386 (installed) >>> gnome-python2-bonobo-2.22.0-2.fc9.i386 from installed has depsolving >>> problems >>> --> Missing Dependency: gnome-python2 = 2.22.0-2.fc9 is needed by >>> package gnome-python2-bonobo-2.22.0-2.fc9.i386 (installed) >>> Error: Missing Dependency: perl = 4:5.10.0-20.fc9 is needed by package >>> 1:perl-Pod-Escapes-1.04-20.fc9.i386 (installed) Error: Missing >>> Dependency: PackageKit = 0.1.12-10.20080505.fc9 is needed by package >>> PackageKit-libs-0.1.12-10.20080505.fc9.i386 (installed) Error: Missing >>> Dependency: gnome-python2 = 2.22.0-2.fc9 is needed by package >>> gnome-python2-bonobo-2.22.0-2.fc9.i386 (installed) Error: Missing >>> Dependency: perl = 4:5.10.0-20.fc9 is needed by package >>> 1:perl-Module-Pluggable-3.60-20.fc9.i386 (installed) >> >> try: >> yum update yum >> >> then do it again. >> > > Tried that already, yum is already updated (did that first). That looks like an update against an incomplete updates repository with some packages there and some not (eg. PackageKit there but not PackageKit-libs). Could be this related to the repository changes that are about to take place. Michael Young From dwheeler at dwheeler.com Fri Sep 5 20:54:43 2008 From: dwheeler at dwheeler.com (David A. Wheeler) Date: Fri, 05 Sep 2008 16:54:43 -0400 (EDT) Subject: GNU Common Lisp (gcl) - need a new security context? In-Reply-To: <20080905194430.2148E61A32C@hormel.redhat.com> References: <20080905194430.2148E61A32C@hormel.redhat.com> Message-ID: Matt Domsch wrote regarding gcl (GNU Common Lisp): > > >> gcl-2.6.7-18.fc9 [u'440913 ASSIGNED'] (build/make) gemi,green > > > I would rather like to let die. It is a pain and does not build > > > anymore on any architecture. Maybe someone have a try with it? From: G?rard Milmeister > Tried that too. However that Fedora memory management and security > features get in the way. Dropping gcl is a bad idea. gcl generates much better code in many cases; dropping makes Fedora bad for running Common Lisp (CL) applications. There are a lot of CL programs, and CL is still important; "Practical Common Lisp" was published 2005 and was a really popular book. For example, performance figures for ACL2 are here: http://www.cs.utexas.edu/users/moore/acl2/current/new.html#performance gcl is 20% faster on 64-bit, and 32% faster on 32-bit,, compared to the next-best implementation available on Fedora. This may illustrate a larger security issue: the Fedora memory management/security features appear to be tuned for C/C++ programs. Unfortunately, they interfere with running programs written in some other languages. It's especially silly when the language design prevents the problem anyway. Take a look at the rant here, where Axiom explains how to run on Fedora: http://axiom.axiom-developer.org/axiom-website/patches/20080527.01.tpd.patch Axiom's solution is completely disable a lot of security functions for the ENTIRE system, not just for that one program. That's not good. I think it'd better to create an SELinux security context that grants additional memory privileges that can be used ONLY when the program actually _NEEDS_ those privileges (e.g., it uses a gcl runtime requiring additional privileges). You could document a "recipe" for how to create such a thing would be a good idea - but you'd need to recreate it for every program compiled by gcl, ugh. I think it'd be better to have a standard context for this case (the current "unconfined" really is confined; maybe the new one is "really_unconfined"?). Having some processes less confined is better than disabling the security mechanisms for the entire system. --- David A. Wheeler From Matt_Domsch at dell.com Fri Sep 5 21:10:24 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Fri, 5 Sep 2008 16:10:24 -0500 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905155539.GP22542@redhat.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <20080905155539.GP22542@redhat.com> Message-ID: <20080905211024.GC21803@auslistsprd01.us.dell.com> On Fri, Sep 05, 2008 at 04:55:39PM +0100, Daniel P. Berrange wrote: > On Fri, Sep 05, 2008 at 10:40:06AM -0500, Matt Domsch wrote: > > The following 90 packages have had FTBFS (Fails to Build From Source) > > failures for several months, some as far back as February 2008. > > > > There are several "trivial" failures which could be addressed easily. > > 8 fail due to unpackaged files > > 6 fail due to patch fuzz > > 1 fails due to open() not passing a mode. > > > > http://fedoraproject.org/wiki/FTBFS describes the FTBFS process. > > > > As was proposed to FESCO, packages with unresolved FTBFS bugs > > immediately following the Alpha release will be removed from the > > distribution. Package owners may request that their package _not_ be > > removed provided they are actively working on resolving the FTBFS and > > have a plan to resolve the FTBFS before the Release Candidate > > release. FESCo has the final say of course, but these are the items > > on my candidate list. I'd prefer packages get fixed rather than > > removed. If you are the package owner, or are interested in the > > future of these packages, please investigate these build failures and > > fix them ASAP. > > This list is far from complete - if you want to remove these 90, the > dependancy chain ripple, will entail the removal of tonnes of other > packages which depend on these. > > Any chance you can generate a report which shows the ripple effect > for each proposed package. If something is just a leaf-node, it isn't > very important to worry about, but if something triggers removal > of 50 dependant packages that's pretty damn important to fix. This > info would be useful in prioritizing which builds need fixing most > urgently. With sincere thanks to Seth Vidal, (he wrote a script do show what packages depend on a given package, posted at http://skvidal.fedorapeople.org/misc/pkg-provs-tree-view.py) here is the list of non-leaf-nodes in "priority" order. The number on the left is essentially the number of packages that depend on the named package. Use the above script as: $ python pkg-provs-tree-view.py to get the results of the "what depends on , recursively". e.g. $ python --enablerepo=rawhide pkg-provs-tree-view.py gauche 604 gauche-0.8.13-1.fc9 551 xml-commons-resolver-1.1-1jpp.12 545 perl-MIME-Lite-3.01-6.fc9 138 libdap-3.7.10-2.fc9 62 plplot-5.9.0-1.fc9 46 mx-2.0.6-3 37 ladspa-1.12-9.fc9 34 libopensync-0.36-2.fc9 27 elektra-0.6.10-6.fc9 24 aiksaurus-1.2.1-15.fc6 22 libnc-dap-3.7.0-9.fc9 20 g-wrap-1.9.9-5.fc9 19 bes-3.5.3-3.fc9 17 libfwbuilder-2.1.16-2.fc9 16 brutus-keyring-0.9.0-6.fc8 14 pl-5.6.57-2.fc10 13 lineakd-0.9-5.fc6 10 libzzub-0.2.3-12.fc9 9 itpp-4.0.0-2.fc9 9 guile-gnome-platform-2.15.93-6.fc8 8 erlang-R12B-3.1.fc10 7 mimetic-0.9.3-2.fc8 7 libFoundation-1.1.3-11.fc9 7 gpsim-0.22.0-5.fc8 7 coolkey-1.1.0-6.fc9 5 gtk-sharp-1.0.10-12.fc7 5 fwbuilder-2.1.16-2.fc9 5 dap-freeform_handler-3.7.7-2.fc9 3 R-Matrix-0.999375-4.fc9 3 djvulibre-3.5.20-2.fc9 3 brltty-3.9-2.2.fc9 3 bmpx-0.40.14-5.fc9 2 qtiplot-0.9-8.fc9 2 mosml-2.01-11.fc9 2 lrmi-0.10-4.fc9 2 lilypond-2.10.33-1.fc8 2 dap-hdf4_handler-3.7.7-3.fc9 -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From jkeating at redhat.com Fri Sep 5 21:14:18 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 05 Sep 2008 14:14:18 -0700 Subject: koji build failed due to python makefile In-Reply-To: <539333cb0809051222s7a9814c1o7793fa93ef21190d@mail.gmail.com> References: <539333cb0809051144x4be4a405yefdc34777a795f61@mail.gmail.com> <48C17F42.3050106@gmail.com> <539333cb0809051222s7a9814c1o7793fa93ef21190d@mail.gmail.com> Message-ID: <1220649258.13594.2.camel@luminos.localdomain> On Sat, 2008-09-06 at 00:52 +0530, subhodip biswas wrote: > > But build for F9 is not failing in koji ..heres the log > http://koji.fedoraproject.org/koji/taskinfo?taskID=809096 Python in F9 is packaged differently. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Fri Sep 5 21:30:35 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 05 Sep 2008 17:30:35 -0400 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905211024.GC21803@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <20080905155539.GP22542@redhat.com> <20080905211024.GC21803@auslistsprd01.us.dell.com> Message-ID: <1220650235.17785.90.camel@rosebud> On Fri, 2008-09-05 at 16:10 -0500, Matt Domsch wrote: > With sincere thanks to Seth Vidal, (he wrote a script do show what > packages depend on a given package, posted at > http://skvidal.fedorapeople.org/misc/pkg-provs-tree-view.py) > here is the list of non-leaf-nodes in "priority" order. > Actually I took a script that James Antill wrote and made it work on provides instead of on requires. Just to make sure credit goes to all the appropriate places. thanks, -sv From jspaleta at gmail.com Fri Sep 5 22:20:55 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 5 Sep 2008 14:20:55 -0800 Subject: MinGW on Fedora - an update In-Reply-To: <20080905101045.GB22542@redhat.com> References: <20080905093031.GA25404@amd.home.annexia.org> <48C101C8.1000806@lfarkas.org> <20080905101045.GB22542@redhat.com> Message-ID: <604aa7910809051520l30c0783co6012d48d4a48c7a8@mail.gmail.com> On Fri, Sep 5, 2008 at 2:10 AM, Daniel P. Berrange wrote: > Too many unknowns to give any sensisble prediction. We're waiting on the > releng/infrastructure guys to create a dedicated build root for mingw > stuff, and set things to it publishes into a separate YUM repo as per > earlier Fedora Board decision[1]. I've no idea how hard/complex this > is, or how long it'll take. Once that's done then we need to bootstrap > the build, and get all the packages through review. > > http://fedoraproject.org/wiki/Board/Meetings/2008-07-15 > > Be nice to have it all done for F10, but no idea if that is practical > as the infrastructure team is very busy. As requested by FESCo, in the post-Board meeting discussion. I've put together a strawman proposal on how to move forward: https://fedoraproject.org/wiki/User:Jspaleta/Draft Please have everyone in the MinGW SIG take a look at that strawman. And please note this is a starting point for discussion as to specific policies. If this draft doesn't cover any specific concerns you have moving forward let me know. I've tried to write the draft in such a way such that the policy issues before FESCo are orthogonal to the issue of initial project resource allocation. I've also put the MinGW Repository formation into the FESCo issue tracker system: https://fedorahosted.org/fesco/ticket/2 I will be be in attendance at the FESCo meeting whenever FESCo takes up the issue. If the MinGW SIG is not ready to move forward with a discussion with FESCo, let me know and I'll make sure the ticket isn't acted on until a rep from MinGW SIG can be in attendance at the FESCo meeting. -jef From lists at ebourne.me.uk Fri Sep 5 22:27:29 2008 From: lists at ebourne.me.uk (Martin Ebourne) Date: Fri, 5 Sep 2008 22:27:29 +0000 (UTC) Subject: Proposed removal of packages with long-standing FTBFS failures References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: On Fri, 05 Sep 2008 20:56:29 +0300, Vasile Gaburici wrote: > On Fri, Sep 5, 2008 at 6:40 PM, Matt Domsch > wrote: > >> pan-0.132-2.fc8 [u'433970 ASSIGNED'] (build/make) adalloz,mpeters > > I've linked to a working srpm on the bug page like a month ago. My srpm > still works for dist-f10: > http://koji.fedoraproject.org/koji/taskinfo?taskID=809090 > > But I have no commit rights, so somebody else needs to do the honors. I certainly wouldn't want to lose pan, wouldn't be able to read fedora- devel for a start. I'm out for the next couple of weeks, but if it's still on the list when I get back I'll take that over. I'll take a look at dejavu-libre as well if necessary. Cheers, Martin From mw_triad at users.sourceforge.net Fri Sep 5 22:48:30 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 05 Sep 2008 17:48:30 -0500 Subject: Dependency loops considered harmful? In-Reply-To: <48C17E10.5090004@gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <1220553370.4415.96.camel@localhost.localdomain> <48C05488.5060507@gmail.com> <48C06206.9040702@gmail.com> <48C084AF.5050006@gmail.com> <48C17E10.5090004@gmail.com> Message-ID: Toshio Kuratomi wrote: > Matthew Woehlke wrote: >> I'm not trying to solve the 'install-less' workflow; the benefit from >> that is IMO considerably less than the workflow *I* have, which I >> illustrated above. (In fact, the only benefit at that point is >> dependency marking. File tracking is irrelevant, and if you haven't >> installed, you aren't providing anything, so you have only one of the >> three benefits to rpm installs.) > > Exactly! Which is why your solution isn't really an answer for pruning > leaf packages. Sure it is :-). It just only helps if you "install" the stuff that needs whatever packages would otherwise get pruned ;-). Although that's somewhat beside the point, since I did rather try to drag the thread off on a (related) tangent. However, it doesn't address -devel packages; for that I think you would need some form of SRPM (and you would absolutely want those to be user-owned, so we've still got the problem of a "system"/root rpm db and one or more user rpm db's). There's overlap... -- Matthew On the internet, no one knows you're a cat... ...until you meow. MEOW! From dcnltc at us.ibm.com Fri Sep 5 23:09:01 2008 From: dcnltc at us.ibm.com (Dave Nomura) Date: Fri, 05 Sep 2008 16:09:01 -0700 Subject: broken dependencies on libfd and libopcodes Message-ID: <48C1BC0D.9040603@us.ibm.com> Hi, I'm trying to fix the following broken dependencies in my new package for Fedora10. I've tried adding both binutils and binutils-devel to both Requires and BuildRequires but neither seems to resolve the dependencies. Assuming that the libbfd and libopcodes libraries are in binutils or binutils-devel as in other distros I would have expected this to resolve the dependency, but apparently not on Fedora. Are these located in different packages on Fedora? Can anyone tell me what I need to add to my Requires/BuildRequires to resolve the dependency? buildsys at fedoraproject.org wrote: > stapitrace has broken dependencies in the development tree: > On ppc: > stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires > libbfd-2.18.50.0.8-2.fc10.so > stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires > libopcodes-2.18.50.0.8-2.fc10.so > Please resolve this as soon as possible. > > > -- Dave Nomura LTC Linux Power Toolchain -- Dave Nomura LTC Linux Power Toolchain From orion at cora.nwra.com Fri Sep 5 23:14:59 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 05 Sep 2008 17:14:59 -0600 Subject: SGML support refactored in F-10? In-Reply-To: <48BEC198.3080809@cora.nwra.com> References: <17316.1219966344@sss.pgh.pa.us> <1219967329.6260.3.camel@localhost.localdomain> <1220015170.3980.43.camel@dhcp-lab-219.englab.brq.redhat.com> <907.1220315414@sss.pgh.pa.us> <48BEC198.3080809@cora.nwra.com> Message-ID: <48C1BD73.70205@cora.nwra.com> Orion Poplawski wrote: > Problems for me too: > > /usr/bin/openjade:/usr/share/sgml/docbook/sgml-dtd-4.2-1.0-39.fc10/dbcentx.mod:308:0:E: > cannot find "ent/iso-amsa.ent"; tried > "/usr/share/sgml/docbook/sgml-dtd-4.2-1.0-39.fc10/ent/iso-amsa.ent", > "/usr/share/sgml/ent/iso-amsa.ent", "/usr/share/xml/ent/iso-amsa.ent" > > and so on... > > find /usr/share -name iso-amsa.ent > /usr/share/sgml/docbook/xml-dtd-4.2-1.0-39.fc10/ent/iso-amsa.ent > /usr/share/sgml/docbook/xml-dtd-4.1.2-1.0-39.fc10/ent/iso-amsa.ent > /usr/share/sgml/docbook/xml-dtd-4.3-1.0-39.fc10/ent/iso-amsa.ent > > > Possible fix filed here: https://bugzilla.redhat.com/show_bug.cgi?id=461206 -- 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 mschwendt at gmail.com Fri Sep 5 23:37:56 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 6 Sep 2008 01:37:56 +0200 Subject: broken dependencies on libfd and libopcodes In-Reply-To: <48C1BC0D.9040603@us.ibm.com> References: <48C1BC0D.9040603@us.ibm.com> Message-ID: <20080906013756.850e6934.mschwendt@gmail.com> On Fri, 05 Sep 2008 16:09:01 -0700, Dave Nomura wrote: > Hi, > I'm trying to fix the following broken dependencies in my new package > for Fedora10. > I've tried adding both binutils and binutils-devel to both Requires and > BuildRequires but neither seems to resolve the dependencies. > > Assuming that the libbfd and libopcodes libraries are in binutils or > binutils-devel as in other distros I would have expected this to resolve > the dependency, but apparently not on Fedora. > > Are these located in different packages on Fedora? > > Can anyone tell me what I need to add to my Requires/BuildRequires to > resolve the dependency? > > buildsys at fedoraproject.org wrote: > > stapitrace has broken dependencies in the development tree: > > On ppc: > > stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires > > libbfd-2.18.50.0.8-2.fc10.so > > stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires > > libopcodes-2.18.50.0.8-2.fc10.so > > Please resolve this as soon as possible. You misinterpret the broken deps report, and you haven't built an update yet that would attempt at fixing the broken deps. libbfd-2.18.50.0.8-2.fc10.so and libopcodes-2.18.50.0.8-2.fc10.so are not available any longer, because binutils-2.18.50.0.9-1.fc10 replaced them with new versions ( http://koji.fedoraproject.org/koji/rpminfo?rpmID=725620 http://koji.fedoraproject.org/koji/rpminfo?rpmID=725621 ). There you cannot simply add any Requires on binutils, since the new binutils pkg does not include these old libraries. So, normally this means you need to rebuild your package to link against the newer libraries (and their newer sonames which result in automatic dependencies). However, your package fails to build on ppc in a libbfd compile-test. Cat config.log to find out why it fails. From bpepple at fedoraproject.org Sat Sep 6 00:36:09 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 05 Sep 2008 20:36:09 -0400 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <1220661369.19946.0.camel@kennedy> On Fri, 2008-09-05 at 10:40 -0500, Matt Domsch wrote: > brutus-keyring-0.9.0-6.fc8 [u'434007 ASSIGNED'] (build/make) bpepple,colding Fixed. Thanks for the heads up. Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From opensource at till.name Fri Sep 5 23:38:57 2008 From: opensource at till.name (Till Maas) Date: Sat, 06 Sep 2008 01:38:57 +0200 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905211024.GC21803@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <20080905155539.GP22542@redhat.com> <20080905211024.GC21803@auslistsprd01.us.dell.com> Message-ID: <200809060139.07587.opensource@till.name> On Fri September 5 2008, Matt Domsch wrote: > With sincere thanks to Seth Vidal, (he wrote a script do show what > packages depend on a given package, posted at > http://skvidal.fedorapeople.org/misc/pkg-provs-tree-view.py) > here is the list of non-leaf-nodes in "priority" order. > > The number on the left is essentially the number of packages that > depend on the named package. > 5 fwbuilder-2.1.16-2.fc9 The script should probably check whether dependent packages are built from the same src.rpm: $ python pkg-provs-tree-view.py --enablerepo=rawhide fwbuilder fwbuilder - 2.1.14-1.fc8.i386 [cmd line] \_ fwbuilder-ipf - 2.1.14-1.fc8.i386 [1: fwbuilder = 2.1.14-1.fc8] \_ fwbuilder-pf - 2.1.14-1.fc8.i386 [1: fwbuilder = 2.1.14-1.fc8] \_ fwbuilder-ipfw - 2.1.14-1.fc8.i386 [1: fwbuilder = 2.1.14-1.fc8] \_ fwbuilder-ipt - 2.1.14-1.fc8.i386 [1: fwbuilder = 2.1.14-1.fc8] Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From michel.sylvan at gmail.com Sat Sep 6 04:14:51 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sat, 6 Sep 2008 00:14:51 -0400 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <1dedbbfc0809051347g383ccf70o1686a982388b685@mail.gmail.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <1220646108.4331.2.camel@PB3.Linux> <1dedbbfc0809051347g383ccf70o1686a982388b685@mail.gmail.com> Message-ID: 2008/9/5 David Nielsen : > > > Den 5. sep. 2008 22.21 skrev Paul : >> >> Hi, >> >> > monodevelop-0.19-6.fc9 [u'449441 ASSIGNED'] (build/make) pfj >> >> This is a pain. Every time I've tried to build MD 1.0, koji has thrown a >> wobbler complaining that %{_libdir}/mono/gac can't be found! I will look >> at it again over this next week though. > > Didn't the wonderful Michel fix this recently, he cleaned up the spec and > bumped us succesfully to 2.0 beta. > I haven't touched the F-9 branch; as I'm not running F-9 anymore, and with the changes in the Mono stack, I didn't want to risk any breakage. Paul likely knows more about the difference between F-9's mono and Rawhide's -- Paul, you could perhaps backport the Rawhide monodevelop to F-9? Some of the BRs might need to be changed. -- Michel Salim http://hircus.jaiku.com/ From paul at city-fan.org Sat Sep 6 07:23:45 2008 From: paul at city-fan.org (Paul Howarth) Date: Sat, 6 Sep 2008 08:23:45 +0100 Subject: GNU Common Lisp (gcl) - need a new security context? In-Reply-To: References: <20080905194430.2148E61A32C@hormel.redhat.com> Message-ID: <20080906082345.484237a2@metropolis.intra.city-fan.org> On Fri, 05 Sep 2008 16:54:43 -0400 (EDT) "David A. Wheeler" wrote: > Matt Domsch wrote regarding gcl (GNU Common Lisp): > > > >> gcl-2.6.7-18.fc9 [u'440913 ASSIGNED'] (build/make) gemi,green > > > > I would rather like to let die. It is a pain and does not build > > > > anymore on any architecture. Maybe someone have a try with it? > > From: G?rard Milmeister > > Tried that too. However that Fedora memory management and security > > features get in the way. > > Dropping gcl is a bad idea. gcl generates much better code in many > cases; dropping makes Fedora bad for running Common Lisp (CL) > applications. There are a lot of CL programs, and CL is still > important; "Practical Common Lisp" was published 2005 and was a > really popular book. > > For example, performance figures for ACL2 are here: > http://www.cs.utexas.edu/users/moore/acl2/current/new.html#performance > gcl is 20% faster on 64-bit, and 32% faster on 32-bit,, compared > to the next-best implementation available on Fedora. > > This may illustrate a larger security issue: > the Fedora memory management/security features appear to > be tuned for C/C++ programs. Unfortunately, > they interfere with running programs written in some other languages. > It's especially silly when the language design prevents the problem > anyway. Take a look at the rant here, where Axiom explains how to run > on Fedora: > http://axiom.axiom-developer.org/axiom-website/patches/20080527.01.tpd.patch > Axiom's solution is completely disable a lot of security functions > for the ENTIRE system, not just for that one program. That's not good. > > I think it'd better to create an SELinux security context that grants > additional memory privileges that can be used ONLY when the > program actually _NEEDS_ those privileges (e.g., it uses > a gcl runtime requiring additional privileges). > You could document a "recipe" for how to create such a > thing would be a good idea - but you'd need to recreate it for > every program compiled by gcl, ugh. I think it'd be better to > have a standard context for this case (the current "unconfined" really > is confined; maybe the new one is "really_unconfined"?). > Having some processes less confined is better than disabling > the security mechanisms for the entire system. This is the approach taken for mono and java, which have similar issues. If you use a context type of java_exec_t for something using the gcl runtime, does it work? Paul. > > --- David A. Wheeler > From subhodip at fedoraproject.org Sat Sep 6 07:47:17 2008 From: subhodip at fedoraproject.org (subhodip biswas) Date: Sat, 6 Sep 2008 13:17:17 +0530 Subject: koji build failed due to python makefile In-Reply-To: <1220649258.13594.2.camel@luminos.localdomain> References: <539333cb0809051144x4be4a405yefdc34777a795f61@mail.gmail.com> <48C17F42.3050106@gmail.com> <539333cb0809051222s7a9814c1o7793fa93ef21190d@mail.gmail.com> <1220649258.13594.2.camel@luminos.localdomain> Message-ID: <539333cb0809060047t7fe03c32l8a08836fbee01b1d@mail.gmail.com> ah ..ok ok -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From ville.skytta at iki.fi Sat Sep 6 08:32:23 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sat, 6 Sep 2008 11:32:23 +0300 Subject: Heads up: packages with Patch:/%patch0 or Patch0:/%patch issues in Rawhide Message-ID: <200809061132.24420.ville.skytta@iki.fi> Hi, There's a number of packages that have problems with the new rpm's behavior of not applying Patch0: with plain %patch or not applying Patch: with %patch0. I just discovered that for some reason, the rpmbuild process does not terminate because of this error, so unless people read their build logs carefully, some patches may go unapplied. https://bugzilla.redhat.com/461347 Below is a list of packages that most likely need packager action. One way to fix them is to convert all unnumbered Patch: lines to Patch0: and all unnumbered %patch lines to %patch0 or %patch -P 0. --- Patch: in specfile, applied with %patch0: alsa-oss perl-JSON-Any rcs starfighter tailor time Patch0: in specfile, applied with %patch (without -P 0): abe bit bontmia cjet classpathx-jaf conexus cpan2rpm dosbox dwdiff eclipse-subclipse environment-modules extrema freetennis gai-pal hdf hspell ifplugd ipcalculator kompose ksynaptics liblqr-1 libnetfilter_conntrack libnetfilter_queue libnfnetlink lvm2 mboxgrep nec2c nethogs osiv papyrus pards perl-BSD-Resource perl-XML-Smart plexus-runtime-builder qemu-launcher ruby-postgres shapelib speech-dispatcher sundials svnmailer symlinks sysstat tclparser tremulous uisp unix2dos weechat wgrib2 windowlab worminator xbae xmlroff xpdf zvbi From laxathom at fedoraproject.org Sat Sep 6 09:07:17 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Sat, 6 Sep 2008 11:07:17 +0200 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <62bc09df0809060207m7513abf4meda28e6aa9ffa191@mail.gmail.com> On Fri, Sep 5, 2008 at 5:40 PM, Matt Domsch wrote: guile-gnome-platform-2.15.93-6.fc8 [u'434289 ASSIGNED'] (build/make) > laxathom > g-wrap-1.9.9-5.fc9 [u'434278 ASSIGNED'] (patch_fuzz) laxathom > ntfs-config-1.0-0.6.rc5.fc9 [u'449585 ASSIGNED'] (build/make) laxathom I'll will fix mine this week-end, thanks. -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Sat Sep 6 09:29:22 2008 From: aph at redhat.com (Andrew Haley) Date: Sat, 06 Sep 2008 10:29:22 +0100 Subject: GNU Common Lisp (gcl) - need a new security context? In-Reply-To: <20080906082345.484237a2@metropolis.intra.city-fan.org> References: <20080905194430.2148E61A32C@hormel.redhat.com> <20080906082345.484237a2@metropolis.intra.city-fan.org> Message-ID: <48C24D72.3070801@redhat.com> Paul Howarth wrote: > On Fri, 05 Sep 2008 16:54:43 -0400 (EDT) > "David A. Wheeler" wrote: > >> I think it'd better to create an SELinux security context that grants >> additional memory privileges that can be used ONLY when the >> program actually _NEEDS_ those privileges (e.g., it uses >> a gcl runtime requiring additional privileges). >> You could document a "recipe" for how to create such a >> thing would be a good idea - but you'd need to recreate it for >> every program compiled by gcl, ugh. I think it'd be better to >> have a standard context for this case (the current "unconfined" really >> is confined; maybe the new one is "really_unconfined"?). >> Having some processes less confined is better than disabling >> the security mechanisms for the entire system. Indeed. The SELinux approach is not to disable such features for a whole system, but to provide fine-grained access control for those parts that need it. > This is the approach taken for mono and java, which have similar issues. > > If you use a context type of java_exec_t for something using the gcl > runtime, does it work? Is it every program created by gcl that needs this access, or just gcl itself? Andrew. From vgaburici at gmail.com Sat Sep 6 09:42:51 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Sat, 6 Sep 2008 12:42:51 +0300 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <62bc09df0809060207m7513abf4meda28e6aa9ffa191@mail.gmail.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <62bc09df0809060207m7513abf4meda28e6aa9ffa191@mail.gmail.com> Message-ID: 2008/9/6 Xavier Lamien : > > > On Fri, Sep 5, 2008 at 5:40 PM, Matt Domsch wrote: > >> guile-gnome-platform-2.15.93-6.fc8 [u'434289 ASSIGNED'] (build/make) >> laxathom >> g-wrap-1.9.9-5.fc9 [u'434278 ASSIGNED'] (patch_fuzz) laxathom >> ntfs-config-1.0-0.6.rc5.fc9 [u'449585 ASSIGNED'] (build/make) laxathom > > I'll will fix mine this week-end, thanks. BTW, in the description of ntfs-config, "with only two click" should have click pluralized. > > > > -- > Xavier.t Lamien > -- > http://fedoraproject.org/wiki/XavierLamien > GPG-Key ID: F3903DEB > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From harald at redhat.com Sat Sep 6 10:52:56 2008 From: harald at redhat.com (Harald Hoyer) Date: Sat, 06 Sep 2008 12:52:56 +0200 Subject: Boot speedup with readahead Message-ID: Hello fellow Fedora developers, recently readahead was modified to adapt to system file changes and to start very early in the boot process via upstart. I would like to encourage you to test readahead-1.4.5-3.fc10 from rawhide (even possible on F9), which I built some minutes ago. It may take a day to reach your local mirror. # yum --enablerepo=rawhide install readahead or # yum --enablerepo=rawhide update readahead With the next reboot readahead-collector runs and collects the information which files are used during the boot process. The next reboot then, readahead read ahead those files and the boot process (from init start to gdm login screen) should be approx. 10% faster. Hope it speeds up your boot process a little bit. Please report any changes in your boot time (can be measured with a stop clock or bootchart). You can modify /etc/sysconfig/readahead to turn readahead on/off. From rawhide at fedoraproject.org Sat Sep 6 11:05:45 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sat, 6 Sep 2008 11:05:45 +0000 (UTC) Subject: rawhide report: 20080906 changes Message-ID: <20080906110546.066701F823B@releng2.fedora.phx.redhat.com> New package alt-ergo Alt-Ergo automatic theorem prover New package gupnp-av GUPnP-AV is a collection of helpers for building UPnP AV applications New package iok Indic Onscreen Virtual Keyboard New package justmoon Just Moon is lunar observing software for Linux New package liblayout CSS based layouting framework New package netbeans-resolver Resolver subproject of xml-commons patched for NetBeans New package ocaml-reins Library of OCaml persistent data structures New package perl-HTML-FromText Convert plain text to HTML New package qrq Morse telegraphy trainer New package samefile An utility to find identical files on the file system New package xfce-mcs-plugins-extra Extra plugins for the Xfce mcs manager Removed package qa-assistant Updated Packages: R-affyio-1.8.1-1.fc10 --------------------- * Fri Sep 5 18:00:00 2008 pingou 1.8.1-1 - Update to version 1.8.1 at-spi-1.23.91-3.fc10 --------------------- * Fri Sep 5 18:00:00 2008 Matthias Clasen - 1.23.91-3 - Fix an evo crash caused by the greeter crash fix * Fri Sep 5 18:00:00 2008 Matthias Clasen - 1.23.91-2 - Fix a greeter crash brutus-keyring-0.9.30-1.fc10 ---------------------------- * Fri Sep 5 18:00:00 2008 Brian Pepple - 0.9.30-1 * Update to 0.9.30. - Update license tag. * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 0.9.0-7 - Autorebuild for GCC 4.3 cobbler-1.2.2-1.fc10 -------------------- * Fri Sep 5 18:00:00 2008 Michael DeHaan - 1.2.2-1 - Upstream changes (see CHANGELOG) dfu-programmer-0.4.6-1.fc10 --------------------------- * Fri Aug 29 18:00:00 2008 Weston Schmidt - 0.4.6-1 - change udev rules and permissions to be hal based * Wed Aug 20 18:00:00 2008 Weston Schmidt - 0.4.5-1 - added 4K bootloader support - added eeprom-dump and eeprom-flash support - fixed the Source0 url djvulibre-3.5.20-3.fc10 ----------------------- * Fri Jun 6 18:00:00 2008 Dennis Gilmore 3.5.20-3 - BR qt3-devel eclipse-photran-4.0.0-0.b4.fc10.3 --------------------------------- * Fri Sep 5 18:00:00 2008 Orion Poplawski - 4.0.0-0.b4.3 - Fix xlf Requires erlang-R12B-3.3.fc10 -------------------- * Fri Sep 5 18:00:00 2008 Gerard Milmeister - R12B-3.3.fc10 - fixed sslrpath patch * Thu Jul 17 18:00:00 2008 Tom "spot" Callaway - R12B-3.2 - fix license tag fedora-icon-theme-1.0.0-2.fc10 ------------------------------ * Fri Sep 5 18:00:00 2008 Matthias Clasen - 1.0.0-2 - Switch to Echo as the default icon theme foomatic-3.0.2-66.fc10 ---------------------- * Fri Sep 5 18:00:00 2008 Tim Waugh 3.0.2-66 - Fixed filename handling in foomatic-rip (bug #457679). gauche-0.8.13-2.fc10 -------------------- * Mon Apr 14 18:00:00 2008 Gerard Milmeister - 0.8.13-2 - set correct path to slib gcc-4.3.2-3 ----------- * Sat Sep 6 18:00:00 2008 Jakub Jelinek 4.3.2-3 - don't run tests that require Altivec hw on non-Altivec powerpcs - make sure none of libgcj binaries/libraries contains /usr/%{lib} in RPATH - fix up BuildRoot * Fri Sep 5 18:00:00 2008 Jakub Jelinek 4.3.2-2 - update from gcc-4_3-branch - PRs c++/37348, c/37261, fortran/36371, fortran/37193, middle-end/36449, target/36332, target/37168 - make ChangeLog files and gcc.info valid UTF-8, remove gnative2ascii from gcc-gnat, comment out most of the Obsoletes (#225778) - on x86_64 decrease frame size in varargs functions that don't need saving gpr or fpr registers - fix ICE on implicitly determined firstprivate where copy ctor or dtor needs synthetization (PR c++/37189) - document how to recrease the tarball gdl-0.9-0.rc1.4.fc10 -------------------- * Fri Sep 5 18:00:00 2008 - Orion Poplawski - 0.9-0.rc1.4 - Add a requires on plplot to pull in drivers (bug#458277) gnome-settings-daemon-2.23.91-5.fc10 ------------------------------------ * Fri Sep 5 18:00:00 2008 Matthias Clasen - 2.23.91-5 - Try harder to use the keyboard layout that gdm tells us gtk-vnc-0.3.7-1.fc10 -------------------- * Fri Sep 5 18:00:00 2008 Matthias Clasen - 0.3.7-1 - Update to 0.3.7 gtk2-2.14.0-4.fc10 ------------------ gtkmm24-2.13.7-2.fc10 --------------------- * Fri Sep 5 18:00:00 2008 Mamoru Tasaka - 2.13.7-2 - Patch from svn temporarily to make compatible with GTK 2.14 (bug 461227) iwl4965-firmware-228.57.2.21-3 ------------------------------ * Fri Sep 5 18:00:00 2008 kwizart < kwizart at gmail.com > - 228.57.2.21-3 - Remove ppc/ppc64 from ExcludedArches jgroups-2.2.9.2-4.6.fc10 ------------------------ * Wed Jul 9 18:00:00 2008 Tom "spot" Callaway - 0:2.2.9.2-4.5 - drop repotag * Wed Jul 9 18:00:00 2008 Deepak Bhole 2.2.9.2-4.6 - Fix bouncycastle classpath * Thu May 29 18:00:00 2008 Tom "spot" Callaway - 0:2.2.9.2-4jpp.4 - fix license tag * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 0:2.2.9.2-4jpp.3 - Autorebuild for GCC 4.3 * Thu Sep 27 18:00:00 2007 Jesse Keating - 2.2.9.2-3jpp.3 - Fix the group typo. kacst-fonts-2.0-1.fc10 ---------------------- * Fri Sep 5 18:00:00 2008 Rahul Bhalerao - 2.0-1.fc10 - Updated to new upstream version konq-plugins-4.1.1-1.fc10 ------------------------- * Fri Aug 29 18:00:00 2008 Than Ngo 4.1.1-1 - 4.1.1 libHX-1.23-1.fc10 ----------------- * Fri Sep 5 18:00:00 2008 Till Maas - 1.23-1 - Update to latest version libfwbuilder-3.0.0-1.fc10 ------------------------- * Fri Sep 5 18:00:00 2008 Ralf Ertzinger 3.0.0-1 - Update to 3.0.0 * Sat Apr 5 18:00:00 2008 Ralf Ertzinger 2.1.16-3 - Change BuildRequires to qt3-devel libmusicbrainz3-3.0.1-4.fc10 ---------------------------- * Fri Sep 5 18:00:00 2008 Rex Dieter 3.0.1-4 - Build docs (#461238) - -devel: drop extraneous Requires libprelude-0.9.20.1-1.fc10 -------------------------- * Fri Sep 5 18:00:00 2008 Steve Grubb - 0.9.20.1-1 - New upstream bugfix release - Get rid of rpath and enable test suite except on PPC libxklavier-3.7-1.fc10 ---------------------- * Fri Sep 5 18:00:00 2008 Matthias Clasen - 3.7-1 - Update to 3.7 maven2-2.0.4-10.15.fc10 ----------------------- * Fri Sep 5 18:00:00 2008 Deepak Bhole 2.0.4-10.15 - Fall back to gcj build * Wed Aug 13 18:00:00 2008 Deepak Bhole 2.0.4-10.14 - Build with IcedTea * Wed Aug 13 18:00:00 2008 Deepak Bhole 2.0.4-10.13 - Build for ppc64 * Wed Jul 9 18:00:00 2008 Tom "spot" Callaway - 2.0.4-10.12 - drop repotag * Thu May 29 18:00:00 2008 Tom "spot" Callaway 2.0.4-10jpp.11 - fix license tag nss-3.12.1.1-2.fc10 ------------------- * Fri Sep 5 18:00:00 2008 Kai Engert - 3.12.1.1-2 - Update to NSS_3_12_1_RC2 openoffice.org-3.0.0-4.2.fc10 ----------------------------- * Thu Sep 4 18:00:00 2008 Caol??n McNamara - 1:3.0.0-4.2 - Resolves: rhbz#460755 TryExec oowriter on brwriter.desktop etc - Resolves: rhbz#460883 openoffice.org-3.0.0.ooo93419.svx.ref_deref.before.ctored.patch - defuzz patches - add openoffice.org-3.0.0.ooo93366.fpicker_in_main.patch - add openoffice.org-3.0.0.oooXXXXX.filter.latex.patch - add openoffice.org-3.0.0.ooo93515.vcl.jrb-frames.patch to get better focus for new frames when already running and behind in stacking order pam_mount-0.47-1.fc10 --------------------- * Fri Sep 5 18:00:00 2008 Till Maas - 0.47-1 - Update to new version that includes a security fix: https://sourceforge.net/project/shownotes.php?release_id=624240 - Add lzma BR and unpack source manually - Update libHX requirements - add new binary perl-Class-MethodMaker-2.12-1.fc10 ---------------------------------- * Fri Sep 5 18:00:00 2008 Daniel P. Berrange - 2.12-1 - Update to new release for rhbz #461285 perl-MIME-Lite-3.01-7.fc10 -------------------------- * Tue Sep 2 18:00:00 2008 Paul Howarth 3.01-7 - fix FTBFS (#449558) perl-Module-ExtractUse-0.23-1.fc10 ---------------------------------- * Fri Sep 5 18:00:00 2008 Daniel P. Berrange - 0.23-1 - Update to 0.23 release perl-Test-YAML-Meta-0.11-1.fc10 ------------------------------- * Fri Sep 5 18:00:00 2008 Daniel Berrange - 0.11-1 - Update to 0.11 release php-pear-Log-1.11.2-1.fc10 -------------------------- * Fri Sep 5 18:00:00 2008 Remi Collet 1.11.2-1 - update to 1.11.2 php-pear-Net-DIME-1.0.1-1.fc10 ------------------------------ * Fri Sep 5 18:00:00 2008 Remi Collet 1.0.1-1 - update to 1.0.1 plague-0.4.5.3-1.fc10 --------------------- * Fri Sep 5 18:00:00 2008 Michael Schwendt - 0.4.5.3-1 - update to 0.4.5.3 for sqlite2 compatibility fixes for Fedora - merge fedora pkg spec changes - include the www tree as server pkg docs plplot-5.9.0-2.svn8752.fc10 --------------------------- * Fri Sep 5 18:00:00 2008 - Orion Poplawski - 5.9.0-2.svn8752 - Update to svn revision 8752 - Add new gnome-python2 BRs - Update build_doc BRs - Add ocaml sub-package for OCaml interface - Enable "D" interface. - Re-enable psttfc test, disable perl and compare tests plymouth-0.6.0-0.2008.09.05.3.fc10 ---------------------------------- * Fri Sep 5 18:00:00 2008 Ray Strode 0.5.0-0.2008.09.05.2 - Try to support multiple serial consoles better (bug 460565) * Fri Sep 5 18:00:00 2008 Ray Strode 0.5.0-0.2008.09.05.1 - Fix some confusion with password handling in details plugin * Fri Sep 5 18:00:00 2008 Bill Nottingham 0.6.0-0.2008.09.05.3 - make the text plugin use the system release info rather than a hardcoded 'Fedora 10' python-lxml-2.1.2-1.fc10 ------------------------ * Fri Sep 5 18:00:00 2008 Jeffrey C. Ollie - 2.1.2-1 - 2.1.2 (2008-09-05) - Features added - - * lxml.etree now tries to find the absolute path name of files when - parsing from a file-like object. This helps custom resolvers when - resolving relative URLs, as lixbml2 can prepend them with the path of - the source document. - - Bugs fixed - - * Memory problem when passing documents between threads. - * Target parser did not honour the recover option and raised an exception - instead of calling .close() on the target. qcad-2.0.5.0-8.fc10 ------------------- qsynth-0.3.3-1.fc10 ------------------- * Fri Sep 5 18:00:00 2008 Michel Salim - 0.3.3-1 - Update to 0.3.3 * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.2.5-8 - fix license tag scons-1.0.0-1.d20080826.fc10 ---------------------------- * Fri Sep 5 18:00:00 2008 Gerard Milmeister - 1.0.0-1.d20080826 - new release 1.0.0 sectool-0.8.6-1.fc10 -------------------- * Fri Sep 5 18:00:00 2008 Peter Vrabec - 0.8.6-1 - upgrade, see changelog splint-3.1.2-2.fc10 ------------------- * Fri Sep 5 18:00:00 2008 Tom "spot" Callaway - 3.1.2-2 - fix license tag sqlgrey-1.7.6-1.fc10 -------------------- * Fri Sep 5 18:00:00 2008 Tom "spot" Callaway 1.7.6-1 - fix license tag - update to 1.7.6 squirrelmail-1.4.15-1.fc10 -------------------------- * Fri Sep 5 18:00:00 2008 Tom "spot" Callaway - 1.4.15-1 - fix license tag - update to 1.4.15 ss5-3.6.4-1.fc10 ---------------- * Fri Sep 5 18:00:00 2008 Tom "spot" Callaway - 3.6.4-1 - fix license tag - update to 3.6.4 sshfp-1.1.3-2.fc10 ------------------ * Fri Sep 5 18:00:00 2008 Tom "spot" Callaway - 1.1.3-2 - fix license tag (man page says v2+, but code says v2) * Tue May 15 18:00:00 2007 Paul Wouters - 1.1.3-1 - Upgraded to 1.1.3 stardict-dic-en-2.4.2-5.fc10 ---------------------------- * Fri Sep 5 18:00:00 2008 Tom "spot" Callaway - 2.4.2-5 - use correct license tag * Fri Sep 5 18:00:00 2008 Tom "spot" Callaway - 2.4.2-4 - fix license tag stardict-dic-ja-2.4.2-4.fc10 ---------------------------- * Fri Sep 5 18:00:00 2008 Tom "spot" Callaway - 2.4.2-4 - fix license tag stardict-dic-ru-2.4.2-5.fc10 ---------------------------- * Fri Sep 5 18:00:00 2008 Tom "spot" Callaway - 2.4.2-5 - Really fix license tag, include documentation * Fri Sep 5 18:00:00 2008 Tom "spot" Callaway - 2.4.2-4 - fix license tag stardict-dic-zh_CN-2.4.2-4.fc10 ------------------------------- * Fri Sep 5 18:00:00 2008 Tom "spot" Callaway - 2.4.2-4 - fix license tag - remove dictionaries for which the licensing is unclear (or outright forbidden) stardict-dic-zh_TW-2.4.2-4.fc10 ------------------------------- * Fri Sep 5 18:00:00 2008 Tom "spot" Callaway - 2.4.2-4 - remove files for which licensing is unclear (or bad) - add xdict files (we know they are good) - fix license tag svnmailer-1.0.8-6.fc10 ---------------------- * Fri Sep 5 18:00:00 2008 Sven Lankes 1.0.8-6 - Fix license tag - Correct patch invocation * Tue Apr 8 18:00:00 2008 Michael Fleming 1.0.8-5 - Update Requires (remove obsolete abi() generation) - Add patch to fix crash when sending multipart messages (bz# 438112) - Update BuildRequires to fix bz# 4407884 - Add egg-info files. tomcat6-6.0.18-1.1.fc10 ----------------------- * Tue Aug 26 18:00:00 2008 David Walluck 0:6.0.18-1.1 - 6.0.18 - Resolves: CVE-2008-1232, CVE-2008-1947, CVE-2008-2370, CVE-2008-2938 - fix definition of java.security.policy with d%{name} start-security - don't pass $CATALINA_OPTS with d%{name} stop - redefine tempdir and workdir for tmpwatch workaround - change eclipse-ecj references to ecj xfce4-battery-plugin-0.5.1-1.fc10 --------------------------------- * Fri Sep 5 18:00:00 2008 Christoph Wickert - 0.5.1-1 - Update to 0.5.1 - Remove acpi.patch (included upstream) - Remove lower-acpi-polling.patch (upstream use different values) xfsprogs-2.10.1-1.fc10 ---------------------- * Fri Sep 5 18:00:00 2008 Eric Sandeen 2.10.1-1 - Update to xfsprogs 2.10.1 - Add ASCII case-insensitive support to xfsprogs. - xfs_repair fixes * Wed Jun 4 18:00:00 2008 Eric Sandeen 2.9.8-2 - Tidy up multilib hack for non-multilib arches & add sparc (#448452) * Wed Jun 4 18:00:00 2008 Dennis Gilmore 2.9.8-3 - sparc32 is built using the sparcv9 variant xml-commons-resolver-1.1-2.14.fc10 ---------------------------------- * Fri Sep 5 18:00:00 2008 Deepak Bhole 1.1-2.14 - Build with IcedTea to escape sinjdoc issues * Thu Jul 10 18:00:00 2008 Tom "spot" Callaway - 0:1.1-2.13 - drop repotag - fix license tag * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 0:1.1-2jpp.12 - Autorebuild for GCC 4.3 Summary: Added Packages: 11 Removed Packages: 1 Modified Packages: 59 Broken deps for i386 ---------------------------------------------------------- audacious-plugins-1.5.1-1.fc10.i386 requires libmtp.so.7 claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 fwbuilder-2.1.16-2.fc9.i386 requires libfwbuilder = 0:2.1.16 fwbuilder-2.1.16-2.fc9.i386 requires libfwbuilder.so.7 fwbuilder-ipf-2.1.16-2.fc9.i386 requires libfwbuilder.so.7 fwbuilder-ipf-2.1.16-2.fc9.i386 requires libfwcompiler.so.7 fwbuilder-ipfw-2.1.16-2.fc9.i386 requires libfwbuilder.so.7 fwbuilder-ipfw-2.1.16-2.fc9.i386 requires libfwcompiler.so.7 fwbuilder-ipt-2.1.16-2.fc9.i386 requires libfwbuilder.so.7 fwbuilder-ipt-2.1.16-2.fc9.i386 requires libfwcompiler.so.7 fwbuilder-pf-2.1.16-2.fc9.i386 requires libfwbuilder.so.7 fwbuilder-pf-2.1.16-2.fc9.i386 requires libfwcompiler.so.7 grisbi-0.5.9-5.fc9.i386 requires tetex-unicode gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.11-1.fc10.i386 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.i386 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.i386 requires perl(MT::Entry) highlight-2.6.11-1.fc10.i386 requires perl(MT) highlight-2.6.11-1.fc10.i386 requires perl(MT::Template::Context) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so poker3d-1.1.36-10.fc10.i386 requires libosg.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgUtil.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgSim.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgTerrain.so.35 poker3d-1.1.36-10.fc10.i386 requires libOpenThreads.so.10 poker3d-1.1.36-10.fc10.i386 requires libosgGA.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgFX.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgManipulator.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgDB.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgParticle.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgViewer.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgText.so.35 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for x86_64 ---------------------------------------------------------- audacious-plugins-1.5.1-1.fc10.x86_64 requires libmtp.so.7()(64bit) claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) fwbuilder-2.1.16-2.fc9.x86_64 requires libfwbuilder.so.7()(64bit) fwbuilder-2.1.16-2.fc9.x86_64 requires libfwbuilder = 0:2.1.16 fwbuilder-ipf-2.1.16-2.fc9.x86_64 requires libfwbuilder.so.7()(64bit) fwbuilder-ipf-2.1.16-2.fc9.x86_64 requires libfwcompiler.so.7()(64bit) fwbuilder-ipfw-2.1.16-2.fc9.x86_64 requires libfwbuilder.so.7()(64bit) fwbuilder-ipfw-2.1.16-2.fc9.x86_64 requires libfwcompiler.so.7()(64bit) fwbuilder-ipt-2.1.16-2.fc9.x86_64 requires libfwbuilder.so.7()(64bit) fwbuilder-ipt-2.1.16-2.fc9.x86_64 requires libfwcompiler.so.7()(64bit) fwbuilder-pf-2.1.16-2.fc9.x86_64 requires libfwbuilder.so.7()(64bit) fwbuilder-pf-2.1.16-2.fc9.x86_64 requires libfwcompiler.so.7()(64bit) grisbi-0.5.9-5.fc9.x86_64 requires tetex-unicode gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Entry) highlight-2.6.11-1.fc10.x86_64 requires perl(MT) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Template::Context) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgFX.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgGA.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgTerrain.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosg.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgSim.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgText.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgDB.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libOpenThreads.so.10()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgManipulator.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgParticle.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgViewer.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgUtil.so.35()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for ppc ---------------------------------------------------------- audacious-plugins-1.5.1-1.fc10.ppc requires libmtp.so.7 claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) fwbuilder-2.1.16-2.fc9.ppc requires libfwbuilder = 0:2.1.16 fwbuilder-2.1.16-2.fc9.ppc requires libfwbuilder.so.7 fwbuilder-ipf-2.1.16-2.fc9.ppc requires libfwbuilder.so.7 fwbuilder-ipf-2.1.16-2.fc9.ppc requires libfwcompiler.so.7 fwbuilder-ipfw-2.1.16-2.fc9.ppc requires libfwbuilder.so.7 fwbuilder-ipfw-2.1.16-2.fc9.ppc requires libfwcompiler.so.7 fwbuilder-ipt-2.1.16-2.fc9.ppc requires libfwbuilder.so.7 fwbuilder-ipt-2.1.16-2.fc9.ppc requires libfwcompiler.so.7 fwbuilder-pf-2.1.16-2.fc9.ppc requires libfwbuilder.so.7 fwbuilder-pf-2.1.16-2.fc9.ppc requires libfwcompiler.so.7 grisbi-0.5.9-5.fc9.ppc requires tetex-unicode gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.11-1.fc10.ppc requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc requires perl(MT::Entry) highlight-2.6.11-1.fc10.ppc requires perl(MT) highlight-2.6.11-1.fc10.ppc requires perl(MT::Template::Context) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so poker3d-1.1.36-10.fc10.ppc requires libosg.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgUtil.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgSim.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgTerrain.so.35 poker3d-1.1.36-10.fc10.ppc requires libOpenThreads.so.10 poker3d-1.1.36-10.fc10.ppc requires libosgGA.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgFX.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgManipulator.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgDB.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgParticle.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgViewer.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgText.so.35 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires libbfd-2.18.50.0.8-2.fc10.so stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires libopcodes-2.18.50.0.8-2.fc10.so vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for ppc64 ---------------------------------------------------------- audacious-plugins-1.5.1-1.fc10.ppc64 requires libmtp.so.7()(64bit) claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) fwbuilder-2.1.16-2.fc9.ppc64 requires libfwbuilder.so.7()(64bit) fwbuilder-2.1.16-2.fc9.ppc64 requires libfwbuilder = 0:2.1.16 fwbuilder-ipf-2.1.16-2.fc9.ppc64 requires libfwbuilder.so.7()(64bit) fwbuilder-ipf-2.1.16-2.fc9.ppc64 requires libfwcompiler.so.7()(64bit) fwbuilder-ipfw-2.1.16-2.fc9.ppc64 requires libfwbuilder.so.7()(64bit) fwbuilder-ipfw-2.1.16-2.fc9.ppc64 requires libfwcompiler.so.7()(64bit) fwbuilder-ipt-2.1.16-2.fc9.ppc64 requires libfwbuilder.so.7()(64bit) fwbuilder-ipt-2.1.16-2.fc9.ppc64 requires libfwcompiler.so.7()(64bit) fwbuilder-pf-2.1.16-2.fc9.ppc64 requires libfwbuilder.so.7()(64bit) fwbuilder-pf-2.1.16-2.fc9.ppc64 requires libfwcompiler.so.7()(64bit) grisbi-0.5.9-5.fc9.ppc64 requires tetex-unicode gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Entry) highlight-2.6.11-1.fc10.ppc64 requires perl(MT) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Template::Context) livecd-tools-018-1.fc10.ppc64 requires yaboot mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 poker3d-1.1.36-10.fc10.ppc64 requires libosgFX.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgGA.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgTerrain.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosg.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgSim.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgText.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgDB.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libOpenThreads.so.10()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgManipulator.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgParticle.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgViewer.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgUtil.so.35()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 From mschwendt at gmail.com Sat Sep 6 11:30:24 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 6 Sep 2008 13:30:24 +0200 Subject: Note to package maintainers: unowned directories Message-ID: <20080906133024.e7c0852d.mschwendt@gmail.com> Some package maintainers have asked in private about "unowned directories", so here is a revised cut'n'paste job of the various replies. [...] The background: https://fedoraproject.org/wiki/Packaging/ReviewGuidelines MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory [...] The term "unowned directory" (or "orphaned directory") refers to a packaging mistake, where * a package includes files within a directory it creates, but _not_ the directory itself, and * none of the package's dependencies provide the directory either, and * the directory belongs to your package and does not belong to any core package or base filesystem package that is considered essential/fundamental. This has several side-effects: [1] A restrictive superuser umask during package installation can create inaccessible directories. Scenario: umask 077 ; yum update or rpm -ivh ... Symptoms: Run-time problems. For example, unreadable subdirs below %_libdir disable plugins. Unreadable subdirs below %_datadir prevent application data, help texts, and graphics from being accessed. Several sorts of users fix such permission problems with chmod instead of taking the time to report it as a bug. It is common belief that such bugs are so obvious they would be found by the package maintainer or will be reported by other users. [2] Upon uninstalling the package (or upgrading to another version), the old directory is not removed from the file system, because in the RPM database it does not belong into the package. Especially if directories contain a version number, they clutter up the file system with every update which doesn't remove old directories. [3] Unowned/orphaned directories cannot be checked with rpm -V and not with rpm -qf either. [4] Upstream source tarball configuration can fail, because it is searched in old and empty versioned header directories, or because it is tried to use multiple versioned directories instead of just the latest valid one. Examples of common packaging mistakes in spec %files lists: [1] %{_datadir}/foo/* This includes everything _in_ "foo", but not "foo" itself. "rpm -qlv pkgname" will show a missing drwxr-xr-x entry for "foo". Correct would be %{_datadir}/foo/ to include the directory _and_ the entire tree below it. [2] %{_docdir}/%{name}-%{version}/* %{_includedir}/%{name}-%{version}/*.h Same as in [1] but creates an additional unowned directory everytime %version changes. Correct would be: %{_docdir}/%{name}-%{version}/ %dir %{_includedir}/%{name}-%{version} %{_includedir}/%{name}-%{version}/*.h [3] %dir %{_libdir}/foo-2/fu %dir %{_libdir}/foo-2/bar %{_libdir}/foo-2/fu/*.so %{_libdir}/foo-2/bar/config* Here it is attempted at including the directories explicitly with the %dir macro. However, while "bar" is included, "foo-2" is not. Typically packagers run into that mistake if all installed files are stored only in subdirs of the parent "foo-2" directory. Correct would be: %dir %{_libdir}/foo-2 %dir %{_libdir}/foo-2/fu %dir %{_libdir}/foo-2/bar %{_libdir}/foo-2/fu/*.so %{_libdir}/foo-2/bar/config* [4] %{_datadir}/%{name}/db/raw/*.db %{_datadir}/%{name}/pixmaps/*.png Here only specific data files are included, and all (4!) directories below %_datadir are unowned. Correct would be: %dir %{_datadir}/%{name} %dir %{_datadir}/%{name}/db %dir %{_datadir}/%{name}/db/raw %dir %{_datadir}/%{name}/pixmaps %{_datadir}/%{name}/db/raw/*.db %{_datadir}/%{name}/pixmaps/*.png It's easy to find unowned directories with "rpmls" from rpmdevtools or "rpm -qlv". Just a bit of carefulness is needed to not include core filesystem directories, such as %_bindir, %_libdir (and obvious others, e.g. from the "filesystem" pkg) which don't belong into your package. HTH From alain.portal at free.fr Sat Sep 6 12:43:52 2008 From: alain.portal at free.fr (Alain PORTAL) Date: Sat, 6 Sep 2008 14:43:52 +0200 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <200809061443.52683.alain.portal@free.fr> Hi, Le vendredi 05 septembre 2008, Matt Domsch a ?crit : > gpsim-0.22.0-5.fc8 [u'434061 ASSIGNED'] (build/make) dionysos As I'm still on FC6, I'm not able to fix this bug. Any help will be appreciated. Regards, Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- 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 alain.portal at free.fr Sat Sep 6 13:28:35 2008 From: alain.portal at free.fr (Alain PORTAL) Date: Sat, 6 Sep 2008 15:28:35 +0200 Subject: Unable to access cvs Message-ID: <200809061528.35585.alain.portal@free.fr> Hi, I don't know why, but I'm unable to access cvs: Permission denied (publickey). cvs [checkout aborted]: end of file from server (consult above messages if any) I updated certificate as said here: https://www.redhat.com/archives/fedora-devel-announce/2008-August/msg00008.html Is there something I missed? I can't fix a bug which is a F10Blocker. Regards, Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- 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 hun at n-dimensional.de Sat Sep 6 14:01:20 2008 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Sat, 06 Sep 2008 16:01:20 +0200 Subject: F9 chkfontpath replacement? In-Reply-To: <200809052036.m85KaxLO006814@jasmine.xos.nl> References: <200809052036.m85KaxLO006814@jasmine.xos.nl> Message-ID: <48C28D30.8020109@n-dimensional.de> Jos Vos wrote: > I see that in F9 chkfontpath is gone. Is there a recommend way to > perform a similar function? > > In some font rpms I'm maintaining, putting fonts in some specific > directories, I used to call chkfontpath with a local font dir > in %post. I got a bug pointing to this while we were preparing for F-8: http://fedoraproject.org/wiki/Releases/FeatureNoMoreXFS -- Hans Ulrich Niedermann From gnomeuser at gmail.com Sat Sep 6 14:07:01 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Sat, 6 Sep 2008 16:07:01 +0200 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <1220646108.4331.2.camel@PB3.Linux> <1dedbbfc0809051347g383ccf70o1686a982388b685@mail.gmail.com> Message-ID: <1dedbbfc0809060707vaf23029w2aba4a6ca34d1a1@mail.gmail.com> 2008/9/6 Michel Salim > 2008/9/5 David Nielsen : > > > > > > Den 5. sep. 2008 22.21 skrev Paul : > >> > >> Hi, > >> > >> > monodevelop-0.19-6.fc9 [u'449441 ASSIGNED'] (build/make) pfj > >> > >> This is a pain. Every time I've tried to build MD 1.0, koji has thrown a > >> wobbler complaining that %{_libdir}/mono/gac can't be found! I will look > >> at it again over this next week though. > > > > Didn't the wonderful Michel fix this recently, he cleaned up the spec and > > bumped us succesfully to 2.0 beta. > > > I haven't touched the F-9 branch; as I'm not running F-9 anymore, and > with the changes in the Mono stack, I didn't want to risk any > breakage. Paul likely knows more about the difference between F-9's > mono and Rawhide's -- Paul, you could perhaps backport the Rawhide > monodevelop to F-9? Some of the BRs might need to be changed. I believe the new monodevelop requires gtk-sharp-2.12 which in return will require us to push everything that depends on gtk-sharp2 (with patches or updated versions from rawhide). I would be in favor of this as it would make our Mono stack a bit more consistent across the supported platforms and it would allow us to have the same supported versions of many programs on every platform. Something like gnome-do e.g. is generally only supported in the latest release by upstream and we cannot put that in F9 because our stack cannot support it currently. Maybe once Mono 2.0 Final hits we can decide if a coordinated push to F9 (and F8 if it is still supported at such a time) is desirable, that would give us time to clean everything up and maybe the friendly ppc arch team can help us fix nant as well so ppc users can get a complete mono stack. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at vanpienbroek.nl Sat Sep 6 14:10:35 2008 From: erik at vanpienbroek.nl (Erik van Pienbroek) Date: Sat, 06 Sep 2008 16:10:35 +0200 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <1220710235.14268.9.camel@alguno.terneuzen.openftd.org> Op vrijdag 05-09-2008 om 20:56 uur [tijdzone +0300], schreef Vasile Gaburici: > On Fri, Sep 5, 2008 at 6:40 PM, Matt Domsch wrote: > > > pan-0.132-2.fc8 [u'433970 ASSIGNED'] (build/make) adalloz,mpeters > > I've linked to a working srpm on the bug page like a month ago. My > srpm still works for dist-f10: > http://koji.fedoraproject.org/koji/taskinfo?taskID=809090 > > But I have no commit rights, so somebody else needs to do the honors. > I just build a new version of pan (0.133) for rawhide and F9 which incorporates the gcc 4.3 fix. Regards, Erik van Pienbroek From tibbs at math.uh.edu Sat Sep 6 14:20:50 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 06 Sep 2008 09:20:50 -0500 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <200809061443.52683.alain.portal@free.fr> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <200809061443.52683.alain.portal@free.fr> Message-ID: >>>>> "AP" == Alain PORTAL writes: AP> Hi, Le vendredi 05 septembre 2008, Matt Domsch a ?crit : >> gpsim-0.22.0-5.fc8 [u'434061 ASSIGNED'] (build/make) dionysos AP> As I'm still on FC6, I'm not able to fix this bug. Any help will AP> be appreciated. Well, you can still do scratch builds so you don't technically need to have an updated system, but it certainly makes things faster. I think this package simply has the C++ issues that we've seen in many other packages. Here's the first failure: g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -MT parse.lo -MD -MP -MF .deps/parse.Tpo -c parse.cc -fPIC -DPIC -o .libs/parse.o In file included from ../src/registers.h:34, from ../src/ui.h:11, from ../src/cmd_gpsim.h:5, from misc.h:24, from parse.yy:33: ../src/value.h: In function 'bool operator!=(String&, String&)': ../src/value.h:590: error: 'strcmp' was not declared in this scope Perhaps needs #include ? - J< From vgaburici at gmail.com Sat Sep 6 14:26:18 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Sat, 6 Sep 2008 17:26:18 +0300 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <200809061443.52683.alain.portal@free.fr> Message-ID: That package has a *lot* of failures like that; pretty old C++ code... On Sat, Sep 6, 2008 at 5:20 PM, Jason L Tibbitts III wrote: >>>>>> "AP" == Alain PORTAL writes: > > AP> Hi, Le vendredi 05 septembre 2008, Matt Domsch a ?crit : > >>> gpsim-0.22.0-5.fc8 [u'434061 ASSIGNED'] (build/make) dionysos > > AP> As I'm still on FC6, I'm not able to fix this bug. Any help will > AP> be appreciated. > > Well, you can still do scratch builds so you don't technically need to > have an updated system, but it certainly makes things faster. > > I think this package simply has the C++ issues that we've seen in many > other packages. Here's the first failure: > > g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/gtk-2.0 > -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 > -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 > -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -O2 -g -pipe > -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector > --param=ssp-buffer-size=4 -m64 -mtune=generic -MT parse.lo -MD -MP > -MF .deps/parse.Tpo -c parse.cc -fPIC -DPIC -o .libs/parse.o > In file included from ../src/registers.h:34, > from ../src/ui.h:11, > from ../src/cmd_gpsim.h:5, > from misc.h:24, > from parse.yy:33: > ../src/value.h: In function 'bool operator!=(String&, String&)': > ../src/value.h:590: error: 'strcmp' was not declared in this scope > > Perhaps needs #include ? > > - J< > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From gnomeuser at gmail.com Sat Sep 6 14:52:57 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Sat, 6 Sep 2008 16:52:57 +0200 Subject: Unable to access cvs In-Reply-To: <200809061528.35585.alain.portal@free.fr> References: <200809061528.35585.alain.portal@free.fr> Message-ID: <1dedbbfc0809060752q671fd587kfe305bafbb96c661@mail.gmail.com> Den 6. sep. 2008 15.28 skrev Alain PORTAL : > Hi, > > I don't know why, but I'm unable to access cvs: > > Permission denied (publickey). > cvs [checkout aborted]: end of file from server (consult above messages if > any) > > I updated certificate as said here: > > https://www.redhat.com/archives/fedora-devel-announce/2008-August/msg00008.html > > Is there something I missed? > > I can't fix a bug which is a F10Blocker. In the same vein, click any package in koji gives a 403 message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcallawa at redhat.com Sat Sep 6 15:26:10 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 06 Sep 2008 11:26:10 -0400 Subject: A couple of license-relate questions In-Reply-To: <200809041611.55232.konrad@tylerc.org> References: <1220567476.7704.8.camel@localhost.localdomain> <200809041611.55232.konrad@tylerc.org> Message-ID: <1220714770.3839.26.camel@localhost.localdomain> On Thu, 2008-09-04 at 16:11 -0700, Conrad Meyer wrote: > Quoth Tom "spot" Callaway: > > On Thu, 2008-09-04 at 22:11 +0300, Vasile Gaburici wrote: > > > 2) Can someone take a look at the Adobe Glyph List license > > > [http://www.adobe.com/devnet/opentype/archives/glyphlist.txt] and > > > determine what is the appropriate rpm license field for it? > > > > Need to run that one past the lawyers... it is worded strangely. > > > > ~spot > > I thought you were the lawyers, spot! Nah, I'm just the conduit to the lawyers. :) ~spot From sandeen at redhat.com Sat Sep 6 15:32:02 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Sat, 06 Sep 2008 10:32:02 -0500 Subject: Boot speedup with readahead In-Reply-To: References: Message-ID: <48C2A272.5000504@redhat.com> Harald Hoyer wrote: > Hello fellow Fedora developers, > > recently readahead was modified to adapt to system file changes and to start very early in the boot process > via upstart. Glad to see that! Sorry I helped put the hammer down on older readahead in the F8 era... but it was pretty broken back then ... ;) > I would like to encourage you to test readahead-1.4.5-3.fc10 from rawhide (even possible on F9), which I built > some minutes ago. It may take a day to reach your local mirror. > > # yum --enablerepo=rawhide install readahead > or > # yum --enablerepo=rawhide update readahead > > With the next reboot readahead-collector runs and collects the information which files are used during the > boot process. The next reboot then, readahead read ahead those files and the boot process (from init start to > gdm login screen) should be approx. 10% faster. So when / how often does readahead-collector run now? Thanks, -Eric > Hope it speeds up your boot process a little bit. Please report any changes in your boot time (can be measured > with a stop clock or bootchart). > > > You can modify /etc/sysconfig/readahead to turn readahead on/off. > From seandarcy2 at gmail.com Sat Sep 6 16:04:11 2008 From: seandarcy2 at gmail.com (sean darcy) Date: Sat, 06 Sep 2008 12:04:11 -0400 Subject: Fedora 8 and 9 updates status In-Reply-To: <1220630950.4273.14.camel@luminos.localdomain> References: <1220630950.4273.14.camel@luminos.localdomain> Message-ID: Jesse Keating wrote: > As you well know, we have been working hard to get updates for 8 and 9 > flowing again, complete with new package signing keys. Discussion has > been somewhat quiet on this front as we've all had our heads down and > have been working hard toward a solution, one that involves little to no > manual effort on behalf of our users. > > Today we've reached a major milestone in this progress. We have done a > successful compose of all the existing and as of yesterday pending > updates for Fedora 8 and Fedora 9, all signed with our new keys. These > updates will soon hit mirrors in a new set of directory locations. What > we don't have quite yet is the updated fedora-release package in the old > updates location that will get you the new keys and the new repo > locations. The last mile testing of this update requires that new > updates be live on the mirrors. > > Due to the size of the resigned updates, it may take a good while for > our sync process. This may delay getting the new fedora-release out > until tomorrow, but we'll be working hard on it. > > While we're working on this update, we'll also be drafting a FAQ page to > explain to users what it is that we're doing, and hopefully answer some > of the questions that will come up. This document will be living > though, and as you encounter questions yourself, or questions via one of > our many avenues of support (email, IRC, forums, LUGS, etc..) please > help us in growing that document. Announcements regarding the location > of said document and how to help with content will be coming shortly. > > We deeply appreciate the enormous magnitude of patience you the greater > community has shown us the Fedora project as we work though these > serious issues. It is a great testament to how wonderful it is to work > in and with the Fedora community. > > First, thanks for all the work to get this back on track. I went and got the new spins of qt-4.4. Now I can't install the because I don't have the new key. I realize I could turn off the key, but after last month, that seems dicier than it used to be. In any event, is the new key for updates 9 available someplace. I realize it'll be part of fedora release eventually. But the public key itself, is it out there someplace now? Thanks again. sean From paul at all-the-johnsons.co.uk Sat Sep 6 16:00:52 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 06 Sep 2008 17:00:52 +0100 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <1dedbbfc0809060707vaf23029w2aba4a6ca34d1a1@mail.gmail.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <1220646108.4331.2.camel@PB3.Linux> <1dedbbfc0809051347g383ccf70o1686a982388b685@mail.gmail.com> <1dedbbfc0809060707vaf23029w2aba4a6ca34d1a1@mail.gmail.com> Message-ID: <1220716852.20819.5.camel@PB3.Linux> Hi, Hmmm, HTML posting... Not nice... Shame on you all! > I haven't touched the F-9 branch; as I'm not running F-9 > anymore, and > with the changes in the Mono stack, I didn't want to risk any > breakage. Paul likely knows more about the difference between > F-9's > mono and Rawhide's -- Paul, you could perhaps backport the > Rawhide > monodevelop to F-9? Some of the BRs might need to be changed. > > I believe the new monodevelop requires gtk-sharp-2.12 which in return > will require us to push everything that depends on gtk-sharp2 (with > patches or updated versions from rawhide). It requires gnome-sharp-desktop as well, so there would be a large number of packages required for the new MD to be brought into F9. > I would be in favor of this as it would make our Mono stack a bit more > consistent across the supported platforms and it would allow us to > have the same supported versions of many programs on every platform. > Something like gnome-do e.g. is generally only supported in the latest > release by upstream and we cannot put that in F9 because our stack > cannot support it currently. Correct. This is one of the biggest reasons why my support for F9 is much slower, the changes in rawhide are massive and to backport many of them would break more than they would fix. > Maybe once Mono 2.0 Final hits we can decide if a coordinated push to > F9 (and F8 if it is still supported at such a time) is desirable, that > would give us time to clean everything up and maybe the friendly ppc > arch team can help us fix nant as well so ppc users can get a complete > mono stack. Mono 2.0 is due for release in the next week or so, so it should be there fully in F10 (though it will be a race!). I'd be much happier with F9 to have the 1.9.1 release (or even a full blown 2.0 release). This would make things a damned sight simpler to keep up to date. It would though need all the mono contributors to co-ordinate a single push. First mono/libgdiplus/mono-basic then gtk stack then MD/nant/mono-tools/monodoc/mono-addins then whatever else is there. Anyone interested in a mono-SIG? It could be useful! TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From Fedora at FamilleCollet.com Sat Sep 6 16:17:36 2008 From: Fedora at FamilleCollet.com (Remi Collet) Date: Sat, 06 Sep 2008 18:17:36 +0200 Subject: Fedora 8 and 9 updates status In-Reply-To: References: <1220630950.4273.14.camel@luminos.localdomain> Message-ID: <48C2AD20.2030002@FamilleCollet.com> sean darcy a ?crit : > In any event, is the new key for updates 9 available someplace. I > realize it'll be part of fedora release eventually. But the public key > itself, is it out there someplace now? It will in the next "fedora-released" RPM update It's also available on keys server : http://pgp.mit.edu:11371/pks/lookup?search=0x6DF2196F&op=index ++ From pbrobinson at gmail.com Sat Sep 6 16:18:24 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Sat, 6 Sep 2008 17:18:24 +0100 Subject: Fedora 8 and 9 updates status In-Reply-To: References: <1220630950.4273.14.camel@luminos.localdomain> Message-ID: <5256d0b0809060918o72ce0cbdrc4c4000fedcb245d@mail.gmail.com> >> As you well know, we have been working hard to get updates for 8 and 9 >> flowing again, complete with new package signing keys. Discussion has >> been somewhat quiet on this front as we've all had our heads down and >> have been working hard toward a solution, one that involves little to no >> manual effort on behalf of our users. >> >> Today we've reached a major milestone in this progress. We have done a >> successful compose of all the existing and as of yesterday pending >> updates for Fedora 8 and Fedora 9, all signed with our new keys. These >> updates will soon hit mirrors in a new set of directory locations. What >> we don't have quite yet is the updated fedora-release package in the old >> updates location that will get you the new keys and the new repo >> locations. The last mile testing of this update requires that new >> updates be live on the mirrors. >> >> Due to the size of the resigned updates, it may take a good while for >> our sync process. This may delay getting the new fedora-release out >> until tomorrow, but we'll be working hard on it. >> >> While we're working on this update, we'll also be drafting a FAQ page to >> explain to users what it is that we're doing, and hopefully answer some >> of the questions that will come up. This document will be living >> though, and as you encounter questions yourself, or questions via one of >> our many avenues of support (email, IRC, forums, LUGS, etc..) please >> help us in growing that document. Announcements regarding the location >> of said document and how to help with content will be coming shortly. >> >> We deeply appreciate the enormous magnitude of patience you the greater >> community has shown us the Fedora project as we work though these >> serious issues. It is a great testament to how wonderful it is to work >> in and with the Fedora community. >> >> > > First, thanks for all the work to get this back on track. > > I went and got the new spins of qt-4.4. Now I can't install the because I > don't have the new key. I realize I could turn off the key, but after last > month, that seems dicier than it used to be. > > In any event, is the new key for updates 9 available someplace. I realize > it'll be part of fedora release eventually. But the public key itself, is it > out there someplace now? I think its part of the new fedora-release package and is available on the fedora project site here http://fedoraproject.org/keys.html Peter From tmz at pobox.com Sat Sep 6 16:23:55 2008 From: tmz at pobox.com (Todd Zullinger) Date: Sat, 6 Sep 2008 12:23:55 -0400 Subject: Fedora 8 and 9 updates status In-Reply-To: References: <1220630950.4273.14.camel@luminos.localdomain> Message-ID: <20080906162354.GQ25264@inocybe.teonanacatl.org> sean darcy wrote: > In any event, is the new key for updates 9 available someplace. I > realize it'll be part of fedora release eventually. But the public > key itself, is it out there someplace now? The keys are in CVS for fedora-release: http://cvs.fedoraproject.org/viewvc/fedora-release/?root=fedora The fingerprints can be verified at: https://fedoraproject.org/keys -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In some cultures what I do would be considered normal. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From benny+usenet at amorsen.dk Sat Sep 6 16:54:25 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Sat, 06 Sep 2008 18:54:25 +0200 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: (Jason L. Tibbitts, III's message of "06 Sep 2008 09\:20\:50 -0500") References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <200809061443.52683.alain.portal@free.fr> Message-ID: Jason L Tibbitts III writes: >>>>>> "AP" == Alain PORTAL writes: > Perhaps needs #include ? Debian or Ubuntu has a patch for this: http://patches.ubuntu.com/by-release/extracted/ubuntu/g/gpsim/0.22.0-5/10-gcc-4.3.dpatch gpsim is building on my laptop right now; so far it looks good. /Benny From vgaburici at gmail.com Sat Sep 6 17:02:47 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Sat, 6 Sep 2008 20:02:47 +0300 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <200809061443.52683.alain.portal@free.fr> Message-ID: I've uploaded a patch for this on the bug page. On Sat, Sep 6, 2008 at 7:54 PM, Benny Amorsen wrote: > Jason L Tibbitts III writes: > >>>>>>> "AP" == Alain PORTAL writes: > >> Perhaps needs #include ? > > Debian or Ubuntu has a patch for this: > > http://patches.ubuntu.com/by-release/extracted/ubuntu/g/gpsim/0.22.0-5/10-gcc-4.3.dpatch > > gpsim is building on my laptop right now; so far it looks good. > > > /Benny > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From michel.sylvan at gmail.com Sat Sep 6 17:15:07 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sat, 6 Sep 2008 13:15:07 -0400 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <1dedbbfc0809060707vaf23029w2aba4a6ca34d1a1@mail.gmail.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <1220646108.4331.2.camel@PB3.Linux> <1dedbbfc0809051347g383ccf70o1686a982388b685@mail.gmail.com> <1dedbbfc0809060707vaf23029w2aba4a6ca34d1a1@mail.gmail.com> Message-ID: 2008/9/6 David Nielsen : > > > 2008/9/6 Michel Salim >> >> 2008/9/5 David Nielsen : >> > >> > >> > Den 5. sep. 2008 22.21 skrev Paul : >> >> >> >> Hi, >> >> >> >> > monodevelop-0.19-6.fc9 [u'449441 ASSIGNED'] (build/make) pfj >> >> >> >> This is a pain. Every time I've tried to build MD 1.0, koji has thrown >> >> a >> >> wobbler complaining that %{_libdir}/mono/gac can't be found! I will >> >> look >> >> at it again over this next week though. >> > >> > Didn't the wonderful Michel fix this recently, he cleaned up the spec >> > and >> > bumped us succesfully to 2.0 beta. >> > >> I haven't touched the F-9 branch; as I'm not running F-9 anymore, and >> with the changes in the Mono stack, I didn't want to risk any >> breakage. Paul likely knows more about the difference between F-9's >> mono and Rawhide's -- Paul, you could perhaps backport the Rawhide >> monodevelop to F-9? Some of the BRs might need to be changed. > > I believe the new monodevelop requires gtk-sharp-2.12 which in return will > require us to push everything that depends on gtk-sharp2 (with patches or > updated versions from rawhide). I would be in favor of this as it would make > our Mono stack a bit more consistent across the supported platforms and it > would allow us to have the same supported versions of many programs on every > platform. Something like gnome-do e.g. is generally only supported in the > latest release by upstream and we cannot put that in F9 because our stack > cannot support it currently. > > Maybe once Mono 2.0 Final hits we can decide if a coordinated push to F9 > (and F8 if it is still supported at such a time) is desirable, that would > give us time to clean everything up and maybe the friendly ppc arch team can > help us fix nant as well so ppc users can get a complete mono stack. > In the meantime, if MonoDevelop 1.0 is not buildable, perhaps we should revert to 0.19 (IIRC that's the last buildable version). Paul, thougts? -- Michel Salim http://hircus.jaiku.com/ From a.badger at gmail.com Sat Sep 6 17:39:07 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 06 Sep 2008 10:39:07 -0700 Subject: Unable to access cvs In-Reply-To: <200809061528.35585.alain.portal@free.fr> References: <200809061528.35585.alain.portal@free.fr> Message-ID: <48C2C03B.9000807@gmail.com> Alain PORTAL wrote: > Hi, > > I don't know why, but I'm unable to access cvs: > > Permission denied (publickey). > cvs [checkout aborted]: end of file from server (consult above messages if > any) > > I updated certificate as said here: > https://www.redhat.com/archives/fedora-devel-announce/2008-August/msg00008.html > > Is there something I missed? > You need to either upload a new ssh key or reupload your old one. If your old key was DSA you'll need a new one. If you stored your private key on a Fedora Infrastructure server you should create a new one for safety. If you had an RSA key and only used it for cvs checkin, then reuploading the old key should be okay. Reupload in FAS:: https://admin.fedoraproject.org/accounts/ -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From a.badger at gmail.com Sat Sep 6 18:17:15 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 06 Sep 2008 11:17:15 -0700 Subject: Unable to access cvs In-Reply-To: <1dedbbfc0809060752q671fd587kfe305bafbb96c661@mail.gmail.com> References: <200809061528.35585.alain.portal@free.fr> <1dedbbfc0809060752q671fd587kfe305bafbb96c661@mail.gmail.com> Message-ID: <48C2C92B.8020402@gmail.com> David Nielsen wrote: > > In the same vein, click any package in koji gives a 403 message. > That seems to work for me. For instance, from this page: https://koji.fedoraproject.org/koji/buildinfo?buildID=61736 I click on the link to: http://koji.fedoraproject.org/packages/python-bugzilla/0.4/0.rc1.fc10/noarch/python-bugzilla-0.4-0.rc1.fc10.noarch.rpm and get a package fine. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From paul at all-the-johnsons.co.uk Sat Sep 6 18:35:22 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 06 Sep 2008 19:35:22 +0100 Subject: Commands for koji - targetting distros Message-ID: <1220726122.21309.1.camel@PB3.Linux> Hi, Is there a list on the wiki which gives the details of what I need to use to target f8-updates, f8-updates-testing, f9-updates and f9-updates-testing? I can't spot anything. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From tcallawa at redhat.com Sat Sep 6 18:34:59 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sat, 06 Sep 2008 14:34:59 -0400 Subject: A couple of license-relate questions In-Reply-To: References: Message-ID: <1220726099.16460.3.camel@localhost.localdomain> On Thu, 2008-09-04 at 22:11 +0300, Vasile Gaburici wrote: > 2) Can someone take a look at the Adobe Glyph List license > [http://www.adobe.com/devnet/opentype/archives/glyphlist.txt] and > determine what is the appropriate rpm license field for it? License: MIT Its a screwed up variant, but the end result is the same. ~spot From mcepl at redhat.com Sat Sep 6 18:59:57 2008 From: mcepl at redhat.com (Matej Cepl) Date: Sat, 06 Sep 2008 20:59:57 +0200 Subject: Fedora 8 and 9 updates status References: <1220630950.4273.14.camel@luminos.localdomain> <20080906162354.GQ25264@inocybe.teonanacatl.org> Message-ID: On 2008-09-06, 16:23 GMT, Todd Zullinger wrote: > The fingerprints can be verified at: > > https://fedoraproject.org/keys Except that the webpage mentions email fedora at redhat.com whereas the real key is signed for fedora at fedoraproject.org Mat?j From selinux at gmail.com Sat Sep 6 19:03:36 2008 From: selinux at gmail.com (Tom London) Date: Sat, 6 Sep 2008 12:03:36 -0700 Subject: Boot speedup with readahead In-Reply-To: References: Message-ID: <4c4ba1530809061203t2ca06046k6e847659258174ee@mail.gmail.com> On Sat, Sep 6, 2008 at 3:52 AM, Harald Hoyer wrote: > Hello fellow Fedora developers, > > recently readahead was modified to adapt to system file changes and to start > very early in the boot process via upstart. > > I would like to encourage you to test readahead-1.4.5-3.fc10 from rawhide > (even possible on F9), which I built some minutes ago. It may take a day to > reach your local mirror. > > # yum --enablerepo=rawhide install readahead > or > # yum --enablerepo=rawhide update readahead > > With the next reboot readahead-collector runs and collects the information > which files are used during the boot process. The next reboot then, > readahead read ahead those files and the boot process (from init start to > gdm login screen) should be approx. 10% faster. > > Hope it speeds up your boot process a little bit. Please report any changes > in your boot time (can be measured with a stop clock or bootchart). > > You can modify /etc/sysconfig/readahead to turn readahead on/off. Running latest rawhide on Thinkpad X60, measured with stopwatch: Prior to installing readahead: time from start of boot to gdm login: 56 seconds time from entering password to gnome applets appearing in upper right panel: 23 seconds First boot after installing readahead: time from start of boot to gdm login: 61 seconds time from password to gnome: 22 seconds Second boot after installing readahead time from start of boot to gdm login: 50 seconds time from password to gnome: 23 seconds Appears 10% faster, as promised.... :-D tom -- Tom London From tmz at pobox.com Sat Sep 6 19:13:06 2008 From: tmz at pobox.com (Todd Zullinger) Date: Sat, 6 Sep 2008 15:13:06 -0400 Subject: Fedora 8 and 9 updates status In-Reply-To: References: <1220630950.4273.14.camel@luminos.localdomain> <20080906162354.GQ25264@inocybe.teonanacatl.org> Message-ID: <20080906191306.GR25264@inocybe.teonanacatl.org> Matej Cepl wrote: > On 2008-09-06, 16:23 GMT, Todd Zullinger wrote: >> The fingerprints can be verified at: >> >> https://fedoraproject.org/keys > > Except that the webpage mentions email fedora at redhat.com whereas > the real key is signed for fedora at fedoraproject.org It only uses that address in the example, which uses the old key in /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora and in the "Obsolete Keys" section when giving details for the old key. And that address is correct for the old key. The information there for RPM-GPG-KEY-fedora-8-and-9-primary and RPM-GPG-KEY-fedora-test-8-and-9-primary should be correct. If it does not match what is in the updated files in fedora-release, please yell loudly. :) -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Now I'm finding truth is a ruin Nauseous end that nobody is pursuing -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From pbrobinson at gmail.com Sat Sep 6 19:33:16 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Sat, 6 Sep 2008 20:33:16 +0100 Subject: Commands for koji - targetting distros In-Reply-To: <1220726122.21309.1.camel@PB3.Linux> References: <1220726122.21309.1.camel@PB3.Linux> Message-ID: <5256d0b0809061233t1109c692kd9e6ca1066bac3bb@mail.gmail.com> 2008/9/6 Paul : > Hi, > > Is there a list on the wiki which gives the details of what I need to > use to target f8-updates, f8-updates-testing, f9-updates and > f9-updates-testing? I can't spot anything. The following command will build a package for fedora-9. You then need to push it to testing. koji build dist-f9-updates-candidate 'cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/package-name/F-9#HEAD' most of the details that you need can be found here https://fedoraproject.org/wiki/PackageMaintainers/UsingKoji Peter From gnomeuser at gmail.com Sat Sep 6 19:34:51 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Sat, 6 Sep 2008 21:34:51 +0200 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <1220716852.20819.5.camel@PB3.Linux> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <1220646108.4331.2.camel@PB3.Linux> <1dedbbfc0809051347g383ccf70o1686a982388b685@mail.gmail.com> <1dedbbfc0809060707vaf23029w2aba4a6ca34d1a1@mail.gmail.com> <1220716852.20819.5.camel@PB3.Linux> Message-ID: <1dedbbfc0809061234qcfaec3au3777fc7fe0eb9ad5@mail.gmail.com> > > Anyone interested in a mono-SIG? It could be useful! > > Absolutely, I don't currently own any Mono packages but I do reviews, patches and testing. Let's do this thing > -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.badger at gmail.com Sat Sep 6 19:41:52 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 06 Sep 2008 12:41:52 -0700 Subject: Note to package maintainers: unowned directories In-Reply-To: <20080906133024.e7c0852d.mschwendt@gmail.com> References: <20080906133024.e7c0852d.mschwendt@gmail.com> Message-ID: <48C2DD00.9080001@gmail.com> Michael Schwendt wrote: > Some package maintainers have asked in private about "unowned directories", > so here is a revised cut'n'paste job of the various replies. Thanks Michael! I've tried to modify this to be a good set of examples to supplement the existing Guidelines: https://fedoraproject.org/wiki/PackagingDrafts/UnownedDirectories Please modify that document and I'll get it integrated into the Packaging Guidelines as soon as possible. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From vgaburici at gmail.com Sat Sep 6 19:59:26 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Sat, 6 Sep 2008 22:59:26 +0300 Subject: [Fedora-legal-list] Re: A couple of license-relate questions In-Reply-To: <1220726099.16460.3.camel@localhost.localdomain> References: <1220726099.16460.3.camel@localhost.localdomain> Message-ID: Interesting outcome. Does that mean I don't have to mention it at if it's included in a GPLv2 package? As a footnote, Werner Lemberg asked Eddie Kohler a while back to remove his (that is Eddie's) changes from the file because of the "No modification, editing or other alteration of this document is allowed" clause in the license. They, meaning Adobe, seem to contradict themselves later on with: # Permission is hereby granted, free of charge, to any person obtaining a # copy of this documentation file, to create their own derivative works # from the content of this document to use, copy, publish, distribute, # sublicense, and/or sell the derivative works, and to permit others to do # the same, provided that the derived work is not represented as being a # copy or version of this document. which allows modifications as long as you don't attribute them to Adobe. So Eddie can change it, but has to call it "Eddie's glyph list". LOL. On Sat, Sep 6, 2008 at 9:34 PM, Tom spot Callaway wrote: > On Thu, 2008-09-04 at 22:11 +0300, Vasile Gaburici wrote: >> 2) Can someone take a look at the Adobe Glyph List license >> [http://www.adobe.com/devnet/opentype/archives/glyphlist.txt] and >> determine what is the appropriate rpm license field for it? > > License: MIT > > Its a screwed up variant, but the end result is the same. > > ~spot > > _______________________________________________ > Fedora-legal-list mailing list > Fedora-legal-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-legal-list > From jeff at ocjtech.us Sat Sep 6 19:37:16 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Sat, 6 Sep 2008 14:37:16 -0500 Subject: Fedora 8 and 9 updates status In-Reply-To: <20080906191306.GR25264@inocybe.teonanacatl.org> References: <1220630950.4273.14.camel@luminos.localdomain> <20080906162354.GQ25264@inocybe.teonanacatl.org> <20080906191306.GR25264@inocybe.teonanacatl.org> Message-ID: <935ead450809061237q5b134e12n83cbc67fd5de8ce5@mail.gmail.com> 2008/9/6 Todd Zullinger : > Matej Cepl wrote: >> On 2008-09-06, 16:23 GMT, Todd Zullinger wrote: >>> The fingerprints can be verified at: >>> >>> https://fedoraproject.org/keys >> >> Except that the webpage mentions email fedora at redhat.com whereas >> the real key is signed for fedora at fedoraproject.org > > It only uses that address in the example, which uses the old key in > /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora and in the "Obsolete Keys" > section when giving details for the old key. And that address is > correct for the old key. > > The information there for RPM-GPG-KEY-fedora-8-and-9-primary and > RPM-GPG-KEY-fedora-test-8-and-9-primary should be correct. If it does > not match what is in the updated files in fedora-release, please yell > loudly. :) What would be even better is if the new GPG keys would be able to be verified through the GPG web of trust. I'm not sure how much time is left in Fudcon Brno, but maybe the folks over there could arrange an impromptu keysigning to expand the GPG web of trust among Fedorans. -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" From paul at all-the-johnsons.co.uk Sat Sep 6 20:33:45 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 06 Sep 2008 21:33:45 +0100 Subject: Setting up a SIG Message-ID: <1220733225.21560.0.camel@PB3.Linux> Hi, Do I need to talk to anyone in particular to get a Mono SIG set up or is it just something I can do? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From markg85 at gmail.com Sat Sep 6 20:40:03 2008 From: markg85 at gmail.com (Mark) Date: Sat, 6 Sep 2008 22:40:03 +0200 Subject: Boot speedup with readahead In-Reply-To: <4c4ba1530809061203t2ca06046k6e847659258174ee@mail.gmail.com> References: <4c4ba1530809061203t2ca06046k6e847659258174ee@mail.gmail.com> Message-ID: <6e24a8e80809061340y2b4b3d9fw416445ad9a722b64@mail.gmail.com> On Sat, Sep 6, 2008 at 9:03 PM, Tom London wrote: > On Sat, Sep 6, 2008 at 3:52 AM, Harald Hoyer wrote: >> Hello fellow Fedora developers, >> >> recently readahead was modified to adapt to system file changes and to start >> very early in the boot process via upstart. >> >> I would like to encourage you to test readahead-1.4.5-3.fc10 from rawhide >> (even possible on F9), which I built some minutes ago. It may take a day to >> reach your local mirror. >> >> # yum --enablerepo=rawhide install readahead >> or >> # yum --enablerepo=rawhide update readahead >> >> With the next reboot readahead-collector runs and collects the information >> which files are used during the boot process. The next reboot then, >> readahead read ahead those files and the boot process (from init start to >> gdm login screen) should be approx. 10% faster. >> >> Hope it speeds up your boot process a little bit. Please report any changes >> in your boot time (can be measured with a stop clock or bootchart). >> >> You can modify /etc/sysconfig/readahead to turn readahead on/off. > > Running latest rawhide on Thinkpad X60, measured with stopwatch: > > Prior to installing readahead: > time from start of boot to gdm login: 56 seconds > time from entering password to gnome applets appearing in upper > right panel: 23 seconds > > First boot after installing readahead: > time from start of boot to gdm login: 61 seconds > time from password to gnome: 22 seconds > > Second boot after installing readahead > time from start of boot to gdm login: 50 seconds > time from password to gnome: 23 seconds > > Appears 10% faster, as promised.... :-D > > tom > -- > Tom London > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > O wow good to see that readahead is finally getting worth something. What i wonder is if the following are alose read ahead: - The default icon theme is also read ahead? - The GTK parts so that for example gnome-panel is open faster or any gtk using app - Are the most used user applications (Specially nautilus and firefox) fully read ahead so that they start FAST (will greatly improve user experience) I hope the performance of readahead can go up a bit more (25%?) Anyway good numbers so far! Keep up posted if you want. From casimiro.barreto at gmail.com Sat Sep 6 22:47:36 2008 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Sat, 06 Sep 2008 19:47:36 -0300 Subject: Fedora 8 and 9 updates status In-Reply-To: <935ead450809061237q5b134e12n83cbc67fd5de8ce5@mail.gmail.com> References: <1220630950.4273.14.camel@luminos.localdomain> <20080906162354.GQ25264@inocybe.teonanacatl.org> <20080906191306.GR25264@inocybe.teonanacatl.org> <935ead450809061237q5b134e12n83cbc67fd5de8ce5@mail.gmail.com> Message-ID: <48C30888.3020000@gmail.com> Jeffrey Ollie escreveu: > 2008/9/6 Todd Zullinger : > >> Matej Cepl wrote: >> >>> On 2008-09-06, 16:23 GMT, Todd Zullinger wrote: >>> >>>> The fingerprints can be verified at: >>>> >>>> https://fedoraproject.org/keys >>>> >>> Except that the webpage mentions email fedora at redhat.com whereas >>> the real key is signed for fedora at fedoraproject.org >>> >> It only uses that address in the example, which uses the old key in >> /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora and in the "Obsolete Keys" >> section when giving details for the old key. And that address is >> correct for the old key. >> >> The information there for RPM-GPG-KEY-fedora-8-and-9-primary and >> RPM-GPG-KEY-fedora-test-8-and-9-primary should be correct. If it does >> not match what is in the updated files in fedora-release, please yell >> loudly. :) >> > > What would be even better is if the new GPG keys would be able to be > verified through the GPG web of trust. I'm not sure how much time is > left in Fudcon Brno, but maybe the folks over there could arrange an > impromptu keysigning to expand the GPG web of trust among Fedorans. > > Doing as told in the page we get: [root at terra rpm-gpg]# rpm --import PUBKEY erro: PUBKEY: leitura de importa??o falhou (-1). [root at terra rpm-gpg]# error: PUBKEY: import reading failed (-1). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From ivazqueznet at gmail.com Sat Sep 6 23:06:48 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sat, 06 Sep 2008 19:06:48 -0400 Subject: Setting up a SIG In-Reply-To: <1220733225.21560.0.camel@PB3.Linux> References: <1220733225.21560.0.camel@PB3.Linux> Message-ID: <1220742408.17290.284.camel@ignacio.lan> On Sat, 2008-09-06 at 21:33 +0100, Paul wrote: > Do I need to talk to anyone in particular to get a Mono SIG set up or is > it just something I can do? You just do it. Announce that you're starting a SIG (on f-a/f-d-a is fine) and set up your SIG page in the wiki. How you proceed from there is up to you. Some have a mailing list, others go without, etc. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alain.portal at free.fr Sat Sep 6 23:35:54 2008 From: alain.portal at free.fr (Alain PORTAL) Date: Sun, 7 Sep 2008 01:35:54 +0200 Subject: Why I'll leave fedora (french speaking people only) [1] Message-ID: <200809070135.54996.alain.portal@free.fr> Pfff... https://bugzilla.redhat.com/show_bug.cgi?id=455277#c8 En fait, quand je me relis, je me rend compte que finalement je ne donne pas vraiment les raisons... Sans doute ai-je trop donn? d'explications ailleurs. Eh Trashy, Zig Heil ! No regards for ass holes Alain [1] You can read french? I'm sorry, but don't forget french is the diplomacy language. -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From tmz at pobox.com Sat Sep 6 23:57:33 2008 From: tmz at pobox.com (Todd Zullinger) Date: Sat, 6 Sep 2008 19:57:33 -0400 Subject: Fedora 8 and 9 updates status In-Reply-To: <48C30888.3020000@gmail.com> References: <1220630950.4273.14.camel@luminos.localdomain> <20080906162354.GQ25264@inocybe.teonanacatl.org> <20080906191306.GR25264@inocybe.teonanacatl.org> <935ead450809061237q5b134e12n83cbc67fd5de8ce5@mail.gmail.com> <48C30888.3020000@gmail.com> Message-ID: <20080906235732.GS25264@inocybe.teonanacatl.org> Casimiro de Almeida Barreto wrote: > Doing as told in the page we get: > > [root at terra rpm-gpg]# rpm --import PUBKEY > erro: PUBKEY: leitura de importa??o falhou (-1). > [root at terra rpm-gpg]# > > error: PUBKEY: import reading failed (-1). That is just a usage example, you need to replace PUBKEY with the path to a key, like /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-8-and-9-primary. Note that yum will do this for you automatically in most cases, so it is not necessary. (As the page says just above that example: "The keys used by Fedora are enabled in the yum repository configuration, so you generally don't need to manually import them into the rpm database.") More likely, you'd want to use gpg to import the key and then verify the fingerprint, as the later examples show. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It is impossible to enjoy idling thoroughly unless one has plenty of work to do. -- Jerome K. Jerome -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From lyos.gemininorezel at gmail.com Sun Sep 7 02:09:30 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Sat, 06 Sep 2008 22:09:30 -0400 Subject: Why I'll leave fedora (french speaking people only) [1] In-Reply-To: <200809070135.54996.alain.portal@free.fr> References: <200809070135.54996.alain.portal@free.fr> Message-ID: <48C337DA.2050009@gmail.com> Alain PORTAL wrote: > Pfff... > > https://bugzilla.redhat.com/show_bug.cgi?id=455277#c8 > > En fait, quand je me relis, je me rend compte que finalement je ne donne pas > vraiment les raisons... Sans doute ai-je trop donn? d'explications ailleurs. > > Eh Trashy, Zig Heil ! > > No regards for ass holes > Alain > > [1] You can read french? > I'm sorry, but don't forget french is the diplomacy language. > Ok... I cannot read French... but from what google's translator is able to decipher... it looks to me like you are the one being unreasonable. You say here: "Je te trouve particuli?rement glonfl? de venir oser me proposer ton aide alors que tu m'as banni ? la fois d'IRC [1] et des forums fedora-fr..." that you were banned from IRC and fedora-fr... well, if you were indeed banned, there must have been some reason for it. I won't delve into that here... though I'm sure someone will enlighten us. The point is... things take time... and with everything going on with Fedora Infrastructure in the last month... you should expect it to take longer. Chill out... remember, it's only code. Lyos Gemini Norezel From skvidal at fedoraproject.org Sun Sep 7 02:35:13 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Sat, 06 Sep 2008 22:35:13 -0400 Subject: Why I'll leave fedora (french speaking people only) [1] In-Reply-To: <48C337DA.2050009@gmail.com> References: <200809070135.54996.alain.portal@free.fr> <48C337DA.2050009@gmail.com> Message-ID: <1220754913.17785.105.camel@rosebud> On Sat, 2008-09-06 at 22:09 -0400, Lyos Gemini Norezel wrote: > Alain PORTAL wrote: > > Pfff... > > > > https://bugzilla.redhat.com/show_bug.cgi?id=455277#c8 > > > > En fait, quand je me relis, je me rend compte que finalement je ne donne pas > > vraiment les raisons... Sans doute ai-je trop donn? d'explications ailleurs. > > > > Eh Trashy, Zig Heil ! > > > > No regards for ass holes > > Alain > > > > [1] You can read french? > > I'm sorry, but don't forget french is the diplomacy language. > > > Ok... I cannot read French... but from what google's translator is able > to decipher... it looks to me like you are the one being unreasonable. > You say here: "Je te trouve particuli?rement glonfl? de venir oser me > proposer ton aide alors que tu m'as banni ? la fois d'IRC [1] et des > forums fedora-fr..." > that you were banned from IRC and fedora-fr... well, if you were indeed > banned, there must have been some reason for it. Let's be fair here. Just b/c someone was punished for something does not mean that they did anything wrong. unjust punishments happen all the time. -sv From alain.portal at free.fr Sun Sep 7 02:35:57 2008 From: alain.portal at free.fr (Alain PORTAL) Date: Sun, 7 Sep 2008 04:35:57 +0200 Subject: Why I'll leave fedora (french speaking people only) [1] In-Reply-To: <200809070135.54996.alain.portal@free.fr> References: <200809070135.54996.alain.portal@free.fr> Message-ID: <200809070435.58126.alain.portal@free.fr> Le dimanche 07 septembre 2008, Alain PORTAL a ?crit : > [1] You can read french? Humm... Of course, there is a typo here, I wanted to say: "You can't read french?" -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- 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 rrankin at ihug.com.au Sun Sep 7 02:47:20 2008 From: rrankin at ihug.com.au (Roy Rankin) Date: Sun, 07 Sep 2008 12:47:20 +1000 Subject: Proposed removal of packages with long-standing FTBFS failures Message-ID: <48C340B8.7050307@ihug.com.au> I sent an e-mail to Alain yesterday indicating that I have a patch for this working under F-9, but wanted to check with him before I applied it. I will do so now. Regards, Roy Rankin >Hi, > >Le vendredi 05 septembre 2008, Matt Domsch a ?crit : > >> gpsim-0.22.0-5.fc8 [u'434061 ASSIGNED'] (build/make) dionysos > >As I'm still on FC6, I'm not able to fix this bug. >Any help will be appreciated. > >Regards, >Alain From lyos.gemininorezel at gmail.com Sun Sep 7 02:53:54 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Sat, 06 Sep 2008 22:53:54 -0400 Subject: Why I'll leave fedora (french speaking people only) [1] In-Reply-To: <1220754913.17785.105.camel@rosebud> References: <200809070135.54996.alain.portal@free.fr> <48C337DA.2050009@gmail.com> <1220754913.17785.105.camel@rosebud> Message-ID: <48C34242.9090103@gmail.com> Seth Vidal wrote: > On Sat, 2008-09-06 at 22:09 -0400, Lyos Gemini Norezel wrote: > > Let's be fair here. Just b/c someone was punished for something does not > mean that they did anything wrong. > > unjust punishments happen all the time. > > -sv Seth... You are, of course, correct... I guess I was just hoping this wouldn't be another case of an asshole mod abusing his powers. If it is indeed, such an asshole mod... then that mod should be permanently removed from his/her position of power... and suspended until a review board of his/her peers reviews all the particulars of the case. If you can't tell already... I hate assholes who abuse their power. At any rate... if I'm right to hold out hope... then my advice was right on. Lyos Gemini Norezel From lyos.gemininorezel at gmail.com Sun Sep 7 03:05:22 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Sat, 06 Sep 2008 23:05:22 -0400 Subject: Why I'll leave fedora (french speaking people only) [1] In-Reply-To: <48C337DA.2050009@gmail.com> References: <200809070135.54996.alain.portal@free.fr> <48C337DA.2050009@gmail.com> Message-ID: <48C344F2.4090705@gmail.com> Lyos Gemini Norezel wrote: > Alain PORTAL wrote: >> Pfff... >> >> https://bugzilla.redhat.com/show_bug.cgi?id=455277#c8 >> >> En fait, quand je me relis, je me rend compte que finalement je ne >> donne pas vraiment les raisons... Sans doute ai-je trop donn? >> d'explications ailleurs. >> >> Eh Trashy, Zig Heil ! >> >> No regards for ass holes >> Alain >> >> [1] You can read french? >> I'm sorry, but don't forget french is the diplomacy language. >> > Ok... I cannot read French... but from what google's translator is > able to decipher... it looks to me like you are the one being > unreasonable. > You say here: "Je te trouve particuli?rement glonfl? de venir oser me > proposer ton aide alors que tu m'as banni ? la fois d'IRC [1] et des > forums fedora-fr..." > that you were banned from IRC and fedora-fr... well, if you were > indeed banned, there must have been some reason for it. > > I won't delve into that here... though I'm sure someone will enlighten > us. > > The point is... things take time... and with everything going on with > Fedora Infrastructure in the last month... you should expect it to > take longer. > > Chill out... > remember, it's only code. > > Lyos Gemini Norezel > Alain... As a followup to my above post... regardless of how you feel about Johan Cwiklinski... you should not ignore his advice. If you'd been watching the mailing list... you'd know that Fedora Infrastructure was compromised last month... because of that... package keys were changed... and ssh keys were reset. You must re-add your ssh key... though you should note that DSA keys are no longer allowed... you must use an RSA key. Just thought you should know. Lyos Gemini Norezel From rrankin at ihug.com.au Sun Sep 7 03:56:21 2008 From: rrankin at ihug.com.au (Roy Rankin) Date: Sun, 07 Sep 2008 13:56:21 +1000 Subject: Help gpsim F-9 builds on x86_64 and i386 but fails on ppc Message-ID: <48C350E5.8020105@ihug.com.au> Below is what looks like the relevant part of the build log. Any suggestions on why this is failing on the ppc but not on x86_64 and i386? Regards, Roy Rankin make[2]: execvp: gtk-config: Permission denied /bin/sh ../libtool --tag=CXX --mode=link g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -o gpsim main.o ../src/libgpsim.la ../cli/libgpsimcli.la ../gui/libgpsimgui.la ../eXdbm/libgpsim_eXdbm.la -lstdc++ -lpopt -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lglib-2.0 -lgtkextra-x11-2.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lpopt mkdir .libs g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -o .libs/gpsim main.o -pthread ../src/.libs/libgpsim.so ../cli/.libs/libgpsimcli.so ../gui/.libs/libgpsimgui.so ../eXdbm/.libs/libgpsim_eXdbm.so -lstdc++ -lgthread-2.0 -lrt -lgtkextra-x11-2.0 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lpopt ../cli/.libs/libgpsimcli.so: undefined reference to `rl_getc_function' ../cli/.libs/libgpsimcli.so: undefined reference to `rl_attempted_completion_function' ../cli/.libs/libgpsimcli.so: undefined reference to `rl_forced_update_display' ../cli/.libs/libgpsimcli.so: undefined reference to `rl_completion_matches' ../cli/.libs/libgpsimcli.so: undefined reference to `rl_callback_handler_remove' ../cli/.libs/libgpsimcli.so: undefined reference to `rl_callback_read_char' ../cli/.libs/libgpsimcli.so: undefined reference to `rl_callback_handler_install' ../cli/.libs/libgpsimcli.so: undefined reference to `add_history' collect2: ld returned 1 exit status make[2]: Leaving directory `/builddir/build/BUILD/gpsim-0.22.0/gpsim' make[1]: Leaving directory `/builddir/build/BUILD/gpsim-0.22.0' RPM build errors: From arjan at infradead.org Sun Sep 7 04:21:25 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Sat, 6 Sep 2008 21:21:25 -0700 Subject: Boot speedup with readahead In-Reply-To: References: Message-ID: <20080906212125.27b9b3bb@infradead.org> On Sat, 06 Sep 2008 12:52:56 +0200 Harald Hoyer wrote: > Hello fellow Fedora developers, > > recently readahead was modified to adapt to system file changes and > to start very early in the boot process via upstart. > > I would like to encourage you to test readahead-1.4.5-3.fc10 from > rawhide (even possible on F9), which I built some minutes ago. It may > take a day to reach your local mirror. > > # yum --enablerepo=rawhide install readahead > or > # yum --enablerepo=rawhide update readahead > > With the next reboot readahead-collector runs and collects the > information which files are used during the boot process. The next > reboot then, readahead read ahead those files and the boot process > (from init start to gdm login screen) should be approx. 10% faster. > for those who are going to the plumbers conference... Auke Kok and I will present there on how to make a Fedora based system boot in 5 seconds... and yes a form of readahead was needed to achieve that ;-) -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From pemboa at gmail.com Sun Sep 7 04:36:48 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 6 Sep 2008 23:36:48 -0500 Subject: NetworkManager-pptp In-Reply-To: <48BF01EC.5000107@hi.is> References: <9497e9990808300831t150c6036ydf4c453f3c822d48@mail.gmail.com> <1220364295.3176.19.camel@borkbork.foobar.com> <9497e9990809020820m67361762n7ed5db1bf7ad7946@mail.gmail.com> <1220369215.8041.15.camel@borkbork.foobar.com> <9497e9990809021520q6458cd39u3ff17f0144c8c5b6@mail.gmail.com> <1220473096.28633.5.camel@borkbork.foobar.com> <48BF01EC.5000107@hi.is> Message-ID: <16de708d0809062136x70e63749r12390c2c62aea82d@mail.gmail.com> I updated my test machine to rawhide. Using the following pptp related packages. NetworkManager-pptp-0.7.0-0.10.svn4027.fc10.i386 pptp-1.7.2-3.fc10.i386 pptp-release-4-2.fc9.noarch pptpconfig-20060821-1.fc9.noarch I tried to connect using NetworkManager and failed at about 18:13. At 18:18 I tried pptp-client and succeeded. At 18:29 I tried NetworkManager again, this time with MPPE on (which I had forgotten the first time) and failed I have attached the relevant portions of /var/log/messages -------------- next part -------------- A non-text attachment was scrubbed... Name: messages-2008092318.log Type: application/octet-stream Size: 11855 bytes Desc: not available URL: From mtasaka at ioa.s.u-tokyo.ac.jp Sun Sep 7 06:16:51 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 07 Sep 2008 15:16:51 +0900 Subject: Help gpsim F-9 builds on x86_64 and i386 but fails on ppc In-Reply-To: <48C350E5.8020105@ihug.com.au> References: <48C350E5.8020105@ihug.com.au> Message-ID: <48C371D3.8070809@ioa.s.u-tokyo.ac.jp> Roy Rankin wrote, at 09/07/2008 12:56 PM +9:00: > Below is what looks like the relevant part of the build log. > Any suggestions on why this is failing on the ppc but not on x86_64 and > i386? > > Regards, > Roy Rankin > > g++ -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector --param=ssp-buffer-size=4 -m32 -o .libs/gpsim main.o > -pthread ../src/.libs/libgpsim.so ../cli/.libs/libgpsimcli.so > ../gui/.libs/libgpsimgui.so ../eXdbm/.libs/libgpsim_eXdbm.so -lstdc++ > -lgthread-2.0 -lrt -lgtkextra-x11-2.0 -lgtk-x11-2.0 -lgdk-x11-2.0 > -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo > -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lpopt > ../cli/.libs/libgpsimcli.so: undefined > reference to `rl_getc_function' > ../cli/.libs/libgpsimcli.so: undefined reference to > `rl_attempted_completion_function' > ../cli/.libs/libgpsimcli.so: undefined reference to > `rl_forced_update_display' > ../cli/.libs/libgpsimcli.so: undefined reference to `rl_completion_matches' > ../cli/.libs/libgpsimcli.so: undefined reference to > `rl_callback_handler_remove' > ../cli/.libs/libgpsimcli.so: undefined reference to `rl_callback_read_char' > ../cli/.libs/libgpsimcli.so: undefined reference to > `rl_callback_handler_install' > ../cli/.libs/libgpsimcli.so: undefined reference to `add_history' > collect2: ld returned 1 exit status Well, with a patch the build succeeds: http://koji.fedoraproject.org/koji/taskinfo?taskID=811499 srpm is available from: http://koji.fedoraproject.org/scratch/mtasaka/task_811499/ Without the patch, build.logs show the difference between x86_64 and ppc like: ---------------------------------------------------------- -checking for ppc-redhat-linux-gnu-gcc... +checking for x86_64-redhat-linux-gnu-gcc... no checking for gcc... gcc @@ -130,34 +130,68 @@ checking for unistd.h... yes checking for GNU Readline library, version 2.0 or newer... -no (it is present but too old to use) +yes, installed version is 5.2 So by some reason libreadline.so is not found or so. ---------------------------------------------------------- I tried to print out what config.log says and it is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=811491 build.log shows: ---------------------------------------------------------- configure:3864: gcc -o conftest -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 conftest.c -lreadline >&5 conftest.c: In function 'main': conftest.c:31: warning: implicit declaration of function 'readline' conftest.c:32: warning: implicit declaration of function 'rl_completion_append_character' /usr/bin/ld: /tmp/ccBR9DBS.o(.text+0x20): unresolvable R_PPC_REL24 relocation against symbol `rl_completion_append_character' /tmp/ccBR9DBS.o: In function `main': /builddir/build/BUILD/gpsim-0.22.0/conftest.c:32: relocation truncated to fit: R_PPC_REL24 against symbol `rl_completion_append_character' defined in .sdata section in /usr/lib/gcc/ppc64-redhat-linux/4.3.2/../../../../lib/libreadline.so /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status configure:3870: $? = 1 configure: failed program was: | /* confdefs.h. */ | int | main () | { | | /* function-body */ | readline(0); | rl_completion_append_character(0); | | ; | return 0; | } However, in readline.h rl_completion_append_character is just "extern int" and this is actually wrong. Applying a patch against acinclude.m4 is needed. If you don't want to call autoconf, modify configure directly. Regards, Mamoru From michel.sylvan at gmail.com Sun Sep 7 06:57:07 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 7 Sep 2008 02:57:07 -0400 Subject: Fedora not "free" enough for GNU? Message-ID: I was just over at gnu.org to download the anniversary video recorded by Stephen Fry, and while I was there decided to take a look at what systems they recommend as being free. They list BLAG, which is based on Fedora. But Fedora itself (and Debian) is not there! http://www.gnu.org/links/links.html#FreeGNULinuxDistributions This struck me as rather strange, especially considering their guidelines are actually based on Fedora's (and we are thanked for it): http://www.gnu.org/philosophy/free-system-distribution-guidelines.html As far as I remember, Rahul Sundaram was talking to the GNU / FSF people about this quite a while back. Is it just the difference over binary-only firmware that's consigning us to the "non-free" heap? Regards, -- Michel Salim http://hircus.jaiku.com/ From pemboa at gmail.com Sun Sep 7 07:17:12 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 7 Sep 2008 02:17:12 -0500 Subject: Fedora not "free" enough for GNU? In-Reply-To: References: Message-ID: <16de708d0809070017i6ac414b2gea81ef8380a65627@mail.gmail.com> On Sun, Sep 7, 2008 at 1:57 AM, Michel Salim wrote: > I was just over at gnu.org to download the anniversary video recorded > by Stephen Fry, and while I was there decided to take a look at what > systems they recommend as being free. > > They list BLAG, which is based on Fedora. But Fedora itself (and > Debian) is not there! > > http://www.gnu.org/links/links.html#FreeGNULinuxDistributions > > This struck me as rather strange, especially considering their > guidelines are actually based on Fedora's (and we are thanked for it): > http://www.gnu.org/philosophy/free-system-distribution-guidelines.html > > As far as I remember, Rahul Sundaram was talking to the GNU / FSF > people about this quite a while back. Is it just the difference over > binary-only firmware that's consigning us to the "non-free" heap? > > Regards, > > -- > Michel Salim > http://hircus.jaiku.com/ I asked a similar question[1] in July, the basic idea I got from it was that binary firmware is unGNU. [1] http://www.redhat.com/archives/rhl-list/2008-July/msg01481.html From tgl at redhat.com Sun Sep 7 07:31:39 2008 From: tgl at redhat.com (Tom Lane) Date: Sun, 07 Sep 2008 03:31:39 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: References: Message-ID: <8553.1220772699@sss.pgh.pa.us> "Michel Salim" writes: > I was just over at gnu.org to download the anniversary video recorded > by Stephen Fry, and while I was there decided to take a look at what > systems they recommend as being free. I've got all the respect in the world for the work that RMS has done over the years ... but: gnu.org does not acknowledge any license but the GPL as being "truly free", and they'll never acknowledge any system that is not 100.00% GPL code as being "truly free". Draw your own conclusions about how that stance connects to reality. regards, tom "my stuff is BSD" lane From gnomeuser at gmail.com Sun Sep 7 08:51:45 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Sun, 7 Sep 2008 10:51:45 +0200 Subject: Boot speedup with readahead In-Reply-To: <20080906212125.27b9b3bb@infradead.org> References: <20080906212125.27b9b3bb@infradead.org> Message-ID: <1dedbbfc0809070151i3192f597ya87f68edb7029516@mail.gmail.com> 2008/9/7 Arjan van de Ven > > for those who are going to the plumbers conference... Auke Kok and I > will present there on how to make a Fedora based system boot in 5 > seconds... > > and yes a form of readahead was needed to achieve that ;-) 5 SECS?? I sincerely hope they will be recording the talks either as audio or even better as video because this I have got to see. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From harald at redhat.com Sun Sep 7 09:03:55 2008 From: harald at redhat.com (Harald Hoyer) Date: Sun, 07 Sep 2008 11:03:55 +0200 Subject: Boot speedup with readahead In-Reply-To: <1dedbbfc0809070151i3192f597ya87f68edb7029516@mail.gmail.com> References: <20080906212125.27b9b3bb@infradead.org> <1dedbbfc0809070151i3192f597ya87f68edb7029516@mail.gmail.com> Message-ID: David Nielsen schrieb: > > > 2008/9/7 Arjan van de Ven > > > > for those who are going to the plumbers conference... Auke Kok and I > will present there on how to make a Fedora based system boot in 5 > seconds... > > and yes a form of readahead was needed to achieve that ;-) > > > 5 SECS?? > > I sincerely hope they will be recording the talks either as audio or > even better as video because this I have got to see. > > - David > standard kernel + initrd alone takes more time than 12s on my system, so no chance to come to 5s without building my own kernel with all modules compiled in. From snecklifter at gmail.com Sun Sep 7 09:09:25 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Sun, 7 Sep 2008 10:09:25 +0100 Subject: Boot speedup with readahead In-Reply-To: References: <20080906212125.27b9b3bb@infradead.org> <1dedbbfc0809070151i3192f597ya87f68edb7029516@mail.gmail.com> Message-ID: <364d303b0809070209k6e90ee32k5f2cc3dbc205b55e@mail.gmail.com> 2008/9/7 Harald Hoyer : > David Nielsen schrieb: >> >> >> 2008/9/7 Arjan van de Ven > > >> >> >> for those who are going to the plumbers conference... Auke Kok and I >> will present there on how to make a Fedora based system boot in 5 >> seconds... >> >> and yes a form of readahead was needed to achieve that ;-) >> >> >> 5 SECS?? >> >> I sincerely hope they will be recording the talks either as audio or even >> better as video because this I have got to see. >> >> - David >> > > standard kernel + initrd alone takes more time than 12s on my system, so no > chance to come to 5s without building my own kernel with all modules > compiled in. Is this on spinning plates or solid state? -- Christopher Brown http://www.chruz.com From aph at redhat.com Sun Sep 7 09:11:00 2008 From: aph at redhat.com (Andrew Haley) Date: Sun, 07 Sep 2008 10:11:00 +0100 Subject: Fedora not "free" enough for GNU? In-Reply-To: <8553.1220772699@sss.pgh.pa.us> References: <8553.1220772699@sss.pgh.pa.us> Message-ID: <48C39AA4.6060903@redhat.com> Tom Lane wrote: > "Michel Salim" writes: >> I was just over at gnu.org to download the anniversary video recorded >> by Stephen Fry, and while I was there decided to take a look at what >> systems they recommend as being free. > > I've got all the respect in the world for the work that RMS has done > over the years ... but: > > gnu.org does not acknowledge any license but the GPL as being "truly > free", and they'll never acknowledge any system that is not 100.00% > GPL code as being "truly free". Draw your own conclusions about how > that stance connects to reality. Rubbish. GNU has always accepted that non-GPL licences are free. http://www.gnu.org/licenses/license-list.html#SoftwareLicenses includes dozens of them. Andrew. From gmaxwell at gmail.com Sun Sep 7 09:15:27 2008 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Sun, 7 Sep 2008 05:15:27 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <8553.1220772699@sss.pgh.pa.us> References: <8553.1220772699@sss.pgh.pa.us> Message-ID: On Sun, Sep 7, 2008 at 3:31 AM, Tom Lane wrote: > "Michel Salim" writes: >> I was just over at gnu.org to download the anniversary video recorded >> by Stephen Fry, and while I was there decided to take a look at what >> systems they recommend as being free. > > I've got all the respect in the world for the work that RMS has done > over the years ... but: > > gnu.org does not acknowledge any license but the GPL as being "truly > free", and they'll never acknowledge any system that is not 100.00% > GPL code as being "truly free". Draw your own conclusions about how > that stance connects to reality. Tom, having been advised by RMS to use the three clause BSD license on code, I have personal experience that refutes your claim. It's also pretty easy to refute it based on documentation on the GNU.org site: http://www.gnu.org/licenses/license-list.html#SoftwareLicenses The reason the FSF isn't advocating Fedora at this point is pretty much only because Fedora doesn't yet strip the binary firmware provided by the Linux kernel (and still provides some re-distributable binary firmware in other packages, the microcode package and alsa-firmware I think). I suppose there is also still some inertia from back at a time when Fedora wasn't as good it is now with licensing checking on packages. I think the situation right now is pretty unfortunate for all involved: Fedora isn't getting the level of acknowledgement it deserves, and the FSF is indirectly promoting Ubuntu, a distribution which is, as far as I can tell, a primary driving factor in new users using and depending on proprietary software. The notion that firmware ought to be free isn't absurd: It doesn't take much effort to find examples of firmware imposing unreasonable limits on users, or firmware containing nasty hidden security bugs. But non-free firmware is something that has only been called for in earnest somewhat recently, in the past it wasn't the lowest hanging fruit in improving user freedom that it is now. It also wasn't so obviously important, but since firmware is increasingly able to spy on users or limit their actions, and since it's increasingly subject to upgrades by manufacturers which are against the user's interests, it becomes increasingly important that people have the ability to understand and modify their field-replaceable firmware. We can probably expect that once free firmware becomes easy for everyone to accomplish the FSF will move on to promoting an additional tougher requirement, thats their job and their nature. From mtasaka at ioa.s.u-tokyo.ac.jp Sun Sep 7 09:25:21 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Sun, 07 Sep 2008 18:25:21 +0900 Subject: Fedora not "free" enough for GNU? In-Reply-To: References: Message-ID: <48C39E01.3060802@ioa.s.u-tokyo.ac.jp> Michel Salim wrote, at 09/07/2008 03:57 PM +9:00: > I was just over at gnu.org to download the anniversary video recorded > by Stephen Fry, and while I was there decided to take a look at what > systems they recommend as being free. > > They list BLAG, which is based on Fedora. But Fedora itself (and > Debian) is not there! > > http://www.gnu.org/links/links.html#FreeGNULinuxDistributions > > This struck me as rather strange, especially considering their > guidelines are actually based on Fedora's (and we are thanked for it): > http://www.gnu.org/philosophy/free-system-distribution-guidelines.html > > As far as I remember, Rahul Sundaram was talking to the GNU / FSF > people about this quite a while back. Is it just the difference over > binary-only firmware that's consigning us to the "non-free" heap? I cannot do any legal comment here, however I just want to say that I don't want to see the nightmare which happened on fedora-list any more. https://www.redhat.com/archives/fedora-list/2008-July/thread.html#01481 Regards, Mamoru From vgaburici at gmail.com Sun Sep 7 09:47:51 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Sun, 7 Sep 2008 12:47:51 +0300 Subject: Why I'll leave fedora (french speaking people only) [1] In-Reply-To: <48C344F2.4090705@gmail.com> References: <200809070135.54996.alain.portal@free.fr> <48C337DA.2050009@gmail.com> <48C344F2.4090705@gmail.com> Message-ID: Well, I can read French. Reading that long diatribe on bugzilla reminded me of some talk pages on less reputable forums and wikis... Also, the "Zig Heil" in the email sent to this list is getting close to Godwin's law. I'm not going to comment on the long-term ban because I don't know the specifics, but I think a bit of moderation wouldn't hurt both sides in this matter. If administrative abuse did happen, I'm sure there's a civilized way to address it. On Sun, Sep 7, 2008 at 6:05 AM, Lyos Gemini Norezel wrote: > Lyos Gemini Norezel wrote: >> >> Alain PORTAL wrote: >>> >>> Pfff... >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=455277#c8 >>> >>> En fait, quand je me relis, je me rend compte que finalement je ne donne >>> pas vraiment les raisons... Sans doute ai-je trop donn? d'explications >>> ailleurs. >>> >>> Eh Trashy, Zig Heil ! >>> >>> No regards for ass holes >>> Alain >>> >>> [1] You can read french? >>> I'm sorry, but don't forget french is the diplomacy language. >>> >> >> Ok... I cannot read French... but from what google's translator is able to >> decipher... it looks to me like you are the one being unreasonable. >> You say here: "Je te trouve particuli?rement glonfl? de venir oser me >> proposer ton aide alors que tu m'as banni ? la fois d'IRC [1] et des forums >> fedora-fr..." >> that you were banned from IRC and fedora-fr... well, if you were indeed >> banned, there must have been some reason for it. >> >> I won't delve into that here... though I'm sure someone will enlighten us. >> >> The point is... things take time... and with everything going on with >> Fedora Infrastructure in the last month... you should expect it to take >> longer. >> >> Chill out... >> remember, it's only code. >> >> Lyos Gemini Norezel >> > Alain... > > As a followup to my above post... > regardless of how you feel about Johan Cwiklinski... you should not ignore > his advice. > > If you'd been watching the mailing list... you'd know that Fedora > Infrastructure was compromised last month... because of that... > package keys were changed... and ssh keys were reset. You must re-add your > ssh key... though you should note that DSA keys are no > longer allowed... you must use an RSA key. > > Just thought you should know. > > Lyos Gemini Norezel > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From benny+usenet at amorsen.dk Sun Sep 7 10:00:02 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Sun, 07 Sep 2008 12:00:02 +0200 Subject: Fedora not "free" enough for GNU? In-Reply-To: (Gregory Maxwell's message of "Sun\, 7 Sep 2008 05\:15\:27 -0400") References: <8553.1220772699@sss.pgh.pa.us> Message-ID: "Gregory Maxwell" writes: > It also wasn't so obviously important, but since firmware is > increasingly able to spy on users or limit their actions, and since > it's increasingly subject to upgrades by manufacturers which are > against the user's interests, it becomes increasingly important that > people have the ability to understand and modify their > field-replaceable firmware. Stallman's quest started with a Xerox laser printer... http://oreilly.com/openbook/freedom/ch01.html /Benny From vgaburici at gmail.com Sun Sep 7 10:08:04 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Sun, 7 Sep 2008 13:08:04 +0300 Subject: Why I'll leave fedora (french speaking people only) [1] In-Reply-To: <1220754913.17785.105.camel@rosebud> References: <200809070135.54996.alain.portal@free.fr> <48C337DA.2050009@gmail.com> <1220754913.17785.105.camel@rosebud> Message-ID: On Sun, Sep 7, 2008 at 5:35 AM, Seth Vidal wrote: > On Sat, 2008-09-06 at 22:09 -0400, Lyos Gemini Norezel wrote: >> Alain PORTAL wrote: >> > Pfff... >> > >> > https://bugzilla.redhat.com/show_bug.cgi?id=455277#c8 >> > >> > En fait, quand je me relis, je me rend compte que finalement je ne donne pas >> > vraiment les raisons... Sans doute ai-je trop donn? d'explications ailleurs. >> > >> > Eh Trashy, Zig Heil ! >> > >> > No regards for ass holes >> > Alain >> > >> > [1] You can read french? >> > I'm sorry, but don't forget french is the diplomacy language. >> > >> Ok... I cannot read French... but from what google's translator is able >> to decipher... it looks to me like you are the one being unreasonable. >> You say here: "Je te trouve particuli?rement glonfl? de venir oser me >> proposer ton aide alors que tu m'as banni ? la fois d'IRC [1] et des >> forums fedora-fr..." >> that you were banned from IRC and fedora-fr... well, if you were indeed >> banned, there must have been some reason for it. > > > Let's be fair here. Just b/c someone was punished for something does not > mean that they did anything wrong. > > unjust punishments happen all the time. > > -sv I his bugzilla message he is complaining (amongst other things) that FESCO did not consider the matter. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From debarshi.ray at gmail.com Sun Sep 7 10:20:30 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sun, 7 Sep 2008 15:50:30 +0530 Subject: Packaging Cherokee In-Reply-To: <3170f42f0808241209w8d44b00p70a0e0084c0c636c@mail.gmail.com> References: <3170f42f0808241209w8d44b00p70a0e0084c0c636c@mail.gmail.com> Message-ID: <3170f42f0809070320o382e28dft6b0da4931325c2a9@mail.gmail.com> Here is the current status: http://rishi.fedorapeople.org/cherokee.spec http://rishi.fedorapeople.org/cherokee-0.8.1-1.fc9.src.rpm There is still some work left, like writing an init file, some testing and so on. If someone was already working on it please let me know so that I can merge your changes with mine. Happy hacking, Debarshi From lyos.gemininorezel at gmail.com Sun Sep 7 10:24:38 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Sun, 07 Sep 2008 06:24:38 -0400 Subject: Why I'll leave fedora (french speaking people only) [1] In-Reply-To: References: <200809070135.54996.alain.portal@free.fr> <48C337DA.2050009@gmail.com> <1220754913.17785.105.camel@rosebud> Message-ID: <48C3ABE6.7040909@gmail.com> Vasile Gaburici wrote: > > I his bugzilla message he is complaining (amongst other things) that > FESCO did not consider the matter. > I, too, noticed this. I forgot to mention it in my previous message... but I wanted to ask: Was this issue ever raised in a FESCo meeting? Was this issue ever put on the discussion agenda? One thing many people do not understand... is that any (comparatively) small governing body, is (by necessity) going to be swamped by issues. I/We may not like it (I despise bureaucracy in all it's forms)... but it's a fact of life. If he did do either of the above... then I can share his outrage. Otherwise... *shrug*... you can't help those who refuse to help themselves. Just my thoughts/opinions. Lyos Gemini Norezel From dave at rimini.com Sun Sep 7 10:41:35 2008 From: dave at rimini.com (Davide Moretti) Date: Sun, 07 Sep 2008 12:41:35 +0200 Subject: Boot speedup with readahead Message-ID: <20080907124135.9qcpb7jgp0oos408@mail.rimini.com> On my system: Without readahead: 1 minute and 30 seconds With readahead: 1 minute and 30 seconds Time was until gnome applet showed up, so on my system readahead did not improve boot speed at all. Note that there is a bug that prevents readahead-collector from starting if you have selinux disabled, since the /.autorelabel file is still hanging around during reboots, I had to remove this file for collector to work. 1) The rhgb removal is a big step forwards, rhgb slows down things a lot. 2) One major thing to look at I think is the initrd and udev, these take really a lot of time 3) Get rid of that sysinit stuff and start using upstart jobs, I still have not seen any progress on this. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From j.w.r.degoede at hhs.nl Sun Sep 7 11:09:00 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 07 Sep 2008 13:09:00 +0200 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <48C3B64C.9050804@hhs.nl> Matt Domsch wrote: > camstream-0.26.3-12.fc8 [u'434345 ASSIGNED'] (build/make) nomis80 I've taken care of this one (as part of my better webcam support work). Regards, Hans From lyos.gemininorezel at gmail.com Sun Sep 7 11:09:50 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Sun, 07 Sep 2008 07:09:50 -0400 Subject: Proposal: Split Fedora into sub-distributions Message-ID: <48C3B67E.6090301@gmail.com> It's come to my attention lately that Fedora has, essensially, become 'to big for it's britches' (as you old farts like to say). I think the time has come for Fedora to be split up into subgroups: Fedora-Mainstream - For mainstream (ie., 'idiot') users... the types of people who buy a $399 Wal-mart POS and expect it to 'Just Work' forever. Fedora-Mini- Generic group for all 'miniature' Fedora distributions... of which I'm sure I'm missing several. --Fedora-Embedded - Self explanatory I suspect --Fedora-Low-Bandwidth - For people on low bandwidth connections... this group would be primarily focused on 'how long will this take to download?' Fedora-Development - Generic development platform Fedora-HPC - The High Performance Computing segment Fedora-Legacy - Everything older than a Pentium 3 (or, alternatively... all processors slower than ~1.0GHz). Fedora-Server - Server distribution... should include all tools necessary to setup various servers Fedora-Live - All of the 'Live' distributions should go here... anything from LiveCDs to LiveUSB images. This proposal is far from complete... but I think it is necessary to stop trying to be a 'everything and the kitchen sink' distribution... and instead focus more on the groups that use fedora. For instance, the majority of those on mainstream, are not going to need stuff like apache, perl, python, etc. John Q Public wants to read his email, browse the web, watch porn/internet videos, etc... not write code, manage a server, or screw with a command line. By the same token, a developer is not likely to use any gui tool that does not provide some extreme 'ease of use' case (be honest, how many of ya'll use vi or vim over gedit?). Fedora cannot (realistically) provide an ideal all-in-one distribution, but it can, if ya'll are willing to try, provide multiple distributions capable of providing ideal platforms to each group. To some extent, these groups already exist, but they are not/cannot be complete until the distribution is behind each one. I know many will knock this idea as "hard to maintain", but... is it really? The infrastructure will be difficult to setup, but once done, should be a breeze to maintain. Especially since everyone here already focuses on their ideal use case anyway. Maybe it's just me, but I think it's time Fedora stops trying to become another Debian, and starts catering to the groups that comprise it. What do ya'll think? Lyos Gemini Norezel From lyos.gemininorezel at gmail.com Sun Sep 7 11:13:16 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Sun, 07 Sep 2008 07:13:16 -0400 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <48C3B67E.6090301@gmail.com> References: <48C3B67E.6090301@gmail.com> Message-ID: <48C3B74C.5000406@gmail.com> Lyos Gemini Norezel wrote: > Fedora-Mainstream - For mainstream (ie., 'idiot') users... the types > of people who buy a $399 Wal-mart POS and expect it to 'Just Work' > forever. > Fedora-Mini- Generic group for all 'miniature' Fedora > distributions... of which I'm sure I'm missing several. > --Fedora-Embedded - Self explanatory I suspect > --Fedora-Low-Bandwidth - For people on low bandwidth connections... > this group would be primarily focused on 'how long will this take to > download?' *Sigh*... my formatting skills are evidently lacking... the above should read: Fedora-Mainstream - For mainstream (ie., 'idiot') users... the types of people who buy a $399 Wal-mart POS and expect it to 'Just Work' forever. Fedora-Mini- Generic group for all 'miniature' Fedora distributions... of which I'm sure I'm missing several. --Fedora-Embedded - Self explanatory I suspect --Fedora-Low-Bandwidth - For people on low bandwidth connections... this group would be primarily focused on 'how long will this take to download?' Lyos Gemini Norezel From drago01 at gmail.com Sun Sep 7 11:32:16 2008 From: drago01 at gmail.com (drago01) Date: Sun, 7 Sep 2008 13:32:16 +0200 Subject: Boot speedup with readahead In-Reply-To: <20080906212125.27b9b3bb@infradead.org> References: <20080906212125.27b9b3bb@infradead.org> Message-ID: On Sun, Sep 7, 2008 at 6:21 AM, Arjan van de Ven wrote: > On Sat, 06 Sep 2008 12:52:56 +0200 > Harald Hoyer wrote: > >> Hello fellow Fedora developers, >> >> recently readahead was modified to adapt to system file changes and >> to start very early in the boot process via upstart. >> >> I would like to encourage you to test readahead-1.4.5-3.fc10 from >> rawhide (even possible on F9), which I built some minutes ago. It may >> take a day to reach your local mirror. >> >> # yum --enablerepo=rawhide install readahead >> or >> # yum --enablerepo=rawhide update readahead >> >> With the next reboot readahead-collector runs and collects the >> information which files are used during the boot process. The next >> reboot then, readahead read ahead those files and the boot process >> (from init start to gdm login screen) should be approx. 10% faster. >> > > for those who are going to the plumbers conference... Auke Kok and I > will present there on how to make a Fedora based system boot in 5 > seconds... > > and yes a form of readahead was needed to achieve that ;-) wtf? without a custom kernel I doubt that this is possible.... From drago01 at gmail.com Sun Sep 7 11:35:26 2008 From: drago01 at gmail.com (drago01) Date: Sun, 7 Sep 2008 13:35:26 +0200 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <48C3B67E.6090301@gmail.com> References: <48C3B67E.6090301@gmail.com> Message-ID: On Sun, Sep 7, 2008 at 1:09 PM, Lyos Gemini Norezel wrote: > What do ya'll think? That's what spins are for. From lyos.gemininorezel at gmail.com Sun Sep 7 11:50:24 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Sun, 07 Sep 2008 07:50:24 -0400 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: References: <48C3B67E.6090301@gmail.com> Message-ID: <48C3C000.6070009@gmail.com> drago01 wrote: > That's what spins are for. Perhaps... but that doesn't help the main distribution. With the main distribution... ya'll are just encouraging the unhealthy attitude that 'bloated is better'. Why encourage people to use an OS that is bogged down with crap they don't need and will never use? I just think it's time for the Fedora community to redefine it's aim/goals. Lyos Gemini Norezel From stlwrt at gmail.com Sun Sep 7 11:52:18 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Sun, 7 Sep 2008 14:52:18 +0300 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <48C3B67E.6090301@gmail.com> References: <48C3B67E.6090301@gmail.com> Message-ID: On Sun, Sep 7, 2008 at 2:09 PM, Lyos Gemini Norezel wrote: > Fedora-Development - Generic development platform DVD has "Development" group with libs and headers and GCC and what not. > Fedora-Legacy - Everything older than a Pentium 3 (or, alternatively... all > processors slower than ~1.0GHz). Join XFCE SIG, they create spin with lightweight software. > Fedora-Server - Server distribution... should include all tools necessary to > setup various servers Again, DVD has "Server" group, and "Storage clustering" and "Virtualization"... > Fedora-Live - All of the 'Live' distributions should go here... anything > from LiveCDs to LiveUSB images. Desktop Media, KDE Media. They're also installable on USB > This proposal is far from complete... but I think it is necessary to stop > trying to be a 'everything and the kitchen sink' distribution... > and instead focus more on the groups that use fedora. For instance, the > majority of those on mainstream, are not going to need stuff > like apache, perl, python, etc. Majority of mainstream can use live media. Making them choose between >10 installation media is pointless > John Q Public wants to read his email, browse the web, watch porn/internet > videos, etc... not write code, manage a server, or screw > with a command line. Desktop Media! > By the same token, a developer is not likely to use any gui tool that does > not provide some extreme 'ease of use' case (be honest, > how many of ya'll use vi or vim over gedit?). Desktop Media after one "yum install gcc eclipse..." > To some extent, these groups already exist, but they are not/cannot be > complete until the distribution is behind each one. > The infrastructure will be difficult to setup, but once done, should be a > breeze to maintain. You are welcome! =) Join team, contribute, maintain spins you think are worth it. -- http://scwlab.com From konrad at tylerc.org Sun Sep 7 12:08:08 2008 From: konrad at tylerc.org (Conrad Meyer) Date: Sun, 7 Sep 2008 05:08:08 -0700 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <48C3C000.6070009@gmail.com> References: <48C3B67E.6090301@gmail.com> <48C3C000.6070009@gmail.com> Message-ID: <200809070508.08850.konrad@tylerc.org> Quoth Lyos Gemini Norezel: > drago01 wrote: > > That's what spins are for. > Perhaps... but that doesn't help the main distribution. > With the main distribution... ya'll are just encouraging the unhealthy > attitude that 'bloated is better'. Why encourage people to use an OS > that is bogged down with crap they don't need and will never use? > > I just think it's time for the Fedora community to redefine it's aim/goals. > > Lyos Gemini Norezel It's not like everyone must install Fedora Everything. Most users install the basic desktop and then go from there. I think most Debian users do something roughly like that too. Regards, -- Conrad Meyer From rawhide at fedoraproject.org Sun Sep 7 12:08:45 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sun, 7 Sep 2008 12:08:45 +0000 (UTC) Subject: rawhide report: 20080907 changes Message-ID: <20080907120845.3917E1F8249@releng2.fedora.phx.redhat.com> New package coredumper Library to create core dumps New package ctemplate A simple but powerful template language for C++ New package python-id3 ID3 tag library for Python New package pyvnc2swf Vnc screen recorder New package txt2rss Convert from txt to rss Updated Packages: Django-1.0-1.fc10 ----------------- * Sat Sep 6 18:00:00 2008 Michel Salim - 1.0-1 - Update to final 1.0 release amora-1.1-1.fc10 ---------------- * Sat Sep 6 18:00:00 2008 Allisson Azevedo 1.1-1 - Update to 1.1 - Added dbus-devel in BuildRequires aterm-1.0.1-3.fc10 ------------------ * Sat Sep 6 18:00:00 2008 Andreas Bierfert - 1.0.1-3 - fix #440779 audacious-1.5.1-3.fc10 ---------------------- * Sat Sep 6 18:00:00 2008 Ralf Ertzinger 1.5.1-3 - Remove libSAD headers from devel package, they were not meant to be public audacious-plugins-1.5.1-2.fc10 ------------------------------ * Sat Sep 6 18:00:00 2008 Ralf Ertzinger 1.5.1-2 - Incorporate libmtp patch by Linus Walleij (BZ#459293) bouml-4.5-1.fc10 ---------------- * Sat Sep 6 18:00:00 2008 Debarshi Ray - 4.5-1 - Version bump to 4.5. Closes Red Hat Bugzilla bug #460528. - Previous releases can not read a project saved with this version, but projects made by previous releases can be read. clutter-0.8.0-1.fc10 -------------------- * Sat Sep 6 18:00:00 2008 Allisson Azevedo 0.8.0-1 - Update to 0.8.0 darkgarden-fonts-1.1-4.fc10 --------------------------- * Sat Sep 6 18:00:00 2008 Lyos Gemini Norezel 1.1-4 - rebuild with new release of fontforge. filesystem-2.4.19-1.fc10 ------------------------ * Sat Sep 6 18:00:00 2008 Phil Knirsch - 2.4.19-1 - Added augeas lenses dir (#461317) - Small specfile fix fluxbox-1.1.0.1-1.fc10 ---------------------- * Sat Sep 6 18:00:00 2008 Andreas Bierfert - 1.1.0.1-1 - version upgrade * Wed Sep 3 18:00:00 2008 Andreas Bierfert - 1.1.0-1 - version upgrade fwbuilder-3.0.0-1.fc10 ---------------------- * Sat Sep 6 18:00:00 2008 Ralf Ertzinger 3.0.0-1 - Update to 3.0.0 g-wrap-1.9.9-7.fc10 ------------------- * Sat Sep 6 18:00:00 2008 Xavier Lamien - 1.9.9-7 - Remove out-dated patch -info.patch. - Rebuild for Rawhide bug #434278. * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 1.9.9-6 - Autorebuild for GCC 4.3 gai-pal-0.7-15.fc10 ------------------- * Sat Sep 6 18:00:00 2008 Michael Schwendt - 0.7-15 - apply first patch as patch0 genius-1.0.3-2.fc10 ------------------- * Sat Sep 6 18:00:00 2008 Gerard Milmeister - 1.0.3-1 - new release 1.0.3 goffice-0.6.5-1.fc10 -------------------- * Sun Sep 7 18:00:00 2008 Julian Sikorski - 0.6.5-1 - Updated to 0.6.5 - Development docs are now in goffice-0.6 grisbi-0.5.9-7.fc10 ------------------- * Sat Sep 6 18:00:00 2008 Aurelien Bompard 0.5.9-7 - rediff patch0 * Sat Sep 6 18:00:00 2008 Aurelien Bompard 0.5.9-6 - use texlive instead of tetex guile-gnome-platform-2.15.93-8.fc10 ----------------------------------- * Sat Sep 6 18:00:00 2008 Xavier Lamien - 2.15.93-8 - Rebuild for rawhide. * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 2.15.93-7 - Autorebuild for GCC 4.3 icu-4.0-3.fc10 -------------- * Sat Sep 6 18:00:00 2008 Caolan McNamara - 4.0-3 - Resolves: rhbz#461348 wrong icu-config jd-2.0.1-0.2.svn2316_trunk.fc10 ------------------------------- * Sun Sep 7 18:00:00 2008 Mamoru Tasaka - rev 2316 - revert default browser setting kernel-2.6.27-0.312.rc5.git7.fc10 --------------------------------- * Sun Sep 7 18:00:00 2008 Dave Airlie - disable radeon verbose debugging. doh. * Sat Sep 6 18:00:00 2008 Dave Airlie - powerpc build broken disable FSL_UPM * Sat Sep 6 18:00:00 2008 Dave Airlie - fix lirc on powerpc64 - its Saturday goddamit. libfwbuilder-3.0.0-2.fc10 ------------------------- * Sat Sep 6 18:00:00 2008 Ralf Ertzinger 3.0.0-1 - Move .so files to -devel subpackage - Use full URL in Source: (thanks to Till Maas for the hints) ntfs-config-1.0.1-2.fc10 ------------------------ * Sat Sep 6 18:00:00 2008 Xavier Lamien - 1.0.1-2 - Rebuild for rawhide bug #449585. * Mon Aug 11 18:00:00 2008 Tom "spot" Callaway - 1.0.1-1 - fix license tag - update to 1.0.1 pan-0.133-1.fc10 ---------------- * Sat Sep 6 18:00:00 2008 Erik van Pienbroek - 1:0.133-1 - Update to version 0.133 (fixes GCC 4.3 compilation problems) - Remove upstreamed patch * Wed May 21 18:00:00 2008 Tom "spot" Callaway - 1:0.132-4 - fix license tag * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 1:0.132-3 - Autorebuild for GCC 4.3 perl-Class-MOP-0.65-1.fc10 -------------------------- * Sat Sep 6 18:00:00 2008 Chris Weyl 0.65-1 - update to 0.65 - adjust br's perl-Moose-0.57-2.fc10 ---------------------- * Sat Sep 6 18:00:00 2008 Chris Weyl 0.57-2 - add additional test BR's * Sat Sep 6 18:00:00 2008 Chris Weyl 0.57-1 - update to 0.57 perl-MooseX-AttributeHelpers-0.13-1.fc10 ---------------------------------------- * Sat Sep 6 18:00:00 2008 Chris Weyl 0.13-1 - update to 0.13 - note BR on Moose is now at 0.56 and is not optional :) pixman-0.11.10-1.fc10 --------------------- * Sat Sep 6 18:00:00 2008 Soren Sandmann 0.11.10-1 - Upgrade to 0.11.10. Drop altivec patch. readahead-1.4.5-3.fc10 ---------------------- * Sat Sep 6 18:00:00 2008 Harald Hoyer 1.4.5-3 - marked /etc/sysconfig/readahead as a config file - removed noreplace from /etc/readahead.conf - fixed /etc/readahead.conf for /sbin/readahead rpm-4.5.90-0.git8461.5 ---------------------- * Sat Sep 6 18:00:00 2008 Jindrich Novy - fail hard if patch isn't found (#461347) rrdtool-1.3.2-1.fc10 -------------------- * Sat Sep 6 18:00:00 2008 Jarod Wilson 1.3.2-1 - Update to rrdtool 1.3.2 * fixes a data corruption bug when rrd wraps around * make imginfo behave the same as docs say it does * fixes for numerous memory leaks scribus-1.3.5-0.4.12516svn.fc10 ------------------------------- * Fri Sep 5 18:00:00 2008 Andreas Bierfert - 1.3.5-0.4.12516svn - new svn snapshot sectool-0.8.6-2.fc10 -------------------- * Sat Sep 6 18:00:00 2008 Peter Vrabec - 0.8.6-2 - fix selinux DEPS, quick workaround sugar-0.82.3-2.fc10 ------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway - 0.82.3-2 - fix license tag * Sat Sep 6 18:00:00 2008 Marco Pesenti Gritti - 0.82.3-1 - #8300 Shell _launchers are leaked - #7856 notify::active behaviour change - #8250 Invalid POT for "Copyright and License" of control panel sugar-artwork-0.82.1-2.fc10 --------------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway - 0.82.1-2 - fix license tag sugar-datastore-0.8.3-2.fc10 ---------------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway - 0.8.3-2 - fix license tag supervisor-2.1-5.fc10 --------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway - 2.1-5 - fix license tag svrcore-4.0.4-3.fc10 -------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway - 4.0.4-3 - fix license tag symlinks-1.2-32.fc10 -------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway 1.2-32 - fix license tag synce-trayicon-0.11-2.fc10 -------------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway - 0.11-2 - fix license tag sysconftool-0.15-4.fc10 ----------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway - 0.15-4 - fix license tag syslinux-3.61-3.fc10 -------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway - 3.61-3 - fix license tag syslog-ng-2.0.8-2.fc10 ---------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway 2.0.8-2 - fix license tag system-config-boot-0.2.20-2.fc10 -------------------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway - 0.2.20-2 - fix license tag system-config-cluster-1.0.53-2 ------------------------------ * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway 1.0.53-2 - fix license tag system-config-httpd-1.4.4-2.fc10 -------------------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway 5:1.4.4-2 - fix license tag system-switch-mail-0.5.26-3 --------------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway - 0.5.26-3 - fix license tag thibault-fonts-0.1-2.fc10 ------------------------- * Sat Sep 6 18:00:00 2008 Lyos Gemini Norezel 0.1-2 - Rebuild for new fontforge release. whysynth-dssi-20080412-2.fc10 ----------------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway 20080412-2 - fix license tag wifi-radar-1.9.9-1.fc10 ----------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway 1.9.9-1 - fix license tag - update to 1.9.9 wings-0.99.02-2.fc10 -------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway - 0.99.02-2 - fix license tag wmctrl-1.07-4.fc10 ------------------ * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway 1.07-4 - fix license tag wordtrans-1.1-0.6.pre13.fc10 ---------------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway 1.1-0.6.pre13 - fix license tag ws-commons-util-1.0.1-8.fc10 ---------------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway - 1.0.1-8 - fix license tag * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 1.0.1-7 - Autorebuild for GCC 4.3 wuja-0.0.8-4.fc10 ----------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway 0.0.8-4 - fix license tag wxGTK-2.8.8-2.fc10 ------------------ * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway - 2.8.8-2 - fix license tag * Thu Jul 31 18:00:00 2008 Dan Horak - 2.8.8-1 - update to 2.8.8 (rh bug #457406) xalan-j2-2.7.0-7.4.fc10 ----------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway 0:2.7.0-7.4 - fix license tag xastir-1.9.2-10.fc10 -------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway - 1.9.2-10 - fix license tag - fix spec up so it doesn't confuse license checking script xemacs-packages-extra-20070427-3.fc10 ------------------------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway - 20070427-3 - fix license tag xl2tpd-1.1.12-3.fc10 -------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway 1.1.12-3 - fix license tag xmlrpc-c-1.14.8-2.fc10 ---------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway - 1.14.8-2 - fix license tag xorg-x11-drv-ati-6.9.0-9.fc10 ----------------------------- * Fri Sep 5 18:00:00 2008 Dave Airlie 6.9.0-9 - add fix for pipe register emits on r300 * Fri Sep 5 18:00:00 2008 Dave Airlie 6.9.0-8 - fix suspend/resume support - needs new pinning API xpp3-1.1.3.8-1.2.fc10 --------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway - 0:1.1.3.8-1.2 - fix license tag - drop jpp tag yasm-0.7.1-2.fc10 ----------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway 0.7.1-2 - fix license tag so that it doesn't trigger a false positive on the check script Summary: Added Packages: 5 Removed Packages: 0 Modified Packages: 63 Broken deps for i386 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 clutter-cairo-0.6.2-1.fc10.i386 requires libclutter-glx-0.6.so.0 clutter-gst-0.6.1-1.fc9.i386 requires libclutter-glx-0.6.so.0 clutter-gtk-0.6.1-1.fc10.i386 requires libclutter-glx-0.6.so.0 cluttermm-0.5.1-2.fc10.i386 requires libclutter-glx-0.6.so.0 cluttermm-cairo-0.5.1-2.fc10.i386 requires libclutter-glx-0.6.so.0 cluttermm-gtk-0.5.1-2.fc10.i386 requires libclutter-glx-0.6.so.0 evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.11-1.fc10.i386 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.i386 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.i386 requires perl(MT::Entry) highlight-2.6.11-1.fc10.i386 requires perl(MT) highlight-2.6.11-1.fc10.i386 requires perl(MT::Template::Context) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so poker3d-1.1.36-10.fc10.i386 requires libosg.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgUtil.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgSim.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgTerrain.so.35 poker3d-1.1.36-10.fc10.i386 requires libOpenThreads.so.10 poker3d-1.1.36-10.fc10.i386 requires libosgGA.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgFX.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgManipulator.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgDB.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgParticle.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgViewer.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgText.so.35 pyclutter-0.6.2-2.fc10.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc10.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc10.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc10.i386 requires libclutter-glx-0.6.so.0 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for x86_64 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) clutter-cairo-0.6.2-1.fc10.i386 requires libclutter-glx-0.6.so.0 clutter-cairo-0.6.2-1.fc10.x86_64 requires libclutter-glx-0.6.so.0()(64bit) clutter-gst-0.6.1-1.fc9.i386 requires libclutter-glx-0.6.so.0 clutter-gst-0.6.1-1.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) clutter-gtk-0.6.1-1.fc10.i386 requires libclutter-glx-0.6.so.0 clutter-gtk-0.6.1-1.fc10.x86_64 requires libclutter-glx-0.6.so.0()(64bit) cluttermm-0.5.1-2.fc10.i386 requires libclutter-glx-0.6.so.0 cluttermm-0.5.1-2.fc10.x86_64 requires libclutter-glx-0.6.so.0()(64bit) cluttermm-cairo-0.5.1-2.fc10.i386 requires libclutter-glx-0.6.so.0 cluttermm-cairo-0.5.1-2.fc10.x86_64 requires libclutter-glx-0.6.so.0()(64bit) cluttermm-gtk-0.5.1-2.fc10.i386 requires libclutter-glx-0.6.so.0 cluttermm-gtk-0.5.1-2.fc10.x86_64 requires libclutter-glx-0.6.so.0()(64bit) evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Entry) highlight-2.6.11-1.fc10.x86_64 requires perl(MT) highlight-2.6.11-1.fc10.x86_64 requires perl(MT::Template::Context) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgFX.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgGA.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgTerrain.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosg.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgSim.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgText.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgDB.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libOpenThreads.so.10()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgManipulator.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgParticle.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgViewer.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgUtil.so.35()(64bit) pyclutter-0.6.2-2.fc10.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc10.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc10.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc10.x86_64 requires libclutter-glx-0.6.so.0()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for ppc ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 clutter-cairo-0.6.2-1.fc10.ppc requires libclutter-glx-0.6.so.0 clutter-cairo-0.6.2-1.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) clutter-gst-0.6.1-1.fc9.ppc requires libclutter-glx-0.6.so.0 clutter-gst-0.6.1-1.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) clutter-gtk-0.6.1-1.fc10.ppc requires libclutter-glx-0.6.so.0 clutter-gtk-0.6.1-1.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) cluttermm-0.5.1-2.fc10.ppc requires libclutter-glx-0.6.so.0 cluttermm-0.5.1-2.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) cluttermm-cairo-0.5.1-2.fc10.ppc requires libclutter-glx-0.6.so.0 cluttermm-cairo-0.5.1-2.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) cluttermm-gtk-0.5.1-2.fc10.ppc requires libclutter-glx-0.6.so.0 cluttermm-gtk-0.5.1-2.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.11-1.fc10.ppc requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc requires perl(MT::Entry) highlight-2.6.11-1.fc10.ppc requires perl(MT) highlight-2.6.11-1.fc10.ppc requires perl(MT::Template::Context) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so poker3d-1.1.36-10.fc10.ppc requires libosg.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgUtil.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgSim.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgTerrain.so.35 poker3d-1.1.36-10.fc10.ppc requires libOpenThreads.so.10 poker3d-1.1.36-10.fc10.ppc requires libosgGA.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgFX.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgManipulator.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgDB.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgParticle.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgViewer.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgText.so.35 pyclutter-0.6.2-2.fc10.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc10.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc10.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc10.ppc requires libclutter-glx-0.6.so.0 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires libbfd-2.18.50.0.8-2.fc10.so stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires libopcodes-2.18.50.0.8-2.fc10.so vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for ppc64 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) clutter-cairo-0.6.2-1.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) clutter-gst-0.6.1-1.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) clutter-gtk-0.6.1-1.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) cluttermm-0.5.1-2.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) cluttermm-cairo-0.5.1-2.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) cluttermm-gtk-0.5.1-2.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Plugin) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::WeblogPublisher) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Entry) highlight-2.6.11-1.fc10.ppc64 requires perl(MT) highlight-2.6.11-1.fc10.ppc64 requires perl(MT::Template::Context) livecd-tools-018-1.fc10.ppc64 requires yaboot mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 poker3d-1.1.36-10.fc10.ppc64 requires libosgFX.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgGA.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgTerrain.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosg.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgSim.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgText.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgDB.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libOpenThreads.so.10()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgManipulator.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgParticle.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgViewer.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgUtil.so.35()(64bit) pyclutter-0.6.2-2.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 From denis at poolshark.org Sun Sep 7 12:18:49 2008 From: denis at poolshark.org (Denis Leroy) Date: Sun, 07 Sep 2008 14:18:49 +0200 Subject: Why I'll leave fedora (french speaking people only) [1] In-Reply-To: References: <200809070135.54996.alain.portal@free.fr> <48C337DA.2050009@gmail.com> <48C344F2.4090705@gmail.com> Message-ID: <48C3C6A9.7050705@poolshark.org> Vasile Gaburici wrote: > Well, I can read French. Reading that long diatribe on bugzilla > reminded me of some talk pages on less reputable forums and wikis... > Also, the "Zig Heil" in the email sent to this list is getting close > to Godwin's law. > > I'm not going to comment on the long-term ban because I don't know the > specifics, but I think a bit of moderation wouldn't hurt both sides in > this matter. If administrative abuse did happen, I'm sure there's a > civilized way to address it. Right, there is clearly a need for mediation here. I read one of the forum discussions that led to Alain's ban, and there is indeed evidence of some verbal abuse and unfortunate postings, evidence of someone having a bad linux day. While this is hardly an excuse, the month ban seems harsh. Alain feels he has been cut off from his main source of packaging technical help. Maybe we should create a fedora-devel-fr mailing list ? I don't know what happened about the IRC channels ban. Hopefully Johan can post the logs and explain. -denis From mailings at x-tnd.be Sun Sep 7 13:20:37 2008 From: mailings at x-tnd.be (Johan Cwiklinski) Date: Sun, 07 Sep 2008 15:20:37 +0200 Subject: Why I'll leave fedora (french speaking people only) [1] In-Reply-To: <48C3C6A9.7050705@poolshark.org> References: <200809070135.54996.alain.portal@free.fr> <48C337DA.2050009@gmail.com> <48C344F2.4090705@gmail.com> <48C3C6A9.7050705@poolshark.org> Message-ID: <48C3D525.80306@x-tnd.be> Denis Leroy a ?crit : > Vasile Gaburici wrote: >> Well, I can read French. Reading that long diatribe on bugzilla >> reminded me of some talk pages on less reputable forums and wikis... >> Also, the "Zig Heil" in the email sent to this list is getting close >> to Godwin's law. >> >> I'm not going to comment on the long-term ban because I don't know the >> specifics, but I think a bit of moderation wouldn't hurt both sides in >> this matter. If administrative abuse did happen, I'm sure there's a >> civilized way to address it. > > Right, there is clearly a need for mediation here. I read one of the > forum discussions that led to Alain's ban, and there is indeed > evidence of some verbal abuse and unfortunate postings, evidence of > someone having a bad linux day. While this is hardly an excuse, the > month ban seems harsh. Alain feels he has been cut off from his main > source of packaging technical help. Maybe we should create a > fedora-devel-fr mailing list ? > > I don't know what happened about the IRC channels ban. Hopefully Johan > can post the logs and explain. > > -denis > Hi, I did not want to respond that thread, because it's an evidence that insults is not the way to resolve anything, he is not asking any question nor trying to resolve the problem ; an answer from me was not asked nor required. Anyways, as the people who can read french can see on the fedora-fr.org forums, on the bugzilla, and here again, insults are more than present. It was the same on the IRC channel. About the duration of the initial ban on the forums, one other fedora-fr admin told me that I was a bit excessive, and he tried to resolve the problem. He was insulted too. By the way, that was this second person who ban him from #fedora-devel-fr, he cames after that to #fedora-fr to - once again! - insult the other admin, telling that he will bring suit, and so on... I've banned him from #fedora-fr in consequence. I'll no longer talk about this here, that's not the place. That problem is not development related, for the development problem that was pointed out, I give the solution on the bz, I had the same problem (as many other contributor) recently, and could give an answer. I do not care about what he is doing or not, nor about his feeling. He had to be polite, he was not, even when we simply asked him to be. When someone try to defend its position, he is again absolutely impolite... I'm not the only admin on fedora-fr, he can complain about me or whatever concerning fedora-fr to the relevant persons. To conclude, he was banned for his impoliteness, and asks impolitely to be deban. Is not there a problem ? He also says that he wants to fight with me, what a solution to resolve a problem. With these attitude, I can only stay on my position, and not answer longer to the messages that could be posted here. Regards, Johan From forum at ru.bir.ru Sun Sep 7 13:09:54 2008 From: forum at ru.bir.ru (forum) Date: Sun, 07 Sep 2008 17:09:54 +0400 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <48C3D2A2.2050904@ru.bir.ru> Matt Domsch ?????: > The following 90 packages have had FTBFS (Fails to Build From Source) > failures for several months, some as far back as February 2008. > > There are several "trivial" failures which could be addressed easily. > 8 fail due to unpackaged files > 6 fail due to patch fuzz > 1 fails due to open() not passing a mode. > > http://fedoraproject.org/wiki/FTBFS describes the FTBFS process. > > As was proposed to FESCO, packages with unresolved FTBFS bugs > immediately following the Alpha release will be removed from the > distribution. Package owners may request that their package _not_ be > removed provided they are actively working on resolving the FTBFS and > have a plan to resolve the FTBFS before the Release Candidate > release. FESCo has the final say of course, but these are the items > on my candidate list. I'd prefer packages get fixed rather than > removed. If you are the package owner, or are interested in the > future of these packages, please investigate these build failures and > fix them ASAP. > > aiksaurus-1.2.1-15.fc6 [u'434484 ASSIGNED'] (build/make) uwog > astyle-1.21-6.fc8 [u'433971 ASSIGNED'] (build/make) addutko,mtasaka > aterm-1.0.1-2.fc9 [u'440779 ASSIGNED'] (build/make) awjb > bes-3.5.3-3.fc9 [u'434360 ASSIGNED'] (build/make) pertusus > bitbake-1.8.8-1.fc8 [u'440562 ASSIGNED'] (build/make) ixs > bmpx-0.40.14-5.fc9 [u'449431 ASSIGNED'] (patch_fuzz) akahl > brltty-3.9-2.2.fc9 [u'449446 ASSIGNED'] (build/make) kasal > brutus-keyring-0.9.0-6.fc8 [u'434007 ASSIGNED'] (build/make) bpepple,colding > camstream-0.26.3-12.fc8 [u'434345 ASSIGNED'] (build/make) nomis80 > coolkey-1.1.0-6.fc9 [u'440753 ASSIGNED'] (build/make) rrelyea,jmagne > dap-freeform_handler-3.7.7-2.fc9 [u'434362 ASSIGNED'] (build/make) pertusus > dap-hdf4_handler-3.7.7-3.fc9 [u'434363 ASSIGNED'] (build/make) pertusus > djvulibre-3.5.20-2.fc9 [u'440910 ASSIGNED'] (build/make) thias > elektra-0.6.10-6.fc9 [u'434364 ASSIGNED'] (build/make) pertusus,kwizart > erlang-R12B-3.1.fc10 [u'449432 ASSIGNED'] (patch_fuzz) gemi > fish-1.23.0-2.fc9 [u'440724 ASSIGNED'] (build/make) ascii,oliver > fluxstyle-1.0.1-2.fc7 [u'440757 ASSIGNED'] (build/make) errr > fonttools-2.0-0.11.20060223cvs.fc7 [u'434409 ASSIGNED'] (unpackaged_files/python-egg-info?) roozbeh,fonts-sig > fontypython-0.2.0-6.fc7 [u'440756 ASSIGNED'] (build/make) cr33dog,fonts-sig > fwbuilder-2.1.16-2.fc9 [u'440846 ASSIGNED'] (build/make) ertzing > gauche-0.8.13-1.fc9 [u'449627 ASSIGNED'] (build/make) gemi > gcl-2.6.7-18.fc9 [u'440913 ASSIGNED'] (build/make) gemi,green > gdmap-0.7.5-6.fc6 [u'434529 ASSIGNED'] (build/make) splinux > gpsim-0.22.0-5.fc8 [u'434061 ASSIGNED'] (build/make) dionysos > gstm-1.2-6.fc7 [u'434531 ASSIGNED'] (build/make) splinux > gtk-sharp-1.0.10-12.fc7 [u'434373 ASSIGNED'] (unpackaged_files/python-egg-info?) pfj > guile-gnome-platform-2.15.93-6.fc8 [u'434289 ASSIGNED'] (build/make) laxathom > g-wrap-1.9.9-5.fc9 [u'434278 ASSIGNED'] (patch_fuzz) laxathom > HelixPlayer-1.0.9-4.fc10 [u'449474 ASSIGNED'] (patch_fuzz) abompard > ht2html-2.0-5.fc6 [u'440916 ASSIGNED'] (build/make) ifoox > itpp-4.0.0-2.fc9 [u'434076 ASSIGNED'] (build/make) edhill > jabbin-2.0-0.6.beta2a.fc9 [u'440730 ASSIGNED'] (build/make) > jgroups-2.2.9.2-3jpp.2 [u'434352 ASSIGNED'] (build/make) dbhole > kdebluetooth-1.0-0.41.beta8.fc9 [u'449604 ASSIGNED'] (build/make) gilboa,scop > ladspa-1.12-9.fc9 [u'449542 ASSIGNED'] (build/make) thomasvs > libdap-3.7.10-2.fc9 [u'434366 ASSIGNED'] (build/make) pertusus > libFoundation-1.1.3-11.fc9 [u'440564 ASSIGNED'] (build/make) athimm > libfwbuilder-2.1.16-2.fc9 [u'449591 ASSIGNED'] (build/make) ertzing > libnc-dap-3.7.0-9.fc9 [u'434367 ASSIGNED'] (build/make) pertusus > libopensync-0.36-2.fc9 [u'449510 ASSIGNED'] (build/make) awjb > libzzub-0.2.3-12.fc9 [u'449661 ASSIGNED'] (patch_fuzz) akahl,mtasaka > lilypond-2.10.33-1.fc8 [u'434394 ASSIGNED'] (build/make) limb > lineakd-0.9-5.fc6 [u'434523 ASSIGNED'] (build/make) xris > lineak-defaultplugin-0.9-2.fc6 [u'434520 ASSIGNED'] (build/make) xris > lineak-xosdplugin-0.9-2.fc6 [u'434522 ASSIGNED'] (build/make) xris > linpsk-0.9-3.fc9 [u'440778 ASSIGNED'] (build/make) bjensen,sindrepb,sconklin > linux-atm-2.5.0-5 [u'434069 ASSIGNED', u'449613 ASSIGNED'] (build/make) dwmw2 > lostirc-0.4.6-3.fc8 [u'440921 ASSIGNED'] (build/make) splinux,splinux > lrmi-0.10-4.fc9 [u'449509 ASSIGNED'] (build/make) pwouters > mimetic-0.9.3-2.fc8 [u'434086 ASSIGNED'] (build/make) ensc > mod_suphp-0.6.3-1.fc9 [u'449578 ASSIGNED'] (build/make) ixs > monodevelop-0.19-6.fc9 [u'449441 ASSIGNED'] (build/make) pfj > mosml-2.01-11.fc9 [u'449445 ASSIGNED'] (build/make) gemi > moto4lin-0.3-6.fc7 [u'434135 ASSIGNED'] (build/make) jafo > muine-scrobbler-0.1.8-5.fc9 [u'449482 ASSIGNED'] (build/make) sindrepb > mx-2.0.6-3 [u'434325 ASSIGNED'] (unpackaged_files/python-egg-info?) misa > mysql-gui-tools-5.0r12-8.fc9 [u'440734 ASSIGNED', u'433987 ASSIGNED'] (patch_fuzz) ausil > I'm not maintainer of this package, but mysql-gui-tools is interesting for me. I think I can fix it soon. From smooge at gmail.com Sun Sep 7 13:30:51 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 7 Sep 2008 07:30:51 -0600 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <48C3B67E.6090301@gmail.com> References: <48C3B67E.6090301@gmail.com> Message-ID: <80d7e4090809070630n6ea5d09btce947009634eabf4@mail.gmail.com> On Sun, Sep 7, 2008 at 5:09 AM, Lyos Gemini Norezel wrote: > It's come to my attention lately that Fedora has, essensially, become 'to > big for it's britches' (as you old farts like to say). > I think the time has come for Fedora to be split up into subgroups: > What is too big for one's britches? That it doesn't fit on one cd? That there is other code than that shipped on the DVD? > To some extent, these groups already exist, but they are not/cannot be > complete until the distribution is behind each one. > > I know many will knock this idea as "hard to maintain", but... is it really? > > The infrastructure will be difficult to setup, but once done, should be a > breeze to maintain. > Especially since everyone here already focuses on their ideal use case > anyway. Are you volunteering to help solve this problem with actual code and showing how developer workflow will happen? Especially when package A is needed by package B which is in X-01 sub-distro but not in X-02 because it doesn't fit the definition of X-02. Or when package A in X-01 has been upgraded and your program in B doesn't work anymore because it needed A-01 and the maintainer is no longer doing that... and you don't find out until release time. To be honest, anyone who says infrastructure should be a breeze to maintain... has to define breeze... I have yet to see a build infrastructure anywhere that is a 'breeze'... too many frickin' corner cases. > > Maybe it's just me, but I think it's time Fedora stops trying to become > another Debian, and starts catering to the groups that comprise it. > > What do ya'll think? > > Lyos Gemini Norezel > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From markg85 at gmail.com Sun Sep 7 13:35:34 2008 From: markg85 at gmail.com (Mark) Date: Sun, 7 Sep 2008 15:35:34 +0200 Subject: Boot speedup with readahead In-Reply-To: <20080906212125.27b9b3bb@infradead.org> References: <20080906212125.27b9b3bb@infradead.org> Message-ID: <6e24a8e80809070635j3c753697nffc465c64a6d014a@mail.gmail.com> On Sun, Sep 7, 2008 at 6:21 AM, Arjan van de Ven wrote: > On Sat, 06 Sep 2008 12:52:56 +0200 > Harald Hoyer wrote: > >> Hello fellow Fedora developers, >> >> recently readahead was modified to adapt to system file changes and >> to start very early in the boot process via upstart. >> >> I would like to encourage you to test readahead-1.4.5-3.fc10 from >> rawhide (even possible on F9), which I built some minutes ago. It may >> take a day to reach your local mirror. >> >> # yum --enablerepo=rawhide install readahead >> or >> # yum --enablerepo=rawhide update readahead >> >> With the next reboot readahead-collector runs and collects the >> information which files are used during the boot process. The next >> reboot then, readahead read ahead those files and the boot process >> (from init start to gdm login screen) should be approx. 10% faster. >> > > for those who are going to the plumbers conference... Auke Kok and I > will present there on how to make a Fedora based system boot in 5 > seconds... > > and yes a form of readahead was needed to achieve that ;-) > > > -- > If you want to reach me at my work email, use arjan at linux.intel.com > For development, discussion and tips for power savings, > visit http://www.lesswatts.org > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Please!! make a video of that and full documentation on how to get that done! i'm gona try that out as well when there are docs on how to do it. I sure hope your right in a 5 second boot. I hope it's still with: - Grub (or grub 2) - that new rhgb replacement - gdm/kdm/slim/xdm Or do you make somekind of a boot dump and start that the next time you boot? More info please! this is interesting. From ville.skytta at iki.fi Sun Sep 7 13:38:53 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 7 Sep 2008 16:38:53 +0300 Subject: Boot speedup with readahead In-Reply-To: <4c4ba1530809061203t2ca06046k6e847659258174ee@mail.gmail.com> References: <4c4ba1530809061203t2ca06046k6e847659258174ee@mail.gmail.com> Message-ID: <200809071638.54199.ville.skytta@iki.fi> Good stuff. I see slightly more than 10% speedup with this on F-9 from end of grub to until the KDE splash screen disappears. Ditto to until all apps that I have on autostart after a small modification. The modifications I made to /etc/event.d/readahead-collector.event were commenting out the [ -f /.autorelabel ] test (no selinux here) as well as increasing the sleep time in pre-stop script to 50 so that all the apps I have on autostart get collected. From stlwrt at gmail.com Sun Sep 7 13:43:01 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Sun, 7 Sep 2008 16:43:01 +0300 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <48C3D2A2.2050904@ru.bir.ru> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <48C3D2A2.2050904@ru.bir.ru> Message-ID: On Sun, Sep 7, 2008 at 4:09 PM, forum wrote: > Matt Domsch ?????: >> >> The following 90 packages have had FTBFS (Fails to Build From Source) >> failures for several months, some as far back as February 2008. >> >> There are several "trivial" failures which could be addressed easily. >> 8 fail due to unpackaged files >> 6 fail due to patch fuzz >> 1 fails due to open() not passing a mode. >> >> http://fedoraproject.org/wiki/FTBFS describes the FTBFS process. >> >> As was proposed to FESCO, packages with unresolved FTBFS bugs >> immediately following the Alpha release will be removed from the >> distribution. Package owners may request that their package _not_ be >> removed provided they are actively working on resolving the FTBFS and >> have a plan to resolve the FTBFS before the Release Candidate >> release. FESCo has the final say of course, but these are the items >> on my candidate list. I'd prefer packages get fixed rather than >> removed. If you are the package owner, or are interested in the >> future of these packages, please investigate these build failures and >> fix them ASAP. >> >> aiksaurus-1.2.1-15.fc6 [u'434484 ASSIGNED'] (build/make) uwog >> astyle-1.21-6.fc8 [u'433971 ASSIGNED'] (build/make) addutko,mtasaka >> aterm-1.0.1-2.fc9 [u'440779 ASSIGNED'] (build/make) awjb >> bes-3.5.3-3.fc9 [u'434360 ASSIGNED'] (build/make) pertusus >> bitbake-1.8.8-1.fc8 [u'440562 ASSIGNED'] (build/make) ixs >> bmpx-0.40.14-5.fc9 [u'449431 ASSIGNED'] (patch_fuzz) akahl >> brltty-3.9-2.2.fc9 [u'449446 ASSIGNED'] (build/make) kasal >> brutus-keyring-0.9.0-6.fc8 [u'434007 ASSIGNED'] (build/make) >> bpepple,colding >> camstream-0.26.3-12.fc8 [u'434345 ASSIGNED'] (build/make) nomis80 >> coolkey-1.1.0-6.fc9 [u'440753 ASSIGNED'] (build/make) rrelyea,jmagne >> dap-freeform_handler-3.7.7-2.fc9 [u'434362 ASSIGNED'] (build/make) >> pertusus >> dap-hdf4_handler-3.7.7-3.fc9 [u'434363 ASSIGNED'] (build/make) pertusus >> djvulibre-3.5.20-2.fc9 [u'440910 ASSIGNED'] (build/make) thias >> elektra-0.6.10-6.fc9 [u'434364 ASSIGNED'] (build/make) pertusus,kwizart >> erlang-R12B-3.1.fc10 [u'449432 ASSIGNED'] (patch_fuzz) gemi >> fish-1.23.0-2.fc9 [u'440724 ASSIGNED'] (build/make) ascii,oliver >> fluxstyle-1.0.1-2.fc7 [u'440757 ASSIGNED'] (build/make) errr >> fonttools-2.0-0.11.20060223cvs.fc7 [u'434409 ASSIGNED'] >> (unpackaged_files/python-egg-info?) roozbeh,fonts-sig >> fontypython-0.2.0-6.fc7 [u'440756 ASSIGNED'] (build/make) >> cr33dog,fonts-sig >> fwbuilder-2.1.16-2.fc9 [u'440846 ASSIGNED'] (build/make) ertzing >> gauche-0.8.13-1.fc9 [u'449627 ASSIGNED'] (build/make) gemi >> gcl-2.6.7-18.fc9 [u'440913 ASSIGNED'] (build/make) gemi,green >> gdmap-0.7.5-6.fc6 [u'434529 ASSIGNED'] (build/make) splinux >> gpsim-0.22.0-5.fc8 [u'434061 ASSIGNED'] (build/make) dionysos >> gstm-1.2-6.fc7 [u'434531 ASSIGNED'] (build/make) splinux >> gtk-sharp-1.0.10-12.fc7 [u'434373 ASSIGNED'] >> (unpackaged_files/python-egg-info?) pfj >> guile-gnome-platform-2.15.93-6.fc8 [u'434289 ASSIGNED'] (build/make) >> laxathom >> g-wrap-1.9.9-5.fc9 [u'434278 ASSIGNED'] (patch_fuzz) laxathom >> HelixPlayer-1.0.9-4.fc10 [u'449474 ASSIGNED'] (patch_fuzz) abompard >> ht2html-2.0-5.fc6 [u'440916 ASSIGNED'] (build/make) ifoox >> itpp-4.0.0-2.fc9 [u'434076 ASSIGNED'] (build/make) edhill >> jabbin-2.0-0.6.beta2a.fc9 [u'440730 ASSIGNED'] (build/make) >> jgroups-2.2.9.2-3jpp.2 [u'434352 ASSIGNED'] (build/make) dbhole >> kdebluetooth-1.0-0.41.beta8.fc9 [u'449604 ASSIGNED'] (build/make) >> gilboa,scop >> ladspa-1.12-9.fc9 [u'449542 ASSIGNED'] (build/make) thomasvs >> libdap-3.7.10-2.fc9 [u'434366 ASSIGNED'] (build/make) pertusus >> libFoundation-1.1.3-11.fc9 [u'440564 ASSIGNED'] (build/make) athimm >> libfwbuilder-2.1.16-2.fc9 [u'449591 ASSIGNED'] (build/make) ertzing >> libnc-dap-3.7.0-9.fc9 [u'434367 ASSIGNED'] (build/make) pertusus >> libopensync-0.36-2.fc9 [u'449510 ASSIGNED'] (build/make) awjb >> libzzub-0.2.3-12.fc9 [u'449661 ASSIGNED'] (patch_fuzz) akahl,mtasaka >> lilypond-2.10.33-1.fc8 [u'434394 ASSIGNED'] (build/make) limb >> lineakd-0.9-5.fc6 [u'434523 ASSIGNED'] (build/make) xris >> lineak-defaultplugin-0.9-2.fc6 [u'434520 ASSIGNED'] (build/make) xris >> lineak-xosdplugin-0.9-2.fc6 [u'434522 ASSIGNED'] (build/make) xris >> linpsk-0.9-3.fc9 [u'440778 ASSIGNED'] (build/make) >> bjensen,sindrepb,sconklin >> linux-atm-2.5.0-5 [u'434069 ASSIGNED', u'449613 ASSIGNED'] (build/make) >> dwmw2 >> lostirc-0.4.6-3.fc8 [u'440921 ASSIGNED'] (build/make) splinux,splinux >> lrmi-0.10-4.fc9 [u'449509 ASSIGNED'] (build/make) pwouters >> mimetic-0.9.3-2.fc8 [u'434086 ASSIGNED'] (build/make) ensc >> mod_suphp-0.6.3-1.fc9 [u'449578 ASSIGNED'] (build/make) ixs >> monodevelop-0.19-6.fc9 [u'449441 ASSIGNED'] (build/make) pfj >> mosml-2.01-11.fc9 [u'449445 ASSIGNED'] (build/make) gemi >> moto4lin-0.3-6.fc7 [u'434135 ASSIGNED'] (build/make) jafo >> muine-scrobbler-0.1.8-5.fc9 [u'449482 ASSIGNED'] (build/make) sindrepb >> mx-2.0.6-3 [u'434325 ASSIGNED'] (unpackaged_files/python-egg-info?) misa >> mysql-gui-tools-5.0r12-8.fc9 [u'440734 ASSIGNED', u'433987 ASSIGNED'] >> (patch_fuzz) ausil >> > > I'm not maintainer of this package, but mysql-gui-tools is interesting for > me. > I think I can fix it soon. I fixed shellbang patch fuzzyness - http://attic.scwlab.com/mysql-administrator-spawn_fetches.patch But now it fails because of GTK API change =( > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From harald at redhat.com Sun Sep 7 13:46:09 2008 From: harald at redhat.com (Harald Hoyer) Date: Sun, 07 Sep 2008 15:46:09 +0200 Subject: Boot speedup with readahead In-Reply-To: <20080907124135.9qcpb7jgp0oos408@mail.rimini.com> References: <20080907124135.9qcpb7jgp0oos408@mail.rimini.com> Message-ID: <48C3DB21.1090307@redhat.com> Davide Moretti schrieb: > On my system: > > Without readahead: 1 minute and 30 seconds > With readahead: 1 minute and 30 seconds > > Time was until gnome applet showed up, so on my system readahead did not > improve boot speed at all. > > Note that there is a bug that prevents readahead-collector from starting > if you have selinux disabled, since the /.autorelabel file is still > hanging around during reboots, I had to remove this file for collector > to work. > > 1) The rhgb removal is a big step forwards, rhgb slows down things a lot. > 2) One major thing to look at I think is the initrd and udev, these take > really a lot of time > 3) Get rid of that sysinit stuff and start using upstart jobs, I still > have not seen any progress on this. > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > Can you provide a bootchart for your system? Best would be 2, one with and one without readahead From michel.sylvan at gmail.com Sun Sep 7 13:51:21 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 7 Sep 2008 09:51:21 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <48C39E01.3060802@ioa.s.u-tokyo.ac.jp> References: <48C39E01.3060802@ioa.s.u-tokyo.ac.jp> Message-ID: On Sun, Sep 7, 2008 at 5:25 AM, Mamoru Tasaka wrote: > Michel Salim wrote, at 09/07/2008 03:57 PM +9:00: >> >> I was just over at gnu.org to download the anniversary video recorded >> by Stephen Fry, and while I was there decided to take a look at what >> systems they recommend as being free. >> >> They list BLAG, which is based on Fedora. But Fedora itself (and >> Debian) is not there! >> >> http://www.gnu.org/links/links.html#FreeGNULinuxDistributions >> >> This struck me as rather strange, especially considering their >> guidelines are actually based on Fedora's (and we are thanked for it): >> http://www.gnu.org/philosophy/free-system-distribution-guidelines.html >> >> As far as I remember, Rahul Sundaram was talking to the GNU / FSF >> people about this quite a while back. Is it just the difference over >> binary-only firmware that's consigning us to the "non-free" heap? > > I cannot do any legal comment here, however I just want to say that > I don't want to see the nightmare which happened on fedora-list any more. > > https://www.redhat.com/archives/fedora-list/2008-July/thread.html#01481 > Apologies; I stopped reading fedora-list due to the volume, but I ought to have checked it first. Just two things: 1. If Fedora ships a firmware blob-free alternative kernel, someone could create an official Fedora spin that's good enough for RMS 2. Should we perhaps link to MarkMail from the mailing list archives site? Regards, -- Michel Salim http://hircus.jaiku.com/ From bruno at wolff.to Sun Sep 7 14:48:13 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 7 Sep 2008 09:48:13 -0500 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <48C3B67E.6090301@gmail.com> References: <48C3B67E.6090301@gmail.com> Message-ID: <20080907144813.GC32537@wolff.to> On Sun, Sep 07, 2008 at 07:09:50 -0400, Lyos Gemini Norezel wrote: > > What do ya'll think? This really is what spins are for. By having one distribution the software should all work together (in theory at least) making it easy to make new spins with little effort. From dtimms at iinet.net.au Sun Sep 7 14:49:34 2008 From: dtimms at iinet.net.au (David Timms) Date: Mon, 08 Sep 2008 00:49:34 +1000 Subject: Fedora 10 Beta Freeze - new packages into rawhide ? In-Reply-To: <1220392329.30380.14.camel@luminos.localdomain> References: <1218474175.3398.46.camel@localhost.localdomain> <1220392329.30380.14.camel@luminos.localdomain> Message-ID: <48C3E9FE.7030908@iinet.net.au> Jesse Keating wrote: > On Mon, 2008-08-11 at 13:02 -0400, Jesse Keating wrote: >> >> Beta freeze also marks the Feature freeze, so it is very important that >> you get your features into working, testable shape by then, or be >> prepared to try your feature again for Fedora 11. >> ... > > We moved our freeze date to reflect the situation. The new freeze date > is Sept. 9, which is in 7 days. This is a friendly reminder that the > freeze is coming up, and coming up quickly. > Just wondering whether a recently reviewed package {pyvnc2swf} can make the beta cut ? I couldn't find a good definition of whether it is outright rejected once alpha has passed ? If it is OK, what does a maintainer need to do to make it happen ? {I also used bodhi to add as new package update for f8,f9 hope that makes sense}. DaveT. From michel.sylvan at gmail.com Sun Sep 7 15:20:26 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 7 Sep 2008 11:20:26 -0400 Subject: NetworkManager-pptp In-Reply-To: <16de708d0809062136x70e63749r12390c2c62aea82d@mail.gmail.com> References: <9497e9990808300831t150c6036ydf4c453f3c822d48@mail.gmail.com> <1220364295.3176.19.camel@borkbork.foobar.com> <9497e9990809020820m67361762n7ed5db1bf7ad7946@mail.gmail.com> <1220369215.8041.15.camel@borkbork.foobar.com> <9497e9990809021520q6458cd39u3ff17f0144c8c5b6@mail.gmail.com> <1220473096.28633.5.camel@borkbork.foobar.com> <48BF01EC.5000107@hi.is> <16de708d0809062136x70e63749r12390c2c62aea82d@mail.gmail.com> Message-ID: 2008/9/7 Arthur Pemberton : > I tried to connect using NetworkManager and failed at about 18:13. > At 18:18 I tried pptp-client and succeeded. > At 18:29 I tried NetworkManager again, this time with MPPE on (which > I had forgotten the first time) and failed > > I have attached the relevant portions of /var/log/messages > Is there a bugzilla tracker for this? Might be a better option, especially once you start using attachments. Regards, -- Michel Salim http://hircus.jaiku.com/ From markg85 at gmail.com Sun Sep 7 15:24:15 2008 From: markg85 at gmail.com (Mark) Date: Sun, 7 Sep 2008 17:24:15 +0200 Subject: Boot speedup with readahead In-Reply-To: <48C3DB21.1090307@redhat.com> References: <20080907124135.9qcpb7jgp0oos408@mail.rimini.com> <48C3DB21.1090307@redhat.com> Message-ID: <6e24a8e80809070824m5ad1c4dfye7fc6065d0cc4063@mail.gmail.com> On Sun, Sep 7, 2008 at 3:46 PM, Harald Hoyer wrote: > Davide Moretti schrieb: >> >> On my system: >> >> Without readahead: 1 minute and 30 seconds >> With readahead: 1 minute and 30 seconds >> >> Time was until gnome applet showed up, so on my system readahead did not >> improve boot speed at all. >> >> Note that there is a bug that prevents readahead-collector from starting >> if you have selinux disabled, since the /.autorelabel file is still hanging >> around during reboots, I had to remove this file for collector to work. >> >> 1) The rhgb removal is a big step forwards, rhgb slows down things a lot. >> 2) One major thing to look at I think is the initrd and udev, these take >> really a lot of time >> 3) Get rid of that sysinit stuff and start using upstart jobs, I still >> have not seen any progress on this. >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> > > Can you provide a bootchart for your system? > Best would be 2, one with and one without readahead > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Incase anyone is interested now in building a custom fedora kernel but doesn't know where to start (like me a few minutes ago): http://fedoraproject.org/wiki/Docs/CustomKernel That provides all the info to customize that kernel of yours. But i do suspect that more customizing is required to get it boot in 5 seconds. probably requires adjusting the initrd image as well. From lsof at nodata.co.uk Sun Sep 7 16:05:13 2008 From: lsof at nodata.co.uk (nodata) Date: Sun, 07 Sep 2008 18:05:13 +0200 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <48C3B67E.6090301@gmail.com> References: <48C3B67E.6090301@gmail.com> Message-ID: <1220803513.3099.7.camel@sb-home> Am Sonntag, den 07.09.2008, 07:09 -0400 schrieb Lyos Gemini Norezel: > It's come to my attention lately that Fedora has, essensially, become > 'to big for it's britches' (as you old farts like to say). > I think the time has come for Fedora to be split up into subgroups: > > For mainstream (ie., 'idiot') users Not helpful. From kevin at scrye.com Sun Sep 7 16:29:17 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Sun, 7 Sep 2008 10:29:17 -0600 Subject: Why I'll leave fedora (french speaking people only) [1] In-Reply-To: <200809070135.54996.alain.portal@free.fr> References: <200809070135.54996.alain.portal@free.fr> Message-ID: <20080907102917.210a5b6f@ohm.scrye.com> On Sun, 7 Sep 2008 01:35:54 +0200 alain.portal at free.fr (Alain PORTAL) wrote: > Pfff... > > https://bugzilla.redhat.com/show_bug.cgi?id=455277#c8 I have commented in the bug with info on how to solve your key issues and offered to try and mediate (or find someone who speaks french) who can do so. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From kevin at scrye.com Sun Sep 7 16:32:35 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Sun, 7 Sep 2008 10:32:35 -0600 Subject: Why I'll leave fedora (french speaking people only) [1] In-Reply-To: <48C3ABE6.7040909@gmail.com> References: <200809070135.54996.alain.portal@free.fr> <48C337DA.2050009@gmail.com> <1220754913.17785.105.camel@rosebud> <48C3ABE6.7040909@gmail.com> Message-ID: <20080907103235.194c5a66@ohm.scrye.com> On Sun, 07 Sep 2008 06:24:38 -0400 lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) wrote: > Vasile Gaburici wrote: > > > > I his bugzilla message he is complaining (amongst other things) that > > FESCO did not consider the matter. > > > > I, too, noticed this. I forgot to mention it in my previous message... > but I wanted to ask: > > Was this issue ever raised in a FESCo meeting? Which issue? I know Alain's problems with some of the fedora french community have been discussed. > Was this issue ever put on the discussion agenda? Not that I can recall, although again, it depends on which issue you are talking about here. > One thing many people do not understand... is that any > (comparatively) small governing body, is (by necessity) going to be > swamped by issues. I/We may not like it > (I despise bureaucracy in all it's forms)... but it's a fact of life. Sure, this is one reason I wanted to setup the trac instance to track issues that need FESCo input. > If he did do either of the above... then I can share his outrage. > Otherwise... *shrug*... you can't help those who refuse to help > themselves. I think there are communications problems going on here. It doesn't help that many of the people looking at this do not speak french and thus may be misunderstanding Alain. > Just my thoughts/opinions. > Lyos Gemini Norezel kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From snecklifter at gmail.com Sun Sep 7 17:13:48 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Sun, 7 Sep 2008 18:13:48 +0100 Subject: Fedora not "free" enough for GNU? In-Reply-To: References: <48C39E01.3060802@ioa.s.u-tokyo.ac.jp> Message-ID: <364d303b0809071013q433b9d5n1bbfb8c1c8c90e1c@mail.gmail.com> 2008/9/7 Michel Salim : > On Sun, Sep 7, 2008 at 5:25 AM, Mamoru Tasaka > wrote: >> Michel Salim wrote, at 09/07/2008 03:57 PM +9:00: >>> >>> I was just over at gnu.org to download the anniversary video recorded >>> by Stephen Fry, and while I was there decided to take a look at what >>> systems they recommend as being free. >>> >>> They list BLAG, which is based on Fedora. But Fedora itself (and >>> Debian) is not there! >>> >>> http://www.gnu.org/links/links.html#FreeGNULinuxDistributions >>> >>> This struck me as rather strange, especially considering their >>> guidelines are actually based on Fedora's (and we are thanked for it): >>> http://www.gnu.org/philosophy/free-system-distribution-guidelines.html >>> >>> As far as I remember, Rahul Sundaram was talking to the GNU / FSF >>> people about this quite a while back. Is it just the difference over >>> binary-only firmware that's consigning us to the "non-free" heap? >> >> I cannot do any legal comment here, however I just want to say that >> I don't want to see the nightmare which happened on fedora-list any more. >> >> https://www.redhat.com/archives/fedora-list/2008-July/thread.html#01481 >> > Apologies; I stopped reading fedora-list due to the volume, but I > ought to have checked it first. > > Just two things: > 1. If Fedora ships a firmware blob-free alternative kernel, someone > could create an official Fedora spin that's good enough for RMS This thread might be of interest: https://www.redhat.com/archives/fedora-kernel-list/2008-August/msg00008.html and then if whoever really wants to remove the rest of the blobs (wireless, ALSA etc.) can do so, submit the finished spin to the FSF and hopefully put this one to bed once and for all. > 2. Should we perhaps link to MarkMail from the mailing list archives site? Not sure why this is relevant. Cheers -- Christopher Brown http://www.chruz.com From emmanuel.seyman at club-internet.fr Sun Sep 7 18:02:40 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Sun, 7 Sep 2008 20:02:40 +0200 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <1220803513.3099.7.camel@sb-home> References: <48C3B67E.6090301@gmail.com> <1220803513.3099.7.camel@sb-home> Message-ID: <20080907180240.GA1485@orient.maison.lan> * nodata [07/09/2008 18:29] : > > Am Sonntag, den 07.09.2008, 07:09 -0400 schrieb Lyos Gemini Norezel: > > > For mainstream (ie., 'idiot') users > > Not helpful. Agreed. Please stop calling people who want things to work out of the box idiots. They're not. Emmanuel From paul at all-the-johnsons.co.uk Sun Sep 7 18:31:45 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 07 Sep 2008 19:31:45 +0100 Subject: New mono SIG created Message-ID: <1220812305.17378.5.camel@PB3.Linux> Hi, If you are a user, packager or maintainer of any mono package, you may like to know that there is now a SIG devoted to Mono. https://fedoraproject.org/wiki/SIGs/Mono I'm not quite sure yet how to set up a mailing list (I think it would be really useful!) for it, but hey, it's early days yet! TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rjones at redhat.com Sun Sep 7 18:41:48 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Sun, 7 Sep 2008 19:41:48 +0100 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <48C3B67E.6090301@gmail.com> References: <48C3B67E.6090301@gmail.com> Message-ID: <20080907184148.GA3431@amd.home.annexia.org> On Sun, Sep 07, 2008 at 07:09:50AM -0400, Lyos Gemini Norezel wrote: > Maybe it's just me, but I think it's time Fedora stops trying to become > another Debian, and starts catering to the groups that comprise it. I just want to knock this silly idea on the head. In my opinion there should be no limits on how many packages get included in Fedora Everything[i], except two: (1) It should be Free software that complies with the guidelines and (2) Someone should be willing to put in the time to maintain it. Whenever there's a package which is missing, some user will say 'Oh but it's in Debian' (along with all that other stuff) so I might as well use Debian. Unfortunately the mix of packages is different for each user, so you have to have them all. Rich. [i] Packages which make it onto a CD/DVD/spin/mirrors is quite a different matter of course. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From jspaleta at gmail.com Sun Sep 7 18:50:36 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 7 Sep 2008 10:50:36 -0800 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <20080907180240.GA1485@orient.maison.lan> References: <48C3B67E.6090301@gmail.com> <1220803513.3099.7.camel@sb-home> <20080907180240.GA1485@orient.maison.lan> Message-ID: <604aa7910809071150g282e18e0p61e3db838072e973@mail.gmail.com> On Sun, Sep 7, 2008 at 10:02 AM, Emmanuel Seyman wrote: > Please stop calling people who want things to work out of the box idiots. > They're not. I'm a certified genius... and I'm officially speaking for the entire genius subculture when I say i/we (for we share a hive mind to some extent) like things to work when I/we take them out of the box. That way when I/we take then apart and try to put the back together I know whether or not I've succeeded in my goal by using the initial functionality as a baseline reference. -jef"Or do i mean certifiable"spaleta From kevin.kofler at chello.at Sun Sep 7 19:14:42 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 7 Sep 2008 19:14:42 +0000 (UTC) Subject: Proposed removal of packages with long-standing FTBFS failures References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <48C3D2A2.2050904@ru.bir.ru> Message-ID: Pavel Shevchuk gmail.com> writes: > I fixed shellbang patch fuzzyness - > http://attic.scwlab.com/mysql-administrator-spawn_fetches.patch > But now it fails because of GTK API change =( #undef GTK_DISABLE_DEPRECATED Kevin Kofler From igorsoares at gmail.com Sun Sep 7 19:24:51 2008 From: igorsoares at gmail.com (Igor Pires Soares) Date: Sun, 07 Sep 2008 16:24:51 -0300 Subject: smolt-firstboot dependencies Message-ID: <1220815491.5122.12.camel@amd5600> Hello! While spinning Rawhide I noticed that smolt-firstboot is picking mysql, TurboGears and many python stuff as dependencies. Is that normal? Regards, Igor Pires Soares From pemboa at gmail.com Sun Sep 7 19:23:21 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Sun, 7 Sep 2008 14:23:21 -0500 Subject: NetworkManager-pptp In-Reply-To: References: <9497e9990808300831t150c6036ydf4c453f3c822d48@mail.gmail.com> <1220364295.3176.19.camel@borkbork.foobar.com> <9497e9990809020820m67361762n7ed5db1bf7ad7946@mail.gmail.com> <1220369215.8041.15.camel@borkbork.foobar.com> <9497e9990809021520q6458cd39u3ff17f0144c8c5b6@mail.gmail.com> <1220473096.28633.5.camel@borkbork.foobar.com> <48BF01EC.5000107@hi.is> <16de708d0809062136x70e63749r12390c2c62aea82d@mail.gmail.com> Message-ID: <16de708d0809071223t29506837lf7bc4e1c2a9a7bbe@mail.gmail.com> On Sun, Sep 7, 2008 at 10:20 AM, Michel Salim wrote: > 2008/9/7 Arthur Pemberton : >> I tried to connect using NetworkManager and failed at about 18:13. >> At 18:18 I tried pptp-client and succeeded. >> At 18:29 I tried NetworkManager again, this time with MPPE on (which >> I had forgotten the first time) and failed >> >> I have attached the relevant portions of /var/log/messages >> > Is there a bugzilla tracker for this? Might be a better option, > especially once you start using attachments. > > Regards, Fair enough, I should have done so before: https://bugzilla.redhat.com/show_bug.cgi?id=461420 -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From jspaleta at gmail.com Sun Sep 7 19:23:37 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 7 Sep 2008 11:23:37 -0800 Subject: Why I'll leave fedora (french speaking people only) [1] In-Reply-To: <20080907103235.194c5a66@ohm.scrye.com> References: <200809070135.54996.alain.portal@free.fr> <48C337DA.2050009@gmail.com> <1220754913.17785.105.camel@rosebud> <48C3ABE6.7040909@gmail.com> <20080907103235.194c5a66@ohm.scrye.com> Message-ID: <604aa7910809071223j322fde86s8fc3221f3edcb081@mail.gmail.com> 2008/9/7 Kevin Fenzi : > I think there are communications problems going on here. > It doesn't help that many of the people looking at this do not speak > french and thus may be misunderstanding Alain. Setting aside the specific people and problems bubbling up right now. Would it make sense for the Board to try to take up the issue of some sort of established process to follow when there are language barriers getting in the way of normal dispute resolution? So we can try to get ahead this sort of situation when it happens again. I can imagine that this might be a place where our Ambassador pool can be called on to act as mediators/arbitration if the are willing to take on that role. -jef"If we'd all just agree to communicate strictly pythonicly we woudn't have a problem"spaleta From ben.kreuter at gmail.com Sun Sep 7 19:23:39 2008 From: ben.kreuter at gmail.com (Benjamin Kreuter) Date: Sun, 7 Sep 2008 15:23:39 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: References: <8553.1220772699@sss.pgh.pa.us> Message-ID: <200809071523.44582.ben.kreuter@gmail.com> On Sunday 07 September 2008 05:15:27 Gregory Maxwell wrote: > > The notion that firmware ought to be free isn't absurd: True, but the notion of non-free firmware is also not absurd, at least if you are willing to tolerate hardware makers refusing to publish circuit and logic diagrams for their hardware. It really boils down to a debate on whether or not firmware should be considered software, and I personally fall in the camp that does not consider firmware to be software, at least firmware in the form of FPGA/CPLD configurations. Additionally, freedom with firmware is a lot more restricted than freedom with software: firmware cannot be "ported" to other hardware, modifying firmware requires a lot more expertise than modifying software, etc. I usually agree with the FSF on these matters, but firmware is where I part ways with them. -- Ben -- Message sent on: Sun Sep 7 15:16:04 EDT 2008 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From kevin.kofler at chello.at Sun Sep 7 19:39:11 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 7 Sep 2008 19:39:11 +0000 (UTC) Subject: Proposed removal of packages with long-standing FTBFS failures References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <200809061443.52683.alain.portal@free.fr> Message-ID: Vasile Gaburici gmail.com> writes: > I've uploaded a patch for this on the bug page. I committed and built it. The package will probably need a new maintainer though, unless you can convince Alain Portal not to leave. Kevin Kofler From jspaleta at gmail.com Sun Sep 7 19:40:46 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 7 Sep 2008 11:40:46 -0800 Subject: Fedora not "free" enough for GNU? In-Reply-To: <200809071523.44582.ben.kreuter@gmail.com> References: <8553.1220772699@sss.pgh.pa.us> <200809071523.44582.ben.kreuter@gmail.com> Message-ID: <604aa7910809071240u1923df65i8861e58de856540b@mail.gmail.com> 2008/9/7 Benjamin Kreuter : > I usually agree with the FSF on these matters, but firmware is where I part > ways with them. And you know what... that's absolutely OKAY. We aren't going to get much accomplished by getting stuck in a debate over the ethical or moral necessity of this. The only question that matters right now is this... Do we want people who feel they must make a personal choice to avoid using closed firmware the ability to use Fedora? If so are we as a project making progress to see that that happens by working with upstream kernel developers to make that possible without adding gobs of Fedora specific kernel patches? All we can do is do our best to make progress on this in a way that does not sacrifice our own core project ideals. What we first and foremost is a conduit between users and upstream development. We must continue to endeavor to see that the changes that we desire or champion get into the upstream development. Is progress being made? The fedora-kernel-list discussions seems to indicate that we are on the right track. The proponents for a blob-less kernel might not be happy with the pace...but it seems to be we are trying to be responsive in a way that makes sense from our project's point of view. It seems to me we have a way forward and its just a matter of getting people to agree to take each step on the path. -jef"but what the hell do i know anyways"spaleta From aph at redhat.com Sun Sep 7 19:54:35 2008 From: aph at redhat.com (Andrew Haley) Date: Sun, 07 Sep 2008 20:54:35 +0100 Subject: Fedora not "free" enough for GNU? In-Reply-To: References: <8553.1220772699@sss.pgh.pa.us> Message-ID: <48C4317B.9050203@redhat.com> Gregory Maxwell wrote: > The notion that firmware ought to be free isn't absurd: It doesn't > take much effort to find examples of firmware imposing unreasonable > limits on users, or firmware containing nasty hidden security bugs. Just to get away from the ethics flame^H^H^H^H^Hdiscussion for a moment... This makes me think of a really interesting question: security- critical organizations presumably have to make use of commercially available computers just like the rest of us. Someone somewhere must have thought about the issues of binary firmware blobs for video and network hardware and their potential to leak data, either deliberately or accidentally. One of the many nice things about free software is the fact that it's reasonably easy to inspect it for security analysis; binary blobs weaken that. Andrew. From lesmikesell at gmail.com Sun Sep 7 19:56:29 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 07 Sep 2008 14:56:29 -0500 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <80d7e4090809070630n6ea5d09btce947009634eabf4@mail.gmail.com> References: <48C3B67E.6090301@gmail.com> <80d7e4090809070630n6ea5d09btce947009634eabf4@mail.gmail.com> Message-ID: <48C431ED.1020905@gmail.com> Stephen John Smoogen wrote: > > To be honest, anyone who says infrastructure should be a breeze to > maintain... has to define breeze... Is the FHS spec - or compliance - ever going to reach a point where it is possible to have distribution-agnostic packages? Or even source builds that completely integrate with the packaged components - so every little program doesn't need special maintenance and different copies for every distro/version before their users can run it? > I have yet to see a build > infrastructure anywhere that is a 'breeze'... too many frickin' corner > cases. That probably can't be completely eliminated for things that require version-specific features to work at all, but there must be some way to reduce the number of corners for things that just need standard services. It doesn't make any sense to require human intervention to fix things to work because of differences on an OS that is supposed to be presenting a standard interface. Rather than splintering the distributions to accommodate and create even more differences, shouldn't the effort go towards making that less necessary? -- Les Mikesell lesmikesell at gmail.com From tibbs at math.uh.edu Sun Sep 7 19:48:05 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Sep 2008 14:48:05 -0500 Subject: smolt-firstboot dependencies In-Reply-To: <1220815491.5122.12.camel@amd5600> References: <1220815491.5122.12.camel@amd5600> Message-ID: >>>>> "IPS" == Igor Pires Soares writes: IPS> Hello! While spinning Rawhide I noticed that smolt-firstboot is IPS> picking mysql, TurboGears and many python stuff as IPS> dependencies. Is that normal? Looks like smolt-firstboot requires python-turboflot, which pulls in TurboGears, which has loads of python dependencies which ends up sucking in the mysql and postgresql client libraries and a tonne of other stuff. - J< From lyos.gemininorezel at gmail.com Sun Sep 7 19:56:50 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Sun, 07 Sep 2008 15:56:50 -0400 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <20080907180240.GA1485@orient.maison.lan> References: <48C3B67E.6090301@gmail.com> <1220803513.3099.7.camel@sb-home> <20080907180240.GA1485@orient.maison.lan> Message-ID: <48C43202.6050600@gmail.com> Emmanuel Seyman wrote: > * nodata [07/09/2008 18:29] : > >> Am Sonntag, den 07.09.2008, 07:09 -0400 schrieb Lyos Gemini Norezel: >> >> Not helpful. >> > > Agreed. > > Please stop calling people who want things to work out of the box idiots. > They're not. > > Emmanuel > Look... regardless of your opinion... the majority of 'users' are idiots. Whether willfully ignorant or just plain stupid... these people comprise nearly 90% of the human race. This just makes those of us who do care enough to use linux (or code for linux), somewhat special (or insane)... no? Lyos Gemini Norezel From lyos.gemininorezel at gmail.com Sun Sep 7 19:56:58 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Sun, 07 Sep 2008 15:56:58 -0400 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <80d7e4090809070630n6ea5d09btce947009634eabf4@mail.gmail.com> References: <48C3B67E.6090301@gmail.com> <80d7e4090809070630n6ea5d09btce947009634eabf4@mail.gmail.com> Message-ID: <48C4320A.4080800@gmail.com> Stephen John Smoogen wrote: > On Sun, Sep 7, 2008 at 5:09 AM, Lyos Gemini Norezel > wrote: >> What is too big for one's britches? That it doesn't fit on one cd? >> That there is other code than that shipped on the DVD? > Are you volunteering to help solve this problem with actual code and > showing how developer workflow will happen? I'm no coder... but I'd certainly be willing to do what I can to help. Lyos Gemini Norezel From lyos.gemininorezel at gmail.com Sun Sep 7 19:57:07 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Sun, 07 Sep 2008 15:57:07 -0400 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <604aa7910809071150g282e18e0p61e3db838072e973@mail.gmail.com> References: <48C3B67E.6090301@gmail.com> <1220803513.3099.7.camel@sb-home> <20080907180240.GA1485@orient.maison.lan> <604aa7910809071150g282e18e0p61e3db838072e973@mail.gmail.com> Message-ID: <48C43213.5020906@gmail.com> Jeff Spaleta wrote: > I'm a certified genius... You're not the only one. > and I'm officially speaking for the entire > genius subculture when I say i/we (for we share a hive mind to some > extent) like things to work when I/we take them out of the box. Sure... until we wish to tinker. I've built thousands of computers (both personal and business)... I love putting things together to make them work. I cannot count the number of times I've taken a rubbish bin of old computers... and made a dozen or more fully working computers, or the times I've taken ancient, nearly unknown cards... and managed to get them to work on one computer or another. So, while having things "Just Work" is nice... you should know that, nothing beats the thrill of making something new (or old) work again. > -jef"Or do i mean certifiable"spaleta I think you mean Certifiably Insane... since the vast majority of Geniuses in the world (past or present) have been/are clinically insane. Lyos"loves being insane"Norezel ;-) From markg85 at gmail.com Sun Sep 7 20:04:46 2008 From: markg85 at gmail.com (Mark) Date: Sun, 7 Sep 2008 22:04:46 +0200 Subject: smolt-firstboot dependencies In-Reply-To: References: <1220815491.5122.12.camel@amd5600> Message-ID: <6e24a8e80809071304l5d3b124s67890f45886d88bf@mail.gmail.com> On Sun, Sep 7, 2008 at 9:48 PM, Jason L Tibbitts III wrote: >>>>>> "IPS" == Igor Pires Soares writes: > > IPS> Hello! While spinning Rawhide I noticed that smolt-firstboot is > IPS> picking mysql, TurboGears and many python stuff as > IPS> dependencies. Is that normal? > > Looks like smolt-firstboot requires python-turboflot, which pulls in > TurboGears, which has loads of python dependencies which ends up > sucking in the mysql and postgresql client libraries and a tonne of > other stuff. > > - J< > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > And all of that for just something you only see once.. Would be best if smolt-firstboot just didn't have any dependency's or only deps that are required by other must install (like python) apps as well From gnomeuser at gmail.com Sun Sep 7 20:06:00 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Sun, 7 Sep 2008 22:06:00 +0200 Subject: New mono SIG created In-Reply-To: <1220812305.17378.5.camel@PB3.Linux> References: <1220812305.17378.5.camel@PB3.Linux> Message-ID: <1dedbbfc0809071306j520a4021wc8f0bedb91b1c9a3@mail.gmail.com> Den 7. sep. 2008 20.31 skrev Paul : > Hi, > > If you are a user, packager or maintainer of any mono package, you may > like to know that there is now a SIG devoted to Mono. > > https://fedoraproject.org/wiki/SIGs/Mono > > I'm not quite sure yet how to set up a mailing list (I think it would be > really useful!) for it, but hey, it's early days yet! Things I would love to see us address: 1) Getting missing software into Fedora such as Monotorrent-dbus (will be needed for the next Banshee), Monsoon, Tasque and Giver 2) Finishing the reviews for the existing Mono packages like the md additional packages 3) Getting the debug stripper to understand Mono, currently we ship symbols in the main mono packages which bloats their size a bit 4) Bribing the PPC arch team to help us fix nant so our ppc users can have a full Mono stack. I can help with 1. I already have specs for a few of them for my own use. Let's get one step closer to the one true mono stack. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From tibbs at math.uh.edu Sun Sep 7 20:11:16 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 Sep 2008 15:11:16 -0500 Subject: smolt-firstboot dependencies In-Reply-To: <6e24a8e80809071304l5d3b124s67890f45886d88bf@mail.gmail.com> References: <1220815491.5122.12.camel@amd5600> <6e24a8e80809071304l5d3b124s67890f45886d88bf@mail.gmail.com> Message-ID: >>>>> "M" == Mark writes: M> And all of that for just something you only see once.. Would be M> best if smolt-firstboot just didn't have any dependency's or only M> deps that are required by other must install (like python) apps as M> well Well, it has to do things like talk over the web, so it's going to need some RPC libraries of some type. I think it is, however, obvious that the current dependency chain is excessive. Checking the specfile, I see the python-turboflot dependency came in with a change which was not changelogged (and did not include a release bump), so there's no information about why that dep was added. The next package change was a license tag change, which included a release bump and a build. It is possible that something snuck out which was not intentended. I'm sure more will be known tomorrow when those involved are back from the weekend. - J< From lyos.gemininorezel at gmail.com Sun Sep 7 20:12:36 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Sun, 07 Sep 2008 16:12:36 -0400 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: References: <48C3B67E.6090301@gmail.com> Message-ID: <48C435B4.6020403@gmail.com> Pavel Shevchuk wrote: > On Sun, Sep 7, 2008 at 2:09 PM, Lyos Gemini Norezel > wrote: > >> Fedora-Development - Generic development platform >> > > DVD has "Development" group with libs and headers and GCC and what not. > Sure... but why not have a distribution just for the developers? >> Fedora-Legacy - Everything older than a Pentium 3 (or, alternatively... all >> processors slower than ~1.0GHz). >> > > Join XFCE SIG, they create spin with lightweight software. > >> Fedora-Server - Server distribution... should include all tools necessary to >> setup various servers >> > > Again, DVD has "Server" group, and "Storage clustering" and "Virtualization"... > And again... why not create a distribution for Servers? >> Fedora-Live - All of the 'Live' distributions should go here... anything >> from LiveCDs to LiveUSB images. >> > > Desktop Media, KDE Media. They're also installable on USB > > So some of it's already there... >> This proposal is far from complete... but I think it is necessary to stop >> trying to be a 'everything and the kitchen sink' distribution... >> and instead focus more on the groups that use fedora. For instance, the >> majority of those on mainstream, are not going to need stuff >> like apache, perl, python, etc. >> > > Majority of mainstream can use live media. Making them choose between 10 installation media is pointless > Sure... the majority can use Live media... but unless that is listed as 'mainstream'... most of the average users coming over from the Micro$hit darkside may not understand which they should use. >> John Q Public wants to read his email, browse the web, watch porn/internet >> videos, etc... not write code, manage a server, or screw >> with a command line. >> > > Desktop Media! > Sure... but you have to be careful with 'John Q Public'... this group does not always understand what you wish they did. >> By the same token, a developer is not likely to use any gui tool that does >> not provide some extreme 'ease of use' case (be honest, >> how many of ya'll use vi or vim over gedit?). >> > > Desktop Media after one "yum install gcc eclipse..." > > > Ok... but again... why not have a distribution aim specifically at developers? >> To some extent, these groups already exist, but they are not/cannot be >> complete until the distribution is behind each one. >> The infrastructure will be difficult to setup, but once done, should be a >> breeze to maintain. >> > > You are welcome! =) Join team, contribute, maintain spins you think > are worth it I'm no coder (as I've mentioned before)... but I'm willing to help where I can. Lyos Gemini Norezel From peter at thecodergeek.com Sun Sep 7 20:14:41 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 07 Sep 2008 13:14:41 -0700 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <48C43213.5020906@gmail.com> References: <48C3B67E.6090301@gmail.com> <1220803513.3099.7.camel@sb-home> <20080907180240.GA1485@orient.maison.lan> <604aa7910809071150g282e18e0p61e3db838072e973@mail.gmail.com> <48C43213.5020906@gmail.com> Message-ID: <1220818481.13109.14.camel@tuxhugs> On Sun, 2008-09-07 at 15:57 -0400, Lyos Gemini Norezel wrote: > > and I'm officially speaking for the entire > > genius subculture when I say i/we (for we share a hive mind to some > > extent) like things to work when I/we take them out of the box. > > Sure... until we wish to tinker. [...] Please explicate this further. I, for one, love to tinker with my system; and Fedora's strictly-organized packaging makes this vastly simpler since I can just do similarly for my own things and know with near-absolute certainty that it won't harm my system. > > -jef"Or do i mean certifiable"spaleta > > I think you mean Certifiably Insane... since the vast majority of > Geniuses in the world (past or present) have been/are clinically insane. "Vast majority" and "All" are not logically equivalent. To put it differently: correlation does not imply causation. Just for fun, let's do this with a syllogism: If J (Jef) is a member of the set G (all geniuses), and G is a partial subset of C (that is, a vast majority of the elements in G are also in the set C - certifiably-insane people), then there is not enough information in this system to deductively infer that J is also a member of the set C. This is because J being a member of the set G only makes it *likely*, but not *certain*, that J is such. -- ?Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From peter at thecodergeek.com Sun Sep 7 20:19:18 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 07 Sep 2008 13:19:18 -0700 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <48C435B4.6020403@gmail.com> References: <48C3B67E.6090301@gmail.com> <48C435B4.6020403@gmail.com> Message-ID: <1220818759.13109.18.camel@tuxhugs> On Sun, 2008-09-07 at 16:12 -0400, Lyos Gemini Norezel wrote: > Sure... but why not have a distribution just for the developers? > [...] > And again... why not create a distribution for Servers? > [...] > Ok... but again... why not have a distribution aim specifically at > developers? If you want to duplicate such an immense workload with only minor changes here and there, feel free; but we as developers are intrinsically a bit lazy: we like things to work simply and effectively. Duplicating much unnecessary work like this is essentially asking for loads of error and frustration... -- ?Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From arjan at infradead.org Sun Sep 7 20:22:02 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Sun, 7 Sep 2008 13:22:02 -0700 Subject: Boot speedup with readahead In-Reply-To: <6e24a8e80809070635j3c753697nffc465c64a6d014a@mail.gmail.com> References: <20080906212125.27b9b3bb@infradead.org> <6e24a8e80809070635j3c753697nffc465c64a6d014a@mail.gmail.com> Message-ID: <20080907132202.762e35e0@infradead.org> On Sun, 7 Sep 2008 15:35:34 +0200 Mark wrote: > Please!! make a video of that and full documentation on how to get > that done! i'm gona try that out as well when there are docs on how to > do it. > > I sure hope your right in a 5 second boot. > I hope it's still with: > - Grub (or grub 2) > - that new rhgb replacement > - gdm/kdm/slim/xdm > > Or do you make somekind of a boot dump and start that the next time > you boot? > without spoiling the presentation.. no we don't do fakes like suspend/resume etc. we start counting at the grub screen and stop counting when the GUI is on the screen and the CPU and disk are idle. we're not using rhgb (why would we? it's on the screen maybe at 8 seconds.. we're done at 5) -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From sandeen at redhat.com Sun Sep 7 20:27:11 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Sun, 07 Sep 2008 15:27:11 -0500 Subject: Boot speedup with readahead In-Reply-To: <20080907132202.762e35e0@infradead.org> References: <20080906212125.27b9b3bb@infradead.org> <6e24a8e80809070635j3c753697nffc465c64a6d014a@mail.gmail.com> <20080907132202.762e35e0@infradead.org> Message-ID: <48C4391F.4050108@redhat.com> Arjan van de Ven wrote: > On Sun, 7 Sep 2008 15:35:34 +0200 > Mark wrote: > >> Please!! make a video of that and full documentation on how to get >> that done! i'm gona try that out as well when there are docs on how to >> do it. >> >> I sure hope your right in a 5 second boot. >> I hope it's still with: >> - Grub (or grub 2) >> - that new rhgb replacement >> - gdm/kdm/slim/xdm >> >> Or do you make somekind of a boot dump and start that the next time >> you boot? >> > > without spoiling the presentation.. While the presentation is well and good, I hope that delaying it for the presentation won't make it miss F10, if that would otherwise be a possibility? :) -Eric > no we don't do fakes like > suspend/resume etc. > > we start counting at the grub screen and stop counting when the GUI is > on the screen and the CPU and disk are idle. > > we're not using rhgb (why would we? it's on the screen maybe at 8 > seconds.. we're done at 5) > > From jaroslav at aster.pl Sun Sep 7 20:28:54 2008 From: jaroslav at aster.pl (=?utf-8?q?Jaros=C5=82aw_G=C3=B3rny?=) Date: Sun, 7 Sep 2008 22:28:54 +0200 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <48C43202.6050600@gmail.com> References: <48C3B67E.6090301@gmail.com> <20080907180240.GA1485@orient.maison.lan> <48C43202.6050600@gmail.com> Message-ID: <200809072228.55250.jaroslav@aster.pl> Sunday 07 of September 2008 21:56:50 Lyos Gemini Norezel napisa?(a): > Emmanuel Seyman wrote: > > > > Please stop calling people who want things to work out of the box idiots. > > They're not. > > > > Look... regardless of your opinion... the majority of 'users' are > idiots. Whether willfully ignorant or just plain stupid... these people > comprise nearly 90% of the human race. > > This just makes those of us who do care enough to use linux (or code for > linux), somewhat special (or insane)... no? > Following this logic, this 10% of population that are not idiots use Linux. So there's no need to make "Fedora-Mainstream - For mainstream (ie., 'idiot') users". Idiots won't use it. regards, -- jg From seg at haxxed.com Sun Sep 7 20:29:29 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 07 Sep 2008 15:29:29 -0500 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <48C435B4.6020403@gmail.com> References: <48C3B67E.6090301@gmail.com> <48C435B4.6020403@gmail.com> Message-ID: <1220819370.6431.7.camel@localhost.localdomain> On Sun, 2008-09-07 at 16:12 -0400, Lyos Gemini Norezel wrote: > Pavel Shevchuk wrote: > > On Sun, Sep 7, 2008 at 2:09 PM, Lyos Gemini Norezel > > wrote: > > > >> Fedora-Development - Generic development platform > >> > > > > DVD has "Development" group with libs and headers and GCC and what not. > > > > Sure... but why not have a distribution just for the developers? And what is the software you develop going to test and run on? Are you developing desktop applications, server/web applications, or both? So the "developer" distribution is a superset of every other dist, which means all sub-dists must not conflict and.... this whole idea is completely senseless. The raison d'?tre of a distribution is integration. Splitting it up runs completely counter to this. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From peter at thecodergeek.com Sun Sep 7 20:36:13 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 07 Sep 2008 13:36:13 -0700 Subject: [OT] Re: Proposal: Split Fedora into sub-distributions In-Reply-To: <1220819370.6431.7.camel@localhost.localdomain> References: <48C3B67E.6090301@gmail.com> <48C435B4.6020403@gmail.com> <1220819370.6431.7.camel@localhost.localdomain> Message-ID: <1220819773.13109.21.camel@tuxhugs> On Sun, 2008-09-07 at 15:29 -0500, Callum Lerwick wrote: > The raison d'?tre of a distribution is integration. Splitting it up > runs completely counter to this. THAT'S the phrase I was looking for! Thanks. :D -- ?Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From loupgaroublond at gmail.com Sun Sep 7 20:36:53 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sun, 7 Sep 2008 16:36:53 -0400 Subject: smolt-firstboot dependencies In-Reply-To: References: <1220815491.5122.12.camel@amd5600> <6e24a8e80809071304l5d3b124s67890f45886d88bf@mail.gmail.com> Message-ID: <7f692fec0809071336x11f1a6f5rdd712a7c0a54f192@mail.gmail.com> On Sun, Sep 7, 2008 at 4:11 PM, Jason L Tibbitts III wrote: >>>>>> "M" == Mark writes: > > M> And all of that for just something you only see once.. Would be > M> best if smolt-firstboot just didn't have any dependency's or only > M> deps that are required by other must install (like python) apps as > M> well > > Well, it has to do things like talk over the web, so it's going to > need some RPC libraries of some type. I think it is, however, obvious > that the current dependency chain is excessive. > > Checking the specfile, I see the python-turboflot dependency came in > with a change which was not changelogged (and did not include a > release bump), so there's no information about why that dep was > added. The next package change was a license tag change, which > included a release bump and a build. It is possible that something > snuck out which was not intentended. I'm sure more will be known > tomorrow when those involved are back from the weekend. > Turboflot should only be necessary for the webapp server end. It is not necessary for the client or firstboot. -Yaakov From stlwrt at gmail.com Sun Sep 7 21:10:51 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Mon, 8 Sep 2008 00:10:51 +0300 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <48C435B4.6020403@gmail.com> References: <48C3B67E.6090301@gmail.com> <48C435B4.6020403@gmail.com> Message-ID: On Sun, Sep 7, 2008 at 11:12 PM, Lyos Gemini Norezel wrote: > Pavel Shevchuk wrote: >> >> On Sun, Sep 7, 2008 at 2:09 PM, Lyos Gemini Norezel >> wrote: >> >>> >>> Fedora-Development - Generic development platform >>> >> >> DVD has "Development" group with libs and headers and GCC and what not. >> > > Sure... but why not have a distribution just for the developers? I'm developer. My CD bag has Centos 5, Fedora 6, 8, 9. i386 and x86_64. All of them are DVDs. At home i install gtk-devel, qt-devel, gcc, do some packaging and C++ dev. At work i install apache, php, mysql and do web dev. One size fits all. Lightweight desktop spin is sure nice idea (XFCE SIG is working on it), but could you please care less about developers? -- http://scwlab.com From rrankin at ihug.com.au Sun Sep 7 21:35:39 2008 From: rrankin at ihug.com.au (Roy Rankin) Date: Mon, 08 Sep 2008 07:35:39 +1000 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <200809061443.52683.alain.portal@free.fr> Message-ID: <48C4492B.3070105@ihug.com.au> I am the package maintainer of Denemo and an upstream contributor to gpsim. If Alain either does not want to, or cannot, continue being the package maintainer for gpsim. I would be happy to take it over. regards, Roy Rankin Kevin Kofler wrote: > Vasile Gaburici gmail.com> writes: >> I've uploaded a patch for this on the bug page. > > I committed and built it. > > The package will probably need a new maintainer though, unless you can convince > Alain Portal not to leave. > > Kevin Kofler > From jreiser at BitWagon.com Sun Sep 7 22:26:11 2008 From: jreiser at BitWagon.com (John Reiser) Date: Sun, 07 Sep 2008 15:26:11 -0700 Subject: Boot speedup with readahead In-Reply-To: References: <20080906212125.27b9b3bb@infradead.org> Message-ID: <48C45503.5070909@BitWagon.com> drago01 wrote: > On Sun, Sep 7, 2008 at 6:21 AM, Arjan van de Ven wrote: [snip] >> for those who are going to the plumbers conference... Auke Kok and I >> will present there on how to make a Fedora based system boot in 5 >> seconds... >> >> and yes a form of readahead was needed to achieve that ;-) > > wtf? > without a custom kernel I doubt that this is possible.... Shut down and boot an Apple Macintosh running current OS X 10.5.4. As part of shutting down, it builds a RAM disk of what will be needed at next boot, then saves the RAM disk to hard disk. (I have not seen the work by Arjan+Auke, but I boot many kinds of systems.) -- From vgaburici at gmail.com Sun Sep 7 22:38:36 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Mon, 8 Sep 2008 01:38:36 +0300 Subject: Boot speedup with readahead In-Reply-To: <48C45503.5070909@BitWagon.com> References: <20080906212125.27b9b3bb@infradead.org> <48C45503.5070909@BitWagon.com> Message-ID: On Mon, Sep 8, 2008 at 1:26 AM, John Reiser wrote: > drago01 wrote: >> On Sun, Sep 7, 2008 at 6:21 AM, Arjan van de Ven wrote: > [snip] >>> for those who are going to the plumbers conference... Auke Kok and I >>> will present there on how to make a Fedora based system boot in 5 >>> seconds... >>> >>> and yes a form of readahead was needed to achieve that ;-) >> >> wtf? >> without a custom kernel I doubt that this is possible.... > > Shut down and boot an Apple Macintosh running current OS X 10.5.4. > As part of shutting down, it builds a RAM disk of what will be needed > at next boot, then saves the RAM disk to hard disk. (I have not seen > the work by Arjan+Auke, but I boot many kinds of systems.) Interesting, so it's almost a hibernate in disguise. (I haven't touched a Mac since 10.4) > > -- > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From markg85 at gmail.com Sun Sep 7 22:52:48 2008 From: markg85 at gmail.com (Mark) Date: Mon, 8 Sep 2008 00:52:48 +0200 Subject: Boot speedup with readahead In-Reply-To: <48C45503.5070909@BitWagon.com> References: <20080906212125.27b9b3bb@infradead.org> <48C45503.5070909@BitWagon.com> Message-ID: <6e24a8e80809071552r73cc81banc22a649f68e799eb@mail.gmail.com> On Mon, Sep 8, 2008 at 12:26 AM, John Reiser wrote: > drago01 wrote: >> On Sun, Sep 7, 2008 at 6:21 AM, Arjan van de Ven wrote: > [snip] >>> for those who are going to the plumbers conference... Auke Kok and I >>> will present there on how to make a Fedora based system boot in 5 >>> seconds... >>> >>> and yes a form of readahead was needed to achieve that ;-) >> >> wtf? >> without a custom kernel I doubt that this is possible.... > > Shut down and boot an Apple Macintosh running current OS X 10.5.4. > As part of shutting down, it builds a RAM disk of what will be needed > at next boot, then saves the RAM disk to hard disk. (I have not seen > the work by Arjan+Auke, but I boot many kinds of systems.) > > -- > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I've been wondering if that was possible or not. Now since you told it is (for mac) i wonder if something like it exists for linux.. I've been looking for something like: "boot from ramdisk" but nothing useful so far. @Arjan, Can you tell if you made code adjustments to readahead? or didn't you use that (because you said "a form of").. And any other code adjustments.. Men.. just tell us how you did this ^_^ From jos at xos.nl Sun Sep 7 22:55:04 2008 From: jos at xos.nl (Jos Vos) Date: Mon, 8 Sep 2008 00:55:04 +0200 Subject: F9 chkfontpath replacement? In-Reply-To: <48C28D30.8020109@n-dimensional.de> References: <200809052036.m85KaxLO006814@jasmine.xos.nl> <48C28D30.8020109@n-dimensional.de> Message-ID: <20080907225504.GA15364@jasmine.xos.nl> On Sat, Sep 06, 2008 at 04:01:20PM +0200, Hans Ulrich Niedermann wrote: > I got a bug pointing to this while we were preparing for F-8: > > http://fedoraproject.org/wiki/Releases/FeatureNoMoreXFS I already found out that there were symlinks in /etc/X11/fontpath.d, but I don't get them (a set of Type1 fonts) working. That is, I don't see them in "fc-list" nor in applications like OO.org. Besides creating the symlink, I did "mkfontdir" and "mkfontscale". Any suggestions? -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From tmus at tmus.dk Sun Sep 7 23:04:09 2008 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sun, 07 Sep 2008 21:04:09 -0200 Subject: long-standing "can't connect to windows shares" bug... Message-ID: Hi guys. I have had problems connecting to Windows shares from nautilus (Places->Connect to server), since F9 was first released. The problem is described in https://bugzilla.redhat.com/show_bug.cgi?id=448008 but the bug has seen no activity for a few months now. Am I the only one hit by this problem, or is it in fact not possible for anyone to connect to a windows share from nautilus in F9? I'd really love for this bug to get fixed in F9, but (at least) equally important, is having it fixed in F10 release. Am I alone here (in which case I must be able to tweak stuff on the windows servers to get things going)? Or is this actually a problem for everyone, "depending" on Windows files servers (in which case the bug deserves a little more attention imho)? Thanks for any feedback! /Thomas From gmaxwell at gmail.com Sun Sep 7 23:10:35 2008 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Sun, 7 Sep 2008 19:10:35 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <48C4317B.9050203@redhat.com> References: <8553.1220772699@sss.pgh.pa.us> <48C4317B.9050203@redhat.com> Message-ID: On Sun, Sep 7, 2008 at 3:54 PM, Andrew Haley wrote: > Gregory Maxwell wrote: > >> The notion that firmware ought to be free isn't absurd: It doesn't >> take much effort to find examples of firmware imposing unreasonable >> limits on users, or firmware containing nasty hidden security bugs. > > Just to get away from the ethics flame^H^H^H^H^Hdiscussion for a > moment... > > This makes me think of a really interesting question: security- > critical organizations presumably have to make use of commercially > available computers just like the rest of us. Someone somewhere > must have thought about the issues of binary firmware blobs for > video and network hardware and their potential to leak data, > either deliberately or accidentally. One of the many nice things > about free software is the fact that it's reasonably easy to inspect > it for security analysis; binary blobs weaken that. There are two broad classes of 'security-critical organizations', real ones and pretenders. Most are pretenders, they fail to consider issues like this, then when it fails they show that they tried really hard and thus it isn't their fault. Real ones consider these issues, and demand manufacturers comply with various security standards which validate the security of the hardware/firmware. Manufacturers often fail to actually do a good job of this, and can get away with it because bad security looks just like good security. ... so then when it fails the security-critical organization points to the standards that were violated, thus demonstrating the breech was not their fault. :) :) I've found two blobs I use on my systems, one of them very obviously is a FPGA image, another one is appears to be software for a small micro-controller. I'm not so sure that the FSF would consider the FPGA image software, but I don't know that they've considered this issue in the context of OS-shipped blobs (in fact, I've heard FPGAs != software from them in the past), I think the vast majority of the blobs distributed in fedora are software for an embedded general purpose CPU and not FPGA images (generally FPGAs are enough of an additional per-unit cost thet you don't see them in mass market devices). (RME hammerfall firmware is the FPGA image, incidentally). As was pointed out here, a spin could be created easily enough. It would make the FSF happy, as well as some number of other people (it would make me happy, if for no other reason than I'd get a better understanding of which of these blobs I'm actually using). From vonbrand at inf.utfsm.cl Sun Sep 7 23:29:02 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 07 Sep 2008 19:29:02 -0400 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <48C43202.6050600@gmail.com> References: <48C3B67E.6090301@gmail.com> <1220803513.3099.7.camel@sb-home> <20080907180240.GA1485@orient.maison.lan> <48C43202.6050600@gmail.com> Message-ID: <200809072329.m87NT281028875@laptop14.inf.utfsm.cl> Lyos Gemini Norezel wrote: > Emmanuel Seyman wrote: > > * nodata [07/09/2008 18:29] : > > > >> Am Sonntag, den 07.09.2008, 07:09 -0400 schrieb Lyos Gemini Norezel: > >> Not helpful. > >> > > > > Agreed. > > > > Please stop calling people who want things to work out of the box idiots. > > They're not. > > > > Emmanuel > Look... regardless of your opinion... the majority of 'users' are > idiots. Whether willfully ignorant or just plain stupid... these > people comprise nearly 90% of the human race. No... it is just that nobody is able to deal "intelligently" with all situations, they just don't have the resources. You /have/ to behave like a complete dud in 90+% of things to concentrate on those few percent that _really_ interest you/where you are _really_ good (and thus are able to shine). > This just makes those of us who do care enough to use linux (or code > for linux), somewhat special (or insane)... no? No, those who code for/tinker with Linux are just Linux geeks (a few percent of all Linux users, by the above). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From konrad at tylerc.org Sun Sep 7 23:36:55 2008 From: konrad at tylerc.org (Conrad Meyer) Date: Sun, 7 Sep 2008 16:36:55 -0700 Subject: Fedora not "free" enough for GNU? In-Reply-To: References: <48C4317B.9050203@redhat.com> Message-ID: <200809071636.55955.konrad@tylerc.org> Quoth Gregory Maxwell: > On Sun, Sep 7, 2008 at 3:54 PM, Andrew Haley wrote: > > Gregory Maxwell wrote: > > > >> The notion that firmware ought to be free isn't absurd: It doesn't > >> take much effort to find examples of firmware imposing unreasonable > >> limits on users, or firmware containing nasty hidden security bugs. > > > > Just to get away from the ethics flame^H^H^H^H^Hdiscussion for a > > moment... > > > > This makes me think of a really interesting question: security- > > critical organizations presumably have to make use of commercially > > available computers just like the rest of us. Someone somewhere > > must have thought about the issues of binary firmware blobs for > > video and network hardware and their potential to leak data, > > either deliberately or accidentally. One of the many nice things > > about free software is the fact that it's reasonably easy to inspect > > it for security analysis; binary blobs weaken that. > > There are two broad classes of 'security-critical organizations', real > ones and pretenders. Most are pretenders, they fail to consider issues > like this, then when it fails they show that they tried really hard > and thus it isn't their fault. Real ones consider these issues, and > demand manufacturers comply with various security standards which > validate the security of the hardware/firmware. Manufacturers often > fail to actually do a good job of this, and can get away with it > because bad security looks just like good security. ... so then when > it fails the security-critical organization points to the standards > that were violated, thus demonstrating the breech was not their fault. > :) :) > > I've found two blobs I use on my systems, one of them very obviously > is a FPGA image, another one is appears to be software for a small > micro-controller. I'm not so sure that the FSF would consider the > FPGA image software, but I don't know that they've considered this > issue in the context of OS-shipped blobs (in fact, I've heard FPGAs != > software from them in the past), I think the vast majority of the > blobs distributed in fedora are software for an embedded general > purpose CPU and not FPGA images (generally FPGAs are enough of an > additional per-unit cost thet you don't see them in mass market > devices). (RME hammerfall firmware is the FPGA image, incidentally). > > As was pointed out here, a spin could be created easily enough. It > would make the FSF happy, as well as some number of other people (it > would make me happy, if for no other reason than I'd get a better > understanding of which of these blobs I'm actually using). The spin's already been created, it's called BLAG. Regards, -- Conrad Meyer From vgaburici at gmail.com Sun Sep 7 23:38:21 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Mon, 8 Sep 2008 02:38:21 +0300 Subject: Fedora not "free" enough for GNU? In-Reply-To: References: <8553.1220772699@sss.pgh.pa.us> <48C4317B.9050203@redhat.com> Message-ID: If you do make a spin just to please GNU, I suggest you call it "GNU/Fedora" ;) On Mon, Sep 8, 2008 at 2:10 AM, Gregory Maxwell wrote: > On Sun, Sep 7, 2008 at 3:54 PM, Andrew Haley wrote: >> Gregory Maxwell wrote: >> >>> The notion that firmware ought to be free isn't absurd: It doesn't >>> take much effort to find examples of firmware imposing unreasonable >>> limits on users, or firmware containing nasty hidden security bugs. >> >> Just to get away from the ethics flame^H^H^H^H^Hdiscussion for a >> moment... >> >> This makes me think of a really interesting question: security- >> critical organizations presumably have to make use of commercially >> available computers just like the rest of us. Someone somewhere >> must have thought about the issues of binary firmware blobs for >> video and network hardware and their potential to leak data, >> either deliberately or accidentally. One of the many nice things >> about free software is the fact that it's reasonably easy to inspect >> it for security analysis; binary blobs weaken that. > > There are two broad classes of 'security-critical organizations', real > ones and pretenders. Most are pretenders, they fail to consider issues > like this, then when it fails they show that they tried really hard > and thus it isn't their fault. Real ones consider these issues, and > demand manufacturers comply with various security standards which > validate the security of the hardware/firmware. Manufacturers often > fail to actually do a good job of this, and can get away with it > because bad security looks just like good security. ... so then when > it fails the security-critical organization points to the standards > that were violated, thus demonstrating the breech was not their fault. > :) :) > > I've found two blobs I use on my systems, one of them very obviously > is a FPGA image, another one is appears to be software for a small > micro-controller. I'm not so sure that the FSF would consider the > FPGA image software, but I don't know that they've considered this > issue in the context of OS-shipped blobs (in fact, I've heard FPGAs != > software from them in the past), I think the vast majority of the > blobs distributed in fedora are software for an embedded general > purpose CPU and not FPGA images (generally FPGAs are enough of an > additional per-unit cost thet you don't see them in mass market > devices). (RME hammerfall firmware is the FPGA image, incidentally). > > As was pointed out here, a spin could be created easily enough. It > would make the FSF happy, as well as some number of other people (it > would make me happy, if for no other reason than I'd get a better > understanding of which of these blobs I'm actually using). > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From michel.sylvan at gmail.com Sun Sep 7 23:41:02 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 7 Sep 2008 19:41:02 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: References: <8553.1220772699@sss.pgh.pa.us> <48C4317B.9050203@redhat.com> Message-ID: On Sun, Sep 7, 2008 at 7:10 PM, Gregory Maxwell wrote: > > As was pointed out here, a spin could be created easily enough. It > would make the FSF happy, as well as some number of other people (it > would make me happy, if for no other reason than I'd get a better > understanding of which of these blobs I'm actually using). > A spin could be created easily enough, but we'd probably need to have a special Yum group for binary firmwares (and packages that contain them, e.g. the normal kernel), so that systems not using such firmwares do not accidentally end up with them. -- Michel Salim http://hircus.jaiku.com/ From michel.sylvan at gmail.com Sun Sep 7 23:44:19 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 7 Sep 2008 19:44:19 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <200809071636.55955.konrad@tylerc.org> References: <48C4317B.9050203@redhat.com> <200809071636.55955.konrad@tylerc.org> Message-ID: On Sun, Sep 7, 2008 at 7:36 PM, Conrad Meyer wrote: > Quoth Gregory Maxwell: >> On Sun, Sep 7, 2008 at 3:54 PM, Andrew Haley wrote: >> > Gregory Maxwell wrote: >> > >> >> The notion that firmware ought to be free isn't absurd: It doesn't >> >> take much effort to find examples of firmware imposing unreasonable >> >> limits on users, or firmware containing nasty hidden security bugs. >> > >> > Just to get away from the ethics flame^H^H^H^H^Hdiscussion for a >> > moment... >> > >> > This makes me think of a really interesting question: security- >> > critical organizations presumably have to make use of commercially >> > available computers just like the rest of us. Someone somewhere >> > must have thought about the issues of binary firmware blobs for >> > video and network hardware and their potential to leak data, >> > either deliberately or accidentally. One of the many nice things >> > about free software is the fact that it's reasonably easy to inspect >> > it for security analysis; binary blobs weaken that. >> >> There are two broad classes of 'security-critical organizations', real >> ones and pretenders. Most are pretenders, they fail to consider issues >> like this, then when it fails they show that they tried really hard >> and thus it isn't their fault. Real ones consider these issues, and >> demand manufacturers comply with various security standards which >> validate the security of the hardware/firmware. Manufacturers often >> fail to actually do a good job of this, and can get away with it >> because bad security looks just like good security. ... so then when >> it fails the security-critical organization points to the standards >> that were violated, thus demonstrating the breech was not their fault. >> :) :) >> >> I've found two blobs I use on my systems, one of them very obviously >> is a FPGA image, another one is appears to be software for a small >> micro-controller. I'm not so sure that the FSF would consider the >> FPGA image software, but I don't know that they've considered this >> issue in the context of OS-shipped blobs (in fact, I've heard FPGAs != >> software from them in the past), I think the vast majority of the >> blobs distributed in fedora are software for an embedded general >> purpose CPU and not FPGA images (generally FPGAs are enough of an >> additional per-unit cost thet you don't see them in mass market >> devices). (RME hammerfall firmware is the FPGA image, incidentally). >> >> As was pointed out here, a spin could be created easily enough. It >> would make the FSF happy, as well as some number of other people (it >> would make me happy, if for no other reason than I'd get a better >> understanding of which of these blobs I'm actually using). > > The spin's already been created, it's called BLAG. > That's not really a spin, though, that's a derivative distribution? The idea of my original flame^H^H^H^H^Hquestion is to see what minimal changes we can adopt to make GNU happy. If it's too intrusive then of course it's not really worth it. A spin can only contain packages that are taken from Fedora proper, thus at the minimum we'd need a blob-free kernel. Isolating the other firmware packages should be easier. -- Michel Salim http://hircus.jaiku.com/ From michel.sylvan at gmail.com Sun Sep 7 23:47:22 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Sun, 7 Sep 2008 19:47:22 -0400 Subject: Boot speedup with readahead In-Reply-To: References: <20080906212125.27b9b3bb@infradead.org> <48C45503.5070909@BitWagon.com> Message-ID: On Sun, Sep 7, 2008 at 6:38 PM, Vasile Gaburici wrote: > On Mon, Sep 8, 2008 at 1:26 AM, John Reiser wrote: >> drago01 wrote: >>> On Sun, Sep 7, 2008 at 6:21 AM, Arjan van de Ven wrote: >> [snip] >>>> for those who are going to the plumbers conference... Auke Kok and I >>>> will present there on how to make a Fedora based system boot in 5 >>>> seconds... >>>> >>>> and yes a form of readahead was needed to achieve that ;-) >>> >>> wtf? >>> without a custom kernel I doubt that this is possible.... >> >> Shut down and boot an Apple Macintosh running current OS X 10.5.4. >> As part of shutting down, it builds a RAM disk of what will be needed >> at next boot, then saves the RAM disk to hard disk. (I have not seen >> the work by Arjan+Auke, but I boot many kinds of systems.) > > Interesting, so it's almost a hibernate in disguise. (I haven't > touched a Mac since 10.4) More like a "JIT"-optimized initrd, perhaps. 10.5 has some interesting optimizations, though the stricter-checking fsck is really annoying. But that's not a discussion to have here. -- Michel Salim http://hircus.jaiku.com/ From vgaburici at gmail.com Sun Sep 7 23:46:58 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Mon, 8 Sep 2008 02:46:58 +0300 Subject: Fedora not "free" enough for GNU? In-Reply-To: <200809071636.55955.konrad@tylerc.org> References: <48C4317B.9050203@redhat.com> <200809071636.55955.konrad@tylerc.org> Message-ID: I see you can download blag already: http://www.blagblagblag.org/ On Mon, Sep 8, 2008 at 2:36 AM, Conrad Meyer wrote: > Quoth Gregory Maxwell: >> On Sun, Sep 7, 2008 at 3:54 PM, Andrew Haley wrote: >> > Gregory Maxwell wrote: >> > >> >> The notion that firmware ought to be free isn't absurd: It doesn't >> >> take much effort to find examples of firmware imposing unreasonable >> >> limits on users, or firmware containing nasty hidden security bugs. >> > >> > Just to get away from the ethics flame^H^H^H^H^Hdiscussion for a >> > moment... >> > >> > This makes me think of a really interesting question: security- >> > critical organizations presumably have to make use of commercially >> > available computers just like the rest of us. Someone somewhere >> > must have thought about the issues of binary firmware blobs for >> > video and network hardware and their potential to leak data, >> > either deliberately or accidentally. One of the many nice things >> > about free software is the fact that it's reasonably easy to inspect >> > it for security analysis; binary blobs weaken that. >> >> There are two broad classes of 'security-critical organizations', real >> ones and pretenders. Most are pretenders, they fail to consider issues >> like this, then when it fails they show that they tried really hard >> and thus it isn't their fault. Real ones consider these issues, and >> demand manufacturers comply with various security standards which >> validate the security of the hardware/firmware. Manufacturers often >> fail to actually do a good job of this, and can get away with it >> because bad security looks just like good security. ... so then when >> it fails the security-critical organization points to the standards >> that were violated, thus demonstrating the breech was not their fault. >> :) :) >> >> I've found two blobs I use on my systems, one of them very obviously >> is a FPGA image, another one is appears to be software for a small >> micro-controller. I'm not so sure that the FSF would consider the >> FPGA image software, but I don't know that they've considered this >> issue in the context of OS-shipped blobs (in fact, I've heard FPGAs != >> software from them in the past), I think the vast majority of the >> blobs distributed in fedora are software for an embedded general >> purpose CPU and not FPGA images (generally FPGAs are enough of an >> additional per-unit cost thet you don't see them in mass market >> devices). (RME hammerfall firmware is the FPGA image, incidentally). >> >> As was pointed out here, a spin could be created easily enough. It >> would make the FSF happy, as well as some number of other people (it >> would make me happy, if for no other reason than I'd get a better >> understanding of which of these blobs I'm actually using). > > The spin's already been created, it's called BLAG. > > Regards, > -- > Conrad Meyer > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From konrad at tylerc.org Sun Sep 7 23:48:24 2008 From: konrad at tylerc.org (Conrad Meyer) Date: Sun, 7 Sep 2008 16:48:24 -0700 Subject: Fedora not "free" enough for GNU? In-Reply-To: References: <200809071636.55955.konrad@tylerc.org> Message-ID: <200809071648.24646.konrad@tylerc.org> Quoth Michel Salim: > On Sun, Sep 7, 2008 at 7:36 PM, Conrad Meyer wrote: > > Quoth Gregory Maxwell: > >> On Sun, Sep 7, 2008 at 3:54 PM, Andrew Haley wrote: > >> > Gregory Maxwell wrote: > >> > > >> >> The notion that firmware ought to be free isn't absurd: It doesn't > >> >> take much effort to find examples of firmware imposing unreasonable > >> >> limits on users, or firmware containing nasty hidden security bugs. > >> > > >> > Just to get away from the ethics flame^H^H^H^H^Hdiscussion for a > >> > moment... > >> > > >> > This makes me think of a really interesting question: security- > >> > critical organizations presumably have to make use of commercially > >> > available computers just like the rest of us. Someone somewhere > >> > must have thought about the issues of binary firmware blobs for > >> > video and network hardware and their potential to leak data, > >> > either deliberately or accidentally. One of the many nice things > >> > about free software is the fact that it's reasonably easy to inspect > >> > it for security analysis; binary blobs weaken that. > >> > >> There are two broad classes of 'security-critical organizations', real > >> ones and pretenders. Most are pretenders, they fail to consider issues > >> like this, then when it fails they show that they tried really hard > >> and thus it isn't their fault. Real ones consider these issues, and > >> demand manufacturers comply with various security standards which > >> validate the security of the hardware/firmware. Manufacturers often > >> fail to actually do a good job of this, and can get away with it > >> because bad security looks just like good security. ... so then when > >> it fails the security-critical organization points to the standards > >> that were violated, thus demonstrating the breech was not their fault. > >> :) :) > >> > >> I've found two blobs I use on my systems, one of them very obviously > >> is a FPGA image, another one is appears to be software for a small > >> micro-controller. I'm not so sure that the FSF would consider the > >> FPGA image software, but I don't know that they've considered this > >> issue in the context of OS-shipped blobs (in fact, I've heard FPGAs != > >> software from them in the past), I think the vast majority of the > >> blobs distributed in fedora are software for an embedded general > >> purpose CPU and not FPGA images (generally FPGAs are enough of an > >> additional per-unit cost thet you don't see them in mass market > >> devices). (RME hammerfall firmware is the FPGA image, incidentally). > >> > >> As was pointed out here, a spin could be created easily enough. It > >> would make the FSF happy, as well as some number of other people (it > >> would make me happy, if for no other reason than I'd get a better > >> understanding of which of these blobs I'm actually using). > > > > The spin's already been created, it's called BLAG. > > > That's not really a spin, though, that's a derivative distribution? > The idea of my original flame^H^H^H^H^Hquestion is to see what minimal > changes we can adopt to make GNU happy. If it's too intrusive then of > course it's not really worth it. > > A spin can only contain packages that are taken from Fedora proper, > thus at the minimum we'd need a blob-free kernel. Isolating the other > firmware packages should be easier. > > -- > Michel Salim > http://hircus.jaiku.com/ Fedora will not include a blob free kernel though, unless upstream does it (i.e. what dwmw2 was trying to help Alexandre Oliva with, despite being insulted for trying to help). Regards, -- Conrad Meyer From forum at ru.bir.ru Sun Sep 7 23:38:09 2008 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Mon, 08 Sep 2008 03:38:09 +0400 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <48C3D2A2.2050904@ru.bir.ru> Message-ID: <48C465E1.1050303@ru.bir.ru> Pavel Shevchuk ?????: > On Sun, Sep 7, 2008 at 4:09 PM, forum wrote: > >> Matt Domsch ?????: >> >>> The following 90 packages have had FTBFS (Fails to Build From Source) >>> failures for several months, some as far back as February 2008. >>> >>> There are several "trivial" failures which could be addressed easily. >>> 8 fail due to unpackaged files >>> 6 fail due to patch fuzz >>> 1 fails due to open() not passing a mode. >>> >>> http://fedoraproject.org/wiki/FTBFS describes the FTBFS process. >>> >>> As was proposed to FESCO, packages with unresolved FTBFS bugs >>> immediately following the Alpha release will be removed from the >>> distribution. Package owners may request that their package _not_ be >>> removed provided they are actively working on resolving the FTBFS and >>> have a plan to resolve the FTBFS before the Release Candidate >>> release. FESCo has the final say of course, but these are the items >>> on my candidate list. I'd prefer packages get fixed rather than >>> removed. If you are the package owner, or are interested in the >>> future of these packages, please investigate these build failures and >>> fix them ASAP. >>> >>> aiksaurus-1.2.1-15.fc6 [u'434484 ASSIGNED'] (build/make) uwog >>> astyle-1.21-6.fc8 [u'433971 ASSIGNED'] (build/make) addutko,mtasaka >>> aterm-1.0.1-2.fc9 [u'440779 ASSIGNED'] (build/make) awjb >>> bes-3.5.3-3.fc9 [u'434360 ASSIGNED'] (build/make) pertusus >>> bitbake-1.8.8-1.fc8 [u'440562 ASSIGNED'] (build/make) ixs >>> bmpx-0.40.14-5.fc9 [u'449431 ASSIGNED'] (patch_fuzz) akahl >>> brltty-3.9-2.2.fc9 [u'449446 ASSIGNED'] (build/make) kasal >>> brutus-keyring-0.9.0-6.fc8 [u'434007 ASSIGNED'] (build/make) >>> bpepple,colding >>> camstream-0.26.3-12.fc8 [u'434345 ASSIGNED'] (build/make) nomis80 >>> coolkey-1.1.0-6.fc9 [u'440753 ASSIGNED'] (build/make) rrelyea,jmagne >>> dap-freeform_handler-3.7.7-2.fc9 [u'434362 ASSIGNED'] (build/make) >>> pertusus >>> dap-hdf4_handler-3.7.7-3.fc9 [u'434363 ASSIGNED'] (build/make) pertusus >>> djvulibre-3.5.20-2.fc9 [u'440910 ASSIGNED'] (build/make) thias >>> elektra-0.6.10-6.fc9 [u'434364 ASSIGNED'] (build/make) pertusus,kwizart >>> erlang-R12B-3.1.fc10 [u'449432 ASSIGNED'] (patch_fuzz) gemi >>> fish-1.23.0-2.fc9 [u'440724 ASSIGNED'] (build/make) ascii,oliver >>> fluxstyle-1.0.1-2.fc7 [u'440757 ASSIGNED'] (build/make) errr >>> fonttools-2.0-0.11.20060223cvs.fc7 [u'434409 ASSIGNED'] >>> (unpackaged_files/python-egg-info?) roozbeh,fonts-sig >>> fontypython-0.2.0-6.fc7 [u'440756 ASSIGNED'] (build/make) >>> cr33dog,fonts-sig >>> fwbuilder-2.1.16-2.fc9 [u'440846 ASSIGNED'] (build/make) ertzing >>> gauche-0.8.13-1.fc9 [u'449627 ASSIGNED'] (build/make) gemi >>> gcl-2.6.7-18.fc9 [u'440913 ASSIGNED'] (build/make) gemi,green >>> gdmap-0.7.5-6.fc6 [u'434529 ASSIGNED'] (build/make) splinux >>> gpsim-0.22.0-5.fc8 [u'434061 ASSIGNED'] (build/make) dionysos >>> gstm-1.2-6.fc7 [u'434531 ASSIGNED'] (build/make) splinux >>> gtk-sharp-1.0.10-12.fc7 [u'434373 ASSIGNED'] >>> (unpackaged_files/python-egg-info?) pfj >>> guile-gnome-platform-2.15.93-6.fc8 [u'434289 ASSIGNED'] (build/make) >>> laxathom >>> g-wrap-1.9.9-5.fc9 [u'434278 ASSIGNED'] (patch_fuzz) laxathom >>> HelixPlayer-1.0.9-4.fc10 [u'449474 ASSIGNED'] (patch_fuzz) abompard >>> ht2html-2.0-5.fc6 [u'440916 ASSIGNED'] (build/make) ifoox >>> itpp-4.0.0-2.fc9 [u'434076 ASSIGNED'] (build/make) edhill >>> jabbin-2.0-0.6.beta2a.fc9 [u'440730 ASSIGNED'] (build/make) >>> jgroups-2.2.9.2-3jpp.2 [u'434352 ASSIGNED'] (build/make) dbhole >>> kdebluetooth-1.0-0.41.beta8.fc9 [u'449604 ASSIGNED'] (build/make) >>> gilboa,scop >>> ladspa-1.12-9.fc9 [u'449542 ASSIGNED'] (build/make) thomasvs >>> libdap-3.7.10-2.fc9 [u'434366 ASSIGNED'] (build/make) pertusus >>> libFoundation-1.1.3-11.fc9 [u'440564 ASSIGNED'] (build/make) athimm >>> libfwbuilder-2.1.16-2.fc9 [u'449591 ASSIGNED'] (build/make) ertzing >>> libnc-dap-3.7.0-9.fc9 [u'434367 ASSIGNED'] (build/make) pertusus >>> libopensync-0.36-2.fc9 [u'449510 ASSIGNED'] (build/make) awjb >>> libzzub-0.2.3-12.fc9 [u'449661 ASSIGNED'] (patch_fuzz) akahl,mtasaka >>> lilypond-2.10.33-1.fc8 [u'434394 ASSIGNED'] (build/make) limb >>> lineakd-0.9-5.fc6 [u'434523 ASSIGNED'] (build/make) xris >>> lineak-defaultplugin-0.9-2.fc6 [u'434520 ASSIGNED'] (build/make) xris >>> lineak-xosdplugin-0.9-2.fc6 [u'434522 ASSIGNED'] (build/make) xris >>> linpsk-0.9-3.fc9 [u'440778 ASSIGNED'] (build/make) >>> bjensen,sindrepb,sconklin >>> linux-atm-2.5.0-5 [u'434069 ASSIGNED', u'449613 ASSIGNED'] (build/make) >>> dwmw2 >>> lostirc-0.4.6-3.fc8 [u'440921 ASSIGNED'] (build/make) splinux,splinux >>> lrmi-0.10-4.fc9 [u'449509 ASSIGNED'] (build/make) pwouters >>> mimetic-0.9.3-2.fc8 [u'434086 ASSIGNED'] (build/make) ensc >>> mod_suphp-0.6.3-1.fc9 [u'449578 ASSIGNED'] (build/make) ixs >>> monodevelop-0.19-6.fc9 [u'449441 ASSIGNED'] (build/make) pfj >>> mosml-2.01-11.fc9 [u'449445 ASSIGNED'] (build/make) gemi >>> moto4lin-0.3-6.fc7 [u'434135 ASSIGNED'] (build/make) jafo >>> muine-scrobbler-0.1.8-5.fc9 [u'449482 ASSIGNED'] (build/make) sindrepb >>> mx-2.0.6-3 [u'434325 ASSIGNED'] (unpackaged_files/python-egg-info?) misa >>> mysql-gui-tools-5.0r12-8.fc9 [u'440734 ASSIGNED', u'433987 ASSIGNED'] >>> (patch_fuzz) ausil >>> >>> >> I'm not maintainer of this package, but mysql-gui-tools is interesting for >> me. >> I think I can fix it soon. >> > > I fixed shellbang patch fuzzyness - > http://attic.scwlab.com/mysql-administrator-spawn_fetches.patch > But now it fails because of GTK API change =( > > In one of the bug (#433987) I'm propose link to my src.rpm which is successfully built on my Fedora9. Now I'm working on package to conform fedora packaging guidelines only and several cosmetic issues. >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> >> > > > > From mmcgrath at redhat.com Mon Sep 8 00:22:14 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Sun, 7 Sep 2008 19:22:14 -0500 (CDT) Subject: smolt-firstboot dependencies In-Reply-To: <7f692fec0809071336x11f1a6f5rdd712a7c0a54f192@mail.gmail.com> References: <1220815491.5122.12.camel@amd5600> <6e24a8e80809071304l5d3b124s67890f45886d88bf@mail.gmail.com> <7f692fec0809071336x11f1a6f5rdd712a7c0a54f192@mail.gmail.com> Message-ID: On Sun, 7 Sep 2008, Yaakov Nemoy wrote: > On Sun, Sep 7, 2008 at 4:11 PM, Jason L Tibbitts III wrote: > >>>>>> "M" == Mark writes: > > > > M> And all of that for just something you only see once.. Would be > > M> best if smolt-firstboot just didn't have any dependency's or only > > M> deps that are required by other must install (like python) apps as > > M> well > > > > Well, it has to do things like talk over the web, so it's going to > > need some RPC libraries of some type. I think it is, however, obvious > > that the current dependency chain is excessive. > > > > Checking the specfile, I see the python-turboflot dependency came in > > with a change which was not changelogged (and did not include a > > release bump), so there's no information about why that dep was > > added. The next package change was a license tag change, which > > included a release bump and a build. It is possible that something > > snuck out which was not intentended. I'm sure more will be known > > tomorrow when those involved are back from the weekend. > > > > Turboflot should only be necessary for the webapp server end. It is > not necessary for the client or firstboot. > This is now fixed. I would like to ask, yet again, why something like this was brought up on the list? Someone could have contacted us directly or even filed a bug. Please think before posting to this list, its too chatty as it is and is _NOT_ the correct place to go looking for actions to be taken on specific packages and bugs that aren't philosophical in nature. -Mike From igorsoares at gmail.com Mon Sep 8 00:37:32 2008 From: igorsoares at gmail.com (Igor Pires Soares) Date: Sun, 07 Sep 2008 21:37:32 -0300 Subject: smolt-firstboot dependencies In-Reply-To: References: <1220815491.5122.12.camel@amd5600> <6e24a8e80809071304l5d3b124s67890f45886d88bf@mail.gmail.com> <7f692fec0809071336x11f1a6f5rdd712a7c0a54f192@mail.gmail.com> Message-ID: <1220834252.4368.4.camel@amd5600> Em Dom, 2008-09-07 ?s 19:22 -0500, Mike McGrath escreveu: > This is now fixed. I would like to ask, yet again, why something like > this was brought up on the list? Someone could have contacted us directly > or even filed a bug. Please think before posting to this list, its too > chatty as it is and is _NOT_ the correct place to go looking for actions > to be taken on specific packages and bugs that aren't philosophical in > nature. I'm sorry. I wasn't sure if it was a bug or not, that's why I decided to ask first. Anyway, thanks for fixing it. From loupgaroublond at gmail.com Mon Sep 8 00:49:53 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Sun, 7 Sep 2008 20:49:53 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: References: <48C4317B.9050203@redhat.com> <200809071636.55955.konrad@tylerc.org> Message-ID: <7f692fec0809071749w48ce465co728e0e754123a9e0@mail.gmail.com> On Sun, Sep 7, 2008 at 7:44 PM, Michel Salim wrote: > On Sun, Sep 7, 2008 at 7:36 PM, Conrad Meyer wrote: >> Quoth Gregory Maxwell: >>> On Sun, Sep 7, 2008 at 3:54 PM, Andrew Haley wrote: >>> > Gregory Maxwell wrote: >>> > >>> >> The notion that firmware ought to be free isn't absurd: It doesn't >>> >> take much effort to find examples of firmware imposing unreasonable >>> >> limits on users, or firmware containing nasty hidden security bugs. >>> > >>> > Just to get away from the ethics flame^H^H^H^H^Hdiscussion for a >>> > moment... >>> > >>> > This makes me think of a really interesting question: security- >>> > critical organizations presumably have to make use of commercially >>> > available computers just like the rest of us. Someone somewhere >>> > must have thought about the issues of binary firmware blobs for >>> > video and network hardware and their potential to leak data, >>> > either deliberately or accidentally. One of the many nice things >>> > about free software is the fact that it's reasonably easy to inspect >>> > it for security analysis; binary blobs weaken that. >>> >>> There are two broad classes of 'security-critical organizations', real >>> ones and pretenders. Most are pretenders, they fail to consider issues >>> like this, then when it fails they show that they tried really hard >>> and thus it isn't their fault. Real ones consider these issues, and >>> demand manufacturers comply with various security standards which >>> validate the security of the hardware/firmware. Manufacturers often >>> fail to actually do a good job of this, and can get away with it >>> because bad security looks just like good security. ... so then when >>> it fails the security-critical organization points to the standards >>> that were violated, thus demonstrating the breech was not their fault. >>> :) :) >>> >>> I've found two blobs I use on my systems, one of them very obviously >>> is a FPGA image, another one is appears to be software for a small >>> micro-controller. I'm not so sure that the FSF would consider the >>> FPGA image software, but I don't know that they've considered this >>> issue in the context of OS-shipped blobs (in fact, I've heard FPGAs != >>> software from them in the past), I think the vast majority of the >>> blobs distributed in fedora are software for an embedded general >>> purpose CPU and not FPGA images (generally FPGAs are enough of an >>> additional per-unit cost thet you don't see them in mass market >>> devices). (RME hammerfall firmware is the FPGA image, incidentally). >>> >>> As was pointed out here, a spin could be created easily enough. It >>> would make the FSF happy, as well as some number of other people (it >>> would make me happy, if for no other reason than I'd get a better >>> understanding of which of these blobs I'm actually using). >> >> The spin's already been created, it's called BLAG. >> > That's not really a spin, though, that's a derivative distribution? > The idea of my original flame^H^H^H^H^Hquestion is to see what minimal > changes we can adopt to make GNU happy. If it's too intrusive then of > course it's not really worth it. > > A spin can only contain packages that are taken from Fedora proper, > thus at the minimum we'd need a blob-free kernel. Isolating the other > firmware packages should be easier. Having looked through a number of the blag packages, a good majority of the changes is rebranding components like anaconda. There are a number of changes though that definitely make it qualify as a derivative, such as choosing jack over pulseaudio. -Yaakov From noriko at redhat.com Mon Sep 8 00:50:58 2008 From: noriko at redhat.com (Noriko Mizumoto) Date: Mon, 08 Sep 2008 10:50:58 +1000 Subject: system-switch-java Message-ID: <48C476F2.7030008@redhat.com> Hi devel team Localization project is currently working on F10 translation, and found that the module called 'system-switch-java' has not been requested it's registration at Transifex for translation where all translators are working on, please see the bug [1]. The package is on the list of Orphan packages[2], however it is not on the list of Retired Packages[3]. Could you please advise us if this package still needs to be translated? [1]:https://bugzilla.redhat.com/show_bug.cgi?id=460426 [2]:https://admin.fedoraproject.org/pkgdb/users/packages/orphan [3]:http://fedoraproject.org/wiki/PackageMaintainers/RetiredPackages cheers noriko From dledford at redhat.com Mon Sep 8 01:11:56 2008 From: dledford at redhat.com (Doug Ledford) Date: Sun, 07 Sep 2008 21:11:56 -0400 Subject: Boot speedup with readahead In-Reply-To: <6e24a8e80809071552r73cc81banc22a649f68e799eb@mail.gmail.com> References: <20080906212125.27b9b3bb@infradead.org> <6e24a8e80809071552r73cc81banc22a649f68e799eb@mail.gmail.com> Message-ID: <1220836316.7801.88.camel@firewall.xsintricity.com> On Mon, 2008-09-08 at 00:52 +0200, Mark wrote: > @Arjan, > Can you tell if you made code adjustments to readahead? or didn't you > use that (because you said "a form of").. > And any other code adjustments.. > > Men.. just tell us how you did this ^_^ Hmm...well, first off the best way to speed up the kernel portion of the boot process would be to identify all the kernel modules you load, and load them in parallel. You might need to tweak some of them to do scheduled sleeps instead of busy loops when waiting for initialization tasks to complete. Then of course upstart and parallel service starts. The biggest time waster in the boot process is serial initialization delay waits. Maybe you have a SCSI controller (the old parallel kind ;-) that needs to scan for devices. There is a 256ms timeout (nominally) for each device *not* present on the bus. If you have a single disk on a wide bus, that's 14 timeouts you need to wait through at 1/4 second each. If you can have your net controllers, your USB controllers, and other modules all doing this kind of stuff simultaneously, you greatly speed up the boot process. Thanks to udev, persistent device naming, and being able to do things like set the eth number by MAC address instead of order that the ethernet drivers are loaded, you can really dump a lot of module loads into the kernel in parallel and then just wait for them all to complete. In that scenario your total time wait is the time it takes your slowest module to initialize (roughly). Similarly with user space services. Do the same basic thing. Readahead can be a tremendous help if you can actually start it before all of the kernel modules are done initializing. For instance, USB devices have a settle delay before they are scanned, so starting readahead as soon as the SATA driver and drive are up means the system can be doing something useful while USB is finishing up. However, I suspect Arjan's system doesn't wait on any USB devices, so at most he has host controllers but nothing slow to initialize. Even just some USB disks might be enough to blow that 5 second load time. Am I close Arjan? -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From gmaxwell at gmail.com Mon Sep 8 01:46:38 2008 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Sun, 7 Sep 2008 21:46:38 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <200809071648.24646.konrad@tylerc.org> References: <200809071636.55955.konrad@tylerc.org> <200809071648.24646.konrad@tylerc.org> Message-ID: On Sun, Sep 7, 2008 at 7:48 PM, Conrad Meyer wrote: > Fedora will not include a blob free kernel though, unless upstream does it > (i.e. what dwmw2 was trying to help Alexandre Oliva with, despite being > insulted for trying to help). Presumably fedora could offer an alternative kernel from a different upstream to meet this requirement? (An yes, Vasile, I'm aware of BLAG, but blag isn't just de-blobbed Fedora) Fedora has a great branding ("Infinite Freedom" etc), it's unfortunate to see it diluted over this technically minor issue. It may be moot, however, since blobs may not be the only blocker. (For example, as distributed, Firefox in Fedora is constantly nagging me to install Flash, and I don't think upstream is interested in changing that behaviour, and one of RMS's criteria in the past is that the OS should not make non-free software automatically available for install as though it were the same as free software) Though I'm perhaps a bit confused by exactly how the rules with respect to following upstream are applied for cases like this, since are there not some packages which are perpetually patched to remove the MP3 codec, for example? From konrad at tylerc.org Mon Sep 8 01:57:16 2008 From: konrad at tylerc.org (Conrad Meyer) Date: Sun, 7 Sep 2008 18:57:16 -0700 Subject: Fedora not "free" enough for GNU? In-Reply-To: References: <200809071648.24646.konrad@tylerc.org> Message-ID: <200809071857.16924.konrad@tylerc.org> Quoth Gregory Maxwell: > On Sun, Sep 7, 2008 at 7:48 PM, Conrad Meyer wrote: > > Fedora will not include a blob free kernel though, unless upstream does it > > (i.e. what dwmw2 was trying to help Alexandre Oliva with, despite being > > insulted for trying to help). > > Presumably fedora could offer an alternative kernel from a different > upstream to meet this requirement? No, it's been discussed before. Fedora won't ship another kernel. > (An yes, Vasile, I'm aware of BLAG, but blag isn't just de-blobbed Fedora) > > Fedora has a great branding ("Infinite Freedom" etc), it's unfortunate > to see it diluted over this technically minor issue. It may be moot, > however, since blobs may not be the only blocker. (For example, as > distributed, Firefox in Fedora is constantly nagging me to install > Flash, and I don't think upstream is interested in changing that > behaviour, and one of RMS's criteria in the past is that the OS should > not make non-free software automatically available for install as > though it were the same as free software) > > Though I'm perhaps a bit confused by exactly how the rules with > respect to following upstream are applied for cases like this, since > are there not some packages which are perpetually patched to remove > the MP3 codec, for example? The MP3 codec is illegal to distribute in the states (where Redhat is), but free software. Flash on the other hand is free to distribute, but closed source. Regards, -- Conrad Meyer From abartlet at samba.org Mon Sep 8 02:19:57 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Mon, 08 Sep 2008 12:19:57 +1000 Subject: How to orphan a feature? (OpenChange) Message-ID: <1220840397.6721.19.camel@naomi.s4.naomi.abartlet.net> Clearly the OpenChange feature won't make it into Fedora 10, and as I feel my energies are best spent on upstream development, I would like to orphan the feature http://fedoraproject.org/wiki/Features/OpenChange and the referenced packages (still pending review), for someone else to take over for a future release. Aside from a note like this to the list, what else do I need to do? In particular, as libmapi/openchange has been approved, but not put into CVS, how do I ensure this approval is useful to whomever comes after me? Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From makghosh at gmail.com Mon Sep 8 03:43:45 2008 From: makghosh at gmail.com (Arindam Ghosh) Date: Mon, 8 Sep 2008 09:13:45 +0530 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <8990327d0809072043u648d7367te46f93f8536adfda@mail.gmail.com> On Fri, Sep 5, 2008 at 9:10 PM, Matt Domsch wrote: > qps-1.9.19-0.2.b.fc7 [u'434312 ASSIGNED'] (build/make) makghosh Fixed in upstream qps-1.10.2-1 -- Arindam Ghosh [http://arindamghosh.wordpress.com] GPG Key: 0EE58920 Key Server: http://pgp.mit.edu From bruno at wolff.to Mon Sep 8 03:57:22 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 7 Sep 2008 22:57:22 -0500 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <200809072329.m87NT281028875@laptop14.inf.utfsm.cl> References: <48C3B67E.6090301@gmail.com> <1220803513.3099.7.camel@sb-home> <20080907180240.GA1485@orient.maison.lan> <48C43202.6050600@gmail.com> <200809072329.m87NT281028875@laptop14.inf.utfsm.cl> Message-ID: <20080908035722.GA28412@wolff.to> On Sun, Sep 07, 2008 at 19:29:02 -0400, "Horst H. von Brand" wrote: > > No, those who code for/tinker with Linux are just Linux geeks (a few > percent of all Linux users, by the above). I suspect a large portion of the population think people who waste their time tinkering with their computers (as opposed to just using them) are the idiots. From bruno at wolff.to Mon Sep 8 04:12:33 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 7 Sep 2008 23:12:33 -0500 Subject: Fedora not "free" enough for GNU? In-Reply-To: <48C4317B.9050203@redhat.com> References: <8553.1220772699@sss.pgh.pa.us> <48C4317B.9050203@redhat.com> Message-ID: <20080908041233.GB28412@wolff.to> On Sun, Sep 07, 2008 at 20:54:35 +0100, Andrew Haley wrote: > > This makes me think of a really interesting question: security- > critical organizations presumably have to make use of commercially > available computers just like the rest of us. Someone somewhere > must have thought about the issues of binary firmware blobs for > video and network hardware and their potential to leak data, > either deliberately or accidentally. One of the many nice things > about free software is the fact that it's reasonably easy to inspect > it for security analysis; binary blobs weaken that. There is a reason the U.S. government is concerned about computers being made in China. There was a relatively recent article that I can't find now, that mentions that easy to miss flaws can be added to chips that would allow people to find keys used by devices. As hardware gets more powerful and companies get more bold about putting anti-consumer features into the bios or device firmware it is going to get much more risky to just trust your hardware. From arjan at infradead.org Mon Sep 8 04:34:52 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Sun, 7 Sep 2008 21:34:52 -0700 Subject: Boot speedup with readahead In-Reply-To: <1220836316.7801.88.camel@firewall.xsintricity.com> References: <20080906212125.27b9b3bb@infradead.org> <6e24a8e80809071552r73cc81banc22a649f68e799eb@mail.gmail.com> <1220836316.7801.88.camel@firewall.xsintricity.com> Message-ID: <20080907213452.13d3277d@infradead.org> On Sun, 07 Sep 2008 21:11:56 -0400 Doug Ledford wrote: > Hmm...well, first off the best way to speed up the kernel portion of > the boot process would be to identify all the kernel modules you > load, and load them in parallel. close but no cigar; my fastboot git tree is used yes but not for modules (we don't use modules for the devices in the system; they're so bog standard that there's no value in using modules for them, and modules are just too slow) > You might need to tweak some of > them to do scheduled sleeps instead of busy loops when waiting for > initialization tasks to complete. Then of course upstart and > parallel service starts. yeah we don't use upstart; it made things slower not faster. > > The biggest time waster in the boot process is serial initialization > delay waits. Maybe you have a SCSI controller (the old parallel > kind ;-) that needs to scan for devices. this is where kernel fastboot comes in. > > Readahead can be a tremendous help if you can actually start it before > all of the kernel modules are done initializing. For instance, USB > devices have a settle delay before they are scanned, so starting > readahead as soon as the SATA driver and drive are up means the system > can be doing something useful while USB is finishing up. we only start readahead after the kernel is done... (but otherwise very early) (it's not the fedora readahead but a totally newly written one) -- If you want to reach me at my work email, use arjan at linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From dbhole at redhat.com Mon Sep 8 05:28:37 2008 From: dbhole at redhat.com (Deepak Bhole) Date: Mon, 8 Sep 2008 01:28:37 -0400 Subject: system-switch-java In-Reply-To: <48C476F2.7030008@redhat.com> References: <48C476F2.7030008@redhat.com> Message-ID: <20080908052836.GA22993@redhat.com> * Noriko Mizumoto [2008-09-07 20:51]: > Hi devel team > > Localization project is currently working on F10 translation, and found > that the module called 'system-switch-java' has not been requested it's > registration at Transifex for translation where all translators are > working on, please see the bug [1]. > > The package is on the list of Orphan packages[2], however it is not on > the list of Retired Packages[3]. > > Could you please advise us if this package still needs to be translated? > > [1]:https://bugzilla.redhat.com/show_bug.cgi?id=460426 > [2]:https://admin.fedoraproject.org/pkgdb/users/packages/orphan > [3]:http://fedoraproject.org/wiki/PackageMaintainers/RetiredPackages > Hi There, I am the new maintainer of system-switch-java. I thought I had already taken ownership of the package.. but turns out something went awry and I accidentally released it a couple of minutes later (according to emails) :/ I have added a comment to the bug stating that the package is still valid. Please go ahead with the translation. Cheers, Deepak > cheers > noriko > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From noriko at redhat.com Mon Sep 8 06:33:52 2008 From: noriko at redhat.com (Noriko Mizumoto) Date: Mon, 08 Sep 2008 16:33:52 +1000 Subject: system-switch-java In-Reply-To: <20080908052836.GA22993@redhat.com> References: <48C476F2.7030008@redhat.com> <20080908052836.GA22993@redhat.com> Message-ID: <48C4C750.6020202@redhat.com> Deepak Bhole ????????: > * Noriko Mizumoto [2008-09-07 20:51]: >> Hi devel team >> >> Localization project is currently working on F10 translation, and found >> that the module called 'system-switch-java' has not been requested it's >> registration at Transifex for translation where all translators are >> working on, please see the bug [1]. >> >> The package is on the list of Orphan packages[2], however it is not on >> the list of Retired Packages[3]. >> >> Could you please advise us if this package still needs to be translated? >> >> [1]:https://bugzilla.redhat.com/show_bug.cgi?id=460426 >> [2]:https://admin.fedoraproject.org/pkgdb/users/packages/orphan >> [3]:http://fedoraproject.org/wiki/PackageMaintainers/RetiredPackages >> > > Hi There, > > I am the new maintainer of system-switch-java. I thought I had already > taken ownership of the package.. but turns out something went awry and I > accidentally released it a couple of minutes later (according to emails) > :/ > > I have added a comment to the bug stating that the package is still valid. > Please go ahead with the translation. Hi Deepak Thank you so much for quick response! It is good news, the module is no longer orphan:) Now some translators have started the translation but unable to commit due to the fact that this module has not been registered at Transifex yet. Could you please have a look below and take adding process for translators? We also need to know which branch to be worked on for f10, otherwise generally we work on devel. http://fedoraproject.org/wiki/L10N/FAQ#How_do_I_add_a_module_to_Transifex.3F_.28.23add-transifex.29 Thanks a lot noriko > > Cheers, > Deepak > >> cheers >> noriko >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list > From rjones at redhat.com Mon Sep 8 08:45:08 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 8 Sep 2008 09:45:08 +0100 Subject: Fedora not "free" enough for GNU? In-Reply-To: References: <8553.1220772699@sss.pgh.pa.us> <48C4317B.9050203@redhat.com> Message-ID: <20080908084508.GA7840@amd.home.annexia.org> On Sun, Sep 07, 2008 at 07:10:35PM -0400, Gregory Maxwell wrote: > Real ones consider these issues, and demand manufacturers comply > with various security standards which validate the security of the > hardware/firmware. Hmmm. Apparently even the US DoD has concerns about electronic trapdoors being placed in hardware: http://www.spectrum.ieee.org/may08/6171 BTW, validating software is really hard. Validating hardware is even harder, and verifying that the chip fitted in your fighter jet matches the designs for the chip and doesn't have some 'extra' circuitry hidden away is prohibitively hard (see that article). Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From howard at cohtech.com Mon Sep 8 08:47:43 2008 From: howard at cohtech.com (Howard Wilkinson) Date: Mon, 08 Sep 2008 09:47:43 +0100 Subject: $arch.newkey mirrors Message-ID: <48C4E6AF.6080203@cohtech.com> I have been following the threads concerning the newly signed updates due for release shortly and have done some investigation on the availability of the packages from the mirrors. From my understanding the $arch.newkey directories contain the newly signed packages underneath each of the release version directories in the updates tree. Looking on download.fedora.redhat.com it looks like these started appearing around 28th August and were last updated around 5th September. HOWEVER, on all of the mirrors I have looked at (which is a small sample) these directory trees exist but are empty. The one's we are interested in support RSYNC as we hold a local copy of the trees we are interested in. The best example of this is mirrorservice.org in the UK (best as it is the one we use) but even major site sin the US do not have the packages. Am I right in believing that this is going to cause some significant delay when the keys are finally published? Is this what is expected or is this a problem with the mirroring process that needs fixing? Reason I am asking is that I would like to fix our mirror process but without directories populated on an rsync server I am stuck. Also, what is the likelihood that the old $arch directories will disappear and be replaced by the $arch.newkey directories once the keys are released? Howard. From rjones at redhat.com Mon Sep 8 08:52:56 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 8 Sep 2008 09:52:56 +0100 Subject: New mono SIG created In-Reply-To: <1220812305.17378.5.camel@PB3.Linux> References: <1220812305.17378.5.camel@PB3.Linux> Message-ID: <20080908085256.GB7840@amd.home.annexia.org> On Sun, Sep 07, 2008 at 07:31:45PM +0100, Paul wrote: > If you are a user, packager or maintainer of any mono package, you may > like to know that there is now a SIG devoted to Mono. > > https://fedoraproject.org/wiki/SIGs/Mono > > I'm not quite sure yet how to set up a mailing list (I think it would be > really useful!) for it, but hey, it's early days yet! Has the Mono SIG looked at packaging WIX (http://wix.sourceforge.net/)? I took a brief look at it because the MinGW SIG needs an installer. "It's a bit weird" would be the best way to describe it. No obvious method of building it under Linux, lots of C# files, and I wasn't entirely sure it was all Free software. But that's probably just my unfamiliarity with Mono. In the end we went with NSIS, which is quite a clumsy tool to use, although it does work. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From paul at all-the-johnsons.co.uk Mon Sep 8 09:16:39 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 08 Sep 2008 10:16:39 +0100 Subject: New mono SIG created In-Reply-To: <20080908085256.GB7840@amd.home.annexia.org> References: <1220812305.17378.5.camel@PB3.Linux> <20080908085256.GB7840@amd.home.annexia.org> Message-ID: <1220865399.13769.10.camel@PB3.Linux> Hi, > > I'm not quite sure yet how to set up a mailing list (I think it would be > > really useful!) for it, but hey, it's early days yet! > > Has the Mono SIG looked at packaging WIX > (http://wix.sourceforge.net/)? I took a brief look at it because the > MinGW SIG needs an installer. "It's a bit weird" would be the best > way to describe it. No obvious method of building it under Linux, > lots of C# files, and I wasn't entirely sure it was all Free software. > But that's probably just my unfamiliarity with Mono. In the end we > went with NSIS, which is quite a clumsy tool to use, although it does > work. The licence is Common Public License v1.0 which I think is ok. The build system is a bit messed up (and it seems nant is as well!), but it should be okay under the rawhide mono stack. I'll have more time later to have a look. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Mon Sep 8 09:23:20 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 8 Sep 2008 11:23:20 +0200 (CEST) Subject: F9 chkfontpath replacement? In-Reply-To: <20080907225504.GA15364@jasmine.xos.nl> References: <200809052036.m85KaxLO006814@jasmine.xos.nl> <48C28D30.8020109@n-dimensional.de> <20080907225504.GA15364@jasmine.xos.nl> Message-ID: <31128895cae3c5282c8c3136d1944612.squirrel@rousalka.dyndns.org> Le Lun 8 septembre 2008 00:55, Jos Vos a ?crit : > > On Sat, Sep 06, 2008 at 04:01:20PM +0200, Hans Ulrich Niedermann > wrote: > >> I got a bug pointing to this while we were preparing for F-8: >> >> http://fedoraproject.org/wiki/Releases/FeatureNoMoreXFS > > I already found out that there were symlinks in /etc/X11/fontpath.d, > but I don't get them (a set of Type1 fonts) working. That is, I don't > see them in "fc-list" nor in applications like OO.org. > > Besides creating the symlink, I did "mkfontdir" and "mkfontscale". > > Any suggestions? XFS, mkfontdir, and mkfontscale are totally unecessary for modern apps that use fontconfig and fc-list. If you want to package fonts for use in anything remotely current, please follow our font packaging guidelines http://fedoraproject.org/wiki/Category:Fonts_packaging -- Nicolas Mailhot From sundaram at fedoraproject.org Mon Sep 8 10:20:15 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 08 Sep 2008 15:50:15 +0530 Subject: [Fedora-legal-list] Fedora not "free" enough for GNU? In-Reply-To: References: Message-ID: <48C4FC5F.7050201@fedoraproject.org> Michel Salim wrote: > I was just over at gnu.org to download the anniversary video recorded > by Stephen Fry, and while I was there decided to take a look at what > systems they recommend as being free. > > They list BLAG, which is based on Fedora. But Fedora itself (and > Debian) is not there! > > http://www.gnu.org/links/links.html#FreeGNULinuxDistributions > > This struck me as rather strange, especially considering their > guidelines are actually based on Fedora's (and we are thanked for it): > http://www.gnu.org/philosophy/free-system-distribution-guidelines.html > > As far as I remember, Rahul Sundaram was talking to the GNU / FSF > people about this quite a while back. Is it just the difference over > binary-only firmware that's consigning us to the "non-free" heap? Basically, yes. I posted the last status on http://lwn.net/Articles/282771/ David Woodhouse initiated a effort to remove firmware into a separate archive. While that work is still in progress, you can see that kernel-firmware is a separate package in rawhide already. While there are other advantages, it allows people who don't want such firmware packages installed for philosophical reasons to easily remove them. A separate spin is easier now as well. Rahul From sundaram at fedoraproject.org Mon Sep 8 10:24:28 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 08 Sep 2008 15:54:28 +0530 Subject: Fedora not "free" enough for GNU? In-Reply-To: <8553.1220772699@sss.pgh.pa.us> References: <8553.1220772699@sss.pgh.pa.us> Message-ID: <48C4FD5C.6040905@fedoraproject.org> Tom Lane wrote: > "Michel Salim" writes: >> I was just over at gnu.org to download the anniversary video recorded >> by Stephen Fry, and while I was there decided to take a look at what >> systems they recommend as being free. > > I've got all the respect in the world for the work that RMS has done > over the years ... but: > > gnu.org does not acknowledge any license but the GPL as being "truly > free", and they'll never acknowledge any system that is not 100.00% > GPL code as being "truly free". Draw your own conclusions about how > that stance connects to reality. It is your claim that is disconnected to reality. http://www.gnu.org/philosophy/license-list.html#SoftwareLicenses http://lwn.net/2001/0301/a/rms-ov-license.php3 There are many valid criticisms against FSF but this often repeated one has never been among them. Rahul From kevin.kofler at chello.at Mon Sep 8 10:25:50 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 8 Sep 2008 10:25:50 +0000 (UTC) Subject: How to orphan a feature? (OpenChange) References: <1220840397.6721.19.camel@naomi.s4.naomi.abartlet.net> Message-ID: Andrew Bartlett samba.org> writes: > Clearly the OpenChange feature won't make it into Fedora 10 Indeed, I was going to put that up for discussion: kdepim 4.2 won't be ready in time for F10, and I don't think we should be rushing in some alpha or beta just to get OpenChange support, with OpenChange itself being in heavy development too and the review requests still pending when we're going to be in feature freeze in a few days. > Aside from a note like this to the list, what else do I need to do? Change the targeted release for the feature to Fedora 11 and kick it back from FeatureAcceptedF10 into FeaturePageIncomplete. > In particular, as libmapi/openchange has been approved, but not put into > CVS, how do I ensure this approval is useful to whomever comes after me? I'd suggest making a note in the review request that the package is up for grabs and letting whoever is going to pick it up fill in the CVS request. Another possibility, if you can find somebody to maintain it right away, is that you fill in the CVS request with them as maintainer and yourself as comaintainer, we've done that with a few KDE packages. Kevin Kofler From kevin.kofler at chello.at Mon Sep 8 10:28:16 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 8 Sep 2008 10:28:16 +0000 (UTC) Subject: $arch.newkey mirrors References: <48C4E6AF.6080203@cohtech.com> Message-ID: Howard Wilkinson cohtech.com> writes: > HOWEVER, on all of the mirrors I have looked at (which is a small > sample) these directory trees exist but are empty. They're nonempty at sunsite.mff.cuni.cz. Kevin Kofler From aph at redhat.com Mon Sep 8 10:32:42 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 08 Sep 2008 11:32:42 +0100 Subject: Fedora not "free" enough for GNU? In-Reply-To: <48C4FD5C.6040905@fedoraproject.org> References: <8553.1220772699@sss.pgh.pa.us> <48C4FD5C.6040905@fedoraproject.org> Message-ID: <48C4FF4A.3030501@redhat.com> Rahul Sundaram wrote: > > It is [ the claim that gnu.org does not acknowledge any license but > the GPL as being "truly free" ] that is disconnected to reality. > > http://www.gnu.org/philosophy/license-list.html#SoftwareLicenses > http://lwn.net/2001/0301/a/rms-ov-license.php3 > > There are many valid criticisms against FSF but this often repeated one > has never been among them. Indeed. The real wonder is that this calumny is repeated again and again, corrected every time, but it simply will not die. I do not know why this nonsense is so persistent. Andrew. From paul at all-the-johnsons.co.uk Mon Sep 8 10:36:40 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 08 Sep 2008 11:36:40 +0100 Subject: Fedora not "free" enough for GNU? In-Reply-To: <200809071857.16924.konrad@tylerc.org> References: <200809071648.24646.konrad@tylerc.org> <200809071857.16924.konrad@tylerc.org> Message-ID: <1220870200.13769.29.camel@PB3.Linux> Hi, > > Though I'm perhaps a bit confused by exactly how the rules with > > respect to following upstream are applied for cases like this, since > > are there not some packages which are perpetually patched to remove > > the MP3 codec, for example? > > The MP3 codec is illegal to distribute in the states (where Redhat is), but > free software. Flash on the other hand is free to distribute, but closed > source. Um, I thought that it was unclear as to what the patent for MP3 might actually be (there is a hell of a fuss over in Europe as to if anyone has the right to patent such things - it is unclear over here if the company involved has the right to patent it as there is prior art over the psychoacoustic model used, it is also unclear in the US over if the company involved has such a patent) and rather than risk anything, Fedora (and redhat before that) decided to drop mp3 support and let the likes of Livna do the support in xmms for mp3. Clean hands and all that... TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rawhide at fedoraproject.org Mon Sep 8 12:11:11 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Mon, 8 Sep 2008 12:11:11 +0000 (UTC) Subject: rawhide report: 20080908 changes Message-ID: <20080908121112.1E3B81F81CD@releng2.fedora.phx.redhat.com> New package labrea Tarpit (slow to a crawl) worms and port scanners New package pentaho-reporting-flow-engine Pentaho Flow Reporting Engine Updated Packages: ClanLib06-0.6.5-13.fc10 ----------------------- * Sun Sep 7 18:00:00 2008 Hans de Goede 0.6.5-13 - Fix patch fuzz build failure MagicPoint-1.11b-7.fc10 ----------------------- * Sun Sep 7 18:00:00 2008 Hans de Goede 1.11b-7 - Fix patch fuzz build failure TnL-071111-7.fc10 ----------------- * Sun Sep 7 18:00:00 2008 Hans de Goede 071111-7 - Fix patch fuzz build failure abuse-0.7.1-2.fc10 ------------------ * Sun Sep 7 18:00:00 2008 Hans de Goede 0.7.1-2 - Fix patch fuzz build failure alex4-1.0-7.fc10 ---------------- * Sun Sep 7 18:00:00 2008 Hans de Goede 1.0-7 - Fix patch fuzz build failure anaconda-11.4.1.32-1 -------------------- * Sat Sep 6 18:00:00 2008 David Cantrell - 11.4.1.32-1 - Use struct audit_reply instead of struct auditd_reply_list (dcantrell) * Sat Sep 6 18:00:00 2008 David Cantrell - 11.4.1.31-1 - Use --service=NAME in firewall.py when calling lokkit (dcantrell) - Make NM work for the DHCP case, at least (dcbw) (#461071). (clumens) - Sleep a little after dbus to give it time before HAL connects. (clumens) - Add libsqlite to the initrd, which is needed by NSS libs. (clumens) - Add more dlopen()ed libraries to the initrd. (clumens) - Fix various problems with the exn saving UI (#461129). (clumens) - Fail gracefully if we can't talk to NetworkManager over DBus. (dcantrell) - Reword text for easy of translating plurals (#460728). (clumens) - Make sure /bin/sh is linked to /bin/bash (dcantrell) - Do not include /usr/lib/gconv in install.img (dcantrell) - Add /etc/NetworkManager/dispatcher.d to the install.img. (clumens) - Remove last vestiges of rhpxl and pirut. (clumens) - Only one list of packages in upd-instroot, thanks. (clumens) - Add xrandr back into the install.img (#458738). (clumens) - Add a couple more directories to search paths. (clumens) - Do repo setup and sack setup as separate steps. (clumens) - Fix a typo that was causing repos in the kickstart file to be skipped (#451020). (clumens) bitbake-1.8.10-1.fc10 --------------------- * Sun Sep 7 18:00:00 2008 Andreas Thienemann - 1.8.10-1 - Updated to 1.8.10 - Include .egg - Fix FTBFS #440562 * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 1.8.8-2 - fix license tag bitlbee-1.2.3-1.fc10 -------------------- * Sun Sep 7 18:00:00 2008 Robert Scheck 1.2.3-1 - Upgrade to 1.2.3 (#461424) blender-2.47-3.fc10 ------------------- * Sun Sep 7 18:00:00 2008 Jochen Schmitt 2.47-3 - Fix prerelease SPEC file * Thu Aug 14 18:00:00 2008 Jochen Schmitt 2.47-1 - New upstream release camstream-0.26.3-15.fc10 ------------------------ * Sun Sep 7 18:00:00 2008 Hans de Goede - 0.26.3-15 - Fix FTBFS (bug 434345) - Patch to use libv4l for support for more webcams * Tue Jul 15 18:00:00 2008 Tom "spot" Callaway - 0.26.3-14 - fix license tag * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 0.26.3-13 - Autorebuild for GCC 4.3 clonekeen-0.8.3-5.fc10 ---------------------- * Sun Sep 7 18:00:00 2008 Hans de Goede 0.8.3-5 - Fix patch build failure clutter-cairo-0.8.2-1.fc10 -------------------------- * Sat Sep 6 18:00:00 2008 Allisson Azevedo 0.8.2-1 - Update to 0.8.2 clutter-gst-0.8.0-1.fc10 ------------------------ * Sat Sep 6 18:00:00 2008 Allisson Azevedo 0.8.0-1 - Update to 0.8.0 clutter-gtk-0.8.1-1.fc10 ------------------------ * Sat Sep 6 18:00:00 2008 Allisson Azevedo 0.8.1-1 - Update to 0.8.1 cluttermm-0.7.3-1.fc10 ---------------------- * Sun Sep 7 18:00:00 2008 Denis Leroy - 0.7.3-1 - Update to upstream 0.7.3 - Cairo and gtk parts are forked into their own tarballs cobbler-1.2.3-1.fc10 -------------------- * Sun Sep 7 18:00:00 2008 Michael DeHaan - 1.2.3-1 - Upstream changes (see CHANGELOG) cryptsetup-luks-1.0.6-4.fc10 ---------------------------- * Sat Sep 6 18:00:00 2008 Milan Broz - 1.0.6-4 - Fix close of zero decriptor. - Fix udevsettle delays - use temporary crypt device remapping. * Wed May 28 18:00:00 2008 Till Maas - 1.0.6-3 - remove a duplicate sentence from the manpage (RH #448705) - add patch metadata about upstream status deluge-0.9.08-1.fc10 -------------------- * Sun Sep 7 18:00:00 2008 Peter Gordon - 0.9.08-1 - Update to new upstream release candidate (1.0.0 RC8) - Drop state_upgrade script from the documentation. (This is now handled automatically.) - Fix version in previous %changelog entry. epiphany-extensions-2.23.91-1.fc10 ---------------------------------- * Sun Sep 7 18:00:00 2008 Peter Gordon - 2.23.91-1 - Update to new upstream release (2.23.91) - Drop fixes for Ephy 2.23 API bump (applied upstream): - 2.22_23-api.diff eric-4.2.1-1.fc10 ----------------- * Sun Sep 7 18:00:00 2008 Johan Cwiklinski 4.2.1-1 - 4.2.1 gcalctool-5.23.92-1.fc10 ------------------------ * Sun Sep 7 18:00:00 2008 Matthias Clasen - 5.23.92-1 - Update to 5.23.92 gnome-keyring-2.23.92-1.fc10 ---------------------------- * Sun Sep 7 18:00:00 2008 Matthias Clasen - 2.23.92-1 - Update to 2.23.92 gpsim-0.22.0-7.fc10 ------------------- * Sun Sep 7 18:00:00 2008 Kevin Kofler 0.22.0-7 - Fix build with GCC 4.3 (#434061), patch by Vasile Gaburici, simpler fix for the "list" name conflict from the Debian patch - PPC build fix (acinclude readline problem) by Mamoru Tasaka * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 0.22.0-6 - Autorebuild for GCC 4.3 gyachi-1.1.46-10.fc10 --------------------- * Sun Sep 7 18:00:00 2008 Hans de Goede - 1.1.46-10 - Patch to use libv4l for support for more webcams * Thu Aug 28 18:00:00 2008 Michael Schwendt - 1.1.46-9 - include %_libdir/gyachi directory - include recre8 theme directory - post+postun: run /sbin/ldconfig directly highlight-2.6.12-1.fc10 ----------------------- * Mon Aug 18 18:00:00 2008 Jochen Schmitt 2.6.12-1 - New upstream release jd-2.0.1-0.2.svn2319_trunk.fc10 ------------------------------- * Mon Sep 8 18:00:00 2008 Mamoru Tasaka - rev 2319 - revert default browser setting jday-2.4-3.fc10 --------------- kbilliards-0.8.7b-8.fc10 ------------------------ * Sun Sep 7 18:00:00 2008 Hans de Goede 0.8.7b-8 - Fix patch fuzz build failure kernel-2.6.27-0.314.rc5.git9.fc10 --------------------------------- * Mon Sep 8 18:00:00 2008 Dave Airlie - disable VGA bashing in radeon - make text reserve larger. libetpan-0.56-1.fc10 -------------------- * Mon Sep 8 18:00:00 2008 Andreas Bierfert - 0.56-1 - version upgrade libopensync-0.36-3.fc10 ----------------------- * Sat Sep 6 18:00:00 2008 Andreas Bierfert - 0.36-3 - upgrade for new swig libvorbis-1.2.0-5.fc10 ---------------------- * Sun Sep 7 18:00:00 2008 Hans de Goede -1:1.2.0-5 - Fix patch fuzz build failure mesa-7.2-0.1.fc10 ----------------- * Fri Sep 5 18:00:00 2008 Dave Airlie 7.2-0.1 - latest snapshot - r300 bufmgr code - stop building mach64, patch around some intel issues * Thu Aug 28 18:00:00 2008 Dave Airlie 7.1-0.38 - latest Mesa snapshot - re-enable tex offset - add r300 command buffer support on top of snapshot - fix mesa build on intel driver midori-0.0.20-1.fc10 -------------------- * Sun Sep 7 18:00:00 2008 Peter Gordon - 0.0.20-1 - Update to new upstream release (0.0.20): adds support for single instances, some userscripts and Greasemonkey scripting, zooming and printing, as well as enhanced news feed detection and session-saving (among other improvements). - Switch to WAF build system. mod_suphp-0.6.3-3.fc10 ---------------------- * Sun Sep 7 18:00:00 2008 Andreas Thienemann - 0.6.3-3 - Fix conditionals, fix FTBFS #449578 * Mon Aug 11 18:00:00 2008 Tom "spot" Callaway - 0.6.3-2 - fix license tag perl-JSON-XS-2.2222-1.fc10 -------------------------- * Sun Sep 7 18:00:00 2008 Chris Weyl 2.2222-1 - update to the increasingly silly version of 2.2222 - update files to include bin * Wed Jun 25 18:00:00 2008 Chris Weyl 2.21-1 - update to 2.21 * Wed May 28 18:00:00 2008 Chris Weyl 2.2-1 - update to 2.2 perl-POE-1.003-1.fc10 --------------------- * Sun Sep 7 18:00:00 2008 Chris Weyl 1.003-1 - update to 1.003 - filter provides, too * Mon Jun 16 18:00:00 2008 Chris Weyl 1.0002-1 - update to 1.0002 perl-SQL-Translator-0.09001-1.fc10 ---------------------------------- * Sun Sep 7 18:00:00 2008 Chris Weyl 0.9001-1 - update to 0.9001 - add new BR: perl(Digest::SHA1) >= 2.00 perl-Text-SimpleTable-0.05-2.fc10 --------------------------------- * Sun Sep 7 18:00:00 2008 Chris Weyl 0.05-2 - let's try this again, with patch fuzz = 2 * Sun Sep 7 18:00:00 2008 Chris Weyl 0.05-1 - update to 0.05 - add patch from CPAN RT#22371 - change to ExtUtils::MakeMaker incantations pioneers-0.12.2-2.fc10 ---------------------- * Sun Sep 7 18:00:00 2008 Hans de Goede 0.12.2-2 - Fix patch fuzz build failure plague-0.4.5.3-2.fc10 --------------------- * Sun Sep 7 18:00:00 2008 Michael Schwendt - 0.4.5.3-2 - fix mod_user in plague-user-manager for sqlite2/3 poppler-0.8.7-1.fc10 -------------------- * Sun Sep 7 18:00:00 2008 Matthias Clasen - 0.8.7-1 - Update to 0.8.7 qps-1.10.2-1.fc10 ----------------- * Sat Sep 6 18:00:00 2008 Arindam Ghosh - 1.10.2-1 - new upstream release - fix gcc4.3 mass-rebuild failure - updated license tag * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 1.9.19-0.4.b - fix license tag * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 1.9.19-0.3.b - Autorebuild for GCC 4.3 seahorse-2.23.92-1.fc10 ----------------------- * Sun Sep 7 18:00:00 2008 Matthias Clasen 2.23.92-1 - Update to 2.23.92 seahorse-plugins-2.23.92-1.fc10 ------------------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen 2.23.92-1 - Update to 2.23.92 smolt-1.1.1.1-6.fc10 -------------------- * Sun Sep 7 18:00:00 2008 Mike McGrath 1.1.1.1-6 - Added turboflot to server, removed from firstboot svnkit-1.1.4-4.fc10 ------------------- * Sun Sep 7 18:00:00 2008 Tom "spot" Callaway - 1.1.4-4 - fix license tag t1utils-1.33-1.fc10 ------------------- * Sun Sep 7 18:00:00 2008 Tom "spot" Callaway - 1.33-1 - fix license tag - update to 1.33 taarich-1.20051120-10.fc10 -------------------------- * Sun Sep 7 18:00:00 2008 Tom "spot" Callaway - 1.20051120-10 - fix license tag tango-icon-theme-0.8.1-2.fc10 ----------------------------- * Sun Sep 7 18:00:00 2008 Tom "spot" Callaway - 0.8.1-2 - fix license tag * Sun Sep 9 18:00:00 2007 Peter Gordon - 0.8.1-1 - Update to new upstream release (0.8.1) tango-icon-theme-extras-0.1.0-2.fc10 ------------------------------------ * Sun Sep 7 18:00:00 2008 Tom "spot" Callaway - 0.1.0-2 - fix license tag vdr-1.6.0-5.fc10 ---------------- * Sun Sep 7 18:00:00 2008 Ville Skytt?? - 1.6.0-5 - Work around Fedora buildsys not coping with "%patch -F" (infrastructure ticket #817). * Sun Sep 7 18:00:00 2008 Ville Skytt?? - 1.6.0-4 - Apply upstream 1.6.0-2 maintenance patch. - Update shutdown/wakeup functionality for F-9+ ACPI wakeup. - Install halt.local script (vdr-halt.local.sh) instead of embedding it in README-package. It still needs to be inserted to (or installed/symlinked as) /sbin/halt.local. - Convert remaining docs to UTF-8. - Set expected fuzz factor when applying patches. wxPython-2.8.8.0-2.fc10 ----------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway - 2.8.8.0-2 - fix license tag * Thu Jul 31 18:00:00 2008 Matthew Miller - 2.8.8.0-1 - update to 2.8.8.0 (bug #457408) - a fix for bug #450073 is included in the upstream release, so dropping that patch. xfce4-dev-tools-4.4.0.1-1.fc10 ------------------------------ * Mon Sep 8 18:00:00 2008 Christoph Wickert - 4.4.0.1-1 - Update to 4.4.0.1 xmms-skins-1.2.10-16 -------------------- * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway 1:1.2.10-16 - fix license tag, remove skins where licensing is unclear xorg-x11-drv-i810-2.4.2-4.fc10 ------------------------------ * Mon Sep 8 18:00:00 2008 Dave Airlie 2.4.2-4 - Add patch from fd.o bug 17341 to fix problems on intel EXA xorg-x11-drv-synaptics-0.15.0-5.fc10 ------------------------------------ * Sun Sep 7 18:00:00 2008 Peter Hutterer 0.15.0-5 - update fdi file to support "appletouch" devices. Summary: Added Packages: 2 Removed Packages: 0 Modified Packages: 57 Broken deps for i386 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.i386 requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.i386 requires libetpan.so.11 evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.12-1.fc10.i386 requires perl(MT::Plugin) highlight-2.6.12-1.fc10.i386 requires perl(MT::WeblogPublisher) highlight-2.6.12-1.fc10.i386 requires perl(MT::Entry) highlight-2.6.12-1.fc10.i386 requires perl(MT) highlight-2.6.12-1.fc10.i386 requires perl(MT::Template::Context) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so poker3d-1.1.36-10.fc10.i386 requires libosg.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgUtil.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgSim.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgTerrain.so.35 poker3d-1.1.36-10.fc10.i386 requires libOpenThreads.so.10 poker3d-1.1.36-10.fc10.i386 requires libosgGA.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgFX.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgManipulator.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgDB.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgParticle.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgViewer.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgText.so.35 pyclutter-0.6.2-2.fc10.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc10.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc10.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc10.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc10.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc10.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc10.i386 requires libclutter-gtk-0.6.so.0 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for x86_64 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.x86_64 requires libetpan.so.11()(64bit) evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.12-1.fc10.x86_64 requires perl(MT::Plugin) highlight-2.6.12-1.fc10.x86_64 requires perl(MT::WeblogPublisher) highlight-2.6.12-1.fc10.x86_64 requires perl(MT::Entry) highlight-2.6.12-1.fc10.x86_64 requires perl(MT) highlight-2.6.12-1.fc10.x86_64 requires perl(MT::Template::Context) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgFX.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgGA.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgTerrain.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosg.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgSim.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgText.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgDB.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libOpenThreads.so.10()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgManipulator.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgParticle.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgViewer.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgUtil.so.35()(64bit) pyclutter-0.6.2-2.fc10.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc10.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc10.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc10.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc10.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc10.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc10.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for ppc ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-dillo-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-pgp-3.4.0-1.fc10.ppc requires libetpan.so.11 claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc requires libetpan.so.11 evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.12-1.fc10.ppc requires perl(MT::Plugin) highlight-2.6.12-1.fc10.ppc requires perl(MT::WeblogPublisher) highlight-2.6.12-1.fc10.ppc requires perl(MT::Entry) highlight-2.6.12-1.fc10.ppc requires perl(MT) highlight-2.6.12-1.fc10.ppc requires perl(MT::Template::Context) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so poker3d-1.1.36-10.fc10.ppc requires libosg.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgUtil.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgSim.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgTerrain.so.35 poker3d-1.1.36-10.fc10.ppc requires libOpenThreads.so.10 poker3d-1.1.36-10.fc10.ppc requires libosgGA.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgFX.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgManipulator.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgDB.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgParticle.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgViewer.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgText.so.35 pyclutter-0.6.2-2.fc10.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc10.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc10.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc10.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc10.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc10.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc10.ppc requires libclutter-gtk-0.6.so.0 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires libbfd-2.18.50.0.8-2.fc10.so stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires libopcodes-2.18.50.0.8-2.fc10.so vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for ppc64 ---------------------------------------------------------- claws-mail-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-bogofilter-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-dillo-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-pgp-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) claws-mail-plugins-spamassassin-3.4.0-1.fc10.ppc64 requires libetpan.so.11()(64bit) eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gajim-0.11.4-4.fc10.ppc64 requires python-docutils gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave highlight-2.6.12-1.fc10.ppc64 requires perl(MT::Plugin) highlight-2.6.12-1.fc10.ppc64 requires perl(MT::WeblogPublisher) highlight-2.6.12-1.fc10.ppc64 requires perl(MT::Entry) highlight-2.6.12-1.fc10.ppc64 requires perl(MT) highlight-2.6.12-1.fc10.ppc64 requires perl(MT::Template::Context) livecd-tools-018-1.fc10.ppc64 requires yaboot mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 poker3d-1.1.36-10.fc10.ppc64 requires libosgFX.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgGA.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgTerrain.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosg.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgSim.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgText.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgDB.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libOpenThreads.so.10()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgManipulator.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgParticle.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgViewer.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgUtil.so.35()(64bit) pyclutter-0.6.2-2.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc10.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc10.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc10.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) python-sphinx-0.4.2-1.fc10.noarch requires python-docutils ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 From j.w.r.degoede at hhs.nl Mon Sep 8 12:22:39 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 08 Sep 2008 14:22:39 +0200 Subject: Lonely packages looking for cosy new owner Message-ID: <48C5190F.7020500@hhs.nl> Hi All, I still need to write a little blog post of this, but as from Sept 1st I've been hired by RedHat to work on anaconda (the installer). As such I would like to reduce my package load as much as possible so that I can focus fully on my new job. Thus *all* of my packages are looking for a new owner (I'm not actually orphaning them, but I *really* want to lower my load quite a bit). https://admin.fedoraproject.org/pkgdb/users/packages/jwrdegoede?acls=owner If you are willing to take over any let me know and I'll orphan them and you can pick them up. I'll be around for a long time to come to answer any questions and help with any issues with them, so don't hesitate! Thanks & Regards, Hans From nhorman at redhat.com Mon Sep 8 12:29:25 2008 From: nhorman at redhat.com (Neil Horman) Date: Mon, 8 Sep 2008 08:29:25 -0400 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C5190F.7020500@hhs.nl> References: <48C5190F.7020500@hhs.nl> Message-ID: <20080908122925.GD1667@hmsendeavour.rdu.redhat.com> On Mon, Sep 08, 2008 at 02:22:39PM +0200, Hans de Goede wrote: > Hi All, > > I still need to write a little blog post of this, but as from Sept 1st > I've been hired by RedHat to work on anaconda (the installer). As such I > would like to reduce my package load as much as possible so that I can > focus fully on my new job. > > Thus *all* of my packages are looking for a new owner (I'm not actually > orphaning them, but I *really* want to lower my load quite a bit). > > https://admin.fedoraproject.org/pkgdb/users/packages/jwrdegoede?acls=owner > > If you are willing to take over any let me know and I'll orphan them and > you can pick them up. I'll be around for a long time to come to answer > any questions and help with any issues with them, so don't hesitate! > > Thanks & Regards, > > Hans > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list Hans- Given that we've been discussing various issues with it, and that I'd like to see it continue to live on as well, I'd be happy to take over the coda packages Regards Neil -- /*************************************************** *Neil Horman *Senior Software Engineer *Red Hat, Inc. *nhorman at redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ From nhorman at redhat.com Mon Sep 8 12:31:03 2008 From: nhorman at redhat.com (Neil Horman) Date: Mon, 8 Sep 2008 08:31:03 -0400 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C5190F.7020500@hhs.nl> References: <48C5190F.7020500@hhs.nl> Message-ID: <20080908123103.GE1667@hmsendeavour.rdu.redhat.com> On Mon, Sep 08, 2008 at 02:22:39PM +0200, Hans de Goede wrote: > Hi All, > > I still need to write a little blog post of this, but as from Sept 1st > I've been hired by RedHat to work on anaconda (the installer). As such I > would like to reduce my package load as much as possible so that I can > focus fully on my new job. > > Thus *all* of my packages are looking for a new owner (I'm not actually > orphaning them, but I *really* want to lower my load quite a bit). > > https://admin.fedoraproject.org/pkgdb/users/packages/jwrdegoede?acls=owner > > If you are willing to take over any let me know and I'll orphan them and > you can pick them up. I'll be around for a long time to come to answer > any questions and help with any issues with them, so don't hesitate! > > Thanks & Regards, > > Hans > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list Sorry, if I wasn't clear on this in my last response, but in addition to coda, I'd also be happy to inherity its dependencies, rvm and rpc2 Neil -- /*************************************************** *Neil Horman *Senior Software Engineer *Red Hat, Inc. *nhorman at redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ From alan at redhat.com Mon Sep 8 12:49:49 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 8 Sep 2008 08:49:49 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <20080908041233.GB28412@wolff.to> References: <8553.1220772699@sss.pgh.pa.us> <48C4317B.9050203@redhat.com> <20080908041233.GB28412@wolff.to> Message-ID: <20080908124949.GC28688@file.rdu.redhat.com> On Sun, Sep 07, 2008 at 11:12:33PM -0500, Bruno Wolff III wrote: > > about free software is the fact that it's reasonably easy to inspect > > it for security analysis; binary blobs weaken that. > > There is a reason the U.S. government is concerned about computers being > made in China. There have also been allegations and some evidence of the reverse. And nobody is to sure about Skype either.. http://www.heise.de/english/newsticker/news/113353 http://wikileaks.org/wiki/Skype_and_the_Bavarian_trojan_in_the_middle Alan From dave at rimini.com Mon Sep 8 12:55:39 2008 From: dave at rimini.com (Davide Moretti) Date: Mon, 08 Sep 2008 14:55:39 +0200 Subject: Boot speedup with readahead Message-ID: <20080908145539.xy5hnd4i7qtc0co0@mail.rimini.com> > Can you provide a bootchart for your system? Here they are: http://kirk.rimini.com/~dave/normal.png http://kirk.rimini.com/~dave/readahead.png ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From alan at redhat.com Mon Sep 8 12:57:28 2008 From: alan at redhat.com (Alan Cox) Date: Mon, 8 Sep 2008 08:57:28 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <8553.1220772699@sss.pgh.pa.us> References: <8553.1220772699@sss.pgh.pa.us> Message-ID: <20080908125728.GE28688@file.rdu.redhat.com> On Sun, Sep 07, 2008 at 03:31:39AM -0400, Tom Lane wrote: > gnu.org does not acknowledge any license but the GPL as being "truly > free", and they'll never acknowledge any system that is not 100.00% > GPL code as being "truly free". Draw your own conclusions about how > that stance connects to reality. Untrue. The FSF is quite happy with a lot of 'free software' licenses. There are some (like old advertising BSD) it considers dubious. There are others it considers free - some GPL compatible and some not. Of the ones it considers free there are some it doesn't usually recommend first off (eg BSD) because they don't ensure the code will remain free in future. Alan From harald at redhat.com Mon Sep 8 13:10:41 2008 From: harald at redhat.com (Harald Hoyer) Date: Mon, 08 Sep 2008 15:10:41 +0200 Subject: Boot speedup with readahead In-Reply-To: <20080908145539.xy5hnd4i7qtc0co0@mail.rimini.com> References: <20080908145539.xy5hnd4i7qtc0co0@mail.rimini.com> Message-ID: <48C52451.5010309@redhat.com> Davide Moretti schrieb: >> Can you provide a bootchart for your system? > > Here they are: > > http://kirk.rimini.com/~dave/normal.png > http://kirk.rimini.com/~dave/readahead.png > Ok, In your case it's vmware-networks and hald probing your video card, which seem both to be very CPU intensive. Parallel starting vmware-networks would help and identifying why hald looks so long at your nvidia? card. From limb at jcomserv.net Mon Sep 8 13:11:20 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 8 Sep 2008 08:11:20 -0500 (CDT) Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C5190F.7020500@hhs.nl> References: <48C5190F.7020500@hhs.nl> Message-ID: <24776.198.175.55.5.1220879480.squirrel@mail.jcomserv.net> > Hi All, > > I still need to write a little blog post of this, but as from Sept 1st > I've been hired by RedHat to work on anaconda (the installer). As such I > would like to reduce my package load as much as possible so that I can > focus fully on my new job. Congratulations! > Thus *all* of my packages are looking for a new owner (I'm not actually > orphaning them, but I *really* want to lower my load quite a bit). > > https://admin.fedoraproject.org/pkgdb/users/packages/jwrdegoede?acls=owner > > If you are willing to take over any let me know and I'll orphan them and > you can pick them up. I'll be around for a long time to come to answer > any questions and help with any issues with them, so don't hesitate! I'd be happy to take liquidwar, pinball, pipenightdreams, supertuxkart, and xgalaxy. Possibly others later, but these for now. > Thanks & Regards, > > Hans > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From limb at jcomserv.net Mon Sep 8 13:14:04 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 8 Sep 2008 08:14:04 -0500 (CDT) Subject: Lonely packages looking for cosy new owner In-Reply-To: <24776.198.175.55.5.1220879480.squirrel@mail.jcomserv.net> References: <48C5190F.7020500@hhs.nl> <24776.198.175.55.5.1220879480.squirrel@mail.jcomserv.net> Message-ID: <27257.198.175.55.5.1220879644.squirrel@mail.jcomserv.net> > >> Hi All, >> >> I still need to write a little blog post of this, but as from Sept 1st >> I've been hired by RedHat to work on anaconda (the installer). As such I >> would like to reduce my package load as much as possible so that I can >> focus fully on my new job. > > Congratulations! > >> Thus *all* of my packages are looking for a new owner (I'm not actually >> orphaning them, but I *really* want to lower my load quite a bit). >> >> https://admin.fedoraproject.org/pkgdb/users/packages/jwrdegoede?acls=owner >> >> If you are willing to take over any let me know and I'll orphan them and >> you can pick them up. I'll be around for a long time to come to answer >> any questions and help with any issues with them, so don't hesitate! > > I'd be happy to take liquidwar, pinball, pipenightdreams, supertuxkart, > and xgalaxy. Possibly others later, but these for now. And, logically, tuxkart. >> Thanks & Regards, >> >> Hans >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > > -- > novus ordo absurdum > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From harald at redhat.com Mon Sep 8 13:48:03 2008 From: harald at redhat.com (Harald Hoyer) Date: Mon, 08 Sep 2008 15:48:03 +0200 Subject: Boot speedup with readahead In-Reply-To: <48C2A272.5000504@redhat.com> References: <48C2A272.5000504@redhat.com> Message-ID: Eric Sandeen schrieb: > Harald Hoyer wrote: >> Hello fellow Fedora developers, >> >> recently readahead was modified to adapt to system file changes and to start very early in the boot process >> via upstart. > > Glad to see that! Sorry I helped put the hammer down on older readahead > in the F8 era... but it was pretty broken back then ... ;) > >> I would like to encourage you to test readahead-1.4.5-3.fc10 from rawhide (even possible on F9), which I built >> some minutes ago. It may take a day to reach your local mirror. >> >> # yum --enablerepo=rawhide install readahead >> or >> # yum --enablerepo=rawhide update readahead >> >> With the next reboot readahead-collector runs and collects the information which files are used during the >> boot process. The next reboot then, readahead read ahead those files and the boot process (from init start to >> gdm login screen) should be approx. 10% faster. > > So when / how often does readahead-collector run now? > > Thanks, > -Eric Every month. /etc/cron.monthly/readahead-monthly.cron From harald at redhat.com Mon Sep 8 13:49:39 2008 From: harald at redhat.com (Harald Hoyer) Date: Mon, 08 Sep 2008 15:49:39 +0200 Subject: Boot speedup with readahead In-Reply-To: <200809071638.54199.ville.skytta@iki.fi> References: <4c4ba1530809061203t2ca06046k6e847659258174ee@mail.gmail.com> <200809071638.54199.ville.skytta@iki.fi> Message-ID: Ville Skytt? schrieb: > Good stuff. > > I see slightly more than 10% speedup with this on F-9 from end of grub to > until the KDE splash screen disappears. Ditto to until all apps that I have > on autostart after a small modification. > > The modifications I made to /etc/event.d/readahead-collector.event were > commenting out the [ -f /.autorelabel ] test (no selinux here) as well as > increasing the sleep time in pre-stop script to 50 so that all the apps I > have on autostart get collected. > .autorelabel check should be fixed in readahead-1.4.6 now and the time to sleep in pre-stop can be configured now in /etc/sysconfig/readahead From harald at redhat.com Mon Sep 8 13:50:32 2008 From: harald at redhat.com (Harald Hoyer) Date: Mon, 08 Sep 2008 15:50:32 +0200 Subject: Boot speedup with readahead In-Reply-To: <20080907124135.9qcpb7jgp0oos408@mail.rimini.com> References: <20080907124135.9qcpb7jgp0oos408@mail.rimini.com> Message-ID: Davide Moretti schrieb: > On my system: > > Without readahead: 1 minute and 30 seconds > With readahead: 1 minute and 30 seconds > > Time was until gnome applet showed up, so on my system readahead did not > improve boot speed at all. > > Note that there is a bug that prevents readahead-collector from starting > if you have selinux disabled, since the /.autorelabel file is still > hanging around during reboots, I had to remove this file for collector > to work. fixed in readahead-1.4.6 From denis at poolshark.org Mon Sep 8 14:26:49 2008 From: denis at poolshark.org (Denis Leroy) Date: Mon, 08 Sep 2008 16:26:49 +0200 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C5190F.7020500@hhs.nl> References: <48C5190F.7020500@hhs.nl> Message-ID: <48C53629.9090201@poolshark.org> Hans de Goede wrote: > Hi All, > > I still need to write a little blog post of this, but as from Sept 1st > I've been hired by RedHat to work on anaconda (the installer). As such I > would like to reduce my package load as much as possible so that I can > focus fully on my new job. > > Thus *all* of my packages are looking for a new owner (I'm not actually > orphaning them, but I *really* want to lower my load quite a bit). > I'll take libgda and libgnomedb From lyos.gemininorezel at gmail.com Mon Sep 8 14:28:46 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Mon, 08 Sep 2008 10:28:46 -0400 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C5190F.7020500@hhs.nl> References: <48C5190F.7020500@hhs.nl> Message-ID: <48C5369E.8000105@gmail.com> Hans de Goede wrote: > Hi All, > > I still need to write a little blog post of this, but as from Sept 1st > I've been hired by RedHat to work on anaconda (the installer). As such > I would like to reduce my package load as much as possible so that I > can focus fully on my new job. > > Thus *all* of my packages are looking for a new owner (I'm not > actually orphaning them, but I *really* want to lower my load quite a > bit). > > https://admin.fedoraproject.org/pkgdb/users/packages/jwrdegoede?acls=owner > > > If you are willing to take over any let me know and I'll orphan them > and you can pick them up. I'll be around for a long time to come to > answer any questions and help with any issues with them, so don't > hesitate! > > Thanks & Regards, > > Hans I'd like to take over: arj, id3lib, ksensors, libogg, libtheora, and libvorbis. Thanks, Lyos Gemini Norezel From lyos.gemininorezel at gmail.com Mon Sep 8 14:31:01 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Mon, 08 Sep 2008 10:31:01 -0400 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C5369E.8000105@gmail.com> References: <48C5190F.7020500@hhs.nl> <48C5369E.8000105@gmail.com> Message-ID: <48C53725.2090101@gmail.com> Lyos Gemini Norezel wrote: > Hans de Goede wrote: >> Hi All, >> >> I still need to write a little blog post of this, but as from Sept >> 1st I've been hired by RedHat to work on anaconda (the installer). As >> such I would like to reduce my package load as much as possible so >> that I can focus fully on my new job. >> >> Thus *all* of my packages are looking for a new owner (I'm not >> actually orphaning them, but I *really* want to lower my load quite a >> bit). >> >> https://admin.fedoraproject.org/pkgdb/users/packages/jwrdegoede?acls=owner >> >> >> If you are willing to take over any let me know and I'll orphan them >> and you can pick them up. I'll be around for a long time to come to >> answer any questions and help with any issues with them, so don't >> hesitate! >> >> Thanks & Regards, >> >> Hans > > I'd like to take over: arj, id3lib, ksensors, libogg, libtheora, and > libvorbis. > > Thanks, > Lyos Gemini Norezel > Unless, of course, the comaintainers want the above. Lyos Gemini Norezel From ajax at redhat.com Mon Sep 8 14:32:12 2008 From: ajax at redhat.com (Adam Jackson) Date: Mon, 08 Sep 2008 10:32:12 -0400 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C5190F.7020500@hhs.nl> References: <48C5190F.7020500@hhs.nl> Message-ID: <1220884332.3170.42.camel@atropine.boston.devel.redhat.com> On Mon, 2008-09-08 at 14:22 +0200, Hans de Goede wrote: > Hi All, > > I still need to write a little blog post of this, but as from Sept 1st > I've been hired by RedHat to work on anaconda (the installer). As such I > would like to reduce my package load as much as possible so that I can > focus fully on my new job. > > Thus *all* of my packages are looking for a new owner (I'm not actually > orphaning them, but I *really* want to lower my load quite a bit). > > https://admin.fedoraproject.org/pkgdb/users/packages/jwrdegoede?acls=owner > > If you are willing to take over any let me know and I'll orphan them and > you can pick them up. I'll be around for a long time to come to answer > any questions and help with any issues with them, so don't hesitate! I'll take: freetype1 i2c-tools lesstif libid3tag libogg libtheora libvorbis libXNVCtrl lm_sensors theora-exp vorbis-tools - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sandeen at redhat.com Mon Sep 8 14:49:02 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Mon, 08 Sep 2008 09:49:02 -0500 Subject: Boot speedup with readahead In-Reply-To: References: <48C2A272.5000504@redhat.com> Message-ID: <48C53B5E.3010500@redhat.com> Harald Hoyer wrote: > Eric Sandeen schrieb: >> So when / how often does readahead-collector run now? >> >> Thanks, >> -Eric > > Every month. > > /etc/cron.monthly/readahead-monthly.cron It'd be interesting to do a daily yum update / reboot and see how the boot times look, graphed for a couple months. Will things degrade until the next collection run? I wonder if some inotify magic might be interesting; if more than X% of the previously-collected files have changed, then kick the collector on again? -Eric From christoph.wickert at googlemail.com Mon Sep 8 14:53:05 2008 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Mon, 08 Sep 2008 16:53:05 +0200 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <1220885585.13498.7.camel@wicktop.localdomain> Am Freitag, den 05.09.2008, 10:40 -0500 schrieb Matt Domsch: > The following 90 packages have had FTBFS (Fails to Build From Source) > failures for several months, some as far back as February 2008. > lostirc-0.4.6-3.fc8 [u'440921 ASSIGNED'] (build/make) splinux,splinux I fixed this in 0.4.6-6, but I think the maintainer (Damien Durand) might be MIA, because the bug was open for 5 months and Denis Leroy provided a patch just one day after the bug was reported. Regards, Christoph From j.w.r.degoede at hhs.nl Mon Sep 8 14:55:16 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 08 Sep 2008 16:55:16 +0200 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C53629.9090201@poolshark.org> References: <48C5190F.7020500@hhs.nl> <48C53629.9090201@poolshark.org> Message-ID: <48C53CD4.4010900@hhs.nl> Denis Leroy wrote: > Hans de Goede wrote: >> Hi All, >> >> I still need to write a little blog post of this, but as from Sept 1st >> I've been hired by RedHat to work on anaconda (the installer). As such >> I would like to reduce my package load as much as possible so that I >> can focus fully on my new job. >> >> Thus *all* of my packages are looking for a new owner (I'm not >> actually orphaning them, but I *really* want to lower my load quite a >> bit). >> > > I'll take libgda and libgnomedb > Thanks! I've approved the rights you requested and released ownership, don't forget to claim ownership! Regards, Hans From j.w.r.degoede at hhs.nl Mon Sep 8 15:01:02 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 08 Sep 2008 17:01:02 +0200 Subject: Lonely packages looking for cosy new owner In-Reply-To: <20080908123103.GE1667@hmsendeavour.rdu.redhat.com> References: <48C5190F.7020500@hhs.nl> <20080908123103.GE1667@hmsendeavour.rdu.redhat.com> Message-ID: <48C53E2E.4020405@hhs.nl> Neil Horman wrote: > On Mon, Sep 08, 2008 at 02:22:39PM +0200, Hans de Goede wrote: >> Hi All, >> >> I still need to write a little blog post of this, but as from Sept 1st >> I've been hired by RedHat to work on anaconda (the installer). As such I >> would like to reduce my package load as much as possible so that I can >> focus fully on my new job. >> >> Thus *all* of my packages are looking for a new owner (I'm not actually >> orphaning them, but I *really* want to lower my load quite a bit). >> >> https://admin.fedoraproject.org/pkgdb/users/packages/jwrdegoede?acls=owner >> >> If you are willing to take over any let me know and I'll orphan them and >> you can pick them up. I'll be around for a long time to come to answer >> any questions and help with any issues with them, so don't hesitate! >> >> Thanks & Regards, >> >> Hans >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > Sorry, if I wasn't clear on this in my last response, but in addition to coda, > I'd also be happy to inherity its dependencies, rvm and rpc2 Thanks, I've released them all, so don't forget to claim ownership or they will be considered as orphans in the future. Regards, Hans From harald at redhat.com Mon Sep 8 15:01:13 2008 From: harald at redhat.com (Harald Hoyer) Date: Mon, 08 Sep 2008 17:01:13 +0200 Subject: Boot speedup with readahead In-Reply-To: <48C53B5E.3010500@redhat.com> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> Message-ID: Eric Sandeen schrieb: > Harald Hoyer wrote: >> Eric Sandeen schrieb: > >>> So when / how often does readahead-collector run now? >>> >>> Thanks, >>> -Eric >> Every month. >> >> /etc/cron.monthly/readahead-monthly.cron > > It'd be interesting to do a daily yum update / reboot and see how the > boot times look, graphed for a couple months. > > Will things degrade until the next collection run? I wonder if some > inotify magic might be interesting; if more than X% of the > previously-collected files have changed, then kick the collector on again? > > -Eric > hehe, yes, but how would you implement that? :) I don't think this is doable :) From pmatilai at laiskiainen.org Mon Sep 8 15:07:48 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Mon, 8 Sep 2008 18:07:48 +0300 (EEST) Subject: Boot speedup with readahead In-Reply-To: References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> Message-ID: On Mon, 8 Sep 2008, Harald Hoyer wrote: > Eric Sandeen schrieb: >> Harald Hoyer wrote: >>> Eric Sandeen schrieb: >> >>>> So when / how often does readahead-collector run now? >>>> >>>> Thanks, >>>> -Eric >>> Every month. >>> >>> /etc/cron.monthly/readahead-monthly.cron >> >> It'd be interesting to do a daily yum update / reboot and see how the >> boot times look, graphed for a couple months. >> >> Will things degrade until the next collection run? I wonder if some >> inotify magic might be interesting; if more than X% of the >> previously-collected files have changed, then kick the collector on again? >> >> -Eric >> > > hehe, yes, but how would you implement that? :) I don't think this is doable > :) A yum-readahead plugin could look at the readahead list after an upgrade and calculate if refreshing is needed. /me ducks and hides - Panu - From skvidal at fedoraproject.org Mon Sep 8 15:12:30 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 08 Sep 2008 11:12:30 -0400 Subject: Boot speedup with readahead In-Reply-To: References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> Message-ID: <1220886750.987.12.camel@rosebud> On Mon, 2008-09-08 at 18:07 +0300, Panu Matilainen wrote: > On Mon, 8 Sep 2008, Harald Hoyer wrote: > > > Eric Sandeen schrieb: > >> Harald Hoyer wrote: > >>> Eric Sandeen schrieb: > >> > >>>> So when / how often does readahead-collector run now? > >>>> > >>>> Thanks, > >>>> -Eric > >>> Every month. > >>> > >>> /etc/cron.monthly/readahead-monthly.cron > >> > >> It'd be interesting to do a daily yum update / reboot and see how the > >> boot times look, graphed for a couple months. > >> > >> Will things degrade until the next collection run? I wonder if some > >> inotify magic might be interesting; if more than X% of the > >> previously-collected files have changed, then kick the collector on again? > >> > >> -Eric > >> > > > > hehe, yes, but how would you implement that? :) I don't think this is doable > > :) > > A yum-readahead plugin could look at the readahead list after an upgrade > and calculate if refreshing is needed. > > /me ducks and hides it'd be like 10 lines long. -sv From jkeating at redhat.com Mon Sep 8 15:19:03 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 08 Sep 2008 08:19:03 -0700 Subject: To freeze, or not to freeze Message-ID: <1220887143.17700.9.camel@luminos.localdomain> A few weeks back the releng team made a schedule adjustment, to make up for lost rawhide time due to the intrusion. When we made that schedule adjustment, we had assumed having a working rawhide within days of that meeting, giving us a week or so worth of working rawhide to shake out any pre-beta bugs we wanted to. Unfortunately, while we were able to /attempt/ rawhide creation as scheduled, a series of software bugs and bad personnel timing has prevented those attempts from producing usable rawhide images until basically today (and today's are pretty shaky from what I hear). This is not so good, as without an installable rawhide, we don't get a good idea as to how the installer is working, and we miss out on a lot of 'initial install' testing of software on people's systems. We get a lot of "I upgraded from foo" type testing, which definitely has it's value, but I feel we're missing a pretty key part of the rawhide experience. The Beta freeze is set for Tomorrow. That means the content that would show up in tomorrow's rawhide would also be the content we use as the basis of Beta. Any changes after that would have to be ran through the releng/qa teams to be approved. Given the "fun" we had with Alpha, I really feel that it would be prudent to spend a few more unfrozen days with a hopefully continually working rawhide installer so that we can do some of that last minute testing of what's wrong before we freeze, and hopefully have a shorter and more productive freeze period. But this is just my opinion, and thus I'm putting this out there for discussion. Feature owners in particular, I'm interested in your opinions as to if you need a few more days to see what shape your features are in before we freeze. Ideally the week before a freeze would have been a slow down period, where large changes were avoided and bugfixing was focused on so that the Beta was useful. I feel like we didn't give you a chance to do this and it'll still feel like crash landing planes on the carrier deck when it come to features in Beta. I'm interested in what the rest of you think as well, both package owners and testers alike. If you think our schedule time would be better spent fixing and verifying things pre-freeze and adding an extra week to the schedule, or just freeze as things are, and potentially slip a week during the freeze to make everything usable for the Beta (or the third option, things are fine as they are, just freeze and release as scheduled and stop being so paranoid). What say you? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Sep 8 15:27:13 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 08 Sep 2008 08:27:13 -0700 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C5190F.7020500@hhs.nl> References: <48C5190F.7020500@hhs.nl> Message-ID: <1220887633.17700.10.camel@luminos.localdomain> On Mon, 2008-09-08 at 14:22 +0200, Hans de Goede wrote: > I still need to write a little blog post of this, but as from Sept 1st > I've been hired by RedHat to work on anaconda (the installer). I'm not going to take over any of your packages, but I did want to give you a big heartfelt welcome to the Red Hat team. I'm very excited to see you join the Anaconda team and look forward to working with you on a more regular basis. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Mon Sep 8 15:27:16 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 08 Sep 2008 11:27:16 -0400 Subject: Boot speedup with readahead In-Reply-To: <1220886750.987.12.camel@rosebud> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> Message-ID: <1220887636.5554.37.camel@aglarond.local> On Mon, 2008-09-08 at 11:12 -0400, Seth Vidal wrote: > On Mon, 2008-09-08 at 18:07 +0300, Panu Matilainen wrote: > > On Mon, 8 Sep 2008, Harald Hoyer wrote: > > > Eric Sandeen schrieb: > > >> Harald Hoyer wrote: > > >>> Eric Sandeen schrieb: > > >>>> So when / how often does readahead-collector run now? > > >>>> > > >>>> Thanks, > > >>>> -Eric > > >>> Every month. > > >>> > > >>> /etc/cron.monthly/readahead-monthly.cron > > >> > > >> It'd be interesting to do a daily yum update / reboot and see how the > > >> boot times look, graphed for a couple months. > > >> > > >> Will things degrade until the next collection run? I wonder if some > > >> inotify magic might be interesting; if more than X% of the > > >> previously-collected files have changed, then kick the collector on again? > > >> > > >> -Eric > > >> > > > > > > hehe, yes, but how would you implement that? :) I don't think this is doable > > > :) > > > > A yum-readahead plugin could look at the readahead list after an upgrade > > and calculate if refreshing is needed. > > > > /me ducks and hides > > it'd be like 10 lines long. And doing it this way would be more effective than cron as there are plenty of people (especially with laptops/desktops which aren't on all the time) for whom cron really isn't appropriate for anything that we actually care to have done Jeremy From limb at jcomserv.net Mon Sep 8 15:27:54 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 8 Sep 2008 10:27:54 -0500 (CDT) Subject: To freeze, or not to freeze In-Reply-To: <1220887143.17700.9.camel@luminos.localdomain> References: <1220887143.17700.9.camel@luminos.localdomain> Message-ID: <48483.198.175.55.5.1220887674.squirrel@mail.jcomserv.net> > A few weeks back the releng team made a schedule adjustment, to make up > for lost rawhide time due to the intrusion. When we made that schedule > adjustment, we had assumed having a working rawhide within days of that > meeting, giving us a week or so worth of working rawhide to shake out > any pre-beta bugs we wanted to. > > Unfortunately, while we were able to /attempt/ rawhide creation as > scheduled, a series of software bugs and bad personnel timing has > prevented those attempts from producing usable rawhide images until > basically today (and today's are pretty shaky from what I hear). This > is not so good, as without an installable rawhide, we don't get a good > idea as to how the installer is working, and we miss out on a lot of > 'initial install' testing of software on people's systems. We get a lot > of "I upgraded from foo" type testing, which definitely has it's value, > but I feel we're missing a pretty key part of the rawhide experience. > > The Beta freeze is set for Tomorrow. That means the content that would > show up in tomorrow's rawhide would also be the content we use as the > basis of Beta. Any changes after that would have to be ran through the > releng/qa teams to be approved. > > Given the "fun" we had with Alpha, I really feel that it would be > prudent to spend a few more unfrozen days with a hopefully continually > working rawhide installer so that we can do some of that last minute > testing of what's wrong before we freeze, and hopefully have a shorter > and more productive freeze period. But this is just my opinion, and > thus I'm putting this out there for discussion. > > Feature owners in particular, I'm interested in your opinions as to if > you need a few more days to see what shape your features are in before > we freeze. Ideally the week before a freeze would have been a slow down > period, where large changes were avoided and bugfixing was focused on so > that the Beta was useful. I feel like we didn't give you a chance to do > this and it'll still feel like crash landing planes on the carrier deck > when it come to features in Beta. > > I'm interested in what the rest of you think as well, both package > owners and testers alike. If you think our schedule time would be > better spent fixing and verifying things pre-freeze and adding an extra > week to the schedule, or just freeze as things are, and potentially slip > a week during the freeze to make everything usable for the Beta (or the > third option, things are fine as they are, just freeze and release as > scheduled and stop being so paranoid). > > What say you? Wait a bit, maybe slip the release a week if you have to. Better slippage than suckage, IMHO. After the intrusion, I think users will understand. > -- > Jesse Keating > Fedora -- Freedom?? is a feature! > identi.ca: http://identi.ca/jkeating > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From orion at cora.nwra.com Mon Sep 8 15:31:25 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 08 Sep 2008 09:31:25 -0600 Subject: To freeze, or not to freeze In-Reply-To: <1220887143.17700.9.camel@luminos.localdomain> References: <1220887143.17700.9.camel@luminos.localdomain> Message-ID: <48C5454D.3070904@cora.nwra.com> Jesse Keating wrote: > Given the "fun" we had with Alpha, I really feel that it would be > prudent to spend a few more unfrozen days with a hopefully continually > working rawhide installer so that we can do some of that last minute > testing of what's wrong before we freeze, and hopefully have a shorter > and more productive freeze period. But this is just my opinion, and > thus I'm putting this out there for discussion. > What say you? Installer issues affect me a lot - I do all of my "upgrades" as fresh installs. Today's (and the last couple day's) rawhide installs are failing with: running /sbin/loader failed to read /lib/modules/module-info We need a beta with a working installer. -- 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 bruno at wolff.to Mon Sep 8 15:37:08 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 8 Sep 2008 10:37:08 -0500 Subject: Getting minor security issue with "alliance" fixed? Message-ID: <20080908153708.GA21489@wolff.to> About four weeks ago a reported (#459336) a minor security issue with the alliance package. It incorrectly modifies the path to put the current working directory (via an empty item in the list) in it. At the time I reported things were kind of crazy, but I would have expected some action on the problem by this time. The fix can't be that complicated even if something is generating the profile files, so I was hoping maybe somebody could take a look at this even if the primary maintainer is busy right now. From clumens at redhat.com Mon Sep 8 15:40:10 2008 From: clumens at redhat.com (Chris Lumens) Date: Mon, 8 Sep 2008 11:40:10 -0400 Subject: To freeze, or not to freeze In-Reply-To: <48C5454D.3070904@cora.nwra.com> References: <1220887143.17700.9.camel@luminos.localdomain> <48C5454D.3070904@cora.nwra.com> Message-ID: <20080908154010.GI4575@localhost.localdomain> > Installer issues affect me a lot - I do all of my "upgrades" as fresh > installs. Today's (and the last couple day's) rawhide installs are > failing with: > > running /sbin/loader > failed to read /lib/modules/module-info > > We need a beta with a working installer. If you've been seeing something for several days, file it or it's not gonna get fixed. We don't know about every single bug and I'm no mind reader. - Chris From lyos.gemininorezel at gmail.com Mon Sep 8 15:43:07 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Mon, 08 Sep 2008 11:43:07 -0400 Subject: To freeze, or not to freeze In-Reply-To: <1220887143.17700.9.camel@luminos.localdomain> References: <1220887143.17700.9.camel@luminos.localdomain> Message-ID: <48C5480B.9000706@gmail.com> Jesse Keating wrote: > A few weeks back the releng team made a schedule adjustment, to make up > for lost rawhide time due to the intrusion. When we made that schedule > adjustment, we had assumed having a working rawhide within days of that > meeting, giving us a week or so worth of working rawhide to shake out > any pre-beta bugs we wanted to. > > Unfortunately, while we were able to /attempt/ rawhide creation as > scheduled, a series of software bugs and bad personnel timing has > prevented those attempts from producing usable rawhide images until > basically today (and today's are pretty shaky from what I hear). This > is not so good, as without an installable rawhide, we don't get a good > idea as to how the installer is working, and we miss out on a lot of > 'initial install' testing of software on people's systems. We get a lot > of "I upgraded from foo" type testing, which definitely has it's value, > but I feel we're missing a pretty key part of the rawhide experience. > > The Beta freeze is set for Tomorrow. That means the content that would > show up in tomorrow's rawhide would also be the content we use as the > basis of Beta. Any changes after that would have to be ran through the > releng/qa teams to be approved. > > Given the "fun" we had with Alpha, I really feel that it would be > prudent to spend a few more unfrozen days with a hopefully continually > working rawhide installer so that we can do some of that last minute > testing of what's wrong before we freeze, and hopefully have a shorter > and more productive freeze period. But this is just my opinion, and > thus I'm putting this out there for discussion. > > Feature owners in particular, I'm interested in your opinions as to if > you need a few more days to see what shape your features are in before > we freeze. Ideally the week before a freeze would have been a slow down > period, where large changes were avoided and bugfixing was focused on so > that the Beta was useful. I feel like we didn't give you a chance to do > this and it'll still feel like crash landing planes on the carrier deck > when it come to features in Beta. > > I'm interested in what the rest of you think as well, both package > owners and testers alike. If you think our schedule time would be > better spent fixing and verifying things pre-freeze and adding an extra > week to the schedule, or just freeze as things are, and potentially slip > a week during the freeze to make everything usable for the Beta (or the > third option, things are fine as they are, just freeze and release as > scheduled and stop being so paranoid). > > What say you? Question: How will this slippage affect F11 (if at all)? Will it be possible to somehow make up the time lost? Honestly... it's better to slip a few weeks than release something horribly buggy, but I still think we should try to avoid pushing the release so far back... that all future releases have to slip as well. Lyos Gemini Norezel From jkeating at redhat.com Mon Sep 8 15:49:16 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 08 Sep 2008 08:49:16 -0700 Subject: To freeze, or not to freeze In-Reply-To: <48C5480B.9000706@gmail.com> References: <1220887143.17700.9.camel@luminos.localdomain> <48C5480B.9000706@gmail.com> Message-ID: <1220888956.17700.16.camel@luminos.localdomain> On Mon, 2008-09-08 at 11:43 -0400, Lyos Gemini Norezel wrote: > > Question: How will this slippage affect F11 (if at all)? > Will it be possible to somehow make up the time lost? The current discussion is that we'll find ways to hit the expected F11 target date (first part of May) by shortening the schedule where we can to make up for the slips in F10. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Mon Sep 8 15:49:44 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 08 Sep 2008 11:49:44 -0400 Subject: To freeze, or not to freeze In-Reply-To: <48483.198.175.55.5.1220887674.squirrel@mail.jcomserv.net> References: <1220887143.17700.9.camel@luminos.localdomain> <48483.198.175.55.5.1220887674.squirrel@mail.jcomserv.net> Message-ID: <1220888984.987.25.camel@rosebud> On Mon, 2008-09-08 at 10:27 -0500, Jon Ciesla wrote: > > A few weeks back the releng team made a schedule adjustment, to make up > > for lost rawhide time due to the intrusion. When we made that schedule > > adjustment, we had assumed having a working rawhide within days of that > > meeting, giving us a week or so worth of working rawhide to shake out > > any pre-beta bugs we wanted to. > > > > Unfortunately, while we were able to /attempt/ rawhide creation as > > scheduled, a series of software bugs and bad personnel timing has > > prevented those attempts from producing usable rawhide images until > > basically today (and today's are pretty shaky from what I hear). This > > is not so good, as without an installable rawhide, we don't get a good > > idea as to how the installer is working, and we miss out on a lot of > > 'initial install' testing of software on people's systems. We get a lot > > of "I upgraded from foo" type testing, which definitely has it's value, > > but I feel we're missing a pretty key part of the rawhide experience. > > > > The Beta freeze is set for Tomorrow. That means the content that would > > show up in tomorrow's rawhide would also be the content we use as the > > basis of Beta. Any changes after that would have to be ran through the > > releng/qa teams to be approved. > > > > Given the "fun" we had with Alpha, I really feel that it would be > > prudent to spend a few more unfrozen days with a hopefully continually > > working rawhide installer so that we can do some of that last minute > > testing of what's wrong before we freeze, and hopefully have a shorter > > and more productive freeze period. But this is just my opinion, and > > thus I'm putting this out there for discussion. > > > > Feature owners in particular, I'm interested in your opinions as to if > > you need a few more days to see what shape your features are in before > > we freeze. Ideally the week before a freeze would have been a slow down > > period, where large changes were avoided and bugfixing was focused on so > > that the Beta was useful. I feel like we didn't give you a chance to do > > this and it'll still feel like crash landing planes on the carrier deck > > when it come to features in Beta. > > > > I'm interested in what the rest of you think as well, both package > > owners and testers alike. If you think our schedule time would be > > better spent fixing and verifying things pre-freeze and adding an extra > > week to the schedule, or just freeze as things are, and potentially slip > > a week during the freeze to make everything usable for the Beta (or the > > third option, things are fine as they are, just freeze and release as > > scheduled and stop being so paranoid). > > > > What say you? > > Wait a bit, maybe slip the release a week if you have to. Better slippage > than suckage, IMHO. After the intrusion, I think users will understand. slipping the release a week gets complicated as we get dangerously close to thanksgiving in the US which takes a huge number of contributors out of the world. -sv From orion at cora.nwra.com Mon Sep 8 15:54:20 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 08 Sep 2008 09:54:20 -0600 Subject: To freeze, or not to freeze In-Reply-To: <20080908154010.GI4575@localhost.localdomain> References: <1220887143.17700.9.camel@luminos.localdomain> <48C5454D.3070904@cora.nwra.com> <20080908154010.GI4575@localhost.localdomain> Message-ID: <48C54AAC.2090701@cora.nwra.com> Chris Lumens wrote: >> Installer issues affect me a lot - I do all of my "upgrades" as fresh >> installs. Today's (and the last couple day's) rawhide installs are >> failing with: >> >> running /sbin/loader >> failed to read /lib/modules/module-info >> >> We need a beta with a working installer. > > If you've been seeing something for several days, file it or it's not > gonna get fixed. We don't know about every single bug and I'm no mind > reader. > > - Chris > Sorry, I usually do (72 anaconda bugs reported so far....), but there have been some other issues as well that I didn't know if they were related or not. #73: https://bugzilla.redhat.com/show_bug.cgi?id=461496 Seems to x86_64 only... -- 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 rc040203 at freenet.de Mon Sep 8 15:53:12 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 08 Sep 2008 17:53:12 +0200 Subject: To freeze, or not to freeze In-Reply-To: <1220887143.17700.9.camel@luminos.localdomain> References: <1220887143.17700.9.camel@luminos.localdomain> Message-ID: <1220889192.6502.42.camel@beck.corsepiu.local> On Mon, 2008-09-08 at 08:19 -0700, Jesse Keating wrote: > I'm interested in what the rest of you think as well, both package > owners and testers alike. If you think our schedule time would be > better spent fixing and verifying things pre-freeze and adding an extra > week to the schedule, or just freeze as things are, and potentially slip > a week during the freeze to make everything usable for the Beta (or the > third option, things are fine as they are, just freeze and release as > scheduled and stop being so paranoid). > > What say you? As I already wrote last week, I'd recommend to shift the whole release schedule by the same amount of time the FC8/FC9 hiatus takes. At least, as far as I my packages are concerned, the hiatus has had a major impact, imposing a major slowdown on development, partially resembling to a "complete still-stand". Ralf From skvidal at fedoraproject.org Mon Sep 8 16:02:13 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 08 Sep 2008 12:02:13 -0400 Subject: Boot speedup with readahead In-Reply-To: <1220887636.5554.37.camel@aglarond.local> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> Message-ID: <1220889733.987.33.camel@rosebud> On Mon, 2008-09-08 at 11:27 -0400, Jeremy Katz wrote: > And doing it this way would be more effective than cron as there are > plenty of people (especially with laptops/desktops which aren't on all > the time) for whom cron really isn't appropriate for anything that we > actually care to have done > What package does the readahead cron-monthly job live in? -sv From ajax at redhat.com Mon Sep 8 16:04:22 2008 From: ajax at redhat.com (Adam Jackson) Date: Mon, 08 Sep 2008 12:04:22 -0400 Subject: To freeze, or not to freeze In-Reply-To: <1220887143.17700.9.camel@luminos.localdomain> References: <1220887143.17700.9.camel@luminos.localdomain> Message-ID: <1220889862.3170.69.camel@atropine.boston.devel.redhat.com> On Mon, 2008-09-08 at 08:19 -0700, Jesse Keating wrote: > Feature owners in particular, I'm interested in your opinions as to if > you need a few more days to see what shape your features are in before > we freeze. Ideally the week before a freeze would have been a slow down > period, where large changes were avoided and bugfixing was focused on so > that the Beta was useful. I feel like we didn't give you a chance to do > this and it'll still feel like crash landing planes on the carrier deck > when it come to features in Beta. As far as the plymouth and drm changes are concerned, having a few more days to sand down the larger splinters would certainly be appreciated. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From gemi at bluewin.ch Mon Sep 8 16:04:35 2008 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Mon, 08 Sep 2008 18:04:35 +0200 Subject: GNU Common Lisp (gcl) - need a new security context? In-Reply-To: References: <20080905194430.2148E61A32C@hormel.redhat.com> Message-ID: <1220889875.27444.9.camel@localhost.localdomain> On Fri, 2008-09-05 at 16:54 -0400, David A. Wheeler wrote: > Dropping gcl is a bad idea. gcl generates much better code in many > cases; > dropping makes Fedora bad for running Common Lisp (CL) applications. > There are a lot of CL programs, and CL is still important; "Practical > Common Lisp" > was published 2005 and was a really popular book. I am not unwilling to continue with GCL. However I would need some help from people knowing about these issues (on several architectures) and how to fix them. BTW, SELinux is only one issue. GCL doesn't compile even with SELinux disabled (randomized addresses etc...) From sandeen at redhat.com Mon Sep 8 16:08:10 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Mon, 08 Sep 2008 11:08:10 -0500 Subject: Boot speedup with readahead In-Reply-To: <1220889733.987.33.camel@rosebud> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220889733.987.33.camel@rosebud> Message-ID: <48C54DEA.4070105@redhat.com> Seth Vidal wrote: > On Mon, 2008-09-08 at 11:27 -0400, Jeremy Katz wrote: > >> And doing it this way would be more effective than cron as there are >> plenty of people (especially with laptops/desktops which aren't on all >> the time) for whom cron really isn't appropriate for anything that we >> actually care to have done >> > > What package does the readahead cron-monthly job live in? > > -sv > > it's in readahead: [root at box]# rpm -ql readahead | grep cron /etc/cron.daily/readahead.cron /etc/cron.monthly/readahead-monthly.cron But we should probably wait a week to see what magic Arjan has before we go off re-architecting any of this :) -Eric From aph at redhat.com Mon Sep 8 16:11:57 2008 From: aph at redhat.com (Andrew Haley) Date: Mon, 08 Sep 2008 17:11:57 +0100 Subject: GNU Common Lisp (gcl) - need a new security context? In-Reply-To: <1220889875.27444.9.camel@localhost.localdomain> References: <20080905194430.2148E61A32C@hormel.redhat.com> <1220889875.27444.9.camel@localhost.localdomain> Message-ID: <48C54ECD.3080402@redhat.com> G?rard Milmeister wrote: > On Fri, 2008-09-05 at 16:54 -0400, David A. Wheeler wrote: >> Dropping gcl is a bad idea. gcl generates much better code in many >> cases; >> dropping makes Fedora bad for running Common Lisp (CL) applications. >> There are a lot of CL programs, and CL is still important; "Practical >> Common Lisp" >> was published 2005 and was a really popular book. > I am not unwilling to continue with GCL. However I would need some help > from people knowing about these issues (on several architectures) and > how to fix them. OK. > BTW, SELinux is only one issue. GCL doesn't compile even with SELinux > disabled (randomized addresses etc...) Hmm. This is because GCL saves its compiled code and expects it to be loaded at the same address? Andrew. From forum at ru.bir.ru Mon Sep 8 16:14:02 2008 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Mon, 08 Sep 2008 20:14:02 +0400 Subject: Why eGroupWare is not in Fedora? Message-ID: <48C54F4A.5090503@ru.bir.ru> http://eGroupWare.org It is sponsored by RedHat. Download page present links to src.rpm (from openSUSE buildservice :) ) so I think it is not hard porting for Fedora. Any legal issues? On first look it is GPLv2 and GPLv3. So, why it is not here (I also check reviews in progress)? Or it just wait maintainer and I can try make review request? With best regards, Pavel Alexeev (aka Pahan-Hubbitus). From jakub at redhat.com Mon Sep 8 16:16:23 2008 From: jakub at redhat.com (Jakub Jelinek) Date: Mon, 8 Sep 2008 12:16:23 -0400 Subject: GNU Common Lisp (gcl) - need a new security context? In-Reply-To: <1220889875.27444.9.camel@localhost.localdomain> References: <20080905194430.2148E61A32C@hormel.redhat.com> <1220889875.27444.9.camel@localhost.localdomain> Message-ID: <20080908161623.GE17472@hs20-bc2-1.build.redhat.com> On Mon, Sep 08, 2008 at 06:04:35PM +0200, G?rard Milmeister wrote: > On Fri, 2008-09-05 at 16:54 -0400, David A. Wheeler wrote: > > Dropping gcl is a bad idea. gcl generates much better code in many > > cases; > > dropping makes Fedora bad for running Common Lisp (CL) applications. > > There are a lot of CL programs, and CL is still important; "Practical > > Common Lisp" > > was published 2005 and was a really popular book. > I am not unwilling to continue with GCL. However I would need some help > from people knowing about these issues (on several architectures) and > how to fix them. See what libffi does, in particular the SELinux related stuff in closures.c. Jakub From skvidal at fedoraproject.org Mon Sep 8 16:15:49 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 08 Sep 2008 12:15:49 -0400 Subject: Boot speedup with readahead In-Reply-To: <48C54DEA.4070105@redhat.com> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220889733.987.33.camel@rosebud> <48C54DEA.4070105@redhat.com> Message-ID: <1220890549.987.35.camel@rosebud> On Mon, 2008-09-08 at 11:08 -0500, Eric Sandeen wrote: > Seth Vidal wrote: > > On Mon, 2008-09-08 at 11:27 -0400, Jeremy Katz wrote: > > > >> And doing it this way would be more effective than cron as there are > >> plenty of people (especially with laptops/desktops which aren't on all > >> the time) for whom cron really isn't appropriate for anything that we > >> actually care to have done > >> > > > > What package does the readahead cron-monthly job live in? > > > > -sv > > > > > > it's in readahead: > > [root at box]# rpm -ql readahead | grep cron > /etc/cron.daily/readahead.cron > /etc/cron.monthly/readahead-monthly.cron > > But we should probably wait a week to see what magic Arjan has before we > go off re-architecting any of this :) okay :) -sv From subhodip at fedoraproject.org Mon Sep 8 16:17:40 2008 From: subhodip at fedoraproject.org (subhodip biswas) Date: Mon, 8 Sep 2008 21:47:40 +0530 Subject: error while using koji Message-ID: <539333cb0809080917k435f3dc8s415b5efac60b5a59@mail.gmail.com> hi ! i get this error when using koji : Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert certificate revoked'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl handshake failure')] why is this so ? -- Regards Subhodip Biswas GPG key : FAEA34AB Server : pgp.mit.edu http://subhodipbiswas.wordpress.com http:/www.fedoraproject.org/wiki/SubhodipBiswas From skvidal at fedoraproject.org Mon Sep 8 16:17:13 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 08 Sep 2008 12:17:13 -0400 Subject: Why eGroupWare is not in Fedora? In-Reply-To: <48C54F4A.5090503@ru.bir.ru> References: <48C54F4A.5090503@ru.bir.ru> Message-ID: <1220890633.987.38.camel@rosebud> On Mon, 2008-09-08 at 20:14 +0400, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > http://eGroupWare.org > It is sponsored by RedHat. Download page present links to src.rpm (from > openSUSE buildservice > :) ) so > I think it is not hard porting for Fedora. > Any legal issues? On first look it is GPLv2 and GPLv3. So, why it is not > here (I also check reviews in progress)? Or it just wait maintainer and > I can try make review request? > I think it just needs a maintainer/packager. Feel free to apply for it. thanks! -sv From limb at jcomserv.net Mon Sep 8 16:31:55 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 8 Sep 2008 11:31:55 -0500 (CDT) Subject: To freeze, or not to freeze In-Reply-To: <1220888984.987.25.camel@rosebud> References: <1220887143.17700.9.camel@luminos.localdomain> <48483.198.175.55.5.1220887674.squirrel@mail.jcomserv.net> <1220888984.987.25.camel@rosebud> Message-ID: <24415.198.175.55.5.1220891515.squirrel@mail.jcomserv.net> > On Mon, 2008-09-08 at 10:27 -0500, Jon Ciesla wrote: >> > A few weeks back the releng team made a schedule adjustment, to make >> up >> > for lost rawhide time due to the intrusion. When we made that >> schedule >> > adjustment, we had assumed having a working rawhide within days of >> that >> > meeting, giving us a week or so worth of working rawhide to shake out >> > any pre-beta bugs we wanted to. >> > >> > Unfortunately, while we were able to /attempt/ rawhide creation as >> > scheduled, a series of software bugs and bad personnel timing has >> > prevented those attempts from producing usable rawhide images until >> > basically today (and today's are pretty shaky from what I hear). This >> > is not so good, as without an installable rawhide, we don't get a good >> > idea as to how the installer is working, and we miss out on a lot of >> > 'initial install' testing of software on people's systems. We get a >> lot >> > of "I upgraded from foo" type testing, which definitely has it's >> value, >> > but I feel we're missing a pretty key part of the rawhide experience. >> > >> > The Beta freeze is set for Tomorrow. That means the content that >> would >> > show up in tomorrow's rawhide would also be the content we use as the >> > basis of Beta. Any changes after that would have to be ran through >> the >> > releng/qa teams to be approved. >> > >> > Given the "fun" we had with Alpha, I really feel that it would be >> > prudent to spend a few more unfrozen days with a hopefully continually >> > working rawhide installer so that we can do some of that last minute >> > testing of what's wrong before we freeze, and hopefully have a shorter >> > and more productive freeze period. But this is just my opinion, and >> > thus I'm putting this out there for discussion. >> > >> > Feature owners in particular, I'm interested in your opinions as to if >> > you need a few more days to see what shape your features are in before >> > we freeze. Ideally the week before a freeze would have been a slow >> down >> > period, where large changes were avoided and bugfixing was focused on >> so >> > that the Beta was useful. I feel like we didn't give you a chance to >> do >> > this and it'll still feel like crash landing planes on the carrier >> deck >> > when it come to features in Beta. >> > >> > I'm interested in what the rest of you think as well, both package >> > owners and testers alike. If you think our schedule time would be >> > better spent fixing and verifying things pre-freeze and adding an >> extra >> > week to the schedule, or just freeze as things are, and potentially >> slip >> > a week during the freeze to make everything usable for the Beta (or >> the >> > third option, things are fine as they are, just freeze and release as >> > scheduled and stop being so paranoid). >> > >> > What say you? >> >> Wait a bit, maybe slip the release a week if you have to. Better >> slippage >> than suckage, IMHO. After the intrusion, I think users will understand. > > slipping the release a week gets complicated as we get dangerously close > to thanksgiving in the US which takes a huge number of contributors out > of the world. Are you suggesting that after a large meal containing high quantities of starch, tryptophan, and alcohol, I might not be at my best? For shame. ;) > -sv > > -- novus ordo absurdum From skvidal at fedoraproject.org Mon Sep 8 16:32:47 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 08 Sep 2008 12:32:47 -0400 Subject: To freeze, or not to freeze In-Reply-To: <24415.198.175.55.5.1220891515.squirrel@mail.jcomserv.net> References: <1220887143.17700.9.camel@luminos.localdomain> <48483.198.175.55.5.1220887674.squirrel@mail.jcomserv.net> <1220888984.987.25.camel@rosebud> <24415.198.175.55.5.1220891515.squirrel@mail.jcomserv.net> Message-ID: <1220891567.987.40.camel@rosebud> On Mon, 2008-09-08 at 11:31 -0500, Jon Ciesla wrote: > > On Mon, 2008-09-08 at 10:27 -0500, Jon Ciesla wrote: > >> > A few weeks back the releng team made a schedule adjustment, to make > >> up > >> > for lost rawhide time due to the intrusion. When we made that > >> schedule > >> > adjustment, we had assumed having a working rawhide within days of > >> that > >> > meeting, giving us a week or so worth of working rawhide to shake out > >> > any pre-beta bugs we wanted to. > >> > > >> > Unfortunately, while we were able to /attempt/ rawhide creation as > >> > scheduled, a series of software bugs and bad personnel timing has > >> > prevented those attempts from producing usable rawhide images until > >> > basically today (and today's are pretty shaky from what I hear). This > >> > is not so good, as without an installable rawhide, we don't get a good > >> > idea as to how the installer is working, and we miss out on a lot of > >> > 'initial install' testing of software on people's systems. We get a > >> lot > >> > of "I upgraded from foo" type testing, which definitely has it's > >> value, > >> > but I feel we're missing a pretty key part of the rawhide experience. > >> > > >> > The Beta freeze is set for Tomorrow. That means the content that > >> would > >> > show up in tomorrow's rawhide would also be the content we use as the > >> > basis of Beta. Any changes after that would have to be ran through > >> the > >> > releng/qa teams to be approved. > >> > > >> > Given the "fun" we had with Alpha, I really feel that it would be > >> > prudent to spend a few more unfrozen days with a hopefully continually > >> > working rawhide installer so that we can do some of that last minute > >> > testing of what's wrong before we freeze, and hopefully have a shorter > >> > and more productive freeze period. But this is just my opinion, and > >> > thus I'm putting this out there for discussion. > >> > > >> > Feature owners in particular, I'm interested in your opinions as to if > >> > you need a few more days to see what shape your features are in before > >> > we freeze. Ideally the week before a freeze would have been a slow > >> down > >> > period, where large changes were avoided and bugfixing was focused on > >> so > >> > that the Beta was useful. I feel like we didn't give you a chance to > >> do > >> > this and it'll still feel like crash landing planes on the carrier > >> deck > >> > when it come to features in Beta. > >> > > >> > I'm interested in what the rest of you think as well, both package > >> > owners and testers alike. If you think our schedule time would be > >> > better spent fixing and verifying things pre-freeze and adding an > >> extra > >> > week to the schedule, or just freeze as things are, and potentially > >> slip > >> > a week during the freeze to make everything usable for the Beta (or > >> the > >> > third option, things are fine as they are, just freeze and release as > >> > scheduled and stop being so paranoid). > >> > > >> > What say you? > >> > >> Wait a bit, maybe slip the release a week if you have to. Better > >> slippage > >> than suckage, IMHO. After the intrusion, I think users will understand. > > > > slipping the release a week gets complicated as we get dangerously close > > to thanksgiving in the US which takes a huge number of contributors out > > of the world. > > Are you suggesting that after a large meal containing high quantities of > starch, tryptophan, and alcohol, I might not be at my best? > > For shame. ;) No, I'm saying most of us don't want to work through that weekend. I know I don't. :) -sv From limb at jcomserv.net Mon Sep 8 16:38:03 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 8 Sep 2008 11:38:03 -0500 (CDT) Subject: To freeze, or not to freeze In-Reply-To: <1220891567.987.40.camel@rosebud> References: <1220887143.17700.9.camel@luminos.localdomain> <48483.198.175.55.5.1220887674.squirrel@mail.jcomserv.net> <1220888984.987.25.camel@rosebud> <24415.198.175.55.5.1220891515.squirrel@mail.jcomserv.net> <1220891567.987.40.camel@rosebud> Message-ID: <49054.198.175.55.5.1220891883.squirrel@mail.jcomserv.net> > On Mon, 2008-09-08 at 11:31 -0500, Jon Ciesla wrote: >> > On Mon, 2008-09-08 at 10:27 -0500, Jon Ciesla wrote: >> >> > A few weeks back the releng team made a schedule adjustment, to >> make >> >> up >> >> > for lost rawhide time due to the intrusion. When we made that >> >> schedule >> >> > adjustment, we had assumed having a working rawhide within days of >> >> that >> >> > meeting, giving us a week or so worth of working rawhide to shake >> out >> >> > any pre-beta bugs we wanted to. >> >> > >> >> > Unfortunately, while we were able to /attempt/ rawhide creation as >> >> > scheduled, a series of software bugs and bad personnel timing has >> >> > prevented those attempts from producing usable rawhide images until >> >> > basically today (and today's are pretty shaky from what I hear). >> This >> >> > is not so good, as without an installable rawhide, we don't get a >> good >> >> > idea as to how the installer is working, and we miss out on a lot >> of >> >> > 'initial install' testing of software on people's systems. We get >> a >> >> lot >> >> > of "I upgraded from foo" type testing, which definitely has it's >> >> value, >> >> > but I feel we're missing a pretty key part of the rawhide >> experience. >> >> > >> >> > The Beta freeze is set for Tomorrow. That means the content that >> >> would >> >> > show up in tomorrow's rawhide would also be the content we use as >> the >> >> > basis of Beta. Any changes after that would have to be ran through >> >> the >> >> > releng/qa teams to be approved. >> >> > >> >> > Given the "fun" we had with Alpha, I really feel that it would be >> >> > prudent to spend a few more unfrozen days with a hopefully >> continually >> >> > working rawhide installer so that we can do some of that last >> minute >> >> > testing of what's wrong before we freeze, and hopefully have a >> shorter >> >> > and more productive freeze period. But this is just my opinion, >> and >> >> > thus I'm putting this out there for discussion. >> >> > >> >> > Feature owners in particular, I'm interested in your opinions as to >> if >> >> > you need a few more days to see what shape your features are in >> before >> >> > we freeze. Ideally the week before a freeze would have been a slow >> >> down >> >> > period, where large changes were avoided and bugfixing was focused >> on >> >> so >> >> > that the Beta was useful. I feel like we didn't give you a chance >> to >> >> do >> >> > this and it'll still feel like crash landing planes on the carrier >> >> deck >> >> > when it come to features in Beta. >> >> > >> >> > I'm interested in what the rest of you think as well, both package >> >> > owners and testers alike. If you think our schedule time would be >> >> > better spent fixing and verifying things pre-freeze and adding an >> >> extra >> >> > week to the schedule, or just freeze as things are, and potentially >> >> slip >> >> > a week during the freeze to make everything usable for the Beta (or >> >> the >> >> > third option, things are fine as they are, just freeze and release >> as >> >> > scheduled and stop being so paranoid). >> >> > >> >> > What say you? >> >> >> >> Wait a bit, maybe slip the release a week if you have to. Better >> >> slippage >> >> than suckage, IMHO. After the intrusion, I think users will >> understand. >> > >> > slipping the release a week gets complicated as we get dangerously >> close >> > to thanksgiving in the US which takes a huge number of contributors >> out >> > of the world. >> >> Are you suggesting that after a large meal containing high quantities of >> starch, tryptophan, and alcohol, I might not be at my best? >> >> For shame. ;) > > No, I'm saying most of us don't want to work through that weekend. > > I know I don't. :) Agreed and seconded. Would have made for some memorable cvs commit messages, though. I think we could easily make up the time between F10 and F11 without slipping F11, though. Especially if there isn't another intrusion. We just might have a really shaky alpha. So what? It's an alpha. > -sv > > -- novus ordo absurdum From mikeb at redhat.com Mon Sep 8 16:42:25 2008 From: mikeb at redhat.com (Mike Bonnet) Date: Mon, 08 Sep 2008 12:42:25 -0400 Subject: error while using koji In-Reply-To: <539333cb0809080917k435f3dc8s415b5efac60b5a59@mail.gmail.com> References: <539333cb0809080917k435f3dc8s415b5efac60b5a59@mail.gmail.com> Message-ID: <1220892145.15415.4.camel@maunalani.home> On Mon, 2008-09-08 at 21:47 +0530, subhodip biswas wrote: > hi ! > > i get this error when using koji : > Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert certificate > revoked'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl handshake > failure')] > > > why is this so ? 'sslv3 alert certificate revoked' All old FAS certificates were recently revoked. You need to download a new client certificate from FAS. From limb at jcomserv.net Mon Sep 8 16:54:00 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Mon, 8 Sep 2008 11:54:00 -0500 (CDT) Subject: $arch.newkey mirrors In-Reply-To: References: <48C4E6AF.6080203@cohtech.com> Message-ID: <51093.198.175.55.5.1220892840.squirrel@mail.jcomserv.net> > Howard Wilkinson cohtech.com> writes: >> HOWEVER, on all of the mirrors I have looked at (which is a small >> sample) these directory trees exist but are empty. > > They're nonempty at sunsite.mff.cuni.cz. Did not, but do now see them at mirror.hiwaay.net. > Kevin Kofler > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From lyos.gemininorezel at gmail.com Mon Sep 8 16:59:12 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Mon, 08 Sep 2008 12:59:12 -0400 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C5369E.8000105@gmail.com> References: <48C5190F.7020500@hhs.nl> <48C5369E.8000105@gmail.com> Message-ID: <48C559E0.80300@gmail.com> Lyos Gemini Norezel wrote: > Hans de Goede wrote: >> Hi All, >> >> I still need to write a little blog post of this, but as from Sept >> 1st I've been hired by RedHat to work on anaconda (the installer). As >> such I would like to reduce my package load as much as possible so >> that I can focus fully on my new job. >> >> Thus *all* of my packages are looking for a new owner (I'm not >> actually orphaning them, but I *really* want to lower my load quite a >> bit). >> >> https://admin.fedoraproject.org/pkgdb/users/packages/jwrdegoede?acls=owner >> >> >> If you are willing to take over any let me know and I'll orphan them >> and you can pick them up. I'll be around for a long time to come to >> answer any questions and help with any issues with them, so don't >> hesitate! >> >> Thanks & Regards, >> >> Hans > > I'd like to take over: arj, id3lib, ksensors, libogg, libtheora, and > libvorbis. > > Thanks, > Lyos Gemini Norezel > Ok... pending any objections... I've taken over ksensors, libtheora, and libvorbis. I've also left all current acls as they were. I'm hoping most of the comaintainers will be willing to continue comaintaining these packages. Lyos Gemini Norezel From dennis at ausil.us Mon Sep 8 16:58:45 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 8 Sep 2008 11:58:45 -0500 Subject: error while using koji In-Reply-To: <1220892145.15415.4.camel@maunalani.home> References: <539333cb0809080917k435f3dc8s415b5efac60b5a59@mail.gmail.com> <1220892145.15415.4.camel@maunalani.home> Message-ID: <200809081200.44146.dennis@ausil.us> On Monday 08 September 2008 11:42:25 am Mike Bonnet wrote: > On Mon, 2008-09-08 at 21:47 +0530, subhodip biswas wrote: > > hi ! > > > > i get this error when using koji : > > Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert certificate > > revoked'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl handshake > > failure')] > > > > > > why is this so ? > > 'sslv3 alert certificate revoked' > > All old FAS certificates were recently revoked. You need to download a > new client certificate from FAS. also you can only have a single certificate now. revoked means that you got another cert after you got the one that your trying to use. and the old one was revoked. please use the most recent cert that you have downloaded. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From nhorman at redhat.com Mon Sep 8 17:05:22 2008 From: nhorman at redhat.com (Neil Horman) Date: Mon, 8 Sep 2008 13:05:22 -0400 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C53E2E.4020405@hhs.nl> References: <48C5190F.7020500@hhs.nl> <20080908123103.GE1667@hmsendeavour.rdu.redhat.com> <48C53E2E.4020405@hhs.nl> Message-ID: <20080908170522.GN1667@hmsendeavour.rdu.redhat.com> On Mon, Sep 08, 2008 at 05:01:02PM +0200, Hans de Goede wrote: > Neil Horman wrote: > >On Mon, Sep 08, 2008 at 02:22:39PM +0200, Hans de Goede wrote: > >>Hi All, > >> > >>I still need to write a little blog post of this, but as from Sept 1st > >>I've been hired by RedHat to work on anaconda (the installer). As such I > >>would like to reduce my package load as much as possible so that I can > >>focus fully on my new job. > >> > >>Thus *all* of my packages are looking for a new owner (I'm not actually > >>orphaning them, but I *really* want to lower my load quite a bit). > >> > >>https://admin.fedoraproject.org/pkgdb/users/packages/jwrdegoede?acls=owner > >> > >>If you are willing to take over any let me know and I'll orphan them and > >>you can pick them up. I'll be around for a long time to come to answer > >>any questions and help with any issues with them, so don't hesitate! > >> > >>Thanks & Regards, > >> > >>Hans > >> > >>-- > >>fedora-devel-list mailing list > >>fedora-devel-list at redhat.com > >>https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > > >Sorry, if I wasn't clear on this in my last response, but in addition to > >coda, > >I'd also be happy to inherity its dependencies, rvm and rpc2 > > Thanks, > > I've released them all, so don't forget to claim ownership or they will > be considered as orphans in the future. > I requested access to cpda, rvm, rpc2 and lwp in the packagedb, but are you sure you released them? The packagedb still lists you as the owner Neil > Regards, > > Hans > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- /*************************************************** *Neil Horman *Senior Software Engineer *Red Hat, Inc. *nhorman at redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ From michel.sylvan at gmail.com Mon Sep 8 17:14:37 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Mon, 8 Sep 2008 13:14:37 -0400 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C5190F.7020500@hhs.nl> References: <48C5190F.7020500@hhs.nl> Message-ID: On Mon, Sep 8, 2008 at 8:22 AM, Hans de Goede wrote: > Hi All, > > I still need to write a little blog post of this, but as from Sept 1st I've > been hired by RedHat to work on anaconda (the installer). As such I would > like to reduce my package load as much as possible so that I can focus fully > on my new job. Congrats! (Both to Hans and Red Hat). Anaconda definitely needs more caring attention. > > Thus *all* of my packages are looking for a new owner (I'm not actually > orphaning them, but I *really* want to lower my load quite a bit). I've just requested access to Io-language. Feel free to drop ownership on the currently-supported releases (though probably not F-8 as that's going EOL soon anyway) -- Michel Salim http://hircus.jaiku.com/ From jkeating at redhat.com Mon Sep 8 17:16:11 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 08 Sep 2008 10:16:11 -0700 Subject: To freeze, or not to freeze In-Reply-To: <1220889192.6502.42.camel@beck.corsepiu.local> References: <1220887143.17700.9.camel@luminos.localdomain> <1220889192.6502.42.camel@beck.corsepiu.local> Message-ID: <1220894171.17700.20.camel@luminos.localdomain> On Mon, 2008-09-08 at 17:53 +0200, Ralf Corsepius wrote: > At least, as far as I my packages are concerned, the hiatus has had a > major impact, imposing a major slowdown on development, partially > resembling to a "complete still-stand". Perhaps you can explain better how lack of F8/9 updates impacts your rawhide development? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From cevich at redhat.com Mon Sep 8 17:30:09 2008 From: cevich at redhat.com (Chris Evich) Date: Mon, 08 Sep 2008 13:30:09 -0400 Subject: Call for developers: rpmbuilder Message-ID: <48C56121.4040605@redhat.com> Hi, Hopefully this is the right mailing list :) Project rpmbuilder aims to provide a template-based approach to packaging. In other words, it removes responsibility from developer to produce an RPM spec file the "right" way. Instead, the package developer just feeds in his project's particulars, and a template-driven engine puts the pieces together and spits out a "sane" RPM and SRPM. https://fedorahosted.org/rpmbuilder Given the recent discussions on dependency management, perhaps there is some interest in helping me develop this tool further. There's no mailing list yet, so if interested, please contact me directly. Thanks! cevich [at-sign] redhat [dot] com From paul at all-the-johnsons.co.uk Mon Sep 8 17:48:07 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 08 Sep 2008 18:48:07 +0100 Subject: Mono - rfc for future developments Message-ID: <1220896087.30639.9.camel@PB3.Linux> Hi, I've just been notified that RC1 of Mono is due to be tagged today at some point with RC2 (final) on the 10th. Given the date difference of only 2 days, I'll be packaging Mono 2.0 for rawhide. Future plans. Currently the mono stack for Fedora is a bit of a mess over the three versions available. What I'm proposing for future mono/libgdiplus releases is this. Mono 2.0 is released on the 10th and packaged for rawhide Mono 1.9.1 is then released on F9 The stack is then rebuilt to cover gtk-sharp2 et al so that by the end of the process rawhide is one version ahead of core. When Mono 2 becomes 2.9, version 2 is released onto core and so on. This, in theory, should kill the problems experienced with the likes of monodevelop in core. It also means that core is operating on the stable release. An alternative is that after a couple of months proving on rawhide, the rawhide version is pushed to core. Comments on this are welcome either on or off list. TTFN Paul (looking for work so has a bit of time to spare to such activities) -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ivazqueznet at gmail.com Mon Sep 8 17:49:07 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 08 Sep 2008 13:49:07 -0400 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C5190F.7020500@hhs.nl> References: <48C5190F.7020500@hhs.nl> Message-ID: <1220896147.523.39.camel@ignacio.lan> On Mon, 2008-09-08 at 14:22 +0200, Hans de Goede wrote: > Thus *all* of my packages are looking for a new owner (I'm not actually > orphaning them, but I *really* want to lower my load quite a bit). I'll take feh, since I'm probably the only person that uses it. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From michel.sylvan at gmail.com Mon Sep 8 18:10:14 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Mon, 8 Sep 2008 14:10:14 -0400 Subject: Call for developers: rpmbuilder In-Reply-To: <48C56121.4040605@redhat.com> References: <48C56121.4040605@redhat.com> Message-ID: On Mon, Sep 8, 2008 at 1:30 PM, Chris Evich wrote: > Hi, > > Hopefully this is the right mailing list :) > > Project rpmbuilder aims to provide a template-based approach to packaging. In > other words, it removes responsibility from developer to produce an RPM spec > file the "right" way. Instead, the package developer just feeds in his > project's particulars, and a template-driven engine puts the pieces together > and spits out a "sane" RPM and SRPM. The name is rather similar to the rpmbuild command. Hopefully this would not cause confusion... Regards, -- Michel Salim http://hircus.jaiku.com/ From behdad at behdad.org Mon Sep 8 18:12:50 2008 From: behdad at behdad.org (Behdad Esfahbod) Date: Mon, 08 Sep 2008 14:12:50 -0400 Subject: Call for developers: rpmbuilder In-Reply-To: <48C56121.4040605@redhat.com> References: <48C56121.4040605@redhat.com> Message-ID: <48C56B22.3040800@behdad.org> Chris Evich wrote: > Hi, > > Hopefully this is the right mailing list :) > > Project rpmbuilder aims to provide a template-based approach to packaging. In > other words, it removes responsibility from developer to produce an RPM spec > file the "right" way. Instead, the package developer just feeds in his > project's particulars, and a template-driven engine puts the pieces together > and spits out a "sane" RPM and SRPM. > > https://fedorahosted.org/rpmbuilder Interesting. Fails to build here: gcc -D__USE_FIXED_PROTOTYPES__ -Wall -g -pthread -DORBIT2=1 -I/home/behdad/.local/include/cairo -I/home/behdad/.local/include/pango-1.0 -I/home/behdad/.local/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libgnome-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/orbit-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 -I/usr/include/libbonoboui-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/libart-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/freetype2 -I/usr/include/gconf/2 -I/usr/include/libglade-2.0 -I/usr/include/libxml2 -c -o template.o template.c In file included from template.c:32: macro.h:39: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?macro_new_context? macro.h:42: error: expected ?)? before ?mc? macro.h:47: error: expected ?)? before ?mc? macro.h:52: error: expected ?)? before ?mc? template.c: In function ?template_expand?: template.c:41: error: ?MacroContext? undeclared (first use in this function) template.c:41: error: (Each undeclared identifier is reported only once template.c:41: error: for each function it appears in.) template.c:41: error: expected ?;? before ?mc? template.c:49: error: ?mc? undeclared (first use in this function) template.c:49: warning: implicit declaration of function ?macro_new_context? make: *** [template.o] Error 1 > Given the recent discussions on dependency management, perhaps there is some > interest in helping me develop this tool further. There's no mailing list > yet, so if interested, please contact me directly. Thanks! > > cevich [at-sign] redhat [dot] com > From walters at verbum.org Mon Sep 8 18:49:56 2008 From: walters at verbum.org (Colin Walters) Date: Mon, 8 Sep 2008 14:49:56 -0400 Subject: Call for developers: rpmbuilder In-Reply-To: <48C56121.4040605@redhat.com> References: <48C56121.4040605@redhat.com> Message-ID: On Mon, Sep 8, 2008 at 1:30 PM, Chris Evich wrote: > Hi, > > Hopefully this is the right mailing list :) > > Project rpmbuilder aims to provide a template-based approach to packaging. In > other words, it removes responsibility from developer to produce an RPM spec > file the "right" way. Instead, the package developer just feeds in his > project's particulars, and a template-driven engine puts the pieces together > and spits out a "sane" RPM and SRPM. > > https://fedorahosted.org/rpmbuilder Personally I would rather see Fedora heavily invest in reducing all the overhead that currently exists in packaging and putting more intelligence into the core of the system, rather than generating spec files. Editing spec files is already painful enough; editing generated ones sounds even less fun. Essentially if the build system knows about things like the Ruby gem specs, Python setup.py, Java's Maven, freedesktop.org autotools-based desktop packages, etc., then you don't need to autogenerate a lot of spec boilerplate. From jkeating at redhat.com Mon Sep 8 18:59:59 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 08 Sep 2008 11:59:59 -0700 Subject: To freeze, or not to freeze In-Reply-To: <1220887143.17700.9.camel@luminos.localdomain> References: <1220887143.17700.9.camel@luminos.localdomain> Message-ID: <1220900399.17700.24.camel@luminos.localdomain> On Mon, 2008-09-08 at 08:19 -0700, Jesse Keating wrote: > > Given the "fun" we had with Alpha, I really feel that it would be > prudent to spend a few more unfrozen days with a hopefully continually > working rawhide installer so that we can do some of that last minute > testing of what's wrong before we freeze, and hopefully have a shorter > and more productive freeze period. But this is just my opinion, and > thus I'm putting this out there for discussion. The Fedora releng team discussed this today at our meeting, and came to the conclusion that slipping the freeze by 2 days (moving it from Tuesday to Thursday) was the best we could do right now, given schedule pressures with a major US holiday coming up (Thanksgiving). To slip around that we would have had to add an extra 2 weeks or so to the schedule, and we'd rather not do that unless we have a very good specific reason. So unless there are any reasonable objections, we're going to move the freeze to Thursday. All other parts of the schedule will remain the same. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From orion at cora.nwra.com Mon Sep 8 19:02:14 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 08 Sep 2008 13:02:14 -0600 Subject: No stage2.img in today's rawhide Message-ID: <48C576B6.3080109@cora.nwra.com> Is this intentional? anaconda seems to still look for it with ks/pxeboot install. -- 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 gnomeuser at gmail.com Mon Sep 8 19:03:47 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Mon, 8 Sep 2008 21:03:47 +0200 Subject: Mono - rfc for future developments In-Reply-To: <1220896087.30639.9.camel@PB3.Linux> References: <1220896087.30639.9.camel@PB3.Linux> Message-ID: <1dedbbfc0809081203h4b7f0aatae9be30d7be084fb@mail.gmail.com> Den 8. sep. 2008 19.48 skrev Paul : > Hi, > > I've just been notified that RC1 of Mono is due to be tagged today at > some point with RC2 (final) on the 10th. Given the date difference of > only 2 days, I'll be packaging Mono 2.0 for rawhide. > > Future plans. > > Currently the mono stack for Fedora is a bit of a mess over the three > versions available. What I'm proposing for future mono/libgdiplus > releases is this. > > Mono 2.0 is released on the 10th and packaged for rawhide > Mono 1.9.1 is then released on F9 > > The stack is then rebuilt to cover gtk-sharp2 et al so that by the end > of the process rawhide is one version ahead of core. > > When Mono 2 becomes 2.9, version 2 is released onto core and so on. > This, in theory, should kill the problems experienced with the likes of > monodevelop in core. It also means that core is operating on the stable > release. > > An alternative is that after a couple of months proving on rawhide, the > rawhide version is pushed to core. I admit I much prefer the latter method, it keeps the stack roughly the same accross releases which means our users have access to the latest bug fixes and a version that is supported by upstream. It also keeps the amount of code actively supported as low as possible. Aggressively pushing vetted versions of the Mono stack seems like the wisest plan to me. As a bonus, we also gain the ability to push the latest and thus often the only supported version of Mono using apps in our stable repos, something our users expect - just watch the Banshee mailing list, not only do our users expect the latest to be available but upstreams first reply to potential problems is nearly always to install the latest supported version. Let make use for Rawhide and updates-testing to vet the Mono stack, bodhi can be used as a metric for when to push updates to stable. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdahlin at redhat.com Mon Sep 8 19:07:17 2008 From: cdahlin at redhat.com (Casey Dahlin) Date: Mon, 08 Sep 2008 15:07:17 -0400 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <604aa7910809071150g282e18e0p61e3db838072e973@mail.gmail.com> References: <48C3B67E.6090301@gmail.com> <1220803513.3099.7.camel@sb-home> <20080907180240.GA1485@orient.maison.lan> <604aa7910809071150g282e18e0p61e3db838072e973@mail.gmail.com> Message-ID: <48C577E5.2070307@redhat.com> Jeff Spaleta wrote: > On Sun, Sep 7, 2008 at 10:02 AM, Emmanuel Seyman > wrote: > >> Please stop calling people who want things to work out of the box idiots. >> They're not. >> > > > I'm a certified genius... and I'm officially speaking for the entire > genius subculture when I say i/we (for we share a hive mind to some > extent) like things to work when I/we take them out of the box. That > way when I/we take then apart and try to put the back together I know > whether or not I've succeeded in my goal by using the initial > functionality as a baseline reference. > > > -jef"Or do i mean certifiable"spaleta > > Certainly, but that's not to say there isn't an "idiot" class of users we need to worry about. It isn't so much people who want things to just work. Its people who need to be protected from their own computer. Its an interesting question: do we want to pursue the same demographic as Nigerian scam artists? People who approach their machines the way early cave men must have first approached fire? People who, in the new age of ecommerce and scam artists, are posing a very real, tangible danger to themselves when they approach their computers? If so, what kind of OS serves this person? Is something more like the Sugar interface appropriate? What can we do to help? I think one good thing that could come of all this is better marketing and advertising of spins. We need more spins to be promoted as heavily as our main product. That way a spin that knows how to reach a niche audience can develop a community of its own, rather than simply existing quietly in Fedora's shadow. --CJD From wwoods at redhat.com Mon Sep 8 19:12:10 2008 From: wwoods at redhat.com (Will Woods) Date: Mon, 08 Sep 2008 15:12:10 -0400 Subject: No stage2.img in today's rawhide In-Reply-To: <48C576B6.3080109@cora.nwra.com> References: <48C576B6.3080109@cora.nwra.com> Message-ID: <1220901130.10435.15.camel@kraid.usersys.redhat.com> On Mon, 2008-09-08 at 13:02 -0600, Orion Poplawski wrote: > Is this intentional? anaconda seems to still look for it with > ks/pxeboot install. It's been renamed to install.img. And it's definitely there for 20080908 rawhide. -w From jspaleta at gmail.com Mon Sep 8 19:15:48 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 8 Sep 2008 11:15:48 -0800 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <48C577E5.2070307@redhat.com> References: <48C3B67E.6090301@gmail.com> <1220803513.3099.7.camel@sb-home> <20080907180240.GA1485@orient.maison.lan> <604aa7910809071150g282e18e0p61e3db838072e973@mail.gmail.com> <48C577E5.2070307@redhat.com> Message-ID: <604aa7910809081215x336bd62g57e8b5b8d5a0c3f6@mail.gmail.com> On Mon, Sep 8, 2008 at 11:07 AM, Casey Dahlin wrote: > Certainly, but that's not to say there isn't an "idiot" class of users we > need to worry about. I'm not so much worried about such a demographic..as I am about trying to keep discourse from devolving into crass baseless bickering. The use of this particular word in the particular context of this discussion... only serves to lower the level of discourse to the point where this discussion is not worth having. if proponents of the concept of splitting Fedora into multiple overlapping distributions must reach for such emotive language in their arguments.. then they deserve to have their ideas fail to be taken credibly. Good day. -jef"I said good day!"spaleta From dcbw at redhat.com Mon Sep 8 19:18:34 2008 From: dcbw at redhat.com (Dan Williams) Date: Mon, 08 Sep 2008 15:18:34 -0400 Subject: To freeze, or not to freeze In-Reply-To: <1220889862.3170.69.camel@atropine.boston.devel.redhat.com> References: <1220887143.17700.9.camel@luminos.localdomain> <1220889862.3170.69.camel@atropine.boston.devel.redhat.com> Message-ID: <1220901514.1618.3.camel@localhost.localdomain> On Mon, 2008-09-08 at 12:04 -0400, Adam Jackson wrote: > On Mon, 2008-09-08 at 08:19 -0700, Jesse Keating wrote: > > > Feature owners in particular, I'm interested in your opinions as to if > > you need a few more days to see what shape your features are in before > > we freeze. Ideally the week before a freeze would have been a slow down > > period, where large changes were avoided and bugfixing was focused on so > > that the Beta was useful. I feel like we didn't give you a chance to do > > this and it'll still feel like crash landing planes on the carrier deck > > when it come to features in Beta. > > As far as the plymouth and drm changes are concerned, having a few more > days to sand down the larger splinters would certainly be appreciated. A few more days for an NM 0.7 RC wouldn't hurt either; I hoped to get an rc1 out by the end of the week. Dan From Axel.Thimm at ATrpms.net Mon Sep 8 19:27:49 2008 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Mon, 8 Sep 2008 22:27:49 +0300 Subject: Why eGroupWare is not in Fedora? In-Reply-To: <1220890633.987.38.camel@rosebud> References: <48C54F4A.5090503@ru.bir.ru> <1220890633.987.38.camel@rosebud> Message-ID: <20080908192749.GA6962@victor.nirvana> On Mon, Sep 08, 2008 at 12:17:13PM -0400, Seth Vidal wrote: > On Mon, 2008-09-08 at 20:14 +0400, Pavel Alexeev (aka Pahan-Hubbitus) > wrote: > > http://eGroupWare.org > > It is sponsored by RedHat. Download page present links to src.rpm (from > > openSUSE buildservice > > :) ) so > > I think it is not hard porting for Fedora. > > Any legal issues? On first look it is GPLv2 and GPLv3. So, why it is not > > here (I also check reviews in progress)? Or it just wait maintainer and > > I can try make review request? > > > > I think it just needs a maintainer/packager. > > Feel free to apply for it. egroupware looks really nice. As did opengroupware before I attempted packaging it. :/ I'd really like to push some more groupware bits into Fedora and see which one is the fittest. egroupware does look a bit easier to package, and if there is interest from more than one person we already have a packager and a reviewer! Pavel, do you want to attack this and have me review it? IIRC correctly there was some attempt in forming a Fedora groupware SIG. What happened to it? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From michel.sylvan at gmail.com Mon Sep 8 19:41:46 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Mon, 8 Sep 2008 15:41:46 -0400 Subject: Mono - rfc for future developments In-Reply-To: <1dedbbfc0809081203h4b7f0aatae9be30d7be084fb@mail.gmail.com> References: <1220896087.30639.9.camel@PB3.Linux> <1dedbbfc0809081203h4b7f0aatae9be30d7be084fb@mail.gmail.com> Message-ID: 2008/9/8 David Nielsen : > > > Den 8. sep. 2008 19.48 skrev Paul : >> >> Hi, >> >> I've just been notified that RC1 of Mono is due to be tagged today at >> some point with RC2 (final) on the 10th. Given the date difference of >> only 2 days, I'll be packaging Mono 2.0 for rawhide. >> >> Future plans. >> >> Currently the mono stack for Fedora is a bit of a mess over the three >> versions available. What I'm proposing for future mono/libgdiplus >> releases is this. >> >> Mono 2.0 is released on the 10th and packaged for rawhide >> Mono 1.9.1 is then released on F9 >> >> The stack is then rebuilt to cover gtk-sharp2 et al so that by the end >> of the process rawhide is one version ahead of core. >> >> When Mono 2 becomes 2.9, version 2 is released onto core and so on. >> This, in theory, should kill the problems experienced with the likes of >> monodevelop in core. It also means that core is operating on the stable >> release. >> >> An alternative is that after a couple of months proving on rawhide, the >> rawhide version is pushed to core. > > I admit I much prefer the latter method, it keeps the stack roughly the same > accross releases which means our users have access to the latest bug fixes > and a version that is supported by upstream. It also keeps the amount of > code actively supported as low as possible. Aggressively pushing vetted > versions of the Mono stack seems like the wisest plan to me. As a bonus, we > also gain the ability to push the latest and thus often the only supported > version of Mono using apps in our stable repos, something our users expect - > just watch the Banshee mailing list, not only do our users expect the latest > to be available but upstreams first reply to potential problems is nearly > always to install the latest supported version. > I concur; the Mono stack seems to be monotonically (pun alert!) increasing in usability, that the benefits of maintaining a single Mono major version across our supported releases outweigh the stability concerns. Would we have time to get 2.0 into F-9, and rebuild the Mono stack there, or do we need an interim release of currently-FTBFS Mono packages? (thinking of Monodevelop here. Wouldn't want it blacklisted) -- Michel Salim http://hircus.jaiku.com/ From jkeating at redhat.com Mon Sep 8 19:52:22 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 08 Sep 2008 12:52:22 -0700 Subject: To freeze, or not to freeze In-Reply-To: <1220901514.1618.3.camel@localhost.localdomain> References: <1220887143.17700.9.camel@luminos.localdomain> <1220889862.3170.69.camel@atropine.boston.devel.redhat.com> <1220901514.1618.3.camel@localhost.localdomain> Message-ID: <1220903542.17700.27.camel@luminos.localdomain> On Mon, 2008-09-08 at 15:18 -0400, Dan Williams wrote: > A few more days for an NM 0.7 RC wouldn't hurt either; I hoped to get an > rc1 out by the end of the week. See, that sounds like a beta threatening change. What sort of changes might this RC include, and how risky is it re anaconda and such? These are the types of things I hate to see crash landed the day of the freeze... -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From orion at cora.nwra.com Mon Sep 8 20:01:19 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Mon, 08 Sep 2008 14:01:19 -0600 Subject: No stage2.img in today's rawhide In-Reply-To: <1220901130.10435.15.camel@kraid.usersys.redhat.com> References: <48C576B6.3080109@cora.nwra.com> <1220901130.10435.15.camel@kraid.usersys.redhat.com> Message-ID: <48C5848F.3090108@cora.nwra.com> Will Woods wrote: > On Mon, 2008-09-08 at 13:02 -0600, Orion Poplawski wrote: >> Is this intentional? anaconda seems to still look for it with >> ks/pxeboot install. > > It's been renamed to install.img. And it's definitely there for 20080908 > rawhide. > > -w > Ah, had an old stage2= line in my pxeboot config. -- 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 jos at xos.nl Mon Sep 8 20:09:59 2008 From: jos at xos.nl (Jos Vos) Date: Mon, 8 Sep 2008 22:09:59 +0200 Subject: Why eGroupWare is not in Fedora? In-Reply-To: <20080908192749.GA6962@victor.nirvana> References: <48C54F4A.5090503@ru.bir.ru> <1220890633.987.38.camel@rosebud> <20080908192749.GA6962@victor.nirvana> Message-ID: <20080908200959.GA1160@jasmine.xos.nl> On Mon, Sep 08, 2008 at 10:27:49PM +0300, Axel Thimm wrote: > I'd really like to push some more groupware bits into Fedora and see > which one is the fittest. egroupware does look a bit easier to > package, and if there is interest from more than one person we already > have a packager and a reviewer! > > Pavel, do you want to attack this and have me review it? I'm offering my help in reviewing and maybe a bit more too, if that helps. I've just downloaded that src.rpm from the SUSE build service, but there might be quite some work in making this a "good" rpm. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From seg at haxxed.com Mon Sep 8 20:28:53 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 08 Sep 2008 15:28:53 -0500 Subject: Boot speedup with readahead In-Reply-To: <1220887636.5554.37.camel@aglarond.local> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> Message-ID: <1220905733.6431.9.camel@localhost.localdomain> On Mon, 2008-09-08 at 11:27 -0400, Jeremy Katz wrote: > And doing it this way would be more effective than cron as there are > plenty of people (especially with laptops/desktops which aren't on all > the time) for whom cron really isn't appropriate for anything that we > actually care to have done We still need to trigger pre-linking after yum transactions rather than by a cron job... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alain.portal at free.fr Mon Sep 8 20:48:06 2008 From: alain.portal at free.fr (Alain PORTAL) Date: Mon, 8 Sep 2008 22:48:06 +0200 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <48C4492B.3070105@ihug.com.au> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <48C4492B.3070105@ihug.com.au> Message-ID: <200809082248.06835.alain.portal@free.fr> Le dimanche 07 septembre 2008, Roy Rankin a ?crit : > I am the package maintainer of Denemo and an upstream contributor to gpsim. > > If Alain either does not want to, or cannot, continue being the package > maintainer for gpsim. I would be happy to take it over. If you take also his dependancy, gtk-extras, I'll let you gpsim; Regards, Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From jkeating at redhat.com Mon Sep 8 20:59:00 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 08 Sep 2008 13:59:00 -0700 Subject: Boot speedup with readahead In-Reply-To: <1220905733.6431.9.camel@localhost.localdomain> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> Message-ID: <1220907540.17700.30.camel@luminos.localdomain> On Mon, 2008-09-08 at 15:28 -0500, Callum Lerwick wrote: > > We still need to trigger pre-linking after yum transactions rather than > by a cron job... So that we can have an "Optimizing harddrive" phase during updates like OSX does? that'd be awesome... -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Mon Sep 8 21:02:22 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 08 Sep 2008 23:02:22 +0200 Subject: To freeze, or not to freeze In-Reply-To: <1220894171.17700.20.camel@luminos.localdomain> References: <1220887143.17700.9.camel@luminos.localdomain> <1220889192.6502.42.camel@beck.corsepiu.local> <1220894171.17700.20.camel@luminos.localdomain> Message-ID: <1220907742.6502.70.camel@beck.corsepiu.local> On Mon, 2008-09-08 at 10:16 -0700, Jesse Keating wrote: > On Mon, 2008-09-08 at 17:53 +0200, Ralf Corsepius wrote: > > At least, as far as I my packages are concerned, the hiatus has had a > > major impact, imposing a major slowdown on development, partially > > resembling to a "complete still-stand". > > Perhaps you can explain better how lack of F8/9 updates impacts your > rawhide development? I am developing/testing on FC9 - My rawhide developments are a spin off from these => No FC9 updates, no rawhide updates. Ralf From forum at ru.bir.ru Mon Sep 8 21:04:37 2008 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Tue, 09 Sep 2008 01:04:37 +0400 Subject: Why eGroupWare is not in Fedora? In-Reply-To: <20080908192749.GA6962@victor.nirvana> References: <48C54F4A.5090503@ru.bir.ru> <1220890633.987.38.camel@rosebud> <20080908192749.GA6962@victor.nirvana> Message-ID: <48C59365.2050002@ru.bir.ru> Axel Thimm ?????: > On Mon, Sep 08, 2008 at 12:17:13PM -0400, Seth Vidal wrote: > >> On Mon, 2008-09-08 at 20:14 +0400, Pavel Alexeev (aka Pahan-Hubbitus) >> wrote: >> >>> http://eGroupWare.org >>> It is sponsored by RedHat. Download page present links to src.rpm (from >>> openSUSE buildservice >>> :) ) so >>> I think it is not hard porting for Fedora. >>> Any legal issues? On first look it is GPLv2 and GPLv3. So, why it is not >>> here (I also check reviews in progress)? Or it just wait maintainer and >>> I can try make review request? >>> >>> >> I think it just needs a maintainer/packager. >> >> Feel free to apply for it. >> > > egroupware looks really nice. As did opengroupware before I attempted > packaging it. :/ > > I'd really like to push some more groupware bits into Fedora and see > which one is the fittest. egroupware does look a bit easier to > package, and if there is interest from more than one person we already > have a packager and a reviewer! > > Pavel, do you want to attack this and have me review it? > I can try. But now for me more interesting egroupware than packaging it :) So, I have now 2 packages in progress, and if meanwhile someone do not start working on it I can try "making this a "good" rpm" ( (C) Jos Vos ) > IIRC correctly there was some attempt in forming a Fedora groupware > SIG. What happened to it? > From kevin at scrye.com Fri Sep 5 21:11:59 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 5 Sep 2008 15:11:59 -0600 Subject: FESCo Issue tracking Message-ID: <20080905151159.74161fb7@ohm.scrye.com> Greetings. In the past, interested parties could bring matters to the attention of FESCo in several ways: Mailing the chair, following up to the schedule posting on the devel list asking for a new topic to be added, or attending meetings on irc and bringing up the topic at the end of the meeting in the Open Discussion phase. While these methods work well for issues that simply need a bit of discussion and a decision, longer term issues that should be tracked and discussed further sometimes are forgotten. To help solve this issue, and to make it easier for folks to bring an issue before FESCo, I have asked Fedora Infrastructure to setup a trac instance for FESCo to track tasks and handle new issues. New issues for FESCo can now be filed at: https://fedorahosted.org/fesco/ Please feel free to file issues there. Note that FESCo (Fedora Engineering Steering Committee) handles the process of accepting new features, the acceptance of new packaging sponsors, Special Interest Groups (SIGs) and SIG Oversight, the packaging process, handling and enforcement of maintainer issues and other technical matters related to the distribution and its construction Thanks. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jkeating at redhat.com Mon Sep 8 21:06:47 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 08 Sep 2008 14:06:47 -0700 Subject: Fedora 8 and 9 updates status In-Reply-To: <1220630950.4273.14.camel@luminos.localdomain> References: <1220630950.4273.14.camel@luminos.localdomain> Message-ID: <1220908007.17700.38.camel@luminos.localdomain> On Fri, 2008-09-05 at 09:09 -0700, Jesse Keating wrote: > Announcements regarding the location > of said document and how to help with content will be coming shortly. Time for another update on the F8 and F9 updates status. Our testing with the live update content as gone well. We identified a couple issues with the current PackageKit and thanks to Richard Hughes we'll have an updated PackageKit to offer as well as an updated fedora-release package for our users. The combination of the two (or just the fedora-release package for you non-packagekit users) will be all that you will need in order to gain access to our newly signed and relocated updates. We're in the final stages of testing a few corner cases, and preparing the official builds of fedora-release, PackageKit, gnome-packagekit, and unique (needed as a new dep for gnome-packagekit). All existing updates in the old update locations will be purged, and just these updates will be put in their place, signed with our old key. Once you've updated to these packages, the next update attempt will point you to our new locations with our new keys and you should be able to process any further pending updates. You'll be prompted to import the new key along the way. A wiki page has been created that covers some of this, https://fedoraproject.org/wiki/Enabling_new_signing_key and will be updated throughout the day as we finish the above listed tasks. A more formal announcement along with links to the official FAQ will be published to same lists this mail is going out to, and likely picked up by various news sites. We expect things to wrap up by the end of today or early tomorrow. Once again we thank you for your continued patience and be aware that we're nearly there! -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From jkeating at redhat.com Mon Sep 8 21:08:45 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 08 Sep 2008 14:08:45 -0700 Subject: To freeze, or not to freeze In-Reply-To: <1220907742.6502.70.camel@beck.corsepiu.local> References: <1220887143.17700.9.camel@luminos.localdomain> <1220889192.6502.42.camel@beck.corsepiu.local> <1220894171.17700.20.camel@luminos.localdomain> <1220907742.6502.70.camel@beck.corsepiu.local> Message-ID: <1220908125.17700.41.camel@luminos.localdomain> On Mon, 2008-09-08 at 23:02 +0200, Ralf Corsepius wrote: > I am developing/testing on FC9 - My rawhide developments are a spin off > from these => No FC9 updates, no rawhide updates. So you develop and test on a different platform than that which you deploy on? Interesting. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sandeen at redhat.com Mon Sep 8 21:11:54 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Mon, 08 Sep 2008 16:11:54 -0500 Subject: Boot speedup with readahead In-Reply-To: <1220907540.17700.30.camel@luminos.localdomain> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220907540.17700.30.camel@luminos.localdomain> Message-ID: <48C5951A.7080803@redhat.com> Jesse Keating wrote: > On Mon, 2008-09-08 at 15:28 -0500, Callum Lerwick wrote: >> We still need to trigger pre-linking after yum transactions rather than >> by a cron job... > > So that we can have an "Optimizing harddrive" phase during updates like > OSX does? that'd be awesome... I guess you can wait now, or wait later. But yeah I agree with osx it's: boots up fast, awesome! background download of updates, awesome! updates install quickly (usually) - awesome! updates force reboot - not awesome! reboot takes AGES that first time - not aweseome! -Eric From stlwrt at gmail.com Mon Sep 8 21:02:55 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Tue, 9 Sep 2008 00:02:55 +0300 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <48C465E1.1050303@ru.bir.ru> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <48C3D2A2.2050904@ru.bir.ru> <48C465E1.1050303@ru.bir.ru> Message-ID: On Mon, Sep 8, 2008 at 2:38 AM, Pavel Alexeev (aka Pahan-Hubbitus) wrote: > Pavel Shevchuk ?????: >> >> On Sun, Sep 7, 2008 at 4:09 PM, forum wrote: >> >>> >>> Matt Domsch ?????: >>> >>>> >>>> The following 90 packages have had FTBFS (Fails to Build From Source) >>>> failures for several months, some as far back as February 2008. >>>> >>>> There are several "trivial" failures which could be addressed easily. >>>> 8 fail due to unpackaged files >>>> 6 fail due to patch fuzz >>>> 1 fails due to open() not passing a mode. >>>> >>>> http://fedoraproject.org/wiki/FTBFS describes the FTBFS process. >>>> >>>> As was proposed to FESCO, packages with unresolved FTBFS bugs >>>> immediately following the Alpha release will be removed from the >>>> distribution. Package owners may request that their package _not_ be >>>> removed provided they are actively working on resolving the FTBFS and >>>> have a plan to resolve the FTBFS before the Release Candidate >>>> release. FESCo has the final say of course, but these are the items >>>> on my candidate list. I'd prefer packages get fixed rather than >>>> removed. If you are the package owner, or are interested in the >>>> future of these packages, please investigate these build failures and >>>> fix them ASAP. >>>> >>>> aiksaurus-1.2.1-15.fc6 [u'434484 ASSIGNED'] (build/make) uwog >>>> astyle-1.21-6.fc8 [u'433971 ASSIGNED'] (build/make) addutko,mtasaka >>>> aterm-1.0.1-2.fc9 [u'440779 ASSIGNED'] (build/make) awjb >>>> bes-3.5.3-3.fc9 [u'434360 ASSIGNED'] (build/make) pertusus >>>> bitbake-1.8.8-1.fc8 [u'440562 ASSIGNED'] (build/make) ixs >>>> bmpx-0.40.14-5.fc9 [u'449431 ASSIGNED'] (patch_fuzz) akahl >>>> brltty-3.9-2.2.fc9 [u'449446 ASSIGNED'] (build/make) kasal >>>> brutus-keyring-0.9.0-6.fc8 [u'434007 ASSIGNED'] (build/make) >>>> bpepple,colding >>>> camstream-0.26.3-12.fc8 [u'434345 ASSIGNED'] (build/make) nomis80 >>>> coolkey-1.1.0-6.fc9 [u'440753 ASSIGNED'] (build/make) rrelyea,jmagne >>>> dap-freeform_handler-3.7.7-2.fc9 [u'434362 ASSIGNED'] (build/make) >>>> pertusus >>>> dap-hdf4_handler-3.7.7-3.fc9 [u'434363 ASSIGNED'] (build/make) pertusus >>>> djvulibre-3.5.20-2.fc9 [u'440910 ASSIGNED'] (build/make) thias >>>> elektra-0.6.10-6.fc9 [u'434364 ASSIGNED'] (build/make) pertusus,kwizart >>>> erlang-R12B-3.1.fc10 [u'449432 ASSIGNED'] (patch_fuzz) gemi >>>> fish-1.23.0-2.fc9 [u'440724 ASSIGNED'] (build/make) ascii,oliver >>>> fluxstyle-1.0.1-2.fc7 [u'440757 ASSIGNED'] (build/make) errr >>>> fonttools-2.0-0.11.20060223cvs.fc7 [u'434409 ASSIGNED'] >>>> (unpackaged_files/python-egg-info?) roozbeh,fonts-sig >>>> fontypython-0.2.0-6.fc7 [u'440756 ASSIGNED'] (build/make) >>>> cr33dog,fonts-sig >>>> fwbuilder-2.1.16-2.fc9 [u'440846 ASSIGNED'] (build/make) ertzing >>>> gauche-0.8.13-1.fc9 [u'449627 ASSIGNED'] (build/make) gemi >>>> gcl-2.6.7-18.fc9 [u'440913 ASSIGNED'] (build/make) gemi,green >>>> gdmap-0.7.5-6.fc6 [u'434529 ASSIGNED'] (build/make) splinux >>>> gpsim-0.22.0-5.fc8 [u'434061 ASSIGNED'] (build/make) dionysos >>>> gstm-1.2-6.fc7 [u'434531 ASSIGNED'] (build/make) splinux >>>> gtk-sharp-1.0.10-12.fc7 [u'434373 ASSIGNED'] >>>> (unpackaged_files/python-egg-info?) pfj >>>> guile-gnome-platform-2.15.93-6.fc8 [u'434289 ASSIGNED'] (build/make) >>>> laxathom >>>> g-wrap-1.9.9-5.fc9 [u'434278 ASSIGNED'] (patch_fuzz) laxathom >>>> HelixPlayer-1.0.9-4.fc10 [u'449474 ASSIGNED'] (patch_fuzz) abompard >>>> ht2html-2.0-5.fc6 [u'440916 ASSIGNED'] (build/make) ifoox >>>> itpp-4.0.0-2.fc9 [u'434076 ASSIGNED'] (build/make) edhill >>>> jabbin-2.0-0.6.beta2a.fc9 [u'440730 ASSIGNED'] (build/make) >>>> jgroups-2.2.9.2-3jpp.2 [u'434352 ASSIGNED'] (build/make) dbhole >>>> kdebluetooth-1.0-0.41.beta8.fc9 [u'449604 ASSIGNED'] (build/make) >>>> gilboa,scop >>>> ladspa-1.12-9.fc9 [u'449542 ASSIGNED'] (build/make) thomasvs >>>> libdap-3.7.10-2.fc9 [u'434366 ASSIGNED'] (build/make) pertusus >>>> libFoundation-1.1.3-11.fc9 [u'440564 ASSIGNED'] (build/make) athimm >>>> libfwbuilder-2.1.16-2.fc9 [u'449591 ASSIGNED'] (build/make) ertzing >>>> libnc-dap-3.7.0-9.fc9 [u'434367 ASSIGNED'] (build/make) pertusus >>>> libopensync-0.36-2.fc9 [u'449510 ASSIGNED'] (build/make) awjb >>>> libzzub-0.2.3-12.fc9 [u'449661 ASSIGNED'] (patch_fuzz) akahl,mtasaka >>>> lilypond-2.10.33-1.fc8 [u'434394 ASSIGNED'] (build/make) limb >>>> lineakd-0.9-5.fc6 [u'434523 ASSIGNED'] (build/make) xris >>>> lineak-defaultplugin-0.9-2.fc6 [u'434520 ASSIGNED'] (build/make) xris >>>> lineak-xosdplugin-0.9-2.fc6 [u'434522 ASSIGNED'] (build/make) xris >>>> linpsk-0.9-3.fc9 [u'440778 ASSIGNED'] (build/make) >>>> bjensen,sindrepb,sconklin >>>> linux-atm-2.5.0-5 [u'434069 ASSIGNED', u'449613 ASSIGNED'] (build/make) >>>> dwmw2 >>>> lostirc-0.4.6-3.fc8 [u'440921 ASSIGNED'] (build/make) splinux,splinux >>>> lrmi-0.10-4.fc9 [u'449509 ASSIGNED'] (build/make) pwouters >>>> mimetic-0.9.3-2.fc8 [u'434086 ASSIGNED'] (build/make) ensc >>>> mod_suphp-0.6.3-1.fc9 [u'449578 ASSIGNED'] (build/make) ixs >>>> monodevelop-0.19-6.fc9 [u'449441 ASSIGNED'] (build/make) pfj >>>> mosml-2.01-11.fc9 [u'449445 ASSIGNED'] (build/make) gemi >>>> moto4lin-0.3-6.fc7 [u'434135 ASSIGNED'] (build/make) jafo >>>> muine-scrobbler-0.1.8-5.fc9 [u'449482 ASSIGNED'] (build/make) sindrepb >>>> mx-2.0.6-3 [u'434325 ASSIGNED'] (unpackaged_files/python-egg-info?) misa >>>> mysql-gui-tools-5.0r12-8.fc9 [u'440734 ASSIGNED', u'433987 ASSIGNED'] >>>> (patch_fuzz) ausil >>>> >>>> >>> >>> I'm not maintainer of this package, but mysql-gui-tools is interesting >>> for >>> me. >>> I think I can fix it soon. >>> >> >> I fixed shellbang patch fuzzyness - >> http://attic.scwlab.com/mysql-administrator-spawn_fetches.patch >> But now it fails because of GTK API change =( >> >> > > In one of the bug (#433987) I'm propose link to my src.rpm which is > successfully built on my Fedora9. F9 has older gtk2. On F10 code needs to be patched -- http://scwlab.com From jkeating at redhat.com Mon Sep 8 21:16:42 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 08 Sep 2008 14:16:42 -0700 Subject: Boot speedup with readahead In-Reply-To: <48C5951A.7080803@redhat.com> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220907540.17700.30.camel@luminos.localdomain> <48C5951A.7080803@redhat.com> Message-ID: <1220908602.17700.42.camel@luminos.localdomain> On Mon, 2008-09-08 at 16:11 -0500, Eric Sandeen wrote: > reboot takes AGES that first time - not aweseome! At least they moved it to the reboot. It used to be tacked on to the tail end of each update run, so you'd download fast, install fast, and then sit there for unknown amount of time waiting for "optimizations" that are likely not going to make up for the lost time. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ville.skytta at iki.fi Mon Sep 8 21:24:03 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Tue, 9 Sep 2008 00:24:03 +0300 Subject: Boot speedup with readahead In-Reply-To: <1220905733.6431.9.camel@localhost.localdomain> References: <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> Message-ID: <200809090024.04426.ville.skytta@iki.fi> On Monday 08 September 2008, Callum Lerwick wrote: > On Mon, 2008-09-08 at 11:27 -0400, Jeremy Katz wrote: > > And doing it this way would be more effective than cron as there are > > plenty of people (especially with laptops/desktops which aren't on all > > the time) for whom cron really isn't appropriate for anything that we > > actually care to have done > > We still need to trigger pre-linking after yum transactions rather than > by a cron job... Please keep users of other package managers than yum in mind, too. Can things like these be hooked to rpm level transactions rather than yum ("%triggerpostrans -- *" or something)? From katzj at redhat.com Mon Sep 8 21:33:54 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 08 Sep 2008 17:33:54 -0400 Subject: Boot speedup with readahead In-Reply-To: <200809090024.04426.ville.skytta@iki.fi> References: <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <200809090024.04426.ville.skytta@iki.fi> Message-ID: <1220909634.5554.78.camel@aglarond.local> On Tue, 2008-09-09 at 00:24 +0300, Ville Skytt? wrote: > On Monday 08 September 2008, Callum Lerwick wrote: > > On Mon, 2008-09-08 at 11:27 -0400, Jeremy Katz wrote: > > > And doing it this way would be more effective than cron as there are > > > plenty of people (especially with laptops/desktops which aren't on all > > > the time) for whom cron really isn't appropriate for anything that we > > > actually care to have done > > > > We still need to trigger pre-linking after yum transactions rather than > > by a cron job... > > Please keep users of other package managers than yum in mind, too. Can things > like these be hooked to rpm level transactions rather than yum > ("%triggerpostrans -- *" or something)? Not really -- for one thing, there isn't functionality for transaction level triggers. And even if there were, using them would introduce other new and different problems. It really boils down to the fact that the Fedora package manager is yum. If users of other package managers want to get their package manager to do similar things, we won't stop them -- but trying to make everything work for such a small minority is going to be increasingly difficult. Much like if you wanted to use dpkg + alien to install packages rather than using rpm Jeremy From cra at WPI.EDU Mon Sep 8 21:34:21 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 8 Sep 2008 17:34:21 -0400 Subject: Fedora 8 and 9 updates status In-Reply-To: <1220908007.17700.38.camel@luminos.localdomain> References: <1220630950.4273.14.camel@luminos.localdomain> <1220908007.17700.38.camel@luminos.localdomain> Message-ID: <20080908213421.GG12193@angus.ind.WPI.EDU> On Mon, Sep 08, 2008 at 02:06:47PM -0700, Jesse Keating wrote: > A wiki page has been created that covers some of this, > https://fedoraproject.org/wiki/Enabling_new_signing_key and will be The Wiki page above links to several different locations with conflicting and duplicated information. One of the links in the above page points here which seems like it would be a more approriate starting place for future announcements [1]. It also points to a locatation which contains old Package Signing Keys [2]. This apparently contains the new Package Signing Keys [3]. Can we settle on a single location for all of this information instead of having a location with the out-of-date information and a separate location for the new information? It seems like the information in "Enabling_new_signing_key" should just be folded into a section of the "New_signing_key" page and point users there instead. Then they get to see all the status updates, overall progress of the resolution process, and instructions all on one page. Also, remove the old keys or at least mark them as old keys on [2] or just fold the information from [3] into [2]. [1] https://fedoraproject.org/wiki/New_signing_key [2] https://admin.fedoraproject.org/fingerprints [3] https://fedoraproject.org/keys From rc040203 at freenet.de Mon Sep 8 21:39:14 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 08 Sep 2008 23:39:14 +0200 Subject: To freeze, or not to freeze In-Reply-To: <1220908125.17700.41.camel@luminos.localdomain> References: <1220887143.17700.9.camel@luminos.localdomain> <1220889192.6502.42.camel@beck.corsepiu.local> <1220894171.17700.20.camel@luminos.localdomain> <1220907742.6502.70.camel@beck.corsepiu.local> <1220908125.17700.41.camel@luminos.localdomain> Message-ID: <1220909954.6502.85.camel@beck.corsepiu.local> On Mon, 2008-09-08 at 14:08 -0700, Jesse Keating wrote: > On Mon, 2008-09-08 at 23:02 +0200, Ralf Corsepius wrote: > > I am developing/testing on FC9 - My rawhide developments are a spin off > > from these => No FC9 updates, no rawhide updates. > > So you develop and test on a different platform than that which you > deploy on? Yes. > Interesting. And where's the problem? Are you expecting application devs to run something as unstable and broken as rawhide? Ralf From rc040203 at freenet.de Mon Sep 8 21:40:45 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 08 Sep 2008 23:40:45 +0200 Subject: orphaning opencv Message-ID: <1220910045.6502.88.camel@beck.corsepiu.local> Hi, I'd like to release ownership of opencv, because I don't use it any longer - Any takers? Ralf From rrankin at ihug.com.au Mon Sep 8 21:57:03 2008 From: rrankin at ihug.com.au (Roy Rankin) Date: Tue, 09 Sep 2008 07:57:03 +1000 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <200809082248.06835.alain.portal@free.fr> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <48C4492B.3070105@ihug.com.au> <200809082248.06835.alain.portal@free.fr> Message-ID: <48C59FAF.1090009@ihug.com.au> Alain, Yes, I can take both gpsim and gtk-extras. Regards, Roy Rankin Alain PORTAL wrote: > Le dimanche 07 septembre 2008, Roy Rankin a ?crit : >> I am the package maintainer of Denemo and an upstream contributor to gpsim. >> >> If Alain either does not want to, or cannot, continue being the package >> maintainer for gpsim. I would be happy to take it over. > > If you take also his dependancy, gtk-extras, I'll let you gpsim; > > Regards, > Alain > From tmz at pobox.com Mon Sep 8 22:00:06 2008 From: tmz at pobox.com (Todd Zullinger) Date: Mon, 8 Sep 2008 18:00:06 -0400 Subject: Fedora 8 and 9 updates status In-Reply-To: <20080908213421.GG12193@angus.ind.WPI.EDU> References: <1220630950.4273.14.camel@luminos.localdomain> <1220908007.17700.38.camel@luminos.localdomain> <20080908213421.GG12193@angus.ind.WPI.EDU> Message-ID: <20080908220006.GA17688@inocybe.teonanacatl.org> Chuck Anderson wrote: > The Wiki page above links to several different locations with > conflicting and duplicated information. One of the links in the > above page points here which seems like it would be a more > approriate starting place for future announcements [1]. It also > points to a locatation which contains old Package Signing Keys [2]. You mean the link at the top which says to verify SSH fingerprints? > Can we settle on a single location for all of this information > instead of having a location with the out-of-date information and a > separate location for the new information? Definitely seems like a good idea. I filed a ticket about updating and/or consolidating the gpg key info from admin.fp.o/fingerprints and fp.o/keys the other day: https://fedorahosted.org/fedora-infrastructure/ticket/814 -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Today I will gladly share my experience and advice, for there are no sweater words than "I told you so!" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From paul at all-the-johnsons.co.uk Mon Sep 8 22:05:03 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 08 Sep 2008 23:05:03 +0100 Subject: Mono - rfc for future developments In-Reply-To: References: <1220896087.30639.9.camel@PB3.Linux> <1dedbbfc0809081203h4b7f0aatae9be30d7be084fb@mail.gmail.com> Message-ID: <1220911503.31583.3.camel@PB3.Linux> Hi, > >> An alternative is that after a couple of months proving on rawhide, the > >> rawhide version is pushed to core. > > > > I admit I much prefer the latter method, it keeps the stack roughly the same > > accross releases which means our users have access to the latest bug fixes > > and a version that is supported by upstream. It also keeps the amount of > > code actively supported as low as possible. Aggressively pushing vetted > > versions of the Mono stack seems like the wisest plan to me. As a bonus, we > > also gain the ability to push the latest and thus often the only supported > > version of Mono using apps in our stable repos, something our users expect - > > just watch the Banshee mailing list, not only do our users expect the latest > > to be available but upstreams first reply to potential problems is nearly > > always to install the latest supported version. Sounds fair enough. I have no problems in doing the push... > I concur; the Mono stack seems to be monotonically (pun alert!) > increasing in usability, that the benefits of maintaining a single > Mono major version across our supported releases outweigh the > stability concerns. No. Stability is a major issue. Remember what rawhide is there for; it's the testing ground. I have no problems doing the mono packaging, wait a few months and then bounce it down to stable, but never at the cost of stability. Release versions need to be treated with cotton gloves as not everyone is as brave as us nutjobs! > Would we have time to get 2.0 into F-9, and rebuild the Mono stack > there, or do we need an interim release of currently-FTBFS Mono > packages? (thinking of Monodevelop here. Wouldn't want it blacklisted) Should have... TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From forum at ru.bir.ru Mon Sep 8 22:06:35 2008 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Tue, 09 Sep 2008 02:06:35 +0400 Subject: Koji upload speed. Message-ID: <48C5A1EB.5010003@ru.bir.ru> I have upload speed of packages around 20 KiB/sec. $ koji build --scratch --arch-override=i386 dist-f10 mysql-gui-tools-5.0r12-1.fc9.Hu.14.src.rpm Uploading srpm: mysql-gui-tools-5.0r12-1.fc9.Hu.14.src.rpm [= ] 03% 00:01:06 768.00 KiB 16.34 KiB/sec Is it normal and may be there any limitations about I not known? Or may be I can adjust something? I have symmetric connection 4000Mib/sec. -- With best regards, Pavel Alexeev (aka Pahan-Hubbitus) From dennis at ausil.us Mon Sep 8 22:15:19 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 8 Sep 2008 17:15:19 -0500 Subject: Koji upload speed. In-Reply-To: <48C5A1EB.5010003@ru.bir.ru> References: <48C5A1EB.5010003@ru.bir.ru> Message-ID: <200809081715.29674.dennis@ausil.us> On Monday 08 September 2008 05:06:35 pm Pavel Alexeev (aka Pahan-Hubbitus) wrote: > I have upload speed of packages around 20 KiB/sec. > > $ koji build --scratch --arch-override=i386 dist-f10 > mysql-gui-tools-5.0r12-1.fc9.Hu.14.src.rpm > Uploading srpm: mysql-gui-tools-5.0r12-1.fc9.Hu.14.src.rpm > [= ] 03% 00:01:06 768.00 KiB 16.34 > KiB/sec > > Is it normal and may be there any limitations about I not known? > Or may be I can adjust something? > > I have symmetric connection 4000Mib/sec. its a side effect of the way it uploads. it does so over xml-rpc in chunks. when i update to 1.2.6 it will be better Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From forum at ru.bir.ru Mon Sep 8 22:35:53 2008 From: forum at ru.bir.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Tue, 09 Sep 2008 02:35:53 +0400 Subject: Koji upload speed. In-Reply-To: <200809081715.29674.dennis@ausil.us> References: <48C5A1EB.5010003@ru.bir.ru> <200809081715.29674.dennis@ausil.us> Message-ID: <48C5A8C9.6020903@ru.bir.ru> Dennis Gilmore ?????: > On Monday 08 September 2008 05:06:35 pm Pavel Alexeev (aka Pahan-Hubbitus) > wrote: > >> I have upload speed of packages around 20 KiB/sec. >> >> $ koji build --scratch --arch-override=i386 dist-f10 >> mysql-gui-tools-5.0r12-1.fc9.Hu.14.src.rpm >> Uploading srpm: mysql-gui-tools-5.0r12-1.fc9.Hu.14.src.rpm >> [= ] 03% 00:01:06 768.00 KiB 16.34 >> KiB/sec >> >> Is it normal and may be there any limitations about I not known? >> Or may be I can adjust something? >> >> I have symmetric connection 4000Mib/sec. >> > its a side effect of the way it uploads. it does so over xml-rpc in chunks. > when i update to 1.2.6 it will be better > > Thanks, Denis. I install version 1.2.6-1.fc10 from rawhide and it got speed around 100 KiB/sec not just well as can be, but is significant better. > Dennis From tcallawa at redhat.com Mon Sep 8 22:47:51 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 08 Sep 2008 18:47:51 -0400 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <1220914071.5702.609.camel@localhost.localdomain> On Fri, 2008-09-05 at 10:40 -0500, Matt Domsch wrote: > The following 90 packages have had FTBFS (Fails to Build From Source) > failures for several months, some as far back as February 2008. Matt, Is there any chance you could try to build these packages again? I'm almost done with the license tag cleanups and can start trying to fix these FTBFS items. ~spot From kevin at scrye.com Mon Sep 8 23:06:12 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 8 Sep 2008 17:06:12 -0600 Subject: Xfce SIG meeting tomorrow (2008-09-09) Message-ID: <20080908170612.6296ef35@ohm.scrye.com> Greetings. We would like to try and get together interested folks for a Xfce SIG meeting, tomorrow at 21:00 UTC in the #fedora-meeting channel. We will mostly be going over some more items and patches for F10, and trying to finalize the Xfce spin for F10. All interested parties welcome! Thanks! kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From triad at df.lth.se Mon Sep 8 23:08:21 2008 From: triad at df.lth.se (Linus Walleij) Date: Tue, 09 Sep 2008 01:08:21 +0200 Subject: Boot speedup with readahead In-Reply-To: <6e24a8e80809071552r73cc81banc22a649f68e799eb@mail.gmail.com> References: <20080906212125.27b9b3bb@infradead.org> <48C45503.5070909@BitWagon.com> <6e24a8e80809071552r73cc81banc22a649f68e799eb@mail.gmail.com> Message-ID: <1220915301.9806.3.camel@c83-254-39-236.bredband.comhem.se> m?n 2008-09-08 klockan 00:52 +0200 skrev Mark: > > Shut down and boot an Apple Macintosh running current OS X 10.5.4. > > As part of shutting down, it builds a RAM disk of what will be needed > > at next boot, then saves the RAM disk to hard disk. > I've been wondering if that was possible or not. Now since you told it > is (for mac) i wonder if something like it exists for linux.. At the Ottawa Linux Symposium the following presentation was done: http://tree.celinuxforum.org/CelfPubWiki/OttawaLinuxSymposium2006?action=AttachFile&do=view&target=snapshot-boot-final.pdf The name is "snapshot boot" and it works well for systems with well-written drivers. (Like some embedded...) Linus From kevin.kofler at chello.at Mon Sep 8 23:30:24 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 8 Sep 2008 23:30:24 +0000 (UTC) Subject: Dependency loops considered harmful? References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <48C00D4F.2030004@gmail.com> <1220556463.17785.30.camel@rosebud> Message-ID: Seth Vidal fedoraproject.org> writes: > http://skvidal.fedorapeople.org/misc/remove-recurse.py The big problem with this approach is that it has no way to know whether the package wasn't actually explicitly installed, but just happens to also be a dependency of the package about to be removed. (E.g. if A Requires B and I do: * yum install B * yum install A * yum remove A I don't really expect B to get removed. And AFAIK there are several pairs of packages in Fedora where that situation could apply.) That's why there's all this discussion about tracking that information with a flag in some database. Kevin Kofler From kevin.kofler at chello.at Mon Sep 8 23:49:04 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 8 Sep 2008 23:49:04 +0000 (UTC) Subject: Using rpm for incremental development builds? (was: Dependency loops considered harmful?) References: <20080903165835.GA31342@localhost> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <1220553370.4415.96.camel@localhost.localdomain> <48C05488.5060507@gmail.com> Message-ID: Matthew Woehlke users.sourceforge.net> writes: > Also, it would be *really* nice to be able to build qt-copy and have it > update rpm's database to "know" that I have qt4 already . Are you aware that our qt packages include qt-copy patches and are regularly updated with the latest qt-copy patches? Kevin Kofler From kevin.kofler at chello.at Mon Sep 8 23:54:04 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 8 Sep 2008 23:54:04 +0000 (UTC) Subject: Dependency loops considered harmful? References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <1220553370.4415.96.camel@localhost.localdomain> <48C05488.5060507@gmail.com> <48C06206.9040702@gmail.com> Message-ID: Matthew Woehlke users.sourceforge.net> writes: > Yes, you'd probably need to write a spec file, and you might need to > fiddle with the 'make' step as well to make it more rpmbuild-like. Of > course, something like this could also be integrated with popular build > systems (I'd mainly care about cmake). Maybe CPack can help? You'll probably find some resistance from KDE folks to that idea though (there has been some when a discussion about CPack was held in the past), given that it the packages it produces won't be complying to any guideline. (I definitely _don't_ recommend installing RPMs generated by CPack or any other specfile autogenerator, at least not to folks who don't _really_ know what they're doing.) But it might solve your usecase, and CPack is also being looked at as a possible option by the Window$ and Mac folks, so maybe CPack support is going to be added to KDE after all. Kevin Kofler From michel.sylvan at gmail.com Mon Sep 8 23:57:50 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Mon, 8 Sep 2008 19:57:50 -0400 Subject: Mono - rfc for future developments In-Reply-To: <1220911503.31583.3.camel@PB3.Linux> References: <1220896087.30639.9.camel@PB3.Linux> <1dedbbfc0809081203h4b7f0aatae9be30d7be084fb@mail.gmail.com> <1220911503.31583.3.camel@PB3.Linux> Message-ID: 2008/9/8 Paul : > Hi, > >> >> An alternative is that after a couple of months proving on rawhide, the >> >> rawhide version is pushed to core. >> > >> > I admit I much prefer the latter method, it keeps the stack roughly the same >> > accross releases which means our users have access to the latest bug fixes >> > and a version that is supported by upstream. It also keeps the amount of >> > code actively supported as low as possible. Aggressively pushing vetted >> > versions of the Mono stack seems like the wisest plan to me. As a bonus, we >> > also gain the ability to push the latest and thus often the only supported >> > version of Mono using apps in our stable repos, something our users expect - >> > just watch the Banshee mailing list, not only do our users expect the latest >> > to be available but upstreams first reply to potential problems is nearly >> > always to install the latest supported version. > > Sounds fair enough. I have no problems in doing the push... > >> I concur; the Mono stack seems to be monotonically (pun alert!) >> increasing in usability, that the benefits of maintaining a single >> Mono major version across our supported releases outweigh the >> stability concerns. > > No. Stability is a major issue. Remember what rawhide is there for; it's > the testing ground. I have no problems doing the mono packaging, wait a > few months and then bounce it down to stable, but never at the cost of > stability. Release versions need to be treated with cotton gloves as not > everyone is as brave as us nutjobs! > Um, that was bad phrasing on my part. What I intended to say is that new Mono releases tend to be good enough, that stabilizing any new release in Rawhide for a few months would be good enough, and we don't need to duplicate our testing efforts by packaging another different version for F9. Regards, -- Michel Salim http://hircus.jaiku.com/ From mw_triad at users.sourceforge.net Tue Sep 9 00:04:06 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Mon, 08 Sep 2008 19:04:06 -0500 Subject: Using rpm for incremental development builds? In-Reply-To: References: <20080903165835.GA31342@localhost> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <1220553370.4415.96.camel@localhost.localdomain> <48C05488.5060507@gmail.com> Message-ID: Kevin Kofler wrote: > Matthew Woehlke users.sourceforge.net> writes: >> Also, it would be *really* nice to be able to build qt-copy and have it >> update rpm's database to "know" that I have qt4 already . > > Are you aware that our qt packages include qt-copy patches and are regularly > updated with the latest qt-copy patches? Hmm, no... I guess I could look at the rpm again, but it wouldn't solve the problem for rosegarden, which needs also kdelibs (which would *not* be nearly as up-to-date as the near-daily builds I do). OTOH, I /have/ occasionally had to patch qt, so using an rpm would make that a bit harder. -- Matthew Warning: This message has not been approved by the FDA. From kevin.kofler at chello.at Tue Sep 9 00:08:14 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 9 Sep 2008 00:08:14 +0000 (UTC) Subject: Dependency loops considered harmful? References: <20080903165835.GA31342@localhost> <604aa7910809031026j1ebabc7fyf85307254f451fb6@mail.gmail.com> Message-ID: Jeff Spaleta gmail.com> writes: > the -libs subpackage situations.. im not sure about. I think its case > by case. Does kde3base-libs need kde3base? I dont know. Does > oddjob-libs need oddjob? In the case of the KDE apps, it's a hack to prevent multilib conflicts: if there's a foo-devel which Requires: foo, then foo-devel and foo will both be multilibbed, and foo may cause multilib conflicts. If we now split foo into foo and foo-libs which Require each other, and have foo-devel Requires: foo-libs instead, then suddenly only foo-devel and foo-libs will be multilibbed, foo won't (don't ask me why), so we just need to make sure that the libs which need multilibbing are in foo-libs and the stuff which causes multilib conflicts is in foo (stuff which is the same on both arches can be in either, though the non-multilibbed foo is preferred because it saves space). Credits go to Rex Dieter for that trick. Kevin Kofler From mtasaka at ioa.s.u-tokyo.ac.jp Tue Sep 9 01:50:47 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 09 Sep 2008 10:50:47 +0900 Subject: To freeze, or not to freeze In-Reply-To: <1220908125.17700.41.camel@luminos.localdomain> References: <1220887143.17700.9.camel@luminos.localdomain> <1220889192.6502.42.camel@beck.corsepiu.local> <1220894171.17700.20.camel@luminos.localdomain> <1220907742.6502.70.camel@beck.corsepiu.local> <1220908125.17700.41.camel@luminos.localdomain> Message-ID: <48C5D677.5060201@ioa.s.u-tokyo.ac.jp> Jesse Keating wrote, at 09/09/2008 06:08 AM +9:00: > On Mon, 2008-09-08 at 23:02 +0200, Ralf Corsepius wrote: >> I am developing/testing on FC9 - My rawhide developments are a spin off >> from these => No FC9 updates, no rawhide updates. > > So you develop and test on a different platform than that which you > deploy on? Interesting. Are you saying that all fedora package maintainers must work on rawhide machine?? Mamoru From jkeating at redhat.com Tue Sep 9 02:59:46 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 08 Sep 2008 19:59:46 -0700 Subject: To freeze, or not to freeze In-Reply-To: <48C5D677.5060201@ioa.s.u-tokyo.ac.jp> References: <1220887143.17700.9.camel@luminos.localdomain> <1220889192.6502.42.camel@beck.corsepiu.local> <1220894171.17700.20.camel@luminos.localdomain> <1220907742.6502.70.camel@beck.corsepiu.local> <1220908125.17700.41.camel@luminos.localdomain> <48C5D677.5060201@ioa.s.u-tokyo.ac.jp> Message-ID: <1220929186.17700.45.camel@luminos.localdomain> On Tue, 2008-09-09 at 10:50 +0900, Mamoru Tasaka wrote: > > So you develop and test on a different platform than that which you > > deploy on? Interesting. > > Are you saying that all fedora package maintainers must work > on rawhide machine?? Nothing of the sort. However testing on a rawhide instance before you throw it at rawhide users would be appreciated. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Tue Sep 9 03:05:10 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 8 Sep 2008 19:05:10 -0800 Subject: To freeze, or not to freeze In-Reply-To: <1220929186.17700.45.camel@luminos.localdomain> References: <1220887143.17700.9.camel@luminos.localdomain> <1220889192.6502.42.camel@beck.corsepiu.local> <1220894171.17700.20.camel@luminos.localdomain> <1220907742.6502.70.camel@beck.corsepiu.local> <1220908125.17700.41.camel@luminos.localdomain> <48C5D677.5060201@ioa.s.u-tokyo.ac.jp> <1220929186.17700.45.camel@luminos.localdomain> Message-ID: <604aa7910809082005p58531bc8n4c3f0e9f957d1099@mail.gmail.com> 2008/9/8 Jesse Keating : > Nothing of the sort. However testing on a rawhide instance before you > throw it at rawhide users would be appreciated. Hopefully, rawhide will install in under f9's virt-manager now. I need to go back and confirm that the bug I filed is fixed with regard to network interface not being seen now that rawhide is back up. -jef From peter at thecodergeek.com Tue Sep 9 03:31:06 2008 From: peter at thecodergeek.com (Peter Gordon) Date: Mon, 08 Sep 2008 20:31:06 -0700 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C5190F.7020500@hhs.nl> References: <48C5190F.7020500@hhs.nl> Message-ID: <1220931066.3226.2.camel@tuxhugs> First off: much congrats on the Red Hat position; and I wish you the best in that! Secondly, seeing as I already maintain tremulous it's probably best that I take its data package (tremulous-data) as well. :) Thanks. -- ?Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From Matt_Domsch at dell.com Tue Sep 9 04:11:59 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 8 Sep 2008 23:11:59 -0500 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <1220914071.5702.609.camel@localhost.localdomain> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <1220914071.5702.609.camel@localhost.localdomain> Message-ID: <20080909041159.GA26225@auslistsprd01.us.dell.com> On Mon, Sep 08, 2008 at 06:47:51PM -0400, Tom spot Callaway wrote: > On Fri, 2008-09-05 at 10:40 -0500, Matt Domsch wrote: > > The following 90 packages have had FTBFS (Fails to Build From Source) > > failures for several months, some as far back as February 2008. > > Matt, > > Is there any chance you could try to build these packages again? I'm > almost done with the license tag cleanups and can start trying to fix > these FTBFS items. the rebuild I posted last week should be current enough. Now that there's a new mock release in rawhide fixing a couple bugs that were tripping up several packages, I'll get a new build going though. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From gnomeuser at gmail.com Tue Sep 9 05:08:28 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Tue, 9 Sep 2008 07:08:28 +0200 Subject: Mono - rfc for future developments In-Reply-To: <1220911503.31583.3.camel@PB3.Linux> References: <1220896087.30639.9.camel@PB3.Linux> <1dedbbfc0809081203h4b7f0aatae9be30d7be084fb@mail.gmail.com> <1220911503.31583.3.camel@PB3.Linux> Message-ID: <1dedbbfc0809082208n537cceeaseb7c4d451522b40a@mail.gmail.com> Den 9. sep. 2008 00.05 skrev Paul : > Hi, > > > >> An alternative is that after a couple of months proving on rawhide, > the > > >> rawhide version is pushed to core. > > > > > > I admit I much prefer the latter method, it keeps the stack roughly the > same > > > accross releases which means our users have access to the latest bug > fixes > > > and a version that is supported by upstream. It also keeps the amount > of > > > code actively supported as low as possible. Aggressively pushing vetted > > > versions of the Mono stack seems like the wisest plan to me. As a > bonus, we > > > also gain the ability to push the latest and thus often the only > supported > > > version of Mono using apps in our stable repos, something our users > expect - > > > just watch the Banshee mailing list, not only do our users expect the > latest > > > to be available but upstreams first reply to potential problems is > nearly > > > always to install the latest supported version. > > Sounds fair enough. I have no problems in doing the push... > > > I concur; the Mono stack seems to be monotonically (pun alert!) > > increasing in usability, that the benefits of maintaining a single > > Mono major version across our supported releases outweigh the > > stability concerns. > > No. Stability is a major issue. Remember what rawhide is there for; it's > the testing ground. I have no problems doing the mono packaging, wait a > few months and then bounce it down to stable, but never at the cost of > stability. Release versions need to be treated with cotton gloves as not > everyone is as brave as us nutjobs! You should also not forget about updates-testing as a source of testing. Once we have a 2.0 release or any release deemed stable by upstream which has survived a build in Rawhide we can do a push for the Mono stack to updates-testing. One reason this is a good idea is that we can gain more testers, not everyone is willing to try out rawhide so we can only count on rawhide to remove the rough of edges - getting people to enable the updates-testing repo everytime a leaf application puts out an update though is easy. I'll use Banshee as the example as they have the most elegant way to address this. Each release note comes with instructions on how to install the new goodies on various distros, for Fedora we merely then trick users into doing yum --enablerepo=updates-testing install banshee. Then they automatically agree to become our guinea pigs for the Mono stack and most related items when available, if nothing is being tested at that moment they just get their fix of new shiny mediaplayer software. Slightly evil but users generally seem to desire the new shiny apps and thus are willing to do testing. Tricking them into providing feedback is a bit harder, bodhi is not very easily discoverable - search it for the correct rpm entries is a disaster, which likely means our metric has to be te lack of fall out measured on bugzilla and in the upstream mailing lists. Not all together the best approach but testing feedback is a problem for all of Fedora not just the Mono stack so we are no worse off than any other piece of software in Fedora. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From j.w.r.degoede at hhs.nl Tue Sep 9 05:23:52 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 09 Sep 2008 07:23:52 +0200 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C5369E.8000105@gmail.com> References: <48C5190F.7020500@hhs.nl> <48C5369E.8000105@gmail.com> Message-ID: <48C60868.3070409@hhs.nl> Lyos Gemini Norezel wrote: > Hans de Goede wrote: >> If you are willing to take over any let me know and I'll orphan them >> and you can pick them up. I'll be around for a long time to come to >> answer any questions and help with any issues with them, so don't >> hesitate! >> >> Thanks & Regards, >> >> Hans > > I'd like to take over: arj, id3lib, ksensors, libogg, libtheora, and > libvorbis. > Thanks, I've released them all, so please don't forget to claim ownership, note that multiple people are interested in libao / libogg / libtheora, so that is on a first come first take bases, other people interested can co-mantain. Note: I see that you've already claimed ownership of most, good! But I wasn't finished yet with releasing ksensors for all releases when my laptop battery died on my, so please do not forget to claim ownership for ksensors for F-8 and F-9 . Thanks & Regards, Hans From j.w.r.degoede at hhs.nl Tue Sep 9 05:36:38 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 09 Sep 2008 07:36:38 +0200 Subject: Lonely packages looking for cosy new owner In-Reply-To: <1220884332.3170.42.camel@atropine.boston.devel.redhat.com> References: <48C5190F.7020500@hhs.nl> <1220884332.3170.42.camel@atropine.boston.devel.redhat.com> Message-ID: <48C60B66.7020608@hhs.nl> Adam Jackson wrote: > On Mon, 2008-09-08 at 14:22 +0200, Hans de Goede wrote: >> Hi All, >> >> I still need to write a little blog post of this, but as from Sept 1st >> I've been hired by RedHat to work on anaconda (the installer). As such I >> would like to reduce my package load as much as possible so that I can >> focus fully on my new job. >> >> Thus *all* of my packages are looking for a new owner (I'm not actually >> orphaning them, but I *really* want to lower my load quite a bit). >> >> https://admin.fedoraproject.org/pkgdb/users/packages/jwrdegoede?acls=owner >> >> If you are willing to take over any let me know and I'll orphan them and >> you can pick them up. I'll be around for a long time to come to answer >> any questions and help with any issues with them, so don't hesitate! > > I'll take: > > freetype1 Released. > i2c-tools Released, note I'm really close to upstream, so if you've any troubles please let me know. > lesstif Not owned by me, should not have been shown, buggy pkgdb ?? But we surely can use help here, so feel free to ask for co-maintainer rights. > libid3tag Released > libogg > libtheora > libvorbis Released and already taken by someone else. > libXNVCtrl Released > lm_sensors Not owned by me (buggy pkgdb I guess), besides that I'm part of upstream, so I'll stay involved in this one. > theora-exp As dead as a doornail (integrated into latest libtheora upstream releases), I guess pkgdb doesn't honor dead.package files in CVS, I'll orphan it. > vorbis-tools Not owned by me (again). Thanks for taking these all over! Regards, Hans From j.w.r.degoede at hhs.nl Tue Sep 9 05:39:58 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 09 Sep 2008 07:39:58 +0200 Subject: Lonely packages looking for cosy new owner In-Reply-To: <20080908170522.GN1667@hmsendeavour.rdu.redhat.com> References: <48C5190F.7020500@hhs.nl> <20080908123103.GE1667@hmsendeavour.rdu.redhat.com> <48C53E2E.4020405@hhs.nl> <20080908170522.GN1667@hmsendeavour.rdu.redhat.com> Message-ID: <48C60C2E.9080209@hhs.nl> Neil Horman wrote: > On Mon, Sep 08, 2008 at 05:01:02PM +0200, Hans de Goede wrote: >> Neil Horman wrote: >>> On Mon, Sep 08, 2008 at 02:22:39PM +0200, Hans de Goede wrote: >>>> Hi All, >>>> >>>> I still need to write a little blog post of this, but as from Sept 1st >>>> I've been hired by RedHat to work on anaconda (the installer). As such I >>>> would like to reduce my package load as much as possible so that I can >>>> focus fully on my new job. >>>> >>>> Thus *all* of my packages are looking for a new owner (I'm not actually >>>> orphaning them, but I *really* want to lower my load quite a bit). >>>> >>>> https://admin.fedoraproject.org/pkgdb/users/packages/jwrdegoede?acls=owner >>>> >>>> If you are willing to take over any let me know and I'll orphan them and >>>> you can pick them up. I'll be around for a long time to come to answer >>>> any questions and help with any issues with them, so don't hesitate! >>>> >>>> Thanks & Regards, >>>> >>>> Hans >>>> >>>> -- >>>> fedora-devel-list mailing list >>>> fedora-devel-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-devel-list >>> >>> Sorry, if I wasn't clear on this in my last response, but in addition to >>> coda, >>> I'd also be happy to inherity its dependencies, rvm and rpc2 >> Thanks, >> >> I've released them all, so don't forget to claim ownership or they will >> be considered as orphans in the future. >> > I requested access to cpda, rvm, rpc2 and lwp in the packagedb, but are you sure > you released them? The packagedb still lists you as the owner > Something went wrong with releasing coda, the rest have been picked up by agoode, so I guess you 2 will co-maintain which is always good. I've released coda again. Regards, Hans From j.w.r.degoede at hhs.nl Tue Sep 9 05:42:11 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 09 Sep 2008 07:42:11 +0200 Subject: Lonely packages looking for cosy new owner In-Reply-To: References: <48C5190F.7020500@hhs.nl> Message-ID: <48C60CB3.4020004@hhs.nl> Michel Salim wrote: > On Mon, Sep 8, 2008 at 8:22 AM, Hans de Goede wrote: >> Hi All, >> >> I still need to write a little blog post of this, but as from Sept 1st I've >> been hired by RedHat to work on anaconda (the installer). As such I would >> like to reduce my package load as much as possible so that I can focus fully >> on my new job. > Congrats! (Both to Hans and Red Hat). Anaconda definitely needs more > caring attention. > >> Thus *all* of my packages are looking for a new owner (I'm not actually >> orphaning them, but I *really* want to lower my load quite a bit). > > > I've just requested access to Io-language. Feel free to drop ownership > on the currently-supported releases (though probably not F-8 as that's > going EOL soon anyway) > > I've just given you the rights and released it, so please claim ownership. Thanks, Hans From trond.danielsen at gmail.com Tue Sep 9 05:42:34 2008 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Tue, 9 Sep 2008 07:42:34 +0200 Subject: Packages looking for new owners Message-ID: <409676c70809082242j3061c67dw9049f43e35f3c963@mail.gmail.com> Hi everyone, it is becoming clear to me that I can no longer provide the collection of packages I maintain the love and care that they deserve. If only there were more hours in a day, but the current situation does no leave much room for volunteer work on free software :-(. Hopefully I will find time in the future to return to Fedora related work The list if packages I maintain is available here: https://admin.fedoraproject.org/pkgdb/users/packages/trondd?acls=owner I don't mind keeping libopenraw, avrdude and uisp unless anyone _really_ want to maintain these packages. Best regards, -- Trond Danielsen From j.w.r.degoede at hhs.nl Tue Sep 9 05:48:08 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 09 Sep 2008 07:48:08 +0200 Subject: Lonely packages looking for cosy new owner In-Reply-To: <27257.198.175.55.5.1220879644.squirrel@mail.jcomserv.net> References: <48C5190F.7020500@hhs.nl> <24776.198.175.55.5.1220879480.squirrel@mail.jcomserv.net> <27257.198.175.55.5.1220879644.squirrel@mail.jcomserv.net> Message-ID: <48C60E18.2090407@hhs.nl> Jon Ciesla wrote: >>> If you are willing to take over any let me know and I'll orphan them and >>> you can pick them up. I'll be around for a long time to come to answer >>> any questions and help with any issues with them, so don't hesitate! >> I'd be happy to take liquidwar, pinball, pipenightdreams, supertuxkart, >> and xgalaxy. Possibly others later, but these for now. > > And, logically, tuxkart. > Thanks! I've released them all, yup can leave tuxkart orphaned though, its dead (superceeded by supertuxkart), pkgdb seems to not care about dead.package files in CVS, Regards, Hans From j.w.r.degoede at hhs.nl Tue Sep 9 05:00:40 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 09 Sep 2008 07:00:40 +0200 Subject: To freeze, or not to freeze In-Reply-To: <1220887143.17700.9.camel@luminos.localdomain> References: <1220887143.17700.9.camel@luminos.localdomain> Message-ID: <48C602F8.7060108@hhs.nl> Jesse Keating wrote: > Feature owners in particular, I'm interested in your opinions as to if > you need a few more days to see what shape your features are in before > we freeze. I don't know what the status for the BetterWebcamSupport feature is I must admit. I've been working my but of to get userspace support into place, and that is in good shape for testing now. But the kernel side is going through upstream, and the upstream subsystem maintainer was away for a week, so he has only just send a pull request to Linus to get all the work being done upstream (and then through upstream in rawhide). I'll check when I'm in the office as the internet here in the hotel in Brno is not usable to download kernel stuff. Regards, Hans From j.w.r.degoede at hhs.nl Tue Sep 9 06:07:36 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 09 Sep 2008 08:07:36 +0200 Subject: Lonely packages looking for cosy new owner In-Reply-To: <1220896147.523.39.camel@ignacio.lan> References: <48C5190F.7020500@hhs.nl> <1220896147.523.39.camel@ignacio.lan> Message-ID: <48C612A8.4090408@hhs.nl> Ignacio Vazquez-Abrams wrote: > On Mon, 2008-09-08 at 14:22 +0200, Hans de Goede wrote: >> Thus *all* of my packages are looking for a new owner (I'm not actually >> orphaning them, but I *really* want to lower my load quite a bit). > > I'll take feh, since I'm probably the only person that uses it. > > Thanks, released. Maybe you want to care of imlib2 too then? Regards, Hans From rakesh.pandit at gmail.com Tue Sep 9 06:07:46 2008 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Tue, 9 Sep 2008 11:37:46 +0530 Subject: Packages looking for new owners In-Reply-To: <409676c70809082242j3061c67dw9049f43e35f3c963@mail.gmail.com> References: <409676c70809082242j3061c67dw9049f43e35f3c963@mail.gmail.com> Message-ID: 2008/9/9 Trond Danielsen : > Hi everyone, > > it is becoming clear to me that I can no longer provide the collection > of packages I maintain the love and care that they deserve. If only > there were more hours in a day, but the current situation does no > leave much room for volunteer work on free software :-(. Hopefully I > will find time in the future to return to Fedora related work > > The list if packages I maintain is available here: > https://admin.fedoraproject.org/pkgdb/users/packages/trondd?acls=owner > I don't mind keeping libopenraw, avrdude and uisp unless anyone > _really_ want to maintain these packages. > I am interested in taking gedit plugins and tackle this bug: https://bugzilla.redhat.com/show_bug.cgi?id=460420 , in case nobody wants it. In case others are also interested please join me. /me - chacha_chaudhry on freenode. -- Regards, rakesh From j.w.r.degoede at hhs.nl Tue Sep 9 06:09:44 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 09 Sep 2008 08:09:44 +0200 Subject: Lonely packages looking for cosy new owner In-Reply-To: <1220931066.3226.2.camel@tuxhugs> References: <48C5190F.7020500@hhs.nl> <1220931066.3226.2.camel@tuxhugs> Message-ID: <48C61328.9070306@hhs.nl> Peter Gordon wrote: > First off: much congrats on the Red Hat position; and I wish you the > best in that! > > Secondly, seeing as I already maintain tremulous it's probably best that > I take its data package (tremulous-data) as well. :) > > Thanks. > Good point, released :) Regards, Hans From konrad at tylerc.org Tue Sep 9 06:12:38 2008 From: konrad at tylerc.org (Conrad Meyer) Date: Mon, 8 Sep 2008 23:12:38 -0700 Subject: Packages looking for new owners In-Reply-To: <409676c70809082242j3061c67dw9049f43e35f3c963@mail.gmail.com> References: <409676c70809082242j3061c67dw9049f43e35f3c963@mail.gmail.com> Message-ID: <200809082312.38592.konrad@tylerc.org> Quoth Trond Danielsen: > Hi everyone, > > it is becoming clear to me that I can no longer provide the collection > of packages I maintain the love and care that they deserve. If only > there were more hours in a day, but the current situation does no > leave much room for volunteer work on free software :-(. Hopefully I > will find time in the future to return to Fedora related work > > The list if packages I maintain is available here: > https://admin.fedoraproject.org/pkgdb/users/packages/trondd?acls=owner > I don't mind keeping libopenraw, avrdude and uisp unless anyone > _really_ want to maintain these packages. > > Best regards, > -- > Trond Danielsen I'd like to take sdcc. Regards, -- Conrad Meyer From tim.lauridsen at googlemail.com Tue Sep 9 06:36:46 2008 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Tue, 09 Sep 2008 08:36:46 +0200 Subject: Packages looking for new owners In-Reply-To: <409676c70809082242j3061c67dw9049f43e35f3c963@mail.gmail.com> References: <409676c70809082242j3061c67dw9049f43e35f3c963@mail.gmail.com> Message-ID: <48C6197E.7040806@googlemail.com> Trond Danielsen wrote: > Hi everyone, > > it is becoming clear to me that I can no longer provide the collection > of packages I maintain the love and care that they deserve. If only > there were more hours in a day, but the current situation does no > leave much room for volunteer work on free software :-(. Hopefully I > will find time in the future to return to Fedora related work > > The list if packages I maintain is available here: > https://admin.fedoraproject.org/pkgdb/users/packages/trondd?acls=owner > I don't mind keeping libopenraw, avrdude and uisp unless anyone > _really_ want to maintain these packages. > > Best regards, I will take postr Tim From trond.danielsen at gmail.com Tue Sep 9 06:51:42 2008 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Tue, 9 Sep 2008 08:51:42 +0200 Subject: Packages looking for new owners In-Reply-To: <48C6197E.7040806@googlemail.com> References: <409676c70809082242j3061c67dw9049f43e35f3c963@mail.gmail.com> <48C6197E.7040806@googlemail.com> Message-ID: <409676c70809082351qb4c5ed3m69f550fc017fe9a3@mail.gmail.com> 2008/9/9 Tim Lauridsen : > Trond Danielsen wrote: >> >> Hi everyone, >> >> it is becoming clear to me that I can no longer provide the collection >> of packages I maintain the love and care that they deserve. If only >> there were more hours in a day, but the current situation does no >> leave much room for volunteer work on free software :-(. Hopefully I >> will find time in the future to return to Fedora related work >> >> The list if packages I maintain is available here: >> https://admin.fedoraproject.org/pkgdb/users/packages/trondd?acls=owner >> I don't mind keeping libopenraw, avrdude and uisp unless anyone >> _really_ want to maintain these packages. >> >> Best regards, > > I will take postr Pkgdb requests approved; I've also released ownership so the packaage is all yours. Regards, -- Trond Danielsen From trond.danielsen at gmail.com Tue Sep 9 06:53:32 2008 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Tue, 9 Sep 2008 08:53:32 +0200 Subject: Packages looking for new owners In-Reply-To: <200809082312.38592.konrad@tylerc.org> References: <409676c70809082242j3061c67dw9049f43e35f3c963@mail.gmail.com> <200809082312.38592.konrad@tylerc.org> Message-ID: <409676c70809082353y266baf11md863990433f5e0d0@mail.gmail.com> 2008/9/9 Conrad Meyer : > I'd like to take sdcc. I have released ownership in pkgdb, so the package is all your. Enjoy :-) Regards, -- Trond Danielsen From trond.danielsen at gmail.com Tue Sep 9 06:55:07 2008 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Tue, 9 Sep 2008 08:55:07 +0200 Subject: Packages looking for new owners In-Reply-To: References: <409676c70809082242j3061c67dw9049f43e35f3c963@mail.gmail.com> Message-ID: <409676c70809082355x7fa6b84cj275b140a88cb2113@mail.gmail.com> 2008/9/9 Rakesh Pandit : > 2008/9/9 Trond Danielsen : >> Hi everyone, >> >> it is becoming clear to me that I can no longer provide the collection >> of packages I maintain the love and care that they deserve. If only >> there were more hours in a day, but the current situation does no >> leave much room for volunteer work on free software :-(. Hopefully I >> will find time in the future to return to Fedora related work >> >> The list if packages I maintain is available here: >> https://admin.fedoraproject.org/pkgdb/users/packages/trondd?acls=owner >> I don't mind keeping libopenraw, avrdude and uisp unless anyone >> _really_ want to maintain these packages. >> > > I am interested in taking gedit plugins and tackle this bug: > https://bugzilla.redhat.com/show_bug.cgi?id=460420 , in case nobody wants it. > In case others are also interested please join me. Gedit-plugins have been released in pkgdb so the are yours to take. Regards, -- Trond Danielsen From martin.sourada at gmail.com Tue Sep 9 08:30:08 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Tue, 09 Sep 2008 10:30:08 +0200 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C5190F.7020500@hhs.nl> References: <48C5190F.7020500@hhs.nl> Message-ID: <1220949008.3180.31.camel@pc-notebook> On Mon, 2008-09-08 at 14:22 +0200, Hans de Goede wrote: > Hi All, > > I still need to write a little blog post of this, but as from Sept 1st > I've been hired by RedHat to work on anaconda (the installer). As such I > would like to reduce my package load as much as possible so that I can > focus fully on my new job. > Congrats :) > Thus *all* of my packages are looking for a new owner (I'm not actually > orphaning them, but I *really* want to lower my load quite a bit). > > https://admin.fedoraproject.org/pkgdb/users/packages/jwrdegoede?acls=owner > > If you are willing to take over any let me know and I'll orphan them and > you can pick them up. I'll be around for a long time to come to answer > any questions and help with any issues with them, so don't hesitate! > I am willing to take over libmatroska. > Thanks & Regards, > Thanks, > Hans > Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pbrobinson at gmail.com Tue Sep 9 08:43:08 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 9 Sep 2008 09:43:08 +0100 Subject: To freeze, or not to freeze In-Reply-To: <604aa7910809082005p58531bc8n4c3f0e9f957d1099@mail.gmail.com> References: <1220887143.17700.9.camel@luminos.localdomain> <1220889192.6502.42.camel@beck.corsepiu.local> <1220894171.17700.20.camel@luminos.localdomain> <1220907742.6502.70.camel@beck.corsepiu.local> <1220908125.17700.41.camel@luminos.localdomain> <48C5D677.5060201@ioa.s.u-tokyo.ac.jp> <1220929186.17700.45.camel@luminos.localdomain> <604aa7910809082005p58531bc8n4c3f0e9f957d1099@mail.gmail.com> Message-ID: <5256d0b0809090143w2cda2075x845dc69f202954d5@mail.gmail.com> On Tue, Sep 9, 2008 at 4:05 AM, Jeff Spaleta wrote: > 2008/9/8 Jesse Keating : >> Nothing of the sort. However testing on a rawhide instance before you >> throw it at rawhide users would be appreciated. > > Hopefully, rawhide will install in under f9's virt-manager now. I > need to go back and confirm that the bug I filed is fixed with regard > to network interface not being seen now that rawhide is back up. I installed rawhide on Fedora 9 using the virt-manager last week. Its running using kvm and it works fine, although I had to install tinyproxy on the host to get web traffic but DNS worked fine. Peter From j.w.r.degoede at hhs.nl Tue Sep 9 09:06:10 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 09 Sep 2008 11:06:10 +0200 Subject: Lonely packages looking for cosy new owner In-Reply-To: <1220949008.3180.31.camel@pc-notebook> References: <48C5190F.7020500@hhs.nl> <1220949008.3180.31.camel@pc-notebook> Message-ID: <48C63C82.2030205@hhs.nl> Martin Sourada wrote: > On Mon, 2008-09-08 at 14:22 +0200, Hans de Goede wrote: >> >> If you are willing to take over any let me know and I'll orphan them and >> you can pick them up. I'll be around for a long time to come to answer >> any questions and help with any issues with them, so don't hesitate! >> > I am willing to take over libmatroska. > Thanks, Released. Regards, Hans From akahl at iconmobile.com Tue Sep 9 09:04:33 2008 From: akahl at iconmobile.com (Alexander Kahl) Date: Tue, 09 Sep 2008 11:04:33 +0200 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> (Matt Domsch's message of "Fri, 5 Sep 2008 10:40:06 -0500") References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: Matt Domsch writes: > bmpx-0.40.14-5.fc9 [u'449431 ASSIGNED'] (patch_fuzz) akahl Will fix this one ASAP > libzzub-0.2.3-12.fc9 [u'449661 ASSIGNED'] (patch_fuzz) akahl,mtasaka Would like to orphan, upstream not cooperative enough. Also affects aldrin. From aph at redhat.com Tue Sep 9 09:22:14 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 09 Sep 2008 10:22:14 +0100 Subject: GNU Common Lisp (gcl) - need a new security context? In-Reply-To: <20080908161623.GE17472@hs20-bc2-1.build.redhat.com> References: <20080905194430.2148E61A32C@hormel.redhat.com> <1220889875.27444.9.camel@localhost.localdomain> <20080908161623.GE17472@hs20-bc2-1.build.redhat.com> Message-ID: <48C64046.8050503@redhat.com> Jakub Jelinek wrote: > On Mon, Sep 08, 2008 at 06:04:35PM +0200, G?rard Milmeister wrote: >> On Fri, 2008-09-05 at 16:54 -0400, David A. Wheeler wrote: >>> Dropping gcl is a bad idea. gcl generates much better code in many >>> cases; >>> dropping makes Fedora bad for running Common Lisp (CL) applications. >>> There are a lot of CL programs, and CL is still important; "Practical >>> Common Lisp" >>> was published 2005 and was a really popular book. >> I am not unwilling to continue with GCL. However I would need some help >> from people knowing about these issues (on several architectures) and >> how to fix them. > > See what libffi does, in particular the SELinux related stuff in closures.c. That's a really nasty solution, though. We'd have to get agreement from upstream for this: it would not be good for us to maintain a fork. Andrew. From martin.sourada at gmail.com Tue Sep 9 09:48:51 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Tue, 09 Sep 2008 11:48:51 +0200 Subject: Looking for co-maintainers Message-ID: <1220953731.8385.7.camel@localhost.localdomain> Hi, I heard it's a good practice to have at least two people working on one packages (so that e.g. one does not have time to solve some critical issue due to being on vacation, the others maintainer steps in and solve it). Therefore I am looking for co-maintainer(s) for these packages: gxine [all Fedoras, EPEL5, originally requested also EPEL4, but there are missing deps (namely xine-lib)] xine-plugin [all Fedoras] subtitleeditor [all Fedoras] Any one willing to co-maintain some of those? Thanks, Martin From hughsient at gmail.com Tue Sep 9 09:48:09 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 09 Sep 2008 10:48:09 +0100 Subject: PackageKit 0.3.2 in rawhide Message-ID: <1220953689.11468.6.camel@hughsie-work> PackageKit 0.3.2 was uploaded to rawhide yesterday -- hopefully it should be hitting mirrors today. Please can you try out this new release and report any bugs you find either in bugzilla or by emailing the packagekit mailing list. The big new feature of this release is a new dispatcher, which should improve the interactivity of GUI applications as the yum instance is reused rather than re-loaded each time. There's also the usual set of bugfixes too. The dispatcher should work even with concurrent access from multiple sessions and different locales and proxies as there's quite a bit of logic deciding when to just drop the old instance and create another. Any problems, please yell. Richard. From sundaram at fedoraproject.org Tue Sep 9 10:10:22 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 09 Sep 2008 15:40:22 +0530 Subject: [packagekit] PackageKit 0.3.2 in rawhide In-Reply-To: <1220953689.11468.6.camel@hughsie-work> References: <1220953689.11468.6.camel@hughsie-work> Message-ID: <48C64B8E.7070000@fedoraproject.org> Richard Hughes wrote: > PackageKit 0.3.2 was uploaded to rawhide yesterday -- hopefully it > should be hitting mirrors today. > > Please can you try out this new release and report any bugs you find > either in bugzilla or by emailing the packagekit mailing list. The big > new feature of this release is a new dispatcher, which should improve > the interactivity of GUI applications as the yum instance is reused > rather than re-loaded each time. There's also the usual set of bugfixes > too. > > The dispatcher should work even with concurrent access from multiple > sessions and different locales and proxies as there's quite a bit of > logic deciding when to just drop the old instance and create another. > > Any problems, please yell. Do you plan on doing test builds for Fedora 9? Rahul From rjones at redhat.com Tue Sep 9 10:12:48 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 9 Sep 2008 11:12:48 +0100 Subject: To freeze, or not to freeze In-Reply-To: <1220909954.6502.85.camel@beck.corsepiu.local> References: <1220887143.17700.9.camel@luminos.localdomain> <1220889192.6502.42.camel@beck.corsepiu.local> <1220894171.17700.20.camel@luminos.localdomain> <1220907742.6502.70.camel@beck.corsepiu.local> <1220908125.17700.41.camel@luminos.localdomain> <1220909954.6502.85.camel@beck.corsepiu.local> Message-ID: <20080909101248.GA16108@amd.home.annexia.org> On Mon, Sep 08, 2008 at 11:39:14PM +0200, Ralf Corsepius wrote: > And where's the problem? Are you expecting application devs to run > something as unstable and broken as rawhide? I've been running my laptop on Rawhide throughout the whole of Fedora 10 development. I've had precisely one problem which was due to some fault with temperature sensing on the 2.6.27 kernel (http://kerneltrap.org/mailarchive/linux-kernel/2008/8/12/2910754/thread) Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From bnocera at redhat.com Tue Sep 9 10:14:00 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 09 Sep 2008 11:14:00 +0100 Subject: make force-tag gone Message-ID: <1220955240.24928.69.camel@cookie.hadess.net> I'm pretty sure it was discussed before, and I forcefully ignored it thinking people would realise it was a bad idea to drop it. It's just that it's making us look like idiots in the changelogs, having to bump release for something like that: http://cvs.fedoraproject.org/viewvc/rpms/gvfs/devel/gvfs.spec?r1=1.69&r2=1.70 Bleh. From rawhide at fedoraproject.org Tue Sep 9 10:38:14 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Tue, 9 Sep 2008 10:38:14 +0000 (UTC) Subject: rawhide report: 20080909 changes Message-ID: <20080909103814.D26201F8247@releng2.fedora.phx.redhat.com> New package beep Beep the PC speaker any number of ways New package gresolver Graphical DNS query tool New package hunspell-is Icelandic hunspell dictionaries New package jsr-305 Reference implementations and tests for JSR-305 New package netbeans-platform8 NetBeans Platform 8 New package nted Musical score editor New package perl-Class-Method-Modifiers Provides Moose-like method modifiers New package perl-Module-Install-ExtraTests Ignorable, contextual test support for Module::Install New package perl-RPC-XML Set of classes for core data, message and XML handling New package perl-Tie-ToObject Tie to an existing object New package perl-namespace-clean Keep your namespace tidy New package rubygem-cobbler An interface for interacting with a Cobbler server New package uriparser URI parsing library - RFC 3986 Updated Packages: JSDoc-1.10.2-6.fc10 ------------------- * Mon Sep 8 18:00:00 2008 Mat??j Cepl 1.10.2-6 - add compatibility perl requirements (Close: bug 454075). PackageKit-0.3.2-1.fc10 ----------------------- * Mon Sep 8 18:00:00 2008 Richard Hughes - 0.3.2-1 - New upstream version - This is the first release with the dispatcher functionality that allows backend reuse. This speeds up packagekitd to native speeds when doing repeated similar transactions from the same session and locale. * Mon Sep 8 18:00:00 2008 Richard Hughes - 0.3.1-7 - Enable the smart backend as it's nearly as complete as the yum backend - Disable the yum2 backend (0.3.2 will have a dispatcher instead) - Add subpackages yum and smart, and pull the former in as a dep by default * Mon Sep 8 18:00:00 2008 Richard Hughes - 0.3.1-6 - Own /var/cache/PackageKit and /var/cache/PackageKit/downloads - Fix up some other rpmlint warnings for docs and config(noreplace) * Mon Sep 8 18:00:00 2008 Richard Hughes - 0.3.1-5 - Don't explicitly BR libarchive to silence rpmlint * Mon Sep 8 18:00:00 2008 Richard Hughes - 0.3.1-4 - Split out a -docs subpackage, which shaves of 324Kb of docs from the main package VLGothic-fonts-20080908-1.fc10 ------------------------------ * Tue Sep 9 18:00:00 2008 Akira TAGOH - 20080908-1 - update to 20080908 release. amqp-1.0.693140-1.fc10 ---------------------- * Mon Sep 8 18:00:00 2008 Nuno Santos - 0:1.0.693140-1 - Update for Fedora 10 arj-3.10.22-6.fc10 ------------------ * Mon Sep 8 18:00:00 2008 Robert Scheck 3.10.22-6 - Added patch to refer to original author in the manual page - Added patch to support parallel builds in upstream Makefile at-spi-1.23.92-1.fc10 --------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 1.23.92-1 - Update to 1.23.92 - Drop upstreamed patch balsa-2.3.26-2.fc10 ------------------- * Mon Sep 8 18:00:00 2008 Pawel Salek - 2.3.26-2 - Use deprecated GTK+ interface until upstream fixes their bugs. * Sun Sep 7 18:00:00 2008 Pawel Salek - 2.3.26-1 - update to upstream 2.3.26. * Mon Jul 14 18:00:00 2008 Tom "spot" Callaway - 2.3.25-2 - fix license tag beldi-0.9.20-1.fc10 ------------------- * Tue Sep 9 18:00:00 2008 Christoph Wickert 0.9.20-1 - Upgrade to 0.9.20 cairo-dock-1.6.2.3-1.fc10 ------------------------- * Tue Sep 9 18:00:00 2008 Mamoru Tasaka - 1.6.2.3-1 - 1.6.2.3 claws-mail-3.5.1-0.1.92cvs.fc10 ------------------------------- * Thu Jul 10 18:00:00 2008 Nikolay Vladimirov - 3.5.0-2 - rebuild for libetpan * Mon Jun 30 18:00:00 2008 Andreas Bierfert - 3.5.0-1 - version upgrade (#453405, #448750) - completely fix (#449209) - provide upgrade path from dropped pdf plugin * Tue Jun 17 18:00:00 2008 Andreas Bierfert - 3.4.0-2 - rebuild for libetpan - fix nm support - fix BR (#449209) cmake-2.6.2-0.rc3.1.fc10 ------------------------ * Mon Sep 8 18:00:00 2008 Orion Poplawski - 2.6.2-0.rc3.1 - Update to 2.6.2-RC-2 - Drop parens patch fixed upstream cobbler-1.2.4-1.fc10 -------------------- * Mon Sep 8 18:00:00 2008 Michael DeHaan - 1.2.4-1 - Rebuild devhelp-0.20-1.fc10 ------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 0.20-1 - Update to 0.20 docbook-utils-0.6.14-14.fc10 ---------------------------- * Mon Sep 8 18:00:00 2008 Ondrej Vasik 0.6-14-14 - ship new version of docbook2man-spec.pl to avoid issues with the old one - dropped funcsynopsis patch - docbook2man-spec.pl from tarball used no longer dos2unix-3.1-33.fc10 -------------------- * Mon Sep 8 18:00:00 2008 Tim Waugh 3.1-33 - Preserve file modes (bug #437465). - Fixed manpage grammar (bug #460731). * Mon Apr 14 18:00:00 2008 Tim Waugh 3.1-32 - Adjust license tag (bug #225706). - Fix missing prototype (bug #225706). - Install copy as symbolic links (bug #225706). eclipse-cdt-5.0.0-5.fc10 ------------------------ * Thu Sep 4 18:00:00 2008 Jeff Johnston 5.0.0-5 - Fix for autotools plugin referencing invalid build nature. - Resolves #461201 eel2-2.23.92-1.fc10 ------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 2.23.92-1 - Update to 2.23.92 eog-2.23.92-1.fc10 ------------------ * Mon Sep 8 18:00:00 2008 Matthias Clasen - 2.23.92-1 - Update to 2.23.92 evolution-2.23.92-1.fc10 ------------------------ * Mon Sep 8 18:00:00 2008 Matthew Barnes - 2.23.92-1.fc10 - Update to 2.23.92 evolution-data-server-2.23.92-1.fc10 ------------------------------------ * Mon Sep 8 18:00:00 2008 Matthew Barnes - 2.23.92-1.fc10 - Update to 2.23.92 evolution-exchange-2.23.92-1.fc10 --------------------------------- * Mon Sep 8 18:00:00 2008 Matthew Barnes - 2.23.92-1.fc10 - Update to 2.23.92 facter-1.5.1-1.fc10 ------------------- * Mon Sep 8 18:00:00 2008 David Lutterkort - 1.5.1-1 - New version file-roller-2.23.92-1.fc10 -------------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 2.23.92-1 - Update to 2.23.92 fs_mark-3.3-1.fc10 ------------------ * Mon Sep 8 18:00:00 2008 Eric Sandeen 3.3-1 - New upstream release ganyremote-5.2.1-1.fc10 ----------------------- * Mon Sep 8 18:00:00 2008 Mikhail Fedotov - 5.2.1-1 - Small bugfixes. * Thu Sep 4 18:00:00 2008 Mikhail Fedotov - 5.2-1 - Added "Details" field to the main window. Added French translation. gc-7.1-3.fc10 ------------- * Mon Sep 8 18:00:00 2008 Rex Dieter 7.1-3 - upstream DONT_ADD_BYTE_AT_END patch - spec cosmetics gdm-2.23.92-1.fc10 ------------------ * Mon Sep 8 18:00:00 2008 Jon McCann - 1:2.23.92-1 - Update to 2.23.92-1 gedit-2.23.92-1.fc10 -------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 1:2.23.92-1 - Update to 2.23.92 gnome-backgrounds-2.23.92-1.fc10 -------------------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 2.23.92-1 - Update to 2.23.92 gnome-desktop-2.23.92-1.fc10 ---------------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 2.23.92-1 - Update to 2.23.92 gnome-games-2.23.92-1.fc10 -------------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 1:2.23.92-1 - Update to 2.23.92 - Adapt to api changes in the ggz snapshot we ship gnome-icon-theme-2.23.92-1.fc10 ------------------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 2.23.92-1 - Update to 2.23.92 gnome-media-2.23.92-1.fc10 -------------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen 2.23.92-1 - Update to 2.23.92 gnome-menus-2.23.92-1.fc10 -------------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 2.23.92-1 - Update to 2.23.92 gnome-packagekit-0.3.2-1.fc10 ----------------------------- * Mon Sep 8 18:00:00 2008 Richard Hughes - 0.3.2-1 - Update to newest upstream version. * Thu Aug 28 18:00:00 2008 Richard Hughes - 0.3.1-3 - Bump because the PackageKit-devel rpm was empty. * Thu Aug 28 18:00:00 2008 Richard Hughes - 0.3.1-2 - Bump as make chainbuild is broken, so we'll have to do this in two steps. * Wed Aug 27 18:00:00 2008 Richard Hughes - 0.3.1-1 - Update to newest upstream version. * Fri Aug 22 18:00:00 2008 Richard Hughes - 0.3.0-1 - Update to newest upstream version. * Mon Aug 4 18:00:00 2008 Robin Norwood - 0.2.4-3 - Fix Source0 URL. gnome-panel-2.23.92-1.fc10 -------------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 2.23.92-1 - Update to 2.23.92 gnome-session-2.23.92-1.fc10 ---------------------------- * Mon Sep 8 18:00:00 2008 Jon McCann - 2.23.92-1 - Update to 2.23.92 gnome-settings-daemon-2.23.92-1.fc10 ------------------------------------ * Mon Sep 8 18:00:00 2008 Matthias Clasen - 2.23.92-1 - Update to 2.23.92 gnome-themes-2.23.92-1.fc10 --------------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 2.23.92-1 - Update to 2.23.92 gnome-utils-2.23.92-2.fc10 -------------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 1:2.23.92-1 - Update to 2.23.92 gnubg-0.9.0.1-1.fc10 -------------------- * Fri Sep 5 18:00:00 2008 Jon Ciesla - 1:0.9.0.1-1 - Update to latest version, BZ 461281. gtkdatabox-0.9.0.1-1.fc10 ------------------------- * Mon Sep 8 18:00:00 2008 Eric Work 0.9.0.1-1 - new upstream version - drop patch gcallback gtkhtml3-3.23.92-1.fc10 ----------------------- * Mon Sep 8 18:00:00 2008 Matthew Barnes - 3.23.92-1.fc10 - Update to 3.23.92 gtksourceview2-2.3.3-1.fc10 --------------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 2.3.3-1 - Update to 2.3.3 hunspell-bn-20080201-1.fc10 --------------------------- * Mon Sep 8 18:00:00 2008 Parag - 20080201-1 - update to latest release. hunspell-da-1.7.24-1.fc10 ------------------------- * Mon Sep 8 18:00:00 2008 Caolan McNamara - 1.7.24-1 - latest version hunspell-fo-0.2.34-1.fc10 ------------------------- * Mon Sep 8 18:00:00 2008 Caolan McNamara - 0.2.34-1 - latest version ibus-0.1.1.20080908-1.fc10 -------------------------- * Mon Sep 8 18:00:00 2008 Huang Peng - 0.1.1.20080908-1 - Update to 0.1.1.20080908. ivtv-firmware-20080701-18 ------------------------- * Sun Aug 24 18:00:00 2008 Axel Thimm - 2:20080701-18 - Update to 20080701. jd-2.0.1-0.2.svn2322_trunk.fc10 ------------------------------- * Tue Sep 9 18:00:00 2008 Mamoru Tasaka - rev 2322 - Set xdg-open as default browser now by configure option kanyremote-5.2.1-2.fc10 ----------------------- * Mon Sep 8 18:00:00 2008 Mikhail Fedotov - 5.2.1-1 - Small bugfixes. * Thu Sep 4 18:00:00 2008 Mikhail Fedotov - 5.2-1 - Added "Details" field to the main window. Added French translation. keyjnote-0.10.2-2.fc10 ---------------------- * Sat Sep 6 18:00:00 2008 Allisson Azevedo 0.10.2-2 - Rebuild for F-10 libgweather-2.23.92-1.fc10 -------------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen 2.23.92-1 - Update to 2.23.92 libsoup-2.23.92-1.fc10 ---------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 2.23.92-1 - Update to 2.23.92 libvirt-0.4.5-1.fc10 -------------------- * Mon Sep 8 18:00:00 2008 Daniel Veillard - 0.4.5-1.fc10 - upstream release 0.4.5 - update libwnck-2.23.92-1.fc10 ---------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 2.23.92-1 - Update to 2.23.92 lilypond-2.11.57-1.fc10 ----------------------- * Mon Sep 8 18:00:00 2008 Jon Ciesla - 2.11.57-1 - Upgrade to new upstream. * Wed Aug 27 18:00:00 2008 Jon Ciesla - 2.10.33-4 - Spec cleanup, fix for BZ 456842, vim file locations. * Mon Apr 7 18:00:00 2008 Christopher Aillon - 2.10.33-3 - Fix the build against GCC 4.3; simply missing some #includes * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 2.10.33-2 - Autorebuild for GCC 4.3 lostirc-0.4.6-6.fc10 -------------------- * Mon Sep 8 18:00:00 2008 Christoph Wickert - 0.4.6-6 - Fix FTBFS bug (#440921) * Thu Aug 7 18:00:00 2008 Tom "spot" Callaway - 0.4.6-5 - fix license tag * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 0.4.6-4 - Autorebuild for GCC 4.3 midori-0.0.20-2.fc10 -------------------- mousetweaks-2.23.92-1.fc10 -------------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 2.23.92-1 - Update to 2.23.92 nautilus-2.23.92-1.fc10 ----------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 2.23.92-1 - Update to 2.23.92 openmsx-0.6.3-4.fc10 -------------------- * Sun Sep 7 18:00:00 2008 Hans de Goede 0.6.3-4 - Fix patch fuzz build failure orca-2.23.92-1.fc10 ------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 2.23.92-1 - Update to 2.23.92 pam-1.0.2-1.fc10 ---------------- * Mon Sep 8 18:00:00 2008 Tomas Mraz 1.0.2-1 - pam_loginuid: uids are unsigned (#460241) - new minor upstream release - use external db4 - drop tests for not pulling in libpthread (as NPTL should be safe) pango-1.21.6-1.fc10 ------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 1.21.6-1 - Update to 1.21.6 perl-CGI-Ajax-0.706-1.fc10 -------------------------- * Mon Sep 8 18:00:00 2008 Chris Weyl 0.706-1 - update to 0.706 perl-Config-IniHash-3.00.00-1.fc10 ---------------------------------- * Mon Sep 8 18:00:00 2008 Chris Weyl 3.00.00-1 - update to 3.00.00 perl-DateTime-0.4304-2.fc10 --------------------------- * Mon Sep 8 18:00:00 2008 Steven Pritchard 1:0.4304-2 - Update to DateTime::TimeZone 0.7904. perl-MooseX-Getopt-0.15-1.fc10 ------------------------------ * Mon Sep 8 18:00:00 2008 Chris Weyl 0.15-1 - update to 0.15 * Thu Jul 10 18:00:00 2008 Chris Weyl 0.13-2 - tweak Getopt::Long dep to 2.35; passes tests just fine with 2.35, and that's what we have in F-8 perl * Sat Jun 28 18:00:00 2008 Chris Weyl 0.13-1 - update to 0.13 - switch to Module::Install invocations, rather than Module::Build plague-0.4.5.5-1.fc10 --------------------- * Mon Sep 8 18:00:00 2008 Michael Schwendt - 0.4.5.5-1 - update to 0.4.5.5 plymouth-0.6.0-0.2008.09.05.4.fc10 ---------------------------------- * Mon Sep 8 18:00:00 2008 Ray Strode 0.5.0-0.2008.09.05.4 - More serial console fixes (bug 460565 again) policycoreutils-2.0.55-5.fc10 ----------------------------- * Mon Sep 8 18:00:00 2008 Dan Walsh 2.0.55-5 - Add node support to semanage * Mon Sep 8 18:00:00 2008 Dan Walsh 2.0.55-4 - Fix fixfiles to correct unlabeled_t files and remove .? files ppl-0.9-24.fc10 --------------- * Mon Sep 8 18:00:00 2008 Roberto Bagnara 0.9-24 - Changed ppl-0.9-swiprolog.patch so as to invoke `plld' with the `-v' option. * Mon Sep 8 18:00:00 2008 Roberto Bagnara 0.9-23 - Fixed ppl-0.9-swiprolog.patch. * Mon Sep 8 18:00:00 2008 Roberto Bagnara 0.9-22 - Implemented a workaround to cope with the new location of SWI-Prolog.h. * Mon Sep 8 18:00:00 2008 Roberto Bagnara 0.9-21 - Fixed the SWI-Prolog interface dependencies. * Mon May 19 18:00:00 2008 Roberto Bagnara 0.9-20 - Added Requires /sbin/ldconfig. pulseaudio-0.9.12-2.fc10 ------------------------ * Tue Sep 9 18:00:00 2008 Lennart Poettering 0.9.12-2 - Add intltool to deps * Tue Sep 9 18:00:00 2008 Lennart Poettering 0.9.12-1 - Release 0.9.12 pyclutter-0.6.2-1.fc10 ---------------------- python-qpid-0.3.693140-1.fc10 ----------------------------- * Mon Sep 8 18:00:00 2008 Nuno Santos - 0.3.693140-1 - Update for Fedora 10 qpidc-0.3.693140-1.fc10 ----------------------- * Mon Sep 8 18:00:00 2008 Nuno Santos - 0.3.693140-1 - Update for Fedora 10 qt-4.4.1-3.fc10 --------------- * Mon Sep 8 18:00:00 2008 Rex Dieter - 4.4.1-3 - apply QMAKEPATH portion of multilib patch only if needed - qt-copy-patches-20080908 rdiff-backup-1.2.1-1.fc10 ------------------------- * Mon Sep 8 18:00:00 2008 Kevin Fenzi - 1.2.1-1 - Update to 1.2.1 readahead-1.4.6-1.fc10 ---------------------- * Mon Sep 8 18:00:00 2008 Harald Hoyer 1.4.6-1 - fixed the selinux=off case rsync-3.0.4-0.fc10 ------------------ * Mon Sep 8 18:00:00 2008 Simo Sorce 3.0.4-0.fc10 - New upstream bugfix release scorched3d-41.3-3.fc10 ---------------------- * Sun Sep 7 18:00:00 2008 Hans de Goede 41.3-3 - Fix patch fuzz build failure selinux-policy-3.5.7-1.fc10 --------------------------- * Fri Sep 5 18:00:00 2008 Dan Walsh 3.5.7-1 - Remove gamin policy slang-2.1.4-1.fc10 ------------------ * Mon Sep 8 18:00:00 2008 Miroslav Lichvar - 2.1.4-1 - update to 2.1.4 sound-juicer-2.23.3-1.fc10 -------------------------- * Mon Sep 8 18:00:00 2008 - Bastien Nocera - 2.23.3-1 - Update to 2.23.3 supertuxkart-0.5-2.fc10 ----------------------- * Sun Sep 7 18:00:00 2008 Hans de Goede 0.5-2 - Fix patch fuzz build failure * Tue Jun 3 18:00:00 2008 Hans de Goede 0.5-1 - New upstream release 0.5 swfdec-0.8.0-1.fc10 ------------------- * Mon Sep 8 18:00:00 2008 Brian Pepple - 0.8.0-1 - Update to 0.8.0. system-config-boot-0.2.21-1.fc10 -------------------------------- * Mon Sep 8 18:00:00 2008 Harald Hoyer - 0.2.21-1 - removed .png from icon entry in the desktop file tclabc-1.1.0-2.fc10 ------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway 1.1.0-2 - fix license tag tcptraceroute-1.5-0.6.beta7.fc10 -------------------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway 1.5-0.6.beta7 - fix license tag tcputils-0.6.2-4.fc10 --------------------- * Sat Sep 6 18:00:00 2008 Allisson Azevedo 0.6.2-4 - Rebuild for F-10 tenr-de-styles-pkg-1.1-2.fc10 ----------------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 1.1-2 - fix license tag testoob-1.13-5.fc10 ------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway 1.13-5 - fix license tag tetex-bytefield-1.2a-4.fc10 --------------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 1.2a-4 - fix license tag - update source (no version change) tetex-font-cm-lgc-0.5-10.fc10 ----------------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 0.5-10 - fix license tag tetex-fonts-hebrew-0.1-9.fc10 ----------------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway 0.1-9 - fix license tag tetex-perltex-1.7-1.fc10 ------------------------ * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 1.7-1 - fix license tag - update to 1.7 tetex-prosper-1.5-4.fc10 ------------------------ * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 1.5-4 - fix license tag themes-backgrounds-gnome-0.5-1.fc10 ----------------------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 0.5-1 - massive licensing audit, some files removed, licensing attribution done properly thewidgetfactory-0.2.1-8.fc10 ----------------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 0.2.1-8 - fix license tag * Fri Feb 22 17:00:00 2008 Luya Tshimbalanga - 0.2.1-7 - Added libcap-devel for dependancy tinyca2-0.7.5-4.fc10 -------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 0.7.5-4 - fix license tag tinyfugue-5.0-0.9.b8.fc10 ------------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 5.0-0.9.b8 - fix license tag tkcvs-8.1-2.fc10 ---------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 8.1-2 - fix license tag tog-pegasus-2.7.1-2.fc10 ------------------------ * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 2:2.7.1-2 - fix license tag tomboy-0.11.3-2.fc10 -------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 0.11.3-2 - fix license tag tomoe-0.6.0-6.fc10 ------------------ * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 0.6.0-6 - fix license tag totem-2.23.91-3.fc10 -------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 2.23.91-3 - fix license tag trac-git-plugin-0.0.1-6.20070705svn1536.fc10 -------------------------------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 0.0.1-6.20070705svn1536 - fix license tag trac-mercurial-plugin-0.10.0.2-4.20070705svn5798.fc10 ----------------------------------------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 0.10.0.2-4.20070705svn5798 - fix license tag transfig-3.2.5-3.fc10 --------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 1:3.2.5-3 - fix license tag transmission-1.33-2.fc10 ------------------------ * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 1.33-2 - fix license tag tripwire-2.4.1.2-6.fc10 ----------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 2.4.1.2-6 - fix license tag ttmkfdir-3.0.9-27.fc10 ---------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 3.0.9-27 - fix license tag turba-2.2.1-2.fc10 ------------------ * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 2.2.1-2 - fix license tag tuxpaint-0.9.20-1.fc10 ---------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 1:0.9.20-1 - update to 0.9.20 * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 1:0.9.17-4 - fix license tag tuxpaint-stamps-2008.06.30-1.fc10 --------------------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway 2008.06.30-1 - fix license tag - update to 2008.06.30. tuxtype2-1.5.3-4.fc10 --------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 1.5.3-4 - fix license tag ucblogo-5.5-11.fc10 ------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 5.5-11 - fix license tag uisp-20050207-4.fc10 -------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 20050207-4 - fix patch * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 20050207-3 - fix license tag unix2dos-2.2-32.fc10 -------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway 2.2-32 - fix license tag * Mon Sep 8 18:00:00 2008 Tim Waugh 2.2-31 - Removed patch fuzz. - Preserve file modes (bug #437469). - Fixed grammar in man page (bug #460731). - Explicitly apply patch0. urw-fonts-2.4-6.fc10 -------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway 2.4-6 - fix license tag varnish-2.0-0.8.beta1.fc10 -------------------------- * Tue Sep 9 18:00:00 2008 Ingvar Hagelund - 2.0-0.8.beta1 - Added a patch from r3171 that fixes an endian bug on ppc and ppc64 - Added a hack that changes the varnishtest ports for 64bits builds, so they can run in parallell with 32bits build on same build host * Tue Sep 2 18:00:00 2008 Ingvar Hagelund - 2.0-0.7.beta1 - Added a patch from r3156 and r3157, hiding a legit errno in make check * Tue Sep 2 18:00:00 2008 Ingvar Hagelund - 2.0-0.6.beta1 - Added a commented option for max coresize in the sysconfig script - Added a comment in README.redhat about upgrading from 1.x to 2.0 * Fri Aug 29 18:00:00 2008 Ingvar Hagelund - 2.0-0.5.beta1 - Bumped version numbers and source url for first beta release \o/ - Added a missing directory to the libs-devel package (Michael Schwendt) - Added the LICENSE file to the libs-devel package - Moved make check to its proper place - Removed superfluous definition of lockfile in initscripts * Wed Aug 27 18:00:00 2008 Ingvar Hagelund - 2.0-0.4.20080827svn3136 - Fixed up init script for varnishlog too * Mon Aug 25 18:00:00 2008 Ingvar Hagelund - 2.0-0.3.20080825svn3125 - Fixing up init script according to newer Fedora standards - The build now runs the test suite after compiling - Requires initscripts - Change default.vcl from nothing but comments to point to localhost:80, * Mon Aug 18 18:00:00 2008 Ingvar Hagelund - 2.0-0.2.tp2 - Changed source, version and release to match 2.0-tp2 * Thu Aug 14 18:00:00 2008 Ingvar Hagelund - 2.0-0.1.20080814svn - default.vcl has moved - Added groff to build requirements vegastrike-0.5.0-4.fc10 ----------------------- * Sun Sep 7 18:00:00 2008 Hans de Goede 0.5.0-4 - Fix patch fuzz build failure viaideinfo-0.5-3.fc10 --------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 0.5-3 - fix license tag vim-7.2.013-1.fc10 ------------------ * Mon Sep 8 18:00:00 2008 Karsten Hopp 7.2.013-1 - patchlevel 13 vim-vimoutliner-0.3.4-10.fc10 ----------------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 0.3.4-10 - fix license tag vinagre-2.23.92-1.fc10 ---------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 2.23.92-1 - Update to 2.23.92 vino-2.23.92-1.fc10 ------------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 2.23.92-1 - Update to 2.23.92 vkeybd-0.1.17a-8.fc10 --------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 0.1.17a-8 - fix license tag vlock-1.3-27.fc10 ----------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 1.3-27 - fix license tag vsftpd-2.0.7-1.fc10 ------------------- * Mon Sep 8 18:00:00 2008 Tom "spot" Callaway - 2.0.7-1 - fix license tag - update to 2.0.7 vte-0.17.3-1.fc10 ----------------- * Mon Sep 8 18:00:00 2008 Matthias Clasen - 0.17.3-1 - Update to 0.17.3 xastir-1.9.4-2.fc10 ------------------- * Mon Sep 8 18:00:00 2008 Lucian Langa - 1.9.4-2 - update Build requires * Sun Sep 7 18:00:00 2008 Lucian Langa - 1.9.4-1 - new upstream 1.9.4 - drop wget and IM patch (fixed upstream) xdg-user-dirs-gtk-0.8-2.fc10 ---------------------------- * Mon Sep 8 18:00:00 2008 Tomas Bzatek - 0.8-2 - Require intltool * Fri Sep 5 18:00:00 2008 Matthias Clasen - 0.8-1 - Update to 0.8 xgalaxy-2.0.34-9.fc10 --------------------- * Sun Sep 7 18:00:00 2008 Hans de Goede 2.0.34-9 - Fix patch fuzz build failure xorg-x11-apps-7.3-5.fc10 ------------------------ * Tue Sep 9 18:00:00 2008 Peter Hutterer 7.3-5 - Add xinput tool. xorg-x11-drv-ati-6.9.0-10.fc10 ------------------------------ * Mon Sep 8 18:00:00 2008 Adam Jackson 6.9.0-10 - radeon-6.9.0-fb-size.patch: Yet more lame heuristics to preallocate a usable framebuffer for laptops. (#458864) xorg-x11-drv-i810-2.4.2-5.fc10 ------------------------------ xorg-x11-drv-nv-2.1.12-2.fc10 ----------------------------- * Mon Sep 8 18:00:00 2008 Adam Jackson 2.1.12-2 - nv-2.1.12-fb-size.patch: Yet more lame heuristics to preallocate a usable framebuffer for laptops. (#458864) xorg-x11-drv-synaptics-0.15.0-6.fc10 ------------------------------------ * Mon Sep 8 18:00:00 2008 Peter Hutterer 0.15.0-6 - xf86-input-synaptics-0.15.0-edges.patch: updated to improve edge calculation and acceleration factors. - xf86-input-synaptics-0.15.0-preprobe patch: pre-probe eventcomm devices for axis ranges if specifed with Device option. - update fdi file to support "bcm5974" devices. Summary: Added Packages: 13 Removed Packages: 0 Modified Packages: 140 Broken deps for i386 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 ganyremote-5.2.1-1.fc10.noarch requires anyremote >= 0:4.8 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.12-1.fc10.i386 requires perl(MT::Plugin) highlight-2.6.12-1.fc10.i386 requires perl(MT::WeblogPublisher) highlight-2.6.12-1.fc10.i386 requires perl(MT::Entry) highlight-2.6.12-1.fc10.i386 requires perl(MT) highlight-2.6.12-1.fc10.i386 requires perl(MT::Template::Context) kanyremote-5.2.1-2.fc10.noarch requires anyremote >= 0:4.8 mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so poker3d-1.1.36-10.fc10.i386 requires libosg.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgUtil.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgSim.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgTerrain.so.35 poker3d-1.1.36-10.fc10.i386 requires libOpenThreads.so.10 poker3d-1.1.36-10.fc10.i386 requires libosgGA.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgFX.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgManipulator.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgDB.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgParticle.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgViewer.so.35 poker3d-1.1.36-10.fc10.i386 requires libosgText.so.35 pyclutter-0.6.2-1.fc10.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-1.fc10.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-1.fc10.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-1.fc10.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-1.fc10.i386 requires libclutter-gtk-0.6.so.0 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so swfdec-gnome-2.23.2-1.fc10.i386 requires libswfdec-0.7.so.1 swfdec-gnome-2.23.2-1.fc10.i386 requires libswfdec-gtk-0.7.so.1 swfdec-mozilla-0.7.4-1.fc10.i386 requires libswfdec-0.7.so.1 swfdec-mozilla-0.7.4-1.fc10.i386 requires libswfdec-gtk-0.7.so.1 vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for x86_64 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) ganyremote-5.2.1-1.fc10.noarch requires anyremote >= 0:4.8 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.12-1.fc10.x86_64 requires perl(MT::Plugin) highlight-2.6.12-1.fc10.x86_64 requires perl(MT::WeblogPublisher) highlight-2.6.12-1.fc10.x86_64 requires perl(MT::Entry) highlight-2.6.12-1.fc10.x86_64 requires perl(MT) highlight-2.6.12-1.fc10.x86_64 requires perl(MT::Template::Context) kanyremote-5.2.1-2.fc10.noarch requires anyremote >= 0:4.8 mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgFX.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgGA.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgTerrain.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosg.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgSim.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgText.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgDB.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libOpenThreads.so.10()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgManipulator.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgParticle.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgViewer.so.35()(64bit) poker3d-1.1.36-10.fc10.x86_64 requires libosgUtil.so.35()(64bit) pyclutter-0.6.2-1.fc10.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-1.fc10.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-1.fc10.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-1.fc10.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-1.fc10.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) swfdec-gnome-2.23.2-1.fc10.x86_64 requires libswfdec-0.7.so.1()(64bit) swfdec-gnome-2.23.2-1.fc10.x86_64 requires libswfdec-gtk-0.7.so.1()(64bit) swfdec-mozilla-0.7.4-1.fc10.x86_64 requires libswfdec-0.7.so.1()(64bit) swfdec-mozilla-0.7.4-1.fc10.x86_64 requires libswfdec-gtk-0.7.so.1()(64bit) vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for ppc ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) ganyremote-5.2.1-1.fc10.noarch requires anyremote >= 0:4.8 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.12-1.fc10.ppc requires perl(MT::Plugin) highlight-2.6.12-1.fc10.ppc requires perl(MT::WeblogPublisher) highlight-2.6.12-1.fc10.ppc requires perl(MT::Entry) highlight-2.6.12-1.fc10.ppc requires perl(MT) highlight-2.6.12-1.fc10.ppc requires perl(MT::Template::Context) kanyremote-5.2.1-2.fc10.noarch requires anyremote >= 0:4.8 mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so poker3d-1.1.36-10.fc10.ppc requires libosg.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgUtil.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgSim.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgTerrain.so.35 poker3d-1.1.36-10.fc10.ppc requires libOpenThreads.so.10 poker3d-1.1.36-10.fc10.ppc requires libosgGA.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgFX.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgManipulator.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgDB.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgParticle.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgViewer.so.35 poker3d-1.1.36-10.fc10.ppc requires libosgText.so.35 pyclutter-0.6.2-1.fc10.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-1.fc10.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-1.fc10.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-1.fc10.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-1.fc10.ppc requires libclutter-gtk-0.6.so.0 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires libbfd-2.18.50.0.8-2.fc10.so stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires libopcodes-2.18.50.0.8-2.fc10.so swfdec-gnome-2.23.2-1.fc10.ppc requires libswfdec-0.7.so.1 swfdec-gnome-2.23.2-1.fc10.ppc requires libswfdec-gtk-0.7.so.1 swfdec-mozilla-0.7.4-1.fc10.ppc requires libswfdec-0.7.so.1 swfdec-mozilla-0.7.4-1.fc10.ppc requires libswfdec-gtk-0.7.so.1 vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for ppc64 ---------------------------------------------------------- eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) ganyremote-5.2.1-1.fc10.noarch requires anyremote >= 0:4.8 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave highlight-2.6.12-1.fc10.ppc64 requires perl(MT::Plugin) highlight-2.6.12-1.fc10.ppc64 requires perl(MT::WeblogPublisher) highlight-2.6.12-1.fc10.ppc64 requires perl(MT::Entry) highlight-2.6.12-1.fc10.ppc64 requires perl(MT) highlight-2.6.12-1.fc10.ppc64 requires perl(MT::Template::Context) kanyremote-5.2.1-2.fc10.noarch requires anyremote >= 0:4.8 livecd-tools-018-1.fc10.ppc64 requires yaboot mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-Module-CPANTS-Analyse-0.75-3.fc9.noarch requires perl(Module::ExtractUse) perl-Module-CPANTS-Analyse-0.75-3.fc9.noarch requires perl(Archive::Any) perl-Module-CPANTS-Analyse-0.75-3.fc9.noarch requires perl(Archive::Any) >= 0:0.06 perl-Module-CPANTS-Analyse-0.75-3.fc9.noarch requires perl(Module::ExtractUse) >= 0:0.18 perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 poker3d-1.1.36-10.fc10.ppc64 requires libosgFX.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgGA.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgTerrain.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosg.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgSim.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgText.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgDB.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libOpenThreads.so.10()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgManipulator.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgParticle.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgViewer.so.35()(64bit) poker3d-1.1.36-10.fc10.ppc64 requires libosgUtil.so.35()(64bit) pyclutter-0.6.2-1.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-1.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-1.fc10.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-1.fc10.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-1.fc10.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) swfdec-gnome-2.23.2-1.fc10.ppc64 requires libswfdec-0.7.so.1()(64bit) swfdec-gnome-2.23.2-1.fc10.ppc64 requires libswfdec-gtk-0.7.so.1()(64bit) swfdec-mozilla-0.7.4-1.fc10.ppc64 requires libswfdec-0.7.so.1()(64bit) swfdec-mozilla-0.7.4-1.fc10.ppc64 requires libswfdec-gtk-0.7.so.1()(64bit) vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 From denis at poolshark.org Tue Sep 9 10:37:46 2008 From: denis at poolshark.org (Denis Leroy) Date: Tue, 09 Sep 2008 12:37:46 +0200 Subject: make force-tag gone In-Reply-To: <1220955240.24928.69.camel@cookie.hadess.net> References: <1220955240.24928.69.camel@cookie.hadess.net> Message-ID: <48C651FA.7080305@poolshark.org> Bastien Nocera wrote: > I'm pretty sure it was discussed before, and I forcefully ignored it > thinking people would realise it was a bad idea to drop it. > > It's just that it's making us look like idiots in the changelogs, having > to bump release for something like that: > http://cvs.fedoraproject.org/viewvc/rpms/gvfs/devel/gvfs.spec?r1=1.69&r2=1.70 Yes please put force-tag: back, or make 'scratch-build' without a branch tag. From redhat at olen.net Tue Sep 9 10:59:25 2008 From: redhat at olen.net (Ola Thoresen) Date: Tue, 09 Sep 2008 12:59:25 +0200 Subject: Boot speedup with readahead In-Reply-To: <1220907540.17700.30.camel@luminos.localdomain> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220907540.17700.30.camel@luminos.localdomain> Message-ID: <48C6570D.4090605@olen.net> Jesse Keating wrote: > On Mon, 2008-09-08 at 15:28 -0500, Callum Lerwick wrote: >> We still need to trigger pre-linking after yum transactions rather than >> by a cron job... > > So that we can have an "Optimizing harddrive" phase during updates like > OSX does? that'd be awesome... > Prelink is fine, but please don't "optimize" my brand new SSD-drive! =;-) Rgds. Ola Thhoresen -- _,--', _._.--._____ .--.--';_'-.', ";_ _.,-' Ola Thoresen .'--'. _.' {`'-;_ .-.>.' '-:_ ) / `' '=. It is easier to fix Unix ) > {_/, /~) than to live with Windows |/ `^ .' From ivazqueznet at gmail.com Tue Sep 9 07:22:45 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 09 Sep 2008 03:22:45 -0400 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C612A8.4090408@hhs.nl> References: <48C5190F.7020500@hhs.nl> <1220896147.523.39.camel@ignacio.lan> <48C612A8.4090408@hhs.nl> Message-ID: <1220944965.523.53.camel@ignacio.lan> On Tue, 2008-09-09 at 08:07 +0200, Hans de Goede wrote: > Ignacio Vazquez-Abrams wrote: > > On Mon, 2008-09-08 at 14:22 +0200, Hans de Goede wrote: > >> Thus *all* of my packages are looking for a new owner (I'm not actually > >> orphaning them, but I *really* want to lower my load quite a bit). > > > > I'll take feh, since I'm probably the only person that uses it. > > > > > > Thanks, released. Maybe you want to care of imlib2 too then? Someone else already seems to own it. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From debarshi.ray at gmail.com Tue Sep 9 11:03:03 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Tue, 9 Sep 2008 16:33:03 +0530 Subject: Packaging Cherokee In-Reply-To: <3170f42f0808241209w8d44b00p70a0e0084c0c636c@mail.gmail.com> References: <3170f42f0808241209w8d44b00p70a0e0084c0c636c@mail.gmail.com> Message-ID: <3170f42f0809090403k3ca7bad6sd1a2081c76fa8f84@mail.gmail.com> > I am packaging Cherokee [1] for Fedora. If someone else is also > interested please let me know. Oops! Someone submitted a review: https://bugzilla.redhat.com/show_bug.cgi?id=461400 I will let Pavel take care of it. :-) Happy hacking, Debarshi From pertusus at free.fr Tue Sep 9 11:25:20 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 9 Sep 2008 13:25:20 +0200 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C60B66.7020608@hhs.nl> References: <48C5190F.7020500@hhs.nl> <1220884332.3170.42.camel@atropine.boston.devel.redhat.com> <48C60B66.7020608@hhs.nl> Message-ID: <20080909112520.GC8520@free.fr> On Tue, Sep 09, 2008 at 07:36:38AM +0200, Hans de Goede wrote: > >> lesstif > > Not owned by me, should not have been shown, buggy pkgdb ?? But we > surely can use help here, so feel free to ask for co-maintainer rights. Seconded. I am the primary maintainer, but Hans does the real bug resolutions. -- Pat From kevin.kofler at chello.at Tue Sep 9 11:27:46 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 9 Sep 2008 11:27:46 +0000 (UTC) Subject: make force-tag gone References: <1220955240.24928.69.camel@cookie.hadess.net> Message-ID: Bastien Nocera redhat.com> writes: > I'm pretty sure it was discussed before, and I forcefully ignored it > thinking people would realise it was a bad idea to drop it. They'd probably have ignored you even if you had complained, I did and I was ignored. :-/ > It's just that it's making us look like idiots in the changelogs, having > to bump release for something like that: > http://cvs.fedoraproject.org/viewvc/rpms/gvfs/devel/gvfs.spec?r1=1.69&r2=1.70 +1 Please put it back! At least until we have a workable alternative. I don't call having to bump Release for each trivial build fix "workable". Otherwise, I think we'll end up with lots of packages with the kernel's "make Release from CVS revision" hack, is that really what we want??? Kevin Kofler From buc at odusz.so-cdu.ru Tue Sep 9 11:34:30 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Tue, 09 Sep 2008 15:34:30 +0400 Subject: make force-tag gone In-Reply-To: <1220955240.24928.69.camel@cookie.hadess.net> References: <1220955240.24928.69.camel@cookie.hadess.net> Message-ID: <48C65F46.40401@odu.neva.ru> Bastien Nocera wrote: > I'm pretty sure it was discussed before, and I forcefully ignored it > thinking people would realise it was a bad idea to drop it. > > It's just that it's making us look like idiots in the changelogs, having > to bump release for something like that: > http://cvs.fedoraproject.org/viewvc/rpms/gvfs/devel/gvfs.spec?r1=1.69&r2=1.70 > +1 ~buc http://www.fedoraproject.org/wiki/DmitryButskoy From kevin.kofler at chello.at Tue Sep 9 11:40:24 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 9 Sep 2008 11:40:24 +0000 (UTC) Subject: make force-tag gone References: <1220955240.24928.69.camel@cookie.hadess.net> <48C651FA.7080305@poolshark.org> Message-ID: Denis Leroy poolshark.org> writes: > Yes please put force-tag: back, or make 'scratch-build' without a branch > tag. Scratch builds are not a solution, as there's no way to turn a scratch build into a non-scratch one without resubmitting the build from scratch (no pun intended) as a non-scratch one, which wastes both my time and Koji's resources. My workflow went like this: * commit * make tag * make build BUILD_FLAGS=--nowait * get result e-mail from Koji * while failed: - commit - make force-tag - resubmit build - get result e-mail from Koji Using scratch builds, I'd have to: * commit * submit scratch build from HEAD (for which there isn't even a makefile command, as you mentioned) * get results from Koji (does it even mail scratch build results?) * while failed: - commit - submit new scratch build from HEAD - get results from Koji * make tag (!) * submit real build (!) The steps I marked with ! mean the package has to wait for me to notice it successfully built so I can issue the new build, and then I have to wait for an additional build from Koji, wasting Koji resources. So this is just a gigantic waste of time and resources. (Don't think of a trivial noarch package which builds in a matter of minutes or even seconds, think of something huge like kdelibs.) Scratch builds can solve some problems (like builds for customized or unreviewed packages), but this isn't one. Kevin Kofler From tmraz at redhat.com Tue Sep 9 11:50:47 2008 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 09 Sep 2008 13:50:47 +0200 Subject: make force-tag gone In-Reply-To: <48C65F46.40401@odu.neva.ru> References: <1220955240.24928.69.camel@cookie.hadess.net> <48C65F46.40401@odu.neva.ru> Message-ID: <1220961047.1564.72.camel@vespa.frost.loc> On Tue, 2008-09-09 at 15:34 +0400, Dmitry Butskoy wrote: > Bastien Nocera wrote: > > I'm pretty sure it was discussed before, and I forcefully ignored it > > thinking people would realise it was a bad idea to drop it. > > > > It's just that it's making us look like idiots in the changelogs, having > > to bump release for something like that: > > http://cvs.fedoraproject.org/viewvc/rpms/gvfs/devel/gvfs.spec?r1=1.69&r2=1.70 > > > > +1 +1 Please -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From limb at jcomserv.net Tue Sep 9 11:54:05 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 9 Sep 2008 06:54:05 -0500 (CDT) Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C60E18.2090407@hhs.nl> References: <48C5190F.7020500@hhs.nl> <24776.198.175.55.5.1220879480.squirrel@mail.jcomserv.net> <27257.198.175.55.5.1220879644.squirrel@mail.jcomserv.net> <48C60E18.2090407@hhs.nl> Message-ID: <8949.198.175.55.5.1220961245.squirrel@mail.jcomserv.net> > Jon Ciesla wrote: >>>> If you are willing to take over any let me know and I'll orphan them >>>> and >>>> you can pick them up. I'll be around for a long time to come to answer >>>> any questions and help with any issues with them, so don't hesitate! >>> I'd be happy to take liquidwar, pinball, pipenightdreams, supertuxkart, >>> and xgalaxy. Possibly others later, but these for now. >> >> And, logically, tuxkart. >> > > Thanks! > > I've released them all, yup can leave tuxkart orphaned though, its dead > (superceeded by supertuxkart), pkgdb seems to not care about > dead.package files in CVS, Thanks, picked up everything but supertuxkart, which you still need to orphan. > Regards, > > Hans > -- novus ordo absurdum From limb at jcomserv.net Tue Sep 9 11:55:32 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 9 Sep 2008 06:55:32 -0500 (CDT) Subject: make force-tag gone In-Reply-To: <1220955240.24928.69.camel@cookie.hadess.net> References: <1220955240.24928.69.camel@cookie.hadess.net> Message-ID: <9420.198.175.55.5.1220961332.squirrel@mail.jcomserv.net> > I'm pretty sure it was discussed before, and I forcefully ignored it > thinking people would realise it was a bad idea to drop it. > > It's just that it's making us look like idiots in the changelogs, having > to bump release for something like that: > http://cvs.fedoraproject.org/viewvc/rpms/gvfs/devel/gvfs.spec?r1=1.69&r2=1.70 > > Bleh. Does TAG_OPTS=-F make tag not do the same thing? Works great for me, if I forget to cvs add a patch, or fat finger something. > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From kzak at redhat.com Tue Sep 9 12:06:55 2008 From: kzak at redhat.com (Karel Zak) Date: Tue, 9 Sep 2008 14:06:55 +0200 Subject: make force-tag gone In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> <48C651FA.7080305@poolshark.org> Message-ID: <20080909120655.GB2943@nb.net.home> On Tue, Sep 09, 2008 at 11:40:24AM +0000, Kevin Kofler wrote: > Denis Leroy poolshark.org> writes: > > Yes please put force-tag: back, or make 'scratch-build' without a branch > > tag. My patch with "make srpm-scratch-build" (scratch without a CVS commit) is waiting in infrastructure track. +1 for force-tag. Karel -- Karel Zak From konrad at tylerc.org Tue Sep 9 12:14:44 2008 From: konrad at tylerc.org (Conrad Meyer) Date: Tue, 9 Sep 2008 05:14:44 -0700 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C5190F.7020500@hhs.nl> References: <48C5190F.7020500@hhs.nl> Message-ID: <200809090514.44905.konrad@tylerc.org> Quoth Hans de Goede: > Hi All, > > I still need to write a little blog post of this, but as from Sept 1st > I've been hired by RedHat to work on anaconda (the installer). As such I > would like to reduce my package load as much as possible so that I can > focus fully on my new job. > > Thus *all* of my packages are looking for a new owner (I'm not actually > orphaning them, but I *really* want to lower my load quite a bit). > > https://admin.fedoraproject.org/pkgdb/users/packages/jwrdegoede?acls=owner > > If you are willing to take over any let me know and I'll orphan them and > you can pick them up. I'll be around for a long time to come to answer > any questions and help with any issues with them, so don't hesitate! > > Thanks & Regards, > > Hans I'll take zasx (unless you are particularly close to upstream). -- Conrad Meyer From pknirsch at redhat.com Tue Sep 9 12:16:48 2008 From: pknirsch at redhat.com (Phil Knirsch) Date: Tue, 09 Sep 2008 14:16:48 +0200 Subject: make force-tag gone In-Reply-To: <1220961047.1564.72.camel@vespa.frost.loc> References: <1220955240.24928.69.camel@cookie.hadess.net> <48C65F46.40401@odu.neva.ru> <1220961047.1564.72.camel@vespa.frost.loc> Message-ID: <48C66930.9050808@redhat.com> Tomas Mraz wrote: > On Tue, 2008-09-09 at 15:34 +0400, Dmitry Butskoy wrote: >> Bastien Nocera wrote: >>> I'm pretty sure it was discussed before, and I forcefully ignored it >>> thinking people would realise it was a bad idea to drop it. >>> >>> It's just that it's making us look like idiots in the changelogs, having >>> to bump release for something like that: >>> http://cvs.fedoraproject.org/viewvc/rpms/gvfs/devel/gvfs.spec?r1=1.69&r2=1.70 >>> >> +1 > +1 +1 please -- Philipp Knirsch | Tel.: +49-711-96437-470 Team Lead Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. From dominik at greysector.net Tue Sep 9 12:31:57 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 9 Sep 2008 14:31:57 +0200 Subject: Lonely packages looking for cosy new owner In-Reply-To: <20080909112520.GC8520@free.fr> References: <48C5190F.7020500@hhs.nl> <1220884332.3170.42.camel@atropine.boston.devel.redhat.com> <48C60B66.7020608@hhs.nl> <20080909112520.GC8520@free.fr> Message-ID: <20080909123157.GA21125@mokona.greysector.net> On Tuesday, 09 September 2008 at 13:25, Patrice Dumas wrote: > On Tue, Sep 09, 2008 at 07:36:38AM +0200, Hans de Goede wrote: > > > >> lesstif > > > > Not owned by me, should not have been shown, buggy pkgdb ?? But we > > surely can use help here, so feel free to ask for co-maintainer rights. > > Seconded. I am the primary maintainer, but Hans does the real bug > resolutions. Off topic, but maybe you could help me with this bug? https://bugzilla.redhat.com/show_bug.cgi?id=216160 Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From limb at jcomserv.net Tue Sep 9 12:33:37 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 9 Sep 2008 07:33:37 -0500 (CDT) Subject: Merge review question Message-ID: <25902.198.175.55.5.1220963617.squirrel@mail.jcomserv.net> If the owner of a former Core package is unresponsive to activity on a Merge Review bug, despite being CCd, and the changes needed are minor, and the reviewer is an uberpackager, is there any reason not to simply commit the changes to cvs with comments and close the bug? Thanks, Jon -- novus ordo absurdum From dominik at greysector.net Tue Sep 9 12:35:48 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 9 Sep 2008 14:35:48 +0200 Subject: Merge review question In-Reply-To: <25902.198.175.55.5.1220963617.squirrel@mail.jcomserv.net> References: <25902.198.175.55.5.1220963617.squirrel@mail.jcomserv.net> Message-ID: <20080909123548.GB21125@mokona.greysector.net> On Tuesday, 09 September 2008 at 14:33, Jon Ciesla wrote: > If the owner of a former Core package is unresponsive to activity on a > Merge Review bug, despite being CCd, and the changes needed are minor, and > the reviewer is an uberpackager, is there any reason not to simply commit > the changes to cvs with comments and close the bug? Or begin AWOL maintainer procedure? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jwboyer at gmail.com Tue Sep 9 12:37:09 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 9 Sep 2008 08:37:09 -0400 Subject: Merge review question In-Reply-To: <25902.198.175.55.5.1220963617.squirrel@mail.jcomserv.net> References: <25902.198.175.55.5.1220963617.squirrel@mail.jcomserv.net> Message-ID: <20080909123709.GB16041@yoda.jdub.homelinux.org> On Tue, Sep 09, 2008 at 07:33:37AM -0500, Jon Ciesla wrote: >If the owner of a former Core package is unresponsive to activity on a >Merge Review bug, despite being CCd, and the changes needed are minor, and >the reviewer is an uberpackager, is there any reason not to simply commit >the changes to cvs with comments and close the bug? No. josh From limb at jcomserv.net Tue Sep 9 12:40:34 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 9 Sep 2008 07:40:34 -0500 (CDT) Subject: Merge review question In-Reply-To: <20080909123548.GB21125@mokona.greysector.net> References: <25902.198.175.55.5.1220963617.squirrel@mail.jcomserv.net> <20080909123548.GB21125@mokona.greysector.net> Message-ID: <30214.198.175.55.5.1220964034.squirrel@mail.jcomserv.net> > On Tuesday, 09 September 2008 at 14:33, Jon Ciesla wrote: >> If the owner of a former Core package is unresponsive to activity on a >> Merge Review bug, despite being CCd, and the changes needed are minor, >> and >> the reviewer is an uberpackager, is there any reason not to simply >> commit >> the changes to cvs with comments and close the bug? > > Or begin AWOL maintainer procedure? Many are clearly not AWOL. Some of these packages have had a build or two since my last comments. Some owners are RH employees. In these cases, I've re-reviewed the current build, noted differences, and double-checked ownership and CC status on the bug. > Regards, > R. > > -- > Fedora http://fedoraproject.org/wiki/User:Rathann > Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu > "Faith manages." > -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From limb at jcomserv.net Tue Sep 9 12:41:36 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 9 Sep 2008 07:41:36 -0500 (CDT) Subject: Merge review question In-Reply-To: <20080909123709.GB16041@yoda.jdub.homelinux.org> References: <25902.198.175.55.5.1220963617.squirrel@mail.jcomserv.net> <20080909123709.GB16041@yoda.jdub.homelinux.org> Message-ID: <30868.198.175.55.5.1220964096.squirrel@mail.jcomserv.net> > On Tue, Sep 09, 2008 at 07:33:37AM -0500, Jon Ciesla wrote: >>If the owner of a former Core package is unresponsive to activity on a >>Merge Review bug, despite being CCd, and the changes needed are minor, >> and >>the reviewer is an uberpackager, is there any reason not to simply commit >>the changes to cvs with comments and close the bug? > > No. That was the way I was leaning, if my fairly leading question wasn't a big enough hint. :) I'll wait for a further objection period, but likely begin soon. > josh > -- novus ordo absurdum From stickster at gmail.com Tue Sep 9 12:59:59 2008 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 09 Sep 2008 08:59:59 -0400 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C5190F.7020500@hhs.nl> References: <48C5190F.7020500@hhs.nl> Message-ID: <1220965199.6904.67.camel@localhost.localdomain> On Mon, 2008-09-08 at 14:22 +0200, Hans de Goede wrote: > Hi All, > > I still need to write a little blog post of this, but as from Sept 1st > I've been hired by RedHat to work on anaconda (the installer). As such I > would like to reduce my package load as much as possible so that I can > focus fully on my new job. > > Thus *all* of my packages are looking for a new owner (I'm not actually > orphaning them, but I *really* want to lower my load quite a bit). > > https://admin.fedoraproject.org/pkgdb/users/packages/jwrdegoede?acls=owner I'll take "pioneers," since I occasionally play it. :-) -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Tue Sep 9 13:04:59 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 9 Sep 2008 15:04:59 +0200 Subject: Heads-up: libdap and libnc-dap updates In-Reply-To: References: <20080905133702.GF26218@free.fr> Message-ID: <20080909130459.GF8520@free.fr> On Fri, Sep 05, 2008 at 07:44:04PM +0000, Kevin Kofler wrote: > Patrice Dumas free.fr> writes: > > I don't want to do devel compat package, I don't think it is needed, > > and this compat package should be removed in F12 or so. > > That makes no sense at all. Either the packages build against the new library, > then they should simply be rebuilt, or they don't, in which case the -devel > package for the compatibility library MUST be provided or the dependent > packages don't rebuild anymore. We're trying hard to get FTBFS bugs fixed, The objective is not to have to rebuild gdal immediately. > intentionally causing new ones is a very bad idea. What if one of the dependent > packages has a security issue? This are not conventional FTBFS created here, but a very controlled one. I maintain all the libdap dependent packages, except gdal, but I watch gdal. > IMHO, compatibility libraries without a -devel package should be banned > entirely. If the compatibility package is needed, so is the > corresponding -devel package, unless the changes are strictly ABI-only with > 100% source compatibility (usually they aren't)! And in that rare event, a mass > rebuild is a better solution than a compatibility package. It may be convenient not to have to rebuild a software everytime upstream introduces ABI change, for some softwares (like numerical models), not tracked in rpm. so I think that doing compatibility libraries or not, with or without devel subpackage should be left to the maintainer. In the case of libdap, ABI is very unstable, but API doesn't change much (except in that case) so I don't think doing compat packages in the general case is interesting. I will also avoid to do it in the present case, since Orion is against (and he is the potential reviewer ;-) and I agree that it was not really needed. -- Pat From hughsient at gmail.com Tue Sep 9 13:35:29 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 09 Sep 2008 14:35:29 +0100 Subject: [packagekit] PackageKit 0.3.2 in rawhide In-Reply-To: <48C64B8E.7070000@fedoraproject.org> References: <1220953689.11468.6.camel@hughsie-work> <48C64B8E.7070000@fedoraproject.org> Message-ID: <1220967329.4752.2.camel@hughsie-work> On Tue, 2008-09-09 at 15:40 +0530, Rahul Sundaram wrote: > Do you plan on doing test builds for Fedora 9? It works great on F9 (I'm using it now) apart from a couple of missing icons which is an easy patch in the SRPM. I want to see how the new code works in the real world, and then if everything is good I'm planning to drag 0.3.3 into F9. Richard. From tspauld98 at yahoo.com Tue Sep 9 13:45:50 2008 From: tspauld98 at yahoo.com (Timothy Spaulding) Date: Tue, 9 Sep 2008 06:45:50 -0700 (PDT) Subject: Looking for co-maintainers In-Reply-To: <1220953731.8385.7.camel@localhost.localdomain> Message-ID: <555464.38066.qm@web65704.mail.ac4.yahoo.com> Hi Martin, I'm looking to get into packaging for Fedora.? I will be upfront with you.? I have ZERO experience but I'm an experience C and Java developer and I've been using Red Hat since 6.2 as a desktop.? If you don't mind helping me get up to speed, I'd be happy to help you maintain gxine.? BTW, gxine is something that I use frequently on my laptop. Let me know if you'd like to give me a shot. Thanks, Tim Spaulding --- On Tue, 9/9/08, Martin Sourada wrote: From: Martin Sourada Subject: Looking for co-maintainers To: "Development discussions related to Fedora" Date: Tuesday, September 9, 2008, 5:48 AM Hi, I heard it's a good practice to have at least two people working on one packages (so that e.g. one does not have time to solve some critical issue due to being on vacation, the others maintainer steps in and solve it). Therefore I am looking for co-maintainer(s) for these packages: gxine [all Fedoras, EPEL5, originally requested also EPEL4, but there are missing deps (namely xine-lib)] xine-plugin [all Fedoras] subtitleeditor [all Fedoras] Any one willing to co-maintain some of those? Thanks, Martin -- 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 rjones at redhat.com Tue Sep 9 13:47:36 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 9 Sep 2008 14:47:36 +0100 Subject: Merge review question In-Reply-To: <25902.198.175.55.5.1220963617.squirrel@mail.jcomserv.net> References: <25902.198.175.55.5.1220963617.squirrel@mail.jcomserv.net> Message-ID: <20080909134736.GA24936@amd.home.annexia.org> On Tue, Sep 09, 2008 at 07:33:37AM -0500, Jon Ciesla wrote: > If the owner of a former Core package is unresponsive to activity on a > Merge Review bug, despite being CCd, and the changes needed are minor, and > the reviewer is an uberpackager, is there any reason not to simply commit > the changes to cvs with comments and close the bug? It may be that they are not receiving bug-mail. Have you tried to email them directly? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From skvidal at fedoraproject.org Tue Sep 9 13:51:37 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 09 Sep 2008 09:51:37 -0400 Subject: Boot speedup with readahead In-Reply-To: <1220905733.6431.9.camel@localhost.localdomain> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> Message-ID: <1220968297.987.65.camel@rosebud> On Mon, 2008-09-08 at 15:28 -0500, Callum Lerwick wrote: > On Mon, 2008-09-08 at 11:27 -0400, Jeremy Katz wrote: > > And doing it this way would be more effective than cron as there are > > plenty of people (especially with laptops/desktops which aren't on all > > the time) for whom cron really isn't appropriate for anything that we > > actually care to have done > > We still need to trigger pre-linking after yum transactions rather than > by a cron job... So we really need a generic yum-post-transaction trigger script. something that says: pkgname: action: command ie: glibc: *: /run/something/for/a/glibc/ How do we determine which pkgs changing need a new prelink run? I can put this together probably today if that's what's needed. -sv From skvidal at fedoraproject.org Tue Sep 9 13:57:00 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 09 Sep 2008 09:57:00 -0400 Subject: Dependency loops considered harmful? In-Reply-To: <48C0D792.4040906@gmail.com> References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> <20080903180224.GA13455@localhost> <48BED37A.5020706@redhat.com> <1220483766.4415.19.camel@localhost.localdomain> <48BF20C4.4050500@gmail.com> <1220512991.4415.40.camel@localhost.localdomain> <48BFADBD.6080103@gmail.com> <48C00D4F.2030004@gmail.com> <1220556463.17785.30.camel@rosebud> <48C03FF3.9040903@gmail.com> <1220560349.17785.37.camel@rosebud> <48C0565A.5090906@gmail.com> <1220571347.17785.44.camel@rosebud> <48C0D792.4040906@gmail.com> Message-ID: <1220968620.987.68.camel@rosebud> On Thu, 2008-09-04 at 23:54 -0700, Toshio Kuratomi wrote: > Seth Vidal wrote: > > On Thu, 2008-09-04 at 14:42 -0700, Toshio Kuratomi wrote: > > >> If it goes in /etc/yum.conf then either one could be the default. A > >> setting in a config file can be scripted in a kickstart, deployed by > >> puppet, or set by an individual user once and then forgotten. > >> > > > > nod. The other option, given the code I just put in a separate script, > > is to make it a plugin to handle the above. > > > > It wouldn't be hard to do and then if you wanted leaf dep removal you > > could install/enable the plugin. > > > That sounds ideal. > I've written the plugin - it is in upstream yum-utils git. The next yum-utils release (1.1.17 I think) should have it. If you install it then all removes will get rid of unused deps from the program(s) being removed. To disable it just disable the plugin either by editing the plugin config file or via --disableplugin=remove-with-leaves -sv From martin.sourada at gmail.com Tue Sep 9 13:58:27 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Tue, 09 Sep 2008 15:58:27 +0200 Subject: Looking for co-maintainers In-Reply-To: <555464.38066.qm@web65704.mail.ac4.yahoo.com> References: <555464.38066.qm@web65704.mail.ac4.yahoo.com> Message-ID: <1220968707.8385.12.camel@localhost.localdomain> On Tue, 2008-09-09 at 06:45 -0700, Timothy Spaulding wrote: > Hi Martin, > > I'm looking to get into packaging for Fedora. I will be upfront with > you. I have ZERO experience but I'm an experience C and Java > developer and I've been using Red Hat since 6.2 as a desktop. If you > don't mind helping me get up to speed, I'd be happy to help you > maintain gxine. BTW, gxine is something that I use frequently on my > laptop. > > Let me know if you'd like to give me a shot. > > Thanks, > > Yeah, that would help both thanks to your experience in C and your frequent usage of gxine :) You need to be a fedora package maintainer first though, which means someone needs to sponsor you (I am not a sponsor myself). https://fedoraproject.org/wiki/PackageMaintainers/Join https://fedoraproject.org/wiki/PackageMaintainers/WishList Thanks, Martin From walters at verbum.org Tue Sep 9 14:01:09 2008 From: walters at verbum.org (Colin Walters) Date: Tue, 9 Sep 2008 10:01:09 -0400 Subject: Boot speedup with readahead In-Reply-To: <1220968297.987.65.camel@rosebud> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> Message-ID: On Tue, Sep 9, 2008 at 9:51 AM, Seth Vidal wrote: > > So we really need a generic yum-post-transaction trigger script. > > something that says: > > pkgname: action: command > > ie: > > glibc: *: /run/something/for/a/glibc/ > > > How do we determine which pkgs changing need a new prelink run? This would be great and we've really needed it for a long time. Ideally it would be structured to recognize packages based on their content; for example, if a package installs an icon in /usr/share/icons, we know to invoke gtk-update-icon-cache. From tibbs at math.uh.edu Tue Sep 9 14:01:28 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 09 Sep 2008 09:01:28 -0500 Subject: Merge review question In-Reply-To: <20080909134736.GA24936@amd.home.annexia.org> References: <25902.198.175.55.5.1220963617.squirrel@mail.jcomserv.net> <20080909134736.GA24936@amd.home.annexia.org> Message-ID: >>>>> "RWMJ" == Richard W M Jones writes: RWMJ> It may be that they are not receiving bug-mail. Have you tried RWMJ> to email them directly? It's also quite possible that the owner has changed since the merge review ticket was opened (nearly two years ago now) and the new owner isn't CC'd on the ticket. I would urge caution in just fixing up the packages just before the beta freeze, but once rawhide reopens I would suggest committing as many cleanups as is warranted. The general problems with merge reviews became apparent just after they were filed. I see two things that need doing: Existing merge reviews need to be checked to ensure that the current owners are CC'd. Soon after rawhide branches, a "package cleanup squad" needs to just go through and deal with the packages where merge reviews have stalled. - J< From arjan at infradead.org Tue Sep 9 14:09:38 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Tue, 9 Sep 2008 07:09:38 -0700 Subject: Boot speedup with readahead In-Reply-To: <1220968297.987.65.camel@rosebud> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> Message-ID: <20080909070938.7d81e715@infradead.org> On Tue, 09 Sep 2008 09:51:37 -0400 Seth Vidal wrote: > On Mon, 2008-09-08 at 15:28 -0500, Callum Lerwick wrote: > > On Mon, 2008-09-08 at 11:27 -0400, Jeremy Katz wrote: > > > And doing it this way would be more effective than cron as there > > > are plenty of people (especially with laptops/desktops which > > > aren't on all the time) for whom cron really isn't appropriate > > > for anything that we actually care to have done > > > > We still need to trigger pre-linking after yum transactions rather > > than by a cron job... > > > So we really need a generic yum-post-transaction trigger script. > > something that says: > > pkgname: action: command > > ie: > > glibc: *: /run/something/for/a/glibc/ > > > How do we determine which pkgs changing need a new prelink run? anything that puts something in /usr/bin or /usr/lib (and their variations) so would be nice if it would glob on package name OR package content. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org From jreiser at BitWagon.com Tue Sep 9 14:16:12 2008 From: jreiser at BitWagon.com (John Reiser) Date: Tue, 09 Sep 2008 07:16:12 -0700 Subject: To freeze, or not to freeze In-Reply-To: <1220900399.17700.24.camel@luminos.localdomain> References: <1220887143.17700.9.camel@luminos.localdomain> <1220900399.17700.24.camel@luminos.localdomain> Message-ID: <48C6852C.3010109@BitWagon.com> > So unless there are any reasonable objections, we're going to move the > freeze to Thursday. Pungi compose to CD-ROM media (more than one platter; DVD works) fails: https://bugzilla.redhat.com/show_bug.cgi?id=461211 -- From cra at WPI.EDU Tue Sep 9 14:22:04 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 9 Sep 2008 10:22:04 -0400 Subject: Merge review question In-Reply-To: References: <25902.198.175.55.5.1220963617.squirrel@mail.jcomserv.net> <20080909134736.GA24936@amd.home.annexia.org> Message-ID: <20080909142204.GJ12193@angus.ind.WPI.EDU> On Tue, Sep 09, 2008 at 09:01:28AM -0500, Jason L Tibbitts III wrote: > Existing merge reviews need to be checked to ensure that the current > owners are CC'd. Isn't there a -owner at fedoraproject.org that ties into pkgdb that all Bugzilla's for should have as a Initial-Cc? Then the actual owner according to pkgdb will always be up-to-date on all of the package's bugs. From berrange at redhat.com Tue Sep 9 13:55:34 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 9 Sep 2008 14:55:34 +0100 Subject: Merge review question In-Reply-To: <25902.198.175.55.5.1220963617.squirrel@mail.jcomserv.net> References: <25902.198.175.55.5.1220963617.squirrel@mail.jcomserv.net> Message-ID: <20080909135534.GH18300@redhat.com> On Tue, Sep 09, 2008 at 07:33:37AM -0500, Jon Ciesla wrote: > If the owner of a former Core package is unresponsive to activity on a > Merge Review bug, despite being CCd, and the changes needed are minor, and > the reviewer is an uberpackager, is there any reason not to simply commit > the changes to cvs with comments and close the bug? For the sake of not surprising the maintainer, I'd recommend just sending them a direct email indicating your intentions and then doing the changes. People here at Red Hat get a tonne of email spam from BugZilla so it is trivial to miss things if it is 1 message in a 100 you get from BZ in a day. So the non-BZ email is more likely to be noticed & avoid the maintainer being surprised at the changes :-) Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From lyos.gemininorezel at gmail.com Tue Sep 9 14:23:31 2008 From: lyos.gemininorezel at gmail.com (Lyos Gemini Norezel) Date: Tue, 09 Sep 2008 10:23:31 -0400 Subject: make force-tag gone In-Reply-To: <48C651FA.7080305@poolshark.org> References: <1220955240.24928.69.camel@cookie.hadess.net> <48C651FA.7080305@poolshark.org> Message-ID: <48C686E3.7090503@gmail.com> Denis Leroy wrote: > Bastien Nocera wrote: >> I'm pretty sure it was discussed before, and I forcefully ignored it >> thinking people would realise it was a bad idea to drop it. > > Yes please put force-tag: back, or make 'scratch-build' without a > branch tag. > +1 Lyos Gemini Norezel From arjan at infradead.org Tue Sep 9 14:23:34 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Tue, 9 Sep 2008 07:23:34 -0700 Subject: Boot speedup with readahead In-Reply-To: References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> Message-ID: <20080909072334.58be6bb3@infradead.org> On Tue, 9 Sep 2008 10:01:09 -0400 "Colin Walters" wrote: > This would be great and we've really needed it for a long time. > Ideally it would be structured to recognize packages based on their > content; for example, if a package installs an icon in > /usr/share/icons, we know to invoke gtk-update-icon-cache. that makes it a question if this should be in yum or in rpm.... > -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org From skvidal at fedoraproject.org Tue Sep 9 14:29:46 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 09 Sep 2008 10:29:46 -0400 Subject: Boot speedup with readahead In-Reply-To: <20080909072334.58be6bb3@infradead.org> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <20080909072334.58be6bb3@infradead.org> Message-ID: <1220970586.987.70.camel@rosebud> On Tue, 2008-09-09 at 07:23 -0700, Arjan van de Ven wrote: > On Tue, 9 Sep 2008 10:01:09 -0400 > "Colin Walters" wrote: > > This would be great and we've really needed it for a long time. > > Ideally it would be structured to recognize packages based on their > > content; for example, if a package installs an icon in > > /usr/share/icons, we know to invoke gtk-update-icon-cache. > > that makes it a question if this should be in yum or in rpm.... > I'm fairly confident it'll be easier to do in yum. -sv From mmcgrath at redhat.com Tue Sep 9 14:30:58 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 9 Sep 2008 09:30:58 -0500 (CDT) Subject: make force-tag gone In-Reply-To: <1220955240.24928.69.camel@cookie.hadess.net> References: <1220955240.24928.69.camel@cookie.hadess.net> Message-ID: On Tue, 9 Sep 2008, Bastien Nocera wrote: > I'm pretty sure it was discussed before, and I forcefully ignored it > thinking people would realise it was a bad idea to drop it. > > It's just that it's making us look like idiots in the changelogs, having > to bump release for something like that: > http://cvs.fedoraproject.org/viewvc/rpms/gvfs/devel/gvfs.spec?r1=1.69&r2=1.70 > In fairness... you should be testing things before you commit them, then tag them. If we keep tagging things that don't work then I'm afraid we are idiots. -Mike From devrim at gunduz.org Tue Sep 9 13:28:48 2008 From: devrim at gunduz.org (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Tue, 09 Sep 2008 16:28:48 +0300 Subject: make force-tag gone In-Reply-To: <20080909120655.GB2943@nb.net.home> References: <1220955240.24928.69.camel@cookie.hadess.net> <48C651FA.7080305@poolshark.org> <20080909120655.GB2943@nb.net.home> Message-ID: <1220966928.2711.149.camel@laptop.gunduz.org> On Tue, 2008-09-09 at 14:06 +0200, Karel Zak wrote: > +1 for force-tag. +1 from here, too. -- Devrim G?ND?Z, RHCE devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Tue Sep 9 14:36:02 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 09 Sep 2008 10:36:02 -0400 Subject: Boot speedup with readahead In-Reply-To: References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> Message-ID: <1220970962.987.74.camel@rosebud> On Tue, 2008-09-09 at 10:01 -0400, Colin Walters wrote: > On Tue, Sep 9, 2008 at 9:51 AM, Seth Vidal wrote: > > > > So we really need a generic yum-post-transaction trigger script. > > > > something that says: > > > > pkgname: action: command > > > > ie: > > > > glibc: *: /run/something/for/a/glibc/ > > > > > > How do we determine which pkgs changing need a new prelink run? > > This would be great and we've really needed it for a long time. > Ideally it would be structured to recognize packages based on their > content; for example, if a package installs an icon in > /usr/share/icons, we know to invoke gtk-update-icon-cache. Does it need to be run if the pkg removed an icon? -sv From arjan at infradead.org Tue Sep 9 14:40:00 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Tue, 9 Sep 2008 07:40:00 -0700 Subject: Boot speedup with readahead In-Reply-To: <1220970586.987.70.camel@rosebud> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <20080909072334.58be6bb3@infradead.org> <1220970586.987.70.camel@rosebud> Message-ID: <20080909074000.57ab627d@infradead.org> On Tue, 09 Sep 2008 10:29:46 -0400 Seth Vidal wrote: > On Tue, 2008-09-09 at 07:23 -0700, Arjan van de Ven wrote: > > On Tue, 9 Sep 2008 10:01:09 -0400 > > "Colin Walters" wrote: > > > This would be great and we've really needed it for a long time. > > > Ideally it would be structured to recognize packages based on > > > their content; for example, if a package installs an icon in > > > /usr/share/icons, we know to invoke gtk-update-icon-cache. > > > > that makes it a question if this should be in yum or in rpm.... > > > > I'm fairly confident it'll be easier to do in yum. > I absolutely do not doubt that ;) the question is more complex than 'what is easiest' if "correctness" type things move into these checks rather than just optimization things. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org From limb at jcomserv.net Tue Sep 9 14:40:38 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 9 Sep 2008 09:40:38 -0500 (CDT) Subject: Fedora 8 and 9 updates status In-Reply-To: <50163.198.175.55.5.1220971051.squirrel@mail.jcomserv.net> References: <1220630950.4273.14.camel@luminos.localdomain> <1220908007.17700.38.camel@luminos.localdomain> <50163.198.175.55.5.1220971051.squirrel@mail.jcomserv.net> Message-ID: <60473.198.175.55.5.1220971238.squirrel@mail.jcomserv.net> > >> On Fri, 2008-09-05 at 09:09 -0700, Jesse Keating wrote: >>> Announcements regarding the location >>> of said document and how to help with content will be coming shortly. >> >> Time for another update on the F8 and F9 updates status. >> >> Our testing with the live update content as gone well. We identified a >> couple issues with the current PackageKit and thanks to Richard Hughes >> we'll have an updated PackageKit to offer as well as an updated >> fedora-release package for our users. The combination of the two (or >> just the fedora-release package for you non-packagekit users) will be >> all that you will need in order to gain access to our newly signed and >> relocated updates. >> >> We're in the final stages of testing a few corner cases, and preparing >> the official builds of fedora-release, PackageKit, gnome-packagekit, and >> unique (needed as a new dep for gnome-packagekit). All existing updates >> in the old update locations will be purged, and just these updates will >> be put in their place, signed with our old key. Once you've updated to >> these packages, the next update attempt will point you to our new >> locations with our new keys and you should be able to process any >> further pending updates. You'll be prompted to import the new key along >> the way. >> >> A wiki page has been created that covers some of this, >> https://fedoraproject.org/wiki/Enabling_new_signing_key and will be >> updated throughout the day as we finish the above listed tasks. A more >> formal announcement along with links to the official FAQ will be >> published to same lists this mail is going out to, and likely picked up >> by various news sites. We expect things to wrap up by the end of today >> or early tomorrow. >> >> Once again we thank you for your continued patience and be aware that >> we're nearly there! > > Given that some updates are already on mirrors, is there a trusted place > from which we may obtain the new key to import? I found that I can check them here. . . https://fedoraproject.org/keys >> -- >> Jesse Keating >> Fedora -- Freedom?? is a feature! >> identi.ca: http://identi.ca/jkeating >> -- >> fedora-announce-list mailing list >> fedora-announce-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-announce-list > > > -- > novus ordo absurdum > -- novus ordo absurdum From skvidal at fedoraproject.org Tue Sep 9 14:43:13 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 09 Sep 2008 10:43:13 -0400 Subject: Boot speedup with readahead In-Reply-To: <20080909074000.57ab627d@infradead.org> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <20080909072334.58be6bb3@infradead.org> <1220970586.987.70.camel@rosebud> <20080909074000.57ab627d@infradead.org> Message-ID: <1220971393.987.76.camel@rosebud> On Tue, 2008-09-09 at 07:40 -0700, Arjan van de Ven wrote: > On Tue, 09 Sep 2008 10:29:46 -0400 > Seth Vidal wrote: > > > On Tue, 2008-09-09 at 07:23 -0700, Arjan van de Ven wrote: > > > On Tue, 9 Sep 2008 10:01:09 -0400 > > > "Colin Walters" wrote: > > > > This would be great and we've really needed it for a long time. > > > > Ideally it would be structured to recognize packages based on > > > > their content; for example, if a package installs an icon in > > > > /usr/share/icons, we know to invoke gtk-update-icon-cache. > > > > > > that makes it a question if this should be in yum or in rpm.... > > > > > > > I'm fairly confident it'll be easier to do in yum. > > > > I absolutely do not doubt that ;) > > the question is more complex than 'what is easiest' if "correctness" > type things move into these checks rather than just optimization things. I'll work on a simple plugin to handle this and we can see if it'll work semi-correctly. If we decide it needs to be at the rpm-level then so be it. :) -sv From rdieter at math.unl.edu Tue Sep 9 14:47:37 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 09 Sep 2008 09:47:37 -0500 Subject: make force-tag gone References: <1220955240.24928.69.camel@cookie.hadess.net> Message-ID: Mike McGrath wrote: > In fairness... you should be testing things before you commit them Of course. I've been hit by this a lot with local builds working, but rawhide builds that fail (for whatever reason, new rpm, wierd build deps breaking, etc...). -- Rex From limb at jcomserv.net Tue Sep 9 14:54:27 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 9 Sep 2008 09:54:27 -0500 (CDT) Subject: make force-tag gone In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> Message-ID: <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> > Mike McGrath wrote: > > >> In fairness... you should be testing things before you commit them > > Of course. I've been hit by this a lot with local builds working, but > rawhide builds that fail (for whatever reason, new rpm, wierd build deps > breaking, etc...). I have issues, also, where something succeeds in a local build, is fine oin i386 mock, but dies in ppc, x86_64, etc. > -- Rex > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From limb at jcomserv.net Tue Sep 9 14:55:59 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 9 Sep 2008 09:55:59 -0500 (CDT) Subject: Merge review question In-Reply-To: <20080909134736.GA24936@amd.home.annexia.org> References: <25902.198.175.55.5.1220963617.squirrel@mail.jcomserv.net> <20080909134736.GA24936@amd.home.annexia.org> Message-ID: <49189.198.175.55.5.1220972159.squirrel@mail.jcomserv.net> > On Tue, Sep 09, 2008 at 07:33:37AM -0500, Jon Ciesla wrote: >> If the owner of a former Core package is unresponsive to activity on a >> Merge Review bug, despite being CCd, and the changes needed are minor, >> and >> the reviewer is an uberpackager, is there any reason not to simply >> commit >> the changes to cvs with comments and close the bug? > > It may be that they are not receiving bug-mail. Have you tried to > email them directly? I had not. I'll start that after the freeze if I get no response. If someone isn't set up to receive BZ mail, how do they hope to keep abreast of problems with the package? > Rich. > > -- > Richard Jones, Emerging Technologies, Red Hat > http://et.redhat.com/~rjones > Read my OCaml programming blog: http://camltastic.blogspot.com/ > Fedora now supports 68 OCaml packages (the OPEN alternative to F#) > http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora > -- novus ordo absurdum From limb at jcomserv.net Tue Sep 9 14:37:31 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 9 Sep 2008 09:37:31 -0500 (CDT) Subject: Fedora 8 and 9 updates status In-Reply-To: <1220908007.17700.38.camel@luminos.localdomain> References: <1220630950.4273.14.camel@luminos.localdomain> <1220908007.17700.38.camel@luminos.localdomain> Message-ID: <50163.198.175.55.5.1220971051.squirrel@mail.jcomserv.net> > On Fri, 2008-09-05 at 09:09 -0700, Jesse Keating wrote: >> Announcements regarding the location >> of said document and how to help with content will be coming shortly. > > Time for another update on the F8 and F9 updates status. > > Our testing with the live update content as gone well. We identified a > couple issues with the current PackageKit and thanks to Richard Hughes > we'll have an updated PackageKit to offer as well as an updated > fedora-release package for our users. The combination of the two (or > just the fedora-release package for you non-packagekit users) will be > all that you will need in order to gain access to our newly signed and > relocated updates. > > We're in the final stages of testing a few corner cases, and preparing > the official builds of fedora-release, PackageKit, gnome-packagekit, and > unique (needed as a new dep for gnome-packagekit). All existing updates > in the old update locations will be purged, and just these updates will > be put in their place, signed with our old key. Once you've updated to > these packages, the next update attempt will point you to our new > locations with our new keys and you should be able to process any > further pending updates. You'll be prompted to import the new key along > the way. > > A wiki page has been created that covers some of this, > https://fedoraproject.org/wiki/Enabling_new_signing_key and will be > updated throughout the day as we finish the above listed tasks. A more > formal announcement along with links to the official FAQ will be > published to same lists this mail is going out to, and likely picked up > by various news sites. We expect things to wrap up by the end of today > or early tomorrow. > > Once again we thank you for your continued patience and be aware that > we're nearly there! Given that some updates are already on mirrors, is there a trusted place from which we may obtain the new key to import? > -- > Jesse Keating > Fedora -- Freedom?? is a feature! > identi.ca: http://identi.ca/jkeating > -- > fedora-announce-list mailing list > fedora-announce-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-announce-list -- novus ordo absurdum From dennis at ausil.us Tue Sep 9 15:06:24 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 9 Sep 2008 10:06:24 -0500 Subject: make force-tag gone In-Reply-To: <1220955240.24928.69.camel@cookie.hadess.net> References: <1220955240.24928.69.camel@cookie.hadess.net> Message-ID: <200809091007.23542.dennis@ausil.us> On Tuesday 09 September 2008 05:14:00 am Bastien Nocera wrote: > I'm pretty sure it was discussed before, and I forcefully ignored it > thinking people would realise it was a bad idea to drop it. > > It's just that it's making us look like idiots in the changelogs, having > to bump release for something like that: > http://cvs.fedoraproject.org/viewvc/rpms/gvfs/devel/gvfs.spec?r1=1.69&r2=1. >70 to ensure GPL compliance and that we can always reproduce we have said for awhile now that tags will eventually be made immutable I had missed that Mike Bonnet had added it, if it had been caught it would have been removed sooner. I would love someone to help here. adding checks to makefile.common check that all patches are commited and that source is updated and commited. AFAIK these are the most common reasons people force a tag and the closest thing to a valid reason for forcing a tag. when we tag we should be sure that the build is fine and going to build. thats why we have targets like mockbuild other targets to help test things are always welcome. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From mmcgrath at redhat.com Tue Sep 9 15:10:08 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 9 Sep 2008 10:10:08 -0500 (CDT) Subject: make force-tag gone In-Reply-To: <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> Message-ID: On Tue, 9 Sep 2008, Jon Ciesla wrote: > > > Mike McGrath wrote: > > > > > >> In fairness... you should be testing things before you commit them > > > > Of course. I've been hit by this a lot with local builds working, but > > rawhide builds that fail (for whatever reason, new rpm, wierd build deps > > breaking, etc...). > > I have issues, also, where something succeeds in a local build, is fine > oin i386 mock, but dies in ppc, x86_64, etc. > So why would you make a change to the spec file, without bumping the release? Also there's an auditing GPL legal reason (IIRC) that we're doing this now. The bottom line is this: Make change to a spec file. Bump release. Its a simple workflow that provides an audit trail that we believe will keep us in compliance with the GPL. force-tag is sort of nice to have I guess, but release bumps happen all the time by everyone its not a high barrier to get releases out. I'm not sure what else to say, its not going to happen guys unless you can come up with a different audit trail that will keep us in compliance with the GPL and satisfies legal. -Mike From walters at verbum.org Tue Sep 9 15:10:05 2008 From: walters at verbum.org (Colin Walters) Date: Tue, 9 Sep 2008 11:10:05 -0400 Subject: Boot speedup with readahead In-Reply-To: <1220970962.987.74.camel@rosebud> References: <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <1220970962.987.74.camel@rosebud> Message-ID: On Tue, Sep 9, 2008 at 10:36 AM, Seth Vidal wrote: > > Does it need to be run if the pkg removed an icon? Yeah, that would be more correct; but if we don't it just means that a program will succeed in finding an icon it "shouldn't have", and I can't offhand think of a reasonable case where that would be a problem. From rjones at redhat.com Tue Sep 9 15:12:58 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 9 Sep 2008 16:12:58 +0100 Subject: Merge review question In-Reply-To: <49189.198.175.55.5.1220972159.squirrel@mail.jcomserv.net> References: <25902.198.175.55.5.1220963617.squirrel@mail.jcomserv.net> <20080909134736.GA24936@amd.home.annexia.org> <49189.198.175.55.5.1220972159.squirrel@mail.jcomserv.net> Message-ID: <20080909151258.GA25533@amd.home.annexia.org> On Tue, Sep 09, 2008 at 09:55:59AM -0500, Jon Ciesla wrote: > If someone isn't set up to receive BZ mail, how do they hope to keep > abreast of problems with the package? A few people *cough* me *cough* get so much Bugzilla mail that we have to aggressively filter it. Usually any packages which are owned by me or bugs which are assigned to me go to my inbox, but I have missed mails from time to time for somewhat inexplicable reasons. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From limb at jcomserv.net Tue Sep 9 15:36:18 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 9 Sep 2008 10:36:18 -0500 (CDT) Subject: make force-tag gone In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> Message-ID: <56296.198.175.55.5.1220974578.squirrel@mail.jcomserv.net> > On Tue, 9 Sep 2008, Jon Ciesla wrote: > >> >> > Mike McGrath wrote: >> > >> > >> >> In fairness... you should be testing things before you commit them >> > >> > Of course. I've been hit by this a lot with local builds working, but >> > rawhide builds that fail (for whatever reason, new rpm, wierd build >> deps >> > breaking, etc...). >> >> I have issues, also, where something succeeds in a local build, is fine >> oin i386 mock, but dies in ppc, x86_64, etc. >> > > So why would you make a change to the spec file, without bumping the > release? Also there's an auditing GPL legal reason (IIRC) that we're > doing this now. The bottom line is this: > > Make change to a spec file. > > Bump release. Even it there's no successful build? Is the cvs log not retained, and useful for auditing purposes? > Its a simple workflow that provides an audit trail that we believe will > keep us in compliance with the GPL. force-tag is sort of nice to have I > guess, but release bumps happen all the time by everyone its not a high > barrier to get releases out. > > I'm not sure what else to say, its not going to happen guys unless you can > come up with a different audit trail that will keep us in compliance with > the GPL and satisfies legal. So is using TAG_OPTS=-F make tag a problem? > -Mike > -- novus ordo absurdum From mmcgrath at redhat.com Tue Sep 9 15:42:05 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 9 Sep 2008 10:42:05 -0500 (CDT) Subject: make force-tag gone In-Reply-To: <56296.198.175.55.5.1220974578.squirrel@mail.jcomserv.net> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <56296.198.175.55.5.1220974578.squirrel@mail.jcomserv.net> Message-ID: On Tue, 9 Sep 2008, Jon Ciesla wrote: > > > On Tue, 9 Sep 2008, Jon Ciesla wrote: > > > >> > >> > Mike McGrath wrote: > >> > > >> > > >> >> In fairness... you should be testing things before you commit them > >> > > >> > Of course. I've been hit by this a lot with local builds working, but > >> > rawhide builds that fail (for whatever reason, new rpm, wierd build > >> deps > >> > breaking, etc...). > >> > >> I have issues, also, where something succeeds in a local build, is fine > >> oin i386 mock, but dies in ppc, x86_64, etc. > >> > > > > So why would you make a change to the spec file, without bumping the > > release? Also there's an auditing GPL legal reason (IIRC) that we're > > doing this now. The bottom line is this: > > > > Make change to a spec file. > > > > Bump release. > > Even it there's no successful build? Is the cvs log not retained, and > useful for auditing purposes? > > > Its a simple workflow that provides an audit trail that we believe will > > keep us in compliance with the GPL. force-tag is sort of nice to have I > > guess, but release bumps happen all the time by everyone its not a high > > barrier to get releases out. > > > > I'm not sure what else to say, its not going to happen guys unless you can > > come up with a different audit trail that will keep us in compliance with > > the GPL and satisfies legal. > > So is using TAG_OPTS=-F make tag a problem? > AFAIK, yes it is. -Mike From jkeating at redhat.com Tue Sep 9 15:42:00 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 09 Sep 2008 08:42:00 -0700 Subject: To freeze, or not to freeze In-Reply-To: <48C6852C.3010109@BitWagon.com> References: <1220887143.17700.9.camel@luminos.localdomain> <1220900399.17700.24.camel@luminos.localdomain> <48C6852C.3010109@BitWagon.com> Message-ID: <1220974920.11620.0.camel@luminos.localdomain> On Tue, 2008-09-09 at 07:16 -0700, John Reiser wrote: > > Pungi compose to CD-ROM media (more than one platter; DVD works) fails: > https://bugzilla.redhat.com/show_bug.cgi?id=461211 Which I told you is already fixed upstream. You could do the patch locally if you want, it's a one liner. There are some other pungi changes I'm working on and will roll up into a new pungi release just prior to spinning the Beta. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sstarr at platform.com Tue Sep 9 15:42:27 2008 From: sstarr at platform.com (Shawn Starr) Date: Tue, 9 Sep 2008 08:42:27 -0700 Subject: Proposed removal of packages with long-standing FTBFS failures Message-ID: See below. > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com > [mailto:fedora-devel-list-bounces at redhat.com]On Behalf Of Matt Domsch > Sent: Friday, September 05, 2008 11:40 AM > To: fedora-devel-list at redhat.com > Subject: Proposed removal of packages with long-standing > FTBFS failures > > > The following 90 packages have had FTBFS (Fails to Build From Source) > failures for several months, some as far back as February 2008. > > There are several "trivial" failures which could be addressed easily. > 8 fail due to unpackaged files > 6 fail due to patch fuzz > 1 fails due to open() not passing a mode. > > http://fedoraproject.org/wiki/FTBFS describes the FTBFS process. > > As was proposed to FESCO, packages with unresolved FTBFS bugs > immediately following the Alpha release will be removed from the > distribution. Package owners may request that their package _not_ be > removed provided they are actively working on resolving the FTBFS and > have a plan to resolve the FTBFS before the Release Candidate > release. FESCo has the final say of course, but these are the items > on my candidate list. I'd prefer packages get fixed rather than > removed. If you are the package owner, or are interested in the > future of these packages, please investigate these build failures and > fix them ASAP. > > astyle-1.21-6.fc8 [u'433971 ASSIGNED'] (build/make) addutko,mtasaka Please don't remove astyle, KDE developers use this to keep coding styles in a certain format and it's documented on our wiki how to use astyle. If it doesn't build, I'll co-maintain it. > lilypond-2.10.33-1.fc8 [u'434394 ASSIGNED'] (build/make) limb Removing this will break any MIDI based apps, you sure that's good? Especially rosegarden and such which use lilypond for notation. > pdsh-2.11-6.fc9 [u'440811 ASSIGNED'] (build/make) kg6fnk Please do not remove PDSH this is needed for clusters especially HPC clusters. Pdsh should build just fine, if not I'll co-maintain it. /me worries what releng is doing... From limb at jcomserv.net Tue Sep 9 15:45:21 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 9 Sep 2008 10:45:21 -0500 (CDT) Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: References: Message-ID: <24788.198.175.55.5.1220975121.squirrel@mail.jcomserv.net> > See below. > >> -----Original Message----- >> From: fedora-devel-list-bounces at redhat.com >> [mailto:fedora-devel-list-bounces at redhat.com]On Behalf Of Matt Domsch >> Sent: Friday, September 05, 2008 11:40 AM >> To: fedora-devel-list at redhat.com >> Subject: Proposed removal of packages with long-standing >> FTBFS failures >> >> >> The following 90 packages have had FTBFS (Fails to Build From Source) >> failures for several months, some as far back as February 2008. >> >> There are several "trivial" failures which could be addressed easily. >> 8 fail due to unpackaged files >> 6 fail due to patch fuzz >> 1 fails due to open() not passing a mode. >> >> http://fedoraproject.org/wiki/FTBFS describes the FTBFS process. >> >> As was proposed to FESCO, packages with unresolved FTBFS bugs >> immediately following the Alpha release will be removed from the >> distribution. Package owners may request that their package _not_ be >> removed provided they are actively working on resolving the FTBFS and >> have a plan to resolve the FTBFS before the Release Candidate >> release. FESCo has the final say of course, but these are the items >> on my candidate list. I'd prefer packages get fixed rather than >> removed. If you are the package owner, or are interested in the >> future of these packages, please investigate these build failures and >> fix them ASAP. >> >> astyle-1.21-6.fc8 [u'433971 ASSIGNED'] (build/make) addutko,mtasaka > > Please don't remove astyle, KDE developers use this to keep coding styles > in a certain format and it's documented on our wiki how to use astyle. If > it doesn't build, I'll co-maintain it. > >> lilypond-2.10.33-1.fc8 [u'434394 ASSIGNED'] (build/make) limb > > Removing this will break any MIDI based apps, you sure that's good? > Especially rosegarden and such which use lilypond for notation. No worries, I fixed it. >> pdsh-2.11-6.fc9 [u'440811 ASSIGNED'] (build/make) kg6fnk > > Please do not remove PDSH this is needed for clusters especially HPC > clusters. > > Pdsh should build just fine, if not I'll co-maintain it. > > /me worries what releng is doing... > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From jkeating at redhat.com Tue Sep 9 15:46:45 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 09 Sep 2008 08:46:45 -0700 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: References: Message-ID: <1220975205.11620.1.camel@luminos.localdomain> On Tue, 2008-09-09 at 08:42 -0700, Shawn Starr wrote: > /me worries what releng is doing... releng is preventing a future where we have to rebuild a large swath of packages for some emergency or another, only to find that a good chunk of them fail to rebuild. This is a bad situation to be in. Often times, the only way to get somebody to work on these is to threaten to remove them from the distro. It brings out the people who actually care about the packages so that they can work on making them build again. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sstarr at platform.com Tue Sep 9 15:48:23 2008 From: sstarr at platform.com (Shawn Starr) Date: Tue, 9 Sep 2008 08:48:23 -0700 Subject: Proposed removal of packages with long-standing FTBFS failures Message-ID: > -----Original Message----- > From: fedora-devel-list-bounces at redhat.com > [mailto:fedora-devel-list-bounces at redhat.com]On Behalf Of > Jesse Keating > Sent: Tuesday, September 09, 2008 11:47 AM > To: fedora-devel-list at redhat.com > Subject: RE: Proposed removal of packages with long-standing FTBFS > failures > > > On Tue, 2008-09-09 at 08:42 -0700, Shawn Starr wrote: > > /me worries what releng is doing... > > releng is preventing a future where we have to rebuild a > large swath of > packages for some emergency or another, only to find that a good chunk > of them fail to rebuild. This is a bad situation to be in. > > Often times, the only way to get somebody to work on these is to > threaten to remove them from the distro. It brings out the people who > actually care about the packages so that they can work on making them > build again. > I guess that's a good thing seeing, It's gotten me to care about some of those now :-) > -- > Jesse Keating > Fedora -- Freedom? is a feature! > identi.ca: http://identi.ca/jkeating > From alain.portal at free.fr Tue Sep 9 15:50:56 2008 From: alain.portal at free.fr (Alain PORTAL) Date: Tue, 9 Sep 2008 17:50:56 +0200 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <48C59FAF.1090009@ihug.com.au> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <200809082248.06835.alain.portal@free.fr> <48C59FAF.1090009@ihug.com.au> Message-ID: <200809091750.56763.alain.portal@free.fr> Le lundi 08 septembre 2008, Roy Rankin a ?crit : > Alain, > > Yes, I can take both gpsim and gtk-extras. So, what we have to do to do that? Regards, Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- 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 Tue Sep 9 15:55:02 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 9 Sep 2008 10:55:02 -0500 (CDT) Subject: make force-tag gone In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <56296.198.175.55.5.1220974578.squirrel@mail.jcomserv.net> Message-ID: <57400.198.175.55.5.1220975702.squirrel@mail.jcomserv.net> > On Tue, 9 Sep 2008, Jon Ciesla wrote: > >> >> > On Tue, 9 Sep 2008, Jon Ciesla wrote: >> > >> >> >> >> > Mike McGrath wrote: >> >> > >> >> > >> >> >> In fairness... you should be testing things before you commit them >> >> > >> >> > Of course. I've been hit by this a lot with local builds working, >> but >> >> > rawhide builds that fail (for whatever reason, new rpm, wierd build >> >> deps >> >> > breaking, etc...). >> >> >> >> I have issues, also, where something succeeds in a local build, is >> fine >> >> oin i386 mock, but dies in ppc, x86_64, etc. >> >> >> > >> > So why would you make a change to the spec file, without bumping the >> > release? Also there's an auditing GPL legal reason (IIRC) that we're >> > doing this now. The bottom line is this: >> > >> > Make change to a spec file. >> > >> > Bump release. >> >> Even it there's no successful build? Is the cvs log not retained, and >> useful for auditing purposes? >> >> > Its a simple workflow that provides an audit trail that we believe >> will >> > keep us in compliance with the GPL. force-tag is sort of nice to have >> I >> > guess, but release bumps happen all the time by everyone its not a >> high >> > barrier to get releases out. >> > >> > I'm not sure what else to say, its not going to happen guys unless you >> can >> > come up with a different audit trail that will keep us in compliance >> with >> > the GPL and satisfies legal. >> >> So is using TAG_OPTS=-F make tag a problem? >> > > AFAIK, yes it is. If if is, then can the Makefile be modified to prevent it, so that others who didn't know that stop doing it? > -Mike > -- novus ordo absurdum From denis at poolshark.org Tue Sep 9 16:03:03 2008 From: denis at poolshark.org (Denis Leroy) Date: Tue, 09 Sep 2008 18:03:03 +0200 Subject: make force-tag gone In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> Message-ID: <48C69E37.5090205@poolshark.org> Mike McGrath wrote: > Its a simple workflow that provides an audit trail that we believe will > keep us in compliance with the GPL. force-tag is sort of nice to have I > guess, but release bumps happen all the time by everyone its not a high > barrier to get releases out. > > I'm not sure what else to say, its not going to happen guys unless you can > come up with a different audit trail that will keep us in compliance with > the GPL and satisfies legal. There's no logic here. You're not forcing people to tag after every CVS check-in, as far as I know. If a release 'n' fails to build (for example, because you forgot to check-in a patch), it makes zero sense to bump to n+1, because release 'n' never *existed* in the first place, since it was never built. That has zero impact over auditing. Spec file auditing is done through CVS. From denis at poolshark.org Tue Sep 9 16:07:19 2008 From: denis at poolshark.org (Denis Leroy) Date: Tue, 09 Sep 2008 18:07:19 +0200 Subject: make force-tag gone In-Reply-To: <200809091007.23542.dennis@ausil.us> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809091007.23542.dennis@ausil.us> Message-ID: <48C69F37.4060500@poolshark.org> Dennis Gilmore wrote: > to ensure GPL compliance and that we can always reproduce we have said for > awhile now that tags will eventually be made immutable This is overreaching, and as I said makes no sense if tagged package was never actually built. > I had missed that Mike Bonnet had added it, if it had been caught it would > have been removed sooner. If you take away force-tag, you have to provide an alternative for scratch builds across all arches, in the same koji build environment > I would love someone to help here. adding checks to makefile.common check > that all patches are commited and that source is updated and commited. AFAIK > these are the most common reasons people force a tag and the closest thing to > a valid reason for forcing a tag. No, there's also difference in build environments in koji (stricter desktop-file-install is a classic, or the recent fuzzy patch issue), as well as cross-architecture builds. As I said, you need to provide an alternative to packagers for cross-arch test builts. > when we tag we should be sure that the build is fine and going to build. thats > why we have targets like mockbuild other targets to help test things are > always welcome. Mock is nice, but it's a resource-heavy tool that can't be used on all systems. My work laptop doesn't have the bandwidth and disk-space for it for example, and it won't catch cross-arch issues. From buc at odusz.so-cdu.ru Tue Sep 9 16:40:57 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Tue, 09 Sep 2008 20:40:57 +0400 Subject: make force-tag gone In-Reply-To: <48C69F37.4060500@poolshark.org> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809091007.23542.dennis@ausil.us> <48C69F37.4060500@poolshark.org> Message-ID: <48C6A719.5030300@odu.neva.ru> Denis Leroy wrote: > > No, there's also difference in build environments in koji (stricter > desktop-file-install is a classic, or the recent fuzzy patch issue), > as well as cross-architecture builds. ...as well as cross-release builds. ~buc From jkeating at redhat.com Tue Sep 9 16:46:46 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 09 Sep 2008 09:46:46 -0700 Subject: make force-tag gone In-Reply-To: <48C69E37.5090205@poolshark.org> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> Message-ID: <1220978806.11620.6.camel@luminos.localdomain> On Tue, 2008-09-09 at 18:03 +0200, Denis Leroy wrote: > > There's no logic here. You're not forcing people to tag after every CVS > check-in, as far as I know. If a release 'n' fails to build (for > example, because you forgot to check-in a patch), it makes zero sense to > bump to n+1, because release 'n' never *existed* in the first place, > since it was never built. That has zero impact over auditing. Spec file > auditing is done through CVS. The audit part is something of a red herring. The GPL compliance part is what is bothersome. If we want to save archive space by relying on re-generating srpms of shipped binaries on demand, we need to ensure that CVS tags don't change over time. For better or worse, we build from CVS tags, so to get the source that matched the build, we have to checkout via CVS tags. If those tags can change over time, the trust level is gone. That's why there is a push to make the tags immutable, or at least the successfully built tags immutable. Personally I just want to move off of CVS and off of building from tags, and instead build from something inherently immutable, like the shasum of the repo at a given time. MikeB said that he'd look into some CVS/make changes that would allow checking koji for an on going or successful build of a tag/n-v-r before allowing a force-tag. This would allow folks to force-tag before having a successful build, but would not allow you to force the tag after a successful build, or while a build is still going with that n-v-r. I think this approach, while it may slow down force-tags and prevent force-tags during any koji outage, will give us the best of both worlds. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ssorce at redhat.com Tue Sep 9 17:00:57 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 09 Sep 2008 13:00:57 -0400 Subject: make force-tag gone In-Reply-To: <1220978806.11620.6.camel@luminos.localdomain> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <1220978806.11620.6.camel@luminos.localdomain> Message-ID: <1220979657.15726.48.camel@localhost.localdomain> On Tue, 2008-09-09 at 09:46 -0700, Jesse Keating wrote: > On Tue, 2008-09-09 at 18:03 +0200, Denis Leroy wrote: > > > > There's no logic here. You're not forcing people to tag after every CVS > > check-in, as far as I know. If a release 'n' fails to build (for > > example, because you forgot to check-in a patch), it makes zero sense to > > bump to n+1, because release 'n' never *existed* in the first place, > > since it was never built. That has zero impact over auditing. Spec file > > auditing is done through CVS. > > The audit part is something of a red herring. The GPL compliance part > is what is bothersome. If we want to save archive space by relying on > re-generating srpms of shipped binaries on demand, we need to ensure > that CVS tags don't change over time. For better or worse, we build > from CVS tags, so to get the source that matched the build, we have to > checkout via CVS tags. If those tags can change over time, the trust > level is gone. That's why there is a push to make the tags immutable, > or at least the successfully built tags immutable. > > Personally I just want to move off of CVS and off of building from tags, > and instead build from something inherently immutable, like the shasum > of the repo at a given time. > > MikeB said that he'd look into some CVS/make changes that would allow > checking koji for an on going or successful build of a tag/n-v-r before > allowing a force-tag. This would allow folks to force-tag before having > a successful build, but would not allow you to force the tag after a > successful build, or while a build is still going with that n-v-r. > > I think this approach, while it may slow down force-tags and prevent > force-tags during any koji outage, will give us the best of both worlds. +1 Simo. -- Simo Sorce * Red Hat, Inc * New York From debarshi.ray at gmail.com Tue Sep 9 16:45:34 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Tue, 9 Sep 2008 22:15:34 +0530 Subject: make force-tag gone In-Reply-To: <1220955240.24928.69.camel@cookie.hadess.net> References: <1220955240.24928.69.camel@cookie.hadess.net> Message-ID: <3170f42f0809090945k597b6505s8c83fc853424a72e@mail.gmail.com> > I'm pretty sure it was discussed before, and I forcefully ignored it > thinking people would realise it was a bad idea to drop it. > > It's just that it's making us look like idiots in the changelogs, having > to bump release for something like that: > http://cvs.fedoraproject.org/viewvc/rpms/gvfs/devel/gvfs.spec?r1=1.69&r2=1.70 +1 I have happily used 'TAG_OPTS=-F make tag' [1] on the rare occasions that I needed force-tag. I might try to use local hacks to get around it if people decided to try and block 'TAG_OPTS=-F make tag'. :-) Happy hacking, Debarshi [1] I did not know about force-tag earlier. From nhorman at redhat.com Tue Sep 9 17:18:13 2008 From: nhorman at redhat.com (Neil Horman) Date: Tue, 9 Sep 2008 13:18:13 -0400 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C60C2E.9080209@hhs.nl> References: <48C5190F.7020500@hhs.nl> <20080908123103.GE1667@hmsendeavour.rdu.redhat.com> <48C53E2E.4020405@hhs.nl> <20080908170522.GN1667@hmsendeavour.rdu.redhat.com> <48C60C2E.9080209@hhs.nl> Message-ID: <20080909171813.GM10568@hmsendeavour.rdu.redhat.com> On Tue, Sep 09, 2008 at 07:39:58AM +0200, Hans de Goede wrote: > Neil Horman wrote: > >On Mon, Sep 08, 2008 at 05:01:02PM +0200, Hans de Goede wrote: > >>Neil Horman wrote: > >>>On Mon, Sep 08, 2008 at 02:22:39PM +0200, Hans de Goede wrote: > >>>>Hi All, > >>>> > >>>>I still need to write a little blog post of this, but as from Sept 1st > >>>>I've been hired by RedHat to work on anaconda (the installer). As such > >>>>I would like to reduce my package load as much as possible so that I > >>>>can focus fully on my new job. > >>>> > >>>>Thus *all* of my packages are looking for a new owner (I'm not actually > >>>>orphaning them, but I *really* want to lower my load quite a bit). > >>>> > >>>>https://admin.fedoraproject.org/pkgdb/users/packages/jwrdegoede?acls=owner > >>>> > >>>>If you are willing to take over any let me know and I'll orphan them > >>>>and you can pick them up. I'll be around for a long time to come to > >>>>answer any questions and help with any issues with them, so don't > >>>>hesitate! > >>>> > >>>>Thanks & Regards, > >>>> > >>>>Hans > >>>> > >>>>-- > >>>>fedora-devel-list mailing list > >>>>fedora-devel-list at redhat.com > >>>>https://www.redhat.com/mailman/listinfo/fedora-devel-list > >>> > >>>Sorry, if I wasn't clear on this in my last response, but in addition to > >>>coda, > >>>I'd also be happy to inherity its dependencies, rvm and rpc2 > >>Thanks, > >> > >>I've released them all, so don't forget to claim ownership or they will > >>be considered as orphans in the future. > >> > >I requested access to cpda, rvm, rpc2 and lwp in the packagedb, but are > >you sure > >you released them? The packagedb still lists you as the owner > > > > Something went wrong with releasing coda, the rest have been picked up > by agoode, so I guess you 2 will co-maintain which is always good. > > I've released coda again. > I've picked it up, thanks Hans! Neil > Regards, > > Hans > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- /*************************************************** *Neil Horman *Senior Software Engineer *Red Hat, Inc. *nhorman at redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ From bnocera at redhat.com Tue Sep 9 17:18:33 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 09 Sep 2008 18:18:33 +0100 Subject: make force-tag gone In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> Message-ID: <1220980713.24928.113.camel@cookie.hadess.net> On Tue, 2008-09-09 at 09:30 -0500, Mike McGrath wrote: > On Tue, 9 Sep 2008, Bastien Nocera wrote: > > > I'm pretty sure it was discussed before, and I forcefully ignored it > > thinking people would realise it was a bad idea to drop it. > > > > It's just that it's making us look like idiots in the changelogs, having > > to bump release for something like that: > > http://cvs.fedoraproject.org/viewvc/rpms/gvfs/devel/gvfs.spec?r1=1.69&r2=1.70 > > > > In fairness... you should be testing things before you commit them, then > tag them. If we keep tagging things that don't work then I'm afraid we > are idiots. I know the code compiles, I was the one who made the release and used "make distcheck". The upstream configure creates a .tar.gz, not a .tar.bz2 (which the maintainer usually picks up from the GNOME FTP). I forgot to change the suffix because all my projects dist to .tar.bz2 files. So I'm supposed to run every single build in mock before committing them? That's not going to happen. The CVS keeps the sources and all the commits done. What's wrong with using it for safe keeping? Fine if you make "force-tag" fail when a build has already been successful, but removing the command altogether is the wrong thing to do. I'd rather "make force-tag" told me to cancel the previous build (if I know it'd gonna fail), just lets me do it if nothing got built on the previous run, or forbids me from using the command if a successful build was done. From a.badger at gmail.com Tue Sep 9 17:17:42 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 09 Sep 2008 10:17:42 -0700 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C60B66.7020608@hhs.nl> References: <48C5190F.7020500@hhs.nl> <1220884332.3170.42.camel@atropine.boston.devel.redhat.com> <48C60B66.7020608@hhs.nl> Message-ID: <48C6AFB6.60406@gmail.com> Hans de Goede wrote: > >> lesstif > > Not owned by me, should not have been shown, buggy pkgdb ?? But we > surely can use help here, so feel free to ask for co-maintainer rights. > >> lm_sensors > > Not owned by me (buggy pkgdb I guess), besides that I'm part of > upstream, so I'll stay involved in this one. > >> vorbis-tools > > Not owned by me (again). > Since the rebuild there's been some issues with the owner/orphaned pages in the packagedb and the notification list. I'll add these to the list of packages that have problems and try to figure out what's going on later this week. >> theora-exp > > As dead as a doornail (integrated into latest libtheora upstream > releases), I guess pkgdb doesn't honor dead.package files in CVS, I'll > orphan it. > Not yet. Maploin has been revamping the status code recently, moving away from keying on orphan at fp.o to keying on the status field in the package listing. The next step in that work will be to sync information from cvs (dead.package files) and the old wiki pages in order to figure out which packages are retired. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jspaleta at gmail.com Tue Sep 9 16:15:56 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 9 Sep 2008 08:15:56 -0800 Subject: make force-tag gone In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> <48C651FA.7080305@poolshark.org> Message-ID: <604aa7910809090915m3dd147bclef1b435ab87b004f@mail.gmail.com> On Tue, Sep 9, 2008 at 3:40 AM, Kevin Kofler wrote: > Scratch builds are not a solution, as there's no way to turn a scratch build > into a non-scratch one without resubmitting the build from scratch (no pun > intended) as a non-scratch one, which wastes both my time and Koji's resources. Is that a hard impossibility or a soft impossibility? As in... can a reasonable amount of technnical work be done to make it possible to turn a scratch build into a non-scratch build and associate a cvs tag with it without doing the full rebuild from scratch? Such a facility would be the logical next step as a counter balance to immutable tagging. -jef From bnocera at redhat.com Tue Sep 9 17:20:04 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Tue, 09 Sep 2008 18:20:04 +0100 Subject: make force-tag gone In-Reply-To: <1220978806.11620.6.camel@luminos.localdomain> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <1220978806.11620.6.camel@luminos.localdomain> Message-ID: <1220980804.24928.116.camel@cookie.hadess.net> On Tue, 2008-09-09 at 09:46 -0700, Jesse Keating wrote: > On Tue, 2008-09-09 at 18:03 +0200, Denis Leroy wrote: > MikeB said that he'd look into some CVS/make changes that would allow > checking koji for an on going or successful build of a tag/n-v-r before > allowing a force-tag. This would allow folks to force-tag before having > a successful build, but would not allow you to force the tag after a > successful build, or while a build is still going with that n-v-r. It should also disallow force tagging if a build is already in flow. Bonus points if it gives the opportunity to cancel the build in the same move as well. From nhorman at redhat.com Tue Sep 9 17:21:17 2008 From: nhorman at redhat.com (Neil Horman) Date: Tue, 9 Sep 2008 13:21:17 -0400 Subject: Package review trade Message-ID: <20080909172117.GN10568@hmsendeavour.rdu.redhat.com> Hey all- I've got two review requests outstanding (one of them has been twisting in the wind waiting for a reviewer for about 6 months). I'd really like to get both of these packages processed: https://bugzilla.redhat.com/show_bug.cgi?id=442377 https://bugzilla.redhat.com/show_bug.cgi?id=461305 I'll trade reviews with anyone interested. Just let me know Thanks! Neil -- /*************************************************** *Neil Horman *Senior Software Engineer *Red Hat, Inc. *nhorman at redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ From jeff at ocjtech.us Tue Sep 9 17:01:44 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Tue, 9 Sep 2008 12:01:44 -0500 Subject: make force-tag gone In-Reply-To: <48C69E37.5090205@poolshark.org> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> Message-ID: <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> On Tue, Sep 9, 2008 at 11:03 AM, Denis Leroy wrote: > > There's no logic here. You're not forcing people to tag after every CVS > check-in, as far as I know. If a release 'n' fails to build (for example, > because you forgot to check-in a patch), it makes zero sense to bump to n+1, > because release 'n' never *existed* in the first place, since it was never > built. That has zero impact over auditing. Spec file auditing is done > through CVS. force-tag can also be used to move the tag of a package that *was* built, if you're not careful. That's the situation we need to avoid. You can also view tagging as "I intend to build this". Why shouldn't we be able to track failed builds? It was submitted to Koji so even though it didn't result in a set of packages there was some effect on the system. Refusing to bump a release number and re-tag because you don't want to "look stupid" is not a technical argument. And before you ask, yes I've used force-tag before even though I know I shouldn't. Removing it will help me be a better package manager. -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" From tibbs at math.uh.edu Tue Sep 9 17:25:43 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 09 Sep 2008 12:25:43 -0500 Subject: Package review trade In-Reply-To: <20080909172117.GN10568@hmsendeavour.rdu.redhat.com> References: <20080909172117.GN10568@hmsendeavour.rdu.redhat.com> Message-ID: >>>>> "NH" == Neil Horman writes: NH> Hey all- I've got two review requests outstanding (one of them has NH> been twisting in the wind waiting for a reviewer for about 6 NH> months). I wonder if you realize that nobody's looked at python-pysctp because the fedora-review flag is set, so they don't show up in anyone's queries. - J< From limb at jcomserv.net Tue Sep 9 17:27:50 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 9 Sep 2008 12:27:50 -0500 (CDT) Subject: Package review trade In-Reply-To: <20080909172117.GN10568@hmsendeavour.rdu.redhat.com> References: <20080909172117.GN10568@hmsendeavour.rdu.redhat.com> Message-ID: <26044.198.175.55.5.1220981270.squirrel@mail.jcomserv.net> > Hey all- > I've got two review requests outstanding (one of them has been > twisting in the wind waiting for a reviewer for about 6 months). I'd > really > like to get both of these packages processed: > https://bugzilla.redhat.com/show_bug.cgi?id=442377 > https://bugzilla.redhat.com/show_bug.cgi?id=461305 > > I'll trade reviews with anyone interested. Just let me know I'll do py_sctp, in exchange for https://bugzilla.redhat.com/show_bug.cgi?id=460297, or 359941, your choice. > Thanks! > Neil > > -- > /*************************************************** > *Neil Horman > *Senior Software Engineer > *Red Hat, Inc. > *nhorman at redhat.com > *gpg keyid: 1024D / 0x92A74FA1 > *http://pgp.mit.edu > ***************************************************/ > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From limb at jcomserv.net Tue Sep 9 17:28:37 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 9 Sep 2008 12:28:37 -0500 (CDT) Subject: Package review trade In-Reply-To: References: <20080909172117.GN10568@hmsendeavour.rdu.redhat.com> Message-ID: <28766.198.175.55.5.1220981317.squirrel@mail.jcomserv.net> >>>>>> "NH" == Neil Horman writes: > > NH> Hey all- I've got two review requests outstanding (one of them has > NH> been twisting in the wind waiting for a reviewer for about 6 > NH> months). > > I wonder if you realize that nobody's looked at python-pysctp because > the fedora-review flag is set, so they don't show up in anyone's > queries. Oh, yeah, it's assigned to Rakesh Pandit. Does he have any interest in reviewing it? > - J< > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From rakesh.pandit at gmail.com Tue Sep 9 17:28:59 2008 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Tue, 9 Sep 2008 22:58:59 +0530 Subject: Package review trade In-Reply-To: <20080909172117.GN10568@hmsendeavour.rdu.redhat.com> References: <20080909172117.GN10568@hmsendeavour.rdu.redhat.com> Message-ID: 2008/9/9 Neil Horman : > Hey all- > I've got two review requests outstanding (one of them has been > twisting in the wind waiting for a reviewer for about 6 months). I'd really > like to get both of these packages processed: > https://bugzilla.redhat.com/show_bug.cgi?id=442377 > https://bugzilla.redhat.com/show_bug.cgi?id=461305 > > I'll trade reviews with anyone interested. Just let me know > > Thanks! > Neil > Because of review flag set it was not showing up. I will do python-pysctp review soon -- rakesh From jspaleta at gmail.com Tue Sep 9 17:28:51 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 9 Sep 2008 09:28:51 -0800 Subject: make force-tag gone In-Reply-To: <3170f42f0809090945k597b6505s8c83fc853424a72e@mail.gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <3170f42f0809090945k597b6505s8c83fc853424a72e@mail.gmail.com> Message-ID: <604aa7910809091028n2db1f23agfa973695d66b9c06@mail.gmail.com> On Tue, Sep 9, 2008 at 8:45 AM, Debarshi Ray wrote: > I have happily used 'TAG_OPTS=-F make tag' [1] on the rare occasions > that I needed force-tag. I might try to use local hacks to get around > it if people decided to try and block 'TAG_OPTS=-F make tag'. :-) We will ultimately need to also disable TAG_OPTS=-F as well if we want to make cvs tags immutable references that we can rely on to generate corresponding source on demand. -jef From limb at jcomserv.net Tue Sep 9 17:31:27 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 9 Sep 2008 12:31:27 -0500 (CDT) Subject: Package review trade In-Reply-To: References: <20080909172117.GN10568@hmsendeavour.rdu.redhat.com> Message-ID: <37316.198.175.55.5.1220981487.squirrel@mail.jcomserv.net> > 2008/9/9 Neil Horman : >> Hey all- >> I've got two review requests outstanding (one of them has been >> twisting in the wind waiting for a reviewer for about 6 months). I'd >> really >> like to get both of these packages processed: >> https://bugzilla.redhat.com/show_bug.cgi?id=442377 >> https://bugzilla.redhat.com/show_bug.cgi?id=461305 >> >> I'll trade reviews with anyone interested. Just let me know >> >> Thanks! >> Neil >> > > Because of review flag set it was not showing up. > > I will do python-pysctp review soon Ok, I'll do pam_kcoda then. > -- > rakesh > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From mtasaka at ioa.s.u-tokyo.ac.jp Tue Sep 9 15:50:02 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 10 Sep 2008 00:50:02 +0900 Subject: make force-tag gone In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> Message-ID: <48C69B2A.9050005@ioa.s.u-tokyo.ac.jp> Mike McGrath wrote, at 09/10/2008 12:10 AM +9:00: > So why would you make a change to the spec file, without bumping the > release? Well, actually there are some cases in which I don't have to change the spec file, just having forgotton to commit a new source or a new patch... Mamoru From bpepple at fedoraproject.org Tue Sep 9 16:23:19 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 09 Sep 2008 12:23:19 -0400 Subject: Plan for tomorrows (20080910) FESCO meeting Message-ID: <1220977399.4252.22.camel@kennedy> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Wednesday at 18:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCo-Meeting -- MinGW - https://fedoraproject.org/wiki/User:Jspaleta/Draft - all /topic FESCO-Meeting -- Features -- https://fedoraproject.org/wiki/Features/Presto /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule. You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Sep 9 17:37:52 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 09 Sep 2008 10:37:52 -0700 Subject: make force-tag gone In-Reply-To: <604aa7910809090915m3dd147bclef1b435ab87b004f@mail.gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <48C651FA.7080305@poolshark.org> <604aa7910809090915m3dd147bclef1b435ab87b004f@mail.gmail.com> Message-ID: <1220981872.11620.35.camel@luminos.localdomain> On Tue, 2008-09-09 at 08:15 -0800, Jeff Spaleta wrote: > > Is that a hard impossibility or a soft impossibility? As in... can a > reasonable amount of technnical work be done to make it possible to > turn a scratch build into a non-scratch build and associate a cvs tag > with it without doing the full rebuild from scratch? > > Such a facility would be the logical next step as a counter balance to > immutable tagging. Scratch builds come directly from srpms while real builds come from source control. We don't allow srpm builds to be tagged into a real collection because there is no real way to track that srpm back down to the source control. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Tue Sep 9 17:38:05 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 9 Sep 2008 17:38:05 +0000 (UTC) Subject: make force-tag gone References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <1220978806.11620.6.camel@luminos.localdomain> Message-ID: Jesse Keating redhat.com> writes: > MikeB said that he'd look into some CVS/make changes that would allow > checking koji for an on going or successful build of a tag/n-v-r before > allowing a force-tag. This would allow folks to force-tag before having > a successful build, but would not allow you to force the tag after a > successful build, or while a build is still going with that n-v-r. > > I think this approach, while it may slow down force-tags and prevent > force-tags during any koji outage, will give us the best of both worlds. I like that too, but until that is implemented, force-tag should just be there as it always was. If it's going to get fixed anyway, why remove it? Kevin Kofler From jkeating at redhat.com Tue Sep 9 17:38:32 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 09 Sep 2008 10:38:32 -0700 Subject: make force-tag gone In-Reply-To: <1220980804.24928.116.camel@cookie.hadess.net> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <1220978806.11620.6.camel@luminos.localdomain> <1220980804.24928.116.camel@cookie.hadess.net> Message-ID: <1220981912.11620.36.camel@luminos.localdomain> On Tue, 2008-09-09 at 18:20 +0100, Bastien Nocera wrote: > > a successful build, but would not allow you to force the tag after a > > successful build, or while a build is still going with that n-v-r. > > It should also disallow force tagging if a build is already in flow. That's what I meant by "or while a build is still going with that n-v-r" -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nhorman at redhat.com Tue Sep 9 17:38:50 2008 From: nhorman at redhat.com (Neil Horman) Date: Tue, 9 Sep 2008 13:38:50 -0400 Subject: Package review trade In-Reply-To: <37316.198.175.55.5.1220981487.squirrel@mail.jcomserv.net> References: <20080909172117.GN10568@hmsendeavour.rdu.redhat.com> <37316.198.175.55.5.1220981487.squirrel@mail.jcomserv.net> Message-ID: <20080909173850.GO10568@hmsendeavour.rdu.redhat.com> On Tue, Sep 09, 2008 at 12:31:27PM -0500, Jon Ciesla wrote: > > > 2008/9/9 Neil Horman : > >> Hey all- > >> I've got two review requests outstanding (one of them has been > >> twisting in the wind waiting for a reviewer for about 6 months). I'd > >> really > >> like to get both of these packages processed: > >> https://bugzilla.redhat.com/show_bug.cgi?id=442377 > >> https://bugzilla.redhat.com/show_bug.cgi?id=461305 > >> > >> I'll trade reviews with anyone interested. Just let me know > >> > >> Thanks! > >> Neil > >> > > > > Because of review flag set it was not showing up. > > > > I will do python-pysctp review soon > > Ok, I'll do pam_kcoda then. > Thank you, I'll do https://bugzilla.redhat.com/show_bug.cgi?id=460297 Neil -- /*************************************************** *Neil Horman *Senior Software Engineer *Red Hat, Inc. *nhorman at redhat.com *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ From jkeating at redhat.com Tue Sep 9 17:39:34 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 09 Sep 2008 10:39:34 -0700 Subject: make force-tag gone In-Reply-To: <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> Message-ID: <1220981974.11620.37.camel@luminos.localdomain> On Tue, 2008-09-09 at 12:01 -0500, Jeffrey Ollie wrote: > > force-tag can also be used to move the tag of a package that *was* > built, if you're not careful. That's the situation we need to avoid. > You can also view tagging as "I intend to build this". Why shouldn't > we be able to track failed builds? It was submitted to Koji so even > though it didn't result in a set of packages there was some effect on > the system. That brings up an important point. Often we'll want to examine why a build failed and being able to get to the exact source of that build is important, not whatever the maintainer thinks that tag should equate to today. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mtasaka at ioa.s.u-tokyo.ac.jp Tue Sep 9 15:53:22 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Wed, 10 Sep 2008 00:53:22 +0900 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: References: Message-ID: <48C69BF2.6090706@ioa.s.u-tokyo.ac.jp> Shawn Starr wrote, at 09/10/2008 12:42 AM +9:00: >> astyle-1.21-6.fc8 [u'433971 ASSIGNED'] (build/make) addutko,mtasaka > > Please don't remove astyle, KDE developers use this to keep coding styles in a certain format and it's documented on our wiki how to use astyle. If it doesn't build, I'll co-maintain it. astyle maintainer replied to me that he is working on this now. Mamoru From kevin.kofler at chello.at Tue Sep 9 17:39:48 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 9 Sep 2008 17:39:48 +0000 (UTC) Subject: make force-tag gone References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> Message-ID: Jeffrey Ollie ocjtech.us> writes: > Refusing to bump a release number and re-tag because you don't want to > "look stupid" is not a technical argument. Maybe, but it's a practical argument. > And before you ask, yes I've used force-tag before even though I know > I shouldn't. Removing it will help me be a better package manager. No, it will make you a worse packager, as your Release tags will get incremented for no reason. Kevin Kofler From a.badger at gmail.com Tue Sep 9 17:39:06 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 09 Sep 2008 10:39:06 -0700 Subject: make force-tag gone In-Reply-To: <604aa7910809090915m3dd147bclef1b435ab87b004f@mail.gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <48C651FA.7080305@poolshark.org> <604aa7910809090915m3dd147bclef1b435ab87b004f@mail.gmail.com> Message-ID: <48C6B4BA.40102@gmail.com> Jeff Spaleta wrote: > On Tue, Sep 9, 2008 at 3:40 AM, Kevin Kofler wrote: >> Scratch builds are not a solution, as there's no way to turn a scratch build >> into a non-scratch one without resubmitting the build from scratch (no pun >> intended) as a non-scratch one, which wastes both my time and Koji's resources. > > Is that a hard impossibility or a soft impossibility? As in... can a > reasonable amount of technnical work be done to make it possible to > turn a scratch build into a non-scratch build and associate a cvs tag > with it without doing the full rebuild from scratch? > > Such a facility would be the logical next step as a counter balance to > immutable tagging. > I'm not a koji dev but here's roughly what would need to happen: 1) koji gets request to build HEAD. 2) koji checks out HEAD and records the cvs versions of each file that corresponds to. 3) koji scratch builds and associates the version info with the scratch build. 4) Package maintainer gets back a success on the scratch build. Installs and tests. 5) Package maintainer requests that koji mark scratch build as non-scratch. 6) koji checks out the versions of the files that it has recorded for that scratch build. 7) koji attempts to tag the files with the proper immutable build tag. 8a) on success, koji changes the db records so the input comes from the tag instead of the collection of versions for the files. 8b) on failure (for instance, someone else has used that tag), koji tells the package maintainer it was unable to move the scratch build to the tag. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From rakesh.pandit at gmail.com Tue Sep 9 17:32:25 2008 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Tue, 9 Sep 2008 23:02:25 +0530 Subject: Package review trade In-Reply-To: <28766.198.175.55.5.1220981317.squirrel@mail.jcomserv.net> References: <20080909172117.GN10568@hmsendeavour.rdu.redhat.com> <28766.198.175.55.5.1220981317.squirrel@mail.jcomserv.net> Message-ID: 2008/9/9 Jon Ciesla : [..] > > Oh, yeah, it's assigned to Rakesh Pandit. Does he have any interest in > reviewing it? My post crossed both of above mails. I just took it for review. Other one is still waiting if anyone is interested. -- rakesh From tibbs at math.uh.edu Tue Sep 9 17:42:39 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 09 Sep 2008 12:42:39 -0500 Subject: Package review trade In-Reply-To: <28766.198.175.55.5.1220981317.squirrel@mail.jcomserv.net> References: <20080909172117.GN10568@hmsendeavour.rdu.redhat.com> <28766.198.175.55.5.1220981317.squirrel@mail.jcomserv.net> Message-ID: >>>>> "JC" == Jon Ciesla writes: JC> Oh, yeah, it's assigned to Rakesh Pandit. Does he have any JC> interest in reviewing it? That assignment happened very recently. The flag setting happened when the ticket was submitted. - J< From kevin.kofler at chello.at Tue Sep 9 17:44:27 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 9 Sep 2008 17:44:27 +0000 (UTC) Subject: make force-tag gone References: <1220955240.24928.69.camel@cookie.hadess.net> <200809091007.23542.dennis@ausil.us> Message-ID: Dennis Gilmore ausil.us> writes: > I had missed that Mike Bonnet had added it, if it had been caught it would > have been removed sooner. Many packagers use this feature, you can't just remove it without even telling us. You made no announcement or anything. Maybe you're underestimating the amount of times force-tag was used? The KDE packages have been force-tagged dozens of times (and no, never after a successful build, we know what we're doing!). > I would love someone to help here. adding checks to makefile.common check > that all patches are commited and that source is updated and commited. AFAIK > these are the most common reasons people force a tag and the closest thing to > a valid reason for forcing a tag. The most common reason people force a tag is that the package failed to build because of a typo in the specfile. > why we have targets like mockbuild other targets to help test things are > always welcome. mockbuild is highly impractical for huge packages like kdelibs, and even more so for dependency chains like qt -> kdelibs -> kdepimlibs -> ... There's just no way packagers are going to mockbuild all their packages locally before building in Koji. (And Bastien Nocera agrees with me there, see his reply elsewhere in this thread.) Kevin Kofler From behdad at behdad.org Tue Sep 9 17:51:35 2008 From: behdad at behdad.org (Behdad Esfahbod) Date: Tue, 09 Sep 2008 13:51:35 -0400 Subject: Boot speedup with readahead In-Reply-To: <1220968297.987.65.camel@rosebud> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> Message-ID: <48C6B7A7.6090405@behdad.org> Seth Vidal wrote: > On Mon, 2008-09-08 at 15:28 -0500, Callum Lerwick wrote: >> On Mon, 2008-09-08 at 11:27 -0400, Jeremy Katz wrote: >>> And doing it this way would be more effective than cron as there are >>> plenty of people (especially with laptops/desktops which aren't on all >>> the time) for whom cron really isn't appropriate for anything that we >>> actually care to have done >> We still need to trigger pre-linking after yum transactions rather than >> by a cron job... > > > So we really need a generic yum-post-transaction trigger script. > > something that says: > > pkgname: action: command > > ie: > > glibc: *: /run/something/for/a/glibc/ > > > How do we determine which pkgs changing need a new prelink run? Shouldn't this be done on RPM level? Isn't this pretty much an extension of RPM triggers? Or it's so hard to do that that we now want to move stuff to yum? Similar issues that can be automatically handled also: - Run gtk-update-icon-cache if icons have been added/removed. - Run fc-cache if fonts have been added/removed. - Run ldconfig when share objects are installed (this one is done already, right?) It's really the same problem. Many of the RPM snippets we keep copying from package to package can be automated. I don't see how this one is different. behdad > I can put this together probably today if that's what's needed. > > -sv From denis at poolshark.org Tue Sep 9 17:53:51 2008 From: denis at poolshark.org (Denis Leroy) Date: Tue, 09 Sep 2008 19:53:51 +0200 Subject: make force-tag gone In-Reply-To: <1220981974.11620.37.camel@luminos.localdomain> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> <1220981974.11620.37.camel@luminos.localdomain> Message-ID: <48C6B82F.8080402@poolshark.org> Jesse Keating wrote: > That brings up an important point. Often we'll want to examine why a > build failed and being able to get to the exact source of that build is > important that's why we have CVS. From cevich at redhat.com Tue Sep 9 17:57:22 2008 From: cevich at redhat.com (Chris Evich) Date: Tue, 09 Sep 2008 13:57:22 -0400 Subject: Call for developers: rpmbuilder Message-ID: <48C6B902.5090804@redhat.com> > Chris Evich wrote: >> Hi, >> >> Hopefully this is the right mailing list :) >> >> Project rpmbuilder aims to provide a template-based approach to packaging. In >> other words, it removes responsibility from developer to produce an RPM spec >> file the "right" way. Instead, the package developer just feeds in his >> project's particulars, and a template-driven engine puts the pieces together >> and spits out a "sane" RPM and SRPM. >> >> https://fedorahosted.org/rpmbuilder > > Interesting. Fails to build here: > > gcc -D__USE_FIXED_PROTOTYPES__ -Wall -g -pthread -DORBIT2=1 > -I/home/behdad/.local/include/cairo -I/home/behdad/.local/include/pango-1.0 > -I/home/behdad/.local/include -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/libgnome-2.0 > -I/usr/include/libbonobo-2.0 -I/usr/include/orbit-2.0 > -I/usr/include/bonobo-activation-2.0 -I/usr/include/libgnomeui-2.0 > -I/usr/include/libbonoboui-2.0 -I/usr/include/libgnomecanvas-2.0 > -I/usr/include/gtk-2.0 -I/usr/include/gnome-vfs-2.0 > -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/libart-2.0 > -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/freetype2 > -I/usr/include/gconf/2 -I/usr/include/libglade-2.0 -I/usr/include/libxml2 > -c -o template.o template.c > In file included from template.c:32: > macro.h:39: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before > ?macro_new_context? > macro.h:42: error: expected ?)? before ?mc? > macro.h:47: error: expected ?)? before ?mc? > macro.h:52: error: expected ?)? before ?mc? > template.c: In function ?template_expand?: > template.c:41: error: ?MacroContext? undeclared (first use in this function) > template.c:41: error: (Each undeclared identifier is reported only once > template.c:41: error: for each function it appears in.) > template.c:41: error: expected ?;? before ?mc? > template.c:49: error: ?mc? undeclared (first use in this function) > template.c:49: warning: implicit declaration of function ?macro_new_context? > make: *** [template.o] Error 1 I think you're missing rpm-devel or some other rpm headers/libraries. Though N.B. The current development version won't actually do anything for you. See the project page for a link to a (very old but somewhat working) version. Contact me off-list for any questions/proposals/info./etc. From skvidal at fedoraproject.org Tue Sep 9 17:57:59 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 09 Sep 2008 13:57:59 -0400 Subject: Boot speedup with readahead In-Reply-To: <48C6B7A7.6090405@behdad.org> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> Message-ID: <1220983079.987.79.camel@rosebud> On Tue, 2008-09-09 at 13:51 -0400, Behdad Esfahbod wrote: > Shouldn't this be done on RPM level? Isn't this pretty much an extension of > RPM triggers? Or it's so hard to do that that we now want to move stuff to yum? a proof of concept plugin for yum is almost finished. If we want to move it to the rpm layer, fine. The rpm devs are busy and getting this added to rpm will take some time. I don't really see the problem in working on it here. -sv From cevich at redhat.com Tue Sep 9 17:59:52 2008 From: cevich at redhat.com (Chris Evich) Date: Tue, 09 Sep 2008 13:59:52 -0400 Subject: Call for developers: rpmbuilder Message-ID: <48C6B998.6020804@redhat.com> > On Mon, Sep 8, 2008 at 1:30 PM, Chris Evich wrote: >> Hi, >> >> Hopefully this is the right mailing list :) >> >> Project rpmbuilder aims to provide a template-based approach to packaging. In >> other words, it removes responsibility from developer to produce an RPM spec >> file the "right" way. Instead, the package developer just feeds in his >> project's particulars, and a template-driven engine puts the pieces together >> and spits out a "sane" RPM and SRPM. > > The name is rather similar to the rpmbuild command. Hopefully this > would not cause confusion... > > Regards, > > -- > Michel Salim > http://hircus.jaiku.com/ > It was named similar intentionally, but I can see your point. Good thing the name is easily changed :) Please contact me off-list for any further comments/suggestions/etc. Thanks! From cevich at redhat.com Tue Sep 9 18:01:33 2008 From: cevich at redhat.com (Chris Evich) Date: Tue, 09 Sep 2008 14:01:33 -0400 Subject: Call for developers: rpmbuilder Message-ID: <48C6B9FD.2040000@redhat.com> > On Mon, Sep 8, 2008 at 1:30 PM, Chris Evich wrote: >> Hi, >> >> Hopefully this is the right mailing list :) >> >> Project rpmbuilder aims to provide a template-based approach to packaging. In >> other words, it removes responsibility from developer to produce an RPM spec >> file the "right" way. Instead, the package developer just feeds in his >> project's particulars, and a template-driven engine puts the pieces together >> and spits out a "sane" RPM and SRPM. >> >> https://fedorahosted.org/rpmbuilder > > Personally I would rather see Fedora heavily invest in reducing all > the overhead that currently exists in packaging and putting more > intelligence into the core of the system, rather than generating spec > files. Editing spec files is already painful enough; editing > generated ones sounds even less fun. Essentially if the build system > knows about things like the Ruby gem specs, Python setup.py, Java's > Maven, freedesktop.org autotools-based desktop packages, etc., then > you don't need to autogenerate a lot of spec boilerplate. > Actually, I completely agree, and this project is intended to address the hand-editing you describe. The templates rpmbuilder uses will be shipped _with it_, I'm not suggesting yet-another-thing-to-edit-when-packaging :) Then, different templates may be specified at packaging time depending on the "thing" to be packaged. For example, I could envision a template for packaging python "stuff" that uses a setup.py when resolving a python-rpmbuilder template. In other words, it should be as simple as: # rpmbuilder --mode=python --pkgname=MyRPMPackageName --version=1.2.3 --release=4 --sourcedir=. --destdir=. The result would be, ./MyRPMPackageName-1.2.4-4.noarch.rpm and/or ./MyRPMPackageName-1.2.4-4.noarch.srpm are written to CWD. Though this could easily extend to other scripting languages / build environments as well. All that's needed is someone to develop a template once. From jspaleta at gmail.com Tue Sep 9 16:37:01 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 9 Sep 2008 08:37:01 -0800 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <1220975205.11620.1.camel@luminos.localdomain> References: <1220975205.11620.1.camel@luminos.localdomain> Message-ID: <604aa7910809090937w1cd6b881qa05c7d66e08be988@mail.gmail.com> 2008/9/9 Jesse Keating : > Often times, the only way to get somebody to work on these is to > threaten to remove them from the distro. It brings out the people who > actually care about the packages so that they can work on making them > build again. As a maintainer I really need a way to know when one of my depchains is in trouble so I can prioritize accordingly. As Matthias pointed out earlier in the thread, I'll be able to more quickly jump in and help with one of my deps if I was notified that my package in in the impending path of destruction. Some people are going to be rockstar contributors and they will dig into that list, just because they want to help as much as they can. I'm not one of those people. I need to prioritize, and there are large segments of the package repository that I must prioritize lower compared to other work that I'm doing outside of Fedora packaging work. And since I know I'm the most typical, mediocre person in the world.. I expect a lot of other contributors need to prioritize the health of their packages in a similar manner. Personally, I'd LOVE to see yet another email.. call it the ticking bomb email... that told me which of my packages had unbuildable deps are unbuildable..with a hard removal date if not fixed. -jef From hughsient at gmail.com Tue Sep 9 18:05:05 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 09 Sep 2008 19:05:05 +0100 Subject: Banned from Fedora Forums Message-ID: <1220983505.17299.5.camel@hughsie-work> I've just been banned from the Fedora Forums [1]. I've been asking users with PackageKit bugs to report them upstream on the mailing list or in bugzilla, explaining what common error messages mean, and how to fix other problems. This, it turns out isn't what the forums are for. I guess it?s just for uniformed users telling less informed users how to "fix" things. My mistake. I won't be even reading the forums anymore, and consider the couple of hours I spent on the forums answering questions and educating users about PackageKit wasted. These are all the posts I?ve made on the forum if you want to check any of my messages: http://forums.fedoraforum.org/search.php?searchid=7137995 A few of them are pretty blunt, but the personal critique of my skills as a programmer [2] and PackageKit is pretty blunt too (especially by a "Community Manager"). Advice to developers: Don't bother. Richard [1] http://forums.fedoraforum.org/showthread.php?p=1078445#post1078439 [2] http://forums.fedoraforum.org/showthread.php?t=192791 From jspaleta at gmail.com Tue Sep 9 18:17:08 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 9 Sep 2008 10:17:08 -0800 Subject: Banned from Fedora Forums In-Reply-To: <1220983505.17299.5.camel@hughsie-work> References: <1220983505.17299.5.camel@hughsie-work> Message-ID: <604aa7910809091117s143f9a0bt9a244acc41c15ace@mail.gmail.com> On Tue, Sep 9, 2008 at 10:05 AM, Richard Hughes wrote: > I've just been banned from the Fedora Forums [1]. > [1] http://forums.fedoraforum.org/showthread.php?p=1078445#post1078439 > [2] http://forums.fedoraforum.org/showthread.php?t=192791 I would need to know which specific guideline that was referred to. I'm not sure what "multiple postings" in this context means. -jef From gemi at bluewin.ch Tue Sep 9 18:18:21 2008 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Tue, 09 Sep 2008 20:18:21 +0200 Subject: GNU Common Lisp (gcl) - need a new security context? In-Reply-To: <48C54ECD.3080402@redhat.com> References: <20080905194430.2148E61A32C@hormel.redhat.com> <1220889875.27444.9.camel@localhost.localdomain> <48C54ECD.3080402@redhat.com> Message-ID: <1220984301.27444.38.camel@localhost.localdomain> Here are my findings: (at home: Fedora-9 i386, gcl-cvs 20080908) - SELinux is disabled - using the bundled binutils instead of the system ones (configure --enable-locbfd --disable-statsysbfd) - building everything with -O2 (-O3 is normally hardwired) then GCL builds completely. This also works in a local mock rawhide build. However a scratch build using koji fails. I found that there is a difference in the memory layout between local (kernel 2.6.14) and koji (2.6.18) and GCL tries to do some funny things (such as generating its own ld script) which probably makes it fail ultimately. In particular it tries to detect some memory layout parameters such as stack ceiling (0xffffffff on koji, 0xbfffffff locally, why is this?) and "shared library/C stack ceiling to heap" (sic) (herefore it looks at the last address used in `ldd /usr/bin/awk`!!!). Apropos SELinux: When loading an image dump (made using unexec known from emacs) GCL tries to change protection using mprotect. It is possible to configure the garbage collector to omit this step. Image loading then proceeds, but loading compiled Lisp modules later fails again due to mprotect. There is probably no way to circumvent this without making far reaching modifications to GCL memory management itself. Therefore creating a security context for GCL is probably the only way to make GCL work smoothly in the mid-term (provided we can get non-selinux builds to work). This is as far as I have come currently, I hope that together we may work out solutions. Regards, G?rard From wtogami at redhat.com Tue Sep 9 18:19:42 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 09 Sep 2008 14:19:42 -0400 Subject: Banned from Fedora Forums In-Reply-To: <1220983505.17299.5.camel@hughsie-work> References: <1220983505.17299.5.camel@hughsie-work> Message-ID: <48C6BE3E.3010603@redhat.com> Richard Hughes wrote: > I've just been banned from the Fedora Forums [1]. > > I've been asking users with PackageKit bugs to report them upstream on > the mailing list or in bugzilla, explaining what common error messages > mean, and how to fix other problems. > This, it turns out isn't what the forums are for. I guess it?s just for > uniformed users telling less informed users how to "fix" things. My > mistake. > > I won't be even reading the forums anymore, and consider the couple of > hours I spent on the forums answering questions and educating users > about PackageKit wasted. > These are all the posts I?ve made on the forum if you want to check any > of my messages: > http://forums.fedoraforum.org/search.php?searchid=7137995 > > A few of them are pretty blunt, but the personal critique of my skills > as a programmer [2] and PackageKit is pretty blunt too (especially by a > "Community Manager"). > > Advice to developers: Don't bother. > > Richard > > [1] http://forums.fedoraforum.org/showthread.php?p=1078445#post1078439 > [2] http://forums.fedoraforum.org/showthread.php?t=192791 > > Oh dear. OK, I don't know the full story here, but it appears that both sides are accusing each other of being disrespectful. They seem to dislike PackageKit because it has been very broken for a long time (which I agree with), however that isn't reason to ban a developer for asking for debugging information with the goal of fixing it. This is especially problematic when Fedora Forum is our #1 preferred place to direct end-users to for end-user support. fedora-list is a dramatic pile of fail for this purpose. We also want to promote greater participation of fedora developers on Fedora Forum in order to better understand what are the common failures and to encourage users to follow the proper processes to isolate the causes and test solutions. > I've been asking users with PackageKit bugs to report them upstream on > the mailing list or in bugzilla, explaining what common error messages > mean, and how to fix other problems. > This, it turns out isn't what the forums are for. I guess it?s just for > uniformed users telling less informed users how to "fix" things. My > mistake. If this really is the case, then Fedora Forum is doing itself a disservice. But I doubt this is truly the case because it would be completely unreasonable. There seems to be upset people and hyperbole being thrown about. Let's have some well thought out discussion instead. Warren Togami wtogami at redhat.com If this really is the From jkeating at redhat.com Tue Sep 9 18:20:39 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 09 Sep 2008 11:20:39 -0700 Subject: make force-tag gone In-Reply-To: <48C6B82F.8080402@poolshark.org> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> <1220981974.11620.37.camel@luminos.localdomain> <48C6B82F.8080402@poolshark.org> Message-ID: <1220984439.3388.0.camel@luminos.localdomain> On Tue, 2008-09-09 at 19:53 +0200, Denis Leroy wrote: > > that's why we have CVS. But when you change the only reference point we have, the tag, that goes right out the window now doesn't it? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From debarshi.ray at gmail.com Tue Sep 9 18:22:29 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Tue, 9 Sep 2008 23:52:29 +0530 Subject: make force-tag gone In-Reply-To: <604aa7910809091028n2db1f23agfa973695d66b9c06@mail.gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <3170f42f0809090945k597b6505s8c83fc853424a72e@mail.gmail.com> <604aa7910809091028n2db1f23agfa973695d66b9c06@mail.gmail.com> Message-ID: <3170f42f0809091122q422e48b3u28648414ca16f636@mail.gmail.com> >> I have happily used 'TAG_OPTS=-F make tag' [1] on the rare occasions >> that I needed force-tag. I might try to use local hacks to get around >> it if people decided to try and block 'TAG_OPTS=-F make tag'. :-) > We will ultimately need to also disable TAG_OPTS=-F as well ... not unless we have a way to force tags keeping the various safeguards already suggested. Cheers, Debarshi From hughsient at gmail.com Tue Sep 9 18:23:59 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 09 Sep 2008 19:23:59 +0100 Subject: Banned from Fedora Forums In-Reply-To: <48C6BE3E.3010603@redhat.com> References: <1220983505.17299.5.camel@hughsie-work> <48C6BE3E.3010603@redhat.com> Message-ID: <1220984639.17299.11.camel@hughsie-work> On Tue, 2008-09-09 at 14:19 -0400, Warren Togami wrote: > Oh dear. OK, I don't know the full story here, but it appears that both > sides are accusing each other of being disrespectful. They seem to > dislike PackageKit because it has been very broken for a long time > (which I agree with), however that isn't reason to ban a developer for > asking for debugging information with the goal of fixing it. Sure, I'm the first to admit PackageKit has it's bugs (and the 0.1.x series was particularly rubbish) but I'm asking users to report bugs in bugzilla rather than spread FUD on forums. > This is especially problematic when Fedora Forum is our #1 preferred > place to direct end-users to for end-user support. This is what I'm worried about. > fedora-list is a dramatic pile of fail for this purpose. We also want to promote greater > participation of fedora developers on Fedora Forum in order to better > understand what are the common failures and to encourage users to follow > the proper processes to isolate the causes and test solutions. Exactly. They need to encourage developers, not ban them. Without developers it just becomes user A winging at user B and user C posting some random workaround. > There seems to be upset people and hyperbole being thrown about. > Let's have some well thought out discussion instead. Yes, I'm a person who wears my heart on my sleeve, so to speak, which I make no apology for. Richard. From hughsient at gmail.com Tue Sep 9 18:27:21 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 09 Sep 2008 19:27:21 +0100 Subject: Banned from Fedora Forums In-Reply-To: <604aa7910809091117s143f9a0bt9a244acc41c15ace@mail.gmail.com> References: <1220983505.17299.5.camel@hughsie-work> <604aa7910809091117s143f9a0bt9a244acc41c15ace@mail.gmail.com> Message-ID: <1220984841.17299.16.camel@hughsie-work> On Tue, 2008-09-09 at 10:17 -0800, Jeff Spaleta wrote: > I would need to know which specific guideline that was referred to. > I'm not sure what "multiple postings" in this context means. I figured it was because I was just posting about PackageKit stuff, which is true, I want people to report bugs and feature requests in bugzilla so we can fix them. I also think it's useful to be able to search for a thread, and get a valid answer, rather than some broken workaround. It's no big problem for me, I just feel they've lost out as it's one less upstream developer reading the forums. Richard. From skvidal at fedoraproject.org Tue Sep 9 18:30:27 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 09 Sep 2008 14:30:27 -0400 Subject: Banned from Fedora Forums In-Reply-To: <1220984639.17299.11.camel@hughsie-work> References: <1220983505.17299.5.camel@hughsie-work> <48C6BE3E.3010603@redhat.com> <1220984639.17299.11.camel@hughsie-work> Message-ID: <1220985027.987.84.camel@rosebud> On Tue, 2008-09-09 at 19:23 +0100, Richard Hughes wrote: > On Tue, 2008-09-09 at 14:19 -0400, Warren Togami wrote: > > Oh dear. OK, I don't know the full story here, but it appears that both > > sides are accusing each other of being disrespectful. They seem to > > dislike PackageKit because it has been very broken for a long time > > (which I agree with), however that isn't reason to ban a developer for > > asking for debugging information with the goal of fixing it. > > Sure, I'm the first to admit PackageKit has it's bugs (and the 0.1.x > series was particularly rubbish) but I'm asking users to report bugs in > bugzilla rather than spread FUD on forums. > Speaking as someone who has taken no end of crap from people not liking the program I spend a lot of time working on I'd like to say: Welcome to the club, we have jackets. I hope you get unbanned. it seems unnecessary and heavy handed. Though I'm a little fuzzy on how posting it to fedora-devel will help resolve the problem. -sv From mschwendt at gmail.com Tue Sep 9 18:37:04 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 9 Sep 2008 20:37:04 +0200 Subject: Banned from Fedora Forums In-Reply-To: <604aa7910809091117s143f9a0bt9a244acc41c15ace@mail.gmail.com> References: <1220983505.17299.5.camel@hughsie-work> <604aa7910809091117s143f9a0bt9a244acc41c15ace@mail.gmail.com> Message-ID: <20080909203704.00c9c149.mschwendt@gmail.com> On Tue, 9 Sep 2008 10:17:08 -0800, Jeff Spaleta wrote: > On Tue, Sep 9, 2008 at 10:05 AM, Richard Hughes wrote: > > I've just been banned from the Fedora Forums [1]. > > [1] http://forums.fedoraforum.org/showthread.php?p=1078445#post1078439 > > [2] http://forums.fedoraforum.org/showthread.php?t=192791 > > I would need to know which specific guideline that was referred to. > I'm not sure what "multiple postings" in this context means. In forums like that it is tried to keep open only a single thread for the same [or similar] topic. To avoid that the same issue is discussed in many different threads (or in different sub-forums). "Multiple postings" is if the same reply is posted in multiple threads, and especially if multiple similar [and possibly old] threads are refreshed by posting to them. From jspaleta at gmail.com Tue Sep 9 16:12:37 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 9 Sep 2008 08:12:37 -0800 Subject: make force-tag gone In-Reply-To: <48C69E37.5090205@poolshark.org> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> Message-ID: <604aa7910809090912h5a435625t6dde3238a9934bc@mail.gmail.com> On Tue, Sep 9, 2008 at 8:03 AM, Denis Leroy wrote: > There's no logic here. You're not forcing people to tag after every CVS > check-in, as far as I know. If a release 'n' fails to build (for example, > because you forgot to check-in a patch), it makes zero sense to bump to n+1, > because release 'n' never *existed* in the first place, since it was never > built. That has zero impact over auditing. Spec file auditing is done > through CVS. I believe he misspoke. You are of course free to make 300 small separate specfile changes between each build attempt. There is a desire to move to a point where we can be reasonably sure that a cvs tag corresponds to a specific build. Since we have no way of making only tags corresponding to successfully built packages immutable, all tags must be immutable. Find me a way to mark only the subset of cvs tags which correspond to a successful koji build as immutable. -jef From vgaburici at gmail.com Tue Sep 9 18:39:11 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Tue, 9 Sep 2008 21:39:11 +0300 Subject: Banned from Fedora Forums In-Reply-To: <1220985027.987.84.camel@rosebud> References: <1220983505.17299.5.camel@hughsie-work> <48C6BE3E.3010603@redhat.com> <1220984639.17299.11.camel@hughsie-work> <1220985027.987.84.camel@rosebud> Message-ID: Well, I've only read this message: http://forums.fedoraforum.org/showthread.php?t=192791 Frankly Wayne, "Community Manager And Lord Of The Malt Beverages" should probably take it easy with said beverages since using pejoratives like "PackageSpit" seems hardly a fitting attitude for someone that's supposed to moderate others. Just my 2c. Never visited those forums before... On Tue, Sep 9, 2008 at 9:30 PM, Seth Vidal wrote: > On Tue, 2008-09-09 at 19:23 +0100, Richard Hughes wrote: >> On Tue, 2008-09-09 at 14:19 -0400, Warren Togami wrote: >> > Oh dear. OK, I don't know the full story here, but it appears that both >> > sides are accusing each other of being disrespectful. They seem to >> > dislike PackageKit because it has been very broken for a long time >> > (which I agree with), however that isn't reason to ban a developer for >> > asking for debugging information with the goal of fixing it. >> >> Sure, I'm the first to admit PackageKit has it's bugs (and the 0.1.x >> series was particularly rubbish) but I'm asking users to report bugs in >> bugzilla rather than spread FUD on forums. >> > > > Speaking as someone who has taken no end of crap from people not liking > the program I spend a lot of time working on I'd like to say: > > Welcome to the club, we have jackets. > > I hope you get unbanned. it seems unnecessary and heavy handed. Though > I'm a little fuzzy on how posting it to fedora-devel will help resolve > the problem. > > -sv > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > From jwboyer at gmail.com Tue Sep 9 18:43:36 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 9 Sep 2008 14:43:36 -0400 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: <1220977399.4252.22.camel@kennedy> References: <1220977399.4252.22.camel@kennedy> Message-ID: <20080909184336.GB16093@yoda.jdub.homelinux.org> On Tue, Sep 09, 2008 at 12:23:19PM -0400, Brian Pepple wrote: >Hi, > >Please find below the list of topics that are likely to come up in the >next FESCo meeting that is scheduled for tomorrow, Wednesday at 18:00 >UTC in #fedora-meeting on irc.freenode.org: > >/topic FESCo-Meeting -- MinGW - >https://fedoraproject.org/wiki/User:Jspaleta/Draft - all > >/topic FESCO-Meeting -- Features -- >https://fedoraproject.org/wiki/Features/Presto > >/topic FESCo meeting -- Free discussion around Fedora > >You want something to be discussed? Send a note to the list in reply to >this mail and I'll add it to the schedule. You can also propose topics >in the meeting while it is in the "Free discussion around Fedora" phase. I think we need to talk about the make force-tag change. It was simply done, with no discussion by rel-eng or FESCo. josh From debarshi.ray at gmail.com Tue Sep 9 18:44:24 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Wed, 10 Sep 2008 00:14:24 +0530 Subject: Banned from Fedora Forums In-Reply-To: <1220983505.17299.5.camel@hughsie-work> References: <1220983505.17299.5.camel@hughsie-work> Message-ID: <3170f42f0809091144i4a98a60x314cb1c7199c1941@mail.gmail.com> > These are all the posts I've made on the forum if you want to check any > of my messages: > http://forums.fedoraforum.org/search.php?searchid=7137995 ... and they led me to http://www.gtk.org/setuid.html Thank you. :-) Happy hacking, Debarshi From bpepple at fedoraproject.org Tue Sep 9 18:54:28 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 09 Sep 2008 14:54:28 -0400 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: <20080909184336.GB16093@yoda.jdub.homelinux.org> References: <1220977399.4252.22.camel@kennedy> <20080909184336.GB16093@yoda.jdub.homelinux.org> Message-ID: <1220986468.7707.1.camel@kennedy> On Tue, 2008-09-09 at 14:43 -0400, Josh Boyer wrote: > >You want something to be discussed? Send a note to the list in reply to > >this mail and I'll add it to the schedule. You can also propose topics > >in the meeting while it is in the "Free discussion around Fedora" phase. > > I think we need to talk about the make force-tag change. It was simply > done, with no discussion by rel-eng or FESCo. I've added it to the schedule. Thanks, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Tue Sep 9 18:56:04 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 9 Sep 2008 10:56:04 -0800 Subject: Banned from Fedora Forums In-Reply-To: <20080909203704.00c9c149.mschwendt@gmail.com> References: <1220983505.17299.5.camel@hughsie-work> <604aa7910809091117s143f9a0bt9a244acc41c15ace@mail.gmail.com> <20080909203704.00c9c149.mschwendt@gmail.com> Message-ID: <604aa7910809091156v467f1d2sa626c074ea71181e@mail.gmail.com> On Tue, Sep 9, 2008 at 10:37 AM, Michael Schwendt wrote: > In forums like that it is tried to keep open only a single thread for the > same [or similar] topic. To avoid that the same issue is discussed in many > different threads (or in different sub-forums). "Multiple postings" is if > the same reply is posted in multiple threads, and especially if multiple > similar [and possibly old] threads are refreshed by posting to them. Is that codified in fedoraforum's guidelines? I'm not sure I see that communicated in a way that is obvious to me. As to "old threads" it would be good to have some basic rule of thumb as to when a thread is "too old" to reply to. Can the forum be configured to automatically close the threads if they are inactive for long enough? We do need to have developers responding to threads about bugs in the forums. But probably also need some specific guidance on how developers are expected to reply. if there are a lot of threads about bugs in a certain package, I think its reasonable a developer to repeatedly suggest filing bugs in the appropriate place to make sure these things get fixed. Beyond the layer of personal bias about PK that is apparent, there is a deeper layer of uncommunicated expectations on general user/developer interaction that needs to be addressed -jef From hughsient at gmail.com Tue Sep 9 19:01:10 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 09 Sep 2008 20:01:10 +0100 Subject: Banned from Fedora Forums In-Reply-To: <1220985027.987.84.camel@rosebud> References: <1220983505.17299.5.camel@hughsie-work> <48C6BE3E.3010603@redhat.com> <1220984639.17299.11.camel@hughsie-work> <1220985027.987.84.camel@rosebud> Message-ID: <1220986870.17299.19.camel@hughsie-work> On Tue, 2008-09-09 at 14:30 -0400, Seth Vidal wrote: > Speaking as someone who has taken no end of crap from people not liking > the program I spend a lot of time working on I'd like to say: > > Welcome to the club, we have jackets. Totally agree. > I hope you get unbanned. it seems unnecessary and heavy handed. Though > I'm a little fuzzy on how posting it to fedora-devel will help resolve > the problem. I wanted to make sure the issue was brought to peoples attention -- I mean, if I tried to get involved and help end users and got pushed back, how many other keen developers have tried? Maybe f-d was the wrong place, I dunno. Richard. From bpepple at fedoraproject.org Tue Sep 9 19:07:05 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 09 Sep 2008 15:07:05 -0400 Subject: Banned from Fedora Forums In-Reply-To: <48C6BE3E.3010603@redhat.com> References: <1220983505.17299.5.camel@hughsie-work> <48C6BE3E.3010603@redhat.com> Message-ID: <1220987225.7707.7.camel@kennedy> On Tue, 2008-09-09 at 14:19 -0400, Warren Togami wrote: > This is especially problematic when Fedora Forum is our #1 preferred > place to direct end-users to for end-user support. fedora-list is a > dramatic pile of fail for this purpose. We also want to promote greater > participation of fedora developers on Fedora Forum in order to better > understand what are the common failures and to encourage users to follow > the proper processes to isolate the causes and test solutions. Should Fedora Forum be our #1 preferred place? I periodically drop in, and I have to agree with Richard that there is not much incentive for developers to invest time trying to answer questions there. Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ssorce at redhat.com Tue Sep 9 19:08:03 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 09 Sep 2008 15:08:03 -0400 Subject: make force-tag gone In-Reply-To: <604aa7910809090912h5a435625t6dde3238a9934bc@mail.gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <604aa7910809090912h5a435625t6dde3238a9934bc@mail.gmail.com> Message-ID: <1220987283.15726.60.camel@localhost.localdomain> On Tue, 2008-09-09 at 08:12 -0800, Jeff Spaleta wrote: > On Tue, Sep 9, 2008 at 8:03 AM, Denis Leroy wrote: > > There's no logic here. You're not forcing people to tag after every CVS > > check-in, as far as I know. If a release 'n' fails to build (for example, > > because you forgot to check-in a patch), it makes zero sense to bump to n+1, > > because release 'n' never *existed* in the first place, since it was never > > built. That has zero impact over auditing. Spec file auditing is done > > through CVS. > > I believe he misspoke. You are of course free to make 300 small > separate specfile changes between each build attempt. > > There is a desire to move to a point where we can be reasonably sure > that a cvs tag corresponds to a specific build. Since we have no way > of making only tags corresponding to successfully built packages > immutable, all tags must be immutable. > Find me a way to mark only the subset of cvs tags which correspond to > a successful koji build as immutable. If this is the aim, then koji should be the one to tag the CVS after a build is successful. It doesn't make sense to tag an unsuccessful build,a nd it is an unnecessary burden on developers. Automation is better, let koji do it. Simo. -- Simo Sorce * Red Hat, Inc * New York From skvidal at fedoraproject.org Tue Sep 9 19:08:11 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 09 Sep 2008 15:08:11 -0400 Subject: Banned from Fedora Forums In-Reply-To: <1220986870.17299.19.camel@hughsie-work> References: <1220983505.17299.5.camel@hughsie-work> <48C6BE3E.3010603@redhat.com> <1220984639.17299.11.camel@hughsie-work> <1220985027.987.84.camel@rosebud> <1220986870.17299.19.camel@hughsie-work> Message-ID: <1220987291.987.88.camel@rosebud> On Tue, 2008-09-09 at 20:01 +0100, Richard Hughes wrote: > On Tue, 2008-09-09 at 14:30 -0400, Seth Vidal wrote: > > Speaking as someone who has taken no end of crap from people not liking > > the program I spend a lot of time working on I'd like to say: > > > > Welcome to the club, we have jackets. > > Totally agree. > No, I'm serious (sort of) http://www.cafepress.com/FYum :) > > I hope you get unbanned. it seems unnecessary and heavy handed. Though > > I'm a little fuzzy on how posting it to fedora-devel will help resolve > > the problem. > > I wanted to make sure the issue was brought to peoples attention -- I > mean, if I tried to get involved and help end users and got pushed back, > how many other keen developers have tried? Maybe f-d was the wrong > place, I dunno. maybe bring it to the board and/or fesco. or if it is very sensitive bring it to pfrields. -sv From sb at monkey-mind.net Tue Sep 9 17:59:45 2008 From: sb at monkey-mind.net (Steven Bakker) Date: Tue, 09 Sep 2008 19:59:45 +0200 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <20080905154006.GA23967@auslistsprd01.us.dell.com> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> Message-ID: <1220983185.6621.1.camel@cluestix.noc.ams-ix.net> On Fri, 2008-09-05 at 10:40 -0500, Matt Domsch wrote: > gstm-1.2-6.fc7 [u'434531 ASSIGNED'] (build/make) splinux I just updated the bug with a patch for the spec file. I'd appreciate it if it could be applied, as I've grown quite attached to gstm ;-) Cheers, -- Steven From denis at poolshark.org Tue Sep 9 18:40:03 2008 From: denis at poolshark.org (Denis Leroy) Date: Tue, 09 Sep 2008 20:40:03 +0200 Subject: make force-tag gone In-Reply-To: <1220984439.3388.0.camel@luminos.localdomain> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> <1220981974.11620.37.camel@luminos.localdomain> <48C6B82F.8080402@poolshark.org> <1220984439.3388.0.camel@luminos.localdomain> Message-ID: <48C6C303.1060703@poolshark.org> Jesse Keating wrote: > On Tue, 2008-09-09 at 19:53 +0200, Denis Leroy wrote: >> that's why we have CVS. > > But when you change the only reference point we have, the tag, that goes > right out the window now doesn't it? Not there is "cvs update -D" from the build time. Seriously, if you really need to recreate a specific koji build failure, it's not exactly hard to look at the cvs history and date tags and checkout the exact version that produced it... From alain.portal at free.fr Tue Sep 9 19:01:13 2008 From: alain.portal at free.fr (Alain PORTAL) Date: Tue, 9 Sep 2008 21:01:13 +0200 Subject: Banned from Fedora Forums In-Reply-To: <1220983505.17299.5.camel@hughsie-work> References: <1220983505.17299.5.camel@hughsie-work> Message-ID: <200809092101.13908.alain.portal@free.fr> Le mardi 09 septembre 2008, Richard Hughes a ?crit : > I've just been banned from the Fedora Forums [1]. Bienvenue au club ! :-D [1] [1] Welcome to the club.... Regards, Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- 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 Tue Sep 9 18:39:13 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 9 Sep 2008 10:39:13 -0800 Subject: Banned from Fedora Forums In-Reply-To: <1220984841.17299.16.camel@hughsie-work> References: <1220983505.17299.5.camel@hughsie-work> <604aa7910809091117s143f9a0bt9a244acc41c15ace@mail.gmail.com> <1220984841.17299.16.camel@hughsie-work> Message-ID: <604aa7910809091139v102276c8je61a78db44b8716f@mail.gmail.com> On Tue, Sep 9, 2008 at 10:27 AM, Richard Hughes wrote: > I figured it was because I was just posting about PackageKit stuff, > which is true, I want people to report bugs and feature requests in > bugzilla so we can fix them. I also think it's useful to be able to > search for a thread, and get a valid answer, rather than some broken > workaround. I need clarity as to what specific guideline is at issue. The reference you gave mentioned 'multiple posting' but I'm not sure what that means exactly or whether it has been applied consistently as a rationale for banning people. I don't know how to move forward unless I have understanding of that underlining guidance and its interpretation. -jef From mschwendt at gmail.com Tue Sep 9 19:14:04 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 9 Sep 2008 21:14:04 +0200 Subject: Banned from Fedora Forums In-Reply-To: <604aa7910809091156v467f1d2sa626c074ea71181e@mail.gmail.com> References: <1220983505.17299.5.camel@hughsie-work> <604aa7910809091117s143f9a0bt9a244acc41c15ace@mail.gmail.com> <20080909203704.00c9c149.mschwendt@gmail.com> <604aa7910809091156v467f1d2sa626c074ea71181e@mail.gmail.com> Message-ID: <20080909211404.c92bfa15.mschwendt@gmail.com> On Tue, 9 Sep 2008 10:56:04 -0800, Jeff Spaleta wrote: > On Tue, Sep 9, 2008 at 10:37 AM, Michael Schwendt wrote: > > In forums like that it is tried to keep open only a single thread for the > > same [or similar] topic. To avoid that the same issue is discussed in many > > different threads (or in different sub-forums). "Multiple postings" is if > > the same reply is posted in multiple threads, and especially if multiple > > similar [and possibly old] threads are refreshed by posting to them. > > Is that codified in fedoraforum's guidelines? I'm not sure I see that > communicated in a way that is obvious to me. I specifically wrote "in forums like that" referring to how it's handled in many web-based message boards. It's typically not put into policies, because hardly anybody would read them anyway. I dunno how it is done at fedoraforum. > As to "old threads" it would be good to have some basic rule of thumb > as to when a thread is "too old" to reply to. Can the forum be > configured to automatically close the threads if they are inactive for > long enough? That's not easy to enforce. In a good forum, where people put common sense to good use, after years there still could be only single thread for each unique topic, and you could refresh it any time it is appropriate. Unfortunately, the more popular a forum gets, the less people search before they post. And the less people search, the more duplicate [or similar] threads are created. In turn, the search results are flooded, stuff becomes less easy to find. If threads are closed, users are forced to open new ones. Valuable details in old closed threads gets buried. From hughsient at gmail.com Tue Sep 9 19:11:16 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 09 Sep 2008 20:11:16 +0100 Subject: Banned from Fedora Forums In-Reply-To: <1220987291.987.88.camel@rosebud> References: <1220983505.17299.5.camel@hughsie-work> <48C6BE3E.3010603@redhat.com> <1220984639.17299.11.camel@hughsie-work> <1220985027.987.84.camel@rosebud> <1220986870.17299.19.camel@hughsie-work> <1220987291.987.88.camel@rosebud> Message-ID: <1220987476.17299.22.camel@hughsie-work> On Tue, 2008-09-09 at 15:08 -0400, Seth Vidal wrote: > > I wanted to make sure the issue was brought to peoples attention -- > I > > mean, if I tried to get involved and help end users and got pushed > back, > > how many other keen developers have tried? Maybe f-d was the wrong > > place, I dunno. > > maybe bring it to the board and/or fesco. > or if it is very sensitive bring it to pfrields. To be honest, I'm not that bothered. It's not anything that will impact how I interact with the Fedora community day-to-day or how I work for Red Hat, it just seemed a shame. Richard. From dennis at ausil.us Tue Sep 9 17:58:14 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 9 Sep 2008 12:58:14 -0500 Subject: make force-tag gone In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> Message-ID: <200809091303.22845.dennis@ausil.us> On Tuesday 09 September 2008 12:39:48 pm Kevin Kofler wrote: > Jeffrey Ollie ocjtech.us> writes: > > Refusing to bump a release number and re-tag because you don't want to > > "look stupid" is not a technical argument. > > Maybe, but it's a practical argument. > > > And before you ask, yes I've used force-tag before even though I know > > I shouldn't. Removing it will help me be a better package manager. > > No, it will make you a worse packager, as your Release tags will get > incremented for no reason. > > Kevin Kofler how does that make you a "worse packager" it is clearly showing the work that you are doing. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From dennis at ausil.us Tue Sep 9 19:25:09 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 9 Sep 2008 14:25:09 -0500 Subject: Banned from Fedora Forums In-Reply-To: <1220983505.17299.5.camel@hughsie-work> References: <1220983505.17299.5.camel@hughsie-work> Message-ID: <200809091427.32034.dennis@ausil.us> On Tuesday 09 September 2008 01:05:05 pm Richard Hughes wrote: > I've just been banned from the Fedora Forums [1]. You need to speak to the people who run fedora forums. Fedora infrastructure has nothing to do with them, and they are not officially affiliated with fedora. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From wtogami at redhat.com Tue Sep 9 19:28:57 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 09 Sep 2008 15:28:57 -0400 Subject: Banned from Fedora Forums In-Reply-To: <1220987225.7707.7.camel@kennedy> References: <1220983505.17299.5.camel@hughsie-work> <48C6BE3E.3010603@redhat.com> <1220987225.7707.7.camel@kennedy> Message-ID: <48C6CE79.3050304@redhat.com> Brian Pepple wrote: > On Tue, 2008-09-09 at 14:19 -0400, Warren Togami wrote: >> This is especially problematic when Fedora Forum is our #1 preferred >> place to direct end-users to for end-user support. fedora-list is a >> dramatic pile of fail for this purpose. We also want to promote greater >> participation of fedora developers on Fedora Forum in order to better >> understand what are the common failures and to encourage users to follow >> the proper processes to isolate the causes and test solutions. > > Should Fedora Forum be our #1 preferred place? I periodically drop in, > and I have to agree with Richard that there is not much incentive for > developers to invest time trying to answer questions there. > Should it? I don't know. It just became the de facto preferred place with the lack of anything better. Warren Togami wtogami at redhat.com From skvidal at fedoraproject.org Tue Sep 9 19:28:45 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 09 Sep 2008 15:28:45 -0400 Subject: Banned from Fedora Forums In-Reply-To: <200809091427.32034.dennis@ausil.us> References: <1220983505.17299.5.camel@hughsie-work> <200809091427.32034.dennis@ausil.us> Message-ID: <1220988525.987.93.camel@rosebud> On Tue, 2008-09-09 at 14:25 -0500, Dennis Gilmore wrote: > On Tuesday 09 September 2008 01:05:05 pm Richard Hughes wrote: > > I've just been banned from the Fedora Forums [1]. > You need to speak to the people who run fedora forums. Fedora infrastructure > has nothing to do with them, and they are not officially affiliated with fedora. > well the forum is blessed by the board.... -sv From notting at redhat.com Tue Sep 9 19:30:47 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 9 Sep 2008 15:30:47 -0400 Subject: Banned from Fedora Forums In-Reply-To: <200809091427.32034.dennis@ausil.us> References: <1220983505.17299.5.camel@hughsie-work> <200809091427.32034.dennis@ausil.us> Message-ID: <20080909193046.GA20070@nostromo.devel.redhat.com> Dennis Gilmore (dennis at ausil.us) said: > On Tuesday 09 September 2008 01:05:05 pm Richard Hughes wrote: > > I've just been banned from the Fedora Forums [1]. > > You need to speak to the people who run fedora forums. Fedora infrastructure > has nothing to do with them, and they are not officially affiliated with fedora. Well, if we're allowing them to use the Fedora mark, I suppose we need to do minor policing of complaints. Probably a board issue. (ugh) Bill From hughsient at gmail.com Tue Sep 9 19:31:44 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 09 Sep 2008 20:31:44 +0100 Subject: Banned from Fedora Forums In-Reply-To: <20080909193046.GA20070@nostromo.devel.redhat.com> References: <1220983505.17299.5.camel@hughsie-work> <200809091427.32034.dennis@ausil.us> <20080909193046.GA20070@nostromo.devel.redhat.com> Message-ID: <1220988704.17299.29.camel@hughsie-work> On Tue, 2008-09-09 at 15:30 -0400, Bill Nottingham wrote: > Dennis Gilmore (dennis at ausil.us) said: > > On Tuesday 09 September 2008 01:05:05 pm Richard Hughes wrote: > > > I've just been banned from the Fedora Forums [1]. > > > > You need to speak to the people who run fedora forums. Fedora > infrastructure > > has nothing to do with them, and they are not officially affiliated > with fedora. > > Well, if we're allowing them to use the Fedora mark, I suppose we need > to do minor policing of complaints. Probably a board issue. (ugh) I'm not complaining, they've just lost one developer who was willing to help end users. I try really, really, hard as a developer to listen to end users with bugs and feature requests. Moderators on a power trip are not interesting to me. Richard. From bpepple at fedoraproject.org Tue Sep 9 19:56:37 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 09 Sep 2008 15:56:37 -0400 Subject: Banned from Fedora Forums In-Reply-To: <48C6CE79.3050304@redhat.com> References: <1220983505.17299.5.camel@hughsie-work> <48C6BE3E.3010603@redhat.com> <1220987225.7707.7.camel@kennedy> <48C6CE79.3050304@redhat.com> Message-ID: <1220990197.7707.16.camel@kennedy> On Tue, 2008-09-09 at 15:28 -0400, Warren Togami wrote: > Brian Pepple wrote: > > On Tue, 2008-09-09 at 14:19 -0400, Warren Togami wrote: > >> This is especially problematic when Fedora Forum is our #1 preferred > >> place to direct end-users to for end-user support. fedora-list is a > >> dramatic pile of fail for this purpose. We also want to promote greater > >> participation of fedora developers on Fedora Forum in order to better > >> understand what are the common failures and to encourage users to follow > >> the proper processes to isolate the causes and test solutions. > > > > Should Fedora Forum be our #1 preferred place? I periodically drop in, > > and I have to agree with Richard that there is not much incentive for > > developers to invest time trying to answer questions there. > > > > Should it? I don't know. > > It just became the de facto preferred place with the lack of anything > better. Maybe the Board should re-evaluated whether we should continue to promote that as our #1 choice. Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Tue Sep 9 19:57:37 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 09 Sep 2008 21:57:37 +0200 Subject: make force-tag gone In-Reply-To: <200809091303.22845.dennis@ausil.us> References: <1220955240.24928.69.camel@cookie.hadess.net> <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> <200809091303.22845.dennis@ausil.us> Message-ID: <1220990257.7986.5.camel@rousalka.okg> Le mardi 09 septembre 2008 ? 12:58 -0500, Dennis Gilmore a ?crit : > On Tuesday 09 September 2008 12:39:48 pm Kevin Kofler wrote: > > Jeffrey Ollie ocjtech.us> writes: > > > Refusing to bump a release number and re-tag because you don't want to > > > "look stupid" is not a technical argument. > > > > Maybe, but it's a practical argument. > > > > > And before you ask, yes I've used force-tag before even though I know > > > I shouldn't. Removing it will help me be a better package manager. > > > > No, it will make you a worse packager, as your Release tags will get > > incremented for no reason. > > > how does that make you a "worse packager" it is clearly showing the work > that you are doing. rawhide kernel is at release 317 right now. A large portion of those 317 were mis-builds, oopsing kernels and other various fails (including stupid typos). Anyone dares saying our kernel people are abysmal packagers? -- 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 jspaleta at gmail.com Tue Sep 9 20:09:54 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 9 Sep 2008 12:09:54 -0800 Subject: Banned from Fedora Forums In-Reply-To: <1220990197.7707.16.camel@kennedy> References: <1220983505.17299.5.camel@hughsie-work> <48C6BE3E.3010603@redhat.com> <1220987225.7707.7.camel@kennedy> <48C6CE79.3050304@redhat.com> <1220990197.7707.16.camel@kennedy> Message-ID: <604aa7910809091309s431416ddka88f2587d274b6dd@mail.gmail.com> 2008/9/9 Brian Pepple : > Maybe the Board should re-evaluated whether we should continue to > promote that as our #1 choice. Yeah, let's just add fuel to the fire and crank up the tension over this issue. How about we backup... and just figure out..specifically what line was crossed..so we can try to avoid having that line crossed again. We could have the same blasted problem in any moderated communications medium. In fact I believe we have already seen this happen in other contexts... or do I need to remind you about the French sub-community problems we've been experiencing. Was this banning incident precedent setting for this forum? Have others been previously banned for the same stated reason? Is the stated reason actually part of the communicated guidance for interaction in the forum? Questions I'm not going to find answers for here. I'll have to walk over to fedora forum's admin team and ask them these questions. And having them on the defensive because someone has suggested already that we re-evaluate our relationship with them isn't going to help. These are all questions I need some reasonable answers to before I'm willing to engage in bridge burning at some a high level. -jef From pemboa at gmail.com Tue Sep 9 19:21:38 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 9 Sep 2008 14:21:38 -0500 Subject: Banned from Fedora Forums In-Reply-To: <1220983505.17299.5.camel@hughsie-work> References: <1220983505.17299.5.camel@hughsie-work> Message-ID: <16de708d0809091221y46ad408ci8a97b9495f058ff6@mail.gmail.com> On Tue, Sep 9, 2008 at 1:05 PM, Richard Hughes wrote: > I've just been banned from the Fedora Forums [1]. > > I've been asking users with PackageKit bugs to report them upstream on > the mailing list or in bugzilla, explaining what common error messages > mean, and how to fix other problems. > This, it turns out isn't what the forums are for. I guess it's just for > uniformed users telling less informed users how to "fix" things. My > mistake. > > I won't be even reading the forums anymore, and consider the couple of > hours I spent on the forums answering questions and educating users > about PackageKit wasted. > These are all the posts I've made on the forum if you want to check any > of my messages: > http://forums.fedoraforum.org/search.php?searchid=7137995 > > A few of them are pretty blunt, but the personal critique of my skills > as a programmer [2] and PackageKit is pretty blunt too (especially by a > "Community Manager"). I have no knowledge of the situation at hand, however I would like to just say. If you need something specific tested, send an email to the fedora-test-list. I monitor that list for atomic tests that I can take some time out of the day and run on my rawhide box. More on topic, I wasn't aware that people were having issues with packagekit, it hasn't gotten in my way as yet on 3 machines with F9. -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From luya_tfz at thefinalzone.com Tue Sep 9 20:14:51 2008 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Tue, 9 Sep 2008 16:14:51 -0400 Subject: Banned from Fedora Forums In-Reply-To: <1220983505.17299.5.camel@hughsie-work> References: <1220983505.17299.5.camel@hughsie-work> Message-ID: <1220991291.48c6d93bcdfb0@ssl.mecca.ca> Quoting Richard Hughes : > A few of them are pretty blunt, but the personal critique of my skills > as a programmer [2] and PackageKit is pretty blunt too (especially by a > "Community Manager"). Hi Richard, I am one of developer from Fedora Artwork who has been recently promoted as Community Manager mostly for adding Fedora Weekly News. I haven't followed the incident about the ban issue, being busy with daily schedule for college and work on Echo icon theme, until now. I think there is a problem with communication with one of community manager (I avoid to mention name to prevent further clashing). As for the guideline, here is[1]. Though I have not read all posts, bringing to Fesco would be good idea. Ironically, this controversy like this one brought exposure of both users and developers. It appears now that more active participations are needed thus bringing more strong ties. I apologize for now being active in that topic. Hopefully that will be resolved in a diplomatic way. Regards, -- Luya Tshimbalanga Fedora Project contributor http://www.fedoraproject.org/wiki/LuyaTshimbalanga Reference: http://www.fedoraforum.org/?view=guide From choeger at cs.tu-berlin.de Tue Sep 9 20:10:29 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 09 Sep 2008 22:10:29 +0200 Subject: Feature Proposal: Use cases database Message-ID: <1220991029.3782.47.camel@choeger6> Hi folks, in the past weeks I had an idea about how to improve the user support. I'll sketch it: 1. A "normal" user, especially when new to Linux will probably start his computer with a concrete idea what he wants to do ("surf the web", "check my mail", "write a document" etc.). While there are tons of information (some of them useful, some not), every peace of information needs the user to at least surf to a given web page and search it for what he needs (not talking about subscribing to a high traffic mailing list). That is definitely too much work for our beginner. Especially, if he wants to know "how to surf the web". 2. The main difference here between Linux and windows is where a beginner can get support. Obviously the lesser spread of linux distributions is a disadvantage. But the distribution itself is not only the solution to this problem, but an even bigger advantage: Thousands of users have access to the same software in the same version. And all of them do those use cases. So we should bring the information about how to do such a use case in our distribution to the user with the distribution itself. 3. So how could we address that technically? Basically a wiki would be a good starting point for some (when not all) of the basic use cases. From there we could bring localized HowTos over a desktop applications to the user (asking "what do you want to do today"). But that's not all: we could also * deliver a set of scripts to check if the desired software is installed in the correct versions. * integrate that system with smolt to get information about which hardware will probably work and which not (this could avoid some frustration) * integrate some kind of "how could I use that file?" functionality in our document centric desktop * lead to further support possibilties (mailing lists, forums) and how to use them * allow a user to easily post a bug report when a use case should work but doesn't * What do you think? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From a.badger at gmail.com Tue Sep 9 20:24:07 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 09 Sep 2008 13:24:07 -0700 Subject: make force-tag gone In-Reply-To: <1220987283.15726.60.camel@localhost.localdomain> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <604aa7910809090912h5a435625t6dde3238a9934bc@mail.gmail.com> <1220987283.15726.60.camel@localhost.localdomain> Message-ID: <48C6DB67.3060706@gmail.com> Simo Sorce wrote: > On Tue, 2008-09-09 at 08:12 -0800, Jeff Spaleta wrote: >> On Tue, Sep 9, 2008 at 8:03 AM, Denis Leroy wrote: >>> There's no logic here. You're not forcing people to tag after every CVS >>> check-in, as far as I know. If a release 'n' fails to build (for example, >>> because you forgot to check-in a patch), it makes zero sense to bump to n+1, >>> because release 'n' never *existed* in the first place, since it was never >>> built. That has zero impact over auditing. Spec file auditing is done >>> through CVS. >> I believe he misspoke. You are of course free to make 300 small >> separate specfile changes between each build attempt. >> >> There is a desire to move to a point where we can be reasonably sure >> that a cvs tag corresponds to a specific build. Since we have no way >> of making only tags corresponding to successfully built packages >> immutable, all tags must be immutable. >> Find me a way to mark only the subset of cvs tags which correspond to >> a successful koji build as immutable. > > If this is the aim, then koji should be the one to tag the CVS after a > build is successful. Question 1: Does this still fall under the all or nothing prevention of moving tags? I don't know CVS well enough to know if there's a fullblown hook that can be run to determine that "all tags prefixed with koji-* are immutable". If so, that is a way to achieve this and was proposed by Jesse several months ago. > It doesn't make sense to tag an unsuccessful build,a nd it is an > unnecessary burden on developers. > Actually... tagging an unsuccessful build is useful. How else do you take a look at what caused a particular build to fail? I think having multiple immutable tags for the same NVR would be preferable. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From denis at poolshark.org Tue Sep 9 20:28:32 2008 From: denis at poolshark.org (Denis Leroy) Date: Tue, 09 Sep 2008 22:28:32 +0200 Subject: make force-tag gone In-Reply-To: <48C6DB67.3060706@gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <604aa7910809090912h5a435625t6dde3238a9934bc@mail.gmail.com> <1220987283.15726.60.camel@localhost.localdomain> <48C6DB67.3060706@gmail.com> Message-ID: <48C6DC70.2070402@poolshark.org> Toshio Kuratomi wrote: > Actually... tagging an unsuccessful build is useful. How else do you > take a look at what caused a particular build to fail? cvs update -D 'koji build time' There's already a safeguard that won't let you build if the files are not checked in. From luya_tfz at thefinalzone.com Tue Sep 9 20:34:17 2008 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Tue, 9 Sep 2008 16:34:17 -0400 Subject: Banned from Fedora Forums In-Reply-To: <1220990197.7707.16.camel@kennedy> References: <1220983505.17299.5.camel@hughsie-work> <48C6BE3E.3010603@redhat.com> <1220987225.7707.7.camel@kennedy> <48C6CE79.3050304@redhat.com> <1220990197.7707.16.camel@kennedy> Message-ID: <1220992457.48c6ddc968e22@ssl.mecca.ca> Quoting Brian Pepple : > Maybe the Board should re-evaluated whether we should continue to > promote that as our #1 choice. Better way is to look to the cause, investigate the problem. Remember an action of one does not necessary represent the whole management which is unfortunately common mistake. -- Luya Tshimbalanga Fedora Project contributor http://www.fedoraproject.org/wiki/LuyaTshimbalanga From rrankin at ihug.com.au Tue Sep 9 20:45:56 2008 From: rrankin at ihug.com.au (Roy Rankin) Date: Wed, 10 Sep 2008 06:45:56 +1000 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <200809091750.56763.alain.portal@free.fr> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <200809082248.06835.alain.portal@free.fr> <48C59FAF.1090009@ihug.com.au> <200809091750.56763.alain.portal@free.fr> Message-ID: <48C6E084.7030209@ihug.com.au> Alain, As I understand (I hope someone will correct me if I am wrong), log into https://admin.fedoraproject.org/pkgdb/, and press "release ownership". Let me know when this is done and then I can claim ownership. Regards, Roy Rankin Alain PORTAL wrote: > Le lundi 08 septembre 2008, Roy Rankin a ?crit : >> Alain, >> >> Yes, I can take both gpsim and gtk-extras. > > So, what we have to do to do that? > > Regards, > Alain > From dpquigl at tycho.nsa.gov Tue Sep 9 20:35:26 2008 From: dpquigl at tycho.nsa.gov (David P. Quigley) Date: Tue, 09 Sep 2008 16:35:26 -0400 Subject: Banned from Fedora Forums In-Reply-To: <1220991291.48c6d93bcdfb0@ssl.mecca.ca> References: <1220983505.17299.5.camel@hughsie-work> <1220991291.48c6d93bcdfb0@ssl.mecca.ca> Message-ID: <1220992526.5347.26.camel@moss-terrapins.epoch.ncsc.mil> On Tue, 2008-09-09 at 16:14 -0400, Luya Tshimbalanga wrote: > Quoting Richard Hughes : > > > A few of them are pretty blunt, but the personal critique of my skills > > as a programmer [2] and PackageKit is pretty blunt too (especially by a > > "Community Manager"). > > Hi Richard, > > I am one of developer from Fedora Artwork who has been recently promoted as > Community Manager mostly for adding Fedora Weekly News. I haven't followed the > incident about the ban issue, being busy with daily schedule for college and > work on Echo icon theme, until now. I think there is a problem with > communication with one of community manager (I avoid to mention name to prevent > further clashing). As for the guideline, here is[1]. Though I have not read all > posts, bringing to Fesco would be good idea. > > Ironically, this controversy like this one brought exposure of both users and > developers. It appears now that more active participations are needed thus > bringing more strong ties. > > I apologize for now being active in that topic. Hopefully that will be resolved > in a diplomatic way. > > Regards, > > > -- > Luya Tshimbalanga > Fedora Project contributor > http://www.fedoraproject.org/wiki/LuyaTshimbalanga > > > Reference: > > http://www.fedoraforum.org/?view=guide > I don't normally chime in on stuff like this but I actually registered for fedora forums recently so I could provide some SELinux help on my off time. I've read through a majority of Richard's posts and from what I see his main sin here is responding to old posts. I also read through the guidelines and faq that the person who banned Richard says to read and nowhere in there do I see a mention of not dredging up old posts. The closest thing I can see Richard violating in the guidelines is "cross posting" by possibly posting the same answer to several questions. If dredging up old posts is an offense then it should definitely be in the guidelines that you linked. It seems that all of Richard's posts were today so if he registered today and was banned today this is probably a bit heavy handed considering most of his posts were civil and being rude doesn't seem to be one of the reasons for banning him. On the other hand the person who banned Richard started a thread with a post that violates several of the guidelines and then proceeded to use those same guidelines as later justification to ban him. It's unfortunate that something like this happened since I've never had a problem with packagekit getting in my way at all. I can only imagine the stuff I'd face since most peoples' first instinct when something goes wrong is to blame SELinux. Dave P.S. I only speak for myself. From vonbrand at inf.utfsm.cl Tue Sep 9 21:00:25 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Tue, 09 Sep 2008 17:00:25 -0400 Subject: rawhide report: 20080909 changes In-Reply-To: <20080909103814.D26201F8247@releng2.fedora.phx.redhat.com> References: <20080909103814.D26201F8247@releng2.fedora.phx.redhat.com> Message-ID: <200809092100.m89L0Pes008548@laptop14.inf.utfsm.cl> Rawhide Report wrote: > New package beep [etc, and lots of updates] yum doen't get any update today... even "yum clean metadata" doesn't get it to grok new packages that _are_ there. And downloading docbook-utils-0.6.14-14.fc10.noarch.rpm and trying "yum localinstall" on that complains it isn't signed (but gpgcheck = 0 in the fedora-rawhide.repo file) What gives? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From alain.portal at free.fr Tue Sep 9 21:23:49 2008 From: alain.portal at free.fr (Alain PORTAL) Date: Tue, 9 Sep 2008 23:23:49 +0200 Subject: Proposed removal of packages with long-standing FTBFS failures In-Reply-To: <48C6E084.7030209@ihug.com.au> References: <20080905154006.GA23967@auslistsprd01.us.dell.com> <200809091750.56763.alain.portal@free.fr> <48C6E084.7030209@ihug.com.au> Message-ID: <200809092323.50206.alain.portal@free.fr> Le mardi 09 septembre 2008, Roy Rankin a ?crit : > Alain, > > As I understand (I hope someone will correct me if I am wrong), log into > https://admin.fedoraproject.org/pkgdb/, and press "release ownership". > Let me know when this is done and then I can claim ownership. Done. Do you want to take gputils ? Regards, Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From skvidal at fedoraproject.org Tue Sep 9 21:33:18 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 09 Sep 2008 17:33:18 -0400 Subject: Boot speedup with readahead In-Reply-To: <1220983079.987.79.camel@rosebud> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> Message-ID: <1220995998.987.98.camel@rosebud> On Tue, 2008-09-09 at 13:57 -0400, Seth Vidal wrote: > On Tue, 2008-09-09 at 13:51 -0400, Behdad Esfahbod wrote: > > Shouldn't this be done on RPM level? Isn't this pretty much an extension of > > RPM triggers? Or it's so hard to do that that we now want to move stuff to yum? > > > a proof of concept plugin for yum is almost finished. If we want to move > it to the rpm layer, fine. The rpm devs are busy and getting this added > to rpm will take some time. I don't really see the problem in working on > it here. > Here's a proof of concept plugin: http://skvidal.fedorapeople.org/misc/post-transaction-actions/ put the .py file in /usr/lib/yum-plugins put the .conf file in /etc/yum/pluginconf.d/ make an /etc/yum/post-actions/ and put the .action file in there - add more .action files as you'd like. run yum transactions and see what happens... -sv From jreiser at BitWagon.com Tue Sep 9 21:45:16 2008 From: jreiser at BitWagon.com (John Reiser) Date: Tue, 09 Sep 2008 14:45:16 -0700 Subject: rawhide report: 20080909 changes In-Reply-To: <200809092100.m89L0Pes008548@laptop14.inf.utfsm.cl> References: <20080909103814.D26201F8247@releng2.fedora.phx.redhat.com> <200809092100.m89L0Pes008548@laptop14.inf.utfsm.cl> Message-ID: <48C6EE6C.6090901@BitWagon.com> > downloading > docbook-utils-0.6.14-14.fc10.noarch.rpm and trying "yum localinstall" on > that complains it isn't signed (but gpgcheck = 0 in the fedora-rawhide.repo > file) localinstall ignores the repos, so I use yum --nogpgcheck localinstall *.rpm -- From ssorce at redhat.com Tue Sep 9 22:09:53 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 09 Sep 2008 18:09:53 -0400 Subject: make force-tag gone In-Reply-To: <48C6DB67.3060706@gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <604aa7910809090912h5a435625t6dde3238a9934bc@mail.gmail.com> <1220987283.15726.60.camel@localhost.localdomain> <48C6DB67.3060706@gmail.com> Message-ID: <1220998193.15726.76.camel@localhost.localdomain> On Tue, 2008-09-09 at 13:24 -0700, Toshio Kuratomi wrote: > Simo Sorce wrote: > > On Tue, 2008-09-09 at 08:12 -0800, Jeff Spaleta wrote: > >> On Tue, Sep 9, 2008 at 8:03 AM, Denis Leroy wrote: > >>> There's no logic here. You're not forcing people to tag after every CVS > >>> check-in, as far as I know. If a release 'n' fails to build (for example, > >>> because you forgot to check-in a patch), it makes zero sense to bump to n+1, > >>> because release 'n' never *existed* in the first place, since it was never > >>> built. That has zero impact over auditing. Spec file auditing is done > >>> through CVS. > >> I believe he misspoke. You are of course free to make 300 small > >> separate specfile changes between each build attempt. > >> > >> There is a desire to move to a point where we can be reasonably sure > >> that a cvs tag corresponds to a specific build. Since we have no way > >> of making only tags corresponding to successfully built packages > >> immutable, all tags must be immutable. > >> Find me a way to mark only the subset of cvs tags which correspond to > >> a successful koji build as immutable. > > > > If this is the aim, then koji should be the one to tag the CVS after a > > build is successful. > > Question 1: Does this still fall under the all or nothing prevention of > moving tags? I don't know CVS well enough to know if there's a > fullblown hook that can be run to determine that "all tags prefixed with > koji-* are immutable". If so, that is a way to achieve this and was > proposed by Jesse several months ago. I like this proposal. > > It doesn't make sense to tag an unsuccessful build,a nd it is an > > unnecessary burden on developers. > > > Actually... tagging an unsuccessful build is useful. How else do you > take a look at what caused a particular build to fail? I think having > multiple immutable tags for the same NVR would be preferable. I didn't say adding tags should be prevented, but I find it unnecessary to force people to run make tag before make build, let koji tag a build if it is successful, and let people ad tags if they need, just not force people to tag when koji can do it with knowledge that that is a good build. and you might also decide to add tags for broken builds if you please by appending a broken build suffix (timestamp) so that you can keep using the same n-v-r until you get a successful build. Actually adding an automatic koji-- tag automatically when running 'make build' is not a bad idea, is it ? Simo. -- Simo Sorce * Red Hat, Inc * New York From kevin.kofler at chello.at Tue Sep 9 22:22:28 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 9 Sep 2008 22:22:28 +0000 (UTC) Subject: make force-tag gone References: <1220955240.24928.69.camel@cookie.hadess.net> <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> Message-ID: Nicolas Mailhot laposte.net> writes: > rawhide kernel is at release 317 right now. A large portion of those 317 > were mis-builds, oopsing kernels and other various fails (including > stupid typos). > > Anyone dares saying our kernel people are abysmal packagers? Do you want all packages to carry this hack? %define fedora_cvs_origin 623 %define fedora_build %(R="$Revision: 1.941 $"; R="${R%% \$}"; R="${R##: 1.}"; expr $R - %{fedora_cvs_origin}) ... %if 0%{?released_kernel} %define pkg_release %{fedora_build}%{?buildid}%{?dist} %else ... %define pkg_release 0.%{fedora_build}%{?rctag}%{?gittag}%{?buildid}%{?dist} %endif ... Release: %{pkg_release} Because that's what the kernel uses and why they don't need force-tag. And even that doesn't completely eliminate the need for force-tag, because the mistake could be somewhere other than the specfile, e.g. a patch you forgot to cvs add. Kevin Kofler From michael.wiktowy at gmail.com Tue Sep 9 22:28:42 2008 From: michael.wiktowy at gmail.com (Michael Wiktowy) Date: Tue, 9 Sep 2008 18:28:42 -0400 Subject: Dependency loops considered harmful? In-Reply-To: References: <20080903165835.GA31342@localhost> <20080903192416.0774097a.mschwendt@gmail.com> <48BECBDA.6090102@hhs.nl> Message-ID: <3e4ec4600809091528m6b007937t85b03150253999cf@mail.gmail.com> On Thu, Sep 4, 2008 at 7:16 AM, Matej Cepl wrote: > And I am afraid there will be no real resolution of this problem, > until yum will be able to do the same thing which aptitude on > Debian was able to do for years -- remembering which package was > installed because user wanted to do so, and which one was > installed only to satisfy dependencies. Another way of thinking of things would be: rather than keeping track of what package was installed as a dependency, have which packages are "libraries" labeled in the metadata of the actual package; "libraries" being specifically defined here as packages that provide something to one or more other packages but are not inherently useful by themselves. That could include game data, plugins or base libraries ... or even some helper apps. Rather than changing the rpm database or behaviour, this might be handed just by putting the package in a specific software group. This differentiates those leaf packages from other non-library leaf packages that don't depend on anything and also are not expected to provide anything to other packages but are inherently useful all by themselves. At that point, all the information is available for package managers like yum to make intelligent decisions based on user preferences about what to do with "library" packages that are installed with no other package installed that requires them. A developer who needs libraries around to create software or someone who just has a ton of hard-drive space and isn't really interested in culling unused libraries can set a preference in their package manager of choice that tells it not to get rid of packages that are labeled as "libraries" when they are unused. Just a different perspective to change the problem from "how a package was installed?" to "what kind of package is this?". /Mike From dennis at ausil.us Tue Sep 9 22:31:35 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 9 Sep 2008 17:31:35 -0500 Subject: make force-tag gone In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> <1220990257.7986.5.camel@rousalka.okg> Message-ID: <200809091731.41312.dennis@ausil.us> On Tuesday 09 September 2008 05:22:28 pm Kevin Kofler wrote: > Nicolas Mailhot laposte.net> writes: > > rawhide kernel is at release 317 right now. A large portion of those 317 > > were mis-builds, oopsing kernels and other various fails (including > > stupid typos). > > > > Anyone dares saying our kernel people are abysmal packagers? > > Do you want all packages to carry this hack? > %define fedora_cvs_origin 623 > %define fedora_build %(R="$Revision: 1.941 $"; R="${R%% \$}"; R="${R##: > 1.}"; expr $R - %{fedora_cvs_origin}) > ... > %if 0%{?released_kernel} > %define pkg_release %{fedora_build}%{?buildid}%{?dist} > %else > ... > %define pkg_release 0.%{fedora_build}%{?rctag}%{?gittag}%{?buildid}%{?dist} > %endif > ... > Release: %{pkg_release} > > Because that's what the kernel uses and why they don't need force-tag. And > even that doesn't completely eliminate the need for force-tag, because the > mistake could be somewhere other than the specfile, e.g. a patch you forgot > to cvs add. which is why I want make tag to check that all patches and sources are commited to cvs before doing the tag. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From a.badger at gmail.com Tue Sep 9 23:39:14 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 09 Sep 2008 16:39:14 -0700 Subject: make force-tag gone In-Reply-To: <48C6DC70.2070402@poolshark.org> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <604aa7910809090912h5a435625t6dde3238a9934bc@mail.gmail.com> <1220987283.15726.60.camel@localhost.localdomain> <48C6DB67.3060706@gmail.com> <48C6DC70.2070402@poolshark.org> Message-ID: <48C70922.7030106@gmail.com> Denis Leroy wrote: > Toshio Kuratomi wrote: >> Actually... tagging an unsuccessful build is useful. How else do you >> take a look at what caused a particular build to fail? > > cvs update -D 'koji build time' > > There's already a safeguard that won't let you build if the files are > not checked in. > timestamp is imprecise (skew between machines, checkin that happens between submitting a build job and processing, getting timezones wrong). It's one of the many reasons you don't build from timestamp always. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From a.badger at gmail.com Tue Sep 9 23:57:43 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 09 Sep 2008 16:57:43 -0700 Subject: make force-tag gone In-Reply-To: <1220998193.15726.76.camel@localhost.localdomain> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <604aa7910809090912h5a435625t6dde3238a9934bc@mail.gmail.com> <1220987283.15726.60.camel@localhost.localdomain> <48C6DB67.3060706@gmail.com> <1220998193.15726.76.camel@localhost.localdomain> Message-ID: <48C70D77.9080605@gmail.com> Simo Sorce wrote: > On Tue, 2008-09-09 at 13:24 -0700, Toshio Kuratomi wrote: >> Simo Sorce wrote: >>> On Tue, 2008-09-09 at 08:12 -0800, Jeff Spaleta wrote: >>>> On Tue, Sep 9, 2008 at 8:03 AM, Denis Leroy wrote: >>>>> There's no logic here. You're not forcing people to tag after every CVS >>>>> check-in, as far as I know. If a release 'n' fails to build (for example, >>>>> because you forgot to check-in a patch), it makes zero sense to bump to n+1, >>>>> because release 'n' never *existed* in the first place, since it was never >>>>> built. That has zero impact over auditing. Spec file auditing is done >>>>> through CVS. >>>> I believe he misspoke. You are of course free to make 300 small >>>> separate specfile changes between each build attempt. >>>> >>>> There is a desire to move to a point where we can be reasonably sure >>>> that a cvs tag corresponds to a specific build. Since we have no way >>>> of making only tags corresponding to successfully built packages >>>> immutable, all tags must be immutable. >>>> Find me a way to mark only the subset of cvs tags which correspond to >>>> a successful koji build as immutable. >>> If this is the aim, then koji should be the one to tag the CVS after a >>> build is successful. >> Question 1: Does this still fall under the all or nothing prevention of >> moving tags? I don't know CVS well enough to know if there's a >> fullblown hook that can be run to determine that "all tags prefixed with >> koji-* are immutable". If so, that is a way to achieve this and was >> proposed by Jesse several months ago. > > I like this proposal. > >>> It doesn't make sense to tag an unsuccessful build,a nd it is an >>> unnecessary burden on developers. >>> >> Actually... tagging an unsuccessful build is useful. How else do you >> take a look at what caused a particular build to fail? I think having >> multiple immutable tags for the same NVR would be preferable. > > I didn't say adding tags should be prevented, but I find it unnecessary > to force people to run make tag before make build, let koji tag a build > if it is successful, and let people ad tags if they need, just not force > people to tag when koji can do it with knowledge that that is a good > build. > and you might also decide to add tags for broken builds if you please by > appending a broken build suffix (timestamp) so that you can keep using > the same n-v-r until you get a successful build. > I've thought up a reason for having tags be done by the build submitter. Race conditions. Say koji is having a really busy day. I cvs commit. Then make build. The request goes to koji which allocates a job to handle the request. Even if the first part of the job is a simple prep that figures out the versions of files in cvs to work with, there's a chance that someone else will cvs commit before that koji job finishes. Even if you take care of that, there's still the chance of clock skew between the builder and cvs server. > Actually adding an automatic koji-- tag > automatically when running 'make build' is not a bad idea, is it ? > I like automatic. I'm wondering if we just get rid of the make tag step if we get rid of the need people see to move tags. For instance: make build => Creates a new unique, immutable tag like koji-username-package-nvr-timestamp and submits to koji koji processes the tag as normal and adds the information to its database. If failure packager cvs add's and cvs commits a missing patch file. make build => Creates a new unique tag with the same username, package, and nvr but a new timestamp. repeat as necessary * Note: The timestamp in the tag doesn't need coordination between machines in this scenario, it is only used to make the tag unique. * Note: I don't know if koji has some understanding of what the tag looks like although I don't see why it should. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From rrankin at ihug.com.au Wed Sep 10 00:02:45 2008 From: rrankin at ihug.com.au (rrankin at ihug.com.au) Date: Wed, 10 Sep 2008 08:02:45 +0800 Subject: Proposed removal of packages with long-standing FTBFS failures Message-ID: <61246.1221004965@ihug.com.au> An HTML attachment was scrubbed... URL: From jwboyer at gmail.com Wed Sep 10 01:21:30 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 9 Sep 2008 21:21:30 -0400 Subject: make force-tag gone In-Reply-To: <200809091731.41312.dennis@ausil.us> References: <1220955240.24928.69.camel@cookie.hadess.net> <1220990257.7986.5.camel@rousalka.okg> <200809091731.41312.dennis@ausil.us> Message-ID: <20080910012130.GA21620@yoda.jdub.homelinux.org> On Tue, Sep 09, 2008 at 05:31:35PM -0500, Dennis Gilmore wrote: >> Because that's what the kernel uses and why they don't need force-tag. And >> even that doesn't completely eliminate the need for force-tag, because the >> mistake could be somewhere other than the specfile, e.g. a patch you forgot >> to cvs add. > >which is why I want make tag to check that all patches and sources are >commited to cvs before doing the tag. That's pretty hard to enforce and it should be run by FESCo before being implemented because it impacts the work flow of our packagers. josh From dennis at ausil.us Wed Sep 10 01:53:03 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 9 Sep 2008 20:53:03 -0500 Subject: make force-tag gone In-Reply-To: <20080910012130.GA21620@yoda.jdub.homelinux.org> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809091731.41312.dennis@ausil.us> <20080910012130.GA21620@yoda.jdub.homelinux.org> Message-ID: <200809092053.14721.dennis@ausil.us> On Tuesday 09 September 2008 08:21:30 pm Josh Boyer wrote: > On Tue, Sep 09, 2008 at 05:31:35PM -0500, Dennis Gilmore wrote: > >> Because that's what the kernel uses and why they don't need force-tag. > >> And even that doesn't completely eliminate the need for force-tag, > >> because the mistake could be somewhere other than the specfile, e.g. a > >> patch you forgot to cvs add. > > > >which is why I want make tag to check that all patches and sources are > >commited to cvs before doing the tag. > > That's pretty hard to enforce and it should be run by FESCo before being > implemented because it impacts the work flow of our packagers. checking that the patches and sources referenced in the spec file are checked into cvs? it will not effect workflow other than making sure that everything is commited. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From ssorce at redhat.com Wed Sep 10 02:13:07 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 09 Sep 2008 22:13:07 -0400 Subject: make force-tag gone In-Reply-To: <48C70922.7030106@gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <604aa7910809090912h5a435625t6dde3238a9934bc@mail.gmail.com> <1220987283.15726.60.camel@localhost.localdomain> <48C6DB67.3060706@gmail.com> <48C6DC70.2070402@poolshark.org> <48C70922.7030106@gmail.com> Message-ID: <1221012787.15726.80.camel@localhost.localdomain> On Tue, 2008-09-09 at 16:39 -0700, Toshio Kuratomi wrote: > Denis Leroy wrote: > > Toshio Kuratomi wrote: > >> Actually... tagging an unsuccessful build is useful. How else do you > >> take a look at what caused a particular build to fail? > > > > cvs update -D 'koji build time' > > > > There's already a safeguard that won't let you build if the files are > > not checked in. > > > timestamp is imprecise (skew between machines, checkin that happens > between submitting a build job and processing, getting timezones wrong). > It's one of the many reasons you don't build from timestamp always. If koji is the one that determine the timestamp these shouldn't really be big problems, and the timestamped tag is useful just to connect the job that has been run with the exact version of CVS files used to run it. It's all koji controlled and matched by teh same timestamp being saved as part of the build metadata so unless you fear that 2 builds for the same package can start at the exact same moment I don't think it is going to be a big deal, is it ? Simo. -- Simo Sorce * Red Hat, Inc * New York From ssorce at redhat.com Wed Sep 10 02:18:05 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 09 Sep 2008 22:18:05 -0400 Subject: make force-tag gone In-Reply-To: <48C70D77.9080605@gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <604aa7910809090912h5a435625t6dde3238a9934bc@mail.gmail.com> <1220987283.15726.60.camel@localhost.localdomain> <48C6DB67.3060706@gmail.com> <1220998193.15726.76.camel@localhost.localdomain> <48C70D77.9080605@gmail.com> Message-ID: <1221013085.15726.86.camel@localhost.localdomain> On Tue, 2008-09-09 at 16:57 -0700, Toshio Kuratomi wrote: > Simo Sorce wrote: > > On Tue, 2008-09-09 at 13:24 -0700, Toshio Kuratomi wrote: > >> Simo Sorce wrote: > >>> On Tue, 2008-09-09 at 08:12 -0800, Jeff Spaleta wrote: > >>>> On Tue, Sep 9, 2008 at 8:03 AM, Denis Leroy wrote: > >>>>> There's no logic here. You're not forcing people to tag after every CVS > >>>>> check-in, as far as I know. If a release 'n' fails to build (for example, > >>>>> because you forgot to check-in a patch), it makes zero sense to bump to n+1, > >>>>> because release 'n' never *existed* in the first place, since it was never > >>>>> built. That has zero impact over auditing. Spec file auditing is done > >>>>> through CVS. > >>>> I believe he misspoke. You are of course free to make 300 small > >>>> separate specfile changes between each build attempt. > >>>> > >>>> There is a desire to move to a point where we can be reasonably sure > >>>> that a cvs tag corresponds to a specific build. Since we have no way > >>>> of making only tags corresponding to successfully built packages > >>>> immutable, all tags must be immutable. > >>>> Find me a way to mark only the subset of cvs tags which correspond to > >>>> a successful koji build as immutable. > >>> If this is the aim, then koji should be the one to tag the CVS after a > >>> build is successful. > >> Question 1: Does this still fall under the all or nothing prevention of > >> moving tags? I don't know CVS well enough to know if there's a > >> fullblown hook that can be run to determine that "all tags prefixed with > >> koji-* are immutable". If so, that is a way to achieve this and was > >> proposed by Jesse several months ago. > > > > I like this proposal. > > > >>> It doesn't make sense to tag an unsuccessful build,a nd it is an > >>> unnecessary burden on developers. > >>> > >> Actually... tagging an unsuccessful build is useful. How else do you > >> take a look at what caused a particular build to fail? I think having > >> multiple immutable tags for the same NVR would be preferable. > > > > I didn't say adding tags should be prevented, but I find it unnecessary > > to force people to run make tag before make build, let koji tag a build > > if it is successful, and let people ad tags if they need, just not force > > people to tag when koji can do it with knowledge that that is a good > > build. > > and you might also decide to add tags for broken builds if you please by > > appending a broken build suffix (timestamp) so that you can keep using > > the same n-v-r until you get a successful build. > > > I've thought up a reason for having tags be done by the build submitter. > Race conditions. Say koji is having a really busy day. I cvs > commit. Then make build. The request goes to koji which allocates a job > to handle the request. Even if the first part of the job is a simple > prep that figures out the versions of files in cvs to work with, there's > a chance that someone else will cvs commit before that koji job > finishes. Even if you take care of that, there's still the chance of > clock skew between the builder and cvs server. If koji does tag the build with the timestamp as the first thing then it doesn't really matter. It will re-tag the same with n-v-r once the build is successfully completed. > > Actually adding an automatic koji-- tag > > automatically when running 'make build' is not a bad idea, is it ? > > > I like automatic. I'm wondering if we just get rid of the make tag step > if we get rid of the need people see to move tags. I think so, I don't believe people should be able to change tags once a build successfully completed, and if some people need "non-build-tags" then all we need to do is probably just reserve a tag namespace for koji (the official one) and let user add other tags as they see fit, for their own need. > For instance: > > make build => Creates a new unique, immutable tag like > koji-username-package-nvr-timestamp and submits to koji > koji processes the tag as normal and adds the information to its database. > If failure > packager cvs add's and cvs commits a missing patch file. > make build => Creates a new unique tag with the same username, > package, and nvr but a new timestamp. > repeat as necessary Not sure we need the username and n-v-r here, but I am not too concerned about that, this in general sound like the process I had in mind. > * Note: The timestamp in the tag doesn't need coordination between > machines in this scenario, it is only used to make the tag unique. Exactly, that was my idea too. Simo. -- Simo Sorce * Red Hat, Inc * New York From jwboyer at gmail.com Wed Sep 10 02:55:02 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 9 Sep 2008 22:55:02 -0400 Subject: make force-tag gone In-Reply-To: <200809092053.14721.dennis@ausil.us> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809091731.41312.dennis@ausil.us> <20080910012130.GA21620@yoda.jdub.homelinux.org> <200809092053.14721.dennis@ausil.us> Message-ID: <20080910025502.GC21620@yoda.jdub.homelinux.org> On Tue, Sep 09, 2008 at 08:53:03PM -0500, Dennis Gilmore wrote: >On Tuesday 09 September 2008 08:21:30 pm Josh Boyer wrote: >> On Tue, Sep 09, 2008 at 05:31:35PM -0500, Dennis Gilmore wrote: >> >> Because that's what the kernel uses and why they don't need force-tag. >> >> And even that doesn't completely eliminate the need for force-tag, >> >> because the mistake could be somewhere other than the specfile, e.g. a >> >> patch you forgot to cvs add. >> > >> >which is why I want make tag to check that all patches and sources are >> >commited to cvs before doing the tag. >> >> That's pretty hard to enforce and it should be run by FESCo before being >> implemented because it impacts the work flow of our packagers. > >checking that the patches and sources referenced in the spec file are checked >into cvs? it will not effect workflow other than making sure that everything is >commited. How exactly do you plan on doing that? In my off-the-top-of-my-head guestimation, you'd have to: 1) Make sure .spec is committed and there are no local changes 2) Parse .spec file to determine PatchNN and SourceNN filenames. 3) Taking into account that we use a lookaside-cache, make sure that all patches and sources are in CVS and are not locally modified. 4) Do the tag. That seems pretty involved. I can't see another valid way to do it though. You don't want to just blindly say something like "if a file that ends in .patch isn't added to CVS, fail the tag" because not all patches end in .patch or .diff and it's still valid to have un-added and un-committed patches in a local CVS checkout while doing a tag if they aren't listed in the SPEC file. There could be even cases where it's valid to have a modified patch file that isn't committed while doing the tag. So yes, I think you need to outline your plan and how you're going to accomplish what you are trying and run it past FESCo before making the change. It may be that we just say "sure, sounds great." It may be that FESCo says "hm. We need to change XX or YY." Either way, it has impacts to packagers and it needs to be run past FESCo. josh From abartlet at samba.org Wed Sep 10 03:19:01 2008 From: abartlet at samba.org (Andrew Bartlett) Date: Wed, 10 Sep 2008 13:19:01 +1000 Subject: Help wanted with Samba4 and OpenChange In-Reply-To: <200807010855.38912.jbarnes@virtuousgeek.org> References: <1214877697.19140.28.camel@naomi.s4.naomi.abartlet.net> <200807010855.38912.jbarnes@virtuousgeek.org> Message-ID: <1221016741.18128.64.camel@naomi.s4.naomi.abartlet.net> On Tue, 2008-07-01 at 08:55 -0700, Jesse Barnes wrote: > On Monday, June 30, 2008 7:01 pm Andrew Bartlett wrote: > > I've recently been working on packaging Heimdal, Samba4 and OpenChange > > for Fedora. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=452212 (heimdal) > > https://bugzilla.redhat.com/show_bug.cgi?id=453083 (Samba4) > > https://bugzilla.redhat.com/show_bug.cgi?id=453395 (libmapi - > > OpenChange) > > > > This will enable much better access to Microsoft Exchange servers from > > clients such as kdepim, and hopefully Evolution (pending a > > re-licensing). > > > > I've got a feature page for this here: > > > > https://fedoraproject.org/wiki/Features/OpenChange > > > > Now, the reason I'm posting here is that I would rather not do this > > alone, and would love some co-maintainers of the packagers above, or at > > least some help with the review and sponsorship, or advise on the best > > way forward. > > > > Any assistance gratefully received, > > I've been really looking forward to this; how can I help? What's involved > with co-maintainership? At the very least I can help with testing and > such... I recently posted my intention to orphan this effort. Do you wish to take it over? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From vonbrand at inf.utfsm.cl Wed Sep 10 03:55:53 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Tue, 09 Sep 2008 23:55:53 -0400 Subject: rawhide report: 20080909 changes In-Reply-To: <200809092100.m89L0Pes008548@laptop14.inf.utfsm.cl> References: <20080909103814.D26201F8247@releng2.fedora.phx.redhat.com> <200809092100.m89L0Pes008548@laptop14.inf.utfsm.cl> Message-ID: <200809100355.m8A3tr81006200@laptop14.inf.utfsm.cl> Horst H. von Brand wrote: > > New package beep > > [etc, and lots of updates] > > yum doen't get any update today... even "yum clean metadata" doesn't get it > to grok new packages that _are_ there. And downloading > docbook-utils-0.6.14-14.fc10.noarch.rpm and trying "yum localinstall" on > that complains it isn't signed (but gpgcheck = 0 in the fedora-rawhide.repo > file) > > What gives? Pilot error. I looked at redhat.com, but the repo file references (stale) fedoraproject.org. Sorry for the noise. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From rc040203 at freenet.de Wed Sep 10 04:32:04 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 10 Sep 2008 06:32:04 +0200 Subject: Banned from Fedora Forums In-Reply-To: <1220987225.7707.7.camel@kennedy> References: <1220983505.17299.5.camel@hughsie-work> <48C6BE3E.3010603@redhat.com> <1220987225.7707.7.camel@kennedy> Message-ID: <1221021124.18327.72.camel@beck.corsepiu.local> On Tue, 2008-09-09 at 15:07 -0400, Brian Pepple wrote: > On Tue, 2008-09-09 at 14:19 -0400, Warren Togami wrote: > > This is especially problematic when Fedora Forum is our #1 preferred > > place to direct end-users to for end-user support. fedora-list is a > > dramatic pile of fail for this purpose. We also want to promote greater > > participation of fedora developers on Fedora Forum in order to better > > understand what are the common failures and to encourage users to follow > > the proper processes to isolate the causes and test solutions. > > Should Fedora Forum be our #1 preferred place? IMO, it should remain "yet another communication channel" amongst many others. Ralf From petersen at redhat.com Wed Sep 10 05:08:22 2008 From: petersen at redhat.com (Jens Petersen) Date: Wed, 10 Sep 2008 01:08:22 -0400 (EDT) Subject: [announcement] fedora-i18n-bugs list In-Reply-To: <28235935.1566781221021758342.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <1040880301.1567531221023302268.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> A new bugs mailing-list fedora-i18n-bugs has been setup to track Fedora i18n related bugs in bugzilla. It will also be used for autocc'ing (initialcc) of i18n related Fedora packages. https://www.redhat.com/mailman/listinfo/fedora-i18n-bugs The list will be fairly high traffic but give people a way to track i18n issues also in the archives or in bugzilla. Thanks, Jens From steven.moix at axianet.ch Wed Sep 10 06:03:58 2008 From: steven.moix at axianet.ch (Steven Moix) Date: Wed, 10 Sep 2008 08:03:58 +0200 Subject: Feature Proposal: Use cases database In-Reply-To: <1220991029.3782.47.camel@choeger6> References: <1220991029.3782.47.camel@choeger6> Message-ID: <1221026638.2783.6.camel@hp6710.axianet.ch> The idea is good, but I see it as "yet another layer of administration to maintain". Don't you think that websites like http://www.fedorafaq.org do most of the things you are asking for? Maybe we could simply improve the http://fedoraproject.org/en/get-help page to point to more resources (by that, I mean language specific forums for example) and create a list of the best applications for each use case? Steven On Tue, 2008-09-09 at 22:10 +0200, Christoph H?ger wrote: > Hi folks, > > in the past weeks I had an idea about how to improve the user support. > I'll sketch it: > > 1. A "normal" user, especially when new to Linux will probably start his > computer with a concrete idea what he wants to do ("surf the web", > "check my mail", "write a document" etc.). While there are tons of > information (some of them useful, some not), every peace of information > needs the user to at least surf to a given web page and search it for > what he needs (not talking about subscribing to a high traffic mailing > list). That is definitely too much work for our beginner. Especially, if > he wants to know "how to surf the web". > > 2. The main difference here between Linux and windows is where a > beginner can get support. Obviously the lesser spread of linux > distributions is a disadvantage. But the distribution itself is not only > the solution to this problem, but an even bigger advantage: Thousands of > users have access to the same software in the same version. And all of > them do those use cases. So we should bring the information about how to > do such a use case in our distribution to the user with the distribution > itself. > > 3. So how could we address that technically? Basically a wiki would be a > good starting point for some (when not all) of the basic use cases. From > there we could bring localized HowTos over a desktop applications to the > user (asking "what do you want to do today"). But that's not all: we > could also > * deliver a set of scripts to check if the desired > software is installed in the correct versions. > > * integrate that system with smolt to get information > about which hardware will probably work and which not > (this could avoid some frustration) > > * integrate some kind of "how could I use that > file?" functionality in our document centric desktop > > * lead to further support possibilties (mailing lists, forums) > and how to use them > > * allow a user to easily post a bug report when a use case > should work but doesn't > > * > > What do you think? > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From lesmikesell at gmail.com Wed Sep 10 06:23:35 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 10 Sep 2008 01:23:35 -0500 Subject: Feature Proposal: Use cases database In-Reply-To: <1221026638.2783.6.camel@hp6710.axianet.ch> References: <1220991029.3782.47.camel@choeger6> <1221026638.2783.6.camel@hp6710.axianet.ch> Message-ID: <48C767E7.9040801@gmail.com> Steven Moix wrote: > The idea is good, but I see it as "yet another layer of administration > to maintain". Don't you think that websites like > http://www.fedorafaq.org do most of the things you are asking for? > > Maybe we could simply improve the http://fedoraproject.org/en/get-help > page to point to more resources (by that, I mean language specific > forums for example) and create a list of the best applications for each > use case? Even better than talking about it would be creating the exact package lists that best enable a variety of use cases and a handy way of telling yum/packagekit to duplicate them on your machine. Then anyone else who needed to do the same thing would have a push-button choice. The idea should be that anyone could 'publish' their installed package set and describe why they think it is best for a particular use, and anyone who was convinced by their description/reputation, etc. could just clone that setup. -- Les Mikesell lesmikesell at gmail.com From jkeating at redhat.com Wed Sep 10 06:39:30 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 09 Sep 2008 23:39:30 -0700 Subject: FESCo Meeting Summary for 2008-08-13 In-Reply-To: <1218669241.5849.11.camel@kennedy> References: <1218669241.5849.11.camel@kennedy> Message-ID: <1221028770.3388.136.camel@luminos.localdomain> On Wed, 2008-08-13 at 19:14 -0400, Brian Pepple wrote: > * FESCo approved the following feature for F10: > * http://fedoraproject.org/wiki/Features/ApplianceTools I just noticed and read this a little closer... and looked a the meeting minutes which were... sparse. This feature involves Fedora actually producing and distributing something we've never done before, a tarred image for use in a virtual machine. That's not your typical "spin" which is an iso format to be consumed by booting it on hardware, real or fake. Was any thought or discussion at all put into the implications of this? Was releng consulted about our ability to produce/test this during development cycles, particularly Beta? Do we have any thought as to how this would be advertised to users, and any documentation about how to use it as well? Could FESCo maybe take another gander at this feature page and comment on some of the above issues? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed Sep 10 06:34:35 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 09 Sep 2008 23:34:35 -0700 Subject: Fedora 8 and 9 updates re-enabled Message-ID: <1221028475.3388.132.camel@luminos.localdomain> In a few hours, updates for Fedora 8 and Fedora 9 will start hitting mirrors. These updates are designed to transition users from our old repo locations to new locations that have all our updates re-signed with a new set of keys. Most users will simply need to apply the offered updates, and later apply any further updates, and verify/import the new GPG key. The process to getting new updates is two stage. Stage 1) Users configured to get updates from existing repos will see a small set of updates available in the next few hours/days. These updates include fedora-release, PackageKit, gnome-packagekit, and unique (for Fedora 8, only fedora-release is offered). These updates should be applied as soon as possible. Stage 2) Once the above updates have been applied, your update tools (yum, PackageKit, pirut) will see a new repository and a larger set of updates available. This is your new standard flow of updates, that will continue to see new updates as the lifetime of Fedora 8 and 9 progress. There will be further milestones in the future that involve redirection of release package repos to match that of updates, and removing of old gpg key from rpm trust. For more details and an FAQ, please see https://fedoraproject.org/w/index.php?title=Enabling_new_signing_key -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From rc040203 at freenet.de Wed Sep 10 07:08:53 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 10 Sep 2008 09:08:53 +0200 Subject: Fedora 8 and 9 updates re-enabled In-Reply-To: <1221028475.3388.132.camel@luminos.localdomain> References: <1221028475.3388.132.camel@luminos.localdomain> Message-ID: <1221030533.18327.76.camel@beck.corsepiu.local> On Tue, 2008-09-09 at 23:34 -0700, Jesse Keating wrote: > In a few hours, updates for Fedora 8 and Fedora 9 will start hitting > mirrors. These updates are designed to transition users from our old > repo locations to new locations that have all our updates re-signed with > a new set of keys. > > Most users will simply need to apply the offered updates, and later > apply any further updates, and verify/import the new GPG key. > > The process to getting new updates is two stage. How about mock setups? The current default mock-configs don't know anything about the "*.newkey" repos, nor do I see mock update-packages pending. Ralf From jonathan at jonmasters.org Wed Sep 10 07:08:38 2008 From: jonathan at jonmasters.org (Jon Masters) Date: Wed, 10 Sep 2008 03:08:38 -0400 Subject: make force-tag gone In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> Message-ID: <1221030518.20891.118.camel@jcmlaptop.bos.redhat.com> On Tue, 2008-09-09 at 10:10 -0500, Mike McGrath wrote: > So why would you make a change to the spec file, without bumping the > release? Because (with all due respect) it seems silly to bump the release just to deal with fat-fingering something. It happens countless times too. > Also there's an auditing GPL legal reason (IIRC) that we're > doing this now. Can someone confirm that this legal reason actually exists? i.e. if one builds packages that are never released, how is it then a problem to retag? And besides, CVS history is still coherent in either case. Jon. From nicu_fedora at nicubunu.ro Wed Sep 10 07:10:40 2008 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Wed, 10 Sep 2008 10:10:40 +0300 Subject: Banned from Fedora Forums In-Reply-To: <1220991291.48c6d93bcdfb0@ssl.mecca.ca> References: <1220983505.17299.5.camel@hughsie-work> <1220991291.48c6d93bcdfb0@ssl.mecca.ca> Message-ID: <48C772F0.8070309@nicubunu.ro> Luya Tshimbalanga wrote: > > I am one of developer from Fedora Artwork who has been recently promoted as > Community Manager mostly for adding Fedora Weekly News. Well Luya, as you are both a Community Manager on the forum and a member of the Art Team, I leave to you the communication about our (Art) team there. Last time when I wanted to involve those guys in our theming process (asking for feed-back for F10 Round 1) the reception was rude so I decided to not bother. -- 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 dennis at ausil.us Wed Sep 10 07:12:49 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 10 Sep 2008 02:12:49 -0500 Subject: FESCo Meeting Summary for 2008-08-13 In-Reply-To: <1221028770.3388.136.camel@luminos.localdomain> References: <1218669241.5849.11.camel@kennedy> <1221028770.3388.136.camel@luminos.localdomain> Message-ID: <200809100213.01371.dennis@ausil.us> On Wednesday 10 September 2008 01:39:30 am Jesse Keating wrote: > On Wed, 2008-08-13 at 19:14 -0400, Brian Pepple wrote: > > * FESCo approved the following feature for F10: > > * http://fedoraproject.org/wiki/Features/ApplianceTools > > I just noticed and read this a little closer... and looked a the meeting > minutes which were... sparse. > > This feature involves Fedora actually producing and distributing > something we've never done before, a tarred image for use in a virtual > machine. That's not your typical "spin" which is an iso format to be > consumed by booting it on hardware, real or fake. Was any thought or > discussion at all put into the implications of this? Was releng > consulted about our ability to produce/test this during development > cycles, particularly Beta? Do we have any thought as to how this would > be advertised to users, and any documentation about how to use it as > well? > > Could FESCo maybe take another gander at this feature page and comment > on some of the above issues? I messed up here I missed "Requires hosting a binary image on http://spins.fedoraproject.org/" from what I remembered it was providing tools to create appliances. not us actually providing appliance images. since appliances are specialised configured things its really hard to provide a single appliance. I personally have no issue with hosting appliance kickstart files. but i think we need to review hosting a binary appliance image Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From wtogami at redhat.com Wed Sep 10 07:22:14 2008 From: wtogami at redhat.com (Warren Togami) Date: Wed, 10 Sep 2008 03:22:14 -0400 Subject: Fedora 8 and 9 updates re-enabled In-Reply-To: <1221030533.18327.76.camel@beck.corsepiu.local> References: <1221028475.3388.132.camel@luminos.localdomain> <1221030533.18327.76.camel@beck.corsepiu.local> Message-ID: <48C775A6.3070406@redhat.com> Ralf Corsepius wrote: > On Tue, 2008-09-09 at 23:34 -0700, Jesse Keating wrote: >> In a few hours, updates for Fedora 8 and Fedora 9 will start hitting >> mirrors. These updates are designed to transition users from our old >> repo locations to new locations that have all our updates re-signed with >> a new set of keys. >> >> Most users will simply need to apply the offered updates, and later >> apply any further updates, and verify/import the new GPG key. >> >> The process to getting new updates is two stage. > How about mock setups? > > The current default mock-configs don't know anything about the > "*.newkey" repos, nor do I see mock update-packages pending. > > Ralf > > Yeah, LiveCD kickstart files, and ltsp-client chroot kickstart files need updating as well. Warren From email.ahmedkamal at googlemail.com Wed Sep 10 07:32:04 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Wed, 10 Sep 2008 09:32:04 +0200 Subject: Fedora 8 and 9 updates re-enabled In-Reply-To: <48C775A6.3070406@redhat.com> References: <1221028475.3388.132.camel@luminos.localdomain> <1221030533.18327.76.camel@beck.corsepiu.local> <48C775A6.3070406@redhat.com> Message-ID: <3da3b5b40809100032x262fb465ja81bf694903aa27@mail.gmail.com> Um, just did the update now and I got: Updating : fedora-release [ 1/10] warning: /etc/yum.repos.d/fedora-updates.repo created as /etc/yum.repos.d/fedora-updates.repo.rpmnew warning: /etc/yum.repos.d/fedora.repo created as /etc/yum.repos.d/fedora.repo.rpmnew That's probably because I once edited those files. I suppose I need to copy over the .rpmnew ones onto the original ones. Would it not have made more sense in this case to overwrite the repos anyway On Wed, Sep 10, 2008 at 9:22 AM, Warren Togami wrote: > Ralf Corsepius wrote: > >> On Tue, 2008-09-09 at 23:34 -0700, Jesse Keating wrote: >> >>> In a few hours, updates for Fedora 8 and Fedora 9 will start hitting >>> mirrors. These updates are designed to transition users from our old >>> repo locations to new locations that have all our updates re-signed with >>> a new set of keys. >>> Most users will simply need to apply the offered updates, and later >>> apply any further updates, and verify/import the new GPG key. >>> >>> The process to getting new updates is two stage. >>> >> How about mock setups? >> >> The current default mock-configs don't know anything about the >> "*.newkey" repos, nor do I see mock update-packages pending. >> >> Ralf >> >> >> > Yeah, LiveCD kickstart files, and ltsp-client chroot kickstart files need > updating as well. > > Warren > > > -- > 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 email.ahmedkamal at googlemail.com Wed Sep 10 07:43:35 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Wed, 10 Sep 2008 09:43:35 +0200 Subject: Fedora 8 and 9 updates re-enabled In-Reply-To: <3da3b5b40809100032x262fb465ja81bf694903aa27@mail.gmail.com> References: <1221028475.3388.132.camel@luminos.localdomain> <1221030533.18327.76.camel@beck.corsepiu.local> <48C775A6.3070406@redhat.com> <3da3b5b40809100032x262fb465ja81bf694903aa27@mail.gmail.com> Message-ID: <3da3b5b40809100043u56f59a1br8e67e0d1c4eddef1@mail.gmail.com> oh and after copying over the .rpmnew files, I get: Error: Missing Dependency: yum >= 3.2.19 is needed by package yum-utils-1.1.16-1.fc9.noarch (updates-newkey) On Wed, Sep 10, 2008 at 9:32 AM, Ahmed Kamal < email.ahmedkamal at googlemail.com> wrote: > Um, just did the update now and I got: > > Updating : fedora-release [ > 1/10] > > warning: /etc/yum.repos.d/fedora-updates.repo created as > /etc/yum.repos.d/fedora-updates.repo.rpmnew > > warning: /etc/yum.repos.d/fedora.repo created as > /etc/yum.repos.d/fedora.repo.rpmnew > > > > That's probably because I once edited those files. I suppose I need to copy > over the .rpmnew ones onto the original ones. Would it not have made more > sense in this case to overwrite the repos anyway > > > On Wed, Sep 10, 2008 at 9:22 AM, Warren Togami wrote: > >> Ralf Corsepius wrote: >> >>> On Tue, 2008-09-09 at 23:34 -0700, Jesse Keating wrote: >>> >>>> In a few hours, updates for Fedora 8 and Fedora 9 will start hitting >>>> mirrors. These updates are designed to transition users from our old >>>> repo locations to new locations that have all our updates re-signed with >>>> a new set of keys. >>>> Most users will simply need to apply the offered updates, and later >>>> apply any further updates, and verify/import the new GPG key. >>>> >>>> The process to getting new updates is two stage. >>>> >>> How about mock setups? >>> >>> The current default mock-configs don't know anything about the >>> "*.newkey" repos, nor do I see mock update-packages pending. >>> >>> Ralf >>> >>> >>> >> Yeah, LiveCD kickstart files, and ltsp-client chroot kickstart files need >> updating as well. >> >> Warren >> >> >> -- >> 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 sander at vermin.nl Wed Sep 10 07:52:44 2008 From: sander at vermin.nl (Sander Vermin) Date: Wed, 10 Sep 2008 09:52:44 +0200 Subject: Fedora 8 and 9 updates re-enabled In-Reply-To: <3da3b5b40809100043u56f59a1br8e67e0d1c4eddef1@mail.gmail.com> References: <1221028475.3388.132.camel@luminos.localdomain> <1221030533.18327.76.camel@beck.corsepiu.local> <48C775A6.3070406@redhat.com> <3da3b5b40809100032x262fb465ja81bf694903aa27@mail.gmail.com> <3da3b5b40809100043u56f59a1br8e67e0d1c4eddef1@mail.gmail.com> Message-ID: <48C77CCC.4050604@vermin.nl> Ahmed Kamal schreef: > oh and after copying over the .rpmnew files, I get: > Error: Missing Dependency: yum >= 3.2.19 is needed by package > yum-utils-1.1.16-1.fc9.noarch (updates-newkey) > > > On Wed, Sep 10, 2008 at 9:32 AM, Ahmed Kamal > > wrote: > > Um, just did the update now and I got: > > Updating : fedora-release > [ > 1/10] > > warning: /etc/yum.repos.d/fedora-updates.repo created as > /etc/yum.repos.d/fedora-updates.repo.rpmnew > > warning: /etc/yum.repos.d/fedora.repo created as > /etc/yum.repos.d/fedora.repo.rpmnew > > > > That's probably because I once edited those files. I suppose I > need to copy over the .rpmnew ones onto the original ones. Would > it not have made more sense in this case to overwrite the repos > anyway > > > On Wed, Sep 10, 2008 at 9:22 AM, Warren Togami > wrote: > > Ralf Corsepius wrote: > > On Tue, 2008-09-09 at 23:34 -0700, Jesse Keating wrote: > > In a few hours, updates for Fedora 8 and Fedora 9 will > start hitting > mirrors. These updates are designed to transition > users from our old > repo locations to new locations that have all our > updates re-signed with > a new set of keys. > Most users will simply need to apply the offered > updates, and later > apply any further updates, and verify/import the new > GPG key. > > The process to getting new updates is two stage. > > How about mock setups? > > The current default mock-configs don't know anything about the > "*.newkey" repos, nor do I see mock update-packages pending. > > Ralf > > > > Yeah, LiveCD kickstart files, and ltsp-client chroot kickstart > files need updating as well. > > Warren > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > Same here Regards, Sander From j.w.r.degoede at hhs.nl Wed Sep 10 08:08:22 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 10 Sep 2008 10:08:22 +0200 Subject: Lonely packages looking for cosy new owner In-Reply-To: <8949.198.175.55.5.1220961245.squirrel@mail.jcomserv.net> References: <48C5190F.7020500@hhs.nl> <24776.198.175.55.5.1220879480.squirrel@mail.jcomserv.net> <27257.198.175.55.5.1220879644.squirrel@mail.jcomserv.net> <48C60E18.2090407@hhs.nl> <8949.198.175.55.5.1220961245.squirrel@mail.jcomserv.net> Message-ID: <48C78076.6000608@hhs.nl> Jon Ciesla wrote: >> Jon Ciesla wrote: >>>>> If you are willing to take over any let me know and I'll orphan them >>>>> and >>>>> you can pick them up. I'll be around for a long time to come to answer >>>>> any questions and help with any issues with them, so don't hesitate! >>>> I'd be happy to take liquidwar, pinball, pipenightdreams, supertuxkart, >>>> and xgalaxy. Possibly others later, but these for now. >>> And, logically, tuxkart. >>> >> Thanks! >> >> I've released them all, yup can leave tuxkart orphaned though, its dead >> (superceeded by supertuxkart), pkgdb seems to not care about >> dead.package files in CVS, > > Thanks, picked up everything but supertuxkart, which you still need to > orphan. > Hmm, I'm pretty sure I did orphan supertuxkart already, but pkgdb seems to be biuggy sometimes, released again. Thanks & Regards, Hans From choeger at cs.tu-berlin.de Wed Sep 10 08:36:48 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 10 Sep 2008 10:36:48 +0200 Subject: Feature Proposal: Use cases database In-Reply-To: <1221026638.2783.6.camel@hp6710.axianet.ch> References: <1220991029.3782.47.camel@choeger6> <1221026638.2783.6.camel@hp6710.axianet.ch> Message-ID: <1221035808.3202.3.camel@choeger6> Am Mittwoch, den 10.09.2008, 08:03 +0200 schrieb Steven Moix: > The idea is good, but I see it as "yet another layer of administration > to maintain". Don't you think that websites like > http://www.fedorafaq.org do most of the things you are asking for? I had fedorafaq in mind, because it helped me a lot when I was new to fedora. But at that point I already knew all the basic things (Software Installation, Browsing the web, etc.). If you are _really_ new you need those infos offline. > > Maybe we could simply improve the http://fedoraproject.org/en/get-help > page to point to more resources (by that, I mean language specific > forums for example) and create a list of the best applications for each > use case? > > Steven I think we could need a lot more then that: We could have screenshots of how to use that software, general How Tos, etc. But yes, to have a "best" (aka default) application would be a good point. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From luya at fedoraproject.org Wed Sep 10 09:24:02 2008 From: luya at fedoraproject.org (Luya Tshimbalanga) Date: Wed, 10 Sep 2008 02:24:02 -0700 Subject: Banned from Fedora Forums In-Reply-To: <48C772F0.8070309@nicubunu.ro> References: <1220983505.17299.5.camel@hughsie-work> <1220991291.48c6d93bcdfb0@ssl.mecca.ca> <48C772F0.8070309@nicubunu.ro> Message-ID: <48C79232.2090308@fedoraproject.org> Nicu Buculei a ?crit : > > Well Luya, as you are both a Community Manager on the forum and a > member of the Art Team, I leave to you the communication about our > (Art) team there. > Last time when I wanted to involve those guys in our theming process > (asking for feed-back for F10 Round 1) the reception was rude so I > decided to not bother. > Which is unfortunate given the plethora of gallery in Fedora Forum. Perhaps the way to communicate is the key. I take the task to bridge that gap representing Art Team, hopefully you will keep track around as there are potential contributors. Luya -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From berrange at redhat.com Wed Sep 10 09:29:42 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 10 Sep 2008 10:29:42 +0100 Subject: Banned from Fedora Forums In-Reply-To: <1220983505.17299.5.camel@hughsie-work> References: <1220983505.17299.5.camel@hughsie-work> Message-ID: <20080910092942.GC2662@redhat.com> On Tue, Sep 09, 2008 at 07:05:05PM +0100, Richard Hughes wrote: > I've just been banned from the Fedora Forums [1]. > > I've been asking users with PackageKit bugs to report them upstream on > the mailing list or in bugzilla, explaining what common error messages > mean, and how to fix other problems. > This, it turns out isn't what the forums are for. I guess it???s just for > uniformed users telling less informed users how to "fix" things. My > mistake. > > I won't be even reading the forums anymore, and consider the couple of > hours I spent on the forums answering questions and educating users > about PackageKit wasted. > These are all the posts I???ve made on the forum if you want to check any > of my messages: > http://forums.fedoraforum.org/search.php?searchid=7137995 > > A few of them are pretty blunt, but the personal critique of my skills > as a programmer [2] and PackageKit is pretty blunt too (especially by a > "Community Manager"). > > Advice to developers: Don't bother. Reluctantly I have to agree with you - and this isn't really a Fedora specific problem. I can to same conclusion with the Xen users mailing list which I used to participate in to help users. There were just too many users who spent all their time insulting the developers & their work rather than engaging in productive conservations about trouble shooting. Its just not worth the pain at the end of the day :-( I don't have enough time as it is, so I just concentrate on user bug reports instead, of which there are plenty to keep me busy indefinitely... That said it is still useful to read / browse the forums / lists every now & then to get a good idea of the kind of problems most commonly hit by users which are not neccessarily bugs, but rather design / conceptual flaws. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From ml at deadbabylon.de Wed Sep 10 09:28:22 2008 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 10 Sep 2008 11:28:22 +0200 Subject: KDE-SIG weekly report (36/2008) Message-ID: <48C79336.1040404@deadbabylon.de> This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. ---------------------------------------------------------------------------------- = Weekly KDE Summary = Week: 36/2008 Time: 2008-09-09 16:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-09-09 Meeting log: https://fedoraproject.org/w/uploads/b/bb/KDE-SIG-2008-09-09.txt ---------------------------------------------------------------------------------- = Participants = * KevinKofler * RexDieter * SebastianVahl * StevenParrish * ThanNgo ---------------------------------------------------------------------------------- = Agenda = * FUDCon Brno report [1] * KDE-4.1.1 status * Fedora 10 Beta * Echo Icon Theme will be default in F10, what will we use in KDE? [2][3] * Fedora User Guide for F10 [4][5][6][7] = Summary = FUDCon Brno report ------------------ * KevinKofler reported from the FUDCON in Brno. * The KDE-SIG was represented by KevinKofler, LukasTinkl and JaroslavReznik. * They held a presentation about the "pillars of KDE 4" with small examples of how to use them as a developer and gave an overview of the goals with KDE4 in Fedora. [8] KDE-4.1.1 status ---------------- * KDE 4.1.1 is already built for F9 and queued for updates-testing. [9] * Also the KDE4-parts in Fedora 8 are queued for updates-testing. [10] * KDE 4.1.1 will stay in testing for one week and then go stable. Fedora 10 Beta -------------- * Fedora 10 Beta will still use nm-applet for controlling NetworkManager. * The NetworkManager plasmoid isn't ready yet (it was scheduled for August). * Alternatives would be the KDE3 based [11] and KDE4 based [12] knetworkmanager (but the latter didn't get many development in the past). * SebastianVahl reported about the current state of the live images: o The Beta will likely come with this package list [13] and this kickstart [14]. o Main differences to the Alpha are: only @fonts (and so no additional fonts), without amarok (space issues) o kdelibs3 will still be on the live images (required by k3b, konversation, kftpgrabber, filelight, ksshaskpass) Echo Icon Theme will be default in F10, what will we use in KDE? ---------------------------------------------------------------- * RexDieter tested Echo as first fallback in Fedora-KDE (before Oxygen) and reported it was working well for KDE4 apps. * KDE3 apps still have to rely on CrystalSVG. * kde-settings will be prepared to use Echo in Rawhide for testing. Fedora User Guide for F10 ------------------------- * The "current" user guide for the KDE Desktop is still based on Fedora 8. [4] * We'll need some volunteers to update it for Fedora 10 (KDE 4.1) and also Fedora 9 (KDE 4.0). Additional notes ---------------- * KDE 3.5.10 is queued for updates-testing in Fedora 8 (whole desktop) [15] and Fedora 9 (only KDE3 parts) [16]. * The review [17] of kde-plasma-lancelot [18] will be finished today. ---------------------------------------------------------------------------------- = Next Meeting = https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-09-16 ---------------------------------------------------------------------------------- = Links = [1] https://fedoraproject.org/wiki/FUDCon/FUDConBrno2008 [2] https://www.redhat.com/archives/fedora-desktop-list/2008-September/msg00002.html [3] https://www.redhat.com/archives/fedora-desktop-list/2008-September/msg00005.html [4] https://www.redhat.com/archives/fedora-docs-list/2008-September/msg00019.html [5] https://fedoraproject.org/wiki/User_Guide#Tour_of_the_KDE_Desktop [6] https://fedoraproject.org/wiki/User_Guide_tasks [7] https://fedoraproject.org/wiki/User_Guide-Tour_of_the_KDE_Desktop [8] https://fedoraproject.org/wiki/JaroslavReznik/Presentations/FUDCon2008Brno [9] https://admin.fedoraproject.org/updates/kdeaccessibility-4.1.1-1.fc9,kdeadmin-4.1.1-1.fc9,kdeartwork-4.1.1-1.fc9,kdebase-4.1.1-1.fc9,kdebase-runtime-4.1.1-2.fc9,kdebase-workspace-4.1.1-1.fc9,kdebindings-4.1.1-1.fc9,kdeedu-4.1.1-1.fc9,kdegames-4.1.1-1.fc9,kdegraphics-4.1.1-1.fc9,kdelibs-4.1.1-5.fc9,kdemultimedia-4.1.1-1.fc9,kdenetwork-4.1.1-1.fc9,kdepimlibs-4.1.1-2.fc9,kdeplasma-addons-4.1.1-1.fc9,kdesdk-4.1.1-1.fc9,kdetoys-4.1.1-1.fc9,kdeutils-4.1.1-1.fc9,guidance-power-manager-4.1.1-1.fc9,kiconedit-4.1.1-1.fc9,konq-plugins-4.1.1-1.fc9,kcoloredit-4.1.1-1.fc9,kde-l10n-4.1.1-1.fc9 [10] https://admin.fedoraproject.org/updates/kdebase4-4.1.1-1.fc8,kdelibs4-4.1.1-5.fc8,kdepimlibs-4.1.1-2.fc8,kdebase-runtime-4.1.1-2.fc8 [11] http://websvn.kde.org/branches/work/knetworkmanager/knetworkmanager-0.7/ [12] http://websvn.kde.org/trunk/playground/utils/knetworkmanager4/ [13] http://www.deadbabylon.de/fedora/livecd/packagelists/f10/long-F10-KDE4-040-i686.txt [14] http://www.deadbabylon.de/fedora/livecd/kickstarts/f10/F10-KDE4-040.ks [15] https://admin.fedoraproject.org/updates/kdeaddons-3.5.10-1.fc9,arts-1.5.10-1.fc9,kdelibs3-3.5.10-1.fc9,kdebase3-3.5.10-1.fc9,kde-i18n-3.5.10-1.fc9,kdepim-3.5.10-1.fc9,kdewebdev-3.5.10-1.fc9,kdevelop-3.5.3-1.fc9,kdegames3-3.5.10-1.fc9 [16] https://admin.fedoraproject.org/updates/kdeaddons-3.5.10-1.fc9,arts-1.5.10-1.fc9,kdelibs3-3.5.10-1.fc9,kdebase3-3.5.10-1.fc9,kde-i18n-3.5.10-1.fc9,kdepim-3.5.10-1.fc9,kdewebdev-3.5.10-1.fc9,kdevelop-3.5.3-1.fc9,kdegames3-3.5.10-1.fc9 [17] https://bugzilla.redhat.com/show_bug.cgi?id=461011 [18] http://www.kde-apps.org/content/show.php/Lancelot?content=87914 ---------------------------------------------------------------------------------- A small authors note: My time in the past was too limited to write these summary mails for the KDE-SIG-Meetings. But I'll hope I'll find the time again to do this on a weekly basis. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From mike.cloaked at gmail.com Wed Sep 10 09:52:14 2008 From: mike.cloaked at gmail.com (Mike) Date: Wed, 10 Sep 2008 09:52:14 +0000 (UTC) Subject: Fedora 8 and 9 updates re-enabled References: <1221028475.3388.132.camel@luminos.localdomain> <1221030533.18327.76.camel@beck.corsepiu.local> <48C775A6.3070406@redhat.com> <3da3b5b40809100032x262fb465ja81bf694903aa27@mail.gmail.com> <3da3b5b40809100043u56f59a1br8e67e0d1c4eddef1@mail.gmail.com> Message-ID: Ahmed Kamal googlemail.com> writes: > > oh and after copying over the .rpmnew files, I get:Error: Missing Dependency: yum >= 3.2.19 is needed by package yum-utils-1.1.16-1.fc9.noarch (updates-newkey) On Wed, Sep 10, 2008 at 9:32 AM, Ahmed Kamal googlemail.com> wrote: No problem - you can do the following in a terminal: yum update --exclude yum --exclude yum-utils then it will update everything except those two - later you can update again when the dependencies are corrected. /etc/yum.repos.d/fedora.repo.rpmnew It does not matter at that point since yum will use the file fedora-updates-newkey.repo and not the old file anyway - HTH From martin.langhoff at gmail.com Wed Sep 10 09:42:55 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 10 Sep 2008 21:42:55 +1200 Subject: Creating a spin - any mechanisms around $product-release, $product-release-notes, $product-logos packages...? Message-ID: <46a038f90809100242o4e65059enbc0f71d65412032e@mail.gmail.com> I'm finishing off the F9 port of the OLPC School Server, and as part of that I'm preparing xs-release, xs-release-notes and xs-logos packages. As far as I can see, these are pulled because they provide system-release and system-logos. fedora-release-notes is pulled in by fedora-release, and perhaps by something depending on indexhtml (httpd?). My key question is: will anything in the Fedora machinery (anaconda, rpm, yum) be looking for a magic "product" name, and then try to use it to request $product-release? (I ask to be safe - recently got very confused by anaconda not upgrading Fedora-based spins due to mismatching 'product' between .discinfo and /etc/redhat-release . Knowing these special rules is important ;-) and I have not found yet any document laying out the subtle traps awaiting anyone doing a Fedora derivative as I am doing...) cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From berrange at redhat.com Wed Sep 10 10:39:42 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 10 Sep 2008 11:39:42 +0100 Subject: make force-tag gone In-Reply-To: <1220978806.11620.6.camel@luminos.localdomain> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <1220978806.11620.6.camel@luminos.localdomain> Message-ID: <20080910103942.GG2662@redhat.com> On Tue, Sep 09, 2008 at 09:46:46AM -0700, Jesse Keating wrote: > On Tue, 2008-09-09 at 18:03 +0200, Denis Leroy wrote: > > > > There's no logic here. You're not forcing people to tag after every CVS > > check-in, as far as I know. If a release 'n' fails to build (for > > example, because you forgot to check-in a patch), it makes zero sense to > > bump to n+1, because release 'n' never *existed* in the first place, > > since it was never built. That has zero impact over auditing. Spec file > > auditing is done through CVS. > > The audit part is something of a red herring. The GPL compliance part > is what is bothersome. If we want to save archive space by relying on > re-generating srpms of shipped binaries on demand, we need to ensure > that CVS tags don't change over time. For better or worse, we build > from CVS tags, so to get the source that matched the build, we have to > checkout via CVS tags. If those tags can change over time, the trust > level is gone. That's why there is a push to make the tags immutable, > or at least the successfully built tags immutable. > > Personally I just want to move off of CVS and off of building from tags, > and instead build from something inherently immutable, like the shasum > of the repo at a given time. > > MikeB said that he'd look into some CVS/make changes that would allow > checking koji for an on going or successful build of a tag/n-v-r before > allowing a force-tag. This would allow folks to force-tag before having > a successful build, but would not allow you to force the tag after a > successful build, or while a build is still going with that n-v-r. > > I think this approach, while it may slow down force-tags and prevent > force-tags during any koji outage, will give us the best of both worlds. I think this would be a very good approach. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From berrange at redhat.com Wed Sep 10 10:41:38 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 10 Sep 2008 11:41:38 +0100 Subject: make force-tag gone In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> Message-ID: <20080910104137.GH2662@redhat.com> On Tue, Sep 09, 2008 at 05:39:48PM +0000, Kevin Kofler wrote: > Jeffrey Ollie ocjtech.us> writes: > > Refusing to bump a release number and re-tag because you don't want to > > "look stupid" is not a technical argument. > > Maybe, but it's a practical argument. > > > And before you ask, yes I've used force-tag before even though I know > > I shouldn't. Removing it will help me be a better package manager. > > No, it will make you a worse packager, as your Release tags will get > incremented for no reason. It is far far worse than this. If you made a mistake doing an update for Fedora 8, and have to bump the Release tag, its quite possible F8 will end up with newer N-E-V-R, than your F9 & rawhide builds breaking the upgrade path. So, now you have to re-build F9 and rawhide with pointless Release tag bumps too :-( Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From rawhide at fedoraproject.org Wed Sep 10 11:07:18 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Wed, 10 Sep 2008 11:07:18 +0000 (UTC) Subject: rawhide report: 20080910 changes Message-ID: <20080910110718.90E421F824C@releng2.fedora.phx.redhat.com> New package hunspell-gu Gujarati hunspell dictionaries New package netbeans Integrated Development Environment (IDE) New package perl-Catalyst-Model-DBIC-Schema DBIx::Class::Schema Model Class New package sysklogd System logging and kernel message trapping daemons New package tennix A simple tennis game Removed package d4x Removed package gchempaint Removed package perl-Class-Gomor Removed package perl-DBIx-SQLite-Simple Removed package perl-Net-Packet Removed package perl-Net-Packet-Target Removed package perl-Net-Write Removed package pgadmin3 Removed package rman Updated Packages: anaconda-11.4.1.33-1 -------------------- * Tue Sep 9 18:00:00 2008 Chris Lumens - 11.4.1.33-1 - Include NetworkManager and dbus libraries on 64-bit arches (#461632). (clumens) - We need libsqlite3.so in upd-instroot before it can be in the initrd. (clumens) - Fix partitions growing (backport of rhbz #442628) (rvykydal) - Kickstart timezone validity check fixed (#461526) (rvykydal) - Add more kernel crypto modules (#443545). (clumens) - Make the progress bar move when downloading the install.img (#461182). (clumens) - Add overrideDHCPhostname as an attribute. (clumens) - Fix saving to remote hosts (#461500). (clumens) - short_desc is now summary. (clumens) - Use print() as a function. (pjones) anyremote-4.8.1-1.fc10 ---------------------- * Tue Sep 9 18:00:00 2008 Mikhail Fedotov - 4.8.1-1 - Small corrections. * Thu Sep 4 18:00:00 2008 Mikhail Fedotov - 4.8-1 - Added configuration file for gThumb. Added GuiDescription field to configuration files. aqbanking-3.7.2-1.fc10 ---------------------- * Tue Sep 9 18:00:00 2008 Bill Nottingham - 3.7.2-1 - update to 3.7.2 - obsolete the no-longer-existing g2banking/kbanking packages bigboard-0.6.2-2.fc10 --------------------- * Mon Sep 8 18:00:00 2008 Owen Taylor - 0.6.2-1 - Update to 0.6.2 (fixes a crash) cheese-2.23.92-3.fc10 --------------------- * Tue Sep 9 18:00:00 2008 Matthias Clasen 2.23.92-3 - Update to 2.23.92 - Drop upstreamed patches clustermon-0.15.0-1.fc10 ------------------------ * Tue Sep 9 18:00:00 2008 Ryan McCabe 0.15.0-1 - Restore missing XVM.cpp file for modcluster coda-6.9.4-0.2.rc2.fc10 ----------------------- * Tue Sep 9 18:00:00 2008 Neil Horman 6.9.4-0.2.rc2 - Enabling krb5 support (bz 461041) conman-0.2.2-1.fc10 ------------------- * Mon Sep 8 18:00:00 2008 Steven M. Parrish 0.2.2-1 - New upstream release dxpc-3.9.1-1 ------------ * Tue Sep 9 18:00:00 2008 John Guthrie - 3.9.1-1 - Upgraded source code to 3.9.1-1 empathy-2.23.92-1.fc10 ---------------------- * Tue Sep 9 18:00:00 2008 Matthias Clasen - 2.23.92-1 - Update to 2.23.92 evince-2.23.92-1.fc10 --------------------- * Tue Sep 9 18:00:00 2008 Matthias Clasen - 2.23.92-1 - Update to 2.23.92 fslint-2.28-1.fc10 ------------------ * Tue Sep 9 18:00:00 2008 P??draig Brady

- 2.28-1 - Update to 2.28 gdm-2.23.92-2.fc10 ------------------ * Tue Sep 9 18:00:00 2008 Jon McCann - 1:2.23.92-2 - Disallow root login genromfs-0.5.2-1 ---------------- * Tue Sep 9 18:00:00 2008 Zdenek Prikryl - 0.5.2-1 - update to 0.5.2 - update of a patch for Makefile gnome-applets-2.23.92-1.fc10 ---------------------------- * Tue Sep 9 18:00:00 2008 Matthias Clasen - 1:2.23.92-1 - Update to 2.23.92 gnome-chemistry-utils-0.9.90-2.fc10 ----------------------------------- * Sun Sep 7 18:00:00 2008 Julian Sikorski - 0.9.90-2 - Patched the ppc build failure, thanks to Tom Callaway and Jean Br??fort * Sun Sep 7 18:00:00 2008 Julian Sikorski - 0.9.90-1 - Updated to 0.9.90 - Replaced the firefox/xulrunner conditional with gecko-devel - Provide and obsolete gchempaint - Dropped the rpath killer for the time being - Dropped the -devel subpackage since it is not needed any more gnucash-2.2.6-2.fc10 -------------------- * Tue Sep 9 18:00:00 2008 Bill Nottingham - 2.2.6-2 - rebuild against new aqbanking gvfs-0.99.7.1-2.fc10 -------------------- * Tue Sep 9 18:00:00 2008 - Bastien Nocera - 0.99.7.1-2 - Somebody made the build system be obnoxious and point out my errors in obvious ways * Tue Sep 9 18:00:00 2008 - Bastien Nocera - 0.99.7.1-1 - Update to 0.99.7.1 gwenhywfar-3.4.1-1.fc10 ----------------------- * Tue Sep 9 18:00:00 2008 Bill Nottingham - 3.4.1-1 - update to 3.4.1 hamster-applet-2.23.92-1.fc10 ----------------------------- * Tue Sep 9 18:00:00 2008 Mads Villadsen - 2.23.92-1 - Update to latest upstream release httrack-3.42.93-1.fc10 ---------------------- * Tue Sep 9 18:00:00 2008 Debarshi Ray - 3.42.93-1 - Version bump to 3.42.93. Closes Red Hat Bugzilla bugs #457523 (CVE-2008-3429)and #460529. - Use of generic macros in the publicly exposed API fixed by upstream. - Use of xdg-open now added by upstream. - OpenSSL version updated by upstream. - Linkage issues in libhtsjava.so fixed by upstream. * Thu Feb 21 17:00:00 2008 Debarshi Ray - 3.42-10 - Fixed runtime problems with --excludedocs. - Omitted unused direct shared library dependencies. hunspell-1.2.7-2.fc10 --------------------- * Tue Sep 9 18:00:00 2008 Caolan McNamara - 1.2.7-2 - add wordlist2hunspell jd-2.0.1-0.3.rc080909.fc10 -------------------------- * Wed Sep 10 18:00:00 2008 Mamoru Tasaka - 2.0.1-0.3.rc080909 - 2.0.1 rc 080909 jna-3.0.4-5.svn700.fc10 ----------------------- * Tue Sep 9 18:00:00 2008 Colin Walters - 3.0.4-5.svn700 - Update to upstream SVN r700; drop all now upstreamed patches * Sat Sep 6 18:00:00 2008 Colin Walters - 3.0.4-3.svn630 - A few more patches for JGIR * Thu Sep 4 18:00:00 2008 Colin Walters - 3.0.4-2.svn630 - Add two (sent upstream) patches that I need for JGIR kernel-2.6.27-0.317.rc5.git10.fc10 ---------------------------------- * Tue Sep 9 18:00:00 2008 Dave Airlie - radeon - update modesetting bits - should fix r400 - add i915 modesetting bits - don't enable these by default yet kmymoney2-0.9-2.fc10 -------------------- * Tue Sep 9 18:00:00 2008 Bill Nottingham 0.9-2 - rebuild for new libofx ABI kvm-74-3.fc10 ------------- * Tue Sep 9 18:00:00 2008 Glauber Costa - 74-3 - fix pxe booting. Needed for oVirt libcanberra-0.9-1.fc10 ---------------------- * Tue Sep 9 18:00:00 2008 Lennart Poettering 0.9-1 - New version libcmpiutil-0.4-2.fc10 ---------------------- * Fri Aug 29 18:00:00 2008 Kaitlin Rupert - 0.4-2 - Added add rep_disabled_ind.patch patch to enable disabled indication reporting libdvdnav-4.1.3-1.fc10 ---------------------- * Tue Sep 9 18:00:00 2008 Dominik Mierzejewski 4.1.3-1 - update to 4.1.3 final libdvdread-4.1.3-1.fc10 ----------------------- * Tue Sep 9 18:00:00 2008 Dominik Mierzejewski 4.1.3-1 - update to 4.1.3 final libgcrypt-1.4.2-1 ----------------- * Mon Sep 8 18:00:00 2008 Nalin Dahyabhai 1.4.2-1 - update to 1.4.2 * Tue Apr 29 18:00:00 2008 Nalin Dahyabhai 1.4.1-1 - update to 1.4.1 - bump libgpgerror-devel requirement to 1.4, matching the requirement enforced by the configure script libofx-0.9.0-1 -------------- * Tue Sep 9 18:00:00 2008 Bill Nottingham - 0.9.0-1 - update to 0.9.0 libpng-1.2.31-2.fc10 -------------------- * Tue Sep 9 18:00:00 2008 Tom Lane 2:1.2.31-2 - Apply upstream patch for zTXT buffer overrun (CVE-2008-3964) Related: #461599 libprelude-0.9.20.2-1.fc10 -------------------------- * Tue Sep 9 18:00:00 2008 Steve Grubb - 0.9.20.2-1 - New upstream bugfix release libselinux-2.0.71-4.fc10 ------------------------ * Tue Sep 9 18:00:00 2008 Dan Walsh - 2.0.71-4 - Add missing get/setkeycreatecon man pages * Tue Sep 9 18:00:00 2008 Dan Walsh - 2.0.71-3 - Split out utilities * Tue Sep 9 18:00:00 2008 Dan Walsh - 2.0.71-2 - Add missing man page links for [lf]getfilecon libvirt-0.4.5-2.fc10 -------------------- * Tue Sep 9 18:00:00 2008 Daniel Veillard - 0.4.5-2.fc10 - fix a crash if a QEmu/KVM domain is defined without an emulator path lilypond-doc-2.11.57-1.fc10 --------------------------- * Mon Sep 8 18:00:00 2008 Jon Ciesla 2.11.57-1 - Update to 2.11.57. lohit-fonts-2.3.1-1.fc10 ------------------------ * Tue Sep 9 18:00:00 2008 Rahul Bhalerao - 2.3.1-1 - Bug 216400: [te_IN] anaconda GUI - Release Notes button overlaps with other text metacity-2.23.610-1.fc10 ------------------------ * Tue Sep 9 18:00:00 2008 Matthias Clasen - 2.23.610-1 - Update to 2.23.610 midori-0.0.21-1.fc10 -------------------- * Tue Sep 9 18:00:00 2008 Peter Gordon - 0.0.21-1 - Update to new upstream release (0.0.21): contains updated translations, fixes for GVFS-->GIO regressions, and various aesthetic enhancements. (See the included ChangeLog for full details.) - Update Source0 URL. mkinitrd-6.0.63-1.fc10 ---------------------- * Tue Sep 9 18:00:00 2008 Peter Jones - 6.0.63-1 - Only sleep for /proc/scsi/scsi changes once (wwoods) - Handle built-in usbfs better - Support dhcp-specified nbd root path (wtogami) - Hide plymouth splash screen before dropping to a shell (katzj) - Create /dev/live symlink for SD (katzj) - Don't force a max length for labels in zipl module-init-tools-3.4.1-1.fc10 ------------------------------ * Tue Sep 9 18:00:00 2008 Jon Masters - 3.4.1 - Add ability to supply module options on kernel command line monafont-2.90-5.fc10 -------------------- * Tue Sep 9 18:00:00 2008 Mamoru Tasaka - 2.90-5 - F-10: Rebuild for new VLGothic nted-1.0.8-2.fc10 ----------------- * Wed Sep 10 18:00:00 2008 Hans Ulrich Niedermann - 1.0.8-2 - Work around upstream shipping an executable dynarray.h file. * Tue Sep 9 18:00:00 2008 Hans Ulrich Niedermann - 1.0.8-1 - Update to upstream's 1.0.8 release. octave-3.0.2-1.fc10 ------------------- * Mon Sep 8 18:00:00 2008 Orion Poplawski 3.0.2-1 - Update to 3.0.2 octave-forge-20080831-1.fc10 ---------------------------- * Mon Sep 8 18:00:00 2008 Orion Poplawski 20080831-1 - Update to 20080831 - Drop upstreamed patches - Enable octave-parallel for 64-bit platforms openoffice.org-3.0.0-5.1.fc10 ----------------------------- * Sun Sep 7 18:00:00 2008 Caol??n McNamara - 1:3.0.0-5.1 - next candidate openswan-2.6.16-1.fc10 ---------------------- * Tue Sep 9 18:00:00 2008 Avesh Agarwal - 2.6.16-1 - new upstream release paprefs-0.9.7-2.fc10 -------------------- * Tue Sep 9 18:00:00 2008 Lennart Poettering 0.9.7-2 - Include intltool in deps * Tue Sep 9 18:00:00 2008 Lennart Poettering 0.9.7-1 - Update to 0.9.7 * Thu Aug 28 18:00:00 2008 Michael Schwendt - 0.9.6-4 - Include unowned directory /usr/share/paprefs pavucontrol-0.9.7-2.fc10 ------------------------ * Tue Sep 9 18:00:00 2008 Lennart Poettering 0.9.7-2 - Add intltool to deps * Tue Sep 9 18:00:00 2008 Lennart Poettering 0.9.7-1 - Update to 0.9.7 perl-Authen-Radius-0.13-3.fc10 ------------------------------ * Tue Sep 9 18:00:00 2008 Tom "spot" Callaway - 0.13-3 - fix license tag (with permission from upstream) perl-Locale-SubCountry-1.41-1.fc10 ---------------------------------- * Mon Sep 8 18:00:00 2008 Chris Weyl 1.41-1 - update to 1.41 - chmod -x everything perl-PPI-1.203-1.fc10 --------------------- * Tue Sep 9 18:00:00 2008 Tom "spot" Callaway - 1.203-1 - update to 1.203 perl-Perl-Critic-1.092-1.fc10 ----------------------------- * Mon Sep 8 18:00:00 2008 Chris Weyl 1.092-1 - update to 1.092 perl-SOAP-Lite-0.710.07-2.fc10 ------------------------------ * Tue Sep 9 18:00:00 2008 Lubomir Rintel - 0.710.07-2 - Re-add the nil patch poker3d-1.1.36-11.fc10 ---------------------- * Tue Sep 9 18:00:00 2008 Christopher Stone 1.1.36-11 - Rebuild against OSG-2.6.0 policycoreutils-2.0.55-7.fc10 ----------------------------- * Tue Sep 9 18:00:00 2008 Dan Walsh 2.0.55-7 - Change Requires line to gnome-python2-gnome - Fix spelling mistakes - Require libselinux-utils postr-0.12.2-1.fc10 ------------------- * Tue Sep 9 18:00:00 2008 Tim Lauridsen - 0.12.2-1 - New upstream version 0.12.2 - added missing gnome-python2-gconf requirement. proj-4.6.1-1.fc10 ----------------- * Fri Sep 5 18:00:00 2008 Balint Cristian - 4.6.1-1 - new stable upstream - new nad datumgrids - drop debian license patch - change homepage URLs publican-0.37-0.fc10 -------------------- * Wed Sep 3 18:00:00 2008 Jeff Fearn 0.37 - Fix Bug in web rpm upgrade script. - Fix Article not building rpms. - Switch ja-JP font name in pdf from SazanamiMincho to SazanamiGothic - Remove empty para tags to break en-US HTML build so writers stop breaking translations. - Changed docs reference from --revision to --edition for create_book option - Fixed Article layout not matching Book Layout. BZ #460969 - Fixed Part not ledded properly in TOC BZ #460976 - Fix duplicate IDs in XHTML output. - Made background of remark a pretty yellow. BZ #459213 - Fix Accessibility typo. BZ #460856 - Fix spurious hyphenation in verbatim. - Fix broken RPM packages when titles have been translated. - Fix display bug in html-single. BZ #461375 - Added FAQ entry for Java weirdness. BZ #460738 - Add default encoding to XML files. BZ #461379 - Removed corpauthor from template. BZ #461222 - Fixed create_book help text. BZ #460736 - Added menuchoice tag. BZ #459671 * Mon Sep 1 18:00:00 2008 Jeff Fearn 0.35-0 - Add missing xerces-j2 Requires. BZ #457497 - Fixed css path for tranlation reports. - Fixed font path for Fedora, ensured build fails if font metric creation fails. BZ #458003 - Set vertical-align:top for TD - BZ #457851 - Added WARNING for ENTITIES declared in XML files. BZ #456170 - Added check to ensure PRODUCT has a valid format. - Only check xml files for revision history. BZ #458740 - Made VERSION and RELEASE over-rideable. BZ #458421 - Fixed display of OL nested in UL. BZ #457915 - Added "make pom" to output a basic maven pom file. - Updated doco. BZ #458764 - Updated Conventions.xml. BZ #456026 #459216 - Made PDF and HTML display product version in similar style. BZ #456486 - Remove ID's from common files. BZ #460770 - Allowed footnote to keep ID. BZ #460790 - Fixed bogus verbatim layout. BZ #460771 publican-fedora-0.15-0.fc10 --------------------------- * Tue Sep 9 18:00:00 2008 Jeff Fearn 0.15 - Removed corpauthor from template. BZ #461222 - Updated Fedora legal notice. BZ #448022 * Mon Sep 1 18:00:00 2008 Jeff Fearn 0.14-0 - Fix styles for publican 0.35 mods - Removed common entity files as they break translation - Remove ID's from common files. BZ #460770 pulseaudio-0.9.12-4.fc10 ------------------------ pybackpack-0.5.5-1.fc10 ----------------------- * Wed Sep 10 18:00:00 2008 Andy Price - 0.5.5-1 - Updated RPM to 0.5.5 pyclutter-0.6.2-2.fc9 --------------------- * Wed May 28 18:00:00 2008 Allisson Azevedo 0.6.2-2 - Rebuild against clutter-cairo python-augeas-0.3.0-1.fc10 -------------------------- * Tue Sep 9 18:00:00 2008 Harald Hoyer 0.3.0-1 - version 0.3.0 python-nss-0.1-1.fc10 --------------------- * Tue Sep 9 18:00:00 2008 John Dennis - 0.1-1 - clean up ssl_example.py, fix arg list in get_cert_nicknames, make certdir cmd line arg consistent with other NSS tools - update httplib.py to support client auth, add httplib_example.py which illustrates it's use - fix some documentation - fix some type usage which were unsafe on 64-bit python-pyasn1-0.0.8a-1.fc10 --------------------------- * Tue Sep 9 18:00:00 2008 Paul P. Komkoff Jr - 0.0.8a-1 - Update to upstream version 0.0.8a python-slip-0.1.13-1.fc10 ------------------------- * Tue Sep 9 18:00:00 2008 Nils Philippsen - 0.1.13 - add working examples qpidc-0.3.693548-1.fc10 ----------------------- * Tue Sep 9 18:00:00 2008 Nuno Santos - 0.3.693548-1 - Include latest changes to qmf rhm-0.2.2432-1.fc10 ------------------- * Tue Sep 9 18:00:00 2008 Nuno Santos - 0.2.2432-1 - Update for Fedora 10 * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.2.2153-3 - fix license tag * Tue Jul 15 18:00:00 2008 Nuno Santos - 0.2.2153-2 - BZ359461: fix package URL * Mon Jun 16 18:00:00 2008 Kim van der Riet - 0.2.2153-1 - Rebased to rev.2153 - Added qpidd rev no dependency * Thu Jun 12 18:00:00 2008 Kim van der Riet - 0.2.2150-1 - Rebased to rev.2150 * Thu Jun 12 18:00:00 2008 Kim van der Riet - 0.2.2148-3 - Changed the installation mechanism for libs * Wed Jun 11 18:00:00 2008 Justin Ross - 0.2.2148-2 - Use macros for the lib dir * Tue Jun 10 18:00:00 2008 Kim van der Riet - 0.2.2148-1 - rebase to rev 2148 - imported nsantos' rhmd fixes * Tue Jun 10 18:00:00 2008 Kim van der Riet - 0.2.2146-1 - rebase to rev 2146 - removed refs to dir /etc/rhmd * Fri Jun 6 18:00:00 2008 Kim van der Riet - 0.2.2144-1 - rebase to rev 2144 ricci-0.15.0-2.fc10 ------------------- * Tue Sep 9 18:00:00 2008 Ryan McCabe 0.15.0-2 - Add nss-devel to BuildDepends * Tue Sep 9 18:00:00 2008 Ryan McCabe 0.15.0-1 - Break circular dependency with cman ruby-cairo-1.7.0-1.fc10 ----------------------- * Tue Sep 9 18:00:00 2008 Allisson Azevedo 1.7.0-1 - Update to 1.7.0 ruby-gnome2-0.17.0-1.fc10 ------------------------- * Tue Sep 9 18:00:00 2008 Allisson Azevedo 0.17.0-1 - Update to 0.17.0 - Removed ruby-gnome2-0.17.0-rc1-newgtk-021303.patch ruby-openid-2.1.2-1.fc10 ------------------------ * Tue Sep 9 18:00:00 2008 Allisson Azevedo 2.1.2-1 - Update to 2.1.2 setroubleshoot-2.0.8-2.fc10 --------------------------- * Tue Sep 9 18:00:00 2008 Dan Walsh - 2.0.8-2 - Fix setroubleshoot init to rely on messagebus being running * Tue Sep 9 18:00:00 2008 Dan Walsh - 2.0.8-1 - Fix spelling mistakes - Update translations sound-theme-freedesktop-0.1-4.fc10 ---------------------------------- * Tue Sep 9 18:00:00 2008 Lennart Poettering - 0.82.5-4 - remove pseudo.po from the source tarball swfdec-gnome-2.23.4-1.fc10 -------------------------- * Mon Sep 8 18:00:00 2008 Brian Pepple - 2.23.4-1 - Update to 2.23.4. swfdec-mozilla-0.8.0-1.fc10 --------------------------- * Tue Sep 9 18:00:00 2008 Brian Pepple - 0.8.0-1 - Update to 0.8.0. system-config-kdump-1.0.14-1.fc10 --------------------------------- * Tue Sep 9 18:00:00 2008 Roman Rakus 1.0.14-1 - Bump to version 1.0.14 themes-backgrounds-gnome-0.5.1-1.fc10 ------------------------------------- * Tue Sep 9 18:00:00 2008 Tom "spot" Callaway - 0.5.1-1 - add GNOME-Transparent back, author gives permission to use under CC-BY-SA wordpress-2.6.2-1.fc10 ---------------------- * Tue Sep 9 18:00:00 2008 Adrian Reber - 2.6.2-1 - updated to 2.6.2 xchat-gnome-0.23.92-1.fc10 -------------------------- * Tue Sep 9 18:00:00 2008 Brian Pepple - 0.23.92-1 - Update to 0.23.92. - Add deps patch to correctly set libnotify & libcanberra options. - Update BR. - Drop reconnect patch. Fixed upstream. - Drop away-command patch. Fixed upstream. - Drop spell-checking patch. Fixed upstream. - Drop it-translation patch. Fixed upstream. xmms-skins-1.2.10-17 -------------------- * Tue Sep 9 18:00:00 2008 Tom "spot" Callaway 1:1.2.10-17 - got some responses from skin creators, readded some of the removed skins xorg-x11-drv-i810-2.4.2-6.fc10 ------------------------------ * Tue Sep 9 18:00:00 2008 Dave Airlie 2.4.2-6 - fix typo in drmmode display.c xorg-x11-drv-synaptics-0.15.1-1.fc10 ------------------------------------ * Tue Sep 9 18:00:00 2008 Peter Hutterer 0.15.1-1 - update to 0.15.1 - remove xf86-input-synaptics-0.15.0-tap.patch: merged in upstream. - update patches to apply against 0.15.1. - xf86-input-synaptics-0.15.1-dont-crash-without-Device.patch: don't crash if neither Device nor Path is given. zaptel-1.4.12.1-1.fc10 ---------------------- * Tue Sep 9 18:00:00 2008 Jeffrey C. Ollie - 1.4.12.1-1 - Update to 1.4.12.1 Summary: Added Packages: 5 Removed Packages: 9 Modified Packages: 88 Broken deps for i386 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 grisbi-0.5.9-7.fc10.i386 requires libofx.so.3 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.12-1.fc10.i386 requires perl(MT::Plugin) highlight-2.6.12-1.fc10.i386 requires perl(MT::WeblogPublisher) highlight-2.6.12-1.fc10.i386 requires perl(MT::Entry) highlight-2.6.12-1.fc10.i386 requires perl(MT) highlight-2.6.12-1.fc10.i386 requires perl(MT::Template::Context) homebank-3.8-2.fc10.i386 requires libofx.so.3 mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for x86_64 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) grisbi-0.5.9-7.fc10.x86_64 requires libofx.so.3()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.12-1.fc10.x86_64 requires perl(MT::Plugin) highlight-2.6.12-1.fc10.x86_64 requires perl(MT::WeblogPublisher) highlight-2.6.12-1.fc10.x86_64 requires perl(MT::Entry) highlight-2.6.12-1.fc10.x86_64 requires perl(MT) highlight-2.6.12-1.fc10.x86_64 requires perl(MT::Template::Context) homebank-3.8-2.fc10.x86_64 requires libofx.so.3()(64bit) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for ppc ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) grisbi-0.5.9-7.fc10.ppc requires libofx.so.3 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.12-1.fc10.ppc requires perl(MT::Plugin) highlight-2.6.12-1.fc10.ppc requires perl(MT::WeblogPublisher) highlight-2.6.12-1.fc10.ppc requires perl(MT::Entry) highlight-2.6.12-1.fc10.ppc requires perl(MT) highlight-2.6.12-1.fc10.ppc requires perl(MT::Template::Context) homebank-3.8-2.fc10.ppc requires libofx.so.3 mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires libbfd-2.18.50.0.8-2.fc10.so stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires libopcodes-2.18.50.0.8-2.fc10.so vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for ppc64 ---------------------------------------------------------- eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) grisbi-0.5.9-7.fc10.ppc64 requires libofx.so.3()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave highlight-2.6.12-1.fc10.ppc64 requires perl(MT::Plugin) highlight-2.6.12-1.fc10.ppc64 requires perl(MT::WeblogPublisher) highlight-2.6.12-1.fc10.ppc64 requires perl(MT::Entry) highlight-2.6.12-1.fc10.ppc64 requires perl(MT) highlight-2.6.12-1.fc10.ppc64 requires perl(MT::Template::Context) homebank-3.8-2.fc10.ppc64 requires libofx.so.3()(64bit) livecd-tools-018-1.fc10.ppc64 requires yaboot mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 From mike.cloaked at gmail.com Wed Sep 10 10:48:23 2008 From: mike.cloaked at gmail.com (Mike) Date: Wed, 10 Sep 2008 10:48:23 +0000 (UTC) Subject: The Transition - big thank you Message-ID: I would like to say thank you to all the people who have worked so tirelessly to implement the transition to the new keys and get this out for all users. It has been hard for many users to keep patient and wait but this is overall a huge success. One outcome is that many more people will be much more aware of security issues... I have now regenerated all my own ssh keys and gpg keys to use 4096 bit RSA encryption - so hopefully I am a little less susceptible to the already low risk of key compromise. In addition I am now a fan of SELinux! Thank you From pingou at pingoured.fr Wed Sep 10 11:16:13 2008 From: pingou at pingoured.fr (Pierre-Yves) Date: Wed, 10 Sep 2008 13:16:13 +0200 Subject: Call for developers: rpmbuilder In-Reply-To: <48C56121.4040605@redhat.com> References: <48C56121.4040605@redhat.com> Message-ID: <48C7AC7D.9050908@pingoured.fr> Chris Evich wrote: > Hi, > > Hopefully this is the right mailing list :) > > Project rpmbuilder aims to provide a template-based approach to packaging. In > other words, it removes responsibility from developer to produce an RPM spec > file the "right" way. Instead, the package developer just feeds in his > project's particulars, and a template-driven engine puts the pieces together > and spits out a "sane" RPM and SRPM. > > https://fedorahosted.org/rpmbuilder > > Given the recent discussions on dependency management, perhaps there is some > interest in helping me develop this tool further. There's no mailing list > yet, so if interested, please contact me directly. Thanks! Hi, Sorry for late reaction, but I have the feeling that your tool is quite close to what I have been working on recently: https://fedorahosted.org/r2spec/ But R2spec is oriented for R libraries whether your is general, maybe there would be a way to integrate them... Regards, Pierre From opensource at till.name Wed Sep 10 11:31:10 2008 From: opensource at till.name (Till Maas) Date: Wed, 10 Sep 2008 13:31:10 +0200 Subject: make force-tag gone In-Reply-To: <48C70D77.9080605@gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <1220998193.15726.76.camel@localhost.localdomain> <48C70D77.9080605@gmail.com> Message-ID: <200809101331.19227.opensource@till.name> On Wed September 10 2008, Toshio Kuratomi wrote: > For instance: > > make build => Creates a new unique, immutable tag like > koji-username-package-nvr-timestamp and submits to koji > koji processes the tag as normal and adds the information to its database. > If failure > packager cvs add's and cvs commits a missing patch file. > make build => Creates a new unique tag with the same username, > package, and nvr but a new timestamp. > repeat as necessary This was already discussed when it was proposed to make the tags immutable. I do not know, why such a procedure was not implemented. > * Note: I don't know if koji has some understanding of what the tag > looks like although I don't see why it should. Afaik koji only expects some cvs URL to work on, e.g. one can use HEAD instead of a tag-value to build HEAD. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From paul at city-fan.org Wed Sep 10 11:33:53 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 10 Sep 2008 12:33:53 +0100 Subject: make force-tag gone In-Reply-To: <20080910104137.GH2662@redhat.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> <20080910104137.GH2662@redhat.com> Message-ID: <48C7B0A1.1030901@city-fan.org> Daniel P. Berrange wrote: > On Tue, Sep 09, 2008 at 05:39:48PM +0000, Kevin Kofler wrote: >> Jeffrey Ollie ocjtech.us> writes: >>> Refusing to bump a release number and re-tag because you don't want to >>> "look stupid" is not a technical argument. >> Maybe, but it's a practical argument. >> >>> And before you ask, yes I've used force-tag before even though I know >>> I shouldn't. Removing it will help me be a better package manager. >> No, it will make you a worse packager, as your Release tags will get >> incremented for no reason. > > It is far far worse than this. If you made a mistake doing an update > for Fedora 8, and have to bump the Release tag, its quite possible > F8 will end up with newer N-E-V-R, than your F9 & rawhide builds > breaking the upgrade path. So, now you have to re-build F9 and rawhide > with pointless Release tag bumps too :-( Unless of course you bump the release after the disttag, e.g. %{?dist}.1, in which case you won't break the upgrade path and everything will be hunky-dory. Paul. From rjones at redhat.com Wed Sep 10 11:56:57 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 10 Sep 2008 12:56:57 +0100 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: <1220977399.4252.22.camel@kennedy> References: <1220977399.4252.22.camel@kennedy> Message-ID: <20080910115657.GA25796@amd.home.annexia.org> On Tue, Sep 09, 2008 at 12:23:19PM -0400, Brian Pepple wrote: > /topic FESCo-Meeting -- MinGW - > https://fedoraproject.org/wiki/User:Jspaleta/Draft - all Just to be clear, this draft has nothing to do with the MinGW SIG, nor is it endorsed or approved in any way by the MinGW SIG. Jef has done nothing for MinGW except be obstructionist and force a decision through the Board behind our backs, based on unfounded FUD, which creates a great deal of extra work for everyone for no apparent benefit. The URLs you should be looking at before the FESCO meeting are: http://fedoraproject.org/wiki/SIGs/MinGW http://hg.et.redhat.com/misc/fedora-mingw--devel/ Dan & I will be at the meeting today to answer any questions. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From rjones at redhat.com Wed Sep 10 12:01:17 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 10 Sep 2008 13:01:17 +0100 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: <20080910115657.GA25796@amd.home.annexia.org> References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> Message-ID: <20080910120117.GB25796@amd.home.annexia.org> On Wed, Sep 10, 2008 at 12:56:57PM +0100, Richard W.M. Jones wrote: > http://fedoraproject.org/wiki/SIGs/MinGW > http://hg.et.redhat.com/misc/fedora-mingw--devel/ Ooops, missed one: http://fedoraproject.org/wiki/PackagingDrafts/MinGW Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From christoph.wickert at googlemail.com Wed Sep 10 12:05:55 2008 From: christoph.wickert at googlemail.com (Christoph Wickert) Date: Wed, 10 Sep 2008 14:05:55 +0200 Subject: make force-tag gone In-Reply-To: <604aa7910809091028n2db1f23agfa973695d66b9c06@mail.gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <3170f42f0809090945k597b6505s8c83fc853424a72e@mail.gmail.com> <604aa7910809091028n2db1f23agfa973695d66b9c06@mail.gmail.com> Message-ID: <1221048355.3285.32.camel@wicktop.localdomain> Am Dienstag, den 09.09.2008, 09:28 -0800 schrieb Jeff Spaleta: > On Tue, Sep 9, 2008 at 8:45 AM, Debarshi Ray wrote: > > I have happily used 'TAG_OPTS=-F make tag' [1] on the rare occasions > > that I needed force-tag. I might try to use local hacks to get around > > it if people decided to try and block 'TAG_OPTS=-F make tag'. :-) > > We will ultimately need to also disable TAG_OPTS=-F as well -1 There are situations where "TAG_OPTS=-F" is really handy and I stumbled over one last night while doing a review: On the topic of ExcludeArch the review guidelines state: > Each architecture listed in ExcludeArch needs to have a bug filed in > bugzilla, describing the reason that the package does not > compile/build/work on that architecture. The bug number should then be > placed in a comment, next to the corresponding ExcludeArch line. New > packages will not have bugzilla entries during the review process, so > they should put this description in the comment until the package is > approved, then file the bugzilla entry, and replace the long > explanation with the bug number. When I approve a package I expect this very special package (NVR) to be imported into CVS. But for packages with ExcludeArch it means that the review requester will have to 1. file a bug after CVS admin procedure is done and the bugzilla component was created, 2. import the package (where it is automatically tagged), 3. add the bug # to the ExcludeArch statement in the spec and 4. then the bump the release only for a trivial change in the spec that * does not affect the functionality of the package nor of the spec in any way * is not visible to users at all and * is not caused by the packagers inattention You see: There are situations where forcing a tag really makes sense. Instead of banning "TAG_OPTS=-F" we should better educate our packagers to not abuse it (accidentally). make tag should check if the same NVR has already been build successfully in koji, but as long as this is not implemented we should stick with forcing tags. Regards, Christoph From billcrawford1970 at gmail.com Wed Sep 10 12:09:54 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 10 Sep 2008 13:09:54 +0100 Subject: Banned from Fedora Forums In-Reply-To: <3170f42f0809091144i4a98a60x314cb1c7199c1941@mail.gmail.com> References: <1220983505.17299.5.camel@hughsie-work> <3170f42f0809091144i4a98a60x314cb1c7199c1941@mail.gmail.com> Message-ID: <544eb990809100509t6c42c3a0ib08976be1fc150e0@mail.gmail.com> On 09/09/2008, Debarshi Ray wrote: >> These are all the posts I've made on the forum if you want to check any >> of my messages: >> http://forums.fedoraforum.org/search.php?searchid=7137995 > > ... and they led me to http://www.gtk.org/setuid.html Thank you. :-) Irony of ironies! The gnome project seeks to replace xscreensaver with something security-related that ... relies on that "500,000 line library". > Happy hacking, > Debarshi And to you, also... From sundaram at fedoraproject.org Wed Sep 10 12:22:30 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 10 Sep 2008 17:52:30 +0530 Subject: Banned from Fedora Forums In-Reply-To: <544eb990809100509t6c42c3a0ib08976be1fc150e0@mail.gmail.com> References: <1220983505.17299.5.camel@hughsie-work> <3170f42f0809091144i4a98a60x314cb1c7199c1941@mail.gmail.com> <544eb990809100509t6c42c3a0ib08976be1fc150e0@mail.gmail.com> Message-ID: <48C7BC06.2060109@fedoraproject.org> Bill Crawford wrote: > On 09/09/2008, Debarshi Ray wrote: >>> These are all the posts I've made on the forum if you want to check any >>> of my messages: >>> http://forums.fedoraforum.org/search.php?searchid=7137995 >> ... and they led me to http://www.gtk.org/setuid.html Thank you. :-) > > Irony of ironies! The gnome project seeks to replace xscreensaver with > something security-related that ... relies on that "500,000 line > library". http://live.gnome.org/GnomeScreensaver/FrequentlyAskedQuestions#head-93217f8ba0fb60ef0b31db92b662319ccbc87bae Rahul From bkearney at redhat.com Wed Sep 10 12:22:16 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 10 Sep 2008 08:22:16 -0400 Subject: FESCo Meeting Summary for 2008-08-13 In-Reply-To: <1221028770.3388.136.camel@luminos.localdomain> References: <1218669241.5849.11.camel@kennedy> <1221028770.3388.136.camel@luminos.localdomain> Message-ID: <48C7BBF8.4060400@redhat.com> Jesse Keating wrote: > On Wed, 2008-08-13 at 19:14 -0400, Brian Pepple wrote: >> * FESCo approved the following feature for F10: >> * http://fedoraproject.org/wiki/Features/ApplianceTools > > I just noticed and read this a little closer... and looked a the meeting > minutes which were... sparse. > > This feature involves Fedora actually producing and distributing > something we've never done before, a tarred image for use in a virtual > machine. That's not your typical "spin" which is an iso format to be > consumed by booting it on hardware, real or fake. Was any thought or > discussion at all put into the implications of this? Was releng > consulted about our ability to produce/test this during development > cycles, particularly Beta? Do we have any thought as to how this would > be advertised to users, and any documentation about how to use it as > well? I can not speak to all the questions, but I know that Josh Broyler was there during the meeting but to be fair we did not discuss that it was a different type of spin. We would be happy to provide the documentaion around how to use it. The tooling which would be used (based on livecd-tools) went through a round of testing the last fedora test day. > > Could FESCo maybe take another gander at this feature page and comment > on some of the above issues? I will plan on being online for the FESCO meeting to discuss as necessary. -- bk From dwalsh at redhat.com Wed Sep 10 12:25:20 2008 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 10 Sep 2008 08:25:20 -0400 Subject: Has any action on automatic submission of bugzillas been done for any Fedora Products? Message-ID: <48C7BCB0.6060203@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I know earlier this summer there was a lot of discussion around bugbuddy, kerneloops and setroubleshooter being able to submit bug reports. Has any work on infrastructure been done on this? Does anyone have a pointer to how this could be done? I would really like to make it easier for setroubleshoot to submit bugs. Dan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjHvLAACgkQrlYvE4MpobMc4gCfQd4w5r208eTCpVa1l5oNhdtx Qu4AnAvUlYGsKKIb+ydEfhnLt+M9rofa =H4Bt -----END PGP SIGNATURE----- From bkearney at redhat.com Wed Sep 10 12:25:45 2008 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 10 Sep 2008 08:25:45 -0400 Subject: FESCo Meeting Summary for 2008-08-13 In-Reply-To: <200809100213.01371.dennis@ausil.us> References: <1218669241.5849.11.camel@kennedy> <1221028770.3388.136.camel@luminos.localdomain> <200809100213.01371.dennis@ausil.us> Message-ID: <48C7BCC9.7020504@redhat.com> Dennis Gilmore wrote: > On Wednesday 10 September 2008 01:39:30 am Jesse Keating wrote: >> On Wed, 2008-08-13 at 19:14 -0400, Brian Pepple wrote: >>> * FESCo approved the following feature for F10: >>> * http://fedoraproject.org/wiki/Features/ApplianceTools >> I just noticed and read this a little closer... and looked a the meeting >> minutes which were... sparse. >> >> This feature involves Fedora actually producing and distributing >> something we've never done before, a tarred image for use in a virtual >> machine. That's not your typical "spin" which is an iso format to be >> consumed by booting it on hardware, real or fake. Was any thought or >> discussion at all put into the implications of this? Was releng >> consulted about our ability to produce/test this during development >> cycles, particularly Beta? Do we have any thought as to how this would >> be advertised to users, and any documentation about how to use it as >> well? >> >> Could FESCo maybe take another gander at this feature page and comment >> on some of the above issues? > I messed up here I missed "Requires hosting a binary image on > http://spins.fedoraproject.org/" from what I remembered it was providing tools > to create appliances. not us actually providing appliance images. since > appliances are specialised configured things its really hard to provide a > single appliance. I personally have no issue with hosting appliance > kickstart files. but i think we need to review hosting a binary appliance > image Dennis: In this case the "appliance" is a running system with the bare number of packages. It is just delivered as a raw disk as opposed to an ISO. Again, I will make sure to be online for the meeting so we can discuss. -- bk From clumens at redhat.com Wed Sep 10 12:31:16 2008 From: clumens at redhat.com (Chris Lumens) Date: Wed, 10 Sep 2008 08:31:16 -0400 Subject: Has any action on automatic submission of bugzillas been done for any Fedora Products? In-Reply-To: <48C7BCB0.6060203@redhat.com> References: <48C7BCB0.6060203@redhat.com> Message-ID: <20080910123116.GR4575@localhost.localdomain> > I know earlier this summer there was a lot of discussion around > bugbuddy, kerneloops and setroubleshooter being able to submit bug > reports. Has any work on infrastructure been done on this? Does anyone > have a pointer to how this could be done? I would really like to make > it easier for setroubleshoot to submit bugs. anaconda is now doing semi-automatic filing of bugs - when an exception happens, one of the destinations you can now save to is bugzilla. So you have to enter your login information, but everything else is automatic. We're using the python-bugzilla module to do all the communications. - Chris From Matt_Domsch at dell.com Wed Sep 10 12:31:22 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 10 Sep 2008 07:31:22 -0500 Subject: make force-tag gone In-Reply-To: <1221030518.20891.118.camel@jcmlaptop.bos.redhat.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <1221030518.20891.118.camel@jcmlaptop.bos.redhat.com> Message-ID: <20080910123122.GA23250@auslistsprd01.us.dell.com> On Wed, Sep 10, 2008 at 03:08:38AM -0400, Jon Masters wrote: > On Tue, 2008-09-09 at 10:10 -0500, Mike McGrath wrote: > > > So why would you make a change to the spec file, without bumping the > > release? > > Because (with all due respect) it seems silly to bump the release just > to deal with fat-fingering something. It happens countless times too. > > > Also there's an auditing GPL legal reason (IIRC) that we're > > doing this now. > > Can someone confirm that this legal reason actually exists? i.e. if one > builds packages that are never released, how is it then a problem to > retag? And besides, CVS history is still coherent in either case. The question is - can an automated tool, given a binary RPM, request of CVS the corresponding source code for it? Yes, unless people can arbitrarily re-tag after the packages have been published. Then there is no guarantee that what is tagged in CVS matches the source code for a given package. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From buc at odusz.so-cdu.ru Wed Sep 10 12:46:02 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Wed, 10 Sep 2008 16:46:02 +0400 Subject: make force-tag gone In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> <200809091007.23542.dennis@ausil.us> Message-ID: <48C7C18A.2090701@odu.neva.ru> Kevin Kofler wrote: > The most common reason people force a tag is that the package failed to build > because of a typo in the specfile. > IMHO the most common case is that the package failed to build either on another arch (ie. ppc when a packager has i386 only), or on another release (ie. rawhide when a packager has, say F8 only). ~buc From sundaram at fedoraproject.org Wed Sep 10 12:47:05 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 10 Sep 2008 18:17:05 +0530 Subject: Has any action on automatic submission of bugzillas been done for any Fedora Products? In-Reply-To: <20080910123116.GR4575@localhost.localdomain> References: <48C7BCB0.6060203@redhat.com> <20080910123116.GR4575@localhost.localdomain> Message-ID: <48C7C1C9.9060401@fedoraproject.org> Chris Lumens wrote: >> I know earlier this summer there was a lot of discussion around >> bugbuddy, kerneloops and setroubleshooter being able to submit bug >> reports. Has any work on infrastructure been done on this? Does anyone >> have a pointer to how this could be done? I would really like to make >> it easier for setroubleshoot to submit bugs. > > anaconda is now doing semi-automatic filing of bugs - when an exception > happens, one of the destinations you can now save to is bugzilla. So > you have to enter your login information, but everything else is > automatic. We're using the python-bugzilla module to do all the > communications. Can we avoid the requirement of a prexisting account? Rahul From denis at poolshark.org Wed Sep 10 12:49:35 2008 From: denis at poolshark.org (Denis Leroy) Date: Wed, 10 Sep 2008 14:49:35 +0200 Subject: make force-tag gone In-Reply-To: <20080910123122.GA23250@auslistsprd01.us.dell.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <1221030518.20891.118.camel@jcmlaptop.bos.redhat.com> <20080910123122.GA23250@auslistsprd01.us.dell.com> Message-ID: <48C7C25F.1060602@poolshark.org> Matt Domsch wrote: > The question is - can an automated tool, given a binary RPM, request > of CVS the corresponding source code for it? Yes, unless people can > arbitrarily re-tag after the packages have been published. Then there > is no guarantee that what is tagged in CVS matches the source code for > a given package. I think we all agree that re-tagging after packages have been built is plain wrong. However this doesn't invalidate the various uses of force-tag that have been discussed in this thread. All we need is a mechanism such that a successful koji build automatically renders the associated tag immutable. From jonstanley at gmail.com Wed Sep 10 12:51:49 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 10 Sep 2008 08:51:49 -0400 Subject: Has any action on automatic submission of bugzillas been done for any Fedora Products? In-Reply-To: <48C7C1C9.9060401@fedoraproject.org> References: <48C7BCB0.6060203@redhat.com> <20080910123116.GR4575@localhost.localdomain> <48C7C1C9.9060401@fedoraproject.org> Message-ID: On Wed, Sep 10, 2008 at 8:47 AM, Rahul Sundaram wrote: > Can we avoid the requirement of a prexisting account? No, there is no XMLRPC call to create a new account (except for admins). From dev at nigelj.com Wed Sep 10 12:53:00 2008 From: dev at nigelj.com (Nigel Jones) Date: Thu, 11 Sep 2008 00:53:00 +1200 Subject: Has any action on automatic submission of bugzillas been done for any Fedora Products? In-Reply-To: <48C7C1C9.9060401@fedoraproject.org> References: <48C7BCB0.6060203@redhat.com> <20080910123116.GR4575@localhost.localdomain> <48C7C1C9.9060401@fedoraproject.org> Message-ID: <1221051180.3398.52.camel@fantail.jnet.net.nz> On Wed, 2008-09-10 at 18:17 +0530, Rahul Sundaram wrote: > Chris Lumens wrote: > >> I know earlier this summer there was a lot of discussion around > >> bugbuddy, kerneloops and setroubleshooter being able to submit bug > >> reports. Has any work on infrastructure been done on this? Does anyone > >> have a pointer to how this could be done? I would really like to make > >> it easier for setroubleshoot to submit bugs. > > > > anaconda is now doing semi-automatic filing of bugs - when an exception > > happens, one of the destinations you can now save to is bugzilla. So > > you have to enter your login information, but everything else is > > automatic. We're using the python-bugzilla module to do all the > > communications. > > Can we avoid the requirement of a prexisting account? I believe the requirement was set due to fears that it'd lead to abuse, something I can actually agree with. -- Nigel Jones From tmz at pobox.com Wed Sep 10 13:19:40 2008 From: tmz at pobox.com (Todd Zullinger) Date: Wed, 10 Sep 2008 09:19:40 -0400 Subject: Moving git commands to libexecdir before beta/freeze (was Re: rpms/git/devel .cvsignore, 1.63, 1.64 git.spec, 1.70, 1.71 sources, 1.63, 1.64 In-Reply-To: <1220022654.13092.1.camel@aglarond.local> References: <20080828121729.6F97B70118@cvs1.fedora.phx.redhat.com> <20080828230443.GV21166@inocybe.teonanacatl.org> <20080829114107.GC20496@crux.yyz.redhat.com> <1220022654.13092.1.camel@aglarond.local> Message-ID: <20080910131940.GH2939@inocybe.teonanacatl.org> Jeremy Katz wrote: > Should change it in rawhide before the beta/feature freeze. Not > that it's big enough to qualify as a "feature" but it's a > significant enough behavior change that there should be time for > everyone else to adapt. So the freeze is tomorrow, should we be changing git before then so that the beta can test things in the new location? I put some patches with the minor changes needed to the git spec file for 1.6.0.1 with the git- commands in libexdir at: https://bugzilla.redhat.com/show_bug.cgi?id=460414 -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Life is the art of drawing without an eraser. -- John Gardner -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From jreiser at BitWagon.com Wed Sep 10 13:23:07 2008 From: jreiser at BitWagon.com (John Reiser) Date: Wed, 10 Sep 2008 06:23:07 -0700 Subject: Has any action on automatic submission of bugzillas been done for any Fedora Products? In-Reply-To: References: <48C7BCB0.6060203@redhat.com> <20080910123116.GR4575@localhost.localdomain> <48C7C1C9.9060401@fedoraproject.org> Message-ID: <48C7CA3B.4050509@BitWagon.com> >> Can we avoid the requirement of a prexisting account? > > No, there is no XMLRPC call to create a new account (except for admins). Create an account for the purpose ("Fedora 10 Automatic Bug Report") and pre-load the fields, including password. Ask in the instructions that anyone with their own account, please override the default. Having a "public password" probably requires administrative approval in advance. -- From clumens at redhat.com Wed Sep 10 13:44:18 2008 From: clumens at redhat.com (Chris Lumens) Date: Wed, 10 Sep 2008 09:44:18 -0400 Subject: Has any action on automatic submission of bugzillas been done for any Fedora Products? In-Reply-To: <48C7CA3B.4050509@BitWagon.com> References: <48C7BCB0.6060203@redhat.com> <20080910123116.GR4575@localhost.localdomain> <48C7C1C9.9060401@fedoraproject.org> <48C7CA3B.4050509@BitWagon.com> Message-ID: <20080910134418.GS4575@localhost.localdomain> >>> Can we avoid the requirement of a prexisting account? >> >> No, there is no XMLRPC call to create a new account (except for admins). > > Create an account for the purpose ("Fedora 10 Automatic Bug Report") > and pre-load the fields, including password. Ask in the instructions > that anyone with their own account, please override the default. > Having a "public password" probably requires administrative approval > in advance. I avoided going down this route in the interests of getting the feature done sometime this year. By just requiring that people use their existing accounts, I was free to get the feature written and committing without needing to deal with all sorts of policies and concerns over public passwords and all that stuff. - Chris From billcrawford1970 at gmail.com Wed Sep 10 13:47:53 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 10 Sep 2008 14:47:53 +0100 Subject: Banned from Fedora Forums In-Reply-To: <48C7BC06.2060109@fedoraproject.org> References: <1220983505.17299.5.camel@hughsie-work> <3170f42f0809091144i4a98a60x314cb1c7199c1941@mail.gmail.com> <544eb990809100509t6c42c3a0ib08976be1fc150e0@mail.gmail.com> <48C7BC06.2060109@fedoraproject.org> Message-ID: <544eb990809100647q292f365ek113504535d1c7df9@mail.gmail.com> On 10/09/2008, Rahul Sundaram wrote: > Bill Crawford wrote: ... >> Irony of ironies! The gnome project seeks to replace xscreensaver with >> something security-related that ... relies on that "500,000 line >> library". > http://live.gnome.org/GnomeScreensaver/FrequentlyAskedQuestions#head-93217f8ba0fb60ef0b31db92b662319ccbc87bae Yes, it's just funny they can do that but complain that their stuff isn't safe for running as root. If there are holes for root, there are holes for users. Less apocalyptic impact, maybe, but still :o) Anyway, apologies for hijacking the thread. And yes, I did read it all. I know it's not quite as black and white as all that ... > Rahul From jonathan at jonmasters.org Wed Sep 10 13:51:56 2008 From: jonathan at jonmasters.org (Jon Masters) Date: Wed, 10 Sep 2008 09:51:56 -0400 Subject: make force-tag gone In-Reply-To: <48C7C25F.1060602@poolshark.org> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <1221030518.20891.118.camel@jcmlaptop.bos.redhat.com> <20080910123122.GA23250@auslistsprd01.us.dell.com> <48C7C25F.1060602@poolshark.org> Message-ID: <1221054716.15227.11.camel@jcmlaptop.bos.redhat.com> On Wed, 2008-09-10 at 14:49 +0200, Denis Leroy wrote: > Matt Domsch wrote: > > The question is - can an automated tool, given a binary RPM, request > > of CVS the corresponding source code for it? Yes, unless people can > > arbitrarily re-tag after the packages have been published. Then there > > is no guarantee that what is tagged in CVS matches the source code for > > a given package. Indeed. I got the point :) But like others, I'm saying it's a non-problem until the package has ever been made available. > I think we all agree that re-tagging after packages have been built is > plain wrong. Hmm...actually, I'd prefer it to be an issue only after you've released those packages, but I suppose the argument will be that once a package is there in koji someone might download it. > However this doesn't invalidate the various uses of > force-tag that have been discussed in this thread. All we need is a > mechanism such that a successful koji build automatically renders the > associated tag immutable. Or we could trust people to do the right thing ;) Jon. From Jochen at herr-schmitt.de Wed Sep 10 14:02:24 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 10 Sep 2008 16:02:24 +0200 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: <20080909184336.GB16093@yoda.jdub.homelinux.org> References: <1220977399.4252.22.camel@kennedy> <20080909184336.GB16093@yoda.jdub.homelinux.org> Message-ID: <0ML29c-1KdQHQ07ED-0001VA@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 9 Sep 2008 14:43:36 -0400, you wrote: >I think we need to talk about the make force-tag change. It was simply >done, with no discussion by rel-eng or FESCo. I thank ther is a simple reason for removing this feature. 'make force-tag allow you to build serveral releases of you package with the same release number, so you can determinate which content in the cvs belongs to a specific build in koji. This breaks the rules in the fedora project to increase the release number for every build. This may the reason to remove this feature so you don't make the people to easy to move tags in the cvs repository. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) Charset: us-ascii wj8DBQFIx9OLT2AHK6txfgwRAoJMAJ4tGxMLe1711S97PS8oLBA3Q8/+AACdH0op str1lrXHtnfen4L2Ns4lBLs= =/Fn7 -----END PGP SIGNATURE----- From jwboyer at gmail.com Wed Sep 10 14:03:07 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 10 Sep 2008 10:03:07 -0400 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: <20080910115657.GA25796@amd.home.annexia.org> References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> Message-ID: <20080910140307.GA23069@yoda.jdub.homelinux.org> On Wed, Sep 10, 2008 at 12:56:57PM +0100, Richard W.M. Jones wrote: >On Tue, Sep 09, 2008 at 12:23:19PM -0400, Brian Pepple wrote: >> /topic FESCo-Meeting -- MinGW - >> https://fedoraproject.org/wiki/User:Jspaleta/Draft - all > >Just to be clear, this draft has nothing to do with the MinGW SIG, nor >is it endorsed or approved in any way by the MinGW SIG. > >Jef has done nothing for MinGW except be obstructionist and force a >decision through the Board behind our backs, based on unfounded FUD, >which creates a great deal of extra work for everyone for no apparent >benefit. Can you comment on what part of his draft you find objectionable? >The URLs you should be looking at before the FESCO meeting are: Those pages (and the other you had in your subsequent email) seem to be augmenting Jeff's proposal rather than conflicting with it. So Jeff's proposal seems to be the "1000 ft. view", while your pages are the implemenation of that. At least from my reading. If you don't agree, commenting on that (preferably on the wiki page itself) would be more helpful. josh From jwboyer at gmail.com Wed Sep 10 14:08:03 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 10 Sep 2008 10:08:03 -0400 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: <0ML29c-1KdQHQ07ED-0001VA@mrelayeu.kundenserver.de> References: <1220977399.4252.22.camel@kennedy> <20080909184336.GB16093@yoda.jdub.homelinux.org> <0ML29c-1KdQHQ07ED-0001VA@mrelayeu.kundenserver.de> Message-ID: <20080910140803.GB23069@yoda.jdub.homelinux.org> On Wed, Sep 10, 2008 at 04:02:24PM +0200, Jochen Schmitt wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Tue, 9 Sep 2008 14:43:36 -0400, you wrote: > >>I think we need to talk about the make force-tag change. It was simply >>done, with no discussion by rel-eng or FESCo. > >I thank ther is a simple reason for removing this feature. > >'make force-tag allow you to build serveral releases of you >package with the same release number, so you can determinate >which content in the cvs belongs to a specific build in koji. > >This breaks the rules in the fedora project to increase the >release number for every build. > >This may the reason to remove this feature so you don't make the >people to easy to move tags in the cvs repository. Sure. I understand that. It was still done without any discussion or mention to FESCo or rel-eng. It impacts developers (as should be apparent from the already long thread on it) and changes like that should at least get approval before being done. So, even if FESCo retro-actively approves the change, I'd like to at least try to actually follow some semblance of process here. josh From tbrinkman at sbcglobal.net Wed Sep 10 14:15:13 2008 From: tbrinkman at sbcglobal.net (Tom) Date: Wed, 10 Sep 2008 09:15:13 -0500 Subject: Fedora 8 and 9 updates re-enabled In-Reply-To: <1221028475.3388.132.camel@luminos.localdomain> References: <1221028475.3388.132.camel@luminos.localdomain> Message-ID: <200809100915.14102.tbrinkman@sbcglobal.net> On Wednesday 10 September 2008 01:34:35 am Jesse Keating wrote: > In a few hours, updates for Fedora 8 and Fedora 9 will start > hitting mirrors. These updates are designed to transition users > from our old repo locations to new locations that have all our > updates re-signed with a new set of keys. > > Most users will simply need to apply the offered updates, and > later apply any further updates, and verify/import the new GPG > key. > > The process to getting new updates is two stage. Worked flawlessly. F9 + updates, T61 laptop (all Intel) -- Tom Brinkman Corpus Christi, Texas From denis at poolshark.org Wed Sep 10 14:18:15 2008 From: denis at poolshark.org (Denis Leroy) Date: Wed, 10 Sep 2008 16:18:15 +0200 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: <0ML29c-1KdQHQ07ED-0001VA@mrelayeu.kundenserver.de> References: <1220977399.4252.22.camel@kennedy> <20080909184336.GB16093@yoda.jdub.homelinux.org> <0ML29c-1KdQHQ07ED-0001VA@mrelayeu.kundenserver.de> Message-ID: <48C7D727.4020304@poolshark.org> Jochen Schmitt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, 9 Sep 2008 14:43:36 -0400, you wrote: > >> I think we need to talk about the make force-tag change. It was simply >> done, with no discussion by rel-eng or FESCo. > > I thank ther is a simple reason for removing this feature. > > 'make force-tag allow you to build serveral releases of you > package with the same release number, so you can determinate > which content in the cvs belongs to a specific build in koji. There are arguments on both sides, but this is discussed in the "make force-tag gone" thread. From jreiser at BitWagon.com Wed Sep 10 14:27:21 2008 From: jreiser at BitWagon.com (John Reiser) Date: Wed, 10 Sep 2008 07:27:21 -0700 Subject: Has any action on automatic submission of bugzillas been done for any Fedora Products? In-Reply-To: <20080910134418.GS4575@localhost.localdomain> References: <48C7BCB0.6060203@redhat.com> <20080910123116.GR4575@localhost.localdomain> <48C7C1C9.9060401@fedoraproject.org> <48C7CA3B.4050509@BitWagon.com> <20080910134418.GS4575@localhost.localdomain> Message-ID: <48C7D949.4020407@BitWagon.com> Chris Lumens wrote: >>>> Can we avoid the requirement of a prexisting account? >>> No, there is no XMLRPC call to create a new account (except for admins). >> Create an account for the purpose ("Fedora 10 Automatic Bug Report") ... > I avoided going down this route in the interests of getting the feature > done sometime this year. [avoiding both abuse and red tape ...] Is there an option to e-mail or scp the data to an alternate destination, in case the user has no bugzilla account or cannot remember the password? (My browser remembers for me, else I have to look it up.) -- From clumens at redhat.com Wed Sep 10 14:32:58 2008 From: clumens at redhat.com (Chris Lumens) Date: Wed, 10 Sep 2008 10:32:58 -0400 Subject: Has any action on automatic submission of bugzillas been done for any Fedora Products? In-Reply-To: <48C7D949.4020407@BitWagon.com> References: <48C7BCB0.6060203@redhat.com> <20080910123116.GR4575@localhost.localdomain> <48C7C1C9.9060401@fedoraproject.org> <48C7CA3B.4050509@BitWagon.com> <20080910134418.GS4575@localhost.localdomain> <48C7D949.4020407@BitWagon.com> Message-ID: <20080910143257.GT4575@localhost.localdomain> > Is there an option to e-mail or scp the data to an alternate destination, > in case the user has no bugzilla account or cannot remember the password? > (My browser remembers for me, else I have to look it up.) Yes, you can still save via scp (which works now, unlike in F10 Alpha) or to a removable drive if you plug one in before clicking "Save". - Chris From dr.diesel at gmail.com Wed Sep 10 14:33:01 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Wed, 10 Sep 2008 09:33:01 -0500 Subject: Fedora 8 and 9 updates re-enabled In-Reply-To: <200809100915.14102.tbrinkman@sbcglobal.net> References: <1221028475.3388.132.camel@luminos.localdomain> <200809100915.14102.tbrinkman@sbcglobal.net> Message-ID: <2a28d2ab0809100733x2f0f6d21h2391992f41adc1af@mail.gmail.com> On Wed, Sep 10, 2008 at 9:15 AM, Tom wrote: > On Wednesday 10 September 2008 01:34:35 am Jesse Keating wrote: >> In a few hours, updates for Fedora 8 and Fedora 9 will start >> hitting mirrors. These updates are designed to transition users >> from our old repo locations to new locations that have all our >> updates re-signed with a new set of keys. >> >> Most users will simply need to apply the offered updates, and >> later apply any further updates, and verify/import the new GPG >> key. >> >> The process to getting new updates is two stage. > > Worked flawlessly. F9 + updates, T61 laptop (all Intel) > -- Minor issue for me: --> Running transaction check ---> Package phonon-backend-gstreamer.i386 0:4.2.0-4.fc9 set to be updated ---> Package yum-utils.noarch 0:1.1.16-1.fc9 set to be updated --> Processing Dependency: yum >= 3.2.19 for package: yum-utils --> Finished Dependency Resolution yum-utils-1.1.16-1.fc9.noarch from updates-newkey has depsolving problems --> Missing Dependency: yum >= 3.2.19 is needed by package yum-utils-1.1.16-1.fc9.noarch (updates-newkey) Error: Missing Dependency: yum >= 3.2.19 is needed by package yum-utils-1.1.16-1.fc9.noarch (updates-newkey) [root at localhost ~]# -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org From vgaburici at gmail.com Wed Sep 10 14:34:28 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Wed, 10 Sep 2008 17:34:28 +0300 Subject: Somewhat off-topic: Another Slashdot (negative) story on the Fedora infrastructure security breach Message-ID: http://linux.slashdot.org/article.pl?sid=08/09/10/029231 From katzj at redhat.com Wed Sep 10 14:48:53 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 10 Sep 2008 10:48:53 -0400 Subject: Creating a spin - any mechanisms around $product-release, $product-release-notes, $product-logos packages...? In-Reply-To: <46a038f90809100242o4e65059enbc0f71d65412032e@mail.gmail.com> References: <46a038f90809100242o4e65059enbc0f71d65412032e@mail.gmail.com> Message-ID: <1221058133.18710.91.camel@aglarond.local> On Wed, 2008-09-10 at 21:42 +1200, Martin Langhoff wrote: > My key question is: will anything in the Fedora machinery (anaconda, > rpm, yum) be looking for a magic "product" name, and then try to use > it to request $product-release? Nothing that I know of Jeremy From dennis at ausil.us Wed Sep 10 14:49:54 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 10 Sep 2008 09:49:54 -0500 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: <20080910140803.GB23069@yoda.jdub.homelinux.org> References: <1220977399.4252.22.camel@kennedy> <0ML29c-1KdQHQ07ED-0001VA@mrelayeu.kundenserver.de> <20080910140803.GB23069@yoda.jdub.homelinux.org> Message-ID: <200809100949.54769.dennis@ausil.us> On Wednesday 10 September 2008 09:08:03 am Josh Boyer wrote: > On Wed, Sep 10, 2008 at 04:02:24PM +0200, Jochen Schmitt wrote: > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > >On Tue, 9 Sep 2008 14:43:36 -0400, you wrote: > >>I think we need to talk about the make force-tag change. It was simply > >>done, with no discussion by rel-eng or FESCo. > > > >I thank ther is a simple reason for removing this feature. > > > >'make force-tag allow you to build serveral releases of you > >package with the same release number, so you can determinate > >which content in the cvs belongs to a specific build in koji. > > > >This breaks the rules in the fedora project to increase the > >release number for every build. > > > >This may the reason to remove this feature so you don't make the > >people to easy to move tags in the cvs repository. > > Sure. I understand that. It was still done without any discussion or > mention to FESCo or rel-eng. It impacts developers (as should be apparent > from the already long thread on it) and changes like that should at least > get approval before being done. > > So, even if FESCo retro-actively approves the change, I'd like to at least > try to actually follow some semblance of process here. > > josh it was quietly added, 16 months ago, because someone inside Red Hat complained that fedoras makefile.common was different to Red Hat's it should have never been added in the first place. Dennis From sundaram at fedoraproject.org Wed Sep 10 14:52:45 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 10 Sep 2008 20:22:45 +0530 Subject: Fedora 8 and 9 updates re-enabled In-Reply-To: <2a28d2ab0809100733x2f0f6d21h2391992f41adc1af@mail.gmail.com> References: <1221028475.3388.132.camel@luminos.localdomain> <200809100915.14102.tbrinkman@sbcglobal.net> <2a28d2ab0809100733x2f0f6d21h2391992f41adc1af@mail.gmail.com> Message-ID: <48C7DF3D.9020008@fedoraproject.org> Dr. Diesel wrote: > On Wed, Sep 10, 2008 at 9:15 AM, Tom wrote: >> On Wednesday 10 September 2008 01:34:35 am Jesse Keating wrote: >>> In a few hours, updates for Fedora 8 and Fedora 9 will start >>> hitting mirrors. These updates are designed to transition users >>> from our old repo locations to new locations that have all our >>> updates re-signed with a new set of keys. >>> >>> Most users will simply need to apply the offered updates, and >>> later apply any further updates, and verify/import the new GPG >>> key. >>> >>> The process to getting new updates is two stage. >> Worked flawlessly. F9 + updates, T61 laptop (all Intel) >> -- > > Minor issue for me: > > --> Running transaction check > ---> Package phonon-backend-gstreamer.i386 0:4.2.0-4.fc9 set to be updated > ---> Package yum-utils.noarch 0:1.1.16-1.fc9 set to be updated > --> Processing Dependency: yum >= 3.2.19 for package: yum-utils > --> Finished Dependency Resolution > yum-utils-1.1.16-1.fc9.noarch from updates-newkey has depsolving problems > --> Missing Dependency: yum >= 3.2.19 is needed by package > yum-utils-1.1.16-1.fc9.noarch (updates-newkey) > Error: Missing Dependency: yum >= 3.2.19 is needed by package > yum-utils-1.1.16-1.fc9.noarch (updates-newkey) https://fedoraproject.org/w/index.php?title=Enabling_new_signing_key#Known_Issues Rahul From dpierce at redhat.com Wed Sep 10 14:58:53 2008 From: dpierce at redhat.com (Darryl L. Pierce) Date: Wed, 10 Sep 2008 10:58:53 -0400 Subject: Fedora 8 and 9 updates re-enabled In-Reply-To: <200809100915.14102.tbrinkman@sbcglobal.net> References: <1221028475.3388.132.camel@luminos.localdomain> <200809100915.14102.tbrinkman@sbcglobal.net> Message-ID: <20080910145851.GA4334@redhat.com> +++ Tom [10/09/08 09:15 -0500]: > Worked flawlessly. F9 + updates, T61 laptop (all Intel) I hit a problem with updating yum-utils: it wants yum >= 3.2.19 and the only version available is 3.2.17 in stable. -- Darryl L. Pierce, Sr. Software Engineer Red Hat, Inc. - http://www.redhat.com/ oVirt - Virtual Machine Management - http://www.ovirt.org/ "What do you care what other people think, Mr. Feynman?" -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rjones at redhat.com Wed Sep 10 15:02:26 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 10 Sep 2008 16:02:26 +0100 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: <20080910140307.GA23069@yoda.jdub.homelinux.org> References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> Message-ID: <20080910150226.GA14299@amd.home.annexia.org> On Wed, Sep 10, 2008 at 10:03:07AM -0400, Josh Boyer wrote: > Can you comment on what part of his draft you find objectionable? Specifically three things: (1) It imposes upon us the need to use a separate repository, which is based on the false assumption that we will be rebuilding a substantial proportion of all Fedora packages, like some sort of secondary architecture. In reality this is not the case - we only wish to rebuild a few common libraries. Secondary architectures rebuild every package, including applications, which we have no intention of doing even if it were possible (which it isn't). (2) "All packages must first be natively available in Fedora before they can be in the MinGW repo" This is a considerable restriction. A useful Windows cross- development environment must include packages like NSIS installer, GNU gettext and PortableXDR, none of which would make sense as standalone Fedora packages. (3) "The repository definition(s) will be included in fedora-release but will be disabled by default." But no reason is given why this extra repository should be disabled by default. Much of the draft states the obvious, like "All packages submitted for MinGW repo must pass a formal review" and "any MinGW specific caveats must be documented in the Fedora Packaging Guidelines". And there's also the plain odd stuff like the requirement to use our own signing key. Anyway, I don't want to spend too long on this since the actual people doing the work are trying to produce a proper, detailed technical packaging draft here: https://fedoraproject.org/wiki/PackagingDrafts/MinGW No "1000 ft views" in here. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From jkeating at redhat.com Wed Sep 10 15:05:50 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 10 Sep 2008 08:05:50 -0700 Subject: make force-tag gone In-Reply-To: <1221054716.15227.11.camel@jcmlaptop.bos.redhat.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <1221030518.20891.118.camel@jcmlaptop.bos.redhat.com> <20080910123122.GA23250@auslistsprd01.us.dell.com> <48C7C25F.1060602@poolshark.org> <1221054716.15227.11.camel@jcmlaptop.bos.redhat.com> Message-ID: <1221059150.3388.145.camel@luminos.localdomain> On Wed, 2008-09-10 at 09:51 -0400, Jon Masters wrote: > Or we could trust people to do the right thing ;) Surely you've been in the real world long enough to realize that this just doesn't happen? Either by ignorance or malice, it's bound to happen and given that it /could/ happen we cannot rely upon it at this point. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed Sep 10 15:10:27 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 10 Sep 2008 08:10:27 -0700 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: <200809100949.54769.dennis@ausil.us> References: <1220977399.4252.22.camel@kennedy> <0ML29c-1KdQHQ07ED-0001VA@mrelayeu.kundenserver.de> <20080910140803.GB23069@yoda.jdub.homelinux.org> <200809100949.54769.dennis@ausil.us> Message-ID: <1221059427.3388.146.camel@luminos.localdomain> On Wed, 2008-09-10 at 09:49 -0500, Dennis Gilmore wrote: > it was quietly added, 16 months ago, because someone inside Red Hat complained > that fedoras makefile.common was different to Red Hat's it should have never > been added in the first place. Except that the TAG_OPTS=-F had been there for much much longer, and had been used the same way. We did discuss a while ago removing the option to force-tag, everywhere, and the pushback was pretty much the same. Solve the problem some other way rather than destroying the ability to force-tag on broken builds. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From hughsient at gmail.com Wed Sep 10 15:09:33 2008 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 10 Sep 2008 16:09:33 +0100 Subject: PackageKit 0.3.2 in rawhide In-Reply-To: <1220953689.11468.6.camel@hughsie-work> References: <1220953689.11468.6.camel@hughsie-work> Message-ID: <1221059373.17299.99.camel@hughsie-work> On Tue, 2008-09-09 at 10:48 +0100, Richard Hughes wrote: > Please can you try out this new release and report any bugs you find > either in bugzilla or by emailing the packagekit mailing list. The big > new feature of this release is a new dispatcher, which should improve > the interactivity of GUI applications as the yum instance is reused > rather than re-loaded each time. There's also the usual set of bugfixes > too. Also, there's a nice little test that I would like people to try: do "pkcon refresh" to make sure you're up to date Edit /etc/PackageKit/PackageKit.conf and enable the RefreshCacheScanDesktopFiles and RefreshCacheUpdatePackageList keys. then do "pkcon refresh" and tell me roughly how long it takes before the gpk-update-icon process (the box icon in the top right) stops reporting searches. Enabling the two commands creates the package list which is used for auto-completion in gpk-application, and it also enables the icons and translations used in the various client tools. If it doesn't take ages (it's pretty CPU demanding) then I'll enable it by default for F10. Richard. From jkeating at redhat.com Wed Sep 10 15:13:56 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 10 Sep 2008 08:13:56 -0700 Subject: Fedora 8 and 9 updates re-enabled In-Reply-To: <48C775A6.3070406@redhat.com> References: <1221028475.3388.132.camel@luminos.localdomain> <1221030533.18327.76.camel@beck.corsepiu.local> <48C775A6.3070406@redhat.com> Message-ID: <1221059636.3388.147.camel@luminos.localdomain> On Wed, 2008-09-10 at 03:22 -0400, Warren Togami wrote: > > The current default mock-configs don't know anything about the > > "*.newkey" repos, nor do I see mock update-packages pending. > > > > Ralf > > > > > > Yeah, LiveCD kickstart files, and ltsp-client chroot kickstart files > need updating as well. These will be forthcoming soon. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From hughsient at gmail.com Wed Sep 10 15:14:08 2008 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 10 Sep 2008 16:14:08 +0100 Subject: Feature Proposal: Use cases database In-Reply-To: <48C767E7.9040801@gmail.com> References: <1220991029.3782.47.camel@choeger6> <1221026638.2783.6.camel@hp6710.axianet.ch> <48C767E7.9040801@gmail.com> Message-ID: <1221059648.17299.103.camel@hughsie-work> On Wed, 2008-09-10 at 01:23 -0500, Les Mikesell wrote: > Even better than talking about it would be creating the exact package > lists that best enable a variety of use cases and a handy way of > telling yum/packagekit to duplicate them on your machine. Then anyone > else who needed to do the same thing would have a push-button choice. > The idea should be that anyone could 'publish' their installed package > set and describe why they think it is best for a particular use, and > anyone who was convinced by their description/reputation, etc. could > just clone that setup. PackageKit already supports catalogs, which is pretty much what you describe. Have a look here http://www.packagekit.org/pk-faq.html#catalogs and tell me if that does what you need. Richard. From dledford at redhat.com Wed Sep 10 15:23:13 2008 From: dledford at redhat.com (Doug Ledford) Date: Wed, 10 Sep 2008 11:23:13 -0400 Subject: make force-tag gone In-Reply-To: <57400.198.175.55.5.1220975702.squirrel@mail.jcomserv.net> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <56296.198.175.55.5.1220974578.squirrel@mail.jcomserv.net> <57400.198.175.55.5.1220975702.squirrel@mail.jcomserv.net> Message-ID: <1221060193.1927.205.camel@firewall.xsintricity.com> On Tue, 2008-09-09 at 10:55 -0500, Jon Ciesla wrote: > If if is, then can the Makefile be modified to prevent it, so that others > who didn't know that stop doing it? No, because then you could just run the cvs command by hand. If our recent "incident" showed us anything, it's that things like this need to be enforced on the CVS server if they are going to be enforced at all. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dledford at redhat.com Wed Sep 10 15:28:10 2008 From: dledford at redhat.com (Doug Ledford) Date: Wed, 10 Sep 2008 11:28:10 -0400 Subject: make force-tag gone In-Reply-To: <1220978806.11620.6.camel@luminos.localdomain> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <1220978806.11620.6.camel@luminos.localdomain> Message-ID: <1221060490.1927.210.camel@firewall.xsintricity.com> On Tue, 2008-09-09 at 09:46 -0700, Jesse Keating wrote: > On Tue, 2008-09-09 at 18:03 +0200, Denis Leroy wrote: > > > > There's no logic here. You're not forcing people to tag after every CVS > > check-in, as far as I know. If a release 'n' fails to build (for > > example, because you forgot to check-in a patch), it makes zero sense to > > bump to n+1, because release 'n' never *existed* in the first place, > > since it was never built. That has zero impact over auditing. Spec file > > auditing is done through CVS. > > The audit part is something of a red herring. The GPL compliance part > is what is bothersome. If we want to save archive space by relying on > re-generating srpms of shipped binaries on demand, we need to ensure > that CVS tags don't change over time. For better or worse, we build > from CVS tags, so to get the source that matched the build, we have to > checkout via CVS tags. If those tags can change over time, the trust > level is gone. That's why there is a push to make the tags immutable, > or at least the successfully built tags immutable. > > Personally I just want to move off of CVS and off of building from tags, > and instead build from something inherently immutable, like the shasum > of the repo at a given time. > > MikeB said that he'd look into some CVS/make changes that would allow > checking koji for an on going or successful build of a tag/n-v-r before > allowing a force-tag. This would allow folks to force-tag before having > a successful build, but would not allow you to force the tag after a > successful build, or while a build is still going with that n-v-r. > > I think this approach, while it may slow down force-tags and prevent > force-tags during any koji outage, will give us the best of both worlds. Of course, a relatively minor change would eliminate this problem. If you just modify koji to treat any build command that uses a branch name instead of a specific revision tag to mean HEAD of that branch, then you can have it download the HEAD of the branch, check the n-v-r in the spec file, check for a conflicting tag already in the repo and bail if found, if not found perform the build, if build succeeds, koji adds n-v-r tag to repo, if build fails, tag still absent. If you want to build a specific non-HEAD build, you just pass in an already existing tag, koji treats it as a rebuild and builds the package accordingly and makes no effort to put the tag into the repo. Really, we shouldn't be tagging at all if the purpose of a tag is to mean "This is the exact source code we built through the build system". Koji knows that just as well as we do, and koji can enforce the correctness and immutability of it without having to worry about CVS tricks or anything like that. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed Sep 10 15:30:05 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 10 Sep 2008 08:30:05 -0700 Subject: make force-tag gone In-Reply-To: <1221060490.1927.210.camel@firewall.xsintricity.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <43749.198.175.55.5.1220972067.squirrel@mail.jcomserv.net> <48C69E37.5090205@poolshark.org> <1220978806.11620.6.camel@luminos.localdomain> <1221060490.1927.210.camel@firewall.xsintricity.com> Message-ID: <1221060605.3388.149.camel@luminos.localdomain> On Wed, 2008-09-10 at 11:28 -0400, Doug Ledford wrote: > Of course, a relatively minor change Great, so we should expect a patch from you any moment now? (: In all seriousness, I'm not really interested in piling more CVS hacks upon koji. I'd much rather spend what little time I get to do buildsystem development to move toward an SCM where this becomes moot. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dledford at redhat.com Wed Sep 10 15:35:15 2008 From: dledford at redhat.com (Doug Ledford) Date: Wed, 10 Sep 2008 11:35:15 -0400 Subject: Boot speedup with readahead In-Reply-To: <1220970586.987.70.camel@rosebud> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <20080909072334.58be6bb3@infradead.org> <1220970586.987.70.camel@rosebud> Message-ID: <1221060916.1927.212.camel@firewall.xsintricity.com> On Tue, 2008-09-09 at 10:29 -0400, Seth Vidal wrote: > On Tue, 2008-09-09 at 07:23 -0700, Arjan van de Ven wrote: > > On Tue, 9 Sep 2008 10:01:09 -0400 > > "Colin Walters" wrote: > > > This would be great and we've really needed it for a long time. > > > Ideally it would be structured to recognize packages based on their > > > content; for example, if a package installs an icon in > > > /usr/share/icons, we know to invoke gtk-update-icon-cache. > > > > that makes it a question if this should be in yum or in rpm.... > > > > I'm fairly confident it'll be easier to do in yum. It doesn't matter where it's easy to do, what matters is it's done in the right place. Core system infrastructure should never be a case of done the easy way, always the right way. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From limb at jcomserv.net Wed Sep 10 15:42:15 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 10 Sep 2008 10:42:15 -0500 (CDT) Subject: [Fwd: Package: wesnoth-1.4.5-1.fc10 Tag: dist-f10 Status: failed Built by: limb] Message-ID: <46628.198.175.55.5.1221061335.squirrel@mail.jcomserv.net> I've seen this exact error before, and if I resubmit and get a non-ppc builder, it works for all arches. Is there anything I can to, save re-submitting ad nauseum? inf ticket,perhaps? ---------------------------- Original Message ---------------------------- Subject: Package: wesnoth-1.4.5-1.fc10 Tag: dist-f10 Status: failed Built by: limb From: "Koji Build System" Date: Wed, September 10, 2008 10:16 am To: mikeb at fedoraproject.org jkeating at fedoraproject.org notting at fedoraproject.org limb at fedoraproject.org kanarip at fedoraproject.org -------------------------------------------------------------------------- Package: wesnoth-1.4.5-1.fc10 Tag: dist-f10 Status: failed Built by: limb ID: 62521 Started: Wed, 10 Sep 2008 15:10:39 UTC Finished: Wed, 10 Sep 2008 15:16:15 UTC Changelog: * Tue Sep 09 2008 Jon Ciesla - 1.4.5-1 - New upstream release. * Tue Aug 12 2008 Jon Ciesla - 1.4.4-1 - New upstream release. - Introduced patch fuzz workaround, will fix. * Thu May 08 2008 Jon Ciesla - 1.4.2-1 - New upstream maintenance release. wesnoth-1.4.5-1.fc10 (62521) failed on xenbuilder4.fedora.phx.redhat.com (noarch), x86-6.fedora.phx.redhat.com (x86_64), x86-2.fedora.phx.redhat.com (i386): BuildrootError: error building package (arch i386), mock exited with status 250 SRPMS: wesnoth-1.4.5-1.fc10.src.rpm Failed tasks: ------------- Task 817702 on xenbuilder4.fedora.phx.redhat.com Task Type: build (dist-f10, devel:wesnoth-1_4_5-1_fc10) Task 817738 on x86-6.fedora.phx.redhat.com Task Type: buildArch (wesnoth-1.4.5-1.fc10.src.rpm, x86_64) logs: http://koji.fedoraproject.org/koji/getfile?taskID=817738&name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=817738&name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=817738&name=state.log Task 817739 on x86-2.fedora.phx.redhat.com Task Type: buildArch (wesnoth-1.4.5-1.fc10.src.rpm, i386) logs: http://koji.fedoraproject.org/koji/getfile?taskID=817739&name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=817739&name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=817739&name=state.log Canceled tasks: --------------- Task 817737 on ppc3.fedora.redhat.com Task Type: buildArch (wesnoth-1.4.5-1.fc10.src.rpm, ppc) logs: http://koji.fedoraproject.org/koji/getfile?taskID=817737&name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=817737&name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=817737&name=state.log Task 817740 on ppc2.fedora.redhat.com Task Type: buildArch (wesnoth-1.4.5-1.fc10.src.rpm, ppc64) logs: http://koji.fedoraproject.org/koji/getfile?taskID=817740&name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=817740&name=root.log http://koji.fedoraproject.org/koji/getfile?taskID=817740&name=state.log Closed tasks: ------------- Task 817703 on x86-3.fedora.phx.redhat.com Task Type: buildSRPMFromSCM (devel:wesnoth-1_4_5-1_fc10) logs: http://koji.fedoraproject.org/koji/getfile?taskID=817703&name=srpm.log Task Info: http://koji.fedoraproject.org/koji/taskinfo?taskID=817702 Build Info: http://koji.fedoraproject.org/koji/buildinfo?buildID=62521 -- novus ordo absurdum From jspaleta at gmail.com Wed Sep 10 15:42:31 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 10 Sep 2008 07:42:31 -0800 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: <20080910150226.GA14299@amd.home.annexia.org> References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> Message-ID: <604aa7910809100842pdb9ba5bl727f3aca09fd3b27@mail.gmail.com> On Wed, Sep 10, 2008 at 7:02 AM, Richard W.M. Jones wrote: > (1) It imposes upon us the need to use a separate repository, which is > based on the false assumption that we will be rebuilding a substantial > proportion of all Fedora packages, like some sort of secondary > architecture. > > In reality this is not the case - we only wish to rebuild a few common > libraries. Secondary architectures rebuild every package, including > applications, which we have no intention of doing even if it were > possible (which it isn't). You can't make any assurances that additional community members will not want additional libraries nor applications to be included. You have a very narrow view as to what you need right now with regard to a development environment for a specific task. It doesn't take much to realize, even from the infrastructure ticket that the libraries requested can mushroom into something larger than the set of libraries you are currently envisioning. > Much of the draft states the obvious, like "All packages submitted for > MinGW repo must pass a formal review" and "any MinGW specific caveats > must be documented in the Fedora Packaging Guidelines". And there's > also the plain odd stuff like the requirement to use our own signing > key. If its a separate repo it will need its own signing key. If its not a stand alone repo, then that requirement is void. > > Anyway, I don't want to spend too long on this since the actual people > doing the work are trying to produce a proper, detailed technical > packaging draft here: > > https://fedoraproject.org/wiki/PackagingDrafts/MinGW This draft does not address the things which came out of the FAB discussion thread. > No "1000 ft views" in here. Indeed your technical draft does not make any effort to address project policy issues as brought to and discussed in the advisory-list. -jef From choeger at cs.tu-berlin.de Wed Sep 10 15:42:28 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 10 Sep 2008 17:42:28 +0200 Subject: Feature Proposal: Use cases database In-Reply-To: <1221059648.17299.103.camel@hughsie-work> References: <1220991029.3782.47.camel@choeger6> <1221026638.2783.6.camel@hp6710.axianet.ch> <48C767E7.9040801@gmail.com> <1221059648.17299.103.camel@hughsie-work> Message-ID: <1221061348.20090.1.camel@choeger6> Am Mittwoch, den 10.09.2008, 16:14 +0100 schrieb Richard Hughes: > On Wed, 2008-09-10 at 01:23 -0500, Les Mikesell wrote: > > Even better than talking about it would be creating the exact package > > lists that best enable a variety of use cases and a handy way of > > telling yum/packagekit to duplicate them on your machine. Then anyone > > else who needed to do the same thing would have a push-button choice. > > The idea should be that anyone could 'publish' their installed package > > set and describe why they think it is best for a particular use, and > > anyone who was convinced by their description/reputation, etc. could > > just clone that setup. > > PackageKit already supports catalogs, which is pretty much what you > describe. > > Have a look here http://www.packagekit.org/pk-faq.html#catalogs and tell > me if that does what you need. > > Richard. > > Hey, that sounds nice, as it fits perfectly into the "detect what if I have all that software installed" hole. I assume there is an 'just check' mode or the user is at least prompted, what parts are missing? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From hughsient at gmail.com Wed Sep 10 15:47:14 2008 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 10 Sep 2008 16:47:14 +0100 Subject: Feature Proposal: Use cases database In-Reply-To: <1221061348.20090.1.camel@choeger6> References: <1220991029.3782.47.camel@choeger6> <1221026638.2783.6.camel@hp6710.axianet.ch> <48C767E7.9040801@gmail.com> <1221059648.17299.103.camel@hughsie-work> <1221061348.20090.1.camel@choeger6> Message-ID: <1221061634.17299.109.camel@hughsie-work> On Wed, 2008-09-10 at 17:42 +0200, Christoph H?ger wrote: > Am Mittwoch, den 10.09.2008, 16:14 +0100 schrieb Richard Hughes: > > On Wed, 2008-09-10 at 01:23 -0500, Les Mikesell wrote: > > > Even better than talking about it would be creating the exact package > > > lists that best enable a variety of use cases and a handy way of > > > telling yum/packagekit to duplicate them on your machine. Then anyone > > > else who needed to do the same thing would have a push-button choice. > > > The idea should be that anyone could 'publish' their installed package > > > set and describe why they think it is best for a particular use, and > > > anyone who was convinced by their description/reputation, etc. could > > > just clone that setup. > > > > PackageKit already supports catalogs, which is pretty much what you > > describe. > > > > Have a look here http://www.packagekit.org/pk-faq.html#catalogs and tell > > me if that does what you need. > > > Hey, that sounds nice, as it fits perfectly into the "detect what if I > have all that software installed" hole. I assume there is an 'just > check' mode or the user is at least prompted, what parts are missing? The user is just asked to install the stuff they haven't already got. I'm not sure what the dialog looks like if you have nothing to install, but I imaging it's that standard modal "nothing to install" dialog. Richard. From rjones at redhat.com Wed Sep 10 15:51:54 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 10 Sep 2008 16:51:54 +0100 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: <604aa7910809100842pdb9ba5bl727f3aca09fd3b27@mail.gmail.com> References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> <604aa7910809100842pdb9ba5bl727f3aca09fd3b27@mail.gmail.com> Message-ID: <20080910155154.GA28948@amd.home.annexia.org> On Wed, Sep 10, 2008 at 07:42:31AM -0800, Jeff Spaleta wrote: > On Wed, Sep 10, 2008 at 7:02 AM, Richard W.M. Jones wrote: > > (1) It imposes upon us the need to use a separate repository, which is > > based on the false assumption that we will be rebuilding a substantial > > proportion of all Fedora packages, like some sort of secondary > > architecture. > > > > In reality this is not the case - we only wish to rebuild a few common > > libraries. Secondary architectures rebuild every package, including > > applications, which we have no intention of doing even if it were > > possible (which it isn't). > > You can't make any assurances that additional community members will > not want additional libraries nor applications to be included. You > have a very narrow view as to what you need right now with regard to a > development environment for a specific task. It doesn't take much to > realize, even from the infrastructure ticket that the libraries > requested can mushroom into something larger than the set of libraries > you are currently envisioning. But even a larger set of libraries isn't the whole of Fedora. Libraries constitute only 1 in 5 Fedora packages. And not all libraries can be ported to Windows, by any means. Cross-compiling is not a mechanical task and requires many upstream changes. At the moment we have, through a large effort, cross compiled 27 libraries, and that includes big ones like Gtk and all its dependencies. 27 libraries, or even 27 x small 'n' libraries is NOT a secondary architecture and does not need a separate repository. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From paul at xelerance.com Wed Sep 10 15:43:22 2008 From: paul at xelerance.com (Paul Wouters) Date: Wed, 10 Sep 2008 11:43:22 -0400 (EDT) Subject: Fedora 8 and 9 updates re-enabled In-Reply-To: <1221028475.3388.132.camel@luminos.localdomain> References: <1221028475.3388.132.camel@luminos.localdomain> Message-ID: On Tue, 9 Sep 2008, Jesse Keating wrote: > Most users will simply need to apply the offered updates, and later > apply any further updates, and verify/import the new GPG key. > For more details and an FAQ, please see > https://fedoraproject.org/w/index.php?title=Enabling_new_signing_key One question I don't see answered is whether the upgrade system purges the trust on the old key from our systems after verification of the new key. Otherwise, some DNS or wifi hack in the future could lead me to a false update site using the old compromised key and my system would still install those updates. Paul From jspaleta at gmail.com Wed Sep 10 15:58:34 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 10 Sep 2008 07:58:34 -0800 Subject: make force-tag gone In-Reply-To: <1221048355.3285.32.camel@wicktop.localdomain> References: <1220955240.24928.69.camel@cookie.hadess.net> <3170f42f0809090945k597b6505s8c83fc853424a72e@mail.gmail.com> <604aa7910809091028n2db1f23agfa973695d66b9c06@mail.gmail.com> <1221048355.3285.32.camel@wicktop.localdomain> Message-ID: <604aa7910809100858h237b0b85u21e4c80140ee862d@mail.gmail.com> On Wed, Sep 10, 2008 at 4:05 AM, Christoph Wickert wrote: > Am Dienstag, den 09.09.2008, 09:28 -0800 schrieb Jeff Spaleta: >> On Tue, Sep 9, 2008 at 8:45 AM, Debarshi Ray wrote: >> > I have happily used 'TAG_OPTS=-F make tag' [1] on the rare occasions >> > that I needed force-tag. I might try to use local hacks to get around >> > it if people decided to try and block 'TAG_OPTS=-F make tag'. :-) >> >> We will ultimately need to also disable TAG_OPTS=-F as well > > -1 You are -1 to my statement? You find my statement factually incorrect? I'm really sick of the +1 and -1... this isn't a vote..this is a discussion. Here I'll reproduce my entire quote verbatim again: "We will ultimately need to also disable TAG_OPTS=-F as well if we want to make cvs tags immutable references that we can rely on to generate corresponding source on demand." IF we want to rely on tags for anything that has a legal implication... then they must be immutable...and even TAG_OPTS=-F must be disabled if it threatens the reliability of the tags. There's no in-between. If we are going to rely on cvs tags then they must be immutable. Education and the honor system is not enough. If we are going to rely on them for any number of auditing reasons they must become immutable. The statement has absolutely nothing to do with the utility of TAG_OPTS=-F in dealing with trivial changes. I'm sure both TAG_OPTS=-F and force tagging are useful to someone. Such utility is not an argument against immutability for the sake of auditability. Nor does my statement assume that cvs tags are the best way to create the source audit trail. But if we are going to attempt to rely on cvs tags... then they must be immutable. If TAG_OPTS=-F is a way to cause damages that immutability...it will have to be disabled. With force tagging off but TAG_OPTS=-F still available, its not clear to me what additional assurances on tag fidelity we have actually gained in the current situation. Half-measures, are no measures. -jef > > There are situations where "TAG_OPTS=-F" is really handy and I stumbled > over one last night while doing a review: On the topic of ExcludeArch > the review guidelines state: > >> Each architecture listed in ExcludeArch needs to have a bug filed in >> bugzilla, describing the reason that the package does not >> compile/build/work on that architecture. The bug number should then be >> placed in a comment, next to the corresponding ExcludeArch line. New >> packages will not have bugzilla entries during the review process, so >> they should put this description in the comment until the package is >> approved, then file the bugzilla entry, and replace the long >> explanation with the bug number. > > When I approve a package I expect this very special package (NVR) to be > imported into CVS. But for packages with ExcludeArch it means that the > review requester will have to > 1. file a bug after CVS admin procedure is done and the bugzilla > component was created, > 2. import the package (where it is automatically tagged), > 3. add the bug # to the ExcludeArch statement in the spec and > 4. then the bump the release only for a trivial change in the spec > that > * does not affect the functionality of the package nor of > the spec in any way > * is not visible to users at all and > * is not caused by the packagers inattention > > You see: There are situations where forcing a tag really makes sense. > Instead of banning "TAG_OPTS=-F" we should better educate our packagers > to not abuse it (accidentally). make tag should check if the same NVR > has already been build successfully in koji, but as long as this is not > implemented we should stick with forcing tags. > > Regards, > Christoph > > -- > 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 Wed Sep 10 15:59:53 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 10 Sep 2008 10:59:53 -0500 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: <20080910150226.GA14299@amd.home.annexia.org> References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> Message-ID: >>>>> "RWMJ" == Richard W M Jones writes: RWMJ> In reality this is not the case - we only wish to rebuild a few RWMJ> common libraries. I guess its important to know who the "we" is that you're speaking for, and whether you intend for that set of people to be limited in some way. Because I honestly don't see the difference between what you're proposing and, say, doing something like building KDE (and all of its attendant libraries and requirements) for Windows. Besides scale, of course. Sure, you have no intention of doing this, but who can say that nobody else here wants to do so? - J< From jonathan.underwood at gmail.com Wed Sep 10 16:00:52 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 10 Sep 2008 17:00:52 +0100 Subject: Fedora 8 and 9 updates re-enabled In-Reply-To: References: <1221028475.3388.132.camel@luminos.localdomain> Message-ID: <645d17210809100900s716a9796jd1282c1e2427b9da@mail.gmail.com> 2008/9/10 Paul Wouters : > On Tue, 9 Sep 2008, Jesse Keating wrote: > >> Most users will simply need to apply the offered updates, and later >> apply any further updates, and verify/import the new GPG key. > >> For more details and an FAQ, please see >> https://fedoraproject.org/w/index.php?title=Enabling_new_signing_key > > One question I don't see answered is whether the upgrade system purges > the trust on the old key from our systems after verification of the new > key. Otherwise, some DNS or wifi hack in the future could lead me to > a false update site using the old compromised key and my system would > still install those updates. > >From the original notification: "There will be further milestones in the future that involve redirection of release package repos to match that of updates, and removing of old gpg key from rpm trust." i.e. at this point the old key is not purged, but it will be in the future. Since the resigned repos of the fedora repo are not yet activated (only the updates-newkey is activated), the old key is still required to install software. That's my reading of the notice, anyhow. From nicolas.mailhot at laposte.net Wed Sep 10 16:02:58 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 10 Sep 2008 18:02:58 +0200 Subject: Feature Proposal: Use cases database In-Reply-To: <1221059648.17299.103.camel@hughsie-work> References: <1220991029.3782.47.camel@choeger6> <1221026638.2783.6.camel@hp6710.axianet.ch> <48C767E7.9040801@gmail.com> <1221059648.17299.103.camel@hughsie-work> Message-ID: <1221062578.21306.13.camel@rousalka.okg> Le mercredi 10 septembre 2008 ? 16:14 +0100, Richard Hughes a ?crit : > PackageKit already supports catalogs, which is pretty much what you > describe. > > Have a look here http://www.packagekit.org/pk-faq.html#catalogs and tell > me if that does what you need. Please work with the anaconda team so whatever resource list format you end up is shared and we don't have pk catalogs vs comps files. Really our comps file is nothing but the initial catalog restricted to the initial repository and it's quite disturbing they have ovelapping functionnality with different featuresets, syntax and limitations. Appart from that: On the positive side: PK catalogs allow specifying resources via something else than package names On the negative side 1. They use .ini syntax. Does not scale well, the fact comps file are .xml had helped set up things such as syntax verification easily 2. They are keyed on distro-id and architecture. Really this is an abysmal idea (as showed by the example asumption Rawhide is fedora 9.90). If you really want a multi-distro multi-release file at least separate cleanly the different bits in separate sections. 3. They have no structure you can't define groups with optionnal/default/etc bits. Anything not limited to a handful of packages will need this -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From tbrinkman at sbcglobal.net Wed Sep 10 16:07:23 2008 From: tbrinkman at sbcglobal.net (Tom) Date: Wed, 10 Sep 2008 11:07:23 -0500 Subject: Fedora 8 and 9 updates re-enabled In-Reply-To: <20080910145851.GA4334@redhat.com> References: <1221028475.3388.132.camel@luminos.localdomain> <200809100915.14102.tbrinkman@sbcglobal.net> <20080910145851.GA4334@redhat.com> Message-ID: <200809101107.23237.tbrinkman@sbcglobal.net> On Wednesday 10 September 2008 09:58:53 am Darryl L. Pierce wrote: > +++ Tom [10/09/08 09:15 -0500]: > > Worked flawlessly. F9 + updates, T61 laptop (all Intel) > > I hit a problem with updating yum-utils: it wants yum >= 3.2.19 > and the only version available is 3.2.17 in stable. These are currently installed, I don't remember if they were (new key) updates. I was mainly lookin for kde updates ~ $ frpm yum (frpm is an alias) yum-utils-1.1.14-4.fc9.noarch yum-3.2.17-2.fc9.noarch yum-metadata-parser-1.1.2-8.fc9.i386 yum-fastestmirror-1.1.16-1.fc9.noarch yum-packagekit-0.2.5-1.fc9.i386 FWIW, it was all auto on the CL. This mornin, d/l'd new key packages (5?, usin the old key), then 45 updates were installed with 'yumup' (alias yumup='yum --skip-broken upgrade') -- Tom Brinkman Corpus Christi, Texas From a.badger at gmail.com Wed Sep 10 16:07:58 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 10 Sep 2008 09:07:58 -0700 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: <20080910150226.GA14299@amd.home.annexia.org> References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> Message-ID: <48C7F0DE.7090402@gmail.com> Richard W.M. Jones wrote: > On Wed, Sep 10, 2008 at 10:03:07AM -0400, Josh Boyer wrote: >> Can you comment on what part of his draft you find objectionable? > > Specifically three things: > > (1) It imposes upon us the need to use a separate repository, which is > based on the false assumption that we will be rebuilding a substantial > proportion of all Fedora packages, like some sort of secondary > architecture. > Can you list some of the impacts a separate repository would impact MingW if #3 was changed to enabled by default? > In reality this is not the case - we only wish to rebuild a few common > libraries. Secondary architectures rebuild every package, including > applications, which we have no intention of doing even if it were > possible (which it isn't). > This is not a strong point. The people pushing MingW at the moment are not necessarily the same people that will be pushing it four years from now. If the whole aim for all time of the MingW SIG were to be able to develop the virt stack for Windows on Fedora, I'd be disappointed. Wooing developers to use Linux even when they have to build for Windows is a good thing in my eyes. > (2) "All packages must first be natively available in Fedora before > they can be in the MinGW repo" > > This is a considerable restriction. A useful Windows cross- > development environment must include packages like NSIS installer, GNU > gettext and PortableXDR, none of which would make sense as standalone > Fedora packages. > rpm -q getext gettext-0.17-4.fc9.i386 :-) I think that some discussion of this is warranted, though. It would be desirable to have a program that can run on Linux and generate Windows installers, for instance, but do we want to force our developers to do the work of adapting a Windows program like NSIS installer to run on Linux natively? > (3) "The repository definition(s) will be included in fedora-release > but will be disabled by default." > > But no reason is given why this extra repository should be disabled by > default. > There are reasons but I don't know if they are valid. When dep solving or downloading filelists.xml for resolving a filename dep, you will end up including MingW stuff unnecessarily which slows things down. But I don't know that that is sufficient reason to disable the repo by default. > Much of the draft states the obvious, like "All packages submitted for > MinGW repo must pass a formal review" and "any MinGW specific caveats > must be documented in the Fedora Packaging Guidelines". And there's > also the plain odd stuff like the requirement to use our own signing > key. > Maybe it's good to state the obvious then :-) Separate repo == separate key is pretty obvious to me. Especially since we're presently going so far as to make new keys for separate Fedora releases. > Anyway, I don't want to spend too long on this since the actual people > doing the work are trying to produce a proper, detailed technical > packaging draft here: > > https://fedoraproject.org/wiki/PackagingDrafts/MinGW > > No "1000 ft views" in here. > The thing is, the 1000 ft view is necessary too. Your stuff is great for the technical side which I'll get to work with in my role on the Packaging Committee. But Axel Thimm brought up the political and Fedora Project Policy side which Jef has been doing a good job of countering on FAB, the Board, and here. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From rjones at redhat.com Wed Sep 10 16:12:37 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 10 Sep 2008 17:12:37 +0100 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> Message-ID: <20080910161237.GA1535@amd.home.annexia.org> On Wed, Sep 10, 2008 at 10:59:53AM -0500, Jason L Tibbitts III wrote: > >>>>> "RWMJ" == Richard W M Jones writes: > > RWMJ> In reality this is not the case - we only wish to rebuild a few > RWMJ> common libraries. > > I guess its important to know who the "we" is that you're speaking > for, and whether you intend for that set of people to be limited in > some way. Certainly don't want to limit it. Our repository is public and open for anyone to download and contribute. Anyone with a FAS account can join the SIG. hg clone http://hg.et.redhat.com/misc/fedora-mingw--devel/ & read the README file. > Because I honestly don't see the difference between what > you're proposing and, say, doing something like building KDE (and all > of its attendant libraries and requirements) for Windows. Besides > scale, of course. Sure, you have no intention of doing this, but who > can say that nobody else here wants to do so? Well we've built the whole of Gtk which was about 10 packages[*]. I don't know how many library packages are in KDE. Remember: not the whole of KDE, just libraries. Should KDE have a separate repo? What about Perl with its hundreds of CPAN libraries? I can point to any big project in Fedora already and ask if it should have a separate repository. Rich. [*] Packages ported to MinGW so far: atk cairo fontconfig freetype gettext glib2 gnutls gtk2 iconv jasper libgcrypt libgpg-error libjpeg libpng libvirt libxml2 pango pixman portablexdr zlib -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From rjones at redhat.com Wed Sep 10 16:18:20 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 10 Sep 2008 17:18:20 +0100 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: <48C7F0DE.7090402@gmail.com> References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> <48C7F0DE.7090402@gmail.com> Message-ID: <20080910161820.GB1535@amd.home.annexia.org> On Wed, Sep 10, 2008 at 09:07:58AM -0700, Toshio Kuratomi wrote: > Can you list some of the impacts a separate repository would impact > MingW if #3 was changed to enabled by default? I'm not really hung up on the whole repository thing. I just think it's extra administrative make-work, and not just for me, but for hard-working rel-eng people. Other large projects seem to get along without needing to be confined to an extra repository. > > This is a considerable restriction. A useful Windows cross- > > development environment must include packages like NSIS installer, GNU > > gettext and PortableXDR, none of which would make sense as standalone > > Fedora packages. > > > > rpm -q getext > gettext-0.17-4.fc9.i386 > :-) The library is a part of glibc. On Windows we compile the library separately because there ain't no glibc ... > I think that some discussion of this is warranted, though. It would be > desirable to have a program that can run on Linux and generate Windows > installers, for instance, but do we want to force our developers to do > the work of adapting a Windows program like NSIS installer to run on > Linux natively? I've already done this. Not checked into the repo yet, but I'll try to check it in later today. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From jwboyer at gmail.com Wed Sep 10 16:29:53 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 10 Sep 2008 12:29:53 -0400 Subject: make force-tag gone In-Reply-To: <604aa7910809100858h237b0b85u21e4c80140ee862d@mail.gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <3170f42f0809090945k597b6505s8c83fc853424a72e@mail.gmail.com> <604aa7910809091028n2db1f23agfa973695d66b9c06@mail.gmail.com> <1221048355.3285.32.camel@wicktop.localdomain> <604aa7910809100858h237b0b85u21e4c80140ee862d@mail.gmail.com> Message-ID: <20080910162953.GC23069@yoda.jdub.homelinux.org> On Wed, Sep 10, 2008 at 07:58:34AM -0800, Jeff Spaleta wrote: >With force tagging off but TAG_OPTS=-F still available, its not clear >to me what additional assurances on tag fidelity we have actually >gained in the current situation. Half-measures, are no measures. Unless you disable it on the CVS server, users can still do 'cvs tag' manually. So removing TAG_OPTS=-F doesn't do anything either in terms of "assurances on tag fidelity." josh From jspaleta at gmail.com Wed Sep 10 16:42:04 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 10 Sep 2008 08:42:04 -0800 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: <48C7F0DE.7090402@gmail.com> References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> <48C7F0DE.7090402@gmail.com> Message-ID: <604aa7910809100942v1dfa81c7p52baebff76273bbf@mail.gmail.com> 2008/9/10 Toshio Kuratomi : > I think that some discussion of this is warranted, though. It would be > desirable to have a program that can run on Linux and generate Windows > installers, for instance, but do we want to force our developers to do > the work of adapting a Windows program like NSIS installer to run on > Linux natively? You could as a compromise include a clause to have FESCo rule on exceptions to this on a case by case basis. Though to do that, I think it would be best to narrowly defined what the purpose of the exceptions must serve... development aids... so that FESCo is only asked to make narrow exception judgements. If the exceptions criteria are more broadly defined as to allow end user applications you'll have a harder time down the road applying a consistent exceptions policy without getting wrapped up in debates over Fedora's purpose. I'd rather front load as much of the policy pain around these payloads with explicit policies now..then have reactionary policies on down the line. > When dep solving or downloading filelists.xml for resolving a filename > dep, you will end up including MingW stuff unnecessarily which slows > things down. But I don't know that that is sufficient reason to disable > the repo by default. As long as individual Spins are explicitly told to they are allowed to disable or enable and that we are not requiring them to keep it in the default state. I fully expect the Developer Spin to enable it. I fully expect the Desktop Spin to disable it. The default state only impacts the traditional installer scenario, and ultimately releng has the final decision as to whether they want this enabled or disabled the mingw repo by default. The suggested default has the least impact on releng. FESCo is certainly free to invert that suggestion so that the new repo is enabled by default. -jef From hughsient at gmail.com Wed Sep 10 16:41:03 2008 From: hughsient at gmail.com (Richard Hughes) Date: Wed, 10 Sep 2008 17:41:03 +0100 Subject: Feature Proposal: Use cases database In-Reply-To: <1221062578.21306.13.camel@rousalka.okg> References: <1220991029.3782.47.camel@choeger6> <1221026638.2783.6.camel@hp6710.axianet.ch> <48C767E7.9040801@gmail.com> <1221059648.17299.103.camel@hughsie-work> <1221062578.21306.13.camel@rousalka.okg> Message-ID: <1221064863.17299.134.camel@hughsie-work> On Wed, 2008-09-10 at 18:02 +0200, Nicolas Mailhot wrote: > Please work with the anaconda team so whatever resource list format you > end up is shared and we don't have pk catalogs vs comps files. I think they are two different formats for two different use cases. > Really our comps file is nothing but the initial catalog restricted to the > initial repository and it's quite disturbing they have ovelapping > functionnality with different featuresets, syntax and limitations. Comps has optional packages, groups, and quite a complex format. Could you write a comps file from memory without copying an existing one and modifying it? > On the positive side: PK catalogs allow specifying resources via > something else than package names Yes, as distros are usually spectacularly bad at deciding on package names (looking at you Debian). > On the negative side > 1. They use .ini syntax. Does not scale well, the fact comps file > are .xml had helped set up things such as syntax verification easily Right, I guess that's another key distinction. Users write catalog files. Users don't usually enjoy writing XML, unless they are sadist programmer types. I also don't intend on having super complex catalog files, so that don't need to scale. Typically they will be a three lines long at most. > 2. They are keyed on distro-id and architecture. Really this is an > abysmal idea (as showed by the example asumption Rawhide is fedora > 9.90). If you really want a multi-distro multi-release file at least > separate cleanly the different bits in separate sections. No, if you look at the file then you'll see as much stuff is common as possible. This means distros with sane naming policies (say, for instance Foresight) don't have to have "support added" by adding an extra section, they just work. distro_id's make a lot of sense when doing this sort of stuff. > 3. They have no structure you can't define groups with > optionnal/default/etc bits. Anything not limited to a handful of > packages will need this Why optional? If you need packages x, y and z to get started hacking on Xorg, why would you possibly need package a as well? If you possibly need it, include it in the main package list as catalogs are not designed for l33t hacker types who want to keep the number of programs installed to a minimum. I really do think it's two different file types and formats for two different use cases. Richard. From jspaleta at gmail.com Wed Sep 10 16:45:07 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 10 Sep 2008 08:45:07 -0800 Subject: make force-tag gone In-Reply-To: <20080910162953.GC23069@yoda.jdub.homelinux.org> References: <1220955240.24928.69.camel@cookie.hadess.net> <3170f42f0809090945k597b6505s8c83fc853424a72e@mail.gmail.com> <604aa7910809091028n2db1f23agfa973695d66b9c06@mail.gmail.com> <1221048355.3285.32.camel@wicktop.localdomain> <604aa7910809100858h237b0b85u21e4c80140ee862d@mail.gmail.com> <20080910162953.GC23069@yoda.jdub.homelinux.org> Message-ID: <604aa7910809100945w1747dbc0uf62535b77f07eb68@mail.gmail.com> On Wed, Sep 10, 2008 at 8:29 AM, Josh Boyer wrote: > Unless you disable it on the CVS server, users can still do 'cvs tag' > manually. So removing TAG_OPTS=-F doesn't do anything either in terms > of "assurances on tag fidelity." Even better... unless we disable it on the CVS server... what has removing force retagging actually bought us? -jef From michel.sylvan at gmail.com Wed Sep 10 16:46:27 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Wed, 10 Sep 2008 12:46:27 -0400 Subject: PackageKit 0.3.2 in rawhide In-Reply-To: <1221059373.17299.99.camel@hughsie-work> References: <1220953689.11468.6.camel@hughsie-work> <1221059373.17299.99.camel@hughsie-work> Message-ID: On Wed, Sep 10, 2008 at 11:09 AM, Richard Hughes wrote: > On Tue, 2008-09-09 at 10:48 +0100, Richard Hughes wrote: >> Please can you try out this new release and report any bugs you find >> either in bugzilla or by emailing the packagekit mailing list. The big >> new feature of this release is a new dispatcher, which should improve >> the interactivity of GUI applications as the yum instance is reused >> rather than re-loaded each time. There's also the usual set of bugfixes >> too. > > Also, there's a nice little test that I would like people to try: > > do "pkcon refresh" to make sure you're up to date > > Edit /etc/PackageKit/PackageKit.conf and enable the > RefreshCacheScanDesktopFiles and RefreshCacheUpdatePackageList keys. > > then do "pkcon refresh" and tell me roughly how long it takes before the > gpk-update-icon process (the box icon in the top right) stops reporting > searches. > > Enabling the two commands creates the package list which is used for > auto-completion in gpk-application, and it also enables the icons and > translations used in the various client tools. > > If it doesn't take ages (it's pretty CPU demanding) then I'll enable it > by default for F10. > On an Intel Core 2 Duo 2 GHz, real 0m23.878s user 0m0.017s sys 0m0.008s So it's not too bad. It was using almost 100% on one core for most of the time. -- Michel Salim http://hircus.jaiku.com/ From jkeating at redhat.com Wed Sep 10 16:51:08 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 10 Sep 2008 09:51:08 -0700 Subject: Boot speedup with readahead In-Reply-To: <1221060916.1927.212.camel@firewall.xsintricity.com> References: <48C2A272.5000504@redhat.com> <48C53B5E.3010500@redhat.com> <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <20080909072334.58be6bb3@infradead.org> <1220970586.987.70.camel@rosebud> <1221060916.1927.212.camel@firewall.xsintricity.com> Message-ID: <1221065468.3388.155.camel@luminos.localdomain> On Wed, 2008-09-10 at 11:35 -0400, Doug Ledford wrote: > > I'm fairly confident it'll be easier to do in yum. > > It doesn't matter where it's easy to do, what matters is it's done in > the right place. Core system infrastructure should never be a case of > done the easy way, always the right way. Ever heard of prototyping? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Wed Sep 10 17:12:13 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 10 Sep 2008 19:12:13 +0200 Subject: make chain-build doesn't work as advertised Message-ID: <20080910171213.GD3402@free.fr> Hello, I have tried to use colons in make chain-build, but it didn't worked. I kicked a build without the grouping, but maybe this could be investigated? $ make chain-build CHAIN='libdap bes:gdal:libnc-dap dap-server:dap-hdf4_handler:dap-netcdf_handler' cvs server: cannot find module `bes:gdal:libnc-dap' - ignored cvs [checkout aborted]: cannot expand modules make: *** [chain-build] Erreur 1 another possibility is that I misunderstood the syntax. -- Pat From skvidal at fedoraproject.org Wed Sep 10 17:13:37 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 10 Sep 2008 13:13:37 -0400 Subject: Feature Proposal: Use cases database In-Reply-To: <1221064863.17299.134.camel@hughsie-work> References: <1220991029.3782.47.camel@choeger6> <1221026638.2783.6.camel@hp6710.axianet.ch> <48C767E7.9040801@gmail.com> <1221059648.17299.103.camel@hughsie-work> <1221062578.21306.13.camel@rousalka.okg> <1221064863.17299.134.camel@hughsie-work> Message-ID: <1221066817.987.118.camel@rosebud> On Wed, 2008-09-10 at 17:41 +0100, Richard Hughes wrote: > On Wed, 2008-09-10 at 18:02 +0200, Nicolas Mailhot wrote: > > Please work with the anaconda team so whatever resource list format you > > end up is shared and we don't have pk catalogs vs comps files. > > I think they are two different formats for two different use cases. > > > Really our comps file is nothing but the initial catalog restricted to the > > initial repository and it's quite disturbing they have ovelapping > > functionnality with different featuresets, syntax and limitations. > > Comps has optional packages, groups, and quite a complex format. Could > you write a comps file from memory without copying an existing one and > modifying it? yes. > Right, I guess that's another key distinction. Users write catalog > files. Users don't usually enjoy writing XML, unless they are sadist > programmer types. I also don't intend on having super complex catalog > files, so that don't need to scale. Typically they will be a three lines > long at most. which is why we have a tool to create that xml file in yum-utils: yum-groups-manager.py -sv From dennis at ausil.us Wed Sep 10 17:16:47 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 10 Sep 2008 12:16:47 -0500 Subject: [Fwd: Package: wesnoth-1.4.5-1.fc10 Tag: dist-f10 Status: failed Built by: limb] In-Reply-To: <46628.198.175.55.5.1221061335.squirrel@mail.jcomserv.net> References: <46628.198.175.55.5.1221061335.squirrel@mail.jcomserv.net> Message-ID: <200809101216.51896.dennis@ausil.us> On Wednesday 10 September 2008 10:42:15 am Jon Ciesla wrote: > I've seen this exact error before, and if I resubmit and get a non-ppc > builder, it works for all arches. Is there anything I can to, save > re-submitting ad nauseum? > > inf ticket,perhaps? It failed to build on x86_64. what exactly is the issue? > ---------------------------- Original Message ---------------------------- > Subject: Package: wesnoth-1.4.5-1.fc10 Tag: dist-f10 Status: failed Built > by: limb > From: "Koji Build System" > Date: Wed, September 10, 2008 10:16 am > To: mikeb at fedoraproject.org > jkeating at fedoraproject.org > notting at fedoraproject.org > limb at fedoraproject.org > kanarip at fedoraproject.org > -------------------------------------------------------------------------- > > Package: wesnoth-1.4.5-1.fc10 > Tag: dist-f10 > Status: failed > Built by: limb > ID: 62521 > Started: Wed, 10 Sep 2008 15:10:39 UTC > Finished: Wed, 10 Sep 2008 15:16:15 UTC > Changelog: > * Tue Sep 09 2008 Jon Ciesla - 1.4.5-1 > - New upstream release. > > * Tue Aug 12 2008 Jon Ciesla - 1.4.4-1 > - New upstream release. > - Introduced patch fuzz workaround, will fix. > > * Thu May 08 2008 Jon Ciesla - 1.4.2-1 > - New upstream maintenance release. > > > > wesnoth-1.4.5-1.fc10 (62521) failed on xenbuilder4.fedora.phx.redhat.com > (noarch), x86-6.fedora.phx.redhat.com (x86_64), > x86-2.fedora.phx.redhat.com (i386): > BuildrootError: error building package (arch i386), mock exited with > status 250 > SRPMS: > wesnoth-1.4.5-1.fc10.src.rpm > > Failed tasks: > ------------- > > Task 817702 on xenbuilder4.fedora.phx.redhat.com > Task Type: build (dist-f10, devel:wesnoth-1_4_5-1_fc10) > > Task 817738 on x86-6.fedora.phx.redhat.com > Task Type: buildArch (wesnoth-1.4.5-1.fc10.src.rpm, x86_64) > logs: > http://koji.fedoraproject.org/koji/getfile?taskID=817738&name=build.log > http://koji.fedoraproject.org/koji/getfile?taskID=817738&name=root.log > http://koji.fedoraproject.org/koji/getfile?taskID=817738&name=state.log > > Task 817739 on x86-2.fedora.phx.redhat.com > Task Type: buildArch (wesnoth-1.4.5-1.fc10.src.rpm, i386) > logs: > http://koji.fedoraproject.org/koji/getfile?taskID=817739&name=build.log > http://koji.fedoraproject.org/koji/getfile?taskID=817739&name=root.log > http://koji.fedoraproject.org/koji/getfile?taskID=817739&name=state.log > > > Canceled tasks: > --------------- > > Task 817737 on ppc3.fedora.redhat.com > Task Type: buildArch (wesnoth-1.4.5-1.fc10.src.rpm, ppc) > logs: > http://koji.fedoraproject.org/koji/getfile?taskID=817737&name=build.log > http://koji.fedoraproject.org/koji/getfile?taskID=817737&name=root.log > http://koji.fedoraproject.org/koji/getfile?taskID=817737&name=state.log > > Task 817740 on ppc2.fedora.redhat.com > Task Type: buildArch (wesnoth-1.4.5-1.fc10.src.rpm, ppc64) > logs: > http://koji.fedoraproject.org/koji/getfile?taskID=817740&name=build.log > http://koji.fedoraproject.org/koji/getfile?taskID=817740&name=root.log > http://koji.fedoraproject.org/koji/getfile?taskID=817740&name=state.log > > > Closed tasks: > ------------- > > Task 817703 on x86-3.fedora.phx.redhat.com > Task Type: buildSRPMFromSCM (devel:wesnoth-1_4_5-1_fc10) > logs: > http://koji.fedoraproject.org/koji/getfile?taskID=817703&name=srpm.log > > > > Task Info: http://koji.fedoraproject.org/koji/taskinfo?taskID=817702 > Build Info: http://koji.fedoraproject.org/koji/buildinfo?buildID=62521 > > > -- > novus ordo absurdum -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From pertusus at free.fr Wed Sep 10 17:21:50 2008 From: pertusus at free.fr (Patrice Dumas) Date: Wed, 10 Sep 2008 19:21:50 +0200 Subject: Heads-up: libdap and libnc-dap updates In-Reply-To: <3090.71.208.78.10.1220624553.squirrel@www.cora.nwra.com> References: <20080905133702.GF26218@free.fr> <3090.71.208.78.10.1220624553.squirrel@www.cora.nwra.com> Message-ID: <20080910172150.GE3402@free.fr> On Fri, Sep 05, 2008 at 08:22:33AM -0600, orion at cora.nwra.com wrote: > > libnc-dap (shouldn't need work, right?): > grads/grads.spec:BuildRequires: libnc-dap-devel > ncl/ncl.spec:BuildRequires: g2clib-devel, libnc-dap-devel, librx-devel, > atlas-devel > nco/nco.spec:BuildRequires: netcdf-devel, libnc-dap-devel > octave-forge/octave-forge.spec:BuildRequires: ImageMagick-c++-devel > libnc-dap-devel pcre-devel gsl-devel > > > Seems pretty small, and you already seem to maintain many (most) of them. > How hard would it be to port to the new libdap and just skip the compat > package? I've CC'ed Balint who maintains gdal. I maintain ncl. I have kicked a build of libdap and dependent packages. Packages linked against libnc-dap will also need a rebuild, since they spuriously depend on libdap. With the new nc-dap-config using pkgconfig, this should be the last time, though. In # repoquery --whatrequires libdap.so.8 there are, among others: grads-0:1.9b4-23.fc9.i386 octave-forge-0:20080429-6.fc10.i386 ncl-0:5.0.0-11.fc9.i386 nco-0:3.9.5-1.fc10.i386 So they need to be rebuilt, but there is no reason why they should fail. I'll rebuild them if they are not rebuilt shortly after the new libnc-dap lands in the repository. -- Pat From dennis at ausil.us Wed Sep 10 17:23:00 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 10 Sep 2008 12:23:00 -0500 Subject: [Fwd: Package: wesnoth-1.4.5-1.fc10 Tag: dist-f10 Status: failed Built by: limb] In-Reply-To: <46628.198.175.55.5.1221061335.squirrel@mail.jcomserv.net> References: <46628.198.175.55.5.1221061335.squirrel@mail.jcomserv.net> Message-ID: <200809101223.03788.dennis@ausil.us> On Wednesday 10 September 2008 10:42:15 am Jon Ciesla wrote: > I've seen this exact error before, and if I resubmit and get a non-ppc > builder, it works for all arches. Is there anything I can to, save > re-submitting ad nauseum? > > inf ticket,perhaps? from build.log magic_file(ms, "/builddir/build/BUILDROOT/wesnoth-1.4.5-1.fc10.x86_64/usr/share/wesnoth/data/core/images/terrain/tent.png") failed: mode 100644 Macintosh HFS Extended version 61389 data (unclean) vasprintf failed (Invalid or incomplete multibyte or wide character) rpmbuild: rpmfc.c:1400: rpmfcClassify: Assertion `ftype != ((void *)0)' failed. there is either something wrong with that file. or there is a bug in rpm that cant deal with it. Its not a buildsystem issue. the builds that failed x86_64 and i386 did not have anything touching a ppc machine the srpm was build on a x86_64 machine. the ppc builds got cancelled as they were still running. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From limb at jcomserv.net Wed Sep 10 17:22:56 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 10 Sep 2008 12:22:56 -0500 (CDT) Subject: [Fwd: Package: wesnoth-1.4.5-1.fc10 Tag: dist-f10 Status: failed Built by: limb] In-Reply-To: <200809101216.51896.dennis@ausil.us> References: <46628.198.175.55.5.1221061335.squirrel@mail.jcomserv.net> <200809101216.51896.dennis@ausil.us> Message-ID: <22301.198.175.55.5.1221067376.squirrel@mail.jcomserv.net> > On Wednesday 10 September 2008 10:42:15 am Jon Ciesla wrote: >> I've seen this exact error before, and if I resubmit and get a non-ppc >> builder, it works for all arches. Is there anything I can to, save >> re-submitting ad nauseum? >> >> inf ticket,perhaps? > > It failed to build on x86_64. what exactly is the issue? End of build.log: magic_file(ms, "/builddir/build/BUILDROOT/wesnoth-1.4.5-1.fc10.x86_64/usr/share/wesnoth/data/core/images/terrain/tent.png") failed: mode 100644 Macintosh HFS Extended version 61389 data (unclean) vasprintf failed (Invalid or incomplete multibyte or wide character) rpmbuild: rpmfc.c:1400: rpmfcClassify: Assertion `ftype != ((void *)0)' failed. EXCEPTION: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/wesnoth.spec'] Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/mock/trace_decorator.py", line 70, in trace result = func(*args, **kw) File "/usr/lib/python2.4/site-packages/mock/util.py", line 315, in do raise mock.exception.Error, ("Command failed. See logs for output.\n # %s" % (command,), child.returncode) Error: Command failed. See logs for output. # ['bash', '--login', '-c', 'rpmbuild -bb --target x86_64 --nodeps builddir/build/SPECS/wesnoth.spec'] LEAVE do --> EXCEPTION RAISED >> ---------------------------- Original Message >> ---------------------------- >> Subject: Package: wesnoth-1.4.5-1.fc10 Tag: dist-f10 Status: failed >> Built >> by: limb >> From: "Koji Build System" >> Date: Wed, September 10, 2008 10:16 am >> To: mikeb at fedoraproject.org >> jkeating at fedoraproject.org >> notting at fedoraproject.org >> limb at fedoraproject.org >> kanarip at fedoraproject.org >> -------------------------------------------------------------------------- >> >> Package: wesnoth-1.4.5-1.fc10 >> Tag: dist-f10 >> Status: failed >> Built by: limb >> ID: 62521 >> Started: Wed, 10 Sep 2008 15:10:39 UTC >> Finished: Wed, 10 Sep 2008 15:16:15 UTC >> Changelog: >> * Tue Sep 09 2008 Jon Ciesla - 1.4.5-1 >> - New upstream release. >> >> * Tue Aug 12 2008 Jon Ciesla - 1.4.4-1 >> - New upstream release. >> - Introduced patch fuzz workaround, will fix. >> >> * Thu May 08 2008 Jon Ciesla - 1.4.2-1 >> - New upstream maintenance release. >> >> >> >> wesnoth-1.4.5-1.fc10 (62521) failed on xenbuilder4.fedora.phx.redhat.com >> (noarch), x86-6.fedora.phx.redhat.com (x86_64), >> x86-2.fedora.phx.redhat.com (i386): >> BuildrootError: error building package (arch i386), mock exited with >> status 250 >> SRPMS: >> wesnoth-1.4.5-1.fc10.src.rpm >> >> Failed tasks: >> ------------- >> >> Task 817702 on xenbuilder4.fedora.phx.redhat.com >> Task Type: build (dist-f10, devel:wesnoth-1_4_5-1_fc10) >> >> Task 817738 on x86-6.fedora.phx.redhat.com >> Task Type: buildArch (wesnoth-1.4.5-1.fc10.src.rpm, x86_64) >> logs: >> http://koji.fedoraproject.org/koji/getfile?taskID=817738&name=build.log >> http://koji.fedoraproject.org/koji/getfile?taskID=817738&name=root.log >> http://koji.fedoraproject.org/koji/getfile?taskID=817738&name=state.log >> >> Task 817739 on x86-2.fedora.phx.redhat.com >> Task Type: buildArch (wesnoth-1.4.5-1.fc10.src.rpm, i386) >> logs: >> http://koji.fedoraproject.org/koji/getfile?taskID=817739&name=build.log >> http://koji.fedoraproject.org/koji/getfile?taskID=817739&name=root.log >> http://koji.fedoraproject.org/koji/getfile?taskID=817739&name=state.log >> >> >> Canceled tasks: >> --------------- >> >> Task 817737 on ppc3.fedora.redhat.com >> Task Type: buildArch (wesnoth-1.4.5-1.fc10.src.rpm, ppc) >> logs: >> http://koji.fedoraproject.org/koji/getfile?taskID=817737&name=build.log >> http://koji.fedoraproject.org/koji/getfile?taskID=817737&name=root.log >> http://koji.fedoraproject.org/koji/getfile?taskID=817737&name=state.log >> >> Task 817740 on ppc2.fedora.redhat.com >> Task Type: buildArch (wesnoth-1.4.5-1.fc10.src.rpm, ppc64) >> logs: >> http://koji.fedoraproject.org/koji/getfile?taskID=817740&name=build.log >> http://koji.fedoraproject.org/koji/getfile?taskID=817740&name=root.log >> http://koji.fedoraproject.org/koji/getfile?taskID=817740&name=state.log >> >> >> Closed tasks: >> ------------- >> >> Task 817703 on x86-3.fedora.phx.redhat.com >> Task Type: buildSRPMFromSCM (devel:wesnoth-1_4_5-1_fc10) >> logs: >> http://koji.fedoraproject.org/koji/getfile?taskID=817703&name=srpm.log >> >> >> >> Task Info: http://koji.fedoraproject.org/koji/taskinfo?taskID=817702 >> Build Info: http://koji.fedoraproject.org/koji/buildinfo?buildID=62521 >> >> >> -- >> novus ordo absurdum > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From limb at jcomserv.net Wed Sep 10 17:27:08 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 10 Sep 2008 12:27:08 -0500 (CDT) Subject: [Fwd: Package: wesnoth-1.4.5-1.fc10 Tag: dist-f10 Status: failed Built by: limb] In-Reply-To: <200809101223.03788.dennis@ausil.us> References: <46628.198.175.55.5.1221061335.squirrel@mail.jcomserv.net> <200809101223.03788.dennis@ausil.us> Message-ID: <33322.198.175.55.5.1221067628.squirrel@mail.jcomserv.net> > On Wednesday 10 September 2008 10:42:15 am Jon Ciesla wrote: >> I've seen this exact error before, and if I resubmit and get a non-ppc >> builder, it works for all arches. Is there anything I can to, save >> re-submitting ad nauseum? >> >> inf ticket,perhaps? > > from build.log > > magic_file(ms, > "/builddir/build/BUILDROOT/wesnoth-1.4.5-1.fc10.x86_64/usr/share/wesnoth/data/core/images/terrain/tent.png") > failed: mode 100644 Macintosh HFS Extended version 61389 data (unclean) > vasprintf failed (Invalid or incomplete multibyte or wide character) > rpmbuild: rpmfc.c:1400: rpmfcClassify: Assertion `ftype != ((void *)0)' > failed. > > > there is either something wrong with that file. or there is a bug in rpm > that > cant deal with it. > > Its not a buildsystem issue. the builds that failed x86_64 and i386 did > not > have anything touching a ppc machine the srpm was build on a x86_64 > machine. > > the ppc builds got cancelled as they were still running. Ok. I thought as much. But why, then does it sometimes work? I did several builds of the 1.4.4 version, and some worked, with no changes to the source. 1.4.5 builds fine for me locally and in mock, on i386. I took a look at that file, and I nothing that distinguishes it from others. > Dennis > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From mw_triad at users.sourceforge.net Wed Sep 10 17:30:24 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 10 Sep 2008 12:30:24 -0500 Subject: Proposal: Split Fedora into sub-distributions In-Reply-To: <48C3B67E.6090301@gmail.com> References: <48C3B67E.6090301@gmail.com> Message-ID: Lyos Gemini Norezel wrote: > It's come to my attention lately that Fedora has, essensially, become > 'to big for it's britches' (as you old farts like to say). > I think the time has come for Fedora to be split up into subgroups: > [snip] That sounds like what we had a few releases back, with Core+Extras. I'm glad that's gone; less stuff available for initial install, more repos to manage... ick. > By the same token, a developer is not likely to use any gui tool that > does not provide some extreme 'ease of use' case (be honest, > how many of ya'll use vi or vim over gedit?). Um... I wouldn't say I use vim "over" kwrite, I just use whichever seems most convenient at the time and for the given task. IOW, while I use kwrite/kate/kdevelop a lot, I *also* use vim a lot. Besides, having a CLI-only text editor is IMO absolutely vital. You need it when logging in remotely over a slow connections, or when things go wrong with X (or when you need to do a few things between reboots* and are too lazy to fire up a desktop environment). (* e.g. one of these days I /really/ need to power down, swap in my dying laptop's HD, dump files off it, rinse, repeat, and put the other HD back; several reboots to fiddle with hardware. No reboots for software, of course, this *is* Linux after all :-).) > Fedora cannot (realistically) provide an ideal all-in-one distribution, > but it can, if ya'll are willing to try, provide multiple distributions > capable of providing ideal platforms to each group. Um... why not? That's *exactly* what I want out of Fedora; packages for just about anything I want :-). And, of course, my wants will be different from Joe's wants, or Tom's wants, or Sue's wants, or... -- Matthew Your eyes are weary from staring at the CRT. You feel sleepy. Notice how restful it is to watch the cursor blink. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise. -- Unknown (found at http://goldmark.org/jeff/stupid-disclaimers/fun.html) From lesmikesell at gmail.com Wed Sep 10 17:45:42 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 10 Sep 2008 12:45:42 -0500 Subject: Feature Proposal: Use cases database In-Reply-To: <1221059648.17299.103.camel@hughsie-work> References: <1220991029.3782.47.camel@choeger6> <1221026638.2783.6.camel@hp6710.axianet.ch> <48C767E7.9040801@gmail.com> <1221059648.17299.103.camel@hughsie-work> Message-ID: <48C807C6.8040902@gmail.com> Richard Hughes wrote: > On Wed, 2008-09-10 at 01:23 -0500, Les Mikesell wrote: >> Even better than talking about it would be creating the exact package >> lists that best enable a variety of use cases and a handy way of >> telling yum/packagekit to duplicate them on your machine. Then anyone >> else who needed to do the same thing would have a push-button choice. >> The idea should be that anyone could 'publish' their installed package >> set and describe why they think it is best for a particular use, and >> anyone who was convinced by their description/reputation, etc. could >> just clone that setup. > > PackageKit already supports catalogs, which is pretty much what you > describe. > > Have a look here http://www.packagekit.org/pk-faq.html#catalogs and tell > me if that does what you need. That's the easy half of the job. What I want is a tool where someone who has added 3rd party repositories, then added/removed any number of packages from any source can push a button and have the catalog generated that would reproduce that set of packages on any other machine starting with the same base distro version. Someone setting out to assemble the perfect set of tools for a job won't know if they've succeeded until after they've tried a lot of the wrong ones, and after they have their system working perfectly they probably won't start over to build a catalog. I want something that will deduce what's there and where it came from after the fact and does everything necessary to reproduce it. Ideally, I'd also like it to give you a choice of duplicating the exact versions of all the packages on the copy or floating them all to the current update. -- Les Mikesell lesmikesell at gmail.com From dennis at ausil.us Wed Sep 10 17:11:07 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 10 Sep 2008 12:11:07 -0500 Subject: Outage Notification - 2008-09-13 01:00 UTC Message-ID: <200809101211.12685.dennis@ausil.us> There will be an outage starting at Y2008-09-13 01:00 UTC, which will last approximately 1 hour. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2008-09-13 01:00 UTC' Affected Services: Buildsystem Unaffected Services: Websites Database CVS / Source Control DNS Mail Torrent Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/830 Reason for Outage: update koji to 1.2.6. it will enable us to turn garbage collection back on. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From a.badger at gmail.com Wed Sep 10 17:46:35 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 10 Sep 2008 10:46:35 -0700 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: <20080910161820.GB1535@amd.home.annexia.org> References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> <48C7F0DE.7090402@gmail.com> <20080910161820.GB1535@amd.home.annexia.org> Message-ID: <48C807FB.1030400@gmail.com> Richard W.M. Jones wrote: > On Wed, Sep 10, 2008 at 09:07:58AM -0700, Toshio Kuratomi wrote: >> Can you list some of the impacts a separate repository would impact >> MingW if #3 was changed to enabled by default? > > I'm not really hung up on the whole repository thing. I just think > it's extra administrative make-work, and not just for me, but for > hard-working rel-eng people. Other large projects seem to get along > without needing to be confined to an extra repository. > Thanks! There is extra work this way but Jef has been asking questions of the infrastructure team so it's something that people have evaluated. SO far there haven't been any problems raised, just the work of setting up the repos. >>> This is a considerable restriction. A useful Windows cross- >>> development environment must include packages like NSIS installer, GNU >>> gettext and PortableXDR, none of which would make sense as standalone >>> Fedora packages. >>> >> rpm -q getext >> gettext-0.17-4.fc9.i386 >> :-) > > The library is a part of glibc. On Windows we compile the library > separately because there ain't no glibc ... > We need some clarification in the policy about this. We have a gettext package in Fedora which contains the source code to build the library. But we disable building that specific library because glibc provides the functionality. Does this fit the "natively available" definition? Also, we still want to think about the generic case of which gettext and NSIS are examples... are there cases where we want to build something for a Windows environment using MingW where we would not desire an equivalent to run under Fedora? >> I think that some discussion of this is warranted, though. It would be >> desirable to have a program that can run on Linux and generate Windows >> installers, for instance, but do we want to force our developers to do >> the work of adapting a Windows program like NSIS installer to run on >> Linux natively? > > I've already done this. Not checked into the repo yet, but I'll try > to check it in later today. > Very nice! So, was this worthwhile? Is it something that the policy should codify for the generic case as a must do, something it should recommend doing, or something that it should stay altogether silent on? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From choeger at cs.tu-berlin.de Wed Sep 10 15:42:28 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 10 Sep 2008 17:42:28 +0200 Subject: Feature Proposal: Use cases database In-Reply-To: <1221059648.17299.103.camel@hughsie-work> References: <1220991029.3782.47.camel@choeger6> <1221026638.2783.6.camel@hp6710.axianet.ch> <48C767E7.9040801@gmail.com> <1221059648.17299.103.camel@hughsie-work> Message-ID: <1221061348.20090.1.camel@choeger6> Am Mittwoch, den 10.09.2008, 16:14 +0100 schrieb Richard Hughes: > On Wed, 2008-09-10 at 01:23 -0500, Les Mikesell wrote: > > Even better than talking about it would be creating the exact package > > lists that best enable a variety of use cases and a handy way of > > telling yum/packagekit to duplicate them on your machine. Then anyone > > else who needed to do the same thing would have a push-button choice. > > The idea should be that anyone could 'publish' their installed package > > set and describe why they think it is best for a particular use, and > > anyone who was convinced by their description/reputation, etc. could > > just clone that setup. > > PackageKit already supports catalogs, which is pretty much what you > describe. > > Have a look here http://www.packagekit.org/pk-faq.html#catalogs and tell > me if that does what you need. > > Richard. > > Hey, that sounds nice, as it fits perfectly into the "detect what if I have all that software installed" hole. I assume there is an 'just check' mode or the user is at least prompted, what parts are missing? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From walters at verbum.org Wed Sep 10 18:14:52 2008 From: walters at verbum.org (Colin Walters) Date: Wed, 10 Sep 2008 14:14:52 -0400 Subject: Boot speedup with readahead In-Reply-To: <1220995998.987.98.camel@rosebud> References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> Message-ID: On Tue, Sep 9, 2008 at 5:33 PM, Seth Vidal wrote: > > Here's a proof of concept plugin: > > http://skvidal.fedorapeople.org/misc/post-transaction-actions/ Ok cool - with one small fix to the plugin, this simple action: # Update the GTK+ icon cache when an icon is installed. # See: http://www.gtk.org/api/2.6/gtk/gtk-update-icon-cache.html /usr/share/icons/hicolor/*:any:gtk-update-icon-cache --quiet --force /usr/share/icons/hicolor seems to work. Now we can apply hundreds (thousand?) of patches of the following form, and probably in many cases entirely eliminate the single %post and %postun we've been copying and pasting around. It will be awesome. Index: hotssh.spec =================================================================== RCS file: /cvs/pkgs/rpms/hotssh/devel/hotssh.spec,v retrieving revision 1.1 diff -u -r1.1 hotssh.spec --- hotssh.spec 4 Aug 2008 19:01:32 -0000 1.1 +++ hotssh.spec 10 Sep 2008 18:14:01 -0000 @@ -4,7 +4,7 @@ Summary: Secure Shell Client Name: hotssh Version: 0.2.5 -Release: 1%{?dist} +Release: 2%{?dist} Source0: http://ftp.gnome.org/pub/GNOME/sources/hotssh/0.2/hotssh-%{version}.tar.bz2 License: GPLv2+ Group: User Interface/Desktops @@ -55,15 +55,10 @@ %dir %{python_sitelib}/hotssh/ %{python_sitelib}/hotssh/* -%post -touch --no-create %{_datadir}/icons/hicolor || : -%{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : - -%postun -touch --no-create %{_datadir}/icons/hicolor || : -%{_bindir}/gtk-update-icon-cache --quiet %{_datadir}/icons/hicolor || : - %changelog +* Wed Sep 10 2008 Colin Walters - 0.2.5-2 +- Delete icon cache bits, now in yum post transaction + * Fri Aug 01 2008 Colin Walters - 0.2.5-1 - New upstream From ville.skytta at iki.fi Wed Sep 10 18:15:18 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Wed, 10 Sep 2008 21:15:18 +0300 Subject: Boot speedup with readahead In-Reply-To: <1220909634.5554.78.camel@aglarond.local> References: <200809090024.04426.ville.skytta@iki.fi> <1220909634.5554.78.camel@aglarond.local> Message-ID: <200809102115.19471.ville.skytta@iki.fi> On Tuesday 09 September 2008, Jeremy Katz wrote: > It really boils down to the fact that > the Fedora package manager is yum. If users of other package managers > want to get their package manager to do similar things, we won't stop > them -- but trying to make everything work for such a small minority is > going to be increasingly difficult. It's not really about _making_ everything work everywhere I'm worried about. It's about people seemingly being very eager to _move_ existing, working functionality to yum or its plugins when someone finds a case that could be optimized by doing that, and dropping the existing generic functionality. "We won't stop them to make their favourite package manager to do similar things" does not really cover it at all well, it's closer to actively making things harder for them. Keeping other package manager (including plain rpm) users in mind does not mean that time should be invested to make everything work for them as well as the optimized case does for yum users. It's very much enough to just not drop the existing functionality and do the yum-optimized cases so that they play nice together with that. With the right mindset, I don't think that's going to be at all difficult to do in the vast majority of cases. Just a couple of examples from this thread: readahead and prelink updates/re-runs. Both are things that should Just Work out of the box even without any package manager (even rpm!) installed. If I misunderstood and the optimized cases are meant to be done so that they're just optimized for yum users, and the existing generic functionality is preserved for others, then no worries. Oh, and by the way, after trying to use yum for several distro versions, always eventually failing and switching to some alternative for various reasons until now, I haven't even tried other package managers than yum during the time I've used F-9. I still find myself disagreeing with some things and run into some bugs every now and then, but at this point I think overall it's the best depsolver I've used on Fedora. From skvidal at fedoraproject.org Wed Sep 10 18:16:17 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 10 Sep 2008 14:16:17 -0400 Subject: Boot speedup with readahead In-Reply-To: References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> Message-ID: <1221070577.987.120.camel@rosebud> On Wed, 2008-09-10 at 14:14 -0400, Colin Walters wrote: > On Tue, Sep 9, 2008 at 5:33 PM, Seth Vidal wrote: > > > > Here's a proof of concept plugin: > > > > http://skvidal.fedorapeople.org/misc/post-transaction-actions/ > > Ok cool - with one small fix to the plugin, this simple action: > Thank you, I've applied this to the one I uploaded above. So this seems to work - now the question is - should we push for this to go into rpm instead? -sv From behdad at behdad.org Wed Sep 10 18:19:53 2008 From: behdad at behdad.org (Behdad Esfahbod) Date: Wed, 10 Sep 2008 14:19:53 -0400 Subject: Boot speedup with readahead In-Reply-To: References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> Message-ID: <48C80FC9.5020902@behdad.org> Colin Walters wrote: > On Tue, Sep 9, 2008 at 5:33 PM, Seth Vidal wrote: >> Here's a proof of concept plugin: >> >> http://skvidal.fedorapeople.org/misc/post-transaction-actions/ > > Ok cool - with one small fix to the plugin, this simple action: > > # Update the GTK+ icon cache when an icon is installed. > # See: http://www.gtk.org/api/2.6/gtk/gtk-update-icon-cache.html > /usr/share/icons/hicolor/*:any:gtk-update-icon-cache --quiet --force > /usr/share/icons/hicolor Err, shouldn't update cache for the entire /usr/share/icons/hicolor. Just the directory changed... behdad From walters at verbum.org Wed Sep 10 18:23:30 2008 From: walters at verbum.org (Colin Walters) Date: Wed, 10 Sep 2008 14:23:30 -0400 Subject: Boot speedup with readahead In-Reply-To: <48C80FC9.5020902@behdad.org> References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <48C80FC9.5020902@behdad.org> Message-ID: On Wed, Sep 10, 2008 at 2:19 PM, Behdad Esfahbod wrote: > Colin Walters wrote: >> On Tue, Sep 9, 2008 at 5:33 PM, Seth Vidal wrote: >>> Here's a proof of concept plugin: >>> >>> http://skvidal.fedorapeople.org/misc/post-transaction-actions/ >> >> Ok cool - with one small fix to the plugin, this simple action: >> >> # Update the GTK+ icon cache when an icon is installed. >> # See: http://www.gtk.org/api/2.6/gtk/gtk-update-icon-cache.html >> /usr/share/icons/hicolor/*:any:gtk-update-icon-cache --quiet --force >> /usr/share/icons/hicolor > > Err, shouldn't update cache for the entire /usr/share/icons/hicolor. Just the > directory changed... Yeah, true. Perhaps the simplest way to do this is for the yum plugin to pass down the paths that matched? Another alternative would be for the the actions themselves to be Python code, and we just do the equivalent of: for plugin in plugin: plugin.run(package_name, changed_files_list) Something to figure out for when this gets pushed into RPM. From dledford at redhat.com Wed Sep 10 18:24:26 2008 From: dledford at redhat.com (Doug Ledford) Date: Wed, 10 Sep 2008 14:24:26 -0400 Subject: Boot speedup with readahead In-Reply-To: <1221070577.987.120.camel@rosebud> References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> Message-ID: <1221071066.1927.216.camel@firewall.xsintricity.com> On Wed, 2008-09-10 at 14:16 -0400, Seth Vidal wrote: > On Wed, 2008-09-10 at 14:14 -0400, Colin Walters wrote: > > On Tue, Sep 9, 2008 at 5:33 PM, Seth Vidal wrote: > > > > > > Here's a proof of concept plugin: > > > > > > http://skvidal.fedorapeople.org/misc/post-transaction-actions/ > > > > Ok cool - with one small fix to the plugin, this simple action: > > > > > Thank you, I've applied this to the one I uploaded above. > > So this seems to work - now the question is - should we push for this to > go into rpm instead? Absolutely. If it's going to exist at all, it needs to be in rpm. Otherwise this and the corresponding rpm changes fail the litmus test of "will my system be the same if I download the rpm(2) and run the transaction manually using rpm as it is if I use yum to install the rpm". Any time you fail that litmus test, you've put the code in the wrong place (at least IMO). -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From michel.sylvan at gmail.com Wed Sep 10 18:35:48 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Wed, 10 Sep 2008 14:35:48 -0400 Subject: Call for developers: rpmbuilder In-Reply-To: <48C7AC7D.9050908@pingoured.fr> References: <48C56121.4040605@redhat.com> <48C7AC7D.9050908@pingoured.fr> Message-ID: On Wed, Sep 10, 2008 at 7:16 AM, Pierre-Yves wrote: > Chris Evich wrote: >> >> Hi, >> >> Hopefully this is the right mailing list :) >> >> Project rpmbuilder aims to provide a template-based approach to packaging. >> In >> other words, it removes responsibility from developer to produce an RPM >> spec >> file the "right" way. Instead, the package developer just feeds in his >> project's particulars, and a template-driven engine puts the pieces >> together >> and spits out a "sane" RPM and SRPM. >> >> https://fedorahosted.org/rpmbuilder >> >> Given the recent discussions on dependency management, perhaps there is >> some >> interest in helping me develop this tool further. There's no mailing list >> yet, so if interested, please contact me directly. Thanks! > > Hi, > > Sorry for late reaction, but I have the feeling that your tool is quite > close to what I have been working on recently: > https://fedorahosted.org/r2spec/ > > But R2spec is oriented for R libraries whether your is general, maybe there > would be a way to integrate them... > There's also Brian O'Sullivan's cabal2rpm for Haskell cabal packages. Regards, -- Michel Salim http://hircus.jaiku.com/ From skvidal at fedoraproject.org Wed Sep 10 18:42:23 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 10 Sep 2008 14:42:23 -0400 Subject: Boot speedup with readahead In-Reply-To: <1221071066.1927.216.camel@firewall.xsintricity.com> References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <1221071066.1927.216.camel@firewall.xsintricity.com> Message-ID: <1221072143.987.125.camel@rosebud> On Wed, 2008-09-10 at 14:24 -0400, Doug Ledford wrote: > On Wed, 2008-09-10 at 14:16 -0400, Seth Vidal wrote: > > On Wed, 2008-09-10 at 14:14 -0400, Colin Walters wrote: > > > On Tue, Sep 9, 2008 at 5:33 PM, Seth Vidal wrote: > > > > > > > > Here's a proof of concept plugin: > > > > > > > > http://skvidal.fedorapeople.org/misc/post-transaction-actions/ > > > > > > Ok cool - with one small fix to the plugin, this simple action: > > > > > > > > > Thank you, I've applied this to the one I uploaded above. > > > > So this seems to work - now the question is - should we push for this to > > go into rpm instead? > > Absolutely. If it's going to exist at all, it needs to be in rpm. > Otherwise this and the corresponding rpm changes fail the litmus test of > "will my system be the same if I download the rpm(2) and run the > transaction manually using rpm as it is if I use yum to install the > rpm". Any time you fail that litmus test, you've put the code in the > wrong place (at least IMO). unless we bite the bullet and stop falling back on being able to do everything from the rpm interface. And just move forward with doing things from the yum-cli and/or yum modules. Using the rpm interface for rescue/recovery functionality only. -sv From rjones at redhat.com Wed Sep 10 18:50:41 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 10 Sep 2008 19:50:41 +0100 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: <48C807FB.1030400@gmail.com> References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> <48C7F0DE.7090402@gmail.com> <20080910161820.GB1535@amd.home.annexia.org> <48C807FB.1030400@gmail.com> Message-ID: <20080910185041.GA2878@amd.home.annexia.org> On Wed, Sep 10, 2008 at 10:46:35AM -0700, Toshio Kuratomi wrote: > Also, we still want to think about the generic case of which gettext and > NSIS are examples... are there cases where we want to build something > for a Windows environment using MingW where we would not desire an > equivalent to run under Fedora? PortableXDR is another example. XDR is provided by glibc in Fedora. Unlike gettext there isn't any Fedora equivalent package. I don't know if PortableXDR even compiles on Linux -- it might do, but that would only be by coincidence since it's primarily designed to provide XDR libraries for Windows & Mac OS X. In any case a Linux PortableXDR package would be pretty useless since it just duplicates functionality which is already in glibc. [NSIS] > Very nice! So, was this worthwhile? Is it something that the policy > should codify for the generic case as a must do, something it should > recommend doing, or something that it should stay altogether silent on? I'm not sure I understand the question, but: The native Fedora NSIS doesn't have any plugins enabled. If you need functionality contained in NSIS plugins then you have to run the Windows version under Wine (or actually in Windows). This isn't as much of a problem as it sounds since if Wine is installed then Windows executables "just work" without you needing to do anything special. I'm hoping that the native Fedora NSIS will be sufficient to build installers for the tools we care about, but I haven't actually tried it out yet. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From paul at city-fan.org Wed Sep 10 18:52:45 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 10 Sep 2008 19:52:45 +0100 Subject: make chain-build doesn't work as advertised In-Reply-To: <20080910171213.GD3402@free.fr> References: <20080910171213.GD3402@free.fr> Message-ID: <20080910195245.1e743cf6@metropolis.intra.city-fan.org> On Wed, 10 Sep 2008 19:12:13 +0200 Patrice Dumas wrote: > Hello, > > I have tried to use colons in make chain-build, but it didn't worked. > I kicked a build without the grouping, but maybe this could be > investigated? > > $ make chain-build CHAIN='libdap bes:gdal:libnc-dap > dap-server:dap-hdf4_handler:dap-netcdf_handler' cvs server: cannot > find module `bes:gdal:libnc-dap' - ignored cvs [checkout aborted]: > cannot expand modules make: *** [chain-build] Erreur 1 > > > another possibility is that I misunderstood the syntax. Try putting spaces around the colons (both sides). Paul. From email.ahmedkamal at googlemail.com Wed Sep 10 18:55:49 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Wed, 10 Sep 2008 20:55:49 +0200 Subject: Fedora 8 and 9 updates re-enabled In-Reply-To: <200809101107.23237.tbrinkman@sbcglobal.net> References: <1221028475.3388.132.camel@luminos.localdomain> <200809100915.14102.tbrinkman@sbcglobal.net> <20080910145851.GA4334@redhat.com> <200809101107.23237.tbrinkman@sbcglobal.net> Message-ID: <3da3b5b40809101155t42d8a62mc6353e52aa41bd40@mail.gmail.com> Um, install sshd is broken. Is this a known issue too ? yum install openssh-server Loaded plugins: refresh-packagekit Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check ---> Package openssh-server.i386 0:5.1p1-2.fc9 set to be updated --> Processing Dependency: pam >= 1.0.1-3 for package: openssh-server --> Finished Dependency Resolution openssh-server-5.1p1-2.fc9.i386 from updates-newkey has depsolving problems --> Missing Dependency: pam >= 1.0.1-3 is needed by package openssh-server-5.1p1-2.fc9.i386 (updates-newkey) Error: Missing Dependency: pam >= 1.0.1-3 is needed by package openssh-server-5.1p1-2.fc9.i386 (updates-newkey) On Wed, Sep 10, 2008 at 6:07 PM, Tom wrote: > On Wednesday 10 September 2008 09:58:53 am Darryl L. Pierce wrote: > > +++ Tom [10/09/08 09:15 -0500]: > > > Worked flawlessly. F9 + updates, T61 laptop (all Intel) > > > > I hit a problem with updating yum-utils: it wants yum >= 3.2.19 > > and the only version available is 3.2.17 in stable. > > These are currently installed, I don't remember if they were (new > key) updates. I was mainly lookin for kde updates > > ~ $ frpm yum (frpm is an alias) > yum-utils-1.1.14-4.fc9.noarch > yum-3.2.17-2.fc9.noarch > yum-metadata-parser-1.1.2-8.fc9.i386 > yum-fastestmirror-1.1.16-1.fc9.noarch > yum-packagekit-0.2.5-1.fc9.i386 > > FWIW, it was all auto on the CL. This mornin, d/l'd new key > packages (5?, usin the old key), then 45 updates were installed > with 'yumup' (alias yumup='yum --skip-broken upgrade') > -- > Tom Brinkman Corpus Christi, Texas > > -- > 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 cweyl at alumni.drew.edu Wed Sep 10 18:56:52 2008 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 10 Sep 2008 11:56:52 -0700 Subject: Call for developers: rpmbuilder In-Reply-To: References: <48C56121.4040605@redhat.com> <48C7AC7D.9050908@pingoured.fr> Message-ID: <7dd7ab490809101156h12bce423ma579c4d018ec52dd@mail.gmail.com> On Wed, Sep 10, 2008 at 11:35 AM, Michel Salim wrote: > On Wed, Sep 10, 2008 at 7:16 AM, Pierre-Yves wrote: >> Sorry for late reaction, but I have the feeling that your tool is quite >> close to what I have been working on recently: >> https://fedorahosted.org/r2spec/ >> >> But R2spec is oriented for R libraries whether your is general, maybe there >> would be a way to integrate them... >> > There's also Brian O'Sullivan's cabal2rpm for Haskell cabal packages. Not to forget Steve's most excellent cpanspec tool, as well as the newer CPANPLUS::Dist::Fedora, both of which generate Fedora-compliant specs for perl dists. -Chris -- Chris Weyl Ex astris, scientia From Jochen at herr-schmitt.de Wed Sep 10 19:01:06 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 10 Sep 2008 21:01:06 +0200 Subject: Unexpected redirection of compiler output to /dev/null on koji Message-ID: <48C81972.8010202@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo, Unfortunately, I have to find out, the a new package which I have imported into cvs failed on koji. After I have a look on the build log, I have to recorgnised the unexpected inserteion of redirection of the compiler output to /dev/null. You can find the build log on http://koji.fedoraproject.org/koji/getfile?taskID=818062&name=build.log I will be happy for any hint to solve this issue, becouse the redirection of the compiler output to /dev/null make it deficuilt to find the reseaon why this build failed. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjIGU0ACgkQT2AHK6txfgwt/gCffHZxjWZvEDJcWuCu91b536Rr 1BcAn1o0loMXkbCockh/LxREMyCOWQIF =HJnM -----END PGP SIGNATURE----- From dennis at ausil.us Wed Sep 10 19:15:47 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 10 Sep 2008 14:15:47 -0500 Subject: [Fwd: Package: wesnoth-1.4.5-1.fc10 Tag: dist-f10 Status: failed Built by: limb] In-Reply-To: <33322.198.175.55.5.1221067628.squirrel@mail.jcomserv.net> References: <46628.198.175.55.5.1221061335.squirrel@mail.jcomserv.net> <200809101223.03788.dennis@ausil.us> <33322.198.175.55.5.1221067628.squirrel@mail.jcomserv.net> Message-ID: <200809101415.47895.dennis@ausil.us> On Wednesday 10 September 2008 12:27:08 pm Jon Ciesla wrote: > > On Wednesday 10 September 2008 10:42:15 am Jon Ciesla wrote: > >> I've seen this exact error before, and if I resubmit and get a non-ppc > >> builder, it works for all arches. Is there anything I can to, save > >> re-submitting ad nauseum? > >> > >> inf ticket,perhaps? > > > > from build.log > > > > magic_file(ms, > > "/builddir/build/BUILDROOT/wesnoth-1.4.5-1.fc10.x86_64/usr/share/wesnoth/ > >data/core/images/terrain/tent.png") failed: mode 100644 Macintosh HFS > > Extended version 61389 data (unclean) vasprintf failed (Invalid or > > incomplete multibyte or wide character) rpmbuild: rpmfc.c:1400: > > rpmfcClassify: Assertion `ftype != ((void *)0)' failed. > > > > > > there is either something wrong with that file. or there is a bug in rpm > > that > > cant deal with it. > > > > Its not a buildsystem issue. the builds that failed x86_64 and i386 did > > not > > have anything touching a ppc machine the srpm was build on a x86_64 > > machine. > > > > the ppc builds got cancelled as they were still running. > > Ok. I thought as much. But why, then does it sometimes work? I did > several builds of the 1.4.4 version, and some worked, with no changes to > the source. 1.4.5 builds fine for me locally and in mock, on i386. I > took a look at that file, and I nothing that distinguishes it from others. Building locally in mock on F-9 it builds ok. building in rawhide it does not. it is quite possible that you have hit a bug in the newer RPM Dennis From paul at city-fan.org Wed Sep 10 19:18:24 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 10 Sep 2008 20:18:24 +0100 Subject: make chain-build doesn't work as advertised In-Reply-To: <20080910195245.1e743cf6@metropolis.intra.city-fan.org> References: <20080910171213.GD3402@free.fr> <20080910195245.1e743cf6@metropolis.intra.city-fan.org> Message-ID: <20080910201824.4ffe19ad@metropolis.intra.city-fan.org> On Wed, 10 Sep 2008 19:52:45 +0100 Paul Howarth wrote: > On Wed, 10 Sep 2008 19:12:13 +0200 > Patrice Dumas wrote: > > > Hello, > > > > I have tried to use colons in make chain-build, but it didn't > > worked. I kicked a build without the grouping, but maybe this could > > be investigated? > > > > $ make chain-build CHAIN='libdap bes:gdal:libnc-dap > > dap-server:dap-hdf4_handler:dap-netcdf_handler' cvs server: cannot > > find module `bes:gdal:libnc-dap' - ignored cvs [checkout aborted]: > > cannot expand modules make: *** [chain-build] Erreur 1 > > > > > > another possibility is that I misunderstood the syntax. > > Try putting spaces around the colons (both sides). And in cases where you're using colons, you almost certainly want a colon at the end too: $ make chain-build CHAIN='libdap bes : gdal : libnc-dap dap-server : dap-hdf4_handler : dap-netcdf_handler :' Paul. From limb at jcomserv.net Wed Sep 10 19:24:02 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 10 Sep 2008 14:24:02 -0500 (CDT) Subject: [Fwd: Package: wesnoth-1.4.5-1.fc10 Tag: dist-f10 Status: failed Built by: limb] In-Reply-To: <200809101415.47895.dennis@ausil.us> References: <46628.198.175.55.5.1221061335.squirrel@mail.jcomserv.net> <200809101223.03788.dennis@ausil.us> <33322.198.175.55.5.1221067628.squirrel@mail.jcomserv.net> <200809101415.47895.dennis@ausil.us> Message-ID: <6155.198.175.55.5.1221074642.squirrel@mail.jcomserv.net> > On Wednesday 10 September 2008 12:27:08 pm Jon Ciesla wrote: >> > On Wednesday 10 September 2008 10:42:15 am Jon Ciesla wrote: >> >> I've seen this exact error before, and if I resubmit and get a >> non-ppc >> >> builder, it works for all arches. Is there anything I can to, save >> >> re-submitting ad nauseum? >> >> >> >> inf ticket,perhaps? >> > >> > from build.log >> > >> > magic_file(ms, >> > "/builddir/build/BUILDROOT/wesnoth-1.4.5-1.fc10.x86_64/usr/share/wesnoth/ >> >data/core/images/terrain/tent.png") failed: mode 100644 Macintosh HFS >> > Extended version 61389 data (unclean) vasprintf failed (Invalid or >> > incomplete multibyte or wide character) rpmbuild: rpmfc.c:1400: >> > rpmfcClassify: Assertion `ftype != ((void *)0)' failed. >> > >> > >> > there is either something wrong with that file. or there is a bug in >> rpm >> > that >> > cant deal with it. >> > >> > Its not a buildsystem issue. the builds that failed x86_64 and i386 >> did >> > not >> > have anything touching a ppc machine the srpm was build on a x86_64 >> > machine. >> > >> > the ppc builds got cancelled as they were still running. >> >> Ok. I thought as much. But why, then does it sometimes work? I did >> several builds of the 1.4.4 version, and some worked, with no changes to >> the source. 1.4.5 builds fine for me locally and in mock, on i386. I >> took a look at that file, and I nothing that distinguishes it from >> others. > Building locally in mock on F-9 it builds ok. building in rawhide it does > not. it is quite possible that you have hit a bug in the newer RPM > I'll try my own mock build. If it fails the same way, I'll file a bug against rpm. > Dennis > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From jakub at redhat.com Wed Sep 10 19:33:47 2008 From: jakub at redhat.com (Jakub Jelinek) Date: Wed, 10 Sep 2008 15:33:47 -0400 Subject: Unexpected redirection of compiler output to /dev/null on koji In-Reply-To: <48C81972.8010202@herr-schmitt.de> References: <48C81972.8010202@herr-schmitt.de> Message-ID: <20080910193347.GF25977@hs20-bc2-1.build.redhat.com> On Wed, Sep 10, 2008 at 09:01:06PM +0200, Jochen Schmitt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Unfortunately, I have to find out, the a new package which I have > imported into cvs failed > on koji. > > After I have a look on the build log, I have to recorgnised the > unexpected inserteion of > redirection of the compiler output to /dev/null. You are using libtool and libtool's default behavior is only show compiler messages from -fPIC compilation and suppress them in the non-pic one. You can pass -no-suppress to libtool to avoid this suppression. Jakub From mschwendt at gmail.com Wed Sep 10 19:32:05 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 10 Sep 2008 21:32:05 +0200 Subject: xmms heads up In-Reply-To: <20080903171001.b9a403f7.mschwendt@gmail.com> References: <1220394346.7539.3.camel@PB3.Linux> <20080903171001.b9a403f7.mschwendt@gmail.com> Message-ID: <20080910213205.011643cd.mschwendt@gmail.com> On Wed, 3 Sep 2008 17:10:01 +0200, Michael Schwendt wrote: > On Tue, 02 Sep 2008 23:25:46 +0100, Paul wrote: > > > I've just built xmms-1.2.11-20071117cvs for rawhide. It should hit > > whenever there is a rawhide push (god knows when that will be ;-p). > > You've reverted the licence fix in the spec file and removed also > the corresponding changelog entry. Why? Ping. Between xmms-1_2_10-39_fc10 and xmms-1_2_11-1_20071117cvs_fc10 you reverted Jason's licence change and %changelog entry in xmms.spec. You changed the licence field from GPLv2+ to GPLv2, while the source files say that GPLv2+ would be correct. Your changelog entry says Alter license which is not verbose enough in this case. -- Michael Schwendt Fedora release 8 (Werewolf) - Linux 2.6.26.3-12.fc8 loadavg: 1.80 1.87 1.77 From paul at all-the-johnsons.co.uk Wed Sep 10 19:44:56 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Wed, 10 Sep 2008 20:44:56 +0100 Subject: xmms heads up In-Reply-To: <20080910213205.011643cd.mschwendt@gmail.com> References: <1220394346.7539.3.camel@PB3.Linux> <20080903171001.b9a403f7.mschwendt@gmail.com> <20080910213205.011643cd.mschwendt@gmail.com> Message-ID: <1221075896.28606.4.camel@PB3.Linux> Hi, > Between xmms-1_2_10-39_fc10 and xmms-1_2_11-1_20071117cvs_fc10 you > reverted Jason's licence change and %changelog entry in xmms.spec. > > You changed the licence field from GPLv2+ to GPLv2, while the source > files say that GPLv2+ would be correct. Fixed. Sorry about that, not sure why the reversion occured! TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pavel.lisy at gmail.com Wed Sep 10 19:49:22 2008 From: pavel.lisy at gmail.com (Pavel Lisy) Date: Wed, 10 Sep 2008 21:49:22 +0200 Subject: Looking for co-maintainers In-Reply-To: <1220953731.8385.7.camel@localhost.localdomain> References: <1220953731.8385.7.camel@localhost.localdomain> Message-ID: <1221076162.5691.9.camel@parents-desktop.lisilan.cz> Martin Sourada p??e v ?t 09. 09. 2008 v 11:48 +0200: > Hi, > > I heard it's a good practice to have at least two people working on one > packages (so that e.g. one does not have time to solve some critical > issue due to being on vacation, the others maintainer steps in and solve > it). Therefore I am looking for co-maintainer(s) for these packages: > > gxine [all Fedoras, EPEL5, originally requested also EPEL4, but there > are missing deps (namely xine-lib)] > xine-plugin [all Fedoras] > subtitleeditor [all Fedoras] > > Any one willing to co-maintain some of those? I'am interesting in "subtitleeditor" so I can help. You can write directly to me (in czech will be better :-) Pavel -- Pavel Lisy From Jochen at herr-schmitt.de Wed Sep 10 19:58:05 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Wed, 10 Sep 2008 21:58:05 +0200 Subject: Unexpected redirection of compiler output to /dev/null on koji In-Reply-To: <20080910193347.GF25977@hs20-bc2-1.build.redhat.com> References: <48C81972.8010202@herr-schmitt.de> <20080910193347.GF25977@hs20-bc2-1.build.redhat.com> Message-ID: <48C826CD.50004@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jakub Jelinek schrieb: > On Wed, Sep 10, 2008 at 09:01:06PM +0200, Jochen Schmitt wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> Unfortunately, I have to find out, the a new package which I have >> imported into cvs failed on koji. >> >> After I have a look on the build log, I have to recorgnised the >> unexpected inserteion of redirection of the compiler output to >> /dev/null. > > You are using libtool and libtool's default behavior is only show > compiler messages from -fPIC compilation and suppress them in the > non-pic one. You can pass -no-suppress to libtool to avoid this > suppression. > > Tank you for your response, but you explaination seem not to be the whole true. It will be nice, if you can explain me why the compiler output was redirected to /dev/null in the following example: if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. - -I. -I.. -I.. -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 - -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 - -mtune=generic -fPIC -finline-functions -fsigned-char -Wall - -Wwrite-strings -Wmissing-prototypes -Wno-format-y2k -MT libcob_la-numeric.lo -MD -MP -MF ".deps/libcob_la-numeric.Tpo" -c -o libcob_la-numeric.lo `test -f 'numeric.c' || echo './'`numeric.c; \ then mv -f ".deps/libcob_la-numeric.Tpo" ".deps/libcob_la-numeric.Plo"; else rm -f ".deps/libcob_la-numeric.Tpo"; exit 1; fi gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -O2 -g -pipe -Wall - -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector - --param=ssp-buffer-size=4 -m64 -mtune=generic -fPIC -finline-functions - -fsigned-char -Wall -Wwrite-strings -Wmissing-prototypes - -Wno-format-y2k -MT libcob_la-strings.lo -MD -MP -MF .deps/libcob_la-strings.Tpo -c strings.c -o libcob_la-strings.o > /dev/null 2>&1 gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -O2 -g -pipe -Wall - -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector - --param=ssp-buffer-size=4 -m64 -mtune=generic -fPIC -finline-functions - -fsigned-char -Wall -Wwrite-strings -Wmissing-prototypes - -Wno-format-y2k -MT libcob_la-common.lo -MD -MP -MF .deps/libcob_la-common.Tpo -c common.c -o libcob_la-common.o>/dev/null 2>&1 Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjIJsMACgkQT2AHK6txfgz0BQCeIF65BEaVu5f14mkmnDuAFeiH aWUAnAlbXE/G1WI+GWfGeU+TtGHVs6y6 =3QNT -----END PGP SIGNATURE----- From konrad at tylerc.org Wed Sep 10 20:04:52 2008 From: konrad at tylerc.org (Conrad Meyer) Date: Wed, 10 Sep 2008 13:04:52 -0700 Subject: Call for developers: rpmbuilder In-Reply-To: <7dd7ab490809101156h12bce423ma579c4d018ec52dd@mail.gmail.com> References: <48C56121.4040605@redhat.com> <7dd7ab490809101156h12bce423ma579c4d018ec52dd@mail.gmail.com> Message-ID: <200809101304.52632.konrad@tylerc.org> Quoth Chris Weyl: > On Wed, Sep 10, 2008 at 11:35 AM, Michel Salim wrote: > > On Wed, Sep 10, 2008 at 7:16 AM, Pierre-Yves wrote: > >> Sorry for late reaction, but I have the feeling that your tool is quite > >> close to what I have been working on recently: > >> https://fedorahosted.org/r2spec/ > >> > >> But R2spec is oriented for R libraries whether your is general, maybe there > >> would be a way to integrate them... > >> > > There's also Brian O'Sullivan's cabal2rpm for Haskell cabal packages. > > Not to forget Steve's most excellent cpanspec tool, as well as the > newer CPANPLUS::Dist::Fedora, both of which generate Fedora-compliant > specs for perl dists. > > -Chris > -- > Chris Weyl > Ex astris, scientia And I think someone in the Ruby camp has made a gem2spec if I'm not mistaken. -- Conrad Meyer From michael at laptop.org Wed Sep 10 20:16:37 2008 From: michael at laptop.org (Michael Stone) Date: Wed, 10 Sep 2008 16:16:37 -0400 Subject: Boot speedup with readahead In-Reply-To: <1221072143.987.125.camel@rosebud> References: <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <1221071066.1927.216.camel@firewall.xsintricity.com> <1221072143.987.125.camel@rosebud> Message-ID: <20080910201637.GR18073@didacte.laptop.org> >And just move forward with doing things from the yum-cli and/or yum >modules. > >Using the rpm interface for rescue/recovery functionality only. Please remember that people use packaging tools for more than simple system maintenance; for example, I use an image-builder which is now based on smart (even though it was originally based on yum) because smart is more convenient for some of my programmatic use cases [1]. Basically, diversity in this area is a Good Thing, in my humble opinion. Please don't impair it without a really good reason when alternatives exist (such as pushing this functionality into RPM). Thanks, Michael [1]: In particular, because of its programmable mirror system, priority system, support for alternate package formats, built-in ability to download packages, builtin ability to save URLs for the packages it is going to download, strictness options, etc.) From jspaleta at gmail.com Wed Sep 10 20:19:51 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 10 Sep 2008 12:19:51 -0800 Subject: Boot speedup with readahead In-Reply-To: <20080910201637.GR18073@didacte.laptop.org> References: <1220887636.5554.37.camel@aglarond.local> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <1221071066.1927.216.camel@firewall.xsintricity.com> <1221072143.987.125.camel@rosebud> <20080910201637.GR18073@didacte.laptop.org> Message-ID: <604aa7910809101319q40a4c654m72b53d5e1530a043@mail.gmail.com> On Wed, Sep 10, 2008 at 12:16 PM, Michael Stone wrote: > [1]: In particular, because of its programmable mirror system, priority > system, support for alternate package formats, built-in ability to > download packages, builtin ability to save URLs for the packages it is > going to download, strictness options, etc.) Hey maybe we should push some of those features down the the rpm layer too. -jef From skvidal at fedoraproject.org Wed Sep 10 20:46:27 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 10 Sep 2008 16:46:27 -0400 Subject: Boot speedup with readahead In-Reply-To: <20080910201637.GR18073@didacte.laptop.org> References: <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <1221071066.1927.216.camel@firewall.xsintricity.com> <1221072143.987.125.camel@rosebud> <20080910201637.GR18073@didacte.laptop.org> Message-ID: <1221079587.987.137.camel@rosebud> On Wed, 2008-09-10 at 16:16 -0400, Michael Stone wrote: > Please remember that people use packaging tools for more than simple > system maintenance; for example, I use an image-builder which is now > based on smart (even though it was originally based on yum) because > smart is more convenient for some of my programmatic use cases [1]. I think I'd like to look at those use cases in more detail. If there's anything that can be done in smart's interface that isn't doable in via the yum python modules I'd be curious to know about it (excluding sudoku b/c I just don't care) > [1]: In particular, > because of its programmable mirror system, - how much more programmable do you want than being able to modify the mirrorlist directly per repo? > priority system, available in a yum plugin - though questionably useful to begin with. > support for alternate package formats, not sure how this helps fedora. > built-in ability to download packages, yum can clearly download pkgs - not sure why it being built in rather than a plugin matters though. Also you can download directly if you're using the yum modules. > builtin ability to save URLs for the packages it is going to download, see above. > strictness options, etc.) strictness of what? explain a bit more about the features you're looking for and I'll see what I can do to help. -sv From martin.sourada at gmail.com Wed Sep 10 20:52:06 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Wed, 10 Sep 2008 22:52:06 +0200 Subject: Need quick package review for F10 Round 3 themes Message-ID: <1221079926.3086.18.camel@pc-notebook> Hi, As per request from Mo [1] I've packaged Round 3 themes for Fedora. The most finished one is Solar, so it has the traditional 4:3 and 16:9 wallpaper with daylight changes, Gears have two different wide-screen wallpapers, InvinXble has one wide-screen wallpaper and Neon has one 4:3 wallpaper. In order to get it to F10 beta, we need to have it in repos as soon as possible, thus request for fast review: https://bugzilla.redhat.com/show_bug.cgi?id=461818 https://bugzilla.redhat.com/show_bug.cgi?id=461819 https://bugzilla.redhat.com/show_bug.cgi?id=461820 https://bugzilla.redhat.com/show_bug.cgi?id=461821 Thanks, Martin [1] https://www.redhat.com/archives/fedora-art-list/2008-September/msg00123.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From lmacken at redhat.com Wed Sep 10 20:59:36 2008 From: lmacken at redhat.com (Luke Macken) Date: Wed, 10 Sep 2008 16:59:36 -0400 Subject: Bodhi 0.5! Message-ID: <20080910205936.GD4048@x300> Hey everyone, As many have already noticed, I performed a large bodhi upgrade recently. A few weeks ago, during The Incident, I was forced to perform what was originally going to be a week long bodhi migration and upgrade, overnight. During the past two weeks I've pushed out 24 versions of bodhi to our infrastructure, fixing various show-stoppers, and making sure that updates got out the door. One of the most noticable changes is that bodhi is much more responsive. Previously, bodhi was a single python process, running on a single server. This single server was also responsible for composing the updates repositories, and rawhide, among lots of other bodhi-related churn. This lead to much pain and suffering for all. The bodhi deployment has since changed. All bodhi requests are now load balanced to a bunch of app servers, each running mod_wsgi with multiple bodhi processes, each with multiple threads. All of the hard work is now done on an isolated releng server. This separate bodhi "masher" is now responsible for composing repositories, updating bugs, generating update notices, sending emails, extended metadata generation, and calculating metrics. I also added support for inter-bodhi communication, which allows our bodhi web frontends to kick off push requests to our bodhi-masher instance. Some of the new features in this release: - A much more flexible karma automatism scheme. Stable/unstable karma thresholds are now fully configurable - Support for bug aliases - A 'newpackage' update type - Newer updates which obsolete older ones will now inherit their bugs and notes. - A shiny new API in the fedora.client.bodhi module - Lots of improved releng and security team support, making our lives little easier - An improved `make update` template (be sure to update your Makefile.common) - Some new bodhi-client features - Creating updates for multiple releases using a single form Note: This is not perfect yet. You can use the "New Update Form" to add any number of builds for any number of releases, but bodhi will still create a single update for each. This issue will be resolved in the next major bodhi release, which will contain a full model redesign. - updateinfo.xml generation takes about 20 seconds, instead of 20 minutes. - A lot of metrics enhancements - A ton of bug and usability fixes Bodhi is far from being feature complete. Some new features in the pipeline: - DeltaRPM generation - Security issue (CVE) tracking and triaging - Dependency closure verification, utilizing the power of rpmgrok. - A complete remodeling from SQLObject to SQLAlchemy, which is almost complete, will give us a lot more flexibility, speed, and power over our update model. This will also allow for things such as having multi-builds for multiple releases in a single update. As always, - File tickets here: https://fedorahosted.org/bodhi/newticket - Help out here: https://fedorahosted.org/bodhi/report/1 - Subscribe to the bodhi mailing list here: https://fedorahosted.org/mailman/listinfo/bodhi - You can always find bodhi here: http://bodhi.fedoraproject.org Thank you all for your patience during the past few weeks, luke p.s. If you're having issues with the bodhi client, a fixed version will be going out with the next batch of updates. For the impatient, you can pull fixed versions from koji (also, make sure your Makefile.common is up to date): koji download-build --arch=noarch python-fedora-0.3.5-1.fc10 koji download-build --arch=noarch bodhi-0.5.2-1.fc9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From kzak at redhat.com Wed Sep 10 21:10:06 2008 From: kzak at redhat.com (Karel Zak) Date: Wed, 10 Sep 2008 23:10:06 +0200 Subject: Boot speedup with readahead In-Reply-To: References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> Message-ID: <20080910211006.GD6092@nb.net.home> On Wed, Sep 10, 2008 at 02:14:52PM -0400, Colin Walters wrote: > On Tue, Sep 9, 2008 at 5:33 PM, Seth Vidal wrote: > > > > Here's a proof of concept plugin: > > > > http://skvidal.fedorapeople.org/misc/post-transaction-actions/ > > Ok cool - with one small fix to the plugin, this simple action: > > # Update the GTK+ icon cache when an icon is installed. > # See: http://www.gtk.org/api/2.6/gtk/gtk-update-icon-cache.html > /usr/share/icons/hicolor/*:any:gtk-update-icon-cache --quiet --force > /usr/share/icons/hicolor > > seems to work. Now we can apply hundreds (thousand?) of patches of > the following form, and probably in many cases entirely eliminate the > single %post and %postun we've been copying and pasting around. It > will be awesome. +1; ...triggers make much more sense than hard coded (and duplicate) scripts. Karel -- Karel Zak From dominik at greysector.net Wed Sep 10 21:35:12 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 10 Sep 2008 23:35:12 +0200 Subject: Boot speedup with readahead In-Reply-To: <1221072143.987.125.camel@rosebud> References: <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <1221071066.1927.216.camel@firewall.xsintricity.com> <1221072143.987.125.camel@rosebud> Message-ID: <20080910213511.GD10743@mokona.greysector.net> On Wednesday, 10 September 2008 at 20:42, Seth Vidal wrote: > On Wed, 2008-09-10 at 14:24 -0400, Doug Ledford wrote: > > On Wed, 2008-09-10 at 14:16 -0400, Seth Vidal wrote: > > > On Wed, 2008-09-10 at 14:14 -0400, Colin Walters wrote: > > > > On Tue, Sep 9, 2008 at 5:33 PM, Seth Vidal wrote: > > > > > > > > > > Here's a proof of concept plugin: > > > > > > > > > > http://skvidal.fedorapeople.org/misc/post-transaction-actions/ > > > > > > > > Ok cool - with one small fix to the plugin, this simple action: > > > > > > > > > > > > > Thank you, I've applied this to the one I uploaded above. > > > > > > So this seems to work - now the question is - should we push for this to > > > go into rpm instead? > > > > Absolutely. If it's going to exist at all, it needs to be in rpm. > > Otherwise this and the corresponding rpm changes fail the litmus test of > > "will my system be the same if I download the rpm(2) and run the > > transaction manually using rpm as it is if I use yum to install the > > rpm". Any time you fail that litmus test, you've put the code in the > > wrong place (at least IMO). > > unless we bite the bullet and stop falling back on being able to do > everything from the rpm interface. -1 Fedora doesn't need to go where Suse already is. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From mclasen at redhat.com Wed Sep 10 21:39:03 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 10 Sep 2008 17:39:03 -0400 Subject: Boot speedup with readahead In-Reply-To: References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <48C80FC9.5020902@behdad.org> Message-ID: <1221082743.3741.1.camel@localhost.localdomain> On Wed, 2008-09-10 at 14:23 -0400, Colin Walters wrote: > On Wed, Sep 10, 2008 at 2:19 PM, Behdad Esfahbod wrote: > > Colin Walters wrote: > >> On Tue, Sep 9, 2008 at 5:33 PM, Seth Vidal wrote: > >>> Here's a proof of concept plugin: > >>> > >>> http://skvidal.fedorapeople.org/misc/post-transaction-actions/ > >> > >> Ok cool - with one small fix to the plugin, this simple action: > >> > >> # Update the GTK+ icon cache when an icon is installed. > >> # See: http://www.gtk.org/api/2.6/gtk/gtk-update-icon-cache.html > >> /usr/share/icons/hicolor/*:any:gtk-update-icon-cache --quiet --force > >> /usr/share/icons/hicolor > > > > Err, shouldn't update cache for the entire /usr/share/icons/hicolor. Just the > > directory changed... > > Yeah, true. Err, there's only a single cache per theme. Nothing per-directory From behdad at behdad.org Wed Sep 10 21:47:21 2008 From: behdad at behdad.org (Behdad Esfahbod) Date: Wed, 10 Sep 2008 17:47:21 -0400 Subject: Boot speedup with readahead In-Reply-To: <1221082743.3741.1.camel@localhost.localdomain> References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <48C80FC9.5020902@behdad.org> <1221082743.3741.1.camel@localhost.localdomain> Message-ID: <48C84069.7030607@behdad.org> Matthias Clasen wrote: > On Wed, 2008-09-10 at 14:23 -0400, Colin Walters wrote: >> On Wed, Sep 10, 2008 at 2:19 PM, Behdad Esfahbod wrote: >>> Colin Walters wrote: >>>> On Tue, Sep 9, 2008 at 5:33 PM, Seth Vidal wrote: >>>>> Here's a proof of concept plugin: >>>>> >>>>> http://skvidal.fedorapeople.org/misc/post-transaction-actions/ >>>> Ok cool - with one small fix to the plugin, this simple action: >>>> >>>> # Update the GTK+ icon cache when an icon is installed. >>>> # See: http://www.gtk.org/api/2.6/gtk/gtk-update-icon-cache.html >>>> /usr/share/icons/hicolor/*:any:gtk-update-icon-cache --quiet --force >>>> /usr/share/icons/hicolor >>> Err, shouldn't update cache for the entire /usr/share/icons/hicolor. Just the >>> directory changed... >> Yeah, true. > > Err, there's only a single cache per theme. Nothing per-directory Umm, I almost wrote "(this may not be an issue for icon theme cache, but definitely will be for font cache)" but removed it. Anyway, said now. behdad From davej at redhat.com Wed Sep 10 21:55:50 2008 From: davej at redhat.com (Dave Jones) Date: Wed, 10 Sep 2008 17:55:50 -0400 Subject: CONFIG_CGROUP_MEM_RES_CTLR In-Reply-To: <661de9470809010029h1ef32ae7h35b6a2dfe2d13c3@mail.gmail.com> References: <661de9470809010029h1ef32ae7h35b6a2dfe2d13c3@mail.gmail.com> Message-ID: <20080910215550.GI31522@redhat.com> On Mon, Sep 01, 2008 at 12:59:28PM +0530, Balbir Singh wrote: > While trying to build the memory resource controller with the latest > kernel source, I saw the following in config-generic > > #NOTE: Before changing the size below, take notice that page struct > will grow past a cacheline on 32 bit. > > I am running F10-alpha 32 bit version, on which I see > > Linux localhost.localdomain 2.6.27-0.166.rc0.git8.fc10.i686 #1 SMP Mon > Jul 21 20:51:26 EDT 2008 i686 i686 i386 GNU/Linux > > sizeof(vma)=84 bytes > sizeof(page)=56 bytes > sizeof(inode)=608 bytes > sizeof(dentry)=160 bytes > sizeof(ext3inode)=860 bytes > sizeof(buffer_head)=56 bytes > sizeof(skbuff)=184 bytes > sizeof(task_struct)=6056 bytes > > With size at 56 bytes, I don't think adding 4 bytes will affect the > growth beyond cacheline size. Yes, but that's with debug options on. With debug options off, on 32bit we're currently at exactly a 32 byte cacheline, so adding a member for CGROUP will push us past 1 cacheline. > I suspect that there are a few debugging options turned on, that are > causing either spinlock_t to bloat or something that CONFIG_PAGE_OWNER > is turned on. Are these debugging options going to go away as we head > towards F10 release? Yes. Dave -- http://www.codemonkey.org.uk From davej at redhat.com Wed Sep 10 22:03:33 2008 From: davej at redhat.com (Dave Jones) Date: Wed, 10 Sep 2008 18:03:33 -0400 Subject: make force-tag gone In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> Message-ID: <20080910220333.GJ31522@redhat.com> On Tue, Sep 09, 2008 at 10:22:28PM +0000, Kevin Kofler wrote: > Because that's what the kernel uses and why they don't need force-tag. And even > that doesn't completely eliminate the need for force-tag, because the mistake > could be somewhere other than the specfile, e.g. a patch you forgot to cvs add. FTR, I use force-tag a *lot*. Here are some of the scenarios.. make tag ; make build oh crap, ppc doesn't build. disable option in config-ppc cvs commit make force-tag (to retag the config-ppc file with the same version as everything else) Now, I could bump the specfile and add "disable option foo on ppc" but if I did this, our changelogs would be absolutely enormous, and for very little gain. Another scenario.. - do a rebase - cvs commit - make tag ; make build - crap, I forgot to add the .sign for the bz2 - cvs add patch..bz2.sign - make force-tag (to tag the bz2.sign the same as the rest) Again, adding an additional entry to the specfile because I forgot to add a file is just going to bloat the changelog into something ridiculous. There are other examples too where this has proven invaluable. I've been away a week or so, so missed the rationale behind all this. So why has this gone away ? Dave -- http://www.codemonkey.org.uk From martin.langhoff at gmail.com Wed Sep 10 22:44:44 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Thu, 11 Sep 2008 10:44:44 +1200 Subject: fedora-release: What is system-release-cpe? Message-ID: <46a038f90809101544v659ffc05i9c23fe9b58fab3a3@mail.gmail.com> The F9 fedora-release has a new file: echo "cpe://o:fedora_project:fedora:%{version}" > $RPM_BUILD_ROOT/etc/system-release-cpe If I ask google, it points be back to the changelog... what is cpe? * Thu Mar 13 2008 Jesse Keating - 8.92-1 - Update for 9 Beta - Update the compose files for 9 Beta - Add system-release-cpe (from Mark Cox) - Add terminal to issue (#436387) - Rename development to rawhide where appropriate. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From stickster at gmail.com Wed Sep 10 23:00:35 2008 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 10 Sep 2008 19:00:35 -0400 Subject: fedora-release: What is system-release-cpe? In-Reply-To: <46a038f90809101544v659ffc05i9c23fe9b58fab3a3@mail.gmail.com> References: <46a038f90809101544v659ffc05i9c23fe9b58fab3a3@mail.gmail.com> Message-ID: <1221087635.14588.32.camel@localhost.localdomain> On Thu, 2008-09-11 at 10:44 +1200, Martin Langhoff wrote: > The F9 fedora-release has a new file: > > echo "cpe://o:fedora_project:fedora:%{version}" > > $RPM_BUILD_ROOT/etc/system-release-cpe > > If I ask google, it points be back to the changelog... what is cpe? > > * Thu Mar 13 2008 Jesse Keating - 8.92-1 > - Update for 9 Beta > - Update the compose files for 9 Beta > - Add system-release-cpe (from Mark Cox) > - Add terminal to issue (#436387) > - Rename development to rawhide where appropriate. I'm guessing it has something to do with http://cpe.mitre.org/ . -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed Sep 10 23:05:15 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 10 Sep 2008 16:05:15 -0700 Subject: fedora-release: What is system-release-cpe? In-Reply-To: <1221087635.14588.32.camel@localhost.localdomain> References: <46a038f90809101544v659ffc05i9c23fe9b58fab3a3@mail.gmail.com> <1221087635.14588.32.camel@localhost.localdomain> Message-ID: <1221087915.3388.165.camel@luminos.localdomain> On Wed, 2008-09-10 at 19:00 -0400, Paul W. Frields wrote: > On Thu, 2008-09-11 at 10:44 +1200, Martin Langhoff wrote: > > The F9 fedora-release has a new file: > > > > echo "cpe://o:fedora_project:fedora:%{version}" > > > $RPM_BUILD_ROOT/etc/system-release-cpe > > > > If I ask google, it points be back to the changelog... what is cpe? > > > > * Thu Mar 13 2008 Jesse Keating - 8.92-1 > > - Update for 9 Beta > > - Update the compose files for 9 Beta > > - Add system-release-cpe (from Mark Cox) > > - Add terminal to issue (#436387) > > - Rename development to rawhide where appropriate. > > I'm guessing it has something to do with http://cpe.mitre.org/ . That's correct, as requested by Marc Cox. https://bugzilla.redhat.com/show_bug.cgi?id=404361 -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From poelstra at redhat.com Wed Sep 10 23:25:14 2008 From: poelstra at redhat.com (John Poelstra) Date: Wed, 10 Sep 2008 16:25:14 -0700 Subject: Fedora Release Engineering Meeting Recap 2008-09-08 Message-ID: <48C8575A.50408@redhat.com> Recap and full IRC transcript found here: https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-sep-08 Please make corrections and clarifications to the wiki page. = Fedora Release Engineering Meeting :: Monday 2008-09-08 = == Fedora 8 & 9 Updates == * updates are pushed to a new location for 8 and 9 (testing too) * doing testing with the updated fedora-release for transition and newer PackageKit builds to handle the key import * working on issues where PackageKit is failing * f13 sending out an announcement today about current status to keep people informed * see IRC transcript for additional details == F10 Beta == * rawhide has been very unstable * push beta freeze from 2008-09-09 to 2008-09-11 while holding to other scheduled dates? ** take discussion and decision to fedora-devel-list == IRC Transcript == From martin.langhoff at gmail.com Wed Sep 10 23:31:07 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Thu, 11 Sep 2008 11:31:07 +1200 Subject: fedora-release: What is system-release-cpe? In-Reply-To: <1221087915.3388.165.camel@luminos.localdomain> References: <46a038f90809101544v659ffc05i9c23fe9b58fab3a3@mail.gmail.com> <1221087635.14588.32.camel@localhost.localdomain> <1221087915.3388.165.camel@luminos.localdomain> Message-ID: <46a038f90809101631o572f5be1q75a24fc709d9bbbb@mail.gmail.com> 2008/9/11 Jesse Keating : > That's correct, as requested by Marc Cox. > https://bugzilla.redhat.com/show_bug.cgi?id=404361 Thanks for the link - Mark Cox writes there... "This is a common platform name, regardless of what individual applications (packages) are provided. Therefore spins can use the same name." which answers my follow up question then -- at least until such time that the OLPC School server grows to have its own CPE entry. Scary thought. fantastic - m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From nicolas.mailhot at laposte.net Wed Sep 10 23:32:59 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 11 Sep 2008 01:32:59 +0200 Subject: make force-tag gone In-Reply-To: <20080910220333.GJ31522@redhat.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> Message-ID: <1221089579.30799.1.camel@rousalka.okg> Le mercredi 10 septembre 2008 ? 18:03 -0400, Dave Jones a ?crit : > Now, I could bump the specfile and add "disable option foo on ppc" but if I did > this, our changelogs would be absolutely enormous, and for very little gain. No one is asking you to add a new changelog line every time you make a small change. You can bump the version in the changelog at the same time you bump it elsewhere -- 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.langhoff at gmail.com Thu Sep 11 00:00:44 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Thu, 11 Sep 2008 12:00:44 +1200 Subject: Fedora-release: picking the GPG files post-transition for a spin Message-ID: <46a038f90809101700t1b444ffaq407e60a67ca5589c@mail.gmail.com> I am working on a custom "fedora-release" replacement package (xs-release) for a custom spin that will be ready at the end of the month. My understanding is that it makes sense to only ship the new GPG keys and new repos. There is a tiny user-base still using a F7-based spin. From what I can see, they'll be able to upgrade with anaconda or yum directly to the post-transition packages. Does my plan make sense? Is there any step in the upgrade machinery that I am missing that might require the old keys? cheers, martin -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From konrad at tylerc.org Thu Sep 11 00:10:51 2008 From: konrad at tylerc.org (Conrad Meyer) Date: Wed, 10 Sep 2008 17:10:51 -0700 Subject: make force-tag gone In-Reply-To: <1221089579.30799.1.camel@rousalka.okg> References: <1220955240.24928.69.camel@cookie.hadess.net> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> Message-ID: <200809101710.51318.konrad@tylerc.org> Quoth Nicolas Mailhot: > Le mercredi 10 septembre 2008 ? 18:03 -0400, Dave Jones a ?crit : > > > Now, I could bump the specfile and add "disable option foo on ppc" but if I did > > this, our changelogs would be absolutely enormous, and for very little gain. > > No one is asking you to add a new changelog line every time you make a > small change. You can bump the version in the changelog at the same time > you bump it elsewhere > > -- > Nicolas Mailhot Actually, they are. See http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs -- Conrad Meyer From michael at laptop.org Thu Sep 11 00:48:00 2008 From: michael at laptop.org (Michael Stone) Date: Wed, 10 Sep 2008 20:48:00 -0400 Subject: Boot speedup with readahead In-Reply-To: <1221079587.987.137.camel@rosebud> References: <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <1221071066.1927.216.camel@firewall.xsintricity.com> <1221072143.987.125.camel@rosebud> <20080910201637.GR18073@didacte.laptop.org> <1221079587.987.137.camel@rosebud> Message-ID: <20080911004729.GU18073@didacte.laptop.org> On Wed, Sep 10, 2008 at 04:46:27PM -0400, Seth Vidal wrote: >On Wed, 2008-09-10 at 16:16 -0400, Michael Stone wrote: > >> Please remember that people use packaging tools for more than simple >> system maintenance; for example, I use an image-builder which is now >> based on smart (even though it was originally based on yum) because >> smart is more convenient for some of my programmatic use cases [1]. > >I think I'd like to look at those use cases in more detail. I'm happy to explain in more detail, though I'll do so in my own order. First, some introduction: my software [1] consists of a family of python programs (called "compilations", since each is a primitive compiler), designed to be run in a mock chroot, which convert collections of packages and hacks into publishables (for example a list of installed packages, a XO JFFS2 disk image, and a tarball of the filesystem contents). [1]: http://wiki.laptop.org/go/Puritan Its primary goal is to ease the task of creating releaseable disk images for OLPC XOs in a reproducible and verifiable fashion by storing all effective inputs to the build process in git commits. Its secondary goal is to overcome some of the infelicities of pilgrim with respect to error detection, cleanup, and debuggability. It's third goal is to be useful to expert Python programmers who maintain Linux builds for fixed hardware regardless of their preferred distro and package-format. It therefore exists in contrast to general-purpose tools like debian-installer, anaconda, revisor, and livecd-tools, which are distro-specific build tools with an interest in shielding their users from the tool's implementation's underlying error-detection, analysis, and correction mechanisms and workflows, often by means of a domain-specific language. Smart is convenient to these goals in that it has a thoroughly documented shell interface which permits the following useful operations: Smart permits me to control my selection of package repositories package more succinctly and less distro-specifically than yum; e.g. smart channel -y --remove-all smart channel -y --add bootstrap type='rpm-md' baseurl='http://dev.laptop.org/~mstone/puritan-repo/' smart channel -y --add bootstrap-f9 type='rpm-md' baseurl='http://dev.laptop.org/~mstone/puritan-f9-repo/' smart channel -y --enable bootstrap smart channel -y --enable bootstrap-f9 smart update smart install -y olpc-crcimg python-msutils I was able to write these basic commands without reference to the smart source code using only its man page; could I have done the same with yum? (In release compilations, the rpm repos being sourced would be included as git submodules of the compilation commit thereby achieving full history good reproducibility.) Next, after adding two new repos (for olpc-specific packages and for general F-9 packages), I run for pkg in firefox seamonkey mozplugger kdebase kernel; do smart priority --set $pkg olpc-joyride 100 done in order to bias several packages toward the OLPC repo. I could do something similar in yum with the '--exclude' option or by modifying the yum repo configuration, but it would be much more annoying either way in that I'd need more complicated code to pipe the results of my configuration phase into the installation phase. Next, mirror configuration: smart mirror --add http://koji.fedoraproject.org/static-repos/dist-olpc3-build-current/i386/ http://koji.fedoraproject.org/packages/ This command essentially lets me perform url-rewriting as needed. This ability is not _necessary_ for my purpose, but it sure is convenient from time to time. >> priority system, >available in a yum plugin - though questionably useful to begin with. Yum plugins seem, at first blush and in general rather than in specific, highly inconvenient for my purpose because of issues like the: * lack of uniform quality control * absence of centralized documentation * potential lack of unified error handling conventions, * perceived difficulty of installation and potential for version mismatch between plugin and host, * lack of a API stability guarantees (Plugins offer a different and compelling social benefit; namely, pluggability; however, that's not the social benefit that _I_ happen to need at the moment.) >> support for alternate package formats, >not sure how this helps fedora. First, must it help Fedora in order to be valuable to me or to be important to my particular use case? Live and let live, friend. Second, please acknowledge that I am, for the time being dedicated first to the XO hardware and second to Fedora. This being what it is, and there lots of other people out there who would like to get their pet distribution running on the XO hardware, it's important to me to be able to collaborate with others using the same tools that I (hope to soon) use during the rest of my day. Isn't that going to benefit Fedora insofar as it helps make Fedora packages work better on all 400k XOs we've shipped it on and insofar as it stimulates more people to make useful contributions to upstream projects? >> built-in ability to download packages, >yum can clearly download pkgs - not sure why it being built in rather >than a plugin matters though. For the reasons I discussed above -- less complexity for me, the tool-writer. >> strictness options, etc.) > >strictness of what? Error-checking. Pilgrim was notorious for producing broken builds because pilgrim failed or was unable to detect situations in which yum was unable to install all the requested packages. Perhaps this is a documentation problem -- I note that the yum man page contains no information about what error codes yum will or can be made to return (if any?). In particular, yum -d 10 -e 10 install grhlkjoei returns 0. This needlessly complicates my life: I _DO NOT_ want to have to parse the yum output in order to learn that a problem occurred. >explain a bit more about the features you're looking for and I'll see >what I can do to help. In conclusion, yum does lots of helpful things but it doesn't do the exact useful things that I need. Yum can certainly be made better by polishing some of these infelicities and I hope that my exposition offers you some useful guidance on conventions and social properties that make my life, as a generic Unix programmer working in Python, much easier were yum's goals a better match for my own. Regarding the possibility of using the yum python modules directly: * what documentation exists? * what guarantees of API stability exist? * what sample code exists and is it sane or contorted? Also, consider the simplicity of my solution: I accomplished everything I needed to (repo configuration, priorities, mirrors, downloading, installation, cross-distro tool, and full error-detection) in something like 40-60 lines of my code which I was able to write from a single man-page and the online help for my tool of choice. I'd be interested in knowing whether you can offer me something comparable. Kind regards, Michael P.S. - I hope I've successfully communicated that I really am interested in my continued ability to make use of all the hard work that goes into maintaining Fedora's packages even though I find myself presently unable to justify doing so with yum? From email.ahmedkamal at googlemail.com Thu Sep 11 01:24:52 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Thu, 11 Sep 2008 03:24:52 +0200 Subject: recover from broken yum transaction Message-ID: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> Hi, I had my computer hang during a major yum upgrade. Now, package-cleanup mentions like 50 duplicate packages installed. I had it clean them up. But now my system does not feel "clean". I am afraid if I reboot it won't come up. Is there a smart way to verify all system files are intact. rpm -Va outputs lots of crappy changes that are "normal". Any way to only get a warning, when something really important has changed ? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From pemboa at gmail.com Thu Sep 11 01:56:12 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 10 Sep 2008 20:56:12 -0500 Subject: Pulseaudio : lots of issues, how can I help? Message-ID: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> I have a lot of seemingly pulse audio related issues on my F9 desktop. Since I really like the idea behind Pulseaudio, I would like to see these get sorted out, and would like to know how I can help in terms of providing useful information. Here is my situation * Sounblaster Live 5.1 PCI -- has full 6 channel audio before, I had for a short while after enabling it as per the pulseaudio wiki, but no more * Tvtime -- no audio (doing `padsp sox -r 48000 -w -c 2 -t ossdsp /dev/dsp -t ossdsp /dev/dsp` works, but causes noticeable lag) * Amarok (xine) -- audio, susceptible to crashes, esp when I scroll to fast in Firefox * Kopete -- used to work, mysteriously stopped working * Konversation -- never worked * Mythfront -- no sound yet (haven't followed http://svn.mythtv.org/trac/ticket/3598#comment:16 yet) * V4L tv capture card -- no sound now, used to rely on capturing AUX on sound card before * PulseAudio -- seems to average 30% CPU usage when playing music, doesn't like me using Firefox too much (seems like a resource issue) Things I use, albeit infrequently, but just work: * flash-plugin * Kplayer What information should I gather, how, and where should I present it? I'm guessing at this point you have more than enough bug reports, but maybe not enough data. Smolt profile for machine in question : http://www.smolts.org/client/show/pub_e429f170-cbfd-4434-a49f-16ef2aadcb54 -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From stickster at gmail.com Thu Sep 11 02:53:38 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 11 Sep 2008 02:53:38 +0000 Subject: Fedora Test Day - 2008-09-11 - Virtualization Message-ID: <1221101618.14588.76.camel@localhost.localdomain> https://www.redhat.com/archives/fedora-test-list/2008-September/msg00159.html Passing this on from fedora-test-list in case there are interested individuals not subscribed there. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Thu Sep 11 03:50:38 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Wed, 10 Sep 2008 23:50:38 -0400 Subject: recover from broken yum transaction In-Reply-To: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> Message-ID: <1221105038.987.147.camel@rosebud> On Thu, 2008-09-11 at 03:24 +0200, Ahmed Kamal wrote: > Hi, > I had my computer hang during a major yum upgrade. When this happens you should run: yum-complete-transaction at the next possible time to see if it can finish the aborted transaction. > Now, package-cleanup mentions like 50 duplicate packages installed. I > had it clean them up. But now my system does not feel "clean". I am > afraid if I reboot it won't come up. Is there a smart way to verify > all system files are intact. rpm -Va outputs lots of crappy changes > that are "normal". Any way to only get a warning, when something > really important has changed ? Really important is a bit subjective. I'd recommend package-cleanup --cleandupes then run: rpm -Va and look for problems in files in /usr/lib /lib/ /boot, and all of the bin dirs. If you don't see any problems in those places then odds are you'll be okay with a reboot. -sv From cweyl at alumni.drew.edu Thu Sep 11 05:29:44 2008 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 10 Sep 2008 22:29:44 -0700 Subject: mass acl opening? Message-ID: <7dd7ab490809102229y51412a3cwe37daeb520bf0a7c@mail.gmail.com> Where do we stand with the mass acl opening to 'uberpackager's? Forgive me if I overlooked an announcement, but google isn't turning anything up at the moment... -Chris -- Chris Weyl Ex astris, scientia From martin.langhoff at gmail.com Thu Sep 11 05:42:22 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Thu, 11 Sep 2008 17:42:22 +1200 Subject: recover from broken yum transaction In-Reply-To: <1221105038.987.147.camel@rosebud> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> Message-ID: <46a038f90809102242w31869559mc6f0b22a291f52b9@mail.gmail.com> On Thu, Sep 11, 2008 at 3:50 PM, Seth Vidal wrote: > When this happens you should run: > yum-complete-transaction Interesting toy! I think you mentioned it at Fudcon Boston and I hadn't been able to recall the right name. Thinking of using it in the use case of the school server (very unreliable power, no sysadmins available, 100% unattended updates) - - Is it safe to run at boot time via an init script? - Is there an easy way to check for pending transactions? - Does it have useful exit codes indicating whether it's done anything? > I'd recommend package-cleanup --cleandupes Another good tool to add to the arsenal. > then run: > rpm -Va and look for problems in files in /usr/lib /lib/ /boot, and all > of the bin dirs. Is that different from `package-cleanup --problems` ? cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From mtasaka at ioa.s.u-tokyo.ac.jp Thu Sep 11 06:02:30 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Thu, 11 Sep 2008 15:02:30 +0900 Subject: mass acl opening? In-Reply-To: <7dd7ab490809102229y51412a3cwe37daeb520bf0a7c@mail.gmail.com> References: <7dd7ab490809102229y51412a3cwe37daeb520bf0a7c@mail.gmail.com> Message-ID: <48C8B476.8040108@ioa.s.u-tokyo.ac.jp> Chris Weyl wrote, at 09/11/2008 02:29 PM +9:00: > Where do we stand with the mass acl opening to 'uberpackager's? > Forgive me if I overlooked an announcement, but google isn't turning > anything up at the moment... > > -Chris > Announced on: https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00007.html Regards, Mamoru From sundaram at fedoraproject.org Thu Sep 11 06:41:28 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 11 Sep 2008 12:11:28 +0530 Subject: Boot speedup with readahead In-Reply-To: <20080910213511.GD10743@mokona.greysector.net> References: <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <1221071066.1927.216.camel@firewall.xsintricity.com> <1221072143.987.125.camel@rosebud> <20080910213511.GD10743@mokona.greysector.net> Message-ID: <48C8BD98.3010408@fedoraproject.org> Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 10 September 2008 at 20:42, Seth Vidal wrote: >> unless we bite the bullet and stop falling back on being able to do >> everything from the rpm interface. > > -1 > > Fedora doesn't need to go where Suse already is. Instead of voting, it would be better, if you can explain why it is wrong in your opinion. +1/-1 doesn't really convey much useful information to assign any weight in a debate. Rahul From weston_schmidt at alumni.purdue.edu Thu Sep 11 07:01:17 2008 From: weston_schmidt at alumni.purdue.edu (Weston T. Schmidt) Date: Thu, 11 Sep 2008 00:01:17 -0700 Subject: [RFC Fedora 10] kill pam_console Message-ID: <48C8C23D.5030208@alumni.purdue.edu> Bill, I'm the maintainer for dfu-programmer. I've been trying to get the HAL permissions to work & I can't figure out what I'm missing. Basically, I need to be able to recognize a usb device is attached and permit the console user to communicate with the usb dfu interface. I'm able to see the device & the properties I added, but get permission denied when I try to access the device. I'm a member of the uucp group (I don't like this approach - I'd rather give the active user permissions, but I couldn't figure that out either). Any help will be greatly appreciated. --Wes What I thought worked for dfu-programmer, but apparently doesn't: dfu-device uucp access_control linux.device_file dfu-device From tmraz at redhat.com Thu Sep 11 07:03:20 2008 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 11 Sep 2008 09:03:20 +0200 Subject: make force-tag gone In-Reply-To: <200809101710.51318.konrad@tylerc.org> References: <1220955240.24928.69.camel@cookie.hadess.net> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> <200809101710.51318.konrad@tylerc.org> Message-ID: <1221116600.3332.11.camel@vespa.frost.loc> On Wed, 2008-09-10 at 17:10 -0700, Conrad Meyer wrote: > Quoth Nicolas Mailhot: > > Le mercredi 10 septembre 2008 ? 18:03 -0400, Dave Jones a ?crit : > > > > > Now, I could bump the specfile and add "disable option foo on ppc" but if > I did > > > this, our changelogs would be absolutely enormous, and for very little > gain. > > > > No one is asking you to add a new changelog line every time you make a > > small change. You can bump the version in the changelog at the same time > > you bump it elsewhere > > > > -- > > Nicolas Mailhot > > Actually, they are. > > See http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs No, you're misreading this. If a package with some n-v-r was never built it doesn't make any sense to have a special changelog entry for it. The wiki is talking about small changes in already built packages. Only once the package has been built and you do even a trivial change (or even no change at all except bumping release because for example the dependecies changed) and do rebuild, then you must add a changelog entry. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From airlied at redhat.com Thu Sep 11 07:18:41 2008 From: airlied at redhat.com (Dave Airlie) Date: Thu, 11 Sep 2008 17:18:41 +1000 Subject: modesetting feature status Message-ID: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> Hi, So one of the features we've been trying to land for F10 that is a major change in how we deal with graphics hardware in the Linux world. https://fedoraproject.org/wiki/Features/KernelModesetting This is going to be a slightly bumpy ride as it involves re-doing all we know about GPU drivers from the ground up. From the kernel to X.org to 3D pieces. So first off how to disable modesetting: add nommodeset to the kernel command line in grub grub can be accessed by holding down the Ctrl key. We are targeting for F10 support for radeon GPUs from r300 to r500 (and possibly r600/r700), and Intel GPUs from i830 to GM45 (though it may end up i915 and up only) For the beta we are only going to enable Radeon support for the r300 to r500 class of hardware, while we await upstream changes to the Intel driver. The intel mode code is more mature, however Intel are currently trying to push the memory manager feature to the kernel first, so are working on stabilising that before finishing the mode setting code. We are including the current Intel code but not enabling it at all until further work is completed. We will switch the code on depending on how things play out and how much testing we think it has had. So why are we doing this: 1. Way better startup sequence. 2. Faster X startup. 3. Better fast-user-switching support 4. Better suspend/resume support 5. Oops/panic messages can appear when X is running. Caveats for Beta release: 1. Performance You will probably notice performance is below what you are used to on the same hardware with the older drivers. This is due to a lack of performance optimization so far and also now that we do more stuff in the kernel, the kernel debugging overheads have a lot more influence on the desktop. 2. 3D. 3D support is not as good. We are currently working with a beta 3D driver on these cards. Compiz might not work for the beta release, we will get it working for F10 final of course. 3. suspend/resume. Suspend/resume may corrupt the graphics. Thanks to everyone who has been involved in this so far and testing all that they have so far. Dave. From email.ahmedkamal at googlemail.com Thu Sep 11 07:53:02 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Thu, 11 Sep 2008 09:53:02 +0200 Subject: recover from broken yum transaction In-Reply-To: <46a038f90809102242w31869559mc6f0b22a291f52b9@mail.gmail.com> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <46a038f90809102242w31869559mc6f0b22a291f52b9@mail.gmail.com> Message-ID: <3da3b5b40809110053n6ebb265vab921118e87dc774@mail.gmail.com> Trying rpm -Va, I am getting lots of these lines S.?..... /usr/bin/kblankscrn.kss S.?..... /usr/bin/kcminit S.?..... /usr/bin/kcminit_startup Basically, the size has changed, and the md5 check cannot be performed ?! I understand this is due to "prelink", but that sux ! This effectively kills the rpm -V functionality. Is it not possible to prelink binaries on the server before wrapping them into rpms ? Any suggested solution around this ? On Thu, Sep 11, 2008 at 7:42 AM, Martin Langhoff wrote: > On Thu, Sep 11, 2008 at 3:50 PM, Seth Vidal > wrote: > > When this happens you should run: > > yum-complete-transaction > > Interesting toy! I think you mentioned it at Fudcon Boston and I > hadn't been able to recall the right name. > > Thinking of using it in the use case of the school server (very > unreliable power, no sysadmins available, 100% unattended updates) - > > - Is it safe to run at boot time via an init script? > - Is there an easy way to check for pending transactions? > - Does it have useful exit codes indicating whether it's done anything? > > > I'd recommend package-cleanup --cleandupes > > Another good tool to add to the arsenal. > > > then run: > > rpm -Va and look for problems in files in /usr/lib /lib/ /boot, and all > > of the bin dirs. > > Is that different from `package-cleanup --problems` ? > > cheers, > > > > m > -- > martin.langhoff at gmail.com > martin at laptop.org -- School Server Architect > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > > -- > 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 email.ahmedkamal at googlemail.com Thu Sep 11 07:58:27 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Thu, 11 Sep 2008 09:58:27 +0200 Subject: RFE: yum transaction auto-complete Message-ID: <3da3b5b40809110058j5be7edddo18bc2dd889973bbb@mail.gmail.com> I would like to propose the following RFE. Whenever yum is running, it creates a state file. If the machine hangs/crashes during an upgrade. Whenever the machine reboots, and yum is run again (or package kit?), that state file should be detected. The user should be warned about an incomplete software installation. The user should be prompted to automatically run yum-complete-transaction. This is actually a less of a brute force way to run yum-complete-transaction at every system boot Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmatilai at laiskiainen.org Thu Sep 11 08:34:10 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 11 Sep 2008 11:34:10 +0300 (EEST) Subject: Boot speedup with readahead In-Reply-To: <1221070577.987.120.camel@rosebud> References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> Message-ID: On Wed, 10 Sep 2008, Seth Vidal wrote: > On Wed, 2008-09-10 at 14:14 -0400, Colin Walters wrote: >> On Tue, Sep 9, 2008 at 5:33 PM, Seth Vidal wrote: >>> >>> Here's a proof of concept plugin: >>> >>> http://skvidal.fedorapeople.org/misc/post-transaction-actions/ >> >> Ok cool - with one small fix to the plugin, this simple action: > > Thank you, I've applied this to the one I uploaded above. > > So this seems to work - now the question is - should we push for this to > go into rpm instead? Not instead, but to rpm *too*, yes. Quite obviously an action that's currently done from say %post script should stay at rpm level, moving some things to be only done once per transaction is just an optimization really. But yum knows a lot more about the surrounding world than rpm does, such as which repository a package came from which is something rpm has no clue about, and thus it can do things in post-transaction that rpm simply could not do. I don't have an example use-case in mind atm but I'm sure somebody can come up with some relatively sane example ;) - Panu - From nicolas.mailhot at laposte.net Thu Sep 11 08:44:51 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 11 Sep 2008 10:44:51 +0200 (CEST) Subject: Boot speedup with readahead In-Reply-To: <48C8BD98.3010408@fedoraproject.org> References: <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <1221071066.1927.216.camel@firewall.xsintricity.com> <1221072143.987.125.camel@rosebud> <20080910213511.GD10743@mokona.greysector.net> <48C8BD98.3010408@fedoraproject.org> Message-ID: <75ba05c9fa0a5adaf2b827e63ef9162f.squirrel@rousalka.dyndns.org> Le Jeu 11 septembre 2008 08:41, Rahul Sundaram a ?crit : > > Dominik 'Rathann' Mierzejewski wrote: >> On Wednesday, 10 September 2008 at 20:42, Seth Vidal wrote: > >>> unless we bite the bullet and stop falling back on being able to do >>> everything from the rpm interface. >> >> -1 >> >> Fedora doesn't need to go where Suse already is. > > Instead of voting, it would be better, if you can explain why it is > wrong in your opinion. +1/-1 doesn't really convey much useful > information to assign any weight in a debate. Yum has progressed a lot in past years but it is not significantly better than competitors (as evidenced by the fact rpm distros have not adopted in in mass) and thus entrenching yum by relying on yum-specific features feels to me rather premature. Competition is healthy. Plus rpm.org has been resurected so there's no compelling reason not to do stuff at this level. -- Nicolas Mailhot From mschwendt at gmail.com Thu Sep 11 09:03:22 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 11 Sep 2008 11:03:22 +0200 Subject: recover from broken yum transaction In-Reply-To: <3da3b5b40809110053n6ebb265vab921118e87dc774@mail.gmail.com> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <46a038f90809102242w31869559mc6f0b22a291f52b9@mail.gmail.com> <3da3b5b40809110053n6ebb265vab921118e87dc774@mail.gmail.com> Message-ID: <20080911110322.02296d5c.mschwendt@gmail.com> On Thu, 11 Sep 2008 09:53:02 +0200, Ahmed Kamal wrote: > Trying rpm -Va, I am getting lots of these lines > > S.?..... /usr/bin/kblankscrn.kss > S.?..... /usr/bin/kcminit > S.?..... /usr/bin/kcminit_startup Then run the test as "root". > Basically, the size has changed, and the md5 check cannot be performed ?! I > understand this is due to "prelink", but that sux ! This effectively kills > the rpm -V functionality. Is it not possible to prelink binaries on the > server before wrapping them into rpms ? Any suggested solution around this ? rpm -Va is aware of prelinking under normal circumstances. From dominik at greysector.net Thu Sep 11 09:05:25 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 11 Sep 2008 11:05:25 +0200 Subject: Boot speedup with readahead In-Reply-To: <48C8BD98.3010408@fedoraproject.org> References: <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <1221071066.1927.216.camel@firewall.xsintricity.com> <1221072143.987.125.camel@rosebud> <20080910213511.GD10743@mokona.greysector.net> <48C8BD98.3010408@fedoraproject.org> Message-ID: <20080911090525.GB17152@mokona.greysector.net> On Thursday, 11 September 2008 at 08:41, Rahul Sundaram wrote: > Dominik 'Rathann' Mierzejewski wrote: > >On Wednesday, 10 September 2008 at 20:42, Seth Vidal wrote: > > >>unless we bite the bullet and stop falling back on being able to do > >>everything from the rpm interface. > > > >-1 > > > >Fedora doesn't need to go where Suse already is. > > Instead of voting, it would be better, if you can explain why it is > wrong in your opinion. +1/-1 doesn't really convey much useful > information to assign any weight in a debate. I believe it is the one who proposes the change that has to explain why it is necessary and can't be done in any other way. It has already been said why it is wrong in this thread: people still use rpm command to install packages. Is there a very good reason to force them to use yum instead? Yum is still slower than plain rpm. After all, it is a frontend and I do not think forcing people to use frontends is a good idea when the tool behind the frontend can do the job just as well. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Thu Sep 11 09:07:52 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 11 Sep 2008 11:07:52 +0200 Subject: Boot speedup with readahead In-Reply-To: References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> Message-ID: <20080911090752.GC17152@mokona.greysector.net> On Thursday, 11 September 2008 at 10:34, Panu Matilainen wrote: > On Wed, 10 Sep 2008, Seth Vidal wrote: > > >On Wed, 2008-09-10 at 14:14 -0400, Colin Walters wrote: > >>On Tue, Sep 9, 2008 at 5:33 PM, Seth Vidal > >>wrote: > >>> > >>>Here's a proof of concept plugin: > >>> > >>>http://skvidal.fedorapeople.org/misc/post-transaction-actions/ > >> > >>Ok cool - with one small fix to the plugin, this simple action: > > > >Thank you, I've applied this to the one I uploaded above. > > > >So this seems to work - now the question is - should we push for this to > >go into rpm instead? > > Not instead, but to rpm *too*, yes. > > Quite obviously an action that's currently done from say %post script > should stay at rpm level, moving some things to be only done once per > transaction is just an optimization really. But yum knows a lot more about > the surrounding world than rpm does, such as which repository a package > came from which is something rpm has no clue about, and thus it can do > things in post-transaction that rpm simply could not do. Granted, but why would it matter where a package came from? All packages should be treated the same, regardless of their origin. I smell some package racism brewing up here. ;) Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From pmatilai at laiskiainen.org Thu Sep 11 09:18:47 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 11 Sep 2008 12:18:47 +0300 (EEST) Subject: Boot speedup with readahead In-Reply-To: <20080911090752.GC17152@mokona.greysector.net> References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <20080911090752.GC17152@mokona.greysector.net> Message-ID: On Thu, 11 Sep 2008, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 11 September 2008 at 10:34, Panu Matilainen wrote: >> On Wed, 10 Sep 2008, Seth Vidal wrote: >> >>> On Wed, 2008-09-10 at 14:14 -0400, Colin Walters wrote: >>>> On Tue, Sep 9, 2008 at 5:33 PM, Seth Vidal >>>> wrote: >>>>> >>>>> Here's a proof of concept plugin: >>>>> >>>>> http://skvidal.fedorapeople.org/misc/post-transaction-actions/ >>>> >>>> Ok cool - with one small fix to the plugin, this simple action: >>> >>> Thank you, I've applied this to the one I uploaded above. >>> >>> So this seems to work - now the question is - should we push for this to >>> go into rpm instead? >> >> Not instead, but to rpm *too*, yes. >> >> Quite obviously an action that's currently done from say %post script >> should stay at rpm level, moving some things to be only done once per >> transaction is just an optimization really. But yum knows a lot more about >> the surrounding world than rpm does, such as which repository a package >> came from which is something rpm has no clue about, and thus it can do >> things in post-transaction that rpm simply could not do. > > Granted, but why would it matter where a package came from? All packages > should be treated the same, regardless of their origin. I smell some > package racism brewing up here. ;) Where a package came from is just one example of things that yum knows that rpm doesn't. Whether there's any real use-case for that particular piece of information is entirely different question. The point is that yum is in position to do various things that rpm cannot possibly do because they operate on different levels and with different amount of information available to them. - Panu - From email.ahmedkamal at googlemail.com Thu Sep 11 09:19:08 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Thu, 11 Sep 2008 11:19:08 +0200 Subject: recover from broken yum transaction In-Reply-To: <20080911110322.02296d5c.mschwendt@gmail.com> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <46a038f90809102242w31869559mc6f0b22a291f52b9@mail.gmail.com> <3da3b5b40809110053n6ebb265vab921118e87dc774@mail.gmail.com> <20080911110322.02296d5c.mschwendt@gmail.com> Message-ID: <3da3b5b40809110219s1257eb0fhbe387f0dd56fbfd9@mail.gmail.com> I am running as root On Thu, Sep 11, 2008 at 11:03 AM, Michael Schwendt wrote: > On Thu, 11 Sep 2008 09:53:02 +0200, Ahmed Kamal wrote: > > > Trying rpm -Va, I am getting lots of these lines > > > > S.?..... /usr/bin/kblankscrn.kss > > S.?..... /usr/bin/kcminit > > S.?..... /usr/bin/kcminit_startup > > Then run the test as "root". > > > Basically, the size has changed, and the md5 check cannot be performed ?! > I > > understand this is due to "prelink", but that sux ! This effectively > kills > > the rpm -V functionality. Is it not possible to prelink binaries on the > > server before wrapping them into rpms ? Any suggested solution around > this ? > > rpm -Va is aware of prelinking under normal circumstances. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.mailhot at laposte.net Thu Sep 11 09:27:59 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 11 Sep 2008 11:27:59 +0200 (CEST) Subject: Feature Proposal: Use cases database In-Reply-To: <1221064863.17299.134.camel@hughsie-work> References: <1220991029.3782.47.camel@choeger6> <1221026638.2783.6.camel@hp6710.axianet.ch> <48C767E7.9040801@gmail.com> <1221059648.17299.103.camel@hughsie-work> <1221062578.21306.13.camel@rousalka.okg> <1221064863.17299.134.camel@hughsie-work> Message-ID: <5cb581610364a94649b91d5bc6e50928.squirrel@rousalka.dyndns.org> Le Mer 10 septembre 2008 18:41, Richard Hughes a ?crit : > > On Wed, 2008-09-10 at 18:02 +0200, Nicolas Mailhot wrote: >> Please work with the anaconda team so whatever resource list format >> you >> end up is shared and we don't have pk catalogs vs comps files. > > I think they are two different formats for two different use cases. I think this is a gratuituous distinction, and a full-blown distro comps file and a 3-line catalog file are just both ends of the same installation spectrum (with lots of people that could use something in-between). >> Really our comps file is nothing but the initial catalog restricted >> to the >> initial repository and it's quite disturbing they have ovelapping >> functionnality with different featuresets, syntax and limitations. > > Comps has optional packages, groups, and quite a complex format. Could > you write a comps file from memory without copying an existing one and > modifying it? Comps has the format necessary for its features and is in fact it is much simpler than the pk catalog format for what it does. I was quite horrified to see how complex the pk catalog format was for what it does. >> On the positive side: PK catalogs allow specifying resources via >> something else than package names > > Yes, as distros are usually spectacularly bad at deciding on package > names (looking at you Debian). > >> On the negative side >> 1. They use .ini syntax. Does not scale well, the fact comps file >> are .xml had helped set up things such as syntax verification easily > > Right, I guess that's another key distinction. Users write catalog > files. Users don't usually enjoy writing XML, unless they are sadist > programmer types. > I also don't intend on having super complex catalog > files, so that don't need to scale. > Typically they will be a three > lines long at most. So you didn't consider the existing format, because XML is "bad", and you didn't think a lot about your format, since you'd decided beforehand it needn't scale. No surprise it feels as a quick and dirty hack. (actually it feels like a format the original XKB authors would have loved. And no that's not a compliment) These are not serious technical arguments. That's handwaving. If it's clean and simple enough to scale that helps three-line users too. If it's not that does not mean it's good for three-line users that just means the problems are spread out more, thus less obvious. And lastly *because* users don't enjoy writing any config file (be it XML or not) they *need* a validation tools that tell them where they made typos (instead of hunting manually for missing parenthesis and such stuff). >> 2. They are keyed on distro-id and architecture. Really this is an >> abysmal idea (as showed by the example asumption Rawhide is fedora >> 9.90). If you really want a multi-distro multi-release file at least >> separate cleanly the different bits in separate sections. > > No, if you look at the file then you'll see as much stuff is common as > possible. This means distros with sane naming policies (say, for > instance Foresight) don't have to have "support added" by adding an > extra section, they just work. distro_id's make a lot of sense when > doing this sort of stuff. This means as soon as a project tries to support more and a handful of distributions it devolves in unmaintainable spaguetti mess. You've made it easy to write distro-specific exceptions instead of making it easy to write the common bits. Also, because you're mixing distributions but not considering scalability, that means a user that wants to check Fedora's cool configs site is going to need loading lots of different catalogs that all define stuff about distros he does not care about, instead of loading a single (or a limited number) of files that only target his distribution but at least are feature-complete. >> 3. They have no structure you can't define groups with >> optionnal/default/etc bits. Anything not limited to a handful of >> packages will need this > > Why optional? If you need packages x, y and z to get started hacking > on > Xorg, why would you possibly need package a as well? In case you've not noticed it every installer be it anaconda or trivial windows aunt-tillie-oriented setup files expose component trees with some optional leaves, because optionnal nice to have but nor strictly necessary bits of an install set are a fact of life. This is one reason we do not do monster monolithic rpm packages because the #1 request of our users is always to have the possibility not to install everything in all cases. The trivial example is software with lots of possible plugins, themes, localizations, or other nice-to-have but not-strictly-necessary and broadband/disk-intensive resources. > I really do think it's two different file types and formats for two > different use cases. Honestly, it does not feel you've spent enough time thinking on the subject. -- Nicolas Mailhot From lordmorgul at gmail.com Thu Sep 11 09:28:24 2008 From: lordmorgul at gmail.com (Andrew Farris) Date: Thu, 11 Sep 2008 02:28:24 -0700 Subject: RFE: yum transaction auto-complete In-Reply-To: <3da3b5b40809110058j5be7edddo18bc2dd889973bbb@mail.gmail.com> References: <3da3b5b40809110058j5be7edddo18bc2dd889973bbb@mail.gmail.com> Message-ID: On 11 Sep 2008, at 12:58 AM, Ahmed Kamal wrote: > I would like to propose the following RFE. Whenever yum is running, > it creates a state file. If the machine hangs/crashes during an > upgrade. Whenever the machine reboots, and yum is run again (or > package kit?), that state file should be detected. The user should > be warned about an incomplete software installation. The user should > be prompted to automatically run yum-complete-transaction. > This is actually a less of a brute force way to run yum-complete- > transaction at every system boot > Regards Better place to discuss that might be here: https://lists.dulug.duke.edu/mailman/listinfo/yum Andrew Farris gpg 0x8300BF29 fingerprint 071D FFE0 4CBC 13FC 7DEB 5BD5 5F89 8E1B 8300 BF29 http://www.lordmorgul.net From j.w.r.degoede at hhs.nl Thu Sep 11 09:28:46 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Thu, 11 Sep 2008 11:28:46 +0200 Subject: modesetting feature status In-Reply-To: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> Message-ID: <48C8E4CE.5040700@hhs.nl> Dave Airlie wrote: > Hi, > > So one of the features we've been trying to land for F10 that is a major > change in how we deal with graphics hardware in the Linux world. > Hi, I own both an r200, r300 and r500 based card. Sofar I've refrained from filing any modesettings related bugs, as the code is moving so fast that my bug would be obsolete the next day. Would now be a good time to start filing bugs about any issues I encounter? If not, when do you expect the code to be in a state where you want to know about any regressions compared to F-9? Thanks & Regards, Hans From airlied at redhat.com Thu Sep 11 10:04:34 2008 From: airlied at redhat.com (Dave Airlie) Date: Thu, 11 Sep 2008 20:04:34 +1000 Subject: modesetting feature status In-Reply-To: <48C8E4CE.5040700@hhs.nl> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <48C8E4CE.5040700@hhs.nl> Message-ID: <1221127474.20727.4.camel@optimus> On Thu, 2008-09-11 at 11:28 +0200, Hans de Goede wrote: > Dave Airlie wrote: > > Hi, > > > > So one of the features we've been trying to land for F10 that is a major > > change in how we deal with graphics hardware in the Linux world. > > > > > > Hi, > > I own both an r200, r300 and r500 based card. Sofar I've refrained from filing > any modesettings related bugs, as the code is moving so fast that my bug would > be obsolete the next day. Would now be a good time to start filing bugs about > any issues I encounter? If not, when do you expect the code to be in a state > where you want to know about any regressions compared to F-9? I'm 100% interested in the output doesn't light up kinda bugs. If anyone encounters these what would be useful is to over ssh boot with nomodeset 3 - go to no X runlevel. rmmod radeon drm modprobe drm debug=1 modprobe radeon modeset=1 and attach dmesg to a bug, also add an xorg log from a nomodeset boot Next on the list are oops and crashes. If I can solve the crashers and modeset not starting I can start on the artifacts, rendering speed regressions and 3D bits. but from the beta release I'd feel free to file any bugs against it. Dave. From dan at danny.cz Thu Sep 11 10:11:57 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Thu, 11 Sep 2008 12:11:57 +0200 Subject: orphaning opencv In-Reply-To: <1220910045.6502.88.camel@beck.corsepiu.local> References: <1220910045.6502.88.camel@beck.corsepiu.local> Message-ID: <1221127917.4911.17.camel@eagle.danny.cz> Ralf Corsepius p??e v Po 08. 09. 2008 v 23:40 +0200: > Hi, > > I'd like to release ownership of opencv, because I don't use it any > longer - Any takers? It is a prerequisite for FreeCAD, so I will take it. Dan From rc040203 at freenet.de Thu Sep 11 10:18:34 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 11 Sep 2008 12:18:34 +0200 Subject: orphaning opencv In-Reply-To: <1221127917.4911.17.camel@eagle.danny.cz> References: <1220910045.6502.88.camel@beck.corsepiu.local> <1221127917.4911.17.camel@eagle.danny.cz> Message-ID: <1221128314.18327.171.camel@beck.corsepiu.local> On Thu, 2008-09-11 at 12:11 +0200, Dan Hor?k wrote: > Ralf Corsepius p??e v Po 08. 09. 2008 v 23:40 +0200: > > Hi, > > > > I'd like to release ownership of opencv, because I don't use it any > > longer - Any takers? > > It is a prerequisite for FreeCAD, so I will take it. Thanks, but meanwhile, Rakesh Pandit has taken it and I stepped into the 2nd row as co-maintainer. Nevertheless, I'd welcome you to join-in as co-maintainer. Ralf From rc040203 at freenet.de Thu Sep 11 10:25:39 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 11 Sep 2008 12:25:39 +0200 Subject: Boot speedup with readahead In-Reply-To: References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> Message-ID: <1221128739.18327.177.camel@beck.corsepiu.local> On Thu, 2008-09-11 at 11:34 +0300, Panu Matilainen wrote: > On Wed, 10 Sep 2008, Seth Vidal wrote: > > > On Wed, 2008-09-10 at 14:14 -0400, Colin Walters wrote: > >> On Tue, Sep 9, 2008 at 5:33 PM, Seth Vidal wrote: > >>> > >>> Here's a proof of concept plugin: > >>> > >>> http://skvidal.fedorapeople.org/misc/post-transaction-actions/ > >> > >> Ok cool - with one small fix to the plugin, this simple action: > > > > Thank you, I've applied this to the one I uploaded above. > > > > So this seems to work - now the question is - should we push for this to > > go into rpm instead? > > Not instead, but to rpm *too*, yes. Rpm only! Yum a wrapper on-top of rpm, not a replacement for rpm nor a wrapper to remedy packing bugs inside of rpm-packages. Ralf From rc040203 at freenet.de Thu Sep 11 10:33:05 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 11 Sep 2008 12:33:05 +0200 Subject: Boot speedup with readahead In-Reply-To: References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <20080911090752.GC17152@mokona.greysector.net> Message-ID: <1221129185.18327.181.camel@beck.corsepiu.local> On Thu, 2008-09-11 at 12:18 +0300, Panu Matilainen wrote: > Where a package came from is just one example of things that yum knows > that rpm doesn't. Whether there's any real use-case for that particular > piece of information is entirely different question. The point is that yum > is in position to do various things that rpm cannot possibly do because > they operate on different levels and with different amount of information > available to them. I would turn this argument around: rpm missed its opportunities "to do various things" forcing people to circumvent rpm's limitations by ruck-sacking rpm with add-ons such as yum, yast/ycl etc. Ralf From hughsient at gmail.com Thu Sep 11 10:40:41 2008 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 11 Sep 2008 11:40:41 +0100 Subject: Feature Proposal: Use cases database In-Reply-To: <5cb581610364a94649b91d5bc6e50928.squirrel@rousalka.dyndns.org> References: <1220991029.3782.47.camel@choeger6> <1221026638.2783.6.camel@hp6710.axianet.ch> <48C767E7.9040801@gmail.com> <1221059648.17299.103.camel@hughsie-work> <1221062578.21306.13.camel@rousalka.okg> <1221064863.17299.134.camel@hughsie-work> <5cb581610364a94649b91d5bc6e50928.squirrel@rousalka.dyndns.org> Message-ID: <1221129641.22654.24.camel@hughsie-work> On Thu, 2008-09-11 at 11:27 +0200, Nicolas Mailhot wrote: > I think this is a gratuituous distinction, and a full-blown distro > comps file and a 3-line catalog file are just both ends of the same > installation spectrum (with lots of people that could use something > in-between). Could you give me some use cases for a catalog please? > Comps has the format necessary for its features and is in fact it is > much simpler than the pk catalog format for what it does. I was quite > horrified to see how complex the pk catalog format was for what it > does. Want to install gnome-do? [PackageKit Catalog] InstallPackages=gnome-do > So you didn't consider the existing format, because XML is "bad", and > you didn't think a lot about your format Please don't tell me what I did and didn't think, I assure you I did do lots of research before I started the feature. > And lastly *because* users don't enjoy writing any config file (be it > XML or not) they *need* a validation tools that tell them where they > made typos (instead of hunting manually for missing parenthesis and > such stuff). Validation tools suck. If you need a validation tool, the format is too complex, sorry. > This means as soon as a project tries to support more and a handful of > distributions it devolves in unmaintainable spaguetti mess. You've > made it easy to write distro-specific exceptions instead of making it > easy to write the common bits. 95% of the package names for _applications_ are common between all distros. 99.9% (thanks Debian...) can be covered like this: [PackageKit Catalog] InstallPackages=gnome-packagekit packagekit-gnome > Also, because you're mixing distributions but not considering > scalability, that means a user that wants to check Fedora's cool > configs site is going to need loading lots of different catalogs that > all define stuff about distros he does not care about, instead of > loading a single (or a limited number) of files that only target his > distribution but at least are feature-complete. No true, sorry. The example shown on the website is a worst-case example, not the common case. > In case you've not noticed it every installer be it anaconda or > trivial windows aunt-tillie-oriented setup files expose component > trees with some optional leaves, because optionnal nice to have but > nor strictly necessary bits of an install set are a fact of life Right, you're assuming the user knows if they want the optional package. Have a look at these people: http://www.packagekit.org/pk-profiles.html Do you think if any of those people know if they want gnome-do when they install "Cool stuff in GNOME.catalog" from a forum post they saw? > . This is one reason we do not do monster monolithic rpm packages because the > #1 request of our users is always to have the possibility not to > install everything in all cases. Right, power users. Power user are not going to be installing packages using silly little catalog files, they'll jump to the command line and use the yum CLI directly. PackageKit just isn't designed for these types of user. > Honestly, it does not feel you've spent enough time thinking on the > subject. That's your opinion. I've actually spent quite a lot of time doing user research. The people on the profiles page are people I know well, and I have either recorded screen-captures of what they did when asked to do common tasks, or who I've asked then to explain to me what they would do with a GUI over the phone. Please don't think I'm going into this blindly, because I'm really not. Richard. From billcrawford1970 at gmail.com Thu Sep 11 11:14:29 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 11 Sep 2008 12:14:29 +0100 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> Message-ID: <544eb990809110414x44c1c563l7d0da7859c166780@mail.gmail.com> On 11/09/2008, Arthur Pemberton wrote: > * Sounblaster Live 5.1 PCI -- has full 6 channel audio before, I had > for a short while after enabling it as per the pulseaudio wiki, but no > more If it's one of the SBs with multiple hardware channels, unless you are likely to want >32 separate apps pumping out sound at once, disable PA and just access the card through ALSA directly. It's worked ok for me :o) From billcrawford1970 at gmail.com Thu Sep 11 11:21:15 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 11 Sep 2008 12:21:15 +0100 Subject: modesetting feature status In-Reply-To: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> Message-ID: <544eb990809110421j7f752186mef1e9c1b17e1dec6@mail.gmail.com> On 11/09/2008, Dave Airlie wrote: > We are targeting for F10 support for radeon GPUs from r300 to r500 (and > possibly r600/r700), and Intel GPUs from i830 to GM45 (though it may end > up i915 and up only) Will r200 class hardware never get kernel modesetting? I've been looking forward to getting this for a number of reasons ... (all my current display hardware is rv280 :o) From cra at WPI.EDU Thu Sep 11 12:03:49 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 11 Sep 2008 08:03:49 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> Message-ID: <20080911120349.GD15457@angus.ind.WPI.EDU> On Wed, Sep 10, 2008 at 08:56:12PM -0500, Arthur Pemberton wrote: > I have a lot of seemingly pulse audio related issues on my F9 desktop. > Since I really like the idea behind Pulseaudio, I would like to see > these get sorted out, and would like to know how I can help in terms > of providing useful information. > > Here is my situation > > * Sounblaster Live 5.1 PCI -- has full 6 channel audio before, I had > for a short while after enabling it as per the pulseaudio wiki, but no > more Check out these two bugs. You might be hitting this where it is trying to use the built-in card instead of your addon PCI card by default, perhaps only for some applications: https://bugzilla.redhat.com/show_bug.cgi?id=441506 https://bugzilla.redhat.com/show_bug.cgi?id=448477 Run "pavucontrol" to set the default output device and monitor applications as they play. You can right click an application stream to change which device it is using to play through on-the-fly. > What information should I gather, how, and where should I present it? > I'm guessing at this point you have more than enough bug reports, but > maybe not enough data. From rawhide at fedoraproject.org Thu Sep 11 12:19:09 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Thu, 11 Sep 2008 12:19:09 +0000 (UTC) Subject: rawhide report: 20080911 changes Message-ID: <20080911121909.6C78A1F8250@releng2.fedora.phx.redhat.com> New package apricots 2D air combat game New package bluez Bluetooth libraries and utilities New package eclipse-nls Babel language packs for the Eclipse platform and various plugins New package gears-backgrounds Gears desktop backgrounds New package hunspell-eu Basque hunspell dictionaries New package invinxble-backgrounds InvinXble desktop backgrounds New package neon-backgrounds Neon desktop backgrounds New package perl-Data-Section Read multiple hunks of data out of your DATA section New package perl-Set-Crontab Expand crontab(5)-style integer lists New package pyexiv2 Python binding to exiv2 New package python-schedutils Linux scheduler python bindings New package snobol Macro Implementation of SNOBOL4 in C New package solar-backgrounds Solar desktop backgrounds New package whatsup Node up/down detection utility Removed package mosml Removed package postgresql-pgpool Updated Packages: PackageKit-0.3.2-3.fc10 ----------------------- * Wed Sep 10 18:00:00 2008 Richard Hughes - 0.3.2-3 - Fix an error where we don't check for existing packages in the catalog code properly. Also fixes the self tests. * Wed Sep 10 18:00:00 2008 Richard Hughes - 0.3.2-2 - Fix a library error so we don't print (null) in the UI. aiksaurus-1.2.1-18.fc10 ----------------------- * Wed Sep 10 18:00:00 2008 Matt Domsch - 1:1.2.1-18 - fix FTBFS #434484 * Fri Jun 13 18:00:00 2008 Jon Stanley - 1:1.2.1-17 - Remove vendor tag, correct license, rebuild * Wed Feb 20 17:00:00 2008 Fedora Release Engineering - 1:1.2.1-16 - Autorebuild for GCC 4.3 alsa-lib-1.0.18-4.rc3.fc10 -------------------------- * Wed Sep 10 18:00:00 2008 Jaroslav Kysela - 1.0.18-4.rc3 - fixed spec file - fixed package version number (1.0.18-3.rc3 was tagged by accident) * Wed Sep 10 18:00:00 2008 Jaroslav Kysela - 1.0.18-1.rc3 - updated to 1.0.18rc3 - moved /etc/alsa configuration files back to /usr/share/alsa - removed pulse default patch (moved to /etc/asound.conf) - added /etc/asound.conf and /etc/alsa/alsactl.conf - disable /dev/aload device checking (obsolete for 2.6 kernels) * Fri Aug 15 18:00:00 2008 Jaroslav Kysela - 1.0.17-3 - updated to 1.0.17a anyremote-4.8.1-2.fc10 ---------------------- * Thu Sep 11 18:00:00 2008 Mamoru Tasaka - 4.8.1-2 - F-10: rebuild against new bluez aplus-fsf-4.22.4-4.fc10 ----------------------- * Wed Sep 10 18:00:00 2008 Jochen Schmitt 4.22.4-4 - Add forgotten file into cvs * Tue Sep 9 18:00:00 2008 Jochen Schmitt 4.22.4-2 - Try to fix BZ #456952 bacula-2.4.2-2.fc10 ------------------- * Tue Sep 9 18:00:00 2008 Jon Ciesla - 2.4.2-2 - Logrotate fix. BZ 457894. - Alternatives fix. BZ 458432. bluez-gnome-1.3-1.fc10 ---------------------- * Wed Sep 10 18:00:00 2008 - David Woodhouse - 1.3-1 - Update to 1.3 * Tue Sep 9 18:00:00 2008 - David Woodhouse -0.28-3 - Fix device addition comps-extras-13-3 ----------------- * Wed Sep 10 18:00:00 2008 Bill Nottingham - 13-3 - add a logo for Sugar desktop coq-8.1pl3-4.fc10 ----------------- * Tue Sep 9 18:00:00 2008 Alan Dunn 8.1pl3-4 - Added creation of prelink blacklist for any bytecode files. - Fixed execstack status for binaries. cups-1.3.8-6.fc10 ----------------- * Wed Sep 10 18:00:00 2008 Tim Waugh 1:1.3.8-6 - Backported patch for FatalErrors configuration directive (bug #314941, STR #2536). * Thu Sep 4 18:00:00 2008 Tim Waugh - Use php-cgi for executing PHP scripts (bug #460898). cwiid-0.6.00-9.fc10 ------------------- * Thu Sep 11 18:00:00 2008 Mamoru Tasaka 0.6.00-9 - F-10: rebuild against new bluez - Fix for bluez api change cyrus-sasl-2.1.22-18.fc10 ------------------------- * Mon Sep 29 18:00:00 2008 Tomas Mraz - 2.1.22-18 - fix most critical build warnings (#433583) - use external db4 db4-4.7.25-4.fc10 ----------------- * Wed Sep 10 18:00:00 2008 Jindrich Novy 4.7.25-4 - actually apply the .jni patch - fix permissions in db4-utils package (#225675) dxpc-3.9.1-1.fc10 ----------------- * Wed Sep 10 18:00:00 2008 John Guthrie - 3.9.1-1 - Added %dist tag back to the release tag that had been inadvertently deleted by the previous update. facter-1.5.2-1.fc10 ------------------- * Tue Sep 9 18:00:00 2008 Todd Zullinger - 1.5.2-1 - New version - Simplify spec file checking for Fedora and RHEL versions fantasdic-1.0-0.2.beta6.fc10 ---------------------------- * Wed Sep 10 18:00:00 2008 Mamoru Tasaka - 1.0-0.2.beta6 - 1.0 beta6 fedora-logos-9.99.3-1.fc10 -------------------------- * Wed Sep 10 18:00:00 2008 Tom "spot" Callaway - 9.99.3-1 - move to its new home - package up xfce4_xicon1.svg (bz 445986) fedora-release-notes-9.0.2-1 ---------------------------- * Sat Jul 19 18:00:00 2008 Paul W. Frields - 9.0.2-1 - Content and translation updates - Fix description (#453255) gambas2-2.8.2-1.fc10 -------------------- * Wed Sep 10 18:00:00 2008 Tom "spot" Callaway 2.8.2-1 - update to 2.8.2 - make gb-db-form subpackage (bz 461595) gkrellm-2.3.1-5.fc10 -------------------- * Wed Sep 10 18:00:00 2008 Hans de Goede 2.3.1-5 - Build against openssl instead of gnutls-openssl fixing symbol conflicts when using pam_ldap (which uses openssl), this fixes rh 446860 gnome-vfs2-2.23.0-2.fc10 ------------------------ * Thu Sep 11 18:00:00 2008 Matthias Clasen - 2.23.0-1 - Rebuild against new bluez-libs grisbi-0.5.9-8.fc10 ------------------- * Wed Sep 10 18:00:00 2008 Bill Nottngham 0.5.9-8 - rebuild against new libofx gtk2-2.14.0-5.fc10 ------------------ gvfs-0.99.7.1-3.fc10 -------------------- * Thu Sep 11 18:00:00 2008 Matthias Clasen - 0.99.7.1-3 - Rebuild hfsplus-tools-332.14-7.fc10 --------------------------- * Wed Sep 10 18:00:00 2008 Tom "spot" Callaway - 332.14-7 - RH Legal was kind enough to point out what I had overlooked, the clause in the APSL which permits "any subsequent version of this License published by Apple". - Fixed license tag homebank-3.8-3.fc10 ------------------- * Wed Sep 10 18:00:00 2008 Bill Nottingham 3.8-3 - rebuild against new libofx initscripts-8.82-1 ------------------ * Wed Sep 10 18:00:00 2008 Bill Nottingham - 8.82-1 - refresh translation strings - plymouth updates. (#460702, ) - translation updates: fi, lv, no - remove duplicate dependency (#465182) - ifup-eth: Change how we set the zeroconf route. (#239609) - ifup*: Use 0.0.0.0/0, not 0/0. (#460580) ipa-1.1.0-3.fc10 ---------------- * Wed Jul 23 18:00:00 2008 Simo Sorce - 1.1.0-3 - Fix for CVE-2008-3274 - Fix segfault in ipa-kpasswd in case getifaddrs returns a NULL interface - Add fix for bug #453185 - Rebuild against openldap libraries, mozldap ones do not work properly - TurboGears is currently broken in rawhide. Added patch to not build the UI locales and removed them from the ipa-server files section. iwl5000-firmware-5.4.A.11-3 --------------------------- * Fri Sep 5 18:00:00 2008 kwizart < kwizart at gmail.com > - 5.4.A.11-3 - Remove ppc/ppc64 from ExcludedArches kernel-2.6.27-0.322.rc6.fc10 ---------------------------- * Wed Sep 10 18:00:00 2008 Mark McLoughlin - Pull in new e1000e hardware support (e.g. ich10) from net-next-2.6 libdap-3.8.2-1.fc10 ------------------- * Fri Sep 5 18:00:00 2008 Patrice Dumas 3.8.2-1 - update to 3.8.2 * Sun Mar 16 18:00:00 2008 Patrice Dumas 3.8.0-1 - update to 3.8.0 * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 3.7.10-3 - Autorebuild for GCC 4.3 libgdiplus-2.0-2.fc10 --------------------- * Tue Sep 9 18:00:00 2008 Paul F. Johnson 2.0-2 - Bump to RC1 libsemanage-2.0.27-3.fc10 ------------------------- * Wed Sep 10 18:00:00 2008 Dan Walsh - 2.0.27-3 - Additional fixes for Don't rebuild on fcontext or seuser modifications * Tue Sep 2 18:00:00 2008 Dan Walsh - 2.0.27-2 - Don't rebuild on fcontext or seuser modifications lineakd-0.9-8.fc10 ------------------ * Wed Sep 10 18:00:00 2008 Matt Domsch - 0.9-8 - fix FTBFS #434523 * Fri Jun 6 18:00:00 2008 Tom "spot" Callaway - 0.9-7 - fix license tag - fix compile with gcc 4.3 * Wed Feb 20 17:00:00 2008 Fedora Release Engineering - 0.9-6 - Autorebuild for GCC 4.3 merkaartor-0.11-3.fc10 ---------------------- * Wed Sep 10 18:00:00 2008 Sven Lankes - 0.11-3 - add patch from -fixes branch (fixes upload error) * Thu Aug 28 18:00:00 2008 Michael Schwendt - 0.11-2 - include unowned directories mod_mono-2.0-2.fc10 ------------------- * Tue Sep 9 18:00:00 2008 Paul F. Johnson 2.0-2 - bump to 2.0 RC 1 mono-2.0-6.fc10 --------------- * Tue Sep 9 18:00:00 2008 Paul F. Johnson 2.0-6 - Bump to RC1 - Removed XIM patch - Added additional configure options - Fixed spec file mono-basic-2.0-2.fc10 --------------------- * Tue Sep 9 18:00:00 2008 Paul F. Johnson 2.0-2 - bump to 2.0 RC 1 mono-tools-2.0-5.fc10 --------------------- * Tue Sep 9 18:00:00 2008 Paul F. Johnson - 2.0-5 - bump to 2.0 RC 1 - spec file chanages monodevelop-1.9-6.fc10 ---------------------- * Tue Sep 9 18:00:00 2008 Paul F. Johnson 1.9-6 - Added patch to build against 2.0 RC 1 - rebuild against 2.0 RC 1 monodoc-2.0-3.fc10 ------------------ * Tue Sep 9 18:00:00 2008 Paul F. Johnson 2.0-3 - bump to 2.0 RC 1 mythes-sk-0.20080905-1.fc10 --------------------------- * Wed Sep 10 18:00:00 2008 Caolan McNamara - 0.20080905-1 - latest version perl-Catalyst-Devel-1.08-2.fc10 ------------------------------- * Wed Sep 10 18:00:00 2008 Chris Weyl 1.08-2 - add perl(parent) as a requires (BZ#461581) perl-File-Remove-1.42-1.fc10 ---------------------------- * Wed Sep 10 18:00:00 2008 Ralf Corsepius - 1.42-1 - Upstream update. perl-Image-Info-1.28-1.fc10 --------------------------- * Wed Sep 10 18:00:00 2008 Tom "spot" Callaway - 1.28-1 - update to 1.28 perl-Pod-Tests-1.19-1.fc10 -------------------------- * Wed Sep 10 18:00:00 2008 Ralf Cors??pius - 1.19-1 - Upstream update. pixman-0.11.10-2.fc10 --------------------- * Wed Sep 10 18:00:00 2008 Soren Sandmann 0.11.10-2 - Add patch to fix stripes in the Nautilus selection retangle. plymouth-0.6.0-0.2008.09.10.1.fc10 ---------------------------------- * Wed Sep 10 18:00:00 2008 Ray Strode 0.5.0-0.2008.09.10.1 - Fix text rendering for certain machines python-virtinst-0.400.0-1.fc10 ------------------------------ * Wed Sep 10 18:00:00 2008 Cole Robinson - 0.400.0-1.fc10 - Add virt-convert tool - Add virt-pack tool - virt-install --disk option for using/provisioning libvirt storage - virt-install remote installation support - virt-install --sound option to add soundcard emulation quota-3.16-5.fc10 ----------------- * Wed Sep 10 18:00:00 2008 Ondrej Vasik 1:3.16-5 - fix rpmlint warnings - absolute symlink and not using epoch in version in changelog (#226353) - rquota headers and manpage now in devel subpackage rpmdevtools-6.7-1.fc9 --------------------- * Sun Aug 3 18:00:00 2008 Ville Skytt?? - 6.7-1 - 6.7. - Make rpmdev-diff, rpmdev-md5 and rpminfo honor TMPDIR. * Sat Apr 26 18:00:00 2008 Ville Skytt?? - Make rpmls work with URLs. * Sun Apr 20 18:00:00 2008 Ville Skytt?? - Include rpm arch in dir names created by rpmdev-extract (#443266). * Fri Apr 18 18:00:00 2008 Ville Skytt?? - Remove duplicate "reload" from case block in init script template. - Fix exit status of "reload" in case service is not running in init script template (#442993). sabayon-2.22.0-4.fc10 --------------------- * Wed Sep 10 18:00:00 2008 Tomas Bzatek - 2.22.0-4 - Fix saving lockdown settings setroubleshoot-2.0.10-2.fc10 ---------------------------- * Wed Sep 10 18:00:00 2008 Dan Walsh - 2.0.10-2 - Fix requires line to gnome-python2-gnome setroubleshoot-plugins-2.0.8-1.fc10 ----------------------------------- * Wed Sep 10 18:00:00 2008 - 2.0.8-1 - Add qemu plugins * Tue Sep 9 18:00:00 2008 - 2.0.7-1 - Add catchall_booleans plugin, fix spelling transfig-3.2.5-4.fc10 --------------------- * Wed Sep 10 18:00:00 2008 Stepan Kasal - 1:3.2.5-4 - remove transfig.3.2.4-pstex.patch, which reintroduced #164140 at the update to 3.2.5 util-linux-ng-2.14.1-2.fc10 --------------------------- * Wed Sep 10 18:00:00 2008 Karel Zak 2.14.1-2 - remove obsolete pam-console support * Wed Sep 10 18:00:00 2008 Karel Zak 2.14.1-1 - upgrade to stable 2.14.1 virt-manager-0.6.0-1.fc10 ------------------------- * Wed Sep 10 18:00:00 2008 Cole Robinson - 0.6.0-1.fc10 - Update to 0.6.0 release - Add libvirt storage management support - Basic support for remote guest installation - Merge VM console and details windows - Poll avahi for libvirtd advertisement - Hypervisor autoconnect option - Add sound emulation when creating new guests wireshark-1.0.3-1.fc10 ---------------------- * Wed Sep 10 18:00:00 2008 Radek Vok??l 1.0.3-1 - upgrade to 1.0.3 - Security-related bugs in the NCP dissector, zlib compression code, and Tektronix .rf5 file parser have been fixed. - WPA group key decryption is now supported. - A bug that could cause packets to be wrongly dissected as "Redback Lawful Intercept" has been fixed. xcb-proto-1.2-1.fc10 -------------------- * Wed Sep 10 18:00:00 2008 Adam Jackson 1.2-1 - xcb-proto 1.2 xorg-x11-drv-ati-6.9.0-12.fc10 ------------------------------ * Wed Sep 10 18:00:00 2008 Adam Jackson 6.9.0-12 - Do the fb size hack a differently bad way. * Tue Sep 9 18:00:00 2008 Kristian H??gsberg 6.9.0-11 - Restore CFLAGS after testing for DRM_MODE in radeon-modeset.patch. xorg-x11-drv-i810-2.4.2-7.fc10 ------------------------------ * Wed Sep 10 18:00:00 2008 Adam Jackson 2.4.2-7 - Do the fb size hack a different terrible way. xorg-x11-drv-nv-2.1.12-3.fc10 ----------------------------- * Wed Sep 10 18:00:00 2008 Adam Jackson 2.1.12-3 - Do the fb size hack a differently wretched way. xsp-2.0-2.fc10 -------------- * Tue Sep 9 18:00:00 2008 Paul F. Johnson 2.0-2 - bump to 2.0 RC 1 yum-utils-1.1.16-2.fc10 ----------------------- * Wed Sep 10 18:00:00 2008 Tim Lauridsen - Added patch to unbreak repoquery Summary: Added Packages: 14 Removed Packages: 2 Modified Packages: 64 Broken deps for i386 ---------------------------------------------------------- bes-3.5.3-3.fc9.i386 requires libdap.so.8 bes-3.5.3-3.fc9.i386 requires libdapserver.so.4 dap-freeform_handler-3.7.7-2.fc9.i386 requires libdap.so.8 dap-freeform_handler-3.7.7-2.fc9.i386 requires libdapserver.so.4 dap-hdf4_handler-3.7.7-3.fc9.i386 requires libdap.so.8 dap-hdf4_handler-3.7.7-3.fc9.i386 requires libdapserver.so.4 dap-netcdf_handler-3.7.8-3.fc9.i386 requires libdap.so.8 dap-netcdf_handler-3.7.8-3.fc9.i386 requires libdapserver.so.4 dap-server-3.8.4-3.fc9.i386 requires libdapclient.so.2 dap-server-3.8.4-3.fc9.i386 requires libdap.so.8 dap-server-3.8.4-3.fc9.i386 requires libdapserver.so.4 em8300-0.17.1-1.fc10.i386 requires /etc/alsa/cards evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 gdal-1.5.2-1.fc10.i386 requires libdapclient.so.2 gdal-1.5.2-1.fc10.i386 requires libdap.so.8 gdal-1.5.2-1.fc10.i386 requires libdapserver.so.4 gdal-ruby-1.5.2-1.fc10.i386 requires libdapclient.so.2 gdal-ruby-1.5.2-1.fc10.i386 requires libdapserver.so.4 gdal-ruby-1.5.2-1.fc10.i386 requires libdap.so.8 grads-1.9b4-23.fc9.i386 requires libdap.so.8 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.12-1.fc10.i386 requires perl(MT::Plugin) highlight-2.6.12-1.fc10.i386 requires perl(MT::WeblogPublisher) highlight-2.6.12-1.fc10.i386 requires perl(MT::Entry) highlight-2.6.12-1.fc10.i386 requires perl(MT) highlight-2.6.12-1.fc10.i386 requires perl(MT::Template::Context) libnc-dap-3.7.0-9.fc9.i386 requires libdapclient.so.2 libnc-dap-3.7.0-9.fc9.i386 requires libdap.so.8 mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 ncl-5.0.0-11.fc9.i386 requires libdapclient.so.2 ncl-5.0.0-11.fc9.i386 requires libdap.so.8 nco-3.9.5-1.fc10.i386 requires libdapclient.so.2 nco-3.9.5-1.fc10.i386 requires libdap.so.8 perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0 pyexiv2-0.1.2-3.fc9.i386 requires libexiv2.so.2 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for x86_64 ---------------------------------------------------------- bes-3.5.3-3.fc9.i386 requires libdap.so.8 bes-3.5.3-3.fc9.i386 requires libdapserver.so.4 bes-3.5.3-3.fc9.x86_64 requires libdapserver.so.4()(64bit) bes-3.5.3-3.fc9.x86_64 requires libdap.so.8()(64bit) dap-freeform_handler-3.7.7-2.fc9.i386 requires libdap.so.8 dap-freeform_handler-3.7.7-2.fc9.i386 requires libdapserver.so.4 dap-freeform_handler-3.7.7-2.fc9.x86_64 requires libdapserver.so.4()(64bit) dap-freeform_handler-3.7.7-2.fc9.x86_64 requires libdap.so.8()(64bit) dap-hdf4_handler-3.7.7-3.fc9.x86_64 requires libdapserver.so.4()(64bit) dap-hdf4_handler-3.7.7-3.fc9.x86_64 requires libdap.so.8()(64bit) dap-netcdf_handler-3.7.8-3.fc9.i386 requires libdap.so.8 dap-netcdf_handler-3.7.8-3.fc9.i386 requires libdapserver.so.4 dap-netcdf_handler-3.7.8-3.fc9.x86_64 requires libdapserver.so.4()(64bit) dap-netcdf_handler-3.7.8-3.fc9.x86_64 requires libdap.so.8()(64bit) dap-server-3.8.4-3.fc9.x86_64 requires libdapserver.so.4()(64bit) dap-server-3.8.4-3.fc9.x86_64 requires libdap.so.8()(64bit) dap-server-3.8.4-3.fc9.x86_64 requires libdapclient.so.2()(64bit) em8300-0.17.1-1.fc10.x86_64 requires /etc/alsa/cards evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) gdal-1.5.2-1.fc10.i386 requires libdapclient.so.2 gdal-1.5.2-1.fc10.i386 requires libdap.so.8 gdal-1.5.2-1.fc10.i386 requires libdapserver.so.4 gdal-1.5.2-1.fc10.x86_64 requires libdapserver.so.4()(64bit) gdal-1.5.2-1.fc10.x86_64 requires libdap.so.8()(64bit) gdal-1.5.2-1.fc10.x86_64 requires libdapclient.so.2()(64bit) gdal-ruby-1.5.2-1.fc10.x86_64 requires libdapserver.so.4()(64bit) gdal-ruby-1.5.2-1.fc10.x86_64 requires libdap.so.8()(64bit) gdal-ruby-1.5.2-1.fc10.x86_64 requires libdapclient.so.2()(64bit) grads-1.9b4-23.fc9.x86_64 requires libdap.so.8()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.12-1.fc10.x86_64 requires perl(MT::Plugin) highlight-2.6.12-1.fc10.x86_64 requires perl(MT::WeblogPublisher) highlight-2.6.12-1.fc10.x86_64 requires perl(MT::Entry) highlight-2.6.12-1.fc10.x86_64 requires perl(MT) highlight-2.6.12-1.fc10.x86_64 requires perl(MT::Template::Context) libnc-dap-3.7.0-9.fc9.i386 requires libdapclient.so.2 libnc-dap-3.7.0-9.fc9.i386 requires libdap.so.8 libnc-dap-3.7.0-9.fc9.x86_64 requires libdapclient.so.2()(64bit) libnc-dap-3.7.0-9.fc9.x86_64 requires libdap.so.8()(64bit) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 ncl-5.0.0-11.fc9.x86_64 requires libdap.so.8()(64bit) ncl-5.0.0-11.fc9.x86_64 requires libdapclient.so.2()(64bit) nco-3.9.5-1.fc10.i386 requires libdapclient.so.2 nco-3.9.5-1.fc10.i386 requires libdap.so.8 nco-3.9.5-1.fc10.x86_64 requires libdap.so.8()(64bit) nco-3.9.5-1.fc10.x86_64 requires libdapclient.so.2()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) pyexiv2-0.1.2-3.fc9.x86_64 requires libexiv2.so.2()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for ppc ---------------------------------------------------------- bes-3.5.3-3.fc9.ppc requires libdap.so.8 bes-3.5.3-3.fc9.ppc requires libdapserver.so.4 bes-3.5.3-3.fc9.ppc64 requires libdapserver.so.4()(64bit) bes-3.5.3-3.fc9.ppc64 requires libdap.so.8()(64bit) dap-freeform_handler-3.7.7-2.fc9.ppc requires libdap.so.8 dap-freeform_handler-3.7.7-2.fc9.ppc requires libdapserver.so.4 dap-freeform_handler-3.7.7-2.fc9.ppc64 requires libdapserver.so.4()(64bit) dap-freeform_handler-3.7.7-2.fc9.ppc64 requires libdap.so.8()(64bit) dap-hdf4_handler-3.7.7-3.fc9.ppc requires libdap.so.8 dap-hdf4_handler-3.7.7-3.fc9.ppc requires libdapserver.so.4 dap-netcdf_handler-3.7.8-3.fc9.ppc requires libdap.so.8 dap-netcdf_handler-3.7.8-3.fc9.ppc requires libdapserver.so.4 dap-netcdf_handler-3.7.8-3.fc9.ppc64 requires libdapserver.so.4()(64bit) dap-netcdf_handler-3.7.8-3.fc9.ppc64 requires libdap.so.8()(64bit) dap-server-3.8.4-3.fc9.ppc requires libdapclient.so.2 dap-server-3.8.4-3.fc9.ppc requires libdap.so.8 dap-server-3.8.4-3.fc9.ppc requires libdapserver.so.4 em8300-0.17.1-1.fc10.ppc requires /etc/alsa/cards evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gdal-1.5.2-1.fc10.ppc requires libdapclient.so.2 gdal-1.5.2-1.fc10.ppc requires libdap.so.8 gdal-1.5.2-1.fc10.ppc requires libdapserver.so.4 gdal-1.5.2-1.fc10.ppc64 requires libdapserver.so.4()(64bit) gdal-1.5.2-1.fc10.ppc64 requires libdap.so.8()(64bit) gdal-1.5.2-1.fc10.ppc64 requires libdapclient.so.2()(64bit) gdal-ruby-1.5.2-1.fc10.ppc requires libdapclient.so.2 gdal-ruby-1.5.2-1.fc10.ppc requires libdapserver.so.4 gdal-ruby-1.5.2-1.fc10.ppc requires libdap.so.8 grads-1.9b4-23.fc9.ppc requires libdap.so.8 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) highlight-2.6.12-1.fc10.ppc requires perl(MT::Plugin) highlight-2.6.12-1.fc10.ppc requires perl(MT::WeblogPublisher) highlight-2.6.12-1.fc10.ppc requires perl(MT::Entry) highlight-2.6.12-1.fc10.ppc requires perl(MT) highlight-2.6.12-1.fc10.ppc requires perl(MT::Template::Context) libnc-dap-3.7.0-9.fc9.ppc requires libdapclient.so.2 libnc-dap-3.7.0-9.fc9.ppc requires libdap.so.8 libnc-dap-3.7.0-9.fc9.ppc64 requires libdapclient.so.2()(64bit) libnc-dap-3.7.0-9.fc9.ppc64 requires libdap.so.8()(64bit) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 ncl-5.0.0-11.fc9.ppc requires libdapclient.so.2 ncl-5.0.0-11.fc9.ppc requires libdap.so.8 nco-3.9.5-1.fc10.ppc requires libdapclient.so.2 nco-3.9.5-1.fc10.ppc requires libdap.so.8 nco-3.9.5-1.fc10.ppc64 requires libdap.so.8()(64bit) nco-3.9.5-1.fc10.ppc64 requires libdapclient.so.2()(64bit) perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0 pyexiv2-0.1.2-3.fc9.ppc requires libexiv2.so.2 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires libbfd-2.18.50.0.8-2.fc10.so stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires libopcodes-2.18.50.0.8-2.fc10.so vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 Broken deps for ppc64 ---------------------------------------------------------- bes-3.5.3-3.fc9.ppc64 requires libdapserver.so.4()(64bit) bes-3.5.3-3.fc9.ppc64 requires libdap.so.8()(64bit) dap-freeform_handler-3.7.7-2.fc9.ppc64 requires libdapserver.so.4()(64bit) dap-freeform_handler-3.7.7-2.fc9.ppc64 requires libdap.so.8()(64bit) dap-hdf4_handler-3.7.7-3.fc9.ppc64 requires libdapserver.so.4()(64bit) dap-hdf4_handler-3.7.7-3.fc9.ppc64 requires libdap.so.8()(64bit) dap-netcdf_handler-3.7.8-3.fc9.ppc64 requires libdapserver.so.4()(64bit) dap-netcdf_handler-3.7.8-3.fc9.ppc64 requires libdap.so.8()(64bit) dap-server-3.8.4-3.fc9.ppc64 requires libdapserver.so.4()(64bit) dap-server-3.8.4-3.fc9.ppc64 requires libdap.so.8()(64bit) dap-server-3.8.4-3.fc9.ppc64 requires libdapclient.so.2()(64bit) eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 em8300-0.17.1-1.fc10.ppc64 requires /etc/alsa/cards evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gdal-1.5.2-1.fc10.ppc64 requires libdapserver.so.4()(64bit) gdal-1.5.2-1.fc10.ppc64 requires libdap.so.8()(64bit) gdal-1.5.2-1.fc10.ppc64 requires libdapclient.so.2()(64bit) gdal-ruby-1.5.2-1.fc10.ppc64 requires libdapserver.so.4()(64bit) gdal-ruby-1.5.2-1.fc10.ppc64 requires libdap.so.8()(64bit) gdal-ruby-1.5.2-1.fc10.ppc64 requires libdapclient.so.2()(64bit) grads-1.9b4-23.fc9.ppc64 requires libdap.so.8()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave highlight-2.6.12-1.fc10.ppc64 requires perl(MT::Plugin) highlight-2.6.12-1.fc10.ppc64 requires perl(MT::WeblogPublisher) highlight-2.6.12-1.fc10.ppc64 requires perl(MT::Entry) highlight-2.6.12-1.fc10.ppc64 requires perl(MT) highlight-2.6.12-1.fc10.ppc64 requires perl(MT::Template::Context) libnc-dap-3.7.0-9.fc9.ppc64 requires libdapclient.so.2()(64bit) libnc-dap-3.7.0-9.fc9.ppc64 requires libdap.so.8()(64bit) livecd-tools-018-1.fc10.ppc64 requires yaboot mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 ncl-5.0.0-11.fc9.ppc64 requires libdap.so.8()(64bit) ncl-5.0.0-11.fc9.ppc64 requires libdapclient.so.2()(64bit) nco-3.9.5-1.fc10.ppc64 requires libdap.so.8()(64bit) nco-3.9.5-1.fc10.ppc64 requires libdapclient.so.2()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) pyexiv2-0.1.2-3.fc9.ppc64 requires libexiv2.so.2()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) vdrift-data-20071226-3.fc9.noarch requires vdrift = 0:20071226 From tibbs at math.uh.edu Thu Sep 11 12:53:19 2008 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 11 Sep 2008 07:53:19 -0500 Subject: mass acl opening? In-Reply-To: <48C8B476.8040108@ioa.s.u-tokyo.ac.jp> References: <7dd7ab490809102229y51412a3cwe37daeb520bf0a7c@mail.gmail.com> <48C8B476.8040108@ioa.s.u-tokyo.ac.jp> Message-ID: >>>>> "MT" == Mamoru Tasaka writes: MT> Announced on: MT> https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00007.html Well, yeah, except that the only part of that which is implemented is the rename of "cvsextras" to "packager". Mainly because the big security thing intervened. Currently nobody seems to know when the rest of the process will happen. - J< From pertusus at free.fr Thu Sep 11 12:56:18 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 11 Sep 2008 14:56:18 +0200 Subject: make chain-build doesn't work as advertised In-Reply-To: <20080910201824.4ffe19ad@metropolis.intra.city-fan.org> References: <20080910171213.GD3402@free.fr> <20080910195245.1e743cf6@metropolis.intra.city-fan.org> <20080910201824.4ffe19ad@metropolis.intra.city-fan.org> Message-ID: <20080911125618.GE3194@free.fr> On Wed, Sep 10, 2008 at 08:18:24PM +0100, Paul Howarth wrote: > > And in cases where you're using colons, you almost certainly want a > colon at the end too: > > $ make chain-build CHAIN='libdap bes : gdal : libnc-dap dap-server : dap-hdf4_handler : dap-netcdf_handler :' this went better this time. But I think I still got it wrong, because I put the colon between members of the same groups while the right thing seems to be the opposite. I think I should have done make chain-build CHAIN='libdap bes gdal : dap-server dap-hdf4_handler dap-netcdf_handler' Would that have lead to parallel build of "libdap bes gdal" and then the parallel build of "dap-server dap-hdf4_handler dap-netcdf_handler dap-freeform_handler" (which is what I wanted to achieve...)? -- Pat From paul at city-fan.org Thu Sep 11 12:59:23 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 11 Sep 2008 13:59:23 +0100 Subject: make chain-build doesn't work as advertised In-Reply-To: <20080911125618.GE3194@free.fr> References: <20080910171213.GD3402@free.fr> <20080910195245.1e743cf6@metropolis.intra.city-fan.org> <20080910201824.4ffe19ad@metropolis.intra.city-fan.org> <20080911125618.GE3194@free.fr> Message-ID: <48C9162B.4030809@city-fan.org> Patrice Dumas wrote: > On Wed, Sep 10, 2008 at 08:18:24PM +0100, Paul Howarth wrote: >> And in cases where you're using colons, you almost certainly want a >> colon at the end too: >> >> $ make chain-build CHAIN='libdap bes : gdal : libnc-dap dap-server : dap-hdf4_handler : dap-netcdf_handler :' > > this went better this time. But I think I still got it wrong, because I > put the colon between members of the same groups while the right thing > seems to be the opposite. I think I should have done > > make chain-build CHAIN='libdap bes gdal : dap-server dap-hdf4_handler dap-netcdf_handler' > > Would that have lead to parallel build of "libdap bes gdal" and then the > parallel build of > "dap-server dap-hdf4_handler dap-netcdf_handler dap-freeform_handler" > (which is what I wanted to achieve...)? Yes, assuming you're doing this from dap-freeform_handler/devel in your CVS checkout. Paul. From nicolas.mailhot at laposte.net Thu Sep 11 13:38:42 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 11 Sep 2008 15:38:42 +0200 (CEST) Subject: Feature Proposal: Use cases database In-Reply-To: <1221129641.22654.24.camel@hughsie-work> References: <1220991029.3782.47.camel@choeger6> <1221026638.2783.6.camel@hp6710.axianet.ch> <48C767E7.9040801@gmail.com> <1221059648.17299.103.camel@hughsie-work> <1221062578.21306.13.camel@rousalka.okg> <1221064863.17299.134.camel@hughsie-work> <5cb581610364a94649b91d5bc6e50928.squirrel@rousalka.dyndns.org> <1221129641.22654.24.camel@hughsie-work> Message-ID: Le Jeu 11 septembre 2008 12:40, Richard Hughes a ?crit : > > On Thu, 2008-09-11 at 11:27 +0200, Nicolas Mailhot wrote: >> I think this is a gratuituous distinction, and a full-blown distro >> comps file and a 3-line catalog file are just both ends of the same >> installation spectrum (with lots of people that could use something >> in-between). > > Could you give me some use cases for a catalog please? Digital-photo forum wants to define an initial setup for new members (automating read the FAQ install x, y and maybe z) So it defines a set composed of root set: mandatory: photo managing set default: photo editing set optionnal: fancy hardware support set and photo publication set photo editing set: default: most popular bitmap editor (gimp...) optionnal: less popular editors some people prefer (krita...) optionnal: specialized plug-ins (raw support, etc) photo managing set default: most popular picture manager optionnal: less popular managers, plugins, docs, localization fancy hardware support set optionnal: hardware support for fancy printers, colorimeter support, cameras not exposed as usb mass storage, etc photo publication set default: xyz optionnal: gallery2 set gallery2 set mandatory: gallery2 core packages default: most popular plugins optionnal: less popular plugins And that's a very focused example. An entity like Fedora's art team will want to provide a setup for people working on vector icons, on sound sets, on bitmap backgrouds (or several of those at once). Replace digital-photo forum with foo community and you'll get pretty much the same results >> Comps has the format necessary for its features and is in fact it is >> much simpler than the pk catalog format for what it does. I was >> quite >> horrified to see how complex the pk catalog format was for what it >> does. > > Want to install gnome-do? > > [PackageKit Catalog] > InstallPackages=gnome-do This is so trivial it presents almost no interest at all. If you want to go mono-app please consider eclipse, openoffice or firefox and their gazillon of plugins and extensions. >> So you didn't consider the existing format, because XML is "bad", >> and >> you didn't think a lot about your format > > Please don't tell me what I did and didn't think, I assure you I did > do > lots of research before I started the feature. > >> And lastly *because* users don't enjoy writing any config file (be >> it >> XML or not) they *need* a validation tools that tell them where they >> made typos (instead of hunting manually for missing parenthesis and >> such stuff). > > Validation tools suck. If you need a validation tool, the format is > too complex, sorry. Then your format is too complex. It *does* need validation (all the = ; () ). If you want an imperative-only simplified list of resources to install kickstart did it better with less fuss. >> This means as soon as a project tries to support more and a handful >> of >> distributions it devolves in unmaintainable spaguetti mess. You've >> made it easy to write distro-specific exceptions instead of making >> it >> easy to write the common bits. > > 95% of the package names for _applications_ are common between all > distros. > 99.9% (thanks Debian...) can be covered like this: > > [PackageKit Catalog] > InstallPackages=gnome-packagekit packagekit-gnome Well that's not the syntax on your own web page (misses ;) so we've answered the question of your format being simple enough to be typed by memory without validation >> Also, because you're mixing distributions but not considering >> scalability, that means a user that wants to check Fedora's cool >> configs site is going to need loading lots of different catalogs >> that >> all define stuff about distros he does not care about, instead of >> loading a single (or a limited number) of files that only target his >> distribution but at least are feature-complete. > > No true, sorry. The example shown on the website is a worst-case > example, not the common case. > >> In case you've not noticed it every installer be it anaconda or >> trivial windows aunt-tillie-oriented setup files expose component >> trees with some optional leaves, because optionnal nice to have but >> nor strictly necessary bits of an install set are a fact of life > > Right, you're assuming the user knows if they want the optional > package. > Have a look at these people: > C > > Do you think if any of those people know if they want gnome-do when > they > install "Cool stuff in GNOME.catalog" from a forum post they saw? This is a ridiculous example. Any "Cool stuff in GNOME" post will say APP A is a cool way to do 1 APP B is a cool way to do 2 APP C is a cool way to do 3 And post readers are perfectly able to decide if they want to do 1, 2, 3 on their computer and the vast majority of users won't want to do the full set of things that interests the initial poster. (and the http://www.packagekit.org/pk-profiles.html page is very clear that your users *do* know what they want to do with their computer) What they do want is to click on a link, get the list of A, B and C, and uncheck the apps targetting stuff they're not interested in. And BTW a resource list format that targets this kind of use case needs to allow associating comments to every resource, so instead of a stupid A B C list The user gets a A "Cool way to do 1" B "Cool way to do 2" C "Cool way to do 3" list (with optional localisation of course) >> . This is one reason we do not do monster monolithic rpm packages >> because the >> #1 request of our users is always to have the possibility not to >> install everything in all cases. > > Right, power users. Wrong, anyone not sitting on a fiber to his home. Which is the normal state of non-developper people who have other priorities than the size of their network pipesa. Think your openoffice user is going to appreciate downloading megs of optionnal openoffice stuff just in case? Think your latex man is interested in installing megs of fonts for languages he does not type? (how do you decide beforehand which language a latex user will want to type) Will the music junkie be interested in dvd playback and authoring tools (just because the average teenager does both music and video)? Presets are fine. Inflexible presets lead to resource waste and menu clutter users do complain of. -- Nicolas Mailhot From joshuacov at googlemail.com Thu Sep 11 13:42:58 2008 From: joshuacov at googlemail.com (Joshua C.) Date: Thu, 11 Sep 2008 15:42:58 +0200 Subject: modesetting feature status In-Reply-To: <1221127474.20727.4.camel@optimus> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <48C8E4CE.5040700@hhs.nl> <1221127474.20727.4.camel@optimus> Message-ID: <5f6f8c5f0809110642i3937c485mfa14cc226b527b5e@mail.gmail.com> 2008/9/11 Dave Airlie : > > I'm 100% interested in the output doesn't light up kinda bugs. > > If anyone encounters these what would be useful is to over ssh > > boot with nomodeset 3 - go to no X runlevel. > rmmod radeon drm > modprobe drm debug=1 > modprobe radeon modeset=1 > > and attach dmesg to a bug, also add an xorg log from a nomodeset boot > > Next on the list are oops and crashes. > > If I can solve the crashers and modeset not starting I can start on the > artifacts, rendering speed regressions and 3D bits. > > but from the beta release I'd feel free to file any bugs against it. > > Dave. Tried it but without ssh there is nothing in /var/log/messages after restart. Only the following [drm] Module unloaded [drm] Initialized drm 1.1.0 20060810 imklog 3.18.1, log source = /proc/kmsg started. After modprobe radeon modeset=1 everything freezes - no display, touchpad, keyboard, only hardware reset helps. This way I cannot extract /proc/kmsg. Is there another way to help with debugging? My bug https://bugzilla.redhat.com/show_bug.cgi?id=461545 From ajax at redhat.com Thu Sep 11 13:44:26 2008 From: ajax at redhat.com (Adam Jackson) Date: Thu, 11 Sep 2008 09:44:26 -0400 Subject: modesetting feature status In-Reply-To: <544eb990809110421j7f752186mef1e9c1b17e1dec6@mail.gmail.com> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <544eb990809110421j7f752186mef1e9c1b17e1dec6@mail.gmail.com> Message-ID: <1221140667.4345.12.camel@atropine.boston.devel.redhat.com> On Thu, 2008-09-11 at 12:21 +0100, Bill Crawford wrote: > On 11/09/2008, Dave Airlie wrote: > > > We are targeting for F10 support for radeon GPUs from r300 to r500 (and > > possibly r600/r700), and Intel GPUs from i830 to GM45 (though it may end > > up i915 and up only) > > Will r200 class hardware never get kernel modesetting? I've been > looking forward to getting this for a number of reasons ... I wouldn't say "never", but probably not in F10. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From aportal at univ-montp2.fr Thu Sep 11 13:57:53 2008 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Thu, 11 Sep 2008 15:57:53 +0200 Subject: Unable to access cvs In-Reply-To: <48C2C03B.9000807@gmail.com> References: <200809061528.35585.alain.portal@free.fr> <48C2C03B.9000807@gmail.com> Message-ID: <200809111557.53948.aportal@univ-montp2.fr> Hi, Le samedi 6 septembre 2008 ? 19:39, Toshio Kuratomi a ?crit?: > You need to either upload a new ssh key or reupload your old one. > > If your old key was DSA you'll need a new one. > If you stored your private key on a Fedora Infrastructure server you > should create a new one for safety. > If you had an RSA key and only used it for cvs checkin, then reuploading > the old key should be okay. > > Reupload in FAS:: > https://admin.fedoraproject.org/accounts/ Thanks for the informations. As you suggested, I created and uploaded a new RSA key. I successfully commited a new spec file, successfully tagged the new branch, but I get an error when I'm trying to build the package: [alain at zarathoustra devel]$ make build /usr/bin/koji build dist-f10 'cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/man-pages-fr/devel#man-pages-fr-2_80_0-3_fc10' OpenSSL.SSL.Error: [] make: *** [koji] Erreur 1 Any idea? Regards, Alain -- La version fran?aise des pages de manuel Linux http://manpagesfr.free.fr From hughsient at gmail.com Thu Sep 11 14:04:50 2008 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 11 Sep 2008 15:04:50 +0100 Subject: Feature Proposal: Use cases database In-Reply-To: References: <1220991029.3782.47.camel@choeger6> <1221026638.2783.6.camel@hp6710.axianet.ch> <48C767E7.9040801@gmail.com> <1221059648.17299.103.camel@hughsie-work> <1221062578.21306.13.camel@rousalka.okg> <1221064863.17299.134.camel@hughsie-work> <5cb581610364a94649b91d5bc6e50928.squirrel@rousalka.dyndns.org> <1221129641.22654.24.camel@hughsie-work> Message-ID: <1221141890.22654.75.camel@hughsie-work> On Thu, 2008-09-11 at 15:38 +0200, Nicolas Mailhot wrote: > Replace digital-photo forum with foo community and you'll get pretty > much the same results You're not meant to have one catalog file for all of that. You could just have a file called "Gallery integration.catalog" -- it's not comps where one file has to describe subsets. > > [PackageKit Catalog] > > InstallPackages=gnome-do > > This is so trivial it presents almost no interest at all. If you want > to go mono-app please consider eclipse, openoffice or firefox and > their gazillon of plugins and extensions. get hacking on packagekit.catalog: [PackageKit Catalog] # Common packages InstallPackages=autoconf;automake;intltool;libtool;pkgconfig # Fedora InstallPackages(fedora)=glib2-devel;gvfs-devel;dbus-glib-devel;NetworkManager-glib-devel;PolicyKit-devel; # Pardus InstallPackages(pardus)=NetworkManager-devel;PolicyKit-devel;autoconf;automake;dbus-devel;dbus-glib-devel;docbook-to-man;gettext-devel;glib2-devel;gtk-doc;poldek-devel;python-devel;readline-devel;rpm-pythonprov;sqlite3-devel # Forsight InstallPackages(forsight)=gnome-development;dbus-development > Well that's not the syntax on your own web page (misses ;) so we've > answered the question of your format being simple enough to be typed > by memory without validation You can use either delimiter, no package names have spaces in them. I guess it might even make sense to add ',' to the delimiter list too. > What they do want is to click on a link, get the list of A, B and C, > and uncheck the apps targetting stuff they're not interested in. They won't know what most of the applications are. Also, applications != packages, so you have to be a bit more wise than just knowing the application name. > Wrong, anyone not sitting on a fiber to his home. I sit on a low speed broadband connection. I don't think I can even get fiber in my road, regardless, I don't spend much time installing new applications. > Think your openoffice user is going to appreciate downloading megs of > optionnal openoffice stuff just in case? I don't think it matters if people install 45Mb rather than 33Mb -- downloading 45Mb takes me about 10 minutes, so I just let it install in the background or go and get a cup of tea. Bandwidth and disk space are cheap. If you're that low on either, then catalogs are not suitable for your use case. > Think your latex man is interested in installing megs of fonts for > languages he does not type? (how do you decide beforehand which > language a latex user will want to type) You don't, you patch the latex program to install it's own font when it's first used in a document (trivial). Let the computer do all the hard work, and let the latex man get on with writing latex rather than working out which font face should be downloaded. > Will the music junkie be interested in dvd playback and authoring > tools (just because the average teenager does both music and video)? I don't see the logic. Catalog files are fine grained -- it's okay to download 5 catalog files and execute then all at once -- gpk-install-catalog is smart enough to combine them into one set of changes. > Presets are fine. Inflexible presets lead to resource waste and menu > clutter users do complain of. More people complain that Linux is "hard to use" than complain they have useless packages on their disk. I can say that, as I've asked a number real users (not developers). For instance, my mum doesn't care there are icons in the menu she doesn't use, but she does care when there isn't any clipart installed. Not all user of Linux have hours to waste making the perfect streamlined setup, most use the computer to actually get something done. Richard. From paul at city-fan.org Thu Sep 11 14:12:05 2008 From: paul at city-fan.org (Paul Howarth) Date: Thu, 11 Sep 2008 15:12:05 +0100 Subject: Unable to access cvs In-Reply-To: <200809111557.53948.aportal@univ-montp2.fr> References: <200809061528.35585.alain.portal@free.fr> <48C2C03B.9000807@gmail.com> <200809111557.53948.aportal@univ-montp2.fr> Message-ID: <48C92735.3040008@city-fan.org> Alain PORTAL wrote: > Hi, > > Le samedi 6 septembre 2008 ? 19:39, Toshio Kuratomi a ?crit : > >> You need to either upload a new ssh key or reupload your old one. >> >> If your old key was DSA you'll need a new one. >> If you stored your private key on a Fedora Infrastructure server you >> should create a new one for safety. >> If you had an RSA key and only used it for cvs checkin, then reuploading >> the old key should be okay. >> >> Reupload in FAS:: >> https://admin.fedoraproject.org/accounts/ > > Thanks for the informations. > As you suggested, I created and uploaded a new RSA key. > > I successfully commited a new spec file, successfully tagged the new branch, > but I get an error when I'm trying to build the package: > > [alain at zarathoustra devel]$ make build > /usr/bin/koji build > dist-f10 'cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/man-pages-fr/devel#man-pages-fr-2_80_0-3_fc10' > OpenSSL.SSL.Error: [] > make: *** [koji] Erreur 1 > > Any idea? You'll need new certificates too: https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00962.html Paul. From jwilson at redhat.com Thu Sep 11 14:20:33 2008 From: jwilson at redhat.com (Jarod Wilson) Date: Thu, 11 Sep 2008 10:20:33 -0400 Subject: Interested in Fedora on Smaller Machines? In-Reply-To: <48A1E9D7.1010106@blagblagblag.org> References: <1218552790.27760.3.camel@aglarond.local> <1218567153.27760.10.camel@aglarond.local> <48A1E9D7.1010106@blagblagblag.org> Message-ID: <200809111020.34015.jwilson@redhat.com> On Tuesday 12 August 2008 15:51:51 jeff wrote: > Jeremy Katz wrote: > > On Tue, 2008-08-12 at 12:50 -0300, jeff wrote: > >> Jeremy Katz wrote: > >>> Smaller form-factor machines such as the Asus eeePC have gotten a fair > >>> bit of the tech press spotlight of late. Have you bought one with the > >>> idea of running Fedora on it? Or have you thought about doing so? My own Acer Aspire One arrived two days ago. Its got rawhide on it now. Needless to say, we don't boot quite as fast as the stock Linpus Linux Lite, but I definitely prefer a full-fledged Fedora install. > For the eee 701/900 i think just about everything is supported in stock > f9-updates kernel except wifi. On the 900 with 1 gig of RAM something as > large as gnome runs well, but something more lightweight is preferable of > course. Once the ath5k driver is there, using NetworkManager is a treat and > *really* "just works". [...] > > Luckily, wifi should be in for 2.6.27, although I need to actually try a > > newer image on my ar2425 based box. I'll probably do that when I get > > home (since that's where it is) > > ar2425 support is in 2.6.27, but I haven't seen the extra patches that are > needed for the eee 701/900 (ath5k) arrive there yet. mickflemms' patchset-8 > applies without too much hassle. The AR2425 in the AAO works quite nicely with current rawhide kernels. I've been able to connect it to both WPA2- and WEP-protected base stations just fine. That said, I think I'm still going to yank it out in favor of a spare iwl5350 I have laying about when I crack the thing open to put more memory in tonight. The only things I've noticed that are a bit quirky are some video artifacts when running an external monitor and some dmesg spew about interrupts from the jmb38x_ms driver when using SD cards (haven't tried any other type), but both do still function. Suspend and resume works w/o a hitch as well. -- Jarod Wilson jarod at redhat.com From skvidal at fedoraproject.org Thu Sep 11 14:20:49 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 11 Sep 2008 10:20:49 -0400 Subject: RFE: yum transaction auto-complete In-Reply-To: <3da3b5b40809110058j5be7edddo18bc2dd889973bbb@mail.gmail.com> References: <3da3b5b40809110058j5be7edddo18bc2dd889973bbb@mail.gmail.com> Message-ID: <1221142849.987.161.camel@rosebud> On Thu, 2008-09-11 at 09:58 +0200, Ahmed Kamal wrote: > I would like to propose the following RFE. Whenever yum is running, it > creates a state file. If the machine hangs/crashes during an upgrade. > Whenever the machine reboots, and yum is run again (or package kit?), > that state file should be detected. The user should be warned about an > incomplete software installation. The user should be prompted to > automatically run yum-complete-transaction. There's a couple of problems with doing this on every run: 1. if the next run is non interactive I'm not sure what is the more appropriate default 2. if the next run is 'yum remove something' does it really make sense to complete the last transaction (possibly downloading a bunch of stuff) first? Now, I would be fine with emitting a "there are unfinished transactions" message and a small sleep. But I don't think intervening with what the user is doing is going to necessarily be helpful. Though I'm not terribly bound to this idea. -sv From a.badger at gmail.com Thu Sep 11 14:27:57 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 11 Sep 2008 07:27:57 -0700 Subject: mass acl opening? In-Reply-To: References: <7dd7ab490809102229y51412a3cwe37daeb520bf0a7c@mail.gmail.com> <48C8B476.8040108@ioa.s.u-tokyo.ac.jp> Message-ID: <48C92AED.1000501@gmail.com> Jason L Tibbitts III wrote: >>>>>> "MT" == Mamoru Tasaka writes: > > MT> Announced on: > MT> https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00007.html > > Well, yeah, except that the only part of that which is implemented is > the rename of "cvsextras" to "packager". Mainly because the big > security thing intervened. Currently nobody seems to know when the > rest of the process will happen. > Casey, Packager infrastructure is pretty much back now, when do you want to start the next phase? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From aportal at univ-montp2.fr Thu Sep 11 14:31:15 2008 From: aportal at univ-montp2.fr (Alain PORTAL) Date: Thu, 11 Sep 2008 16:31:15 +0200 Subject: Unable to access cvs In-Reply-To: <48C92735.3040008@city-fan.org> References: <200809061528.35585.alain.portal@free.fr> <200809111557.53948.aportal@univ-montp2.fr> <48C92735.3040008@city-fan.org> Message-ID: <200809111631.15772.aportal@univ-montp2.fr> Le jeudi 11 septembre 2008 ? 16:12, Paul Howarth a ?crit?: > You'll need new certificates too: > > https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00962.html I already got the new certificates. But perhaps I got also new certificates a second time on another machine.... I'll check when I'll be on it. Thanks. Alain -- La version fran?aise des pages de manuel Linux http://manpagesfr.free.fr From john.ellson at comcast.net Thu Sep 11 14:40:35 2008 From: john.ellson at comcast.net (John Ellson) Date: Thu, 11 Sep 2008 10:40:35 -0400 Subject: what is keeping per-user state outside of user's $HOME ? Message-ID: <48C92DE3.8080406@comcast.net> I have a problem when my userid, and only my userid, has no Lock Screen menu item or applet. I reported this problem against gnome-screensaver (BZ# 457147) but its not progressing so perhaps the problem should be reported against a different component? What is really weird, and bothersome, is that this state (no Lock Screen menu item) doesn't get reset by: rm -rf .gnome .gnome2 .gconf .gconfd .metacity Where else is per-user state kept ? My system is x86_64 Rawhide. *||* -- John Ellson From cdahlin at redhat.com Thu Sep 11 14:49:33 2008 From: cdahlin at redhat.com (Casey Dahlin) Date: Thu, 11 Sep 2008 10:49:33 -0400 Subject: mass acl opening? In-Reply-To: <48C92AED.1000501@gmail.com> References: <7dd7ab490809102229y51412a3cwe37daeb520bf0a7c@mail.gmail.com> <48C8B476.8040108@ioa.s.u-tokyo.ac.jp> <48C92AED.1000501@gmail.com> Message-ID: <48C92FFD.30905@redhat.com> Toshio Kuratomi wrote: > Jason L Tibbitts III wrote: > >>>>>>> "MT" == Mamoru Tasaka writes: >>>>>>> >> MT> Announced on: >> MT> https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00007.html >> >> Well, yeah, except that the only part of that which is implemented is >> the rename of "cvsextras" to "packager". Mainly because the big >> security thing intervened. Currently nobody seems to know when the >> rest of the process will happen. >> >> > Casey, > > Packager infrastructure is pretty much back now, when do you want to > start the next phase? > > -Toshio > > > We've seeded uberpackager already, and locked out packager, correct? I'm good with going ahead asap. --CJD From skvidal at fedoraproject.org Thu Sep 11 14:52:54 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 11 Sep 2008 10:52:54 -0400 Subject: Boot speedup with readahead In-Reply-To: References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> Message-ID: <1221144774.987.175.camel@rosebud> On Thu, 2008-09-11 at 11:34 +0300, Panu Matilainen wrote: > > So this seems to work - now the question is - should we push for this to > > go into rpm instead? > > Not instead, but to rpm *too*, yes. > > Quite obviously an action that's currently done from say %post script > should stay at rpm level, moving some things to be only done once per > transaction is just an optimization really. But yum knows a lot more about > the surrounding world than rpm does, such as which repository a package > came from which is something rpm has no clue about, and thus it can do > things in post-transaction that rpm simply could not do. I don't have an > example use-case in mind atm but I'm sure somebody can come up with some > relatively sane example ;) Recording info on what happened in each transaction in an external database and wanting to include the info on where a package came from. I was thinking of adding a set of variables you could pass to external scripts. Something like: 1. pkg nevra 2. pkg repo (if pkg being installed/updated) 3. action being taken on package (install, update, erase, etc) 4. package checksum (if pkg being installed/updated) Afaict all but 2 should be doable inside rpm. I'm just a little blurry on how easy it will be to implement in rpm. If you want it in rpm, though, that's fine by me. I'm holding off checking this plugin into yum-utils until after this is discussed a bit. -sv From skvidal at fedoraproject.org Thu Sep 11 14:54:01 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 11 Sep 2008 10:54:01 -0400 Subject: Boot speedup with readahead In-Reply-To: <1221129185.18327.181.camel@beck.corsepiu.local> References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <20080911090752.GC17152@mokona.greysector.net> <1221129185.18327.181.camel@beck.corsepiu.local> Message-ID: <1221144841.987.177.camel@rosebud> On Thu, 2008-09-11 at 12:33 +0200, Ralf Corsepius wrote: > On Thu, 2008-09-11 at 12:18 +0300, Panu Matilainen wrote: > > > Where a package came from is just one example of things that yum knows > > that rpm doesn't. Whether there's any real use-case for that particular > > piece of information is entirely different question. The point is that yum > > is in position to do various things that rpm cannot possibly do because > > they operate on different levels and with different amount of information > > available to them. > I would turn this argument around: rpm missed its opportunities "to do > various things" forcing people to circumvent rpm's limitations by > ruck-sacking rpm with add-ons such as yum, yast/ycl etc. okay - but how does the above change anything. Yes, there was about 3-4 years of relatively no major rpm devel. And people engineered around the outside of it. 1. why is this bad? 2. why is this particularly surprising? -sv From csnook at redhat.com Thu Sep 11 14:56:42 2008 From: csnook at redhat.com (Christopher Snook) Date: Thu, 11 Sep 2008 10:56:42 -0400 Subject: what is keeping per-user state outside of user's $HOME ? In-Reply-To: <48C92DE3.8080406@comcast.net> References: <48C92DE3.8080406@comcast.net> Message-ID: <48C931AA.6050001@redhat.com> John Ellson wrote: > I have a problem when my userid, and only my userid, has no Lock Screen > menu item or applet. > > I reported this problem against gnome-screensaver (BZ# 457147) but its > not progressing so perhaps the problem should be reported against a > different component? > > What is really weird, and bothersome, is that this state (no Lock Screen > menu item) doesn't get reset by: > rm -rf .gnome .gnome2 .gconf .gconfd .metacity > > Where else is per-user state kept ? /tmp -- Chris From dominik at greysector.net Thu Sep 11 15:01:25 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 11 Sep 2008 17:01:25 +0200 Subject: Boot speedup with readahead In-Reply-To: <1221144841.987.177.camel@rosebud> References: <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <20080911090752.GC17152@mokona.greysector.net> <1221129185.18327.181.camel@beck.corsepiu.local> <1221144841.987.177.camel@rosebud> Message-ID: <20080911150125.GG17152@mokona.greysector.net> On Thursday, 11 September 2008 at 16:54, Seth Vidal wrote: > On Thu, 2008-09-11 at 12:33 +0200, Ralf Corsepius wrote: > > On Thu, 2008-09-11 at 12:18 +0300, Panu Matilainen wrote: > > > > > Where a package came from is just one example of things that yum knows > > > that rpm doesn't. Whether there's any real use-case for that particular > > > piece of information is entirely different question. The point is that yum > > > is in position to do various things that rpm cannot possibly do because > > > they operate on different levels and with different amount of information > > > available to them. > > I would turn this argument around: rpm missed its opportunities "to do > > various things" forcing people to circumvent rpm's limitations by > > ruck-sacking rpm with add-ons such as yum, yast/ycl etc. > > okay - but how does the above change anything. Yes, there was about 3-4 > years of relatively no major rpm devel. And people engineered around the > outside of it. > > 1. why is this bad? It's bad because of duplicated work. We now have a dozen of rpm frontends all of which do mostly the same things using different code. > 2. why is this particularly surprising? Nobody said it was surprising. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From skvidal at fedoraproject.org Thu Sep 11 15:01:05 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 11 Sep 2008 11:01:05 -0400 Subject: recover from broken yum transaction In-Reply-To: <46a038f90809102242w31869559mc6f0b22a291f52b9@mail.gmail.com> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <46a038f90809102242w31869559mc6f0b22a291f52b9@mail.gmail.com> Message-ID: <1221145265.987.183.camel@rosebud> On Thu, 2008-09-11 at 17:42 +1200, Martin Langhoff wrote: > On Thu, Sep 11, 2008 at 3:50 PM, Seth Vidal wrote: > > When this happens you should run: > > yum-complete-transaction > > Interesting toy! I think you mentioned it at Fudcon Boston and I > hadn't been able to recall the right name. > > Thinking of using it in the use case of the school server (very > unreliable power, no sysadmins available, 100% unattended updates) - > > - Is it safe to run at boot time via an init script? as long as the network is up, it should be. > - Is there an easy way to check for pending transactions? yum-complete-transaction checks for them itself > - Does it have useful exit codes indicating whether it's done anything? If the results codes are not good enough we can fix that easily enough. > Is that different from `package-cleanup --problems` ? --problems reports a different set of things - package conflicts and unresolved deps. A dupe is not, implicitly, a problem. it CAN be, but it is not always. -sv From john.ellson at comcast.net Thu Sep 11 15:03:00 2008 From: john.ellson at comcast.net (John Ellson) Date: Thu, 11 Sep 2008 11:03:00 -0400 Subject: what is keeping per-user state outside of user's $HOME ? In-Reply-To: <48C931AA.6050001@redhat.com> References: <48C92DE3.8080406@comcast.net> <48C931AA.6050001@redhat.com> Message-ID: <48C93324.4050500@comcast.net> Christopher Snook wrote: > John Ellson wrote: >> I have a problem when my userid, and only my userid, has no Lock >> Screen menu item or applet. >> >> I reported this problem against gnome-screensaver (BZ# 457147) but >> its not progressing so perhaps the problem should be reported >> against a different component? >> >> What is really weird, and bothersome, is that this state (no Lock >> Screen menu item) doesn't get reset by: >> rm -rf .gnome .gnome2 .gconf .gconfd .metacity >> >> Where else is per-user state kept ? > > /tmp > > -- Chris > No, tried that. its not in any file in /tmp or /var/tmp -- John Ellson From kanarip at kanarip.com Thu Sep 11 15:03:44 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 11 Sep 2008 17:03:44 +0200 Subject: Fedora-release: picking the GPG files post-transition for a spin In-Reply-To: <46a038f90809101700t1b444ffaq407e60a67ca5589c@mail.gmail.com> References: <46a038f90809101700t1b444ffaq407e60a67ca5589c@mail.gmail.com> Message-ID: <48C93350.9080306@kanarip.com> Martin Langhoff wrote: > I am working on a custom "fedora-release" replacement package > (xs-release) for a custom spin that will be ready at the end of the > month. My understanding is that it makes sense to only ship the new > GPG keys and new repos. > > There is a tiny user-base still using a F7-based spin. From what I can > see, they'll be able to upgrade with anaconda or yum directly to the > post-transition packages. > > Does my plan make sense? Is there any step in the upgrade machinery > that I am missing that might require the old keys? > There should be no problem to continue as usual. Provided the -release package you include holds the new GPG key configuration as well as the new repository location, the systems should not have to go through the transition after the installation. Kind regards, Jeroen van Meeuwen -kanarip From katzj at redhat.com Thu Sep 11 15:06:39 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 11 Sep 2008 11:06:39 -0400 Subject: modesetting feature status In-Reply-To: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> Message-ID: <1221145599.11745.3.camel@aglarond.local> On Thu, 2008-09-11 at 17:18 +1000, Dave Airlie wrote: > For the beta we are only going to enable Radeon support for the r300 to > r500 class of hardware, while we await upstream changes to the Intel > driver. ... we really shouldn't shove in major changes like this for a significant chunk of hardware post-beta. Putting it in the beta means that we get a relatively large chunk of testing done due to the visibility surrounding the beta announce. As well as having time to fix large problems that are uncovered. Later milestones both a) lack the time for changes after them and b) the visibility. > The intel mode code is more mature Yeah, I've seen intel's "mature" code before. Excuse me if this is anything but reassuring. Jeremy From skvidal at fedoraproject.org Thu Sep 11 15:02:31 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 11 Sep 2008 11:02:31 -0400 Subject: recover from broken yum transaction In-Reply-To: <3da3b5b40809110053n6ebb265vab921118e87dc774@mail.gmail.com> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <46a038f90809102242w31869559mc6f0b22a291f52b9@mail.gmail.com> <3da3b5b40809110053n6ebb265vab921118e87dc774@mail.gmail.com> Message-ID: <1221145351.987.185.camel@rosebud> On Thu, 2008-09-11 at 09:53 +0200, Ahmed Kamal wrote: > Trying rpm -Va, I am getting lots of these lines > > S.?..... /usr/bin/kblankscrn.kss > S.?..... /usr/bin/kcminit > S.?..... /usr/bin/kcminit_startup > > Basically, the size has changed, and the md5 check cannot be > performed ?! I understand this is due to "prelink", but that sux ! > This effectively kills the rpm -V functionality. Is it not possible to > prelink binaries on the server before wrapping them into rpms ? Any > suggested solution around this ? > You might consider reinstalling kdebase-workspace yum reinstall kdebase-workspace see if that works for you. -sv From pemboa at gmail.com Thu Sep 11 15:14:28 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 11 Sep 2008 10:14:28 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <544eb990809110414x44c1c563l7d0da7859c166780@mail.gmail.com> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <544eb990809110414x44c1c563l7d0da7859c166780@mail.gmail.com> Message-ID: <16de708d0809110814l6eda770ey54db2073391e0511@mail.gmail.com> On Thu, Sep 11, 2008 at 6:14 AM, Bill Crawford wrote: > On 11/09/2008, Arthur Pemberton wrote: > >> * Sounblaster Live 5.1 PCI -- has full 6 channel audio before, I had >> for a short while after enabling it as per the pulseaudio wiki, but no >> more > > If it's one of the SBs with multiple hardware channels, unless you are > likely to want >32 separate apps pumping out sound at once, disable PA > and just access the card through ALSA directly. It's worked ok for me > :o) I'm pretty sure disabling PulseAudio will work since it worked before PulseAudio. But disabling it defeats the purpose. -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From jkeating at redhat.com Thu Sep 11 15:15:22 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 11 Sep 2008 08:15:22 -0700 Subject: modesetting feature status In-Reply-To: <1221145599.11745.3.camel@aglarond.local> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221145599.11745.3.camel@aglarond.local> Message-ID: <1221146122.3388.169.camel@luminos.localdomain> On Thu, 2008-09-11 at 11:06 -0400, Jeremy Katz wrote: > ... we really shouldn't shove in major changes like this for a > significant chunk of hardware post-beta. Putting it in the beta means > that we get a relatively large chunk of testing done due to the > visibility surrounding the beta announce. As well as having time to fix > large problems that are uncovered. Later milestones both a) lack the > time for changes after them and b) the visibility. Yeah, I'm not so keen on doing all of this post-beta. We've got enough stability problems with F10 as it is. This honestly feels like one of those features that just isn't 'testable' by Beta, and thus needs to enact the contingency plan. https://fedoraproject.org/wiki/Features/KernelModesetting#Contingency_Plan How do things look for that contingency plan. Is it even possible at this point? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Thu Sep 11 15:17:08 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 11 Sep 2008 08:17:08 -0700 Subject: what is keeping per-user state outside of user's $HOME ? In-Reply-To: <48C92DE3.8080406@comcast.net> References: <48C92DE3.8080406@comcast.net> Message-ID: <1221146228.3388.170.camel@luminos.localdomain> On Thu, 2008-09-11 at 10:40 -0400, John Ellson wrote: > > I have a problem when my userid, and only my userid, has no Lock Screen > menu item or applet. (having not looked at the bug) Are you sure it's not a ConsoleKit interaction making the session think your user isn't at the console? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dcbw at redhat.com Thu Sep 11 15:29:13 2008 From: dcbw at redhat.com (Dan Williams) Date: Thu, 11 Sep 2008 11:29:13 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> Message-ID: <1221146953.771.19.camel@localhost.localdomain> On Wed, 2008-09-10 at 20:56 -0500, Arthur Pemberton wrote: > I have a lot of seemingly pulse audio related issues on my F9 desktop. > Since I really like the idea behind Pulseaudio, I would like to see > these get sorted out, and would like to know how I can help in terms > of providing useful information. > > Here is my situation > > * Sounblaster Live 5.1 PCI -- has full 6 channel audio before, I had > for a short while after enabling it as per the pulseaudio wiki, but no > more > * Tvtime -- no audio (doing `padsp sox -r 48000 -w -c 2 -t ossdsp > /dev/dsp -t ossdsp /dev/dsp` works, but causes noticeable lag) > * Amarok (xine) -- audio, susceptible to crashes, esp when I scroll to > fast in Firefox > * Kopete -- used to work, mysteriously stopped working > * Konversation -- never worked > * Mythfront -- no sound yet (haven't followed > http://svn.mythtv.org/trac/ticket/3598#comment:16 yet) > * V4L tv capture card -- no sound now, used to rely on capturing AUX > on sound card before > * PulseAudio -- seems to average 30% CPU usage when playing music, > doesn't like me using Firefox too much (seems like a resource issue) > > Things I use, albeit infrequently, but just work: > * flash-plugin Make sure you have libflashsupport installed. I makes flash happier with pulseaudio. Dan From john.ellson at comcast.net Thu Sep 11 15:30:53 2008 From: john.ellson at comcast.net (John Ellson) Date: Thu, 11 Sep 2008 11:30:53 -0400 Subject: what is keeping per-user state outside of user's $HOME ? In-Reply-To: <1221146228.3388.170.camel@luminos.localdomain> References: <48C92DE3.8080406@comcast.net> <1221146228.3388.170.camel@luminos.localdomain> Message-ID: <48C939AD.4040808@comcast.net> Jesse Keating wrote: > On Thu, 2008-09-11 at 10:40 -0400, John Ellson wrote: > >> I have a problem when my userid, and only my userid, has no Lock Screen >> menu item or applet. >> > > > (having not looked at the bug) > > Are you sure it's not a ConsoleKit interaction making the session think > your user isn't at the console? > > Only if ConsoleKit is keeping per user-state. If I login at the console as any other user I get the Lock Screen menu item. I just tried moving aside my home directorory, deleting my userid, removing everything in /tmp and /var/tmp, rebooting creating a new userid with the same name (but different user and group numbers), and it still has no Lock Screen!!! Something is keeping information about userid "ellson" outside of /home/ellson, but what? -- John Ellson From pemboa at gmail.com Thu Sep 11 15:36:22 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 11 Sep 2008 10:36:22 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1221146953.771.19.camel@localhost.localdomain> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <1221146953.771.19.camel@localhost.localdomain> Message-ID: <16de708d0809110836u4f68238fse97e4727a98d74d3@mail.gmail.com> On Thu, Sep 11, 2008 at 10:29 AM, Dan Williams wrote: > On Wed, 2008-09-10 at 20:56 -0500, Arthur Pemberton wrote: >> Things I use, albeit infrequently, but just work: >> * flash-plugin > > Make sure you have libflashsupport installed. I makes flash happier > with pulseaudio. As I tried to say, flash works, even though it it is a low priority for me. And I don't want the thread to seem like I am asking for end-user support on the devel list. -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From pemboa at gmail.com Thu Sep 11 15:37:24 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 11 Sep 2008 10:37:24 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080911120349.GD15457@angus.ind.WPI.EDU> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080911120349.GD15457@angus.ind.WPI.EDU> Message-ID: <16de708d0809110837v4036ee2bp9b0d2f6d5981eaaa@mail.gmail.com> On Thu, Sep 11, 2008 at 7:03 AM, Chuck Anderson wrote: > On Wed, Sep 10, 2008 at 08:56:12PM -0500, Arthur Pemberton wrote: >> I have a lot of seemingly pulse audio related issues on my F9 desktop. >> Since I really like the idea behind Pulseaudio, I would like to see >> these get sorted out, and would like to know how I can help in terms >> of providing useful information. >> >> Here is my situation >> >> * Sounblaster Live 5.1 PCI -- has full 6 channel audio before, I had >> for a short while after enabling it as per the pulseaudio wiki, but no >> more > > Check out these two bugs. You might be hitting this where it is > trying to use the built-in card instead of your addon PCI card by > default, perhaps only for some applications: > > https://bugzilla.redhat.com/show_bug.cgi?id=441506 > https://bugzilla.redhat.com/show_bug.cgi?id=448477 I'll follow up on those reports and attempt to add useful information. I have since previous OS (FC7) disabled the onboard sound card at the BIOS level. -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From bnocera at redhat.com Thu Sep 11 15:41:16 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 11 Sep 2008 16:41:16 +0100 Subject: libbluetooth soname bump Message-ID: <1221147676.24928.196.camel@cookie.hadess.net> Heya, It all went a bit quick, and the new bluez 4.x utilities and libraries have landed in rawhide. This means that a number of applications needed to be rebuilt. If your application was using the bluetooth library itself, there are very few changes to the underlying API, only if you used to parse SDP records by hand. See this example patch: http://cvs.fedoraproject.org/viewvc/rpms/obex-data-server/devel/obex-data-server-0.3.4-bluez4.patch?view=markup For applications that used the D-Bus API, well, you'll need to update them to use the new API. Only apps I know that do that are apps I maintain, so I wouldn't worry about it :) Many thanks to the maintainers who already did their own rebuilds in meantime. Here's the list of rebuilds I made. Let me know if I forgot anything. * Rebuilt apps: pilot-link obex-data-server gnome-vfs2-obexftp libbtctl libwiimote gnokii gnome-phone-manager gnome-bluetooth obexftp gypsy libsyncml amora pybluez callweaver-bluetooth libopensync-plugin-irmc pulseaudio-module-bluetooth * Apps that still need porting: gnome-user-share nautilus-sendto obex-data-server * Apps that I couldn't rebuilt, didn't rebuild: gammu (closed ACLs) openobex-apps (closed ACLs) obexfs (http://koji.fedoraproject.org/koji/taskinfo?taskID=820234, not bluez related) asterisk-mobile (http://koji.fedoraproject.org/koji/taskinfo?taskID=820332, not bluez related) kdebluetooth (http://koji.fedoraproject.org/koji/taskinfo?taskID=820405, missing BR) Cheers From a.badger at gmail.com Thu Sep 11 15:47:07 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 11 Sep 2008 08:47:07 -0700 Subject: mass acl opening? In-Reply-To: <48C92FFD.30905@redhat.com> References: <7dd7ab490809102229y51412a3cwe37daeb520bf0a7c@mail.gmail.com> <48C8B476.8040108@ioa.s.u-tokyo.ac.jp> <48C92AED.1000501@gmail.com> <48C92FFD.30905@redhat.com> Message-ID: <48C93D7B.9020100@gmail.com> Casey Dahlin wrote: > Toshio Kuratomi wrote: >> Jason L Tibbitts III wrote: >> >>>>>>>> "MT" == Mamoru Tasaka writes: >>>>>>>> >>> MT> Announced on: >>> MT> >>> https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00007.html >>> >>> >>> Well, yeah, except that the only part of that which is implemented is >>> the rename of "cvsextras" to "packager". Mainly because the big >>> security thing intervened. Currently nobody seems to know when the >>> rest of the process will happen. >>> >>> >> Casey, >> >> Packager infrastructure is pretty much back now, when do you want to >> start the next phase? >> >> -Toshio >> >> >> > We've seeded uberpackager already, and locked out packager, correct? > > I'm good with going ahead asap. > Locking out packager is the next step. I can go ahead with that today. From reading the announcement, that will just leave us with #4 left to do. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From nicolas.mailhot at laposte.net Thu Sep 11 14:41:44 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 11 Sep 2008 16:41:44 +0200 (CEST) Subject: Feature Proposal: Use cases database In-Reply-To: <1221141890.22654.75.camel@hughsie-work> References: <1220991029.3782.47.camel@choeger6> <1221026638.2783.6.camel@hp6710.axianet.ch> <48C767E7.9040801@gmail.com> <1221059648.17299.103.camel@hughsie-work> <1221062578.21306.13.camel@rousalka.okg> <1221064863.17299.134.camel@hughsie-work> <5cb581610364a94649b91d5bc6e50928.squirrel@rousalka.dyndns.org> <1221129641.22654.24.camel@hughsie-work> <1221141890.22654.75.camel@hughsie-work> Message-ID: Le Jeu 11 septembre 2008 16:04, Richard Hughes a ?crit : > > On Thu, 2008-09-11 at 15:38 +0200, Nicolas Mailhot wrote: >> Replace digital-photo forum with foo community and you'll get pretty >> much the same results > > You're not meant to have one catalog file for all of that. This was a much more focused example than your own "Cool GNOME stuff list". > You could > just have a file called "Gallery integration.catalog" I don't see how you can both maintain user can not discover applications without catalogs, and affirm he can discover catalogs by himself. And even if you have a separate "Gallery integration.catalog" and you manage to get the user to discover it that does not answer the optionnal elements part. Are you going to split the gallery catalog itself too? What's the advantage of catalogs over packages if you end up with long catalog lists and users needing to perform installation logic manually? > -- it's not > comps > where one file has to describe subsets. > >> > [PackageKit Catalog] >> > InstallPackages=gnome-do >> >> This is so trivial it presents almost no interest at all. If you >> want >> to go mono-app please consider eclipse, openoffice or firefox and >> their gazillon of plugins and extensions. > > get hacking on packagekit.catalog: > > [PackageKit Catalog] > # Common packages > InstallPackages=autoconf;automake;intltool;libtool;pkgconfig > # Fedora > InstallPackages(fedora)=glib2-devel;gvfs-devel;dbus-glib-devel;NetworkManager-glib-devel;PolicyKit-devel; > # Pardus > InstallPackages(pardus)=NetworkManager-devel;PolicyKit-devel;autoconf;automake;dbus-devel;dbus-glib-devel;docbook-to-man;gettext-devel;glib2-devel;gtk-doc;poldek-devel;python-devel;readline-devel;rpm-pythonprov;sqlite3-devel > # Forsight > InstallPackages(forsight)=gnome-development;dbus-development I'm quite surprised your new example is developper oriented after your claim of targetting non-technical users. But even with this use-case it's not been unknown of development projects to provide optionnal stuff (integration in X, Y or Z IDE) not every developper will want. >> Well that's not the syntax on your own web page (misses ;) so we've >> answered the question of your format being simple enough to be typed >> by memory without validation > > You can use either delimiter, no package names have spaces in them. I > guess it might even make sense to add ',' to the delimiter list too. I rest my case. This is quickly evolving in perl-land. >> What they do want is to click on a link, get the list of A, B and C, >> and uncheck the apps targetting stuff they're not interested in. > > They won't know what most of the applications are. > Also, applications > != > packages, so you have to be a bit more wise than just knowing the > application name. You didn't read my message. I did address this point. >> Wrong, anyone not sitting on a fiber to his home. > > I sit on a low speed broadband connection. I don't think I can even > get > fiber in my road, regardless, I don't spend much time installing new > applications. > >> Think your openoffice user is going to appreciate downloading megs >> of >> optionnal openoffice stuff just in case? > > I don't think it matters if people install 45Mb rather than 33Mb -- ???? You're off by quite a large level. > downloading 45Mb takes me about 10 minutes, so I just let it install > in the background or go and get a cup of tea. That works because you're technical enough not to make mistakes. A non-technical user will resent massively having to wait before knowing he made a mistake or not. > Bandwidth and disk space are cheap. They're not. >> Think your latex man is interested in installing megs of fonts for >> languages he does not type? (how do you decide beforehand which >> language a latex user will want to type) > > You don't, you patch the latex program to install it's own font when > it's first used in a document (trivial). Only works if either your user is working on someone else's document that specifies this font, or if he knows the font beforehand. Normal users need to have fonts installed before they think to use them. >> Will the music junkie be interested in dvd playback and authoring >> tools (just because the average teenager does both music and video)? > > I don't see the logic. Catalog files are fine grained -- it's okay to > download 5 catalog files and execute then all at once -- > gpk-install-catalog is smart enough to combine them into one set of > changes. So basically you want to replace howtos that say type a b c by howtos that say click a b c. That's not much of an improvement. At least you can paste cli lines in a term in one go. >> Presets are fine. Inflexible presets lead to resource waste and menu >> clutter users do complain of. > > More people complain that Linux is "hard to use" than complain they > have > useless packages on their disk. I can say that, as I've asked a number > real users (not developers). If you asked it this way I'm not surprised you go this answer. The user-visible effect is not "useless packages on their disk" but "updates taking twice the time". Cordialement, -- Nicolas Mailhot From laxathom at fedoraproject.org Thu Sep 11 16:06:41 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Thu, 11 Sep 2008 18:06:41 +0200 Subject: libbluetooth soname bump In-Reply-To: <1221147676.24928.196.camel@cookie.hadess.net> References: <1221147676.24928.196.camel@cookie.hadess.net> Message-ID: <62bc09df0809110906v1bdb33bdtf4ce89f8e8a633c3@mail.gmail.com> On Thu, Sep 11, 2008 at 5:41 PM, Bastien Nocera wrote: > Heya, > > It all went a bit quick, and the new bluez 4.x utilities and libraries > have landed in rawhide. This means that a number of applications needed > to be rebuilt. > > If your application was using the bluetooth library itself, there are > very few changes to the underlying API, only if you used to parse SDP > records by hand. See this example patch: > http://cvs.fedoraproject.org/viewvc/rpms/obex-data-server/devel/obex-data-server-0.3.4-bluez4.patch?view=markup > > For applications that used the D-Bus API, well, you'll need to update > them to use the new API. Only apps I know that do that are apps I > maintain, so I wouldn't worry about it :) > > Many thanks to the maintainers who already did their own rebuilds in > meantime. > > Here's the list of rebuilds I made. Let me know if I forgot anything. > > * Rebuilt apps: > pilot-link > obex-data-server > gnome-vfs2-obexftp > libbtctl > libwiimote > gnokii > gnome-phone-manager > gnome-bluetooth > obexftp > gypsy > libsyncml > amora > pybluez > callweaver-bluetooth > libopensync-plugin-irmc > pulseaudio-module-bluetooth > > * Apps that still need porting: > gnome-user-share > nautilus-sendto > obex-data-server > > * Apps that I couldn't rebuilt, didn't rebuild: > gammu (closed ACLs) Rebuilt -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB Fingerprint: 0F2A 7A17 0F1B 82EE FCBF 1F51 76B7 A28D F390 3DEB From s-t-rhbugzilla at wwwdotorg.org Thu Sep 11 16:18:54 2008 From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren) Date: Thu, 11 Sep 2008 10:18:54 -0600 (MDT) Subject: modesetting feature status In-Reply-To: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> Message-ID: <1221149934.7867.TMDA@tmda.severn.wwwdotorg.org> On Thu, September 11, 2008 1:18 am, Dave Airlie wrote: > Hi, > > So one of the features we've been trying to land for F10 that is a major > change in how we deal with graphics hardware in the Linux world. > > https://fedoraproject.org/wiki/Features/KernelModesetting What will happen on unsupported hardware (NVIDIA, unsupported ATI/Intel chipsets)? Will the system simply fall back to the existing F9-style startup sequence. I assume the X.org drivers won't be coded to assume that kernel modesetting has already run? How will X.org drivers detect this? How will this interact with proprietary binary drivers from NVIDIA and ATI, which don't know anything about this new feature? From jspaleta at gmail.com Thu Sep 11 16:20:46 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 11 Sep 2008 08:20:46 -0800 Subject: what is keeping per-user state outside of user's $HOME ? In-Reply-To: <48C939AD.4040808@comcast.net> References: <48C92DE3.8080406@comcast.net> <1221146228.3388.170.camel@luminos.localdomain> <48C939AD.4040808@comcast.net> Message-ID: <604aa7910809110920n45931e39sc9a2598090e85080@mail.gmail.com> On Thu, Sep 11, 2008 at 7:30 AM, John Ellson wrote: >> Are you sure it's not a ConsoleKit interaction making the session think >> your user isn't at the console? >> >> > > Only if ConsoleKit is keeping per user-state. If I login at the console as > any other user I get the Lock Screen menu item. Taking a quick look at the authorizations gui on my F9 system, you can in fact do grants and blocks for individual users, but I don't see anything in the list of possible authorization targets which is lock screen. Rawhide could have added that however. I still don't understand PolicyKit/ConsoleKit well enough to help you track it down in the filesystem with 100% confidence. But I would suspect that you should look in /var/lib/PolicyKit/ and /var/lib/PolicyKit-public/ for per-user authorization rules if they existed. Hope this helps. -jef From Jochen at herr-schmitt.de Thu Sep 11 16:21:43 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 11 Sep 2008 18:21:43 +0200 Subject: Possible gcc issue Message-ID: <48C94597.2000705@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hallo, during a koni scratch build I have got the following error messages: strings.c: In function 'cob_string_append': /usr/include/bits/string.h:190: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' /usr/include/bits/string.h:190: error: 'asm' operand has impossible constraints /usr/include/bits/string.h:190: error: 'asm' operand has impossible constraints I would ask, is this a gcc specific issue where I should file a bug report agains gcc, or is there any need to modified the source of the application to fixed this issue The whole build log may be find at: http://koji.fedoraproject.org/koji/getfile?taskID=820581&name=build.log Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjJRYYACgkQT2AHK6txfgzW2gCgg1QwR4YKXqDVRdfz0jFvgqHA 2JkAnA4PpIpp3+QYZzXVVbSPYXVQ+zfg =FN1Y -----END PGP SIGNATURE----- From dominik at greysector.net Thu Sep 11 16:37:30 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 11 Sep 2008 18:37:30 +0200 Subject: libbluetooth soname bump In-Reply-To: <1221147676.24928.196.camel@cookie.hadess.net> References: <1221147676.24928.196.camel@cookie.hadess.net> Message-ID: <20080911163729.GA20000@mokona.greysector.net> On Thursday, 11 September 2008 at 17:41, Bastien Nocera wrote: > Heya, > > It all went a bit quick, and the new bluez 4.x utilities and libraries > have landed in rawhide. This means that a number of applications needed > to be rebuilt. [...] > * Apps that I couldn't rebuilt, didn't rebuild: > obexfs (http://koji.fedoraproject.org/koji/taskinfo?taskID=820234, not > bluez related) Builds fine in mock locally (fedora-devel-i386). Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From billcrawford1970 at gmail.com Thu Sep 11 16:40:41 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 11 Sep 2008 17:40:41 +0100 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <16de708d0809110814l6eda770ey54db2073391e0511@mail.gmail.com> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <544eb990809110414x44c1c563l7d0da7859c166780@mail.gmail.com> <16de708d0809110814l6eda770ey54db2073391e0511@mail.gmail.com> Message-ID: <544eb990809110940j26d828ady63bc91e3c50cca3d@mail.gmail.com> On 11/09/2008, Arthur Pemberton wrote: > On Thu, Sep 11, 2008 at 6:14 AM, Bill Crawford > wrote: >> On 11/09/2008, Arthur Pemberton wrote: >> >>> * Sounblaster Live 5.1 PCI -- has full 6 channel audio before, I had >>> for a short while after enabling it as per the pulseaudio wiki, but no >>> more >> >> If it's one of the SBs with multiple hardware channels, unless you are >> likely to want >32 separate apps pumping out sound at once, disable PA >> and just access the card through ALSA directly. It's worked ok for me >> :o) > > > I'm pretty sure disabling PulseAudio will work since it worked before > PulseAudio. But disabling it defeats the purpose. If you have multi-channel hardware that mixes itself, then using PulseAudio sort of defeats the purpose of that hardware ;o) I'll accept the argument about allowing mixing with different volume levels from different sources, but in theory that can be done via ALSA if the hardware allows it. From bnocera at redhat.com Thu Sep 11 16:45:33 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Thu, 11 Sep 2008 17:45:33 +0100 Subject: libbluetooth soname bump In-Reply-To: <20080911163729.GA20000@mokona.greysector.net> References: <1221147676.24928.196.camel@cookie.hadess.net> <20080911163729.GA20000@mokona.greysector.net> Message-ID: <1221151533.24928.199.camel@cookie.hadess.net> On Thu, 2008-09-11 at 18:37 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 11 September 2008 at 17:41, Bastien Nocera wrote: > > Heya, > > > > It all went a bit quick, and the new bluez 4.x utilities and libraries > > have landed in rawhide. This means that a number of applications needed > > to be rebuilt. > [...] > > * Apps that I couldn't rebuilt, didn't rebuild: > > obexfs (http://koji.fedoraproject.org/koji/taskinfo?taskID=820234, not > > bluez related) > > Builds fine in mock locally (fedora-devel-i386). You'll want to check what's happening in koji then... From csnook at redhat.com Thu Sep 11 16:42:39 2008 From: csnook at redhat.com (Christopher Snook) Date: Thu, 11 Sep 2008 12:42:39 -0400 Subject: modesetting feature status In-Reply-To: <1221146122.3388.169.camel@luminos.localdomain> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221145599.11745.3.camel@aglarond.local> <1221146122.3388.169.camel@luminos.localdomain> Message-ID: <48C94A7F.5010507@redhat.com> Jesse Keating wrote: > On Thu, 2008-09-11 at 11:06 -0400, Jeremy Katz wrote: >> ... we really shouldn't shove in major changes like this for a >> significant chunk of hardware post-beta. Putting it in the beta means >> that we get a relatively large chunk of testing done due to the >> visibility surrounding the beta announce. As well as having time to fix >> large problems that are uncovered. Later milestones both a) lack the >> time for changes after them and b) the visibility. > > Yeah, I'm not so keen on doing all of this post-beta. We've got enough > stability problems with F10 as it is. This honestly feels like one of > those features that just isn't 'testable' by Beta, and thus needs to > enact the contingency plan. > > https://fedoraproject.org/wiki/Features/KernelModesetting#Contingency_Plan > > How do things look for that contingency plan. Is it even possible at > this point? If we're not going to enable it by default, I would rather the modesetting code be included, but disabled by default, and let users enable it on the kernel command line. -- Chris From ivazqueznet at gmail.com Thu Sep 11 16:48:57 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 11 Sep 2008 12:48:57 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <544eb990809110940j26d828ady63bc91e3c50cca3d@mail.gmail.com> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <544eb990809110414x44c1c563l7d0da7859c166780@mail.gmail.com> <16de708d0809110814l6eda770ey54db2073391e0511@mail.gmail.com> <544eb990809110940j26d828ady63bc91e3c50cca3d@mail.gmail.com> Message-ID: <1221151737.27183.74.camel@ignacio.lan> On Thu, 2008-09-11 at 17:40 +0100, Bill Crawford wrote: > If you have multi-channel hardware that mixes itself, then using > PulseAudio sort of defeats the purpose of that hardware ;o) You're absolutely right... if all you're using PulseAudio for is basic mixing. But as soon as you need/want something like per-app volume control, network transport, audio stream redirection, or audio device hotplugging then you want PulseAudio. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Wed Sep 10 23:32:59 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 11 Sep 2008 01:32:59 +0200 Subject: make force-tag gone In-Reply-To: <20080910220333.GJ31522@redhat.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> Message-ID: <1221089579.30799.1.camel@rousalka.okg> Le mercredi 10 septembre 2008 ? 18:03 -0400, Dave Jones a ?crit : > Now, I could bump the specfile and add "disable option foo on ppc" but if I did > this, our changelogs would be absolutely enormous, and for very little gain. No one is asking you to add a new changelog line every time you make a small change. You can bump the version in the changelog at the same time you bump it elsewhere -- 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 mtasaka at ioa.s.u-tokyo.ac.jp Thu Sep 11 16:54:07 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 12 Sep 2008 01:54:07 +0900 Subject: libbluetooth soname bump In-Reply-To: <20080911163729.GA20000@mokona.greysector.net> References: <1221147676.24928.196.camel@cookie.hadess.net> <20080911163729.GA20000@mokona.greysector.net> Message-ID: <48C94D2F.6090906@ioa.s.u-tokyo.ac.jp> Dominik 'Rathann' Mierzejewski wrote, at 09/12/2008 01:37 AM +9:00: > On Thursday, 11 September 2008 at 17:41, Bastien Nocera wrote: >> Heya, >> >> It all went a bit quick, and the new bluez 4.x utilities and libraries >> have landed in rawhide. This means that a number of applications needed >> to be rebuilt. > [...] >> * Apps that I couldn't rebuilt, didn't rebuild: >> obexfs (http://koji.fedoraproject.org/koji/taskinfo?taskID=820234, not >> bluez related) > > Builds fine in mock locally (fedora-devel-i386). > > Regards, > R. > Umm... what is strange is that root.log shows dependency resolution problem, however mock kept rebuilding anyway: root.log: DEBUG util.py:250: Total download size: 392 k DEBUG util.py:250: ERROR with rpm_check_debug vs depsolve: DEBUG util.py:250: Package obexftp-libs needs libbluetooth.so.2, this is not available. build.log: Building target platforms: i386 Building for target i386 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.WApyoR + umask 022 ......... Perhaps a bug in yum or mock ? By the way now the dependency on obexftp is resolved and the build seems to be going well (scratch build) http://koji.fedoraproject.org/koji/taskinfo?taskID=820680 Mamoru From aph at redhat.com Thu Sep 11 16:56:31 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 11 Sep 2008 17:56:31 +0100 Subject: Possible gcc issue In-Reply-To: <48C94597.2000705@herr-schmitt.de> References: <48C94597.2000705@herr-schmitt.de> Message-ID: <48C94DBF.5030404@redhat.com> Jochen Schmitt wrote: > Hallo, > > during a koni scratch build I have got the following error messages: > > strings.c: In function 'cob_string_append': > /usr/include/bits/string.h:190: error: can't find a register in class > 'GENERAL_REGS' while reloading 'asm' > /usr/include/bits/string.h:190: error: 'asm' operand has impossible > constraints > /usr/include/bits/string.h:190: error: 'asm' operand has impossible > constraints > > I would ask, is this a gcc specific issue where I should file a bug > report agains gcc, Probably not. Do that compilation with -save-temps and let's see the preprocessed .i file. Then we'll see if it's a gcc bug. Andrew. From john.ellson at comcast.net Thu Sep 11 17:03:33 2008 From: john.ellson at comcast.net (John Ellson) Date: Thu, 11 Sep 2008 13:03:33 -0400 Subject: what is keeping per-user state outside of user's $HOME ? In-Reply-To: <604aa7910809110920n45931e39sc9a2598090e85080@mail.gmail.com> References: <48C92DE3.8080406@comcast.net> <1221146228.3388.170.camel@luminos.localdomain> <48C939AD.4040808@comcast.net> <604aa7910809110920n45931e39sc9a2598090e85080@mail.gmail.com> Message-ID: <48C94F65.10707@comcast.net> Jeff Spaleta wrote: > On Thu, Sep 11, 2008 at 7:30 AM, John Ellson wrote: > >>> Are you sure it's not a ConsoleKit interaction making the session think >>> your user isn't at the console? >>> >>> >>> >> Only if ConsoleKit is keeping per user-state. If I login at the console as >> any other user I get the Lock Screen menu item. >> > > Taking a quick look at the authorizations gui on my F9 system, you can > in fact do grants and blocks for individual users, but I don't see > anything in the list of possible authorization targets which is lock > screen. Rawhide could have added that however. > > I still don't understand PolicyKit/ConsoleKit well enough to help you > track it down in the filesystem with 100% confidence. But I would > suspect that you should look in /var/lib/PolicyKit/ and > /var/lib/PolicyKit-public/ for per-user authorization rules if they > existed. > > Hope this helps. > > -jef > > There is a /var/lib/PolicyKit/user-ellson.auths but removing it makes no difference. That file talks about using polkit-auth Running polkit-auth as user ellson generates a long list of stuff: org.freedesktop.hal.dockstation.undock org.freedesktop.hal.device-access.sound org.freedesktop.hal.device-access.video4linux org.freedesktop.hal.device-access.cdrom ... Where does it get this from? Removing /var/lib/PolicyKit/user-ellson.auths doesn't change the output. Running it in another user's account generates different, empty, output. "polkit-auth --show-obtainable" doesn't offer any obvious token for enabling LockScreen. -- John Ellson From ajax at redhat.com Thu Sep 11 17:08:22 2008 From: ajax at redhat.com (Adam Jackson) Date: Thu, 11 Sep 2008 13:08:22 -0400 Subject: modesetting feature status In-Reply-To: <1221149934.7867.TMDA@tmda.severn.wwwdotorg.org> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221149934.7867.TMDA@tmda.severn.wwwdotorg.org> Message-ID: <1221152902.4345.16.camel@atropine.boston.devel.redhat.com> On Thu, 2008-09-11 at 10:18 -0600, Stephen Warren wrote: > On Thu, September 11, 2008 1:18 am, Dave Airlie wrote: > > Hi, > > > > So one of the features we've been trying to land for F10 that is a major > > change in how we deal with graphics hardware in the Linux world. > > > > https://fedoraproject.org/wiki/Features/KernelModesetting > > What will happen on unsupported hardware (NVIDIA, unsupported ATI/Intel > chipsets)? Will the system simply fall back to the existing F9-style > startup sequence. They'll get text boot, yes. > I assume the X.org drivers won't be coded to assume that > kernel modesetting has already run? How will X.org drivers detect this? They have been changed to notice if kms has already happened. > How will this interact with proprietary binary drivers from NVIDIA and > ATI, which don't know anything about this new feature? Well, it's irrelevant for nvidia since we don't even pretend to do kms there. For fglrx, you'll probably have to force it to text boot, since otherwise the radeon driver will load, locking out fglrx. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ajax at redhat.com Thu Sep 11 17:09:16 2008 From: ajax at redhat.com (Adam Jackson) Date: Thu, 11 Sep 2008 13:09:16 -0400 Subject: modesetting feature status In-Reply-To: <1221145599.11745.3.camel@aglarond.local> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221145599.11745.3.camel@aglarond.local> Message-ID: <1221152956.4345.17.camel@atropine.boston.devel.redhat.com> On Thu, 2008-09-11 at 11:06 -0400, Jeremy Katz wrote: > On Thu, 2008-09-11 at 17:18 +1000, Dave Airlie wrote: > > For the beta we are only going to enable Radeon support for the r300 to > > r500 class of hardware, while we await upstream changes to the Intel > > driver. > > ... we really shouldn't shove in major changes like this for a > significant chunk of hardware post-beta. Putting it in the beta means > that we get a relatively large chunk of testing done due to the > visibility surrounding the beta announce. As well as having time to fix > large problems that are uncovered. Later milestones both a) lack the > time for changes after them and b) the visibility. So are you saying: a) enable it for both, see what breaks b) remove both, because, screw it ? - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Thu Sep 11 17:20:09 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 11 Sep 2008 13:20:09 -0400 Subject: Boot speedup with readahead In-Reply-To: <20080911004729.GU18073@didacte.laptop.org> References: <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <1221071066.1927.216.camel@firewall.xsintricity.com> <1221072143.987.125.camel@rosebud> <20080910201637.GR18073@didacte.laptop.org> <1221079587.987.137.camel@rosebud> <20080911004729.GU18073@didacte.laptop.org> Message-ID: <1221153609.987.201.camel@rosebud> On Wed, 2008-09-10 at 20:48 -0400, Michael Stone wrote: > I'm happy to explain in more detail, though I'll do so in my own order. > > First, some introduction: my software [1] consists of a family of python > programs (called "compilations", since each is a primitive compiler), designed > to be run in a mock chroot, which convert collections of packages and hacks > into publishables (for example a list of installed packages, a XO JFFS2 disk > image, and a tarball of the filesystem contents). > > [1]: http://wiki.laptop.org/go/Puritan > > Its primary goal is to ease the task of creating releaseable disk images for > OLPC XOs in a reproducible and verifiable fashion by storing all effective > inputs to the build process in git commits. Its secondary goal is to overcome > some of the infelicities of pilgrim with respect to error detection, cleanup, > and debuggability. It's third goal is to be useful to expert Python programmers > who maintain Linux builds for fixed hardware regardless of their preferred > distro and package-format. It therefore exists in contrast to general-purpose > tools like debian-installer, anaconda, revisor, and livecd-tools, which are > distro-specific build tools with an interest in shielding their users from the > tool's implementation's underlying error-detection, analysis, and correction > mechanisms and workflows, often by means of a domain-specific language. > > Smart is convenient to these goals in that it has a thoroughly documented shell > interface which permits the following useful operations: > > Smart permits me to control my selection of package repositories package more > succinctly and less distro-specifically than yum; e.g. > > smart channel -y --remove-all > smart channel -y --add bootstrap type='rpm-md' baseurl='http://dev.laptop.org/~mstone/puritan-repo/' > smart channel -y --add bootstrap-f9 type='rpm-md' baseurl='http://dev.laptop.org/~mstone/puritan-f9-repo/' > smart channel -y --enable bootstrap > smart channel -y --enable bootstrap-f9 > smart update > smart install -y olpc-crcimg python-msutils > > I was able to write these basic commands without reference to the smart source > code using only its man page; could I have done the same with yum? > > (In release compilations, the rpm repos being sourced would be included as > git submodules of the compilation commit thereby achieving full history good > reproducibility.) > > Next, after adding two new repos (for olpc-specific packages and for general > F-9 packages), I run > > for pkg in firefox seamonkey mozplugger kdebase kernel; do > smart priority --set $pkg olpc-joyride 100 > done > I think you can do all of the above in the yum shell yum shell >repo enable foo >repo disable bar >config assumeyes 1 >update >install pkg1 pkg2 pkg3 >run > in order to bias several packages toward the OLPC repo. I could do something > similar in yum with the '--exclude' option or by modifying the yum repo > configuration, but it would be much more annoying either way in that I'd need > more complicated code to pipe the results of my configuration phase into the > installation phase. You can set the repo cost, too. > > Next, mirror configuration: > > smart mirror --add http://koji.fedoraproject.org/static-repos/dist-olpc3-build-current/i386/ http://koji.fedoraproject.org/packages/ > > This command essentially lets me perform url-rewriting as needed. This ability > is not _necessary_ for my purpose, but it sure is convenient from time to time. > >> priority system, > >available in a yum plugin - though questionably useful to begin with. > > Yum plugins seem, at first blush and in general rather than in specific, highly > inconvenient for my purpose because of issues like the: > > * lack of uniform quality control - So all features in smart have complete uniform quality control? I've read smart's bug reports. I don't think all features are tested identically. > * absence of centralized documentation > * potential lack of unified error handling conventions, > * perceived difficulty of installation and potential for version mismatch > between plugin and host, > * lack of a API stability guarantees What on earth? We've had a few bugs but the yum api and the plugin api has been stable for quite a while, now. > Second, please acknowledge that I am, for the time being dedicated first to the > XO hardware and second to Fedora. This being what it is, and there lots of > other people out there who would like to get their pet distribution running on > the XO hardware, it's important to me to be able to collaborate with others > using the same tools that I (hope to soon) use during the rest of my day. Isn't > that going to benefit Fedora insofar as it helps make Fedora packages work > better on all 400k XOs we've shipped it on and insofar as it stimulates more > people to make useful contributions to upstream projects? > > Error-checking. Pilgrim was notorious for producing broken builds because > pilgrim failed or was unable to detect situations in which yum was unable to > install all the requested packages. Perhaps this is a documentation problem -- > I note that the yum man page contains no information about what error codes yum > will or can be made to return (if any?). > > In particular, > > yum -d 10 -e 10 install grhlkjoei > > returns 0. This needlessly complicates my life: I _DO NOT_ want to have to > parse the yum output in order to learn that a problem occurred. Then don't use shell! Use python. > Regarding the possibility of using the yum python modules directly: > > * what documentation exists? pydoc has a fair bit in docstrings for yum. We have lots of good example code to work from, too. Both James and I have been posting common examples to get people started writing their own utilities using the yum modules. > * what guarantees of API stability exist? 3.2.X is guaranteed api stable. If we've broken compat it is not intentional. > * what sample code exists and is it sane or contorted? http://illiterat.livejournal.com/6254.html http://fedoraproject.org/wiki/SethVidal/YumCodeSnippets all of the yum-utils are pretty good code examples, too. Finally, I'd like to mention that excluding the 'make it work with random package formats' everything you've described above is wheel reinvention. You've respun what we've already done and had available in fedora, rhel, rhl for years. It sure feels like there's a lot of NIH at work in OLPC development and that's not productive for anyone and certainly not very collaborative. -sv From hughsient at gmail.com Thu Sep 11 17:22:04 2008 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 11 Sep 2008 18:22:04 +0100 Subject: Feature Proposal: Use cases database In-Reply-To: References: <1220991029.3782.47.camel@choeger6> <1221026638.2783.6.camel@hp6710.axianet.ch> <48C767E7.9040801@gmail.com> <1221059648.17299.103.camel@hughsie-work> <1221062578.21306.13.camel@rousalka.okg> <1221064863.17299.134.camel@hughsie-work> <5cb581610364a94649b91d5bc6e50928.squirrel@rousalka.dyndns.org> <1221129641.22654.24.camel@hughsie-work> <1221141890.22654.75.camel@hughsie-work> Message-ID: <1221153724.22654.86.camel@hughsie-work> On Thu, 2008-09-11 at 16:41 +0200, Nicolas Mailhot wrote: > > Bandwidth and disk space are cheap. > > They're not. Cost of me downloading a 24Mb open office clipart package = = ?20/month (takes 7 minutes to download) = 0.3 pence Cost of diskspace = ?120 / 80Gb = 3.5 pence Cost of me spending 5 minutes setting up clipart for my mum: = ?20 / hour = ?1.67 > >> Think your latex man is interested in installing megs of fonts for > >> languages he does not type? (how do you decide beforehand which > >> language a latex user will want to type) > > > > You don't, you patch the latex program to install it's own font when > > it's first used in a document (trivial). > > Only works if either your user is working on someone else's document > that specifies this font, or if he knows the font beforehand. Normal > users need to have fonts installed before they think to use them. latex files are compiled from .tex to .pdf, and the compiler knows exactly what filename it needs. Richard. From mclasen at redhat.com Thu Sep 11 17:30:02 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 11 Sep 2008 13:30:02 -0400 Subject: what is keeping per-user state outside of user's $HOME ? In-Reply-To: <48C94F65.10707@comcast.net> References: <48C92DE3.8080406@comcast.net> <1221146228.3388.170.camel@luminos.localdomain> <48C939AD.4040808@comcast.net> <604aa7910809110920n45931e39sc9a2598090e85080@mail.gmail.com> <48C94F65.10707@comcast.net> Message-ID: <1221154202.3956.0.camel@localhost.localdomain> On Thu, 2008-09-11 at 13:03 -0400, John Ellson wrote: > Jeff Spaleta wrote: > > On Thu, Sep 11, 2008 at 7:30 AM, John Ellson wrote: > > > >>> Are you sure it's not a ConsoleKit interaction making the session think > >>> your user isn't at the console? > >>> > >>> > >>> > >> Only if ConsoleKit is keeping per user-state. If I login at the console as > >> any other user I get the Lock Screen menu item. > >> > > > > Taking a quick look at the authorizations gui on my F9 system, you can > > in fact do grants and blocks for individual users, but I don't see > > anything in the list of possible authorization targets which is lock > > screen. Rawhide could have added that however. > > > > I still don't understand PolicyKit/ConsoleKit well enough to help you > > track it down in the filesystem with 100% confidence. But I would > > suspect that you should look in /var/lib/PolicyKit/ and > > /var/lib/PolicyKit-public/ for per-user authorization rules if they > > existed. > > > > Hope this helps. Why don't we stop all this blind guessing, and attach a debugger to the panel instead ? It would be so much easier... From Jochen at herr-schmitt.de Thu Sep 11 17:32:11 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 11 Sep 2008 19:32:11 +0200 Subject: Possible gcc issue In-Reply-To: <48C94DBF.5030404@redhat.com> References: <48C94597.2000705@herr-schmitt.de> <48C94DBF.5030404@redhat.com> Message-ID: <48C9561B.6010901@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Haley schrieb: > Jochen Schmitt wrote: >> Hallo, >> >> during a koni scratch build I have got the following error messages: >> >> strings.c: In function 'cob_string_append': >> /usr/include/bits/string.h:190: error: can't find a register in class >> 'GENERAL_REGS' while reloading 'asm' >> /usr/include/bits/string.h:190: error: 'asm' operand has impossible >> constraints >> /usr/include/bits/string.h:190: error: 'asm' operand has impossible >> constraints >> >> I would ask, is this a gcc specific issue where I should file a bug >> report agains gcc, > > Probably not. Do that compilation with -save-temps and let's see the > preprocessed .i file. Then we'll see if it's a gcc bug. I have try out the -save-temp flags and have got .s and .lo files, but not the .i file. In which directory should I saarch for this files. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjJVg0ACgkQT2AHK6txfgxNAQCfU2Lpd5kRJ93LUc8Jr4kmbdKM RPMAn2lNdUgHvcCIvck6WxmnbKjkm7V9 =xtki -----END PGP SIGNATURE----- From aph at redhat.com Thu Sep 11 17:36:39 2008 From: aph at redhat.com (Andrew Haley) Date: Thu, 11 Sep 2008 18:36:39 +0100 Subject: Possible gcc issue In-Reply-To: <48C9561B.6010901@herr-schmitt.de> References: <48C94597.2000705@herr-schmitt.de> <48C94DBF.5030404@redhat.com> <48C9561B.6010901@herr-schmitt.de> Message-ID: <48C95727.9070602@redhat.com> Jochen Schmitt wrote: > Andrew Haley schrieb: >> Jochen Schmitt wrote: >>> Hallo, >>> >>> during a koni scratch build I have got the following error messages: >>> >>> strings.c: In function 'cob_string_append': >>> /usr/include/bits/string.h:190: error: can't find a register in class >>> 'GENERAL_REGS' while reloading 'asm' >>> /usr/include/bits/string.h:190: error: 'asm' operand has impossible >>> constraints >>> /usr/include/bits/string.h:190: error: 'asm' operand has impossible >>> constraints >>> >>> I would ask, is this a gcc specific issue where I should file a bug >>> report agains gcc, >> Probably not. Do that compilation with -save-temps and let's see the >> preprocessed .i file. Then we'll see if it's a gcc bug. > I have try out the -save-temp flags and have got .s and .lo files, but > not the > .i file. > > In which directory should I saarch for this files. In the directory where the compilation is run. It will be there, you just have to search for it. If you still can't find it, use gcc -E. Andrew. From pemboa at gmail.com Thu Sep 11 17:43:14 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 11 Sep 2008 12:43:14 -0500 Subject: Feature Proposal: Use cases database In-Reply-To: <1221153724.22654.86.camel@hughsie-work> References: <1220991029.3782.47.camel@choeger6> <1221059648.17299.103.camel@hughsie-work> <1221062578.21306.13.camel@rousalka.okg> <1221064863.17299.134.camel@hughsie-work> <5cb581610364a94649b91d5bc6e50928.squirrel@rousalka.dyndns.org> <1221129641.22654.24.camel@hughsie-work> <1221141890.22654.75.camel@hughsie-work> <1221153724.22654.86.camel@hughsie-work> Message-ID: <16de708d0809111043y6ab64021p9ed49ceba2422fe4@mail.gmail.com> On Thu, Sep 11, 2008 at 12:22 PM, Richard Hughes wrote: > Cost of me spending 5 minutes setting up clipart for my mum: > = ?20 / hour > = ?1.67 I have to say this took me by suprise -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From katzj at redhat.com Thu Sep 11 17:46:04 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 11 Sep 2008 13:46:04 -0400 Subject: modesetting feature status In-Reply-To: <1221152956.4345.17.camel@atropine.boston.devel.redhat.com> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221145599.11745.3.camel@aglarond.local> <1221152956.4345.17.camel@atropine.boston.devel.redhat.com> Message-ID: <1221155164.11745.13.camel@aglarond.local> On Thu, 2008-09-11 at 13:09 -0400, Adam Jackson wrote: > On Thu, 2008-09-11 at 11:06 -0400, Jeremy Katz wrote: > > On Thu, 2008-09-11 at 17:18 +1000, Dave Airlie wrote: > > > For the beta we are only going to enable Radeon support for the r300 to > > > r500 class of hardware, while we await upstream changes to the Intel > > > driver. > > > > ... we really shouldn't shove in major changes like this for a > > significant chunk of hardware post-beta. Putting it in the beta means > > that we get a relatively large chunk of testing done due to the > > visibility surrounding the beta announce. As well as having time to fix > > large problems that are uncovered. Later milestones both a) lack the > > time for changes after them and b) the visibility. > > So are you saying: > > a) enable it for both, see what breaks I've been advocating us getting the pieces merged for a long time so that we could see what was broken rather than trying to wait for a mythical "perfection" that's been just another week or two out for on the order of months now. > b) remove both, because, screw it This is a part of the contingency plan. But removing for both seems a little extreme. There's also c) Just enable it for radeon. Intel users get pretty modesetting for F11. It's only six months away. Adding the Intel support post-beta just leaves us with way too little runway of testing on what's a significant amount of the hardware running Fedora. And one of the big reasons behind the six month release cycle is that if something is late to the party for release n, n+1 is not that far away. Jeremy From lesmikesell at gmail.com Thu Sep 11 17:58:30 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 11 Sep 2008 12:58:30 -0500 Subject: Feature Proposal: Use cases database In-Reply-To: <1221141890.22654.75.camel@hughsie-work> References: <1220991029.3782.47.camel@choeger6> <1221026638.2783.6.camel@hp6710.axianet.ch> <48C767E7.9040801@gmail.com> <1221059648.17299.103.camel@hughsie-work> <1221062578.21306.13.camel@rousalka.okg> <1221064863.17299.134.camel@hughsie-work> <5cb581610364a94649b91d5bc6e50928.squirrel@rousalka.dyndns.org> <1221129641.22654.24.camel@hughsie-work> <1221141890.22654.75.camel@hughsie-work> Message-ID: <48C95C46.1060904@gmail.com> Richard Hughes wrote: > On Thu, 2008-09-11 at 15:38 +0200, Nicolas Mailhot wrote: >> Replace digital-photo forum with foo community and you'll get pretty >> much the same results > > You're not meant to have one catalog file for all of that. You could > just have a file called "Gallery integration.catalog" -- it's not comps > where one file has to describe subsets. Can you describe a whole machine with a catalog file? -- Les Mikesell lesmikesell at gmail.com From seg at haxxed.com Thu Sep 11 18:36:37 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 11 Sep 2008 13:36:37 -0500 Subject: Beware: External repos can break key transition Message-ID: <1221158197.6431.24.camel@localhost.localdomain> $ sudo yum update Loaded plugins: fedorakmod, refresh-packagekit livna | 2.1 kB 00:00 primary.sqlite.bz2 | 192 kB 00:01 adobe-linux-i386 | 951 B 00:00 updates | 2.6 kB 00:00 primary.sqlite.bz2 | 11 kB 00:00 fedora | 2.4 kB 00:00 Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package gnome-packagekit.x86_64 0:0.2.5-2.fc9 set to be updated ---> Package xine-lib-extras-nonfree.x86_64 0:1.1.15-1.lvn9 set to be updated --> Processing Dependency: xine-lib(plugin-abi) = 1.24 for package: xine-lib-extras-nonfree ---> Package PackageKit.x86_64 0:0.2.5-1.fc9 set to be updated ---> Package fedora-release.noarch 0:9-5.transition set to be updated ---> Package yum-packagekit.x86_64 0:0.2.5-1.fc9 set to be updated ---> Package PackageKit-libs.x86_64 0:0.2.5-1.fc9 set to be updated --> Finished Dependency Resolution xine-lib-extras-nonfree-1.1.15-1.lvn9.x86_64 from livna has depsolving problems --> Missing Dependency: xine-lib(plugin-abi) = 1.24 is needed by package xine-lib-extras-nonfree-1.1.15-1.lvn9.x86_64 (livna) Error: Missing Dependency: xine-lib(plugin-abi) = 1.24 is needed by package xine-lib-extras-nonfree-1.1.15-1.lvn9.x86_64 (livna) So, an update in the Repo That Can Not Be Named, depends on an update in the updates-newkey repo, not yet available, thus breaking the transaction due to yum's pedantry. Something to be aware of if you have non-technical users using Livna, and you didn't think you needed the skip-broken plugin... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From davej at redhat.com Thu Sep 11 18:45:06 2008 From: davej at redhat.com (Dave Jones) Date: Thu, 11 Sep 2008 14:45:06 -0400 Subject: make force-tag gone In-Reply-To: <1221089579.30799.1.camel@rousalka.okg> References: <1220955240.24928.69.camel@cookie.hadess.net> <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> Message-ID: <20080911184506.GA1486@redhat.com> On Thu, Sep 11, 2008 at 01:32:59AM +0200, Nicolas Mailhot wrote: > Le mercredi 10 septembre 2008 ? 18:03 -0400, Dave Jones a ?crit : > > > Now, I could bump the specfile and add "disable option foo on ppc" but if I did > > this, our changelogs would be absolutely enormous, and for very little gain. > > No one is asking you to add a new changelog line every time you make a > small change. You can bump the version in the changelog at the same time > you bump it elsewhere Regardless, it's still an extra file I have to edit for no apparent reason. Dave -- http://www.codemonkey.org.uk From skvidal at fedoraproject.org Thu Sep 11 18:44:49 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 11 Sep 2008 14:44:49 -0400 Subject: Beware: External repos can break key transition In-Reply-To: <1221158197.6431.24.camel@localhost.localdomain> References: <1221158197.6431.24.camel@localhost.localdomain> Message-ID: <1221158689.987.213.camel@rosebud> On Thu, 2008-09-11 at 13:36 -0500, Callum Lerwick wrote: > $ sudo yum update > Loaded plugins: fedorakmod, refresh-packagekit > livna | 2.1 kB 00:00 > primary.sqlite.bz2 | 192 kB 00:01 > adobe-linux-i386 | 951 B 00:00 > updates | 2.6 kB 00:00 > primary.sqlite.bz2 | 11 kB 00:00 > fedora | 2.4 kB 00:00 > Setting up Update Process > Resolving Dependencies > --> Running transaction check > ---> Package gnome-packagekit.x86_64 0:0.2.5-2.fc9 set to be updated > ---> Package xine-lib-extras-nonfree.x86_64 0:1.1.15-1.lvn9 set to be updated > --> Processing Dependency: xine-lib(plugin-abi) = 1.24 for package: xine-lib-extras-nonfree > ---> Package PackageKit.x86_64 0:0.2.5-1.fc9 set to be updated > ---> Package fedora-release.noarch 0:9-5.transition set to be updated > ---> Package yum-packagekit.x86_64 0:0.2.5-1.fc9 set to be updated > ---> Package PackageKit-libs.x86_64 0:0.2.5-1.fc9 set to be updated > --> Finished Dependency Resolution > xine-lib-extras-nonfree-1.1.15-1.lvn9.x86_64 from livna has depsolving problems > --> Missing Dependency: xine-lib(plugin-abi) = 1.24 is needed by package xine-lib-extras-nonfree-1.1.15-1.lvn9.x86_64 (livna) > Error: Missing Dependency: xine-lib(plugin-abi) = 1.24 is needed by package xine-lib-extras-nonfree-1.1.15-1.lvn9.x86_64 (livna) > > So, an update in the Repo That Can Not Be Named, depends on an update in > the updates-newkey repo, not yet available, thus breaking the > transaction due to yum's pedantry. > please test the above with: yum --skip-broken update -sv From jspaleta at gmail.com Thu Sep 11 18:51:09 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 11 Sep 2008 10:51:09 -0800 Subject: Beware: External repos can break key transition In-Reply-To: <1221158197.6431.24.camel@localhost.localdomain> References: <1221158197.6431.24.camel@localhost.localdomain> Message-ID: <604aa7910809111151s330ea17cr5c5d08d6aefa5862@mail.gmail.com> 2008/9/11 Callum Lerwick : > Something to be aware of if you have non-technical users using Livna, > and you didn't think you needed the skip-broken plugin... Seems okay for me. I just installed xine-lib-extras-nonfree on my 32bit system. Perhaps this a transitory issue due to one of the mirrors not being fully synced? -jef From john.ellson at comcast.net Thu Sep 11 18:59:07 2008 From: john.ellson at comcast.net (John Ellson) Date: Thu, 11 Sep 2008 14:59:07 -0400 Subject: what is keeping per-user state outside of user's $HOME ? In-Reply-To: <1221154202.3956.0.camel@localhost.localdomain> References: <48C92DE3.8080406@comcast.net> <1221146228.3388.170.camel@luminos.localdomain> <48C939AD.4040808@comcast.net> <604aa7910809110920n45931e39sc9a2598090e85080@mail.gmail.com> <48C94F65.10707@comcast.net> <1221154202.3956.0.camel@localhost.localdomain> Message-ID: <48C96A7B.40005@comcast.net> Matthias Clasen wrote: > > Why don't we stop all this blind guessing, and attach a debugger to the > panel instead ? It would be so much easier... > > Because I'm not a gdb expert, and I don't know what to look for in gnome-panel, or even why you think gnome-panel is the place to look? If you wouldn't mind helping out with some more detailed suggestions, perhaps offline from this list, then I'm willing to try. -- John Ellson From drepper at redhat.com Thu Sep 11 19:01:59 2008 From: drepper at redhat.com (Ulrich Drepper) Date: Thu, 11 Sep 2008 12:01:59 -0700 Subject: Possible gcc issue In-Reply-To: <48C94597.2000705@herr-schmitt.de> References: <48C94597.2000705@herr-schmitt.de> Message-ID: <48C96B27.9020700@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jochen Schmitt wrote: > I would ask, is this a gcc specific issue where I should file a bug > report agains gcc, Not a gcc bug and no bug in glibc. This is inline asm which requires registers which for some reason are not available. Compile this file with __NO_STRING_INLINES defined. - -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkjJaycACgkQ2ijCOnn/RHSoxgCfekOB7J4Ilb1Hku4SML0vQCRt 6hMAn3Tbk4uPhhFajvEq1Lbko8i1ZgcX =YCXv -----END PGP SIGNATURE----- From mclasen at redhat.com Thu Sep 11 19:10:51 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Thu, 11 Sep 2008 15:10:51 -0400 Subject: what is keeping per-user state outside of user's $HOME ? In-Reply-To: <48C96A7B.40005@comcast.net> References: <48C92DE3.8080406@comcast.net> <1221146228.3388.170.camel@luminos.localdomain> <48C939AD.4040808@comcast.net> <604aa7910809110920n45931e39sc9a2598090e85080@mail.gmail.com> <48C94F65.10707@comcast.net> <1221154202.3956.0.camel@localhost.localdomain> <48C96A7B.40005@comcast.net> Message-ID: <1221160251.3956.12.camel@localhost.localdomain> On Thu, 2008-09-11 at 14:59 -0400, John Ellson wrote: > Matthias Clasen wrote: > > > > Why don't we stop all this blind guessing, and attach a debugger to the > > panel instead ? It would be so much easier... > > > > > Because I'm not a gdb expert, and I don't know what to look for in > gnome-panel, or even why you think gnome-panel is the place to look? > > If you wouldn't mind helping out with some more detailed suggestions, > perhaps offline from this list, then I'm willing to try. > You probably want to break in panel_lock_screen_action_available and see what is going on there. From joshuacov at googlemail.com Thu Sep 11 19:09:12 2008 From: joshuacov at googlemail.com (Joshua C.) Date: Thu, 11 Sep 2008 21:09:12 +0200 Subject: modesetting feature status In-Reply-To: <1221155164.11745.13.camel@aglarond.local> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221145599.11745.3.camel@aglarond.local> <1221152956.4345.17.camel@atropine.boston.devel.redhat.com> <1221155164.11745.13.camel@aglarond.local> Message-ID: <5f6f8c5f0809111209o1d28bae4p246d699f3520c40@mail.gmail.com> 2008/9/11 Jeremy Katz : > On Thu, 2008-09-11 at 13:09 -0400, Adam Jackson wrote: >> On Thu, 2008-09-11 at 11:06 -0400, Jeremy Katz wrote: >> > On Thu, 2008-09-11 at 17:18 +1000, Dave Airlie wrote: >> > > For the beta we are only going to enable Radeon support for the r300 to >> > > r500 class of hardware, while we await upstream changes to the Intel >> > > driver. >> > >> > ... we really shouldn't shove in major changes like this for a >> > significant chunk of hardware post-beta. Putting it in the beta means >> > that we get a relatively large chunk of testing done due to the >> > visibility surrounding the beta announce. As well as having time to fix >> > large problems that are uncovered. Later milestones both a) lack the >> > time for changes after them and b) the visibility. >> >> So are you saying: >> >> a) enable it for both, see what breaks > > I've been advocating us getting the pieces merged for a long time so > that we could see what was broken rather than trying to wait for a > mythical "perfection" that's been just another week or two out for on > the order of months now. > >> b) remove both, because, screw it > > This is a part of the contingency plan. But removing for both seems a > little extreme. > > There's also c) Just enable it for radeon. Intel users get pretty > modesetting for F11. It's only six months away. Adding the Intel > support post-beta just leaves us with way too little runway of testing > on what's a significant amount of the hardware running Fedora. And one > of the big reasons behind the six month release cycle is that if > something is late to the party for release n, n+1 is not that far away. > > Jeremy > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Is there a list of cards that work with this (already tested)? f10 is just a month away and my rs485 still cannot function with this code. It's an important feature and if it cannot work, then maybe the contingency plan should be applied. From joshuacov at googlemail.com Thu Sep 11 19:11:13 2008 From: joshuacov at googlemail.com (Joshua C.) Date: Thu, 11 Sep 2008 21:11:13 +0200 Subject: Beware: External repos can break key transition In-Reply-To: <604aa7910809111151s330ea17cr5c5d08d6aefa5862@mail.gmail.com> References: <1221158197.6431.24.camel@localhost.localdomain> <604aa7910809111151s330ea17cr5c5d08d6aefa5862@mail.gmail.com> Message-ID: <5f6f8c5f0809111211x2f480402yed41374e9d773379@mail.gmail.com> 2008/9/11 Jeff Spaleta : > 2008/9/11 Callum Lerwick : >> Something to be aware of if you have non-technical users using Livna, >> and you didn't think you needed the skip-broken plugin... > > Seems okay for me. I just installed xine-lib-extras-nonfree on my > 32bit system. Perhaps this a transitory issue due to one of the > mirrors not being fully synced? > > -jef > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Got the same here. download the packages from koji and install it. Still isn't pushed to testing. From jspaleta at gmail.com Thu Sep 11 19:18:14 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 11 Sep 2008 11:18:14 -0800 Subject: Beware: External repos can break key transition In-Reply-To: <5f6f8c5f0809111211x2f480402yed41374e9d773379@mail.gmail.com> References: <1221158197.6431.24.camel@localhost.localdomain> <604aa7910809111151s330ea17cr5c5d08d6aefa5862@mail.gmail.com> <5f6f8c5f0809111211x2f480402yed41374e9d773379@mail.gmail.com> Message-ID: <604aa7910809111218i7a3769fft2ada9fe607c991a9@mail.gmail.com> On Thu, Sep 11, 2008 at 11:11 AM, Joshua C. wrote: > Got the same here. download the packages from koji and install it. > Still isn't pushed to testing. ? On my F9 system less than a minute ago: yum install xine-lib-extras-nonfree ... Installing: xine-lib-extras-nonfree i386 1.1.15-1.lvn9 livna 581 k Installing for dependencies: xine-lib i386 1.1.15-1.fc9 updates-newkey 2.7 M ... transaction succeeds -jef From fedora at leemhuis.info Thu Sep 11 19:31:38 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 11 Sep 2008 21:31:38 +0200 Subject: Beware: External repos can break key transition In-Reply-To: <1221158197.6431.24.camel@localhost.localdomain> References: <1221158197.6431.24.camel@localhost.localdomain> Message-ID: <48C9721A.6070603@leemhuis.info> On 11.09.2008 20:36, Callum Lerwick wrote: > $ sudo yum update > Loaded plugins: fedorakmod, refresh-packagekit > [...] > So, an update in the Repo That Can Not Be Named, depends on an update in > the updates-newkey repo, not yet available, Just to set things straight: it's available for about 36 hours now afaics: https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00385.html The xine-lib-extras-nonfree package hit the livna repo about half a hour later. > thus breaking the transaction due to yum's pedantry. > > Something to be aware of if you have non-technical users using Livna, > and you didn't think you needed the skip-broken plugin... That is a well known problem; I put it up for broader discussion how to best fix it and described the root of the problem in details about one month ago: https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html I'm all for solving that problem, but that afaics should happen on the yum level and thus in Fedora and not in Livna/RPM Fusion. Seems skip-broken is the best answer, but that's not enabled by default in Fedora. Livna/RPM Fusion could fix that via its release-packages, but that's not nice and I want to avoid going that route. CU knurd From denis at poolshark.org Thu Sep 11 19:33:27 2008 From: denis at poolshark.org (Denis Leroy) Date: Thu, 11 Sep 2008 21:33:27 +0200 Subject: make force-tag gone In-Reply-To: <20080911184506.GA1486@redhat.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> <20080911184506.GA1486@redhat.com> Message-ID: <48C97287.8040402@poolshark.org> Dave Jones wrote: > On Thu, Sep 11, 2008 at 01:32:59AM +0200, Nicolas Mailhot wrote: > > Le mercredi 10 septembre 2008 ? 18:03 -0400, Dave Jones a ?crit : > > > > > Now, I could bump the specfile and add "disable option foo on ppc" but if I did > > > this, our changelogs would be absolutely enormous, and for very little gain. > > > > No one is asking you to add a new changelog line every time you make a > > small change. You can bump the version in the changelog at the same time > > you bump it elsewhere > > Regardless, it's still an extra file I have to edit for no apparent reason. So, did FeSCo meet and talk about this ? From jdieter at gmail.com Thu Sep 11 19:35:12 2008 From: jdieter at gmail.com (Jonathan Dieter) Date: Thu, 11 Sep 2008 22:35:12 +0300 Subject: Presto repositories for F8/F9 Message-ID: <1221161712.25860.12.camel@jdlaptop> If you are using the Presto yum plugin, the key change should have gone without a hitch, except for the minor detail that there were no deltarpms for the 600+ MB of updates. Angel (the x86_64 deltarpm mirror manager) and I (the i386 deltarpm mirror manager) have (hopefully) managed to get the .newkey repositories properly deltarpm'd. To use the Presto test repositories for .newkey packages, you need to set change fedora-updates-newkey.repo so that the mirrorlist line is as follows: mirrorlist=http://presto-mirrors.anmar.eu.org/mirrorlist?repo=updates-released-f$releasever.newkey&arch=$basearch I will make this announcement on fedora-list and update the appropriate page tomorrow if no major problems are reported. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jwboyer at gmail.com Thu Sep 11 19:52:52 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 11 Sep 2008 15:52:52 -0400 Subject: make force-tag gone In-Reply-To: <48C97287.8040402@poolshark.org> References: <1220955240.24928.69.camel@cookie.hadess.net> <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> <20080911184506.GA1486@redhat.com> <48C97287.8040402@poolshark.org> Message-ID: <20080911195252.GB26684@yoda.jdub.homelinux.org> On Thu, Sep 11, 2008 at 09:33:27PM +0200, Denis Leroy wrote: > Dave Jones wrote: >> On Thu, Sep 11, 2008 at 01:32:59AM +0200, Nicolas Mailhot wrote: >> > Le mercredi 10 septembre 2008 ? 18:03 -0400, Dave Jones a ?crit : >> > > > Now, I could bump the specfile and add "disable option foo on >> ppc" but if I did >> > > this, our changelogs would be absolutely enormous, and for very little gain. >> > > No one is asking you to add a new changelog line every time you >> make a >> > small change. You can bump the version in the changelog at the same time >> > you bump it elsewhere >> >> Regardless, it's still an extra file I have to edit for no apparent reason. > > So, did FeSCo meet and talk about this ? Yes. It was decided to leave the removal, and to also remove TAG_OPTS=-F. The decision was not unanimous. I believe the meeting summary will have links to the relevant discussion. josh From jwboyer at gmail.com Thu Sep 11 19:55:54 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 11 Sep 2008 15:55:54 -0400 Subject: modesetting feature status In-Reply-To: <1221155164.11745.13.camel@aglarond.local> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221145599.11745.3.camel@aglarond.local> <1221152956.4345.17.camel@atropine.boston.devel.redhat.com> <1221155164.11745.13.camel@aglarond.local> Message-ID: <20080911195554.GC26684@yoda.jdub.homelinux.org> On Thu, Sep 11, 2008 at 01:46:04PM -0400, Jeremy Katz wrote: >On Thu, 2008-09-11 at 13:09 -0400, Adam Jackson wrote: >> On Thu, 2008-09-11 at 11:06 -0400, Jeremy Katz wrote: >> > On Thu, 2008-09-11 at 17:18 +1000, Dave Airlie wrote: >> > > For the beta we are only going to enable Radeon support for the r300 to >> > > r500 class of hardware, while we await upstream changes to the Intel >> > > driver. >> > >> > ... we really shouldn't shove in major changes like this for a >> > significant chunk of hardware post-beta. Putting it in the beta means >> > that we get a relatively large chunk of testing done due to the >> > visibility surrounding the beta announce. As well as having time to fix >> > large problems that are uncovered. Later milestones both a) lack the >> > time for changes after them and b) the visibility. >> >> So are you saying: >> >> a) enable it for both, see what breaks > >I've been advocating us getting the pieces merged for a long time so >that we could see what was broken rather than trying to wait for a >mythical "perfection" that's been just another week or two out for on >the order of months now. > >> b) remove both, because, screw it > >This is a part of the contingency plan. But removing for both seems a >little extreme. > >There's also c) Just enable it for radeon. Intel users get pretty It's not working very well on radeon either. My laptop never gets a display (i686), and it's hosed on ppc in general. josh From dominik at greysector.net Thu Sep 11 20:04:07 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 11 Sep 2008 22:04:07 +0200 Subject: libbluetooth soname bump In-Reply-To: <48C94D2F.6090906@ioa.s.u-tokyo.ac.jp> References: <1221147676.24928.196.camel@cookie.hadess.net> <20080911163729.GA20000@mokona.greysector.net> <48C94D2F.6090906@ioa.s.u-tokyo.ac.jp> Message-ID: <20080911200407.GA24270@mokona.greysector.net> On Thursday, 11 September 2008 at 18:54, Mamoru Tasaka wrote: > Dominik 'Rathann' Mierzejewski wrote, at 09/12/2008 01:37 AM +9:00: > >On Thursday, 11 September 2008 at 17:41, Bastien Nocera wrote: > >>Heya, > >> > >>It all went a bit quick, and the new bluez 4.x utilities and libraries > >>have landed in rawhide. This means that a number of applications needed > >>to be rebuilt. > >[...] > >>* Apps that I couldn't rebuilt, didn't rebuild: > >>obexfs (http://koji.fedoraproject.org/koji/taskinfo?taskID=820234, not > >>bluez related) > > > >Builds fine in mock locally (fedora-devel-i386). > > > >Regards, > >R. > > > > Umm... what is strange is that root.log shows dependency resolution > problem, however mock kept rebuilding anyway: > > root.log: > DEBUG util.py:250: Total download size: 392 k > DEBUG util.py:250: ERROR with rpm_check_debug vs depsolve: > DEBUG util.py:250: Package obexftp-libs needs libbluetooth.so.2, this is > not available. > > build.log: > Building target platforms: i386 > Building for target i386 > Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.WApyoR > + umask 022 > ......... > > Perhaps a bug in yum or mock ? A PEBKAC, too. obexfs depends on obexftp, so these two should've been chain-built. > By the way now the dependency on obexftp is resolved and the build seems to > be > going well (scratch build) > http://koji.fedoraproject.org/koji/taskinfo?taskID=820680 And a regular build, too. Waiting for createrepo with the updated obexftp was enough. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jbarnes at virtuousgeek.org Thu Sep 11 20:03:01 2008 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Thu, 11 Sep 2008 13:03:01 -0700 Subject: Help wanted with Samba4 and OpenChange In-Reply-To: <1221016741.18128.64.camel@naomi.s4.naomi.abartlet.net> References: <1214877697.19140.28.camel@naomi.s4.naomi.abartlet.net> <200807010855.38912.jbarnes@virtuousgeek.org> <1221016741.18128.64.camel@naomi.s4.naomi.abartlet.net> Message-ID: <200809111303.01885.jbarnes@virtuousgeek.org> On Tuesday, September 9, 2008 8:19 pm Andrew Bartlett wrote: > On Tue, 2008-07-01 at 08:55 -0700, Jesse Barnes wrote: > > On Monday, June 30, 2008 7:01 pm Andrew Bartlett wrote: > > > I've recently been working on packaging Heimdal, Samba4 and OpenChange > > > for Fedora. > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=452212 (heimdal) > > > https://bugzilla.redhat.com/show_bug.cgi?id=453083 (Samba4) > > > https://bugzilla.redhat.com/show_bug.cgi?id=453395 (libmapi - > > > OpenChange) > > > > > > This will enable much better access to Microsoft Exchange servers from > > > clients such as kdepim, and hopefully Evolution (pending a > > > re-licensing). > > > > > > I've got a feature page for this here: > > > > > > https://fedoraproject.org/wiki/Features/OpenChange > > > > > > Now, the reason I'm posting here is that I would rather not do this > > > alone, and would love some co-maintainers of the packagers above, or at > > > least some help with the review and sponsorship, or advise on the best > > > way forward. > > > > > > Any assistance gratefully received, > > > > I've been really looking forward to this; how can I help? What's > > involved with co-maintainership? At the very least I can help with > > testing and such... > > I recently posted my intention to orphan this effort. Do you wish to > take it over? I wish I could commit to doing it, but I don't think I have the time. And it looks like KDE upstream has abandoned libmapi support, which I definitely don't have time to deal with, but maybe someone else will step up? -- Jesse Barnes, Intel Open Source Technology Center From tmraz at redhat.com Thu Sep 11 20:13:23 2008 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 11 Sep 2008 22:13:23 +0200 Subject: make force-tag gone In-Reply-To: <20080911195252.GB26684@yoda.jdub.homelinux.org> References: <1220955240.24928.69.camel@cookie.hadess.net> <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> <20080911184506.GA1486@redhat.com> <48C97287.8040402@poolshark.org> <20080911195252.GB26684@yoda.jdub.homelinux.org> Message-ID: <1221164003.3332.82.camel@vespa.frost.loc> On Thu, 2008-09-11 at 15:52 -0400, Josh Boyer wrote: > On Thu, Sep 11, 2008 at 09:33:27PM +0200, Denis Leroy wrote: > > Dave Jones wrote: > >> On Thu, Sep 11, 2008 at 01:32:59AM +0200, Nicolas Mailhot wrote: > >> > Le mercredi 10 septembre 2008 ? 18:03 -0400, Dave Jones a ?crit : > >> > > > Now, I could bump the specfile and add "disable option foo on > >> ppc" but if I did > >> > > this, our changelogs would be absolutely enormous, and for very little gain. > >> > > No one is asking you to add a new changelog line every time you > >> make a > >> > small change. You can bump the version in the changelog at the same time > >> > you bump it elsewhere > >> > >> Regardless, it's still an extra file I have to edit for no apparent reason. > > > > So, did FeSCo meet and talk about this ? > > Yes. It was decided to leave the removal, and to also remove TAG_OPTS=-F. > The decision was not unanimous. I believe the meeting summary will have > links to the relevant discussion. OK, hopefully nobody will object if I always use this script before make tag: REL=date +%s;sed s/@REL@/$REL/g spec.in >spec;cvs ci -m 'Bump' :) -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From tmraz at redhat.com Thu Sep 11 20:14:23 2008 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 11 Sep 2008 22:14:23 +0200 Subject: make force-tag gone In-Reply-To: <1221164003.3332.82.camel@vespa.frost.loc> References: <1220955240.24928.69.camel@cookie.hadess.net> <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> <20080911184506.GA1486@redhat.com> <48C97287.8040402@poolshark.org> <20080911195252.GB26684@yoda.jdub.homelinux.org> <1221164003.3332.82.camel@vespa.frost.loc> Message-ID: <1221164063.3332.83.camel@vespa.frost.loc> On Thu, 2008-09-11 at 22:13 +0200, Tomas Mraz wrote: > On Thu, 2008-09-11 at 15:52 -0400, Josh Boyer wrote: > > On Thu, Sep 11, 2008 at 09:33:27PM +0200, Denis Leroy wrote: > > > Dave Jones wrote: > > >> On Thu, Sep 11, 2008 at 01:32:59AM +0200, Nicolas Mailhot wrote: > > >> > Le mercredi 10 septembre 2008 ? 18:03 -0400, Dave Jones a ?crit : > > >> > > > Now, I could bump the specfile and add "disable option foo on > > >> ppc" but if I did > > >> > > this, our changelogs would be absolutely enormous, and for very little gain. > > >> > > No one is asking you to add a new changelog line every time you > > >> make a > > >> > small change. You can bump the version in the changelog at the same time > > >> > you bump it elsewhere > > >> > > >> Regardless, it's still an extra file I have to edit for no apparent reason. > > > > > > So, did FeSCo meet and talk about this ? > > > > Yes. It was decided to leave the removal, and to also remove TAG_OPTS=-F. > > The decision was not unanimous. I believe the meeting summary will have > > links to the relevant discussion. > > OK, hopefully nobody will object if I always use this script before make > tag: > > REL=date +%s;sed s/@REL@/$REL/g spec.in >spec;cvs ci -m 'Bump' of course I forgot $() around date :) -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From rdieter at math.unl.edu Thu Sep 11 20:21:20 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 11 Sep 2008 15:21:20 -0500 Subject: Help wanted with Samba4 and OpenChange References: <1214877697.19140.28.camel@naomi.s4.naomi.abartlet.net> <200807010855.38912.jbarnes@virtuousgeek.org> <1221016741.18128.64.camel@naomi.s4.naomi.abartlet.net> <200809111303.01885.jbarnes@virtuousgeek.org> Message-ID: Jesse Barnes wrote: > And it looks like KDE upstream has abandoned libmapi support The akonadi/kdepim folks were very keen on using libmapi when I discussed the topic @ akademy. When/where did you hear otherwise? -- Rex From mw_triad at users.sourceforge.net Thu Sep 11 20:21:50 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 11 Sep 2008 15:21:50 -0500 Subject: Beware: External repos can break key transition In-Reply-To: <604aa7910809111151s330ea17cr5c5d08d6aefa5862@mail.gmail.com> References: <1221158197.6431.24.camel@localhost.localdomain> <604aa7910809111151s330ea17cr5c5d08d6aefa5862@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > 2008/9/11 Callum Lerwick : >> Something to be aware of if you have non-technical users using Livna, >> and you didn't think you needed the skip-broken plugin... > > Seems okay for me. I just installed xine-lib-extras-nonfree on my > 32bit system. Perhaps this a transitory issue due to one of the > mirrors not being fully synced? That seems likely; I just checked again, and the new fedora-release is only just now showing up for my home machine. The livna update has been there for a few days. I didn't try without --exclude=xine\*, but I bet things would fail before the newkey repos are installed. -- Matthew If you believe you received this e-mail in error, you are probably sadly mistaken, but if not, aren't you lucky? -- Unknown From skvidal at fedoraproject.org Thu Sep 11 20:25:58 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 11 Sep 2008 16:25:58 -0400 Subject: [Server-devel] recover from broken yum transaction In-Reply-To: <1FE222BE-D59E-46EA-9193-D3A443E8671A@laptop.org> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <46a038f90809102242w31869559mc6f0b22a291f52b9@mail.gmail.com> <1221145265.987.183.camel@rosebud> <1FE222BE-D59E-46EA-9193-D3A443E8671A@laptop.org> Message-ID: <1221164758.987.224.camel@rosebud> On Thu, 2008-09-11 at 16:24 -0400, John Watlington wrote: > On Sep 11, 2008, at 11:01 AM, Seth Vidal wrote: > > > On Thu, 2008-09-11 at 17:42 +1200, Martin Langhoff wrote: > >> On Thu, Sep 11, 2008 at 3:50 PM, Seth Vidal > >> wrote: > >>> When this happens you should run: > >>> yum-complete-transaction > >> > >> Interesting toy! I think you mentioned it at Fudcon Boston and I > >> hadn't been able to recall the right name. > >> > >> Thinking of using it in the use case of the school server (very > >> unreliable power, no sysadmins available, 100% unattended updates) - > >> > >> - Is it safe to run at boot time via an init script? > > > > as long as the network is up, it should be. > > I assume you mean "as long as the server has an Internet connection > to the yum repositories" ? Or did you mean "as long as the networking > subsystem is up" ? > > This may be a show stopper for us, as plenty of servers won't have a > reliable > network connection to the Internet. > Then you have the yum-complete-transaction be called if and only if the internet connection is working. -sv From kevin.kofler at chello.at Thu Sep 11 20:35:30 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 11 Sep 2008 20:35:30 +0000 (UTC) Subject: make force-tag gone References: <1220955240.24928.69.camel@cookie.hadess.net> <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> <20080911184506.GA1486@redhat.com> <48C97287.8040402@poolshark.org> <20080911195252.GB26684@yoda.jdub.homelinux.org> Message-ID: Josh Boyer gmail.com> writes: > Yes. It was decided to leave the removal, and to also remove TAG_OPTS=-F. Yet another abuse of power by FESCo. Why can't FESCo listen to the many developers who objected to the removal here, including developers like Dave Jones and Rex Dieter who are experienced Fedora packagers and do much of the actual packaging work in Fedora (Dave Jones is the primary maintainer of the kernel, Rex Dieter is #4 in number of builds per packager)? Why can't the decision be left to the people who are actually affected by the change, i.e. the packagers? FESCo is supposed to represent the interests of the packagers (that's what they're elected for), not their own, too bad they actually do the latter. > The decision was not unanimous. Nice to see there were at least some sane people left... Kevin "#7 in number of builds per packager and still gets ignored by FESCo on an issue which directly affects people doing builds" Kofler From Jochen at herr-schmitt.de Thu Sep 11 20:45:26 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 11 Sep 2008 22:45:26 +0200 Subject: Possible gcc issue In-Reply-To: <48C96B27.9020700@redhat.com> References: <48C94597.2000705@herr-schmitt.de> <48C96B27.9020700@redhat.com> Message-ID: <0ML31I-1Kdt2h29yK-0006cn@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 11 Sep 2008 12:01:59 -0700, you wrote: >Not a gcc bug and no bug in glibc. This is inline asm which requires >registers which for some reason are not available. > >Compile this file with __NO_STRING_INLINES defined. Thank you for your hint, I'm now able to build the package on koji. But I have the following question: Why does this issue occurs only on rawhide in the i386-architecture. On F-9 or on other architectures this issue doesn't occurs. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) Charset: us-ascii wj8DBQFIyYNvT2AHK6txfgwRAvI+AKCdk4tMjhUaQxfc9QzR/a345K38vACeO2MX b2dIg2Lb2hzlfSwWXE89ybQ= =HLON -----END PGP SIGNATURE----- From denis at poolshark.org Thu Sep 11 20:49:54 2008 From: denis at poolshark.org (Denis Leroy) Date: Thu, 11 Sep 2008 22:49:54 +0200 Subject: make force-tag gone In-Reply-To: <20080911195252.GB26684@yoda.jdub.homelinux.org> References: <1220955240.24928.69.camel@cookie.hadess.net> <935ead450809091001k46879e72q216ef5e2762ddc4d@mail.gmail.com> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> <20080911184506.GA1486@redhat.com> <48C97287.8040402@poolshark.org> <20080911195252.GB26684@yoda.jdub.homelinux.org> Message-ID: <48C98472.1090905@poolshark.org> Josh Boyer wrote: > Yes. It was decided to leave the removal, and to also remove TAG_OPTS=-F. > The decision was not unanimous. I believe the meeting summary will have > links to the relevant discussion. Well there's no question we can all live without force-tag :-), it's merely a minor annoyance that packagers will have to deal with. But I'm really bothered by the message this is sending. Infrastructure takes away a tool that was useful and popular amongst packagers, with NO effort to provide an alternative or at least some workaround for failed builds retagging. This is not cool. I would like to kindly request that infrastructure makes some effort to come up with a solution (i.e a reasonably short term one, not just "migrate to new SCM"). -denis From jeff at ocjtech.us Thu Sep 11 20:51:57 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 11 Sep 2008 15:51:57 -0500 Subject: make force-tag gone In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> <20080911184506.GA1486@redhat.com> <48C97287.8040402@poolshark.org> <20080911195252.GB26684@yoda.jdub.homelinux.org> Message-ID: <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> On Thu, Sep 11, 2008 at 3:35 PM, Kevin Kofler wrote: > Josh Boyer gmail.com> writes: >> Yes. It was decided to leave the removal, and to also remove TAG_OPTS=-F. > > Yet another abuse of power by FESCo. Why can't FESCo listen to the many > developers who objected to the removal here, including developers like Dave > Jones and Rex Dieter who are experienced Fedora packagers and do much of the > actual packaging work in Fedora (Dave Jones is the primary maintainer of the > kernel, Rex Dieter is #4 in number of builds per packager)? Why can't the > decision be left to the people who are actually affected by the change, i.e. > the packagers? FESCo is supposed to represent the interests of the packagers > (that's what they're elected for), not their own, too bad they actually do the > latter. Basically because the only argument for keeping "make force-tag" wasn't a technical one. There's a need to ensure that a tag points to the exact source that was used to build a package. Disallowing force-tag is the easiest way to do that. Creating some hack that checks with koji to see if there's a successful build associated with a tag before allowing a force-tag operation to success sounds like a recipe for really slow and expensive CVS operations. >> The decision was not unanimous. > > Nice to see there were at least some sane people left... Agreed :) -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" From jkeating at redhat.com Thu Sep 11 21:03:20 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 11 Sep 2008 14:03:20 -0700 Subject: make force-tag gone In-Reply-To: <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> <20080911184506.GA1486@redhat.com> <48C97287.8040402@poolshark.org> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> Message-ID: <1221167000.26178.5.camel@luminos.localdomain> On Thu, 2008-09-11 at 15:51 -0500, Jeffrey Ollie wrote: > > Basically because the only argument for keeping "make force-tag" > wasn't a technical one. There's a need to ensure that a tag points to > the exact source that was used to build a package. Disallowing > force-tag is the easiest way to do that. Creating some hack that > checks with koji to see if there's a successful build associated with > a tag before allowing a force-tag operation to success sounds like a > recipe for really slow and expensive CVS operations. That's pretty incorrect. There is lots of evidence where being able to move forward contents of the build target without fiddling with the target itself has value. Both in time saved and interaction with upstreams. Really it comes down to a premature desire to clean up the way that Koji builds things. For lack of something easier, koji builds from a CVS tag based on the N-V-R of a package build. For lack of knowledge of something easier, the thought is that tag is the only thing we can use to get back to the actual source used for a build. It's not. I've been told of at least one way to use something different, the CVS/Entries file. Yeah, it might take a little work to cook up an app to go from that to the source, but that's fine, that's work the person who wants this has to do. Instead, we're forcing all of our users to change how they work because some people feel uncomfortable about something WE'RE NOT EVEN RELYING UPON!! We don't rely upon anything to go backwards at this time. Nothing. I have no objections to finding a way to make absolutely certain that what koji builds from is immutable and can be pulled out of source control. No objections at all. I highly object to forcing our users to come up with this for us, because they're so pissed off that we've removed tag moving. Simply put, figure out a way to meet the immutable requirements first, before taking away the ability to move tags forward. Don't remove that ability, and then sometime in the indeterminate future fix the immutable problem. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Thu Sep 11 19:35:36 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 11 Sep 2008 21:35:36 +0200 Subject: Beware: External repos can break key transition In-Reply-To: <604aa7910809111151s330ea17cr5c5d08d6aefa5862@mail.gmail.com> References: <1221158197.6431.24.camel@localhost.localdomain> <604aa7910809111151s330ea17cr5c5d08d6aefa5862@mail.gmail.com> Message-ID: <48C97308.6050909@leemhuis.info> On 11.09.2008 20:51, Jeff Spaleta wrote: > 2008/9/11 Callum Lerwick : >> Something to be aware of if you have non-technical users using Livna, >> and you didn't think you needed the skip-broken plugin... > Seems okay for me. I just installed xine-lib-extras-nonfree on my > 32bit system. Perhaps this a transitory issue due to one of the > mirrors not being fully synced? Likely; but the problem happens each time when Livna/RPM Fusion packages with deps on a specific Fedora packages get pushed in sync; that creates a lot of trouble -- I'd say once for 24 hours each two weeks. Most people blame livna for it, but in fact it's a general problem and livna can only push to early or to late. More details: https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html CU knurd From jeff at ocjtech.us Thu Sep 11 21:00:59 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Thu, 11 Sep 2008 16:00:59 -0500 Subject: make force-tag gone In-Reply-To: <48C98472.1090905@poolshark.org> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> <20080911184506.GA1486@redhat.com> <48C97287.8040402@poolshark.org> <20080911195252.GB26684@yoda.jdub.homelinux.org> <48C98472.1090905@poolshark.org> Message-ID: <935ead450809111400w117d0e8br68f42f574afeecb8@mail.gmail.com> On Thu, Sep 11, 2008 at 3:49 PM, Denis Leroy wrote: > Josh Boyer wrote: >> >> Yes. It was decided to leave the removal, and to also remove TAG_OPTS=-F. >> The decision was not unanimous. I believe the meeting summary will have >> links to the relevant discussion. > > Well there's no question we can all live without force-tag :-), it's merely > a minor annoyance that packagers will have to deal with. > > But I'm really bothered by the message this is sending. Infrastructure takes > away a tool that was useful and popular amongst packagers, with NO effort to > provide an alternative or at least some workaround for failed builds > retagging. This is not cool. I would like to kindly request that > infrastructure makes some effort to come up with a solution (i.e a > reasonably short term one, not just "migrate to new SCM"). Actually, migrating to a new SCM would likely kill the notion of force-tag altogether because one of the leading candidates to replace CVS (git) wants strong guarantees that tags are not mutable (hg and bzr may do the same but I'm not as familiar with them to say). What I'd like to see though is a Makefile option that will check out a fresh copy of the package in a separate directory and run "make srpm" to see if everything has been committed to CVS that will be needed to create the SRPM. -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" From Jochen at herr-schmitt.de Thu Sep 11 19:10:13 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Thu, 11 Sep 2008 21:10:13 +0200 Subject: Possible gcc issue In-Reply-To: <48C95727.9070602@redhat.com> References: <48C94597.2000705@herr-schmitt.de> <48C94DBF.5030404@redhat.com> <48C9561B.6010901@herr-schmitt.de> <48C95727.9070602@redhat.com> Message-ID: <0MKwtQ-1KdrYY1A2L-0005KE@mrelayeu.kundenserver.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 11 Sep 2008 18:36:39 +0100, you wrote: >Jochen Schmitt wrote: >> Andrew Haley schrieb: >>> Jochen Schmitt wrote: >>>> Hallo, >>>> >>>> during a koni scratch build I have got the following error messages: >>>> >>>> strings.c: In function 'cob_string_append': >>>> /usr/include/bits/string.h:190: error: can't find a register in class >>>> 'GENERAL_REGS' while reloading 'asm' >>>> /usr/include/bits/string.h:190: error: 'asm' operand has impossible >>>> constraints >>>> /usr/include/bits/string.h:190: error: 'asm' operand has impossible >>>> constraints >>>> >>>> I would ask, is this a gcc specific issue where I should file a bug >>>> report agains gcc, >>> Probably not. Do that compilation with -save-temps and let's see the >>> preprocessed .i file. Then we'll see if it's a gcc bug. >> I have try out the -save-temp flags and have got .s and .lo files, but >> not the >> .i file. >> >> In which directory should I saarch for this files. > >In the directory where the compilation is run. It will be there, you >just have to search for it. If you still can't find it, use gcc -E. It's seems, that the .1 files will only generated, if the compiliation was failed. I have uploaded the following files: http://www.herr-schmitt.de/pub/open-cobol/strings.1 http://www.herr-schmitt.de/pub/open-cobol/build.log http://www.herr-schmitt.de/pub/open-cobol/open-cobol-1.0.90-3.fc10.src.rpm Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) Charset: us-ascii wj8DBQFIyW0eT2AHK6txfgwRArzvAJ9OWzeSYnbmVANHLRq8YmfEyUnAvQCeLk+r ktN0XkUXS8zhvT6XWWy3wgo= =Jp2s -----END PGP SIGNATURE----- From ajax at redhat.com Thu Sep 11 21:20:04 2008 From: ajax at redhat.com (Adam Jackson) Date: Thu, 11 Sep 2008 17:20:04 -0400 Subject: make force-tag gone In-Reply-To: <1221167000.26178.5.camel@luminos.localdomain> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> <20080911184506.GA1486@redhat.com> <48C97287.8040402@poolshark.org> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> Message-ID: <1221168004.4345.32.camel@atropine.boston.devel.redhat.com> On Thu, 2008-09-11 at 14:03 -0700, Jesse Keating wrote: > On Thu, 2008-09-11 at 15:51 -0500, Jeffrey Ollie wrote: > > > > Basically because the only argument for keeping "make force-tag" > > wasn't a technical one. There's a need to ensure that a tag points to > > the exact source that was used to build a package. Disallowing > > force-tag is the easiest way to do that. Creating some hack that > > checks with koji to see if there's a successful build associated with > > a tag before allowing a force-tag operation to success sounds like a > > recipe for really slow and expensive CVS operations. > > That's pretty incorrect. There is lots of evidence where being able to > move forward contents of the build target without fiddling with the > target itself has value. Both in time saved and interaction with > upstreams. > > Really it comes down to a premature desire to clean up the way that Koji > builds things. For lack of something easier, koji builds from a CVS tag > based on the N-V-R of a package build. For lack of knowledge of > something easier, the thought is that tag is the only thing we can use > to get back to the actual source used for a build. It's not. I've been > told of at least one way to use something different, the CVS/Entries > file. Yeah, it might take a little work to cook up an app to go from > that to the source, but that's fine, that's work the person who wants > this has to do. Attached patch implements this, or at least attempts to. I wrote it blind, I'm reasonably sure it'd work but I don't have a local kojid instance to test with. If I really have to set one up, I will. Seriously, removing force-tag is a bad solution to that problem. This took all of 35 minutes to write, counting checking out koji and figuring out enough kojid context to have some idea of what to write. I don't even really know python that well. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: koji-1.2.6-preserve-Entries-for-cvs.patch Type: text/x-patch Size: 867 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jbarnes at virtuousgeek.org Thu Sep 11 21:28:17 2008 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Thu, 11 Sep 2008 14:28:17 -0700 Subject: Help wanted with Samba4 and OpenChange In-Reply-To: References: <1214877697.19140.28.camel@naomi.s4.naomi.abartlet.net> <200809111303.01885.jbarnes@virtuousgeek.org> Message-ID: <200809111428.17212.jbarnes@virtuousgeek.org> On Thursday, September 11, 2008 1:21 pm Rex Dieter wrote: > Jesse Barnes wrote: > > And it looks like KDE upstream has abandoned libmapi support > > The akonadi/kdepim folks were very keen on using libmapi when I discussed > the topic @ akademy. When/where did you hear otherwise? When I last checked out the code it was disabled in the build. And when I re-enabled it I got lots of compile errors, so I assumed it hadn't been touched in awhile. Hopefully things have changed since then... -- Jesse Barnes, Intel Open Source Technology Center From hughsient at gmail.com Thu Sep 11 21:39:56 2008 From: hughsient at gmail.com (Richard Hughes) Date: Thu, 11 Sep 2008 21:39:56 +0000 Subject: Feature Proposal: Use cases database In-Reply-To: <48C95C46.1060904@gmail.com> References: <1220991029.3782.47.camel@choeger6> <48C767E7.9040801@gmail.com> <1221059648.17299.103.camel@hughsie-work> <1221062578.21306.13.camel@rousalka.okg> <1221064863.17299.134.camel@hughsie-work> <5cb581610364a94649b91d5bc6e50928.squirrel@rousalka.dyndns.org> <1221129641.22654.24.camel@hughsie-work> <1221141890.22654.75.camel@hughsie-work> <48C95C46.1060904@gmail.com> Message-ID: <15e53e180809111439r4c66178ax1440f9940544fd79@mail.gmail.com> On 9/11/08, Les Mikesell wrote: > Can you describe a whole machine with a catalog file? I guess you could, but they are not really designed for that. Richard From a.badger at gmail.com Thu Sep 11 21:47:49 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 11 Sep 2008 14:47:49 -0700 Subject: make force-tag gone In-Reply-To: <1221167000.26178.5.camel@luminos.localdomain> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> <20080911184506.GA1486@redhat.com> <48C97287.8040402@poolshark.org> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> Message-ID: <48C99205.9060903@gmail.com> Jesse Keating wrote: > Really it comes down to a premature desire to clean up the way that Koji > builds things. For lack of something easier, koji builds from a CVS tag > based on the N-V-R of a package build. For lack of knowledge of > something easier, the thought is that tag is the only thing we can use > to get back to the actual source used for a build. It's not. I've been > told of at least one way to use something different, the CVS/Entries > file. Yeah, it might take a little work to cook up an app to go from > that to the source, but that's fine, that's work the person who wants > this has to do. > This specific implementation would be a bad thing. Instead of having a nice, SCM abstract method of communicating to koji what to build from (the tag) you'd be resorting to CVS specific knowledge. > Instead, we're forcing all of our users to change how they work because > some people feel uncomfortable about something WE'RE NOT EVEN RELYING > UPON!! We don't rely upon anything to go backwards at this time. > Nothing. I have no objections to finding a way to make absolutely > certain that what koji builds from is immutable and can be pulled out of > source control. No objections at all. I highly object to forcing our > users to come up with this for us, because they're so pissed off that > we've removed tag moving. > > Simply put, figure out a way to meet the immutable requirements first, > before taking away the ability to move tags forward. Don't remove that > ability, and then sometime in the indeterminate future fix the immutable > problem. So I see a certain bit of mismatch here between what koji is made to do and what people want to do. It's also one of the contributing reasons we aren't yet building EPEL in koji: Reproducibility of Builds In order for this to hold true, you have to consider the input streams (cvs, lookaside cache, and download repositories) as part of koji. If we could upload new files to the lookaside cache locations or arbitrarily change what's in the SCM or change the packages in the repository without koji knowing then koji loses the ability to reprodce builds. Note that I think the particular implementation of Makefile.common and koji forces us into a no-win situation in this. On the one hand, tags that go into the buildsystem must be immutable in order for the reproducibility of builds to be assured. On the other hand, the tag is tied to the version and release of the package in such a way that it's impossible to submit a new build without bumping the version in the spec file even when no packages were created in the previous run. We need to decouple these. I think it'll require changes to Makefile.common (to write the tags), CVSROOT/admin/tagcheck (to check for immutability of specific tags), and koji (to check that the Version and Release in the spec file isn't currently a building or built package). -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From martin.langhoff at gmail.com Thu Sep 11 21:54:42 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Fri, 12 Sep 2008 09:54:42 +1200 Subject: recover from broken yum transaction In-Reply-To: <1221145265.987.183.camel@rosebud> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <46a038f90809102242w31869559mc6f0b22a291f52b9@mail.gmail.com> <1221145265.987.183.camel@rosebud> Message-ID: <46a038f90809111454n79c9aaf3k81445e7f527a6069@mail.gmail.com> On Fri, Sep 12, 2008 at 3:01 AM, Seth Vidal wrote: >> - Is it safe to run at boot time via an init script? > as long as the network is up, it should be. That is not very useful for us. I don't worry so much about the machine being killed in the 'download stuff' part, bit AFAIK that's not part of the 'transaction'. When yum-complete-transaction is called, I am expecting it to work with the RPMs it has, and ensure anything it was trying to do gets done... WRT networking, in places like Peru my rule of thumb is that 50% of the servers will _not_ have internet. Package installations / upgrades are very likely to happen by sending out USB keys with a bunch of RPMs, and a GPG-signed script that triggers the yum process. yum supports -C... can yum-complete-transaction support -C as well? >> - Is there an easy way to check for pending transactions? > > yum-complete-transaction checks for them itself Yes, though it's useful to be able to check that for logging/reporting... >> - Does it have useful exit codes indicating whether it's done anything? > > If the results codes are not good enough we can fix that easily enough. I am asking because checking the manpage and reading the source did not give me any hints as to exit codes. Neither does 'man yum' talk about exit codes except for the "check-update" command. So I wonder what's the expected behaviour WRT exit codes for yum? >> Is that different from `package-cleanup --problems` ? > > --problems reports a different set of things - package conflicts and > unresolved deps. A dupe is not, implicitly, a problem. it CAN be, but it > is not always. Right - that's lower priority for my use cases. Thanks for the hint. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From ajax at redhat.com Thu Sep 11 21:56:10 2008 From: ajax at redhat.com (Adam Jackson) Date: Thu, 11 Sep 2008 17:56:10 -0400 Subject: make force-tag gone In-Reply-To: <48C99205.9060903@gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> <20080911184506.GA1486@redhat.com> <48C97287.8040402@poolshark.org> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> Message-ID: <1221170170.4345.35.camel@atropine.boston.devel.redhat.com> On Thu, 2008-09-11 at 14:47 -0700, Toshio Kuratomi wrote: > Jesse Keating wrote: > > Really it comes down to a premature desire to clean up the way that Koji > > builds things. For lack of something easier, koji builds from a CVS tag > > based on the N-V-R of a package build. For lack of knowledge of > > something easier, the thought is that tag is the only thing we can use > > to get back to the actual source used for a build. It's not. I've been > > told of at least one way to use something different, the CVS/Entries > > file. Yeah, it might take a little work to cook up an app to go from > > that to the source, but that's fine, that's work the person who wants > > this has to do. > > > This specific implementation would be a bad thing. Instead of having a > nice, SCM abstract method of communicating to koji what to build from > (the tag) you'd be resorting to CVS specific knowledge. Okay, so scm.checkout grows another outparam that return the reproducability information. You'd get a tag from git, Entries from CVS, revision number from SVN... This isn't materially more work. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Thu Sep 11 21:56:26 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 11 Sep 2008 14:56:26 -0700 Subject: make force-tag gone In-Reply-To: <48C99205.9060903@gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> <20080911184506.GA1486@redhat.com> <48C97287.8040402@poolshark.org> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> Message-ID: <1221170186.26178.9.camel@luminos.localdomain> On Thu, 2008-09-11 at 14:47 -0700, Toshio Kuratomi wrote: > This specific implementation would be a bad thing. Instead of having a > nice, SCM abstract method of communicating to koji what to build from > (the tag) you'd be resorting to CVS specific knowledge. I don't necessarily disagree, however that's something to figure out /before/ you remove force-tag capabilities. Not after. > > > Instead, we're forcing all of our users to change how they work because > > some people feel uncomfortable about something WE'RE NOT EVEN RELYING > > UPON!! We don't rely upon anything to go backwards at this time. > > Nothing. I have no objections to finding a way to make absolutely > > certain that what koji builds from is immutable and can be pulled out of > > source control. No objections at all. I highly object to forcing our > > users to come up with this for us, because they're so pissed off that > > we've removed tag moving. > > > > Simply put, figure out a way to meet the immutable requirements first, > > before taking away the ability to move tags forward. Don't remove that > > ability, and then sometime in the indeterminate future fix the immutable > > problem. > > So I see a certain bit of mismatch here between what koji is made to do > and what people want to do. It's also one of the contributing reasons > we aren't yet building EPEL in koji: > > Reproducibility of Builds > > In order for this to hold true, you have to consider the input streams > (cvs, lookaside cache, and download repositories) as part of koji. If > we could upload new files to the lookaside cache locations or > arbitrarily change what's in the SCM or change the packages in the > repository without koji knowing then koji loses the ability to reprodce > builds. > > Note that I think the particular implementation of Makefile.common and > koji forces us into a no-win situation in this. On the one hand, tags > that go into the buildsystem must be immutable in order for the > reproducibility of builds to be assured. On the other hand, the tag is > tied to the version and release of the package in such a way that it's > impossible to submit a new build without bumping the version in the spec > file even when no packages were created in the previous run. We need to > decouple these. I think it'll require changes to Makefile.common (to > write the tags), CVSROOT/admin/tagcheck (to check for immutability of > specific tags), and koji (to check that the Version and Release in the > spec file isn't currently a building or built package). That way has been discussed as well, and is being worked on by Mike M. and Mike B. My big point here though is that work should be done, tested, and put in place, before any act of removing force-tag was done. We're not just talking about the Make alias(es) for it, because if you're really serious about wanting to prevent tag moves, you have to block at at the CVS server side. It's an arms race. This is a clear case where it must first continue to be usable by the users before you fix the underlying problem. First, do no harm. We should have learned this lesson after the Core/Extras merge and various fallouts therein. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kzak at redhat.com Thu Sep 11 22:01:48 2008 From: kzak at redhat.com (Karel Zak) Date: Fri, 12 Sep 2008 00:01:48 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1221151737.27183.74.camel@ignacio.lan> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <544eb990809110414x44c1c563l7d0da7859c166780@mail.gmail.com> <16de708d0809110814l6eda770ey54db2073391e0511@mail.gmail.com> <544eb990809110940j26d828ady63bc91e3c50cca3d@mail.gmail.com> <1221151737.27183.74.camel@ignacio.lan> Message-ID: <20080911220148.GI6092@nb.net.home> On Thu, Sep 11, 2008 at 12:48:57PM -0400, Ignacio Vazquez-Abrams wrote: > On Thu, 2008-09-11 at 17:40 +0100, Bill Crawford wrote: > > If you have multi-channel hardware that mixes itself, then using > > PulseAudio sort of defeats the purpose of that hardware ;o) > > You're absolutely right... if all you're using PulseAudio for is basic > mixing. But as soon as you need/want something like per-app volume > control, network transport, audio stream redirection, or audio device > hotplugging then you want PulseAudio. How many **ordinary** Fedora users really need these **advanced** features? For example I have never had any serious SW problem with sound on Linux. And I use it for more than 10 years... Karel -- Karel Zak From john.ellson at comcast.net Thu Sep 11 22:13:47 2008 From: john.ellson at comcast.net (John Ellson) Date: Thu, 11 Sep 2008 18:13:47 -0400 Subject: SOLVED: Re: what is keeping per-user state outside of user's $HOME ? In-Reply-To: <1221160251.3956.12.camel@localhost.localdomain> References: <48C92DE3.8080406@comcast.net> <1221146228.3388.170.camel@luminos.localdomain> <48C939AD.4040808@comcast.net> <604aa7910809110920n45931e39sc9a2598090e85080@mail.gmail.com> <48C94F65.10707@comcast.net> <1221154202.3956.0.camel@localhost.localdomain> <48C96A7B.40005@comcast.net> <1221160251.3956.12.camel@localhost.localdomain> Message-ID: <48C9981B.2050401@comcast.net> Matthias Clasen wrote: > [ gnome-panel ] [ gnome-panel ] > > You probably want to break in panel_lock_screen_action_available and see > what is going on there. > > Thanks for that clue. I've found my problem. It turns out that there is a new feature: System -> Preferences -> Lockdown Editor which is provided by a package called "pessulus" (Obvious! How could I miss it!) This gui allows the administrator to enable/disable certain features for each user. It stores the setting away somewhere in gconf magic-land. I couldn't work out where but it definitely isn't under $HOME. I think what happened was that I installed this new "pessulus" package, then tried it out from the command line to see what it did, randomly clicked on some buttons, then promptly forgot about it and didn't know how to get it back. -- John Ellson From a.badger at gmail.com Thu Sep 11 22:19:48 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 11 Sep 2008 15:19:48 -0700 Subject: make force-tag gone In-Reply-To: <1221170186.26178.9.camel@luminos.localdomain> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> <20080911184506.GA1486@redhat.com> <48C97287.8040402@poolshark.org> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> <1221170186.26178.9.camel@luminos.localdomain> Message-ID: <48C99984.1080209@gmail.com> Jesse Keating wrote: > On Thu, 2008-09-11 at 14:47 -0700, Toshio Kuratomi wrote: >> This specific implementation would be a bad thing. Instead of having a >> nice, SCM abstract method of communicating to koji what to build from >> (the tag) you'd be resorting to CVS specific knowledge. > > I don't necessarily disagree, however that's something to figure > out /before/ you remove force-tag capabilities. Not after. > Sure. *I'm* not going to dispute that part of the discussion :-) -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From a.badger at gmail.com Thu Sep 11 22:30:09 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 11 Sep 2008 15:30:09 -0700 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080911220148.GI6092@nb.net.home> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <544eb990809110414x44c1c563l7d0da7859c166780@mail.gmail.com> <16de708d0809110814l6eda770ey54db2073391e0511@mail.gmail.com> <544eb990809110940j26d828ady63bc91e3c50cca3d@mail.gmail.com> <1221151737.27183.74.camel@ignacio.lan> <20080911220148.GI6092@nb.net.home> Message-ID: <48C99BF1.5040908@gmail.com> Karel Zak wrote: > On Thu, Sep 11, 2008 at 12:48:57PM -0400, Ignacio Vazquez-Abrams wrote: >> On Thu, 2008-09-11 at 17:40 +0100, Bill Crawford wrote: >>> If you have multi-channel hardware that mixes itself, then using >>> PulseAudio sort of defeats the purpose of that hardware ;o) >> You're absolutely right... if all you're using PulseAudio for is basic >> mixing. But as soon as you need/want something like per-app volume >> control, network transport, audio stream redirection, or audio device >> hotplugging then you want PulseAudio. > > How many **ordinary** Fedora users really need these **advanced** > features? > > For example I have never had any serious SW problem with sound on > Linux. And I use it for more than 10 years... > Quite a few need network transport when you talk about thinclient. It's made worse by the fact that in many of those situations you have a whole bunch of extremely ordinary Fedora users to a small number of entry-level-knowledge admins. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From kevin.kofler at chello.at Thu Sep 11 22:32:54 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 11 Sep 2008 22:32:54 +0000 (UTC) Subject: make force-tag gone References: <1220955240.24928.69.camel@cookie.hadess.net> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> <20080911184506.GA1486@redhat.com> <48C97287.8040402@poolshark.org> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> Message-ID: Toshio Kuratomi gmail.com> writes: > This specific implementation would be a bad thing. Instead of having a > nice, SCM abstract method of communicating to koji what to build from > (the tag) you'd be resorting to CVS specific knowledge. That whole trick is only needed with CVS. In all the newer SCMs (SVN and all the distributed stuff), you have a revision ID (a monotonically increasing number in the case of SVN, a checksum in the distributed systems) which you can trivially refer to. Only CVS needs a revision number per file, and that's exactly what the Entries file contains. All the envisioned replacement SCMs will only need a number (be it an incremental ID or a checksum), so it will be trivial to add support for those. In the case of SVN, you could also upload .svn/entries, which is the equivalent file, however only the first few lines (which contain the revision number and the directory's URL) are needed to recreate the revision. Another trivial SVN-based implementation would be to run "svn info >Entries" (which is a local operation and thus very fast). But only the revision ID is really needed, the URL is trivial to figure out and the rest of the svn info output is not needed to recreate the revision. I'm sure the situation is similar for the distributed systems and their checksum-based IDs. Kevin Kofler From kevin.kofler at chello.at Thu Sep 11 23:02:42 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 11 Sep 2008 23:02:42 +0000 (UTC) Subject: Plan for tomorrows (20080910) FESCO meeting References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> <48C7F0DE.7090402@gmail.com> <20080910161820.GB1535@amd.home.annexia.org> <48C807FB.1030400@gmail.com> <20080910185041.GA2878@amd.home.annexia.org> Message-ID: Richard W.M. Jones redhat.com> writes: > I'm not sure I understand the question, but: The native Fedora NSIS > doesn't have any plugins enabled. If you need functionality contained > in NSIS plugins then you have to run the Windows version under Wine > (or actually in Windows). This isn't as much of a problem as it > sounds since if Wine is installed then Windows executables "just work" > without you needing to do anything special. FYI, as the plugins are just Window$ DLLs and noarch data, it is technically possible to simply use the plugins from the Window$ binary ZIP. I have NSIS packages at http://repo.calcforge.org/fedora/ which do this (nsis is the stuff built from source, nsis-data is a noarch package with the copied binaries). I realize that doing this is against Fedora guidelines though. I just wanted to point out it is possible. Debian, on the other hand, has had success with building much of NSIS with a MinGW cross-compiler. You can take a look at their package. The README.Debian in the current Debian experimental package says only the System plugin still doesn't build (due to inline assembly, and there are attempts to fix that). You may need a fairly old MinGW GCC to get it to build without heavy patching though, at least last I checked NSIS used stuff like lvalue casts in their code, as M$VC doesn't complain about those. Debian also had a patch to support 64-bit builds (real ones, not -m32 as upstream NSIS used), which I used in my package too, but this appears to be finally fixed upstream in 2.39. Kevin Kofler From gnomeuser at gmail.com Thu Sep 11 23:04:23 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Fri, 12 Sep 2008 01:04:23 +0200 Subject: modesetting feature status In-Reply-To: <20080911195554.GC26684@yoda.jdub.homelinux.org> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221145599.11745.3.camel@aglarond.local> <1221152956.4345.17.camel@atropine.boston.devel.redhat.com> <1221155164.11745.13.camel@aglarond.local> <20080911195554.GC26684@yoda.jdub.homelinux.org> Message-ID: <1dedbbfc0809111604h6bca28c2k46427a732f786d54@mail.gmail.com> 2008/9/11 Josh Boyer > On Thu, Sep 11, 2008 at 01:46:04PM -0400, Jeremy Katz wrote: > >On Thu, 2008-09-11 at 13:09 -0400, Adam Jackson wrote: > >> On Thu, 2008-09-11 at 11:06 -0400, Jeremy Katz wrote: > >> > On Thu, 2008-09-11 at 17:18 +1000, Dave Airlie wrote: > >> > > For the beta we are only going to enable Radeon support for the r300 > to > >> > > r500 class of hardware, while we await upstream changes to the Intel > >> > > driver. > >> > > >> > ... we really shouldn't shove in major changes like this for a > >> > significant chunk of hardware post-beta. Putting it in the beta means > >> > that we get a relatively large chunk of testing done due to the > >> > visibility surrounding the beta announce. As well as having time to > fix > >> > large problems that are uncovered. Later milestones both a) lack the > >> > time for changes after them and b) the visibility. > >> > >> So are you saying: > >> > >> a) enable it for both, see what breaks > > > >I've been advocating us getting the pieces merged for a long time so > >that we could see what was broken rather than trying to wait for a > >mythical "perfection" that's been just another week or two out for on > >the order of months now. > > > >> b) remove both, because, screw it > > > >This is a part of the contingency plan. But removing for both seems a > >little extreme. > > > >There's also c) Just enable it for radeon. Intel users get pretty > > It's not working very well on radeon either. My laptop never gets a > display (i686), and it's hosed on ppc in general. Neither my trusty old r200 nor my shiny new r600 experience any issues booting in the default configuration, however there is no sign of acceleration so the X experience is so slow as to be practically useless. I trust the regression will go away by stable, I will help any way I am able to make it so (which frankly does not go beyond testing new code and reporting back). - David - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Thu Sep 11 23:09:24 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 11 Sep 2008 15:09:24 -0800 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> <48C7F0DE.7090402@gmail.com> <20080910161820.GB1535@amd.home.annexia.org> <48C807FB.1030400@gmail.com> <20080910185041.GA2878@amd.home.annexia.org> Message-ID: <604aa7910809111609h37882b82wcc044a8457be10a2@mail.gmail.com> On Thu, Sep 11, 2008 at 3:02 PM, Kevin Kofler wrote: > FYI, as the plugins are just Window$ DLLs and noarch data, it is technically > possible to simply use the plugins from the Window$ binary ZIP. I have NSIS > packages at http://repo.calcforge.org/fedora/ which do this (nsis is the stuff > built from source, nsis-data is a noarch package with the copied binaries). I > realize that doing this is against Fedora guidelines though. I just wanted to > point out it is possible. Just to clarify.... the nsis-data package is against the Fedora guidelines because it contains binary blobs not compiled from source? The nsis package you have however, as it stands.. would it pass Fedora guidelines? -jef From stickster at gmail.com Thu Sep 11 23:10:58 2008 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 11 Sep 2008 23:10:58 +0000 Subject: modesetting feature status In-Reply-To: <5f6f8c5f0809111209o1d28bae4p246d699f3520c40@mail.gmail.com> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221145599.11745.3.camel@aglarond.local> <1221152956.4345.17.camel@atropine.boston.devel.redhat.com> <1221155164.11745.13.camel@aglarond.local> <5f6f8c5f0809111209o1d28bae4p246d699f3520c40@mail.gmail.com> Message-ID: <1221174658.4936.46.camel@localhost.localdomain> On Thu, 2008-09-11 at 21:09 +0200, Joshua C. wrote: > 2008/9/11 Jeremy Katz : > > On Thu, 2008-09-11 at 13:09 -0400, Adam Jackson wrote: > >> On Thu, 2008-09-11 at 11:06 -0400, Jeremy Katz wrote: > >> > On Thu, 2008-09-11 at 17:18 +1000, Dave Airlie wrote: > >> > > For the beta we are only going to enable Radeon support for the r300 to > >> > > r500 class of hardware, while we await upstream changes to the Intel > >> > > driver. > >> > > >> > ... we really shouldn't shove in major changes like this for a > >> > significant chunk of hardware post-beta. Putting it in the beta means > >> > that we get a relatively large chunk of testing done due to the > >> > visibility surrounding the beta announce. As well as having time to fix > >> > large problems that are uncovered. Later milestones both a) lack the > >> > time for changes after them and b) the visibility. > >> > >> So are you saying: > >> > >> a) enable it for both, see what breaks > > > > I've been advocating us getting the pieces merged for a long time so > > that we could see what was broken rather than trying to wait for a > > mythical "perfection" that's been just another week or two out for on > > the order of months now. > > > >> b) remove both, because, screw it > > > > This is a part of the contingency plan. But removing for both seems a > > little extreme. > > > > There's also c) Just enable it for radeon. Intel users get pretty > > modesetting for F11. It's only six months away. Adding the Intel > > support post-beta just leaves us with way too little runway of testing > > on what's a significant amount of the hardware running Fedora. And one > > of the big reasons behind the six month release cycle is that if > > something is late to the party for release n, n+1 is not that far away. > > > > Jeremy > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > Is there a list of cards that work with this (already tested)? f10 is > just a month away and my rs485 still cannot function with this code. > It's an important feature and if it cannot work, then maybe the > contingency plan should be applied. By my calendar, F10 is a little over two months away... https://fedoraproject.org/wiki/Releases/10/Schedule ...though development freeze is only about six weeks from now. -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From airlied at redhat.com Thu Sep 11 23:11:44 2008 From: airlied at redhat.com (Dave Airlie) Date: Fri, 12 Sep 2008 09:11:44 +1000 Subject: modesetting feature status In-Reply-To: <1dedbbfc0809111604h6bca28c2k46427a732f786d54@mail.gmail.com> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221145599.11745.3.camel@aglarond.local> <1221152956.4345.17.camel@atropine.boston.devel.redhat.com> <1221155164.11745.13.camel@aglarond.local> <20080911195554.GC26684@yoda.jdub.homelinux.org> <1dedbbfc0809111604h6bca28c2k46427a732f786d54@mail.gmail.com> Message-ID: <1221174704.30676.8.camel@optimus> On Fri, 2008-09-12 at 01:04 +0200, David Nielsen wrote: > > > 2008/9/11 Josh Boyer > On Thu, Sep 11, 2008 at 01:46:04PM -0400, Jeremy Katz wrote: > >On Thu, 2008-09-11 at 13:09 -0400, Adam Jackson wrote: > >> On Thu, 2008-09-11 at 11:06 -0400, Jeremy Katz wrote: > >> > On Thu, 2008-09-11 at 17:18 +1000, Dave Airlie wrote: > >> > > For the beta we are only going to enable Radeon support > for the r300 to > >> > > r500 class of hardware, while we await upstream changes > to the Intel > >> > > driver. > >> > > >> > ... we really shouldn't shove in major changes like this > for a > >> > significant chunk of hardware post-beta. Putting it in > the beta means > >> > that we get a relatively large chunk of testing done due > to the > >> > visibility surrounding the beta announce. As well as > having time to fix > >> > large problems that are uncovered. Later milestones both > a) lack the > >> > time for changes after them and b) the visibility. > >> > >> So are you saying: > >> > >> a) enable it for both, see what breaks > > > >I've been advocating us getting the pieces merged for a long > time so > >that we could see what was broken rather than trying to wait > for a > >mythical "perfection" that's been just another week or two > out for on > >the order of months now. > > > >> b) remove both, because, screw it > > > >This is a part of the contingency plan. But removing for > both seems a > >little extreme. > > > >There's also c) Just enable it for radeon. Intel users get > pretty > > > It's not working very well on radeon either. My laptop never > gets a > display (i686), and it's hosed on ppc in general. > > Neither my trusty old r200 nor my shiny new r600 experience any issues > booting in the default configuration, however there is no sign of > acceleration so the X experience is so slow as to be practically > useless. I trust the regression will go away by stable, I will help > any way I am able to make it so (which frankly does not go beyond > testing new code and reporting back). > Neither of these should have changed much if at all so they should just be as they were in F9. Actually maybe r200 is now using EXA by default.. but r600 has no acceleration support to speak off yet. Dave. From airlied at redhat.com Thu Sep 11 23:16:20 2008 From: airlied at redhat.com (Dave Airlie) Date: Fri, 12 Sep 2008 09:16:20 +1000 Subject: modesetting feature status In-Reply-To: <5f6f8c5f0809111209o1d28bae4p246d699f3520c40@mail.gmail.com> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221145599.11745.3.camel@aglarond.local> <1221152956.4345.17.camel@atropine.boston.devel.redhat.com> <1221155164.11745.13.camel@aglarond.local> <5f6f8c5f0809111209o1d28bae4p246d699f3520c40@mail.gmail.com> Message-ID: <1221174980.30676.10.camel@optimus> On Thu, 2008-09-11 at 21:09 +0200, Joshua C. wrote: > 2008/9/11 Jeremy Katz : > > On Thu, 2008-09-11 at 13:09 -0400, Adam Jackson wrote: > >> On Thu, 2008-09-11 at 11:06 -0400, Jeremy Katz wrote: > >> > On Thu, 2008-09-11 at 17:18 +1000, Dave Airlie wrote: > >> > > For the beta we are only going to enable Radeon support for the r300 to > >> > > r500 class of hardware, while we await upstream changes to the Intel > >> > > driver. > >> > > >> > ... we really shouldn't shove in major changes like this for a > >> > significant chunk of hardware post-beta. Putting it in the beta means > >> > that we get a relatively large chunk of testing done due to the > >> > visibility surrounding the beta announce. As well as having time to fix > >> > large problems that are uncovered. Later milestones both a) lack the > >> > time for changes after them and b) the visibility. > >> > >> So are you saying: > >> > >> a) enable it for both, see what breaks > > > > I've been advocating us getting the pieces merged for a long time so > > that we could see what was broken rather than trying to wait for a > > mythical "perfection" that's been just another week or two out for on > > the order of months now. > > > >> b) remove both, because, screw it > > > > This is a part of the contingency plan. But removing for both seems a > > little extreme. > > > > There's also c) Just enable it for radeon. Intel users get pretty > > modesetting for F11. It's only six months away. Adding the Intel > > support post-beta just leaves us with way too little runway of testing > > on what's a significant amount of the hardware running Fedora. And one > > of the big reasons behind the six month release cycle is that if > > something is late to the party for release n, n+1 is not that far away. > > > > Jeremy > > > > -- > > fedora-devel-list mailing list > > fedora-devel-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-devel-list > > > > Is there a list of cards that work with this (already tested)? f10 is > just a month away and my rs485 still cannot function with this code. > It's an important feature and if it cannot work, then maybe the > contingency plan should be applied. > bug number? what kernel did you last test with? stop scare mongering its a beta release, if it still doesn't work at devel freeze I'll blacklist all the broken machines. Dave. From kevin.kofler at chello.at Thu Sep 11 23:29:06 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 11 Sep 2008 23:29:06 +0000 (UTC) Subject: Plan for tomorrows (20080910) FESCO meeting References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> <48C7F0DE.7090402@gmail.com> <20080910161820.GB1535@amd.home.annexia.org> <48C807FB.1030400@gmail.com> <20080910185041.GA2878@amd.home.annexia.org> <604aa7910809111609h37882b82wcc044a8457be10a2@mail.gmail.com> Message-ID: Jeff Spaleta gmail.com> writes: > Just to clarify.... the nsis-data package is against the Fedora > guidelines because it contains binary blobs not compiled from source? Right. > The nsis package you have however, as it stands.. would it pass Fedora > guidelines? Not really because it doesn't actually work without nsis-data, at least the installer stubs are needed. But with the Debian approach (BR the MinGW toolchain and build it completely from source that way), we could have a fully functional (or almost) native NSIS (well, as native as NSIS is, it's a cross-tool just like MinGW, the generated installers are Window$-only), even with plugins, and completely built from source. Kevin Kofler From konrad at tylerc.org Thu Sep 11 23:47:46 2008 From: konrad at tylerc.org (Conrad Meyer) Date: Thu, 11 Sep 2008 16:47:46 -0700 Subject: Possible gcc issue In-Reply-To: <0ML31I-1Kdt2h29yK-0006cn@mrelayeu.kundenserver.de> References: <48C94597.2000705@herr-schmitt.de> <48C96B27.9020700@redhat.com> <0ML31I-1Kdt2h29yK-0006cn@mrelayeu.kundenserver.de> Message-ID: <200809111647.46588.konrad@tylerc.org> Quoth Jochen Schmitt: > On Thu, 11 Sep 2008 12:01:59 -0700, you wrote: > > >Not a gcc bug and no bug in glibc. This is inline asm which requires > >registers which for some reason are not available. > > > >Compile this file with __NO_STRING_INLINES defined. > > Thank you for your hint, I'm now able to build the package on > koji. > > But I have the following question: Why does this issue occurs > only on rawhide in the i386-architecture. On F-9 or on other > architectures this issue doesn't occurs. > > Best Regards: > > Jochen Schmitt Other architectures are less register starved. -- Conrad Meyer From jspaleta at gmail.com Thu Sep 11 23:48:59 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 11 Sep 2008 15:48:59 -0800 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: References: <1220977399.4252.22.camel@kennedy> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> <48C7F0DE.7090402@gmail.com> <20080910161820.GB1535@amd.home.annexia.org> <48C807FB.1030400@gmail.com> <20080910185041.GA2878@amd.home.annexia.org> <604aa7910809111609h37882b82wcc044a8457be10a2@mail.gmail.com> Message-ID: <604aa7910809111648l67c2e303x9778f79f9e5ef223@mail.gmail.com> On Thu, Sep 11, 2008 at 3:29 PM, Kevin Kofler wrote: > But with the Debian approach (BR the MinGW toolchain and build it completely > from source that way), we could have a fully functional (or almost) native NSIS > (well, as native as NSIS is, it's a cross-tool just like MinGW, the generated > installers are Window$-only), even with plugins, and completely built from > source. Using MinGW as a BR isn't really an issue. If we did it Debian's way the resulting nsis tool itself would run natively under Fedora... like our MinGW executable does? is there a reason why should not prefer to have a native nsis executable? It seems to me that we should prefer native executables when its possible, and treat anything non-native as exceptions which will require some oversight. -jef From martin.langhoff at gmail.com Thu Sep 11 23:59:19 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Fri, 12 Sep 2008 11:59:19 +1200 Subject: PostgreSQL mgmt on Fedora: pg_cluster-like tools? Message-ID: <46a038f90809111659o41e98cc5r3e256c890669c5ec@mail.gmail.com> I'm getting familiar with the Fedora tools around Pg, and wondering whether there is anything similar to the pg_cluster stuff that's available in Debian/Ubuntu. So far I've looked at the postgresql-* packages and rhdb-utils -- nothing I've found seems to fill that space. Is there a package I am missing, or a workflow that achieves the same goals? My goals: - Run Pg with custom options - I see the sysconfig/pgsql/$NAME trick in the init script, handy! - Major Pg upgrades will have to run 100% unattended, with a sane failover, so: install the new version of Pg, attempt a pg_dump|pg_restore data migration and only switch over if it was successful. the pg_cluster scripts and the wrappers around psql and friends simplify a lot of error-prone stuff when working in these upgrade scenarios. How do I handle it in Fedora-land? cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From tgl at redhat.com Fri Sep 12 00:14:20 2008 From: tgl at redhat.com (Tom Lane) Date: Thu, 11 Sep 2008 20:14:20 -0400 Subject: PostgreSQL mgmt on Fedora: pg_cluster-like tools? In-Reply-To: <46a038f90809111659o41e98cc5r3e256c890669c5ec@mail.gmail.com> References: <46a038f90809111659o41e98cc5r3e256c890669c5ec@mail.gmail.com> Message-ID: <16999.1221178460@sss.pgh.pa.us> "Martin Langhoff" writes: > I'm getting familiar with the Fedora tools around Pg, and wondering > whether there is anything similar to the pg_cluster stuff that's > available in Debian/Ubuntu. Not really. I think Devrim Gunduz has been working on a similar idea for the RPM distributions, but no results yet. Obviously the lack of a convenient upgrade path is a real PITA, so I'm in favor of solving it somehow, but how to do it without breaking a lot of stuff? (It should be noted that upstream is working on in-place upgrade; but I wouldn't exactly hold my breath on that happening for PG 8.4, and it does nothing for existing releases anyway.) regards, tom lane From martin.langhoff at gmail.com Fri Sep 12 00:24:50 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Fri, 12 Sep 2008 12:24:50 +1200 Subject: PostgreSQL mgmt on Fedora: pg_cluster-like tools? In-Reply-To: <16999.1221178460@sss.pgh.pa.us> References: <46a038f90809111659o41e98cc5r3e256c890669c5ec@mail.gmail.com> <16999.1221178460@sss.pgh.pa.us> Message-ID: <46a038f90809111724w4c079ceew8ca53f883746d0f4@mail.gmail.com> 2008/9/12 Tom Lane : > Not really. I think Devrim Gunduz has been working on a similar idea > for the RPM distributions, but no results yet. Obviously the lack of > a convenient upgrade path is a real PITA, so I'm in favor of solving > it somehow, but how to do it without breaking a lot of stuff? Any reason not to use the debianistas code? It does cause some subtle breakage in some cases, but it broke first on debian/ubuntu and the fallout is over. By which I mean: app developers already cursed and added fixes/workarounds/documentation to deal with it; that road is paved. Doing it differently means breaking in new and original ways, and a new round of cursing... > (It should be noted that upstream is working on in-place upgrade; > but I wouldn't exactly hold my breath on that happening for PG 8.4, > and it does nothing for existing releases anyway.) Interesting to hear. That'll be good news when it happens. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From kevin.kofler at chello.at Fri Sep 12 00:36:42 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 12 Sep 2008 00:36:42 +0000 (UTC) Subject: Beware: External repos can break key transition References: <1221158197.6431.24.camel@localhost.localdomain> <604aa7910809111151s330ea17cr5c5d08d6aefa5862@mail.gmail.com> Message-ID: Jeff Spaleta gmail.com> writes: > Seems okay for me. I just installed xine-lib-extras-nonfree on my > 32bit system. Perhaps this a transitory issue due to one of the > mirrors not being fully synced? Not really. Everyone with xine-lib-extras-nonfree installed who didn't migrate to the new key yet is going to be hit by it, as the matching xine-lib only shows up once the newkey repo is enabled, and the yum update which should do that will fail due to broken dependencies (chicken&egg at work, the "chicken" is working "yum update", the "egg" is the new fedora-release package). Only a selective update (with --skip-broken or --exclude, or by manually listing what to update - note that for F9, a new PackageKit is also needed, so please DON'T just "yum update fedora-release") can bring the user out of this mess. The easiest way out for a new user is to use the PackageKit GUI, click on "Review updates" and uncheck the xine-lib-extras-nonfree update, then apply. All the folks who claim there is no problem aren't affected because they updated immediately after the new fedora-release went out, before the xine-lib-extras-nonfree update happened in Livna. (Congratulations, you managed to update within a couple hours of the announcement! ;-) ) Kevin Kofler From tgl at redhat.com Fri Sep 12 00:38:04 2008 From: tgl at redhat.com (Tom Lane) Date: Thu, 11 Sep 2008 20:38:04 -0400 Subject: PostgreSQL mgmt on Fedora: pg_cluster-like tools? In-Reply-To: <46a038f90809111724w4c079ceew8ca53f883746d0f4@mail.gmail.com> References: <46a038f90809111659o41e98cc5r3e256c890669c5ec@mail.gmail.com> <16999.1221178460@sss.pgh.pa.us> <46a038f90809111724w4c079ceew8ca53f883746d0f4@mail.gmail.com> Message-ID: <17430.1221179884@sss.pgh.pa.us> "Martin Langhoff" writes: > 2008/9/12 Tom Lane : >> ... but how to do it without breaking a lot of stuff? > Any reason not to use the debianistas code? It does cause some subtle > breakage in some cases, but it broke first on debian/ubuntu and the > fallout is over. By which I mean: app developers already cursed and > added fixes/workarounds/documentation to deal with it; that road is > paved. Hm, well, maybe I haven't been paying enough attention. I remember the cursing ;-) but not whether they'd gotten it sorted adequately. Has anyone looked at whether their solution would drop into Fedora? regards, tom lane From ivazqueznet at gmail.com Fri Sep 12 01:20:18 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 11 Sep 2008 21:20:18 -0400 Subject: Feature Proposal: Use cases database In-Reply-To: <16de708d0809111043y6ab64021p9ed49ceba2422fe4@mail.gmail.com> References: <1220991029.3782.47.camel@choeger6> <1221059648.17299.103.camel@hughsie-work> <1221062578.21306.13.camel@rousalka.okg> <1221064863.17299.134.camel@hughsie-work> <5cb581610364a94649b91d5bc6e50928.squirrel@rousalka.dyndns.org> <1221129641.22654.24.camel@hughsie-work> <1221141890.22654.75.camel@hughsie-work> <1221153724.22654.86.camel@hughsie-work> <16de708d0809111043y6ab64021p9ed49ceba2422fe4@mail.gmail.com> Message-ID: <1221182418.27183.88.camel@ignacio.lan> On Thu, 2008-09-11 at 12:43 -0500, Arthur Pemberton wrote: > On Thu, Sep 11, 2008 at 12:22 PM, Richard Hughes wrote: > > Cost of me spending 5 minutes setting up clipart for my mum: > > = ?20 / hour > > = ?1.67 > > I have to say this took me by suprise Time is money, regardless of whether or not you're actually charging. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From lesmikesell at gmail.com Fri Sep 12 01:55:24 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 11 Sep 2008 20:55:24 -0500 Subject: Feature Proposal: Use cases database In-Reply-To: <15e53e180809111439r4c66178ax1440f9940544fd79@mail.gmail.com> References: <1220991029.3782.47.camel@choeger6> <48C767E7.9040801@gmail.com> <1221059648.17299.103.camel@hughsie-work> <1221062578.21306.13.camel@rousalka.okg> <1221064863.17299.134.camel@hughsie-work> <5cb581610364a94649b91d5bc6e50928.squirrel@rousalka.dyndns.org> <1221129641.22654.24.camel@hughsie-work> <1221141890.22654.75.camel@hughsie-work> <48C95C46.1060904@gmail.com> <15e53e180809111439r4c66178ax1440f9940544fd79@mail.gmail.com> Message-ID: <48C9CC0C.4090506@gmail.com> Richard Hughes wrote: > >> Can you describe a whole machine with a catalog file? > > I guess you could, but they are not really designed for that. Well, since we are talking about use cases here, I'll describe what I think a package manager should do. I'd like it to convert between a text description of the packages and the packages themselves in the general sense and in either direction. That is, at any point you could ask it for a description of the packages you have and get a file that you could copy to a different machine where you could use it to install exactly the same set there. Or, you might diff the file against another one produced at a different time or on a different machine to see what packages were different. Or, you might feed it to a version control system, perhaps with similar machines as branches so that you could easily track any combination of changes over time or changes between machines. It should, of course do subset groupings as well as the whole package list. Being able to revert backwards would be a big plus as would an option to track files that are modified after installation from a package. -- Les Mikesell lesmikesell at gmail.com From skvidal at fedoraproject.org Fri Sep 12 02:20:41 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Thu, 11 Sep 2008 22:20:41 -0400 Subject: recover from broken yum transaction In-Reply-To: <46a038f90809111454n79c9aaf3k81445e7f527a6069@mail.gmail.com> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <46a038f90809102242w31869559mc6f0b22a291f52b9@mail.gmail.com> <1221145265.987.183.camel@rosebud> <46a038f90809111454n79c9aaf3k81445e7f527a6069@mail.gmail.com> Message-ID: <1221186041.987.239.camel@rosebud> On Fri, 2008-09-12 at 09:54 +1200, Martin Langhoff wrote: > That is not very useful for us. I don't worry so much about the > machine being killed in the 'download stuff' part, bit AFAIK that's > not part of the 'transaction'. When yum-complete-transaction is > called, I am expecting it to work with the RPMs it has, and ensure > anything it was trying to do gets done... The transaction file is written out after the pkgs are downloaded, so the transaction should complete just fine if the system hasn't changed state dramatically. > WRT networking, in places like Peru my rule of thumb is that 50% of > the servers will _not_ have internet. Package installations / upgrades > are very likely to happen by sending out USB keys with a bunch of > RPMs, and a GPG-signed script that triggers the yum process. Then that won't be an issue at all, you'll have a local repo on the usb key which yum can access. It won't even need -C b/c it will have connectivity to the local file:/// based repo. > yum supports -C... can yum-complete-transaction support -C as well? it already does. - try it: yum-complete-transaction --help > >> - Is there an easy way to check for pending transactions? > > > > yum-complete-transaction checks for them itself > > Yes, though it's useful to be able to check that for logging/reporting... You can check with one call: import yum.misc yum.misc.find_unfinished_transactions() if it returns a non-empty list then you have unfinished transactions. > >> - Does it have useful exit codes indicating whether it's done anything? > > > > If the results codes are not good enough we can fix that easily enough. > > I am asking because checking the manpage and reading the source did > not give me any hints as to exit codes. Neither does 'man yum' talk > about exit codes except for the "check-update" command. at this point yum should be returning 0 for any non-erroring exit and 1 for any error condition. Including rpm scriptlet failures. That should also be true for yum-complete-transaction -sv From s-t-rhbugzilla at wwwdotorg.org Fri Sep 12 02:32:01 2008 From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren) Date: Thu, 11 Sep 2008 20:32:01 -0600 Subject: modesetting feature status In-Reply-To: <1221152902.4345.16.camel@atropine.boston.devel.redhat.com> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221149934.7867.TMDA@tmda.severn.wwwdotorg.org> <1221152902.4345.16.camel@atropine.boston.devel.redhat.com> Message-ID: <1221186711.22009.TMDA@tmda.severn.wwwdotorg.org> Adam Jackson wrote: > On Thu, 2008-09-11 at 10:18 -0600, Stephen Warren wrote: >> On Thu, September 11, 2008 1:18 am, Dave Airlie wrote: >>> Hi, >>> >>> So one of the features we've been trying to land for F10 that is a major >>> change in how we deal with graphics hardware in the Linux world. >>> >>> https://fedoraproject.org/wiki/Features/KernelModesetting >> What will happen on unsupported hardware (NVIDIA, unsupported ATI/Intel >> chipsets)? Will the system simply fall back to the existing F9-style >> startup sequence. > > They'll get text boot, yes. Oh, that's not an F9-style boot. Are you saying that systems where kms doesn't work can't get any form of graphical boot at all? From jspaleta at gmail.com Fri Sep 12 02:47:41 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 11 Sep 2008 18:47:41 -0800 Subject: Beware: External repos can break key transition In-Reply-To: References: <1221158197.6431.24.camel@localhost.localdomain> <604aa7910809111151s330ea17cr5c5d08d6aefa5862@mail.gmail.com> Message-ID: <604aa7910809111947o10b6ee51vb5e8efc74471f517@mail.gmail.com> On Thu, Sep 11, 2008 at 4:36 PM, Kevin Kofler wrote: > Not really. Everyone with xine-lib-extras-nonfree installed who didn't migrate > to the new key yet is going to be hit by it, as the matching xine-lib only > shows up once the newkey repo is enabled, and the yum update which should do > that will fail due to broken dependencies (chicken&egg at work, the "chicken" > is working "yum update", the "egg" is the new fedora-release package). Ah. -jef From martin.langhoff at gmail.com Fri Sep 12 02:50:26 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Fri, 12 Sep 2008 14:50:26 +1200 Subject: PostgreSQL mgmt on Fedora: pg_cluster-like tools? In-Reply-To: <17430.1221179884@sss.pgh.pa.us> References: <46a038f90809111659o41e98cc5r3e256c890669c5ec@mail.gmail.com> <16999.1221178460@sss.pgh.pa.us> <46a038f90809111724w4c079ceew8ca53f883746d0f4@mail.gmail.com> <17430.1221179884@sss.pgh.pa.us> Message-ID: <46a038f90809111950q61ff578m3fb77f8b3a874cf3@mail.gmail.com> On Fri, Sep 12, 2008 at 12:38 PM, Tom Lane wrote: > Hm, well, maybe I haven't been paying enough attention. I remember the > cursing ;-) but not whether they'd gotten it sorted adequately. Cursing? When!? :-) -- anyway, from the "don't do this, dummy" department, a tiny patch, titled... initdb fails if the logfile is set to be inside the data directory. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -------------- next part -------------- A non-text attachment was scrubbed... Name: pginit.patch Type: application/octet-stream Size: 779 bytes Desc: not available URL: From rc040203 at freenet.de Fri Sep 12 04:22:56 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 12 Sep 2008 06:22:56 +0200 Subject: make force-tag gone In-Reply-To: <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> <20080911184506.GA1486@redhat.com> <48C97287.8040402@poolshark.org> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> Message-ID: <1221193376.18327.308.camel@beck.corsepiu.local> On Thu, 2008-09-11 at 15:51 -0500, Jeffrey Ollie wrote: > On Thu, Sep 11, 2008 at 3:35 PM, Kevin Kofler wrote: > > Josh Boyer gmail.com> writes: > >> Yes. It was decided to leave the removal, and to also remove TAG_OPTS=-F. > > > > Yet another abuse of power by FESCo. Why can't FESCo listen to the many > > developers who objected to the removal here, including developers like Dave > > Jones and Rex Dieter who are experienced Fedora packagers and do much of the > > actual packaging work in Fedora (Dave Jones is the primary maintainer of the > > kernel, Rex Dieter is #4 in number of builds per packager)? Why can't the > > decision be left to the people who are actually affected by the change, i.e. > > the packagers? FESCo is supposed to represent the interests of the packagers > > (that's what they're elected for), not their own, too bad they actually do the > > latter. > > Basically because the only argument for keeping "make force-tag" > wasn't a technical one. There's a need to ensure that a tag points to > the exact source that was used to build a package. ... iff a built run succeeds and the package has been released". > Disallowing > force-tag is the easiest way to do that. I do not agree with this. It's a naive approach rending contributing to Fedora furtherly difficult. From fedora at leemhuis.info Fri Sep 12 04:49:11 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 12 Sep 2008 06:49:11 +0200 Subject: Beware: External repos can break key transition In-Reply-To: References: <1221158197.6431.24.camel@localhost.localdomain> <604aa7910809111151s330ea17cr5c5d08d6aefa5862@mail.gmail.com> Message-ID: <48C9F4C7.9080301@leemhuis.info> On 12.09.2008 02:36, Kevin Kofler wrote: > Jeff Spaleta gmail.com> writes: >> Seems okay for me. I just installed xine-lib-extras-nonfree on my >> 32bit system. Perhaps this a transitory issue due to one of the >> mirrors not being fully synced? > Not really. That's wrong (sorry), as the same problem shows up each time a new xine-lib/xine-lib-extras-nonfree packages hit the repo. The exact same problem also happens with other packages with close inter-repo deps -- kernel module packages for example, but also qmmp/qmmp-plugins-freeworld, audacious/audacious-plugins-nonfree and a few others. For details see https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html This > Everyone with xine-lib-extras-nonfree installed who didn't migrate > to the new key yet is going to be hit by it, as the matching xine-lib only > shows up once the newkey repo is enabled, and the yum update which should do > that will fail due to broken dependencies (chicken&egg at work, the "chicken" > is working "yum update", the "egg" is the new fedora-release package). only makes it a bit more painful this round ;-) > [...] CU knurd From mathstuf at gmail.com Fri Sep 12 05:11:59 2008 From: mathstuf at gmail.com (Ben Boeckel) Date: Fri, 12 Sep 2008 01:11:59 -0400 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: <604aa7910809111648l67c2e303x9778f79f9e5ef223@mail.gmail.com> References: <1220977399.4252.22.camel@kennedy> <604aa7910809111648l67c2e303x9778f79f9e5ef223@mail.gmail.com> Message-ID: <200809120111.59541.MathStuf@gmail.com> On Thursday 11 September 2008 07:48:59 pm Jeff Spaleta wrote: > Using MinGW as a BR isn't really an issue. If we did it Debian's way > the resulting nsis tool itself would run natively under Fedora... like > our MinGW executable does? > > is there a reason why should not prefer to have a native nsis executable? > > It seems to me that we should prefer native executables when its > possible, and treat anything non-native as exceptions which will > require some oversight. > > -jef FWIW, I used Kevin's nsis package recently to build an installer. Works fine, though I had to roll my own dep-solver (I could package it up for other to use; it is just a NSIS header or two). Testing's a pain, but that's to be expected of any cross-target toolchain. --Ben From devrim at gunduz.org Fri Sep 12 05:16:54 2008 From: devrim at gunduz.org (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Fri, 12 Sep 2008 08:16:54 +0300 Subject: PostgreSQL mgmt on Fedora: pg_cluster-like tools? In-Reply-To: <46a038f90809111659o41e98cc5r3e256c890669c5ec@mail.gmail.com> References: <46a038f90809111659o41e98cc5r3e256c890669c5ec@mail.gmail.com> Message-ID: <1221196614.15987.52.camel@laptop.gunduz.org> On Fri, 2008-09-12 at 11:59 +1200, Martin Langhoff wrote: > - Major Pg upgrades will have to run 100% unattended, with a sane > failover, so: install the new version of Pg, attempt a > pg_dump|pg_restore data migration and only switch over if it was > successful. I am *very* against this one. It is not packager's job to run dump/reload: * You may never be sure that it will work. We had this issue in 8.3 for example. * Upstream never ever gives such a guarantee that all apps will work on every PostgreSQL version. For example, some casts were removed in 8.3. So dumping/restoring should be a DBA work. So "switch over if it was successful" is really a bad idea, and *will* break things. * RPMs are *not* allowed to do interactive job, per guidelines. Period. Regards, -- Devrim G?ND?Z, RHCE devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From martin.langhoff at gmail.com Fri Sep 12 05:28:33 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Fri, 12 Sep 2008 17:28:33 +1200 Subject: PostgreSQL mgmt on Fedora: pg_cluster-like tools? In-Reply-To: <1221196614.15987.52.camel@laptop.gunduz.org> References: <46a038f90809111659o41e98cc5r3e256c890669c5ec@mail.gmail.com> <1221196614.15987.52.camel@laptop.gunduz.org> Message-ID: <46a038f90809112228s172abc4cy1c05b7d494a91f67@mail.gmail.com> 2008/9/12 Devrim G?ND?Z : > I am *very* against this one. It is not packager's job to run > dump/reload: I agree with you in a normal rpm package. I am working to some very special requirements :-) > * You may never be sure that it will work. We had this issue in 8.3 for > example. Yes, I've overseen many 7.2/7.3/7.4/8.0/8.1/8.2 migrations and understand the pitfalls fairly well. > * Upstream never ever gives such a guarantee that all apps will work on > every PostgreSQL version. For example, some casts were removed in 8.3. Having been once the maintainer of the Pg compat layer in Moodle, I also have first-hand experience with this. When the casts removal was mentioned in pg-devel, who was there asking about backwards compat? ;-) > So dumping/restoring should be a DBA work. So "switch over if it was > successful" is really a bad idea, and *will* break things. We'll have ~5K school servers in rural schools just in Peru, a team of perhaps 10 sysadmins for them, most of the servers disconnected. OTOH, we know what apps talk to Pg, and we'll have tested them thoroughly. The failures could come from data that breaks during migration - so if an 8.3 to 8.4 migration fails to complete we keep running on Pg 8.3, and write a log. (This is assuming that 8.4 has improvements worth the migration risks. We'll probably defer until a version of Pg has significant benefits to actually do this...) quite a challenge - :-) m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From devrim at gunduz.org Fri Sep 12 05:47:26 2008 From: devrim at gunduz.org (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Fri, 12 Sep 2008 08:47:26 +0300 Subject: PostgreSQL mgmt on Fedora: pg_cluster-like tools? In-Reply-To: <46a038f90809112228s172abc4cy1c05b7d494a91f67@mail.gmail.com> References: <46a038f90809111659o41e98cc5r3e256c890669c5ec@mail.gmail.com> <1221196614.15987.52.camel@laptop.gunduz.org> <46a038f90809112228s172abc4cy1c05b7d494a91f67@mail.gmail.com> Message-ID: <1221198446.15987.64.camel@laptop.gunduz.org> On Fri, 2008-09-12 at 17:28 +1200, Martin Langhoff wrote: > OTOH, we know what apps talk to Pg, and we'll have tested them > thoroughly. The failures could come from data that breaks during > migration - so if an 8.3 to 8.4 migration fails to complete we keep > running on Pg 8.3, and write a log. So to which directory do you want us to get backup? What if it is filled in the middle of dumping? We have some customers that has hundreds GB of data -- can you imagine how long will the dump take? During the dump, we have do shutdown (actually don't allow anyone else than localhost/Unix domain sockets) PostgreSQL in order to be able to migrate correctly. It will be really painful. PostgreSQL project has Slony-I to be used in such migrations (almost) without downtime. So, IMHO what Fedora should do is to be able to install many versions in parallel, and leave the rest of DBA work to the users. -- Devrim G?ND?Z, RHCE devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From lesmikesell at gmail.com Fri Sep 12 06:04:25 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 12 Sep 2008 01:04:25 -0500 Subject: PostgreSQL mgmt on Fedora: pg_cluster-like tools? In-Reply-To: <1221198446.15987.64.camel@laptop.gunduz.org> References: <46a038f90809111659o41e98cc5r3e256c890669c5ec@mail.gmail.com> <1221196614.15987.52.camel@laptop.gunduz.org> <46a038f90809112228s172abc4cy1c05b7d494a91f67@mail.gmail.com> <1221198446.15987.64.camel@laptop.gunduz.org> Message-ID: <48CA0669.8090603@gmail.com> Devrim G?ND?Z wrote: > On Fri, 2008-09-12 at 17:28 +1200, Martin Langhoff wrote: >> OTOH, we know what apps talk to Pg, and we'll have tested them >> thoroughly. The failures could come from data that breaks during >> migration - so if an 8.3 to 8.4 migration fails to complete we keep >> running on Pg 8.3, and write a log. > > So to which directory do you want us to get backup? What if it is filled > in the middle of dumping? We have some customers that has hundreds GB of > data -- can you imagine how long will the dump take? During the dump, we > have do shutdown (actually don't allow anyone else than localhost/Unix > domain sockets) PostgreSQL in order to be able to migrate correctly. It > will be really painful. PostgreSQL project has Slony-I to be used in > such migrations (almost) without downtime. > > So, IMHO what Fedora should do is to be able to install many versions > in parallel, and leave the rest of DBA work to the users. I agree that the package manager should have the ability to install multiple versions of things - and not just in this case. But, what/who should determine which executables/libraries go in the default path? -- Les Mikesell lesmikesell at gmail.com From devrim at gunduz.org Fri Sep 12 06:10:05 2008 From: devrim at gunduz.org (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Fri, 12 Sep 2008 09:10:05 +0300 Subject: PostgreSQL mgmt on Fedora: pg_cluster-like tools? In-Reply-To: <48CA0669.8090603@gmail.com> References: <46a038f90809111659o41e98cc5r3e256c890669c5ec@mail.gmail.com> <1221196614.15987.52.camel@laptop.gunduz.org> <46a038f90809112228s172abc4cy1c05b7d494a91f67@mail.gmail.com> <1221198446.15987.64.camel@laptop.gunduz.org> <48CA0669.8090603@gmail.com> Message-ID: <1221199805.15987.83.camel@laptop.gunduz.org> Hi, On Fri, 2008-09-12 at 01:04 -0500, Les Mikesell wrote: > I agree that the package manager should have the ability to install > multiple versions of things - and not just in this case. But, > what/who should determine which executables/libraries go in the > default path? rpm -ivh postgresql-set-default-8.3-1.noarch.f9.rpm :) This will symlink executables and libraries to default path and leave the rest outside the path. How does it sound? Regards, -- Devrim G?ND?Z, RHCE devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Fri Sep 12 06:21:22 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 12 Sep 2008 11:51:22 +0530 Subject: PostgreSQL mgmt on Fedora: pg_cluster-like tools? In-Reply-To: <1221199805.15987.83.camel@laptop.gunduz.org> References: <46a038f90809111659o41e98cc5r3e256c890669c5ec@mail.gmail.com> <1221196614.15987.52.camel@laptop.gunduz.org> <46a038f90809112228s172abc4cy1c05b7d494a91f67@mail.gmail.com> <1221198446.15987.64.camel@laptop.gunduz.org> <48CA0669.8090603@gmail.com> <1221199805.15987.83.camel@laptop.gunduz.org> Message-ID: <48CA0A62.1070507@fedoraproject.org> Devrim G?ND?Z wrote: > Hi, > > On Fri, 2008-09-12 at 01:04 -0500, Les Mikesell wrote: >> I agree that the package manager should have the ability to install >> multiple versions of things - and not just in this case. Packaging, not a package manager decides that. RPM and yum can install parallel versions just fine and do that for dozens of packages in the repository. But, >> what/who should determine which executables/libraries go in the >> default path? > > rpm -ivh postgresql-set-default-8.3-1.noarch.f9.rpm > > :) > > This will symlink executables and libraries to default path and leave > the rest outside the path. > > How does it sound? Sounds like duplicating what is available as part of alternatives package. Rahul From devrim at gunduz.org Fri Sep 12 06:38:40 2008 From: devrim at gunduz.org (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Fri, 12 Sep 2008 09:38:40 +0300 Subject: PostgreSQL mgmt on Fedora: pg_cluster-like tools? In-Reply-To: <48CA0A62.1070507@fedoraproject.org> References: <46a038f90809111659o41e98cc5r3e256c890669c5ec@mail.gmail.com> <1221196614.15987.52.camel@laptop.gunduz.org> <46a038f90809112228s172abc4cy1c05b7d494a91f67@mail.gmail.com> <1221198446.15987.64.camel@laptop.gunduz.org> <48CA0669.8090603@gmail.com> <1221199805.15987.83.camel@laptop.gunduz.org> <48CA0A62.1070507@fedoraproject.org> Message-ID: <1221201520.15987.85.camel@laptop.gunduz.org> On Fri, 2008-09-12 at 11:51 +0530, Rahul Sundaram wrote: > Sounds like duplicating what is available as part of alternatives > package. Hmm. -- Devrim G?ND?Z, RHCE devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kraxel at redhat.com Fri Sep 12 07:14:25 2008 From: kraxel at redhat.com (Gerd Hoffmann) Date: Fri, 12 Sep 2008 09:14:25 +0200 Subject: make force-tag gone In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> <20080911184506.GA1486@redhat.com> <48C97287.8040402@poolshark.org> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> Message-ID: <48CA16D1.5070409@redhat.com> Hi, > Only CVS needs a revision number per file, and that's > exactly what the Entries file contains. Hmm, wouldn't checkout by date do the trick for cvs? cheers, Gerd From harald at redhat.com Fri Sep 12 08:06:36 2008 From: harald at redhat.com (Harald Hoyer) Date: Fri, 12 Sep 2008 10:06:36 +0200 Subject: Beware: External repos can break key transition In-Reply-To: <48C9721A.6070603@leemhuis.info> References: <1221158197.6431.24.camel@localhost.localdomain> <48C9721A.6070603@leemhuis.info> Message-ID: Thorsten Leemhuis wrote: > On 11.09.2008 20:36, Callum Lerwick wrote: >> $ sudo yum update >> Loaded plugins: fedorakmod, refresh-packagekit >> [...] >> So, an update in the Repo That Can Not Be Named, depends on an update in >> the updates-newkey repo, not yet available, > > Just to set things straight: it's available for about 36 hours now afaics: > https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00385.html > > > The xine-lib-extras-nonfree package hit the livna repo about half a hour > later. > >> thus breaking the transaction due to yum's pedantry. >> >> Something to be aware of if you have non-technical users using Livna, >> and you didn't think you needed the skip-broken plugin... > > That is a well known problem; I put it up for broader discussion how to > best fix it and described the root of the problem in details about one > month ago: > > https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html > > I'm all for solving that problem, but that afaics should happen on the > yum level and thus in Fedora and not in Livna/RPM Fusion. Seems > skip-broken is the best answer, but that's not enabled by default in > Fedora. Livna/RPM Fusion could fix that via its release-packages, but > that's not nice and I want to avoid going that route. > > CU > knurd > Such things trouble/scare common end-users a lot. There should be a "More Information" button in PackageKit dialogs, which explains the situation and that this might only just take some days to resolve. From fedora at leemhuis.info Fri Sep 12 08:27:03 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 12 Sep 2008 10:27:03 +0200 Subject: Beware: External repos can break key transition In-Reply-To: References: <1221158197.6431.24.camel@localhost.localdomain> <48C9721A.6070603@leemhuis.info> Message-ID: <48CA27D7.2080505@leemhuis.info> On 12.09.2008 10:06, Harald Hoyer wrote: > Thorsten Leemhuis wrote: >> On 11.09.2008 20:36, Callum Lerwick wrote: >>> $ sudo yum update >>> Loaded plugins: fedorakmod, refresh-packagekit >>> [...] >>> So, an update in the Repo That Can Not Be Named, depends on an update in >>> the updates-newkey repo, not yet available, >> Just to set things straight: it's available for about 36 hours now afaics: >> https://www.redhat.com/archives/fedora-package-announce/2008-September/msg00385.html >> The xine-lib-extras-nonfree package hit the livna repo about half a hour >> later. >> >>> thus breaking the transaction due to yum's pedantry. >>> Something to be aware of if you have non-technical users using Livna, >>> and you didn't think you needed the skip-broken plugin... >> That is a well known problem; I put it up for broader discussion how to >> best fix it and described the root of the problem in details about one >> month ago: >> https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html >> >> I'm all for solving that problem, but that afaics should happen on the >> yum level and thus in Fedora and not in Livna/RPM Fusion. Seems >> skip-broken is the best answer, but that's not enabled by default in >> Fedora. Livna/RPM Fusion could fix that via its release-packages, but >> that's not nice and I want to avoid going that route. > > Such things trouble/scare common end-users a lot. Sure, that's why I one month ago tried to kick of the discussion to find a solution (see the mail that is quoted above). But I didn't really succeed afaics. :-/ > There should be a "More > Information" button in PackageKit dialogs, which explains the situation and that > this might only just take some days to resolve. I'd *much* prefer if users don't run into that trouble at all. I currently think that the best solution is the one outlined in this sub thread: https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00151.html E.g. enable skip-broken by default, but show the error to the user if security updates are involved *or* if the problem doesn't vanish within 72 hours after it had been hit on the client for the first time. For those cases a '"More Information" button in PackageKit' is likely a really good idea. CU knurd From martin.langhoff at gmail.com Fri Sep 12 08:30:39 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Fri, 12 Sep 2008 20:30:39 +1200 Subject: PostgreSQL mgmt on Fedora: pg_cluster-like tools? In-Reply-To: <1221198446.15987.64.camel@laptop.gunduz.org> References: <46a038f90809111659o41e98cc5r3e256c890669c5ec@mail.gmail.com> <1221196614.15987.52.camel@laptop.gunduz.org> <46a038f90809112228s172abc4cy1c05b7d494a91f67@mail.gmail.com> <1221198446.15987.64.camel@laptop.gunduz.org> Message-ID: <46a038f90809120130i55c7d04fxee50b574bd16900f@mail.gmail.com> 2008/9/12 Devrim G?ND?Z : > So to which directory do you want us to get backup? (...) All reasonable questions. I'm not suggesting the stock RPMs do any of this crazy stuff I am talking about... > So, IMHO what Fedora should do is to be able to install many versions > in parallel, and leave the rest of DBA work to the users. Yes. 200% agreed. And the OLPC XS team will craft special custom RPMs to run the upgrade in the field, estimating disk storage needs to avoid the disk-full situation, evaluating the success of the migration and subsequent steps. Now, once the 'many versions in parallel' thing works well, it does need a bit of glue to be nice and easy to write scripts that perform some actions on one PG install, and other actions on another PG install. That's the glue I am asking for. In other words... if I'm going to shoot myself in the foot, the gun better be nice and comfortable to hold :-) Debian has reasonably good glue/wrappers - with some problems, but they all have workarounds. They could be rewritten in Python or bash easily. As Tom points out, it'll be pretty nigh impossible to write a wrapper without _some_ issues so Fedora could at least be bug-compatible... cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From aph at redhat.com Fri Sep 12 09:15:37 2008 From: aph at redhat.com (Andrew Haley) Date: Fri, 12 Sep 2008 10:15:37 +0100 Subject: Possible gcc issue In-Reply-To: <0ML31I-1Kdt2h29yK-0006cn@mrelayeu.kundenserver.de> References: <48C94597.2000705@herr-schmitt.de> <48C96B27.9020700@redhat.com> <0ML31I-1Kdt2h29yK-0006cn@mrelayeu.kundenserver.de> Message-ID: <48CA3339.8020401@redhat.com> Jochen Schmitt wrote: > On Thu, 11 Sep 2008 12:01:59 -0700, you wrote: > >> Not a gcc bug and no bug in glibc. This is inline asm which requires >> registers which for some reason are not available. > >> Compile this file with __NO_STRING_INLINES defined. > > Thank you for your hint, I'm now able to build the package on > koji. > > But I have the following question: Why does this issue occurs > only on rawhide in the i386-architecture. On F-9 or on other > architectures this issue doesn't occurs. The i386 is very short of registers and that asm uses most of them. gcc can't find any scrtach registers to use as temporaries. It's lucky that this worked in the past. I'm not sure that I agree with Uli that this is no bug in glibc -- it looks to me like this inline should be disabled or deleted. Andrew. From joshuacov at googlemail.com Fri Sep 12 10:05:16 2008 From: joshuacov at googlemail.com (Joshua C.) Date: Fri, 12 Sep 2008 12:05:16 +0200 Subject: modesetting feature status In-Reply-To: <1221174980.30676.10.camel@optimus> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221145599.11745.3.camel@aglarond.local> <1221152956.4345.17.camel@atropine.boston.devel.redhat.com> <1221155164.11745.13.camel@aglarond.local> <5f6f8c5f0809111209o1d28bae4p246d699f3520c40@mail.gmail.com> <1221174980.30676.10.camel@optimus> Message-ID: <5f6f8c5f0809120305y41ac861fq8a91d1547519a955@mail.gmail.com> 2008/9/12 Dave Airlie : > > bug number? https://bugzilla.redhat.com/show_bug.cgi?id=461545 > > what kernel did you last test with? > > stop scare mongering its a beta release, if it still doesn't work at I'm just trying to HELP > devel freeze I'll blacklist all the broken machines. > > Dave. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > See here too https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01018.html From bnocera at redhat.com Fri Sep 12 10:28:45 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 12 Sep 2008 11:28:45 +0100 Subject: Does your package provide GStreamer plugins? Message-ID: <1221215325.24928.235.camel@cookie.hadess.net> Hey, If your package provides GStreamer plugins, please rebuild it in rawhide with the latest gstreamer-devel and RPM builds. If you are a third-party repository maintainer, this is even more important. We are trying to use a PackageKit-based solution to installing missing GStreamer plugins. The new GStreamer and RPM packages will add strings like this to your RPM's provides: gstreamer0.10(urisource-ssh)()(64bit) gstreamer0.10(decoder-application/ogg)()(64bit) This will be used by a yet-to-be-written application that will use PackageKit to provide missing plugins installation. That means that, with the right set of third-party repositories, most videos and audio files will have seamless auto-installation, without any hard-coding of which package provides which resource. For more information see: https://fedoraproject.org/wiki/Features/GStreamer_dependencies_in_RPM I've already rebuilt: gstreamer-plugins-base gstreamer-plugins-good gstreamer-plugins-flumpegdemux I will rebuild bluez as well. Could somebody please rebuild gstreamer-plugins-farsight as well? Cheers From hughsient at gmail.com Fri Sep 12 10:25:59 2008 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 12 Sep 2008 11:25:59 +0100 Subject: Beware: External repos can break key transition In-Reply-To: <48CA27D7.2080505@leemhuis.info> References: <1221158197.6431.24.camel@localhost.localdomain> <48C9721A.6070603@leemhuis.info> <48CA27D7.2080505@leemhuis.info> Message-ID: <1221215159.3284.51.camel@hughsie-work> On Fri, 2008-09-12 at 10:27 +0200, Thorsten Leemhuis wrote: > I'd *much* prefer if users don't run into that trouble at all. I > currently think that the best solution is the one outlined in this sub > thread: > https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00151.html > > E.g. enable skip-broken by default The yum backend in PackageKit tries to enable --skip-broken, but it doesn't seem to make much difference. > For those cases a '"More Information" button in PackageKit' is likely > a really good idea. The text I've got already is this: case PK_ERROR_ENUM_FILE_CONFLICTS: text = _("Two packages provide the same file.\n" "This is usually due to mixing packages for different software sources."); break; case PK_ERROR_ENUM_PACKAGE_CONFLICTS: text = _("Multiple packages exist that are not compatible with each other.\n" "This is usually due to mixing packages for different software sources."); break; case PK_ERROR_ENUM_REPO_NOT_AVAILABLE: text = _("There was a (possibly temporary) problem connecting to a software source\n" "Please check the detailed error for further details."); break; case PK_ERROR_ENUM_NO_MORE_MIRRORS_TO_TRY: text = _("Required data could not be found on any of the configured software sources.\n" "There were no more download mirrors that could be tried."); break; I don't mind adding a clickable link in the dialog, but the data needs to be translated and so I would much prefer to point the user to a yelp page with all the extra info. I've a horrible feeling that this help text would be very distro specific. How would you improve those error messages, and what "extra information" would you provide to the user? My personal view is that by showing an error dialog, we've lost, and should avoid doing it at all costs. Richard. From mschwendt at gmail.com Fri Sep 12 11:48:09 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Fri, 12 Sep 2008 13:48:09 +0200 Subject: Fw: [PATCH] postgresql in rawhide Message-ID: <20080912134809.1981af07.mschwendt@gmail.com> Begin forwarded message: Date: Wed, 27 Aug 2008 00:45:20 +0200 From: Michael Schwendt To: postgresql-owner at fedoraproject.org Subject: [PATCH] postgresql in rawhide Hi! Here's a trivial patch for Fedora devel. It fixes the status output of "service postgresql initdb". -- Michael Schwendt Fedora release 8 (Werewolf) - Linux 2.6.26.3-5.fc8 loadavg: 1.74 1.85 1.84 -------------- next part -------------- A non-text attachment was scrubbed... Name: postgresql.init.patch Type: application/octet-stream Size: 637 bytes Desc: not available URL: From tgl at redhat.com Fri Sep 12 12:07:47 2008 From: tgl at redhat.com (Tom Lane) Date: Fri, 12 Sep 2008 08:07:47 -0400 Subject: PostgreSQL mgmt on Fedora: pg_cluster-like tools? In-Reply-To: <46a038f90809112228s172abc4cy1c05b7d494a91f67@mail.gmail.com> References: <46a038f90809111659o41e98cc5r3e256c890669c5ec@mail.gmail.com> <1221196614.15987.52.camel@laptop.gunduz.org> <46a038f90809112228s172abc4cy1c05b7d494a91f67@mail.gmail.com> Message-ID: <2591.1221221267@sss.pgh.pa.us> "Martin Langhoff" writes: > 2008/9/12 Devrim G?ND?Z : >> * Upstream never ever gives such a guarantee that all apps will work on >> every PostgreSQL version. For example, some casts were removed in 8.3. > Having been once the maintainer of the Pg compat layer in Moodle, I > also have first-hand experience with this. When the casts removal was > mentioned in pg-devel, who was there asking about backwards compat? If you need 100% backwards compatibility, you keep using 8.2 (or whichever). That's why we keep maintaining back branches for so long. If we were to try to keep 100% compatibility in new releases, our ability to add new features would be crippled. So I'm not about to apologize for the fact that 8.3 exposed the brokenness of some broken apps. Anyway, Devrim is quite right that mere installation of an RPM cannot execute any sort of database conversion. The functionality would need to be invoked sometime else. That doesn't mean it has to be manual though. Could we put it in the start script, invoked by something like "service postgresql upgrade"? Exactly what does a conversion look like in Debian's packaging, anyway? regards, tom lane From j.w.r.degoede at hhs.nl Fri Sep 12 12:17:55 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 12 Sep 2008 14:17:55 +0200 Subject: Does your package provide GStreamer plugins? In-Reply-To: <1221215325.24928.235.camel@cookie.hadess.net> References: <1221215325.24928.235.camel@cookie.hadess.net> Message-ID: <48CA5DF3.4080902@hhs.nl> Bastien Nocera wrote: > Hey, > > If your package provides GStreamer plugins, please rebuild it in rawhide > with the latest gstreamer-devel and RPM builds. > > If you are a third-party repository maintainer, this is even more > important. > I will take care of the third-party packages I'm maintaining, I need to update them to the latest upstream anyways. Regards, Hans From rawhide at fedoraproject.org Fri Sep 12 12:46:39 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Fri, 12 Sep 2008 12:46:39 +0000 (UTC) Subject: rawhide report: 20080912 changes Message-ID: <20080912124639.592611F8251@releng2.fedora.phx.redhat.com> New package binclock Fullscreen console binary clock New package csstidy CSS parser and optimizer New package gnome-valgrind-session Run an entire GNOME session under valgrind New package hunspell-nr Southern Ndebele hunspell dictionaries New package nes_ntsc Provides a NES NTSC video filtering library New package open-cobol OpenCOBOL - COBOL compiler New package perl-Config-Grammar Grammar-based, user-friendly config parser New package perl-Schedule-Cron-Events Take a line from a crontab and find out when events will occur New package pidgin-facebookchat Facebook Chat IM Pidgin plugin New package ptlib Portable Tools Library New package python-markdown2 A fast and complete Python implementation of Markdown New package python-peak-rules Generic functions and business rules support systems New package python-peak-util-addons Dynamically extend other objects with AddOns New package python-peak-util-assembler Generate Python code objects by "assembling" bytecode New package python-peak-util-extremes Production-quality 'Min' and 'Max' objects New package python-peak-util-symbols Simple "symbol" type, useful for enumerations or sentinels New package python-pysctp Python sctp socket api extensions bindings New package xosview An X Window System utility for monitoring system resources Removed package tetex-eurofont Removed package uqm-content Removed package vdrift-data Updated Packages: GraphicsMagick-1.1.14-3.fc10 ---------------------------- * Thu Sep 11 18:00:00 2008 Tom "spot" Callaway - 1.1.14-3 - own all files properly * Thu Sep 11 18:00:00 2008 Tom "spot" Callaway - 1.1.14-2 - turns out we do need gcc43 patch * Thu Sep 11 18:00:00 2008 Tom "spot" Callaway - 1.1.14-1 - update to 1.1.14 - fix perl issue (bz 454087) NetworkManager-0.7.0-0.11.svn4022.2.fc10 ---------------------------------------- * Thu Sep 11 18:00:00 2008 Dan Williams - 1:0.7.0-0.11.svn4022.2 - Fix hang when reading system connections from ifcfg files alsa-lib-1.0.18-6.rc3.fc10 -------------------------- alsa-plugins-1.0.18-1.rc3.fc10 ------------------------------ * Thu Sep 11 18:00:00 2008 Jaroslav Kysela - 1.0.18-1.rc3 - Updated to 1.0.18rc3 - Added usbstream subpackage alsa-utils-1.0.18-1.rc3.fc10 ---------------------------- * Thu Sep 11 18:00:00 2008 Jaroslav Kysela 1.0.18-1.rc3 - updated to 1.0.18rc3 - updated alsa-info.sh script to 0.4.51 - removed alsacard utility - removed salsa utility - changed alsaunmute to use 'alsactl init' now - updated ALSA udevd rules to use alsactl - moved /etc/alsa/asound.state back to /etc/asound.state amora-1.1-2.fc10 ---------------- * Thu Sep 11 18:00:00 2008 - Bastien Nocera 1.1-2 - Rebuild anaconda-11.4.1.34-1 -------------------- * Thu Sep 11 18:00:00 2008 Chris Lumens - 11.4.1.34-1 - Always start NM so we can talk to it in the boot.iso case (#461071). (clumens) - Use the device path to identify LUKS devs in /etc/fstab. (#460700) (dlehman) - Use the LUKS UUID instead of device nodes in all references. (#460700) (dlehman) - LUKSDevice.getScheme() no longer cares if the dev has a passphrase. (#461203) (dlehman) - Correct translation to fix the build. (clumens) - Add the method string back into anaconda-ks.cfg. (clumens) - Let's try pulling libsqlite into the initrd one more time. (clumens) - Don't traceback at the end of live installs (katzj) - Correct the message telling you to use a VNC password. (clumens) - Remove unused TIMEZONES= crud. (clumens) - print doesn't yet support the file= syntax in our version of python. (clumens) - Catch errors from using the wrong bugzilla field and display them. (clumens) - Fix line wrapping on part type screen (jlaska, #461759). - rep_platform has been renamed to platform. (clumens) audit-1.7.6-1.fc10 ------------------ * Thu Sep 11 18:00:00 2008 Steve Grubb 1.7.6-1 - Add subject to audit daemon events (Chu Li) - Add tcp_wrappers support for auditd - Updated syscall tables for 2.6.27 kernel - Audit connect/disconnect of remote clients - Add GSS/Kerberos encryption to the remote protocol (DJ Delorie) bes-3.6.2-1.fc10 ---------------- * Fri Sep 5 18:00:00 2008 Patrice Dumas 3.6.2-1 - update to 3.6.2 * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 3.5.3-4 - Autorebuild for GCC 4.3 callweaver-1.2.0.1-1.2.fc10 --------------------------- * Thu Sep 11 18:00:00 2008 - Bastien Nocera - 1.2.0.1-1.2 - Rebuild cdparanoia-10.2-1.fc10 ---------------------- * Thu Sep 11 18:00:00 2008 Adam Jackson 10.2-1 - cdparanoia 10.2 cksfv-1.3.13-1.fc10 ------------------- * Thu Sep 11 18:00:00 2008 Christopher Stone 1.3.13-1 - Upstream sync dap-freeform_handler-3.7.9-1.fc10 --------------------------------- * Fri Sep 5 18:00:00 2008 Patrice Dumas 3.7.9-1 - update to 3.7.9 * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 3.7.7-3 - Autorebuild for GCC 4.3 dap-hdf4_handler-3.7.9-1.fc10 ----------------------------- * Fri Sep 5 18:00:00 2008 Patrice Dumas 3.7.9-1 - update to 3.7.9 - remove now unneeded open patch * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 3.7.7-4 - Autorebuild for GCC 4.3 dap-netcdf_handler-3.7.9-1.fc10 ------------------------------- * Fri Sep 5 18:00:00 2008 Patrice Dumas 3.7.9-1 - update to 3.7.9 dap-server-3.8.5-1.fc10 ----------------------- * Fri Sep 5 18:00:00 2008 Patrice Dumas 3.8.5-1 - update to 3.8.5 dhcpv6-1.0.22-1.fc10 -------------------- * Thu Sep 11 18:00:00 2008 David Cantrell - 1.0.22-1 - Upgrade to dhcpv6-1.0.22, changes include: Windows 2008 interoperability fixes for ADVERTISE msgs Information Refresh Time option support IA address option bug fixes Check DAD by interface type in REPLY msgs Clear request addr list when msg is sent successfully Call init_lease_hashes() in dhcp6c echo-artist-0.1.1-1.fc10 ------------------------ * Fri Sep 19 18:00:00 2008 Martin Sourada - 0.1.1-1 - New release - Fixes problem with adding new icons to dir where no other icons are yet. echo-icon-theme-0.3.89.0-0.10.20080911gita7c752e.fc10 ----------------------------------------------------- * Thu Sep 11 18:00:00 2008 Martin Sourada - 0.3.89.0-0.10.20080911gita7c752e - New git snapshot eclipse-cdt-5.0.0-6.fc10 ------------------------ * Tue Sep 9 18:00:00 2008 Jeff Johnston 5.0.0-6 - Fix for NPE during alteration of Autotools configuration settings. - Resolves #461647 flam3-2.7.16-1.fc10 ------------------- * Thu Sep 11 18:00:00 2008 Ian Weller 2.7.16-1 - Upstream updated: Added 'clone_all' to flam3_genome to allow application of template to all flames in a file at once, and 'animate' to write a full sequence of interpolations out. 'animate' is similar to 'sequence' except that no control point rotation is performed. Fixed non-functional 'write_genome' env var for flam3_animate. Two bugs associated with interpolating from a log interpolation_type to a non-log interpolation_type fixed (rotate angle reduction and special inverted identity). when using flam3_rotate in 'spin_inter' the interp type of the first genome is now used rather than the current genome's interp type. Enforced upper and lower bounds for xform color and upper bound for interpolated colormap values as "smooth" interpolation led to values out of range. If "smooth" interpolation is specified for all flames in a file, the first and second-to-last genome is switched to "linear" with a warning. spatial filters with non-box-filter window functions fixed. Release as 2.7.16. freecol-0.7.4-2.fc10 -------------------- * Thu Sep 11 18:00:00 2008 Tom "spot" Callaway 0.7.4-2 - use tetex-tex4ht instead of latex2html gammu-1.20.90-2.fc10 -------------------- * Thu Sep 11 18:00:00 2008 Xavier Lamien - 1.20.90-2 - Rebuild against new libbluetooth. * Mon Aug 25 18:00:00 2008 Xavier Lamien - 1.20.90-1 - Update release. * Sat Aug 23 18:00:00 2008 Xavier Lamien - 1.20.0-1 - Update release. gdal-1.5.2-3.fc10 ----------------- * Tue Sep 9 18:00:00 2008 Patrice Dumas - 1.5.2-3 - patch for libdap > 0.8.0, from Rob Cermak gdm-2.23.92-3.fc10 ------------------ * Thu Sep 11 18:00:00 2008 Ray Strode - 1:2.23.92-3 - Add hook to allow for plymouth transition gnokii-0.6.26-3.fc10 -------------------- * Thu Sep 11 18:00:00 2008 - Bastien Nocera - 0.6.26-3 - Rebuild gnome-bluetooth-0.11.0-5.fc10 ----------------------------- * Thu Sep 11 18:00:00 2008 Matthias Clasen - 0.11.0-5 - Rebuild against new bluez-libs gnome-phone-manager-0.60-2.fc10 ------------------------------- * Thu Sep 11 18:00:00 2008 Matthias Clasen - Rebuild gnome-settings-daemon-2.23.92-2.fc10 ------------------------------------ * Thu Sep 11 18:00:00 2008 Soren Sandmann - 2.23.91-5 - Fix various bugs in the fn-F7 support gnome-vfs2-obexftp-0.4-8.fc10 ----------------------------- * Thu Sep 11 18:00:00 2008 - Bastien Nocera - 0.4-8 - Rebuild grads-1.9b4-25.fc10 ------------------- * Thu Sep 11 18:00:00 2008 - Patrice Dumas 1.9b4-25 - rebuild for new libnc-dap - rediff patches - use new netcdf devel file locations gstreamer-0.10.20-5.fc10 ------------------------ * Fri Sep 12 18:00:00 2008 - Bastien Nocera - 0.10.20-5 - Update rpm provides script and patch to: - filter out errors - only run gst-inspect on gstreamer plugins - print out protocol handlers provides correctly * Thu Sep 11 18:00:00 2008 - Bastien Nocera - 0.10.20-4 - Add the rpm scripts install in /usr/lib/rpm, not under libdir on 64-bit * Thu Sep 11 18:00:00 2008 - Bastien Nocera - 0.10.20-3 - Update filelist as well * Thu Sep 11 18:00:00 2008 - Bastien Nocera - 0.10.20-2 - Update gstreamer provides work for the new RPM, see #438225 gstreamer-plugins-base-0.10.20-4.fc10 ------------------------------------- * Fri Sep 12 18:00:00 2008 - Bastien Nocera - 0.10.20-4 - Another rebuild * Thu Sep 11 18:00:00 2008 - Bastien Nocera - 0.10.20-3 - Rebuild for new RPM provides gstreamer-plugins-flumpegdemux-0.10.15-4.fc10 --------------------------------------------- * Fri Sep 12 18:00:00 2008 - Bastien Nocera - 0.10.15-4 - Another rebuild * Thu Sep 11 18:00:00 2008 - Bastien Nocera - 0.10.15-3 - Rebuild for GStreamer RPM provides work gstreamer-plugins-good-0.10.10-4.fc10 ------------------------------------- * Fri Sep 12 18:00:00 2008 - Bastien Nocera 0.10.10-4 - Another rebuild * Thu Sep 11 18:00:00 2008 - Bastien Nocera 0.10.10-3 - Rebuild for GStreamer RPM provides gypsy-0.6-4.fc10 ---------------- * Thu Sep 11 18:00:00 2008 - Bastien Nocera 0.6-4 - Rebuild hal-info-20080813-4.fc10 ------------------------ * Thu Sep 11 18:00:00 2008 Soren Sandmann - 20080813-2 - Add patch for Lenovo 3000 video key highlight-2.6.12-2.fc10 ----------------------- * Thu Sep 11 18:00:00 2008 Tom "spot" Callaway 2.6.12-2 - don't package broken examples, causes bogus perl provides/requires - don't claim to Provide: perl(highlight_pipe) - don't claim to Requires: perl(IPC::Open3) ikiwiki-2.63-1.fc10 ------------------- * Thu Sep 11 18:00:00 2008 Thomas Moschny - 2.63-1 - Update to 2.63. kdebluetooth-1.0-0.43.beta8.fc10 -------------------------------- * Thu Sep 11 18:00:00 2008 Rex Dieter - 1.0-0.43.beta8 - fix build (no kdepim3 on f10+) - spec cosmetics - drop multilib upgrade Obsoletes hack * Thu Sep 11 18:00:00 2008 - Bastien Nocera - 1.0-0.42.beta8 - Rebuild kernel-2.6.27-0.323.rc6.fc10 ---------------------------- * Thu Sep 11 18:00:00 2008 Dave Airlie - drm - fix some minor annoyance with radeon for beta ldm-2.0.12-2.fc10 ----------------- * Wed Sep 10 18:00:00 2008 Warren Togami - 2.0.12-2 - remove /var/cache/ldm from package, renamed and shipped in ltsp-server instead libHX-1.25-1.fc10 ----------------- * Thu Sep 11 18:00:00 2008 Till Maas - 1.25-1 - Update to latest version libbtctl-0.10.0-5.fc10 ---------------------- * Thu Sep 11 18:00:00 2008 - Bastien Nocera - 0.10.0-5 - Rebuild with patch for BlueZ 4.x * Thu Sep 11 18:00:00 2008 - Bastien Nocera - 0.10.0-4 - Rebuild libcgroup-0.31-1.fc10 --------------------- * Thu Sep 11 18:00:00 2008 Dhaval Giani 0.31-1 - Update to latest upstream libnc-dap-3.7.3-1.fc10 ---------------------- * Tue Sep 9 18:00:00 2008 Patrice Dumas 3.7.3-1 - update to 3.7.3 * Thu Sep 4 18:00:00 2008 Patrice Dumas 3.7.0-11 - gcc 4.3 patch for missing include files * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 3.7.0-10 - Autorebuild for GCC 4.3 libopensync-plugin-irmc-0.36-2.fc10 ----------------------------------- * Thu Sep 11 18:00:00 2008 - Bastien Nocera - 0.36-2 - Rebuild libspe2-2.2.80.132-1.fc10 ------------------------- * Thu Sep 11 18:00:00 2008 Jochen Roth 2.2.80.132-1 - Upgraded to latest upstream version libsyncml-0.4.5-3.fc10 ---------------------- * Thu Sep 11 18:00:00 2008 - Bastien Nocera - 0.4.5-3 - Rebuild libwiimote-0.4-7.fc10 --------------------- * Thu Sep 11 18:00:00 2008 - Bastien Nocera - 0.4-7 - Rebuild with Bluez 4.x patch * Thu Sep 11 18:00:00 2008 - Bastien Nocera - 0.4-6 - Rebuild libxcb-1.1.91-1.fc10 -------------------- * Wed Sep 10 18:00:00 2008 Adam Jackson 1.1.91-1 - libxcb 1.1.91 ltsp-5.1.24-1.fc10 ------------------ * Thu Sep 11 18:00:00 2008 Warren Togami - 5.1.24-1 - lts.conf options: VOLUME, HEADPHONE_VOLUME, PCM_VOLUME, CD_VOLUME, FRONT_VOLUME Set values higher than default if not specified in lts.conf. MIC_VOLUME not set by default, but can be controlled by lts.conf. - xrexec renamed to ltsp-localapps - xrexecd.sh renamed to ltsp-localappsd - fix build on RHEL-5 * Wed Sep 10 18:00:00 2008 Warren Togami - 5.1.23-1 - Point F8 and F9 client chroot builder at newkey repos - Ensure that initscripts installs before ltsp-client ltspfs-0.5.4-1.fc10 ------------------- * Thu Sep 11 18:00:00 2008 Warren Togami - 0.5.4-1 - bug fixes and more man pages mkinitrd-6.0.63-2.fc10 ---------------------- * Thu Sep 11 18:00:00 2008 Peter Jones - 6.0.63-2 - Require a newer plymouth mtr-0.74-1.fc10 --------------- * Tue Sep 9 18:00:00 2008 Zdenek Prikryl - 2:0.74-1 - Updated to 0.74 ncl-5.0.0-12.fc10 ----------------- * Thu Sep 11 18:00:00 2008 - Orion Poplawski - 5.0.0-12 - Rebuild for new libdap - Fix netcdf include location nco-3.9.5-2.fc10 ---------------- * Thu Sep 11 18:00:00 2008 - Patrice Dumas - 3.9.5-2 - rebuild for newer libnc-dap nss_ldap-261-3.fc10 ------------------- * Thu Sep 11 18:00:00 2008 Nalin Dahyabhai - 261-3 - promote the previous change from a scratch build to the real thing * Tue Aug 26 18:00:00 2008 Nalin Dahyabhai - 261-2 - add libssl and libcrypto to the list of libraries against which we link statically to avoid running into symbol collisions at run-time (#446860) obex-data-server-0.3.4-3.fc10 ----------------------------- * Thu Sep 11 18:00:00 2008 Matthias Clasen - 0.3.4-2 - Rebuild * Thu Sep 11 18:00:00 2008 - Bastien Nocera - 0.3.4-3 - Rebuild with BlueZ 4.x patch obexfs-0.11-0.4.rc3.fc10 ------------------------ * Thu Sep 11 18:00:00 2008 - Bastien Nocera - 0.11-0.4.rc3 - Rebuild obexftp-0.23-0.2.alpha.fc10 --------------------------- * Thu Sep 11 18:00:00 2008 - Bastien Nocera - 0.23-0.2.alpha - Rebuild octave-forge-20080831-2.fc10 ---------------------------- * Thu Sep 11 18:00:00 2008 Orion Poplawski 20080831-2 - Rebuild for new libdap pam_mount-0.48-1.fc10 --------------------- * Thu Sep 11 18:00:00 2008 Till Maas - 0.48-1 - Update to new version perl-Data-ICal-0.13-3.fc10 -------------------------- * Fri Sep 12 18:00:00 2008 Ralf Cors??pius 0.13-3 - Fix minor typo in spec. perl-Glib-1.183-1.fc10 ---------------------- * Thu Sep 11 18:00:00 2008 Tom "spot" Callaway - 1.183-1 - update to 1.183 pilot-link-0.12.3-15.fc10 ------------------------- * Thu Sep 11 18:00:00 2008 - Bastien Nocera - 2:0.12.3-15 - Rebuild pm-utils-1.2.0-1.fc10 --------------------- * Thu Sep 11 18:00:00 2008 Richard Hughes - 1.2.0-1 - Update to 1.2.0 - The core hook-running machinery will now abort running hooks of one fails, and the front-end scripts will return a failure error code if hook-running was aborted. policycoreutils-2.0.55-8.fc10 ----------------------------- * Thu Sep 11 18:00:00 2008 Dan Walsh 2.0.55-8 - Only call gen_requires once in sepolgen pulseaudio-0.9.12-5.fc10 ------------------------ * Thu Sep 11 18:00:00 2008 - Bastien Nocera 0.9.12-5 - Rebuild pybluez-0.15-2.fc10 ------------------- * Thu Sep 11 18:00:00 2008 - Bastien Nocera - 0.15-2 - Rebuild pyexiv2-0.1.2-4.fc10 -------------------- * Thu Sep 11 18:00:00 2008 Jesse Keating - 0.1.2-4 - Rebuild for deps qosmic-1.4.1-1.fc10 ------------------- * Thu Sep 11 18:00:00 2008 Ian Weller 1.4.1-1 - Updated upstream: - Viewer presets can be renamed and changed, and they no longer modify the final image size. - Added support for UGR gradient files to the palette editor. - Updated all debug messages to work with 64bit systems. - Several rendering scheduling bugfixes. - Fixed a crash bug in the genome selection widget, and also adjusted the layout. - Automatically rescale the genome when the image size is changed. - Fixed a some scaling and redrawing problems in the figure editor. - Updated to flam3-2.7.16. - Updated flam3 requires to 2.7.16 rekall-2.4.6-5.fc10 ------------------- rhpxl-1.9-3.fc10 ---------------- * Thu Sep 11 18:00:00 2008 Adam Jackson 1.9-3 - Un-Requires: newt. rpm-4.5.90-0.git8461.7 ---------------------- * Thu Sep 11 18:00:00 2008 Panu Matilainen - add hack to support extracting gstreamer plugin provides (#438225) - fix another macro argument handling regression (#461180) * Thu Sep 11 18:00:00 2008 Jindrich Novy - create directory structure for rpmbuild prior to build if it doesn't exist (#455387) - create _topdir if it doesn't exist when installing SRPM - don't generate broken cpio in case of hardlink pointing on softlink, thanks to pixel at mandriva.com ssmtp-2.61-11.6.fc10 -------------------- * Thu Sep 11 18:00:00 2008 Manuel "lonely wolf" Wolfshant 2.61-11.6 - patch to fix CVE-2008-3962 (courtesy https://bugs.gentoo.org/127592) - cleanup of other patches, make build with fuzz=0 * Sat Aug 2 18:00:00 2008 Manuel "lonely wolf" Wolfshant 2.61-11.5.4 - work around rpmbuild more strict syntax checker sugar-0.82.4-1.fc10 ------------------- * Thu Sep 11 18:00:00 2008 Marco Pesenti Gritti - 0.82.4-1 - #7480 Need to 'reset' the network configurations - short term fix - #8368 Disable the server plugin if no server was specified sugar-journal-99-3.fc10 ----------------------- * Thu Sep 11 18:00:00 2008 Marco Pesenti Gritti - 99-3 - Obvious typo in the files * Thu Sep 11 18:00:00 2008 Marco Pesenti Gritti - 99-2 - Fixup packaging for the new bundlebuilder * Thu Sep 11 18:00:00 2008 Marco Pesenti Gritti - 99-1 - #8287 8.2-757: Copy-to-clipboard broken in Journal sugar-toolkit-0.82.6-1.fc10 --------------------------- * Thu Sep 11 18:00:00 2008 Marco Pesenti Gritti - 0.82.6-1 - #8394 sugar shell leaks presence service info - #8392 Remove "dynamic" font height computation system-config-kdump-1.0.14-2.fc10 --------------------------------- * Thu Sep 11 18:00:00 2008 Roman Rakus 1.0.14-2 - Don't specify any offset in cmdline argument Resolves: #461602 uqm-0.6.2-6.fc10 ---------------- * Thu Sep 11 18:00:00 2008 Tom "spot" Callaway - 0.6.2-6 - properly Provide/Obsolete dead uqm-content package * Wed Sep 10 18:00:00 2008 Tom "spot" Callaway - 0.6.2-5 - drop /usr/share/games/uqm to /usr/share/uqm * Wed Sep 10 18:00:00 2008 Tom "spot" Callaway - 0.6.2-4 - convert package to use autodownloader - look for content in user homedir w3c-markup-validator-0.8.3-2 ---------------------------- * Thu Sep 11 18:00:00 2008 Ville Skytt?? - 0.8.3-2 - Upstream fix for server error log trashing. * Tue Aug 12 18:00:00 2008 Ville Skytt?? - 0.8.3-1 - 0.8.3 + upstream types.conf fix; missing form enctype patch applied upstream. - Drop disttag. xcb-proto-1.2-2.fc10 -------------------- * Thu Sep 11 18:00:00 2008 Adam Jackson 1.2-2 - Add additional selinux requests. (#461844) xmms-1.2.11-1.20071117cvs.1.fc10 -------------------------------- * Wed Sep 10 18:00:00 2008 Paul F. Johnson 1.2.11-20071117cvs-1.1 - Reverted license to gplv2+ (oopsy!) xmms-skins-1.2.10-18 -------------------- * Thu Sep 11 18:00:00 2008 Tom "spot" Callaway 1:1.2.10-18 - Ultrafina author says we can use them under CC-BY xorg-x11-drv-ati-6.9.0-14.fc10 ------------------------------ * Thu Sep 11 18:00:00 2008 Soren Sandmann 6.9.0-13 - Remove the fb size hack since there is a fix in the server now. - Unfortunately, the driver prevents this fix from working by applying its own heuristics. Remove those. * Thu Sep 11 18:00:00 2008 Adam Jackson 6.9.0-14 - radeon-6.9.0-panel-size-sanity.patch: Panels smaller than 800x480 are highly implausible, disable them if we find them. If you have one, you can force it with Option "PanelSize". xorg-x11-drv-i810-2.4.2-8.fc10 ------------------------------ * Thu Sep 11 18:00:00 2008 Soren Sandmann 2.4.2-8 - Remove the fb size hack, since there is a fix in the server now. xorg-x11-drv-nv-2.1.12-4.fc10 ----------------------------- * Thu Sep 11 18:00:00 2008 Soren Sandmann 2.1.12-4 - Remove fb size hack since there is a fix in the server now. xorg-x11-server-1.5.0-6.fc10 ---------------------------- * Thu Sep 11 18:00:00 2008 Soren Sandmann 1.5.0-6 - Comment out glxdri2.c since it doesn't compile. (krh says it won't break at runtime). * Thu Sep 11 18:00:00 2008 Soren Sandmann 1.5.0-5 - Bump BuildRequires on mesa-GL-devel. Maybe that will work. * Thu Sep 11 18:00:00 2008 Soren Sandmann 1.5.0-4 - Bump BuildRequires on xorg-x11-proto-devel * Thu Sep 11 18:00:00 2008 Soren Sandmann 1.5.0-3 - Change the external monitor patch to base off of amount of video ram. * Thu Sep 11 18:00:00 2008 Soren Sandmann 1.5.0-3 - Change the default screen limits to include room for a 1280 wide projector. * Wed Sep 10 18:00:00 2008 Dave Airlie 1.5.0-2 - bring master exa back xscreensaver-5.07-2.fc10 ------------------------ * Fri Sep 12 18:00:00 2008 Mamoru Tasaka - 1:5.07-2 - Update ja.po - Fix the explanation in XScreenSaver.ad (bug 461415) Summary: Added Packages: 18 Removed Packages: 3 Modified Packages: 90 Broken deps for i386 ---------------------------------------------------------- em8300-0.17.1-1.fc10.i386 requires /etc/alsa/cards evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.i386 requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so Broken deps for x86_64 ---------------------------------------------------------- em8300-0.17.1-1.fc10.x86_64 requires /etc/alsa/cards evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.x86_64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- em8300-0.17.1-1.fc10.ppc requires /etc/alsa/cards evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.ppc requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires libbfd-2.18.50.0.8-2.fc10.so stapitrace-1.0.0-6.20080622cvs_alpha.fc10.ppc requires libopcodes-2.18.50.0.8-2.fc10.so Broken deps for ppc64 ---------------------------------------------------------- eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 em8300-0.17.1-1.fc10.ppc64 requires /etc/alsa/cards evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave livecd-tools-018-1.fc10.ppc64 requires yaboot mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.ppc64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) From lesmikesell at gmail.com Fri Sep 12 13:05:13 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 12 Sep 2008 08:05:13 -0500 Subject: PostgreSQL mgmt on Fedora: pg_cluster-like tools? In-Reply-To: <48CA0A62.1070507@fedoraproject.org> References: <46a038f90809111659o41e98cc5r3e256c890669c5ec@mail.gmail.com> <1221196614.15987.52.camel@laptop.gunduz.org> <46a038f90809112228s172abc4cy1c05b7d494a91f67@mail.gmail.com> <1221198446.15987.64.camel@laptop.gunduz.org> <48CA0669.8090603@gmail.com> <1221199805.15987.83.camel@laptop.gunduz.org> <48CA0A62.1070507@fedoraproject.org> Message-ID: <48CA6909.8090801@gmail.com> Rahul Sundaram wrote: > >>> I agree that the package manager should have the ability to install >>> multiple versions of things - and not just in this case. > > Packaging, not a package manager decides that. RPM and yum can install > parallel versions just fine and do that for dozens of packages in the > repository. > > But, >>> what/who should determine which executables/libraries go in the >>> default path? >> >> rpm -ivh postgresql-set-default-8.3-1.noarch.f9.rpm >> >> :) >> >> This will symlink executables and libraries to default path and leave >> the rest outside the path. >> >> How does it sound? > > Sounds like duplicating what is available as part of alternatives package. The double symlinks used by alternatives are even more confusing than the single set needed to do it directly, but it could work either way with a helper script for the conversion so the end user doesn't need to know too much about the real locations. There would be a couple of extra problems here - you would be starting from a package not alternatives aware and trying to change that too, and you somehow need to whack all the running programs that might be linked to the wrong libraries when the running version update happens. -- Les Mikesell lesmikesell at gmail.com From jeff at ocjtech.us Fri Sep 12 13:06:53 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Fri, 12 Sep 2008 08:06:53 -0500 Subject: Does your package provide GStreamer plugins? In-Reply-To: <1221215325.24928.235.camel@cookie.hadess.net> References: <1221215325.24928.235.camel@cookie.hadess.net> Message-ID: <935ead450809120606g2a0a93e2p350d9917417d180e@mail.gmail.com> On Fri, Sep 12, 2008 at 5:28 AM, Bastien Nocera wrote: > > If your package provides GStreamer plugins, please rebuild it in rawhide > with the latest gstreamer-devel and RPM builds. > > We are trying to use a PackageKit-based solution to installing missing > GStreamer plugins. The new GStreamer and RPM packages will add strings > like this to your RPM's provides: > gstreamer0.10(urisource-ssh)()(64bit) > gstreamer0.10(decoder-application/ogg)()(64bit) I tried rebuilding schroedinger but I didn't see any new provides show up. Is there something I'm doing wrong? Here's a scratch build I just did: http://koji.fedoraproject.org/koji/taskinfo?taskID=822502 -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" From ajax at redhat.com Fri Sep 12 13:31:35 2008 From: ajax at redhat.com (Adam Jackson) Date: Fri, 12 Sep 2008 09:31:35 -0400 Subject: make force-tag gone In-Reply-To: <48CA16D1.5070409@redhat.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> <20080911184506.GA1486@redhat.com> <48C97287.8040402@poolshark.org> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> <48CA16D1.5070409@redhat.com> Message-ID: <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> On Fri, 2008-09-12 at 09:14 +0200, Gerd Hoffmann wrote: > Hi, > > > Only CVS needs a revision number per file, and that's > > exactly what the Entries file contains. > > Hmm, wouldn't checkout by date do the trick for cvs? Yes, but that's a bit harder to reconstruct after the fact. There's a potential skew between the notions of "time" between the kojid and the cvs server; the latter is authoritative, but the former is what gets recorded in the build output. Whereas cvs gives you the Entries file for free, so you might as well just save it. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From smorovic at gmail.com Fri Sep 12 12:57:34 2008 From: smorovic at gmail.com (Srecko Morovic) Date: Fri, 12 Sep 2008 12:57:34 +0000 (UTC) Subject: Pulseaudio : lots of issues, how can I help? References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> Message-ID: Arthur Pemberton gmail.com> writes: > > I have a lot of seemingly pulse audio related issues on my F9 desktop. > Since I really like the idea behind Pulseaudio, I would like to see > these get sorted out, and would like to know how I can help in terms > of providing useful information. > FWIW, there is a FUSE patch, called CUSE (character device emulation in userspace). The author also created a proof of concept userspace OSS emulation which should work with pulseaudio, but it requires ALSA OSS emulation to be disabled in kernel at compile time. The implementation doesn't have mmap oss support at this time. http://userweb.kernel.org/~tj/ossp/ kernel mailing list discussion: http://thread.gmane.org/gmane.comp.file-systems.fuse.devel/6818/focus=6820 From bpepple at fedoraproject.org Fri Sep 12 13:35:19 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Fri, 12 Sep 2008 09:35:19 -0400 Subject: Does your package provide GStreamer plugins? In-Reply-To: <1221215325.24928.235.camel@cookie.hadess.net> References: <1221215325.24928.235.camel@cookie.hadess.net> Message-ID: <1221226519.2577.0.camel@truman> On Fri, 2008-09-12 at 11:28 +0100, Bastien Nocera wrote: > Could somebody please rebuild gstreamer-plugins-farsight as well? Yeah, I'll rebuild it. Thanks for the heads up. Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Fri Sep 12 13:38:01 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 12 Sep 2008 15:38:01 +0200 Subject: Beware: External repos can break key transition In-Reply-To: <1221215159.3284.51.camel@hughsie-work> References: <1221158197.6431.24.camel@localhost.localdomain> <48C9721A.6070603@leemhuis.info> <48CA27D7.2080505@leemhuis.info> <1221215159.3284.51.camel@hughsie-work> Message-ID: <48CA70B9.8080005@leemhuis.info> On 12.09.2008 12:25, Richard Hughes wrote: > On Fri, 2008-09-12 at 10:27 +0200, Thorsten Leemhuis wrote: >> I'd *much* prefer if users don't run into that trouble at all. I >> currently think that the best solution is the one outlined in this sub >> thread: >> https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00151.html >> E.g. enable skip-broken by default > The yum backend in PackageKit tries to enable --skip-broken, but it > doesn't seem to make much difference. :-/ >> For those cases a '"More Information" button in PackageKit' is likely >> a really good idea. > The text I've got already is this: > [...] > case PK_ERROR_ENUM_REPO_NOT_AVAILABLE: > text = _("There was a (possibly temporary) problem connecting to a software source\n" > "Please check the detailed error for further details."); > break; I suppose this one is the one that will be shown in the xine-lib/xine-lib-extras case and similar cases with inter-repo problems. > [...] > I don't mind adding a clickable link in the dialog, but the data needs > to be translated and so I would much prefer to point the user to a yelp > page with all the extra info. I've a horrible feeling that this help > text would be very distro specific. > > How would you improve those error messages, and what "extra > information" would you provide to the user? Hmmm. Not sure and maybe a total crazy idea, but maybe a three stage solution could do the trick: 1) the small warning dialog with links to 2) a more specific help text in yelp 3) a page in the wiki which could list current issues and their workaround > My personal view is that by showing an error dialog, we've lost, and > should avoid doing it at all costs. +1 And we should not forget all those users that call yum directly. CU knurd From wolfy at nobugconsulting.ro Fri Sep 12 13:51:20 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Fri, 12 Sep 2008 16:51:20 +0300 Subject: Beware: External repos can break key transition In-Reply-To: <1221215159.3284.51.camel@hughsie-work> References: <1221158197.6431.24.camel@localhost.localdomain> <48C9721A.6070603@leemhuis.info> <48CA27D7.2080505@leemhuis.info> <1221215159.3284.51.camel@hughsie-work> Message-ID: <48CA73D8.1040902@nobugconsulting.ro> Richard Hughes wrote: > On Fri, 2008-09-12 at 10:27 +0200, Thorsten Leemhuis wrote: > >> I'd *much* prefer if users don't run into that trouble at all. I >> currently think that the best solution is the one outlined in this sub >> thread: >> https://www.redhat.com/archives/fedora-devel-list/2008-August/msg00151.html >> >> E.g. enable skip-broken by default >> > > The yum backend in PackageKit tries to enable --skip-broken, but it > doesn't seem to make much difference. > > >> For those cases a '"More Information" button in PackageKit' is likely >> a really good idea. >> > > The text I've got already is this: > > case PK_ERROR_ENUM_FILE_CONFLICTS: > text = _("Two packages provide the same file.\n" > "This is usually due to mixing packages for different software sources."); > "for different" or "from different" ? > break; > case PK_ERROR_ENUM_PACKAGE_CONFLICTS: > text = _("Multiple packages exist that are not compatible with each other.\n" > "This is usually due to mixing packages for different software sources."); > same question here... From limb at jcomserv.net Fri Sep 12 14:22:06 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 12 Sep 2008 09:22:06 -0500 (CDT) Subject: [Fwd: Package: wesnoth-1.4.5-1.fc10 Tag: dist-f10 Status: failed Built by: limb] In-Reply-To: <6155.198.175.55.5.1221074642.squirrel@mail.jcomserv.net> References: <46628.198.175.55.5.1221061335.squirrel@mail.jcomserv.net> <200809101223.03788.dennis@ausil.us> <33322.198.175.55.5.1221067628.squirrel@mail.jcomserv.net> <200809101415.47895.dennis@ausil.us> <6155.198.175.55.5.1221074642.squirrel@mail.jcomserv.net> Message-ID: <44260.198.175.55.5.1221229326.squirrel@mail.jcomserv.net> > >> On Wednesday 10 September 2008 12:27:08 pm Jon Ciesla wrote: >>> > On Wednesday 10 September 2008 10:42:15 am Jon Ciesla wrote: >>> >> I've seen this exact error before, and if I resubmit and get a >>> non-ppc >>> >> builder, it works for all arches. Is there anything I can to, save >>> >> re-submitting ad nauseum? >>> >> >>> >> inf ticket,perhaps? >>> > >>> > from build.log >>> > >>> > magic_file(ms, >>> > "/builddir/build/BUILDROOT/wesnoth-1.4.5-1.fc10.x86_64/usr/share/wesnoth/ >>> >data/core/images/terrain/tent.png") failed: mode 100644 Macintosh HFS >>> > Extended version 61389 data (unclean) vasprintf failed (Invalid or >>> > incomplete multibyte or wide character) rpmbuild: rpmfc.c:1400: >>> > rpmfcClassify: Assertion `ftype != ((void *)0)' failed. >>> > >>> > >>> > there is either something wrong with that file. or there is a bug in >>> rpm >>> > that >>> > cant deal with it. >>> > >>> > Its not a buildsystem issue. the builds that failed x86_64 and i386 >>> did >>> > not >>> > have anything touching a ppc machine the srpm was build on a x86_64 >>> > machine. >>> > >>> > the ppc builds got cancelled as they were still running. >>> >>> Ok. I thought as much. But why, then does it sometimes work? I did >>> several builds of the 1.4.4 version, and some worked, with no changes >>> to >>> the source. 1.4.5 builds fine for me locally and in mock, on i386. I >>> took a look at that file, and I nothing that distinguishes it from >>> others. >> Building locally in mock on F-9 it builds ok. building in rawhide it >> does >> not. it is quite possible that you have hit a bug in the newer RPM >> > I'll try my own mock build. If it fails the same way, I'll file a bug > against rpm. Slightly different failure in local mock. Bug 462064 filed. > >> Dennis >> >> -- >> fedora-devel-list mailing list >> fedora-devel-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-devel-list >> > > > -- > novus ordo absurdum > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From a.badger at gmail.com Fri Sep 12 14:23:04 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Fri, 12 Sep 2008 07:23:04 -0700 Subject: mass acl opening? In-Reply-To: <48C92FFD.30905@redhat.com> References: <7dd7ab490809102229y51412a3cwe37daeb520bf0a7c@mail.gmail.com> <48C8B476.8040108@ioa.s.u-tokyo.ac.jp> <48C92AED.1000501@gmail.com> <48C92FFD.30905@redhat.com> Message-ID: <48CA7B48.7060207@gmail.com> Casey Dahlin wrote: > Toshio Kuratomi wrote: >> Jason L Tibbitts III wrote: >> >>>>>>>> "MT" == Mamoru Tasaka writes: >>>>>>>> >>> MT> Announced on: >>> MT> >>> https://www.redhat.com/archives/fedora-announce-list/2008-August/msg00007.html >>> >>> >>> Well, yeah, except that the only part of that which is implemented is >>> the rename of "cvsextras" to "packager". Mainly because the big >>> security thing intervened. Currently nobody seems to know when the >>> rest of the process will happen. >>> >>> >> Casey, >> >> Packager infrastructure is pretty much back now, when do you want to >> start the next phase? >> >> -Toshio >> >> >> > We've seeded uberpackager already, and locked out packager, correct? > > I'm good with going ahead asap. > So I took a look at locking out packager and realized we'd talked about several things in this regard. 1) Switching things so uberpackager gets the packager permissions 2) Setting packager to not have permission to commit 3) Locking down the defaults so uberpackager gets permission but packager does not. 4) Changing the UI so packager doesn't show up as a group to give permissions to. These are all ready to go except #4. Entirely my fault. I'm going to be gone today and probably large swathes of the weekend and we're heading into a mini-freeze for the Fedora 10 Beta so rather than destabilize things now, I'd like to delay this until after the freeze. That means, I'll deploy this on our new staging infrastructure and push it live the middle to later part of next week. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From bnocera at redhat.com Fri Sep 12 15:08:45 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Fri, 12 Sep 2008 16:08:45 +0100 Subject: Does your package provide GStreamer plugins? In-Reply-To: <935ead450809120606g2a0a93e2p350d9917417d180e@mail.gmail.com> References: <1221215325.24928.235.camel@cookie.hadess.net> <935ead450809120606g2a0a93e2p350d9917417d180e@mail.gmail.com> Message-ID: <1221232125.24928.268.camel@cookie.hadess.net> On Fri, 2008-09-12 at 08:06 -0500, Jeffrey Ollie wrote: > On Fri, Sep 12, 2008 at 5:28 AM, Bastien Nocera wrote: > > > > If your package provides GStreamer plugins, please rebuild it in rawhide > > with the latest gstreamer-devel and RPM builds. > > > > We are trying to use a PackageKit-based solution to installing missing > > GStreamer plugins. The new GStreamer and RPM packages will add strings > > like this to your RPM's provides: > > gstreamer0.10(urisource-ssh)()(64bit) > > gstreamer0.10(decoder-application/ogg)()(64bit) > > I tried rebuilding schroedinger but I didn't see any new provides show > up. Is there something I'm doing wrong? Here's a scratch build I > just did: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=822502 $ echo /usr/lib64/gstreamer-0.10/libgstschro.so | ./gstreamer.prov gstreamer0.10(encoder-video/x-dirac)()(64bit) gstreamer0.10(decoder-video/x-dirac)()(64bit) gstreamer0.10(decoder-video/x-dirac)()(64bit) I don't get it, the RPM and gstreamer-devel versions are new enough for the provides to work. Panu, could it be RPM not calling the script for sub packages? Cheers From hughsient at gmail.com Fri Sep 12 15:12:14 2008 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 12 Sep 2008 16:12:14 +0100 Subject: Beware: External repos can break key transition In-Reply-To: <48CA73D8.1040902@nobugconsulting.ro> References: <1221158197.6431.24.camel@localhost.localdomain> <48C9721A.6070603@leemhuis.info> <48CA27D7.2080505@leemhuis.info> <1221215159.3284.51.camel@hughsie-work> <48CA73D8.1040902@nobugconsulting.ro> Message-ID: <1221232334.3284.81.camel@hughsie-work> On Fri, 2008-09-12 at 16:51 +0300, Manuel Wolfshant wrote: > > case PK_ERROR_ENUM_FILE_CONFLICTS: > > text = _("Two packages provide the same file.\n" > > "This is usually due to mixing packages for different > software sources."); > > > "for different" or "from different" ? > > > break; > > case PK_ERROR_ENUM_PACKAGE_CONFLICTS: > > text = _("Multiple packages exist that are not compatible with > each other.\n" > > "This is usually due to mixing packages for different > software sources."); > > > same question here... I'm really not sure, my grammar is pretty awful. If somebody (you? :-) could have a look at all the translations and suggest fixes I would be very grateful. Richard. From ssorce at redhat.com Fri Sep 12 15:46:23 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 12 Sep 2008 11:46:23 -0400 Subject: make force-tag gone In-Reply-To: <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809091303.22845.dennis@ausil.us> <1220990257.7986.5.camel@rousalka.okg> <20080910220333.GJ31522@redhat.com> <1221089579.30799.1.camel@rousalka.okg> <20080911184506.GA1486@redhat.com> <48C97287.8040402@poolshark.org> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> <48CA16D1.5070409@redhat.com> <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> Message-ID: <1221234383.15726.194.camel@localhost.localdomain> On Fri, 2008-09-12 at 09:31 -0400, Adam Jackson wrote: > On Fri, 2008-09-12 at 09:14 +0200, Gerd Hoffmann wrote: > > Hi, > > > > > Only CVS needs a revision number per file, and that's > > > exactly what the Entries file contains. > > > > Hmm, wouldn't checkout by date do the trick for cvs? > > Yes, but that's a bit harder to reconstruct after the fact. There's a > potential skew between the notions of "time" between the kojid and the > cvs server; the latter is authoritative, but the former is what gets > recorded in the build output. > > Whereas cvs gives you the Entries file for free, so you might as well > just save it. That and then letting koji set the tag, this way we do not have to mess with tags at all (or we can reserve tags that start with koji- so that devs can't change them while letting devs have their own custom tags if they need them). Simo. -- Simo Sorce * Red Hat, Inc * New York From jkeating at redhat.com Fri Sep 12 15:50:12 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 12 Sep 2008 08:50:12 -0700 Subject: Frozen for Fedora 10 Beta Message-ID: <1221234612.3674.8.camel@luminos.localdomain> As of the rawhide compose last night, we are frozen for Fedora 10. Rawhide will compose from the frozen content so that we all are aware of what Beta is going to be comprised of. Extra scruitiny and testing of rawhide over the next week is greatly appreciated. Builds that you feel need to be in the Beta can be requested via the Release Engineering Trac queue ( https://fedorahosted.org/rel-eng log in using FAS and file a new ticket ). We'll want build n-v-r, rational of accepting the build, and information about any testing you've already done with the build. Lets all work together to make the beta freeze as quick and painless as possible, and the Beta as useful as possible to greater Fedora 10 testing. See https://fedoraproject.org/wiki/ReleaseEngineering/FeatureFreezePolicy for more information. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From opensource at till.name Fri Sep 12 16:14:59 2008 From: opensource at till.name (Till Maas) Date: Fri, 12 Sep 2008 18:14:59 +0200 Subject: Frozen for Fedora 10 Beta In-Reply-To: <1221234612.3674.8.camel@luminos.localdomain> References: <1221234612.3674.8.camel@luminos.localdomain> Message-ID: <200809121815.09979.opensource@till.name> On Fri September 12 2008, Jesse Keating wrote: > As of the rawhide compose last night, we are frozen for Fedora 10. Are the changes from the rawhide report "20080912 changes" included in the frozen content? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From stickster at gmail.com Fri Sep 12 16:14:58 2008 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 12 Sep 2008 16:14:58 +0000 Subject: Beware: External repos can break key transition In-Reply-To: <1221232334.3284.81.camel@hughsie-work> References: <1221158197.6431.24.camel@localhost.localdomain> <48C9721A.6070603@leemhuis.info> <48CA27D7.2080505@leemhuis.info> <1221215159.3284.51.camel@hughsie-work> <48CA73D8.1040902@nobugconsulting.ro> <1221232334.3284.81.camel@hughsie-work> Message-ID: <1221236098.10226.145.camel@localhost.localdomain> On Fri, 2008-09-12 at 16:12 +0100, Richard Hughes wrote: > On Fri, 2008-09-12 at 16:51 +0300, Manuel Wolfshant wrote: > > > case PK_ERROR_ENUM_FILE_CONFLICTS: > > > text = _("Two packages provide the same file.\n" > > > "This is usually due to mixing packages for different > > software sources."); > > > > > "for different" or "from different" ? > > > > > break; > > > case PK_ERROR_ENUM_PACKAGE_CONFLICTS: > > > text = _("Multiple packages exist that are not compatible with > > each other.\n" > > > "This is usually due to mixing packages for different > > software sources."); > > > > > same question here... > > I'm really not sure, my grammar is pretty awful. If somebody (you? :-) > could have a look at all the translations and suggest fixes I would be > very grateful. "From" is correct, or at least preferred here. -- Paul W. Frields ("${LANG} dictator to the rescue!") gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri Sep 12 16:31:45 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 12 Sep 2008 09:31:45 -0700 Subject: Frozen for Fedora 10 Beta In-Reply-To: <200809121815.09979.opensource@till.name> References: <1221234612.3674.8.camel@luminos.localdomain> <200809121815.09979.opensource@till.name> Message-ID: <1221237105.3674.12.camel@luminos.localdomain> On Fri, 2008-09-12 at 18:14 +0200, Till Maas wrote: > Are the changes from the rawhide report "20080912 changes" included in the > frozen content? Yes. 20080912 composed from the freeze tag. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From j.w.r.degoede at hhs.nl Fri Sep 12 18:04:57 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 12 Sep 2008 20:04:57 +0200 Subject: NetworkworkManger and network based filesystem /usr Message-ID: <48CAAF49.3090105@hhs.nl> Hi all, As you know I've started as the newest member of the anaconda team this September. The first thing I've been working on is iSCSI support in the Fedora (master) branch of anaconda. Getting anaconda into shape for iSCSI support is one, but getting the installed system to actually work with anaconda is a different problem altogether. The problem here is that the current default in Fedora is to *always* use NetworkManager to configure the network interfaces. But if you look in /etc/rc.d/rc5.d you will see: S06cpuspeed S07iscsid S08iptables S10network S11auditd S12rsyslog S13iscsi S22messagebus S25fuse S25netfs S26haldaemon S27NetworkManager Note this is with both the old network service as well as NetworkManager enabled which is done just to illustrate things! What you see here is that the old network service started at priority 10, with low priorities starting first, then at 13 iscsi got started and at 25 network filesystems (nfs, iscsi, etc) get fsck-ed (where applicable) and then mounten. Then at 26 hal gets started and at 27 NetworkManager. Now here we have a problem as in the brave new world without the old network service, when iscsi gets started and when netfs tries to mount nfs shares, the network is not configured yet as NetworkManager hasn't been started yet. This can probably best be fixed by moving both hal and NetworkManager earlier and then waiting in iscsi and in netfs (for systems without iscsi but for example nfs) for NetworkManager to complete configuring the network, I already have a patch for the iscsi initscript todo this. But there is a catch, hal and NetworkManager are currently under /usr which could be on a network based fs itself. So hal and NetworkManager will need to be moved to /bin and /lib[64], or alternatively we could declare that installations where /usr is on a different fs then / are not supported (which might be a good thing todo for F-10 and then move hal + NM for F-11). Before I start filing bugs and submitting patches I would like some feedback on this. I would like to end this mail with noting that since we've choosen to move away from the old network scripts to an all NetworkManager based world, that moving hal + NM earlier and to the root fs seems to be the only solution. Regards, Hans From notting at redhat.com Fri Sep 12 18:12:13 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 12 Sep 2008 14:12:13 -0400 Subject: NetworkworkManger and network based filesystem /usr In-Reply-To: <48CAAF49.3090105@hhs.nl> References: <48CAAF49.3090105@hhs.nl> Message-ID: <20080912181213.GA3270@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > What you see here is that the old network service started at priority 10, > with low priorities starting first, then at 13 iscsi got started and at > 25 network filesystems (nfs, iscsi, etc) get fsck-ed (where applicable) > and then mounten. > > Then at 26 hal gets started and at 27 NetworkManager. > > Now here we have a problem as in the brave new world without the old > network service, when iscsi gets started and when netfs tries to mount > nfs shares, the network is not configured yet as NetworkManager hasn't > been started yet. netfs does not start if neither of network or NM has started yet, and is separately started by NM if needed. > But there is a catch, hal and NetworkManager are currently under /usr > which could be on a network based fs itself. So hal and NetworkManager > will need to be moved to /bin and /lib[64], or alternatively we could > declare that installations where /usr is on a different fs then / are not > supported (which might be a good thing todo for F-10 and then move hal + > NM for F-11). Having network /usr and non-network / isn't really practical long term. I'm all for not supporting it. Bill From law at redhat.com Fri Sep 12 18:19:02 2008 From: law at redhat.com (Jeff Law) Date: Fri, 12 Sep 2008 12:19:02 -0600 Subject: NetworkworkManger and network based filesystem /usr In-Reply-To: <20080912181213.GA3270@nostromo.devel.redhat.com> References: <48CAAF49.3090105@hhs.nl> <20080912181213.GA3270@nostromo.devel.redhat.com> Message-ID: <48CAB296.80101@redhat.com> Bill Nottingham wrote: > Hans de Goede (j.w.r.degoede at hhs.nl) said: > >> What you see here is that the old network service started at priority 10, >> with low priorities starting first, then at 13 iscsi got started and at >> 25 network filesystems (nfs, iscsi, etc) get fsck-ed (where applicable) >> and then mounten. >> >> Then at 26 hal gets started and at 27 NetworkManager. >> >> Now here we have a problem as in the brave new world without the old >> network service, when iscsi gets started and when netfs tries to mount >> nfs shares, the network is not configured yet as NetworkManager hasn't >> been started yet. >> > > netfs does not start if neither of network or NM has started yet, and > is separately started by NM if needed. > > >> But there is a catch, hal and NetworkManager are currently under /usr >> which could be on a network based fs itself. So hal and NetworkManager >> will need to be moved to /bin and /lib[64], or alternatively we could >> declare that installations where /usr is on a different fs then / are not >> supported (which might be a good thing todo for F-10 and then move hal + >> NM for F-11). >> > > Having network /usr and non-network / isn't really practical long term. > I'm all for not supporting it. > It must die die die. We're far better off making root filesystems sharable and readonly. jeff From j.w.r.degoede at hhs.nl Fri Sep 12 18:43:05 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 12 Sep 2008 20:43:05 +0200 Subject: NetworkworkManger and network based filesystem /usr In-Reply-To: <20080912181213.GA3270@nostromo.devel.redhat.com> References: <48CAAF49.3090105@hhs.nl> <20080912181213.GA3270@nostromo.devel.redhat.com> Message-ID: <48CAB839.3000305@hhs.nl> Bill Nottingham wrote: > Hans de Goede (j.w.r.degoede at hhs.nl) said: >> What you see here is that the old network service started at priority 10, >> with low priorities starting first, then at 13 iscsi got started and at >> 25 network filesystems (nfs, iscsi, etc) get fsck-ed (where applicable) >> and then mounten. >> >> Then at 26 hal gets started and at 27 NetworkManager. >> >> Now here we have a problem as in the brave new world without the old >> network service, when iscsi gets started and when netfs tries to mount >> nfs shares, the network is not configured yet as NetworkManager hasn't >> been started yet. > > netfs does not start if neither of network or NM has started yet, and > is separately started by NM if needed. > Thats a cool trick, can we teach NM to start iscsi too and do that (and let it complete) before it starts netfs? That would be nicer then my current dbus-send get NM status and sleep while not connected loop in bash. Although I wonder if this (delaying netfs start until NM is done) is a good solution, what if some later service which needs one of the dirs mounted by netfs gets started before NM is done configuring the interfaces? >> But there is a catch, hal and NetworkManager are currently under /usr >> which could be on a network based fs itself. So hal and NetworkManager >> will need to be moved to /bin and /lib[64], or alternatively we could >> declare that installations where /usr is on a different fs then / are not >> supported (which might be a good thing todo for F-10 and then move hal + >> NM for F-11). > > Having network /usr and non-network / isn't really practical long term. > I'm all for not supporting it. What about having both network based, but not the same fs, so say 2 separate nfs exports one for / and one for /usr, that situation will run into similar problems, initrd will do some hackish setup of the network to get the rootfs, but won't mount other network based fs and netfs will not run untill NM is done, so we once more have a catch 22. Regards, Hans From jspaleta at gmail.com Fri Sep 12 18:50:19 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 12 Sep 2008 10:50:19 -0800 Subject: NetworkworkManger and network based filesystem /usr In-Reply-To: <48CAB839.3000305@hhs.nl> References: <48CAAF49.3090105@hhs.nl> <20080912181213.GA3270@nostromo.devel.redhat.com> <48CAB839.3000305@hhs.nl> Message-ID: <604aa7910809121150n52863499r390d5957b2ee2c49@mail.gmail.com> On Fri, Sep 12, 2008 at 10:43 AM, Hans de Goede wrote: > Thats a cool trick, can we teach NM to start iscsi too and do that (and let > it complete) before it starts netfs? look at /etc/NetworkManager/dispatcher.d/ -jef From notting at redhat.com Fri Sep 12 18:51:49 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 12 Sep 2008 14:51:49 -0400 Subject: NetworkworkManger and network based filesystem /usr In-Reply-To: <48CAB839.3000305@hhs.nl> References: <48CAAF49.3090105@hhs.nl> <20080912181213.GA3270@nostromo.devel.redhat.com> <48CAB839.3000305@hhs.nl> Message-ID: <20080912185149.GA5197@nostromo.devel.redhat.com> Hans de Goede (j.w.r.degoede at hhs.nl) said: > Thats a cool trick, can we teach NM to start iscsi too and do that (and > let it complete) before it starts netfs? I'm not sure why we couldn't off the top of my head. > That would be nicer then my current dbus-send get NM status and sleep > while not connected loop in bash. > > Although I wonder if this (delaying netfs start until NM is done) is a > good solution, what if some later service which needs one of the dirs > mounted by netfs gets started before NM is done configuring the > interfaces? What happens to that service if the network cable happens to be down during boot? Services, in general, need to be smarter. If absolutely necessary, they can set NETWORKWAIT in /etc/sysconfig/network. >> Having network /usr and non-network / isn't really practical long term. >> I'm all for not supporting it. > > What about having both network based, but not the same fs, so say 2 > separate nfs exports one for / and one for /usr, that situation will run > into similar problems, initrd will do some hackish setup of the network > to get the rootfs, but won't mount other network based fs and netfs will > not run untill NM is done, so we once more have a catch 22. It's just not a practical setup, IMO. Bill From pjones at redhat.com Fri Sep 12 19:02:09 2008 From: pjones at redhat.com (Peter Jones) Date: Fri, 12 Sep 2008 15:02:09 -0400 Subject: NetworkworkManger and network based filesystem /usr In-Reply-To: <48CAB296.80101@redhat.com> References: <48CAAF49.3090105@hhs.nl> <20080912181213.GA3270@nostromo.devel.redhat.com> <48CAB296.80101@redhat.com> Message-ID: <48CABCB1.6030203@redhat.com> Jeff Law wrote: > Bill Nottingham wrote: >> Hans de Goede (j.w.r.degoede at hhs.nl) said: >>> But there is a catch, hal and NetworkManager are currently under /usr >>> which could be on a network based fs itself. So hal and >>> NetworkManager will need to be moved to /bin and /lib[64], or >>> alternatively we could declare that installations where /usr is on a >>> different fs then / are not supported (which might be a good thing >>> todo for F-10 and then move hal + NM for F-11). >>> >> >> Having network /usr and non-network / isn't really practical long term. >> I'm all for not supporting it. >> > It must die die die. We're far better off making root filesystems > sharable and readonly. I'm not necessarily against stopping supporting this, but it does mean that upgrading won't work on some systems. And it means that "yum upgrading" will fail /catastrophically/ on those machines. -- Peter I was born not knowing and have had only a little time to change that here and there. -- Feynman From notting at redhat.com Fri Sep 12 19:05:31 2008 From: notting at redhat.com (Bill Nottingham) Date: Fri, 12 Sep 2008 15:05:31 -0400 Subject: NetworkworkManger and network based filesystem /usr In-Reply-To: <48CABCB1.6030203@redhat.com> References: <48CAAF49.3090105@hhs.nl> <20080912181213.GA3270@nostromo.devel.redhat.com> <48CAB296.80101@redhat.com> <48CABCB1.6030203@redhat.com> Message-ID: <20080912190531.GB5649@nostromo.devel.redhat.com> Peter Jones (pjones at redhat.com) said: > I'm not necessarily against stopping supporting this, but it does mean > that upgrading won't work on some systems. And it means that "yum > upgrading" will fail /catastrophically/ on those machines. How so, if yum upgrades don't switch you from network -> NM? (yet) Bill From limb at jcomserv.net Fri Sep 12 19:14:51 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 12 Sep 2008 14:14:51 -0500 (CDT) Subject: NetworkworkManger and network based filesystem /usr In-Reply-To: <20080912190531.GB5649@nostromo.devel.redhat.com> References: <48CAAF49.3090105@hhs.nl> <20080912181213.GA3270@nostromo.devel.redhat.com> <48CAB296.80101@redhat.com> <48CABCB1.6030203@redhat.com> <20080912190531.GB5649@nostromo.devel.redhat.com> Message-ID: <27354.198.175.55.5.1221246891.squirrel@mail.jcomserv.net> > Peter Jones (pjones at redhat.com) said: >> I'm not necessarily against stopping supporting this, but it does mean >> that upgrading won't work on some systems. And it means that "yum >> upgrading" will fail /catastrophically/ on those machines. Which would be bad, IMHO and should be avoided. > How so, if yum upgrades don't switch you from network -> NM? (yet) Please tell me there are no plans to do this. . .what's next, migrating people from sendmail to postfix? > Bill > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From janina at rednote.net Fri Sep 12 19:43:02 2008 From: janina at rednote.net (Janina Sajka) Date: Fri, 12 Sep 2008 15:43:02 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> Message-ID: <20080912194302.GA4421@sonata.rednote.net> Arthur Pemberton writes: > I have a lot of seemingly pulse audio related issues on my F9 desktop. > Since I really like the idea behind Pulseaudio, I would like to see > these get sorted out, and would like to know how I can help in terms > of providing useful information. > Well, let me step up to say that I feel the same way. Pulse Audio holds great promise for accessibility, but it ain't working out in practice yet. And, some of us are scratching our heads as to how we get from here to there. The problems we have right now are sufficiently sever to be showstoppers. At the SpeakupModified.Org we recommend disabling pulseaudio. As things stand in F-9, one gets no audio until after a user logs in on the GUI. So, how are those who need screen reader support supposed to use the a11y features of GDM? As it stands, there seems no way to get console audio without that GUI login. Also a nonstarter in the screen reader user community. It seems a useful initial step toward resolution is to run pulseaudio as a system daemon, via an init script, /sbin/service, /sbin/chkconfig. The trade-offs vs the per user model that F-9 employs are probably more than acceptable to most a11y users. So, let me simply ask ... Has anyone a working init script for pulseaudio as a system daemon? Anything close that we could continue to refine as an alternative configuration option for Fedora? Janina Janina Sajka, Phone: +1.202.595.7777; sip:janina at a11y.org Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada Learn more at http://ScreenlessPhone.Com Chair, Open Accessibility janina at a11y.org Linux Foundation http://a11y.org From walters at verbum.org Fri Sep 12 19:46:11 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 12 Sep 2008 15:46:11 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080912194302.GA4421@sonata.rednote.net> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: On Fri, Sep 12, 2008 at 3:43 PM, Janina Sajka wrote: > > The problems we have right now are sufficiently sever to be > showstoppers. At the SpeakupModified.Org we recommend disabling > pulseaudio. As things stand in F-9, one gets no audio until after a user > logs in on the GUI. So, how are those who need screen reader support > supposed to use the a11y features of GDM? As it stands, there seems no > way to get console audio without that GUI login. Also a nonstarter in > the screen reader user community. If you want to run terminal applications, can't you just log in to a full screen gnome-terminal? > It seems a useful initial step toward resolution is to run pulseaudio > as a system daemon, via an init script, /sbin/service, /sbin/chkconfig. > The trade-offs vs the per user model that F-9 employs are probably more > than acceptable to most a11y users. > > So, let me simply ask ... Has anyone a working init script for > pulseaudio as a system daemon? Anything close that we could continue to > refine as an alternative configuration option for Fedora? We're going to be removing the legacy non-X system consoles by default in the long run. From walters at verbum.org Fri Sep 12 19:48:17 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 12 Sep 2008 15:48:17 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <544eb990809110940j26d828ady63bc91e3c50cca3d@mail.gmail.com> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <544eb990809110414x44c1c563l7d0da7859c166780@mail.gmail.com> <16de708d0809110814l6eda770ey54db2073391e0511@mail.gmail.com> <544eb990809110940j26d828ady63bc91e3c50cca3d@mail.gmail.com> Message-ID: On Thu, Sep 11, 2008 at 12:40 PM, Bill Crawford wrote: > > If you have multi-channel hardware that mixes itself, then using > PulseAudio sort of defeats the purpose of that hardware ;o) Such hardware is as far as I understand it, really no longer sold and has not been for some time, because it just makes more sense to do in software. From cry_regarder at yahoo.com Fri Sep 12 19:22:36 2008 From: cry_regarder at yahoo.com (Cry) Date: Fri, 12 Sep 2008 19:22:36 +0000 (UTC) Subject: SIGs/SciTech/SAGE progress? Message-ID: Are there any status updates on building SAGE^3 into fedora?^1 I've been looking at the PCLinuxOS rpms. As it stands SAGE depends on kash which has a strange license. Another issue is that the software bundles many other packages against the fedora tradition. Thanks, 1: http://fedoraproject.org/wiki/SIGs/SciTech/SAGE 2: http://rpm.pbone.net/index.php3/stat/3/srodzaj/2/search/sage-3.0.3-1pclos2007.src.rpm 3: http://sagemath.org From j.w.r.degoede at hhs.nl Fri Sep 12 19:54:08 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 12 Sep 2008 21:54:08 +0200 Subject: NetworkworkManger and network based filesystem /usr In-Reply-To: <20080912185149.GA5197@nostromo.devel.redhat.com> References: <48CAAF49.3090105@hhs.nl> <20080912181213.GA3270@nostromo.devel.redhat.com> <48CAB839.3000305@hhs.nl> <20080912185149.GA5197@nostromo.devel.redhat.com> Message-ID: <48CAC8E0.6030109@hhs.nl> Bill Nottingham wrote: > Hans de Goede (j.w.r.degoede at hhs.nl) said: >> Thats a cool trick, can we teach NM to start iscsi too and do that (and >> let it complete) before it starts netfs? > > I'm not sure why we couldn't off the top of my head. > >> That would be nicer then my current dbus-send get NM status and sleep >> while not connected loop in bash. >> >> Although I wonder if this (delaying netfs start until NM is done) is a >> good solution, what if some later service which needs one of the dirs >> mounted by netfs gets started before NM is done configuring the >> interfaces? > > What happens to that service if the network cable happens to be down > during boot? Services, in general, need to be smarter. If absolutely > necessary, they can set NETWORKWAIT in /etc/sysconfig/network. > I agree, but the chances of a network cable being non functional in some datacenter using iscsi is small, the chances of getting caught by the race condition I described are probably bigger. Note as said I agree with you, but at the same time I try to play devils advocate here. If we are going to make a list of (crazy) unsupported configurations, I'm all for it, but we do need write really good release notes for this then. Then again I think F-9 has this bug too as that defaults to NM too, and I don't know how much bugs regarding this we've gotten. >>> Having network /usr and non-network / isn't really practical long term. >>> I'm all for not supporting it. >> What about having both network based, but not the same fs, so say 2 >> separate nfs exports one for / and one for /usr, that situation will run >> into similar problems, initrd will do some hackish setup of the network >> to get the rootfs, but won't mount other network based fs and netfs will >> not run untill NM is done, so we once more have a catch 22. > > It's just not a practical setup, IMO. > Agreed, but again I'm playing devils advocate. Anyways there seems to be some consensus that having /usr seperate from / is a somewhat archaic usecase we which we do not necessarily want to support. So for now I'll go and write patches for delay iscsi start when using NetworkManager, just like netfs currently is started delayed. Regards, Hans From dcantrell at redhat.com Fri Sep 12 20:17:56 2008 From: dcantrell at redhat.com (David Cantrell) Date: Fri, 12 Sep 2008 10:17:56 -1000 Subject: change isdn4k-utils to optional Message-ID: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> A random sampling of users at FUDCon Brno 2008 showed that ISDN isn't really in use as much in Europe as previously thought. When I asked people at FUDCon, I was met with laughter, much like when you talk about ISDN in the United States. Are there any places out there still where ISDN is still more deployed than PPP dial-ups or DSL? Please comment on https://bugzilla.redhat.com/show_bug.cgi?id=462126 Thanks, -- David Cantrell Red Hat / Honolulu, HI From kzak at redhat.com Fri Sep 12 20:28:13 2008 From: kzak at redhat.com (Karel Zak) Date: Fri, 12 Sep 2008 22:28:13 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: <20080912202813.GL6092@nb.net.home> On Fri, Sep 12, 2008 at 03:46:11PM -0400, Colin Walters wrote: > On Fri, Sep 12, 2008 at 3:43 PM, Janina Sajka wrote: > > > > The problems we have right now are sufficiently sever to be > > showstoppers. At the SpeakupModified.Org we recommend disabling > > pulseaudio. As things stand in F-9, one gets no audio until after a user > > logs in on the GUI. So, how are those who need screen reader support > > supposed to use the a11y features of GDM? As it stands, there seems no > > way to get console audio without that GUI login. Also a nonstarter in > > the screen reader user community. > > If you want to run terminal applications, can't you just log in to a > full screen gnome-terminal? He wants to use audio before login to X Window. Somehow I don't understand how do you want to fix this problem by gnome-terminal... > > It seems a useful initial step toward resolution is to run pulseaudio > > as a system daemon, via an init script, /sbin/service, /sbin/chkconfig. > > The trade-offs vs the per user model that F-9 employs are probably more > > than acceptable to most a11y users. > > > > So, let me simply ask ... Has anyone a working init script for > > pulseaudio as a system daemon? Anything close that we could continue to > > refine as an alternative configuration option for Fedora? > > We're going to be removing the legacy non-X system consoles by default > in the long run. Yeah, we need more RAM for our hungry GUI applications :-) Karel -- Karel Zak From loganjerry at gmail.com Fri Sep 12 20:29:34 2008 From: loganjerry at gmail.com (Jerry James) Date: Fri, 12 Sep 2008 14:29:34 -0600 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: <870180fe0809121329w6f74ebdcj4280ca4d3f12c907@mail.gmail.com> On Fri, Sep 12, 2008 at 1:46 PM, Colin Walters wrote: > If you want to run terminal applications, can't you just log in to a > full screen gnome-terminal? I got the impression that Janina was talking about those who need audio to be able to login in the first place. > We're going to be removing the legacy non-X system consoles by default > in the long run. Those have been useful to me in a lot of circumstances that I don't see going away anytime soon. Here are a few just off the top of my head. 1. It's late. I'm tired. I log out, then remember some small system administration task I meant to do. Rather than wait for all the GUI stuff to reload as I log back in, it is much faster to switch to a text console, login there, do my task, then log back out. 2. I'm playing some game that runs at a low resolution and it crashes. I don't know why, but my mouse is almost always nonfunctional afterwards. When my desktop is at 320x200 and I can't use the mouse, regaining control is difficult. I often switch to a text console so I can clean up some running programs in a nice way before I Ctrl-Alt-Backspace to get my X back. (I have this happen quite often with one particular game that my 9 year old likes. I'd run it in GDB so I can get a backtrace and file a proper bug report, except when it crashes I can't SEE the backtrace because my screen is at 320x200 and my mouse is dead. Argh!) 3. I launch some X program that consumes 100% CPU and is clearly out of control. In those cases, the mouse becomes sluggish. It can take a very long time to either launch a gnome-terminal or get the mouse over a gnome-terminal so I can click on it, have the click actually move the focus to that window, type the command to kill the process, have the typed text actually show up on the gnome-terminal, press the Enter key, then wait the shell to process the command. It is MUCH faster to switch to a text console, login, kill the process, logout, and switch back to X. Once you can guarantee that X programs won't consume 100% CPU or crash while in a different screen resolution from my desktop, and can guarantee that logging into an X session is below the human time perception threshold, then I'll be ready to give up text consoles. Until then, I want them. -- Jerry James http://loganjerry.googlepages.com/ From cra at WPI.EDU Fri Sep 12 20:30:36 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 12 Sep 2008 16:30:36 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080912202813.GL6092@nb.net.home> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <20080912202813.GL6092@nb.net.home> Message-ID: <20080912203036.GN32741@angus.ind.WPI.EDU> On Fri, Sep 12, 2008 at 10:28:13PM +0200, Karel Zak wrote: > On Fri, Sep 12, 2008 at 03:46:11PM -0400, Colin Walters wrote: > > If you want to run terminal applications, can't you just log in to a > > full screen gnome-terminal? > > He wants to use audio before login to X Window. Somehow I don't understand > how do you want to fix this problem by gnome-terminal... Audio works on the GDM login screen. Orca starts and reads the login window to me... From pjones at redhat.com Fri Sep 12 20:34:58 2008 From: pjones at redhat.com (Peter Jones) Date: Fri, 12 Sep 2008 16:34:58 -0400 Subject: NetworkworkManger and network based filesystem /usr In-Reply-To: <20080912190531.GB5649@nostromo.devel.redhat.com> References: <48CAAF49.3090105@hhs.nl> <20080912181213.GA3270@nostromo.devel.redhat.com> <48CAB296.80101@redhat.com> <48CABCB1.6030203@redhat.com> <20080912190531.GB5649@nostromo.devel.redhat.com> Message-ID: <48CAD272.1010604@redhat.com> Bill Nottingham wrote: > Peter Jones (pjones at redhat.com) said: >> I'm not necessarily against stopping supporting this, but it does mean >> that upgrading won't work on some systems. And it means that "yum >> upgrading" will fail /catastrophically/ on those machines. > > How so, if yum upgrades don't switch you from network -> NM? (yet) Yeah, if we're not doing that then it should be ok for this particular problem; though in general we still need to be careful about this. -- Peter Growth for the sake of growth is the ideology of the cancer cell. From walters at verbum.org Fri Sep 12 20:42:57 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 12 Sep 2008 16:42:57 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080912203036.GN32741@angus.ind.WPI.EDU> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <20080912202813.GL6092@nb.net.home> <20080912203036.GN32741@angus.ind.WPI.EDU> Message-ID: On Fri, Sep 12, 2008 at 4:30 PM, Chuck Anderson wrote: > On Fri, Sep 12, 2008 at 10:28:13PM +0200, Karel Zak wrote: >> On Fri, Sep 12, 2008 at 03:46:11PM -0400, Colin Walters wrote: >> > If you want to run terminal applications, can't you just log in to a >> > full screen gnome-terminal? >> >> He wants to use audio before login to X Window. Somehow I don't understand >> how do you want to fix this problem by gnome-terminal... > > Audio works on the GDM login screen. Orca starts and reads the login > window to me... Exactly; the GDM team did a lot of work over the last two cycles to make GDM fully accessible. From walters at verbum.org Fri Sep 12 21:06:01 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 12 Sep 2008 17:06:01 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <870180fe0809121329w6f74ebdcj4280ca4d3f12c907@mail.gmail.com> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <870180fe0809121329w6f74ebdcj4280ca4d3f12c907@mail.gmail.com> Message-ID: On Fri, Sep 12, 2008 at 4:29 PM, Jerry James wrote: > On Fri, Sep 12, 2008 at 1:46 PM, Colin Walters wrote: >> If you want to run terminal applications, can't you just log in to a >> full screen gnome-terminal? > > I got the impression that Janina was talking about those who need > audio to be able to login in the first place. Probably both. In any case, our answer is GDM and gnome-terminal. > Those have been useful to me in a lot of circumstances that I don't > see going away anytime soon. Here are a few just off the top of my > head. > > 1. It's late. I'm tired. I log out, then remember some small system > administration task I meant to do. Rather than wait for all the GUI > stuff to reload as I log back in, it is much faster to switch to a > text console, login there, do my task, then log back out. "Login is slow" - something we know about and makes sense to fix, rather than having an entirely different way to log in. Another answer is that if you hold down a magic key sequence (say Ctrl-Shift-t) then you get just gnome-terminal. > 2. I'm playing some game that runs at a low resolution and it crashes. > I don't know why, but my mouse is almost always nonfunctional > afterwards. When my desktop is at 320x200 and I can't use the mouse, > regaining control is difficult. I often switch to a text console so I > can clean up some running programs in a nice way before I > Ctrl-Alt-Backspace to get my X back. First, fix the app. Second, invest some in making the system robust against applications that crash. Third, land http://fedoraproject.org/wiki/Features/CrashHandling so you don't need to use GDB manually. > 3. I launch some X program that consumes 100% CPU and is clearly out > of control. In those cases, the mouse becomes sluggish. It can take > a very long time to either launch a gnome-terminal or get the mouse > over a gnome-terminal so I can click on it, have the click actually > move the focus to that window, type the command to kill the process, > have the typed text actually show up on the gnome-terminal, press the > Enter key, then wait the shell to process the command. It is MUCH > faster to switch to a text console, login, kill the process, logout, > and switch back to X. I don't see that problem here with an app just burning a core. Now if you're in swap, obviously that's a whole other issue. From mw_triad at users.sourceforge.net Fri Sep 12 21:59:58 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 12 Sep 2008 16:59:58 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: Colin Walters wrote: > We're going to be removing the legacy non-X system consoles by default > in the long run. Um... what happens then when X is broken? -- Matthew What? This signature /again/? From cweyl at alumni.drew.edu Fri Sep 12 22:11:50 2008 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Fri, 12 Sep 2008 15:11:50 -0700 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: <7dd7ab490809121511x300c2a71q9d803ff57f1f22a4@mail.gmail.com> On Fri, Sep 12, 2008 at 12:46 PM, Colin Walters wrote: > On Fri, Sep 12, 2008 at 3:43 PM, Janina Sajka wrote: >> It seems a useful initial step toward resolution is to run pulseaudio >> as a system daemon, via an init script, /sbin/service, /sbin/chkconfig. >> The trade-offs vs the per user model that F-9 employs are probably more >> than acceptable to most a11y users. >> >> So, let me simply ask ... Has anyone a working init script for >> pulseaudio as a system daemon? Anything close that we could continue to >> refine as an alternative configuration option for Fedora? > > We're going to be removing the legacy non-X system consoles by default > in the long run. On a related note, here we get to my pet bug, too: 444172. I often use my desktop with one X session to the machine itself, and another X session remotely logged in to my work laptop via XDMCP. However, the per-user model means that not only can I not use PA on the laptop to play over the desktop's speakers, but I can't continue to play anything through the first X session. https://bugzilla.redhat.com/show_bug.cgi?id=444172 (It's filed under ConsoleKit, as that seemed to be where the problem was. I'm more than happy to reassign it if that makes sense :)) -Chris -- Chris Weyl Ex astris, scientia From lesmikesell at gmail.com Fri Sep 12 22:11:54 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 12 Sep 2008 17:11:54 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <870180fe0809121329w6f74ebdcj4280ca4d3f12c907@mail.gmail.com> Message-ID: <48CAE92A.4060705@gmail.com> Colin Walters wrote: > >> Those have been useful to me in a lot of circumstances that I don't >> see going away anytime soon. Here are a few just off the top of my >> head. >> > "Login is slow" - something we know about and makes sense to fix, > rather than having an entirely different way to log in. How about 'starting X doesn't work'? Or can you guarantee that won't ever happen again? And what about servers that don't need any X programs? Or where essentially all access is through ssh, remote X sessions, and freenx/NX? -- Les Mikesell lesmikesell at gmail.com From walters at verbum.org Fri Sep 12 22:16:13 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 12 Sep 2008 18:16:13 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: On Fri, Sep 12, 2008 at 5:59 PM, Matthew Woehlke wrote: > Colin Walters wrote: >> >> We're going to be removing the legacy non-X system consoles by default >> in the long run. > > Um... what happens then when X is broken? What happens when the linux kernel is broken? What happens when /bin/sh is broken? What happens when NetworkManager is broken? You fix the bug. Also, one thing I would like to see Fedora install by default is a compressed recovery image, rather than just multiple kernels. From pemboa at gmail.com Fri Sep 12 22:19:21 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 12 Sep 2008 17:19:21 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: <16de708d0809121519q4cd4c79cod5bf6ab45c13a0e4@mail.gmail.com> On Fri, Sep 12, 2008 at 5:16 PM, Colin Walters wrote: > On Fri, Sep 12, 2008 at 5:59 PM, Matthew Woehlke > wrote: >> Colin Walters wrote: >>> >>> We're going to be removing the legacy non-X system consoles by default >>> in the long run. >> >> Um... what happens then when X is broken? > > What happens when the linux kernel is broken? What happens when > /bin/sh is broken? What happens when NetworkManager is broken? You > fix the bug. I think you misunderstand? X being broken isn't always a bug. It can simply be a configuration issue. How is one suppose to fix a config issue with X in this scenario? -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From lesmikesell at gmail.com Fri Sep 12 22:24:58 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 12 Sep 2008 17:24:58 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: <48CAEC3A.3030808@gmail.com> Colin Walters wrote: > On Fri, Sep 12, 2008 at 5:59 PM, Matthew Woehlke > wrote: >> Colin Walters wrote: >>> We're going to be removing the legacy non-X system consoles by default >>> in the long run. >> Um... what happens then when X is broken? > > What happens when the linux kernel is broken? What happens when > /bin/sh is broken? What happens when NetworkManager is broken? You > fix the bug. > Errr, when the kernel or shell are broken you don't run at all until you fix them. When X isn't running, you run faster and more efficiently. -- Les Mikesell lesmikesell at gmail.com From pemboa at gmail.com Fri Sep 12 22:19:21 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 12 Sep 2008 17:19:21 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: <16de708d0809121519q4cd4c79cod5bf6ab45c13a0e4@mail.gmail.com> On Fri, Sep 12, 2008 at 5:16 PM, Colin Walters wrote: > On Fri, Sep 12, 2008 at 5:59 PM, Matthew Woehlke > wrote: >> Colin Walters wrote: >>> >>> We're going to be removing the legacy non-X system consoles by default >>> in the long run. >> >> Um... what happens then when X is broken? > > What happens when the linux kernel is broken? What happens when > /bin/sh is broken? What happens when NetworkManager is broken? You > fix the bug. I think you misunderstand? X being broken isn't always a bug. It can simply be a configuration issue. How is one suppose to fix a config issue with X in this scenario? -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From mw_triad at users.sourceforge.net Fri Sep 12 22:36:20 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 12 Sep 2008 17:36:20 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: Colin Walters wrote: > On Fri, Sep 12, 2008 at 5:59 PM, Matthew Woehlke > wrote: >> Colin Walters wrote: >>> We're going to be removing the legacy non-X system consoles by default >>> in the long run. >> Um... what happens then when X is broken? > > What happens when the linux kernel is broken? ...then you boot from a disk with a bootable kernel. > What happens when /bin/sh is broken? Hmm... then you probably need a rescue disk to replace /bin/sh. > What happens when NetworkManager is broken? You fix it :-). You've degenerated from errors that result in an unusable system (meaning: cannot boot to a command prompt from which, at the least, basic repair tools are available) to errors that are potentially mere annoyances. Let's go back to my question: >> What happens when X is broken? Then you boot in non-X mode. Oh, wait. You want to remove non-X mode. You want me to have to go find a rescue disk, just because 'yum update nvidia' wasn't such a good idea? No, thanks; I'd rather have X fail to start and dump me at a normal console from which I can fix the problem *without rebooting*, much less needing to dig up a rescue disk :P. Currently non-functioning X is like non-functioning network; annoying, but not crippling (kernel still works, shell still works, still possible to run commands, do debugging, etc., without rebooting or a rescue disk). You're proposing to make it a system-crippling problem. I will suggest that making a known-fragile component *required* for a functional system, including any chance of repair (short of a rescue disk), is the worst idea I've heard in a while. (But I /have/ heard it before. It's called "Windows". YTH do we want to copy /that/?) ...not to mention that X is bloated and completely unneeded overhead on servers. Even Microsoft realizes this; I hear 2008 has a non-GUI mode for exactly this reason. > Also, one thing I would like to see Fedora install by default is a > compressed recovery image, rather than just multiple kernels. That would help, but would still require rebooting all the time until X is working (anyone say "PITA"?). Currently, "bad kernel" is the only situation that needs a reboot to test if it works. (Well, non-working /bin/sh depends on why it is non-working; if it's a bad binary, you can try to run it as a subshell, so no reboot needed. If it's an interaction with other bits of the system, it might fall into the 'needs reboot to test' category. But non-working X currently is comfortably NOT in the 'needs reboot' category.) -- Matthew What? This signature /again/? From walters at verbum.org Fri Sep 12 22:52:13 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 12 Sep 2008 18:52:13 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: On Fri, Sep 12, 2008 at 6:36 PM, Matthew Woehlke wrote: > No, > thanks; I'd rather have X fail to start and dump me at a normal console from > which I can fix the problem *without rebooting*, much less needing to dig up > a rescue disk :P. I believe we already do that today, and am not advocating removing that functionality if possible. Anyways, I've said what I need to, so hopefully people won't be surprised later. From pemboa at gmail.com Fri Sep 12 22:59:31 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 12 Sep 2008 17:59:31 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> On Fri, Sep 12, 2008 at 5:52 PM, Colin Walters wrote: > On Fri, Sep 12, 2008 at 6:36 PM, Matthew Woehlke > wrote: > >> No, >> thanks; I'd rather have X fail to start and dump me at a normal console from >> which I can fix the problem *without rebooting*, much less needing to dig up >> a rescue disk :P. > > I believe we already do that today, and am not advocating removing > that functionality if possible. Anyways, I've said what I need to, so > hopefully people won't be surprised later. I'm confused. Is Fedora really going to remove non X consoles? -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From walters at verbum.org Fri Sep 12 23:02:16 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 12 Sep 2008 19:02:16 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> Message-ID: On Fri, Sep 12, 2008 at 6:59 PM, Arthur Pemberton wrote: > On Fri, Sep 12, 2008 at 5:52 PM, Colin Walters wrote: >> On Fri, Sep 12, 2008 at 6:36 PM, Matthew Woehlke >> wrote: >> >>> No, >>> thanks; I'd rather have X fail to start and dump me at a normal console from >>> which I can fix the problem *without rebooting*, much less needing to dig up >>> a rescue disk :P. >> >> I believe we already do that today, and am not advocating removing >> that functionality if possible. Anyways, I've said what I need to, so >> hopefully people won't be surprised later. > > > I'm confused. Is Fedora really going to remove non X consoles? I'm talking about the direction and technology of the desktop product; what server images, embedded etc. do is an entirely different matter. From pemboa at gmail.com Fri Sep 12 23:05:41 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 12 Sep 2008 18:05:41 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> Message-ID: <16de708d0809121605q643a304et42396074d6598ec3@mail.gmail.com> On Fri, Sep 12, 2008 at 6:02 PM, Colin Walters wrote: > On Fri, Sep 12, 2008 at 6:59 PM, Arthur Pemberton wrote: >> On Fri, Sep 12, 2008 at 5:52 PM, Colin Walters wrote: >>> On Fri, Sep 12, 2008 at 6:36 PM, Matthew Woehlke >>> wrote: >>> >>>> No, >>>> thanks; I'd rather have X fail to start and dump me at a normal console from >>>> which I can fix the problem *without rebooting*, much less needing to dig up >>>> a rescue disk :P. >>> >>> I believe we already do that today, and am not advocating removing >>> that functionality if possible. Anyways, I've said what I need to, so >>> hopefully people won't be surprised later. >> >> >> I'm confused. Is Fedora really going to remove non X consoles? > > I'm talking about the direction and technology of the desktop product; > what server images, embedded etc. do is an entirely different matter. What is the proper procedure for adding input to this decision? -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From walters at verbum.org Fri Sep 12 23:10:16 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 12 Sep 2008 19:10:16 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <16de708d0809121605q643a304et42396074d6598ec3@mail.gmail.com> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <16de708d0809121605q643a304et42396074d6598ec3@mail.gmail.com> Message-ID: On Fri, Sep 12, 2008 at 7:05 PM, Arthur Pemberton wrote: > > What is the proper procedure for adding input to this decision? You are now! There is plenty to figure out (like the recovery scenarios) and finish, and so any help is appreciated. From mw_triad at users.sourceforge.net Fri Sep 12 23:22:07 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 12 Sep 2008 18:22:07 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: Colin Walters wrote: > On Fri, Sep 12, 2008 at 6:36 PM, Matthew Woehlke > wrote: > >> No, >> thanks; I'd rather have X fail to start and dump me at a normal console from >> which I can fix the problem *without rebooting*, much less needing to dig up >> a rescue disk :P. > > I believe we already do that today, and am not advocating removing > that functionality if possible. Right. If X doesn't work, we currently fall back on non-X consoles. You said earlier: > We're going to be removing the legacy non-X system consoles by default > in the long run. ...which would cause a problem there. Maybe we're simply miscommunicating. Did you mean "we are going to arrange so that you never see a non-X console unless you a: ask for one (ctrl-alt-fX) or b: something goes wrong"? That's not how I read that the first time (now, I'm simply unsure what you meant). If that's the case, cool, forget what I said :-). Just so long as those "legacy non-X consoles" don't cease to exist, I've no gripes making them as hidden as you like for people that don't go looking for them. -- Matthew What? This signature /again/? From kzak at redhat.com Sat Sep 13 00:34:19 2008 From: kzak at redhat.com (Karel Zak) Date: Sat, 13 Sep 2008 02:34:19 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> Message-ID: <20080913003419.GM6092@nb.net.home> On Fri, Sep 12, 2008 at 07:02:16PM -0400, Colin Walters wrote: > On Fri, Sep 12, 2008 at 6:59 PM, Arthur Pemberton wrote: > > On Fri, Sep 12, 2008 at 5:52 PM, Colin Walters wrote: > >> On Fri, Sep 12, 2008 at 6:36 PM, Matthew Woehlke > >> wrote: > >> > >>> No, > >>> thanks; I'd rather have X fail to start and dump me at a normal console from > >>> which I can fix the problem *without rebooting*, much less needing to dig up > >>> a rescue disk :P. > >> > >> I believe we already do that today, and am not advocating removing > >> that functionality if possible. Anyways, I've said what I need to, so > >> hopefully people won't be surprised later. > > > > > > I'm confused. Is Fedora really going to remove non X consoles? > > I'm talking about the direction and technology of the desktop product; What is reason for this "direction"? I still don't see any technical reason. What is wrong with mingetty(8)? BTW, "We're going to remove..." -- who is "We"? Karel -- Karel Zak From dr.diesel at gmail.com Sat Sep 13 00:43:03 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 12 Sep 2008 20:43:03 -0400 Subject: Today's (9/12) rawhide all users = unable to authenticate user! Message-ID: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> Booting normally to GDM, using normal root login gives me unable to authenticate user. If I boot to init3, my user/pass works just fine, then I can startx. I attempted passwd and reset my pass with no luck! Anybody else? Should I file this under GDM? -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From darrellpf at gmail.com Sat Sep 13 00:47:53 2008 From: darrellpf at gmail.com (darrell pfeifer) Date: Fri, 12 Sep 2008 17:47:53 -0700 Subject: Today's (9/12) rawhide all users = unable to authenticate user! In-Reply-To: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> Message-ID: 2008/9/12 Dr. Diesel > Booting normally to GDM, using normal root login gives me unable to > authenticate user. If I boot to init3, my user/pass works just fine, then I > can startx. I attempted passwd and reset my pass with no luck! > > Anybody else? Should I file this under GDM? > The gdm changelog says * Tue Sep 09 2008 Jon McCann - 1:2.23.92-2 - Disallow root login So it is intentional darrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From dr.diesel at gmail.com Sat Sep 13 00:50:58 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 12 Sep 2008 20:50:58 -0400 Subject: Today's (9/12) rawhide all users = unable to authenticate user! In-Reply-To: References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> Message-ID: <2a28d2ab0809121750t6ce72fe6pf3d7085a97d3fe16@mail.gmail.com> 2008/9/12 darrell pfeifer > > > 2008/9/12 Dr. Diesel > >> Booting normally to GDM, using normal root login gives me unable to >> authenticate user. If I boot to init3, my user/pass works just fine, then I >> can startx. I attempted passwd and reset my pass with no luck! >> >> Anybody else? Should I file this under GDM? >> > > The gdm changelog says > > * Tue Sep 09 2008 Jon McCann - 1:2.23.92-2 > > - Disallow root login > > So it is intentional > > darrell > Wow, maybe a change of output, to something like "Root login disabled" Interesting property to suddenly change? Thanks -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From skvidal at fedoraproject.org Sat Sep 13 01:27:19 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 12 Sep 2008 21:27:19 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> Message-ID: <1221269239.3076.41.camel@rosebud> On Fri, 2008-09-12 at 19:02 -0400, Colin Walters wrote: > I'm talking about the direction and technology of the desktop product; > what server images, embedded etc. do is an entirely different matter. Desktop Product? We don't make a desktop product. We make a linux distribution. What "Desktop Product" are you talking about? -sv From walters at verbum.org Sat Sep 13 01:39:32 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 12 Sep 2008 21:39:32 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1221269239.3076.41.camel@rosebud> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <1221269239.3076.41.camel@rosebud> Message-ID: On Fri, Sep 12, 2008 at 9:27 PM, Seth Vidal wrote: > On Fri, 2008-09-12 at 19:02 -0400, Colin Walters wrote: > >> I'm talking about the direction and technology of the desktop product; >> what server images, embedded etc. do is an entirely different matter. > > > Desktop Product? We don't make a desktop product. The live CD image, combined with the default comps tree from "gnome-desktop" is what I consider the desktop product. > We make a linux > distribution. I am certainly not here to make a "linux distribution", which I consider a derogatory term. It implies that all we do is take the linux kernel and a bunch of tarballs we found on the internet, compile them, and throw the binaries over the wall. The goal is rather to make a compelling and useful free desktop operating system. To do that, you need to make choices about how the operating system works, and how pieces fit together. If people want an OS that tries to support every possible configuration of every tarball that can be found on the Internet, and is consequently near-paralyzed by choice and is only able to make releases every 5 years, debian.org is --> that way. From janina at rednote.net Sat Sep 13 01:57:52 2008 From: janina at rednote.net (Janina Sajka) Date: Fri, 12 Sep 2008 21:57:52 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080912203036.GN32741@angus.ind.WPI.EDU> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <20080912202813.GL6092@nb.net.home> <20080912203036.GN32741@angus.ind.WPI.EDU> Message-ID: <20080913015752.GB4421@sonata.rednote.net> Chuck Anderson writes: > > Audio works on the GDM login screen. Orca starts and reads the login > window to me... What Fedora? And, what GDM? This worked, hmm, perhaps 60-70% for me back in Fedora 8. But GDM has gone through a massive rewrite since then. None of the users I'm in touch with have gotten this to work on F-9 or later. So, please share the magic if you know something we don't. Janina > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka, Phone: +1.202.595.7777; sip:janina at a11y.org Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada Learn more at http://ScreenlessPhone.Com Chair, Open Accessibility janina at a11y.org Linux Foundation http://a11y.org From janina at rednote.net Sat Sep 13 02:05:05 2008 From: janina at rednote.net (Janina Sajka) Date: Fri, 12 Sep 2008 22:05:05 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <1221269239.3076.41.camel@rosebud> Message-ID: <20080913020505.GC4421@sonata.rednote.net> Colin Walters writes: > On Fri, Sep 12, 2008 at 9:27 PM, Seth Vidal wrote: > > On Fri, 2008-09-12 at 19:02 -0400, Colin Walters wrote: > > > >> I'm talking about the direction and technology of the desktop product; > >> what server images, embedded etc. do is an entirely different matter. > > > > > > Desktop Product? We don't make a desktop product. > > The live CD image, combined with the default comps tree from > "gnome-desktop" is what I consider the desktop product. > > > We make a linux > > distribution. > > I am certainly not here to make a "linux distribution", which I > consider a derogatory term. And this is your reason for denying others the choice they would make? Well, that rather speaks for itself, imho. In any case, thanks for hijacking the thread away from pulseaudio. I guess the system daemon is still purely theoretical--described on pulseaudio.org without specifics. Janina -- Janina Sajka, Phone: +1.202.595.7777; sip:janina at a11y.org Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada Learn more at http://ScreenlessPhone.Com Chair, Open Accessibility janina at a11y.org Linux Foundation http://a11y.org From walters at verbum.org Sat Sep 13 02:11:36 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 12 Sep 2008 22:11:36 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080913015752.GB4421@sonata.rednote.net> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <20080912202813.GL6092@nb.net.home> <20080912203036.GN32741@angus.ind.WPI.EDU> <20080913015752.GB4421@sonata.rednote.net> Message-ID: On Fri, Sep 12, 2008 at 9:57 PM, Janina Sajka wrote: > Chuck Anderson writes: >> >> Audio works on the GDM login screen. Orca starts and reads the login >> window to me... > > > What Fedora? And, what GDM? This worked, hmm, perhaps 60-70% for me back > in Fedora 8. But GDM has gone through a massive rewrite since then. None > of the users I'm in touch with have gotten this to work on F-9 or later. I just tried this too with GDM, and got speech too. I right clicked in the lower left of the screen, checked the "Read text" option, and moused over and heard sound. Have you filed a bug about this issue? From walters at verbum.org Sat Sep 13 02:20:57 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 12 Sep 2008 22:20:57 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <20080912202813.GL6092@nb.net.home> <20080912203036.GN32741@angus.ind.WPI.EDU> <20080913015752.GB4421@sonata.rednote.net> Message-ID: On Fri, Sep 12, 2008 at 10:11 PM, Colin Walters wrote: > On Fri, Sep 12, 2008 at 9:57 PM, Janina Sajka wrote: >> Chuck Anderson writes: >>> >>> Audio works on the GDM login screen. Orca starts and reads the login >>> window to me... >> >> >> What Fedora? And, what GDM? This worked, hmm, perhaps 60-70% for me back >> in Fedora 8. But GDM has gone through a massive rewrite since then. None >> of the users I'm in touch with have gotten this to work on F-9 or later. > > I just tried this too with GDM, and got speech too. I right clicked > in the lower left of the screen, checked the "Read text" option, and > moused over and heard sound. Have you filed a bug about this issue? Incidentally you should be able to enable this by default so sightless people don't have the bootstrapping problem of enabling TTS. There is some documentation on the new GDM configuration here: http://live.gnome.org/GDM/2.22/Configuration Unfortunately GConf is overly complex to use (a bug we would like to fix), but this page describes how to use GConf to set GDM's system-wide settings: https://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/desktop-guide/s1-ddg-intro-gconf-default-mandatory.html So for example: sudo gconftool-2 --direct --config-source xml:readwrite:/etc/gconf/gconf.xml.defaults --type=boolean -s /apps/gdm/simple-greeter/accessibility/screen_reader_enabled true From casimiro.barreto at gmail.com Sat Sep 13 02:49:19 2008 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Fri, 12 Sep 2008 23:49:19 -0300 Subject: Yum broken & PAM-mount broken In-Reply-To: <2a28d2ab0809121750t6ce72fe6pf3d7085a97d3fe16@mail.gmail.com> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <2a28d2ab0809121750t6ce72fe6pf3d7085a97d3fe16@mail.gmail.com> Message-ID: <48CB2A2F.90609@gmail.com> Ok, # yum update ... # poweroff ... Some time later # yum update [root at terra casimiro]# yum update Traceback (most recent call last): File "/usr/bin/yum", line 29, in yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 229, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 84, in main base.getOptionsConfig(args) File "/usr/share/yum-cli/cli.py", line 184, in getOptionsConfig enabled_plugins=self.optparser._splitArg(opts.enableplugins)) File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 189, in _getConfig startupconf.pluginconfpath,disabled_plugins,enabled_plugins) File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 355, in doPluginSetup plugin_types, confpath, disabled_plugins, enabled_plugins) File "/usr/lib/python2.5/site-packages/yum/plugins.py", line 152, in __init__ self._importplugins(types) File "/usr/lib/python2.5/site-packages/yum/plugins.py", line 195, in _importplugins self._loadplugin(modulefile, types) File "/usr/lib/python2.5/site-packages/yum/plugins.py", line 251, in _loadplugin module = imp.load_module(modname, fp, pathname, description) File "/usr/lib/yum-plugins/filter-data.py", line 111 ('committers', 'committer')] ^ SyntaxError: invalid syntax [root at terra casimiro]# -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From dennis at ausil.us Sat Sep 13 02:28:12 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 12 Sep 2008 21:28:12 -0500 Subject: Outage Notification - 2008-09-13 01:00 UTC In-Reply-To: <200809101211.12685.dennis@ausil.us> References: <200809101211.12685.dennis@ausil.us> Message-ID: <200809122128.19013.dennis@ausil.us> On Wednesday 10 September 2008 12:11:07 pm Dennis Gilmore wrote: > There will be an outage starting at Y2008-09-13 01:00 UTC, which will > last approximately 1 hour. > > To convert UTC to your local time, take a look at > http://fedoraproject.org/wiki/Infrastructure/UTCHowto > or run: > > date -d '2008-09-13 01:00 UTC' > > Affected Services: > Buildsystem > > Unaffected Services: > Websites > Database > CVS / Source Control > DNS > Mail > Torrent > > > Ticket Link: > https://fedorahosted.org/fedora-infrastructure/ticket/830 > > Reason for Outage: > update koji to 1.2.6. it will enable us to turn garbage collection back > on. > > Contact Information: > > Please join #fedora-admin in irc.freenode.net or respond to this email > to track > the status of this outage. This work has been completed, all build services restored. Please report any unusual things that you see. Dennis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From skvidal at fedoraproject.org Sat Sep 13 04:12:38 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Sat, 13 Sep 2008 00:12:38 -0400 Subject: Yum broken & PAM-mount broken In-Reply-To: <48CB2A2F.90609@gmail.com> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <2a28d2ab0809121750t6ce72fe6pf3d7085a97d3fe16@mail.gmail.com> <48CB2A2F.90609@gmail.com> Message-ID: <1221279158.3076.44.camel@rosebud> On Fri, 2008-09-12 at 23:49 -0300, Casimiro de Almeida Barreto wrote: > Ok, > > # yum update > ... > # poweroff > ... > > Some time later > # yum update > [root at terra casimiro]# yum update > Traceback (most recent call last): > File "/usr/bin/yum", line 29, in > yummain.user_main(sys.argv[1:], exit_code=True) > File "/usr/share/yum-cli/yummain.py", line 229, in user_main > errcode = main(args) > File "/usr/share/yum-cli/yummain.py", line 84, in main > base.getOptionsConfig(args) > File "/usr/share/yum-cli/cli.py", line 184, in getOptionsConfig > enabled_plugins=self.optparser._splitArg(opts.enableplugins)) > File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 189, in > _getConfig > startupconf.pluginconfpath,disabled_plugins,enabled_plugins) > File "/usr/lib/python2.5/site-packages/yum/__init__.py", line 355, in > doPluginSetup > plugin_types, confpath, disabled_plugins, enabled_plugins) > File "/usr/lib/python2.5/site-packages/yum/plugins.py", line 152, in > __init__ > self._importplugins(types) > File "/usr/lib/python2.5/site-packages/yum/plugins.py", line 195, in > _importplugins > self._loadplugin(modulefile, types) > File "/usr/lib/python2.5/site-packages/yum/plugins.py", line 251, in > _loadplugin > module = imp.load_module(modname, fp, pathname, description) > File "/usr/lib/yum-plugins/filter-data.py", line 111 > ('committers', 'committer')] > ^ > SyntaxError: invalid syntax > [root at terra casimiro]# The yum bug: https://bugzilla.redhat.com/show_bug.cgi?id=460963 -sv From mw_triad at users.sourceforge.net Sat Sep 13 04:30:23 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 12 Sep 2008 23:30:23 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: Colin Walters wrote: > On Fri, Sep 12, 2008 at 3:43 PM, Janina Sajka wrote: >> The problems we have right now are sufficiently sever to be >> showstoppers. At the SpeakupModified.Org we recommend disabling >> pulseaudio. As things stand in F-9, one gets no audio until after a user >> logs in on the GUI. So, how are those who need screen reader support >> supposed to use the a11y features of GDM? As it stands, there seems no >> way to get console audio without that GUI login. Also a nonstarter in >> the screen reader user community. > > If you want to run terminal applications, can't you just log in to a > full screen gnome-terminal? > >> It seems a useful initial step toward resolution is to run pulseaudio >> as a system daemon, via an init script, /sbin/service, /sbin/chkconfig. >> The trade-offs vs the per user model that F-9 employs are probably more >> than acceptable to most a11y users. >> >> So, let me simply ask ... Has anyone a working init script for >> pulseaudio as a system daemon? Anything close that we could continue to >> refine as an alternative configuration option for Fedora? > > We're going to be removing the legacy non-X system consoles by default > in the long run. Aside from the fact that this little nugget derailed the thread due to the many people (rightly*, IMO) freaking out, I fail to see where any part of your message to which I am replying was of any relevance whatsoever to this thread. PA as a system daemon should work (or, perhaps, not work) regardless of what happens to "non-X system consoles" in the future. Nor do I even see where Janina said *anything* about them, or even about consoles or the CLI in general. Did I miss something? (*...though you still haven't answered if you really want to kill non-X consoles or just hide them really well, which would have avoided all that.) -- Matthew ENOWIT: .sig file for this machine not set up yet From mw_triad at users.sourceforge.net Sat Sep 13 04:35:13 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 12 Sep 2008 23:35:13 -0500 Subject: Today's (9/12) rawhide all users = unable to authenticate user! In-Reply-To: References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> Message-ID: darrell pfeifer wrote: > 2008/9/12 Dr. Diesel > >> Booting normally to GDM, using normal root login gives me unable to >> authenticate user. If I boot to init3, my user/pass works just fine, then I >> can startx. I attempted passwd and reset my pass with no luck! >> >> Anybody else? Should I file this under GDM? >> > > The gdm changelog says > > * Tue Sep 09 2008 Jon McCann - 1:2.23.92-2 > - Disallow root login > > So it is intentional So... what exactly are we supposed to do when the user login gets hosed? Reach for a rescue disk? (Seriously, what's with the sudden trend to make fixing problems harder by making recovery modes inaccessible in an apparent bid to hide the "confusing/potentially dangerous" bits of the system from the user?) -- Matthew ENOWIT: .sig file for this machine not set up yet From pemboa at gmail.com Sat Sep 13 04:43:32 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 12 Sep 2008 23:43:32 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: <16de708d0809122143w670ca05boa78cc0daab02a2f4@mail.gmail.com> On Fri, Sep 12, 2008 at 11:30 PM, Matthew Woehlke wrote: > (*...though you still haven't answered if you really want to kill non-X > consoles or just hide them really well, which would have avoided all that.) Maybe someone could split this off into a different thread. Back on topic: should I just file a bug against pulseaudio for each usecase that doesn't work? or is there a PulseAudip updates in in386.newkey that I should wait for? -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From martin.langhoff at gmail.com Sat Sep 13 04:54:56 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Sat, 13 Sep 2008 16:54:56 +1200 Subject: PostgreSQL mgmt on Fedora: pg_cluster-like tools? In-Reply-To: <2591.1221221267@sss.pgh.pa.us> References: <46a038f90809111659o41e98cc5r3e256c890669c5ec@mail.gmail.com> <1221196614.15987.52.camel@laptop.gunduz.org> <46a038f90809112228s172abc4cy1c05b7d494a91f67@mail.gmail.com> <2591.1221221267@sss.pgh.pa.us> Message-ID: <46a038f90809122154u7d8d13e3l5923c4a2f4e6d2a9@mail.gmail.com> On Sat, Sep 13, 2008 at 12:07 AM, Tom Lane wrote: >> Having been once the maintainer of the Pg compat layer in Moodle, I >> also have first-hand experience with this. When the casts removal was >> mentioned in pg-devel, who was there asking about backwards compat? > > If you need 100% backwards compatibility, you keep using 8.2 Perhaps wasn't clear - I wasn't complaining at all, just pointing out to Devrim that I am aware and active in tracking compat issues. > Anyway, Devrim is quite right that mere installation of an RPM cannot > execute any sort of database conversion. The functionality would need > to be invoked sometime else. That doesn't mean it has to be manual > though. Could we put it in the start script, invoked by something like > "service postgresql upgrade"? I completely agree. > Exactly what does a conversion look like > in Debian's packaging, anyway? * apt-get install postgresql-8.2 * pg_dropcluster ?stop 8.2 main * pg_upgradecluster -v 8.2 8.1 main /var/lib/postgresql/8.2/main and if it works well, pg_dropcluster 8.1 main will delete the data dir of the old one. also see http://www.digipedia.pl/man/pg_upgradecluster.8.html cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From rc040203 at freenet.de Sat Sep 13 05:20:49 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 13 Sep 2008 07:20:49 +0200 Subject: PostgreSQL mgmt on Fedora: pg_cluster-like tools? In-Reply-To: <46a038f90809122154u7d8d13e3l5923c4a2f4e6d2a9@mail.gmail.com> References: <46a038f90809111659o41e98cc5r3e256c890669c5ec@mail.gmail.com> <1221196614.15987.52.camel@laptop.gunduz.org> <46a038f90809112228s172abc4cy1c05b7d494a91f67@mail.gmail.com> <2591.1221221267@sss.pgh.pa.us> <46a038f90809122154u7d8d13e3l5923c4a2f4e6d2a9@mail.gmail.com> Message-ID: <1221283249.18327.404.camel@beck.corsepiu.local> On Sat, 2008-09-13 at 16:54 +1200, Martin Langhoff wrote: > On Sat, Sep 13, 2008 at 12:07 AM, Tom Lane wrote: > >> Having been once the maintainer of the Pg compat layer in Moodle, I > >> also have first-hand experience with this. When the casts removal was > >> mentioned in pg-devel, who was there asking about backwards compat? > > > > If you need 100% backwards compatibility, you keep using 8.2 > > Perhaps wasn't clear - I wasn't complaining at all, just pointing out > to Devrim that I am aware and active in tracking compat issues. > > > Anyway, Devrim is quite right that mere installation of an RPM cannot > > execute any sort of database conversion. The functionality would need > > to be invoked sometime else. That doesn't mean it has to be manual > > though. Could we put it in the start script, invoked by something like > > "service postgresql upgrade"? Only if such conversion can be guaranteed not to fail. In many cases this is not possible, because data-bases normally are subject to different layers of authentication or might be networked. > I completely agree. > > > Exactly what does a conversion look like > > in Debian's packaging, anyway? > > * apt-get install postgresql-8.2 > * pg_dropcluster ?stop 8.2 main > * pg_upgradecluster -v 8.2 8.1 main /var/lib/postgresql/8.2/main > > and if it works well, pg_dropcluster 8.1 main will delete the data dir > of the old one. I am not familiar with this particular case nor with postgres, but with many mysql-based applications such approach is mostly certain to fail. Ralf From dev at nigelj.com Sat Sep 13 05:53:55 2008 From: dev at nigelj.com (Nigel Jones) Date: Sat, 13 Sep 2008 17:53:55 +1200 Subject: Today's (9/12) rawhide all users = unable to authenticate user! In-Reply-To: References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> Message-ID: <1221285235.3492.4.camel@fantail.jnet.net.nz> On Fri, 2008-09-12 at 23:35 -0500, Matthew Woehlke wrote: > darrell pfeifer wrote: > > 2008/9/12 Dr. Diesel > > > >> Booting normally to GDM, using normal root login gives me unable to > >> authenticate user. If I boot to init3, my user/pass works just fine, then I > >> can startx. I attempted passwd and reset my pass with no luck! > >> > >> Anybody else? Should I file this under GDM? > >> > > > > The gdm changelog says > > > > * Tue Sep 09 2008 Jon McCann - 1:2.23.92-2 > > - Disallow root login > > > > So it is intentional > > So... what exactly are we supposed to do when the user login gets hosed? > Reach for a rescue disk? (Seriously, what's with the sudden trend to > make fixing problems harder by making recovery modes inaccessible in an > apparent bid to hide the "confusing/potentially dangerous" bits of the > system from the user?) >From memory GDM has always done this, (I personally don't use GDM, I favour KDM), I remember some FC5 machines in particular that required a GDM configuration hack to allow root logins. Overall, I'm in favour of not allowing root GUI logins by default, I'd imagine we are still going to always have direct root CLI logins. What I'd like to see, is sudo being setup by default (full access w/ password) for the first user (as configured during firstboot). > > -- > Matthew > ENOWIT: .sig file for this machine not set up yet > -- Nigel Jones From pekkas at netcore.fi Sat Sep 13 07:03:25 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 13 Sep 2008 10:03:25 +0300 (EEST) Subject: Please fix #445898: slow keys turn on, lock keyboard Message-ID: Hi, Would someone PLEASE provide updates to #445898. A fix has been known since end of July (and merged upstream) but to update ahs been pushed. It's very annoying to lose your keyboard if you're unlucky enough to press some keys for too long! The "gnome-settings-daemon workaround" doesn't work for those of us who aren't using it. https://bugzilla.redhat.com/show_bug.cgi?id=445898 -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From steven.moix at axianet.ch Sat Sep 13 08:33:45 2008 From: steven.moix at axianet.ch (Steven Moix) Date: Sat, 13 Sep 2008 10:33:45 +0200 Subject: Today's (9/12) rawhide all users = unable to authenticate user! In-Reply-To: <1221285235.3492.4.camel@fantail.jnet.net.nz> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <1221285235.3492.4.camel@fantail.jnet.net.nz> Message-ID: <1221294825.2709.3.camel@hp6710.axianet.ch> On Sat, 2008-09-13 at 17:53 +1200, Nigel Jones wrote: > Overall, I'm in favour of not allowing root GUI logins by default, I'd > imagine we are still going to always have direct root CLI logins. Really, I think this is a very bad idea. The root user isn't shown in the login GUI anyways, so if someone types "root" by hand, he really wants to be root. I don't see the point of going the Ubuntu "protect us from ourselves" way. Steven From ben.lewis at benl.co.uk Sat Sep 13 09:04:06 2008 From: ben.lewis at benl.co.uk (Benjamin Lewis) Date: Sat, 13 Sep 2008 10:04:06 +0100 Subject: Today's (9/12) rawhide all users = unable to authenticate user! In-Reply-To: References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> Message-ID: <48CB8206.8000708@benl.co.uk> Matthew Woehlke wrote: > darrell pfeifer wrote: >> 2008/9/12 Dr. Diesel >> >>> Booting normally to GDM, using normal root login gives me unable to >>> authenticate user. If I boot to init3, my user/pass works just fine, >>> then I >>> can startx. I attempted passwd and reset my pass with no luck! >>> >>> Anybody else? Should I file this under GDM? >>> >> >> The gdm changelog says >> >> * Tue Sep 09 2008 Jon McCann - 1:2.23.92-2 >> - Disallow root login >> >> So it is intentional > > So... what exactly are we supposed to do when the user login gets hosed? > Reach for a rescue disk? (Seriously, what's with the sudden trend to > make fixing problems harder by making recovery modes inaccessible in an > apparent bid to hide the "confusing/potentially dangerous" bits of the > system from the user?) > CTRL+ALT+F1 Login as root there fix it CTRL+ALT+F7 to get back to GDM -- Benjamin Lewis ben.lewis at benl.co.uk Ambassador, Fedora Project - http://fedoraproject.org ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 -------------- next part -------------- A non-text attachment was scrubbed... Name: ben_lewis.vcf Type: text/x-vcard Size: 203 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 897 bytes Desc: OpenPGP digital signature URL: From pmatilai at laiskiainen.org Sat Sep 13 09:41:22 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Sat, 13 Sep 2008 12:41:22 +0300 (EEST) Subject: Does your package provide GStreamer plugins? In-Reply-To: <1221232125.24928.268.camel@cookie.hadess.net> References: <1221215325.24928.235.camel@cookie.hadess.net> <935ead450809120606g2a0a93e2p350d9917417d180e@mail.gmail.com> <1221232125.24928.268.camel@cookie.hadess.net> Message-ID: On Fri, 12 Sep 2008, Bastien Nocera wrote: > On Fri, 2008-09-12 at 08:06 -0500, Jeffrey Ollie wrote: >> On Fri, Sep 12, 2008 at 5:28 AM, Bastien Nocera wrote: >>> >>> If your package provides GStreamer plugins, please rebuild it in rawhide >>> with the latest gstreamer-devel and RPM builds. >>> >>> We are trying to use a PackageKit-based solution to installing missing >>> GStreamer plugins. The new GStreamer and RPM packages will add strings >>> like this to your RPM's provides: >>> gstreamer0.10(urisource-ssh)()(64bit) >>> gstreamer0.10(decoder-application/ogg)()(64bit) >> >> I tried rebuilding schroedinger but I didn't see any new provides show >> up. Is there something I'm doing wrong? Here's a scratch build I >> just did: >> >> http://koji.fedoraproject.org/koji/taskinfo?taskID=822502 > > $ echo /usr/lib64/gstreamer-0.10/libgstschro.so | ./gstreamer.prov > gstreamer0.10(encoder-video/x-dirac)()(64bit) > gstreamer0.10(decoder-video/x-dirac)()(64bit) > gstreamer0.10(decoder-video/x-dirac)()(64bit) > > I don't get it, the RPM and gstreamer-devel versions are new enough for > the provides to work. Panu, could it be RPM not calling the script for > sub packages? Nope, it gets called for all shared libraries. Here's the problem: [pmatilai at turre ~]$ gst-inspect --print-plugin-auto-install-info --rpm /home/pmatilai/rpmbuild/BUILDROOT/schroedinger-1.0.5-2.fc9.x86_64/usr/lib64/gstreamer-0.10/libgstschro.so (gst-inspect-0.10:6091): GStreamer-WARNING **: Failed to load plugin '/home/pmatilai/rpmbuild/BUILDROOT/schroedinger-1.0.5-2.fc9.x86_64/usr/lib64/gstreamer-0.10/libgstschro.so': libschroedinger-1.0.so.0: cannot open shared object file: No such file or directory Could not load plugin file: Opening module failed: libschroedinger-1.0.so.0: cannot open shared object file: No such file or directory The schroedinger plugin library depends on a library that's only available in the buildroot. The above with LD_LIBRARY_PATH set to buildroot %{_libdir} succeeds but... - Panu - From martin.sourada at gmail.com Sat Sep 13 10:12:41 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Sat, 13 Sep 2008 12:12:41 +0200 Subject: Today's (9/12) rawhide all users = unable to authenticate user! In-Reply-To: <48CB8206.8000708@benl.co.uk> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <48CB8206.8000708@benl.co.uk> Message-ID: <1221300761.3152.2.camel@pc-notebook> On Sat, 2008-09-13 at 10:04 +0100, Benjamin Lewis wrote: > CTRL+ALT+F1 > Login as root there > fix it > CTRL+ALT+F7 to get back to GDM > Or boot to runlevel 3, login as root there and startx... Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From martin.sourada at gmail.com Sat Sep 13 10:16:52 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Sat, 13 Sep 2008 12:16:52 +0200 Subject: Today's (9/12) rawhide all users = unable to authenticate user! In-Reply-To: <1221285235.3492.4.camel@fantail.jnet.net.nz> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <1221285235.3492.4.camel@fantail.jnet.net.nz> Message-ID: <1221301012.3152.7.camel@pc-notebook> > What I'd like to see, is sudo being setup by default (full access w/ > password) for the first user (as configured during firstboot). Please no! Sudo is not the good way to do this kind of things. There is PolicyKit for doing such things correctly. Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jos at xos.nl Sat Sep 13 10:21:18 2008 From: jos at xos.nl (Jos Vos) Date: Sat, 13 Sep 2008 12:21:18 +0200 Subject: change isdn4k-utils to optional In-Reply-To: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> References: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> Message-ID: <20080913102118.GA8601@jasmine.xos.nl> On Fri, Sep 12, 2008 at 10:17:56AM -1000, David Cantrell wrote: > A random sampling of users at FUDCon Brno 2008 showed that ISDN isn't > really in use as much in Europe as previously thought. When I asked > people at FUDCon, I was met with laughter, much like when you talk > about ISDN in the United States. I think "previous thoughts" were correct. ISDN was used a lot in some countries (at least a lot in Germany and the Netherlands, for example) *before* many people moved to broadband/DSL (recent statistics show that in the Netherlands now 78% of all households has a broadband connection). > Are there any places out there still where ISDN is still more deployed > than PPP dial-ups or DSL? Please comment on > https://bugzilla.redhat.com/show_bug.cgi?id=462126 I'm pretty sure ISDN is still used more than ordinary, analogue PPP dial-ups in some countries, although PPP dial-ups (seen from the viewpoint of a Linux system) are now used again for Bluetooth connections with GPRS/UMTS phones ;-). Having said this, I have no strong opinion on the original question, whether ISDN should become optional or not. But a "random sampling" of FUDCon visitors is probably not a good statistical base for a decision, as FUDCon visitors might be -- in general -- better connected than the average user. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From rawhide at fedoraproject.org Sat Sep 13 10:24:14 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sat, 13 Sep 2008 10:24:14 +0000 (UTC) Subject: rawhide report: 20080913 changes Message-ID: <20080913102414.CEED61F8252@releng2.fedora.phx.redhat.com> New package eigen2 A lightweight C++ template library for vector and matrix math New package libvidcap Cross-platform video capture library New package ql2500-firmware Firmware for qlogic 2500 devices Updated Packages: c-ares-1.5.3-1.fc10 ------------------- * Fri Sep 12 18:00:00 2008 Tom "spot" Callaway - 1.5.3-1 - update to 1.5.3 daa2iso-0.1.6-1.fc10 -------------------- * Fri Sep 12 18:00:00 2008 Tom "spot" Callaway 0.1.6-1 - update to 0.1.6 koffice-1.9.95.10-1.fc10 ------------------------ * Wed Aug 20 18:00:00 2008 Rex Dieter 1.9.95.10-1 - koffice-1.9.95.10 kscope-1.6.2-1.fc10 ------------------- * Fri Sep 12 18:00:00 2008 Tom "spot" Callaway 1.6.2-1 - update to 1.6.2 libconfig-1.3.1-1.fc10 ---------------------- * Fri Sep 12 18:00:00 2008 Tom "spot" Callaway - 1.3.1-1 - update to 1.3.1 ntfsprogs-2.0.0-9.fc10 ---------------------- * Fri Sep 12 18:00:00 2008 Tom "spot" Callaway 2.0.0-9 - avoid crash when ntfs_attr_readall fails (Christophe Grenier) - fix segfault in ntfsundelete (Gary Funck) - fix FTBFS qstat-2.11-6.20080912svn311.fc10 -------------------------------- * Fri Sep 12 18:00:00 2008 Tom "spot" Callaway - 2.11-6.20080912svn311 - update to latest svn - upstream relicensed to Artistic 2.0 stapitrace-1.0.0-12.20080622cvs_alpha.fc10 ------------------------------------------ * Fri Sep 12 18:00:00 2008 Josh Boyer - Fix bfd configure test as binutils now requires zlib for compressed sections uqm-0.6.2-7.fc10 ---------------- * Fri Sep 12 18:00:00 2008 Tom "spot" Callaway - 0.6.2-7 - forgot a few obsoletes/provides winpdb-1.4.0-1.fc10 ------------------- * Fri Sep 12 18:00:00 2008 Tom "spot" Callaway - 1.4.0-1 - update to 1.4.0 Summary: Added Packages: 3 Removed Packages: 0 Modified Packages: 10 Broken deps for i386 ---------------------------------------------------------- em8300-0.17.1-1.fc10.i386 requires /etc/alsa/cards evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.i386 requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so Broken deps for x86_64 ---------------------------------------------------------- em8300-0.17.1-1.fc10.x86_64 requires /etc/alsa/cards evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.x86_64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- em8300-0.17.1-1.fc10.ppc requires /etc/alsa/cards evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.ppc requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so Broken deps for ppc64 ---------------------------------------------------------- eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 em8300-0.17.1-1.fc10.ppc64 requires /etc/alsa/cards evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave livecd-tools-018-1.fc10.ppc64 requires yaboot mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.ppc64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) From ivazqueznet at gmail.com Sat Sep 13 10:38:41 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sat, 13 Sep 2008 06:38:41 -0400 Subject: Does your package provide GStreamer plugins? In-Reply-To: References: <1221215325.24928.235.camel@cookie.hadess.net> <935ead450809120606g2a0a93e2p350d9917417d180e@mail.gmail.com> <1221232125.24928.268.camel@cookie.hadess.net> Message-ID: <1221302321.27183.137.camel@ignacio.lan> On Sat, 2008-09-13 at 12:41 +0300, Panu Matilainen wrote: > Could not load plugin file: Opening module failed: > libschroedinger-1.0.so.0: cannot open shared object file: No such file or > directory > > The schroedinger plugin library depends on a library that's only available > in the buildroot. The above with LD_LIBRARY_PATH set to buildroot > %{_libdir} succeeds but... But what? Other than the hand-wavy "It's ugly!", what's wrong with that approach? -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ndbecker2 at gmail.com Sat Sep 13 12:01:08 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 13 Sep 2008 08:01:08 -0400 Subject: SIGs/SciTech/SAGE progress? References: Message-ID: Cry wrote: > > Are there any status updates on building SAGE^3 into fedora?^1 > > I've been looking at the PCLinuxOS rpms. As it stands SAGE depends on > kash which has a strange license. > > Another issue is that the software bundles many other packages against the > fedora tradition. > > Thanks, > > 1: http://fedoraproject.org/wiki/SIGs/SciTech/SAGE > 2: > http://rpm.pbone.net/index.php3/stat/3/srodzaj/2/search/sage-3.0.3-1pclos2007.src.rpm > 3: http://sagemath.org > > > Cython should be available now. From fedora at leemhuis.info Sat Sep 13 12:02:12 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 13 Sep 2008 14:02:12 +0200 Subject: configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!) In-Reply-To: <1221301012.3152.7.camel@pc-notebook> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <1221285235.3492.4.camel@fantail.jnet.net.nz> <1221301012.3152.7.camel@pc-notebook> Message-ID: <48CBABC4.5060005@leemhuis.info> On 13.09.2008 12:16, Martin Sourada wrote: >> What I'd like to see, is sudo being setup by default (full access w/ >> password) for the first user (as configured during firstboot). I'm not sure if that's a good idea, as that could lead to unwilling side-effect as that's easily forgotten by those not familiar with this behavior in Fedora. But a checkbox with a text "User is the sysadmin for this system" might makes sense in firstboot -- that checkbox could not only configure sudo and/or PolicyKit access but also do other things like setting up a alias to /etc/aliases to make sure the user in question retrieves the mail send to root. > Please no! Sudo is not the good way to do this kind of things. There is > PolicyKit for doing such things correctly. Then please tell me how for example read /var/log/messages or other log files from /var/log/ using PolicyKit from a {gnome,kde}-terminal(?) with an easy to remember and fast to type command (like "sudo"). tia -- I'm really curious if such a command exists. CU knurd (?) something most of us have done in the past or regularly do From opensource at till.name Sat Sep 13 12:03:01 2008 From: opensource at till.name (Till Maas) Date: Sat, 13 Sep 2008 14:03:01 +0200 Subject: Yum broken & PAM-mount broken In-Reply-To: <48CB2A2F.90609@gmail.com> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <2a28d2ab0809121750t6ce72fe6pf3d7085a97d3fe16@mail.gmail.com> <48CB2A2F.90609@gmail.com> Message-ID: <200809131403.06528.opensource@till.name> On Sat September 13 2008, Casimiro de Almeida Barreto wrote: [nothing about pam_mount] Regarding the subject, what is in which version of pam_mount for you broken? And please create a bug report for this, if it is not fixed in pam_mount 0.48. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From mattdm at mattdm.org Sat Sep 13 12:06:36 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 13 Sep 2008 08:06:36 -0400 Subject: configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!) In-Reply-To: <48CBABC4.5060005@leemhuis.info> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <1221285235.3492.4.camel@fantail.jnet.net.nz> <1221301012.3152.7.camel@pc-notebook> <48CBABC4.5060005@leemhuis.info> Message-ID: <20080913120636.GA20878@jadzia.bu.edu> On Sat, Sep 13, 2008 at 02:02:12PM +0200, Thorsten Leemhuis wrote: > But a checkbox with a text "User is the sysadmin for this system" might > makes sense in firstboot -- that checkbox could not only configure sudo > and/or PolicyKit access but also do other things like setting up a alias to > /etc/aliases to make sure the user in question retrieves the mail send to > root. If we do this (and I'm for it), we should make this work by uncommenting the wheel group in /etc/sudoers, and having said checkbox add the user to the wheel group. -- Matthew Miller mattdm at mattdm.org From fedora at camperquake.de Sat Sep 13 12:06:43 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 13 Sep 2008 14:06:43 +0200 Subject: change isdn4k-utils to optional In-Reply-To: <20080913102118.GA8601@jasmine.xos.nl> References: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> <20080913102118.GA8601@jasmine.xos.nl> Message-ID: <20080913140643.40ae1d3d@lain.camperquake.de> Hi. On Sat, 13 Sep 2008 12:21:18 +0200, Jos Vos wrote > Having said this, I have no strong opinion on the original question, > whether ISDN should become optional or not. But a "random sampling" > of FUDCon visitors is probably not a good statistical base for a > decision, as FUDCon visitors might be -- in general -- better > connected than the average user. I agree with that. There are (and always will be, I suspect) places where anything faster than ISDN will simply not be available. If there is a size concern for this package maybe we could split out all the pieces not necessary for simple PPP dialup (the whole CAPI and FAX tools) and just install the PPP bits? From martin.sourada at gmail.com Sat Sep 13 12:31:03 2008 From: martin.sourada at gmail.com (Martin Sourada) Date: Sat, 13 Sep 2008 14:31:03 +0200 Subject: configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!) In-Reply-To: <48CBABC4.5060005@leemhuis.info> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <1221285235.3492.4.camel@fantail.jnet.net.nz> <1221301012.3152.7.camel@pc-notebook> <48CBABC4.5060005@leemhuis.info> Message-ID: <1221309063.3152.27.camel@pc-notebook> On Sat, 2008-09-13 at 14:02 +0200, Thorsten Leemhuis wrote: > I'm not sure if that's a good idea, as that could lead to unwilling > side-effect as that's easily forgotten by those not familiar with this > behavior in Fedora. > > But a checkbox with a text "User is the sysadmin for this system" might > makes sense in firstboot -- that checkbox could not only configure sudo > and/or PolicyKit access but also do other things like setting up a alias > to /etc/aliases to make sure the user in question retrieves the mail > send to root. > Yeah, that seems to me to make sense. What I am mostly against is having full access to sudo without password by default by any user. I believe PolicyKit is designed to solve this issue by granting rights (by admin) to user to do this and that and not do other admin tasks... > > Please no! Sudo is not the good way to do this kind of things. There is > > PolicyKit for doing such things correctly. > > Then please tell me how for example read /var/log/messages or other log > files from /var/log/ using PolicyKit from a {gnome,kde}-terminal(?) with > an easy to remember and fast to type command (like "sudo"). tia -- I'm > really curious if such a command exists. > Good point. I am by no means expert in this area, but from I heard/read, it seems like PolicyKit is designed to fine-tune such things as well, though it's probably not implemented currently. Basically the implementation should IMHO be like cat/nano/vi/whatever detects that you are trying to access some file you don't have enough rights to access, then it asks PolicyKit whether to allow it or not and PolicyKit handles the rest (i.e. checks whether your admin already allowed that access for you, if not asks for root password for allowing the access and if succeeded sends back that its OK for you to access the file). Ideally it wouldn't require any additional command (like sudo). Though probably this would need to be implemented on filesystem level, rather than in cat/nano/... When I want to view logs (though I don't very much understand why I cannot read them as normal user) I just log in as root (in console/gnome-terminal only!). Yeah it's not pleasant to write root password every time I want to do some admin task - and that's probably one of the reasons why PolicyKit has been developed - but I think allowing full access to sudo without password for normal user account is a big security hole. Anyway my point in short is that I think allowing full sudo access without password is wrong unless you really know what that means and I believe PolicyKit was partly developed to avoid the need for that. > CU > knurd > Martin > (?) something most of us have done in the past or regularly do > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Sat Sep 13 12:58:46 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Sat, 13 Sep 2008 08:58:46 -0400 Subject: configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!) In-Reply-To: <20080913120636.GA20878@jadzia.bu.edu> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <1221285235.3492.4.camel@fantail.jnet.net.nz> <1221301012.3152.7.camel@pc-notebook> <48CBABC4.5060005@leemhuis.info> <20080913120636.GA20878@jadzia.bu.edu> Message-ID: <1221310726.3076.46.camel@rosebud> On Sat, 2008-09-13 at 08:06 -0400, Matthew Miller wrote: > On Sat, Sep 13, 2008 at 02:02:12PM +0200, Thorsten Leemhuis wrote: > > But a checkbox with a text "User is the sysadmin for this system" might > > makes sense in firstboot -- that checkbox could not only configure sudo > > and/or PolicyKit access but also do other things like setting up a alias to > > /etc/aliases to make sure the user in question retrieves the mail send to > > root. > > If we do this (and I'm for it), we should make this work by uncommenting the > wheel group in /etc/sudoers, and having said checkbox add the user to the > wheel group. I don't like the wheel group way into sudoers. Not the least of which because the wheel group, on systems which are using some other form of nss than local files, can be mucked with too easily. -sv From janina at rednote.net Sat Sep 13 13:47:41 2008 From: janina at rednote.net (Janina Sajka) Date: Sat, 13 Sep 2008 09:47:41 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <20080912202813.GL6092@nb.net.home> <20080912203036.GN32741@angus.ind.WPI.EDU> <20080913015752.GB4421@sonata.rednote.net> Message-ID: <20080913134741.GD4421@sonata.rednote.net> Colin Walters writes: > On Fri, Sep 12, 2008 at 9:57 PM, Janina Sajka wrote: > > Chuck Anderson writes: > >> > >> Audio works on the GDM login screen. Orca starts and reads the login > >> window to me... > > > > > > What Fedora? And, what GDM? This worked, hmm, perhaps 60-70% for me back > > in Fedora 8. But GDM has gone through a massive rewrite since then. None > > of the users I'm in touch with have gotten this to work on F-9 or later. > > I just tried this too with GDM, and got speech too. I right clicked > in the lower left of the screen, checked the "Read text" option, and > moused over and heard sound. Have you filed a bug about this issue? > Well, the blind user will need to use the built in Ctrl-s rather than the mouse, but this is helpful to know at least to help narrow down the problem. Are you gdm 2.22.x? Janina > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka, Phone: +1.202.595.7777; sip:janina at a11y.org Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada Learn more at http://ScreenlessPhone.Com Chair, Open Accessibility janina at a11y.org Linux Foundation http://a11y.org From janina at rednote.net Sat Sep 13 13:51:08 2008 From: janina at rednote.net (Janina Sajka) Date: Sat, 13 Sep 2008 09:51:08 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <20080912202813.GL6092@nb.net.home> <20080912203036.GN32741@angus.ind.WPI.EDU> <20080913015752.GB4421@sonata.rednote.net> Message-ID: <20080913135108.GE4421@sonata.rednote.net> Colin Walters writes: > On Fri, Sep 12, 2008 at 10:11 PM, Colin Walters wrote: > > On Fri, Sep 12, 2008 at 9:57 PM, Janina Sajka wrote: > >> Chuck Anderson writes: > >>> > >>> Audio works on the GDM login screen. Orca starts and reads the login > >>> window to me... > >> > >> > >> What Fedora? And, what GDM? This worked, hmm, perhaps 60-70% for me back > >> in Fedora 8. But GDM has gone through a massive rewrite since then. None > >> of the users I'm in touch with have gotten this to work on F-9 or later. > > > > I just tried this too with GDM, and got speech too. I right clicked > > in the lower left of the screen, checked the "Read text" option, and > > moused over and heard sound. Have you filed a bug about this issue? > > Incidentally you should be able to enable this by default so sightless > people don't have the bootstrapping problem of enabling TTS. There is > some documentation on the new GDM configuration here: > http://live.gnome.org/GDM/2.22/Configuration > I'm sure personal machines will be set up with this as a default, once all the bugs are cleared. One known issue, last it was working in F-8, is that you could get speech via GDM, or speech on the Desktop after login--but not both. Rather a bug. Also, the intent is that Ctrl-s needs to be available so that any GNOME desktop, whether your sister's, your neighbor's, the university's, or the local coffee stand's, can work via a reliable "gesture." Janina > Unfortunately GConf is overly complex to use (a bug we would like to > fix), but this page describes how to use GConf to set GDM's > system-wide settings: > > https://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/desktop-guide/s1-ddg-intro-gconf-default-mandatory.html > > So for example: > sudo gconftool-2 --direct --config-source > xml:readwrite:/etc/gconf/gconf.xml.defaults --type=boolean -s > /apps/gdm/simple-greeter/accessibility/screen_reader_enabled true > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka, Phone: +1.202.595.7777; sip:janina at a11y.org Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada Learn more at http://ScreenlessPhone.Com Chair, Open Accessibility janina at a11y.org Linux Foundation http://a11y.org From pekkas at netcore.fi Sat Sep 13 14:19:47 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 13 Sep 2008 17:19:47 +0300 (EEST) Subject: graphics w/ 2.6.26.3-29 kernel sluggish, 2.6.25.14-108 OK? Message-ID: Hi, On FC9, after upgrading the kernel to 2.6.26.3-29, I noticed that any video (e.g. watching vid on xine or kaffeine) was really sluggish and choppy. CPU usage was very high significant: 5522 psavola 20 0 295m 94m 60m S 75.4 12.4 24:18.99 kaffeine 9854 psavola 20 0 335m 120m 94m S 39.1 15.9 0:12.45 xine Rebooting back to 2.6.25.14-108 halved the CPU usage and made graphics work again. (In general it seems as if in 2.6.26.3 the kernel was slow overall but it's difficult to prove.) Running RadeonHD on AMD Sempron. I couldn't find any bugs like this so I filed it here: https://bugzilla.redhat.com/show_bug.cgi?id=462180 Anyone else see something like this or have workaround or ideas for the cause? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From stlwrt at gmail.com Sat Sep 13 14:33:59 2008 From: stlwrt at gmail.com (Pavel Shevchuk) Date: Sat, 13 Sep 2008 17:33:59 +0300 Subject: graphics w/ 2.6.26.3-29 kernel sluggish, 2.6.25.14-108 OK? In-Reply-To: References: Message-ID: no problems with nvidia driver. mplayer and glxgears show no anomalies On Sat, Sep 13, 2008 at 5:19 PM, Pekka Savola wrote: > Hi, > > On FC9, after upgrading the kernel to 2.6.26.3-29, I noticed that any video > (e.g. watching vid on xine or kaffeine) was really sluggish and choppy. CPU > usage was very high significant: > > 5522 psavola 20 0 295m 94m 60m S 75.4 12.4 24:18.99 kaffeine > 9854 psavola 20 0 335m 120m 94m S 39.1 15.9 0:12.45 xine > > Rebooting back to 2.6.25.14-108 halved the CPU usage and made graphics work > again. (In general it seems as if in 2.6.26.3 the kernel was slow overall > but it's difficult to prove.) > > Running RadeonHD on AMD Sempron. I couldn't find any bugs like this so I > filed it here: > > https://bugzilla.redhat.com/show_bug.cgi?id=462180 > > Anyone else see something like this or have workaround or ideas for the > cause? > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- http://scwlab.com From casimiro.barreto at gmail.com Sat Sep 13 14:49:36 2008 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Sat, 13 Sep 2008 11:49:36 -0300 Subject: Yum broken & PAM-mount broken In-Reply-To: <200809131403.06528.opensource@till.name> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <2a28d2ab0809121750t6ce72fe6pf3d7085a97d3fe16@mail.gmail.com> <48CB2A2F.90609@gmail.com> <200809131403.06528.opensource@till.name> Message-ID: <48CBD300.5090700@gmail.com> Till Maas escreveu: > On Sat September 13 2008, Casimiro de Almeida Barreto wrote: > [nothing about pam_mount] > > Regarding the subject, what is in which version of pam_mount for you broken? > And please create a bug report for this, if it is not fixed in pam_mount > 0.48. > > Regards, > Till > I'll fill bugzilla. Anyways the "official pam_mount" for fc9 is 0.47 as shown: [root at terra casimiro]# rpm -e --allmatches pam_mount aviso: /etc/security/pam_mount.conf.xml salvo como /etc/security/pam_mount.conf.xml.rpmsave [root at terra casimiro]# yum install pam_mount Plugins carregados: aliases, allowdowngrade, changelog, downloadonly, : fastestmirror, fedorakmod, kernel-module, keys, list-data, : merge-conf, priorities, protect-packages, protectbase, : refresh-packagekit, refresh-updatesd, tmprepo, tsflags, : upgrade-helper, verify, versionlock Loading mirror speeds from cached hostfile * livna: rpm.livna.org * fedora: fedora.c3sl.ufpr.br * updates-newkey: mirror.cc.vt.edu * updates: ftp.linux.ncsu.edu Reading version lock configuration 0 packages excluded due to repository protections Configurando o Processo de Instala??o Analisando argumentos da instala??o de pacotes Resolvendo Depend?ncias --> Executando verifica??o da transa??o ---> Pacote pam_mount.i386 0:0.47-1.fc9 definido para ser atualizado --> Resolu??o de Depend?ncias Finalizada Depend?ncias Resolvidas ================================================================================ Pacote Arq. Vers?o Reposit?rio Tamanho ================================================================================ Instalando: pam_mount i386 0.47-1.fc9 updates-newkey 119 k Transaction Summary ================================================================================ Install 1 Package(s) Update 0 Package(s) Remove 0 Package(s) Tamanho total do download: 119 k Correto? [s/N]:s Baixando Pacotes: pam_mount-0.47-1.fc9.i386.rpm | 119 kB 00:01 Executando o rpm_check_debug Executando Teste de Transa??o Teste de Transa??o Finalizado Teste de Transa??o Completo Executando a Transa??o Instalando : pam_mount [1/1] Instalados: pam_mount.i386 *0:0.47-1.fc9* Conclu?do! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From opensource at till.name Sat Sep 13 15:06:03 2008 From: opensource at till.name (Till Maas) Date: Sat, 13 Sep 2008 17:06:03 +0200 Subject: Yum broken & PAM-mount broken In-Reply-To: <48CBD300.5090700@gmail.com> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <200809131403.06528.opensource@till.name> <48CBD300.5090700@gmail.com> Message-ID: <200809131706.12332.opensource@till.name> On Sat September 13 2008, Casimiro de Almeida Barreto wrote: > Till Maas escreveu: > > On Sat September 13 2008, Casimiro de Almeida Barreto wrote: > > [nothing about pam_mount] > > > > Regarding the subject, what is in which version of pam_mount for you > > broken? And please create a bug report for this, if it is not fixed in > > pam_mount 0.48. > I'll fill bugzilla. Anyways the "official pam_mount" for fc9 is 0.47 as > shown: With the next push, pam_mount should be updated to 0.48 in Fedora 8 and 9: https://admin.fedoraproject.org/updates/pam_mount-0.48-2.fc9,libHX-1.25-1.fc9 Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From casimiro.barreto at gmail.com Sat Sep 13 15:45:47 2008 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Sat, 13 Sep 2008 12:45:47 -0300 Subject: Yum broken & PAM-mount broken In-Reply-To: <200809131706.12332.opensource@till.name> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <200809131403.06528.opensource@till.name> <48CBD300.5090700@gmail.com> <200809131706.12332.opensource@till.name> Message-ID: <48CBE02B.5080401@gmail.com> Till Maas escreveu: > On Sat September 13 2008, Casimiro de Almeida Barreto wrote: > >> Till Maas escreveu: >> >>> On Sat September 13 2008, Casimiro de Almeida Barreto wrote: >>> [nothing about pam_mount] >>> >>> Regarding the subject, what is in which version of pam_mount for you >>> broken? And please create a bug report for this, if it is not fixed in >>> pam_mount 0.48. >>> > > >> I'll fill bugzilla. Anyways the "official pam_mount" for fc9 is 0.47 as >> shown: >> > > With the next push, pam_mount should be updated to 0.48 in Fedora 8 and 9: > https://admin.fedoraproject.org/updates/pam_mount-0.48-2.fc9,libHX-1.25-1.fc9 > > Regards, > Till > Ok, I'm transcripting the debugging information. First of all I have an encripted "partition" for /home/casimiro that is mount via loop0. It was working well until last update. It is still mounting when I use input lile: # openssl aes-256-cbc -d -in /etc/pki/cryptofs/mykey.key | mount -p0 -o loop,encryption=aes-cbc-256,rw /xxx/yyy.img /home/casimiro But, when it goes to PAM... that's what happen: Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(pam_mount.c:259) pam_mount 0.47: entering auth stage Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(pam_mount.c:269) could not get password from PAM system Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(pam_mount.c:191) enter read_password Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(pam_mount.c:294) saving authtok for session code (authtok=0x8e0d630) Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(pam_mount.c:437) pam_mount 0.47: entering session stage Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(pam_mount.c:458) back from global readconfig Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(pam_mount.c:460) per-user configurations not allowed by pam_mount.conf.xml Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(misc.c:45) Session open: (uid=0, euid=0, gid=501, egid=501) Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(rdconf2.c:190) checking sanity of volume record (/home/.casimiro.img) Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(pam_mount.c:512) about to perform mount operations Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:364) information for mount: Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:365) ---------------------- Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:366) (defined by globalconf) Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:367) user: casimiro Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:368) server: (null) Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:369) volume: /xxx/yyy.img Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:370) mountpoint: /home/casimiro Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:371) options: loop,encryption=aes-cbc-256,rw Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:372) fs_key_cipher: aes-256-cbc Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:373) fs_key_path: /etc/pki/cryptofs/mykey.key Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:374) use_fstab: 0 Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:375) ---------------------- Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:151) realpath of volume "/home/casimiro" is "/home/casimiro" Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:155) checking to see if /xxx/yyy.img is already mounted at /home/casimiro Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:824) checking for encrypted filesystem key configuration Sep 13 12:14:28 terra kdm: :0[3068]: pam_mount(mount.c:831) decrypting FS key using system auth. token and aes-256-cbc Sep 13 12:14:28 terra kdm[3019]: Unknown session exit code 0 (sig 6) from manager process Sep 13 12:14:28 terra kdm_greet[3072]: Cannot read from core Sep 13 12:14:39 terra login: pam_mount(pam_mount.c:259) pam_mount 0.47: entering auth stage Sep 13 12:14:39 terra login: pam_mount(pam_mount.c:269) could not get password from PAM system Sep 13 12:14:39 terra login: pam_mount(pam_mount.c:191) enter read_password Sep 13 12:14:42 terra login: pam_mount(pam_mount.c:294) saving authtok for session code (authtok=0x94f04d8) Sep 13 12:14:42 terra login: pam_mount(pam_mount.c:437) pam_mount 0.47: entering session stage Sep 13 12:14:42 terra login: pam_mount(pam_mount.c:458) back from global readconfig Sep 13 12:14:42 terra login: pam_mount(pam_mount.c:460) per-user configurations not allowed by pam_mount.conf.xml Sep 13 12:14:42 terra login: pam_mount(misc.c:45) Session open: (uid=0, euid=0, gid=0, egid=0) Sep 13 12:14:42 terra login: pam_mount(rdconf2.c:190) checking sanity of volume record (/xxx/yyy.img) Sep 13 12:14:42 terra login: pam_mount(pam_mount.c:512) about to perform mount operations Sep 13 12:14:42 terra login: pam_mount(mount.c:364) information for mount: Sep 13 12:14:42 terra login: pam_mount(mount.c:365) ---------------------- Sep 13 12:14:42 terra login: pam_mount(mount.c:366) (defined by globalconf) Sep 13 12:14:42 terra login: pam_mount(mount.c:367) user: casimiro Sep 13 12:14:42 terra login: pam_mount(mount.c:368) server: (null) Sep 13 12:14:42 terra login: pam_mount(mount.c:369) volume: /xxx/yyy.img Sep 13 12:14:42 terra login: pam_mount(mount.c:370) mountpoint: /home/casimiro Sep 13 12:14:42 terra login: pam_mount(mount.c:371) options: loop,encryption=aes-cbc-256,rw Sep 13 12:14:42 terra login: pam_mount(mount.c:372) fs_key_cipher: aes-256-cbc Sep 13 12:14:42 terra login: pam_mount(mount.c:373) fs_key_path: /etc/pki/cryptofs/mykey.key Sep 13 12:14:42 terra login: pam_mount(mount.c:374) use_fstab: 0 Sep 13 12:14:42 terra login: pam_mount(mount.c:375) ---------------------- Sep 13 12:14:42 terra login: pam_mount(mount.c:151) realpath of volume "/home/casimiro" is "/home/casimiro" Sep 13 12:14:42 terra login: pam_mount(mount.c:155) checking to see if /xxx/yyy.img is already mounted at /home/casimiro Sep 13 12:14:42 terra login: pam_mount(mount.c:824) checking for encrypted filesystem key configuration Sep 13 12:14:42 terra login: pam_mount(mount.c:831) decrypting FS key using system auth. token and aes-256-cbc Sep 13 12:14:42 terra init: tty1 main process (3034) killed by ABRT signal Sep 13 12:14:42 terra init: tty1 main process ended, respawning And them, back to /etc/security/pam_mount.conf.xml: /usr/sbin/lsof %(MNTPT) /sbin/fsck -p %(FSCKTARGET) /sbin/losetup -p0 "%(before=\"-e\" CIPHER)" "%(before=\"-k\" KEYBITS)" %(FSCKLOOP) %(VOLUME) /sbin/losetup -d %(FSCKLOOP) /bin/mount -t cifs //%(SERVER)/%(VOLUME) %(MNTPT) -o "user=%(USER),uid=%(USERUID),gid=%(USERGID)%(before=\",\" OPTIONS)" /usr/bin/smbmount //%(SERVER)/%(VOLUME) %(MNTPT) -o "username=%(USER),uid=%(USERUID),gid=%(USERGID)%(before=\",\" OPTIONS)" /usr/bin/ncpmount %(SERVER)/%(USER) %(MNTPT) -o "pass-fd=0,volume=%(VOLUME)%(before=\",\" OPTIONS)" /usr/bin/smbumount %(MNTPT) /usr/bin/ncpumount %(MNTPT) /sbin/mount.fuse %(VOLUME) %(MNTPT) "%(before=\"-o\" OPTIONS)" /usr/bin/fusermount -u %(MNTPT) /bin/umount %(MNTPT) /bin/mount -p0 -t %(FSTYPE) %(VOLUME) %(MNTPT) "%(before=\"-o\" OPTIONS)" /bin/mount -t crypt "%(before=\"-o\" OPTIONS)" %(VOLUME) %(MNTPT) /bin/mount %(SERVER):%(VOLUME) %(MNTPT) "%(before=\"-o\" OPTIONS)" /bin/mount /usr/sbin/pmvarrun -u %(USER) -o %(OPERATION) note that developer is in a flash memory... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From paul at all-the-johnsons.co.uk Sat Sep 13 16:26:56 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 13 Sep 2008 17:26:56 +0100 Subject: Pushing from f9-update-candidates to f9-updates Message-ID: <1221323216.2714.1.camel@PB3.Linux> Hi, I've uploaded a pile of mono and xmms updates to f9-update-candidates and they've built fine. Is there a way that I can push them into f9-updates? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From opensource at till.name Sat Sep 13 16:29:36 2008 From: opensource at till.name (Till Maas) Date: Sat, 13 Sep 2008 18:29:36 +0200 Subject: Yum broken & PAM-mount broken In-Reply-To: <48CBE02B.5080401@gmail.com> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <200809131706.12332.opensource@till.name> <48CBE02B.5080401@gmail.com> Message-ID: <200809131829.42026.opensource@till.name> On Sat September 13 2008, Casimiro de Almeida Barreto wrote: > I'm transcripting the debugging information. First of all I have an > encripted "partition" for /home/casimiro that is mount via loop0. It was > working well until last update. It is still mounting when I use input lile: > > # openssl aes-256-cbc -d -in /etc/pki/cryptofs/mykey.key | mount -p0 -o > loop,encryption=aes-cbc-256,rw /xxx/yyy.img /home/casimiro There is a bug fixed in pam_mount 0.48 that fixes a bug that is triggered in your setup. If you have a FAS account and a client certificate in the .fedora.cert file and the Fedora server ca cert in the .fedora-server-ca.cert file, then you can already securly download the rpm for i386 with the following command: wget --ca-certificate=.fedora-server-ca.cert --certificate .fedora.cert --private-key .fedora.cert -O pam_mount-0.48-2.fc9.i386.rpm "https://koji.fedoraproject.org/koji/getfile?taskID=824307&name=pam_mount-0.48-2.fc9.i386.rpm" Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From kevin.kofler at chello.at Sat Sep 13 16:57:02 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 13 Sep 2008 16:57:02 +0000 (UTC) Subject: Pushing from f9-update-candidates to f9-updates References: <1221323216.2714.1.camel@PB3.Linux> Message-ID: Paul all-the-johnsons.co.uk> writes: > I've uploaded a pile of mono and xmms updates to f9-update-candidates > and they've built fine. Is there a way that I can push them into > f9-updates? Yes, that's what Bodhi is for. https://admin.fedoraproject.org/updates/ How you can still not know that considering that Bodhi has been in use since Fedora 7 is beyond me. Kevin Kofler From walters at verbum.org Sat Sep 13 17:06:22 2008 From: walters at verbum.org (Colin Walters) Date: Sat, 13 Sep 2008 13:06:22 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: On Sat, Sep 13, 2008 at 12:30 AM, Matthew Woehlke wrote: > > Aside from the fact that this little nugget derailed the thread due to the > many people (rightly*, IMO) freaking out, I fail to see where any part of > your message to which I am replying was of any relevance whatsoever to this > thread. PA as a system daemon should work (or, perhaps, not work) regardless > of what happens to "non-X system consoles" in the future. Nor do I even see > where Janina said *anything* about them, or even about consoles or the CLI > in general. As I understood it, pulse as a system daemon was at least partially by the desire to use it on a console, outside of a normal X login (and all the infrastructure that comes with X, like the DBus session bus which defines the session). From paul at all-the-johnsons.co.uk Sat Sep 13 17:25:42 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 13 Sep 2008 18:25:42 +0100 Subject: Pushing from f9-update-candidates to f9-updates In-Reply-To: References: <1221323216.2714.1.camel@PB3.Linux> Message-ID: <1221326742.3169.1.camel@PB3.Linux> Hi, > > I've uploaded a pile of mono and xmms updates to f9-update-candidates > > and they've built fine. Is there a way that I can push them into > > f9-updates? > > Yes, that's what Bodhi is for. > https://admin.fedoraproject.org/updates/ > How you can still not know that considering that Bodhi has been in use since > Fedora 7 is beyond me. Ah... Bodhi... According to the bodhi docs, -r accepts F7 and F8, not F9 which is what I need. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From janina at rednote.net Sat Sep 13 17:27:09 2008 From: janina at rednote.net (Janina Sajka) Date: Sat, 13 Sep 2008 13:27:09 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: <20080913172709.GF4421@sonata.rednote.net> Colin Walters writes: > As I understood it, pulse as a system daemon was at least partially by > the desire to use it on a console, outside of a normal X login (and > all the infrastructure that comes with X, like the DBus session bus > which defines the session). > That's one use case. Someone here had another use case that was GUI. There are probably additional use cases, and pulseaudio.org lays out advantages and disadvantages of per user vs daemon mode. The need is to support all the legitimate use cases. At this point I would be happy with a pointer to a reasonably similar init script as a starting point. I know you don't care about consoles--I got that. But, I do, and apparently I'm not alone. Surely the Fedora tent is big enough. PS: Speaking strictly personally, I runlevel 5 by default. I like it that way. I'm thrilled to finally have an up to date browser in Firefox 3, which is working very well with Orca, thank you. And, I'm using Open Office more and more. But, I still launch 24 consoles when I boot, because I actually use most of them in very specific ways. About 6 of these 24 run screen with 9 separate terminal windows defined by ~/.screenrc. I don't see gnome terminal replacing that anytime soon. Yes, I'm familiar with gnome terminal. I'm reduced to it, and reduced to gedit, when I have to run my laptop all day long on batteries, meaning that I suspend frequently. Because of issues between the TTS engine driver and alsa, I can't effectively resume consoles right now--screen appears to be full of null chars, which rather defeats the screen reader. I get by with terminal, and gedit for notes, but it's a case of getting by. No way can I replicate my rapid, key-combination-based random access to the various tasks I park in particular consoles on gnome-terminal, when all I have to allow cycling among them is Alt+TAB or maybe a series of desktop shortcuts. That would be too slow and inefficient, in my experience to date. Janina > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka, Phone: +1.202.595.7777; sip:janina at a11y.org Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada Learn more at http://ScreenlessPhone.Com Chair, Open Accessibility janina at a11y.org Linux Foundation http://a11y.org From kevin.kofler at chello.at Sat Sep 13 17:29:53 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 13 Sep 2008 17:29:53 +0000 (UTC) Subject: Pushing from f9-update-candidates to f9-updates References: <1221323216.2714.1.camel@PB3.Linux> <1221326742.3169.1.camel@PB3.Linux> Message-ID: Paul all-the-johnsons.co.uk> writes: > According to the bodhi docs, -r accepts F7 and F8, not F9 which is what > I need. That just means either the documentation is outdated or your version of the Bodhi client is outdated. In any case, you can always use the web interface at https://admin.fedoraproject.org/updates/ . You don't have to specify the Fedora release at all anymore, it's figured out automatically from the builds you include in the update. Kevin Kofler From walters at verbum.org Sat Sep 13 17:41:42 2008 From: walters at verbum.org (Colin Walters) Date: Sat, 13 Sep 2008 13:41:42 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080913172709.GF4421@sonata.rednote.net> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <20080913172709.GF4421@sonata.rednote.net> Message-ID: On Sat, Sep 13, 2008 at 1:27 PM, Janina Sajka wrote: > > But, I still launch 24 consoles when I boot, because I actually use most > of them in very specific ways. About 6 of these 24 run screen with 9 > separate terminal windows defined by ~/.screenrc. I don't see gnome > terminal replacing that anytime soon. It has tabs, and you can script it; I don't see what wouldn't work with your setup. From benny+usenet at amorsen.dk Sat Sep 13 18:40:17 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Sat, 13 Sep 2008 20:40:17 +0200 Subject: change isdn4k-utils to optional References: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> <20080913102118.GA8601@jasmine.xos.nl> <20080913140643.40ae1d3d@lain.camperquake.de> Message-ID: Ralf Ertzinger writes: > There are (and always will be, I suspect) places where anything faster > than ISDN will simply not be available. Do you know anyone who uses dialup ISDN? Generally people around here who use dialup use it on their cell phones (which is fairly hard to set up in Fedora, by the way). There are still a few users on analog dialup too. But ISDN? No way. /Benny From mcepl at redhat.com Sat Sep 13 18:58:04 2008 From: mcepl at redhat.com (Matej Cepl) Date: Sat, 13 Sep 2008 20:58:04 +0200 Subject: SWAMP -- is it good for anything? Message-ID: Somebody from SUSE mentioned open-sourced swap -- their tool for workflow management (http://swamp.sf.net). Would it help to anything in Fedora? Mat?j From debarshi.ray at gmail.com Sat Sep 13 20:07:19 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Sun, 14 Sep 2008 01:37:19 +0530 Subject: LDTP and Pystatgrab Message-ID: <3170f42f0809131307s42581281qc710bd2e7fd8eb8b@mail.gmail.com> Just to avoid stepping onto someone's toes, I am working on packaging LDTP [1] and its dependency Pystatgrab [2]. Will keep you posted. Happy hacking, Debarshi [1] http://ldtp.freedesktop.org/ [2] http://www.i-scream.org/pystatgrab/ From jonstanley at gmail.com Sat Sep 13 23:18:58 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Sat, 13 Sep 2008 19:18:58 -0400 Subject: Why I'll leave fedora (french speaking people only) [1] In-Reply-To: <604aa7910809071223j322fde86s8fc3221f3edcb081@mail.gmail.com> References: <200809070135.54996.alain.portal@free.fr> <48C337DA.2050009@gmail.com> <1220754913.17785.105.camel@rosebud> <48C3ABE6.7040909@gmail.com> <20080907103235.194c5a66@ohm.scrye.com> <604aa7910809071223j322fde86s8fc3221f3edcb081@mail.gmail.com> Message-ID: On Sun, Sep 7, 2008 at 3:23 PM, Jeff Spaleta wrote: > Setting aside the specific people and problems bubbling up right now. > Would it make sense for the Board to try to take up the issue of some > sort of established process to follow when there are language barriers > getting in the way of normal dispute resolution? So we can try to get > ahead this sort of situation when it happens again. Apologies for not seeing this earlier, just catching up on some old mail that I have neglected :(. I'm not sure that the Board needs to make a policy for this sort of thing, it (hopefully) doesn't happen often and can be dealt with on a case-by-case basis when it does. Though reaching out earlier than the point that it becomes a crisis would be helpful. > I can imagine that this might be a place where our Ambassador pool can > be called on to act as mediators/arbitration if the are willing to > take on that role. I think that this is an excellent idea, and had thought of the same myself in this particular situation. Has anyone reached out to the ambassadors to deal with the situation at hand? I'm looking at a rawhide install right now with the man-pages-fr conflict :( From pemboa at gmail.com Sun Sep 14 03:06:01 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Sat, 13 Sep 2008 22:06:01 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <20080913172709.GF4421@sonata.rednote.net> Message-ID: <16de708d0809132006pc030324wf0963e70a0797b5a@mail.gmail.com> On Sat, Sep 13, 2008 at 12:41 PM, Colin Walters wrote: > On Sat, Sep 13, 2008 at 1:27 PM, Janina Sajka wrote: >> >> But, I still launch 24 consoles when I boot, because I actually use most >> of them in very specific ways. About 6 of these 24 run screen with 9 >> separate terminal windows defined by ~/.screenrc. I don't see gnome >> terminal replacing that anytime soon. > > It has tabs, and you can script it; I don't see what wouldn't work > with your setup. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I just updated from an Intel Celeron D 2.8Ghz 533Mhz FSB to an Intel P4 3.0Hz 800Mhz FSB, which in turned allowed my memory to operate at 400Mhz instead of 333MHz. One of the noticeable improvements is that I can use Firefox + Pulseaudio + Amarok. Previously, at 4 or 5 tabs, scrolling, or similar activity in Firefox would somehow bring about Pulseaudio's demise. Top reports Pulse audio between 30% and 55% CPU usage. -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From weston_schmidt at alumni.purdue.edu Sun Sep 14 05:56:01 2008 From: weston_schmidt at alumni.purdue.edu (Weston T. Schmidt) Date: Sat, 13 Sep 2008 22:56:01 -0700 Subject: [RFC Fedora 10] kill pam_console In-Reply-To: <48C8C23D.5030208@alumni.purdue.edu> References: <48C8C23D.5030208@alumni.purdue.edu> Message-ID: <48CCA771.3000804@alumni.purdue.edu> Cancel my request. I was able to figure out what was wrong. I placed the file in the policy directory and it should have been place in the information directory. --Wes Weston T. Schmidt wrote: > Bill, > > I'm the maintainer for dfu-programmer. I've been trying to get the > HAL permissions to work & I can't figure out what I'm missing. > Basically, I need to be able to recognize a usb device is attached and > permit the console user to communicate with the usb dfu interface. > I'm able to see the device & the properties I added, but get > permission denied when I try to access the device. I'm a member of > the uucp group (I don't like this approach - I'd rather give the > active user permissions, but I couldn't figure that out either). > > Any help will be greatly appreciated. > > --Wes > > What I thought worked for dfu-programmer, but apparently doesn't: > > > > > > > > > > > > > > int_outof="0x2fff;0x2ffb;0x2ffb;0x2ffa"> > type="strlist">dfu-device > type="strlist">uucp > > > > > > type="strlist">access_control > type="copy_property">linux.device_file > dfu-device > > > > From abraxis at telkomsa.net Sun Sep 14 06:50:03 2008 From: abraxis at telkomsa.net (Neil Thompson) Date: Sun, 14 Sep 2008 08:50:03 +0200 Subject: change isdn4k-utils to optional In-Reply-To: References: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> <20080913102118.GA8601@jasmine.xos.nl> <20080913140643.40ae1d3d@lain.camperquake.de> Message-ID: <20080914065003.GA17842@wol.32.boerneef.vornavalley> On Sat, Sep 13, 2008 at 08:40:17PM +0200, Benny Amorsen wrote: > Ralf Ertzinger writes: > > > There are (and always will be, I suspect) places where anything faster > > than ISDN will simply not be available. > > Do you know anyone who uses dialup ISDN? > > Generally people around here who use dialup use it on their cell > phones (which is fairly hard to set up in Fedora, by the way). There > are still a few users on analog dialup too. But ISDN? No way. > We don't all live in the first world, you know. Around here (in Africa) there are many (maybe most) people on ISDN and ordinary landline dialup. And those are the people who can afford communications. -- Cheers! (Relax...have a homebrew) Neil ...aliquando et insanire iucundum est. -- Lucius Annaeus Seneca From rc040203 at freenet.de Sun Sep 14 08:35:31 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 14 Sep 2008 10:35:31 +0200 Subject: change isdn4k-utils to optional In-Reply-To: References: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> <20080913102118.GA8601@jasmine.xos.nl> <20080913140643.40ae1d3d@lain.camperquake.de> Message-ID: <1221381331.18327.532.camel@beck.corsepiu.local> On Sat, 2008-09-13 at 20:40 +0200, Benny Amorsen wrote: > Ralf Ertzinger writes: > > > There are (and always will be, I suspect) places where anything faster > > than ISDN will simply not be available. Definitely. > Do you know anyone who uses dialup ISDN? Yes, ... typically these are people, who use ISDN for landline phone communication and who don't feel to have a need or do not want to allocate a budget for better internet access. > Generally people around here who use dialup use it on their cell > phones (which is fairly hard to set up in Fedora, by the way). There > are still a few users on analog dialup too. But ISDN? No way. Well, in Germany approx. 1/3 of all landline phones are ISDN, with VolIP gradually gaining increasing importance over both ISDN and analog in phone communication. At the same time, internet access is rapidly switching over to broadband, having reduced small band internet access (analog/ISDN etc.) to a fraction of what it used to be some years ago[1]. I.e. nowadays, in Germany, ISDN is still a major player in voice phone communication, while ISDN dialups are rapidly following the importance of analog dialups. Finally, consider, there is another set of use-cases for ISDN on Linux: phone-applications (answering machines, fax-servers, ...). Ralf [1] http://www.bundesnetzagentur.de/media/archive/13212.pdf [German Federal Network Agency's 2007 Annual Report (German only)] From konrad at tylerc.org Sun Sep 14 09:07:07 2008 From: konrad at tylerc.org (Conrad Meyer) Date: Sun, 14 Sep 2008 02:07:07 -0700 Subject: change isdn4k-utils to optional In-Reply-To: <1221381331.18327.532.camel@beck.corsepiu.local> References: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> <1221381331.18327.532.camel@beck.corsepiu.local> Message-ID: <200809140207.08044.konrad@tylerc.org> Quoth Ralf Corsepius: > I.e. nowadays, in Germany, ISDN is still a major player in voice phone > communication, while ISDN dialups are rapidly following the importance > of analog dialups. > > Finally, consider, there is another set of use-cases for ISDN on Linux: > phone-applications (answering machines, fax-servers, ...). Right, the OP wasn't talking about removing the package from Fedora entirely, but disabling it as a default installed package. Users who need ISDN for non-internet purposes can always download the isdn packages from repositories, whereas those who need it to connect to the internet would be out of luck if it was disabled by default (for new installs, anyways). > Ralf > > [1] http://www.bundesnetzagentur.de/media/archive/13212.pdf > [German Federal Network Agency's 2007 Annual Report (German only)] Regards, -- Conrad Meyer From drago01 at gmail.com Sun Sep 14 10:35:32 2008 From: drago01 at gmail.com (drago01) Date: Sun, 14 Sep 2008 12:35:32 +0200 Subject: make force-tag gone In-Reply-To: <1221234383.15726.194.camel@localhost.localdomain> References: <1220955240.24928.69.camel@cookie.hadess.net> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> <48CA16D1.5070409@redhat.com> <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> <1221234383.15726.194.camel@localhost.localdomain> Message-ID: Was away for one week and now make force-tag no longer works.... Why do we need to bump the release and changelog for every small change? ex: typo? This makes the changelog useless to read and fills the users rpmdb/disk with crap entries "forgot to add a patch"; "fix a typo", etc. +1 for adding it back. Just removing stuff does not solve problems you have to implement a better alternative first (and not rely on a worse one). From dominik at greysector.net Sun Sep 14 11:30:12 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 14 Sep 2008 13:30:12 +0200 Subject: make force-tag gone In-Reply-To: References: <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> <48CA16D1.5070409@redhat.com> <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> <1221234383.15726.194.camel@localhost.localdomain> Message-ID: <20080914113011.GF9241@mokona.greysector.net> On Sunday, 14 September 2008 at 12:35, drago01 wrote: > Was away for one week and now make force-tag no longer works.... > Why do we need to bump the release and changelog for every small > change? ex: typo? > This makes the changelog useless to read and fills the users > rpmdb/disk with crap entries "forgot to add a patch"; "fix a typo", > etc. > > +1 for adding it back. > > Just removing stuff does not solve problems you have to implement a > better alternative first (and not rely on a worse one). Frankly I didn't even know it existed until this thread and always used cvs tag -F. ;) Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From gdt at gdt.id.au Sun Sep 14 12:13:53 2008 From: gdt at gdt.id.au (Glen Turner) Date: Sun, 14 Sep 2008 21:43:53 +0930 Subject: system autodeath Message-ID: <48CD0001.8010301@gdt.id.au> Hello, I am the author of the Wiki page with the suggestion. A friend showed me this discussion and I'd like to add a few points. MOTIVATION The intent is to remove machines which are subvertable from the Internet. My employer provides network connectivity to universities, and it's very evident in traffic profiles when a distribution ceases maintenance and an exploit for a never-to-be-patched flaw sweeps across the network. In the past we found a real person for the IP address which has been subverted, educated that person in the evil side of the Internet, and then encouraged them to act. Today -- like most ISPs -- we are becoming less and less generous about this massive waste of our time. I can see the day arriving where we automatically blackhole machines which reach some threshold in the IDS systems. Of course, this is less than optimal, as the first thing we'll see is misuse of that automation by some IRC user upset at other IRC users. The loss of default route is no different to what we do if we can't get a subverted machine fixed -- we simply set our routing table to blackhole all traffic to and from that machine. The end result for an EOL machine is the same -- it is only a matter of timing and cost. This motivation is substantially different to the motivation for Windows Genuine Advantage. In fact, WGA discourages some users from being up to date with patches, which is counter to our goal. GUI V SERVER There's no difference between server and desktop machines. From a networking perspective a desktop Linux machine is simply a server which has a console user for a third of the day. Unfortunately, desktop machines are now so abundant in computing resources that users generally do not notice exploit behaviour. Nagging GUI users would be fine. But that would be a related package, not this one. PHILOSOPHY To be effective, the package will need to be installed by default. I do realise that this is a big ask, and something likely to be achieved by small steps. People will need to become conversant with the idea and happy with the quality of the implementation. If a sysadmin intends deploying a machine past EOL, they can simply remove the autodeath package. If a sysadmin needs to stop autodeath acting (because it is hosing an important machine) then there should be two configuration switches: - a "not now" toggle, which is re-set on OS upgrade - a "never" switch, which disables autodeath from acting, ever. Because the configuration holds the expiry date, logwatch can warn of expiring Internet connectivity for a machine, just as it warns of expiring certificates today. Someone mentioned "tyranny". I rather think of this as correctly assigning the work from a unmaintained machine. Making the system owner of the machine deal with their lack of an upgrade plan is much, much fairer than pushing the cost onto network administrators, ISPs or onto those people DDoSed by a subverted machine. And yes, we've all failed at various times to do the work of a timely upgrade of a short-life operating system. A lot of the argument seems to be that avoiding a penalty for this is OK. I'd argue in return that this is mix of hubris (my machine would never be subverted) and cost-shifting (a subversion will harm others more than me). Best wishes to all, Glen -- Glen Turner From mschwendt at gmail.com Sun Sep 14 12:23:39 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Sun, 14 Sep 2008 14:23:39 +0200 Subject: make force-tag gone In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> <48CA16D1.5070409@redhat.com> <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> <1221234383.15726.194.camel@localhost.localdomain> Message-ID: <20080914142339.2af3b7c8.mschwendt@gmail.com> On Sun, 14 Sep 2008 12:35:32 +0200, drago01 wrote: > Was away for one week and now make force-tag no longer works.... > Why do we need to bump the release and changelog for every small > change? ex: typo? > This makes the changelog useless to read and fills the users > rpmdb/disk with crap entries "forgot to add a patch"; "fix a typo", > etc. No need to add a changelog for typo fixes and such. It is ridiculous to fill the changelog with irrelevant data. The requirement that package EVR is added to every changelog entry is questionable in such cases, too. > +1 for adding it back. > > Just removing stuff does not solve problems you have to implement a > better alternative first (and not rely on a worse one). I've never used the force-tag option, but "TAG_OPTS=-F make tag" a few times for "lame commits" where I forgot to add a file or made a typo. It TAG_OPTS will be blocked, too, I don't care. It's fine with me to simply bump release. But I won't add a completely new changelog entry for minor fixes in unreleased revisions. From sgrubb at redhat.com Sun Sep 14 13:19:50 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Sun, 14 Sep 2008 09:19:50 -0400 Subject: make force-tag gone In-Reply-To: <1220978806.11620.6.camel@luminos.localdomain> References: <1220955240.24928.69.camel@cookie.hadess.net> <48C69E37.5090205@poolshark.org> <1220978806.11620.6.camel@luminos.localdomain> Message-ID: <200809140919.50743.sgrubb@redhat.com> On Tuesday 09 September 2008 12:46:46 Jesse Keating wrote: > MikeB said that he'd look into some CVS/make changes that would allow > checking koji for an on going or successful build of a tag/n-v-r before > allowing a force-tag. ?This would allow folks to force-tag before having > a successful build, but would not allow you to force the tag after a > successful build, or while a build is still going with that n-v-r. > > I think this approach, while it may slow down force-tags and prevent > force-tags during any koji outage, will give us the best of both worlds. I think this is the best solution. If you do a make force-tag, I don't care if it takes 2 minutes vs 15 seconds for normal tags. I am faced right now with debugging a failure in a test suite and will need to bump the release number a bunch of times to troubleshoot the problem. Previously I could use force-tag so that scratch builds don't increment the count and when its resolved I have the release number I meant to. If we are going to this policy, I think the people enforcing it should have the tools already in place and working so that they do not impact the community without reason. The way this is being done is about as disruptive as when someone does a soname bump without telling anyone. Please put it back until someone comes up with a way to give release engineers what they want and package maintainers what they want. In the mean time I will needlessly bump my package release number and add a commit message stating why I changed my package for the next release. I hope PackageKit can display all the text this creates for my release notes. -Steve From bnocera at redhat.com Sun Sep 14 13:25:03 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Sun, 14 Sep 2008 14:25:03 +0100 Subject: Does your package provide GStreamer plugins? In-Reply-To: <935ead450809120606g2a0a93e2p350d9917417d180e@mail.gmail.com> References: <1221215325.24928.235.camel@cookie.hadess.net> <935ead450809120606g2a0a93e2p350d9917417d180e@mail.gmail.com> Message-ID: <1221398703.24928.289.camel@cookie.hadess.net> On Fri, 2008-09-12 at 08:06 -0500, Jeffrey Ollie wrote: > On Fri, Sep 12, 2008 at 5:28 AM, Bastien Nocera wrote: > > > > If your package provides GStreamer plugins, please rebuild it in rawhide > > with the latest gstreamer-devel and RPM builds. > > > > We are trying to use a PackageKit-based solution to installing missing > > GStreamer plugins. The new GStreamer and RPM packages will add strings > > like this to your RPM's provides: > > gstreamer0.10(urisource-ssh)()(64bit) > > gstreamer0.10(decoder-application/ogg)()(64bit) > > I tried rebuilding schroedinger but I didn't see any new provides show > up. Is there something I'm doing wrong? Here's a scratch build I > just did: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=822502 An updated gstreamer package is building, let me know whether that fixes the problem for you: http://koji.fedoraproject.org/koji/taskinfo?taskID=825065 Cheers From sgrubb at redhat.com Sun Sep 14 14:10:32 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Sun, 14 Sep 2008 10:10:32 -0400 Subject: make force-tag gone In-Reply-To: <200809140919.50743.sgrubb@redhat.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <1220978806.11620.6.camel@luminos.localdomain> <200809140919.50743.sgrubb@redhat.com> Message-ID: <200809141010.32753.sgrubb@redhat.com> On Sunday 14 September 2008 09:19:50 Steve Grubb wrote: > In the mean time I will needlessly bump my package release number and add a > commit message stating why I changed my package for the next release. I > hope PackageKit can display all the text this creates for my release notes. OK, it took 3 builds to get libprelude squared away. Now because force-tag is no longer available, we have libprelude-0.9.20.2-1 in rawhide and libprelude-0.9.20.2-3 aimed at F-9 inclusion. Does anaconda favor packages that are part of the right release even when the release number is smaller? Was this one of the consequences considered before implementing a mandatory policy? Whoever does that n-v-r upgrade from F-9 to F-10 report may need to take into account that we all have to increment release numbers which makes it real hard to get the upgrade path right if anaconda does not favor packages within its own repo. -Steve From wtogami at redhat.com Sun Sep 14 14:16:03 2008 From: wtogami at redhat.com (Warren Togami) Date: Sun, 14 Sep 2008 10:16:03 -0400 Subject: Proposal: Better force-tag In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> <48CA16D1.5070409@redhat.com> <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> <1221234383.15726.194.camel@localhost.localdomain> Message-ID: <48CD1CA3.5060302@redhat.com> drago01 wrote: > Was away for one week and now make force-tag no longer works.... > Why do we need to bump the release and changelog for every small > change? ex: typo? > This makes the changelog useless to read and fills the users > rpmdb/disk with crap entries "forgot to add a patch"; "fix a typo", > etc. > > +1 for adding it back. > > Just removing stuff does not solve problems you have to implement a > better alternative first (and not rely on a worse one). > Since nothing stops the user from using TAG_OPTS=-F, it is ineffective of us to remove force-tag. How about an improved force-tag instead? Make force-tag use koji to check if a build for that N-V-R is already complete. If it is complete, then refuse to tag again with the same N-V-R. Warren Togami wtogami at redhat.com From fedora at camperquake.de Sun Sep 14 14:18:10 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 14 Sep 2008 16:18:10 +0200 Subject: change isdn4k-utils to optional In-Reply-To: References: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> <20080913102118.GA8601@jasmine.xos.nl> <20080913140643.40ae1d3d@lain.camperquake.de> Message-ID: <20080914161810.55f8678e@lain.camperquake.de> Hi. On Sat, 13 Sep 2008 20:40:17 +0200, Benny Amorsen wrote > Do you know anyone who uses dialup ISDN? I work for an ISP in a definitely first world country, and yes, we do have ISDN dialup customers. Hell, we even have analogue ones. From fedora at camperquake.de Sun Sep 14 14:19:48 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 14 Sep 2008 16:19:48 +0200 Subject: change isdn4k-utils to optional In-Reply-To: <200809140207.08044.konrad@tylerc.org> References: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> <1221381331.18327.532.camel@beck.corsepiu.local> <200809140207.08044.konrad@tylerc.org> Message-ID: <20080914161948.18e1eace@lain.camperquake.de> Hi. On Sun, 14 Sep 2008 02:07:07 -0700, Conrad Meyer wrote > Right, the OP wasn't talking about removing the package from Fedora > entirely, but disabling it as a default installed package. Users who > need ISDN for non-internet purposes can always download the isdn > packages from repositories, whereas those who need it to connect to > the internet would be out of luck if it was disabled by default (for > new installs, anyways). Thus, my suggestion to split the package into the bits needed for internet access and those not. From kevin.kofler at chello.at Sun Sep 14 14:22:00 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 14 Sep 2008 14:22:00 +0000 (UTC) Subject: make force-tag gone References: <1220955240.24928.69.camel@cookie.hadess.net> <1220978806.11620.6.camel@luminos.localdomain> <200809140919.50743.sgrubb@redhat.com> <200809141010.32753.sgrubb@redhat.com> Message-ID: Steve Grubb redhat.com> writes: > OK, it took 3 builds to get libprelude squared away. Now because force-tag is > no longer available, we have libprelude-0.9.20.2-1 in rawhide and > libprelude-0.9.20.2-3 aimed at F-9 inclusion. > > Does anaconda favor packages that are part of the right release even when the > release number is smaller? No, it doesn't, and probably never will. EVR comparisons are used in many places, it would be pretty stupid to make Anaconda behave specially there. What about people doing live yum upgrades? Or even apt-get dist-upgrade? You have to bump and rebuild the Rawhide package now too. > Was this one of the consequences considered before implementing a mandatory > policy? This problem also existed (to a lesser extent, sure, but it did) before the removal of force-tag and there's already a perfectly valid solution: you MUST NOT bump from -1 to -3 in F9, instead, you bump from 1%{?dist} to 1%{dist}.1 (and then 1%{?dist}.2 etc.), because 1.fc10 will still be larger than 1.fc9.2. > Whoever does that n-v-r upgrade from F-9 to F-10 report may need to take into > account that we all have to increment release numbers which makes it real > hard to get the upgrade path right if anaconda does not favor packages within > its own repo. This is impossible to "take into account", you have to make the upgrade path work for users no matter how hard it is. There can't be any tolerance because any error makes users end up with the wrong package, potentially causing dependency issues or other problems. You have to bump and rebuild the Rawhide package now. And next time do it the right way (see the paragraph above). Removing force-tag sucks in many ways, but this isn't one of them. Kevin Kofler From ivazqueznet at gmail.com Sun Sep 14 14:29:50 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sun, 14 Sep 2008 10:29:50 -0400 Subject: Proposal: Better force-tag In-Reply-To: <48CD1CA3.5060302@redhat.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> <48CA16D1.5070409@redhat.com> <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> <1221234383.15726.194.camel@localhost.localdomain> <48CD1CA3.5060302@redhat.com> Message-ID: <1221402590.27183.172.camel@ignacio.lan> On Sun, 2008-09-14 at 10:16 -0400, Warren Togami wrote: > drago01 wrote: > > Just removing stuff does not solve problems you have to implement a > > better alternative first (and not rely on a worse one). > > Since nothing stops the user from using TAG_OPTS=-F, it is ineffective > of us to remove force-tag. How about an improved force-tag instead? > > Make force-tag use koji to check if a build for that N-V-R is already > complete. If it is complete, then refuse to tag again with the same N-V-R. Ultimately nothing can stop the user from using cvs tag -F, so any solution (including this one, which I like a lot) would have to be server-side. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tmz at pobox.com Sun Sep 14 14:29:55 2008 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 14 Sep 2008 10:29:55 -0400 Subject: make force-tag gone In-Reply-To: <200809141010.32753.sgrubb@redhat.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <1220978806.11620.6.camel@luminos.localdomain> <200809140919.50743.sgrubb@redhat.com> <200809141010.32753.sgrubb@redhat.com> Message-ID: <20080914142955.GU2939@inocybe.teonanacatl.org> Steve Grubb wrote: > OK, it took 3 builds to get libprelude squared away. Now because > force-tag is no longer available, we have libprelude-0.9.20.2-1 in > rawhide and libprelude-0.9.20.2-3 aimed at F-9 inclusion. [...] > Whoever does that n-v-r upgrade from F-9 to F-10 report may need to > take into account that we all have to increment release numbers > which makes it real hard to get the upgrade path right if anaconda > does not favor packages within its own repo. Not to ignore the hassle factor for you, but I think that regardless of the reason that the F-9 branch needed to be rebuilt more often than the devel branch, this section of the guidelines covers how best to handle such bumps in older branches: https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches So you could have just bumped the F-9 branch to 0.9.20.2-1.fc9.1, .2, etc. Then it would still have an n-v-r less than the devel branch does at 0.9.20.2-1.fc10. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ You know an odd feeling? Sitting on the toilet eating a chocolate candy bar. -- George Carlin, Napalm & Silly Putty -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From kevin.kofler at chello.at Sun Sep 14 14:32:23 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 14 Sep 2008 14:32:23 +0000 (UTC) Subject: make force-tag gone References: <1220955240.24928.69.camel@cookie.hadess.net> <1220978806.11620.6.camel@luminos.localdomain> <200809140919.50743.sgrubb@redhat.com> <200809141010.32753.sgrubb@redhat.com> Message-ID: I wrote: > You have to bump and rebuild the Rawhide package now too. Actually, I just did that for you in this case. But normally, this is the maintainer's job, and doing the F-9 bumps the right way, it isn't necessary. Kevin Kofler From kevin.kofler at chello.at Sun Sep 14 14:41:37 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 14 Sep 2008 14:41:37 +0000 (UTC) Subject: make force-tag gone References: <1220955240.24928.69.camel@cookie.hadess.net> <1220978806.11620.6.camel@luminos.localdomain> <200809140919.50743.sgrubb@redhat.com> <200809141010.32753.sgrubb@redhat.com> Message-ID: I wrote: > > You have to bump and rebuild the Rawhide package now too. > > Actually, I just did that for you in this case. But normally, this is the > maintainer's job, and doing the F-9 bumps the right way, it isn't necessary. Well, the build failed, so it looks like the fixes actually need to go into the Rawhide package too. Right now you have not only an upgrade path bug, but also an FTBFS bug. Please fix libprelude ASAP. Kevin Kofler From cra at WPI.EDU Sun Sep 14 14:45:02 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Sun, 14 Sep 2008 10:45:02 -0400 Subject: make force-tag gone In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> <1220978806.11620.6.camel@luminos.localdomain> <200809140919.50743.sgrubb@redhat.com> <200809141010.32753.sgrubb@redhat.com> Message-ID: <20080914144502.GA27836@angus.ind.WPI.EDU> On Sun, Sep 14, 2008 at 02:32:23PM +0000, Kevin Kofler wrote: > I wrote: > > You have to bump and rebuild the Rawhide package now too. > > Actually, I just did that for you in this case. But normally, this is the > maintainer's job, and doing the F-9 bumps the right way, it isn't necessary. How hard would it be to enforce upgrade paths automatically? When a bump happens in any older branch, automatically bump (but don't necessarily build yet) newer branches? From pekkas at netcore.fi Sun Sep 14 14:47:14 2008 From: pekkas at netcore.fi (Pekka Savola) Date: Sun, 14 Sep 2008 17:47:14 +0300 (EEST) Subject: graphics w/ 2.6.26.3-29 kernel sluggish, 2.6.25.14-108 OK? In-Reply-To: References: Message-ID: On Sat, 13 Sep 2008, Pekka Savola wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=462180 This appears to affect non-graphics as well, see the bug for more. I noticed interesting thing on both 2.6.26 and 2.6.25 though. If I boot using "nosmp" option, bootup freezes at "Starting udev". "acpi=off nosmp" works though, as works the default option. This is a a single CPU system. Seems pretty strange. I wonder if this intentional? There doesn't seem to be any bug filed on this, the closest (inverse to this) was: https://bugzilla.redhat.com/show_bug.cgi?id=405361 -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From dominik at greysector.net Sun Sep 14 15:22:53 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Sun, 14 Sep 2008 17:22:53 +0200 Subject: make force-tag gone In-Reply-To: <20080914144502.GA27836@angus.ind.WPI.EDU> References: <1220955240.24928.69.camel@cookie.hadess.net> <1220978806.11620.6.camel@luminos.localdomain> <200809140919.50743.sgrubb@redhat.com> <200809141010.32753.sgrubb@redhat.com> <20080914144502.GA27836@angus.ind.WPI.EDU> Message-ID: <20080914152253.GL9241@mokona.greysector.net> On Sunday, 14 September 2008 at 16:45, Chuck Anderson wrote: > On Sun, Sep 14, 2008 at 02:32:23PM +0000, Kevin Kofler wrote: > > I wrote: > > > You have to bump and rebuild the Rawhide package now too. > > > > Actually, I just did that for you in this case. But normally, this is the > > maintainer's job, and doing the F-9 bumps the right way, it isn't necessary. > > How hard would it be to enforce upgrade paths automatically? When a > bump happens in any older branch, automatically bump (but don't > necessarily build yet) newer branches? Bad idea. Instead, refuse a package that would break the upgrade path to be added to updates in bodhi. And make make build complain loudly if the package you're about to build breaks upgrade path. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From choeger at cs.tu-berlin.de Sun Sep 14 15:25:48 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Sun, 14 Sep 2008 17:25:48 +0200 Subject: feedback wanted: tracetrap.py Message-ID: <1221405948.3552.6.camel@choeger6> Hi, this is the first public version of a little script I wrote. The main purpose is to get a strace output of an executable that runs somewhere in the future. This works by replacing the original file with a wrapper script. I would appreciate any feedback. If you test it, be aware, that little bugs may destroy the original file so make another backup copy ;). regards christoph -------------- next part -------------- GNU GENERAL PUBLIC LICENSE Version 3, 29 June 2007 Copyright (C) 2007 Free Software Foundation, Inc. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The GNU General Public License is a free, copyleft license for software and other kinds of works. The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work released this way by its authors. You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things. To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others. For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it. For the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software. For both users' and authors' sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions. Some devices are designed to deny users access to install or run modified versions of the software inside them, although the manufacturer can do so. This is fundamentally incompatible with the aim of protecting users' freedom to change the software. The systematic pattern of such abuse occurs in the area of products for individuals to use, which is precisely where it is most unacceptable. Therefore, we have designed this version of the GPL to prohibit the practice for those products. If such problems arise substantially in other domains, we stand ready to extend this provision to those domains in future versions of the GPL, as needed to protect the freedom of users. Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free. The precise terms and conditions for copying, distribution and modification follow. TERMS AND CONDITIONS 0. Definitions. "This License" refers to version 3 of the GNU General Public License. "Copyright" also means copyright-like laws that apply to other kinds of works, such as semiconductor masks. "The Program" refers to any copyrightable work licensed under this License. Each licensee is addressed as "you". "Licensees" and "recipients" may be individuals or organizations. To "modify" a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a "modified version" of the earlier work or a work "based on" the earlier work. A "covered work" means either the unmodified Program or a work based on the Program. To "propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well. To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying. An interactive user interface displays "Appropriate Legal Notices" to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion. 1. Source Code. The "source code" for a work means the preferred form of the work for making modifications to it. "Object code" means any non-source form of a work. A "Standard Interface" means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language. The "System Libraries" of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A "Major Component", in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it. The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work. The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source. The Corresponding Source for a work in source code form is that same work. 2. Basic Permissions. All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law. You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you. Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary. 3. Protecting Users' Legal Rights From Anti-Circumvention Law. No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures. When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures. 4. Conveying Verbatim Copies. You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program. You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee. 5. Conveying Modified Source Versions. You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions: a) The work must carry prominent notices stating that you modified it, and giving a relevant date. b) The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to "keep intact all notices". c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it. d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so. A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate. 6. Conveying Non-Source Forms. You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways: a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange. b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge. c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b. d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements. e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d. A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work. A "User Product" is either (1) a "consumer product", which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. In determining whether a product is a consumer product, doubtful cases shall be resolved in favor of coverage. For a particular product received by a particular user, "normally used" refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product. A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product. "Installation Information" for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made. If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM). The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network. Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying. 7. Additional Terms. "Additional permissions" are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions. When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission. Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms: a) Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or d) Limiting the use for publicity purposes of names of licensors or authors of the material; or e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or f) Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors. All other non-permissive additional terms are considered "further restrictions" within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying. If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms. Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way. 8. Termination. You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11). However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation. Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice. Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10. 9. Acceptance Not Required for Having Copies. You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so. 10. Automatic Licensing of Downstream Recipients. Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License. An "entity transaction" is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party's predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts. You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it. 11. Patents. A "contributor" is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor's "contributor version". A contributor's "essential patent claims" are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, "control" includes the right to grant patent sublicenses in a manner consistent with the requirements of this License. Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version. In the following three paragraphs, a "patent license" is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement). To "grant" such a patent license to a party means to make such an agreement or commitment not to enforce a patent against the party. If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. "Knowingly relying" means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient's use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid. If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it. A patent license is "discriminatory" if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007. Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law. 12. No Surrender of Others' Freedom. If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program. 13. Use with the GNU Affero General Public License. Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such. 14. Revised Versions of this License. The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License "or any later version" applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation. If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Program. Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version. 15. Disclaimer of Warranty. THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. Limitation of Liability. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 17. Interpretation of Sections 15 and 16. If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Programs If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see . Also add information on how to contact you by electronic and paper mail. If the program does terminal interaction, make it output a short notice like this when it starts in an interactive mode: Copyright (C) This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, your program's commands might be different; for a GUI interface, you would use an "about box". You should also get your employer (if you work as a programmer) or school, if any, to sign a "copyright disclaimer" for the program, if necessary. For more information on this, and how to apply and follow the GNU GPL, see . The GNU General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. But first, please read . -------------- next part -------------- A non-text attachment was scrubbed... Name: tracetrap.py Type: text/x-python Size: 4196 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From denis at poolshark.org Sun Sep 14 15:52:56 2008 From: denis at poolshark.org (Denis Leroy) Date: Sun, 14 Sep 2008 17:52:56 +0200 Subject: Proposal: Better force-tag In-Reply-To: <1221402590.27183.172.camel@ignacio.lan> References: <1220955240.24928.69.camel@cookie.hadess.net> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> <48CA16D1.5070409@redhat.com> <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> <1221234383.15726.194.camel@localhost.localdomain> <48CD1CA3.5060302@redhat.com> <1221402590.27183.172.camel@ignacio.lan> Message-ID: <48CD3358.8060105@poolshark.org> Ignacio Vazquez-Abrams wrote: > Ultimately nothing can stop the user from using cvs tag -F, so any > solution (including this one, which I like a lot) would have to be > server-side. That's what they're planning to do, despite many objections. When will the FeSCo minutes be available on the wiki ? I would like to know who voted for this. From sgrubb at redhat.com Sun Sep 14 16:16:39 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Sun, 14 Sep 2008 12:16:39 -0400 Subject: Proposal: Better force-tag In-Reply-To: <48CD1CA3.5060302@redhat.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <48CD1CA3.5060302@redhat.com> Message-ID: <200809141216.39628.sgrubb@redhat.com> On Sunday 14 September 2008 10:16:03 Warren Togami wrote: > > Just removing stuff does not solve problems you have to implement a > > better alternative first (and not rely on a worse one). > > Since nothing stops the user from using TAG_OPTS=-F, it is ineffective > of us to remove force-tag. ?How about an improved force-tag instead? > > Make force-tag use koji to check if a build for that N-V-R is already > complete. ?If it is complete, then refuse to tag again with the same N-V-R. Yes, this sounds exactly like what should have been done. We should not have disabled a feature that many people legitimately use until we had a tested solution that does not interrupt the work flow. This is needless arguing with no tangible benefits for anyone. I consider the srpm to be the canonical source of the build. That is the only granularity people can access via any mirror. -Steve From sgrubb at redhat.com Sun Sep 14 16:21:17 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Sun, 14 Sep 2008 12:21:17 -0400 Subject: make force-tag gone In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> Message-ID: <200809141221.17527.sgrubb@redhat.com> On Sunday 14 September 2008 10:41:37 Kevin Kofler wrote: > > > You have to bump and rebuild the Rawhide package now too. > > > > Actually, I just did that for you in this case. Why would you do this to my package? Its not like this has to be fixed this morning. > > But normally, this is the maintainer's job, and doing the F-9 bumps the > > right way, it isn't necessary. > > Well, the build failed, so it looks like the fixes actually need to go into > the Rawhide package too. This is libgcrypt. There are probably a lot of things failing. I am working this with upstream to see if we can get a fix. > Right now you have not only an upgrade path bug, but also an FTBFS bug. > Please fix libprelude ASAP. If we didn't go taking away something people use, this wouldn't have happened. There is no reason why developers can't have force-tag and rel-eng have some audit trail. -Steve From bpepple at fedoraproject.org Sun Sep 14 16:23:09 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Sun, 14 Sep 2008 12:23:09 -0400 Subject: Proposal: Better force-tag In-Reply-To: <48CD3358.8060105@poolshark.org> References: <1220955240.24928.69.camel@cookie.hadess.net> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> <48CA16D1.5070409@redhat.com> <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> <1221234383.15726.194.camel@localhost.localdomain> <48CD1CA3.5060302@redhat.com> <1221402590.27183.172.camel@ignacio.lan> <48CD3358.8060105@poolshark.org> Message-ID: <1221409389.24484.1.camel@truman> On Sun, 2008-09-14 at 17:52 +0200, Denis Leroy wrote: > Ignacio Vazquez-Abrams wrote: > > Ultimately nothing can stop the user from using cvs tag -F, so any > > solution (including this one, which I like a lot) would have to be > > server-side. > > That's what they're planning to do, despite many objections. When will > the FeSCo minutes be available on the wiki ? I would like to know who > voted for this. I'm planning to write up the summary later today, but the IRC logs are available as soon as the meeting ends. http://bpepple.fedorapeople.org/fesco/ Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sgrubb at redhat.com Sun Sep 14 16:23:57 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Sun, 14 Sep 2008 12:23:57 -0400 Subject: make force-tag gone In-Reply-To: <20080914142955.GU2939@inocybe.teonanacatl.org> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809141010.32753.sgrubb@redhat.com> <20080914142955.GU2939@inocybe.teonanacatl.org> Message-ID: <200809141223.58108.sgrubb@redhat.com> On Sunday 14 September 2008 10:29:55 Todd Zullinger wrote: > So you could have just bumped the F-9 branch to 0.9.20.2-1.fc9.1, .2, > etc. ?Then it would still have an n-v-r less than the devel branch > does at 0.9.20.2-1.fc10. That is a horrible, UGLY kludge. I'm amazed that is our policy. It would have been far more helpful if someone who took away make force-tag would have made it echo a message to my screen saying that you need to do that. Seriously, why wasn't there any transition guidance? -Steve From tmz at pobox.com Sun Sep 14 16:34:45 2008 From: tmz at pobox.com (Todd Zullinger) Date: Sun, 14 Sep 2008 12:34:45 -0400 Subject: make force-tag gone In-Reply-To: <200809141223.58108.sgrubb@redhat.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809141010.32753.sgrubb@redhat.com> <20080914142955.GU2939@inocybe.teonanacatl.org> <200809141223.58108.sgrubb@redhat.com> Message-ID: <20080914163445.GY2939@inocybe.teonanacatl.org> Steve Grubb wrote: > That is a horrible, UGLY kludge. I'm amazed that is our policy. It > would have been far more helpful if someone who took away make > force-tag would have made it echo a message to my screen saying that > you need to do that. I'm not arguing in favor of force-tag removal. However, bumping the release number like this is pretty much required if you have to rebuild a package in an older branch, which can happen for various reasons. I don't see what's ugly or kludgy about ensuring that the n-v-r remains less than what is in the devel branch. -- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Common sense is genius dressed in its working clothes. -- Ralph Waldo Emerson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 542 bytes Desc: not available URL: From wtogami at redhat.com Sun Sep 14 16:37:59 2008 From: wtogami at redhat.com (Warren Togami) Date: Sun, 14 Sep 2008 12:37:59 -0400 Subject: Proposal: Better force-tag In-Reply-To: <200809141216.39628.sgrubb@redhat.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <48CD1CA3.5060302@redhat.com> <200809141216.39628.sgrubb@redhat.com> Message-ID: <48CD3DE7.6040204@redhat.com> Steve Grubb wrote: > On Sunday 14 September 2008 10:16:03 Warren Togami wrote: >>> Just removing stuff does not solve problems you have to implement a >>> better alternative first (and not rely on a worse one). >> Since nothing stops the user from using TAG_OPTS=-F, it is ineffective >> of us to remove force-tag. How about an improved force-tag instead? >> >> Make force-tag use koji to check if a build for that N-V-R is already >> complete. If it is complete, then refuse to tag again with the same N-V-R. > > Yes, this sounds exactly like what should have been done. We should not have > disabled a feature that many people legitimately use until we had a tested > solution that does not interrupt the work flow. This is needless arguing with > no tangible benefits for anyone. I consider the srpm to be the canonical > source of the build. That is the only granularity people can access via any > mirror. > > -Steve > The goal of preventing force-tag is to better guarantee that .src.rpm comtents match tags. We can achieve this by having force-tag fail if the buildsystem says that E:N-V-R was either already built or is currently building. Could FESCO please consider this during the next meeting? Warren Togami wtogami at redhat.com From moe at blagblagblag.org Sun Sep 14 17:06:32 2008 From: moe at blagblagblag.org (Jeff Moe) Date: Sun, 14 Sep 2008 17:06:32 +0000 (UTC) Subject: Fedora not "free" enough for GNU? References: <48C4317B.9050203@redhat.com> <200809071636.55955.konrad@tylerc.org> <7f692fec0809071749w48ce465co728e0e754123a9e0@mail.gmail.com> Message-ID: /me delurks to make small correction, re: BLAG.... > Having looked through a number of the blag packages, a good majority > of the changes is rebranding components like anaconda. Correct, and building various other packages for the repo and plundering livna, freshrpms, etc for more packages to include by default on the CD and repo, and changing a few default settings to make things more lightweight. > There are a number of changes though that definitely make it qualify > as a derivative, such as choosing jack over pulseaudio. I agree it's more of a derivative (branch?) than a spin. But we don't use jack by default in BLAG, it uses pulseaudio. In FREEEEE ( http://freeeee.org), a distro/spin/derivative based on BLAG for Asus EeePC computers, jack is used by default (and rocks). That's probably what you were thinking of. -Jeff From sgrubb at redhat.com Sun Sep 14 17:35:24 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Sun, 14 Sep 2008 13:35:24 -0400 Subject: Proposal: Better force-tag In-Reply-To: <48CD3DE7.6040204@redhat.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809141216.39628.sgrubb@redhat.com> <48CD3DE7.6040204@redhat.com> Message-ID: <200809141335.24831.sgrubb@redhat.com> On Sunday 14 September 2008 12:37:59 Warren Togami wrote: > The goal of preventing force-tag is to better guarantee that .src.rpm > comtents match tags. Is this really a problem in practice? I honestly do not care what is or has been in cvs between actual releases. The srpm has all the files that are part of a build. I never use cvs to research a problem. > We can achieve this by having force-tag fail if the buildsystem says that > E:N-V-R was either already built or is currently building. Or by embedding a sources file in the srpm that cross references all cvs versions of all files used in the build attempt. Doing it this way wouldn't have required disrupting the workflow. -Steve From wtogami at redhat.com Sun Sep 14 18:21:21 2008 From: wtogami at redhat.com (Warren Togami) Date: Sun, 14 Sep 2008 14:21:21 -0400 Subject: Proposal: Better force-tag In-Reply-To: <200809141335.24831.sgrubb@redhat.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809141216.39628.sgrubb@redhat.com> <48CD3DE7.6040204@redhat.com> <200809141335.24831.sgrubb@redhat.com> Message-ID: <48CD5621.3000501@redhat.com> Steve Grubb wrote: > On Sunday 14 September 2008 12:37:59 Warren Togami wrote: >> The goal of preventing force-tag is to better guarantee that .src.rpm >> comtents match tags. > > Is this really a problem in practice? I honestly do not care what is or has > been in cvs between actual releases. The srpm has all the files that are part > of a build. I never use cvs to research a problem. It is useful and important to keep the CVS matching .src.rpm's. One of many checks after the intrusion that we did was comparing the CVS tags to .src.rpm contents. > > >> We can achieve this by having force-tag fail if the buildsystem says that >> E:N-V-R was either already built or is currently building. > > Or by embedding a sources file in the srpm that cross references all cvs > versions of all files used in the build attempt. Doing it this way wouldn't > have required disrupting the workflow. The "Better force-tag" proposal doesn't disrupt your workflow either, unless you are doing something clearly wrong. Warren Togami wtogami at redhat.com From wtogami at redhat.com Sun Sep 14 18:27:27 2008 From: wtogami at redhat.com (Warren Togami) Date: Sun, 14 Sep 2008 14:27:27 -0400 Subject: Proposal: Better force-tag In-Reply-To: <48CD5621.3000501@redhat.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809141216.39628.sgrubb@redhat.com> <48CD3DE7.6040204@redhat.com> <200809141335.24831.sgrubb@redhat.com> <48CD5621.3000501@redhat.com> Message-ID: <48CD578F.8050301@redhat.com> Warren Togami wrote: > Steve Grubb wrote: >> On Sunday 14 September 2008 12:37:59 Warren Togami wrote: >>> The goal of preventing force-tag is to better guarantee that .src.rpm >>> comtents match tags. >> >> Is this really a problem in practice? I honestly do not care what is >> or has been in cvs between actual releases. The srpm has all the files >> that are part of a build. I never use cvs to research a problem. > > It is useful and important to keep the CVS matching .src.rpm's. One of > many checks after the intrusion that we did was comparing the CVS tags > to .src.rpm contents. 4 packages out of a sample of 3396 were not matching between .src.rpm contents and the matching CVS tag. Manual inspection however found the differences to be inconsequential and the result of incorrect use of force-tag. The "Better force-tag" proposal would have prevented these four problems from occurring without restricting legitimate uses of force-tag. Warren Togami wtogami at redhat.com From fedora at camperquake.de Sun Sep 14 18:53:38 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 14 Sep 2008 20:53:38 +0200 Subject: Proposal: Better force-tag In-Reply-To: <48CD578F.8050301@redhat.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809141216.39628.sgrubb@redhat.com> <48CD3DE7.6040204@redhat.com> <200809141335.24831.sgrubb@redhat.com> <48CD5621.3000501@redhat.com> <48CD578F.8050301@redhat.com> Message-ID: <20080914205338.638baec4@lain.camperquake.de> Hi. On Sun, 14 Sep 2008 14:27:27 -0400, Warren Togami wrote > 4 packages out of a sample of 3396 were not matching between .src.rpm > contents and the matching CVS tag. Manual inspection however found > the differences to be inconsequential and the result of incorrect use > of force-tag. That means that force-tag was used on the CVS tree after the previous tag had already been built in koji? From warren at togami.com Sun Sep 14 18:55:32 2008 From: warren at togami.com (Warren Togami) Date: Sun, 14 Sep 2008 14:55:32 -0400 Subject: Proposal: Better force-tag In-Reply-To: <20080914205338.638baec4@lain.camperquake.de> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809141216.39628.sgrubb@redhat.com> <48CD3DE7.6040204@redhat.com> <200809141335.24831.sgrubb@redhat.com> <48CD5621.3000501@redhat.com> <48CD578F.8050301@redhat.com> <20080914205338.638baec4@lain.camperquake.de> Message-ID: <48CD5E24.5060505@togami.com> Ralf Ertzinger wrote: > Hi. > > On Sun, 14 Sep 2008 14:27:27 -0400, Warren Togami wrote > >> 4 packages out of a sample of 3396 were not matching between .src.rpm >> contents and the matching CVS tag. Manual inspection however found >> the differences to be inconsequential and the result of incorrect use >> of force-tag. > > That means that force-tag was used on the CVS tree after the previous tag > had already been built in koji? > Yes, and offenders have been beaten. Warren From smooge at gmail.com Sun Sep 14 19:26:26 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 14 Sep 2008 13:26:26 -0600 Subject: configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!) In-Reply-To: <1221310726.3076.46.camel@rosebud> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <1221285235.3492.4.camel@fantail.jnet.net.nz> <1221301012.3152.7.camel@pc-notebook> <48CBABC4.5060005@leemhuis.info> <20080913120636.GA20878@jadzia.bu.edu> <1221310726.3076.46.camel@rosebud> Message-ID: <80d7e4090809141226g7fa6fcfdy4d670dcaf9289584@mail.gmail.com> On Sat, Sep 13, 2008 at 6:58 AM, Seth Vidal wrote: > On Sat, 2008-09-13 at 08:06 -0400, Matthew Miller wrote: >> On Sat, Sep 13, 2008 at 02:02:12PM +0200, Thorsten Leemhuis wrote: >> > But a checkbox with a text "User is the sysadmin for this system" might >> > makes sense in firstboot -- that checkbox could not only configure sudo >> > and/or PolicyKit access but also do other things like setting up a alias to >> > /etc/aliases to make sure the user in question retrieves the mail send to >> > root. >> >> If we do this (and I'm for it), we should make this work by uncommenting the >> wheel group in /etc/sudoers, and having said checkbox add the user to the >> wheel group. > > I don't like the wheel group way into sudoers. Not the least of which > because the wheel group, on systems which are using some other form of > nss than local files, can be mucked with too easily. > Any solution is going to be fragile in the case of a network'd computer. Unix permission scheme was never designed with that in mind. So what is the 80% use solution? Of the fedora users, are 80% covered by local files or using nss_XXX? I am not for wheel or against it.. I just figure we should look at what is the majority use scheme and work around it for the rest. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From skvidal at fedoraproject.org Sun Sep 14 21:09:57 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Sun, 14 Sep 2008 17:09:57 -0400 Subject: configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!) In-Reply-To: <80d7e4090809141226g7fa6fcfdy4d670dcaf9289584@mail.gmail.com> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <1221285235.3492.4.camel@fantail.jnet.net.nz> <1221301012.3152.7.camel@pc-notebook> <48CBABC4.5060005@leemhuis.info> <20080913120636.GA20878@jadzia.bu.edu> <1221310726.3076.46.camel@rosebud> <80d7e4090809141226g7fa6fcfdy4d670dcaf9289584@mail.gmail.com> Message-ID: <1221426597.25056.6.camel@rosebud> On Sun, 2008-09-14 at 13:26 -0600, Stephen John Smoogen wrote: > On Sat, Sep 13, 2008 at 6:58 AM, Seth Vidal wrote: > > On Sat, 2008-09-13 at 08:06 -0400, Matthew Miller wrote: > >> On Sat, Sep 13, 2008 at 02:02:12PM +0200, Thorsten Leemhuis wrote: > >> > But a checkbox with a text "User is the sysadmin for this system" might > >> > makes sense in firstboot -- that checkbox could not only configure sudo > >> > and/or PolicyKit access but also do other things like setting up a alias to > >> > /etc/aliases to make sure the user in question retrieves the mail send to > >> > root. > >> > >> If we do this (and I'm for it), we should make this work by uncommenting the > >> wheel group in /etc/sudoers, and having said checkbox add the user to the > >> wheel group. > > > > I don't like the wheel group way into sudoers. Not the least of which > > because the wheel group, on systems which are using some other form of > > nss than local files, can be mucked with too easily. > > > > Any solution is going to be fragile in the case of a network'd > computer. Unix permission scheme was never designed with that in mind. > So > what is the 80% use solution? Of the fedora users, are 80% covered by > local files or using nss_XXX? I am not for wheel or against it.. I > just figure we should look at what is the majority use scheme and work > around it for the rest. > 80% is the entry gets added to /etc/sudoers by the user addition interface if 'make this user an admin' is checked. I think the entry would look like: username ALL=(ALL) ALL -sv From moe at blagblagblag.org Sun Sep 14 21:12:41 2008 From: moe at blagblagblag.org (Jeff Moe) Date: Sun, 14 Sep 2008 21:12:41 +0000 (UTC) Subject: Fedora not "free" enough for GNU? References: <8553.1220772699@sss.pgh.pa.us> <48C4317B.9050203@redhat.com> <20080908041233.GB28412@wolff.to> <20080908124949.GC28688@file.rdu.redhat.com> Message-ID: Alan Cox redhat.com> writes: > On Sun, Sep 07, 2008 at 11:12:33PM -0500, Bruno Wolff III wrote: > > > about free software is the fact that it's reasonably easy to inspect > > > it for security analysis; binary blobs weaken that. > > > > There is a reason the U.S. government is concerned about computers being > > made in China. > > There have also been allegations and some evidence of the reverse. > > And nobody is to sure about Skype either.. Hmm, they should be sure. It seems reasonably clear the USA Federal Government has been able to intercept Skype since at least 2005. Presumably other governments can buy this service as well. "FOIA Litigation: Electronic Surveillance Systems, Documents Released By the Department of Justice on July 2, 2007" http://www.eff.org/files/filenode/061708CKK/070207_dcs02.pdf See sections about VoIP to get a general idea; "Skype In/Out" is mentioned on page 115. -Jeff P.S. As a side note, they have been using Microsoft for the spying since 1997. They ditched Linux early (see "Lessons Learned"): "End users are not familiar with the LINUX operating system"... From debarshi.ray at gmail.com Sun Sep 14 22:00:01 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Mon, 15 Sep 2008 03:30:01 +0530 Subject: make force-tag gone In-Reply-To: <200809141010.32753.sgrubb@redhat.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <1220978806.11620.6.camel@luminos.localdomain> <200809140919.50743.sgrubb@redhat.com> <200809141010.32753.sgrubb@redhat.com> Message-ID: <3170f42f0809141500u384a4678r42130f68707c2715@mail.gmail.com> > OK, it took 3 builds to get libprelude squared away. Now because force-tag is > no longer available, we have libprelude-0.9.20.2-1 in rawhide and > libprelude-0.9.20.2-3 aimed at F-9 inclusion. This is why I always build F-n, then F-(n+1) and finally devel. :-) Cheerio, Debarshi From dev at nigelj.com Sun Sep 14 22:33:35 2008 From: dev at nigelj.com (Nigel Jones) Date: Mon, 15 Sep 2008 10:33:35 +1200 Subject: configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!) In-Reply-To: <1221426597.25056.6.camel@rosebud> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <1221285235.3492.4.camel@fantail.jnet.net.nz> <1221301012.3152.7.camel@pc-notebook> <48CBABC4.5060005@leemhuis.info> <20080913120636.GA20878@jadzia.bu.edu> <1221310726.3076.46.camel@rosebud> <80d7e4090809141226g7fa6fcfdy4d670dcaf9289584@mail.gmail.com> <1221426597.25056.6.camel@rosebud> Message-ID: <1221431615.29149.1.camel@fantail.jnet.net.nz> On Sun, 2008-09-14 at 17:09 -0400, Seth Vidal wrote: > On Sun, 2008-09-14 at 13:26 -0600, Stephen John Smoogen wrote: > > On Sat, Sep 13, 2008 at 6:58 AM, Seth Vidal wrote: > > > On Sat, 2008-09-13 at 08:06 -0400, Matthew Miller wrote: > > >> On Sat, Sep 13, 2008 at 02:02:12PM +0200, Thorsten Leemhuis wrote: > > >> > But a checkbox with a text "User is the sysadmin for this system" might > > >> > makes sense in firstboot -- that checkbox could not only configure sudo > > >> > and/or PolicyKit access but also do other things like setting up a alias to > > >> > /etc/aliases to make sure the user in question retrieves the mail send to > > >> > root. > > >> > > >> If we do this (and I'm for it), we should make this work by uncommenting the > > >> wheel group in /etc/sudoers, and having said checkbox add the user to the > > >> wheel group. > > > > > > I don't like the wheel group way into sudoers. Not the least of which > > > because the wheel group, on systems which are using some other form of > > > nss than local files, can be mucked with too easily. > > > > > > > Any solution is going to be fragile in the case of a network'd > > computer. Unix permission scheme was never designed with that in mind. > > So > > what is the 80% use solution? Of the fedora users, are 80% covered by > > local files or using nss_XXX? I am not for wheel or against it.. I > > just figure we should look at what is the majority use scheme and work > > around it for the rest. > > > > 80% is the entry gets added to /etc/sudoers by the user addition > interface if 'make this user an admin' is checked. > > I think the entry would look like: > > username ALL=(ALL) I agree, I've filed an RFE as bug #462161 (https://bugzilla.redhat.com/show_bug.cgi?id=462161), forgot to mention it previously. - Nigel > > -sv > > > -- Nigel Jones From kanarip at kanarip.com Sun Sep 14 23:08:48 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 15 Sep 2008 01:08:48 +0200 Subject: configuring sudo by default In-Reply-To: <1221310726.3076.46.camel@rosebud> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <1221285235.3492.4.camel@fantail.jnet.net.nz> <1221301012.3152.7.camel@pc-notebook> <48CBABC4.5060005@leemhuis.info> <20080913120636.GA20878@jadzia.bu.edu> <1221310726.3076.46.camel@rosebud> Message-ID: <48CD9980.1050609@kanarip.com> Seth Vidal wrote: > On Sat, 2008-09-13 at 08:06 -0400, Matthew Miller wrote: >> On Sat, Sep 13, 2008 at 02:02:12PM +0200, Thorsten Leemhuis wrote: >>> But a checkbox with a text "User is the sysadmin for this system" might >>> makes sense in firstboot -- that checkbox could not only configure sudo >>> and/or PolicyKit access but also do other things like setting up a alias to >>> /etc/aliases to make sure the user in question retrieves the mail send to >>> root. >> If we do this (and I'm for it), we should make this work by uncommenting the >> wheel group in /etc/sudoers, and having said checkbox add the user to the >> wheel group. > > I don't like the wheel group way into sudoers. Not the least of which > because the wheel group, on systems which are using some other form of > nss than local files, can be mucked with too easily. > I'm not sure I see how this can be mucked with... If anything other then local files is used by nss the group membership of local files is supposed to be overriden, not extended, and the group's members from the other form of nss should be used, isn't it? This is at least the case for nss_ldap with nsswitch set to 'files ldap' (a case I had the chance to verify just now). Kind regards, Jeroen van Meeuwen -kanarip From mattdm at mattdm.org Sun Sep 14 23:26:39 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 14 Sep 2008 19:26:39 -0400 Subject: SWAMP -- is it good for anything? In-Reply-To: References: Message-ID: <20080914232639.GA13166@jadzia.bu.edu> On Sat, Sep 13, 2008 at 08:58:04PM +0200, Matej Cepl wrote: > Somebody from SUSE mentioned open-sourced swap -- their tool for > workflow management (http://swamp.sf.net). Would it help to > anything in Fedora? It looks like it at least could be a useful package to have in the repo. -- Matthew Miller mattdm at mattdm.org From bnocera at redhat.com Sun Sep 14 23:51:21 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 15 Sep 2008 00:51:21 +0100 Subject: graphics w/ 2.6.26.3-29 kernel sluggish, 2.6.25.14-108 OK? In-Reply-To: References: Message-ID: <1221436281.24928.295.camel@cookie.hadess.net> On Sun, 2008-09-14 at 17:47 +0300, Pekka Savola wrote: > On Sat, 13 Sep 2008, Pekka Savola wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=462180 > > This appears to affect non-graphics as well, see the bug for more. > > I noticed interesting thing on both 2.6.26 and 2.6.25 though. If I > boot using "nosmp" option, bootup freezes at "Starting udev". > "acpi=off nosmp" works though, as works the default option. This is a > a single CPU system. > > Seems pretty strange. I wonder if this intentional? There doesn't > seem to be any bug filed on this, the closest (inverse to this) was: > https://bugzilla.redhat.com/show_bug.cgi?id=405361 The problem I'm currently seeing with the latest rawhide is that X will only refresh the screen when there is keyboard or mouse activity. Leaving "Ctrl" pressed allows for the UI to update. Not sure if this is the same issue you're seeing... From gdt at gdt.id.au Sun Sep 14 23:59:25 2008 From: gdt at gdt.id.au (Glen Turner) Date: Mon, 15 Sep 2008 09:29:25 +0930 Subject: Fedora not "free" enough for GNU? In-Reply-To: References: <8553.1220772699@sss.pgh.pa.us> <48C4317B.9050203@redhat.com> <20080908041233.GB28412@wolff.to> <20080908124949.GC28688@file.rdu.redhat.com> Message-ID: <48CDA55D.8010104@gdt.id.au> Jeff Moe wrote: > Hmm, they should be sure. It seems reasonably clear the USA Federal Government > has been able to intercept Skype since at least 2005. Presumably other > governments can buy this service as well. If the service was widely available then why did the Bavarian police bother with malware-style solutions to Skype interception in 2007? Given the attractiveness of Skype interception to non-US intelligence agencies, I can't imagine the US government would be too happy with Skype offering interception services to most non-US governments. Best wishes, Glen -- Glen Turner From email.ahmedkamal at googlemail.com Mon Sep 15 00:20:37 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Mon, 15 Sep 2008 02:20:37 +0200 Subject: The state of resolv.conf Message-ID: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> I have an itch. I connect to work using openvpn. Works great, except that openvpn does not modify resolv.conf to add work's dns servers (now available through vpn). It does that on Windows though! I cannot expect openvpn or (any other application) to simply overwrite /etc/resolv.conf at will, but what is fedora missing to get an elegant solution to this problem ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at xelerance.com Mon Sep 15 01:37:46 2008 From: paul at xelerance.com (Paul Wouters) Date: Sun, 14 Sep 2008 21:37:46 -0400 (EDT) Subject: The state of resolv.conf In-Reply-To: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> Message-ID: On Mon, 15 Sep 2008, Ahmed Kamal wrote: > I have an itch. I connect to work using openvpn. Works great, except that openvpn does not modify resolv.conf to add > work's dns servers (now available through vpn). It does that on Windows though! I cannot expect openvpn or (any other > application) to simply overwrite /etc/resolv.conf at will, but what is fedora missing to get an elegant solution to > this problem ? If you use openvpn through NetworkManager, then I'd say NetworkManager should handle this for you. Paul From paul at xelerance.com Mon Sep 15 02:15:30 2008 From: paul at xelerance.com (Paul Wouters) Date: Sun, 14 Sep 2008 22:15:30 -0400 (EDT) Subject: Missing packages in SRPMS.newkey ? Message-ID: Hi, I am seeing a lot more packages in x86_64.newkey then I'm seeing packages in SRPMS.newkey. Is this a known problem? In my case, I was looking for some perl source rpms, but they're not there: No source RPM found for 1:perl-Module-Build-0.2808-20.fc9.x86_64 No source RPM found for 1:perl-Module-Build-0.2808-33.fc9.x86_64 No source RPM found for perl-Module-CoreList-2.14-20.fc9.x86_64 No source RPM found for perl-Module-CoreList-2.14-33.fc9.x86_64 No source RPM found for 1:perl-Module-Pluggable-3.60-33.fc9.x86_64 No source RPM found for 1:perl-Module-Pluggable-3.60-20.fc9.x86_64 Since the binary rpms contained newer versions, I tried those as well, but I also got errors on those: $ yumdownloader --source perl-Module-Build-0.2808-33.fc9 perl-Module-CoreList-2.14-33.fc9 Loaded plugins: refresh-packagekit Enabling updates-source repository Enabling livna-source repository Enabling fedora-source repository Enabling updates-newkey-source repository No source RPM found for 1:perl-Module-Build-0.2808-33.fc9.x86_64 No source RPM found for perl-Module-CoreList-2.14-33.fc9.x86_64 Nothing to download Paul From jonstanley at gmail.com Mon Sep 15 02:47:29 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Sun, 14 Sep 2008 22:47:29 -0400 Subject: Missing packages in SRPMS.newkey ? In-Reply-To: References: Message-ID: On Sun, Sep 14, 2008 at 10:15 PM, Paul Wouters wrote: > I am seeing a lot more packages in x86_64.newkey then I'm seeing packages > in SRPMS.newkey. Is this a known problem? Nope, the particular modules that you are trying to download are built as part of the base perl SRPM: [jstanley at rugrat x86_64.newkey]$ rpm -qip perl-Module-Pluggable-3.60-33.fc9.x86_64.rpm warning: perl-Module-Pluggable-3.60-33.fc9.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 6df2196f Name : perl-Module-Pluggable Relocations: (not relocatable) Version : 3.60 Vendor: Fedora Project Release : 33.fc9 Build Date: Thu 07 Aug 2008 05:14:10 AM EDT Install Date: (not installed) Build Host: x86-3 Group : Development/Libraries Source RPM: perl-5.10.0-33.fc9.src.rpm Size : 28908 License: GPL+ or Artistic Signature : DSA/SHA1, Wed 10 Sep 2008 03:31:11 PM EDT, Key ID 62aec3dc6df2196f Packager : Fedora Project URL : http://www.perl.org/ Summary : Automatically give your module the ability to have plugins Description : Provides a simple but, hopefully, extensible way of having 'plugins' for your module. [jstanley at rugrat x86_64.newkey]$ Note the 'Source RPM' field there. Many binary packages are built as subpackages of the same source package, this is not unusual. From orion at cora.nwra.com Mon Sep 15 02:55:37 2008 From: orion at cora.nwra.com (orion at cora.nwra.com) Date: Sun, 14 Sep 2008 20:55:37 -0600 (MDT) Subject: graphics w/ 2.6.26.3-29 kernel sluggish, 2.6.25.14-108 OK? In-Reply-To: <1221436281.24928.295.camel@cookie.hadess.net> References: <1221436281.24928.295.camel@cookie.hadess.net> Message-ID: <2216.71.208.40.13.1221447337.squirrel@www.cora.nwra.com> > On Sun, 2008-09-14 at 17:47 +0300, Pekka Savola wrote: >> On Sat, 13 Sep 2008, Pekka Savola wrote: >> > https://bugzilla.redhat.com/show_bug.cgi?id=462180 >> >> This appears to affect non-graphics as well, see the bug for more. >> >> I noticed interesting thing on both 2.6.26 and 2.6.25 though. If I >> boot using "nosmp" option, bootup freezes at "Starting udev". >> "acpi=off nosmp" works though, as works the default option. This is a >> a single CPU system. >> >> Seems pretty strange. I wonder if this intentional? There doesn't >> seem to be any bug filed on this, the closest (inverse to this) was: >> https://bugzilla.redhat.com/show_bug.cgi?id=405361 > > The problem I'm currently seeing with the latest rawhide is that X will > only refresh the screen when there is keyboard or mouse activity. > Leaving "Ctrl" pressed allows for the UI to update. > > Not sure if this is the same issue you're seeing... > I'm seeing this too, though particularly with thunderbird. Is there bug filed yet? -Orion > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From paul at xelerance.com Mon Sep 15 02:47:50 2008 From: paul at xelerance.com (Paul Wouters) Date: Sun, 14 Sep 2008 22:47:50 -0400 (EDT) Subject: Missing packages in SRPMS.newkey ? In-Reply-To: References: Message-ID: On Sun, 14 Sep 2008, Jon Stanley wrote: >> I am seeing a lot more packages in x86_64.newkey then I'm seeing packages >> in SRPMS.newkey. Is this a known problem? > > Nope, the particular modules that you are trying to download are built > as part of the base perl SRPM: > Note the 'Source RPM' field there. Many binary packages are built as > subpackages of the same source package, this is not unusual. Shit. Looks like I'm bitten by centos perl 5.8 vs fedora perl 5.10. Thanks for the tip. At least now i understand the problem. Paul From vonbrand at inf.utfsm.cl Mon Sep 15 03:23:49 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 14 Sep 2008 23:23:49 -0400 Subject: NetworkworkManger and network based filesystem /usr In-Reply-To: <48CAB296.80101@redhat.com> References: <48CAAF49.3090105@hhs.nl> <20080912181213.GA3270@nostromo.devel.redhat.com> <48CAB296.80101@redhat.com> Message-ID: <200809150323.m8F3NnVG015326@laptop14.inf.utfsm.cl> Jeff Law wrote: [...] > It must die die die. We're far better off making root filesystems > sharable and readonly. /etc at the very least is a /intensely/ personal issue for each machine... We had local / and shared /usr and so on for ages under assorted Unices here, and then for Linux. True, today disks are much cheaper; but old habits are long in dying. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From dcbw at redhat.com Mon Sep 15 03:36:45 2008 From: dcbw at redhat.com (Dan Williams) Date: Sun, 14 Sep 2008 23:36:45 -0400 Subject: NetworkworkManger and network based filesystem /usr In-Reply-To: <48CAD272.1010604@redhat.com> References: <48CAAF49.3090105@hhs.nl> <20080912181213.GA3270@nostromo.devel.redhat.com> <48CAB296.80101@redhat.com> <48CABCB1.6030203@redhat.com> <20080912190531.GB5649@nostromo.devel.redhat.com> <48CAD272.1010604@redhat.com> Message-ID: <1221449805.27102.3.camel@localhost.localdomain> On Fri, 2008-09-12 at 16:34 -0400, Peter Jones wrote: > Bill Nottingham wrote: > > Peter Jones (pjones at redhat.com) said: > >> I'm not necessarily against stopping supporting this, but it does mean > >> that upgrading won't work on some systems. And it means that "yum > >> upgrading" will fail /catastrophically/ on those machines. > > > > How so, if yum upgrades don't switch you from network -> NM? (yet) > > Yeah, if we're not doing that then it should be ok for this particular problem; > though in general we still need to be careful about this. Not doing this now, and no plans to do so at this time. But we do need to be careful with the initscripts and such. Dan From Matt_Domsch at dell.com Mon Sep 15 03:37:02 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 14 Sep 2008 22:37:02 -0500 Subject: non-responsive maintainer 'misa': mx and pyOpenSSL packages up for adoption Message-ID: <20080915033702.GA4887@auslistsprd01.us.dell.com> I would like to request a short-circuit of the Non-responsive Maintainer process, for Mihai Ibanescu, FAS account 'misa', formerly a Red Hat employee. misa owns two packages, mx and pyOpenSSL. mx has not been touched by misa since March 2005, and pyOpenSSL since November 2005; only the slightest maintenance has been performed on them since this time by rel-eng members to enable them to keep building. mx has a FTBFS bug against it (#434325), and is overdue for a major version update from 2.0.6 -> 3.1.1. Both packages are closed to commits from the 'packager' group. mx has a long list of packages which depend on it, noted below, so I don't want to see it removed from the distribution. I have a patch to fix the mx FTBFS bug which I will apply as soon as permissions in pkgdb allow, but would like to see these orphaned and put up for adoption by a loving packager. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux mx-2.0.6-3.x86_64 MySQL-python-1.2.2-7.fc10.x86_64 bibus-1.4.3-1.fc10.x86_64 gnue-common-0.6.9-4.fc10.noarch poker-server-1.6.0-1.fc10.noarch pyicq-t-mysql-0.8-6.b.fc10.noarch python-biopython-1.47-1.fc10.x86_64 python-sqlobject-0.10.2-1.fc10.noarch TurboGears-1.0.4.4-3.fc10.noarch bodhi-server-0.5.0-7.fc9.noarch ipa-server-1.1.0-4.fc9.x86_64 ipa-server-selinux-1.1.0-4.fc9.x86_64 ipa-server-1.1.0-4.fc9.x86_64 python-TurboMail-2.1-3.fc9.noarch bodhi-server-0.5.0-7.fc9.noarch python-tgcaptcha-0.11-3.fc10.noarch bodhi-server-0.5.0-7.fc9.noarch python-turboflot-0.1.1-1.fc10.noarch bodhi-server-0.5.0-7.fc9.noarch smolt-server-1.1.1.1-6.fc10.noarch smolt-server-1.1.1.1-6.fc10.noarch python-storm-mysql-0.13-2.fc10.x86_64 python-storm-0.13-2.fc10.x86_64 python-storm-mysql-0.13-2.fc10.x86_64 python-storm-postgresql-0.13-2.fc10.x86_64 python-storm-0.13-2.fc10.x86_64 python-storm-sqlite-0.13-2.fc10.x86_64 python-storm-0.13-2.fc10.x86_64 gnue-common-0.6.9-4.fc10.noarch postgresql-python-8.3.3-3.fc10.x86_64 koji-hub-1.2.6-1.fc10.noarch koji-utils-1.2.6-1.fc10.noarch koji-web-1.2.6-1.fc10.noarch python-sqlobject-0.10.2-1.fc10.noarch tinyerp-server-4.2.2-4.fc10.noarch python-biopython-1.47-1.fc10.x86_64 python-logilab-common-0.32.0-1.fc10.noarch python-logilab-astng-0.17.2-1.fc9.noarch pylint-0.14.0-1.fc9.noarch pylint-gui-0.14.0-1.fc9.noarch python-psycopg-1.1.21-8.fc10.x86_64 python-biopython-1.47-1.fc10.x86_64 tinyerp-server-4.2.2-4.fc10.noarch smolt-server-1.1.1.1-6.fc10.noarch straw-0.27-12.fc9.noarch tinyerp-4.2.2-4.fc10.noarch From dcbw at redhat.com Mon Sep 15 03:41:32 2008 From: dcbw at redhat.com (Dan Williams) Date: Sun, 14 Sep 2008 23:41:32 -0400 Subject: The state of resolv.conf In-Reply-To: References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> Message-ID: <1221450093.27102.7.camel@localhost.localdomain> On Sun, 2008-09-14 at 21:37 -0400, Paul Wouters wrote: > On Mon, 15 Sep 2008, Ahmed Kamal wrote: > > > I have an itch. I connect to work using openvpn. Works great, except that openvpn does not modify resolv.conf to add > > work's dns servers (now available through vpn). It does that on Windows though! I cannot expect openvpn or (any other > > application) to simply overwrite /etc/resolv.conf at will, but what is fedora missing to get an elegant solution to > > this problem ? > > If you use openvpn through NetworkManager, then I'd say NetworkManager should > handle this for you. Yeah, at the end of the day something needs to mediate between services that need to update your DNS information. If you're using NetworkManager, then NM does this mediation for you for things like PPP, PPtP, DHCP, openvpn, and vpnc. But if you're not using NM, each service (vpnc, dhcp, openvpn, pptp, ppp, whatever) has to have it's own logic to backup and restore resolv.conf. And that just sucks. Some distros have resolvconf to help with this, which does the same sort of thing as NM and "stacks" DNS configs. Most of these hacks are standard *NIX: everything has it's own system and nothing works very well. Dan From dcbw at redhat.com Mon Sep 15 03:44:04 2008 From: dcbw at redhat.com (Dan Williams) Date: Sun, 14 Sep 2008 23:44:04 -0400 Subject: change isdn4k-utils to optional In-Reply-To: <20080914161948.18e1eace@lain.camperquake.de> References: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> <1221381331.18327.532.camel@beck.corsepiu.local> <200809140207.08044.konrad@tylerc.org> <20080914161948.18e1eace@lain.camperquake.de> Message-ID: <1221450244.27102.9.camel@localhost.localdomain> On Sun, 2008-09-14 at 16:19 +0200, Ralf Ertzinger wrote: > Hi. > > On Sun, 14 Sep 2008 02:07:07 -0700, Conrad Meyer wrote > > > Right, the OP wasn't talking about removing the package from Fedora > > entirely, but disabling it as a default installed package. Users who > > need ISDN for non-internet purposes can always download the isdn > > packages from repositories, whereas those who need it to connect to > > the internet would be out of luck if it was disabled by default (for > > new installs, anyways). > > Thus, my suggestion to split the package into the bits needed for > internet access and those not. I'm for this; if/when NetworkManager grows ISDN support it'll make these bits a dep, and we wouldn't necessarily want to drag all of them back in. dan From jonstanley at gmail.com Mon Sep 15 03:55:31 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Sun, 14 Sep 2008 23:55:31 -0400 Subject: non-responsive maintainer 'misa': mx and pyOpenSSL packages up for adoption In-Reply-To: <20080915033702.GA4887@auslistsprd01.us.dell.com> References: <20080915033702.GA4887@auslistsprd01.us.dell.com> Message-ID: On Sun, Sep 14, 2008 at 11:37 PM, Matt Domsch wrote: > I would like to request a short-circuit of the Non-responsive > Maintainer process, for Mihai Ibanescu, FAS account 'misa', formerly a > Red Hat employee. Sort of +1. We need some sort of policy for former RH'ers, with the understanding that not all of them will abandon their Fedora responsibilities when leaving RH. David Woodhouse is an excellent example of this. However, where the circumstances make it clear that they have no intent to continue maintenance of their Fedora packages, such as here, I don't think that the entire process need be invoked. I also don't want this to devolve into a "Red Hat vs. community" thing, whereby we have different standards for folks that are or were employed by Red Hat vs. folks who aren't, so any policy that we come up with for fast-tracking the non-responsive process (which I think can be appropriate in circumstances such as this) needs to be broadly applicable, I'll open a FESCo trac ticket on this so we don't lose sight of it. Other thoughts? From Matt_Domsch at dell.com Mon Sep 15 04:06:46 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Sun, 14 Sep 2008 23:06:46 -0500 Subject: non-responsive maintainer 'misa': mx and pyOpenSSL packages up for adoption In-Reply-To: References: <20080915033702.GA4887@auslistsprd01.us.dell.com> Message-ID: <20080915040646.GB4887@auslistsprd01.us.dell.com> On Sun, Sep 14, 2008 at 11:55:31PM -0400, Jon Stanley wrote: > On Sun, Sep 14, 2008 at 11:37 PM, Matt Domsch wrote: > > I would like to request a short-circuit of the Non-responsive > > Maintainer process, for Mihai Ibanescu, FAS account 'misa', formerly a > > Red Hat employee. > > Sort of +1. We need some sort of policy for former RH'ers, with the > understanding that not all of them will abandon their Fedora > responsibilities when leaving RH. David Woodhouse is an excellent > example of this. > > However, where the circumstances make it clear that they have no > intent to continue maintenance of their Fedora packages, such as here, > I don't think that the entire process need be invoked. > > I also don't want this to devolve into a "Red Hat vs. community" > thing, whereby we have different standards for folks that are or were > employed by Red Hat vs. folks who aren't, so any policy that we come > up with for fast-tracking the non-responsive process (which I think > can be appropriate in circumstances such as this) needs to be broadly > applicable, I agree completely. Should the same happen to a Dell employee who happens to also maintain packages in Fedora, should they both leave Dell and stop actively maintaining their packages, I would expect others from Dell who are aware that person has left to step up and ack the NRM request. If Mihai had updated his FAS account with an active email address, I'd be happy to send mails there. As it stands, the address is a non-functional @redhat.com address, with no good way to reach him, and clearly no maintainence on his part in years. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From dcbw at redhat.com Mon Sep 15 04:28:58 2008 From: dcbw at redhat.com (Dan Williams) Date: Mon, 15 Sep 2008 00:28:58 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080911220148.GI6092@nb.net.home> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <544eb990809110414x44c1c563l7d0da7859c166780@mail.gmail.com> <16de708d0809110814l6eda770ey54db2073391e0511@mail.gmail.com> <544eb990809110940j26d828ady63bc91e3c50cca3d@mail.gmail.com> <1221151737.27183.74.camel@ignacio.lan> <20080911220148.GI6092@nb.net.home> Message-ID: <1221452938.27102.16.camel@localhost.localdomain> On Fri, 2008-09-12 at 00:01 +0200, Karel Zak wrote: > On Thu, Sep 11, 2008 at 12:48:57PM -0400, Ignacio Vazquez-Abrams wrote: > > On Thu, 2008-09-11 at 17:40 +0100, Bill Crawford wrote: > > > If you have multi-channel hardware that mixes itself, then using > > > PulseAudio sort of defeats the purpose of that hardware ;o) > > > > You're absolutely right... if all you're using PulseAudio for is basic > > mixing. But as soon as you need/want something like per-app volume > > control, network transport, audio stream redirection, or audio device > > hotplugging then you want PulseAudio. > > How many **ordinary** Fedora users really need these **advanced** > features? > > For example I have never had any serious SW problem with sound on > Linux. And I use it for more than 10 years... I have USB speakers at home. I do not have them at work. I used to have to change the alsa default device in system-config-soundcard and then quit all open apps just to get the sound to come out of the hotplugged USB speakers. Flash used to only play to the default alsa soundcard. That completely totally sucks. Mac OS X and Windows seamlessly redirect the output to the USB speakers when they are plugged in, and when I unplug them the sound switches back to onboard instantly. USB headphones and webcams with integrated microphones (FW iSight for example) are also used quite often. Those get hotplugged and thus they should just work. I could never, ever, ever get plain ALSA to handle any sort of hotplugging automagically. It just works with Pulse. I shouldn't have to hand-edit random config files in both /etc and ~, reload kernel modules so they can get different ALSA device number module parameters, and restart apps just to get sound to go where I want it. Dan From dcbw at redhat.com Mon Sep 15 04:33:16 2008 From: dcbw at redhat.com (Dan Williams) Date: Mon, 15 Sep 2008 00:33:16 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <544eb990809110414x44c1c563l7d0da7859c166780@mail.gmail.com> <16de708d0809110814l6eda770ey54db2073391e0511@mail.gmail.com> <544eb990809110940j26d828ady63bc91e3c50cca3d@mail.gmail.com> Message-ID: <1221453197.27102.19.camel@localhost.localdomain> On Fri, 2008-09-12 at 15:48 -0400, Colin Walters wrote: > On Thu, Sep 11, 2008 at 12:40 PM, Bill Crawford > wrote: > > > > If you have multi-channel hardware that mixes itself, then using > > PulseAudio sort of defeats the purpose of that hardware ;o) > > Such hardware is as far as I understand it, really no longer sold and > has not been for some time, because it just makes more sense to do in > software. "The thing is, hardware mixing is a thing of the past, modern soundcards don't do it anymore. Precisely for doing things like mixing in software SIMD CPU extensions like SSE have been invented. Modern sound cards these days are kind of "dumbed" down, high-quality DACs. They don't do mixing anymore, many modern chips don't even do volume control anymore." http://0pointer.de/blog/projects/jeffrey-stedfast.html Dan From vonbrand at inf.utfsm.cl Mon Sep 15 05:09:55 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 15 Sep 2008 01:09:55 -0400 Subject: system autodeath In-Reply-To: <48CD0001.8010301@gdt.id.au> References: <48CD0001.8010301@gdt.id.au> Message-ID: <200809150509.m8F59thK015924@laptop14.inf.utfsm.cl> Glen Turner wrote: > I am the author of the Wiki page with the suggestion. A friend showed > me this discussion and I'd like to add a few points. I was in charge of computer labs around here, and have known my measure of users... even ones you'd think should be /very/ sophisticated. - What makes you think that when the machine gets disabled, a Google search won't suggest that the "easiest solution" is just disabling autodeath? - Nagging the user at the screen of the machine is of no use, they mostly don't care about upgrading (and if they do, can't do anything about it). The lab administrator is probably running something else in any case. - Many times around here upgrades were held back because something or other didn't work (old servers + new clients: No autofs and thus no accounts; GCC update: Examples/asignments don't compile anymore; random package upgrade: Some propietary extension or program doesn't work). Yes, sometimes it /is/ rational not to upgrade. And sadly, many times those can't be bugzilla'd decently. - Yes, a /long/ time ago we had a Windows machine just for our students working on their theses... and it started behaving weird. One of the users had disabled the antivirus, as it didn't let them run a program from diskette, while loudly warning that it was infected... - In the Red Hat 7.3 timeframe (our machines were kept rigurously up to date) a user tried an exploit targeted at _unpatched_ Red Hat 6, that had an /explicit/ warning that it wouldn't work on anything newer, and that it generated a very noticeable overload on the target, during lab rush hour against the machine of the neighboring user... we didn't know if we should punish him for attempted cracking or sheer stupidity. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From seg at haxxed.com Mon Sep 15 05:48:08 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 15 Sep 2008 00:48:08 -0500 Subject: Boot speedup with readahead In-Reply-To: <1221129185.18327.181.camel@beck.corsepiu.local> References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <20080911090752.GC17152@mokona.greysector.net> <1221129185.18327.181.camel@beck.corsepiu.local> Message-ID: <1221457688.6122.23.camel@localhost.localdomain> On Thu, 2008-09-11 at 12:33 +0200, Ralf Corsepius wrote: > I would turn this argument around: rpm missed its opportunities "to do > various things" forcing people to circumvent rpm's limitations by > ruck-sacking rpm with add-ons such as yum, yast/ycl etc. Oh come on. How is layered, loosely coupled, encapsulated separation of concerns NOT good design? The diversity of RPM front ends is a sign we're doing things right. Do we want to drag all of Yum's deps (python, and so on) down in to RPM itself? How about C++? RPM should be kept as small and simple as possible. We should avoid creeping features into it. We need to think carefully about what RPM's job really is. If anything it needs to be simpler. There was talk of ripping the URL-download "feature" out of RPM. Did that ever actually happen? Two things are getting completely confounded in this thread. 1) Prelinking 2) GNOME icon cache Prelinking is a non-vital system-wide optimization. It does not need to be in RPM. The GNOME icon cache is a whole other bag of crackrock. Is it really required for system functioning? I'm assuming since we're bending over backward for it, it is required. Duplicate spec scriptlets stink, but I think the real problem is in GNOME. Should the cache really be system wide? Why is it not per-user, and automatically re-generated? The whole thing stinks of bad design, we shouldn't have to be special-casing crap like this in our package management in the first place. It doesn't belong in RPM *or* yum. http://en.wikipedia.org/wiki/Code_smell -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Mon Sep 15 06:03:08 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 15 Sep 2008 08:03:08 +0200 Subject: Boot speedup with readahead In-Reply-To: <1221457688.6122.23.camel@localhost.localdomain> References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <20080911090752.GC17152@mokona.greysector.net> <1221129185.18327.181.camel@beck.corsepiu.local> <1221457688.6122.23.camel@localhost.localdomain> Message-ID: <1221458588.18327.564.camel@beck.corsepiu.local> On Mon, 2008-09-15 at 00:48 -0500, Callum Lerwick wrote: > On Thu, 2008-09-11 at 12:33 +0200, Ralf Corsepius wrote: > > I would turn this argument around: rpm missed its opportunities "to do > > various things" forcing people to circumvent rpm's limitations by > > ruck-sacking rpm with add-ons such as yum, yast/ycl etc. > > Oh come on. How is layered, loosely coupled, encapsulated separation of > concerns NOT good design? The point is: Any actions on rpm must be performed through rpm (rsp. corresponding library calls= only. In other words: rpm -U|-i|-e must work. High end frontends such as yum/smart/apt/yast must not performing additional hacks interfering into the system (e.g. prelinking) or the rpmdata bases. > The diversity of RPM front ends is a sign we're doing things right. I disagree. Provided the history of rpm, I take the diversity of highlevel RPM front ends, as a sign of diverging interest and of influence of vendor hegemony. > Do we want to drag all of Yum's deps (python, and so on) down in to RPM > itself? C.f. above. > How about C++? Implementation detail. > RPM should be kept as small and simple as possible. It should perform what is necessary to make rpm -U|-i|-e etc. deterministically working. Ralf From behdad at behdad.org Mon Sep 15 06:14:15 2008 From: behdad at behdad.org (Behdad Esfahbod) Date: Mon, 15 Sep 2008 02:14:15 -0400 Subject: Boot speedup with readahead In-Reply-To: <1221457688.6122.23.camel@localhost.localdomain> References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <20080911090752.GC17152@mokona.greysector.net> <1221129185.18327.181.camel@beck.corsepiu.local> <1221457688.6122.23.camel@localhost.localdomain> Message-ID: <48CDFD37.8080702@behdad.org> Callum Lerwick wrote: > The diversity of RPM front ends is a sign we're doing things right. And the fact that none reliably works... > Do we want to drag all of Yum's deps (python, and so on) down in to RPM > itself? How about C++? Since when C code can't do all the stuff Python and C++ can? > Two things are getting completely confounded in this thread. > > 1) Prelinking > 2) GNOME icon cache > > Prelinking is a non-vital system-wide optimization. It does not need to > be in RPM. You are completely missing the discussion. No one suggested RPM should do prelinking or update GNOME icon cache. The discussion is how to get RPM trigger those. > The GNOME icon cache is a whole other bag of crackrock. Design a better one if you can. > Is it really > required for system functioning? I'm assuming since we're bending over > backward for it, it is required. Duplicate spec scriptlets stink, but I > think the real problem is in GNOME. Should the cache really be system > wide? Why is it not per-user, and automatically re-generated? The whole > thing stinks of bad design, we shouldn't have to be special-casing crap > like this in our package management in the first place. It doesn't > belong in RPM *or* yum. Allowing flexible triggers such that GTK+ can add a trigger to be run whenever an icon is installed belongs in RPM. behdad > http://en.wikipedia.org/wiki/Code_smell > From seg at haxxed.com Mon Sep 15 06:19:44 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 15 Sep 2008 01:19:44 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1221453197.27102.19.camel@localhost.localdomain> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <544eb990809110414x44c1c563l7d0da7859c166780@mail.gmail.com> <16de708d0809110814l6eda770ey54db2073391e0511@mail.gmail.com> <544eb990809110940j26d828ady63bc91e3c50cca3d@mail.gmail.com> <1221453197.27102.19.camel@localhost.localdomain> Message-ID: <1221459584.6122.32.camel@localhost.localdomain> On Mon, 2008-09-15 at 00:33 -0400, Dan Williams wrote: > "The thing is, hardware mixing is a thing of the past, modern soundcards > don't do it anymore. Precisely for doing things like mixing in software > SIMD CPU extensions like SSE have been invented. Modern sound cards > these days are kind of "dumbed" down, high-quality DACs. They don't do > mixing anymore, many modern chips don't even do volume control anymore." What, they still make sound cards? Onboard sound is still noisy as hell. You can have my Aureal Vortex2 when you pry it from my cold dead hands, or whenever they stop making PCI motherboards. (Have they already? I haven't even looked. The last system I bought a few years back is an AGP system since PCIe was much more expensive for no real gain at the time...) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dcbw at redhat.com Mon Sep 15 06:38:46 2008 From: dcbw at redhat.com (Dan Williams) Date: Mon, 15 Sep 2008 02:38:46 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1221459584.6122.32.camel@localhost.localdomain> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <544eb990809110414x44c1c563l7d0da7859c166780@mail.gmail.com> <16de708d0809110814l6eda770ey54db2073391e0511@mail.gmail.com> <544eb990809110940j26d828ady63bc91e3c50cca3d@mail.gmail.com> <1221453197.27102.19.camel@localhost.localdomain> <1221459584.6122.32.camel@localhost.localdomain> Message-ID: <1221460726.27102.72.camel@localhost.localdomain> On Mon, 2008-09-15 at 01:19 -0500, Callum Lerwick wrote: > On Mon, 2008-09-15 at 00:33 -0400, Dan Williams wrote: > > "The thing is, hardware mixing is a thing of the past, modern soundcards > > don't do it anymore. Precisely for doing things like mixing in software > > SIMD CPU extensions like SSE have been invented. Modern sound cards > > these days are kind of "dumbed" down, high-quality DACs. They don't do > > mixing anymore, many modern chips don't even do volume control anymore." > > What, they still make sound cards? Onboard sound is still noisy as hell. > > You can have my Aureal Vortex2 when you pry it from my cold dead hands, > or whenever they stop making PCI motherboards. (Have they already? I Not quite yet, but most vendors ship either half-and-half or just one or two PCI slots, the rest are PCIe. Absolutely nobody ships AGP any more. Dan > haven't even looked. The last system I bought a few years back is an AGP > system since PCIe was much more expensive for no real gain at the > time...) > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From email.ahmedkamal at googlemail.com Mon Sep 15 07:32:28 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Mon, 15 Sep 2008 09:32:28 +0200 Subject: The state of resolv.conf In-Reply-To: <1221450093.27102.7.camel@localhost.localdomain> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> Message-ID: <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> Wouldn't the best way be to have an api that can be used to add and delete DNS servers and manipulate resolv.conf. Then we could have deamons call that. On Mon, Sep 15, 2008 at 5:41 AM, Dan Williams wrote: > On Sun, 2008-09-14 at 21:37 -0400, Paul Wouters wrote: > > On Mon, 15 Sep 2008, Ahmed Kamal wrote: > > > > > I have an itch. I connect to work using openvpn. Works great, except > that openvpn does not modify resolv.conf to add > > > work's dns servers (now available through vpn). It does that on Windows > though! I cannot expect openvpn or (any other > > > application) to simply overwrite /etc/resolv.conf at will, but what is > fedora missing to get an elegant solution to > > > this problem ? > > > > If you use openvpn through NetworkManager, then I'd say NetworkManager > should > > handle this for you. > > Yeah, at the end of the day something needs to mediate between services > that need to update your DNS information. If you're using > NetworkManager, then NM does this mediation for you for things like PPP, > PPtP, DHCP, openvpn, and vpnc. > > But if you're not using NM, each service (vpnc, dhcp, openvpn, pptp, > ppp, whatever) has to have it's own logic to backup and restore > resolv.conf. And that just sucks. Some distros have resolvconf to help > with this, which does the same sort of thing as NM and "stacks" DNS > configs. Most of these hacks are standard *NIX: everything has it's own > system and nothing works very well. > > Dan > > -- > 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 paul at all-the-johnsons.co.uk Mon Sep 15 08:05:47 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 15 Sep 2008 09:05:47 +0100 Subject: non-responsive maintainer 'misa': mx and pyOpenSSL packages up for adoption In-Reply-To: <20080915033702.GA4887@auslistsprd01.us.dell.com> References: <20080915033702.GA4887@auslistsprd01.us.dell.com> Message-ID: <1221465947.9141.5.camel@PB3.Linux> Hi, > I have a patch to fix the mx FTBFS bug which I will apply as soon as > permissions in pkgdb allow, but would like to see these orphaned and > put up for adoption by a loving packager. Can you provide the patch and I'll take it on for now and then when (and if) it's orphaned, I'll do it as one of my packages? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From paul at city-fan.org Mon Sep 15 08:32:42 2008 From: paul at city-fan.org (Paul Howarth) Date: Mon, 15 Sep 2008 09:32:42 +0100 Subject: The state of resolv.conf In-Reply-To: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> Message-ID: <48CE1DAA.8090303@city-fan.org> Ahmed Kamal wrote: > I have an itch. I connect to work using openvpn. Works great, except that > openvpn does not modify resolv.conf to add work's dns servers (now available > through vpn). It does that on Windows though! I cannot expect openvpn or > (any other application) to simply overwrite /etc/resolv.conf at will, but > what is fedora missing to get an elegant solution to this problem ? I use a local DNS server that forwards queries (both forward and reverse lookups for the network I'm connecting to) down the tunnel. So /etc/resolv.conf always contains just localhost as the nameserver. Paul. From paul at all-the-johnsons.co.uk Mon Sep 15 08:58:15 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 15 Sep 2008 09:58:15 +0100 Subject: non-responsive maintainer 'misa': mx and pyOpenSSL packages up for adoption In-Reply-To: <1221465947.9141.5.camel@PB3.Linux> References: <20080915033702.GA4887@auslistsprd01.us.dell.com> <1221465947.9141.5.camel@PB3.Linux> Message-ID: <1221469095.19843.0.camel@PB3.Linux> Hi, > Can you provide the patch and I'll take it on for now and then when (and > if) it's orphaned, I'll do it as one of my packages? mx-3.1.1 is now on my fedorapeople area pfj.fedorapeople.org IIRC TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dominik at greysector.net Mon Sep 15 10:31:58 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 15 Sep 2008 12:31:58 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: <20080915103158.GB20342@mokona.greysector.net> On Friday, 12 September 2008 at 21:46, Colin Walters wrote: > On Fri, Sep 12, 2008 at 3:43 PM, Janina Sajka wrote: > > > > The problems we have right now are sufficiently sever to be > > showstoppers. At the SpeakupModified.Org we recommend disabling > > pulseaudio. As things stand in F-9, one gets no audio until after a user > > logs in on the GUI. So, how are those who need screen reader support > > supposed to use the a11y features of GDM? As it stands, there seems no > > way to get console audio without that GUI login. Also a nonstarter in > > the screen reader user community. > > If you want to run terminal applications, can't you just log in to a > full screen gnome-terminal? I can, but that's irrelevant. Why do you want to take my ability to log in in text mode? > > It seems a useful initial step toward resolution is to run pulseaudio > > as a system daemon, via an init script, /sbin/service, /sbin/chkconfig. > > The trade-offs vs the per user model that F-9 employs are probably more > > than acceptable to most a11y users. > > > > So, let me simply ask ... Has anyone a working init script for > > pulseaudio as a system daemon? Anything close that we could continue to > > refine as an alternative configuration option for Fedora? > > We're going to be removing the legacy non-X system consoles by default > in the long run. Please tell me this is some kind of bad joke! Is Fedora becoming like MS Windows? Just when Microsoft announced that you'll be able to install Windows 7 without a GUI, you're announcing something opposite for Fedora? Are you going to drive away people who like the textmode better? Seriously, that would be one of the changes that would drive *me* away from Fedora. Please don't do that. I like Fedora too much and I've invested too much time in improving it for me. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From rjones at redhat.com Mon Sep 15 10:30:52 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 15 Sep 2008 11:30:52 +0100 Subject: Plan for tomorrows (20080910) FESCO meeting In-Reply-To: References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> <48C7F0DE.7090402@gmail.com> <20080910161820.GB1535@amd.home.annexia.org> <48C807FB.1030400@gmail.com> <20080910185041.GA2878@amd.home.annexia.org> Message-ID: <20080915103052.GA24308@amd.home.annexia.org> On Thu, Sep 11, 2008 at 11:02:42PM +0000, Kevin Kofler wrote: > Debian, on the other hand, has had success with building much of > NSIS with a MinGW cross-compiler. You can take a look at their > package. The README.Debian in the current Debian experimental > package says only the System plugin still doesn't build (due to > inline assembly, and there are attempts to fix that). You may need a > fairly old MinGW GCC to get it to build without heavy patching > though, at least last I checked NSIS used stuff like lvalue casts in > their code, as M$VC doesn't complain about those. Debian also had a > patch to support 64-bit builds (real ones, not -m32 as upstream NSIS > used), which I used in my package too, but this appears to be > finally fixed upstream in 2.39. Thanks - I wasn't aware that Debian packaged NSIS, but I will definitely take a look at this & at your stuff. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From nicolas.mailhot at laposte.net Mon Sep 15 10:35:33 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 15 Sep 2008 12:35:33 +0200 (CEST) Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> Message-ID: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> Le Sam 13 septembre 2008 00:59, Arthur Pemberton a ?crit : > > On Fri, Sep 12, 2008 at 5:52 PM, Colin Walters > wrote: >> On Fri, Sep 12, 2008 at 6:36 PM, Matthew Woehlke >> wrote: >> >>> No, >>> thanks; I'd rather have X fail to start and dump me at a normal >>> console from >>> which I can fix the problem *without rebooting*, much less needing >>> to dig up >>> a rescue disk :P. >> >> I believe we already do that today, and am not advocating removing >> that functionality if possible. Anyways, I've said what I need to, >> so >> hopefully people won't be surprised later. > > > I'm confused. Is Fedora really going to remove non X consoles? Mid-term that wouln't be such a bad idea. Of course the replacements need to prove their robustness. -- Nicolas Mailhot From dominik at greysector.net Mon Sep 15 10:36:28 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 15 Sep 2008 12:36:28 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: <20080915103628.GC20342@mokona.greysector.net> On Saturday, 13 September 2008 at 00:16, Colin Walters wrote: > On Fri, Sep 12, 2008 at 5:59 PM, Matthew Woehlke > wrote: > > Colin Walters wrote: > >> > >> We're going to be removing the legacy non-X system consoles by default > >> in the long run. > > > > Um... what happens then when X is broken? > > What happens when the linux kernel is broken? Bad analogy. You can work without X, but you can't without the kernel. > What happens when /bin/sh is broken? Use /bin/csh. ;) > What happens when NetworkManager is broken? I still use the old network scripts. You will pry them from my rotting fingers, but not before. > You fix the bug. Sure. If you can. If not, you file a bugreport, but in the meantime, you want to be able to work. > Also, one thing I would like to see Fedora install by default is a > compressed recovery image, rather than just multiple kernels. I don't want to have to reboot just to fix a typo in xorg.conf. Did you spend too much time working on MS Windows? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Mon Sep 15 10:39:16 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 15 Sep 2008 12:39:16 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: <20080915103916.GD20342@mokona.greysector.net> On Saturday, 13 September 2008 at 00:52, Colin Walters wrote: > On Fri, Sep 12, 2008 at 6:36 PM, Matthew Woehlke > wrote: > > > No, > > thanks; I'd rather have X fail to start and dump me at a normal console from > > which I can fix the problem *without rebooting*, much less needing to dig up > > a rescue disk :P. > > I believe we already do that today, and am not advocating removing > that functionality if possible. You said you were, just the day before. Are you retracting your statement? > Anyways, I've said what I need to, so hopefully people won't be surprised later. Surprised by what, exactly? If you disable text mode log in, you'd better be prepared to handle an enraged mob with torches and pitchforks, because this is going to get ugly real soon. ;) Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Mon Sep 15 10:41:07 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 15 Sep 2008 12:41:07 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> Message-ID: <20080915104107.GE20342@mokona.greysector.net> On Saturday, 13 September 2008 at 01:02, Colin Walters wrote: > On Fri, Sep 12, 2008 at 6:59 PM, Arthur Pemberton wrote: > > On Fri, Sep 12, 2008 at 5:52 PM, Colin Walters wrote: > >> On Fri, Sep 12, 2008 at 6:36 PM, Matthew Woehlke > >> wrote: > >> > >>> No, > >>> thanks; I'd rather have X fail to start and dump me at a normal console from > >>> which I can fix the problem *without rebooting*, much less needing to dig up > >>> a rescue disk :P. > >> > >> I believe we already do that today, and am not advocating removing > >> that functionality if possible. Anyways, I've said what I need to, so > >> hopefully people won't be surprised later. > > > > > > I'm confused. Is Fedora really going to remove non X consoles? > > I'm talking about the direction and technology of the desktop product; > what server images, embedded etc. do is an entirely different matter. Except there are no "server images" in Fedora. And I want text mode consoles on my desktop! Why do you want to remove them? You have been asked several times already and provide no answers so far. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Mon Sep 15 10:56:01 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 15 Sep 2008 12:56:01 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <1221269239.3076.41.camel@rosebud> Message-ID: <20080915105601.GF20342@mokona.greysector.net> On Saturday, 13 September 2008 at 03:39, Colin Walters wrote: > On Fri, Sep 12, 2008 at 9:27 PM, Seth Vidal wrote: > > On Fri, 2008-09-12 at 19:02 -0400, Colin Walters wrote: > > > >> I'm talking about the direction and technology of the desktop product; > >> what server images, embedded etc. do is an entirely different matter. > > > > > > Desktop Product? We don't make a desktop product. > > The live CD image, combined with the default comps tree from > "gnome-desktop" is what I consider the desktop product. So let me get this straight. You only want to disable text mode consoles in the live CD spin? Why didn't you say so in the beginning? Even so, it is still a bad idea. > > We make a linux distribution. > > I am certainly not here to make a "linux distribution", which I > consider a derogatory term. What? Are you serious? I certainly am here to do that and I'm proud of it. And I know many others who feel the same. > It implies that all we do is take the > linux kernel and a bunch of tarballs we found on the internet, compile > them, and throw the binaries over the wall. It implies no such thing. I don't know where you get your ideas, but please keep them away from Fedora. > The goal is rather to > make a compelling and useful free desktop operating system. "Useful" is the key word here. Why you insist on calling it "desktop" OS, I don't know. Maybe you're not talking about Fedora. > To do > that, you need to make choices about how the operating system works, > and how pieces fit together. If people want an OS that tries to > support every possible configuration of every tarball that can be > found on the Internet, That's a non-sequitur and you know it. Giving users a distribution that will allow them to run whatever software they want (regardless of whether it is included in Fedora or not) is one of the goals of Fedora, but this has nothing to do with text mode consoles being there or not. > and is consequently near-paralyzed by choice > and is only able to make releases every 5 years, debian.org is --> > that way. Apparently you don't listen to what users have to say. If you want to support only a single configuration and deny users the choice, apple.com is ---> that way. Or maybe microsoft.com. Definitely NOT fedoraproject.org. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Mon Sep 15 10:57:04 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 15 Sep 2008 12:57:04 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> Message-ID: <20080915105704.GG20342@mokona.greysector.net> On Monday, 15 September 2008 at 12:35, Nicolas Mailhot wrote: > > > Le Sam 13 septembre 2008 00:59, Arthur Pemberton a ?crit : > > > > On Fri, Sep 12, 2008 at 5:52 PM, Colin Walters > > wrote: > >> On Fri, Sep 12, 2008 at 6:36 PM, Matthew Woehlke > >> wrote: > >> > >>> No, > >>> thanks; I'd rather have X fail to start and dump me at a normal > >>> console from > >>> which I can fix the problem *without rebooting*, much less needing > >>> to dig up > >>> a rescue disk :P. > >> > >> I believe we already do that today, and am not advocating removing > >> that functionality if possible. Anyways, I've said what I need to, > >> so > >> hopefully people won't be surprised later. > > > > > > I'm confused. Is Fedora really going to remove non X consoles? > > Mid-term that wouln't be such a bad idea. One would have to say why it is a good idea in the first place. > Of course the replacements need to prove their robustness. What replacements do you have in mind? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From bserkez at gmail.com Mon Sep 15 11:02:32 2008 From: bserkez at gmail.com (Brett Serkez) Date: Mon, 15 Sep 2008 07:02:32 -0400 Subject: The state of resolv.conf In-Reply-To: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> Message-ID: 2008/9/14 Ahmed Kamal : > I have an itch. I connect to work using openvpn. Works great, except that > openvpn does not modify resolv.conf to add work's dns servers (now available > through vpn). It does that on Windows though! I cannot expect openvpn or > (any other application) to simply overwrite /etc/resolv.conf at will, but > what is fedora missing to get an elegant solution to this problem ? You should be able to push DHCP options from the OpenVPN server: http://openvpn.net/index.php/documentation/howto.html#dhcp push "dhcp-option DNS 10.66.0.4" push "dhcp-option DNS 10.66.0.5" The client OS shouldn't matter, it should be picking up the DHCP options when the OpenVPN client brings up the interface when it comes up. Brett From email.ahmedkamal at googlemail.com Mon Sep 15 11:09:57 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Mon, 15 Sep 2008 13:09:57 +0200 Subject: The state of resolv.conf In-Reply-To: References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> Message-ID: <3da3b5b40809150409u4e440e1dvdcb8eb1f7d99bba2@mail.gmail.com> I'm already pushing DNS .. I don't believe it works on Linux clients though! Take a look at the kind of hacks needed: http://www.phocean.net/?p=12 On Mon, Sep 15, 2008 at 1:02 PM, Brett Serkez wrote: > 2008/9/14 Ahmed Kamal : > > I have an itch. I connect to work using openvpn. Works great, except that > > openvpn does not modify resolv.conf to add work's dns servers (now > available > > through vpn). It does that on Windows though! I cannot expect openvpn or > > (any other application) to simply overwrite /etc/resolv.conf at will, but > > what is fedora missing to get an elegant solution to this problem ? > > You should be able to push DHCP options from the OpenVPN server: > > http://openvpn.net/index.php/documentation/howto.html#dhcp > > push "dhcp-option DNS 10.66.0.4" > push "dhcp-option DNS 10.66.0.5" > > The client OS shouldn't matter, it should be picking up the DHCP > options when the OpenVPN client brings up the interface when it comes > up. > > Brett > > -- > 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 bojan at rexursive.com Mon Sep 15 11:10:00 2008 From: bojan at rexursive.com (Bojan Smojver) Date: Mon, 15 Sep 2008 11:10:00 +0000 (UTC) Subject: Pulseaudio : lots of issues, how can I help? References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: Colin Walters verbum.org> writes: > We're going to be removing the legacy non-X system consoles by default > in the long run. I am sincerely hoping that we are not heading for this kind of disaster: http://technet.microsoft.com/en-us/library/cc750820.aspx Don't worry about graphics drivers being moved into the kernel - that's not the biggest evil here. Pay particular attention to this sentence: "And there is no loss of reliability, since (a) the kernel mode implementations of Win32 are fully protected from direct access by applications; and (b) the Win32 server process is considered a critical system component of Windows NT 3.51, such that if the CSRSS.EXE process faults the entire Windows NT operating system is _shutdown_." Note how Microsoft engineers completely missed the real reliability point here. The situation is grave (i.e. the reliability is crap) due to idiotic design - and right from the start - they just documented it here. They are here because they have no _alternative_ UI. No other way to log in. No way to kill bad stuff and continue. Let's not do that with Fedora. Please. -- Bojan From walters at verbum.org Mon Sep 15 11:12:02 2008 From: walters at verbum.org (Colin Walters) Date: Mon, 15 Sep 2008 07:12:02 -0400 Subject: Boot speedup with readahead In-Reply-To: <1221457688.6122.23.camel@localhost.localdomain> References: <1220886750.987.12.camel@rosebud> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <20080911090752.GC17152@mokona.greysector.net> <1221129185.18327.181.camel@beck.corsepiu.local> <1221457688.6122.23.camel@localhost.localdomain> Message-ID: 2008/9/15 Callum Lerwick : > On Thu, 2008-09-11 at 12:33 +0200, Ralf Corsepius wrote: >> I would turn this argument around: rpm missed its opportunities "to do >> various things" forcing people to circumvent rpm's limitations by >> ruck-sacking rpm with add-ons such as yum, yast/ycl etc. > > Oh come on. How is layered, loosely coupled, encapsulated separation of > concerns NOT good design? > > The diversity of RPM front ends is a sign we're doing things right. No. If even 1/10 of the energy that goes into all these alternate frontends went into fixing yum, we would have one better frontend instead of multiples with different sets of bugs. > Do we want to drag all of Yum's deps (python, and so on) down in to RPM > itself? If you have a lot of C code, adding a scripting language on top is a *very* sensible way to write an application. > The GNOME icon cache is a whole other bag of crackrock. Is it really > required for system functioning? Look, building an actual operating system turns out to be harder than just wget and untar and call it done. There are going to be other things that will need global knowledge outside of an individual piece of software. > I'm assuming since we're bending over > backward for it, it is required. Duplicate spec scriptlets stink, but I > think the real problem is in GNOME. Should the cache really be system > wide? Why is it not per-user, and automatically re-generated? That would be immensely wasteful on the kinds of servers that have multiple users. I would think this would be obvious and not require explanation.. From nicolas.mailhot at laposte.net Mon Sep 15 11:39:35 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 15 Sep 2008 13:39:35 +0200 (CEST) Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080915105704.GG20342@mokona.greysector.net> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> Message-ID: <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> Le Lun 15 septembre 2008 12:57, Dominik 'Rathann' Mierzejewski a ?crit : > > On Monday, 15 September 2008 at 12:35, Nicolas Mailhot wrote: >> Le Sam 13 septembre 2008 00:59, Arthur Pemberton a ?crit : >> > I'm confused. Is Fedora really going to remove non X consoles? >> >> Mid-term that wouln't be such a bad idea. > > One would have to say why it is a good idea in the first place. Simply put, non-X-console input is a mess (X input is a mess too but at least there are people trying to fix it), non-X-console font support has fossilized, and support for modern high resolution screens is severely lacking. The console has not evolved for a long time, while text requirements have gone up. At this point a dumbed down text-only X session is probably the only credible console future (or something that is not X at all but uses many libraries we associate with apps now). Non-X-console state is so bad nowadays I don't bother reporting bugs on it. Even if they are fixed they always reappear the next Fedora cycle. There is simply not enough console users and console developpers to do anything but life support anymore. And that's ok. Do remember that X was defined at a time hardware was vastly less powerful and core X is not wasteful at all. Compared to how the rest of the system has bloated, X is definitely lean and mean. -- Nicolas Mailhot From Matt_Domsch at dell.com Mon Sep 15 11:52:24 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 15 Sep 2008 06:52:24 -0500 Subject: non-responsive maintainer 'misa': mx and pyOpenSSL packages up for adoption In-Reply-To: <1221465947.9141.5.camel@PB3.Linux> References: <20080915033702.GA4887@auslistsprd01.us.dell.com> <1221465947.9141.5.camel@PB3.Linux> Message-ID: <20080915115224.GA17799@auslistsprd01.us.dell.com> On Mon, Sep 15, 2008 at 09:05:47AM +0100, Paul wrote: > Hi, > > > I have a patch to fix the mx FTBFS bug which I will apply as soon as > > permissions in pkgdb allow, but would like to see these orphaned and > > put up for adoption by a loving packager. > > Can you provide the patch and I'll take it on for now and then when (and > if) it's orphaned, I'll do it as one of my packages? I attached it to bugzilla 434325. It was simply missing a .egg-info file in %files. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From rawhide at fedoraproject.org Mon Sep 15 11:54:16 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Mon, 15 Sep 2008 11:54:16 +0000 (UTC) Subject: rawhide report: 20080914 changes Message-ID: <20080915115417.252D01F8259@releng2.fedora.phx.redhat.com> Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Broken deps for i386 ---------------------------------------------------------- em8300-0.17.1-1.fc10.i386 requires /etc/alsa/cards evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.i386 requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so Broken deps for x86_64 ---------------------------------------------------------- em8300-0.17.1-1.fc10.x86_64 requires /etc/alsa/cards evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.x86_64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- em8300-0.17.1-1.fc10.ppc requires /etc/alsa/cards evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.ppc requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so Broken deps for ppc64 ---------------------------------------------------------- eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 em8300-0.17.1-1.fc10.ppc64 requires /etc/alsa/cards evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave livecd-tools-018-1.fc10.ppc64 requires yaboot mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.ppc64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) From skvidal at fedoraproject.org Mon Sep 15 11:53:47 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 15 Sep 2008 07:53:47 -0400 Subject: Boot speedup with readahead In-Reply-To: References: <1220886750.987.12.camel@rosebud> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <20080911090752.GC17152@mokona.greysector.net> <1221129185.18327.181.camel@beck.corsepiu.local> <1221457688.6122.23.camel@localhost.localdomain> Message-ID: <1221479627.25056.16.camel@rosebud> On Mon, 2008-09-15 at 07:12 -0400, Colin Walters wrote: > No. If even 1/10 of the energy that goes into all these alternate > frontends went into fixing yum, we would have one better frontend > instead of multiples with different sets of bugs. > Really? Then 1/10th of the energy? I'm intrigued to hear what you believe is broken with yum, now. Better yet, I'm interested to see what bugs you've filed. I don't think yum is flaw free but I am curious what all things you perceive as wrong that you also seem to believe can be fixed with 1/10th the energy being spent on the various pkg managers. -sv From skvidal at fedoraproject.org Mon Sep 15 11:54:36 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 15 Sep 2008 07:54:36 -0400 Subject: Boot speedup with readahead In-Reply-To: <48CDFD37.8080702@behdad.org> References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <20080911090752.GC17152@mokona.greysector.net> <1221129185.18327.181.camel@beck.corsepiu.local> <1221457688.6122.23.camel@localhost.localdomain> <48CDFD37.8080702@behdad.org> Message-ID: <1221479676.25056.18.camel@rosebud> On Mon, 2008-09-15 at 02:14 -0400, Behdad Esfahbod wrote: > Callum Lerwick wrote: > > The diversity of RPM front ends is a sign we're doing things right. > > And the fact that none reliably works... Do you think that might reflect on the complexity of problem more than it reflects the tools? -sv From dominik at greysector.net Mon Sep 15 12:04:57 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 15 Sep 2008 14:04:57 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> References: <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> Message-ID: <20080915120457.GH20342@mokona.greysector.net> On Monday, 15 September 2008 at 13:39, Nicolas Mailhot wrote: > > > Le Lun 15 septembre 2008 12:57, Dominik 'Rathann' Mierzejewski a ?crit : > > > > On Monday, 15 September 2008 at 12:35, Nicolas Mailhot wrote: > >> Le Sam 13 septembre 2008 00:59, Arthur Pemberton a ?crit : > >> > I'm confused. Is Fedora really going to remove non X consoles? > >> > >> Mid-term that wouln't be such a bad idea. > > > > One would have to say why it is a good idea in the first place. > > Simply put, non-X-console input is a mess (X input is a mess too but > at least there are people trying to fix it), non-X-console font > support has fossilized, and support for modern high resolution screens > is severely lacking. That doesn't make it useless, nor is grounds for removal. Admittedly it is not something people use on a daily bases (even if I do know a few who do), but it still has its applications. > The console has not evolved for a long time, while text requirements > have gone up. At this point a dumbed down text-only X session is > probably the only credible console future (or something that is not X > at all but uses many libraries we associate with apps now). Irrelevant. I'm not saying the text mode console has to have the same usability as a full-screen terminal emulator running on X. > Non-X-console state is so bad nowadays I don't bother reporting bugs > on it. Even if they are fixed they always reappear the next Fedora > cycle. There is simply not enough console users and console > developpers to do anything but life support anymore. I don't know of any bugs that prevent me or my colleagues from using the text mode console. That's not to say they don't exist, but I've never heard of any problems with the console either personally or from my colleagues. > And that's ok. Do remember that X was defined at a time hardware was > vastly less powerful and core X is not wasteful at all. Compared to > how the rest of the system has bloated, X is definitely lean and mean. That doesn't mean you have to disable the text mode console. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From nicolas.mailhot at laposte.net Mon Sep 15 12:26:30 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 15 Sep 2008 14:26:30 +0200 (CEST) Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080915120457.GH20342@mokona.greysector.net> References: <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> Message-ID: <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> Le Lun 15 septembre 2008 14:04, Dominik 'Rathann' Mierzejewski a ?crit : > > On Monday, 15 September 2008 at 13:39, Nicolas Mailhot wrote: >> >> The console has not evolved for a long time, while text requirements >> have gone up. At this point a dumbed down text-only X session is >> probably the only credible console future (or something that is not >> X >> at all but uses many libraries we associate with apps now). > > Irrelevant. I'm not saying the text mode console has to have the > same usability as a full-screen terminal emulator running on X. That may be irrelevant for you but that's not irrelevant for me both as a console user and as someone who is an upstream maintainer for my language of some of the bits the console use. The separation between the X text stack and the console text stack is not worth the maintenance burden. As evidenced by the fact the maintenance part of the console text stack (even as iso-functionnality) is not done properly anymore. >> Non-X-console state is so bad nowadays I don't bother reporting bugs >> on it. Even if they are fixed they always reappear the next Fedora >> cycle. There is simply not enough console users and console >> developpers to do anything but life support anymore. > > I don't know of any bugs that prevent me or my colleagues from using > the text mode console. Lucky you. > That's not to say they don't exist, but I've > never heard of any problems with the console either personally or from > my colleagues. So it works for you. OSS works for some people too. >> And that's ok. Do remember that X was defined at a time hardware was >> vastly less powerful and core X is not wasteful at all. Compared to >> how the rest of the system has bloated, X is definitely lean and >> mean. > > That doesn't mean you have to disable the text mode console. Do you volunteer for maintening all the stuff text mode console relies on (fonts, layout definitions, etc)? -- Nicolas Mailhot From lesmikesell at gmail.com Mon Sep 15 12:37:21 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 15 Sep 2008 07:37:21 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> Message-ID: <48CE5701.7000109@gmail.com> Nicolas Mailhot wrote: > > Simply put, non-X-console input is a mess (X input is a mess too but > at least there are people trying to fix it), non-X-console font > support has fossilized, and support for modern high resolution screens > is severely lacking. Will you still be able to run a headless machine with its console redirected to a serial port? > And that's ok. Do remember that X was defined at a time hardware was > vastly less powerful and core X is not wasteful at all. Compared to > how the rest of the system has bloated, X is definitely lean and mean. But there's no reason to assume that the X display(s) is/are directly connected to the CPU in question. What do you do when they aren't? -- Les Mikesell lesmikesell at gmail.com From ssorce at redhat.com Mon Sep 15 12:44:07 2008 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 15 Sep 2008 08:44:07 -0400 Subject: The state of resolv.conf In-Reply-To: <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> Message-ID: <1221482647.15427.10.camel@localhost.localdomain> On Mon, 2008-09-15 at 09:32 +0200, Ahmed Kamal wrote: > Wouldn't the best way be to have an api that can be used to add and > delete DNS servers and manipulate resolv.conf. Then we could have > deamons call that. No what you really need is more than a simple resolv.conf file. We need a default caching daemon (which by itself will solve a lot of other issues) that tools like NM, vpnc, openvpn can interact with. These tools will tell the caching daemon which IP ranges and which domains their provided forwarders should be consulted for. All dynamic so that as soon as one daemon goes away, the caching DNS will notice and revert queries to the default DNS. And if NM/routes go away it can keep working out of its cache. Simo. -- Simo Sorce * Red Hat, Inc * New York From nicolas.mailhot at laposte.net Mon Sep 15 12:49:01 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 15 Sep 2008 14:49:01 +0200 (CEST) Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <48CE5701.7000109@gmail.com> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE5701.7000109@gmail.com> Message-ID: <7c601311b9fd1b6bf9ded8a1d6419efa.squirrel@rousalka.dyndns.org> Le Lun 15 septembre 2008 14:37, Les Mikesell a ?crit : > > Nicolas Mailhot wrote: >> >> Simply put, non-X-console input is a mess (X input is a mess too but >> at least there are people trying to fix it), non-X-console font >> support has fossilized, and support for modern high resolution >> screens >> is severely lacking. > > Will you still be able to run a headless machine with its console > redirected to a serial port? Why not ? >> And that's ok. Do remember that X was defined at a time hardware was >> vastly less powerful and core X is not wasteful at all. Compared to >> how the rest of the system has bloated, X is definitely lean and >> mean. > > But there's no reason to assume that the X display(s) is/are directly > connected to the CPU in question. What do you do when they aren't? Do not parse -- Nicolas Mailhot From walters at verbum.org Mon Sep 15 12:51:20 2008 From: walters at verbum.org (Colin Walters) Date: Mon, 15 Sep 2008 08:51:20 -0400 Subject: Boot speedup with readahead In-Reply-To: <1221479627.25056.16.camel@rosebud> References: <1220886750.987.12.camel@rosebud> <1221070577.987.120.camel@rosebud> <20080911090752.GC17152@mokona.greysector.net> <1221129185.18327.181.camel@beck.corsepiu.local> <1221457688.6122.23.camel@localhost.localdomain> <1221479627.25056.16.camel@rosebud> Message-ID: On Mon, Sep 15, 2008 at 7:53 AM, Seth Vidal wrote: > On Mon, 2008-09-15 at 07:12 -0400, Colin Walters wrote: > >> No. If even 1/10 of the energy that goes into all these alternate >> frontends went into fixing yum, we would have one better frontend >> instead of multiples with different sets of bugs. >> > > Really? Then 1/10th of the energy? I'm intrigued to hear what you > believe is broken with yum, now. Better yet, I'm interested to see what > bugs you've filed. I personally don't have any real issues. About the only thing that annoys me is that it prompts "Y/n" for installing single packages, but I've just gotten in the habit of using -y. Apparently other people do have issues, but I don't know much about it. I think you perceived my message as being negative towards yum - it was not intended to be so, quite the opposite. When I said "fixing yum" I meant that in the general way of "all software has flaws and can be improved". From simon.andrews at bbsrc.ac.uk Mon Sep 15 12:52:11 2008 From: simon.andrews at bbsrc.ac.uk (Simon Andrews) Date: Mon, 15 Sep 2008 13:52:11 +0100 Subject: Non responsive maintainer question Message-ID: A bug I reported back in February (#432767) has been sitting for some time with a couple of reported fixes, but no response from the maintainer. I've looked at the non-responsive maintainer policy, but this seems to only apply in the case where you want to take over the package yourself - which I don't have the skills to do. Is there a procedure for flagging up that a package maintainer seems to have gone AWOL whilst asking for anyone suitably qualified to take it over? Simon. From lesmikesell at gmail.com Mon Sep 15 13:03:18 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 15 Sep 2008 08:03:18 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <7c601311b9fd1b6bf9ded8a1d6419efa.squirrel@rousalka.dyndns.org> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE5701.7000109@gmail.com> <7c601311b9fd1b6bf9ded8a1d6419efa.squirrel@rousalka.dyndns.org> Message-ID: <48CE5D16.5060805@gmail.com> Nicolas Mailhot wrote: > >>> Simply put, non-X-console input is a mess (X input is a mess too but >>> at least there are people trying to fix it), non-X-console font >>> support has fossilized, and support for modern high resolution >>> screens >>> is severely lacking. >> Will you still be able to run a headless machine with its console >> redirected to a serial port? > > Why not ? I think I'm confused by the term 'non X consoles'. Is that something different than the native text mode you see before X starts? >>> And that's ok. Do remember that X was defined at a time hardware was >>> vastly less powerful and core X is not wasteful at all. Compared to >>> how the rest of the system has bloated, X is definitely lean and >>> mean. >> But there's no reason to assume that the X display(s) is/are directly >> connected to the CPU in question. What do you do when they aren't? > > Do not parse I rarely use the console of the machine running my programs. I'll either ssh for text mode or use a remote X or freenx/NX to connect from elsewhere, and in the case of NX, often floating the session around among several different displays keeping running programs intact. That leaves the question of how to manage the host without needing X locally, and back to the topic of pulseaudio, how to use the host's audio system when the X sessions are displayed elsewhere. And by the way, I highly recommend the freenx/NX combo if you ever move from your desk. -- Les Mikesell lesmikesell at gmail.com From nicolas.mailhot at laposte.net Mon Sep 15 13:24:26 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 15 Sep 2008 15:24:26 +0200 (CEST) Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <48CE5D16.5060805@gmail.com> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE5701.7000109@gmail.com> <7c601311b9fd1b6bf9ded8a1d6419efa.squirrel@rousalka.dyndns.org> <48CE5D16.5060805@gmail.com> Message-ID: <7585a70c49ca0b864930da2f0d060e1e.squirrel@rousalka.dyndns.org> Le Lun 15 septembre 2008 15:03, Les Mikesell a ?crit : > > Nicolas Mailhot wrote: >> >>>> Simply put, non-X-console input is a mess (X input is a mess too >>>> but >>>> at least there are people trying to fix it), non-X-console font >>>> support has fossilized, and support for modern high resolution >>>> screens >>>> is severely lacking. >>> Will you still be able to run a headless machine with its console >>> redirected to a serial port? >> >> Why not ? > > I think I'm confused by the term 'non X consoles'. Is that something > different than the native text mode you see before X starts? I think you have two different things. A VT to which you can attach an X session, a serial port, a remote SSH, mingetty... and the software stack used to display locally the VT text and collect user input. I've no problem with the low-level VT bit. The current console software stack OTOH has rotten and seriously needs replacement. -- Nicolas Mailhot From pingou at pingoured.fr Mon Sep 15 13:27:27 2008 From: pingou at pingoured.fr (Pierre-Yves) Date: Mon, 15 Sep 2008 15:27:27 +0200 Subject: Source0 from Trac Message-ID: <48CE62BF.4030401@pingoured.fr> Dear list, I have a small question, while packaging source obtained from a trac wiki/git the link given on Source0 can be: 1 - https://fedorahosted.org/r2spec/export/96ae0f7a737bcda9950ecddc452800804e0c7346/R2spec-2.5.0.tar.gz or 2 - https://fedorahosted.org/r2spec/browser/R2spec-2.5.0.tar.gz?format=raw But: 1- the link is quite ugly and will need to be changed for every release 2- the link usable via wget but provide a file named R2spec-2.5.0.tar.gz?format=raw which is not exactly what we are looking for... I was thus wondering: Is there a way on the Trac of Fedorahosted to get a clean link to a tarball ? If not what would be the best way to write Source0 on the spec file ? I tought https://fedorahosted.org/r2spec/browser/R2spec-2.5.0.tar.gz would be fine with an additional comments but I'm not sure this is correct. Any input ? :) Thanks, Pierre From pingou at pingoured.fr Mon Sep 15 13:27:27 2008 From: pingou at pingoured.fr (Pierre-Yves) Date: Mon, 15 Sep 2008 15:27:27 +0200 Subject: Source0 from Trac Message-ID: <48CE62BF.4030401@pingoured.fr> Dear list, I have a small question, while packaging source obtained from a trac wiki/git the link given on Source0 can be: 1 - https://fedorahosted.org/r2spec/export/96ae0f7a737bcda9950ecddc452800804e0c7346/R2spec-2.5.0.tar.gz or 2 - https://fedorahosted.org/r2spec/browser/R2spec-2.5.0.tar.gz?format=raw But: 1- the link is quite ugly and will need to be changed for every release 2- the link usable via wget but provide a file named R2spec-2.5.0.tar.gz?format=raw which is not exactly what we are looking for... I was thus wondering: Is there a way on the Trac of Fedorahosted to get a clean link to a tarball ? If not what would be the best way to write Source0 on the spec file ? I tought https://fedorahosted.org/r2spec/browser/R2spec-2.5.0.tar.gz would be fine with an additional comments but I'm not sure this is correct. Any input ? :) Thanks, Pierre From jeff at ocjtech.us Mon Sep 15 13:32:10 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Mon, 15 Sep 2008 08:32:10 -0500 Subject: Source0 from Trac In-Reply-To: <48CE62BF.4030401@pingoured.fr> References: <48CE62BF.4030401@pingoured.fr> Message-ID: <935ead450809150632h26389da6w7878d9b4387f4491@mail.gmail.com> On Mon, Sep 15, 2008 at 8:27 AM, Pierre-Yves wrote: > > Is there a way on the Trac of Fedorahosted to get a clean link to a tarball See the next-to-last entry in the FedoraHosted FAQ: https://fedorahosted.org/web/faq If you follow the outlined procedure tarballs will show up here: https://fedorahosted.org/releases/r/2/r2spec/ -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" From paul at all-the-johnsons.co.uk Mon Sep 15 13:31:33 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 15 Sep 2008 14:31:33 +0100 Subject: non-responsive maintainer 'misa': mx and pyOpenSSL packages up for adoption In-Reply-To: <1221465947.9141.5.camel@PB3.Linux> References: <20080915033702.GA4887@auslistsprd01.us.dell.com> <1221465947.9141.5.camel@PB3.Linux> Message-ID: <1221485493.5272.16.camel@PB3.Linux> Hi, > > I have a patch to fix the mx FTBFS bug which I will apply as soon as > > permissions in pkgdb allow, but would like to see these orphaned and > > put up for adoption by a loving packager. > > Can you provide the patch and I'll take it on for now and then when (and > if) it's orphaned, I'll do it as one of my packages? If someone puts me down as the co-maintainer, mx-3.1.1 is ready to roll into rawhide! TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jeff at ocjtech.us Mon Sep 15 13:33:47 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Mon, 15 Sep 2008 08:33:47 -0500 Subject: Does your package provide GStreamer plugins? In-Reply-To: <1221398703.24928.289.camel@cookie.hadess.net> References: <1221215325.24928.235.camel@cookie.hadess.net> <935ead450809120606g2a0a93e2p350d9917417d180e@mail.gmail.com> <1221398703.24928.289.camel@cookie.hadess.net> Message-ID: <935ead450809150633k7f6b0eedld976ad8d3a72b544@mail.gmail.com> On Sun, Sep 14, 2008 at 8:25 AM, Bastien Nocera wrote: > On Fri, 2008-09-12 at 08:06 -0500, Jeffrey Ollie wrote: >> On Fri, Sep 12, 2008 at 5:28 AM, Bastien Nocera wrote: >> > >> > If your package provides GStreamer plugins, please rebuild it in rawhide >> > with the latest gstreamer-devel and RPM builds. >> > >> > We are trying to use a PackageKit-based solution to installing missing >> > GStreamer plugins. The new GStreamer and RPM packages will add strings >> > like this to your RPM's provides: >> > gstreamer0.10(urisource-ssh)()(64bit) >> > gstreamer0.10(decoder-application/ogg)()(64bit) >> >> I tried rebuilding schroedinger but I didn't see any new provides show >> up. Is there something I'm doing wrong? Here's a scratch build I >> just did: >> >> http://koji.fedoraproject.org/koji/taskinfo?taskID=822502 > > An updated gstreamer package is building, let me know whether that fixes > the problem for you: > http://koji.fedoraproject.org/koji/taskinfo?taskID=825065 Looks like it worked: http://koji.fedoraproject.org/koji/taskinfo?taskID=825991 Is this something we should request beta-freeze tag overrides for? -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" From dcbw at redhat.com Mon Sep 15 13:36:04 2008 From: dcbw at redhat.com (Dan Williams) Date: Mon, 15 Sep 2008 09:36:04 -0400 Subject: The state of resolv.conf In-Reply-To: <3da3b5b40809150409u4e440e1dvdcb8eb1f7d99bba2@mail.gmail.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <3da3b5b40809150409u4e440e1dvdcb8eb1f7d99bba2@mail.gmail.com> Message-ID: <1221485764.10177.3.camel@localhost.localdomain> On Mon, 2008-09-15 at 13:09 +0200, Ahmed Kamal wrote: > I'm already pushing DNS .. I don't believe it works on Linux clients > though! It certainly works with NetworkManager and the NM-openvpn plugin. NM will use the returned DNS servers from the openvpn server if you tell it not to ignore them. When the VPN connection goes away or is disconnected, NM will restore your previous DNS servers from the underlying connection on which the VPN was running. Dan > Take a look at the kind of hacks needed: http://www.phocean.net/?p=12 > > On Mon, Sep 15, 2008 at 1:02 PM, Brett Serkez > wrote: > 2008/9/14 Ahmed Kamal : > > > I have an itch. I connect to work using openvpn. Works > great, except that > > openvpn does not modify resolv.conf to add work's dns > servers (now available > > through vpn). It does that on Windows though! I cannot > expect openvpn or > > (any other application) to simply overwrite /etc/resolv.conf > at will, but > > what is fedora missing to get an elegant solution to this > problem ? > > > You should be able to push DHCP options from the OpenVPN > server: > > http://openvpn.net/index.php/documentation/howto.html#dhcp > > push "dhcp-option DNS 10.66.0.4" > push "dhcp-option DNS 10.66.0.5" > > The client OS shouldn't matter, it should be picking up the > DHCP > options when the OpenVPN client brings up the interface when > it comes > up. > > Brett > > > -- > 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 ajax at redhat.com Mon Sep 15 13:35:45 2008 From: ajax at redhat.com (Adam Jackson) Date: Mon, 15 Sep 2008 09:35:45 -0400 Subject: Proposal: Better force-tag In-Reply-To: <48CD3DE7.6040204@redhat.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <48CD1CA3.5060302@redhat.com> <200809141216.39628.sgrubb@redhat.com> <48CD3DE7.6040204@redhat.com> Message-ID: <1221485745.15981.7.camel@atropine.boston.devel.redhat.com> On Sun, 2008-09-14 at 12:37 -0400, Warren Togami wrote: > Steve Grubb wrote: > > On Sunday 14 September 2008 10:16:03 Warren Togami wrote: > >>> Just removing stuff does not solve problems you have to implement a > >>> better alternative first (and not rely on a worse one). > >> Since nothing stops the user from using TAG_OPTS=-F, it is ineffective > >> of us to remove force-tag. How about an improved force-tag instead? > >> > >> Make force-tag use koji to check if a build for that N-V-R is already > >> complete. If it is complete, then refuse to tag again with the same N-V-R. > > > > Yes, this sounds exactly like what should have been done. We should not have > > disabled a feature that many people legitimately use until we had a tested > > solution that does not interrupt the work flow. This is needless arguing with > > no tangible benefits for anyone. I consider the srpm to be the canonical > > source of the build. That is the only granularity people can access via any > > mirror. > > The goal of preventing force-tag is to better guarantee that .src.rpm > comtents match tags. We can achieve this by having force-tag fail if > the buildsystem says that E:N-V-R was either already built or is > currently building. Except, as mentioned elsewhere in the thread, the goal is really "srpm contents are reconstructable". Which is exactly equivalent to saving the Entries file from the CVS checkout as part of the build output. A patch to implement this exists. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pingou at pingoured.fr Mon Sep 15 13:36:17 2008 From: pingou at pingoured.fr (Pierre-Yves) Date: Mon, 15 Sep 2008 15:36:17 +0200 Subject: Source0 from Trac In-Reply-To: <935ead450809150632h26389da6w7878d9b4387f4491@mail.gmail.com> References: <48CE62BF.4030401@pingoured.fr> <935ead450809150632h26389da6w7878d9b4387f4491@mail.gmail.com> Message-ID: <48CE64D1.8070304@pingoured.fr> Jeffrey Ollie wrote: > On Mon, Sep 15, 2008 at 8:27 AM, Pierre-Yves wrote: >> Is there a way on the Trac of Fedorahosted to get a clean link to a tarball > > See the next-to-last entry in the FedoraHosted FAQ: > > https://fedorahosted.org/web/faq > > If you follow the outlined procedure tarballs will show up here: > > https://fedorahosted.org/releases/r/2/r2spec/ > Sweet :) Thanks a lot Regards, Pierre PS. I have no idea why I am sending mail twice sorry about that From jreznik at redhat.com Mon Sep 15 13:38:06 2008 From: jreznik at redhat.com (Jaroslav Reznik) Date: Mon, 15 Sep 2008 09:38:06 -0400 (EDT) Subject: Source0 from Trac In-Reply-To: <933432669.37841221485660807.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Message-ID: <786796381.40831221485886166.JavaMail.root@zmail02.collab.prod.int.phx2.redhat.com> Hi, I think it's better to use fedorahosted releases storage. You can find it here: https://fedorahosted.org/releases/ In system-config-bind project we have custom Makefile with release target: ---code--- archive: ${NAME}-${VERSION}.tar.gz ${NAME}-${VERSION}.tar.gz: hg archive -t tgz ${NAME}-${VERSION}.tar.gz tag: hg tag ${VERSION} release: archive tag scp ${NAME}-${VERSION}.tar.gz fedorahosted.org:${NAME} ---code--- Version is read directly from current SPEC file. --- Jaroslav Reznik Software Engineer - Base OS Core Services Brno Red Hat, Inc. +420 532 294 275 ----- "Pierre-Yves" wrote: > Dear list, > > I have a small question, while packaging source obtained from a trac > wiki/git the link given on Source0 can be: > 1 - > https://fedorahosted.org/r2spec/export/96ae0f7a737bcda9950ecddc452800804e0c7346/R2spec-2.5.0.tar.gz > or > 2 - > https://fedorahosted.org/r2spec/browser/R2spec-2.5.0.tar.gz?format=raw > > But: > 1- the link is quite ugly and will need to be changed for every > release > 2- the link usable via wget but provide a file named > R2spec-2.5.0.tar.gz?format=raw which is not exactly what we are > looking > for... > > I was thus wondering: > Is there a way on the Trac of Fedorahosted to get a clean link to a > tarball ? > If not what would be the best way to write Source0 on the spec file ? > I tought https://fedorahosted.org/r2spec/browser/R2spec-2.5.0.tar.gz > would be fine with an additional comments but I'm not sure this is > correct. > > Any input ? :) > > Thanks, > > Pierre > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From denis at poolshark.org Mon Sep 15 13:39:53 2008 From: denis at poolshark.org (Denis Leroy) Date: Mon, 15 Sep 2008 15:39:53 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> Message-ID: <48CE65A9.8040401@poolshark.org> Nicolas Mailhot wrote: > Simply put, non-X-console input is a mess (X input is a mess too but > at least there are people trying to fix it), non-X-console font > support has fossilized, and support for modern high resolution screens > is severely lacking. > > The console has not evolved for a long time, while text requirements > have gone up. At this point a dumbed down text-only X session is > probably the only credible console future (or something that is not X > at all but uses many libraries we associate with apps now). > > Non-X-console state is so bad nowadays I don't bother reporting bugs > on it. Even if they are fixed they always reappear the next Fedora > cycle. Well, people can log in, and people can run commands. As long as that works, where's the problem ? I understand support for foreign characters is going to be a problem, but how does that justify removing the entire thing ? > There is simply not enough console users [cut] to do anything but > life support anymore. On what facts do you base that opinion ? I occasionally run into a Gnome app bug where drag'n'drop "hangs" the desktop (the "drag" never "drops", sort of) where the only way out is ctrl-alt-f1 to mingetty and killall the user-space app. Without mingetty, ctrl-alt-del is the only other option (i.e. loose all unsaved documents). From ajax at redhat.com Mon Sep 15 13:40:09 2008 From: ajax at redhat.com (Adam Jackson) Date: Mon, 15 Sep 2008 09:40:09 -0400 Subject: Source0 from Trac In-Reply-To: <48CE62BF.4030401@pingoured.fr> References: <48CE62BF.4030401@pingoured.fr> Message-ID: <1221486009.15981.9.camel@atropine.boston.devel.redhat.com> On Mon, 2008-09-15 at 15:27 +0200, Pierre-Yves wrote: > Dear list, > > I have a small question, while packaging source obtained from a trac > wiki/git the link given on Source0 can be: > 1 - > https://fedorahosted.org/r2spec/export/96ae0f7a737bcda9950ecddc452800804e0c7346/R2spec-2.5.0.tar.gz > or > 2 - https://fedorahosted.org/r2spec/browser/R2spec-2.5.0.tar.gz?format=raw > > But: > 1- the link is quite ugly and will need to be changed for every release > 2- the link usable via wget but provide a file named > R2spec-2.5.0.tar.gz?format=raw which is not exactly what we are looking > for... > > I was thus wondering: > Is there a way on the Trac of Fedorahosted to get a clean link to a > tarball ? > If not what would be the best way to write Source0 on the spec file ? > I tought https://fedorahosted.org/r2spec/browser/R2spec-2.5.0.tar.gz > would be fine with an additional comments but I'm not sure this is correct. I was going to suggest: https://fedorahosted.org/releases/r/2/r2spec/R2Spec-2.5.0.tar.gz since a similarly formatted URL is what I use for rhpxl. But that link doesn't work, and I don't know why. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jeff at ocjtech.us Mon Sep 15 13:42:19 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Mon, 15 Sep 2008 08:42:19 -0500 Subject: Source0 from Trac In-Reply-To: <1221486009.15981.9.camel@atropine.boston.devel.redhat.com> References: <48CE62BF.4030401@pingoured.fr> <1221486009.15981.9.camel@atropine.boston.devel.redhat.com> Message-ID: <935ead450809150642p3f41f81em952a1240094499b6@mail.gmail.com> 2008/9/15 Adam Jackson : > > I was going to suggest: > > https://fedorahosted.org/releases/r/2/r2spec/R2Spec-2.5.0.tar.gz > > since a similarly formatted URL is what I use for rhpxl. But that link > doesn't work, and I don't know why. Because you have to upload it first. Attachments created in Trac don't go into the releases space automatically. -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" From walters at verbum.org Mon Sep 15 13:43:05 2008 From: walters at verbum.org (Colin Walters) Date: Mon, 15 Sep 2008 09:43:05 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <48CE65A9.8040401@poolshark.org> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> Message-ID: On Mon, Sep 15, 2008 at 9:39 AM, Denis Leroy wrote: > > I occasionally run into a Gnome app bug where drag'n'drop "hangs" the > desktop (the "drag" never "drops", sort of) where the only way out is > ctrl-alt-f1 to mingetty and killall the user-space app. Without mingetty, > ctrl-alt-del is the only other option (i.e. loose all unsaved documents). We should make Ctrl-Alt-Backspace just break server grabs instead of killing the server (and of course fix the bugs in the apps that hang while holding a server grab). From notting at redhat.com Mon Sep 15 13:48:55 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 15 Sep 2008 09:48:55 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> Message-ID: <20080915134855.GB10826@nostromo.devel.redhat.com> Colin Walters (walters at verbum.org) said: > > I occasionally run into a Gnome app bug where drag'n'drop "hangs" the > > desktop (the "drag" never "drops", sort of) where the only way out is > > ctrl-alt-f1 to mingetty and killall the user-space app. Without mingetty, > > ctrl-alt-del is the only other option (i.e. loose all unsaved documents). > > We should make Ctrl-Alt-Backspace just break server grabs instead of > killing the server (and of course fix the bugs in the apps that hang > while holding a server grab). Wait, that redefines the standard logout keyboard shortcut! Bill From kvantanet at seznam.cz Mon Sep 15 13:50:07 2008 From: kvantanet at seznam.cz (kvantanet at seznam.cz) Date: Mon, 15 Sep 2008 15:50:07 +0200 (CEST) Subject: Version of Postfix in Fedora not kept up to date Message-ID: <11.14-31640-1558071764-1221486607@seznam.cz> Hi Everyone, Why is always Postfix a couple of versions behind? The latest version of Postfix is now 2.5.5 and F10 includes only 2.5.1. (Released 2008-02-17) Other distros like Debian always updates this package. Fedora never updates this package after release. Does this mean the we don't need to address the issues corrected in new versions of Postfix? E.G. Latest 2 issues ---------------------------------------- SNIP ----------------------------------------------- 20080814 Security: some systems have changed their link() semantics, and will hardlink a symlink, contrary to POSIX and XPG4. Sebastian Krahmer, SuSE. File: util/safe_open.c. The solution introduces the following incompatible change: when the target of mail delivery is a symlink, the parent directory of that symlink must now be writable by root only (in addition to the already existing requirement that the symlink itself is owned by root). This change will break legitimate configurations that deliver mail to a symbolic link in a directory with less restrictive permissions. 20080826 Bugfix (introduced Postfix 2.4): epoll file descriptor leak. With Postfix >= 2.4 on Linux >= 2.6, Postfix has an epoll file descriptor leak when it executes non-Postfix commands in, for example, user-controlled $HOME/.forward files. A local user can access a leaked epoll file descriptor to implement a denial of service attack on Postfix. Data confidentiality and integrity are not affected. File: util/events.c. ---------------------------------------- /SNIP ----------------------------------------------- More at : ftp://ftp.porcupine.org/mirrors/postfix-release/official/postfix-2.5.5.HISTORY Best Tomas Lanik From kvantanet at seznam.cz Mon Sep 15 13:50:07 2008 From: kvantanet at seznam.cz (kvantanet at seznam.cz) Date: Mon, 15 Sep 2008 15:50:07 +0200 (CEST) Subject: Version of Postfix in Fedora not kept up to date Message-ID: <11.14-31640-1558071764-1221486607@seznam.cz> Hi Everyone, Why is always Postfix a couple of versions behind? The latest version of Postfix is now 2.5.5 and F10 includes only 2.5.1. (Released 2008-02-17) Other distros like Debian always updates this package. Fedora never updates this package after release. Does this mean the we don't need to address the issues corrected in new versions of Postfix? E.G. Latest 2 issues ---------------------------------------- SNIP ----------------------------------------------- 20080814 Security: some systems have changed their link() semantics, and will hardlink a symlink, contrary to POSIX and XPG4. Sebastian Krahmer, SuSE. File: util/safe_open.c. The solution introduces the following incompatible change: when the target of mail delivery is a symlink, the parent directory of that symlink must now be writable by root only (in addition to the already existing requirement that the symlink itself is owned by root). This change will break legitimate configurations that deliver mail to a symbolic link in a directory with less restrictive permissions. 20080826 Bugfix (introduced Postfix 2.4): epoll file descriptor leak. With Postfix >= 2.4 on Linux >= 2.6, Postfix has an epoll file descriptor leak when it executes non-Postfix commands in, for example, user-controlled $HOME/.forward files. A local user can access a leaked epoll file descriptor to implement a denial of service attack on Postfix. Data confidentiality and integrity are not affected. File: util/events.c. ---------------------------------------- /SNIP ----------------------------------------------- More at : ftp://ftp.porcupine.org/mirrors/postfix-release/official/postfix-2.5.5.HISTORY Best Tomas Lanik From dominik at greysector.net Mon Sep 15 14:07:03 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 15 Sep 2008 16:07:03 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> Message-ID: <20080915140703.GI20342@mokona.greysector.net> On Monday, 15 September 2008 at 14:26, Nicolas Mailhot wrote: > > > Le Lun 15 septembre 2008 14:04, Dominik 'Rathann' Mierzejewski a ?crit : > > > > On Monday, 15 September 2008 at 13:39, Nicolas Mailhot wrote: > >> > > >> The console has not evolved for a long time, while text requirements > >> have gone up. At this point a dumbed down text-only X session is > >> probably the only credible console future (or something that is not > >> X > >> at all but uses many libraries we associate with apps now). > > > > Irrelevant. I'm not saying the text mode console has to have the > > same usability as a full-screen terminal emulator running on X. > > That may be irrelevant for you but that's not irrelevant for me both > as a console user and as someone who is an upstream maintainer for my > language of some of the bits the console use. Read the second sentence again. > The separation between the X text stack and the console text stack is > not worth the maintenance burden. As evidenced by the fact the > maintenance part of the console text stack (even as > iso-functionnality) is not done properly anymore. Please point to the evidenced fact. > >> Non-X-console state is so bad nowadays I don't bother reporting bugs > >> on it. Even if they are fixed they always reappear the next Fedora > >> cycle. There is simply not enough console users and console > >> developpers to do anything but life support anymore. > > > > I don't know of any bugs that prevent me or my colleagues from using > > the text mode console. > > Lucky you. > > > That's not to say they don't exist, but I've > > never heard of any problems with the console either personally or from > > my colleagues. > > So it works for you. > OSS works for some people too. Do you mean Open Source Software or Open Sound System? In case of OSS, it's realy a shame, because it was (and still is) a great piece of software with nice API and doesn't require any external libraries like ALSA. But you can't compare console/X to OSS/ALSA. The latter provide functionality on the same level, the former are completely different. > >> And that's ok. Do remember that X was defined at a time hardware was > >> vastly less powerful and core X is not wasteful at all. Compared to > >> how the rest of the system has bloated, X is definitely lean and > >> mean. > > > > That doesn't mean you have to disable the text mode console. > > Do you volunteer for maintening all the stuff text mode console relies > on (fonts, layout definitions, etc)? Please point me to what needs maintaining and I'll see if I can get one of my colleagues to handle that. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From rc040203 at freenet.de Mon Sep 15 14:09:03 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 15 Sep 2008 16:09:03 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <48CE65A9.8040401@poolshark.org> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> Message-ID: <1221487743.18327.612.camel@beck.corsepiu.local> On Mon, 2008-09-15 at 15:39 +0200, Denis Leroy wrote: > Nicolas Mailhot wrote: > > There is simply not enough console users [cut] to do anything but > > life support anymore. > > On what facts do you base that opinion ? Probably, because most console users already quit using Fedora, because already has been turned into a single user desktop OS? This is at least what I will certainly do should this plan become true. /me ducks and hides From buc at odusz.so-cdu.ru Mon Sep 15 14:26:40 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 15 Sep 2008 18:26:40 +0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> Message-ID: <48CE70A0.1070308@odu.neva.ru> Nicolas Mailhot wrote: > Simply put, non-X-console input is a mess (X input is a mess too but > at least there are people trying to fix it), non-X-console font > support has fossilized, and support for modern high resolution screens > is severely lacking. > Me and some people around me use console often enough. Perhaps just by habits. Including a habit to "a bigger letter", "less colors", "still old monitors", "still wild country" etc. There is only one big font issue for me, introduced since RHL8 -- switch to 512-glyphs default console font (latarcyrheb). Such a font (when > 256 glyphs) leads to lack of some console colors. (The solution is to use another console fonts, which are always present in system). > The console has not evolved for a long time, Perhaps all the efforts was focused on GUI (to reach windoze etc.), but this does not mean that console (as well as "classical" cmdline interface) is an unneeded thing to be supported in a general purpose distro... > Non-X-console state is so bad nowadays I don't bother reporting bugs > on it. Sad. > There is simply not enough console users and console > developpers to do anything but life support anymore. > At least 50% of my time is at console, not at X. I would not wish to explain why I (still) use console and why, using it, I am not an idiot. But I use it, hence I can help... IMHO, the "not enough console users" is true for the current Fedora environment, but not true *in general*. Considering (simplifying) Fedora as RedHat employees (focused on GUI for market reasons) plus young enthusiasts (who started their life from GUI), we see why we lack console for now. ~buc http://www.fedoraproject.org/wiki/DmitryButskoy From andrewparker at bigfoot.com Mon Sep 15 14:33:38 2008 From: andrewparker at bigfoot.com (Andrew Parker) Date: Mon, 15 Sep 2008 10:33:38 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> Message-ID: <6c3f5e6c0809150733x1a715ca8yf4f24140143ad8b7@mail.gmail.com> On Mon, Sep 15, 2008 at 9:43 AM, Colin Walters wrote: > On Mon, Sep 15, 2008 at 9:39 AM, Denis Leroy wrote: >> >> I occasionally run into a Gnome app bug where drag'n'drop "hangs" the >> desktop (the "drag" never "drops", sort of) where the only way out is >> ctrl-alt-f1 to mingetty and killall the user-space app. Without mingetty, >> ctrl-alt-del is the only other option (i.e. loose all unsaved documents). > > We should make Ctrl-Alt-Backspace just break server grabs instead of > killing the server (and of course fix the bugs in the apps that hang > while holding a server grab). ok, so remove all the consoles when all the bugs have been fixed and no new bugs are going to be written. From nicolas.mailhot at laposte.net Mon Sep 15 14:33:50 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 15 Sep 2008 16:33:50 +0200 (CEST) Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080915140703.GI20342@mokona.greysector.net> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> Message-ID: <63968c86c9a5b24e9c2dd38dd26794e5.squirrel@rousalka.dyndns.org> Le Lun 15 septembre 2008 16:07, Dominik 'Rathann' Mierzejewski a ?crit : > > On Monday, 15 September 2008 at 14:26, Nicolas Mailhot wrote: >> >> >> Le Lun 15 septembre 2008 14:04, Dominik 'Rathann' Mierzejewski a >> ?crit : >> > That doesn't mean you have to disable the text mode console. >> >> Do you volunteer for maintening all the stuff text mode console >> relies >> on (fonts, layout definitions, etc)? > > Please point me to what needs maintaining and I'll see if I can get > one of my colleagues to handle that. The whole console layout database needs to be re-synched with the xorg one (People have stopped submitting patches to kbd every time they fix an xkeyboard-config bug. After several years of such the disconnect is getting huge). The whole console font set needs to be dumped and the console taught to use generic truetype/opentype fonts (likewise, bugs are fixed in modern fonts but not legacy console fonts, plus legacy fonts are limited to 256 glyphs so each time someone gets to add a glyph for a language he breaks another one. A year ago I've asked volunteers to look at console fonts. So far no one answered). For some reason switching to the console displays an @ nowadays login does not work as a result right now. Can't login, broken display and buggy keyboard layouts. I don't see how the situation could be worse (but I'm sure next month rawhide will show me). -- Nicolas Mailhot From andrewparker at bigfoot.com Mon Sep 15 14:38:03 2008 From: andrewparker at bigfoot.com (Andrew Parker) Date: Mon, 15 Sep 2008 10:38:03 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> References: <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> Message-ID: <6c3f5e6c0809150738x2773d562t1fddad4400f36716@mail.gmail.com> On Mon, Sep 15, 2008 at 8:26 AM, Nicolas Mailhot wrote: >> >> I don't know of any bugs that prevent me or my colleagues from using >> the text mode console. > > Lucky you. > So because it doesn't work for you its not allowed to work for me? From nicolas.mailhot at laposte.net Mon Sep 15 14:40:46 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 15 Sep 2008 16:40:46 +0200 (CEST) Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <48CE70A0.1070308@odu.neva.ru> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE70A0.1070308@odu.neva.ru> Message-ID: <29aeedb35e6f63c10690146acfb0aff5.squirrel@rousalka.dyndns.org> Le Lun 15 septembre 2008 16:26, Dmitry Butskoy a ?crit : > > Nicolas Mailhot wrote: >> There is simply not enough console users and console >> developpers to do anything but life support anymore. >> > > At least 50% of my time is at console, not at X. I would not wish to > explain why I (still) use console and why, using it, I am not an > idiot. I spend much of my time on the console... the X terminal+ssh one. The non-X terminal one is a waste of my time. Please do not take anything I wrote as an attack on the CLI usefulness. It isn't. I'm complaining of the state of the console software stack, not on the CLI in general. > But I use it, hence I can help... > > IMHO, the "not enough console users" is true for the current Fedora > environment, but not true *in general*. The problem is that the population that runs Fedora is highly more susceptible to fix problems that the population that does not run Fedora (and tends to wait for someone else to do the work). The non-Fedora population is the one that was happy with OSS and did nothing with it (and as a result it got dumped for alsa by the people who were doing the work). -- Nicolas Mailhot From buc at odusz.so-cdu.ru Mon Sep 15 14:41:10 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 15 Sep 2008 18:41:10 +0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1221487743.18327.612.camel@beck.corsepiu.local> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> Message-ID: <48CE7406.1010409@odu.neva.ru> Ralf Corsepius wrote: > On Mon, 2008-09-15 at 15:39 +0200, Denis Leroy wrote: > >> Nicolas Mailhot wrote: >> > > >> > There is simply not enough console users [cut] to do anything but >> > life support anymore. >> >> On what facts do you base that opinion ? >> > > Probably, because most console users already quit using Fedora, > +1. And situation is worse than simply loss of a rare segment of the market. Who are "console users"? Most cases they are users who began for a long time ago (when GUI was either poor or unavailable). Lacking such "long time ago" users, we lack all their skills, knowledge, intuition. And as begun for a long time, many of them have already made their career, and even make decisions now. Decisions not for Fedora. Anyway, while Fedora is (still) considered as "general purpose disto", it should has console. ~buc http://www.fedoraproject.org/wiki/DmitryButskoy From nicolas.mailhot at laposte.net Mon Sep 15 14:42:00 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 15 Sep 2008 16:42:00 +0200 (CEST) Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <6c3f5e6c0809150738x2773d562t1fddad4400f36716@mail.gmail.com> References: <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <6c3f5e6c0809150738x2773d562t1fddad4400f36716@mail.gmail.com> Message-ID: <26905daf4f281992e0071f0788542863.squirrel@rousalka.dyndns.org> Le Lun 15 septembre 2008 16:38, Andrew Parker a ?crit : > > On Mon, Sep 15, 2008 at 8:26 AM, Nicolas Mailhot > wrote: >>> >>> I don't know of any bugs that prevent me or my colleagues from >>> using >>> the text mode console. >> >> Lucky you. >> > > So because it doesn't work for you its not allowed to work for me? Just because it works for you does not mean it's healthy in general. -- Nicolas Mailhot From mfleming at enlartenment.com Mon Sep 15 14:41:27 2008 From: mfleming at enlartenment.com (Michael Fleming) Date: Tue, 16 Sep 2008 00:41:27 +1000 Subject: Version of Postfix in Fedora not kept up to date In-Reply-To: <11.14-31640-1558071764-1221486607@seznam.cz> References: <11.14-31640-1558071764-1221486607@seznam.cz> Message-ID: <48CE7417.70903@enlartenment.com> kvantanet at seznam.cz wrote: > Hi Everyone, > > Why is always Postfix a couple of versions behind? > The latest version of Postfix is now 2.5.5 and F10 includes only 2.5.1. (Released 2008-02-17) > Other distros like Debian always updates this package. Fedora never updates this package after release. > Does this mean the we don't need to address the issues corrected in new versions of Postfix? Have you logged an RFE in bugzilla against postfix for this? It's the most effective way of getting the attention of the appropriate maintainers. It does tend to get updated infrequently, but Postfix's stable branch doesn't see a lot of releases :) Michael (Postfix user, mostly rolling my own packages for it though :-)) From nicolas.mailhot at laposte.net Mon Sep 15 14:22:08 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 15 Sep 2008 16:22:08 +0200 (CEST) Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <48CE65A9.8040401@poolshark.org> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> Message-ID: <9f1e9c7bbba727ef318c1b7270680d7f.squirrel@rousalka.dyndns.org> Le Lun 15 septembre 2008 15:39, Denis Leroy a ?crit : > > Nicolas Mailhot wrote: > > Simply put, non-X-console input is a mess (X input is a mess too > but >> at least there are people trying to fix it), non-X-console font >> support has fossilized, and support for modern high resolution >> screens >> is severely lacking. >> >> The console has not evolved for a long time, while text requirements >> have gone up. At this point a dumbed down text-only X session is >> probably the only credible console future (or something that is not >> X >> at all but uses many libraries we associate with apps now). >> >> Non-X-console state is so bad nowadays I don't bother reporting bugs >> on it. Even if they are fixed they always reappear the next Fedora >> cycle. > > Well, people can log in, and people can run commands. As long as that > works, where's the problem ? I understand support for foreign > characters > is going to be a problem, but how does that justify removing the > entire thing ? Keeping this stuff alive is not free you know. Displaying boot messages properly or doing a VT switch does not work completely on my rawhide box right now. And no one decided to break it. It just rotted away. > > There is simply not enough console users [cut] to do anything but > > life support anymore. > > On what facts do you base that opinion ? On my experience of xkb layout maintainer for my language, kbd maintainer for my language, main animator of the Fedora fonts SIG, regular console user, etc. Text support is hard. Text support requires ongoing maintenance (even at iso-functionnality). Our GUI environment has gotten good enough people that used to do console maintenance have less and less incentive to do so, and as a result the console is slowly rotting (ascii-only text + qwerty is easier and not exhibiting a lot of rot so far, but that's only a question of time). Even hardcore kernel devs will tell you to just use and xterm instead of bothering with console problems nowadays. The situation won't get better untill a lot more of the software stack is shared between Xorg and the console. -- Nicolas Mailhot From dominik at greysector.net Mon Sep 15 14:50:41 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 15 Sep 2008 16:50:41 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <26905daf4f281992e0071f0788542863.squirrel@rousalka.dyndns.org> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <6c3f5e6c0809150738x2773d562t1fddad4400f36716@mail.gmail.com> <26905daf4f281992e0071f0788542863.squirrel@rousalka.dyndns.org> Message-ID: <20080915145041.GJ20342@mokona.greysector.net> On Monday, 15 September 2008 at 16:42, Nicolas Mailhot wrote: > > > Le Lun 15 septembre 2008 16:38, Andrew Parker a ?crit : > > > > On Mon, Sep 15, 2008 at 8:26 AM, Nicolas Mailhot > > wrote: > >>> > >>> I don't know of any bugs that prevent me or my colleagues from > >>> using > >>> the text mode console. > >> > >> Lucky you. > >> > > > > So because it doesn't work for you its not allowed to work for me? > > Just because it works for you does not mean it's healthy in general. Just because it doesn't work for you does not mean it must be removed. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From buc at odusz.so-cdu.ru Mon Sep 15 14:53:54 2008 From: buc at odusz.so-cdu.ru (Dmitry Butskoy) Date: Mon, 15 Sep 2008 18:53:54 +0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <63968c86c9a5b24e9c2dd38dd26794e5.squirrel@rousalka.dyndns.org> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <63968c86c9a5b24e9c2dd38dd26794e5.squirrel@rousalka.dyndns.org> Message-ID: <48CE7702.5090908@odu.neva.ru> Nicolas Mailhot wrote: >> Please point me to what needs maintaining and I'll see if I can get >> one of my colleagues to handle that. >> > > The whole console layout database needs to be re-synched with the xorg > one (People have stopped submitting patches to kbd every time they fix > an xkeyboard-config bug. We mix two different concepts here -- "console" and "serial tty". Linux console is more richly -- color support, different size, mouse support, screen history etc. -- but IMHO it is just an enhancement for the "simply serial-like tty". If people actually want "just a tty" (plus some additional convenience unlike in "dumb" tty), then the re-sync of databases with X etc. seems not needed. > The whole console font set needs to be dumped and the console taught > to use generic truetype/opentype fonts For me, just one font for more than 10 years... As if it is a dumb tty. Noone will work on console "as under X" -- it has another target. > Can't login, broken display and buggy keyboard layouts. I don't see > how the situation could be worse Well, just do not use console! But do not deprecate it for me (it works for me now properly). ~buc http://www.fedoraproject.org/wiki/DmitryButskoy From nicolas.mailhot at laposte.net Mon Sep 15 14:55:52 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 15 Sep 2008 16:55:52 +0200 (CEST) Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080915145041.GJ20342@mokona.greysector.net> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <6c3f5e6c0809150738x2773d562t1fddad4400f36716@mail.gmail.com> <26905daf4f281992e0071f0788542863.squirrel@rousalka.dyndns.org> <20080915145041.GJ20342@mokona.greysector.net> Message-ID: Le Lun 15 septembre 2008 16:50, Dominik 'Rathann' Mierzejewski a ?crit : > > On Monday, 15 September 2008 at 16:42, Nicolas Mailhot wrote: >> >> >> Le Lun 15 septembre 2008 16:38, Andrew Parker a ?crit : >> > >> > On Mon, Sep 15, 2008 at 8:26 AM, Nicolas Mailhot >> > wrote: >> >>> >> >>> I don't know of any bugs that prevent me or my colleagues from >> >>> using >> >>> the text mode console. >> >> >> >> Lucky you. >> >> >> > >> > So because it doesn't work for you its not allowed to work for me? >> >> Just because it works for you does not mean it's healthy in general. > > Just because it doesn't work for you does not mean it must be removed. Since it's rotting it does not matter if it's explicitely removed or not. The functionality is effectively going away through lack of maintenance. -- Nicolas Mailhot From rc040203 at freenet.de Mon Sep 15 14:59:35 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 15 Sep 2008 16:59:35 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <48CE7406.1010409@odu.neva.ru> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> Message-ID: <1221490775.18327.626.camel@beck.corsepiu.local> On Mon, 2008-09-15 at 18:41 +0400, Dmitry Butskoy wrote: > Ralf Corsepius wrote: > > On Mon, 2008-09-15 at 15:39 +0200, Denis Leroy wrote: > > > >> Nicolas Mailhot wrote: > >> > > > > > >> > There is simply not enough console users [cut] to do anything but > >> > life support anymore. > >> > >> On what facts do you base that opinion ? > >> > > > > Probably, because most console users already quit using Fedora, > > > > +1. > > And situation is worse than simply loss of a rare segment of the market. > > Who are "console users"? Most cases they are users who began for a long > time ago (when GUI was either poor or unavailable). Yep, this is likely one group (BTW: There are still situations, where Fedora's GUI is either poor or unavailable). It's likely the same group which is booting into "runlevel 3". Other groups/use-cases, I see: - Situations of emergency (Broken X-server, memory hogging-desktop desktop apps etc.) - Debugging. - Machines without GUI installed. Probably the latter is hard to imagine to the folks who came up this proposal. Yes, folks, there are machines which are being used without a GUI! > Anyway, while Fedora is (still) considered as "general purpose disto", > it should has console. I regret having to state this, but I have been thinking Fedora has quit being a "general purpose distro" for quite a while. Ralf From nicolas.mailhot at laposte.net Mon Sep 15 15:01:25 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 15 Sep 2008 17:01:25 +0200 (CEST) Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <48CE7702.5090908@odu.neva.ru> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <63968c86c9a5b24e9c2dd38dd26794e5.squirrel@rousalka.dyndns.org> <48CE7702.5090908@odu.neva.ru> Message-ID: <39672ab9e4eed69aaf30ab34617ccc10.squirrel@rousalka.dyndns.org> Le Lun 15 septembre 2008 16:53, Dmitry Butskoy a ?crit : > > Nicolas Mailhot wrote: >>> Please point me to what needs maintaining and I'll see if I can get >>> one of my colleagues to handle that. > [...] seems not needed. > [...] But do not deprecate it for me Well if no one wants to stand for the console or feels concerned with its problems I'll certainly push for it to be marked as unmaintained junkware. -- Nicolas Mailhot From dominik at greysector.net Mon Sep 15 15:07:04 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 15 Sep 2008 17:07:04 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <6c3f5e6c0809150738x2773d562t1fddad4400f36716@mail.gmail.com> <26905daf4f281992e0071f0788542863.squirrel@rousalka.dyndns.org> <20080915145041.GJ20342@mokona.greysector.net> Message-ID: <20080915150704.GB23250@mokona.greysector.net> On Monday, 15 September 2008 at 16:55, Nicolas Mailhot wrote: > > > Le Lun 15 septembre 2008 16:50, Dominik 'Rathann' Mierzejewski a ?crit : > > > > On Monday, 15 September 2008 at 16:42, Nicolas Mailhot wrote: > >> > >> > >> Le Lun 15 septembre 2008 16:38, Andrew Parker a ?crit : > >> > > >> > On Mon, Sep 15, 2008 at 8:26 AM, Nicolas Mailhot > >> > wrote: > >> >>> > >> >>> I don't know of any bugs that prevent me or my colleagues from > >> >>> using > >> >>> the text mode console. > >> >> > >> >> Lucky you. > >> >> > >> > > >> > So because it doesn't work for you its not allowed to work for me? > >> > >> Just because it works for you does not mean it's healthy in general. > > > > Just because it doesn't work for you does not mean it must be removed. > > Since it's rotting it does not matter if it's explicitely removed or > not. The functionality is effectively going away through lack of > maintenance. It does matter, since the removal affects me (and some other people, apparently), while just keeping it means it will continue to work as it does now. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Mon Sep 15 15:09:15 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 15 Sep 2008 17:09:15 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <39672ab9e4eed69aaf30ab34617ccc10.squirrel@rousalka.dyndns.org> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <63968c86c9a5b24e9c2dd38dd26794e5.squirrel@rousalka.dyndns.org> <48CE7702.5090908@odu.neva.ru> <39672ab9e4eed69aaf30ab34617ccc10.squirrel@rousalka.dyndns.org> Message-ID: <20080915150915.GC23250@mokona.greysector.net> On Monday, 15 September 2008 at 17:01, Nicolas Mailhot wrote: > > > Le Lun 15 septembre 2008 16:53, Dmitry Butskoy a ?crit : > > > > Nicolas Mailhot wrote: > >>> Please point me to what needs maintaining and I'll see if I can get > >>> one of my colleagues to handle that. > > > [...] seems not needed. > > > [...] But do not deprecate it for me > > Well if no one wants to stand for the console or feels concerned with > its problems I'll certainly push for it to be marked as unmaintained > junkware. I said I'd ask my colleague. Were you expecting an answer within 5 minutes? And I thought my voice in this thread was clearly concerned enough, so I don't really understand why you're saying nobody feels concerned. Are you trying to ignore the voice of the community, too? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From rc040203 at freenet.de Mon Sep 15 15:17:04 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 15 Sep 2008 17:17:04 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <9f1e9c7bbba727ef318c1b7270680d7f.squirrel@rousalka.dyndns.org> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <9f1e9c7bbba727ef318c1b7270680d7f.squirrel@rousalka.dyndns.org> Message-ID: <1221491824.18327.639.camel@beck.corsepiu.local> On Mon, 2008-09-15 at 16:22 +0200, Nicolas Mailhot wrote: > Text support is hard. Text support requires ongoing maintenance (even > at iso-functionnality). Our GUI environment has gotten good enough > people that used to do console maintenance have less and less > incentive to do so, Rubbish - You are comparing apples and oranges. Using consoles has completely different use-cases than desktops. This thought might be incomprehensible news to kids who grew up with Windows, but ... > and as a result the console is slowly rotting > (ascii-only text + qwerty is easier and not exhibiting a lot of rot so > far, but that's only a question of time). Even hardcore kernel devs > will tell you to just use and xterm instead of bothering with console > problems nowadays. Of cause it's more convenient to use an xterm than a console. But this already had been the case 20 years ago - it doesn't invalidate reasons for using consoles. Ralf From nicolas.mailhot at laposte.net Mon Sep 15 15:19:06 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 15 Sep 2008 17:19:06 +0200 (CEST) Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080915150915.GC23250@mokona.greysector.net> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <63968c86c9a5b24e9c2dd38dd26794e5.squirrel@rousalka.dyndns.org> <48CE7702.5090908@odu.neva.ru> <39672ab9e4eed69aaf30ab34617ccc10.squirrel@rousalka.dyndns.org> <20080915150915.GC23250@mokona.greysector.net> Message-ID: <20e7ffb0eee2d5341701815933096e67.squirrel@rousalka.dyndns.org> Le Lun 15 septembre 2008 17:09, Dominik 'Rathann' Mierzejewski a ?crit : > > On Monday, 15 September 2008 at 17:01, Nicolas Mailhot wrote: >> >> >> Le Lun 15 septembre 2008 16:53, Dmitry Butskoy a ?crit : >> > >> > Nicolas Mailhot wrote: >> >>> Please point me to what needs maintaining and I'll see if I can >> get >> >>> one of my colleagues to handle that. >> >> > [...] seems not needed. >> >> > [...] But do not deprecate it for me >> >> Well if no one wants to stand for the console or feels concerned >> with >> its problems I'll certainly push for it to be marked as unmaintained >> junkware. > > I said I'd ask my colleague. Were you expecting an answer within 5 > minutes? Sorry, I read your message as a no. I guess I'm just too disgusted at the situation and should drop the subject. I don't think I've anything else to add. -- Nicolas Mailhot From jon at floorboard.com Mon Sep 15 15:19:16 2008 From: jon at floorboard.com (Jon Biggar) Date: Mon, 15 Sep 2008 08:19:16 -0700 Subject: The state of resolv.conf In-Reply-To: <48CE1DAA.8090303@city-fan.org> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <48CE1DAA.8090303@city-fan.org> Message-ID: Paul Howarth wrote: > Ahmed Kamal wrote: >> I have an itch. I connect to work using openvpn. Works great, except that >> openvpn does not modify resolv.conf to add work's dns servers (now >> available >> through vpn). It does that on Windows though! I cannot expect openvpn or >> (any other application) to simply overwrite /etc/resolv.conf at will, but >> what is fedora missing to get an elegant solution to this problem ? > > I use a local DNS server that forwards queries (both forward and reverse > lookups for the network I'm connecting to) down the tunnel. So > /etc/resolv.conf always contains just localhost as the nameserver. Does that handle the case well where you've got a laptop and you move from one wireless network to another? How would you get it to recognize the changing DNS servers in that case? -- Jon Biggar jon at biggar.org jon at floorboard.com From rawhide at fedoraproject.org Mon Sep 15 15:25:37 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Mon, 15 Sep 2008 15:25:37 +0000 (UTC) Subject: rawhide report: 20080915 changes Message-ID: <20080915152538.109A91F8258@releng2.fedora.phx.redhat.com> Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Broken deps for i386 ---------------------------------------------------------- em8300-0.17.1-1.fc10.i386 requires /etc/alsa/cards evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.i386 requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so Broken deps for x86_64 ---------------------------------------------------------- em8300-0.17.1-1.fc10.x86_64 requires /etc/alsa/cards evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.x86_64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- em8300-0.17.1-1.fc10.ppc requires /etc/alsa/cards evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.ppc requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so Broken deps for ppc64 ---------------------------------------------------------- ds9-5.2-4.fc10.ppc64 requires tkcon >= 0:2.5 eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 em8300-0.17.1-1.fc10.ppc64 requires /etc/alsa/cards evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave livecd-tools-018-1.fc10.ppc64 requires yaboot mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-Catalyst-Plugin-StackTrace-0.07-4.fc10.noarch requires perl(Devel::StackTrace) perl-Class-ReturnValue-0.55-2.fc9.noarch requires perl(Devel::StackTrace) perl-Exception-Class-1.24-1.fc10.noarch requires perl(Devel::StackTrace) >= 0:1.17 perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.ppc64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) From nicolas.mailhot at laposte.net Mon Sep 15 15:28:30 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 15 Sep 2008 17:28:30 +0200 (CEST) Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1221491824.18327.639.camel@beck.corsepiu.local> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <9f1e9c7bbba727ef318c1b7270680d7f.squirrel@rousalka.dyndns.org> <1221491824.18327.639.camel@beck.corsepiu.local> Message-ID: Le Lun 15 septembre 2008 17:17, Ralf Corsepius a ?crit : > > On Mon, 2008-09-15 at 16:22 +0200, Nicolas Mailhot wrote: > >> Text support is hard. Text support requires ongoing maintenance >> (even >> at iso-functionnality). Our GUI environment has gotten good enough >> people that used to do console maintenance have less and less >> incentive to do so, > Rubbish - You are comparing apples and oranges. > > Using consoles has completely different use-cases than desktops. Ability to use the keyboard properly, to display the system text documents, or use the local screen is the same. I'm not complaining the console is lacking fancy GL acceleration. I'm complaining the console is sucking more and more at text which is sort of the console point. > This > thought might be incomprehensible news to kids who grew up with > Windows, The argument being? > Of cause it's more convenient to use an xterm than a console. But this > already had been the case 20 years ago - it doesn't invalidate reasons > for using consoles. It does if the gap between them continues to grow. -- Nicolas Mailhot From rc040203 at freenet.de Mon Sep 15 15:30:17 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 15 Sep 2008 17:30:17 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <6c3f5e6c0809150738x2773d562t1fddad4400f36716@mail.gmail.com> <26905daf4f281992e0071f0788542863.squirrel@rousalka.dyndns.org> <20080915145041.GJ20342@mokona.greysector.net> Message-ID: <1221492617.18327.651.camel@beck.corsepiu.local> On Mon, 2008-09-15 at 16:55 +0200, Nicolas Mailhot wrote: > > Le Lun 15 septembre 2008 16:50, Dominik 'Rathann' Mierzejewski a ?crit : > > > > On Monday, 15 September 2008 at 16:42, Nicolas Mailhot wrote: > > Just because it doesn't work for you does not mean it must be removed. > > Since it's rotting it does not matter if it's explicitely removed or > not. The functionality is effectively going away through lack of > maintenance. 1. What is rotting, what is broken? 2. Who are you to decide that? From skvidal at fedoraproject.org Mon Sep 15 15:32:32 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 15 Sep 2008 11:32:32 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <26905daf4f281992e0071f0788542863.squirrel@rousalka.dyndns.org> References: <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <6c3f5e6c0809150738x2773d562t1fddad4400f36716@mail.gmail.com> <26905daf4f281992e0071f0788542863.squirrel@rousalka.dyndns.org> Message-ID: <1221492752.25056.27.camel@rosebud> On Mon, 2008-09-15 at 16:42 +0200, Nicolas Mailhot wrote: > > So because it doesn't work for you its not allowed to work for me? > > Just because it works for you does not mean it's healthy in general. > 'healthy in general'? I'd love to see how we determine that criteria. So, yah - let's not play this game, shall we? Here is my question: - does the presence of the text console limit the ability for the X interfaces to work? I think the answer is no. - does the presence of the text console make a considerable impact on the available development time of the poeple working on X? I'd have to see some numbers that say otherwise but the answer still feels like no. let's not go overboard -sv From jdieter at gmail.com Mon Sep 15 15:26:35 2008 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 15 Sep 2008 18:26:35 +0300 Subject: Non responsive maintainer question In-Reply-To: References: Message-ID: <1221492395.7307.1.camel@jdlaptop> On Mon, 2008-09-15 at 13:52 +0100, Simon Andrews wrote: > A bug I reported back in February (#432767) has been sitting for some > time with a couple of reported fixes, but no response from the maintainer. I emailed the maintainer yesterday for this particular bug and got permission to push an update. Hope that helps. Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From law at redhat.com Mon Sep 15 15:41:06 2008 From: law at redhat.com (Jeff Law) Date: Mon, 15 Sep 2008 09:41:06 -0600 Subject: NetworkworkManger and network based filesystem /usr In-Reply-To: <200809150323.m8F3NnVG015326@laptop14.inf.utfsm.cl> References: <48CAAF49.3090105@hhs.nl> <20080912181213.GA3270@nostromo.devel.redhat.com> <48CAB296.80101@redhat.com> <200809150323.m8F3NnVG015326@laptop14.inf.utfsm.cl> Message-ID: <48CE8212.40009@redhat.com> Horst H. von Brand wrote: > Jeff Law wrote: > > [...] > > >> It must die die die. We're far better off making root filesystems >> sharable and readonly. >> > > /etc at the very least is a /intensely/ personal issue for each machine... > We had local / and shared /usr and so on for ages under assorted Unices > here, and then for Linux. True, today disks are much cheaper; but old > habits are long in dying. > union filesystems are the answer for those (very few) items in /etc which are not sharable. Jeff From nicolas.mailhot at laposte.net Mon Sep 15 15:48:18 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 15 Sep 2008 17:48:18 +0200 (CEST) Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1221492752.25056.27.camel@rosebud> References: <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <6c3f5e6c0809150738x2773d562t1fddad4400f36716@mail.gmail.com> <26905daf4f281992e0071f0788542863.squirrel@rousalka.dyndns.org> <1221492752.25056.27.camel@rosebud> Message-ID: <612fb30b4b887182b3356a7a6ff514d8.squirrel@rousalka.dyndns.org> Le Lun 15 septembre 2008 17:32, Seth Vidal a ?crit : > > On Mon, 2008-09-15 at 16:42 +0200, Nicolas Mailhot wrote: >> > So because it doesn't work for you its not allowed to work for me? >> >> Just because it works for you does not mean it's healthy in general. >> > > 'healthy in general'? I'd love to see how we determine that criteria. > > So, yah - let's not play this game, shall we? > > Here is my question: > - does the presence of the text console limit the ability for the X > interfaces to work? I think the answer is no. > - does the presence of the text console make a considerable impact on > the available development time of the poeple working on X? I'd have to > see some numbers that say otherwise but the answer still feels like > no. We have all sorts of packaging rules designed to avoid hitting console limitations and problems. Every few months we have people filling bugs because the presence of two text stacks confuses them and they don't understand why things working in one do not work in the other (and that's the people who do fill bugs. they tend to be from asian countries where people under-report problems). We have spin teams that do not install the default distro font set to make room for stuff like the console, and then ask for help because it broke X text on some locale. So console support is not free for the rest of the distro. And I'd be happy to applaud this cost, if someone actively maintained the console (instead of playing the "touch nothing, if something broke that's the distro fault" game). > let's not go overboard -- Nicolas Mailhot From rnicholsNOSPAM at comcast.net Mon Sep 15 15:52:41 2008 From: rnicholsNOSPAM at comcast.net (Robert Nichols) Date: Mon, 15 Sep 2008 10:52:41 -0500 Subject: The state of resolv.conf In-Reply-To: References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <48CE1DAA.8090303@city-fan.org> Message-ID: Jon Biggar wrote: > Paul Howarth wrote: >> >> I use a local DNS server that forwards queries (both forward and >> reverse lookups for the network I'm connecting to) down the tunnel. So >> /etc/resolv.conf always contains just localhost as the nameserver. > > Does that handle the case well where you've got a laptop and you move > from one wireless network to another? How would you get it to recognize > the changing DNS servers in that case? I handle that with a dhclient-exit-hooks script that modifies named.conf and triggers a named reload whenever dhclient sees a change in the DNS server addresses. It's messy, though, and if SELinux were enabled it would complain mightily about dhclient doing naughty things. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it. From paul at city-fan.org Mon Sep 15 15:54:09 2008 From: paul at city-fan.org (Paul Howarth) Date: Mon, 15 Sep 2008 16:54:09 +0100 Subject: The state of resolv.conf In-Reply-To: References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <48CE1DAA.8090303@city-fan.org> Message-ID: <48CE8521.40002@city-fan.org> Jon Biggar wrote: > Paul Howarth wrote: >> Ahmed Kamal wrote: >>> I have an itch. I connect to work using openvpn. Works great, except >>> that >>> openvpn does not modify resolv.conf to add work's dns servers (now >>> available >>> through vpn). It does that on Windows though! I cannot expect openvpn or >>> (any other application) to simply overwrite /etc/resolv.conf at will, >>> but >>> what is fedora missing to get an elegant solution to this problem ? >> >> I use a local DNS server that forwards queries (both forward and >> reverse lookups for the network I'm connecting to) down the tunnel. So >> /etc/resolv.conf always contains just localhost as the nameserver. > > Does that handle the case well where you've got a laptop and you move > from one wireless network to another? How would you get it to recognize > the changing DNS servers in that case? If you have your local server set up as a caching DNS server, it wouldn't matter, as your local server wouldn't use $PROVIDER's server at all, and would resolve things itself via the root servers (just as the provider's servers would do, though they will have a bigger cache). Paul. From pbrobinson at gmail.com Mon Sep 15 16:07:44 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 15 Sep 2008 17:07:44 +0100 Subject: Interested in Fedora on Smaller Machines? In-Reply-To: <1220024200.13092.7.camel@aglarond.local> References: <1218552790.27760.3.camel@aglarond.local> <5256d0b0808290744x138de8bbs86cf67ca375a01fa@mail.gmail.com> <1220024200.13092.7.camel@aglarond.local> Message-ID: <5256d0b0809150907y54726fd1g948f1180abe8c0d5@mail.gmail.com> >> > Smaller form-factor machines such as the Asus eeePC have gotten a fair >> > bit of the tech press spotlight of late. Have you bought one with the >> > idea of running Fedora on it? Or have you thought about doing so? >> > >> > I'm trying to gauge the interest in starting a SIG with the purpose of >> > making distribution changes to make running on these devices more >> > streamlined and have more work "out of the box". This will involve both >> > the necessary work to just get the hardware working well with Fedora of >> > today as well as possibly a spin that is explicitly targeted at some of >> > the constraints of the hardware down the line[1]. >> > >> > If enough people are interested, I'd like to find a time later this week >> > or next week to have an initial meeting to kind of figure out what >> > bounds we want to tackle things in for the first pass. Hardware that I >> > think definitely falls into the scope would be: netbooks, UMPCs, MIDs, >> > maybe the XO? I've started up a page on the wiki >> > (http://fedoraproject.org/wiki/JeremyKatz/Netbooks) that people can edit >> > and then we can go from there >> >> What is the status of this SIG? I presume there's enough interest, and >> that the hold up is more than likely the infrastructure issues. Is >> there a planned name for the SIG? I would suggest something quite >> general like "Fedora Mini SIG" rather than something that has netbook >> in the name. > > I like "mini" -- it has some nostalgia factor. We can just start > referring to them as mini-computers and watch people's heads explode :-) Yea, my thoughts exactly :-) > And yeah, hold up is the infrastructure issues took a lot of my time and > then I went on vacation and then I've been just catching up with having > been on vacation. Timing looks like it's going to be a bit of a bear > but I'll pick a time that looks like it'll be as good as possible and > send out a mail with that later this afternoon Ping! I some how don't think your time has been any less free between Fedora updates and then the beta, anything that can be done by me to expedite the SIG setup? Peter From walters at verbum.org Mon Sep 15 16:13:20 2008 From: walters at verbum.org (Colin Walters) Date: Mon, 15 Sep 2008 12:13:20 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1221492617.18327.651.camel@beck.corsepiu.local> References: <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <6c3f5e6c0809150738x2773d562t1fddad4400f36716@mail.gmail.com> <26905daf4f281992e0071f0788542863.squirrel@rousalka.dyndns.org> <20080915145041.GJ20342@mokona.greysector.net> <1221492617.18327.651.camel@beck.corsepiu.local> Message-ID: On Mon, Sep 15, 2008 at 11:30 AM, Ralf Corsepius wrote: > On Mon, 2008-09-15 at 16:55 +0200, Nicolas Mailhot wrote: >> >> Le Lun 15 septembre 2008 16:50, Dominik 'Rathann' Mierzejewski a ?crit : >> > >> > On Monday, 15 September 2008 at 16:42, Nicolas Mailhot wrote: > >> > Just because it doesn't work for you does not mean it must be removed. >> >> Since it's rotting it does not matter if it's explicitely removed or >> not. The functionality is effectively going away through lack of >> maintenance. > 1. What is rotting, what is broken? The reason this thread began was that sound/pulseaudio doesn't work on a console. That is -> resolved NOTABUG. From denis at poolshark.org Mon Sep 15 16:16:28 2008 From: denis at poolshark.org (Denis Leroy) Date: Mon, 15 Sep 2008 18:16:28 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> Message-ID: <48CE8A5C.4090902@poolshark.org> Nicolas Mailhot wrote: > And that's ok. Do remember that X was defined at a time hardware was > vastly less powerful and core X is not wasteful at all. Compared to > how the rest of the system has bloated, X is definitely lean and mean. I agree with that point. Does an X-based mingetty replacement actually exists ? Something that's proven to be sufficiently fail-safe (will work even with half-broken X configurations and such?). From dominik at greysector.net Mon Sep 15 16:41:35 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 15 Sep 2008 18:41:35 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <612fb30b4b887182b3356a7a6ff514d8.squirrel@rousalka.dyndns.org> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <6c3f5e6c0809150738x2773d562t1fddad4400f36716@mail.gmail.com> <26905daf4f281992e0071f0788542863.squirrel@rousalka.dyndns.org> <1221492752.25056.27.camel@rosebud> <612fb30b4b887182b3356a7a6ff514d8.squirrel@rousalka.dyndns.org> Message-ID: <20080915164135.GB24088@mokona.greysector.net> On Monday, 15 September 2008 at 17:48, Nicolas Mailhot wrote: > > > Le Lun 15 septembre 2008 17:32, Seth Vidal a ?crit : > > > > On Mon, 2008-09-15 at 16:42 +0200, Nicolas Mailhot wrote: > >> > So because it doesn't work for you its not allowed to work for me? > >> > >> Just because it works for you does not mean it's healthy in general. > >> > > > > 'healthy in general'? I'd love to see how we determine that criteria. > > > > So, yah - let's not play this game, shall we? > > > > Here is my question: > > - does the presence of the text console limit the ability for the X > > interfaces to work? I think the answer is no. > > - does the presence of the text console make a considerable impact on > > the available development time of the poeple working on X? I'd have to > > see some numbers that say otherwise but the answer still feels like > > no. > > We have all sorts of packaging rules designed to avoid hitting console > limitations and problems. > > Every few months we have people filling bugs because the presence of > two text stacks confuses them and they don't understand why things > working in one do not work in the other (and that's the people who do > fill bugs. they tend to be from asian countries where people > under-report problems). Bugzilla links, please. > We have spin teams that do not install the default distro font set to > make room for stuff like the console, and then ask for help because it > broke X text on some locale. Bugzilla/mailing list links, please. > So console support is not free for the rest of the distro. And I'd be > happy to applaud this cost, if someone actively maintained the console > (instead of playing the "touch nothing, if something broke that's the > distro fault" game). These ARE good arguments. Why didn't you use them in the first place instead of hand-waving? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From tcallawa at redhat.com Mon Sep 15 16:59:59 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 15 Sep 2008 12:59:59 -0400 Subject: Non responsive maintainer question In-Reply-To: References: Message-ID: <1221497999.29052.74.camel@localhost.localdomain> On Mon, 2008-09-15 at 13:52 +0100, Simon Andrews wrote: > A bug I reported back in February (#432767) has been sitting for some > time with a couple of reported fixes, but no response from the maintainer. > > I've looked at the non-responsive maintainer policy, but this seems to > only apply in the case where you want to take over the package yourself > - which I don't have the skills to do. > > Is there a procedure for flagging up that a package maintainer seems to > have gone AWOL whilst asking for anyone suitably qualified to take it over? While we're doing that, I've kicked the package up to current to resolve the technical issue. ~scruffy, the janitor From behdad at behdad.org Mon Sep 15 17:02:26 2008 From: behdad at behdad.org (Behdad Esfahbod) Date: Mon, 15 Sep 2008 13:02:26 -0400 Subject: Boot speedup with readahead In-Reply-To: <1221479676.25056.18.camel@rosebud> References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <20080911090752.GC17152@mokona.greysector.net> <1221129185.18327.181.camel@beck.corsepiu.local> <1221457688.6122.23.camel@localhost.localdomain> <48CDFD37.8080702@behdad.org> <1221479676.25056.18.camel@rosebud> Message-ID: <48CE9522.2010308@behdad.org> Seth Vidal wrote: > On Mon, 2008-09-15 at 02:14 -0400, Behdad Esfahbod wrote: >> Callum Lerwick wrote: >>> The diversity of RPM front ends is a sign we're doing things right. >> And the fact that none reliably works... > > Do you think that might reflect on the complexity of problem more than > it reflects the tools? I'm sure it is a very very complex problem. I also hear that a lot of these problems are caused by RPM having to retain a lot of baggage for the name of compatibility. Hence my conclusion. The question is: if one could throw RPM away and design a new one, could one do significantly better? From what I hear I think the answer might be yes. What does it mean to Fedora: we need to kick RPM in the butt to catch up with competition. Lets look back at the problem at hand: we all agree that custom-installed glob-matched post-transaction triggers are useful things. I think I can also say that we agree that it should be in the lowest-level package management system. What has been up to debate so far is whether that lowest-level is RPM, or that RPM is a lost case and yum is considered the lowest-level. The answer to that one does not matter. A few data points that put this discussion in perspective however: - Michael K Johnson, the very first Fedora Project leader, thought he can invent a better RPM, left Red Hat, and built Conary. It does use Python indeed, and it does support glob-matched scripts. - First Mandriva and then SuSE felt they needed to heavily customize RPM and went down that road. I wonder how longer we need to wait to reach for the same conclusion. - Kristian H?gsberg built razor which can solve deps in fraction of a second where yum simply takes way too long. Is anyone in the RPM camp impressed? No. They just don't think it's possible to do with RPM. - RPM already supports %posttrans scripts which are a huge improvement over %post, but when I desperately needed them to refresh fontconfig caches upon upgrade (using %post the old package is still installed when the script is run; ouch!), but was told to not use %posttrans as it's broken and eats babies. I'm not sure if that's accurate, but that was the recommendation I got from very core Fedora developers. This is the kind of limitation RPM imposes right now. Now I understand that using RPM is one of Fedora's biggest assets ("industry standard" blah blah), so I'm not suggesting that we should move to something significantly different. Just to acknowledge that there is a problem here, identify solutions, and fix them. I'd love to be corrected if any of the above statements is wrong. behdad > -sv From jdieter at gmail.com Mon Sep 15 17:29:17 2008 From: jdieter at gmail.com (Jonathan Dieter) Date: Mon, 15 Sep 2008 20:29:17 +0300 Subject: Non responsive maintainer question In-Reply-To: <1221497999.29052.74.camel@localhost.localdomain> References: <1221497999.29052.74.camel@localhost.localdomain> Message-ID: <1221499757.7307.3.camel@jdlaptop> On Mon, 2008-09-15 at 12:59 -0400, Tom "spot" Callaway wrote: > While we're doing that, I've kicked the package up to current to resolve > the technical issue. Thanks Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Mon Sep 15 17:32:36 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 15 Sep 2008 19:32:36 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080915164135.GB24088@mokona.greysector.net> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <6c3f5e6c0809150738x2773d562t1fddad4400f36716@mail.gmail.com> <26905daf4f281992e0071f0788542863.squirrel@rousalka.dyndns.org> <1221492752.25056.27.camel@rosebud> <612fb30b4b887182b3356a7a6ff514d8.squirrel@rousalka.dyndns.org> <20080915164135.GB24088@mokona.greysector.net> Message-ID: <1221499956.5321.16.camel@rousalka.okg> Le lundi 15 septembre 2008 ? 18:41 +0200, Dominik 'Rathann' Mierzejewski a ?crit : > On Monday, 15 September 2008 at 17:48, Nicolas Mailhot wrote: > > > > > > Le Lun 15 septembre 2008 17:32, Seth Vidal a ?crit : > > > > > > On Mon, 2008-09-15 at 16:42 +0200, Nicolas Mailhot wrote: > > >> > So because it doesn't work for you its not allowed to work for me? > > >> > > >> Just because it works for you does not mean it's healthy in general. > > >> > > > > > > 'healthy in general'? I'd love to see how we determine that criteria. > > > > > > So, yah - let's not play this game, shall we? > > > > > > Here is my question: > > > - does the presence of the text console limit the ability for the X > > > interfaces to work? I think the answer is no. > > > - does the presence of the text console make a considerable impact on > > > the available development time of the poeple working on X? I'd have to > > > see some numbers that say otherwise but the answer still feels like > > > no. > > > > We have all sorts of packaging rules designed to avoid hitting console > > limitations and problems. > > > > Every few months we have people filling bugs because the presence of > > two text stacks confuses them and they don't understand why things > > working in one do not work in the other (and that's the people who do > > fill bugs. they tend to be from asian countries where people > > under-report problems). > > Bugzilla links, please. Unfortunately, the last one I remember was so generally worded I can't find a significant keyword to nail it in google > > We have spin teams that do not install the default distro font set to > > make room for stuff like the console, and then ask for help because it > > broke X text on some locale. > > Bugzilla/mailing list links, please. https://fedorahosted.org/spin-kickstarts/browser/fedora-live-xfce.ks?rev=13934a0984417b545411c59fae3ccda8fa34e297 http://www.deadbabylon.de/blog/2007/11/08/create-your-own-localized-version-of-fedora-8-live-kde/ https://bugzilla.redhat.com/show_bug.cgi?id=445291 The first reflex of a spin author is always to drop fonts to "save space" and keeping two different font sets does not help choosing the right ones to drop. Spin space is contended. > > So console support is not free for the rest of the distro. And I'd be > > happy to applaud this cost, if someone actively maintained the console > > (instead of playing the "touch nothing, if something broke that's the > > distro fault" game). > > These ARE good arguments. Why didn't you use them in the first place > instead of hand-waving? I've stated several times I was a layout maintainer in kbd and xkb. (This is easy to check either in google or greping those component credits.) Anyone that follows this list knows I contribute to the fonts SIG. I'd say this is qualification enough to have an opinion on the console state. And if you do not know what that means, please do not talk about handwaving. -- 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 Sep 15 17:38:00 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 15 Sep 2008 19:38:00 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <48CE8A5C.4090902@poolshark.org> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE8A5C.4090902@poolshark.org> Message-ID: <1221500281.5321.22.camel@rousalka.okg> Le lundi 15 septembre 2008 ? 18:16 +0200, Denis Leroy a ?crit : > Nicolas Mailhot wrote: > > And that's ok. Do remember that X was defined at a time hardware was > > vastly less powerful and core X is not wasteful at all. Compared to > > how the rest of the system has bloated, X is definitely lean and mean. > > I agree with that point. Does an X-based mingetty replacement actually > exists ? Something that's proven to be sufficiently fail-safe (will work > even with half-broken X configurations and such?). I suspect that as soon as much of the hardware pocking is moved from xorg to the kernel and X can be run as a normal user "X-based mingetty replacement" will be just running a x term fullscreen in an autoconfigured X instance. Of course one could theorically write a much lighter solution using only freetype (cairo, pango?) and an xkb-config parser -- 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 tcallawa at redhat.com Mon Sep 15 17:55:33 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 15 Sep 2008 13:55:33 -0400 Subject: [Fedora-legal-list] Re: A couple of license-relate questions In-Reply-To: References: <1220726099.16460.3.camel@localhost.localdomain> Message-ID: <1221501333.29052.75.camel@localhost.localdomain> On Sat, 2008-09-06 at 22:59 +0300, Vasile Gaburici wrote: > Interesting outcome. Does that mean I don't have to mention it at if > it's included in a GPLv2 package? Ehh, I would lean on the safe side and list it in the tag. Apologies for the delayed response. ~spot From surenkarapetyan at gmail.com Mon Sep 15 17:57:51 2008 From: surenkarapetyan at gmail.com (Suren Karapetyan) Date: Mon, 15 Sep 2008 22:57:51 +0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <48CE8A5C.4090902@poolshark.org> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE8A5C.4090902@poolshark.org> Message-ID: <48CEA21F.8000605@gmail.com> Denis Leroy wrote: > Nicolas Mailhot wrote: >> And that's ok. Do remember that X was defined at a time hardware was >> vastly less powerful and core X is not wasteful at all. Compared to >> how the rest of the system has bloated, X is definitely lean and mean. > > I agree with that point. Does an X-based mingetty replacement actually > exists ? Something that's proven to be sufficiently fail-safe (will work > even with half-broken X configurations and such?). > This is getting really confusing. There will NEVER be a "X-based mingetty replacement". At least because mingetty is "_MINIMAL_ getty for consoles". Having to run X (and you know... it won't start with less then 256M ram) on every machine with Fedora is a real problem. For example on the desktop I'm writing from (and I'm sure not only here) X is always high in top with both CPU and memory usage, it's the most frequently crashing/freezing part of the system. And I don't think it will ever change. You know, X is doing a really complex job. Input/output devices, resolution changing, 3D acceleration, broken games... They will always cause problems. I don't think it's possible to create fail-safe X. Having this problems on a machine which will never benefit from X, is a rel problem. On the other hand I rarely see mingetty sessions crash. And if mingetty+bash+mc+gpm is more than enough for a system, having a full X stack running on it is overkill (or stupid). There are a lot of people in the community pushing really hard to make Fedora a "Desktop OS", "desktop product". These people must understand that their desktop isn't the only (and I hope not even the most important) place Fedora is supposed to run. I personally run it on a desktop a laptop and 6 servers. I like NetworkManager running on the laptop. It makes switching from network to network very easy, it works perfectly with wireless networks. But NetworkManager enabled by default on a server I install is really confusing. It makes my (professional) life harder. If we continue making power users'/administrators' life harder while we try to be more "user-friendly" (and by user we always think Joe-clueless) we will loose them. And this special kind of users are the most important (correct me if I'm wrong) for Free Software. And I would like to thank You for Your time if You managed to read till here :) From pemboa at gmail.com Mon Sep 15 18:02:15 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 15 Sep 2008 13:02:15 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> Message-ID: <16de708d0809151102p2641edcawcc4881e25bdc594b@mail.gmail.com> On Mon, Sep 15, 2008 at 6:39 AM, Nicolas Mailhot wrote: > > > Le Lun 15 septembre 2008 12:57, Dominik 'Rathann' Mierzejewski a ?crit : >> >> On Monday, 15 September 2008 at 12:35, Nicolas Mailhot wrote: >>> Le Sam 13 septembre 2008 00:59, Arthur Pemberton a ?crit : >>> > I'm confused. Is Fedora really going to remove non X consoles? >>> >>> Mid-term that wouln't be such a bad idea. >> >> One would have to say why it is a good idea in the first place. > > Simply put, non-X-console input is a mess (X input is a mess too but > at least there are people trying to fix it), non-X-console font > support has fossilized, and support for modern high resolution screens > is severely lacking. > > The console has not evolved for a long time, while text requirements > have gone up. At this point a dumbed down text-only X session is > probably the only credible console future (or something that is not X > at all but uses many libraries we associate with apps now). > > Non-X-console state is so bad nowadays I don't bother reporting bugs > on it. Even if they are fixed they always reappear the next Fedora > cycle. There is simply not enough console users and console > developpers to do anything but life support anymore. > > And that's ok. Do remember that X was defined at a time hardware was > vastly less powerful and core X is not wasteful at all. Compared to > how the rest of the system has bloated, X is definitely lean and mean. Leave non X consoles alone. Plain and simple. If you want to make it better fine, if not leave it alone. I don't even think that this is up for debate. -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From skvidal at fedoraproject.org Mon Sep 15 18:04:22 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 15 Sep 2008 14:04:22 -0400 Subject: Boot speedup with readahead In-Reply-To: <48CE9522.2010308@behdad.org> References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <20080911090752.GC17152@mokona.greysector.net> <1221129185.18327.181.camel@beck.corsepiu.local> <1221457688.6122.23.camel@localhost.localdomain> <48CDFD37.8080702@behdad.org> <1221479676.25056.18.camel@rosebud> <48CE9522.2010308@behdad.org> Message-ID: <1221501862.25056.44.camel@rosebud> On Mon, 2008-09-15 at 13:02 -0400, Behdad Esfahbod wrote: > I'm sure it is a very very complex problem. I also hear that a lot of these > problems are caused by RPM having to retain a lot of baggage for the name of > compatibility. Hence my conclusion. have you talked to the rpm maintainers? Also - compatibility is important, not just to people working on longer-term oses like rhel/centos/sled but also to fedora package maintainers - remember a lot of the fedora maintainers also work on epel. > The question is: if one could throw RPM away and design a new one, could one > do significantly better? From what I hear I think the answer might be yes. > What does it mean to Fedora: we need to kick RPM in the butt to catch up with > competition. Have you tracked the changes that have been going on currently or do you consider anything other than 'throwing it all away' not rapid enough movement? I think you underestimate the sheer volume of code that needs to be protected/verified and reimplemented if we were to just 'throw it all away'. > Lets look back at the problem at hand: we all agree that custom-installed > glob-matched post-transaction triggers are useful things. I think I can also > say that we agree that it should be in the lowest-level package management > system. What has been up to debate so far is whether that lowest-level is > RPM, or that RPM is a lost case and yum is considered the lowest-level. The > answer to that one does not matter. A few data points that put this > discussion in perspective however: > > - Michael K Johnson, the very first Fedora Project leader, thought he can > invent a better RPM, left Red Hat, and built Conary. It does use Python > indeed, and it does support glob-matched scripts. The migration path to conary for fedora is measured in years - not to mention breaking track considerably with everything that came before us and the projects forked from us. And, of course, we've just swapped our known bugs for a whole new set of unknown bugs. It'll be fun to come back a year after a migration to conary to find a whole different set of complaints. Hey, Maybe we'll be encouraged to throw it all away, again. That'd be amusing. > > - First Mandriva and then SuSE felt they needed to heavily customize RPM and > went down that road. I wonder how longer we need to wait to reach for the > same conclusion. Mandriva and SuSE are working with rpm.org and collaborating to make rpm better. They did customize things and we're all progressing on a common tree. > > - Kristian H?gsberg built razor which can solve deps in fraction of a second > where yum simply takes way too long. Is anyone in the RPM camp impressed? > No. They just don't think it's possible to do with RPM. Kristian built something which solves some dependencies. Mostly he wrote a mmap'd repometadata format. > - RPM already supports %posttrans scripts which are a huge improvement over > %post, but when I desperately needed them to refresh fontconfig caches upon > upgrade (using %post the old package is still installed when the script is > run; ouch!), but was told to not use %posttrans as it's broken and eats > babies. I'm not sure if that's accurate, but that was the recommendation I > got from very core Fedora developers. This is the kind of limitation RPM > imposes right now. People use posttrans now - the issue is that posttrans scripts often make some intriguing assumptions about what you're running on and how you're being installed. Ditto with pretrans. And posttrans doesn't play nicely with the rpmdb being accessed/modified right now, either. > Now I understand that using RPM is one of Fedora's biggest assets ("industry > standard" blah blah), so I'm not suggesting that we should move to something > significantly different. Just to acknowledge that there is a problem here, > identify solutions, and fix them. Have you interacted, at all, with rpm.org - Panu, Florian, Jindrich about what they're working on? Maybe reviewed the slides from brno's fudcon? I think they're posted somewhere publicly. Checked out the git changelog for rpm.org? Looked at the rpm feature proposals for fedora? Simply put, Fedora-devel is not the best place for learning about rpm development. rpm-maint at lists.rpm.org is a better place. Look at the rpm wiki, too: http://wiki.rpm.org/DevPriorities If you want to talk about rpm issues that need work, or better yet, if you want to work on them - come to the rpm-maint list. I can think of one or two items which I'm sure the rpm devs would love some additional thoughts on. File fingerprinting comes to mind as non-trivial and excruciating all at the same time. And, of course, eminently necessary for putting down files. -sv From dwheeler at dwheeler.com Mon Sep 15 18:06:35 2008 From: dwheeler at dwheeler.com (David A. Wheeler) Date: Mon, 15 Sep 2008 14:06:35 -0400 (EDT) Subject: Non-X text mode console In-Reply-To: <20080915151812.0730561B48E@hormel.redhat.com> References: <20080915151812.0730561B48E@hormel.redhat.com> Message-ID: I routinely use text mode console without X, for a variety of reasons. For example: * I have a number of systems (servers) at runlevel 3 * console is critically important when X fails. "Log in with ssh" doesn't work when ssh or the network fails. * It's often much simpler to quickly log in to do a small task rather than waiting for all the X + desktop startup stuff * I have some systems that have GUIs but not X at all (e.g., use DirectFB directly to the framebuffer)... and I sometimes need a recovery method, just like I do for X I think it's clear from this discussion here that many people DO find non-X console mode useful, and thus, it shouldn't be removed: Dominik 'Rathann' Mierzejewski: > It does matter, since the removal affects me (and some other people, apparently), > while just keeping it means it will continue to work as it does now. The complaints about non-X console mode failing to support "multiple fonts" are irrelevant. I do not WANT text-mode console to support multiple fonts; that would interfere with console mode's advantages (e.g., small size, often works even when X fails). When I want fonts, I'll use X. --- David A. Wheeler From skvidal at fedoraproject.org Mon Sep 15 18:07:38 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 15 Sep 2008 14:07:38 -0400 Subject: Non responsive maintainer question In-Reply-To: <1221497999.29052.74.camel@localhost.localdomain> References: <1221497999.29052.74.camel@localhost.localdomain> Message-ID: <1221502058.25056.48.camel@rosebud> On Mon, 2008-09-15 at 12:59 -0400, Tom "spot" Callaway wrote: > On Mon, 2008-09-15 at 13:52 +0100, Simon Andrews wrote: > > A bug I reported back in February (#432767) has been sitting for some > > time with a couple of reported fixes, but no response from the maintainer. > > > > I've looked at the non-responsive maintainer policy, but this seems to > > only apply in the case where you want to take over the package yourself > > - which I don't have the skills to do. > > > > Is there a procedure for flagging up that a package maintainer seems to > > have gone AWOL whilst asking for anyone suitably qualified to take it over? > > While we're doing that, I've kicked the package up to current to resolve > the technical issue. > > ~scruffy, the janitor I thought the Janitor's name was Frazz[1] -sv 1. http://en.wikipedia.org/wiki/Frazz From dledford at redhat.com Mon Sep 15 18:15:15 2008 From: dledford at redhat.com (Doug Ledford) Date: Mon, 15 Sep 2008 14:15:15 -0400 Subject: Proposal: Better force-tag In-Reply-To: <1221409389.24484.1.camel@truman> References: <1220955240.24928.69.camel@cookie.hadess.net> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> <48CA16D1.5070409@redhat.com> <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> <1221234383.15726.194.camel@localhost.localdomain> <48CD1CA3.5060302@redhat.com> <1221402590.27183.172.camel@ignacio.lan> <48CD3358.8060105@poolshark.org> <1221409389.24484.1.camel@truman> Message-ID: <1221502515.1927.385.camel@firewall.xsintricity.com> On Sun, 2008-09-14 at 12:23 -0400, Brian Pepple wrote: > On Sun, 2008-09-14 at 17:52 +0200, Denis Leroy wrote: > > Ignacio Vazquez-Abrams wrote: > > > Ultimately nothing can stop the user from using cvs tag -F, so any > > > solution (including this one, which I like a lot) would have to be > > > server-side. > > > > That's what they're planning to do, despite many objections. When will > > the FeSCo minutes be available on the wiki ? I would like to know who > > voted for this. > > I'm planning to write up the summary later today, but the IRC logs are > available as soon as the meeting ends. > > http://bpepple.fedorapeople.org/fesco/ So, this is to dgilmore, bpepple, jds2001, and nirik (the 4 people that voted for this action): you have just made it highly likely that you will not ever get my vote to participate as a member of FESCo again (I don't say this as a threat, just to let you know that your actions in this endeavor so directly counter what I want/expect out of FESCo that I don't consider you the right people for the job any more). I don't want you to think that I make this out of some sort of emotional response to the removal though (after all, I've been talking about immutable tags in my various git-repo threads), so let me explain. Of the various reasons discussed for removing the makefile options, it was confirmed that removing the option does not actually stop people from changing tags, it just keeps it from being "easy". It was confirmed that the change does not solve the GPL compliance issue. In this thread, it's been brought up that many, many developers use this capability responsibly day in and day out, while we have had only a handful of irresponsible uses. Given these facts, we can draw the following conclusions: 1) The change does not solve the one actual real problem that needs solved, the GPL compliance issue. 2) The change interrupts many developer's work flow in the name of a non-solution to the one real problem, the GPL compliance issue. 3) The change attempts to sweep the real problem under the rug and does not give any date or time line for a *real* solution to be effected. I hate to say this, but these quotes from the IRC log are really what bother me: notting: it makes it not blatant and easy to do ... dgilmore, mmcgrath mentioned legal issues in the discussion thread as a motivation spoleeba: right, gpl compliance. that's a bit of a red herring bpepple, lets be clear....afaict..this one action doesnt actually solve the problem correct ... spoleeba: We can definitely make all tagging operations immutable. Making just some immutable would need some planning but could be done as well. abadger1999, for a later discussion To dgilmore: Make no mistake about it, this change is 100% pure security by obscurity. It doesn't solve the real problem, and everyone that voted for it acknowledges it doesn't solve the real problem. You're just sweeping it under the rug. I'm actually quite disappointed that anyone in the open source community still thinks this way. To abadger1999: you had the right idea, talk about the *real* solution instead of this non-solution, but you didn't push the issue hard enough. They should have never been allowed to sweep the real problem under the rug without at least having a firm deadline to solve the problem for real, and some would argue that it would even be better to make the problem worse so as to make it unavoidable, that way that couldn't just sweep it under the rug but would have to address it properly. Look guys, maybe what we have here is a case of mis-communication. So, let me communicate what I expect out of FESCo/Fedora. Maybe I'm wrong and my expectations are unreasonable. If so, I'll accept that answer. But what I saw here was what I would expect to see in some proprietary company under a self imposed deadline that cuts corners to get the job done. I don't participate in Fedora for that. I participate in Fedora because it's *supposed* to be the a place where we put quality above expediency and we don't just do things, we do them right. In fact, I care about that so much that it is definitely a valid voting item as far as I'm concerned. I don't see this as being anywhere close to doing things right, this is a sloppy, half-assed attempt to deal with a legitimate problem by not actually dealing with it at all. I won't vote for that, so by extension I won't vote for people that support doing things this way. If I'm in the wrong place, and Fedora is about doing things the expedient way instead of the right way, let me know and I'll let you be. -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From Jochen at herr-schmitt.de Mon Sep 15 18:17:55 2008 From: Jochen at herr-schmitt.de (Jochen Schmitt) Date: Mon, 15 Sep 2008 20:17:55 +0200 Subject: Non-X text mode console In-Reply-To: References: <20080915151812.0730561B48E@hormel.redhat.com> Message-ID: <48CEA6D3.90906@herr-schmitt.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David A. Wheeler schrieb: > I think it's clear from this discussion here that many people DO > find non-X console mode useful, and thus, it shouldn't be removed: > Dominik 'Rathann' Mierzejewski: I agree with you, that a release of Fedora without non-x mode console may be a disadvantage. Blind or low vision people may prefer non-X mode consoles. And I think there are other peoples with such prefernces too. Best Regards: Jochen Schmitt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjOpscACgkQT2AHK6txfgyRrwCfXubOr9Vq6x08Ro+aywzyTRhs +asAn1cOTRgyQO+2KX2TmOt1mT0jjr5M =mO+z -----END PGP SIGNATURE----- From nicolas.mailhot at laposte.net Mon Sep 15 18:19:27 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 15 Sep 2008 20:19:27 +0200 Subject: Non-X text mode console In-Reply-To: References: <20080915151812.0730561B48E@hormel.redhat.com> Message-ID: <1221502767.5321.25.camel@rousalka.okg> Le lundi 15 septembre 2008 ? 14:06 -0400, David A. Wheeler a ?crit : > The complaints about non-X console mode failing to support > "multiple fonts" are irrelevant. There are no such complains. My complain on the contrary is that current console mode demands the use of multiple fonts (and creates many problems in the 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 csnook at redhat.com Mon Sep 15 18:24:08 2008 From: csnook at redhat.com (Chris Snook) Date: Mon, 15 Sep 2008 14:24:08 -0400 Subject: Non-X text mode console In-Reply-To: References: <20080915151812.0730561B48E@hormel.redhat.com> Message-ID: <48CEA848.2050005@redhat.com> David A. Wheeler wrote: > I routinely use text mode console without X, for a > variety of reasons. For example: > * I have a number of systems (servers) at runlevel 3 > * console is critically important when X fails. "Log in with ssh" > doesn't work when ssh or the network fails. > * It's often much simpler to quickly log in to do a small task > rather than waiting for all the X + desktop startup stuff > * I have some systems that have GUIs but not X at all > (e.g., use DirectFB directly to the framebuffer)... and > I sometimes need a recovery method, just like I do for X > > I think it's clear from this discussion here that many people DO > find non-X console mode useful, and thus, it shouldn't be removed: > Dominik 'Rathann' Mierzejewski: >> It does matter, since the removal affects me (and some other people, apparently), >> while just keeping it means it will continue to work as it does now. > > The complaints about non-X console mode failing to support > "multiple fonts" are irrelevant. I do not WANT text-mode > console to support multiple fonts; that would interfere with > console mode's advantages (e.g., small size, often works even when > X fails). When I want fonts, I'll use X. > > --- David A. Wheeler > Unless I've missed something huge, virtual terminals aren't going away. What may or may not be going away is the x86 video BIOS text mode, to be replaced with a kernel framebuffer, which precludes the use of console fonts, which very few people ever mess with. The console itself will remain. Someone please correct me if I'm wrong. -- Chris From dominik at greysector.net Mon Sep 15 18:28:08 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 15 Sep 2008 20:28:08 +0200 Subject: Proposal: Better force-tag In-Reply-To: <1221502515.1927.385.camel@firewall.xsintricity.com> References: <48CA16D1.5070409@redhat.com> <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> <1221234383.15726.194.camel@localhost.localdomain> <48CD1CA3.5060302@redhat.com> <1221402590.27183.172.camel@ignacio.lan> <48CD3358.8060105@poolshark.org> <1221409389.24484.1.camel@truman> <1221502515.1927.385.camel@firewall.xsintricity.com> Message-ID: <20080915182808.GE24088@mokona.greysector.net> On Monday, 15 September 2008 at 20:15, Doug Ledford wrote: > On Sun, 2008-09-14 at 12:23 -0400, Brian Pepple wrote: > > On Sun, 2008-09-14 at 17:52 +0200, Denis Leroy wrote: > > > Ignacio Vazquez-Abrams wrote: > > > > Ultimately nothing can stop the user from using cvs tag -F, so any > > > > solution (including this one, which I like a lot) would have to be > > > > server-side. > > > > > > That's what they're planning to do, despite many objections. When will > > > the FeSCo minutes be available on the wiki ? I would like to know who > > > voted for this. > > > > I'm planning to write up the summary later today, but the IRC logs are > > available as soon as the meeting ends. > > > > http://bpepple.fedorapeople.org/fesco/ > > So, this is to dgilmore, bpepple, jds2001, and nirik (the 4 people that > voted for this action): you have just made it highly likely that you > will not ever get my vote to participate as a member of FESCo again (I > don't say this as a threat, just to let you know that your actions in > this endeavor so directly counter what I want/expect out of FESCo that I > don't consider you the right people for the job any more). +1 /me makes a note not to vote for these as well. [snip - excellent call] > Look guys, maybe what we have here is a case of mis-communication. So, > let me communicate what I expect out of FESCo/Fedora. Maybe I'm wrong > and my expectations are unreasonable. If so, I'll accept that answer. > But what I saw here was what I would expect to see in some proprietary > company under a self imposed deadline that cuts corners to get the job > done. I don't participate in Fedora for that. I participate in Fedora > because it's *supposed* to be the a place where we put quality above > expediency and we don't just do things, we do them right. In fact, I > care about that so much that it is definitely a valid voting item as far > as I'm concerned. I don't see this as being anywhere close to doing > things right, this is a sloppy, half-assed attempt to deal with a > legitimate problem by not actually dealing with it at all. I won't vote > for that, so by extension I won't vote for people that support doing > things this way. If I'm in the wrong place, and Fedora is about doing > things the expedient way instead of the right way, let me know and I'll > let you be. +1 And coming from someone @redhat.com, this is saying a lot. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From mw_triad at users.sourceforge.net Mon Sep 15 18:28:43 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Mon, 15 Sep 2008 13:28:43 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> Message-ID: Colin Walters wrote: > On Mon, Sep 15, 2008 at 9:39 AM, Denis Leroy wrote: >> I occasionally run into a Gnome app bug where drag'n'drop "hangs" the >> desktop (the "drag" never "drops", sort of) where the only way out is >> ctrl-alt-f1 to mingetty and killall the user-space app. Without mingetty, >> ctrl-alt-del is the only other option (i.e. loose all unsaved documents). > > We should make Ctrl-Alt-Backspace just break server grabs instead of > killing the server (and of course fix the bugs in the apps that hang > while holding a server grab). I hear the magic key to kill server grabs is going away in new X (maybe already has)... which is a pity, because something on my desktop occasionally grabs the mouse and won't let go. So... I'm in favor of a 'break grabs' key enabled by default :-). -- Matthew "NT was a marketing name that stood for New Technology, but it was still an amusing coincidence that WNT was VMS with each letter replaced by the next one." -- Jeremy Reimer From lesmikesell at gmail.com Mon Sep 15 18:38:41 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 15 Sep 2008 13:38:41 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <6c3f5e6c0809150738x2773d562t1fddad4400f36716@mail.gmail.com> <26905daf4f281992e0071f0788542863.squirrel@rousalka.dyndns.org> <20080915145041.GJ20342@mokona.greysector.net> <1221492617.18327.651.camel@beck.corsepiu.local> Message-ID: <48CEABB1.2080400@gmail.com> Colin Walters wrote: > On Mon, Sep 15, 2008 at 11:30 AM, Ralf Corsepius wrote: >> On Mon, 2008-09-15 at 16:55 +0200, Nicolas Mailhot wrote: >>> Le Lun 15 septembre 2008 16:50, Dominik 'Rathann' Mierzejewski a ?crit : >>>> On Monday, 15 September 2008 at 16:42, Nicolas Mailhot wrote: >>>> Just because it doesn't work for you does not mean it must be removed. >>> Since it's rotting it does not matter if it's explicitely removed or >>> not. The functionality is effectively going away through lack of >>> maintenance. >> 1. What is rotting, what is broken? > > The reason this thread began was that sound/pulseaudio doesn't work on > a console. That is -> resolved NOTABUG. So what is the solution where you want to use audio on a headless box? Or your X session (if you have one) is remote but the audio output connected to the speakers for the room is local? Or you want music to keep playing when the local X user changes? (Macs get this wrong too, but at least they have the excuse that they are trying to sell you a separate device that you can dedicate to audio if you actually want to listen to an uninterrupted song). -- Les Mikesell lesmikesell at gmail.com From Matt_Domsch at dell.com Mon Sep 15 18:52:47 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Mon, 15 Sep 2008 13:52:47 -0500 Subject: non-responsive maintainer 'misa': mx and pyOpenSSL packages up for adoption In-Reply-To: <1221485493.5272.16.camel@PB3.Linux> References: <20080915033702.GA4887@auslistsprd01.us.dell.com> <1221465947.9141.5.camel@PB3.Linux> <1221485493.5272.16.camel@PB3.Linux> Message-ID: <20080915185247.GA3627@auslistsprd01.us.dell.com> On Mon, Sep 15, 2008 at 02:31:33PM +0100, Paul wrote: > Hi, > > > > I have a patch to fix the mx FTBFS bug which I will apply as soon as > > > permissions in pkgdb allow, but would like to see these orphaned and > > > put up for adoption by a loving packager. > > > > Can you provide the patch and I'll take it on for now and then when (and > > if) it's orphaned, I'll do it as one of my packages? > > If someone puts me down as the co-maintainer, mx-3.1.1 is ready to roll > into rawhide! I move that Paul be allowed to take over the 'mx' package. I further request approval from a member of FESCo. Policy: If at least one FESco member approves the takeover, and no one objects within 3 days, you may take over the package. I also move that pyOpenSSL be orphaned, allowing another willing packager to take it on. This requires approval of FESCo. Policy: It is common for a Fedora contributor to maintain multiple packages within Fedora, and the situation may arise where multiple packages with a single maintainer need to be orphaned. Given that, it would be quite impractical to create a bugzilla ticket for each package. In the case where a mass orphaning is likely, the above should still be followed choosing a single package owned by the potential non-responsive developer. However, the formal request to the Fedora development mailing list should include all other bug reports open on all neglected packages from the same maintainer, indicating that the maintainer is indeed non-responsive. The Steering Committee can then step in and orphan the other packages if necessary. https://fedorahosted.org/fesco/ticket/5 is open to track these requests. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From lesmikesell at gmail.com Mon Sep 15 18:57:27 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 15 Sep 2008 13:57:27 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <7585a70c49ca0b864930da2f0d060e1e.squirrel@rousalka.dyndns.org> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE5701.7000109@gmail.com> <7c601311b9fd1b6bf9ded8a1d6419efa.squirrel@rousalka.dyndns.org> <48CE5D16.5060805@gmail.com> <7585a70c49ca0b864930da2f0d060e1e.squirrel@rousalka.dyndns.org> Message-ID: <48CEB017.1090505@gmail.com> Nicolas Mailhot wrote: > >>>>> Simply put, non-X-console input is a mess (X input is a mess too >>>>> but >>>>> at least there are people trying to fix it), non-X-console font >>>>> support has fossilized, and support for modern high resolution >>>>> screens >>>>> is severely lacking. >>>> Will you still be able to run a headless machine with its console >>>> redirected to a serial port? >>> Why not ? >> I think I'm confused by the term 'non X consoles'. Is that something >> different than the native text mode you see before X starts? > > I think you have two different things. A VT to which you can attach an > X session, a serial port, a remote SSH, mingetty... and the software > stack used to display locally the VT text and collect user input. > > I've no problem with the low-level VT bit. The current console > software stack OTOH has rotten and seriously needs replacement. OK, the low level part that works in character mode and expects some hardware to supply and render the fonts is absolutely necessary - software other than X that renders custom fonts, not so much. Can you make the distinction a little more clear when you are talking about removing parts? -- Les Mikesell lesmikesell at gmail.com From mw_triad at users.sourceforge.net Mon Sep 15 18:58:11 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Mon, 15 Sep 2008 13:58:11 -0500 Subject: Today's (9/12) rawhide all users = unable to authenticate user! In-Reply-To: <1221285235.3492.4.camel@fantail.jnet.net.nz> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <1221285235.3492.4.camel@fantail.jnet.net.nz> Message-ID: Nigel Jones wrote: > On Fri, 2008-09-12 at 23:35 -0500, Matthew Woehlke wrote: >> darrell pfeifer wrote: >>> 2008/9/12 Dr. Diesel >>> >>>> Booting normally to GDM, using normal root login gives me unable to >>>> authenticate user. If I boot to init3, my user/pass works just fine, then I >>>> can startx. I attempted passwd and reset my pass with no luck! >>>> >>>> Anybody else? Should I file this under GDM? >>>> >>> The gdm changelog says >>> >>> * Tue Sep 09 2008 Jon McCann - 1:2.23.92-2 >>> - Disallow root login >>> >>> So it is intentional >> So... what exactly are we supposed to do when the user login gets hosed? >> Reach for a rescue disk? (Seriously, what's with the sudden trend to >> make fixing problems harder by making recovery modes inaccessible in an >> apparent bid to hide the "confusing/potentially dangerous" bits of the >> system from the user?) > From memory GDM has always done this, (I personally don't use GDM, I > favour KDM), I remember some FC5 machines in particular that required a > GDM configuration hack to allow root logins. Last I checked I can login as root (in the display manager, which AFAIK is gdm) on this box. This is F9, and at any rate I'm 99% sure it worked in F8. > Overall, I'm in favour of not allowing root GUI logins by default, I'd > imagine we are still going to always have direct root CLI logins. ...unless the "let's remove mingetty" crowd gets their way. (That also assumes that VT switching is working, which seems to not be the case with nvidia's POS video drivers :-(.) -- Matthew "NT was a marketing name that stood for New Technology, but it was still an amusing coincidence that WNT was VMS with each letter replaced by the next one." -- Jeremy Reimer From choeger at cs.tu-berlin.de Mon Sep 15 19:02:59 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 15 Sep 2008 21:02:59 +0200 Subject: Non-X text mode console In-Reply-To: References: <20080915151812.0730561B48E@hormel.redhat.com> Message-ID: <1221505379.21005.4.camel@choeger6> Am Montag, den 15.09.2008, 14:06 -0400 schrieb David A. Wheeler: I think you _really_ misunderstood something, as I do not see any reason to kill vts, but if so: How hard is it for you to reactivate them? AFAIK they're just single processes started by init. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From lesmikesell at gmail.com Mon Sep 15 19:10:02 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 15 Sep 2008 14:10:02 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <48CE7406.1010409@odu.neva.ru> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> Message-ID: <48CEB30A.3000001@gmail.com> Dmitry Butskoy wrote: > >> Probably, because most console users already quit using Fedora, > > +1. > > And situation is worse than simply loss of a rare segment of the market. > > Who are "console users"? Most cases they are users who began for a long > time ago (when GUI was either poor or unavailable). Users whose main (only) purpose for the machine is to provide network services and there is little or no direct console use (firewall, router, file/email/web/database server, media player etc.). That is, most of the things computers are good at. > Lacking such "long > time ago" users, we lack all their skills, knowledge, intuition. And as > begun for a long time, many of them have already made their career, and > even make decisions now. Decisions not for Fedora. Fedora's direction makes it not particularly suited for production services, but... > Anyway, while Fedora is (still) considered as "general purpose disto", > it should has console. If you are going to do development/testing work for something to be matched and ready for the 'next' version of enterprise distributions, what OS should you use if not fedora? -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Mon Sep 15 18:45:37 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 15 Sep 2008 13:45:37 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1221490775.18327.626.camel@beck.corsepiu.local> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> Message-ID: <48CEAD51.9050700@gmail.com> Ralf Corsepius wrote: > > Other groups/use-cases, I see: > - Situations of emergency (Broken X-server, memory hogging-desktop > desktop apps etc.) > - Debugging. > - Machines without GUI installed. > > Probably the latter is hard to imagine to the folks who came up this > proposal. Yes, folks, there are machines which are being used without a > GUI! Servers need a GUI like a fish needs a bicycle (I forget who said that, but it's still just as true). >> Anyway, while Fedora is (still) considered as "general purpose disto", >> it should has console. > I regret having to state this, but I have been thinking Fedora has quit > being a "general purpose distro" for quite a while. Which will make things 'interesting' if RHEL continues to try to use fedora as a starting point. -- Les Mikesell lesmikesell at gmail.com From walters at verbum.org Mon Sep 15 19:27:58 2008 From: walters at verbum.org (Colin Walters) Date: Mon, 15 Sep 2008 15:27:58 -0400 Subject: Non-X text mode console In-Reply-To: <48CEA6D3.90906@herr-schmitt.de> References: <20080915151812.0730561B48E@hormel.redhat.com> <48CEA6D3.90906@herr-schmitt.de> Message-ID: On Mon, Sep 15, 2008 at 2:17 PM, Jochen Schmitt wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > David A. Wheeler schrieb: >> I think it's clear from this discussion here that many people DO >> find non-X console mode useful, and thus, it shouldn't be removed: >> Dominik 'Rathann' Mierzejewski: > I agree with you, that a release of Fedora without non-x mode console > may be > a disadvantage. > > Blind or low vision people may prefer non-X mode consoles. And I think > there are other > peoples with such prefernces too. For such use cases, an X terminal emulator such as gnome-terminal should be indistinguishable. Except that all the OS infrastructure like DBus, sound, etc. will be available and work. From smooge at gmail.com Mon Sep 15 19:44:48 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Mon, 15 Sep 2008 13:44:48 -0600 Subject: configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!) In-Reply-To: <1221426597.25056.6.camel@rosebud> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <1221285235.3492.4.camel@fantail.jnet.net.nz> <1221301012.3152.7.camel@pc-notebook> <48CBABC4.5060005@leemhuis.info> <20080913120636.GA20878@jadzia.bu.edu> <1221310726.3076.46.camel@rosebud> <80d7e4090809141226g7fa6fcfdy4d670dcaf9289584@mail.gmail.com> <1221426597.25056.6.camel@rosebud> Message-ID: <80d7e4090809151244g59e02d4doba20413e75c2c568@mail.gmail.com> On Sun, Sep 14, 2008 at 3:09 PM, Seth Vidal wrote: > On Sun, 2008-09-14 at 13:26 -0600, Stephen John Smoogen wrote: >> On Sat, Sep 13, 2008 at 6:58 AM, Seth Vidal wrote: >> > On Sat, 2008-09-13 at 08:06 -0400, Matthew Miller wrote: >> >> On Sat, Sep 13, 2008 at 02:02:12PM +0200, Thorsten Leemhuis wrote: >> >> > But a checkbox with a text "User is the sysadmin for this system" might >> >> > makes sense in firstboot -- that checkbox could not only configure sudo >> >> > and/or PolicyKit access but also do other things like setting up a alias to >> >> > /etc/aliases to make sure the user in question retrieves the mail send to >> >> > root. >> >> >> >> If we do this (and I'm for it), we should make this work by uncommenting the >> >> wheel group in /etc/sudoers, and having said checkbox add the user to the >> >> wheel group. >> > >> > I don't like the wheel group way into sudoers. Not the least of which >> > because the wheel group, on systems which are using some other form of >> > nss than local files, can be mucked with too easily. >> > >> >> Any solution is going to be fragile in the case of a network'd >> computer. Unix permission scheme was never designed with that in mind. >> So >> what is the 80% use solution? Of the fedora users, are 80% covered by >> local files or using nss_XXX? I am not for wheel or against it.. I >> just figure we should look at what is the majority use scheme and work >> around it for the rest. >> > > 80% is the entry gets added to /etc/sudoers by the user addition > interface if 'make this user an admin' is checked. > > I think the entry would look like: > > username ALL=(ALL) ALL > Perfect for me. Its my first step after logging in... just as long as we dont do username ALL=(ALL) NOPASSWD: ALL username ALL=(ALL) ANNOYINGPOPUP: ALL -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From kevin at scrye.com Mon Sep 15 19:51:19 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Mon, 15 Sep 2008 13:51:19 -0600 Subject: Proposal: Better force-tag In-Reply-To: <1221502515.1927.385.camel@firewall.xsintricity.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> <48CA16D1.5070409@redhat.com> <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> <1221234383.15726.194.camel@localhost.localdomain> <48CD1CA3.5060302@redhat.com> <1221402590.27183.172.camel@ignacio.lan> <48CD3358.8060105@poolshark.org> <1221409389.24484.1.camel@truman> <1221502515.1927.385.camel@firewall.xsintricity.com> Message-ID: <20080915135119.1a191264@ohm.scrye.com> On Mon, 15 Sep 2008 14:15:15 -0400 dledford at redhat.com (Doug Ledford) wrote: > On Sun, 2008-09-14 at 12:23 -0400, Brian Pepple wrote: > > On Sun, 2008-09-14 at 17:52 +0200, Denis Leroy wrote: > > > Ignacio Vazquez-Abrams wrote: > > > > Ultimately nothing can stop the user from using cvs tag -F, so > > > > any solution (including this one, which I like a lot) would > > > > have to be server-side. > > > > > > That's what they're planning to do, despite many objections. When > > > will the FeSCo minutes be available on the wiki ? I would like to > > > know who voted for this. > > > > I'm planning to write up the summary later today, but the IRC logs > > are available as soon as the meeting ends. > > > > http://bpepple.fedorapeople.org/fesco/ > > So, this is to dgilmore, bpepple, jds2001, and nirik (the 4 people > that voted for this action): you have just made it highly likely > that you will not ever get my vote to participate as a member of > FESCo again (I don't say this as a threat, just to let you know that > your actions in this endeavor so directly counter what I want/expect > out of FESCo that I don't consider you the right people for the job > any more). Fair enough. ...snipp... > Look guys, maybe what we have here is a case of mis-communication. I think this entire thing has been a lot of mis-communication. First of all I didn't think this was that big a deal. I have used 'make force-tag' and/or 'TAG_OPTS=-F make tag' a few times, but it was very few and far between. I guess possibly because I don't have packages that have tons of changes always happening. (yes, I also mockbuild locally my packages before checking in changes too, which I realize is not practical for everyone). It seems that forcing tags is heavily in the main path of some developers. ;( I disagree that some of those reasons are needed, but it sure seems to upset some people, and there is no reason to force a change before we have some work around. Given this I would like to see this revisited this week, and reverse the changes until we can get some fix in place (I like ajax's patch using Entities, but thats up to the buildsys/koji folks). > So, let me communicate what I expect out of FESCo/Fedora. Maybe I'm > wrong and my expectations are unreasonable. If so, I'll accept that > answer. But what I saw here was what I would expect to see in some > proprietary company under a self imposed deadline that cuts corners > to get the job done. I don't participate in Fedora for that. I > participate in Fedora because it's *supposed* to be the a place where > we put quality above expediency and we don't just do things, we do > them right. In fact, I care about that so much that it is definitely > a valid voting item as far as I'm concerned. I don't see this as > being anywhere close to doing things right, this is a sloppy, > half-assed attempt to deal with a legitimate problem by not actually > dealing with it at all. I won't vote for that, so by extension I > won't vote for people that support doing things this way. If I'm in > the wrong place, and Fedora is about doing things the expedient way > instead of the right way, let me know and I'll let you be. I don't think you are wrong, but I think this entire thing has been a miscommunication of the importantance of this change. I personally didn't think it was a big deal, it seems I was wrong. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jreiser at BitWagon.com Mon Sep 15 20:01:10 2008 From: jreiser at BitWagon.com (John Reiser) Date: Mon, 15 Sep 2008 13:01:10 -0700 Subject: Non-X text mode console In-Reply-To: References: <20080915151812.0730561B48E@hormel.redhat.com> <48CEA6D3.90906@herr-schmitt.de> Message-ID: <48CEBF06.8040604@BitWagon.com> >> Blind or low vision people may prefer non-X mode consoles. And I think >> there are other peoples with such prefernces too. > For such use cases, an X terminal emulator such as gnome-terminal > should be indistinguishable. Except that all the OS infrastructure > like DBus, sound, etc. will be available and work. No. An X terminal emulator is easily distinguishable from VGA text mode. Sometimes the difference an asset, and sometimes it is a liability. The 'screen' package is one example of software that can tell, and almost no serious user of both has any difficulty telling them apart. Also, "DBus, sound, etc." all can be used without X11. Even a mouse can be used without X11, and until some months ago this was the default. (gpm and/or its usage changed.) -- From krh at redhat.com Mon Sep 15 20:17:34 2008 From: krh at redhat.com (Kristian =?ISO-8859-1?Q?H=F8gsberg?=) Date: Mon, 15 Sep 2008 16:17:34 -0400 Subject: Boot speedup with readahead In-Reply-To: <1221501862.25056.44.camel@rosebud> References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <20080911090752.GC17152@mokona.greysector.net> <1221129185.18327.181.camel@beck.corsepiu.local> <1221457688.6122.23.camel@localhost.localdomain> <48CDFD37.8080702@behdad.org> <1221479676.25056.18.camel@rosebud> <48CE9522.2010308@behdad.org> <1221501862.25056.44.camel@rosebud> Message-ID: <1221509854.3906.19.camel@gaara.bos.redhat.com> On Mon, 2008-09-15 at 14:04 -0400, Seth Vidal wrote: > On Mon, 2008-09-15 at 13:02 -0400, Behdad Esfahbod wrote: > > - Kristian H?gsberg built razor which can solve deps in fraction of a second > > where yum simply takes way too long. Is anyone in the RPM camp impressed? > > No. They just don't think it's possible to do with RPM. > > > Kristian built something which solves some dependencies. Mostly he wrote > a mmap'd repometadata format. Look, depsolving isn't hard and razor is on par with yum as far as correctness goes and in a whole different class as far as performance goes. I'm sure it's convenient to write it off as just a different repodata format, but we both know razor is much more than that. Our current package deployment stack is a horrible tangle of different scripting languages, different database formats and an rpm codebase that we're afraid to touch. A lof of that complexity is self-inflicted, the rest is horrible implementation. We could be ambitious here and try to own the problem from laying the files down on disk all the way up to doing depsolving in an instant. Instead we have a small group of people adding bandaids to yum and tip-toeing around the rpm complexity, while telling everybody how hard this problem is and we're lucky yum isn't slower with all the things it does. I don't have the time or energy to jump into this discussion, and when I do, despite my better judgement, I get frustrated, upset and lose my motivation for a week. Keep your pathetic little kingdom. Kristian From a.badger at gmail.com Mon Sep 15 20:28:58 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 15 Sep 2008 13:28:58 -0700 Subject: Proposal: Better force-tag In-Reply-To: <20080915135119.1a191264@ohm.scrye.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> <48CA16D1.5070409@redhat.com> <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> <1221234383.15726.194.camel@localhost.localdomain> <48CD1CA3.5060302@redhat.com> <1221402590.27183.172.camel@ignacio.lan> <48CD3358.8060105@poolshark.org> <1221409389.24484.1.camel@truman> <1221502515.1927.385.camel@firewall.xsintricity.com> <20080915135119.1a191264@ohm.scrye.com> Message-ID: <48CEC58A.3060009@gmail.com> Kevin Fenzi wrote: > I think this entire thing has been a lot of mis-communication. > > First of all I didn't think this was that big a deal. > I have used 'make force-tag' and/or 'TAG_OPTS=-F make tag' a few times, > but it was very few and far between. I guess possibly because I don't > have packages that have tons of changes always happening. > (yes, I also mockbuild locally my packages before checking in changes > too, which I realize is not practical for everyone). > > It seems that forcing tags is heavily in the main path of some > developers. ;( I disagree that some of those reasons are needed, but it > sure seems to upset some people, and there is no reason to force a > change before we have some work around. > > Given this I would like to see this revisited this week, and reverse > the changes until we can get some fix in place (I like ajax's patch > using Entities, but thats up to the buildsys/koji folks). > Reversing the decision may be the right thing to do. To avoid seesawing decisions as one side and then another argues their case, I'd love to hear a few words from the koji devs, though: 1) In what situations can things be broken with force-tags? (ie: is it just when force tagging a successfully completed build? Are completed failed builds okay? What happens if a retag occurs on an in-progress build?) 2) What breakage occurs? (ie: the current discussion seems to be that only recreating an SRPM for GPL compliance is broken. What about requeue and other koji functions?) 3) Is there a plan for fixing things so developers don't need to do retags? Timeframe? Is it acceptable to leave these commands in until then? I feel like FESCo is in the unenviable position of mediating between tool developers who say the tool doesn't operate the way people are using it but haven't given enough details of what the problem is and package maintainers who want to do something potentially problematic because of other deficiencies in the tool. More communication between the two endpoints is desirable here. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From ajax at redhat.com Mon Sep 15 20:31:37 2008 From: ajax at redhat.com (Adam Jackson) Date: Mon, 15 Sep 2008 16:31:37 -0400 Subject: Proposal: Better force-tag In-Reply-To: <20080915135119.1a191264@ohm.scrye.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> <48CA16D1.5070409@redhat.com> <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> <1221234383.15726.194.camel@localhost.localdomain> <48CD1CA3.5060302@redhat.com> <1221402590.27183.172.camel@ignacio.lan> <48CD3358.8060105@poolshark.org> <1221409389.24484.1.camel@truman> <1221502515.1927.385.camel@firewall.xsintricity.com> <20080915135119.1a191264@ohm.scrye.com> Message-ID: <1221510697.15981.83.camel@atropine.boston.devel.redhat.com> On Mon, 2008-09-15 at 13:51 -0600, Kevin Fenzi wrote: > First of all I didn't think this was that big a deal. > I have used 'make force-tag' and/or 'TAG_OPTS=-F make tag' a few times, > but it was very few and far between. I guess possibly because I don't > have packages that have tons of changes always happening. > (yes, I also mockbuild locally my packages before checking in changes > too, which I realize is not practical for everyone). It's not that it's not practical, it's that it's not sufficient. I regularly trip up on architecture differences. Granted, X is intrinsically hardware-dependent in a way that (say) coreutils isn't, but anyone who's ever had to deal with a multilib bug has probably hit this too; it's just too much to keep in your head, so don't bother, let the build system sort it out for you. I think the major objection here is that the solution didn't match the problem, even to a first degree. First you remove force-tag, then someone notices TAG_OPTS so you have to remove that, then they notice that cvs tag still works so you have to go lock it down server-side. We're typically willing to accept workflow changes if they are well-deployed and achieve a worthwhile goal. This, manifestly, did not. Now, that it was done without announcement, and apparently without even cursory investigation into the solution space, is the sort of thing that makes people go all ranty and arm-wavey. Personally I try not to get too worked up about communication problems, since afaict it's just the reality of dealing with nerds on the internet. But that's not to say we don't have lessons to learn. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Mon Sep 15 20:32:43 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 16 Sep 2008 02:02:43 +0530 Subject: Boot speedup with readahead In-Reply-To: <1221509854.3906.19.camel@gaara.bos.redhat.com> References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <20080911090752.GC17152@mokona.greysector.net> <1221129185.18327.181.camel@beck.corsepiu.local> <1221457688.6122.23.camel@localhost.localdomain> <48CDFD37.8080702@behdad.org> <1221479676.25056.18.camel@rosebud> <48CE9522.2010308@behdad.org> <1221501862.25056.44.camel@rosebud> <1221509854.3906.19.camel@gaara.bos.redhat.com> Message-ID: <48CEC66B.2000206@fedoraproject.org> Kristian H?gsberg wrote: > On Mon, 2008-09-15 at 14:04 -0400, Seth Vidal wrote: >> On Mon, 2008-09-15 at 13:02 -0400, Behdad Esfahbod wrote: >>> - Kristian H?gsberg built razor which can solve deps in fraction of a second >>> where yum simply takes way too long. Is anyone in the RPM camp impressed? >>> No. They just don't think it's possible to do with RPM. >> >> Kristian built something which solves some dependencies. Mostly he wrote >> a mmap'd repometadata format. > > Look, depsolving isn't hard and razor is on par with yum as far as > correctness goes and in a whole different class as far as performance > goes. Is it in a usable state for day to day work or atleast for testing? I would like to see it packaged and more easily consumable in that case atleast for rawhide. Rahul From chitlesh.goorah at gmail.com Mon Sep 15 20:36:28 2008 From: chitlesh.goorah at gmail.com (Chitlesh GOORAH) Date: Mon, 15 Sep 2008 22:36:28 +0200 Subject: KDE4: Utilities directory messed up Message-ID: <50baabb30809151336s60f056e3j906c1e1f5a7bed50@mail.gmail.com> Hai there, I have been forwarded to the following email. KDE4 experts and heroes can you have a look at it please ? :) Chitlesh --------------------------- Subject: [Bug 161117] Utilities directory messed up by Revision 789264 of applications.menu http://bugs.kde.org/show_bug.cgi?id=161117 --- Comment #3 from Ariszl? 2008-09-15 19:21:39 --- This is no longer an svn bug: it has entered KDE 4.1.0 and is passed on to KDE 4.1.1. You will not suffer from this bug if you are using Kubuntu because the bug has been fixed downstream. You will not suffer from it in openSUSE either because openSUSE has never used the upstream applications.menu. You will only notice this bug if you are using a distribution that does not change the upstream applications.menu and does not modify the Categories fields of the .desktop files either. Log in to Fedora Rawhide and install kdegraphics, kdeutils, koffice-core, koffice-kchart and koffice-kformula. Now you will see the mess! KColorChooser & KRuler will be listed in both Graphics/More and Utilities main. They will be listed in Graphics/More because they have both Graphics and X-KDE-More in their Categories fields. They will be listed in Utilities main because whatever has X-KDE-More in its Categories field will be listed there with no restriction. KChart, KFormula & Kthesaurus will be listed in both Office/More and Utilities main because they have both Office and X-KDE-More in their Categories fields. KDiskFree and KwikDisk will be listed in both System/More and Utilities main because they have System and X-KDE-More in their Categories fields. Finally, KCharSelect, KTimer and Sweeper will be listed in both Utilities main and Utilities/More. They will be listed in Utilities/More because they have both Utility and X-KDE-More in their Categories fields. They will be listed in Utilities main because whatever has X-KDE-More in its Categories field will be listed there. You may also test this bug in Kubuntu Intrepid Ibex provided that you manually replace Kubuntu's kde-applications.menu with the upstream applications.menu. Now install the following packages and experience the bug just like in Fedora. Don't forget to replace kde-applications.menu with the upstream applications.menu! apt-get install kcharselect, kcolorchooser, kdf, kruler, ktimer, sweeper Unfortunately, if you are using openSUSE then you are out of luck ;) You won't be able to test this bug no matter how much you try because your distribution heavily customizes both the applications.menu and the .desktop files. From dledford at redhat.com Mon Sep 15 20:49:16 2008 From: dledford at redhat.com (Doug Ledford) Date: Mon, 15 Sep 2008 16:49:16 -0400 Subject: Proposal: Better force-tag In-Reply-To: <20080915135119.1a191264@ohm.scrye.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> <48CA16D1.5070409@redhat.com> <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> <1221234383.15726.194.camel@localhost.localdomain> <48CD1CA3.5060302@redhat.com> <1221402590.27183.172.camel@ignacio.lan> <48CD3358.8060105@poolshark.org> <1221409389.24484.1.camel@truman> <1221502515.1927.385.camel@firewall.xsintricity.com> <20080915135119.1a191264@ohm.scrye.com> Message-ID: <1221511756.1927.419.camel@firewall.xsintricity.com> On Mon, 2008-09-15 at 13:51 -0600, Kevin Fenzi wrote: > On Mon, 15 Sep 2008 14:15:15 -0400 > dledford at redhat.com (Doug Ledford) wrote: > > Look guys, maybe what we have here is a case of mis-communication. > > I think this entire thing has been a lot of mis-communication. > > First of all I didn't think this was that big a deal. > I have used 'make force-tag' and/or 'TAG_OPTS=-F make tag' a few times, > but it was very few and far between. I guess possibly because I don't > have packages that have tons of changes always happening. > (yes, I also mockbuild locally my packages before checking in changes > too, which I realize is not practical for everyone). It varies from person to person and package to package. I locally build almost all of my packages, but I have a few that are ppc/ppc64 only and I have no means of building them. So, they get their testing done in the build system. On those packages, I make judicious use of force-tag. In addition, the kernel is a good example of one that I use force-tag on because it also may break on arches other than your own (the kernel is a bit special in that is has so much arch specific code that the chances of another arch breaking are quite high for certain types of changes). I *could* do an srpm build to test ppc/ppc64 kernel builds, but it takes 30 minutes for a kernel srpm to upload to the build system from here (admittedly, I do this on my rhel kernel builds, I haven't been messing with Fedora kernels, but the point is valid regardless), so I commit, tag, build, fix, force-tag, build, fix, etc. > I don't think you are wrong, but I think this entire thing has been a > miscommunication of the importantance of this change. I personally > didn't think it was a big deal, it seems I was wrong. There are two aspects to this. 1) It's a change to solve a problem. The problem is, it didn't solve the problem. That made the action analogous to security by obscurity type actions. 2) When it doesn't solve the problem, and it negatively impacts people's work flow, and you go ahead and do it anyway, then it feels like the majority of us that use it responsibly are being punished for the actions of a few. In fact, I would liken it to all the DRM placed on songs or videos: it doesn't stop the criminals from doing what they are going to do, but it makes the lives of honest people more difficult. I'm going to go out on a limb and say that the reason so many people have objected to the change is because we don't give FESCo the right to make our lives more difficult without cause. Due to #1 and #2, that's what they did. Don't do that and we'll get along *much* better ;-) Anyway, I'll withdraw my statement that I won't ever vote for you guys. It doesn't sound like people here are on a power trip, instead it feels a bit more like an unfortunate rookie mistake ;-) -- Doug Ledford GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From paul at all-the-johnsons.co.uk Mon Sep 15 21:02:50 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Mon, 15 Sep 2008 22:02:50 +0100 Subject: non-responsive maintainer 'misa': mx and pyOpenSSL packages up for adoption In-Reply-To: <20080915185247.GA3627@auslistsprd01.us.dell.com> References: <20080915033702.GA4887@auslistsprd01.us.dell.com> <1221465947.9141.5.camel@PB3.Linux> <1221485493.5272.16.camel@PB3.Linux> <20080915185247.GA3627@auslistsprd01.us.dell.com> Message-ID: <1221512570.8091.8.camel@PB3.Linux> Hi, > > > > If someone puts me down as the co-maintainer, mx-3.1.1 is ready to roll > > into rawhide! > > I move that Paul be allowed to take over the 'mx' package. I further > request approval from a member of FESCo. > > Policy: If at least one FESco member approves the takeover, and no one > objects within 3 days, you may take over the package. > > > I also move that pyOpenSSL be orphaned, allowing another willing > packager to take it on. This requires approval of FESCo. If no-one else wants it, I'll take that as well. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pemboa at gmail.com Mon Sep 15 21:19:22 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 15 Sep 2008 16:19:22 -0500 Subject: Non-X text mode console In-Reply-To: <1221505379.21005.4.camel@choeger6> References: <20080915151812.0730561B48E@hormel.redhat.com> <1221505379.21005.4.camel@choeger6> Message-ID: <16de708d0809151419l5d51863eg5a425db07166071a@mail.gmail.com> 2008/9/15 Christoph H?ger : > Am Montag, den 15.09.2008, 14:06 -0400 schrieb David A. Wheeler: > > I think you _really_ misunderstood something, as I do not see any reason > to kill vts, but if so: How hard is it for you to reactivate them? AFAIK > they're just single processes started by init. How hard is it for people who wanted deactivated to deactivate them? -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From jkeating at j2solutions.net Mon Sep 15 21:51:04 2008 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 15 Sep 2008 14:51:04 -0700 Subject: Proposal: Better force-tag In-Reply-To: <48CEC58A.3060009@gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> <48CA16D1.5070409@redhat.com> <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> <1221234383.15726.194.camel@localhost.localdomain> <48CD1CA3.5060302@redhat.com> <1221402590.27183.172.camel@ignacio.lan> <48CD3358.8060105@poolshark.org> <1221409389.24484.1.camel@truman> <1221502515.1927.385.camel@firewall.xsintricity.com> <20080915135119.1a191264@ohm.scrye.com> <48CEC58A.3060009@gmail.com> Message-ID: <1221515464.3629.25.camel@luminos.localdomain> On Mon, 2008-09-15 at 13:28 -0700, Toshio Kuratomi wrote: > Reversing the decision may be the right thing to do. To avoid seesawing It's not seesawing, it's re-examining a decision when more relevant information is presented. > decisions as one side and then another argues their case, I'd love to > hear a few words from the koji devs, though: > > 1) In what situations can things be broken with force-tags? (ie: is it > just when force tagging a successfully completed build? Are completed > failed builds okay? What happens if a retag occurs on an in-progress > build?) The only thing that can be "broken" is the ability to check the source back out via the tag and have it match what went into koji. Once koji has done the initial checkout, it's done with CVS for that build. Nothing later in the build task requires hitting CVS, so changing the tag for an inflight build does not harm the current build. If somebody requests a task be resubmitted, there is a chance that the content that comes out of CVS will be different than the first time. Then again, the content in the buildroots can be different as well. Really nothing in the way we /currently/ use Koji and CVS requires that the tags not be forced. We just can't add any functionality to our infrastructure that would depend on it until we close this loop. > > 2) What breakage occurs? (ie: the current discussion seems to be that > only recreating an SRPM for GPL compliance is broken. What about > requeue and other koji functions?) I tried to cover that above. > > 3) Is there a plan for fixing things so developers don't need to do > retags? Timeframe? Is it acceptable to leave these commands in until then? It was not really a priority to fix, there were other things being worked on. We can certainly make this a priority, although it's really more of a Make/CVS issue than a Koji issue. > I feel like FESCo is in the unenviable position of mediating between > tool developers who say the tool doesn't operate the way people are > using it but haven't given enough details of what the problem is and > package maintainers who want to do something potentially problematic > because of other deficiencies in the tool. More communication between > the two endpoints is desirable here. > -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Sep 15 22:02:42 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 15 Sep 2008 15:02:42 -0700 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1221490775.18327.626.camel@beck.corsepiu.local> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> Message-ID: <1221516162.3629.26.camel@luminos.localdomain> On Mon, 2008-09-15 at 16:59 +0200, Ralf Corsepius wrote: > I regret having to state this, but I have been thinking Fedora has quit > being a "general purpose distro" for quite a while. More to the point, the only large active group trying to move things forward for Fedora are those that care about the Desktop experience, ergo those are the directions Fedora is going in. It's a serve yourself kind of project, it is what you make of it. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From lesmikesell at gmail.com Mon Sep 15 22:16:17 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 15 Sep 2008 17:16:17 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1221516162.3629.26.camel@luminos.localdomain> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <1221516162.3629.26.camel@luminos.localdomain> Message-ID: <48CEDEB1.2080000@gmail.com> Jesse Keating wrote: > On Mon, 2008-09-15 at 16:59 +0200, Ralf Corsepius wrote: >> I regret having to state this, but I have been thinking Fedora has quit >> being a "general purpose distro" for quite a while. > > More to the point, the only large active group trying to move things > forward for Fedora are those that care about the Desktop experience, > ergo those are the directions Fedora is going in. It's a serve yourself > kind of project, it is what you make of it. I don't think you can call it 'moving forward' if it breaks the things that have been the most useful about Linux so far. -- Les Mikesell lesmikesell at gmail.com From j.w.r.degoede at hhs.nl Mon Sep 15 22:17:51 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 16 Sep 2008 00:17:51 +0200 Subject: Headsup: new ode release (soname change) coming to rawhide Message-ID: <48CEDF0F.8010809@hhs.nl> Hi All, When rawhide unfreezes a new ode release, which changes the ABI (but not the API, so a rebuild should suffice *) will hit rawhide. In the mean time you can get it here: http://kojipkgs.fedoraproject.org/packages/ode/0.10.1/1.fc10/ * Note I say: "a rebuild should suffice" but for 2 of my own ode using packages it did not suffice, as they did not call dInitODE(), something which ode now checks for and if not init-ed before use the new ode will abort. To test rebuild, prepare and test your packages. Do not fire of rebuilds until rawhide is unfrozen from the beta, rebuilding before that will build against the old ode. I wish I could have done this before the beta, but I simply did not have the time for this. Affected packages: raydium-0:1.2-9.fc10.x86_64 machineball-0:1.0-5.fc9.x86_64 xmoto-0:0.4.2-1.fc9.x86_64 stormbaancoureur-0:2.1.4-1.fc10.x86_64 crystalspace-0:1.2-7.fc10.x86_64 rcssserver3d-0:0.6-4.fc10.x86_64 I'll take care of raydium, machineball, stormbaancoureur and crystalspace myself as those are all mine. Regards, Hans From james.antill at redhat.com Mon Sep 15 23:11:53 2008 From: james.antill at redhat.com (James Antill) Date: Mon, 15 Sep 2008 19:11:53 -0400 Subject: Boot speedup with readahead In-Reply-To: <48CE9522.2010308@behdad.org> References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <20080911090752.GC17152@mokona.greysector.net> <1221129185.18327.181.camel@beck.corsepiu.local> <1221457688.6122.23.camel@localhost.localdomain> <48CDFD37.8080702@behdad.org> <1221479676.25056.18.camel@rosebud> <48CE9522.2010308@behdad.org> Message-ID: <1221520313.16310.26.camel@code.and.org> On Mon, 2008-09-15 at 13:02 -0400, Behdad Esfahbod wrote: > The question is: if one could throw RPM away and design a new one, could one > do significantly better? Of course one could, the relevant question is _how long_ would it take. And could it be done faster by just fixing rpm, and I've not seen any compelling arguments that it would be faster to throw away what we have. It is also wide believed as true in the software field that "re-write from scratch" is a last resort, and will always take longer and be more expensive etc. There are cases where the subset of problems people care about is smaller than those solved by the original program, "everyone" dislikes the original program and a small group of good programmers are willing to spend/invest a _lot_ of time to create a replacement. But I can only think of a handful of examples here, and there's a reason for that. > Lets look back at the problem at hand: we all agree that custom-installed > glob-matched post-transaction triggers are useful things. I think I can also > say that we agree that it should be in the lowest-level package management > system. What has been up to debate so far is whether that lowest-level is > RPM, or that RPM is a lost case and yum is considered the lowest-level. That is a severe mis-reading of the discussion, the question is given that rpm+yum are currently how all Fedora users manage their system. Do we want to still require that all packaging problems should be solved at the rpm layer, or should we try to move up and allow some more of the problems to be solved at the yum layer. There are many advantages to doing this, including just plain ease of implementation. The only real disadvantage is that apt/smart/zypp/etc. will become even more of a second class citizen in Fedora than they already are (although I'm confident that the change proposed by Seth could easily be ported to work in all of the above). -- James Antill Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From paul at all-the-johnsons.co.uk Mon Sep 15 23:12:38 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 16 Sep 2008 00:12:38 +0100 Subject: Unstripped .so files in python packages Message-ID: <1221520358.23024.3.camel@PB3.Linux> Hi, I'm just doing the final cleanup for the next version of mx and have hit a number of warnings from rpmlint that there are a number of .so files which are not stripped. How do I do that within the spec file or is it an rpmlint oddity which can be ignored? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From airlied at redhat.com Mon Sep 15 23:13:56 2008 From: airlied at redhat.com (Dave Airlie) Date: Tue, 16 Sep 2008 09:13:56 +1000 Subject: Non-X text mode console In-Reply-To: <48CEA848.2050005@redhat.com> References: <20080915151812.0730561B48E@hormel.redhat.com> <48CEA848.2050005@redhat.com> Message-ID: <1221520436.7519.0.camel@localhost> On Mon, 2008-09-15 at 14:24 -0400, Chris Snook wrote: > David A. Wheeler wrote: > > I routinely use text mode console without X, for a > > variety of reasons. For example: > > * I have a number of systems (servers) at runlevel 3 > > * console is critically important when X fails. "Log in with ssh" > > doesn't work when ssh or the network fails. > > * It's often much simpler to quickly log in to do a small task > > rather than waiting for all the X + desktop startup stuff > > * I have some systems that have GUIs but not X at all > > (e.g., use DirectFB directly to the framebuffer)... and > > I sometimes need a recovery method, just like I do for X > > > > I think it's clear from this discussion here that many people DO > > find non-X console mode useful, and thus, it shouldn't be removed: > > Dominik 'Rathann' Mierzejewski: > >> It does matter, since the removal affects me (and some other people, apparently), > >> while just keeping it means it will continue to work as it does now. > > > > The complaints about non-X console mode failing to support > > "multiple fonts" are irrelevant. I do not WANT text-mode > > console to support multiple fonts; that would interfere with > > console mode's advantages (e.g., small size, often works even when > > X fails). When I want fonts, I'll use X. > > > > --- David A. Wheeler > > > > Unless I've missed something huge, virtual terminals aren't going away. What > may or may not be going away is the x86 video BIOS text mode, to be replaced > with a kernel framebuffer, which precludes the use of console fonts, which very > few people ever mess with. The console itself will remain. Someone please > correct me if I'm wrong. Exactly. the vga text mode will not be enabled by default, you will need to pass nomodeset if you want to use vga text mode. Welcome to the 1990s. Dave. From paul at all-the-johnsons.co.uk Mon Sep 15 23:19:29 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 16 Sep 2008 00:19:29 +0100 Subject: mx and pyOpenSSL - Heads up to rebuild! Message-ID: <1221520769.23024.9.camel@PB3.Linux> Hi, I've just finished building mx and pyOpenSSL for putting into rawhide as soon as I get ACL approval for them. If you are a packager for one of the following, please download the mx src.rpm and do a local build from it and then recompile your apps. Packages affected: MySQL-python bibus gnue-common poker-server pyicq-t-mysql python-biopython python-sqlobject TurboGears bodhi-server ipa-server ipa-server python-TurboMail python-tgcaptcha python-turboflot smolt-serve python-storm-mysql python-storm python-storm-postgresql python-storm-sqlite postgresql-python koji-hub koji-utils koji-web python-sqlobject tinyerp-server python-biopython python-logilab python-logilab-astng pylint pylint-gui python-psycopg straw tinyerp mx-3.1.1-1.fc10.src.rpm and pyOpenSSL-0.7-1.fc10.src.rpm are available from pfj.fedorapeople.org TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Mon Sep 15 23:25:31 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 15 Sep 2008 16:25:31 -0700 Subject: Unstripped .so files in python packages In-Reply-To: <1221520358.23024.3.camel@PB3.Linux> References: <1221520358.23024.3.camel@PB3.Linux> Message-ID: <48CEEEEB.7020009@gmail.com> Paul wrote: > Hi, > > I'm just doing the final cleanup for the next version of mx and have hit > a number of warnings from rpmlint that there are a number of .so files > which are not stripped. > > How do I do that within the spec file or is it an rpmlint oddity which > can be ignored? > They should be detected and stripped by rpmbuild. If the sources are checked in I can take a look. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From behdad at behdad.org Mon Sep 15 23:30:47 2008 From: behdad at behdad.org (Behdad Esfahbod) Date: Mon, 15 Sep 2008 19:30:47 -0400 Subject: Boot speedup with readahead In-Reply-To: <1221520313.16310.26.camel@code.and.org> References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <20080911090752.GC17152@mokona.greysector.net> <1221129185.18327.181.camel@beck.corsepiu.local> <1221457688.6122.23.camel@localhost.localdomain> <48CDFD37.8080702@behdad.org> <1221479676.25056.18.camel@rosebud> <48CE9522.2010308@behdad.org> <1221520313.16310.26.camel@code.and.org> Message-ID: <48CEF027.8050307@behdad.org> James Antill wrote: > On Mon, 2008-09-15 at 13:02 -0400, Behdad Esfahbod wrote: > >> The question is: if one could throw RPM away and design a new one, could one >> do significantly better? > > Of course one could, the relevant question is _how long_ would it take. > And could it be done faster by just fixing rpm, and I've not seen any > compelling arguments that it would be faster to throw away what we have. I made it very clear in my mail that I'm not suggesting that we should throw RPM away. The question I asked is supposed to give one an idea of how much of the problem is caused by the current implementation as opposed to the inherent complexity of the problem. >> Lets look back at the problem at hand: we all agree that custom-installed >> glob-matched post-transaction triggers are useful things. I think I can also >> say that we agree that it should be in the lowest-level package management >> system. What has been up to debate so far is whether that lowest-level is >> RPM, or that RPM is a lost case and yum is considered the lowest-level. > > That is a severe mis-reading of the discussion, the question is given > that rpm+yum are currently how all Fedora users manage their system. Do > we want to still require that all packaging problems should be solved at > the rpm layer, or should we try to move up and allow some more of the > problems to be solved at the yum layer. > There are many advantages to doing this, including just plain ease of > implementation. The only real disadvantage is that apt/smart/zypp/etc. > will become even more of a second class citizen in Fedora than they > already are (although I'm confident that the change proposed by Seth > could easily be ported to work in all of the above). What exactly in my paragraph you quotes is "a severe mis-reading of the discussion"? You say the exact same thing as I did except that instead of calling RPM a lost case as I did, you call this approach making apt/smart/zypp/etc. even more of a second class citizen. End result is the same pig: use yum or be screwed. You and Seth seem to be on the camp that thinks it's no big deal if one uses RPM directly and gets into a suboptimal state. Some of us think that that's unacceptable. We disagree and that's fine. Whoever ends up doing the work decides what to do. I fully understand that and don't mean to imply what people should be working on. Hope I've made myself clear this time. behdad From jkeating at redhat.com Mon Sep 15 23:42:51 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 15 Sep 2008 16:42:51 -0700 Subject: kernel-devel in "Fedora" spin? Message-ID: <1221522171.2102.6.camel@luminos.localdomain> Back in December, I had made a change that blocked kernel-devel packages from winding up in the install media for the Fedora spin. I don't recall getting any push back at the time, but I've gotten at least one angry comment since then. So I'm putting it out for more discussion. Do we feel that the kernel-devel (5~megs) should be in the install media? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Mon Sep 15 23:54:04 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 15 Sep 2008 15:54:04 -0800 Subject: kernel-devel in "Fedora" spin? In-Reply-To: <1221522171.2102.6.camel@luminos.localdomain> References: <1221522171.2102.6.camel@luminos.localdomain> Message-ID: <604aa7910809151654ic50d153re5e0244f2f3f08fe@mail.gmail.com> 2008/9/15 Jesse Keating : > Back in December, I had made a change that blocked kernel-devel packages > from winding up in the install media for the Fedora spin. I don't > recall getting any push back at the time, but I've gotten at least one > angry comment since then. So I'm putting it out for more discussion. > Do we feel that the kernel-devel (5~megs) should be in the install > media? Any other -devel packages on the media? -jef From joshuacov at googlemail.com Mon Sep 15 23:57:38 2008 From: joshuacov at googlemail.com (Joshua C.) Date: Tue, 16 Sep 2008 01:57:38 +0200 Subject: New repo directories on http://download.fedora.redhat.com ??? Message-ID: <5f6f8c5f0809151657s222ea376hc5af72e8a9b212a9@mail.gmail.com> I just saw that the dirs in testing on http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$release/ are renamed from $basearch.newkey to $basearch.newkey.newkey. But the other mirrors still have $basearch.newkey. Is this connected with the new signing key or is just a server problem? From cra at WPI.EDU Tue Sep 16 00:00:05 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 15 Sep 2008 20:00:05 -0400 Subject: kernel-devel in "Fedora" spin? In-Reply-To: <604aa7910809151654ic50d153re5e0244f2f3f08fe@mail.gmail.com> References: <1221522171.2102.6.camel@luminos.localdomain> <604aa7910809151654ic50d153re5e0244f2f3f08fe@mail.gmail.com> Message-ID: <20080916000005.GH15457@angus.ind.WPI.EDU> On Mon, Sep 15, 2008 at 03:54:04PM -0800, Jeff Spaleta wrote: > 2008/9/15 Jesse Keating : > > Back in December, I had made a change that blocked kernel-devel packages > > from winding up in the install media for the Fedora spin. I don't > > recall getting any push back at the time, but I've gotten at least one > > angry comment since then. So I'm putting it out for more discussion. > > Do we feel that the kernel-devel (5~megs) should be in the install > > media? > > Any other -devel packages on the media? I see 166 -devel in 9/Fedora/i386/os/Packages. How were they chosen? -devel for all packages present on the media? If so, kernel-devel logically fits there too. From jkeating at redhat.com Tue Sep 16 00:00:38 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 15 Sep 2008 17:00:38 -0700 Subject: kernel-devel in "Fedora" spin? In-Reply-To: <604aa7910809151654ic50d153re5e0244f2f3f08fe@mail.gmail.com> References: <1221522171.2102.6.camel@luminos.localdomain> <604aa7910809151654ic50d153re5e0244f2f3f08fe@mail.gmail.com> Message-ID: <1221523238.2102.7.camel@luminos.localdomain> On Mon, 2008-09-15 at 15:54 -0800, Jeff Spaleta wrote: > Any other -devel packages on the media? Just the following groups: @development-libs @development-tools @gnome-software-development @java-development @kde-software-development @web-development @x-software-development kernel-devel does not seem to be a part of any of those groups. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Sep 16 00:01:21 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 15 Sep 2008 17:01:21 -0700 Subject: New repo directories on http://download.fedora.redhat.com ??? In-Reply-To: <5f6f8c5f0809151657s222ea376hc5af72e8a9b212a9@mail.gmail.com> References: <5f6f8c5f0809151657s222ea376hc5af72e8a9b212a9@mail.gmail.com> Message-ID: <1221523281.2102.8.camel@luminos.localdomain> On Tue, 2008-09-16 at 01:57 +0200, Joshua C. wrote: > I just saw that the dirs in testing on > http://download.fedora.redhat.com/pub/fedora/linux/updates/testing/$release/ > are renamed from $basearch.newkey to $basearch.newkey.newkey. But the > other mirrors still have $basearch.newkey. Is this connected with the > new signing key or is just a server problem? Process problem. .newkey.newkey will be going away, .newkey should have never gone away. If you saw it go away, something different went wrong. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Tue Sep 16 00:11:11 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 15 Sep 2008 16:11:11 -0800 Subject: kernel-devel in "Fedora" spin? In-Reply-To: <1221523238.2102.7.camel@luminos.localdomain> References: <1221522171.2102.6.camel@luminos.localdomain> <604aa7910809151654ic50d153re5e0244f2f3f08fe@mail.gmail.com> <1221523238.2102.7.camel@luminos.localdomain> Message-ID: <604aa7910809151711j36666d8cx56a570b19fe6fd32@mail.gmail.com> 2008/9/15 Jesse Keating : > kernel-devel does not seem to be a part of any of those groups. hmm not part of any established development group...that seems like an oversight. So it was being special cased before? -jef"Speaking of oversights..I should really add my apps to the comps file..sigh"spaleta From jkeating at redhat.com Tue Sep 16 00:21:47 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 15 Sep 2008 17:21:47 -0700 Subject: kernel-devel in "Fedora" spin? In-Reply-To: <604aa7910809151711j36666d8cx56a570b19fe6fd32@mail.gmail.com> References: <1221522171.2102.6.camel@luminos.localdomain> <604aa7910809151654ic50d153re5e0244f2f3f08fe@mail.gmail.com> <1221523238.2102.7.camel@luminos.localdomain> <604aa7910809151711j36666d8cx56a570b19fe6fd32@mail.gmail.com> Message-ID: <1221524507.2102.11.camel@luminos.localdomain> On Mon, 2008-09-15 at 16:11 -0800, Jeff Spaleta wrote: > hmm not part of any established development group...that seems like an > oversight. > So it was being special cased before? It wasn't a special case per se, it was just dragged in by my "kernel*" entry. Around December I made that more fine grained as to avoid kernel-debug(info) and the like. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From seandarcy2 at gmail.com Tue Sep 16 00:48:03 2008 From: seandarcy2 at gmail.com (sean darcy) Date: Mon, 15 Sep 2008 20:48:03 -0400 Subject: Non-X text mode console In-Reply-To: References: <20080915151812.0730561B48E@hormel.redhat.com> Message-ID: David A. Wheeler wrote: > I routinely use text mode console without X, for a > variety of reasons. For example: > * I have a number of systems (servers) at runlevel 3 > * console is critically important when X fails. "Log in with ssh" > doesn't work when ssh or the network fails. Have I missed something...big? If I can't ssh into those boxes, can't I have someone just use the console in person? Some of these boxes are ooold - 600mhz 256mb, which BTW, works superbly at runlevel 3. X would be a real strain, and is generally not even installed. Tell me it ain't so. sean From skvidal at fedoraproject.org Tue Sep 16 00:54:12 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 15 Sep 2008 20:54:12 -0400 Subject: Boot speedup with readahead In-Reply-To: <1221520313.16310.26.camel@code.and.org> References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <20080911090752.GC17152@mokona.greysector.net> <1221129185.18327.181.camel@beck.corsepiu.local> <1221457688.6122.23.camel@localhost.localdomain> <48CDFD37.8080702@behdad.org> <1221479676.25056.18.camel@rosebud> <48CE9522.2010308@behdad.org> <1221520313.16310.26.camel@code.and.org> Message-ID: <1221526452.25056.63.camel@rosebud> On Mon, 2008-09-15 at 19:11 -0400, James Antill wrote: > On Mon, 2008-09-15 at 13:02 -0400, Behdad Esfahbod wrote: > > > The question is: if one could throw RPM away and design a new one, could one > > do significantly better? > > Of course one could, the relevant question is _how long_ would it take. > And could it be done faster by just fixing rpm, and I've not seen any > compelling arguments that it would be faster to throw away what we have. > > It is also wide believed as true in the software field that "re-write > from scratch" is a last resort, and will always take longer and be more > expensive etc. > There are cases where the subset of problems people care about is > smaller than those solved by the original program, "everyone" dislikes > the original program and a small group of good programmers are willing > to spend/invest a _lot_ of time to create a replacement. But I can only > think of a handful of examples here, and there's a reason for that. > > > Lets look back at the problem at hand: we all agree that custom-installed > > glob-matched post-transaction triggers are useful things. I think I can also > > say that we agree that it should be in the lowest-level package management > > system. What has been up to debate so far is whether that lowest-level is > > RPM, or that RPM is a lost case and yum is considered the lowest-level. > > That is a severe mis-reading of the discussion, the question is given > that rpm+yum are currently how all Fedora users manage their system. Do > we want to still require that all packaging problems should be solved at > the rpm layer, or should we try to move up and allow some more of the > problems to be solved at the yum layer. > There are many advantages to doing this, including just plain ease of > implementation. The only real disadvantage is that apt/smart/zypp/etc. > will become even more of a second class citizen in Fedora than they > already are (although I'm confident that the change proposed by Seth > could easily be ported to work in all of the above). > s/easily/trivially/ it's a colon-delimited file format with pretty simple rules. -sv From csnook at redhat.com Tue Sep 16 00:58:09 2008 From: csnook at redhat.com (Chris Snook) Date: Mon, 15 Sep 2008 20:58:09 -0400 Subject: kernel-devel in "Fedora" spin? In-Reply-To: <1221522171.2102.6.camel@luminos.localdomain> References: <1221522171.2102.6.camel@luminos.localdomain> Message-ID: <48CF04A1.7020801@redhat.com> Jesse Keating wrote: > Back in December, I had made a change that blocked kernel-devel packages > from winding up in the install media for the Fedora spin. I don't > recall getting any push back at the time, but I've gotten at least one > angry comment since then. So I'm putting it out for more discussion. > Do we feel that the kernel-devel (5~megs) should be in the install > media? Yes please. There's always new hardware we don't support yet, so some people will need to build drivers just to get online and access the repos. If we ship it on the install media, it's much easier to distribute code that you're reasonably confident will work on a new install. If people have to hunt down matching kernel and kernel-devel rpms, it's a moving target for people working on these device drivers. I'm not saying we should bend over backwards for out-of-tree drivers, but this is precisely the scenario that determines the first impression for someone trying this "Linux" thing on their shiny new bleeding-edge box, and it's pretty easy to accomodate. -- Chris From csnook at redhat.com Tue Sep 16 01:05:22 2008 From: csnook at redhat.com (Chris Snook) Date: Mon, 15 Sep 2008 21:05:22 -0400 Subject: Non-X text mode console In-Reply-To: References: <20080915151812.0730561B48E@hormel.redhat.com> Message-ID: <48CF0652.5080208@redhat.com> sean darcy wrote: > David A. Wheeler wrote: >> I routinely use text mode console without X, for a >> variety of reasons. For example: >> * I have a number of systems (servers) at runlevel 3 >> * console is critically important when X fails. "Log in with ssh" >> doesn't work when ssh or the network fails. > > Have I missed something...big? If I can't ssh into those boxes, can't I > have someone just use the console in person? Some of these boxes are > ooold - 600mhz 256mb, which BTW, works superbly at runlevel 3. X would > be a real strain, and is generally not even installed. > > Tell me it ain't so. > > sean > It ain't so. This is a gross misunderstanding of the fact that we're moving to using a kernel framebuffer by default, like some distros did almost a decade ago. And you can opt out with 'nomodeset' on the boot command line, to get the old vga BIOS framebuffer. -- Chris From ivazqueznet at gmail.com Tue Sep 16 01:15:42 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Mon, 15 Sep 2008 21:15:42 -0400 Subject: mx and pyOpenSSL - Heads up to rebuild! In-Reply-To: <1221520769.23024.9.camel@PB3.Linux> References: <1221520769.23024.9.camel@PB3.Linux> Message-ID: <1221527742.27649.23.camel@ignacio.lan> On Tue, 2008-09-16 at 00:19 +0100, Paul wrote: > If you are a packager for one of the following, please download the mx > src.rpm and do a local build from it and then recompile your apps. Err, what? Python doesn't work *quite* the same way. Check for SRPMs requiring the -devel subpackages. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Tue Sep 16 01:24:41 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 15 Sep 2008 21:24:41 -0400 Subject: Beware: External repos can break key transition In-Reply-To: <1221158197.6431.24.camel@localhost.localdomain> References: <1221158197.6431.24.camel@localhost.localdomain> Message-ID: <48CF0AD9.6040506@redhat.com> BTW, I just thought of a horribly ugly but automatic working solution to this problem: Filter the require on "xine-lib(plugin-abi) = 1.24" from that package. This sucks, but at least yum update will upgrade to the latest N-V-R packages in both repos so this doesn't exactly break anything. Warren From skvidal at fedoraproject.org Tue Sep 16 01:30:52 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 15 Sep 2008 21:30:52 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1221516162.3629.26.camel@luminos.localdomain> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <1221516162.3629.26.camel@luminos.localdomain> Message-ID: <1221528652.25056.66.camel@rosebud> On Mon, 2008-09-15 at 15:02 -0700, Jesse Keating wrote: > On Mon, 2008-09-15 at 16:59 +0200, Ralf Corsepius wrote: > > I regret having to state this, but I have been thinking Fedora has quit > > being a "general purpose distro" for quite a while. > > More to the point, the only large active group trying to move things > forward for Fedora are those that care about the Desktop experience, > ergo those are the directions Fedora is going in. It's a serve yourself > kind of project, it is what you make of it. > I think you're begging the question. Ralf is saying that the changes the desktop teams wants to make are not FORWARD. They are in a direction that is sub-optimal for various things. And to be fair a lot of other people who do things with fedora don't require large changes for that to happen. The folks providing functional daemons, for example, they don't need much more than a quasi-stable base to run on. -sv From pemboa at gmail.com Tue Sep 16 01:35:48 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 15 Sep 2008 20:35:48 -0500 Subject: Non-X text mode console In-Reply-To: <48CF0652.5080208@redhat.com> References: <20080915151812.0730561B48E@hormel.redhat.com> <48CF0652.5080208@redhat.com> Message-ID: <16de708d0809151835q1daf91ebn8e5b94be2a5548cf@mail.gmail.com> On Mon, Sep 15, 2008 at 8:05 PM, Chris Snook wrote: > sean darcy wrote: >> >> David A. Wheeler wrote: >>> >>> I routinely use text mode console without X, for a >>> variety of reasons. For example: >>> * I have a number of systems (servers) at runlevel 3 >>> * console is critically important when X fails. "Log in with ssh" >>> doesn't work when ssh or the network fails. >> >> Have I missed something...big? If I can't ssh into those boxes, can't I >> have someone just use the console in person? Some of these boxes are ooold - >> 600mhz 256mb, which BTW, works superbly at runlevel 3. X would be a real >> strain, and is generally not even installed. >> >> Tell me it ain't so. >> >> sean >> > > It ain't so. This is a gross misunderstanding of the fact that we're moving > to using a kernel framebuffer by default, like some distros did almost a > decade ago. And you can opt out with 'nomodeset' on the boot command line, > to get the old vga BIOS framebuffer. Sorry for acting dumb, but I'll ask the question that I have: Will I be able to do Ctrl+Alt+F1? And will I be able to use a machine locally without X? -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From jwboyer at gmail.com Tue Sep 16 02:07:42 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Mon, 15 Sep 2008 22:07:42 -0400 Subject: kernel-devel in "Fedora" spin? In-Reply-To: <48CF04A1.7020801@redhat.com> References: <1221522171.2102.6.camel@luminos.localdomain> <48CF04A1.7020801@redhat.com> Message-ID: <20080916020742.GA11480@yoda.jdub.homelinux.org> On Mon, Sep 15, 2008 at 08:58:09PM -0400, Chris Snook wrote: > Jesse Keating wrote: >> Back in December, I had made a change that blocked kernel-devel packages >> from winding up in the install media for the Fedora spin. I don't >> recall getting any push back at the time, but I've gotten at least one >> angry comment since then. So I'm putting it out for more discussion. >> Do we feel that the kernel-devel (5~megs) should be in the install >> media? > > Yes please. There's always new hardware we don't support yet, so some > people will need to build drivers just to get online and access the > repos. If we ship it on the install media, it's much easier to > distribute code that you're reasonably confident will work on a new > install. If people have to hunt down matching kernel and kernel-devel > rpms, it's a moving target for people working on these device drivers. > > I'm not saying we should bend over backwards for out-of-tree drivers, but > this is precisely the scenario that determines the first impression for > someone trying this "Linux" thing on their shiny new bleeding-edge box, > and it's pretty easy to accomodate. Erm... if this is the first time someone is trying a shiny new "Linux" thing on a bleeding edge box, and they have to grab a kernel-devel package and build drivers _themselves_, then they are obviously smart enough to run 'yum install kernel-devel'. Somehow I think your example is slightly off. I don't know many Linux newbies that know 1) that they need to build a driver, 2) what driver to build, and 3) what packages they need to build it all without knowing how to install anything. These are not the people you are targeting. They know enough to not require kernel-devel on the install media. You can move on to finding some other use case that makes sense. josh From seandarcy2 at gmail.com Tue Sep 16 02:24:01 2008 From: seandarcy2 at gmail.com (sean darcy) Date: Mon, 15 Sep 2008 22:24:01 -0400 Subject: Non-X text mode console In-Reply-To: <48CF0652.5080208@redhat.com> References: <20080915151812.0730561B48E@hormel.redhat.com> <48CF0652.5080208@redhat.com> Message-ID: Chris Snook wrote: > sean darcy wrote: >> David A. Wheeler wrote: >>> I routinely use text mode console without X, for a >>> variety of reasons. For example: >>> * I have a number of systems (servers) at runlevel 3 >>> * console is critically important when X fails. "Log in with ssh" >>> doesn't work when ssh or the network fails. >> >> Have I missed something...big? If I can't ssh into those boxes, can't >> I have someone just use the console in person? Some of these boxes are >> ooold - 600mhz 256mb, which BTW, works superbly at runlevel 3. X would >> be a real strain, and is generally not even installed. >> >> Tell me it ain't so. >> >> sean >> > > It ain't so. This is a gross misunderstanding of the fact that we're > moving to using a kernel framebuffer by default, like some distros did > almost a decade ago. And you can opt out with 'nomodeset' on the boot > command line, to get the old vga BIOS framebuffer. > > -- Chris > So if I have a box set to runlevel 3 without any kernel parameters, what's on the monitor? Nothing? How do I tell a tech to get to grub.conf and change the kernel parameter? ( I can imagine this phone call!) Or does the tech reboot ( hard, ctl-alt-del? ) and edit from the grub screen? Or does the kernel framebuffer display on the monitor? If so, that's fine. I don't care about fonts or pretty colors. A simple command line is OK. sean From bruno at wolff.to Tue Sep 16 02:43:51 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Mon, 15 Sep 2008 21:43:51 -0500 Subject: Fedora not "free" enough for GNU? In-Reply-To: <48CDA55D.8010104@gdt.id.au> References: <8553.1220772699@sss.pgh.pa.us> <48C4317B.9050203@redhat.com> <20080908041233.GB28412@wolff.to> <20080908124949.GC28688@file.rdu.redhat.com> <48CDA55D.8010104@gdt.id.au> Message-ID: <20080916024351.GA9785@wolff.to> On Mon, Sep 15, 2008 at 09:29:25 +0930, Glen Turner wrote: > > Given the attractiveness of Skype interception to non-US intelligence > agencies, I can't imagine the US government would be too happy with > Skype offering interception services to most non-US governments. The kind of people the U.S. Government cares about securing are going to know enough not to use Skype. They probably prefer most people prefering Skype to a true peer to peer solution which would be much more of a pain for them to track. From a.badger at gmail.com Tue Sep 16 02:46:27 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 15 Sep 2008 19:46:27 -0700 Subject: Unstripped .so files in python packages In-Reply-To: <1221521320.23024.10.camel@PB3.Linux> References: <1221520358.23024.3.camel@PB3.Linux> <48CEEEEB.7020009@gmail.com> <1221521320.23024.10.camel@PB3.Linux> Message-ID: <48CF1E03.8070000@gmail.com> Paul wrote: > Hi Toshio, > >> They should be detected and stripped by rpmbuild. If the sources are >> checked in I can take a look. > > The srpm is at pfj.fedorapeople.org - not sure why rpmbuild is not > stripping them or why it's generating a debug_package when I've told it > not to! > That's part of the problem... you want to have a debug package in this case. Attaching a spec file that cleans a few things up. this needs some commenting on, though. The include files in the old package weren't done very well. It moved headers from things like: %{python_sitearch}/mx/DateTime/mxDateTime/mxh.h => %{_includedir}/mxh.h %{python_sitearch}/mx/BeeBase/mxBeeBase/mxh.h => %{_includedir}/mxh.h That, of course bashes some files. The new code in the spec file places things in: %{_includedir}/mx/DateTime/mxDateTime/mxh.h %{_inlcudedir}/mx/BeeBase/mxBeeBase/mxh.h This is not necessarily the best structure (we could cut out either the DateTime directory or the mxDateTime directory in the above example). It also requires modules that need the headers (for instance, python-psycopg) to define a different directory for the headers in order to compile. -Toshio -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mx.spec URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From rc040203 at freenet.de Tue Sep 16 02:56:05 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 16 Sep 2008 04:56:05 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1221516162.3629.26.camel@luminos.localdomain> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <1221516162.3629.26.camel@luminos.localdomain> Message-ID: <1221533765.18327.670.camel@beck.corsepiu.local> On Mon, 2008-09-15 at 15:02 -0700, Jesse Keating wrote: > On Mon, 2008-09-15 at 16:59 +0200, Ralf Corsepius wrote: > > I regret having to state this, but I have been thinking Fedora has quit > > being a "general purpose distro" for quite a while. > > More to the point, the only large active group trying to move things > forward for Fedora are those that care about the Desktop experience, > ergo those are the directions Fedora is going in. It's a serve yourself > kind of project, it is what you make of it. My view is different: Due to the fact the number of desktop use-cases likely by way outweighs the number of non-desktop use-cases, has caused the Fedora distribution to get infected with designs missing (rsp. ignoring) the demands of non-desktop uses-cases. Overall this has caused the Fedora distro to regress/derail from what once used to be a "general multipurpose distro" into a "single-user desktop distro". Ralf From rc040203 at freenet.de Tue Sep 16 03:14:58 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 16 Sep 2008 05:14:58 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1221528652.25056.66.camel@rosebud> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <1221516162.3629.26.camel@luminos.localdomain> <1221528652.25056.66.camel@rosebud> Message-ID: <1221534898.18327.685.camel@beck.corsepiu.local> On Mon, 2008-09-15 at 21:30 -0400, Seth Vidal wrote: > On Mon, 2008-09-15 at 15:02 -0700, Jesse Keating wrote: > > On Mon, 2008-09-15 at 16:59 +0200, Ralf Corsepius wrote: > > > I regret having to state this, but I have been thinking Fedora has quit > > > being a "general purpose distro" for quite a while. > > > > More to the point, the only large active group trying to move things > > forward for Fedora are those that care about the Desktop experience, > > ergo those are the directions Fedora is going in. It's a serve yourself > > kind of project, it is what you make of it. > > > > I think you're begging the question. > > Ralf is saying that the changes the desktop teams wants to make are not > FORWARD. Correct. > They are in a direction that is sub-optimal for various things. Also correct. > And to be fair a lot of other people who do things with fedora don't > require large changes for that to happen. The folks providing functional > daemons, for example, they don't need much more than a quasi-stable base > to run on. Exactly. At least I would not complain, if things "just worked". Unfortunately this doesn't apply. With each Fedora release, I experience things which are advertised as "revolutionary new features/great achievements" to actually worsen my use-cases. Often this is presumably because these new developments did not take into account certain setups'/use-cases' requirements and likely had been designed on single-user-desktops. Ralf From poelstra at redhat.com Tue Sep 16 03:47:54 2008 From: poelstra at redhat.com (John Poelstra) Date: Mon, 15 Sep 2008 20:47:54 -0700 Subject: Fedora 10 feature owners--rescue your unfinished feature pages! Message-ID: <48CF2C6A.303@redhat.com> I'm working to get http://fedoraproject.org/wiki/Releases/10/FeatureList into a near final state. This important for our beta release notes and announcement as well as accurately advertising the features that *will* be in Fedora 10. It is also very important for focusing our testing efforts! According to a review of all the feature pages, the following features have not been updated since the Feature Freeze on 2008-09-11 and/or are not 100% complete. https://fedoraproject.org/wiki/Features/ApplicationInstaller https://fedoraproject.org/wiki/Features/ApplianceTools https://fedoraproject.org/wiki/Features/BetterStartup https://fedoraproject.org/wiki/Features/BetterWebcamSupport https://fedoraproject.org/wiki/Features/Eclipse34 https://fedoraproject.org/wiki/Features/30SecondStartup https://fedoraproject.org/wiki/Features/EFI https://fedoraproject.org/wiki/Features/FirstAidKit https://fedoraproject.org/wiki/Features/GNOME2_24 https://fedoraproject.org/wiki/Features/GoodHaskellSupport https://fedoraproject.org/wiki/Features/HDTVEnhancements https://fedoraproject.org/wiki/Features/KernelModesetting https://fedoraproject.org/wiki/Features/OnlineAccountsService https://fedoraproject.org/wiki/Features/OpenChange https://fedoraproject.org/wiki/Features/RPM4.6 https://fedoraproject.org/wiki/Features/SaveToBugzilla https://fedoraproject.org/wiki/Features/Sugar https://fedoraproject.org/wiki/Features/TimeZoneAndLocation https://fedoraproject.org/wiki/Features/VirtStorage https://fedoraproject.org/wiki/Features/LXDE https://fedoraproject.org/wiki/Features/EchoIconTheme If you believe your feature is substantially complete and testable state for Fedora 10, please perform the following: 1) Update the % complete and "last updated" date 2) In the status section please also include what remains to be completed including your best estimated percentage chance actually doing so. Please complete this as soon as possible so that we can prepare an accurate beta release announcement. FESCo will also be reviewing the complete feature list at its next meeting on Wednesday, September 17, 2008, and determining which incomplete features should remain. If however, you believe your feature is not ready for Fedora 10, that is okay :) It can always be targeted for Fedora 11. If you would like to target your feature for Fedora 11, please change the "Target Release to Fedora 11" and change the wiki page category to "Cateogory:FeatureReadyForWranger". If your feature will not be ready for Fedora 10 and you aren't sure what is going to happen to it: 1) Please change the category of your page to Category:FeaturePageIncomplete 2) Remove Fedora 10 as the targeted release. I have a watch on all the feature page and will remove it from the summary page. Or for a limited time only... email me and I'll unwind everything for you :) Thank you for your help, John _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From fedora at leemhuis.info Tue Sep 16 05:14:22 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 16 Sep 2008 07:14:22 +0200 Subject: Beware: External repos can break key transition In-Reply-To: <48CF0AD9.6040506@redhat.com> References: <1221158197.6431.24.camel@localhost.localdomain> <48CF0AD9.6040506@redhat.com> Message-ID: <48CF40AE.8080006@leemhuis.info> On 16.09.2008 03:24, Warren Togami wrote: > BTW, I just thought of a horribly ugly but automatic working solution to > this problem: Filter the require on "xine-lib(plugin-abi) = 1.24" from > that package. > > This sucks, but at least yum update will upgrade to the latest N-V-R > packages in both repos so this doesn't exactly break anything. It breaks for some times: let's say xine-lib (Fedora) and xine-lib-extras-nonfree (Livna) get both pushed to their repos at round about the same time (like it was the case for the recent packages). Then there is a time window that's afaics round about somewhat between 24 and 36 hours long(?) where yum on the user's system might chose to use the livna master repo (or a up2date livna mirror) and a Fedora mirror that's not up to date. Thus yum will install the new xine-lib-extras-nonfree from Livna, but not the matching xine-lib from Fedora. Thus all apps that rely on xine will silently stop playing some videos that they were able to play beforehand. I'd call that breakage ;-) A breakage that IMHO is not acceptable, as users won't know what's up and might file bugs. CU knurd (?) time configured in yum for metadata_expire + time until mirrormanager stops pointing yum to mirrors that don't ship xine-lib; manually configured mirror that are out of date will make things worse From rc040203 at freenet.de Tue Sep 16 06:08:37 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 16 Sep 2008 08:08:37 +0200 Subject: NetworkworkManger and network based filesystem /usr In-Reply-To: <48CE8212.40009@redhat.com> References: <48CAAF49.3090105@hhs.nl> <20080912181213.GA3270@nostromo.devel.redhat.com> <48CAB296.80101@redhat.com> <200809150323.m8F3NnVG015326@laptop14.inf.utfsm.cl> <48CE8212.40009@redhat.com> Message-ID: <1221545317.18327.726.camel@beck.corsepiu.local> On Mon, 2008-09-15 at 09:41 -0600, Jeff Law wrote: > Horst H. von Brand wrote: > > Jeff Law wrote: > > > > [...] > > > > > >> It must die die die. We're far better off making root filesystems > >> sharable and readonly. > >> > > > > /etc at the very least is a /intensely/ personal issue for each machine... > > We had local / and shared /usr and so on for ages under assorted Unices > > here, and then for Linux. True, today disks are much cheaper; but old > > habits are long in dying. > > > union filesystems are the answer for those (very few) items in /etc > which are not sharable. ?!? I am confused by this answer. /etc reflects a machine's local configuration, i.e. most in /etc/ is not shareable. Or conversely: Those files in /etc/ which are shareable, likely should not be in /etc. Ralf From law at redhat.com Tue Sep 16 07:22:23 2008 From: law at redhat.com (Jeff Law) Date: Tue, 16 Sep 2008 01:22:23 -0600 Subject: NetworkworkManger and network based filesystem /usr In-Reply-To: <1221545317.18327.726.camel@beck.corsepiu.local> References: <48CAAF49.3090105@hhs.nl> <20080912181213.GA3270@nostromo.devel.redhat.com> <48CAB296.80101@redhat.com> <200809150323.m8F3NnVG015326@laptop14.inf.utfsm.cl> <48CE8212.40009@redhat.com> <1221545317.18327.726.camel@beck.corsepiu.local> Message-ID: <48CF5EAF.4090001@redhat.com> Ralf Corsepius wrote: > > ?!? I am confused by this answer. > > /etc reflects a machine's local configuration, > i.e. most in /etc/ is not shareable. > > Or conversely: Those files in /etc/ which are shareable, likely should > not be in /etc. > > Ralf > > Most of /etc is sharable in my experience, this is particularly true in clusters and anywhere there's a reasonably run IT department that realizes that their time is not well spent if the ratio of machines to configurations is small on the machines they maintain. The non-sharable hunks fall into two broad categories. 1. Persistent -- host SSH keys and the like 2. Non-persistent -- /etc/mtab and its friends. The nature of atomic file updates in unix systems is such that you need a r/w union overlay for /etc itself. That overlay is backed by a temporary filesystem. The few persistent bits are most easily handled by bind mounting the appropriate files/directories to persistent storage. Jeff From nicolas.mailhot at laposte.net Tue Sep 16 07:35:33 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 16 Sep 2008 09:35:33 +0200 (CEST) Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <48CEDEB1.2080000@gmail.com> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <1221516162.3629.26.camel@luminos.localdomain> <48CEDEB1.2080000@gmail.com> Message-ID: <07384cf048cc830a21eeb16bf6fd35a8.squirrel@rousalka.dyndns.org> Le Mar 16 septembre 2008 00:16, Les Mikesell a ?crit : > > Jesse Keating wrote: >> On Mon, 2008-09-15 at 16:59 +0200, Ralf Corsepius wrote: >>> I regret having to state this, but I have been thinking Fedora has >>> quit >>> being a "general purpose distro" for quite a while. >> >> More to the point, the only large active group trying to move things >> forward for Fedora are those that care about the Desktop experience, >> ergo those are the directions Fedora is going in. It's a serve >> yourself >> kind of project, it is what you make of it. > > I don't think you can call it 'moving forward' if it breaks the things > that have been the most useful about Linux so far. Nevertheless this group tries at least to do stuff, and the counter-proposals are too often "do nothing". -- Nicolas Mailhot From mike.cloaked at gmail.com Tue Sep 16 07:43:02 2008 From: mike.cloaked at gmail.com (Mike) Date: Tue, 16 Sep 2008 07:43:02 +0000 (UTC) Subject: New repo directories on http://download.fedora.redhat.com ??? References: <5f6f8c5f0809151657s222ea376hc5af72e8a9b212a9@mail.gmail.com> <1221523281.2102.8.camel@luminos.localdomain> Message-ID: Jesse Keating redhat.com> writes: > Process problem. .newkey.newkey will be going away, .newkey should have > never gone away. If you saw it go away, something different went wrong. Seems that the directory http://download.fedora.redhat.com/pub/fedora/linux/updates/8/i386.newkey and related have vanished! From mcepl at redhat.com Tue Sep 16 08:02:24 2008 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 16 Sep 2008 10:02:24 +0200 Subject: scratch-build on untagged code [Was: Re: Proposal: Better force-tag] References: <1220955240.24928.69.camel@cookie.hadess.net> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> <48CA16D1.5070409@redhat.com> <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> <1221234383.15726.194.camel@localhost.localdomain> <48CD1CA3.5060302@redhat.com> <1221402590.27183.172.camel@ignacio.lan> <48CD3358.8060105@poolshark.org> <1221409389.24484.1.camel@truman> <1221502515.1927.385.camel@firewall.xsintricity.com> <20080915135119.1a191264@ohm.scrye.com> <1221511756.1927.419.camel@firewall.xsintricity.com> Message-ID: On 2008-09-15, 20:49 GMT, Doug Ledford wrote: > I *could* do an srpm build to test ppc/ppc64 kernel builds, but > it takes 30 minutes for a kernel srpm to upload to the build > system from here (admittedly, I do this on my rhel kernel > builds, I haven't been messing with Fedora kernels, but the > point is valid regardless), so I commit, tag, build, fix, > force-tag, build, fix, etc. I don't want to immerse myself into this discussion (which I haven't heard and read before), but this looks like bad workaround around stupid problem. The problem here is IMHO that koji is apparently not able to make a scratch build from untagged (but commited) code. Why? This is a thing I really hate myself, but fortunately (for me) none of the packages I want to build has size which would make it too difficult just to make srpm; koji build --scratch *.src.rpm Isn't there a better solution for this? Mat?j From mcepl at redhat.com Tue Sep 16 08:25:15 2008 From: mcepl at redhat.com (Matej Cepl) Date: Tue, 16 Sep 2008 10:25:15 +0200 Subject: Version of Postfix in Fedora not kept up to date References: <11.14-31640-1558071764-1221486607@seznam.cz> <48CE7417.70903@enlartenment.com> Message-ID: On 2008-09-15, 14:41 GMT, Michael Fleming wrote: > Michael > (Postfix user, mostly rolling my own packages for it though :-)) Why? Couldn't finally something be done about less-than-perfect maintained postfix in Red Hat related distributions? Seven years ago not-really-resolved bug 57137 was the last straw which pushed me to Debian, currently I don't have choice of using distro, so bug 215722 (with duplicate in bug 220295) switched me just back to sendmail, although I believe that postfix would be much better piece of software if properly maintained. Did you try to contact Thomas to help him maintain postfix? What are the problems which make you to use your own builds? Best, Mat?j From kzak at redhat.com Tue Sep 16 08:42:24 2008 From: kzak at redhat.com (Karel Zak) Date: Tue, 16 Sep 2008 10:42:24 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1221516162.3629.26.camel@luminos.localdomain> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <1221516162.3629.26.camel@luminos.localdomain> Message-ID: <20080916084224.GA28147@nb.net.home> On Mon, Sep 15, 2008 at 03:02:42PM -0700, Jesse Keating wrote: > More to the point, the only large active group trying to move things > forward for Fedora are those that care about the Desktop experience, I guess that the large group of kernel, tools and base-os people are very happy to see this conclusion. So.. thanks! :-(( BTW, invisible != inactive. Karel -- Karel Zak From nils at redhat.com Tue Sep 16 08:45:12 2008 From: nils at redhat.com (Nils Philippsen) Date: Tue, 16 Sep 2008 10:45:12 +0200 Subject: Feature Proposal: Use cases database In-Reply-To: <1221182418.27183.88.camel@ignacio.lan> References: <1220991029.3782.47.camel@choeger6> <1221059648.17299.103.camel@hughsie-work> <1221062578.21306.13.camel@rousalka.okg> <1221064863.17299.134.camel@hughsie-work> <5cb581610364a94649b91d5bc6e50928.squirrel@rousalka.dyndns.org> <1221129641.22654.24.camel@hughsie-work> <1221141890.22654.75.camel@hughsie-work> <1221153724.22654.86.camel@hughsie-work> <16de708d0809111043y6ab64021p9ed49ceba2422fe4@mail.gmail.com> <1221182418.27183.88.camel@ignacio.lan> Message-ID: <1221554712.19134.10.camel@gibraltar.str.redhat.com> On Thu, 2008-09-11 at 21:20 -0400, Ignacio Vazquez-Abrams wrote: > On Thu, 2008-09-11 at 12:43 -0500, Arthur Pemberton wrote: > > On Thu, Sep 11, 2008 at 12:22 PM, Richard Hughes wrote: > > > Cost of me spending 5 minutes setting up clipart for my mum: > > > = ?20 / hour > > > = ?1.67 > > > > I have to say this took me by suprise > > Time is money, regardless of whether or not you're actually charging. Actually I find measuring everything in monetary terms quite silly. By that notion, after raising you, your parents practically own you. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils at redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From kzak at redhat.com Tue Sep 16 08:49:42 2008 From: kzak at redhat.com (Karel Zak) Date: Tue, 16 Sep 2008 10:49:42 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1221528652.25056.66.camel@rosebud> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <1221516162.3629.26.camel@luminos.localdomain> <1221528652.25056.66.camel@rosebud> Message-ID: <20080916084942.GB28147@nb.net.home> On Mon, Sep 15, 2008 at 09:30:52PM -0400, Seth Vidal wrote: > Ralf is saying that the changes the desktop teams wants to make are not > FORWARD. They are in a direction that is sub-optimal for various things. > > And to be fair a lot of other people who do things with fedora don't > require large changes for that to happen. The folks providing functional > daemons, for example, they don't need much more than a quasi-stable base > to run on. Yes. Sane development = Evolution, not revolution. Karel -- Karel Zak From kevin.kofler at chello.at Tue Sep 16 08:54:43 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 16 Sep 2008 08:54:43 +0000 (UTC) Subject: Fedora 10 feature owners--rescue your unfinished feature pages! References: <48CF2C6A.303@redhat.com> Message-ID: John Poelstra redhat.com> writes: > https://fedoraproject.org/wiki/Features/OpenChange This one won't be ready for F10 and it also needs a new owner, see: https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00522.html Therefore, I bumped the targeted release to F11 and kicked it back into Category:FeaturePageIncomplete. Anyone interested in owning this feature should claim ownership and move it into Category:FeatureReadyForWrangler. If nobody is interested in this in a F11 timeframe, we will have to remove the targeted release entirely. It would be a pity though, as kdepim 4.2 will have support for OpenChange and thus I think we should really offer this in Fedora. Kevin Kofler From hughsient at gmail.com Tue Sep 16 09:17:09 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 16 Sep 2008 10:17:09 +0100 Subject: Boot speedup with readahead In-Reply-To: <48CEC66B.2000206@fedoraproject.org> References: <1220886750.987.12.camel@rosebud> <1220887636.5554.37.camel@aglarond.local> <1220905733.6431.9.camel@localhost.localdomain> <1220968297.987.65.camel@rosebud> <48C6B7A7.6090405@behdad.org> <1220983079.987.79.camel@rosebud> <1220995998.987.98.camel@rosebud> <1221070577.987.120.camel@rosebud> <20080911090752.GC17152@mokona.greysector.net> <1221129185.18327.181.camel@beck.corsepiu.local> <1221457688.6122.23.camel@localhost.localdomain> <48CDFD37.8080702@behdad.org> <1221479676.25056.18.camel@rosebud> <48CE9522.2010308@behdad.org> <1221501862.25056.44.camel@rosebud> <1221509854.3906.19.camel@gaara.bos.redhat.com> <48CEC66B.2000206@fedoraproject.org> Message-ID: <1221556629.8166.29.camel@hughsie-work> On Tue, 2008-09-16 at 02:02 +0530, Rahul Sundaram wrote: > Is it in a usable state for day to day work or atleast for testing? I > would like to see it packaged and more easily consumable in that case > atleast for rawhide. I've got local rpms of razor on my system, but I'm not sure they are ready to inflict even on developers yet. Razor is cool to play with and hack on, but I think it needs some more work before it's even ready to release a first version. But, my god, it's quick. Richard. From alan at redhat.com Tue Sep 16 09:28:07 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 16 Sep 2008 05:28:07 -0400 Subject: Non-X text mode console In-Reply-To: <48CEA848.2050005@redhat.com> References: <20080915151812.0730561B48E@hormel.redhat.com> <48CEA848.2050005@redhat.com> Message-ID: <20080916092807.GA22628@shell.devel.redhat.com> > Unless I've missed something huge, virtual terminals aren't going away. > What may or may not be going away is the x86 video BIOS text mode, to be > replaced with a kernel framebuffer, which precludes the use of console > fonts, which very few people ever mess with. The console itself will > remain. Someone please correct me if I'm wrong. Framebuffer consoles support fonts. However they do not work on all machines, they do not work with a lot of screen reader technology and they don't work with many of the remote management cards. Alan From nils at redhat.com Tue Sep 16 09:34:32 2008 From: nils at redhat.com (Nils Philippsen) Date: Tue, 16 Sep 2008 11:34:32 +0200 Subject: The state of resolv.conf In-Reply-To: <1221482647.15427.10.camel@localhost.localdomain> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> Message-ID: <1221557672.19134.15.camel@gibraltar.str.redhat.com> On Mon, 2008-09-15 at 08:44 -0400, Simo Sorce wrote: > On Mon, 2008-09-15 at 09:32 +0200, Ahmed Kamal wrote: > > Wouldn't the best way be to have an api that can be used to add and > > delete DNS servers and manipulate resolv.conf. Then we could have > > deamons call that. > > No what you really need is more than a simple resolv.conf file. > > We need a default caching daemon (which by itself will solve a lot of > other issues) that tools like NM, vpnc, openvpn can interact with. > These tools will tell the caching daemon which IP ranges and which > domains their provided forwarders should be consulted for. All dynamic > so that as soon as one daemon goes away, the caching DNS will notice and > revert queries to the default DNS. And if NM/routes go away it can keep > working out of its cache. Definitely. The current way of modifying resolv.conf sometimes leaves behind the VPN setup (without VPN connection) and is generally unflexible. Ideally, it should be something which isn't restricted to class A/B/C like reverse DNS (seems to be), but which would route DNS requests based on arbitrary domain name or IP-range criteria to the desired name servers. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils at redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From laurent.rineau__fedora at normalesup.org Tue Sep 16 09:41:54 2008 From: laurent.rineau__fedora at normalesup.org (Laurent Rineau) Date: Tue, 16 Sep 2008 11:41:54 +0200 Subject: Non-X text mode console In-Reply-To: References: <20080915151812.0730561B48E@hormel.redhat.com> <48CF0652.5080208@redhat.com> Message-ID: <200809161141.54386@rineau.tsetse> On Tuesday 16 September 2008 04:24:01 sean darcy wrote: > So if I have a box set to runlevel 3 without any kernel parameters, > what's on the monitor? Nothing? A framebuffer showing your usual text mode consoles. Do not worry, that should not change anything for you (unless the default VGA mode is not supported by your graphic card). -- Laurent Rineau http://fedoraproject.org/wiki/LaurentRineau From rc040203 at freenet.de Tue Sep 16 09:45:15 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 16 Sep 2008 11:45:15 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <07384cf048cc830a21eeb16bf6fd35a8.squirrel@rousalka.dyndns.org> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <1221516162.3629.26.camel@luminos.localdomain> <48CEDEB1.2080000@gmail.com> <07384cf048cc830a21eeb16bf6fd35a8.squirrel@rousalka.dyndns.org> Message-ID: <1221558315.18327.751.camel@beck.corsepiu.local> On Tue, 2008-09-16 at 09:35 +0200, Nicolas Mailhot wrote: > > Le Mar 16 septembre 2008 00:16, Les Mikesell a ?crit : > > > > Jesse Keating wrote: > >> On Mon, 2008-09-15 at 16:59 +0200, Ralf Corsepius wrote: > >>> I regret having to state this, but I have been thinking Fedora has > >>> quit > >>> being a "general purpose distro" for quite a while. > >> > >> More to the point, the only large active group trying to move things > >> forward for Fedora are those that care about the Desktop experience, > >> ergo those are the directions Fedora is going in. It's a serve > >> yourself > >> kind of project, it is what you make of it. > > > > I don't think you can call it 'moving forward' if it breaks the things > > that have been the most useful about Linux so far. > > Nevertheless this group tries at least to do stuff, and the > counter-proposals are too often "do nothing". Generally speaking, not referring to your proposal, these counter proposals/critical remarks often are motivated from a) Don't break what's not broken b) A proposal is incomplete and misses to cover essential parts of a problem. c) A proposal is replacing one problem with another one. d) A proposal is naive, silly and dumb. In most cases, it's b) or c). From dominik at greysector.net Tue Sep 16 09:53:17 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 16 Sep 2008 11:53:17 +0200 Subject: scratch-build on untagged code [Was: Re: Proposal: Better force-tag] In-Reply-To: References: <1221234383.15726.194.camel@localhost.localdomain> <48CD1CA3.5060302@redhat.com> <1221402590.27183.172.camel@ignacio.lan> <48CD3358.8060105@poolshark.org> <1221409389.24484.1.camel@truman> <1221502515.1927.385.camel@firewall.xsintricity.com> <20080915135119.1a191264@ohm.scrye.com> <1221511756.1927.419.camel@firewall.xsintricity.com> Message-ID: <20080916095317.GB30868@mokona.greysector.net> On Tuesday, 16 September 2008 at 10:02, Matej Cepl wrote: > On 2008-09-15, 20:49 GMT, Doug Ledford wrote: > > I *could* do an srpm build to test ppc/ppc64 kernel builds, but > > it takes 30 minutes for a kernel srpm to upload to the build > > system from here (admittedly, I do this on my rhel kernel > > builds, I haven't been messing with Fedora kernels, but the > > point is valid regardless), so I commit, tag, build, fix, > > force-tag, build, fix, etc. > > I don't want to immerse myself into this discussion (which > I haven't heard and read before), but this looks like bad > workaround around stupid problem. The problem here is IMHO that > koji is apparently not able to make a scratch build from untagged > (but commited) code. Wrong. You can use the tag "HEAD". Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann Livna http://rpm.livna.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From seg at haxxed.com Tue Sep 16 10:01:29 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 16 Sep 2008 05:01:29 -0500 Subject: The state of resolv.conf In-Reply-To: <1221482647.15427.10.camel@localhost.localdomain> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> Message-ID: <1221559289.8461.1.camel@localhost.localdomain> On Mon, 2008-09-15 at 08:44 -0400, Simo Sorce wrote: > On Mon, 2008-09-15 at 09:32 +0200, Ahmed Kamal wrote: > > Wouldn't the best way be to have an api that can be used to add and > > delete DNS servers and manipulate resolv.conf. Then we could have > > deamons call that. > > No what you really need is more than a simple resolv.conf file. > > We need a default caching daemon (which by itself will solve a lot of > other issues) that tools like NM, vpnc, openvpn can interact with. > These tools will tell the caching daemon which IP ranges and which > domains their provided forwarders should be consulted for. All dynamic > so that as soon as one daemon goes away, the caching DNS will notice and > revert queries to the default DNS. And if NM/routes go away it can keep > working out of its cache. Might this daemon be called dnsmasq? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From paul at city-fan.org Tue Sep 16 10:05:41 2008 From: paul at city-fan.org (Paul Howarth) Date: Tue, 16 Sep 2008 11:05:41 +0100 Subject: The state of resolv.conf In-Reply-To: <1221557672.19134.15.camel@gibraltar.str.redhat.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221557672.19134.15.camel@gibraltar.str.redhat.com> Message-ID: <48CF84F5.3010701@city-fan.org> Nils Philippsen wrote: > On Mon, 2008-09-15 at 08:44 -0400, Simo Sorce wrote: >> On Mon, 2008-09-15 at 09:32 +0200, Ahmed Kamal wrote: >>> Wouldn't the best way be to have an api that can be used to add and >>> delete DNS servers and manipulate resolv.conf. Then we could have >>> deamons call that. >> No what you really need is more than a simple resolv.conf file. >> >> We need a default caching daemon (which by itself will solve a lot of >> other issues) that tools like NM, vpnc, openvpn can interact with. >> These tools will tell the caching daemon which IP ranges and which >> domains their provided forwarders should be consulted for. All dynamic >> so that as soon as one daemon goes away, the caching DNS will notice and >> revert queries to the default DNS. And if NM/routes go away it can keep >> working out of its cache. > > Definitely. The current way of modifying resolv.conf sometimes leaves > behind the VPN setup (without VPN connection) and is generally > unflexible. Ideally, it should be something which isn't restricted to > class A/B/C like reverse DNS (seems to be), but which would route DNS > requests based on arbitrary domain name or IP-range criteria to the > desired name servers. Another problem with modifying resolv.conf is that most processes only read it once, usually shortly after starting up, so any changes that happen after that don't get picked up by existing processes. So for instance you could have a web browser that couldn't resolve names from a VPN tunnel that had been brought up after the browser had been started. Paul. From luya_tfz at thefinalzone.com Tue Sep 16 10:19:22 2008 From: luya_tfz at thefinalzone.com (Luya Tshimbalanga) Date: Tue, 16 Sep 2008 06:19:22 -0400 Subject: Fedora 10 feature owners--rescue your unfinished feature pages! In-Reply-To: <48CF2C6A.303@redhat.com> References: <48CF2C6A.303@redhat.com> Message-ID: <1221560362.48cf882a76ef9@ssl.mecca.ca> Quoting John Poelstra : > https://fedoraproject.org/wiki/Features/EchoIconTheme Current status was updated on 2008-08-11. I have recently added status to reflect the progress on echo-icon-theme. Do we need to add release note to tell echo is the current default icon set? -- Luya Tshimbalanga Fedora Project contributor http://www.fedoraproject.org/wiki/LuyaTshimbalanga From nils at redhat.com Tue Sep 16 11:09:51 2008 From: nils at redhat.com (Nils Philippsen) Date: Tue, 16 Sep 2008 13:09:51 +0200 Subject: Proposal: Better force-tag In-Reply-To: <48CEC58A.3060009@gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> <48CA16D1.5070409@redhat.com> <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> <1221234383.15726.194.camel@localhost.localdomain> <48CD1CA3.5060302@redhat.com> <1221402590.27183.172.camel@ignacio.lan> <48CD3358.8060105@poolshark.org> <1221409389.24484.1.camel@truman> <1221502515.1927.385.camel@firewall.xsintricity.com> <20080915135119.1a191264@ohm.scrye.com> <48CEC58A.3060009@gmail.com> Message-ID: <1221563391.19134.34.camel@gibraltar.str.redhat.com> On Mon, 2008-09-15 at 13:28 -0700, Toshio Kuratomi wrote: > 1) In what situations can things be broken with force-tags? (ie: is it > just when force tagging a successfully completed build? Are completed > failed builds okay? What happens if a retag occurs on an in-progress > build?) This is maybe the point where prohibiting tagging with existing tags makes sense: if there is an ongoing build of that tag or a successfully finished one. From my armchair POV, it should be technically possible to let CVS check for this and only prohibit tagging with a specific tag if one of these conditions is given. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils at redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From choeger at cs.tu-berlin.de Tue Sep 16 11:08:25 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 16 Sep 2008 13:08:25 +0200 Subject: standby and cd discovery Message-ID: <1221563305.21005.12.camel@choeger6> Hi, I assume this is a bug (or a _really_ annoying feature): Whenever I put my thinkpad to sleep (standby), with a cd in the drive and resume, that cd pops up as a folder as if I inserted it. Thats annoying. After the third standby/resume cycle I _know_ whats on that disc! Does anyone know if this is _really_ a bug or how to fix it (if its fixable it should propably be fixed in the release version)? thank you christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From nils at redhat.com Tue Sep 16 11:16:27 2008 From: nils at redhat.com (Nils Philippsen) Date: Tue, 16 Sep 2008 13:16:27 +0200 Subject: scratch-build on untagged code [Was: Re: Proposal: Better force-tag] In-Reply-To: <20080916095317.GB30868@mokona.greysector.net> References: <1221234383.15726.194.camel@localhost.localdomain> <48CD1CA3.5060302@redhat.com> <1221402590.27183.172.camel@ignacio.lan> <48CD3358.8060105@poolshark.org> <1221409389.24484.1.camel@truman> <1221502515.1927.385.camel@firewall.xsintricity.com> <20080915135119.1a191264@ohm.scrye.com> <1221511756.1927.419.camel@firewall.xsintricity.com> <20080916095317.GB30868@mokona.greysector.net> Message-ID: <1221563787.19134.39.camel@gibraltar.str.redhat.com> On Tue, 2008-09-16 at 11:53 +0200, Dominik 'Rathann' Mierzejewski wrote: > On Tuesday, 16 September 2008 at 10:02, Matej Cepl wrote: > > On 2008-09-15, 20:49 GMT, Doug Ledford wrote: > > > I *could* do an srpm build to test ppc/ppc64 kernel builds, but > > > it takes 30 minutes for a kernel srpm to upload to the build > > > system from here (admittedly, I do this on my rhel kernel > > > builds, I haven't been messing with Fedora kernels, but the > > > point is valid regardless), so I commit, tag, build, fix, > > > force-tag, build, fix, etc. > > > > I don't want to immerse myself into this discussion (which > > I haven't heard and read before), but this looks like bad > > workaround around stupid problem. The problem here is IMHO that > > koji is apparently not able to make a scratch build from untagged > > (but commited) code. > > Wrong. You can use the tag "HEAD". Which doesn't help you if somebody else is concurrently working on the same package and checks in things while you're waiting for your scratch build. We could use "scratch-tags", but I find this a bit silly. IMO, this is rather a point where using an SCM with a repo-wide revision-id (instead of a per file one as used by CVS) would help. Who again was looking for use-cases for different SCMs ;-)? Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils at redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nils at redhat.com Tue Sep 16 11:19:19 2008 From: nils at redhat.com (Nils Philippsen) Date: Tue, 16 Sep 2008 13:19:19 +0200 Subject: The state of resolv.conf In-Reply-To: <48CF84F5.3010701@city-fan.org> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221557672.19134.15.camel@gibraltar.str.redhat.com> <48CF84F5.3010701@city-fan.org> Message-ID: <1221563959.19134.43.camel@gibraltar.str.redhat.com> On Tue, 2008-09-16 at 11:05 +0100, Paul Howarth wrote: > Another problem with modifying resolv.conf is that most processes only > read it once, usually shortly after starting up, so any changes that > happen after that don't get picked up by existing processes. So for > instance you could have a web browser that couldn't resolve names from a > VPN tunnel that had been brought up after the browser had been started. Which is a bug IMO. If applications don't use the glibc supplied functions for name-resolving, they should at least reinvent the wheel properly and check for changes to resolv.conf. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils at redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nils at redhat.com Tue Sep 16 11:21:11 2008 From: nils at redhat.com (Nils Philippsen) Date: Tue, 16 Sep 2008 13:21:11 +0200 Subject: standby and cd discovery In-Reply-To: <1221563305.21005.12.camel@choeger6> References: <1221563305.21005.12.camel@choeger6> Message-ID: <1221564071.19134.47.camel@gibraltar.str.redhat.com> On Tue, 2008-09-16 at 13:08 +0200, Christoph H?ger wrote: > Hi, > > I assume this is a bug (or a _really_ annoying feature): > > Whenever I put my thinkpad to sleep (standby), with a cd in the drive > and resume, that cd pops up as a folder as if I inserted it. > Thats annoying. After the third standby/resume cycle I _know_ whats on > that disc! > Does anyone know if this is _really_ a bug or how to fix it (if its > fixable it should propably be fixed in the release version)? I would say this is a bug. Suspending a machine should just "pause" the system and the behaviour afterwards should be the same as if you hadn't suspended the machine at all. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils at redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From hun at n-dimensional.de Tue Sep 16 11:32:37 2008 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Tue, 16 Sep 2008 13:32:37 +0200 Subject: standby and cd discovery In-Reply-To: <1221564071.19134.47.camel@gibraltar.str.redhat.com> References: <1221563305.21005.12.camel@choeger6> <1221564071.19134.47.camel@gibraltar.str.redhat.com> Message-ID: <48CF9955.1010400@n-dimensional.de> Nils Philippsen wrote: > On Tue, 2008-09-16 at 13:08 +0200, Christoph H?ger wrote: >> Whenever I put my thinkpad to sleep (standby), with a cd in the drive >> and resume, that cd pops up as a folder as if I inserted it. >> Thats annoying. After the third standby/resume cycle I _know_ whats on >> that disc! >> Does anyone know if this is _really_ a bug or how to fix it (if its >> fixable it should propably be fixed in the release version)? > > I would say this is a bug. Suspending a machine should just "pause" the > system and the behaviour afterwards should be the same as if you hadn't > suspended the machine at all. Not in all respects. A common usecase is you sit at place A connected to WLAN A, suspend the box, move it, and resume it at place B. It does not make sense now to try sending to WLAN A for a minute (which feels like an eternity), and only then consider that we might want to look for other WLANs or wired LANs to connect to. You'd want the resume to trigger action much more quickly. In the case of storage media and media drives however, I'd guess there should be unique drive and medium/filesystem identifiers somewhere which, when they are discovered to be the same after the resume as before the suspend, could easily just prevent the medium from being detected as "new". -- Hans Ulrich Niedermann -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From email.ahmedkamal at googlemail.com Tue Sep 16 11:34:06 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Tue, 16 Sep 2008 13:34:06 +0200 Subject: The state of resolv.conf In-Reply-To: <1221563959.19134.43.camel@gibraltar.str.redhat.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221557672.19134.15.camel@gibraltar.str.redhat.com> <48CF84F5.3010701@city-fan.org> <1221563959.19134.43.camel@gibraltar.str.redhat.com> Message-ID: <3da3b5b40809160434j12a23896k9123a1724d108913@mail.gmail.com> Is there any current daemon that does this effect of directing name resolution to specific servers according to IP ranges and/or domain names, with the option of adding/removing servers on the fly ? Does dnsmasq do that ? On Tue, Sep 16, 2008 at 1:19 PM, Nils Philippsen wrote: > On Tue, 2008-09-16 at 11:05 +0100, Paul Howarth wrote: > > > Another problem with modifying resolv.conf is that most processes only > > read it once, usually shortly after starting up, so any changes that > > happen after that don't get picked up by existing processes. So for > > instance you could have a web browser that couldn't resolve names from a > > VPN tunnel that had been brought up after the browser had been started. > > Which is a bug IMO. If applications don't use the glibc supplied > functions for name-resolving, they should at least reinvent the wheel > properly and check for changes to resolv.conf. > > Nils > -- > Nils Philippsen "Those who would give up Essential Liberty to purchase > Red Hat a little Temporary Safety, deserve neither Liberty > nils at redhat.com nor Safety." -- Benjamin Franklin, 1759 > PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From msivak at redhat.com Tue Sep 16 11:44:03 2008 From: msivak at redhat.com (Martin Sivak) Date: Tue, 16 Sep 2008 13:44:03 +0200 Subject: NetworkworkManger and network based filesystem /usr In-Reply-To: <48CAB296.80101@redhat.com> References: <48CAAF49.3090105@hhs.nl> <20080912181213.GA3270@nostromo.devel.redhat.com> <48CAB296.80101@redhat.com> Message-ID: <20080916114403.GF23124@localhost.localdomain> >>> But there is a catch, hal and NetworkManager are currently under /usr >>> which could be on a network based fs itself. So hal and >>> NetworkManager will need to be moved to /bin and /lib[64], or >>> alternatively we could declare that installations where /usr is on a >>> different fs then / are not supported (which might be a good thing >>> todo for F-10 and then move hal + NM for F-11). >>> >> >> Having network /usr and non-network / isn't really practical long term. >> I'm all for not supporting it. >> > It must die die die. We're far better off making root filesystems > sharable and readonly. > OK, but change the FHS first. Because the Filesystem Hierarchy Standard says, that files needed for boot must be in / and not in /usr. NetworkManager is in the category "needed for boot" right now. And even if the harddrives are cheap, when you have hundreds of machines (like universities usualy have), then you can save awfull lot of money by using shared /usr (or pxe+shared / and thin clients I admit..). Support in fedora is not critical, but obeying the FHS is one think I would strongly recommend. -- Martin Sivak msivak at redhat.com office: +420 532 294 111 / 62079 jabber: mars at njs.netlab.cz Red Hat Inc. http://cz.redhat.com From rjones at redhat.com Tue Sep 16 12:02:42 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 16 Sep 2008 13:02:42 +0100 Subject: The state of resolv.conf In-Reply-To: <3da3b5b40809160434j12a23896k9123a1724d108913@mail.gmail.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221557672.19134.15.camel@gibraltar.str.redhat.com> <48CF84F5.3010701@city-fan.org> <1221563959.19134.43.camel@gibraltar.str.redhat.com> <3da3b5b40809160434j12a23896k9123a1724d108913@mail.gmail.com> Message-ID: <20080916120242.GA8858@amd.home.annexia.org> On Tue, Sep 16, 2008 at 01:34:06PM +0200, Ahmed Kamal wrote: > Is there any current daemon that does this effect of directing name > resolution to specific servers according to IP ranges and/or domain names, > with the option of adding/removing servers on the fly ? Does dnsmasq do that? Yes, dnsmasq can definitely direct specific domain names to specific servers. I'm not sure whether it can do IP ranges (ie. reverse lookups) but it wouldn't surprise me. server=/example.com/1.2.3.4 server=5.6.7.8 will direct all requests for example.com and *.example.com to server 1.2.3.4, and any others to 5.6.7.8. I use this feature all the time BTW. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From msivak at redhat.com Tue Sep 16 12:18:49 2008 From: msivak at redhat.com (Martin Sivak) Date: Tue, 16 Sep 2008 14:18:49 +0200 Subject: The state of resolv.conf In-Reply-To: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> Message-ID: <20080916121849.GG23124@localhost.localdomain> On Mon, Sep 15, 2008 at 02:20:37AM +0200, Ahmed Kamal wrote: > I have an itch. I connect to work using openvpn. Works great, except that > openvpn does not modify resolv.conf to add work's dns servers (now available > through vpn). It does that on Windows though! I cannot expect openvpn or > (any other application) to simply overwrite /etc/resolv.conf at will, but > what is fedora missing to get an elegant solution to this problem ? Well, NM could handle it or take a look at the debian way. Their resolvconf package does exacly what we need. -- Martin Sivak msivak at redhat.com office: +420 532 294 111 / 62079 jabber: mars at njs.netlab.cz Red Hat Inc. http://cz.redhat.com From markg85 at gmail.com Tue Sep 16 12:26:11 2008 From: markg85 at gmail.com (Mark) Date: Tue, 16 Sep 2008 14:26:11 +0200 Subject: Boot speedup with readahead In-Reply-To: <1221556629.8166.29.camel@hughsie-work> References: <1220886750.987.12.camel@rosebud> <1221129185.18327.181.camel@beck.corsepiu.local> <1221457688.6122.23.camel@localhost.localdomain> <48CDFD37.8080702@behdad.org> <1221479676.25056.18.camel@rosebud> <48CE9522.2010308@behdad.org> <1221501862.25056.44.camel@rosebud> <1221509854.3906.19.camel@gaara.bos.redhat.com> <48CEC66B.2000206@fedoraproject.org> <1221556629.8166.29.camel@hughsie-work> Message-ID: <6e24a8e80809160526l75bf1153v234789557351196d@mail.gmail.com> On Tue, Sep 16, 2008 at 11:17 AM, Richard Hughes wrote: > On Tue, 2008-09-16 at 02:02 +0530, Rahul Sundaram wrote: >> Is it in a usable state for day to day work or atleast for testing? I >> would like to see it packaged and more easily consumable in that case >> atleast for rawhide. > > I've got local rpms of razor on my system, but I'm not sure they are > ready to inflict even on developers yet. > > Razor is cool to play with and hack on, but I think it needs some more > work before it's even ready to release a first version. > > But, my god, it's quick. > > Richard. > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > The discussion here isn't really going about the 5 second boot anymore.. I hope we can go back on that now since i really want to know how that's done. From paul at all-the-johnsons.co.uk Tue Sep 16 12:29:26 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 16 Sep 2008 13:29:26 +0100 Subject: Advice request for mono packages Message-ID: <1221568166.26602.28.camel@PB3.Linux> Hi, There has been some discussion on the mono-developers forums about the inclusion of prebuilt dlls (such as Mono.Cecil) and I have been alerted to the fact that as Mono.Cecil does not have a stable API, the likes of MD come with the source code included for Mono.Cecil and this should be used in favour of any other version. I have checked this and it is the case. The version of Mono.Cecil in rawhide is not the same as the other versions around. I'm considering repackaging MD with this in mind but would like the advice of others as to the usefulness of this. It is something which is important for mono based packages that provide the source for non-GAC dlls and needs to be addressed in the packaging guidelines (something which needs altering a tad IMHO). I have second issue over packaging mono itself, but will address that in another posting. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From Matt_Domsch at dell.com Tue Sep 16 12:29:22 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 16 Sep 2008 07:29:22 -0500 Subject: New repo directories on http://download.fedora.redhat.com ??? In-Reply-To: References: <5f6f8c5f0809151657s222ea376hc5af72e8a9b212a9@mail.gmail.com> <1221523281.2102.8.camel@luminos.localdomain> Message-ID: <20080916122922.GA8409@auslistsprd01.us.dell.com> On Tue, Sep 16, 2008 at 07:43:02AM +0000, Mike wrote: > Jesse Keating redhat.com> writes: > > > Process problem. .newkey.newkey will be going away, .newkey should have > > never gone away. If you saw it go away, something different went wrong. > > Seems that the directory > http://download.fedora.redhat.com/pub/fedora/linux/updates/8/i386.newkey > and related have vanished! yep. 9/*.newkey are there, 8/*.newkey are gone. Arrgghh. That is far from intentional. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mk at crc.dk Tue Sep 16 12:38:49 2008 From: mk at crc.dk (Mogens Kjaer) Date: Tue, 16 Sep 2008 14:38:49 +0200 Subject: New repo directories on http://download.fedora.redhat.com ??? In-Reply-To: <20080916122922.GA8409@auslistsprd01.us.dell.com> References: <5f6f8c5f0809151657s222ea376hc5af72e8a9b212a9@mail.gmail.com> <1221523281.2102.8.camel@luminos.localdomain> <20080916122922.GA8409@auslistsprd01.us.dell.com> Message-ID: <48CFA8D9.6030409@crc.dk> Matt Domsch wrote: ... > yep. 9/*.newkey are there, 8/*.newkey are gone. Arrgghh. That is > far from intentional. When I set up my fedora/centos mirror I felt a bit stupid adding a weekly tape backup to the machine. This has saved me more than once :-) I always wished there were a trash folder system for rsync; files deleted are moved to the trash folder, and before each download a check is made to see if the file already exists in the trash folder. This folder could then be purged at regular intervals. Mogens -- Mogens Kjaer, Carlsberg A/S, Computer Department Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark Phone: +45 33 27 53 25, Fax: +45 33 27 47 08 Email: mk at crc.dk Homepage: http://www.crc.dk From markmc at redhat.com Tue Sep 16 12:41:20 2008 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 16 Sep 2008 13:41:20 +0100 Subject: Proposal: Better force-tag In-Reply-To: <1221409389.24484.1.camel@truman> References: <1220955240.24928.69.camel@cookie.hadess.net> <20080911195252.GB26684@yoda.jdub.homelinux.org> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> <48CA16D1.5070409@redhat.com> <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> <1221234383.15726.194.camel@localhost.localdomain> <48CD1CA3.5060302@redhat.com> <1221402590.27183.172.camel@ignacio.lan> <48CD3358.8060105@poolshark.org> <1221409389.24484.1.camel@truman> Message-ID: <1221568880.4534.51.camel@blaa> On Sun, 2008-09-14 at 12:23 -0400, Brian Pepple wrote: > On Sun, 2008-09-14 at 17:52 +0200, Denis Leroy wrote: > > Ignacio Vazquez-Abrams wrote: > > > Ultimately nothing can stop the user from using cvs tag -F, so any > > > solution (including this one, which I like a lot) would have to be > > > server-side. > > > > That's what they're planning to do, despite many objections. When will > > the FeSCo minutes be available on the wiki ? I would like to know who > > voted for this. > > I'm planning to write up the summary later today, but the IRC logs are > available as soon as the meeting ends. > > http://bpepple.fedorapeople.org/fesco/ jwb> so we've had vocal feedback on this i think a simple vote is in order dgilmore> your saying you want FESCo to control Makefile.common jwb> i'm saying FESCo was elected to represent our developer and user communities, and changes that impact them should at least be run past FESCo Actually, may I respectfully suggest that FESCo should try and stay out of matters like this insofar as possible? IMHO, FESCo should merely be trying to reflect the "rough consensus" of the rest of the community. e.g. in this example, a rough consensus is forming on the list along the lines of: 1) "force-tag" is used by a number of packagers for reasonably valid reasons that don't conflict with the tracking of what sources were used for a given build 2) We could disallow (on the server-side) re-tagging if a build has completed, or is in progress, using that tag 3) Or we could track the CVS/Entries for a given build FESCo need not play any role here beyond keeping an eye on the progress of this rough consensus - i.e. that the original change is being reverted and the relevant maintainers (and others) are hashing out the implementation of either suggestion. FESCo taking a position via a vote is not helpful, IMHO. Cheers, Mark. From skvidal at fedoraproject.org Tue Sep 16 12:48:53 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 16 Sep 2008 08:48:53 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080916084942.GB28147@nb.net.home> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <1221516162.3629.26.camel@luminos.localdomain> <1221528652.25056.66.camel@rosebud> <20080916084942.GB28147@nb.net.home> Message-ID: <1221569333.27902.0.camel@rosebud> On Tue, 2008-09-16 at 10:49 +0200, Karel Zak wrote: > On Mon, Sep 15, 2008 at 09:30:52PM -0400, Seth Vidal wrote: > > Ralf is saying that the changes the desktop teams wants to make are not > > FORWARD. They are in a direction that is sub-optimal for various things. > > > > And to be fair a lot of other people who do things with fedora don't > > require large changes for that to happen. The folks providing functional > > daemons, for example, they don't need much more than a quasi-stable base > > to run on. > > Yes. Sane development = Evolution, not revolution. > Yes and we've gotten everywhere via evolutionary steps. Revolutions just piss people off and get people killed. -sv From atkac at redhat.com Tue Sep 16 12:51:36 2008 From: atkac at redhat.com (Adam Tkac) Date: Tue, 16 Sep 2008 14:51:36 +0200 Subject: The state of resolv.conf In-Reply-To: <3da3b5b40809160434j12a23896k9123a1724d108913@mail.gmail.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221557672.19134.15.camel@gibraltar.str.redhat.com> <48CF84F5.3010701@city-fan.org> <1221563959.19134.43.camel@gibraltar.str.redhat.com> <3da3b5b40809160434j12a23896k9123a1724d108913@mail.gmail.com> Message-ID: <20080916125136.GA8548@evileye.atkac.englab.brq.redhat.com> On Tue, Sep 16, 2008 at 01:34:06PM +0200, Ahmed Kamal wrote: > Is there any current daemon that does this effect of directing name > resolution to specific servers according to IP ranges and/or domain names, > with the option of adding/removing servers on the fly ? Does dnsmasq do that > ? > What you mean with "according to IP ranges/domain names"? - if you want redirect clients from specific networks to different servers you can use BIND and view statements: view "name" { match-clients { 10.0.0.0/8; }; forwarders { 1.2.3.4; }; forward only; }; - if you want redirect target domains to different servers you can use BIND and forward zones: zone "example" IN { type forward; forward only; forwarders { 1.2.3.4; }; }; Adam -- Adam Tkac, Red Hat, Inc. From atkac at redhat.com Tue Sep 16 13:09:51 2008 From: atkac at redhat.com (Adam Tkac) Date: Tue, 16 Sep 2008 15:09:51 +0200 Subject: The state of resolv.conf In-Reply-To: <1221559289.8461.1.camel@localhost.localdomain> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221559289.8461.1.camel@localhost.localdomain> Message-ID: <20080916130951.GB8548@evileye.atkac.englab.brq.redhat.com> On Tue, Sep 16, 2008 at 05:01:29AM -0500, Callum Lerwick wrote: > On Mon, 2008-09-15 at 08:44 -0400, Simo Sorce wrote: > > On Mon, 2008-09-15 at 09:32 +0200, Ahmed Kamal wrote: > > > Wouldn't the best way be to have an api that can be used to add and > > > delete DNS servers and manipulate resolv.conf. Then we could have > > > deamons call that. > > > > No what you really need is more than a simple resolv.conf file. > > > > We need a default caching daemon (which by itself will solve a lot of > > other issues) that tools like NM, vpnc, openvpn can interact with. > > These tools will tell the caching daemon which IP ranges and which > > domains their provided forwarders should be consulted for. All dynamic > > so that as soon as one daemon goes away, the caching DNS will notice and > > revert queries to the default DNS. And if NM/routes go away it can keep > > working out of its cache. If NM and routes go away I think you don't need DNS at all ;) If you are interested only in caching why you cannot use nscd? I have creation of NM support to BIND in TODO (https://bugzilla.redhat.com/show_bug.cgi?id=441057) but I haven't got time for it yet. If vpnc/openvpn will interract with NM then you can ask NM for DNS servers for every interface and then use them as "forwarders" in BIND. Additionaly you can get advantage of DNSSEC aware resolver. Adam -- Adam Tkac, Red Hat, Inc. From ssorce at redhat.com Tue Sep 16 13:46:08 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 16 Sep 2008 09:46:08 -0400 Subject: The state of resolv.conf In-Reply-To: <20080916130951.GB8548@evileye.atkac.englab.brq.redhat.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221559289.8461.1.camel@localhost.localdomain> <20080916130951.GB8548@evileye.atkac.englab.brq.redhat.com> Message-ID: <1221572768.12851.22.camel@localhost.localdomain> On Tue, 2008-09-16 at 15:09 +0200, Adam Tkac wrote: > On Tue, Sep 16, 2008 at 05:01:29AM -0500, Callum Lerwick wrote: > > On Mon, 2008-09-15 at 08:44 -0400, Simo Sorce wrote: > > > On Mon, 2008-09-15 at 09:32 +0200, Ahmed Kamal wrote: > > > > Wouldn't the best way be to have an api that can be used to add and > > > > delete DNS servers and manipulate resolv.conf. Then we could have > > > > deamons call that. > > > > > > No what you really need is more than a simple resolv.conf file. > > > > > > We need a default caching daemon (which by itself will solve a lot of > > > other issues) that tools like NM, vpnc, openvpn can interact with. > > > These tools will tell the caching daemon which IP ranges and which > > > domains their provided forwarders should be consulted for. All dynamic > > > so that as soon as one daemon goes away, the caching DNS will notice and > > > revert queries to the default DNS. And if NM/routes go away it can keep > > > working out of its cache. > > If NM and routes go away I think you don't need DNS at all ;) Well if you use NM only to manage your networks that is true, although that's not the only way (and I also have VMs with virttual networks on my laptop :-) > If you are interested only in caching why you cannot use nscd? Not all programs use nscd as not all type of queries can be fulfilled by the glibc interface. For example SRV/TXT records ... Also nscd is not smart enough to understand network condition and adapt it's behavior. > I have creation of NM support to BIND in TODO > (https://bugzilla.redhat.com/show_bug.cgi?id=441057) but I haven't got > time for it yet. If vpnc/openvpn will interract with NM then you can ask > NM for DNS servers for every interface and then use them as "forwarders" > in BIND. Additionaly you can get advantage of DNSSEC aware resolver. I am not concerned about the DNS server used to do this. It would be nice tho if bind could consult different DNSs based 1) on the DNS name to be queried, and B) the reverse IP to be queried. IE when I connect to the RedHat VPN in some case I would like to have all .redhat.com DNS queries sent to the RH DNS servers and all others sent to my normal network DNS. Also for reverse lookups I'd like to send to the RH network only the networks RH do manage, and not any other networks in the world. This will allow me to make efficient use of the VPN, and when I am on slow links allows me to send non-RH queries to the local, much faster DNS server instead of piping them through the VPN. If you have multiple VPNs set up you can see how this becomes important, esp. if each site you are connected to has its own DNS with private views available only to internal clients. Simo. -- Simo Sorce * Red Hat, Inc * New York From paul at city-fan.org Tue Sep 16 14:00:52 2008 From: paul at city-fan.org (Paul Howarth) Date: Tue, 16 Sep 2008 15:00:52 +0100 Subject: The state of resolv.conf In-Reply-To: <1221572768.12851.22.camel@localhost.localdomain> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221559289.8461.1.camel@localhost.localdomain> <20080916130951.GB8548@evileye.atkac.englab.brq.redhat.com> <1221572768.12851.22.camel@localhost.localdomain> Message-ID: <48CFBC14.8070106@city-fan.org> Simo Sorce wrote: > On Tue, 2008-09-16 at 15:09 +0200, Adam Tkac wrote: >> On Tue, Sep 16, 2008 at 05:01:29AM -0500, Callum Lerwick wrote: >>> On Mon, 2008-09-15 at 08:44 -0400, Simo Sorce wrote: >>>> On Mon, 2008-09-15 at 09:32 +0200, Ahmed Kamal wrote: >>>>> Wouldn't the best way be to have an api that can be used to add and >>>>> delete DNS servers and manipulate resolv.conf. Then we could have >>>>> deamons call that. >>>> No what you really need is more than a simple resolv.conf file. >>>> >>>> We need a default caching daemon (which by itself will solve a lot of >>>> other issues) that tools like NM, vpnc, openvpn can interact with. >>>> These tools will tell the caching daemon which IP ranges and which >>>> domains their provided forwarders should be consulted for. All dynamic >>>> so that as soon as one daemon goes away, the caching DNS will notice and >>>> revert queries to the default DNS. And if NM/routes go away it can keep >>>> working out of its cache. >> If NM and routes go away I think you don't need DNS at all ;) > > Well if you use NM only to manage your networks that is true, although > that's not the only way (and I also have VMs with virttual networks on > my laptop :-) > >> If you are interested only in caching why you cannot use nscd? > > Not all programs use nscd as not all type of queries can be fulfilled by > the glibc interface. For example SRV/TXT records ... > Also nscd is not smart enough to understand network condition and adapt > it's behavior. > >> I have creation of NM support to BIND in TODO >> (https://bugzilla.redhat.com/show_bug.cgi?id=441057) but I haven't got >> time for it yet. If vpnc/openvpn will interract with NM then you can ask >> NM for DNS servers for every interface and then use them as "forwarders" >> in BIND. Additionaly you can get advantage of DNSSEC aware resolver. > > I am not concerned about the DNS server used to do this. It would be > nice tho if bind could consult different DNSs based 1) on the DNS name > to be queried, and B) the reverse IP to be queried. > > IE when I connect to the RedHat VPN in some case I would like to have > all .redhat.com DNS queries sent to the RH DNS servers and all others > sent to my normal network DNS. Also for reverse lookups I'd like to send > to the RH network only the networks RH do manage, and not any other > networks in the world. > > This will allow me to make efficient use of the VPN, and when I am on > slow links allows me to send non-RH queries to the local, much faster > DNS server instead of piping them through the VPN. > > If you have multiple VPNs set up you can see how this becomes important, > esp. if each site you are connected to has its own DNS with private > views available only to internal clients. Bind can already do this (see "if you want redirect target domains to different servers" in Adam's recent post). It's how I use it in conjunction with my employer's VPN. Paul. From atkac at redhat.com Tue Sep 16 14:15:24 2008 From: atkac at redhat.com (Adam Tkac) Date: Tue, 16 Sep 2008 16:15:24 +0200 Subject: The state of resolv.conf In-Reply-To: <1221572768.12851.22.camel@localhost.localdomain> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221559289.8461.1.camel@localhost.localdomain> <20080916130951.GB8548@evileye.atkac.englab.brq.redhat.com> <1221572768.12851.22.camel@localhost.localdomain> Message-ID: <20080916141524.GA9465@evileye.atkac.englab.brq.redhat.com> On Tue, Sep 16, 2008 at 09:46:08AM -0400, Simo Sorce wrote: > On Tue, 2008-09-16 at 15:09 +0200, Adam Tkac wrote: > > On Tue, Sep 16, 2008 at 05:01:29AM -0500, Callum Lerwick wrote: > > > On Mon, 2008-09-15 at 08:44 -0400, Simo Sorce wrote: > > > > On Mon, 2008-09-15 at 09:32 +0200, Ahmed Kamal wrote: > > > > > Wouldn't the best way be to have an api that can be used to add and > > > > > delete DNS servers and manipulate resolv.conf. Then we could have > > > > > deamons call that. > > > > > > > > No what you really need is more than a simple resolv.conf file. > > > > > > > > We need a default caching daemon (which by itself will solve a lot of > > > > other issues) that tools like NM, vpnc, openvpn can interact with. > > > > These tools will tell the caching daemon which IP ranges and which > > > > domains their provided forwarders should be consulted for. All dynamic > > > > so that as soon as one daemon goes away, the caching DNS will notice and > > > > revert queries to the default DNS. And if NM/routes go away it can keep > > > > working out of its cache. > > > > If NM and routes go away I think you don't need DNS at all ;) > > Well if you use NM only to manage your networks that is true, although > that's not the only way (and I also have VMs with virttual networks on > my laptop :-) > > > If you are interested only in caching why you cannot use nscd? > > Not all programs use nscd as not all type of queries can be fulfilled by > the glibc interface. For example SRV/TXT records ... > Also nscd is not smart enough to understand network condition and adapt > it's behavior. Right you are. > > > I have creation of NM support to BIND in TODO > > (https://bugzilla.redhat.com/show_bug.cgi?id=441057) but I haven't got > > time for it yet. If vpnc/openvpn will interract with NM then you can ask > > NM for DNS servers for every interface and then use them as "forwarders" > > in BIND. Additionaly you can get advantage of DNSSEC aware resolver. > > I am not concerned about the DNS server used to do this. It would be > nice tho if bind could consult different DNSs based 1) on the DNS name > to be queried, and B) the reverse IP to be queried. > > IE when I connect to the RedHat VPN in some case I would like to have > all .redhat.com DNS queries sent to the RH DNS servers and all others > sent to my normal network DNS. Also for reverse lookups I'd like to send > to the RH network only the networks RH do manage, and not any other > networks in the world. > > This will allow me to make efficient use of the VPN, and when I am on > slow links allows me to send non-RH queries to the local, much faster > DNS server instead of piping them through the VPN. > > If you have multiple VPNs set up you can see how this becomes important, > esp. if each site you are connected to has its own DNS with private > views available only to internal clients. > Yes, it will be nice feature to use the closest nameserver. But it is very difficult to get this information automatically (if you are using "static" nameserver configuration you could configure forward zones and it will work well). One solution, in theory, might be use information from DHCP: - get per-device DHCP information and export it (NM) - get "preferred" domains from search/domain directives from DHCP - for that domains use servers whose are on same network interface as domain With reverse lookups situation is far more difficult - I can't see any solution how get potential per-interface candidates from DHCP. Adam -- Adam Tkac, Red Hat, Inc. From airlied at redhat.com Tue Sep 16 14:15:36 2008 From: airlied at redhat.com (Dave Airlie) Date: Wed, 17 Sep 2008 00:15:36 +1000 Subject: Non-X text mode console In-Reply-To: <20080916092807.GA22628@shell.devel.redhat.com> References: <20080915151812.0730561B48E@hormel.redhat.com> <48CEA848.2050005@redhat.com> <20080916092807.GA22628@shell.devel.redhat.com> Message-ID: <1221574536.4057.3.camel@localhost> On Tue, 2008-09-16 at 05:28 -0400, Alan Cox wrote: > > Unless I've missed something huge, virtual terminals aren't going away. > > What may or may not be going away is the x86 video BIOS text mode, to be > > replaced with a kernel framebuffer, which precludes the use of console > > fonts, which very few people ever mess with. The console itself will > > remain. Someone please correct me if I'm wrong. > > Framebuffer consoles support fonts. > > However they do not work on all machines, they do not work with a lot of > screen reader technology and they don't work with many of the remote management > cards. If you can find a remote management card made in the last 10 years that doesn't work with a Windows box on the other end, I'd be pleasently surprised considering the market for such a thing wouldn't be large enough to bother making it. Again screen reader technology, yes there may be something from the DOS days, but how much Linux specific screen-reader tech exists, where is the market for this?. So while I think you might be right I'm not sure it will ever affect anyone, and if it does they can boot text mode like they do now. Dave. From adellam at sevenseas.org Tue Sep 16 14:38:24 2008 From: adellam at sevenseas.org (Andrea Dell'Amico) Date: Tue, 16 Sep 2008 16:38:24 +0200 Subject: The state of resolv.conf In-Reply-To: <20080916141524.GA9465@evileye.atkac.englab.brq.redhat.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221559289.8461.1.camel@localhost.localdomain> <20080916130951.GB8548@evileye.atkac.englab.brq.redhat.com> <1221572768.12851.22.camel@localhost.localdomain> <20080916141524.GA9465@evileye.atkac.englab.brq.redhat.com> Message-ID: <1221575904.7205.45.camel@altrove.masaccio.sevenseas.org> On Tue, 2008-09-16 at 16:15 +0200, Adam Tkac wrote: > Yes, it will be nice feature to use the closest nameserver. But it is > very difficult to get this information automatically (if you are > using "static" nameserver configuration you could configure forward > zones and it will work well). > > One solution, in theory, might be use information from DHCP: > - get per-device DHCP information and export it (NM) > - get "preferred" domains from search/domain directives from DHCP > - for that domains use servers whose are on same network interface as > domain > > With reverse lookups situation is far more difficult - I can't see > any solution how get potential per-interface candidates from DHCP. In the past (F7 time?), bind had a dbus interface, never accepted upstream and so removed, that could be used to specify which nameserver we wanted as main forwarders. That feature permitted a configuration where bind was configured with static forwarders for my vpn networks, and used as forwarders the name servers passed by my dhcp server. In /etc/resolv.conf I had only 127.0.0.1 It wasn't the optimum solution, but it was better than the actual situation. > Adam > > -- > Adam Tkac, Red Hat, Inc. ciao andrea -- "Thinking meat! You're asking me to believe in thinking meat!" - Terry Bisson From ssorce at redhat.com Tue Sep 16 14:57:02 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 16 Sep 2008 10:57:02 -0400 Subject: The state of resolv.conf In-Reply-To: <20080916141524.GA9465@evileye.atkac.englab.brq.redhat.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221559289.8461.1.camel@localhost.localdomain> <20080916130951.GB8548@evileye.atkac.englab.brq.redhat.com> <1221572768.12851.22.camel@localhost.localdomain> <20080916141524.GA9465@evileye.atkac.englab.brq.redhat.com> Message-ID: <1221577022.12851.30.camel@localhost.localdomain> On Tue, 2008-09-16 at 16:15 +0200, Adam Tkac wrote: > On Tue, Sep 16, 2008 at 09:46:08AM -0400, Simo Sorce wrote: > > On Tue, 2008-09-16 at 15:09 +0200, Adam Tkac wrote: > > > On Tue, Sep 16, 2008 at 05:01:29AM -0500, Callum Lerwick wrote: > > > > On Mon, 2008-09-15 at 08:44 -0400, Simo Sorce wrote: > > > > > On Mon, 2008-09-15 at 09:32 +0200, Ahmed Kamal wrote: > > > > > > Wouldn't the best way be to have an api that can be used to add and > > > > > > delete DNS servers and manipulate resolv.conf. Then we could have > > > > > > deamons call that. > > > > > > > > > > No what you really need is more than a simple resolv.conf file. > > > > > > > > > > We need a default caching daemon (which by itself will solve a lot of > > > > > other issues) that tools like NM, vpnc, openvpn can interact with. > > > > > These tools will tell the caching daemon which IP ranges and which > > > > > domains their provided forwarders should be consulted for. All dynamic > > > > > so that as soon as one daemon goes away, the caching DNS will notice and > > > > > revert queries to the default DNS. And if NM/routes go away it can keep > > > > > working out of its cache. > > > > > > If NM and routes go away I think you don't need DNS at all ;) > > > > Well if you use NM only to manage your networks that is true, although > > that's not the only way (and I also have VMs with virttual networks on > > my laptop :-) > > > > > If you are interested only in caching why you cannot use nscd? > > > > Not all programs use nscd as not all type of queries can be fulfilled by > > the glibc interface. For example SRV/TXT records ... > > Also nscd is not smart enough to understand network condition and adapt > > it's behavior. > > Right you are. > > > > > > I have creation of NM support to BIND in TODO > > > (https://bugzilla.redhat.com/show_bug.cgi?id=441057) but I haven't got > > > time for it yet. If vpnc/openvpn will interract with NM then you can ask > > > NM for DNS servers for every interface and then use them as "forwarders" > > > in BIND. Additionaly you can get advantage of DNSSEC aware resolver. > > > > I am not concerned about the DNS server used to do this. It would be > > nice tho if bind could consult different DNSs based 1) on the DNS name > > to be queried, and B) the reverse IP to be queried. > > > > IE when I connect to the RedHat VPN in some case I would like to have > > all .redhat.com DNS queries sent to the RH DNS servers and all others > > sent to my normal network DNS. Also for reverse lookups I'd like to send > > to the RH network only the networks RH do manage, and not any other > > networks in the world. > > > > This will allow me to make efficient use of the VPN, and when I am on > > slow links allows me to send non-RH queries to the local, much faster > > DNS server instead of piping them through the VPN. > > > > If you have multiple VPNs set up you can see how this becomes important, > > esp. if each site you are connected to has its own DNS with private > > views available only to internal clients. > > > > Yes, it will be nice feature to use the closest nameserver. But it is > very difficult to get this information automatically (if you are > using "static" nameserver configuration you could configure forward > zones and it will work well). > > One solution, in theory, might be use information from DHCP: > - get per-device DHCP information and export it (NM) > - get "preferred" domains from search/domain directives from DHCP > - for that domains use servers whose are on same network interface as > domain Yes, this was the idea. > With reverse lookups situation is far more difficult - I can't see > any solution how get potential per-interface candidates from DHCP. Ys you do not get this one from DHCP, but in most cases DHCP serves your primary interface and so that is the default (if not then we could think to add per-connection metadata to tell which are the "local networks" for this connection). With VPN, in most cases you *have* the remote networks, because you need them to be able to route anything. It can be just a number of subnets, or in some case, it can be that the VPN wants to reroute all. In either case you know what to do. (If the VPN forces to route all traffic then you have to use the VPN provided DNS for everything). I believe NM should keep this information around and we should you it to make the best choice we can. Simo. -- Simo Sorce * Red Hat, Inc * New York From janina at rednote.net Tue Sep 16 14:57:53 2008 From: janina at rednote.net (Janina Sajka) Date: Tue, 16 Sep 2008 10:57:53 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <20080913172709.GF4421@sonata.rednote.net> Message-ID: <20080916145753.GA32117@sonata.rednote.net> Colin Walters writes: > On Sat, Sep 13, 2008 at 1:27 PM, Janina Sajka wrote: > > > > But, I still launch 24 consoles when I boot, because I actually use most > > of them in very specific ways. About 6 of these 24 run screen with 9 > > separate terminal windows defined by ~/.screenrc. I don't see gnome > > terminal replacing that anytime soon. > > It has tabs, and you can script it; I don't see what wouldn't work > with your setup. > Perhaps when X evolves enough that we aren't limited to it on one console. Or, perhaps also when the at stack becomes much more robust. Right now, while the gui has been usable (for about a year), it's prone to something--God only knows what, because when my speech dies I have no notion of any error, etc--I simply lose the whole environment. Usually, Ctrl+Alt+Backspace lets me start over, but that doesn't encourage one to replace 24 consoles with terminal tabs. Not infrequently, ctrl+alt+backspace doesn't work, and I'm trying telinit 3 followed by telinit 5. Too frequently, even this doesn't work and I have to reboot if I want a stable gui--which discourages me from relying on it for real work. BTW: Not all my consoles are simple terminal screens. I run 9 mutt instances in 9 screen terminals on Ctrl+Alt+F1, for instance. My inbox is in Ctrl-A1, Fedora mail in Ctrl-a5, my standards related work in Ctrl-a9, etc. Meanwhile, evolution and thunderbird are only marginally usable from the screen reader perspective, and not with the same alacrity that serves me in mutt. Heck, I can still cite specific web pages where lynx does better than firefox3 from my a11y perspective. Thankfully, there are plenty examples the other way around, too. Janina > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka, Phone: +1.202.595.7777; sip:janina at a11y.org Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada Learn more at http://ScreenlessPhone.Com Chair, Open Accessibility janina at a11y.org Linux Foundation http://a11y.org From billcrawford1970 at gmail.com Tue Sep 16 15:03:45 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Tue, 16 Sep 2008 16:03:45 +0100 Subject: make force-tag gone In-Reply-To: References: <1220955240.24928.69.camel@cookie.hadess.net> <935ead450809111351r1483943dw3307e5ff69ffef6a@mail.gmail.com> <1221167000.26178.5.camel@luminos.localdomain> <48C99205.9060903@gmail.com> <48CA16D1.5070409@redhat.com> <1221226295.4345.37.camel@atropine.boston.devel.redhat.com> <1221234383.15726.194.camel@localhost.localdomain> Message-ID: <544eb990809160803h65914e83j78b9610f64ab609b@mail.gmail.com> 2008/9/14 drago01 : > Was away for one week and now make force-tag no longer works.... > Why do we need to bump the release and changelog for every small > change? ex: typo? > This makes the changelog useless to read and fills the users > rpmdb/disk with crap entries "forgot to add a patch"; "fix a typo", > etc. Remove some of them later. It's still in CVS history :) > +1 for adding it back. > > Just removing stuff does not solve problems you have to implement a > better alternative first (and not rely on a worse one). > > -- > 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 Tue Sep 16 15:09:00 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 16 Sep 2008 11:09:00 -0400 Subject: Advice request for mono packages In-Reply-To: <1221568166.26602.28.camel@PB3.Linux> References: <1221568166.26602.28.camel@PB3.Linux> Message-ID: <1221577740.29052.144.camel@localhost.localdomain> On Tue, 2008-09-16 at 13:29 +0100, Paul wrote: > It is something which is important for mono based packages that > provide > the source for non-GAC dlls and needs to be addressed in the packaging > guidelines (something which needs altering a tad IMHO). This is really where we're working around bad coding practices from upstream. Why doesn't Mono.Cecil adopt a stable API? Or at least a versioned API, so that when they break API, they increment version and then things can depend on a version of the API? This isn't rocket science. It isn't even novel. We don't generally permit package-local copies of system libraries for lots of reasons, like the fact that they often miss bug fixes, security fixes, often end up being duplicated in multiple packages and are much more difficult to maintain. ~spot From alan at redhat.com Tue Sep 16 15:16:24 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 16 Sep 2008 11:16:24 -0400 Subject: Non-X text mode console In-Reply-To: <1221574536.4057.3.camel@localhost> References: <20080915151812.0730561B48E@hormel.redhat.com> <48CEA848.2050005@redhat.com> <20080916092807.GA22628@shell.devel.redhat.com> <1221574536.4057.3.camel@localhost> Message-ID: <20080916151624.GA25388@shell.devel.redhat.com> > think you might be right I'm not sure it will ever affect anyone, and if > it does they can boot text mode like they do now. Right - providing you don't take that away. From nils at redhat.com Tue Sep 16 15:17:30 2008 From: nils at redhat.com (Nils Philippsen) Date: Tue, 16 Sep 2008 17:17:30 +0200 Subject: standby and cd discovery In-Reply-To: <48CF9955.1010400@n-dimensional.de> References: <1221563305.21005.12.camel@choeger6> <1221564071.19134.47.camel@gibraltar.str.redhat.com> <48CF9955.1010400@n-dimensional.de> Message-ID: <1221578250.4107.5.camel@gibraltar.str.redhat.com> On Tue, 2008-09-16 at 13:32 +0200, Hans Ulrich Niedermann wrote: > Nils Philippsen wrote: > > On Tue, 2008-09-16 at 13:08 +0200, Christoph H?ger wrote: > > >> Whenever I put my thinkpad to sleep (standby), with a cd in the drive > >> and resume, that cd pops up as a folder as if I inserted it. > >> Thats annoying. After the third standby/resume cycle I _know_ whats on > >> that disc! > >> Does anyone know if this is _really_ a bug or how to fix it (if its > >> fixable it should propably be fixed in the release version)? > > > > I would say this is a bug. Suspending a machine should just "pause" the > > system and the behaviour afterwards should be the same as if you hadn't > > suspended the machine at all. > > Not in all respects. > > A common usecase is you sit at place A connected to WLAN A, suspend the > box, move it, and resume it at place B. It does not make sense now to > try sending to WLAN A for a minute (which feels like an eternity), and > only then consider that we might want to look for other WLANs or wired > LANs to connect to. > > You'd want the resume to trigger action much more quickly. Of course it should quickly detect that it can't reach the old WLAN anymore, but that's just the same if the system is continually running. To avoid that moving your laptop out of reception range and moving it back in breaks the connection to quick, a slightly modified behavior in the suspend/resume case might be needed, admittedly. If "something" is "connected" after the resume that was "connected" before, it should just continue, if "something" isn't "connected" anymore, it should just act as if the plug was pulled. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils at redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From janina at rednote.net Tue Sep 16 15:17:42 2008 From: janina at rednote.net (Janina Sajka) Date: Tue, 16 Sep 2008 11:17:42 -0400 Subject: Non-X text mode console In-Reply-To: References: <20080915151812.0730561B48E@hormel.redhat.com> <48CEA6D3.90906@herr-schmitt.de> Message-ID: <20080916151742.GB32117@sonata.rednote.net> Colin Walters writes: > On Mon, Sep 15, 2008 at 2:17 PM, Jochen Schmitt wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > David A. Wheeler schrieb: > >> I think it's clear from this discussion here that many people DO > >> find non-X console mode useful, and thus, it shouldn't be removed: > >> Dominik 'Rathann' Mierzejewski: > > I agree with you, that a release of Fedora without non-x mode console > > may be > > a disadvantage. > > > > Blind or low vision people may prefer non-X mode consoles. And I think > > there are other > > peoples with such prefernces too. > > For such use cases, an X terminal emulator such as gnome-terminal > should be indistinguishable. Except that all the OS infrastructure > like DBus, sound, etc. will be available and work. > You're assuming the X-based assistive technology will become at least as performant as the non X technology is today. I certainly don't regard this to be impossible. I simply note we're not there. But, I suspect we would also need multiple x-terms. Cramming this all into one tty won't cut it from the perspective of reliable access to particular applications. I realize emacspeak actually does it in one tty, by providing a list of virtual buffers. But that's an interaction model that doesn't work for everyone--probably for similar reasons that vi and emacs have their strong partisans even in the a11y community. It's a different model for getting from where I am to where I want to go next. Janina > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka, Phone: +1.202.595.7777; sip:janina at a11y.org Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada Learn more at http://ScreenlessPhone.Com Chair, Open Accessibility janina at a11y.org Linux Foundation http://a11y.org From janina at rednote.net Tue Sep 16 15:26:18 2008 From: janina at rednote.net (Janina Sajka) Date: Tue, 16 Sep 2008 11:26:18 -0400 Subject: Non-X text mode console In-Reply-To: <1221502767.5321.25.camel@rousalka.okg> References: <20080915151812.0730561B48E@hormel.redhat.com> <1221502767.5321.25.camel@rousalka.okg> Message-ID: <20080916152618.GC32117@sonata.rednote.net> Nicolas Mailhot writes: > Le lundi 15 septembre 2008 ? 14:06 -0400, David A. Wheeler a ?crit : > > > The complaints about non-X console mode failing to support > > "multiple fonts" are irrelevant. > > There are no such complains. My complain on the contrary is that current > console mode demands the use of multiple fonts (and creates many > problems in the process) I would grant that maintaining two separate technologies for font and layout is untenable. That makes sense to me. The conclusion that, therefore consoles must die is not, however, a logical conclusion inevitably drawable from that proposition. It would be so unlike computer technology to provide us but one solution to any problem--one of the first principles I was taught in CS 101, and one that seems to be borne out by experience. Janina > > -- > Nicolas Mailhot > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka, Phone: +1.202.595.7777; sip:janina at a11y.org Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada Learn more at http://ScreenlessPhone.Com Chair, Open Accessibility janina at a11y.org Linux Foundation http://a11y.org From nils at redhat.com Tue Sep 16 15:32:31 2008 From: nils at redhat.com (Nils Philippsen) Date: Tue, 16 Sep 2008 17:32:31 +0200 Subject: The state of resolv.conf In-Reply-To: <20080916125136.GA8548@evileye.atkac.englab.brq.redhat.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221557672.19134.15.camel@gibraltar.str.redhat.com> <48CF84F5.3010701@city-fan.org> <1221563959.19134.43.camel@gibraltar.str.redhat.com> <3da3b5b40809160434j12a23896k9123a1724d108913@mail.gmail.com> <20080916125136.GA8548@evileye.atkac.englab.brq.redhat.com> Message-ID: <1221579151.4107.11.camel@gibraltar.str.redhat.com> On Tue, 2008-09-16 at 14:51 +0200, Adam Tkac wrote: > On Tue, Sep 16, 2008 at 01:34:06PM +0200, Ahmed Kamal wrote: > > Is there any current daemon that does this effect of directing name > > resolution to specific servers according to IP ranges and/or domain names, > > with the option of adding/removing servers on the fly ? Does dnsmasq do that > > ? > > > > What you mean with "according to IP ranges/domain names"? [...] > - if you want redirect target domains to different servers you can use > BIND and forward zones: I would want to be able to do that based on domain names (which is easily done with BIND) and on classless IP ranges. I don't think the latter can be done as the IP ranges are octet-granular, e.g. 10.in-addr.arpa for 10.0.0.0/8 -- I can't imagine how I would tell BIND to use a certain server for e.g. 10.1.0.0/12 (where 4 MSB of the second octet are part of the network address and the remaining 4 LSB are part of the host address). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils at redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From billcrawford1970 at gmail.com Tue Sep 16 15:33:45 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Tue, 16 Sep 2008 16:33:45 +0100 Subject: change isdn4k-utils to optional In-Reply-To: <200809140207.08044.konrad@tylerc.org> References: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> <1221381331.18327.532.camel@beck.corsepiu.local> <200809140207.08044.konrad@tylerc.org> Message-ID: <544eb990809160833w7f1044cclb558320bfb2dab8a@mail.gmail.com> 2008/9/14 Conrad Meyer : > Right, the OP wasn't talking about removing the package from Fedora entirely, > but disabling it as a default installed package. Users who need ISDN for > non-internet purposes can always download the isdn packages from > repositories, whereas those who need it to connect to the internet would be > out of luck if it was disabled by default (for new installs, anyways). Yes, but this is a chicken and egg for anyone who forgets to select the ISDN package at install time (especially if they're used to ISDN "just working" with previous installs). I'm usually in the "disk space might be cheap but the whole disk isn't, for everyone" camp; on this occasion I'm wholly behind the people who want to keep it in there by default (I can always UNselect it at install time if I don't want it!). From alain.portal at free.fr Tue Sep 16 15:40:00 2008 From: alain.portal at free.fr (Alain PORTAL) Date: Tue, 16 Sep 2008 17:40:00 +0200 Subject: Orphaning my packages Message-ID: <200809161740.01071.alain.portal@free.fr> Hi, As said some days ago, I want to release ownership of my packages: fcron -- A task scheduler kbackup -- Back up your data in a simple, user friendly way kicad -- Electronic schematic diagrams and printed circuit board artwork man-pages-fr -- French version of the Linux man-pages pikdev -- IDE for development of PICmicro based application (under Linux/KDE) piklab -- Development environment for applications based on PIC & dsPIC microcontrollers pikloops -- Code generator for PIC delays tetex-eurofont -- Provides a command that prints a euro symbol utrac -- Universal Text Recognizer and Converter Any takers? Regards, Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. URL: From paul at city-fan.org Tue Sep 16 15:41:11 2008 From: paul at city-fan.org (Paul Howarth) Date: Tue, 16 Sep 2008 16:41:11 +0100 Subject: The state of resolv.conf In-Reply-To: <1221579151.4107.11.camel@gibraltar.str.redhat.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221557672.19134.15.camel@gibraltar.str.redhat.com> <48CF84F5.3010701@city-fan.org> <1221563959.19134.43.camel@gibraltar.str.redhat.com> <3da3b5b40809160434j12a23896k9123a1724d108913@mail.gmail.com> <20080916125136.GA8548@evileye.atkac.englab.brq.redhat.com> <1221579151.4107.11.camel@gibraltar.str.redhat.com> Message-ID: <48CFD397.7030001@city-fan.org> Nils Philippsen wrote: > On Tue, 2008-09-16 at 14:51 +0200, Adam Tkac wrote: >> On Tue, Sep 16, 2008 at 01:34:06PM +0200, Ahmed Kamal wrote: >>> Is there any current daemon that does this effect of directing name >>> resolution to specific servers according to IP ranges and/or domain names, >>> with the option of adding/removing servers on the fly ? Does dnsmasq do that >>> ? >>> >> What you mean with "according to IP ranges/domain names"? > [...] >> - if you want redirect target domains to different servers you can use >> BIND and forward zones: > > I would want to be able to do that based on domain names (which is > easily done with BIND) and on classless IP ranges. I don't think the > latter can be done as the IP ranges are octet-granular, e.g. > 10.in-addr.arpa for 10.0.0.0/8 -- I can't imagine how I would tell BIND > to use a certain server for e.g. 10.1.0.0/12 (where 4 MSB of the second > octet are part of the network address and the remaining 4 LSB are part > of the host address). You could do it as 16 separate /16 forwards but obviously that would be very ugly and doing it for a /17 would be much worse... Paul. From nils at redhat.com Tue Sep 16 15:42:06 2008 From: nils at redhat.com (Nils Philippsen) Date: Tue, 16 Sep 2008 17:42:06 +0200 Subject: The state of resolv.conf In-Reply-To: <20080916121849.GG23124@localhost.localdomain> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <20080916121849.GG23124@localhost.localdomain> Message-ID: <1221579726.4107.13.camel@gibraltar.str.redhat.com> On Tue, 2008-09-16 at 14:18 +0200, Martin Sivak wrote: > On Mon, Sep 15, 2008 at 02:20:37AM +0200, Ahmed Kamal wrote: > > I have an itch. I connect to work using openvpn. Works great, except that > > openvpn does not modify resolv.conf to add work's dns servers (now available > > through vpn). It does that on Windows though! I cannot expect openvpn or > > (any other application) to simply overwrite /etc/resolv.conf at will, but > > what is fedora missing to get an elegant solution to this problem ? > > Well, NM could handle it or take a look at the debian way. Their > resolvconf package does exacly what we need. What does resolveconf exactly do? I've googled it, but only find not very helpful forum messages ;-). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils at redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nils at redhat.com Tue Sep 16 15:44:23 2008 From: nils at redhat.com (Nils Philippsen) Date: Tue, 16 Sep 2008 17:44:23 +0200 Subject: The state of resolv.conf In-Reply-To: <48CFD397.7030001@city-fan.org> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221557672.19134.15.camel@gibraltar.str.redhat.com> <48CF84F5.3010701@city-fan.org> <1221563959.19134.43.camel@gibraltar.str.redhat.com> <3da3b5b40809160434j12a23896k9123a1724d108913@mail.gmail.com> <20080916125136.GA8548@evileye.atkac.englab.brq.redhat.com> <1221579151.4107.11.camel@gibraltar.str.redhat.com> <48CFD397.7030001@city-fan.org> Message-ID: <1221579863.4107.15.camel@gibraltar.str.redhat.com> On Tue, 2008-09-16 at 16:41 +0100, Paul Howarth wrote: > Nils Philippsen wrote: > > On Tue, 2008-09-16 at 14:51 +0200, Adam Tkac wrote: > >> On Tue, Sep 16, 2008 at 01:34:06PM +0200, Ahmed Kamal wrote: > >>> Is there any current daemon that does this effect of directing name > >>> resolution to specific servers according to IP ranges and/or domain names, > >>> with the option of adding/removing servers on the fly ? Does dnsmasq do that > >>> ? > >>> > >> What you mean with "according to IP ranges/domain names"? > > [...] > >> - if you want redirect target domains to different servers you can use > >> BIND and forward zones: > > > > I would want to be able to do that based on domain names (which is > > easily done with BIND) and on classless IP ranges. I don't think the > > latter can be done as the IP ranges are octet-granular, e.g. > > 10.in-addr.arpa for 10.0.0.0/8 -- I can't imagine how I would tell BIND > > to use a certain server for e.g. 10.1.0.0/12 (where 4 MSB of the second > > octet are part of the network address and the remaining 4 LSB are part > > of the host address). > > You could do it as 16 separate /16 forwards but obviously that would be > very ugly and doing it for a /17 would be much worse... Make that "I don't want to imagine..." then ;-). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils at redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From limb at jcomserv.net Tue Sep 16 15:46:17 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 16 Sep 2008 10:46:17 -0500 (CDT) Subject: Orphaning my packages In-Reply-To: <200809161740.01071.alain.portal@free.fr> References: <200809161740.01071.alain.portal@free.fr> Message-ID: <5123.198.175.55.5.1221579977.squirrel@mail.jcomserv.net> > Hi, > > As said some days ago, I want to release ownership of my packages: > > fcron -- A task scheduler > kbackup -- Back up your data in a simple, user friendly way > kicad -- Electronic schematic diagrams and printed circuit board artwork > man-pages-fr -- French version of the Linux man-pages > pikdev -- IDE for development of PICmicro based application (under > Linux/KDE) > piklab -- Development environment for applications based on PIC & dsPIC > microcontrollers > pikloops -- Code generator for PIC delays > tetex-eurofont -- Provides a command that prints a euro symbol > utrac -- Universal Text Recognizer and Converter > > Any takers? Will take kicad and utrac, if no one objects. > Regards, > Alain > -- > Les pages de manuel Linux en fran??ais > http://manpagesfr.free.fr/ > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From pertusus at free.fr Tue Sep 16 15:46:00 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 16 Sep 2008 17:46:00 +0200 Subject: Orphaning my packages In-Reply-To: <200809161740.01071.alain.portal@free.fr> References: <200809161740.01071.alain.portal@free.fr> Message-ID: <20080916154600.GD32189@free.fr> On Tue, Sep 16, 2008 at 05:40:00PM +0200, Alain PORTAL wrote: > Hi, > > As said some days ago, I want to release ownership of my packages: > > fcron -- A task scheduler I can take fcron. But it would be better if I were only co-maintainer. > man-pages-fr -- French version of the Linux man-pages Likewise if nobody wants it. > tetex-eurofont -- Provides a command that prints a euro symbol Isn't that package in texlive? -- Pat From mw_triad at users.sourceforge.net Tue Sep 16 15:46:14 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 16 Sep 2008 10:46:14 -0500 Subject: Beware: External repos can break key transition In-Reply-To: <48CF40AE.8080006@leemhuis.info> References: <1221158197.6431.24.camel@localhost.localdomain> <48CF0AD9.6040506@redhat.com> <48CF40AE.8080006@leemhuis.info> Message-ID: Thorsten Leemhuis wrote: > Thus yum will install the new xine-lib-extras-nonfree from Livna, but > not the matching xine-lib from Fedora. Thus all apps that rely on xine > will silently stop playing some videos that they were able to play > beforehand. Huh? If that happened, I'd sure file a bug... against either the package, for having a broken Requires:, or against yum/rpm for ignoring the Requires:. But I'm confused, because (at least in my case) yum correctly refused to install xine-libs-extras-nonfree until the matching xine-lib was also available, so I don't get how this would happen. -- Matthew There's no place like ~. -- Unknown From tcallawa at redhat.com Tue Sep 16 15:51:29 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 16 Sep 2008 11:51:29 -0400 Subject: Orphaning my packages In-Reply-To: <20080916154600.GD32189@free.fr> References: <200809161740.01071.alain.portal@free.fr> <20080916154600.GD32189@free.fr> Message-ID: <1221580289.29052.154.camel@localhost.localdomain> On Tue, 2008-09-16 at 17:46 +0200, Patrice Dumas wrote: > > tetex-eurofont -- Provides a command that prints a euro symbol > > Isn't that package in texlive? Probably. Anyways, I had to kill it in rawhide for licensing reasons. I haven't pulled it out of texlive yet because the maintainer finally replied to me and is considering relicensing to LPPL. ~spot From kevin.kofler at chello.at Tue Sep 16 15:52:38 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 16 Sep 2008 15:52:38 +0000 (UTC) Subject: Orphaning my packages References: <200809161740.01071.alain.portal@free.fr> Message-ID: Alain PORTAL free.fr> writes: > tetex-eurofont -- Provides a command that prints a euro symbol This one has been removed from Rawhide because it includes non-Free TTF fonts. So it's probably not worth picking it up, it should just be EOLed. Kevin Kofler From u0103a at gmail.com Tue Sep 16 15:55:45 2008 From: u0103a at gmail.com (jude ui) Date: Tue, 16 Sep 2008 11:55:45 -0400 Subject: hi Message-ID: <91157db90809160855i3eaf4b3en5fcddbec7d8060f@mail.gmail.com> hi -------------- next part -------------- An HTML attachment was scrubbed... URL: From cdahlin at redhat.com Tue Sep 16 16:00:19 2008 From: cdahlin at redhat.com (Casey Dahlin) Date: Tue, 16 Sep 2008 12:00:19 -0400 Subject: hi In-Reply-To: <91157db90809160855i3eaf4b3en5fcddbec7d8060f@mail.gmail.com> References: <91157db90809160855i3eaf4b3en5fcddbec7d8060f@mail.gmail.com> Message-ID: <48CFD813.8090206@redhat.com> jude ui wrote: > hi sup From lesmikesell at gmail.com Tue Sep 16 16:00:46 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 16 Sep 2008 11:00:46 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080916145753.GA32117@sonata.rednote.net> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <20080913172709.GF4421@sonata.rednote.net> <20080916145753.GA32117@sonata.rednote.net> Message-ID: <48CFD82E.3060704@gmail.com> Janina Sajka wrote: >>> But, I still launch 24 consoles when I boot, because I actually use most >>> of them in very specific ways. About 6 of these 24 run screen with 9 >>> separate terminal windows defined by ~/.screenrc. I don't see gnome >>> terminal replacing that anytime soon. >> It has tabs, and you can script it; I don't see what wouldn't work >> with your setup. >> > Perhaps when X evolves enough that we aren't limited to it on one > console. X has never been limited to one console - and the consoles are not required to be attached to the host. Fedora's pulseaudio configuration may assume otherwise, though. > Or, perhaps also when the at stack becomes much more robust. > Right now, while the gui has been usable (for about a year), it's prone > to something--God only knows what, because when my speech dies I have no > notion of any error, etc--I simply lose the whole environment. I'm not sure how it interacts with speech - or even audio at all, but freenx with the NX client from www.nomachine.com is fairly robust and lets you suspend and reconnect the display, possibly from different clients and locations. You might need to use the commercial version of the NX server to get audio to work remotely. > BTW: Not all my consoles are simple terminal screens. I run 9 mutt > instances in 9 screen terminals on Ctrl+Alt+F1, for instance. My inbox > is in Ctrl-A1, Fedora mail in Ctrl-a5, my standards related work in > Ctrl-a9, etc. Meanwhile, evolution and thunderbird are only marginally > usable from the screen reader perspective, and not with the same > alacrity that serves me in mutt. Heck, I can still cite specific web > pages where lynx does better than firefox3 from my a11y perspective. > Thankfully, there are plenty examples the other way around, too. I can't comment on how well you can find things on an NX screen without seeing them, but otherwise I find NX to be much nicer than screen in terms of being able to keep a whole desktop of programs running on a central well-connected host and being able to pick up the display on a work desktop, a roaming laptop, or through a vpn from home. You also have access to the native programs on the machine where you run the NX client, which might be linux, windows or a mac. I normally have enough terminal and firefox sessions running that gnome collates them to one task bar item that pops up a list when you click it. While I don't want text mode to go away, the NX approach fixes a lot of the problems with native X. -- Les Mikesell lesmikesell at gmail.com From alain.portal at free.fr Tue Sep 16 16:12:18 2008 From: alain.portal at free.fr (Alain PORTAL) Date: Tue, 16 Sep 2008 18:12:18 +0200 Subject: Orphaning my packages In-Reply-To: <20080916154600.GD32189@free.fr> References: <200809161740.01071.alain.portal@free.fr> <20080916154600.GD32189@free.fr> Message-ID: <200809161812.19271.alain.portal@free.fr> Le mardi 16 septembre 2008, Patrice Dumas a ?crit : > On Tue, Sep 16, 2008 at 05:40:00PM +0200, Alain PORTAL wrote: > > Hi, > > > > As said some days ago, I want to release ownership of my packages: > > > > fcron -- A task scheduler > > I can take fcron. But it would be better if I were only co-maintainer. Released. There is an open bug since 14 months for this package: https://bugzilla.redhat.com/show_bug.cgi?id=246922 There is a new version also: http://fcron.free.fr/download.php > > man-pages-fr -- French version of the Linux man-pages > > Likewise if nobody wants it. Released > > tetex-eurofont -- Provides a command that prints a euro symbol > > Isn't that package in texlive? I don't know. -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- 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 alain.portal at free.fr Tue Sep 16 16:22:00 2008 From: alain.portal at free.fr (Alain PORTAL) Date: Tue, 16 Sep 2008 18:22:00 +0200 Subject: Orphaning my packages In-Reply-To: <5123.198.175.55.5.1221579977.squirrel@mail.jcomserv.net> References: <200809161740.01071.alain.portal@free.fr> <5123.198.175.55.5.1221579977.squirrel@mail.jcomserv.net> Message-ID: <200809161822.01305.alain.portal@free.fr> Le mardi 16 septembre 2008, Jon Ciesla a ?crit : > > kicad -- Electronic schematic diagrams and printed circuit board artwork There is a new release since 3 weeks http://sourceforge.net/project/showfiles.php?group_id=145591 > > utrac -- Universal Text Recognizer and Converter No new release since more than 3 years, but there was no problem to build the package through the different Fedora releases, and I find this tool very useful. -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- 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 lesmikesell at gmail.com Tue Sep 16 16:23:47 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 16 Sep 2008 11:23:47 -0500 Subject: The state of resolv.conf In-Reply-To: <1221579151.4107.11.camel@gibraltar.str.redhat.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221557672.19134.15.camel@gibraltar.str.redhat.com> <48CF84F5.3010701@city-fan.org> <1221563959.19134.43.camel@gibraltar.str.redhat.com> <3da3b5b40809160434j12a23896k9123a1724d108913@mail.gmail.com> <20080916125136.GA8548@evileye.atkac.englab.brq.redhat.com> <1221579151.4107.11.camel@gibraltar.str.redhat.com> Message-ID: <48CFDD93.8020207@gmail.com> Nils Philippsen wrote: > On Tue, 2008-09-16 at 14:51 +0200, Adam Tkac wrote: >> On Tue, Sep 16, 2008 at 01:34:06PM +0200, Ahmed Kamal wrote: >>> Is there any current daemon that does this effect of directing name >>> resolution to specific servers according to IP ranges and/or domain names, >>> with the option of adding/removing servers on the fly ? Does dnsmasq do that >>> ? >>> >> What you mean with "according to IP ranges/domain names"? > [...] >> - if you want redirect target domains to different servers you can use >> BIND and forward zones: > > I would want to be able to do that based on domain names (which is > easily done with BIND) and on classless IP ranges. I don't think the > latter can be done as the IP ranges are octet-granular, e.g. > 10.in-addr.arpa for 10.0.0.0/8 -- I can't imagine how I would tell BIND > to use a certain server for e.g. 10.1.0.0/12 (where 4 MSB of the second > octet are part of the network address and the remaining 4 LSB are part > of the host address). For private ranges/domain views, you'd normally either have a local DNS server configured as primary or secondary for those zones that can also resolve public addresses, or for roaming vpn users you'd use a similar central private server that can resolve everything, public or private while you are connected. You'll quickly go insane if you try to mix unrelated private connections (for example, if there really are different parts of your 10.x.x.x range that don't know about each other). If there isn't some 'other' part of your 10.x range, you can point the whole /8 to a server that knows about the part you use. -- Les Mikesell lesmikesell at gmail.com From harald at redhat.com Tue Sep 16 16:28:43 2008 From: harald at redhat.com (Harald Hoyer) Date: Tue, 16 Sep 2008 18:28:43 +0200 Subject: NetworkworkManger and network based filesystem /usr In-Reply-To: <48CAC8E0.6030109@hhs.nl> References: <48CAAF49.3090105@hhs.nl> <20080912181213.GA3270@nostromo.devel.redhat.com> <48CAB839.3000305@hhs.nl> <20080912185149.GA5197@nostromo.devel.redhat.com> <48CAC8E0.6030109@hhs.nl> Message-ID: Hans de Goede wrote: > Agreed, but again I'm playing devils advocate. > > Anyways there seems to be some consensus that having /usr seperate from > / is a somewhat archaic usecase we which we do not necessarily want to > support. So for now I'll go and write patches for delay iscsi start when > using NetworkManager, just like netfs currently is started delayed. > > Regards, > > Hans > > I think _we want_ to support /usr on netfs for all those universities, companies, HPC clusters, etc.! From a.badger at gmail.com Tue Sep 16 16:27:48 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 16 Sep 2008 09:27:48 -0700 Subject: Advice request for mono packages In-Reply-To: <1221577740.29052.144.camel@localhost.localdomain> References: <1221568166.26602.28.camel@PB3.Linux> <1221577740.29052.144.camel@localhost.localdomain> Message-ID: <48CFDE84.4060000@gmail.com> Tom "spot" Callaway wrote: > On Tue, 2008-09-16 at 13:29 +0100, Paul wrote: >> It is something which is important for mono based packages that >> provide >> the source for non-GAC dlls and needs to be addressed in the packaging >> guidelines (something which needs altering a tad IMHO). > > This is really where we're working around bad coding practices from > upstream. > > Why doesn't Mono.Cecil adopt a stable API? Or at least a versioned API, > so that when they break API, they increment version and then things can > depend on a version of the API? > > This isn't rocket science. It isn't even novel. > > We don't generally permit package-local copies of system libraries for > lots of reasons, like the fact that they often miss bug fixes, security > fixes, often end up being duplicated in multiple packages and are much > more difficult to maintain. > If we have to I would be much more in favour of separate versioned package libraries in cases like these than having separate library versions in multiple application libraries. This means that when a security fix comes out, we can look at package names and decide we need to upgrade Mono.Cecil-1.0 to 1.0.1 and backport a fix to Mono-Cecil-0.9.1 instead of hunting on the filesystem for anything with a Mono.Cecil dll. Several notes to this: To make this work, upstreams for the dlls need to version their APIs as spot mentions. There is increased packager burden as packagers have to maintain multiple mono.cecil packages *and* may have to perform backports to old versions of the library that upstream no longer supports. Traditionally, we have worked on the application source to make it compile/run with newer versions of the API in strong preference to making compatible library packages. This should continue to be the case as we're either going to end up writing code to backport fixes to the dead-upstream-versions of the dlls or writing code to bring living applications up to speed with the newest versions of the libraries. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From pablo.martin-gomez at laposte.net Tue Sep 16 16:45:29 2008 From: pablo.martin-gomez at laposte.net (Martin-Gomez Pablo) Date: Tue, 16 Sep 2008 18:45:29 +0200 Subject: Orphaning my packages In-Reply-To: <200809161740.01071.alain.portal@free.fr> References: <200809161740.01071.alain.portal@free.fr> Message-ID: <20080916184529.65a844ff@laposte.net> Le Tue, 16 Sep 2008 17:40:00 +0200, Alain PORTAL a ?crit : > Hi, > > As said some days ago, I want to release ownership of my packages: > > fcron -- A task scheduler > kbackup -- Back up your data in a simple, user friendly way > kicad -- Electronic schematic diagrams and printed circuit board > artwork man-pages-fr -- French version of the Linux man-pages > pikdev -- IDE for development of PICmicro based application (under > Linux/KDE) piklab -- Development environment for applications based > on PIC & dsPIC microcontrollers > pikloops -- Code generator for PIC delays > tetex-eurofont -- Provides a command that prints a euro symbol > utrac -- Universal Text Recognizer and Converter > > Any takers? > > Regards, > Alain I would like to take man-pages-fr, and I would be please to be co-maintainer with Patrice. Regards, Pablo From hughsient at gmail.com Tue Sep 16 16:43:38 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 16 Sep 2008 17:43:38 +0100 Subject: Beware: External repos can break key transition In-Reply-To: <1221236098.10226.145.camel@localhost.localdomain> References: <1221158197.6431.24.camel@localhost.localdomain> <48C9721A.6070603@leemhuis.info> <48CA27D7.2080505@leemhuis.info> <1221215159.3284.51.camel@hughsie-work> <48CA73D8.1040902@nobugconsulting.ro> <1221232334.3284.81.camel@hughsie-work> <1221236098.10226.145.camel@localhost.localdomain> Message-ID: <1221583418.17490.14.camel@hughsie-work> On Fri, 2008-09-12 at 16:14 +0000, Paul W. Frields wrote: > I'm really not sure, my grammar is pretty awful. If somebody (you? :-) > > could have a look at all the translations and suggest fixes I would > be > > very grateful. > > "From" is correct, or at least preferred here. Fixed, thanks. If anyone is feeling brave, I've uploaded the whole pot file here: http://people.freedesktop.org/~hughsient/temp/gnome-packagekit.pot Comments and updates welcome. Thanks. Richard. From limb at jcomserv.net Tue Sep 16 17:18:29 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 16 Sep 2008 12:18:29 -0500 (CDT) Subject: Orphaning my packages In-Reply-To: <200809161822.01305.alain.portal@free.fr> References: <200809161740.01071.alain.portal@free.fr> <5123.198.175.55.5.1221579977.squirrel@mail.jcomserv.net> <200809161822.01305.alain.portal@free.fr> Message-ID: <64673.198.175.55.5.1221585509.squirrel@mail.jcomserv.net> > Le mardi 16 septembre 2008, Jon Ciesla a ?crit : > >> > kicad -- Electronic schematic diagrams and printed circuit board >> artwork > > There is a new release since 3 weeks > http://sourceforge.net/project/showfiles.php?group_id=145591 Thanks, I'll get on it. >> > utrac -- Universal Text Recognizer and Converter > > No new release since more than 3 years, but there was no problem to build > the > package through the different Fedora releases, and I find this tool very > useful. Sounds like a few of mine. :) > -- > Les pages de manuel Linux en fran?ais > http://manpagesfr.free.fr/ > -- novus ordo absurdum From ihok at hotmail.com Tue Sep 16 17:40:21 2008 From: ihok at hotmail.com (Jack Tanner) Date: Tue, 16 Sep 2008 17:40:21 +0000 (UTC) Subject: where's gimp-2.4.7 for F9 ? Message-ID: koji says it's in updates-testing, and so does bodhi. I don't see it in either updates-testing or in updates. Where'd it go? From sundaram at fedoraproject.org Tue Sep 16 17:45:35 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 16 Sep 2008 23:15:35 +0530 Subject: Fedora 10 feature owners--rescue your unfinished feature pages! In-Reply-To: <1221560362.48cf882a76ef9@ssl.mecca.ca> References: <48CF2C6A.303@redhat.com> <1221560362.48cf882a76ef9@ssl.mecca.ca> Message-ID: <48CFF0BF.9010803@fedoraproject.org> Luya Tshimbalanga wrote: > Quoting John Poelstra : > >> https://fedoraproject.org/wiki/Features/EchoIconTheme > > Current status was updated on 2008-08-11. I have recently added status to > reflect the progress on echo-icon-theme. Do we need to add release note to tell > echo is the current default icon set? Yes, that would be helpful. Rahul From a.badger at gmail.com Tue Sep 16 17:47:41 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 16 Sep 2008 10:47:41 -0700 Subject: scratch-build on untagged code [Was: Re: Proposal: Better force-tag] In-Reply-To: <1221563787.19134.39.camel@gibraltar.str.redhat.com> References: <1221234383.15726.194.camel@localhost.localdomain> <48CD1CA3.5060302@redhat.com> <1221402590.27183.172.camel@ignacio.lan> <48CD3358.8060105@poolshark.org> <1221409389.24484.1.camel@truman> <1221502515.1927.385.camel@firewall.xsintricity.com> <20080915135119.1a191264@ohm.scrye.com> <1221511756.1927.419.camel@firewall.xsintricity.com> <20080916095317.GB30868@mokona.greysector.net> <1221563787.19134.39.camel@gibraltar.str.redhat.com> Message-ID: <48CFF13D.3040706@gmail.com> Nils Philippsen wrote: > On Tue, 2008-09-16 at 11:53 +0200, Dominik 'Rathann' Mierzejewski wrote: >> On Tuesday, 16 September 2008 at 10:02, Matej Cepl wrote: >>> On 2008-09-15, 20:49 GMT, Doug Ledford wrote: >>>> I *could* do an srpm build to test ppc/ppc64 kernel builds, but >>>> it takes 30 minutes for a kernel srpm to upload to the build >>>> system from here (admittedly, I do this on my rhel kernel >>>> builds, I haven't been messing with Fedora kernels, but the >>>> point is valid regardless), so I commit, tag, build, fix, >>>> force-tag, build, fix, etc. >>> I don't want to immerse myself into this discussion (which >>> I haven't heard and read before), but this looks like bad >>> workaround around stupid problem. The problem here is IMHO that >>> koji is apparently not able to make a scratch build from untagged >>> (but commited) code. >> Wrong. You can use the tag "HEAD". > > Which doesn't help you if somebody else is concurrently working on the > same package and checks in things while you're waiting for your scratch > build. We could use "scratch-tags", but I find this a bit silly. IMO, > this is rather a point where using an SCM with a repo-wide revision-id > (instead of a per file one as used by CVS) would help. Who again was > looking for use-cases for different SCMs ;-)? > Actually... this is easily solved with tags that are generated by the system per build-request. If make build and make scratch-build automatically tagged, there wouldn't be any problem here. Instead of adding a make target for scratch-tags, take away make tag. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jjohnstn at redhat.com Tue Sep 16 18:04:24 2008 From: jjohnstn at redhat.com (Jeff Johnston) Date: Tue, 16 Sep 2008 14:04:24 -0400 Subject: Fedora 10 feature owners--rescue your unfinished feature pages! In-Reply-To: <48CF2C6A.303@redhat.com> References: <48CF2C6A.303@redhat.com> Message-ID: <48CFF528.30003@redhat.com> John Poelstra wrote: > I'm working to get > http://fedoraproject.org/wiki/Releases/10/FeatureList into a near > final state. This important for our beta release notes and > announcement as well as accurately advertising the features that > *will* be in Fedora 10. It is also very important for focusing our > testing efforts! > > According to a review of all the feature pages, the following features > have not been updated since the Feature Freeze on 2008-09-11 and/or > are not 100% complete. > > https://fedoraproject.org/wiki/Features/Eclipse34 > I have just updated this. -- Jeff J. From jkeating at redhat.com Tue Sep 16 18:11:16 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 16 Sep 2008 11:11:16 -0700 Subject: scratch-build on untagged code [Was: Re: Proposal: Better force-tag] In-Reply-To: <48CFF13D.3040706@gmail.com> References: <1221234383.15726.194.camel@localhost.localdomain> <48CD1CA3.5060302@redhat.com> <1221402590.27183.172.camel@ignacio.lan> <48CD3358.8060105@poolshark.org> <1221409389.24484.1.camel@truman> <1221502515.1927.385.camel@firewall.xsintricity.com> <20080915135119.1a191264@ohm.scrye.com> <1221511756.1927.419.camel@firewall.xsintricity.com> <20080916095317.GB30868@mokona.greysector.net> <1221563787.19134.39.camel@gibraltar.str.redhat.com> <48CFF13D.3040706@gmail.com> Message-ID: <1221588676.4736.25.camel@luminos.localdomain> On Tue, 2008-09-16 at 10:47 -0700, Toshio Kuratomi wrote: > Actually... this is easily solved with tags that are generated by the > system per build-request. If make build and make scratch-build > automatically tagged, there wouldn't be any problem here. Instead of > adding a make target for scratch-tags, take away make tag. You're also talking about two distinct uses of scratch-build. There is a scratch-build where you want to test something that either doesn't exist in Fedora yet, or changes you don't want committed yet. This is where building from srpm and not from SCM is important. Then there is a scratch-build where you just want to test that what you've committed actually works, and this is usually done by just building and cleaning up anything that fails. This build requires that content be in SCM and come from a CVS URL. We /prefer/ this tag not be #HEAD, and that the tag comes from 'make tag'. However there isn't anything that enforces this. The only "enforcement" is that the CVS url provided... works. There is a build type that can be done, that doesn't immediately result in a build being tagged. It's a normal build in every way, it comes from a CVS url, its tracked through the system, the results are imported. However the last step, the tag step, is skipped. This means the build exists in the "system" but it is as of yet not tagged for any collection. This would allow the submitter to attempt a build, test the results, and make a decision after the fact as to if it's suitable to be published via a tag. --skip-tag is the option to koji build, I don't believe we have that hooked up into the Make system at all. Some of the problems with it is that it's very easy to do the build and forget to later tag, or do the build and accidentally tag into the wrong collection. That said, the value of being able to do a trial build, test it as functional, and stamp your approval on it is pretty high. None of that though helps the case where the build fails and you wish to alter something without progressing the n-v-r. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From lmacken at redhat.com Tue Sep 16 18:15:57 2008 From: lmacken at redhat.com (Luke Macken) Date: Tue, 16 Sep 2008 14:15:57 -0400 Subject: where's gimp-2.4.7 for F9 ? In-Reply-To: References: Message-ID: <20080916181557.GD6117@x300.bos.redhat.com> On Tue, Sep 16, 2008 at 05:40:21PM +0000, Jack Tanner wrote: > koji says it's in updates-testing, and so does bodhi. I don't see it in either > updates-testing or in updates. Where'd it go? The repos are syncing out the master mirror now. This version of gimp is present in the f9-updates-testing repo. luke From fedora at leemhuis.info Tue Sep 16 18:33:16 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 16 Sep 2008 20:33:16 +0200 Subject: Beware: External repos can break key transition In-Reply-To: References: <1221158197.6431.24.camel@localhost.localdomain> <48CF0AD9.6040506@redhat.com> <48CF40AE.8080006@leemhuis.info> Message-ID: <48CFFBEC.2030102@leemhuis.info> On 16.09.2008 17:46, Matthew Woehlke wrote: > Thorsten Leemhuis wrote: >> Thus yum will install the new xine-lib-extras-nonfree from Livna, but >> not the matching xine-lib from Fedora. Thus all apps that rely on xine >> will silently stop playing some videos that they were able to play >> beforehand. > > Huh? If that happened, I'd sure file a bug... against either the > package, for having a broken Requires:, or against yum/rpm for ignoring > the Requires:. But I'm confused, because (at least in my case) yum > correctly refused to install xine-libs-extras-nonfree until the matching > xine-lib was also available, so I don't get how this would happen. This afaics would happen if Livna would have done what was suggested in https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01462.html So it was just hypothetical. Cu knurd From janina at rednote.net Tue Sep 16 18:34:44 2008 From: janina at rednote.net (Janina Sajka) Date: Tue, 16 Sep 2008 14:34:44 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <48CEAD51.9050700@gmail.com> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> Message-ID: <20080916183444.GA4973@sonata.rednote.net> I just decided to give pa another go--so that I could speak from recent experience. I went to my /etc/alsa/alsa.conf and uncommented line 11. Then, I rebooted. 1.) There continues to be no audio indication of when gdm is ready. This despite the fact that I have "SoundOnLogin=true" in my /etc/gdm/custom.conf. The builtin GDM "audio icon" doesn't play, neither does GDM beep when it launches, nor can I get a beep from pressing back-space. 2.) Ctrl-S does not work in GDM. This is gdm-2.22.0-8.fc9. Should I try from rawhide? 3.) Logging in I hear first the GDM "audio logo," think I'll call it an earcon from now on. But, Orca launches in my secondary audio device. That's inappropriate, but I have no way to control that except to unplug my secondary and tertiary audio devices and start over. 4.) Logging back in with only one audio device on board, Orca does indeed startup on that device--but it seems I have to choose between Orca and playing other audio. How quaint! I thought we got past this silly "one sound at a time" view back around alsa-0.9. Does anyone recall the alsa FAQ used to claim this was appropriate back then? Well, it still isn't appropriate, but that's what's happening. If I paplay some .wav from a Gnome-Terminal, then attempt to go somewhere off my Alt-F1 (Applications) menu--there's no Orca until my .wav ends. I guess it would be like the screen blanking while the cd audio disc plays? Very curious, indeed. 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented from doing so, paplay believes it should pause playing while I'm away from the gui tty. Now, who's the genius that figured out this "feature?" Needless to say, line 11 is again pounded off. Janina 1. -- Janina Sajka, Phone: +1.202.595.7777; sip:janina at a11y.org Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada Learn more at http://ScreenlessPhone.Com Chair, Open Accessibility janina at a11y.org Linux Foundation http://a11y.org From mclasen at redhat.com Tue Sep 16 19:12:46 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 16 Sep 2008 15:12:46 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080916183444.GA4973@sonata.rednote.net> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> Message-ID: <1221592366.32342.23.camel@localhost.localdomain> On Tue, 2008-09-16 at 14:34 -0400, Janina Sajka wrote: > I just decided to give pa another go--so that I could speak from recent > experience. I went to my /etc/alsa/alsa.conf and uncommented line 11. > Then, I rebooted. > > 1.) There continues to be no audio indication of when gdm is ready. > This despite the fact that I have "SoundOnLogin=true" in my > /etc/gdm/custom.conf. The builtin GDM "audio icon" doesn't play, neither > does GDM beep when it launches, nor can I get a beep from pressing > back-space. What is the 'builtin audio icon' ? I have no idea what you are talking about here. And I've explained months ago how you can get a sound when the login screen appears - assuming you are willing to make simple customizations, which seems to be the case, considering that you are editing alsa.conf... Why do you expect to get a beep from pressing backspace ? You can get beeps in all sorts of ways: pressing up arrow, pressing enter, followed by backspace, etc... > 2.) Ctrl-S does not work in GDM. This is gdm-2.22.0-8.fc9. Should I > try from rawhide? Yeah, I know we wanted to add such global hotkeys to gnome-settings-daemon, but it hasn't happened, as far as I can see. I'll try to find out where that stands. But this is not very related to pulseaudio anyway... > 3.) Logging in I hear first the GDM "audio logo," think I'll call it > an earcon from now on. But, Orca launches in my secondary audio device. > That's inappropriate, but I have no way to control that except to unplug > my secondary and tertiary audio devices and start over. Hardly pulseaudios fault if orca picks the wrong device. I have no idea how orca decides which device to use. > 4.) Logging back in with only one audio device on board, Orca does > indeed startup on that device--but it seems I have to choose between > Orca and playing other audio. How quaint! I thought we got past this > silly "one sound at a time" view back around alsa-0.9. Does anyone > recall the alsa FAQ used to claim this was appropriate back then? I don't recall old alsa FAQs, but you can observe that all the rest of the desktop happily shares the output device under pulseaudios control. You'd think it should be possible for orca to do the same. That it is not doing so is again not pulseaudios fault... > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented > from doing so, paplay believes it should pause playing while I'm away > from the gui tty. Now, who's the genius that figured out this "feature?" Insults won't help your cause. From walters at verbum.org Tue Sep 16 19:19:03 2008 From: walters at verbum.org (Colin Walters) Date: Tue, 16 Sep 2008 15:19:03 -0400 Subject: Non-X text mode console In-Reply-To: <20080916151742.GB32117@sonata.rednote.net> References: <20080915151812.0730561B48E@hormel.redhat.com> <48CEA6D3.90906@herr-schmitt.de> <20080916151742.GB32117@sonata.rednote.net> Message-ID: On Tue, Sep 16, 2008 at 11:17 AM, Janina Sajka wrote: > > You're assuming the X-based assistive technology will become at least as > performant as the non X technology is today. I certainly don't regard > this to be impossible. I simply note we're not there. I am trongly suggesting that accessibility efforts focus on X based technology, because that is the focus of the work that goes on in the desktop. > But, I suspect we would also need multiple x-terms. gnome-terminal has tabs. And multiple windows. From tcallawa at redhat.com Tue Sep 16 19:02:04 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 16 Sep 2008 15:02:04 -0400 Subject: Updates to Fedora Packaging Guidelines Message-ID: <1221591724.29052.171.camel@localhost.localdomain> Hi Fedorans! The Fedora Packaging Committee has made some updates to the Fedora Packaging Guidelines. All of these changes were approved by the Fedora Packaging Committee and ratified by FESCo. Specifically: * There are now language specific guidelines for Haskell and Lisp See: https://fedoraproject.org/wiki/Packaging/Haskell https://fedoraproject.org/wiki/Packaging/Lisp * The Packaging/Guidelines have new sections covering: - Noting Patch Upstream Status https://fedoraproject.org/wiki/Packaging/Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment - Bundling multiple upstream items in a single package https://fedoraproject.org/wiki/Packaging/Guidelines#Bundling_of_multiple_projects - Avoiding font bundling https://fedoraproject.org/wiki/Packaging/Guidelines#Avoid_bundling_of_fonts_in_other_packages In addition, the Desktop files section has been updated to reflect the permitted usage of desktop-file-install: https://fedoraproject.org/wiki/Packaging/Guidelines#Desktop_files Thanks to everyone who helped in the process of amending the Fedora Guidelines. ~spot _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From rc040203 at freenet.de Tue Sep 16 19:26:19 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 16 Sep 2008 21:26:19 +0200 Subject: where's gimp-2.4.7 for F9 ? In-Reply-To: <20080916181557.GD6117@x300.bos.redhat.com> References: <20080916181557.GD6117@x300.bos.redhat.com> Message-ID: <1221593179.18327.806.camel@beck.corsepiu.local> On Tue, 2008-09-16 at 14:15 -0400, Luke Macken wrote: > On Tue, Sep 16, 2008 at 05:40:21PM +0000, Jack Tanner wrote: > > koji says it's in updates-testing, and so does bodhi. I don't see it in either > > updates-testing or in updates. Where'd it go? > > The repos are syncing out the master mirror now. This version of gimp > is present in the f9-updates-testing repo. f9-updates-testing or f9-updates-testing.newkey? # rpm -qf /etc/yum.repos.d/fedora-updates-testing-newkey.repo fedora-release-9-5.transition.noarch Ralf From dcbw at redhat.com Tue Sep 16 19:53:43 2008 From: dcbw at redhat.com (Dan Williams) Date: Tue, 16 Sep 2008 15:53:43 -0400 Subject: The state of resolv.conf In-Reply-To: <1221579726.4107.13.camel@gibraltar.str.redhat.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <20080916121849.GG23124@localhost.localdomain> <1221579726.4107.13.camel@gibraltar.str.redhat.com> Message-ID: <1221594823.19977.3.camel@localhost.localdomain> On Tue, 2008-09-16 at 17:42 +0200, Nils Philippsen wrote: > On Tue, 2008-09-16 at 14:18 +0200, Martin Sivak wrote: > > On Mon, Sep 15, 2008 at 02:20:37AM +0200, Ahmed Kamal wrote: > > > I have an itch. I connect to work using openvpn. Works great, except that > > > openvpn does not modify resolv.conf to add work's dns servers (now available > > > through vpn). It does that on Windows though! I cannot expect openvpn or > > > (any other application) to simply overwrite /etc/resolv.conf at will, but > > > what is fedora missing to get an elegant solution to this problem ? > > > > Well, NM could handle it or take a look at the debian way. Their > > resolvconf package does exacly what we need. > > What does resolveconf exactly do? I've googled it, but only find not > very helpful forum messages ;-). AFAIK you invoke it with "-a" and a "tag" that names your configuration, and then dump some config to it over stdin. Then when you're done with that config (or exiting) you invoke it with "-d" and it removes that config and replaces the previous one. NM does what resolvconf also does. Resolvconf is used in debian and (was) maybe SUSE for quite a while until they switched to something called netconf instead. resolvconf still requires modifications to programs so that they talk to resolvconf and don't just overwrite /etc/resolv.conf. Dan From carl at five-ten-sg.com Tue Sep 16 19:53:14 2008 From: carl at five-ten-sg.com (Carl Byington) Date: Tue, 16 Sep 2008 12:53:14 -0700 Subject: beta freeze vs. bug fixes Message-ID: <1221594794.11556.31.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am a new packager, and not that familiar with the fedora procedures regarding beta (or other) freezes. I presume those are handled with cvs tagging operations, that are generally transparent to packagers. I have a new version of my package (libpst) with some bug fixes that would be nice to be in fedora 10. Can those be added with the normal cvs commit make tag make build now, or should I wait for some unfreeze event? Is there some packager documentation that explains the required procedures around these freezes? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD4DBQFI0A6WL6j7milTFsERAt4NAJ945z3+tzmt1BX6w37cWfAJHNG4tgCUCgH8 XHYZRpoe2zU9p8NjkLOfFQ== =wF1U -----END PGP SIGNATURE----- From lesmikesell at gmail.com Tue Sep 16 19:57:42 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 16 Sep 2008 14:57:42 -0500 Subject: Non-X text mode console In-Reply-To: References: <20080915151812.0730561B48E@hormel.redhat.com> <48CEA6D3.90906@herr-schmitt.de> <20080916151742.GB32117@sonata.rednote.net> Message-ID: <48D00FB6.5050900@gmail.com> Colin Walters wrote: > On Tue, Sep 16, 2008 at 11:17 AM, Janina Sajka wrote: >> You're assuming the X-based assistive technology will become at least as >> performant as the non X technology is today. I certainly don't regard >> this to be impossible. I simply note we're not there. > > I am trongly suggesting that accessibility efforts focus on X based > technology, because that is the focus of the work that goes on in the > desktop. > >> But, I suspect we would also need multiple x-terms. > > gnome-terminal has tabs. And multiple windows. > And the gnome desktop will collapse a large number of them into one item in the task bar that expands to a list showing the window label (defaulting to user at host:/path) of each. I don't know if there are accessibility hooks to read the task bar or the expanded list, though, or after you select one and pop it to the front, how you find it on the screen. -- Les Mikesell lesmikesell at gmail.com From limb at jcomserv.net Tue Sep 16 20:00:31 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 16 Sep 2008 15:00:31 -0500 (CDT) Subject: beta freeze vs. bug fixes In-Reply-To: <1221594794.11556.31.camel@ns.five-ten-sg.com> References: <1221594794.11556.31.camel@ns.five-ten-sg.com> Message-ID: <3185.198.175.55.5.1221595231.squirrel@mail.jcomserv.net> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I am a new packager, and not that familiar with the fedora procedures > regarding beta (or other) freezes. I presume those are handled with cvs > tagging operations, that are generally transparent to packagers. I have > a new version of my package (libpst) with some bug fixes that would be > nice to be in fedora 10. Can those be added with the normal > > cvs commit > make tag > make build > > now, or should I wait for some unfreeze event? Is there some packager > documentation that explains the required procedures around these > freezes? Do it now. It won't be in the beta, but will still make F10 if it beats the Final Freeze, IIRC. If it doesn't, it won't be in F10 GA, but can be pushed as an update via Bodhi immediately thereafter. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > > iD4DBQFI0A6WL6j7milTFsERAt4NAJ945z3+tzmt1BX6w37cWfAJHNG4tgCUCgH8 > XHYZRpoe2zU9p8NjkLOfFQ== > =wF1U > -----END PGP SIGNATURE----- > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From cra at WPI.EDU Tue Sep 16 20:12:47 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 16 Sep 2008 16:12:47 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080916183444.GA4973@sonata.rednote.net> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> Message-ID: <20080916201247.GA32741@angus.ind.WPI.EDU> On Tue, Sep 16, 2008 at 02:34:44PM -0400, Janina Sajka wrote: > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented > from doing so, paplay believes it should pause playing while I'm away > from the gui tty. Now, who's the genius that figured out this "feature?" That's ConsoleKit deactivating the streams on the non-active console. This is so mult-user-switching can work and each user can have their own audio. From jspaleta at gmail.com Tue Sep 16 20:46:46 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 16 Sep 2008 12:46:46 -0800 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080916201247.GA32741@angus.ind.WPI.EDU> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> Message-ID: <604aa7910809161346n7c93e3c5ma0c1e92994effed7@mail.gmail.com> On Tue, Sep 16, 2008 at 12:12 PM, Chuck Anderson wrote: > That's ConsoleKit deactivating the streams on the non-active console. > This is so mult-user-switching can work and each user can have their > own audio. Technically.. is it PolicyKit or ConsoleKit doing the deactivation? I always get confused as to which one of those is doing what. Regardless, PolicyKit's authorization mechanisms both on the cmdline and the gui should be usable to change how access control for the streams work to widen the access scope to sound devices to any user at the console and not just the active console..or even wider if desired. -jef From Matt_Domsch at dell.com Tue Sep 16 20:57:09 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 16 Sep 2008 15:57:09 -0500 Subject: orphaning python packages Message-ID: <20080916205709.GA9224@auslistsprd01.us.dell.com> Shahms King would like to orphan his packages due to other time commitments outside of Fedora. We thank him for his involvement thusfar and look forward to his return. Until then, these packages are up for grabs. I'll ask Toshio to mark them as orphans. python-lxml -- ElementTree-like Python bindings for libxml2 and libxslt python-protocols -- Open Protocols and Component Adaptation for Python python-psyco -- The Python Specialing Compiler python-psycopg -- PostgreSQL database adapter for Python python-quixote -- A highly Pythonic Web application framework python-simpletal -- An XML based template processor for TAL, TALES and METAL specifications. python-tpg -- A Python "toy parser generator" Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Tue Sep 16 20:58:08 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 16 Sep 2008 15:58:08 -0500 Subject: orphaning python packages In-Reply-To: <20080916205709.GA9224@auslistsprd01.us.dell.com> References: <20080916205709.GA9224@auslistsprd01.us.dell.com> Message-ID: <20080916205808.GB9224@auslistsprd01.us.dell.com> On Tue, Sep 16, 2008 at 03:57:09PM -0500, Matt Domsch wrote: > Shahms King would like to orphan his packages due to other time > commitments outside of Fedora. We thank him for his involvement > thusfar and look forward to his return. > > Until then, these packages are up for grabs. I'll ask Toshio to mark > them as orphans. > > > python-lxml -- ElementTree-like Python bindings for libxml2 and libxslt > > python-protocols -- Open Protocols and Component Adaptation for Python > > python-psyco -- The Python Specialing Compiler > > python-psycopg -- PostgreSQL database adapter for Python > > python-quixote -- A highly Pythonic Web application framework > > python-simpletal -- An XML based template processor for TAL, TALES and > METAL specifications. > > python-tpg -- A Python "toy parser generator" This one too... python-paramiko -- A SSH2 protocol library for python -Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From alain.portal at free.fr Tue Sep 16 21:00:15 2008 From: alain.portal at free.fr (Alain PORTAL) Date: Tue, 16 Sep 2008 23:00:15 +0200 Subject: They are really asshole! Message-ID: <200809162300.16635.alain.portal@free.fr> Hey FESCo! Wake up!!! Just after I said on devel list I'm orphaning my packages, I post also a message on a fedora-fr.org forum to say man-pages-fr is orphaned and it is searching for a maintainer, nothing else... I'm sure Martin-Gomez answer on the list after he saw my post on the forum. But nobody can read this post any more. Less than two hours after my post, this post have been deleted.... Why ? I don't see any reason but that they are really fucking assholes! FESCo, you don't listen to me when I warm you a few months ago about the fedora-fr association... Sorry, french below, hope you could find somebody who is able translate [1] ? Tant pis pour vous ! ? Vous ne maitrisez rien et ils en sont fiers ! Comme l'avait dit quelqu'un (d?sol?, pas de lien ? fournir, je n'ai plus le message dans ma bo?te, mais si vous faites un effort, vous trouverez...), une bonne chose serait leur retirer le droit ? l'utilisation du nom et du logo Fedora. Mais faut des couilles pour ?a ! Alors ? Vous les avez ? Non. Je le savais, alors... Adieu [1] Comme la GPL, seule la version originale fait foi -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- 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 walters at verbum.org Tue Sep 16 21:02:43 2008 From: walters at verbum.org (Colin Walters) Date: Tue, 16 Sep 2008 17:02:43 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <604aa7910809161346n7c93e3c5ma0c1e92994effed7@mail.gmail.com> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <604aa7910809161346n7c93e3c5ma0c1e92994effed7@mail.gmail.com> Message-ID: On Tue, Sep 16, 2008 at 4:46 PM, Jeff Spaleta wrote: > On Tue, Sep 16, 2008 at 12:12 PM, Chuck Anderson wrote: >> That's ConsoleKit deactivating the streams on the non-active console. >> This is so mult-user-switching can work and each user can have their >> own audio. > > Technically.. is it PolicyKit or ConsoleKit doing the deactivation? > I always get confused as to which one of those is doing what. Neither actually - pulseaudio is listening to ConsoleKit events and giving up the stream itself. > Regardless, PolicyKit's authorization mechanisms both on the cmdline > and the gui should be usable to change how access control for the > streams work to widen the access scope to sound devices to any user at > the console and not just the active console..or even wider if desired. This is a bit of a grey area between "system configuration" and "security", but I'd suggest that if someone needs the ability to change the behavior, that should be a change to pulseaudio and not try to express it in policykit. From csnook at redhat.com Tue Sep 16 21:02:34 2008 From: csnook at redhat.com (Chris Snook) Date: Tue, 16 Sep 2008 17:02:34 -0400 Subject: Non-X text mode console In-Reply-To: <16de708d0809151835q1daf91ebn8e5b94be2a5548cf@mail.gmail.com> References: <20080915151812.0730561B48E@hormel.redhat.com> <48CF0652.5080208@redhat.com> <16de708d0809151835q1daf91ebn8e5b94be2a5548cf@mail.gmail.com> Message-ID: <48D01EEA.7020904@redhat.com> Arthur Pemberton wrote: > On Mon, Sep 15, 2008 at 8:05 PM, Chris Snook wrote: >> sean darcy wrote: >>> David A. Wheeler wrote: >>>> I routinely use text mode console without X, for a >>>> variety of reasons. For example: >>>> * I have a number of systems (servers) at runlevel 3 >>>> * console is critically important when X fails. "Log in with ssh" >>>> doesn't work when ssh or the network fails. >>> Have I missed something...big? If I can't ssh into those boxes, can't I >>> have someone just use the console in person? Some of these boxes are ooold - >>> 600mhz 256mb, which BTW, works superbly at runlevel 3. X would be a real >>> strain, and is generally not even installed. >>> >>> Tell me it ain't so. >>> >>> sean >>> >> It ain't so. This is a gross misunderstanding of the fact that we're moving >> to using a kernel framebuffer by default, like some distros did almost a >> decade ago. And you can opt out with 'nomodeset' on the boot command line, >> to get the old vga BIOS framebuffer. > > > Sorry for acting dumb, but I'll ask the question that I have: > > Will I be able to do Ctrl+Alt+F1? And will I be able to use a machine > locally without X? > Yes. The only difference will be that the framebuffer is managed by the kernel instead of the video BIOS. On most non-x86 architectures, this is how it has been done since the dawn of time. It's been supported on x86 for a very long time too, but we've chosen not to enable it by default, for various reasons, until now. -- Chris From skvidal at fedoraproject.org Tue Sep 16 21:02:10 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Tue, 16 Sep 2008 17:02:10 -0400 Subject: orphaning python packages In-Reply-To: <20080916205709.GA9224@auslistsprd01.us.dell.com> References: <20080916205709.GA9224@auslistsprd01.us.dell.com> Message-ID: <1221598930.5296.6.camel@rosebud> On Tue, 2008-09-16 at 15:57 -0500, Matt Domsch wrote: > Shahms King would like to orphan his packages due to other time > commitments outside of Fedora. We thank him for his involvement > thusfar and look forward to his return. > > Until then, these packages are up for grabs. I'll ask Toshio to mark > them as orphans. > > > python-lxml -- ElementTree-like Python bindings for libxml2 and libxslt > > python-protocols -- Open Protocols and Component Adaptation for Python > > python-psyco -- The Python Specialing Compiler > > python-psycopg -- PostgreSQL database adapter for Python > > python-quixote -- A highly Pythonic Web application framework > > python-simpletal -- An XML based template processor for TAL, TALES and > METAL specifications. > > python-tpg -- A Python "toy parser generator" > worth mentioning - a lot of things depend on these pkgs. -sv From benny+usenet at amorsen.dk Tue Sep 16 21:04:39 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Tue, 16 Sep 2008 23:04:39 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <48CE65A9.8040401@poolshark.org> (Denis Leroy's message of "Mon\, 15 Sep 2008 15\:39\:53 +0200") References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> Message-ID: Denis Leroy writes: > I occasionally run into a Gnome app bug where drag'n'drop "hangs" the > desktop (the "drag" never "drops", sort of) where the only way out is > ctrl-alt-f1 to mingetty and killall the user-space app. Without > mingetty, ctrl-alt-del is the only other option (i.e. loose all > unsaved documents). ctrl-alt-f1 is iffy on a lot of machines. Sometimes you need a reboot to get back to X. Having the kernel involved in the whole affair has a somewhat better chance of working. Well that or we might get a Linus rant; that often gets things fixed a bit faster. No, I haven't filed bugs for that. Sorry. I prefer to file bugs for problems I can reliably reproduce; at least then I have a chance to keep the bug open when the system tries to close it after the next Fedora release. /Benny From jspaleta at gmail.com Tue Sep 16 21:09:56 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 16 Sep 2008 13:09:56 -0800 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <604aa7910809161346n7c93e3c5ma0c1e92994effed7@mail.gmail.com> Message-ID: <604aa7910809161409u21ccede0t7f0abc11d1c85128@mail.gmail.com> On Tue, Sep 16, 2008 at 1:02 PM, Colin Walters wrote: > This is a bit of a grey area between "system configuration" and > "security", but I'd suggest that if someone needs the ability to > change the behavior, that should be a change to pulseaudio and not try > to express it in policykit. So its appropriate for policykit to expose direct access to sound devices via hal? But not control over pulseaudio streams? Hmm... -jef From kevin.kofler at chello.at Tue Sep 16 21:11:08 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 16 Sep 2008 21:11:08 +0000 (UTC) Subject: They are really asshole! References: <200809162300.16635.alain.portal@free.fr> Message-ID: Alain PORTAL free.fr> writes: > Sorry, french below, hope you could find somebody who is able translate [1] Translation here (marked with "->" quotes). Disclaimer: I'm trying hard to be 100% accurate here, but I cannot exclude mistranslations, especially when it comes to subtle implicit meaning. The accuracy of translations is often a big problem in conflict situations. > ? Tant pis pour vous ! ? -> "Bad luck for you!" > Vous ne maitrisez rien et ils en sont fiers ! -> You do not control anything and they are proud of it! > Comme l'avait dit quelqu'un (d?sol?, pas de lien ? fournir, je n'ai plus le > message dans ma bo?te, mais si vous faites un effort, vous trouverez...), une > bonne chose serait leur retirer le droit ? l'utilisation du nom et du logo > Fedora. -> As somebody had said (sorry, no link to provide, I do not have the message -> in the mailbox anymore, but if you try hard enough, you will find it...), a -> good thing would be to withdraw their right to use the Fedora name and logo. > Mais faut des couilles pour ?a ! -> But that needs balls! > Alors ? Vous les avez ? -> So? Do you have them? > Non. -> No. > Je le savais, alors... -> I knew it, so... > Adieu -> Farewell > [1] Comme la GPL, seule la version originale fait foi -> As for the GPL, only the original is binding Disclaimer: the above are TRANSLATIONS, they do not necessarily reflect my own opinion. I haven't followed the conflict, so I can't judge what's really going on over at fedora-fr. I hope this helps so non-French-speakers can figure out what's going on. Kevin Kofler From benny+usenet at amorsen.dk Tue Sep 16 21:13:35 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Tue, 16 Sep 2008 23:13:35 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <48CEA21F.8000605@gmail.com> (Suren Karapetyan's message of "Mon\, 15 Sep 2008 22\:57\:51 +0500") References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE8A5C.4090902@poolshark.org> <48CEA21F.8000605@gmail.com> Message-ID: Suren Karapetyan writes: > Having to run X (and you know... it won't start with less then 256M > ram) on every machine with Fedora is a real problem. The Nokia 770 runs X. Back in the day, 8MB 486's ran X. Heck, Sun 5-60's (68020's with 6MB of memory) ran X quite nicely. When you see X in "top", a lot of its memory use is actually graphics card memory. An X solution is not impossible. I'm not saying it's the answer, but you can't rule it out like that. /Benny From nicoleau.fabien at gmail.com Tue Sep 16 21:19:44 2008 From: nicoleau.fabien at gmail.com (Nicoleau Fabien) Date: Tue, 16 Sep 2008 23:19:44 +0200 Subject: They are really asshole! In-Reply-To: <200809162300.16635.alain.portal@free.fr> References: <200809162300.16635.alain.portal@free.fr> Message-ID: <48D022F0.2050708@gmail.com> Alain PORTAL a ?crit : > Hey FESCo! Wake up!!! > > Just after I said on devel list I'm orphaning my packages, I post also a > message on a fedora-fr.org forum to say man-pages-fr is orphaned and it is > searching for a maintainer, nothing else... > I'm sure Martin-Gomez answer on the list after he saw my post on the forum. > But nobody can read this post any more. > > Less than two hours after my post, this post have been deleted.... > Why ? > I don't see any reason but that they are really fucking assholes! > > FESCo, you don't listen to me when I warm you a few months ago about the > fedora-fr association... > > Sorry, french below, hope you could find somebody who is able translate [1] > > ? Tant pis pour vous ! ? > Vous ne maitrisez rien et ils en sont fiers ! > Comme l'avait dit quelqu'un (d?sol?, pas de lien ? fournir, je n'ai plus le > message dans ma bo?te, mais si vous faites un effort, vous trouverez...), une > bonne chose serait leur retirer le droit ? l'utilisation du nom et du logo > Fedora. > Mais faut des couilles pour ?a ! > Alors ? Vous les avez ? > Non. > Je le savais, alors... > Adieu > > > [1] Comme la GPL, seule la version originale fait foi > It's false. Your post is always available here: http://forums.fedora-fr.org/viewtopic.php?id=35529 and has never been deleted. Nicoleau Fabien (eponyme) From csnook at redhat.com Tue Sep 16 21:20:46 2008 From: csnook at redhat.com (Chris Snook) Date: Tue, 16 Sep 2008 17:20:46 -0400 Subject: kernel-devel in "Fedora" spin? In-Reply-To: <20080916020742.GA11480@yoda.jdub.homelinux.org> References: <1221522171.2102.6.camel@luminos.localdomain> <48CF04A1.7020801@redhat.com> <20080916020742.GA11480@yoda.jdub.homelinux.org> Message-ID: <48D0232E.7080101@redhat.com> Josh Boyer wrote: > On Mon, Sep 15, 2008 at 08:58:09PM -0400, Chris Snook wrote: >> Jesse Keating wrote: >>> Back in December, I had made a change that blocked kernel-devel packages >>> from winding up in the install media for the Fedora spin. I don't >>> recall getting any push back at the time, but I've gotten at least one >>> angry comment since then. So I'm putting it out for more discussion. >>> Do we feel that the kernel-devel (5~megs) should be in the install >>> media? >> Yes please. There's always new hardware we don't support yet, so some >> people will need to build drivers just to get online and access the >> repos. If we ship it on the install media, it's much easier to >> distribute code that you're reasonably confident will work on a new >> install. If people have to hunt down matching kernel and kernel-devel >> rpms, it's a moving target for people working on these device drivers. >> >> I'm not saying we should bend over backwards for out-of-tree drivers, but >> this is precisely the scenario that determines the first impression for >> someone trying this "Linux" thing on their shiny new bleeding-edge box, >> and it's pretty easy to accomodate. > > Erm... if this is the first time someone is trying a shiny new "Linux" thing > on a bleeding edge box, and they have to grab a kernel-devel package and > build drivers _themselves_, then they are obviously smart enough to run > 'yum install kernel-devel'. Somehow I think your example is slightly off. > I don't know many Linux newbies that know 1) that they need to build a > driver, 2) what driver to build, and 3) what packages they need to build it > all without knowing how to install anything. > > > These are not the people you are targeting. They know enough to not require > kernel-devel on the install media. You can move on to finding some other > use case that makes sense. > > > josh > How are they going to 'yum install kernel-devel' with no internet connection? And how does the maintainer of the not-yet-merged driver ensure that his code always works with whatever kernel Fedora has rebased to today? If you can be reasonably confident that every Fedora 10 user can at least get a certain matching kernel and kernel-devel, it's a lot easier to maintain drivers. In theory you could build packages, but when you're doing this for Fedora, Debian, Ubuntu, CentOS, etc. it isn't really feasible. I know this is a niche use case, but it's a very large niche, and it's the niche that's most likely to become avid Linux users if we don't push them away the first time. I know because I had this experience when I first started maintaining the atl2 network driver. Tens of thousands of EeePC users, many of them technically savvy but Linux novices, wanted to replace the hacked up Xandros that ships on the Eee with something a bit more flexible, but they needed atl2 to make it work, and it wasn't merged in the distros yet. When fast-moving distros like Fedora rebased their kernels to 2.6.24, my code broke, but the users who had kernel-devel or equivalent on their install media were fine, while the others either had to dig around to find a matching kernel and development headers, since only the latest were in the repos, or wait for me to fix it. The situation is much worse in the wireless world, where many of the drivers are reverse engineered and break on every new hardware rev, forcing users to install experimental stuff that isn't ready for merging in order to get their shiny new laptop online. I'm not saying that kernel-devel is an absolutely critical package to have on the install media, but it's extremely convenient at a time when users are most frustrated. If we're going to trim the install media, which I'm not fundamentally opposed to, there are much more frivolous things that should go first. -- Chris From benny+usenet at amorsen.dk Tue Sep 16 21:22:37 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Tue, 16 Sep 2008 23:22:37 +0200 Subject: change isdn4k-utils to optional In-Reply-To: <20080914161810.55f8678e@lain.camperquake.de> (Ralf Ertzinger's message of "Sun\, 14 Sep 2008 16\:18\:10 +0200") References: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> <20080913102118.GA8601@jasmine.xos.nl> <20080913140643.40ae1d3d@lain.camperquake.de> <20080914161810.55f8678e@lain.camperquake.de> Message-ID: Ralf Ertzinger writes: > I work for an ISP in a definitely first world country, and yes, we do > have ISDN dialup customers. Hell, we even have analogue ones. I am not surprised that you have analogue dialup customers. I am very surprised that ISDN dialup still exists. ISDN BRI must have been a massive success in Germany compared to pretty much anywhere else. /Benny From janina at rednote.net Tue Sep 16 21:28:27 2008 From: janina at rednote.net (Janina Sajka) Date: Tue, 16 Sep 2008 17:28:27 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <1221592366.32342.23.camel@localhost.localdomain> References: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> Message-ID: <20080916212827.GA5290@sonata.rednote.net> Matthias Clasen writes: > On Tue, 2008-09-16 at 14:34 -0400, Janina Sajka wrote: > > I just decided to give pa another go--so that I could speak from recent > > experience. I went to my /etc/alsa/alsa.conf and uncommented line 11. > > Then, I rebooted. > > > > 1.) There continues to be no audio indication of when gdm is ready. > > This despite the fact that I have "SoundOnLogin=true" in my > > /etc/gdm/custom.conf. The builtin GDM "audio icon" doesn't play, neither > > does GDM beep when it launches, nor can I get a beep from pressing > > back-space. > > What is the 'builtin audio icon' ? I have no idea what you are talking The sound the GDM plays when you've enabled audio. It plays after login, which is nice. But that doesn't meet the user need to know when GDM is ready for use. I suspect no one thought to give this feature a name. If they did, I haven't heard it. Typically a Marketing Dept would call such a thing a "audio logo." Think of the sound that accompanies Intel's "Intel Inside" commercials. > about here. And I've explained months ago how you can get a sound when > the login screen appears - assuming you are willing to make simple > customizations, which seems to be the case, considering that you are > editing alsa.conf... Sorry, I don't recall that--nor can I find it in my mailboxes or via Google. I do see an extended conversation on gdm-list that included both of us. Looking at that mail I see that I reported this sound would play after a Ctrl+Alt+Backspace--but not on boot. That continues to be the case. > > Why do you expect to get a beep from pressing backspace ? You can get > beeps in all sorts of ways: pressing up arrow, pressing enter, followed > by backspace, etc... > I don't necessarily. Again, the user need is to know when GDM is ready for login. A beep on backspace is one way to achieve that. It was the old behavior when "SoundOnLogin=TRUE" > > 2.) Ctrl-S does not work in GDM. This is gdm-2.22.0-8.fc9. Should I > > try from rawhide? > > Yeah, I know we wanted to add such global hotkeys to > gnome-settings-daemon, but it hasn't happened, as far as I can see. I'll > try to find out where that stands. But this is not very related to > pulseaudio anyway... OK. Thank you. Ctrl+s to start Orca with speech, Ctrl+b to start it with braille, and ctrl+m to start it with magnification are certainly noncontroversial. We discussed additional, mouse-oriented a11y for users of Gok on gdm-list. I don't believe we came to conclusions. > > > 3.) Logging in I hear first the GDM "audio logo," think I'll call it > > an earcon from now on. But, Orca launches in my secondary audio device. > > That's inappropriate, but I have no way to control that except to unplug > > my secondary and tertiary audio devices and start over. > > Hardly pulseaudios fault if orca picks the wrong device. I have no idea > how orca decides which device to use. Orca makes no decisions about audio devices. Neither does gnome-speech. So, it's rather an uncontrolled hand-wave. > > 4.) Logging back in with only one audio device on board, Orca does > > indeed startup on that device--but it seems I have to choose between > > Orca and playing other audio. How quaint! I thought we got past this > > silly "one sound at a time" view back around alsa-0.9. Does anyone > > recall the alsa FAQ used to claim this was appropriate back then? > > I don't recall old alsa FAQs, but you can observe that all the rest of > the desktop happily shares the output device under pulseaudios control. > You'd think it should be possible for orca to do the same. That it is > not doing so is again not pulseaudios fault... Perhaps not, but commenting and uncomment line 11 in /etc/alsa/alsa.conf--the line that invokes (or blocks) pulse audio toggles this between broken and correct functionality. What else am I to conclude about pulse audio? > > > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented > > from doing so, paplay believes it should pause playing while I'm away > > from the gui tty. Now, who's the genius that figured out this "feature?" > > Insults won't help your cause. Well, my apologies if this offends you. Is it supposed to work that way, though? Is there actually a use case for that behavior? Or is this just some incidental artifact? Janina > > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka, Phone: +1.202.595.7777; sip:janina at a11y.org Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada Learn more at http://ScreenlessPhone.Com Chair, Open Accessibility janina at a11y.org Linux Foundation http://a11y.org From alain.portal at free.fr Tue Sep 16 21:32:45 2008 From: alain.portal at free.fr (Alain PORTAL) Date: Tue, 16 Sep 2008 23:32:45 +0200 Subject: They are really asshole! In-Reply-To: <48D022F0.2050708@gmail.com> References: <200809162300.16635.alain.portal@free.fr> <48D022F0.2050708@gmail.com> Message-ID: <200809162332.46304.alain.portal@free.fr> Le mardi 16 septembre 2008, Nicoleau Fabien a ?crit : > It's false. > Your post is always available here: > http://forums.fedora-fr.org/viewtopic.php?id=35529 > and has never been deleted. Oh ? Comme c'est facile de ressuciter un post sur un autre forum... Pas une trace pour indiquer que le post a ?t? d?plac?. Pourtant, d'habitude, ils ne se g?nent pas. Kevin, if you can continue -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- 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 bruno at wolff.to Tue Sep 16 21:37:31 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Tue, 16 Sep 2008 16:37:31 -0500 Subject: The state of resolv.conf In-Reply-To: <1221579151.4107.11.camel@gibraltar.str.redhat.com> References: <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221557672.19134.15.camel@gibraltar.str.redhat.com> <48CF84F5.3010701@city-fan.org> <1221563959.19134.43.camel@gibraltar.str.redhat.com> <3da3b5b40809160434j12a23896k9123a1724d108913@mail.gmail.com> <20080916125136.GA8548@evileye.atkac.englab.brq.redhat.com> <1221579151.4107.11.camel@gibraltar.str.redhat.com> Message-ID: <20080916213731.GA28026@wolff.to> On Tue, Sep 16, 2008 at 17:32:31 +0200, Nils Philippsen wrote: > > I would want to be able to do that based on domain names (which is > easily done with BIND) and on classless IP ranges. I don't think the > latter can be done as the IP ranges are octet-granular, e.g. > 10.in-addr.arpa for 10.0.0.0/8 -- I can't imagine how I would tell BIND > to use a certain server for e.g. 10.1.0.0/12 (where 4 MSB of the second > octet are part of the network address and the remaining 4 LSB are part > of the host address). You do it using 16 entries for the 16 /16s. In the worst case you need 128 entries. From a.badger at gmail.com Tue Sep 16 21:36:26 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 16 Sep 2008 14:36:26 -0700 Subject: orphaning python packages In-Reply-To: <1221598930.5296.6.camel@rosebud> References: <20080916205709.GA9224@auslistsprd01.us.dell.com> <1221598930.5296.6.camel@rosebud> Message-ID: <48D026DA.4070107@gmail.com> Seth Vidal wrote: > On Tue, 2008-09-16 at 15:57 -0500, Matt Domsch wrote: >> Shahms King would like to orphan his packages due to other time >> commitments outside of Fedora. We thank him for his involvement >> thusfar and look forward to his return. >> >> Until then, these packages are up for grabs. I'll ask Toshio to mark >> them as orphans. >> >> >> python-lxml -- ElementTree-like Python bindings for libxml2 and libxslt >> (also python-paramiko) jcollie is comaintainer on both of these and has been pushing packages. jcollie, want to assume full responsibility? ;-) >> python-protocols -- Open Protocols and Component Adaptation for Python >> I've taken over this one as I'm already a comaintainer on this >> python-psycopg -- PostgreSQL database adapter for Python >> Devrim, when I orphaned this in pkgdb, I approved your co-maintainership request. If you want to take it over, you're welcome to. >> python-psyco -- The Python Specialing Compiler >> >> python-quixote -- A highly Pythonic Web application framework >> >> python-simpletal -- An XML based template processor for TAL, TALES and >> METAL specifications. >> >> python-tpg -- A Python "toy parser generator" >> One further mention: python-durus -- A Python Object Database -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From benny+usenet at amorsen.dk Tue Sep 16 21:38:08 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Tue, 16 Sep 2008 23:38:08 +0200 Subject: The state of resolv.conf In-Reply-To: <48CE8521.40002@city-fan.org> (Paul Howarth's message of "Mon\, 15 Sep 2008 16\:54\:09 +0100") References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <48CE1DAA.8090303@city-fan.org> <48CE8521.40002@city-fan.org> Message-ID: Paul Howarth writes: > If you have your local server set up as a caching DNS server, it > wouldn't matter, as your local server wouldn't use $PROVIDER's server > at all, and would resolve things itself via the root servers (just as > the provider's servers would do, though they will have a bigger > cache). Recursive DNS servers are often set up for forwarding. /Benny From jos at xos.nl Tue Sep 16 21:39:00 2008 From: jos at xos.nl (Jos Vos) Date: Tue, 16 Sep 2008 23:39:00 +0200 Subject: change isdn4k-utils to optional In-Reply-To: References: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> <20080913102118.GA8601@jasmine.xos.nl> <20080913140643.40ae1d3d@lain.camperquake.de> <20080914161810.55f8678e@lain.camperquake.de> Message-ID: <20080916213900.GB20999@jasmine.xos.nl> On Tue, Sep 16, 2008 at 11:22:37PM +0200, Benny Amorsen wrote: > I am not surprised that you have analogue dialup customers. I am very > surprised that ISDN dialup still exists. ISDN BRI must have been a > massive success in Germany compared to pretty much anywhere else. I'm surprised that people make so many assumptions about other countries. And till I do not understand why it is so unbelievable that there are still ISDN dialups. B.t.w. in the Netherlands the use of ISDN has also been pretty popular and I know that there are still new ISDN lines delivered. -- -- Jos Vos -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204 From nicoleau.fabien at gmail.com Tue Sep 16 21:46:08 2008 From: nicoleau.fabien at gmail.com (Nicoleau Fabien) Date: Tue, 16 Sep 2008 23:46:08 +0200 Subject: They are really asshole! In-Reply-To: <200809162332.46304.alain.portal@free.fr> References: <200809162300.16635.alain.portal@free.fr> <48D022F0.2050708@gmail.com> <200809162332.46304.alain.portal@free.fr> Message-ID: <48D02920.4010204@gmail.com> Alain PORTAL a ?crit : > Le mardi 16 septembre 2008, Nicoleau Fabien a ?crit : > > >> It's false. >> Your post is always available here: >> http://forums.fedora-fr.org/viewtopic.php?id=35529 >> and has never been deleted. >> > > Oh ? > Comme c'est facile de ressuciter un post sur un autre forum... > > Pas une trace pour indiquer que le post a ?t? d?plac?. Pourtant, d'habitude, > ils ne se g?nent pas. > > Kevin, if you can continue > I saw your post when you created it. It was already in this forum. "Moved" posts have still a link on old place when they are moved. This post has NEVER been moved or deleted. Can you provied the old link (if exists) ? Perhpas you are just wrong, and just made a mistake when you created the post (wrong forum ?). This is no so serious to insult (again and again) french community. Nicoleau Fabien (eponyme) From denis at poolshark.org Tue Sep 16 21:48:32 2008 From: denis at poolshark.org (Denis Leroy) Date: Tue, 16 Sep 2008 23:48:32 +0200 Subject: They are really asshole! In-Reply-To: <200809162332.46304.alain.portal@free.fr> References: <200809162300.16635.alain.portal@free.fr> <48D022F0.2050708@gmail.com> <200809162332.46304.alain.portal@free.fr> Message-ID: <48D029B0.9070206@poolshark.org> Alain PORTAL wrote: > Le mardi 16 septembre 2008, Nicoleau Fabien a ?crit : > >> It's false. >> Your post is always available here: >> http://forums.fedora-fr.org/viewtopic.php?id=35529 >> and has never been deleted. > > Oh ? > Comme c'est facile de ressuciter un post sur un autre forum... "Oh it's so easy to resurrect a post on another forum" > Pas une trace pour indiquer que le post a ?t? d?plac?. Pourtant, d'habitude, > ils ne se g?nent pas. "No trace indicates the post was moved, although they usually don't try to hide it." From benny+usenet at amorsen.dk Tue Sep 16 21:53:08 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Tue, 16 Sep 2008 23:53:08 +0200 Subject: Non-X text mode console In-Reply-To: <20080916092807.GA22628@shell.devel.redhat.com> (Alan Cox's message of "Tue\, 16 Sep 2008 05\:28\:07 -0400") References: <20080915151812.0730561B48E@hormel.redhat.com> <48CEA848.2050005@redhat.com> <20080916092807.GA22628@shell.devel.redhat.com> Message-ID: Alan Cox writes: > However they do not work on all machines, they do not work with a lot of > screen reader technology and they don't work with many of the remote management > cards. I only have experience with HP's iLO, and that only supports BIOS writes as far as I can tell (except the advanced version which does a full graphical console). Linux doesn't use BIOS writes, so that battle is lost already. That's ok though, because it also works as a serial-port-over-telnet, and the Linux serial console is reasonably good. I would imagine that most of the other remote management cards do the same, am I wrong? /Benny From jspaleta at gmail.com Tue Sep 16 21:57:48 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 16 Sep 2008 13:57:48 -0800 Subject: They are really asshole! In-Reply-To: <48D029B0.9070206@poolshark.org> References: <200809162300.16635.alain.portal@free.fr> <48D022F0.2050708@gmail.com> <200809162332.46304.alain.portal@free.fr> <48D029B0.9070206@poolshark.org> Message-ID: <604aa7910809161457r59c01256w5fd110f88fd11b9c@mail.gmail.com> On Tue, Sep 16, 2008 at 1:48 PM, Denis Leroy wrote: > "No trace indicates the post was moved, although they usually don't try to > hide it." You know..if we knew which forum username to search for, someone could attempt to do a full review of all of the available interactions, in context. The forum as configured does make it easy to get a full listing of all the posts attributed to a specific user...unless I'm reading things incorrectly. I don't recall Alain providing that information however. I'm left assuming that the username in question is Dionysos. -jef From janina at rednote.net Tue Sep 16 22:05:27 2008 From: janina at rednote.net (Janina Sajka) Date: Tue, 16 Sep 2008 18:05:27 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080916201247.GA32741@angus.ind.WPI.EDU> References: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> Message-ID: <20080916220527.GC5290@sonata.rednote.net> Chuck Anderson writes: > On Tue, Sep 16, 2008 at 02:34:44PM -0400, Janina Sajka wrote: > > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented > > from doing so, paplay believes it should pause playing while I'm away > > from the gui tty. Now, who's the genius that figured out this "feature?" > > That's ConsoleKit deactivating the streams on the non-active console. > This is so mult-user-switching can work and each user can have their > own audio. > OK. Thanks for the explanation. So, the concept limits audio to a single console, even if the same user is logged in somewhere else? I guess running pa as a systen daemon would not exhibit this behavior? Janina > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka, Phone: +1.202.595.7777; sip:janina at a11y.org Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada Learn more at http://ScreenlessPhone.Com Chair, Open Accessibility janina at a11y.org Linux Foundation http://a11y.org From nicoleau.fabien at gmail.com Tue Sep 16 22:05:25 2008 From: nicoleau.fabien at gmail.com (Nicoleau Fabien) Date: Wed, 17 Sep 2008 00:05:25 +0200 Subject: They are really asshole! In-Reply-To: <604aa7910809161457r59c01256w5fd110f88fd11b9c@mail.gmail.com> References: <200809162300.16635.alain.portal@free.fr> <48D022F0.2050708@gmail.com> <200809162332.46304.alain.portal@free.fr> <48D029B0.9070206@poolshark.org> <604aa7910809161457r59c01256w5fd110f88fd11b9c@mail.gmail.com> Message-ID: <48D02DA5.6030109@gmail.com> Jeff Spaleta a ?crit : > On Tue, Sep 16, 2008 at 1:48 PM, Denis Leroy wrote: > >> "No trace indicates the post was moved, although they usually don't try to >> hide it." >> > > You know..if we knew which forum username to search for, someone could > attempt to do a full review of all of the available interactions, in > context. The forum as configured does make it easy to get a full > listing of all the posts attributed to a specific user...unless I'm > reading things incorrectly. I don't recall Alain providing that > information however. I'm left assuming that the username in question > is Dionysos. > > -jef > > Yes, his username on the forum is Dionysos. Nicoleau Fabien (eponyme) From paul at all-the-johnsons.co.uk Tue Sep 16 22:06:58 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Tue, 16 Sep 2008 23:06:58 +0100 Subject: Orphaning my packages In-Reply-To: <200809161740.01071.alain.portal@free.fr> References: <200809161740.01071.alain.portal@free.fr> Message-ID: <1221602818.8512.4.camel@PB3.Linux> Hi, > kbackup -- Back up your data in a simple, user friendly way > kicad -- Electronic schematic diagrams and printed circuit board artwork > pikdev -- IDE for development of PICmicro based application (under Linux/KDE) > piklab -- Development environment for applications based on PIC & dsPIC > microcontrollers > pikloops -- Code generator for PIC delays If no-one else wants them, I'll take these on. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pbrobinson at gmail.com Tue Sep 16 22:17:25 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 16 Sep 2008 23:17:25 +0100 Subject: change isdn4k-utils to optional In-Reply-To: <20080916213900.GB20999@jasmine.xos.nl> References: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> <20080913102118.GA8601@jasmine.xos.nl> <20080913140643.40ae1d3d@lain.camperquake.de> <20080914161810.55f8678e@lain.camperquake.de> <20080916213900.GB20999@jasmine.xos.nl> Message-ID: <5256d0b0809161517u11bfce08q6598175b41d91b2b@mail.gmail.com> >> I am not surprised that you have analogue dialup customers. I am very >> surprised that ISDN dialup still exists. ISDN BRI must have been a >> massive success in Germany compared to pretty much anywhere else. > > I'm surprised that people make so many assumptions about other countries. > And till I do not understand why it is so unbelievable that there are > still ISDN dialups. > > B.t.w. in the Netherlands the use of ISDN has also been pretty popular > and I know that there are still new ISDN lines delivered. They are in Australia as well as they can run over relatively long distances unlike ADSL. Also not sure what the difference between dialup ISDN and what is used by VoIP gateways such as asterisk that used ISDN PRIs for getting out onto the PSTN. Peter From janina at rednote.net Tue Sep 16 22:33:58 2008 From: janina at rednote.net (Janina Sajka) Date: Tue, 16 Sep 2008 18:33:58 -0400 Subject: Non-X text mode console In-Reply-To: References: <20080915151812.0730561B48E@hormel.redhat.com> <48CEA6D3.90906@herr-schmitt.de> <20080916151742.GB32117@sonata.rednote.net> Message-ID: <20080916223358.GD5290@sonata.rednote.net> Colin Walters writes: > On Tue, Sep 16, 2008 at 11:17 AM, Janina Sajka wrote: > > > > You're assuming the X-based assistive technology will become at least as > > performant as the non X technology is today. I certainly don't regard > > this to be impossible. I simply note we're not there. > > I am trongly suggesting that accessibility efforts focus on X based > technology, because that is the focus of the work that goes on in the > desktop. > And, that's where much of the effort is these days. However, this doesn't remove a need for a11y in nonX consoles for the same reasons that others have raised in support of nonX consoles. People boot their machines to do a particular task--not to view a monitor or listen to a TTS engine. The monitor and the screen.reader/TTS.engine are just tools. So, while most users may be more than satisfied on the GUI, there's the geek who's job is maintaining a rack of servers. Some of those geeks happen to be persons with disabilities. I suggest there's a simple way to understand this: Wherever there's a user interface, there's a need for a11y. Clearly, that's the gui desktop, but it's also the console. One of these days we'll need to extend a11y to bios and boot loader as well. If it takes input, there's someone who needs input alternatives. If it produces output, there's someone who needs output alternatives. Janina From jeff at ocjtech.us Tue Sep 16 22:36:10 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Tue, 16 Sep 2008 17:36:10 -0500 Subject: orphaning python packages In-Reply-To: <48D026DA.4070107@gmail.com> References: <20080916205709.GA9224@auslistsprd01.us.dell.com> <1221598930.5296.6.camel@rosebud> <48D026DA.4070107@gmail.com> Message-ID: <935ead450809161536v240c9d4pb74d5b018c58c01d@mail.gmail.com> 2008/9/16 Toshio Kuratomi : > Seth Vidal wrote: >> On Tue, 2008-09-16 at 15:57 -0500, Matt Domsch wrote: >>> python-lxml -- ElementTree-like Python bindings for libxml2 and libxslt >>> > (also python-paramiko) > > jcollie is comaintainer on both of these and has been pushing packages. > jcollie, want to assume full responsibility? ;-) Taken. -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" From benny+usenet at amorsen.dk Tue Sep 16 22:37:23 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Wed, 17 Sep 2008 00:37:23 +0200 Subject: change isdn4k-utils to optional In-Reply-To: <5256d0b0809161517u11bfce08q6598175b41d91b2b@mail.gmail.com> (Peter Robinson's message of "Tue\, 16 Sep 2008 23\:17\:25 +0100") References: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> <20080913102118.GA8601@jasmine.xos.nl> <20080913140643.40ae1d3d@lain.camperquake.de> <20080914161810.55f8678e@lain.camperquake.de> <20080916213900.GB20999@jasmine.xos.nl> <5256d0b0809161517u11bfce08q6598175b41d91b2b@mail.gmail.com> Message-ID: "Peter Robinson" writes: > Also not sure what the difference between dialup ISDN and what is used > by VoIP gateways such as asterisk that used ISDN PRIs for getting out > onto the PSTN. Voice-over-PRI doesn't depend on isdn4k-utils. Also, it is really unlikely to have a Fedora system which has an ISDN-PRI as the only way to get Fedora packages from the Internet. /Benny From pemboa at gmail.com Tue Sep 16 22:47:15 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 16 Sep 2008 17:47:15 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> Message-ID: <16de708d0809161547sa61072endae6427c9df089fa@mail.gmail.com> On Tue, Sep 16, 2008 at 4:04 PM, Benny Amorsen wrote: > Denis Leroy writes: > ctrl-alt-f1 is iffy on a lot of machines. Sometimes you need a reboot > to get back to X. Having the kernel involved in the whole affair has a > somewhat better chance of working. Well that or we might get a Linus > rant; that often gets things fixed a bit faster. What machine is that? I've been installing Redhat/Fedora/Centos since 2003, not that long, but I have never seen Ctrl+Alt+F1 be iffy -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From ssorce at redhat.com Tue Sep 16 22:57:18 2008 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 16 Sep 2008 18:57:18 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE8A5C.4090902@poolshark.org> <48CEA21F.8000605@gmail.com> Message-ID: <1221605838.12851.66.camel@localhost.localdomain> On Tue, 2008-09-16 at 23:13 +0200, Benny Amorsen wrote: > Suren Karapetyan writes: > > > Having to run X (and you know... it won't start with less then 256M > > ram) on every machine with Fedora is a real problem. > > The Nokia 770 runs X. Back in the day, 8MB 486's ran X. Heck, Sun 5-60's > (68020's with 6MB of memory) ran X quite nicely. When you see X in > "top", a lot of its memory use is actually graphics card memory. I had and 486 at the time with 8MB and I can assure you that X was the *only* process running when I tried to use it (ie it used all memory and some swap and the machine was basically dieing for the swapping) When I had money to go 12MB X became slightly usable with some Xterms, Xeyes and friends. Nothing fancy tho or swapping would start killing your machine again. However 32MB of ram will run X with a minimal Window Manager and apps really well, especially at lower resolutions. > An X solution is not impossible. I'm not saying it's the answer, but > you can't rule it out like that. On this I can agree :) -- Simo Sorce * Red Hat, Inc * New York From sundaram at fedoraproject.org Tue Sep 16 22:57:38 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 17 Sep 2008 04:27:38 +0530 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <16de708d0809161547sa61072endae6427c9df089fa@mail.gmail.com> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <16de708d0809161547sa61072endae6427c9df089fa@mail.gmail.com> Message-ID: <48D039E2.8030506@fedoraproject.org> Arthur Pemberton wrote: > On Tue, Sep 16, 2008 at 4:04 PM, Benny Amorsen wrote: >> Denis Leroy writes: >> ctrl-alt-f1 is iffy on a lot of machines. Sometimes you need a reboot >> to get back to X. Having the kernel involved in the whole affair has a >> somewhat better chance of working. Well that or we might get a Linus >> rant; that often gets things fixed a bit faster. > > > What machine is that? I've been installing Redhat/Fedora/Centos since > 2003, not that long, but I have never seen Ctrl+Alt+F1 be iffy It is not hardware specific. If you do that often enough, you will probably hit it sometime or the other. It is not easily reproducible however. Rahul From alan at redhat.com Tue Sep 16 23:24:45 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 16 Sep 2008 19:24:45 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> Message-ID: <20080916232445.GA17153@shell.devel.redhat.com> On Tue, Sep 16, 2008 at 11:04:39PM +0200, Benny Amorsen wrote: > ctrl-alt-f1 is iffy on a lot of machines. Sometimes you need a reboot > to get back to X. Having the kernel involved in the whole affair has a That would be an X bug. X handles all the mode switching logic for this stuff. There are good reasons to get the kernel involved these days (for one we've gone from fifty or more vendors down to about five of any relevance and they tend to use sensible means for mode switching) but it won't really change any reliability in that area. What it will help with is stuff like recovering from an X crash, implementing full SAK support and oops display. From alan at redhat.com Tue Sep 16 23:27:55 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 16 Sep 2008 19:27:55 -0400 Subject: change isdn4k-utils to optional In-Reply-To: <20080916213900.GB20999@jasmine.xos.nl> References: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> <20080913102118.GA8601@jasmine.xos.nl> <20080913140643.40ae1d3d@lain.camperquake.de> <20080914161810.55f8678e@lain.camperquake.de> <20080916213900.GB20999@jasmine.xos.nl> Message-ID: <20080916232755.GB17153@shell.devel.redhat.com> On Tue, Sep 16, 2008 at 11:39:00PM +0200, Jos Vos wrote: > > massive success in Germany compared to pretty much anywhere else. It was - for various timing reaosns > I'm surprised that people make so many assumptions about other countries. > And till I do not understand why it is so unbelievable that there are > still ISDN dialups. > > B.t.w. in the Netherlands the use of ISDN has also been pretty popular > and I know that there are still new ISDN lines delivered. In the UK it i fairly unusual for internet service but still found in some areas out of ADSL reach and still sold, so it hasn't gone away entirely. From alan at redhat.com Tue Sep 16 23:29:53 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 16 Sep 2008 19:29:53 -0400 Subject: Non-X text mode console In-Reply-To: References: <20080915151812.0730561B48E@hormel.redhat.com> <48CEA848.2050005@redhat.com> <20080916092807.GA22628@shell.devel.redhat.com> Message-ID: <20080916232953.GC17153@shell.devel.redhat.com> On Tue, Sep 16, 2008 at 11:53:08PM +0200, Benny Amorsen wrote: > I only have experience with HP's iLO, and that only supports BIOS > writes as far as I can tell (except the advanced version which does a > full graphical console). Linux doesn't use BIOS writes, so that battle > is lost already. > > That's ok though, because it also works as a serial-port-over-telnet, > and the Linux serial console is reasonably good. I would imagine that > most of the other remote management cards do the same, am I wrong? Quite a few see all I/O to the text mode console and relay that. Works with Linux and the big server farms don't care too much about graphical management and buy lots of units. Some of them these days do graphics properly - a few even talk VNC From alan at redhat.com Tue Sep 16 23:31:17 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 16 Sep 2008 19:31:17 -0400 Subject: change isdn4k-utils to optional In-Reply-To: References: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> <20080913102118.GA8601@jasmine.xos.nl> <20080913140643.40ae1d3d@lain.camperquake.de> <20080914161810.55f8678e@lain.camperquake.de> <20080916213900.GB20999@jasmine.xos.nl> <5256d0b0809161517u11bfce08q6598175b41d91b2b@mail.gmail.com> Message-ID: <20080916233117.GD17153@shell.devel.redhat.com> On Wed, Sep 17, 2008 at 12:37:23AM +0200, Benny Amorsen wrote: > Voice-over-PRI doesn't depend on isdn4k-utils. Also, it is really > unlikely to have a Fedora system which has an ISDN-PRI as the only way > to get Fedora packages from the Internet. Its a supported package and more relevant than half of Fedora, so who cares anyway. And your assumption is I think wrong - folks with an ISDN PRI tend to use it for everything. From alan at redhat.com Tue Sep 16 23:32:07 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 16 Sep 2008 19:32:07 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <48D039E2.8030506@fedoraproject.org> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <16de708d0809161547sa61072endae6427c9df089fa@mail.gmail.com> <48D039E2.8030506@fedoraproject.org> Message-ID: <20080916233207.GE17153@shell.devel.redhat.com> On Wed, Sep 17, 2008 at 04:27:38AM +0530, Rahul Sundaram wrote: > It is not hardware specific. If you do that often enough, you will That I doubt. > probably hit it sometime or the other. It is not easily reproducible > however. The mode switch logic is driver specific so would be hardware specific in X From alan at redhat.com Tue Sep 16 23:33:17 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 16 Sep 2008 19:33:17 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1221605838.12851.66.camel@localhost.localdomain> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE8A5C.4090902@poolshark.org> <48CEA21F.8000605@gmail.com> <1221605838.12851.66.camel@localhost.localdomain> Message-ID: <20080916233317.GF17153@shell.devel.redhat.com> On Tue, Sep 16, 2008 at 06:57:18PM -0400, Simo Sorce wrote: > However 32MB of ram will run X with a minimal Window Manager and apps > really well, especially at lower resolutions. It also depends on your X server. XFree86 is not small, clean or efficient compare to things like KDrive. X is a protocol with a bloated nasty default implementation which is only slowly recovering from twenty years of neglect From sundaram at fedoraproject.org Tue Sep 16 23:35:41 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 17 Sep 2008 05:05:41 +0530 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080916233207.GE17153@shell.devel.redhat.com> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <16de708d0809161547sa61072endae6427c9df089fa@mail.gmail.com> <48D039E2.8030506@fedoraproject.org> <20080916233207.GE17153@shell.devel.redhat.com> Message-ID: <48D042CD.80305@fedoraproject.org> Alan Cox wrote: > On Wed, Sep 17, 2008 at 04:27:38AM +0530, Rahul Sundaram wrote: >> It is not hardware specific. If you do that often enough, you will > > That I doubt. > >> probably hit it sometime or the other. It is not easily reproducible >> however. > > The mode switch logic is driver specific so would be hardware specific in X Yes, I wasn't very clear. What I meant was it occurs in many systems rather than being limited to one particular hardware. Rahul From dwmw2 at infradead.org Tue Sep 16 23:42:09 2008 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 16 Sep 2008 16:42:09 -0700 Subject: Fedora not "free" enough for GNU? In-Reply-To: References: <8553.1220772699@sss.pgh.pa.us> Message-ID: <1221608529.20234.96.camel@macbook.infradead.org> On Sun, 2008-09-07 at 05:15 -0400, Gregory Maxwell wrote: > The reason the FSF isn't advocating Fedora at this point is pretty > much only because Fedora doesn't yet strip the binary firmware > provided by the Linux kernel (and still provides some re-distributable > binary firmware in other packages, the microcode package and > alsa-firmware I think). I suppose there is also still some inertia > from back at a time when Fedora wasn't as good it is now with > licensing checking on packages. We are almost at the point where we can do a spin which remedies that. Our 'kernel-firmware' package is currently built from the kernel source as a subpackage of the normal kernel build -- but we should stop doing that anyway, and build it instead as a completely separate package from the linux-firmware.git repository on kernel.org. That repository contains more firmware than the kernel does already, and is going to be gaining even more. Once we're doing that as a completely separate package, people will be able to do an alternative package which Provides: kernel-firmware, but which contains only the stuff for which they have source. Then they can do their own Fedora spin which _does_ meet the FSF requirements, although we obviously don't want the 'real' Fedora spin to do that. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation From poelstra at redhat.com Tue Sep 16 23:45:56 2008 From: poelstra at redhat.com (John Poelstra) Date: Tue, 16 Sep 2008 16:45:56 -0700 Subject: Fedora Release Engineering Meeting Recap 2008-09-15 Message-ID: <48D04534.20704@redhat.com> Recap and full IRC transcript found here: https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-sep-15 Please make corrections and clarifications to the wiki page. = Fedora Release Engineering Meeting :: Monday 2008-09-15 = == F10 Beta == * froze on Thursday * have had a few recent days of ''installable'' rawhide * review of development progress and stability in different areas == IRC Transcript == From tcallawa at redhat.com Wed Sep 17 00:17:02 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Tue, 16 Sep 2008 20:17:02 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <1221608529.20234.96.camel@macbook.infradead.org> References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> Message-ID: <1221610622.6574.3.camel@localhost.localdomain> On Tue, 2008-09-16 at 16:42 -0700, David Woodhouse wrote: > We are almost at the point where we can do a spin which remedies that. > > Our 'kernel-firmware' package is currently built from the kernel > source > as a subpackage of the normal kernel build -- but we should stop doing > that anyway, and build it instead as a completely separate package > from > the linux-firmware.git repository on kernel.org. That repository > contains more firmware than the kernel does already, and is going to > be > gaining even more. David, There still looks to be firmware in the kernel source code that hasn't been separated out properly yet. For example, tg3.c: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=drivers/net/tg3.c;hb=HEAD I don't know if you're tracking that or not, but I'll need to do a legal audit at some point to ensure that the firmware is all separated out from the source. When we get to a point where the kernel-firmware package is truly separate, then we're closer to being able to do a free spin, but it is not the only roadblock. ~spot From sundaram at fedoraproject.org Wed Sep 17 00:28:51 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 17 Sep 2008 05:58:51 +0530 Subject: Fedora not "free" enough for GNU? In-Reply-To: <1221610622.6574.3.camel@localhost.localdomain> References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> Message-ID: <48D04F43.30900@fedoraproject.org> Tom "spot" Callaway wrote: > David, > > There still looks to be firmware in the kernel source code that hasn't > been separated > out properly yet. For example, tg3.c: > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=drivers/net/tg3.c;hb=HEAD > > I don't know if you're tracking that or not, but I'll need to do a legal > audit at some point to ensure that the firmware is all separated out > from the source. Might want to take a look at http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html Rahul From mclasen at redhat.com Wed Sep 17 00:40:43 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 16 Sep 2008 20:40:43 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080916220527.GC5290@sonata.rednote.net> References: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> Message-ID: <1221612043.18922.5.camel@localhost.localdomain> On Tue, 2008-09-16 at 18:05 -0400, Janina Sajka wrote: > Chuck Anderson writes: > > On Tue, Sep 16, 2008 at 02:34:44PM -0400, Janina Sajka wrote: > > > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented > > > from doing so, paplay believes it should pause playing while I'm away > > > from the gui tty. Now, who's the genius that figured out this "feature?" > > > > That's ConsoleKit deactivating the streams on the non-active console. > > This is so mult-user-switching can work and each user can have their > > own audio. > > > OK. Thanks for the explanation. > > So, the concept limits audio to a single console, even if the same user > is logged in somewhere else? I guess running pa as a systen daemon would > not exhibit this behavior? > Actually, Lennart changed PA to not be strictly per-session, but per-user, I think. But I don't know the details of how that works. I've looked into your 'login screen ready' sound problem, and found that it doesn't work atm due to a pulseaudio bug: https://bugzilla.redhat.com/show_bug.cgi?id=462537 Matthias From jwboyer at gmail.com Wed Sep 17 00:56:18 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 16 Sep 2008 20:56:18 -0400 Subject: They are really asshole! In-Reply-To: <200809162300.16635.alain.portal@free.fr> References: <200809162300.16635.alain.portal@free.fr> Message-ID: <20080917005618.GA12421@yoda.jdub.homelinux.org> On Tue, Sep 16, 2008 at 11:00:15PM +0200, Alain PORTAL wrote: >Hey FESCo! Wake up!!! > >Just after I said on devel list I'm orphaning my packages, I post also a >message on a fedora-fr.org forum to say man-pages-fr is orphaned and it is >searching for a maintainer, nothing else... >I'm sure Martin-Gomez answer on the list after he saw my post on the forum. >But nobody can read this post any more. > >Less than two hours after my post, this post have been deleted.... >Why ? >I don't see any reason but that they are really fucking assholes! > >FESCo, you don't listen to me when I warm you a few months ago about the >fedora-fr association... Several people from FESCo did attempt to at least try something. However, FESCo has neither the authority nor the jurisdiction to intervene on a privately run forum. This is not unlike the situation that Richard Jones recently encountered on fedoraforum.org. As much as those of us on FESCo would like to be able to help, there is only so much we can do. josh From sundaram at fedoraproject.org Wed Sep 17 01:00:15 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 17 Sep 2008 06:30:15 +0530 Subject: They are really asshole! In-Reply-To: <20080917005618.GA12421@yoda.jdub.homelinux.org> References: <200809162300.16635.alain.portal@free.fr> <20080917005618.GA12421@yoda.jdub.homelinux.org> Message-ID: <48D0569F.8000202@fedoraproject.org> Josh Boyer wrote: > > This is not unlike the situation that Richard Jones recently encountered on > fedoraforum.org. Are you talking about Richard Hughes or did Richard Jones have a separate problem as well? Rahul From jwboyer at gmail.com Wed Sep 17 01:03:47 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 16 Sep 2008 21:03:47 -0400 Subject: They are really asshole! In-Reply-To: <48D0569F.8000202@fedoraproject.org> References: <200809162300.16635.alain.portal@free.fr> <20080917005618.GA12421@yoda.jdub.homelinux.org> <48D0569F.8000202@fedoraproject.org> Message-ID: <20080917010347.GA12452@yoda.jdub.homelinux.org> On Wed, Sep 17, 2008 at 06:30:15AM +0530, Rahul Sundaram wrote: > Josh Boyer wrote: > >> >> This is not unlike the situation that Richard Jones recently encountered on >> fedoraforum.org. > > Are you talking about Richard Hughes or did Richard Jones have a > separate problem as well? Gah! Richard Hughes. My apologies. josh From devrim at gunduz.org Wed Sep 17 01:36:04 2008 From: devrim at gunduz.org (Devrim =?ISO-8859-1?Q?G=DCND=DCZ?=) Date: Wed, 17 Sep 2008 04:36:04 +0300 Subject: orphaning python packages In-Reply-To: <48D026DA.4070107@gmail.com> References: <20080916205709.GA9224@auslistsprd01.us.dell.com> <1221598930.5296.6.camel@rosebud> <48D026DA.4070107@gmail.com> Message-ID: <1221615364.3277.142.camel@laptop.gunduz.org> On Tue, 2008-09-16 at 14:36 -0700, Toshio Kuratomi wrote: > >> python-psycopg -- PostgreSQL database adapter for Python > >> > Devrim, when I orphaned this in pkgdb, I approved your > co-maintainership > request. If you want to take it over, you're welcome to. Done. Actually let me see whether we can get rid of that package in Fedora completely. Regards, -- Devrim G?ND?Z, RHCE devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mw_triad at users.sourceforge.net Wed Sep 17 02:42:37 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 16 Sep 2008 21:42:37 -0500 Subject: Beware: External repos can break key transition In-Reply-To: <48CFFBEC.2030102@leemhuis.info> References: <1221158197.6431.24.camel@localhost.localdomain> <48CF0AD9.6040506@redhat.com> <48CF40AE.8080006@leemhuis.info> <48CFFBEC.2030102@leemhuis.info> Message-ID: Thorsten Leemhuis wrote: > On 16.09.2008 17:46, Matthew Woehlke wrote: >> Thorsten Leemhuis wrote: >>> Thus yum will install the new xine-lib-extras-nonfree from Livna, but >>> not the matching xine-lib from Fedora. Thus all apps that rely on >>> xine will silently stop playing some videos that they were able to >>> play beforehand. >> >> Huh? If that happened, I'd sure file a bug... against either the >> package, for having a broken Requires:, or against yum/rpm for >> ignoring the Requires:. But I'm confused, because (at least in my >> case) yum correctly refused to install xine-libs-extras-nonfree until >> the matching xine-lib was also available, so I don't get how this >> would happen. > > This afaics would happen if Livna would have done what was suggested in > https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01462.html Sigh. Somehow I seem to have failed to read that part of the thread. My bad :-). -- Matthew There's no place like ~. -- Unknown From vonbrand at inf.utfsm.cl Wed Sep 17 02:55:13 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Tue, 16 Sep 2008 22:55:13 -0400 Subject: Non-X text mode console In-Reply-To: <48CEA6D3.90906@herr-schmitt.de> References: <20080915151812.0730561B48E@hormel.redhat.com> <48CEA6D3.90906@herr-schmitt.de> Message-ID: <200809170255.m8H2tDU5010168@laptop14.inf.utfsm.cl> Jochen Schmitt wrote: > David A. Wheeler schrieb: > > I think it's clear from this discussion here that many people DO > > find non-X console mode useful, and thus, it shouldn't be removed: > > Dominik 'Rathann' Mierzejewski: > I agree with you, that a release of Fedora without non-x mode console > may be a disadvantage. Bzzt, wrong. Would make it next to useless for many applications. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From wtogami at redhat.com Wed Sep 17 03:06:25 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 16 Sep 2008 23:06:25 -0400 Subject: Beware: External repos can break key transition In-Reply-To: <48CF40AE.8080006@leemhuis.info> References: <1221158197.6431.24.camel@localhost.localdomain> <48CF0AD9.6040506@redhat.com> <48CF40AE.8080006@leemhuis.info> Message-ID: <48D07431.1010307@redhat.com> Thorsten Leemhuis wrote: > On 16.09.2008 03:24, Warren Togami wrote: >> BTW, I just thought of a horribly ugly but automatic working solution >> to this problem: Filter the require on "xine-lib(plugin-abi) = 1.24" >> from that package. >> >> This sucks, but at least yum update will upgrade to the latest N-V-R >> packages in both repos so this doesn't exactly break anything. > > It breaks for some times: let's say xine-lib (Fedora) and > xine-lib-extras-nonfree (Livna) get both pushed to their repos at round > about the same time (like it was the case for the recent packages). Then > there is a time window that's afaics round about somewhat between 24 and > 36 hours long(?) where yum on the user's system might chose to use the > livna master repo (or a up2date livna mirror) and a Fedora mirror that's > not up to date. > > Thus yum will install the new xine-lib-extras-nonfree from Livna, but > not the matching xine-lib from Fedora. Thus all apps that rely on xine > will silently stop playing some videos that they were able to play > beforehand. I'd call that breakage ;-) A breakage that IMHO is not > acceptable, as users won't know what's up and might file bugs. > You are suggesting that out of sync mirrors causing this software to fail as being "unacceptable". Implicitly this means you suggest it is better for the entire update transaction to fail and require manual intervention? The former problem is only temporary and likely to clear itself up, while the latter is permanently fatal. Certainly this suggestion sucks, but is there a better way? Warren From dcbw at redhat.com Wed Sep 17 03:50:05 2008 From: dcbw at redhat.com (Dan Williams) Date: Tue, 16 Sep 2008 23:50:05 -0400 Subject: The state of resolv.conf In-Reply-To: <1221563959.19134.43.camel@gibraltar.str.redhat.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221557672.19134.15.camel@gibraltar.str.redhat.com> <48CF84F5.3010701@city-fan.org> <1221563959.19134.43.camel@gibraltar.str.redhat.com> Message-ID: <1221623405.23132.2.camel@localhost.localdomain> On Tue, 2008-09-16 at 13:19 +0200, Nils Philippsen wrote: > On Tue, 2008-09-16 at 11:05 +0100, Paul Howarth wrote: > > > Another problem with modifying resolv.conf is that most processes only > > read it once, usually shortly after starting up, so any changes that > > happen after that don't get picked up by existing processes. So for > > instance you could have a web browser that couldn't resolve names from a > > VPN tunnel that had been brought up after the browser had been started. > > Which is a bug IMO. If applications don't use the glibc supplied > functions for name-resolving, they should at least reinvent the wheel > properly and check for changes to resolv.conf. Nobody is rolling their own code; they all use gethostbyname. The problem is that glibc's resolver is too simplistic. I asked the glibc guys about this about 3 years ago and they said they wanted to keep glibc's resolver simple and that this should be handled either by lwresd or a caching nameserver. The core issue was that doing something like polling /etc/resolv.conf for updates would be unecessary on many platforms. So the answer seems to be that glibc will not change it's simple internal resolver (which has more limitations than just noticing resolv.conf changes), but the recommendation is that lwresd or a local caching nameserver be used for more complex DNS setups. Dan From dcbw at redhat.com Wed Sep 17 03:50:05 2008 From: dcbw at redhat.com (Dan Williams) Date: Tue, 16 Sep 2008 23:50:05 -0400 Subject: The state of resolv.conf In-Reply-To: <1221563959.19134.43.camel@gibraltar.str.redhat.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221557672.19134.15.camel@gibraltar.str.redhat.com> <48CF84F5.3010701@city-fan.org> <1221563959.19134.43.camel@gibraltar.str.redhat.com> Message-ID: <1221623405.23132.2.camel@localhost.localdomain> On Tue, 2008-09-16 at 13:19 +0200, Nils Philippsen wrote: > On Tue, 2008-09-16 at 11:05 +0100, Paul Howarth wrote: > > > Another problem with modifying resolv.conf is that most processes only > > read it once, usually shortly after starting up, so any changes that > > happen after that don't get picked up by existing processes. So for > > instance you could have a web browser that couldn't resolve names from a > > VPN tunnel that had been brought up after the browser had been started. > > Which is a bug IMO. If applications don't use the glibc supplied > functions for name-resolving, they should at least reinvent the wheel > properly and check for changes to resolv.conf. Nobody is rolling their own code; they all use gethostbyname. The problem is that glibc's resolver is too simplistic. I asked the glibc guys about this about 3 years ago and they said they wanted to keep glibc's resolver simple and that this should be handled either by lwresd or a caching nameserver. The core issue was that doing something like polling /etc/resolv.conf for updates would be unecessary on many platforms. So the answer seems to be that glibc will not change it's simple internal resolver (which has more limitations than just noticing resolv.conf changes), but the recommendation is that lwresd or a local caching nameserver be used for more complex DNS setups. Dan From walters at verbum.org Wed Sep 17 03:57:00 2008 From: walters at verbum.org (Colin Walters) Date: Tue, 16 Sep 2008 23:57:00 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <1221612043.18922.5.camel@localhost.localdomain> References: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> Message-ID: On Tue, Sep 16, 2008 at 8:40 PM, Matthias Clasen wrote: > On Tue, 2008-09-16 at 18:05 -0400, Janina Sajka wrote: >> Chuck Anderson writes: >> > On Tue, Sep 16, 2008 at 02:34:44PM -0400, Janina Sajka wrote: >> > > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented >> > > from doing so, paplay believes it should pause playing while I'm away >> > > from the gui tty. Now, who's the genius that figured out this "feature?" >> > >> > That's ConsoleKit deactivating the streams on the non-active console. >> > This is so mult-user-switching can work and each user can have their >> > own audio. >> > >> OK. Thanks for the explanation. >> >> So, the concept limits audio to a single console, even if the same user >> is logged in somewhere else? I guess running pa as a systen daemon would >> not exhibit this behavior? >> > > Actually, Lennart changed PA to not be strictly per-session, but > per-user, I think. But I don't know the details of how that works. Which is broken because in reality per-session and per-user are the same thing. You can't log in multiple times: http://cgwalters.livejournal.com/16885.html From dcbw at redhat.com Wed Sep 17 04:29:47 2008 From: dcbw at redhat.com (Dan Williams) Date: Wed, 17 Sep 2008 00:29:47 -0400 Subject: change isdn4k-utils to optional In-Reply-To: <20080916213900.GB20999@jasmine.xos.nl> References: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> <20080913102118.GA8601@jasmine.xos.nl> <20080913140643.40ae1d3d@lain.camperquake.de> <20080914161810.55f8678e@lain.camperquake.de> <20080916213900.GB20999@jasmine.xos.nl> Message-ID: <1221625788.23335.18.camel@localhost.localdomain> On Tue, 2008-09-16 at 23:39 +0200, Jos Vos wrote: > On Tue, Sep 16, 2008 at 11:22:37PM +0200, Benny Amorsen wrote: > > > I am not surprised that you have analogue dialup customers. I am very > > surprised that ISDN dialup still exists. ISDN BRI must have been a > > massive success in Germany compared to pretty much anywhere else. > > I'm surprised that people make so many assumptions about other countries. > And till I do not understand why it is so unbelievable that there are > still ISDN dialups. I think it's mainly "OMG HTF can you use teh intarwebs @ 128kbps"? 56k dialup is just unbelievably horrible for anything other than POP email these days, and ISDN is not much faster... These days with ADSL pushing 30,000ft (about 9km) at more than two or three times ISDN speeds, there's not much of a point in ISDN. Dan From tgl at redhat.com Wed Sep 17 05:40:54 2008 From: tgl at redhat.com (Tom Lane) Date: Wed, 17 Sep 2008 01:40:54 -0400 Subject: The state of resolv.conf In-Reply-To: <1221623405.23132.2.camel@localhost.localdomain> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221557672.19134.15.camel@gibraltar.str.redhat.com> <48CF84F5.3010701@city-fan.org> <1221563959.19134.43.camel@gibraltar.str.redhat.com> <1221623405.23132.2.camel@localhost.localdomain> Message-ID: <1861.1221630054@sss.pgh.pa.us> Dan Williams writes: > Nobody is rolling their own code; they all use gethostbyname. The > problem is that glibc's resolver is too simplistic. I asked the glibc > guys about this about 3 years ago and they said they wanted to keep > glibc's resolver simple and that this should be handled either by lwresd > or a caching nameserver. The core issue was that doing something like > polling /etc/resolv.conf for updates would be unecessary on many > platforms. Hm, these are the same people who insist on driving date/time performance into the ground by stat'ing /etc/localtime on every call to any function that has any interest in timezone-dependent info. And surely that file is *less* likely to change than /etc/resolv.conf; not to mention that the ensuing work is orders of magnitude cheaper than sending an inquiry to your friendly local DNS server. Something does not compute here. regards, tom lane From dan at danny.cz Wed Sep 17 05:43:08 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Wed, 17 Sep 2008 07:43:08 +0200 Subject: orphaning python packages In-Reply-To: <1221615364.3277.142.camel@laptop.gunduz.org> References: <20080916205709.GA9224@auslistsprd01.us.dell.com> <1221598930.5296.6.camel@rosebud> <48D026DA.4070107@gmail.com> <1221615364.3277.142.camel@laptop.gunduz.org> Message-ID: <1221630188.3574.3.camel@eagle.danny.cz> Devrim G?ND?Z p??e v St 17. 09. 2008 v 04:36 +0300: > On Tue, 2008-09-16 at 14:36 -0700, Toshio Kuratomi wrote: > > >> python-psycopg -- PostgreSQL database adapter for Python > > >> > > Devrim, when I orphaned this in pkgdb, I approved your > > co-maintainership > > request. If you want to take it over, you're welcome to. > > Done. > > Actually let me see whether we can get rid of that package in Fedora > completely. I don't think it will be possible, TinyERP/OpenERP depends on some features that are not available in python-psycopg2. Dan -- Fedora and Red Hat package maintainer From rakesh.pandit at gmail.com Wed Sep 17 06:18:31 2008 From: rakesh.pandit at gmail.com (Rakesh Pandit) Date: Wed, 17 Sep 2008 11:48:31 +0530 Subject: orphaning python packages In-Reply-To: <48D026DA.4070107@gmail.com> References: <20080916205709.GA9224@auslistsprd01.us.dell.com> <1221598930.5296.6.camel@rosebud> <48D026DA.4070107@gmail.com> Message-ID: 2008/9/17 Toshio Kuratomi : [..] > One further mention: > > python-durus -- A Python Object Database > If no one is interested I will take it. *it is an alternative for ZODB. -- rakesh pandit From rc040203 at freenet.de Wed Sep 17 06:20:08 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 17 Sep 2008 08:20:08 +0200 Subject: change isdn4k-utils to optional In-Reply-To: <1221625788.23335.18.camel@localhost.localdomain> References: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> <20080913102118.GA8601@jasmine.xos.nl> <20080913140643.40ae1d3d@lain.camperquake.de> <20080914161810.55f8678e@lain.camperquake.de> <20080916213900.GB20999@jasmine.xos.nl> <1221625788.23335.18.camel@localhost.localdomain> Message-ID: <1221632408.18327.885.camel@beck.corsepiu.local> On Wed, 2008-09-17 at 00:29 -0400, Dan Williams wrote: > On Tue, 2008-09-16 at 23:39 +0200, Jos Vos wrote: > > On Tue, Sep 16, 2008 at 11:22:37PM +0200, Benny Amorsen wrote: > > > > > I am not surprised that you have analogue dialup customers. I am very > > > surprised that ISDN dialup still exists. ISDN BRI must have been a > > > massive success in Germany compared to pretty much anywhere else. > > > > I'm surprised that people make so many assumptions about other countries. > > And till I do not understand why it is so unbelievable that there are > > still ISDN dialups. > > I think it's mainly "OMG HTF can you use teh intarwebs @ 128kbps"? 56k > dialup is just unbelievably horrible for anything other than POP email > these days, and ISDN is not much faster... Did you ever used ISDN? There are various advantages of ISDN over analog. Even with DSL/VolIP, some of them still are valid today. > These days with ADSL pushing > 30,000ft (about 9km) at more than two or three times ISDN speeds, > there's not much of a point in ISDN. True, but /me thinks people from outside of Germany are not aware about the role ISDN in Germany has. ISDN has been the "standard technology" for phone communication in Germany over more than a decade. It's just thanks to the fact that "German Federal Post" and their successors (Telekom, T-com etc.), haven't managed to abandon analog phone lines "on the last mile", that you still find analog phone lines at all. So, I'd recommend to turn the question into "Why doesn't everybody use broadband in your country/neighborhood?" Your answers would be similar to what I would have to reply above. An alternative question would be: Is Fedora usable without broadband? Then my answer would be: No, Fedora is unusable without broadband, all packages dealing with dial-up on non-broadband can be made optional, because they likely lack a user-base. Ralf From fedora at leemhuis.info Wed Sep 17 06:46:29 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 17 Sep 2008 08:46:29 +0200 Subject: Beware: External repos can break key transition In-Reply-To: <48D07431.1010307@redhat.com> References: <1221158197.6431.24.camel@localhost.localdomain> <48CF0AD9.6040506@redhat.com> <48CF40AE.8080006@leemhuis.info> <48D07431.1010307@redhat.com> Message-ID: <48D0A7C5.8070404@leemhuis.info> On 17.09.2008 05:06, Warren Togami wrote: > Thorsten Leemhuis wrote: >> On 16.09.2008 03:24, Warren Togami wrote: >>> BTW, I just thought of a horribly ugly but automatic working solution >>> to this problem: Filter the require on "xine-lib(plugin-abi) = 1.24" >>> from that package. >>> This sucks, but at least yum update will upgrade to the latest N-V-R >>> packages in both repos so this doesn't exactly break anything. >> It breaks for some times: let's say xine-lib (Fedora) and >> xine-lib-extras-nonfree (Livna) get both pushed to their repos at round >> about the same time (like it was the case for the recent packages). Then >> there is a time window that's afaics round about somewhat between 24 and >> 36 hours long(?) where yum on the user's system might chose to use the >> livna master repo (or a up2date livna mirror) and a Fedora mirror that's >> not up to date. >> Thus yum will install the new xine-lib-extras-nonfree from Livna, but >> not the matching xine-lib from Fedora. Thus all apps that rely on xine >> will silently stop playing some videos that they were able to play >> beforehand. I'd call that breakage ;-) A breakage that IMHO is not >> acceptable, as users won't know what's up and might file bugs. > You are suggesting that out of sync mirrors causing this software to > fail as being "unacceptable". Implicitly this means you suggest it is > better for the entire update transaction to fail and require manual > intervention? > > The former problem is only temporary and likely to clear itself up, > while the latter is permanently fatal. Both problems normally would only be temporary. Just this time it permanently due to the newkey stuff. > Certainly this suggestion sucks, but is there a better way? - for the current newkey problem: copying over xine-lib to the updates repo in the old location could solve this; yes, I know it's not nice; Alternative: maybe for this single update it might make sense to remove the requires from the xine-lib-extras-nonfree package *temporary*; but I'm unable to do that right now as the livna buildsys is down :-/ - to avoid similar problems in the future: Enable skip-broken by default (or do something else to let yum handle such inter-repo dependency problems without causing trouble or confusion for the users; that IMHO is needed in any case) CU knurd From nicolas.mailhot at laposte.net Wed Sep 17 07:31:35 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 17 Sep 2008 09:31:35 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080916212827.GA5290@sonata.rednote.net> References: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> Message-ID: <1221636695.17831.1.camel@rousalka.okg> Le mardi 16 septembre 2008 ? 17:28 -0400, Janina Sajka a ?crit : > Matthias Clasen writes: > > On Tue, 2008-09-16 at 14:34 -0400, Janina Sajka wrote: > > > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented > > > from doing so, paplay believes it should pause playing while I'm away > > > from the gui tty. Now, who's the genius that figured out this "feature?" > > > > Insults won't help your cause. > Well, my apologies if this offends you. Is it supposed to work that way, > though? Is there actually a use case for that behavior? Or is this just > some incidental artifact? This is part of PA's design yes. And many people have already complained it was hostile to their computer usage. -- 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 pbrobinson at gmail.com Wed Sep 17 08:17:07 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 17 Sep 2008 09:17:07 +0100 Subject: change isdn4k-utils to optional In-Reply-To: <1221625788.23335.18.camel@localhost.localdomain> References: <1F1322CC-EE18-49E7-9BBD-D402207D4823@redhat.com> <20080913102118.GA8601@jasmine.xos.nl> <20080913140643.40ae1d3d@lain.camperquake.de> <20080914161810.55f8678e@lain.camperquake.de> <20080916213900.GB20999@jasmine.xos.nl> <1221625788.23335.18.camel@localhost.localdomain> Message-ID: <5256d0b0809170117r5d634b29xb7b2f3596501107c@mail.gmail.com> >> > I am not surprised that you have analogue dialup customers. I am very >> > surprised that ISDN dialup still exists. ISDN BRI must have been a >> > massive success in Germany compared to pretty much anywhere else. >> >> I'm surprised that people make so many assumptions about other countries. >> And till I do not understand why it is so unbelievable that there are >> still ISDN dialups. > > I think it's mainly "OMG HTF can you use teh intarwebs @ 128kbps"? 56k > dialup is just unbelievably horrible for anything other than POP email > these days, and ISDN is not much faster... These days with ADSL pushing > 30,000ft (about 9km) at more than two or three times ISDN speeds, > there's not much of a point in ISDN. You obviously haven't been to a lot of parts of Australia :-) And 9km very much depends on the quality of the cooper as well. Peter From ml at deadbabylon.de Wed Sep 17 09:04:04 2008 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 17 Sep 2008 11:04:04 +0200 Subject: KDE-SIG weekly report (38/2008) Message-ID: <200809171104.09410.ml@deadbabylon.de> This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply to this email or add it to the related meeting page. ---------------------------------------------------------------------------------- = Weekly KDE Summary = Week: 38/2008 Time: 2008-09-16 16:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-09-16 Meeting log: https://fedoraproject.org/w/uploads/f/fa/KDE-SIG-2008-09-16.txt ---------------------------------------------------------------------------------- = Participants = JaroslavReznik KevinKofler LukasTinkl RexDieter SebastianVahl StevenParrish ThanNgo LorenzoVillani ---------------------------------------------------------------------------------- = Agenda = * topics to discuss: - any interest in picking up Features/OpenChange (for F11, it won't make F10)? [1] - Release notes for KDE (needed for Beta? Final?) - Status of KDE 4.1.1 in F9/updates-testing (FEDORA-2008-7789) [2] * recent bugs to discuss: - https://bugzilla.redhat.com/show_bug.cgi?id=461725 = Summary = o Topic 1 - notes any interest in picking up Features/OpenChange? ----------------------------------------------------------------------- * KevinKofler asked if we should maitain or co-maintain OpenChange for kdepim-4.2 in F11. Release notes for KDE (needed for Beta? Final?) ----------------------------------------------------------------------- * JaroslavReznik volunteered for setting up some Release Notes for Fedora 10 Beta. * The section of obsoletes in KDE 4.1 should be double-checked. Status of KDE 4.1.1 in F9/updates-testing (FEDORA-2008-7789) --------------------------------------------------------------------------------------------- * The only known blocker of KDE 4.1.1 is "461725: Konqueror does not finish its procces on exit (KDE 4.1.1)" [3] * This bug seems to occur at least when JavaScript is enabled and it's maybe caused by a fix of the JavaScript Console problem. [4] * A possible fix for that is reverting the patch. * After this bug is fixed KDE 4.1.1 will be pushed to stable. Open discussion: ------------------------- o kdegames: * With ksirk obsoleted by KDE 4.1 kdeaddons-atlantikdesigner is the last package that uses kdegames-devel. * KevinKofler will try to built kdegames without the libkdegames.so devel symlink and so also drop the parallel-devel hacks. o Desktop User Guide: * JaroslavReznik reported from FUDCon that many folks asked for a guide to KDE 4. So we'll really need some volunteers to update the Fedora Desktop Guide. o echo-icon-theme: * Making echo-icon-theme the default icon theme in KDE will need some work. * There are lots of kde-specific icons missing, but Echo will fall back to it's own generic fallbacks before it uses Oxygen. * Also a mixture of Echo and Oxygen icons doesn't have a consistend look. ---------------------------------------------------------------------------------- = Next Meeting = https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-09-23 ---------------------------------------------------------------------------------- = Links = [1] https://fedoraproject.org/wiki/Features/OpenChange [2] https://admin.fedoraproject.org/updates/F9/FEDORA-2008-7789 [3] https://bugzilla.redhat.com/show_bug.cgi?id=461725 [4] http://bugs.kde.org/show_bug.cgi?id=169881 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From mschwendt at gmail.com Wed Sep 17 09:30:27 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 17 Sep 2008 11:30:27 +0200 Subject: rawhide report: 20080912 changes In-Reply-To: <20080912124639.592611F8251@releng2.fedora.phx.redhat.com> References: <20080912124639.592611F8251@releng2.fedora.phx.redhat.com> Message-ID: <20080917113027.71468816.mschwendt@gmail.com> With some of the last changes (or earlier ones from the week before the freeze), I can no longer observe a major performance penalty in rawhide. And one F8 updated partially to F9 with Yum doesn't suffer from that problem anymore either. I did "yum update kernel ; yum update xorg-x11-drv-ati" plus more from xorg, libs and gdm to make the system work. 797 pkgs are still from F8. It used to be a sys cpu usage overhead of something around 20% for basic gnome desktop usage, with peaks much higher than that which slowed down the entire desktop significantly (and visibly also in system monitor). That is not noticable anymore. From benny+usenet at amorsen.dk Wed Sep 17 10:05:56 2008 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: Wed, 17 Sep 2008 12:05:56 +0200 Subject: The state of resolv.conf In-Reply-To: <1861.1221630054@sss.pgh.pa.us> (Tom Lane's message of "Wed\, 17 Sep 2008 01\:40\:54 -0400") References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221557672.19134.15.camel@gibraltar.str.redhat.com> <48CF84F5.3010701@city-fan.org> <1221563959.19134.43.camel@gibraltar.str.redhat.com> <1221623405.23132.2.camel@localhost.localdomain> <1861.1221630054@sss.pgh.pa.us> Message-ID: Tom Lane writes: > And surely that file is *less* likely to change than /etc/resolv.conf; > not to mention that the ensuing work is orders of magnitude cheaper > than sending an inquiry to your friendly local DNS server. > Something does not compute here. True. Having a proper local caching DNS server would be nice though. dnsmasq is lightweight, easy to configure (all configuration options can be set on the command line) and it already integrates with DBUS... If applications can count on having a caching server on the same host, perhaps they will stop implementing their own caching. Getting DNS cache-behaviour right seems to be somewhat difficult, and dnsmasq already did the hard work. It can also do the fancy stuff like "company1.lan can be resolved from 1.2.3.4 whereas example.net is on 9.8.7.6 and 7.6.5.4". That is very handy for VPN's. /Benny From nils at redhat.com Wed Sep 17 10:39:54 2008 From: nils at redhat.com (Nils Philippsen) Date: Wed, 17 Sep 2008 12:39:54 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080916212827.GA5290@sonata.rednote.net> References: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> Message-ID: <1221647994.1454.16.camel@gibraltar.str.redhat.com> On Tue, 2008-09-16 at 17:28 -0400, Janina Sajka wrote: > Matthias Clasen writes: > > On Tue, 2008-09-16 at 14:34 -0400, Janina Sajka wrote: [...] > > > > > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented > > > from doing so, paplay believes it should pause playing while I'm away > > > from the gui tty. Now, who's the genius that figured out this "feature?" > > > > Insults won't help your cause. > Well, my apologies if this offends you. Is it supposed to work that way, > though? Is there actually a use case for that behavior? Or is this just > some incidental artifact? There is a use case for this, namely if you have several "seats" with different logged in users: in this case one probably only wants the sounds of the "active session" being played and others muted. Just in case you ask, we're using that setup at home, my wife and I are logged in all the time an switch between users via the applet or F7/F9. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils at redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nils at redhat.com Wed Sep 17 10:41:40 2008 From: nils at redhat.com (Nils Philippsen) Date: Wed, 17 Sep 2008 12:41:40 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <1221636695.17831.1.camel@rousalka.okg> References: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221636695.17831.1.camel@rousalka.okg> Message-ID: <1221648100.1454.19.camel@gibraltar.str.redhat.com> On Wed, 2008-09-17 at 09:31 +0200, Nicolas Mailhot wrote: > Le mardi 16 septembre 2008 ? 17:28 -0400, Janina Sajka a ?crit : > > Matthias Clasen writes: > > > On Tue, 2008-09-16 at 14:34 -0400, Janina Sajka wrote: > > > > > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented > > > > from doing so, paplay believes it should pause playing while I'm away > > > > from the gui tty. Now, who's the genius that figured out this "feature?" > > > > > > Insults won't help your cause. > > Well, my apologies if this offends you. Is it supposed to work that way, > > though? Is there actually a use case for that behavior? Or is this just > > some incidental artifact? > > This is part of PA's design yes. And many people have already complained > it was hostile to their computer usage. "Hostile" is a bit of a hard word here, don't you think? Maybe PA should offer an option whether to mute/unmute when switching to different VCs or not as there are valid use cases for both behaviors. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils at redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nils at redhat.com Wed Sep 17 11:06:46 2008 From: nils at redhat.com (Nils Philippsen) Date: Wed, 17 Sep 2008 13:06:46 +0200 Subject: The state of resolv.conf In-Reply-To: <48CFDD93.8020207@gmail.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221557672.19134.15.camel@gibraltar.str.redhat.com> <48CF84F5.3010701@city-fan.org> <1221563959.19134.43.camel@gibraltar.str.redhat.com> <3da3b5b40809160434j12a23896k9123a1724d108913@mail.gmail.com> <20080916125136.GA8548@evileye.atkac.englab.brq.redhat.com> <1221579151.4107.11.camel@gibraltar.str.redhat.com> <48CFDD93.8020207@gmail.com> Message-ID: <1221649606.1454.25.camel@gibraltar.str.redhat.com> On Tue, 2008-09-16 at 11:23 -0500, Les Mikesell wrote: > For private ranges/domain views, you'd normally either have a local DNS > server configured as primary or secondary for those zones that can > also resolve public addresses, or for roaming vpn users you'd use a > similar central private server that can resolve everything, public or > private while you are connected. You'll quickly go insane if you try to > mix unrelated private connections (for example, if there really are > different parts of your 10.x.x.x range that don't know about each > other). If there isn't some 'other' part of your 10.x range, you can > point the whole /8 to a server that knows about the part you use. I have a private network which has its own non-public name server. I connect to a VPN with "similar" addresses (10.x.y.z) that doesn't know a thing about my home network (and neither should it). From my POV, that bind still doesn't allow to properly separate responsibilities here is an oversight that needs fixing. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils at redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From lesmikesell at gmail.com Wed Sep 17 12:50:25 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 17 Sep 2008 07:50:25 -0500 Subject: The state of resolv.conf In-Reply-To: <1221649606.1454.25.camel@gibraltar.str.redhat.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221557672.19134.15.camel@gibraltar.str.redhat.com> <48CF84F5.3010701@city-fan.org> <1221563959.19134.43.camel@gibraltar.str.redhat.com> <3da3b5b40809160434j12a23896k9123a1724d108913@mail.gmail.com> <20080916125136.GA8548@evileye.atkac.englab.brq.redhat.com> <1221579151.4107.11.camel@gibraltar.str.redhat.com> <48CFDD93.8020207@gmail.com> <1221649606.1454.25.camel@gibraltar.str.redhat.com> Message-ID: <48D0FD11.2050309@gmail.com> Nils Philippsen wrote: > On Tue, 2008-09-16 at 11:23 -0500, Les Mikesell wrote: >> For private ranges/domain views, you'd normally either have a local DNS >> server configured as primary or secondary for those zones that can >> also resolve public addresses, or for roaming vpn users you'd use a >> similar central private server that can resolve everything, public or >> private while you are connected. You'll quickly go insane if you try to >> mix unrelated private connections (for example, if there really are >> different parts of your 10.x.x.x range that don't know about each >> other). If there isn't some 'other' part of your 10.x range, you can >> point the whole /8 to a server that knows about the part you use. > > I have a private network which has its own non-public name server. I > connect to a VPN with "similar" addresses (10.x.y.z) that doesn't know a > thing about my home network (and neither should it). From my POV, that > bind still doesn't allow to properly separate responsibilities here is > an oversight that needs fixing. As long as someone coordinates addresses on the private ranges you can survive, but the internet wasn't designed to permit duplicate addressing so you can't expect this to work in general. In your scenario I'd have a local name server set up with the forward and reverse zones for the private local zones, with forwarders set for the private zones on the VPN pointed to a DNS server there (or, depending on your relationship, configure as secondary for those zones). Likewise, depending on your relationship and whether the VPN is up all the time, you can let the DNS server on the VPN forward everything thing including public addresses to simplify the config, or you can use your ISP's servers, or just go to the public yourself. Named can be configured to do what you want, it just is not graceful about dynamic changes. You might have a complaint if you regularly switch your vpn connections among different private networks and had to switch the forwarders. -- Les Mikesell lesmikesell at gmail.com From ssorce at redhat.com Wed Sep 17 13:10:07 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 17 Sep 2008 09:10:07 -0400 Subject: The state of resolv.conf In-Reply-To: <1221623405.23132.2.camel@localhost.localdomain> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221557672.19134.15.camel@gibraltar.str.redhat.com> <48CF84F5.3010701@city-fan.org> <1221563959.19134.43.camel@gibraltar.str.redhat.com> <1221623405.23132.2.camel@localhost.localdomain> Message-ID: <1221657007.12851.78.camel@localhost.localdomain> On Tue, 2008-09-16 at 23:50 -0400, Dan Williams wrote: > On Tue, 2008-09-16 at 13:19 +0200, Nils Philippsen wrote: > > On Tue, 2008-09-16 at 11:05 +0100, Paul Howarth wrote: > > > > > Another problem with modifying resolv.conf is that most processes only > > > read it once, usually shortly after starting up, so any changes that > > > happen after that don't get picked up by existing processes. So for > > > instance you could have a web browser that couldn't resolve names from a > > > VPN tunnel that had been brought up after the browser had been started. > > > > Which is a bug IMO. If applications don't use the glibc supplied > > functions for name-resolving, they should at least reinvent the wheel > > properly and check for changes to resolv.conf. > > Nobody is rolling their own code; they all use gethostbyname. You are very wrong. gethostbyname is useful only for querying A records, DNS is more. > The > problem is that glibc's resolver is too simplistic. I asked the glibc > guys about this about 3 years ago and they said they wanted to keep > glibc's resolver simple and that this should be handled either by lwresd > or a caching nameserver. The core issue was that doing something like > polling /etc/resolv.conf for updates would be unecessary on many > platforms. And I think they are correct, it's not glibc duty to provide a solution to good DNS caching. > So the answer seems to be that glibc will not change it's simple > internal resolver (which has more limitations than just noticing > resolv.conf changes), but the recommendation is that lwresd or a local > caching nameserver be used for more complex DNS setups. A caching nameserver that can be instructed what to do when conditions change is what we really need. Simo. -- Simo Sorce * Red Hat, Inc * New York From lesmikesell at gmail.com Wed Sep 17 13:29:19 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 17 Sep 2008 08:29:19 -0500 Subject: The state of resolv.conf In-Reply-To: <1221657007.12851.78.camel@localhost.localdomain> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221557672.19134.15.camel@gibraltar.str.redhat.com> <48CF84F5.3010701@city-fan.org> <1221563959.19134.43.camel@gibraltar.str.redhat.com> <1221623405.23132.2.camel@localhost.localdomain> <1221657007.12851.78.camel@localhost.localdomain> Message-ID: <48D1062F.5010102@gmail.com> Simo Sorce wrote: > > >> So the answer seems to be that glibc will not change it's simple >> internal resolver (which has more limitations than just noticing >> resolv.conf changes), but the recommendation is that lwresd or a local >> caching nameserver be used for more complex DNS setups. > > A caching nameserver that can be instructed what to do when conditions > change is what we really need. Isn't it a little late to redesign the internet so names and addressing aren't delegated hierarchically? -- Les Mikesell lesmikesell at gmail.com From loganjerry at gmail.com Wed Sep 17 13:41:10 2008 From: loganjerry at gmail.com (Jerry James) Date: Wed, 17 Sep 2008 07:41:10 -0600 Subject: make force-tag gone In-Reply-To: <20080914163445.GY2939@inocybe.teonanacatl.org> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809141010.32753.sgrubb@redhat.com> <20080914142955.GU2939@inocybe.teonanacatl.org> <200809141223.58108.sgrubb@redhat.com> <20080914163445.GY2939@inocybe.teonanacatl.org> Message-ID: <870180fe0809170641t3557715bj3a55ef31e733052e@mail.gmail.com> On 2008/9/14 Todd Zullinger wrote: > I'm not arguing in favor of force-tag removal. However, bumping the > release number like this is pretty much required if you have to > rebuild a package in an older branch, which can happen for various > reasons. I don't see what's ugly or kludgy about ensuring that the > n-v-r remains less than what is in the devel branch. I've wondered for awhile now why Fedora uses such a complex versioning scheme. The upstream version numbers should be informative, not normative. The right way to do it is to have a three part version number: [distribution version number]-[# of builds for this distribution number]-[upstream version number], where the last part is for the user's information only; i.e., it does not play into version number comparisons. This lets you deal with rolling back to a previous upstream release without needing Epochs. It lets you fix a problem that manifests in one distribution version only without having to touch the others. You NEVER have upgrade problems because the distribution version number is the most significant part. It lets you give upstream's exact version number, even if it contains hyphens (a problem I've had to deal with twice now). It makes everything so much simpler. Not that it isn't way too late now to change, but how did we wind up with all this unnecessary complexity? This wasn't directed at you, Todd. The thread just made me think of it again. -- Jerry James http://loganjerry.googlepages.com/ From dimi at lattica.com Wed Sep 17 13:45:06 2008 From: dimi at lattica.com (Dimi Paun) Date: Wed, 17 Sep 2008 09:45:06 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <1221647994.1454.16.camel@gibraltar.str.redhat.com> References: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> Message-ID: <1221659106.7264.55.camel@dimi.lattica.com> On Wed, 2008-09-17 at 12:39 +0200, Nils Philippsen wrote: > There is a use case for this, namely if you have several "seats" with > different logged in users: in this case one probably only wants the > sounds of the "active session" being played and others muted. Just in > case you ask, we're using that setup at home, my wife and I are logged > in all the time an switch between users via the applet or > F7/F9. This is a good example of a common problem with free software: we focus on the fringe cases at the detriment of the common ones (many time the ratio can be less then 10/90). Folks that do use multi-seat setups are already more advanced, so those guys should flip a switch (maybe not even a PA but rather a desktop wide switch saying "multi-seat"), the default should match peoples expectations. -- Dimi Paun Lattica, Inc. From u0103a at gmail.com Wed Sep 17 13:45:56 2008 From: u0103a at gmail.com (jude ui) Date: Wed, 17 Sep 2008 09:45:56 -0400 Subject: hi In-Reply-To: <48CFD813.8090206@redhat.com> References: <91157db90809160855i3eaf4b3en5fcddbec7d8060f@mail.gmail.com> <48CFD813.8090206@redhat.com> Message-ID: <91157db90809170645y5491e529p2f36b151b2af21ad@mail.gmail.com> > > > >sup > > nothing -------------- next part -------------- An HTML attachment was scrubbed... URL: From u0103a at gmail.com Wed Sep 17 13:46:19 2008 From: u0103a at gmail.com (jude ui) Date: Wed, 17 Sep 2008 09:46:19 -0400 Subject: jude ui has invited you to open a Google mail account Message-ID: <91157db90809170646g6006f394k@mail.gmail.com> I've been using Gmail and thought you might like to try it out. Here's an invitation to create an account. ----------------------------------------------------------------------- jude ui has invited you to open a free Gmail account. To accept this invitation and register for your account, visit http://mail.google.com/mail/a-c0d6b8a12c-6f96a71ce5-00a31f44d1 Once you create your account, jude ui will be notified with your new email address so you can stay in touch with Gmail! If you haven't already heard about Gmail, it's a new search-based webmail service that offers: - Over 2,700 megabytes (two gigabytes) of free storage - Built-in Google search that instantly finds any message you want - Automatic arrangement of messages and related replies into "conversations" - Powerful spam protection using innovative Google technology - No large, annoying ads--just small text ads and related pages that are relevant to the content of your messages To learn more about Gmail before registering, visit: http://mail.google.com/mail/help/benefits.html And, to see how easy it can be to switch to a new email service, check out our new switch guide: http://mail.google.com/mail/help/switch/ We're still working every day to improve Gmail, so we might ask for your comments and suggestions periodically. We hope you'll like Gmail. We do. And, it's only going to get better. Thanks, The Gmail Team (If clicking the URLs in this message does not work, copy and paste them into the address bar of your browser). From u0103a at gmail.com Wed Sep 17 13:50:16 2008 From: u0103a at gmail.com (jude ui) Date: Wed, 17 Sep 2008 09:50:16 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <48D04F43.30900@fedoraproject.org> References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> Message-ID: <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> On 9/16/08, Rahul Sundaram wrote: > > Tom "spot" Callaway wrote: > > David, >> >> There still looks to be firmware in the kernel source code that hasn't >> been separated >> out properly yet. For example, tg3.c: >> >> >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=drivers/net/tg3.c;hb=HEAD >> >> I don't know if you're tracking that or not, but I'll need to do a legal >> audit at some point to ensure that the firmware is all separated out >> from the source. >> > > Might want to take a look at > > http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html > > Rahul > > Why is there the source for firmware? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at city-fan.org Wed Sep 17 13:59:53 2008 From: paul at city-fan.org (Paul Howarth) Date: Wed, 17 Sep 2008 14:59:53 +0100 Subject: make force-tag gone In-Reply-To: <870180fe0809170641t3557715bj3a55ef31e733052e@mail.gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809141010.32753.sgrubb@redhat.com> <20080914142955.GU2939@inocybe.teonanacatl.org> <200809141223.58108.sgrubb@redhat.com> <20080914163445.GY2939@inocybe.teonanacatl.org> <870180fe0809170641t3557715bj3a55ef31e733052e@mail.gmail.com> Message-ID: <48D10D59.2070604@city-fan.org> Jerry James wrote: > On 2008/9/14 Todd Zullinger wrote: >> I'm not arguing in favor of force-tag removal. However, bumping the >> release number like this is pretty much required if you have to >> rebuild a package in an older branch, which can happen for various >> reasons. I don't see what's ugly or kludgy about ensuring that the >> n-v-r remains less than what is in the devel branch. > > I've wondered for awhile now why Fedora uses such a complex versioning > scheme. The upstream version numbers should be informative, not > normative. The right way to do it is to have a three part version > number: [distribution version number]-[# of builds for this > distribution number]-[upstream version number], where the last part is > for the user's information only; i.e., it does not play into version > number comparisons. This lets you deal with rolling back to a > previous upstream release without needing Epochs. It lets you fix a > problem that manifests in one distribution version only without having > to touch the others. You NEVER have upgrade problems because the > distribution version number is the most significant part. It lets you > give upstream's exact version number, even if it contains hyphens (a > problem I've had to deal with twice now). It makes everything so much > simpler. Not that it isn't way too late now to change, but how did we > wind up with all this unnecessary complexity? > > This wasn't directed at you, Todd. The thread just made me think of it again. It would also mean that every package would have to be rebuilt for every distribution release (to pick up the new distribution version number), something that's not had to happen for a while now with the existing scheme. Paul. From nicolas.mailhot at laposte.net Wed Sep 17 14:22:53 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 17 Sep 2008 16:22:53 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <1221648100.1454.19.camel@gibraltar.str.redhat.com> References: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221636695.17831.1.camel@rousalka.okg> <1221648100.1454.19.camel@gibraltar.str.redhat.com> Message-ID: <1221661373.26943.1.camel@rousalka.okg> Le mercredi 17 septembre 2008 ? 12:41 +0200, Nils Philippsen a ?crit : > On Wed, 2008-09-17 at 09:31 +0200, Nicolas Mailhot wrote: > > Le mardi 16 septembre 2008 ? 17:28 -0400, Janina Sajka a ?crit : > > > Matthias Clasen writes: > > > > On Tue, 2008-09-16 at 14:34 -0400, Janina Sajka wrote: > > > > > > > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented > > > > > from doing so, paplay believes it should pause playing while I'm away > > > > > from the gui tty. Now, who's the genius that figured out this "feature?" > > > > > > > > Insults won't help your cause. > > > Well, my apologies if this offends you. Is it supposed to work that way, > > > though? Is there actually a use case for that behavior? Or is this just > > > some incidental artifact? > > > > This is part of PA's design yes. And many people have already complained > > it was hostile to their computer usage. > > "Hostile" is a bit of a hard word here, don't you think? I don't think anyone can accuse PA of softness or any other form of moderation in this regard. -- 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 janina at rednote.net Wed Sep 17 14:47:32 2008 From: janina at rednote.net (Janina Sajka) Date: Wed, 17 Sep 2008 10:47:32 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <1221612043.18922.5.camel@localhost.localdomain> References: <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> Message-ID: <20080917144732.GE5290@sonata.rednote.net> Matthias Clasen writes: > On Tue, 2008-09-16 at 18:05 -0400, Janina Sajka wrote: > > Chuck Anderson writes: > > > On Tue, Sep 16, 2008 at 02:34:44PM -0400, Janina Sajka wrote: > > > > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented > > > > from doing so, paplay believes it should pause playing while I'm away > > > > from the gui tty. Now, who's the genius that figured out this "feature?" > > > > > > That's ConsoleKit deactivating the streams on the non-active console. > > > This is so mult-user-switching can work and each user can have their > > > own audio. > > > > > OK. Thanks for the explanation. > > > > So, the concept limits audio to a single console, even if the same user > > is logged in somewhere else? I guess running pa as a systen daemon would > > not exhibit this behavior? > > > > Actually, Lennart changed PA to not be strictly per-session, but > per-user, I think. But I don't know the details of how that works. > I also thought it was per user, but I got the same pause behavior even after I logged in on Ctrl+Alt+F1, as I recall. > I've looked into your 'login screen ready' sound problem, and found that > it doesn't work atm due to a pulseaudio bug: > https://bugzilla.redhat.com/show_bug.cgi?id=462537 Thanks for filing this one. PS: IMHO, it would be worth the extra effort to clear this and the associated issues as discussed upstream: http://mail.gnome.org/archives/gdm-list/2008-September/msg00015.html in time for the next spin of RHEL. The Linux desktop, with orca, gok, and dasher as builtin AT, plus the solid support for a11y in Firefox 3 and Open Office 3 should finally make Linux a serious contender for U.S. Government desktop sales under Sec. 508--something that hasn't been there before. Janina > > > Matthias > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka, Phone: +1.202.595.7777; sip:janina at a11y.org Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada Learn more at http://ScreenlessPhone.Com Chair, Open Accessibility janina at a11y.org Linux Foundation http://a11y.org From mattdm at mattdm.org Wed Sep 17 15:07:29 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 17 Sep 2008 11:07:29 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <1221647994.1454.16.camel@gibraltar.str.redhat.com> References: <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> Message-ID: <20080917150729.GA4076@jadzia.bu.edu> On Wed, Sep 17, 2008 at 12:39:54PM +0200, Nils Philippsen wrote: > There is a use case for this, namely if you have several "seats" with > different logged in users: in this case one probably only wants the > sounds of the "active session" being played and others muted. Just in > case you ask, we're using that setup at home, my wife and I are logged > in all the time an switch between users via the applet or > F7/F9. Yes, we do the same at my house. (Presumably you are also using KDM, given that current GDM is apparently totally broken in this regard?) -- Matthew Miller mattdm at mattdm.org From mattdm at mattdm.org Wed Sep 17 15:08:09 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 17 Sep 2008 11:08:09 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <1221659106.7264.55.camel@dimi.lattica.com> References: <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <1221659106.7264.55.camel@dimi.lattica.com> Message-ID: <20080917150809.GB4076@jadzia.bu.edu> On Wed, Sep 17, 2008 at 09:45:06AM -0400, Dimi Paun wrote: > This is a good example of a common problem with free software: we focus > on the fringe cases at the detriment of the common ones (many time the > ratio can be less then 10/90). Where "fringe case" is defined as "whatever I'm not doing" and "common case" is defined at as "the way I do it"? -- Matthew Miller mattdm at mattdm.org From mattdm at mattdm.org Wed Sep 17 15:14:21 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 17 Sep 2008 11:14:21 -0400 Subject: configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!) In-Reply-To: <1221310726.3076.46.camel@rosebud> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <1221285235.3492.4.camel@fantail.jnet.net.nz> <1221301012.3152.7.camel@pc-notebook> <48CBABC4.5060005@leemhuis.info> <20080913120636.GA20878@jadzia.bu.edu> <1221310726.3076.46.camel@rosebud> Message-ID: <20080917151421.GC4076@jadzia.bu.edu> On Sat, Sep 13, 2008 at 08:58:46AM -0400, Seth Vidal wrote: > I don't like the wheel group way into sudoers. Not the least of which > because the wheel group, on systems which are using some other form of > nss than local files, can be mucked with too easily. If you can muck with groups, you can get into the group 'root', and the point is moot, no? -- Matthew Miller mattdm at mattdm.org From mattdm at mattdm.org Wed Sep 17 15:23:42 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 17 Sep 2008 11:23:42 -0400 Subject: configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!) In-Reply-To: <1221426597.25056.6.camel@rosebud> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <1221285235.3492.4.camel@fantail.jnet.net.nz> <1221301012.3152.7.camel@pc-notebook> <48CBABC4.5060005@leemhuis.info> <20080913120636.GA20878@jadzia.bu.edu> <1221310726.3076.46.camel@rosebud> <80d7e4090809141226g7fa6fcfdy4d670dcaf9289584@mail.gmail.com> <1221426597.25056.6.camel@rosebud> Message-ID: <20080917152342.GD4076@jadzia.bu.edu> On Sun, Sep 14, 2008 at 05:09:57PM -0400, Seth Vidal wrote: > 80% is the entry gets added to /etc/sudoers by the user addition > interface if 'make this user an admin' is checked. > I think the entry would look like: > username ALL=(ALL) ALL The problem is that this is file has a ridiculously complicated and picky syntax. I am really skeptical about machine-editing it. It seems a lot safer to have a group there, and add and remove from that group. It doesn't have to be "wheel", although that's traditional. Plus, we get userhelper auth-as-user functionality basically for free. -- Matthew Miller mattdm at mattdm.org From alain.portal at free.fr Wed Sep 17 15:34:29 2008 From: alain.portal at free.fr (Alain PORTAL) Date: Wed, 17 Sep 2008 17:34:29 +0200 Subject: Orphaning my packages In-Reply-To: <1221602818.8512.4.camel@PB3.Linux> References: <200809161740.01071.alain.portal@free.fr> <1221602818.8512.4.camel@PB3.Linux> Message-ID: <200809171734.30563.alain.portal@free.fr> Le mercredi 17 septembre 2008, Paul a ?crit : > Hi, > > > kbackup -- Back up your data in a simple, user friendly way > > kicad -- Electronic schematic diagrams and printed circuit board artwork > > pikdev -- IDE for development of PICmicro based application (under > > Linux/KDE) piklab -- Development environment for applications based on > > PIC & dsPIC microcontrollers > > pikloops -- Code generator for PIC delays > > If no-one else wants them, I'll take these on. Thanks! kicad is already taken, but it could be a good idea to get a comaintainer as it isn't easy to package. kbackup has a new release: http://kde-apps.org/content/show.php/KBackup?content=44998 Regards. Alain -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- 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 Wed Sep 17 15:39:53 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 17 Sep 2008 10:39:53 -0500 (CDT) Subject: Orphaning my packages In-Reply-To: <200809171734.30563.alain.portal@free.fr> References: <200809161740.01071.alain.portal@free.fr> <1221602818.8512.4.camel@PB3.Linux> <200809171734.30563.alain.portal@free.fr> Message-ID: <50834.198.175.55.5.1221665993.squirrel@mail.jcomserv.net> > Le mercredi 17 septembre 2008, Paul a ??crit : >> Hi, >> >> > kbackup -- Back up your data in a simple, user friendly way >> > kicad -- Electronic schematic diagrams and printed circuit board >> artwork >> > pikdev -- IDE for development of PICmicro based application (under >> > Linux/KDE) piklab -- Development environment for applications based on >> > PIC & dsPIC microcontrollers >> > pikloops -- Code generator for PIC delays >> >> If no-one else wants them, I'll take these on. > > Thanks! > kicad is already taken, but it could be a good idea to get a comaintainer > as > it isn't easy to package. Actually, I've having quite a lot of trouble. If you're more familiar, perhaps you should take kicad? > kbackup has a new release: > http://kde-apps.org/content/show.php/KBackup?content=44998 > > Regards. > Alain > -- > Les pages de manuel Linux en fran??ais > http://manpagesfr.free.fr/ > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From dimi at lattica.com Wed Sep 17 15:42:34 2008 From: dimi at lattica.com (Dimi Paun) Date: Wed, 17 Sep 2008 11:42:34 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080917150809.GB4076@jadzia.bu.edu> References: <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <1221659106.7264.55.camel@dimi.lattica.com> <20080917150809.GB4076@jadzia.bu.edu> Message-ID: <1221666155.7264.75.camel@dimi.lattica.com> On Wed, 2008-09-17 at 11:08 -0400, Matthew Miller wrote: > Where "fringe case" is defined as "whatever I'm not doing" and "common > case" is defined at as "the way I do it"? Not at all. It is not always easy to figure out, but it's not all that difficult either. There are untold number of cases where we put the carriage before the horse so to speak: * slower boot times for _everybody_ because of fringe cases like when /usr is loaded from the network. Never mind that such setups are run by technically savvy people that could be bothered to flip a few switches. * geditor opens an idiotic tab by default, and it's slow to load because it's cool to have a "programming" editor. Never mind that most people are non-programmers, and even those want to see files quickly without programming. On a fast machine it takes sometimes 2-3 sec to load the darn thing, whereas it takes 250ms to load notepad in wine! I could go on. But the bottom line is that we sometimes make bad decisions for "default" values (I guess because they are mostly taken by people that are too technical). And I'm sorry to say it, but for vast majority of cases "default" should be "what people expect" and that usually means "what Windows does". I know it sounds heretic, but that's the reality of it. Not that we should be stuck there forever, but we should have really good reasons to deviate, and when we do we should do it gently. Instead, we do it a lot of times "on a whim", and that ends up hurting the end user. -- Dimi Paun Lattica, Inc. From jkeating at redhat.com Wed Sep 17 15:47:25 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 17 Sep 2008 08:47:25 -0700 Subject: configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!) In-Reply-To: <20080917152342.GD4076@jadzia.bu.edu> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <1221285235.3492.4.camel@fantail.jnet.net.nz> <1221301012.3152.7.camel@pc-notebook> <48CBABC4.5060005@leemhuis.info> <20080913120636.GA20878@jadzia.bu.edu> <1221310726.3076.46.camel@rosebud> <80d7e4090809141226g7fa6fcfdy4d670dcaf9289584@mail.gmail.com> <1221426597.25056.6.camel@rosebud> <20080917152342.GD4076@jadzia.bu.edu> Message-ID: <1221666445.14439.4.camel@luminos.localdomain> On Wed, 2008-09-17 at 11:23 -0400, Matthew Miller wrote: > The problem is that this is file has a ridiculously complicated and picky > syntax. I am really skeptical about machine-editing it. Augeas ? /etc/sudoers.d/ ? It's not like we haven't solved the problem of 'complicated and picky syntax' before... -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From ssorce at redhat.com Wed Sep 17 15:52:22 2008 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 17 Sep 2008 11:52:22 -0400 Subject: configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!) In-Reply-To: <1221666445.14439.4.camel@luminos.localdomain> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <1221285235.3492.4.camel@fantail.jnet.net.nz> <1221301012.3152.7.camel@pc-notebook> <48CBABC4.5060005@leemhuis.info> <20080913120636.GA20878@jadzia.bu.edu> <1221310726.3076.46.camel@rosebud> <80d7e4090809141226g7fa6fcfdy4d670dcaf9289584@mail.gmail.com> <1221426597.25056.6.camel@rosebud> <20080917152342.GD4076@jadzia.bu.edu> <1221666445.14439.4.camel@luminos.localdomain> Message-ID: <1221666742.12851.134.camel@localhost.localdomain> On Wed, 2008-09-17 at 08:47 -0700, Jesse Keating wrote: > On Wed, 2008-09-17 at 11:23 -0400, Matthew Miller wrote: > > The problem is that this is file has a ridiculously complicated and picky > > syntax. I am really skeptical about machine-editing it. > > Augeas ? /etc/sudoers.d/ ? It's not like we haven't solved the problem > of 'complicated and picky syntax' before... Why preferring to modify the file instead of the simpler method of using group memeberships ? Simo. -- Simo Sorce * Red Hat, Inc * New York From a.badger at gmail.com Wed Sep 17 15:53:19 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Wed, 17 Sep 2008 08:53:19 -0700 Subject: make force-tag gone In-Reply-To: <870180fe0809170641t3557715bj3a55ef31e733052e@mail.gmail.com> References: <1220955240.24928.69.camel@cookie.hadess.net> <200809141010.32753.sgrubb@redhat.com> <20080914142955.GU2939@inocybe.teonanacatl.org> <200809141223.58108.sgrubb@redhat.com> <20080914163445.GY2939@inocybe.teonanacatl.org> <870180fe0809170641t3557715bj3a55ef31e733052e@mail.gmail.com> Message-ID: <48D127EF.10401@gmail.com> Jerry James wrote: > On 2008/9/14 Todd Zullinger wrote: >> I'm not arguing in favor of force-tag removal. However, bumping the >> release number like this is pretty much required if you have to >> rebuild a package in an older branch, which can happen for various >> reasons. I don't see what's ugly or kludgy about ensuring that the >> n-v-r remains less than what is in the devel branch. > > I've wondered for awhile now why Fedora uses such a complex versioning > scheme. The upstream version numbers should be informative, not > normative. The right way to do it is to have a three part version > number: [distribution version number]-[# of builds for this > distribution number]-[upstream version number], where the last part is > for the user's information only; i.e., it does not play into version > number comparisons. This lets you deal with rolling back to a > previous upstream release without needing Epochs. It lets you fix a > problem that manifests in one distribution version only without having > to touch the others. You NEVER have upgrade problems because the > distribution version number is the most significant part. It lets you > give upstream's exact version number, even if it contains hyphens (a > problem I've had to deal with twice now). It makes everything so much > simpler. Not that it isn't way too late now to change, but how did we > wind up with all this unnecessary complexity? > It might be simple to implement this but it will break people's expectations. To find out which upstream version of the software Ian rpm equates to I'd have to query release instead of version. When you throw hyphens into the mix, it will also break their scripts. ie to parse: name-with-hyphens-version-release.arch.rpm I can read the filename backwards, popping off release and version, and everything remaining being the name. to parse: name-with-hyphens-ends-in-dash-number-version-release-with-hyphens.arch.rpm I can't tell where the name ends and the version begins nor where the release ends and the version begins. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From jkeating at redhat.com Wed Sep 17 16:02:18 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 17 Sep 2008 09:02:18 -0700 Subject: configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!) In-Reply-To: <1221666742.12851.134.camel@localhost.localdomain> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <1221285235.3492.4.camel@fantail.jnet.net.nz> <1221301012.3152.7.camel@pc-notebook> <48CBABC4.5060005@leemhuis.info> <20080913120636.GA20878@jadzia.bu.edu> <1221310726.3076.46.camel@rosebud> <80d7e4090809141226g7fa6fcfdy4d670dcaf9289584@mail.gmail.com> <1221426597.25056.6.camel@rosebud> <20080917152342.GD4076@jadzia.bu.edu> <1221666445.14439.4.camel@luminos.localdomain> <1221666742.12851.134.camel@localhost.localdomain> Message-ID: <1221667338.14439.5.camel@luminos.localdomain> On Wed, 2008-09-17 at 11:52 -0400, Simo Sorce wrote: > > Augeas ? /etc/sudoers.d/ ? It's not like we haven't solved the problem > > of 'complicated and picky syntax' before... > > Why preferring to modify the file instead of the simpler method of using > group memeberships ? I don't have a preference, I just didn't buy the argument provided. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Wed Sep 17 16:07:55 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 17 Sep 2008 18:07:55 +0200 Subject: configuring sudo by default In-Reply-To: <1221666445.14439.4.camel@luminos.localdomain> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <1221285235.3492.4.camel@fantail.jnet.net.nz> <1221301012.3152.7.camel@pc-notebook> <48CBABC4.5060005@leemhuis.info> <20080913120636.GA20878@jadzia.bu.edu> <1221310726.3076.46.camel@rosebud> <80d7e4090809141226g7fa6fcfdy4d670dcaf9289584@mail.gmail.com> <1221426597.25056.6.camel@rosebud> <20080917152342.GD4076@jadzia.bu.edu> <1221666445.14439.4.camel@luminos.localdomain> Message-ID: <48D12B5B.4010509@leemhuis.info> On 17.09.2008 17:47, Jesse Keating wrote: > On Wed, 2008-09-17 at 11:23 -0400, Matthew Miller wrote: >> The problem is that this is file has a ridiculously complicated and picky >> syntax. I am really skeptical about machine-editing it. > Augeas ? Augeas afaik (correct me if I'm wrong) doesn't solve the "rpmnew files get generated and need to be manually merged if local conf file was modified"-problem. This > /etc/sudoers.d/ ? OTOH would. CU knurd From sundaram at fedoraproject.org Wed Sep 17 17:00:50 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 17 Sep 2008 22:30:50 +0530 Subject: Fedora not "free" enough for GNU? In-Reply-To: <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> Message-ID: <48D137C2.3030801@fedoraproject.org> jude ui wrote: > Might want to take a look at > > http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html > > Rahul > > > Why is there the source for firmware? Sorry. I am not sure what that means. Rahul From billcrawford1970 at gmail.com Wed Sep 17 18:06:23 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 17 Sep 2008 19:06:23 +0100 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <20080912202813.GL6092@nb.net.home> <20080912203036.GN32741@angus.ind.WPI.EDU> <20080913015752.GB4421@sonata.rednote.net> Message-ID: <544eb990809171106q4f1aa298ucf67fc99914a6376@mail.gmail.com> On 13/09/2008, Colin Walters wrote: > I just tried this too with GDM, and got speech too. I right clicked > in the lower left of the screen, checked the "Read text" option, and > moused over and heard sound. Have you filed a bug about this issue? Good grief. You're actually telling people who NEED A SCREEN READER to right click and read the text (which might be too small)?? From walters at verbum.org Wed Sep 17 18:17:24 2008 From: walters at verbum.org (Colin Walters) Date: Wed, 17 Sep 2008 14:17:24 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <544eb990809171106q4f1aa298ucf67fc99914a6376@mail.gmail.com> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <20080912202813.GL6092@nb.net.home> <20080912203036.GN32741@angus.ind.WPI.EDU> <20080913015752.GB4421@sonata.rednote.net> <544eb990809171106q4f1aa298ucf67fc99914a6376@mail.gmail.com> Message-ID: On Wed, Sep 17, 2008 at 2:06 PM, Bill Crawford wrote: > On 13/09/2008, Colin Walters wrote: > >> I just tried this too with GDM, and got speech too. I right clicked >> in the lower left of the screen, checked the "Read text" option, and >> moused over and heard sound. Have you filed a bug about this issue? > > Good grief. You're actually telling people who NEED A SCREEN READER to > right click and read the text (which might be too small)?? No. I followed up with a post about how this can be enabled by default, and there is a keybinding as well. From joshuacov at googlemail.com Wed Sep 17 18:36:24 2008 From: joshuacov at googlemail.com (Joshua C.) Date: Wed, 17 Sep 2008 20:36:24 +0200 Subject: modesetting feature status In-Reply-To: <5f6f8c5f0809120305y41ac861fq8a91d1547519a955@mail.gmail.com> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221145599.11745.3.camel@aglarond.local> <1221152956.4345.17.camel@atropine.boston.devel.redhat.com> <1221155164.11745.13.camel@aglarond.local> <5f6f8c5f0809111209o1d28bae4p246d699f3520c40@mail.gmail.com> <1221174980.30676.10.camel@optimus> <5f6f8c5f0809120305y41ac861fq8a91d1547519a955@mail.gmail.com> Message-ID: <5f6f8c5f0809171136lb722a87taee2cbd5afc2ff29@mail.gmail.com> 2008/9/12 Joshua C. : > 2008/9/12 Dave Airlie : > >> >> bug number? > > https://bugzilla.redhat.com/show_bug.cgi?id=461545 > >> >> what kernel did you last test with? >> >> stop scare mongering its a beta release, if it still doesn't work at > > I'm just trying to HELP > > >> devel freeze I'll blacklist all the broken machines. >> >> Dave. Dave can you make the radeon driver fall back to vesa in case of a problem? my display disappears after modprobe radeon modeset=1 and if the driver unloads itself, then maybe i can see any error messages on the display. Are there any other ways to help with the debugging of this without ssh? From lesmikesell at gmail.com Wed Sep 17 18:49:01 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 17 Sep 2008 13:49:01 -0500 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <1221666155.7264.75.camel@dimi.lattica.com> References: <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <1221659106.7264.55.camel@dimi.lattica.com> <20080917150809.GB4076@jadzia.bu.edu> <1221666155.7264.75.camel@dimi.lattica.com> Message-ID: <48D1511D.60607@gmail.com> Dimi Paun wrote: > > And I'm sorry to say it, but for vast majority of cases "default" > should be "what people expect" and that usually means "what Windows > does". If people want to run windows, it isn't difficult to find. I like to run linux for the things it can do better than windows. Please don't throw that away. -- Les Mikesell lesmikesell at gmail.com From dimi at lattica.com Wed Sep 17 19:09:07 2008 From: dimi at lattica.com (Dimi Paun) Date: Wed, 17 Sep 2008 15:09:07 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <48D1511D.60607@gmail.com> References: <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <1221659106.7264.55.camel@dimi.lattica.com> <20080917150809.GB4076@jadzia.bu.edu> <1221666155.7264.75.camel@dimi.lattica.com> <48D1511D.60607@gmail.com> Message-ID: <1221678547.7264.95.camel@dimi.lattica.com> On Wed, 2008-09-17 at 13:49 -0500, Les Mikesell wrote: > If people want to run windows, it isn't difficult to find. I like to > run linux for the things it can do better than windows. Please don't > throw that away. Nobody is proposing to throw everything away. Look -- I've been using Linux _exclusively_ for about 12+ years. I like it. But we do have our faults too. Blind hatred of Windows will not help us build a better experience. We should learn from their successes just like we learn from their failures. At least we have the benefit of hindsight. -- Dimi Paun Lattica, Inc. From kevin at scrye.com Wed Sep 17 19:21:58 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 17 Sep 2008 13:21:58 -0600 Subject: non-responsive maintainer 'misa': mx and pyOpenSSL packages up for adoption In-Reply-To: <1221512570.8091.8.camel@PB3.Linux> References: <20080915033702.GA4887@auslistsprd01.us.dell.com> <1221465947.9141.5.camel@PB3.Linux> <1221485493.5272.16.camel@PB3.Linux> <20080915185247.GA3627@auslistsprd01.us.dell.com> <1221512570.8091.8.camel@PB3.Linux> Message-ID: <20080917132158.0066f4c7@ohm.scrye.com> On Mon, 15 Sep 2008 22:02:50 +0100 paul at all-the-johnsons.co.uk (Paul) wrote: > Hi, > > > > > > > If someone puts me down as the co-maintainer, mx-3.1.1 is ready > > > to roll into rawhide! > > > > I move that Paul be allowed to take over the 'mx' package. I > > further request approval from a member of FESCo. > > > > Policy: If at least one FESco member approves the takeover, and no > > one objects within 3 days, you may take over the package. +1 from me. > > I also move that pyOpenSSL be orphaned, allowing another willing > > packager to take it on. This requires approval of FESCo. > > If no-one else wants it, I'll take that as well. ok. They are both yours... Thanks! > TTFN > > Paul kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From fedora at camperquake.de Wed Sep 17 19:35:18 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Wed, 17 Sep 2008 21:35:18 +0200 Subject: libbluetooth soname bump In-Reply-To: <1221147676.24928.196.camel@cookie.hadess.net> References: <1221147676.24928.196.camel@cookie.hadess.net> Message-ID: <20080917213518.7c601812@lain.camperquake.de> Hi. On Thu, 11 Sep 2008 16:41:16 +0100, Bastien Nocera wrote > It all went a bit quick, and the new bluez 4.x utilities and libraries > have landed in rawhide. This means that a number of applications > needed to be rebuilt. Maybe I'm a bit slow, but the associated bluez-utils package seems to have lost quite a bit of functionality on the way. There is no hcid any more, and /etc/bluetooth/rfcomm.conf seems to get ignored, too. Is there a new way to do things? From dimitris at glezos.com Wed Sep 17 14:41:08 2008 From: dimitris at glezos.com (Dimitris Glezos) Date: Wed, 17 Sep 2008 17:41:08 +0300 Subject: Fedora 10 and translations: String freeze and repackaging Message-ID: <6d4237680809170741u45670cb4h668b192258a24d56@mail.gmail.com> A kind reminder that shipped packages for which Fedora is upstream for are **string frozen** since the Beta freeze of September 11: no translatable strings can be added or modified for Fedora 10. For more information, please refer to the F10 schedule and the string freeze policy: https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy Also, please note that the Fedora L10n Steering Committee has moved the Translation Deadline to 14/10 (one week earlier). Maintainers of the above packages need to put a reminder to issue a new build *later* than this date and before the Development Freeze of 21/10. The closer to the development freeze the rebuild takes place, the better for our translators. If you have not received any translations since the last build, a rebuild is not necessary. For more information concerning these two translation-related dates, please refer to: https://fedoraproject.org/wiki/L10N/Freezes Feel free to drop an email to fedora-trans-list at redhat.com if you have any questions. Thanks. -d -- Dimitris Glezos Jabber ID: glezos at jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From poelstra at redhat.com Wed Sep 17 19:39:03 2008 From: poelstra at redhat.com (John Poelstra) Date: Wed, 17 Sep 2008 12:39:03 -0700 Subject: [Fwd: bugzilla.redhat.com, hardware.redhat.com Planned Outage | 09-17-2008 - 1700 EDT (-0400)] Message-ID: <48D15CD7.1060203@redhat.com> -------- Original Message -------- Subject: bugzilla.redhat.com, hardware.redhat.com Planned Outage | 09-17-2008 - 1700 EDT (-0400) Date: Wed, 17 Sep 2008 15:00:29 -0400 From: Matthew Schick O U T A G E R E Q U E S T F O R M ===================================== Severity: Severity One (Urgent) Scheduled Date: 09-17-2008 Scheduled Time: 1700 EDT (-0400) Estimated Time Required: 30 minutes Performed By: Engineering Operations People/Groups Impacted: Bugzilla users Site/Services Affected: bugzilla.redhat.com, hardware.redhat.com Impact: Bugzilla and Hardware will be offline briefly. Description: New perl package will be installed to address performance concerns. Mysql servers will be upgraded for bugfixes. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From ajax at redhat.com Wed Sep 17 20:39:37 2008 From: ajax at redhat.com (Adam Jackson) Date: Wed, 17 Sep 2008 16:39:37 -0400 Subject: modesetting feature status In-Reply-To: <5f6f8c5f0809171136lb722a87taee2cbd5afc2ff29@mail.gmail.com> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221145599.11745.3.camel@aglarond.local> <1221152956.4345.17.camel@atropine.boston.devel.redhat.com> <1221155164.11745.13.camel@aglarond.local> <5f6f8c5f0809111209o1d28bae4p246d699f3520c40@mail.gmail.com> <1221174980.30676.10.camel@optimus> <5f6f8c5f0809120305y41ac861fq8a91d1547519a955@mail.gmail.com> <5f6f8c5f0809171136lb722a87taee2cbd5afc2ff29@mail.gmail.com> Message-ID: <1221683977.15981.223.camel@atropine.boston.devel.redhat.com> On Wed, 2008-09-17 at 20:36 +0200, Joshua C. wrote: > Dave can you make the radeon driver fall back to vesa in case of a > problem? my display disappears after modprobe radeon modeset=1 and if > the driver unloads itself, then maybe i can see any error messages on > the display. Not really. There's no way to ask the display "hey, that mode I'm sending you, does it work?" so it's sort of hard to programmatically know when it doesn't work. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From joshuacov at googlemail.com Wed Sep 17 21:33:46 2008 From: joshuacov at googlemail.com (Joshua C.) Date: Wed, 17 Sep 2008 22:33:46 +0100 Subject: modesetting feature status In-Reply-To: <1221683977.15981.223.camel@atropine.boston.devel.redhat.com> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221145599.11745.3.camel@aglarond.local> <1221152956.4345.17.camel@atropine.boston.devel.redhat.com> <1221155164.11745.13.camel@aglarond.local> <5f6f8c5f0809111209o1d28bae4p246d699f3520c40@mail.gmail.com> <1221174980.30676.10.camel@optimus> <5f6f8c5f0809120305y41ac861fq8a91d1547519a955@mail.gmail.com> <5f6f8c5f0809171136lb722a87taee2cbd5afc2ff29@mail.gmail.com> <1221683977.15981.223.camel@atropine.boston.devel.redhat.com> Message-ID: <5f6f8c5f0809171433t3d1af2a1w7685936b396522c6@mail.gmail.com> 2008/9/17 Adam Jackson : > On Wed, 2008-09-17 at 20:36 +0200, Joshua C. wrote: > >> Dave can you make the radeon driver fall back to vesa in case of a >> problem? my display disappears after modprobe radeon modeset=1 and if >> the driver unloads itself, then maybe i can see any error messages on >> the display. > > Not really. There's no way to ask the display "hey, that mode I'm > sending you, does it work?" so it's sort of hard to programmatically > know when it doesn't work. > > - ajax modprobe radeon modeset=0 works fine and modeset=1 crashes the display. this means that modeset=1 should either (1) pass some (already available information) to the driver or (2) make it execute a spesific routine. case 1 - there should be a way to look into this info before it's passed to the driver. case 2 - then my problem is in the routine and only debugging can help. I tried to look into the drm-modeset-radeon patch in kernel -0.317 and -0.321 but it is 1,7 MB and I don't know where to start from. Any idea what i should look at? From dpquigl at tycho.nsa.gov Wed Sep 17 21:17:35 2008 From: dpquigl at tycho.nsa.gov (David P. Quigley) Date: Wed, 17 Sep 2008 17:17:35 -0400 Subject: Loopback mounting the root filesystem using nash Message-ID: <1221686255.3685.64.camel@moss-terrapins.epoch.ncsc.mil> Hello, I've been working on trying to build a really tiny SELinux enabled version of fedora and I am getting stuck with something things in nash. I created a file called rootfs.img using the following commands: dd if=/dev/zero of=rootfs.img count=1 bs=64MB mke2fs -j -F -i 1024 rootfs.img I then mounted it as a loopback fs and proceeded to copy the appropriate filesystem structure and what I need to get the system running with busybox into it. I ran into a problem when I tried to use this from an initrd. I first tried to losetup the file onto /dev/loop0 but kept getting loop: can't get info on device /dev/loop0: No such device or address. I thought it was because I was missing the loop device so I created it with mknod /dev/loop0 b 7 0 (as it is on my actual fedora box) but this didn't help. The next thing I tried was to not bother with this and just use the -o loop option to mount but this fails with the error "mount: error mounting /rootfs.img on /sysroot as ext3: Block device required" I started by unpacking the initrd that is for the kernel that I am currently running so at some point it worked. I have pasted the modified init script that I am using in hopes that someone can help me figure out what I am doing wrong. Dave #!/bin/nash mount -t proc /proc /proc setquiet echo Mounting proc filesystem echo Mounting sysfs filesystem mount -t sysfs /sys /sys echo Creating /dev mount -o mode=0755 -t tmpfs /dev /dev mkdir /dev/pts mount -t devpts -o gid=5,mode=620 /dev/pts /dev/pts mkdir /dev/shm mkdir /dev/mapper echo Creating initial device nodes mknod /dev/null c 1 3 mknod /dev/zero c 1 5 mknod /dev/systty c 4 0 mknod /dev/tty c 5 0 mknod /dev/console c 5 1 mknod /dev/ptmx c 5 2 mknod /dev/tty0 c 4 0 mknod /dev/tty1 c 4 1 mknod /dev/tty2 c 4 2 mknod /dev/tty3 c 4 3 mknod /dev/tty4 c 4 4 mknod /dev/tty5 c 4 5 mknod /dev/tty6 c 4 6 mknod /dev/tty7 c 4 7 mknod /dev/tty8 c 4 8 mknod /dev/tty9 c 4 9 mknod /dev/tty10 c 4 10 mknod /dev/tty11 c 4 11 mknod /dev/tty12 c 4 12 mknod /dev/ttyS0 c 4 64 mknod /dev/ttyS1 c 4 65 mknod /dev/ttyS2 c 4 66 mknod /dev/ttyS3 c 4 67 mknod /dev/loop0 b 7 0 echo Setting up hotplug. hotplug echo Creating block device nodes. mkblkdevs echo "Loading ehci-hcd module" modprobe -q ehci-hcd echo "Loading ohci-hcd module" modprobe -q ohci-hcd echo "Loading uhci-hcd module" modprobe -q uhci-hcd mount -t usbfs /proc/bus/usb /proc/bus/usb echo "Loading loop module" modprobe -q loop echo "Loading ext3 module" modprobe -q ext3 echo "Loading scsi_mod module" modprobe -q scsi_mod echo "Loading sd_mod module" modprobe -q sd_mod echo "Loading scsi_transport_spi module" modprobe -q scsi_transport_spi echo "Loading mptbase module" modprobe -q mptbase echo "Loading mptscsih module" modprobe -q mptscsih echo "Loading mptspi module" modprobe -q mptspi modprobe scsi_wait_scan rmmod scsi_wait_scan mkblkdevs resume /dev/sda2 echo "Creating root device" mkrootdev -t ext3 -o loop,ro /rootfs.img echo "Mounting root filesystem" mount -t ext3 /sysroot echo Setting up other filesystems. setuproot echo Switching to new root and running init. switchroot echo Booting has failed. sleep -1 From joshuacov at googlemail.com Wed Sep 17 21:37:05 2008 From: joshuacov at googlemail.com (Joshua C.) Date: Wed, 17 Sep 2008 22:37:05 +0100 Subject: modesetting feature status In-Reply-To: <1221683977.15981.223.camel@atropine.boston.devel.redhat.com> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221145599.11745.3.camel@aglarond.local> <1221152956.4345.17.camel@atropine.boston.devel.redhat.com> <1221155164.11745.13.camel@aglarond.local> <5f6f8c5f0809111209o1d28bae4p246d699f3520c40@mail.gmail.com> <1221174980.30676.10.camel@optimus> <5f6f8c5f0809120305y41ac861fq8a91d1547519a955@mail.gmail.com> <5f6f8c5f0809171136lb722a87taee2cbd5afc2ff29@mail.gmail.com> <1221683977.15981.223.camel@atropine.boston.devel.redhat.com> Message-ID: <5f6f8c5f0809171437y3c022d8t562c713d529be8c6@mail.gmail.com> 2008/9/17 Adam Jackson : > On Wed, 2008-09-17 at 20:36 +0200, Joshua C. wrote: > >> Dave can you make the radeon driver fall back to vesa in case of a >> problem? my display disappears after modprobe radeon modeset=1 and if >> the driver unloads itself, then maybe i can see any error messages on >> the display. > > Not really. There's no way to ask the display "hey, that mode I'm > sending you, does it work?" so it's sort of hard to programmatically > know when it doesn't work. > > - ajax > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > In theory i can tell the driver that "this mode isn't working for you" with a specific key e.g. pressing ctr+alt+n should tell the driver to unload itself. From murray.mcallister at gmail.com Wed Sep 17 22:14:48 2008 From: murray.mcallister at gmail.com (Murray McAllister) Date: Thu, 18 Sep 2008 08:14:48 +1000 Subject: hi In-Reply-To: <91157db90809170645y5491e529p2f36b151b2af21ad@mail.gmail.com> References: <91157db90809160855i3eaf4b3en5fcddbec7d8060f@mail.gmail.com> <48CFD813.8090206@redhat.com> <91157db90809170645y5491e529p2f36b151b2af21ad@mail.gmail.com> Message-ID: <95f1114b0809171514tdcb1dbfra683a0d4a35d049@mail.gmail.com> 2008/9/17 jude ui : > >>> >> >> >sup >> > nothing Did you invite everyone on the list to join gmail? From notting at redhat.com Wed Sep 17 18:16:52 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 17 Sep 2008 11:16:52 -0700 Subject: NetworkworkManger and network based filesystem /usr In-Reply-To: References: <48CAAF49.3090105@hhs.nl> <20080912181213.GA3270@nostromo.devel.redhat.com> <48CAB839.3000305@hhs.nl> <20080912185149.GA5197@nostromo.devel.redhat.com> <48CAC8E0.6030109@hhs.nl> Message-ID: <20080917181652.GA5285@nostromo.devel.redhat.com> Harald Hoyer (harald at redhat.com) said: > I think _we want_ to support /usr on netfs for all those universities, > companies, HPC clusters, etc.! Why is that better at all for the user or the admin than just a fully network /? Bill From rawhide at fedoraproject.org Wed Sep 17 22:44:12 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Wed, 17 Sep 2008 22:44:12 +0000 (UTC) Subject: rawhide report: 20080917 changes Message-ID: <20080917224412.87FB71F825C@releng2.fedora.phx.redhat.com> Removed package ksirk Updated Packages: mash-0.4.1-2.fc10 ----------------- * Tue Sep 16 18:00:00 2008 Jesse Keating - 0.4.1-2 - Rename 'rawhide' back to 'development' as we're not ready to make that name change on the mirror. * Mon Sep 15 18:00:00 2008 Bill Nottingham 0.4.1-1 - Adjust for new keys moto4lin-0.3-10.fc10 -------------------- * Wed Sep 17 18:00:00 2008 Rex Dieter - 0.3-10 - minor qt3 build tweak - move icon out of cvs, into sources * Tue Apr 8 18:00:00 2008 Rex Dieter - 0.3-9 - BR: qt3-devel (#434135) - License: GPLv2+ * Mon Apr 7 18:00:00 2008 Jesse Keating - 0.3-8 - Fix desktop file. * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 0.3-7 - Autorebuild for GCC 4.3 Summary: Added Packages: 0 Removed Packages: 1 Modified Packages: 2 Broken deps for i386 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.i386 requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.i386 requires librpm-4.4.so pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.i386 requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so sonata-1.5.2-1.fc10.i386 requires python-mpd Broken deps for x86_64 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.x86_64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.x86_64 requires librpmdb-4.4.so()(64bit) pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.x86_64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc requires librpmio-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpmdb-4.4.so perl-RPM2-0.67-5.fc9.ppc requires librpm-4.4.so pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.ppc requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so Broken deps for ppc64 ---------------------------------------------------------- eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave livecd-tools-018-1.fc10.ppc64 requires yaboot mediawiki-SpecialInterwiki-0-0.3.20080606svn.fc10.noarch requires mediawiki < 0:1.11 perl-RPM2-0.67-5.fc9.ppc64 requires librpmio-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpm-4.4.so()(64bit) perl-RPM2-0.67-5.fc9.ppc64 requires librpmdb-4.4.so()(64bit) perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.ppc64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) From mattdm at mattdm.org Wed Sep 17 23:35:03 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 17 Sep 2008 19:35:03 -0400 Subject: configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!) In-Reply-To: <1221666445.14439.4.camel@luminos.localdomain> References: <1221285235.3492.4.camel@fantail.jnet.net.nz> <1221301012.3152.7.camel@pc-notebook> <48CBABC4.5060005@leemhuis.info> <20080913120636.GA20878@jadzia.bu.edu> <1221310726.3076.46.camel@rosebud> <80d7e4090809141226g7fa6fcfdy4d670dcaf9289584@mail.gmail.com> <1221426597.25056.6.camel@rosebud> <20080917152342.GD4076@jadzia.bu.edu> <1221666445.14439.4.camel@luminos.localdomain> Message-ID: <20080917233503.GA24168@jadzia.bu.edu> On Wed, Sep 17, 2008 at 08:47:25AM -0700, Jesse Keating wrote: > Augeas ? /etc/sudoers.d/ ? It's not like we haven't solved the problem > of 'complicated and picky syntax' before... It could be done, but /etc/sudoers.d still might have odd interactions with the main file, and in any case it'd be a certain amount of work which might not get accepted upstream. Meanwhile, group approach works right now and requires a one character change to an existing config file. Developing a special sudoers.d directory also doesn't automatically work with userhelper/consolehelper -- which the group solution does. (And PolicyKit can work off group membership too, right?) -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs Computing & Information Technology Harvard School of Engineering & Applied Sciences From mw_triad at users.sourceforge.net Thu Sep 18 00:25:24 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 17 Sep 2008 19:25:24 -0500 Subject: Non-X text mode console In-Reply-To: <200809170255.m8H2tDU5010168@laptop14.inf.utfsm.cl> References: <20080915151812.0730561B48E@hormel.redhat.com> <48CEA6D3.90906@herr-schmitt.de> <200809170255.m8H2tDU5010168@laptop14.inf.utfsm.cl> Message-ID: Horst H. von Brand wrote: > Jochen Schmitt wrote: >> David A. Wheeler schrieb: >>> I think it's clear from this discussion here that many people DO >>> find non-X console mode useful, and thus, it shouldn't be removed: >>> Dominik 'Rathann' Mierzejewski: > >> I agree with you, that a release of Fedora without non-x mode console >> may be a disadvantage. > > Bzzt, wrong. > > Would make it next to useless for many applications. Huh? How does not removing something make Fedora "next to useless for many applications"? Or did you mean to agree with David and Jochen? -- Matthew Your eyes are weary from staring at the CRT. You feel sleepy. Notice how restful it is to watch the cursor blink. Close your eyes. The opinions stated above are yours. You cannot imagine why you ever felt otherwise. -- Unknown (found at http://goldmark.org/jeff/stupid-disclaimers/fun.html) From pemboa at gmail.com Thu Sep 18 02:15:44 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 17 Sep 2008 21:15:44 -0500 Subject: Non-X text mode console In-Reply-To: References: <20080915151812.0730561B48E@hormel.redhat.com> <48CEA6D3.90906@herr-schmitt.de> <200809170255.m8H2tDU5010168@laptop14.inf.utfsm.cl> Message-ID: <16de708d0809171915n729c75een986e1008c208524@mail.gmail.com> On Wed, Sep 17, 2008 at 7:25 PM, Matthew Woehlke wrote: > Horst H. von Brand wrote: >> >> Jochen Schmitt wrote: >>> >>> David A. Wheeler schrieb: >>>> >>>> I think it's clear from this discussion here that many people DO >>>> find non-X console mode useful, and thus, it shouldn't be removed: >>>> Dominik 'Rathann' Mierzejewski: >> >>> I agree with you, that a release of Fedora without non-x mode console >>> may be a disadvantage. >> >> Bzzt, wrong. >> >> Would make it next to useless for many applications. > > Huh? How does not removing something make Fedora "next to useless for many > applications"? Or did you mean to agree with David and Jochen? > He's agreeing with them, based on how I comprehended that. -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From seg at haxxed.com Thu Sep 18 02:29:42 2008 From: seg at haxxed.com (Callum Lerwick) Date: Wed, 17 Sep 2008 21:29:42 -0500 Subject: configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!) In-Reply-To: <20080917233503.GA24168@jadzia.bu.edu> References: <1221285235.3492.4.camel@fantail.jnet.net.nz> <1221301012.3152.7.camel@pc-notebook> <48CBABC4.5060005@leemhuis.info> <20080913120636.GA20878@jadzia.bu.edu> <1221310726.3076.46.camel@rosebud> <80d7e4090809141226g7fa6fcfdy4d670dcaf9289584@mail.gmail.com> <1221426597.25056.6.camel@rosebud> <20080917152342.GD4076@jadzia.bu.edu> <1221666445.14439.4.camel@luminos.localdomain> <20080917233503.GA24168@jadzia.bu.edu> Message-ID: <1221704982.8461.6.camel@localhost.localdomain> On Wed, 2008-09-17 at 19:35 -0400, Matthew Miller wrote: > It could be done, but /etc/sudoers.d still might have odd interactions with > the main file, and in any case it'd be a certain amount of work which might > not get accepted upstream. Meanwhile, group approach works right now and > requires a one character change to an existing config file. > > Developing a special sudoers.d directory also doesn't automatically work > with userhelper/consolehelper -- which the group solution does. (And > PolicyKit can work off group membership too, right?) Also, with a 'chgrp wheel /var/log/messages' and a 'chmod 640 /var/log/messages' you can solve the log reading problem too. Maybe we should consider making that default too... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mattdm at mattdm.org Thu Sep 18 04:02:11 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 18 Sep 2008 00:02:11 -0400 Subject: configuring sudo by default (was: Re: Today's (9/12) rawhide all users = unable to authenticate user!) In-Reply-To: <1221704982.8461.6.camel@localhost.localdomain> References: <1221301012.3152.7.camel@pc-notebook> <48CBABC4.5060005@leemhuis.info> <20080913120636.GA20878@jadzia.bu.edu> <1221310726.3076.46.camel@rosebud> <80d7e4090809141226g7fa6fcfdy4d670dcaf9289584@mail.gmail.com> <1221426597.25056.6.camel@rosebud> <20080917152342.GD4076@jadzia.bu.edu> <1221666445.14439.4.camel@luminos.localdomain> <20080917233503.GA24168@jadzia.bu.edu> <1221704982.8461.6.camel@localhost.localdomain> Message-ID: <20080918040211.GA22112@jadzia.bu.edu> On Wed, Sep 17, 2008 at 09:29:42PM -0500, Callum Lerwick wrote: > > Developing a special sudoers.d directory also doesn't automatically work > > with userhelper/consolehelper -- which the group solution does. (And > > PolicyKit can work off group membership too, right?) > Also, with a 'chgrp wheel /var/log/messages' and a 'chmod > 640 /var/log/messages' you can solve the log reading problem too. Maybe > we should consider making that default too... Heh. Also already the default in BU Linux. :) -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs Computing & Information Technology Harvard School of Engineering & Applied Sciences From fedora at shmuelhome.mine.nu Thu Sep 18 04:30:48 2008 From: fedora at shmuelhome.mine.nu (shmuel siegel) Date: Thu, 18 Sep 2008 07:30:48 +0300 Subject: modesetting feature status In-Reply-To: <1221683977.15981.223.camel@atropine.boston.devel.redhat.com> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221145599.11745.3.camel@aglarond.local> <1221152956.4345.17.camel@atropine.boston.devel.redhat.com> <1221155164.11745.13.camel@aglarond.local> <5f6f8c5f0809111209o1d28bae4p246d699f3520c40@mail.gmail.com> <1221174980.30676.10.camel@optimus> <5f6f8c5f0809120305y41ac861fq8a91d1547519a955@mail.gmail.com> <5f6f8c5f0809171136lb722a87taee2cbd5afc2ff29@mail.gmail.com> <1221683977.15981.223.camel@atropine.boston.devel.redhat.com> Message-ID: <48D1D978.7020102@shmuelhome.mine.nu> Adam Jackson wrote: > On Wed, 2008-09-17 at 20:36 +0200, Joshua C. wrote: > > >> Dave can you make the radeon driver fall back to vesa in case of a >> problem? my display disappears after modprobe radeon modeset=1 and if >> the driver unloads itself, then maybe i can see any error messages on >> the display. >> > > Not really. There's no way to ask the display "hey, that mode I'm > sending you, does it work?" so it's sort of hard to programmatically > know when it doesn't work. > > - ajax > But a keyboard shortcut that forces a change to the vesa driver would be very useful. From email.ahmedkamal at googlemail.com Thu Sep 18 07:36:56 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Thu, 18 Sep 2008 09:36:56 +0200 Subject: modesetting feature status In-Reply-To: <48D1D978.7020102@shmuelhome.mine.nu> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221145599.11745.3.camel@aglarond.local> <1221152956.4345.17.camel@atropine.boston.devel.redhat.com> <1221155164.11745.13.camel@aglarond.local> <5f6f8c5f0809111209o1d28bae4p246d699f3520c40@mail.gmail.com> <1221174980.30676.10.camel@optimus> <5f6f8c5f0809120305y41ac861fq8a91d1547519a955@mail.gmail.com> <5f6f8c5f0809171136lb722a87taee2cbd5afc2ff29@mail.gmail.com> <1221683977.15981.223.camel@atropine.boston.devel.redhat.com> <48D1D978.7020102@shmuelhome.mine.nu> Message-ID: <3da3b5b40809180036o33ad4e27h328ba1740bf03ade@mail.gmail.com> What about modesetting for proprietary nvidia users ? On Thu, Sep 18, 2008 at 6:30 AM, shmuel siegel wrote: > Adam Jackson wrote: > >> On Wed, 2008-09-17 at 20:36 +0200, Joshua C. wrote: >> >> >> >>> Dave can you make the radeon driver fall back to vesa in case of a >>> problem? my display disappears after modprobe radeon modeset=1 and if >>> the driver unloads itself, then maybe i can see any error messages on >>> the display. >>> >>> >> >> Not really. There's no way to ask the display "hey, that mode I'm >> sending you, does it work?" so it's sort of hard to programmatically >> know when it doesn't work. >> >> - ajax >> >> > But a keyboard shortcut that forces a change to the vesa driver would be > very useful. > > > -- > 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 Sep 18 07:45:16 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 18 Sep 2008 13:15:16 +0530 Subject: modesetting feature status In-Reply-To: <3da3b5b40809180036o33ad4e27h328ba1740bf03ade@mail.gmail.com> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221145599.11745.3.camel@aglarond.local> <1221152956.4345.17.camel@atropine.boston.devel.redhat.com> <1221155164.11745.13.camel@aglarond.local> <5f6f8c5f0809111209o1d28bae4p246d699f3520c40@mail.gmail.com> <1221174980.30676.10.camel@optimus> <5f6f8c5f0809120305y41ac861fq8a91d1547519a955@mail.gmail.com> <5f6f8c5f0809171136lb722a87taee2cbd5afc2ff29@mail.gmail.com> <1221683977.15981.223.camel@atropine.boston.devel.redhat.com> <48D1D978.7020102@shmuelhome.mine.nu> <3da3b5b40809180036o33ad4e27h328ba1740bf03ade@mail.gmail.com> Message-ID: <48D2070C.7010508@fedoraproject.org> Ahmed Kamal wrote: > What about modesetting for proprietary nvidia users ? Your question has half of the answer. Only Nvidia has the source code. Ask them. Rahul From kzak at redhat.com Thu Sep 18 09:06:47 2008 From: kzak at redhat.com (Karel Zak) Date: Thu, 18 Sep 2008 11:06:47 +0200 Subject: Loopback mounting the root filesystem using nash In-Reply-To: <1221686255.3685.64.camel@moss-terrapins.epoch.ncsc.mil> References: <1221686255.3685.64.camel@moss-terrapins.epoch.ncsc.mil> Message-ID: <20080918090647.GH28147@nb.net.home> On Wed, Sep 17, 2008 at 05:17:35PM -0400, David P. Quigley wrote: > I first tried to losetup the file onto /dev/loop0 but kept getting loop: > can't get info on device /dev/loop0: No such device or address. I > thought it was because I was missing the loop device so I created it > with mknod /dev/loop0 b 7 0 (as it is on my actual fedora box) but this be careful with loop minor numbers (F10 kernels): # ls -l /dev/loop?* brw-rw---- 1 root disk 7, 0 2008-03-05 14:55 /dev/loop0 brw-rw---- 1 root disk 7, 64 2008-03-05 14:55 /dev/loop1 brw-rw---- 1 root disk 7, 128 2008-03-05 14:55 /dev/loop2 > The next thing I tried was to not bother with this and just use the -o > loop option to mount but this fails with the error "mount: error > mounting /rootfs.img on /sysroot as ext3: Block device required" the nash does not duplicate all mount(8) functionality and it does not support "mount -o loop". You have to call "losetup /dev/loop0 file.img" before the mount. Karel -- Karel Zak From nicolas.mailhot at laposte.net Thu Sep 18 09:18:48 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 18 Sep 2008 11:18:48 +0200 (CEST) Subject: modesetting feature status In-Reply-To: <48D2070C.7010508@fedoraproject.org> References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221145599.11745.3.camel@aglarond.local> <1221152956.4345.17.camel@atropine.boston.devel.redhat.com> <1221155164.11745.13.camel@aglarond.local> <5f6f8c5f0809111209o1d28bae4p246d699f3520c40@mail.gmail.com> <1221174980.30676.10.camel@optimus> <5f6f8c5f0809120305y41ac861fq8a91d1547519a955@mail.gmail.com> <5f6f8c5f0809171136lb722a87taee2cbd5afc2ff29@mail.gmail.com> <1221683977.15981.223.camel@atropine.boston.devel.redhat.com> <48D1D978.7020102@shmuelhome.mine.nu> <3da3b5b40809180036o33ad4e27h328ba1740bf03ade@mail.gmail.com> <48D2070C.7010508@fedoraproject.org> Message-ID: Le Jeu 18 septembre 2008 09:45, Rahul Sundaram a ?crit : > > Ahmed Kamal wrote: >> What about modesetting for proprietary nvidia users ? > > Your question has half of the answer. Only Nvidia has the source code. > Ask them. That still leaves the question of nv and nouveau users open. -- Nicolas Mailhot From rawhide at fedoraproject.org Thu Sep 18 09:52:01 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Thu, 18 Sep 2008 09:52:01 +0000 (UTC) Subject: rawhide report: 20080918 changes Message-ID: <20080918095201.952E71F825D@releng2.fedora.phx.redhat.com> Removed package HelixPlayer Removed package perl-RPM2 Updated Packages: man-pages-fr-2.80.0-5.fc10 -------------------------- * Sat Sep 13 18:00:00 2008 Alain Portal 2.80.0-5 - Bump release * Sat Sep 6 18:00:00 2008 Alain Portal 2.80.0-3 - Remove pages provided by their upstream tarball Fix #455277 and #457663 mediawiki-SpecialInterwiki-0-0.4.20080913svn.fc10 ------------------------------------------------- * Sat Sep 13 18:00:00 2008 Nigel Jones - 0-0.4.20080913svn - Update to >= 1.12 version now that rawhide has an updated Mediawiki package Summary: Added Packages: 0 Removed Packages: 2 Modified Packages: 2 Broken deps for i386 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.i386 requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so Broken deps for x86_64 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.x86_64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.ppc requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so Broken deps for ppc64 ---------------------------------------------------------- eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave livecd-tools-018-1.fc10.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.ppc64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) From billcrawford1970 at gmail.com Thu Sep 18 11:53:52 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 18 Sep 2008 12:53:52 +0100 Subject: Non-X text mode console In-Reply-To: <200809161141.54386@rineau.tsetse> References: <20080915151812.0730561B48E@hormel.redhat.com> <200809161141.54386@rineau.tsetse> Message-ID: <200809181253.52601.billcrawford1970@gmail.com> On Tuesday 16 September 2008 10:41:54 Laurent Rineau wrote: > On Tuesday 16 September 2008 04:24:01 sean darcy wrote: > > So if I have a box set to runlevel 3 without any kernel parameters, > > what's on the monitor? Nothing? > > A framebuffer showing your usual text mode consoles. Do not worry, that > should not change anything for you (unless the default VGA mode is not > supported by your graphic card). It's not so much that, as the fb consoles tend to not support the nine-column vga text modes afaics? It's noticeably easier to read, at least for me ... > -- > Laurent Rineau > http://fedoraproject.org/wiki/LaurentRineau From billcrawford1970 at gmail.com Thu Sep 18 12:01:56 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 18 Sep 2008 13:01:56 +0100 Subject: New repo directories on http://download.fedora.redhat.com ??? In-Reply-To: <48CFA8D9.6030409@crc.dk> References: <5f6f8c5f0809151657s222ea376hc5af72e8a9b212a9@mail.gmail.com> <20080916122922.GA8409@auslistsprd01.us.dell.com> <48CFA8D9.6030409@crc.dk> Message-ID: <200809181301.57038.billcrawford1970@gmail.com> On Tuesday 16 September 2008 13:38:49 Mogens Kjaer wrote: > I always wished there were a trash folder system for rsync; > files deleted are moved to the trash folder, and before each > download a check is made to see if the file already exists in > the trash folder. This folder could then be purged at regular intervals. That would be the --backup, --backup-dir, --compare-dest, and --copy-dest (or --link-dest) options to rsync? From jwboyer at gmail.com Thu Sep 18 12:13:05 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 18 Sep 2008 08:13:05 -0400 Subject: FESCo Meeting Summary for 2008-09-17 Message-ID: <20080918121304.GA2697@yoda.jdub.homelinux.org> === Present === * Josh Boyer (jwb) * Kevin Fenzi (nirik) * Jarod Wilson (j-rod) * Jon Stanley (jds2001) * Dennis Gilmore (dgilmore) === Absent === * Brian Pepple (bpepple) * Bill Nottingham (notting) * David Woodhouse (dwmw2) * Karsten Hopp (kick_) == Summary == === Features === * FESCo approved the following features for F10: ** https://fedoraproject.org/wiki/Features/Red_Hat_Messaging ** https://fedoraproject.org/wiki/Features/GStreamer_dependencies_in_RPM *** There was a bit of discussion on the naming of Red Hat Messaging, however that is the actual project/product name and it wasn't enough of a concern to impact the Feature's acceptance. As an added note, the following Feature pages have not been updated. They need to be updated before Beta or they will be dropped as Features: ** https://fedoraproject.org/wiki/Features/BetterStartup ** https://fedoraproject.org/wiki/Features/EFI ** https://fedoraproject.org/wiki/Features/FirstAidKit ** https://fedoraproject.org/wiki/Features/GNOME2_24 ** https://fedoraproject.org/wiki/Features/GoodHaskellSupport ** https://fedoraproject.org/wiki/Features/HDTVEnhancements ** https://fedoraproject.org/wiki/Features/KernelModesetting ** https://fedoraproject.org/wiki/Features/OnlineAccountsService ** https://fedoraproject.org/wiki/Features/RPM4.6 ** https://fedoraproject.org/wiki/Features/SaveToBugzilla ** https://fedoraproject.org/wiki/Features/Sugar ** https://fedoraproject.org/wiki/Features/TimeZoneAndLocation === Sponsor Nominations === * FESCo approved Bernie Innocenti as a sponsor. Dennis Gilmore volunteered to guide Bernie in his sponsor activities as he comes up to speed. Congrats to Bernie and Thanks to Dennis. === MinGW === * The MinGW discussion was delayed until next week. This was at the request of Richard Jones, and also as a result of light attendance from the FESCo members due to the Linux Plumbers Conference or other unavoidable reasons. === 'make force-tag'/TAG_OPTS=-F === * nirik brought the force-tag/TAG_OPTS=-F discussion again in light of new information and further discussion on the lists. A proposal to add back 'make force-tag' was not approved due to lack of consensus (proposal #1). A second proposal to add back TAG_OPTS=-F was approved (proposal #2). Dennis Gilmore will add TAG_OPTS back to the makefile. ** Proposal #1 *** For: j-rod, nirik, jwb, jds2001 *** Against: dgilmore *** Absent: dwmw2, kick_, notting, bpepple ** Proposal #2 *** For: j-rod, nirik, jwb, jds2001, dgilmore (majority vote of FESCo) *** Absent: dwmw2, kick_, notting, bpepple === Codina === * There was a brief discussion on what the status of Codina was. FESCo would like to find out what the plan for Codina is and will revisit this next week. From jwboyer at gmail.com Thu Sep 18 12:22:03 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Thu, 18 Sep 2008 08:22:03 -0400 Subject: FESCo Meeting Summary for 2008-09-17 In-Reply-To: <20080918121304.GA2697@yoda.jdub.homelinux.org> References: <20080918121304.GA2697@yoda.jdub.homelinux.org> Message-ID: <20080918122203.GB2697@yoda.jdub.homelinux.org> I forgot to put that the IRC log can be found here: http://jwboyer.fedorapeople.org/fesco/FESCo-2008-09-17.html josh From u0103a at gmail.com Thu Sep 18 12:53:50 2008 From: u0103a at gmail.com (jude ui) Date: Thu, 18 Sep 2008 08:53:50 -0400 Subject: configuring sudo by default In-Reply-To: <48D12B5B.4010509@leemhuis.info> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <1221301012.3152.7.camel@pc-notebook> <48CBABC4.5060005@leemhuis.info> <20080913120636.GA20878@jadzia.bu.edu> <1221310726.3076.46.camel@rosebud> <80d7e4090809141226g7fa6fcfdy4d670dcaf9289584@mail.gmail.com> <1221426597.25056.6.camel@rosebud> <20080917152342.GD4076@jadzia.bu.edu> <1221666445.14439.4.camel@luminos.localdomain> <48D12B5B.4010509@leemhuis.info> Message-ID: <91157db90809180553n3deaef8bv9c352517d2cf33fc@mail.gmail.com> > On Wed, 2008-09-17 at 11:23 -0400, Matthew Miller wrote: >> >>> >The problem is that this is file has a ridiculously complicated and >>> picky >>> >syntax. I am really skeptical about machine-editing it. >> >> What do you mean machine edit it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From u0103a at gmail.com Thu Sep 18 12:58:36 2008 From: u0103a at gmail.com (jude ui) Date: Thu, 18 Sep 2008 08:58:36 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <48D137C2.3030801@fedoraproject.org> References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> Message-ID: <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> On 9/17/08, Rahul Sundaram wrote: > > jude ui wrote: > > Might want to take a look at >> >> http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html >> >> Rahul >> >> >> Why is there the source for firmware? >> > > >Sorry. I am not sure what that means. > > Rahul > > Thanks for the link - but it's debian-I thought we were talking about > Fedora here And to repharse my question - Can't you guys reselse the firmware as opensource - are they prosperity drivers? (correct me if I'm wrong) -------------- next part -------------- An HTML attachment was scrubbed... URL: From u0103a at gmail.com Thu Sep 18 13:23:14 2008 From: u0103a at gmail.com (jude ui) Date: Thu, 18 Sep 2008 09:23:14 -0400 Subject: hi In-Reply-To: <95f1114b0809171514tdcb1dbfra683a0d4a35d049@mail.gmail.com> References: <91157db90809160855i3eaf4b3en5fcddbec7d8060f@mail.gmail.com> <48CFD813.8090206@redhat.com> <91157db90809170645y5491e529p2f36b151b2af21ad@mail.gmail.com> <95f1114b0809171514tdcb1dbfra683a0d4a35d049@mail.gmail.com> Message-ID: <91157db90809180623j1e57112k52002948c8f34707@mail.gmail.com> On 9/17/08, Murray McAllister wrote: > > 2008/9/17 jude ui : > > > >>> > >> > >> >sup > >> > > nothing > > >Did you invite everyone on the list to join gmail? > > What are you talking about? -------------- next part -------------- An HTML attachment was scrubbed... URL: From opensource at till.name Thu Sep 18 13:35:05 2008 From: opensource at till.name (Till Maas) Date: Thu, 18 Sep 2008 15:35:05 +0200 Subject: FESCo Meeting Summary for 2008-09-17 In-Reply-To: <20080918121304.GA2697@yoda.jdub.homelinux.org> References: <20080918121304.GA2697@yoda.jdub.homelinux.org> Message-ID: <200809181535.19547.opensource@till.name> On Thu September 18 2008, Josh Boyer wrote: > === 'make force-tag'/TAG_OPTS=-F === > * nirik brought the force-tag/TAG_OPTS=-F discussion again in light of new > information and further discussion on the lists. A proposal to add back > 'make force-tag' was not approved due to lack of consensus (proposal #1). > A second proposal to add back TAG_OPTS=-F was approved (proposal #2). > Dennis Gilmore will add TAG_OPTS back to the makefile. Once TAG_OPTS can be used again, every maintainer who wants to maintain his packages a little bit more efficient can add these two lines to his ~/.cvspkgsrc file[1]: force-tag: $(SPECFILE) $(COMMON_DIR)/branches @$(MAKE) tag TAG_OPTS="-F $(TAG_OPTS)" The using make force-tag will be back again. Regards, Till [1] If it does not exist, you can just create it. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From green at redhat.com Thu Sep 18 13:44:38 2008 From: green at redhat.com (Anthony Green) Date: Thu, 18 Sep 2008 06:44:38 -0700 Subject: "make build" hanging Message-ID: <48D25B46.3020203@redhat.com> I probably missed something important that I was supposed to do after The Incident, because ever since then "make build" on my packages simply sits there hanging without any output. Any suggestions? AG From debarshi.ray at gmail.com Thu Sep 18 13:54:31 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Thu, 18 Sep 2008 19:24:31 +0530 Subject: hi In-Reply-To: <91157db90809180623j1e57112k52002948c8f34707@mail.gmail.com> References: <91157db90809160855i3eaf4b3en5fcddbec7d8060f@mail.gmail.com> <48CFD813.8090206@redhat.com> <91157db90809170645y5491e529p2f36b151b2af21ad@mail.gmail.com> <95f1114b0809171514tdcb1dbfra683a0d4a35d049@mail.gmail.com> <91157db90809180623j1e57112k52002948c8f34707@mail.gmail.com> Message-ID: <3170f42f0809180654o4c7f2cdfyf8eab07fd739704b@mail.gmail.com> >> What are you talking about? https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01637.html Regards, Debarshi From mattdm at mattdm.org Thu Sep 18 14:54:26 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 18 Sep 2008 10:54:26 -0400 Subject: configuring sudo by default In-Reply-To: <91157db90809180553n3deaef8bv9c352517d2cf33fc@mail.gmail.com> References: <1221301012.3152.7.camel@pc-notebook> <48CBABC4.5060005@leemhuis.info> <20080913120636.GA20878@jadzia.bu.edu> <1221310726.3076.46.camel@rosebud> <80d7e4090809141226g7fa6fcfdy4d670dcaf9289584@mail.gmail.com> <1221426597.25056.6.camel@rosebud> <20080917152342.GD4076@jadzia.bu.edu> <1221666445.14439.4.camel@luminos.localdomain> <48D12B5B.4010509@leemhuis.info> <91157db90809180553n3deaef8bv9c352517d2cf33fc@mail.gmail.com> Message-ID: <20080918145426.GA31944@jadzia.bu.edu> On Thu, Sep 18, 2008 at 08:53:50AM -0400, jude ui wrote: > >>> >The problem is that this is file has a ridiculously complicated and > >>> >picky syntax. I am really skeptical about machine-editing it. > What do you mean machine edit it? Having a program modify the file; it's not designed for that. -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs Computing & Information Technology Harvard School of Engineering & Applied Sciences From adi1981.2k5 at gmail.com Thu Sep 18 15:04:22 2008 From: adi1981.2k5 at gmail.com (Adrian P) Date: Thu, 18 Sep 2008 17:04:22 +0200 Subject: Fedora Security Tools spin In-Reply-To: <20080905002309.GN3726@x300> References: <48BE023A.70703@redhat.com> <48BE1F95.2090509@redhat.com> <20080903210044.GF3726@x300> <200809050052.49444.Adi1981.2k5@gmail.com> <20080905002309.GN3726@x300> Message-ID: 2008/9/5 Luke Macken > On Fri, Sep 05, 2008 at 12:52:49AM +0200, Adrian Pilchowiec wrote: > > On Wednesday 03 of September 2008 23:00:44 Luke Macken wrote: > > > On Wed, Sep 03, 2008 at 10:54:37AM +0530, Huzaifa Sidhpurwala wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA1 > > > > > > > > Todd Zullinger wrote: > > > > > Huzaifa Sidhpurwala wrote: > > > > >> I just came across a knoppix security tool live CD and thought it > > > > >> would be a good idea for a security tool fedora spin too. > > > > >> The tools are freely available at: > > > > >> > > > > >> http://knoppix-std.org/index.html > > > > >> and are all GPLed? > > > > >> > > > > >> Do you guys think this is a good idea, I am sure such a spin does > > > > >> not exists in Fedora yet. > > > > > > > > > > Do you mean something like Luke Macken put together? > > > > > > > > > > http://fedoraproject.org/wiki/LukeMacken/SecurityLiveCD > > > > > > > > Yeah but more tools and more bare bones, > > > > Perhaps i can assist Luke in this? > > > > > > Absolutely! > > > > > > I'm in the process of rebasing the kickstart against the latest livecd > > > base, and I will be pushing it through the New Spin Process soon. > > > > > > More tools? Yes. I want it to ship with every security tool in > Fedora. > > > If you know of any that are missing from the list, please let me know. > > > > > > > Maybe it would be good to add OpenVAS [1] (free fork of nessus) to the > spin ? > > I added OpenVAS to the WishList, thanks! > > https://fedoraproject.org/wiki/SecuritySpin#Wishlist > > luke > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Got few other tools to propose: Lynis [1] - Security and system auditing tool Nebula [2] Intrusion signature generator Unhide [3] tool for searching hidden processes SARA [4] Security Auditor's Research Assistant SiLK [5] Security analysis tool for network developed by CERT ArpON [6] Detects and blocks all ARP poisoning/spoofing attacks. Bh (Beholder) [7] IDS for wireless networks. Distack [8] Framework for attack detection which allows for an integration of various detection methods as lightweight modules. Ttyrpld [9] Multi-os kernel-level tty logger A lot of useful tools for this spin can be also found on Packetstorm [10] web page. It would be also great if there would be snort + mysql (or whatever db) + base (or acid, or whatever analysis tool for snort) integrated by default. [1] http://www.rootkit.nl/projects/lynis.html [2] http://nebula.mwcollect.org/ [3] http://www.security-projects.com/?Unhide [4] http://www-arc.com/sara/ [5] http://tools.netsa.cert.org/silk/ [6] http://arpon.sourceforge.net/ [7] http://www.beholderwireless.org/ [8] https://i72projekte.tm.uka.de/trac/Distack [9] http://ttyrpld.sourceforge.net/ [10] http://packetstorm.linuxsecurity.com/defense/unix/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Thu Sep 18 16:46:15 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 18 Sep 2008 10:46:15 -0600 Subject: Cannot do a pxeboot/network kickstart install with current rawhide Message-ID: <48D285D7.7070100@cora.nwra.com> I am unable to do a pxeboot/network kickstart install with current rawhide. See https://bugzilla.redhat.com/show_bug.cgi?id=462083 Now, I assume I must be one of the only people to see this or there would be more talk about this. I've been doing these kind of installs for years, but I've made stupid mistakes before. I'm downloading from download.fedora.redhat.com. md5sums i386 pxeboot images: d33ab838ba5c2dd84d3903e06aa13dd8 initrd.img 912ebd856285531259bfa85acb6cbcb5 vmlinuz Help? -- 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 fedora at leemhuis.info Thu Sep 18 16:58:27 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 18 Sep 2008 18:58:27 +0200 Subject: consequences when a feature gets dropped (Re: FESCo Meeting Summary for 2008-09-17) In-Reply-To: <20080918121304.GA2697@yoda.jdub.homelinux.org> References: <20080918121304.GA2697@yoda.jdub.homelinux.org> Message-ID: <48D288B3.1000209@leemhuis.info> On 18.09.2008 14:13, Josh Boyer wrote: > == Summary == > === Features === > [...] > As an added note, the following Feature pages have not been updated. They > need to be updated before Beta or they will be dropped as Features: > ** https://fedoraproject.org/wiki/Features/BetterStartup > ** https://fedoraproject.org/wiki/Features/EFI > ** https://fedoraproject.org/wiki/Features/FirstAidKit > ** https://fedoraproject.org/wiki/Features/GNOME2_24 > ** https://fedoraproject.org/wiki/Features/GoodHaskellSupport > ** https://fedoraproject.org/wiki/Features/HDTVEnhancements > ** https://fedoraproject.org/wiki/Features/KernelModesetting > ** https://fedoraproject.org/wiki/Features/OnlineAccountsService > ** https://fedoraproject.org/wiki/Features/RPM4.6 > ** https://fedoraproject.org/wiki/Features/SaveToBugzilla > ** https://fedoraproject.org/wiki/Features/Sugar > ** https://fedoraproject.org/wiki/Features/TimeZoneAndLocation What exactly are the consequences if a Feature "will be dropped"? It sounds a bit like a threat and as something bad. But is it really? What for example will happen if the owners of the feature GNOME2_24 don't update the page. Will rawhide switch back to Gnome 2.22? Won't Gnome 2.24 be mentioned at all in the release notes? Will it not get any QA? Will we stick to Gnome 2.24 in F11? Will Spot send his nijas (?)? CU knurd (?) http://fedoraproject.org/wiki/TomCallaway/Ninjas From jkeating at redhat.com Thu Sep 18 17:07:29 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 18 Sep 2008 10:07:29 -0700 Subject: consequences when a feature gets dropped (Re: FESCo Meeting Summary for 2008-09-17) In-Reply-To: <48D288B3.1000209@leemhuis.info> References: <20080918121304.GA2697@yoda.jdub.homelinux.org> <48D288B3.1000209@leemhuis.info> Message-ID: <1221757649.14439.38.camel@luminos.localdomain> On Thu, 2008-09-18 at 18:58 +0200, Thorsten Leemhuis wrote: > What exactly are the consequences if a Feature "will be dropped"? It > sounds a bit like a threat and as something bad. But is it really? > > What for example will happen if the owners of the feature GNOME2_24 > don't update the page. Will rawhide switch back to Gnome 2.22? Won't > Gnome 2.24 be mentioned at all in the release notes? Will it not get any > QA? Will we stick to Gnome 2.24 in F11? Will Spot send his nijas (?)? Depends on the feature and the date. Standard examples could be: * enact the contingency plan * go forward with the work, but don't advertise it as a feature in any announcements/press/releasenotes/etc.. * get an exception from FESCo to land the feature late It really varies from feature to feature and at what point the decision is to made to remove it from the feature list. It's a discussion/decision that FESCo needs to make with the feature owner. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From poelstra at redhat.com Thu Sep 18 17:18:19 2008 From: poelstra at redhat.com (zimbra) Date: Thu, 18 Sep 2008 10:18:19 -0700 Subject: consequences when a feature gets dropped (Re: FESCo Meeting Summary for 2008-09-17) In-Reply-To: <48D288B3.1000209@leemhuis.info> References: <20080918121304.GA2697@yoda.jdub.homelinux.org> <48D288B3.1000209@leemhuis.info> Message-ID: <48D28D5B.9020403@redhat.com> Thorsten Leemhuis said the following on 09/18/2008 09:58 AM Pacific Time: > On 18.09.2008 14:13, Josh Boyer wrote: >> == Summary == >> === Features === > > [...] >> As an added note, the following Feature pages have not been updated. >> They >> need to be updated before Beta or they will be dropped as Features: >> ** https://fedoraproject.org/wiki/Features/BetterStartup >> ** https://fedoraproject.org/wiki/Features/EFI >> ** https://fedoraproject.org/wiki/Features/FirstAidKit >> ** https://fedoraproject.org/wiki/Features/GNOME2_24 >> ** https://fedoraproject.org/wiki/Features/GoodHaskellSupport >> ** https://fedoraproject.org/wiki/Features/HDTVEnhancements >> ** https://fedoraproject.org/wiki/Features/KernelModesetting >> ** https://fedoraproject.org/wiki/Features/OnlineAccountsService >> ** https://fedoraproject.org/wiki/Features/RPM4.6 >> ** https://fedoraproject.org/wiki/Features/SaveToBugzilla >> ** https://fedoraproject.org/wiki/Features/Sugar >> ** https://fedoraproject.org/wiki/Features/TimeZoneAndLocation > > What exactly are the consequences if a Feature "will be dropped"? It > sounds a bit like a threat and as something bad. But is it really? https://fedoraproject.org/wiki/Features/Policy/Dropping Since the beginning of the feature process we have referred to it this way. To date this is best motivational technique we've been able to find to get people to update their feature pages. We'd gladly accept suggestion for something better :) "dropped" essentially means it won't be advertised as a key feature of the release on this page: https://fedoraproject.org/wiki/Releases/10/FeatureList No where does it say the package has to be removed from the distro if the proposed feature isn't completed in time. We had some examples in Fedora 9 where this was the case. > What for example will happen if the owners of the feature GNOME2_24 > don't update the page. Will rawhide switch back to Gnome 2.22? Won't > Gnome 2.24 be mentioned at all in the release notes? Will it not get any > QA? Will we stick to Gnome 2.24 in F11? Will Spot send his nijas (?)? > > CU > knurd > > (?) http://fedoraproject.org/wiki/TomCallaway/Ninjas > From jonrob at fedoraproject.org Thu Sep 18 17:02:22 2008 From: jonrob at fedoraproject.org (Jonathan Roberts) Date: Thu, 18 Sep 2008 18:02:22 +0100 Subject: Interested in Fedora on Smaller Machines? Message-ID: <507738ef0809181002lc539f6fma548d78a8dbab32c@mail.gmail.com> I'm a bit late to this thread, but.... Me and Yaakov Nemoy have packaged the Ubuntu netbook applications, such as the new launcher, window picker etc. They're now waiting for review to get into Fedora, and if anyone would like to help out here, that would be great! Bug numbers are below: https://bugzilla.redhat.com/show_bug.cgi?id=451768 https://bugzilla.redhat.com/show_bug.cgi?id=451771 https://bugzilla.redhat.com/show_bug.cgi?id=451772 https://bugzilla.redhat.com/show_bug.cgi?id=451773 https://bugzilla.redhat.com/show_bug.cgi?id=462736 Also, this evening I plan to work on creating a minimal spin with these packages on and configured to launch by default, as a first step towards creating a Fedora Netbook/Mini spin. I realise there are loads of different ways we could approach this, and I really like the idea of trying to do a similar spin with Sugar as the interface, but this is where I'm going to be focussing my attention for now. Can I suggest that if people are interested in starting a SIG wrt this, then we should arrange to have a meeting at some point in the near future? Jon From fedora at leemhuis.info Thu Sep 18 17:51:44 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 18 Sep 2008 19:51:44 +0200 Subject: consequences when a feature gets dropped (Re: FESCo Meeting Summary for 2008-09-17) In-Reply-To: <48D28D5B.9020403@redhat.com> References: <20080918121304.GA2697@yoda.jdub.homelinux.org> <48D288B3.1000209@leemhuis.info> <48D28D5B.9020403@redhat.com> Message-ID: <48D29530.3020608@leemhuis.info> On 18.09.2008 19:18, zimbra wrote: > Thorsten Leemhuis said the following on 09/18/2008 09:58 AM Pacific Time: >> On 18.09.2008 14:13, Josh Boyer wrote: >>> == Summary == >>> === Features === >> > [...] >>> As an added note, the following Feature pages have not been updated. >>> They >>> need to be updated before Beta or they will be dropped as Features: >>> ** https://fedoraproject.org/wiki/Features/BetterStartup >>> ** https://fedoraproject.org/wiki/Features/EFI >>> ** https://fedoraproject.org/wiki/Features/FirstAidKit >>> ** https://fedoraproject.org/wiki/Features/GNOME2_24 >>> ** https://fedoraproject.org/wiki/Features/GoodHaskellSupport >>> ** https://fedoraproject.org/wiki/Features/HDTVEnhancements >>> ** https://fedoraproject.org/wiki/Features/KernelModesetting >>> ** https://fedoraproject.org/wiki/Features/OnlineAccountsService >>> ** https://fedoraproject.org/wiki/Features/RPM4.6 >>> ** https://fedoraproject.org/wiki/Features/SaveToBugzilla >>> ** https://fedoraproject.org/wiki/Features/Sugar >>> ** https://fedoraproject.org/wiki/Features/TimeZoneAndLocation >> What exactly are the consequences if a Feature "will be dropped"? It >> sounds a bit like a threat and as something bad. But is it really? > > https://fedoraproject.org/wiki/Features/Policy/Dropping thx for the pointer > Since the beginning of the feature process we have referred to it this > way. To date this is best motivational technique we've been able to > find to get people to update their feature pages. We'd gladly accept > suggestion for something better :) > > "dropped" essentially means it won't be advertised as a key feature of > the release on this page: > https://fedoraproject.org/wiki/Releases/10/FeatureList Well, that logic does work much for me. If I'd be a *lazy* fedora contributor (and I'm sure we have some of those then work on middle-sized or big features) then I'd just do my work and simply ignore the whole feature process right from the start (or at this point) to avoid the bureaucracy that it brings. Sure, my Feature then might not get mentioned in the FeatureList -- but a lazy packager might not think about that at all or just say "that's mainly Fedora's problem, not mine". But if that scheme works for you guys then I won't ask more stupid questions, especially as I normally don't have to deal with the Feature process much :-) . But I have one final question (hopefully not that stupid): Is anybody doing checks for "new features" (as i features, not as in feature process) that (for example) should get mentioned in the release notes and checked during QA, but don't have a Feature page (yet)? Take for example KDE 4.1, which afaics has no Feature page (correct me if I'm wrong, I could not find one), but at least should get mentioned in the realease notes properly. > [...] CU knurd From kevin.kofler at chello.at Thu Sep 18 18:04:03 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 18 Sep 2008 18:04:03 +0000 (UTC) Subject: consequences when a feature gets dropped (Re: FESCo Meeting Summary for 2008-09-17) References: <20080918121304.GA2697@yoda.jdub.homelinux.org> <48D288B3.1000209@leemhuis.info> <48D28D5B.9020403@redhat.com> <48D29530.3020608@leemhuis.info> Message-ID: Thorsten Leemhuis leemhuis.info> writes: > and checked during QA, but don't have a Feature page (yet)? Take for > example KDE 4.1, which afaics has no Feature page (correct me if I'm > wrong, I could not find one), but at least should get mentioned in the > realease notes properly. We don't consider KDE 4.1 a big enough change to deserve a full-blown feature page, also considering that most of it (everything except kdepim 4 and the KDE4 libkipi framework in kdegraphics) also got pushed as an F9 update. We will, however, make sure the release notes get updated for KDE 4.1 / F10, this was brought up on this week's KDE SIG meeting and jreznik volunteered. (I'll be helping him if needed. All the KDE release notes for F9 were written by me.) Kevin Kofler From lmacken at redhat.com Thu Sep 18 18:14:39 2008 From: lmacken at redhat.com (Luke Macken) Date: Thu, 18 Sep 2008 14:14:39 -0400 Subject: where's gimp-2.4.7 for F9 ? In-Reply-To: <1221593179.18327.806.camel@beck.corsepiu.local> References: <20080916181557.GD6117@x300.bos.redhat.com> <1221593179.18327.806.camel@beck.corsepiu.local> Message-ID: <20080918181439.GG6117@x300.bos.redhat.com> On Tue, Sep 16, 2008 at 09:26:19PM +0200, Ralf Corsepius wrote: > On Tue, 2008-09-16 at 14:15 -0400, Luke Macken wrote: > > On Tue, Sep 16, 2008 at 05:40:21PM +0000, Jack Tanner wrote: > > > koji says it's in updates-testing, and so does bodhi. I don't see it in either > > > updates-testing or in updates. Where'd it go? > > > > The repos are syncing out the master mirror now. This version of gimp > > is present in the f9-updates-testing repo. > f9-updates-testing or f9-updates-testing.newkey? f9-updates-testing.newkey From fedora at leemhuis.info Thu Sep 18 18:25:14 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 18 Sep 2008 20:25:14 +0200 Subject: consequences when a feature gets dropped (Re: FESCo Meeting Summary for 2008-09-17) In-Reply-To: References: <20080918121304.GA2697@yoda.jdub.homelinux.org> <48D288B3.1000209@leemhuis.info> <48D28D5B.9020403@redhat.com> <48D29530.3020608@leemhuis.info> Message-ID: <48D29D0A.9020908@leemhuis.info> On 18.09.2008 20:04, Kevin Kofler wrote: > Thorsten Leemhuis leemhuis.info> writes: >> and checked during QA, but don't have a Feature page (yet)? Take for >> example KDE 4.1, which afaics has no Feature page (correct me if I'm >> wrong, I could not find one), but at least should get mentioned in the >> realease notes properly. > > We don't consider KDE 4.1 a big enough change to deserve a full-blown feature > page, also considering that most of it (everything except kdepim 4 and the KDE4 > libkipi framework in kdegraphics) also got pushed as an F9 update. > > We will, however, make sure the release notes get updated for KDE 4.1 / F10, > this was brought up on this week's KDE SIG meeting and jreznik volunteered. > (I'll be helping him if needed. All the KDE release notes for F9 were written > by me.) As mentioned, KDE was just an example. Or IOW: I'm wondering what new Features we might have no FeaturePage, but are nevertheless worth mentioning in the release notes or should get testing during QA. Cu knurd From jkeating at redhat.com Thu Sep 18 18:53:13 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 18 Sep 2008 11:53:13 -0700 Subject: consequences when a feature gets dropped (Re: FESCo Meeting Summary for 2008-09-17) In-Reply-To: <48D29D0A.9020908@leemhuis.info> References: <20080918121304.GA2697@yoda.jdub.homelinux.org> <48D288B3.1000209@leemhuis.info> <48D28D5B.9020403@redhat.com> <48D29530.3020608@leemhuis.info> <48D29D0A.9020908@leemhuis.info> Message-ID: <1221763993.14439.40.camel@luminos.localdomain> On Thu, 2008-09-18 at 20:25 +0200, Thorsten Leemhuis wrote: > As mentioned, KDE was just an example. > > Or IOW: I'm wondering what new Features we might have no FeaturePage, > but are nevertheless worth mentioning in the release notes or should get > testing during QA. Magic 8-ball says?? Seriously, this is a serve yourself kind of deal here. If you want your software tested and lauded, you need to bring it to people's attention. The amount of churn in Fedora in a daily basis is huge, and trying to extrapolate feature type information from the builds is no easy task. If you wished to create some group of people who tried to do this, I wouldn't stop you, in fact I'd welcome it. There just isn't anybody doing it right now. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mmcgrath at redhat.com Thu Sep 18 19:41:16 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Thu, 18 Sep 2008 14:41:16 -0500 (CDT) Subject: consequences when a feature gets dropped (Re: FESCo Meeting Summary for 2008-09-17) In-Reply-To: <48D288B3.1000209@leemhuis.info> References: <20080918121304.GA2697@yoda.jdub.homelinux.org> <48D288B3.1000209@leemhuis.info> Message-ID: On Thu, 18 Sep 2008, Thorsten Leemhuis wrote: > On 18.09.2008 14:13, Josh Boyer wrote: > > == Summary == > > === Features === > > [...] > > As an added note, the following Feature pages have not been updated. They > > need to be updated before Beta or they will be dropped as Features: > > ** https://fedoraproject.org/wiki/Features/BetterStartup > > ** https://fedoraproject.org/wiki/Features/EFI > > ** https://fedoraproject.org/wiki/Features/FirstAidKit > > ** https://fedoraproject.org/wiki/Features/GNOME2_24 > > ** https://fedoraproject.org/wiki/Features/GoodHaskellSupport > > ** https://fedoraproject.org/wiki/Features/HDTVEnhancements > > ** https://fedoraproject.org/wiki/Features/KernelModesetting > > ** https://fedoraproject.org/wiki/Features/OnlineAccountsService > > ** https://fedoraproject.org/wiki/Features/RPM4.6 > > ** https://fedoraproject.org/wiki/Features/SaveToBugzilla > > ** https://fedoraproject.org/wiki/Features/Sugar > > ** https://fedoraproject.org/wiki/Features/TimeZoneAndLocation > > What exactly are the consequences if a Feature "will be dropped"? It sounds a > bit like a threat and as something bad. But is it really? > I didn't really see it as a threat but a way for people to know they are accountable when they put a feature up there and it doesn't get done. I suspect this is aimed at people who assume their feature will get in and don't do the work or make the deadlines. -Mike From ssorce at redhat.com Thu Sep 18 20:29:55 2008 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 18 Sep 2008 16:29:55 -0400 Subject: The state of resolv.conf In-Reply-To: <48D1062F.5010102@gmail.com> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221557672.19134.15.camel@gibraltar.str.redhat.com> <48CF84F5.3010701@city-fan.org> <1221563959.19134.43.camel@gibraltar.str.redhat.com> <1221623405.23132.2.camel@localhost.localdomain> <1221657007.12851.78.camel@localhost.localdomain> <48D1062F.5010102@gmail.com> Message-ID: <1221769795.21330.16.camel@localhost.localdomain> On Wed, 2008-09-17 at 08:29 -0500, Les Mikesell wrote: > Simo Sorce wrote: > > > > >> So the answer seems to be that glibc will not change it's simple > >> internal resolver (which has more limitations than just noticing > >> resolv.conf changes), but the recommendation is that lwresd or a local > >> caching nameserver be used for more complex DNS setups. > > > > A caching nameserver that can be instructed what to do when conditions > > change is what we really need. > > Isn't it a little late to redesign the internet so names and addressing > aren't delegated hierarchically? What would this mean ? But let me ask a question in your own style: do you understand the difference between a normal DNS server and a local cache ? Simo. -- Simo Sorce * Red Hat, Inc * New York From jkeating at redhat.com Thu Sep 18 20:43:30 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 18 Sep 2008 13:43:30 -0700 Subject: Planned power outage in Raleigh, NC and the release date of beta Message-ID: <1221770610.14439.51.camel@luminos.localdomain> Yesterday I became aware of a planned 24+ hour power outage of Red Hat's Raleigh HQ offices. Normally this wouldn't have much impact at all upon Fedora, however our primary Internet2 mirror seed is located there, and our ability to get Fedora 10 Beta properly staged to our mirrors will be severely diminished. As such, I propose that we delay the release of Fedora 10 Beta from Tuesday Sept 23 to Thursday Sept 25. This should give us enough days clear of the outage to properly stage the Beta bits for our release. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From forum at hubbitus.com.ru Thu Sep 18 22:01:22 2008 From: forum at hubbitus.com.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Fri, 19 Sep 2008 02:01:22 +0400 Subject: hi In-Reply-To: <3170f42f0809180654o4c7f2cdfyf8eab07fd739704b@mail.gmail.com> References: <91157db90809160855i3eaf4b3en5fcddbec7d8060f@mail.gmail.com> <48CFD813.8090206@redhat.com> <91157db90809170645y5491e529p2f36b151b2af21ad@mail.gmail.com> <95f1114b0809171514tdcb1dbfra683a0d4a35d049@mail.gmail.com> <91157db90809180623j1e57112k52002948c8f34707@mail.gmail.com> <3170f42f0809180654o4c7f2cdfyf8eab07fd739704b@mail.gmail.com> Message-ID: <48D2CFB2.9090306@ru.bir.ru> Debarshi Ray wrote: >>> What are you talking about? >>> > > https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01637.html > > Regards, > Debarshi > > Heh, furthermore with very outdated invitation with offer only 2.7Gb :) From lesmikesell at gmail.com Thu Sep 18 22:59:13 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 18 Sep 2008 17:59:13 -0500 Subject: The state of resolv.conf In-Reply-To: <1221769795.21330.16.camel@localhost.localdomain> References: <3da3b5b40809141720u2054aba4l43e037c8a7cdac6b@mail.gmail.com> <1221450093.27102.7.camel@localhost.localdomain> <3da3b5b40809150032r7fbb77far41c914d14cbd5ebd@mail.gmail.com> <1221482647.15427.10.camel@localhost.localdomain> <1221557672.19134.15.camel@gibraltar.str.redhat.com> <48CF84F5.3010701@city-fan.org> <1221563959.19134.43.camel@gibraltar.str.redhat.com> <1221623405.23132.2.camel@localhost.localdomain> <1221657007.12851.78.camel@localhost.localdomain> <48D1062F.5010102@gmail.com> <1221769795.21330.16.camel@localhost.localdomain> Message-ID: <48D2DD41.7020606@gmail.com> Simo Sorce wrote: > >>>> So the answer seems to be that glibc will not change it's simple >>>> internal resolver (which has more limitations than just noticing >>>> resolv.conf changes), but the recommendation is that lwresd or a local >>>> caching nameserver be used for more complex DNS setups. >>> A caching nameserver that can be instructed what to do when conditions >>> change is what we really need. >> Isn't it a little late to redesign the internet so names and addressing >> aren't delegated hierarchically? > > What would this mean ? What it would mean is that could have duplication of names and addresses and different nameservers give different results on purpose. This happens with private lans with private addresses and non-registered domains and you can sort-of deal with it as long as the private space you see is all coordinated and has no overlap with the public. > But let me ask a question in your own style: do you understand the > difference between a normal DNS server and a local cache ? I'm not sure what you mean by the question. It is very normal for any DNS server to also be a local cache. The issue here is about 'when conditions change', which in the context of public DNS is basically never - that is, any resolver anywhere will give the same result unless you go out of your way to localize it. I think what we were talking about are situations where you have one or more private LAN segments with their own private name servers (that can probably also resolve public DNS) and your machine is a roaming laptop or you arbitrarily make and break VPN connections among the private segments. In the simple roaming case you would let DHCP give you DNS servers that are primary or secondary for their private space as well as public resolvers. In the more complicated setup, you can configure named to use different forwarders for different private zones. You won't be able to resolve names if your VPN to a forwarder is down, but you wouldn't be able to connect there anyway so it's not a big loss. -- Les Mikesell lesmikesell at gmail.com From notting at redhat.com Fri Sep 19 00:41:12 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 18 Sep 2008 17:41:12 -0700 Subject: No more MAKEDEV? Message-ID: <20080919004112.GB8478@nostromo.devel.redhat.com> Looking at some of the inefficiencies in bootup (in regards to the 5 second Fedora boot), we came across MAKEDEV. To be short - it's a pig. The only user of it in Fedora is udev, which uses it for entries in /etc/udev/makedev.d. However, there's an already-upstream solution of putting device nodes in /lib/udev/devices. Why not just use this, remove MAKEDEV, simplify start_udev, and boot faster? Bill From dennis at ausil.us Fri Sep 19 01:11:51 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 18 Sep 2008 20:11:51 -0500 Subject: No more MAKEDEV? In-Reply-To: <20080919004112.GB8478@nostromo.devel.redhat.com> References: <20080919004112.GB8478@nostromo.devel.redhat.com> Message-ID: <200809182011.52358.dennis@ausil.us> On Thursday 18 September 2008 07:41:12 pm Bill Nottingham wrote: > Looking at some of the inefficiencies in bootup (in regards to the 5 > second Fedora boot), we came across MAKEDEV. To be short - it's a pig. > > The only user of it in Fedora is udev, which uses it for entries in > /etc/udev/makedev.d. However, there's an already-upstream solution > of putting device nodes in /lib/udev/devices. Why not just use this, > remove MAKEDEV, simplify start_udev, and boot faster? Please Dennis From ivazqueznet at gmail.com Fri Sep 19 01:28:34 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Thu, 18 Sep 2008 21:28:34 -0400 Subject: No more MAKEDEV? In-Reply-To: <20080919004112.GB8478@nostromo.devel.redhat.com> References: <20080919004112.GB8478@nostromo.devel.redhat.com> Message-ID: <1221787714.3433.5.camel@ignacio.lan> On Thu, 2008-09-18 at 17:41 -0700, Bill Nottingham wrote: > The only user of it in Fedora is udev... tpb as well. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ndbecker2 at gmail.com Fri Sep 19 01:34:02 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 18 Sep 2008 21:34:02 -0400 Subject: koji error (certificate revoked) Message-ID: I'm sure I went through the process a few weeks back, I have a ~/.fedora.cert dated 8/24/08 and ~/.fedora-server-ca.cert dated 8/20/08 and ~/.fedora-uploaded-ca.cert 8/20/08. I just tried to do make tag build and got: /usr/bin/koji build dist-f10 'cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/igraph/devel#igraph-0_5-14_fc10' Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert certificate revoked'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl handshake failure')] What do I need to do? From mattdm at mattdm.org Fri Sep 19 02:36:06 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 18 Sep 2008 22:36:06 -0400 Subject: No more MAKEDEV? In-Reply-To: <1221787714.3433.5.camel@ignacio.lan> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221787714.3433.5.camel@ignacio.lan> Message-ID: <20080919023606.GA32189@jadzia.bu.edu> On Thu, Sep 18, 2008 at 09:28:34PM -0400, Ignacio Vazquez-Abrams wrote: > > The only user of it in Fedora is udev... > tpb as well. It doesn't look like it would need to -- that's just in the specfile and not in the package itself. -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs Computing & Information Technology Harvard School of Engineering & Applied Sciences From dwheeler at dwheeler.com Fri Sep 19 02:56:45 2008 From: dwheeler at dwheeler.com (David A. Wheeler) Date: Thu, 18 Sep 2008 22:56:45 -0400 (EDT) Subject: No more MAKEDEV? In-Reply-To: <20080919011234.D974B619C5D@hormel.redhat.com> References: <20080919011234.D974B619C5D@hormel.redhat.com> Message-ID: > On Thursday 18 September 2008 07:41:12 pm Bill Nottingham wrote: > > there's an already-upstream solution > > of putting device nodes in /lib/udev/devices. Why not just use this, > > remove MAKEDEV, simplify start_udev, and boot faster? Please don't _remove_ MAKEDEV. I believe the FHS requires the existence of MAKEDEV, anyway; see: http://www.pathname.com/fhs/pub/fhs-2.3.html#DEVDEVICEFILES There are a lot of reasons to manually create a device in /dev. Nothing requires that the _initial_ boot use MAKEDEV, though. If the upstream solution works and is really sound, you could use it, and leave MAKEDEV around as a "manual override" switch. Has this gotten enough testing, though? A post-freeze change in fundamental boot methods might leave systems unbootable. --- David A. Wheeler From a.badger at gmail.com Fri Sep 19 03:32:13 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Thu, 18 Sep 2008 20:32:13 -0700 Subject: koji error (certificate revoked) In-Reply-To: References: Message-ID: <48D31D3D.9090405@gmail.com> Neal Becker wrote: > I'm sure I went through the process a few weeks back, I have a ~/.fedora.cert dated 8/24/08 and ~/.fedora-server-ca.cert dated 8/20/08 and > ~/.fedora-uploaded-ca.cert 8/20/08. > > I just tried to do make tag build and got: > > /usr/bin/koji build dist-f10 'cvs://cvs.fedoraproject.org/cvs/pkgs?rpms/igraph/devel#igraph-0_5-14_fc10' > Error: [('SSL routines', 'SSL3_READ_BYTES', 'sslv3 alert certificate revoked'), ('SSL routines', 'SSL3_WRITE_BYTES', 'ssl handshake failure')] > > What do I need to do? > revoked means that you've downloaded two certificates from the account system and the first one is what's in your ~/.fedora.cert file. The account system (since the intrusion last month) revokes old certificates when you get a new one so that you can only have a single valid certificate at a time. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From skvidal at fedoraproject.org Fri Sep 19 04:29:46 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 19 Sep 2008 00:29:46 -0400 Subject: system-autodeath Message-ID: <1221798586.3057.26.camel@rosebud> A while back I mentioned a system-autodeath idea for fedora. For some reason I had neglected it but this evening I put it together. If you take a look it is utterly trivial and just uses cron to kill the default route. I'm sure there are limitless ways this will not be perfect but I think it will probably be good enough. http://skvidal.fedorapeople.org/system-autodeath/ If you can come up with any way it is broken, let me know, otherwise I'll probably submit it for review. Thanks, -sv -- I only speak for me. From debarshi.ray at gmail.com Fri Sep 19 04:33:35 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Fri, 19 Sep 2008 10:03:35 +0530 Subject: LDTP and Pystatgrab In-Reply-To: <3170f42f0809131307s42581281qc710bd2e7fd8eb8b@mail.gmail.com> References: <3170f42f0809131307s42581281qc710bd2e7fd8eb8b@mail.gmail.com> Message-ID: <3170f42f0809182133r34f998ddx45fb1fd9d7d352e4@mail.gmail.com> > Just to avoid stepping onto someone's toes, I am working on packaging > LDTP [1] and its dependency Pystatgrab [2]. Will keep you posted. Done. + ldtp - Desktop testing framework: https://bugzilla.redhat.com/462813 + python-statgrab - Python bindings for libstatgrab: https://bugzilla.redhat.com/462279 Happy hacking, Debarshi From rc040203 at freenet.de Fri Sep 19 05:19:10 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 19 Sep 2008 07:19:10 +0200 Subject: where's gimp-2.4.7 for F9 ? In-Reply-To: <20080918181439.GG6117@x300.bos.redhat.com> References: <20080916181557.GD6117@x300.bos.redhat.com> <1221593179.18327.806.camel@beck.corsepiu.local> <20080918181439.GG6117@x300.bos.redhat.com> Message-ID: <1221801550.18327.1114.camel@beck.corsepiu.local> On Thu, 2008-09-18 at 14:14 -0400, Luke Macken wrote: > On Tue, Sep 16, 2008 at 09:26:19PM +0200, Ralf Corsepius wrote: > > On Tue, 2008-09-16 at 14:15 -0400, Luke Macken wrote: > > > On Tue, Sep 16, 2008 at 05:40:21PM +0000, Jack Tanner wrote: > > > > koji says it's in updates-testing, and so does bodhi. I don't see it in either > > > > updates-testing or in updates. Where'd it go? > > > > > > The repos are syncing out the master mirror now. This version of gimp > > > is present in the f9-updates-testing repo. > > f9-updates-testing or f9-updates-testing.newkey? > > f9-updates-testing.newkey Hmm, http://download.fedoraproject.org/pub/fedora/linux/updates/testing/$releasever/$basearch.newkey as in fedora-release-9-5.transition.noarch's /etc/yum.repos.d/fedora-updates-testing-newkey.repo doesn't exist. Ralf From poelstra at redhat.com Fri Sep 19 05:45:07 2008 From: poelstra at redhat.com (John Poelstra) Date: Thu, 18 Sep 2008 22:45:07 -0700 Subject: consequences when a feature gets dropped (Re: FESCo Meeting Summary for 2008-09-17) In-Reply-To: <48D29530.3020608@leemhuis.info> References: <20080918121304.GA2697@yoda.jdub.homelinux.org> <48D288B3.1000209@leemhuis.info> <48D28D5B.9020403@redhat.com> <48D29530.3020608@leemhuis.info> Message-ID: <48D33C63.4020902@redhat.com> Thorsten Leemhuis said the following on 09/18/2008 10:51 AM Pacific Time: > Well, that logic does work much for me. If I'd be a *lazy* fedora > contributor (and I'm sure we have some of those then work on > middle-sized or big features) then I'd just do my work and simply ignore > the whole feature process right from the start (or at this point) to > avoid the bureaucracy that it brings. Sure, my Feature then might not > get mentioned in the FeatureList -- but a lazy packager might not think > about that at all or just say "that's mainly Fedora's problem, not mine". Having the right level of accountability and motivation around the feature process has been the unsolved riddle for me since we started it. If you can suggest and help me implement the alternative we will have taken Fedora to the next level! I ask myself this every time we try to fine tune the feature process to make it better. Way back when there was no formal process around features or what was new in a release. There also seemed to be limited visibility into areas Fedora was innovating in. I guess we are working under the assumption that all of us want Fedora to be good and to be recognized for what we do even if that means "bureaucracy" (which I believe is overstating how hard it is). I can't think of any thriving communities or projects that have succeeded because most of the members thought it was "someone else's problem". Without waxing too philosophical, it is really OUR problem if WE want to make Fedora a good and better distro. > But if that scheme works for you guys then I won't ask more stupid > questions, especially as I normally don't have to deal with the Feature > process much :-) . > > But I have one final question (hopefully not that stupid): Is anybody > doing checks for "new features" (as i features, not as in feature > process) that (for example) should get mentioned in the release notes > and checked during QA, but don't have a Feature page (yet)? Take for > example KDE 4.1, which afaics has no Feature page (correct me if I'm > wrong, I could not find one), but at least should get mentioned in the > realease notes properly. As I said above, I think it is up to all of us and the different oversight committees to make sure everything is covered. How can we know about the things that we don't know about if nobody tells us? ;-) Or as the great philosopher Donald Rumsfeld is quoted as saying here http://politicalhumor.about.com/cs/quotethis/a/rumsfeldquotes.htm "...We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns -- the ones we don't know we don't know." John From jkeating at redhat.com Fri Sep 19 06:03:34 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 18 Sep 2008 23:03:34 -0700 Subject: where's gimp-2.4.7 for F9 ? In-Reply-To: <1221801550.18327.1114.camel@beck.corsepiu.local> References: <20080916181557.GD6117@x300.bos.redhat.com> <1221593179.18327.806.camel@beck.corsepiu.local> <20080918181439.GG6117@x300.bos.redhat.com> <1221801550.18327.1114.camel@beck.corsepiu.local> Message-ID: <1221804214.14439.61.camel@luminos.localdomain> On Fri, 2008-09-19 at 07:19 +0200, Ralf Corsepius wrote: > > Hmm, > > http://download.fedoraproject.org/pub/fedora/linux/updates/testing/$releasever/$basearch.newkey > > as in fedora-release-9-5.transition.noarch's > > /etc/yum.repos.d/fedora-updates-testing-newkey.repo > > doesn't exist. There was a snafu the other day with rsync which led to a period of time where those files weren't there. We've fixed the issue that day, and those dirs have been there since. Perhaps you're looking at a stale mirror? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rc040203 at freenet.de Fri Sep 19 07:40:26 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 19 Sep 2008 09:40:26 +0200 Subject: where's gimp-2.4.7 for F9 ? In-Reply-To: <1221804214.14439.61.camel@luminos.localdomain> References: <20080916181557.GD6117@x300.bos.redhat.com> <1221593179.18327.806.camel@beck.corsepiu.local> <20080918181439.GG6117@x300.bos.redhat.com> <1221801550.18327.1114.camel@beck.corsepiu.local> <1221804214.14439.61.camel@luminos.localdomain> Message-ID: <1221810026.18327.1128.camel@beck.corsepiu.local> On Thu, 2008-09-18 at 23:03 -0700, Jesse Keating wrote: > On Fri, 2008-09-19 at 07:19 +0200, Ralf Corsepius wrote: > > > > Hmm, > > > > http://download.fedoraproject.org/pub/fedora/linux/updates/testing/$releasever/$basearch.newkey > > > > as in fedora-release-9-5.transition.noarch's > > > > /etc/yum.repos.d/fedora-updates-testing-newkey.repo > > > > doesn't exist. > > There was a snafu the other day with rsync which led to a period of time > where those files weren't there. We've fixed the issue that day, and > those dirs have been there since. Perhaps you're looking at a stale > mirror? Well, I actually was looking at http://download.fedoraproject.org/pub/fedora/linux/updates/testing/9 at the time when writing the mail above. Now, I see the *.newkey repos, but they had not been there when writing the email. Do you have some redirection active? This would explain other weirdnesses I have been experiencing throughout the last couple of days. Ralf From valent.turkovic at gmail.com Fri Sep 19 08:52:24 2008 From: valent.turkovic at gmail.com (Valent Turkovic) Date: Fri, 19 Sep 2008 10:52:24 +0200 Subject: Xbmc on Fedora? (fabulous mediacenter application) Message-ID: <64b14b300809190152o2c1ee6b4ka0a22b7cd82fd208@mail.gmail.com> http://xbmc.org/ The multiplatform version of XboxMediaCenter is out, but there are only instuctions how to install it on Ubunut :( If anybody manages to install it on Fedora please post your howto. If you haven't seen XboxMediaCenter you will be amazed how functiona and estetic this application is! I'm using it on my Xbox 1 console and I'm really blown away by it every time I use it. screenshots: http://xbmc.org/media/ videos: http://video.google.com/videosearch?q=xbmc# Cheers, Valent. -- http://kernelreloaded.blog385.com/ linux, blog, anime, spirituality, windsurf, wireless registered as user #367004 with the Linux Counter, http://counter.li.org. ICQ: 2125241, Skype: valent.turkovic From rawhide at fedoraproject.org Fri Sep 19 09:31:01 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Fri, 19 Sep 2008 09:31:01 +0000 (UTC) Subject: rawhide report: 20080919 changes Message-ID: <20080919093102.007D51F825E@releng2.fedora.phx.redhat.com> Removed package ivman Updated Packages: audit-1.7.7-1.fc10 ------------------ * Wed Sep 17 18:00:00 2008 Steve Grubb 1.7.7-1 - Bug fixes for GSSAPI code in remote logging (DJ Delorie) - Add watched syscall support to audisp-prelude - Enable tcp_wrappers support in auditd gnome-chemistry-utils-0.9.91-2.fc10 ----------------------------------- * Mon Sep 15 18:00:00 2008 Julian Sikorski - 0.9.91-2 - Added bodr to Requires - Added chrpath to BuildRequires - Switched to chrpath as a method to eliminate rpaths * Sun Sep 14 18:00:00 2008 Julian Sikorski - 0.9.91-1 - Updated to 0.9.91 - Dropped the ppc build patch (merged upstream) gvfs-0.99.8-4.fc10 ------------------ * Wed Sep 17 18:00:00 2008 Tomas Bzatek - 0.99.8-4 - Actually apply the kerberos patch * Tue Sep 16 18:00:00 2008 Tomas Bzatek - 0.99.8-3 - SMB: Fix kerberos authentication * Mon Sep 15 18:00:00 2008 Matthias Clasen - 0.99.8-2 - Update to 0.99.8 * Mon Sep 15 18:00:00 2008 - Bastien Nocera - 0.99.7.1-4 - Update for BlueZ and obex-data-server D-Bus API changes im-chooser-1.2.3-1.fc10 ----------------------- * Wed Sep 17 18:00:00 2008 Akira TAGOH - 1.2.3-1 - New upstream release. imsettings-0.104.0-1.fc10 ------------------------- * Wed Sep 17 18:00:00 2008 Akira TAGOH - 0.104.0-1 - New upstream release. - Fix deadkey issue under XIM. (#457901) - Correct .desktop file for imsettings-applet (#460695) - Hide a status icon by default. (#460703) koffice-1.6.3-16.fc10 --------------------- * Thu Sep 18 18:00:00 2008 Rex Dieter 1:1.6.3-16 - revert koffice2->koffice1, introduce Epoch - fix pkg interdependencies (#394101), multilib issues - -krita: drop Requires: %name-filters (#394101) - cleanup scriptlets libgcrypt-1.4.3-1.fc10 ---------------------- * Thu Sep 18 18:00:00 2008 Nalin Dahyabhai 1.4.3-1 - update to 1.4.3 - own /etc/gcrypt * Mon Sep 15 18:00:00 2008 Nalin Dahyabhai - invoke make with %{?_smp_mflags} to build faster on multi-processor systems (Steve Grubb) libgxim-0.2.0-1.fc10 -------------------- * Wed Sep 17 18:00:00 2008 Akira TAGOH - 0.2.0-1 - New upstream release. - Fix discarding some packets when reconnecting. - Fix invalid memory access. Summary: Added Packages: 0 Removed Packages: 1 Modified Packages: 8 Broken deps for i386 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.i386 requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so Broken deps for x86_64 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.x86_64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.ppc requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so Broken deps for ppc64 ---------------------------------------------------------- eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave livecd-tools-018-1.fc10.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.ppc64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) From nils at redhat.com Fri Sep 19 09:31:22 2008 From: nils at redhat.com (Nils Philippsen) Date: Fri, 19 Sep 2008 11:31:22 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080917150729.GA4076@jadzia.bu.edu> References: <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <20080917150729.GA4076@jadzia.bu.edu> Message-ID: <1221816682.29046.8.camel@gibraltar.str.redhat.com> On Wed, 2008-09-17 at 11:07 -0400, Matthew Miller wrote: > On Wed, Sep 17, 2008 at 12:39:54PM +0200, Nils Philippsen wrote: > > There is a use case for this, namely if you have several "seats" with > > different logged in users: in this case one probably only wants the > > sounds of the "active session" being played and others muted. Just in > > case you ask, we're using that setup at home, my wife and I are logged > > in all the time an switch between users via the applet or > > F7/F9. > > Yes, we do the same at my house. > > (Presumably you are also using KDM, given that current GDM is apparently > totally broken in this regard?) No, it doesn't seem broken to me. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils at redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From nils at redhat.com Fri Sep 19 09:37:12 2008 From: nils at redhat.com (Nils Philippsen) Date: Fri, 19 Sep 2008 11:37:12 +0200 Subject: Fedora not "free" enough for GNU? In-Reply-To: <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> Message-ID: <1221817032.29046.12.camel@gibraltar.str.redhat.com> On Thu, 2008-09-18 at 08:58 -0400, jude ui wrote: > > > On 9/17/08, Rahul Sundaram wrote: > jude ui wrote: > > Might want to take a look at > > > http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html > > Rahul > > > Why is there the source for firmware? > > >Sorry. I am not sure what that means. > > Rahul > > Thanks for the link - but it's debian-I thought we were > talking about Fedora here > > And to repharse my question - Can't you guys reselse the firmware as "release"? > opensource - are they prosperity drivers? (correct me if I'm wrong) "proprietary"? If I understand you correctly(*), then yes, most (all?) firmware is proprietary software for which we don't have the source code. (*): It's a bit hard to answer questions where you have to guess what is asked ;-). Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty nils at redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From fedora at camperquake.de Fri Sep 19 10:50:49 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 19 Sep 2008 12:50:49 +0200 Subject: where's gimp-2.4.7 for F9 ? In-Reply-To: <1221810026.18327.1128.camel@beck.corsepiu.local> References: <20080916181557.GD6117@x300.bos.redhat.com> <1221593179.18327.806.camel@beck.corsepiu.local> <20080918181439.GG6117@x300.bos.redhat.com> <1221801550.18327.1114.camel@beck.corsepiu.local> <1221804214.14439.61.camel@luminos.localdomain> <1221810026.18327.1128.camel@beck.corsepiu.local> Message-ID: <20080919125049.7afa0d8c@dhcp03.addix.net> Hi. On Fri, 19 Sep 2008 09:40:26 +0200, Ralf Corsepius wrote: > Do you have some redirection active? This would explain other > weirdnesses I have been experiencing throughout the last couple of > days. Yes, download.fedoraproject merrily redirect you around the world. From rc040203 at freenet.de Fri Sep 19 11:08:36 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 19 Sep 2008 13:08:36 +0200 Subject: where's gimp-2.4.7 for F9 ? In-Reply-To: <20080919125049.7afa0d8c@dhcp03.addix.net> References: <20080916181557.GD6117@x300.bos.redhat.com> <1221593179.18327.806.camel@beck.corsepiu.local> <20080918181439.GG6117@x300.bos.redhat.com> <1221801550.18327.1114.camel@beck.corsepiu.local> <1221804214.14439.61.camel@luminos.localdomain> <1221810026.18327.1128.camel@beck.corsepiu.local> <20080919125049.7afa0d8c@dhcp03.addix.net> Message-ID: <1221822516.18327.1160.camel@beck.corsepiu.local> On Fri, 2008-09-19 at 12:50 +0200, Ralf Ertzinger wrote: > Hi. > > On Fri, 19 Sep 2008 09:40:26 +0200, Ralf Corsepius wrote: > > > Do you have some redirection active? This would explain other > > weirdnesses I have been experiencing throughout the last couple of > > days. > > Yes, download.fedoraproject merrily redirect you around the world. Then I regret having to conclude this redirection to be non functional. BTW: Meanwhile the effect reappeared - I've been able to reproduce it several times (and videotaped it). Ralf From kzak at redhat.com Fri Sep 19 11:16:36 2008 From: kzak at redhat.com (Karel Zak) Date: Fri, 19 Sep 2008 13:16:36 +0200 Subject: No more MAKEDEV? In-Reply-To: References: <20080919011234.D974B619C5D@hormel.redhat.com> Message-ID: <20080919111636.GJ28147@nb.net.home> On Thu, Sep 18, 2008 at 10:56:45PM -0400, David A. Wheeler wrote: > > On Thursday 18 September 2008 07:41:12 pm Bill Nottingham wrote: > > > there's an already-upstream solution > > > of putting device nodes in /lib/udev/devices. Why not just use this, > > > remove MAKEDEV, simplify start_udev, and boot faster? > > Please don't _remove_ MAKEDEV. > I believe the FHS requires the existence of MAKEDEV, anyway; see: > http://www.pathname.com/fhs/pub/fhs-2.3.html#DEVDEVICEFILES > There are a lot of reasons to manually create a device in /dev. +1 karel -- Karel Zak From ndbecker2 at gmail.com Fri Sep 19 11:43:01 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 19 Sep 2008 07:43:01 -0400 Subject: make update problem Message-ID: When editor opens, all I do is add a line: type=E which seems to be what the comments in the template call for, then: make update Traceback (most recent call last): File "/usr/bin/bodhi", line 313, in main() File "/usr/bin/bodhi", line 134, in main updates = bodhi.parse_file(input_file=opts.input_file) File "/usr/lib/python2.5/site-packages/fedora/client/bodhi.py", line 268, in parse_file config.readfp(template_file) File "/usr/lib/python2.5/site-packages/iniparse/compat.py", line 106, in readfp self.data.readfp(fp) File "/usr/lib/python2.5/site-packages/iniparse/ini.py", line 501, in readfp raise MissingSectionHeaderError(fname, linecount, line) ConfigParser.MissingSectionHeaderError: File contains no section headers. file: bodhi.template, line: 6 'type=E\n' From ndbecker2 at gmail.com Fri Sep 19 12:26:17 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 19 Sep 2008 08:26:17 -0400 Subject: make update problem References: Message-ID: Neal Becker wrote: > When editor opens, all I do is add a line: > type=E > > which seems to be what the comments in the template call for, then: > > make update > Traceback (most recent call last): > File "/usr/bin/bodhi", line 313, in > main() > File "/usr/bin/bodhi", line 134, in main > updates = bodhi.parse_file(input_file=opts.input_file) > File "/usr/lib/python2.5/site-packages/fedora/client/bodhi.py", line > 268, in parse_file > config.readfp(template_file) > File "/usr/lib/python2.5/site-packages/iniparse/compat.py", line 106, in > readfp > self.data.readfp(fp) > File "/usr/lib/python2.5/site-packages/iniparse/ini.py", line 501, in > readfp > raise MissingSectionHeaderError(fname, linecount, line) > ConfigParser.MissingSectionHeaderError: File contains no section headers. > file: bodhi.template, line: 6 > 'type=E\n' > If I try this: --------------------- [ igraph-0.5-14.fc9 ] type=E -------------------- Then I get: call last): File "/usr/bin/bodhi", line 313, in main() File "/usr/bin/bodhi", line 134, in main updates = bodhi.parse_file(input_file=opts.input_file) File "/usr/lib/python2.5/site-packages/fedora/client/bodhi.py", line 280, in parse_file update['stable_karma'] = config.getint(section, 'stable_karma') File "/usr/lib/python2.5/site-packages/iniparse/compat.py", line 128, in getint return int(self.get(section, option)) File "/usr/lib/python2.5/site-packages/iniparse/compat.py", line 224, in get return self._interpolate(section, option, value, d) File "/usr/lib/python2.5/site-packages/iniparse/compat.py", line 232, in _interpolate if "%(" in value: TypeError: argument of type 'int' is not iterable From surya.namuduri at gmail.com Fri Sep 19 12:32:47 2008 From: surya.namuduri at gmail.com (Chaitanya) Date: Fri, 19 Sep 2008 18:02:47 +0530 Subject: sram card Message-ID: <1221827567.2994.4.camel@localhost.localdomain> Hi, I was trying to get a Pretec SRAM PCMCIA card to be detected on a Fedora 8. The module gets loaded correctly and lspci also shows the card. But the pccardctl shows it as "no driver". The kernel is compiled with PCMCIA support I'm not sure if this is the correct mailing list to contact, please let me know if there is another list. Thanks in advance. From u0103a at gmail.com Fri Sep 19 12:34:49 2008 From: u0103a at gmail.com (jude ui) Date: Fri, 19 Sep 2008 08:34:49 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <1221817032.29046.12.camel@gibraltar.str.redhat.com> References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221817032.29046.12.camel@gibraltar.str.redhat.com> Message-ID: <91157db90809190534s757edc28tc2868da2cc7fe245@mail.gmail.com> > > > (*): It's a bit hard to answer questions where you have to guess what is > asked ;-). > > > Sorry about that .... Where is the firmware- the kernel? -------------- next part -------------- An HTML attachment was scrubbed... URL: From u0103a at gmail.com Fri Sep 19 12:50:11 2008 From: u0103a at gmail.com (jude ui) Date: Fri, 19 Sep 2008 08:50:11 -0400 Subject: sram card In-Reply-To: <1221827567.2994.4.camel@localhost.localdomain> References: <1221827567.2994.4.camel@localhost.localdomain> Message-ID: <91157db90809190550w35260d02k6be96127516894c@mail.gmail.com> On 9/19/08, Chaitanya wrote: > > Hi, > > >I was trying to get a Pretec SRAM PCMCIA card to be detected on a > >Fedora 8. > > >The module gets loaded correctly and lspci also shows the card. > >But the pccardctl shows it as "no driver". >I'm not sure if this is the correct mailing list to contact, please let >me know if there is another list. It's okay- you're kindof in the right mailing list- although this is for development- what you're reporting here is a bug- at least fedora knows there is a card there (there's the PCMCIA support) Fedora doesn't have a driver So what is a "Pretec SRAM PCMCIA " card - what is it supposed to do? If its a really special card maybe , fedora isn't aware that it such a card exists or needed (others correct me if I'm wrong) 1. First file a bug report (I'm not 100% sure where) 2.Ask someone or check websites for the special driver (like www.linuxlinks.com) -------------- next part -------------- An HTML attachment was scrubbed... URL: From giallu at gmail.com Fri Sep 19 13:32:58 2008 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 19 Sep 2008 15:32:58 +0200 Subject: make update problem In-Reply-To: References: Message-ID: On Fri, Sep 19, 2008 at 1:43 PM, Neal Becker wrote: > When editor opens, all I do is add a line: > type=E > > which seems to be what the comments in the template call for, then: > > make update > Traceback (most recent call last): > File "/usr/bin/bodhi", line 313, in > main() > File "/usr/bin/bodhi", line 134, in main > updates = bodhi.parse_file(input_file=opts.input_file) > File "/usr/lib/python2.5/site-packages/fedora/client/bodhi.py", line 268, in parse_file > config.readfp(template_file) > File "/usr/lib/python2.5/site-packages/iniparse/compat.py", line 106, in readfp > self.data.readfp(fp) > File "/usr/lib/python2.5/site-packages/iniparse/ini.py", line 501, in readfp > raise MissingSectionHeaderError(fname, linecount, line) > ConfigParser.MissingSectionHeaderError: File contains no section headers. > file: bodhi.template, line: 6 > 'type=E\n' I'm not 100% sure if that's the same problem, but I had issues with "make update" as well and I was redirected to updating bodhi-client and python-fedora packages, then it worked like a charm. Right now I have: [giallu at bingo ~]$ rpm -q python-fedora bodhi-client python-fedora-0.3.6-2.fc9.noarch bodhi-client-0.5.3-1.fc9.noarch HTH Gianluca From ndbecker2 at gmail.com Fri Sep 19 13:47:36 2008 From: ndbecker2 at gmail.com (Neal Becker) Date: Fri, 19 Sep 2008 09:47:36 -0400 Subject: make update problem References: Message-ID: Gianluca Sforna wrote: > On Fri, Sep 19, 2008 at 1:43 PM, Neal Becker wrote: >> When editor opens, all I do is add a line: >> type=E >> >> which seems to be what the comments in the template call for, then: >> >> make update >> Traceback (most recent call last): >> File "/usr/bin/bodhi", line 313, in >> main() >> File "/usr/bin/bodhi", line 134, in main >> updates = bodhi.parse_file(input_file=opts.input_file) >> File "/usr/lib/python2.5/site-packages/fedora/client/bodhi.py", line >> 268, in parse_file >> config.readfp(template_file) >> File "/usr/lib/python2.5/site-packages/iniparse/compat.py", line 106, in >> readfp >> self.data.readfp(fp) >> File "/usr/lib/python2.5/site-packages/iniparse/ini.py", line 501, in >> readfp >> raise MissingSectionHeaderError(fname, linecount, line) >> ConfigParser.MissingSectionHeaderError: File contains no section headers. >> file: bodhi.template, line: 6 >> 'type=E\n' > > I'm not 100% sure if that's the same problem, but I had issues with > "make update" as well and I was redirected to updating bodhi-client > and python-fedora packages, then it worked like a charm. > > Right now I have: > [giallu at bingo ~]$ rpm -q python-fedora bodhi-client > python-fedora-0.3.6-2.fc9.noarch > bodhi-client-0.5.3-1.fc9.noarch > I have: python-fedora-0.3.6-2.fc9.noarch bodhi-client-0.5.3-1.fc9.noarch using this: -------------------------------- [ igraph-0.5-14.fc9 ] type=E ------------------------------ gives: make bodhi Traceback (most recent call last): File "/usr/bin/bodhi", line 313, in main() File "/usr/bin/bodhi", line 134, in main updates = bodhi.parse_file(input_file=opts.input_file) File "/usr/lib/python2.5/site-packages/fedora/client/bodhi.py", line 281, in parse_file update['stable_karma'] = config.getint(section, 'stable_karma') File "/usr/lib/python2.5/site-packages/iniparse/compat.py", line 128, in getint return int(self.get(section, option)) File "/usr/lib/python2.5/site-packages/iniparse/compat.py", line 224, in get return self._interpolate(section, option, value, d) File "/usr/lib/python2.5/site-packages/iniparse/compat.py", line 232, in _interpolate if "%(" in value: TypeError: argument of type 'int' is not iterable make: *** [bodhi] Error 1 From sundaram at fedoraproject.org Fri Sep 19 13:53:02 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 19 Sep 2008 19:23:02 +0530 Subject: Fedora not "free" enough for GNU? In-Reply-To: <91157db90809190534s757edc28tc2868da2cc7fe245@mail.gmail.com> References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221817032.29046.12.camel@gibraltar.str.redhat.com> <91157db90809190534s757edc28tc2868da2cc7fe245@mail.gmail.com> Message-ID: <48D3AEBE.7090901@fedoraproject.org> jude ui wrote: > > (*): It's a bit hard to answer questions where you have to guess what is > asked ;-). > > > Sorry about that .... > > Where is the firmware- the kernel? Sometimes, they are bundled within the kernel. Others are in *-firmware packages. Rahul From ivazqueznet at gmail.com Fri Sep 19 13:59:49 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 19 Sep 2008 09:59:49 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> Message-ID: <1221832789.3433.33.camel@ignacio.lan> On Thu, 2008-09-18 at 08:58 -0400, jude ui wrote: > And to repharse my question - Can't you guys reselse the firmware as > opensource - are they prosperity drivers? (correct me if I'm wrong) The firmware is not Fedora's to release. The hardware vendor releases it as a binary blob due to at least one of 3 concerns: 1) Regulatory issues Hardware vendors need to prevent end-users from modifying the firmware so that the hardware can not be driven outside legal ranges. 2) Intellectual "Property" issues Hardware vendors don't want other hardware vendors to know how they run their hardware so that their design can't be copied or stolen. 3) Inability to build Firmware is usually code for some PLD or ASIC, which needs specialized (and EXPENSIVE) compilers to build. Most people are unlikely to be able to turn the source into the firmware. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From pemboa at gmail.com Fri Sep 19 14:45:20 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 19 Sep 2008 09:45:20 -0500 Subject: Fedora not "free" enough for GNU? In-Reply-To: <1221832789.3433.33.camel@ignacio.lan> References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> Message-ID: <16de708d0809190745o77a9fd91p745689ebf706761e@mail.gmail.com> 2008/9/19 Ignacio Vazquez-Abrams : > On Thu, 2008-09-18 at 08:58 -0400, jude ui wrote: >> And to repharse my question - Can't you guys reselse the firmware as >> opensource - are they prosperity drivers? (correct me if I'm wrong) > > The firmware is not Fedora's to release. The hardware vendor releases it > as a binary blob due to at least one of 3 concerns: > > 1) Regulatory issues > > Hardware vendors need to prevent end-users from modifying the firmware > so that the hardware can not be driven outside legal ranges. > > 2) Intellectual "Property" issues > > Hardware vendors don't want other hardware vendors to know how they run > their hardware so that their design can't be copied or stolen. > > 3) Inability to build > > Firmware is usually code for some PLD or ASIC, which needs specialized > (and EXPENSIVE) compilers to build. Most people are unlikely to be able > to turn the source into the firmware. Only 3 seems valid to me. But I at least understand 1 and 2. -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From sundaram at fedoraproject.org Fri Sep 19 14:51:04 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 19 Sep 2008 20:21:04 +0530 Subject: Fedora not "free" enough for GNU? In-Reply-To: <16de708d0809190745o77a9fd91p745689ebf706761e@mail.gmail.com> References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> <16de708d0809190745o77a9fd91p745689ebf706761e@mail.gmail.com> Message-ID: <48D3BC58.9070407@fedoraproject.org> Arthur Pemberton wrote: > 2008/9/19 Ignacio Vazquez-Abrams : >> On Thu, 2008-09-18 at 08:58 -0400, jude ui wrote: >>> And to repharse my question - Can't you guys reselse the firmware as >>> opensource - are they prosperity drivers? (correct me if I'm wrong) >> The firmware is not Fedora's to release. The hardware vendor releases it >> as a binary blob due to at least one of 3 concerns: >> >> 1) Regulatory issues >> >> Hardware vendors need to prevent end-users from modifying the firmware >> so that the hardware can not be driven outside legal ranges. >> >> 2) Intellectual "Property" issues >> >> Hardware vendors don't want other hardware vendors to know how they run >> their hardware so that their design can't be copied or stolen. >> >> 3) Inability to build >> >> Firmware is usually code for some PLD or ASIC, which needs specialized >> (and EXPENSIVE) compilers to build. Most people are unlikely to be able >> to turn the source into the firmware. > > > Only 3 seems valid to me. But I at least understand 1 and 2. 1 is a serious concern as well legally. Linux kernel now has a framework to support this. http://lwn.net/Articles/294675/ Rahul From pemboa at gmail.com Fri Sep 19 14:59:03 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 19 Sep 2008 09:59:03 -0500 Subject: Fedora not "free" enough for GNU? In-Reply-To: <48D3BC58.9070407@fedoraproject.org> References: <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> <16de708d0809190745o77a9fd91p745689ebf706761e@mail.gmail.com> <48D3BC58.9070407@fedoraproject.org> Message-ID: <16de708d0809190759p7989090eg2b70392d5fea4355@mail.gmail.com> On Fri, Sep 19, 2008 at 9:51 AM, Rahul Sundaram wrote: > Arthur Pemberton wrote: >> >> 2008/9/19 Ignacio Vazquez-Abrams : >>> >>> On Thu, 2008-09-18 at 08:58 -0400, jude ui wrote: >>>> >>>> And to repharse my question - Can't you guys reselse the firmware as >>>> opensource - are they prosperity drivers? (correct me if I'm wrong) >>> >>> The firmware is not Fedora's to release. The hardware vendor releases it >>> as a binary blob due to at least one of 3 concerns: >>> >>> 1) Regulatory issues >>> >>> Hardware vendors need to prevent end-users from modifying the firmware >>> so that the hardware can not be driven outside legal ranges. >>> >>> 2) Intellectual "Property" issues >>> >>> Hardware vendors don't want other hardware vendors to know how they run >>> their hardware so that their design can't be copied or stolen. >>> >>> 3) Inability to build >>> >>> Firmware is usually code for some PLD or ASIC, which needs specialized >>> (and EXPENSIVE) compilers to build. Most people are unlikely to be able >>> to turn the source into the firmware. >> >> >> Only 3 seems valid to me. But I at least understand 1 and 2. > > 1 is a serious concern as well legally. Linux kernel now has a framework to > support this. > > http://lwn.net/Articles/294675/ > > Rahul Isn't 1 also the main reason GNU disagrees with the binary firmware? Disallowing the purchases of hardware from utilizing it how they would like to? -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From alan at redhat.com Fri Sep 19 15:00:17 2008 From: alan at redhat.com (Alan Cox) Date: Fri, 19 Sep 2008 11:00:17 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <1221832789.3433.33.camel@ignacio.lan> References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> Message-ID: <20080919150017.GA5599@shell.devel.redhat.com> > 2) Intellectual "Property" issues > > Hardware vendors don't want other hardware vendors to know how they run > their hardware so that their design can't be copied or stolen. Sounds like Microsoft about operating systems - not a good free software reason at all. > 3) Inability to build > > Firmware is usually code for some PLD or ASIC, which needs specialized > (and EXPENSIVE) compilers to build. Most people are unlikely to be able > to turn the source into the firmware. So.. most people can't work a compiler but they can still benefit from the fact there are people who can and do have the tools and use them. A lot of fancier embedded device firmware is ARM, MIPS or some microcontroller if you stuff it through a few disassemblers. Most CD/DVD firmware for example is ARM. Alan From nicolas.mailhot at laposte.net Fri Sep 19 15:06:18 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 19 Sep 2008 17:06:18 +0200 (CEST) Subject: Fedora not "free" enough for GNU? In-Reply-To: <48D3BC58.9070407@fedoraproject.org> References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> <16de708d0809190745o77a9fd91p745689ebf706761e@mail.gmail.com> <48D3BC58.9070407@fedoraproject.org> Message-ID: > Arthur Pemberton wrote: >> 2008/9/19 Ignacio Vazquez-Abrams : >>> 3) Inability to build >>> >>> Firmware is usually code for some PLD or ASIC, which needs >>> specialized >>> (and EXPENSIVE) compilers to build. Most people are unlikely to be >>> able >>> to turn the source into the firmware. >> >> >> Only 3 seems valid to me. 3 is ridiculous. If you really think no one can compile your sources, there is no risk at all to provide them. -- Nicolas Mailhot From ajax at redhat.com Fri Sep 19 15:06:59 2008 From: ajax at redhat.com (Adam Jackson) Date: Fri, 19 Sep 2008 11:06:59 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <20080919150017.GA5599@shell.devel.redhat.com> References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> <20080919150017.GA5599@shell.devel.redhat.com> Message-ID: <1221836819.15981.280.camel@atropine.boston.devel.redhat.com> On Fri, 2008-09-19 at 11:00 -0400, Alan Cox wrote: > > Firmware is usually code for some PLD or ASIC, which needs specialized > > (and EXPENSIVE) compilers to build. Most people are unlikely to be able > > to turn the source into the firmware. > > So.. most people can't work a compiler but they can still benefit from the > fact there are people who can and do have the tools and use them. Even if you don't have the tools to rebuild the firmware, knowing what it's doing helps you figure out why your driver doesn't work. Being able to read the source is valuable enough on its own. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pbrobinson at gmail.com Fri Sep 19 15:16:27 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 19 Sep 2008 16:16:27 +0100 Subject: fun with metacity segfaults on rawhide eeepc Message-ID: <5256d0b0809190816r705dafbboda1bf05843f31252@mail.gmail.com> Hi All, I installed rawhide on an asus eeepc 901 last night... can't say its been the most enjoyable experience. But the big issue I'm seeing which is basically making X unusable seems to be because metacity is segfaulting (details below). There were all sorts of other weird errors too at one point to do with gconf, no idea why but will try another reinstall once the Beta hits. Has anyone seen this before? Is there a way to move to to compiz on the command line so I can see if I have any more luck with that? metacity[2758]: segfault at 0 ip 080aa033 sp bf9ec1e0 error 4 in metacity[8048000+82000] [drm:i915_mem_init_heap] *ERROR* heap already initialized?<6>metacity[3035]: segfault at 0 ip 080aa033 sp bfacf530 error 4 in metacity[8048000+82000] [drm:i915_mem_init_heap] *ERROR* heap already initialized?<6>metacity[3331]: segfault at 0 ip 080aa033 sp bfc2afd0 error 4 in metacity[8048000+82000] [drm:i915_mem_init_heap] *ERROR* heap already initialized?<6>metacity[3589]: segfault at 0 ip 080aa033 sp bfc6eb10 error 4 in metacity[8048000+8200 Peter From alan at redhat.com Fri Sep 19 15:18:54 2008 From: alan at redhat.com (Alan Cox) Date: Fri, 19 Sep 2008 11:18:54 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <48D3BC58.9070407@fedoraproject.org> References: <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> <16de708d0809190745o77a9fd91p745689ebf706761e@mail.gmail.com> <48D3BC58.9070407@fedoraproject.org> Message-ID: <20080919151854.GC5599@shell.devel.redhat.com> On Fri, Sep 19, 2008 at 08:21:04PM +0530, Rahul Sundaram wrote: > 1 is a serious concern as well legally. Linux kernel now has a framework > to support this. > > http://lwn.net/Articles/294675/ As a note historically we used to ship a signed set of ISDN code that was approved. You could change it but then it became unapproved and not permitted in some countries. The approvals was basically a racket to make the phone companies money (by claiming that non approved software might bring down the exchanges etc). Once government got its new war on abstract nouns (terrorism this time) it didn't take very long after it was observed that "if it isn't robust enough to handle arbitary faulty ISDN stacks then terrorists can bring down the phone exchange before setting off a bomb" before that stopped being a credible telco story and scam. The Java issue is similar. Sun really want 'Java' to mean Sun Java compatible in all respects and passing the test suite. What they never seemed to grasp (or I suspect didn't at the time want to admit) was that nobody really minded that but instead wanted to build interesting things and change the code around and didn't care if it was called something else. Alan From pemboa at gmail.com Fri Sep 19 15:25:00 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 19 Sep 2008 10:25:00 -0500 Subject: Fedora not "free" enough for GNU? In-Reply-To: <1221832789.3433.33.camel@ignacio.lan> References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> Message-ID: <16de708d0809190825v5f36c593u3890ce0681dad9c4@mail.gmail.com> 2008/9/19 Ignacio Vazquez-Abrams : > On Thu, 2008-09-18 at 08:58 -0400, jude ui wrote: >> And to repharse my question - Can't you guys reselse the firmware as >> opensource - are they prosperity drivers? (correct me if I'm wrong) > > The firmware is not Fedora's to release. The hardware vendor releases it > as a binary blob due to at least one of 3 concerns: > > 1) Regulatory issues > > Hardware vendors need to prevent end-users from modifying the firmware > so that the hardware can not be driven outside legal ranges. > > 2) Intellectual "Property" issues > > Hardware vendors don't want other hardware vendors to know how they run > their hardware so that their design can't be copied or stolen. > > 3) Inability to build > > Firmware is usually code for some PLD or ASIC, which needs specialized > (and EXPENSIVE) compilers to build. Most people are unlikely to be able > to turn the source into the firmware. Another question I guess would be -- do any of these points benefit power or regular users? -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From mschmidt at redhat.com Fri Sep 19 15:27:08 2008 From: mschmidt at redhat.com (Michal Schmidt) Date: Fri, 19 Sep 2008 17:27:08 +0200 Subject: Lonely packages looking for cosy new owner In-Reply-To: <48C5190F.7020500@hhs.nl> References: <48C5190F.7020500@hhs.nl> Message-ID: <20080919172708.24d24fb2@brian.englab.brq.redhat.com> On Mon, 08 Sep 2008 14:22:39 +0200 Hans de Goede wrote: > Thus *all* of my packages are looking for a new owner (I'm not > actually orphaning them, but I *really* want to lower my load quite a > bit). > > https://admin.fedoraproject.org/pkgdb/users/packages/jwrdegoede?acls=owner > > If you are willing to take over any let me know and I'll orphan them > and you can pick them up. I'll be around for a long time to come to > answer any questions and help with any issues with them, so don't > hesitate! I'd like to take crack-attack, lbrickbuster2 and pachi. My wife loves these games. :-) Michal From ivazqueznet at gmail.com Fri Sep 19 15:35:20 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 19 Sep 2008 11:35:20 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <16de708d0809190825v5f36c593u3890ce0681dad9c4@mail.gmail.com> References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> <16de708d0809190825v5f36c593u3890ce0681dad9c4@mail.gmail.com> Message-ID: <1221838521.3433.39.camel@ignacio.lan> On Fri, 2008-09-19 at 10:25 -0500, Arthur Pemberton wrote: > 2008/9/19 Ignacio Vazquez-Abrams : > > 1) Regulatory issues > > > > Hardware vendors need to prevent end-users from modifying the firmware > > so that the hardware can not be driven outside legal ranges. > > > > 2) Intellectual "Property" issues > > > > Hardware vendors don't want other hardware vendors to know how they run > > their hardware so that their design can't be copied or stolen. > > > > 3) Inability to build > > > > Firmware is usually code for some PLD or ASIC, which needs specialized > > (and EXPENSIVE) compilers to build. Most people are unlikely to be able > > to turn the source into the firmware. > > Another question I guess would be -- do any of these points benefit > power or regular users? Hah. No. And in fact, it can cripple them under certain circumstances (e.g., bug in the firmware). -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Fri Sep 19 15:35:42 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 19 Sep 2008 21:05:42 +0530 Subject: Fedora not "free" enough for GNU? In-Reply-To: <16de708d0809190759p7989090eg2b70392d5fea4355@mail.gmail.com> References: <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> <16de708d0809190745o77a9fd91p745689ebf706761e@mail.gmail.com> <48D3BC58.9070407@fedoraproject.org> <16de708d0809190759p7989090eg2b70392d5fea4355@mail.gmail.com> Message-ID: <48D3C6CE.8090201@fedoraproject.org> Arthur Pemberton wrote: > Isn't 1 also the main reason GNU disagrees with the binary firmware? > Disallowing the purchases of hardware from utilizing it how they would > like to? I think you would have to ask them to know what they are thinking. Not here. Rahul From u0103a at gmail.com Fri Sep 19 15:42:10 2008 From: u0103a at gmail.com (jude ui) Date: Fri, 19 Sep 2008 11:42:10 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <48D3C6CE.8090201@fedoraproject.org> References: <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> <16de708d0809190745o77a9fd91p745689ebf706761e@mail.gmail.com> <48D3BC58.9070407@fedoraproject.org> <16de708d0809190759p7989090eg2b70392d5fea4355@mail.gmail.com> <48D3C6CE.8090201@fedoraproject.org> Message-ID: <91157db90809190842m12ae7d03hf5670519e1f0d580@mail.gmail.com> > > > 1) Regulatory issues > > > > Hardware vendors need to prevent end-users from modifying the firmware > > so that the hardware can not be driven outside legal ranges. > > > > 2) Intellectual "Property" issues > > > > Hardware vendors don't want other hardware vendors to know how they run > > their hardware so that their design can't be copied or stolen. > > > > 3) Inability to build > > > > Firmware is usually code for some PLD or ASIC, which needs specialized > > (and EXPENSIVE) compilers to build. Most people are unlikely to be able > > to turn the source into the firmware. Now this is making a little more sence - I gues the only solution is to provide it seperatly for others to install at they're own disgresstion. Come to think of it now I have an idea - if there is apt for package management - could there be the same for firmware and drivers (they're software too)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan at redhat.com Fri Sep 19 15:45:39 2008 From: alan at redhat.com (Alan Cox) Date: Fri, 19 Sep 2008 11:45:39 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <1221838521.3433.39.camel@ignacio.lan> References: <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> <16de708d0809190825v5f36c593u3890ce0681dad9c4@mail.gmail.com> <1221838521.3433.39.camel@ignacio.lan> Message-ID: <20080919154539.GB10901@shell.devel.redhat.com> On Fri, Sep 19, 2008 at 11:35:20AM -0400, Ignacio Vazquez-Abrams wrote: > Hah. No. And in fact, it can cripple them under certain circumstances > (e.g., bug in the firmware). Also products which use firmware to artifically cripple the device so they can sell the uncrippled one for more. Alan From sundaram at fedoraproject.org Fri Sep 19 15:45:40 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 19 Sep 2008 21:15:40 +0530 Subject: Fedora not "free" enough for GNU? In-Reply-To: <91157db90809190842m12ae7d03hf5670519e1f0d580@mail.gmail.com> References: <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> <16de708d0809190745o77a9fd91p745689ebf706761e@mail.gmail.com> <48D3BC58.9070407@fedoraproject.org> <16de708d0809190759p7989090eg2b70392d5fea4355@mail.gmail.com> <48D3C6CE.8090201@fedoraproject.org> <91157db90809190842m12ae7d03hf5670519e1f0d580@mail.gmail.com> Message-ID: <48D3C924.5040900@fedoraproject.org> jude ui wrote: > > Now this is making a little more sence - I gues the only solution is to > provide it seperatly for others to install at they're own disgresstion. It is already provided separately. The firmware for the kernel used to be within the same package but even that is split up in rawhide. > Come to think of it now I have an idea - if there is apt for package > management - could there be the same for firmware and drivers (they're > software too)? What does this mean? Rahul From lesmikesell at gmail.com Fri Sep 19 15:49:42 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 19 Sep 2008 10:49:42 -0500 Subject: Fedora not "free" enough for GNU? In-Reply-To: <1221836819.15981.280.camel@atropine.boston.devel.redhat.com> References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> <20080919150017.GA5599@shell.devel.redhat.com> <1221836819.15981.280.camel@atropine.boston.devel.redhat.com> Message-ID: <48D3CA16.1020902@gmail.com> Adam Jackson wrote: > >>> Firmware is usually code for some PLD or ASIC, which needs specialized >>> (and EXPENSIVE) compilers to build. Most people are unlikely to be able >>> to turn the source into the firmware. >> So.. most people can't work a compiler but they can still benefit from the >> fact there are people who can and do have the tools and use them. > > Even if you don't have the tools to rebuild the firmware, knowing what > it's doing helps you figure out why your driver doesn't work. Being > able to read the source is valuable enough on its own. I don't think anyone is arguing that source availability is bad, but how something is distributed is up to the author/copyright holder. The only way to get free source is for someone to write/own it that wants to give it away and has rights to all components that it might be derived from. There are, and probably always will be cases where that hasn't happened for something you need to drive a piece of hardware. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Fri Sep 19 15:55:26 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 19 Sep 2008 10:55:26 -0500 Subject: Fedora not "free" enough for GNU? In-Reply-To: <20080919151854.GC5599@shell.devel.redhat.com> References: <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> <16de708d0809190745o77a9fd91p745689ebf706761e@mail.gmail.com> <48D3BC58.9070407@fedoraproject.org> <20080919151854.GC5599@shell.devel.redhat.com> Message-ID: <48D3CB6E.9000009@gmail.com> Alan Cox wrote: > > The Java issue is similar. Sun really want 'Java' to mean Sun Java compatible > in all respects and passing the test suite. What they never seemed to grasp (or > I suspect didn't at the time want to admit) was that nobody really minded that > but instead wanted to build interesting things and change the code around and > didn't care if it was called something else. I think I've missed something if that's actually the case. Is there really a non-Sun java that is 100% compatible? When I run java apps, I don't want something "interesting" to happen. -- Les Mikesell lesmikesell at gmail.com From u0103a at gmail.com Fri Sep 19 15:51:23 2008 From: u0103a at gmail.com (jude ui) Date: Fri, 19 Sep 2008 11:51:23 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <48D3C924.5040900@fedoraproject.org> References: <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> <16de708d0809190745o77a9fd91p745689ebf706761e@mail.gmail.com> <48D3BC58.9070407@fedoraproject.org> <16de708d0809190759p7989090eg2b70392d5fea4355@mail.gmail.com> <48D3C6CE.8090201@fedoraproject.org> <91157db90809190842m12ae7d03hf5670519e1f0d580@mail.gmail.com> <48D3C924.5040900@fedoraproject.org> Message-ID: <91157db90809190851t263f7a14ye5b763b9fcec5c4d@mail.gmail.com> oooooooh ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan at redhat.com Fri Sep 19 16:11:10 2008 From: alan at redhat.com (Alan Cox) Date: Fri, 19 Sep 2008 12:11:10 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <48D3CB6E.9000009@gmail.com> References: <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> <16de708d0809190745o77a9fd91p745689ebf706761e@mail.gmail.com> <48D3BC58.9070407@fedoraproject.org> <20080919151854.GC5599@shell.devel.redhat.com> <48D3CB6E.9000009@gmail.com> Message-ID: <20080919161110.GA14003@shell.devel.redhat.com> On Fri, Sep 19, 2008 at 10:55:26AM -0500, Les Mikesell wrote: > I think I've missed something if that's actually the case. Is there > really a non-Sun java that is 100% compatible? When I run java apps, I IBM I believe > don't want something "interesting" to happen. Thats about the trademark name not the code. You don't care what running 'frobozz' does, but what 'java' means.. Alan From lesmikesell at gmail.com Fri Sep 19 16:38:12 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 19 Sep 2008 11:38:12 -0500 Subject: Fedora not "free" enough for GNU? In-Reply-To: <20080919161110.GA14003@shell.devel.redhat.com> References: <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> <16de708d0809190745o77a9fd91p745689ebf706761e@mail.gmail.com> <48D3BC58.9070407@fedoraproject.org> <20080919151854.GC5599@shell.devel.redhat.com> <48D3CB6E.9000009@gmail.com> <20080919161110.GA14003@shell.devel.redhat.com> Message-ID: <48D3D574.3030400@gmail.com> Alan Cox wrote: > On Fri, Sep 19, 2008 at 10:55:26AM -0500, Les Mikesell wrote: >> I think I've missed something if that's actually the case. Is there >> really a non-Sun java that is 100% compatible? When I run java apps, I > > IBM I believe > >> don't want something "interesting" to happen. > > Thats about the trademark name not the code. You don't care what running > 'frobozz' does, but what 'java' means.. Right - but I've just seen too much stuff that pretends to be java that isn't quite. My latest encounter is a cell phone that doesn't give the jvm access to its soft (and only) keyboard. You can install mini-opera but you can't type a url... -- Les Mikesell lesmikesell at gmail.com From kevin at scrye.com Fri Sep 19 16:40:20 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Fri, 19 Sep 2008 10:40:20 -0600 Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <1221787714.3433.5.camel@ignacio.lan> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221787714.3433.5.camel@ignacio.lan> Message-ID: <20080919104020.3958c1c5@ohm.scrye.com> On Thu, 18 Sep 2008 21:28:34 -0400 ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) wrote: > On Thu, 2008-09-18 at 17:41 -0700, Bill Nottingham wrote: > > The only user of it in Fedora is udev... > > tpb as well. Hi there... I am the current maintainer for tpb, but I no longer use a thinkpad day to day, so I haven't done much with this package of late. tpb upstream had been dead for a long time, but there is some activity now this year. Would anyone care to take over tpb? Or does anyone even use it these days? Perhaps we can just drop it? Let me know and I will be happy to release it... kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From walters at verbum.org Fri Sep 19 16:41:53 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 19 Sep 2008 12:41:53 -0400 Subject: fun with metacity segfaults on rawhide eeepc In-Reply-To: <5256d0b0809190816r705dafbboda1bf05843f31252@mail.gmail.com> References: <5256d0b0809190816r705dafbboda1bf05843f31252@mail.gmail.com> Message-ID: On Fri, Sep 19, 2008 at 11:16 AM, Peter Robinson wrote: > Hi All, > > I installed rawhide on an asus eeepc 901 last night... can't say its > been the most enjoyable experience. > > But the big issue I'm seeing which is basically making X unusable > seems to be because metacity is segfaulting (details below). Hi, please see: http://fedoraproject.org/wiki/StackTraces And file a bug against metacity with the associated trace. (Someday we will finish http://fedoraproject.org/wiki/CrashHandling and this manual work will not be necessary) From limb at jcomserv.net Fri Sep 19 16:49:26 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 19 Sep 2008 11:49:26 -0500 (CDT) Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <20080919104020.3958c1c5@ohm.scrye.com> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221787714.3433.5.camel@ignacio.lan> <20080919104020.3958c1c5@ohm.scrye.com> Message-ID: <31662.198.175.55.5.1221842966.squirrel@mail.jcomserv.net> > On Thu, 18 Sep 2008 21:28:34 -0400 > ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) wrote: > >> On Thu, 2008-09-18 at 17:41 -0700, Bill Nottingham wrote: >> > The only user of it in Fedora is udev... >> >> tpb as well. > > Hi there... I am the current maintainer for tpb, but I no longer use a > thinkpad day to day, so I haven't done much with this package of late. > > tpb upstream had been dead for a long time, but there is some activity > now this year. > > Would anyone care to take over tpb? Or does anyone even use it these > days? Perhaps we can just drop it? > > Let me know and I will be happy to release it... We use them at work. I'll take it if no one else speaks up. > kevin > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From hughsient at gmail.com Fri Sep 19 16:48:35 2008 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 19 Sep 2008 17:48:35 +0100 Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <20080919104020.3958c1c5@ohm.scrye.com> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221787714.3433.5.camel@ignacio.lan> <20080919104020.3958c1c5@ohm.scrye.com> Message-ID: <1221842915.5524.5.camel@hughsie-work> On Fri, 2008-09-19 at 10:40 -0600, Kevin Fenzi wrote: > Would anyone care to take over tpb? Or does anyone even use it these > days? Perhaps we can just drop it? Vendor specific daemons such as tpb have been on the way out since we've been moving the userspace bodges down into proper kernel frameworks. ThinkPads, just like any other model, should "just work" without any special daemons installed. Richard. From limb at jcomserv.net Fri Sep 19 16:53:37 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 19 Sep 2008 11:53:37 -0500 (CDT) Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <1221842915.5524.5.camel@hughsie-work> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221787714.3433.5.camel@ignacio.lan> <20080919104020.3958c1c5@ohm.scrye.com> <1221842915.5524.5.camel@hughsie-work> Message-ID: <45771.198.175.55.5.1221843217.squirrel@mail.jcomserv.net> > On Fri, 2008-09-19 at 10:40 -0600, Kevin Fenzi wrote: >> Would anyone care to take over tpb? Or does anyone even use it these >> days? Perhaps we can just drop it? > > Vendor specific daemons such as tpb have been on the way out since we've > been moving the userspace bodges down into proper kernel frameworks. > > ThinkPads, just like any other model, should "just work" without any > special daemons installed. That would be ideal. Are we to that point currently? If so, I vote let it EOL. > Richard. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From opensource at till.name Fri Sep 19 16:58:50 2008 From: opensource at till.name (Till Maas) Date: Fri, 19 Sep 2008 18:58:50 +0200 Subject: Hal keymap quirks (was: Re: anyone interested in tpb?) In-Reply-To: <20080919104020.3958c1c5@ohm.scrye.com> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221787714.3433.5.camel@ignacio.lan> <20080919104020.3958c1c5@ohm.scrye.com> Message-ID: <200809191858.56778.opensource@till.name> On Fri September 19 2008, Kevin Fenzi wrote: > Would anyone care to take over tpb? Or does anyone even use it these > days? Perhaps we can just drop it? I use it too, but it seems that a better way would be to use hal keymap quirks[1] instead, but I do not yet know how to do this sucessfully. Regards, Till [1] http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From pbrobinson at gmail.com Fri Sep 19 16:59:02 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 19 Sep 2008 17:59:02 +0100 Subject: fun with metacity segfaults on rawhide eeepc In-Reply-To: References: <5256d0b0809190816r705dafbboda1bf05843f31252@mail.gmail.com> Message-ID: <5256d0b0809190959o2b81b68ese04e595af340d4c8@mail.gmail.com> >> I installed rawhide on an asus eeepc 901 last night... can't say its >> been the most enjoyable experience. >> >> But the big issue I'm seeing which is basically making X unusable >> seems to be because metacity is segfaulting (details below). > > Hi, please see: > > http://fedoraproject.org/wiki/StackTraces > > And file a bug against metacity with the associated trace. > > (Someday we will finish http://fedoraproject.org/wiki/CrashHandling > and this manual work will not be necessary) OK, I can install debug packages and log tickets without issue but I have no idea given that its crashing as I login through GDM I have no idea how I'd add GDB to that. Peter From limb at jcomserv.net Fri Sep 19 17:02:27 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 19 Sep 2008 12:02:27 -0500 (CDT) Subject: Hal keymap quirks (was: Re: anyone interested in tpb?) In-Reply-To: <200809191858.56778.opensource@till.name> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221787714.3433.5.camel@ignacio.lan> <20080919104020.3958c1c5@ohm.scrye.com> <200809191858.56778.opensource@till.name> Message-ID: <11078.198.175.55.5.1221843747.squirrel@mail.jcomserv.net> > On Fri September 19 2008, Kevin Fenzi wrote: > >> Would anyone care to take over tpb? Or does anyone even use it these >> days? Perhaps we can just drop it? > > I use it too, but it seems that a better way would be to use hal keymap > quirks[1] instead, but I do not yet know how to do this sucessfully. Not sure. As it it, I just tested a t43 I have, and the buttons, they do nothing, until tpb is installed. For that reason, I could see keeping tpb until hal keyboard quirks is documented. Or if it already is, someone links to it. :) > Regards, > Till > > > [1] http://people.freedesktop.org/~hughsient/quirk/quirk-keymap-index.html > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From mclasen at redhat.com Fri Sep 19 17:05:36 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Fri, 19 Sep 2008 13:05:36 -0400 Subject: fun with metacity segfaults on rawhide eeepc In-Reply-To: <5256d0b0809190959o2b81b68ese04e595af340d4c8@mail.gmail.com> References: <5256d0b0809190816r705dafbboda1bf05843f31252@mail.gmail.com> <5256d0b0809190959o2b81b68ese04e595af340d4c8@mail.gmail.com> Message-ID: <1221843936.27383.2.camel@localhost.localdomain> On Fri, 2008-09-19 at 17:59 +0100, Peter Robinson wrote: > >> I installed rawhide on an asus eeepc 901 last night... can't say its > >> been the most enjoyable experience. > >> > >> But the big issue I'm seeing which is basically making X unusable > >> seems to be because metacity is segfaulting (details below). > > > > Hi, please see: > > > > http://fedoraproject.org/wiki/StackTraces > > > > And file a bug against metacity with the associated trace. > > > > (Someday we will finish http://fedoraproject.org/wiki/CrashHandling > > and this manual work will not be necessary) > > OK, I can install debug packages and log tickets without issue but I > have no idea given that its crashing as I login through GDM I have no > idea how I'd add GDB to that. What you can always do is get a core dump and use gdb on that later ulimit -c unlimited gdb /path/to/app core From dbn.lists at gmail.com Fri Sep 19 17:09:28 2008 From: dbn.lists at gmail.com (Dan Nicholson) Date: Fri, 19 Sep 2008 10:09:28 -0700 Subject: fun with metacity segfaults on rawhide eeepc In-Reply-To: <5256d0b0809190959o2b81b68ese04e595af340d4c8@mail.gmail.com> References: <5256d0b0809190816r705dafbboda1bf05843f31252@mail.gmail.com> <5256d0b0809190959o2b81b68ese04e595af340d4c8@mail.gmail.com> Message-ID: <91705d080809191009u4e52a126n91b3b4ce3e0da086@mail.gmail.com> On Fri, Sep 19, 2008 at 9:59 AM, Peter Robinson wrote: >>> I installed rawhide on an asus eeepc 901 last night... can't say its >>> been the most enjoyable experience. >>> >>> But the big issue I'm seeing which is basically making X unusable >>> seems to be because metacity is segfaulting (details below). >> >> Hi, please see: >> >> http://fedoraproject.org/wiki/StackTraces >> >> And file a bug against metacity with the associated trace. >> >> (Someday we will finish http://fedoraproject.org/wiki/CrashHandling >> and this manual work will not be necessary) > > OK, I can install debug packages and log tickets without issue but I > have no idea given that its crashing as I login through GDM I have no > idea how I'd add GDB to that. Go to the console and run it through startx. You can just invoke metacity as your regular window manager. echo xterm > ~/.xinitrc Then from the fresh xterm, you can run metacity through gdb. Maybe it won't be triggered, though, unless you run a full gnome-session. Matthias' suggestion might be easier, though. -- Dan From ssorce at redhat.com Fri Sep 19 17:23:11 2008 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 19 Sep 2008 13:23:11 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <48D3D574.3030400@gmail.com> References: <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> <16de708d0809190745o77a9fd91p745689ebf706761e@mail.gmail.com> <48D3BC58.9070407@fedoraproject.org> <20080919151854.GC5599@shell.devel.redhat.com> <48D3CB6E.9000009@gmail.com> <20080919161110.GA14003@shell.devel.redhat.com> <48D3D574.3030400@gmail.com> Message-ID: <1221844991.6455.21.camel@localhost.localdomain> On Fri, 2008-09-19 at 11:38 -0500, Les Mikesell wrote: > Alan Cox wrote: > > On Fri, Sep 19, 2008 at 10:55:26AM -0500, Les Mikesell wrote: > >> I think I've missed something if that's actually the case. Is there > >> really a non-Sun java that is 100% compatible? When I run java apps, I > > > > IBM I believe > > > >> don't want something "interesting" to happen. > > > > Thats about the trademark name not the code. You don't care what running > > 'frobozz' does, but what 'java' means.. > > Right - but I've just seen too much stuff that pretends to be java that > isn't quite. My latest encounter is a cell phone that doesn't give the > jvm access to its soft (and only) keyboard. You can install mini-opera > but you can't type a url... This really does not apply, you are confounding JVM compliance with the sandboxing technique the phone maker decided to adopt. You can as easily have a Sun JVM running in Linux and denying it access to a keyboard. These are 2 completely orthogonal things. Simo. -- Simo Sorce * Red Hat, Inc * New York From mike at miketc.net Fri Sep 19 17:37:44 2008 From: mike at miketc.net (Mike Chambers) Date: Fri, 19 Sep 2008 12:37:44 -0500 Subject: Rawhide install 9/19 via NFS fails network setup Message-ID: <1221845864.3552.3.camel@scrappy.miketc.net> When configuring network setup (static IP) and hitting apply, got a traceback. Wasn't able to save the output, but did copy down what looks like the problem line.. /usr/lib/anaconda/iw/netconfig_dialog.py line 191 in _ok.netdev.bringDeviceUp () not present or available or something. NetworkDevice instance has no attribute 'bringDeviceUp' Something along those lines and had to exit the installer. -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From lesmikesell at gmail.com Fri Sep 19 17:52:24 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 19 Sep 2008 12:52:24 -0500 Subject: Fedora not "free" enough for GNU? In-Reply-To: <1221844991.6455.21.camel@localhost.localdomain> References: <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> <16de708d0809190745o77a9fd91p745689ebf706761e@mail.gmail.com> <48D3BC58.9070407@fedoraproject.org> <20080919151854.GC5599@shell.devel.redhat.com> <48D3CB6E.9000009@gmail.com> <20080919161110.GA14003@shell.devel.redhat.com> <48D3D574.3030400@gmail.com> <1221844991.6455.21.camel@localhost.localdomain> Message-ID: <48D3E6D8.9010001@gmail.com> Simo Sorce wrote: > >>>> I think I've missed something if that's actually the case. Is there >>>> really a non-Sun java that is 100% compatible? When I run java apps, I >>> IBM I believe >>> >>>> don't want something "interesting" to happen. >>> Thats about the trademark name not the code. You don't care what running >>> 'frobozz' does, but what 'java' means.. >> Right - but I've just seen too much stuff that pretends to be java that >> isn't quite. My latest encounter is a cell phone that doesn't give the >> jvm access to its soft (and only) keyboard. You can install mini-opera >> but you can't type a url... > > This really does not apply, you are confounding JVM compliance with the > sandboxing technique the phone maker decided to adopt. If JVM compliance doesn't require access to your input, why bother testing something that can't work? > You can as easily have a Sun JVM running in Linux and denying it access > to a keyboard. It isn't denied access as a permission issue. The code that would give it access is replaced by custom code that requires matching changes in the apps. > These are 2 completely orthogonal things. It is either just a bug or an effort on the vendor's part to make people buy their custom apps (which aren't available yet either..). They are promising an update to fix it sometime in the distant future. -- Les Mikesell lesmikesell at gmail.com From ivazqueznet at gmail.com Fri Sep 19 17:55:10 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Fri, 19 Sep 2008 13:55:10 -0400 Subject: Hal keymap quirks (was: Re: anyone interested in tpb?) In-Reply-To: <11078.198.175.55.5.1221843747.squirrel@mail.jcomserv.net> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221787714.3433.5.camel@ignacio.lan> <20080919104020.3958c1c5@ohm.scrye.com> <200809191858.56778.opensource@till.name> <11078.198.175.55.5.1221843747.squirrel@mail.jcomserv.net> Message-ID: <1221846910.3433.44.camel@ignacio.lan> On Fri, 2008-09-19 at 12:02 -0500, Jon Ciesla wrote: > > I use it too, but it seems that a better way would be to use hal keymap > > quirks[1] instead, but I do not yet know how to do this sucessfully. > > Not sure. As it it, I just tested a t43 I have, and the buttons, they do > nothing, until tpb is installed. Not even taking a dump in the system log? -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From joshuacov at googlemail.com Fri Sep 19 17:57:34 2008 From: joshuacov at googlemail.com (Joshua C.) Date: Fri, 19 Sep 2008 19:57:34 +0200 Subject: modesetting feature status In-Reply-To: References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <5f6f8c5f0809111209o1d28bae4p246d699f3520c40@mail.gmail.com> <1221174980.30676.10.camel@optimus> <5f6f8c5f0809120305y41ac861fq8a91d1547519a955@mail.gmail.com> <5f6f8c5f0809171136lb722a87taee2cbd5afc2ff29@mail.gmail.com> <1221683977.15981.223.camel@atropine.boston.devel.redhat.com> <48D1D978.7020102@shmuelhome.mine.nu> <3da3b5b40809180036o33ad4e27h328ba1740bf03ade@mail.gmail.com> <48D2070C.7010508@fedoraproject.org> Message-ID: <5f6f8c5f0809191057m23688c2by287052700b94312b@mail.gmail.com> 2008/9/18 Nicolas Mailhot : > > > Le Jeu 18 septembre 2008 09:45, Rahul Sundaram a ?crit : >> >> Ahmed Kamal wrote: >>> What about modesetting for proprietary nvidia users ? >> >> Your question has half of the answer. Only Nvidia has the source code. >> Ask them. > > That still leaves the question of nv and nouveau users open. > > -- > Nicolas Mailhot > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > I tried `strace -o /drm.strace modprobe drm debug=1` and got the output in the attached file. I tried the same with `strace -o /radeon.trace modprobe radeon modeset=1` but this time there's nothing in the file. How can I hook strace to the radeon driver? -------------- next part -------------- A non-text attachment was scrubbed... Name: drm.strace Type: application/octet-stream Size: 14038 bytes Desc: not available URL: From limb at jcomserv.net Fri Sep 19 17:58:50 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Fri, 19 Sep 2008 12:58:50 -0500 (CDT) Subject: Hal keymap quirks (was: Re: anyone interested in tpb?) In-Reply-To: <1221846910.3433.44.camel@ignacio.lan> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221787714.3433.5.camel@ignacio.lan> <20080919104020.3958c1c5@ohm.scrye.com> <200809191858.56778.opensource@till.name> <11078.198.175.55.5.1221843747.squirrel@mail.jcomserv.net> <1221846910.3433.44.camel@ignacio.lan> Message-ID: <57750.198.175.55.5.1221847130.squirrel@mail.jcomserv.net> > On Fri, 2008-09-19 at 12:02 -0500, Jon Ciesla wrote: >> > I use it too, but it seems that a better way would be to use hal >> keymap >> > quirks[1] instead, but I do not yet know how to do this sucessfully. >> >> Not sure. As it it, I just tested a t43 I have, and the buttons, they >> do >> nothing, until tpb is installed. > > Not even taking a dump in the system log? Just tried that. Nothing. > -- > Ignacio Vazquez-Abrams > > PLEASE don't CC me; I'm already subscribed > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- novus ordo absurdum From alan at redhat.com Fri Sep 19 18:17:04 2008 From: alan at redhat.com (Alan Cox) Date: Fri, 19 Sep 2008 14:17:04 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <48D3D574.3030400@gmail.com> References: <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> <16de708d0809190745o77a9fd91p745689ebf706761e@mail.gmail.com> <48D3BC58.9070407@fedoraproject.org> <20080919151854.GC5599@shell.devel.redhat.com> <48D3CB6E.9000009@gmail.com> <20080919161110.GA14003@shell.devel.redhat.com> <48D3D574.3030400@gmail.com> Message-ID: <20080919181704.GA27686@shell.devel.redhat.com> On Fri, Sep 19, 2008 at 11:38:12AM -0500, Les Mikesell wrote: > isn't quite. My latest encounter is a cell phone that doesn't give the > jvm access to its soft (and only) keyboard. You can install mini-opera > but you can't type a url... But that is standards compliant I believe. The original java mobile spec doesn't guarantee you get keyboard support, just how you interface with it if you do. From fedora at camperquake.de Fri Sep 19 18:37:51 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 19 Sep 2008 20:37:51 +0200 Subject: where's gimp-2.4.7 for F9 ? In-Reply-To: <1221822516.18327.1160.camel@beck.corsepiu.local> References: <20080916181557.GD6117@x300.bos.redhat.com> <1221593179.18327.806.camel@beck.corsepiu.local> <20080918181439.GG6117@x300.bos.redhat.com> <1221801550.18327.1114.camel@beck.corsepiu.local> <1221804214.14439.61.camel@luminos.localdomain> <1221810026.18327.1128.camel@beck.corsepiu.local> <20080919125049.7afa0d8c@dhcp03.addix.net> <1221822516.18327.1160.camel@beck.corsepiu.local> Message-ID: <20080919203751.1b495c21@lain.camperquake.de> Hi On Fri, 19 Sep 2008 13:08:36 +0200, Ralf Corsepius wrote > Then I regret having to conclude this redirection to be non > functional. Yep. You'll get one repomd.xml from one mirror, primary.sqlite from another, and packages from a third. Which don't match, sometimes. From jwboyer at gmail.com Fri Sep 19 18:45:02 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 19 Sep 2008 14:45:02 -0400 Subject: modesetting feature status In-Reply-To: <5f6f8c5f0809191057m23688c2by287052700b94312b@mail.gmail.com> References: <5f6f8c5f0809111209o1d28bae4p246d699f3520c40@mail.gmail.com> <1221174980.30676.10.camel@optimus> <5f6f8c5f0809120305y41ac861fq8a91d1547519a955@mail.gmail.com> <5f6f8c5f0809171136lb722a87taee2cbd5afc2ff29@mail.gmail.com> <1221683977.15981.223.camel@atropine.boston.devel.redhat.com> <48D1D978.7020102@shmuelhome.mine.nu> <3da3b5b40809180036o33ad4e27h328ba1740bf03ade@mail.gmail.com> <48D2070C.7010508@fedoraproject.org> <5f6f8c5f0809191057m23688c2by287052700b94312b@mail.gmail.com> Message-ID: <20080919184502.GA4545@yoda.jdub.homelinux.org> On Fri, Sep 19, 2008 at 07:57:34PM +0200, Joshua C. wrote: >I tried `strace -o /drm.strace modprobe drm debug=1` and got the >output in the attached file. I tried the same with `strace -o >/radeon.trace modprobe radeon modeset=1` but this time there's nothing >in the file. How can I hook strace to the radeon driver? You can't. All you're stracing is the modprobe command, not the driver operation. Drivers don't operate in userspace, and don't make system calls. So strace just plain doesn't work. josh From mjs at clemson.edu Fri Sep 19 19:27:41 2008 From: mjs at clemson.edu (Matthew Saltzman) Date: Fri, 19 Sep 2008 19:27:41 +0000 Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <31662.198.175.55.5.1221842966.squirrel@mail.jcomserv.net> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221787714.3433.5.camel@ignacio.lan> <20080919104020.3958c1c5@ohm.scrye.com> <31662.198.175.55.5.1221842966.squirrel@mail.jcomserv.net> Message-ID: <1221852461.12827.23.camel@valkyrie.localdomain> On Fri, 2008-09-19 at 11:49 -0500, Jon Ciesla wrote: > > On Thu, 18 Sep 2008 21:28:34 -0400 > > ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) wrote: > > > >> On Thu, 2008-09-18 at 17:41 -0700, Bill Nottingham wrote: > >> > The only user of it in Fedora is udev... > >> > >> tpb as well. > > > > Hi there... I am the current maintainer for tpb, but I no longer use a > > thinkpad day to day, so I haven't done much with this package of late. > > > > tpb upstream had been dead for a long time, but there is some activity > > now this year. > > > > Would anyone care to take over tpb? Or does anyone even use it these > > days? Perhaps we can just drop it? > > > > Let me know and I will be happy to release it... > > We use them at work. I'll take it if no one else speaks up. > I've been using it, but it's gotten a bit quirky with some of the infrastructure changes that have been occurring. I'd like to see it updated and maintained, but I don't have the skills to do it myself. I'm happy to help test, tough. -- Matthew Saltzman Clemson University Math Sciences mjs AT clemson DOT edu http://www.math.clemson.edu/~mjs From dennis at ausil.us Fri Sep 19 19:30:57 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 19 Sep 2008 14:30:57 -0500 Subject: mx and pyOpenSSL - Heads up to rebuild! In-Reply-To: <1221520769.23024.9.camel@PB3.Linux> References: <1221520769.23024.9.camel@PB3.Linux> Message-ID: <200809191435.19304.dennis@ausil.us> On Monday 15 September 2008 06:19:29 pm Paul wrote: > Hi, > > I've just finished building mx and pyOpenSSL for putting into rawhide as > soon as I get ACL approval for them. > > If you are a packager for one of the following, please download the mx > src.rpm and do a local build from it and then recompile your apps. This update to pyOpenSSL causes python to core dump when using the koji command line. https://bugzilla.redhat.com/show_bug.cgi?id=462807 note that koji only has a Requires on pyOpenSSL. it likely breaks plague also. it would be great if you could give us an idea of what changed between the old version at the new one. its not used at build time at all and rebuilding wont actually change anything. Dennis From mattdm at mattdm.org Fri Sep 19 20:13:29 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 19 Sep 2008 16:13:29 -0400 Subject: system-autodeath In-Reply-To: <1221798586.3057.26.camel@rosebud> References: <1221798586.3057.26.camel@rosebud> Message-ID: <20080919201329.GA8521@jadzia.bu.edu> On Fri, Sep 19, 2008 at 12:29:46AM -0400, seth vidal wrote: > A while back I mentioned a system-autodeath idea for fedora. For some > reason I had neglected it but this evening I put it together. If you > take a look it is utterly trivial and just uses cron to kill the default > route. I'm sure there are limitless ways this will not be perfect but I > think it will probably be good enough. > > http://skvidal.fedorapeople.org/system-autodeath/ > > If you can come up with any way it is broken, let me know, otherwise > I'll probably submit it for review. Looks good to me at first glance. The man page probably could use a little more explanation of the specifics of what deleting the default route does. -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs Computing & Information Technology Harvard School of Engineering & Applied Sciences From skvidal at fedoraproject.org Fri Sep 19 20:16:24 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 19 Sep 2008 16:16:24 -0400 Subject: system-autodeath In-Reply-To: <20080919201329.GA8521@jadzia.bu.edu> References: <1221798586.3057.26.camel@rosebud> <20080919201329.GA8521@jadzia.bu.edu> Message-ID: <1221855384.7388.10.camel@rosebud> On Fri, 2008-09-19 at 16:13 -0400, Matthew Miller wrote: > On Fri, Sep 19, 2008 at 12:29:46AM -0400, seth vidal wrote: > > A while back I mentioned a system-autodeath idea for fedora. For some > > reason I had neglected it but this evening I put it together. If you > > take a look it is utterly trivial and just uses cron to kill the default > > route. I'm sure there are limitless ways this will not be perfect but I > > think it will probably be good enough. > > > > http://skvidal.fedorapeople.org/system-autodeath/ > > > > If you can come up with any way it is broken, let me know, otherwise > > I'll probably submit it for review. > > Looks good to me at first glance. The man page probably could use a little > more explanation of the specifics of what deleting the default route does. > patches welcome! -sv From david at hlacik.eu Fri Sep 19 20:18:52 2008 From: david at hlacik.eu (=?ISO-8859-2?Q?David_Hl=E1=E8ik?=) Date: Fri, 19 Sep 2008 22:18:52 +0200 Subject: gtk-murrine-engine problem with Firefox Message-ID: Hello guys, I am using gtk-murrine-engine-0.53.1-2.fc9.i386 . Everything seems to works fine except Firefox . Buttons under Firefox are not correctly displayed there is a row cutting image into 2 parts (as if button ending - shadow is before it actual end) . Simple - this is bug . Is there any way to fix it? Probably setting some parameters to Firefox UI in config? Thanks! David -------------- next part -------------- An HTML attachment was scrubbed... URL: From s-t-rhbugzilla at wwwdotorg.org Fri Sep 19 20:43:02 2008 From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren) Date: Fri, 19 Sep 2008 14:43:02 -0600 (MDT) Subject: system-autodeath In-Reply-To: <1221855384.7388.10.camel@rosebud> References: <1221798586.3057.26.camel@rosebud> <20080919201329.GA8521@jadzia.bu.edu> <1221855384.7388.10.camel@rosebud> Message-ID: <1221856982.28919.TMDA@tmda.severn.wwwdotorg.org> On Fri, Sep 19, 2008 at 12:29:46AM -0400, seth vidal wrote: > A while back I mentioned a system-autodeath idea for fedora. For some > reason I had neglected it but this evening I put it together. If you > take a look it is utterly trivial and just uses cron to kill the default > route. I'm sure there are limitless ways this will not be perfect but I > think it will probably be good enough. > > http://skvidal.fedorapeople.org/system-autodeath/ > > If you can come up with any way it is broken, let me know, otherwise > I'll probably submit it for review. I forget from previous conversations - Is this intended to be part of a default install - i.e. whether somebody asks for it or not? If so, it seems broken by design to me. This and the ignore-everyone-not-using-ATI-or-Intel text console/modesetting thing is really making me seriously consider switching distros. I haven't actually looked at the implementation yet, but does it interact correctly with dhcp, NetworkManager, wifiroamd, etc. (i.e. stop those services from simply restoring the default route immediately.) From sundaram at fedoraproject.org Fri Sep 19 20:48:31 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 20 Sep 2008 02:18:31 +0530 Subject: system-autodeath In-Reply-To: <1221856982.28919.TMDA@tmda.severn.wwwdotorg.org> References: <1221798586.3057.26.camel@rosebud> <20080919201329.GA8521@jadzia.bu.edu> <1221855384.7388.10.camel@rosebud> <1221856982.28919.TMDA@tmda.severn.wwwdotorg.org> Message-ID: <48D4101F.4070109@fedoraproject.org> Stephen Warren wrote: > This and the ignore-everyone-not-using-ATI-or-Intel text > console/modesetting thing is really making me seriously consider switching > distros. It is actually ignore-proprietary-drivers-because-we-dont-have-source-code -for-them. Plymouth has a reasonable fallback as well anyway. Modesetting is getting merged upstream and not only Linux but pretty much everybody using X is going to be having it at some point. I don't think switching distributions is going to help here. Rahul From skvidal at fedoraproject.org Fri Sep 19 20:48:13 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 19 Sep 2008 16:48:13 -0400 Subject: system-autodeath In-Reply-To: <1221856982.28919.TMDA@tmda.severn.wwwdotorg.org> References: <1221798586.3057.26.camel@rosebud> <20080919201329.GA8521@jadzia.bu.edu> <1221855384.7388.10.camel@rosebud> <1221856982.28919.TMDA@tmda.severn.wwwdotorg.org> Message-ID: <1221857293.7388.12.camel@rosebud> On Fri, 2008-09-19 at 14:43 -0600, Stephen Warren wrote: > I forget from previous conversations - Is this intended to be part of a > default install - i.e. whether somebody asks for it or not? If so, it > seems broken by design to me. It is not intended to be a part of the default install. This is just a nicety for sysadmins or local-respin maintainers who would like to put a dropdead date on their releases. -sv From pemboa at gmail.com Fri Sep 19 20:50:00 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 19 Sep 2008 15:50:00 -0500 Subject: system-autodeath In-Reply-To: <1221856982.28919.TMDA@tmda.severn.wwwdotorg.org> References: <1221798586.3057.26.camel@rosebud> <20080919201329.GA8521@jadzia.bu.edu> <1221855384.7388.10.camel@rosebud> <1221856982.28919.TMDA@tmda.severn.wwwdotorg.org> Message-ID: <16de708d0809191350w286d0329hc1482edcf93e155b@mail.gmail.com> On Fri, Sep 19, 2008 at 3:43 PM, Stephen Warren wrote: > On Fri, Sep 19, 2008 at 12:29:46AM -0400, seth vidal wrote: >> A while back I mentioned a system-autodeath idea for fedora. For some >> reason I had neglected it but this evening I put it together. If you >> take a look it is utterly trivial and just uses cron to kill the > default >> route. I'm sure there are limitless ways this will not be perfect but > I >> think it will probably be good enough. >> >> http://skvidal.fedorapeople.org/system-autodeath/ >> >> If you can come up with any way it is broken, let me know, otherwise >> I'll probably submit it for review. > > I forget from previous conversations - Is this intended to be part of a > default install - i.e. whether somebody asks for it or not? If so, it > seems broken by design to me. > > This and the ignore-everyone-not-using-ATI-or-Intel text > console/modesetting thing is really making me seriously consider switching > distros. > > I haven't actually looked at the implementation yet, but does it interact > correctly with dhcp, NetworkManager, wifiroamd, etc. (i.e. stop those > services from simply restoring the default route immediately.) Seems like you need a lot more info before you express any strong view. -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From pbrobinson at gmail.com Fri Sep 19 21:20:43 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 19 Sep 2008 22:20:43 +0100 Subject: fun with metacity segfaults on rawhide eeepc In-Reply-To: <91705d080809191009u4e52a126n91b3b4ce3e0da086@mail.gmail.com> References: <5256d0b0809190816r705dafbboda1bf05843f31252@mail.gmail.com> <5256d0b0809190959o2b81b68ese04e595af340d4c8@mail.gmail.com> <91705d080809191009u4e52a126n91b3b4ce3e0da086@mail.gmail.com> Message-ID: <5256d0b0809191420g7f8972e1va44aa40d07608a76@mail.gmail.com> >>>> I installed rawhide on an asus eeepc 901 last night... can't say its >>>> been the most enjoyable experience. >>>> >>>> But the big issue I'm seeing which is basically making X unusable >>>> seems to be because metacity is segfaulting (details below). >>> >>> Hi, please see: >>> >>> http://fedoraproject.org/wiki/StackTraces >>> >>> And file a bug against metacity with the associated trace. >>> >>> (Someday we will finish http://fedoraproject.org/wiki/CrashHandling >>> and this manual work will not be necessary) >> >> OK, I can install debug packages and log tickets without issue but I >> have no idea given that its crashing as I login through GDM I have no >> idea how I'd add GDB to that. > > Go to the console and run it through startx. You can just invoke > metacity as your regular window manager. > > echo xterm > ~/.xinitrc > > Then from the fresh xterm, you can run metacity through gdb. Maybe it > won't be triggered, though, unless you run a full gnome-session. > > Matthias' suggestion might be easier, though. Maybe, so is the change it to compiz or something that doesn't break... but then that doesn't move the release forward for the better either... I was hoping for the former so I could actually use my nice new netbook, but I'll gather the useful info first... is it possible to change WM from the command line though? gconf or something? Peter From s-t-rhbugzilla at wwwdotorg.org Fri Sep 19 21:50:03 2008 From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren) Date: Fri, 19 Sep 2008 15:50:03 -0600 (MDT) Subject: system-autodeath In-Reply-To: <48D4101F.4070109@fedoraproject.org> References: <1221798586.3057.26.camel@rosebud> <20080919201329.GA8521@jadzia.bu.edu> <1221855384.7388.10.camel@rosebud> <1221856982.28919.TMDA@tmda.severn.wwwdotorg.org> <48D4101F.4070109@fedoraproject.org> Message-ID: <1221861003.30470.TMDA@tmda.severn.wwwdotorg.org> On Fri, September 19, 2008 2:48 pm, Rahul Sundaram wrote: > Stephen Warren wrote: > >> This and the ignore-everyone-not-using-ATI-or-Intel text >> console/modesetting thing is really making me seriously consider >> switching >> distros. > > It is actually > ignore-proprietary-drivers-because-we-dont-have-source-code -for-them. As pointed out by other people: What about nv and nouvea users; obviously those drivers can modeset, and the source is available. > Plymouth has a reasonable fallback as well anyway. OK. This question wasn't directly answered the last time I asked. What is the fallback? On Fri, September 19, 2008 2:50 pm, Arthur Pemberton wrote: > Seems like you need a lot more info before you express any strong view. Not really. The autodeath thing was certainly strongly advocated as part of the default install earlier in discussions. From skvidal at fedoraproject.org Fri Sep 19 21:57:34 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Fri, 19 Sep 2008 17:57:34 -0400 Subject: system-autodeath In-Reply-To: <1221861003.30470.TMDA@tmda.severn.wwwdotorg.org> References: <1221798586.3057.26.camel@rosebud> <20080919201329.GA8521@jadzia.bu.edu> <1221855384.7388.10.camel@rosebud> <1221856982.28919.TMDA@tmda.severn.wwwdotorg.org> <48D4101F.4070109@fedoraproject.org> <1221861003.30470.TMDA@tmda.severn.wwwdotorg.org> Message-ID: <1221861454.7388.17.camel@rosebud> On Fri, 2008-09-19 at 15:50 -0600, Stephen Warren wrote: > On Fri, September 19, 2008 2:50 pm, Arthur Pemberton wrote: > > Seems like you need a lot more info before you express any strong view. > > Not really. The autodeath thing was certainly strongly advocated as part > of the default install earlier in discussions. No, it wasn't. In fact I'll quote the original email I sent on aug 20th: "A friend forwarded me this blog: http://www.gdt.id.au/~gdt/blog/linux/autodeath.1024px and I wondered if it would be something to consider for fedora releases. This would NOT be as a default, but as a package you can install, if you wish, to drop the route on your box after whatever expiration date. We can set the release date in a file in the package and key from there." -sv From sundaram at fedoraproject.org Fri Sep 19 22:05:05 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 20 Sep 2008 03:35:05 +0530 Subject: system-autodeath In-Reply-To: <1221861003.30470.TMDA@tmda.severn.wwwdotorg.org> References: <1221798586.3057.26.camel@rosebud> <20080919201329.GA8521@jadzia.bu.edu> <1221855384.7388.10.camel@rosebud> <1221856982.28919.TMDA@tmda.severn.wwwdotorg.org> <48D4101F.4070109@fedoraproject.org> <1221861003.30470.TMDA@tmda.severn.wwwdotorg.org> Message-ID: <48D42211.10502@fedoraproject.org> Stephen Warren wrote: > > As pointed out by other people: What about nv and nouvea users; obviously > those drivers can modeset, and the source is available. Nv and "source available" is kind of a stretch from what I heard, it is pretty obfuscated. Nobody seems to be working on it except Nvidia. A fair amount of the interest in Nouvea is around just purely 2D but with more clarity in the source code. Nouvea is still considered pretty experimental and a fast moving codebase. If you are using it, modesetting is probably not the thing that would be bothering you much. However Richard Hughes or David Airlie can probably give you more details on that. >> Plymouth has a reasonable fallback as well anyway. > > OK. This question wasn't directly answered the last time I asked. What is > the fallback? Wouldn't it be better to know about that before criticizing? http://fedoraproject.org/wiki/Releases/FeatureBetterStartup " Plymouth, that starts earlier (even before / is mounted!), doesn't require an X server, and gets rid of a lot of the noise during startup. Plymouth will requires DRM kernel modesetting drivers to get pretty graphics, but will have a text mode fallback for systems without driver support." Rahul From mschwendt at gmail.com Fri Sep 19 22:06:46 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Sat, 20 Sep 2008 00:06:46 +0200 Subject: mx and pyOpenSSL - Heads up to rebuild! In-Reply-To: <200809191435.19304.dennis@ausil.us> References: <1221520769.23024.9.camel@PB3.Linux> <200809191435.19304.dennis@ausil.us> Message-ID: <20080920000646.da9f828c.mschwendt@gmail.com> On Fri, 19 Sep 2008 14:30:57 -0500, Dennis Gilmore wrote: > On Monday 15 September 2008 06:19:29 pm Paul wrote: > > Hi, > > > > I've just finished building mx and pyOpenSSL for putting into rawhide as > > soon as I get ACL approval for them. > > > > If you are a packager for one of the following, please download the mx > > src.rpm and do a local build from it and then recompile your apps. > > This update to pyOpenSSL causes python to core dump when using the koji > command line. > https://bugzilla.redhat.com/show_bug.cgi?id=462807 > > note that koji only has a Requires on pyOpenSSL. it likely breaks plague > also. it would be great if you could give us an idea of what changed between > the old version at the new one. its not used at build time at all and > rebuilding wont actually change anything. IMO, the pyOpenSSL-0.7-threadsafe.patch looks broken, since it adds duplicate code that conflicts with the changes between pyOpenSSL 0.6 and 0.7 in context.c From janina at rednote.net Fri Sep 19 22:15:58 2008 From: janina at rednote.net (Janina Sajka) Date: Fri, 19 Sep 2008 18:15:58 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <20080912202813.GL6092@nb.net.home> <20080912203036.GN32741@angus.ind.WPI.EDU> <20080913015752.GB4421@sonata.rednote.net> <544eb990809171106q4f1aa298ucf67fc99914a6376@mail.gmail.com> Message-ID: <20080919221558.GF5290@sonata.rednote.net> Colin Walters writes: > On Wed, Sep 17, 2008 at 2:06 PM, Bill Crawford > wrote: > > On 13/09/2008, Colin Walters wrote: > > > >> I just tried this too with GDM, and got speech too. I right clicked > >> in the lower left of the screen, checked the "Read text" option, and > >> moused over and heard sound. Have you filed a bug about this issue? > > > > Good grief. You're actually telling people who NEED A SCREEN READER to > > right click and read the text (which might be too small)?? > > No. I followed up with a post about how this can be enabled by > default, and there is a keybinding as well. > Except that the key combo doesn't work. And, it seems Matthias now agrees there's a bug re the availability of pulse audio: https://bugzilla.redhat.com/show_bug.cgi?id=462537 Janina > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Janina Sajka, Phone: +1.202.595.7777; sip:janina at a11y.org Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada Learn more at http://ScreenlessPhone.Com Chair, Open Accessibility janina at a11y.org Linux Foundation http://a11y.org From pemboa at gmail.com Fri Sep 19 22:20:37 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 19 Sep 2008 17:20:37 -0500 Subject: system-autodeath In-Reply-To: <48D42211.10502@fedoraproject.org> References: <1221798586.3057.26.camel@rosebud> <20080919201329.GA8521@jadzia.bu.edu> <1221855384.7388.10.camel@rosebud> <1221856982.28919.TMDA@tmda.severn.wwwdotorg.org> <48D4101F.4070109@fedoraproject.org> <1221861003.30470.TMDA@tmda.severn.wwwdotorg.org> <48D42211.10502@fedoraproject.org> Message-ID: <16de708d0809191520m7f5adcfct56f4209193eefb98@mail.gmail.com> On Fri, Sep 19, 2008 at 5:05 PM, Rahul Sundaram wrote: > Stephen Warren wrote: > >> >> As pointed out by other people: What about nv and nouvea users; obviously >> those drivers can modeset, and the source is available. > > Nv and "source available" is kind of a stretch from what I heard, it is > pretty obfuscated. Nobody seems to be working on it except Nvidia. A fair > amount of the interest in Nouvea is around just purely 2D but with more > clarity in the source code. Nouvea is still considered pretty experimental > and a fast moving codebase. If you are using it, modesetting is probably not > the thing that would be bothering you much. However Richard Hughes or David > Airlie can probably give you more details on that. > >>> Plymouth has a reasonable fallback as well anyway. >> >> OK. This question wasn't directly answered the last time I asked. What is >> the fallback? > > Wouldn't it be better to know about that before criticizing? > > http://fedoraproject.org/wiki/Releases/FeatureBetterStartup > > " Plymouth, that starts earlier (even before / is mounted!), doesn't require > an X server, and gets rid of a lot of the noise during startup. > > Plymouth will requires DRM kernel modesetting drivers to get pretty > graphics, but will have a text mode fallback for systems without driver > support." > If anyone else was like me wondering "DRM??", in this context it means "Direct Rendering Modules" -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From bernie at codewiz.org Sat Sep 20 00:13:07 2008 From: bernie at codewiz.org (Bernie Innocenti) Date: Sat, 20 Sep 2008 02:13:07 +0200 Subject: No more MAKEDEV? In-Reply-To: <20080919004112.GB8478@nostromo.devel.redhat.com> References: <20080919004112.GB8478@nostromo.devel.redhat.com> Message-ID: <48D44013.1010609@codewiz.org> Bill Nottingham wrote: > The only user of it in Fedora is udev, which uses it for entries in > /etc/udev/makedev.d. However, there's an already-upstream solution > of putting device nodes in /lib/udev/devices. Why not just use this, > remove MAKEDEV, simplify start_udev, and boot faster? Another subtle source of inefficiency at boot time comes from the 64 hard-coded number virtual terminals in the kernel (tty0 to tty63). It's particularly annoying for embedded systems because the kernel preallocates various data structures according to this value. The majority of udev's debug output on small systems originates from tty initialization, although it may take very little time in practice. Moreover, console-kit-daemon needs to create 64 threads because the VT_WAITACTIVE ioctl is blocking as someone suggested yesterday on #fedora-devel. It may be a big waste of resources, but it makes us look bad in the face of Linux haters :-) Fixing such an ancient kernel/userland interface without breaking dozens of legaciy tools would be an interesting challenge. -- \___/ Bernie Innocenti - http://www.codewiz.org/ _| X | Sugar Labs Team - http://www.sugarlabs.org/ \|_O_| "It's an education project, not a laptop project!" From arjan at infradead.org Sat Sep 20 00:28:51 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Fri, 19 Sep 2008 17:28:51 -0700 Subject: No more MAKEDEV? In-Reply-To: <20080919004112.GB8478@nostromo.devel.redhat.com> References: <20080919004112.GB8478@nostromo.devel.redhat.com> Message-ID: <20080919172851.31cfd30a@infradead.org> On Thu, 18 Sep 2008 17:41:12 -0700 Bill Nottingham wrote: > Looking at some of the inefficiencies in bootup (in regards to the 5 > second Fedora boot), we came across MAKEDEV. To be short - it's a pig. > > The only user of it in Fedora is udev, which uses it for entries in > /etc/udev/makedev.d. However, there's an already-upstream solution > of putting device nodes in /lib/udev/devices. Why not just use this, > remove MAKEDEV, simplify start_udev, and boot faster? this btw can be done in two steps; Step 1) Put the standard static device nodes in /lib/udev/devices Step 2) Once MAKEDEV no longer is used as a result, obsolete it Step 1) is obviously simple and can be done with no risk ... and will in practice make MAKEDEV unused and gives you the boottime gain Step 2) can be done later... to make people who guard freezes less nervous -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org From mark.bidewell at alumni.clemson.edu Sat Sep 20 00:43:15 2008 From: mark.bidewell at alumni.clemson.edu (Mark Bidewell) Date: Fri, 19 Sep 2008 20:43:15 -0400 Subject: Possible Major bug in X.org update Message-ID: I just updated my F9 system and when I restarted my box, my USB keyboard will not work. It works under console mode and my USB mouse continues to work. This is a major issue (for me at least) due to the fact that I have no PS/2 ports and this makes Fedora unusable. Mark Bidewell -------------- next part -------------- An HTML attachment was scrubbed... URL: From dr.diesel at gmail.com Sat Sep 20 00:45:46 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 19 Sep 2008 20:45:46 -0400 Subject: Possible Major bug in X.org update In-Reply-To: References: Message-ID: <2a28d2ab0809191745ja18a39bm951fb0efc147f05c@mail.gmail.com> 2008/9/19 Mark Bidewell > I just updated my F9 system and when I restarted my box, my USB keyboard > will not work. It works under console mode and my USB mouse continues to > work. This is a major issue (for me at least) due to the fact that I have > no PS/2 ports and this makes Fedora unusable. > > Mark Bidewell > Same here with a PS2 via a KVM switch. Ran system-config-keyboard and all was fine.... -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedoraproject at cyberpear.com Sat Sep 20 00:50:05 2008 From: fedoraproject at cyberpear.com (James Cassell) Date: Fri, 19 Sep 2008 20:50:05 -0400 Subject: Possible Major bug in X.org update In-Reply-To: References: Message-ID: https://admin.fedoraproject.org/updates/xorg-x11-server-1.5.0-2.fc9 says it fixes a keyboard problem On Fri, 19 Sep 2008 20:43:15 -0400, Mark Bidewell wrote: > I just updated my F9 system and when I restarted my box, my USB keyboard > will not work. It works under console mode and my USB mouse continues to > work. This is a major issue (for me at least) due to the fact that I > have > no PS/2 ports and this makes Fedora unusable. > > Mark Bidewell From fedoraproject at cyberpear.com Sat Sep 20 00:50:05 2008 From: fedoraproject at cyberpear.com (James Cassell) Date: Fri, 19 Sep 2008 20:50:05 -0400 Subject: Possible Major bug in X.org update In-Reply-To: References: Message-ID: https://admin.fedoraproject.org/updates/xorg-x11-server-1.5.0-2.fc9 says it fixes a keyboard problem On Fri, 19 Sep 2008 20:43:15 -0400, Mark Bidewell wrote: > I just updated my F9 system and when I restarted my box, my USB keyboard > will not work. It works under console mode and my USB mouse continues to > work. This is a major issue (for me at least) due to the fact that I > have > no PS/2 ports and this makes Fedora unusable. > > Mark Bidewell From gmaxwell at gmail.com Sat Sep 20 02:30:03 2008 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Fri, 19 Sep 2008 22:30:03 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <1221832789.3433.33.camel@ignacio.lan> References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> Message-ID: 2008/9/19 Ignacio Vazquez-Abrams : [snip] > 1) Regulatory issues > > Hardware vendors need to prevent end-users from modifying the firmware > so that the hardware can not be driven outside legal ranges. This doesn't actually work: I've modified the binary firmware of a popular wireless card to force the card below the 2.4 GHz ISM allocation. (As an amateur radio operator I'm legally authorized to do so in any case, but the firmware is an ineffective measure and to whatever limited extent that it is effective it interferes with what I'm legally permitted to do, likewise it often forces incorrect operation in other regulatory domains) In the US at least the requirement for FCC type certification is that you demonstrate your device will not operate in a way which does not conform with the regulations and can not be trivially modified to do so. Since this will be re-occuring problem for free software we should be making an effort for the FCC to accept that needing to recompile source is roughly equal to binary firmware in terms of its (in)effectiveness for this purpose. The position I'd take to a manufacturer is "help us convince the FCC that source is sufficient, or we'll convince the FCC that firmware is not". For ISM band devices (WiFi, bluetooth, etc) manufacturers can *always* ensure regulatory compliance by including an appropriate hardware bandpass filter (which should also making the device less noisy and less subject to interference, i.e. better. But it adds cost). For some other devices (cellular modems) the exact behavior of the MAC may also be relevant for regulatory compliance. These couldn't be solved with the addition of a better bandpass filter but I've never seen one where the code wasn't in ROM. There is a lurking BiggerQuestion(tm) here: What happens when someone decides that things like with-source PDF readers are not in compliance with the law because they can be modified to ignore "do not print", "do not modify" bits? US Law [17 USC 12 ? 1201(k)(1)(a)] already forbids the trafficking of certain classes of hardware which to not play along with certain copy control schemes, it would not be surprising to see future legislation extend similar requirement to software which would be fundamentally and irreconcilably incompatible with the terms of the GPL (v3 at least). The knowledge of how to address regulatory incompatibilities with free software is a skill our communities will need for the future, so we should learn it now while it's less urgent. > 2) Intellectual "Property" issues > Hardware vendors don't want other hardware vendors to know how they run > their hardware so that their design can't be copied or stolen. Other people pointed it out already, this reason just sucks. I don't fault you for saying it, because it is true but Fedora does not ship proprietary applications, and the exact same reasoning would apply. > 3) Inability to build > > Firmware is usually code for some PLD or ASIC, which needs specialized > (and EXPENSIVE) compilers to build. Most people are unlikely to be able > to turn the source into the firmware. 'usually'? No. As far as I can tell much of the actual firmware (rather than simple arrays of registers) is code for various micro-controllers. In most cases it was probably coded in C or the relevant assembly. (ASIC's are only programmable if they implement there own microcode engine, and it might well be that there is no source) I do not doubt that there are a few CPLD and FPGA images out there, I know of one FPGA image in alsa-firmware. FPGA images will almost always be sourced from verilog or VHDL. Both are widely known languages. There are zero-cost commercial grade tools for compiling this stuff. Fedora ships packages which have verilog and vhdl in their source (GNURadio, for example). (Other people already made good arguments that source is useful even in a read-only context, etc) I think it would be very useful to classify all the various bits of binary firmware and identify what it is, why the source is not available, etc. Even if none of it is removed. If someone begins work on such a project please ping me. From joshuacov at googlemail.com Sat Sep 20 04:18:37 2008 From: joshuacov at googlemail.com (Joshua C.) Date: Sat, 20 Sep 2008 06:18:37 +0200 Subject: modesetting feature status In-Reply-To: <20080919184502.GA4545@yoda.jdub.homelinux.org> References: <5f6f8c5f0809111209o1d28bae4p246d699f3520c40@mail.gmail.com> <5f6f8c5f0809120305y41ac861fq8a91d1547519a955@mail.gmail.com> <5f6f8c5f0809171136lb722a87taee2cbd5afc2ff29@mail.gmail.com> <1221683977.15981.223.camel@atropine.boston.devel.redhat.com> <48D1D978.7020102@shmuelhome.mine.nu> <3da3b5b40809180036o33ad4e27h328ba1740bf03ade@mail.gmail.com> <48D2070C.7010508@fedoraproject.org> <5f6f8c5f0809191057m23688c2by287052700b94312b@mail.gmail.com> <20080919184502.GA4545@yoda.jdub.homelinux.org> Message-ID: <5f6f8c5f0809192118r6d3df87au3193b000296b4099@mail.gmail.com> 2008/9/19 Josh Boyer : > On Fri, Sep 19, 2008 at 07:57:34PM +0200, Joshua C. wrote: >>I tried `strace -o /drm.strace modprobe drm debug=1` and got the >>output in the attached file. I tried the same with `strace -o >>/radeon.trace modprobe radeon modeset=1` but this time there's nothing >>in the file. How can I hook strace to the radeon driver? > > You can't. All you're stracing is the modprobe command, not the driver > operation. > > Drivers don't operate in userspace, and don't make system calls. So strace > just plain doesn't work. > > josh Ok, I cannot use ssh (just one mashine). What other options do I have to debug this thing? There should be a way to do this with just one computer. I read somewhere that the 2.6.26 kernel have some "new debugger" or so. I just need to make it write down the process to a file. After restart I can send you the log. After the drive loads I can only hard reset the computer. And if everything is in the ram, then I have to dump it to a file. Any other ideas? From mcepl at redhat.com Sat Sep 20 06:30:15 2008 From: mcepl at redhat.com (Matej Cepl) Date: Sat, 20 Sep 2008 08:30:15 +0200 Subject: modesetting feature status References: <1221117521.22241.36.camel@clockmaker.usersys.redhat.com> <1221145599.11745.3.camel@aglarond.local> <1221152956.4345.17.camel@atropine.boston.devel.redhat.com> <1221155164.11745.13.camel@aglarond.local> <5f6f8c5f0809111209o1d28bae4p246d699f3520c40@mail.gmail.com> <1221174980.30676.10.camel@optimus> <5f6f8c5f0809120305y41ac861fq8a91d1547519a955@mail.gmail.com> <5f6f8c5f0809171136lb722a87taee2cbd5afc2ff29@mail.gmail.com> <1221683977.15981.223.camel@atropine.boston.devel.redhat.com> <48D1D978.7020102@shmuelhome.mine.nu> <3da3b5b40809180036o33ad4e27h328ba1740bf03ade@mail.gmail.com> <48D2070C.7010508@fedoraproject.org> Message-ID: On 2008-09-18, 09:18 GMT, Nicolas Mailhot wrote: > That still leaves the question of nv and nouveau users open. http://permalink.gmane.org/gmane.linux.redhat.fedora.devel/92772 Mat?j From hughsient at gmail.com Sat Sep 20 07:51:36 2008 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 20 Sep 2008 08:51:36 +0100 Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <45771.198.175.55.5.1221843217.squirrel@mail.jcomserv.net> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221787714.3433.5.camel@ignacio.lan> <20080919104020.3958c1c5@ohm.scrye.com> <1221842915.5524.5.camel@hughsie-work> <45771.198.175.55.5.1221843217.squirrel@mail.jcomserv.net> Message-ID: <1221897096.3208.0.camel@hughsie-work> On Fri, 2008-09-19 at 11:53 -0500, Jon Ciesla wrote: > That would be ideal. Are we to that point currently? I think so. Richard. From hughsient at gmail.com Sat Sep 20 07:56:53 2008 From: hughsient at gmail.com (Richard Hughes) Date: Sat, 20 Sep 2008 08:56:53 +0100 Subject: system-autodeath In-Reply-To: <48D42211.10502@fedoraproject.org> References: <1221798586.3057.26.camel@rosebud> <20080919201329.GA8521@jadzia.bu.edu> <1221855384.7388.10.camel@rosebud> <1221856982.28919.TMDA@tmda.severn.wwwdotorg.org> <48D4101F.4070109@fedoraproject.org> <1221861003.30470.TMDA@tmda.severn.wwwdotorg.org> <48D42211.10502@fedoraproject.org> Message-ID: <1221897413.3208.5.camel@hughsie-work> On Sat, 2008-09-20 at 03:35 +0530, Rahul Sundaram wrote: > If you are using it, > modesetting is probably not the thing that would be bothering you > much. > However Richard Hughes or David Airlie can probably give you more > details on that. 2D nouveau works great on all the laptops I can throw at it. It does support xrandr really well, but doesn't support kernel modesetting yet, although Maarten Maathuis is working on it very quickly. Don't even try 3D yet. It does work, but only if the moon is waxing, and your pet cat is called Oliver. Richard. From email.ahmedkamal at googlemail.com Sat Sep 20 08:38:05 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Sat, 20 Sep 2008 10:38:05 +0200 Subject: Xorg wrong colors after resume Message-ID: <3da3b5b40809200138k146ac196t3505611a1be81b93@mail.gmail.com> Hi This seems to be a potential bug with Xorg, but I can't begin to describe it to search bz for it! Basically after resuming my laptop from suspend-to-ram (which works nicely btw :) I always get wrong colors when watching video. Wrong colors mean that anything "reddish" in the movie would look more "greenish", actors look like green aliens ;) I noticed with mplayer this effect happens only with the default video out module of Xv (x-video), however, if I switch output to x11 (x11-shm) the colors are normal again. I am using the closed nvidia drivers, with latest F9 everything. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From rawhide at fedoraproject.org Sat Sep 20 10:24:43 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sat, 20 Sep 2008 10:24:43 +0000 (UTC) Subject: rawhide report: 20080920 changes Message-ID: <20080920102443.471BC1F825F@releng2.fedora.phx.redhat.com> New package anaconda-yum-plugins Installation-related yum plugins Updated Packages: anaconda-11.4.1.37-1 -------------------- * Fri Sep 19 18:00:00 2008 Chris Lumens - 11.4.1.37-1 - Set the filename on the traceback when we upload it (wwoods). - Don't worry about errors looking up protected partitions on upgrades. (clumens) - Fix test for allowing the installation source to be on the root fs (#462769). (clumens) - lang-names should really only depend on lang-table (katzj) - Don't make the .desktop file unless we actually need to (katzj) - Fix lang-name generation (katzj) - Look for xrandr in the search path. (clumens) - Make the textw network screen match the iw interface by only prompting for hostname (#462592) (dcantrell) - Pick up hostname if we have it, otherwise use localhost.localdomain (#461933) (dcantrell) - dhclient-script not needed for NetworkManager (dcantrell) - Add getDefaultHostname() to network.py (dcantrel) - Write out NETMASK and BROADCAST correctly in loader. (dcantrel) - Fix problems with manual network configuration in loader. (dcantrel) - anaconda-yum-plugins is now in its own source repo. (clumens) - Remove most of the network configuration from text mode as well (#462691). (clumens) - Add an extra newline to the empty partition table message. (clumens) - Fixup DiskSet._askForLabelPermission() (markmc) Summary: Added Packages: 1 Removed Packages: 0 Modified Packages: 1 Broken deps for i386 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.i386 requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so Broken deps for x86_64 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.x86_64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.ppc requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so Broken deps for ppc64 ---------------------------------------------------------- eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave livecd-tools-018-1.fc10.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.ppc64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) From opensource at till.name Sat Sep 20 10:15:59 2008 From: opensource at till.name (Till Maas) Date: Sat, 20 Sep 2008 12:15:59 +0200 Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <45771.198.175.55.5.1221843217.squirrel@mail.jcomserv.net> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221842915.5524.5.camel@hughsie-work> <45771.198.175.55.5.1221843217.squirrel@mail.jcomserv.net> Message-ID: <200809201216.09552.opensource@till.name> On Fri September 19 2008, Jon Ciesla wrote: > > On Fri, 2008-09-19 at 10:40 -0600, Kevin Fenzi wrote: > >> Would anyone care to take over tpb? Or does anyone even use it these > >> days? Perhaps we can just drop it? > > > > Vendor specific daemons such as tpb have been on the way out since we've > > been moving the userspace bodges down into proper kernel frameworks. > > > > ThinkPads, just like any other model, should "just work" without any > > special daemons installed. > > That would be ideal. Are we to that point currently? If so, I vote let > it EOL. I just noticed, that tpb also provides a nice OSD, e.g. for the volume. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jwboyer at gmail.com Sat Sep 20 12:24:42 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 20 Sep 2008 08:24:42 -0400 Subject: modesetting feature status In-Reply-To: <5f6f8c5f0809192118r6d3df87au3193b000296b4099@mail.gmail.com> References: <5f6f8c5f0809120305y41ac861fq8a91d1547519a955@mail.gmail.com> <5f6f8c5f0809171136lb722a87taee2cbd5afc2ff29@mail.gmail.com> <1221683977.15981.223.camel@atropine.boston.devel.redhat.com> <48D1D978.7020102@shmuelhome.mine.nu> <3da3b5b40809180036o33ad4e27h328ba1740bf03ade@mail.gmail.com> <48D2070C.7010508@fedoraproject.org> <5f6f8c5f0809191057m23688c2by287052700b94312b@mail.gmail.com> <20080919184502.GA4545@yoda.jdub.homelinux.org> <5f6f8c5f0809192118r6d3df87au3193b000296b4099@mail.gmail.com> Message-ID: <20080920122442.GA3401@vader.jdub.homelinux.org> On Sat, Sep 20, 2008 at 06:18:37AM +0200, Joshua C. wrote: >Ok, I cannot use ssh (just one mashine). What other options do I have >to debug this thing? There should be a way to do this with just one >computer. >I read somewhere that the 2.6.26 kernel have some "new debugger" or >so. I just need to make it write down the process to a file. After >restart I can send you the log. >After the drive loads I can only hard reset the computer. And if >everything is in the ram, then I have to dump it to a file. Any other >ideas? See bug 460644. That has a list of steps you can do to get debug output. At this point though, Dave is working with the AMD folks to play hunt the bug. The best thing you can probably do is just try new kernel builds from koji. josh From dr.diesel at gmail.com Sat Sep 20 13:33:36 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Sat, 20 Sep 2008 09:33:36 -0400 Subject: [Bug 456515] New: Dragging Files via NFS share moves instead of copy In-Reply-To: References: Message-ID: <2a28d2ab0809200633u1866755ehc82741c63e576658@mail.gmail.com> https://bugzilla.redhat.com/show_bug.cgi?id=456515 Summary: Dragging Files via NFS share moves instead of copy Product: Fedora Version: 9 Platform: i386 OS/Version: Linux Status: NEW Severity: low Priority: low Component: nautilus AssignedTo: tbzatek at redhat.com ReportedBy: dr.diesel at gmail.com QAContact: extras-qa at fedoraproject.org CC: tbzatek at redhat.com Description of problem: Server machine is F6, client is F9. When I drag a file from the server to client it moves the files instead of copying? If I move it back from the client to the server is copies instead of moving? Version-Release number of selected component (if applicable): Client F9 Stable, all updates current. Server F6. How reproducible: Everytime Steps to Reproduce: 1. Setup Client/Server NFS Share 2. Drag files in Gnome from server to client Actual results: >From server to client files are moved not copied. From client to server files are copied. Expected results: In both cased files should be copied and not moved. Additional info: Any thoughts on this? I'd consider it a major bug due to the possibility of lost data. This bug was written on a F9 box, but I couldn't find any evidence it was fixed in Rawhide. Thanks Andy -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From bruno at wolff.to Sat Sep 20 14:42:26 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 20 Sep 2008 09:42:26 -0500 Subject: Fedora not "free" enough for GNU? In-Reply-To: <1221832789.3433.33.camel@ignacio.lan> References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> Message-ID: <20080920144226.GA4631@wolff.to> On Fri, Sep 19, 2008 at 09:59:49 -0400, Ignacio Vazquez-Abrams wrote: > > 2) Intellectual "Property" issues > > Hardware vendors don't want other hardware vendors to know how they run > their hardware so that their design can't be copied or stolen. You mean that hardware vendors don't want their competitors to see how they are doing things because they may be violating one of their competitors' patents and having the source out their makes it easier for their competitors to see this. From lsof at nodata.co.uk Sat Sep 20 15:26:39 2008 From: lsof at nodata.co.uk (nodata) Date: Sat, 20 Sep 2008 17:26:39 +0200 Subject: system-autodeath In-Reply-To: <1221798586.3057.26.camel@rosebud> References: <1221798586.3057.26.camel@rosebud> Message-ID: <1221924399.2909.7.camel@sb-home> Am Freitag, den 19.09.2008, 00:29 -0400 schrieb seth vidal: > A while back I mentioned a system-autodeath idea for fedora. For some > reason I had neglected it but this evening I put it together. If you > take a look it is utterly trivial and just uses cron to kill the default > route. I'm sure there are limitless ways this will not be perfect but I > think it will probably be good enough. > > http://skvidal.fedorapeople.org/system-autodeath/ > > If you can come up with any way it is broken, let me know, otherwise > I'll probably submit it for review. > > > Thanks, > -sv > > -- > I only speak for me. > Do you log a message to all consoles when this happens? From mike at miketc.net Sat Sep 20 15:40:24 2008 From: mike at miketc.net (Mike Chambers) Date: Sat, 20 Sep 2008 10:40:24 -0500 Subject: rawhide report: 20080920 changes In-Reply-To: <20080920102443.471BC1F825F@releng2.fedora.phx.redhat.com> References: <20080920102443.471BC1F825F@releng2.fedora.phx.redhat.com> Message-ID: <1221925224.2805.6.camel@scrappy.miketc.net> On Sat, 2008-09-20 at 10:24 +0000, Rawhide Report wrote: > anaconda-11.4.1.37-1 > -------------------- > * Fri Sep 19 18:00:00 2008 Chris Lumens - 11.4.1.37-1 > - lang-names should really only depend on lang-table (katzj) > - Don't make the .desktop file unless we actually need to (katzj) > - Fix lang-name generation (katzj) Don't know what the problem was above, but as of today when trying an nfs install, the Language Screen doesn't show any languages at all (as in screen is empty), and when going ahead and trying to click Next button anyway, it gets an exception and have to exit the installer. (Ugh, haven't really been able to install rawhide since the Alpha version (obviously the intrusion thing caused some constraints) and sort of sucks cause I like running Rawhide most of the time. Anyway, the new look and such is looking better, so keep pounding away and await another fix/solution. -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From ssorce at redhat.com Sat Sep 20 16:21:36 2008 From: ssorce at redhat.com (Simo Sorce) Date: Sat, 20 Sep 2008 16:21:36 +0000 Subject: Fedora not "free" enough for GNU? In-Reply-To: <20080920144226.GA4631@wolff.to> References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> <1221610622.6574.3.camel@localhost.localdomain> <48D04F43.30900@fedoraproject.org> <91157db90809170650w1acb8541sbba9f513ee20d1ca@mail.gmail.com> <48D137C2.3030801@fedoraproject.org> <91157db90809180558j37db259bwad62aedd96b668a9@mail.gmail.com> <1221832789.3433.33.camel@ignacio.lan> <20080920144226.GA4631@wolff.to> Message-ID: <1221927696.6455.32.camel@localhost.localdomain> On Sat, 2008-09-20 at 09:42 -0500, Bruno Wolff III wrote: > On Fri, Sep 19, 2008 at 09:59:49 -0400, > Ignacio Vazquez-Abrams wrote: > > > > 2) Intellectual "Property" issues > > > > Hardware vendors don't want other hardware vendors to know how they run > > their hardware so that their design can't be copied or stolen. > > You mean that hardware vendors don't want their competitors to see how they > are doing things because they may be violating one of their competitors' > patents and having the source out their makes it easier for their competitors > to see this. Maybe for ASICs, but for all the firmware for ARM and MIPS processors, where it is easy to disassemble the code, this line of reasoning really does not hold. It is as easy for a competitor to disassemble and see what's going on than it is for anyone else. In these cases holding the source has nothing to do with preventing competition from hardware makers. Except, maybe, as a way to delay competitors. But if this is the point then a delayed release of the source (1 year later) would work as well, by the time you release it, you are probably already working on the next generation and you do not loose much. It might be a way to respect/fool regulations as in the radio transmission case, but in all other cases I think there are ample margins to teach the benefit of openness and push these people to release the source in whatever form it is as soon as possible. Simo. -- Simo Sorce * Red Hat, Inc * New York From seg at haxxed.com Sat Sep 20 17:26:49 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 20 Sep 2008 12:26:49 -0500 Subject: MinGW In-Reply-To: <20080910150226.GA14299@amd.home.annexia.org> References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> Message-ID: <1221931609.4837.17.camel@localhost.localdomain> On Wed, 2008-09-10 at 16:02 +0100, Richard W.M. Jones wrote: > On Wed, Sep 10, 2008 at 10:03:07AM -0400, Josh Boyer wrote: > > Can you comment on what part of his draft you find objectionable? > > Specifically three things: > > (1) It imposes upon us the need to use a separate repository, which is > based on the false assumption that we will be rebuilding a substantial > proportion of all Fedora packages, like some sort of secondary > architecture. > > In reality this is not the case - we only wish to rebuild a few common > libraries. Secondary architectures rebuild every package, including > applications, which we have no intention of doing even if it were > possible (which it isn't). I think all this arguing about "number of packages" is a red herring. This all smacks of misguided political compromise where pointless obstructions are put in place in an attempt to appeal to both sides. This kind of bullshit has no place in an engineering organization. If we could point to a repo overflowing with mingw packages, there might be a point to this. But right now it's purely "oh there might be a lot of them!" which is not sound engineering practice, it's hypothetical bullshitty handwaving. Either we commit 100% to having a Win32 toolchain in Fedora or we don't bother. No compromises. > (2) "All packages must first be natively available in Fedora before > they can be in the MinGW repo" > > This is a considerable restriction. A useful Windows cross- > development environment must include packages like NSIS installer, GNU > gettext and PortableXDR, none of which would make sense as standalone > Fedora packages. It's another pointless obstruction. If a cross-package meets licensing guidelines, why is it not be acceptable? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From fedora at leemhuis.info Sat Sep 20 18:36:25 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 20 Sep 2008 20:36:25 +0200 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? Message-ID: <48D542A9.1070600@leemhuis.info> Hi all! I recently created comps.xml files for RPM Fusion. During that a few things around comps.xml got discussed on the RPM Fusion lists(?). That and a recent change (?) to https://fedoraproject.org/wiki/PackageMaintainers/CompsXml made me wonder: How important is comps.xml to us these days? (Note that I mean Fedora and RPM Fusion with "us" here, as RPM Fusion for things like this just follows the Fedora guidelines) Comps.xml is afaics mainly used in anaconda (and thus indirectly in tools like pungi that rely on anaconda) and yum (if you know what to do) these days; PackageKit afaics doesn't use it much (or does it use comps.xml at all? Will that change?); it just lists everything it finds afaics (correct me if I'm wrong, I'm not using PackageKit much and just use yum directly). Thus for most packages it doesn't matter much if they are missing in comps.xml -- if they are missing there they will not be able to select in anaconda during install, but that's all. Which brings me to the second question: Which packages should be in comps.xml and which not? Round about two years ago (e.g. before the merge) we IIRC for a short while mainly said and acted like this: round about everything that is not a lib (those normally get tracked in by deps when needed) or a devel package should be mentioned in comps.xml; that of course included command line apps(?). Note sure if it ever made it to the guidelines with these or similar words; likely not. These days the wiki says: > If you maintain an application which makes sense for a user to select > during installation, [...] make sure that your package is listed in a > reasonable group in the comps-fn.xml.in files. I consider the "during installation" part not much helpful because a package that seems unimportant during installation for 99% of the users might be something a few other users will look out for. Heck, some new Fedora users might even abort the Fedora install at this point if they miss a package they really plan to use with Fedora. But that is only one of the problems afaics; according to http://fedoraproject.org/wiki/PackageMaintainers/PackageStatus/CompsF10Missing there are 2866 packages in comps-f10 and 1711 packages missing (seems the SRPMS are used as a base here; I'm wondering if using RPMs might be more wise, but that is just one more thing to discuss); some of those 1711 really are in fedora for quite a while and really look to me like worthwhile mentioning in comps.xml (see above), to make sure people can find and select them right during install with anaconda. Do we care? Cu knurd (?) doesn't matter much for this discussion, but for the curious see this thread http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-September/001027.html (?) https://fedoraproject.org/w/index.php?title=PackageMaintainers%2FCompsXml&diff=49865&oldid=36786 (?) see also http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-September/001103.html From vgaburici at gmail.com Sat Sep 20 18:42:44 2008 From: vgaburici at gmail.com (Vasile Gaburici) Date: Sat, 20 Sep 2008 21:42:44 +0300 Subject: Xorg wrong colors after resume In-Reply-To: <3da3b5b40809200138k146ac196t3505611a1be81b93@mail.gmail.com> References: <3da3b5b40809200138k146ac196t3505611a1be81b93@mail.gmail.com> Message-ID: With the FOSS Radeon driver I have a somewhat similar problem, although it seldom occurs: after a resume from suspend I sometimes get "rainbow" colors in areas that are supposed to be transparent, e.g. the rounded corners of windows (using compiz). This happens too seldom and it's corrected when windows are redrawn, so it's not worth filing a bug report over it. YMMV. 2008/9/20 Ahmed Kamal : > Hi > This seems to be a potential bug with Xorg, but I can't begin to describe it > to search bz for it! Basically after resuming my laptop from suspend-to-ram > (which works nicely btw :) I always get wrong colors when watching video. > Wrong colors mean that anything "reddish" in the movie would look more > "greenish", actors look like green aliens ;) I noticed with mplayer this > effect happens only with the default video out module of Xv (x-video), > however, if I switch output to x11 (x11-shm) the colors are normal again. > I am using the closed nvidia drivers, with latest F9 everything. > Thanks > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From jmtaylor90 at gmail.com Sat Sep 20 18:46:02 2008 From: jmtaylor90 at gmail.com (Jason) Date: Sat, 20 Sep 2008 14:46:02 -0400 Subject: rawhide report: 20080920 changes In-Reply-To: <1221925224.2805.6.camel@scrappy.miketc.net> References: <20080920102443.471BC1F825F@releng2.fedora.phx.redhat.com> <1221925224.2805.6.camel@scrappy.miketc.net> Message-ID: <1221936362.11593.0.camel@bruiser.localdomain> On Sat, 2008-09-20 at 10:40 -0500, Mike Chambers wrote: > On Sat, 2008-09-20 at 10:24 +0000, Rawhide Report wrote: > > > anaconda-11.4.1.37-1 > > -------------------- > > * Fri Sep 19 18:00:00 2008 Chris Lumens - 11.4.1.37-1 > > > - lang-names should really only depend on lang-table (katzj) > > - Don't make the .desktop file unless we actually need to (katzj) > > - Fix lang-name generation (katzj) > > Don't know what the problem was above, but as of today when trying an > nfs install, the Language Screen doesn't show any languages at all (as > in screen is empty), and when going ahead and trying to click Next > button anyway, it gets an exception and have to exit the installer. > > (Ugh, haven't really been able to install rawhide since the Alpha > version (obviously the intrusion thing caused some constraints) and sort > of sucks cause I like running Rawhide most of the time. Anyway, the new > look and such is looking better, so keep pounding away and await another > fix/solution. > > -- > Mike Chambers > Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. > mikec302 at fedoraproject.org > I get the same trying an x86_64 install from boot.iso from todays (20-Sept-2008) rawhide branch.. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Sat Sep 20 18:53:53 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Sat, 20 Sep 2008 11:53:53 -0700 Subject: MinGW In-Reply-To: <1221931609.4837.17.camel@localhost.localdomain> References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> <1221931609.4837.17.camel@localhost.localdomain> Message-ID: <48D546C1.4050801@gmail.com> Callum Lerwick wrote: > On Wed, 2008-09-10 at 16:02 +0100, Richard W.M. Jones wrote: >> On Wed, Sep 10, 2008 at 10:03:07AM -0400, Josh Boyer wrote: >>> Can you comment on what part of his draft you find objectionable? >> Specifically three things: >> >> (1) It imposes upon us the need to use a separate repository, which is >> based on the false assumption that we will be rebuilding a substantial >> proportion of all Fedora packages, like some sort of secondary >> architecture. >> >> In reality this is not the case - we only wish to rebuild a few common >> libraries. Secondary architectures rebuild every package, including >> applications, which we have no intention of doing even if it were >> possible (which it isn't). > > I think all this arguing about "number of packages" is a red herring. > This all smacks of misguided political compromise where pointless > obstructions are put in place in an attempt to appeal to both sides. > This kind of bullshit has no place in an engineering organization. If we > could point to a repo overflowing with mingw packages, there might be a > point to this. But right now it's purely "oh there might be a lot of > them!" which is not sound engineering practice, it's hypothetical > bullshitty handwaving. > > Either we commit 100% to having a Win32 toolchain in Fedora or we don't > bother. No compromises. > I agree with your sentiment. I'm not certain that a separate repo is a bad thing, though... it allows mirrors to choose whether to mirror the content or not. If we're committing 100% to to having a win32 toolchain, though, we should enable the repo by default. >> (2) "All packages must first be natively available in Fedora before >> they can be in the MinGW repo" >> >> This is a considerable restriction. A useful Windows cross- >> development environment must include packages like NSIS installer, GNU >> gettext and PortableXDR, none of which would make sense as standalone >> Fedora packages. > > It's another pointless obstruction. If a cross-package meets licensing > guidelines, why is it not be acceptable? > This is one that I'm not so sure about. The theory is that there's packages which belong in a cross-compiled environment but not in Fedora. But the question is what is the definition of "belongs"? NSIS is useful for Fedora and Richard has patches to let it work to some extent here. gettext *is* in Fedora for the applications that are in the package. PortableXDR is a library that would provide functionality redundant with stuff in glibc but on the other hand we have tons of packages which provide redundant functionality in Fedora already. If someone proposed these packages be natively compiled and entered into Fedora we would welcome them. So the argument that these don't make sense as standalone packages in Fedora is not quite true. On the other hand, what we want to know is why we should impose an additional restriction on packages destined for use in a crosscompiler. Jef, care to lay out the reasons for this restriction? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From ville.skytta at iki.fi Sat Sep 20 19:13:07 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Sat, 20 Sep 2008 22:13:07 +0300 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <48D542A9.1070600@leemhuis.info> References: <48D542A9.1070600@leemhuis.info> Message-ID: <200809202213.08483.ville.skytta@iki.fi> On Saturday 20 September 2008, Thorsten Leemhuis wrote: > > If you maintain an application which makes sense for a user to select > > during installation, [...] make sure that your package is listed in a > > reasonable group in the comps-fn.xml.in files. > > I consider the "during installation" part not much helpful Not sure if you're referring to the addition of those two words, but I added them today - if I'm missing something and they make the document less correct, the change should be reverted. But I thought it'd be better that way than just "If you maintain an application which makes sense for a user to select, ..." (select when? ever?) From sundaram at fedoraproject.org Sat Sep 20 19:55:24 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sun, 21 Sep 2008 01:25:24 +0530 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <48D542A9.1070600@leemhuis.info> References: <48D542A9.1070600@leemhuis.info> Message-ID: <48D5552C.1000700@fedoraproject.org> Thorsten Leemhuis wrote: > > Comps.xml is afaics mainly used in anaconda (and thus indirectly in > tools like pungi that rely on anaconda) and yum (if you know what to do) > these days; PackageKit afaics doesn't use it much (or does it use > comps.xml at all? Will that change?); it just lists everything it finds > afaics (correct me if I'm wrong, I'm not using PackageKit much and just > use yum directly). PackageKit does use it via the yum backend. http://blogs.gnome.org/hughsie/2008/09/19/packagekit-collections/ Rahul From kevin.kofler at chello.at Sat Sep 20 20:00:51 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 20 Sep 2008 20:00:51 +0000 (UTC) Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> Message-ID: Rahul Sundaram fedoraproject.org> writes: > PackageKit does use it via the yum backend. > > http://blogs.gnome.org/hughsie/2008/09/19/packagekit-collections/ Note that this is only from 0.3.3 on. The 0.2.x version currently in Fedora 9 (and the 0.1.x version in F9 GA) just hardcode the categories, which is IMHO a bug (or "missing feature" if you prefer) in PackageKit, so I'm glad this got fixed now. For example, the hardcoded category for KDE was missing some of the stuff we list for KDE in comps, and some categories were missing entirely (e.g. KDE Software Development). Kevin Kofler From jspaleta at gmail.com Sat Sep 20 20:03:29 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 20 Sep 2008 12:03:29 -0800 Subject: MinGW In-Reply-To: <48D546C1.4050801@gmail.com> References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> <1221931609.4837.17.camel@localhost.localdomain> <48D546C1.4050801@gmail.com> Message-ID: <604aa7910809201303i565e8e60i19c63467bb3ac854@mail.gmail.com> 2008/9/20 Toshio Kuratomi : > On the other hand, what we want to know is why we should impose an > additional restriction on packages destined for use in a crosscompiler. > Jef, care to lay out the reasons for this restriction? I will answer your question with a number of other questions. How do we handle arch specific things for secondary arches right now? Do we consider things which are only found in secondary arches as exceptional circumstances which need some sort of oversight before they are allowed? Do we allow things into secondary arches which will not build in primary arches? Do we ask the following question "does this build under the primary arches?" regardless of the answer to "is this useful as a binary to ship in the primary arch repos?" Perhaps FESCo doesn't think this should be a hard requirement, but instead situations should be flagged for review and taken up by some sort of oversight group on a case-by-case basis. Or maybe FESCo disagrees completely with this and doesn't think an oversight is needed. If FESCo thinks this particular restriction is unnecessary I will defer to their decision on the matter. But if FESCo does disagree with me I'd like to see a policy statement with regard to this matter that is generally applicable to the nature of "primary-ness". How committed are we to the "primary arches".. and in what sense are they "primary." Even if it can be successfully argued that mingw payloads are not equal in scope to a full primary arch, I do not personally consider them to be part of the primary arch mandate as I understand it. If FESCo thinks they are part of the primary arch mandate, I want to see a treatise on that which details why. As to the whole on by default or not... the main thrust here is that I don't think its appropriate to mandate that this repo be turned on by default in all Spins. I think, at least for the time being. The mingw repository definition should be up to the individual Spin maintainers to have enabled or disabled by default. And even during the FESCo meeting, it was suggested that a mingw-release rpm could be included instead of defining this in the fedora-release. And you know what, that sort of makes some sense too...if these mingw packages could be cross-distro in nature. If OpenSuse made available the mingw toolset in their main repository... would they be able to make use of the same mingw payloads that are the focus of this discussion once we put them in their own repository space? I hadn't thought of that before now. If that would be a very nice secondary benefit, if our mingw SIG wanted to reach across the aisle and get OpenSuse's community to build something we could all equally use. To be clear the Board mandate itself was limited to requiring to putting these things into a separate repository structure, and not in the main repository. I've seen no discussion which would indicate this is not technical possible to do. Other things in the draft are my own thinking about how best to do that in more detail. I took Josh's request for a draft as a request for something more comprehensive than just "thou shalt put this in a separate repository" when he asked me to draft something. Please don't confuse the implementation detail suggestions with the underlying mandate. I probably could have done a better job separating the mandate from the suggestions. -jef From halfline at gmail.com Sat Sep 20 20:38:34 2008 From: halfline at gmail.com (Ray Strode) Date: Sat, 20 Sep 2008 16:38:34 -0400 Subject: fun with metacity segfaults on rawhide eeepc In-Reply-To: <5256d0b0809191420g7f8972e1va44aa40d07608a76@mail.gmail.com> References: <5256d0b0809190816r705dafbboda1bf05843f31252@mail.gmail.com> <5256d0b0809190959o2b81b68ese04e595af340d4c8@mail.gmail.com> <91705d080809191009u4e52a126n91b3b4ce3e0da086@mail.gmail.com> <5256d0b0809191420g7f8972e1va44aa40d07608a76@mail.gmail.com> Message-ID: <45abe7d80809201338j1a783ab1lb942e7bea42bd43e@mail.gmail.com> Hi, > is it possible to change WM from the command line though? gconf or something? Just run desktop-effects and click the enable button. --Ray From jwboyer at gmail.com Sat Sep 20 20:42:06 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Sat, 20 Sep 2008 16:42:06 -0400 Subject: MinGW In-Reply-To: <604aa7910809201303i565e8e60i19c63467bb3ac854@mail.gmail.com> References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> <1221931609.4837.17.camel@localhost.localdomain> <48D546C1.4050801@gmail.com> <604aa7910809201303i565e8e60i19c63467bb3ac854@mail.gmail.com> Message-ID: <20080920204206.GA3187@vader.jdub.homelinux.org> On Sat, Sep 20, 2008 at 12:03:29PM -0800, Jeff Spaleta wrote: >2008/9/20 Toshio Kuratomi : >> On the other hand, what we want to know is why we should impose an >> additional restriction on packages destined for use in a crosscompiler. >> Jef, care to lay out the reasons for this restriction? > >I will answer your question with a number of other questions. > >How do we handle arch specific things for secondary arches right now? We don't. There are no official secondary arches. (White lie). >Do we consider things which are only found in secondary arches as >exceptional circumstances which need some sort of oversight before >they are allowed? We have Exclude/Exclusive arch tracker bugs. That's it. From a CVS standpoint, everything must build out of the canonical Fedora CVS repository for all architectures. The MinGW package set would not differ from this rule either, and I have seen _no_ indication that the MinGW SIG has ever suggested otherwise. >Do we allow things into secondary arches which will not build in primary >arches? Yes. Even among "primary" arches this is allowed. >Do we ask the following question "does this build under the primary arches?" No. And we shouldn't, because if we did that we'd never have anything worthwhile for secondary arches. >regardless of the answer to "is this useful as a binary to ship in the >primary arch repos?" Nope. >Perhaps FESCo doesn't think this should be a hard requirement, but >instead situations should be flagged for review and taken up by some >sort of oversight group on a case-by-case basis. Or maybe FESCo >disagrees completely with this and doesn't think an oversight is >needed. If FESCo thinks this particular restriction is unnecessary I >will defer to their decision on the matter. But if FESCo does >disagree with me I'd like to see a policy statement with regard to >this matter that is generally applicable to the nature of >"primary-ness". How committed are we to the "primary arches".. and in >what sense are they "primary." Ok, first of all you keep making statements about secondary architectures and differences from primary architectures. An architecture, primary, secondary, or otherwise, will by nature carry packages that are exclusive to that architecture. This is a fact of life and trying to build exception clauses in for checking "primary applicability" is basically going to just add a hurdle that really doesn't need to be there. It does not _help_ anything. Secondly, you keep comparing MinGW to a secondary architecture. It is NOT. This is a (relatively) new class of support in the Fedora ecosystem. Namely, this is cross-compiling support. We have cross compilers and toolchains today. What the MinGW folks are trying to do is expand upon that and provide additional packages to ease packager/developer burden when cross compiling applications. There are certain similarities to be sure, so it is not an unreasonable jump to compare cross compiling to secondary architectures. However, I believe the scope, technical implications, and target audiences are different enough that by doing such comparison one will inevitably cloud the issues for both enough that nothing good for either will come of that. >Even if it can be successfully argued that mingw payloads are not >equal in scope to a full primary arch, I do not personally consider >them to be part of the primary arch mandate as I understand it. If >FESCo thinks they are part of the primary arch mandate, I want to see >a treatise on that which details why. What primary arch mandate? >As to the whole on by default or not... the main thrust here is that I >don't think its appropriate to mandate that this repo be turned on by >default in all Spins. I think, at least for the time being. The mingw >repository definition should be up to the individual Spin maintainers >to have enabled or disabled by default. And even during the FESCo >meeting, it was suggested that a mingw-release rpm could be included >instead of defining this in the fedora-release. And you know what, >that sort of makes some sense too...if these mingw packages could be >cross-distro in nature. If OpenSuse made available the mingw toolset >in their main repository... would they be able to make use of the same >mingw payloads that are the focus of this discussion once we put them >in their own repository space? I hadn't thought of that before now. If >that would be a very nice secondary benefit, if our mingw SIG wanted >to reach across the aisle and get OpenSuse's community to build >something we could all equally use. I don't really disagree with anything you say there, so I won't comment. >To be clear the Board mandate itself was limited to requiring to >putting these things into a separate repository structure, and not in >the main repository. I've seen no discussion which would indicate >this is not technical possible to do. Other things in the draft are >my own thinking about how best to do that in more detail. I took >Josh's request for a draft as a request for something more >comprehensive than just "thou shalt put this in a separate repository" >when he asked me to draft something. Please don't confuse the >implementation detail suggestions with the underlying mandate. I >probably could have done a better job separating the mandate from the >suggestions. I belive (and I stated as much in the FESCo meeting where we talked about this briefly), that the crux of the issue with your proposal is the "needs to build natively" item. That is the issue FESCo needs to further consider, along with the packaging guidelines that the MinGW SIG is drafting. Those are the items that require careful thought, and not just for MinGW. The draft guidelines I have seen so far have nothing overly MinGW specific about them, and _should_ be easily usable for cross-compile packages in the future as well. josh From jspaleta at gmail.com Sat Sep 20 21:07:28 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 20 Sep 2008 13:07:28 -0800 Subject: MinGW In-Reply-To: <20080920204206.GA3187@vader.jdub.homelinux.org> References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> <1221931609.4837.17.camel@localhost.localdomain> <48D546C1.4050801@gmail.com> <604aa7910809201303i565e8e60i19c63467bb3ac854@mail.gmail.com> <20080920204206.GA3187@vader.jdub.homelinux.org> Message-ID: <604aa7910809201407n3b495f52w22ba35f7b929bfd4@mail.gmail.com> On Sat, Sep 20, 2008 at 12:42 PM, Josh Boyer wrote: > I belive (and I stated as much in the FESCo meeting where we talked about > this briefly), that the crux of the issue with your proposal is the "needs > to build natively" item. That is the issue FESCo needs to further consider, > along with the packaging guidelines that the MinGW SIG is drafting. I fully accept that this issue needs thought. And your right, this cross compiling stuff is different. I'm fully aware that I'm muddying the waters with analogies to 2ndary arches. But its the only comparison my pea-sized brain is capable of finding and holding on to to as a reference point as we pilot this steam boat up river into unknown waters. Toshio asked for an explanation of my thinking...i've given it. If the reasoning doesn't make sense to anyone else, continuing to ask me to re-explain my thinking is probably not going to particularly fruitful...until we find an interpreter who is fluent in Jef-speak. -jef From rjones at redhat.com Sat Sep 20 21:38:07 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 20 Sep 2008 22:38:07 +0100 Subject: MinGW In-Reply-To: <1221931609.4837.17.camel@localhost.localdomain> References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> <1221931609.4837.17.camel@localhost.localdomain> Message-ID: <20080920213807.GA8251@amd.home.annexia.org> On Sat, Sep 20, 2008 at 12:26:49PM -0500, Callum Lerwick wrote: > I think all this arguing about "number of packages" is a red herring. > This all smacks of misguided political compromise where pointless > obstructions are put in place in an attempt to appeal to both sides. Just as background ... this is a rather old set of packages from about one and a half weeks ago, building a good selection of libraries including some big stuff like GTK. Total size is 217 MB: http://www.annexia.org/tmp/mingw/00-files.txt (Actual packages here: http://www.annexia.org/tmp/mingw/) I'm actually going to be working on this tomorrow, including new guidelines, new packages, a test repository etc. I'll post some more to this list when I have something, in a day or two. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From rjones at redhat.com Sat Sep 20 21:40:31 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Sat, 20 Sep 2008 22:40:31 +0100 Subject: MinGW In-Reply-To: <48D546C1.4050801@gmail.com> References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> <1221931609.4837.17.camel@localhost.localdomain> <48D546C1.4050801@gmail.com> Message-ID: <20080920214031.GB8251@amd.home.annexia.org> On Sat, Sep 20, 2008 at 11:53:53AM -0700, Toshio Kuratomi wrote: > NSIS is useful for Fedora and Richard has patches to let it work to > some extent here. It was mentioned on this list a few days ago that Debian have compiled a substantial part of NSIS natively now. I only managed to get some very core/basic parts. Hopefully I can use Debian's work to get a near-native NSIS, which can only be a good thing. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From seg at haxxed.com Sat Sep 20 22:53:48 2008 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 20 Sep 2008 17:53:48 -0500 Subject: Xbmc on Fedora? (fabulous mediacenter application) In-Reply-To: <64b14b300809190152o2c1ee6b4ka0a22b7cd82fd208@mail.gmail.com> References: <64b14b300809190152o2c1ee6b4ka0a22b7cd82fd208@mail.gmail.com> Message-ID: <1221951228.4837.23.camel@localhost.localdomain> On Fri, 2008-09-19 at 10:52 +0200, Valent Turkovic wrote: > The multiplatform version of XboxMediaCenter is out, but there are > only instuctions how to install it on Ubunut :( > If anybody manages to install it on Fedora please post your howto. Unless you're talking about packaging it this is somewhat off topic. And given that media codecs are a patent minefield, and XBMC does not appear to use gstreamer or xinelib, it may require significant work to make it "patent clean" enough for Fedora. Looks like it's built on top of mplayer. It also seems to bundle in all the libraries it uses. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kanarip at kanarip.com Sun Sep 21 01:25:45 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Sun, 21 Sep 2008 03:25:45 +0200 Subject: Orange Sombrero 9 Released - based on Fedora Message-ID: <48D5A299.6000908@kanarip.com> One more Software Freedom Day well spent ;-) I'm proud to announce a new minor player in the world of insignificant clones of major, important Free and Open Source Linux Distributions, *bling* Orange Sombrero - /based on Fedora/ *bling* Orange Sombrero starts with releasing version number 9 - the same version number as the upstream distribution, Fedora, to avoid confusion. Has anything been changed? Yeah, a patch to anaconda[1,2] that didn't make it in in time for the Fedora 10 Beta freeze has been applied to compose this release -which is sort of the entire use case behind the patch anyway. Also, a different branch of Revisor has been used that uses the patch to anaconda[3]. Since I've got limited bandwidth and disk space, this is a 1 CD distribution. If I had bandwidth and disk space, I might have thrown in a mid-release Everything Spin but I couldn't. Also, given that this is a 1 CD distribution, I've added an install class to anaconda so that it selects the correct groups of packages. Who needs "Office & Productivity" if there's only @core and @base, right? "Base System" FTW! It was fun, it took me 4 koji scratch builds of anaconda and another number of composes to get it "right". Note that despite these changes the installed system will behave just the same as Fedora. In fact, if you look really hard, there's the occasional "Fedora" in there, still -maybe that's because I used fedora-release, which I should be able to do without trademark violations, even though /etc/fedora-release still says "Fedora" ;-) Why bother? Trademark guidelines right now say a derivative distribution cannot use "based on Fedora" -which is bad, and Orange Sombrero is now raising some red flags about it. Work is well on it's way to improve that situation[4] though, for which I thank everyone involved. I hope soon, very soon, derivative's of Fedora pop up everywhere, like mushrooms in autumn. Where is it? http://orangesombrero.org (torrents) On behalf of the entire Orange Sombrero Community (e.g. ~1 person), Kind regards, Jeroen van Meeuwen -kanarip [1] http://tinyurl.com/49eq5n [2] http://tinyurl.com/47v38s [3] http://tinyurl.com/4le262 [4] http://tinyurl.com/6d3ykf From mattdm at mattdm.org Sun Sep 21 02:14:43 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 20 Sep 2008 22:14:43 -0400 Subject: MinGW In-Reply-To: <48D546C1.4050801@gmail.com> References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> <1221931609.4837.17.camel@localhost.localdomain> <48D546C1.4050801@gmail.com> Message-ID: <20080921021443.GA29122@jadzia.bu.edu> On Sat, Sep 20, 2008 at 11:53:53AM -0700, Toshio Kuratomi wrote: > But the question is what is the definition of "belongs"? NSIS is > useful for Fedora and Richard has patches to let it work to some extent > here. gettext *is* in Fedora for the applications that are in the +1 for NSIS in particular. I want to build and package up things for Windows without actaully ever touching it myself. Long ago, I ran it under wine (with wine's X layer turned off so it was all command-line -- you can do that) but it'd be better to have it just native in Fedora. -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs Computing & Information Technology Harvard School of Engineering & Applied Sciences From dtimms at iinet.net.au Sun Sep 21 07:12:32 2008 From: dtimms at iinet.net.au (David Timms) Date: Sun, 21 Sep 2008 17:12:32 +1000 Subject: package maintenance from multiple PCs ? Message-ID: <48D5F3E0.7050307@iinet.net.au> Hi, I've recently been trying to do package development from my notebook PC, rather than my desktop PC {which has all the ssh certs, own/fedora/fedara certs, and the client side certificate}. To use a second development machine is it necessary and sufficient to: cp from my account on original desktop: - .fedora.cert - .fedora-server-ca.cert - .fedora-upload-ca.cert - .ssh/id_rsa.pub - .ssh/id_rsa - fedora-browser-cert.p12 and import that into firefox. ? Is there a better way ? My first attempt, I uploaded the second machine's id_rsa.pub, got a new certificate from fas and so on since I didn't have access to the original desktop {while out of town}. If I have all the same key/certs on the notebook, what are the security implications if the machine is stolen {and obtained by someone with malicious ideas} etc ? DaveT. From peter.hutterer at who-t.net Sun Sep 21 07:15:58 2008 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Sun, 21 Sep 2008 16:45:58 +0930 Subject: Possible Major bug in X.org update In-Reply-To: References: Message-ID: <20080921071558.GA7350@emu> On Fri, Sep 19, 2008 at 08:43:15PM -0400, Mark Bidewell wrote: > I just updated my F9 system and when I restarted my box, my USB > keyboard will not work. It works under console mode and my USB mouse > continues to work. This is a major issue (for me at least) due to the > fact that I have no PS/2 ports and this makes Fedora unusable. > Mark Bidewell The update to 1.5.0 pulled in an upstream change to input driver loading when no xorg is present or incomplete ServerLayouts are given. As a result, the kbd driver is not loaded automatically if no xorg.conf is present. This combines with the F9 patch to disable evdev keyboards - resulting in no keyboard being available. As said before, xorg-x11-server-1.5.0-2.fc9 reverts the upstream change and kbd is now loaded automatically unless explicitly specified otherwise. Cheers, Peter From bnocera at redhat.com Sun Sep 21 07:15:05 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Sun, 21 Sep 2008 00:15:05 -0700 Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <200809201216.09552.opensource@till.name> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221842915.5524.5.camel@hughsie-work> <45771.198.175.55.5.1221843217.squirrel@mail.jcomserv.net> <200809201216.09552.opensource@till.name> Message-ID: <1221981305.4240.12.camel@snoogens.fab.redhat.com> On Sat, 2008-09-20 at 12:15 +0200, Till Maas wrote: > On Fri September 19 2008, Jon Ciesla wrote: > > > On Fri, 2008-09-19 at 10:40 -0600, Kevin Fenzi wrote: > > >> Would anyone care to take over tpb? Or does anyone even use it these > > >> days? Perhaps we can just drop it? > > > > > > Vendor specific daemons such as tpb have been on the way out since we've > > > been moving the userspace bodges down into proper kernel frameworks. > > > > > > ThinkPads, just like any other model, should "just work" without any > > > special daemons installed. > > > > That would be ideal. Are we to that point currently? If so, I vote let > > it EOL. > > I just noticed, that tpb also provides a nice OSD, e.g. for the volume. And GNOME has a nicer one if you use compositing. And if your desktop doesn't have a nice OSD for multimedia keys, file a bug against it instead of using an obsolete daemon. From ml at kiewel-online.de Sun Sep 21 07:24:05 2008 From: ml at kiewel-online.de (Uwe Kiewel) Date: Sun, 21 Sep 2008 09:24:05 +0200 Subject: Orange Sombrero 9 Released - based on Fedora In-Reply-To: <48D5A299.6000908@kanarip.com> References: <48D5A299.6000908@kanarip.com> Message-ID: <48D5F695.6060607@kiewel-online.de> Jeroen van Meeuwen schrieb: > One more Software Freedom Day well spent ;-) > > I'm proud to announce a new minor player in the world of insignificant > clones of major, important Free and Open Source Linux Distributions, > > *bling* Orange Sombrero - /based on Fedora/ *bling* Sorry for the question. What *is* sombrero!? TIA, Uwe From luya at fedoraproject.org Sun Sep 21 07:32:05 2008 From: luya at fedoraproject.org (Luya Tshimbalanga) Date: Sun, 21 Sep 2008 00:32:05 -0700 Subject: Orange Sombrero 9 Released - based on Fedora In-Reply-To: <48D5F695.6060607@kiewel-online.de> References: <48D5A299.6000908@kanarip.com> <48D5F695.6060607@kiewel-online.de> Message-ID: <48D5F875.6040004@fedoraproject.org> Uwe Kiewel a ?crit : > > Sorry for the question. What *is* sombrero!? Mexican hat. http://en.wikipedia.org/wiki/Sombrero Luya -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From konrad at tylerc.org Sun Sep 21 07:32:39 2008 From: konrad at tylerc.org (Conrad Meyer) Date: Sun, 21 Sep 2008 00:32:39 -0700 Subject: Orange Sombrero 9 Released - based on Fedora In-Reply-To: <48D5F695.6060607@kiewel-online.de> References: <48D5A299.6000908@kanarip.com> <48D5F695.6060607@kiewel-online.de> Message-ID: <200809210032.39921.konrad@tylerc.org> Quoth Uwe Kiewel: > Jeroen van Meeuwen schrieb: > > One more Software Freedom Day well spent ;-) > > > > I'm proud to announce a new minor player in the world of insignificant > > clones of major, important Free and Open Source Linux Distributions, > > > > *bling* Orange Sombrero - /based on Fedora/ *bling* > > > Sorry for the question. What *is* sombrero!? > > TIA, > Uwe Apparently it's a spin that adds the ability to easily rebrand parts of Fedora (i.e. anaconda). Regards, -- Conrad Meyer From ml at kiewel-online.de Sun Sep 21 07:37:12 2008 From: ml at kiewel-online.de (Uwe Kiewel) Date: Sun, 21 Sep 2008 09:37:12 +0200 Subject: Orange Sombrero 9 Released - based on Fedora In-Reply-To: <48D5F875.6040004@fedoraproject.org> References: <48D5A299.6000908@kanarip.com> <48D5F695.6060607@kiewel-online.de> <48D5F875.6040004@fedoraproject.org> Message-ID: <48D5F9A8.8090309@kiewel-online.de> Luya Tshimbalanga schrieb: > Uwe Kiewel a ?crit : >> Sorry for the question. What *is* sombrero!? > Mexican hat. > > http://en.wikipedia.org/wiki/Sombrero > I know - but it's not fedora based :-) From nicolas.mailhot at laposte.net Sun Sep 21 08:00:03 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 21 Sep 2008 10:00:03 +0200 Subject: Possible Major bug in X.org update In-Reply-To: <20080921071558.GA7350@emu> References: <20080921071558.GA7350@emu> Message-ID: <1221984003.9766.10.camel@rousalka.okg> Le dimanche 21 septembre 2008 ? 16:45 +0930, Peter Hutterer a ?crit : > On Fri, Sep 19, 2008 at 08:43:15PM -0400, Mark Bidewell wrote: > > I just updated my F9 system and when I restarted my box, my USB > > keyboard will not work. It works under console mode and my USB mouse > > continues to work. This is a major issue (for me at least) due to the > > fact that I have no PS/2 ports and this makes Fedora unusable. > > Mark Bidewell > > The update to 1.5.0 pulled in an upstream change to input driver loading when > no xorg is present or incomplete ServerLayouts are given. As a result, the kbd > driver is not loaded automatically if no xorg.conf is present. This combines > with the F9 patch to disable evdev keyboards - resulting in no keyboard being > available. So what? the F9 patch to disable evdev keyboards already resulted in no keyboards on some systems, latest upstream change only made this result more common. > As said before, xorg-x11-server-1.5.0-2.fc9 reverts the upstream change and > kbd is now loaded automatically unless explicitly specified otherwise. I hope that someday we'll stop working at cross-purposes with upstream on input (given that Fedora derivatives like OLPC already use evdev) -- 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 ml at kiewel-online.de Sun Sep 21 07:24:05 2008 From: ml at kiewel-online.de (Uwe Kiewel) Date: Sun, 21 Sep 2008 09:24:05 +0200 Subject: Orange Sombrero 9 Released - based on Fedora In-Reply-To: <48D5A299.6000908@kanarip.com> References: <48D5A299.6000908@kanarip.com> Message-ID: <48D5F695.6060607@kiewel-online.de> Jeroen van Meeuwen schrieb: > One more Software Freedom Day well spent ;-) > > I'm proud to announce a new minor player in the world of insignificant > clones of major, important Free and Open Source Linux Distributions, > > *bling* Orange Sombrero - /based on Fedora/ *bling* Sorry for the question. What *is* sombrero!? TIA, Uwe From peter.hutterer at who-t.net Sun Sep 21 08:51:17 2008 From: peter.hutterer at who-t.net (Peter Hutterer) Date: Sun, 21 Sep 2008 18:21:17 +0930 Subject: Possible Major bug in X.org update In-Reply-To: <1221984003.9766.10.camel@rousalka.okg> References: <20080921071558.GA7350@emu> <1221984003.9766.10.camel@rousalka.okg> Message-ID: <20080921085116.GA9471@taz> On Sun, Sep 21, 2008 at 10:00:03AM +0200, Nicolas Mailhot wrote: > > As said before, xorg-x11-server-1.5.0-2.fc9 reverts the upstream change and > > kbd is now loaded automatically unless explicitly specified otherwise. > > I hope that someday we'll stop working at cross-purposes with upstream > on input (given that Fedora derivatives like OLPC already use evdev) When F9 came out, evdev caused quite a few problems, both due to bugs in the server/driver and lack of documentation about changes in config files. Most of these bugs are fixed and F10 uses evdev by default now. So input-wise, we're basically identical to upstream. Cheers, Peter From nicolas.mailhot at laposte.net Sun Sep 21 09:17:48 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 21 Sep 2008 11:17:48 +0200 Subject: Possible Major bug in X.org update In-Reply-To: <20080921085116.GA9471@taz> References: <20080921071558.GA7350@emu> <1221984003.9766.10.camel@rousalka.okg> <20080921085116.GA9471@taz> Message-ID: <1221988668.10138.0.camel@rousalka.okg> Le dimanche 21 septembre 2008 ? 18:21 +0930, Peter Hutterer a ?crit : > On Sun, Sep 21, 2008 at 10:00:03AM +0200, Nicolas Mailhot wrote: > > > As said before, xorg-x11-server-1.5.0-2.fc9 reverts the upstream change and > > > kbd is now loaded automatically unless explicitly specified otherwise. > > > > I hope that someday we'll stop working at cross-purposes with upstream > > on input (given that Fedora derivatives like OLPC already use evdev) > > When F9 came out, evdev caused quite a few problems, both due to bugs in the > server/driver and lack of documentation about changes in config files. Most of > these bugs are fixed and F10 uses evdev by default now. So input-wise, we're > basically identical to upstream. That's nice. I guess I need to remove my F9 workarounds then -- 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 aoliva at redhat.com Sun Sep 21 09:29:55 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sun, 21 Sep 2008 06:29:55 -0300 Subject: Fedora not "free" enough for GNU? In-Reply-To: <1221608529.20234.96.camel@macbook.infradead.org> (David Woodhouse's message of "Tue\, 16 Sep 2008 16\:42\:09 -0700") References: <8553.1220772699@sss.pgh.pa.us> <1221608529.20234.96.camel@macbook.infradead.org> Message-ID: On Sep 16, 2008, David Woodhouse wrote: > Our 'kernel-firmware' package is currently built from the kernel source > as a subpackage of the normal kernel build -- but we should stop doing > that anyway, and build it instead as a completely separate package from > the linux-firmware.git repository on kernel.org. That repository > contains more firmware than the kernel does already, and is going to be > gaining even more. Speaking of which... Any chance you could break up your repository into free and non-free parts, so that Fedora could "build" them as separate packages, out of separate sources? Then people doing Free spins could still offer Free firmware, rather than just removing it all, or having to clean it up in the very same way that is currently done in linux-libre. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From rawhide at fedoraproject.org Sun Sep 21 09:36:03 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sun, 21 Sep 2008 09:36:03 +0000 (UTC) Subject: rawhide report: 20080921 changes Message-ID: <20080921093603.AAD1B1F825F@releng2.fedora.phx.redhat.com> Updated Packages: anaconda-11.4.1.38-1 -------------------- * Sat Sep 20 18:00:00 2008 David Cantrell - 11.4.1.38-1 - Restore old lang-names generation method (dcantrell) - Remount /mnt/sysimage/dev after migrating filesystems. (clumens) - Use the instroot parameter like we should be doing. (clumens) Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 1 Broken deps for i386 ---------------------------------------------------------- bodhi-server-0.5.0-7.fc9.noarch requires python-turboflot evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.i386 requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so smolt-server-1.1.1.1-6.fc10.noarch requires python-turboflot Broken deps for x86_64 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.x86_64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.ppc requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so Broken deps for ppc64 ---------------------------------------------------------- eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave livecd-tools-018-1.fc10.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.ppc64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) From aoliva at redhat.com Sun Sep 21 09:52:54 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sun, 21 Sep 2008 06:52:54 -0300 Subject: Fedora not "free" enough for GNU? In-Reply-To: <604aa7910809071240u1923df65i8861e58de856540b@mail.gmail.com> (Jeff Spaleta's message of "Sun\, 7 Sep 2008 11\:40\:46 -0800") References: <8553.1220772699@sss.pgh.pa.us> <200809071523.44582.ben.kreuter@gmail.com> <604aa7910809071240u1923df65i8861e58de856540b@mail.gmail.com> Message-ID: On Sep 7, 2008, "Jeff Spaleta" wrote: > but it seems to be we are trying to be responsive in a way that > makes sense from our project's point of view. Not trying to be flamy, but... - there's a 100% Free kernel source alternate upstream that tracks kernel.org very closely, that's identical except for the removal of non-Free firmware, and that's been available for quite a while (linux-libre) - there's a viable alternate source for firmware, both Free and non-Free, and it has been available for quite a while (dwmw2's firwmare git repo) - the removal of firmware upstream won't take place in linux-2.6.27, which pretty much means kernel.org linux sources won't be stripped off of non-Free bits in time for Fedora 10 - Fedora still prefers to ship the encumbered bits, making it impossible to distribute 100% Free spins of Fedora 10 without distributing or committing to distributing the non-Free bits in the corresponding sources of the kernel Care to help me understand how that is responsive or makes sense from the project's point of view? I'm quite puzzled at that. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From ville.skytta at iki.fi Sun Sep 21 09:59:27 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Sun, 21 Sep 2008 12:59:27 +0300 Subject: Heads up: packages with Patch:/%patch0 or Patch0:/%patch issues in Rawhide In-Reply-To: <200809061132.24420.ville.skytta@iki.fi> References: <200809061132.24420.ville.skytta@iki.fi> Message-ID: <200809211259.28923.ville.skytta@iki.fi> On Saturday 06 September 2008, Ville Skytt? wrote: > Hi, > > There's a number of packages that have problems with the new rpm's behavior > of not applying Patch0: with plain %patch or not applying Patch: with > %patch0. > > I just discovered that for some reason, the rpmbuild process does not > terminate because of this error, so unless people read their build logs > carefully, some patches may go unapplied. > https://bugzilla.redhat.com/461347 > > Below is a list of packages that most likely need packager action. One way > to fix them is to convert all unnumbered Patch: lines to Patch0: and all > unnumbered %patch lines to %patch0 or %patch -P 0. Status update: some packages were already fixed, of the remaining ones I've fixed what ACLs allowed me to in CVS, but NOT tagged or built anything, and filed bugs with patches for the rest. List of packages built and tagged for F-10 with a patch missing due to the above follows. This was done with quick manual inspection of build logs so it's possible that I missed something. At least for these it should be reviewed how bad it would be to ship a build with the affected patch missing in F-10, and fixed + built if needed (+ rel-eng contacted to get it to F-10 at this point I believe): - alsa-oss - extrema - freetennis (CVS ACLs prevented commit, bug with patch filed) - libnetfilter_conntrack - libnetfilter_queue (CVS ACLs prevented commit, bug with patch filed) - libnfnetlink - speech-dispatcher Apparently no builds done with the buggy rpm, FTBFS fix commit prevented by CVS ACL, bug with patch filed instead: - bontmia - cjet - classpathx-jaf - dwdiff - lvm2 - pbm2l7k - plexus-runtime-builder - sundials - sysstat - time - weechat - xournal Apparently no builds done with the buggy rpm, FTBFS fix committed to CVS: - abe - bit - conexus - cpan2rpm - dosbox - eclipse-subclipse - hdf - hspell - ifplugd - ipcalculator - liblqr-1 - mboxgrep - nec2c - nethogs - osiv - papyrus - pards - perl-BSD-Resource - perl-JSON-Any - perl-XML-Smart - qemu-launcher - starfighter - tclparser - tremulous - wgrib2 - worminator - xmlroff - xpdf - zvbi From aoliva at redhat.com Sun Sep 21 10:05:37 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sun, 21 Sep 2008 07:05:37 -0300 Subject: recover from broken yum transaction In-Reply-To: <1221105038.987.147.camel@rosebud> (Seth Vidal's message of "Wed\, 10 Sep 2008 23\:50\:38 -0400") References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> Message-ID: On Sep 11, 2008, Seth Vidal wrote: > On Thu, 2008-09-11 at 03:24 +0200, Ahmed Kamal wrote: >> Hi, >> I had my computer hang during a major yum upgrade. > When this happens you should run: > yum-complete-transaction Neat! In a slightly different scenario: I often find that, if the ssh connection from which I start 'yum update' is broken for whatever reason (say the machine from which I started reboots or so), yum gets an error posting its progress reports, and then it starts removing lots and lots of packages to keep dependencies from being unmet. Wouldn't it be much nicer if, like, it ran to completion without regarding the stdout errors; recorded a recovery transaction to revert the removals, or at least recorded a transaction to complete the interrupted update? I realize the latter is risky, for you may end up unable to start yum in the first place, but this unfortunately is also the case of the current code. Last time I got this error, an elfutils update was part of the transaction, and it stopped at such an unfortunate time that elfutils got removed, and rpm would no longer run. Oops :-) Is this bug report material? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From ml at kiewel-online.de Sun Sep 21 10:14:09 2008 From: ml at kiewel-online.de (Uwe Kiewel) Date: Sun, 21 Sep 2008 12:14:09 +0200 Subject: Orange Sombrero 9 Released - based on Fedora In-Reply-To: <200809210032.39921.konrad@tylerc.org> References: <48D5A299.6000908@kanarip.com> <48D5F695.6060607@kiewel-online.de> <200809210032.39921.konrad@tylerc.org> Message-ID: <48D61E71.40105@kiewel-online.de> Conrad Meyer schrieb: > Quoth Uwe Kiewel: >> Jeroen van Meeuwen schrieb: >>> One more Software Freedom Day well spent ;-) >>> >>> I'm proud to announce a new minor player in the world of insignificant >>> clones of major, important Free and Open Source Linux Distributions, >>> >>> *bling* Orange Sombrero - /based on Fedora/ *bling* >> >> Sorry for the question. What *is* sombrero!? >> >> TIA, >> Uwe > > Apparently it's a spin that adds the ability to easily rebrand parts of Fedora > (i.e. anaconda). > Thanks for the information. Regards, Uwe From menthos at menthos.com Sun Sep 21 11:33:53 2008 From: menthos at menthos.com (Christian Rose) Date: Sun, 21 Sep 2008 13:33:53 +0200 Subject: Fedora not "free" enough for GNU? In-Reply-To: References: <8553.1220772699@sss.pgh.pa.us> <200809071523.44582.ben.kreuter@gmail.com> <604aa7910809071240u1923df65i8861e58de856540b@mail.gmail.com> Message-ID: <97da516f0809210433x74337763o18f9b7c9a11db42b@mail.gmail.com> On 9/21/08, Alexandre Oliva wrote: > On Sep 7, 2008, "Jeff Spaleta" wrote: > > but it seems to be we are trying to be responsive in a way that > > makes sense from our project's point of view. > > Not trying to be flamy, but... [...] > - the removal of firmware upstream won't take place in linux-2.6.27, > which pretty much means kernel.org linux sources won't be stripped off > of non-Free bits in time for Fedora 10 As for the other options I don't know, but in my book, long-term actions, especially ones involving architectural changes, are still actions, even though they may not be ready in time for the very next release. So I don't think anyone should be blamed for them not being ready in the next release already. Christian From fedora at leemhuis.info Sun Sep 21 12:04:30 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 21 Sep 2008 14:04:30 +0200 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <200809202213.08483.ville.skytta@iki.fi> References: <48D542A9.1070600@leemhuis.info> <200809202213.08483.ville.skytta@iki.fi> Message-ID: <48D6384E.1000802@leemhuis.info> On 20.09.2008 21:13, Ville Skytt? wrote: > On Saturday 20 September 2008, Thorsten Leemhuis wrote: > >>> If you maintain an application which makes sense for a user to select >>> during installation, [...] make sure that your package is listed in a >>> reasonable group in the comps-fn.xml.in files. >> I consider the "during installation" part not much helpful > Not sure if you're referring to the addition of those two words, but I added > them today - I don't have a any problems with the addition of those two words (but I'm not sure if they really improve the situation); the change OTOH was one more reason for me to actually write the mail that started this thread ;-) > if I'm missing something and they make the document less > correct, the change should be reverted. No pressing need to; what we afaics need is this 1. take a closer look at how the data from comps.xml is used in anaconda and PackageKit or other software 2. based on those information create more clear guidelines (or even a policy) what packages should be in comps (and where and how) 3. implement that guideline/policy; that normally will be a job that is best done by the package maintainers; but I suppose more than just a few will likely ignore that work, thus depending on how important comps.xml is (which depends on "1") someone maybe should sit down and add all those that are not in yet but should; > [...] CU knurd From fedora at leemhuis.info Sun Sep 21 12:25:02 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 21 Sep 2008 14:25:02 +0200 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> Message-ID: <48D63D1E.4070806@leemhuis.info> On 20.09.2008 22:00, Kevin Kofler wrote: > Rahul Sundaram fedoraproject.org> writes: >> PackageKit does use it via the yum backend. One more reason for us then to make sure everything a user might want to select is in comps.xml, isn't it? >> http://blogs.gnome.org/hughsie/2008/09/19/packagekit-collections/ > Note that this is only from 0.3.3 on. /me looks at rawhide and finds 0.3.2 /me grabs 0.3.3 straight from koji /me fails to get it to work on F9 (likely my faul) :-/ Hmm. From the screenshot it's hard to see if gpk-application exports the package groups from comps.xml similar to how pirut/anaconda do. But seems to be different, which would be a important detail for the decision how to maintain the comps.xml in Fedora... > [...] Cu knurd From fedora at leemhuis.info Sun Sep 21 12:35:30 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 21 Sep 2008 14:35:30 +0200 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <48D63D1E.4070806@leemhuis.info> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> Message-ID: <48D63F92.8000608@leemhuis.info> On 21.09.2008 14:25, Thorsten Leemhuis wrote: > On 20.09.2008 22:00, Kevin Kofler wrote: >> Rahul Sundaram fedoraproject.org> writes: >>> PackageKit does use it via the yum backend. > One more reason for us then to make sure everything a user might want to > select is in comps.xml, isn't it? > >>> http://blogs.gnome.org/hughsie/2008/09/19/packagekit-collections/ >> Note that this is only from 0.3.3 on. > > /me looks at rawhide and finds 0.3.2 > > /me grabs 0.3.3 straight from koji > > /me fails to get it to work on F9 (likely my fault) :-/ Updating yum as well did the trick. > Hmm. From the screenshot it's hard to see if gpk-application exports the > package groups from comps.xml similar to how pirut/anaconda do. But > seems to be different, which would be a important detail for the > decision how to maintain the comps.xml in Fedora... Seems to be way different. In pirut/anaconda you in F9 for example can select the group "GNOME Desktop Environment"; then you can hit the "details" button and select some more packages from the gnome group or deselect some other you don't want. Seems that's not possible in gpk-application right now. Not sure if it should, but that's quite and important detail when if comes to the "how to maintain comps.xml properly" question. CU knurd From bruno at wolff.to Sun Sep 21 12:59:55 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 21 Sep 2008 07:59:55 -0500 Subject: recover from broken yum transaction In-Reply-To: References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> Message-ID: <20080921125955.GA31700@wolff.to> On Sun, Sep 21, 2008 at 07:05:37 -0300, Alexandre Oliva wrote: > > In a slightly different scenario: I often find that, if the ssh > connection from which I start 'yum update' is broken for whatever > reason (say the machine from which I started reboots or so), yum gets > an error posting its progress reports, and then it starts removing > lots and lots of packages to keep dependencies from being unmet. Use screen. If the connection gets broken you can reconnect to the screen terminal from a new one. It is also a good idea to do this when running yum inside an xterm as upgrades occassionally toast the x server. From jameshubbard at gmail.com Sun Sep 21 14:23:21 2008 From: jameshubbard at gmail.com (James Hubbard) Date: Sun, 21 Sep 2008 10:23:21 -0400 Subject: system-autodeath In-Reply-To: <1221798586.3057.26.camel@rosebud> References: <1221798586.3057.26.camel@rosebud> Message-ID: On Fri, Sep 19, 2008 at 12:29 AM, seth vidal wrote: > A while back I mentioned a system-autodeath idea for fedora. For some > reason I had neglected it but this evening I put it together. If you > take a look it is utterly trivial and just uses cron to kill the default > route. I'm sure there are limitless ways this will not be perfect but I > think it will probably be good enough. > > http://skvidal.fedorapeople.org/system-autodeath/ > > If you can come up with any way it is broken, let me know, otherwise > I'll probably submit it for review. Since the primary of user this app seems to be a network admin, I'm taking that use case into account during this discussion. Wouldn't a better idea be to create a system management app that would report some basic things like the system being out of date with security patches and the OS ver to central admin server? The admin software could be setup to change default routes based on rules specified by the admin that wants it. I believe that it's a bad idea to have an app that when installed by mistake will cause the system to not work. If it is installed, the user should be forced to change a config file that will enable it's capabilities. From ivazqueznet at gmail.com Sun Sep 21 14:39:14 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sun, 21 Sep 2008 10:39:14 -0400 Subject: package maintenance from multiple PCs ? In-Reply-To: <48D5F3E0.7050307@iinet.net.au> References: <48D5F3E0.7050307@iinet.net.au> Message-ID: <1222007954.3433.90.camel@ignacio.lan> On Sun, 2008-09-21 at 17:12 +1000, David Timms wrote: > Hi, I've recently been trying to do package development from my notebook > PC, rather than my desktop PC {which has all the ssh certs, > own/fedora/fedara certs, and the client side certificate}. > > To use a second development machine is it necessary and sufficient to: > cp from my account on original desktop: > - .ssh/id_rsa.pub Not required unless you want to set up other machines for entry with the same key. > If I have all the same key/certs on the notebook, what are the security > implications if the machine is stolen {and obtained by someone with > malicious ideas} etc ? 1) Your passphrase can be brute-forced, thereby possibly gaining some knowledge about your passphrases in general. 2) Someone can act as you in koji, both in the browser and in the command line ("Beware criminals requeueing packages"). -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jvonau at shaw.ca Sun Sep 21 15:12:26 2008 From: jvonau at shaw.ca (Jerry Vonau) Date: Sun, 21 Sep 2008 10:12:26 -0500 Subject: Orange Sombrero 9 Released - based on Fedora In-Reply-To: <48D5A299.6000908@kanarip.com> References: <48D5A299.6000908@kanarip.com> Message-ID: <48D6645A.80000@shaw.ca> Jeroen van Meeuwen wrote: > One more Software Freedom Day well spent ;-) > > I'm proud to announce a new minor player in the world of insignificant > clones of major, important Free and Open Source Linux Distributions, > > *bling* Orange Sombrero - /based on Fedora/ *bling* > > Orange Sombrero starts with releasing version number 9 - the same > version number as the upstream distribution, Fedora, to avoid confusion. > > Has anything been changed? > > Yeah, a patch to anaconda[1,2] that didn't make it in in time for the > Fedora 10 Beta freeze has been applied to compose this release -which is > sort of the entire use case behind the patch anyway. Also, a different > branch of Revisor has been used that uses the patch to anaconda[3]. > > Since I've got limited bandwidth and disk space, this is a 1 CD > distribution. If I had bandwidth and disk space, I might have thrown in > a mid-release Everything Spin but I couldn't. Also, given that this is a > 1 CD distribution, I've added an install class to anaconda so that it > selects the correct groups of packages. Who needs "Office & > Productivity" if there's only @core and @base, right? "Base System" FTW! > It was fun, it took me 4 koji scratch builds of anaconda and another > number of composes to get it "right". > Since this variant of revisor is a single CD distro, any reason to have boot.iso in /images? Could gain +100megs for other stuff to fit in boot.iso's place. Might help Martin at xs-olpc with his quest for a single cd distro, and will most likely be a user of the re-branding offered. Just a thought, Jerry From mike at miketc.net Sun Sep 21 15:17:19 2008 From: mike at miketc.net (Mike Chambers) Date: Sun, 21 Sep 2008 10:17:19 -0500 Subject: rawhide report: 20080921 changes In-Reply-To: <20080921093603.AAD1B1F825F@releng2.fedora.phx.redhat.com> References: <20080921093603.AAD1B1F825F@releng2.fedora.phx.redhat.com> Message-ID: <1222010239.2987.2.camel@scrappy.miketc.net> On Sun, 2008-09-21 at 09:36 +0000, Rawhide Report wrote: > Updated Packages: > > anaconda-11.4.1.38-1 > -------------------- > * Sat Sep 20 18:00:00 2008 David Cantrell - 11.4.1.38-1 > - Restore old lang-names generation method (dcantrell) > - Remount /mnt/sysimage/dev after migrating filesystems. (clumens) > - Use the instroot parameter like we should be doing. (clumens) The Language selection screen was fixed and worked this time, good job. But, the network selection screen still has problems. When manually configuring network (IP, netmask, etc..) you get error about network itself, and when trying dhcp you get an exception. Not able to save them so no files or anything to show you what they were. This was a normal Rawhide install using boot.iso via nfs and doing so graphically. -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From jvonau at shaw.ca Sun Sep 21 15:12:26 2008 From: jvonau at shaw.ca (Jerry Vonau) Date: Sun, 21 Sep 2008 10:12:26 -0500 Subject: Orange Sombrero 9 Released - based on Fedora In-Reply-To: <48D5A299.6000908@kanarip.com> References: <48D5A299.6000908@kanarip.com> Message-ID: <48D6645A.80000@shaw.ca> Jeroen van Meeuwen wrote: > One more Software Freedom Day well spent ;-) > > I'm proud to announce a new minor player in the world of insignificant > clones of major, important Free and Open Source Linux Distributions, > > *bling* Orange Sombrero - /based on Fedora/ *bling* > > Orange Sombrero starts with releasing version number 9 - the same > version number as the upstream distribution, Fedora, to avoid confusion. > > Has anything been changed? > > Yeah, a patch to anaconda[1,2] that didn't make it in in time for the > Fedora 10 Beta freeze has been applied to compose this release -which is > sort of the entire use case behind the patch anyway. Also, a different > branch of Revisor has been used that uses the patch to anaconda[3]. > > Since I've got limited bandwidth and disk space, this is a 1 CD > distribution. If I had bandwidth and disk space, I might have thrown in > a mid-release Everything Spin but I couldn't. Also, given that this is a > 1 CD distribution, I've added an install class to anaconda so that it > selects the correct groups of packages. Who needs "Office & > Productivity" if there's only @core and @base, right? "Base System" FTW! > It was fun, it took me 4 koji scratch builds of anaconda and another > number of composes to get it "right". > Since this variant of revisor is a single CD distro, any reason to have boot.iso in /images? Could gain +100megs for other stuff to fit in boot.iso's place. Might help Martin at xs-olpc with his quest for a single cd distro, and will most likely be a user of the re-branding offered. Just a thought, Jerry From rjones at redhat.com Sun Sep 21 16:10:40 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Sun, 21 Sep 2008 17:10:40 +0100 Subject: [ANNOUNCE] Fedora MinGW - Windows cross-compiler for Fedora Message-ID: <20080921161040.GA3240@amd.home.annexia.org> [This project is still at a draft stage, but since we've put together a test repository, hopefully people can now very easily try out what we've been working on]. What is MinGW? ---------------------------------------------------------------------- MinGW is a C and C++ cross-compiler, based on gcc, that targets Windows. What is Fedora MinGW? ---------------------------------------------------------------------- The Fedora MinGW project's mission is to provide an excellent development environment for Fedora users who wish to cross-compile their programs to run on Windows, minimizing the need to use Windows at all. In the past developers have had to port and compile all of the libraries and tools they have needed, and this huge effort has happened independently many times over. We aim to eliminate duplication of work for application developers by providing a range of libraries and development tools which have already been ported to the cross-compiler environment. This means that developers will not need to recompile the application stack themselves, but can concentrate just on the changes needed to their own application. Compiling applications ---------------------------------------------------------------------- Many applications can be compiled simply by installing any dependent mingw-* libraries and doing: ./configure --host=i686-pc-mingw32 Most will need to be changed, ranging from simple changes to large scale ports. Some resources which can help with porting are: http://www.gnu.org/software/gnulib/ http://www.mingw.org/ http://et.redhat.com/~rjones/win32-porting/ How to get Fedora MinGW? ---------------------------------------------------------------------- Our temporary test repository (Fedora/x86-64 only): http://www.annexia.org/tmp/mingw/ To use it, create a file in /etc/yum.repos.d/ containing: [mingw] name=MinGW baseurl=http://www.annexia.org/tmp/mingw/ enabled=1 gpgcheck=0 The MinGW SIG: https://fedoraproject.org/wiki/MinGW Draft packaging guidelines: https://fedoraproject.org/wiki/PackagingDrafts/MinGW Development repository: hg clone http://hg.et.redhat.com/misc/fedora-mingw--devel -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From dennis at ausil.us Sun Sep 21 16:36:35 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 21 Sep 2008 11:36:35 -0500 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <48D542A9.1070600@leemhuis.info> References: <48D542A9.1070600@leemhuis.info> Message-ID: <200809211136.41152.dennis@ausil.us> On Saturday 20 September 2008 01:36:25 pm Thorsten Leemhuis wrote: > Hi all! > > I recently created comps.xml files for RPM Fusion. During that a few > things around comps.xml got discussed on the RPM Fusion lists(?). > > That and a recent change (?) to > https://fedoraproject.org/wiki/PackageMaintainers/CompsXml > made me wonder: > > > How important is comps.xml to us these days? > > > (Note that I mean Fedora and RPM Fusion with "us" here, as RPM Fusion > for things like this just follows the Fedora guidelines) > > Comps.xml is afaics mainly used in anaconda (and thus indirectly in > tools like pungi that rely on anaconda) and yum (if you know what to do) > these days; PackageKit afaics doesn't use it much (or does it use > comps.xml at all? Will that change?); it just lists everything it finds > afaics (correct me if I'm wrong, I'm not using PackageKit much and just > use yum directly). comps.xml is used by yum when doing group functions also so "yum groupinstall xfce-desktop" gets that group info from the comps file. its still pretty vital. and to get the highest visability to your package you should be entering it. Dennis From paul at all-the-johnsons.co.uk Sun Sep 21 16:41:32 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 21 Sep 2008 17:41:32 +0100 Subject: Mono 2.0 in F10 Message-ID: <1222015292.10041.7.camel@PB3.Linux> Hi, I've been informed that Mono 2.0 RC3 is due out next week (RC3 is going to be the actual release from what I've been told). If it is out next week, can we get it pushed for inclusion into F10 (it is mostly bug fixes over the version currently in rawhide, so testing will need to be minimal)? It will mean that when F10 is released, it will have something that not even OpenSuSE will have, the proper Mono 2.0 in - a big bonus for us! A knock on is that the mono packagers should be able to get the full 1.9.x stack into F9, so there should be less problems than we're currently finding with pushing into core. TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From s-t-rhbugzilla at wwwdotorg.org Sun Sep 21 16:53:37 2008 From: s-t-rhbugzilla at wwwdotorg.org (Stephen Warren) Date: Sun, 21 Sep 2008 10:53:37 -0600 Subject: Possible Major bug in X.org update In-Reply-To: <20080921071558.GA7350@emu> References: <20080921071558.GA7350@emu> Message-ID: <1222015985.14598.TMDA@tmda.severn.wwwdotorg.org> Peter Hutterer wrote: > On Fri, Sep 19, 2008 at 08:43:15PM -0400, Mark Bidewell wrote: >> I just updated my F9 system and when I restarted my box, my USB >> keyboard will not work. It works under console mode and my USB mouse >> continues to work. This is a major issue (for me at least) due to the >> fact that I have no PS/2 ports and this makes Fedora unusable. >> Mark Bidewell > > The update to 1.5.0 pulled in an upstream change to input driver loading when > no xorg is present or incomplete ServerLayouts are given. As a result, the kbd > driver is not loaded automatically if no xorg.conf is present. This combines > with the F9 patch to disable evdev keyboards - resulting in no keyboard being > available. Yuck. This probably hits a significant number of laptop users, since they will have emptied out their xorg.conf to work around the synaptics issue in bug 439386. https://bugzilla.redhat.com/show_bug.cgi?id=439386 Didn't the update mentioned above get tested at all? > As said before, xorg-x11-server-1.5.0-2.fc9 reverts the upstream change and > kbd is now loaded automatically unless explicitly specified otherwise. Yup, this fixes it for me. From gnomeuser at gmail.com Sun Sep 21 16:57:24 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Sun, 21 Sep 2008 18:57:24 +0200 Subject: Mono 2.0 in F10 In-Reply-To: <1222015292.10041.7.camel@PB3.Linux> References: <1222015292.10041.7.camel@PB3.Linux> Message-ID: <1dedbbfc0809210957vfa47cd3q3b48167fe7114373@mail.gmail.com> Den 21. sep. 2008 18.41 skrev Paul : > Hi, > > I've been informed that Mono 2.0 RC3 is due out next week (RC3 is going > to be the actual release from what I've been told). > > If it is out next week, can we get it pushed for inclusion into F10 (it > is mostly bug fixes over the version currently in rawhide, so testing > will need to be minimal)? It will mean that when F10 is released, it > will have something that not even OpenSuSE will have, the proper Mono > 2.0 in - a big bonus for us! > > A knock on is that the mono packagers should be able to get the full > 1.9.x stack into F9, so there should be less problems than we're > currently finding with pushing into core. Oh this is good news indeed, I also see that gtk-sharp2 2.12 was built for F9 as well so we might finally get a modern version of gnome-do and monodevelop in F9. Any specific testing you desire before preparing the push to updates-testing?. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim.lauridsen at googlemail.com Sun Sep 21 17:05:26 2008 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Sun, 21 Sep 2008 19:05:26 +0200 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <48D63F92.8000608@leemhuis.info> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> Message-ID: <48D67ED6.6040405@googlemail.com> Thorsten Leemhuis wrote: > On 21.09.2008 14:25, Thorsten Leemhuis wrote: >> On 20.09.2008 22:00, Kevin Kofler wrote: >>> Rahul Sundaram fedoraproject.org> writes: >>>> PackageKit does use it via the yum backend. >> One more reason for us then to make sure everything a user might want >> to select is in comps.xml, isn't it? >> >>>> http://blogs.gnome.org/hughsie/2008/09/19/packagekit-collections/ >>> Note that this is only from 0.3.3 on. >> >> /me looks at rawhide and finds 0.3.2 >> >> /me grabs 0.3.3 straight from koji >> >> /me fails to get it to work on F9 (likely my fault) :-/ > > Updating yum as well did the trick. > >> Hmm. From the screenshot it's hard to see if gpk-application exports >> the package groups from comps.xml similar to how pirut/anaconda do. >> But seems to be different, which would be a important detail for the >> decision how to maintain the comps.xml in Fedora... > > Seems to be way different. In pirut/anaconda you in F9 for example can > select the group "GNOME Desktop Environment"; then you can hit the > "details" button and select some more packages from the gnome group or > deselect some other you don't want. Seems that's not possible in > gpk-application right now. Not sure if it should, but that's quite and > important detail when if comes to the "how to maintain comps.xml > properly" question. > > CU > knurd > The groups in comps.xml is used as meta-packages, there can be installed and removed. just like yum groupinstall/groupremove. Ex. you can install KDE by installing the kde-desktop meta-package. All the meta-packages (comps groups) are located under collections. The categories is not used in pk-application. Tim From fedora at leemhuis.info Sun Sep 21 18:27:01 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 21 Sep 2008 20:27:01 +0200 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <200809211136.41152.dennis@ausil.us> References: <48D542A9.1070600@leemhuis.info> <200809211136.41152.dennis@ausil.us> Message-ID: <48D691F5.3000009@leemhuis.info> On 21.09.2008 18:36, Dennis Gilmore wrote: > On Saturday 20 September 2008 01:36:25 pm Thorsten Leemhuis wrote: >> I recently created comps.xml files for RPM Fusion. During that a few >> things around comps.xml got discussed on the RPM Fusion lists(?). >> That and a recent change (?) to >> https://fedoraproject.org/wiki/PackageMaintainers/CompsXml >> made me wonder: >> >> How important is comps.xml to us these days? >> >> (Note that I mean Fedora and RPM Fusion with "us" here, as RPM Fusion >> for things like this just follows the Fedora guidelines) >> >> Comps.xml is afaics mainly used in anaconda (and thus indirectly in >> tools like pungi that rely on anaconda) and yum (if you know what to do) >> these days; PackageKit afaics doesn't use it much (or does it use >> comps.xml at all? Will that change?); it just lists everything it finds >> afaics (correct me if I'm wrong, I'm not using PackageKit much and just >> use yum directly). Seems you didn't get what I was up to. Sorry, my fault. Let me try again. > comps.xml is used by yum when doing group functions also so "yum > groupinstall xfce-desktop" gets that group info from the comps file. Sure. > its still pretty vital. Sure. But it afaics could be a whole lot more "vital" if all packagers would use it and would use it in the same way. > and to get the highest visability to your package you > should be entering it. Sure. But if you read my mail up to the end you will notice that a good bunch of packagers don't care and don't add their packages to comps. I want to know if we in Fedora (the project/the distribution) should work towards fixing that. That implies a proper policy (which is not really clear right now), fixing the current mess where round about one/third of our packages (or even more; depends on the way you count) are missing in comps.xml and making sure all apps present the data from comps in a similar way. Cu knurd From fedora at leemhuis.info Sun Sep 21 18:31:30 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 21 Sep 2008 20:31:30 +0200 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <48D67ED6.6040405@googlemail.com> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> Message-ID: <48D69302.3080607@leemhuis.info> On 21.09.2008 19:05, Tim Lauridsen wrote: > Thorsten Leemhuis wrote: >> On 21.09.2008 14:25, Thorsten Leemhuis wrote: >>> On 20.09.2008 22:00, Kevin Kofler wrote: >>>> Rahul Sundaram fedoraproject.org> writes: >>>>> PackageKit does use it via the yum backend. >>> One more reason for us then to make sure everything a user might want >>> to select is in comps.xml, isn't it? >>>>> http://blogs.gnome.org/hughsie/2008/09/19/packagekit-collections/ >>>> Note that this is only from 0.3.3 on. >>> /me looks at rawhide and finds 0.3.2 >>> /me grabs 0.3.3 straight from koji >>> /me fails to get it to work on F9 (likely my fault) :-/ >> Updating yum as well did the trick. >> >>> Hmm. From the screenshot it's hard to see if gpk-application exports >>> the package groups from comps.xml similar to how pirut/anaconda do. >>> But seems to be different, which would be a important detail for the >>> decision how to maintain the comps.xml in Fedora... >> Seems to be way different. In pirut/anaconda you in F9 for example can >> select the group "GNOME Desktop Environment"; then you can hit the >> "details" button and select some more packages from the gnome group or >> deselect some other you don't want. Seems that's not possible in >> gpk-application right now. Not sure if it should, but that's quite and >> important detail when if comes to the "how to maintain comps.xml >> properly" question. > The groups in comps.xml is used as meta-packages, there can be installed > and removed. just like yum groupinstall/groupremove. Yeah, but that will only install (or remove?) packages that are '' in the comps file, correct? > Ex. you can install KDE by installing the kde-desktop meta-package. > All the meta-packages (comps groups) are located under collections. > The categories is not used in pk-application. IOW: adding packages to a group in comps.xml as '' is only worth the trouble if you want to make the package selectable in anaconda, as that information is not used by pk-application. Correct? CU knurd From jspaleta at gmail.com Sun Sep 21 18:44:39 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 21 Sep 2008 10:44:39 -0800 Subject: Fedora not "free" enough for GNU? In-Reply-To: References: <8553.1220772699@sss.pgh.pa.us> <200809071523.44582.ben.kreuter@gmail.com> <604aa7910809071240u1923df65i8861e58de856540b@mail.gmail.com> Message-ID: <604aa7910809211144s77460d18se7d6620518c4db56@mail.gmail.com> On Sun, Sep 21, 2008 at 1:52 AM, Alexandre Oliva wrote: > Not trying to be flamy, but... > > - there's a 100% Free kernel source alternate upstream that tracks > kernel.org very closely, that's identical except for the removal of > non-Free firmware, and that's been available for quite a while > (linux-libre) I think the suggestion that we move to an alternate source for the kernel, is short sighted and not in the long term best interests of this project. > > - there's a viable alternate source for firmware, both Free and > non-Free, and it has been available for quite a while (dwmw2's > firwmare git repo) Define "quite a while now". By Woodhouse's own words in this thread, he feels we are "close" to offering a solution. Perhaps he's got a better feel for the timescales involved than you do. Is it in time for F10? no. Is that ultimately so important? no. People are working on it. If David feels things are "close" then we will hopefully see this land for reals in the development tree in time for spins to take advantage of for the F11 release process. > > - the removal of firmware upstream won't take place in linux-2.6.27, > which pretty much means kernel.org linux sources won't be stripped off > of non-Free bits in time for Fedora 10 Timescales are not my primary concern, process is. Is there an upstream process in place now on how do deal with the movement of firmware out of the kernel source into a separate source collection? If so, are things now in a state where people interested in our community could choose to actively participate to accelerate the rate at which fireware is moved out of the main kernel source tarball, using the upstream process as part of the F11 Feature scoping? > > - Fedora still prefers to ship the encumbered bits, making it > impossible to distribute 100% Free spins of Fedora 10 without > distributing or committing to distributing the non-Free bits in the > corresponding sources of the kernel > > Care to help me understand how that is responsive or makes sense from > the project's point of view? I'm quite puzzled at that. Honestly, no. I personally do not care to help you specifically understand what I consider to be the established project's pov. I've personally come to the point where I don't think its worth anyone's time to try to talk to you specifically. Your views are quite entrenched. Even for people who are sympathetic to your points of view, and it seems to be there are many such people, its difficult to discuss things with you and feel like it was worth the time. So honestly why bother. If progress is going to be made, its quite doubtful that it will be done with further consultation with you. Hopefully, you'll eventually benefit from the end result, even if you don't appreciate the means by which other people make it happen. But for anyone else still paying attention to this I'll say this. I believe that the project's stance on firmware policy is well documented and has been in place for so long that to call it controversial would be a stretch. In light of that standing project policy, I believe the right way forward, and the way that maximizes benefit everyone is to work directly with upstream to make working with firmware more flexible for everyone...regardless of the timescale that it takes. The question I care about the most is this. Is our involvement as a project, even indirectly, helping upstream make progress on the issue of increasing the flexibility of firmware distribution options and firmware distribution usage. -jef"AFK for the next 10 hours...doing yard work"spaleta From pbrobinson at gmail.com Sun Sep 21 19:17:28 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Sun, 21 Sep 2008 20:17:28 +0100 Subject: fun with metacity segfaults on rawhide eeepc In-Reply-To: <45abe7d80809201338j1a783ab1lb942e7bea42bd43e@mail.gmail.com> References: <5256d0b0809190816r705dafbboda1bf05843f31252@mail.gmail.com> <5256d0b0809190959o2b81b68ese04e595af340d4c8@mail.gmail.com> <91705d080809191009u4e52a126n91b3b4ce3e0da086@mail.gmail.com> <5256d0b0809191420g7f8972e1va44aa40d07608a76@mail.gmail.com> <45abe7d80809201338j1a783ab1lb942e7bea42bd43e@mail.gmail.com> Message-ID: <5256d0b0809211217jc36ca67x50bef0b1ecf7232a@mail.gmail.com> On Sat, Sep 20, 2008 at 9:38 PM, Ray Strode wrote: > Hi, > >> is it possible to change WM from the command line though? gconf or something? > Just run desktop-effects and click the enable button. I can't as I don't get a desktop because metacity keeps segfaulting. Peter From bnocera at redhat.com Sun Sep 21 07:15:05 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Sun, 21 Sep 2008 00:15:05 -0700 Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <200809201216.09552.opensource@till.name> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221842915.5524.5.camel@hughsie-work> <45771.198.175.55.5.1221843217.squirrel@mail.jcomserv.net> <200809201216.09552.opensource@till.name> Message-ID: <1221981305.4240.12.camel@snoogens.fab.redhat.com> On Sat, 2008-09-20 at 12:15 +0200, Till Maas wrote: > On Fri September 19 2008, Jon Ciesla wrote: > > > On Fri, 2008-09-19 at 10:40 -0600, Kevin Fenzi wrote: > > >> Would anyone care to take over tpb? Or does anyone even use it these > > >> days? Perhaps we can just drop it? > > > > > > Vendor specific daemons such as tpb have been on the way out since we've > > > been moving the userspace bodges down into proper kernel frameworks. > > > > > > ThinkPads, just like any other model, should "just work" without any > > > special daemons installed. > > > > That would be ideal. Are we to that point currently? If so, I vote let > > it EOL. > > I just noticed, that tpb also provides a nice OSD, e.g. for the volume. And GNOME has a nicer one if you use compositing. And if your desktop doesn't have a nice OSD for multimedia keys, file a bug against it instead of using an obsolete daemon. From bnocera at redhat.com Sun Sep 21 07:15:05 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Sun, 21 Sep 2008 00:15:05 -0700 Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <200809201216.09552.opensource@till.name> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221842915.5524.5.camel@hughsie-work> <45771.198.175.55.5.1221843217.squirrel@mail.jcomserv.net> <200809201216.09552.opensource@till.name> Message-ID: <1221981305.4240.12.camel@snoogens.fab.redhat.com> On Sat, 2008-09-20 at 12:15 +0200, Till Maas wrote: > On Fri September 19 2008, Jon Ciesla wrote: > > > On Fri, 2008-09-19 at 10:40 -0600, Kevin Fenzi wrote: > > >> Would anyone care to take over tpb? Or does anyone even use it these > > >> days? Perhaps we can just drop it? > > > > > > Vendor specific daemons such as tpb have been on the way out since we've > > > been moving the userspace bodges down into proper kernel frameworks. > > > > > > ThinkPads, just like any other model, should "just work" without any > > > special daemons installed. > > > > That would be ideal. Are we to that point currently? If so, I vote let > > it EOL. > > I just noticed, that tpb also provides a nice OSD, e.g. for the volume. And GNOME has a nicer one if you use compositing. And if your desktop doesn't have a nice OSD for multimedia keys, file a bug against it instead of using an obsolete daemon. From arjan at infradead.org Sun Sep 21 19:45:54 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Sun, 21 Sep 2008 12:45:54 -0700 Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <1221981305.4240.12.camel@snoogens.fab.redhat.com> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221842915.5524.5.camel@hughsie-work> <45771.198.175.55.5.1221843217.squirrel@mail.jcomserv.net> <200809201216.09552.opensource@till.name> <1221981305.4240.12.camel@snoogens.fab.redhat.com> Message-ID: <20080921124554.5bd81d16@infradead.org> On Sun, 21 Sep 2008 00:15:05 -0700 Bastien Nocera wrote: > > I just noticed, that tpb also provides a nice OSD, e.g. for the > > volume. > > And GNOME has a nicer one if you use compositing. > > And if your desktop doesn't have a nice OSD for multimedia keys, file > a bug against it instead of using an obsolete daemon. > as a sidenote: do you know which part of gnome does the brightness OSD? because that part really needs to talk to gnome-power-manager! (right now you have the behavior where if I as user crank the brightness up, say because of bad light, it works for like 20 seconds and then g-p-m comes in and things I want to dimm my screen again to the battery level. Same for the other direction) -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org From snecklifter at gmail.com Sun Sep 21 20:25:11 2008 From: snecklifter at gmail.com (Christopher Brown) Date: Sun, 21 Sep 2008 21:25:11 +0100 Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <45771.198.175.55.5.1221843217.squirrel@mail.jcomserv.net> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221787714.3433.5.camel@ignacio.lan> <20080919104020.3958c1c5@ohm.scrye.com> <1221842915.5524.5.camel@hughsie-work> <45771.198.175.55.5.1221843217.squirrel@mail.jcomserv.net> Message-ID: <364d303b0809211325w1b61df8lb6721f24883ed108@mail.gmail.com> 2008/9/19 Jon Ciesla : > >> On Fri, 2008-09-19 at 10:40 -0600, Kevin Fenzi wrote: >>> Would anyone care to take over tpb? Or does anyone even use it these >>> days? Perhaps we can just drop it? >> >> Vendor specific daemons such as tpb have been on the way out since we've >> been moving the userspace bodges down into proper kernel frameworks. >> >> ThinkPads, just like any other model, should "just work" without any >> special daemons installed. > > That would be ideal. Are we to that point currently? If so, I vote let > it EOL. FWIW, I no longer install tpb on my thinkpads as the quirks/gnome-clever-stuff get better and more functional with each release. So from a user perspective, this is now a Works Out Of The Box experience and I see no problem with tpb being deprecated. Regards -- Christopher Brown http://www.chruz.com From aoliva at redhat.com Sun Sep 21 20:52:50 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sun, 21 Sep 2008 17:52:50 -0300 Subject: Fedora not "free" enough for GNU? In-Reply-To: <604aa7910809211144s77460d18se7d6620518c4db56@mail.gmail.com> (Jeff Spaleta's message of "Sun\, 21 Sep 2008 10\:44\:39 -0800") References: <8553.1220772699@sss.pgh.pa.us> <200809071523.44582.ben.kreuter@gmail.com> <604aa7910809071240u1923df65i8861e58de856540b@mail.gmail.com> <604aa7910809211144s77460d18se7d6620518c4db56@mail.gmail.com> Message-ID: On Sep 21, 2008, "Jeff Spaleta" wrote: > On Sun, Sep 21, 2008 at 1:52 AM, Alexandre Oliva wrote: >> Not trying to be flamy, but... >> >> - there's a 100% Free kernel source alternate upstream that tracks >> kernel.org very closely, that's identical except for the removal of >> non-Free firmware, and that's been available for quite a while >> (linux-libre) > I think the suggestion that we move to an alternate source for the > kernel, is short sighted and not in the long term best interests of > this project. Now that the ability to ship firmware separately was mostly addressed, what's the new objection? The switch didn't even have to be permanent. Just use what's ready and tracks upstream now, and then go back to what isn't ready now when it is. What's the big deal? > Define "quite a while now". More than two months, for the firmware package. Twice as long since I first got involved with linux-libre, which was long after the project started. Heck, when linux-libre was first proposed as a solution, it wasn't even too late for Fedora 9, if the issue of user freedom was taken as seriously as say legal issues. > By Woodhouse's own words in this > thread, he feels we are "close" to offering a solution. I don't see that he's trying solve the same problem. It might be that, as a collateral effect of his work, we'll be closer to a solution for the problem of user freedom. But that he keeps Free and non-Free firmware in the same package, and promotes the solution as a means to add even more non-Free firmware to the package and the distro, shows his goal is 'remove firmware from the kernel', not 'split Free from non-Free software in a way that enables Free software to be shipped without non-Free Software'. > Is it in time for F10? no. Is that ultimately so important? no. Not for Fedora, that's quite clear. Two releases in a row that refrain from adopting a solution that's ready, because... I don't know, because "it's not in the long term best interests of this project"? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Sun Sep 21 20:55:40 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sun, 21 Sep 2008 17:55:40 -0300 Subject: recover from broken yum transaction In-Reply-To: <20080921125955.GA31700@wolff.to> (Bruno Wolff, III's message of "Sun\, 21 Sep 2008 07\:59\:55 -0500") References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <20080921125955.GA31700@wolff.to> Message-ID: On Sep 21, 2008, Bruno Wolff III wrote: > On Sun, Sep 21, 2008 at 07:05:37 -0300, > Alexandre Oliva wrote: >> In a slightly different scenario: I often find that, if the ssh >> connection from which I start 'yum update' is broken for whatever >> reason (say the machine from which I started reboots or so), yum gets >> an error posting its progress reports, and then it starts removing >> lots and lots of packages to keep dependencies from being unmet. > Use screen. I do. But how do you propose to script that over 10+ (or 100+ :-) boxes? I use screen on the server from which I initiate the updates, but that doesn't cut it when it's the server that is rebooted, or gets disconnected from the client. And then, using screen is just a work around for a serious problem. Wouldn't we be better off solving the problem in the first place? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From smooge at gmail.com Sun Sep 21 21:19:36 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Sun, 21 Sep 2008 15:19:36 -0600 Subject: Fedora not "free" enough for GNU? In-Reply-To: References: <8553.1220772699@sss.pgh.pa.us> <200809071523.44582.ben.kreuter@gmail.com> <604aa7910809071240u1923df65i8861e58de856540b@mail.gmail.com> <604aa7910809211144s77460d18se7d6620518c4db56@mail.gmail.com> Message-ID: <80d7e4090809211419p78edad66k18a297ab151e0b25@mail.gmail.com> On Sun, Sep 21, 2008 at 2:52 PM, Alexandre Oliva wrote: >> Is it in time for F10? no. Is that ultimately so important? no. > > Not for Fedora, that's quite clear. Two releases in a row that > refrain from adopting a solution that's ready, because... I don't > know, because "it's not in the long term best interests of this > project"? > You are becoming your worst enemy with lines like that. You fail to communicate well, you keep treating people like imbeciles, then you expect them to follow you without question.. and unlike a good prophet you expect them to do the work for you. Make an Orange Sombrero or some hat from Brazil. Show that it can be done and maintained.. and then you will have something to point to. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From james.antill at redhat.com Sun Sep 21 21:27:06 2008 From: james.antill at redhat.com (James Antill) Date: Sun, 21 Sep 2008 17:27:06 -0400 Subject: recover from broken yum transaction In-Reply-To: References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> Message-ID: <1222032426.20430.8.camel@code.and.org> On Sun, 2008-09-21 at 07:05 -0300, Alexandre Oliva wrote: > On Sep 11, 2008, Seth Vidal wrote: > > > On Thu, 2008-09-11 at 03:24 +0200, Ahmed Kamal wrote: > >> Hi, > >> I had my computer hang during a major yum upgrade. > > > When this happens you should run: > > yum-complete-transaction Also note that the latest yum will inform you to run the above, when you need to. > In a slightly different scenario: I often find that, if the ssh > connection from which I start 'yum update' is broken for whatever > reason (say the machine from which I started reboots or so), yum gets > an error posting its progress reports, and then it starts removing > lots and lots of packages to keep dependencies from being unmet. I haven't heard this before, and I don't see how yum could do that. I assume you mean when the connection dies after the "Running transaction" stage? At this point yum is really rpm. Although I'd still be surprised if rpm altered the running transaction to remove a bunch of applications, it seems more plausible than yum doing the same. The error I usually see is when the connection dies and yum/rpm instantly die with it ... at which point rpm is some way through the transaction and so for all the updates which have been done without the corresponding cleanup you actually have two versions of those packages installed. Due to version deps. this sometimes means that things don't work. > Wouldn't it be much nicer if, like, it ran to completion without > regarding the stdout errors; recorded a recovery transaction to revert > the removals, or at least recorded a transaction to complete the > interrupted update? That's what yum-complete-transaction does. "running to completion" would only really be possible if we compartmentalized the UI from the backend (in different processes), which would be nice ... but is a lot of work. > I realize the latter is risky, for you may end up unable to start yum > in the first place, but this unfortunately is also the case of the > current code. Last time I got this error, an elfutils update was part > of the transaction, and it stopped at such an unfortunate time that > elfutils got removed, and rpm would no longer run. Oops :-) > > Is this bug report material? If you have a reproducer feel free to report it and we'll investigate. -- James Antill Fedora -------------- 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 kevin.kofler at chello.at Sun Sep 21 21:33:45 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 21 Sep 2008 21:33:45 +0000 (UTC) Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> Message-ID: Tim Lauridsen googlemail.com> writes: > The groups in comps.xml is used as meta-packages, there can be installed > and removed. just like yum groupinstall/groupremove. > Ex. you can install KDE by installing the kde-desktop meta-package. > All the meta-packages (comps groups) are located under collections. > The categories is not used in pk-application. I see this now in the screenshot. I'm sorry, but I think this is a really, really awful UI. Comps groups should be shown as categories, in the list view on the left, instead of the current hardcoded categories. As you'll certainly ask me why, i.e. what's wrong with the current implementation, here's it: With the current UI: * there is no way to see what's in the collection, * we still rely on the hardcoded categories which can't be controlled by the distribution's package maintainers and which are missing a lot of stuff from comps.xml, when we actually _do_ have that information and mostly throw it away, * it is inconsistent: both the comps.xml groups and the hardcoded categories are lists of packages, yet the hardcoded categories can be listed, but not installed or removed as a whole, the comps.xml groups on the other hand are listed as packages and can be installed or removed, but there's no way to list their contents. IMHO, a much better approach would be to: * throw out the hardcoded categories! We have that information in comps.xml, PackageKit should not try to duplicate it. * display the comps.xml groups instead of the hardcoded categories and * add tristate checkboxes next to the groups, like in Anaconda: by default, they're in the gray state, unless you have all packages installed (checked) or none (unchecked); they can be checked or unchecked, which is equivalent to a groupinstall or groupremove, but the only way to get them into the gray state is to individually install or remove packages from the group (using the list view on the right). Kevin Kofler From lmacken at redhat.com Sun Sep 21 22:04:34 2008 From: lmacken at redhat.com (Luke Macken) Date: Sun, 21 Sep 2008 18:04:34 -0400 Subject: make update problem In-Reply-To: References: Message-ID: <20080921220434.GB20649@x300> On Fri, Sep 19, 2008 at 07:43:01AM -0400, Neal Becker wrote: > When editor opens, all I do is add a line: > type=E > > which seems to be what the comments in the template call for, then: > > make update > Traceback (most recent call last): > File "/usr/bin/bodhi", line 313, in > main() > File "/usr/bin/bodhi", line 134, in main > updates = bodhi.parse_file(input_file=opts.input_file) > File "/usr/lib/python2.5/site-packages/fedora/client/bodhi.py", line 268, in parse_file > config.readfp(template_file) > File "/usr/lib/python2.5/site-packages/iniparse/compat.py", line 106, in readfp > self.data.readfp(fp) > File "/usr/lib/python2.5/site-packages/iniparse/ini.py", line 501, in readfp > raise MissingSectionHeaderError(fname, linecount, line) > ConfigParser.MissingSectionHeaderError: File contains no section headers. > file: bodhi.template, line: 6 > 'type=E\n' Try updating your Makefile.common. bodhi's update template parser got ported to iniparse, and the new template format now looks like this: [ python-fedora-0.3.6-2.fc9 ] # bugfix, security, enhancement, newpackage (required) type=enhancement # testing, stable request=testing # Bug numbers: 1234,9876 bugs= # Description of your update notes=Here is where you give an explanation of your update. # Enable request automation based on the stable/unstable karma thresholds autokarma=True stable_karma=3 unstable_karma=-3 # Automatically close bugs when this marked as stable close_bugs=True # Suggest that users restart after update suggest_reboot=False luke From dtimms at iinet.net.au Sun Sep 21 22:25:09 2008 From: dtimms at iinet.net.au (David Timms) Date: Mon, 22 Sep 2008 08:25:09 +1000 Subject: package maintenance from multiple PCs ? In-Reply-To: <1222007954.3433.90.camel@ignacio.lan> References: <48D5F3E0.7050307@iinet.net.au> <1222007954.3433.90.camel@ignacio.lan> Message-ID: <48D6C9C5.8050901@iinet.net.au> Ignacio Vazquez-Abrams wrote: > On Sun, 2008-09-21 at 17:12 +1000, David Timms wrote: >> Hi, I've recently been trying to do package development from my notebook >> PC, rather than my desktop PC {which has all the ssh certs, >> own/fedora/fedara certs, and the client side certificate}. >> >> To use a second development machine is it necessary and sufficient to: >> cp from my account on original desktop: > >> - .ssh/id_rsa.pub > > Not required unless you want to set up other machines for entry with the > same key. Isn't this required to be uploaded to fas so that cvs commits can work ? [Oh, since public is already uploaded, I don't need it again unless the key is regenerated {and then it's a new public key}] ? Don't you then need at least the private key on the second machine ? >> If I have all the same key/certs on the notebook, what are the security >> implications if the machine is stolen {and obtained by someone with >> malicious ideas} etc ? > > 1) Your passphrase can be brute-forced, thereby possibly gaining some > knowledge about your passphrases in general. So make sure you used a strong passphrase ? Or is that not enough ? > 2) Someone can act as you in koji, both in the browser and in the > command line ("Beware criminals requeueing packages"). Which id parts are used by cvs, koji, bodhi ? DaveT. From bruno at wolff.to Sun Sep 21 22:42:34 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 21 Sep 2008 17:42:34 -0500 Subject: recover from broken yum transaction In-Reply-To: References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <20080921125955.GA31700@wolff.to> Message-ID: <20080921224234.GA5640@wolff.to> On Sun, Sep 21, 2008 at 17:55:40 -0300, Alexandre Oliva wrote: > > On Sun, Sep 21, 2008 at 07:05:37 -0300, > > Alexandre Oliva wrote: > > I do. But how do you propose to script that over 10+ (or 100+ :-) > boxes? If you are scripting it, shouldn't you be able to run yum not attached to any terminal? For example you might run it in the background with the -y option. The clients could even be polling a local mirror so that you could use changes to the mirror to start the update process. You'd still have to make sure that the updates actually occured, but it should be rare for them to get killed in the middle of updating. From bnocera at redhat.com Sun Sep 21 23:09:29 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Sun, 21 Sep 2008 16:09:29 -0700 Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <20080921124554.5bd81d16@infradead.org> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221842915.5524.5.camel@hughsie-work> <45771.198.175.55.5.1221843217.squirrel@mail.jcomserv.net> <200809201216.09552.opensource@till.name> <1221981305.4240.12.camel@snoogens.fab.redhat.com> <20080921124554.5bd81d16@infradead.org> Message-ID: <1222038569.10497.1.camel@snoogens.fab.redhat.com> On Sun, 2008-09-21 at 12:45 -0700, Arjan van de Ven wrote: > On Sun, 21 Sep 2008 00:15:05 -0700 > Bastien Nocera wrote: > > > > I just noticed, that tpb also provides a nice OSD, e.g. for the > > > volume. > > > > And GNOME has a nicer one if you use compositing. > > > > And if your desktop doesn't have a nice OSD for multimedia keys, file > > a bug against it instead of using an obsolete daemon. > > > > as a sidenote: do you know which part of gnome does the brightness OSD? > because that part really needs to talk to gnome-power-manager! Funnily enough, it's gnome-power-manager :) > (right now you have the behavior where if I as user crank the > brightness up, say because of bad light, it works for like 20 seconds > and then g-p-m comes in and things I want to dimm my screen again to > the battery level. Same for the other direction) You might want to file a bug with debug output, see: http://www.gnome.org/projects/gnome-power-manager/bugs.html Cheers From aoliva at redhat.com Mon Sep 22 00:06:03 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Sun, 21 Sep 2008 21:06:03 -0300 Subject: recover from broken yum transaction In-Reply-To: <20080921224234.GA5640@wolff.to> (Bruno Wolff, III's message of "Sun\, 21 Sep 2008 17\:42\:34 -0500") References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <20080921125955.GA31700@wolff.to> <20080921224234.GA5640@wolff.to> Message-ID: On Sep 21, 2008, Bruno Wolff III wrote: > On Sun, Sep 21, 2008 at 17:55:40 -0300, > Alexandre Oliva wrote: >> > On Sun, Sep 21, 2008 at 07:05:37 -0300, >> > Alexandre Oliva wrote: >> >> I do. But how do you propose to script that over 10+ (or 100+ :-) >> boxes? > If you are scripting it, shouldn't you be able to run yum not attached to > any terminal? That's exactly how I run it. It knows it doesn't have a terminal, and it doesn't print as much in terms of progress report as it does when it's run in a terminal. But it still prints messages once it installs each package, and I redirect that to a file on the server. Still, if the server fails, yum stops installing packages, and then starts removing packages that it had scheduled to remove in the transaction, or something like that. And then, again, you seem to be proposing work-arounds for what I perceive as an actual problem. Do you really not think there is a problem, or are you just trying to be helpful to me? My interest is not in work arounds, it's in addressing the actual problem, if there's agreement that there is one, so that it doesn't bite people who didn't know about the need for work arounds in the first place. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From bruno at wolff.to Mon Sep 22 00:51:30 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Sun, 21 Sep 2008 19:51:30 -0500 Subject: recover from broken yum transaction In-Reply-To: References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <20080921125955.GA31700@wolff.to> <20080921224234.GA5640@wolff.to> Message-ID: <20080922005130.GA19894@wolff.to> On Sun, Sep 21, 2008 at 21:06:03 -0300, Alexandre Oliva wrote: > > My interest is not in work arounds, it's in addressing the actual > problem, if there's agreement that there is one, so that it doesn't > bite people who didn't know about the need for work arounds in the > first place. There seems to be two problems you are referring to. One is convenient remote management and the other is transactions not being atomic. The grid people probably have some remote management tools to help them out. If these aren't available in Fedora, then maybe someone can get them into Fedora. There have been a few messages from people trying to get a SIG off the ground that would be a good place to address this. Doing atomic yum transactions is going to be hard. Probably your effort would be better spent keeping the system from crashing during an update then trying to implement atomic updates. From skvidal at fedoraproject.org Mon Sep 22 00:56:41 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Sun, 21 Sep 2008 20:56:41 -0400 Subject: system-autodeath In-Reply-To: References: <1221798586.3057.26.camel@rosebud> Message-ID: <1222045001.12513.4.camel@rosebud> On Sun, 2008-09-21 at 10:23 -0400, James Hubbard wrote: > On Fri, Sep 19, 2008 at 12:29 AM, seth vidal wrote: > > A while back I mentioned a system-autodeath idea for fedora. For some > > reason I had neglected it but this evening I put it together. If you > > take a look it is utterly trivial and just uses cron to kill the default > > route. I'm sure there are limitless ways this will not be perfect but I > > think it will probably be good enough. > > > > http://skvidal.fedorapeople.org/system-autodeath/ > > > > If you can come up with any way it is broken, let me know, otherwise > > I'll probably submit it for review. > > Since the primary of user this app seems to be a network admin, I'm > taking that use case into account during this discussion. > > Wouldn't a better idea be to create a system management app that would > report some basic things like the system being out of date with > security patches and the OS ver to central admin server? The admin > software could be setup to change default routes based on rules > specified by the admin that wants it. > > I believe that it's a bad idea to have an app that when installed by > mistake will cause the system to not work. If it is installed, the > user should be forced to change a config file that will enable it's > capabilities. As a former sysadmin who maintained a respin on multiple linux distro releases for people who then installed systems that I did not control the above is exactly the intent. If the grad students in the lab who installed the university linux distro decide to not keep up and monitor their system I would want it to drop the default route so then, at least, it is only accessible from the local network. -sv From ivazqueznet at gmail.com Mon Sep 22 01:28:16 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Sun, 21 Sep 2008 21:28:16 -0400 Subject: package maintenance from multiple PCs ? In-Reply-To: <48D6C9C5.8050901@iinet.net.au> References: <48D5F3E0.7050307@iinet.net.au> <1222007954.3433.90.camel@ignacio.lan> <48D6C9C5.8050901@iinet.net.au> Message-ID: <1222046897.3433.105.camel@ignacio.lan> On Mon, 2008-09-22 at 08:25 +1000, David Timms wrote: > Ignacio Vazquez-Abrams wrote: > > On Sun, 2008-09-21 at 17:12 +1000, David Timms wrote: > >> Hi, I've recently been trying to do package development from my notebook > >> PC, rather than my desktop PC {which has all the ssh certs, > >> own/fedora/fedara certs, and the client side certificate}. > >> > >> To use a second development machine is it necessary and sufficient to: > >> cp from my account on original desktop: > > > >> - .ssh/id_rsa.pub > > > > Not required unless you want to set up other machines for entry with the > > same key. > Isn't this required to be uploaded to fas so that cvs commits can work ? Once. > [Oh, since public is already uploaded, I don't need it again unless the > key is regenerated {and then it's a new public key}] ? Correct. > Don't you then need at least the private key on the second machine ? Yes. But .pub is the public key. > >> If I have all the same key/certs on the notebook, what are the security > >> implications if the machine is stolen {and obtained by someone with > >> malicious ideas} etc ? > > > > 1) Your passphrase can be brute-forced, thereby possibly gaining some > > knowledge about your passphrases in general. > So make sure you used a strong passphrase ? > Or is that not enough ? Just don't use predictable patterns across the board, such as "family members' names with the second letter 1337-ized and the fourth letter capitalized", etc. Or if you *are* going to use a predictable pattern, make the pattern "ludicrously long/complex passwords". > > 2) Someone can act as you in koji, both in the browser and in the > > command line ("Beware criminals requeueing packages"). > Which id parts are used by cvs, koji, bodhi ? I'm not certain about this, but cvs is your ssh key, koji is your SSL cert, and I'm not sure what bodhi uses. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dev at nigelj.com Mon Sep 22 03:02:32 2008 From: dev at nigelj.com (Nigel Jones) Date: Mon, 22 Sep 2008 15:02:32 +1200 Subject: package maintenance from multiple PCs ? In-Reply-To: <1222046897.3433.105.camel@ignacio.lan> References: <48D5F3E0.7050307@iinet.net.au> <1222007954.3433.90.camel@ignacio.lan> <48D6C9C5.8050901@iinet.net.au> <1222046897.3433.105.camel@ignacio.lan> Message-ID: <1222052552.3534.2.camel@fantail.jnet.net.nz> On Sun, 2008-09-21 at 21:28 -0400, Ignacio Vazquez-Abrams wrote: > On Mon, 2008-09-22 at 08:25 +1000, David Timms wrote: > > Ignacio Vazquez-Abrams wrote: > > > On Sun, 2008-09-21 at 17:12 +1000, David Timms wrote: > > >> Hi, I've recently been trying to do package development from my notebook > > >> PC, rather than my desktop PC {which has all the ssh certs, > > >> own/fedora/fedara certs, and the client side certificate}. > > >> > > >> To use a second development machine is it necessary and sufficient to: > > >> cp from my account on original desktop: > > > > > >> - .ssh/id_rsa.pub > > > > > > Not required unless you want to set up other machines for entry with the > > > same key. > > Isn't this required to be uploaded to fas so that cvs commits can work ? > > Once. > > > [Oh, since public is already uploaded, I don't need it again unless the > > key is regenerated {and then it's a new public key}] ? > > Correct. > > > Don't you then need at least the private key on the second machine ? > > Yes. But .pub is the public key. > > > >> If I have all the same key/certs on the notebook, what are the security > > >> implications if the machine is stolen {and obtained by someone with > > >> malicious ideas} etc ? > > > > > > 1) Your passphrase can be brute-forced, thereby possibly gaining some > > > knowledge about your passphrases in general. > > So make sure you used a strong passphrase ? > > Or is that not enough ? > > Just don't use predictable patterns across the board, such as "family > members' names with the second letter 1337-ized and the fourth letter > capitalized", etc. Or if you *are* going to use a predictable pattern, > make the pattern "ludicrously long/complex passwords". > > > > 2) Someone can act as you in koji, both in the browser and in the > > > command line ("Beware criminals requeueing packages"). > > Which id parts are used by cvs, koji, bodhi ? > > I'm not certain about this, but cvs is your ssh key, koji is your SSL > cert, and I'm not sure what bodhi uses. Bodhi uses json over HTTPS (and your normal FAS password) iirc > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Nigel Jones From martin.langhoff at gmail.com Mon Sep 22 03:29:49 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 22 Sep 2008 15:29:49 +1200 Subject: recover from broken yum transaction In-Reply-To: <20080922005130.GA19894@wolff.to> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <20080921125955.GA31700@wolff.to> <20080921224234.GA5640@wolff.to> <20080922005130.GA19894@wolff.to> Message-ID: <46a038f90809212029l1dc6eff4wc69c1a896ef0135f@mail.gmail.com> On Mon, Sep 22, 2008 at 12:51 PM, Bruno Wolff III wrote: > Doing atomic yum transactions is going to be hard. No doubt about that. RPM/Yum atomicity without FS snapshot support is impossible to achieve. But I am sure a lot of things can be improved. > Probably your effort would > be better spent keeping the system from crashing during an update then > trying to implement atomic updates. I cannot speak for Alexandre - but in my case that is just not possible. I will soon be dealing with thousands of servers running in rural schools in many countries. Very unreliable power, spotty internet connectivity. Once yum has started an operation, I hope it can work hard at completing it, even if that's across several reboots. cheers, martin -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From skvidal at fedoraproject.org Mon Sep 22 04:07:45 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 22 Sep 2008 00:07:45 -0400 Subject: recover from broken yum transaction In-Reply-To: <46a038f90809212029l1dc6eff4wc69c1a896ef0135f@mail.gmail.com> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <20080921125955.GA31700@wolff.to> <20080921224234.GA5640@wolff.to> <20080922005130.GA19894@wolff.to> <46a038f90809212029l1dc6eff4wc69c1a896ef0135f@mail.gmail.com> Message-ID: <1222056465.12513.8.camel@rosebud> On Mon, 2008-09-22 at 15:29 +1200, Martin Langhoff wrote: > On Mon, Sep 22, 2008 at 12:51 PM, Bruno Wolff III wrote: > > Doing atomic yum transactions is going to be hard. > > No doubt about that. RPM/Yum atomicity without FS snapshot support is > impossible to achieve. But I am sure a lot of things can be improved. > > > Probably your effort would > > be better spent keeping the system from crashing during an update then > > trying to implement atomic updates. > > I cannot speak for Alexandre - but in my case that is just not > possible. I will soon be dealing with thousands of servers running in > rural schools in many countries. Very unreliable power, spotty > internet connectivity. Once yum has started an operation, I hope it > can work hard at completing it, even if that's across several reboots. > Rpm updates should behave as expected. When updating packages rpm installs all the new packages first, then cleans up the old packages. So, at no time is the system without at least 1 copy of the package. The most common problem we've run into with yum is getting halfway through a transaction and power or network or something fails such that the second part, cleaning up the older packages, cannot occur. this is where yum-complete-transaction comes in. It will finish up the remaining steps since it has enumerated them. Hope this helps, explain. -sv From michael at laptop.org Mon Sep 22 04:31:57 2008 From: michael at laptop.org (Michael Stone) Date: Mon, 22 Sep 2008 00:31:57 -0400 Subject: recover from broken yum transaction In-Reply-To: <1222056465.12513.8.camel@rosebud> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <20080921125955.GA31700@wolff.to> <20080921224234.GA5640@wolff.to> <20080922005130.GA19894@wolff.to> <46a038f90809212029l1dc6eff4wc69c1a896ef0135f@mail.gmail.com> <1222056465.12513.8.camel@rosebud> Message-ID: <20080922043156.GW18785@didacte.laptop.org> On Mon, Sep 22, 2008 at 12:07:45AM -0400, Seth Vidal wrote: >So, at no time is the system without at least 1 copy of the package. The >most common problem we've run into with yum is getting halfway through a >transaction and power or network or something fails such that the second >part, cleaning up the older packages, cannot occur. > >this is where yum-complete-transaction comes in. It will finish up the >remaining steps since it has enumerated them. Seth, Due to memory pressure and constraints on the XO, we regularly see some RPM %pre- and %post-scripts fail due to OOM. Is there anything which could reasonably be done to mitigate this problem for our yum-users? Thanks, Michael (Background: we believe that yum is used on our systems primarily by hackers and 'technically minded' G1G1 donors for customizing OLPC software releases; to date, general software updates have been made available through olpc-update, which is atomic, bandwidth-efficient, and which permits 'emergency rollback' to the previous (known-good) OS tree.) From skvidal at fedoraproject.org Mon Sep 22 04:42:48 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 22 Sep 2008 00:42:48 -0400 Subject: recover from broken yum transaction In-Reply-To: <20080922043156.GW18785@didacte.laptop.org> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <20080921125955.GA31700@wolff.to> <20080921224234.GA5640@wolff.to> <20080922005130.GA19894@wolff.to> <46a038f90809212029l1dc6eff4wc69c1a896ef0135f@mail.gmail.com> <1222056465.12513.8.camel@rosebud> <20080922043156.GW18785@didacte.laptop.org> Message-ID: <1222058568.12513.11.camel@rosebud> On Mon, 2008-09-22 at 00:31 -0400, Michael Stone wrote: > On Mon, Sep 22, 2008 at 12:07:45AM -0400, Seth Vidal wrote: > >So, at no time is the system without at least 1 copy of the package. The > >most common problem we've run into with yum is getting halfway through a > >transaction and power or network or something fails such that the second > >part, cleaning up the older packages, cannot occur. > > > >this is where yum-complete-transaction comes in. It will finish up the > >remaining steps since it has enumerated them. > > Seth, > > Due to memory pressure and constraints on the XO, we regularly see some > RPM %pre- and %post-scripts fail due to OOM. Is there anything which > could reasonably be done to mitigate this problem for our yum-users? Not much - if it's OOM'ing the only real option is: 1. get more memory 2. have it use less memory if you want to pursue 2 that's fine - but to be very clear - everything after: Running RPM Transaction Test is in rpm-land as to trimming out memory/cpu usage. There's very little yum can do there. -sv From martin.langhoff at gmail.com Mon Sep 22 04:53:37 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 22 Sep 2008 16:53:37 +1200 Subject: recover from broken yum transaction In-Reply-To: <1222058568.12513.11.camel@rosebud> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <20080921125955.GA31700@wolff.to> <20080921224234.GA5640@wolff.to> <20080922005130.GA19894@wolff.to> <46a038f90809212029l1dc6eff4wc69c1a896ef0135f@mail.gmail.com> <1222056465.12513.8.camel@rosebud> <20080922043156.GW18785@didacte.laptop.org> <1222058568.12513.11.camel@rosebud> Message-ID: <46a038f90809212153w567f33ebn6f64a1b770ed9f8b@mail.gmail.com> On Mon, Sep 22, 2008 at 4:42 PM, Seth Vidal wrote: > Not much - if it's OOM'ing the only real option is: > 1. get more memory > 2. have it use less memory > > if you want to pursue 2 that's fine - but to be very clear - everything > after: > Running RPM Transaction Test > > is in rpm-land as to trimming out memory/cpu usage. There's very little > yum can do there. I *think* that what Michael is talking about is that when you get to that point yum is still running and can be a substantial part of the memory pressure. Perhaps yum's memory footprint could be trimmed? If by then it's loaded hard-to-shed things (like python libs) perhaps it can exec a minimalistic "yum stage 2" that drives rpm? cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From michael at laptop.org Mon Sep 22 05:00:34 2008 From: michael at laptop.org (Michael Stone) Date: Mon, 22 Sep 2008 01:00:34 -0400 Subject: recover from broken yum transaction In-Reply-To: <46a038f90809212153w567f33ebn6f64a1b770ed9f8b@mail.gmail.com> References: <20080921125955.GA31700@wolff.to> <20080921224234.GA5640@wolff.to> <20080922005130.GA19894@wolff.to> <46a038f90809212029l1dc6eff4wc69c1a896ef0135f@mail.gmail.com> <1222056465.12513.8.camel@rosebud> <20080922043156.GW18785@didacte.laptop.org> <1222058568.12513.11.camel@rosebud> <46a038f90809212153w567f33ebn6f64a1b770ed9f8b@mail.gmail.com> Message-ID: <20080922050031.GY18785@didacte.laptop.org> Martin, I'm sure there are easier things to prune than yum itself. I was simply asking whether yum's transacation-completion machinery was applicable here. In the meantime, I suspect that we will recommend the use of a temporary off-NAND swap partition or swap-file by the people who need it. Michael From fedora at leemhuis.info Mon Sep 22 05:01:52 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 22 Sep 2008 07:01:52 +0200 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> Message-ID: <48D726C0.4060208@leemhuis.info> On 21.09.2008 23:33, Kevin Kofler wrote: > Tim Lauridsen googlemail.com> writes: > [...] > IMHO, a much better approach would be to: > * throw out the hardcoded categories! We have that information in comps.xml, > PackageKit should not try to duplicate it. > * display the comps.xml groups instead of the hardcoded categories and > * add tristate checkboxes next to the groups, like in Anaconda: by default, > they're in the gray state, unless you have all packages installed (checked) or > none (unchecked); they can be checked or unchecked, which is equivalent to a > groupinstall or groupremove, but the only way to get them into the gray state > is to individually install or remove packages from the group (using the list > view on the right). Strong +1 with one addition for us: * Fedora and its package maintainers need to way better job making sure that most if not all packages are properly listed in comps.xml -- otherwise a good portion of our packages won't show up in any of the groups CU knurd From martin.langhoff at gmail.com Mon Sep 22 05:19:29 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 22 Sep 2008 17:19:29 +1200 Subject: recover from broken yum transaction In-Reply-To: <20080922050031.GY18785@didacte.laptop.org> References: <20080921125955.GA31700@wolff.to> <20080921224234.GA5640@wolff.to> <20080922005130.GA19894@wolff.to> <46a038f90809212029l1dc6eff4wc69c1a896ef0135f@mail.gmail.com> <1222056465.12513.8.camel@rosebud> <20080922043156.GW18785@didacte.laptop.org> <1222058568.12513.11.camel@rosebud> <46a038f90809212153w567f33ebn6f64a1b770ed9f8b@mail.gmail.com> <20080922050031.GY18785@didacte.laptop.org> Message-ID: <46a038f90809212219s71122471w585fe38c3ae219dc@mail.gmail.com> On Mon, Sep 22, 2008 at 5:00 PM, Michael Stone wrote: > I'm sure there are easier things to prune than yum itself. Perhaps you are right. I was probably expressing my own worries about yum memory usage on the XO :-) In a 30s unscientific test yum does seem to consume a fair bit of RAM while RPM runs. The F9 machine I use for dev/build purposes had 9 updates to apply. I just did `yum -yt update` while running repeatedly `ps_mem.py | grep yum ` (in hindsight, I should have grepped for rpm as well). It quickly ramped up to 44.9 MiB private + 1.5 MiB shared during the Resolving Dependencies stage, and stayed there for the duration. While rpm was running, yum was _still_ sitting on thos 46MiB. It looks like it has the whole package metadata in a memory structure. Perhaps it's needed for the plugins, though I hope the internal APIs don't require that all that stuff is in memory. > whether yum's transacation-completion machinery was applicable > here. >From what I read in this thread the transaction-completion machinery doesn't try to parse the repo data into memory. It just reads the plan from the transaction log and tries to execute it. If that's true, then it's got a good chance as a workaround. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From james.antill at redhat.com Mon Sep 22 05:38:03 2008 From: james.antill at redhat.com (James Antill) Date: Mon, 22 Sep 2008 01:38:03 -0400 Subject: recover from broken yum transaction In-Reply-To: <46a038f90809212219s71122471w585fe38c3ae219dc@mail.gmail.com> References: <20080921125955.GA31700@wolff.to> <20080921224234.GA5640@wolff.to> <20080922005130.GA19894@wolff.to> <46a038f90809212029l1dc6eff4wc69c1a896ef0135f@mail.gmail.com> <1222056465.12513.8.camel@rosebud> <20080922043156.GW18785@didacte.laptop.org> <1222058568.12513.11.camel@rosebud> <46a038f90809212153w567f33ebn6f64a1b770ed9f8b@mail.gmail.com> <20080922050031.GY18785@didacte.laptop.org> <46a038f90809212219s71122471w585fe38c3ae219dc@mail.gmail.com> Message-ID: <1222061883.30758.7.camel@code.and.org> On Mon, 2008-09-22 at 17:19 +1200, Martin Langhoff wrote: > On Mon, Sep 22, 2008 at 5:00 PM, Michael Stone wrote: > > I'm sure there are easier things to prune than yum itself. > > Perhaps you are right. I was probably expressing my own worries about > yum memory usage on the XO :-) > > In a 30s unscientific test yum does seem to consume a fair bit of RAM > while RPM runs. The F9 machine I use for dev/build purposes had 9 > updates to apply. > > I just did `yum -yt update` while running repeatedly `ps_mem.py | > grep yum ` (in hindsight, I should have grepped for rpm as well). It > quickly ramped up to 44.9 MiB private + 1.5 MiB shared during the > Resolving Dependencies stage, and stayed there for the duration. While > rpm was running, yum was _still_ sitting on thos 46MiB. What arch? How many repos. did you have enabled? In my tests the latest yum does a "large" update in about 40MB RSS, a few packages is much more likely to be in the 25-30MB range (VSZ is higher, but is just unpaged stuff, not actual swap). > It looks like it has the whole package metadata in a memory structure. > Perhaps it's needed for the plugins, though I hope the internal APIs > don't require that all that stuff is in memory. We drop all the cached data from within yum when the depsolving is finished, however we have little control of how much of that is then usable by rpm to do the transaction (that'd be mostly upto python and libc). We also have plans to split transactions, but I'm not sure you should rely on that to significantly drop the memory usage requirements (although it will make the failure case much nicer). -- James Antill Red Hat -------------- 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 james.antill at redhat.com Mon Sep 22 05:53:37 2008 From: james.antill at redhat.com (James Antill) Date: Mon, 22 Sep 2008 01:53:37 -0400 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <48D67ED6.6040405@googlemail.com> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> Message-ID: <1222062817.30758.17.camel@code.and.org> On Sun, 2008-09-21 at 19:05 +0200, Tim Lauridsen wrote: > The groups in comps.xml is used as meta-packages, there can be installed > and removed. just like yum groupinstall/groupremove. But that's not how groupinstall/groupremove works! Groups are _very_ different from meta-packages, for instance: yum shell < Red Hat -------------- 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 martin.langhoff at gmail.com Mon Sep 22 05:56:17 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 22 Sep 2008 17:56:17 +1200 Subject: recover from broken yum transaction In-Reply-To: <1222061883.30758.7.camel@code.and.org> References: <20080921125955.GA31700@wolff.to> <20080922005130.GA19894@wolff.to> <46a038f90809212029l1dc6eff4wc69c1a896ef0135f@mail.gmail.com> <1222056465.12513.8.camel@rosebud> <20080922043156.GW18785@didacte.laptop.org> <1222058568.12513.11.camel@rosebud> <46a038f90809212153w567f33ebn6f64a1b770ed9f8b@mail.gmail.com> <20080922050031.GY18785@didacte.laptop.org> <46a038f90809212219s71122471w585fe38c3ae219dc@mail.gmail.com> <1222061883.30758.7.camel@code.and.org> Message-ID: <46a038f90809212256ic9cda09i8bb043689f28849@mail.gmail.com> 2008/9/22 James Antill : > What arch? How many repos. did you have enabled? i386 - and the very minimum repos $ yum repolist Loaded plugins: refresh-packagekit repo id repo name status fedora Fedora 9 - i386 enabled : 9,897 updates Fedora 9 - i386 - Updates enabled : 10 updates-newkey Fedora 9 - i386 - Updates Newkey enabled : 3,951 repolist: 13,858 > In my tests the latest yum does a "large" update in about 40MB RSS, a > few packages is much more likely to be in the 25-30MB range (VSZ is > higher, but is just unpaged stuff, not actual swap). I'm looking at the output of ps_mem.py which uses the kernel smap data -- which I understand is regarded as much more reliable than what top reports these days - see http://www.pixelbeat.org/scripts/ps_mem.py > We drop all the cached data from within yum when the depsolving is > finished, however we have little control of how much of that is then There was no observable drop in memory footprint from depsolving to rpm stages, even if we were just updating 9 packages. If my rough test is reasonably accurate then it's easy to see why people would get OOM with yum on the XO -- just reading the release repo, yum is sitting on a good chunk of our available memory, and we have _no_ swap available. One workaround would be to say --disablerepo=release but that means any install that requires packages from the main repo will fail. > We also have plans to split transactions, but I'm not sure you should > rely on that to significantly drop the memory usage requirements > (although it will make the failure case much nicer). I'm *all* for making the failure case better as the XS installations will fail... plenty :-) cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From nicolas.mailhot at laposte.net Mon Sep 22 06:47:45 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 22 Sep 2008 08:47:45 +0200 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <48D726C0.4060208@leemhuis.info> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> Message-ID: <1222066065.19471.6.camel@rousalka.okg> Le lundi 22 septembre 2008 ? 07:01 +0200, Thorsten Leemhuis a ?crit : > On 21.09.2008 23:33, Kevin Kofler wrote: > > Tim Lauridsen googlemail.com> writes: > > [...] > > IMHO, a much better approach would be to: > > * throw out the hardcoded categories! We have that information in comps.xml, > > PackageKit should not try to duplicate it. The PK argument used to be comps groups suck, are distro-specific, have no equivalent on some distros, so people should drop comps and contribute to pk hardcoded stuff instead. NIH syndrom IMHO, replacing distro infra with something else, which pk was not supposed to do. (also pk hardcoding makes no provision for non-centralised group declaration) > > * add tristate checkboxes next to the groups, like in Anaconda: by default, > > they're in the gray state, unless you have all packages installed (checked) or > > none (unchecked); Mostly, pk needs to learn optionals > Strong +1 with one addition for us: > > * Fedora and its package maintainers need to way better job making sure > that most if not all packages are properly listed in comps.xml -- > otherwise a good portion of our packages won't show up in any of the groups Do not generalise, some Fedora groups do have clear comps policies (though no one really wanted to approve those) -- 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 alexl at users.sourceforge.net Mon Sep 22 06:49:19 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sun, 21 Sep 2008 23:49:19 -0700 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <48D726C0.4060208@leemhuis.info> (Thorsten Leemhuis's message of "Mon\, 22 Sep 2008 07\:01\:52 +0200") References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> Message-ID: >>>>> "TL" == Thorsten Leemhuis writes: TL> On 21.09.2008 23:33, Kevin Kofler wrote: >> Tim Lauridsen googlemail.com> writes: [...] >> IMHO, a much better approach would be to: * throw out the hardcoded >> categories! We have that information in comps.xml, PackageKit >> should not try to duplicate it. * display the comps.xml groups >> instead of the hardcoded categories and * add tristate checkboxes >> next to the groups, like in Anaconda: by default, they're in the >> gray state, unless you have all packages installed (checked) or >> none (unchecked); they can be checked or unchecked, which is >> equivalent to a groupinstall or groupremove, but the only way to >> get them into the gray state is to individually install or remove >> packages from the group (using the list view on the right). TL> Strong +1 with one addition for us: TL> * Fedora and its package maintainers need to way better job making TL> sure that most if not all packages are properly listed in TL> comps.xml -- otherwise a good portion of our packages won't show TL> up in any of the groups Ideally this would be done either as a mandatory part of the original CVS import request (a field could be added, with an opt-out provision if really not appropriate for comps), or added interactively by the maintainer via PackageDB as I suggested in the feature request here: https://fedorahosted.org/packagedb/ticket/78#comment:1 Having to manually update the comps.xml file for multiple releases is painful, error-prone and probably why most package maintainers ignore it, especially since it is not enforced in package reviews. Alex From alexl at users.sourceforge.net Mon Sep 22 06:52:18 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Sun, 21 Sep 2008 23:52:18 -0700 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <48D691F5.3000009@leemhuis.info> (Thorsten Leemhuis's message of "Sun\, 21 Sep 2008 20\:27\:01 +0200") References: <48D542A9.1070600@leemhuis.info> <200809211136.41152.dennis@ausil.us> <48D691F5.3000009@leemhuis.info> Message-ID: >>>>> "TL" == Thorsten Leemhuis writes: [...] >> and to get the highest visability to your package you should be >> entering it. TL> Sure. But if you read my mail up to the end you will notice that a TL> good bunch of packagers don't care and don't add their packages to TL> comps. I want to know if we in Fedora (the project/the TL> distribution) should work towards fixing that. That implies a TL> proper policy (which is not really clear right now), fixing the TL> current mess where round about one/third of our packages (or even TL> more; depends on the way you count) are missing in comps.xml and TL> making sure all apps present the data from comps in a similar way. Yep, this is a real problem with the comps.xml approach at the moment. See the feature request: https://fedorahosted.org/packagedb/ticket/78 and my response to another part of the thread. Alex From tomek at crocom.com.pl Mon Sep 22 07:02:17 2008 From: tomek at crocom.com.pl (Tomasz Torcz) Date: Mon, 22 Sep 2008 09:02:17 +0200 Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <1221842915.5524.5.camel@hughsie-work> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221787714.3433.5.camel@ignacio.lan> <20080919104020.3958c1c5@ohm.scrye.com> <1221842915.5524.5.camel@hughsie-work> Message-ID: <1222066937.3186.18.camel@s1.crocom.com.pl> Dnia 2008-09-19, pi? o godzinie 17:48 +0100, Richard Hughes pisze: > On Fri, 2008-09-19 at 10:40 -0600, Kevin Fenzi wrote: > > Would anyone care to take over tpb? Or does anyone even use it these > > days? Perhaps we can just drop it? > ThinkPads, just like any other model, should "just work" without any > special daemons installed. My z61t isn't. Fn+number keys probably work (I pressed "lock" and screen locked), but volume and mute keys do not work. When I press them nothing happens - "xev" shows nothing and dmesg is silent. -- Tomasz Torcz From aoliva at redhat.com Mon Sep 22 04:05:47 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Mon, 22 Sep 2008 01:05:47 -0300 Subject: recover from broken yum transaction In-Reply-To: <20080922005130.GA19894@wolff.to> (Bruno Wolff, III's message of "Sun\, 21 Sep 2008 19\:51\:30 -0500") References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <20080921125955.GA31700@wolff.to> <20080921224234.GA5640@wolff.to> <20080922005130.GA19894@wolff.to> Message-ID: On Sep 21, 2008, Bruno Wolff III wrote: > There seems to be two problems you are referring to. One is convenient > remote management and the other is transactions not being atomic. I'm actually talking about a third problem: that yum starts removing packages just because of an error in reporting progress to stdout/stderr. Everything else was just context to trigger the problem. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From fedora at leemhuis.info Mon Sep 22 07:07:49 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 22 Sep 2008 09:07:49 +0200 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> Message-ID: <48D74445.3030900@leemhuis.info> On 22.09.2008 08:49, Alex Lancaster wrote: >>>>>> "TL" == Thorsten Leemhuis writes: > > TL> On 21.09.2008 23:33, Kevin Kofler wrote: >>> Tim Lauridsen googlemail.com> writes: [...] >>> IMHO, a much better approach would be to: * throw out the hardcoded >>> categories! We have that information in comps.xml, PackageKit >>> should not try to duplicate it. * display the comps.xml groups >>> instead of the hardcoded categories and * add tristate checkboxes >>> next to the groups, like in Anaconda: by default, they're in the >>> gray state, unless you have all packages installed (checked) or >>> none (unchecked); they can be checked or unchecked, which is >>> equivalent to a groupinstall or groupremove, but the only way to >>> get them into the gray state is to individually install or remove >>> packages from the group (using the list view on the right). > > TL> Strong +1 with one addition for us: > > TL> * Fedora and its package maintainers need to way better job making > TL> sure that most if not all packages are properly listed in > TL> comps.xml -- otherwise a good portion of our packages won't show > TL> up in any of the groups > > Ideally this would be done either as a mandatory part of the original > CVS import request (a field could be added, with an opt-out provision > if really not appropriate for comps), or added interactively by the > maintainer via PackageDB as I suggested in the feature request here: > https://fedorahosted.org/packagedb/ticket/78#comment:1 Hmmmm. How much does the pkgdb know about the binary packages that get build from the source packages? Not much afaics, as the pkgdb mainly (only?) works with the (source) packages and not the ones that get build from it -- but in a proper comps.xml we need to list the binary packages, as a user might want to select the packages (rpms) foo or bar that both might get build from the package (srpm) foobar. > Having to manually update the comps.xml file for multiple releases is > painful, error-prone and probably why most package maintainers ignore > it, especially since it is not enforced in package reviews. +1 CU knurd From rc040203 at freenet.de Mon Sep 22 07:29:07 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 22 Sep 2008 09:29:07 +0200 Subject: recover from broken yum transaction In-Reply-To: <46a038f90809212153w567f33ebn6f64a1b770ed9f8b@mail.gmail.com> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <20080921125955.GA31700@wolff.to> <20080921224234.GA5640@wolff.to> <20080922005130.GA19894@wolff.to> <46a038f90809212029l1dc6eff4wc69c1a896ef0135f@mail.gmail.com> <1222056465.12513.8.camel@rosebud> <20080922043156.GW18785@didacte.laptop.org> <1222058568.12513.11.camel@rosebud> <46a038f90809212153w567f33ebn6f64a1b770ed9f8b@mail.gmail.com> Message-ID: <1222068547.4152.29.camel@beck.corsepiu.local> On Mon, 2008-09-22 at 16:53 +1200, Martin Langhoff wrote: > On Mon, Sep 22, 2008 at 4:42 PM, Seth Vidal wrote: > > Not much - if it's OOM'ing the only real option is: > > 1. get more memory > > 2. have it use less memory > > > > if you want to pursue 2 that's fine - but to be very clear - everything > > after: > > Running RPM Transaction Test > > > > is in rpm-land as to trimming out memory/cpu usage. There's very little > > yum can do there. > > I *think* that what Michael is talking about is that when you get to > that point yum is still running and can be a substantial part of the > memory pressure. > > Perhaps yum's memory footprint could be trimmed? How much memory do you have? I am able to run yum (FC9) on an i586 w/ 64MB RAM and 256MB swap. In the past, yum occasionally had OOM'ed, but this hasn't happened for quite a while. The key to me had been to slim down the kernel memory requirements (Switching off SELinux worked wonders! This particular machine OOMs when booting with SELinux enabled) Ralf From konrad at tylerc.org Mon Sep 22 07:32:39 2008 From: konrad at tylerc.org (Conrad Meyer) Date: Mon, 22 Sep 2008 00:32:39 -0700 Subject: recover from broken yum transaction In-Reply-To: <1222068547.4152.29.camel@beck.corsepiu.local> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <46a038f90809212153w567f33ebn6f64a1b770ed9f8b@mail.gmail.com> <1222068547.4152.29.camel@beck.corsepiu.local> Message-ID: <200809220032.39342.konrad@tylerc.org> Quoth Ralf Corsepius: > On Mon, 2008-09-22 at 16:53 +1200, Martin Langhoff wrote: > > On Mon, Sep 22, 2008 at 4:42 PM, Seth Vidal wrote: > > > Not much - if it's OOM'ing the only real option is: > > > 1. get more memory > > > 2. have it use less memory > > > > > > if you want to pursue 2 that's fine - but to be very clear - everything > > > after: > > > Running RPM Transaction Test > > > > > > is in rpm-land as to trimming out memory/cpu usage. There's very little > > > yum can do there. > > > > I *think* that what Michael is talking about is that when you get to > > that point yum is still running and can be a substantial part of the > > memory pressure. > > > > Perhaps yum's memory footprint could be trimmed? > How much memory do you have? > > I am able to run yum (FC9) on an i586 w/ 64MB RAM and 256MB swap. > > In the past, yum occasionally had OOM'ed, but this hasn't happened for > quite a while. The key to me had been to slim down the kernel memory > requirements (Switching off SELinux worked wonders! This particular > machine OOMs when booting with SELinux enabled) > > Ralf Right, I run yum on a similar (i586, 128M of ram, plenty of swap) machine and it works great nowadays. Regards, -- Conrad Meyer From bnocera at redhat.com Mon Sep 22 07:45:21 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 22 Sep 2008 00:45:21 -0700 Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <1222066937.3186.18.camel@s1.crocom.com.pl> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221787714.3433.5.camel@ignacio.lan> <20080919104020.3958c1c5@ohm.scrye.com> <1221842915.5524.5.camel@hughsie-work> <1222066937.3186.18.camel@s1.crocom.com.pl> Message-ID: <1222069521.10497.3.camel@snoogens.fab.redhat.com> On Mon, 2008-09-22 at 09:02 +0200, Tomasz Torcz wrote: > Dnia 2008-09-19, pi? o godzinie 17:48 +0100, Richard Hughes pisze: > > On Fri, 2008-09-19 at 10:40 -0600, Kevin Fenzi wrote: > > > Would anyone care to take over tpb? Or does anyone even use it these > > > days? Perhaps we can just drop it? > > ThinkPads, just like any other model, should "just work" without any > > special daemons installed. > > My z61t isn't. Fn+number keys probably work (I pressed "lock" and > screen locked), but volume and mute keys do not work. When I press them > nothing happens - "xev" shows nothing and dmesg is silent. Those are slightly different, as they manipulate a hardware mixer directly. File a bug against the kernel, and CC: Richard on it, he'll know what to do :) From bnocera at redhat.com Mon Sep 22 07:50:00 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 22 Sep 2008 00:50:00 -0700 Subject: fun with metacity segfaults on rawhide eeepc In-Reply-To: <5256d0b0809211217jc36ca67x50bef0b1ecf7232a@mail.gmail.com> References: <5256d0b0809190816r705dafbboda1bf05843f31252@mail.gmail.com> <5256d0b0809190959o2b81b68ese04e595af340d4c8@mail.gmail.com> <91705d080809191009u4e52a126n91b3b4ce3e0da086@mail.gmail.com> <5256d0b0809191420g7f8972e1va44aa40d07608a76@mail.gmail.com> <45abe7d80809201338j1a783ab1lb942e7bea42bd43e@mail.gmail.com> <5256d0b0809211217jc36ca67x50bef0b1ecf7232a@mail.gmail.com> Message-ID: <1222069800.10497.5.camel@snoogens.fab.redhat.com> On Sun, 2008-09-21 at 20:17 +0100, Peter Robinson wrote: > On Sat, Sep 20, 2008 at 9:38 PM, Ray Strode wrote: > > Hi, > > > >> is it possible to change WM from the command line though? gconf or something? > > Just run desktop-effects and click the enable button. > > I can't as I don't get a desktop because metacity keeps segfaulting. There's probably more than just metacity crashing, otherwise the desktop would still be coming up. Might be the new gnome-session being a bit too bent on getting the window manager running and not throttling the launches. From pbrobinson at gmail.com Mon Sep 22 08:34:20 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 22 Sep 2008 09:34:20 +0100 Subject: fun with metacity segfaults on rawhide eeepc In-Reply-To: <1222069800.10497.5.camel@snoogens.fab.redhat.com> References: <5256d0b0809190816r705dafbboda1bf05843f31252@mail.gmail.com> <5256d0b0809190959o2b81b68ese04e595af340d4c8@mail.gmail.com> <91705d080809191009u4e52a126n91b3b4ce3e0da086@mail.gmail.com> <5256d0b0809191420g7f8972e1va44aa40d07608a76@mail.gmail.com> <45abe7d80809201338j1a783ab1lb942e7bea42bd43e@mail.gmail.com> <5256d0b0809211217jc36ca67x50bef0b1ecf7232a@mail.gmail.com> <1222069800.10497.5.camel@snoogens.fab.redhat.com> Message-ID: <5256d0b0809220134v169dfe18mae8f325f4ee74d7f@mail.gmail.com> >> > Hi, >> > >> >> is it possible to change WM from the command line though? gconf or something? >> > Just run desktop-effects and click the enable button. >> >> I can't as I don't get a desktop because metacity keeps segfaulting. > > There's probably more than just metacity crashing, otherwise the desktop > would still be coming up. Might be the new gnome-session being a bit too > bent on getting the window manager running and not throttling the > launches. That sounds like it could be possible as playing over the weekend I found it sometimes works and sometimes doesn't Peter From hughsient at gmail.com Mon Sep 22 08:39:14 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 22 Sep 2008 09:39:14 +0100 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222062817.30758.17.camel@code.and.org> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222062817.30758.17.camel@code.and.org> Message-ID: <1222072754.3330.0.camel@hughsie-work> On Mon, 2008-09-22 at 01:53 -0400, James Antill wrote: > But then 0.3.2 is still doing utterly broken direct SQL calls, and > failing *sigh*. Yes, that was ripped out when the fixed yum was pushed to F9. Richard. From hughsient at gmail.com Mon Sep 22 08:41:43 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 22 Sep 2008 09:41:43 +0100 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222066065.19471.6.camel@rousalka.okg> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> Message-ID: <1222072903.3330.3.camel@hughsie-work> On Mon, 2008-09-22 at 08:47 +0200, Nicolas Mailhot wrote: > The PK argument used to be comps groups suck, are distro-specific, > have no equivalent on some distros, so people should drop comps and > contribute to pk hardcoded stuff instead. Sure. PK groups are different to comps groups. There are tons of comps groups, and I wanted only a few that we can share between distros. There are other distros than fedora that will share these categories. > NIH syndrom IMHO NSFU (not suitable for us) actually. Richard. From hughsient at gmail.com Mon Sep 22 08:49:24 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 22 Sep 2008 09:49:24 +0100 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> Message-ID: <1222073364.3330.11.camel@hughsie-work> On Sun, 2008-09-21 at 21:33 +0000, Kevin Kofler wrote: > As you'll certainly ask me why, i.e. what's wrong with the current > implementation, here's it: With the current UI: > * there is no way to see what's in the collection, You get prompted with the full list when you try and install. You can use Get Dependencies on the collection if you want to know beforehand. > * it is inconsistent: both the comps.xml groups and the hardcoded categories > are lists of packages The hardcoded groups are not lists of packages, it's a map of comps groups to PK groups. > IMHO, a much better approach would be to: > * throw out the hardcoded categories! We have that information in comps.xml, > PackageKit should not try to duplicate it. It's not. Groups are a subset of the comps groups. I've done substantial user research, and I'm sorry to say fine grained categories _do not work_ with real users. None of the people in http://www.packagekit.org/pk-profiles.html could tell me what they expected to find in base-system/system-tools or base-system/admin-tools, or tell me the difference between them. > * add tristate checkboxes next to the groups, like in Anaconda: by default, > they're in the gray state, unless you have all packages installed (checked) or > none (unchecked); they can be checked or unchecked, which is equivalent to a > groupinstall or groupremove, but the only way to get them into the gray state > is to individually install or remove packages from the group (using the list > view on the right). That would be a usability disaster. Do you want to try explaining how a tristate checkbox works to any of the people on the profiles page? Richard. From martin.langhoff at gmail.com Mon Sep 22 09:07:58 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 22 Sep 2008 21:07:58 +1200 Subject: recover from broken yum transaction In-Reply-To: <200809220032.39342.konrad@tylerc.org> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <46a038f90809212153w567f33ebn6f64a1b770ed9f8b@mail.gmail.com> <1222068547.4152.29.camel@beck.corsepiu.local> <200809220032.39342.konrad@tylerc.org> Message-ID: <46a038f90809220207r65a9d021k7b19a73df2a8c1c3@mail.gmail.com> On Mon, Sep 22, 2008 at 7:32 PM, Conrad Meyer wrote: > Quoth Ralf Corsepius: >> I am able to run yum (FC9) on an i586 w/ 64MB RAM and 256MB swap. > Right, I run yum on a similar (i586, 128M of ram, plenty of swap) machine and > it works great nowadays. We're talking about OLPC's XOs - with 256 RAM and no swap. Our 'base working set' is about half of that - so 128MB is all there is to play with. We're trying hard to trim out base working set, but that's where we are now (and some dev builds have been much more hoggish). The kernel is a champ as long as there's memory. When memory pressure kicks in it all turns nasty pretty quickly... Anyway - I'm happy to test again in a more controlled test-case if Seth wants it, but at first blush it looks like yum is not releasing memory at a time when it could. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From caolanm at redhat.com Mon Sep 22 09:28:40 2008 From: caolanm at redhat.com (=?ISO-8859-1?Q?Caol=E1n?= McNamara) Date: Mon, 22 Sep 2008 10:28:40 +0100 Subject: recover from broken yum transaction In-Reply-To: <46a038f90809220207r65a9d021k7b19a73df2a8c1c3@mail.gmail.com> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <46a038f90809212153w567f33ebn6f64a1b770ed9f8b@mail.gmail.com> <1222068547.4152.29.camel@beck.corsepiu.local> <200809220032.39342.konrad@tylerc.org> <46a038f90809220207r65a9d021k7b19a73df2a8c1c3@mail.gmail.com> Message-ID: <1222075720.5617.5.camel@vain.rhgalway> On Mon, 2008-09-22 at 21:07 +1200, Martin Langhoff wrote: > at first blush it looks like yum is not releasing > memory at a time when it could. I guess its always possible that the unused memory hasn't been garbage collected by python yet. Happens a lot for anyone playing with pygtk pixbufs for example. Maybe experiment with whacking a great big gc.collect() at the end of depsolving to see if it makes a blind bit of difference. C. From choeger at cs.tu-berlin.de Mon Sep 22 09:32:47 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Mon, 22 Sep 2008 11:32:47 +0200 Subject: where does pulseaudio store session information? Message-ID: <1222075967.3326.4.camel@choeger6> Hi, I encounter the following behaviour: When I mute my notebook, after a reboot the sound is enabled at full volume level. That's annoying. I figured out that pulseaudio runs a rather small app named gconf-helper. The source code indicates that this app gets some gconf values from /system/pulseaudio/ but that key seems not to exist. So where (if at all) does pulseaudio store its data? regards christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From tomek at crocom.com.pl Mon Sep 22 09:46:17 2008 From: tomek at crocom.com.pl (Tomasz Torcz) Date: Mon, 22 Sep 2008 11:46:17 +0200 Subject: where does pulseaudio store session information? In-Reply-To: <1222075967.3326.4.camel@choeger6> References: <1222075967.3326.4.camel@choeger6> Message-ID: <1222076777.3186.25.camel@s1.crocom.com.pl> Dnia 2008-09-22, pon o godzinie 11:32 +0200, Christoph H?ger pisze: > Hi, > > I encounter the following behaviour: When I mute my notebook, after a > reboot the sound is enabled at full volume level. That's annoying. > I figured out that pulseaudio runs a rather small app named > gconf-helper. The source code indicates that this app gets some gconf > values from /system/pulseaudio/ but that key seems not to exist. > So where (if at all) does pulseaudio store its data? in ~/.pulse/volume-restore-table. But aren't volume levels supposed to be stored in /etc/asound.state by "alsactl store" invoked by init scripts on shutdown? And restored on boot by /etc/udev/rules.d/90-alsa.rules ? -- Tomasz Torcz From konrad at tylerc.org Mon Sep 22 09:46:53 2008 From: konrad at tylerc.org (Conrad Meyer) Date: Mon, 22 Sep 2008 02:46:53 -0700 Subject: recover from broken yum transaction In-Reply-To: <46a038f90809220207r65a9d021k7b19a73df2a8c1c3@mail.gmail.com> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <200809220032.39342.konrad@tylerc.org> <46a038f90809220207r65a9d021k7b19a73df2a8c1c3@mail.gmail.com> Message-ID: <200809220246.53879.konrad@tylerc.org> Quoth Martin Langhoff: > On Mon, Sep 22, 2008 at 7:32 PM, Conrad Meyer wrote: > > Quoth Ralf Corsepius: > >> I am able to run yum (FC9) on an i586 w/ 64MB RAM and 256MB swap. > > Right, I run yum on a similar (i586, 128M of ram, plenty of swap) machine and > > it works great nowadays. > > We're talking about OLPC's XOs - with 256 RAM and no swap. Our 'base > working set' is about half of that - so 128MB is all there is to play > with. We're trying hard to trim out base working set, but that's where > we are now (and some dev builds have been much more hoggish). > > The kernel is a champ as long as there's memory. When memory pressure > kicks in it all turns nasty pretty quickly... > > Anyway - I'm happy to test again in a more controlled test-case if > Seth wants it, but at first blush it looks like yum is not releasing > memory at a time when it could. > > cheers, > > > > m > -- > martin.langhoff at gmail.com > martin at laptop.org -- School Server Architect > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff Any reason for not having swap? Or if you don't want to use the disk all the time, perhaps create a swap file before doing updates with yum? But as you've said before, most users won't be using yum anyways (and even fewer users will actually be getting updates at all). Power users can easily add swap. Regards, -- Conrad Meyer From berrange at redhat.com Mon Sep 22 10:12:46 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 22 Sep 2008 11:12:46 +0100 Subject: [ANNOUNCE] Fedora MinGW - Windows cross-compiler for Fedora In-Reply-To: <20080921161040.GA3240@amd.home.annexia.org> References: <20080921161040.GA3240@amd.home.annexia.org> Message-ID: <20080922101246.GC22344@redhat.com> On Sun, Sep 21, 2008 at 05:10:40PM +0100, Richard W.M. Jones wrote: > [This project is still at a draft stage, but since we've put together > a test repository, hopefully people can now very easily try out what > we've been working on]. > > What is MinGW? > ---------------------------------------------------------------------- > MinGW is a C and C++ cross-compiler, based on gcc, that targets > Windows. > > What is Fedora MinGW? > ---------------------------------------------------------------------- > > The Fedora MinGW project's mission is to provide an excellent > development environment for Fedora users who wish to cross-compile > their programs to run on Windows, minimizing the need to use Windows > at all. In the past developers have had to port and compile all of > the libraries and tools they have needed, and this huge effort has > happened independently many times over. We aim to eliminate > duplication of work for application developers by providing a range of > libraries and development tools which have already been ported to the > cross-compiler environment. This means that developers will not need > to recompile the application stack themselves, but can concentrate > just on the changes needed to their own application. I'd like to point out that since our major announcement on the MinGW work we've been attempting to reduce the maintainence burden of carrying builds of various packages. eg the pain of keeping changes to 'libjpeg' in sync with changes to 'mingw-libjpeg'. We recognise that person maintaining the native Fedora version of the package may well not be the same person maintaining the mingw (or other cross compiled) versions. The key is thus enabling the maintainer of the cross compiled version to track changes. Our current experiment in this area is to write a python tool to compare two spec files and report on important differences - particularly those related to source versions / patches because closely following security patches is the single most important thing. Ensuring consistent versions, source URLs & licensing metdata is also pretty important. In the MinGW repo we've got a tool called 'compare.py' which takes 2 spec files and compares them and reports on likely problems Taking our current (broken) mingw-libxml2 specfile as an example $ python compare.py \ $HOME/src/fedora/libxml2/devel/libxml2.spec \ $HOME/src/fedora-mingw--devel/libxml2/mingw-libxml2.spec \ $HOME/src/fedora-mingw--devel/libxml2/compare.supp WARNING different version: 'libxml2': '2.7.1' != 'mingw-libxml2': '2.6.32' WARNING different license: 'libxml2': 'MIT' != 'mingw-libxml2': 'LGPLv2+' WARNING different URL: 'libxml2': 'http://xmlsoft.org/' != 'mingw-libxml2': 'http://www.xmlsoft.org/' WARNING missing source: 'libxml2-2.7.1.tar.gz' WARNING extra source: 'libxml2-2.6.32.tar.gz' WARNING missing patch 'libxml2-multilib.patch' So it can show that the mingw version has incorrect Licensing data, minor difference in URL, and is lagging the latest rawhide release. All things I need to fix before we submit this package to Fedora. The libxml2-multilib.patch is a irrelevant problem for mingw which doesn't care about multilib, so I can add that to the compare.supp suppressions file, so next time it'll not include that line noise. Once the Fedora MinGW is approved and starts to get into Fedora CVS, the aim will be to generate nightly reports on all mingw packages. This compare.py script could also be of use to any other cross-compiled archs added to Fedora such as ARM, or for people for fork the Fedora repos such as OLPC, to help them keep in sync. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From martin.langhoff at gmail.com Mon Sep 22 10:47:27 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 22 Sep 2008 22:47:27 +1200 Subject: recover from broken yum transaction In-Reply-To: <200809220246.53879.konrad@tylerc.org> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <200809220032.39342.konrad@tylerc.org> <46a038f90809220207r65a9d021k7b19a73df2a8c1c3@mail.gmail.com> <200809220246.53879.konrad@tylerc.org> Message-ID: <46a038f90809220347p30dbd60budd15230479f8155c@mail.gmail.com> On Mon, Sep 22, 2008 at 9:46 PM, Conrad Meyer wrote: > Any reason for not having swap? Or if you don't want to use the disk all the > time, perhaps create a swap file before doing updates with yum? Lots. We are running jffs2 on bare NAND. A NAND partition dedicated to a conventional swap would wear out badly. And jffs2 is a compressed fs (no per-file flag to disable compression) with very strange performance patterns -- a swapfile in there is bad news. > But as you've > said before, most users won't be using yum anyways (and even fewer users will > actually be getting updates at all). Power users can easily add swap. Well, we are using a homegrown update mechanism. It has some advantages over yum -- for starters, it works on our hw :-) . Let's say that the fact that yum+rpm do _not_ work on our hardware for large upgrades - due to memory issues - closes many avenues. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From rc040203 at freenet.de Mon Sep 22 11:06:24 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 22 Sep 2008 13:06:24 +0200 Subject: recover from broken yum transaction In-Reply-To: <46a038f90809220347p30dbd60budd15230479f8155c@mail.gmail.com> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <200809220032.39342.konrad@tylerc.org> <46a038f90809220207r65a9d021k7b19a73df2a8c1c3@mail.gmail.com> <200809220246.53879.konrad@tylerc.org> <46a038f90809220347p30dbd60budd15230479f8155c@mail.gmail.com> Message-ID: <1222081584.4152.60.camel@beck.corsepiu.local> On Mon, 2008-09-22 at 22:47 +1200, Martin Langhoff wrote: > On Mon, Sep 22, 2008 at 9:46 PM, Conrad Meyer wrote: > > Any reason for not having swap? Or if you don't want to use the disk all the > > time, perhaps create a swap file before doing updates with yum? > > Lots. We are running jffs2 on bare NAND. A NAND partition dedicated to > a conventional swap would wear out badly. And jffs2 is a compressed fs > (no per-file flag to disable compression) with very strange > performance patterns -- a swapfile in there is bad news. Why? You could create a temporary swapfile when launching yum and delete it afterwards. It would not cause more wear-out than any other dynamic file somewhere on the file system. > > But as you've > > said before, most users won't be using yum anyways (and even fewer users will > > actually be getting updates at all). Power users can easily add swap. > > Well, we are using a homegrown update mechanism. It has some > advantages over yum -- for starters, it works on our hw :-) . Let's > say that the fact that yum+rpm do _not_ work on our hardware for large > upgrades - due to memory issues - closes many avenues. Openly said, based on my experience with my i586, I don't buy this. Usually, the memory requirements introduced other applications are magnitudes above that of yum. However I am not sufficiently familiar with OPLC to be able to further comment on this. Ralf From rawhide at fedoraproject.org Mon Sep 22 11:17:38 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Mon, 22 Sep 2008 11:17:38 +0000 (UTC) Subject: rawhide report: 20080922 changes Message-ID: <20080922111738.E9CE11F825C@releng2.fedora.phx.redhat.com> Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Broken deps for i386 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.i386 requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so Broken deps for x86_64 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.x86_64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.ppc requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so Broken deps for ppc64 ---------------------------------------------------------- eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) gspiceui-0.9.65-2.fc10.ppc64 requires gwave livecd-tools-018-1.fc10.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.ppc64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) yum-refresh-updatesd-1.1.16-2.fc10.noarch requires yum-updatesd From tim.lauridsen at googlemail.com Mon Sep 22 11:31:01 2008 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Mon, 22 Sep 2008 13:31:01 +0200 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222062817.30758.17.camel@code.and.org> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222062817.30758.17.camel@code.and.org> Message-ID: <48D781F5.3090304@googlemail.com> James Antill wrote: > On Sun, 2008-09-21 at 19:05 +0200, Tim Lauridsen wrote: > >> The groups in comps.xml is used as meta-packages, there can be installed >> and removed. just like yum groupinstall/groupremove. > > But that's not how groupinstall/groupremove works! Groups are _very_ > different from meta-packages, for instance: > > yum shell < install @x-software-development > remove libXaw-devel > run > EOL > in the pk yum backend a "meta package" the same as a yum group. InstallPackages('x-software-development;meta;meta;meta') will do the same as 'yum install @x-software-development" but on other package managers it can be something else. > But then 0.3.2 is still doing utterly broken direct SQL calls, and > failing *sigh*. > it is fixed in 0.3.3 Tim From skvidal at fedoraproject.org Mon Sep 22 11:55:31 2008 From: skvidal at fedoraproject.org (Seth Vidal) Date: Mon, 22 Sep 2008 07:55:31 -0400 Subject: recover from broken yum transaction In-Reply-To: References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <20080921125955.GA31700@wolff.to> <20080921224234.GA5640@wolff.to> <20080922005130.GA19894@wolff.to> Message-ID: <1222084531.12513.14.camel@rosebud> On Mon, 2008-09-22 at 01:05 -0300, Alexandre Oliva wrote: > On Sep 21, 2008, Bruno Wolff III wrote: > > > There seems to be two problems you are referring to. One is convenient > > remote management and the other is transactions not being atomic. > > I'm actually talking about a third problem: that yum starts removing > packages just because of an error in reporting progress to > stdout/stderr. Everything else was just context to trigger the > problem. So let's clear a few things up: 1. Once the transaction starts 'yum' isn't doing anything. It is reporting what rpm is doing. 2. The only things it is possible for rpm to do is what is in the transaction set and the user agrees to perform by hitting 'y' So, if you have a case where pkgs are being removed that you have not agreed to remove, please file a bug with details. -sv From u0103a at gmail.com Mon Sep 22 12:50:37 2008 From: u0103a at gmail.com (jude ui) Date: Mon, 22 Sep 2008 08:50:37 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: <80d7e4090809211419p78edad66k18a297ab151e0b25@mail.gmail.com> References: <8553.1220772699@sss.pgh.pa.us> <200809071523.44582.ben.kreuter@gmail.com> <604aa7910809071240u1923df65i8861e58de856540b@mail.gmail.com> <604aa7910809211144s77460d18se7d6620518c4db56@mail.gmail.com> <80d7e4090809211419p78edad66k18a297ab151e0b25@mail.gmail.com> Message-ID: <91157db90809220550t16d83231ne525edaf55ad17a6@mail.gmail.com> wow we really got of topic ;) -ginki -------------- next part -------------- An HTML attachment was scrubbed... URL: From selinux at gmail.com Mon Sep 22 13:38:15 2008 From: selinux at gmail.com (Tom London) Date: Mon, 22 Sep 2008 06:38:15 -0700 Subject: where does pulseaudio store session information? In-Reply-To: <1222076777.3186.25.camel@s1.crocom.com.pl> References: <1222075967.3326.4.camel@choeger6> <1222076777.3186.25.camel@s1.crocom.com.pl> Message-ID: <4c4ba1530809220638g47fb1ecl2329e0b90a8b7da2@mail.gmail.com> On Mon, Sep 22, 2008 at 2:46 AM, Tomasz Torcz wrote: > Dnia 2008-09-22, pon o godzinie 11:32 +0200, Christoph H?ger pisze: >> Hi, >> >> I encounter the following behaviour: When I mute my notebook, after a >> reboot the sound is enabled at full volume level. That's annoying. >> I figured out that pulseaudio runs a rather small app named >> gconf-helper. The source code indicates that this app gets some gconf >> values from /system/pulseaudio/ but that key seems not to exist. > >> So where (if at all) does pulseaudio store its data? > > in ~/.pulse/volume-restore-table. But aren't volume levels supposed to > be stored in /etc/asound.state by "alsactl store" invoked by init > scripts on shutdown? And restored on boot > by /etc/udev/rules.d/90-alsa.rules ? > > -- > Tomasz Torcz > Not sure if it's related, but I discovered that /etc/asound.state was AWOL on my system, and that I had to reset volume levels each reboot. I ran the following as root to recreate it: alsactl store 0; restorecon -v /etc/asound.state tom -- Tom London From dtimms at iinet.net.au Mon Sep 22 14:14:28 2008 From: dtimms at iinet.net.au (David Timms) Date: Tue, 23 Sep 2008 00:14:28 +1000 Subject: [solved]: Re: package maintenance from multiple PCs ? In-Reply-To: <1222052552.3534.2.camel@fantail.jnet.net.nz> References: <48D5F3E0.7050307@iinet.net.au> <1222007954.3433.90.camel@ignacio.lan> <48D6C9C5.8050901@iinet.net.au> <1222046897.3433.105.camel@ignacio.lan> <1222052552.3534.2.camel@fantail.jnet.net.nz> Message-ID: <48D7A844.5070906@iinet.net.au> Nigel Jones wrote: > On Sun, 2008-09-21 at 21:28 -0400, Ignacio Vazquez-Abrams wrote: >>> Which id parts are used by cvs, koji, bodhi ? >> I'm not certain about this, but cvs is your ssh key, koji is your SSL >> cert, and I'm not sure what bodhi uses. > Bodhi uses json over HTTPS (and your normal FAS password) iirc OK, thanks Nigel and Ignacio, for that info. DaveT. From tomek at crocom.com.pl Mon Sep 22 14:14:59 2008 From: tomek at crocom.com.pl (Tomasz Torcz) Date: Mon, 22 Sep 2008 16:14:59 +0200 Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <1222069521.10497.3.camel@snoogens.fab.redhat.com> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221787714.3433.5.camel@ignacio.lan> <20080919104020.3958c1c5@ohm.scrye.com> <1221842915.5524.5.camel@hughsie-work> <1222066937.3186.18.camel@s1.crocom.com.pl> <1222069521.10497.3.camel@snoogens.fab.redhat.com> Message-ID: <1222092899.3186.29.camel@s1.crocom.com.pl> Dnia 2008-09-22, pon o godzinie 00:45 -0700, Bastien Nocera pisze: > > > > My z61t isn't. Fn+number keys probably work (I pressed "lock" and > > screen locked), but volume and mute keys do not work. When I press them > > nothing happens - "xev" shows nothing and dmesg is silent. > > Those are slightly different, as they manipulate a hardware mixer > directly. File a bug against the kernel, and CC: Richard on it, he'll > know what to do :) Done, as https://bugzilla.redhat.com//show_bug.cgi?id=463141 Sorry Richard for adding you work at monday morning :) -- Tomasz Torcz Crocom Computer Systems From hun at n-dimensional.de Mon Sep 22 14:41:25 2008 From: hun at n-dimensional.de (Hans Ulrich Niedermann) Date: Mon, 22 Sep 2008 16:41:25 +0200 Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <20080921124554.5bd81d16@infradead.org> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221842915.5524.5.camel@hughsie-work> <45771.198.175.55.5.1221843217.squirrel@mail.jcomserv.net> <200809201216.09552.opensource@till.name> <1221981305.4240.12.camel@snoogens.fab.redhat.com> <20080921124554.5bd81d16@infradead.org> Message-ID: <48D7AE95.6060608@n-dimensional.de> Arjan van de Ven wrote: > as a sidenote: do you know which part of gnome does the brightness OSD? > because that part really needs to talk to gnome-power-manager! > > (right now you have the behavior where if I as user crank the > brightness up, say because of bad light, it works for like 20 seconds > and then g-p-m comes in and things I want to dimm my screen again to > the battery level. Same for the other direction) https://bugzilla.redhat.com/show_bug.cgi?id=445760 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From vonbrand at inf.utfsm.cl Sun Sep 21 23:51:28 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 21 Sep 2008 19:51:28 -0400 Subject: [ANNOUNCE] Fedora MinGW - Windows cross-compiler for Fedora In-Reply-To: <20080921161040.GA3240@amd.home.annexia.org> References: <20080921161040.GA3240@amd.home.annexia.org> Message-ID: <200809212351.m8LNpSVN007375@laptop14.inf.utfsm.cl> Richard W.M. Jones wrote: > [This project is still at a draft stage, but since we've put together > a test repository, hopefully people can now very easily try out what > we've been working on]. > > What is MinGW? > ---------------------------------------------------------------------- > MinGW is a C and C++ cross-compiler, based on gcc, that targets > Windows. Congratulations! Not that I'm in any need of this right now, but I hope the project will do well. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Mon Sep 22 01:39:08 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 21 Sep 2008 21:39:08 -0400 Subject: MinGW In-Reply-To: <604aa7910809201407n3b495f52w22ba35f7b929bfd4@mail.gmail.com> References: <1220977399.4252.22.camel@kennedy> <20080910115657.GA25796@amd.home.annexia.org> <20080910140307.GA23069@yoda.jdub.homelinux.org> <20080910150226.GA14299@amd.home.annexia.org> <1221931609.4837.17.camel@localhost.localdomain> <48D546C1.4050801@gmail.com> <604aa7910809201303i565e8e60i19c63467bb3ac854@mail.gmail.com> <20080920204206.GA3187@vader.jdub.homelinux.org> <604aa7910809201407n3b495f52w22ba35f7b929bfd4@mail.gmail.com> Message-ID: <200809220139.m8M1d8r2009023@laptop14.inf.utfsm.cl> Jeff Spaleta wrote: > On Sat, Sep 20, 2008 at 12:42 PM, Josh Boyer wrote: > > I belive (and I stated as much in the FESCo meeting where we talked about > > this briefly), that the crux of the issue with your proposal is the "needs > > to build natively" item. That is the issue FESCo needs to further consider, > > along with the packaging guidelines that the MinGW SIG is drafting. > > I fully accept that this issue needs thought. And your right, this > cross compiling stuff is different. I'm fully aware that I'm muddying > the waters with analogies to 2ndary arches. But its the only > comparison my pea-sized brain is capable of finding and holding on to > to as a reference point as we pilot this steam boat up river into > unknown waters. Toshio asked for an explanation of my thinking...i've > given it. If the reasoning doesn't make sense to anyone else, > continuing to ask me to re-explain my thinking is probably not going > to particularly fruitful...until we find an interpreter who is fluent > in Jef-speak. Perhaps you should accept this /is/ new waters, and not try to find analogies elsewhere. Analogies have a way of misleading. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Sun Sep 21 23:27:54 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 21 Sep 2008 19:27:54 -0400 Subject: Orange Sombrero 9 Released - based on Fedora In-Reply-To: <48D5F875.6040004@fedoraproject.org> References: <48D5A299.6000908@kanarip.com> <48D5F695.6060607@kiewel-online.de> <48D5F875.6040004@fedoraproject.org> Message-ID: <200809212327.m8LNRswF007184@laptop14.inf.utfsm.cl> Luya Tshimbalanga wrote: > Uwe Kiewel a ??crit : > > Sorry for the question. What *is* sombrero!? > Mexican hat. No. It is just Spanish for "hat". -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From hughsient at gmail.com Mon Sep 22 14:47:36 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 22 Sep 2008 15:47:36 +0100 Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <20080921124554.5bd81d16@infradead.org> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221842915.5524.5.camel@hughsie-work> <45771.198.175.55.5.1221843217.squirrel@mail.jcomserv.net> <200809201216.09552.opensource@till.name> <1221981305.4240.12.camel@snoogens.fab.redhat.com> <20080921124554.5bd81d16@infradead.org> Message-ID: <1222094856.24063.0.camel@hughsie-work> On Sun, 2008-09-21 at 12:45 -0700, Arjan van de Ven wrote: > (right now you have the behavior where if I as user crank the > brightness up, say because of bad light, it works for like 20 seconds > and then g-p-m comes in and things I want to dimm my screen again to > the battery level. Same for the other direction) Ii this with rawhide or F9? Richard. From mclasen at redhat.com Mon Sep 22 13:15:36 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 22 Sep 2008 09:15:36 -0400 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222066065.19471.6.camel@rousalka.okg> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> Message-ID: <1222089336.3818.0.camel@localhost.localdomain> On Mon, 2008-09-22 at 08:47 +0200, Nicolas Mailhot wrote: > Le lundi 22 septembre 2008 ? 07:01 +0200, Thorsten Leemhuis a ?crit : > > On 21.09.2008 23:33, Kevin Kofler wrote: > > > Tim Lauridsen googlemail.com> writes: > > > [...] > > > IMHO, a much better approach would be to: > > > * throw out the hardcoded categories! We have that information in compsxml, > > > PackageKit should not try to duplicate it. > > The PK argument used to be comps groups suck, are distro-specific, have > no equivalent on some distros, so people should drop comps and > contribute to pk hardcoded stuff instead. Where did you get that idea ? From krh at redhat.com Mon Sep 22 15:09:38 2008 From: krh at redhat.com (Kristian =?ISO-8859-1?Q?H=F8gsberg?=) Date: Mon, 22 Sep 2008 11:09:38 -0400 Subject: modesetting feature status In-Reply-To: <5f6f8c5f0809192118r6d3df87au3193b000296b4099@mail.gmail.com> References: <5f6f8c5f0809111209o1d28bae4p246d699f3520c40@mail.gmail.com> <5f6f8c5f0809120305y41ac861fq8a91d1547519a955@mail.gmail.com> <5f6f8c5f0809171136lb722a87taee2cbd5afc2ff29@mail.gmail.com> <1221683977.15981.223.camel@atropine.boston.devel.redhat.com> <48D1D978.7020102@shmuelhome.mine.nu> <3da3b5b40809180036o33ad4e27h328ba1740bf03ade@mail.gmail.com> <48D2070C.7010508@fedoraproject.org> <5f6f8c5f0809191057m23688c2by287052700b94312b@mail.gmail.com> <20080919184502.GA4545@yoda.jdub.homelinux.org> <5f6f8c5f0809192118r6d3df87au3193b000296b4099@mail.gmail.com> Message-ID: <1222096178.3802.12.camel@gaara.bos.redhat.com> On Sat, 2008-09-20 at 06:18 +0200, Joshua C. wrote: > 2008/9/19 Josh Boyer : > > On Fri, Sep 19, 2008 at 07:57:34PM +0200, Joshua C. wrote: > >>I tried `strace -o /drm.strace modprobe drm debug=1` and got the > >>output in the attached file. I tried the same with `strace -o > >>/radeon.trace modprobe radeon modeset=1` but this time there's nothing > >>in the file. How can I hook strace to the radeon driver? > > > > You can't. All you're stracing is the modprobe command, not the driver > > operation. > > > > Drivers don't operate in userspace, and don't make system calls. So strace > > just plain doesn't work. > > > > josh > > > Ok, I cannot use ssh (just one mashine). What other options do I have > to debug this thing? There should be a way to do this with just one > computer. > I read somewhere that the 2.6.26 kernel have some "new debugger" or > so. I just need to make it write down the process to a file. After > restart I can send you the log. > After the drive loads I can only hard reset the computer. And if > everything is in the ram, then I have to dump it to a file. Any other > ideas? When you're debugging graphics drivers that may crash and leave random garbage on your screen, you generally need to ssh in from a second computer. Also, for kernel modesetting, you'll have to resort to printk-debugging for the most cases and put up with a lot of rebooting. The easiest way to debug this is to clone Daves kernel tree from here http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git and then check out the drm-rawhide branch. Something like this: $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git $ git checkout -b drm-rawhide origin/drm-rawhide Or you may want to start from the drm-rawhide branch in my kernel repo here: people.freedesktop.org/~krh/linux-2.6, which have a couple of fixes that Dave hasn't pulled yet - or maybe he just didn't push them to the kernel.org repo. They're in rawhide though. You then need the kernel-devel rpm for the kernel you're running and then you should be able to build just the drm drivers from the kernel tree against your current kernel like this: $ make -C /lib/modules/$(uname -r)/build M=~/src/drm-2.6/drivers/gpu/drm assuming your kernel tree clone lives in ~/src/drm-2.6. Use $ insmod ~/src/drm-2.6/drivers/gpu/drm/drm.ko debug=1 $ insmod ~/src/drm-2.6/drivers/gpu/drm/radeon/radeon.ko modeset=1 to load the drivers with debugging and modesetting enabled. This will let you change and recompile the drivers quickly and you can now add printk statements (or use the DRM_ERROR macro) in the code to see how far it gets etc. Good luck :) Kristian From nathanael at gnat.ca Mon Sep 22 16:15:41 2008 From: nathanael at gnat.ca (Nathanael D. Noblet) Date: Mon, 22 Sep 2008 10:15:41 -0600 Subject: Instant Mirror Status...? Message-ID: <48D7C4AD.7040308@gnat.ca> Hello, I've become increasingly interested in a simple updates mirroring system to proxy/store updates for a number of fedora machines on our network. I searched google and found the instant mirror project, but it seemed somewhat dead. Is it still alive? Did some other solution replace it? -- Nathanael d. Noblet Gnat Solutions, Inc T: 403.875.4613 From skvidal at fedoraproject.org Mon Sep 22 16:24:09 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 22 Sep 2008 12:24:09 -0400 Subject: Instant Mirror Status...? In-Reply-To: <48D7C4AD.7040308@gnat.ca> References: <48D7C4AD.7040308@gnat.ca> Message-ID: <1222100649.12513.71.camel@rosebud> On Mon, 2008-09-22 at 10:15 -0600, Nathanael D. Noblet wrote: > Hello, > I've become increasingly interested in a simple updates mirroring > system to proxy/store updates for a number of fedora machines on our > network. I searched google and found the instant mirror project, but it > seemed somewhat dead. Is it still alive? Did some other solution replace it? > Take a look at intelligent mirror. A GSoC project by Kulbir Saini. https://fedorahosted.org/intelligentmirror/ -sv From arjan at infradead.org Mon Sep 22 16:28:52 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Mon, 22 Sep 2008 09:28:52 -0700 Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <1222094856.24063.0.camel@hughsie-work> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221842915.5524.5.camel@hughsie-work> <45771.198.175.55.5.1221843217.squirrel@mail.jcomserv.net> <200809201216.09552.opensource@till.name> <1221981305.4240.12.camel@snoogens.fab.redhat.com> <20080921124554.5bd81d16@infradead.org> <1222094856.24063.0.camel@hughsie-work> Message-ID: <20080922092852.50575110@infradead.org> On Mon, 22 Sep 2008 15:47:36 +0100 Richard Hughes wrote: > On Sun, 2008-09-21 at 12:45 -0700, Arjan van de Ven wrote: > > (right now you have the behavior where if I as user crank the > > brightness up, say because of bad light, it works for like 20 > > seconds and then g-p-m comes in and things I want to dimm my screen > > again to the battery level. Same for the other direction) > > Ii this with rawhide or F9? F9 rawhide is a little too rough for my production machine still ;0 -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org From jkeating at redhat.com Mon Sep 22 16:41:37 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 22 Sep 2008 09:41:37 -0700 Subject: rawhide report: 20080921 changes In-Reply-To: <1222010239.2987.2.camel@scrappy.miketc.net> References: <20080921093603.AAD1B1F825F@releng2.fedora.phx.redhat.com> <1222010239.2987.2.camel@scrappy.miketc.net> Message-ID: <1222101697.4108.8.camel@luminos.localdomain> On Sun, 2008-09-21 at 10:17 -0500, Mike Chambers wrote: > The Language selection screen was fixed and worked this time, good job. > But, the network selection screen still has problems. When manually > configuring network (IP, netmask, etc..) you get error about network > itself, and when trying dhcp you get an exception. Not able to save > them so no files or anything to show you what they were. This was a > normal Rawhide install using boot.iso via nfs and doing so graphically. Did you file a bug on this? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mike at miketc.net Mon Sep 22 17:18:48 2008 From: mike at miketc.net (Mike Chambers) Date: Mon, 22 Sep 2008 12:18:48 -0500 Subject: rawhide report: 20080921 changes In-Reply-To: <1222101697.4108.8.camel@luminos.localdomain> References: <20080921093603.AAD1B1F825F@releng2.fedora.phx.redhat.com> <1222010239.2987.2.camel@scrappy.miketc.net> <1222101697.4108.8.camel@luminos.localdomain> Message-ID: <1222103928.2584.9.camel@scrappy.miketc.net> On Mon, 2008-09-22 at 09:41 -0700, Jesse Keating wrote: > On Sun, 2008-09-21 at 10:17 -0500, Mike Chambers wrote: > > The Language selection screen was fixed and worked this time, good job. > > But, the network selection screen still has problems. When manually > > configuring network (IP, netmask, etc..) you get error about network > > itself, and when trying dhcp you get an exception. Not able to save > > them so no files or anything to show you what they were. This was a > > normal Rawhide install using boot.iso via nfs and doing so graphically. > > Did you file a bug on this? No, I wanted to see if it was known already. And I think I saw someone post on test list about network issues coming up from stage2 and was known, and that I think you can put in update=garbage.url paramater and that brings up the network earlier during the install instead of waiting to help bypass the problem for now. https://www.redhat.com/archives/fedora-test-list/2008-September/msg00479.html I think that is the problem I am having currently. -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From tcallawa at redhat.com Mon Sep 22 17:18:43 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 22 Sep 2008 13:18:43 -0400 Subject: rawhide report: 20080921 changes In-Reply-To: <20080921093603.AAD1B1F825F@releng2.fedora.phx.redhat.com> References: <20080921093603.AAD1B1F825F@releng2.fedora.phx.redhat.com> Message-ID: <1222103923.3555.67.camel@localhost.localdomain> On Sun, 2008-09-21 at 09:36 +0000, Rawhide Report wrote: > gscan2pdf-0.9.24-1.fc10.noarch requires perl(Gtk2::ImageView) Not sure why this is occurring. [spot at localhost devel]$ koji latest-pkg dist-f10 perl-Gtk2-ImageView Build Tag Built by ---------------------------------------- -------------------- ---------------- perl-Gtk2-ImageView-0.04-2.fc10 dist-f10 spot [spot at localhost devel]$ rpm -q perl-Gtk2-ImageView --provides ImageView.so()(64bit) perl(Gtk2::ImageView) = 0.04 perl(Gtk2::ImageView::Install::Files) perl-Gtk2-ImageView = 0.04-2.fc10 perl-Gtk2-ImageView(x86-64) = 0.04-2.fc10 ~spot From tcallawa at redhat.com Mon Sep 22 17:20:35 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 22 Sep 2008 13:20:35 -0400 Subject: Mono 2.0 in F10 In-Reply-To: <1222015292.10041.7.camel@PB3.Linux> References: <1222015292.10041.7.camel@PB3.Linux> Message-ID: <1222104035.3555.68.camel@localhost.localdomain> On Sun, 2008-09-21 at 17:41 +0100, Paul wrote: > Hi, > > I've been informed that Mono 2.0 RC3 is due out next week (RC3 is going > to be the actual release from what I've been told). > > If it is out next week, can we get it pushed for inclusion into F10 (it > is mostly bug fixes over the version currently in rawhide, so testing > will need to be minimal)? It will mean that when F10 is released, it > will have something that not even OpenSuSE will have, the proper Mono > 2.0 in - a big bonus for us! As long as you keep that silverlight/moonlight stuff disabled, I see no problems here. ~spot From jkeating at redhat.com Mon Sep 22 17:22:39 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 22 Sep 2008 10:22:39 -0700 Subject: rawhide report: 20080921 changes In-Reply-To: <1222103923.3555.67.camel@localhost.localdomain> References: <20080921093603.AAD1B1F825F@releng2.fedora.phx.redhat.com> <1222103923.3555.67.camel@localhost.localdomain> Message-ID: <1222104159.4108.10.camel@luminos.localdomain> On Mon, 2008-09-22 at 13:18 -0400, Tom "spot" Callaway wrote: > dist-f10 And what about for f10-beta ? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From lesmikesell at gmail.com Mon Sep 22 16:58:05 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 22 Sep 2008 11:58:05 -0500 Subject: Instant Mirror Status...? In-Reply-To: <1222100649.12513.71.camel@rosebud> References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> Message-ID: <48D7CE9D.20601@gmail.com> seth vidal wrote: > On Mon, 2008-09-22 at 10:15 -0600, Nathanael D. Noblet wrote: >> Hello, >> I've become increasingly interested in a simple updates mirroring >> system to proxy/store updates for a number of fedora machines on our >> network. I searched google and found the instant mirror project, but it >> seemed somewhat dead. Is it still alive? Did some other solution replace it? >> > > Take a look at intelligent mirror. A GSoC project by Kulbir Saini. > > https://fedorahosted.org/intelligentmirror/ Is there still no way to make yum default to behaving intelligently by itself in the presence of a caching proxy? All it really needs to do is use the same mirror as the last person chose so the URLs will match. -- Les Mikesell lesmikesell at gmail.com From tcallawa at redhat.com Mon Sep 22 17:29:02 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 22 Sep 2008 13:29:02 -0400 Subject: rawhide report: 20080921 changes In-Reply-To: <1222104159.4108.10.camel@luminos.localdomain> References: <20080921093603.AAD1B1F825F@releng2.fedora.phx.redhat.com> <1222103923.3555.67.camel@localhost.localdomain> <1222104159.4108.10.camel@luminos.localdomain> Message-ID: <1222104542.3555.69.camel@localhost.localdomain> On Mon, 2008-09-22 at 10:22 -0700, Jesse Keating wrote: > On Mon, 2008-09-22 at 13:18 -0400, Tom "spot" Callaway wrote: > > dist-f10 > > And what about for f10-beta ? You said that you tagged it for the beta. :) ~spot From gmaxwell at gmail.com Mon Sep 22 17:36:22 2008 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Mon, 22 Sep 2008 13:36:22 -0400 Subject: Instant Mirror Status...? In-Reply-To: <48D7CE9D.20601@gmail.com> References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> Message-ID: On Mon, Sep 22, 2008 at 12:58 PM, Les Mikesell wrote: > Is there still no way to make yum default to behaving intelligently by > itself in the presence of a caching proxy? All it really needs to do is use > the same mirror as the last person chose so the URLs will match. How would it know? From jkeating at redhat.com Mon Sep 22 17:42:14 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 22 Sep 2008 10:42:14 -0700 Subject: Further recommended slip of Beta, and Fedora 10 schedule Message-ID: <1222105334.4108.17.camel@luminos.localdomain> After a week(end) of hacking, we're just not there yet for Beta. There are a few more anaconda issues that we're tracking down: * Network installs where network needs to be brought up in stage2 * Installs via Media * Doing something with tracebacks We're fairly confident that we've got fixes for these issues, but given the current timeline we'd rather have a few more days of testing rather than rush something out that doesn't work. The Release Engineering team is recommending a slip of the Beta release date to Tuesday Sept 30th. To go along with this slip, we recommend that all further points of the Fedora 10 schedule slip out a week as well, which would put the Fedora 10 release date at November 25th. While we realize that this is a Holiday week for the vast majority of people in the United States of America, the work for Fedora 10 would have to have been completed by Nov 20th in order to release on the 25th so there should not be (many) schedule conflicts. Any further slipping of the schedule will slip around this holiday week. FESCo will need to ACK this schedule change, and we are also making sure this schedule doesn't conflict with (m)any thing(s) at Red Hat, and other distributions. An announcement of the schedule change will be made when it is fully approved. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From janina at rednote.net Mon Sep 22 18:00:01 2008 From: janina at rednote.net (Janina Sajka) Date: Mon, 22 Sep 2008 14:00:01 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <1221647994.1454.16.camel@gibraltar.str.redhat.com> References: <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> Message-ID: <20080922180001.GA8379@sonata.rednote.net> I've been meaning to comment on your multi-seat setup ... Nils Philippsen writes: > On Tue, 2008-09-16 at 17:28 -0400, Janina Sajka wrote: > > Matthias Clasen writes: > > > On Tue, 2008-09-16 at 14:34 -0400, Janina Sajka wrote: > [...] > > > > > > > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented > > > > from doing so, paplay believes it should pause playing while I'm away > > > > from the gui tty. Now, who's the genius that figured out this "feature?" > > > > > > Insults won't help your cause. > > Well, my apologies if this offends you. Is it supposed to work that way, > > though? Is there actually a use case for that behavior? Or is this just > > some incidental artifact? > > There is a use case for this, namely if you have several "seats" with > different logged in users: in this case one probably only wants the > sounds of the "active session" being played and others muted. Just in > case you ask, we're using that setup at home, my wife and I are logged > in all the time an switch between users via the applet or > F7/F9. > I don't believe it necessarily follows that technology should enforce who does, and who does not have audio in this circumstance. Consider an office environment--perhaps it's similar to what you and your wife have. There are several desks with chairs. Perhaps these are in an open room. Perhaps there are dividers between the desks to provide a small measure of privacy. Each desk in this scenario is undoubtedly equipped with a telephone. No one would think that the occupant of Desk B should be denied telephone calls just because the occupant of Desk A is on the phone. Technology is not required to enforce appropriate social behavior in this circumstance. The humans who work in this environment have learned appropriate behaviors in the past century. Why is the computer desktop so different? What compells us to require that technology enforce no audio for B while A is provided audio? Perhaps the users want to listen to voice mail attachments received via email. Even four or five feet separation is sufficient to do so. We don't need technology to do for us such things as we humans clearly know how to negotiate for ourselves. Indeed, it seems to me precluding multiseat audio is one way of saying that Fedora does not support telephone answering environments--airline reservations, bank customer support, etc., etc. What am I missing here? Janina From cra at WPI.EDU Mon Sep 22 18:17:24 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 22 Sep 2008 14:17:24 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080922180001.GA8379@sonata.rednote.net> References: <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <20080922180001.GA8379@sonata.rednote.net> Message-ID: <20080922181724.GI31922@angus.ind.WPI.EDU> On Mon, Sep 22, 2008 at 02:00:01PM -0400, Janina Sajka wrote: > I don't believe it necessarily follows that technology should enforce > who does, and who does not have audio in this circumstance. I don't think fast-user-switching as described above is really multi-seat. For true multi-seat, yes, of course each seat would have its own audio. For a single-seat, fast-user-switching scenario, there needs to be a way to revoke audio from the first session when a new user logs into a second session, or when users toggles between different sessions. Otherwise there is a privacy problem where user A could run a program that records the Mic input of the soundcard, user B activates their session, and user A can record all sounds that user B makes. From jkeating at redhat.com Mon Sep 22 18:20:15 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 22 Sep 2008 11:20:15 -0700 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222072903.3330.3.camel@hughsie-work> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> Message-ID: <1222107615.4108.23.camel@luminos.localdomain> On Mon, 2008-09-22 at 09:41 +0100, Richard Hughes wrote: > NSFU (not suitable for us) actually. What's your definition of "us"? Showing the users one set of package information during install, and then a completely different one after install is not suitable either. Is "not suitable for us" supposed to mean that PK is trying to hard to be generic across the distros so that we lose the classifications and groupings we work on in Fedora, so that PK is not suitable for Fedora? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Sep 22 18:22:25 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 22 Sep 2008 11:22:25 -0700 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222073364.3330.11.camel@hughsie-work> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222073364.3330.11.camel@hughsie-work> Message-ID: <1222107745.4108.24.camel@luminos.localdomain> On Mon, 2008-09-22 at 09:49 +0100, Richard Hughes wrote: > > It's not. Groups are a subset of the comps groups. I've done substantial > user research, and I'm sorry to say fine grained categories _do not > work_ with real users. None of the people in > http://www.packagekit.org/pk-profiles.html could tell me what they > expected to find in base-system/system-tools or base-system/admin-tools, > or tell me the difference between them. So your solution is to invent something else entirely, rather than helping Fedora clean up its groupings definitions? Really? Nice. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From aoliva at redhat.com Mon Sep 22 18:29:35 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Mon, 22 Sep 2008 15:29:35 -0300 Subject: Fedora not "free" enough for GNU? In-Reply-To: <80d7e4090809211419p78edad66k18a297ab151e0b25@mail.gmail.com> (Stephen John Smoogen's message of "Sun\, 21 Sep 2008 15\:19\:36 -0600") References: <8553.1220772699@sss.pgh.pa.us> <200809071523.44582.ben.kreuter@gmail.com> <604aa7910809071240u1923df65i8861e58de856540b@mail.gmail.com> <604aa7910809211144s77460d18se7d6620518c4db56@mail.gmail.com> <80d7e4090809211419p78edad66k18a297ab151e0b25@mail.gmail.com> Message-ID: On Sep 21, 2008, "Stephen John Smoogen" wrote: > you expect them to follow you without question. I'm not sure what leads you to this conclusion. I can see reasons to support the other claims, but not for this one. I'm quite open to questioning (too open and too willing to answer, I guess you'd all agree), and I'd be more than happy (too happy, indeed :-) to answer questions as to my motivations, goals and positions. What I seem to be facing is the exact opposite situation: (some) people in charge are unhappy for being questioned on a decision that, to me, doesn't make sense. > unlike a good prophet you expect them to do the work for you. Make > an Orange Sombrero or some hat from Brazil. Show that it can be done > and maintained.. and then you will have something to point to. Erhm... I've *already* done the work, at least the part that others hadn't done before, and I've already pointed at them a number of times. I've also offered to linux-libre packages for Fedora? In fact, that was the first thing I did when linux-libre came up. And I've been doing that ever since, although under the name freed-ora, because Fedora proper rejected it. You can see more info about the project and maintenance at http://fsfla.org/selibre/linux-libre/freed-ora As for actual distros, gNewSense and BLAG use linux-libre, and they have since before I joined it. Now there are more. Besides, BLAG happens to be based on Fedora, as you probably know, so there's little point in creating yet another distro just to prove this point. And then, this would do little to liberate Fedora users. You see, it doesn't make much sense to try that elsewhere, given that the goal is to improve Fedora. I'm very surprised this meets so much resistence. Even if my way of presenting the suggestions causes strong antagonistic reactions, one would think the stated goals of the project would eventually prevail and dominate the feelings the things I write seem to evoke. But they don't, and I can't quite understand why. I can understand "we don't want a kernel-libre variant, we're just now finally getting rid of the kernel-xen maintained separately, and it still hurts". I can understand "we don't want people's computers to stop working because the non-Free firmware is gone", even though I don't quite agree with this stance. But I have no evidence that people who object to this move even looked at the list of affected modules before raising the objection. And then, although back when this started a few oddball components would indeed miss the firmwares, and be disabled from the build because of that (which wouldn't stop people from building the modules on their own), nowadays both kernel.org and linux-libre's kernel sources let you ship the firmware separately, and the modules will pick it up. I can understand "we don't want to have more maintenance work because of this issue", but this shouldn't be an issue when someone offers to do the maintenance work for you. I can understand "we don't want to diverge from upstream", but tracking a slightly cleaned-up version that tracks upstream very closely isn't quite diverging. I can understand "we're concerned the project might just disappear and then we'd be left out in the cold", but linux-libre tracks upstream so closely as to be interchangeable, and the changes required to adopt it (or to drop it) are no-brainers. I can understand "we're not in a hurry, and upstream is taking care of it for us", but there's no indication that upstream will follow through or even is trying to address the same problem, and meanwhile there is a solution that we could adopt right now, even if temporarily, so this position comes off as "we don't care enough about this". I could understand if someone wrote "you attack us and disturb us, why should we take your suggestions or your package?", but I'd hope Fedora's decisions would at least try to separate the messenger from the message. I could understand if someone wrote "given your background and political agenda, if it's you maintaining this package, then it must be too radical for us", but given the considerations above, I'd consider this foolish. I could understand if someone wrote "look, we just don't want to do this, shut the fsck up and go away", but the "don't want to" is a consequence of the actual reasons, which are precisely what I'm trying to understand. What is it that I'm missing to understand the rejection of a Free kernel for Fedora 10? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From aoliva at redhat.com Mon Sep 22 18:47:39 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Mon, 22 Sep 2008 15:47:39 -0300 Subject: recover from broken yum transaction In-Reply-To: <1222084531.12513.14.camel@rosebud> (Seth Vidal's message of "Mon\, 22 Sep 2008 07\:55\:31 -0400") References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <20080921125955.GA31700@wolff.to> <20080921224234.GA5640@wolff.to> <20080922005130.GA19894@wolff.to> <1222084531.12513.14.camel@rosebud> Message-ID: On Sep 22, 2008, Seth Vidal wrote: > On Mon, 2008-09-22 at 01:05 -0300, Alexandre Oliva wrote: >> On Sep 21, 2008, Bruno Wolff III wrote: >> >> > There seems to be two problems you are referring to. One is convenient >> > remote management and the other is transactions not being atomic. >> >> I'm actually talking about a third problem: that yum starts removing >> packages just because of an error in reporting progress to >> stdout/stderr. Everything else was just context to trigger the >> problem. > So let's clear a few things up: > 1. Once the transaction starts 'yum' isn't doing anything. It is > reporting what rpm is doing. It's precisely when yum's reporting fails that the situation arises. > 2. The only things it is possible for rpm to do is what is in the > transaction set and the user agrees to perform by hitting 'y' Right. The problem is when you agree to "update x", i.e., "install x-N+1; remove x-N', and it fails (say, in case sys.stdout.write or sys.stdout.flush raise an exception within callback) before it gets to install x-N+1. Then RPM still ends up removing x-N, although sometimes what I saw looked more like a --justdb removal (files and libraries left behind, but package gone from the rpmdb), but in others, as in the most recent case, elfutils libraries were really gone. > So, if you have a case where pkgs are being removed that you have not > agreed to remove, please file a bug with details. In the scenario above, would you say you agreed to remove x-N or not? I.e., does it pass the condition you set for a bug report to be filed? Could it be the solution is as simple as guarding (exception-wise) sys.stdout calls in callbacks, to avoid exception leakage that could get the rpm transaction aborted in this way? (I'm not sufficiently versed in Python to know whether write or flush will raise exceptions). -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From kanarip at kanarip.com Mon Sep 22 18:48:24 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 22 Sep 2008 20:48:24 +0200 Subject: Orange Sombrero 9 Released - based on Fedora In-Reply-To: <200809210032.39921.konrad@tylerc.org> References: <48D5A299.6000908@kanarip.com> <48D5F695.6060607@kiewel-online.de> <200809210032.39921.konrad@tylerc.org> Message-ID: <48D7E878.9050708@kanarip.com> Conrad Meyer wrote: > Quoth Uwe Kiewel: >> Jeroen van Meeuwen schrieb: >>> One more Software Freedom Day well spent ;-) >>> >>> I'm proud to announce a new minor player in the world of insignificant >>> clones of major, important Free and Open Source Linux Distributions, >>> >>> *bling* Orange Sombrero - /based on Fedora/ *bling* >> >> Sorry for the question. What *is* sombrero!? >> >> TIA, >> Uwe > > Apparently it's a spin that adds the ability to easily rebrand parts of Fedora > (i.e. anaconda). > So, that's not it. It's single feature is that it is being released as "Based on Fedora". Everything else you read about it is a matter of convenience, no technical requirement or feature whatsoever. Kind regards, Jeroen van Meeuwen -kanarip From kanarip at kanarip.com Mon Sep 22 18:50:30 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Mon, 22 Sep 2008 20:50:30 +0200 Subject: Orange Sombrero 9 Released - based on Fedora In-Reply-To: <48D6645A.80000@shaw.ca> References: <48D5A299.6000908@kanarip.com> <48D6645A.80000@shaw.ca> Message-ID: <48D7E8F6.1050200@kanarip.com> Jerry Vonau wrote: > Since this variant of revisor is a single CD distro, any reason to have > boot.iso in /images? Could gain +100megs for other stuff to fit in > boot.iso's place. Might help Martin at xs-olpc with his quest for a > single cd distro, and will most likely be a user of the re-branding > offered. > We could probably nuke boot.iso if we really wanted to, but that's not the point behind Orange Sombrero. I guess we're working with Martin to enable his (very important!) use-case on fedora-buildsys-list also. Kind regards, Jeroen van Meeuwen -kanarip From skvidal at fedoraproject.org Mon Sep 22 18:52:15 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 22 Sep 2008 14:52:15 -0400 Subject: recover from broken yum transaction In-Reply-To: References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <20080921125955.GA31700@wolff.to> <20080921224234.GA5640@wolff.to> <20080922005130.GA19894@wolff.to> <1222084531.12513.14.camel@rosebud> Message-ID: <1222109535.12513.81.camel@rosebud> On Mon, 2008-09-22 at 15:47 -0300, Alexandre Oliva wrote: > Right. The problem is when you agree to "update x", i.e., "install > x-N+1; remove x-N', and it fails (say, in case sys.stdout.write or > sys.stdout.flush raise an exception within callback) before it gets to > install x-N+1. Then RPM still ends up removing x-N, although > sometimes what I saw looked more like a --justdb removal (files and > libraries left behind, but package gone from the rpmdb), but in > others, as in the most recent case, elfutils libraries were really > gone. The above really isn't possible. If you can recreate this then please file a bug. File the bug against rpm but please cc me on it. > > So, if you have a case where pkgs are being removed that you have not > > agreed to remove, please file a bug with details. > > In the scenario above, would you say you agreed to remove x-N or not? > I.e., does it pass the condition you set for a bug report to be filed? If you have a case where x-N is being removed w/o x-N+1 being installed then yes, file a bug. -sv From ajax at redhat.com Mon Sep 22 19:19:27 2008 From: ajax at redhat.com (Adam Jackson) Date: Mon, 22 Sep 2008 15:19:27 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: References: <8553.1220772699@sss.pgh.pa.us> <200809071523.44582.ben.kreuter@gmail.com> <604aa7910809071240u1923df65i8861e58de856540b@mail.gmail.com> <604aa7910809211144s77460d18se7d6620518c4db56@mail.gmail.com> <80d7e4090809211419p78edad66k18a297ab151e0b25@mail.gmail.com> Message-ID: <1222111167.15981.358.camel@atropine.boston.devel.redhat.com> On Mon, 2008-09-22 at 15:29 -0300, Alexandre Oliva wrote: > I'm very surprised this meets so much resistence. Even if my way of > presenting the suggestions causes strong antagonistic reactions, one > would think the stated goals of the project would eventually prevail > and dominate the feelings the things I write seem to evoke. > > But they don't, and I can't quite understand why. Partly because statements like "But they don't, and I can't quite understand why" makes you sound like you have a phenomenal persecution complex, which triggers the crazy-person filter. Particularly when you're addressing a problem that is not universally agreed to be a problem at all. (Please don't take this as an invitation to try to convince me.) But, now for a real technical objection: atropine:~% uname -a Linux atropine 2.6.27-0.314.rc5.git9.fc10.i686 #1 SMP Sun Sep 7 20:57:41 EDT 2008 i686 i686 i386 GNU/Linux atropine:~% modinfo -F firmware aic7xxx | wc -l 0 Apparently there is still not yet a reliable way to determine firmware requirements for modules that you may need to load to mount the root filesystem. It would be really nice to have that, so we can build an initramfs that will, you know, boot. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From a.badger at gmail.com Mon Sep 22 19:31:29 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 22 Sep 2008 12:31:29 -0700 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <48D74445.3030900@leemhuis.info> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <48D74445.3030900@leemhuis.info> Message-ID: <48D7F291.1010502@gmail.com> Thorsten Leemhuis wrote: > On 22.09.2008 08:49, Alex Lancaster wrote: >> Ideally this would be done either as a mandatory part of the original >> CVS import request (a field could be added, with an opt-out provision >> if really not appropriate for comps), or added interactively by the >> maintainer via PackageDB as I suggested in the feature request here: >> https://fedorahosted.org/packagedb/ticket/78#comment:1 > > Hmmmm. How much does the pkgdb know about the binary packages that get > build from the source packages? Not much afaics, as the pkgdb mainly > (only?) works with the (source) packages and not the ones that get build > from it -- but in a proper comps.xml we need to list the binary > packages, as a user might want to select the packages (rpms) foo or bar > that both might get build from the package (srpm) foobar. > >> Having to manually update the comps.xml file for multiple releases is >> painful, error-prone and probably why most package maintainers ignore >> it, especially since it is not enforced in package reviews. > +1 So here's where I'm at WRT binary packages. We have too many apps interested in doing only a subset of the work in this area. There's amber which is going to provide an end user view of applications (rather than packages) with categories and tags. There's Fedora collection which probably won't have a permanent data store of its own. There's PackageDB which oculd be expanded to handle this (it has tables for binary packages but is unfilled with data). There's koji which touches every binary package, consumes and generates comps files. There's comps.xml which is the master store for this information right now. There's repoview which provides a static interface to binary packages and comps on the gold repo but not yet updates -- if it is updated to work on updates, that will require bodhi to write out the files. So: 1) In which app should the canonical storage for this reside? 2) What interface do we want to put on top of the storage? 3) What apps will need to pull data from there once we have it? -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From pemboa at gmail.com Mon Sep 22 19:03:41 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 22 Sep 2008 14:03:41 -0500 Subject: Instant Mirror Status...? In-Reply-To: References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> Message-ID: <16de708d0809221203o4cd9e78xf91b3ebd77ee9f0@mail.gmail.com> On Mon, Sep 22, 2008 at 12:36 PM, Gregory Maxwell wrote: > On Mon, Sep 22, 2008 at 12:58 PM, Les Mikesell wrote: >> Is there still no way to make yum default to behaving intelligently by >> itself in the presence of a caching proxy? All it really needs to do is use >> the same mirror as the last person chose so the URLs will match. > > How would it know? Well unless its a transparent proxy, yum.conf will have the proxy variable set. -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From mzerqung at 0pointer.de Mon Sep 22 20:28:07 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Mon, 22 Sep 2008 22:28:07 +0200 Subject: where does pulseaudio store session information? In-Reply-To: <1222075967.3326.4.camel@choeger6> References: <1222075967.3326.4.camel@choeger6> Message-ID: <20080922202807.GA525@tango.0pointer.de> On Mon, 22.09.08 11:32, Christoph H?ger (choeger at cs.tu-berlin.de) wrote: > Hi, > > I encounter the following behaviour: When I mute my notebook, after a > reboot the sound is enabled at full volume level. That's annoying. > I figured out that pulseaudio runs a rather small app named > gconf-helper. The source code indicates that this app gets some gconf > values from /system/pulseaudio/ but that key seems not to exist. > So where (if at all) does pulseaudio store its data? PA stores it's state in ~/.pulse. GConf is used for configuration, not for state. You can use it for everything that is exposed in the "paprefs" tool. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From aoliva at redhat.com Mon Sep 22 20:32:35 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Mon, 22 Sep 2008 17:32:35 -0300 Subject: Fedora not "free" enough for GNU? In-Reply-To: <1222111167.15981.358.camel@atropine.boston.devel.redhat.com> (Adam Jackson's message of "Mon\, 22 Sep 2008 15\:19\:27 -0400") References: <8553.1220772699@sss.pgh.pa.us> <200809071523.44582.ben.kreuter@gmail.com> <604aa7910809071240u1923df65i8861e58de856540b@mail.gmail.com> <604aa7910809211144s77460d18se7d6620518c4db56@mail.gmail.com> <80d7e4090809211419p78edad66k18a297ab151e0b25@mail.gmail.com> <1222111167.15981.358.camel@atropine.boston.devel.redhat.com> Message-ID: On Sep 22, 2008, Adam Jackson wrote: > Partly because statements like "But they don't, and I can't quite > understand why" makes you sound like you have a phenomenal persecution > complex, which triggers the crazy-person filter. The reason I've focused on whatever effect I might have on the rejection of the message is that this possibility was brought up. It's not something I made up myself and, although I don't reject the possibility that it plays a significant role, I'm looking for other possibilities as well. I suspect this one is just as significant: > a problem that is not universally agreed to be a problem at all. in spite of Fedora's stated goals. > (Please don't take this as an invitation to try to convince me.) :-) > But, now for a real technical objection: > atropine:~% uname -a > Linux atropine 2.6.27-0.314.rc5.git9.fc10.i686 #1 SMP Sun Sep 7 20:57:41 > EDT 2008 i686 i686 i386 GNU/Linux > atropine:~% modinfo -F firmware aic7xxx | wc -l > 0 Erhm... Are you sure aic7xxx was built with any expectation of loading firmware through the standard firmware-loading interface, rather than of having it built right into the kernel image? $ uname -r 2.6.27-libre.0.337.rc6.git5.fc10.x86_64 $ modinfo -F firmware snd-maestro3 ess/maestro3_assp_minisrc.fw ess/maestro3_assp_kernel.fw -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From mzerqung at 0pointer.de Mon Sep 22 20:37:00 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Mon, 22 Sep 2008 22:37:00 +0200 Subject: where does pulseaudio store session information? In-Reply-To: <1222076777.3186.25.camel@s1.crocom.com.pl> References: <1222075967.3326.4.camel@choeger6> <1222076777.3186.25.camel@s1.crocom.com.pl> Message-ID: <20080922203700.GB525@tango.0pointer.de> On Mon, 22.09.08 11:46, Tomasz Torcz (tomek at crocom.com.pl) wrote: > > Dnia 2008-09-22, pon o godzinie 11:32 +0200, Christoph H?ger pisze: > > Hi, > > > > I encounter the following behaviour: When I mute my notebook, after a > > reboot the sound is enabled at full volume level. That's annoying. > > I figured out that pulseaudio runs a rather small app named > > gconf-helper. The source code indicates that this app gets some gconf > > values from /system/pulseaudio/ but that key seems not to exist. > > > So where (if at all) does pulseaudio store its data? > > in ~/.pulse/volume-restore-table. But aren't volume levels supposed to > be stored in /etc/asound.state by "alsactl store" invoked by init > scripts on shutdown? And restored on boot > by /etc/udev/rules.d/90-alsa.rules ? Please note that on Rawhide PA actually stores the stream volume tables in ~/.pulse/:stream-volumes..gdbm. We include the D-Bus machine id in the name because of NFS safety. The build arch is included in the name because gdbm files are arch-dependant. PA from rawhide always saves/restores device volumes in ~/.pulse/:device-volumes..gdbm. We don't rely on alsactl store for (at least) three reasons: 1) I believe that volume information should be a user and not a system setting. 2) When an ALSA audio device is unplugged it is already too late to save its volume if we just use alsactl. Since PA is running continouisly and caches the volume setting we can save the volume when it changes. 3) Many audio devices support only very limited volume control: the minimal volume is not actually silence, no seperate per-channel volumes are supported, only very few levels are supported. PA will always extend the hardware volume range in software and thus exposes the same volume capabilities on all hardware, even the most limited one. However, since PA's volume settings are thus not necessarily in the range the hardware supports and we thus cannot rely on "alsactl store" doing the job for us. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From casimiro.barreto at gmail.com Mon Sep 22 20:37:51 2008 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Mon, 22 Sep 2008 17:37:51 -0300 Subject: pam_mount is still buggy Message-ID: <48D8021F.7020906@gmail.com> pam_mount (pam_mount-0.48-2.fc9.i386) is not able to get the password while trying to mount an encrypted filesystem... I guess few people uses encrypted systems over loop devices... Anyways... That's what is shown in /var/log/messages: When logging from KDM: Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(pam_mount.c:258) pam_mount 0.48: entering auth stage Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(pam_mount.c:268) could not get password from PAM system Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(pam_mount.c:190) enter read_password Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(pam_mount.c:293) saving authtok for session code (authtok=0x98b7630) Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(pam_mount.c:436) pam_mount 0.48: entering session stage Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(pam_mount.c:457) back from global readconfig Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(pam_mount.c:459) per-user configurations not allowed by pam_mount.conf.xml Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(misc.c:46) Session open: (uid=0, euid=0, gid=501, egid=501) Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(rdconf2.c:190) checking sanity of volume record (/home/.xxx.img) Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(pam_mount.c:511) about to perform mount operations Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:364) information for mount: Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:365) ---------------------- Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:366) (defined by globalconf) Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:367) user: xxx Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:368) server: (null) Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:369) volume: /home/.xxx.img Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:370) mountpoint: /home/xxx Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:371) options: loop,encryption=aes-cbc-256,rw Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:372) fs_key_cipher: aes-256-cbc Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:373) fs_key_path: /etc/pki/cryptofs/.xxx.key Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:374) use_fstab: 0 Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:375) ---------------------- Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:151) realpath of volume "/home/xxx" is "/home/xxx" Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:155) checking to see if /home/.xxx.img is already mounted at /home/casimiro Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:824) checking for encrypted filesystem key configuration Sep 22 17:21:30 terra kdm: :0[3192]: pam_mount(mount.c:831) decrypting FS key using system auth. token and aes-256-cbc Sep 22 17:21:31 terra kdm[3143]: *Unknown session exit code 0 (sig 6) from manager process* When logging from console: Sep 22 17:21:39 terra login: pam_mount(pam_mount.c:258) pam_mount 0.48: entering auth stage Sep 22 17:21:39 terra login: pam_mount(pam_mount.c:268) could not get password from PAM system Sep 22 17:21:39 terra login: pam_mount(pam_mount.c:190) enter read_password Sep 22 17:21:44 terra login: pam_mount(pam_mount.c:293) saving authtok for session code (authtok=0x87e24d8) Sep 22 17:21:44 terra login: pam_mount(pam_mount.c:436) pam_mount 0.48: entering session stage Sep 22 17:21:44 terra login: pam_mount(pam_mount.c:457) back from global readconfig Sep 22 17:21:44 terra login: pam_mount(pam_mount.c:459) per-user configurations not allowed by pam_mount.conf.xml Sep 22 17:21:44 terra login: pam_mount(misc.c:46) Session open: (uid=0, euid=0, gid=0, egid=0) Sep 22 17:21:44 terra login: pam_mount(rdconf2.c:190) checking sanity of volume record (/home/.xxx.img) Sep 22 17:21:44 terra login: pam_mount(pam_mount.c:511) about to perform mount operations Sep 22 17:21:44 terra login: pam_mount(mount.c:364) information for mount: Sep 22 17:21:44 terra login: pam_mount(mount.c:365) ---------------------- Sep 22 17:21:44 terra login: pam_mount(mount.c:366) (defined by globalconf) Sep 22 17:21:44 terra login: pam_mount(mount.c:367) user: casimiro Sep 22 17:21:44 terra login: pam_mount(mount.c:368) server: (null) Sep 22 17:21:44 terra login: pam_mount(mount.c:369) volume: /home/.xxx.img Sep 22 17:21:44 terra login: pam_mount(mount.c:370) mountpoint: /home/xxx Sep 22 17:21:44 terra login: pam_mount(mount.c:371) options: loop,encryption=aes-cbc-256,rw Sep 22 17:21:44 terra login: pam_mount(mount.c:372) fs_key_cipher: aes-256-cbc Sep 22 17:21:44 terra login: pam_mount(mount.c:373) fs_key_path: /etc/pki/cryptofs/.xxx.key Sep 22 17:21:44 terra login: pam_mount(mount.c:374) use_fstab: 0 Sep 22 17:21:44 terra login: pam_mount(mount.c:375) ---------------------- Sep 22 17:21:44 terra login: pam_mount(mount.c:151) realpath of volume "/home/xxx" is "/home/xxx" Sep 22 17:21:44 terra login: pam_mount(mount.c:155) checking to see if /home/.xxx.img is already mounted at /home/xxx Sep 22 17:21:44 terra login: pam_mount(mount.c:824) checking for encrypted filesystem key configuration Sep 22 17:21:44 terra login: pam_mount(mount.c:831) decrypting FS key using system auth. token and aes-256-cbc Sep 22 17:21:44 terra init: *tty1 main process (3154) **killed by ABRT signal* Sep 22 17:21:44 terra init: tty1 main process ended, respawning The /etc/security/pam_mount.conf.xml is: /usr/sbin/lsof %(MNTPT) /sbin/fsck -p %(FSCKTARGET) /sbin/losetup -p0 "%(before=\"-e\" CIPHER)" "%(before=\"-k\" KEYBITS)" %(FSCKLOOP) %(VOLUME) /sbin/losetup -d %(FSCKLOOP) /bin/mount -t cifs //%(SERVER)/%(VOLUME) %(MNTPT) -o "user=%(USER),uid=%(USERUID),gid=%(USERGID)%(before=\",\" OPTIONS)" /usr/bin/smbmount //%(SERVER)/%(VOLUME) %(MNTPT) -o "username=%(USER),uid=%(USERUID),gid=%(USERGID)%(before=\",\" OPTIONS)" /usr/bin/ncpmount %(SERVER)/%(USER) %(MNTPT) -o "pass-fd=0,volume=%(VOLUME)%(before=\",\" OPTIONS)" /usr/bin/smbumount %(MNTPT) /usr/bin/ncpumount %(MNTPT) /sbin/mount.fuse %(VOLUME) %(MNTPT) "%(before=\"-o\" OPTIONS)" /usr/bin/fusermount -u %(MNTPT) /bin/umount %(MNTPT) /bin/mount -p0 -t %(FSTYPE) %(VOLUME) %(MNTPT) "%(before=\"-o\" OPTIONS)" /bin/mount -t crypt "%(before=\"-o\" OPTIONS)" %(VOLUME) %(MNTPT) /bin/mount %(SERVER):%(VOLUME) %(MNTPT) "%(before=\"-o\" OPTIONS)" /bin/mount /usr/sbin/pmvarrun -u %(USER) -o %(OPERATION) Of note is that pam_mount was working about 3 weeks ago... Except it refused to unmount the volumes when user logged off. BTW, after Sept 19 updates rhgb stop working properly (X crashes). -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From hughsient at gmail.com Mon Sep 22 20:34:25 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 22 Sep 2008 21:34:25 +0100 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222107615.4108.23.camel@luminos.localdomain> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> Message-ID: <1222115665.24063.14.camel@hughsie-work> On Mon, 2008-09-22 at 11:20 -0700, Jesse Keating wrote: > On Mon, 2008-09-22 at 09:41 +0100, Richard Hughes wrote: > > NSFU (not suitable for us) actually. > > What's your definition of "us"? Showing the users one set of package > information during install, and then a completely different one after > install is not suitable either. Surely with a live CD we don't show the user any sets of groups at all? > Is "not suitable for us" supposed to mean that PK is trying to hard to > be generic across the distros so that we lose the classifications and > groupings we work on in Fedora, so that PK is not suitable for Fedora? No, we keep the groupings as the yum backend supports them as part of "collections". I'm just not showing the giant tree of arbitrary classifications as the main point of user interaction. Richard. From mike at flyn.org Mon Sep 22 20:46:03 2008 From: mike at flyn.org (W. Michael Petullo) Date: Mon, 22 Sep 2008 16:46:03 -0400 (EDT) Subject: pam_mount is still buggy In-Reply-To: <48D8021F.7020906@gmail.com> References: <48D8021F.7020906@gmail.com> Message-ID: <8d601c9757566dc068a5e6fba5703303.squirrel@mail.voxel.net> > Of note is that pam_mount was working about 3 weeks ago... Except it > refused to unmount the volumes when user logged off. I am no longer the maintainer of pam_mount (upstream or package), but I can address this part of your issue. The pam_mount module will not be able to unmount a home directory if processes still remain with open file descriptors in the directory. Last I looked, many user daemons (e.g., gconf?) remained for a few seconds or minutes after a user logged out. If you look through GNOME and Red Hat's bugzilla, you will see a couple of examples of this that were fixed. You will also find some examples that were never fixed upstream. It used to be that you could instruct pam_mount to run lsof and log the output to help troubleshoot this. I don't know if this feature is still available, but it would identify which processes are causing the problem. Mike From hughsient at gmail.com Mon Sep 22 20:43:10 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 22 Sep 2008 21:43:10 +0100 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222107745.4108.24.camel@luminos.localdomain> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222073364.3330.11.camel@hughsie-work> <1222107745.4108.24.camel@luminos.localdomain> Message-ID: <1222116190.24063.24.camel@hughsie-work> On Mon, 2008-09-22 at 11:22 -0700, Jesse Keating wrote: > So your solution is to invent something else entirely, rather than > helping Fedora clean up its groupings definitions? Really? Nice. No. PK groups are made up _from_ the comps groups. There are just an order of magnitude less options, and it's a flat list rather than a tree. Comps supports optional, mandatory, suggested and the sort of power user stuff that I just don't want to support in PackageKit. For me to "clean up the groups" would be to rip out all optional groups, rip out most of the obscure categories and add lots of packages with lots of extra deps. I'm sure that's not what you want me to do with comps at all. If you want to actually help with this stuff, can I suggest you join the PackageKit mailing list and discuss there? Fedora isn't the only consumer of PackageKit, and I'm keen on working upstream on ideas and policies with other distros rather than just defending decisions made upstream that affect fedora. And just correcting you: this wasn't _my_ decision, this was the result of working with lots of other distros. Sarcasm doesn't help anybody. Richard. From kevin.kofler at chello.at Mon Sep 22 20:49:22 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 22 Sep 2008 20:49:22 +0000 (UTC) Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> Message-ID: Richard Hughes gmail.com> writes: > Sure. PK groups are different to comps groups. There are tons of comps > groups, and I wanted only a few that we can share between distros. There > are other distros than fedora that will share these categories. But those "tons of comps groups" need to be shown! For example PackageKit isn't showing the KDE Software Development group at all. We need that group shown (and as a group, not a metapackage). Kevin Kofler From kevin.kofler at chello.at Mon Sep 22 20:55:27 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 22 Sep 2008 20:55:27 +0000 (UTC) Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> Message-ID: Richard Hughes gmail.com> writes: > On Mon, 2008-09-22 at 11:20 -0700, Jesse Keating wrote: > > What's your definition of "us"? Showing the users one set of package > > information during install, and then a completely different one after > > install is not suitable either. > > Surely with a live CD we don't show the user any sets of groups at all? But that's not the only way to install Fedora. > > Is "not suitable for us" supposed to mean that PK is trying to hard to > > be generic across the distros so that we lose the classifications and > > groupings we work on in Fedora, so that PK is not suitable for Fedora? > > No, we keep the groupings as the yum backend supports them as part of > "collections". I'm just not showing the giant tree of arbitrary > classifications as the main point of user interaction. Those "arbitrary" classifications are what Fedora maintainers work hard to keep up to date and complete, unlike your incomplete hardcoded classifications in PackageKit which are truly arbitrary and do not reflect how Fedora intends to categorize its packages. It doesn't make sense to have distro-independent categories of packages, categories are defined by the distributions, they should be read from the appropriate distro-specific classification by the PackageKit backend. For example, does it make sense to show a KDE resp. GNOME category for a distribution which doesn't even ship KDE resp. GNOME, maybe with a single package (think of a GNOME distribution shipping e.g. Amarok or K3b as its only KDE app)? And distributions with more packages will necessarily have more categories! Fedora has many packages, PackageKit's categories don't even come close to covering all of them. Kevin Kofler From kevin.kofler at chello.at Mon Sep 22 20:57:12 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 22 Sep 2008 20:57:12 +0000 (UTC) Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222089336.3818.0.camel@localhost.localdomain> Message-ID: Matthias Clasen redhat.com> writes: > > On Mon, 2008-09-22 at 08:47 +0200, Nicolas Mailhot wrote: > > The PK argument used to be comps groups suck, are distro-specific, have > > no equivalent on some distros, so people should drop comps and > > contribute to pk hardcoded stuff instead. > > Where did you get that idea ? Just read Richard Hughes's interventions in this thread. Kevin Kofler From kevin.kofler at chello.at Mon Sep 22 21:00:34 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 22 Sep 2008 21:00:34 +0000 (UTC) Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> Message-ID: Jesse Keating redhat.com> writes: > Is "not suitable for us" supposed to mean that PK is trying to hard to > be generic across the distros so that we lose the classifications and > groupings we work on in Fedora, so that PK is not suitable for Fedora? I agree that that's about the only conclusion we can draw. Kevin Kofler From mclasen at redhat.com Mon Sep 22 21:05:41 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 22 Sep 2008 17:05:41 -0400 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> Message-ID: <1222117541.5988.1.camel@localhost.localdomain> On Mon, 2008-09-22 at 20:55 +0000, Kevin Kofler wrote: > > Those "arbitrary" classifications are what Fedora maintainers work hard to keep > up to date and complete, unlike your incomplete hardcoded classifications in > PackageKit which are truly arbitrary and do not reflect how Fedora intends to > categorize its packages. What makes you think that the comps classifications are less arbitrary ? And isn't one of the original motivations for this thread that many packagers are exactly _not_ doing that hard work ?! From kevin.kofler at chello.at Mon Sep 22 21:09:21 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 22 Sep 2008 21:09:21 +0000 (UTC) Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222073364.3330.11.camel@hughsie-work> Message-ID: Richard Hughes gmail.com> writes: > That would be a usability disaster. Do you want to try explaining how a > tristate checkbox works to any of the people on the profiles page? How else do you want to represent a group? A group can be partially installed, you can't just show it as not installed (then how do you represent uninstalling it?) or installed (then how do you represent installing it completely?), showing a group as not installed or as installed when it's actually partially installed is going to confuse users. Tristate checkboxes are a very common UI to represent groups where a more detailed selection is available, many Window$ installers use them (and those are surely targeted at the average user!), as does Anaconda (or at least used to do). A tristate in the gray state is a clear hint that you have to go to the details to see what exactly is selected and unselected. Kevin Kofler From billcrawford1970 at gmail.com Mon Sep 22 21:13:11 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Mon, 22 Sep 2008 22:13:11 +0100 Subject: Instant Mirror Status...? In-Reply-To: <16de708d0809221203o4cd9e78xf91b3ebd77ee9f0@mail.gmail.com> References: <48D7C4AD.7040308@gnat.ca> <16de708d0809221203o4cd9e78xf91b3ebd77ee9f0@mail.gmail.com> Message-ID: <200809222213.11691.billcrawford1970@gmail.com> On Monday 22 September 2008 20:03:41 Arthur Pemberton wrote: > On Mon, Sep 22, 2008 at 12:36 PM, Gregory Maxwell wrote: > > On Mon, Sep 22, 2008 at 12:58 PM, Les Mikesell wrote: > >> Is there still no way to make yum default to behaving intelligently by > >> itself in the presence of a caching proxy? All it really needs to do is > >> use the same mirror as the last person chose so the URLs will match. > > > > How would it know? > > Well unless its a transparent proxy, yum.conf will have the proxy variable > set. I think he meant, how would it know what the last mirror was? From kevin.kofler at chello.at Mon Sep 22 21:04:53 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 22 Sep 2008 21:04:53 +0000 (UTC) Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222073364.3330.11.camel@hughsie-work> <1222107745.4108.24.camel@luminos.localdomain> <1222116190.24063.24.camel@hughsie-work> Message-ID: Richard Hughes gmail.com> writes: > No. PK groups are made up _from_ the comps groups. There are just an > order of magnitude less options, and it's a flat list rather than a > tree. Comps supports optional, mandatory, suggested and the sort of > power user stuff that I just don't want to support in PackageKit. So you want PackageKit to be useless for power users? Then what should power users use? > For me to "clean up the groups" would be to rip out all optional groups, > rip out most of the obscure categories and add lots of packages with > lots of extra deps. I'm sure that's not what you want me to do with > comps at all. The optional groups all exist for a reason, they shouldn't be removed, but they also shouldn't be hidden (which for an end user is essentially the same as removing). > If you want to actually help with this stuff, can I suggest you join the > PackageKit mailing list and discuss there? Fedora isn't the only > consumer of PackageKit, and I'm keen on working upstream on ideas and > policies with other distros rather than just defending decisions made > upstream that affect fedora. Then (i.e. if there's disagreement between distributions on how to handle this) there needs to be a way for a distribution to configure this, and the configuration in Fedora should reflect Fedora's wishes, not those of other distributions. Kevin Kofler From kevin.kofler at chello.at Mon Sep 22 21:13:10 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 22 Sep 2008 21:13:10 +0000 (UTC) Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222062817.30758.17.camel@code.and.org> Message-ID: James Antill redhat.com> writes: > But that's not how groupinstall/groupremove works! Groups are _very_ > different from meta-packages, for instance: > > yum shell < install @x-software-development > remove libXaw-devel > run > EOL > > ...at the end of this the 'X Software Development' group is not > installed. ... and that's exactly why tristates are needed. > Why doesn't PK make it's "categories" the same as the yum backends > "groups"? +1, that's what most of us are asking. Kevin Kofler From pemboa at gmail.com Mon Sep 22 21:20:21 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 22 Sep 2008 16:20:21 -0500 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222116190.24063.24.camel@hughsie-work> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222073364.3330.11.camel@hughsie-work> <1222107745.4108.24.camel@luminos.localdomain> <1222116190.24063.24.camel@hughsie-work> Message-ID: <16de708d0809221420q7e6f11f6g84dfeeb06b4ac939@mail.gmail.com> On Mon, Sep 22, 2008 at 3:43 PM, Richard Hughes wrote: > On Mon, 2008-09-22 at 11:22 -0700, Jesse Keating wrote: >> So your solution is to invent something else entirely, rather than >> helping Fedora clean up its groupings definitions? Really? Nice. > > No. PK groups are made up _from_ the comps groups. There are just an > order of magnitude less options, and it's a flat list rather than a > tree. Comps supports optional, mandatory, suggested and the sort of > power user stuff that I just don't want to support in PackageKit. You should have said this earlier. This puts this discussion in the hands of UI and design specialists, as opposed to developers. Which may mean that Fedora is the wrong place to do most of this work. Because this suggests that this tool will be useless to me. I tried to use packagekit when I first installed it. I was taking some notes to file bugs, but these will likely not be of interest as they are aimed more at users like myself. There is no reason why an abstracted GUI should be less easy to use than yum. -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From pertusus at free.fr Mon Sep 22 21:30:50 2008 From: pertusus at free.fr (Patrice Dumas) Date: Mon, 22 Sep 2008 23:30:50 +0200 Subject: Orphaning my packages In-Reply-To: <200809161812.19271.alain.portal@free.fr> References: <200809161740.01071.alain.portal@free.fr> <20080916154600.GD32189@free.fr> <200809161812.19271.alain.portal@free.fr> Message-ID: <20080922213050.GA3484@free.fr> On Tue, Sep 16, 2008 at 06:12:18PM +0200, Alain PORTAL wrote: > Released. > There is an open bug since 14 months for this package: > https://bugzilla.redhat.com/show_bug.cgi?id=246922 I accept patch for this initscript review stuff, but I'll not do it myself (at least not soon), especially since the wiki is full of questions not answered. > There is a new version also: > http://fcron.free.fr/download.php Built in rawhide. Hope you get back to fedora one day, though ;-). -- Pat From james at fedoraproject.org Mon Sep 22 21:41:13 2008 From: james at fedoraproject.org (James Antill) Date: Mon, 22 Sep 2008 17:41:13 -0400 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222062817.30758.17.camel@code.and.org> Message-ID: <1222119673.30758.28.camel@code.and.org> On Mon, 2008-09-22 at 21:13 +0000, Kevin Kofler wrote: > James Antill redhat.com> writes: > > But that's not how groupinstall/groupremove works! Groups are _very_ > > different from meta-packages, for instance: > > > > yum shell < > install @x-software-development > > remove libXaw-devel > > run > > EOL > > > > ...at the end of this the 'X Software Development' group is not > > installed. > > .. and that's exactly why tristates are needed. You want installed: yes/no/maybe? IMNSHO it'd be _much_ better to just treat groups as collections of packages (in the UI) instead of trying to convince the user they are real objects they can manipulate in some way. -- James Antill Fedora From kevin.kofler at chello.at Mon Sep 22 21:44:16 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 22 Sep 2008 21:44:16 +0000 (UTC) Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222062817.30758.17.camel@code.and.org> <1222119673.30758.28.camel@code.and.org> Message-ID: James Antill fedoraproject.org> writes: > > On Mon, 2008-09-22 at 21:13 +0000, Kevin Kofler wrote: > > .. and that's exactly why tristates are needed. > > You want installed: yes/no/maybe? Yes/no/partially. A group for which some, but not all packages are installed is "partially installed" and would be represented by the tristate's "intermediate" state (the one with the gray checkmark). This is a very common idiom in software installers. Kevin Kofler From kulbirsaini at students.iiit.ac.in Mon Sep 22 21:59:39 2008 From: kulbirsaini at students.iiit.ac.in (Kulbir Saini) Date: Tue, 23 Sep 2008 03:29:39 +0530 Subject: Instant Mirror Status...? In-Reply-To: <48D7CE9D.20601@gmail.com> References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> Message-ID: <48D8154B.9080804@students.iiit.ac.in> Hi Mikesell, Les Mikesell wrote: > seth vidal wrote: >> On Mon, 2008-09-22 at 10:15 -0600, Nathanael D. Noblet wrote: >>> Hello, >>> I've become increasingly interested in a simple updates mirroring >>> system to proxy/store updates for a number of fedora machines on our >>> network. I searched google and found the instant mirror project, but >>> it seemed somewhat dead. Is it still alive? Did some other solution >>> replace it? >>> >> >> Take a look at intelligent mirror. A GSoC project by Kulbir Saini. >> >> https://fedorahosted.org/intelligentmirror/ > > Is there still no way to make yum default to behaving intelligently by > itself in the presence of a caching proxy? All it really needs to do is > use the same mirror as the last person chose so the URLs will match. I think its not possible. Especially in shared environments. For example in a university, machine A ran yum and downloaded foo.rpm via bar.com. Now if machine B runs yum to download the same foo.rpm, how will it know what mirror machine A used? If you have a look at the latest developments of intelligentmirror[1], you'll observe that this mirror switching problem has been resolved but at the proxy level. [1] http://fedora.co.in/intelligentmirror > -- > Les Mikesell > lesmikesell at gmail.com > -- --------------------------------------------------- Thank you, Kulbir Saini, Computer Science and Engineering, International Institute of Information Technology, Hyderbad, India - 500032. My Home-Page: http://saini.co.in/ My Web-Blog: http://fedora.co.in/ IRC nick : generalBordeaux Channels : #fedora, #fedora-devel, #yum on freenode From kulbirsaini at students.iiit.ac.in Mon Sep 22 22:04:45 2008 From: kulbirsaini at students.iiit.ac.in (Kulbir Saini) Date: Tue, 23 Sep 2008 03:34:45 +0530 Subject: Instant Mirror Status...? In-Reply-To: <48D7C4AD.7040308@gnat.ca> References: <48D7C4AD.7040308@gnat.ca> Message-ID: <48D8167D.9000309@students.iiit.ac.in> Hi! If you are using squid 2.7, latest version of intelligentmirror[1] will really be helpful. I am a sysadmin at my university (a single squid server with almost 2500 clients) and we have been using the above version since two weeks now. And out of 5-6GB requests for rpm/deb packages, we serve almost 4-4.5GB from cache itself :) In case you have squid version other than 2.7, try out this[2] version. [1] http://fedora.co.in/content/intelligentmirror-gets-even-more-intelligent [2] http://fedora.co.in/content/intelligentmirror-rpm-and-debian-package-caching-system-04-available-now Nathanael D. Noblet wrote: > Hello, > I've become increasingly interested in a simple updates mirroring system > to proxy/store updates for a number of fedora machines on our network. I > searched google and found the instant mirror project, but it seemed > somewhat dead. Is it still alive? Did some other solution replace it? > -- --------------------------------------------------- Thank you, Kulbir Saini, Computer Science and Engineering, International Institute of Information Technology, Hyderbad, India - 500032. My Home-Page: http://saini.co.in/ My Web-Blog: http://fedora.co.in/ IRC nick : generalBordeaux Channels : #fedora, #fedora-devel, #yum on freenode From emmanuel.seyman at club-internet.fr Mon Sep 22 22:15:40 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Tue, 23 Sep 2008 00:15:40 +0200 Subject: Instant Mirror Status...? In-Reply-To: References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> Message-ID: <20080922221540.GA15926@orient.maison.lan> * Gregory Maxwell [22/09/2008 20:04] : > > How would it know? And more importantly, if you want to always hit the same mirror, why don't you edit its configuration to reflect that ? Emmanuel From jkeating at redhat.com Mon Sep 22 22:21:34 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 22 Sep 2008 15:21:34 -0700 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222116190.24063.24.camel@hughsie-work> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222073364.3330.11.camel@hughsie-work> <1222107745.4108.24.camel@luminos.localdomain> <1222116190.24063.24.camel@hughsie-work> Message-ID: <1222122094.4108.42.camel@luminos.localdomain> On Mon, 2008-09-22 at 21:43 +0100, Richard Hughes wrote: > No. PK groups are made up _from_ the comps groups. There are just an > order of magnitude less options, and it's a flat list rather than a > tree. Comps supports optional, mandatory, suggested and the sort of > power user stuff that I just don't want to support in PackageKit. Well that's just too damn bad. You're making things /worse/ by having a different view of things post-install than you had during install. This was one of the /best/ things about pirut is that you got the same familiar UI, whether that UI was good or bad didn't matter, it was the /same/ and /consistent/. > > For me to "clean up the groups" would be to rip out all optional groups, > rip out most of the obscure categories and add lots of packages with > lots of extra deps. I'm sure that's not what you want me to do with > comps at all. Well it'd certainly be a starting point for a conversation, which is much better than decisions being made about our distribution and what our users see in our distribution discussed and made somewhere that was /not/ our distribution. Hurting, not helping. > If you want to actually help with this stuff, can I suggest you join the > PackageKit mailing list and discuss there? Fedora isn't the only > consumer of PackageKit, and I'm keen on working upstream on ideas and > policies with other distros rather than just defending decisions made > upstream that affect fedora. If I'd known that upstream was actively looking to destroy our package classifications, rather than actually work with us to clean them up a bit maybe I would have joined the conversation. A heads up might have been in order. I fear that any conversation now will just be too little too late. > And just correcting you: this wasn't _my_ decision, this was the result > of working with lots of other distros. Sarcasm doesn't help anybody. Neither does letting other distributions make decisions about ours. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From poelstra at redhat.com Mon Sep 22 22:34:48 2008 From: poelstra at redhat.com (John Poelstra) Date: Mon, 22 Sep 2008 15:34:48 -0700 Subject: Fedora Release Engineering Meeting Recap 2008-09-22 Message-ID: <48D81D88.1010708@redhat.com> Recap and full IRC transcript found here: https://fedoraproject.org/wiki/ReleaseEngineering/Meetings/2008-sep-22 Please make corrections and clarifications to the wiki page. = Fedora Release Engineering Meeting :: Monday 2008-09-22 = == F10 Beta Delayed == * Still fighting installer issues * Test results page is empty http://fedoraproject.org/wiki/QA/TestResults/Fedora10Install/Beta * Proposing new dates to FESCo ** Push all dates forward one week ** Beta release on 2008-09-30 ** GA date of 2008-11-25 == IRC Transcript == From mclasen at redhat.com Mon Sep 22 22:52:54 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Mon, 22 Sep 2008 18:52:54 -0400 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222122094.4108.42.camel@luminos.localdomain> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222073364.3330.11.camel@hughsie-work> <1222107745.4108.24.camel@luminos.localdomain> <1222116190.24063.24.camel@hughsie-work> <1222122094.4108.42.camel@luminos.localdomain> Message-ID: <1222123974.15195.5.camel@localhost.localdomain> On Mon, 2008-09-22 at 15:21 -0700, Jesse Keating wrote: > On Mon, 2008-09-22 at 21:43 +0100, Richard Hughes wrote: > > No. PK groups are made up _from_ the comps groups. There are just an > > order of magnitude less options, and it's a flat list rather than a > > tree. Comps supports optional, mandatory, suggested and the sort of > > power user stuff that I just don't want to support in PackageKit. > > Well that's just too damn bad. You're making things /worse/ by having a > different view of things post-install than you had during install. This > was one of the /best/ things about pirut is that you got the same > familiar UI, whether that UI was good or bad didn't matter, it was > the /same/ and /consistent/. > > > > > For me to "clean up the groups" would be to rip out all optional groups, > > rip out most of the obscure categories and add lots of packages with > > lots of extra deps. I'm sure that's not what you want me to do with > > comps at all. > > Well it'd certainly be a starting point for a conversation, which is > much better than decisions being made about our distribution and what > our users see in our distribution discussed and made somewhere that > was /not/ our distribution. Hurting, not helping. > > > If you want to actually help with this stuff, can I suggest you join the > > PackageKit mailing list and discuss there? Fedora isn't the only > > consumer of PackageKit, and I'm keen on working upstream on ideas and > > policies with other distros rather than just defending decisions made > > upstream that affect fedora. > > If I'd known that upstream was actively looking to destroy our package > classifications, rather than actually work with us to clean them up a > bit maybe I would have joined the conversation. A heads up might have > been in order. I fear that any conversation now will just be too little > too late. > > > And just correcting you: this wasn't _my_ decision, this was the result > > of working with lots of other distros. Sarcasm doesn't help anybody. > > Neither does letting other distributions make decisions about ours. Thanks Jesse, for making it clear that you are more interested in confrontation than a constructive discussion impossible. People who are interested in improving PackageKit should probably take the discussion to the packagekit list (packagekit at lists.freedesktop.org) From jkeating at redhat.com Mon Sep 22 22:57:25 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 22 Sep 2008 15:57:25 -0700 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222123974.15195.5.camel@localhost.localdomain> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222073364.3330.11.camel@hughsie-work> <1222107745.4108.24.camel@luminos.localdomain> <1222116190.24063.24.camel@hughsie-work> <1222122094.4108.42.camel@luminos.localdomain> <1222123974.15195.5.camel@localhost.localdomain> Message-ID: <1222124245.4108.44.camel@luminos.localdomain> On Mon, 2008-09-22 at 18:52 -0400, Matthias Clasen wrote: > Thanks Jesse, for making it clear that you are more interested in > confrontation than a constructive discussion impossible. I'm interested in fixing our comps files, since that's what is used by our installer, our compose tools, our package tools such as yum, our developers, our documentation, etc, etc... I won't argue that it could use improvement. I will however argue that the way to improve it is to have dialog with those using it and producing it, rather than deciding off project somewhere to just ignore it or apply filtering/modification to it without consulting the project at all. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From lesmikesell at gmail.com Mon Sep 22 23:05:35 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 22 Sep 2008 18:05:35 -0500 Subject: Instant Mirror Status...? In-Reply-To: <16de708d0809221203o4cd9e78xf91b3ebd77ee9f0@mail.gmail.com> References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> <16de708d0809221203o4cd9e78xf91b3ebd77ee9f0@mail.gmail.com> Message-ID: <48D824BF.5070501@gmail.com> Arthur Pemberton wrote: > On Mon, Sep 22, 2008 at 12:36 PM, Gregory Maxwell wrote: >> On Mon, Sep 22, 2008 at 12:58 PM, Les Mikesell wrote: >>> Is there still no way to make yum default to behaving intelligently by >>> itself in the presence of a caching proxy? All it really needs to do is use >>> the same mirror as the last person chose so the URLs will match. >> How would it know? > > > Well unless its a transparent proxy, yum.conf will have the proxy variable set. Or you might have http_proxy set in the environment. Normally a proxy will add headers to the response - the hard part is knowing which server from a mirrorlist has the URL's already cached. If there is no way to compute a first choice based on a hash of something like the proxy server name from the header when you request the mirrorlist, it might be worth having a central server somewhere that could coordinate things. A quick database hit seems like a reasonable tradeoff for a huge reduction in mirror server bandwidth. Or an external server that could see the IP address of the proxy could pick a first choice from the mirrorlist based on that without storing anything. -- Les Mikesell lesmikesell at gmail.com From mzerqung at 0pointer.de Mon Sep 22 23:13:28 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 01:13:28 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> Message-ID: <20080922231328.GD18272@tango.0pointer.de> On Wed, 10.09.08 20:56, Arthur Pemberton (pemboa at gmail.com) wrote: > I have a lot of seemingly pulse audio related issues on my F9 desktop. > Since I really like the idea behind Pulseaudio, I would like to see > these get sorted out, and would like to know how I can help in terms > of providing useful information. > > Here is my situation > > * Sounblaster Live 5.1 PCI -- has full 6 channel audio before, I had > for a short while after enabling it as per the pulseaudio wiki, but no > more Does pavucontrol show the device as having 6 channels? Please make sure that /etc/pulse/daemon.conf (or ~/.pulse/daemon.conf if you have that) is configured for 6 channel audio with "default-sample-channels=6". Also, an output of "pulseaudio -vvvv" (you might need to stop pa first by issuing pulseaudio -k first) would be very useful to track down what is going on. > * Tvtime -- no audio (doing `padsp sox -r 48000 -w -c 2 -t ossdsp > /dev/dsp -t ossdsp /dev/dsp` works, but causes noticeable lag) > * Amarok (xine) -- audio, susceptible to crashes, esp when I scroll to > fast in Firefox Xine should work fine. Make sure you are running the newest packages for F9, then provide crash bt. > * Kopete -- used to work, mysteriously stopped working > * Konversation -- never worked > * Mythfront -- no sound yet (haven't followed > http://svn.mythtv.org/trac/ticket/3598#comment:16 yet) I don't know these apps. Don't know much about KDE. Do these also use Xine? > * V4L tv capture card -- no sound now, used to rely on capturing AUX > on sound card before "no sound"? What does that mean? > * PulseAudio -- seems to average 30% CPU usage when playing music, > doesn't like me using Firefox too much (seems like a resource issue) Firefox doesn't use audio. Flash does. Flash is broken. libflashsupport can fix a few issues but doesn't solve them entirely. If PA eats too much CPU this might be caused be the resampler we use. Consider playinging around with "resample-method" in daemon.conf and setting it to "trivial". Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Mon Sep 22 23:16:02 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 01:16:02 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080912194302.GA4421@sonata.rednote.net> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> Message-ID: <20080922231601.GE18272@tango.0pointer.de> On Fri, 12.09.08 15:43, Janina Sajka (janina at rednote.net) wrote: > The problems we have right now are sufficiently sever to be > showstoppers. At the SpeakupModified.Org we recommend disabling > pulseaudio. As things stand in F-9, one gets no audio until after a user > logs in on the GUI. So, how are those who need screen reader support > supposed to use the a11y features of GDM? As it stands, there seems no > way to get console audio without that GUI login. Also a nonstarter in > the screen reader user community. In Rawhide PA is started on demand (in addition to being started from gnome-session) and thus should generally work fine on the console too. > It seems a useful initial step toward resolution is to run pulseaudio > as a system daemon, via an init script, /sbin/service, /sbin/chkconfig. > The trade-offs vs the per user model that F-9 employs are probably more > than acceptable to most a11y users. Nope. Please don't. This particular problem is solved in Rawhide. > So, let me simply ask ... Has anyone a working init script for > pulseaudio as a system daemon? Anything close that we could continue to > refine as an alternative configuration option for Fedora? Some distros ship an init script. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Mon Sep 22 23:18:38 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 01:18:38 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080912202813.GL6092@nb.net.home> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <20080912202813.GL6092@nb.net.home> Message-ID: <20080922231838.GF18272@tango.0pointer.de> On Fri, 12.09.08 22:28, Karel Zak (kzak at redhat.com) wrote: > > > The problems we have right now are sufficiently sever to be > > > showstoppers. At the SpeakupModified.Org we recommend disabling > > > pulseaudio. As things stand in F-9, one gets no audio until after a user > > > logs in on the GUI. So, how are those who need screen reader support > > > supposed to use the a11y features of GDM? As it stands, there seems no > > > way to get console audio without that GUI login. Also a nonstarter in > > > the screen reader user community. > > > > If you want to run terminal applications, can't you just log in to a > > full screen gnome-terminal? > > He wants to use audio before login to X Window. Somehow I don't understand > how do you want to fix this problem by gnome-terminal... By shortening the boot time, so that we start X early and have nothing "before" X. As soon as GDM is up PA is up too. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Mon Sep 22 23:26:33 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 01:26:33 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <7dd7ab490809121511x300c2a71q9d803ff57f1f22a4@mail.gmail.com> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080912194302.GA4421@sonata.rednote.net> <7dd7ab490809121511x300c2a71q9d803ff57f1f22a4@mail.gmail.com> Message-ID: <20080922232633.GG18272@tango.0pointer.de> On Fri, 12.09.08 15:11, Chris Weyl (cweyl at alumni.drew.edu) wrote: > >> So, let me simply ask ... Has anyone a working init script for > >> pulseaudio as a system daemon? Anything close that we could continue to > >> refine as an alternative configuration option for Fedora? > > > > We're going to be removing the legacy non-X system consoles by default > > in the long run. > > On a related note, here we get to my pet bug, too: 444172. I often > use my desktop with one X session to the machine itself, and another X > session remotely logged in to my work laptop via XDMCP. However, the > per-user model means that not only can I not use PA on the laptop to > play over the desktop's speakers, but I can't continue to play > anything through the first X session. > > https://bugzilla.redhat.com/show_bug.cgi?id=444172 > > (It's filed under ConsoleKit, as that seemed to be where the problem > was. I'm more than happy to reassign it if that makes sense :)) We make sure that a user that is not active on a screen gets no access to audio device so that he cannot wiretap what you say or hear. (this works only to a certain degree ince we still lack revoke() in the kernel) Now, if I correctly understood your problem, then your XDMCP session on the second vt will run as local gdm user or similar. We thus make sure that only the gdm user has access. I see the problem you are experiencing. On the other hand I would say PA/CK behave correctly here. I think the proper fix is to start PA locally on the XDMCP vt, so that your remote audio is actually forwarded to a PA server that is attached to your X11 server. Not sure about the security implications however... Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Mon Sep 22 23:39:24 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 01:39:24 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080915140703.GI20342@mokona.greysector.net> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> Message-ID: <20080922233924.GA20911@tango.0pointer.de> On Mon, 15.09.08 16:07, Dominik 'Rathann' Mierzejewski (dominik at greysector.net) wrote: > Do you mean Open Source Software or Open Sound System? In case of OSS, > it's realy a shame, because it was (and still is) a great piece of software > with nice API and doesn't require any external libraries like ALSA. > But you can't compare console/X to OSS/ALSA. The latter provide functionality I must correct you: the OSS API sucks. And ALSA is certainly a far greater piece of software than OSS ever was, and among the reasons is precisely the fact that it is a proper library instead of some fucked up kernel interface based on ioctls(). Everyone hates ioctl()s. The kernel people do. The userspace people too. An API for application usage that is based around ioctl()s is thus mandatorily a big failure. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From pemboa at gmail.com Mon Sep 22 23:48:23 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 22 Sep 2008 18:48:23 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080922231328.GD18272@tango.0pointer.de> References: <16de708d0809101856p697cddf4we84f1c47873ad983@mail.gmail.com> <20080922231328.GD18272@tango.0pointer.de> Message-ID: <16de708d0809221648h34e88c74w71ae6b1fe38b02d4@mail.gmail.com> On Mon, Sep 22, 2008 at 6:13 PM, Lennart Poettering wrote: > On Wed, 10.09.08 20:56, Arthur Pemberton (pemboa at gmail.com) wrote: > >> I have a lot of seemingly pulse audio related issues on my F9 desktop. >> Since I really like the idea behind Pulseaudio, I would like to see >> these get sorted out, and would like to know how I can help in terms >> of providing useful information. >> >> Here is my situation >> >> * Sounblaster Live 5.1 PCI -- has full 6 channel audio before, I had >> for a short while after enabling it as per the pulseaudio wiki, but no >> more > > Does pavucontrol show the device as having 6 channels? Please make > sure that /etc/pulse/daemon.conf (or ~/.pulse/daemon.conf if you have > that) is configured for 6 channel audio with > "default-sample-channels=6". > > Also, an output of "pulseaudio -vvvv" (you might need to stop pa first > by issuing pulseaudio -k first) would be very useful to track down > what is going on. > >> * Tvtime -- no audio (doing `padsp sox -r 48000 -w -c 2 -t ossdsp >> /dev/dsp -t ossdsp /dev/dsp` works, but causes noticeable lag) >> * Amarok (xine) -- audio, susceptible to crashes, esp when I scroll to >> fast in Firefox > > Xine should work fine. Make sure you are running the newest packages > for F9, then provide crash bt. > >> * Kopete -- used to work, mysteriously stopped working >> * Konversation -- never worked >> * Mythfront -- no sound yet (haven't followed >> http://svn.mythtv.org/trac/ticket/3598#comment:16 yet) > > I don't know these apps. Don't know much about KDE. Do these also use Xine? > >> * V4L tv capture card -- no sound now, used to rely on capturing AUX >> on sound card before > > "no sound"? What does that mean? > >> * PulseAudio -- seems to average 30% CPU usage when playing music, >> doesn't like me using Firefox too much (seems like a resource issue) > > Firefox doesn't use audio. Flash does. Flash is > broken. libflashsupport can fix a few issues but doesn't solve them > entirely. > > If PA eats too much CPU this might be caused be the resampler we > use. Consider playinging around with "resample-method" in daemon.conf > and setting it to "trivial". > > Lennart Hi Lennart, I appreciate your assistance, but I regret to say that I removed PulseAudio this past weekend. It relatively easy, and my system almost shamefully more functional now. I have since discovered at least one feature that I did not did not even know existed as PulseAudio wasn't functioning properly. This situation is made even more unfortunate as I have recently discovered that current version on Microsoft Windows has PulseAudio like features working just fine. If there is a specific test that I can run, I'll be happy to do so, but I cannot really run PulseAudio full time as is, I enjoy my music collection too much for this. Arthur Pemberton -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From pemboa at gmail.com Mon Sep 22 23:50:25 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 22 Sep 2008 18:50:25 -0500 Subject: Instant Mirror Status...? In-Reply-To: <48D8154B.9080804@students.iiit.ac.in> References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> <48D8154B.9080804@students.iiit.ac.in> Message-ID: <16de708d0809221650n27d4cd7djfa4b39e4ad12ff27@mail.gmail.com> On Mon, Sep 22, 2008 at 4:59 PM, Kulbir Saini wrote: > Hi Mikesell, > > Les Mikesell wrote: >> >> seth vidal wrote: >>> >>> On Mon, 2008-09-22 at 10:15 -0600, Nathanael D. Noblet wrote: >>>> >>>> Hello, >>>> I've become increasingly interested in a simple updates mirroring system >>>> to proxy/store updates for a number of fedora machines on our network. I >>>> searched google and found the instant mirror project, but it seemed somewhat >>>> dead. Is it still alive? Did some other solution replace it? >>>> >>> >>> Take a look at intelligent mirror. A GSoC project by Kulbir Saini. >>> >>> https://fedorahosted.org/intelligentmirror/ >> >> Is there still no way to make yum default to behaving intelligently by >> itself in the presence of a caching proxy? All it really needs to do is use >> the same mirror as the last person chose so the URLs will match. > > I think its not possible. Especially in shared environments. For example in > a university, machine A ran yum and downloaded foo.rpm via bar.com. Now if > machine B runs yum to download the same foo.rpm, how will it know what > mirror machine A used? You make it sound like yum is incapable of persisting data. Can't it just save the last used mirror? -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From pemboa at gmail.com Mon Sep 22 23:51:05 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 22 Sep 2008 18:51:05 -0500 Subject: Instant Mirror Status...? In-Reply-To: <20080922221540.GA15926@orient.maison.lan> References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> <20080922221540.GA15926@orient.maison.lan> Message-ID: <16de708d0809221651s13dae2c4w6f485eebd659782@mail.gmail.com> On Mon, Sep 22, 2008 at 5:15 PM, Emmanuel Seyman wrote: > * Gregory Maxwell [22/09/2008 20:04] : >> >> How would it know? > > And more importantly, if you want to always hit the same mirror, why don't > you edit its configuration to reflect that ? I am not sure that I would consider this "more importantly" but that is exactly the approach that I use. -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From mzerqung at 0pointer.de Mon Sep 22 23:57:31 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 01:57:31 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080916183444.GA4973@sonata.rednote.net> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> Message-ID: <20080922235731.GA21642@tango.0pointer.de> On Tue, 16.09.08 14:34, Janina Sajka (janina at rednote.net) wrote: > 3.) Logging in I hear first the GDM "audio logo," think I'll call it > an earcon from now on. But, Orca launches in my secondary audio device. > That's inappropriate, but I have no way to control that except to unplug > my secondary and tertiary audio devices and start over. In udev times ALSA devices don't have any particular order anymore. Which one you consider "primary", "secondary" or "tertiary" is known to you, but Linux doesn't know about that. Nowadays the indexes of ALSA sound cards depend on the initialization order of the drivers. Those drivers are now usually initialized in parallel which hence results in different orders at each boot. PA completely ignores alsa device indexes. Instead it uses HAL UDIs for identifiying devices, which is much more useful. When PA is first started up and no default audio device is configured, then PA will pick one. It is not defined which one it will pick, and as it appears it picked the wrong one for you. After login you can change the default device by right-clicking on it in paucontrol. However, that setting is per-user, so it won't have any effect on gdm. I thought of writing a small module for PA which in the case that no default device is configured will try some heuristic to find a suitable default (i.e. prefer PCI over USB over Bluetooth cards). Not sure this would fully fix your problem though. > 4.) Logging back in with only one audio device on board, Orca does > indeed startup on that device--but it seems I have to choose between > Orca and playing other audio. How quaint! I thought we got past this > silly "one sound at a time" view back around alsa-0.9. Does anyone > recall the alsa FAQ used to claim this was appropriate back then? I don't know how orca is configured. If it is a well behaving ALSA client it should connect to the device called "default" which will then result in a connection to PA. However, if it is a badly behaving ALSA client and hardcodes device strings such as "hw:0" then orca needs fixing. > Well, it still isn't appropriate, but that's what's happening. If I > paplay some .wav from a Gnome-Terminal, then attempt to go somewhere off > my Alt-F1 (Applications) menu--there's no Orca until my .wav ends. I > guess it would be like the screen blanking while the cd audio disc > plays? Very curious, indeed. This is intended behaviour. We will pause audio for inactive sessions, to make sure that other users cannot eavesdrop on you when they take over the active session. > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented > from doing so, paplay believes it should pause playing while I'm away > from the gui tty. Now, who's the genius that figured out this > "feature?" I did. And it actually is a feature. It fixes a long standing security issue. As long as you switch from/to sessions that are owned by the same user audio stays on. We only suspend audio if you switch to a session owned by a different user. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From jkeating at redhat.com Tue Sep 23 00:00:26 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 22 Sep 2008 17:00:26 -0700 Subject: Instant Mirror Status...? In-Reply-To: <16de708d0809221650n27d4cd7djfa4b39e4ad12ff27@mail.gmail.com> References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> <48D8154B.9080804@students.iiit.ac.in> <16de708d0809221650n27d4cd7djfa4b39e4ad12ff27@mail.gmail.com> Message-ID: <1222128026.4108.46.camel@luminos.localdomain> On Mon, 2008-09-22 at 18:50 -0500, Arthur Pemberton wrote: > > You make it sound like yum is incapable of persisting data. Can't it > just save the last used mirror? A single machine can continually hit the same mirror. However the original question (at least as I read it) is why can't yum on client A hit the same mirror that yum on client B just got done using, which would be pretty difficult for yum on client A to know about. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mzerqung at 0pointer.de Tue Sep 23 00:00:06 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 02:00:06 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <1221592366.32342.23.camel@localhost.localdomain> References: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> Message-ID: <20080923000006.GB21642@tango.0pointer.de> On Tue, 16.09.08 15:12, Matthias Clasen (mclasen at redhat.com) wrote: > > 3.) Logging in I hear first the GDM "audio logo," think I'll call it > > an earcon from now on. But, Orca launches in my secondary audio device. > > That's inappropriate, but I have no way to control that except to unplug > > my secondary and tertiary audio devices and start over. > > Hardly pulseaudios fault if orca picks the wrong device. I have no idea > how orca decides which device to use. Actually, nowadays I prefer seeing PA as black box, where only PA decides what device clients should be connecting to, not the clients themselves. Policy decisions should be up to the sound server, not the client. That said, in some situations (like probably this one) it does make sense to have device selection in the clients themsevles. Unfortunately ALSA device enumeratin is rather flaky and we don't support it in the PA backend for libasound. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Tue Sep 23 00:03:17 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 02:03:17 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080916220527.GC5290@sonata.rednote.net> References: <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> Message-ID: <20080923000317.GC21642@tango.0pointer.de> On Tue, 16.09.08 18:05, Janina Sajka (janina at rednote.net) wrote: > > Chuck Anderson writes: > > On Tue, Sep 16, 2008 at 02:34:44PM -0400, Janina Sajka wrote: > > > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented > > > from doing so, paplay believes it should pause playing while I'm away > > > from the gui tty. Now, who's the genius that figured out this "feature?" > > > > That's ConsoleKit deactivating the streams on the non-active console. > > This is so mult-user-switching can work and each user can have their > > own audio. > > > OK. Thanks for the explanation. > > So, the concept limits audio to a single console, even if the same user > is logged in somewhere else? I guess running pa as a systen daemon would > not exhibit this behavior? Every session owned by the same user will share a single PA instance. As long as you switch bac and force from/to sessions owned by the same user audio will not be suspended. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Tue Sep 23 00:05:20 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 02:05:20 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <1221612043.18922.5.camel@localhost.localdomain> References: <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> Message-ID: <20080923000519.GD21642@tango.0pointer.de> On Tue, 16.09.08 20:40, Matthias Clasen (mclasen at redhat.com) wrote: > > On Tue, 2008-09-16 at 18:05 -0400, Janina Sajka wrote: > > Chuck Anderson writes: > > > On Tue, Sep 16, 2008 at 02:34:44PM -0400, Janina Sajka wrote: > > > > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented > > > > from doing so, paplay believes it should pause playing while I'm away > > > > from the gui tty. Now, who's the genius that figured out this "feature?" > > > > > > That's ConsoleKit deactivating the streams on the non-active console. > > > This is so mult-user-switching can work and each user can have their > > > own audio. > > > > > OK. Thanks for the explanation. > > > > So, the concept limits audio to a single console, even if the same user > > is logged in somewhere else? I guess running pa as a systen daemon would > > not exhibit this behavior? > > > > Actually, Lennart changed PA to not be strictly per-session, but > per-user, I think. But I don't know the details of how that works. This is corrrect. We spawn at most one PA instance per-machine/per-homedir. All sessions that come and go share it. When the last session of a user terminates and some timeout elapsed PA will terminate itself again. > I've looked into your 'login screen ready' sound problem, and found that > it doesn't work atm due to a pulseaudio bug: > https://bugzilla.redhat.com/show_bug.cgi?id=462537 I belive this is more of a gdm bug, though. ;-) Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Tue Sep 23 00:18:15 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 02:18:15 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080922180001.GA8379@sonata.rednote.net> References: <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <20080922180001.GA8379@sonata.rednote.net> Message-ID: <20080923001815.GE21642@tango.0pointer.de> On Mon, 22.09.08 14:00, Janina Sajka (janina at rednote.net) wrote: > > I've been meaning to comment on your multi-seat setup ... > > Nils Philippsen writes: > > On Tue, 2008-09-16 at 17:28 -0400, Janina Sajka wrote: > > > Matthias Clasen writes: > > > > On Tue, 2008-09-16 at 14:34 -0400, Janina Sajka wrote: > > [...] > > > > > > > > > 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented > > > > > from doing so, paplay believes it should pause playing while I'm away > > > > > from the gui tty. Now, who's the genius that figured out this "feature?" > > > > > > > > Insults won't help your cause. > > > Well, my apologies if this offends you. Is it supposed to work that way, > > > though? Is there actually a use case for that behavior? Or is this just > > > some incidental artifact? > > > > There is a use case for this, namely if you have several "seats" with > > different logged in users: in this case one probably only wants the > > sounds of the "active session" being played and others muted. Just in > > case you ask, we're using that setup at home, my wife and I are logged > > in all the time an switch between users via the applet or > > F7/F9. > > > I don't believe it necessarily follows that technology should enforce > who does, and who does not have audio in this circumstance. > > Consider an office environment--perhaps it's similar to what you and > your wife have. There are several desks with chairs. Perhaps these are > in an open room. Perhaps there are dividers between the desks to provide > a small measure of privacy. > > Each desk in this scenario is undoubtedly equipped with a telephone. No > one would think that the occupant of Desk B should be denied telephone > calls just because the occupant of Desk A is on the phone. Technology is > not required to enforce appropriate social behavior in this > circumstance. The humans who work in this environment have learned > appropriate behaviors in the past century. > > Why is the computer desktop so different? What compells us to require > that technology enforce no audio for B while A is provided audio? > Perhaps the users want to listen to voice mail attachments received via > email. Even four or five feet separation is sufficient to do so. We > don't need technology to do for us such things as we humans clearly know > how to negotiate for ourselves. > > Indeed, it seems to me precluding multiseat audio is one way of saying > that Fedora does not support telephone answering environments--airline > reservations, bank customer support, etc., etc. > > What am I missing here? I am pretty sure the airlines and the banks are quite happy that we are closing the security vulnerarbility that without this feature allows people to eavesdrop on your audio, without you knowing. To suspend audio for inactive sessions and only allow audio for active sessions fixes a big security hole. And it's not just we who fixed this hole like this. Apple for example does it too. And usually Apple is the gold standard of user-friendliness, right? Allowing multiple different users audio device access at the same is a security nightmare. It has been with ALSA dmix. And it is even more so in PA. Far down on my todo list is adding some kind of handover logic between multiple PA instances, so that we can add fading of audio when we switch sessions. This would also allow us to continue playback from inactive sessions if the now active user is OK with that. But this is complex, security-sensitive and not a priority. So don't expect any quick results. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From pemboa at gmail.com Tue Sep 23 00:20:38 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 22 Sep 2008 19:20:38 -0500 Subject: Instant Mirror Status...? In-Reply-To: <1222128026.4108.46.camel@luminos.localdomain> References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> <48D8154B.9080804@students.iiit.ac.in> <16de708d0809221650n27d4cd7djfa4b39e4ad12ff27@mail.gmail.com> <1222128026.4108.46.camel@luminos.localdomain> Message-ID: <16de708d0809221720r3dad221vac4cb255ccc50490@mail.gmail.com> 2008/9/22 Jesse Keating : > On Mon, 2008-09-22 at 18:50 -0500, Arthur Pemberton wrote: >> >> You make it sound like yum is incapable of persisting data. Can't it >> just save the last used mirror? > > > A single machine can continually hit the same mirror. However the > original question (at least as I read it) is why can't yum on client A > hit the same mirror that yum on client B just got done using, which > would be pretty difficult for yum on client A to know about. Thanks for that clarification, I totally missed this interpretation. I currently manually set the proxy for this on each machine. Would be nice is there was a zero-conf way of doing this, especially on a large scale. -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From cra at WPI.EDU Tue Sep 23 00:21:47 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Mon, 22 Sep 2008 20:21:47 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080922235731.GA21642@tango.0pointer.de> References: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080922235731.GA21642@tango.0pointer.de> Message-ID: <20080923002147.GA6761@angus.ind.WPI.EDU> On Tue, Sep 23, 2008 at 01:57:31AM +0200, Lennart Poettering wrote: > PA completely ignores alsa device indexes. Instead it uses HAL UDIs > for identifiying devices, which is much more useful. When PA is first > started up and no default audio device is configured, then PA will > pick one. It is not defined which one it will pick, and as it appears > it picked the wrong one for you. > > After login you can change the default device by right-clicking on it > in paucontrol. However, that setting is per-user, so it won't have any > effect on gdm. > > I thought of writing a small module for PA which in the case that no > default device is configured will try some heuristic to find a > suitable default (i.e. prefer PCI over USB over Bluetooth cards). Not > sure this would fully fix your problem though. This may be a crazy idea--but why don't we just make the default output device "all devices"--copy the audio streams to every device until the user selects a specific device as the default. This would neatly solve the issue in this thread as well as other peoples' confusion of "why do I have no sound" when the sound is being directed to a card without any speakers attached. There should be a way to override this system-wide default as well. Alternatively, perhaps hal-based quirks can specify the system-specific default sound output device. e.g. for laptops or desktop models the built-in soundcard would be a sane default. If there is no hal quirk for the current system, you could fall back to "all output devices" or the heuristics you describe above. Basically: 1. system factory default: output to all sound cards simultaneously 2. system custom default: either hal-quirk based, heuristic-based, or set by sysadmin. 3. per user setting: as we have now, per user default output device setting. From mzerqung at 0pointer.de Tue Sep 23 00:25:43 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 02:25:43 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: References: <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> Message-ID: <20080923002543.GF21642@tango.0pointer.de> On Tue, 16.09.08 23:57, Colin Walters (walters at verbum.org) wrote: > >> > That's ConsoleKit deactivating the streams on the non-active console. > >> > This is so mult-user-switching can work and each user can have their > >> > own audio. > >> > > >> OK. Thanks for the explanation. > >> > >> So, the concept limits audio to a single console, even if the same user > >> is logged in somewhere else? I guess running pa as a systen daemon would > >> not exhibit this behavior? > >> > > > > Actually, Lennart changed PA to not be strictly per-session, but > > per-user, I think. But I don't know the details of how that works. > > Which is broken because in reality per-session and per-user are the > same thing. You can't log in multiple times: > http://cgwalters.livejournal.com/16885.html As far as I know we again allow multiple simultaneous X logins by the same user. Also, PA supports console logins now, where multiple logins are the common case. I'd love to have a per-homedir/per-machine bus in D-Bus. This would allow me to start PA up via normal activation. Unfortunately we don't have such a bus and adding it to D-Bus is admittedly questionnable since only in the fewest cases using such a bus is valid. Those cases are the ones where machine-specific resources are managed by a user dbus service. Besides PA only the new V4L daemon (possibly) comes to my mind that fall into this category. Adding such a bus for just two users probably doesn't make too much sense. Especially since according to Scott Upstart will eventually support starting per-user "singleton" daemons easily. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Tue Sep 23 00:32:24 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 02:32:24 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080923002147.GA6761@angus.ind.WPI.EDU> References: <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080922235731.GA21642@tango.0pointer.de> <20080923002147.GA6761@angus.ind.WPI.EDU> Message-ID: <20080923003224.GA24837@tango.0pointer.de> On Mon, 22.09.08 20:21, Chuck Anderson (cra at WPI.EDU) wrote: > > On Tue, Sep 23, 2008 at 01:57:31AM +0200, Lennart Poettering wrote: > > PA completely ignores alsa device indexes. Instead it uses HAL UDIs > > for identifiying devices, which is much more useful. When PA is first > > started up and no default audio device is configured, then PA will > > pick one. It is not defined which one it will pick, and as it appears > > it picked the wrong one for you. > > > > After login you can change the default device by right-clicking on it > > in paucontrol. However, that setting is per-user, so it won't have any > > effect on gdm. > > > > I thought of writing a small module for PA which in the case that no > > default device is configured will try some heuristic to find a > > suitable default (i.e. prefer PCI over USB over Bluetooth cards). Not > > sure this would fully fix your problem though. > > This may be a crazy idea--but why don't we just make the default > output device "all devices"--copy the audio streams to every device > until the user selects a specific device as the default. This would > neatly solve the issue in this thread as well as other peoples' > confusion of "why do I have no sound" when the sound is being directed > to a card without any speakers attached. Unfortunately doing this will substantially increase CPU load (because we need to resample the streams for each of the devcies with a slightly different sample rate and people are already complaining if we do this for just a single stream...) and also practically disable glitch-free audio. I.e. all the power savings are gone. Not a good choice for a default. There has been some work on adding SSE support to the resampler. That's a step in the right direction. Maybe we can do what you suggest some time in he future, but right now people would probably just cry and call PA a teribble CPU hogger once more ;-) Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From jkeating at redhat.com Tue Sep 23 00:35:56 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 22 Sep 2008 17:35:56 -0700 Subject: Fedora i686 Live image (Desktop) 43megs oversize... Message-ID: <1222130156.4108.52.camel@luminos.localdomain> Need to cut something out here. Looking deeper into it. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From michael at laptop.org Tue Sep 23 01:08:17 2008 From: michael at laptop.org (Michael Stone) Date: Mon, 22 Sep 2008 21:08:17 -0400 Subject: recover from broken yum transaction In-Reply-To: <1222081584.4152.60.camel@beck.corsepiu.local> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <200809220032.39342.konrad@tylerc.org> <46a038f90809220207r65a9d021k7b19a73df2a8c1c3@mail.gmail.com> <200809220246.53879.konrad@tylerc.org> <46a038f90809220347p30dbd60budd15230479f8155c@mail.gmail.com> <1222081584.4152.60.camel@beck.corsepiu.local> Message-ID: <20080923010815.GB18785@didacte.laptop.org> On Mon, Sep 22, 2008 at 01:06:24PM +0200, Ralf Corsepius wrote: >Openly said, based on my experience with my i586, I don't buy this. >Usually, the memory requirements introduced other applications are >magnitudes above that of yum. My impression is that our lack of swap really hurts us here; on most systems, it's possible to swap some pages (dirty or clean) at relatively fixed cost and keep going. We _suspect_ (but have not yet proven) that on XOs, under memory pressure, we start thrashing code pages (which can be unmapped since they are clean but which must be de-compressed in order to be remapped) and eventually OOM when we finally receive an allocation that cannot possibly be satisfied. >However I am not sufficiently familiar with OPLC to be able to further >comment on this. If you would like to become sufficiently familiar with XOs to comment further, it can be easily arranged, either through our Developer's Program [1] or through a renewed G1G1 effort scheduled for November [2]. Please consider it -- we could use your help and it's a great way to help OLPC get better at doing things the Fedora way. Michael [1]: http://wiki.laptop.org/go/Contributors_program [2]: sneak preview; more information to follow in coming weeks From kevin.kofler at chello.at Tue Sep 23 01:44:33 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 23 Sep 2008 01:44:33 +0000 (UTC) Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222073364.3330.11.camel@hughsie-work> <1222107745.4108.24.camel@luminos.localdomain> <1222116190.24063.24.camel@hughsie-work> <1222122094.4108.42.camel@luminos.localdomain> <1222123974.15195.5.camel@localhost.localdomain> <1222124245.4108.44.camel@luminos.localdomain> Message-ID: Jesse Keating redhat.com> writes: > I won't argue that it could use improvement. I will however argue that > the way to improve it is to have dialog with those using it and > producing it, rather than deciding off project somewhere to just ignore > it or apply filtering/modification to it without consulting the project > at all. Indeed. PackageKit should be fixed to use comps groups unmunged. Unfortunately, PackageKit's design is fundamentally broken and thus fixing this needs API changes. See this enum: typedef enum { PK_GROUP_ENUM_ACCESSIBILITY, PK_GROUP_ENUM_ACCESSORIES, PK_GROUP_ENUM_ADMIN_TOOLS, PK_GROUP_ENUM_COMMUNICATION, PK_GROUP_ENUM_DESKTOP_GNOME, PK_GROUP_ENUM_DESKTOP_KDE, PK_GROUP_ENUM_DESKTOP_OTHER, PK_GROUP_ENUM_DESKTOP_XFCE, PK_GROUP_ENUM_EDUCATION, PK_GROUP_ENUM_FONTS, PK_GROUP_ENUM_GAMES, PK_GROUP_ENUM_GRAPHICS, PK_GROUP_ENUM_INTERNET, PK_GROUP_ENUM_LEGACY, PK_GROUP_ENUM_LOCALIZATION, PK_GROUP_ENUM_MAPS, PK_GROUP_ENUM_MULTIMEDIA, PK_GROUP_ENUM_NETWORK, PK_GROUP_ENUM_OFFICE, PK_GROUP_ENUM_OTHER, PK_GROUP_ENUM_POWER_MANAGEMENT, PK_GROUP_ENUM_PROGRAMMING, PK_GROUP_ENUM_PUBLISHING, PK_GROUP_ENUM_REPOS, PK_GROUP_ENUM_SECURITY, PK_GROUP_ENUM_SERVERS, PK_GROUP_ENUM_SYSTEM, PK_GROUP_ENUM_VIRTUALIZATION, PK_GROUP_ENUM_SCIENCE, PK_GROUP_ENUM_DOCUMENTATION, PK_GROUP_ENUM_ELECTRONICS, PK_GROUP_ENUM_COLLECTIONS, PK_GROUP_ENUM_UNKNOWN } PkGroupEnum; This enum is all the way down in libpackagekit and the backends have no control over its contents. This is exactly how things should NOT be done! The list of groups should be determined by the backend (entirely, not as a bitfield of the "which of the groups in the enum do we support" type). It should be the backend's task to return a string and an optional icon (with a sane default, like that "metapackage" icon) for each of the groups which are actually present, they should not have to force their groups into a set of hardcoded integers (and throw away everything the enum doesn't cover). The current system is overly simplistic, inflexible and just plain dumb. Kevin Kofler From jonstanley at gmail.com Tue Sep 23 02:42:06 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Mon, 22 Sep 2008 22:42:06 -0400 Subject: Instant Mirror Status...? In-Reply-To: <16de708d0809221720r3dad221vac4cb255ccc50490@mail.gmail.com> References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> <48D8154B.9080804@students.iiit.ac.in> <16de708d0809221650n27d4cd7djfa4b39e4ad12ff27@mail.gmail.com> <1222128026.4108.46.camel@luminos.localdomain> <16de708d0809221720r3dad221vac4cb255ccc50490@mail.gmail.com> Message-ID: On Mon, Sep 22, 2008 at 8:20 PM, Arthur Pemberton wrote: > I currently manually set the proxy for this on each machine. Would be > nice is there was a zero-conf way of doing this, especially on a large > scale. There is - if you set up a private mirror in MirrorManager, then all requests from your netblock will be directed to said mirror. Or am I missing something? From pemboa at gmail.com Tue Sep 23 02:54:37 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 22 Sep 2008 21:54:37 -0500 Subject: Instant Mirror Status...? In-Reply-To: References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> <48D8154B.9080804@students.iiit.ac.in> <16de708d0809221650n27d4cd7djfa4b39e4ad12ff27@mail.gmail.com> <1222128026.4108.46.camel@luminos.localdomain> <16de708d0809221720r3dad221vac4cb255ccc50490@mail.gmail.com> Message-ID: <16de708d0809221954p7be9160auad70df68bdb676d3@mail.gmail.com> On Mon, Sep 22, 2008 at 9:42 PM, Jon Stanley wrote: > On Mon, Sep 22, 2008 at 8:20 PM, Arthur Pemberton wrote: > >> I currently manually set the proxy for this on each machine. Would be >> nice is there was a zero-conf way of doing this, especially on a large >> scale. > > There is - if you set up a private mirror in MirrorManager, then all > requests from your netblock will be directed to said mirror. Or am I > missing something? What you are missing, due to my own ambiguity, is that I am currently using Squid. Not nearly as elegant as it can be, but was very quick to setup with my Centos server hosting the proxy. -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From lesmikesell at gmail.com Tue Sep 23 03:07:29 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 22 Sep 2008 22:07:29 -0500 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080923001815.GE21642@tango.0pointer.de> References: <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <20080922180001.GA8379@sonata.rednote.net> <20080923001815.GE21642@tango.0pointer.de> Message-ID: <48D85D71.4020503@gmail.com> Lennart Poettering wrote: > > To suspend audio for inactive sessions and only allow audio for active > sessions fixes a big security hole. But it sucks if you are playing music for the room and someone else wants to check their email. > And it's not just we who fixed > this hole like this. Apple for example does it too. And usually Apple > is the gold standard of user-friendliness, right? No, it sucks just as much when itunes does it. You expect that kind of stuff from Apple who only has a short history of multi-user machines and who would really rather sell you an apple tv or ipod with dock that you can dedicate to driving your speakers, though. Linux has always been multi-user and doesn't have any such excuses for arbitrarily disconnecting devices. > Allowing multiple different users audio device access at the same is a > security nightmare. It has been with ALSA dmix. And it is even more so > in PA. Doesn't the kernel have a mechanism for exclusive locks on devices if someone wants to have exclusive access? It's not all that difficult to eavesdrop on music playing loudly anyway... > Far down on my todo list is adding some kind of handover logic between > multiple PA instances, so that we can add fading of audio when we > switch sessions. This would also allow us to continue playback from > inactive sessions if the now active user is OK with that. But this is > complex, security-sensitive and not a priority. So don't expect any > quick results. What's the right way to set up a media player service that isn't attached to anyone's session? -- Les Mikesell lesmikesell at gmail.com From jonstanley at gmail.com Tue Sep 23 03:33:39 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Mon, 22 Sep 2008 23:33:39 -0400 Subject: F11 Spins process refinement Message-ID: As a member of FESCo, I'm leading an effort to improve the spins process for F11. At the time that the F10 beta came around, no one seemed to know what spins we were to produce to be hosted on spins.fp.o, what process they had been through (Spins SIG, Board trademark, rel-eng). We also inadvertently wound up requesting that rel-eng produce spin using a toolchain that they had never heard of before. As a result of this, the need for improvement became immediately obvious to me. If you're interested in this topic, we will be having a meeting, hopefully sometime this week, via conference call. The reason for holding this meeting via conference call rather than IRC is the massively increased bandwidth that's available on a conference call to actually discuss items - while IRC is wonderful for taking votes on things that have already been thought out, it can't be used for a sort of "working session". What I need is *a volunteer* from each of the below groups to attend this call. The reason for a single (or at most two) people from each group is to facilitate an efficient, manageable call that stands a fighting chance of accomplishing something :) Spins SIG Release Engineering Board FESCo I'll also be reaching out to Bryan Kearney, who has some experience going through this process, and some suggestions for refinement. Note that we will be using a public whiteboard (most likely the Fedora sobby instance), and the minutes of the call will be made public. Thanks! -Jon From lesmikesell at gmail.com Tue Sep 23 03:51:52 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 22 Sep 2008 22:51:52 -0500 Subject: Instant Mirror Status...? In-Reply-To: References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> <48D8154B.9080804@students.iiit.ac.in> <16de708d0809221650n27d4cd7djfa4b39e4ad12ff27@mail.gmail.com> <1222128026.4108.46.camel@luminos.localdomain> <16de708d0809221720r3dad221vac4cb255ccc50490@mail.gmail.com> Message-ID: <48D867D8.40304@gmail.com> Jon Stanley wrote: > On Mon, Sep 22, 2008 at 8:20 PM, Arthur Pemberton wrote: > >> I currently manually set the proxy for this on each machine. Would be >> nice is there was a zero-conf way of doing this, especially on a large >> scale. > > There is - if you set up a private mirror in MirrorManager, then all > requests from your netblock will be directed to said mirror. Or am I > missing something? What you are missing is that the people sharing a proxy shouldn't have to know about each other or set anything up. All they should have to do is request the same URLs. Why can't that happen automatically? That is, within whatever blocks geoip might consider 'near', arbitrarily select the first-choice mirror based on the source IP range in a repeatable way. That way everyone behind the same proxy requests the same URL and the caching works automatically. -- Les Mikesell lesmikesell at gmail.com From poelstra at redhat.com Tue Sep 23 04:07:46 2008 From: poelstra at redhat.com (John Poelstra) Date: Mon, 22 Sep 2008 21:07:46 -0700 Subject: F11 Spins process refinement In-Reply-To: References: Message-ID: <48D86B92.80303@redhat.com> Jon Stanley said the following on 09/22/2008 08:33 PM Pacific Time: > What I need is *a volunteer* from each of the below groups to attend > this call. The reason for a single (or at most two) people from each > group is to facilitate an efficient, manageable call that stands a > fighting chance of accomplishing something :) > > Spins SIG > Release Engineering > Board > FESCo > > I'll also be reaching out to Bryan Kearney, who has some experience > going through this process, and some suggestions for refinement. > It's not listed above, but I would be happy to contribute as note taker and diagram drawer if that is helpful. John From gmaxwell at gmail.com Tue Sep 23 04:35:30 2008 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Tue, 23 Sep 2008 00:35:30 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080922235731.GA21642@tango.0pointer.de> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080922235731.GA21642@tango.0pointer.de> Message-ID: On Mon, Sep 22, 2008 at 7:57 PM, Lennart Poettering wrote: [snip] >> 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented >> from doing so, paplay believes it should pause playing while I'm away >> from the gui tty. Now, who's the genius that figured out this >> "feature?" > > I did. And it actually is a feature. It fixes a long standing security > issue. [snip] I'm missing how write access (as opposed to read/recording) to an audio device creates a material security vulnerability. It seems that the majority of the complaints are that playback stops and that it surprises the user. Recording stopping may also be surprising, but it's easy to explain the security argument there. If the answer is "differentiating read and write access is hard/not possible with the current API" then thats what it is, but simply blaming security is going to baffle people. From james at fedoraproject.org Tue Sep 23 05:12:30 2008 From: james at fedoraproject.org (James Antill) Date: Tue, 23 Sep 2008 01:12:30 -0400 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222117541.5988.1.camel@localhost.localdomain> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> <1222117541.5988.1.camel@localhost.localdomain> Message-ID: <1222146750.30758.38.camel@code.and.org> On Mon, 2008-09-22 at 17:05 -0400, Matthias Clasen wrote: > On Mon, 2008-09-22 at 20:55 +0000, Kevin Kofler wrote: > > > > > Those "arbitrary" classifications are what Fedora maintainers work hard to keep > > up to date and complete, unlike your incomplete hardcoded classifications in > > PackageKit which are truly arbitrary and do not reflect how Fedora intends to > > categorize its packages. > > What makes you think that the comps classifications are less arbitrary ? Because anyone who sets up a repository can create a classification, instead of making it a "oh, you've created a new package ... now you just need to recompile PK". > And isn't one of the original motivations for this thread that many > packagers are exactly _not_ doing that hard work ?! Right, so the obvious solution is to make it even harder for anyone to do anything. -- James Antill Fedora From james.antill at redhat.com Tue Sep 23 06:16:46 2008 From: james.antill at redhat.com (James Antill) Date: Tue, 23 Sep 2008 02:16:46 -0400 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222115665.24063.14.camel@hughsie-work> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> Message-ID: <1222150606.30758.65.camel@code.and.org> On Mon, 2008-09-22 at 21:34 +0100, Richard Hughes wrote: > No, we keep the groupings as the yum backend supports them as part of > "collections". I'm just not showing the giant tree of arbitrary > classifications as the main point of user interaction. gpk-application 0.2.5/0.3.2 list 20 hardcoded "groups", including such joys as "Legacy". yum grouplist has 45 with just Fedora-9, and 46 if you include the updates repo. (we added "SUGAR Desktop Environment" -- listed in the "Other" group in PK, not even the "Other desktops"). Most of the difference seems to be: 1. PK doesn't have any of the '*Development*' groups (9), 2. PK has a single Servers group instead of each of the specific servers groups (9). ...also PK doesn't have any of the specific groups like "Authoring and Publishing", "Engineering and Scientific" or amusingly "Fedora Packager". It also screws up the "*Legacy*" groups putting the legacy fonts in the Fonts group, for example. In short it's arbitrarily different, hardcoded and just plain wrong. But hey, you've done "substantial user research" while we're just lowly developers, so feel free to keep ignoring us. > None of the people in > http://www.packagekit.org/pk-profiles.html could tell me what they > expected to find in base-system/system-tools or > base-system/admin-tools, > or tell me the difference between them. _Well done_ for bringing up rpm specfile groups which are obsolete, as I'm sure you know, and have been since before PK existed. -- James Antill Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Tue Sep 23 06:31:28 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 23 Sep 2008 08:31:28 +0200 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222089336.3818.0.camel@localhost.localdomain> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222089336.3818.0.camel@localhost.localdomain> Message-ID: <1222151488.4159.0.camel@arekh.okg> Le lundi 22 septembre 2008 ? 09:15 -0400, Matthias Clasen a ?crit : > On Mon, 2008-09-22 at 08:47 +0200, Nicolas Mailhot wrote: > > Le lundi 22 septembre 2008 ? 07:01 +0200, Thorsten Leemhuis a ?crit : > > > On 21.09.2008 23:33, Kevin Kofler wrote: > > > > Tim Lauridsen googlemail.com> writes: > > > > [...] > > > > IMHO, a much better approach would be to: > > > > * throw out the hardcoded categories! We have that information in compsxml, > > > > PackageKit should not try to duplicate it. > > > > The PK argument used to be comps groups suck, are distro-specific, have > > no equivalent on some distros, so people should drop comps and > > contribute to pk hardcoded stuff instead. > > Where did you get that idea ? Already had many exchanges with Richard on the subject :) -- 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 pemboa at gmail.com Tue Sep 23 06:40:18 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Tue, 23 Sep 2008 01:40:18 -0500 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222151488.4159.0.camel@arekh.okg> References: <48D542A9.1070600@leemhuis.info> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222089336.3818.0.camel@localhost.localdomain> <1222151488.4159.0.camel@arekh.okg> Message-ID: <16de708d0809222340m2db34049o303fb5124b43823e@mail.gmail.com> 2008/9/23 Nicolas Mailhot : > Le lundi 22 septembre 2008 ? 09:15 -0400, Matthias Clasen a ?crit : >> On Mon, 2008-09-22 at 08:47 +0200, Nicolas Mailhot wrote: >> > Le lundi 22 septembre 2008 ? 07:01 +0200, Thorsten Leemhuis a ?crit : >> > > On 21.09.2008 23:33, Kevin Kofler wrote: >> > > > Tim Lauridsen googlemail.com> writes: >> > > > [...] >> > > > IMHO, a much better approach would be to: >> > > > * throw out the hardcoded categories! We have that information in compsxml, >> > > > PackageKit should not try to duplicate it. >> > >> > The PK argument used to be comps groups suck, are distro-specific, have >> > no equivalent on some distros, so people should drop comps and >> > contribute to pk hardcoded stuff instead. >> >> Where did you get that idea ? > > Already had many exchanges with Richard on the subject :) If this is the idea, then this needs to be done at the LSB level, and let it filter down to the distros. Frankly, I thought the idea was to fit into each distro, not override each distro -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From nicolas.mailhot at laposte.net Tue Sep 23 06:43:13 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 23 Sep 2008 08:43:13 +0200 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222117541.5988.1.camel@localhost.localdomain> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> <1222117541.5988.1.camel@localhost.localdomain> Message-ID: <1222152193.4159.1.camel@arekh.okg> Le lundi 22 septembre 2008 ? 17:05 -0400, Matthias Clasen a ?crit : > On Mon, 2008-09-22 at 20:55 +0000, Kevin Kofler wrote: > > > > > Those "arbitrary" classifications are what Fedora maintainers work hard to keep > > up to date and complete, unlike your incomplete hardcoded classifications in > > PackageKit which are truly arbitrary and do not reflect how Fedora intends to > > categorize its packages. > > What makes you think that the comps classifications are less arbitrary ? > And isn't one of the original motivations for this thread that many > packagers are exactly _not_ doing that hard work ?! Some of them are. Even if hiding them in our main gui update tool isn't exactly motivating. -- 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 Tue Sep 23 07:00:20 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 23 Sep 2008 09:00:20 +0200 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222123974.15195.5.camel@localhost.localdomain> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222073364.3330.11.camel@hughsie-work> <1222107745.4108.24.camel@luminos.localdomain> <1222116190.24063.24.camel@hughsie-work> <1222122094.4108.42.camel@luminos.localdomain> <1222123974.15195.5.camel@localhost.localdomain> Message-ID: <1222153220.4159.9.camel@arekh.okg> Le lundi 22 septembre 2008 ? 18:52 -0400, Matthias Clasen a ?crit : > On Mon, 2008-09-22 at 15:21 -0700, Jesse Keating wrote: > > On Mon, 2008-09-22 at 21:43 +0100, Richard Hughes wrote: > > > And just correcting you: this wasn't _my_ decision, this was the result > > > of working with lots of other distros. Sarcasm doesn't help anybody. > > > > Neither does letting other distributions make decisions about ours. > > > Thanks Jesse, for making it clear that you are more interested in > confrontation than a constructive discussion impossible. Constructive discussion needs to be 2 way. I had to write down the PK position on this for people on fedora-devel to learn what decisions were being made for them. And the decisions touched packaging which is fedora-devel main subject. (unfortunately the desktop team mislike for the common distro communication channel is not new). I sure hope the "other distro representatives" we've read so much on were more representative than the Fedora ones. > People who are interested in improving PackageKit should probably take > the discussion to the packagekit list (packagekit at lists.freedesktop.org) But we're not interested in improving PK. We're interested in improving Fedora. If PK intends to focus on a non-Fedora user, we're not interested in PK are we? -- 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 james.antill at redhat.com Tue Sep 23 07:01:39 2008 From: james.antill at redhat.com (James Antill) Date: Tue, 23 Sep 2008 03:01:39 -0400 Subject: Instant Mirror Status...? In-Reply-To: <48D867D8.40304@gmail.com> References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> <48D8154B.9080804@students.iiit.ac.in> <16de708d0809221650n27d4cd7djfa4b39e4ad12ff27@mail.gmail.com> <1222128026.4108.46.camel@luminos.localdomain> <16de708d0809221720r3dad221vac4cb255ccc50490@mail.gmail.com> <48D867D8.40304@gmail.com> Message-ID: <1222153299.29561.7.camel@code.and.org> On Mon, 2008-09-22 at 22:51 -0500, Les Mikesell wrote: > All they should have to do is request the same URLs. > > Why can't that happen automatically? That is, within whatever blocks > geoip might consider 'near', arbitrarily select the first-choice mirror > based on the source IP range in a repeatable way. That way everyone > behind the same proxy requests the same URL and the caching works > automatically. MirrorManager gives the clients the URLs to try in a specific order (and soon with even more data). Yum/urlgrabber will try the URLs in the order it gets them. So what you are saying essentially is: "Why can't MirrorManager decide what the best URL is for a netblock/geoip and always list it first, just to make the proxy problem zero-conf" And I can guess that the answer to that is basically "Because it doesn't work", feel free to send Matt patches though if you think otherwise. It is on my TODO to look at trying to get a usable version of yum-avahi? that people can use, this should solve your proxy problem in a generic way ... although it would do so by routing around it. I also have a lot of things on my TODO list, so again patches welcome :) ? http://users.ecs.soton.ac.uk/rds204/yum-avahi/ -- James Antill Red Hat -------------- 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 tim.lauridsen at googlemail.com Tue Sep 23 07:16:54 2008 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Tue, 23 Sep 2008 09:16:54 +0200 Subject: No dynamic groups in PackageKit In-Reply-To: <1222150606.30758.65.camel@code.and.org> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> <1222150606.30758.65.camel@code.and.org> Message-ID: <48D897E6.4090600@googlemail.com> I think this discussion is getting a little heated and it is not the most constructive, if you want something to change IMHO. I agree in there is some issues with the static groups currently in pk. so i have made this proposal on the upstream packagekit list. http://lists.freedesktop.org/archives/packagekit/2008-September/003675.html To solve some of the issues being discussed in this thread. Tim From hughsient at gmail.com Tue Sep 23 07:45:37 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 23 Sep 2008 08:45:37 +0100 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> Message-ID: <1222155937.3265.3.camel@hughsie-work> On Mon, 2008-09-22 at 20:49 +0000, Kevin Kofler wrote: > But those "tons of comps groups" need to be shown! For example > PackageKit isn't showing the KDE Software Development group at all. We > need that group shown (and as a group, not a metapackage). You think we NEED a "KDE Software Development group". PackageKit is not designed for you. Can you explain how having fine grained groups would help people like: http://www.packagekit.org/pk-profiles.html ? PackageKit is not designed for the sort of users who are comfortable using yum on the command line. PackageKit doesn't replace yum, it's just complimentary. If we designed PK as a "suitable for any user" tool then it would be suitable for no-one. Hence the need for a profiles page. Thanks, Richard. From hughsient at gmail.com Tue Sep 23 07:49:21 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 23 Sep 2008 08:49:21 +0100 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> Message-ID: <1222156161.3265.8.camel@hughsie-work> On Mon, 2008-09-22 at 21:00 +0000, Kevin Kofler wrote: > Jesse Keating redhat.com> writes: > > Is "not suitable for us" supposed to mean that PK is trying to hard to > > be generic across the distros so that we lose the classifications and > > groupings we work on in Fedora, so that PK is not suitable for Fedora? > > I agree that that's about the only conclusion we can draw. I get the impression you don't like PackageKit, which is fine, but I would prefer you stick to helpful suggestions and working _WITH_ upstream rather than dictating what upstream HAS to do according to you. Richard. From hughsient at gmail.com Tue Sep 23 07:52:48 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 23 Sep 2008 08:52:48 +0100 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222153220.4159.9.camel@arekh.okg> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222073364.3330.11.camel@hughsie-work> <1222107745.4108.24.camel@luminos.localdomain> <1222116190.24063.24.camel@hughsie-work> <1222122094.4108.42.camel@luminos.localdomain> <1222123974.15195.5.camel@localhost.localdomain> <1222153220.4159.9.camel@arekh.okg> Message-ID: <1222156368.3265.9.camel@hughsie-work> On Tue, 2008-09-23 at 09:00 +0200, Nicolas Mailhot wrote: > But we're not interested in improving PK. We're interested in > improving Fedora. If PK intends to focus on a non-Fedora user, we're > not interested in PK are we? I don't respond to silly threats, sorry. Richard. From hughsient at gmail.com Tue Sep 23 07:55:46 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 23 Sep 2008 08:55:46 +0100 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222073364.3330.11.camel@hughsie-work> Message-ID: <1222156546.3265.13.camel@hughsie-work> On Mon, 2008-09-22 at 21:09 +0000, Kevin Kofler wrote: > Tristate checkboxes are a very common UI to represent groups where a more > detailed selection is available, many Window$ installers use them (and those > are surely targeted at the average user!), as does Anaconda (or at least used > to do). A tristate in the gray state is a clear hint that you have to go to the > details to see what exactly is selected and unselected. I've done two user-screencasts of people navigating groups using pirut who have never used pirut or PackageKit before. I can upload them somewhere if poeple are interested, although they are pretty big. Tri-state checkboxes are a disaster. Richard. From mls at suse.de Tue Sep 23 08:01:12 2008 From: mls at suse.de (Michael Schroeder) Date: Tue, 23 Sep 2008 10:01:12 +0200 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222156546.3265.13.camel@hughsie-work> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222073364.3330.11.camel@hughsie-work> <1222156546.3265.13.camel@hughsie-work> Message-ID: <20080923080112.GA32652@suse.de> On Tue, Sep 23, 2008 at 08:55:46AM +0100, Richard Hughes wrote: > On Mon, 2008-09-22 at 21:09 +0000, Kevin Kofler wrote: > > Tristate checkboxes are a very common UI to represent groups where a more > > detailed selection is available, many Window$ installers use them (and those > > are surely targeted at the average user!), as does Anaconda (or at least used > > to do). A tristate in the gray state is a clear hint that you have to go to the > > details to see what exactly is selected and unselected. > > I've done two user-screencasts of people navigating groups using pirut > who have never used pirut or PackageKit before. I can upload them > somewhere if poeple are interested, although they are pretty big. I'm interested, could you please make them available? Thanks, Michael. -- Michael Schroeder mls at suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} From hughsient at gmail.com Tue Sep 23 08:11:50 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 23 Sep 2008 09:11:50 +0100 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <20080923080112.GA32652@suse.de> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222073364.3330.11.camel@hughsie-work> <1222156546.3265.13.camel@hughsie-work> <20080923080112.GA32652@suse.de> Message-ID: <1222157510.3265.16.camel@hughsie-work> On Tue, 2008-09-23 at 10:01 +0200, Michael Schroeder wrote: > I'm interested, could you please make them available? Sure, I'll ask kenvandine if I can use packagekit.org (it's a VM in a colo) as I'm betting he's not keen on several people downloading 200Mb+ at at the same time. I've got a 147M quota on rhughes.fedoraproject.org -- is there anyway I can get this bumped up to ~300Mb? Richard. From nicolas.mailhot at laposte.net Tue Sep 23 08:17:00 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 23 Sep 2008 10:17:00 +0200 (CEST) Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222153220.4159.9.camel@arekh.okg> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222073364.3330.11.camel@hughsie-work> <1222107745.4108.24.camel@luminos.localdomain> <1222116190.24063.24.camel@hughsie-work> <1222122094.4108.42.camel@luminos.localdomain> <1222123974.15195.5.camel@localhost.localdomain> <1222153220.4159.9.camel@arekh.okg> Message-ID: Le Mar 23 septembre 2008 09:00, Nicolas Mailhot a ?crit : > Le lundi 22 septembre 2008 ? 18:52 -0400, Matthias Clasen a ?crit : >> Thanks Jesse, for making it clear that you are more interested in >> confrontation than a constructive discussion impossible. > > Constructive discussion needs to be 2 way. Sorry, got carried over. I apologise for the abrasiveness. Still, any decision concerning the way we install or update the distro is releng territory IMHO, and I'm distressed that Jesse didn't seem to be in the loop at all. (I could live with PK people disagreeing with me. That's ok, I disagree with lots of people) -- Nicolas Mailhot From hughsient at gmail.com Tue Sep 23 08:21:11 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 23 Sep 2008 09:21:11 +0100 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222073364.3330.11.camel@hughsie-work> <1222107745.4108.24.camel@luminos.localdomain> <1222116190.24063.24.camel@hughsie-work> <1222122094.4108.42.camel@luminos.localdomain> <1222123974.15195.5.camel@localhost.localdomain> <1222153220.4159.9.camel@arekh.okg> Message-ID: <1222158071.3265.24.camel@hughsie-work> On Tue, 2008-09-23 at 10:17 +0200, Nicolas Mailhot wrote: > Sorry, got carried over. I apologise for the abrasiveness. Cool, thanks. > Still, any decision concerning the way we install or update the distro > is releng territory IMHO, and I'm distressed that Jesse didn't seem to > be in the loop at all. Sure, possibly my fault too -- I always ask people to join the mailing list and jump in on pretty much any discussion -- but maybe I need to actively _invite_ more people. > (I could live with PK people disagreeing with me. That's ok, I > disagree with lots of people) Disagreement is good. People get angry because they care about the outcome, and that's a totally positive thing. Richard. From dominik at greysector.net Tue Sep 23 08:54:17 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Tue, 23 Sep 2008 10:54:17 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080922233924.GA20911@tango.0pointer.de> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <20080922233924.GA20911@tango.0pointer.de> Message-ID: <20080923085417.GA18032@mokona.greysector.net> On Tuesday, 23 September 2008 at 01:39, Lennart Poettering wrote: > On Mon, 15.09.08 16:07, Dominik 'Rathann' Mierzejewski (dominik at greysector.net) wrote: > > > Do you mean Open Source Software or Open Sound System? In case of OSS, > > it's realy a shame, because it was (and still is) a great piece of software > > with nice API and doesn't require any external libraries like ALSA. > > But you can't compare console/X to OSS/ALSA. The latter provide functionality > > I must correct you: the OSS API sucks. And ALSA is certainly a far > greater piece of software than OSS ever was, and among the reasons is > precisely the fact that it is a proper library instead of some fucked up kernel > interface based on ioctls(). > > Everyone hates ioctl()s. The kernel people do. The userspace people > too. An API for application usage that is based around ioctl()s is > thus mandatorily a big failure. The people whose opinion I value disagree. I have no strong opinion of my own, because I never wrote code to interface with either ALSA or OSS. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From pmatilai at laiskiainen.org Tue Sep 23 09:03:10 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 23 Sep 2008 12:03:10 +0300 (EEST) Subject: recover from broken yum transaction In-Reply-To: <1222109535.12513.81.camel@rosebud> References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <20080921125955.GA31700@wolff.to> <20080921224234.GA5640@wolff.to> <20080922005130.GA19894@wolff.to> <1222084531.12513.14.camel@rosebud> <1222109535.12513.81.camel@rosebud> Message-ID: On Mon, 22 Sep 2008, seth vidal wrote: > On Mon, 2008-09-22 at 15:47 -0300, Alexandre Oliva wrote: > >> Right. The problem is when you agree to "update x", i.e., "install >> x-N+1; remove x-N', and it fails (say, in case sys.stdout.write or >> sys.stdout.flush raise an exception within callback) before it gets to >> install x-N+1. Then RPM still ends up removing x-N, although >> sometimes what I saw looked more like a --justdb removal (files and >> libraries left behind, but package gone from the rpmdb), but in >> others, as in the most recent case, elfutils libraries were really >> gone. > > The above really isn't possible. If you can recreate this then please > file a bug. File the bug against rpm but please cc me on it. I wouldn't call it impossible, in fact I just managed to reproduce it with this: --- a/yum/rpmtrans.py +++ b/yum/rpmtrans.py @@ -374,6 +374,7 @@ class RPMTransaction: self.total_installed += 1 self.complete_actions += 1 self.installed_pkg_names.append(hdr['name']) + raise IOError return fd else: self.display.errorlog("Error: No Header to INST_OPEN_FILE") Without having yet looked deeper into it, it probably comes down to this in rpmtsRun(): /* * XXX This has always been a hack, now mostly broken. * If install failed, then we shouldn't erase. */ The hack in question is easily fooled, and so rpm is ultimately responsible for the damage that results from yum code tracebacking in the transaction callback. Rpm needs fixing (I'll go look into it right now), but I'd suggest you go and comb through the ts callback code in yum - you do NOT want it tracebacking, especially on "trivial" things like sys.stdout operations failing. - Panu - From rjones at redhat.com Tue Sep 23 09:01:19 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 23 Sep 2008 10:01:19 +0100 Subject: Heads up: packages with Patch:/%patch0 or Patch0:/%patch issues in Rawhide In-Reply-To: <200809211259.28923.ville.skytta@iki.fi> References: <200809061132.24420.ville.skytta@iki.fi> <200809211259.28923.ville.skytta@iki.fi> Message-ID: <20080923090119.GA22411@amd.home.annexia.org> On Sun, Sep 21, 2008 at 12:59:27PM +0300, Ville Skytt? wrote: > - freetennis (CVS ACLs prevented commit, bug with patch filed) This one is now fixed, plus a FTBFS bug in a dependency which I accidentally broke a few days ago. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From hughsient at gmail.com Tue Sep 23 09:09:39 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 23 Sep 2008 10:09:39 +0100 Subject: specspo and PackageKit Message-ID: <1222160979.3265.37.camel@hughsie-work> Quick question: should PackageKit depend on specspo? If you have the specspo package installed then you get localised package names and descriptions in the client applications, but dragging in specspo adds a 6.9Mb download and 22.7Mb install dep. Ideas welcome. Richard. From rc040203 at freenet.de Tue Sep 23 09:21:06 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 23 Sep 2008 11:21:06 +0200 Subject: specspo and PackageKit In-Reply-To: <1222160979.3265.37.camel@hughsie-work> References: <1222160979.3265.37.camel@hughsie-work> Message-ID: <1222161666.3564.43.camel@beck.corsepiu.local> On Tue, 2008-09-23 at 10:09 +0100, Richard Hughes wrote: > Quick question: should PackageKit depend on specspo? If you have the > specspo package installed then you get localised package names and > descriptions in the client applications, but dragging in specspo adds a > 6.9Mb download and 22.7Mb install dep. Exactly => Too much bloat. > Ideas welcome. I thought, specspo had been scheduled to die, years ago, but I could be wrong. Ralf From tim.lauridsen at googlemail.com Tue Sep 23 09:26:39 2008 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Tue, 23 Sep 2008 11:26:39 +0200 Subject: specspo and PackageKit In-Reply-To: <1222160979.3265.37.camel@hughsie-work> References: <1222160979.3265.37.camel@hughsie-work> Message-ID: <48D8B64F.9010806@googlemail.com> Richard Hughes wrote: > Quick question: should PackageKit depend on specspo? If you have the > specspo package installed then you get localised package names and > descriptions in the client applications, but dragging in specspo adds a > 6.9Mb download and 22.7Mb install dep. > > Ideas welcome. > > Richard. > > No, not a hard depencies, just use it if it is installed. 22.7 Mb will really hurt on a live cd. Tim From giallu at gmail.com Tue Sep 23 09:36:26 2008 From: giallu at gmail.com (Gianluca Sforna) Date: Tue, 23 Sep 2008 11:36:26 +0200 Subject: specspo and PackageKit In-Reply-To: <1222160979.3265.37.camel@hughsie-work> References: <1222160979.3265.37.camel@hughsie-work> Message-ID: On Tue, Sep 23, 2008 at 11:09 AM, Richard Hughes wrote: > Quick question: should PackageKit depend on specspo? If you have the > specspo package installed then you get localised package names and > descriptions in the client applications, but dragging in specspo adds a > 6.9Mb download and 22.7Mb install dep. > Are there statistics about localization coverage in spec files? The bloat is even less desirable if only a handful of packages are going to benefit... From rawhide at fedoraproject.org Tue Sep 23 09:48:52 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Tue, 23 Sep 2008 09:48:52 +0000 (UTC) Subject: rawhide report: 20080923 changes Message-ID: <20080923094852.683AC1F825C@releng2.fedora.phx.redhat.com> New package perl-Gtk2-ImageView Perl bindings to the GtkImageView image viewer widget Updated Packages: anaconda-11.4.1.39-1 -------------------- * Mon Sep 22 18:00:00 2008 David Cantrell - 11.4.1.39-1 - Fix a traceback when getting the interface settings (#462592). (clumens) - self.anaconda -> anaconda (clumens) Summary: Added Packages: 1 Removed Packages: 0 Modified Packages: 1 Broken deps for i386 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.i386 requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so Broken deps for x86_64 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.x86_64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.ppc requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so Broken deps for ppc64 ---------------------------------------------------------- eclipse-checkstyle-4.0.1-10.fc9.ppc64 requires checkstyle-optional = 0:4.1 eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gspiceui-0.9.65-2.fc10.ppc64 requires gwave livecd-tools-018-1.fc10.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.ppc64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) From hughsient at gmail.com Tue Sep 23 09:55:04 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 23 Sep 2008 10:55:04 +0100 Subject: specspo and PackageKit In-Reply-To: <48D8B64F.9010806@googlemail.com> References: <1222160979.3265.37.camel@hughsie-work> <48D8B64F.9010806@googlemail.com> Message-ID: <1222163704.3265.43.camel@hughsie-work> On Tue, 2008-09-23 at 11:26 +0200, Tim Lauridsen wrote: > No, not a hard depencies, just use it if it is installed. > 22.7 Mb will really hurt on a live cd. This is what I thought -- although it's not exactly discoverable for new user when they log in and find "PackageKit doesn't do translations like I've seen in screenshots" Richard. From billcrawford1970 at gmail.com Tue Sep 23 10:03:26 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Tue, 23 Sep 2008 11:03:26 +0100 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080923000006.GB21642@tango.0pointer.de> References: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <1221592366.32342.23.camel@localhost.localdomain> <20080923000006.GB21642@tango.0pointer.de> Message-ID: <200809231103.26560.billcrawford1970@gmail.com> On Tuesday 23 September 2008 01:00:06 Lennart Poettering wrote: > Actually, nowadays I prefer seeing PA as black box, where only PA > decides what device clients should be connecting to, not the clients > themselves. Policy decisions should be up to the sound server, not the > client. This sounds like "we want to control everything" and, as the user of the machine I want to control everything. It's my tool. That's how I expect it to behave, not talk back to me (shades of 2001 here). From hughsient at gmail.com Tue Sep 23 10:17:59 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 23 Sep 2008 11:17:59 +0100 Subject: specspo and PackageKit In-Reply-To: References: <1222160979.3265.37.camel@hughsie-work> Message-ID: <1222165079.3265.48.camel@hughsie-work> On Tue, 2008-09-23 at 11:36 +0200, Gianluca Sforna wrote: > Are there statistics about localization coverage in spec files? The > bloat is even less desirable if only a handful of packages are going > to benefit... Well, I've attached the results of my script to extract and analyse the translations -- and it seems a lot of the packages are well translated. I just keep thinking about how effective an out-of-band translator package is, but the alternative is giant spec files like PLD linux: http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/SPECS/BitTorrent.spec?rev=1.81;content-type=text%2Fplain Richard. -------------- next part -------------- A non-text attachment was scrubbed... Name: specspo.txt.bz2 Type: application/x-bzip Size: 10132 bytes Desc: not available URL: From tim.lauridsen at googlemail.com Tue Sep 23 10:23:56 2008 From: tim.lauridsen at googlemail.com (Tim Lauridsen) Date: Tue, 23 Sep 2008 12:23:56 +0200 Subject: specspo and PackageKit In-Reply-To: <1222163704.3265.43.camel@hughsie-work> References: <1222160979.3265.37.camel@hughsie-work> <48D8B64F.9010806@googlemail.com> <1222163704.3265.43.camel@hughsie-work> Message-ID: <48D8C3BC.40803@googlemail.com> Richard Hughes wrote: > On Tue, 2008-09-23 at 11:26 +0200, Tim Lauridsen wrote: >> No, not a hard depencies, just use it if it is installed. >> 22.7 Mb will really hurt on a live cd. > > This is what I thought -- although it's not exactly discoverable for new > user when they log in and find "PackageKit doesn't do translations like > I've seen in screenshots" > > Richard. > > If you does a normal desktop install, then specspo is installed on the systen AFIAK. (specspo is part of the base group) Tim From hughsient at gmail.com Tue Sep 23 10:39:26 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 23 Sep 2008 11:39:26 +0100 Subject: specspo and PackageKit In-Reply-To: <48D8C3BC.40803@googlemail.com> References: <1222160979.3265.37.camel@hughsie-work> <48D8B64F.9010806@googlemail.com> <1222163704.3265.43.camel@hughsie-work> <48D8C3BC.40803@googlemail.com> Message-ID: <1222166366.3265.50.camel@hughsie-work> On Tue, 2008-09-23 at 12:23 +0200, Tim Lauridsen wrote: > If you does a normal desktop install, then specspo is installed on the > systen AFIAK. (specspo is part of the base group) Ahh, brilliant, thanks. Richard. From mschwendt at gmail.com Tue Sep 23 10:53:49 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Tue, 23 Sep 2008 12:53:49 +0200 Subject: specspo and PackageKit In-Reply-To: <1222161666.3564.43.camel@beck.corsepiu.local> References: <1222160979.3265.37.camel@hughsie-work> <1222161666.3564.43.camel@beck.corsepiu.local> Message-ID: <20080923125349.fc8a758e.mschwendt@gmail.com> On Tue, 23 Sep 2008 11:21:06 +0200, Ralf Corsepius wrote: > On Tue, 2008-09-23 at 10:09 +0100, Richard Hughes wrote: > > Quick question: should PackageKit depend on specspo? If you have the > > specspo package installed then you get localised package names and > > descriptions in the client applications, but dragging in specspo adds a > > 6.9Mb download and 22.7Mb install dep. > Exactly => Too much bloat. > > > Ideas welcome. > I thought, specspo had been scheduled to die, years ago, but I could be > wrong. If not, then who maintains it these days? From stickster at gmail.com Tue Sep 23 11:29:59 2008 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 23 Sep 2008 07:29:59 -0400 Subject: F11 Spins process refinement In-Reply-To: <48D86B92.80303@redhat.com> References: <48D86B92.80303@redhat.com> Message-ID: <1222169399.22903.15.camel@victoria-eth.internal.frields.org> On Mon, 2008-09-22 at 21:07 -0700, John Poelstra wrote: > Jon Stanley said the following on 09/22/2008 08:33 PM Pacific Time: > > What I need is *a volunteer* from each of the below groups to attend > > this call. The reason for a single (or at most two) people from each > > group is to facilitate an efficient, manageable call that stands a > > fighting chance of accomplishing something :) > > > > Spins SIG > > Release Engineering > > Board > > FESCo > > > > I'll also be reaching out to Bryan Kearney, who has some experience > > going through this process, and some suggestions for refinement. > > > > It's not listed above, but I would be happy to contribute as note taker > and diagram drawer if that is helpful. I know this would be much appreciated John -- thanks! (I'm slightly answering for Jon but I can guess he'll be in favor.) :-) -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Tue Sep 23 12:09:43 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 23 Sep 2008 08:09:43 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080922233924.GA20911@tango.0pointer.de> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <20080922233924.GA20911@tango.0pointer.de> Message-ID: <20080923120943.GB7813@shell.devel.redhat.com> On Tue, Sep 23, 2008 at 01:39:24AM +0200, Lennart Poettering wrote: > Everyone hates ioctl()s. The kernel people do. The userspace people Not true. Ioctl has a very important place in things. From limb at jcomserv.net Tue Sep 23 12:11:30 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Tue, 23 Sep 2008 07:11:30 -0500 (CDT) Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <1222066937.3186.18.camel@s1.crocom.com.pl> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221787714.3433.5.camel@ignacio.lan> <20080919104020.3958c1c5@ohm.scrye.com> <1221842915.5524.5.camel@hughsie-work> <1222066937.3186.18.camel@s1.crocom.com.pl> Message-ID: <31045.198.175.55.5.1222171890.squirrel@mail.jcomserv.net> > Dnia 2008-09-19, pi? o godzinie 17:48 +0100, Richard Hughes pisze: >> On Fri, 2008-09-19 at 10:40 -0600, Kevin Fenzi wrote: >> > Would anyone care to take over tpb? Or does anyone even use it these >> > days? Perhaps we can just drop it? >> ThinkPads, just like any other model, should "just work" without any >> special daemons installed. > > My z61t isn't. Fn+number keys probably work (I pressed "lock" and > screen locked), but volume and mute keys do not work. When I press them > nothing happens - "xev" shows nothing and dmesg is silent. So since there it seems there is still a need for tpb, albeit temporarily, Kevin, will you be orphaning it, or EOLing it? > -- > Tomasz Torcz > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From skvidal at fedoraproject.org Tue Sep 23 12:10:54 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 23 Sep 2008 08:10:54 -0400 Subject: recover from broken yum transaction In-Reply-To: References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <20080921125955.GA31700@wolff.to> <20080921224234.GA5640@wolff.to> <20080922005130.GA19894@wolff.to> <1222084531.12513.14.camel@rosebud> <1222109535.12513.81.camel@rosebud> Message-ID: <1222171854.4144.0.camel@rosebud> On Tue, 2008-09-23 at 12:03 +0300, Panu Matilainen wrote: > > The above really isn't possible. If you can recreate this then please > > file a bug. File the bug against rpm but please cc me on it. > > I wouldn't call it impossible, in fact I just managed to reproduce it with > this: You're right - I should have said 'shouldn't be possible'. Not isn't possible. > Without having yet looked deeper into it, it probably comes down to this > in rpmtsRun(): > /* > * XXX This has always been a hack, now mostly broken. > * If install failed, then we shouldn't erase. > */ > That's a nice fixme to have. :) > The hack in question is easily fooled, and so rpm is ultimately > responsible for the damage that results from yum code tracebacking in the > transaction callback. Rpm needs fixing (I'll go look into it right now), > but I'd suggest you go and comb through the ts callback code in yum - you > do NOT want it tracebacking, especially on "trivial" things like > sys.stdout operations failing. I'll look into it, thanks, -sv From mzerqung at 0pointer.de Tue Sep 23 12:18:31 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 14:18:31 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <200809231103.26560.billcrawford1970@gmail.com> References: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <1221592366.32342.23.camel@localhost.localdomain> <20080923000006.GB21642@tango.0pointer.de> <200809231103.26560.billcrawford1970@gmail.com> Message-ID: <20080923121831.GA7596@tango.0pointer.de> On Tue, 23.09.08 11:03, Bill Crawford (billcrawford1970 at gmail.com) wrote: > > On Tuesday 23 September 2008 01:00:06 Lennart Poettering wrote: > > > Actually, nowadays I prefer seeing PA as black box, where only PA > > decides what device clients should be connecting to, not the clients > > themselves. Policy decisions should be up to the sound server, not the > > client. > > This sounds like "we want to control everything" and, as the user of the machine > I want to control everything. It's my tool. That's how I expect it to behave, > not talk back to me (shades of 2001 here). Bah, bah, bah! I take that "world domination" goal very personal, you know? I want to control all your audio streams, muaahahahahah! Muahahahahah! All your streams are belong to us! muahahahaah! Seriously, of course the sound server should decide the device policy based on *user settings*, and it already does just that. PA will decide things for you -- but only based on your preferences. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From skvidal at fedoraproject.org Tue Sep 23 12:19:02 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 23 Sep 2008 08:19:02 -0400 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222157510.3265.16.camel@hughsie-work> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222073364.3330.11.camel@hughsie-work> <1222156546.3265.13.camel@hughsie-work> <20080923080112.GA32652@suse.de> <1222157510.3265.16.camel@hughsie-work> Message-ID: <1222172342.4144.2.camel@rosebud> On Tue, 2008-09-23 at 09:11 +0100, Richard Hughes wrote: > On Tue, 2008-09-23 at 10:01 +0200, Michael Schroeder wrote: > > I'm interested, could you please make them available? > > Sure, I'll ask kenvandine if I can use packagekit.org (it's a VM in a > colo) as I'm betting he's not keen on several people downloading 200Mb+ > at at the same time. > > I've got a 147M quota on rhughes.fedoraproject.org -- is there anyway I > can get this bumped up to ~300Mb? it's rhughes.fedorapeople.org and your quota is now raised to 400M -sv From mzerqung at 0pointer.de Tue Sep 23 12:21:26 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 14:21:26 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080923085417.GA18032@mokona.greysector.net> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <20080922233924.GA20911@tango.0pointer.de> <20080923085417.GA18032@mokona.greysector.net> Message-ID: <20080923122126.GB7596@tango.0pointer.de> On Tue, 23.09.08 10:54, Dominik 'Rathann' Mierzejewski (dominik at greysector.net) wrote: > > > Do you mean Open Source Software or Open Sound System? In case of OSS, > > > it's realy a shame, because it was (and still is) a great piece of software > > > with nice API and doesn't require any external libraries like ALSA. > > > But you can't compare console/X to OSS/ALSA. The latter provide functionality > > > > I must correct you: the OSS API sucks. And ALSA is certainly a far > > greater piece of software than OSS ever was, and among the reasons is > > precisely the fact that it is a proper library instead of some fucked up kernel > > interface based on ioctls(). > > > > Everyone hates ioctl()s. The kernel people do. The userspace people > > too. An API for application usage that is based around ioctl()s is > > thus mandatorily a big failure. > > The people whose opinion I value disagree. I have no strong opinion > of my own, because I never wrote code to interface with either ALSA > or OSS. Oh my. So you know someone who thinks that ioctl()s are ingenious API design? You probably should choose your friends more carefully, then. ;-) Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From galibert at pobox.com Tue Sep 23 12:26:18 2008 From: galibert at pobox.com (Olivier Galibert) Date: Tue, 23 Sep 2008 14:26:18 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080923122126.GB7596@tango.0pointer.de> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <20080922233924.GA20911@tango.0pointer.de> <20080923085417.GA18032@mokona.greysector.net> <20080923122126.GB7596@tango.0pointer.de> Message-ID: <20080923122618.GA90772@dspnet.fr.eu.org> On Tue, Sep 23, 2008 at 02:21:26PM +0200, Lennart Poettering wrote: > Oh my. So you know someone who thinks that ioctl()s are ingenious API > design? You probably should choose your friends more carefully, then. ;-) ALSA's kernel interface is 100% ioctl. It doesn't even use read() or write(). OG. From hughsient at gmail.com Tue Sep 23 12:23:48 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 23 Sep 2008 13:23:48 +0100 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222172342.4144.2.camel@rosebud> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222073364.3330.11.camel@hughsie-work> <1222156546.3265.13.camel@hughsie-work> <20080923080112.GA32652@suse.de> <1222157510.3265.16.camel@hughsie-work> <1222172342.4144.2.camel@rosebud> Message-ID: <1222172628.3265.65.camel@hughsie-work> On Tue, 2008-09-23 at 08:19 -0400, seth vidal wrote: > > it's rhughes.fedorapeople.org > > and your quota is now raised to 400M Legend, thanks. I'll upload this afternoon. Richard From mzerqung at 0pointer.de Tue Sep 23 12:24:17 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 14:24:17 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080923120943.GB7813@shell.devel.redhat.com> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <20080922233924.GA20911@tango.0pointer.de> <20080923120943.GB7813@shell.devel.redhat.com> Message-ID: <20080923122417.GC7596@tango.0pointer.de> On Tue, 23.09.08 08:09, Alan Cox (alan at redhat.com) wrote: > > On Tue, Sep 23, 2008 at 01:39:24AM +0200, Lennart Poettering wrote: > > Everyone hates ioctl()s. The kernel people do. The userspace people > > Not true. Ioctl has a very important place in things. Sure they have. But its an awkward interface. Everything multiplexed via a single syscall. Unreadable/unpronouncable names. No type-safety, not even size-safety. No proper signatures. ioctl()s are awful. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Tue Sep 23 12:37:48 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 14:37:48 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080923122618.GA90772@dspnet.fr.eu.org> References: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <20080922233924.GA20911@tango.0pointer.de> <20080923085417.GA18032@mokona.greysector.net> <20080923122126.GB7596@tango.0pointer.de> <20080923122618.GA90772@dspnet.fr.eu.org> Message-ID: <20080923123748.GE7596@tango.0pointer.de> On Tue, 23.09.08 14:26, Olivier Galibert (galibert at pobox.com) wrote: > > On Tue, Sep 23, 2008 at 02:21:26PM +0200, Lennart Poettering wrote: > > Oh my. So you know someone who thinks that ioctl()s are ingenious API > > design? You probably should choose your friends more carefully, then. ;-) > > ALSA's kernel interface is 100% ioctl. It doesn't even use read() or > write(). I know. But ALSA hides that in a library, so you never have to deal with these ugly details. Ain't that great? OTOH OSS' programmers interface *is* the ioctls themselves. And that's one reason why its API sucks. Also, OSS is practically not virtualizable. (LD_PRELOAD and CUSE are hacks, that only work for the smallest part) The timing model is broken. The entire design is hardware-specific, and focusses on hw we had 20 years ago. OSS as an API is terrible. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From rc040203 at freenet.de Tue Sep 23 12:38:57 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 23 Sep 2008 14:38:57 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080923122126.GB7596@tango.0pointer.de> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <20080922233924.GA20911@tango.0pointer.de> <20080923085417.GA18032@mokona.greysector.net> <20080923122126.GB7596@tango.0pointer.de> Message-ID: <1222173537.3564.69.camel@beck.corsepiu.local> On Tue, 2008-09-23 at 14:21 +0200, Lennart Poettering wrote: > On Tue, 23.09.08 10:54, Dominik 'Rathann' Mierzejewski (dominik at greysector.net) wrote: > Oh my. So you know someone who thinks that ioctl()s are ingenious API > design? What do ioctls and files/stream not provide that you are missing? ioctls essentially are "descriptor"/"tag"/"arbitrary argument". An interface can hardly be more generic than this. From mzerqung at 0pointer.de Tue Sep 23 12:47:10 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 14:47:10 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1222173537.3564.69.camel@beck.corsepiu.local> References: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <20080922233924.GA20911@tango.0pointer.de> <20080923085417.GA18032@mokona.greysector.net> <20080923122126.GB7596@tango.0pointer.de> <1222173537.3564.69.camel@beck.corsepiu.local> Message-ID: <20080923124710.GF7596@tango.0pointer.de> On Tue, 23.09.08 14:38, Ralf Corsepius (rc040203 at freenet.de) wrote: > > On Tue, 2008-09-23 at 14:21 +0200, Lennart Poettering wrote: > > On Tue, 23.09.08 10:54, Dominik 'Rathann' Mierzejewski (dominik at greysector.net) wrote: > > > Oh my. So you know someone who thinks that ioctl()s are ingenious API > > design? > What do ioctls and files/stream not provide that you are missing? > > ioctls essentially are "descriptor"/"tag"/"arbitrary argument". > An interface can hardly be more generic than this. Yes, and the fact that it is that generic is the weakness. You know, we have this wonderful language called C. It's all about tape-safety and having nice names for things and having proper signatures for functions and being descriptive. ioctl()s go against all that. They are not type-safe, have unreadable names, have no signatures and are everthing but descriptive. Let's say every single libc call would have been mutlipexed by a single function call. i.e. instead of calling malloc() like this: a = malloc(4711); you'd call: a = (void*) libc(LC_MLLC, 4711); Now think of hwo your program would look like in its entirety: unreadable. Absolutely crazy and unreadable. Now ioctl() does exactly this: a vast number of function calls are multiplexed via a single function call. Big fuckup. And everyone who claims that that would be good API design is just wrong, really, really wrong. It's not good. It's a fuckup. It's terrible. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From lesmikesell at gmail.com Tue Sep 23 12:57:42 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 23 Sep 2008 07:57:42 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080923122126.GB7596@tango.0pointer.de> References: <16de708d0809121559qf7f054boc5d6ccfcd0f88b9f@mail.gmail.com> <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <20080922233924.GA20911@tango.0pointer.de> <20080923085417.GA18032@mokona.greysector.net> <20080923122126.GB7596@tango.0pointer.de> Message-ID: <48D8E7C6.3080500@gmail.com> Lennart Poettering wrote: > On Tue, 23.09.08 10:54, Dominik 'Rathann' Mierzejewski (dominik at greysector.net) wrote: > >>>> Do you mean Open Source Software or Open Sound System? In case of OSS, >>>> it's realy a shame, because it was (and still is) a great piece of software >>>> with nice API and doesn't require any external libraries like ALSA. >>>> But you can't compare console/X to OSS/ALSA. The latter provide functionality >>> I must correct you: the OSS API sucks. And ALSA is certainly a far >>> greater piece of software than OSS ever was, and among the reasons is >>> precisely the fact that it is a proper library instead of some fucked up kernel >>> interface based on ioctls(). >>> >>> Everyone hates ioctl()s. The kernel people do. The userspace people >>> too. An API for application usage that is based around ioctl()s is >>> thus mandatorily a big failure. >> The people whose opinion I value disagree. I have no strong opinion >> of my own, because I never wrote code to interface with either ALSA >> or OSS. > > Oh my. So you know someone who thinks that ioctl()s are ingenious API > design? You probably should choose your friends more carefully, then. ;-) They are nicely minimalistic in that they permit device-specific operations to be passed to a driver without waiting for some overly-bulky generalized intermediate API that thinks it knows what every device/driver might ever need to do. The down side is that it is very hard to subsequently decouple the application from the device - for example to let it use a remote device on a machine with different bit/byte ordering. -- Les Mikesell lesmikesell at gmail.com From mzerqung at 0pointer.de Tue Sep 23 12:59:27 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 14:59:27 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: References: <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <48CE65A9.8040401@poolshark.org> <1221487743.18327.612.camel@beck.corsepiu.local> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080922235731.GA21642@tango.0pointer.de> Message-ID: <20080923125927.GG7596@tango.0pointer.de> On Tue, 23.09.08 00:35, Gregory Maxwell (gmaxwell at gmail.com) wrote: > >> 5.) While I paplay, I try to go Ctrl-Alt-F1. While I'm not prevented > >> from doing so, paplay believes it should pause playing while I'm away > >> from the gui tty. Now, who's the genius that figured out this > >> "feature?" > > > > I did. And it actually is a feature. It fixes a long standing security > > issue. > [snip] > > I'm missing how write access (as opposed to read/recording) to an > audio device creates a material security vulnerability. It seems that > the majority of the complaints are that playback stops and that it > surprises the user. Recording stopping may also be surprising, but > it's easy to explain the security argument there. It's true that being able to eavesdrop in your record streams is a bigger security hole than just eavesdropping what you play. Nonethless it's still a hole: they'd still be able to listen to one direction of your voip call, and they'd still be able to play a fake stream that you might then end up trusting. We already had this discussion here twice or more times. I do believe the right way is to suspend audio when we switch sessions by default. I also acknowledge that it is valid for users to put security second and have audio continue to play. In fact and as I already mentioned, I have this on my TODO list, but way down. I am always happy to take patches BTW. If this feature is important to you the best thing to make it happen is actually write the code yourself! Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From rc040203 at freenet.de Tue Sep 23 13:02:32 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 23 Sep 2008 15:02:32 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080923124710.GF7596@tango.0pointer.de> References: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <20080922233924.GA20911@tango.0pointer.de> <20080923085417.GA18032@mokona.greysector.net> <20080923122126.GB7596@tango.0pointer.de> <1222173537.3564.69.camel@beck.corsepiu.local> <20080923124710.GF7596@tango.0pointer.de> Message-ID: <1222174952.3564.75.camel@beck.corsepiu.local> On Tue, 2008-09-23 at 14:47 +0200, Lennart Poettering wrote: > On Tue, 23.09.08 14:38, Ralf Corsepius (rc040203 at freenet.de) wrote: > > > > > On Tue, 2008-09-23 at 14:21 +0200, Lennart Poettering wrote: > > > On Tue, 23.09.08 10:54, Dominik 'Rathann' Mierzejewski (dominik at greysector.net) wrote: > > > > > Oh my. So you know someone who thinks that ioctl()s are ingenious API > > > design? > > What do ioctls and files/stream not provide that you are missing? > > > > ioctls essentially are "descriptor"/"tag"/"arbitrary argument". > > An interface can hardly be more generic than this. > > Yes, and the fact that it is that generic is the weakness. > > You know, we have this wonderful language called C. It's all about > tape-safety and having nice names for things and having proper > signatures for functions and being descriptive. ioctl()s go against > all that. They are not type-safe, have unreadable names, have no > signatures and are everthing but descriptive. > > Let's say every single libc call would have been mutlipexed by a > single function call. i.e. instead of calling malloc() like this: > > a = malloc(4711); > > you'd call: > > a = (void*) libc(LC_MLLC, 4711); > > Now think of hwo your program would look like in its entirety: > unreadable. Absolutely crazy and unreadable. > > Now ioctl() does exactly this: a vast number of function calls are > multiplexed via a single function call. Big fuckup. And everyone who > claims that that would be good API design is just wrong, really, > really wrong. It's not good. It's a fuckup. It's terrible. And I tell you: You are wrong, plain wrong. ioctl's are a well defined _low level_ interface, providing a clean and "natural" separation between kernel and userspace. To make them easily applicable in high-level userspace applications, they are supposed to be wrapped. From mzerqung at 0pointer.de Tue Sep 23 13:05:29 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 15:05:29 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <48D85D71.4020503@gmail.com> References: <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <20080922180001.GA8379@sonata.rednote.net> <20080923001815.GE21642@tango.0pointer.de> <48D85D71.4020503@gmail.com> Message-ID: <20080923130529.GH7596@tango.0pointer.de> On Mon, 22.09.08 22:07, Les Mikesell (lesmikesell at gmail.com) wrote: > > Lennart Poettering wrote: >> To suspend audio for inactive sessions and only allow audio for active >> sessions fixes a big security hole. > > But it sucks if you are playing music for the room and someone else wants > to check their email. Yes, I know that some people don't like that behaviour. We had this discussion already. I already put it on my TODO list months ago. We can end this discussion here and now. >> And it's not just we who fixed >> this hole like this. Apple for example does it too. And usually Apple >> is the gold standard of user-friendliness, right? > > No, it sucks just as much when itunes does it. You expect that kind of > stuff from Apple who only has a short history of multi-user machines and > who would really rather sell you an apple tv or ipod with dock that you can > dedicate to driving your speakers, though. Linux has always been multi-user > and doesn't have any such excuses for arbitrarily disconnecting > devices. "arbitrarily"? Oh man. Claiming that things are right because Linux always did it this way is not very convincing. You never noticed that quite a few things in Linux haven't been all that shiny right from day 0? Some things got fixed by now, and this is just another instance. >> Allowing multiple different users audio device access at the same is a >> security nightmare. It has been with ALSA dmix. And it is even more so >> in PA. > > Doesn't the kernel have a mechanism for exclusive locks on devices if > someone wants to have exclusive access? It's not all that difficult to > eavesdrop on music playing loudly anyway... Access to audio devices (both OSS and ALSA) is exclusive by default anyway. >> Far down on my todo list is adding some kind of handover logic between >> multiple PA instances, so that we can add fading of audio when we >> switch sessions. This would also allow us to continue playback from >> inactive sessions if the now active user is OK with that. But this is >> complex, security-sensitive and not a priority. So don't expect any >> quick results. > > What's the right way to set up a media player service that isn't attached > to anyone's session? You can bypass PA if you wish. Or run a specific tailored PA instance for it. It's up to you. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Tue Sep 23 13:07:36 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 15:07:36 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1222174952.3564.75.camel@beck.corsepiu.local> References: <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <20080922233924.GA20911@tango.0pointer.de> <20080923085417.GA18032@mokona.greysector.net> <20080923122126.GB7596@tango.0pointer.de> <1222173537.3564.69.camel@beck.corsepiu.local> <20080923124710.GF7596@tango.0pointer.de> <1222174952.3564.75.camel@beck.corsepiu.local> Message-ID: <20080923130736.GI7596@tango.0pointer.de> On Tue, 23.09.08 15:02, Ralf Corsepius (rc040203 at freenet.de) wrote: > > Let's say every single libc call would have been mutlipexed by a > > single function call. i.e. instead of calling malloc() like this: > > > > a = malloc(4711); > > > > you'd call: > > > > a = (void*) libc(LC_MLLC, 4711); > > > > Now think of hwo your program would look like in its entirety: > > unreadable. Absolutely crazy and unreadable. > > > > Now ioctl() does exactly this: a vast number of function calls are > > multiplexed via a single function call. Big fuckup. And everyone who > > claims that that would be good API design is just wrong, really, > > really wrong. It's not good. It's a fuckup. It's terrible. > > And I tell you: You are wrong, plain wrong. > > ioctl's are a well defined _low level_ interface, providing a clean and > "natural" separation between kernel and userspace. > To make them easily applicable in high-level userspace applications, > they are supposed to be wrapped. Yepp! That's exactly what I was saying: OSS as an application programmers interface is a trainwreck because it directly exposes ioctls. ioctl as an API for normal programs == bad! When ioctls are hidden to normal programs like ALSA does it == acceptable! Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From alan at redhat.com Tue Sep 23 13:26:49 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 23 Sep 2008 09:26:49 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080923123748.GE7596@tango.0pointer.de> References: <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <20080922233924.GA20911@tango.0pointer.de> <20080923085417.GA18032@mokona.greysector.net> <20080923122126.GB7596@tango.0pointer.de> <20080923122618.GA90772@dspnet.fr.eu.org> <20080923123748.GE7596@tango.0pointer.de> Message-ID: <20080923132649.GA16844@shell.devel.redhat.com> On Tue, Sep 23, 2008 at 02:37:48PM +0200, Lennart Poettering wrote: > OTOH OSS' programmers interface *is* the ioctls themselves. And that's > one reason why its API sucks. Thats a 'nobody wrote the library' case > Also, OSS is practically not virtualizable. (LD_PRELOAD and CUSE are > hacks, that only work for the smallest part) The timing model is > broken. The entire design is hardware-specific, and focusses on hw we The timing model is crap, but the rest of the design is neither hardware specific no focussed on twenty year old hardware - in fact todays hardware looks more and more like the hardware of twenty years ago but with more channels. From mclasen at redhat.com Tue Sep 23 13:46:36 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 23 Sep 2008 09:46:36 -0400 Subject: specspo and PackageKit In-Reply-To: References: <1222160979.3265.37.camel@hughsie-work> Message-ID: <1222177596.3920.1.camel@localhost.localdomain> On Tue, 2008-09-23 at 11:36 +0200, Gianluca Sforna wrote: > On Tue, Sep 23, 2008 at 11:09 AM, Richard Hughes wrote: > > Quick question: should PackageKit depend on specspo? If you have the > > specspo package installed then you get localised package names and > > descriptions in the client applications, but dragging in specspo adds a > > 6.9Mb download and 22.7Mb install dep. > > > > Are there statistics about localization coverage in spec files? The > bloat is even less desirable if only a handful of packages are going > to benefit... If we want to be able to say with a straight face that we have an end-user software installation application, then translated package descriptions are pretty much a must. From mzerqung at 0pointer.de Tue Sep 23 14:01:10 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 16:01:10 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080923132649.GA16844@shell.devel.redhat.com> References: <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <20080922233924.GA20911@tango.0pointer.de> <20080923085417.GA18032@mokona.greysector.net> <20080923122126.GB7596@tango.0pointer.de> <20080923122618.GA90772@dspnet.fr.eu.org> <20080923123748.GE7596@tango.0pointer.de> <20080923132649.GA16844@shell.devel.redhat.com> Message-ID: <20080923140110.GA15557@tango.0pointer.de> On Tue, 23.09.08 09:26, Alan Cox (alan at redhat.com) wrote: > > On Tue, Sep 23, 2008 at 02:37:48PM +0200, Lennart Poettering wrote: > > OTOH OSS' programmers interface *is* the ioctls themselves. And that's > > one reason why its API sucks. > > Thats a 'nobody wrote the library' case No it's not. The people behind OSS (i.e. Hannu) advertise the kernel API is the audio API to use for normal programs. Because they do this they moved mixing and sample type conversion into the kernel in OSS4. > > Also, OSS is practically not virtualizable. (LD_PRELOAD and CUSE are > > hacks, that only work for the smallest part) The timing model is > > broken. The entire design is hardware-specific, and focusses on hw we > > The timing model is crap, but the rest of the design is neither hardware > specific no focussed on twenty year old hardware - in fact todays hardware > looks more and more like the hardware of twenty years ago but with more > channels. Oh, of course it is hardware specific. Stuff like fragments and stuff are very hardware specific. Software sound servers don't want to expose fragment-based buffering metrics. Instead a modern sound system wants to expose latency values and process time values. Then, the fact that OSS assumes that the DAC reads directly from the hw playback buffer makes the whole thing questionable already on USB hardware. That you even get access to the hardware buffer makes it very hardware-specific. Using OSS for more than 2ch sensibly is practically not possible. Modern sound systems want to disable sound card interrupts as far as possible and schedule audio via system timers, OSS always wants fragment interrupts. Modern sound systems want huge buffers and the ability to rewind software pointers. OSS cannot do this (at most partially if you use mmap() which opens a lot of additional problems and is shaky ground). No decibel information for mixers. Then, the way fragments work in OSS you couldn't even express something like "buffer size 200ms, fillup when only 10ms left". And this list goes on and on. In short: how modern software wants to drive a sound card has changed quite a bit. And OSS3 is from the early 90's. So it's focussed on hardware, and it is focussed on hw and sw from 20y ago. An SB16 is quite different from a modern HDA sound card. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From skvidal at fedoraproject.org Tue Sep 23 14:05:29 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 23 Sep 2008 10:05:29 -0400 Subject: specspo and PackageKit In-Reply-To: <1222177596.3920.1.camel@localhost.localdomain> References: <1222160979.3265.37.camel@hughsie-work> <1222177596.3920.1.camel@localhost.localdomain> Message-ID: <1222178729.4144.6.camel@rosebud> On Tue, 2008-09-23 at 09:46 -0400, Matthias Clasen wrote: > On Tue, 2008-09-23 at 11:36 +0200, Gianluca Sforna wrote: > > On Tue, Sep 23, 2008 at 11:09 AM, Richard Hughes wrote: > > > Quick question: should PackageKit depend on specspo? If you have the > > > specspo package installed then you get localised package names and > > > descriptions in the client applications, but dragging in specspo adds a > > > 6.9Mb download and 22.7Mb install dep. > > > > > > > Are there statistics about localization coverage in spec files? The > > bloat is even less desirable if only a handful of packages are going > > to benefit... > > If we want to be able to say with a straight face that we have an > end-user software installation application, then translated package > descriptions are pretty much a must. I don't think he was saying we shouldn't translate the pkgs - I think he was saying - specspo might just be a bad solution. for example - translating pkgs might best be served by translating the metadata in external files. -sv From gnome at dux-linux.org Tue Sep 23 14:13:11 2008 From: gnome at dux-linux.org (gnome at dux-linux.org) Date: Tue, 23 Sep 2008 07:13:11 -0700 Subject: Orphan Packages: mrxvt and astyle Message-ID: <20080923071311.85c7159e41fef2a72f1f5b5eafb9f4e5.a9a4778a43.wbe@email.secureserver.net> An HTML attachment was scrubbed... URL: From alan at redhat.com Tue Sep 23 14:23:50 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 23 Sep 2008 10:23:50 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080923140110.GA15557@tango.0pointer.de> References: <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <20080922233924.GA20911@tango.0pointer.de> <20080923085417.GA18032@mokona.greysector.net> <20080923122126.GB7596@tango.0pointer.de> <20080923122618.GA90772@dspnet.fr.eu.org> <20080923123748.GE7596@tango.0pointer.de> <20080923132649.GA16844@shell.devel.redhat.com> <20080923140110.GA15557@tango.0pointer.de> Message-ID: <20080923142350.GB22565@shell.devel.redhat.com> On Tue, Sep 23, 2008 at 04:01:10PM +0200, Lennart Poettering wrote: > > Thats a 'nobody wrote the library' case > > No it's not. The people behind OSS (i.e. Hannu) advertise the kernel > API is the audio API to use for normal programs. Because they do this > they moved mixing and sample type conversion into the kernel in OSS4. Please don't confuse Hannu's later stuff with what the kernel community accepted. > In short: how modern software wants to drive a sound card has changed > quite a bit. And OSS3 is from the early 90's. So it's focussed on > hardware, and it is focussed on hw and sw from 20y ago. An SB16 is > quite different from a modern HDA sound card. Not vastly, its a DMA pipe with a DAC on the end Alan From hughsient at gmail.com Tue Sep 23 14:16:44 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 23 Sep 2008 15:16:44 +0100 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080923121831.GA7596@tango.0pointer.de> References: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <1221592366.32342.23.camel@localhost.localdomain> <20080923000006.GB21642@tango.0pointer.de> <200809231103.26560.billcrawford1970@gmail.com> <20080923121831.GA7596@tango.0pointer.de> Message-ID: <1222179404.3265.67.camel@hughsie-work> On Tue, 2008-09-23 at 14:18 +0200, Lennart Poettering wrote: > All your streams are belong to us! You've seen the EULA example, right? http://www.packagekit.org/img/gpk-eula.png Richard. From debarshi.ray at gmail.com Tue Sep 23 14:34:28 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Tue, 23 Sep 2008 20:04:28 +0530 Subject: Orphan Packages: mrxvt and astyle In-Reply-To: <20080923071311.85c7159e41fef2a72f1f5b5eafb9f4e5.a9a4778a43.wbe@email.secureserver.net> References: <20080923071311.85c7159e41fef2a72f1f5b5eafb9f4e5.a9a4778a43.wbe@email.secureserver.net> Message-ID: <3170f42f0809230734x68ee38cese3c80993e3907e2e@mail.gmail.com> > Since helping to get mrxvt and astyle included into Fedora a few releases > back my life has become a lot busier. > [...] > I've followed the orphan procedure as indicated on the > wiki and will also e-mail the source code owners and let them know these > packages are going into orphaned status. I see that you have Mamoru Tasaka and Brian Pepple as co-maintainers. If and only if they are not interested, I can take care of astyle. Cheers, Debarshi From james.antill at redhat.com Tue Sep 23 14:41:15 2008 From: james.antill at redhat.com (James Antill) Date: Tue, 23 Sep 2008 10:41:15 -0400 Subject: recover from broken yum transaction In-Reply-To: References: <3da3b5b40809101824m2d05d182n2cd129a7df67c24a@mail.gmail.com> <1221105038.987.147.camel@rosebud> <20080921125955.GA31700@wolff.to> <20080921224234.GA5640@wolff.to> <20080922005130.GA19894@wolff.to> <1222084531.12513.14.camel@rosebud> <1222109535.12513.81.camel@rosebud> Message-ID: <1222180875.4078.5.camel@code.and.org> On Tue, 2008-09-23 at 12:03 +0300, Panu Matilainen wrote: > On Mon, 22 Sep 2008, seth vidal wrote: > > > On Mon, 2008-09-22 at 15:47 -0300, Alexandre Oliva wrote: > > > >> Right. The problem is when you agree to "update x", i.e., "install > >> x-N+1; remove x-N', and it fails (say, in case sys.stdout.write or > >> sys.stdout.flush raise an exception within callback) before it gets to > >> install x-N+1. Then RPM still ends up removing x-N, although > >> sometimes what I saw looked more like a --justdb removal (files and > >> libraries left behind, but package gone from the rpmdb), but in > >> others, as in the most recent case, elfutils libraries were really > >> gone. > > > > The above really isn't possible. If you can recreate this then please > > file a bug. File the bug against rpm but please cc me on it. > > I wouldn't call it impossible, in fact I just managed to reproduce it with > this: > --- a/yum/rpmtrans.py > +++ b/yum/rpmtrans.py > @@ -374,6 +374,7 @@ class RPMTransaction: > self.total_installed += 1 > self.complete_actions += 1 > self.installed_pkg_names.append(hdr['name']) > + raise IOError > return fd > else: > self.display.errorlog("Error: No Header to INST_OPEN_FILE") > > > Without having yet looked deeper into it, it probably comes down to this > in rpmtsRun(): > /* > * XXX This has always been a hack, now mostly broken. > * If install failed, then we shouldn't erase. > */ > > The hack in question is easily fooled, and so rpm is ultimately > responsible for the damage that results from yum code tracebacking in the > transaction callback. I think Seth meant "I find it impossible that rpm has a bug/feature which would allow this to happen" ... but he's just way too much of a raving optimist :). > Rpm needs fixing (I'll go look into it right now), > but I'd suggest you go and comb through the ts callback code in yum - you > do NOT want it tracebacking, especially on "trivial" things like > sys.stdout operations failing. I think I've worked around the "normal" cases on the yum side with: http://devel.linux.duke.edu/gitweb/?p=yum.git;a=commitdiff;h=cf896fc7ccc135aeb94d69739bb625fc44934377 and http://devel.linux.duke.edu/gitweb/?p=yum.git;a=commitdiff;h=0aed92573666a4e09650e5a5c0f25357ac957d2a ...although it doesn't "fix" the patch above, I think it'll work around the ssh case ... Alexandre, if you can reproduce it can you try it with the latest from the yum-3_2_X branch? -- James Antill Red Hat -------------- 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 mzerqung at 0pointer.de Tue Sep 23 14:42:21 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 16:42:21 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080923142350.GB22565@shell.devel.redhat.com> References: <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <20080922233924.GA20911@tango.0pointer.de> <20080923085417.GA18032@mokona.greysector.net> <20080923122126.GB7596@tango.0pointer.de> <20080923122618.GA90772@dspnet.fr.eu.org> <20080923123748.GE7596@tango.0pointer.de> <20080923132649.GA16844@shell.devel.redhat.com> <20080923140110.GA15557@tango.0pointer.de> <20080923142350.GB22565@shell.devel.redhat.com> Message-ID: <20080923144221.GA19381@tango.0pointer.de> On Tue, 23.09.08 10:23, Alan Cox (alan at redhat.com) wrote: > > In short: how modern software wants to drive a sound card has changed > > quite a bit. And OSS3 is from the early 90's. So it's focussed on > > hardware, and it is focussed on hw and sw from 20y ago. An SB16 is > > quite different from a modern HDA sound card. > > Not vastly, its a DMA pipe with a DAC on the end There's not necessarily a DAC at "the end" anymore. Could be SPDIF too. And if you say that a modern sound card behaves very similarly to early 90's sound card because it ues DMA, then you could say that sound card is very similar to a harddisk, too. Which is definitely true in a way. The really interesting part of audio is not the data transfer, it's the timing. And that's where hardware changed. And software too. And OSS is broken and legacy. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Tue Sep 23 14:53:58 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 16:53:58 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <1222179404.3265.67.camel@hughsie-work> References: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <1221592366.32342.23.camel@localhost.localdomain> <20080923000006.GB21642@tango.0pointer.de> <200809231103.26560.billcrawford1970@gmail.com> <20080923121831.GA7596@tango.0pointer.de> <1222179404.3265.67.camel@hughsie-work> Message-ID: <20080923145358.GC19381@tango.0pointer.de> On Tue, 23.09.08 15:16, Richard Hughes (hughsient at gmail.com) wrote: > > On Tue, 2008-09-23 at 14:18 +0200, Lennart Poettering wrote: > > All your streams are belong to us! > > You've seen the EULA example, right? > http://www.packagekit.org/img/gpk-eula.png Awesome! How do I add this to my packages? ;-) Although actually, I think for my goal of world domination it would be counterprodutive to first ask for permission. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mtasaka at ioa.s.u-tokyo.ac.jp Tue Sep 23 14:59:20 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Tue, 23 Sep 2008 23:59:20 +0900 Subject: Orphan Packages: mrxvt and astyle In-Reply-To: <3170f42f0809230734x68ee38cese3c80993e3907e2e@mail.gmail.com> References: <20080923071311.85c7159e41fef2a72f1f5b5eafb9f4e5.a9a4778a43.wbe@email.secureserver.net> <3170f42f0809230734x68ee38cese3c80993e3907e2e@mail.gmail.com> Message-ID: <48D90448.3010702@ioa.s.u-tokyo.ac.jp> Hi; Debarshi Ray wrote, at 09/23/2008 11:34 PM +9:00: >> Since helping to get mrxvt and astyle included into Fedora a few releases >> back my life has become a lot busier. >> [...] >> I've followed the orphan procedure as indicated on the >> wiki and will also e-mail the source code owners and let them know these >> packages are going into orphaned status. > > I see that you have Mamoru Tasaka and Brian Pepple as co-maintainers. > If and only if they are not interested, I can take care of astyle. > > Cheers, > Debarshi I would appreciate it if you would take over maintainership of these packages, Regards, Mamoru From alan at redhat.com Tue Sep 23 15:02:34 2008 From: alan at redhat.com (Alan Cox) Date: Tue, 23 Sep 2008 11:02:34 -0400 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080923144221.GA19381@tango.0pointer.de> References: <20080915140703.GI20342@mokona.greysector.net> <20080922233924.GA20911@tango.0pointer.de> <20080923085417.GA18032@mokona.greysector.net> <20080923122126.GB7596@tango.0pointer.de> <20080923122618.GA90772@dspnet.fr.eu.org> <20080923123748.GE7596@tango.0pointer.de> <20080923132649.GA16844@shell.devel.redhat.com> <20080923140110.GA15557@tango.0pointer.de> <20080923142350.GB22565@shell.devel.redhat.com> <20080923144221.GA19381@tango.0pointer.de> Message-ID: <20080923150234.GB27042@shell.devel.redhat.com> On Tue, Sep 23, 2008 at 04:42:21PM +0200, Lennart Poettering wrote: > > Not vastly, its a DMA pipe with a DAC on the end > > There's not necessarily a DAC at "the end" anymore. Could be SPDIF > too. SPDIF is over 20 years old too. There is a DAC somewhere and will be until you get a copy protection jack and license slot embedded in your skull... > the timing. And that's where hardware changed. And software too. And > OSS is broken and legacy. Not a lot - it started much like todays stuff, got all fancy and complicated and is now back on the dumb end of the cycle with hardware raytraced sound presumably going to be the next 'do it in hardware' cycle. Alan From mike at miketc.net Tue Sep 23 15:10:21 2008 From: mike at miketc.net (Mike Chambers) Date: Tue, 23 Sep 2008 10:10:21 -0500 Subject: rawhide report: 20080923 changes In-Reply-To: <20080923094852.683AC1F825C@releng2.fedora.phx.redhat.com> References: <20080923094852.683AC1F825C@releng2.fedora.phx.redhat.com> Message-ID: <1222182621.7141.1.camel@scrappy.miketc.net> On Tue, 2008-09-23 at 09:48 +0000, Rawhide Report wrote: > Updated Packages: > > anaconda-11.4.1.39-1 > -------------------- > * Mon Sep 22 18:00:00 2008 David Cantrell - 11.4.1.39-1 > - Fix a traceback when getting the interface settings (#462592). (clumens) > - self.anaconda -> anaconda (clumens) Is the fix above for the network config issues coming out of stage2 and such? -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From ajax at redhat.com Tue Sep 23 15:33:04 2008 From: ajax at redhat.com (Adam Jackson) Date: Tue, 23 Sep 2008 11:33:04 -0400 Subject: Fedora not "free" enough for GNU? In-Reply-To: References: <8553.1220772699@sss.pgh.pa.us> <200809071523.44582.ben.kreuter@gmail.com> <604aa7910809071240u1923df65i8861e58de856540b@mail.gmail.com> <604aa7910809211144s77460d18se7d6620518c4db56@mail.gmail.com> <80d7e4090809211419p78edad66k18a297ab151e0b25@mail.gmail.com> <1222111167.15981.358.camel@atropine.boston.devel.redhat.com> Message-ID: <1222183984.15981.410.camel@atropine.boston.devel.redhat.com> On Mon, 2008-09-22 at 17:32 -0300, Alexandre Oliva wrote: > On Sep 22, 2008, Adam Jackson wrote: > > a problem that is not universally agreed to be a problem at all. > > in spite of Fedora's stated goals. Only if you think firmware is 100% software and 100% not content. This is far from being an obvious or trivial distinction. > > But, now for a real technical objection: > > > atropine:~% uname -a > > Linux atropine 2.6.27-0.314.rc5.git9.fc10.i686 #1 SMP Sun Sep 7 20:57:41 > > EDT 2008 i686 i686 i386 GNU/Linux > > atropine:~% modinfo -F firmware aic7xxx | wc -l > > 0 > > Erhm... Are you sure aic7xxx was built with any expectation of > loading firmware through the standard firmware-loading interface, > rather than of having it built right into the kernel image? It appears to not use request_firmware(), correct. But that's sort of the point. kernel-libre makes no attempt to fix those drivers to use the firmware loader, afaict. Without that, stripping firmware from disk drivers (and network drivers, for that matter) is explicitly saying that some people's machines are worth sacrificing in the name of firmware purity. Given that firmware purity is not universally accepted to be a problem worth solving, kernel-libre as it stands is not going to be universally accepted as a solution worth adopting. Now you've expressed your distaste for converting such drivers to the firmware loader before, on the grounds that it encourages the use of non-free firmware, which is not your goal. That's well within your rights to decide. It's also the primary functional reason (as far as I can tell) that kernel-libre is not something Fedora can consume. Are you more interested in having produced a libre kernel package, or in having users run it? - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From Matt_Domsch at dell.com Tue Sep 23 15:33:46 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 23 Sep 2008 10:33:46 -0500 Subject: Instant Mirror Status...? In-Reply-To: <1222153299.29561.7.camel@code.and.org> References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> <48D8154B.9080804@students.iiit.ac.in> <16de708d0809221650n27d4cd7djfa4b39e4ad12ff27@mail.gmail.com> <1222128026.4108.46.camel@luminos.localdomain> <16de708d0809221720r3dad221vac4cb255ccc50490@mail.gmail.com> <48D867D8.40304@gmail.com> <1222153299.29561.7.camel@code.and.org> Message-ID: <20080923153346.GA10633@auslistsprd01.us.dell.com> On Tue, Sep 23, 2008 at 03:01:39AM -0400, James Antill wrote: > On Mon, 2008-09-22 at 22:51 -0500, Les Mikesell wrote: > > All they should have to do is request the same URLs. > > > > Why can't that happen automatically? That is, within whatever blocks > > geoip might consider 'near', arbitrarily select the first-choice mirror > > based on the source IP range in a repeatable way. That way everyone > > behind the same proxy requests the same URL and the caching works > > automatically. GeoIP doesn't have this level of granularity. Best we can get from that database "for free" is the country for a given address. Furthermore, I absolutely don't want to return the same mirror at the top of the list _for everyone_ in a given country. We want to load balance the requests across the mirrors in a given country. If your organization wants to ensure that everyone within it always is directed to the same mirror first, get the mirror owner to add your organization's netblock to the list of netblocks on their entry in MM's database. Then MM will always hand out that mirror to your users first. > MirrorManager gives the clients the URLs to try in a specific order > (and soon with even more data). Yum/urlgrabber will try the URLs in the > order it gets them. > So what you are saying essentially is: "Why can't MirrorManager decide > what the best URL is for a netblock/geoip and always list it first, just > to make the proxy problem zero-conf" > And I can guess that the answer to that is basically "Because it > doesn't work", feel free to send Matt patches though if you think > otherwise. If someone can give me a method of getting the entire Internet's BGP routing table, and a good algorithm for finding the bandwidth-weighted shortest path between two arbitrary points in that table, I'll gladly include that in MM. Until then, MM simply can't know enough to always give you the same (ideally correct) answer for any given set of clients. The netblocks trick is already pretty slick, and "good enough" for a lot of folks. but yes, patches would be welcome! Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From galibert at pobox.com Tue Sep 23 15:40:35 2008 From: galibert at pobox.com (Olivier Galibert) Date: Tue, 23 Sep 2008 17:40:35 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080923123748.GE7596@tango.0pointer.de> References: <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <20080922233924.GA20911@tango.0pointer.de> <20080923085417.GA18032@mokona.greysector.net> <20080923122126.GB7596@tango.0pointer.de> <20080923122618.GA90772@dspnet.fr.eu.org> <20080923123748.GE7596@tango.0pointer.de> Message-ID: <20080923154035.GA11588@dspnet.fr.eu.org> On Tue, Sep 23, 2008 at 02:37:48PM +0200, Lennart Poettering wrote: > I know. But ALSA hides that in a library, so you never have to deal > with these ugly details. Ain't that great? Depends on the library. In ALSA's case, it's a particularly badly designed one, annoyingly enough. As an API, OSS is better. OG. From choeger at cs.tu-berlin.de Tue Sep 23 15:58:14 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 23 Sep 2008 17:58:14 +0200 Subject: speed up boot about 10s Message-ID: <1222185494.9042.10.camel@choeger6> Hi, I'm playing around with bootchart and had an initial boot time of 45s. When I did the usual stuff (disabling senseless services) I came to 42s. Then I picked the biggest fish: udevsettle sleeps for about 5s and does what? I added udevtimeout=1 to the cmdline to get rid of it and had no problem but an annoying error message on boot and 4s less boot time. I also tried to start rhgb in background from rc.sysinit simply by calling /usr/bin/rhgb& That again saved me 3s (but let rhgb run in background forever using 100% cpu). Ive lost rhgb X-output a while ago and don't know why (maybe an update put out a regression, I do not boot my laptop that often), so I cannot test if that kind of stuff works, but at least somehow the process should be killed somewhen ;) To make a conclusion: making startup of blocks in rc.sysinit parallel is worth some work ;) What about the future? Does plymouth start parallel? Is someone working on speeding up nash-hotplug? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From casimiro.barreto at gmail.com Tue Sep 23 16:07:42 2008 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Tue, 23 Sep 2008 13:07:42 -0300 Subject: pam_mount is still buggy In-Reply-To: <8d601c9757566dc068a5e6fba5703303.squirrel@mail.voxel.net> References: <48D8021F.7020906@gmail.com> <8d601c9757566dc068a5e6fba5703303.squirrel@mail.voxel.net> Message-ID: <48D9144E.2060007@gmail.com> W. Michael Petullo escreveu: >> Of note is that pam_mount was working about 3 weeks ago... Except it >> refused to unmount the volumes when user logged off. >> > > I am no longer the maintainer of pam_mount (upstream or package), but I > can address this part of your issue. The pam_mount module will not be able > to unmount a home directory if processes still remain with open file > descriptors in the directory. Last I looked, many user daemons (e.g., > gconf?) remained for a few seconds or minutes after a user logged out. > > If you look through GNOME and Red Hat's bugzilla, you will see a couple of > examples of this that were fixed. You will also find some examples that > were never fixed upstream. > > It used to be that you could instruct pam_mount to run lsof and log the > output to help troubleshoot this. I don't know if this feature is still > available, but it would identify which processes are causing the problem. > > Mike > > > Ok. I created an error report at bugzilla. As I am not currently using GDM (the packed version is not manageable enough... I couldn't find a way to disable the -nolisten in the X server) but your observations about processes kept running while system tries to unmount fs are true. I regard this bug as severe but I got a little frustrated: either few people uses "old fashioned" encrypted file systems or it is something wrong the way I configured things... -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From bpepple at fedoraproject.org Tue Sep 23 16:17:04 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 23 Sep 2008 12:17:04 -0400 Subject: Plan for tomorrows (20080924) FESCO meeting Message-ID: <1222186624.14583.2.camel@truman> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Wednesday at 18:00 UTC in #fedora-meeting on irc.freenode.org: /topic FESCo-Meeting -- F10 Schedule slip - https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01938.html - all /topic FESCo-Meeting -- MinGW - all /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule. You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From kevin.kofler at chello.at Tue Sep 23 16:30:42 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 23 Sep 2008 16:30:42 +0000 (UTC) Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222155937.3265.3.camel@hughsie-work> Message-ID: Richard Hughes gmail.com> writes: > You think we NEED a "KDE Software Development group". PackageKit is not > designed for you. Can you explain how having fine grained groups would > help people like: http://www.packagekit.org/pk-profiles.html ? Well, at least the med student could have a use for a "medical applications" group (which I'm aware does not currently exist, but that's not PackageKit's problem ;-) ), if not now, at least in the future. And you have only 3 profiles, that's a pretty small sample of all the users around, I'm sure there are many more users with needs for at least one specialized group (with the end result that _all_ specialized groups are needed). > PackageKit is not designed for the sort of users who are comfortable > using yum on the command line. PackageKit doesn't replace yum, it's just > complimentary. Power users can benefit a lot from a UI which is designed with them in mind. I don't consider this "design for newbies only, power users can just use the command line" premise helpful. > If we designed PK as a "suitable for any user" tool then > it would be suitable for no-one. Hence the need for a profiles page. That's an assumption which has yet to be proven. For example, KDE aims at being usable both by new users and by power users and is IMHO fairly successful at that. And another issue is that the library design doesn't allow making a more powerful UI on top of the same library, because the "simple" groups are hardcoded and there's no API to get to the actual groups. Even if we accept your premise that a package manager for power users necessarily has to be a different application, it would still be nice to be able to build it on the same library. Reinventing the wheel to work around library limitations would be a big waste. For example, KPackageKit could potentially be that "more powerful UI" if the library allowed it. Kevin Kofler From kwhiskerz at gmail.com Tue Sep 23 16:34:07 2008 From: kwhiskerz at gmail.com (kwhiskerz) Date: Tue, 23 Sep 2008 10:34:07 -0600 Subject: Missing awesfx package Message-ID: <200809231034.08191.kwhiskerz@gmail.com> Is awesfx not going to be in FX? It is required for loading sound fonts into the emu10k1 card memory for playing midi without the use of a software workaround like timidity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From poelstra at redhat.com Tue Sep 23 16:38:51 2008 From: poelstra at redhat.com (John Poelstra) Date: Tue, 23 Sep 2008 09:38:51 -0700 Subject: Plan for tomorrows (20080924) FESCO meeting In-Reply-To: <1222186624.14583.2.camel@truman> References: <1222186624.14583.2.camel@truman> Message-ID: <48D91B9B.1050401@redhat.com> Brian Pepple said the following on 09/23/2008 09:17 AM Pacific Time: > Hi, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Wednesday at 18:00 > UTC in #fedora-meeting on irc.freenode.org: > > /topic FESCo-Meeting -- F10 Schedule slip - > https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01938.html - all > > /topic FESCo-Meeting -- MinGW - all > > /topic FESCo meeting -- Free discussion around Fedora > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule. You can also propose topics > in the meeting while it is in the "Free discussion around Fedora" phase. > > Later, > /B > FESCo should consider items #1 and #2 below. Copying liberally from: https://fedoraproject.org/wiki/Releases/10/FeatureList (1) Unfinished features (no response from page owner)--consider for dropping [1]: https://fedoraproject.org/wiki/Features/EFI https://fedoraproject.org/wiki/Features/GoodHaskellSupport (2) Unfinished features which should be evaluated as to whether they should remain on the F10 list. I cannot tell from the status summary whether they are in a "testable" state or complete enough for Beta [1]: https://fedoraproject.org/wiki/Features/HDTVEnhancements https://fedoraproject.org/wiki/Features/KernelModesetting https://fedoraproject.org/wiki/Features/Sugar https://fedoraproject.org/wiki/Features/LXDE (3) Unfinished features which appear to be "testable" for beta: https://fedoraproject.org/wiki/Features/BetterStartup https://fedoraproject.org/wiki/Features/BetterWebcamSupport https://fedoraproject.org/wiki/Features/EchoIconTheme https://fedoraproject.org/wiki/Features/GNOME2_24 https://fedoraproject.org/wiki/Features/GStreamer_dependencies_in_RPM https://fedoraproject.org/wiki/Features/RPM4.6 https://fedoraproject.org/wiki/Features/SaveToBugzilla [1]--https://fedoraproject.org/wiki/Features/Policy/Dropping From hughsient at gmail.com Tue Sep 23 16:46:02 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 23 Sep 2008 17:46:02 +0100 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222155937.3265.3.camel@hughsie-work> Message-ID: <1222188362.3265.89.camel@hughsie-work> On Tue, 2008-09-23 at 16:30 +0000, Kevin Kofler wrote: > Richard Hughes gmail.com> writes: > > You think we NEED a "KDE Software Development group". PackageKit is not > > designed for you. Can you explain how having fine grained groups would > > help people like: http://www.packagekit.org/pk-profiles.html ? > > Well, at least the med student could have a use for a "medical applications" > group (which I'm aware does not currently exist, but that's not PackageKit's > problem ;-) ) A simple collection (one package) would solve that need, rather than a whole group of packages that she wouldn't know what any of them did. > , if not now, at least in the future. And you have only 3 > profiles, that's a pretty small sample of all the users around, I'm sure there > are many more users with needs for at least one specialized group (with the end > result that _all_ specialized groups are needed). You cannot design a program for everybody. If you do that, then it's suitable for nobody. > And another issue is that the library design doesn't allow making a more > powerful UI on top of the same library, because the "simple" groups are > hardcoded and there's no API to get to the actual groups. You mean the DBUS API is not sufficient. > Even if we accept > your premise that a package manager for power users necessarily has to be a > different application, it would still be nice to be able to build it on the > same library. Reinventing the wheel to work around library limitations would be > a big waste. For example, KPackageKit could potentially be that "more powerful > UI" if the library allowed it. kpackagekit uses it's own bindings and library. If you actually joined the upstream mailing list, you can see we are discussing what to do, perhaps adding another group API to compliment the "simple one". But now I'm bored, it just seems like you are wasting my time. I listen most to people that actually contribute code. Sorry to be blunt. Richard. From jkeating at redhat.com Tue Sep 23 16:51:10 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 23 Sep 2008 09:51:10 -0700 Subject: Plan for tomorrows (20080924) FESCO meeting In-Reply-To: <1222186624.14583.2.camel@truman> References: <1222186624.14583.2.camel@truman> Message-ID: <1222188670.4108.65.camel@luminos.localdomain> On Tue, 2008-09-23 at 12:17 -0400, Brian Pepple wrote: > /topic FESCo-Meeting -- F10 Schedule slip - > https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01938.html - all Any chance we can get a decision on this today? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alain.portal at free.fr Tue Sep 23 16:53:38 2008 From: alain.portal at free.fr (Alain PORTAL) Date: Tue, 23 Sep 2008 18:53:38 +0200 Subject: They are really ???????! In-Reply-To: <48D02920.4010204@gmail.com> References: <200809162300.16635.alain.portal@free.fr> <200809162332.46304.alain.portal@free.fr> <48D02920.4010204@gmail.com> Message-ID: <200809231853.40202.alain.portal@free.fr> Le mardi 16 septembre 2008, Nicoleau Fabien a ?crit : > Alain PORTAL a ?crit : > > Le mardi 16 septembre 2008, Nicoleau Fabien a ?crit : > >> It's false. > >> Your post is always available here: > >> http://forums.fedora-fr.org/viewtopic.php?id=35529 > >> and has never been deleted. > > > > Oh ? > > Comme c'est facile de ressuciter un post sur un autre forum... > > > > Pas une trace pour indiquer que le post a ?t? d?plac?. Pourtant, > > d'habitude, ils ne se g?nent pas. > > > > Kevin, if you can continue > > I saw your post when you created it. It was already in this forum. > "Moved" posts have still a link on old place when they are moved. This > post has NEVER been moved or deleted. Never say never! Bouska admit the post have been moved... http://forums.fedora-fr.org/viewtopic.php?pid=297488#p297488 > Can you provied the old link (if exists) ? > Perhpas you are just wrong, and just made a mistake when you created the > post (wrong forum ?). This is no so serious to insult (again and again) > french community. Not the french community! Only the fedora-fr.org headquaters... -- Les pages de manuel Linux en fran?ais http://manpagesfr.free.fr/ -------------- 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 mzerqung at 0pointer.de Tue Sep 23 17:05:25 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 19:05:25 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080923154035.GA11588@dspnet.fr.eu.org> References: <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <20080922233924.GA20911@tango.0pointer.de> <20080923085417.GA18032@mokona.greysector.net> <20080923122126.GB7596@tango.0pointer.de> <20080923122618.GA90772@dspnet.fr.eu.org> <20080923123748.GE7596@tango.0pointer.de> <20080923154035.GA11588@dspnet.fr.eu.org> Message-ID: <20080923170525.GA22873@tango.0pointer.de> On Tue, 23.09.08 17:40, Olivier Galibert (galibert at pobox.com) wrote: > > I know. But ALSA hides that in a library, so you never have to deal > > with these ugly details. Ain't that great? > > Depends on the library. In ALSA's case, it's a particularly badly > designed one, annoyingly enough. As an API, OSS is better. I know both APIs very very well. Probably much better than most people. I have been using features of both APIs that apparently noone ever used before me. PA probably uses a larger part of the ALSA API than any other client. And from that experience I can say that while ALSA has issues it certainly gets much much more right than OSS ever did. But anyway. We have to agree to disagree. This discussion is pointless. Let's end this here. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From jkeating at redhat.com Tue Sep 23 17:07:21 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 23 Sep 2008 10:07:21 -0700 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222188362.3265.89.camel@hughsie-work> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222155937.3265.3.camel@hughsie-work> <1222188362.3265.89.camel@hughsie-work> Message-ID: <1222189641.4108.66.camel@luminos.localdomain> On Tue, 2008-09-23 at 17:46 +0100, Richard Hughes wrote: > I listen > most to people that actually contribute code. This is not going to be helpful. Which of http://www.packagekit.org/pk-profiles.html these people contributed code to PackageKit? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mzerqung at 0pointer.de Tue Sep 23 17:07:42 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 19:07:42 +0200 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <20080923150234.GB27042@shell.devel.redhat.com> References: <20080922233924.GA20911@tango.0pointer.de> <20080923085417.GA18032@mokona.greysector.net> <20080923122126.GB7596@tango.0pointer.de> <20080923122618.GA90772@dspnet.fr.eu.org> <20080923123748.GE7596@tango.0pointer.de> <20080923132649.GA16844@shell.devel.redhat.com> <20080923140110.GA15557@tango.0pointer.de> <20080923142350.GB22565@shell.devel.redhat.com> <20080923144221.GA19381@tango.0pointer.de> <20080923150234.GB27042@shell.devel.redhat.com> Message-ID: <20080923170742.GB22873@tango.0pointer.de> On Tue, 23.09.08 11:02, Alan Cox (alan at redhat.com) wrote: > Not a lot - it started much like todays stuff, got all fancy and complicated > and is now back on the dumb end of the cycle with hardware raytraced sound > presumably going to be the next 'do it in hardware' cycle. Still the timing model, which is the most interesting part is broken and out-of-date in OSS. Anyway, this discussion is pointless too. Let's end this. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From nicoleau.fabien at gmail.com Tue Sep 23 17:06:44 2008 From: nicoleau.fabien at gmail.com (Nicoleau Fabien) Date: Tue, 23 Sep 2008 19:06:44 +0200 Subject: They are really ???????! In-Reply-To: <200809231853.40202.alain.portal@free.fr> References: <200809162300.16635.alain.portal@free.fr> <200809162332.46304.alain.portal@free.fr> <48D02920.4010204@gmail.com> <200809231853.40202.alain.portal@free.fr> Message-ID: <48D92224.9080108@gmail.com> Alain PORTAL a ?crit : > Le mardi 16 septembre 2008, Nicoleau Fabien a ?crit : > >> Alain PORTAL a ?crit : >> >>> Le mardi 16 septembre 2008, Nicoleau Fabien a ?crit : >>> >>>> It's false. >>>> Your post is always available here: >>>> http://forums.fedora-fr.org/viewtopic.php?id=35529 >>>> and has never been deleted. >>>> >>> Oh ? >>> Comme c'est facile de ressuciter un post sur un autre forum... >>> >>> Pas une trace pour indiquer que le post a ?t? d?plac?. Pourtant, >>> d'habitude, ils ne se g?nent pas. >>> >>> Kevin, if you can continue >>> >> I saw your post when you created it. It was already in this forum. >> "Moved" posts have still a link on old place when they are moved. This >> post has NEVER been moved or deleted. >> > > Never say never! > Bouska admit the post have been moved... > http://forums.fedora-fr.org/viewtopic.php?pid=297488#p297488 > > >> Can you provied the old link (if exists) ? >> Perhpas you are just wrong, and just made a mistake when you created the >> post (wrong forum ?). This is no so serious to insult (again and again) >> french community. >> > > Not the french community! > Only the fedora-fr.org headquaters... > > zzzzzzzz Your original complains where about deleted post. OK, your post has been moved to a forum that fits better (in my opinion) to its subject. I think that french community deserves a big punishment and insults that you told for that. From fedora at leemhuis.info Tue Sep 23 17:13:04 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 23 Sep 2008 19:13:04 +0200 Subject: No dynamic groups in PackageKit In-Reply-To: <48D897E6.4090600@googlemail.com> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> <1222150606.30758.65.camel@code.and.org> <48D897E6.4090600@googlemail.com> Message-ID: <48D923A0.4060001@leemhuis.info> On 23.09.2008 09:16, Tim Lauridsen wrote: > I think this discussion is getting a little heated and it is not the > most constructive, if you want something to change IMHO. > > I agree in there is some issues with the static groups currently in pk. > so i have made this proposal on the upstream packagekit list. > > http://lists.freedesktop.org/archives/packagekit/2008-September/003675.html > > To solve some of the issues being discussed in this thread. As the one that started this thread (which I didn wasn't meant to become a PK-bashing (sub-)thread) let me say: thx Tim for working towards a better solution. BTW, not sure if it matters, but might be a good time to bring it up: Livna/RPM Fusion in the past tried to put its packages into the same groups as Fedora did. That somehow broke or confused groupinstall in yum iirc (never looked into the details; just heard it from skvidal and others); thus instead of trying to extend the groups Fedora defined we now define our own -- e.g. the groups have a different "groupid" and a string like "(RPM Fusion free)" got added to each of the groups descriptions(?). That IMHO might have been fine as a short term solution. But IMHO it's the wrong thing to do (especially should PK use dynamic groups), as the user normally should not have to care at all where a package comes from. Not sure what's the best way to fix this. Cu knurd (?) for the curious: comps.xml files for RPM Fusion can be found at http://cvs.rpmfusion.org/viewvc/comps/comps-f10.xml.in?root=free&view=markup http://cvs.rpmfusion.org/viewvc/comps/comps-f10.xml.in?root=nonfree&view=markup From csnook at redhat.com Tue Sep 23 17:19:41 2008 From: csnook at redhat.com (Chris Snook) Date: Tue, 23 Sep 2008 13:19:41 -0400 Subject: Fedora i686 Live image (Desktop) 43megs oversize... In-Reply-To: <1222130156.4108.52.camel@luminos.localdomain> References: <1222130156.4108.52.camel@luminos.localdomain> Message-ID: <48D9252D.9080202@redhat.com> Jesse Keating wrote: > Need to cut something out here. Looking deeper into it. I just replaced a 73 MB F9 kernel with a 15 MB rawhide kernel. If your package manifest hasn't changed, I'd check to see if you've got one of those incompletely stripped kernel RPMs. -- Chris From jkeating at redhat.com Tue Sep 23 17:22:29 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 23 Sep 2008 10:22:29 -0700 Subject: No dynamic groups in PackageKit In-Reply-To: <48D923A0.4060001@leemhuis.info> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> <1222150606.30758.65.camel@code.and.org> <48D897E6.4090600@googlemail.com> <48D923A0.4060001@leemhuis.info> Message-ID: <1222190549.4108.69.camel@luminos.localdomain> On Tue, 2008-09-23 at 19:13 +0200, Thorsten Leemhuis wrote: > Livna/RPM Fusion in the past tried to put its packages into the same > groups as Fedora did. That somehow broke or confused groupinstall in yum > iirc (never looked into the details; just heard it from skvidal and > others) I do believe the problem was that you used the same group names, but different descriptions. If you had used the exact same name/description/translation/etc... and /only/ changed the package contents it would have been just fine. (that's what we do with the groupdata in the release repos and the updates repos. Only the package items change, nothing else) -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Tue Sep 23 17:24:38 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 23 Sep 2008 10:24:38 -0700 Subject: Fedora i686 Live image (Desktop) 43megs oversize... In-Reply-To: <48D9252D.9080202@redhat.com> References: <1222130156.4108.52.camel@luminos.localdomain> <48D9252D.9080202@redhat.com> Message-ID: <1222190678.4108.70.camel@luminos.localdomain> On Tue, 2008-09-23 at 13:19 -0400, Chris Snook wrote: > Jesse Keating wrote: > > Need to cut something out here. Looking deeper into it. > > I just replaced a 73 MB F9 kernel with a 15 MB rawhide kernel. If your package > manifest hasn't changed, I'd check to see if you've got one of those > incompletely stripped kernel RPMs. > > -- Chris > The compose is of rawhide packages. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Tue Sep 23 17:27:00 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 23 Sep 2008 19:27:00 +0200 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222188362.3265.89.camel@hughsie-work> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222155937.3265.3.camel@hughsie-work> <1222188362.3265.89.camel@hughsie-work> Message-ID: <1222190820.19205.8.camel@arekh.okg> Le mardi 23 septembre 2008 ? 17:46 +0100, Richard Hughes a ?crit : > On Tue, 2008-09-23 at 16:30 +0000, Kevin Kofler wrote: > > Richard Hughes gmail.com> writes: > > > You think we NEED a "KDE Software Development group". PackageKit is not > > > designed for you. Can you explain how having fine grained groups would > > > help people like: http://www.packagekit.org/pk-profiles.html ? > > > > Well, at least the med student could have a use for a "medical applications" > > group (which I'm aware does not currently exist, but that's not PackageKit's > > problem ;-) ) > > A simple collection (one package) would solve that need, rather than a > whole group of packages that she wouldn't know what any of them did. Users like simple jumbo mono-package solutions, but they're not maintenable in the real world (and are usually a licensing trap). Comps complexity and number of packages/groups have not evolvded from a wish to make users or comps writers life difficult, but from the need to present lots of granular packages (engineering, maintainership and legal requirement) to people with lots of different interests (many targetted groups) It's always easy to present one-shot specialized solutions. The difficulty is scaling because separate maintenance of specialized overlapping package collections is not efficient). When you refuse to look at scaling problems you're missing the core of the problem. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From walters at verbum.org Tue Sep 23 16:55:02 2008 From: walters at verbum.org (Colin Walters) Date: Tue, 23 Sep 2008 12:55:02 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080923002543.GF21642@tango.0pointer.de> References: <48CE65A9.8040401@poolshark.org> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> Message-ID: On Mon, Sep 22, 2008 at 8:25 PM, Lennart Poettering wrote: > As far as I know we again allow multiple simultaneous X logins by the > same user. If we do, it's broken. > Also, PA supports console logins now, where multiple logins > are the common case. One of the many ways in which the consoles are broken. > I'd love to have a per-homedir/per-machine bus in D-Bus. This would > allow me to start PA up via normal activation. Unfortunately we don't > have such a bus and adding it to D-Bus is admittedly questionnable > since only in the fewest cases using such a bus is valid. Those cases > are the ones where machine-specific resources are managed by a user > dbus service. Besides PA only the new V4L daemon (possibly) comes to > my mind that fall into this category. Adding such a bus for just two > users probably doesn't make too much sense. Especially since according > to Scott Upstart will eventually support starting per-user "singleton" > daemons easily. Adding such a bus makes no sense because the desktop and apps will break/disallow concurrent usage. About the only thing you can do in such a second session is run a terminal, which you could do equally well with just a new tab in your current session. From jwboyer at gmail.com Tue Sep 23 17:28:51 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 23 Sep 2008 13:28:51 -0400 Subject: Plan for tomorrows (20080924) FESCO meeting In-Reply-To: <1222188670.4108.65.camel@luminos.localdomain> References: <1222186624.14583.2.camel@truman> <1222188670.4108.65.camel@luminos.localdomain> Message-ID: <20080923172851.GB14099@yoda.jdub.homelinux.org> On Tue, Sep 23, 2008 at 09:51:10AM -0700, Jesse Keating wrote: >On Tue, 2008-09-23 at 12:17 -0400, Brian Pepple wrote: >> /topic FESCo-Meeting -- F10 Schedule slip - >> https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01938.html - all > >Any chance we can get a decision on this today? And break our bureaucracy?? *Sigh* If we must.. Can you create a trac ticket for it and we can get the votes recorded there? Otherwise we could do it here, but there's less of a chance that all of FESCo will see it (maybe). I'm +1 in any case. josh From jwboyer at gmail.com Tue Sep 23 17:29:55 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Tue, 23 Sep 2008 13:29:55 -0400 Subject: Plan for tomorrows (20080924) FESCO meeting In-Reply-To: <1222186624.14583.2.camel@truman> References: <1222186624.14583.2.camel@truman> Message-ID: <20080923172955.GC14099@yoda.jdub.homelinux.org> On Tue, Sep 23, 2008 at 12:17:04PM -0400, Brian Pepple wrote: >Hi, > >Please find below the list of topics that are likely to come up in the >next FESCo meeting that is scheduled for tomorrow, Wednesday at 18:00 >UTC in #fedora-meeting on irc.freenode.org: > >/topic FESCo-Meeting -- F10 Schedule slip - >https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01938.html - all > >/topic FESCo-Meeting -- MinGW - all > >/topic FESCo meeting -- Free discussion around Fedora > >You want something to be discussed? Send a note to the list in reply to >this mail and I'll add it to the schedule. You can also propose topics >in the meeting while it is in the "Free discussion around Fedora" phase. In the last meeting minutes I noted that Kevin would like to get a status update on Codeina and have a discussion around that. Kevin, do you still want to do that? josh From jspaleta at gmail.com Tue Sep 23 17:31:43 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 23 Sep 2008 09:31:43 -0800 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222155937.3265.3.camel@hughsie-work> References: <48D542A9.1070600@leemhuis.info> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222155937.3265.3.camel@hughsie-work> Message-ID: <604aa7910809231031l792d257av950a05c84648c80b@mail.gmail.com> On Mon, Sep 22, 2008 at 11:45 PM, Richard Hughes wrote: > You think we NEED a "KDE Software Development group". PackageKit is not > designed for you. Can you explain how having fine grained groups would > help people like: http://www.packagekit.org/pk-profiles.html ? > > PackageKit is not designed for the sort of users who are comfortable > using yum on the command line. PackageKit doesn't replace yum, it's just > complimentary. If we designed PK as a "suitable for any user" tool then > it would be suitable for no-one. Hence the need for a profiles page. Can the motivating profiles for PK be extended to include situations where an instituttion is looking to create its own group definition for inhouse software for specific desktop users tasking? For example the medical school that your example medical student goes to may very well want to give its linux users a centralized way to access inhouse curriculum software utilities and may feel the best way to do that is to provide a dedicated grouping in a comps file definition in its local school package repository. Will PK grow to help those institutional users? Are you asking institutions who are running local, non-public, repositories to tell their medical student analogs to drop to the cmdline to install the inhouse software utilities via yum groupinstall, instead of exposing the institution's groupings via PK UI? The best part of comps to me, is the fact that local, non-public, institutional repositories have the flexibility to define their own groupings that best meet their situational needs.. without getting stuck in the god forsaken debate over how a particular distribution chooses to organize things. For academic institutions like medical schools, that could end up looking like curriculum or courseware groupings... grouping concepts we'd never ever need to consider in the most general case. Can anyone say that's not a valid way to make use of the flexiblity comps in an institutional setting? I can't. -jef"We can probably spend the next several months doing nothing more but nitpick how we group things in Fedora's comps. Or in fact nitpicking how anyone defines a group. I'm sure historians who focus on brick and mortar library catelog schemes will get a big kick out of it."spaleta From james at fedoraproject.org Tue Sep 23 17:37:37 2008 From: james at fedoraproject.org (James Antill) Date: Tue, 23 Sep 2008 13:37:37 -0400 Subject: No dynamic groups in PackageKit In-Reply-To: <48D923A0.4060001@leemhuis.info> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> <1222150606.30758.65.camel@code.and.org> <48D897E6.4090600@googlemail.com> <48D923A0.4060001@leemhuis.info> Message-ID: <1222191457.5506.7.camel@code.and.org> On Tue, 2008-09-23 at 19:13 +0200, Thorsten Leemhuis wrote: > Livna/RPM Fusion in the past tried to put its packages into the same > groups as Fedora did. No, groups are defined by their groupid, Livna always created searate groups (they had a different ID) ... they just named them the same. This caused problems on older yum's because on groupinstall yum would pick a single match so the other group was basically unavailable. Newer yum's find all groups that match, so there's no problem on current Fedora 9 or newer. Of course to be fair reinventing the groups concept in PK, poorly and with no input from anyone else or ability for Livna to group anything, also solves this problem. -- James Antill Fedora From debarshi.ray at gmail.com Tue Sep 23 17:40:06 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Tue, 23 Sep 2008 23:10:06 +0530 Subject: Orphan Packages: mrxvt and astyle In-Reply-To: <48D90448.3010702@ioa.s.u-tokyo.ac.jp> References: <20080923071311.85c7159e41fef2a72f1f5b5eafb9f4e5.a9a4778a43.wbe@email.secureserver.net> <3170f42f0809230734x68ee38cese3c80993e3907e2e@mail.gmail.com> <48D90448.3010702@ioa.s.u-tokyo.ac.jp> Message-ID: <3170f42f0809231040r65abbd9m5f6711d51301fdee@mail.gmail.com> >> I see that you have Mamoru Tasaka and Brian Pepple as co-maintainers. >> If and only if they are not interested, I can take care of astyle. > I would appreciate it if you would take over maintainership of > these packages, I will take 'astyle', but not the other one since I would not be able to impart the necessary attention and care to it. Thanks, Debarshi From fedora at leemhuis.info Tue Sep 23 17:52:38 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 23 Sep 2008 19:52:38 +0200 Subject: No dynamic groups in PackageKit In-Reply-To: <1222190549.4108.69.camel@luminos.localdomain> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> <1222150606.30758.65.camel@code.and.org> <48D897E6.4090600@googlemail.com> <48D923A0.4060001@leemhuis.info> <1222190549.4108.69.camel@luminos.localdomain> Message-ID: <48D92CE6.5000402@leemhuis.info> On 23.09.2008 19:22, Jesse Keating wrote: > On Tue, 2008-09-23 at 19:13 +0200, Thorsten Leemhuis wrote: >> Livna/RPM Fusion in the past tried to put its packages into the same >> groups as Fedora did. That somehow broke or confused groupinstall in yum >> iirc (never looked into the details; just heard it from skvidal and >> others) > I do believe the problem was that you used the same group names, but > different descriptions. I'm quite sure I started with the same group names. But: - maybe the Fedora names changed over time (I suppose the comps.xml I used as a start for livna might have been for FC6 or something like that) and we forgot to adjust our - we iirc hadn't imported all the translation files (are they under a free license?), which I suppose might be the root case for the problem Well, doesn't matter much now. I'm more interested in the way forward. So what would you suggest that RPM Fusion does in the future? Import the .po files from fedora to our cvs, adjust the group description and grouid in our comps files to match the ones from Fedora and make sure they stay in sync(?)? (?) the latter shouldn't be to hard to do, but nevertheless is a bit error prone over time... > If you had used the exact same > name/description/translation/etc... and /only/ changed the package > contents it would have been just fine. Just wondering and making sure I get this right: What exactly do you mean by "changed" in the latter sentence? (1) just use the same ids and description and list only the packages from RPM Fusion in the rpmfusion comps.xml files (2) import the whole comps.xml stuff from Fedora, keep it in sync and add the RPM Fusion packages I suppose you meant (1)? > [...] CU knurd P.S.: Why the heck hasn't anybody told me the above when I asked for a better way to fix the mess livna created a few months ago? From jkeating at redhat.com Tue Sep 23 17:58:20 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 23 Sep 2008 10:58:20 -0700 Subject: No dynamic groups in PackageKit In-Reply-To: <48D92CE6.5000402@leemhuis.info> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> <1222150606.30758.65.camel@code.and.org> <48D897E6.4090600@googlemail.com> <48D923A0.4060001@leemhuis.info> <1222190549.4108.69.camel@luminos.localdomain> <48D92CE6.5000402@leemhuis.info> Message-ID: <1222192700.4108.74.camel@luminos.localdomain> On Tue, 2008-09-23 at 19:52 +0200, Thorsten Leemhuis wrote: > > Just wondering and making sure I get this right: What exactly do you > mean by "changed" in the latter sentence? > > (1) just use the same ids and description and list only the packages > from RPM Fusion in the rpmfusion comps.xml files > > (2) import the whole comps.xml stuff from Fedora, keep it in sync and > add the RPM Fusion packages > > I suppose you meant (1)? I think I misspoke on the translation side, that likely doesn't matter. James gave a better description of what happened. I'd recommend using 1 if you want your packages to show up along side other Fedora packages in the same groups. I think this doesn't solve an issue where you add the Livna repo at install time in anaconda, as there may still be a bug that the group memberships don't get re-evaluated when a new repo is added, so the livna group members may not be added to the install list. That's just a bug though and could probably be fixed. > > [...] > > CU > knurd > > P.S.: Why the heck hasn't anybody told me the above when I asked for a > better way to fix the mess livna created a few months ago? I'd have to dig through IRC logs, but I'm pretty sure I stated exactly what you did in #1, along the lines of "either use the same name/description as Fedora proper does, or use your own group names". It seemed to me that livna chose the latter and the problem was "solved". -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mzerqung at 0pointer.de Tue Sep 23 17:58:26 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 19:58:26 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: References: <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> Message-ID: <20080923175826.GA4885@tango.0pointer.de> On Tue, 23.09.08 12:55, Colin Walters (walters at verbum.org) wrote: > > As far as I know we again allow multiple simultaneous X logins by the > > same user. > > If we do, it's broken. Maybe we should come to some official agreement if we do want to allow simultaneous X logins of the same user or not. In the last year or two it was always a constant forth and back whether we would want to support this or not. First people told me we should allow this, then they told me we already gave up on it, then people told me we would like to support it, now you again say we don't want it. So, what's it now? Shall we support multiple simultaneous logins by the same user on X or shall we not? I am pretty sure in GNOME allowing this is a lost cause or would mean a lot of work, but maybe some of the oh-I-have-a-gray-beard-i-like-fvwm fraction really insists on having this feature. What's the current default for gdm? > > dbus service. Besides PA only the new V4L daemon (possibly) comes to > > my mind that fall into this category. Adding such a bus for just two > > users probably doesn't make too much sense. Especially since according > > to Scott Upstart will eventually support starting per-user "singleton" > > daemons easily. > > Adding such a bus makes no sense because the desktop and apps will > break/disallow concurrent usage. About the only thing you can do in > such a second session is run a terminal, which you could do equally > well with just a new tab in your current session. Sure, I see the problem. Always did. But I wonder if the current plan is to fix all those apps, or that we already gave up on it. Anyway, for now I support multiple logins, since that is the superset of the single-login case. But nonetheless I'd be interested to know what actually is on. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From fedora at leemhuis.info Tue Sep 23 18:00:11 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 23 Sep 2008 20:00:11 +0200 Subject: No dynamic groups in PackageKit In-Reply-To: <1222191457.5506.7.camel@code.and.org> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> <1222150606.30758.65.camel@code.and.org> <48D897E6.4090600@googlemail.com> <48D923A0.4060001@leemhuis.info> <1222191457.5506.7.camel@code.and.org> Message-ID: <48D92EAB.8090901@leemhuis.info> On 23.09.2008 19:37, James Antill wrote: > On Tue, 2008-09-23 at 19:13 +0200, Thorsten Leemhuis wrote: > >> Livna/RPM Fusion in the past tried to put its packages into the same >> groups as Fedora did. > No, groups are defined by their groupid, Livna always created searate > groups (they had a different ID) ... they just named them the same. The old and unmodified comps.xml for FC6 is still available http://livna-dl.reloumirrors.net/fedora/6/i386/comps.xml The -fields back then were round about those Fedora still uses these days -- take "sound-and-video" for example; but maybe something else was from with those files...; I only changed those to be livna specific for F7 and later a few months ago on request from Fedora skvidal when the problem that was mentioned earlier showed up > [...] > Newer yum's find all groups that match, so there's no problem on > current Fedora 9 or newer. Good to know, thx. > [...] CU knurd From katzj at redhat.com Tue Sep 23 18:07:57 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 23 Sep 2008 14:07:57 -0400 Subject: No dynamic groups in PackageKit In-Reply-To: <1222192700.4108.74.camel@luminos.localdomain> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> <1222150606.30758.65.camel@code.and.org> <48D897E6.4090600@googlemail.com> <48D923A0.4060001@leemhuis.info> <1222190549.4108.69.camel@luminos.localdomain> <48D92CE6.5000402@leemhuis.info> <1222192700.4108.74.camel@luminos.localdomain> Message-ID: <1222193277.4270.0.camel@aglarond.local> On Tue, 2008-09-23 at 10:58 -0700, Jesse Keating wrote: > I think this doesn't solve an issue where you add the Livna repo at > install time in anaconda, as there may still be a bug that the group > memberships don't get re-evaluated when a new repo is added, so the > livna group members may not be added to the install list. That's just a > bug though and could probably be fixed. It actually should be fixed with a patch I have queued up for post-beta that takes care of some other oddities that now pop-up with the ability to change your base repo. It just felt a little bit too scary to drop in the day before we froze for beta Jeremy From fedora at leemhuis.info Tue Sep 23 18:15:19 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 23 Sep 2008 20:15:19 +0200 Subject: No dynamic groups in PackageKit In-Reply-To: <1222192700.4108.74.camel@luminos.localdomain> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> <1222150606.30758.65.camel@code.and.org> <48D897E6.4090600@googlemail.com> <48D923A0.4060001@leemhuis.info> <1222190549.4108.69.camel@luminos.localdomain> <48D92CE6.5000402@leemhuis.info> <1222192700.4108.74.camel@luminos.localdomain> Message-ID: <48D93237.5080101@leemhuis.info> On 23.09.2008 19:58, Jesse Keating wrote: > On Tue, 2008-09-23 at 19:52 +0200, Thorsten Leemhuis wrote: >> Just wondering and making sure I get this right: What exactly do you >> mean by "changed" in the latter sentence? >> >> (1) just use the same ids and description and list only the packages >> from RPM Fusion in the rpmfusion comps.xml files >> >> (2) import the whole comps.xml stuff from Fedora, keep it in sync and >> add the RPM Fusion packages >> >> I suppose you meant (1)? > > I think I misspoke on the translation side, that likely doesn't matter. > James gave a better description of what happened. > > I'd recommend using 1 if you want your packages to show up along side > other Fedora packages in the same groups. I'll give it a try in RPM Fusions devel branch; we can easily switch it back later if needed. > I think this doesn't solve an issue where you add the Livna repo at > install time in anaconda, as there may still be a bug that the group > memberships don't get re-evaluated when a new repo is added, so the > livna group members may not be added to the install list. That's just a > bug though and could probably be fixed. https://bugzilla.redhat.com/show_bug.cgi?id=239167 Was closed as WONTFIX :-/ So I suppose that bug is still around in anaconda. We really need to get this fixed because otherwise it's impossible to get the rpmfusion-release package automatically installed for people that enable RPM Fusion during install with anaconda. Which makes the whole idea to enable a repo during install mostly useless IMHO.... That brings me to a different question: what's the long term solution for package selection in anaconda? It's a bit odd to offer the old pirut frontend in anaconda during install and having a frontend for PK later on the installed system that looks quite different... >> P.S.: Why the heck hasn't anybody told me the above when I asked for a >> better way to fix the mess livna created a few months ago? > I'd have to dig through IRC logs, but I'm pretty sure I stated exactly > what you did in #1, along the lines of "either use the same > name/description as Fedora proper does, or use your own group names". > It seemed to me that livna chose the latter and the problem was > "solved". Someone else IIRC suggested that renaming was the better way to solve the problem, and thus that was what I did. But whatever, that is history now or will be soon, so it doesn't matter much anymore (and I don't care). CU knurd From fedora at leemhuis.info Tue Sep 23 18:19:28 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 23 Sep 2008 20:19:28 +0200 Subject: No dynamic groups in PackageKit In-Reply-To: <1222193277.4270.0.camel@aglarond.local> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> <1222150606.30758.65.camel@code.and.org> <48D897E6.4090600@googlemail.com> <48D923A0.4060001@leemhuis.info> <1222190549.4108.69.camel@luminos.localdomain> <48D92CE6.5000402@leemhuis.info> <1222192700.4108.74.camel@luminos.localdomain> <1222193277.4270.0.camel@aglarond.local> Message-ID: <48D93330.30700@leemhuis.info> On 23.09.2008 20:07, Jeremy Katz wrote: > On Tue, 2008-09-23 at 10:58 -0700, Jesse Keating wrote: >> I think this doesn't solve an issue where you add the Livna repo at >> install time in anaconda, as there may still be a bug that the group >> memberships don't get re-evaluated when a new repo is added, so the >> livna group members may not be added to the install list. That's just a >> bug though and could probably be fixed. > It actually should be fixed with a patch I have queued up for post-beta > that takes care of some other oddities that now pop-up with the ability > to change your base repo. It just felt a little bit too scary to drop > in the day before we froze for beta Thx jeremy; and I had assumed the bug in question had been forgotten. Sorry. CU knurd From lesmikesell at gmail.com Tue Sep 23 18:33:52 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 23 Sep 2008 13:33:52 -0500 Subject: Instant Mirror Status...? In-Reply-To: <1222153299.29561.7.camel@code.and.org> References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> <48D8154B.9080804@students.iiit.ac.in> <16de708d0809221650n27d4cd7djfa4b39e4ad12ff27@mail.gmail.com> <1222128026.4108.46.camel@luminos.localdomain> <16de708d0809221720r3dad221vac4cb255ccc50490@mail.gmail.com> <48D867D8.40304@gmail.com> <1222153299.29561.7.camel@code.and.org> Message-ID: <48D93690.2070902@gmail.com> James Antill wrote: > > So what you are saying essentially is: "Why can't MirrorManager decide > what the best URL is for a netblock/geoip and always list it first, just > to make the proxy problem zero-conf" > And I can guess that the answer to that is basically "Because it > doesn't work", feel free to send Matt patches though if you think > otherwise. How can it be worse than whatever you are doing now which essentially defeats any caching infrastructure that anyone has in place? That is, I don't see how any attempt at ordering the list repeatably can 'not work' or be worse than no attempt at all. What can break if you do something simple like take the list you'd return after geoip calculations (if any), divide the ip space up by the number of mirrors and rotate the list to the corresponding starting point for the source IP? You'd still be giving the same set of choices to the same recipients, but in a way that will work if they have caching in place. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Tue Sep 23 18:41:50 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 23 Sep 2008 13:41:50 -0500 Subject: Instant Mirror Status...? In-Reply-To: <20080922221540.GA15926@orient.maison.lan> References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> <20080922221540.GA15926@orient.maison.lan> Message-ID: <48D9386E.8060803@gmail.com> Emmanuel Seyman wrote: > * Gregory Maxwell [22/09/2008 20:04] : >> How would it know? > > And more importantly, if you want to always hit the same mirror, why don't > you edit its configuration to reflect that ? Here's the scenario: you have hundreds/thousands of people behind a caching proxy. They don't know each other, they don't know what OS distribution someone else is installing and the ones that happen to be installing Fedora aren't going to know what mirror someone else chose or got by accident. Likewise for the proxy - it's not going to know/care that there are a bunch of different mirrors for different stuff that an assortment of people might or might not want at the same time. -- Les Mikesell lesmikesell at gmail.com From fedora at leemhuis.info Tue Sep 23 18:46:18 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 23 Sep 2008 20:46:18 +0200 Subject: No dynamic groups in PackageKit In-Reply-To: <48D93237.5080101@leemhuis.info> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> <1222150606.30758.65.camel@code.and.org> <48D897E6.4090600@googlemail.com> <48D923A0.4060001@leemhuis.info> <1222190549.4108.69.camel@luminos.localdomain> <48D92CE6.5000402@leemhuis.info> <1222192700.4108.74.camel@luminos.localdomain> <48D93237.5080101@leemhuis.info> Message-ID: <48D9397A.2060803@leemhuis.info> On 23.09.2008 20:15, Thorsten Leemhuis wrote: > On 23.09.2008 19:58, Jesse Keating wrote: >> On Tue, 2008-09-23 at 19:52 +0200, Thorsten Leemhuis wrote: >>> Just wondering and making sure I get this right: What exactly do you >>> mean by "changed" in the latter sentence? >>> >>> (1) just use the same ids and description and list only the packages >>> from RPM Fusion in the rpmfusion comps.xml files >>> >>> (2) import the whole comps.xml stuff from Fedora, keep it in sync and >>> add the RPM Fusion packages >>> >>> I suppose you meant (1)? >> I think I misspoke on the translation side, that likely doesn't matter. >> James gave a better description of what happened. >> >> I'd recommend using 1 if you want your packages to show up along side >> other Fedora packages in the same groups. > > I'll give it a try in RPM Fusions devel branch; we can easily switch it > back later if needed. Done, but only for the "free" repo for now; new comps can be found for review in CVS for RPM Fusion: http://cvs.rpmfusion.org/viewvc/comps/comps-f10.xml.in?root=free&view=markup File is on the way to the repo and should be available at http://download1.rpmfusion.org/free/fedora/development//os/comps.xml in a few minutes. James, Jesse, does that look like it should look like? Some questions: - Should I better remove the fields "<_name>", "<_description>" "" and "" to avoid mixing up what comes from Fedora's comps.xml? - I don't define any category's; is that okay? CU knurd From skvidal at fedoraproject.org Tue Sep 23 18:52:59 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 23 Sep 2008 14:52:59 -0400 Subject: Fedora i686 Live image (Desktop) 43megs oversize... In-Reply-To: <48D9252D.9080202@redhat.com> References: <1222130156.4108.52.camel@luminos.localdomain> <48D9252D.9080202@redhat.com> Message-ID: <1222195979.4144.28.camel@rosebud> On Tue, 2008-09-23 at 13:19 -0400, Chris Snook wrote: > Jesse Keating wrote: > > Need to cut something out here. Looking deeper into it. > > I just replaced a 73 MB F9 kernel with a 15 MB rawhide kernel. If your package > manifest hasn't changed, I'd check to see if you've got one of those > incompletely stripped kernel RPMs. > You replaced an expanded installed 73MB kernel with the compressed uninstalled 15MB kernel from a repo. run: yum info installed kernel and see the size of the one you just installed. -sv From mike at miketc.net Tue Sep 23 18:56:48 2008 From: mike at miketc.net (Mike Chambers) Date: Tue, 23 Sep 2008 13:56:48 -0500 Subject: rawhide report: 20080923 changes In-Reply-To: <1222182621.7141.1.camel@scrappy.miketc.net> References: <20080923094852.683AC1F825C@releng2.fedora.phx.redhat.com> <1222182621.7141.1.camel@scrappy.miketc.net> Message-ID: <1222196208.2956.0.camel@scrappy.miketc.net> On Tue, 2008-09-23 at 10:10 -0500, Mike Chambers wrote: > On Tue, 2008-09-23 at 09:48 +0000, Rawhide Report wrote: > > > Updated Packages: > > > > anaconda-11.4.1.39-1 > > -------------------- > > * Mon Sep 22 18:00:00 2008 David Cantrell - 11.4.1.39-1 > > - Fix a traceback when getting the interface settings (#462592). (clumens) > > - self.anaconda -> anaconda (clumens) > > Is the fix above for the network config issues coming out of stage2 and > such? If it was the fix, then it failed, as I get the same network config problems as before. If not, then guess was for nothing LOL. -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From kevin at scrye.com Tue Sep 23 18:56:56 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Tue, 23 Sep 2008 12:56:56 -0600 Subject: Plan for tomorrows (20080924) FESCO meeting In-Reply-To: <20080923172955.GC14099@yoda.jdub.homelinux.org> References: <1222186624.14583.2.camel@truman> <20080923172955.GC14099@yoda.jdub.homelinux.org> Message-ID: <20080923125656.434057d5@ohm.scrye.com> On Tue, 23 Sep 2008 13:29:55 -0400 jwboyer at gmail.com (Josh Boyer) wrote: > In the last meeting minutes I noted that Kevin would like to get a > status update on Codeina and have a discussion around that. Kevin, > do you still want to do that? I would love to hear status on that. I don't know that discussing it at the meeting will have any effect unless someone can gather that status and report it to us, which they could just as well do here. ;) I think right now it's waiting on figuring out if packagekit can handle the codec installs/etc, then codiena can go away. If not, it might need to be modified to handle the new rpm provides. Does anyone have any more detailed status on that? > josh kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From kevin at scrye.com Tue Sep 23 19:04:54 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Tue, 23 Sep 2008 13:04:54 -0600 Subject: anyone interested in tpb? (was Re: No more MAKEDEV?) In-Reply-To: <31045.198.175.55.5.1222171890.squirrel@mail.jcomserv.net> References: <20080919004112.GB8478@nostromo.devel.redhat.com> <1221787714.3433.5.camel@ignacio.lan> <20080919104020.3958c1c5@ohm.scrye.com> <1221842915.5524.5.camel@hughsie-work> <1222066937.3186.18.camel@s1.crocom.com.pl> <31045.198.175.55.5.1222171890.squirrel@mail.jcomserv.net> Message-ID: <20080923130454.601ecbad@ohm.scrye.com> On Tue, 23 Sep 2008 07:11:30 -0500 (CDT) limb at jcomserv.net ("Jon Ciesla") wrote: > > > Dnia 2008-09-19, pi? o godzinie 17:48 +0100, Richard Hughes pisze: > >> On Fri, 2008-09-19 at 10:40 -0600, Kevin Fenzi wrote: > >> > Would anyone care to take over tpb? Or does anyone even use it > >> > these days? Perhaps we can just drop it? > >> ThinkPads, just like any other model, should "just work" without > >> any special daemons installed. > > > > My z61t isn't. Fn+number keys probably work (I pressed "lock" and > > screen locked), but volume and mute keys do not work. When I press > > them nothing happens - "xev" shows nothing and dmesg is silent. > > So since there it seems there is still a need for tpb, albeit > temporarily, Kevin, will you be orphaning it, or EOLing it? I think it's a bit late in the cycle to be orphaning it. How about some folks who care take it over now, and we look at orphaning it in the f11 cycle? It has two outstanding bugs: https://bugzilla.redhat.com/show_bug.cgi?id=317401 Brightness display increments too large on some displays and https://bugzilla.redhat.com/show_bug.cgi?id=441498 tpb generated coredump So, who wants it? Feel free to mail me or reply to this thread and I will release it for you. kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From lesmikesell at gmail.com Tue Sep 23 19:11:34 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 23 Sep 2008 14:11:34 -0500 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: References: <48CE65A9.8040401@poolshark.org> <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> Message-ID: <48D93F66.9040907@gmail.com> Colin Walters wrote: > >> As far as I know we again allow multiple simultaneous X logins by the >> same user. > > If we do, it's broken. Why shouldn't I be able to do as many xdm logins as I want as the same user? This isn't an X issue. -- Les Mikesell lesmikesell at gmail.com From mzerqung at 0pointer.de Tue Sep 23 19:30:26 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Tue, 23 Sep 2008 21:30:26 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <48D93F66.9040907@gmail.com> References: <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> Message-ID: <20080923193026.GA12861@tango.0pointer.de> On Tue, 23.09.08 14:11, Les Mikesell (lesmikesell at gmail.com) wrote: > > Colin Walters wrote: >>> As far as I know we again allow multiple simultaneous X logins by the >>> same user. >> If we do, it's broken. > > Why shouldn't I be able to do as many xdm logins as I want as the same > user? This isn't an X issue. Because many apps don't distuingish state from configuration cleanly. For example: you configure your gnome panel to include a clock applet. Then you open another session and add a network monitor applet to it. What do you expect from this? That both panels will always stay perfectly in sync and the network monitor applet is transparently added to the first session as well? When you log out from both, what happens when you log in again, do you get the panel layout from the first session or from the second session? Also, most WMs support multiple desktops, which is basically the same as multiple sessions. The question is: is it worth bothering at all with questions like the panel question above? Since the feature is redundant we might simply say: forget it, let's disable multiple logins and the problem is gone. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From walters at verbum.org Tue Sep 23 19:36:26 2008 From: walters at verbum.org (Colin Walters) Date: Tue, 23 Sep 2008 15:36:26 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080923193026.GA12861@tango.0pointer.de> References: <1221490775.18327.626.camel@beck.corsepiu.local> <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> <20080923193026.GA12861@tango.0pointer.de> Message-ID: On Tue, Sep 23, 2008 at 3:30 PM, Lennart Poettering wrote: > > Also, most WMs support multiple desktops, which is basically the same > as multiple sessions. No - a concrete difference is that when you click the Firefox icon with multiple desktops, you get a new window for the same Firefox process because Firefox uses the X server as a naming service. More modern applications use the DBus session bus for this purpose. There is X server per session bus per user login per user id. Breaking that model greatly increases pain for very little to no gain. From jarod at redhat.com Tue Sep 23 19:48:49 2008 From: jarod at redhat.com (Jarod Wilson) Date: Tue, 23 Sep 2008 15:48:49 -0400 Subject: Plan for tomorrows (20080924) FESCO meeting In-Reply-To: <20080923172851.GB14099@yoda.jdub.homelinux.org> References: <1222186624.14583.2.camel@truman> <1222188670.4108.65.camel@luminos.localdomain> <20080923172851.GB14099@yoda.jdub.homelinux.org> Message-ID: <48D94821.1070905@redhat.com> Josh Boyer wrote: > On Tue, Sep 23, 2008 at 09:51:10AM -0700, Jesse Keating wrote: >> On Tue, 2008-09-23 at 12:17 -0400, Brian Pepple wrote: >>> /topic FESCo-Meeting -- F10 Schedule slip - >>> https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01938.html - all >> Any chance we can get a decision on this today? > > And break our bureaucracy?? *Sigh* If we must.. Can you create a trac > ticket for it and we can get the votes recorded there? Otherwise we could > do it here, but there's less of a chance that all of FESCo will see it (maybe). > > I'm +1 in any case. Bureaucracy be damned! +1 Oh wait, I think I just damned myself, didn't I?... -- Jarod Wilson jarod at redhat.com From cweyl at alumni.drew.edu Tue Sep 23 19:54:31 2008 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Tue, 23 Sep 2008 12:54:31 -0700 Subject: mass acl opening? In-Reply-To: <48CA7B48.7060207@gmail.com> References: <7dd7ab490809102229y51412a3cwe37daeb520bf0a7c@mail.gmail.com> <48C8B476.8040108@ioa.s.u-tokyo.ac.jp> <48C92AED.1000501@gmail.com> <48C92FFD.30905@redhat.com> <48CA7B48.7060207@gmail.com> Message-ID: <7dd7ab490809231254w7811751bgad4990db06071097@mail.gmail.com> 2008/9/12 Toshio Kuratomi : > Casey Dahlin wrote: >> I'm good with going ahead asap. >> [...snip...] > That means, I'll deploy this on our new staging infrastructure and push > it live the middle to later part of next week. Gentle, friendly "where are we?" I know there are more important things going on. -Chris -- Chris Weyl Ex astris, scientia From kevin at scrye.com Tue Sep 23 20:24:04 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Tue, 23 Sep 2008 14:24:04 -0600 Subject: Plan for tomorrows (20080924) FESCO meeting In-Reply-To: <48D94821.1070905@redhat.com> References: <1222186624.14583.2.camel@truman> <1222188670.4108.65.camel@luminos.localdomain> <20080923172851.GB14099@yoda.jdub.homelinux.org> <48D94821.1070905@redhat.com> Message-ID: <20080923142404.3a08d3a4@ohm.scrye.com> On Tue, 23 Sep 2008 15:48:49 -0400 jarod at redhat.com (Jarod Wilson) wrote: > Josh Boyer wrote: > > On Tue, Sep 23, 2008 at 09:51:10AM -0700, Jesse Keating wrote: > >> On Tue, 2008-09-23 at 12:17 -0400, Brian Pepple wrote: > >>> /topic FESCo-Meeting -- F10 Schedule slip - > >>> https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01938.html > >>> - all > >> Any chance we can get a decision on this today? > > > > And break our bureaucracy?? *Sigh* If we must.. Can you create a > > trac ticket for it and we can get the votes recorded there? > > Otherwise we could do it here, but there's less of a chance that > > all of FESCo will see it (maybe). > > > > I'm +1 in any case. > > Bureaucracy be damned! > > +1 > > Oh wait, I think I just damned myself, didn't I?... +1 here. (Might as well be dammed too). kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From lesmikesell at gmail.com Tue Sep 23 20:25:31 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 23 Sep 2008 15:25:31 -0500 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080923130529.GH7596@tango.0pointer.de> References: <48CE7406.1010409@odu.neva.ru> <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <20080922180001.GA8379@sonata.rednote.net> <20080923001815.GE21642@tango.0pointer.de> <48D85D71.4020503@gmail.com> <20080923130529.GH7596@tango.0pointer.de> Message-ID: <48D950BB.3030103@gmail.com> Lennart Poettering wrote: > >>> And it's not just we who fixed >>> this hole like this. Apple for example does it too. And usually Apple >>> is the gold standard of user-friendliness, right? >> No, it sucks just as much when itunes does it. You expect that kind of >> stuff from Apple who only has a short history of multi-user machines and >> who would really rather sell you an apple tv or ipod with dock that you can >> dedicate to driving your speakers, though. Linux has always been multi-user >> and doesn't have any such excuses for arbitrarily disconnecting >> devices. > > "arbitrarily"? Arbitrarily, as in guessing who should have exclusive access based on nothing that particularly relates to the specific audio device. It is no more right than automatically killing scheduled tape backups would be because someone else logged in on a keyboard near the tape device. > Oh man. Claiming that things are right because Linux always did it > this way is not very convincing. Linux what? The kernel doesn't make arbitrary access decisions by itself, does it? > You never noticed that quite a few > things in Linux haven't been all that shiny right from day 0? Some > things got fixed by now, and this is just another instance. Fixed - so the same machine doing audio output can't be used for anything else? >>> Allowing multiple different users audio device access at the same is a >>> security nightmare. It has been with ALSA dmix. And it is even more so >>> in PA. >> Doesn't the kernel have a mechanism for exclusive locks on devices if >> someone wants to have exclusive access? It's not all that difficult to >> eavesdrop on music playing loudly anyway... > > Access to audio devices (both OSS and ALSA) is exclusive by default anyway. Exclusive access is OK. Killing that access based on unrelated circumstances isn't. >> What's the right way to set up a media player service that isn't attached >> to anyone's session? > > You can bypass PA if you wish. Or run a specific tailored PA > instance for it. It's up to you. I meant in Fedora. -- Les Mikesell lesmikesell at gmail.com From loupgaroublond at gmail.com Tue Sep 23 20:36:35 2008 From: loupgaroublond at gmail.com (Yaakov Nemoy) Date: Tue, 23 Sep 2008 16:36:35 -0400 Subject: Debugging pulseaudio when autostarted by gnome or kde Message-ID: <7f692fec0809231336h66277cb0v7b8958566aa8997b@mail.gmail.com> Hi List, I'm having some troubles lately with Pulesaudio, where my music is constantly cracking (pausing for a few milliseconds), and then pulseaudio going down in flames, with a noticeable click on the soundcard when it does. While I can start pulseaudio back up, not all programs can use it properly. For example, once I start playing music with exaile (which uses gstreamer, for the record), exaile works fine, but flash and other apps cannot access either the sound card or pulseaudio anymore. Sometimes pulseaudio goes down in flames randomly after a fresh login/reboot, and sometimes it waits until I put my laptop in standby. When I bring it back up, it's crashed about 50% of the time, even from a new instance that I start in my session. I understand that Pulseaudio is started when gnome-session tries to start up esd. Aside from the bizareness of this, how can I debug PA when it's started up like this? I know there's a -vv option, but I can't imagine the best way to get PA to use that, and then where would I find the output from it? Cheers, Yaakov From fedoraproject at cyberpear.com Tue Sep 23 20:39:02 2008 From: fedoraproject at cyberpear.com (James Cassell) Date: Tue, 23 Sep 2008 16:39:02 -0400 Subject: Instant Mirror Status...? In-Reply-To: <48D93690.2070902@gmail.com> References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> <48D8154B.9080804@students.iiit.ac.in> <16de708d0809221650n27d4cd7djfa4b39e4ad12ff27@mail.gmail.com> <1222128026.4108.46.camel@luminos.localdomain> <16de708d0809221720r3dad221vac4cb255ccc50490@mail.gmail.com> <48D867D8.40304@gmail.com> <1222153299.29561.7.camel@code.and.org> <48D93690.2070902@gmail.com> Message-ID: Maybe I'm not seeing the entire problem, but couldn't you just cache the response from mirrormanager, in addition to caching the packages? Wouldn't everyone then get the same list, and by default, choose the first (and thus the same) mirror in the list? -- James Cassell On Tue, 23 Sep 2008 14:33:52 -0400, Les Mikesell wrote: > James Antill wrote: >> So what you are saying essentially is: "Why can't MirrorManager decide >> what the best URL is for a netblock/geoip and always list it first, just >> to make the proxy problem zero-conf" >> And I can guess that the answer to that is basically "Because it >> doesn't work", feel free to send Matt patches though if you think >> otherwise. > > How can it be worse than whatever you are doing now which essentially > defeats any caching infrastructure that anyone has in place? That is, I > don't see how any attempt at ordering the list repeatably can 'not work' > or be worse than no attempt at all. What can break if you do something > simple like take the list you'd return after geoip calculations (if > any), divide the ip space up by the number of mirrors and rotate the > list to the corresponding starting point for the source IP? You'd still > be giving the same set of choices to the same recipients, but in a way > that will work if they have caching in place. > From aoliva at redhat.com Tue Sep 23 20:39:35 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Tue, 23 Sep 2008 17:39:35 -0300 Subject: Fedora not "free" enough for GNU? In-Reply-To: <1222183984.15981.410.camel@atropine.boston.devel.redhat.com> (Adam Jackson's message of "Tue\, 23 Sep 2008 11\:33\:04 -0400") References: <8553.1220772699@sss.pgh.pa.us> <200809071523.44582.ben.kreuter@gmail.com> <604aa7910809071240u1923df65i8861e58de856540b@mail.gmail.com> <604aa7910809211144s77460d18se7d6620518c4db56@mail.gmail.com> <80d7e4090809211419p78edad66k18a297ab151e0b25@mail.gmail.com> <1222111167.15981.358.camel@atropine.boston.devel.redhat.com> <1222183984.15981.410.camel@atropine.boston.devel.redhat.com> Message-ID: On Sep 23, 2008, Adam Jackson wrote: > On Mon, 2008-09-22 at 17:32 -0300, Alexandre Oliva wrote: >> On Sep 22, 2008, Adam Jackson wrote: >> > a problem that is not universally agreed to be a problem at all. >> in spite of Fedora's stated goals. > Only if you think firmware is 100% software and 100% not content. This > is far from being an obvious or trivial distinction. I agree the distinction is not trivial. But I've never had qualms about firmware. My issue is against non-Free Software. That's why I say that moving all firmware out of the kernel, regardless of whether it's software, regardless of whether it's Free, is a different problem. >> Erhm... Are you sure aic7xxx was built with any expectation of >> loading firmware through the standard firmware-loading interface, >> rather than of having it built right into the kernel image? > It appears to not use request_firmware(), correct. > But that's sort of the point. kernel-libre makes no attempt to fix > those drivers to use the firmware loader, afaict. Why should it? Its goal is not to get all drivers to use firmware loaders. AFAICT from the deblob script, aic7xxx is one that has Free firmware, so it's not even stripped off. What's the concern? > Without that, stripping firmware from disk drivers (and network > drivers, for that matter) is explicitly saying that some people's > machines are worth sacrificing in the name of firmware purity. It just means they (or you) might have to build those modules with firmware on their (or your) own *if* they're willing to sacrifice their freedom, nothing but it. Meanwhile, most users would know what they're getting. > Given that firmware purity is not universally accepted to be a problem > worth solving, kernel-libre as it stands is not going to be universally > accepted as a solution worth adopting. You evidently misunderstand the purpose of kernel-libre. > Now you've expressed your distaste for converting such drivers to > the firmware loader before [...] It's also the primary functional > reason (as far as I can tell) that kernel-libre is not something > Fedora can consume. My distaste didn't stop others from doing just that, so at this point it's a non-issue, as pointed out upthread. > Are you more interested in having produced a libre kernel package, or in > having users run it? I'm interested in users' freedom. I worked to offer an option, and I work to spread it. I hope it keeps on getting more users. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From email.ahmedkamal at googlemail.com Tue Sep 23 20:48:57 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Tue, 23 Sep 2008 23:48:57 +0300 Subject: Debugging pulseaudio when autostarted by gnome or kde In-Reply-To: <7f692fec0809231336h66277cb0v7b8958566aa8997b@mail.gmail.com> References: <7f692fec0809231336h66277cb0v7b8958566aa8997b@mail.gmail.com> Message-ID: <3da3b5b40809231348w50ceab16l58334f6bbfbce4d5@mail.gmail.com> Yes, the dies in flames after wakeup from suspend happens to me too, very often. And I use KDE. Should there be an autostart mechanism ?!Also, why is it that after I restart PA, the apps still can't use it, and I have to restart the apps. This one really sucks. On Tue, Sep 23, 2008 at 11:36 PM, Yaakov Nemoy wrote: > Hi List, > > I'm having some troubles lately with Pulesaudio, where my music is > constantly cracking (pausing for a few milliseconds), and then > pulseaudio going down in flames, with a noticeable click on the > soundcard when it does. While I can start pulseaudio back up, not all > programs can use it properly. For example, once I start playing music > with exaile (which uses gstreamer, for the record), exaile works fine, > but flash and other apps cannot access either the sound card or > pulseaudio anymore. > > Sometimes pulseaudio goes down in flames randomly after a fresh > login/reboot, and sometimes it waits until I put my laptop in standby. > When I bring it back up, it's crashed about 50% of the time, even > from a new instance that I start in my session. > > I understand that Pulseaudio is started when gnome-session tries to > start up esd. Aside from the bizareness of this, how can I debug PA > when it's started up like this? I know there's a -vv option, but I > can't imagine the best way to get PA to use that, and then where would > I find the output from it? > > Cheers, > Yaakov > > -- > 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 lesmikesell at gmail.com Tue Sep 23 20:50:29 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 23 Sep 2008 15:50:29 -0500 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080923193026.GA12861@tango.0pointer.de> References: <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> <20080923193026.GA12861@tango.0pointer.de> Message-ID: <48D95695.1050108@gmail.com> Lennart Poettering wrote: > On Tue, 23.09.08 14:11, Les Mikesell (lesmikesell at gmail.com) wrote: > >> Colin Walters wrote: >>>> As far as I know we again allow multiple simultaneous X logins by the >>>> same user. >>> If we do, it's broken. >> Why shouldn't I be able to do as many xdm logins as I want as the same >> user? This isn't an X issue. > > Because many apps don't distuingish state from configuration cleanly. So you'd cripple the system because there are some bad apps? > For example: you configure your gnome panel to include a clock > applet. Then you open another session and add a network monitor applet > to it. What do you expect from this? That both panels will always stay > perfectly in sync and the network monitor applet is transparently > added to the first session as well? When you log out from both, what > happens when you log in again, do you get the panel layout from the > first session or from the second session? How is this different than running 2 instances of vi? If you edit the same file at the same time you'll have a conflict. That doesn't mean you should cripple the system to the point where it can't run 2 instances of vi. > Also, most WMs support multiple desktops, which is basically the same > as multiple sessions. Except I want my other logins to be from other places. Like one on the console, one freenx/NX'd and floating, others xdm'd, perhaps Xnested. Mostly I don't want to need to know the status of any of the other desktops when I start a new one. I could probably live with one floating freenx if it could float on and off the console and always resize to match the NX client, but those don't seem to work right. > The question is: is it worth bothering at all with questions like the > panel question above? Since the feature is redundant we might simply > say: forget it, let's disable multiple logins and the problem is > gone. Windows terminal services has gotten this more or less right since at least windows 2000 server that included 2 licenses for administrative use. If they can do it with an interface that wasn't designed to be remote or multiuser, it can't be that hard. But, if it can't be done right, the WM should enforce it and give you a choice of killing the old session when you attempt a new login instead of just letting random things fail. -- Les Mikesell lesmikesell at gmail.com From mclasen at redhat.com Tue Sep 23 20:57:09 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Tue, 23 Sep 2008 16:57:09 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <48D95695.1050108@gmail.com> References: <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> <20080923193026.GA12861@tango.0pointer.de> <48D95695.1050108@gmail.com> Message-ID: <1222203429.4803.3.camel@localhost.localdomain> On Tue, 2008-09-23 at 15:50 -0500, Les Mikesell wrote: > But, if it can't be done right, the WM should enforce it and give you a > choice of killing the old session when you attempt a new login instead > of just letting random things fail. Have you actually tried it in F9 or F10 ? gdm doesn't let you log in multiple times, it brings you back to your old session if you try. From notting at redhat.com Tue Sep 23 20:59:03 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 23 Sep 2008 16:59:03 -0400 Subject: specspo and PackageKit In-Reply-To: <1222178729.4144.6.camel@rosebud> References: <1222160979.3265.37.camel@hughsie-work> <1222177596.3920.1.camel@localhost.localdomain> <1222178729.4144.6.camel@rosebud> Message-ID: <20080923205903.GA22595@nostromo.devel.redhat.com> seth vidal (skvidal at fedoraproject.org) said: > for example - translating pkgs might best be served by translating the > metadata in external files. Isn't that just moving the source of the large bloat and translation from one point to another? What does it gain you? Bill From notting at redhat.com Tue Sep 23 21:01:24 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 23 Sep 2008 17:01:24 -0400 Subject: Plan for tomorrows (20080924) FESCO meeting In-Reply-To: <1222188670.4108.65.camel@luminos.localdomain> References: <1222186624.14583.2.camel@truman> <1222188670.4108.65.camel@luminos.localdomain> Message-ID: <20080923210124.GB22595@nostromo.devel.redhat.com> Jesse Keating (jkeating at redhat.com) said: > On Tue, 2008-09-23 at 12:17 -0400, Brian Pepple wrote: > > /topic FESCo-Meeting -- F10 Schedule slip - > > https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01938html - all > > Any chance we can get a decision on this today? +1 from me. Bill From skvidal at fedoraproject.org Tue Sep 23 21:05:43 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Tue, 23 Sep 2008 17:05:43 -0400 Subject: specspo and PackageKit In-Reply-To: <20080923205903.GA22595@nostromo.devel.redhat.com> References: <1222160979.3265.37.camel@hughsie-work> <1222177596.3920.1.camel@localhost.localdomain> <1222178729.4144.6.camel@rosebud> <20080923205903.GA22595@nostromo.devel.redhat.com> Message-ID: <1222203943.4144.42.camel@rosebud> On Tue, 2008-09-23 at 16:59 -0400, Bill Nottingham wrote: > seth vidal (skvidal at fedoraproject.org) said: > > for example - translating pkgs might best be served by translating the > > metadata in external files. > > Isn't that just moving the source of the large bloat and translation from > one point to another? What does it gain you? not having them in @base for everyone, and for EVERY language - even if you're not speaking any of them. so then we could have the lang things separate per lang in the metadata 'oh look, you're in russian, grab the russian translations, too' not 'oh look, you're using en_US, go grab EVERY DAMN LANGUAGE' right? -sv From walters at verbum.org Tue Sep 23 21:03:24 2008 From: walters at verbum.org (Colin Walters) Date: Tue, 23 Sep 2008 17:03:24 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <48D95695.1050108@gmail.com> References: <1221490775.18327.626.camel@beck.corsepiu.local> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> <20080923193026.GA12861@tango.0pointer.de> <48D95695.1050108@gmail.com> Message-ID: On Tue, Sep 23, 2008 at 4:50 PM, Les Mikesell wrote: > > Except I want my other logins to be from other places. Like one on the > console, one freenx/NX'd and floating, others xdm'd, perhaps Xnested. There are two answers on remote login: 1) Unix shell over ssh - we're not breaking this, but it is what it is 2) Access currently logged in desktop over VNC/your-protocol-here via vino Ideally vino would also allow you to dynamically enable remote new logins over GDM/XDMCP though policykit. But Xnest and console are broken and should not be supported except as debugging/development tools. From notting at redhat.com Tue Sep 23 21:20:45 2008 From: notting at redhat.com (Bill Nottingham) Date: Tue, 23 Sep 2008 17:20:45 -0400 Subject: specspo and PackageKit In-Reply-To: <1222203943.4144.42.camel@rosebud> References: <1222160979.3265.37.camel@hughsie-work> <1222177596.3920.1.camel@localhost.localdomain> <1222178729.4144.6.camel@rosebud> <20080923205903.GA22595@nostromo.devel.redhat.com> <1222203943.4144.42.camel@rosebud> Message-ID: <20080923212045.GC22595@nostromo.devel.redhat.com> seth vidal (skvidal at fedoraproject.org) said: > On Tue, 2008-09-23 at 16:59 -0400, Bill Nottingham wrote: > > seth vidal (skvidal at fedoraproject.org) said: > > > for example - translating pkgs might best be served by translating the > > > metadata in external files. > > > > Isn't that just moving the source of the large bloat and translation from > > one point to another? What does it gain you? > > not having them in @base for everyone, and for EVERY language - even if > you're not speaking any of them. > > so then we could have the lang things separate per lang in the metadata > > 'oh look, you're in russian, grab the russian translations, too' > > not > 'oh look, you're using en_US, go grab EVERY DAMN LANGUAGE' I'm just trying to comprehend how we'd generate this information for the repodata in any sort of sane manner, and failing miserably. You'd need to have every run of createrepo check out some source controlled translation directory, and munge it with intltool (aiyeeeeeeeee) into a separate translated XML file. Bill From a.badger at gmail.com Tue Sep 23 21:49:28 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Tue, 23 Sep 2008 14:49:28 -0700 Subject: mass acl opening? In-Reply-To: <7dd7ab490809231254w7811751bgad4990db06071097@mail.gmail.com> References: <7dd7ab490809102229y51412a3cwe37daeb520bf0a7c@mail.gmail.com> <48C8B476.8040108@ioa.s.u-tokyo.ac.jp> <48C92AED.1000501@gmail.com> <48C92FFD.30905@redhat.com> <48CA7B48.7060207@gmail.com> <7dd7ab490809231254w7811751bgad4990db06071097@mail.gmail.com> Message-ID: <48D96468.1040301@gmail.com> Chris Weyl wrote: > 2008/9/12 Toshio Kuratomi : >> Casey Dahlin wrote: >>> I'm good with going ahead asap. >>> > [...snip...] >> That means, I'll deploy this on our new staging infrastructure and push >> it live the middle to later part of next week. > > Gentle, friendly "where are we?" I know there are more important > things going on. > Beta's slip means that the infrastructure freeze is extended as well. So we're still waiting in the wings. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From lesmikesell at gmail.com Tue Sep 23 22:34:37 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 23 Sep 2008 17:34:37 -0500 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: References: <1221490775.18327.626.camel@beck.corsepiu.local> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> <20080923193026.GA12861@tango.0pointer.de> <48D95695.1050108@gmail.com> Message-ID: <48D96EFD.2010900@gmail.com> Colin Walters wrote: > On Tue, Sep 23, 2008 at 4:50 PM, Les Mikesell wrote: >> Except I want my other logins to be from other places. Like one on the >> console, one freenx/NX'd and floating, others xdm'd, perhaps Xnested. > > There are two answers on remote login: > > 1) Unix shell over ssh - we're not breaking this, but it is what it is > 2) Access currently logged in desktop over VNC/your-protocol-here via vino freenx/NX is much, much nicer for remote access than vnc. Nice enough to give up logging in directly on the console at all if that won't mesh and you do anything from other locations. > Ideally vino would also allow you to dynamically enable remote new > logins over GDM/XDMCP though policykit. I'd settle for yanking the running session to my new login location if the desktop resized appropriately. I think vino/vnc's goal is controlling remote session with the concept that there really are 2 copies of the session. I want to have a remote session that is not necessarily a copy of another one running somewhere else. I realize that freenx does in fact have a copy of the session tucked away somewhere but it's not intrusive, doesn't tie up a physical console, and isn't restricted to one user/session at a time on a machine. It is a better fit for long-running sessions and mobile users than vino/vnc where you have to start the session from a fixed console and subsequently tie it up - and leave it open to intrusion, even when you aren't there. > But Xnest and console are broken and should not be supported except as > debugging/development tools. I think of Xnest as a test like a compiler being able to compile itself. If it doesn't work, there is something inherently wrong. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Tue Sep 23 22:37:44 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 23 Sep 2008 17:37:44 -0500 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <1222203429.4803.3.camel@localhost.localdomain> References: <1221490775.18327.626.camel@beck.corsepiu.local> <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> <20080923193026.GA12861@tango.0pointer.de> <48D95695.1050108@gmail.com> <1222203429.4803.3.camel@localhost.localdomain> Message-ID: <48D96FB8.6040205@gmail.com> Matthias Clasen wrote: > >> But, if it can't be done right, the WM should enforce it and give you a >> choice of killing the old session when you attempt a new login instead >> of just letting random things fail. > > Have you actually tried it in F9 or F10 ? gdm doesn't let you log in > multiple times, it brings you back to your old session if you try. No I haven't. What does 'bring you back to your old session' mean when your subsequent login is remote - or both were? -- Les Mikesell lesmikesell at gmail.com From airlied at redhat.com Tue Sep 23 22:45:00 2008 From: airlied at redhat.com (Dave Airlie) Date: Wed, 24 Sep 2008 08:45:00 +1000 Subject: Possible Major bug in X.org update In-Reply-To: <1221984003.9766.10.camel@rousalka.okg> References: <20080921071558.GA7350@emu> <1221984003.9766.10.camel@rousalka.okg> Message-ID: <1222209901.3504.0.camel@clockmaker.usersys.redhat.com> On Sun, 2008-09-21 at 10:00 +0200, Nicolas Mailhot wrote: > Le dimanche 21 septembre 2008 ? 16:45 +0930, Peter Hutterer a ?crit : > > On Fri, Sep 19, 2008 at 08:43:15PM -0400, Mark Bidewell wrote: > > > I just updated my F9 system and when I restarted my box, my USB > > > keyboard will not work. It works under console mode and my USB mouse > > > continues to work. This is a major issue (for me at least) due to the > > > fact that I have no PS/2 ports and this makes Fedora unusable. > > > Mark Bidewell > > > > The update to 1.5.0 pulled in an upstream change to input driver loading when > > no xorg is present or incomplete ServerLayouts are given. As a result, the kbd > > driver is not loaded automatically if no xorg.conf is present. This combines > > with the F9 patch to disable evdev keyboards - resulting in no keyboard being > > available. > > So what? the F9 patch to disable evdev keyboards already resulted in no > keyboards on some systems, latest upstream change only made this result > more common. > > > As said before, xorg-x11-server-1.5.0-2.fc9 reverts the upstream change and > > kbd is now loaded automatically unless explicitly specified otherwise. > > I hope that someday we'll stop working at cross-purposes with upstream > on input (given that Fedora derivatives like OLPC already use evdev) > You do know that upstream X.org has two major input contributors, and Peter is one? I'm not sure how can be working at cross-purposes with ourselves.. Dave. From bpepple at fedoraproject.org Tue Sep 23 22:49:04 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 23 Sep 2008 18:49:04 -0400 Subject: Plan for tomorrows (20080924) FESCO meeting In-Reply-To: <20080923210124.GB22595@nostromo.devel.redhat.com> References: <1222186624.14583.2.camel@truman> <1222188670.4108.65.camel@luminos.localdomain> <20080923210124.GB22595@nostromo.devel.redhat.com> Message-ID: <1222210144.16171.2.camel@kennedy> On Tue, 2008-09-23 at 17:01 -0400, Bill Nottingham wrote: > Jesse Keating (jkeating at redhat.com) said: > > On Tue, 2008-09-23 at 12:17 -0400, Brian Pepple wrote: > > > /topic FESCo-Meeting -- F10 Schedule slip - > > > https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01938html - all > > > > Any chance we can get a decision on this today? > > +1 from me. +1 here also. Jesse, since more than half of FESCo has voted in favor of the schedule change, consider it approved. Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From laxathom at fedoraproject.org Tue Sep 23 22:53:27 2008 From: laxathom at fedoraproject.org (Xavier Lamien) Date: Wed, 24 Sep 2008 00:53:27 +0200 Subject: Summary of the 2008-09-23 Packaging Committee Meeting Message-ID: <62bc09df0809231553v7cab7a5dw3da036b30de99b12@mail.gmail.com> Hello folks, The meeting minutes and the full logs of the 2008-09-23 packaging committee meeting will be online at --> http://fedoraproject.org/wiki/Packaging/Minutes/20080923 == Summary == The Packaging Committee board approved the following drafts : * Packaging Guideline for Unowned Directories : https://fedoraproject.org/wiki/PackagingDrafts/UnownedDirectories * Packaging guideline for MinGW (with specific exception, check out irc log for details): https://fedoraproject.org/wiki/PackagingDrafts/MinGW * Package guideline for Javascript https://fedoraproject.org/wiki/PackagingDrafts/JavaScript --------- * Discussed on python provides|requires package (egg-info related): https://fedoraproject.org/wiki/PackagingDrafts/Python -- Xavier.t Lamien -- http://fedoraproject.org/wiki/XavierLamien GPG-Key ID: F3903DEB From mzerqung at 0pointer.de Tue Sep 23 23:13:12 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 24 Sep 2008 01:13:12 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <48D950BB.3030103@gmail.com> References: <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <20080922180001.GA8379@sonata.rednote.net> <20080923001815.GE21642@tango.0pointer.de> <48D85D71.4020503@gmail.com> <20080923130529.GH7596@tango.0pointer.de> <48D950BB.3030103@gmail.com> Message-ID: <20080923231312.GA338@tango.0pointer.de> On Tue, 23.09.08 15:25, Les Mikesell (lesmikesell at gmail.com) wrote: >>> No, it sucks just as much when itunes does it. You expect that kind of >>> stuff from Apple who only has a short history of multi-user machines and >>> who would really rather sell you an apple tv or ipod with dock that you >>> can dedicate to driving your speakers, though. Linux has always been >>> multi-user and doesn't have any such excuses for arbitrarily >>> disconnecting >>> devices. >> "arbitrarily"? > > Arbitrarily, as in guessing who should have exclusive access based on > nothing that particularly relates to the specific audio device. It is no > more right than automatically killing scheduled tape backups would be > because someone else logged in on a keyboard near the tape device. We generally consider speakers/mikes/headphones to be part of the workplace of the user, i.e. together with mouse/keyboard/screen we switch them over when the active session changes. And again, that's the way *I* think it makes the most sense. Of course, you are free to consider audio to be hw that is completely detached from sessions. I disagree. Most of the RH engineers I talked to about this agree with how *I* see things. (And Apple too, ...) Nonetheless, I do see some sense in the way you want to use the audio devices. However, I don't think that would be the normal use-case, and I also don't think that defaulting to this insecure configuration would be a good choice. So, let's end this discussion right now. I did acknowledge the validity of your usecase, although I priorize a different one. Supporting your preferred way of doing session switching for audio is on my TODO list (although way at the end). That's the most you will get from me. If you disagrees with my priorities, then bad luck, you won't be able to change them. BTW, Free Software is about scratching your own itches. Apparently this functionality is very important to you, otherwise we wouldn't have this discussion again and again and again. Hence: I AM HAPPY TO MERGE YOUR PATCHES (if they are good)! >> Oh man. Claiming that things are right because Linux always did it >> this way is not very convincing. > > Linux what? The kernel doesn't make arbitrary access decisions by itself, > does it? Oh man, stop it. Those decisions are not arbitrary. They make sense. (Except maybe for you) >>> Doesn't the kernel have a mechanism for exclusive locks on devices if >>> someone wants to have exclusive access? It's not all that difficult to >>> eavesdrop on music playing loudly anyway... >> Access to audio devices (both OSS and ALSA) is exclusive by default >> anyway. > > Exclusive access is OK. Killing that access based on unrelated > circumstances isn't. We don't "kill" access. We suspend access until you reactivate your session. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Tue Sep 23 23:15:13 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 24 Sep 2008 01:15:13 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <1222203429.4803.3.camel@localhost.localdomain> References: <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> <20080923193026.GA12861@tango.0pointer.de> <48D95695.1050108@gmail.com> <1222203429.4803.3.camel@localhost.localdomain> Message-ID: <20080923231513.GB338@tango.0pointer.de> On Tue, 23.09.08 16:57, Matthias Clasen (mclasen at redhat.com) wrote: > > But, if it can't be done right, the WM should enforce it and give you a > > choice of killing the old session when you attempt a new login instead > > of just letting random things fail. > > Have you actually tried it in F9 or F10 ? gdm doesn't let you log in > multiple times, it brings you back to your old session if you try. Just wondering, do the other dm's do that too? As it appears I have to support KDE/... with PA, too. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From mzerqung at 0pointer.de Tue Sep 23 23:34:49 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 24 Sep 2008 01:34:49 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <48D95695.1050108@gmail.com> References: <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> <20080923193026.GA12861@tango.0pointer.de> <48D95695.1050108@gmail.com> Message-ID: <20080923233449.GA2076@tango.0pointer.de> On Tue, 23.09.08 15:50, Les Mikesell (lesmikesell at gmail.com) wrote: >>>>> As far as I know we again allow multiple simultaneous X logins by the >>>>> same user. >>>> If we do, it's broken. >>> Why shouldn't I be able to do as many xdm logins as I want as the same >>> user? This isn't an X issue. >> Because many apps don't distuingish state from configuration cleanly. > > So you'd cripple the system because there are some bad apps? Oh my, Lennart cripples computers. I should be banned. Just like DRM! >> For example: you configure your gnome panel to include a clock >> applet. Then you open another session and add a network monitor applet >> to it. What do you expect from this? That both panels will always stay >> perfectly in sync and the network monitor applet is transparently >> added to the first session as well? When you log out from both, what >> happens when you log in again, do you get the panel layout from the >> first session or from the second session? > > How is this different than running 2 instances of vi? If you edit the same > file at the same time you'll have a conflict. That doesn't mean you should > cripple the system to the point where it can't run 2 instances of > vi. vi has static config files. They are only read on vi's startup. OTOH GNOME usually does instant-apply. I.e. what you configure is immediately executed and saved for later. You did not respond to my question what you'd think the proper behaviour would be for gnome-panel. I'll take that as an acknowledgment that you understand that the problem exists. >> The question is: is it worth bothering at all with questions like the >> panel question above? Since the feature is redundant we might simply >> say: forget it, let's disable multiple logins and the problem is >> gone. > > Windows terminal services has gotten this more or less right since at least > windows 2000 server that included 2 licenses for administrative use. If > they can do it with an interface that wasn't designed to be remote or > multiuser, it can't be that hard. Are you sure you can log in twice on Win2k as exactly the same user id? > But, if it can't be done right, the WM should enforce it and give you a > choice of killing the old session when you attempt a new login instead of > just letting random things fail. Nah, if at all that's the job of the dm or the sm, not the wm. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From jspaleta at gmail.com Tue Sep 23 23:54:58 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 23 Sep 2008 15:54:58 -0800 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: References: <1221490775.18327.626.camel@beck.corsepiu.local> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> <20080923193026.GA12861@tango.0pointer.de> <48D95695.1050108@gmail.com> Message-ID: <604aa7910809231654x5b33793jbc9fff02f09efa6f@mail.gmail.com> On Tue, Sep 23, 2008 at 1:03 PM, Colin Walters wrote: > 1) Unix shell over ssh - we're not breaking this, but it is what it is > 2) Access currently logged in desktop over VNC/your-protocol-here via vino Correct me if I'm wrong. Does remote vnc access via vino wake up the locally locked display still in F10? Is that okay from a security perspective? I don't know how to reconcile the security arguments being made for pulseaudio with regard to disabling streams on console switching, with the fact that our default remote desktop implementation as implemented by vino wakes up the local console screen, even if its a locked session, if you connect remotely to the desktop in F9. I feel there's a disconnect here as to what a secure desktop experience is suppose to be. -jef"the disconnect could just be in my head"spaleta From halfline at gmail.com Wed Sep 24 00:37:13 2008 From: halfline at gmail.com (Ray Strode) Date: Tue, 23 Sep 2008 20:37:13 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <604aa7910809231654x5b33793jbc9fff02f09efa6f@mail.gmail.com> References: <1221490775.18327.626.camel@beck.corsepiu.local> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> <20080923193026.GA12861@tango.0pointer.de> <48D95695.1050108@gmail.com> <604aa7910809231654x5b33793jbc9fff02f09efa6f@mail.gmail.com> Message-ID: <45abe7d80809231737j5abee721g644af81a32c8552c@mail.gmail.com> Hi, On Tue, Sep 23, 2008 at 7:54 PM, Jeff Spaleta wrote: > Correct me if I'm wrong. Does remote vnc access via vino wake up the > locally locked display still in F10? You're not wrong, and it's not the desired behavior: http://bugzilla.gnome.org/show_bug.cgi?id=311780 Just hard to fix and no one has spent time doing it yet. --Ray From mw_triad at users.sourceforge.net Wed Sep 24 00:38:09 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 23 Sep 2008 19:38:09 -0500 Subject: multiple local X logins by same user (was: Tried Pulse Audio Again--No Good For A11y) In-Reply-To: <20080923233449.GA2076@tango.0pointer.de> References: <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> <20080923193026.GA12861@tango.0pointer.de> <48D95695.1050108@gmail.com> <20080923233449.GA2076@tango.0pointer.de> Message-ID: Lennart Poettering wrote: > You did not respond to my question what you'd think the proper > behaviour would be for gnome-panel. I'll take that as an > acknowledgment that you understand that the problem exists. I don't use gnome, but... I'd expect plasma (KDE's desktop container and taskbar) to write its settings out when I apply changes. This should either overwrite any other changes made to the file (a common behavior when running multiple independent instances of a program) or else merge the changes in a way that doesn't break the app the next time it starts up (but is not necessarily required to have any "desired effect"; IMO that's permissible for such a usage.) Therefore, I don't consider that there is a significant "problem" here. Ideally, updating the configuration would be atomic (this is probably needed regardless, although you aren't likely to have race conditions when talking about user settings) and would notify all instances to re-read the configuration, but I don't consider this crucial. >> Windows terminal services has gotten this more or less right since at least >> windows 2000 server that included 2 licenses for administrative use. If >> they can do it with an interface that wasn't designed to be remote or >> multiuser, it can't be that hard. > > Are you sure you can log in twice on Win2k as exactly the same user id? I don't know about w2k, but it works in 2k3 (I just tested). Two logins, same user, different apps running. Wow, it's almost like having virtual desktops! :-) So, er... yeah. To throw in my $0.02, I don't see why this shouldn't be permitted. (Incidentally, Firefox drives me nuts not letting me run it on my local login and via 'ssh -X' from a remote machine. Some apps are even worse behaved than not coping with two full local X sessions as to go so far as to not permit multiple instances to be run /at all/.) > On Tue, 23.09.08 15:50, Les Mikesell (lesmikesell at gmail.com) wrote: >> But, if it can't be done right, the WM should enforce it and give you a >> choice of killing the old session when you attempt a new login instead of >> just letting random things fail. > > Nah, if at all that's the job of the dm or the sm, not the wm. Er... I guess. I suppose the DM has to figure out how to start a second X root session. Beyond that, apps that break when you try to run two instances in multiple X sessions are, IMO, just plain buggy. It's perfectly normal for me to run apps over remote X, and not uncommon to want to run Xephyr sessions. I expect apps (and this includes WM's and other desktop bits) to work just fine if I try to run multiple instances in multiple X sessions, regardless of what kind of X session I'm trying to run it in (local, nested, remote, headless*). (* i.e. vncserver, or any others that use an offscreen buffer for X output) -- Matthew Igor Peshansky: Don't hippos love water even more than dogs? Dave Korn: Don't ask me. I didn't even know that hippos loved dogs. From walters at verbum.org Wed Sep 24 00:57:28 2008 From: walters at verbum.org (Colin Walters) Date: Tue, 23 Sep 2008 20:57:28 -0400 Subject: multiple local X logins by same user (was: Tried Pulse Audio Again--No Good For A11y) In-Reply-To: References: <20080916183444.GA4973@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> <20080923193026.GA12861@tango.0pointer.de> <48D95695.1050108@gmail.com> <20080923233449.GA2076@tango.0pointer.de> Message-ID: On Tue, Sep 23, 2008 at 8:38 PM, Matthew Woehlke wrote: > > > (Incidentally, Firefox drives me nuts not letting me run it on my local > login and via 'ssh -X' from a remote machine. Some apps are even worse > behaved than not coping with two full local X sessions as to go so far as to > not permit multiple instances to be run /at all/.) Basically every nontrivial app doesn't support it, because it's just too crazy. One could spend an entire lifespan trying to figure out "Ok, what if I do *this*?". If you want to access your Firefox instance remotely, use vino or one of the other systems that lets you access your existing session. It works, and we can collectively move on to more important problems. From lesmikesell at gmail.com Wed Sep 24 02:03:29 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 23 Sep 2008 21:03:29 -0500 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080923233449.GA2076@tango.0pointer.de> References: <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> <20080923193026.GA12861@tango.0pointer.de> <48D95695.1050108@gmail.com> <20080923233449.GA2076@tango.0pointer.de> Message-ID: <48D99FF1.3030000@gmail.com> Lennart Poettering wrote: > >>> For example: you configure your gnome panel to include a clock >>> applet. Then you open another session and add a network monitor applet >>> to it. What do you expect from this? That both panels will always stay >>> perfectly in sync and the network monitor applet is transparently >>> added to the first session as well? When you log out from both, what >>> happens when you log in again, do you get the panel layout from the >>> first session or from the second session? >> How is this different than running 2 instances of vi? If you edit the same >> file at the same time you'll have a conflict. That doesn't mean you should >> cripple the system to the point where it can't run 2 instances of >> vi. > > vi has static config files. They are only read on vi's startup. > > OTOH GNOME usually does instant-apply. I.e. what you configure is > immediately executed and saved for later. I've always hated that. I've had horrible things happen when I change layouts on a large screen and the next login is on a small one. Things in general seem to resize better now so maybe it isn't as much of a problem. Can you still make apps open with the borders you need to resize them off the screen completely? > You did not respond to my question what you'd think the proper > behaviour would be for gnome-panel. I'll take that as an > acknowledgment that you understand that the problem exists. My idea of proper behavior is to not change defaults unless I specify that I want defaults changed. I suppose that doesn't mesh very well with gnome concepts but just because I try something once on one monitor does not mean I'll want it always or ever again. And in the context of multiple sessions for the same user, that would mean the last save wins as you expect for other files. >>> The question is: is it worth bothering at all with questions like the >>> panel question above? Since the feature is redundant we might simply >>> say: forget it, let's disable multiple logins and the problem is >>> gone. >> Windows terminal services has gotten this more or less right since at least >> windows 2000 server that included 2 licenses for administrative use. If >> they can do it with an interface that wasn't designed to be remote or >> multiuser, it can't be that hard. > > Are you sure you can log in twice on Win2k as exactly the same user id? Yes, and you can be running the same apps in different-sized windows in each. You only get terminal services in the server products but it is done surprisingly well - current versions take sound along for the ride too. >> But, if it can't be done right, the WM should enforce it and give you a >> choice of killing the old session when you attempt a new login instead of >> just letting random things fail. > > Nah, if at all that's the job of the dm or the sm, not the wm. Which has the restriction of not understanding multiple concurrent sessions? -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Wed Sep 24 02:26:34 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 23 Sep 2008 21:26:34 -0500 Subject: multiple local X logins by same user In-Reply-To: References: <20080916183444.GA4973@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> <20080923193026.GA12861@tango.0pointer.de> <48D95695.1050108@gmail.com> <20080923233449.GA2076@tango.0pointer.de> Message-ID: <48D9A55A.3060902@gmail.com> Colin Walters wrote: > On Tue, Sep 23, 2008 at 8:38 PM, Matthew Woehlke > wrote: >> >> (Incidentally, Firefox drives me nuts not letting me run it on my local >> login and via 'ssh -X' from a remote machine. Some apps are even worse >> behaved than not coping with two full local X sessions as to go so far as to >> not permit multiple instances to be run /at all/.) > > Basically every nontrivial app doesn't support it, because it's just > too crazy. One could spend an entire lifespan trying to figure out > "Ok, what if I do *this*?". If you want to access your Firefox > instance remotely, use vino or one of the other systems that lets you > access your existing session. It works, and we can collectively move > on to more important problems. What is more important than predicable behavior? Something very different happens when you run firefox for the first time in a remote window compared to when it is already running. -- Les Mikesell lesmikesell at gmail.com From jspaleta at gmail.com Wed Sep 24 02:45:42 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 23 Sep 2008 18:45:42 -0800 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <45abe7d80809231737j5abee721g644af81a32c8552c@mail.gmail.com> References: <1221490775.18327.626.camel@beck.corsepiu.local> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> <20080923193026.GA12861@tango.0pointer.de> <48D95695.1050108@gmail.com> <604aa7910809231654x5b33793jbc9fff02f09efa6f@mail.gmail.com> <45abe7d80809231737j5abee721g644af81a32c8552c@mail.gmail.com> Message-ID: <604aa7910809231945x7611db18h65730ecafbb39649@mail.gmail.com> On Tue, Sep 23, 2008 at 4:37 PM, Ray Strode wrote: > You're not wrong, and it's not the desired behavior: > > http://bugzilla.gnome.org/show_bug.cgi?id=311780 > > Just hard to fix and no one has spent time doing it yet. Excellent! I absolutely love it when I'm wrong! -jef From lesmikesell at gmail.com Wed Sep 24 03:28:17 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Tue, 23 Sep 2008 22:28:17 -0500 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080923231312.GA338@tango.0pointer.de> References: <48CEAD51.9050700@gmail.com> <20080916183444.GA4973@sonata.rednote.net> <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <20080922180001.GA8379@sonata.rednote.net> <20080923001815.GE21642@tango.0pointer.de> <48D85D71.4020503@gmail.com> <20080923130529.GH7596@tango.0pointer.de> <48D950BB.3030103@gmail.com> <20080923231312.GA338@tango.0pointer.de> Message-ID: <48D9B3D1.70805@gmail.com> Lennart Poettering wrote: > >> Arbitrarily, as in guessing who should have exclusive access based on >> nothing that particularly relates to the specific audio device. It is no >> more right than automatically killing scheduled tape backups would be >> because someone else logged in on a keyboard near the tape device. > > We generally consider speakers/mikes/headphones to be part of the > workplace of the user, i.e. together with mouse/keyboard/screen > we switch them over when the active session changes. But, I rarely log on to the keyboard/screen attached to the machines running Linux. NX is so good that there is rarely any need to. > And again, that's the way *I* think it makes the most sense. If you haven't, give freenx/NX a try, floating your running session among displays at work, perhaps a wireless laptop, and pick them up from home with everything still running. And try it with several people sharing a machine. You might get used to the concept that your devices are really not that closely coupled. Or perhaps at least that your session isn't tied to the local console. X never intended it to be, but before freenx it wasn't that great remotely. > Of course, you are free to consider audio to be hw that is completely > detached from sessions. I disagree. Most of the RH engineers I talked > to about this agree with how *I* see things. (And Apple too, ...) Keep in mind that Apple makes a very good business out of selling things to help deal with what OS X lacks natively on the Macs. For example you can't even drive two different output devices at once to have always-on built-in speakers plus a USB device feeding an amp that you can power up for more volume. But they'll sell you an apple tv or airport express or ipod and dock to fix that for you. And I didn't realize RH was very involved in audio at all. > Nonetheless, I do see some sense in the way you want to use the audio > devices. However, I don't think that would be the normal use-case, and I also > don't think that defaulting to this insecure configuration would be a > good choice. The default isn't a particular problem - but that's not the only possible or even likely scenario, leaving the question of how to change the configuration. > BTW, Free Software is about scratching your own itches. Apparently > this functionality is very important to you, otherwise we wouldn't > have this discussion again and again and again. Hence: I AM HAPPY TO > MERGE YOUR PATCHES (if they are good)! Realistically, something like mediatomb feeding an independent media player like the one included in a PS3 is probably a better solution for what I want but I can't help thinking that a linux box should be able to do it all by itself while still providing other services. >> Exclusive access is OK. Killing that access based on unrelated >> circumstances isn't. > > We don't "kill" access. We suspend access until you reactivate your > session. So if I could get control of the local audio device in a remote X or freenx session that keeps running, would it keep control even if a different user logs on at the console? -- Les Mikesell lesmikesell at gmail.com From jonstanley at gmail.com Wed Sep 24 04:16:34 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 24 Sep 2008 00:16:34 -0400 Subject: Plan for tomorrows (20080924) FESCO meeting In-Reply-To: <1222188670.4108.65.camel@luminos.localdomain> References: <1222186624.14583.2.camel@truman> <1222188670.4108.65.camel@luminos.localdomain> Message-ID: 2008/9/23 Jesse Keating : > Any chance we can get a decision on this today? +1 here, for the record. Better late than never :) From dev at nigelj.com Wed Sep 24 04:25:25 2008 From: dev at nigelj.com (Nigel Jones) Date: Wed, 24 Sep 2008 16:25:25 +1200 Subject: Plan for tomorrows (20080924) FESCO meeting In-Reply-To: <1222186624.14583.2.camel@truman> References: <1222186624.14583.2.camel@truman> Message-ID: <1222230325.3367.100.camel@fantail.jnet.net.nz> On Tue, 2008-09-23 at 12:17 -0400, Brian Pepple wrote: > Hi, > > Please find below the list of topics that are likely to come up in the > next FESCo meeting that is scheduled for tomorrow, Wednesday at 18:00 > UTC in #fedora-meeting on irc.freenode.org: > > /topic FESCo-Meeting -- F10 Schedule slip - > https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01938.html - all > > /topic FESCo-Meeting -- MinGW - all > > /topic FESCo meeting -- Free discussion around Fedora > > You want something to be discussed? Send a note to the list in reply to > this mail and I'll add it to the schedule. You can also propose topics > in the meeting while it is in the "Free discussion around Fedora" phase. As discussed on IRC, if there is time: https://www.redhat.com/archives/fedora-advisory-board/2008-September/msg00080.html -- Nigel Jones From alexl at users.sourceforge.net Wed Sep 24 06:46:49 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Tue, 23 Sep 2008 23:46:49 -0700 Subject: rpms/blam/F-9 blam.spec,1.24,1.25 In-Reply-To: <20080924060730.2E9F370103@cvs1.fedora.phx.redhat.com> (Christopher Aillon's message of "Wed\, 24 Sep 2008 06\:07\:30 +0000 \(UTC\)") References: <20080924060730.2E9F370103@cvs1.fedora.phx.redhat.com> Message-ID: >>>>> "CA" == Christopher Aillon writes: CA> Author: caillon Update of /cvs/extras/rpms/blam/F-9 In directory CA> cvs1.fedora.phx.redhat.com:/tmp/cvs-serv30824 CA> Modified Files: blam.spec Log Message: * Wed Sep 24 2008 CA> Christopher Aillon - 1.8.5-2 - Rebuild CA> against newer gecko Are you going to bump and rebuild the rawhide/F-10 branch? rawhide is on: blam-1.8.5-1.fc10 which will cause a broken upgrade path as blam-1.8.5-2.fc9 > blam-1.8.5-1.fc10 Can you consider bumping the release tag *after* the disttag, i.e.: blam-1.8.5-1.fc9.1 this would avoid the need to rebuild the rawhide branch. Alex From pkh444 at yahoo.com Wed Sep 24 07:03:43 2008 From: pkh444 at yahoo.com (Prakash Hallalli) Date: Wed, 24 Sep 2008 00:03:43 -0700 (PDT) Subject: Is Zimbra open-source software Message-ID: <804765.33554.qm@web57416.mail.re1.yahoo.com> Hi, I am prakash, i would like to know about zimbra, Is Zimbra stable to deploy and is it free software (GNO/GPL)? Please help me. Thanks, prakash, k, h, -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at leemhuis.info Wed Sep 24 07:32:31 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 24 Sep 2008 09:32:31 +0200 Subject: rpms/blam/F-9 blam.spec,1.24,1.25 In-Reply-To: References: <20080924060730.2E9F370103@cvs1.fedora.phx.redhat.com> Message-ID: <48D9ED0F.6040804@leemhuis.info> On 24.09.2008 08:46, Alex Lancaster wrote: >>>>>> "CA" == Christopher Aillon writes: > > CA> Author: caillon Update of /cvs/extras/rpms/blam/F-9 In directory > CA> cvs1.fedora.phx.redhat.com:/tmp/cvs-serv30824 > > CA> Modified Files: blam.spec Log Message: * Wed Sep 24 2008 > CA> Christopher Aillon - 1.8.5-2 - Rebuild > CA> against newer gecko > > Are you going to bump and rebuild the rawhide/F-10 branch? rawhide is > on: > > blam-1.8.5-1.fc10 > > which will cause a broken upgrade path as > > blam-1.8.5-2.fc9 > blam-1.8.5-1.fc10 > > Can you consider bumping the release tag *after* the disttag, i.e.: > > blam-1.8.5-1.fc9.1 > > this would avoid the need to rebuild the rawhide branch. In case anybody is interested: a rough and not much tested patch(?) that makes rpmdev-bumpspec from rpmdevtools optionally bump the rightmost part of the release field can be found in: https://fedorahosted.org/rpmdevtools/ticket/1 CU knurd (?) done by someone with only basic python and programming skills ;-) From ml at deadbabylon.de Wed Sep 24 09:55:54 2008 From: ml at deadbabylon.de (Sebastian Vahl) Date: Wed, 24 Sep 2008 11:55:54 +0200 Subject: KDE-SIG weekly report (39/2008) Message-ID: <200809241156.02809.ml@deadbabylon.de> This is a report of the weekly KDE-SIG-Meeting with a summary of the topics that were discussed. If you want to add a comment please reply ?to this email or add it to the related meeting page. ---------------------------------------------------------------------------------- = Weekly KDE Summary = Week: 39/2008 Time: 2008-09-23 16:00 UTC Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-09-23 Meeting log: https://fedoraproject.org/w/uploads/d/dd/KDE-SIG-2008-09-23.txt ---------------------------------------------------------------------------------- = Participants = - ArthurPemberton - JaroslavReznik - KevinKofler - ThanNgo - RexDieter - SebastianVahl - StephenParrish ---------------------------------------------------------------------------------- = Agenda = - echo-icon-theme - phonon-xine for F10-beta = Summary = echo-icon-theme in KDE: ------------------------------------ * We should get a list of missing kde-specific icons in Echo and report them to the art team. * Maybe a special kde-settings.rpm with Echo already enabled will be prepared for willing testers to get more feedback. phonon-xine for F10-beta: ------------------------------------- * xine will be the default phonon-backend in Fedora 10 Beta. * The kickstart for the live images has to be prepared to include it. After Rawhide is unfrozen it will be a normal dependency. Open discussion: ------------------------- o knetworkmanager: * knetworkmanager is in Rawhide and will (likely) be in F10. o kpackagekit: * The beta4 of kpackagekit is in Rawhide, the .1 release will be released soon. o Live images: * The switch back to koffice-1.6 has increased the size of the live images a bit. x86_64 is now at 705 megs and so too big for a normal CD-R. [1] * With phonon-backend-xine there is no more need of gstreamer. * Pavucontrol, which is nice-to-have but not essential, will be removed from the live images to free the needed space (it pulls in gstreamer due to its dependecy libcanberra) ---------------------------------------------------------------------------------- = Next Meeting = https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2008-09-30 ---------------------------------------------------------------------------------- = Links = [1] http://fedoraproject.org/w/index.php?title=SebastianVahl/CurrentPackageList&oldid=50205 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: From dcbw at redhat.com Wed Sep 24 10:47:49 2008 From: dcbw at redhat.com (Dan Williams) Date: Wed, 24 Sep 2008 06:47:49 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <48D99FF1.3030000@gmail.com> References: <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> <20080923193026.GA12861@tango.0pointer.de> <48D95695.1050108@gmail.com> <20080923233449.GA2076@tango.0pointer.de> <48D99FF1.3030000@gmail.com> Message-ID: <1222253269.26675.4.camel@localhost.localdomain> On Tue, 2008-09-23 at 21:03 -0500, Les Mikesell wrote: > Lennart Poettering wrote: > > > >>> For example: you configure your gnome panel to include a clock > >>> applet. Then you open another session and add a network monitor applet > >>> to it. What do you expect from this? That both panels will always stay > >>> perfectly in sync and the network monitor applet is transparently > >>> added to the first session as well? When you log out from both, what > >>> happens when you log in again, do you get the panel layout from the > >>> first session or from the second session? > >> How is this different than running 2 instances of vi? If you edit the same > >> file at the same time you'll have a conflict. That doesn't mean you should > >> cripple the system to the point where it can't run 2 instances of > >> vi. > > > > vi has static config files. They are only read on vi's startup. > > > > OTOH GNOME usually does instant-apply. I.e. what you configure is > > immediately executed and saved for later. > > I've always hated that. I've had horrible things happen when I change > layouts on a large screen and the next login is on a small one. Things > in general seem to resize better now so maybe it isn't as much of a > problem. Can you still make apps open with the borders you need to > resize them off the screen completely? > > > You did not respond to my question what you'd think the proper > > behaviour would be for gnome-panel. I'll take that as an > > acknowledgment that you understand that the problem exists. > > My idea of proper behavior is to not change defaults unless I specify > that I want defaults changed. I suppose that doesn't mesh very well > with gnome concepts but just because I try something once on one monitor > does not mean I'll want it always or ever again. And in the context of > multiple sessions for the same user, that would mean the last save wins > as you expect for other files. > > >>> The question is: is it worth bothering at all with questions like the > >>> panel question above? Since the feature is redundant we might simply > >>> say: forget it, let's disable multiple logins and the problem is > >>> gone. > >> Windows terminal services has gotten this more or less right since at least > >> windows 2000 server that included 2 licenses for administrative use. If > >> they can do it with an interface that wasn't designed to be remote or > >> multiuser, it can't be that hard. > > > > Are you sure you can log in twice on Win2k as exactly the same user id? > > Yes, and you can be running the same apps in different-sized windows in > each. You only get terminal services in the server products but it is > done surprisingly well - current versions take sound along for the ride too. Are you sure? I was just watching somebody try to use RDP to a Windows Server 2008 box this weekend and it blanked out the first login and only allowed the second login direct access. I could be wrong and maybe he configured it wrong, but I though Windows only allowed one _active_ login at a time, and suspended the other remote sessions. Dan From Matt_Domsch at dell.com Wed Sep 24 12:20:36 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 24 Sep 2008 07:20:36 -0500 Subject: Fedora rawhide rebuild in mock status 2008-09-23 x86_64 Message-ID: <20080924122036.GA28400@mock.linuxdev.us.dell.com> Fedora Rawhide-in-Mock Build Results for x86_64 using the rawhide tree of Tuesday, 2008-10-23. This is not a full rebuild of everything, merely a rebuild of packages failing to build over the last few weeks. Failures here will cause new bugzilla bugs to be created, which will block the 'F10FTBFS' bug. My hope is that we can resolve all these before the Fedora 10 Release Candidate. 122 of these failures are due to patch fuzz. Each of those should be reviewed to ensure upstream has not already fixed the problem the patch addressed, either by applying the patch or by fixing it in another way. If the problem persists, please rebase the patch to the current source code, so it applies without fuzz, and forward your patch to the upstream package maintainer. Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 6191 Number failed to build: 312 Number expected to fail due to ExclusiveArch or ExcludeArch: 34 Leaving: 278 Of those expected to have worked... Without a bug filed: 275 ---------------------------------- KoboDeluxe-0.5.1-2.fc9 (build/make) jwrdegoede LabPlot-1.6.0.1-1.fc10 (patch_fuzz) chitlesh,chitlesh,tnorth PyAmanith-0.3.35-2.fc9 (patch_fuzz) spot PyX-0.10-4.fc9 (patch_fuzz) jamatos,mpeters,jamatos PythonCard-0.8.2-1.fc10 (build/make) mmahut R-Matrix-0.999375-4.fc9 (build/make) tmoertel R-RScaLAPACK-0.5.1-15.fc10 (patch_fuzz) spot SimGear-1.0.0-4.fc10 (patch_fuzz) spot,bellet UnihanDb-5.1.0-4.fc10 (build/make) dchen WindowMaker-0.92.0-18.fc9 (patch_fuzz) awjb a2ps-4.14-5.fc10 (patch_fuzz) twaugh,pertusus abiword-2.6.4-7.fc10 (build/make) uwog aide-0.13.1-4 (patch_fuzz) sgrubb akode-2.0.2-5.fc9 (patch_fuzz) rdieter,tuxbrewr ale-0.9.0.1-1.fc10 (patch_fuzz) silfreed alienarena-7.10-1.fc10 (patch_fuzz) spot alsa-firmware-1.0.17-1.fc10 (build/make) timj amanith-0.3-9.fc9 (patch_fuzz) spot amarok-1.90-1.fc10 (build/make) abompard,rdieter,tuxbrewr anacron-2.3-61.fc10 (patch_fuzz) mmaslano archivemail-0.7.2-1.fc9 (patch_fuzz) limb ardour-2.4.1-1.fc9 (patch_fuzz) green,jwrdegoede arm-gp2x-linux-gcc-4.1.2-8.fc9 (build/make) jwrdegoede arpack-2.1-7.fc9 (build/make) athimm astyle-1.21-6.fc8 (build/make) rishi,mtasaka asylum-0.2.3-3.fc9 (build/make) mfleming audacious-plugin-fc-0.2-7 (build/make) mschwendt aumix-2.8-17.fc9 (patch_fuzz) somlo autoconf-2.62-5.fc10 (patch_fuzz) karsten automake15-1.5-23 (patch_fuzz) karsten avr-binutils-2.18-2.fc9 (patch_fuzz) tnorth,trondd avr-gcc-4.1.2-6.fc9 (build/make) tnorth,trondd axis-1.2.1-4.fc10 (build/make) pcheung azureus-3.0.4.2-16.fc10 (build/make) langel,langel bidiv-1.5-6.fc9 (build/make) danken bigboard-0.6.2-2.fc10 (build/make) walters bigloo-3.1a-1.fc10 (patch_fuzz) gemi bit-0.4.1-3.fc9 (build/make) rvinyard bluez-utils-3.36-2.fc10 (build/make) dwmw2,hadess bmpx-0.40.14-5.fc9 (patch_fuzz) akahl bodhi-0.5.0-7.fc9 (build/make) lmacken,toshio,timlau boost-1.34.1-16.fc10 (patch_fuzz) bkoz,pmachata brltty-3.9-2.2.fc9 (build/make) kasal bsd-games-2.17-23.fc9 (patch_fuzz) wart bwbar-1.2.3-2 (patch_fuzz) adrian cernlib-2006-30.fc10 (build/make) pertusus cernlib-g77-2006-30.fc10 (build/make) pertusus classpathx-jaf-1.0-12.fc10 (build/make) devrim compat-gcc-34-3.4.6-9 (patch_fuzz) jakub conexus-0.5.3-4.fc9 (build/make) rvinyard conexusmm-0.5.0-3.fc7 (build/make) rvinyard coolkey-1.1.0-6.fc9 (build/make) rrelyea,jmagne cpan2rpm-2.028-2.fc8.1 (build/make) ghenry,perl-sig cyphesis-0.5.16-3.fc10 (build/make) wart dia-0.96.1-6.fc10 (patch_fuzz) huzaifas,huzaifas dnssec-tools-1.4.1-2.fc10 (build/make) hardaker docbook-utils-0.6.14-14.fc10 (build/make) ovasik dosbox-0.72-4.fc9 (build/make) awjb dump-0.4b41-8.fc10 (patch_fuzz) atkac dwdiff-1.4-1.fc10 (build/make) jhrozek dx-4.4.4-6.fc10 (patch_fuzz) rathann eclipse-checkstyle-4.0.1-10.fc9 (build/make) rmyers,overholt eclipse-egit-0.3.1-0.fc9 (build/make) rmyers eclipse-gef-3.3.0-2.fc9 (build/make) overholt eclipse-mylyn-3.0.1-2.fc10 (build/make) overholt eclipse-rpm-editor-0.4.0-1.fc10 (build/make) alcapcom,overholt eclipse-subclipse-1.2.4-11.fc9 (patch_fuzz) robmv elektra-0.6.10-6.fc9 (build/make) pertusus,kwizart emacspeak-26-3.fc8 (patch_fuzz) petersen evolution-brutus-1.2.17-1.fc10 (build/make) bpepple,colding evolution-rss-0.1.1-2.fc10 (build/make) lucilanga evolution-sharp-0.17.4-3.fc10 (build/make) mbarnes expect-5.43.0-14.fc10 (patch_fuzz) vcrhonek extrema-4.3.6-1.fc10 (build/make) terjeros,mmahut fedora-ds-base-1.1.1-2.fc10 (build/make) rmeggins,nkinder,nhosoi fetchmail-6.3.8-7.fc10 (patch_fuzz) vcrhonek,pertusus firewalk-5.0-2.fc9 (build/make) sindrepb fish-1.23.0-2.fc9 (build/make) ascii,oliver fltk-1.1.8-1.fc9 (patch_fuzz) rdieter,pertusus fluxstyle-1.0.1-2.fc7 (build/make) errr fonttools-2.0-0.11.20060223cvs.fc7 (unpackaged_files/python-egg-info?) roozbeh,fonts-sig fontypython-0.2.0-6.fc7 (build/make) cr33dog,fonts-sig freefem++-2.24-2.fc9 (build/make) rathann frysk-0.4-0.fc10 (build/make) cagney,pmuldoon,swagiaal gabedit-2.1.7-1.fc10 (build/make) rathann galeon-2.0.6-1.fc10 (patch_fuzz) denis gauche-0.8.13-2.fc10 (build/make) gemi gauche-gl-0.4.4-3.fc9 (build/make) gemi gauche-gtk-0.4.1-17.fc9 (build/make) gemi gcin-1.4.2-2.fc10 (patch_fuzz) candyz,petersen gcombust-0.1.55-13 (build/make) thias gdesklets-0.36-1.fc9 (unpackaged_files/python-egg-info?) luya,owentl gdmap-0.7.5-6.fc6 (build/make) splinux geronimo-specs-1.0-2.M2.fc10 (build/make) fnasser gimmix-0.4.2-3.fc9 (build/make) awjb glade2-2.12.2-2.fc9 (build/make) mclasen gmpc-0.15.5.0-3.fc9 (patch_fuzz) adrian gnome-python2-extras-2.19.1-17.fc9 (patch_fuzz) mbarnes gnome-specimen-0.3-2.fc10 (unpackaged_files/python-egg-info?) splinux gnumeric-1.8.2-2.fc9 (patch_fuzz) huzaifas,huzaifas goocanvas-0.10-1.fc10 (build/make) bjohnson groff-1.18.1.4-14.fc9 (patch_fuzz) kasal gstm-1.2-6.fc7 (build/make) splinux gtk+-1.2.10-61.fc9 (patch_fuzz) rdieter gtk-gnutella-0.96.5-2.fc10 (build/make) buc gweled-0.7-11.1 (patch_fuzz) thl hardinfo-0.4.2.3-6.fc10 (build/make) drago01 hdf-4.2r3-2.fc9 (build/make) orion,pertusus hfsutils-3.2.6-14.fc9 (patch_fuzz) dwmw2 ht2html-2.0-5.fc6 (build/make) ifoox ifplugd-0.28-11.fc9 (build/make) jamatos,rakesh indent-2.2.10-1.fc9 (patch_fuzz) rrakus ip-sentinel-0.12-11.fc9 (build/make) ensc isdn4k-utils-3.2-58.fc9 (patch_fuzz) than isomaster-1.3.3-1.fc10 (patch_fuzz) szpak itpp-4.0.0-2.fc9 (build/make) edhill jabbin-2.0-0.6.beta2a.fc9 (build/make) jakarta-commons-net-1.4.1-4.2.fc10 (patch_fuzz) pcheung jhead-2.82-1.fc9 (patch_fuzz) adrian jpackage-utils-1.7.5-1.5.fc10 (patch_fuzz) dbhole k3b-1.0.5-5.fc10 (build/make) rrakus,rdieter,tuxbrewr kaffeine-0.8.7-2.fc10 (build/make) rdieter,scop,mef kdemultimedia-4.1.1-1.fc10 (build/make) than,rdieter,kkofler,tuxbrewr,ltinkl,jreznik knetworkmanager-0.7-0.5.20080715svn.fc10 (build/make) ausil,rdieter,mmcgrath,liquidat,ltinkl koffice-langpack-1.6.3-1.fc8 (build/make) awjb ladspa-1.12-9.fc9 (build/make) thomasvs lazarus-0.9.24-4.fc10 (patch_fuzz) joost lib3ds-1.3.0-3.fc10 (build/make) corsepiu,laxathom libAfterImage-1.15-4.fc9 (patch_fuzz) awjb libXTrap-1.0.0-6.fc10 (build/make) ssp libXfontcache-1.0.4-5.fc9 (build/make) ssp,fonts-sig libepc-0.3.5-2.fc10 (build/make) bpepple libgii-1.0.2-6.fc9 (build/make) kwizart libgnomecups-0.2.3-3.fc9 (patch_fuzz) davidz libkexif-0.2.5-4.fc9 (patch_fuzz) abompard,rdieter libmatheval-1.1.5-2.fc9 (patch_fuzz) edhill libnasl-2.2.10-5.fc9 (patch_fuzz) awjb libpciaccess-0.10.3-2.fc9 (patch_fuzz) ajax librra-0.11.1-1.fc9 (build/make) awjb,abompard libstroke-0.5.1-17.fc9 (build/make) chitlesh libunwind-0.99-0.5.frysk20070405cvs.fc9 (build/make) jkratoch libzzub-0.2.3-12.fc9 (patch_fuzz) lineak-xosdplugin-0.9-2.fc6 (build/make) xris linkage-0.2.0-2.fc10 (build/make) drago01 linpsk-0.9-3.fc9 (build/make) bjensen,sindrepb,sconklin linux-atm-2.5.0-5 (build/make) dwmw2 lock-keys-applet-1.0-14.fc9 (build/make) jorge lockdev-1.0.1-12.fc9.1 (patch_fuzz) kzak lout-3.36-2.fc9 (build/make) spot ltrace-0.5-11.45svn.fc10 (patch_fuzz) pmachata lvm2-2.02.39-3.fc10 (build/make) lvm-team,agk,mornfall,bmr,mbroz,dwysocha,bmarzins lybniz-1.3.2-1.fc9 (patch_fuzz) firewing mailgraph-1.14-2.fc9 (patch_fuzz) bjohnson,mfleming make-3.81-12.fc9 (patch_fuzz) pmachata maven-wagon-1.0-0.1.a5.3.3.fc10 (build/make) mwringe mdadm-2.6.7-1.fc10 (patch_fuzz) dledford mediatomb-0.11.0-1.fc9 (build/make) mwiriadi mgetty-1.1.36-1.fc10 (patch_fuzz) jskala,jskala mimetic-0.9.3-2.fc8 (build/make) ensc mod_python-3.3.1-7 (build/make) jorton mtools-3.9.11-4.fc9 (patch_fuzz) atkac mx-2.0.6-3 (unpackaged_files/python-egg-info?) pfj mysql-connector-java-3.1.12-6.fc10 (build/make) ifoox mysql-gui-tools-5.0r12-8.fc9 (patch_fuzz) ausil,hubbitus nagi-2.06-5.fc9 (patch_fuzz) limb nagios-3.0.3-6.fc10 (patch_fuzz) mmcgrath,wtogami,romal,sebastian nedit-5.5-18.fc9 (patch_fuzz) jnovy nessus-core-2.2.10-4.fc9 (patch_fuzz) awjb netatalk-2.0.3-19.fc9 (build/make) jskala nethogs-0.7-3.20080627cvs.fc10 (build/make) afsilva nfs4-acl-tools-0.3.2-2.fc9 (patch_fuzz) steved ocsinventory-agent-0.0.9.2-1.fc10 (patch_fuzz) remi ode-0.9-4.fc9 (patch_fuzz) jwrdegoede,eitch oggconvert-0.3.0-14.fc9 (unpackaged_files/python-egg-info?) ngompa openal-0.0.9-0.15.20060204cvs.fc9 (patch_fuzz) awjb openjpeg-1.3-2.fc9 (patch_fuzz) seg osiv-2.0.0-0.4.beta.fc9 (build/make) edhill oyranos-0.1.7-11.fc9 (patch_fuzz) kwizart papyrus-0.7.1-3.fc9 (build/make) rvinyard pards-0.4-6.fc9 (build/make) masahase pcre-7.3-4.fc10 (patch_fuzz) kasal,lkundrak pdfedit-0.4.1-1.fc10 (patch_fuzz) bjohnson pekwm-0.1.5-5.fc7 (build/make) errr perl-Apache2-SOAP-0.73-1.fc10 (build/make) remi perl-CGI-SpeedyCGI-2.22-2.fc10 (build/make) robert perl-Catalyst-Plugin-ConfigLoader-0.20-1.fc10 (build/make) cweyl,perl-sig perl-Crypt-SSLeay-0.57-7.fc9 (patch_fuzz) kasal,rnorwood,mmaslano perl-DBIx-Class-0.08010-6.fc10 (patch_fuzz) cweyl,perl-sig perl-Event-Lib-1.03-3.fc10 (build/make) kwizart,perl-sig perl-PDF-API2-0.69-5.fc10 (patch_fuzz) bjohnson,perl-sig perl-RRD-Simple-1.43-3.fc9 (build/make) cweyl,perl-sig perl-SVN-Mirror-0.73-3.fc9 (build/make) iburrell,perl-sig perl-Test-AutoBuild-1.2.2-3.fc9 (build/make) berrange perl-bioperl-1.5.2_102-12.fc9 (patch_fuzz) alexlan,perl-sig petitboot-0.0.1-7.fc8 (build/make) dwmw2,jwboyer phpldapadmin-1.1.0.5-1.fc9 (patch_fuzz) buc pic2aa-0.2.1-3.fc9 (build/make) kurzawa piklab-0.15.3-1.fc10 (patch_fuzz) chitlesh pinot-0.87-1.fc10 (build/make) drago01 pl-5.6.57-2.fc10 (build/make) gemi,mef planet-2.0-5.fc9 (patch_fuzz) richdawe plexus-runtime-builder-1.0-0.2.a9.1.5.fc10 (build/make) dbhole plexus-xmlrpc-1.0-0.2.b4.2.9.fc10 (patch_fuzz) dbhole pmount-0.9.17-2.fc9 (patch_fuzz) pertusus,jpmahowa pnm2ppa-1.04-15.fc9 (patch_fuzz) twaugh poker-network-1.6.0-1.fc10 (patch_fuzz) xulchris polyxmass-bin-0.9.7-2.fc8 (build/make) awjb pspp-0.6.0-7.fc10 (build/make) mcepl pstoedit-3.45-3.fc10 (patch_fuzz) denis pyclutter-0.6.2-2.fc9 (build/make) allisson pysvn-1.5.3-1.fc10 (patch_fuzz) ravenoak python-TurboMail-2.1-3.fc9 (build/make) lmacken,toshio,fschwarz python-durus-3.5-3.fc7 (build/make) rakesh python-imaging-1.1.6-10.fc10 (patch_fuzz) jamatos,jgranado python-reportlab-2.1-2.fc9 (build/make) bpepple python-simpletal-4.1-5.fc7 (build/make) python-tgcaptcha-0.11-3.fc10 (build/make) lmacken,toshio,fschwarz python-turboflot-0.1.1-1.fc10 (build/make) lmacken,toshio,fschwarz pywbxml-0.1-3.fc9 (build/make) awjb pyzor-0.4.0-11.fc7 (build/make) ixs qemu-0.9.1-10.fc10 (patch_fuzz) dwmw2 qgo-1.5.4r2-1.fc9 (build/make) kaboom qpidc-0.3.693548-1.fc10 (build/make) aconway,nsantos qt3-3.3.8b-14.fc10 (patch_fuzz) than,rdieter,kkofler quake3-1.34-0.9.rc4.fc9 (patch_fuzz) laxathom queuegraph-1.1-3.fc9 (patch_fuzz) bjohnson rafkill-1.2.3-1.fc10 (patch_fuzz) limb rasqal-0.9.15-1.fc9 (build/make) thomasvs rsh-0.17-50.fc10 (patch_fuzz) atkac ruby-bdb-0.6.0-1.fc7 (build/make) errr ruby-rpm-1.2.3-4.fc9 (build/make) lutter,stahnma scim-skk-0.5.2-8.fc6 (build/make) ryo sdcc-2.6.0-12.fc9 (build/make) konradm,jwrdegoede seamonkey-1.1.11-1.fc9 (patch_fuzz) gecko-maint,kengert seq24-0.8.7-13.fc10 (patch_fuzz) green slim-1.3.0-5.fc10 (patch_fuzz) afb smarteiffel-2.3-2.fc9 (build/make) gemi squid-3.0.STABLE7-1.fc10 (patch_fuzz) jskala,jsteffan,mnagy,hno,jskala straw-0.27-12.fc9 (build/make) subhodip sundials-2.3.0-6.fc9 (build/make) jpye sysvinit-2.86-24 (patch_fuzz) notting tachyon-0.98-0.6.20070319.fc9 (build/make) rathann tanukiwrapper-3.2.3-2.2.fc10 (patch_fuzz) dbhole,devrim,jmrodri tclparser-1.4-4.20061030cvs.fc9 (build/make) wart tcltls-1.5.0-16.fc9 (patch_fuzz) tjikkun thttpd-2.25b-16.fc9 (patch_fuzz) thias thunderbird-2.0.0.14-1.fc10 (patch_fuzz) gecko-maint tiger-3.2.1-8.fc9 (patch_fuzz) abompard time-1.7-33.fc9 (build/make) rrakus tla-1.3.5-5.fc9 (build/make) rishi tomcat5-5.5.26-1.5.fc10 (build/make) devrim,devrim uw-imap-2007b-1.fc10 (patch_fuzz) rdieter,jorton valgrind-3.3.0-3 (patch_fuzz) jakub vnc-4.1.2-34.fc10 (patch_fuzz) atkac vtk-5.0.4-21.fc9 (patch_fuzz) athimm,orion w3c-libwww-5.4.1-0.10.20060206cvs.fc9 (patch_fuzz) awjb w3lib-1.6-3.fc10 (build/make) pertusus wammu-0.28-1.fc10 (build/make) laxathom wcstools-3.7.0-2.fc9 (build/make) sergiopr,mmahut wesnoth-1.4.4-1.fc10 (build/make) limb,wtogami wp_tray-0.5.3-7.fc9 (patch_fuzz) denis x3270-3.3.6-5.fc9 (patch_fuzz) karsten xautolock-2.2-5.fc9 (build/make) ianweller xcb-proto-1.2-2.fc10 (unpackaged_files/python-egg-info?) ajax xdelta-1.1.4-3.fc9 (patch_fuzz) atkac xdoclet-1.2.3-9.2.fc10 (patch_fuzz) mwringe xdx-2.4-2.fc9 (build/make) bjensen,sindrepb,sconklin xfce4-panel-4.4.2-4.fc9 (patch_fuzz) kevin,cwickert xlhtml-0.5-8.fc9 (build/make) abompard xmms-cdread-0.14-13.fc9 (build/make) jsoeterb xmoto-0.4.2-1.fc9 (patch_fuzz) limb xscorch-0.2.0-12.fc8 (build/make) mgarski yoltia-0.22.1-2.fc9 (build/make) kurzawa ypserv-2.19-9.fc9 (patch_fuzz) vcrhonek zsh-4.3.4-8.fc9 (patch_fuzz) james With bugs filed: 3 ---------------------------------- gtk-sharp-1.0.10-12.fc7 [u'434373 ASSIGNED'] (unpackaged_files/python-egg-info?) pfj libFoundation-1.1.3-11.fc9 [u'440564 ASSIGNED'] (build/make) athimm qtiplot-0.9-8.fc9 [u'434100 ASSIGNED'] (build/make) frankb ---------------------------------- Packages by owner: abompard: amarok,libkexif,librra,tiger,xlhtml aconway: qpidc adrian: bwbar,gmpc,jhead afb: slim afsilva: nethogs agk: lvm2 ajax: libpciaccess,xcb-proto akahl: bmpx alcapcom: eclipse-rpm-editor alexlan: perl-bioperl allisson: pyclutter ascii: fish athimm: arpack,libFoundation,vtk atkac: dump,mtools,rsh,vnc,xdelta ausil: knetworkmanager,mysql-gui-tools awjb: WindowMaker,dosbox,gimmix,koffice-langpack,libAfterImage,libnasl,librra,nessus-core,openal,polyxmass-bin,pywbxml,w3c-libwww bellet: SimGear berrange: perl-Test-AutoBuild bjensen: linpsk,xdx bjohnson: goocanvas,mailgraph,pdfedit,perl-PDF-API2,queuegraph bkoz: boost bmarzins: lvm2 bmr: lvm2 bpepple: evolution-brutus,libepc,python-reportlab buc: gtk-gnutella,phpldapadmin cagney: frysk candyz: gcin chitlesh: LabPlot,LabPlot,libstroke,piklab colding: evolution-brutus corsepiu: lib3ds cr33dog: fontypython cweyl: perl-Catalyst-Plugin-ConfigLoader,perl-DBIx-Class,perl-RRD-Simple cwickert: xfce4-panel danken: bidiv davidz: libgnomecups dbhole: jpackage-utils,plexus-runtime-builder,plexus-xmlrpc,tanukiwrapper dchen: UnihanDb denis: galeon,pstoedit,wp_tray devrim: classpathx-jaf,tanukiwrapper,tomcat5,tomcat5 dledford: mdadm drago01: hardinfo,linkage,pinot dwmw2: bluez-utils,hfsutils,linux-atm,petitboot,qemu dwysocha: lvm2 edhill: itpp,libmatheval,osiv eitch: ode ensc: ip-sentinel,mimetic errr: fluxstyle,pekwm,ruby-bdb firewing: lybniz fnasser: geronimo-specs fonts-sig: fonttools,fontypython,libXfontcache frankb: qtiplot fschwarz: python-TurboMail,python-tgcaptcha,python-turboflot gecko-maint: seamonkey,thunderbird gemi: bigloo,gauche,gauche-gl,gauche-gtk,pl,smarteiffel ghenry: cpan2rpm green: ardour,seq24 hadess: bluez-utils hardaker: dnssec-tools hno: squid hubbitus: mysql-gui-tools huzaifas: dia,dia,gnumeric,gnumeric ianweller: xautolock iburrell: perl-SVN-Mirror ifoox: ht2html,mysql-connector-java ixs: pyzor jakub: compat-gcc-34,valgrind jamatos: PyX,PyX,ifplugd,python-imaging james: zsh jgranado: python-imaging jhrozek: dwdiff jkratoch: libunwind jmagne: coolkey jmrodri: tanukiwrapper jnovy: nedit joost: lazarus jorge: lock-keys-applet jorton: mod_python,uw-imap jpmahowa: pmount jpye: sundials jreznik: kdemultimedia jskala: mgetty,mgetty,netatalk,squid,squid jsoeterb: xmms-cdread jsteffan: squid jwboyer: petitboot jwrdegoede: KoboDeluxe,ardour,arm-gp2x-linux-gcc,ode,sdcc kaboom: qgo karsten: autoconf,automake15,x3270 kasal: brltty,groff,pcre,perl-Crypt-SSLeay kengert: seamonkey kevin: xfce4-panel kkofler: kdemultimedia,qt3 konradm: sdcc kurzawa: pic2aa,yoltia kwizart: elektra,libgii,oyranos,perl-Event-Lib kzak: lockdev langel: azureus,azureus laxathom: lib3ds,quake3,wammu limb: archivemail,nagi,rafkill,wesnoth,xmoto liquidat: knetworkmanager lkundrak: pcre lmacken: bodhi,python-TurboMail,python-tgcaptcha,python-turboflot ltinkl: kdemultimedia,knetworkmanager lucilanga: evolution-rss lutter: ruby-rpm luya: gdesklets lvm-team: lvm2 masahase: pards mbarnes: evolution-sharp,gnome-python2-extras mbroz: lvm2 mcepl: pspp mclasen: glade2 mef: kaffeine,pl mfleming: asylum,mailgraph mgarski: xscorch mmahut: PythonCard,extrema,wcstools mmaslano: anacron,perl-Crypt-SSLeay mmcgrath: knetworkmanager,nagios mnagy: squid mornfall: lvm2 mpeters: PyX mschwendt: audacious-plugin-fc mtasaka: astyle mwiriadi: mediatomb mwringe: maven-wagon,xdoclet ngompa: oggconvert nhosoi: fedora-ds-base nkinder: fedora-ds-base notting: sysvinit nsantos: qpidc oliver: fish orion: hdf,vtk ovasik: docbook-utils overholt: eclipse-checkstyle,eclipse-gef,eclipse-mylyn,eclipse-rpm-editor owentl: gdesklets pcheung: axis,jakarta-commons-net perl-sig: cpan2rpm,perl-Catalyst-Plugin-ConfigLoader,perl-DBIx-Class,perl-Event-Lib,perl-PDF-API2,perl-RRD-Simple,perl-SVN-Mirror,perl-bioperl pertusus: a2ps,cernlib,cernlib-g77,elektra,fetchmail,fltk,hdf,pmount,w3lib petersen: emacspeak,gcin pfj: gtk-sharp,mx pmachata: boost,ltrace,make pmuldoon: frysk rakesh: ifplugd,python-durus rathann: dx,freefem++,gabedit,tachyon ravenoak: pysvn rdieter: akode,amarok,fltk,gtk+,k3b,kaffeine,kdemultimedia,knetworkmanager,libkexif,qt3,uw-imap remi: ocsinventory-agent,perl-Apache2-SOAP richdawe: planet rishi: astyle,tla rmeggins: fedora-ds-base rmyers: eclipse-checkstyle,eclipse-egit rnorwood: perl-Crypt-SSLeay robert: perl-CGI-SpeedyCGI robmv: eclipse-subclipse romal: nagios roozbeh: fonttools rrakus: indent,k3b,time rrelyea: coolkey rvinyard: bit,conexus,conexusmm,papyrus ryo: scim-skk sconklin: linpsk,xdx scop: kaffeine sebastian: nagios seg: openjpeg sergiopr: wcstools sgrubb: aide silfreed: ale sindrepb: firewalk,linpsk,xdx somlo: aumix splinux: gdmap,gnome-specimen,gstm spot: PyAmanith,R-RScaLAPACK,SimGear,alienarena,amanith,lout ssp: libXTrap,libXfontcache stahnma: ruby-rpm steved: nfs4-acl-tools subhodip: straw swagiaal: frysk szpak: isomaster terjeros: extrema than: isdn4k-utils,kdemultimedia,qt3 thias: gcombust,thttpd thl: gweled thomasvs: ladspa,rasqal timj: alsa-firmware timlau: bodhi tjikkun: tcltls tmoertel: R-Matrix tnorth: LabPlot,avr-binutils,avr-gcc toshio: bodhi,python-TurboMail,python-tgcaptcha,python-turboflot trondd: avr-binutils,avr-gcc tuxbrewr: akode,amarok,k3b,kdemultimedia twaugh: a2ps,pnm2ppa uwog: abiword vcrhonek: expect,fetchmail,ypserv walters: bigboard wart: bsd-games,cyphesis,tclparser wtogami: nagios,wesnoth xris: lineak-xosdplugin xulchris: poker-network -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Wed Sep 24 12:21:47 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 24 Sep 2008 07:21:47 -0500 Subject: Fedora rawhide rebuild in mock status 2008-09-23 i386 Message-ID: <20080924122147.GA4137@mock.linuxdev.us.dell.com> Fedora Rawhide-in-Mock Build Results for i386 using the rawhide tree of Tuesday, 2008-10-23. This is not a full rebuild of everything, merely a rebuild of packages failing to build over the last few weeks. Failures here will cause new bugzilla bugs to be created, which will block the 'F10FTBFS' bug. My hope is that we can resolve all these before the Fedora 10 Release Candidate. 122 of these failures are due to patch fuzz. Each of those should be reviewed to ensure upstream has not already fixed the problem the patch addressed, either by applying the patch or by fixing it in another way. If the problem persists, please rebase the patch to the current source code, so it applies without fuzz, and forward your patch to the upstream package maintainer. Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ Total packages: 6192 Number failed to build: 278 Number expected to fail due to ExclusiveArch or ExcludeArch: 14 Leaving: 264 Of those expected to have worked... Without a bug filed: 260 ---------------------------------- KoboDeluxe-0.5.1-2.fc9 (build/make) jwrdegoede LabPlot-1.6.0.1-1.fc10 (patch_fuzz) chitlesh,chitlesh,tnorth PyAmanith-0.3.35-2.fc9 (patch_fuzz) spot PyX-0.10-4.fc9 (patch_fuzz) jamatos,mpeters,jamatos R-Matrix-0.999375-4.fc9 (build/make) tmoertel R-RScaLAPACK-0.5.1-15.fc10 (patch_fuzz) spot SimGear-1.0.0-4.fc10 (patch_fuzz) spot,bellet UnihanDb-5.1.0-4.fc10 (build/make) dchen WindowMaker-0.92.0-18.fc9 (patch_fuzz) awjb a2ps-4.14-5.fc10 (patch_fuzz) twaugh,pertusus abiword-2.6.4-7.fc10 (build/make) uwog aide-0.13.1-4 (patch_fuzz) sgrubb akode-2.0.2-5.fc9 (patch_fuzz) rdieter,tuxbrewr ale-0.9.0.1-1.fc10 (patch_fuzz) silfreed alienarena-7.10-1.fc10 (patch_fuzz) spot alsa-firmware-1.0.17-1.fc10 (build/make) timj amanith-0.3-9.fc9 (patch_fuzz) spot amarok-1.90-1.fc10 (build/make) abompard,rdieter,tuxbrewr anacron-2.3-61.fc10 (patch_fuzz) mmaslano archivemail-0.7.2-1.fc9 (patch_fuzz) limb ardour-2.4.1-1.fc9 (patch_fuzz) green,jwrdegoede arm-gp2x-linux-gcc-4.1.2-8.fc9 (build/make) jwrdegoede arpack-2.1-7.fc9 (build/make) athimm astyle-1.21-6.fc8 (build/make) rishi,mtasaka asylum-0.2.3-3.fc9 (build/make) mfleming atitvout-0.4-8 (patch_fuzz) awjb atlas-3.6.0-15.fc10 (build/make) deji,deji audacious-plugin-fc-0.2-7 (build/make) mschwendt aumix-2.8-17.fc9 (patch_fuzz) somlo autoconf-2.62-5.fc10 (patch_fuzz) karsten automake15-1.5-23 (patch_fuzz) karsten avr-binutils-2.18-2.fc9 (patch_fuzz) tnorth,trondd avr-gcc-4.1.2-6.fc9 (build/make) tnorth,trondd azureus-3.0.4.2-16.fc10 (build/make) langel,langel bidiv-1.5-6.fc9 (build/make) danken bigboard-0.6.2-2.fc10 (build/make) walters bigloo-3.1a-1.fc10 (patch_fuzz) gemi bit-0.4.1-3.fc9 (build/make) rvinyard bluez-utils-3.36-2.fc10 (build/make) dwmw2,hadess bmpx-0.40.14-5.fc9 (patch_fuzz) akahl bodhi-0.5.0-7.fc9 (build/make) lmacken,toshio,timlau boost-1.34.1-16.fc10 (patch_fuzz) bkoz,pmachata brltty-3.9-2.2.fc9 (build/make) kasal bsd-games-2.17-23.fc9 (patch_fuzz) wart bwbar-1.2.3-2 (patch_fuzz) adrian cernlib-2006-30.fc10 (build/make) pertusus cernlib-g77-2006-30.fc10 (build/make) pertusus classpathx-jaf-1.0-12.fc10 (build/make) devrim compat-gcc-34-3.4.6-9 (patch_fuzz) jakub conexus-0.5.3-4.fc9 (build/make) rvinyard conexusmm-0.5.0-3.fc7 (build/make) rvinyard coolkey-1.1.0-6.fc9 (build/make) rrelyea,jmagne cpan2rpm-2.028-2.fc8.1 (build/make) ghenry,perl-sig cyphesis-0.5.16-3.fc10 (build/make) wart dia-0.96.1-6.fc10 (patch_fuzz) huzaifas,huzaifas dnssec-tools-1.4.1-2.fc10 (build/make) hardaker dosbox-0.72-4.fc9 (build/make) awjb dump-0.4b41-8.fc10 (patch_fuzz) atkac dwdiff-1.4-1.fc10 (build/make) jhrozek dx-4.4.4-6.fc10 (patch_fuzz) rathann eclipse-checkstyle-4.0.1-10.fc9 (build/make) rmyers,overholt eclipse-egit-0.3.1-0.fc9 (build/make) rmyers eclipse-gef-3.3.0-2.fc9 (build/make) overholt eclipse-mylyn-3.0.1-2.fc10 (build/make) overholt eclipse-rpm-editor-0.4.0-1.fc10 (build/make) alcapcom,overholt eclipse-subclipse-1.2.4-11.fc9 (patch_fuzz) robmv elektra-0.6.10-6.fc9 (build/make) pertusus,kwizart emacspeak-26-3.fc8 (patch_fuzz) petersen evolution-brutus-1.2.17-1.fc10 (build/make) bpepple,colding evolution-rss-0.1.1-2.fc10 (build/make) lucilanga evolution-sharp-0.17.4-3.fc10 (build/make) mbarnes expect-5.43.0-14.fc10 (patch_fuzz) vcrhonek extrema-4.3.6-1.fc10 (build/make) terjeros,mmahut fedora-ds-base-1.1.1-2.fc10 (build/make) rmeggins,nkinder,nhosoi fetchmail-6.3.8-7.fc10 (patch_fuzz) vcrhonek,pertusus fish-1.23.0-2.fc9 (build/make) ascii,oliver fltk-1.1.8-1.fc9 (patch_fuzz) rdieter,pertusus fluxstyle-1.0.1-2.fc7 (build/make) errr fonttools-2.0-0.11.20060223cvs.fc7 (unpackaged_files/python-egg-info?) roozbeh,fonts-sig fontypython-0.2.0-6.fc7 (build/make) cr33dog,fonts-sig freefem++-2.24-2.fc9 (build/make) rathann frysk-0.4-0.fc10 (build/make) cagney,pmuldoon,swagiaal gabedit-2.1.7-1.fc10 (build/make) rathann galeon-2.0.6-1.fc10 (patch_fuzz) denis gambas-1.0.19-6.fc9 (patch_fuzz) spot gcin-1.4.2-2.fc10 (patch_fuzz) candyz,petersen gdesklets-0.36-1.fc9 (unpackaged_files/python-egg-info?) luya,owentl gdmap-0.7.5-6.fc6 (build/make) splinux geronimo-specs-1.0-2.M2.fc10 (build/make) fnasser gimmix-0.4.2-3.fc9 (build/make) awjb glade2-2.12.2-2.fc9 (build/make) mclasen gmpc-0.15.5.0-3.fc9 (patch_fuzz) adrian gnome-python2-extras-2.19.1-17.fc9 (patch_fuzz) mbarnes gnumeric-1.8.2-2.fc9 (patch_fuzz) huzaifas,huzaifas goocanvas-0.10-1.fc10 (build/make) bjohnson groff-1.18.1.4-14.fc9 (patch_fuzz) kasal gstm-1.2-6.fc7 (build/make) splinux gtk+-1.2.10-61.fc9 (patch_fuzz) rdieter gtk-gnutella-0.96.5-2.fc10 (build/make) buc gweled-0.7-11.1 (patch_fuzz) thl hardinfo-0.4.2.3-6.fc10 (build/make) drago01 hdf-4.2r3-2.fc9 (build/make) orion,pertusus hfsutils-3.2.6-14.fc9 (patch_fuzz) dwmw2 ht2html-2.0-5.fc6 (build/make) ifoox ifplugd-0.28-11.fc9 (build/make) jamatos,rakesh indent-2.2.10-1.fc9 (patch_fuzz) rrakus ip-sentinel-0.12-11.fc9 (build/make) ensc isdn4k-utils-3.2-58.fc9 (patch_fuzz) than isomaster-1.3.3-1.fc10 (patch_fuzz) szpak itpp-4.0.0-2.fc9 (build/make) edhill jabbin-2.0-0.6.beta2a.fc9 (build/make) jakarta-commons-net-1.4.1-4.2.fc10 (patch_fuzz) pcheung jhead-2.82-1.fc9 (patch_fuzz) adrian jpackage-utils-1.7.5-1.5.fc10 (patch_fuzz) dbhole k3b-1.0.5-5.fc10 (build/make) rrakus,rdieter,tuxbrewr kaffeine-0.8.7-2.fc10 (build/make) rdieter,scop,mef kdemultimedia-4.1.1-1.fc10 (build/make) than,rdieter,kkofler,tuxbrewr,ltinkl,jreznik knetworkmanager-0.7-0.5.20080715svn.fc10 (build/make) ausil,rdieter,mmcgrath,liquidat,ltinkl koffice-langpack-1.6.3-1.fc8 (build/make) awjb ladspa-1.12-9.fc9 (build/make) thomasvs lazarus-0.9.24-4.fc10 (patch_fuzz) joost lib3ds-1.3.0-3.fc10 (build/make) corsepiu,laxathom libAfterImage-1.15-4.fc9 (patch_fuzz) awjb libXTrap-1.0.0-6.fc10 (build/make) ssp libXfontcache-1.0.4-5.fc9 (build/make) ssp,fonts-sig libepc-0.3.5-2.fc10 (build/make) bpepple libgnomecups-0.2.3-3.fc9 (patch_fuzz) davidz libkexif-0.2.5-4.fc9 (patch_fuzz) abompard,rdieter libmatheval-1.1.5-2.fc9 (patch_fuzz) edhill libnasl-2.2.10-5.fc9 (patch_fuzz) awjb libpciaccess-0.10.3-2.fc9 (patch_fuzz) ajax librra-0.11.1-1.fc9 (build/make) awjb,abompard libunwind-0.99-0.5.frysk20070405cvs.fc9 (build/make) jkratoch libzzub-0.2.3-12.fc9 (patch_fuzz) lineak-xosdplugin-0.9-2.fc6 (build/make) xris linkage-0.2.0-2.fc10 (build/make) drago01 linpsk-0.9-3.fc9 (build/make) bjensen,sindrepb,sconklin linux-atm-2.5.0-5 (build/make) dwmw2 lock-keys-applet-1.0-14.fc9 (build/make) jorge lockdev-1.0.1-12.fc9.1 (patch_fuzz) kzak lrmi-0.10-4.fc9 (build/make) pwouters ltrace-0.5-11.45svn.fc10 (patch_fuzz) pmachata lvm2-2.02.39-3.fc10 (build/make) lvm-team,agk,mornfall,bmr,mbroz,dwysocha,bmarzins lybniz-1.3.2-1.fc9 (patch_fuzz) firewing mailgraph-1.14-2.fc9 (patch_fuzz) bjohnson,mfleming make-3.81-12.fc9 (patch_fuzz) pmachata maven-wagon-1.0-0.1.a5.3.3.fc10 (build/make) mwringe mdadm-2.6.7-1.fc10 (patch_fuzz) dledford mediatomb-0.11.0-1.fc9 (build/make) mwiriadi mgetty-1.1.36-1.fc10 (patch_fuzz) jskala,jskala mimetic-0.9.3-2.fc8 (build/make) ensc mod_python-3.3.1-7 (build/make) jorton mtools-3.9.11-4.fc9 (patch_fuzz) atkac muine-scrobbler-0.1.8-5.fc9 (build/make) sindrepb mx-2.0.6-3 (unpackaged_files/python-egg-info?) pfj mysql-gui-tools-5.0r12-8.fc9 (patch_fuzz) ausil,hubbitus nagi-2.06-5.fc9 (patch_fuzz) limb nagios-3.0.3-6.fc10 (patch_fuzz) mmcgrath,wtogami,romal,sebastian nedit-5.5-18.fc9 (patch_fuzz) jnovy nessus-core-2.2.10-4.fc9 (patch_fuzz) awjb netatalk-2.0.3-19.fc9 (build/make) jskala nethogs-0.7-3.20080627cvs.fc10 (build/make) afsilva nfs4-acl-tools-0.3.2-2.fc9 (patch_fuzz) steved ocsinventory-agent-0.0.9.2-1.fc10 (patch_fuzz) remi ode-0.9-4.fc9 (patch_fuzz) jwrdegoede,eitch oggconvert-0.3.0-14.fc9 (unpackaged_files/python-egg-info?) ngompa openal-0.0.9-0.15.20060204cvs.fc9 (patch_fuzz) awjb openjpeg-1.3-2.fc9 (patch_fuzz) seg osiv-2.0.0-0.4.beta.fc9 (build/make) edhill oyranos-0.1.7-11.fc9 (patch_fuzz) kwizart papyrus-0.7.1-3.fc9 (build/make) rvinyard pards-0.4-6.fc9 (build/make) masahase pcre-7.3-4.fc10 (patch_fuzz) kasal,lkundrak pdfedit-0.4.1-1.fc10 (patch_fuzz) bjohnson pekwm-0.1.5-5.fc7 (build/make) errr perl-Apache2-SOAP-0.73-1.fc10 (build/make) remi perl-CGI-SpeedyCGI-2.22-2.fc10 (build/make) robert perl-Catalyst-Plugin-ConfigLoader-0.20-1.fc10 (build/make) cweyl,perl-sig perl-Crypt-SSLeay-0.57-7.fc9 (patch_fuzz) kasal,rnorwood,mmaslano perl-DBIx-Class-0.08010-6.fc10 (patch_fuzz) cweyl,perl-sig perl-Event-Lib-1.03-3.fc10 (build/make) kwizart,perl-sig perl-PDF-API2-0.69-5.fc10 (patch_fuzz) bjohnson,perl-sig perl-RRD-Simple-1.43-3.fc9 (build/make) cweyl,perl-sig perl-SVN-Mirror-0.73-3.fc9 (build/make) iburrell,perl-sig perl-Test-AutoBuild-1.2.2-3.fc9 (build/make) berrange perl-bioperl-1.5.2_102-12.fc9 (patch_fuzz) alexlan,perl-sig petitboot-0.0.1-7.fc8 (build/make) dwmw2,jwboyer phpldapadmin-1.1.0.5-1.fc9 (patch_fuzz) buc pic2aa-0.2.1-3.fc9 (build/make) kurzawa piklab-0.15.3-1.fc10 (patch_fuzz) chitlesh pinot-0.87-1.fc10 (build/make) drago01 planet-2.0-5.fc9 (patch_fuzz) richdawe plexus-runtime-builder-1.0-0.2.a9.1.5.fc10 (build/make) dbhole plexus-xmlrpc-1.0-0.2.b4.2.9.fc10 (patch_fuzz) dbhole pmount-0.9.17-2.fc9 (patch_fuzz) pertusus,jpmahowa pnm2ppa-1.04-15.fc9 (patch_fuzz) twaugh poker-network-1.6.0-1.fc10 (patch_fuzz) xulchris polyxmass-bin-0.9.7-2.fc8 (build/make) awjb pspp-0.6.0-7.fc10 (build/make) mcepl pstoedit-3.45-3.fc10 (patch_fuzz) denis pyclutter-0.6.2-2.fc9 (build/make) allisson pysvn-1.5.3-1.fc10 (patch_fuzz) ravenoak python-TurboMail-2.1-3.fc9 (build/make) lmacken,toshio,fschwarz python-durus-3.5-3.fc7 (build/make) rakesh python-imaging-1.1.6-10.fc10 (patch_fuzz) jamatos,jgranado python-simpletal-4.1-5.fc7 (build/make) python-tgcaptcha-0.11-3.fc10 (build/make) lmacken,toshio,fschwarz python-turboflot-0.1.1-1.fc10 (build/make) lmacken,toshio,fschwarz pywbxml-0.1-3.fc9 (build/make) awjb pyzor-0.4.0-11.fc7 (build/make) ixs qemu-0.9.1-10.fc10 (patch_fuzz) dwmw2 qgo-1.5.4r2-1.fc9 (build/make) kaboom qpidc-0.3.693548-1.fc10 (build/make) aconway,nsantos qt3-3.3.8b-14.fc10 (patch_fuzz) than,rdieter,kkofler quake3-1.34-0.9.rc4.fc9 (patch_fuzz) laxathom queuegraph-1.1-3.fc9 (patch_fuzz) bjohnson rafkill-1.2.3-1.fc10 (patch_fuzz) limb rasqal-0.9.15-1.fc9 (build/make) thomasvs rsh-0.17-50.fc10 (patch_fuzz) atkac ruby-bdb-0.6.0-1.fc7 (build/make) errr ruby-rpm-1.2.3-4.fc9 (build/make) lutter,stahnma scim-skk-0.5.2-8.fc6 (build/make) ryo sdcc-2.6.0-12.fc9 (build/make) konradm,jwrdegoede seamonkey-1.1.11-1.fc9 (patch_fuzz) gecko-maint,kengert seq24-0.8.7-13.fc10 (patch_fuzz) green slim-1.3.0-5.fc10 (patch_fuzz) afb smarteiffel-2.3-2.fc9 (build/make) gemi squid-3.0.STABLE7-1.fc10 (patch_fuzz) jskala,jsteffan,mnagy,hno,jskala straw-0.27-12.fc9 (build/make) subhodip sundials-2.3.0-6.fc9 (build/make) jpye sysvinit-2.86-24 (patch_fuzz) notting tachyon-0.98-0.6.20070319.fc9 (build/make) rathann tanukiwrapper-3.2.3-2.2.fc10 (patch_fuzz) dbhole,devrim,jmrodri tcltls-1.5.0-16.fc9 (patch_fuzz) tjikkun thttpd-2.25b-16.fc9 (patch_fuzz) thias thunderbird-2.0.0.14-1.fc10 (patch_fuzz) gecko-maint tiger-3.2.1-8.fc9 (patch_fuzz) abompard time-1.7-33.fc9 (build/make) rrakus tla-1.3.5-5.fc9 (build/make) rishi uw-imap-2007b-1.fc10 (patch_fuzz) rdieter,jorton valgrind-3.3.0-3 (patch_fuzz) jakub vnc-4.1.2-34.fc10 (patch_fuzz) atkac vtk-5.0.4-21.fc9 (patch_fuzz) athimm,orion w3c-libwww-5.4.1-0.10.20060206cvs.fc9 (patch_fuzz) awjb w3lib-1.6-3.fc10 (build/make) pertusus wammu-0.28-1.fc10 (build/make) laxathom wcstools-3.7.0-2.fc9 (build/make) sergiopr,mmahut wesnoth-1.4.4-1.fc10 (build/make) limb,wtogami wp_tray-0.5.3-7.fc9 (patch_fuzz) denis x3270-3.3.6-5.fc9 (patch_fuzz) karsten xautolock-2.2-5.fc9 (build/make) ianweller xdelta-1.1.4-3.fc9 (patch_fuzz) atkac xdoclet-1.2.3-9.2.fc10 (patch_fuzz) mwringe xdx-2.4-2.fc9 (build/make) bjensen,sindrepb,sconklin xfce4-panel-4.4.2-4.fc9 (patch_fuzz) kevin,cwickert xmoto-0.4.2-1.fc9 (patch_fuzz) limb xscorch-0.2.0-12.fc8 (build/make) mgarski yoltia-0.22.1-2.fc9 (build/make) kurzawa ypserv-2.19-9.fc9 (patch_fuzz) vcrhonek zsh-4.3.4-8.fc9 (patch_fuzz) james With bugs filed: 4 ---------------------------------- gcl-2.6.7-18.fc9 [u'440913 ASSIGNED'] (build/make) gemi,green gtk-sharp-1.0.10-12.fc7 [u'434373 ASSIGNED'] (build/make) pfj libFoundation-1.1.3-11.fc9 [u'440564 ASSIGNED'] (build/make) athimm qtiplot-0.9-8.fc9 [u'434100 ASSIGNED'] (build/make) frankb ---------------------------------- Packages by owner: abompard: amarok,libkexif,librra,tiger aconway: qpidc adrian: bwbar,gmpc,jhead afb: slim afsilva: nethogs agk: lvm2 ajax: libpciaccess akahl: bmpx alcapcom: eclipse-rpm-editor alexlan: perl-bioperl allisson: pyclutter ascii: fish athimm: arpack,libFoundation,vtk atkac: dump,mtools,rsh,vnc,xdelta ausil: knetworkmanager,mysql-gui-tools awjb: WindowMaker,atitvout,dosbox,gimmix,koffice-langpack,libAfterImage,libnasl,librra,nessus-core,openal,polyxmass-bin,pywbxml,w3c-libwww bellet: SimGear berrange: perl-Test-AutoBuild bjensen: linpsk,xdx bjohnson: goocanvas,mailgraph,pdfedit,perl-PDF-API2,queuegraph bkoz: boost bmarzins: lvm2 bmr: lvm2 bpepple: evolution-brutus,libepc buc: gtk-gnutella,phpldapadmin cagney: frysk candyz: gcin chitlesh: LabPlot,LabPlot,piklab colding: evolution-brutus corsepiu: lib3ds cr33dog: fontypython cweyl: perl-Catalyst-Plugin-ConfigLoader,perl-DBIx-Class,perl-RRD-Simple cwickert: xfce4-panel danken: bidiv davidz: libgnomecups dbhole: jpackage-utils,plexus-runtime-builder,plexus-xmlrpc,tanukiwrapper dchen: UnihanDb deji: atlas,atlas denis: galeon,pstoedit,wp_tray devrim: classpathx-jaf,tanukiwrapper dledford: mdadm drago01: hardinfo,linkage,pinot dwmw2: bluez-utils,hfsutils,linux-atm,petitboot,qemu dwysocha: lvm2 edhill: itpp,libmatheval,osiv eitch: ode ensc: ip-sentinel,mimetic errr: fluxstyle,pekwm,ruby-bdb firewing: lybniz fnasser: geronimo-specs fonts-sig: fonttools,fontypython,libXfontcache frankb: qtiplot fschwarz: python-TurboMail,python-tgcaptcha,python-turboflot gecko-maint: seamonkey,thunderbird gemi: bigloo,gcl,smarteiffel ghenry: cpan2rpm green: ardour,gcl,seq24 hadess: bluez-utils hardaker: dnssec-tools hno: squid hubbitus: mysql-gui-tools huzaifas: dia,dia,gnumeric,gnumeric ianweller: xautolock iburrell: perl-SVN-Mirror ifoox: ht2html ixs: pyzor jakub: compat-gcc-34,valgrind jamatos: PyX,PyX,ifplugd,python-imaging james: zsh jgranado: python-imaging jhrozek: dwdiff jkratoch: libunwind jmagne: coolkey jmrodri: tanukiwrapper jnovy: nedit joost: lazarus jorge: lock-keys-applet jorton: mod_python,uw-imap jpmahowa: pmount jpye: sundials jreznik: kdemultimedia jskala: mgetty,mgetty,netatalk,squid,squid jsteffan: squid jwboyer: petitboot jwrdegoede: KoboDeluxe,ardour,arm-gp2x-linux-gcc,ode,sdcc kaboom: qgo karsten: autoconf,automake15,x3270 kasal: brltty,groff,pcre,perl-Crypt-SSLeay kengert: seamonkey kevin: xfce4-panel kkofler: kdemultimedia,qt3 konradm: sdcc kurzawa: pic2aa,yoltia kwizart: elektra,oyranos,perl-Event-Lib kzak: lockdev langel: azureus,azureus laxathom: lib3ds,quake3,wammu limb: archivemail,nagi,rafkill,wesnoth,xmoto liquidat: knetworkmanager lkundrak: pcre lmacken: bodhi,python-TurboMail,python-tgcaptcha,python-turboflot ltinkl: kdemultimedia,knetworkmanager lucilanga: evolution-rss lutter: ruby-rpm luya: gdesklets lvm-team: lvm2 masahase: pards mbarnes: evolution-sharp,gnome-python2-extras mbroz: lvm2 mcepl: pspp mclasen: glade2 mef: kaffeine mfleming: asylum,mailgraph mgarski: xscorch mmahut: extrema,wcstools mmaslano: anacron,perl-Crypt-SSLeay mmcgrath: knetworkmanager,nagios mnagy: squid mornfall: lvm2 mpeters: PyX mschwendt: audacious-plugin-fc mtasaka: astyle mwiriadi: mediatomb mwringe: maven-wagon,xdoclet ngompa: oggconvert nhosoi: fedora-ds-base nkinder: fedora-ds-base notting: sysvinit nsantos: qpidc oliver: fish orion: hdf,vtk overholt: eclipse-checkstyle,eclipse-gef,eclipse-mylyn,eclipse-rpm-editor owentl: gdesklets pcheung: jakarta-commons-net perl-sig: cpan2rpm,perl-Catalyst-Plugin-ConfigLoader,perl-DBIx-Class,perl-Event-Lib,perl-PDF-API2,perl-RRD-Simple,perl-SVN-Mirror,perl-bioperl pertusus: a2ps,cernlib,cernlib-g77,elektra,fetchmail,fltk,hdf,pmount,w3lib petersen: emacspeak,gcin pfj: gtk-sharp,mx pmachata: boost,ltrace,make pmuldoon: frysk pwouters: lrmi rakesh: ifplugd,python-durus rathann: dx,freefem++,gabedit,tachyon ravenoak: pysvn rdieter: akode,amarok,fltk,gtk+,k3b,kaffeine,kdemultimedia,knetworkmanager,libkexif,qt3,uw-imap remi: ocsinventory-agent,perl-Apache2-SOAP richdawe: planet rishi: astyle,tla rmeggins: fedora-ds-base rmyers: eclipse-checkstyle,eclipse-egit rnorwood: perl-Crypt-SSLeay robert: perl-CGI-SpeedyCGI robmv: eclipse-subclipse romal: nagios roozbeh: fonttools rrakus: indent,k3b,time rrelyea: coolkey rvinyard: bit,conexus,conexusmm,papyrus ryo: scim-skk sconklin: linpsk,xdx scop: kaffeine sebastian: nagios seg: openjpeg sergiopr: wcstools sgrubb: aide silfreed: ale sindrepb: linpsk,muine-scrobbler,xdx somlo: aumix splinux: gdmap,gstm spot: PyAmanith,R-RScaLAPACK,SimGear,alienarena,amanith,gambas ssp: libXTrap,libXfontcache stahnma: ruby-rpm steved: nfs4-acl-tools subhodip: straw swagiaal: frysk szpak: isomaster terjeros: extrema than: isdn4k-utils,kdemultimedia,qt3 thias: thttpd thl: gweled thomasvs: ladspa,rasqal timj: alsa-firmware timlau: bodhi tjikkun: tcltls tmoertel: R-Matrix tnorth: LabPlot,avr-binutils,avr-gcc toshio: bodhi,python-TurboMail,python-tgcaptcha,python-turboflot trondd: avr-binutils,avr-gcc tuxbrewr: akode,amarok,k3b,kdemultimedia twaugh: a2ps,pnm2ppa uwog: abiword vcrhonek: expect,fetchmail,ypserv walters: bigboard wart: bsd-games,cyphesis wtogami: nagios,wesnoth xris: lineak-xosdplugin xulchris: poker-network -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From mzerqung at 0pointer.de Wed Sep 24 12:33:34 2008 From: mzerqung at 0pointer.de (Lennart Poettering) Date: Wed, 24 Sep 2008 14:33:34 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <48D9B3D1.70805@gmail.com> References: <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <20080922180001.GA8379@sonata.rednote.net> <20080923001815.GE21642@tango.0pointer.de> <48D85D71.4020503@gmail.com> <20080923130529.GH7596@tango.0pointer.de> <48D950BB.3030103@gmail.com> <20080923231312.GA338@tango.0pointer.de> <48D9B3D1.70805@gmail.com> Message-ID: <20080924123334.GA18824@tango.0pointer.de> On Tue, 23.09.08 22:28, Les Mikesell (lesmikesell at gmail.com) wrote: >> And again, that's the way *I* think it makes the most sense. > > If you haven't, give freenx/NX a try, floating your running session among > displays at work, perhaps a wireless laptop, and pick them up from home > with everything still running. And try it with several people sharing a > machine. You might get used to the concept that your devices are really > not that closely coupled. Or perhaps at least that your session isn't tied > to the local console. X never intended it to be, but before freenx it > wasn't that great remotely. If you use a terminal client, then audio should be forwarded to it. Audio should always be sent to the same machine that shows you the video. Audio is part of the workplace, not the server. From the terminal client to the terminal server we send keyboard, mouse, audio recording. From the terminal server to the terminal client we send audio playback and screen contents. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4 From limb at jcomserv.net Wed Sep 24 12:37:45 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Wed, 24 Sep 2008 07:37:45 -0500 (CDT) Subject: Fedora rawhide rebuild in mock status 2008-09-23 x86_64 In-Reply-To: <20080924122036.GA28400@mock.linuxdev.us.dell.com> References: <20080924122036.GA28400@mock.linuxdev.us.dell.com> Message-ID: <36504.198.175.55.5.1222259865.squirrel@mail.jcomserv.net> > Fedora Rawhide-in-Mock Build Results for x86_64 > using the rawhide tree of Tuesday, 2008-10-23. > > This is not a full rebuild of everything, merely a rebuild of packages > failing to build over the last few weeks. Failures here will cause > new bugzilla bugs to be created, which will block the 'F10FTBFS' bug. > My hope is that we can resolve all these before the Fedora 10 Release > Candidate. > > 122 of these failures are due to patch fuzz. Each of those should be > reviewed to ensure upstream has not already fixed the problem the > patch addressed, either by applying the patch or by fixing it in > another way. If the problem persists, please rebase the patch to the > current source code, so it applies without fuzz, and forward your > patch to the upstream package maintainer. > > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > Total packages: 6191 > Number failed to build: 312 > Number expected to fail due to ExclusiveArch or ExcludeArch: 34 > Leaving: 278 > > Of those expected to have worked... > Without a bug filed: 275 > ---------------------------------- > KoboDeluxe-0.5.1-2.fc9 (build/make) jwrdegoede > LabPlot-1.6.0.1-1.fc10 (patch_fuzz) chitlesh,chitlesh,tnorth > PyAmanith-0.3.35-2.fc9 (patch_fuzz) spot > PyX-0.10-4.fc9 (patch_fuzz) jamatos,mpeters,jamatos > PythonCard-0.8.2-1.fc10 (build/make) mmahut > R-Matrix-0.999375-4.fc9 (build/make) tmoertel > R-RScaLAPACK-0.5.1-15.fc10 (patch_fuzz) spot > SimGear-1.0.0-4.fc10 (patch_fuzz) spot,bellet > UnihanDb-5.1.0-4.fc10 (build/make) dchen > WindowMaker-0.92.0-18.fc9 (patch_fuzz) awjb > a2ps-4.14-5.fc10 (patch_fuzz) twaugh,pertusus > abiword-2.6.4-7.fc10 (build/make) uwog > aide-0.13.1-4 (patch_fuzz) sgrubb > akode-2.0.2-5.fc9 (patch_fuzz) rdieter,tuxbrewr > ale-0.9.0.1-1.fc10 (patch_fuzz) silfreed > alienarena-7.10-1.fc10 (patch_fuzz) spot > alsa-firmware-1.0.17-1.fc10 (build/make) timj > amanith-0.3-9.fc9 (patch_fuzz) spot > amarok-1.90-1.fc10 (build/make) abompard,rdieter,tuxbrewr > anacron-2.3-61.fc10 (patch_fuzz) mmaslano > archivemail-0.7.2-1.fc9 (patch_fuzz) limb > ardour-2.4.1-1.fc9 (patch_fuzz) green,jwrdegoede > arm-gp2x-linux-gcc-4.1.2-8.fc9 (build/make) jwrdegoede > arpack-2.1-7.fc9 (build/make) athimm > astyle-1.21-6.fc8 (build/make) rishi,mtasaka > asylum-0.2.3-3.fc9 (build/make) mfleming > audacious-plugin-fc-0.2-7 (build/make) mschwendt > aumix-2.8-17.fc9 (patch_fuzz) somlo > autoconf-2.62-5.fc10 (patch_fuzz) karsten > automake15-1.5-23 (patch_fuzz) karsten > avr-binutils-2.18-2.fc9 (patch_fuzz) tnorth,trondd > avr-gcc-4.1.2-6.fc9 (build/make) tnorth,trondd > axis-1.2.1-4.fc10 (build/make) pcheung > azureus-3.0.4.2-16.fc10 (build/make) langel,langel > bidiv-1.5-6.fc9 (build/make) danken > bigboard-0.6.2-2.fc10 (build/make) walters > bigloo-3.1a-1.fc10 (patch_fuzz) gemi > bit-0.4.1-3.fc9 (build/make) rvinyard > bluez-utils-3.36-2.fc10 (build/make) dwmw2,hadess > bmpx-0.40.14-5.fc9 (patch_fuzz) akahl > bodhi-0.5.0-7.fc9 (build/make) lmacken,toshio,timlau > boost-1.34.1-16.fc10 (patch_fuzz) bkoz,pmachata > brltty-3.9-2.2.fc9 (build/make) kasal > bsd-games-2.17-23.fc9 (patch_fuzz) wart > bwbar-1.2.3-2 (patch_fuzz) adrian > cernlib-2006-30.fc10 (build/make) pertusus > cernlib-g77-2006-30.fc10 (build/make) pertusus > classpathx-jaf-1.0-12.fc10 (build/make) devrim > compat-gcc-34-3.4.6-9 (patch_fuzz) jakub > conexus-0.5.3-4.fc9 (build/make) rvinyard > conexusmm-0.5.0-3.fc7 (build/make) rvinyard > coolkey-1.1.0-6.fc9 (build/make) rrelyea,jmagne > cpan2rpm-2.028-2.fc8.1 (build/make) ghenry,perl-sig > cyphesis-0.5.16-3.fc10 (build/make) wart > dia-0.96.1-6.fc10 (patch_fuzz) huzaifas,huzaifas > dnssec-tools-1.4.1-2.fc10 (build/make) hardaker > docbook-utils-0.6.14-14.fc10 (build/make) ovasik > dosbox-0.72-4.fc9 (build/make) awjb > dump-0.4b41-8.fc10 (patch_fuzz) atkac > dwdiff-1.4-1.fc10 (build/make) jhrozek > dx-4.4.4-6.fc10 (patch_fuzz) rathann > eclipse-checkstyle-4.0.1-10.fc9 (build/make) rmyers,overholt > eclipse-egit-0.3.1-0.fc9 (build/make) rmyers > eclipse-gef-3.3.0-2.fc9 (build/make) overholt > eclipse-mylyn-3.0.1-2.fc10 (build/make) overholt > eclipse-rpm-editor-0.4.0-1.fc10 (build/make) alcapcom,overholt > eclipse-subclipse-1.2.4-11.fc9 (patch_fuzz) robmv > elektra-0.6.10-6.fc9 (build/make) pertusus,kwizart > emacspeak-26-3.fc8 (patch_fuzz) petersen > evolution-brutus-1.2.17-1.fc10 (build/make) bpepple,colding > evolution-rss-0.1.1-2.fc10 (build/make) lucilanga > evolution-sharp-0.17.4-3.fc10 (build/make) mbarnes > expect-5.43.0-14.fc10 (patch_fuzz) vcrhonek > extrema-4.3.6-1.fc10 (build/make) terjeros,mmahut > fedora-ds-base-1.1.1-2.fc10 (build/make) rmeggins,nkinder,nhosoi > fetchmail-6.3.8-7.fc10 (patch_fuzz) vcrhonek,pertusus > firewalk-5.0-2.fc9 (build/make) sindrepb > fish-1.23.0-2.fc9 (build/make) ascii,oliver > fltk-1.1.8-1.fc9 (patch_fuzz) rdieter,pertusus > fluxstyle-1.0.1-2.fc7 (build/make) errr > fonttools-2.0-0.11.20060223cvs.fc7 (unpackaged_files/python-egg-info?) > roozbeh,fonts-sig > fontypython-0.2.0-6.fc7 (build/make) cr33dog,fonts-sig > freefem++-2.24-2.fc9 (build/make) rathann > frysk-0.4-0.fc10 (build/make) cagney,pmuldoon,swagiaal > gabedit-2.1.7-1.fc10 (build/make) rathann > galeon-2.0.6-1.fc10 (patch_fuzz) denis > gauche-0.8.13-2.fc10 (build/make) gemi > gauche-gl-0.4.4-3.fc9 (build/make) gemi > gauche-gtk-0.4.1-17.fc9 (build/make) gemi > gcin-1.4.2-2.fc10 (patch_fuzz) candyz,petersen > gcombust-0.1.55-13 (build/make) thias > gdesklets-0.36-1.fc9 (unpackaged_files/python-egg-info?) luya,owentl > gdmap-0.7.5-6.fc6 (build/make) splinux > geronimo-specs-1.0-2.M2.fc10 (build/make) fnasser > gimmix-0.4.2-3.fc9 (build/make) awjb > glade2-2.12.2-2.fc9 (build/make) mclasen > gmpc-0.15.5.0-3.fc9 (patch_fuzz) adrian > gnome-python2-extras-2.19.1-17.fc9 (patch_fuzz) mbarnes > gnome-specimen-0.3-2.fc10 (unpackaged_files/python-egg-info?) splinux > gnumeric-1.8.2-2.fc9 (patch_fuzz) huzaifas,huzaifas > goocanvas-0.10-1.fc10 (build/make) bjohnson > groff-1.18.1.4-14.fc9 (patch_fuzz) kasal > gstm-1.2-6.fc7 (build/make) splinux > gtk+-1.2.10-61.fc9 (patch_fuzz) rdieter > gtk-gnutella-0.96.5-2.fc10 (build/make) buc > gweled-0.7-11.1 (patch_fuzz) thl > hardinfo-0.4.2.3-6.fc10 (build/make) drago01 > hdf-4.2r3-2.fc9 (build/make) orion,pertusus > hfsutils-3.2.6-14.fc9 (patch_fuzz) dwmw2 > ht2html-2.0-5.fc6 (build/make) ifoox > ifplugd-0.28-11.fc9 (build/make) jamatos,rakesh > indent-2.2.10-1.fc9 (patch_fuzz) rrakus > ip-sentinel-0.12-11.fc9 (build/make) ensc > isdn4k-utils-3.2-58.fc9 (patch_fuzz) than > isomaster-1.3.3-1.fc10 (patch_fuzz) szpak > itpp-4.0.0-2.fc9 (build/make) edhill > jabbin-2.0-0.6.beta2a.fc9 (build/make) > jakarta-commons-net-1.4.1-4.2.fc10 (patch_fuzz) pcheung > jhead-2.82-1.fc9 (patch_fuzz) adrian > jpackage-utils-1.7.5-1.5.fc10 (patch_fuzz) dbhole > k3b-1.0.5-5.fc10 (build/make) rrakus,rdieter,tuxbrewr > kaffeine-0.8.7-2.fc10 (build/make) rdieter,scop,mef > kdemultimedia-4.1.1-1.fc10 (build/make) > than,rdieter,kkofler,tuxbrewr,ltinkl,jreznik > knetworkmanager-0.7-0.5.20080715svn.fc10 (build/make) > ausil,rdieter,mmcgrath,liquidat,ltinkl > koffice-langpack-1.6.3-1.fc8 (build/make) awjb > ladspa-1.12-9.fc9 (build/make) thomasvs > lazarus-0.9.24-4.fc10 (patch_fuzz) joost > lib3ds-1.3.0-3.fc10 (build/make) corsepiu,laxathom > libAfterImage-1.15-4.fc9 (patch_fuzz) awjb > libXTrap-1.0.0-6.fc10 (build/make) ssp > libXfontcache-1.0.4-5.fc9 (build/make) ssp,fonts-sig > libepc-0.3.5-2.fc10 (build/make) bpepple > libgii-1.0.2-6.fc9 (build/make) kwizart > libgnomecups-0.2.3-3.fc9 (patch_fuzz) davidz > libkexif-0.2.5-4.fc9 (patch_fuzz) abompard,rdieter > libmatheval-1.1.5-2.fc9 (patch_fuzz) edhill > libnasl-2.2.10-5.fc9 (patch_fuzz) awjb > libpciaccess-0.10.3-2.fc9 (patch_fuzz) ajax > librra-0.11.1-1.fc9 (build/make) awjb,abompard > libstroke-0.5.1-17.fc9 (build/make) chitlesh > libunwind-0.99-0.5.frysk20070405cvs.fc9 (build/make) jkratoch > libzzub-0.2.3-12.fc9 (patch_fuzz) > lineak-xosdplugin-0.9-2.fc6 (build/make) xris > linkage-0.2.0-2.fc10 (build/make) drago01 > linpsk-0.9-3.fc9 (build/make) bjensen,sindrepb,sconklin > linux-atm-2.5.0-5 (build/make) dwmw2 > lock-keys-applet-1.0-14.fc9 (build/make) jorge > lockdev-1.0.1-12.fc9.1 (patch_fuzz) kzak > lout-3.36-2.fc9 (build/make) spot > ltrace-0.5-11.45svn.fc10 (patch_fuzz) pmachata > lvm2-2.02.39-3.fc10 (build/make) > lvm-team,agk,mornfall,bmr,mbroz,dwysocha,bmarzins > lybniz-1.3.2-1.fc9 (patch_fuzz) firewing > mailgraph-1.14-2.fc9 (patch_fuzz) bjohnson,mfleming > make-3.81-12.fc9 (patch_fuzz) pmachata > maven-wagon-1.0-0.1.a5.3.3.fc10 (build/make) mwringe > mdadm-2.6.7-1.fc10 (patch_fuzz) dledford > mediatomb-0.11.0-1.fc9 (build/make) mwiriadi > mgetty-1.1.36-1.fc10 (patch_fuzz) jskala,jskala > mimetic-0.9.3-2.fc8 (build/make) ensc > mod_python-3.3.1-7 (build/make) jorton > mtools-3.9.11-4.fc9 (patch_fuzz) atkac > mx-2.0.6-3 (unpackaged_files/python-egg-info?) pfj > mysql-connector-java-3.1.12-6.fc10 (build/make) ifoox > mysql-gui-tools-5.0r12-8.fc9 (patch_fuzz) ausil,hubbitus > nagi-2.06-5.fc9 (patch_fuzz) limb > nagios-3.0.3-6.fc10 (patch_fuzz) mmcgrath,wtogami,romal,sebastian > nedit-5.5-18.fc9 (patch_fuzz) jnovy > nessus-core-2.2.10-4.fc9 (patch_fuzz) awjb > netatalk-2.0.3-19.fc9 (build/make) jskala > nethogs-0.7-3.20080627cvs.fc10 (build/make) afsilva > nfs4-acl-tools-0.3.2-2.fc9 (patch_fuzz) steved > ocsinventory-agent-0.0.9.2-1.fc10 (patch_fuzz) remi > ode-0.9-4.fc9 (patch_fuzz) jwrdegoede,eitch > oggconvert-0.3.0-14.fc9 (unpackaged_files/python-egg-info?) ngompa > openal-0.0.9-0.15.20060204cvs.fc9 (patch_fuzz) awjb > openjpeg-1.3-2.fc9 (patch_fuzz) seg > osiv-2.0.0-0.4.beta.fc9 (build/make) edhill > oyranos-0.1.7-11.fc9 (patch_fuzz) kwizart > papyrus-0.7.1-3.fc9 (build/make) rvinyard > pards-0.4-6.fc9 (build/make) masahase > pcre-7.3-4.fc10 (patch_fuzz) kasal,lkundrak > pdfedit-0.4.1-1.fc10 (patch_fuzz) bjohnson > pekwm-0.1.5-5.fc7 (build/make) errr > perl-Apache2-SOAP-0.73-1.fc10 (build/make) remi > perl-CGI-SpeedyCGI-2.22-2.fc10 (build/make) robert > perl-Catalyst-Plugin-ConfigLoader-0.20-1.fc10 (build/make) cweyl,perl-sig > perl-Crypt-SSLeay-0.57-7.fc9 (patch_fuzz) kasal,rnorwood,mmaslano > perl-DBIx-Class-0.08010-6.fc10 (patch_fuzz) cweyl,perl-sig > perl-Event-Lib-1.03-3.fc10 (build/make) kwizart,perl-sig > perl-PDF-API2-0.69-5.fc10 (patch_fuzz) bjohnson,perl-sig > perl-RRD-Simple-1.43-3.fc9 (build/make) cweyl,perl-sig > perl-SVN-Mirror-0.73-3.fc9 (build/make) iburrell,perl-sig > perl-Test-AutoBuild-1.2.2-3.fc9 (build/make) berrange > perl-bioperl-1.5.2_102-12.fc9 (patch_fuzz) alexlan,perl-sig > petitboot-0.0.1-7.fc8 (build/make) dwmw2,jwboyer > phpldapadmin-1.1.0.5-1.fc9 (patch_fuzz) buc > pic2aa-0.2.1-3.fc9 (build/make) kurzawa > piklab-0.15.3-1.fc10 (patch_fuzz) chitlesh > pinot-0.87-1.fc10 (build/make) drago01 > pl-5.6.57-2.fc10 (build/make) gemi,mef > planet-2.0-5.fc9 (patch_fuzz) richdawe > plexus-runtime-builder-1.0-0.2.a9.1.5.fc10 (build/make) dbhole > plexus-xmlrpc-1.0-0.2.b4.2.9.fc10 (patch_fuzz) dbhole > pmount-0.9.17-2.fc9 (patch_fuzz) pertusus,jpmahowa > pnm2ppa-1.04-15.fc9 (patch_fuzz) twaugh > poker-network-1.6.0-1.fc10 (patch_fuzz) xulchris > polyxmass-bin-0.9.7-2.fc8 (build/make) awjb > pspp-0.6.0-7.fc10 (build/make) mcepl > pstoedit-3.45-3.fc10 (patch_fuzz) denis > pyclutter-0.6.2-2.fc9 (build/make) allisson > pysvn-1.5.3-1.fc10 (patch_fuzz) ravenoak > python-TurboMail-2.1-3.fc9 (build/make) lmacken,toshio,fschwarz > python-durus-3.5-3.fc7 (build/make) rakesh > python-imaging-1.1.6-10.fc10 (patch_fuzz) jamatos,jgranado > python-reportlab-2.1-2.fc9 (build/make) bpepple > python-simpletal-4.1-5.fc7 (build/make) > python-tgcaptcha-0.11-3.fc10 (build/make) lmacken,toshio,fschwarz > python-turboflot-0.1.1-1.fc10 (build/make) lmacken,toshio,fschwarz > pywbxml-0.1-3.fc9 (build/make) awjb > pyzor-0.4.0-11.fc7 (build/make) ixs > qemu-0.9.1-10.fc10 (patch_fuzz) dwmw2 > qgo-1.5.4r2-1.fc9 (build/make) kaboom > qpidc-0.3.693548-1.fc10 (build/make) aconway,nsantos > qt3-3.3.8b-14.fc10 (patch_fuzz) than,rdieter,kkofler > quake3-1.34-0.9.rc4.fc9 (patch_fuzz) laxathom > queuegraph-1.1-3.fc9 (patch_fuzz) bjohnson > rafkill-1.2.3-1.fc10 (patch_fuzz) limb > rasqal-0.9.15-1.fc9 (build/make) thomasvs > rsh-0.17-50.fc10 (patch_fuzz) atkac > ruby-bdb-0.6.0-1.fc7 (build/make) errr > ruby-rpm-1.2.3-4.fc9 (build/make) lutter,stahnma > scim-skk-0.5.2-8.fc6 (build/make) ryo > sdcc-2.6.0-12.fc9 (build/make) konradm,jwrdegoede > seamonkey-1.1.11-1.fc9 (patch_fuzz) gecko-maint,kengert > seq24-0.8.7-13.fc10 (patch_fuzz) green > slim-1.3.0-5.fc10 (patch_fuzz) afb > smarteiffel-2.3-2.fc9 (build/make) gemi > squid-3.0.STABLE7-1.fc10 (patch_fuzz) jskala,jsteffan,mnagy,hno,jskala > straw-0.27-12.fc9 (build/make) subhodip > sundials-2.3.0-6.fc9 (build/make) jpye > sysvinit-2.86-24 (patch_fuzz) notting > tachyon-0.98-0.6.20070319.fc9 (build/make) rathann > tanukiwrapper-3.2.3-2.2.fc10 (patch_fuzz) dbhole,devrim,jmrodri > tclparser-1.4-4.20061030cvs.fc9 (build/make) wart > tcltls-1.5.0-16.fc9 (patch_fuzz) tjikkun > thttpd-2.25b-16.fc9 (patch_fuzz) thias > thunderbird-2.0.0.14-1.fc10 (patch_fuzz) gecko-maint > tiger-3.2.1-8.fc9 (patch_fuzz) abompard > time-1.7-33.fc9 (build/make) rrakus > tla-1.3.5-5.fc9 (build/make) rishi > tomcat5-5.5.26-1.5.fc10 (build/make) devrim,devrim > uw-imap-2007b-1.fc10 (patch_fuzz) rdieter,jorton > valgrind-3.3.0-3 (patch_fuzz) jakub > vnc-4.1.2-34.fc10 (patch_fuzz) atkac > vtk-5.0.4-21.fc9 (patch_fuzz) athimm,orion > w3c-libwww-5.4.1-0.10.20060206cvs.fc9 (patch_fuzz) awjb > w3lib-1.6-3.fc10 (build/make) pertusus > wammu-0.28-1.fc10 (build/make) laxathom > wcstools-3.7.0-2.fc9 (build/make) sergiopr,mmahut > wesnoth-1.4.4-1.fc10 (build/make) limb,wtogami > wp_tray-0.5.3-7.fc9 (patch_fuzz) denis > x3270-3.3.6-5.fc9 (patch_fuzz) karsten > xautolock-2.2-5.fc9 (build/make) ianweller > xcb-proto-1.2-2.fc10 (unpackaged_files/python-egg-info?) ajax > xdelta-1.1.4-3.fc9 (patch_fuzz) atkac > xdoclet-1.2.3-9.2.fc10 (patch_fuzz) mwringe > xdx-2.4-2.fc9 (build/make) bjensen,sindrepb,sconklin > xfce4-panel-4.4.2-4.fc9 (patch_fuzz) kevin,cwickert > xlhtml-0.5-8.fc9 (build/make) abompard > xmms-cdread-0.14-13.fc9 (build/make) jsoeterb > xmoto-0.4.2-1.fc9 (patch_fuzz) limb > xscorch-0.2.0-12.fc8 (build/make) mgarski > yoltia-0.22.1-2.fc9 (build/make) kurzawa > ypserv-2.19-9.fc9 (patch_fuzz) vcrhonek > zsh-4.3.4-8.fc9 (patch_fuzz) james > > With bugs filed: 3 > ---------------------------------- > gtk-sharp-1.0.10-12.fc7 [u'434373 ASSIGNED'] > (unpackaged_files/python-egg-info?) pfj > libFoundation-1.1.3-11.fc9 [u'440564 ASSIGNED'] (build/make) athimm > qtiplot-0.9-8.fc9 [u'434100 ASSIGNED'] (build/make) frankb > > > > > ---------------------------------- > Packages by owner: > abompard: amarok,libkexif,librra,tiger,xlhtml > > aconway: qpidc > > adrian: bwbar,gmpc,jhead > > afb: slim > > afsilva: nethogs > > agk: lvm2 > > ajax: libpciaccess,xcb-proto > > akahl: bmpx > > alcapcom: eclipse-rpm-editor > > alexlan: perl-bioperl > > allisson: pyclutter > > ascii: fish > > athimm: arpack,libFoundation,vtk > > atkac: dump,mtools,rsh,vnc,xdelta > > ausil: knetworkmanager,mysql-gui-tools > > awjb: > WindowMaker,dosbox,gimmix,koffice-langpack,libAfterImage,libnasl,librra,nessus-core,openal,polyxmass-bin,pywbxml,w3c-libwww > > bellet: SimGear > > berrange: perl-Test-AutoBuild > > bjensen: linpsk,xdx > > bjohnson: goocanvas,mailgraph,pdfedit,perl-PDF-API2,queuegraph > > bkoz: boost > > bmarzins: lvm2 > > bmr: lvm2 > > bpepple: evolution-brutus,libepc,python-reportlab > > buc: gtk-gnutella,phpldapadmin > > cagney: frysk > > candyz: gcin > > chitlesh: LabPlot,LabPlot,libstroke,piklab > > colding: evolution-brutus > > corsepiu: lib3ds > > cr33dog: fontypython > > cweyl: perl-Catalyst-Plugin-ConfigLoader,perl-DBIx-Class,perl-RRD-Simple > > cwickert: xfce4-panel > > danken: bidiv > > davidz: libgnomecups > > dbhole: jpackage-utils,plexus-runtime-builder,plexus-xmlrpc,tanukiwrapper > > dchen: UnihanDb > > denis: galeon,pstoedit,wp_tray > > devrim: classpathx-jaf,tanukiwrapper,tomcat5,tomcat5 > > dledford: mdadm > > drago01: hardinfo,linkage,pinot > > dwmw2: bluez-utils,hfsutils,linux-atm,petitboot,qemu > > dwysocha: lvm2 > > edhill: itpp,libmatheval,osiv > > eitch: ode > > ensc: ip-sentinel,mimetic > > errr: fluxstyle,pekwm,ruby-bdb > > firewing: lybniz > > fnasser: geronimo-specs > > fonts-sig: fonttools,fontypython,libXfontcache > > frankb: qtiplot > > fschwarz: python-TurboMail,python-tgcaptcha,python-turboflot > > gecko-maint: seamonkey,thunderbird > > gemi: bigloo,gauche,gauche-gl,gauche-gtk,pl,smarteiffel > > ghenry: cpan2rpm > > green: ardour,seq24 > > hadess: bluez-utils > > hardaker: dnssec-tools > > hno: squid > > hubbitus: mysql-gui-tools > > huzaifas: dia,dia,gnumeric,gnumeric > > ianweller: xautolock > > iburrell: perl-SVN-Mirror > > ifoox: ht2html,mysql-connector-java > > ixs: pyzor > > jakub: compat-gcc-34,valgrind > > jamatos: PyX,PyX,ifplugd,python-imaging > > james: zsh > > jgranado: python-imaging > > jhrozek: dwdiff > > jkratoch: libunwind > > jmagne: coolkey > > jmrodri: tanukiwrapper > > jnovy: nedit > > joost: lazarus > > jorge: lock-keys-applet > > jorton: mod_python,uw-imap > > jpmahowa: pmount > > jpye: sundials > > jreznik: kdemultimedia > > jskala: mgetty,mgetty,netatalk,squid,squid > > jsoeterb: xmms-cdread > > jsteffan: squid > > jwboyer: petitboot > > jwrdegoede: KoboDeluxe,ardour,arm-gp2x-linux-gcc,ode,sdcc > > kaboom: qgo > > karsten: autoconf,automake15,x3270 > > kasal: brltty,groff,pcre,perl-Crypt-SSLeay > > kengert: seamonkey > > kevin: xfce4-panel > > kkofler: kdemultimedia,qt3 > > konradm: sdcc > > kurzawa: pic2aa,yoltia > > kwizart: elektra,libgii,oyranos,perl-Event-Lib > > kzak: lockdev > > langel: azureus,azureus > > laxathom: lib3ds,quake3,wammu > > limb: archivemail,nagi,rafkill,wesnoth,xmoto I've already fixed all these after the last email on this. Every one of these has a newer, fixed version in rawhide, built around 9/12. How is this 9/23 rawhide? > liquidat: knetworkmanager > > lkundrak: pcre > > lmacken: bodhi,python-TurboMail,python-tgcaptcha,python-turboflot > > ltinkl: kdemultimedia,knetworkmanager > > lucilanga: evolution-rss > > lutter: ruby-rpm > > luya: gdesklets > > lvm-team: lvm2 > > masahase: pards > > mbarnes: evolution-sharp,gnome-python2-extras > > mbroz: lvm2 > > mcepl: pspp > > mclasen: glade2 > > mef: kaffeine,pl > > mfleming: asylum,mailgraph > > mgarski: xscorch > > mmahut: PythonCard,extrema,wcstools > > mmaslano: anacron,perl-Crypt-SSLeay > > mmcgrath: knetworkmanager,nagios > > mnagy: squid > > mornfall: lvm2 > > mpeters: PyX > > mschwendt: audacious-plugin-fc > > mtasaka: astyle > > mwiriadi: mediatomb > > mwringe: maven-wagon,xdoclet > > ngompa: oggconvert > > nhosoi: fedora-ds-base > > nkinder: fedora-ds-base > > notting: sysvinit > > nsantos: qpidc > > oliver: fish > > orion: hdf,vtk > > ovasik: docbook-utils > > overholt: eclipse-checkstyle,eclipse-gef,eclipse-mylyn,eclipse-rpm-editor > > owentl: gdesklets > > pcheung: axis,jakarta-commons-net > > perl-sig: > cpan2rpm,perl-Catalyst-Plugin-ConfigLoader,perl-DBIx-Class,perl-Event-Lib,perl-PDF-API2,perl-RRD-Simple,perl-SVN-Mirror,perl-bioperl > > pertusus: a2ps,cernlib,cernlib-g77,elektra,fetchmail,fltk,hdf,pmount,w3lib > > petersen: emacspeak,gcin > > pfj: gtk-sharp,mx > > pmachata: boost,ltrace,make > > pmuldoon: frysk > > rakesh: ifplugd,python-durus > > rathann: dx,freefem++,gabedit,tachyon > > ravenoak: pysvn > > rdieter: > akode,amarok,fltk,gtk+,k3b,kaffeine,kdemultimedia,knetworkmanager,libkexif,qt3,uw-imap > > remi: ocsinventory-agent,perl-Apache2-SOAP > > richdawe: planet > > rishi: astyle,tla > > rmeggins: fedora-ds-base > > rmyers: eclipse-checkstyle,eclipse-egit > > rnorwood: perl-Crypt-SSLeay > > robert: perl-CGI-SpeedyCGI > > robmv: eclipse-subclipse > > romal: nagios > > roozbeh: fonttools > > rrakus: indent,k3b,time > > rrelyea: coolkey > > rvinyard: bit,conexus,conexusmm,papyrus > > ryo: scim-skk > > sconklin: linpsk,xdx > > scop: kaffeine > > sebastian: nagios > > seg: openjpeg > > sergiopr: wcstools > > sgrubb: aide > > silfreed: ale > > sindrepb: firewalk,linpsk,xdx > > somlo: aumix > > splinux: gdmap,gnome-specimen,gstm > > spot: PyAmanith,R-RScaLAPACK,SimGear,alienarena,amanith,lout > > ssp: libXTrap,libXfontcache > > stahnma: ruby-rpm > > steved: nfs4-acl-tools > > subhodip: straw > > swagiaal: frysk > > szpak: isomaster > > terjeros: extrema > > than: isdn4k-utils,kdemultimedia,qt3 > > thias: gcombust,thttpd > > thl: gweled > > thomasvs: ladspa,rasqal > > timj: alsa-firmware > > timlau: bodhi > > tjikkun: tcltls > > tmoertel: R-Matrix > > tnorth: LabPlot,avr-binutils,avr-gcc > > toshio: bodhi,python-TurboMail,python-tgcaptcha,python-turboflot > > trondd: avr-binutils,avr-gcc > > tuxbrewr: akode,amarok,k3b,kdemultimedia > > twaugh: a2ps,pnm2ppa > > uwog: abiword > > vcrhonek: expect,fetchmail,ypserv > > walters: bigboard > > wart: bsd-games,cyphesis,tclparser > > wtogami: nagios,wesnoth > > xris: lineak-xosdplugin > > xulchris: poker-network > > > -- > Matt Domsch > Linux Technology Strategist, Dell Office of the CTO > linux.dell.com & www.dell.com/linux > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From Matt_Domsch at dell.com Wed Sep 24 13:05:49 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Wed, 24 Sep 2008 08:05:49 -0500 Subject: Fedora rawhide rebuild in mock status 2008-09-23 x86_64 In-Reply-To: <36504.198.175.55.5.1222259865.squirrel@mail.jcomserv.net> References: <20080924122036.GA28400@mock.linuxdev.us.dell.com> <36504.198.175.55.5.1222259865.squirrel@mail.jcomserv.net> Message-ID: <20080924130549.GA5994@auslistsprd01.us.dell.com> On Wed, Sep 24, 2008 at 07:37:45AM -0500, Jon Ciesla wrote: > I've already fixed all these after the last email on this. Every one of > these has a newer, fixed version in rawhide, built around 9/12. How is > this 9/23 rawhide? Good point. Rawhide has been "mostly frozen" to get the beta out the door. It'll start flowing normally again once the beta is done. Until then, since the freeze, you would have had to request your builds get tagged into the beta by rel-eng. I'll hold off mass bug filing until rawhide is flowing normally again. Thanks, Matt -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From rawhide at fedoraproject.org Wed Sep 24 13:07:48 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Wed, 24 Sep 2008 13:07:48 +0000 (UTC) Subject: rawhide report: 20080924 changes Message-ID: <20080924130748.C1D281F825C@releng2.fedora.phx.redhat.com> Updated Packages: bluez-4.6-1.fc10 ---------------- * Sun Sep 14 18:00:00 2008 - David Woodhouse - 4.6-1 - Update to 4.6 * Fri Sep 12 18:00:00 2008 - David Woodhouse - 4.5-4 - SDP browse fixes * Fri Sep 12 18:00:00 2008 - David Woodhouse - 4.5-3 - Bluez-alsa needs to provide/obsolete bluez-utils-alsa - Use versioned Obsoletes: * Fri Sep 12 18:00:00 2008 - David Woodhouse - 4.5-2 - Change main utils package name to 'bluez'; likewise its subpackages - Remove references to obsolete initscripts (hidd,pand,dund) * Fri Sep 12 18:00:00 2008 - Bastien Nocera - 4.5-1 - Update to 4.5 - Fix initscript to actually start bluetoothd by hand - Add chkconfig information to the initscript kernel-2.6.27-0.352.rc7.git1.fc10 --------------------------------- * Tue Sep 23 18:00:00 2008 Dave Jones - x86 compile fix. * Tue Sep 23 18:00:00 2008 Dave Jones - Merge Linux-2.6 up to commit fb478da5ba69ecf40729ae8ab37ca406b1e5be48 * Tue Sep 23 18:00:00 2008 Dave Jones - Disable E1000E driver until bz 459202 is solved. * Tue Sep 23 18:00:00 2008 Dave Airlie - rebase drm patches with latest upstream GEM bits * Tue Sep 23 18:00:00 2008 Dave Airlie - fix radeon cursor disappearing bug. * Mon Sep 22 18:00:00 2008 Roland McGrath - utrace update * Mon Sep 22 18:00:00 2008 Roland McGrath - 2.6.27-rc7-git1 * Mon Sep 22 18:00:00 2008 Kyle McMartin - Linux 2.6.27-rc7 * Mon Sep 22 18:00:00 2008 Kristian H??gsberg - Fix check for radeon external TMDS. * Mon Sep 22 18:00:00 2008 Kristian H??gsberg - Add patch to allow userspace to get a handle for the buffer object backing the drm fbdev buffer. - Update intel modesetting for the buffer object change. mkinitrd-6.0.64-1.fc10 ---------------------- * Tue Sep 23 18:00:00 2008 Jeremy Katz - 6.0.64-1 - Fix live initrds for some built-in modules Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 3 Broken deps for i386 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.i386 requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so Broken deps for x86_64 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.x86_64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.ppc requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so Broken deps for ppc64 ---------------------------------------------------------- eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gspiceui-0.9.65-2.fc10.ppc64 requires gwave livecd-tools-018-1.fc10.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.ppc64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) From lesmikesell at gmail.com Wed Sep 24 13:17:31 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 24 Sep 2008 08:17:31 -0500 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <20080924123334.GA18824@tango.0pointer.de> References: <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <20080922180001.GA8379@sonata.rednote.net> <20080923001815.GE21642@tango.0pointer.de> <48D85D71.4020503@gmail.com> <20080923130529.GH7596@tango.0pointer.de> <48D950BB.3030103@gmail.com> <20080923231312.GA338@tango.0pointer.de> <48D9B3D1.70805@gmail.com> <20080924123334.GA18824@tango.0pointer.de> Message-ID: <48DA3DEB.8030504@gmail.com> Lennart Poettering wrote: > >>> And again, that's the way *I* think it makes the most sense. >> If you haven't, give freenx/NX a try, floating your running session among >> displays at work, perhaps a wireless laptop, and pick them up from home >> with everything still running. And try it with several people sharing a >> machine. You might get used to the concept that your devices are really >> not that closely coupled. Or perhaps at least that your session isn't tied >> to the local console. X never intended it to be, but before freenx it >> wasn't that great remotely. > > If you use a terminal client, then audio should be forwarded to > it. That should be an option of course, perhaps the default choice even though it won't always work. If you are on a low bandwidth connection which works fine otherwise with NX, audio will be horrible. And your client may not have speakers - you may use many clients and good speakers are expensive and not portable. > Audio should always be sent to the same machine that shows you the > video. No, audio should always be sent to the device you choose. Guesswork is not a good thing. > Audio is part of the workplace, not the server. Sometimes you would want an audio 'session' at your local device, sometimes you want to control the device on the server. > From the > terminal client to the terminal server we send keyboard, mouse, audio > recording. From the terminal server to the terminal client we send > audio playback and screen contents. I'm usually in the same room with the server, with the server connected to speakers intended for the whole room. But, I want to use the keyboard, mouse, and monitor from a nearby desktop box or float the display to a laptop - and when I pick up the session from home I don't want to attempt audio because of the bandwidth issue. Windows RDP connections attempt that but it's not pretty. The other point about NX as a client is that as far as the local machine is concerned, it is just one app running in one window, sort of like Xnest. You still have full access to all the other apps you want to run locally and it usually makes much more sense to run apps that require local audio locally than to forward them from some remote session. Thinking of your computer as a single piece might make sense for someone who only has one, but does anyone really run fedora as their one and only computer? -- Les Mikesell lesmikesell at gmail.com From rjones at redhat.com Wed Sep 24 13:55:40 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Wed, 24 Sep 2008 14:55:40 +0100 Subject: libjpeg Source0 URI points to non-existent file Message-ID: <20080924135540.GA15290@amd.home.annexia.org> >From devel/libjpeg.spec: Source0: ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6b.tar.bz2 AFAICT this file is non-existent, should be .gz instead. Now I would normally file a bug about this, but I want to check first if this is a genuine bug, or some sort of RPM or Fedora Makefile trickery, like it automatically generates a bzip file or something. Can someone tell me? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From skasal at redhat.com Wed Sep 24 14:04:07 2008 From: skasal at redhat.com (Stepan Kasal) Date: Wed, 24 Sep 2008 16:04:07 +0200 Subject: specspo and PackageKit In-Reply-To: <1222178729.4144.6.camel@rosebud> References: <1222160979.3265.37.camel@hughsie-work> <1222177596.3920.1.camel@localhost.localdomain> <1222178729.4144.6.camel@rosebud> Message-ID: <20080924140407.GA27548@camelia.ucw.cz> Hello, On Tue, Sep 23, 2008 at 10:05:29AM -0400, seth vidal wrote: > I don't think he was saying we shouldn't translate the pkgs - I think he > was saying - specspo might just be a bad solution. agreed. Each installation contains a specspo catalogue of all Fedora packages (means Core + Extras in the yesterday's terminology). Yet if an rpm in Updates has fixed a typo in the summary or the description, the string is not found in the catalogue and stays in English. This might be mitigated by frequent updates of specspo, but: 1) specspo.rpm is relatively big 2) even with rpm-diffs, the diffs may still be big, as *.mo files are cpmpiled hashes, not mere lists 3) it still isn't a solution for people who consume only selected updates Moreover, the specspo solution is not extensible at all; if you add a third part repository, the messages just are not there. And the repository cannot install another catalogue, rpm uses just "the catalogue". specspo is as hostile to 3rd party rpm suppliers as is yum.repos.d friendly to them. Indeed, the design has to be fixed. (I tried to think about it for some time, but have not invented anything usable. Clearly, some help is needed here.) Stepan Kasal* * the current specspo maintainer From james.antill at redhat.com Wed Sep 24 14:10:20 2008 From: james.antill at redhat.com (James Antill) Date: Wed, 24 Sep 2008 10:10:20 -0400 Subject: Instant Mirror Status...? In-Reply-To: <48D9386E.8060803@gmail.com> References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> <20080922221540.GA15926@orient.maison.lan> <48D9386E.8060803@gmail.com> Message-ID: <1222265420.18055.14.camel@code.and.org> On Tue, 2008-09-23 at 13:41 -0500, Les Mikesell wrote: > Emmanuel Seyman wrote: > > * Gregory Maxwell [22/09/2008 20:04] : > >> How would it know? > > > > And more importantly, if you want to always hit the same mirror, why don't > > you edit its configuration to reflect that ? > > Here's the scenario: you have hundreds/thousands of people behind a > caching proxy. They don't know each other, they don't know what OS > distribution someone else is installing and the ones that happen to be > installing Fedora aren't going to know what mirror someone else chose or > got by accident. Likewise for the proxy - it's not going to know/care > that there are a bunch of different mirrors for different stuff that an > assortment of people might or might not want at the same time. Outcomes: 1) Noone does anything and the ISP/company serving the people download packages/etc. lots of times eating the company/ISPs bandwidth. 2) ISP/company tells MirrorManager what is going on, and saves bandwidth (note they get to solve their own problem, yay). And here's another scenario: hundreds/thousands of people with "close" IPs which aren't behind the same proxy, MirrorManager gives them the same list in the same order to try and hack around #1 above. Now everyone's download goes slow as they all hit the same mirror server (and the mirror server admin wonders why he got screwed over). Everyone complains and says MirrorManager/yum sucks ... and there's nothing anyone can do to fix the problem. -- James Antill Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Wed Sep 24 14:13:42 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 24 Sep 2008 10:13:42 -0400 Subject: specspo and PackageKit In-Reply-To: <20080923212045.GC22595@nostromo.devel.redhat.com> References: <1222160979.3265.37.camel@hughsie-work> <1222177596.3920.1.camel@localhost.localdomain> <1222178729.4144.6.camel@rosebud> <20080923205903.GA22595@nostromo.devel.redhat.com> <1222203943.4144.42.camel@rosebud> <20080923212045.GC22595@nostromo.devel.redhat.com> Message-ID: <1222265622.4144.53.camel@rosebud> On Tue, 2008-09-23 at 17:20 -0400, Bill Nottingham wrote: > I'm just trying to comprehend how we'd generate this information for > the repodata in any sort of sane manner, and failing miserably. You'd > need to have every run of createrepo check out some source controlled > translation directory, and munge it with intltool (aiyeeeeeeeee) into > a separate translated XML file. No, you don't need to do it on every run of createrepo. You can do it after the fact, if you want and then hit the repo with modifyrepo to add the translation data. You could even have a separate repomd-translation.xml which lists out the translation files available and their checksums, etc. The whole point is specspo isn't useful on its own anymore. I understand things we may do from here will take some work but specspo just takes up space w/o providing any functionality at all afaict. -sv From notting at redhat.com Wed Sep 24 14:20:59 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 24 Sep 2008 10:20:59 -0400 Subject: specspo and PackageKit In-Reply-To: <1222265622.4144.53.camel@rosebud> References: <1222160979.3265.37.camel@hughsie-work> <1222177596.3920.1.camel@localhost.localdomain> <1222178729.4144.6.camel@rosebud> <20080923205903.GA22595@nostromo.devel.redhat.com> <1222203943.4144.42.camel@rosebud> <20080923212045.GC22595@nostromo.devel.redhat.com> <1222265622.4144.53.camel@rosebud> Message-ID: <20080924142059.GB2843@nostromo.devel.redhat.com> seth vidal (skvidal at fedoraproject.org) said: > On Tue, 2008-09-23 at 17:20 -0400, Bill Nottingham wrote: > > I'm just trying to comprehend how we'd generate this information for > > the repodata in any sort of sane manner, and failing miserably. You'd > > need to have every run of createrepo check out some source controlled > > translation directory, and munge it with intltool (aiyeeeeeeeee) into > > a separate translated XML file. > > No, you don't need to do it on every run of createrepo. You can do it > after the fact, if you want and then hit the repo with modifyrepo to add > the translation data. You could even have a separate > repomd-translation.xml which lists out the translation files available > and their checksums, etc. > > The whole point is specspo isn't useful on its own anymore. I understand > things we may do from here will take some work but specspo just takes up > space w/o providing any functionality at all afaict. You're specifically architecting a repodata-based solution to replace just what it does now. How is that 'w/o providing any functionality at all'? Bill From skvidal at fedoraproject.org Wed Sep 24 14:23:30 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 24 Sep 2008 10:23:30 -0400 Subject: specspo and PackageKit In-Reply-To: <20080924142059.GB2843@nostromo.devel.redhat.com> References: <1222160979.3265.37.camel@hughsie-work> <1222177596.3920.1.camel@localhost.localdomain> <1222178729.4144.6.camel@rosebud> <20080923205903.GA22595@nostromo.devel.redhat.com> <1222203943.4144.42.camel@rosebud> <20080923212045.GC22595@nostromo.devel.redhat.com> <1222265622.4144.53.camel@rosebud> <20080924142059.GB2843@nostromo.devel.redhat.com> Message-ID: <1222266210.4144.57.camel@rosebud> On Wed, 2008-09-24 at 10:20 -0400, Bill Nottingham wrote: > seth vidal (skvidal at fedoraproject.org) said: > > On Tue, 2008-09-23 at 17:20 -0400, Bill Nottingham wrote: > > > I'm just trying to comprehend how we'd generate this information for > > > the repodata in any sort of sane manner, and failing miserably. You'd > > > need to have every run of createrepo check out some source controlled > > > translation directory, and munge it with intltool (aiyeeeeeeeee) into > > > a separate translated XML file. > > > > No, you don't need to do it on every run of createrepo. You can do it > > after the fact, if you want and then hit the repo with modifyrepo to add > > the translation data. You could even have a separate > > repomd-translation.xml which lists out the translation files available > > and their checksums, etc. > > > > The whole point is specspo isn't useful on its own anymore. I understand > > things we may do from here will take some work but specspo just takes up > > space w/o providing any functionality at all afaict. > > You're specifically architecting a repodata-based solution to replace > just what it does now. How is that 'w/o providing any functionality at > all'? No, I was offering a way of doing it so you only got the translations you needed for the language you were using. Additionally, I was trying to focus on a solution which allowed you to have translations for both the installed and available packages. In my ideal world things would work like this: 1. translations live in the repodata in separate files per language 2. yum downloads the translations for the lang you're running in 3. when you install a package it takes the translations from the repodata translation and stuffs them in the rpmdb alongside the stock info for the pkg. 1 and 2 should be doable. 3 is tricky w/o support from rpm, but not impossible. -sv From notting at redhat.com Wed Sep 24 14:34:33 2008 From: notting at redhat.com (Bill Nottingham) Date: Wed, 24 Sep 2008 10:34:33 -0400 Subject: specspo and PackageKit In-Reply-To: <1222266210.4144.57.camel@rosebud> References: <1222160979.3265.37.camel@hughsie-work> <1222177596.3920.1.camel@localhost.localdomain> <1222178729.4144.6.camel@rosebud> <20080923205903.GA22595@nostromo.devel.redhat.com> <1222203943.4144.42.camel@rosebud> <20080923212045.GC22595@nostromo.devel.redhat.com> <1222265622.4144.53.camel@rosebud> <20080924142059.GB2843@nostromo.devel.redhat.com> <1222266210.4144.57.camel@rosebud> Message-ID: <20080924143433.GA6467@nostromo.devel.redhat.com> seth vidal (skvidal at fedoraproject.org) said: > No, I was offering a way of doing it so you only got the translations > you needed for the language you were using. Additionally, I was trying > to focus on a solution which allowed you to have translations for both > the installed and available packages. Again, this is all stuff that exists. (specspo is lang-tagged, just like any other package's translation.) > In my ideal world things would work like this: > > 1. translations live in the repodata in separate files per language > 2. yum downloads the translations for the lang you're running in > 3. when you install a package it takes the translations from the > repodata translation and stuffs them in the rpmdb alongside the stock > info for the pkg. This is still a tremendous burden at repodata time, which requires tying a large cpu-intensive process (that has to pull from source control) into every tool that we have (mash, bodhi, etc.) Bill From james.antill at redhat.com Wed Sep 24 14:38:51 2008 From: james.antill at redhat.com (James Antill) Date: Wed, 24 Sep 2008 10:38:51 -0400 Subject: specspo and PackageKit In-Reply-To: <20080924142059.GB2843@nostromo.devel.redhat.com> References: <1222160979.3265.37.camel@hughsie-work> <1222177596.3920.1.camel@localhost.localdomain> <1222178729.4144.6.camel@rosebud> <20080923205903.GA22595@nostromo.devel.redhat.com> <1222203943.4144.42.camel@rosebud> <20080923212045.GC22595@nostromo.devel.redhat.com> <1222265622.4144.53.camel@rosebud> <20080924142059.GB2843@nostromo.devel.redhat.com> Message-ID: <1222267131.18055.25.camel@code.and.org> On Wed, 2008-09-24 at 10:20 -0400, Bill Nottingham wrote: > seth vidal (skvidal at fedoraproject.org) said: > > On Tue, 2008-09-23 at 17:20 -0400, Bill Nottingham wrote: > > > I'm just trying to comprehend how we'd generate this information for > > > the repodata in any sort of sane manner, and failing miserably. You'd > > > need to have every run of createrepo check out some source controlled > > > translation directory, and munge it with intltool (aiyeeeeeeeee) into > > > a separate translated XML file. > > > > No, you don't need to do it on every run of createrepo. You can do it > > after the fact, if you want and then hit the repo with modifyrepo to add > > the translation data. You could even have a separate > > repomd-translation.xml which lists out the translation files available > > and their checksums, etc. > > > > The whole point is specspo isn't useful on its own anymore. I understand > > things we may do from here will take some work but specspo just takes up > > space w/o providing any functionality at all afaict. > > You're specifically architecting a repodata-based solution to replace > just what it does now. How is that 'w/o providing any functionality at > all'? So there are two specific problems that I see, which have no good solution with specspo: 1. sepcspo only solves the problem for Fedora, other repos. are very much second class citizens. 2. Currently yum does operations based on the repodata, like search etc. ... ergo. this isn't localized so you can't search for "Libreria SELinux" or whatever. In theory you can fix this with specspo by loading all packages into memory and doing the operations in python ... given how much PCP the "yum is slow" people take, noone wants to do that fix. ...there are also a bunch of other minor problems, that probably could be fixed with specspo but might well be easier to fix with something else like: 1. specspo is often out of date (esp. problematic is if you change the summary/description for a pacakge ... as you now need two translations as someone might have the old version installed). 2. you have to download all langs with specspo -- James Antill Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mclasen at redhat.com Wed Sep 24 14:43:29 2008 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 24 Sep 2008 10:43:29 -0400 Subject: specspo and PackageKit In-Reply-To: <1222267131.18055.25.camel@code.and.org> References: <1222160979.3265.37.camel@hughsie-work> <1222177596.3920.1.camel@localhost.localdomain> <1222178729.4144.6.camel@rosebud> <20080923205903.GA22595@nostromo.devel.redhat.com> <1222203943.4144.42.camel@rosebud> <20080923212045.GC22595@nostromo.devel.redhat.com> <1222265622.4144.53.camel@rosebud> <20080924142059.GB2843@nostromo.devel.redhat.com> <1222267131.18055.25.camel@code.and.org> Message-ID: <1222267409.5267.2.camel@localhost.localdomain> On Wed, 2008-09-24 at 10:38 -0400, James Antill wrote: > > 2. you have to download all langs with specspo Is it really worth solving this problem without also solving the 'must squeeze all the languages in the world on the livecd' problem ? If I understand Bill correctly, specspo has lang tags, so making lang tags useful would solve both problems at the same time. From kwade at redhat.com Wed Sep 24 14:46:26 2008 From: kwade at redhat.com (Karsten 'quaid' Wade) Date: Wed, 24 Sep 2008 07:46:26 -0700 Subject: configuring sudo by default In-Reply-To: <48CBABC4.5060005@leemhuis.info> References: <2a28d2ab0809121743h1374e9c6w9c0b9cebbbf5261c@mail.gmail.com> <1221285235.3492.4.camel@fantail.jnet.net.nz> <1221301012.3152.7.camel@pc-notebook> <48CBABC4.5060005@leemhuis.info> Message-ID: <1222267586.16394.274.camel@calliope.phig.org> On Sat, 2008-09-13 at 14:02 +0200, Thorsten Leemhuis wrote: > But a checkbox with a text "User is the sysadmin for this system" might > makes sense in firstboot -- that checkbox could not only configure sudo > and/or PolicyKit access but also do other things like setting up a alias > to /etc/aliases to make sure the user in question retrieves the mail > send to root. +1 From a documentation perspective, not having 'sudo' setup by default is a major PITA. We have these options currently in writing: a. In each document that requires doing actions as root, have a section that explains how to configure 'sudo' 1. Or we have to send them out to a stand-alone Sudo How To, which can be described as, "sucky reader experience." b. Use 'su -c' in all situations, despite other Linux tutorials commonly using sudo b.1 Why does this matter? It's good to follow a common practice to make readers more familiar and comfortable; tutorials can more easily be reused or apply to Fedora. b.2 Also 'su' requires knowing the root password, where 'sudo' doesn't. The situation we have without 'sudo' configured by user-who-is-admin is that the user must know and use the root password on a regular basis. Super evil may ensue. Makes writing documentation exponentially more difficult. - Karsten -- Karsten Wade, Community Gardener Dev Fu : http://developer.redhatmagazine.com Fedora : http://quaid.fedorapeople.org gpg key : -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From skvidal at fedoraproject.org Wed Sep 24 14:44:58 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Wed, 24 Sep 2008 10:44:58 -0400 Subject: specspo and PackageKit In-Reply-To: <1222267409.5267.2.camel@localhost.localdomain> References: <1222160979.3265.37.camel@hughsie-work> <1222177596.3920.1.camel@localhost.localdomain> <1222178729.4144.6.camel@rosebud> <20080923205903.GA22595@nostromo.devel.redhat.com> <1222203943.4144.42.camel@rosebud> <20080923212045.GC22595@nostromo.devel.redhat.com> <1222265622.4144.53.camel@rosebud> <20080924142059.GB2843@nostromo.devel.redhat.com> <1222267131.18055.25.camel@code.and.org> <1222267409.5267.2.camel@localhost.localdomain> Message-ID: <1222267498.4144.60.camel@rosebud> On Wed, 2008-09-24 at 10:43 -0400, Matthias Clasen wrote: > On Wed, 2008-09-24 at 10:38 -0400, James Antill wrote: > > > > > 2. you have to download all langs with specspo > > Is it really worth solving this problem without also solving the 'must > squeeze all the languages in the world on the livecd' problem ? If you don't install specspo you save that space on the livecd. Then when someone wants translated info they get it dynamically from all repos that support translated metadata, for example. > If I understand Bill correctly, specspo has lang tags, so making lang > tags useful would solve both problems at the same time. But it doesn't and it doesn't solve them for multiple repos at all. Since, afaik, you can only have one specspo pkg at a time. -sv From konrad at tylerc.org Wed Sep 24 15:11:57 2008 From: konrad at tylerc.org (Conrad Meyer) Date: Wed, 24 Sep 2008 08:11:57 -0700 Subject: Fedora rawhide rebuild in mock status 2008-09-23 x86_64 In-Reply-To: <20080924122036.GA28400@mock.linuxdev.us.dell.com> References: <20080924122036.GA28400@mock.linuxdev.us.dell.com> Message-ID: <200809240811.58008.konrad@tylerc.org> On Wednesday 24 September 2008 05:20:36 am Matt Domsch wrote: > Fedora Rawhide-in-Mock Build Results for x86_64 > using the rawhide tree of Tuesday, 2008-10-23. > > This is not a full rebuild of everything, merely a rebuild of packages > failing to build over the last few weeks. Failures here will cause > new bugzilla bugs to be created, which will block the 'F10FTBFS' bug. > My hope is that we can resolve all these before the Fedora 10 Release > Candidate. > > 122 of these failures are due to patch fuzz. Each of those should be > reviewed to ensure upstream has not already fixed the problem the > patch addressed, either by applying the patch or by fixing it in > another way. If the problem persists, please rebase the patch to the > current source code, so it applies without fuzz, and forward your > patch to the upstream package maintainer. > > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > > Total packages: 6191 > Number failed to build: 312 > Number expected to fail due to ExclusiveArch or ExcludeArch: 34 > Leaving: 278 > > Of those expected to have worked... > Without a bug filed: 275 > ---------------------------------- > ... > sdcc-2.6.0-12.fc9 (build/make) konradm,jwrdegoede > ... > konradm: sdcc 2.8.0 builds from source fine and I have the spec ready, pending this bug: https://bugzilla.redhat.com/show_bug.cgi?id=462383 -- Conrad Meyer From cmadams at hiwaay.net Wed Sep 24 15:14:34 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 24 Sep 2008 10:14:34 -0500 Subject: libjpeg Source0 URI points to non-existent file In-Reply-To: <20080924135540.GA15290@amd.home.annexia.org> References: <20080924135540.GA15290@amd.home.annexia.org> Message-ID: <20080924151433.GB1414283@hiwaay.net> Once upon a time, Richard W.M. Jones said: > >From devel/libjpeg.spec: > > Source0: ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6b.tar.bz2 > > AFAICT this file is non-existent, should be .gz instead. > > Now I would normally file a bug about this, but I want to check first > if this is a genuine bug, or some sort of RPM or Fedora Makefile > trickery, like it automatically generates a bzip file or something. > Can someone tell me? For a while, Red Hat was fetching source and recompressing it to bz2 to gain a little space. I don't think anybody is doing it now, but this may be a remnant from that time (since the JPEG reference source hasn't changed in a long time). I would say that at this point it would be good to switch back to the original (pristine) source; saving a few K by recompressing isn't worth it. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jkeating at redhat.com Wed Sep 24 15:28:09 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 24 Sep 2008 08:28:09 -0700 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <48DA3DEB.8030504@gmail.com> References: <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <20080922180001.GA8379@sonata.rednote.net> <20080923001815.GE21642@tango.0pointer.de> <48D85D71.4020503@gmail.com> <20080923130529.GH7596@tango.0pointer.de> <48D950BB.3030103@gmail.com> <20080923231312.GA338@tango.0pointer.de> <48D9B3D1.70805@gmail.com> <20080924123334.GA18824@tango.0pointer.de> <48DA3DEB.8030504@gmail.com> Message-ID: <1222270089.4108.93.camel@luminos.localdomain> On Wed, 2008-09-24 at 08:17 -0500, Les Mikesell wrote: > but does anyone really run fedora as their one and > only computer? I do, and have for years. Before I ever got involved with Fedora, back in the RHL days. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From poelstra at redhat.com Wed Sep 24 15:23:44 2008 From: poelstra at redhat.com (John Poelstra) Date: Wed, 24 Sep 2008 08:23:44 -0700 Subject: Plan for tomorrows (20080924) FESCO meeting In-Reply-To: <1222210144.16171.2.camel@kennedy> References: <1222186624.14583.2.camel@truman> <1222188670.4108.65.camel@luminos.localdomain> <20080923210124.GB22595@nostromo.devel.redhat.com> <1222210144.16171.2.camel@kennedy> Message-ID: <48DA5B80.7010400@redhat.com> Brian Pepple said the following on 09/23/2008 03:49 PM Pacific Time: > On Tue, 2008-09-23 at 17:01 -0400, Bill Nottingham wrote: >> Jesse Keating (jkeating at redhat.com) said: >>> On Tue, 2008-09-23 at 12:17 -0400, Brian Pepple wrote: >>>> /topic FESCo-Meeting -- F10 Schedule slip - >>>> https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01938html - all >>> Any chance we can get a decision on this today? >> +1 from me. > > +1 here also. > > Jesse, since more than half of FESCo has voted in favor of the schedule > change, consider it approved. > > Later, > /B > All schedules updated https://fedoraproject.org/wiki/Releases/10/Schedule http://poelstra.fedorapeople.org/schedules/f-10/f-10-all-milestones.html John From lesmikesell at gmail.com Wed Sep 24 15:35:40 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 24 Sep 2008 10:35:40 -0500 Subject: Instant Mirror Status...? In-Reply-To: <1222265420.18055.14.camel@code.and.org> References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> <20080922221540.GA15926@orient.maison.lan> <48D9386E.8060803@gmail.com> <1222265420.18055.14.camel@code.and.org> Message-ID: <48DA5E4C.3020009@gmail.com> James Antill wrote: > >>>> How would it know? >>> And more importantly, if you want to always hit the same mirror, why don't >>> you edit its configuration to reflect that ? >> Here's the scenario: you have hundreds/thousands of people behind a >> caching proxy. They don't know each other, they don't know what OS >> distribution someone else is installing and the ones that happen to be >> installing Fedora aren't going to know what mirror someone else chose or >> got by accident. Likewise for the proxy - it's not going to know/care >> that there are a bunch of different mirrors for different stuff that an >> assortment of people might or might not want at the same time. > > Outcomes: > > 1) Noone does anything and the ISP/company serving the people download > packages/etc. lots of times eating the company/ISPs bandwidth. > > 2) ISP/company tells MirrorManager what is going on, and saves bandwidth > (note they get to solve their own problem, yay). That will probably happen in about a dozen cases. > And here's another scenario: hundreds/thousands of people with "close" > IPs which aren't behind the same proxy, MirrorManager gives them the > same list in the same order to try and hack around #1 above. Huh? Why do you think this ratio would be skewed worse with intelligent processing than randomly? And if you have a reason to think that, why can't you use a heuristic to compute the distribution fairly? > Now > everyone's download goes slow as they all hit the same mirror server > (and the mirror server admin wonders why he got screwed over). Well, no - even if some of the sites in an unfair distribution don't have proxies, many will and those will reduce the load on the mirrors. > Everyone > complains and says MirrorManager/yum sucks ... and there's nothing > anyone can do to fix the problem. That would only happen if your intelligent computation is worse than random. And if it is a problem you could go back to the old way without making anything worse than it is now - or use a more intelligent heuristic if you see your first attempt is wrong. You can't get worse than the cache pollution that happens when every attempt for the same file gets a different URL. It doesn't have to be perfect or locked forever to make it better. -- Les Mikesell lesmikesell at gmail.com From dr.diesel at gmail.com Wed Sep 24 15:36:12 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Wed, 24 Sep 2008 10:36:12 -0500 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <1222270089.4108.93.camel@luminos.localdomain> References: <1221592366.32342.23.camel@localhost.localdomain> <20080923001815.GE21642@tango.0pointer.de> <48D85D71.4020503@gmail.com> <20080923130529.GH7596@tango.0pointer.de> <48D950BB.3030103@gmail.com> <20080923231312.GA338@tango.0pointer.de> <48D9B3D1.70805@gmail.com> <20080924123334.GA18824@tango.0pointer.de> <48DA3DEB.8030504@gmail.com> <1222270089.4108.93.camel@luminos.localdomain> Message-ID: <2a28d2ab0809240836v28568f31i2719587b25ad361c@mail.gmail.com> 2008/9/24 Jesse Keating > On Wed, 2008-09-24 at 08:17 -0500, Les Mikesell wrote: > > but does anyone really run fedora as their one and > > only computer? > > I do, and have for years. Before I ever got involved with Fedora, back > in the RHL days. > > I've been only using Fedora at home since Core 1. My kids, age 3 and 6, both have their own computers, both Fedora and my wife switched from Windblows to Fedora about this time last year! And I ask, why wouldn't you use Fedora as your only computer?? -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at gmail.com Wed Sep 24 15:48:42 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Wed, 24 Sep 2008 11:48:42 -0400 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <1222270089.4108.93.camel@luminos.localdomain> References: <20080922180001.GA8379@sonata.rednote.net> <20080923001815.GE21642@tango.0pointer.de> <48D85D71.4020503@gmail.com> <20080923130529.GH7596@tango.0pointer.de> <48D950BB.3030103@gmail.com> <20080923231312.GA338@tango.0pointer.de> <48D9B3D1.70805@gmail.com> <20080924123334.GA18824@tango.0pointer.de> <48DA3DEB.8030504@gmail.com> <1222270089.4108.93.camel@luminos.localdomain> Message-ID: <20080924154842.GA25274@yoda.jdub.homelinux.org> On Wed, Sep 24, 2008 at 08:28:09AM -0700, Jesse Keating wrote: >On Wed, 2008-09-24 at 08:17 -0500, Les Mikesell wrote: >> but does anyone really run fedora as their one and >> only computer? > >I do, and have for years. Before I ever got involved with Fedora, back >in the RHL days. Ditto. And not just for home use either. I use Fedora, and only Fedora, at work too. josh From mw_triad at users.sourceforge.net Wed Sep 24 16:16:08 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 24 Sep 2008 11:16:08 -0500 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <48DA3DEB.8030504@gmail.com> References: <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <20080922180001.GA8379@sonata.rednote.net> <20080923001815.GE21642@tango.0pointer.de> <48D85D71.4020503@gmail.com> <20080923130529.GH7596@tango.0pointer.de> <48D950BB.3030103@gmail.com> <20080923231312.GA338@tango.0pointer.de> <48D9B3D1.70805@gmail.com> <20080924123334.GA18824@tango.0pointer.de> <48DA3DEB.8030504@gmail.com> Message-ID: Les Mikesell wrote: > Thinking of your computer as a single piece might make sense for someone > who only has one, but does anyone really run fedora as their one and > only computer? That's like saying Fedora should only be targeted at highly tech-savvy users, which I have to take issue at. Do we really want to limit ourselves to that audience? (To those that stated "I only use Fedora on , I think you all missed the point of the question, which was, 'do any Fedora users have /only one computer/', not 'does anyone use only Fedora'.) -- Matthew I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while in a KDE session. And nothing bad happened whatsoever. Try THAT on Windows :-D. From denis at poolshark.org Wed Sep 24 16:17:55 2008 From: denis at poolshark.org (Denis Leroy) Date: Wed, 24 Sep 2008 18:17:55 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <1222270089.4108.93.camel@luminos.localdomain> References: <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <20080922180001.GA8379@sonata.rednote.net> <20080923001815.GE21642@tango.0pointer.de> <48D85D71.4020503@gmail.com> <20080923130529.GH7596@tango.0pointer.de> <48D950BB.3030103@gmail.com> <20080923231312.GA338@tango.0pointer.de> <48D9B3D1.70805@gmail.com> <20080924123334.GA18824@tango.0pointer.de> <48DA3DEB.8030504@gmail.com> <1222270089.4108.93.camel@luminos.localdomain> Message-ID: <48DA6833.9070003@poolshark.org> Jesse Keating wrote: > On Wed, 2008-09-24 at 08:17 -0500, Les Mikesell wrote: >> but does anyone really run fedora as their one and >> only computer? Fedora at home. Fedora on work laptop. No stinkin' dual boot. Before that RedHat starting at RH 6.1. Before that Solaris and MacOS. Never used Windows. From katzj at redhat.com Wed Sep 24 16:17:44 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 24 Sep 2008 12:17:44 -0400 Subject: libjpeg Source0 URI points to non-existent file In-Reply-To: <20080924151433.GB1414283@hiwaay.net> References: <20080924135540.GA15290@amd.home.annexia.org> <20080924151433.GB1414283@hiwaay.net> Message-ID: <1222273064.22019.6.camel@aglarond.local> On Wed, 2008-09-24 at 10:14 -0500, Chris Adams wrote: > Once upon a time, Richard W.M. Jones said: > > >From devel/libjpeg.spec: > > > > Source0: ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6b.tar.bz2 > > > > AFAICT this file is non-existent, should be .gz instead. > > > > Now I would normally file a bug about this, but I want to check first > > if this is a genuine bug, or some sort of RPM or Fedora Makefile > > trickery, like it automatically generates a bzip file or something. > > Can someone tell me? > > For a while, Red Hat was fetching source and recompressing it to bz2 to > gain a little space. I don't think anybody is doing it now, but this > may be a remnant from that time (since the JPEG reference source hasn't > changed in a long time). Almost certainly the case. It mattered when we needed to keep the cd set size down so that we could keep production costs at a minimum and not lose money on the box set :-) > I would say that at this point it would be good to switch back to the > original (pristine) source; saving a few K by recompressing isn't worth > it. Yeah, probably true also Jeremy From jonstanley at gmail.com Wed Sep 24 16:19:53 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Wed, 24 Sep 2008 12:19:53 -0400 Subject: Is Zimbra open-source software In-Reply-To: <804765.33554.qm@web57416.mail.re1.yahoo.com> References: <804765.33554.qm@web57416.mail.re1.yahoo.com> Message-ID: 2008/9/24 Prakash Hallalli : > Hi, > > I am prakash, i would like to know about zimbra, > Is Zimbra stable to deploy and is it free software (GNO/GPL)? > Please help me. I'm not sure that this is the appropriate forum for this, but Zimbra is stable to deploy - they have two editions, the FOSS editions and the Network edition. The Network edition is non-free, the FOSS edition is open source under the terms of the Yahoo! Public License. As I recall, this license was recently modified in order to make it free - the problem with the prior version is that Yahoo could unilaterally revoke the license. From mw_triad at users.sourceforge.net Wed Sep 24 16:29:20 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 24 Sep 2008 11:29:20 -0500 Subject: multiple local X logins by same user In-Reply-To: References: <20080916183444.GA4973@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> <20080923193026.GA12861@tango.0pointer.de> <48D95695.1050108@gmail.com> <20080923233449.GA2076@tango.0pointer.de> Message-ID: Colin Walters wrote: > On Tue, Sep 23, 2008 at 8:38 PM, Matthew Woehlke > wrote: >> >> (Incidentally, Firefox drives me nuts not letting me run it on my local >> login and via 'ssh -X' from a remote machine. Some apps are even worse >> behaved than not coping with two full local X sessions as to go so far as to >> not permit multiple instances to be run /at all/.) > > Basically every nontrivial app doesn't support it, because it's just > too crazy. Erm? Every app that supports running two simultaneous independent instances (which is to say, 90% or more of all non-trivial apps) won't even notice they aren't in the same X session. It's only "crazy" for apps that go ridiculously out of their way to make sure there is only ever one instance running on a machine. In fact, *other* than Firefox I can't think of a single program that has this problem. > One could spend an entire lifespan trying to figure out > "Ok, what if I do *this*?". If you want to access your Firefox > instance remotely, use vino or one of the other systems that lets you > access your existing session. I don't *want* to access my existing session. I want to start a second, completely independent session^1. Firefox is nearly the only program I can think of that doesn't let me do this. (^1 I'll admit that I'd prefer one that won't hose state information when I run it, which I suppose is the problem we were talking about. Nevertheless, KDE applications don't seem to have a problem here, so trying to argue that it's "hard" is obviously just an excuse. There's all sorts of Free and proprietary software I could list that can run independent instances without hosing their state. Usually the last-running instance clobbers the state left by any others, which, while perhaps not ideal, is certainly "good enough" in many cases^2.) (^2 I will grant that "last state wins" may be unacceptable for things like web browser history, which should be not only lossless but possibly shared, but there are already good solutions for that (usually called "databases"), and Firefox *is* using SQL these days...) -- Matthew I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while in a KDE session. And nothing bad happened whatsoever. Try THAT on Windows :-D. From kevin at scrye.com Wed Sep 24 16:03:17 2008 From: kevin at scrye.com (Kevin Fenzi) Date: Wed, 24 Sep 2008 10:03:17 -0600 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <48D7F291.1010502@gmail.com> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <48D74445.3030900@leemhuis.info> <48D7F291.1010502@gmail.com> Message-ID: <20080924100317.78534d0f@ohm.scrye.com> On Mon, 22 Sep 2008 12:31:29 -0700 a.badger at gmail.com (Toshio Kuratomi) wrote: > Thorsten Leemhuis wrote: > > On 22.09.2008 08:49, Alex Lancaster wrote: > >> Ideally this would be done either as a mandatory part of the > >> original CVS import request (a field could be added, with an > >> opt-out provision if really not appropriate for comps), or added > >> interactively by the maintainer via PackageDB as I suggested in > >> the feature request here: > >> https://fedorahosted.org/packagedb/ticket/78#comment:1 > > > > Hmmmm. How much does the pkgdb know about the binary packages that > > get build from the source packages? Not much afaics, as the pkgdb > > mainly (only?) works with the (source) packages and not the ones > > that get build from it -- but in a proper comps.xml we need to list > > the binary packages, as a user might want to select the packages > > (rpms) foo or bar that both might get build from the package (srpm) > > foobar. > > > >> Having to manually update the comps.xml file for multiple releases > >> is painful, error-prone and probably why most package maintainers > >> ignore it, especially since it is not enforced in package reviews. > > > +1 Yeah, agreed here too. > So here's where I'm at WRT binary packages. > > We have too many apps interested in doing only a subset of the work in > this area. > > There's amber which is going to provide an end user view of > applications (rather than packages) with categories and tags. > There's Fedora collection which probably won't have a permanent data > store of its own. There's PackageDB which oculd be expanded to handle > this (it has tables for binary packages but is unfilled with data). > There's koji which touches every binary package, consumes and > generates comps files. I thought it was mash that consumed and generated the comps files? > There's comps.xml which is the master store > for this information right now. There's repoview which provides a > static interface to binary packages and comps on the gold repo but > not yet updates -- if it is updated to work on updates, that will > require bodhi to write out the files. > > So: > > 1) In which app should the canonical storage for this reside? Perhaps we could get together a meeting of koji, mash, bodhi, pkgdb folks and hash this out? > 2) What interface do we want to put on top of the storage? > 3) What apps will need to pull data from there once we have it? I think 2 and 3 will depend on where the data ends up being stored. > -Toshio kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Wed Sep 24 16:30:15 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 24 Sep 2008 18:30:15 +0200 Subject: specspo and PackageKit In-Reply-To: <20080924143433.GA6467@nostromo.devel.redhat.com> References: <1222160979.3265.37.camel@hughsie-work> <1222177596.3920.1.camel@localhost.localdomain> <1222178729.4144.6.camel@rosebud> <20080923205903.GA22595@nostromo.devel.redhat.com> <1222203943.4144.42.camel@rosebud> <20080923212045.GC22595@nostromo.devel.redhat.com> <1222265622.4144.53.camel@rosebud> <20080924142059.GB2843@nostromo.devel.redhat.com> <1222266210.4144.57.camel@rosebud> <20080924143433.GA6467@nostromo.devel.redhat.com> Message-ID: <1222273815.4776.4.camel@arekh.okg> Le mercredi 24 septembre 2008 ? 10:34 -0400, Bill Nottingham a ?crit : > > In my ideal world things would work like this: > > > > 1. translations live in the repodata in separate files per language > > 2. yum downloads the translations for the lang you're running in > > 3. when you install a package it takes the translations from the > > repodata translation and stuffs them in the rpmdb alongside the stock > > info for the pkg. > > This is still a tremendous burden at repodata time, which requires > tying a large cpu-intensive process (that has to pull from source control) > into every tool that we have (mash, bodhi, etc.) Unless I'm mistaken, 1. 2. 3. makes no assumption on where the translations are sourced from before they end up in repodata. And sourcing them from source control would not work for third-party repositories. (to work with them you need to either bundle translations in the packages themselves, or define a detached translation file format that can be associated to a 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 jkeating at redhat.com Wed Sep 24 16:57:42 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 24 Sep 2008 09:57:42 -0700 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: References: <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <20080922180001.GA8379@sonata.rednote.net> <20080923001815.GE21642@tango.0pointer.de> <48D85D71.4020503@gmail.com> <20080923130529.GH7596@tango.0pointer.de> <48D950BB.3030103@gmail.com> <20080923231312.GA338@tango.0pointer.de> <48D9B3D1.70805@gmail.com> <20080924123334.GA18824@tango.0pointer.de> <48DA3DEB.8030504@gmail.com> Message-ID: <1222275462.4108.98.camel@luminos.localdomain> On Wed, 2008-09-24 at 11:16 -0500, Matthew Woehlke wrote: > > (To those that stated "I only use Fedora on , I think > you all missed the point of the question, which was, 'do any Fedora > users have /only one computer/', not 'does anyone use only Fedora'.) Until I started working from home, yes. I had exactly one computer, my work laptop. It ran Fedora and only Fedora. My wife had her own laptop. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed Sep 24 17:01:13 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 24 Sep 2008 10:01:13 -0700 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <48D7F291.1010502@gmail.com> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <48D74445.3030900@leemhuis.info> <48D7F291.1010502@gmail.com> Message-ID: <1222275673.4108.100.camel@luminos.localdomain> On Mon, 2008-09-22 at 12:31 -0700, Toshio Kuratomi wrote: > There's koji which > touches every binary package, consumes and generates comps files. > There's comps.xml which is the master store for this information right > now. There's repoview which provides a static interface to binary > packages and comps on the gold repo but not yet updates -- if it is > updated to work on updates, that will require bodhi to write out the files. Kevin is right, it's mash that pulls comps out of cvs and 'makes' it and uses it when generating repodata. Mash is used during rawhide production and during update repo generation. When we make releases, that uses pungi which consumes the comps data that mash generated and merges in data from any other repo pungi is configured to use. Then pungi calls repoview to create data based on that merged comps. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From billcrawford1970 at gmail.com Wed Sep 24 17:04:40 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Wed, 24 Sep 2008 18:04:40 +0100 Subject: multiple local X logins by same user In-Reply-To: References: <20080916183444.GA4973@sonata.rednote.net> Message-ID: <200809241804.40399.billcrawford1970@gmail.com> On Wednesday 24 September 2008 17:29:20 Matthew Woehlke wrote: > I don't *want* to access my existing session. I want to start a second, > completely independent session^1. Firefox is nearly the only program I > can think of that doesn't let me do this. I put "firefox -Pfoo %u" in a panel icon, with different foo in different places, and can start three different firefox instances (I have three screens, and I often use them for different purposes e.g. if I need to log into our web app under an admin and non-admin user ID at the same time ... this is extremely useful for testing purposes). It's kludgy, but it works. Perhaps even a script that created a profile based on the display name? "firefox -Pprofile-%DISPLAY" might cut it, if anyone fancies trying it. From lesmikesell at gmail.com Wed Sep 24 17:11:28 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 24 Sep 2008 12:11:28 -0500 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: References: <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <20080922180001.GA8379@sonata.rednote.net> <20080923001815.GE21642@tango.0pointer.de> <48D85D71.4020503@gmail.com> <20080923130529.GH7596@tango.0pointer.de> <48D950BB.3030103@gmail.com> <20080923231312.GA338@tango.0pointer.de> <48D9B3D1.70805@gmail.com> <20080924123334.GA18824@tango.0pointer.de> <48DA3DEB.8030504@gmail.com> Message-ID: <48DA74C0.4010602@gmail.com> Matthew Woehlke wrote: > >> Thinking of your computer as a single piece might make sense for >> someone who only has one, but does anyone really run fedora as their >> one and only computer? > > That's like saying Fedora should only be targeted at highly tech-savvy > users, which I have to take issue at. Do we really want to limit > ourselves to that audience? If you don't serve that audience or offer a forward path beyond entry level, who do you serve and who is going to promote it? > (To those that stated "I only use Fedora on , I think > you all missed the point of the question, which was, 'do any Fedora > users have /only one computer/', not 'does anyone use only Fedora'.) Yes, it was at least a two-part question. One is whether you have more than one box - with the implication that in the likely scenario that you do, you'll want to split services among them in various ways and access each from the others. The other is whether Fedora is the best, or even a possible choice for every function. My impression is that even though individual computers are becoming more powerful, in practice things are becoming more distributed and parts are more mobile. While there is a trend toward hiding all of the networking under browser based applications, it is still a mistake to throw away the native ability of X to run about anything anywhere and handle multiple instances on the same box. If you aren't using Fedora for every function, it should still be a good choice for that - and with freenx/NX it is accessible from other platforms as well. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Wed Sep 24 17:22:09 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 24 Sep 2008 12:22:09 -0500 Subject: multiple local X logins by same user In-Reply-To: References: <20080916183444.GA4973@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> <20080923193026.GA12861@tango.0pointer.de> <48D95695.1050108@gmail.com> <20080923233449.GA2076@tango.0pointer.de> Message-ID: <48DA7741.3030401@gmail.com> Matthew Woehlke wrote: > > Erm? Every app that supports running two simultaneous independent > instances (which is to say, 90% or more of all non-trivial apps) won't > even notice they aren't in the same X session. It's only "crazy" for > apps that go ridiculously out of their way to make sure there is only > ever one instance running on a machine. In fact, *other* than Firefox I > can't think of a single program that has this problem. It probably does give an efficiency boost to have the running app open a new window (although if that's what you wanted, you probably would have told it to open a new window instead of starting a new instance...). I suppose it's really for the automated startup when you click a link embedded in some other app though. But while it is going ridiculously out of it's way, you'd think it could check to see if the new invocation you want is running on the same $DISPLAY as the running instance or not. > (^2 I will grant that "last state wins" may be unacceptable for things > like web browser history, which should be not only lossless but possibly > shared, but there are already good solutions for that (usually called > "databases"), and Firefox *is* using SQL these days...) Any number of apps have to deal with shared files, sometimes over networks. -- Les Mikesell lesmikesell at gmail.com From mw_triad at users.sourceforge.net Wed Sep 24 17:23:57 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 24 Sep 2008 12:23:57 -0500 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <48D99FF1.3030000@gmail.com> References: <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> <20080923193026.GA12861@tango.0pointer.de> <48D95695.1050108@gmail.com> <20080923233449.GA2076@tango.0pointer.de> <48D99FF1.3030000@gmail.com> Message-ID: Les Mikesell wrote: > Can you still make apps open with the borders you need to > resize them off the screen completely? If you need borders to resize a window, then you need a better WM :-). Not that there's anything wrong with borders, but a good WM will protect you from this case by providing keyboard shortcuts to begin a resize (and allowing you to use the keyboard to actually resize the window), so that you can still resize even if the borders /are/ off the screen. Of course, a good WM will also not create windows with borders off the screen, so... :-) -- Matthew I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while in a KDE session. And nothing bad happened whatsoever. Try THAT on Windows :-D. From gnomeuser at gmail.com Wed Sep 24 17:46:47 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Wed, 24 Sep 2008 19:46:47 +0200 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <48DA3DEB.8030504@gmail.com> References: <1221592366.32342.23.camel@localhost.localdomain> <20080922180001.GA8379@sonata.rednote.net> <20080923001815.GE21642@tango.0pointer.de> <48D85D71.4020503@gmail.com> <20080923130529.GH7596@tango.0pointer.de> <48D950BB.3030103@gmail.com> <20080923231312.GA338@tango.0pointer.de> <48D9B3D1.70805@gmail.com> <20080924123334.GA18824@tango.0pointer.de> <48DA3DEB.8030504@gmail.com> Message-ID: <1dedbbfc0809241046t8afa5d5hc2428667a203f47e@mail.gmail.com> 2008/9/24 Les Mikesell > > Thinking of your computer as a single piece might make sense for someone > who only has one, but does anyone really run fedora as their one and only > computer? > I have run Linux as my one and only OS for over a decade, right now both machines I own run Fedora and that has been the case basically since FC1 came out. I would happily recommend switching a family' single machine to pure Fedora. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From mailings at x-tnd.be Wed Sep 24 17:48:39 2008 From: mailings at x-tnd.be (Johan Cwiklinski) Date: Wed, 24 Sep 2008 19:48:39 +0200 Subject: Vacation Message-ID: <48DA7D77.9000802@x-tnd.be> Hi, I'll leave this friday (September 26th), and will come back on October 15th approximatively. Regards, Johan From mw_triad at users.sourceforge.net Wed Sep 24 17:54:41 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 24 Sep 2008 12:54:41 -0500 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <48DA74C0.4010602@gmail.com> References: <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <20080922180001.GA8379@sonata.rednote.net> <20080923001815.GE21642@tango.0pointer.de> <48D85D71.4020503@gmail.com> <20080923130529.GH7596@tango.0pointer.de> <48D950BB.3030103@gmail.com> <20080923231312.GA338@tango.0pointer.de> <48D9B3D1.70805@gmail.com> <20080924123334.GA18824@tango.0pointer.de> <48DA3DEB.8030504@gmail.com> <48DA74C0.4010602@gmail.com> Message-ID: Les Mikesell wrote: > Matthew Woehlke wrote: >>> Thinking of your computer as a single piece might make sense for >>> someone who only has one, but does anyone really run fedora as their >>> one and only computer? >> >> That's like saying Fedora should only be targeted at highly tech-savvy >> users, which I have to take issue at. Do we really want to limit >> ourselves to that audience? > > If you don't serve that audience or offer a forward path beyond entry > level, who do you serve and who is going to promote it? Of course we /should/ serve those users, I never suggested otherwise! But should we serve /only/ those users? It's fine and good to make things work for people that do session hopping. I just didn't like how the original question seemed to imply that those are the only people we care about. Maybe you could have asked instead, "do we really expect that no one running Fedora has more then one computer?", which indicates a positive interest in such people without seeming to assume that they are the only group that exists. -- Matthew I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while in a KDE session. And nothing bad happened whatsoever. Try THAT on Windows :-D. From mw_triad at users.sourceforge.net Wed Sep 24 17:59:22 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 24 Sep 2008 12:59:22 -0500 Subject: multiple local X logins by same user In-Reply-To: <200809241804.40399.billcrawford1970@gmail.com> References: <20080916183444.GA4973@sonata.rednote.net> <200809241804.40399.billcrawford1970@gmail.com> Message-ID: (Please do not quote my e-mail address unobfuscated in message bodies.) Bill Crawford wrote: > I put "firefox -Pfoo %u" in a panel icon, with different foo in different > places, and can start three different firefox instances (I have three screens, > and I often use them for different purposes e.g. if I need to log into our web > app under an admin and non-admin user ID at the same time ... this is extremely > useful for testing purposes). > > It's kludgy, but it works. Perhaps even a script that created a profile based on > the display name? "firefox -Pprofile-%DISPLAY" might cut it, if anyone fancies > trying it. Ah, so it's a limitation of the profile support, then? I guess that makes sense, though I still consider it a bug :-). Thanks for the tip, though! -- Matthew I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while in a KDE session. And nothing bad happened whatsoever. Try THAT on Windows :-D. From mw_triad at users.sourceforge.net Wed Sep 24 18:35:11 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 24 Sep 2008 13:35:11 -0500 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <1222253269.26675.4.camel@localhost.localdomain> References: <20080916183444.GA4973@sonata.rednote.net> <20080916201247.GA32741@angus.ind.WPI.EDU> <20080916220527.GC5290@sonata.rednote.net> <1221612043.18922.5.camel@localhost.localdomain> <20080923002543.GF21642@tango.0pointer.de> <48D93F66.9040907@gmail.com> <20080923193026.GA12861@tango.0pointer.de> <48D95695.1050108@gmail.com> <20080923233449.GA2076@tango.0pointer.de> <48D99FF1.3030000@gmail.com> <1222253269.26675.4.camel@localhost.localdomain> Message-ID: Dan Williams wrote: > Are you sure? I was just watching somebody try to use RDP to a Windows > Server 2008 box this weekend and it blanked out the first login and only > allowed the second login direct access. I could be wrong and maybe he > configured it wrong, but I though Windows only allowed one _active_ > login at a time, and suspended the other remote sessions. I fired up two instances of krdc (on separate monitors, great having more than one ;-) ), logged into the same (W2k3) machine as the same (local) user, started a Cygwin session on each, and ran: $ for f in `seq 100 200` ; do sleep 0.1 ; echo $f ; done (I used `seq 500 600` for the other one) ...and watched both of them spit out numbers at the same time. It's not exactly full-motion video, but it was certainly timesharing two active login sessions as the same user. I'm not sure what else you're looking for, but it sure seems to me that it works just fine. Oh, and I also fired up Xephyr, dropped an xterm in it, and ran 'startkde'... as I write this, I have two KDE desktop sessions running (one nested) as the same user. I have yet to see a single good reason (other than "because stripping advanced functionality is the Gnome way") not to support multiple X sessions as the same user. -- Matthew I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while in a KDE session. And nothing bad happened whatsoever. Try THAT on Windows :-D. From lesmikesell at gmail.com Wed Sep 24 19:10:12 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 24 Sep 2008 14:10:12 -0500 Subject: Instant Mirror Status...? In-Reply-To: References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> <48D8154B.9080804@students.iiit.ac.in> <16de708d0809221650n27d4cd7djfa4b39e4ad12ff27@mail.gmail.com> <1222128026.4108.46.camel@luminos.localdomain> <16de708d0809221720r3dad221vac4cb255ccc50490@mail.gmail.com> <48D867D8.40304@gmail.com> <1222153299.29561.7.camel@code.and.org> <48D93690.2070902@gmail.com> Message-ID: <48DA9094.6030503@gmail.com> James Cassell wrote: > Maybe I'm not seeing the entire problem, but couldn't you just cache the > response from mirrormanager, in addition to caching the packages? > Wouldn't everyone then get the same list, and by default, choose the > first (and thus the same) mirror in the list? That's probably the simplest solution. Mirrormanager could just set appropriate expires/cache-control headers for some value of appropriate. But, if you add new mirrors, clients behind proxies wouldn't get them in the list until it expires and if some client behind the proxy gets a copy in a browser and does a refresh it would pull in a different-order copy. By the way, is there a handy way to tell yum not to try ftp:// urls from the list? Sometimes I am behind a squid proxy that will handle them and sometimes I have to use a microsoft isa proxy that won't and there are annoyingly long timeouts for the failures. -- Les Mikesell lesmikesell at gmail.com From lists at timj.co.uk Wed Sep 24 19:26:59 2008 From: lists at timj.co.uk (Tim Jackson) Date: Wed, 24 Sep 2008 20:26:59 +0100 Subject: koji constantly asking me to authenticate Message-ID: <48DA9483.2000104@timj.co.uk> Firefox (3) is constantly prompting me to select a certificate on (almost) every page load of Koji. I have my new client certificate and the new Fedora CA. The authentication *succeeds* but I keep getting prompted. What magic am I missing? Thanks Tim From choeger at cs.tu-berlin.de Wed Sep 24 20:13:17 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 24 Sep 2008 22:13:17 +0200 Subject: please deactivate services by default! Message-ID: <1222287197.3941.7.camel@choeger6> Hi, I have some services found being activated by default that should be removed for the following reasons: 1. sendmail: starts way too slow, is not usefull for any normal desktop user I know. Making it usefull requires configuration so I assume wohever uses that service _can_ activate it. 2. ip6tables: I do not know of any provider actually working with ipv6. So I assume the mass of all users do not need it. 3. isdn: isdn requires configuration and thus should be set to start when that config is actually done. 4. setroubleshootd: That service also takes long to boot, but its quite usefull. I wonder if one could make auditd start setroubleshootd when required - having two daemons working on base of the same informations seems not very clever. So, now go on and punsh me ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From dominik at greysector.net Wed Sep 24 20:23:51 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 24 Sep 2008 22:23:51 +0200 Subject: Fedora rawhide rebuild in mock status 2008-09-23 i386 In-Reply-To: <20080924122147.GA4137@mock.linuxdev.us.dell.com> References: <20080924122147.GA4137@mock.linuxdev.us.dell.com> Message-ID: <20080924202350.GB29032@mokona.greysector.net> On Wednesday, 24 September 2008 at 14:21, Matt Domsch wrote: > Fedora Rawhide-in-Mock Build Results for i386 > using the rawhide tree of Tuesday, 2008-10-23. > dx-4.4.4-6.fc10 (patch_fuzz) rathann Fixed. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From lsof at nodata.co.uk Wed Sep 24 20:32:57 2008 From: lsof at nodata.co.uk (nodata) Date: Wed, 24 Sep 2008 22:32:57 +0200 Subject: please deactivate services by default! In-Reply-To: <1222287197.3941.7.camel@choeger6> References: <1222287197.3941.7.camel@choeger6> Message-ID: <1222288377.2908.3.camel@sb-home> Am Mittwoch, den 24.09.2008, 22:13 +0200 schrieb Christoph H?ger: > Hi, > > I have some services found being activated by default that should be > removed for the following reasons: > > 1. sendmail: starts way too slow, is not usefull for any normal desktop > user I know. Making it usefull requires configuration so I assume > wohever uses that service _can_ activate it. How will you get emails from logwatch and errors from your cron scripts? > 2. ip6tables: I do not know of any provider actually working with ipv6. > So I assume the mass of all users do not need it. This takes no time. > > 3. isdn: isdn requires configuration and thus should be set to start > when that config is actually done. +1 > > 4. setroubleshootd: That service also takes long to boot, but its quite > usefull. I wonder if one could make auditd start setroubleshootd when > required - having two daemons working on base of the same informations > seems not very clever. Bug? > > So, now go on and punsh me ;) > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From dennis at ausil.us Wed Sep 24 20:34:24 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 24 Sep 2008 15:34:24 -0500 Subject: please deactivate services by default! In-Reply-To: <1222287197.3941.7.camel@choeger6> References: <1222287197.3941.7.camel@choeger6> Message-ID: <200809241534.35986.dennis@ausil.us> On Wednesday 24 September 2008 03:13:17 pm Christoph H?ger wrote: > Hi, > > I have some services found being activated by default that should be > removed for the following reasons: > > 1. sendmail: starts way too slow, is not usefull for any normal desktop > user I know. Making it usefull requires configuration so I assume > wohever uses that service _can_ activate it. sendmail is useful out of the box. maybe we should evaluate replacing it with some other option out of the box. we could also maybe look at having firstboot let you configure who gets roots email. which could be a local just created user. or we could add to the user creating a checkbox to get roots email. > 2. ip6tables: I do not know of any provider actually working with ipv6. > So I assume the mass of all users do not need it. I run ipv6 at home as do many other people. if ipv6 was disabled by default maybe it would be ok to disable ip6tables but with ipv6 enabled by default it should also be protected. > 3. isdn: isdn requires configuration and thus should be set to start > when that config is actually done. probably should be disabled > 4. setroubleshootd: That service also takes long to boot, but its quite > usefull. I wonder if one could make auditd start setroubleshootd when > required - having two daemons working on base of the same informations > seems not very clever. would need more input from the folks developing the tools. > So, now go on and punsh me ;) its too late for F-10 for these changes but they could be F-11 features. yes we need to start thinking about them now. Dennis From caillon at redhat.com Wed Sep 24 20:43:27 2008 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 24 Sep 2008 16:43:27 -0400 Subject: rpms/blam/F-9 blam.spec,1.24,1.25 In-Reply-To: References: <20080924060730.2E9F370103@cvs1.fedora.phx.redhat.com> Message-ID: <48DAA66F.7000603@redhat.com> Alex Lancaster wrote: >>>>>> "CA" == Christopher Aillon writes: > > CA> Author: caillon Update of /cvs/extras/rpms/blam/F-9 In directory > CA> cvs1.fedora.phx.redhat.com:/tmp/cvs-serv30824 > > CA> Modified Files: blam.spec Log Message: * Wed Sep 24 2008 > CA> Christopher Aillon - 1.8.5-2 - Rebuild > CA> against newer gecko > > Are you going to bump and rebuild the rawhide/F-10 branch? rawhide is > on: Yes, I intend on doing this for all packages that need it but my first priority is for F8 and F9. > > blam-1.8.5-1.fc10 > > which will cause a broken upgrade path as > > blam-1.8.5-2.fc9 > blam-1.8.5-1.fc10 > > Can you consider bumping the release tag *after* the disttag, i.e.: > > blam-1.8.5-1.fc9.1 > > this would avoid the need to rebuild the rawhide branch. I'm using bumpspecfile.py[1] to do this automatically because manually doing it for 30ish packages just isn't my idea of fun... [1] http://fedoraproject.org/wiki/PackageMaintainers/UsefulScripts#bumpspecfile From jlaska at redhat.com Wed Sep 24 19:10:12 2008 From: jlaska at redhat.com (James Laska) Date: Wed, 24 Sep 2008 15:10:12 -0400 Subject: Fedora Test Day - 2008-09-25 - Live Beta Images and FirstAidKit Message-ID: <1222283412.3319.86.camel@flatline> Greetings folks, I'd like to invite testers and users to join #fedora-qa on Thursday, September 25, 2008. Testing efforts will focus on testing Fedora 10 Beta Live images as well as system recovery using FirstAidKit. Come with questions, bug reports, and/or suggested test areas. More details will be posted to https://fedoraproject.org/wiki/QA/Test_Days/2008-09-25. Thanks, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From walters at verbum.org Wed Sep 24 20:48:28 2008 From: walters at verbum.org (Colin Walters) Date: Wed, 24 Sep 2008 16:48:28 -0400 Subject: please deactivate services by default! In-Reply-To: <1222287197.3941.7.camel@choeger6> References: <1222287197.3941.7.camel@choeger6> Message-ID: 2008/9/24 Christoph H?ger : > Hi, > > I have some services found being activated by default that should be > removed for the following reasons: > > 1. sendmail: starts way too slow, is not usefull for any normal desktop > user I know. Making it usefull requires configuration so I assume > wohever uses that service _can_ activate it. The desktop image no longer installs sendmail by default. From lesmikesell at gmail.com Wed Sep 24 20:50:26 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 24 Sep 2008 15:50:26 -0500 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: References: <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <20080922180001.GA8379@sonata.rednote.net> <20080923001815.GE21642@tango.0pointer.de> <48D85D71.4020503@gmail.com> <20080923130529.GH7596@tango.0pointer.de> <48D950BB.3030103@gmail.com> <20080923231312.GA338@tango.0pointer.de> <48D9B3D1.70805@gmail.com> <20080924123334.GA18824@tango.0pointer.de> <48DA3DEB.8030504@gmail.com> <48DA74C0.4010602@gmail.com> Message-ID: <48DAA812.3030601@gmail.com> Matthew Woehlke wrote: > >>>> Thinking of your computer as a single piece might make sense for >>>> someone who only has one, but does anyone really run fedora as their >>>> one and only computer? >>> >>> That's like saying Fedora should only be targeted at highly >>> tech-savvy users, which I have to take issue at. Do we really want to >>> limit ourselves to that audience? >> >> If you don't serve that audience or offer a forward path beyond entry >> level, who do you serve and who is going to promote it? > > Of course we /should/ serve those users, I never suggested otherwise! > But should we serve /only/ those users? I didn't say that either, but typically the simple case is a subset of the more complex one so if the design is right you don't have to make that choice. > It's fine and good to make things work for people that do session > hopping. I just didn't like how the original question seemed to imply > that those are the only people we care about. I didn't quite mean it like that, but X and unix-like systems just naturally divorce applications and sessions from hardware and it seems wrong to throw that away even if you don't need it today. Especially if it is just to avoid the trouble of properly managing profile data. > Maybe you could have asked instead, "do we really expect that no one > running Fedora has more then one computer?", which indicates a positive > interest in such people without seeming to assume that they are the only > group that exists. I'll go even farther that direction if you want: "do you really expect that no one running fedora will ever have more than one computer?" When/if they do, I'd expect them to want to share resources among them. -- Les Mikesell lesmikesell at gmail.com From caillon at redhat.com Wed Sep 24 20:51:39 2008 From: caillon at redhat.com (Christopher Aillon) Date: Wed, 24 Sep 2008 16:51:39 -0400 Subject: rpms/blam/F-9 blam.spec,1.24,1.25 In-Reply-To: <48D9ED0F.6040804@leemhuis.info> References: <20080924060730.2E9F370103@cvs1.fedora.phx.redhat.com> <48D9ED0F.6040804@leemhuis.info> Message-ID: <48DAA85B.8040401@redhat.com> Thorsten Leemhuis wrote: > On 24.09.2008 08:46, Alex Lancaster wrote: >>>>>>> "CA" == Christopher Aillon writes: >> >> CA> Author: caillon Update of /cvs/extras/rpms/blam/F-9 In directory >> CA> cvs1.fedora.phx.redhat.com:/tmp/cvs-serv30824 >> >> CA> Modified Files: blam.spec Log Message: * Wed Sep 24 2008 >> CA> Christopher Aillon - 1.8.5-2 - Rebuild >> CA> against newer gecko >> >> Are you going to bump and rebuild the rawhide/F-10 branch? rawhide is >> on: >> >> blam-1.8.5-1.fc10 >> >> which will cause a broken upgrade path as >> blam-1.8.5-2.fc9 > blam-1.8.5-1.fc10 >> >> Can you consider bumping the release tag *after* the disttag, i.e.: >> >> blam-1.8.5-1.fc9.1 >> >> this would avoid the need to rebuild the rawhide branch. > > In case anybody is interested: a rough and not much tested patch(?) that > makes rpmdev-bumpspec from rpmdevtools optionally bump the rightmost > part of the release field can be found in: > > https://fedorahosted.org/rpmdevtools/ticket/1 I'd also like to see it bump 1.1{?dist} -> 1.2{?dist} instead of 2.1{?dist} without needing to pass an option. From smooge at gmail.com Wed Sep 24 20:57:22 2008 From: smooge at gmail.com (Stephen John Smoogen) Date: Wed, 24 Sep 2008 14:57:22 -0600 Subject: please deactivate services by default! In-Reply-To: <1222288377.2908.3.camel@sb-home> References: <1222287197.3941.7.camel@choeger6> <1222288377.2908.3.camel@sb-home> Message-ID: <80d7e4090809241357x7de30e0bv1e42bbb8c020b0ce@mail.gmail.com> On Wed, Sep 24, 2008 at 2:32 PM, nodata wrote: > Am Mittwoch, den 24.09.2008, 22:13 +0200 schrieb Christoph H?ger: >> Hi, >> >> I have some services found being activated by default that should be >> removed for the following reasons: >> >> 1. sendmail: starts way too slow, is not usefull for any normal desktop >> user I know. Making it usefull requires configuration so I assume >> wohever uses that service _can_ activate it. > > How will you get emails from logwatch and errors from your cron scripts? > >> 2. ip6tables: I do not know of any provider actually working with ipv6. >> So I assume the mass of all users do not need it. > Not having ipv6 firewall means that you aren't protected if someone wants to walk your 'local' network via ipv6. ping6 -I eth0 ff02::1 walk the hosts with no firewalls. I am guessing that turning off ipv6 altogether would be a better idea, but I do not know what effect that has on things like ipsec etc. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice" From lesmikesell at gmail.com Wed Sep 24 21:04:09 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 24 Sep 2008 16:04:09 -0500 Subject: please deactivate services by default! In-Reply-To: <1222287197.3941.7.camel@choeger6> References: <1222287197.3941.7.camel@choeger6> Message-ID: <48DAAB49.7050807@gmail.com> Christoph H?ger wrote: > Hi, > > I have some services found being activated by default that should be > removed for the following reasons: > > 1. sendmail: starts way too slow, Sendmail startup should only be slow if your dns is broken or you've removed the localhost entry from your hosts file. Either of those needs to be fixed anyway. > is not usefull for any normal desktop > user I know. > > So, now go on and punsh me ;) > Maybe you should meet some more users. -- Les Mikesell lesmikesell at gmail.com From denis at poolshark.org Wed Sep 24 21:13:22 2008 From: denis at poolshark.org (Denis Leroy) Date: Wed, 24 Sep 2008 23:13:22 +0200 Subject: Vacation In-Reply-To: <48DA7D77.9000802@x-tnd.be> References: <48DA7D77.9000802@x-tnd.be> Message-ID: <48DAAD72.5040701@poolshark.org> Johan Cwiklinski wrote: > Hi, > > I'll leave this friday (September 26th), and will come back on October > 15th approximatively. Johan, is Alain Portal still banned from your Fedora forum ? He's still bugging me about it by email. -d From dimi at lattica.com Wed Sep 24 21:15:34 2008 From: dimi at lattica.com (Dimi Paun) Date: Wed, 24 Sep 2008 17:15:34 -0400 Subject: please deactivate services by default! In-Reply-To: <48DAAB49.7050807@gmail.com> References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> Message-ID: <1222290934.5774.35.camel@dimi.lattica.com> On Wed, 2008-09-24 at 16:04 -0500, Les Mikesell wrote: > Sendmail startup should only be slow if your dns is broken or you've > removed the localhost entry from your hosts file. Either of those > needs to be fixed anyway. Give me a break. What naive user would know what to do with the thing? Even if it takes 200ms to load it's way too much. -- Dimi Paun Lattica, Inc. From mw_triad at users.sourceforge.net Wed Sep 24 21:20:59 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 24 Sep 2008 16:20:59 -0500 Subject: Tried Pulse Audio Again--No Good For A11y In-Reply-To: <48DAA812.3030601@gmail.com> References: <1221592366.32342.23.camel@localhost.localdomain> <20080916212827.GA5290@sonata.rednote.net> <1221647994.1454.16.camel@gibraltar.str.redhat.com> <20080922180001.GA8379@sonata.rednote.net> <20080923001815.GE21642@tango.0pointer.de> <48D85D71.4020503@gmail.com> <20080923130529.GH7596@tango.0pointer.de> <48D950BB.3030103@gmail.com> <20080923231312.GA338@tango.0pointer.de> <48D9B3D1.70805@gmail.com> <20080924123334.GA18824@tango.0pointer.de> <48DA3DEB.8030504@gmail.com> <48DA74C0.4010602@gmail.com> <48DAA812.3030601@gmail.com> Message-ID: Les Mikesell wrote: > Matthew Woehlke wrote: >> It's fine and good to make things work for people that do session >> hopping. I just didn't like how the original question seemed to imply >> that those are the only people we care about. > > I didn't quite mean it like that, but X and unix-like systems just > naturally divorce applications and sessions from hardware and it seems > wrong to throw that away even if you don't need it today. Especially if > it is just to avoid the trouble of properly managing profile data. Indeed; that's almost exactly what I said ranting about Firefox :-D. I'm very much on your side here (just so long as we don't forget the trivial case ;-) ). >> Maybe you could have asked instead, "do we really expect that no one >> running Fedora has more then one computer?", which indicates a >> positive interest in such people without seeming to assume that they >> are the only group that exists. > > I'll go even farther that direction if you want: "do you really expect > that no one running fedora will ever have more than one computer?" > When/if they do, I'd expect them to want to share resources among them. I considered that addition to be implied, but yes, that's certainly fine. Thanks. It's just that the original wording bugged me :-). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while in a KDE session. And nothing bad happened whatsoever. Try THAT on Windows :-D. From cmadams at hiwaay.net Wed Sep 24 21:22:36 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 24 Sep 2008 16:22:36 -0500 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> Message-ID: <20080924212236.GJ1414283@hiwaay.net> Once upon a time, Colin Walters said: > The desktop image no longer installs sendmail by default. What SMTP server is installed now? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From triad at df.lth.se Wed Sep 24 21:24:15 2008 From: triad at df.lth.se (Linus Walleij) Date: Wed, 24 Sep 2008 23:24:15 +0200 Subject: please deactivate services by default! In-Reply-To: <1222287197.3941.7.camel@choeger6> References: <1222287197.3941.7.camel@choeger6> Message-ID: <1222291455.4384.15.camel@c83-254-39-236.bredband.comhem.se> ons 2008-09-24 klockan 22:13 +0200 skrev Christoph H?ger: > I have some services found being activated by default that should be > removed for the following reasons: Seems to match the findings from Arjans recent fastboot-excersise quite well. > 1. sendmail: starts way too slow, is not usefull for any normal desktop > user I know. Making it usefull requires configuration so I assume > wohever uses that service _can_ activate it. The server people and large installation maintainers really like these mails AFAIK, for desktop/laptop you administer yourself I never quite understood how to actually read them execept for less /var/spool/mail/root OK what's in there after a few months daily use on this self-managed desktop: * logwatch disk space messages, and the diskspace is low, well wouldn't it be better to have this as a desktop popup like "you have mail" actually, mailing it to root sort of implies that you have someone else managing you disks/system. * SELinux audit trail, reflecting normal usage and expected mistakes and yum updates (like I didn't know, only root can do them!) Useful information for the use cases where end-user and administrator is seldom/never the same person. The admin will forward these mails to their main inbox or whatever and grep it for stuff they need to know I believe, and collect stats? Then they could presumably also turn on this when they install the system and Fedora could leave it off in the default install, no? Linus From triad at df.lth.se Wed Sep 24 21:25:27 2008 From: triad at df.lth.se (Linus Walleij) Date: Wed, 24 Sep 2008 23:25:27 +0200 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> Message-ID: <1222291527.4384.17.camel@c83-254-39-236.bredband.comhem.se> ons 2008-09-24 klockan 16:48 -0400 skrev Colin Walters: > The desktop image no longer installs sendmail by default. Cool, problem solved. Linus From pemboa at gmail.com Wed Sep 24 21:25:40 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 24 Sep 2008 16:25:40 -0500 Subject: please deactivate services by default! In-Reply-To: <1222287197.3941.7.camel@choeger6> References: <1222287197.3941.7.camel@choeger6> Message-ID: <16de708d0809241425o6a241428y8dd3469f54d5f208@mail.gmail.com> 2008/9/24 Christoph H?ger : > Hi, > > I have some services found being activated by default that should be > removed for the following reasons: > > 1. sendmail: starts way too slow, is not usefull for any normal desktop > user I know. Making it usefull requires configuration so I assume > wohever uses that service _can_ activate it. Agreed > 2. ip6tables: I do not know of any provider actually working with ipv6. > So I assume the mass of all users do not need it. Agreed -- but should be auto done based on packages chosen on install > 3. isdn: isdn requires configuration and thus should be set to start > when that config is actually done. Agreed > 4. setroubleshootd: That service also takes long to boot, but its quite > usefull. I wonder if one could make auditd start setroubleshootd when > required - having two daemons working on base of the same informations > seems not very clever. We need setroubleshootd > So, now go on and punsh me ;) 5 laps around the neighbourhood -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From lsof at nodata.co.uk Wed Sep 24 21:25:41 2008 From: lsof at nodata.co.uk (nodata) Date: Wed, 24 Sep 2008 23:25:41 +0200 Subject: please deactivate services by default! In-Reply-To: <1222291455.4384.15.camel@c83-254-39-236.bredband.comhem.se> References: <1222287197.3941.7.camel@choeger6> <1222291455.4384.15.camel@c83-254-39-236.bredband.comhem.se> Message-ID: <1222291541.2912.0.camel@sb-home> Am Mittwoch, den 24.09.2008, 23:24 +0200 schrieb Linus Walleij: > ons 2008-09-24 klockan 22:13 +0200 skrev Christoph H?ger: > > > I have some services found being activated by default that should be > > removed for the following reasons: > > Seems to match the findings from Arjans recent fastboot-excersise quite > well. > > > 1. sendmail: starts way too slow, is not usefull for any normal desktop > > user I know. Making it usefull requires configuration so I assume > > wohever uses that service _can_ activate it. > > The server people and large installation maintainers really like these > mails AFAIK, for desktop/laptop you administer yourself I never quite > understood how to actually read them execept for > less /var/spool/mail/root # mail or # mutt > > OK what's in there after a few months daily use on this self-managed > desktop: > > * logwatch disk space messages, and the diskspace is low, well wouldn't > it be better to have this as a desktop popup like "you have mail" > actually, mailing it to root sort of implies that you have someone else > managing you disks/system. > > * SELinux audit trail, reflecting normal usage and expected mistakes and > yum updates (like I didn't know, only root can do them!) > > Useful information for the use cases where end-user and administrator is > seldom/never the same person. The admin will forward these mails to > their main inbox or whatever and grep it for stuff they need to know I > believe, and collect stats? > > Then they could presumably also turn on this when they install the > system and Fedora could leave it off in the default install, no? > > Linus > From walters at verbum.org Wed Sep 24 21:26:22 2008 From: walters at verbum.org (Colin Walters) Date: Wed, 24 Sep 2008 17:26:22 -0400 Subject: please deactivate services by default! In-Reply-To: <20080924212236.GJ1414283@hiwaay.net> References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> Message-ID: On Wed, Sep 24, 2008 at 5:22 PM, Chris Adams wrote: > Once upon a time, Colin Walters said: >> The desktop image no longer installs sendmail by default. > > What SMTP server is installed now? None. From arjan at infradead.org Wed Sep 24 21:26:46 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Wed, 24 Sep 2008 14:26:46 -0700 Subject: please deactivate services by default! In-Reply-To: <48DAAB49.7050807@gmail.com> References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> Message-ID: <20080924142646.1e766949@infradead.org> On Wed, 24 Sep 2008 16:04:09 -0500 Les Mikesell wrote: > Christoph H?ger wrote: > > Hi, > > > > I have some services found being activated by default that should be > > removed for the following reasons: > > > > 1. sendmail: starts way too slow, > > Sendmail startup should only be slow if your dns is broken or you've > removed the localhost entry from your hosts file. Either of those > needs to be fixed anyway. the slow part is the aliases generation. anyone not using their machine as a mail server really doesn't need sendmail ;( ("slow" is relative, for me, anything taking more than 0.5 seconds is slow) -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org From sundaram at fedoraproject.org Wed Sep 24 21:28:27 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 25 Sep 2008 02:58:27 +0530 Subject: please deactivate services by default! In-Reply-To: <20080924212236.GJ1414283@hiwaay.net> References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> Message-ID: <48DAB0FB.8000408@fedoraproject.org> Chris Adams wrote: > Once upon a time, Colin Walters said: >> The desktop image no longer installs sendmail by default. > > What SMTP server is installed now? None. It is a desktop live cd. Rahul From mailings at x-tnd.be Wed Sep 24 21:30:18 2008 From: mailings at x-tnd.be (Johan Cwiklinski) Date: Wed, 24 Sep 2008 23:30:18 +0200 Subject: Vacation In-Reply-To: <48DAAD72.5040701@poolshark.org> References: <48DA7D77.9000802@x-tnd.be> <48DAAD72.5040701@poolshark.org> Message-ID: <48DAB16A.7040808@x-tnd.be> Denis Leroy a ?crit : > Johan Cwiklinski wrote: >> Hi, >> >> I'll leave this friday (September 26th), and will come back on October >> 15th approximatively. > > Johan, is Alain Portal still banned from your Fedora forum ? He's > still bugging me about it by email. > > -d > Hi, He has been debanned from http://forum.fedora-fr.org for a while ; he recently posts messages on the forum, and complains here once again: https://www.redhat.com/archives/fedora-devel-list/2008-September/msg01565.html As you can see on these page : http://forums.fedora-fr.org/profile.php?id=8065 ; he posted a message yesterday, at 6:32PM (hour from Paris). I've just checked - just in case - and he is currently not banned. Regards, Johan From cmadams at hiwaay.net Wed Sep 24 21:31:13 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 24 Sep 2008 16:31:13 -0500 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> Message-ID: <20080924213113.GK1414283@hiwaay.net> Once upon a time, Colin Walters said: > On Wed, Sep 24, 2008 at 5:22 PM, Chris Adams wrote: > > Once upon a time, Colin Walters said: > >> The desktop image no longer installs sendmail by default. > > > > What SMTP server is installed now? > > None. So what happens to messages from cron jobs and other standard Unix stuff that expects /bin/mail or /usr/sbin/sendmail to do something useful? What about mail clients like (IIRC) mutt that don't have an SMTP client built in? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From choeger at cs.tu-berlin.de Wed Sep 24 21:31:40 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 24 Sep 2008 23:31:40 +0200 Subject: please deactivate services by default! In-Reply-To: <48DAAB49.7050807@gmail.com> References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> Message-ID: <1222291900.3941.14.camel@choeger6> Am Mittwoch, den 24.09.2008, 16:04 -0500 schrieb Les Mikesell: > Christoph H?ger wrote: > > Hi, > > > > I have some services found being activated by default that should be > > removed for the following reasons: > > > > 1. sendmail: starts way too slow, > > Sendmail startup should only be slow if your dns is broken or you've > removed the localhost entry from your hosts file. Either of those needs > to be fixed anyway. > I have localhost setup, I also run a dns server in my LAN, but I tend to use NM for setup maybe thats the reason. But still my sendmail needs 1.5s to start - That is way too much. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From cmadams at hiwaay.net Wed Sep 24 21:35:04 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 24 Sep 2008 16:35:04 -0500 Subject: please deactivate services by default! In-Reply-To: <20080924142646.1e766949@infradead.org> References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> <20080924142646.1e766949@infradead.org> Message-ID: <20080924213504.GL1414283@hiwaay.net> Once upon a time, Arjan van de Ven said: > the slow part is the aliases generation. So don't do that. :-) I always thought that was a bad idea in the init script anyway (that goes for all the rebuilding done in there). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From choeger at cs.tu-berlin.de Wed Sep 24 21:35:27 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Wed, 24 Sep 2008 23:35:27 +0200 Subject: please deactivate services by default! In-Reply-To: <16de708d0809241425o6a241428y8dd3469f54d5f208@mail.gmail.com> References: <1222287197.3941.7.camel@choeger6> <16de708d0809241425o6a241428y8dd3469f54d5f208@mail.gmail.com> Message-ID: <1222292127.3941.17.camel@choeger6> Am Mittwoch, den 24.09.2008, 16:25 -0500 schrieb Arthur Pemberton: > > Agreed nice :) > > > 4. setroubleshootd: That service also takes long to boot, but its quite > > usefull. I wonder if one could make auditd start setroubleshootd when > > required - having two daemons working on base of the same informations > > seems not very clever. > > We need setroubleshootd Yes, I know. But do we need it to startup sooo slow every time? Can't we have it start, when its actually needed? > > > So, now go on and punsh me ;) > > 5 laps around the neighbourhood > Did my 6kms today. Ok for you? ;) > -- > Fedora 9 : sulphur is good for the skin > ( www.pembo13.com ) > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From walters at verbum.org Wed Sep 24 21:35:27 2008 From: walters at verbum.org (Colin Walters) Date: Wed, 24 Sep 2008 17:35:27 -0400 Subject: please deactivate services by default! In-Reply-To: <20080924213113.GK1414283@hiwaay.net> References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> Message-ID: On Wed, Sep 24, 2008 at 5:31 PM, Chris Adams wrote: > Once upon a time, Colin Walters said: >> On Wed, Sep 24, 2008 at 5:22 PM, Chris Adams wrote: >> > Once upon a time, Colin Walters said: >> >> The desktop image no longer installs sendmail by default. >> > >> > What SMTP server is installed now? >> >> None. > > So what happens to messages from cron jobs and other standard Unix stuff > that expects /bin/mail or /usr/sbin/sendmail to do something useful? If there are cron jobs that send mail, we will deactivate them. > What about mail clients like (IIRC) mutt that don't have an SMTP client > built in? You can install sendmail or some other server. From cmadams at hiwaay.net Wed Sep 24 21:38:34 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 24 Sep 2008 16:38:34 -0500 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> Message-ID: <20080924213834.GM1414283@hiwaay.net> Once upon a time, Colin Walters said: > On Wed, Sep 24, 2008 at 5:31 PM, Chris Adams wrote: > > What about mail clients like (IIRC) mutt that don't have an SMTP client > > built in? > > You can install sendmail or some other server. If that's the expected way, then there should have been an announcement so everything that requires SMTP (like mutt) can be modified to have "Requires: smtpdaemon". -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From walters at verbum.org Wed Sep 24 21:43:37 2008 From: walters at verbum.org (Colin Walters) Date: Wed, 24 Sep 2008 17:43:37 -0400 Subject: please deactivate services by default! In-Reply-To: <20080924213834.GM1414283@hiwaay.net> References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <20080924213834.GM1414283@hiwaay.net> Message-ID: On Wed, Sep 24, 2008 at 5:38 PM, Chris Adams wrote: > Once upon a time, Colin Walters said: >> On Wed, Sep 24, 2008 at 5:31 PM, Chris Adams wrote: >> > What about mail clients like (IIRC) mutt that don't have an SMTP client >> > built in? >> >> You can install sendmail or some other server. > > If that's the expected way, then there should have been an announcement > so everything that requires SMTP (like mutt) can be modified to have > "Requires: smtpdaemon". Please do so =) From mschwendt at gmail.com Wed Sep 24 21:56:16 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Wed, 24 Sep 2008 23:56:16 +0200 Subject: rpms/blam/F-9 blam.spec,1.24,1.25 In-Reply-To: <48DAA85B.8040401@redhat.com> References: <20080924060730.2E9F370103@cvs1.fedora.phx.redhat.com> <48D9ED0F.6040804@leemhuis.info> <48DAA85B.8040401@redhat.com> Message-ID: <20080924235616.1101dc68.mschwendt@gmail.com> On Wed, 24 Sep 2008 16:51:39 -0400, Christopher Aillon wrote: [bumpspecfile] > I'd also like to see it bump 1.1{?dist} -> 1.2{?dist} instead of > 2.1{?dist} without needing to pass an option. It was made to cover the most common versioning schemes used in the Fedora package collection without passing an option. How does it know whether Y in X.Y is not a cvs/svn/post-release/date identifier or number that it must not touch? Such as: 1.0-1.a%{?dist} for version 1.0a (post-1.0 update) 1.0-1.20080901%{?dist} for a scm checkout Side-note: 1.1%{?dist} to begin with may be fine, but only if you use exactly the same versioning scheme for all %dists. Else you break the upgrade path too easily, e.g. if an older dist bumps 1%{?dist} to 1.1%{?dist}, which then compares .1 to %{?dist}, and 1 is greater than all fedora dist tags. From mw_triad at users.sourceforge.net Wed Sep 24 22:03:07 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 24 Sep 2008 17:03:07 -0500 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> Message-ID: Colin Walters wrote: > On Wed, Sep 24, 2008 at 5:31 PM, Chris Adams wrote: >> Once upon a time, Colin Walters said: >>> On Wed, Sep 24, 2008 at 5:22 PM, Chris Adams wrote: >>>> Once upon a time, Colin Walters said: >>>>> The desktop image no longer installs sendmail by default. >>>> What SMTP server is installed now? >>> None. >> So what happens to messages from cron jobs and other standard Unix stuff >> that expects /bin/mail or /usr/sbin/sendmail to do something useful? > > If there are cron jobs that send mail, we will deactivate them. So... you just broke cron? I use rsync for nightly backup. It makes noise. Ergo, I get mail. Are you saying my *nightly backup* suddenly won't work? Or at best, I will have no way of knowing if any errors occurred? I really hope I'm missing something... -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while in a KDE session. And nothing bad happened whatsoever. Try THAT on Windows :-D. From dtimms at iinet.net.au Wed Sep 24 22:09:40 2008 From: dtimms at iinet.net.au (David Timms) Date: Thu, 25 Sep 2008 08:09:40 +1000 Subject: please deactivate services by default! sendmail|sm-client In-Reply-To: <20080924142646.1e766949@infradead.org> References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> <20080924142646.1e766949@infradead.org> Message-ID: <48DABAA4.3020902@iinet.net.au> Arjan van de Ven wrote: > On Wed, 24 Sep 2008 16:04:09 -0500 > Les Mikesell wrote: > >> Christoph H??ger wrote: >>> Hi, >>> >>> I have some services found being activated by default that should be >>> removed for the following reasons: >>> >>> 1. sendmail: starts way too slow, >> Sendmail startup should only be slow if your dns is broken or you've >> removed the localhost entry from your hosts file. Either of those >> needs to be fixed anyway. > > the slow part is the aliases generation. > > anyone not using their machine as a mail server really doesn't need > sendmail ;( > > ("slow" is relative, for me, anything taking more than 0.5 seconds is > slow) So waiting during bootup for 2 minutes for sendmail to look up it's own {non-existent} ip address inside a nat network, then another minute for sm-client to do the same wouldn't be acceptable to you then ? Glad I'm not the only one who thinks delays above a second should be improved: https://bugzilla.redhat.com/show_bug.cgi?id=238308 DaveT. From sundaram at fedoraproject.org Wed Sep 24 22:13:00 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 25 Sep 2008 03:43:00 +0530 Subject: please deactivate services by default! sendmail|sm-client In-Reply-To: <48DABAA4.3020902@iinet.net.au> References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> <20080924142646.1e766949@infradead.org> <48DABAA4.3020902@iinet.net.au> Message-ID: <48DABB6C.3050201@fedoraproject.org> David Timms wrote: > > Glad I'm not the only one who thinks delays above a second should be > improved: https://bugzilla.redhat.com/show_bug.cgi?id=238308 Bug report says closed due to need info. Maybe you should reopen and provide the information requested. Rahul From arjan at infradead.org Wed Sep 24 22:14:31 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Wed, 24 Sep 2008 15:14:31 -0700 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> Message-ID: <20080924151431.41ba4a45@infradead.org> On Wed, 24 Sep 2008 17:35:27 -0400 "Colin Walters" wrote: > On Wed, Sep 24, 2008 at 5:31 PM, Chris Adams > wrote: > > Once upon a time, Colin Walters said: > >> On Wed, Sep 24, 2008 at 5:22 PM, Chris Adams > >> wrote: > >> > Once upon a time, Colin Walters said: > >> >> The desktop image no longer installs sendmail by default. > >> > > >> > What SMTP server is installed now? > >> > >> None. > > > > So what happens to messages from cron jobs and other standard Unix > > stuff that expects /bin/mail or /usr/sbin/sendmail to do something > > useful? > > If there are cron jobs that send mail, we will deactivate them. > > > What about mail clients like (IIRC) mutt that don't have an SMTP > > client built in? > > You can install sendmail or some other server. ssmtp seems what various other distros use for "tiny low overhead send only servers" > -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org From lesmikesell at gmail.com Wed Sep 24 22:16:19 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 24 Sep 2008 17:16:19 -0500 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> Message-ID: <48DABC33.10005@gmail.com> Colin Walters wrote: > >>>> Once upon a time, Colin Walters said: >>>>> The desktop image no longer installs sendmail by default. >>>> What SMTP server is installed now? >>> None. >> So what happens to messages from cron jobs and other standard Unix stuff >> that expects /bin/mail or /usr/sbin/sendmail to do something useful? > > If there are cron jobs that send mail, we will deactivate them. Errr... cron itself sends mail on behalf of _any_ job that generates output to stdout/stderr. It is expected behavior. -- Les Mikesell lesmikesell at gmail.com From mschwendt at gmail.com Wed Sep 24 22:18:05 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 25 Sep 2008 00:18:05 +0200 Subject: rpms/blam/F-9 blam.spec,1.24,1.25 In-Reply-To: <48D9ED0F.6040804@leemhuis.info> References: <20080924060730.2E9F370103@cvs1.fedora.phx.redhat.com> <48D9ED0F.6040804@leemhuis.info> Message-ID: <20080925001805.cb1f9b1c.mschwendt@gmail.com> On Wed, 24 Sep 2008 09:32:31 +0200, Thorsten Leemhuis wrote: > In case anybody is interested: a rough and not much tested patch(?) that > makes rpmdev-bumpspec from rpmdevtools optionally bump the rightmost > part of the release field can be found in: > > https://fedorahosted.org/rpmdevtools/ticket/1 > > CU > knurd > > (?) done by someone with only basic python and programming skills ;-) The patch looks harmless, but I wonder whether the script's users will remember to use that option when bumping old branches only. I wonder even more why rpmdev-bumpspec says Copyright (c) 2005-2008 Red Hat Inc. which is not correct. 2005 may be true for its origin, the pre-Fedora Extras era. For the first mass-rebuilds and beyond that it was developed further by me, and just because I don't want to claim full copyright, it should not be given to Red Hat for 2006-2008. That sounds very wrong to me, because nobody at Red Hat has been an author of changes to the script in those years. From choeger at cs.tu-berlin.de Wed Sep 24 22:22:18 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Thu, 25 Sep 2008 00:22:18 +0200 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> Message-ID: <1222294938.3941.20.camel@choeger6> > I really hope I'm missing something... calm down! No one will break your system. In the worst case you would simply have to enable sendmail. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From walters at verbum.org Wed Sep 24 22:34:09 2008 From: walters at verbum.org (Colin Walters) Date: Wed, 24 Sep 2008 18:34:09 -0400 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> Message-ID: On Wed, Sep 24, 2008 at 6:03 PM, Matthew Woehlke wrote: > > So... you just broke cron? I use rsync for nightly backup. It makes noise. > Ergo, I get mail. Are you saying my *nightly backup* suddenly won't work? Or > at best, I will have no way of knowing if any errors occurred? I've swapped in ssmtp instead of sendmail now. From lesmikesell at gmail.com Wed Sep 24 22:35:21 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 24 Sep 2008 17:35:21 -0500 Subject: please deactivate services by default! In-Reply-To: <20080924142646.1e766949@infradead.org> References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> <20080924142646.1e766949@infradead.org> Message-ID: <48DAC0A9.9040907@gmail.com> Arjan van de Ven wrote: > >>> I have some services found being activated by default that should be >>> removed for the following reasons: >>> >>> 1. sendmail: starts way too slow, >> Sendmail startup should only be slow if your dns is broken or you've >> removed the localhost entry from your hosts file. Either of those >> needs to be fixed anyway. > > the slow part is the aliases generation. Oh, if only unix-like systems had a common tool to quickly determine if the source text file is newer than the dependent db... -- Les Mikesell lesmikesell at gmail.com From cra at WPI.EDU Wed Sep 24 22:36:57 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 24 Sep 2008 18:36:57 -0400 Subject: please deactivate services by default! In-Reply-To: <80d7e4090809241357x7de30e0bv1e42bbb8c020b0ce@mail.gmail.com> References: <1222287197.3941.7.camel@choeger6> <1222288377.2908.3.camel@sb-home> <80d7e4090809241357x7de30e0bv1e42bbb8c020b0ce@mail.gmail.com> Message-ID: <20080924223657.GJ31922@angus.ind.WPI.EDU> On Wed, Sep 24, 2008 at 02:57:22PM -0600, Stephen John Smoogen wrote: > Not having ipv6 firewall means that you aren't protected if someone > wants to walk your 'local' network via ipv6. > > ping6 -I eth0 ff02::1 > > walk the hosts with no firewalls. I am guessing that turning off ipv6 > altogether would be a better idea, but I do not know what effect that > has on things like ipsec etc. No no no! IPv6 needs to stay on by default. We've had discussions about this before. Please don't disable IPv6 by default. And yes, this means that ip6tables should be on by default too, for the exact reason Smooge points out above. From cra at WPI.EDU Wed Sep 24 22:40:22 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Wed, 24 Sep 2008 18:40:22 -0400 Subject: please deactivate services by default! In-Reply-To: <16de708d0809241425o6a241428y8dd3469f54d5f208@mail.gmail.com> References: <1222287197.3941.7.camel@choeger6> <16de708d0809241425o6a241428y8dd3469f54d5f208@mail.gmail.com> Message-ID: <20080924224022.GK31922@angus.ind.WPI.EDU> On Wed, Sep 24, 2008 at 04:25:40PM -0500, Arthur Pemberton wrote: > 2008/9/24 Christoph H?ger : > > 2. ip6tables: I do not know of any provider actually working with ipv6. > > So I assume the mass of all users do not need it. > > Agreed -- but should be auto done based on packages chosen on install No. Everyone today has IPv6, but may not realize it. For example, link-local and automatic tunnels. We must have a firewall to protect the system from these entry points. From orion at cora.nwra.com Wed Sep 24 22:41:08 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 24 Sep 2008 16:41:08 -0600 Subject: debuginfo package dependencies Message-ID: <48DAC204.7000901@cora.nwra.com> Going to install httpd-debuginfo and php-debuginfo: ---> Package httpd-debuginfo.i386 0:2.2.9-1.fc9 set to be updated --> Processing Dependency: mod_ssl.so for package: httpd-debuginfo ---> Package php-debuginfo.i386 0:5.2.6-2.fc9 set to be updated --> Processing Dependency: xmlreader.so for package: php-debuginfo --> Processing Dependency: libphp5-5.2.6.so for package: php-debuginfo --> Processing Dependency: tidy.so for package: php-debuginfo --> Processing Dependency: pgsql.so for package: php-debuginfo --> Processing Dependency: gd.so for package: php-debuginfo --> Processing Dependency: xmlwriter.so for package: php-debuginfo --> Processing Dependency: dba.so for package: php-debuginfo --> Processing Dependency: imap.so for package: php-debuginfo --> Processing Dependency: dom.so for package: php-debuginfo --> Processing Dependency: mhash.so for package: php-debuginfo --> Processing Dependency: mcrypt.so for package: php-debuginfo --> Processing Dependency: xsl.so for package: php-debuginfo --> Processing Dependency: ldap.so for package: php-debuginfo --> Processing Dependency: xmlrpc.so for package: php-debuginfo --> Processing Dependency: ncurses.so for package: php-debuginfo --> Processing Dependency: bcmath.so for package: php-debuginfo --> Processing Dependency: pdo_pgsql.so for package: php-debuginfo --> Processing Dependency: mbstring.so for package: php-debuginfo --> Processing Dependency: odbc.so for package: php-debuginfo --> Processing Dependency: mssql.so for package: php-debuginfo --> Processing Dependency: pdo_odbc.so for package: php-debuginfo --> Processing Dependency: pspell.so for package: php-debuginfo --> Processing Dependency: soap.so for package: php-debuginfo Are these dependencies in the debuginfo packages really appropriate? I'm not going to be debugging these extra code paths - just the packages already installed. Should this get fixed? Where? -- 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 dominik at greysector.net Wed Sep 24 22:44:23 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 25 Sep 2008 00:44:23 +0200 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <20080924213834.GM1414283@hiwaay.net> Message-ID: <20080924224422.GC29032@mokona.greysector.net> On Wednesday, 24 September 2008 at 23:43, Colin Walters wrote: > On Wed, Sep 24, 2008 at 5:38 PM, Chris Adams wrote: > > Once upon a time, Colin Walters said: > >> On Wed, Sep 24, 2008 at 5:31 PM, Chris Adams wrote: > >> > What about mail clients like (IIRC) mutt that don't have an SMTP client > >> > built in? > >> > >> You can install sendmail or some other server. > > > > If that's the expected way, then there should have been an announcement > > so everything that requires SMTP (like mutt) can be modified to have > > "Requires: smtpdaemon". > > Please do so =) I believe mutt already does. In fact, nothing non-sendmail-specific requires sendmail explicitly: $ repoquery --whatrequires sendmail dkim-milter-0:2.5.1-5.fc9.x86_64 sendmail-devel-0:8.14.2-4.fc9.x86_64 sendmail-devel-0:8.14.2-4.fc9.i386 milter-regex-0:1.7-3.fc9.x86_64 spamass-milter-0:0.3.1-7.fc9.x86_64 clamav-milter-sendmail-0:0.93-0.1.rc1.fc9.x86_64 spamass-milter-0:0.3.1-8.fc9.x86_64 sendmail-cf-0:8.14.2-4.fc9.x86_64 clamav-milter-sendmail-0:0.93.3-1.fc9.x86_64 sendmail-doc-0:8.14.2-4.fc9.x86_64 Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From dominik at greysector.net Wed Sep 24 22:46:37 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 25 Sep 2008 00:46:37 +0200 Subject: please deactivate services by default! In-Reply-To: <48DAC0A9.9040907@gmail.com> References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> <20080924142646.1e766949@infradead.org> <48DAC0A9.9040907@gmail.com> Message-ID: <20080924224637.GD29032@mokona.greysector.net> On Thursday, 25 September 2008 at 00:35, Les Mikesell wrote: > Arjan van de Ven wrote: > > > >>>I have some services found being activated by default that should be > >>>removed for the following reasons: > >>> > >>>1. sendmail: starts way too slow, > >>Sendmail startup should only be slow if your dns is broken or you've > >>removed the localhost entry from your hosts file. Either of those > >>needs to be fixed anyway. > > > >the slow part is the aliases generation. > > Oh, if only unix-like systems had a common tool to quickly determine if > the source text file is newer than the dependent db... Um, am I missing something here or is the answer simply: make ? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From jonathan.underwood at gmail.com Wed Sep 24 22:47:16 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Wed, 24 Sep 2008 23:47:16 +0100 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> Message-ID: <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> 2008/9/24 Colin Walters : > On Wed, Sep 24, 2008 at 6:03 PM, Matthew Woehlke > wrote: >> >> So... you just broke cron? I use rsync for nightly backup. It makes noise. >> Ergo, I get mail. Are you saying my *nightly backup* suddenly won't work? Or >> at best, I will have no way of knowing if any errors occurred? > > I've swapped in ssmtp instead of sendmail now. ssmtp doesn't do local delivery does it? From lesmikesell at gmail.com Wed Sep 24 22:49:24 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 24 Sep 2008 17:49:24 -0500 Subject: please deactivate services by default! In-Reply-To: <1222290934.5774.35.camel@dimi.lattica.com> References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> <1222290934.5774.35.camel@dimi.lattica.com> Message-ID: <48DAC3F4.2000205@gmail.com> Dimi Paun wrote: > >> Sendmail startup should only be slow if your dns is broken or you've >> removed the localhost entry from your hosts file. Either of those >> needs to be fixed anyway. > > Give me a break. What naive user would know what to do with > the thing? Even if it takes 200ms to load it's way too much. Users typically don't do anything directly with sendmail but during an install an alias for root should be set up so system messages reach someone who cares about the things logwatch and smartctl will send. I don't understand the point of making something only useful to naive users. They won't always stay naive forever. And what's the point of booting faster? If you want speed, you want sleep/hibernate to work - or just leave the machine on and give it something to do. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Wed Sep 24 22:57:39 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 24 Sep 2008 17:57:39 -0500 Subject: please deactivate services by default! sendmail|sm-client In-Reply-To: <48DABAA4.3020902@iinet.net.au> References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> <20080924142646.1e766949@infradead.org> <48DABAA4.3020902@iinet.net.au> Message-ID: <48DAC5E3.7080002@gmail.com> David Timms wrote: > >> ("slow" is relative, for me, anything taking more than 0.5 seconds is >> slow) > So waiting during bootup for 2 minutes for sendmail to look up it's own > {non-existent} ip address inside a nat network, then another minute for > sm-client to do the same wouldn't be acceptable to you then ? That DNS resolution time shouldn't be acceptable to anyone regardless of whether sendmail is involved or not. Who is it asking and why doesn't it respond quickly with an answer even if it is a lookup failure? -- Les Mikesell lesmikesell at gmail.com From pemboa at gmail.com Wed Sep 24 22:59:08 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 24 Sep 2008 17:59:08 -0500 Subject: please deactivate services by default! In-Reply-To: <48DAC3F4.2000205@gmail.com> References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> <1222290934.5774.35.camel@dimi.lattica.com> <48DAC3F4.2000205@gmail.com> Message-ID: <16de708d0809241559n18947064h34f3607b552b250e@mail.gmail.com> On Wed, Sep 24, 2008 at 5:49 PM, Les Mikesell wrote: > Dimi Paun wrote: >> >>> Sendmail startup should only be slow if your dns is broken or you've >>> removed the localhost entry from your hosts file. Either of those >>> needs to be fixed anyway. >> >> Give me a break. What naive user would know what to do with >> the thing? Even if it takes 200ms to load it's way too much. > > Users typically don't do anything directly with sendmail but during an > install an alias for root should be set up so system messages reach someone > who cares about the things logwatch and smartctl will send. We've been saying this since Fedora 7 (at least, maybe longer). It's never happened, I don't know why. From pertusus at free.fr Wed Sep 24 23:01:29 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 25 Sep 2008 01:01:29 +0200 Subject: please deactivate services by default! In-Reply-To: <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> Message-ID: <20080924230129.GB29113@free.fr> On Wed, Sep 24, 2008 at 11:47:16PM +0100, Jonathan Underwood wrote: > > ssmtp doesn't do local delivery does it? No it doesn't (at least it didn't some time ago). Same for esmtp. But they can still be /sur/sbin/sendmail replacements. -- Pat From sundaram at fedoraproject.org Wed Sep 24 23:01:33 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 25 Sep 2008 04:31:33 +0530 Subject: please deactivate services by default! In-Reply-To: <16de708d0809241559n18947064h34f3607b552b250e@mail.gmail.com> References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> <1222290934.5774.35.camel@dimi.lattica.com> <48DAC3F4.2000205@gmail.com> <16de708d0809241559n18947064h34f3607b552b250e@mail.gmail.com> Message-ID: <48DAC6CD.2050802@fedoraproject.org> Arthur Pemberton wrote: > On Wed, Sep 24, 2008 at 5:49 PM, Les Mikesell wrote: >> Dimi Paun wrote: >>>> Sendmail startup should only be slow if your dns is broken or you've >>>> removed the localhost entry from your hosts file. Either of those >>>> needs to be fixed anyway. >>> Give me a break. What naive user would know what to do with >>> the thing? Even if it takes 200ms to load it's way too much. >> Users typically don't do anything directly with sendmail but during an >> install an alias for root should be set up so system messages reach someone >> who cares about the things logwatch and smartctl will send. > > > We've been saying this since Fedora 7 (at least, maybe longer). It's > never happened, I don't know why. Not every developer is subscribed or reading all the threads here. If you want suggestions to actually reach the developers, it is always better to file a enhancement request in bugzilla. Rahul From lesmikesell at gmail.com Wed Sep 24 23:06:24 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 24 Sep 2008 18:06:24 -0500 Subject: please deactivate services by default! In-Reply-To: <20080924224637.GD29032@mokona.greysector.net> References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> <20080924142646.1e766949@infradead.org> <48DAC0A9.9040907@gmail.com> <20080924224637.GD29032@mokona.greysector.net> Message-ID: <48DAC7F0.40106@gmail.com> Dominik 'Rathann' Mierzejewski wrote: > >>>>> I have some services found being activated by default that should be >>>>> removed for the following reasons: >>>>> >>>>> 1. sendmail: starts way too slow, >>>> Sendmail startup should only be slow if your dns is broken or you've >>>> removed the localhost entry from your hosts file. Either of those >>>> needs to be fixed anyway. >>> the slow part is the aliases generation. >> Oh, if only unix-like systems had a common tool to quickly determine if >> the source text file is newer than the dependent db... > > Um, am I missing something here or is the answer simply: > make Actually I'm not sure. If make is installed it is used intelligently for most of the db's, but in my admittedly not current fedora setup it looks like newaliases is run blindly on every startup. Is there some reason for that? If make is not installed it might cost you some time anyway. -- Les Mikesell lesmikesell at gmail.com From roland at redhat.com Wed Sep 24 23:17:06 2008 From: roland at redhat.com (Roland McGrath) Date: Wed, 24 Sep 2008 16:17:06 -0700 (PDT) Subject: debuginfo package dependencies In-Reply-To: Orion Poplawski's message of Wednesday, 24 September 2008 16:41:08 -0600 <48DAC204.7000901@cora.nwra.com> References: <48DAC204.7000901@cora.nwra.com> Message-ID: <20080924231706.874E8154493@magilla.localdomain> That looks like automatic soname dependencies being generated in the debuginfo rpms. This is supposed to be prevented by the line: AutoReqProv: 0\ in /usr/lib/rpm/redhat/macros, from redhat-rpm-config. The rawhide rpms don't have these extra requires and provides. I don't know why F-9's debuginfo rpms do have them. Thanks, Roland From mw_triad at users.sourceforge.net Wed Sep 24 23:20:21 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 24 Sep 2008 18:20:21 -0500 Subject: please deactivate services by default! In-Reply-To: <1222294938.3941.20.camel@choeger6> References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> Message-ID: Christoph ? wrote: >> I really hope I'm missing something... > > calm down! No one will break your system. In the worst case you would > simply have to enable sendmail. Ah... yeah. Good thing I read fedora-devel then, yes? If an upgrade makes cron jobs stop working, or a new F10 system allows creating cron jobs that won't run, that's a bug (a potentially grave bug, at that, and IMO an unacceptable one). The only way I'd accept this is if I can't get into the situation of having a non-working cron job (that would otherwise work if sendmail was around) is if I must /actively acknowledge/ (i.e. click or type "yes" in response to) a warning that explains that sendmail is no longer active by default and what adverse effects this has. I shouldn't have to know to enable sendmail to maintain functionality that I've had on Linux for decades, especially when we're talking about causing critical system components (in this case, my backup process) to suddenly not work. Make sure it won't do that. Otherwise I will be very unhappy, yes? :-) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while in a KDE session. And nothing bad happened whatsoever. Try THAT on Windows :-D. From pemboa at gmail.com Wed Sep 24 23:24:29 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 24 Sep 2008 18:24:29 -0500 Subject: please deactivate services by default! In-Reply-To: <48DAC6CD.2050802@fedoraproject.org> References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> <1222290934.5774.35.camel@dimi.lattica.com> <48DAC3F4.2000205@gmail.com> <16de708d0809241559n18947064h34f3607b552b250e@mail.gmail.com> <48DAC6CD.2050802@fedoraproject.org> Message-ID: <16de708d0809241624l32543ac1y41806bd221ab11f5@mail.gmail.com> On Wed, Sep 24, 2008 at 6:01 PM, Rahul Sundaram wrote: > Arthur Pemberton wrote: >> >> On Wed, Sep 24, 2008 at 5:49 PM, Les Mikesell >> wrote: >>> >>> Dimi Paun wrote: >>>>> >>>>> Sendmail startup should only be slow if your dns is broken or you've >>>>> removed the localhost entry from your hosts file. Either of those >>>>> needs to be fixed anyway. >>>> >>>> Give me a break. What naive user would know what to do with >>>> the thing? Even if it takes 200ms to load it's way too much. >>> >>> Users typically don't do anything directly with sendmail but during an >>> install an alias for root should be set up so system messages reach >>> someone >>> who cares about the things logwatch and smartctl will send. >> >> >> We've been saying this since Fedora 7 (at least, maybe longer). It's >> never happened, I don't know why. > > Not every developer is subscribed or reading all the threads here. If you > want suggestions to actually reach the developers, it is always better to > file a enhancement request in bugzilla. I am aware of that. I wasn't complaining. I had come to the conclusion that the devs had a reason for not doing. I can file an RFE if necessary. -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From mw_triad at users.sourceforge.net Wed Sep 24 23:30:50 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 24 Sep 2008 18:30:50 -0500 Subject: please deactivate services by default! In-Reply-To: <20080924230129.GB29113@free.fr> References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> Message-ID: Patrice Dumas wrote: > On Wed, Sep 24, 2008 at 11:47:16PM +0100, Jonathan Underwood wrote: >> ssmtp doesn't do local delivery does it? > > No it doesn't (at least it didn't some time ago). Same for esmtp. But they > can still be /sur/sbin/sendmail replacements. Ok, so you still broke cron? I use cron for backups. I care about getting that output delivered. For similar people not reading this list, how are you going to ensure that their jobs still run and their output still gets delivered like they're used to? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while in a KDE session. And nothing bad happened whatsoever. Try THAT on Windows :-D. From jkeating at redhat.com Wed Sep 24 23:39:26 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 24 Sep 2008 16:39:26 -0700 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> Message-ID: <1222299566.1895.0.camel@luminos.localdomain> On Wed, 2008-09-24 at 18:30 -0500, Matthew Woehlke wrote: > Ok, so you still broke cron? I use cron for backups. I care about > getting that output delivered. For similar people not reading this list, > how are you going to ensure that their jobs still run and their output > still gets delivered like they're used to? Which is why we shouldn't be using local delivery for this stuff. Instead we should ask in firstboot where you'd want the mail delivered to. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From emmanuel.seyman at club-internet.fr Wed Sep 24 23:42:52 2008 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Thu, 25 Sep 2008 01:42:52 +0200 Subject: please deactivate services by default! In-Reply-To: <20080924213113.GK1414283@hiwaay.net> References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> Message-ID: <20080924234252.GA9895@orient.maison.lan> * Chris Adams [25/09/2008 00:48] : > > What about mail clients like (IIRC) mutt that don't have an SMTP client > built in? Mutt acquired smtp support in 1.5.15, IIRC. Emmanuel From mw_triad at users.sourceforge.net Wed Sep 24 23:54:01 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 24 Sep 2008 18:54:01 -0500 Subject: please deactivate services by default! In-Reply-To: <1222299566.1895.0.camel@luminos.localdomain> References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <1222299566.1895.0.camel@luminos.localdomain> Message-ID: Jesse Keating wrote: > On Wed, 2008-09-24 at 18:30 -0500, Matthew Woehlke wrote: >> Ok, so you still broke cron? I use cron for backups. I care about >> getting that output delivered. For similar people not reading this list, >> how are you going to ensure that their jobs still run and their output >> still gets delivered like they're used to? > > Which is why we shouldn't be using local delivery for this stuff. > Instead we should ask in firstboot where you'd want the mail delivered > to. Ok, that's acceptable just as long as "local delivery" is still a choice and ensures that sendmail gets installed. And as long as upgrading doesn't break systems where this currently works. (And as long as cron can still deliver notifications... for which we still need a mail daemon.) Otherwise... well, I can paint some horror scenarios if you really want me to ;-). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while in a KDE session. And nothing bad happened whatsoever. Try THAT on Windows :-D. From pertusus at free.fr Wed Sep 24 23:57:01 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 25 Sep 2008 01:57:01 +0200 Subject: please deactivate services by default! In-Reply-To: References: <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> Message-ID: <20080924235701.GA14542@free.fr> On Wed, Sep 24, 2008 at 06:30:50PM -0500, Matthew Woehlke wrote: > > Ok, so you still broke cron? I use cron for backups. I care about > getting that output delivered. For similar people not reading this list, > how are you going to ensure that their jobs still run and their output > still gets delivered like they're used to? if you care about the output being delivered, you should find the mail client (which can be a full blown MTA like sendmail, or esmtp/ssmtp) you prefer and configure it. esmtp can do local delivery through a mda, but once again all this should be configured by the user. As a side note and unless I am wrong the package that provides /usr/sbin/sendmail with shortest name wins and I wouldn't be surprised if currently exim was installed. We can do some kind of GUI in firstboot, as Jesse said but in the mean time I think that leaving the configuration to the user is better since we cannot guess for the user -- there is no superior setup, and no superior /usr/sbin/sendmail mail agent. -- Pat From pertusus at free.fr Wed Sep 24 22:59:42 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 25 Sep 2008 00:59:42 +0200 Subject: please deactivate services by default! In-Reply-To: <20080924213113.GK1414283@hiwaay.net> References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> Message-ID: <20080924225942.GA29113@free.fr> On Wed, Sep 24, 2008 at 04:31:13PM -0500, Chris Adams wrote: > > So what happens to messages from cron jobs and other standard Unix stuff > that expects /bin/mail or /usr/sbin/sendmail to do something useful? > What about mail clients like (IIRC) mutt that don't have an SMTP client > built in? If the application calls /bin/mail it should Requires /bin/mail. If the application really needs a (local) smtp server, it should Requires server(smtp) (smtpdaemon is deprecated, but can be used for backward compatibility). If the application calls /usr/sbin/sendmail, it should require /usr/sbin/sendmail. I guess that a Requires: /usr/sbin/sendmail is missing for cronie. fetchmail will soon stop needing a smtp server, and instead use procmail for delivery. But otherwise things looks pretty good: # repoquery --whatprovides 'server(smtp)' smtpdaemon sendmail-0:8.14.3-1.fc10.i386 postfix-2:2.5.1-4.fc10.i386 exim-0:4.69-7.fc10.i386 # repoquery --whatrequires 'server(smtp)' smtpdaemon fetchmail-0:6.3.8-7.fc10.i386 sagator-0:1.1.1-0.beta1.fc10.noarch mlmmj-0:1.2.15-2.fc9.i386 bugzilla-0:3.0.4-2.fc10.noarch amavisd-new-0:2.5.2-3.fc10.noarch # repoquery --whatprovides '/usr/sbin/sendmail' esmtp-0:0.6.0-4.fc9.i386 exim-0:4.69-7.fc10.i386 postfix-2:2.5.1-4.fc10.i386 sendmail-0:8.14.3-1.fc10.i386 ssmtp-0:2.61-11.6.fc10.i386 # repoquery --whatrequires '/usr/sbin/sendmail' websec-0:1.9.0-5.1.noarch uudeview-0:0.5.20-17.fc10.i386 pgp-tools-0:1.0-1.fc10.noarch alpine-0:2.00-1.fc10.i386 bcfg2-server-0:0.9.5.7-1.fc9.noarch dbmail-0:2.2.9-2.fc10.i386 asterisk-voicemail-0:1.6.0-0.21.beta9.fc10.i386 mgetty-0:1.1.36-1.fc10.i386 squirrelmail-0:1.4.15-1.fc10.noarch quilt-0:0.47-1.fc10.i386 fvwm-0:2.5.26-2.fc10.i386 fcron-0:3.0.3-4.fc9.i386 arpwatch-14:2.1a15-8.fc9.i386 redhat-lsb-0:3.2-2.fc10.i386 # repoquery --whatprovides '/bin/mail' mailx-0:12.4-1.fc10.i386 # repoquery --whatrequires '/bin/mail' apcupsd-0:3.14.4-2.fc10.i386 -- Pat From bpepple at fedoraproject.org Wed Sep 24 23:35:12 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Wed, 24 Sep 2008 19:35:12 -0400 Subject: FESCo Meeting Summary for 2008-09-24 Message-ID: <1222299312.18153.3.camel@kennedy> === Members Present === * Brian Pepple (bpepple) * Kevin Fenzi (nirik) * Jarod Wilson (j-rod) * Bill Nottingham (notting) * Jon Stanley (jds2001) * Dennis Gilmore (dgilmore) * Josh Boyer (jwb) * David Woodhouse (dwmw2) === Absent === * Karsten Hopp (kick_) == Summary == === MinGW === * FESCo approved a proposal (contingent on rel-eng and infrastructure team buy-in) not to make any hard restrictions about what files are shipped, but recommend that they don't ship end-user binaries. And to put the _target_ (noarch) stuff in a separate repository, and the actual toolchain into Fedora. === Features === * FESCo reviewed some features to determine if they were in a testable state for the beta release. Based on the information available, they chose to push the following features back to the F11 release: ** https://fedoraproject.org/wiki/Features/GoodHaskellSupport ** https://fedoraproject.org/wiki/Features/HDTVEnhancements ** https://fedoraproject.org/wiki/Features/LXDE === Misc === * Paul Frields (stickster) asked if FESCo could move there meeting time, since FESCo has ended up bumping the Docs team from their time slot for the last month or so. FESCo will discuss on their mailing list when & where they will hold their meetings. * FESCo approved a proposal to hold their upcoming election at the same time as the Board and other groups. IRC log can be found at: http://bpepple.fedorapeople.org/fesco/FESCo-2008-09-24.html Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Thu Sep 25 00:00:28 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 25 Sep 2008 02:00:28 +0200 Subject: please deactivate services by default! In-Reply-To: References: <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <1222299566.1895.0.camel@luminos.localdomain> Message-ID: <20080925000028.GB14542@free.fr> On Wed, Sep 24, 2008 at 06:54:01PM -0500, Matthew Woehlke wrote: > > Ok, that's acceptable just as long as "local delivery" is still a choice > and ensures that sendmail gets installed. And as long as upgrading > doesn't break systems where this currently works. (And as long as cron > can still deliver notifications... for which we still need a mail > daemon.) I don't know exactly what you mean with mail daemon, but I don't think that there is such a requirement. As I said in another mail, for example, esmtp can both deliver locally through a mda or to another localtion, and it is not obvious that everybody needs local delivery. Now the right package could be installed depending on the user choice, but I don't think we should try to be too smart. -- Pat From jonathan.underwood at gmail.com Thu Sep 25 00:03:31 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Thu, 25 Sep 2008 01:03:31 +0100 Subject: please deactivate services by default! In-Reply-To: <20080924235701.GA14542@free.fr> References: <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <20080924235701.GA14542@free.fr> Message-ID: <645d17210809241703u29261696pacebb9725b802dc7@mail.gmail.com> 2008/9/25 Patrice Dumas : > On Wed, Sep 24, 2008 at 06:30:50PM -0500, Matthew Woehlke wrote: >> >> Ok, so you still broke cron? I use cron for backups. I care about >> getting that output delivered. For similar people not reading this list, >> how are you going to ensure that their jobs still run and their output >> still gets delivered like they're used to? > > if you care about the output being delivered, you should find the mail > client (which can be a full blown MTA like sendmail, or esmtp/ssmtp) you > prefer and configure it. > > esmtp can do local delivery through a mda, but once again all this > should be configured by the user. > So an alternative to sendmail would be esmtp+procmail for the desktop spin not wanting an MTA but still wanting local mail delivery, right? From mw_triad at users.sourceforge.net Thu Sep 25 00:19:11 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 24 Sep 2008 19:19:11 -0500 Subject: please deactivate services by default! In-Reply-To: <20080925000028.GB14542@free.fr> References: <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <1222299566.1895.0.camel@luminos.localdomain> <20080925000028.GB14542@free.fr> Message-ID: Patrice Dumas wrote: > On Wed, Sep 24, 2008 at 06:54:01PM -0500, Matthew Woehlke wrote: >> Ok, that's acceptable just as long as "local delivery" is still a choice >> and ensures that sendmail gets installed. And as long as upgrading >> doesn't break systems where this currently works. (And as long as cron >> can still deliver notifications... for which we still need a mail >> daemon.) > > I don't know exactly what you mean with mail daemon, but I don't think > that there is such a requirement. Maybe I'm confusing with some other things said in the thread. To clarify, cron needs to be able to deliver notifications. If the chosen delivery method is "local delivery" (which is what I currently use, as I find it more convenient), then that needs to work. > Now the right package could be installed depending on the user choice, > but I don't think we should try to be too smart. I think it's really important that cron still works as expected :-). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while in a KDE session. And nothing bad happened whatsoever. Try THAT on Windows :-D. From mw_triad at users.sourceforge.net Thu Sep 25 00:29:18 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 24 Sep 2008 19:29:18 -0500 Subject: please deactivate services by default! In-Reply-To: <20080924235701.GA14542@free.fr> References: <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <20080924235701.GA14542@free.fr> Message-ID: Patrice Dumas wrote: > On Wed, Sep 24, 2008 at 06:30:50PM -0500, Matthew Woehlke wrote: >> Ok, so you still broke cron? I use cron for backups. I care about >> getting that output delivered. For similar people not reading this list, >> how are you going to ensure that their jobs still run and their output >> still gets delivered like they're used to? > > if you care about the output being delivered, Of course I care. Knowing if my nightly backup had problems is, well, rather important. > you should find the mail > client (which can be a full blown MTA like sendmail, or esmtp/ssmtp) you > prefer and configure it. I like local delivery. For as long as I can remember, local delivery Just Works(TM). Having to find and configure something would be a serious regression (with potentially dire consequences if someone doesn't know to do this). > As a side note and unless I am wrong the package that provides > /usr/sbin/sendmail with shortest name wins and I wouldn't be surprised > if currently exim was installed. Oh? $ rpm -q -f /usr/sbin/sendmail sendmail-8.14.2-4.fc9.x86_64 (Unless I lucked out and picked 'sendmail' when I installed?) > We can do some kind of GUI in firstboot, as Jesse said but in the mean > time I think that leaving the configuration to the user is better since > we cannot guess for the user -- there is no superior setup, and no > superior /usr/sbin/sendmail mail agent. GUI setup is fine, just so long as it works by default. Working by default is IMO really important. (That, or make sure that both new installs and upgrades give me a Warning That I Cannot Possibly Miss if it won't be working OOTB.) Actually, working by default for things like smartctl is also really important (I'd like to know if my HD is about to go belly-up, thank you!), but at least we have the excuse that smartctl never worked nicely to begin with. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while in a KDE session. And nothing bad happened whatsoever. Try THAT on Windows :-D. From jkeating at redhat.com Thu Sep 25 00:41:23 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 24 Sep 2008 17:41:23 -0700 Subject: please deactivate services by default! In-Reply-To: References: <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <20080924235701.GA14542@free.fr> Message-ID: <1222303283.1895.10.camel@luminos.localdomain> On Wed, 2008-09-24 at 19:29 -0500, Matthew Woehlke wrote: > Actually, working by default for things like smartctl is also really > important (I'd like to know if my HD is about to go belly-up, thank > you!), but at least we have the excuse that smartctl never worked nicely > to begin with. But see, it doesn't "work by default". By default (with sendmail) mail is just dropped in /var/spool/mail/root. The user is given no hint, documentation, or otherwise notification that they may want to configure some email client to subscribe to this, which is quite difficult as a normal user to subscribed to /var/spool/mail/root . Things certainly don't "work by default". If you're interested in them working by default, I would suggest helping out the situation and ensuring that this vastly important email is delivered to the user rather than some spool file a user has no access to. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From sundaram at fedoraproject.org Thu Sep 25 00:59:43 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 25 Sep 2008 06:29:43 +0530 Subject: please deactivate services by default! In-Reply-To: <16de708d0809241624l32543ac1y41806bd221ab11f5@mail.gmail.com> References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> <1222290934.5774.35.camel@dimi.lattica.com> <48DAC3F4.2000205@gmail.com> <16de708d0809241559n18947064h34f3607b552b250e@mail.gmail.com> <48DAC6CD.2050802@fedoraproject.org> <16de708d0809241624l32543ac1y41806bd221ab11f5@mail.gmail.com> Message-ID: <48DAE27F.1030202@fedoraproject.org> Arthur Pemberton wrote: > > I am aware of that. I wasn't complaining. I had come to the conclusion > that the devs had a reason for not doing. I can file an RFE if > necessary. The same reasoning applies. Ultimately it is the maintainer's decision. If they are not reading this thread, you aren't going to get a response. So unless you file a RFE, you won't know if it will get accepted or rejected. Rahul From tcallawa at redhat.com Thu Sep 25 01:06:39 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Wed, 24 Sep 2008 21:06:39 -0400 Subject: Fedora rawhide rebuild in mock status 2008-09-23 i386 In-Reply-To: <20080924122147.GA4137@mock.linuxdev.us.dell.com> References: <20080924122147.GA4137@mock.linuxdev.us.dell.com> Message-ID: <1222304799.23344.514.camel@localhost.localdomain> Note that I'm not claiming to have fixed all of these myself (although I did fix all but one in this list). Here's today's pass through the latest FTBFS (hint, I'm just going in alphabetical order): On Wed, 2008-09-24 at 07:21 -0500, Matt Domsch wrote: > KoboDeluxe-0.5.1-2.fc9 (build/make) jwrdegoede Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=64184 > LabPlot-1.6.0.1-1.fc10 (patch_fuzz) chitlesh,chitlesh,tnorth Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=64199 > PyAmanith-0.3.35-2.fc9 (patch_fuzz) spot Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=64193 > PyX-0.10-4.fc9 (patch_fuzz) jamatos,mpeters,jamatos Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=64198 > R-Matrix-0.999375-4.fc9 (build/make) tmoertel Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=63164 > R-RScaLAPACK-0.5.1-15.fc10 (patch_fuzz) spot Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=64214 > SimGear-1.0.0-4.fc10 (patch_fuzz) spot,bellet Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=64207 > UnihanDb-5.1.0-4.fc10 (build/make) dchen Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=64091 > WindowMaker-0.92.0-18.fc9 (patch_fuzz) awjb Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=64223 ~spot From pemboa at gmail.com Thu Sep 25 01:18:37 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 24 Sep 2008 20:18:37 -0500 Subject: please deactivate services by default! In-Reply-To: <48DAE27F.1030202@fedoraproject.org> References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> <1222290934.5774.35.camel@dimi.lattica.com> <48DAC3F4.2000205@gmail.com> <16de708d0809241559n18947064h34f3607b552b250e@mail.gmail.com> <48DAC6CD.2050802@fedoraproject.org> <16de708d0809241624l32543ac1y41806bd221ab11f5@mail.gmail.com> <48DAE27F.1030202@fedoraproject.org> Message-ID: <16de708d0809241818v2629198cv84aa8aa25b5a684f@mail.gmail.com> On Wed, Sep 24, 2008 at 7:59 PM, Rahul Sundaram wrote: > Arthur Pemberton wrote: >> >> I am aware of that. I wasn't complaining. I had come to the conclusion >> that the devs had a reason for not doing. I can file an RFE if >> necessary. > > The same reasoning applies. Ultimately it is the maintainer's decision. If > they are not reading this thread, you aren't going to get a response. So > unless you file a RFE, you won't know if it will get accepted or rejected. > > Rahul > You have a point. What should I file this against? I see that 'setup owns '/etc/aliases' -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From sundaram at fedoraproject.org Thu Sep 25 01:24:44 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 25 Sep 2008 06:54:44 +0530 Subject: please deactivate services by default! In-Reply-To: <16de708d0809241818v2629198cv84aa8aa25b5a684f@mail.gmail.com> References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> <1222290934.5774.35.camel@dimi.lattica.com> <48DAC3F4.2000205@gmail.com> <16de708d0809241559n18947064h34f3607b552b250e@mail.gmail.com> <48DAC6CD.2050802@fedoraproject.org> <16de708d0809241624l32543ac1y41806bd221ab11f5@mail.gmail.com> <48DAE27F.1030202@fedoraproject.org> <16de708d0809241818v2629198cv84aa8aa25b5a684f@mail.gmail.com> Message-ID: <48DAE85C.1010905@fedoraproject.org> Arthur Pemberton wrote: > On Wed, Sep 24, 2008 at 7:59 PM, Rahul Sundaram > wrote: >> Arthur Pemberton wrote: >>> I am aware of that. I wasn't complaining. I had come to the conclusion >>> that the devs had a reason for not doing. I can file an RFE if >>> necessary. >> The same reasoning applies. Ultimately it is the maintainer's decision. If >> they are not reading this thread, you aren't going to get a response. So >> unless you file a RFE, you won't know if it will get accepted or rejected. >> >> Rahul >> > > You have a point. What should I file this against? I see that 'setup > owns '/etc/aliases' That seems to be a good place. If not, it can always be reassigned. Rahul From mw_triad at users.sourceforge.net Thu Sep 25 01:08:29 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 24 Sep 2008 20:08:29 -0500 Subject: please deactivate services by default! In-Reply-To: <1222303283.1895.10.camel@luminos.localdomain> References: <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <20080924235701.GA14542@free.fr> <1222303283.1895.10.camel@luminos.localdomain> Message-ID: Jesse Keating wrote: > On Wed, 2008-09-24 at 19:29 -0500, Matthew Woehlke wrote: >> Actually, working by default for things like smartctl is also really >> important (I'd like to know if my HD is about to go belly-up, thank >> you!), but at least we have the excuse that smartctl never worked nicely >> to begin with. > > But see, it doesn't "work by default". By default (with sendmail) mail > is just dropped in /var/spool/mail/root. First, I'm not talking about root's mail. Second, how does local mail not work? I get 'you have mail' notifications just fine (granted, bash isn't as obnoxious about it as it could be, i.e. it seems like some days I don't see a notification, but...). 'mail' is able to read and manage my spool. What's the problem? This discussion prior to when I jumped in had given the impression that local mail would stop working. I've already expressed (numerous times) why I think that would be a Very Bad Thing. > The user is given no hint, documentation, or otherwise notification > that they may want to configure some email client to subscribe to > this, which is quite difficult as a normal user to subscribed to > /var/spool/mail/root. True. However, while I agree this is a real problem, it's somewhat different from (though related to) the problem I'm concerned about. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- I was recently amused by issuing 'rm -rf $KDEDIR'... from Konsole, while in a KDE session. And nothing bad happened whatsoever. Try THAT on Windows :-D. From lesmikesell at gmail.com Thu Sep 25 01:42:42 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Wed, 24 Sep 2008 20:42:42 -0500 Subject: please deactivate services by default! In-Reply-To: <1222303283.1895.10.camel@luminos.localdomain> References: <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <20080924235701.GA14542@free.fr> <1222303283.1895.10.camel@luminos.localdomain> Message-ID: <48DAEC92.60306@gmail.com> Jesse Keating wrote: > On Wed, 2008-09-24 at 19:29 -0500, Matthew Woehlke wrote: >> Actually, working by default for things like smartctl is also really >> important (I'd like to know if my HD is about to go belly-up, thank >> you!), but at least we have the excuse that smartctl never worked nicely >> to begin with. > > But see, it doesn't "work by default". By default (with sendmail) mail > is just dropped in /var/spool/mail/root. The user is given no hint, > documentation, or otherwise notification that they may want to configure > some email client to subscribe to this, which is quite difficult as a > normal user to subscribed to /var/spool/mail/root . Things certainly > don't "work by default". It isn't so much that things don't work by default as that you are discouraging/preventing anyone from logging in as root without fixing everything that needs to change if they don't. -- Les Mikesell lesmikesell at gmail.com From pemboa at gmail.com Thu Sep 25 01:55:44 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 24 Sep 2008 20:55:44 -0500 Subject: please deactivate services by default! In-Reply-To: <48DAE85C.1010905@fedoraproject.org> References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> <1222290934.5774.35.camel@dimi.lattica.com> <48DAC3F4.2000205@gmail.com> <16de708d0809241559n18947064h34f3607b552b250e@mail.gmail.com> <48DAC6CD.2050802@fedoraproject.org> <16de708d0809241624l32543ac1y41806bd221ab11f5@mail.gmail.com> <48DAE27F.1030202@fedoraproject.org> <16de708d0809241818v2629198cv84aa8aa25b5a684f@mail.gmail.com> <48DAE85C.1010905@fedoraproject.org> Message-ID: <16de708d0809241855l2814484diae9a4e194cf6e24a@mail.gmail.com> On Wed, Sep 24, 2008 at 8:24 PM, Rahul Sundaram wrote: > Arthur Pemberton wrote: >> >> On Wed, Sep 24, 2008 at 7:59 PM, Rahul Sundaram >> wrote: >>> >>> Arthur Pemberton wrote: >>>> >>>> I am aware of that. I wasn't complaining. I had come to the conclusion >>>> that the devs had a reason for not doing. I can file an RFE if >>>> necessary. >>> >>> The same reasoning applies. Ultimately it is the maintainer's decision. >>> If >>> they are not reading this thread, you aren't going to get a response. So >>> unless you file a RFE, you won't know if it will get accepted or >>> rejected. >>> >>> Rahul >>> >> >> You have a point. What should I file this against? I see that 'setup >> owns '/etc/aliases' > > That seems to be a good place. If not, it can always be reassigned. https://bugzilla.redhat.com/show_bug.cgi?id=463864 -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From gmaxwell at gmail.com Thu Sep 25 02:28:29 2008 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Wed, 24 Sep 2008 22:28:29 -0400 Subject: please deactivate services by default! In-Reply-To: <16de708d0809241425o6a241428y8dd3469f54d5f208@mail.gmail.com> References: <1222287197.3941.7.camel@choeger6> <16de708d0809241425o6a241428y8dd3469f54d5f208@mail.gmail.com> Message-ID: On Wed, Sep 24, 2008 at 5:25 PM, Arthur Pemberton wrote: >> 2. ip6tables: I do not know of any provider actually working with ipv6. >> So I assume the mass of all users do not need it. > > Agreed -- but should be auto done based on packages chosen on install What?! No. Or rather, only if the IPv4 iptables can be disabled too, or is there a no network access install that I'm not aware of? :) As soon as you happen to plug into an IPv6 enabled network you would be exposed without any firewalling, thats only okay for v6 if it's also okay for v4. About 4% of the web browsers hitting English language Wikipedia are IPv6 enabled. IPv6 enabled web clients may even become more numerous than Linux desktops this year, almost certainly by next year, so be careful what you call rare. :) From pemboa at gmail.com Thu Sep 25 02:35:06 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 24 Sep 2008 21:35:06 -0500 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <16de708d0809241425o6a241428y8dd3469f54d5f208@mail.gmail.com> Message-ID: <16de708d0809241935t8ab3e6bl32c856336b39d79@mail.gmail.com> On Wed, Sep 24, 2008 at 9:28 PM, Gregory Maxwell wrote: > On Wed, Sep 24, 2008 at 5:25 PM, Arthur Pemberton wrote: >>> 2. ip6tables: I do not know of any provider actually working with ipv6. >>> So I assume the mass of all users do not need it. >> >> Agreed -- but should be auto done based on packages chosen on install > > What?! > No. Or rather, only if the IPv4 iptables can be disabled too, or is > there a no network access install that I'm not aware of? :) > > As soon as you happen to plug into an IPv6 enabled network you would > be exposed without any firewalling, thats only okay for v6 if it's > also okay for v4. > > About 4% of the web browsers hitting English language Wikipedia are > IPv6 enabled. IPv6 enabled web clients may even become more numerous > than Linux desktops this year, almost certainly by next year, so be > careful what you call rare. :) Seems like I needed some serious reeducation on this topic. Based on the comments, there seems to be more than enough reason to keep ip6tables. Change my 'Agree' to a "Disagree' -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From ville.skytta at iki.fi Thu Sep 25 05:55:38 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 25 Sep 2008 08:55:38 +0300 Subject: rpms/blam/F-9 blam.spec,1.24,1.25 In-Reply-To: <20080925001805.cb1f9b1c.mschwendt@gmail.com> References: <20080924060730.2E9F370103@cvs1.fedora.phx.redhat.com> <48D9ED0F.6040804@leemhuis.info> <20080925001805.cb1f9b1c.mschwendt@gmail.com> Message-ID: <200809250855.38538.ville.skytta@iki.fi> On Thursday 25 September 2008, Michael Schwendt wrote: > I wonder even more why rpmdev-bumpspec says > > Copyright (c) 2005-2008 Red Hat Inc. > > which is not correct. 2005 may be true for its origin, the pre-Fedora > Extras era. For the first mass-rebuilds and beyond that it was developed > further by me, and just because I don't want to claim full copyright, > it should not be given to Red Hat for 2006-2008. That sounds very wrong > to me, because nobody at Red Hat has been an author of changes to the > script in those years. This was discussed in several mails between you, me and notting in March when I was about to add the script in rpmdevtools. I asked you to add copyright notices to the script, and you added it but without mentioning a copyright holder. When discussing it further, you concluded "(c) Fedora Project ... sounds reasonable. Who is/are the original author(s)? [...]" and did not mention that you would like to have your name there. To your question (which mentioned someone at Red Hat giving it out for the pre-Fedora Extras 3 period), Bill answered "If it was given out by someone @RH, you can just put (c) Red Hat on it." and there were no further replies. I wanted to have something as the copyright holder in it, and since your version didn't have one (it still doesn't, it seems), I put what's currently in it there based on Bill's suggestion. Maybe adding the years was not a good thing to do, but I don't think there's any irreparable harm done. If you or anyone who knows the history of the script can suggest a more truthful set of copyright holder lines to have in it, patches welcome. I'm not going to invent anything based on informal discussions for the 2nd time, so explicit patches or specified lines are needed to change it. Or if you like, the offer for commit access to rpmdevtools upstream (also discussed in March) still stands so you could fix it yourself, just request it in FAS and I'll approve it. From ville.skytta at iki.fi Thu Sep 25 05:58:52 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 25 Sep 2008 08:58:52 +0300 Subject: rpms/blam/F-9 blam.spec,1.24,1.25 In-Reply-To: <48D9ED0F.6040804@leemhuis.info> References: <20080924060730.2E9F370103@cvs1.fedora.phx.redhat.com> <48D9ED0F.6040804@leemhuis.info> Message-ID: <200809250858.52436.ville.skytta@iki.fi> On Wednesday 24 September 2008, Thorsten Leemhuis wrote: > https://fedorahosted.org/rpmdevtools/ticket/1 Ah, I had no idea that a ticket was waiting there, I was not notified by email of its existence - the fedorahosted trac setup does not seem to notify anyone useful in new out of the box projects. It should be configured to mail me now, and I'll look into the ticket soon. From jkeating at redhat.com Thu Sep 25 06:18:06 2008 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 24 Sep 2008 23:18:06 -0700 Subject: please deactivate services by default! In-Reply-To: References: <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <20080924235701.GA14542@free.fr> <1222303283.1895.10.camel@luminos.localdomain> Message-ID: <1222323486.1895.16.camel@luminos.localdomain> On Wed, 2008-09-24 at 20:08 -0500, Matthew Woehlke wrote: > > First, I'm not talking about root's mail. Second, how does local mail > not work? I get 'you have mail' notifications just fine (granted, bash > isn't as obnoxious about it as it could be, i.e. it seems like some days > I don't see a notification, but...). 'mail' is able to read and manage > my spool. What's the problem? Root's mail is where things like logwatch and smart reports go. That's the only thing getting mail on a fresh install. For users that never log into a virtual tty (and that's a large large amount of them) they never see a new mail notification. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Thu Sep 25 07:11:21 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 25 Sep 2008 09:11:21 +0200 Subject: please deactivate services by default! In-Reply-To: <645d17210809241703u29261696pacebb9725b802dc7@mail.gmail.com> References: <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <20080924235701.GA14542@free.fr> <645d17210809241703u29261696pacebb9725b802dc7@mail.gmail.com> Message-ID: <20080925071121.GA2819@free.fr> On Thu, Sep 25, 2008 at 01:03:31AM +0100, Jonathan Underwood wrote: > > So an alternative to sendmail would be esmtp+procmail for the desktop > spin not wanting an MTA but still wanting local mail delivery, right? Yes. Currently the no /etc/esmtprc file is shipped (nor in the %files list...), so local delivery is not enabled. -- Pat From mschwendt at gmail.com Thu Sep 25 07:52:50 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 25 Sep 2008 09:52:50 +0200 Subject: rpms/blam/F-9 blam.spec,1.24,1.25 In-Reply-To: <200809250855.38538.ville.skytta@iki.fi> References: <20080924060730.2E9F370103@cvs1.fedora.phx.redhat.com> <48D9ED0F.6040804@leemhuis.info> <20080925001805.cb1f9b1c.mschwendt@gmail.com> <200809250855.38538.ville.skytta@iki.fi> Message-ID: <20080925095250.1fb37551.mschwendt@gmail.com> On Thu, 25 Sep 2008 08:55:38 +0300, Ville Skytt? wrote: > On Thursday 25 September 2008, Michael Schwendt wrote: > > > I wonder even more why rpmdev-bumpspec says > > > > Copyright (c) 2005-2008 Red Hat Inc. > > > > which is not correct. 2005 may be true for its origin, the pre-Fedora > > Extras era. For the first mass-rebuilds and beyond that it was developed > > further by me, and just because I don't want to claim full copyright, > > it should not be given to Red Hat for 2006-2008. That sounds very wrong > > to me, because nobody at Red Hat has been an author of changes to the > > script in those years. > > This was discussed in several mails between you, me and notting in March when > I was about to add the script in rpmdevtools. I asked you to add copyright > notices to the script, and you added it but without mentioning a copyright > holder. I've found those mails, but they don't cover such a very specific copyright line that differs from the one I called "reasonable". It's simply not accurate. > When discussing it further, you concluded "(c) Fedora Project ... sounds > reasonable. Who is/are the original author(s)? [...]" Because I'm not a lawyer, and the script is derived work based on something that didn't have any legal stuff attached to it at all. I wrote the following and added Bill: : (c) Fedora Project ... sounds reasonable. : : Who is/are the original author(s)? The skeleton of the original code is : still present. If memory serves correctly, the first version of the script : was given out by someone at Red Hat for the pre-Fedora Extras 3 period and : then improved for the first mass-rebuilds. But who exactly was the original : author, I don't know. notting or sopwith or mkj or gafton? Neither one? You see? With an existing list of authors, I could have added myself. But claiming full copyright and credits [for any original bits that may be left] is an entirely different thing. > and did not mention > that you would like to have your name there. I don't care about my name in there. I don't get my name attached to lots of patches for F/LOSS either. And this is just a script that can be rewritten from scratch if someone insists on doing that. > To your question (which > mentioned someone at Red Hat giving it out for the pre-Fedora Extras 3 > period), Bill answered "If it was given out by someone @RH, you can just put > (c) Red Hat on it." and there were no further replies. True, but Bill apparently was the wrong one to ask. And a different proposal was made earlier, too. However, the added line changes history. From alexl at users.sourceforge.net Thu Sep 25 09:26:51 2008 From: alexl at users.sourceforge.net (Alex Lancaster) Date: Thu, 25 Sep 2008 02:26:51 -0700 Subject: Fedora rawhide rebuild in mock status 2008-09-23 i386 In-Reply-To: <20080924122147.GA4137@mock.linuxdev.us.dell.com> (Matt Domsch's message of "Wed\, 24 Sep 2008 07\:21\:47 -0500") References: <20080924122147.GA4137@mock.linuxdev.us.dell.com> Message-ID: >>>>> "MD" == Matt Domsch writes: [...] MD> alexlan: perl-bioperl This was a patch fuzz issue. Fixed in dist-f10 (not yet in rawhide): https://koji.fedoraproject.org/koji/buildinfo?buildID=64243 From billcrawford1970 at gmail.com Thu Sep 25 09:38:34 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 25 Sep 2008 10:38:34 +0100 Subject: please deactivate services by default! In-Reply-To: <20080924213834.GM1414283@hiwaay.net> References: <1222287197.3941.7.camel@choeger6> <20080924213834.GM1414283@hiwaay.net> Message-ID: <200809251038.34508.billcrawford1970@gmail.com> On Wednesday 24 September 2008 22:38:34 Chris Adams wrote: > Once upon a time, Colin Walters said: > > On Wed, Sep 24, 2008 at 5:31 PM, Chris Adams wrote: > > > What about mail clients like (IIRC) mutt that don't have an SMTP client > > > built in? > > > > You can install sendmail or some other server. > > If that's the expected way, then there should have been an announcement > so everything that requires SMTP (like mutt) can be modified to have > "Requires: smtpdaemon". Surely the SMTP server isn't absolutely required to be on localhost? I never send any mail via localhost SMTP, it's all done through my company's mail servers or the Google ones for personal mail. From billcrawford1970 at gmail.com Thu Sep 25 09:50:57 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Thu, 25 Sep 2008 10:50:57 +0100 Subject: please deactivate services by default! In-Reply-To: <20080924224637.GD29032@mokona.greysector.net> References: <1222287197.3941.7.camel@choeger6> <48DAC0A9.9040907@gmail.com> <20080924224637.GD29032@mokona.greysector.net> Message-ID: <200809251050.58096.billcrawford1970@gmail.com> On Wednesday 24 September 2008 23:46:37 Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 25 September 2008 at 00:35, Les Mikesell wrote: > > Arjan van de Ven wrote: > > >>>I have some services found being activated by default that should be > > >>>removed for the following reasons: > > >>> > > >>>1. sendmail: starts way too slow, > > >> > > >>Sendmail startup should only be slow if your dns is broken or you've > > >>removed the localhost entry from your hosts file. Either of those > > >>needs to be fixed anyway. > > > > > >the slow part is the aliases generation. > > > > Oh, if only unix-like systems had a common tool to quickly determine if > > the source text file is newer than the dependent db... > > Um, am I missing something here or is the answer simply: > make bash(1): ... CONDITIONAL EXPRESSIONS ... file1 -nt file2 True if file1 is newer (according to modification date) than file2, or if file1 exists and file2 does not. ... From kanarip at kanarip.com Thu Sep 25 09:54:51 2008 From: kanarip at kanarip.com (Jeroen van Meeuwen) Date: Thu, 25 Sep 2008 11:54:51 +0200 Subject: F11 Spins process refinement In-Reply-To: References: Message-ID: <48DB5FEB.1080307@kanarip.com> Jon Stanley wrote: > As a member of FESCo, I'm leading an effort to improve the spins > process for F11. At the time that the F10 beta came around, no one > seemed to know what spins we were to produce to be hosted on > spins.fp.o, what process they had been through (Spins SIG, Board > trademark, rel-eng). We also inadvertently wound up requesting that > rel-eng produce spin using a toolchain that they had never heard of > before. As a result of this, the need for improvement became > immediately obvious to me. > > If you're interested in this topic, we will be having a meeting, > hopefully sometime this week, via conference call. The reason for > holding this meeting via conference call rather than IRC is the > massively increased bandwidth that's available on a conference call to > actually discuss items - while IRC is wonderful for taking votes on > things that have already been thought out, it can't be used for a sort > of "working session". > > What I need is *a volunteer* from each of the below groups to attend > this call. The reason for a single (or at most two) people from each > group is to facilitate an efficient, manageable call that stands a > fighting chance of accomplishing something :) > I can join the call as soon as my company gives me a phone, and enough access to calling international phone numbers. This will probably be next week. Kind regards, Jeroen van Meeuwen -kanarip From mschwendt at gmail.com Thu Sep 25 09:55:41 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 25 Sep 2008 11:55:41 +0200 Subject: Fedora rawhide rebuild in mock status 2008-09-23 i386 In-Reply-To: <20080924122147.GA4137@mock.linuxdev.us.dell.com> References: <20080924122147.GA4137@mock.linuxdev.us.dell.com> Message-ID: <20080925115541.01ed5889.mschwendt@gmail.com> On Wed, 24 Sep 2008 07:21:47 -0500, Matt Domsch wrote: > Fedora Rawhide-in-Mock Build Results for i386 > using the rawhide tree of Tuesday, 2008-10-23. > audacious-plugin-fc-0.2-7 (build/make) mschwendt This is Audacious' API being broken: #454364 From nicolas.mailhot at laposte.net Thu Sep 25 10:12:49 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 25 Sep 2008 12:12:49 +0200 (CEST) Subject: please deactivate services by default! In-Reply-To: <200809251038.34508.billcrawford1970@gmail.com> References: <1222287197.3941.7.camel@choeger6> <20080924213834.GM1414283@hiwaay.net> <200809251038.34508.billcrawford1970@gmail.com> Message-ID: <79b49d63945363e8177dda7db1b27ab2.squirrel@arekh.dyndns.org> Le Jeu 25 septembre 2008 11:38, Bill Crawford a ?crit : > > On Wednesday 24 September 2008 22:38:34 Chris Adams wrote: >> Once upon a time, Colin Walters said: >> > On Wed, Sep 24, 2008 at 5:31 PM, Chris Adams >> wrote: >> > > What about mail clients like (IIRC) mutt that don't have an SMTP >> client >> > > built in? >> > >> > You can install sendmail or some other server. >> >> If that's the expected way, then there should have been an >> announcement >> so everything that requires SMTP (like mutt) can be modified to have >> "Requires: smtpdaemon". > > Surely the SMTP server isn't absolutely required to be on localhost? I > never > send any mail via localhost SMTP, it's all done through my company's > mail > servers or the Google ones for personal mail. It's often simpler and more robust to have a local smtp that relays to a specific ISP/company smtp. 1. This way when the relay smtp changes you only have to modify one config instead of trawling through app configs for all the places where the smtp server is specified. 2. Also an awful lot of applications have poor failure handling, so having them pass mail to a local server that always work (and queues mail transparently when the relay smtp is not available) helps a lot. 3. Lastly a local smtp can be used to pass mail through your own filters, when you're not happy about the ISP ones, and don't want to wait minutes for MUAs to process new mail every time your start them. -- Nicolas Mailhot From rawhide at fedoraproject.org Thu Sep 25 10:27:12 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Thu, 25 Sep 2008 10:27:12 +0000 (UTC) Subject: rawhide report: 20080925 changes Message-ID: <20080925102712.1CDA81F825C@releng2.fedora.phx.redhat.com> Updated Packages: anaconda-11.4.1.40-1 -------------------- * Wed Sep 24 18:00:00 2008 David Cantrell - 11.4.1.40-1 - Fix network interface bring up in text mode (#463861, #462592) (dcantrell) - Bring back isys.resetResolv() and fix NetworkManager polling in network.py. (dcantrell) - Poll 'State' property from NetworkManager in network.bringUp() (dcantrell) - Log error in rescue mode is network.bringUp() fails. (dcantrell) - Set the first network device in the list to active. (dcantrell) - Get rid of firstnetdevice in Network (dcantrell) - Do not write /lib/udev.d rules if instPath is '' (dcantrell) - Fix problems with bringDeviceUp() calls (#463512) (dcantrell) python-bugzilla-0.4-0.rc2.fc10 ------------------------------ * Thu Sep 18 18:00:00 2008 Will Woods 0.4-0.rc2 - Auto-generated man page with much more info - Fix _attachfile() Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 2 Broken deps for i386 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.i386 requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so Broken deps for x86_64 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.x86_64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.ppc requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so Broken deps for ppc64 ---------------------------------------------------------- eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gspiceui-0.9.65-2.fc10.ppc64 requires gwave livecd-tools-018-1.fc10.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.ppc64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) From alan at redhat.com Thu Sep 25 11:16:53 2008 From: alan at redhat.com (Alan Cox) Date: Thu, 25 Sep 2008 07:16:53 -0400 Subject: please deactivate services by default! In-Reply-To: <20080924230129.GB29113@free.fr> References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> Message-ID: <20080925111653.GA19313@shell.devel.redhat.com> On Thu, Sep 25, 2008 at 01:01:29AM +0200, Patrice Dumas wrote: > On Wed, Sep 24, 2008 at 11:47:16PM +0100, Jonathan Underwood wrote: > > > > ssmtp doesn't do local delivery does it? > > No it doesn't (at least it didn't some time ago). Same for esmtp. But they > can still be /sur/sbin/sendmail replacements. Whats the problem with just starting up sendmail asynchronously in the background. I've always tweaked my boxes to do this for cases when I find I've got no DNS. From berrange at redhat.com Thu Sep 25 11:23:07 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 25 Sep 2008 12:23:07 +0100 Subject: please deactivate services by default! In-Reply-To: <1222287197.3941.7.camel@choeger6> References: <1222287197.3941.7.camel@choeger6> Message-ID: <20080925112307.GB16919@redhat.com> On Wed, Sep 24, 2008 at 10:13:17PM +0200, Christoph H?ger wrote: > Hi, > > I have some services found being activated by default that should be > removed for the following reasons: > > 1. sendmail: starts way too slow, is not usefull for any normal desktop > user I know. Making it usefull requires configuration so I assume > wohever uses that service _can_ activate it. > > 2. ip6tables: I do not know of any provider actually working with ipv6. > So I assume the mass of all users do not need it. There are plenty of ways to get IPv6 from 3rd parties and tunnel it over IPv4 - you don't need to get it from your main ISP. As such I can plug into any network and setup an IPv6-over-IPv4 tunnel, run an radvd daemon on my machine, and more or less every other machine will automatically configure itself with a global IPv6 address with no admin work required. As such you really do want to have IPv6 firewall enabled all the time even if you don't think you're using IPv6. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From johannbg at hi.is Thu Sep 25 12:00:19 2008 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Thu, 25 Sep 2008 12:00:19 +0000 Subject: please deactivate services by default! In-Reply-To: <1222287197.3941.7.camel@choeger6> References: <1222287197.3941.7.camel@choeger6> Message-ID: <48DB7D53.6080507@hi.is> Christoph H?ger wrote: > Hi, > > I have some services found being activated by default that should be > removed for the following reasons: > > 1. sendmail: starts way too slow, is not usefull for any normal desktop > user I know. Making it usefull requires configuration so I assume > wohever uses that service _can_ activate it. > > 2. ip6tables: I do not know of any provider actually working with ipv6. > So I assume the mass of all users do not need it. > > 3. isdn: isdn requires configuration and thus should be set to start > when that config is actually done. > > 4. setroubleshootd: That service also takes long to boot, but its quite > usefull. I wonder if one could make auditd start setroubleshootd when > required - having two daemons working on base of the same informations > seems not very clever. > > So, now go on and punsh me ;) > Add sshd cups bluetooth and avahi to the list as well.. -------------- next part -------------- A non-text attachment was scrubbed... Name: johannbg.vcf Type: text/x-vcard Size: 356 bytes Desc: not available URL: From pbrobinson at gmail.com Thu Sep 25 12:11:30 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 25 Sep 2008 13:11:30 +0100 Subject: please deactivate services by default! In-Reply-To: <48DB7D53.6080507@hi.is> References: <1222287197.3941.7.camel@choeger6> <48DB7D53.6080507@hi.is> Message-ID: <5256d0b0809250511p1df37aevb1d6471ad2083043@mail.gmail.com> >> I have some services found being activated by default that should be >> removed for the following reasons: >> >> 1. sendmail: starts way too slow, is not usefull for any normal desktop >> user I know. Making it usefull requires configuration so I assume >> wohever uses that service _can_ activate it. >> >> 2. ip6tables: I do not know of any provider actually working with ipv6. >> So I assume the mass of all users do not need it. Fedora comes with it out of the box, the Mac AP/routers actually support it out of the box as well as are some others I believe so by not starting this we are leaving users open to possible attach vectors. >> 3. isdn: isdn requires configuration and thus should be set to start >> when that config is actually done. >> >> 4. setroubleshootd: That service also takes long to boot, but its quite >> usefull. I wonder if one could make auditd start setroubleshootd when >> required - having two daemons working on base of the same informations >> seems not very clever. >> >> So, now go on and punsh me ;) >> > > Add sshd cups bluetooth and avahi to the list as well.. I actually think we should not ship printing support by default. Its better for the environment if people actually have to work out how to print to paper before they can do so.... think of trees we'll save :-P Does that make my opinion correct though, probably not! Those services are all very useful to be configured out of the box for newbies, but it doesn't mean they can't be started up async though. Peter From mcepl at redhat.com Thu Sep 25 12:04:35 2008 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 25 Sep 2008 14:04:35 +0200 Subject: please deactivate services by default! References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> <1222290934.5774.35.camel@dimi.lattica.com> Message-ID: On 2008-09-24, 21:15 GMT, Dimi Paun wrote: >> Sendmail startup should only be slow if your dns is broken or >> you've removed the localhost entry from your hosts file. >> Either of those needs to be fixed anyway. > > Give me a break. What naive user would know what to do with > the thing? Even if it takes 200ms to load it's way too much. What was meant (I guess) is that if DNS is broken and there is no localhost entry in /etc/hosts, user however naive will have bigger problems than slow sendmail on start. Mat?j From choeger at cs.tu-berlin.de Thu Sep 25 12:33:24 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Thu, 25 Sep 2008 14:33:24 +0200 Subject: please deactivate services by default! In-Reply-To: <48DB7D53.6080507@hi.is> References: <1222287197.3941.7.camel@choeger6> <48DB7D53.6080507@hi.is> Message-ID: <1222346004.3941.24.camel@choeger6> > Add sshd cups bluetooth and avahi to the list as well.. sshd seems to be deactivated by default on my laptop (I cannot remember deactivating it), bluetooth can be activated on command (hardware switch, starting a bluetooth app) but cups seems to be a problem. How would you print things when the printer is attached to a server (how even discover it)? Avahi may be a little talkative but for home purposes it seems pretty usefull. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From lesmikesell at gmail.com Thu Sep 25 12:33:35 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 25 Sep 2008 07:33:35 -0500 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> <1222290934.5774.35.camel@dimi.lattica.com> Message-ID: <48DB851F.7060804@gmail.com> Matej Cepl wrote: > On 2008-09-24, 21:15 GMT, Dimi Paun wrote: >>> Sendmail startup should only be slow if your dns is broken or >>> you've removed the localhost entry from your hosts file. >>> Either of those needs to be fixed anyway. >> Give me a break. What naive user would know what to do with >> the thing? Even if it takes 200ms to load it's way too much. > > What was meant (I guess) is that if DNS is broken and there is no > localhost entry in /etc/hosts, user however naive will have > bigger problems than slow sendmail on start. Perhaps there should be a diagnostic for that added somewhere to make it more obvious. By the way, what is supposed to happen when you use private addressing but don't provide your own dns for it? Does it annoy the root servers to get all those reverse lookup queries for ranges that don't have public servers? -- Les Mikesell lesmikesell at gmail.com From rdieter at math.unl.edu Thu Sep 25 12:47:14 2008 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 25 Sep 2008 07:47:14 -0500 Subject: please deactivate services by default! References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> Message-ID: Matthew Woehlke wrote: > Christoph ? wrote: >>> I really hope I'm missing something... >> >> calm down! No one will break your system. In the worst case you would >> simply have to enable sendmail. > > Ah... yeah. Good thing I read fedora-devel then, yes? > > > > If an upgrade makes cron jobs stop working, Upgrades not affected, only new installs. > >or a new F10 system allows > creating cron jobs that won't run jobs still (should!) run, there's just no target for the cron notification mails to land. -- Rex From Matt_Domsch at dell.com Thu Sep 25 12:47:44 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 25 Sep 2008 07:47:44 -0500 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <20080924213834.GM1414283@hiwaay.net> Message-ID: <20080925124744.GA25838@auslistsprd01.us.dell.com> On Wed, Sep 24, 2008 at 05:43:37PM -0400, Colin Walters wrote: > On Wed, Sep 24, 2008 at 5:38 PM, Chris Adams wrote: > > Once upon a time, Colin Walters said: > >> On Wed, Sep 24, 2008 at 5:31 PM, Chris Adams wrote: > >> > What about mail clients like (IIRC) mutt that don't have an SMTP client > >> > built in? > >> > >> You can install sendmail or some other server. > > > > If that's the expected way, then there should have been an announcement > > so everything that requires SMTP (like mutt) can be modified to have > > "Requires: smtpdaemon". > > Please do so =) mutt has an SMTP client built in now. set smtp_url = "smtp://yourmailserver.yourdomain.com/" -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From johannbg at hi.is Thu Sep 25 12:57:19 2008 From: johannbg at hi.is (=?ISO-8859-1?Q?=22J=F3hann_B=2E_Gu=F0mundsson=22?=) Date: Thu, 25 Sep 2008 12:57:19 +0000 Subject: please deactivate services by default! In-Reply-To: <1222346004.3941.24.camel@choeger6> References: <1222287197.3941.7.camel@choeger6> <48DB7D53.6080507@hi.is> <1222346004.3941.24.camel@choeger6> Message-ID: <48DB8AAF.2070203@hi.is> Christoph H?ger wrote: >> Add sshd cups bluetooth and avahi to the list as well.. >> > > sshd seems to be deactivated by default on my laptop (I cannot remember > deactivating it), bluetooth can be activated on command (hardware > switch, starting a bluetooth app) but cups seems to be a problem. How > would you print things when the printer is attached to a server (how > even discover it)? Avahi may be a little talkative but for home purposes > it seems pretty usefull. > ssh is on by default and port 22 is open in the firewall In system-config-firewall --> Trusted services they removed the hash from SSH so the novice enduser would not notice it.... ( It shows in Other ports now ) Services that are not needed for system functionality and network connection should be turned of by default JB -------------- next part -------------- A non-text attachment was scrubbed... Name: johannbg.vcf Type: text/x-vcard Size: 356 bytes Desc: not available URL: From choeger at cs.tu-berlin.de Thu Sep 25 13:04:30 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Thu, 25 Sep 2008 15:04:30 +0200 Subject: please deactivate services by default! In-Reply-To: <48DB8AAF.2070203@hi.is> References: <1222287197.3941.7.camel@choeger6> <48DB7D53.6080507@hi.is> <1222346004.3941.24.camel@choeger6> <48DB8AAF.2070203@hi.is> Message-ID: <1222347870.3941.28.camel@choeger6> Am Donnerstag, den 25.09.2008, 12:57 +0000 schrieb "J?hann B. Gu?mundsson": > Christoph H?ger wrote: > >> Add sshd cups bluetooth and avahi to the list as well.. > >> > > > > sshd seems to be deactivated by default on my laptop (I cannot remember > > deactivating it), bluetooth can be activated on command (hardware > > switch, starting a bluetooth app) but cups seems to be a problem. How > > would you print things when the printer is attached to a server (how > > even discover it)? Avahi may be a little talkative but for home purposes > > it seems pretty usefull. > > > ssh is on by default and port 22 is open in the firewall > In system-config-firewall --> Trusted services > they removed the hash from SSH so the novice enduser > would not notice it.... ( It shows in Other ports now ) Hmm, then I must have disabled ssh somewhen... I Just cannot remember. > > Services that are not needed for system functionality > and network connection should be turned of by default IMO every service that offers a "service" to the network should be off by default. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From michel.sylvan at gmail.com Thu Sep 25 13:15:12 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 25 Sep 2008 09:15:12 -0400 Subject: Should we mount with reltime as default? Message-ID: One of the configuration changes made when installing Linux on Flash media seems to be to turn on the 'reltime' mount option in fstab. Should we perhaps turn this by default, if there are no downside to this? Failing that, perhaps being able to mark, when using Anaconda, which devices are actually Flash -- or autodetect them somehow -- and use 'reltime' on those? Regards, -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From sundaram at fedoraproject.org Thu Sep 25 13:26:11 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Thu, 25 Sep 2008 18:56:11 +0530 Subject: please deactivate services by default! In-Reply-To: <1222347870.3941.28.camel@choeger6> References: <1222287197.3941.7.camel@choeger6> <48DB7D53.6080507@hi.is> <1222346004.3941.24.camel@choeger6> <48DB8AAF.2070203@hi.is> <1222347870.3941.28.camel@choeger6> Message-ID: <48DB9173.8050508@fedoraproject.org> Christoph H?ger wrote: > Am Donnerstag, den 25.09.2008, 12:57 +0000 schrieb "J?hann B. > Gu?mundsson": >> Christoph H?ger wrote: >>>> Add sshd cups bluetooth and avahi to the list as well.. >>>> >>> sshd seems to be deactivated by default on my laptop (I cannot remember >>> deactivating it), bluetooth can be activated on command (hardware >>> switch, starting a bluetooth app) but cups seems to be a problem. How >>> would you print things when the printer is attached to a server (how >>> even discover it)? Avahi may be a little talkative but for home purposes >>> it seems pretty usefull. >>> >> ssh is on by default and port 22 is open in the firewall >> In system-config-firewall --> Trusted services >> they removed the hash from SSH so the novice enduser >> would not notice it.... ( It shows in Other ports now ) > > Hmm, then I must have disabled ssh somewhen... I Just cannot remember. No. sshd has always been disabled on the live cd since it doesn't have a root password. Rahul From mcepl at redhat.com Thu Sep 25 13:16:14 2008 From: mcepl at redhat.com (Matej Cepl) Date: Thu, 25 Sep 2008 15:16:14 +0200 Subject: please deactivate services by default! References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <1222299566.1895.0.camel@luminos.localdomain> Message-ID: On 2008-09-24, 23:54 GMT, Matthew Woehlke wrote: > Ok, that's acceptable just as long as "local delivery" is still > a choice and ensures that sendmail gets installed. And as long I guess you meant s!sendmail!/usr/sbin/sendmail! right? If we would have finally maintained postfix, I would prefer it. Mat?j From pemboa at gmail.com Thu Sep 25 14:23:02 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 25 Sep 2008 09:23:02 -0500 Subject: please deactivate services by default! In-Reply-To: <48DB7D53.6080507@hi.is> References: <1222287197.3941.7.camel@choeger6> <48DB7D53.6080507@hi.is> Message-ID: <16de708d0809250723l490da64du53cd7f9f091880e5@mail.gmail.com> 2008/9/25 "J?hann B. Gu?mundsson" : > Christoph H?ger wrote: >> >> Hi, >> >> I have some services found being activated by default that should be >> removed for the following reasons: >> >> 1. sendmail: starts way too slow, is not usefull for any normal desktop >> user I know. Making it usefull requires configuration so I assume >> wohever uses that service _can_ activate it. >> >> 2. ip6tables: I do not know of any provider actually working with ipv6. >> So I assume the mass of all users do not need it. >> >> 3. isdn: isdn requires configuration and thus should be set to start >> when that config is actually done. >> >> 4. setroubleshootd: That service also takes long to boot, but its quite >> usefull. I wonder if one could make auditd start setroubleshootd when >> required - having two daemons working on base of the same informations >> seems not very clever. >> >> So, now go on and punsh me ;) >> > > Add sshd cups bluetooth and avahi to the list as well.. sshd -- it's already disabled off of some LiveCDs and I hate this bluetooth -- this was dismissed last time this thread came up, I assume nothing has changed. avahi -- no opinion, not familiar with this -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From pemboa at gmail.com Thu Sep 25 14:23:02 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 25 Sep 2008 09:23:02 -0500 Subject: please deactivate services by default! In-Reply-To: <48DB7D53.6080507@hi.is> References: <1222287197.3941.7.camel@choeger6> <48DB7D53.6080507@hi.is> Message-ID: <16de708d0809250723l490da64du53cd7f9f091880e5@mail.gmail.com> 2008/9/25 "J?hann B. Gu?mundsson" : > Christoph H?ger wrote: >> >> Hi, >> >> I have some services found being activated by default that should be >> removed for the following reasons: >> >> 1. sendmail: starts way too slow, is not usefull for any normal desktop >> user I know. Making it usefull requires configuration so I assume >> wohever uses that service _can_ activate it. >> >> 2. ip6tables: I do not know of any provider actually working with ipv6. >> So I assume the mass of all users do not need it. >> >> 3. isdn: isdn requires configuration and thus should be set to start >> when that config is actually done. >> >> 4. setroubleshootd: That service also takes long to boot, but its quite >> usefull. I wonder if one could make auditd start setroubleshootd when >> required - having two daemons working on base of the same informations >> seems not very clever. >> >> So, now go on and punsh me ;) >> > > Add sshd cups bluetooth and avahi to the list as well.. sshd -- it's already disabled off of some LiveCDs and I hate this bluetooth -- this was dismissed last time this thread came up, I assume nothing has changed. avahi -- no opinion, not familiar with this -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From cmadams at hiwaay.net Thu Sep 25 14:35:25 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 25 Sep 2008 09:35:25 -0500 Subject: Should we mount with reltime as default? In-Reply-To: References: Message-ID: <20080925143525.GE1126464@hiwaay.net> Once upon a time, Michel Salim said: > One of the configuration changes made when installing Linux on Flash > media seems to be to turn on the 'reltime' mount option in fstab. > Should we perhaps turn this by default, if there are no downside to > this? Do you mean 'relatime'? I don't see 'reltime' in the mount(8) man page. If you mean 'relatime', I think that has been the default since (at least) Fedora 8 for ext3 filesystems; it is set in the kernel. You have to add 'atime' to the mount options to turn it off. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From cmadams at hiwaay.net Thu Sep 25 14:36:35 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 25 Sep 2008 09:36:35 -0500 Subject: please deactivate services by default! In-Reply-To: <48DB9173.8050508@fedoraproject.org> References: <1222287197.3941.7.camel@choeger6> <48DB7D53.6080507@hi.is> <1222346004.3941.24.camel@choeger6> <48DB8AAF.2070203@hi.is> <1222347870.3941.28.camel@choeger6> <48DB9173.8050508@fedoraproject.org> Message-ID: <20080925143635.GF1126464@hiwaay.net> Once upon a time, Rahul Sundaram said: > No. sshd has always been disabled on the live cd since it doesn't have a > root password. Wouldn't it be better to have sshd configured to either: - block root logins - block logins to accounts with no password -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From ville.skytta at iki.fi Thu Sep 25 15:48:43 2008 From: ville.skytta at iki.fi (Ville =?iso-8859-1?q?Skytt=E4?=) Date: Thu, 25 Sep 2008 18:48:43 +0300 Subject: Fedora rawhide rebuild in mock status 2008-09-23 x86_64 In-Reply-To: <20080924122036.GA28400@mock.linuxdev.us.dell.com> References: <20080924122036.GA28400@mock.linuxdev.us.dell.com> Message-ID: <200809251848.43509.ville.skytta@iki.fi> On Wednesday 24 September 2008, Matt Domsch wrote: > kaffeine-0.8.7-2.fc10 (build/make) > kdemultimedia-4.1.1-1.fc10 (build/make) cdparanoia C++ issues, https://bugzilla.redhat.com/463009 From pertusus at free.fr Thu Sep 25 15:55:46 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 25 Sep 2008 17:55:46 +0200 Subject: updated script to check conflicts with scratch builds Message-ID: <20080925155546.GA3625@free.fr> Hello, I have updated the script that I use to check conflicts in packages for those who don't have a multilib setup. I also reattach the python script multilib-cmp.py. -- Pat -------------- next part -------------- A non-text attachment was scrubbed... Name: get_scratch_packages.sh Type: application/x-sh Size: 841 bytes Desc: not available URL: -------------- next part -------------- #!/usr/bin/python -tt # # Simple script to help ferret out multilib conflicts. # # Can be used in two different modes. The first is comparing two # packages given on the command line and showing any conflicts. # multilib-cmp.py # Can also be used to find multilib conflicts in a tree # multilib-cmp.py # # Copyright, 2006 Red Hat, Inc. # Jeremy Katz # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; version 2 only # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU Library General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. import os,sys import glob import rpm import rpmUtils.arch import rpmUtils.miscutils _ts = None def comparePackages(one, two): fi1 = one.fiFromHeader() fi2 = two.fiFromHeader() num = 0 for file1 in fi1: name = fi1.FN() for file2 in fi2: if fi2.FN() == name: break if fi2.FN() != name: continue # if they're different colors, rpm is fine with it if fi1.FColor() != fi2.FColor(): continue # else, they're the same color and same path. ensure they don't # conflict if fi1.MD5() != fi2.MD5(): print "File conflict for %s in %s-%s-%s" %(fi1.FN(), one['name'], one['version'], one['release']) num += 1 return num def packageCompare(one, two): global _ts if _ts is None: _ts = rpm.TransactionSet() _ts.setVSFlags(-1) if not os.access(one, os.R_OK) or not os.access(two, os.R_OK): print one, two print "need packages!" sys.exit(1) fd = os.open(one, os.O_RDONLY) h1 = _ts.hdrFromFdno(fd) os.close(fd) fd = os.open(two, os.O_RDONLY) h2 = _ts.hdrFromFdno(fd) os.close(fd) return comparePackages(h1, h2) def multilibTreeCompare(tree): if not os.path.isdir(tree): print "Not a tree!" sys.exit(1) checked = [] for f in os.listdir(tree): (n, v, r, e, a) = rpmUtils.miscutils.splitFilename(f) if not rpmUtils.arch.isMultiLibArch(a): continue files = glob.glob("%s/%s-%s-%s.*.rpm" %(tree, n, v, r)) if len(files) == 1: continue for f2 in files: f2 = os.path.basename(f2) (n2, v2, r2, e2, a2) = rpmUtils.miscutils.splitFilename(f2) if (n, a) == (n2, a2): continue if a2 not in rpmUtils.arch.getArchList(a): continue packageCompare("%s/%s" %(tree, f), "%s/%s" %(tree, f2)) pass def main(): if len(sys.argv) == 2: multilibTreeCompare(sys.argv[1]) elif len(sys.argv) == 3: num = packageCompare(sys.argv[1], sys.argv[2]) if num == 0: print "No conflicts" else: print "Invalid usage!" sys.exit(1) if __name__ == "__main__": main() From mw_triad at users.sourceforge.net Thu Sep 25 15:56:32 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 25 Sep 2008 10:56:32 -0500 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <1222299566.1895.0.camel@luminos.localdomain> Message-ID: Matej Cepl wrote: > On 2008-09-24, 23:54 GMT, Matthew Woehlke wrote: >> Ok, that's acceptable just as long as "local delivery" is still >> a choice and ensures that sendmail gets installed. And as long > > I guess you meant > > s!sendmail!/usr/sbin/sendmail! Strictly speaking, yes, though I was somewhat assuming "sendmail" would be the default provider of that (though that isn't critical). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw) From mw_triad at users.sourceforge.net Thu Sep 25 16:19:03 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 25 Sep 2008 11:19:03 -0500 Subject: please deactivate services by default! In-Reply-To: <1222323486.1895.16.camel@luminos.localdomain> References: <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <20080924235701.GA14542@free.fr> <1222303283.1895.10.camel@luminos.localdomain> <1222323486.1895.16.camel@luminos.localdomain> Message-ID: Jesse Keating wrote: > On Wed, 2008-09-24 at 20:08 -0500, Matthew Woehlke wrote: >> First, I'm not talking about root's mail. Second, how does local mail >> not work? I get 'you have mail' notifications just fine (granted, bash >> isn't as obnoxious about it as it could be, i.e. it seems like some days >> I don't see a notification, but...). 'mail' is able to read and manage >> my spool. What's the problem? > > Root's mail is where things like logwatch and smart reports go. That's > the only thing getting mail on a fresh install. > > For users that never log into a virtual tty (and that's a large large > amount of them) they never see a new mail notification. I agree it's a problem. It is, however, not the problem I'm raising my concerns about. I *do* log into tty's (konsole is almost always one of the first three programs I start, and I often have a dozen or so tty's open at once), and I do get local mail sent to my user, ergo I *do* see new mail notifications. I don't think that's uncommon for power users using cron. (Hmm. This reminds me of the opposite of the gdm-multi-login conversation, the attitude that we should cater /only/ to Joe Average and screw over power users.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw) From mw_triad at users.sourceforge.net Thu Sep 25 16:24:45 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 25 Sep 2008 11:24:45 -0500 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> Message-ID: Rex Dieter wrote: > Matthew Woehlke wrote: >> Christoph ? wrote: >>>> I really hope I'm missing something... >>> calm down! No one will break your system. In the worst case you would >>> simply have to enable sendmail. >> Ah... yeah. Good thing I read fedora-devel then, yes? >> >> >> >> If an upgrade makes cron jobs stop working, > > Upgrades not affected, only new installs. That's good, but... >>> or a new F10 system allows >> creating cron jobs that won't run > > jobs still (should!) run, there's just no target for the cron notification > mails to land. ...I still feel that this is a problem. Scenario: I'm Joe User. I use cron+rsync to do nightly backups and keep my home on a separate partition (so I'm somewhere in the "power user" category, but I don't read fedora-devel). I just upgraded to F10 (F11?) by doing a clean install. I didn't read the release notes (yeah, we know the joke, "who does?"). I reloaded my crontab with my backup script (only generates output, hence mail, if an error occurs), and go on with life. Probably I'll notice that I'm not getting any mail and take it as a good sign (in fact, everyting /is/ working perfectly right now). Some time later, the job starts failing, but since I didn't know I had to install sendmail, the error is sent to /dev/null and I am totally clueless. Later still, my main drive fails. Now... I just lost all of my work since whenever rsync went south. Not because I'm an idiot and didn't have a backup strategy, but because my new Fedora disabled a critical system component (cron's ability to send mail) that should - that otherwise *would* - have told me there was a problem within a day or two, long before it compounded into large amounts of lost data/work. If we're going to disable important system functionality, it's *critical* IMO that we beat people over the head letting them know that we're doing so, so that the people affected don't see functionality silently removed and only find out about it when it's too late. I think we've already suggested the best way to do this; make setting up local mail part of firstboot. Then we simply don't /have/ the problem that cron has nowhere to deliver notifications. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw) From mw_triad at users.sourceforge.net Thu Sep 25 16:31:02 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 25 Sep 2008 11:31:02 -0500 Subject: please deactivate services by default! In-Reply-To: <20080925143635.GF1126464@hiwaay.net> References: <1222287197.3941.7.camel@choeger6> <48DB7D53.6080507@hi.is> <1222346004.3941.24.camel@choeger6> <48DB8AAF.2070203@hi.is> <1222347870.3941.28.camel@choeger6> <48DB9173.8050508@fedoraproject.org> <20080925143635.GF1126464@hiwaay.net> Message-ID: Chris Adams wrote: > Once upon a time, Rahul Sundaram said: >> No. sshd has always been disabled on the live cd since it doesn't have a >> root password. > > Wouldn't it be better to have sshd configured to either: > > - block root logins This seems to be the default on some UNIX's (or, at least, it's true for some of the machines I work with, though it's possible that IT set it up). I'm indifferent; I might re-enable it (though, since I can su also, I might not), but I don't mind making this default. > - block logins to accounts with no password This is different from passphrase-less keys, right? If so I'd definitely vote for this. It doesn't need to be exclusive with disabling root login, though. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw) From notting at redhat.com Thu Sep 25 16:41:38 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 25 Sep 2008 12:41:38 -0400 Subject: please deactivate services by default! In-Reply-To: References: <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> Message-ID: <20080925164138.GC16719@nostromo.devel.redhat.com> Matthew Woehlke (mw_triad at users.sourceforge.net) said: > I'm Joe User. I use cron+rsync to do nightly backups and keep my home on > a separate partition (so I'm somewhere in the "power user" category, but > I don't read fedora-devel). I just upgraded to F10 (F11?) by doing a > clean install. I didn't read the release notes (yeah, we know the joke, > "who does?"). This has *nothing* to do with upgrades. This is all about the desktop livecd only. Bill From mw_triad at users.sourceforge.net Thu Sep 25 16:47:01 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 25 Sep 2008 11:47:01 -0500 Subject: please deactivate services by default! In-Reply-To: <20080925164138.GC16719@nostromo.devel.redhat.com> References: <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > Matthew Woehlke (mw_triad at users.sourceforge.net) said: >> I'm Joe User. I use cron+rsync to do nightly backups and keep my home on >> a separate partition (so I'm somewhere in the "power user" category, but >> I don't read fedora-devel). I just upgraded to F10 (F11?) by doing a >> clean install. I didn't read the release notes (yeah, we know the joke, >> "who does?"). > > This has *nothing* to do with upgrades. This is all about the desktop > livecd only. If so, that's the first I heard, unless that's what "desktop image" means (which is not at all clear). I'll allow that expecting cron and local mail delivery to work on a livecd might be a bit much :-). Does it still work on a default *install*? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw) From pertusus at free.fr Thu Sep 25 16:51:00 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 25 Sep 2008 18:51:00 +0200 Subject: please deactivate services by default! In-Reply-To: References: <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> Message-ID: <20080925165100.GB3625@free.fr> On Thu, Sep 25, 2008 at 11:24:45AM -0500, Matthew Woehlke wrote: > > ...I still feel that this is a problem. Scenario: > > If we're going to disable important system functionality, it's It is acritical system functionnality for your use case. But for other use cases it is something annoying, it fills /var/spool with unneeded data, there is a daemon running (only listening on localhost, but still). your use case is not superior to the use case of a user not wanting to have a smtp daemon in the default case. -- Pat From tgl at redhat.com Thu Sep 25 17:04:02 2008 From: tgl at redhat.com (Tom Lane) Date: Thu, 25 Sep 2008 13:04:02 -0400 Subject: rpms/postgresql/F-9 .cvsignore, 1.42, 1.43 postgresql-ac-version.patch, 1.2, 1.3 postgresql.spec, 1.96, 1.97 sources, 1.43, 1.44 In-Reply-To: <1222359209.3368.14.camel@laptop.gunduz.org> References: <20080925145120.3996D7010A@cvs1.fedora.phx.redhat.com> <1222359209.3368.14.camel@laptop.gunduz.org> Message-ID: <8683.1222362242@sss.pgh.pa.us> Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= writes: > Hi Tom, > On Thu, 2008-09-25 at 14:51 +0000, Tom Lane wrote: >> -Source17: >> http://www.postgresql.org/docs/manuals/postgresql-8.3.3-US.pdf >> +Source17: >> http://www.postgresql.org/docs/manuals/postgresql-8.3.4-US.pdf > This gives 404 -- you don't need to change URL. Just make it: > http://www.postgresql.org/files/documentation/pdf/8.3/postgresql-8.3-US.pdf Actually, I was just wondering who to complain to about that ... and I think it's you ;-) The decision to overwrite the same URL with new documentation updates means that there is actually not any way for me to obey the source-URL packaging guidelines with respect to the PG documentation. If I point to that URL in the 8.3.4 specfile, then the SRPM will stop matching the upstream URL as soon as 8.3.5 comes out and someone overwrites the PDF again. Give each PDF version an honest permanent URL, and I'll link to it. (I've also considered not treating the PDF as a source at all, but generating it during RPM build; which would get me around the problem that the docs aren't usually available when I need to build the RPMs. But it'd increase the package build time rather horrendously.) regards, tom lane From lesmikesell at gmail.com Thu Sep 25 17:10:39 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 25 Sep 2008 12:10:39 -0500 Subject: please deactivate services by default! In-Reply-To: <20080925165100.GB3625@free.fr> References: <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925165100.GB3625@free.fr> Message-ID: <48DBC60F.5030104@gmail.com> Patrice Dumas wrote: > On Thu, Sep 25, 2008 at 11:24:45AM -0500, Matthew Woehlke wrote: >> ...I still feel that this is a problem. Scenario: >> >> If we're going to disable important system functionality, it's > > It is acritical system functionnality for your use case. But for other > use cases it is something annoying, it fills /var/spool with unneeded > data, there is a daemon running (only listening on localhost, but > still). your use case is not superior to the use case of a user not > wanting to have a smtp daemon in the default case. So, before taking away standard functionality that is expected on any unix-like system, perhaps you could ask the the user in question if he cares if important system messages are quietly discarded - and if not, where he would like them to be delivered. -- Les Mikesell lesmikesell at gmail.com From ville.skytta at iki.fi Thu Sep 25 17:11:55 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 25 Sep 2008 20:11:55 +0300 Subject: rpms/blam/F-9 blam.spec,1.24,1.25 In-Reply-To: <20080925095250.1fb37551.mschwendt@gmail.com> References: <20080924060730.2E9F370103@cvs1.fedora.phx.redhat.com> <200809250855.38538.ville.skytta@iki.fi> <20080925095250.1fb37551.mschwendt@gmail.com> Message-ID: <200809252011.56390.ville.skytta@iki.fi> On Thursday 25 September 2008, Michael Schwendt wrote: > However, the added line changes history. Would you mind just telling me how to fix it so we can move on? From choeger at cs.tu-berlin.de Thu Sep 25 17:20:59 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Thu, 25 Sep 2008 19:20:59 +0200 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> Message-ID: <1222363259.3941.36.camel@choeger6> So Joe User, what are you doing with that mail? Is it just dropped in /var/spool...? Then you probably only want a /usr/bin/sendmail binary that does so. But you do not need an smtp daemon then. If you want that mail to be routed over your network (or to other networks) you'll probably configure that after a clean install - and notice that you have to enable that daemon. On my laptop I (and arrogant as I am I think others too ;)) basically do not want to see _any_ infrastructure services run by default eating ressources and much boot time. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From sgrubb at redhat.com Thu Sep 25 17:28:01 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 25 Sep 2008 13:28:01 -0400 Subject: Do we care about /sbin /bin linked to /usr/lib ? Message-ID: <200809251328.01886.sgrubb@redhat.com> Hi, I wrote a utility that checks all apps in /bin & /sbin to see if they link against anything in /usr. Is this a problem that we care about? /bin/rpm uses something in /usr /sbin/arping uses something in /usr /sbin/audispd-zos-remote uses something in /usr /sbin/audisp-prelude uses something in /usr /sbin/audisp-remote uses something in /usr /sbin/auditd uses something in /usr /sbin/cifs.upcall uses something in /usr /sbin/grubby uses something in /usr /sbin/lsusb uses something in /usr /sbin/nash uses something in /usr /sbin/setkey uses something in /usr /sbin/umount.hal uses something in /usr This was not an everything install. -Steve From limb at jcomserv.net Thu Sep 25 17:32:00 2008 From: limb at jcomserv.net (Jon Ciesla) Date: Thu, 25 Sep 2008 12:32:00 -0500 (CDT) Subject: Do we care about /sbin /bin linked to /usr/lib ? In-Reply-To: <200809251328.01886.sgrubb@redhat.com> References: <200809251328.01886.sgrubb@redhat.com> Message-ID: <23210.198.175.55.5.1222363920.squirrel@mail.jcomserv.net> > Hi, > > I wrote a utility that checks all apps in /bin & /sbin to see if they link > against anything in /usr. Is this a problem that we care about? > > /bin/rpm uses something in /usr > /sbin/arping uses something in /usr > /sbin/audispd-zos-remote uses something in /usr > /sbin/audisp-prelude uses something in /usr > /sbin/audisp-remote uses something in /usr > /sbin/auditd uses something in /usr > /sbin/cifs.upcall uses something in /usr > /sbin/grubby uses something in /usr > /sbin/lsusb uses something in /usr > /sbin/nash uses something in /usr > /sbin/setkey uses something in /usr > /sbin/umount.hal uses something in /usr > > This was not an everything install. I would think that we would care. I'd be very curious to see the results of this run on an everything install. And the code. :) > -Steve > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- novus ordo absurdum From mschwendt at gmail.com Thu Sep 25 17:33:24 2008 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 25 Sep 2008 19:33:24 +0200 Subject: rpms/blam/F-9 blam.spec,1.24,1.25 In-Reply-To: <200809252011.56390.ville.skytta@iki.fi> References: <20080924060730.2E9F370103@cvs1.fedora.phx.redhat.com> <200809250855.38538.ville.skytta@iki.fi> <20080925095250.1fb37551.mschwendt@gmail.com> <200809252011.56390.ville.skytta@iki.fi> Message-ID: <20080925193324.656df72f.mschwendt@gmail.com> On Thu, 25 Sep 2008 20:11:55 +0300, Ville Skytt? wrote: > On Thursday 25 September 2008, Michael Schwendt wrote: > > > However, the added line changes history. > > Would you mind just telling me how to fix it so we can move on? Replacing it with (c) 2005-2008 Fedora Project would be reasonable as pointed out before. It doesn't fill in the blanks, but is closer to the truth. Oldest public mention I could find of the original script is this message where Seth Vidal attached it after he had added one sys.arg: http://www.redhat.com/archives/fedora-maintainers/2005-February/msg00042.html No author information, no licence, no copyright. From notting at redhat.com Thu Sep 25 17:38:58 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 25 Sep 2008 13:38:58 -0400 Subject: please deactivate services by default! In-Reply-To: References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> Message-ID: <20080925173858.GA21166@nostromo.devel.redhat.com> Matthew Woehlke (mw_triad at users.sourceforge.net) said: > If so, that's the first I heard, unless that's what "desktop image" > means (which is not at all clear). > > I'll allow that expecting cron and local mail delivery to work on a > livecd might be a bit much :-). Does it still work on a default > *install*? On the base Fedora distro spin (jack of all trades, master of none), it should. Note that neither Evolution nor Thunderbird monitor the local spools by default, so even stuffing an alias in /etc/aliases wouldn't really help the cron case. Bill From sgrubb at redhat.com Thu Sep 25 17:40:42 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 25 Sep 2008 13:40:42 -0400 Subject: Do we care about /sbin /bin linked to /usr/lib ? In-Reply-To: <23210.198.175.55.5.1222363920.squirrel@mail.jcomserv.net> References: <200809251328.01886.sgrubb@redhat.com> <23210.198.175.55.5.1222363920.squirrel@mail.jcomserv.net> Message-ID: <200809251340.42554.sgrubb@redhat.com> On Thursday 25 September 2008 13:32:00 Jon Ciesla wrote: > > This was not an everything install. > > I would think that we would care. ?I'd be very curious to see the > results of this run on an everything install. ?And the code. :) This and about 10-15 other programs are part of a collection of programs I run as a post install check. >From ~/.rpmmacros: %__arch_install_post ~/checks/rpm-checks \ /usr/lib/rpm/check-rpaths \ /usr/lib/rpm/check-buildroot this is the new program. Its designed to take a directory path so it can be pointed to the rpm build install dir. It otherwise defaults to "/" for everything install testing. -Steve #!/bin/sh if [ $# -ge 2 ] ; then echo "Usage: check-root-usr [directory]" 1>&2 exit 1 fi DIR="/" if [ $# -eq 1 ] ; then if [ -d "$1" ] ; then DIR="$1" else echo "Option passed in was not a directory" 1>&2 exit 1 fi fi rc=0 ROOT="/bin /sbin" for d in $ROOT do # Skip dirs that are not in the package if [ ! -e $DIR/$d ] ; then continue fi files=`ls $DIR/$d` for f in $files do # Skip apps we can't read if [ ! -r $DIR$d/$f ] ; then continue fi # Skip static linked apps ldd $DIR$d/$f 2>/dev/null 1>&2 if [ $? -eq 1 ] ; then continue fi ldd $DIR$d/$f | grep '\/usr\/' 2>/dev/null 1>&2 if [ $? -eq 0 ] ; then echo "$d/$f uses something in /usr:" ldd $DIR$d/$f | grep '\/usr\/' 2>/dev/null rc=1 fi done done exit $rc From notting at redhat.com Thu Sep 25 17:41:42 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 25 Sep 2008 13:41:42 -0400 Subject: Do we care about /sbin /bin linked to /usr/lib ? In-Reply-To: <200809251328.01886.sgrubb@redhat.com> References: <200809251328.01886.sgrubb@redhat.com> Message-ID: <20080925174142.GB21166@nostromo.devel.redhat.com> Steve Grubb (sgrubb at redhat.com) said: > I wrote a utility that checks all apps in /bin & /sbin to see if they link > against anything in /usr. Is this a problem that we care about? For things that actually need run when /usr may not be available (grrr), it's needed. In the ones you list below, that would include arping, and audit*. For things like rpm or initrd-related tools, it's not really an issue. (Of course, they may not actaully need to be in /sbin, but it may be more trouble to move them.) Bill From ricky at fedoraproject.org Thu Sep 25 17:41:35 2008 From: ricky at fedoraproject.org (Ricky Zhou) Date: Thu, 25 Sep 2008 13:41:35 -0400 Subject: Do we care about /sbin /bin linked to /usr/lib ? In-Reply-To: <23210.198.175.55.5.1222363920.squirrel@mail.jcomserv.net> References: <200809251328.01886.sgrubb@redhat.com> <23210.198.175.55.5.1222363920.squirrel@mail.jcomserv.net> Message-ID: <20080925174135.GA19768@sphe.res.cmu.edu> On 2008-09-25 12:32:00 PM, Jon Ciesla wrote: > I would think that we would care. I'd be very curious to see the results > of this run on an everything install. And the code. :) Here's my command and the output: for file in /bin/* /sbin/*; do ldd $file 2>/dev/null | grep /usr > /dev/null 2>&1 && echo $file; done /bin/rpm /sbin/arping /sbin/cifs.upcall /sbin/grubby /sbin/lsusb /sbin/mkfs.ntfs /sbin/multipath /sbin/multipathd /sbin/nash /sbin/rpcbind /sbin/umount.hal /sbin/ypbind Note that I did not run as root, so this would not include files that are only root-readable. Thanks, Ricky -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From sgrubb at redhat.com Thu Sep 25 17:43:06 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 25 Sep 2008 13:43:06 -0400 Subject: please deactivate services by default! In-Reply-To: <1222287197.3941.7.camel@choeger6> References: <1222287197.3941.7.camel@choeger6> Message-ID: <200809251343.07036.sgrubb@redhat.com> On Wednesday 24 September 2008 16:13:17 Christoph H?ger wrote: > 4. setroubleshootd: That service also takes long to boot, but its quite > usefull. I wonder if one could make auditd start setroubleshootd when > required - having two daemons working on base of the same informations > seems not very clever. This was always intended by me to run as an audispd plugin. When it was written, the author chose not to do it that way. But running as a plugin would solve the boot problem since auditd would hide the start up from init. -Steve From sgrubb at redhat.com Thu Sep 25 17:51:18 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 25 Sep 2008 13:51:18 -0400 Subject: Do we care about /sbin /bin linked to /usr/lib ? In-Reply-To: <20080925174142.GB21166@nostromo.devel.redhat.com> References: <200809251328.01886.sgrubb@redhat.com> <20080925174142.GB21166@nostromo.devel.redhat.com> Message-ID: <200809251351.18293.sgrubb@redhat.com> On Thursday 25 September 2008 13:41:42 Bill Nottingham wrote: > Steve Grubb (sgrubb at redhat.com) said: > > I wrote a utility that checks all apps in /bin & /sbin to see if they > > link against anything in /usr. Is this a problem that we care about? > > For things that actually need run when /usr may not be available (grrr), > it's needed. In the ones you list below, that would include arping, > and audit*. So, that brings up an interesting point...rsyslog has a gssapi plugin. It starts about the same time as auditd. If the plugin is installed and enabled...wouldn't rsyslog have the same problem as auditd? (Both are wanting the gssapi library.) -Steve From ville.skytta at iki.fi Thu Sep 25 17:51:41 2008 From: ville.skytta at iki.fi (Ville =?utf-8?q?Skytt=C3=A4?=) Date: Thu, 25 Sep 2008 20:51:41 +0300 Subject: rpms/blam/F-9 blam.spec,1.24,1.25 In-Reply-To: <20080925193324.656df72f.mschwendt@gmail.com> References: <20080924060730.2E9F370103@cvs1.fedora.phx.redhat.com> <200809252011.56390.ville.skytta@iki.fi> <20080925193324.656df72f.mschwendt@gmail.com> Message-ID: <200809252051.41937.ville.skytta@iki.fi> On Thursday 25 September 2008, Michael Schwendt wrote: > On Thu, 25 Sep 2008 20:11:55 +0300, Ville Skytt? wrote: > > On Thursday 25 September 2008, Michael Schwendt wrote: > > > However, the added line changes history. > > > > Would you mind just telling me how to fix it so we can move on? > > Replacing it with (c) 2005-2008 Fedora Project would be reasonable > as pointed out before. It doesn't fill in the blanks, but is closer > to the truth. Ok, done in git, thanks. From cmadams at hiwaay.net Thu Sep 25 18:03:10 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 25 Sep 2008 13:03:10 -0500 Subject: please deactivate services by default! In-Reply-To: <20080925164138.GC16719@nostromo.devel.redhat.com> References: <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> Message-ID: <20080925180310.GL1126464@hiwaay.net> Once upon a time, Bill Nottingham said: > This has *nothing* to do with upgrades. This is all about the desktop > livecd only. But the livecd "copy to hard drive" option is a quick-and-easy way to install a system from a single CD, at which point this is NOT just about the CD version. The smallest thing you can download from Fedora and install (without requiring network access during install) is the livecd, so that is a common path to take. You can then customize easily from there (but if you don't know no local SMTP server was installed, you aren't liable to go looking for it). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From michel.sylvan at gmail.com Thu Sep 25 18:05:50 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 25 Sep 2008 14:05:50 -0400 Subject: Should we mount with reltime as default? In-Reply-To: <20080925143525.GE1126464@hiwaay.net> References: <20080925143525.GE1126464@hiwaay.net> Message-ID: On Thu, Sep 25, 2008 at 10:35 AM, Chris Adams wrote: > Once upon a time, Michel Salim said: >> One of the configuration changes made when installing Linux on Flash >> media seems to be to turn on the 'reltime' mount option in fstab. >> Should we perhaps turn this by default, if there are no downside to >> this? > > Do you mean 'relatime'? I don't see 'reltime' in the mount(8) man page. > > If you mean 'relatime', I think that has been the default since (at > least) Fedora 8 for ext3 filesystems; it is set in the kernel. You have > to add 'atime' to the mount options to turn it off. > Oops, yes. Incidentally, the manpage mispells it as 'realatime' in the norelatime section; time to file a bug. No mention that relatime is the default either -- does this belong in the manpage or in the release notes? Just noticed the Fedora Mini SIG; the wiki should probably have a page discussing configuration options, in case anyone else incorrectly assumes (as I did) that the default is still 'atime'. Thanks, -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From wolfy at nobugconsulting.ro Thu Sep 25 18:06:49 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Thu, 25 Sep 2008 21:06:49 +0300 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <20080924213834.GM1414283@hiwaay.net> Message-ID: <48DBD339.4070408@nobugconsulting.ro> On 09/25/2008 12:43 AM, Colin Walters wrote: > On Wed, Sep 24, 2008 at 5:38 PM, Chris Adams wrote: > >> Once upon a time, Colin Walters said: >> >>> On Wed, Sep 24, 2008 at 5:31 PM, Chris Adams wrote: >>> >>>> What about mail clients like (IIRC) mutt that don't have an SMTP client >>>> built in? >>>> >>> You can install sendmail or some other server. >>> >> If that's the expected way, then there should have been an announcement >> so everything that requires SMTP (like mutt) can be modified to have >> "Requires: smtpdaemon". >> > > Please do so =) > You do not want "Requires: smtpdaemon" but "Requires: MTA". Manuel From cmadams at hiwaay.net Thu Sep 25 18:09:36 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 25 Sep 2008 13:09:36 -0500 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <48DB7D53.6080507@hi.is> <1222346004.3941.24.camel@choeger6> <48DB8AAF.2070203@hi.is> <1222347870.3941.28.camel@choeger6> <48DB9173.8050508@fedoraproject.org> <20080925143635.GF1126464@hiwaay.net> Message-ID: <20080925180936.GM1126464@hiwaay.net> Once upon a time, Matthew Woehlke said: > Chris Adams wrote: > >- block root logins > > This seems to be the default on some UNIX's (or, at least, it's true for > some of the machines I work with, though it's possible that IT set it > up). I'm indifferent; I might re-enable it (though, since I can su also, > I might not), but I don't mind making this default. I always thought it was odd that some things (e.g. telnet) block root logins but others (e.g. ssh) don't. I can telnet in and then su and the password is just as much in the clear as it would have been with straight root-login-telnet. Either all should allow or all should block (I personally block), except for directly attached consoles (so root can get in when all else is broken). Maybe sshd could be configured as "PermitRootLogin without-password", which would require someone to configure keys (but not reconfigure sshd) before root ssh could be used. > >- block logins to accounts with no password > > This is different from passphrase-less keys, right? If so I'd definitely > vote for this. It doesn't need to be exclusive with disabling root > login, though. Yes. I'm pretty sure there is a difference between "account with no password" and "account with empty-string password", and the sshd option "PermitEmptyPasswords" (which defaults to no) works as you describe. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From walters at verbum.org Thu Sep 25 18:09:55 2008 From: walters at verbum.org (Colin Walters) Date: Thu, 25 Sep 2008 14:09:55 -0400 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <1222299566.1895.0.camel@luminos.localdomain> Message-ID: On Thu, Sep 25, 2008 at 11:56 AM, Matthew Woehlke wrote: > Matej Cepl wrote: >> >> On 2008-09-24, 23:54 GMT, Matthew Woehlke wrote: >>> >>> Ok, that's acceptable just as long as "local delivery" is still a choice >>> and ensures that sendmail gets installed. And as long >> >> I guess you meant >> >> s!sendmail!/usr/sbin/sendmail! > > Strictly speaking, yes, though I was somewhat assuming "sendmail" would be > the default provider of that (though that isn't critical). ssmtp is installed. Let's end this thread. From katzj at redhat.com Thu Sep 25 18:11:14 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 25 Sep 2008 14:11:14 -0400 Subject: please deactivate services by default! In-Reply-To: <20080925180310.GL1126464@hiwaay.net> References: <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> Message-ID: <1222366274.22019.18.camel@aglarond.local> On Thu, 2008-09-25 at 13:03 -0500, Chris Adams wrote: > Once upon a time, Bill Nottingham said: > > This has *nothing* to do with upgrades. This is all about the desktop > > livecd only. > > But the livecd "copy to hard drive" option is a quick-and-easy way to > install a system from a single CD, at which point this is NOT just about > the CD version. > > The smallest thing you can download from Fedora and install (without > requiring network access during install) is the livecd, so that is a > common path to take. You can then customize easily from there (but if > you don't know no local SMTP server was installed, you aren't liable to > go looking for it). Having it be in the release notes feels very sensible. Then it's there for those who read before they jump :-) Jeremy From sandeen at redhat.com Thu Sep 25 18:13:06 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 25 Sep 2008 13:13:06 -0500 Subject: Should we mount with reltime as default? In-Reply-To: References: <20080925143525.GE1126464@hiwaay.net> Message-ID: <48DBD4B2.3040403@redhat.com> Michel Salim wrote: > On Thu, Sep 25, 2008 at 10:35 AM, Chris Adams wrote: >> Once upon a time, Michel Salim said: >>> One of the configuration changes made when installing Linux on Flash >>> media seems to be to turn on the 'reltime' mount option in fstab. >>> Should we perhaps turn this by default, if there are no downside to >>> this? >> Do you mean 'relatime'? I don't see 'reltime' in the mount(8) man page. >> >> If you mean 'relatime', I think that has been the default since (at >> least) Fedora 8 for ext3 filesystems; it is set in the kernel. You have >> to add 'atime' to the mount options to turn it off. >> > Oops, yes. Incidentally, the manpage mispells it as 'realatime' in the > norelatime section; time to file a bug. No mention that relatime is > the default either -- does this belong in the manpage or in the > release notes? > > Just noticed the Fedora Mini SIG; the wiki should probably have a page > discussing configuration options, in case anyone else incorrectly > assumes (as I did) that the default is still 'atime'. > > Thanks, > probably release notes, since default relatime is a fedora-special, and not upstream. -Eric From cmadams at hiwaay.net Thu Sep 25 18:13:30 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 25 Sep 2008 13:13:30 -0500 Subject: please deactivate services by default! In-Reply-To: <1222366274.22019.18.camel@aglarond.local> References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <1222366274.22019.18.camel@aglarond.local> Message-ID: <20080925181330.GN1126464@hiwaay.net> Once upon a time, Jeremy Katz said: > Having it be in the release notes feels very sensible. Then it's there > for those who read before they jump :-) Yeah, but you already know. Who else reads those? :-) -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From notting at redhat.com Thu Sep 25 18:16:47 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 25 Sep 2008 14:16:47 -0400 Subject: please deactivate services by default! In-Reply-To: <20080925180310.GL1126464@hiwaay.net> References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> Message-ID: <20080925181647.GC21166@nostromo.devel.redhat.com> Chris Adams (cmadams at hiwaay.net) said: > Once upon a time, Bill Nottingham said: > > This has *nothing* to do with upgrades. This is all about the desktop > > livecd only. > > But the livecd "copy to hard drive" option is a quick-and-easy way to > install a system from a single CD, at which point this is NOT just about > the CD version. > > The smallest thing you can download from Fedora and install (without > requiring network access during install) is the livecd, so that is a > common path to take. You can then customize easily from there (but if > you don't know no local SMTP server was installed, you aren't liable to > go looking for it). Sure, but... - If you're just installing a single-user desktop, there's not really a usage case for a local mail delivery agent - If you're using it as a base for installing Some Other Thing, you're already doing customization; this is just one more thing - If you're installing a lab of machines you want to forward cron stuff centrally, you're (hopefully) doing kickstart, not shoving the livecd in each machine Bill From cmadams at hiwaay.net Thu Sep 25 18:17:04 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 25 Sep 2008 13:17:04 -0500 Subject: Should we mount with reltime as default? In-Reply-To: <48DBD4B2.3040403@redhat.com> References: <20080925143525.GE1126464@hiwaay.net> <48DBD4B2.3040403@redhat.com> Message-ID: <20080925181704.GO1126464@hiwaay.net> Once upon a time, Eric Sandeen said: > Michel Salim wrote: > > Oops, yes. Incidentally, the manpage mispells it as 'realatime' in the > > norelatime section; time to file a bug. No mention that relatime is > > the default either -- does this belong in the manpage or in the > > release notes? > > probably release notes, since default relatime is a fedora-special, and > not upstream. I'd think that if Fedora is going to carry a custom patch to set this in the kernel, Fedora could also carry a custom patch noting it in the mount(8) man page. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From sandeen at redhat.com Thu Sep 25 18:20:36 2008 From: sandeen at redhat.com (Eric Sandeen) Date: Thu, 25 Sep 2008 13:20:36 -0500 Subject: Should we mount with reltime as default? In-Reply-To: <20080925181704.GO1126464@hiwaay.net> References: <20080925143525.GE1126464@hiwaay.net> <48DBD4B2.3040403@redhat.com> <20080925181704.GO1126464@hiwaay.net> Message-ID: <48DBD674.7010205@redhat.com> Chris Adams wrote: > Once upon a time, Eric Sandeen said: >> Michel Salim wrote: >>> Oops, yes. Incidentally, the manpage mispells it as 'realatime' in the >>> norelatime section; time to file a bug. No mention that relatime is >>> the default either -- does this belong in the manpage or in the >>> release notes? >> probably release notes, since default relatime is a fedora-special, and >> not upstream. > > I'd think that if Fedora is going to carry a custom patch to set this in > the kernel, Fedora could also carry a custom patch noting it in the > mount(8) man page. ok :) -Eric (who at one point was going to try to clean up that patch and get it upstream, since the author has not done so...) :) From mattdm at mattdm.org Thu Sep 25 18:22:06 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 25 Sep 2008 14:22:06 -0400 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> Message-ID: <20080925182206.GA2504@jadzia.bu.edu> On Wed, Sep 24, 2008 at 05:35:27PM -0400, Colin Walters wrote: > If there are cron jobs that send mail, we will deactivate them. What will you do with error output from cron? -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs Computing & Information Technology Harvard School of Engineering & Applied Sciences From tmraz at redhat.com Thu Sep 25 18:24:33 2008 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 25 Sep 2008 20:24:33 +0200 Subject: please deactivate services by default! In-Reply-To: <20080925143635.GF1126464@hiwaay.net> References: <1222287197.3941.7.camel@choeger6> <48DB7D53.6080507@hi.is> <1222346004.3941.24.camel@choeger6> <48DB8AAF.2070203@hi.is> <1222347870.3941.28.camel@choeger6> <48DB9173.8050508@fedoraproject.org> <20080925143635.GF1126464@hiwaay.net> Message-ID: <1222367073.16840.151.camel@vespa.frost.loc> On Thu, 2008-09-25 at 09:36 -0500, Chris Adams wrote: > Once upon a time, Rahul Sundaram said: > > No. sshd has always been disabled on the live cd since it doesn't have a > > root password. > > Wouldn't it be better to have sshd configured to either: > > - block root logins This is not yet done due to the requirement to be able to install a server remotely through vnc without a kickstart file. > - block logins to accounts with no password This was always the case for sshd. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From mattdm at mattdm.org Thu Sep 25 18:25:06 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 25 Sep 2008 14:25:06 -0400 Subject: please deactivate services by default! In-Reply-To: <20080925181647.GC21166@nostromo.devel.redhat.com> References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <20080925181647.GC21166@nostromo.devel.redhat.com> Message-ID: <20080925182506.GB2504@jadzia.bu.edu> On Thu, Sep 25, 2008 at 02:16:47PM -0400, Bill Nottingham wrote: > - If you're just installing a single-user desktop, there's not really > a usage case for a local mail delivery agent So, where does logwatch send its reports? -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs Computing & Information Technology Harvard School of Engineering & Applied Sciences From tmraz at redhat.com Thu Sep 25 18:27:16 2008 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 25 Sep 2008 20:27:16 +0200 Subject: please deactivate services by default! In-Reply-To: <20080925173858.GA21166@nostromo.devel.redhat.com> References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925173858.GA21166@nostromo.devel.redhat.com> Message-ID: <1222367236.16840.153.camel@vespa.frost.loc> On Thu, 2008-09-25 at 13:38 -0400, Bill Nottingham wrote: > Matthew Woehlke (mw_triad at users.sourceforge.net) said: > > If so, that's the first I heard, unless that's what "desktop image" > > means (which is not at all clear). > > > > I'll allow that expecting cron and local mail delivery to work on a > > livecd might be a bit much :-). Does it still work on a default > > *install*? > > On the base Fedora distro spin (jack of all trades, master of none), it > should. > > Note that neither Evolution nor Thunderbird monitor the local spools > by default, so even stuffing an alias in /etc/aliases wouldn't really > help the cron case. I wonder whether it would be possible to make them somehow to do so? -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From cmadams at hiwaay.net Thu Sep 25 18:27:22 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 25 Sep 2008 13:27:22 -0500 Subject: please deactivate services by default! In-Reply-To: <20080925182206.GA2504@jadzia.bu.edu> References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <20080925182206.GA2504@jadzia.bu.edu> Message-ID: <20080925182722.GP1126464@hiwaay.net> Once upon a time, Matthew Miller said: > On Wed, Sep 24, 2008 at 05:35:27PM -0400, Colin Walters wrote: > > If there are cron jobs that send mail, we will deactivate them. > > What will you do with error output from cron? Maybe cron could be modified to log it (to the "cron" facility even), although you could end up with a catch-22 for things like logwatch. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From tmraz at redhat.com Thu Sep 25 18:32:35 2008 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 25 Sep 2008 20:32:35 +0200 Subject: Do we care about /sbin /bin linked to /usr/lib ? In-Reply-To: <200809251328.01886.sgrubb@redhat.com> References: <200809251328.01886.sgrubb@redhat.com> Message-ID: <1222367555.16840.155.camel@vespa.frost.loc> On Thu, 2008-09-25 at 13:28 -0400, Steve Grubb wrote: > Hi, > > I wrote a utility that checks all apps in /bin & /sbin to see if they link > against anything in /usr. Is this a problem that we care about? > > /bin/rpm uses something in /usr > /sbin/arping uses something in /usr > /sbin/audispd-zos-remote uses something in /usr > /sbin/audisp-prelude uses something in /usr > /sbin/audisp-remote uses something in /usr > /sbin/auditd uses something in /usr > /sbin/cifs.upcall uses something in /usr > /sbin/grubby uses something in /usr > /sbin/lsusb uses something in /usr > /sbin/nash uses something in /usr > /sbin/setkey uses something in /usr > /sbin/umount.hal uses something in /usr On which Fedora version did you run this, Steve? The /sbin/setkey should be fixed in rawhide in regards to this problem. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From notting at redhat.com Thu Sep 25 18:32:49 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 25 Sep 2008 14:32:49 -0400 Subject: please deactivate services by default! In-Reply-To: <1222367236.16840.153.camel@vespa.frost.loc> References: <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925173858.GA21166@nostromo.devel.redhat.com> <1222367236.16840.153.camel@vespa.frost.loc> Message-ID: <20080925183249.GA24278@nostromo.devel.redhat.com> Tomas Mraz (tmraz at redhat.com) said: > > Note that neither Evolution nor Thunderbird monitor the local spools > > by default, so even stuffing an alias in /etc/aliases wouldn't really > > help the cron case. > > I wonder whether it would be possible to make them somehow to do so? Ideally: - The mail smarthost is a system setting that any configured MTA uses, and any configured MUA automatically picks up (overridable) - The default aliases read the users' e-mail configuration, sending it to their local account, gmail, yahoo, ISP mail, whatever Bill From cmadams at hiwaay.net Thu Sep 25 18:30:17 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 25 Sep 2008 13:30:17 -0500 Subject: please deactivate services by default! In-Reply-To: <1222367073.16840.151.camel@vespa.frost.loc> References: <1222287197.3941.7.camel@choeger6> <48DB7D53.6080507@hi.is> <1222346004.3941.24.camel@choeger6> <48DB8AAF.2070203@hi.is> <1222347870.3941.28.camel@choeger6> <48DB9173.8050508@fedoraproject.org> <20080925143635.GF1126464@hiwaay.net> <1222367073.16840.151.camel@vespa.frost.loc> Message-ID: <20080925183017.GQ1126464@hiwaay.net> Once upon a time, Tomas Mraz said: > On Thu, 2008-09-25 at 09:36 -0500, Chris Adams wrote: > > Once upon a time, Rahul Sundaram said: > > > No. sshd has always been disabled on the live cd since it doesn't have a > > > root password. > > > > Wouldn't it be better to have sshd configured to either: > > > > - block root logins > This is not yet done due to the requirement to be able to install a > server remotely through vnc without a kickstart file. > > > - block logins to accounts with no password > This was always the case for sshd. Okay, so the "sshd has always been disabled on the live cd since it doesn't have a root password" justification doesn't quite work (or does "PermitRootLogin yes" override "PermitEmptyPasswords no"?). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From notting at redhat.com Thu Sep 25 18:34:27 2008 From: notting at redhat.com (Bill Nottingham) Date: Thu, 25 Sep 2008 14:34:27 -0400 Subject: please deactivate services by default! In-Reply-To: <20080925182506.GB2504@jadzia.bu.edu> References: <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <20080925181647.GC21166@nostromo.devel.redhat.com> <20080925182506.GB2504@jadzia.bu.edu> Message-ID: <20080925183427.GB24278@nostromo.devel.redhat.com> Matthew Miller (mattdm at mattdm.org) said: > On Thu, Sep 25, 2008 at 02:16:47PM -0400, Bill Nottingham wrote: > > - If you're just installing a single-user desktop, there's not really > > a usage case for a local mail delivery agent > > So, where does logwatch send its reports? Considering my experience with logwatch, hopefully /dev/null. But I suspect not everyone shares my opinion. Bill From tmraz at redhat.com Thu Sep 25 18:39:33 2008 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 25 Sep 2008 20:39:33 +0200 Subject: please deactivate services by default! In-Reply-To: <20080925183017.GQ1126464@hiwaay.net> References: <1222287197.3941.7.camel@choeger6> <48DB7D53.6080507@hi.is> <1222346004.3941.24.camel@choeger6> <48DB8AAF.2070203@hi.is> <1222347870.3941.28.camel@choeger6> <48DB9173.8050508@fedoraproject.org> <20080925143635.GF1126464@hiwaay.net> <1222367073.16840.151.camel@vespa.frost.loc> <20080925183017.GQ1126464@hiwaay.net> Message-ID: <1222367973.16840.159.camel@vespa.frost.loc> On Thu, 2008-09-25 at 13:30 -0500, Chris Adams wrote: > Once upon a time, Tomas Mraz said: > > On Thu, 2008-09-25 at 09:36 -0500, Chris Adams wrote: > > > Once upon a time, Rahul Sundaram said: > > > > No. sshd has always been disabled on the live cd since it doesn't have a > > > > root password. > > > > > > Wouldn't it be better to have sshd configured to either: > > > > > > - block root logins > > This is not yet done due to the requirement to be able to install a > > server remotely through vnc without a kickstart file. > > > > > - block logins to accounts with no password > > This was always the case for sshd. > > Okay, so the "sshd has always been disabled on the live cd since it > doesn't have a root password" justification doesn't quite work (or does > "PermitRootLogin yes" override "PermitEmptyPasswords no"?). Yes, this justification doesn't work. But I can understand not having sshd enabled on Live CD even without this justification. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From walters at verbum.org Thu Sep 25 18:43:19 2008 From: walters at verbum.org (Colin Walters) Date: Thu, 25 Sep 2008 14:43:19 -0400 Subject: please deactivate services by default! In-Reply-To: <20080925182206.GA2504@jadzia.bu.edu> References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <20080925182206.GA2504@jadzia.bu.edu> Message-ID: On Thu, Sep 25, 2008 at 2:22 PM, Matthew Miller wrote: > On Wed, Sep 24, 2008 at 05:35:27PM -0400, Colin Walters wrote: >> If there are cron jobs that send mail, we will deactivate them. > > What will you do with error output from cron? We install ssmtp now. From michel.sylvan at gmail.com Thu Sep 25 19:04:11 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 25 Sep 2008 15:04:11 -0400 Subject: Should we mount with reltime as default? In-Reply-To: <48DBD674.7010205@redhat.com> References: <20080925143525.GE1126464@hiwaay.net> <48DBD4B2.3040403@redhat.com> <20080925181704.GO1126464@hiwaay.net> <48DBD674.7010205@redhat.com> Message-ID: On Thu, Sep 25, 2008 at 2:20 PM, Eric Sandeen wrote: > Chris Adams wrote: >> Once upon a time, Eric Sandeen said: >>> Michel Salim wrote: >>>> Oops, yes. Incidentally, the manpage mispells it as 'realatime' in the >>>> norelatime section; time to file a bug. No mention that relatime is >>>> the default either -- does this belong in the manpage or in the >>>> release notes? >>> probably release notes, since default relatime is a fedora-special, and >>> not upstream. >> >> I'd think that if Fedora is going to carry a custom patch to set this in >> the kernel, Fedora could also carry a custom patch noting it in the >> mount(8) man page. > > ok :) Sounds good; I added that request to the bug report as well: https://bugzilla.redhat.com/show_bug.cgi?id=463979 Thanks, -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From lesmikesell at gmail.com Thu Sep 25 19:08:18 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 25 Sep 2008 14:08:18 -0500 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <1222299566.1895.0.camel@luminos.localdomain> Message-ID: <48DBE1A2.1090401@gmail.com> Colin Walters wrote: > On Thu, Sep 25, 2008 at 11:56 AM, Matthew Woehlke > wrote: >> Matej Cepl wrote: >>> On 2008-09-24, 23:54 GMT, Matthew Woehlke wrote: >>>> Ok, that's acceptable just as long as "local delivery" is still a choice >>>> and ensures that sendmail gets installed. And as long >>> I guess you meant >>> >>> s!sendmail!/usr/sbin/sendmail! >> Strictly speaking, yes, though I was somewhat assuming "sendmail" would be >> the default provider of that (though that isn't critical). > > ssmtp is installed. Let's end this thread. If I'm looking at the right docs, ssmtp doesn't do the two simple things that need to be done: aliasing, so you can get the system mail delivered to the right person, and local delivery. -- Les Mikesell lesmikesell at gmail.com From mattdm at mattdm.org Thu Sep 25 19:29:52 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 25 Sep 2008 15:29:52 -0400 Subject: make mail go somewhere by default [was Re: please deactivate services by default!] In-Reply-To: <1222299566.1895.0.camel@luminos.localdomain> References: <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <1222299566.1895.0.camel@luminos.localdomain> Message-ID: <20080925192952.GC2504@jadzia.bu.edu> On Wed, Sep 24, 2008 at 04:39:26PM -0700, Jesse Keating wrote: > Which is why we shouldn't be using local delivery for this stuff. > Instead we should ask in firstboot where you'd want the mail delivered > to. Ooh! And do it this way! https://bugzilla.redhat.com/show_bug.cgi?id=143437 -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs Computing & Information Technology Harvard School of Engineering & Applied Sciences From Matt_Domsch at dell.com Thu Sep 25 19:31:05 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Thu, 25 Sep 2008 14:31:05 -0500 Subject: Fedora rawhide rebuild in mock status 2008-09-23 i386 In-Reply-To: <1222304799.23344.514.camel@localhost.localdomain> References: <20080924122147.GA4137@mock.linuxdev.us.dell.com> <1222304799.23344.514.camel@localhost.localdomain> Message-ID: <20080925193105.GA5861@auslistsprd01.us.dell.com> On Wed, Sep 24, 2008 at 09:06:39PM -0400, Tom spot Callaway wrote: > Note that I'm not claiming to have fixed all of these myself (although I > did fix all but one in this list). Thanks Spot, Dominik, Alex, and everyone else who is attacking this list. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From walters at verbum.org Thu Sep 25 19:35:25 2008 From: walters at verbum.org (Colin Walters) Date: Thu, 25 Sep 2008 15:35:25 -0400 Subject: please deactivate services by default! In-Reply-To: <48DBE1A2.1090401@gmail.com> References: <1222287197.3941.7.camel@choeger6> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <1222299566.1895.0.camel@luminos.localdomain> <48DBE1A2.1090401@gmail.com> Message-ID: On Thu, Sep 25, 2008 at 3:08 PM, Les Mikesell wrote: > > If I'm looking at the right docs, ssmtp doesn't do the two simple things > that need to be done: aliasing, so you can get the system mail delivered to > the right person, and local delivery. I guess there is a hard dependency between "cron with custom user cronjobs" and sendmail. I don't want to break that, and it's probably too late in the cycle for this change anyways. It does suck to have everyone take this startup time hit if they're not using custom jobs, but it's been slow for years, so we can take another cycle of slow. For the next cycle, one possible solution to this is to have cron itself start sendmail if there are custom jobs. The system jobs should on failure be treated as OS component crashes and be handled through the same mechanism as http://fedoraproject.org/wiki/Features/CrashHandling From mattdm at mattdm.org Thu Sep 25 19:39:19 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 25 Sep 2008 15:39:19 -0400 Subject: please deactivate services by default! In-Reply-To: <200809251050.58096.billcrawford1970@gmail.com> References: <1222287197.3941.7.camel@choeger6> <48DAC0A9.9040907@gmail.com> <20080924224637.GD29032@mokona.greysector.net> <200809251050.58096.billcrawford1970@gmail.com> Message-ID: <20080925193919.GE2504@jadzia.bu.edu> On Thu, Sep 25, 2008 at 10:50:57AM +0100, Bill Crawford wrote: > CONDITIONAL EXPRESSIONS > file1 -nt file2 > True if file1 is newer (according to modification date) than > file2, or if file1 exists and file2 does not. The problem is: how do you know what file2 is supposed to be? -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs Computing & Information Technology Harvard School of Engineering & Applied Sciences From lesmikesell at gmail.com Thu Sep 25 19:58:16 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 25 Sep 2008 14:58:16 -0500 Subject: make mail go somewhere by default [was Re: please deactivate services by default!] In-Reply-To: <20080925192952.GC2504@jadzia.bu.edu> References: <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <1222299566.1895.0.camel@luminos.localdomain> <20080925192952.GC2504@jadzia.bu.edu> Message-ID: <48DBED58.3040307@gmail.com> Matthew Miller wrote: > On Wed, Sep 24, 2008 at 04:39:26PM -0700, Jesse Keating wrote: >> Which is why we shouldn't be using local delivery for this stuff. >> Instead we should ask in firstboot where you'd want the mail delivered >> to. > > Ooh! And do it this way! > > https://bugzilla.redhat.com/show_bug.cgi?id=143437 That's a good technique, but wouldn't it follow the system style more closely to put install/firstboot setting snippets somewhere under /etc/sysconfig with the stock alias file including from there? -- Les Mikesell lesmikesell at gmail.com From dominik at greysector.net Thu Sep 25 19:39:42 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 25 Sep 2008 21:39:42 +0200 Subject: Fedora rawhide rebuild in mock status 2008-09-23 i386 In-Reply-To: <20080925193105.GA5861@auslistsprd01.us.dell.com> References: <20080924122147.GA4137@mock.linuxdev.us.dell.com> <1222304799.23344.514.camel@localhost.localdomain> <20080925193105.GA5861@auslistsprd01.us.dell.com> Message-ID: <20080925193941.GB12512@mokona.greysector.net> On Thursday, 25 September 2008 at 21:31, Matt Domsch wrote: > On Wed, Sep 24, 2008 at 09:06:39PM -0400, Tom spot Callaway wrote: > > Note that I'm not claiming to have fixed all of these myself (although I > > did fix all but one in this list). > > Thanks Spot, Dominik, Alex, and everyone else who is attacking this > list. And finding bugs and regressions. :( gabedit(gtk2) and freefem++(lam/openmpi) are giving me a bit of hard time. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From mattdm at mattdm.org Thu Sep 25 19:32:59 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 25 Sep 2008 15:32:59 -0400 Subject: please deactivate services by default! In-Reply-To: <20080925183427.GB24278@nostromo.devel.redhat.com> References: <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <20080925181647.GC21166@nostromo.devel.redhat.com> <20080925182506.GB2504@jadzia.bu.edu> <20080925183427.GB24278@nostromo.devel.redhat.com> Message-ID: <20080925193259.GD2504@jadzia.bu.edu> On Thu, Sep 25, 2008 at 02:34:27PM -0400, Bill Nottingham wrote: > > On Thu, Sep 25, 2008 at 02:16:47PM -0400, Bill Nottingham wrote: > > > - If you're just installing a single-user desktop, there's not really > > > a usage case for a local mail delivery agent > > So, where does logwatch send its reports? > Considering my experience with logwatch, hopefully /dev/null. But I suspect > not everyone shares my opinion. Heh. Yeah, okay, fair point -- but currently it's the best we've got (given that epylog seems stalled)... -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs Computing & Information Technology Harvard School of Engineering & Applied Sciences From mw_triad at users.sourceforge.net Thu Sep 25 20:03:25 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 25 Sep 2008 15:03:25 -0500 Subject: please deactivate services by default! In-Reply-To: <20080925180310.GL1126464@hiwaay.net> References: <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> Message-ID: Chris Adams wrote: > Once upon a time, Bill Nottingham said: >> This has *nothing* to do with upgrades. This is all about the desktop >> livecd only. > > But the livecd "copy to hard drive" option is a quick-and-easy way to > install a system from a single CD, at which point this is NOT just about > the CD version. Is sendmail so huge it doesn't fit on the livecd? I suspect not, this conversation started about boot time after all. So... don't start it for the livecd, *do* start it when the livecd is installed to disk. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw) From skvidal at fedoraproject.org Thu Sep 25 20:03:34 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 25 Sep 2008 16:03:34 -0400 Subject: please deactivate services by default! In-Reply-To: <20080925193259.GD2504@jadzia.bu.edu> References: <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <20080925181647.GC21166@nostromo.devel.redhat.com> <20080925182506.GB2504@jadzia.bu.edu> <20080925183427.GB24278@nostromo.devel.redhat.com> <20080925193259.GD2504@jadzia.bu.edu> Message-ID: <1222373014.4144.137.camel@rosebud> On Thu, 2008-09-25 at 15:32 -0400, Matthew Miller wrote: > On Thu, Sep 25, 2008 at 02:34:27PM -0400, Bill Nottingham wrote: > > > On Thu, Sep 25, 2008 at 02:16:47PM -0400, Bill Nottingham wrote: > > > > - If you're just installing a single-user desktop, there's not really > > > > a usage case for a local mail delivery agent > > > So, where does logwatch send its reports? > > Considering my experience with logwatch, hopefully /dev/null. But I suspect > > not everyone shares my opinion. > > Heh. Yeah, okay, fair point -- but currently it's the best we've got (given > that epylog seems stalled)... > I haven't heard from Konstantin about epylog in a good long while now. You should email him and see if he needs someone to take it over. https://fedorahosted.org/epylog/ -sv From debarshi.ray at gmail.com Thu Sep 25 20:05:01 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Fri, 26 Sep 2008 01:35:01 +0530 Subject: Fedora rawhide rebuild in mock status 2008-09-23 i386 In-Reply-To: <20080924122147.GA4137@mock.linuxdev.us.dell.com> References: <20080924122147.GA4137@mock.linuxdev.us.dell.com> Message-ID: <3170f42f0809251305y11d6c4bcx78771ce3783a6427@mail.gmail.com> > astyle-1.21-6.fc8 (build/make) rishi,mtasaka Fixed. This had a pending GCC 4.3 failure and was just orphaned. > tla-1.3.5-5.fc9 (build/make) rishi Seems like %{__cc} changed from 'gcc' to 'gcc -std=gnu99' from Fedora 9 onwards. Should be fixed soon. Cheerio, Debarshi From lesmikesell at gmail.com Thu Sep 25 20:06:23 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 25 Sep 2008 15:06:23 -0500 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <1222299566.1895.0.camel@luminos.localdomain> <48DBE1A2.1090401@gmail.com> Message-ID: <48DBEF3F.5070702@gmail.com> Colin Walters wrote: > On Thu, Sep 25, 2008 at 3:08 PM, Les Mikesell wrote: >> If I'm looking at the right docs, ssmtp doesn't do the two simple things >> that need to be done: aliasing, so you can get the system mail delivered to >> the right person, and local delivery. > > I guess there is a hard dependency between "cron with custom user > cronjobs" and sendmail. I don't want to break that, and it's probably > too late in the cycle for this change anyways. It does suck to have > everyone take this startup time hit if they're not using custom jobs, > but it's been slow for years, so we can take another cycle of slow. > > For the next cycle, one possible solution to this is to have cron > itself start sendmail if there are custom jobs. The system jobs > should on failure be treated as OS component crashes and be handled > through the same mechanism as > http://fedoraproject.org/wiki/Features/CrashHandling Is is strictly necessary for sendmail to start in its ordered position? Why not peel out the daemons that don't have particular dependencies and background their startup so they continue to happen as you log in? There's not really a good way to intervene if there are problems anyway, so why wait? -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Thu Sep 25 20:10:54 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 25 Sep 2008 15:10:54 -0500 Subject: please deactivate services by default! In-Reply-To: <20080925193919.GE2504@jadzia.bu.edu> References: <1222287197.3941.7.camel@choeger6> <48DAC0A9.9040907@gmail.com> <20080924224637.GD29032@mokona.greysector.net> <200809251050.58096.billcrawford1970@gmail.com> <20080925193919.GE2504@jadzia.bu.edu> Message-ID: <48DBF04E.3010300@gmail.com> Matthew Miller wrote: > On Thu, Sep 25, 2008 at 10:50:57AM +0100, Bill Crawford wrote: >> CONDITIONAL EXPRESSIONS >> file1 -nt file2 >> True if file1 is newer (according to modification date) than >> file2, or if file1 exists and file2 does not. > > The problem is: how do you know what file2 is supposed to be? newaliases rebuilds aliases.db from aliases - but it is only necessary if aliases is newer. You could also just define(`confAUTO_REBUILD') in sendmail.mc and let sendmail manage it as needed. -- Les Mikesell lesmikesell at gmail.com From mw_triad at users.sourceforge.net Thu Sep 25 20:11:52 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 25 Sep 2008 15:11:52 -0500 Subject: please deactivate services by default! In-Reply-To: <48DBC60F.5030104@gmail.com> References: <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> Message-ID: Les Mikesell wrote: > Patrice Dumas wrote: >> On Thu, Sep 25, 2008 at 11:24:45AM -0500, Matthew Woehlke wrote: >>> ...I still feel that this is a problem. Scenario: >>> >>> If we're going to disable important system functionality, it's >> >> It is acritical system functionnality for your use case. But for other >> use cases it is something annoying, it fills /var/spool with unneeded >> data, there is a daemon running (only listening on localhost, but >> still). your use case is not superior to the use case of a user not >> wanting to have a smtp daemon in the default case. > > So, before taking away standard functionality that is expected on any > unix-like system, perhaps you could ask the the user in question if he > cares if important system messages are quietly discarded - and if not, > where he would like them to be delivered. Yes. (replying to Patrice) As I've suggested, be damned sure people that might be relying on a local MTA either get one, or cannot possibly miss the notice that we didn't install one by default. So long as upgrades don't silently remove an existing MTA, firstboot, with an appropriate balance of gloom-and-doom and reassurance-if-you're-confused wording would probably suffice for that. Besides; Patrice, your argument is that we should remove functionality that is critical to some users because no one has bothered to fix the /bug/ that by default logwatch sits around filling the spool with large, mostly-redundant messages. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw) From mw_triad at users.sourceforge.net Thu Sep 25 20:15:35 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 25 Sep 2008 15:15:35 -0500 Subject: please deactivate services by default! In-Reply-To: <20080925181647.GC21166@nostromo.devel.redhat.com> References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <20080925181647.GC21166@nostromo.devel.redhat.com> Message-ID: Bill Nottingham wrote: > Sure, but... > > - If you're just installing a single-user desktop, there's not really > a usage case for a local mail delivery agent Let's see, there's logwatch, smartctl, cron, *my nightly backups*... :-) (Oh, and apcupsd for some users.) I mean, it's not like there's not really a use case for syslogd on a single-user desktop either, right? ;-) (I'm actually serious. If you're going to break cron and logwatch, why keep syslogd around? I'd love to see a reasonable argument for keeping one and not the other.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw) From davej at redhat.com Thu Sep 25 20:20:31 2008 From: davej at redhat.com (Dave Jones) Date: Thu, 25 Sep 2008 16:20:31 -0400 Subject: please deactivate services by default! In-Reply-To: <20080925183427.GB24278@nostromo.devel.redhat.com> References: <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <20080925181647.GC21166@nostromo.devel.redhat.com> <20080925182506.GB2504@jadzia.bu.edu> <20080925183427.GB24278@nostromo.devel.redhat.com> Message-ID: <20080925202031.GA23619@redhat.com> On Thu, Sep 25, 2008 at 02:34:27PM -0400, Bill Nottingham wrote: > Matthew Miller (mattdm at mattdm.org) said: > > On Thu, Sep 25, 2008 at 02:16:47PM -0400, Bill Nottingham wrote: > > > - If you're just installing a single-user desktop, there's not really > > > a usage case for a local mail delivery agent > > > > So, where does logwatch send its reports? > > Considering my experience with logwatch, hopefully /dev/null. But I suspect > not everyone shares my opinion. logwatch has been handy a few times for me, where it's sent me mail with some kernel spew that I would otherwise have not even seen. Though we have kerneloopsd these days which catches most of those traces. Dave -- http://www.codemonkey.org.uk From sundaram at fedoraproject.org Thu Sep 25 20:21:57 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 26 Sep 2008 01:51:57 +0530 Subject: please deactivate services by default! In-Reply-To: References: <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> Message-ID: <48DBF2E5.70006@fedoraproject.org> Matthew Woehlke wrote: > Chris Adams wrote: >> Once upon a time, Bill Nottingham said: >>> This has *nothing* to do with upgrades. This is all about the desktop >>> livecd only. >> >> But the livecd "copy to hard drive" option is a quick-and-easy way to >> install a system from a single CD, at which point this is NOT just about >> the CD version. > > Is sendmail so huge it doesn't fit on the livecd? I suspect not, this > conversation started about boot time after all. So... don't start it for > the livecd, *do* start it when the livecd is installed to disk. Live CD is always cramped for space. So everything that doesn't really fit the regular single user desktop use cases (and sometimes even that) would probably be removed from the live cd unless there are package dependencies. Even earlier today, release engineering was fighting to get it down to CD size. Rahul From davej at redhat.com Thu Sep 25 20:24:40 2008 From: davej at redhat.com (Dave Jones) Date: Thu, 25 Sep 2008 16:24:40 -0400 Subject: Should we mount with reltime as default? In-Reply-To: <20080925181704.GO1126464@hiwaay.net> References: <20080925143525.GE1126464@hiwaay.net> <48DBD4B2.3040403@redhat.com> <20080925181704.GO1126464@hiwaay.net> Message-ID: <20080925202440.GB23619@redhat.com> On Thu, Sep 25, 2008 at 01:17:04PM -0500, Chris Adams wrote: > Once upon a time, Eric Sandeen said: > > Michel Salim wrote: > > > Oops, yes. Incidentally, the manpage mispells it as 'realatime' in the > > > norelatime section; time to file a bug. No mention that relatime is > > > the default either -- does this belong in the manpage or in the > > > release notes? > > > > probably release notes, since default relatime is a fedora-special, and > > not upstream. > > I'd think that if Fedora is going to carry a custom patch to set this in > the kernel, Fedora could also carry a custom patch noting it in the > mount(8) man page. FWIW, we don't carry that patch in the kernel any more. Until upstream takes it, it's unlikely to come back. Dave -- http://www.codemonkey.org.uk From jarod at redhat.com Thu Sep 25 20:26:29 2008 From: jarod at redhat.com (Jarod Wilson) Date: Thu, 25 Sep 2008 16:26:29 -0400 Subject: make mail go somewhere by default [was Re: please deactivate services by default!] In-Reply-To: <48DBED58.3040307@gmail.com> References: <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <1222299566.1895.0.camel@luminos.localdomain> <20080925192952.GC2504@jadzia.bu.edu> <48DBED58.3040307@gmail.com> Message-ID: <48DBF3F5.3080806@redhat.com> Les Mikesell wrote: > Matthew Miller wrote: >> On Wed, Sep 24, 2008 at 04:39:26PM -0700, Jesse Keating wrote: >>> Which is why we shouldn't be using local delivery for this stuff. >>> Instead we should ask in firstboot where you'd want the mail delivered >>> to. >> >> Ooh! And do it this way! >> >> https://bugzilla.redhat.com/show_bug.cgi?id=143437 > > That's a good technique, but wouldn't it follow the system style more > closely to put install/firstboot setting snippets somewhere under > /etc/sysconfig with the stock alias file including from there? Hm... I wrote a firstboot patch ages ago (almost 3 years ago?) that let you say "send root mail to this user" when you added a user in firstboot... Its even in bz somewhere, iirc... -- Jarod Wilson jarod at redhat.com From pertusus at free.fr Thu Sep 25 20:26:39 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 25 Sep 2008 22:26:39 +0200 Subject: please deactivate services by default! In-Reply-To: References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> Message-ID: <20080925202639.GA3831@free.fr> On Thu, Sep 25, 2008 at 03:11:52PM -0500, Matthew Woehlke wrote: > > Yes. (replying to Patrice) As I've suggested, be damned sure people that > might be relying on a local MTA either get one, or cannot possibly miss > the notice that we didn't install one by default. So long as upgrades > don't silently remove an existing MTA, firstboot, with an appropriate > balance of gloom-and-doom and reassurance-if-you're-confused wording > would probably suffice for that. > > Besides; Patrice, your argument is that we should remove functionality > that is critical to some users because no one has bothered to fix the > /bug/ that by default logwatch sits around filling the spool with large, > mostly-redundant messages. It is not really my argument. First I think that these issues are power user issues. And then that there is no clear solution for this issue, there are many use cases with different choices. So, if there no integrated solution, like something with firstboot, /etc/sysconfig or whatever the users should not rely on a specific setup and should setup what they prefer and configure it themselves. And they can do that since they are power users. Starting from this point of view it is better to have nothing started nor configured and things only pulled in as dependencies. I don't really care that it worked before, once again it is a very specific use case and I can't see why it should be priviledged. I think that it was always a mistake to start sendmail in the default case, and even to install it (not as a dependency). Well it should not be changed within a release, nor by updates, but I would find it normal to have it broken by clean installs (with release notes, if possible). -- Pat From cmadams at hiwaay.net Thu Sep 25 20:27:45 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 25 Sep 2008 15:27:45 -0500 Subject: Should we mount with reltime as default? In-Reply-To: <20080925202440.GB23619@redhat.com> References: <20080925143525.GE1126464@hiwaay.net> <48DBD4B2.3040403@redhat.com> <20080925181704.GO1126464@hiwaay.net> <20080925202440.GB23619@redhat.com> Message-ID: <20080925202745.GU1126464@hiwaay.net> Once upon a time, Dave Jones said: > FWIW, we don't carry that patch in the kernel any more. > Until upstream takes it, it's unlikely to come back. Ah, okay. I looked at the kernel SRPM from rawhide, and the patch is still in there, but now I see in the spec that it is commented out. That would be something release-note worthy IMHO, since it is a change in behavior. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From pbrobinson at gmail.com Thu Sep 25 20:29:49 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 25 Sep 2008 21:29:49 +0100 Subject: please deactivate services by default! In-Reply-To: <48DBF2E5.70006@fedoraproject.org> References: <20080924212236.GJ1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <48DBF2E5.70006@fedoraproject.org> Message-ID: <5256d0b0809251329g44a69287l585bf57bd6b3130c@mail.gmail.com> >>>> This has *nothing* to do with upgrades. This is all about the desktop >>>> livecd only. >>> >>> But the livecd "copy to hard drive" option is a quick-and-easy way to >>> install a system from a single CD, at which point this is NOT just about >>> the CD version. >> >> Is sendmail so huge it doesn't fit on the livecd? I suspect not, this >> conversation started about boot time after all. So... don't start it for the >> livecd, *do* start it when the livecd is installed to disk. > > Live CD is always cramped for space. So everything that doesn't really fit > the regular single user desktop use cases (and sometimes even that) would > probably be removed from the live cd unless there are package dependencies. > Even earlier today, release engineering was fighting to get it down to CD > size. Dare I ask why numactl is on there then :-) Its not like a person installing a numactl system wouldn't know how to install a package and its fairly distant from your mainstream. Peter From mw_triad at users.sourceforge.net Thu Sep 25 20:33:41 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 25 Sep 2008 15:33:41 -0500 Subject: please deactivate services by default! In-Reply-To: <20080925180936.GM1126464@hiwaay.net> References: <1222287197.3941.7.camel@choeger6> <48DB7D53.6080507@hi.is> <1222346004.3941.24.camel@choeger6> <48DB8AAF.2070203@hi.is> <1222347870.3941.28.camel@choeger6> <48DB9173.8050508@fedoraproject.org> <20080925143635.GF1126464@hiwaay.net> <20080925180936.GM1126464@hiwaay.net> Message-ID: Chris Adams wrote: > Once upon a time, Matthew Woehlke said: (please read my .sig, thanks!) > I always thought it was odd that some things (e.g. telnet) block root > logins but others (e.g. ssh) don't. I can telnet in and then su and the > password is just as much in the clear as it would have been with > straight root-login-telnet. Either all should allow or all should block > (I personally block), except for directly attached consoles (so root can > get in when all else is broken). True, but then, IMO telnet should just be disabled, period :-). > Maybe sshd could be configured as "PermitRootLogin without-password", > which would require someone to configure keys (but not reconfigure sshd) > before root ssh could be used. What's wrong with simply blocking root login unless root has a password? (Or does this allow login with keys *or* a real password, which would be fine?) >>> - block logins to accounts with no password >> This is different from passphrase-less keys, right? If so I'd definitely >> vote for this. It doesn't need to be exclusive with disabling root >> login, though. > > Yes. I'm pretty sure there is a difference between "account with no > password" and "account with empty-string password", and the sshd option > "PermitEmptyPasswords" (which defaults to no) works as you describe. Ok. Eh, so I'm confused, an account with "no" password just cannot be logged into at all, I thought? (Except via methods that wouldn't use password authentication, e.g. key-based authentication as mentioned above, 'su' as root...) I wouldn't expect an ssh setting for that, I'd expect it to simply be denied :-). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw) From pertusus at free.fr Thu Sep 25 20:37:18 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 25 Sep 2008 22:37:18 +0200 Subject: please deactivate services by default! In-Reply-To: References: <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <20080925181647.GC21166@nostromo.devel.redhat.com> Message-ID: <20080925203718.GB3831@free.fr> On Thu, Sep 25, 2008 at 03:15:35PM -0500, Matthew Woehlke wrote: > Bill Nottingham wrote: >> Sure, but... >> >> - If you're just installing a single-user desktop, there's not really >> a usage case for a local mail delivery agent > > Let's see, there's logwatch, smartctl, cron, *my nightly backups*... :-) > (Oh, and apcupsd for some users.) They need /usr/sbin/sendmail, it is up to the user to choose the corresponding package, configure it, and set it up as he wants. > (I'm actually serious. If you're going to break cron and logwatch, why > keep syslogd around? I'd love to see a reasonable argument for keeping > one and not the other.) In any case syslogd is much more important since it is used by many programs. cron is used by less programs, but still it is used by pretty important applications. I really can't see why logwatch should be installed in the default case, however, and even less why it should be activated. I hope it isn't the case... -- Pat From debarshi.ray at gmail.com Thu Sep 25 20:37:42 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Fri, 26 Sep 2008 02:07:42 +0530 Subject: make mail go somewhere by default [was Re: please deactivate services by default!] In-Reply-To: <48DBF3F5.3080806@redhat.com> References: <20080924212236.GJ1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <1222299566.1895.0.camel@luminos.localdomain> <20080925192952.GC2504@jadzia.bu.edu> <48DBED58.3040307@gmail.com> <48DBF3F5.3080806@redhat.com> Message-ID: <3170f42f0809251337r91f85bavf7f581e1540cd80@mail.gmail.com> Just hit upon gnubiff. What do you think of it? Can we get it to notify users who don't use the ttys about mail? I have never used it myself, so I am not sure. ---- http://gnubiff.sourceforge.net/ gnubiff is a mail notification program that checks for mail and displays headers when new mail has arrived. gnubiff features include: * Multiple mailbox support * pop3, apop, imap4, mh, qmail and mailfile support * SSL & certificates support * GNOME support with complete integration to panel * GTK stand-alone support * Support for the system tray * Support for running without GUI or X * Automatic detection of mailbox format * Mail header & content display * IDLE state support for imap4 * FAM support for mh/qmail/mailfile * PNG animation support * Highly configurable * HIG 2.0 compliance * Small memory usage ---- From sgrubb at redhat.com Thu Sep 25 20:38:47 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 25 Sep 2008 16:38:47 -0400 Subject: Do we care about /sbin /bin linked to /usr/lib ? In-Reply-To: <1222367555.16840.155.camel@vespa.frost.loc> References: <200809251328.01886.sgrubb@redhat.com> <1222367555.16840.155.camel@vespa.frost.loc> Message-ID: <200809251638.47794.sgrubb@redhat.com> On Thursday 25 September 2008 14:32:35 Tomas Mraz wrote: > On which Fedora version did you run this, Steve? Good point. It was F-9 for the record. Rawhide shows this: /bin/mail uses something in /usr: /bin/mailx uses something in /usr: /bin/rpm uses something in /usr: /sbin/audispd-zos-remote uses something in /usr: /sbin/audisp-prelude uses something in /usr: /sbin/audisp-remote uses something in /usr: /sbin/auditd uses something in /usr: /sbin/cifs.spnego uses something in /usr: /sbin/dhcp6c uses something in /usr: /sbin/grubby uses something in /usr: /sbin/lspci uses something in /usr: /sbin/nash uses something in /usr: /sbin/netlabelctl uses something in /usr: /sbin/rpcbind uses something in /usr: /sbin/setpci uses something in /usr: /sbin/umount.hal uses something in /usr: /sbin/ypbind uses something in /usr: -Steve From walters at verbum.org Thu Sep 25 20:43:47 2008 From: walters at verbum.org (Colin Walters) Date: Thu, 25 Sep 2008 16:43:47 -0400 Subject: make mail go somewhere by default [was Re: please deactivate services by default!] In-Reply-To: <3170f42f0809251337r91f85bavf7f581e1540cd80@mail.gmail.com> References: <20080924212236.GJ1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <1222299566.1895.0.camel@luminos.localdomain> <20080925192952.GC2504@jadzia.bu.edu> <48DBED58.3040307@gmail.com> <48DBF3F5.3080806@redhat.com> <3170f42f0809251337r91f85bavf7f581e1540cd80@mail.gmail.com> Message-ID: On Thu, Sep 25, 2008 at 4:37 PM, Debarshi Ray wrote: > Just hit upon gnubiff. What do you think of it? Can we get it to > notify users who don't use the ttys about mail? I have never used it > myself, so I am not sure. No, we're not going to install biff by default on the desktop - aside from custom cron jobs there is no reason for the default OS to be generating email. Things like smartctl should be integrated with HAL and generally be handled the same way e.g. the low disk space notification works now. From mw_triad at users.sourceforge.net Thu Sep 25 20:43:49 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 25 Sep 2008 15:43:49 -0500 Subject: please deactivate services by default! In-Reply-To: <48DBF2E5.70006@fedoraproject.org> References: <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <48DBF2E5.70006@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Matthew Woehlke wrote: >> Is sendmail so huge it doesn't fit on the livecd? I suspect not, this >> conversation started about boot time after all. So... don't start it >> for the livecd, *do* start it when the livecd is installed to disk. > > Live CD is always cramped for space. So everything that doesn't really > fit the regular single user desktop use cases (and sometimes even that) > would probably be removed from the live cd unless there are package > dependencies. Even earlier today, release engineering was fighting to > get it down to CD size. Yes, but sendmail is... Ok. 1.9 M is rather larger than I would have expected. (Whee, the actual program is really 800 k? Wow.) I've never had to poke the MTA, it's always Just Worked. Is there something else that would provide local mail in a smaller rpm? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw) From lesmikesell at gmail.com Thu Sep 25 20:46:16 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 25 Sep 2008 15:46:16 -0500 Subject: please deactivate services by default! In-Reply-To: References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <20080925181647.GC21166@nostromo.devel.redhat.com> Message-ID: <48DBF898.1030907@gmail.com> Matthew Woehlke wrote: > Bill Nottingham wrote: >> Sure, but... >> >> - If you're just installing a single-user desktop, there's not really >> a usage case for a local mail delivery agent > > Let's see, there's logwatch, smartctl, cron, *my nightly backups*... :-) > (Oh, and apcupsd for some users.) > > I mean, it's not like there's not really a use case for syslogd on a > single-user desktop either, right? ;-) > > (I'm actually serious. If you're going to break cron and logwatch, why > keep syslogd around? I'd love to see a reasonable argument for keeping > one and not the other.) I'd agree that syslogd and system mail are equally disposable if you know no one cares about reading them, but syslog's output at least gets some automated maintenance from logrotate. Root's mailbox was left stranded when you started discouraging anyone from logging in as root. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Thu Sep 25 20:46:02 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 26 Sep 2008 02:16:02 +0530 Subject: please deactivate services by default! In-Reply-To: <5256d0b0809251329g44a69287l585bf57bd6b3130c@mail.gmail.com> References: <20080924212236.GJ1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <48DBF2E5.70006@fedoraproject.org> <5256d0b0809251329g44a69287l585bf57bd6b3130c@mail.gmail.com> Message-ID: <48DBF88A.6000900@fedoraproject.org> Peter Robinson wrote: >>>>> This has *nothing* to do with upgrades. This is all about the desktop >>>>> livecd only. >>>> But the livecd "copy to hard drive" option is a quick-and-easy way to >>>> install a system from a single CD, at which point this is NOT just about >>>> the CD version. >>> Is sendmail so huge it doesn't fit on the livecd? I suspect not, this >>> conversation started about boot time after all. So... don't start it for the >>> livecd, *do* start it when the livecd is installed to disk. >> Live CD is always cramped for space. So everything that doesn't really fit >> the regular single user desktop use cases (and sometimes even that) would >> probably be removed from the live cd unless there are package dependencies. >> Even earlier today, release engineering was fighting to get it down to CD >> size. > > Dare I ask why numactl is on there then :-) Its not like a person > installing a numactl system wouldn't know how to install a package and > its fairly distant from your mainstream. @core and @base is shared between the regular dvd images and live images and sometimes these niche packages sneak it. I made a bunch of changes in the live base ks file for future builds to save some space. If folks find anything amiss, let me know. Rahul From sundaram at fedoraproject.org Thu Sep 25 20:48:05 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 26 Sep 2008 02:18:05 +0530 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <48DB7D53.6080507@hi.is> <1222346004.3941.24.camel@choeger6> <48DB8AAF.2070203@hi.is> <1222347870.3941.28.camel@choeger6> <48DB9173.8050508@fedoraproject.org> <20080925143635.GF1126464@hiwaay.net> <20080925180936.GM1126464@hiwaay.net> Message-ID: <48DBF905.4050501@fedoraproject.org> Matthew Woehlke wrote: > Ok. Eh, so I'm confused, an account with "no" password just cannot be > logged into at all, I thought? (Except via methods that wouldn't use > password authentication, e.g. key-based authentication as mentioned > above, 'su' as root...) I wouldn't expect an ssh setting for that, I'd > expect it to simply be denied :-). It is not just root. The default user has no password in the live cd either. Rahul From maillist at diffingo.com Thu Sep 25 20:53:30 2008 From: maillist at diffingo.com (Stewart Adam) Date: Thu, 25 Sep 2008 16:53:30 -0400 Subject: please deactivate services by default! In-Reply-To: <1222287197.3941.7.camel@choeger6> References: <1222287197.3941.7.camel@choeger6> Message-ID: <48DBFA4A.90405@diffingo.com> Christoph H?ger wrote: > Hi, > > I have some services found being activated by default that should be > removed for the following reasons: > > 1. sendmail: starts way too slow, is not usefull for any normal desktop > user I know. Making it usefull requires configuration so I assume > wohever uses that service _can_ activate it. > > 2. ip6tables: I do not know of any provider actually working with ipv6. > So I assume the mass of all users do not need it. > > 3. isdn: isdn requires configuration and thus should be set to start > when that config is actually done. > > 4. setroubleshootd: That service also takes long to boot, but its quite > usefull. I wonder if one could make auditd start setroubleshootd when > required - having two daemons working on base of the same informations > seems not very clever. > > So, now go on and punsh me ;) > I made a Feature page [1] for this a while back, but I didn't include ip6tables or setroubleshootd... Some of the services I listed may be needed (please let me know if that's the case, I didn't do much research before writing it) but otherwise I think it would be great if we could cut down on the number of services and start certain ones (ie bluetooth) only when bluetooth hardware is present. I'm not sure if that's plausible though, it would make for one long list of PCI IDs. Stewart [1] https://fedoraproject.org/wiki/Features/MinimalServices From walters at verbum.org Thu Sep 25 20:02:41 2008 From: walters at verbum.org (Colin Walters) Date: Thu, 25 Sep 2008 16:02:41 -0400 Subject: please deactivate services by default! In-Reply-To: <20080925193259.GD2504@jadzia.bu.edu> References: <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <20080925181647.GC21166@nostromo.devel.redhat.com> <20080925182506.GB2504@jadzia.bu.edu> <20080925183427.GB24278@nostromo.devel.redhat.com> <20080925193259.GD2504@jadzia.bu.edu> Message-ID: On Thu, Sep 25, 2008 at 3:32 PM, Matthew Miller wrote: > On Thu, Sep 25, 2008 at 02:34:27PM -0400, Bill Nottingham wrote: >> > On Thu, Sep 25, 2008 at 02:16:47PM -0400, Bill Nottingham wrote: >> > > - If you're just installing a single-user desktop, there's not really >> > > a usage case for a local mail delivery agent >> > So, where does logwatch send its reports? >> Considering my experience with logwatch, hopefully /dev/null. But I suspect >> not everyone shares my opinion. > > Heh. Yeah, okay, fair point -- but currently it's the best we've got (given > that epylog seems stalled)... logwatch is for servers and system administrators; it is not appropriate for the desktop's general target audience. From mw_triad at users.sourceforge.net Thu Sep 25 20:22:22 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 25 Sep 2008 15:22:22 -0500 Subject: please deactivate services by default! In-Reply-To: <1222363259.3941.36.camel@choeger6> References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <1222363259.3941.36.camel@choeger6> Message-ID: Christoph ? wrote: (What is the symbol in your name supposed to be, incidentally? Thunderbird is rendering it as a ? in a diamond.) > So Joe User, what are you doing with that mail? Is it just dropped > in /var/spool...? Then you probably only want a /usr/bin/sendmail binary > that does so. But you do not need an smtp daemon then. If you want that > mail to be routed over your network (or to other networks) you'll > probably configure that after a clean install - and notice that you have > to enable that daemon. The original mail stated "The desktop image no longer installs sendmail by default." It seems to me there is a great deal of confusion in this thread as to what exactly that means. One interpretation is that this means local mail no longer works. This would be a problem. Another is that I merely lost the ability to use my own box as an SMTP first-hop relay for internet-bound mail. This is probably less of a problem, since if I hit 'send' in Thunderbird and get back an error that localhost did not accept the connection, I will probably notice very quickly that I might now need to install a daemon. As long as this doesn't affect important things like cron/logwatch/smartctl/etc that might have no other way of notifying the user that something is wrong, this should be okay. If someone could clear this up, it would help. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw) From mw_triad at users.sourceforge.net Thu Sep 25 21:04:41 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 25 Sep 2008 16:04:41 -0500 Subject: please deactivate services by default! In-Reply-To: <20080925202639.GA3831@free.fr> References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> <20080925202639.GA3831@free.fr> Message-ID: Patrice Dumas wrote: > On Thu, Sep 25, 2008 at 03:11:52PM -0500, Matthew Woehlke wrote: >> Besides; Patrice, your argument is that we should remove functionality >> that is critical to some users because no one has bothered to fix the >> /bug/ that by default logwatch sits around filling the spool with large, >> mostly-redundant messages. > > It is not really my argument. First I think that these issues are > power user issues. Yes, but... > And then that there is no clear solution for this > issue, there are many use cases with different choices. So, if there no > integrated solution, like something with firstboot, /etc/sysconfig or > whatever the users should not rely on a specific setup and should setup > what they prefer and configure it themselves. And they can do that since > they are power users. Starting from this point of view it is better to > have nothing started nor configured and things only pulled in as > dependencies. ...you still need to let them know there is something they need to do, that they never had to do before (which in itself has Irate User potential). And I strongly disagree with changing from 'something that always worked before' to 'nothing, with potentially catastrophic consequences if you don't know that we removed functionality' being a good idea. > I don't really care that it worked before, Obviously, I do :-). You're "removing" a feature I depend on. It would be one thing if you have a way to ensure that I know this has been done so that I can re-enable it. You apparently feel differently. > once again it is a very specific > use case and I can't see why it should be priviledged. ...because so far I haven't heard that you've ensured people depending on this will know they have to do something special, now. And, as I've pointed out, that lack of knowledge can have severe consequences. Because - ok, I told myself I wouldn't, but I'm going to pull out the Big Gun now - if Red Hat did this, and I lost data because of it, I'd be filing a lawsuit. Seriously. You're talking about playing games with people's data, and I don't take that lightly. And I don't understand why we're still having this conversation. Several suggestions (that, to me at least, seem perfectly reasonable) have already been suggested. Something in anaconda or firstboot would be best (ideally, you could configure things like if you want logwatch at all), that would make sure you either get a local mail MTA, or are required to click through the Big Scary Warning about the Dire Consequences if you elect not to run one. Or make cron require an MTA. Or possibly both. I'm willing to blame it on user negligence if they knowingly choose not to have an MTA, or purposefully circumvent cron's normal use thereof. I *don't* consider it acceptable for the default cron setup to be changed from one that (IMO) is effective, to one that silently discards output in a way that the user may not even be aware that there is a problem. Why is that so hard to understand? (And I'll repeat what I said elsewhere. The replies I'm getting from some people seem to indicate that this is a real issue. If I'm really just inventing a scenario that can't happen, /someone bloody please just tell me!/) > I think that it > was always a mistake to start sendmail in the default case, and even to > install it (not as a dependency). (I happen to disagree, but that's me... Unless you're only talking about the daemon(smtp) part, and not the MTA part that handles local mail.) > Well it should not be changed within > a release, nor by updates, but I would find it normal to have it broken > by clean installs (with release notes, if possible). Who reads release notes? :-) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw) From walters at verbum.org Thu Sep 25 21:05:20 2008 From: walters at verbum.org (Colin Walters) Date: Thu, 25 Sep 2008 17:05:20 -0400 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <1222363259.3941.36.camel@choeger6> Message-ID: On Thu, Sep 25, 2008 at 4:22 PM, Matthew Woehlke wrote: > Christoph ? wrote: > > (What is the symbol in your name supposed to be, incidentally? Thunderbird > is rendering it as a ? in a diamond.) > >> So Joe User, what are you doing with that mail? Is it just dropped >> in /var/spool...? Then you probably only want a /usr/bin/sendmail binary >> that does so. But you do not need an smtp daemon then. If you want that >> mail to be routed over your network (or to other networks) you'll >> probably configure that after a clean install - and notice that you have >> to enable that daemon. > > The original mail stated "The desktop image no longer installs sendmail by > default." > > If someone could clear this up, it would help. We've punted on this and will use sendmail for F10. From skvidal at fedoraproject.org Thu Sep 25 21:10:42 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 25 Sep 2008 17:10:42 -0400 Subject: please deactivate services by default! In-Reply-To: References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> <20080925202639.GA3831@free.fr> Message-ID: <1222377042.4144.157.camel@rosebud> On Thu, 2008-09-25 at 16:04 -0500, Matthew Woehlke wrote: > Because - ok, I told myself I wouldn't, but I'm going to pull out the > Big Gun now - if Red Hat did this, and I lost data because of it, I'd be > filing a lawsuit. Seriously. You're talking about playing games with > people's data, and I don't take that lightly. > A couple of things: 1. if you're resorting to threats then the door is OVER THERE. 2. You'll find that the License you accept by using fedora will make such a lawsuit utterly void. Good luck, -sv From choeger at cs.tu-berlin.de Thu Sep 25 21:14:15 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Thu, 25 Sep 2008 23:14:15 +0200 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <1222363259.3941.36.camel@choeger6> Message-ID: <1222377255.4083.5.camel@choeger6> Am Donnerstag, den 25.09.2008, 15:22 -0500 schrieb Matthew Woehlke: > Christoph ? wrote: > > (What is the symbol in your name supposed to be, incidentally? > Thunderbird is rendering it as a ? in a diamond.) You are the one talking about obfuscating sender ;) No, its just an ?, as in H?ger, my name. This mail should be encoded in utf-8 (hope that doesn't break your backup ;) I cannot efford a lawyer), so I assume your decoding doesn't work well. > If someone could clear this up, it would help. I was only talking about the daemon started at bootup what is not usefull IMO. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From jkeating at redhat.com Thu Sep 25 21:14:08 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 25 Sep 2008 14:14:08 -0700 Subject: please deactivate services by default! In-Reply-To: References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> <20080925202639.GA3831@free.fr> Message-ID: <1222377248.4848.4.camel@luminos.localdomain> On Thu, 2008-09-25 at 16:04 -0500, Matthew Woehlke wrote: > Who reads release notes? :-) People that depend on the software for mission critical situations. Competent admins. Upgrading/updating critical systems without reading about the update you're about to apply is just plain stupid, and a fireable offense. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From lesmikesell at gmail.com Thu Sep 25 21:30:31 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Thu, 25 Sep 2008 16:30:31 -0500 Subject: please deactivate services by default! In-Reply-To: <1222377248.4848.4.camel@luminos.localdomain> References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> <20080925202639.GA3831@free.fr> <1222377248.4848.4.camel@luminos.localdomain> Message-ID: <48DC02F7.4080404@gmail.com> Jesse Keating wrote: > On Thu, 2008-09-25 at 16:04 -0500, Matthew Woehlke wrote: >> Who reads release notes? :-) > > People that depend on the software for mission critical situations. > Competent admins. > > Upgrading/updating critical systems without reading about the update > you're about to apply is just plain stupid, and a fireable offense. If it applied, the same would be true for removing expected functionality from an update you expect (well, eventually force by lack of legacy security support) everyone to apply. -- Les Mikesell lesmikesell at gmail.com From pertusus at free.fr Thu Sep 25 21:31:14 2008 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 25 Sep 2008 23:31:14 +0200 Subject: please deactivate services by default! In-Reply-To: References: <1222294938.3941.20.camel@choeger6> <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> <20080925202639.GA3831@free.fr> Message-ID: <20080925213114.GC3831@free.fr> On Thu, Sep 25, 2008 at 04:04:41PM -0500, Matthew Woehlke wrote: > > ...you still need to let them know there is something they need to do, > that they never had to do before (which in itself has Irate User > potential). Those who read those mails are not regular users. They are power users. They should control their setups. > And I strongly disagree with changing from 'something that always worked > before' to 'nothing, with potentially catastrophic consequences if you > don't know that we removed functionality' being a good idea. I disagree on the 'always worked' part. It did something, sure but it didn't 'worked', at least not for most use cases. > Obviously, I do :-). You're "removing" a feature I depend on. It would > be one thing if you have a way to ensure that I know this has been done > so that I can re-enable it. You apparently feel differently. I don't feel differently. It is what releases notes are for. > ...because so far I haven't heard that you've ensured people depending > on this will know they have to do something special, now. And, as I've > pointed out, that lack of knowledge can have severe consequences. Release notes are for those kind of changes. > Because - ok, I told myself I wouldn't, but I'm going to pull out the > Big Gun now - if Red Hat did this, and I lost data because of it, I'd be > filing a lawsuit. Seriously. You're talking about playing games with > people's data, and I don't take that lightly. It is fedora here, not Red Hat. I am in no way affiliated with Red Hat. If you want to have sendmail installed in RHEL this is not the right thread. And I am not playing game with people data, if you really care about root mail being delivered locally you should willingly enable it, and shouldn't rely on the default configuration of some application (on a clean install). > And I don't understand why we're still having this conversation. Several > suggestions (that, to me at least, seem perfectly reasonable) have > already been suggested. Something in anaconda or firstboot would be best > (ideally, you could configure things like if you want logwatch at all), > that would make sure you either get a local mail MTA, or are required to > click through the Big Scary Warning about the Dire Consequences if you > elect not to run one. I agree on this point, having something integrated would be nice. > Or make cron require an MTA. Or possibly both. cron now requires /usr/sbin/sendmail, which is enough in my opinion. > I'm willing to blame it on user negligence if they knowingly choose not > to have an MTA, or purposefully circumvent cron's normal use thereof. I > *don't* consider it acceptable for the default cron setup to be changed > from one that (IMO) is effective, to one that silently discards output > in a way that the user may not even be aware that there is a problem. The user could only be aware if he modified /etc/aliases anyway, so there is no such regression. But this is not the real problem here. The problem is that the distribution settled to a specific default that is not generic and effective only in some cases. I think that no default would be better. > Why is that so hard to understand? I do understand that you want backward compatibility for a feature that you find important. I think there is nothing wrong with that, and indeed, breaking past stuff is bad. However, breaking backward compatibility is also needed when something was done wrong and badly designed and yet made its way in the distro. Having a MTA like sendmail installed in the default case and started as a daemon was wrong. > (I happen to disagree, but that's me... Unless you're only talking about > the daemon(smtp) part, and not the MTA part that handles local mail.) I am mostly talking about the server(smtp) part. But also about local delivery. At least something lighter should be used (maybe a wrapper script around procmail?). But a random app that provides /usr/sbin/sendmail would also be right, even if it doesn't do local delivery. >> Well it should not be changed within a release, nor by updates, but I >> would find it normal to have it broken by clean installs (with release >> notes, if possible). > > Who reads release notes? :-) Those who understand that things need to change sometime to be better designed, even if it is at the expense of their past habits. -- Pat From jkeating at redhat.com Thu Sep 25 21:41:25 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 25 Sep 2008 14:41:25 -0700 Subject: please deactivate services by default! In-Reply-To: <48DC02F7.4080404@gmail.com> References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> <20080925202639.GA3831@free.fr> <1222377248.4848.4.camel@luminos.localdomain> <48DC02F7.4080404@gmail.com> Message-ID: <1222378885.4848.6.camel@luminos.localdomain> On Thu, 2008-09-25 at 16:30 -0500, Les Mikesell wrote: > > If it applied, the same would be true for removing expected > functionality from an update you expect (well, eventually force by lack > of legacy security support) everyone to apply. Except that we're talking about a major version change, in which we have lateral to make sweeping changes such as this, and the purpose of release notes is to outline such fundamental changes that may require admin knowledge before performing the major version upgrade. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dominik at greysector.net Thu Sep 25 21:42:05 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 25 Sep 2008 23:42:05 +0200 Subject: Fedora rawhide rebuild in mock status 2008-09-23 i386 In-Reply-To: <20080924122147.GA4137@mock.linuxdev.us.dell.com> References: <20080924122147.GA4137@mock.linuxdev.us.dell.com> Message-ID: <20080925214204.GC12512@mokona.greysector.net> On Wednesday, 24 September 2008 at 14:21, Matt Domsch wrote: > Fedora Rawhide-in-Mock Build Results for i386 > using the rawhide tree of Tuesday, 2008-10-23. [...] > Of those expected to have worked... > Without a bug filed: 260 > ---------------------------------- [...] > gabedit-2.1.7-1.fc10 (build/make) rathann Fixed (+ updated to 2.1.8 stable). Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From vonbrand at inf.utfsm.cl Thu Sep 25 21:48:12 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Thu, 25 Sep 2008 17:48:12 -0400 Subject: please deactivate services by default! In-Reply-To: <20080925180936.GM1126464@hiwaay.net> References: <1222287197.3941.7.camel@choeger6> <48DB7D53.6080507@hi.is> <1222346004.3941.24.camel@choeger6> <48DB8AAF.2070203@hi.is> <1222347870.3941.28.camel@choeger6> <48DB9173.8050508@fedoraproject.org> <20080925143635.GF1126464@hiwaay.net> <20080925180936.GM1126464@hiwaay.net> Message-ID: <200809252148.m8PLmCHq000491@laptop14.inf.utfsm.cl> Chris Adams wrote: [...] > I always thought it was odd that some things (e.g. telnet) block root > logins but others (e.g. ssh) don't. I can telnet in and then su and the > password is just as much in the clear as it would have been with > straight root-login-telnet. telnet needs to go. I haven't installed the daemon for ages, and for some time before had it disabled. The client comes handy to check out text-based protocols, though. But perhaps netcat is a replacement here... ssh is a different beast, the connection is encrypted. > Either all should allow or all should block > (I personally block), except for directly attached consoles (so root can > get in when all else is broken). > Maybe sshd could be configured as "PermitRootLogin without-password", > which would require someone to configure keys (but not reconfigure sshd) > before root ssh could be used. Not for me, please. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From vonbrand at inf.utfsm.cl Thu Sep 25 21:54:51 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Thu, 25 Sep 2008 17:54:51 -0400 Subject: please deactivate services by default! In-Reply-To: <20080925181647.GC21166@nostromo.devel.redhat.com> References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <20080925181647.GC21166@nostromo.devel.redhat.com> Message-ID: <200809252154.m8PLspuY000558@laptop14.inf.utfsm.cl> Bill Nottingham wrote: > Chris Adams (cmadams at hiwaay.net) said: > > Once upon a time, Bill Nottingham said: > > > This has *nothing* to do with upgrades. This is all about the desktop > > > livecd only. > > > > But the livecd "copy to hard drive" option is a quick-and-easy way to > > install a system from a single CD, at which point this is NOT just about > > the CD version. > > > > The smallest thing you can download from Fedora and install (without > > requiring network access during install) is the livecd, so that is a > > common path to take. You can then customize easily from there (but if > > you don't know no local SMTP server was installed, you aren't liable to > > go looking for it). > > Sure, but... > > - If you're just installing a single-user desktop, there's not really > a usage case for a local mail delivery agent fetchmail for reading mail locally even when the network is slow or nonexistent + being able to queue and route mail out, even if the machine is network-less ATM and hops between networks (home, job, other). > - If you're using it as a base for installing Some Other Thing, you're > already doing customization; this is just one more thing It's just not nice to add unnecessary work for anyone doing this. > - If you're installing a lab of machines you want to forward cron stuff > centrally, you're (hopefully) doing kickstart, not shoving the livecd > in each machine Nodz. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From michel.sylvan at gmail.com Thu Sep 25 21:55:09 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 25 Sep 2008 17:55:09 -0400 Subject: Should we mount with reltime as default? In-Reply-To: <20080925202745.GU1126464@hiwaay.net> References: <20080925143525.GE1126464@hiwaay.net> <48DBD4B2.3040403@redhat.com> <20080925181704.GO1126464@hiwaay.net> <20080925202440.GB23619@redhat.com> <20080925202745.GU1126464@hiwaay.net> Message-ID: On Thu, Sep 25, 2008 at 4:27 PM, Chris Adams wrote: > Once upon a time, Dave Jones said: >> FWIW, we don't carry that patch in the kernel any more. >> Until upstream takes it, it's unlikely to come back. > > Ah, okay. I looked at the kernel SRPM from rawhide, and the patch is > still in there, but now I see in the spec that it is commented out. > > That would be something release-note worthy IMHO, since it is a change > in behavior. > It makes sense to ship as close a kernel as possible to upstream -- in this case, should the 'relatime' be introduced in the userspace somewhere, though? Whichever utility (anaconda? hal?) touches /etc/fstab should add 'relatime' appropriately. Regards , -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From lists at timj.co.uk Thu Sep 25 22:06:18 2008 From: lists at timj.co.uk (Tim Jackson) Date: Thu, 25 Sep 2008 23:06:18 +0100 Subject: speed up boot about 10s In-Reply-To: <1222185494.9042.10.camel@choeger6> References: <1222185494.9042.10.camel@choeger6> Message-ID: <48DC0B5A.9010602@timj.co.uk> Christoph H?ger wrote: > Ive lost rhgb X-output a while ago and don't know why (maybe an update > put out a regression, I do not boot my laptop that often) Not the best-reported bug ever, but maybe: https://bugzilla.redhat.com/show_bug.cgi?id=463107 ? I have that on at least 2 machines too. Tim From mw_triad at users.sourceforge.net Thu Sep 25 22:12:04 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 25 Sep 2008 17:12:04 -0500 Subject: please deactivate services by default! In-Reply-To: <1222377042.4144.157.camel@rosebud> References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> <20080925202639.GA3831@free.fr> <1222377042.4144.157.camel@rosebud> Message-ID: seth vidal wrote: > On Thu, 2008-09-25 at 16:04 -0500, Matthew Woehlke wrote: >> Because - ok, I told myself I wouldn't, but I'm going to pull out the >> Big Gun now - if Red Hat did this, and I lost data because of it, I'd be >> filing a lawsuit. Seriously. You're talking about playing games with >> people's data, and I don't take that lightly. > > A couple of things: > > 1. if you're resorting to threats then the door is OVER THERE. I'm trying not to. I'm trying, rather, to express just astronomically, er, "upset" I would be if Fedora made a decision that knowing caused me serious data loss, through no fault of my own other than ignorance of said decision, where a different decision would not have resulted in said loss. > 2. You'll find that the License you accept by using fedora will make > such a lawsuit utterly void. Right; that's why I mentioned Red Hat (on the assumption that I'm paying support and thus have some expectation of warranty). -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw) From mattdm at mattdm.org Thu Sep 25 22:12:26 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 25 Sep 2008 18:12:26 -0400 Subject: please deactivate services by default! In-Reply-To: References: <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <20080925181647.GC21166@nostromo.devel.redhat.com> <20080925182506.GB2504@jadzia.bu.edu> <20080925183427.GB24278@nostromo.devel.redhat.com> <20080925193259.GD2504@jadzia.bu.edu> Message-ID: <20080925221226.GA27278@jadzia.bu.edu> On Thu, Sep 25, 2008 at 04:02:41PM -0400, Colin Walters wrote: > > Heh. Yeah, okay, fair point -- but currently it's the best we've got > > (given that epylog seems stalled)... > logwatch is for servers and system administrators; it is not > appropriate for the desktop's general target audience. That's only because it sucks. We need some way of properly communicating this sort of status information to users. -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs Computing & Information Technology Harvard School of Engineering & Applied Sciences From mw_triad at users.sourceforge.net Thu Sep 25 22:18:32 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 25 Sep 2008 17:18:32 -0500 Subject: please deactivate services by default! In-Reply-To: <1222377255.4083.5.camel@choeger6> References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <1222363259.3941.36.camel@choeger6> <1222377255.4083.5.camel@choeger6> Message-ID: Christoph ? wrote: > Am Donnerstag, den 25.09.2008, 15:22 -0500 schrieb Matthew Woehlke: >> Christoph ? wrote: >> >> (What is the symbol in your name supposed to be, incidentally? >> Thunderbird is rendering it as a ? in a diamond.) > > You are the one talking about obfuscating sender ;) ...just the e-mail address :-). > No, its just an ?, > as in H?ger, my name. This mail should be encoded in utf-8 (hope that > doesn't break your backup ;) I cannot efford a lawyer), Nah, unless you're a grossly-overpaid CEO, you wouldn't have enough money ;-). > so I assume your decoding doesn't work well. Apparently not :-(. I guess Thunderbird has problems with UTF8 in subjects (or else it's a gmane limitation). Strange. Anyway, thanks for enlightening me. (Oh, and, yes, the body is fine, it's just the message list pane, and when I go to reply.) >> If someone could clear this up, it would help. > > I was only talking about the daemon started at bootup what is not > usefull IMO. If local mail still works (does it?), why are we having this conversation? :-) (Read: why did it take so long to get this cleared up, and how did the original statement that "cron won't work any more" get made in the first place?) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw) From skvidal at fedoraproject.org Thu Sep 25 22:20:21 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Thu, 25 Sep 2008 18:20:21 -0400 Subject: please deactivate services by default! In-Reply-To: References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> <20080925202639.GA3831@free.fr> <1222377042.4144.157.camel@rosebud> Message-ID: <1222381221.4144.164.camel@rosebud> On Thu, 2008-09-25 at 17:12 -0500, Matthew Woehlke wrote: > > 2. You'll find that the License you accept by using fedora will make > > such a lawsuit utterly void. > > Right; that's why I mentioned Red Hat (on the assumption that I'm paying > support and thus have some expectation of warranty). Fedora is not RHEL and it is not relevant on this mailing list. There are RHEL lists. You can take your threats there, if you'd like. -sv From cmadams at hiwaay.net Thu Sep 25 22:25:02 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 25 Sep 2008 17:25:02 -0500 Subject: Should we mount with reltime as default? In-Reply-To: References: <20080925143525.GE1126464@hiwaay.net> <48DBD4B2.3040403@redhat.com> <20080925181704.GO1126464@hiwaay.net> <20080925202440.GB23619@redhat.com> <20080925202745.GU1126464@hiwaay.net> Message-ID: <20080925222502.GA1517148@hiwaay.net> Once upon a time, Michel Salim said: > It makes sense to ship as close a kernel as possible to upstream -- in > this case, should the 'relatime' be introduced in the userspace > somewhere, though? Whichever utility (anaconda? hal?) touches > /etc/fstab should add 'relatime' appropriately. If you want to go that path, it should be added to the options set in the filesystem superblock (ext3 has a field for default mount options) at filesystem creation time. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mw_triad at users.sourceforge.net Thu Sep 25 22:30:52 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 25 Sep 2008 17:30:52 -0500 Subject: please deactivate services by default! In-Reply-To: <20080925221226.GA27278@jadzia.bu.edu> References: <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <20080925181647.GC21166@nostromo.devel.redhat.com> <20080925182506.GB2504@jadzia.bu.edu> <20080925183427.GB24278@nostromo.devel.redhat.com> <20080925193259.GD2504@jadzia.bu.edu> <20080925221226.GA27278@jadzia.bu.edu> Message-ID: Matthew Miller wrote: > On Thu, Sep 25, 2008 at 04:02:41PM -0400, Colin Walters wrote: >>> Heh. Yeah, okay, fair point -- but currently it's the best we've got >>> (given that epylog seems stalled)... >> logwatch is for servers and system administrators; it is not >> appropriate for the desktop's general target audience. > > That's only because it sucks. We need some way of properly communicating > this sort of status information to users. +1 :-). I too would appreciate a condensed flavor of logwatch (delivered somewhere more sensible). One that can combine all "unread" events (with the option to drill down if desired) would be best. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw) From cmadams at hiwaay.net Thu Sep 25 22:33:12 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 25 Sep 2008 17:33:12 -0500 Subject: please deactivate services by default! In-Reply-To: References: <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <1222299566.1895.0.camel@luminos.localdomain> <48DBE1A2.1090401@gmail.com> Message-ID: <20080925223311.GC1517148@hiwaay.net> Once upon a time, Colin Walters said: > I guess there is a hard dependency between "cron with custom user > cronjobs" and sendmail. I don't want to break that, and it's probably > too late in the cycle for this change anyways. It does suck to have > everyone take this startup time hit if they're not using custom jobs, > but it's been slow for years, so we can take another cycle of slow. I think a part of the startup hit is from rebuilding aliases unconditionally. That should be considered a bug and removed from the sendmail init script (or at least changed to check if aliases is newer than aliases.db before calling). There's a reason sendmail removed auto-rebuilding aliases from the daemon itself. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mw_triad at users.sourceforge.net Thu Sep 25 22:39:55 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 25 Sep 2008 17:39:55 -0500 Subject: please deactivate services by default! In-Reply-To: <200809252148.m8PLmCHq000491@laptop14.inf.utfsm.cl> References: <1222287197.3941.7.camel@choeger6> <48DB7D53.6080507@hi.is> <1222346004.3941.24.camel@choeger6> <48DB8AAF.2070203@hi.is> <1222347870.3941.28.camel@choeger6> <48DB9173.8050508@fedoraproject.org> <20080925143635.GF1126464@hiwaay.net> <20080925180936.GM1126464@hiwaay.net> <200809252148.m8PLmCHq000491@laptop14.inf.utfsm.cl> Message-ID: Horst H. von Brand wrote: > Chris Adams wrote: >> I always thought it was odd that some things (e.g. telnet) block root >> logins but others (e.g. ssh) don't. I can telnet in and then su and the >> password is just as much in the clear as it would have been with >> straight root-login-telnet. > > telnet needs to go. I haven't installed the daemon for ages, and for some > time before had it disabled. The client comes handy to check out text-based > protocols, though. But perhaps netcat is a replacement here... Hard to say; I occasionally use telnet to talk to HTTP servers, and it can be used for some MUD's I think (though better clients often exist). At work, I need it to deal with some machines that don't have ssh :-(. I'm fine not installing it by default, but would prefer to see the package stick around. I'd also be a bit hesitant about killing off telnetd entirely (i.e. totally removing the package; less so than removing the client, though), but I strongly agree with Horst that it shouldn't be /installed/ (and absolutely, not set up to accept connections!!) by default. Maybe we should just deprecate telnetd and see who complains? ;-) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw) From cmadams at hiwaay.net Thu Sep 25 22:43:29 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 25 Sep 2008 17:43:29 -0500 Subject: please deactivate services by default! In-Reply-To: References: <48DB7D53.6080507@hi.is> <1222346004.3941.24.camel@choeger6> <48DB8AAF.2070203@hi.is> <1222347870.3941.28.camel@choeger6> <48DB9173.8050508@fedoraproject.org> <20080925143635.GF1126464@hiwaay.net> <20080925180936.GM1126464@hiwaay.net> <200809252148.m8PLmCHq000491@laptop14.inf.utfsm.cl> Message-ID: <20080925224328.GD1517148@hiwaay.net> Once upon a time, Matthew Woehlke said: > I'd also be a bit hesitant about killing off telnetd entirely (i.e. > totally removing the package; less so than removing the client, though), > but I strongly agree with Horst that it shouldn't be /installed/ (and > absolutely, not set up to accept connections!!) by default. Well, you are in luck, since telnet-server hasn't been installed by default for years (sometime around RHL 8.0 IIRC). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From carl at five-ten-sg.com Thu Sep 25 22:43:34 2008 From: carl at five-ten-sg.com (Carl Byington) Date: Thu, 25 Sep 2008 15:43:34 -0700 Subject: please deactivate services by default! In-Reply-To: <48DB851F.7060804@gmail.com> References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> <1222290934.5774.35.camel@dimi.lattica.com> <48DB851F.7060804@gmail.com> Message-ID: <1222382614.12997.91.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 2008-09-25 at 07:33 -0500, Les Mikesell wrote: > Perhaps there should be a diagnostic for that added somewhere to make > it > more obvious. That would be nice. > By the way, what is supposed to happen when you use > private addressing but don't provide your own dns for it? Does it > annoy the root servers to get all those reverse lookup queries for > ranges that don't have public servers? Yes, it does annoy them. See for some gory details. Bind 9.5.1 includes (will include?) support for automatic empty zones to cover those queries. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFI3BQLL6j7milTFsERAhZFAJ0fn/Xu8ZFOHg36vRcvubB1ObjlnQCeMwTx 9YAixIxIkIsD9cHhjja4D4w= =Ly8H -----END PGP SIGNATURE----- From mw_triad at users.sourceforge.net Thu Sep 25 22:44:43 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 25 Sep 2008 17:44:43 -0500 Subject: please deactivate services by default! In-Reply-To: <1222381221.4144.164.camel@rosebud> References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> <20080925202639.GA3831@free.fr> <1222377042.4144.157.camel@rosebud> <1222381221.4144.164.camel@rosebud> Message-ID: seth vidal wrote: > Fedora is not RHEL and it is not relevant on this mailing list. I never said it was. > There are RHEL lists. You can take your threats there, if you'd like. What part of "I was using an analogy to express an opinion, not making a threat" did you not understand? I could have used any Big Corporation instead of Red Hat. Maybe I should have... -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw) From michel.sylvan at gmail.com Thu Sep 25 22:52:55 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 25 Sep 2008 18:52:55 -0400 Subject: Should we mount with reltime as default? In-Reply-To: <20080925222502.GA1517148@hiwaay.net> References: <20080925143525.GE1126464@hiwaay.net> <48DBD4B2.3040403@redhat.com> <20080925181704.GO1126464@hiwaay.net> <20080925202440.GB23619@redhat.com> <20080925202745.GU1126464@hiwaay.net> <20080925222502.GA1517148@hiwaay.net> Message-ID: On Thu, Sep 25, 2008 at 6:25 PM, Chris Adams wrote: > Once upon a time, Michel Salim said: >> It makes sense to ship as close a kernel as possible to upstream -- in >> this case, should the 'relatime' be introduced in the userspace >> somewhere, though? Whichever utility (anaconda? hal?) touches >> /etc/fstab should add 'relatime' appropriately. > > If you want to go that path, it should be added to the options set in > the filesystem superblock (ext3 has a field for default mount options) > at filesystem creation time. That would exclude removable media, though? Regards, -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From carl at five-ten-sg.com Thu Sep 25 23:00:36 2008 From: carl at five-ten-sg.com (Carl Byington) Date: Thu, 25 Sep 2008 16:00:36 -0700 Subject: please deactivate services by default! In-Reply-To: <1222367236.16840.153.camel@vespa.frost.loc> References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925173858.GA21166@nostromo.devel.redhat.com> <1222367236.16840.153.camel@vespa.frost.loc> Message-ID: <1222383636.12997.96.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 2008-09-25 at 20:27 +0200, Tomas Mraz wrote: > > Note that neither Evolution nor Thunderbird monitor the local > spools > > by default, so even stuffing an alias in /etc/aliases wouldn't > really > > help the cron case. > I wonder whether it would be possible to make them somehow to do so? For Evolution, when you setup a mail account, you need to specify the mail source (imap, pop3, local delivery, or mbox spool). I have not used them, but presumably one of those last two is what you want in order to read /var/spool/mail/root. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFI3Bf+L6j7milTFsERAoPuAJ9LoVQvNjw3xEEEJaC7FaH5Hxp/JQCfXzMg Zw01BIsT6DWGuM/C9MBkRLk= =rO5s -----END PGP SIGNATURE----- From alan at redhat.com Thu Sep 25 23:05:29 2008 From: alan at redhat.com (Alan Cox) Date: Thu, 25 Sep 2008 19:05:29 -0400 Subject: please deactivate services by default! In-Reply-To: <20080925183249.GA24278@nostromo.devel.redhat.com> References: <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925173858.GA21166@nostromo.devel.redhat.com> <1222367236.16840.153.camel@vespa.frost.loc> <20080925183249.GA24278@nostromo.devel.redhat.com> Message-ID: <20080925230529.GC29433@shell.devel.redhat.com> On Thu, Sep 25, 2008 at 02:32:49PM -0400, Bill Nottingham wrote: > - The mail smarthost is a system setting that any configured MTA uses, > and any configured MUA automatically picks up (overridable) > - The default aliases read the users' e-mail configuration, sending it > to their local account, gmail, yahoo, ISP mail, whatever Log files tend to contain stuff like passwords typed in the wrong box so we shouldn't casually point mail off box. Also a lot of mail from cron, logging etc will be mail to explain your internet connection is down or your email couldn't be forwarded .. From jkeating at redhat.com Thu Sep 25 23:05:50 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 25 Sep 2008 16:05:50 -0700 Subject: please deactivate services by default! In-Reply-To: <1222383636.12997.96.camel@ns.five-ten-sg.com> References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925173858.GA21166@nostromo.devel.redhat.com> <1222367236.16840.153.camel@vespa.frost.loc> <1222383636.12997.96.camel@ns.five-ten-sg.com> Message-ID: <1222383950.4848.7.camel@luminos.localdomain> On Thu, 2008-09-25 at 16:00 -0700, Carl Byington wrote: > I have not > used them, but presumably one of those last two is what you want in > order to read /var/spool/mail/root. Except that you can't unless you're running evolution as root. And if you are, well hope no important data is on your system. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From alan at redhat.com Thu Sep 25 23:09:39 2008 From: alan at redhat.com (Alan Cox) Date: Thu, 25 Sep 2008 19:09:39 -0400 Subject: please deactivate services by default! In-Reply-To: <48DBEF3F.5070702@gmail.com> References: <20080924230129.GB29113@free.fr> <1222299566.1895.0.camel@luminos.localdomain> <48DBE1A2.1090401@gmail.com> <48DBEF3F.5070702@gmail.com> Message-ID: <20080925230939.GD29433@shell.devel.redhat.com> On Thu, Sep 25, 2008 at 03:06:23PM -0500, Les Mikesell wrote: > Is is strictly necessary for sendmail to start in its ordered position? No. > Why not peel out the daemons that don't have particular dependencies > and background their startup so they continue to happen as you log in? > There's not really a good way to intervene if there are problems > anyway, so why wait? You can start sendmail late and asynchronously. I've done that for years on Fedora boxes and its a standard mod I make every time to sendmail or exim scripts. Tools that use /usr/bin/sendmail will work fine as they don't need the daemon running yet. Tools that use port 25 SMTP already have to handle failed connections and work just fine too. Simply stuffing an "&" on the end of the sendmail stuff in the boot scripts is sufficient to solve all the sendmail delay problems From alan at redhat.com Thu Sep 25 23:10:42 2008 From: alan at redhat.com (Alan Cox) Date: Thu, 25 Sep 2008 19:10:42 -0400 Subject: please deactivate services by default! In-Reply-To: <20080925202031.GA23619@redhat.com> References: <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <20080925181647.GC21166@nostromo.devel.redhat.com> <20080925182506.GB2504@jadzia.bu.edu> <20080925183427.GB24278@nostromo.devel.redhat.com> <20080925202031.GA23619@redhat.com> Message-ID: <20080925231042.GE29433@shell.devel.redhat.com> On Thu, Sep 25, 2008 at 04:20:31PM -0400, Dave Jones wrote: > logwatch has been handy a few times for me, where it's sent me mail > with some kernel spew that I would otherwise have not even seen. > > Though we have kerneloopsd these days which catches most of those traces. I find logwatch invaluable but if we are serious about desktop ease of use we should keep it and make it post the data somewhere a desktop click can show and browse the results not just via email. Alan From dr.diesel at gmail.com Thu Sep 25 23:10:26 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Thu, 25 Sep 2008 19:10:26 -0400 Subject: Yum NFS mounted/shared cache directories? Message-ID: <2a28d2ab0809251610u3c07e2b1k5a6ebe12f6ee88be@mail.gmail.com> Perhaps not a bug or maybe requires a feature request. I'm attempting to host my /var/cache/yum directory on a NFS to share with several other machines. I've tired doing with by simply changing the location in yum.conf and also by creating a symbolic link to the directory with no succes, yum just stops here with no error: [root at localhost ~]# yum -y update Loaded plugins: fastestmirror, refresh-packagekit Determining fastest mirrors * livna: rpm.livna.org * fedora: mirror.anl.gov * updates-newkey: mirror.steadfast.net * updates-newkey-source: mirror.steadfast.net * updates: mirror.steadfast.net livna | 2.1 kB 00:00 fedora | 2.4 kB 00:00 updates-newkey | 2.3 kB 00:00 updates-newkey-source | 2.1 kB 00:00 updates It will sit here pretty much forever without output, at least for the ~15 I waited, but did create the following directory structure: [root at localhost ~]# ls -R /main/uploads/yum /main/uploads/yum: fedora livna timedhosts.txt updates updates-newkey updates-newkey-source /main/uploads/yum/fedora: cachecookie mirrorlist.txt packages primary.sqlite repomd.xml /main/uploads/yum/fedora/packages: /main/uploads/yum/livna: cachecookie packages primary.sqlite repomd.xml /main/uploads/yum/livna/packages: /main/uploads/yum/updates: cachecookie mirrorlist.txt packages primary.sqlite repomd.xml /main/uploads/yum/updates/packages: /main/uploads/yum/updates-newkey: cachecookie mirrorlist.txt packages primary.sqlite repomd.xml /main/uploads/yum/updates-newkey/packages: /main/uploads/yum/updates-newkey-source: cachecookie mirrorlist.txt packages primary.sqlite repomd.xml /main/uploads/yum/updates-newkey-source/packages: [root at localhost ~]# Is this intentional or possibility a bug? I realize creating a yum repo is fairly easy but I was hoping to only cache the packages that my machines use, not the entire repo. Any help or suggestions? Thanks Andy -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mw_triad at users.sourceforge.net Thu Sep 25 23:10:39 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 25 Sep 2008 18:10:39 -0500 Subject: please deactivate services by default! In-Reply-To: <20080925213114.GC3831@free.fr> References: <1222294938.3941.20.camel@choeger6> <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> <20080925202639.GA3831@free.fr> <20080925213114.GC3831@free.fr> Message-ID: (After Christoph's contribution, I feel like this is too long of a reply. Sorry :-). I'm still trying to understand what the future plans are, hence some of the longer paragraphs...) Patrice Dumas wrote: > On Thu, Sep 25, 2008 at 04:04:41PM -0500, Matthew Woehlke wrote: >> ...you still need to let them know there is something they need to do, >> that they never had to do before (which in itself has Irate User >> potential). > > Those who read those mails are not regular users. They are power users. > They should control their setups. The default configuration works fine for me. > It is fedora here, not Red Hat. I am in no way affiliated with Red Hat. (See my reply to Seth Vidal.) > And I am not playing game with people data, If local mail suddenly went to /dev/null, and I didn't realize that, you /would/ be playing with my data. > if you really care > about root mail being delivered locally you should willingly enable it, > and shouldn't rely on the default configuration of some application > (on a clean install). Why do people keep assuming I am talking about root's mail. Where did I say that? (Even if I was, maybe I regularly become root just to check root's mail...) >> Or make cron require an MTA. Or possibly both. > > cron now requires /usr/sbin/sendmail, which is enough in my opinion. Well then... say so :-). Yesterday would have been a nice time :-). > The problem is that the distribution settled to a specific default > that is not generic and effective only in some cases. I think that no > default would be better. Well, I feel it's a regression for people relying on the previous default; especially if they don't realize anything has changed. Point of clarification: would installing cron restore the old behavior? (That is, working local mail delivery...) If so, well, it will be hard to set up cron-based backups when cron isn't installed, so effectively 'yum install cronie' will get things working the way they always did. > I do understand that you want backward compatibility for a feature that > you find important. I think there is nothing wrong with that, and > indeed, breaking past stuff is bad. However, breaking backward > compatibility is also needed when something was done wrong and badly > designed and yet made its way in the distro. Having a MTA like sendmail > installed in the default case and started as a daemon was wrong. Well, obviously I disagree that there is anything wrong with the current local mail behavior for non-root. Anyway... the point is that I don't consider it acceptable to break backward compatibility in a way that may a: go unnoticed, and b: have disastrous consequences. Making cron require a reliable* MTA avoids the disastrous consequences. An anaconda/firstboot screen would fix the "unnoticed" bit. Either is acceptable (both would be preferred, of course). The whole point has been, don't break things until the mechanism to handle the fallout is in place. Sounds like we've decided to do that. Now... was that so hard? :-) (* where "reliable" means that cron's mail will wind up either in the local spool like always, or will safely arrive somewhere that a user used to local mail will notice it, with a failure rate at or below what we have now) >> (I happen to disagree, but that's me... Unless you're only talking about >> the daemon(smtp) part, and not the MTA part that handles local mail.) > > I am mostly talking about the server(smtp) part. But also about local > delivery. At least something lighter should be used (maybe a wrapper > script around procmail?). Hehe, given the 1.9 M girth of sendmail, I can agree with that :-), but... > But a random app that provides > /usr/sbin/sendmail would also be right, even if it doesn't do local > delivery. ...not this, unless said MTA is reasonably assured to deliver cron's mail, as per my definition (above) of "reliable". -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw) From jkeating at redhat.com Thu Sep 25 23:12:07 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 25 Sep 2008 16:12:07 -0700 Subject: please deactivate services by default! In-Reply-To: <20080925230529.GC29433@shell.devel.redhat.com> References: <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925173858.GA21166@nostromo.devel.redhat.com> <1222367236.16840.153.camel@vespa.frost.loc> <20080925183249.GA24278@nostromo.devel.redhat.com> <20080925230529.GC29433@shell.devel.redhat.com> Message-ID: <1222384327.4848.9.camel@luminos.localdomain> On Thu, 2008-09-25 at 19:05 -0400, Alan Cox wrote: > Log files tend to contain stuff like passwords typed in the wrong box so > we shouldn't casually point mail off box. Also a lot of mail from cron, > logging etc will be mail to explain your internet connection is down or your > email couldn't be forwarded .. Which does no good if we don't actually lead people to read this mail, one way or another. Right now we just hope that they figure out some how to start collecting root's mail before it fills up filesystem. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Thu Sep 25 23:12:47 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 26 Sep 2008 01:12:47 +0200 Subject: please deactivate services by default! In-Reply-To: <200809252154.m8PLspuY000558@laptop14.inf.utfsm.cl> References: <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <20080925181647.GC21166@nostromo.devel.redhat.com> <200809252154.m8PLspuY000558@laptop14.inf.utfsm.cl> Message-ID: <20080925231247.GD3831@free.fr> On Thu, Sep 25, 2008 at 05:54:51PM -0400, Horst H. von Brand wrote: > > > > fetchmail for reading mail locally even when the network is slow or > nonexistent + being able to queue and route mail out, even if the machine > is network-less ATM and hops between networks (home, job, other). Fetchmail just needs a MDA to deliver mail locally, nowadays (and it should depend on procmail instead of smtp(server) in F10). -- Pat From alan at redhat.com Thu Sep 25 23:13:05 2008 From: alan at redhat.com (Alan Cox) Date: Thu, 25 Sep 2008 19:13:05 -0400 Subject: please deactivate services by default! In-Reply-To: <1222377042.4144.157.camel@rosebud> References: <1222294938.3941.20.camel@choeger6> <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> <20080925202639.GA3831@free.fr> <1222377042.4144.157.camel@rosebud> Message-ID: <20080925231305.GF29433@shell.devel.redhat.com> On Thu, Sep 25, 2008 at 05:10:42PM -0400, seth vidal wrote: > 1. if you're resorting to threats then the door is OVER THERE. Agreed, but please use the upstairs window ;) > 2. You'll find that the License you accept by using fedora will make > such a lawsuit utterly void. In the USA, maybe ... From alan at redhat.com Thu Sep 25 23:14:38 2008 From: alan at redhat.com (Alan Cox) Date: Thu, 25 Sep 2008 19:14:38 -0400 Subject: please deactivate services by default! In-Reply-To: <200809252148.m8PLmCHq000491@laptop14.inf.utfsm.cl> References: <1222287197.3941.7.camel@choeger6> <48DB7D53.6080507@hi.is> <1222346004.3941.24.camel@choeger6> <48DB8AAF.2070203@hi.is> <1222347870.3941.28.camel@choeger6> <48DB9173.8050508@fedoraproject.org> <20080925143635.GF1126464@hiwaay.net> <20080925180936.GM1126464@hiwaay.net> <200809252148.m8PLmCHq000491@laptop14.inf.utfsm.cl> Message-ID: <20080925231438.GG29433@shell.devel.redhat.com> On Thu, Sep 25, 2008 at 05:48:12PM -0400, Horst H. von Brand wrote: > telnet needs to go. I haven't installed the daemon for ages, and for some > time before had it disabled. The client comes handy to check out text-based > protocols, though. But perhaps netcat is a replacement here... There are still a lot of appliances and other junk that only speak telnet including some of the crappier home internet DSL boxes. Fortunately telnet is tiny From alan at redhat.com Thu Sep 25 23:15:36 2008 From: alan at redhat.com (Alan Cox) Date: Thu, 25 Sep 2008 19:15:36 -0400 Subject: please deactivate services by default! In-Reply-To: References: <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <20080925181647.GC21166@nostromo.devel.redhat.com> <20080925182506.GB2504@jadzia.bu.edu> <20080925183427.GB24278@nostromo.devel.redhat.com> <20080925193259.GD2504@jadzia.bu.edu> <20080925221226.GA27278@jadzia.bu.edu> Message-ID: <20080925231536.GH29433@shell.devel.redhat.com> On Thu, Sep 25, 2008 at 05:30:52PM -0500, Matthew Woehlke wrote: > +1 :-). I too would appreciate a condensed flavor of logwatch (delivered > somewhere more sensible). One that can combine all "unread" events (with > the option to drill down if desired) would be best. Firefox browser as one of the default RSS feeds ? Alan From mw_triad at users.sourceforge.net Thu Sep 25 23:28:38 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 25 Sep 2008 18:28:38 -0500 Subject: please deactivate services by default! In-Reply-To: <20080925231536.GH29433@shell.devel.redhat.com> References: <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <20080925181647.GC21166@nostromo.devel.redhat.com> <20080925182506.GB2504@jadzia.bu.edu> <20080925183427.GB24278@nostromo.devel.redhat.com> <20080925193259.GD2504@jadzia.bu.edu> <20080925221226.GA27278@jadzia.bu.edu> <20080925231536.GH29433@shell.devel.redhat.com> Message-ID: Alan Cox wrote: > On Thu, Sep 25, 2008 at 05:30:52PM -0500, Matthew Woehlke wrote: >> +1 :-). I too would appreciate a condensed flavor of logwatch (delivered >> somewhere more sensible). One that can combine all "unread" events (with >> the option to drill down if desired) would be best. > > Firefox browser as one of the default RSS feeds ? What about people using konq? ;-) Hmm... rss feeds, sounds like an interesting idea. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw) From carl at five-ten-sg.com Thu Sep 25 23:29:12 2008 From: carl at five-ten-sg.com (Carl Byington) Date: Thu, 25 Sep 2008 16:29:12 -0700 Subject: please deactivate services by default! In-Reply-To: <1222383950.4848.7.camel@luminos.localdomain> References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925173858.GA21166@nostromo.devel.redhat.com> <1222367236.16840.153.camel@vespa.frost.loc> <1222383636.12997.96.camel@ns.five-ten-sg.com> <1222383950.4848.7.camel@luminos.localdomain> Message-ID: <1222385352.12997.100.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 2008-09-25 at 16:05 -0700, Jesse Keating wrote: > On Thu, 2008-09-25 at 16:00 -0700, Carl Byington wrote: > > I have not > > used them, but presumably one of those last two is what you want in > > order to read /var/spool/mail/root. > Except that you can't unless you're running evolution as root. And > if > you are, well hope no important data is on your system. Yes, but I assumed that /etc/mail/aliases: root: someuser And that as someuser, you would then configure an Evolution account to read /var/spool/mail/someuser. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFI3B6nL6j7milTFsERAmvJAJ9Sq6/pwo/XcCKyfNnlerYPTqfHuwCfSvMV ZG3R+CK10UAbFWF2QFC0PfU= =WpF1 -----END PGP SIGNATURE----- From fedora at shmuelhome.mine.nu Thu Sep 25 23:34:52 2008 From: fedora at shmuelhome.mine.nu (shmuel siegel) Date: Fri, 26 Sep 2008 02:34:52 +0300 Subject: please deactivate services by default! In-Reply-To: <20080925202639.GA3831@free.fr> References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> <20080925202639.GA3831@free.fr> Message-ID: <48DC201C.9040905@shmuelhome.mine.nu> Patrice Dumas wrote: > Well it should not be changed within > a release, nor by updates, but I would find it normal to have it broken > by clean installs (with release notes, if possible). > > -- > Pat > > This particular problem doesn't concern me since my work does not depend on sendmail. But I think that a logical error is being made here. For repeat users, I don't see a real difference between updates and clean installs. I, for one, am very willing to install a new release since it will clean out accumulated junk. The only thing that I will keep from the old release is /home. I don't think that I would find it acceptable that previously assumed features just stopped working. Breaking cron or side effects of cron is unacceptable. From jkeating at redhat.com Thu Sep 25 23:39:48 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 25 Sep 2008 16:39:48 -0700 Subject: please deactivate services by default! In-Reply-To: <1222385352.12997.100.camel@ns.five-ten-sg.com> References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925173858.GA21166@nostromo.devel.redhat.com> <1222367236.16840.153.camel@vespa.frost.loc> <1222383636.12997.96.camel@ns.five-ten-sg.com> <1222383950.4848.7.camel@luminos.localdomain> <1222385352.12997.100.camel@ns.five-ten-sg.com> Message-ID: <1222385988.4848.12.camel@luminos.localdomain> On Thu, 2008-09-25 at 16:29 -0700, Carl Byington wrote: > Yes, but I assumed that /etc/mail/aliases: > root: someuser > > And that as someuser, you would then configure an Evolution account to > read /var/spool/mail/someuser. Why would you assume that though? What currently in Fedora sets this up for a user after a fresh install? What currently in Fedora recommends that a user do that themselves? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From walters at verbum.org Thu Sep 25 23:40:04 2008 From: walters at verbum.org (Colin Walters) Date: Thu, 25 Sep 2008 19:40:04 -0400 Subject: please deactivate services by default! In-Reply-To: <48DC201C.9040905@shmuelhome.mine.nu> References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> <20080925202639.GA3831@free.fr> <48DC201C.9040905@shmuelhome.mine.nu> Message-ID: O > This particular problem doesn't concern me since my work does not depend on > sendmail. But I think that a logical error is being made here. For repeat > users, I don't see a real difference between updates and clean installs. I, > for one, am very willing to install a new release since it will clean out > accumulated junk. The only thing that I will keep from the old release is > /home. I don't think that I would find it acceptable that previously assumed > features just stopped working. Breaking cron or side effects of cron is > unacceptable. If you only keep /home, you'll lose your crontab (since they're in /var/spool/cron, not /home). In the longer term I would like to see cron-like functionality provided by and integrated with GNOME, which would fix not only this but also cleanly allow your cron jobs to access cached authentication credentials in gnome-keyring, let you pop up notification messages, etc. From carl at five-ten-sg.com Thu Sep 25 23:45:35 2008 From: carl at five-ten-sg.com (Carl Byington) Date: Thu, 25 Sep 2008 16:45:35 -0700 Subject: please deactivate services by default! In-Reply-To: <1222385988.4848.12.camel@luminos.localdomain> References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925173858.GA21166@nostromo.devel.redhat.com> <1222367236.16840.153.camel@vespa.frost.loc> <1222383636.12997.96.camel@ns.five-ten-sg.com> <1222383950.4848.7.camel@luminos.localdomain> <1222385352.12997.100.camel@ns.five-ten-sg.com> <1222385988.4848.12.camel@luminos.localdomain> Message-ID: <1222386335.12997.112.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 2008-09-25 at 16:39 -0700, Jesse Keating wrote: > On Thu, 2008-09-25 at 16:29 -0700, Carl Byington wrote: > > Yes, but I assumed that /etc/mail/aliases: > > root: someuser > > > > And that as someuser, you would then configure an Evolution account > to > > read /var/spool/mail/someuser. > Why would you assume that though? What currently in Fedora sets this > up > for a user after a fresh install? What currently in Fedora > recommends > that a user do that themselves? Nothing at all. I was just responding to the comment that Evolution did not know how to read a local spool file (as opposed to imap/pop from a server). If we continue to do local delivery of cron/logwatch/etc stuff, and if we possibly add some stuff to firstboot to help setup the root alias, then we already have a tool, evolution, that can be used to read the resulting mail spool. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFI3CKVL6j7milTFsERAnUGAJ9/ldl/3O/IU3xGp+CzM1mK/oJ/3wCfT9Ph lBfXH0XYptCLEe2nNu6WlLg= =/X5g -----END PGP SIGNATURE----- From mw_triad at users.sourceforge.net Thu Sep 25 23:47:51 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 25 Sep 2008 18:47:51 -0500 Subject: please deactivate services by default! In-Reply-To: References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> <20080925202639.GA3831@free.fr> <48DC201C.9040905@shmuelhome.mine.nu> Message-ID: Colin Walters wrote: > O >> This particular problem doesn't concern me since my work does not depend on >> sendmail. But I think that a logical error is being made here. For repeat >> users, I don't see a real difference between updates and clean installs. I, >> for one, am very willing to install a new release since it will clean out >> accumulated junk. The only thing that I will keep from the old release is >> /home. I don't think that I would find it acceptable that previously assumed >> features just stopped working. Breaking cron or side effects of cron is >> unacceptable. > > If you only keep /home, you'll lose your crontab (since they're in > /var/spool/cron, not /home). Note that in my example, I specifically talked about setting up [my] cron[tab] again. > In the longer term I would like to see cron-like functionality > provided by and integrated with GNOME, What about KDE, lxde, others? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "You know what Microsoft's problem really is? They've lost the ability to feel ashamed." -- Pamela Jones (Groklaw) From cmadams at hiwaay.net Thu Sep 25 22:27:42 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 25 Sep 2008 17:27:42 -0500 Subject: please deactivate services by default! In-Reply-To: References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> Message-ID: <20080925222742.GB1517148@hiwaay.net> Once upon a time, Matthew Woehlke said: > Chris Adams wrote: > >But the livecd "copy to hard drive" option is a quick-and-easy way to > >install a system from a single CD, at which point this is NOT just about > >the CD version. > > Is sendmail so huge it doesn't fit on the livecd? I suspect not, this > conversation started about boot time after all. So... don't start it for > the livecd, *do* start it when the livecd is installed to disk. Don't confuse sendmail with "SMTP server". It doesn't have to be sendmail. I know how to manage sendmail and use it, but obviously it isn't for everybody. Also, is there any way to have configuration changes like that made when the live image is copied to disk? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From carl at five-ten-sg.com Thu Sep 25 22:22:28 2008 From: carl at five-ten-sg.com (Carl Byington) Date: Thu, 25 Sep 2008 15:22:28 -0700 Subject: please deactivate services by default! In-Reply-To: <1222299566.1895.0.camel@luminos.localdomain> References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <1222299566.1895.0.camel@luminos.localdomain> Message-ID: <1222381348.12997.87.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Which is why we shouldn't be using local delivery for this stuff. > Instead we should ask in firstboot where you'd want the mail > delivered > to. If you don't do local delivery, but instead talk to some other server over port 25/587, you then need to *also* ask for: smtp authentication required (yes/no) authentication style pop before smtp (I wish that would go away) smtp auth (login, plain, ntlm?) tls (never, always, if available) username/password for that authentication step - where will you keep those credentials securely? That is a rather large can of worms, rather than just doing local delivery via a local sendmail. Then, only those who care need to worry about the grungy details of getting that mail properly forwarded elsewhere. Consider the case of a laptop, booting up in a hotel that blocks outgoing port 25, trying to send cron output. Consider the same hotel blocking port 587 (yes, some are that silly). Suppose that at the time this laptop was configured, it was on the same subnet as the corporate mail server, so everything just seemed to work over port 25 with no authentication (since relaying was allowed from that subnet). Now, when the laptop is taken home, all the cron mail silently fails. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFI3A7lL6j7milTFsERAjk3AJ95KbqWuqRZNO9uC53C3Jyu71Ab4QCcCYkc MTEYrw2O+mH3Ip+H80v/Nac= =4BY8 -----END PGP SIGNATURE----- From sundaram at fedoraproject.org Fri Sep 26 00:08:06 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 26 Sep 2008 05:38:06 +0530 Subject: please deactivate services by default! In-Reply-To: <20080925222742.GB1517148@hiwaay.net> References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <20080925222742.GB1517148@hiwaay.net> Message-ID: <48DC27E6.6010709@fedoraproject.org> Chris Adams wrote: > Once upon a time, Matthew Woehlke said: >> Chris Adams wrote: >>> But the livecd "copy to hard drive" option is a quick-and-easy way to >>> install a system from a single CD, at which point this is NOT just about >>> the CD version. >> Is sendmail so huge it doesn't fit on the livecd? I suspect not, this >> conversation started about boot time after all. So... don't start it for >> the livecd, *do* start it when the livecd is installed to disk. > > Don't confuse sendmail with "SMTP server". It doesn't have to be > sendmail. I know how to manage sendmail and use it, but obviously it > isn't for everybody. > > Also, is there any way to have configuration changes like that made when > the live image is copied to disk? Sure. Within a init script or %post section in kickstart Rahul From seg at haxxed.com Fri Sep 26 00:21:23 2008 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 25 Sep 2008 19:21:23 -0500 Subject: please deactivate services by default! In-Reply-To: <5256d0b0809251329g44a69287l585bf57bd6b3130c@mail.gmail.com> References: <20080924212236.GJ1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <48DBF2E5.70006@fedoraproject.org> <5256d0b0809251329g44a69287l585bf57bd6b3130c@mail.gmail.com> Message-ID: <1222388483.5130.6.camel@localhost.localdomain> On Thu, 2008-09-25 at 21:29 +0100, Peter Robinson wrote: > > Live CD is always cramped for space. So everything that doesn't really fit > > the regular single user desktop use cases (and sometimes even that) would > > probably be removed from the live cd unless there are package dependencies. > > Even earlier today, release engineering was fighting to get it down to CD > > size. > > Dare I ask why numactl is on there then :-) Its not like a person > installing a numactl system wouldn't know how to install a package and > its fairly distant from your mainstream. All multi-processor x86_64 machines are NUMA. I'm unclear how this applies to multi-core (in one chip) though. Do the cores have independent DDR controllers? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From michel.sylvan at gmail.com Fri Sep 26 00:47:10 2008 From: michel.sylvan at gmail.com (Michel Salim) Date: Thu, 25 Sep 2008 20:47:10 -0400 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222150606.30758.65.camel@code.and.org> References: <48D542A9.1070600@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> <1222150606.30758.65.camel@code.and.org> Message-ID: 2008/9/23 James Antill : > > _Well done_ for bringing up rpm specfile groups which are obsolete, as > I'm sure you know, and have been since before PK existed. I've been wondering -- is there any reason we don't get rpmbuild to strip the group out of the package metadata when it generates a binary RPM? Also, right now, rpmdev-newspec still creates a Group field, and even prepopulates it for certain templates (e.g. libraries) Regards, -- mi?el salim ? http://hircus.jaiku.com/ IUCS ? msalim at cs.indiana.edu Fedora ? salimma at fedoraproject.org MacPorts ? hircus at macports.org From sundaram at fedoraproject.org Fri Sep 26 00:50:19 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 26 Sep 2008 06:20:19 +0530 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: References: <48D542A9.1070600@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> <1222150606.30758.65.camel@code.and.org> Message-ID: <48DC31CB.3030207@fedoraproject.org> Michel Salim wrote: > 2008/9/23 James Antill : >> _Well done_ for bringing up rpm specfile groups which are obsolete, as >> I'm sure you know, and have been since before PK existed. > > I've been wondering -- is there any reason we don't get rpmbuild to > strip the group out of the package metadata when it generates a binary > RPM? Smart, Apt and probably others still rely on those IIRC. If they are taught to use comps, we can get rid of the rpm groups. Rahul From jkeating at redhat.com Fri Sep 26 00:55:27 2008 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 25 Sep 2008 17:55:27 -0700 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <48DC31CB.3030207@fedoraproject.org> References: <48D542A9.1070600@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> <1222150606.30758.65.camel@code.and.org> <48DC31CB.3030207@fedoraproject.org> Message-ID: <1222390527.4848.15.camel@luminos.localdomain> On Fri, 2008-09-26 at 06:20 +0530, Rahul Sundaram wrote: > Smart, Apt and probably others still rely on those IIRC. If they are > taught to use comps, we can get rid of the rpm groups. No, we won't be waiting for those to catch up. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mattdm at mattdm.org Fri Sep 26 00:56:12 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 25 Sep 2008 20:56:12 -0400 Subject: please deactivate services by default! In-Reply-To: References: <1222294938.3941.20.camel@choeger6> <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> <20080925202639.GA3831@free.fr> <48DC201C.9040905@shmuelhome.mine.nu> Message-ID: <20080926005612.GA7897@jadzia.bu.edu> On Thu, Sep 25, 2008 at 07:40:04PM -0400, Colin Walters wrote: > If you only keep /home, you'll lose your crontab (since they're in > /var/spool/cron, not /home). 5 6 * * * crontab -l > ~/.crontab.bak > In the longer term I would like to see cron-like functionality > provided by and integrated with GNOME, which would fix not only this How's that work when you log out? -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs Computing & Information Technology Harvard School of Engineering & Applied Sciences From csnook at redhat.com Fri Sep 26 01:02:44 2008 From: csnook at redhat.com (Chris Snook) Date: Thu, 25 Sep 2008 21:02:44 -0400 Subject: Do we care about /sbin /bin linked to /usr/lib ? In-Reply-To: <200809251328.01886.sgrubb@redhat.com> References: <200809251328.01886.sgrubb@redhat.com> Message-ID: <48DC34B4.9080407@redhat.com> Steve Grubb wrote: > Hi, > > I wrote a utility that checks all apps in /bin & /sbin to see if they link > against anything in /usr. Is this a problem that we care about? > > /bin/rpm uses something in /usr > /sbin/arping uses something in /usr > /sbin/audispd-zos-remote uses something in /usr > /sbin/audisp-prelude uses something in /usr > /sbin/audisp-remote uses something in /usr I don't see why the above need to be in /bin or /sbin. > /sbin/auditd uses something in /usr This is a problem. The sorts of people who care about auditd may want to rely on having a separate /usr partition to minimize the amount of code on their system that could possibly run before auditd is up and running. > /sbin/cifs.upcall uses something in /usr I don't think a lot of people are mounting /usr over cifs, but on principle, I don't think we should have filesystem-related things depending on /usr. > /sbin/grubby uses something in /usr I would think we really only need to be calling grubby when the system is fully booted. > /sbin/lsusb uses something in /usr This could be a problem for people booting off USB devices. Mostly this is only used for liveCD/liveUSB, so we don't hit it, but with the rise of netbooks and such where people may want to boot off a USB-attached SD card, it could come up. I don't think it's a high priority, but if there's an easy fix, we should do it. > /sbin/nash uses something in /usr That sounds bad. > /sbin/setkey uses something in /usr > /sbin/umount.hal uses something in /usr Is HAL supposed to be involved with system partitions? I was under the impression that it is not, so this doesn't need to be in /sbin. -- Chris From jan.kratochvil at redhat.com Fri Sep 26 01:07:56 2008 From: jan.kratochvil at redhat.com (Jan Kratochvil) Date: Fri, 26 Sep 2008 03:07:56 +0200 Subject: debuginfo package dependencies In-Reply-To: <20080924231706.874E8154493@magilla.localdomain> References: <48DAC204.7000901@cora.nwra.com> <20080924231706.874E8154493@magilla.localdomain> Message-ID: <20080926010756.GA31059@host0.dyn.jankratochvil.net> On Thu, 25 Sep 2008 01:17:06 +0200, Roland McGrath wrote: > The rawhide rpms don't have these extra requires and provides. > I don't know why F-9's debuginfo rpms do have them. https://bugzilla.redhat.com/show_bug.cgi?id=427579 it missed the time F9 was mass-rebuilt. Regards, Jan From icon at fedoraproject.org Fri Sep 26 01:18:26 2008 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Thu, 25 Sep 2008 21:18:26 -0400 Subject: Epylog (Re: please deactivate services by default!) Message-ID: On Thu, Sep 25, 2008 at 4:03 PM, seth vidal wrote: >> >> Heh. Yeah, okay, fair point -- but currently it's the best we've got (given >> that epylog seems stalled)... >> > > I haven't heard from Konstantin about epylog in a good long while now. > > You should email him and see if he needs someone to take it over. He does. :) The trouble is that once I was no longer a sysadmin, that particular itch has disappeared. I have been a busy boy in the past few years, too (wife, family, etc), so I no longer have copious amounts of time to dedicate to hacking on fun projects in the evenings. Mea culpa. Epylog is still a sound project, it just needs to become someone else's itch to scratch. :) The plans that I had for it were: 1. Rewrite log parsing routines to be configurable and not hardcoded, since programmers don't really think twice about modifying those (one day is "service foo started by user=bar domain=baz," in the next version it's "service foo started: user=bar; domain=baz") 2. There is really just a couple of log notice types that make up the bulk of messages -- e.g. "user foo logged into bar using service baz from host quux", just in different formats. These can all be abstracted and put into sqlite db for generating reports (not in huge dicts as right now). 3. Everything else are one-offs that people either don't care about ("daemon foo received a message!") or really-really care about ("smartd says the disk on node X is about to keel over and die"). The crap you filter out, and whatever doesn't fall under "crap" you usually put at the top. That's pretty much all it would take to make Epylog not as annoying when it comes to configuration and hacking. However, like I said -- I don't think I'll have the time or motivation to do that. Moving the project to fedorahosted was one of the steps I had in mind towards making it more accessible for others to hack on (should they be interested in that). Cheers, -- Konstantin Ryabitsev Montr?al, Qu?bec From katzj at redhat.com Fri Sep 26 01:47:11 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 25 Sep 2008 21:47:11 -0400 Subject: Do we care about /sbin /bin linked to /usr/lib ? In-Reply-To: <48DC34B4.9080407@redhat.com> References: <200809251328.01886.sgrubb@redhat.com> <48DC34B4.9080407@redhat.com> Message-ID: <1222393631.15682.1.camel@aglarond.local> On Thu, 2008-09-25 at 21:02 -0400, Chris Snook wrote: > Steve Grubb wrote: > > /sbin/lsusb uses something in /usr > > This could be a problem for people booting off USB devices. Mostly this is only > used for liveCD/liveUSB, so we don't hit it, but with the rise of netbooks and > such where people may want to boot off a USB-attached SD card, it could come up. > I don't think it's a high priority, but if there's an easy fix, we should do it. Nothing involved in booting off of USB requires lsusb. It's purely a diagnostic tool. And you can get all of the information also via /proc or /sys > > /sbin/umount.hal uses something in /usr > > Is HAL supposed to be involved with system partitions? I was under the > impression that it is not, so this doesn't need to be in /sbin. It has to be in /sbin because mount helpers are only looked for in /sbin Jeremy From cmadams at hiwaay.net Fri Sep 26 01:37:34 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 25 Sep 2008 20:37:34 -0500 Subject: please deactivate services by default! In-Reply-To: References: <1222294938.3941.20.camel@choeger6> <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> <20080925202639.GA3831@free.fr> <48DC201C.9040905@shmuelhome.mine.nu> Message-ID: <20080926013734.GE1517148@hiwaay.net> Once upon a time, Colin Walters said: > In the longer term I would like to see cron-like functionality > provided by and integrated with GNOME ... What is the fixation with moving underlying system-level things (network config, power management, timed job execution, etc.) into the desktop? I use systems with running X or without ever logging in. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From james.antill at redhat.com Fri Sep 26 03:35:46 2008 From: james.antill at redhat.com (James Antill) Date: Thu, 25 Sep 2008 23:35:46 -0400 Subject: Yum NFS mounted/shared cache directories? In-Reply-To: <2a28d2ab0809251610u3c07e2b1k5a6ebe12f6ee88be@mail.gmail.com> References: <2a28d2ab0809251610u3c07e2b1k5a6ebe12f6ee88be@mail.gmail.com> Message-ID: <1222400146.22953.39.camel@code.and.org> On Thu, 2008-09-25 at 19:10 -0400, Dr. Diesel wrote: > Perhaps not a bug or maybe requires a feature request. I'm attempting > to host my /var/cache/yum directory on a NFS to share with several > other machines. I've tired doing with by simply changing the location > in yum.conf and also by creating a symbolic link to the directory with > no succes, yum just stops here with no error: What verison? What does strace say yum is doing? The sqlite documentation generally recommends against using NFS to store the DB, although yum doesn't rely on multiple processes updating the DB at once ... even so you might want to just have the packages dirs. on NFS but leave the top level local. We're hoping that something like yum-avahi will allow you to share data over the local network for Fedora 11, which is the "good" way to solve this problem IMO. -- James Antill Red Hat -------------- 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 vonbrand at inf.utfsm.cl Fri Sep 26 03:53:39 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Thu, 25 Sep 2008 23:53:39 -0400 Subject: please deactivate services by default! In-Reply-To: References: <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> <20080925202639.GA3831@free.fr> <48DC201C.9040905@shmuelhome.mine.nu> Message-ID: <200809260353.m8Q3rdDn004719@laptop14.inf.utfsm.cl> Colin Walters wrote: [...] > In the longer term I would like to see cron-like functionality > provided by and integrated with GNOME, which would fix not only this > but also cleanly allow your cron jobs to access cached authentication > credentials in gnome-keyring, let you pop up notification messages, > etc. Integrating that into /one/ graphical environment (that probably isn't running at all most of the time) makes no sense to me... and is completely misplaced, to boot. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From skvidal at fedoraproject.org Fri Sep 26 05:03:47 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 26 Sep 2008 01:03:47 -0400 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: References: <48D542A9.1070600@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> <1222150606.30758.65.camel@code.and.org> Message-ID: <1222405427.4144.174.camel@rosebud> On Thu, 2008-09-25 at 20:47 -0400, Michel Salim wrote: > 2008/9/23 James Antill : > > > > _Well done_ for bringing up rpm specfile groups which are obsolete, as > > I'm sure you know, and have been since before PK existed. > > I've been wondering -- is there any reason we don't get rpmbuild to > strip the group out of the package metadata when it generates a binary > RPM? > > Also, right now, rpmdev-newspec still creates a Group field, and even > prepopulates it for certain templates (e.g. libraries) it'll be maintained for compat reasons by it is no longer required to build a package as of the new rpm in rawhide, iirc. -sv From skvidal at fedoraproject.org Fri Sep 26 05:05:09 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Fri, 26 Sep 2008 01:05:09 -0400 Subject: Yum NFS mounted/shared cache directories? In-Reply-To: <1222400146.22953.39.camel@code.and.org> References: <2a28d2ab0809251610u3c07e2b1k5a6ebe12f6ee88be@mail.gmail.com> <1222400146.22953.39.camel@code.and.org> Message-ID: <1222405509.4144.177.camel@rosebud> On Thu, 2008-09-25 at 23:35 -0400, James Antill wrote: > On Thu, 2008-09-25 at 19:10 -0400, Dr. Diesel wrote: > > Perhaps not a bug or maybe requires a feature request. I'm attempting > > to host my /var/cache/yum directory on a NFS to share with several > > other machines. I've tired doing with by simply changing the location > > in yum.conf and also by creating a symbolic link to the directory with > > no succes, yum just stops here with no error: > > What verison? > What does strace say yum is doing? > The sqlite documentation generally recommends against using NFS to > store the DB, although yum doesn't rely on multiple processes updating > the DB at once ... even so you might want to just have the packages > dirs. on NFS but leave the top level local. > > We're hoping that something like yum-avahi will allow you to share data > over the local network for Fedora 11, which is the "good" way to solve > this problem IMO. > intelligent mirror is another good way. Relying on nfs + sqlite and worrying about the race conditions w/multiple yum instances on multiple machines possibly writing to this location is just going to end badly. -sv From debarshi.ray at gmail.com Fri Sep 26 05:23:53 2008 From: debarshi.ray at gmail.com (Debarshi Ray) Date: Fri, 26 Sep 2008 10:53:53 +0530 Subject: please deactivate services by default! In-Reply-To: <1222367236.16840.153.camel@vespa.frost.loc> References: <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925173858.GA21166@nostromo.devel.redhat.com> <1222367236.16840.153.camel@vespa.frost.loc> Message-ID: <3170f42f0809252223w2aac167cm51ec805f943968f2@mail.gmail.com> > I wonder whether it would be possible to make them somehow to do so? As I noted in the other thread, gnubiff might do this, but then I have no idea whether that is going to solve anything for us. Cheers, Debarshi From aoliva at redhat.com Fri Sep 26 05:59:00 2008 From: aoliva at redhat.com (Alexandre Oliva) Date: Fri, 26 Sep 2008 02:59:00 -0300 Subject: Instant Mirror Status...? In-Reply-To: <20080923153346.GA10633@auslistsprd01.us.dell.com> (Matt Domsch's message of "Tue\, 23 Sep 2008 10\:33\:46 -0500") References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> <48D8154B.9080804@students.iiit.ac.in> <16de708d0809221650n27d4cd7djfa4b39e4ad12ff27@mail.gmail.com> <1222128026.4108.46.camel@luminos.localdomain> <16de708d0809221720r3dad221vac4cb255ccc50490@mail.gmail.com> <48D867D8.40304@gmail.com> <1222153299.29561.7.camel@code.and.org> <20080923153346.GA10633@auslistsprd01.us.dell.com> Message-ID: On Sep 23, 2008, Matt Domsch wrote: > Furthermore, I absolutely don't want to return the same mirror at the > top of the list _for everyone_ in a given country. Hash MM's "primary" IP address to select one of the various available mirrors, assuming they're returned in a consistent order? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} FSFLA Board Member ?S? Libre! => http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} From lesmikesell at gmail.com Fri Sep 26 06:35:15 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 26 Sep 2008 01:35:15 -0500 Subject: Instant Mirror Status...? In-Reply-To: References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> <48D8154B.9080804@students.iiit.ac.in> <16de708d0809221650n27d4cd7djfa4b39e4ad12ff27@mail.gmail.com> <1222128026.4108.46.camel@luminos.localdomain> <16de708d0809221720r3dad221vac4cb255ccc50490@mail.gmail.com> <48D867D8.40304@gmail.com> <1222153299.29561.7.camel@code.and.org> <20080923153346.GA10633@auslistsprd01.us.dell.com> Message-ID: <48DC82A3.9010207@gmail.com> Alexandre Oliva wrote: > On Sep 23, 2008, Matt Domsch wrote: > >> Furthermore, I absolutely don't want to return the same mirror at the >> top of the list _for everyone_ in a given country. > > Hash MM's "primary" IP address to select one of the various available > mirrors, assuming they're returned in a consistent order? If you are going to return a list of N mirrors, make N copies of that list, rotating one position for each. Knock the last octet off the source IP and hash the remaining part with some consistent algorithm that will give you N values and use that to choose the copy of the list you send. Everything is as distributed and robust as before, but you don't defeat attempts to save your bandwidth with caching proxies. -- Les Mikesell lesmikesell at gmail.com From mike at miketc.net Fri Sep 26 07:10:31 2008 From: mike at miketc.net (Mike Chambers) Date: Fri, 26 Sep 2008 02:10:31 -0500 Subject: rawhide report: 20080925 changes In-Reply-To: <20080925102712.1CDA81F825C@releng2.fedora.phx.redhat.com> References: <20080925102712.1CDA81F825C@releng2.fedora.phx.redhat.com> Message-ID: <1222413031.22052.5.camel@scrappy.miketc.net> On Thu, 2008-09-25 at 10:27 +0000, Rawhide Report wrote: > Updated Packages: > > anaconda-11.4.1.40-1 > -------------------- > * Wed Sep 24 18:00:00 2008 David Cantrell - 11.4.1.40-1 > - Fix network interface bring up in text mode (#463861, #462592) (dcantrell) > - Bring back isys.resetResolv() and fix NetworkManager polling in > network.py. (dcantrell) > - Poll 'State' property from NetworkManager in network.bringUp() (dcantrell) > - Log error in rescue mode is network.bringUp() fails. (dcantrell) > - Set the first network device in the list to active. (dcantrell) > - Get rid of firstnetdevice in Network (dcantrell) > - Do not write /lib/udev.d rules if instPath is '' (dcantrell) > - Fix problems with bringDeviceUp() calls (#463512) (dcantrell) Finally was able to do an install and configure the network, sort of. I tried to configure it manually but the config screen kept coming back up and wouldn't accept it or something (never saw an error). But, was able to do it via dhcp and worked like a champ. I was able to configure the network manually post install though, via NetworkManager. -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From pmatilai at laiskiainen.org Fri Sep 26 07:47:36 2008 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 26 Sep 2008 10:47:36 +0300 (EEST) Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222405427.4144.174.camel@rosebud> References: <48D542A9.1070600@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> <1222150606.30758.65.camel@code.and.org> <1222405427.4144.174.camel@rosebud> Message-ID: On Fri, 26 Sep 2008, seth vidal wrote: > On Thu, 2008-09-25 at 20:47 -0400, Michel Salim wrote: >> 2008/9/23 James Antill : >>> >>> _Well done_ for bringing up rpm specfile groups which are obsolete, as >>> I'm sure you know, and have been since before PK existed. >> >> I've been wondering -- is there any reason we don't get rpmbuild to >> strip the group out of the package metadata when it generates a binary >> RPM? >> >> Also, right now, rpmdev-newspec still creates a Group field, and even >> prepopulates it for certain templates (e.g. libraries) > > it'll be maintained for compat reasons by it is no longer required to > build a package as of the new rpm in rawhide, iirc. Yup. We can't drop off the group tag just like that, not only various software expects it to be there, it's documented as a mandatory field in LSB. rpmbuild no longer requires the Group: tag in specs, but it drops in "Unspecified" if the spec doesn't set it to comply (the current rawhide rpm wont do this but it's fixed upstream, rawhide will get it in next version update) - Panu - From pbrobinson at gmail.com Fri Sep 26 08:00:59 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 26 Sep 2008 09:00:59 +0100 Subject: please deactivate services by default! In-Reply-To: <1222388483.5130.6.camel@localhost.localdomain> References: <20080924212236.GJ1414283@hiwaay.net> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <48DBF2E5.70006@fedoraproject.org> <5256d0b0809251329g44a69287l585bf57bd6b3130c@mail.gmail.com> <1222388483.5130.6.camel@localhost.localdomain> Message-ID: <5256d0b0809260100jc5f100fm51e42fa310981857@mail.gmail.com> >> > Live CD is always cramped for space. So everything that doesn't really fit >> > the regular single user desktop use cases (and sometimes even that) would >> > probably be removed from the live cd unless there are package dependencies. >> > Even earlier today, release engineering was fighting to get it down to CD >> > size. >> >> Dare I ask why numactl is on there then :-) Its not like a person >> installing a numactl system wouldn't know how to install a package and >> its fairly distant from your mainstream. > > All multi-processor x86_64 machines are NUMA. I'm unclear how this > applies to multi-core (in one chip) though. Do the cores have > independent DDR controllers? I thought numa is a series of computers connected together via a fast interconnect such as Infiband where they can access each others memory but accessing local memory is faster than non-local memory. Hence Non Uniform Memory Access. http://en.wikipedia.org/wiki/Non-Uniform_Memory_Access Peter From Juha.Tuomala at iki.fi Fri Sep 26 08:25:21 2008 From: Juha.Tuomala at iki.fi (Juha Tuomala) Date: Fri, 26 Sep 2008 11:25:21 +0300 Subject: sqlite on NFS (was: re: Yum NFS mounted/shared cache directories?) In-Reply-To: <1222400146.22953.39.camel@code.and.org> References: <2a28d2ab0809251610u3c07e2b1k5a6ebe12f6ee88be@mail.gmail.com> <1222400146.22953.39.camel@code.and.org> Message-ID: <200809261125.21890.Juha.Tuomala@iki.fi> On Friday 26 September 2008 06:35:46 James Antill wrote: > The sqlite documentation generally recommends against using NFS to > store the DB, I know two programs which already do so, msynctool and firefox which both fail if your nfs lockd is not working properly. And when it does, there's no problem. But I'm more worried about Akonadi that is going to run mysqld database on my nfs $HOME. [tuju at wasa]~% akonadictl start Starting Akonadi Server... done. process listing: /usr/bin/akonadi_control \_ akonadiserver \_ /usr/libexec/mysqld --defaults-file=/home/tuju/.local/share Tuju -- Varo hattup?isi? autoilijoita. From pertusus at free.fr Fri Sep 26 08:38:36 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 26 Sep 2008 10:38:36 +0200 Subject: please deactivate services by default! In-Reply-To: References: <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> <20080925202639.GA3831@free.fr> <20080925213114.GC3831@free.fr> Message-ID: <20080926083836.GC3149@free.fr> On Thu, Sep 25, 2008 at 06:10:39PM -0500, Matthew Woehlke wrote: > >> And I am not playing game with people data, > > If local mail suddenly went to /dev/null, and I didn't realize that, you > /would/ be playing with my data. Not suddenly. Between releases and marked in release notes. >> cron now requires /usr/sbin/sendmail, which is enough in my opinion. > > Well then... say so :-). Yesterday would have been a nice time :-). I said it much before when I listed what dependend on what and what provided what. But it is not what you want. You want to have local delivery working in the default case. In order to achieve your goal: 1) we could add a new virtual provides, like Requires: mail(local-delivery) meaning that the software directly or indirectly provides /usr/sbin/sendmail and is configured to do local delivery in the default case. exim, postfix and sendmail could then provide that, and even a package installing /etc/esmtp.conf with local mail delivered through procmail condfigured, depending on procmail and esmtp. 2) we could say that the MTA virtual provides means provides /usr/sbin/sendmail, server(smtp), aliases, and the same than mail(local-delivery), and have cron depend on MTA. exim, postfix or sendmail would then be selected 3) we could change the meaning of the /usr/sbin/sendmail provides, and require that it is the same than mail(local-delivery). In that case ssmtp could not provide it anymore since it cannot do local delivery. 4) to select the default program that provides /usr/sbin/sendmail we could make sure that it is a program that provides mail(local-delivery). I think that all those are wrong. In my opinion 4) should be considered when choosing the default programs, but should only be one of the element to consider when selecting the default application. > Well, I feel it's a regression for people relying on the previous > default; especially if they don't realize anything has changed. They should read release notes. > Point of clarification: would installing cron restore the old behavior? > (That is, working local mail delivery...) If so, well, it will be hard > to set up cron-based backups when cron isn't installed, so effectively > 'yum install cronie' will get things working the way they always did. Unless I am wrong cronie is in the default package set, and so it drags in /usr/sbin/sendmail dependency. If there is no package in the default set already providing it, exim would be choosen since the shortest name wins. But maybe there is a package in th edefault set that provides /usr/sbin/sendmail. > Well, obviously I disagree that there is anything wrong with the current > local mail behavior for non-root. It is not wrong, but it is arbitrary. I think that local mail delivery should not be granted. If the package that that provides /usr/sbin/sendmail delivers mail locally, then fine, if it doesn't, then fine too. And, still in my opinion, the upsteram conf should be followed. > The whole point has been, don't break things until the mechanism to > handle the fallout is in place. Sounds like we've decided to do that. Maybe what should be done for F10 could be to choose a /usr/sbin/sendmail provider that is a full blown MTA, and discuss what functionnalities should the default package providing /usr/sbin/sendmail have. But it would certainly lead to the same debate. >> But a random app that provides >> /usr/sbin/sendmail would also be right, even if it doesn't do local >> delivery. > > ...not this, unless said MTA is reasonably assured to deliver cron's > mail, as per my definition (above) of "reliable". Well, my opinion is that how reliable the /usr/sbin/sendmail is should be left to the user installing it, or to the default /usr/sbin/sendmail provider decision and not be tight to the previous use case. -- Pat From pertusus at free.fr Fri Sep 26 09:11:09 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 26 Sep 2008 11:11:09 +0200 Subject: unfrozen repo somewhere? Message-ID: <20080926091109.GF3149@free.fr> Hello, I understand why rawhide should be frozen at some points, but sometime there is a package one really wants, that is built in koji, but not available in rawhide because it is frozen. In my case, for example, rpm-build is broken but aleady fixed. So maybe it would be worth having a special repo that would not be enabled, but that would allow to have the latest builds during a beta freeze. In my opinion this repo should also be used for Matt rebuilds since there are alot of already fixed FTBS in his reports due to the freeze, which is a bit annoying. -- Pat From gc at falconpl.org Fri Sep 26 09:29:13 2008 From: gc at falconpl.org (Giancarlo Niccolai) Date: Fri, 26 Sep 2008 11:29:13 +0200 Subject: please deactivate services by default! In-Reply-To: <1222384327.4848.9.camel@luminos.localdomain> References: <1222294938.3941.20.camel@choeger6> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925173858.GA21166@nostromo.devel.redhat.com> <1222367236.16840.153.camel@vespa.frost.loc> <20080925183249.GA24278@nostromo.devel.redhat.com> <20080925230529.GC29433@shell.devel.redhat.com> <1222384327.4848.9.camel@luminos.localdomain> Message-ID: <48DCAB69.7010904@falconpl.org> Jesse Keating wrote: > On Thu, 2008-09-25 at 19:05 -0400, Alan Cox wrote: > >> Log files tend to contain stuff like passwords typed in the wrong box so >> we shouldn't casually point mail off box. Also a lot of mail from cron, >> logging etc will be mail to explain your internet connection is down or your >> email couldn't be forwarded .. >> > > Which does no good if we don't actually lead people to read this mail, > one way or another. Right now we just hope that they figure out some > how to start collecting root's mail before it fills up filesystem. > Sorry for jumping in the discussion; as a user of multiple distros and of multiple versions of each distro, I feel this point terribly sensible. Figuring out what's the right way(TM) to get root mail on one distro is not exactly a cakewalk, and it requires usually some sysop skills that are not always readily available to the mean desktop user. And even for developers (as I am) and power users, it's a annoying waste of time. When you switch distros or you find newer versions of the same distro having different policies on this topic, unless your business with Linux is having fun in tweaking the system config, you easily give up with a "oh well, I have 250GB hd, I'll figure out how to dump this trash before filling it up, eventually". Pitifully, the vast majority of distro maintainers ARE guys who have lots of fun in tweaking system configs... I think it's high time for everyone else to have an easy desktop-accessible place from where to check for sensible logs, with a flashlight on the taskbar when some critical warning is issued and with sensible self-cleanup policy... Bests, Giancarlo. From mtasaka at ioa.s.u-tokyo.ac.jp Fri Sep 26 09:37:24 2008 From: mtasaka at ioa.s.u-tokyo.ac.jp (Mamoru Tasaka) Date: Fri, 26 Sep 2008 18:37:24 +0900 Subject: unfrozen repo somewhere? In-Reply-To: <20080926091109.GF3149@free.fr> References: <20080926091109.GF3149@free.fr> Message-ID: <48DCAD54.7060804@ioa.s.u-tokyo.ac.jp> Patrice Dumas wrote, at 09/26/2008 06:11 PM +9:00: > Hello, > > I understand why rawhide should be frozen at some points, but sometime > there is a package one really wants, that is built in koji, but not > available in rawhide because it is frozen. In my case, for example, > rpm-build is broken but aleady fixed. So maybe it would be worth having > a special repo that would not be enabled, but that would allow to have > the latest builds during a beta freeze. In my opinion this repo should > also be used for Matt rebuilds since there are alot of already fixed FTBS > in his reports due to the freeze, which is a bit annoying. > > -- > Pat I always use a repo file (named fedora-koji.repo) which contains: --------------------------------------------------------------- [koji] name= koji - koji snapshot tree baseurl=http://koji.fedoraproject.org/static-repos/dist-f10-build-current/$basearch/ enabled=1 gpgcheck=0 --------------------------------------------------------------- And I think fedora-devel-i386.cfg (in mock) has similar lines. Mamoru From rawhide at fedoraproject.org Fri Sep 26 09:58:43 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Fri, 26 Sep 2008 09:58:43 +0000 (UTC) Subject: rawhide report: 20080926 changes Message-ID: <20080926095843.4EE961F825C@releng2.fedora.phx.redhat.com> Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Broken deps for i386 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 1:openoffice.org-langpack-pa_IN-3.0.0-5.1.fc10.i386 requires hunspell-pa pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.i386 requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so Broken deps for x86_64 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.x86_64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.ppc requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so Broken deps for ppc64 ---------------------------------------------------------- eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gspiceui-0.9.65-2.fc10.ppc64 requires gwave livecd-tools-018-1.fc10.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.ppc64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) From Lam at Lam.pl Fri Sep 26 10:11:50 2008 From: Lam at Lam.pl (Leszek Matok) Date: Fri, 26 Sep 2008 12:11:50 +0200 Subject: please deactivate services by default! In-Reply-To: <1222288377.2908.3.camel@sb-home> References: <1222287197.3941.7.camel@choeger6> <1222288377.2908.3.camel@sb-home> Message-ID: <20080926121150.7e1aa0a1@pensja.lam.pl> Dnia 2008-09-24, o godz. 22:32:57 nodata napisa?(a): > Am Mittwoch, den 24.09.2008, 22:13 +0200 schrieb Christoph H?ger: > > 1. sendmail: starts way too slow, is not usefull for any normal desktop > > user I know. Making it usefull requires configuration so I assume > > wohever uses that service _can_ activate it. > > How will you get emails from logwatch and errors from your cron scripts? > You don't need daemon running for that, I think. When I cared, cron used sendmail (the executable binary), which delivers locally (the default is still to simply deliver to /var/spool/mail/root) without connecting to any daemon. Has that changed recently? Unless you use an alias to forward root's mail to some other server, in which case it will never leave the mail queue. But that's just one new step required to make that kind of non-default setup work. Lam -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dr.diesel at gmail.com Fri Sep 26 10:29:12 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 26 Sep 2008 05:29:12 -0500 Subject: Yum NFS mounted/shared cache directories? In-Reply-To: <1222405509.4144.177.camel@rosebud> References: <2a28d2ab0809251610u3c07e2b1k5a6ebe12f6ee88be@mail.gmail.com> <1222400146.22953.39.camel@code.and.org> <1222405509.4144.177.camel@rosebud> Message-ID: <2a28d2ab0809260329m1397766btaea508f660853715@mail.gmail.com> > > > > > We're hoping that something like yum-avahi will allow you to share data > > over the local network for Fedora 11, which is the "good" way to solve > > this problem IMO. > > > > intelligent mirror is another good way. > > Relying on nfs + sqlite and worrying about the race conditions > w/multiple yum instances on multiple machines possibly writing to this > location is just going to end badly. > > -sv > Mirroring the package directories is easy enough. I will attempt the strace suggestion and get back to you all. Current versions are all F9 to date. Any project information on yum-avahi and what it might evolve into? Thanks Andy > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From rc040203 at freenet.de Fri Sep 26 10:35:53 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 26 Sep 2008 12:35:53 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <20080926091109.GF3149@free.fr> References: <20080926091109.GF3149@free.fr> Message-ID: <1222425353.3564.248.camel@beck.corsepiu.local> On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote: > Hello, > > I understand why rawhide should be frozen at some points, Openly said, I don't understand this. To me, these freezes are a defect in Rel-Eng's procedures, which could easily be overcome, if they wanted to. But, this had been discussed to death, and Rel-Eng made clear, they are not interested in a change - So be it. Ralf From billcrawford1970 at gmail.com Fri Sep 26 10:55:24 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 26 Sep 2008 11:55:24 +0100 Subject: Do we care about /sbin /bin linked to /usr/lib ? In-Reply-To: <48DC34B4.9080407@redhat.com> References: <200809251328.01886.sgrubb@redhat.com> <48DC34B4.9080407@redhat.com> Message-ID: <200809261155.25091.billcrawford1970@gmail.com> On Friday 26 September 2008 02:02:44 Chris Snook wrote: > Steve Grubb wrote: ... > > /bin/rpm uses something in /usr ... > I don't see why the above need to be in /bin or /sbin. It can help in (admittedly quite odd situations) where you need to, say, reinstall grub or a kernel because you broke something ;o) Also, admittedly, in that case, I was able to mount /usr before proceeding, but if the package I'd needed to reinstall was providing "mount" and that was broken ... meh. I know we have rescue disks, but there are still machines without working optical drives. Honestly, there are. Now, adding a "rescue" initrd would halfway help here ... think that thread died now though. From billcrawford1970 at gmail.com Fri Sep 26 10:48:37 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 26 Sep 2008 11:48:37 +0100 Subject: please deactivate services by default! In-Reply-To: <20080925223311.GC1517148@hiwaay.net> References: <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080925223311.GC1517148@hiwaay.net> Message-ID: <200809261148.37156.billcrawford1970@gmail.com> On Thursday 25 September 2008 23:33:12 Chris Adams wrote: > I think a part of the startup hit is from rebuilding aliases > unconditionally. That should be considered a bug and removed from the > sendmail init script (or at least changed to check if aliases is newer > than aliases.db before calling). if [ aliases -nt aliases.db ]; then ... fi From pertusus at free.fr Fri Sep 26 11:26:43 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 26 Sep 2008 13:26:43 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <1222425353.3564.248.camel@beck.corsepiu.local> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> Message-ID: <20080926112643.GA25473@free.fr> On Fri, Sep 26, 2008 at 12:35:53PM +0200, Ralf Corsepius wrote: > On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote: > > Hello, > > > > I understand why rawhide should be frozen at some points, > Openly said, I don't understand this. To me, these freezes are a defect > in Rel-Eng's procedures, which could easily be overcome, if they wanted > to. Indeed, I think that rawhide should not be frozen, only the beta, which would have specific package changes pushed instead of the reverse. -- Pat From jnovy at redhat.com Fri Sep 26 11:50:55 2008 From: jnovy at redhat.com (Jindrich Novy) Date: Fri, 26 Sep 2008 13:50:55 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <20080926091109.GF3149@free.fr> References: <20080926091109.GF3149@free.fr> Message-ID: <20080926115055.GB11932@dhcp-lab-186.brq.redhat.com> Hi, On Fri, Sep 26, 2008 at 11:11:09AM +0200, Patrice Dumas wrote: > Hello, > > I understand why rawhide should be frozen at some points, but sometime > there is a package one really wants, that is built in koji, but not > available in rawhide because it is frozen. In my case, for example, > rpm-build is broken but aleady fixed. So maybe it would be worth having > a special repo that would not be enabled, but that would allow to have > the latest builds during a beta freeze. In my opinion this repo should > also be used for Matt rebuilds since there are alot of already fixed FTBS > in his reports due to the freeze, which is a bit annoying. > Just mailed rel-eng guys if it's possible to move the new rpm to beta. Jindrich > -- > Pat > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Jindrich Novy http://people.redhat.com/jnovy/ From jwboyer at gmail.com Fri Sep 26 12:02:25 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 26 Sep 2008 08:02:25 -0400 Subject: unfrozen repo somewhere? In-Reply-To: <20080926112643.GA25473@free.fr> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <20080926112643.GA25473@free.fr> Message-ID: <20080926120225.GA2185@yoda.jdub.homelinux.org> On Fri, Sep 26, 2008 at 01:26:43PM +0200, Patrice Dumas wrote: >On Fri, Sep 26, 2008 at 12:35:53PM +0200, Ralf Corsepius wrote: >> On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote: >> > Hello, >> > >> > I understand why rawhide should be frozen at some points, >> Openly said, I don't understand this. To me, these freezes are a defect >> in Rel-Eng's procedures, which could easily be overcome, if they wanted >> to. > >Indeed, I think that rawhide should not be frozen, only the beta, which >would have specific package changes pushed instead of the reverse. Alpha was done that way the past two times. It didn't work out wonderfully. And by the point you get to Beta, you want all your testing focused on a single tree. So having a Beta tree that nobody is testing before Beta release is pretty pointless. That is one of the major reasons for freezing rawhide, so that you get a single tree to test, triage, and focus bug efforts on. josh From jwboyer at gmail.com Fri Sep 26 12:03:45 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 26 Sep 2008 08:03:45 -0400 Subject: unfrozen repo somewhere? In-Reply-To: <20080926091109.GF3149@free.fr> References: <20080926091109.GF3149@free.fr> Message-ID: <20080926120345.GB2185@yoda.jdub.homelinux.org> On Fri, Sep 26, 2008 at 11:11:09AM +0200, Patrice Dumas wrote: >Hello, > >I understand why rawhide should be frozen at some points, but sometime >there is a package one really wants, that is built in koji, but not >available in rawhide because it is frozen. In my case, for example, >rpm-build is broken but aleady fixed. So maybe it would be worth having rpm-build the program is broken? How long has it been broken? Did you file a bug? Did you ask the package maintainer or rel-eng to include the fixed version in the freeze tag? josh From pertusus at free.fr Fri Sep 26 12:12:52 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 26 Sep 2008 14:12:52 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <20080926120345.GB2185@yoda.jdub.homelinux.org> References: <20080926091109.GF3149@free.fr> <20080926120345.GB2185@yoda.jdub.homelinux.org> Message-ID: <20080926121252.GC25473@free.fr> On Fri, Sep 26, 2008 at 08:03:45AM -0400, Josh Boyer wrote: > On Fri, Sep 26, 2008 at 11:11:09AM +0200, Patrice Dumas wrote: > >Hello, > > > rpm-build the program is broken? How long has it been broken? Did you > file a bug? Did you ask the package maintainer or rel-eng to include the > fixed version in the freeze tag? It was just an example... I filled a bug, but it was already fixed (as I said) and looks like Jindrich already asked rel-eng. -- Pat From jwboyer at gmail.com Fri Sep 26 12:18:54 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 26 Sep 2008 08:18:54 -0400 Subject: unfrozen repo somewhere? In-Reply-To: <20080926121252.GC25473@free.fr> References: <20080926091109.GF3149@free.fr> <20080926120345.GB2185@yoda.jdub.homelinux.org> <20080926121252.GC25473@free.fr> Message-ID: <20080926121854.GB2204@yoda.jdub.homelinux.org> On Fri, Sep 26, 2008 at 02:12:52PM +0200, Patrice Dumas wrote: >On Fri, Sep 26, 2008 at 08:03:45AM -0400, Josh Boyer wrote: >> On Fri, Sep 26, 2008 at 11:11:09AM +0200, Patrice Dumas wrote: >> >Hello, >> > >> rpm-build the program is broken? How long has it been broken? Did you >> file a bug? Did you ask the package maintainer or rel-eng to include the >> fixed version in the freeze tag? > >It was just an example... I filled a bug, but it was already fixed (as I >said) and looks like Jindrich already asked rel-eng. Yes. And I made an example of your example. I'm not 100% certain, but I think the Beta is already syncing to the mirrors, so it's quite possible it's too late for Beta. If things are broken in the frozen rawhide, and there are known fixes for them then it is up to the users and developers to get rel-eng to get those fixes pulled in. Rel-eng and QA work really hard at trying to test and bug people for fixes, but there is no possible way for them to test everything. Freezes and releases need participation from both sides in order to work well. josh From jwboyer at gmail.com Fri Sep 26 12:15:06 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 26 Sep 2008 08:15:06 -0400 Subject: unfrozen repo somewhere? In-Reply-To: <20080926115055.GB11932@dhcp-lab-186.brq.redhat.com> References: <20080926091109.GF3149@free.fr> <20080926115055.GB11932@dhcp-lab-186.brq.redhat.com> Message-ID: <20080926121506.GA2204@yoda.jdub.homelinux.org> On Fri, Sep 26, 2008 at 01:50:55PM +0200, Jindrich Novy wrote: >Hi, > >On Fri, Sep 26, 2008 at 11:11:09AM +0200, Patrice Dumas wrote: >> Hello, >> >> I understand why rawhide should be frozen at some points, but sometime >> there is a package one really wants, that is built in koji, but not >> available in rawhide because it is frozen. In my case, for example, >> rpm-build is broken but aleady fixed. So maybe it would be worth having >> a special repo that would not be enabled, but that would allow to have >> the latest builds during a beta freeze. In my opinion this repo should >> also be used for Matt rebuilds since there are alot of already fixed FTBS >> in his reports due to the freeze, which is a bit annoying. >> > >Just mailed rel-eng guys if it's possible to move the new rpm to beta. What email address did you use? I don't see it on the rel-eng list, nor on the trac thing. josh From j.w.r.degoede at hhs.nl Fri Sep 26 12:30:01 2008 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 26 Sep 2008 14:30:01 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <20080926121506.GA2204@yoda.jdub.homelinux.org> References: <20080926091109.GF3149@free.fr> <20080926115055.GB11932@dhcp-lab-186.brq.redhat.com> <20080926121506.GA2204@yoda.jdub.homelinux.org> Message-ID: <48DCD5C9.70302@hhs.nl> Josh Boyer wrote: > On Fri, Sep 26, 2008 at 01:50:55PM +0200, Jindrich Novy wrote: >> Hi, >> >> On Fri, Sep 26, 2008 at 11:11:09AM +0200, Patrice Dumas wrote: >>> Hello, >>> >>> I understand why rawhide should be frozen at some points, but sometime >>> there is a package one really wants, that is built in koji, but not >>> available in rawhide because it is frozen. In my case, for example, >>> rpm-build is broken but aleady fixed. So maybe it would be worth having >>> a special repo that would not be enabled, but that would allow to have >>> the latest builds during a beta freeze. In my opinion this repo should >>> also be used for Matt rebuilds since there are alot of already fixed FTBS >>> in his reports due to the freeze, which is a bit annoying. >>> >> Just mailed rel-eng guys if it's possible to move the new rpm to beta. > > What email address did you use? I don't see it on the rel-eng list, nor on > the trac thing. Thats most likely because rel-eng at fedoraproject.org is broken (it was about a week ago) which I've already reported multiple times but with no result sofar. Regards, hans From pertusus at free.fr Fri Sep 26 12:31:06 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 26 Sep 2008 14:31:06 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <20080926120225.GA2185@yoda.jdub.homelinux.org> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <20080926112643.GA25473@free.fr> <20080926120225.GA2185@yoda.jdub.homelinux.org> Message-ID: <20080926123106.GE25473@free.fr> On Fri, Sep 26, 2008 at 08:02:25AM -0400, Josh Boyer wrote: > > And by the point you get to Beta, you want all your testing focused on a > single tree. So having a Beta tree that nobody is testing before Beta release > is pretty pointless. That is one of the major reasons for freezing rawhide, > so that you get a single tree to test, triage, and focus bug efforts on. I understand that for installs/upgrades using anaconda, thus for images, but for users that track rawhide, being able to test if bugs are fixed without doing a local rebuild is handy. Especially for packages that are not at the core of the distribution. I guess that maybe it isn't very practical, but the frozen packages in rawhide could be a subset of the packages, including everything in the minimal buildroot, in some groups, say @base, @base-x, @code, @fedora-packager, @hardware-support, @input-methods, @legacy-software-development, @legacy-software-support, @printing, @system-tools, and their dependencies, and the kernel (and maybe @admin-tools). -- Pat From pertusus at free.fr Fri Sep 26 12:39:57 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 26 Sep 2008 14:39:57 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <20080926121854.GB2204@yoda.jdub.homelinux.org> References: <20080926091109.GF3149@free.fr> <20080926120345.GB2185@yoda.jdub.homelinux.org> <20080926121252.GC25473@free.fr> <20080926121854.GB2204@yoda.jdub.homelinux.org> Message-ID: <20080926123957.GF25473@free.fr> On Fri, Sep 26, 2008 at 08:18:54AM -0400, Josh Boyer wrote: > > If things are broken in the frozen rawhide, and there are known fixes for them > then it is up to the users and developers to get rel-eng to get those fixes > pulled in. Rel-eng and QA work really hard at trying to test and bug people > for fixes, but there is no possible way for them to test everything. > > Freezes and releases need participation from both sides in order to work well. Maybe rpm-build was a bad example since pushing it to the beta may have been better. However, I won't require a human intervention on many of the packages I use, that have bug fixed during the freeze, because they are niche packages, and don't have (in general) integration issues. And in fedora there are now many of such packages and it is growing very steadily. Looking at my personal case, which is certainly very specific, there are maybe 15 over 125 I watch that should be frozen, in my opinion. -- Pat From choeger at cs.tu-berlin.de Fri Sep 26 12:57:06 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Fri, 26 Sep 2008 14:57:06 +0200 Subject: start setroubleshootd as audisp plugin Message-ID: <1222433826.4546.3.camel@choeger6> Hi, thanks to Steve Grubb I figured out how to make setroubleshootd start as an auditd plugin. with the two files attached (plugin conf and selinux module) it should be a little faster in boot (see attached bootchart). Anyone wants to bring that into the setroubleshoot/audit pkg? regards christoph -------------- next part -------------- A non-text attachment was scrubbed... Name: bootchart.png Type: image/png Size: 184669 bytes Desc: not available URL: -------------- next part -------------- policy_module(auditd-troubled,0.1) gen_require(` type setroubleshootd_exec_t; ') gen_require(` type setroubleshootd_t; ') gen_require(` type audisp_t; ') allow audisp_t setroubleshootd_exec_t:file read_file_perms; allow audisp_t setroubleshootd_exec_t:file execute; domain_auto_trans(audisp_t, setroubleshootd_exec_t, setroubleshootd_t) corecmd_exec_bin(audisp_t) allow setroubleshootd_t audisp_t:unix_stream_socket { ioctl read write }; allow audisp_t setroubleshootd_t:process signal; -------------- next part -------------- active = yes direction = out path = /usr/sbin/setroubleshootd type = always args = -f format = string -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From dbn.lists at gmail.com Fri Sep 26 13:43:11 2008 From: dbn.lists at gmail.com (Dan Nicholson) Date: Fri, 26 Sep 2008 06:43:11 -0700 Subject: Do we care about /sbin /bin linked to /usr/lib ? In-Reply-To: <200809261155.25091.billcrawford1970@gmail.com> References: <200809251328.01886.sgrubb@redhat.com> <48DC34B4.9080407@redhat.com> <200809261155.25091.billcrawford1970@gmail.com> Message-ID: <91705d080809260643q137750a2ja5273810cbc47e2d@mail.gmail.com> On Fri, Sep 26, 2008 at 3:55 AM, Bill Crawford wrote: > On Friday 26 September 2008 02:02:44 Chris Snook wrote: >> Steve Grubb wrote: > ... >> > /bin/rpm uses something in /usr > ... >> I don't see why the above need to be in /bin or /sbin. > > It can help in (admittedly quite odd situations) where you need to, say, > reinstall grub or a kernel because you broke something ;o) Also, admittedly, in > that case, I was able to mount /usr before proceeding On the rpm5 list, Jeff Johnson mentioned that /bin/rpm was just a legacy thing that people expected and has since changed the package to install to $bindir (/usr/bin). Not that that applies here exactly, but making /bin/rpm usable when /usr is not available would require moving a lot of things to /lib. -- Dan From james at fedoraproject.org Fri Sep 26 13:46:25 2008 From: james at fedoraproject.org (James Antill) Date: Fri, 26 Sep 2008 09:46:25 -0400 Subject: Instant Mirror Status...? In-Reply-To: <48DC82A3.9010207@gmail.com> References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> <48D8154B.9080804@students.iiit.ac.in> <16de708d0809221650n27d4cd7djfa4b39e4ad12ff27@mail.gmail.com> <1222128026.4108.46.camel@luminos.localdomain> <16de708d0809221720r3dad221vac4cb255ccc50490@mail.gmail.com> <48D867D8.40304@gmail.com> <1222153299.29561.7.camel@code.and.org> <20080923153346.GA10633@auslistsprd01.us.dell.com> <48DC82A3.9010207@gmail.com> Message-ID: <1222436785.22953.47.camel@code.and.org> On Fri, 2008-09-26 at 01:35 -0500, Les Mikesell wrote: > Alexandre Oliva wrote: > > On Sep 23, 2008, Matt Domsch wrote: > > > >> Furthermore, I absolutely don't want to return the same mirror at the > >> top of the list _for everyone_ in a given country. > > > > Hash MM's "primary" IP address to select one of the various available > > mirrors, assuming they're returned in a consistent order? > > If you are going to return a list of N mirrors, make N copies of that > list, rotating one position for each. Knock the last octet off the > source IP and hash the remaining part with some consistent algorithm > that will give you N values and use that to choose the copy of the list > you send. Which is much harder than it sounds given that MM can't actually "make N copies" of each list of IPs it might send out. But... > Everything is as distributed and robust as before, but you > don't defeat attempts to save your bandwidth with caching proxies. This is _only_ true if you are getting asked for the list from every single IP address, or that the subset of IP addresses you are getting asked from happen to be as random/distributed as what MM does now. You might argue that it'll probably "random/distributed enough", but I find it much easier to believe that the above will solve your problem and you didn't get much further than that in your analysis. -- James Antill Fedora From gnomeuser at gmail.com Fri Sep 26 13:54:59 2008 From: gnomeuser at gmail.com (David Nielsen) Date: Fri, 26 Sep 2008 15:54:59 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <48DCAD54.7060804@ioa.s.u-tokyo.ac.jp> References: <20080926091109.GF3149@free.fr> <48DCAD54.7060804@ioa.s.u-tokyo.ac.jp> Message-ID: <1dedbbfc0809260654k531f4ab1ya040d4911ab33a81@mail.gmail.com> 2008/9/26 Mamoru Tasaka > Patrice Dumas wrote, at 09/26/2008 06:11 PM +9:00: > >> Hello, >> >> I understand why rawhide should be frozen at some points, but sometime >> there is a package one really wants, that is built in koji, but not >> available in rawhide because it is frozen. In my case, for example, >> rpm-build is broken but aleady fixed. So maybe it would be worth having >> a special repo that would not be enabled, but that would allow to have >> the latest builds during a beta freeze. In my opinion this repo should >> also be used for Matt rebuilds since there are alot of already fixed FTBS >> in his reports due to the freeze, which is a bit annoying. >> >> -- >> Pat >> > > I always use a repo file (named fedora-koji.repo) which contains: > --------------------------------------------------------------- > [koji] > name= koji - koji snapshot tree > baseurl= > http://koji.fedoraproject.org/static-repos/dist-f10-build-current/$basearch/ > enabled=1 > gpgcheck=0 > --------------------------------------------------------------- > > And I think fedora-devel-i386.cfg (in mock) has similar lines. Wow, I never knew koji did that, very cool indeed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwboyer at gmail.com Fri Sep 26 13:13:50 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 26 Sep 2008 09:13:50 -0400 Subject: unfrozen repo somewhere? In-Reply-To: <48DCD5C9.70302@hhs.nl> References: <20080926091109.GF3149@free.fr> <20080926115055.GB11932@dhcp-lab-186.brq.redhat.com> <20080926121506.GA2204@yoda.jdub.homelinux.org> <48DCD5C9.70302@hhs.nl> Message-ID: <20080926131350.GA2388@yoda.jdub.homelinux.org> On Fri, Sep 26, 2008 at 02:30:01PM +0200, Hans de Goede wrote: > Josh Boyer wrote: >> On Fri, Sep 26, 2008 at 01:50:55PM +0200, Jindrich Novy wrote: >>> Hi, >>> >>> On Fri, Sep 26, 2008 at 11:11:09AM +0200, Patrice Dumas wrote: >>>> Hello, >>>> >>>> I understand why rawhide should be frozen at some points, but sometime >>>> there is a package one really wants, that is built in koji, but not >>>> available in rawhide because it is frozen. In my case, for example, >>>> rpm-build is broken but aleady fixed. So maybe it would be worth having >>>> a special repo that would not be enabled, but that would allow to have >>>> the latest builds during a beta freeze. In my opinion this repo should >>>> also be used for Matt rebuilds since there are alot of already fixed FTBS >>>> in his reports due to the freeze, which is a bit annoying. >>>> >>> Just mailed rel-eng guys if it's possible to move the new rpm to beta. >> >> What email address did you use? I don't see it on the rel-eng list, nor on >> the trac thing. > > Thats most likely because rel-eng at fedoraproject.org is broken (it was > about a week ago) which I've already reported multiple times but with no > result sofar. https://www.redhat.com/archives/fedora-devel-announce/2008-July/msg00004.html josh From billcrawford1970 at gmail.com Fri Sep 26 14:00:09 2008 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 26 Sep 2008 15:00:09 +0100 Subject: Do we care about /sbin /bin linked to /usr/lib ? In-Reply-To: <91705d080809260643q137750a2ja5273810cbc47e2d@mail.gmail.com> References: <200809251328.01886.sgrubb@redhat.com> <200809261155.25091.billcrawford1970@gmail.com> <91705d080809260643q137750a2ja5273810cbc47e2d@mail.gmail.com> Message-ID: <200809261500.09968.billcrawford1970@gmail.com> On Friday 26 September 2008 14:43:11 Dan Nicholson wrote: > On the rpm5 list, Jeff Johnson mentioned that /bin/rpm was just a > legacy thing that people expected and has since changed the package to > install to $bindir (/usr/bin). Not that that applies here exactly, but > making /bin/rpm usable when /usr is not available would require moving > a lot of things to /lib. Not that big a list, but hardly worth it. Long term, I'll admit that getting rid of separate /usr may be a good idea, Solaris appears to have done away with it a while ago (which surprised me, since they used to make explicit provision for having shared /usr in their package management system). Anyway, there are quite a few situations in which you're basically screwed unless you can run your package manager (and possibly things like ldconfig) so I'd like to add another vote in favour of adding a "create a rescue image" command somewhere ... From james at fedoraproject.org Fri Sep 26 14:15:01 2008 From: james at fedoraproject.org (James Antill) Date: Fri, 26 Sep 2008 10:15:01 -0400 Subject: Yum NFS mounted/shared cache directories? In-Reply-To: <2a28d2ab0809260329m1397766btaea508f660853715@mail.gmail.com> References: <2a28d2ab0809251610u3c07e2b1k5a6ebe12f6ee88be@mail.gmail.com> <1222400146.22953.39.camel@code.and.org> <1222405509.4144.177.camel@rosebud> <2a28d2ab0809260329m1397766btaea508f660853715@mail.gmail.com> Message-ID: <1222438501.22953.59.camel@code.and.org> On Fri, 2008-09-26 at 05:29 -0500, Dr. Diesel wrote: > Any project information on yum-avahi and what it might evolve into? The "current" yum-avahi is at: http://users.ecs.soton.ac.uk/rds204/yum-avahi/ ...AIUI it "works", the problem is that it basically stores extra foo.repo files on the "avahi network" and so any local attacker can override the client machines gpg checking settings etc. So it needs to move to just add the extra local URL at the front of the mirrors list, and probably be cleanedup/spedup a bit. Then there is the design of what it does now: It is designed to present a full mirror to the clients, which isn't that useful. What we'd want is more like "box X already download primary.sqlite and perl, so when you do 'yum update' on box Y get those packages from it". The server part of it also needs some work, so it's integrated into yum-updatesd or something and generally is cleaner/safer. As now you have to run a specific server just for the avahi bits. -- James Antill Fedora From fedora at leemhuis.info Fri Sep 26 14:37:56 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 26 Sep 2008 16:37:56 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <20080926131350.GA2388@yoda.jdub.homelinux.org> References: <20080926091109.GF3149@free.fr> <20080926115055.GB11932@dhcp-lab-186.brq.redhat.com> <20080926121506.GA2204@yoda.jdub.homelinux.org> <48DCD5C9.70302@hhs.nl> <20080926131350.GA2388@yoda.jdub.homelinux.org> Message-ID: <48DCF3C4.5010506@leemhuis.info> On 26.09.2008 15:13, Josh Boyer wrote: > On Fri, Sep 26, 2008 at 02:30:01PM +0200, Hans de Goede wrote: >> Josh Boyer wrote: >>> On Fri, Sep 26, 2008 at 01:50:55PM +0200, Jindrich Novy wrote: >>>> On Fri, Sep 26, 2008 at 11:11:09AM +0200, Patrice Dumas wrote: >>>>> I understand why rawhide should be frozen at some points, but sometime >>>>> there is a package one really wants, that is built in koji, but not >>>>> available in rawhide because it is frozen. In my case, for example, >>>>> rpm-build is broken but aleady fixed. So maybe it would be worth having >>>>> a special repo that would not be enabled, but that would allow to have >>>>> the latest builds during a beta freeze. In my opinion this repo should >>>>> also be used for Matt rebuilds since there are alot of already fixed FTBS >>>>> in his reports due to the freeze, which is a bit annoying. >>>> Just mailed rel-eng guys if it's possible to move the new rpm to beta. >>> What email address did you use? I don't see it on the rel-eng list, nor on >>> the trac thing. >> Thats most likely because rel-eng at fedoraproject.org is broken (it was >> about a week ago) which I've already reported multiple times but with no >> result sofar. > https://www.redhat.com/archives/fedora-devel-announce/2008-July/msg00004.html http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy CU knurd From fedora at leemhuis.info Fri Sep 26 14:44:58 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 26 Sep 2008 16:44:58 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <48DCF3C4.5010506@leemhuis.info> References: <20080926091109.GF3149@free.fr> <20080926115055.GB11932@dhcp-lab-186.brq.redhat.com> <20080926121506.GA2204@yoda.jdub.homelinux.org> <48DCD5C9.70302@hhs.nl> <20080926131350.GA2388@yoda.jdub.homelinux.org> <48DCF3C4.5010506@leemhuis.info> Message-ID: <48DCF56A.2080301@leemhuis.info> On 26.09.2008 16:37, Thorsten Leemhuis wrote: > On 26.09.2008 15:13, Josh Boyer wrote: >> On Fri, Sep 26, 2008 at 02:30:01PM +0200, Hans de Goede wrote: >>> Josh Boyer wrote: >>>> On Fri, Sep 26, 2008 at 01:50:55PM +0200, Jindrich Novy wrote: >>>>> On Fri, Sep 26, 2008 at 11:11:09AM +0200, Patrice Dumas wrote: >>>>>> I understand why rawhide should be frozen at some points, but sometime >>>>>> there is a package one really wants, that is built in koji, but not >>>>>> available in rawhide because it is frozen. In my case, for example, >>>>>> rpm-build is broken but aleady fixed. So maybe it would be worth having >>>>>> a special repo that would not be enabled, but that would allow to have >>>>>> the latest builds during a beta freeze. In my opinion this repo should >>>>>> also be used for Matt rebuilds since there are alot of already fixed FTBS >>>>>> in his reports due to the freeze, which is a bit annoying. >>>>> Just mailed rel-eng guys if it's possible to move the new rpm to beta. >>>> What email address did you use? I don't see it on the rel-eng list, nor on >>>> the trac thing. >>> Thats most likely because rel-eng at fedoraproject.org is broken (it was >>> about a week ago) which I've already reported multiple times but with no >>> result sofar. >> https://www.redhat.com/archives/fedora-devel-announce/2008-July/msg00004.html > http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy Note: Normally I don't send mails that contain just a link, but it seemed the right thing to do here, as the post before that was just a link as well. ;-) What I wanted to say with the link: Do you really expect that everybody can think of each and every mail that is a few weeks old? And: we have a wiki for a reasons, so why didn't rel-eng simply update the page while the problem in question persist? Note that http://www.google.com/search?q=rel-eng%40fedoraproject.org++site%3Afedoraproject.org%2Fwiki%2F&ie=utf-8&oe=utf-8&hl=en&num=100&aq=t finds a few other places that might need updating to prevent further confusion. For example: http://fedoraproject.org/wiki/ReleaseEngineering/FinalFreezePolicy https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy CU knurd From mattdm at mattdm.org Fri Sep 26 14:48:20 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 26 Sep 2008 10:48:20 -0400 Subject: please deactivate services by default! In-Reply-To: <200809261148.37156.billcrawford1970@gmail.com> References: <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080925223311.GC1517148@hiwaay.net> <200809261148.37156.billcrawford1970@gmail.com> Message-ID: <20080926144820.GA30254@jadzia.bu.edu> On Fri, Sep 26, 2008 at 11:48:37AM +0100, Bill Crawford wrote: > > I think a part of the startup hit is from rebuilding aliases > > unconditionally. That should be considered a bug and removed from the > > sendmail init script (or at least changed to check if aliases is newer > > than aliases.db before calling). > if [ aliases -nt aliases.db ]; then > ... > fi What if aliases includes other files? -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs Computing & Information Technology Harvard School of Engineering & Applied Sciences From mattdm at mattdm.org Fri Sep 26 14:50:43 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 26 Sep 2008 10:50:43 -0400 Subject: please deactivate services by default! In-Reply-To: <5256d0b0809260100jc5f100fm51e42fa310981857@mail.gmail.com> References: <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <48DBF2E5.70006@fedoraproject.org> <5256d0b0809251329g44a69287l585bf57bd6b3130c@mail.gmail.com> <1222388483.5130.6.camel@localhost.localdomain> <5256d0b0809260100jc5f100fm51e42fa310981857@mail.gmail.com> Message-ID: <20080926145043.GB30254@jadzia.bu.edu> On Fri, Sep 26, 2008 at 09:00:59AM +0100, Peter Robinson wrote: > > All multi-processor x86_64 machines are NUMA. I'm unclear how this > > applies to multi-core (in one chip) though. Do the cores have > > independent DDR controllers? > I thought numa is a series of computers connected together via a fast > interconnect such as Infiband where they can access each others memory > but accessing local memory is faster than non-local memory. Hence Non > Uniform Memory Access. > http://en.wikipedia.org/wiki/Non-Uniform_Memory_Access That article could use some updating. Modern multi-cpu systems basically use that same model internal to the system. -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs Computing & Information Technology Harvard School of Engineering & Applied Sciences From sgrubb at redhat.com Fri Sep 26 15:13:44 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 26 Sep 2008 11:13:44 -0400 Subject: rpmbuild post install checks Message-ID: <200809261113.44281.sgrubb@redhat.com> Hi, I have tarred up my post install build checks that found the /bin /sbin linked to /usr problems. It can be downloaded from: http://people.redhat.com/sgrubb/files/rpmbuild-checks.tar.gz The tarball has installation instructions in the README file. If any test fails, it stops the build and rpms are not written. I have about 10 checks and would like to add more. I would also like to take any contributions that can look for problems at build time. The intent is to find problems in local builds before pushing it out to Koji for an official build. Comments? -Steve ---------------------- Typical output: ******** Starting special post build checks ******** Checking man page encoding Checking compressed pages... Checking uncompressed pages... No man page encoding problems found Looking for shell script errors Locating executables... Refining list to shell scripts... Examining shell scripts... No problems found Looking for insecure tmp file usage in shell scripts Locating shell scripts... No problems found Looking for exec stack errors No problems found Looking for group writable dirs Scanning /bin ... Scanning /boot ... Scanning /etc ... Scanning /lib ... Scanning /lib64 ... Scanning /sbin ... Scanning /tmp ... Scanning /usr ... Scanning /var/account ... Scanning /var/cache ... Scanning /var/crash ... Scanning /var/db ... Scanning /var/gdm ... Scanning /var/lib ... Scanning /var/local ... Scanning /var/lock ... Scanning /var/nis ... Scanning /var/run ... Scanning /var/tmp ... Scanning /var/www ... Scanning /var/yp ... No problems found Looking for world writable dirs No problems found Looking for world writable files No problems found Looking for files in /bin /sbin linked to something in /usr No problems found Looking for elf files that were somehow not stripped during install No problems found Running /usr/lib/rpm/check-rpaths Running /usr/lib/rpm/check-buildroot ******** Post build checks successfully completed ******** From cmadams at hiwaay.net Fri Sep 26 15:34:35 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 26 Sep 2008 10:34:35 -0500 Subject: Do we care about /sbin /bin linked to /usr/lib ? In-Reply-To: <200809261500.09968.billcrawford1970@gmail.com> References: <200809251328.01886.sgrubb@redhat.com> <200809261155.25091.billcrawford1970@gmail.com> <91705d080809260643q137750a2ja5273810cbc47e2d@mail.gmail.com> <200809261500.09968.billcrawford1970@gmail.com> Message-ID: <20080926153435.GC1338970@hiwaay.net> Once upon a time, Bill Crawford said: > Long term, I'll admit that getting rid of separate /usr may be a good idea, > Solaris appears to have done away with it a while ago (which surprised me, > since they used to make explicit provision for having shared /usr in their > package management system). I use a separate (but not shared) /usr on my servers, and I mount it read-only. My reasoning is that / has to be read-write still for some things (root's home directory, /etc/passwd and /etc/shadow, etc.). I keep a small / that is read-write, but having a good chunk of the installed stuff in /usr mounted read-only makes it a little "safer" (i.e. an attacker would have to remount it to modify it, filesystem corruption is unlikely on a read-only FS, etc.). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From cmadams at hiwaay.net Fri Sep 26 15:37:24 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 26 Sep 2008 10:37:24 -0500 Subject: please deactivate services by default! In-Reply-To: <20080926144820.GA30254@jadzia.bu.edu> References: <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080925223311.GC1517148@hiwaay.net> <200809261148.37156.billcrawford1970@gmail.com> <20080926144820.GA30254@jadzia.bu.edu> Message-ID: <20080926153724.GD1338970@hiwaay.net> Once upon a time, Matthew Miller said: > On Fri, Sep 26, 2008 at 11:48:37AM +0100, Bill Crawford wrote: > > > I think a part of the startup hit is from rebuilding aliases > > > unconditionally. That should be considered a bug and removed from the > > > sendmail init script (or at least changed to check if aliases is newer > > > than aliases.db before calling). > > if [ aliases -nt aliases.db ]; then > > ... > > fi > > What if aliases includes other files? If somebody knows how to reconfigure sendmail for multiple alias files, they really should know that (by default) sendmail requires you to rebuild the aliases file when you make changes. IMHO the same really goes for all the .db files (e.g. virtusertable, mailertable, etc.); the init script really should not be rebuilding anything. Do these people that know about /etc/aliases but not newaliases restart sendmail every time they change /etc/aliases? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jwboyer at gmail.com Fri Sep 26 15:53:00 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 26 Sep 2008 11:53:00 -0400 Subject: unfrozen repo somewhere? In-Reply-To: <48DCF3C4.5010506@leemhuis.info> References: <20080926091109.GF3149@free.fr> <20080926115055.GB11932@dhcp-lab-186.brq.redhat.com> <20080926121506.GA2204@yoda.jdub.homelinux.org> <48DCD5C9.70302@hhs.nl> <20080926131350.GA2388@yoda.jdub.homelinux.org> <48DCF3C4.5010506@leemhuis.info> Message-ID: <20080926155300.GA5864@yoda.jdub.homelinux.org> On Fri, Sep 26, 2008 at 04:37:56PM +0200, Thorsten Leemhuis wrote: >>> Thats most likely because rel-eng at fedoraproject.org is broken (it was >>> about a week ago) which I've already reported multiple times but >>> with no result sofar. >> https://www.redhat.com/archives/fedora-devel-announce/2008-July/msg00004.html > > http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy Touche. If I could figure out a good way to make this a picture, I would post it to failblog.org with the caption "Rel-Eng communication fail". Though I noticed that you didn't fix it while you were there. So now we have both Wiki fail (*gasp* out of date wiki pages!! *gasp*) and community fail. /me goes to fail some more josh From lesmikesell at gmail.com Fri Sep 26 15:35:31 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 26 Sep 2008 10:35:31 -0500 Subject: Instant Mirror Status...? In-Reply-To: <1222436785.22953.47.camel@code.and.org> References: <48D7C4AD.7040308@gnat.ca> <1222100649.12513.71.camel@rosebud> <48D7CE9D.20601@gmail.com> <48D8154B.9080804@students.iiit.ac.in> <16de708d0809221650n27d4cd7djfa4b39e4ad12ff27@mail.gmail.com> <1222128026.4108.46.camel@luminos.localdomain> <16de708d0809221720r3dad221vac4cb255ccc50490@mail.gmail.com> <48D867D8.40304@gmail.com> <1222153299.29561.7.camel@code.and.org> <20080923153346.GA10633@auslistsprd01.us.dell.com> <48DC82A3.9010207@gmail.com> <1222436785.22953.47.camel@code.and.org> Message-ID: <48DD0143.40508@gmail.com> James Antill wrote: > > >>>> Furthermore, I absolutely don't want to return the same mirror at the >>>> top of the list _for everyone_ in a given country. >>> Hash MM's "primary" IP address to select one of the various available >>> mirrors, assuming they're returned in a consistent order? >> If you are going to return a list of N mirrors, make N copies of that >> list, rotating one position for each. Knock the last octet off the >> source IP and hash the remaining part with some consistent algorithm >> that will give you N values and use that to choose the copy of the list >> you send. > > Which is much harder than it sounds given that MM can't actually "make > N copies" of each list of IPs it might send out. But... If you can get the list in a fixed order, you just have to replace the code that randomizes it with something that isn't 'worst-possible-case' for a site with a caching proxy. You could get some improvement simply by setting cache control headers on the list for some reasonable time - but then it is much harder to correct a mistake. >> Everything is as distributed and robust as before, but you >> don't defeat attempts to save your bandwidth with caching proxies. > > This is _only_ true if you are getting asked for the list from every > single IP address, or that the subset of IP addresses you are getting > asked from happen to be as random/distributed as what MM does now. That's up to the hashing algorithm. I'm not an expert, but someone should be able to pick one that can take the first 3 octets of an IP address as input and give an essentially random distribution. For brute force you could convert the address to ascii, md5 it, then take modulo the number of list items as the starting point. There's probably something much more efficient, but that should give you randomness. I'd drop the last octet so clustered proxies in the same class C subnet or behind NAT gateways with multiple public addresses would get the same list. > You might argue that it'll probably "random/distributed enough", but I > find it much easier to believe that the above will solve your problem > and you didn't get much further than that in your analysis. It isn't 'my' problem. It's everyone's problems that the mirrors have to send many times the number of copies that they would if you stop going out of your way to defeat existing caching infrastructure. And I intentionally left the choice of hashing algorithm up to someone who is more familiar with their nature. Personally, I don't think it can get any worse than it is so I'm probably not qualified for the analysis you'd like. As long as you keep giving the whole list, the clients will find something that works even if it isn't optimal. Or maybe yum could look for proxy headers on the response and (optionally) randomize by itself if there are none. -- Les Mikesell lesmikesell at gmail.com From walters at verbum.org Fri Sep 26 16:00:18 2008 From: walters at verbum.org (Colin Walters) Date: Fri, 26 Sep 2008 12:00:18 -0400 Subject: Do we care about /sbin /bin linked to /usr/lib ? In-Reply-To: <20080926153435.GC1338970@hiwaay.net> References: <200809251328.01886.sgrubb@redhat.com> <200809261155.25091.billcrawford1970@gmail.com> <91705d080809260643q137750a2ja5273810cbc47e2d@mail.gmail.com> <200809261500.09968.billcrawford1970@gmail.com> <20080926153435.GC1338970@hiwaay.net> Message-ID: On Fri, Sep 26, 2008 at 11:34 AM, Chris Adams wrote: > Once upon a time, Bill Crawford said: >> Long term, I'll admit that getting rid of separate /usr may be a good idea, >> Solaris appears to have done away with it a while ago (which surprised me, >> since they used to make explicit provision for having shared /usr in their >> package management system). > > I use a separate (but not shared) /usr on my servers, and I mount it > read-only. I suggest using SELinux (if you're not already) instead; it provides far stronger security than messing with the filesystem layout ever can. From sgrubb at redhat.com Fri Sep 26 16:09:26 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 26 Sep 2008 12:09:26 -0400 Subject: Do we care about /sbin /bin linked to /usr/lib ? In-Reply-To: References: <200809251328.01886.sgrubb@redhat.com> <20080926153435.GC1338970@hiwaay.net> Message-ID: <200809261209.26931.sgrubb@redhat.com> On Friday 26 September 2008 12:00:18 Colin Walters wrote: > > I use a separate (but not shared) /usr on my servers, and I mount it > > read-only. > > I suggest using SELinux (if you're not already) instead; it provides > far stronger security than messing with the filesystem layout ever > can. Security should be in layers. But aside from security, this is typically used to prevent accidental overwrites of important files. -Steve From jkeating at redhat.com Fri Sep 26 16:13:03 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 26 Sep 2008 09:13:03 -0700 Subject: unfrozen repo somewhere? In-Reply-To: <20080926123106.GE25473@free.fr> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <20080926112643.GA25473@free.fr> <20080926120225.GA2185@yoda.jdub.homelinux.org> <20080926123106.GE25473@free.fr> Message-ID: <1222445583.4848.21.camel@luminos.localdomain> On Fri, 2008-09-26 at 14:31 +0200, Patrice Dumas wrote: > I understand that for installs/upgrades using anaconda, thus for images, > but for users that track rawhide, being able to test if bugs are fixed > without doing a local rebuild is handy. Especially for packages that are > not at the core of the distribution. I guess that maybe it isn't very > practical, but the frozen packages in rawhide could be a subset of the > packages, including everything in the minimal buildroot, in some groups, > say @base, @base-x, @code, @fedora-packager, @hardware-support, > @input-methods, @legacy-software-development, @legacy-software-support, > @printing, @system-tools, and their dependencies, and the kernel > (and maybe @admin-tools). Not really practical, bound to be wrong. Instead we offer static-repos of the continued package flow for those people who want to bypass any testing of the freeze content. Those repos aren't mirrored just yet, and may be in the future, but with our current resources available, the best way to get things done is to freeze rawhide. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Fri Sep 26 16:14:46 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 26 Sep 2008 09:14:46 -0700 Subject: unfrozen repo somewhere? In-Reply-To: <48DCF3C4.5010506@leemhuis.info> References: <20080926091109.GF3149@free.fr> <20080926115055.GB11932@dhcp-lab-186.brq.redhat.com> <20080926121506.GA2204@yoda.jdub.homelinux.org> <48DCD5C9.70302@hhs.nl> <20080926131350.GA2388@yoda.jdub.homelinux.org> <48DCF3C4.5010506@leemhuis.info> Message-ID: <1222445686.4848.22.camel@luminos.localdomain> On Fri, 2008-09-26 at 16:37 +0200, Thorsten Leemhuis wrote: > > http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy If you knew the page was wrong, why didn't you fix it? Just so that you could point out that we forgot to change a wiki page somewhere? Thanks. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From lesmikesell at gmail.com Fri Sep 26 16:15:10 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 26 Sep 2008 11:15:10 -0500 Subject: please deactivate services by default! In-Reply-To: <20080926144820.GA30254@jadzia.bu.edu> References: <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080925223311.GC1517148@hiwaay.net> <200809261148.37156.billcrawford1970@gmail.com> <20080926144820.GA30254@jadzia.bu.edu> Message-ID: <48DD0A8E.2050806@gmail.com> Matthew Miller wrote: > On Fri, Sep 26, 2008 at 11:48:37AM +0100, Bill Crawford wrote: >>> I think a part of the startup hit is from rebuilding aliases >>> unconditionally. That should be considered a bug and removed from the >>> sendmail init script (or at least changed to check if aliases is newer >>> than aliases.db before calling). >> if [ aliases -nt aliases.db ]; then >> ... >> fi > > What if aliases includes other files? :include: in the expansion is processed at expansion time and changes in those files don't require rebuilding the db. This is handy, for example, to let some user manage a mail group by editing the file that is included. -- Les Mikesell lesmikesell at gmail.com From mw_triad at users.sourceforge.net Fri Sep 26 16:17:40 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 26 Sep 2008 11:17:40 -0500 Subject: please deactivate services by default! In-Reply-To: <20080926083836.GC3149@free.fr> References: <20080925165100.GB3625@free.fr> <48DBC60F.5030104@gmail.com> <20080925202639.GA3831@free.fr> <20080925213114.GC3831@free.fr> <20080926083836.GC3149@free.fr> Message-ID: Patrice Dumas wrote: > 3) we could change the meaning of the /usr/sbin/sendmail provides, and > require that it is the same than mail(local-delivery). In that case > ssmtp could not provide it anymore since it cannot do local delivery. See... that bothers me. Obviously, I have an expectation of working local mail on my system, which apparently means /usr/sbin/sendmail providing that. IMO, a package that does not provide local mail should not provide /usr/sbin/sendmail, because it is /not/ providing equivalent functionality, and is therefore /not/ interchangeable. (Ok, so obviously this is true of most alternatives, but then, I'd argue that non-common functionality should be available through non-common provides, be they files or virtual-provides. Ah, so, I guess that means that if /usr/bin/sendmail isn't guaranteed to do local, then yes, we /do/ need a virtual-provides for that.) I guess the real problem is that certain things (cron, smartctl, logwatch) have an expectation of notification delivery. Historically, this has been provided by local mail. It sounds like you are telling me there is currently no package dependency to ensure this, i.e. I could, if I don't know what I'm doing, switch from sendmail to ssmtp and break cron in the process, and yum/rpm won't tell me I'm doing something bad. > Unless I am wrong cronie is in the default package set, and so it drags > in /usr/sbin/sendmail dependency. If there is no package in the default > set already providing it, exim would be choosen since the shortest name > wins. But maybe there is a package in th edefault set that provides > /usr/sbin/sendmail. If something providing local mail is in the default set, then where did comments like "if there are cron jobs that send mail, we will deactivate them" come from? I keep wondering if this whole thread is a result of people making wrong assumptions, and other people, rather than clarifying, throwing fuel onto the fire instead. (And yeah, I'm part of it, but I'm operating from ignorance; it's the people that know better and aren't stepping in to correct the errors that I'd be annoyed with.) > Well, my opinion is that how reliable the /usr/sbin/sendmail is should > be left to the user installing it, or to the default /usr/sbin/sendmail > provider decision and not be tight to the previous use case. If something is added to firstboot, that's fine. Then it's on the user's head if they mess it up. I still feel that providers shouldn't go making things worse than before. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "Who wants to sing?" -- Orcs (Warcraft II) From dr.diesel at gmail.com Fri Sep 26 16:42:11 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 26 Sep 2008 11:42:11 -0500 Subject: Yum NFS mounted/shared cache directories? In-Reply-To: <1222400146.22953.39.camel@code.and.org> References: <2a28d2ab0809251610u3c07e2b1k5a6ebe12f6ee88be@mail.gmail.com> <1222400146.22953.39.camel@code.and.org> Message-ID: <2a28d2ab0809260942k67783de9xddf636c41193fb91@mail.gmail.com> 2008/9/25 James Antill > > What verison? > What does strace say yum is doing? > Ran strace on the yum PID, left it since this morning, not a single thread of activity! -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at leemhuis.info Fri Sep 26 16:44:08 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 26 Sep 2008 18:44:08 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <1222445686.4848.22.camel@luminos.localdomain> References: <20080926091109.GF3149@free.fr> <20080926115055.GB11932@dhcp-lab-186.brq.redhat.com> <20080926121506.GA2204@yoda.jdub.homelinux.org> <48DCD5C9.70302@hhs.nl> <20080926131350.GA2388@yoda.jdub.homelinux.org> <48DCF3C4.5010506@leemhuis.info> <1222445686.4848.22.camel@luminos.localdomain> Message-ID: <48DD1158.8040407@leemhuis.info> On 26.09.2008 18:14, Jesse Keating wrote: > On Fri, 2008-09-26 at 16:37 +0200, Thorsten Leemhuis wrote: >> http://fedoraproject.org/wiki/ReleaseEngineering/DevelFreezePolicy > If you knew the page was wrong, why didn't you fix it? - I'm not in rel-eng, thus -- I was unsure how to best fix it, as "mail rel-eng@" is used on multiple pages in the wiki; creating a dedicated "how to contact rel-eng" page seemed and seems like the best to me, but that is more than a small change thus someone from rel-eng should do it or ACK it -- I don't know anything about the issue in question besides what is written in the (quite old) mail jwb pointed to. Thus I'm didn't feel familiar with the issue enough to do changes as those easily might have been wrong or obsolete just a few minutes later in case someone enabls the mail-> trac gateway again - I just had hit the "log-out" button in the time-tracking system at work one or two minutes earlier and send the mail right before driving home > Just so that you could point out that we forgot to change a s/a/multiple/ afaics > wiki page somewhere? Yes, indeed -- and at the same time it was also a nitpick to the mail style jwb used. Jwb got the message and responded in a nice way I really liked. The other reply I got was just a reminder for one of the reasons why I'm contributing a whole lot less to the Fedora project these days then one or two years ago. CU knurd From jkeating at redhat.com Fri Sep 26 17:03:47 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 26 Sep 2008 10:03:47 -0700 Subject: unfrozen repo somewhere? In-Reply-To: <48DD1158.8040407@leemhuis.info> References: <20080926091109.GF3149@free.fr> <20080926115055.GB11932@dhcp-lab-186.brq.redhat.com> <20080926121506.GA2204@yoda.jdub.homelinux.org> <48DCD5C9.70302@hhs.nl> <20080926131350.GA2388@yoda.jdub.homelinux.org> <48DCF3C4.5010506@leemhuis.info> <1222445686.4848.22.camel@luminos.localdomain> <48DD1158.8040407@leemhuis.info> Message-ID: <1222448627.4848.23.camel@luminos.localdomain> On Fri, 2008-09-26 at 18:44 +0200, Thorsten Leemhuis wrote: > > - I'm not in rel-eng, thus > > -- I was unsure how to best fix it, as "mail rel-eng@" is used on > multiple pages in the wiki; creating a dedicated "how to contact > rel-eng" page seemed and seems like the best to me, but that is more > than a small change thus someone from rel-eng should do it or ACK it > > -- I don't know anything about the issue in question besides what is > written in the (quite old) mail jwb pointed to. Thus I'm didn't feel > familiar with the issue enough to do changes as those easily might have > been wrong or obsolete just a few minutes later in case someone enabls > the mail-> trac gateway again > > - I just had hit the "log-out" button in the time-tracking system at > work one or two minutes earlier and send the mail right before driving home See, a mail like this, to rel-eng, or the the devel mailing list, would have sufficed. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Fri Sep 26 17:32:20 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 26 Sep 2008 19:32:20 +0200 Subject: make mail go somewhere by default [was Re: please deactivate services by default!] In-Reply-To: References: <20080924212236.GJ1414283@hiwaay.net> <645d17210809241547l16deec88g5bcc786aede32913@mail.gmail.com> <20080924230129.GB29113@free.fr> <1222299566.1895.0.camel@luminos.localdomain> <20080925192952.GC2504@jadzia.bu.edu> <48DBED58.3040307@gmail.com> <48DBF3F5.3080806@redhat.com> <3170f42f0809251337r91f85bavf7f581e1540cd80@mail.gmail.com> Message-ID: <1222450340.1303.2.camel@arekh.okg> Le jeudi 25 septembre 2008 ? 16:43 -0400, Colin Walters a ?crit : > On Thu, Sep 25, 2008 at 4:37 PM, Debarshi Ray wrote: > > Just hit upon gnubiff. What do you think of it? Can we get it to > > notify users who don't use the ttys about mail? I have never used it > > myself, so I am not sure. > > No, we're not going to install biff by default on the desktop - aside > from custom cron jobs there is no reason for the default OS to be > generating email. Things like smartctl should be integrated with HAL > and generally be handled the same way e.g. the low disk space > notification works now. But they are not right now, aren't they? Some of those things protect from data failure. Are we going to dump the old airbag system in the hope than someday another one will materialise and no one will have any accident in the meanwhile? -- 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 cmadams at hiwaay.net Fri Sep 26 17:32:17 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 26 Sep 2008 12:32:17 -0500 Subject: Do we care about /sbin /bin linked to /usr/lib ? In-Reply-To: References: <200809251328.01886.sgrubb@redhat.com> <200809261155.25091.billcrawford1970@gmail.com> <91705d080809260643q137750a2ja5273810cbc47e2d@mail.gmail.com> <200809261500.09968.billcrawford1970@gmail.com> <20080926153435.GC1338970@hiwaay.net> Message-ID: <20080926173217.GE1338970@hiwaay.net> Once upon a time, Colin Walters said: > On Fri, Sep 26, 2008 at 11:34 AM, Chris Adams wrote: > > I use a separate (but not shared) /usr on my servers, and I mount it > > read-only. > > I suggest using SELinux (if you're not already) instead; it provides > far stronger security than messing with the filesystem layout ever > can. Since you snipped my reasons, can you explain how SELinux protects against accidental filesystem corruption? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From david at hlacik.eu Fri Sep 26 17:34:21 2008 From: david at hlacik.eu (=?ISO-8859-2?Q?David_Hl=E1=E8ik?=) Date: Fri, 26 Sep 2008 19:34:21 +0200 Subject: still no progress with opengl video problems? Message-ID: Hello guys, so far i was solving problems with opengl video output with ATI binary drivers & compiz turned on Fedora 9. Videos are blinking . As i was informed, problem can not be solved. It is becouse bug is on ATI driver side? Thanks! David From bruno at wolff.to Fri Sep 26 17:56:16 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 26 Sep 2008 12:56:16 -0500 Subject: unfrozen repo somewhere? In-Reply-To: <1222445583.4848.21.camel@luminos.localdomain> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <20080926112643.GA25473@free.fr> <20080926120225.GA2185@yoda.jdub.homelinux.org> <20080926123106.GE25473@free.fr> <1222445583.4848.21.camel@luminos.localdomain> Message-ID: <20080926175616.GA17173@wolff.to> On Fri, Sep 26, 2008 at 09:13:03 -0700, Jesse Keating wrote: > > Instead we offer static-repos of the continued package flow for those > people who want to bypass any testing of the freeze content. Those > repos aren't mirrored just yet, and may be in the future, but with our > current resources available, the best way to get things done is to > freeze rawhide. This would be nice. When not at a point where I am testing installs, I prefer to keep following rawhide as it helps testing possible fixes to problems I am having. I have something working to get this stuff now, but would prefer to be pulling from mirrors. From jkeating at redhat.com Fri Sep 26 17:59:45 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 26 Sep 2008 10:59:45 -0700 Subject: unfrozen repo somewhere? In-Reply-To: <20080926175616.GA17173@wolff.to> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <20080926112643.GA25473@free.fr> <20080926120225.GA2185@yoda.jdub.homelinux.org> <20080926123106.GE25473@free.fr> <1222445583.4848.21.camel@luminos.localdomain> <20080926175616.GA17173@wolff.to> Message-ID: <1222451985.4848.25.camel@luminos.localdomain> On Fri, 2008-09-26 at 12:56 -0500, Bruno Wolff III wrote: > I have something working to get this stuff now, but would prefer to be pulling > from mirrors. Unfortunately these repos A) change on an hourly basis, depending on builds done in the tags, and B) are not multilib. It makes them somewhat less desirable for mass consumption and mirroring. What we may eventually do is compose out two rawhide like trees during freezes. One that is the freeze content, another that is the unfrozen content. The logistics of this haven't been explored too much, mostly due to lack of resources to realize it. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dominik at greysector.net Fri Sep 26 18:30:01 2008 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 26 Sep 2008 20:30:01 +0200 Subject: Fedora rawhide rebuild in mock status 2008-09-23 i386 In-Reply-To: <20080924122147.GA4137@mock.linuxdev.us.dell.com> References: <20080924122147.GA4137@mock.linuxdev.us.dell.com> Message-ID: <20080926183000.GA21429@mokona.greysector.net> On Wednesday, 24 September 2008 at 14:21, Matt Domsch wrote: > Fedora Rawhide-in-Mock Build Results for i386 > using the rawhide tree of Tuesday, 2008-10-23. [...] > Of those expected to have worked... > Without a bug filed: 260 > ---------------------------------- [...] > tachyon-0.98-0.6.20070319.fc9 (build/make) rathann Fixed. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From naheemzaffar at gmail.com Fri Sep 26 18:38:26 2008 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Fri, 26 Sep 2008 19:38:26 +0100 Subject: still no progress with opengl video problems? In-Reply-To: References: Message-ID: <3adc77210809261138n9b43afaw575b87ad4efd475b@mail.gmail.com> By "Binary Drivers" do you mean fglrx? If so = no help (and from what I understand to even use them you have to downgrade half the distro to F8 versions...). If your card is an R5xx or less, try giving the radeon driver another try - that has since gained 3d and Xv support for R5XX class cards. 2008/9/26 David Hl??ik : > Hello guys, > > so far i was solving problems with opengl video output with ATI binary > drivers & compiz turned on Fedora 9. Videos are blinking . > As i was informed, problem can not be solved. It is becouse bug is on > ATI driver side? > > Thanks! > > David > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From mw_triad at users.sourceforge.net Fri Sep 26 19:21:07 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Fri, 26 Sep 2008 14:21:07 -0500 Subject: please deactivate services by default! In-Reply-To: <48DBF905.4050501@fedoraproject.org> References: <1222287197.3941.7.camel@choeger6> <48DB7D53.6080507@hi.is> <1222346004.3941.24.camel@choeger6> <48DB8AAF.2070203@hi.is> <1222347870.3941.28.camel@choeger6> <48DB9173.8050508@fedoraproject.org> <20080925143635.GF1126464@hiwaay.net> <20080925180936.GM1126464@hiwaay.net> <48DBF905.4050501@fedoraproject.org> Message-ID: Rahul Sundaram wrote: > Matthew Woehlke wrote: >> Ok. Eh, so I'm confused, an account with "no" password just cannot be >> logged into at all, I thought? (Except via methods that wouldn't use >> password authentication, e.g. key-based authentication as mentioned >> above, 'su' as root...) I wouldn't expect an ssh setting for that, I'd >> expect it to simply be denied :-). > > It is not just root. The default user has no password in the live cd > either. I guess I am confused. Ubuntu disables root, I thought by giving no password to root. The livecd obviously should have "no password", but does that mean unset, or empty? (If unset, does unset have a different effect on root than normal accounts?) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- "Who wants to sing?" -- Orcs (Warcraft II) From sundaram at fedoraproject.org Fri Sep 26 19:32:31 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 27 Sep 2008 01:02:31 +0530 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <48DB7D53.6080507@hi.is> <1222346004.3941.24.camel@choeger6> <48DB8AAF.2070203@hi.is> <1222347870.3941.28.camel@choeger6> <48DB9173.8050508@fedoraproject.org> <20080925143635.GF1126464@hiwaay.net> <20080925180936.GM1126464@hiwaay.net> <48DBF905.4050501@fedoraproject.org> Message-ID: <48DD38CF.6050900@fedoraproject.org> Matthew Woehlke wrote: > I guess I am confused. Ubuntu disables root, I thought by giving no > password to root. They don't enable sshd by default either iirc. The livecd obviously should have "no password", but > does that mean unset, or empty? (If unset, does unset have a different > effect on root than normal accounts?) sshd by default on a live cd is not desirable in either case. More remote services enabled by default always opens the possibility for security issues. Besides the kickstart files are often used as a template for further customization so minimal amount of services enabled is a plus. If you have more questions, feel free to test the live cd or look at the kickstart files for details: https://fedorahosted.org/spin-kickstarts Rahul From jwboyer at gmail.com Fri Sep 26 19:41:32 2008 From: jwboyer at gmail.com (Josh Boyer) Date: Fri, 26 Sep 2008 15:41:32 -0400 Subject: unfrozen repo somewhere? In-Reply-To: <20080926123106.GE25473@free.fr> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <20080926112643.GA25473@free.fr> <20080926120225.GA2185@yoda.jdub.homelinux.org> <20080926123106.GE25473@free.fr> Message-ID: <20080926194132.GC5864@yoda.jdub.homelinux.org> On Fri, Sep 26, 2008 at 02:31:06PM +0200, Patrice Dumas wrote: >On Fri, Sep 26, 2008 at 08:02:25AM -0400, Josh Boyer wrote: >> >> And by the point you get to Beta, you want all your testing focused on a >> single tree. So having a Beta tree that nobody is testing before Beta release >> is pretty pointless. That is one of the major reasons for freezing rawhide, >> so that you get a single tree to test, triage, and focus bug efforts on. > >I understand that for installs/upgrades using anaconda, thus for images, >but for users that track rawhide, being able to test if bugs are fixed >without doing a local rebuild is handy. Especially for packages that are >not at the core of the distribution. I guess that maybe it isn't very >practical, but the frozen packages in rawhide could be a subset of the >packages, including everything in the minimal buildroot, in some groups, >say @base, @base-x, @code, @fedora-packager, @hardware-support, >@input-methods, @legacy-software-development, @legacy-software-support, >@printing, @system-tools, and their dependencies, and the kernel >(and maybe @admin-tools). So now you've sort of separated the packages in Fedora into a "Core" set, and then an "Extras" set. Each set would have different rules around release time, and probably for updates and such too. Oh wait... that sounds like Fedora Core and Fedora Extras. josh From fedora at camperquake.de Fri Sep 26 20:09:51 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 26 Sep 2008 22:09:51 +0200 Subject: please deactivate services by default! In-Reply-To: <200809251038.34508.billcrawford1970@gmail.com> References: <1222287197.3941.7.camel@choeger6> <20080924213834.GM1414283@hiwaay.net> <200809251038.34508.billcrawford1970@gmail.com> Message-ID: <20080926220951.4476e7f1@lain.camperquake.de> Hi. On Thu, 25 Sep 2008 10:38:34 +0100, Bill Crawford wrote > Surely the SMTP server isn't absolutely required to be on localhost? > I never send any mail via localhost SMTP, it's all done through my > company's mail servers or the Google ones for personal mail. Unfortunately, sendmail isn't just a program, it's an API. Calling /usr/lib/sendmail has been the way to get mail out (whereever out is) in UNIX for, well, as long as sendmail exists, which is quite some time. That does not mean that it has to be "the" sendmail, of course. Oh, and LSB requires that it's there. From bruno at wolff.to Fri Sep 26 20:24:22 2008 From: bruno at wolff.to (Bruno Wolff III) Date: Fri, 26 Sep 2008 15:24:22 -0500 Subject: unfrozen repo somewhere? In-Reply-To: <1222451985.4848.25.camel@luminos.localdomain> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <20080926112643.GA25473@free.fr> <20080926120225.GA2185@yoda.jdub.homelinux.org> <20080926123106.GE25473@free.fr> <1222445583.4848.21.camel@luminos.localdomain> <20080926175616.GA17173@wolff.to> <1222451985.4848.25.camel@luminos.localdomain> Message-ID: <20080926202422.GA14107@wolff.to> On Fri, Sep 26, 2008 at 10:59:45 -0700, Jesse Keating wrote: > On Fri, 2008-09-26 at 12:56 -0500, Bruno Wolff III wrote: > > I have something working to get this stuff now, but would prefer to be pulling > > from mirrors. > > Unfortunately these repos A) change on an hourly basis, depending on > builds done in the tags, and B) are not multilib. It makes them > somewhat less desirable for mass consumption and mirroring. Even mirrors of the rpms could be useful. My current process involves grabbing rpms that aren't in the latest rawhide and creating repo information on my end. I am experimenting with a hack for multilib that doesn't pull in the same mix as mash does. Currently I am using 'provides' information. If I really want everything that is i386 specific I need to look at the files, but that would be slower and I haven't actually needed the missing stuff yet. > What we may eventually do is compose out two rawhide like trees during > freezes. One that is the freeze content, another that is the unfrozen > content. The logistics of this haven't been explored too much, mostly > due to lack of resources to realize it. This sounds like a good idea if you get the people time and mirrors are OK with carrying it. It also hurt that this time around the beta freeze was especially long. From opensource at till.name Fri Sep 26 20:26:29 2008 From: opensource at till.name (Till Maas) Date: Fri, 26 Sep 2008 22:26:29 +0200 Subject: Creating a core dump / backtrace from /bin/login Message-ID: <200809262226.38192.opensource@till.name> Hiyas, pam_mount is crashing /bin/login under special circumstances when I login via a text console and I would like to get a backtrace. In a recent thread using a core dump was suggested for a crashing window manager, but it was needed to run a "ulimit -c unlimited" or similiar to get the core dump in the shell before the window manager is started. But how can I do this for /bin/login? Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From lesmikesell at gmail.com Fri Sep 26 20:56:48 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Fri, 26 Sep 2008 15:56:48 -0500 Subject: please deactivate services by default! In-Reply-To: <20080926220951.4476e7f1@lain.camperquake.de> References: <1222287197.3941.7.camel@choeger6> <20080924213834.GM1414283@hiwaay.net> <200809251038.34508.billcrawford1970@gmail.com> <20080926220951.4476e7f1@lain.camperquake.de> Message-ID: <48DD4C90.8080608@gmail.com> Ralf Ertzinger wrote: > Hi. > > On Thu, 25 Sep 2008 10:38:34 +0100, Bill Crawford wrote > >> Surely the SMTP server isn't absolutely required to be on localhost? >> I never send any mail via localhost SMTP, it's all done through my >> company's mail servers or the Google ones for personal mail. > > Unfortunately, sendmail isn't just a program, it's an API. Calling > /usr/lib/sendmail has been the way to get mail out (whereever out > is) in UNIX for, well, as long as sendmail exists, which is quite some > time. Yes, it seems odd that it bothers someone now when computers are orders of magnitude faster than when this scheme was designed. > That does not mean that it has to be "the" sendmail, of course. > > Oh, and LSB requires that it's there. Postfix is probably the only alternative that has all of the expected functionality, but really the effort should be focused on the only real issue here which is that starting the daemon can cause a visible delay at boot time - and there are several easy fixes for that. -- Les Mikesell lesmikesell at gmail.com From pemboa at gmail.com Fri Sep 26 21:20:54 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 26 Sep 2008 16:20:54 -0500 Subject: please deactivate services by default! In-Reply-To: <48DD4C90.8080608@gmail.com> References: <1222287197.3941.7.camel@choeger6> <20080924213834.GM1414283@hiwaay.net> <200809251038.34508.billcrawford1970@gmail.com> <20080926220951.4476e7f1@lain.camperquake.de> <48DD4C90.8080608@gmail.com> Message-ID: <16de708d0809261420m61f5a463ma570da78ac8febc9@mail.gmail.com> On Fri, Sep 26, 2008 at 3:56 PM, Les Mikesell wrote: > Ralf Ertzinger wrote: >> >> Hi. >> >> On Thu, 25 Sep 2008 10:38:34 +0100, Bill Crawford wrote >> >>> Surely the SMTP server isn't absolutely required to be on localhost? >>> I never send any mail via localhost SMTP, it's all done through my >>> company's mail servers or the Google ones for personal mail. >> >> Unfortunately, sendmail isn't just a program, it's an API. Calling >> /usr/lib/sendmail has been the way to get mail out (whereever out >> is) in UNIX for, well, as long as sendmail exists, which is quite some >> time. > > Yes, it seems odd that it bothers someone now when computers are orders of > magnitude faster than when this scheme was designed. > >> That does not mean that it has to be "the" sendmail, of course. >> >> Oh, and LSB requires that it's there. > > Postfix is probably the only alternative that has all of the expected > functionality, but really the effort should be focused on the only real > issue here which is that starting the daemon can cause a visible delay at > boot time - and there are several easy fixes for that. Seems like doing an IO heavy task like this will no longer be much of an issue with a parallel init type startup. -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From pertusus at free.fr Fri Sep 26 21:32:45 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 26 Sep 2008 23:32:45 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <20080926155300.GA5864@yoda.jdub.homelinux.org> References: <20080926091109.GF3149@free.fr> <20080926115055.GB11932@dhcp-lab-186.brq.redhat.com> <20080926121506.GA2204@yoda.jdub.homelinux.org> <48DCD5C9.70302@hhs.nl> <20080926131350.GA2388@yoda.jdub.homelinux.org> <48DCF3C4.5010506@leemhuis.info> <20080926155300.GA5864@yoda.jdub.homelinux.org> Message-ID: <20080926213245.GB3058@free.fr> On Fri, Sep 26, 2008 at 11:53:00AM -0400, Josh Boyer wrote: > > Though I noticed that you didn't fix it while you were there. So now we have > both Wiki fail (*gasp* out of date wiki pages!! *gasp*) and community fail. Thorsten already answered, but I think this is a fundamental error to think that a wiki means that everybody should change everywhere. It is very important that people restrict themselves to their areas of expertise. That being said, community members can help with the wiki ioutside of their area of expertise, but only under the guidance of somebody who knows. So I am not sure it is failure here. -- Pat From jkeating at redhat.com Fri Sep 26 21:55:39 2008 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 26 Sep 2008 14:55:39 -0700 Subject: unfrozen repo somewhere? In-Reply-To: <20080926213245.GB3058@free.fr> References: <20080926091109.GF3149@free.fr> <20080926115055.GB11932@dhcp-lab-186.brq.redhat.com> <20080926121506.GA2204@yoda.jdub.homelinux.org> <48DCD5C9.70302@hhs.nl> <20080926131350.GA2388@yoda.jdub.homelinux.org> <48DCF3C4.5010506@leemhuis.info> <20080926155300.GA5864@yoda.jdub.homelinux.org> <20080926213245.GB3058@free.fr> Message-ID: <1222466139.4848.33.camel@luminos.localdomain> On Fri, 2008-09-26 at 23:32 +0200, Patrice Dumas wrote: > Thorsten already answered, but I think this is a fundamental error to > think that a wiki means that everybody should change everywhere. It is > very important that people restrict themselves to their areas of > expertise. That being said, community members can help with the wiki > ioutside of their area of expertise, but only under the guidance of > somebody who knows. The "community" (aren't we all community?) doesn't have to edit it. However if they notice that it's wrong, they could bring it to the attention of the group who "owns" those pages. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From pertusus at free.fr Fri Sep 26 21:28:38 2008 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 26 Sep 2008 23:28:38 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <20080926194132.GC5864@yoda.jdub.homelinux.org> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <20080926112643.GA25473@free.fr> <20080926120225.GA2185@yoda.jdub.homelinux.org> <20080926123106.GE25473@free.fr> <20080926194132.GC5864@yoda.jdub.homelinux.org> Message-ID: <20080926212838.GA3058@free.fr> On Fri, Sep 26, 2008 at 03:41:32PM -0400, Josh Boyer wrote: > > So now you've sort of separated the packages in Fedora into a "Core" set, and > then an "Extras" set. Each set would have different rules around release > time, and probably for updates and such too. > > Oh wait... that sounds like Fedora Core and Fedora Extras. No. The difference between Core and Extras was a different set of people and responsibilities, and different repos. Moreover in core there was many things that are not listed in my list, like clients, desktop apps and so on. This is a fundamentaly different distinction. Everything on my list corresponds, however, with things that were in Core. Here I wanted to separate the things that should be stable in freeze which make the base of the OS, and apps whose changes won't disturb too much other apps that are on top of those base apps but don't have much interdependencies (except within bounded groups). -- Pat From tcallawa at redhat.com Fri Sep 26 22:10:36 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 26 Sep 2008 18:10:36 -0400 Subject: Fedora rawhide rebuild in mock status 2008-09-23 i386 In-Reply-To: <20080924122147.GA4137@mock.linuxdev.us.dell.com> References: <20080924122147.GA4137@mock.linuxdev.us.dell.com> Message-ID: <1222467036.3969.380.camel@localhost.localdomain> On Wed, 2008-09-24 at 07:21 -0500, Matt Domsch wrote: > a2ps-4.14-5.fc10 (patch_fuzz) twaugh,pertusus Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=64150 > abiword-2.6.4-7.fc10 (build/make) uwog Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=64396 > aide-0.13.1-4 (patch_fuzz) sgrubb Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=64395 > akode-2.0.2-5.fc9 (patch_fuzz) rdieter,tuxbrewr Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=64409 > ale-0.9.0.1-1.fc10 (patch_fuzz) silfreed Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=64137 > alienarena-7.10-1.fc10 (patch_fuzz) spot Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=64411 > alsa-firmware-1.0.17-1.fc10 (build/make) timj Bugzilla 463809. > amanith-0.3-9.fc9 (patch_fuzz) spot Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=64416 > anacron-2.3-61.fc10 (patch_fuzz) mmaslano Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=63961 > archivemail-0.7.2-1.fc9 (patch_fuzz) limb Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=62909 > ardour-2.4.1-1.fc9 (patch_fuzz) green,jwrdegoede Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=63692 > arpack-2.1-7.fc9 (build/make) athimm Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=64311 > astyle-1.21-6.fc8 (build/make) rishi,mtasaka Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=64033 > asylum-0.2.3-3.fc9 (build/make) mfleming Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=64429 > autoconf-2.62-5.fc10 (patch_fuzz) karsten Fixed: http://koji.fedoraproject.org/koji/buildinfo?buildID=63419 From jreiser at BitWagon.com Fri Sep 26 22:12:00 2008 From: jreiser at BitWagon.com (John Reiser) Date: Fri, 26 Sep 2008 15:12:00 -0700 Subject: Creating a core dump / backtrace from /bin/login In-Reply-To: <200809262226.38192.opensource@till.name> References: <200809262226.38192.opensource@till.name> Message-ID: <48DD5E30.4060707@BitWagon.com> > How can I set ulimits for /bin/login? For a general program: wrap the program in a shell script. Move the program to a new name somewhere else, then put a script at the original name: #! /bin/bash ulimit -c unlimited exec /path/to/new/name/of/original/program "$@" For the case of /bin/login, perhaps there will be problems with the initial environment; see INVOCATION in "man bash". Therefore, wrap /bin/login in a short C program which calls setrlimit(3) then exec*() the original 'login' which has been moved to a different location. Beware the security implications due to running under setuid(), etc. -- From pertusus at free.fr Fri Sep 26 22:13:32 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 27 Sep 2008 00:13:32 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <1222466139.4848.33.camel@luminos.localdomain> References: <20080926091109.GF3149@free.fr> <20080926115055.GB11932@dhcp-lab-186.brq.redhat.com> <20080926121506.GA2204@yoda.jdub.homelinux.org> <48DCD5C9.70302@hhs.nl> <20080926131350.GA2388@yoda.jdub.homelinux.org> <48DCF3C4.5010506@leemhuis.info> <20080926155300.GA5864@yoda.jdub.homelinux.org> <20080926213245.GB3058@free.fr> <1222466139.4848.33.camel@luminos.localdomain> Message-ID: <20080926221332.GC3058@free.fr> On Fri, Sep 26, 2008 at 02:55:39PM -0700, Jesse Keating wrote: > > The "community" (aren't we all community?) doesn't have to edit it. > However if they notice that it's wrong, they could bring it to the > attention of the group who "owns" those pages. Agreed. -- Pat From dr.diesel at gmail.com Fri Sep 26 22:15:15 2008 From: dr.diesel at gmail.com (Dr. Diesel) Date: Fri, 26 Sep 2008 18:15:15 -0400 Subject: Yum NFS mounted/shared cache directories? In-Reply-To: <1222405509.4144.177.camel@rosebud> References: <2a28d2ab0809251610u3c07e2b1k5a6ebe12f6ee88be@mail.gmail.com> <1222400146.22953.39.camel@code.and.org> <1222405509.4144.177.camel@rosebud> Message-ID: <2a28d2ab0809261515i394601f4vb2f05ce1937843b4@mail.gmail.com> On Fri, Sep 26, 2008 at 1:05 AM, seth vidal wrote: > > > intelligent mirror is another good way. > > Relying on nfs + sqlite and worrying about the race conditions > w/multiple yum instances on multiple machines possibly writing to this > location is just going to end badly. > > -sv > All, linking only the packages directory has done the trick! Many thanks to all.. Andy -- projecthuh.com All of my bits are free, are yours? Fedoraproject.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From orion at cora.nwra.com Fri Sep 26 22:47:42 2008 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 26 Sep 2008 16:47:42 -0600 Subject: Could use help with cfengine/db4 issue Message-ID: <48DD668E.9010908@cora.nwra.com> I could use some help tracking down a db4 issue with cfengine on rawhide: DB->get_dbname: method not permitted before handle's open method see https://bugzilla.redhat.com/show_bug.cgi?id=461942 Thanks! -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion at cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com From michael at laptop.org Fri Sep 26 23:32:27 2008 From: michael at laptop.org (Michael Stone) Date: Fri, 26 Sep 2008 19:32:27 -0400 Subject: Do we care about /sbin /bin linked to /usr/lib ? In-Reply-To: <20080926153435.GC1338970@hiwaay.net> References: <200809251328.01886.sgrubb@redhat.com> <200809261155.25091.billcrawford1970@gmail.com> <91705d080809260643q137750a2ja5273810cbc47e2d@mail.gmail.com> <200809261500.09968.billcrawford1970@gmail.com> <20080926153435.GC1338970@hiwaay.net> Message-ID: <20080926233224.GT18785@didacte.laptop.org> On Fri, Sep 26, 2008 at 10:34:35AM -0500, Chris Adams wrote: >Once upon a time, Bill Crawford said: >> Long term, I'll admit that getting rid of separate /usr may be a good idea, >> Solaris appears to have done away with it a while ago (which surprised me, >> since they used to make explicit provision for having shared /usr in their >> package management system). > >I use a separate (but not shared) /usr on my servers, and I mount it >read-only. My reasoning is that / has to be read-write still for some >things (root's home directory, /etc/passwd and /etc/shadow, etc.). I >keep a small / that is read-write, but having a good chunk of the >installed stuff in /usr mounted read-only makes it a little "safer" >(i.e. an attacker would have to remount it to modify it, filesystem >corruption is unlikely on a read-only FS, etc.). I'll mention in passing that OLPC is both extremely interested in (and well on its way) to shipping something rather like a read-only / as part of our security and update schemes. (The weasel words are due the fact that, in our design, we chroot through a symlink tree at boot in order to permit easy atomic OS updates and use both file-mounted tmpfsen and a custom NSS module to deal with the small number of writes that still must be permitted.) Anyway, suffice it to say that I'd enjoy hearing more about your progress toward a read-only / as you make it. Regards, Michael From fedora at leemhuis.info Sat Sep 27 06:28:08 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 27 Sep 2008 08:28:08 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <1222466139.4848.33.camel@luminos.localdomain> References: <20080926091109.GF3149@free.fr> <20080926115055.GB11932@dhcp-lab-186.brq.redhat.com> <20080926121506.GA2204@yoda.jdub.homelinux.org> <48DCD5C9.70302@hhs.nl> <20080926131350.GA2388@yoda.jdub.homelinux.org> <48DCF3C4.5010506@leemhuis.info> <20080926155300.GA5864@yoda.jdub.homelinux.org> <20080926213245.GB3058@free.fr> <1222466139.4848.33.camel@luminos.localdomain> Message-ID: <48DDD278.6030307@leemhuis.info> On 26.09.2008 23:55, Jesse Keating wrote: > On Fri, 2008-09-26 at 23:32 +0200, Patrice Dumas wrote: >> Thorsten already answered, but I think this is a fundamental error to >> think that a wiki means that everybody should change everywhere. It is >> very important that people restrict themselves to their areas of >> expertise. That being said, community members can help with the wiki >> ioutside of their area of expertise, but only under the guidance of >> somebody who knows. +1 > The "community" (aren't we all community?) doesn't have to edit it. > However if they notice that it's wrong, they could bring it to the > attention of the group who "owns" those pages. Hmmm. After reading this para and the stuff you wrote in https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02494.html (?) I more and more get the impression you assume I was aware of the problem in question (email to rel-eng at fedoraproject.org mentioned on several wiki pages) for quite a long while already. That's not the case. I saw the mail from jwb and then just used google (search term: "rel-eng at fedoraproject.org site:fedoraproject.org") and found important pages that were misleading. I then immediately mailed the list. Yes, the first mail I send was a bit unobvious (jwb got the message :-) ), but that's why I wrote another one as reply to myself immediately after sending the first one ;-) Cu knurd (?) I didn't really understand that mail in this context; I thought it was not worth discussing this further as it wouldn't lead to anything productive, hence I didn't reply. And note, of course I agree that making other people or groups aware of a problem when you spot one is the best for everyone. Most people should know that I do that and/or fix things myself immediately as long as that makes sense (didn#t make sense here) P.S.: I hope this sub-thread can now die... It seems just another proof for the statement "sometimes discussing things on mailing lists simply doesn't work" From fedora at camperquake.de Sat Sep 27 09:10:53 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 27 Sep 2008 11:10:53 +0200 Subject: please deactivate services by default! In-Reply-To: <5256d0b0809260100jc5f100fm51e42fa310981857@mail.gmail.com> References: <20080924212236.GJ1414283@hiwaay.net> <20080925164138.GC16719@nostromo.devel.redhat.com> <20080925180310.GL1126464@hiwaay.net> <48DBF2E5.70006@fedoraproject.org> <5256d0b0809251329g44a69287l585bf57bd6b3130c@mail.gmail.com> <1222388483.5130.6.camel@localhost.localdomain> <5256d0b0809260100jc5f100fm51e42fa310981857@mail.gmail.com> Message-ID: <20080927111053.66a665e0@lain.camperquake.de> Hi. On Fri, 26 Sep 2008 09:00:59 +0100, Peter Robinson wrote > I thought numa is a series of computers connected together via a fast > interconnect such as Infiband where they can access each others memory > but accessing local memory is faster than non-local memory. Hence Non > Uniform Memory Access. NUMA basically relates to the fact that in some systems not all memory is equal. Not all nodes may be able to access all memory locations, or access to some memory locations is slower/faster than access to other locations. It is beneficial for the OS to know about this. AMDs Opteron series uses a system like this, so it's definitely quite mainstream these days. From fedora at camperquake.de Sat Sep 27 09:20:26 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 27 Sep 2008 11:20:26 +0200 Subject: please deactivate services by default! In-Reply-To: <1222377255.4083.5.camel@choeger6> References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <1222363259.3941.36.camel@choeger6> <1222377255.4083.5.camel@choeger6> Message-ID: <20080927112026.1238eef7@lain.camperquake.de> Hi. On Thu, 25 Sep 2008 23:14:15 +0200, Christoph H?ger wrote > You are the one talking about obfuscating sender ;) No, its just an ?, > as in H?ger, my name. This mail should be encoded in utf-8 (hope that > doesn't break your backup ;) I cannot efford a lawyer), so I assume > your decoding doesn't work well. The header is encoded as ISO-8859-1, quoted printable, and looks fine. If TB chokes on that you might want to file a bug. From fedora at camperquake.de Sat Sep 27 09:24:27 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 27 Sep 2008 11:24:27 +0200 Subject: please deactivate services by default! In-Reply-To: <20080925230939.GD29433@shell.devel.redhat.com> References: <20080924230129.GB29113@free.fr> <1222299566.1895.0.camel@luminos.localdomain> <48DBE1A2.1090401@gmail.com> <48DBEF3F.5070702@gmail.com> <20080925230939.GD29433@shell.devel.redhat.com> Message-ID: <20080927112427.26dc6263@lain.camperquake.de> Hi. On Thu, 25 Sep 2008 19:09:39 -0400, Alan Cox wrote > You can start sendmail late and asynchronously. I've done that for > years on Fedora boxes and its a standard mod I make every time to > sendmail or exim scripts. Won't upstart do that, anyway, once it works as intended? From fedora at camperquake.de Sat Sep 27 09:35:48 2008 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 27 Sep 2008 11:35:48 +0200 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> <1222290934.5774.35.camel@dimi.lattica.com> Message-ID: <20080927113548.2fc732e4@lain.camperquake.de> Hi. On Thu, 25 Sep 2008 14:04:35 +0200, Matej Cepl wrote > What was meant (I guess) is that if DNS is broken and there is no > localhost entry in /etc/hosts, user however naive will have > bigger problems than slow sendmail on start. Is there any particular reason why the resolver does not know about 127.0.0.1<->localhost by default? It should of course follow the methods outlined in nsswitch.conf to get more specific results, but localhost is pretty crucial for a working UNIX which has networking cababilities. From rawhide at fedoraproject.org Sat Sep 27 10:15:39 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sat, 27 Sep 2008 10:15:39 +0000 (UTC) Subject: rawhide report: 20080927 changes Message-ID: <20080927101539.4DE7C1F8261@releng2.fedora.phx.redhat.com> Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Broken deps for i386 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.i386 requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so Broken deps for x86_64 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.x86_64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.ppc requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so Broken deps for ppc64 ---------------------------------------------------------- eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gspiceui-0.9.65-2.fc10.ppc64 requires gwave livecd-tools-018-1.fc10.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.ppc64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) From paul at all-the-johnsons.co.uk Sat Sep 27 08:35:40 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Sat, 27 Sep 2008 09:35:40 +0100 Subject: Fedora rawhide rebuild in mock status 2008-09-23 i386 In-Reply-To: <20080924122147.GA4137@mock.linuxdev.us.dell.com> References: <20080924122147.GA4137@mock.linuxdev.us.dell.com> Message-ID: <1222504540.2679.1.camel@PB3.Linux> Hi gtk-sharp - AFAIK, nothing relies on this anymore in rawhide. Possibly does in f9. Is it worth keeping this package in? > mx-2.0.6-3 (unpackaged_files/python-egg-info?) pfj Fixed in f10-dist but not rawhide (missed the freeze) TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From cra at WPI.EDU Sat Sep 27 18:04:13 2008 From: cra at WPI.EDU (Chuck Anderson) Date: Sat, 27 Sep 2008 14:04:13 -0400 Subject: please deactivate services by default! In-Reply-To: <20080927113548.2fc732e4@lain.camperquake.de> References: <1222287197.3941.7.camel@choeger6> <48DAAB49.7050807@gmail.com> <1222290934.5774.35.camel@dimi.lattica.com> <20080927113548.2fc732e4@lain.camperquake.de> Message-ID: <20080927180413.GA12626@angus.ind.WPI.EDU> On Sat, Sep 27, 2008 at 11:35:48AM +0200, Ralf Ertzinger wrote: > Hi. > > On Thu, 25 Sep 2008 14:04:35 +0200, Matej Cepl wrote > > > What was meant (I guess) is that if DNS is broken and there is no > > localhost entry in /etc/hosts, user however naive will have > > bigger problems than slow sendmail on start. > > Is there any particular reason why the resolver does not know > about 127.0.0.1<->localhost by default? It should of course follow > the methods outlined in nsswitch.conf to get more specific results, > but localhost is pretty crucial for a working UNIX which has networking > cababilities. It isn't localhost that is a problem. It is the system hostname to IP mapping that is a problem. e.g. for a host called "foobar": 127.0.0.1 localhost.localdomain localhost foobar.domain.com foobar From wolfy at nobugconsulting.ro Sat Sep 27 18:25:07 2008 From: wolfy at nobugconsulting.ro (Manuel Wolfshant) Date: Sat, 27 Sep 2008 21:25:07 +0300 Subject: please deactivate services by default! In-Reply-To: <48DD4C90.8080608@gmail.com> References: <1222287197.3941.7.camel@choeger6> <20080924213834.GM1414283@hiwaay.net> <200809251038.34508.billcrawford1970@gmail.com> <20080926220951.4476e7f1@lain.camperquake.de> <48DD4C90.8080608@gmail.com> Message-ID: <48DE7A83.6050705@nobugconsulting.ro> On 09/26/2008 11:56 PM, Les Mikesell wrote: > Ralf Ertzinger wrote: >> Hi. >> >> On Thu, 25 Sep 2008 10:38:34 +0100, Bill Crawford wrote >> >>> Surely the SMTP server isn't absolutely required to be on localhost? >>> I never send any mail via localhost SMTP, it's all done through my >>> company's mail servers or the Google ones for personal mail. >> >> Unfortunately, sendmail isn't just a program, it's an API. Calling >> /usr/lib/sendmail has been the way to get mail out (whereever out >> is) in UNIX for, well, as long as sendmail exists, which is quite some >> time. > > Yes, it seems odd that it bothers someone now when computers are > orders of magnitude faster than when this scheme was designed. > >> That does not mean that it has to be "the" sendmail, of course. >> >> Oh, and LSB requires that it's there. > > Postfix is probably the only alternative that has all of the expected > functionality, but really the effort should be focused on the only > real issue here which is that starting the daemon can cause a visible > delay at boot time - and there are several easy fixes for that. what's wrong with exim (not that I like or recommend it, but it is there and it works) ? From opensource at till.name Sat Sep 27 20:36:04 2008 From: opensource at till.name (Till Maas) Date: Sat, 27 Sep 2008 22:36:04 +0200 Subject: Creating a core dump / backtrace from /bin/login In-Reply-To: <48DD5E30.4060707@BitWagon.com> References: <200809262226.38192.opensource@till.name> <48DD5E30.4060707@BitWagon.com> Message-ID: <200809272236.14079.opensource@till.name> On Sat September 27 2008, John Reiser wrote: > > How can I set ulimits for /bin/login? > > For a general program: wrap the program in a shell script. Move the > program to a new name somewhere else, then put a script at the original > name: #! /bin/bash > ulimit -c unlimited > exec /path/to/new/name/of/original/program "$@" Thank you, this worked perfectly. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From kwizart at gmail.com Sat Sep 27 22:47:30 2008 From: kwizart at gmail.com (KH KH) Date: Sun, 28 Sep 2008 00:47:30 +0200 Subject: Fedora rawhide rebuild in mock status 2008-09-23 i386 In-Reply-To: <20080924122147.GA4137@mock.linuxdev.us.dell.com> References: <20080924122147.GA4137@mock.linuxdev.us.dell.com> Message-ID: 2008/9/24 Matt Domsch : > Fedora Rawhide-in-Mock Build Results for i386 > using the rawhide tree of Tuesday, 2008-10-23. <...> kwizart: elektra,oyranos,perl-Event-Lib <...> elektra was already fixed (by you - thx) oyranos has just been fixed. perl-Event-Lib, make test failed on ppc64 (needs to advice maintainer - or de-activate the failing test). libgii failed only on lib64 systems but i will orphan it. From alan at redhat.com Sat Sep 27 22:50:23 2008 From: alan at redhat.com (Alan Cox) Date: Sat, 27 Sep 2008 18:50:23 -0400 Subject: please deactivate services by default! In-Reply-To: <20080927112427.26dc6263@lain.camperquake.de> References: <1222299566.1895.0.camel@luminos.localdomain> <48DBE1A2.1090401@gmail.com> <48DBEF3F.5070702@gmail.com> <20080925230939.GD29433@shell.devel.redhat.com> <20080927112427.26dc6263@lain.camperquake.de> Message-ID: <20080927225023.GB14956@shell.devel.redhat.com> On Sat, Sep 27, 2008 at 11:24:27AM +0200, Ralf Ertzinger wrote: > Hi. > > On Thu, 25 Sep 2008 19:09:39 -0400, Alan Cox wrote > > > You can start sendmail late and asynchronously. I've done that for > > years on Fedora boxes and its a standard mod I make every time to > > sendmail or exim scripts. > > Won't upstart do that, anyway, once it works as intended? To quote a certain nodding dog "Oh yes..." From kwizart at gmail.com Sat Sep 27 22:58:42 2008 From: kwizart at gmail.com (KH KH) Date: Sun, 28 Sep 2008 00:58:42 +0200 Subject: libgii is orphaned. Message-ID: Hi Libgii was the first step of an attempt to package the whole ggi project. See http://www.ggi-project.org/ I'm not interested anymore in it. (libggi failed with usability test and now libgii is in the FTBFS list for lib64) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239939 Nicolas (kwizart) From mr.ecik at gmail.com Sat Sep 27 23:00:43 2008 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Sun, 28 Sep 2008 01:00:43 +0200 Subject: Fever spamming Message-ID: <668bb39a0809271600u4dc1a943x697acb022f1d7472@mail.gmail.com> Hi, as some of you have already noticed, fever spammed bugzilla a bit, submitting notification about a new version of a package which has been already submitted either long time ago or a few minutes before. This was caused by a fundamental bug in fever's code which now should be fixed; it's related to fever's new email address due to inactiveness of the previous one. I would like to strongly apologize everyone who needed to or will need to clean the trash fever caused. It should never happen again. -- Micha? Bentkowski mr.ecik at gmail.com From kevin.kofler at chello.at Sun Sep 28 01:05:43 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 28 Sep 2008 01:05:43 +0000 (UTC) Subject: Fever spamming References: <668bb39a0809271600u4dc1a943x697acb022f1d7472@mail.gmail.com> Message-ID: I just noticed a problem with many of the Fever regexes: SourceForge changed their site layout, which breaks all the regexes based on SourceForge file names. :-( They no longer have one convenient page listing all the downloads which we can automatically scan. Anything we can do about that? Kevin Kofler From kevin.kofler at chello.at Sun Sep 28 01:12:35 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 28 Sep 2008 01:12:35 +0000 (UTC) Subject: Fever spamming References: <668bb39a0809271600u4dc1a943x697acb022f1d7472@mail.gmail.com> Message-ID: I wrote: > Anything we can do about that? Actually, I figured out a solution myself: You have to provide a showfiles link with both a group_id and a package_id, e.g.: http://sourceforge.net/project/showfiles.php?group_id=2917&package_id=2867 instead of the previously used: http://prdownloads.sourceforge.net/z88dk format which redirects to just: http://sourceforge.net/project/showfiles.php?group_id=2917 which brings up the "simplified" layout which hides all the important information. This will work... until SF breaks everything again. :-/ I really hate their complex download management system which doesn't even let you get something as simple as a directory listing. Now someone needs to fix all the SF regexes. Kevin Kofler From rawhide at fedoraproject.org Sun Sep 28 09:49:57 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Sun, 28 Sep 2008 09:49:57 +0000 (UTC) Subject: rawhide report: 20080928 changes Message-ID: <20080928094958.18DD71F8261@releng2.fedora.phx.redhat.com> Summary: Added Packages: 0 Removed Packages: 0 Modified Packages: 0 Broken deps for i386 ---------------------------------------------------------- dejavu-fonts-experimental-2.26-2.fc10.noarch requires dejavu-fonts = 0:2.26-2.fc10 evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 mapnik-0.5.1-4.fc10.i386 requires dejavu-fonts 1:openoffice.org-langpack-ar-3.0.0-5.1.fc10.i386 requires dejavu-fonts 1:openoffice.org-langpack-he_IL-3.0.0-5.1.fc10.i386 requires dejavu-fonts perl-Module-ExtractUse-0.23-1.fc10.noarch requires perl(Pod::Strip) perl-PDF-API2-0.69-5.fc10.noarch requires dejavu-fonts pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.i386 requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so sdljava-demo-0.9.1-9.fc9.i386 requires /usr/share/fonts/dejavu/DejaVuSans-BoldOblique.ttf sdljava-demo-0.9.1-9.fc9.i386 requires /usr/share/fonts/dejavu/DejaVuSans-Bold.ttf sdljava-demo-0.9.1-9.fc9.i386 requires /usr/share/fonts/dejavu/DejaVuSans-Oblique.ttf sdljava-demo-0.9.1-9.fc9.i386 requires /usr/share/fonts/dejavu/DejaVuSans.ttf warzone2100-2.1.0-0.5.beta2.fc10.i386 requires dejavu-fonts Broken deps for x86_64 ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.i386 requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.i386 requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.x86_64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.x86_64 requires libcamel-1.2.so.12()(64bit) pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.x86_64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) Broken deps for ppc ---------------------------------------------------------- evolution-brutus-1.2.17-1.fc10.ppc requires libBrutusKeyringd-1.0.so.1 evolution-brutus-1.2.17-1.fc10.ppc requires libcamel-1.2.so.12 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0 python-gammu-0.26-1.fc10.ppc requires libGammu.so.3 ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so Broken deps for ppc64 ---------------------------------------------------------- eclipse-mylyn-3.0.1-2.fc10.noarch requires ws-commons-util >= 0:1.0.1-5 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-common >= 0:3.0-1jpp.3 eclipse-mylyn-3.0.1-2.fc10.noarch requires xmlrpc3-client >= 0:3.0-1jpp.3 evolution-brutus-1.2.17-1.fc10.ppc64 requires libBrutusKeyringd-1.0.so.1()(64bit) evolution-brutus-1.2.17-1.fc10.ppc64 requires libcamel-1.2.so.12()(64bit) gspiceui-0.9.65-2.fc10.ppc64 requires gwave livecd-tools-018-1.fc10.ppc64 requires yaboot perl-Test-AutoBuild-darcs-1.2.2-3.fc9.noarch requires darcs >= 0:1.0.0 pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) python-gammu-0.26-1.fc10.ppc64 requires libGammu.so.3()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) From forum at hubbitus.com.ru Sun Sep 28 10:22:12 2008 From: forum at hubbitus.com.ru (Pavel Alexeev (aka Pahan-Hubbitus)) Date: Sun, 28 Sep 2008 14:22:12 +0400 Subject: Link to UnownedDirectories on wiki page FrequentlyMadeMistakes. Message-ID: <48DF5AD4.4010805@ru.bir.ru> I think what will be highly appreciated link to https://fedoraproject.org/wiki/PackagingDrafts/UnownedDirectories on the end of https://fedoraproject.org/wiki/Packaging/FrequentlyMadeMistakes From gdt at gdt.id.au Sun Sep 28 12:20:41 2008 From: gdt at gdt.id.au (Glen Turner) Date: Sun, 28 Sep 2008 21:50:41 +0930 Subject: please deactivate services by default! In-Reply-To: <48DBFA4A.90405@diffingo.com> References: <1222287197.3941.7.camel@choeger6> <48DBFA4A.90405@diffingo.com> Message-ID: <48DF7699.1090008@gdt.id.au> Stewart Adam wrote: > I made a Feature page [1] for this a while back, but I didn't include > ip6tables or setroubleshootd... Please do not include ip6tables. IPv6 will start anyway, at the very least with a link scope address. So all you are doing is deactivating the firewall for IPv6. You should either deactivate both iptables and ip6tables, or if you feel that is too insecure (as the current default configuration assumes), activate them both. One of the issues with IPv6 deployment is the number of corporate firewalls which filter IPv4 but silently pass IPv6 unfiltered through the firewall once the firewall is (perhaps automatically) configured with an IPv6 address. Let's not add Fedora to that list of troubled systems. I know less about SELinux, but from a user interface point of view SELinux's "did you see that?" audit-based approach is far superior to Vista's UAC "put you on the spot" approach. Setroubleshootd is a key part to delivering SELinux's user experience. -- Glen Turner From pertusus at free.fr Sun Sep 28 12:21:03 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 28 Sep 2008 14:21:03 +0200 Subject: proposal for make help chain-build text Message-ID: <20080928122103.GA2728@free.fr> Hello, Here is a proposal for the result of make help for the chain-build target, what I changed relates with : and prallel builds: chain-build Build current package in order with other packages example: make chain-build CHAIN='libwidget libgizmo' The current package is added to the end of the CHAIN list. Colons (:) can be used in the CHAIN parameter to define parallely built package groups. Packages in a single group will be built in parallel, and all packages in a group must build successfully and populate the repository before the next group will begin building. For example make chain-build CHAIN='libwidget libaselib : libgizmo :' will cause libwidget and libaselib to be build in parallel, followed by libgizmo and then the current directory package. If no groups are defined, packages will be built sequentially. -- Pat From mr.ecik at gmail.com Sun Sep 28 12:53:21 2008 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Sun, 28 Sep 2008 14:53:21 +0200 Subject: Fever spamming In-Reply-To: References: <668bb39a0809271600u4dc1a943x697acb022f1d7472@mail.gmail.com> Message-ID: <668bb39a0809280553l2c6ae22s1183a53ea9bbb26f@mail.gmail.com> 2008/9/28 Kevin Kofler > Now someone needs to fix all the SF regexes. > Within the next 24 hours I'm going to make a script which should fix everything (or maybe I'll make a workaround within fever itself). -- Micha? Bentkowski mr.ecik at gmail.com From jonathan.underwood at gmail.com Sun Sep 28 17:10:28 2008 From: jonathan.underwood at gmail.com (Jonathan Underwood) Date: Sun, 28 Sep 2008 18:10:28 +0100 Subject: proposal for make help chain-build text In-Reply-To: <20080928122103.GA2728@free.fr> References: <20080928122103.GA2728@free.fr> Message-ID: <645d17210809281010l676e22b4kc15d0c5bf0824549@mail.gmail.com> 2008/9/28 Patrice Dumas : > Hello, > > Here is a proposal for the result of make help for the chain-build > target, what I changed relates with : and prallel builds: > > chain-build Build current package in order with > other packages > example: make chain-build CHAIN='libwidget libgizmo' > The current package is added to the end of the CHAIN list. > Colons (:) can be used in the CHAIN parameter to define > parallely built package groups. > Packages in a single group will be built in parallel, > and all packages in a group must build successfully and > populate the repository before the next group will begin building. > For example > make chain-build CHAIN='libwidget libaselib : libgizmo > :' > will cause libwidget and libaselib to be build in parallel, > followed by libgizmo and then the current directory package. > If no groups are defined, packages will be built sequentially. Does chain-build also allow for boostrapping situation i.e. could one do make chain-build CHAIN='libwidget libaselib : libgizmo : libwidget to rebuild libwidget against the newly built libgizmo ? J. From vonbrand at inf.utfsm.cl Sun Sep 28 18:31:45 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 28 Sep 2008 14:31:45 -0400 Subject: unfrozen repo somewhere? In-Reply-To: <1222425353.3564.248.camel@beck.corsepiu.local> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> Message-ID: <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> Ralf Corsepius wrote: > On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote: > > Hello, > > I understand why rawhide should be frozen at some points, > Openly said, I don't understand this. To me, these freezes are a defect > in Rel-Eng's procedures, which could easily be overcome, if they wanted > to. What Rel-Eng wants is that the rawhide snapshot that Is To Be Fedora- gets beaten to a pulp by us rawhideans. Yes, I'd also like for the rollercoaster ride to continue, but there is no way around that us crazy bunch needs a little gentle leading to help out stabilize the next release. Plus I can imagine that most (all?) developers are concentrating on that job, so there are not many hands free to work of pushing the envelope forward in any case. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From opensource at till.name Sun Sep 28 19:02:39 2008 From: opensource at till.name (Till Maas) Date: Sun, 28 Sep 2008 21:02:39 +0200 Subject: proposal for make help chain-build text In-Reply-To: <645d17210809281010l676e22b4kc15d0c5bf0824549@mail.gmail.com> References: <20080928122103.GA2728@free.fr> <645d17210809281010l676e22b4kc15d0c5bf0824549@mail.gmail.com> Message-ID: <200809282102.47820.opensource@till.name> On Sun September 28 2008, Jonathan Underwood wrote: > Does chain-build also allow for boostrapping situation i.e. could one do > > make chain-build CHAIN='libwidget libaselib : libgizmo : libwidget > > to rebuild libwidget against the newly built libgizmo ? I guess not, because you need to bump the nvr of libwidget to rebuild it afaik. Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From paul at all-the-johnsons.co.uk Sun Sep 28 19:55:54 2008 From: paul at all-the-johnsons.co.uk (Paul) Date: Sun, 28 Sep 2008 20:55:54 +0100 Subject: Unable to expunge some folders, but not all of them Message-ID: <1222631754.26543.1.camel@PB3.Linux> Hi, I'm using the current rawhide version of Evolution and have found that I'm having mixed fortunes expunging folders. Sometimes they will, sometimes they won't. When it fails, all I get it "Failed to expunge" on the message bar. Any ideas on how to clear my folders? TTFN Paul -- ?Sie k?nnen mich aufreizen und wirklich hei? machen! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From vonbrand at inf.utfsm.cl Sun Sep 28 20:17:50 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 28 Sep 2008 16:17:50 -0400 Subject: please deactivate services by default! In-Reply-To: <16de708d0809261420m61f5a463ma570da78ac8febc9@mail.gmail.com> References: <1222287197.3941.7.camel@choeger6> <20080924213834.GM1414283@hiwaay.net> <200809251038.34508.billcrawford1970@gmail.com> <20080926220951.4476e7f1@lain.camperquake.de> <48DD4C90.8080608@gmail.com> <16de708d0809261420m61f5a463ma570da78ac8febc9@mail.gmail.com> Message-ID: <200809282017.m8SKHojj006508@laptop14.inf.utfsm.cl> Arthur Pemberton wrote: > On Fri, Sep 26, 2008 at 3:56 PM, Les Mikesell wrote: > > Ralf Ertzinger wrote: > >> On Thu, 25 Sep 2008 10:38:34 +0100, Bill Crawford wrote [...] > >> Unfortunately, sendmail isn't just a program, it's an API. Calling > >> /usr/lib/sendmail has been the way to get mail out (whereever out > >> is) in UNIX for, well, as long as sendmail exists, which is quite some > >> time. > > Yes, it seems odd that it bothers someone now when computers are orders of > > magnitude faster than when this scheme was designed. Disks aren't /that/ much faster, and are much bigger, so the access time has stayed roughly the same. [...] > Seems like doing an IO heavy task like this will no longer be much of > an issue with a parallel init type startup. Parallel init is still limited by IO-heavy tasks. All I've seen about "parallel service startup" is that is makes almost no difference. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From arjan at infradead.org Sun Sep 28 20:25:39 2008 From: arjan at infradead.org (Arjan van de Ven) Date: Sun, 28 Sep 2008 13:25:39 -0700 Subject: please deactivate services by default! In-Reply-To: <200809282017.m8SKHojj006508@laptop14.inf.utfsm.cl> References: <1222287197.3941.7.camel@choeger6> <20080924213834.GM1414283@hiwaay.net> <200809251038.34508.billcrawford1970@gmail.com> <20080926220951.4476e7f1@lain.camperquake.de> <48DD4C90.8080608@gmail.com> <16de708d0809261420m61f5a463ma570da78ac8febc9@mail.gmail.com> <200809282017.m8SKHojj006508@laptop14.inf.utfsm.cl> Message-ID: <20080928132539.19d01965@infradead.org> On Sun, 28 Sep 2008 16:17:50 -0400 "Horst H. von Brand" wrote: > > Seems like doing an IO heavy task like this will no longer be much > > of an issue with a parallel init type startup. > > Parallel init is still limited by IO-heavy tasks. All I've seen about > "parallel service startup" is that is makes almost no difference. "parallel init" is surprisingly not the answer to booting fast. (unlike parallel, asynchronous components do help) -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org From vonbrand at inf.utfsm.cl Sun Sep 28 20:32:55 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 28 Sep 2008 16:32:55 -0400 Subject: unfrozen repo somewhere? In-Reply-To: <20080926212838.GA3058@free.fr> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <20080926112643.GA25473@free.fr> <20080926120225.GA2185@yoda.jdub.homelinux.org> <20080926123106.GE25473@free.fr> <20080926194132.GC5864@yoda.jdub.homelinux.org> <20080926212838.GA3058@free.fr> Message-ID: <200809282032.m8SKWtOK006578@laptop14.inf.utfsm.cl> Patrice Dumas wrote: > On Fri, Sep 26, 2008 at 03:41:32PM -0400, Josh Boyer wrote: > > So now you've sort of separated the packages in Fedora into a "Core" > > set, and then an "Extras" set. Each set would have different rules > > around release time, and probably for updates and such too. > > Oh wait... that sounds like Fedora Core and Fedora Extras. > No. The difference between Core and Extras was a different set of people > and responsibilities, and different repos. Moreover in core there was > many things that are not listed in my list, like clients, desktop apps > and so on. This is a fundamentaly different distinction. Everything on > my list corresponds, however, with things that were in Core. > Here I wanted to separate the things that should be stable in freeze > which make the base of the OS, and apps whose changes won't disturb too > much other apps that are on top of those base apps but don't have much > interdependencies (except within bounded groups). What is "too much disturbance"? Who says that what for you is peripheral isn't extremely important for the next gal? There is a saying around here, "Ley pareja no es dura" (Evenhanded law isn't hard), and (unless there is a /very/ strong reason to make a difference) I'd prefer handling everything the same way. Cuts down on endless bickering why something or other isn't in the other set, and what the rules to belong in each group should be, and flaming over the (inevitable) mistakes adding a package to the wrong group or handling it according to the wrong set of rules. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From pertusus at free.fr Sun Sep 28 20:47:40 2008 From: pertusus at free.fr (Patrice Dumas) Date: Sun, 28 Sep 2008 22:47:40 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <200809282032.m8SKWtOK006578@laptop14.inf.utfsm.cl> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <20080926112643.GA25473@free.fr> <20080926120225.GA2185@yoda.jdub.homelinux.org> <20080926123106.GE25473@free.fr> <20080926194132.GC5864@yoda.jdub.homelinux.org> <20080926212838.GA3058@free.fr> <200809282032.m8SKWtOK006578@laptop14.inf.utfsm.cl> Message-ID: <20080928204740.GC2728@free.fr> On Sun, Sep 28, 2008 at 04:32:55PM -0400, Horst H. von Brand wrote: > > What is "too much disturbance"? Who says that what for you is peripheral > isn't extremely important for the next gal? My selection is loosely based on what depends on what. At least that's the idea. It isn't about being important or not. And it is not depending in the sense of rpm dependencies, but in the sense of needing the functionalities provided by the set of packages. > There is a saying around here, "Ley pareja no es dura" (Evenhanded law > isn't hard), and (unless there is a /very/ strong reason to make a > difference) I'd prefer handling everything the same way. Cuts down on I don't know if it is a strong reason, but it seems to me that there are packages that need to be frozen because most of the other packages depend on them, and I propose a heuristic to select them, while it seems to me that, for other packages, testing fixes is the priority since it is less likely that other packages depend on them. Put it otherwise, the frozen set is the set of packages that should be frozen to be able to test against them, while the other are tested against the frozen packages. Of course there is no evident way to choose the set, I propose to use some comps groups, but I perfectly understand that it may be a bad choice. -- Pat From lesmikesell at gmail.com Sun Sep 28 21:09:36 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Sun, 28 Sep 2008 16:09:36 -0500 Subject: please deactivate services by default! In-Reply-To: <20080928132539.19d01965@infradead.org> References: <1222287197.3941.7.camel@choeger6> <20080924213834.GM1414283@hiwaay.net> <200809251038.34508.billcrawford1970@gmail.com> <20080926220951.4476e7f1@lain.camperquake.de> <48DD4C90.8080608@gmail.com> <16de708d0809261420m61f5a463ma570da78ac8febc9@mail.gmail.com> <200809282017.m8SKHojj006508@laptop14.inf.utfsm.cl> <20080928132539.19d01965@infradead.org> Message-ID: <48DFF290.7070001@gmail.com> Arjan van de Ven wrote: > On Sun, 28 Sep 2008 16:17:50 -0400 > "Horst H. von Brand" wrote: > >>> Seems like doing an IO heavy task like this will no longer be much >>> of an issue with a parallel init type startup. >> Parallel init is still limited by IO-heavy tasks. All I've seen about >> "parallel service startup" is that is makes almost no difference. > > > "parallel init" is surprisingly not the answer to booting fast. > > (unlike parallel, asynchronous components do help) But there's no reason to delay logins until cron or the sendmail daemon have started. And the sendmail daemon doesn't really ever have to run unless there are undelivered messages in the queue. I'd guess the only reason it was ever done that way was the convention of giving X it's own runlevel which doesn't make all that much sense anyway. -- Les Mikesell lesmikesell at gmail.com From martin.langhoff at gmail.com Sun Sep 28 23:47:02 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 29 Sep 2008 12:47:02 +1300 Subject: please deactivate services by default! In-Reply-To: <20080928132539.19d01965@infradead.org> References: <1222287197.3941.7.camel@choeger6> <20080924213834.GM1414283@hiwaay.net> <200809251038.34508.billcrawford1970@gmail.com> <20080926220951.4476e7f1@lain.camperquake.de> <48DD4C90.8080608@gmail.com> <16de708d0809261420m61f5a463ma570da78ac8febc9@mail.gmail.com> <200809282017.m8SKHojj006508@laptop14.inf.utfsm.cl> <20080928132539.19d01965@infradead.org> Message-ID: <46a038f90809281647p546dad57xc541ee4a6da6882@mail.gmail.com> On Mon, Sep 29, 2008 at 9:25 AM, Arjan van de Ven wrote: > "parallel init" is surprisingly not the answer to booting fast. > > (unlike parallel, asynchronous components do help) Hi Arjan, have you guys published your paper and/or slides anywhere after the plumbers conf? I'm definitely anxious to read it, and went looking for it in the conference website and the intel lesswatts site a few days ago. Couldn't find anything... where's the gory details...? Patches? Sample disk image? Hardware used...? cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From rc040203 at freenet.de Mon Sep 29 01:19:25 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 29 Sep 2008 03:19:25 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> Message-ID: <1222651165.3564.314.camel@beck.corsepiu.local> On Sun, 2008-09-28 at 14:31 -0400, Horst H. von Brand wrote: > Ralf Corsepius wrote: > > On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote: > > > Hello, > > > > I understand why rawhide should be frozen at some points, > > > Openly said, I don't understand this. To me, these freezes are a defect > > in Rel-Eng's procedures, which could easily be overcome, if they wanted > > to. > > What Rel-Eng wants is that the rawhide snapshot that Is To Be Fedora- > gets beaten to a pulp by us rawhideans. Yes, I'd also like for the > rollercoaster ride to continue, but there is no way around that us crazy > bunch needs a little gentle leading to help out stabilize the next > release. Plus I can imagine that most (all?) developers are concentrating > on that job, so there are not many hands free to work of pushing the > envelope forward in any case. What I would like to see it Rel-Eng to adopt the development principles, most other developments apply: Decouple "product development" (here: FC) development from bleeding edge "unstable/experimental" "head development" (here: rawhide). To achieve this, most projects first branch a "release branch" and work on this "release branch" to stabilize it before release/product deployment. I.e. instead of bringing "head development" and "maintenance of released products on hold" (aka. freezes), I'd recommend Rel-Eng to branch FC. Ralf From vonbrand at inf.utfsm.cl Mon Sep 29 02:38:18 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Sun, 28 Sep 2008 22:38:18 -0400 Subject: unfrozen repo somewhere? In-Reply-To: <1222651165.3564.314.camel@beck.corsepiu.local> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> Message-ID: <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> Ralf Corsepius wrote: > On Sun, 2008-09-28 at 14:31 -0400, Horst H. von Brand wrote: > > Ralf Corsepius wrote: > > > On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote: > > > > Hello, > > > > I understand why rawhide should be frozen at some points, > > > Openly said, I don't understand this. To me, these freezes are a defect > > > in Rel-Eng's procedures, which could easily be overcome, if they wanted > > > to. > > What Rel-Eng wants is that the rawhide snapshot that Is To Be Fedora- > > gets beaten to a pulp by us rawhideans. Yes, I'd also like for the > > rollercoaster ride to continue, but there is no way around that us crazy > > bunch needs a little gentle leading to help out stabilize the next > > release. Plus I can imagine that most (all?) developers are concentrating > > on that job, so there are not many hands free to work of pushing the > > envelope forward in any case. > What I would like to see it Rel-Eng to adopt the development principles, > most other developments apply: > > Decouple "product development" (here: FC) development from bleeding > edge "unstable/experimental" "head development" (here: rawhide). Needs more hands. Starves the "product development" of developers and testers. Was the idea in Linux before 2.6, was abandoned for exactly the above reasons. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From rc040203 at freenet.de Mon Sep 29 03:37:45 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 29 Sep 2008 05:37:45 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> Message-ID: <1222659465.3564.332.camel@beck.corsepiu.local> On Sun, 2008-09-28 at 22:38 -0400, Horst H. von Brand wrote: > Ralf Corsepius wrote: > > On Sun, 2008-09-28 at 14:31 -0400, Horst H. von Brand wrote: > > > Ralf Corsepius wrote: > > > > On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote: > > > > > Hello, > > > > > > I understand why rawhide should be frozen at some points, > > > > > Openly said, I don't understand this. To me, these freezes are a defect > > > > in Rel-Eng's procedures, which could easily be overcome, if they wanted > > > > to. > > > > What Rel-Eng wants is that the rawhide snapshot that Is To Be Fedora- > > > gets beaten to a pulp by us rawhideans. Yes, I'd also like for the > > > rollercoaster ride to continue, but there is no way around that us crazy > > > bunch needs a little gentle leading to help out stabilize the next > > > release. Plus I can imagine that most (all?) developers are concentrating > > > on that job, so there are not many hands free to work of pushing the > > > envelope forward in any case. > > > What I would like to see it Rel-Eng to adopt the development principles, > > most other developments apply: > > > > Decouple "product development" (here: FC) development from bleeding > > edge "unstable/experimental" "head development" (here: rawhide). > > Needs more hands. Starves the "product development" of developers and > testers. I don't see this - To the contrary. I feel the current model is driving away developers and testers, esp. packagers. > Was the idea in Linux before 2.6, was abandoned for exactly the > above reasons. ... but it is the idea which is being applied almost anywhere else. Ask yourself: Is the current development model in Fedora a success? I don't think so. - Fedora releases essentially are rawhide snapshots. Packages from rawhide automatically become "stable" (Lack of "rawhide/testing"). E.g. I have package upgrades pending, I currently don't want to push to Fedora, because I fear them to be too unstable for a product. - Fedora's release process starves package development. E.g. I have several (upstream) package upgrades pending, I can't push to Fedora because to the freezes are permanently interfering. - rawhide is too volatile to be usable for many testers, esp. packagers testing their packages. - The current process introduces a bloated bureaucracy to work around the side-effects of "not-branches". Ralf From tgl at redhat.com Mon Sep 29 03:51:02 2008 From: tgl at redhat.com (Tom Lane) Date: Sun, 28 Sep 2008 23:51:02 -0400 Subject: unfrozen repo somewhere? In-Reply-To: <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> Message-ID: <25665.1222660262@sss.pgh.pa.us> "Horst H. von Brand" writes: > Ralf Corsepius wrote: >> Decouple "product development" (here: FC) development from bleeding >> edge "unstable/experimental" "head development" (here: rawhide). > Needs more hands. Starves the "product development" of developers and > testers. Was the idea in Linux before 2.6, was abandoned for exactly the > above reasons. Yeah ... when it's time to ship a release, you need a forcing function to encourage people to test-and-fix-bugs, rather than develop-cool-new- features. Branching early encourages people to ignore the release and do the latter. The Postgres project has generally avoided early branching, and I think that policy has been a significant contributor to our ten-year history of making stable releases. Branching early works if you have a sufficiently large critical mass of developers and testers who like to work on stabilizing a release, and another sufficiently large critical mass of people who prefer to work on pushing new features forward, plus enough extra manpower to deal with keeping the two branches in sync. If you lack any of those things it's a loser. There are certainly a small number of open source projects that have enough popularity and enough ensuing manpower-and-expertise to make a go of this approach. To imagine that it's workable for the majority of projects is to demonstrate lack of connection to reality. To propose that it become a distro-wide policy is so ... so ... well, I can't think of an adjective that's fit to print. regards, tom lane From vonbrand at inf.utfsm.cl Mon Sep 29 04:37:10 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 29 Sep 2008 00:37:10 -0400 Subject: unfrozen repo somewhere? In-Reply-To: <1222659465.3564.332.camel@beck.corsepiu.local> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> <1222659465.3564.332.camel@beck.corsepiu.local> Message-ID: <200809290437.m8T4bAAH011491@laptop14.inf.utfsm.cl> Ralf Corsepius wrote: > On Sun, 2008-09-28 at 22:38 -0400, Horst H. von Brand wrote: > > Ralf Corsepius wrote: > > > On Sun, 2008-09-28 at 14:31 -0400, Horst H. von Brand wrote: > > > > Ralf Corsepius wrote: > > > > > On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote: > > > > > > I understand why rawhide should be frozen at some points, > > > > > Openly said, I don't understand this. To me, these freezes are a > > > > > defect in Rel-Eng's procedures, which could easily be overcome, > > > > > if they wanted to. > > > > What Rel-Eng wants is that the rawhide snapshot that Is To Be > > > > Fedora- gets beaten to a pulp by us rawhideans. Yes, I'd also > > > > like for the rollercoaster ride to continue, but there is no way > > > > around that us crazy bunch needs a little gentle leading to help > > > > out stabilize the next release. Plus I can imagine that most (all?) > > > > developers are concentrating on that job, so there are not many > > > > hands free to work of pushing the envelope forward in any case. > > > What I would like to see it Rel-Eng to adopt the development > > > principles, most other developments apply: > > > > > > Decouple "product development" (here: FC) development from > > > bleeding edge "unstable/experimental" "head development" (here: > > > rawhide). > > Needs more hands. Starves the "product development" of developers and > > testers. > I don't see this - To the contrary. I feel the current model is driving > away developers and testers, esp. packagers. Any hard (or even mushy) data to support this? > > Was the idea in Linux before 2.6, was abandoned for exactly the > > above reasons. > ... but it is the idea which is being applied almost anywhere else. Examples? > Ask yourself: Is the current development model in Fedora a success? Need to define what "success" means... if it is keeping a very popular, solid distribution moving forward, and gathering more packages, I'd have to say it is. > I don't think so. How do you define "success" then? Where is Fedora lacking? No, this is not just making noise, I'm really interested in the answer. > - Fedora releases essentially are rawhide snapshots. Packages from > rawhide automatically become "stable" (Lack of "rawhide/testing"). E.g. > I have package upgrades pending, I currently don't want to push to > Fedora, because I fear them to be too unstable for a product. Then they should go to rawhide? Go into your local, testers-only repo? Stay in koji, and be advertised somewhere? > - Fedora's release process starves package development. E.g. I have > several (upstream) package upgrades pending, I can't push to Fedora > because to the freezes are permanently interfering. Please elaborate. Freezes are far in between, it would be phenomenal bad luck if many important upstream just happen to fall into those. And those can presumably be applied after the freeze is lifted. > - rawhide is too volatile to be usable for many testers, esp. packagers > testing their packages. What packages are we talking about? For rawhide's instability to be of very much impact, the package development would have to be as fast as rawhide's, or the package have a lot of tendrils reaching into all nooks and cranies of the system. Heck, rawhide is stable enough for me to use as a regular workstation (with some precautions), how would that be /so/ different than deoing development work? Besides, building/testing/stabilizing your packages on Fedora current practically /guarantees/ that by the time the work is finished it is completely irrelevant, as Fedora has moved on into the blue beyond by then. > - The current process introduces a bloated bureaucracy to work around > the side-effects of "not-branches". Please elaborate. I'm sure the people involved would love to get that workload diminished... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From rc040203 at freenet.de Mon Sep 29 04:49:33 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 29 Sep 2008 06:49:33 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <25665.1222660262@sss.pgh.pa.us> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> <25665.1222660262@sss.pgh.pa.us> Message-ID: <1222663773.3564.355.camel@beck.corsepiu.local> On Sun, 2008-09-28 at 23:51 -0400, Tom Lane wrote: > "Horst H. von Brand" writes: > > Ralf Corsepius wrote: > >> Decouple "product development" (here: FC) development from bleeding > >> edge "unstable/experimental" "head development" (here: rawhide). > > > Needs more hands. Starves the "product development" of developers and > > testers. Was the idea in Linux before 2.6, was abandoned for exactly the > > above reasons. > > Yeah ... when it's time to ship a release, you need a forcing function > to encourage people to test-and-fix-bugs, rather than develop-cool-new- > features. Correct. > Branching early encourages people to ignore the release and > do the latter. Well, I don't agree. IMO, branching encourages "early adopter end-users to try sneak previews" and to stay away from the "bleeding edge aiming at developers". > The Postgres project has generally avoided early branching, and I think > that policy has been a significant contributor to our ten-year history > of making stable releases. > > Branching early works if you have a sufficiently large critical mass of > developers and testers who like to work on stabilizing a release, and > another sufficiently large critical mass of people who prefer to work > on pushing new features forward, plus enough extra manpower to deal with > keeping the two branches in sync. If you lack any of those things it's > a loser. > > There are certainly a small number of open source projects that have > enough popularity and enough ensuing manpower-and-expertise to make a go > of this approach. Small number of projects? Probably a matter of perspective ;) > To imagine that it's workable for the majority of > projects is to demonstrate lack of connection to reality. Pardon, but you probably can relate, why I have to disagree on this. I would turn this argument around: The apparent lack of quality of the distro, the amount of bureaucracy and ineffectiveness the Fedora approach cause are a living proof for a non-functional approach. Ralf From vonbrand at inf.utfsm.cl Mon Sep 29 05:18:28 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 29 Sep 2008 01:18:28 -0400 Subject: unfrozen repo somewhere? In-Reply-To: <1222663773.3564.355.camel@beck.corsepiu.local> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> <25665.1222660262@sss.pgh.pa.us> <1222663773.3564.355.camel@beck.corsepiu.local> Message-ID: <200809290518.m8T5ISXu012958@laptop14.inf.utfsm.cl> From vonbrand at inf.utfsm.cl Mon Sep 29 05:26:25 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 29 Sep 2008 01:26:25 -0400 Subject: unfrozen repo somewhere? In-Reply-To: <1222663773.3564.355.camel@beck.corsepiu.local> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> <25665.1222660262@sss.pgh.pa.us> <1222663773.3564.355.camel@beck.corsepiu.local> Message-ID: <200809290526.m8T5QPGw012980@laptop14.inf.utfsm.cl> Ralf Corsepius wrote: > On Sun, 2008-09-28 at 23:51 -0400, Tom Lane wrote: > > "Horst H. von Brand" writes: > > > Ralf Corsepius wrote: > > >> Decouple "product development" (here: FC) development from bleeding > > >> edge "unstable/experimental" "head development" (here: rawhide). > > > Needs more hands. Starves the "product development" of developers and > > > testers. Was the idea in Linux before 2.6, was abandoned for exactly the > > > above reasons. > > Yeah ... when it's time to ship a release, you need a forcing function > > to encourage people to test-and-fix-bugs, rather than develop-cool-new- > > features. > Correct. > > Branching early encourages people to ignore the release and > > do the latter. > Well, I don't agree. > > IMO, branching encourages "early adopter end-users to try sneak > previews" and to stay away from the "bleeding edge aiming at > developers". Needs some data to back it up. BTW, data for other classes of development efforts (smaller scale, less developers, slower progress, ...) don't necessarily apply (but would be useful). [...] > > There are certainly a small number of open source projects that have > > enough popularity and enough ensuing manpower-and-expertise to make a go > > of this approach. > Small number of projects? Probably a matter of perspective ;) You' have to provide data to back up your perspective then. > > To imagine that it's workable for the majority of > > projects is to demonstrate lack of connection to reality. > Pardon, but you probably can relate, why I have to disagree on this. > > I would turn this argument around: The apparent lack of quality of the > distro, the amount of bureaucracy and ineffectiveness the Fedora > approach cause are a living proof for a non-functional approach. How do you measure "distro quality", "amount of bureacracy" (and how much of that is "too much"), "effectiveness"? I'd say the fact that we are discussing this shows that the qualility is at least decent enough for serious consideration. Others I can't really see what you mean, so I can't comment. In any case, this would need to be contrasted with other distros for a valid discussion. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From rc040203 at freenet.de Mon Sep 29 05:29:31 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 29 Sep 2008 07:29:31 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <200809290437.m8T4bAAH011491@laptop14.inf.utfsm.cl> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> <1222659465.3564.332.camel@beck.corsepiu.local> <200809290437.m8T4bAAH011491@laptop14.inf.utfsm.cl> Message-ID: <1222666171.3564.392.camel@beck.corsepiu.local> On Mon, 2008-09-29 at 00:37 -0400, Horst H. von Brand wrote: > Ralf Corsepius wrote: > > On Sun, 2008-09-28 at 22:38 -0400, Horst H. von Brand wrote: > > > Ralf Corsepius wrote: > > > > On Sun, 2008-09-28 at 14:31 -0400, Horst H. von Brand wrote: > > > > > Ralf Corsepius wrote: > > > > > > On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote: > > > > > > > > I understand why rawhide should be frozen at some points, > > > > > > > Openly said, I don't understand this. To me, these freezes are a > > > > > > defect in Rel-Eng's procedures, which could easily be overcome, > > > > > > if they wanted to. > > > > > > What Rel-Eng wants is that the rawhide snapshot that Is To Be > > > > > Fedora- gets beaten to a pulp by us rawhideans. Yes, I'd also > > > > > like for the rollercoaster ride to continue, but there is no way > > > > > around that us crazy bunch needs a little gentle leading to help > > > > > out stabilize the next release. Plus I can imagine that most (all?) > > > > > developers are concentrating on that job, so there are not many > > > > > hands free to work of pushing the envelope forward in any case. > > > > > What I would like to see it Rel-Eng to adopt the development > > > > principles, most other developments apply: > > > > > > > > Decouple "product development" (here: FC) development from > > > > bleeding edge "unstable/experimental" "head development" (here: > > > > rawhide). > > > > Needs more hands. Starves the "product development" of developers and > > > testers. > > > I don't see this - To the contrary. I feel the current model is driving > > away developers and testers, esp. packagers. > > Any hard (or even mushy) data to support this? I am only speaking for myself here. > > > Was the idea in Linux before 2.6, was abandoned for exactly the > > > above reasons. > > > ... but it is the idea which is being applied almost anywhere else. > > Examples? ... GNOME, GCC, binutils, gdb. > > Ask yourself: Is the current development model in Fedora a success? > > Need to define what "success" means... if it is keeping a very popular, > solid distribution moving forward, and gathering more packages, I'd have to > say it is. > > > I don't think so. > > How do you define "success" then? In the sense of "development model assists to achieve a functional and stable product". > Where is Fedora lacking? 2 fundamental issues: * Stability: Initial Fedora CD/DVD releases tend to be pretty buggy and often are unusable. At least to me, most Fedora releases so far only have reached a point of "acceptable quality" several weeks after release. * Support to packagers/ease of use of the infrastructure: One detail amongst many: The freezes are a major handicap to packagers. > No, this is not > just making noise, I'm really interested in the answer. Neither am wanting to make noise. I am simply trying to raise attention to what I consider to be a fundamental problem in Fedora. > > - Fedora releases essentially are rawhide snapshots. Packages from > > rawhide automatically become "stable" (Lack of "rawhide/testing"). E.g. > > I have package upgrades pending, I currently don't want to push to > > Fedora, because I fear them to be too unstable for a product. > > Then they should go to rawhide? If Fedora was using release branches, then this would be a possibility. I'd push these packages to rawhide now, and would push them to an FC10 release branch when having gained confidence these upgrades are stable enough for FC10. The current development model causes me to withhold these upgrades to avoid endangering FC10. => These upgrades with likely be missing in initial FC10 and may (or may not) be added to FC10 later (or never). > Go into your local, That's what they do now => Little attention, little testing. => These upgrades with likely be missing in initial FC10 and may (or may not) be added to FC10 later (or never). == Missed opportunities. > > - Fedora's release process starves package development. E.g. I have > > several (upstream) package upgrades pending, I can't push to Fedora > > because to the freezes are permanently interfering. > > Please elaborate. Freezes are far in between, it would be phenomenal bad > luck if many important upstream just happen to fall into those. And those > can presumably be applied after the freeze is lifted. The problem is: Neither a packager's nor an upstreams' workflow are necessarily synchronized with Rel-Eng's workflow or Fedora release cycles (And if they are, things occasionally tend to get worse.) > > - rawhide is too volatile to be usable for many testers, esp. packagers > > testing their packages. > Heck, rawhide is stable enough for me to use as a regular workstation (with > some precautions), how would that be /so/ different than deoing development > work? A matter of personal objectives: You probably are working on the "Fedora distro". I am working on applications and am using Fedora as a vehicle. > > - The current process introduces a bloated bureaucracy to work around > > the side-effects of "not-branches". > > Please elaborate. I'm sure the people involved would love to get that > workload diminished... /me feels a lot of the bureaucracy and other churn Rel-Eng is imposing on packagers actually is them playing with symptoms of them not applying release branches. Ralf From rc040203 at freenet.de Mon Sep 29 05:46:33 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 29 Sep 2008 07:46:33 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <200809290526.m8T5QPGw012980@laptop14.inf.utfsm.cl> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> <25665.1222660262@sss.pgh.pa.us> <1222663773.3564.355.camel@beck.corsepiu.local> <200809290526.m8T5QPGw012980@laptop14.inf.utfsm.cl> Message-ID: <1222667193.3564.406.camel@beck.corsepiu.local> On Mon, 2008-09-29 at 01:26 -0400, Horst H. von Brand wrote: > Ralf Corsepius wrote: > > On Sun, 2008-09-28 at 23:51 -0400, Tom Lane wrote: > > > "Horst H. von Brand" writes: > > > > Ralf Corsepius wrote: > > > To imagine that it's workable for the majority of > > > projects is to demonstrate lack of connection to reality. > > > Pardon, but you probably can relate, why I have to disagree on this. > > > > I would turn this argument around: The apparent lack of quality of the > > distro, the amount of bureaucracy and ineffectiveness the Fedora > > approach cause are a living proof for a non-functional approach. > > How do you measure "distro quality", My subjective measure is "distro works for me without major effort". Reality is: This doesn't apply. > "amount of bureacracy" (and how much > of that is "too much"), "effectiveness"? koji, bodhi, packagedb, acls, freezes, bugzilla, trac, wikis, mails to rel-eng/, the "incident", the triagers, server downtimes, mirror latencies, bugs not getting fixed, ... All together (not worth mentioning all the bugs and nits they suffer from) have a massive impact on effectiveness. Openly said, it has hardly ever been less effective to contribute to Fedora as it is in recent past. > I'd say the fact that we are discussing this shows that the qualility is at > least decent enough for serious consideration. Certainly - Otherwise, I wasn't be using Fedora. Ralf From giallu at gmail.com Mon Sep 29 07:11:19 2008 From: giallu at gmail.com (Gianluca Sforna) Date: Mon, 29 Sep 2008 09:11:19 +0200 Subject: please deactivate services by default! In-Reply-To: <46a038f90809281647p546dad57xc541ee4a6da6882@mail.gmail.com> References: <1222287197.3941.7.camel@choeger6> <20080924213834.GM1414283@hiwaay.net> <200809251038.34508.billcrawford1970@gmail.com> <20080926220951.4476e7f1@lain.camperquake.de> <48DD4C90.8080608@gmail.com> <16de708d0809261420m61f5a463ma570da78ac8febc9@mail.gmail.com> <200809282017.m8SKHojj006508@laptop14.inf.utfsm.cl> <20080928132539.19d01965@infradead.org> <46a038f90809281647p546dad57xc541ee4a6da6882@mail.gmail.com> Message-ID: On Mon, Sep 29, 2008 at 1:47 AM, Martin Langhoff wrote: > have you guys published your paper and/or slides anywhere after the > plumbers conf? I'm definitely anxious to read it, and went looking for > it in the conference website and the intel lesswatts site a few days > ago. Couldn't find anything... > The only good coverage I've read so far is from LWN: http://lwn.net/Articles/299483/ -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna From pemboa at gmail.com Mon Sep 29 07:44:27 2008 From: pemboa at gmail.com (Arthur Pemberton) Date: Mon, 29 Sep 2008 02:44:27 -0500 Subject: please deactivate services by default! In-Reply-To: References: <1222287197.3941.7.camel@choeger6> <20080924213834.GM1414283@hiwaay.net> <200809251038.34508.billcrawford1970@gmail.com> <20080926220951.4476e7f1@lain.camperquake.de> <48DD4C90.8080608@gmail.com> <16de708d0809261420m61f5a463ma570da78ac8febc9@mail.gmail.com> <200809282017.m8SKHojj006508@laptop14.inf.utfsm.cl> <20080928132539.19d01965@infradead.org> <46a038f90809281647p546dad57xc541ee4a6da6882@mail.gmail.com> Message-ID: <16de708d0809290044h43693cb9sef8fb3568353da2d@mail.gmail.com> On Mon, Sep 29, 2008 at 2:11 AM, Gianluca Sforna wrote: > On Mon, Sep 29, 2008 at 1:47 AM, Martin Langhoff > wrote: >> have you guys published your paper and/or slides anywhere after the >> plumbers conf? I'm definitely anxious to read it, and went looking for >> it in the conference website and the intel lesswatts site a few days >> ago. Couldn't find anything... >> > > The only good coverage I've read so far is from LWN: > > http://lwn.net/Articles/299483/ There is a YouTube video floating around showing the 5 second boot -- Fedora 9 : sulphur is good for the skin ( www.pembo13.com ) From mcrha at redhat.com Mon Sep 29 08:26:30 2008 From: mcrha at redhat.com (Milan Crha) Date: Mon, 29 Sep 2008 10:26:30 +0200 Subject: Unable to expunge some folders, but not all of them In-Reply-To: <1222631754.26543.1.camel@PB3.Linux> References: <1222631754.26543.1.camel@PB3.Linux> Message-ID: <1222676790.2971.16.camel@Lion> On Sun, 2008-09-28 at 20:55 +0100, Paul wrote: > Hi, > > I'm using the current rawhide version of Evolution and have found that > I'm having mixed fortunes expunging folders. Sometimes they will, > sometimes they won't. > > When it fails, all I get it "Failed to expunge" on the message bar. > > Any ideas on how to clear my folders? > > TTFN > > Paul Hi, try to ask on evolution-list at gnome.org You can click the exclamation icon in the status bar to see the detailed error message saying what's going wrong. I think this could be related to Camel disk-summary changes in 2.23 development version and I'm not sure, but I think I saw that in http://bugzilla.gnome.org , maybe related to these: http://bugzilla.gnome.org/show_bug.cgi?id=550414 http://bugzilla.gnome.org/show_bug.cgi?id=552552 Bye, Milan From hughsient at gmail.com Mon Sep 29 10:26:18 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 29 Sep 2008 11:26:18 +0100 Subject: PackageKit-gstreamer-plugin replacing codeina Message-ID: <1222683978.3385.22.camel@hughsie-laptop> When I build the new version of PackageKit today, it will have a new subpackage, PackageKit-gstreamer-plugin. This provides the optional binary /usr/libexec/pk-gstreamer-install which is symlinked to gst-install-plugins-helper. This means we get UI like this http://packagekit.org/img/gpk-client-codecs.png rather than being prompted to pay for codecs using codeina. Should I just add: Obsoletes: codeina < 0.10.1-8 Provides: codeina = 0.10.1-8 to the gstreamer-plugin part of the spec file and be done away with codeina? This would allow people to remove PackageKit-gstreamer-plugin and install codeina if they really wanted, but by default we get the "right" thing installed for the release. Also, we can't do an "everything" install, as both packages provide the gst-install-plugins-helper file. One option might be for the gstreamer package to install a bash script gst-install-plugins-helper, which directs to either codeina, or PackageKit. So what I'm really asking is, do we really want people to be able to: 1. use codeina in F10 2. install PackageKit-gstreamer-plugin and codeina at the same time Advice welcome. Richard. From sundaram at fedoraproject.org Mon Sep 29 10:40:52 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 29 Sep 2008 16:10:52 +0530 Subject: PackageKit-gstreamer-plugin replacing codeina In-Reply-To: <1222683978.3385.22.camel@hughsie-laptop> References: <1222683978.3385.22.camel@hughsie-laptop> Message-ID: <48E0B0B4.4030801@fedoraproject.org> Richard Hughes wrote: > When I build the new version of PackageKit today, it will have a new > subpackage, PackageKit-gstreamer-plugin. > > This provides the optional binary /usr/libexec/pk-gstreamer-install > which is symlinked to gst-install-plugins-helper. > > This means we get UI like this > http://packagekit.org/img/gpk-client-codecs.png rather than being > prompted to pay for codecs using codeina. Why don't you automatically search and display the actual packages if it is available directly? Rahul From hughsient at gmail.com Mon Sep 29 10:57:36 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 29 Sep 2008 11:57:36 +0100 Subject: PackageKit-gstreamer-plugin replacing codeina In-Reply-To: <48E0B0B4.4030801@fedoraproject.org> References: <1222683978.3385.22.camel@hughsie-laptop> <48E0B0B4.4030801@fedoraproject.org> Message-ID: <1222685856.3385.24.camel@hughsie-laptop> On Mon, 2008-09-29 at 16:10 +0530, Rahul Sundaram wrote: > Why don't you automatically search and display the actual packages if > it is available directly? If you click search, then it does. Searching can take a few seconds to complete (minutes if you need to download repo data) and so we should give the user a choice of what to do. Richard. From rawhide at fedoraproject.org Mon Sep 29 12:27:31 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Mon, 29 Sep 2008 12:27:31 +0000 (UTC) Subject: rawhide report: 20080929 changes Message-ID: <20080929122731.3983E1F825C@releng2.fedora.phx.redhat.com> New package R2spec Python script to generate R spec file New package anyremote2html WEB interface for anyRemote New package arora A cross platform web browser New package avogadro Avogadro is an advanced Molecular editor New package blobAndConquer Blob Wars 2: Blob And Conquer New package cl-asdf Another System Definition Facility New package clutter-cairomm C++ wrapper for clutter-cairo library New package clutter-gtkmm C++ wrapper for clutter-gtk library New package common-lisp-controller Common Lisp source and compiler manager New package corosync The Corosync Cluster Engine and Application Programming Interfaces New package cpan-upload Automate the uploading of files to the CPAN (PAUSE) New package ember Ember - a client for Worldforge New package ember-media Media files for the ember WorldForge client New package fet Open source free timetabling software New package generic-release Generic release files New package gnome-applet-jalali-calendar Jalali calendar panel applet for GNOME New package hunspell-ku Kurdish hunspell dictionaries New package hunspell-nso Northern Sotho hunspell dictionaries New package hunspell-oc Occitan hunspell dictionaries New package hunspell-ro Romanian hunspell dictionaries New package hunspell-sq Albanian hunspell dictionaries New package hunspell-ss Swati hunspell dictionaries New package hunspell-st Southern Sotho hunspell dictionaries New package hunspell-tn Tswana hunspell dictionaries New package hunspell-ts Tsonga hunspell dictionaries New package hunspell-uk Ukrainian hunspell dictionaries New package hunspell-ur Urdu hunspell dictionaries New package hunspell-uz Uzbek hunspell dictionaries New package hunspell-ve Venda hunspell dictionaries New package hunspell-vi Vietnamese hunspell dictionaries New package hunspell-wa Walloon hunspell dictionaries New package hunspell-xh Xhosa hunspell dictionaries New package itzam-core Library for creating and manipulating keyed-access database files New package kde-plasma-lancelot An alternative application launcher New package krazy2 Krazy is a tool for checking code against the KDE coding guidelines New package ksplice Patching a Linux kernel without reboot New package libftdi Library to program and control the FTDI USB controller New package libmirage A CD-ROM image access library New package messiggy Messiggy is a database of celestial objects New package moe A powerful clean text editor New package ms-sys Create DOS/MS-compatible boot records New package openoffice-lv Latvian linguistic dictionaries New package orsa Orbit Reconstruction, Simulation and Analysis New package perl-AppConfig-Std Provides standard configuration options New package perl-IPC-Run-SafeHandles Use IPC::Run and IPC::Run3 safely New package perl-Log-Dispatch-Perl Use core Perl functions for logging New package perl-Log-TraceMessages Perl extension for trace messages used in debugging New package perl-Test-HTTP-Server-Simple Test::More functions for HTTP::Server::Simple New package perl-Test-MockTime Replaces actual time with simulated time New package purple-facebookchat Libpurple plug-in supporting facebook IM New package purple-microblog Libpurple plug-in supporting microblog services like Twitter New package python-ethtool Ethernet settings python bindings New package python-prioritized-methods An extension to PEAK-Rules to prioritize methods in order New package python-virtualenv Tool to create isolated Python environments New package rcsslogplayer RoboCup Soccer Simulator LogPlayer New package rcssserver Robocup 2D Soccer Simulation Server New package rssh Restricted shell for use with OpenSSH, allowing only scp and/or sftp New package rsstool Command-line RSS/Atom parser and generator New package sigen An RPG/Strategy engine inspired by the Pok??mon??? games New package sms_ntsc Provides an SMS NTSC video filtering library New package snes_ntsc Provides a SNES NTSC video filtering library New package stk Synthesis ToolKit in C++ New package sugar-calculator Calculator for Sugar New package sugar-chat Chat client for Sugar New package sugar-log Log activity for Sugar New package sugar-write Word processor for Sugar New package system-switch-displaymanager A display manager switcher for GDM, KDM, XDM and WDM New package tcl-snack Sound toolkit New package tcl-tile Modified Tk styling engine New package vdr-streamdev Streaming plugin for VDR New package weplab Analyzing WEP encryption security on wireless networks New package xhtml2fo-style-xsl Antenna House, Inc. XHTML to XSL:FO stylesheets New package xmmsctrl Command line control utility for xmms Removed package libkdcraw Removed package libkexiv2 Removed package libkipi Updated Packages: ConsoleKit-0.3.0-2.fc10 ----------------------- * Tue Sep 16 18:00:00 2008 Ray Strode - 0.3.0-2 - Grab X server display device from XFree86_VT root window property, if X server doesn't have a controlling terminal. GConf2-2.24.0-1.fc10 -------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 - Drop obsolete timeout patch KoboDeluxe-0.5.1-3.fc10 ----------------------- * Wed Sep 24 18:00:00 2008 Tom "spot" Callaway - 0.5.1-3 - avoid variable collision between "pipe2" and unistd.h LabPlot-1.6.0.2-2.fc10 ---------------------- * Wed Sep 24 18:00:00 2008 Tom "spot" Callaway - 1.6.0.2-2 - handle libLabPlotnetCDF.so* * Wed Sep 24 18:00:00 2008 Tom "spot" Callaway - 1.6.0.2-1 - update to 1.6.0.2 - drop useless gcc43 patch, init-smg-before-open-files patch LinLog-0.3.1-1.fc10 ------------------- * Mon Sep 22 18:00:00 2008 Lucian Langa - 0.3.1-1 - new upstream 0.3.1 - add missing sql files - fixed rpm macros - fix build requires - fix desktop file MAKEDEV-3.23-6 -------------- * Fri Sep 19 18:00:00 2008 Dave Airlie 3.23-6 - make it boot faster by renaming a bunch of 00 files into a better order Miro-1.2.7-1.fc10 ----------------- * Sun Sep 28 18:00:00 2008 Alex Lancaster - 1.2.7-1 - Update to 1.2.7 - Rebuild against gecko-libs 1.9.0.2 (#464205) ORBit2-2.14.16-1.fc10 --------------------- * Sun Sep 21 18:00:00 2008 Matthias Clasen - 2.14.16-1 - Update to 2.14.16 * Thu Sep 18 18:00:00 2008 Matthias Clasen - 2.14.15-1 - Update to 2.14.15 PackageKit-0.3.4-5.fc10 ----------------------- * Thu Sep 25 18:00:00 2008 Richard Hughes - 0.3.4-5 - When returning results from a cache we should always return finished in an idle loop so we can block and wait for a response - This fixes the bug where if you have two GetUpdates in the queue the second would hang waiting for the first, even though it had already finished. * Tue Sep 23 18:00:00 2008 Richard Hughes - 0.3.4-4 - Fix the error dialog when no mirrors are found * Tue Sep 23 18:00:00 2008 Richard Hughes - 0.3.4-3 - Don't try to run all the committed transactions at once with a deep queue. - This fixes the bug where the dispatcher would sometimes fail to run the next method and PkSpawn would warn the user with 'timeout already set'. * Tue Sep 23 18:00:00 2008 Richard Hughes - 0.3.4-2 - Don't send ::Finished when the script exits because of a dispatcher exit. - This only seems to happen when we are making the dispatcher be reloaded from multiple sessions with different locales. * Mon Sep 22 18:00:00 2008 Richard Hughes - 0.3.4-1 - New upstream version * Wed Sep 17 18:00:00 2008 Richard Hughes - 0.3.3-3 - Fix a silly typo where we might upgrade the kernel when we check for distro upgrades. * Tue Sep 16 18:00:00 2008 Richard Hughes - 0.3.3-2 - Fix an error where we didn't connect up the GetDistroUpgrades in the new dispatcher code. * Tue Sep 16 18:00:00 2008 Richard Hughes - 0.3.3-1 - New upstream version - Fixes a nasty bug where the daemon could get locked under heavy load - Adds collection support for group install and remove PolicyKit-0.9-3.fc10 -------------------- * Fri Sep 19 18:00:00 2008 Matthias Clasen - 0.9-3 - Plug a memory leak PyAmanith-0.3.35-3.fc10 ----------------------- * Wed Sep 24 18:00:00 2008 Tom "spot" Callaway 0.3.35-3 - rework PyAmanith-0.3.34-buildfix.patch to apply without fuzz PyOpenGL-3.0.0-0.8.b6.fc10 -------------------------- * Mon Sep 22 18:00:00 2008 Nikolay Vladimirov 3.0.0-0.8.b6 - New upstream release 3.0.0b6 PyX-0.10-4.fc10 --------------- R-Matrix-0.999375-5.fc10 ------------------------ * Mon Sep 15 18:00:00 2008 Tom "spot" Callaway - 0.999375-5 - update to packrel=14 R-RScaLAPACK-0.5.1-18.fc10 -------------------------- * Wed Sep 24 18:00:00 2008 Tom "spot" Callaway - 0.5.1-18 - ... and forgot to remove one last bit of the lam ick * Wed Sep 24 18:00:00 2008 Tom "spot" Callaway - 0.5.1-17 - forgot to add one patch * Wed Sep 24 18:00:00 2008 Tom "spot" Callaway - 0.5.1-16 - use openmpi instead of lam R-maanova-1.10.0-1.fc10 ----------------------- * Fri May 2 18:00:00 2008 Pingou 1.10.0-1 - Update to bioconductor 2.2 SimGear-1.0.0-5.fc10 -------------------- * Wed Sep 24 18:00:00 2008 Tom "spot" Callaway 1.0.0-5 - fix SimGear-0.3.10-notabbed_value_test.patch to apply without fuzz TurboGears-1.0.7-2.fc10 ----------------------- * Wed Sep 17 18:00:00 2008 Luke Macken 1.0.7-2 - Add a patch to allow newer versions of TurboJson * Tue Sep 16 18:00:00 2008 Luke Macken 1.0.7-1 - Update to the latest upstream release - Utilize the test suite - Remove the setup.py patch UnihanDb-5.1.0-7.fc10 --------------------- * Tue Sep 23 18:00:00 2008 Ding-Yi Chen - 5.1.0-7 - Correct counting in FreqRank field of kMandarin table. WindowMaker-0.92.0-18.fc10 -------------------------- * Wed Sep 24 18:00:00 2008 Tom "spot" Callaway - 0.92.0-18 - fix patches to apply without fuzz - adjust URL/Source to new website Zim-0.26-1.fc10 --------------- * Thu Sep 25 18:00:00 2008 Chris Weyl 0.26-1 - update to 0.26 a2ps-4.14-6.fc10 ---------------- * Wed Sep 24 18:00:00 2008 Tim Waugh 4.14-6 - Removed patch fuzz. abcMIDI-20080924-1.fc10 ----------------------- * Wed Sep 24 18:00:00 2008 Gerard Milmeister - 20080924-1 - new release 2008-09-24 abcm2ps-5.9.0-1.fc10 -------------------- * Sun Sep 28 18:00:00 2008 Gerard Milmeister - 5.9.0-1 - new release 5.9.0 abiword-2.6.4-8.fc10 -------------------- * Fri Sep 26 18:00:00 2008 Tom "spot" Callaway - 1:2.6.4-8 - add t1lib-devel to BuildRequires, fixes FTBFS acpitool-0.5-1.fc10 ------------------- * Thu Sep 18 18:00:00 2008 Patrice Dumas 0.5-1 - update to 0.5 afflib-3.3.3-3.fc10 ------------------- * Mon Sep 15 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.3.3-3 - Update to 3.3.3 aide-0.13.1-5.fc10 ------------------ * Fri Sep 26 18:00:00 2008 Tom "spot" Callaway - 0.13.1-5 - fix selcon patch to apply without fuzz aimage-3.2.0-1.fc10 ------------------- * Tue Sep 23 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.2.0-1 - Update to 3.2.0 akode-2.0.2-6.fc10 ------------------ * Fri Sep 26 18:00:00 2008 Tom "spot" Callaway 2.0.2-6 - fix pulseaudio patch to apply without fuzz alacarte-0.11.6-3.fc10 ---------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 0.11.6-3 - Update to 0.11.6 ale-0.9.0.1-2.fc10 ------------------ * Tue Sep 23 18:00:00 2008 Douglas E. Warner 0.9.0.1-2 - updated gcc4.3 patch for 0.9.0.1 to compile w/ new fuzz settings alienarena-7.10-2.fc10 ---------------------- * Fri Sep 26 18:00:00 2008 Tom "spot" Callaway - 7.10-2 - drop fhs patch, use Makefile DATADIR options instead alliance-5.0-21.20070718snap.fc10 --------------------------------- * Mon Sep 15 18:00:00 2008 Chitlesh Goorah - 5.0-21.20070718snap - Bugfix : Alliance incorrectly mungs your path and adds the cwd to the path #459336 - Bugfix : Latest alc_env fixes broken system man path #452645 alsa-utils-1.0.18-3.rc3.fc10 ---------------------------- * Thu Sep 18 18:00:00 2008 Jaroslav Kysela 1.0.18-3.rc3 - fixed alsa-info.sh link * Thu Sep 18 18:00:00 2008 Jaroslav Kysela 1.0.18-2.rc3 - fixed /lib/alsa/init path for x86_64 (was /lib64/alsa/init) - added /etc/alsa/asound.state -> /etc/asound.state shift to %post section - fix udev rules (ommited /dev/ prefix for the alsactl utility) - added --ignore option for alsactl (added also to upstream) amanith-0.3-9.fc10 ------------------ anacron-2.3-64.fc10 ------------------- * Wed Jul 30 18:00:00 2008 Marcela Maslanova 2.3-64 - fix fuzz - fix previous patch, thanks to mbroz * Wed Jul 30 18:00:00 2008 Marcela Maslanova 2.3-62 - 441576 really stop anacron daemon anjuta-2.4.2-1.fc10 ------------------- * Sat Sep 20 18:00:00 2008 Debarshi Ray - 1:2.4.2-1 - Version bump to 2.4.2. - Enabled Valgrind plugin and added 'BuildRequires: binutils-devel'. ant-1.7.1-7.1.fc10 ------------------ * Fri Sep 26 18:00:00 2008 Permaine Cheung 0:1.7.1-7.1 - Define with_gcj_support * Tue Sep 23 18:00:00 2008 Permaine Cheung 0:1.7.1-7 - Update to 1.7.1 - Fix some rpmlint issues * Tue Jul 15 18:00:00 2008 David Walluck 0:1.7.1-7 - enable non-bootstrap * Tue Jul 15 18:00:00 2008 David Walluck 0:1.7.1-6 - add ant-bootstrap jar if bootstrap is enabled - enable jmf, swing, trax if bootstrap is enabled - BuildRequires: jaxp_transform_impl - BuildRequires: junit for non-bootstrap * Tue Jul 15 18:00:00 2008 David Walluck 0:1.7.1-5 - enable ant-nodeps in bootstrap mode * Tue Jul 15 18:00:00 2008 David Walluck 0:1.7.1-4 - remove junit for bootstrap * Tue Jul 15 18:00:00 2008 David Walluck 0:1.7.1-3 - build as bootstrap * Tue Jul 15 18:00:00 2008 David Walluck 0:1.7.1-2 - set rpm_mode=false by default * Thu Jul 10 18:00:00 2008 David Walluck 0:1.7.1-1 - 1.7.1 - update maven pom files - rediff apache-ant-jars.patch - rediff apache-ant-bz163689.patch - add apache-ant-gnu-classpath.patch - set rpm_mode=true in conf since the ant script handles the rest * Thu Jul 10 18:00:00 2008 David Walluck 0:1.7.0-3 - add bootstrap mode - replace some alternatives/virtual requires by explicit requires - remove javadoc scriptlets - fix GCJ support - add workaround for xalan-j2 in %{_sysconfdir}/%{name}.d/trax - version Obsoletes and add Provides - remove Conflicts - mark files in %{_sysconfdir} as %config(noreplace) appliance-tools-003-4.fc10 -------------------------- * Wed Sep 17 18:00:00 2008 David Huff - 003-4 - Removed all the kickstart files in the config dir to mirror livecd-tools - Added the image minimization to the refactored code (BKearney) - multiple interface issue (#460922) - added --format option to specity disk image format - added --package option to specify output, currently only .zip supported - added --vmem and --vcpu options - Merged ec2-converter code (jboggs) archivemail-0.7.2-2.fc10 ------------------------ * Fri Sep 12 18:00:00 2008 Jon Ciesla 0.7.2-2 - Introduced patch fuzz workaround, will fix. ardour-2.5-2.fc10 ----------------- * Sun Sep 21 18:00:00 2008 Anthony Green 2.5-2 - Add HOST_NOT_FOUND patch. * Thu Jul 10 18:00:00 2008 Anthony Green 2.5-1 - New upstream release 2.5. arpack-2.1-10.fc10 ------------------ * Wed Sep 24 18:00:00 2008 Dominik 'Rathann' Mierzejewski 2.1-10 - fix libarpack.so: undefined reference to `etime_' with recent gfortran * Mon Aug 25 18:00:00 2008 Axel Thimm - 2.1-9 - Patch0 and %patch make recent rpm silenty fail. * Wed May 21 18:00:00 2008 Tom "spot" Callaway 2.1-8 - fix license tag arpwatch-2.1a15-9.fc10 ---------------------- * Tue Sep 16 18:00:00 2008 Miroslav Lichvar 14:2.1a15-9 - update ethercodes.dat (#462364) astyle-1.21-9.fc10 ------------------ * Wed Sep 24 18:00:00 2008 Debarshi Ray - 1.21-9 - Fixed build failure with gcc-4.3. Closes Red Hat Bugzilla bug #433971. * Wed May 21 18:00:00 2008 Tom "spot" Callaway - 1.21-8 - fix license tag * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 1.21-7 - Autorebuild for GCC 4.3 asylum-0.2.4-3.fc10 ------------------- * Fri Sep 26 18:00:00 2008 Tom "spot" Callaway - 0.2.4-3 - fix makefile patch to apply properly * Fri Aug 29 18:00:00 2008 Michael Fleming - 0.2.4-2 - New builders don't like Patch0 declaration, adjust make it happy * Fri Aug 29 18:00:00 2008 Michael Fleming - 0.2.4-1 - Upgrade to 0.2.4 at-3.1.10-25.fc10 ----------------- * Tue Sep 16 18:00:00 2008 Marcela Maslanova - 3.1.10-25 - thanks dwalsh for selinux patch, which fix #460873 at-spi-1.24.0-2.fc10 -------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 1.24.0-2 - Update to 1.24.0 atk-1.24.0-1.fc10 ----------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 1.24.0-1 - Update to 1.24.0 aumix-2.8-18.fc10 ----------------- * Fri Sep 26 18:00:00 2008 Gabriel L. Somlo 2.8-18 - re-based patches to eliminate fuzz autoconf-2.63-1.fc10 -------------------- * Wed Sep 17 18:00:00 2008 Stepan Kasal 2.63-1 - upstream bugfix release - all patches dropped, the issues are fixed upstream autofs-5.0.3-25 --------------- * Fri Sep 26 18:00:00 2008 Ian Kent - 5.0.3-25 - fix fd leak at multi-mount non-fatal mount fail. - fix incorrect multi-mount mountpoint calcualtion. * Fri Sep 19 18:00:00 2008 Ian Kent - 5.0.3-23 - add upstream bug fixes - bug fix for mtab check. - bug fix for zero length nis key. - update for ifc buffer handling. - bug fix for kernel automount handling. - warning: I found a bunch of patches that were present but not being applied. automaton-1.10r5-1.fc10 ----------------------- * Fri Sep 12 18:00:00 2008 Jerry James - 1.10r5-1 - Upgrade to 1.10-5 bash-completion-20060301-13 --------------------------- * Thu Sep 11 18:00:00 2008 Ville Skytt?? - 20060301-13 - Borrow/improve/adapt to Fedora some patches from Mandriva: improved support for getent and rpm --eval, better rpm backup file avoidance, lzma support. - Patch/unpatch to fix gzip and bzip2 options completion. - Patch to add --rsyncable to gzip options completion. - Add and trigger-install support for lzop. - Associate *.sqlite with sqlite3. bigloo-3.1b-2.fc10 ------------------ * Thu Sep 18 18:00:00 2008 Gerard Milmeister - 3.1b-1 - new release 3.1b bind-9.5.1-0.7.b2.fc10 ---------------------- * Wed Sep 24 18:00:00 2008 Adam Tkac 32:9.5.1-0.7.b2 - 9.5.1b2 release - patches merged - bind95-rh454783.patch - bind-9.5-edns.patch - bind95-rh450995.patch - bind95-rh457175.patch * Wed Sep 17 18:00:00 2008 Adam Tkac 32:9.5.1-0.6.b1 - IDN output strings didn't honour locale settings (#461409) binutils-2.18.50.0.9-5.fc10 --------------------------- * Mon Sep 22 18:00:00 2008 Jan Kratochvil 2.18.50.0.9-5 - Remove %makeinstall to comply with the spu-binutils review (BZ 452211). * Mon Sep 22 18:00:00 2008 Jan Kratochvil 2.18.50.0.9-4 - Fix *.so scripts for multilib linking (BZ 463101, suggested by Jakub Jelinek). * Sun Sep 21 18:00:00 2008 Jan Kratochvil 2.18.50.0.9-3 - Provide libbfd.so and libopcodes.so for automatic dependencies (BZ 463101). - Fix .eh_frame_hdr build on C++ files with discarded common groups (BZ 458950). - Provide --build and --host to fix `rpmbuild --target' biarch builds. - Include %{binutils_target}- filename prefix for binaries for cross builds. - Fix multilib conflict on /usr/include/bfd.h's BFD_HOST_64BIT_LONG_LONG. * Mon Sep 15 18:00:00 2008 Jan Kratochvil 2.18.50.0.9-2 - Package review, analysed by Jon Ciesla and Patrice Dumas (BZ 225615). - build back in the sourcedir without problems as gasp is no longer included. - Fix the install-info requirement. - Drop the needless gzipping of the info files. - Provide Obsoletes versions. - Use the %configure macro. blacs-1.1-30.fc10 ----------------- * Tue Sep 23 18:00:00 2008 Tom "spot" Callaway - 1.1-30 - incorporate Deji Akingunola's changes - use openmpi rather than lam blam-1.8.5-2.fc10 ----------------- * Wed Sep 24 18:00:00 2008 Christopher Aillon - 1.8.5-2 - Rebuild against newer gecko bluecurve-icon-theme-8.0.2-2.fc10 --------------------------------- * Wed Sep 24 18:00:00 2008 Matthias Clasen - 8.0.2-2 - Split off cursor theme as a separate package bluez-4.7-1.fc10 ---------------- * Fri Sep 26 18:00:00 2008 - Bastien Nocera - 4.7-1 - Update to 4.7 * Wed Sep 24 18:00:00 2008 - Bastien Nocera - 4.6-4 - Fix patch application * Wed Sep 24 18:00:00 2008 - Bastien Nocera - 4.6-3 - Add fuzz * Wed Sep 24 18:00:00 2008 - Bastien Nocera - 4.6-2 - Fix possible crasher on resume from suspend bluez-gnome-1.5-1.fc10 ---------------------- * Sat Sep 27 18:00:00 2008 - Bastien Nocera - 1.5-1 - Update to 1.5 * Tue Sep 23 18:00:00 2008 - Bastien Nocera - 1.4-4 - Update bluetooth-sendto to the BlueZ 4.x API, and obex-data-server SVN APIs * Sun Sep 14 18:00:00 2008 - David Woodhouse - Tidy up specfile, fix source URL * Sun Sep 14 18:00:00 2008 - Bastien Nocera - 1.4-3 - Add missing files to the list * Sat Sep 13 18:00:00 2008 - Bastien Nocera - 1.4-2 - Remove obsolete patch * Sat Sep 13 18:00:00 2008 - Bastien Nocera - 1.4-1 - Update to 1.4 bluez-hcidump-1.42-2.fc10 ------------------------- * Mon Sep 22 18:00:00 2008 - David Woodhouse - 1.42-2 - Rebuild for libbluetooth.so.3 bmpx-0.40.14-7.fc10 ------------------- * Sun Sep 14 18:00:00 2008 josef radinger - 0.40.14-7 - cvs problems * Sat Sep 13 18:00:00 2008 josef radinger - 0.40.14-6 - fix patch libsoup - add hostnotfound-patch - remove cdparanoia, use libcdio (for now) bontmia-0.14-3.fc10 ------------------- * Sun Sep 21 18:00:00 2008 Terje Rosten - 0.14-3 - Fix patch macro brasero-0.8.2-1.fc10 -------------------- * Mon Sep 15 18:00:00 2008 Denis Leroy - 0.8.2-1 - Update to upstream 0.8.2 brltty-3.10-1.fc10 ------------------ * Sat Sep 13 18:00:00 2008 Stepan Kasal - 3.10-1 - new upstream release - drop brltty-3.9-java-svn.patch, brltty-3.9-tcl85path.patch, and brltty-3.9-pyxfix.patch, they are upstream - fix BuildRoot - fix many sub-packages' Requires on brlapi * Wed Sep 10 18:00:00 2008 Stepan Kasal - 3.9-3 - add brltty-3.9-autoconf.patch to fix to build with Autoconf 2.62 - add brltty-3.9-parallel.patch to fix race condition with parallel make - add brltty-3.9-pyxfix.patch to fix build with current pyrex - Summary lines shall not end with a dot bug-buddy-2.24.0-1.fc10 ----------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 1:2.24.0-1 - Update to 2.24.0 bwbar-1.2.3-3 ------------- * Mon Sep 1 18:00:00 2008 Adrian Reber - 1.2.3-3 - recreated bwbar.daemon.patch to apply cleanly bzr-1.7-1.fc10 -------------- * Thu Sep 25 18:00:00 2008 Toshio Kuratomi - 1.7-1 - 1.7 Final bzr-gtk-0.95.0-2.fc10 --------------------- * Thu Sep 25 18:00:00 2008 Toshio Kuratomi 0.95.0-2 - Update for fixed nautilus-python package. bzrtools-1.7.0-1.fc10 --------------------- * Thu Sep 18 18:00:00 2008 Toshio Kuratomi 1.7.0-1 - Update to 1.7.0 cairo-1.8.0-1.fc10 ------------------ * Thu Sep 25 18:00:00 2008 Behdad Esfahbod 1.8.0-1 - Update to 1.8.0 - Update dep versions * Mon Sep 22 18:00:00 2008 Behdad Esfahbod 1.7.6-1 - Update to 1.7.6 cairo-dock-1.6.3-0.1.svn1319_trunk.fc10 --------------------------------------- * Thu Sep 25 18:00:00 2008 Mamoru Tasaka - rev 1319 cdpr-2.3-1.fc10 --------------- * Sat Sep 20 18:00:00 2008 Michael Stahnke - 2.3-1 - New version certmaster-0.23-1.fc10 ---------------------- cfengine-2.2.8-2.fc10 --------------------- * Sat Sep 27 18:00:00 2008 Jeff Sheltren 2.2.8-2 - Patch configure to detect db-4.7 (#461942) cfitsio-3.100-1.fc10 -------------------- * Fri Sep 19 18:00:00 2008 Matthew Truch - 3.100-1 - Update to 3.100 upstream. Includes bugfixes and new compression scheme. cheese-2.24.0-1.fc10 -------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen 2.24.0-1 - Update to 2.24.0 cluster-2.99.10-5.fc10 ---------------------- * Fri Sep 26 18:00:00 2008 Fabio M. Di Nitto - 2.99.10-5 - cman now Requires: ricci and modcluster. * Fri Sep 26 18:00:00 2008 Fabio M. Di Nitto - 2.99.10-4 - Split libcman.so* from cman and cman-devel into cmanlib and cmanlib-devel to break a very annoying circular dependency. * Thu Sep 25 18:00:00 2008 Fabio M. Di Nitto - 2.99.10-3 - The "CVS HATES ME" release. - New upstream release. - Build against new corosync and openais. - specfile cleanup: rename buildxen to buildvirt. * Thu Sep 25 18:00:00 2008 Fabio M. Di Nitto - 2.99.10-2 - Retag release. - New upstream release. - Build against new corosync and openais. - specfile cleanup: rename buildxen to buildvirt. * Thu Sep 25 18:00:00 2008 Fabio M. Di Nitto - 2.99.10-1 - New upstream release. - Build against new corosync and openais. - specfile cleanup: rename buildxen to buildvirt. clustermon-0.15.0-3.fc10 ------------------------ * Fri Sep 26 18:00:00 2008 Fabio M. Di Nitto 0.15.0-3 - Change BuildRequires from cman-devel to cmanlib-devel * Thu Sep 25 18:00:00 2008 Fabio M. Di Nitto 0.15.0-2 - Add versioned BR on cman-devel clutter-gst-0.8.0-2.fc10 ------------------------ * Fri Sep 12 18:00:00 2008 Allisson Azevedo 0.8.0-2 - Rebuild against new gstreamer-devel cluttermm-0.7.3-2.fc10 ---------------------- * Mon Sep 15 18:00:00 2008 Denis Leroy - 0.7.3-2 - Fixed devel requires cobbler-1.2.5-1.fc10 -------------------- * Fri Sep 26 18:00:00 2008 Michael DeHaan - 1.2.5-1 - Upstream changes (see CHANGELOG) coda-6.9.4-0.3.rc2.fc10 ----------------------- * Sun Sep 14 18:00:00 2008 Adam Goode - 6.9.4-0.3.rc2 - Do not change the default behavior of clog when building with krb5 (rh 462179) codeblocks-8.02-3.fc10 ---------------------- * Sat Sep 20 18:00:00 2008 Dan Horak 8.02-3 - update desktop file - fix running console applications (#461120) collectl-3.1.0-1.fc10 --------------------- * Mon Sep 22 18:00:00 2008 Dan Horak 3.1.0-1 - upgrade to upstream version 3.1.0 - remove logrotate support because internal mechanism is used by default compat-db-4.6.21-4.fc10 ----------------------- * Tue Sep 16 18:00:00 2008 Jindrich Novy 4.6.21-4 - build also if db4 is not installed (thanks to Michael A. Peters) compiz-0.7.6-11.fc10 -------------------- * Thu Sep 25 18:00:00 2008 Jon McCann - 0.7.6-11 - Add compiz-gtk driver script and desktop file - New desktop effects release comps-extras-14-1 ----------------- * Wed Sep 24 18:00:00 2008 Bill Nottingham - 14-1 - make more echo-y conduit-0.3.14-1.fc10 --------------------- * Sun Sep 21 18:00:00 2008 Michel Salim - 0.3.14-1 - Update to 0.3.14 control-center-2.24.0.1-1.fc10 ------------------------------ * Wed Sep 24 18:00:00 2008 Matthias Clasen - 2.24.0.1-1 - Update to 2.24.0.1 * Tue Sep 23 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 coolkey-1.1.0-7.fc10 -------------------- * Sun Sep 14 18:00:00 2008 Matt Domsch - 1.1.0-7 - BR: nss-devel not mozilla-nss-devel (FTBFS BZ#440753) cpuspeed-1.2.1-9.fc10 --------------------- * Fri Sep 26 18:00:00 2008 Jarod Wilson 1.2.1-9 - backport proper multicore support for userspace governor (cpuspeed daemon) case from v1.5 cpuspeed snapshot cronie-1.2-3.fc10 ----------------- * Thu Sep 25 18:00:00 2008 Marcela Maslanova - 1.2-3 - add sendmail file into requirement, cause it's needed some MTA * Thu Sep 18 18:00:00 2008 Marcela Maslanova - 1.2-2 - 462252 /etc/sysconfig/crond does not need to be executable cryptsetup-luks-1.0.6-5.fc10 ---------------------------- * Tue Sep 23 18:00:00 2008 Milan Broz - 1.0.6-5 - Change new project home page. - Print more descriptive messages for initialization errors. - Refresh patches to versions commited upstream. csmash-0.6.6-19 --------------- * Mon Sep 15 18:00:00 2008 Matthias Saou 0.6.6-19 - Fix desktop file (#462261). - Convert README file to UTF-8. ctemplate-0.91-3.fc10 --------------------- * Tue Sep 23 18:00:00 2008 Dennis Gilmore - 0.91-3 - clean up headers so that they include each other as intended curl-7.18.2-7.fc10 ------------------ * Tue Sep 9 18:00:00 2008 Jindrich Novy 7.18.2-7 - update the thread safety patch, thanks to Rob Crittenden (#462217) cyrus-imapd-2.3.12p2-3.fc10 --------------------------- * Fri Sep 26 18:00:00 2008 Dan Hor??k - 2.0.2-3 - revert last change and require policycoreutils for post (mtasaka, #462221) * Fri Sep 19 18:00:00 2008 Jens Petersen - 2.0.2-2 - use full paths to selinux tools in %post (Jon Stanley, #462221) * Sat Jun 28 18:00:00 2008 Jeremy Hinegardner - 2.0.2-1 - split out the manual to a -doc rpm - update to 2.0.2 - switch to make test - remove skipping of tests - it doesn't appear to apply anymore db4-4.7.25-5.fc10 ----------------- * Tue Sep 16 18:00:00 2008 Jindrich Novy 4.7.25-5 - build also if db4 is not installed (thanks to Michael A. Peters) dbus-1.2.3-2.fc10 ----------------- * Thu Sep 25 18:00:00 2008 David Zeuthen - 1.2.3-2.fc10 - Avoid using noreplace for files that aren't really config files dbus-python-0.83.0-3.fc10 ------------------------- * Tue Sep 16 18:00:00 2008 Marco Pesenti Gritti - 0.83.0-3 - Add patch for https://bugs.freedesktop.org/show_bug.cgi?id=17551 deluge-1.0.0-1.fc10 ------------------- * Sat Sep 27 18:00:00 2008 Peter Gordon - 1.0.0-1 - Update to new upstream release (1.0.0 Final) - Apply patch from Mamoru Tasaka to build against the multi-threaded Boost libraries once more: + mt-boost-fix.patch - Resolves: #464151 (About 1.0.0 build failure) * Tue Sep 16 18:00:00 2008 Peter Gordon - 0.9.09-1 - Update to new upstream release candidate (1.0.0 RC9) - Drop mt-boost patch (fixed upstream): - use-mt-boost.patch denyhosts-2.6-13.fc10 --------------------- * Mon Sep 22 18:00:00 2008 Jason L Tibbitts III - 2.6-13 - Add plugin to restore file contexts after purging. deskbar-applet-2.24.0-1.fc10 ---------------------------- * Fri Sep 26 18:00:00 2008 Luke Macken - 2.24.0-1 - Latest upstrem release devhelp-0.21-2.fc10 ------------------- * Wed Sep 24 18:00:00 2008 Matthias Clasen - 0.21-2 - Rebuild against newer gecko * Mon Sep 22 18:00:00 2008 Matthias Clasen - 0.21-1 - Update to 0.21 device-mapper-multipath-0.4.8-7.fc10 ------------------------------------ * Fri Sep 26 18:00:00 2008 Benjamin Marzinski 0.4.8-7 - Since libaio is now in /lib, not /usr/lib, multipath no longer needs to statically link against it. Fixed an error with binding file and WWIDs that include spaces. Cleaned up the messages from the directio checker function. Fixed the udev rules. Fixed a regression in multipath.conf parsing - Fixed 457530, 457589 dhcp-4.0.0-24.fc10 ------------------ * Tue Sep 16 18:00:00 2008 David Cantrell - 12:4.0.0-24 - 'server' -> 'service' in dhclient-script (#462343) digikam-0.10.0-0.4.beta3.fc10 ----------------------------- * Fri Sep 26 18:00:00 2008 Rex Dieter - 0.10.0-0.4.beta3 - digikam-0.10.0-beta3 dirac-1.0.0-1.fc10 ------------------ * Sun Sep 28 18:00:00 2008 kwizart < kwizart at gmail.com > - 1.0.0-1 - Update to 1.0.0 dmraid-1.0.0.rc15-1.fc10 ------------------------ * Thu Sep 25 18:00:00 2008 Heinz Mauelshagen - 1.0.0.rc15-1 - Update to version 1.0.0.rc15 docbook-dtds-1.0-41.fc10 ------------------------ * Fri Sep 26 18:00:00 2008 Ondrej Vasik - 1.0-41 - Removed openjade requirement - registration reworked to triggers(#234345) * Wed Sep 24 18:00:00 2008 Ondrej Vasik - 1.0-40 - Fix wrong filenames for xml-dtd-4.4 and xml-dtd-4.5 iso entities(#461206) - /ent/iso-cyr1.ent now correctly registered in xml catalog (there was /ent/iso-cyrl.ent typo) - fixed broken unregistration of xml-dtds from catalog (missing CAT_DIR variable) dos2unix-3.1-34.fc10 -------------------- * Wed Sep 24 18:00:00 2008 Tim Waugh 3.1-34 - Moved 'make clean' to prep section and added comment about there being no upstream (bug #225706). dstat-0.6.8-1.fc10 ------------------ * Tue Sep 16 18:00:00 2008 Zdenek Prikryl - 0.6.8-1 - Updated to 0.6.8 - Fixed dbus module patch dwdiff-1.4-2.fc10 ----------------- * Sun Sep 21 18:00:00 2008 Ville Skytt?? - 1.4-2 - Fix Patch0:/%patch mismatch. dx-4.4.4-7.fc10 --------------- * Wed Sep 24 18:00:00 2008 Dominik Mierzejewski 4.4.4-7 - rediff patch to fix build with new rpm eclipse-3.4.0-24.fc10 --------------------- * Thu Sep 25 18:00:00 2008 Michal Nowak 3.4.0-24 - exclude parts of eclipse-pydev from JIT compilation - Resolves: bug 461860 eclipse-checkstyle-4.0.1-11.fc10 -------------------------------- * Wed Jul 30 18:00:00 2008 Andrew Overholt 4.0.1-11 - Update for Eclipse SDK 3.4 eclipse-egit-0.3.1-2.fc10 ------------------------- * Wed Jul 30 18:00:00 2008 Andrew Overholt 0.3.1-2 - Move files and update build for Eclipse SDK 3.4 - Use pdebuild * Thu Jul 17 18:00:00 2008 Tom "spot" Callaway - 0.3.1-1 - fix license tag eel2-2.24.0-2.fc10 ------------------ * Mon Sep 22 18:00:00 2008 Ray Strode - 2.24.0-2 - Don't fade desktop from themed gray color at startup * Sun Sep 21 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 * Thu Sep 18 18:00:00 2008 Ray Strode - 2.23.92-2 - When switching desktop backgrounds fade between them eigen2-2.0-0.4.beta1.fc10 ------------------------- * Mon Sep 22 18:00:00 2008 Rex Dieter 2.0-0.4.beta1 - eigen-2.0-beta1 ekiga-3.0.0-2.fc10 ------------------ * Tue Sep 23 18:00:00 2008 Peter Robinson - 3.0.0-2 - add libnotify-devel as a build dep * Tue Sep 23 18:00:00 2008 Peter Robinson - 3.0.0-1 - Ekiga 3 final release elektra-0.6.10-8.fc10 --------------------- * Thu Sep 18 18:00:00 2008 Matt Domsch - 0.6.10-8 - add -D_GNU_SOURCE to CFLAGS, fixes FTBFS BZ#434364 * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 0.6.10-7 - Autorebuild for GCC 4.3 elice-0.313-1.fc10 ------------------ * Sun Sep 14 18:00:00 2008 Hans de Goede 0.313-1 - New upstream release 0.313 emacs-bbdb-2.35-9.20080928cvs.fc10 ---------------------------------- * Sun Sep 28 18:00:00 2008 Jonathan G. Underwood - 2.35-9.20080928cvs - Update to current CVS snapshot, fixing several bugs - Ensure that bbdb-vm.elc is built and installed (BZ 462875) - Add --enable-developer to configure for more verbose build info emacs-vm-8.0.11.581-1.fc10 -------------------------- * Sat Sep 27 18:00:00 2008 Jonathan G. Underwood - 8.0.11.581-1 - Update to 8.0.11-581 emacspeak-28.0-3.fc10 --------------------- * Fri Sep 26 18:00:00 2008 Jens Petersen - 28.0-3 - (CVE-2008-4191) fix tmpfile vulnerability in extract-table.pl with emacspeak-28.0-tmpfile.patch from upstream svn (#463821) * Fri Sep 26 18:00:00 2008 Jens Petersen - 28.0-2 - fix broken generated deps reported by mtasaka (#463899) - script the replacement of tcl with tclsh to fix missing dtk-soft - replace python2.4 with python in HTTPSpeaker.py * Thu Sep 25 18:00:00 2008 Jens Petersen - 28.0-1 - update to 28.0 with emacspeak-28.0-no-httpd.patch - replace emacspeak-tcl-pkgreq-tclx.patch with sed - emacspeak-no-linux-espeak.patch no longer needed - update emacspeak-15.0-fixpref.patch for patch fuzz empathy-2.24.0-1.fc10 --------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 eog-2.24.0-1.fc10 ----------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 epiphany-2.24.0.1-3.fc10 ------------------------ * Thu Sep 25 18:00:00 2008 Matthias Clasen - 2.24.0.1-3 - Save some space * Tue Sep 23 18:00:00 2008 Matthias Clasen - 2.24.0.1-2 - Update to 2.24.0.1 * Tue Sep 23 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 eventlog-0.2.7-1.fc10 --------------------- * Wed Apr 9 18:00:00 2008 Douglas E. Warner 0.2.7-1 - updated to 0.2.7 library - removed static library evince-2.24.0-1.fc10 -------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 * Fri Sep 12 18:00:00 2008 Marek Kasik - 2.23.92-2 - fix duplex printing of copies - upstream bug #455759 evolution-2.24.0-2.fc10 ----------------------- * Thu Sep 25 18:00:00 2008 Matthew Barnes - 2.24.0-2.fc10 - Strip unneeded translations from .mo files (RH bug #463887). - Split Perl-based utilities into a "perl" subpackage (RH bug #462345). * Mon Sep 22 18:00:00 2008 Matthew Barnes - 2.24.0-1.fc10 - Update to 2.24.0 evolution-brutus-1.2.27-1.fc10 ------------------------------ * Sun Sep 21 18:00:00 2008 Alex Lancaster - 1.2.27-1 - Update to 1.2.27 * Thu Sep 11 18:00:00 2008 Jesse Keating - 1.2.17-2 - Rebuild for broken deps. evolution-data-server-2.24.0-1.fc10 ----------------------------------- * Mon Sep 22 18:00:00 2008 Matthew Barnes - 2.24.0-1.fc10 - Update to 2.24.0 evolution-exchange-2.24.0-1.fc10 -------------------------------- * Mon Sep 22 18:00:00 2008 Matthew Barnes - 2.24.0-1.fc10 - Update to 2.24.0 * Thu Sep 18 18:00:00 2008 Matthew Barnes - 2.23.92-2.fc10 - Fix unowned directories (RH bug #462346). evolution-rss-0.1.1-3.fc10 -------------------------- * Sat Sep 27 18:00:00 2008 Lucian Langa - 0.1.1-3 - new upstream snapshot for 0.1.1 evolution-sharp-0.18.0-1.fc10 ----------------------------- * Thu Sep 25 18:00:00 2008 Matthew Barnes - 0.18.0-1.fc10 - Update to 0.18.0 * Wed Sep 10 18:00:00 2008 Matthew Barnes - 0.17.5-1.fc10 - Update to 0.17.5 expect-5.43.0-15.fc10 --------------------- * Thu Sep 25 18:00:00 2008 Vitezslav Crhonek - 5:43.0-15 - Rediff all patches to work with patch --fuzz=0 ext3grep-0.9.0-1.fc10 --------------------- * Mon Sep 29 18:00:00 2008 Milos Jakubicek - 0.9.0-1 - Upstream version 0.9.0 - Marked as ExcludeArch: ppc ppc64, see BZ#464436 extrema-4.3.6-2.fc10 -------------------- * Sun Sep 21 18:00:00 2008 Ville Skytt?? - 4.3.6-2 - Fix Patch0:/%patch mismatch. farsight-0.1.28-2.fc10 ---------------------- * Fri Sep 19 18:00:00 2008 Brian Pepple - 0.1.28-2 - rebuilt for new libjingle. fcron-3.0.4-1.fc10 ------------------ * Thu Sep 18 18:00:00 2008 Patrice Dumas 3.0.4-1 - update to 3.0.4 fedora-ds-admin-1.1.6-2.fc10 ---------------------------- * Mon Sep 15 18:00:00 2008 Rich Megginson - 1.1.6-2 - patch for bug 451702 not required anymore - in upstream now * Wed Jul 2 18:00:00 2008 Rich Megginson - 1.1.6-1 - add patch for bug 451702 - The 1.1.6 release fedora-gnome-theme-8.0.0-7.fc10 ------------------------------- * Wed Sep 24 18:00:00 2008 Matthias Clasen - 8.0.0-7 - Only require bluecurve cursors, not the full icon theme fedora-logos-9.99.4-1.fc10 -------------------------- * Tue Sep 23 18:00:00 2008 Tom "spot" Callaway - 9.99.4-1 - update to 9.99.4 - replace firstboot workstation logo with something modern for F10 fedora-release-notes-8.92-2 --------------------------- * Mon Sep 22 18:00:00 2008 Tom "spot" Callaway - 8.92-2 - Provides: system-release-notes fetchmail-6.3.8-8.fc10 ---------------------- * Thu Sep 18 18:00:00 2008 Vitezslav Crhonek - 6.3.8-8 - Rediff all patches to work with patch --fuzz=0 - Replace server(smtp) requires by procmail Resolves: #66396 file-4.26-1.fc10 ---------------- * Mon Sep 15 18:00:00 2008 Daniel Novotny 4.26-1 - new upstream version: fixes #462064 file-browser-applet-0.5.9-1.fc10 -------------------------------- * Mon Sep 22 18:00:00 2008 Deji Akingunola - 0.5.9-1 - New upstream version file-roller-2.24.0-1.fc10 ------------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 filezilla-3.1.3-1.fc10 ---------------------- * Tue Sep 23 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.1.3-1 - Update to 3.1.3 firefox-3.0.2-1.fc10 -------------------- * Tue Sep 23 18:00:00 2008 Christopher Aillon 3.0.2-1 - Update to 3.0.2 firstboot-1.100-1.fc10 ---------------------- * Fri Sep 12 18:00:00 2008 Chris Lumens 1.100-1 - Force creating a user unless the network button was checked (jmccann, #461656). - Don't sit at the bootup splash screen indefinitely (#458553). fish-1.23.0-6.fc10 ------------------ * Mon Sep 15 18:00:00 2008 Tom "spot" Callaway - 1.23.0-6 - cleanups - define ARG_MAX properly so it compiles * Mon Jul 7 18:00:00 2008 Tom "spot" Callaway - 1.23.0-5 - fix conditional comparison * Sun Jul 6 18:00:00 2008 Oliver Falk - 1.23.0-4 - Rebuild * Wed May 21 18:00:00 2008 Tom "spot" Callaway - 1.23.0-3 - fix license tag flashrom-0-0.12.20080928svn3602.fc10 ------------------------------------ * Sun Sep 28 18:00:00 2008 Peter Lemenkov 0-0.12.20080928svn3602 - Proper support for EN29F002(A)(N)[BT] - Recognize the Intel EP80579 LPC flash interface - Add support for MSI KT4V - Support for Winbond W39V040C and MSI K8T Neo2-F florence-0.3.0-1.fc10 --------------------- * Tue Sep 16 18:00:00 2008 Simon Wesp - 0.3.0-1 - New upstream release fluxbox-1.1.1-1.fc10 -------------------- * Thu Sep 18 18:00:00 2008 Andreas Bierfert - 1.1.1-1 - version upgrade fluxstyle-1.0.1-4.fc10 ---------------------- * Tue Sep 16 18:00:00 2008 Matt Domsch - 1.0.1-4 - fix desktop, add egg-info. Fixes FTBFS BZ#440757 * Fri Jul 18 18:00:00 2008 Tom "spot" Callaway - 1.0.1-3 - fix license tag fonttools-2.2-1.fc10 -------------------- * Tue Sep 16 18:00:00 2008 Matt Domsch - 2.2-1 - update to 2.2, drop upstreamed patch, fix FTBFS BZ#434409 * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 2.0-0.12.20060223cvs - Autorebuild for GCC 4.3 fontypython-0.3.6-1.fc10 ------------------------ * Mon Sep 15 18:00:00 2008 Tom "spot" Callaway 0.3.6-1 - update to 0.3.6 * Thu May 22 18:00:00 2008 Tom "spot" Callaway 0.2.0-7 - fix license tag foobillard-3.0a-8.fc10 ---------------------- * Mon Sep 15 18:00:00 2008 Miloslav Trma?? - 3.0a-8 - Add missing Requires: dejavu-fonts Resolves: #462168 fotoxx-5.3-1.fc10 ----------------- * Thu Sep 18 18:00:00 2008 Nicoleau Fabien - 5.3-1 - Rebuild for 5.3 freefem++-2.24-4.2.fc10 ----------------------- * Sun Sep 28 18:00:00 2008 Dominik Mierzejewski 2.24-4.2 - disabled testsuite on ppc64 - kill lamd processes upon completing make check * Wed Sep 24 18:00:00 2008 Dominik Mierzejewski 2.24-3.2 - updated to 2.24-2 - fixed build in rawhide - re-enable testsuite freeradius-2.1.1-2.fc10 ----------------------- * Fri Sep 26 18:00:00 2008 John Dennis - 2.1.1-1 - Resolves: bug #464119 bootstrap code could not create initial certs in /etc/raddb/certs because permissions were 750, radiusd running as euid radiusd could not write there, permissions now 770 * Thu Sep 25 18:00:00 2008 John Dennis - 2.1.1-1 - upgrade to new upstream 2.1.1 release freetennis-0.4.8-14.fc10 ------------------------ * Mon Sep 22 18:00:00 2008 Richard W.M. Jones - 0.4.8-14 - patch -> patch0 (rhbz #463055). - BR ocaml-lablgtk >= 2.10.1-5 fuse-2.7.4-1.fc10 ----------------- * Sat Aug 23 18:00:00 2008 Peter Lemenkov 2.7.4-1 - Ver. 2.7.4 fuse-sshfs-2.1-1.fc10 --------------------- * Sun Sep 28 18:00:00 2008 Peter Lemenkov 2.1-1 - Ver. 2.1 fusecompress-1.99.19-2.fc10 --------------------------- * Sun Sep 28 18:00:00 2008 Lubomir Rintel - 1.99.19-2 - Fix build - Drop silly mount wrapper * Sat Sep 27 18:00:00 2008 Luke Macken - 1.99.19-1 - Update to 1.99.19 - Remove fusecompress-1.99.17-attr.patch and fusecompress-1.99.17-gcc43.patch, as they are now upstream in this release. gabedit-2.1.8-1.fc10 -------------------- * Thu Sep 25 18:00:00 2008 Dominik Mierzejewski 2.1.8-1 - updated to latest stable version (2.1.8) - fixed build with gtk2-2.14 - use system gl2ps ganyremote-5.3-1.fc10 --------------------- * Wed Sep 24 18:00:00 2008 Mikhail Fedotov - 5.3-1 - Add icons to menu and buttons. gbrainy-1.00-1.fc10 ------------------- * Thu Sep 25 18:00:00 2008 Beno??t Marcelin 1.00-1 - Clean Build Requires - Fix bug 460353 - Upate to 1.00 - 1 new logic puzzle, 1 new memory puzzle - Better look and feel (new background) - Switch font drawing to Pango - Better I18N support - Bug fixes gcalctool-5.24.0-1.fc10 ----------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 5.24.0-1 - Update to 5.24.0 gcc-4.3.2-4 ----------- * Wed Sep 17 18:00:00 2008 Jakub Jelinek 4.3.2-4 - update from 4.3 branch - PRs c++/37389, fortran/35837, fortran/36214, fortran/37099, fortran/37199, rtl-optimization/37408, target/37466, tree-optimization/36630 - revert PR c++/36741 fix - fix VLA debuginfo at -O0 (PR debug/34037) gcin-1.4.2-3.fc10 ----------------- * Mon Sep 29 18:00:00 2008 Jens Petersen - 1.4.2-3 - update im-client.patch to fix patch fuzz gconf-editor-2.24.0.1-1.fc10 ---------------------------- * Tue Sep 23 18:00:00 2008 Matthias Clasen - 2.24.0.1-1 - Update to 2.24.0.1 * Tue Sep 23 18:00:00 2008 Matthias Clasen - 2.24.0-2 - Update to 2.24.0 gconfmm26-2.24.0-1.fc10 ----------------------- * Wed Sep 24 18:00:00 2008 Denis Leroy - 2.24.0-1 - Update to upstream 2.24.0 gdm-2.24.0-5.fc10 ----------------- * Thu Sep 25 18:00:00 2008 Matthias Clasen - 1:2.24.0-5 - Require gnome-session * Tue Sep 23 18:00:00 2008 Ray Strode - 1:2.24.0-3 - Load background after everything else, so the crossfade isn't choppy. * Tue Sep 23 18:00:00 2008 Matthias Clasen - 1:2.24.0-4 - Let /var/lib/gdm be owned by gdm, to make pulseaudio happy * Mon Sep 22 18:00:00 2008 Ray Strode - 1:2.24.0-2 - Fix permssions on spool dir * Mon Sep 22 18:00:00 2008 Ray Strode - 1:2.23.92-10 - Flush X event queue after setting _XROOTPMAP_ID so there's no race with settings daemon reading the property * Mon Sep 22 18:00:00 2008 Matthias Clasen - 1:2.24.0-1 - Update to 2.24.0 * Fri Sep 19 18:00:00 2008 Ray Strode - 1:2.23.92-9 - Fix crash from language dialog * Wed Sep 17 18:00:00 2008 Ray Strode - 1:2.23.92-8 - canonicalize codeset to match output of locale -m - filter duplicates from language list * Tue Sep 16 18:00:00 2008 Ray Strode - 1:2.23.92-6 - Use _XROOTPMAP_ID instead of _XSETROOT_ID * Tue Sep 16 18:00:00 2008 Ray Strode - 1:2.23.92-5 - Save root window in XSETROOTID property for transition gedit-2.24.0-3.fc10 ------------------- * Thu Sep 25 18:00:00 2008 Matthias Clasen - 1:2.24.0-3 - Save some space * Mon Sep 22 18:00:00 2008 Matthias Clasen - 1:2.24.0-2 - Update to 2.24.0 ghc-6.8.3-5.fc10 ---------------- * Wed Sep 24 18:00:00 2008 Jens Petersen - 6.8.3-5.fc10 - bring back including haddock-generated lib docs, now under docdir/ghc - fix macros.ghc filepath (#460304) - spec file cleanups: - fix the source urls back - drop requires chkconfig - do not override __spec_install_post - setup docs building in build.mk - no longer need to remove network/include/Typeable.h - install binaries under libdir not libexec - remove hsc2hs and runhaskell binaries since are alternatives * Wed Sep 17 18:00:00 2008 Jens Petersen - 6.8.3-4.fc10 - add macros.ghc for new Haskell Packaging Guidelines (#460304) gimp-2.4.7-4.fc10 ----------------- * Mon Sep 22 18:00:00 2008 Nils Philippsen - 2:2.4.7-4 - don't require desktop-file-utils (#463049, patch by Ville Skytt??) * Wed Sep 17 18:00:00 2008 Nils Philippsen - 2:2.4.7-3 - don't make pyconsole.py plug-in executable as upstream indicates it shouldn't be * Wed Sep 17 18:00:00 2008 Nils Philippsen - 2:2.4.7-2 - Merge review: - convert spec file to UTF-8 - remove unneeded gimp2, gimp-beta obsoletes - quote macros in changelog - use only spaces, not tabs - make pyconsole.py plug-in executable (upstream bug #552601) glade3-3.4.5-1.fc10 ------------------- * Tue Sep 16 18:00:00 2008 Debarshi Ray - 3.4.5-1 - Version bump to 3.4.5. glib2-2.18.1-1.fc10 ------------------- * Wed Sep 17 18:00:00 2008 Matthias Clasen - 2.18.1-1 - Update to 2.18.1 glibmm24-2.18.0-1.fc10 ---------------------- * Tue Sep 23 18:00:00 2008 Denis Leroy - 2.18.0-1 - Update to upstream 2.18.0 glpi-0.71.2-1.fc10 ------------------ * Mon Sep 15 18:00:00 2008 Remi Collet - 0.71.2-1 - update to 0.71.1 bugfix glpk-4.31-1.fc10 ---------------- * Thu Sep 25 18:00:00 2008 Conrad Meyer 4.31-1 - Update to 4.31. gnome-applet-netspeed-0.15-2.fc10 --------------------------------- * Sun Sep 28 18:00:00 2008 Julian Sikorski - 0.15-2 - Removed libgnomeui-devel from BuildRequires, added wireless-tools-devel - Updated URL * Sun Sep 28 18:00:00 2008 Julian Sikorski - 0.15-1 - Updated to 0.15 - Added hicolor-icon-theme to Requires gnome-applets-2.24.0.1-3.fc10 ----------------------------- * Fri Sep 26 18:00:00 2008 Matthias Clasen - 1:2.24.0.1-3 - Small improvement to the drivemount applet * Wed Sep 24 18:00:00 2008 Matthias Clasen - 1:2.24.0.1-2 - Update to 2.24.0.1 * Sun Sep 21 18:00:00 2008 Matthias Clasen - 1:2.24.0-2 - Update to 2.24.0 * Tue Sep 16 18:00:00 2008 Matthias Clasen - 1:2.23.92-2 - Plug a leak in the trash applet gnome-backgrounds-2.24.0-1.fc10 ------------------------------- * Tue Sep 23 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 gnome-desktop-2.24.0-3.fc10 --------------------------- * Wed Sep 24 18:00:00 2008 Soren Sandmann - 2.24.0-2 - Make clone-modes.patch work again * Wed Sep 24 18:00:00 2008 Ray Strode - 2.24.0-3 - make bg crossfade animation .75 seconds instead of .5 * Mon Sep 22 18:00:00 2008 Ray Strode - 2.23.92-5 - s/animatins/animations/ yes there's deja vu here * Mon Sep 22 18:00:00 2008 Ray Strode - 2.23.92-4 - Add some flush calls to make transition smoother * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 * Thu Sep 18 18:00:00 2008 Ray Strode - 2.23.92-3 - s/animatins/animations/ * Thu Sep 18 18:00:00 2008 Ray Strode - 2.23.92-2 - Add new api for doing desktop background change transition gnome-devel-docs-2.24.0-1.fc10 ------------------------------ * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 gnome-doc-utils-0.14.0-1.fc10 ----------------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 0.14.0-1 - Update to 0.14.0 gnome-games-2.24.0-2.fc10 ------------------------- * Thu Sep 25 18:00:00 2008 Matthias Clasen - 1:2.24.0-2 - Save some space * Sun Sep 21 18:00:00 2008 Matthias Clasen - 1:2.24.0-1 - Update to 2.24.0 gnome-icon-theme-2.24.0-1.fc10 ------------------------------ * Tue Sep 23 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 gnome-keyring-2.24.0-2.fc10 --------------------------- * Sun Sep 21 18:00:00 2008 Matthias Clasen - 2.24.0-2 - Update to 2.24.0 gnome-mag-0.15.4-1.fc10 ----------------------- * Tue Sep 23 18:00:00 2008 Matthias Clasen - 0.15.4-1 - Update to 0.15.4 gnome-media-2.24.0.1-1.fc10 --------------------------- * Wed Sep 24 18:00:00 2008 Matthias Clasen 2.24.0.1-1 - Update to 2.24.0 * Tue Sep 23 18:00:00 2008 Matthias Clasen 2.24.0-1 - Update to 2.24.0 gnome-menus-2.24.0-1.fc10 ------------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 gnome-netstatus-2.12.2-2.fc10 ----------------------------- * Tue Sep 23 18:00:00 2008 Matthias Clasen - 2.12.2-2 - Update to 2.12.2 * Thu May 29 18:00:00 2008 Tom "spot" Callaway - 2.12.1-5 - fix license tag gnome-nettool-2.22.1-2.fc10 --------------------------- * Tue Sep 23 18:00:00 2008 Matthias Clasen - 2.22.1-2 - Update to 2.22.1 * Thu May 29 18:00:00 2008 Tom "spot" Callaway - 2.22.0-2 - fix license tag gnome-packagekit-0.3.4-1.fc10 ----------------------------- * Mon Sep 22 18:00:00 2008 Richard Hughes - 0.3.4-1 - New upstream version * Wed Sep 17 18:00:00 2008 Richard Hughes - 0.3.3-2 - Fix the interaction when the update check and the upgrade check are scheduled at the same time. * Tue Sep 16 18:00:00 2008 Richard Hughes - 0.3.3-1 - Update to newest upstream version. - Supports collection install and remove in the UI - Add InstallGStreamerCodecs to the session interface gnome-panel-2.24.0-4.fc10 ------------------------- * Fri Sep 26 18:00:00 2008 Ray Strode - 2.24.0-4 - Try to make initial panel slide-in animation be smooth * Thu Sep 25 18:00:00 2008 Ray Strode - 2.24.0-2 - Requires: gnome-session-xsession so it gets pulled in for typical GNOME installs. * Thu Sep 25 18:00:00 2008 Matthias Clasen - 2.24.0-3 - Save some space * Tue Sep 23 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 gnome-power-manager-2.24.0-4.fc10 --------------------------------- * Thu Sep 25 18:00:00 2008 Matthias Clasen - 2.24.0-4 - Save some space * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-2 - Update to 2.24.0 gnome-python2-2.22.3-1.fc10 --------------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.22.3-1 - Update to 2.22.3 * Sun Sep 21 18:00:00 2008 Matthew Barnes - 2.22.2-1.fc10 - Update to 2.22.2 gnome-python2-extras-2.19.1-18.fc9 ---------------------------------- * Wed Sep 24 18:00:00 2008 Christopher Aillon - 2.19.1-18 - Rebuild against newer gecko gnome-screensaver-2.24.0-1.fc10 ------------------------------- * Wed Sep 24 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 gnome-session-2.24.0-5.fc10 --------------------------- * Sun Sep 28 18:00:00 2008 Matthias Clasen - 2.24.0-5 - BR xorg-x11-xtrans-devel (#464316) * Fri Sep 26 18:00:00 2008 Ray Strode - 2.24.0-4 - Make the new xsession subpackage require the version of gnome-session it's built against * Thu Sep 25 18:00:00 2008 Ray Strode - 2.24.0-3 - Split gnome-session.desktop off into subpackage * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-2 - Update to 2.24.0 - Drop upstreamed patches * Thu Sep 18 18:00:00 2008 Matthias Clasen - 2.23.92-6 - Plug memory leaks * Thu Sep 18 18:00:00 2008 Matthias Clasen - 2.23.92-5 - Plug memory leaks * Mon Sep 15 18:00:00 2008 Matthias Clasen - 2.23.92-4 - Plug memory leaks * Sun Sep 14 18:00:00 2008 Matthias Clasen - 2.23.92-3 - Plug memory leaks * Sun Sep 14 18:00:00 2008 Matthias Clasen - 2.23.92-2 - Plug memory leaks gnome-settings-daemon-2.24.0-2.fc10 ----------------------------------- * Sun Sep 28 18:00:00 2008 Ray Strode - 2.24.0-2 - Don't draw background twice at startup * Tue Sep 23 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 * Thu Sep 18 18:00:00 2008 Ray Strode - 2.23.92-3 - When switching desktop backgrounds fade between them gnome-system-monitor-2.24.0-1.fc10 ---------------------------------- * Tue Sep 23 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 gnome-terminal-2.24.0-2.fc10 ---------------------------- * Thu Sep 25 18:00:00 2008 Matthias Clasen - 2.24.0-2 - Save some space * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 gnome-themes-2.24.0-1.fc10 -------------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 gnome-user-share-0.40-3.fc10 ---------------------------- * Mon Sep 22 18:00:00 2008 - Bastien Nocera - 0.40-3 - Add missing libnotify BR * Mon Sep 22 18:00:00 2008 - Bastien Nocera - 0.40-2 - Add missing intltool BR * Mon Sep 22 18:00:00 2008 - Bastien Nocera - 0.40-1 - Update to 0.40 * Mon Sep 22 18:00:00 2008 - Bastien Nocera - 0.31-3 - Add patch to port to BlueZ 4.x API * Sun May 4 18:00:00 2008 Matthias Clasen - 0.31-2 - Fix source url gnome-utils-2.24.0-2.fc10 ------------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 1:2.24.0-1 - Update to 2.24.0 gnome-valgrind-session-1.1-3.fc10 --------------------------------- * Tue Sep 16 18:00:00 2008 Debarshi Ray - 1.1-3 - Explicitly mention the PID as the suffix of the log files for all distributions, except Fedora 8. gnome-vfs2-2.24.0-3.fc10 ------------------------ * Thu Sep 25 18:00:00 2008 Matthias Clasen - 2.24.0-3 - Save some space * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-2 - Update to 2.24.0 - Drop upstreamed patches gnome-vfsmm26-2.24.0-1.fc10 --------------------------- * Wed Sep 24 18:00:00 2008 Denis Leroy - 2.24.0-1 - Update to upstream 2.24.0 gnome-volume-manager-2.24.0-1.fc10 ---------------------------------- * Wed Sep 24 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 gnome-web-photo-0.3-14.fc9 -------------------------- * Wed Sep 24 18:00:00 2008 Christopher Aillon - 0.3-14 - Rebuild against newer gecko gnomesword-2.4.0-1.fc10 ----------------------- * Sun Sep 21 18:00:00 2008 Deji Akingunola - 2.4.0-1 - Update to 2.4.0 gnutls-2.4.2-2.fc10 ------------------- * Thu Sep 25 18:00:00 2008 Tomas Mraz 2.4.2-2 - add guile subpackage (#463735) - force new libtool through autoreconf to drop unnecessary rpaths * Tue Sep 23 18:00:00 2008 Tomas Mraz 2.4.2-1 - new upstream version gok-2.24.0-2.fc10 ----------------- * Thu Sep 25 18:00:00 2008 Matthias Clasen - 2.24.0-2 - Save some space * Tue Sep 23 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 google-perftools-0.99.1-1.fc10 ------------------------------ * Mon Sep 22 18:00:00 2008 Tom "spot" Callaway - 0.99.1-1 - update to 0.99.1 - previous patches in 0.98-1 were taken upstream gparted-0.3.9-1.fc10.1 ---------------------- * Mon Sep 22 18:00:00 2008 Deji Akingunola - 0.3.9-1 - New upstream version - Finally removed the 'preun' call that ensures the old gparted fdi (pre-FC6) file is removed on update gputils-0.13.6-1.fc10 --------------------- * Mon Sep 15 18:00:00 2008 Roy Rankin 0.13.6-1 - New upstream version gridengine-6.2-2.fc10 --------------------- * Fri Sep 26 18:00:00 2008 - Orion Poplawski - 6.2-2 - No more sge_schedd in 6.2, remove from startup script gsl-1.11-4.fc10 --------------- * Tue Sep 16 18:00:00 2008 Ivana Varekova - 1.11-4 - Resolves: #462369 - remove %{_datadir}/aclocal - add automake dependency gspiceui-0.9.65-3.fc10 ---------------------- * Thu Jul 31 18:00:00 2008 Xavier Lamien - 0.9.65-3 - Excluded ppc64 (gwave is not available on ppc64). gstm-1.2-9.fc10 --------------- * Tue Sep 16 18:00:00 2008 Matt Domsch - 1.2-9 - add BR libxml2-devel & pkgconfig, redo auto* to pick them up. Fixes FTBFS BZ#434531 - Steven Bakker: remove extraneous desktop file category * Fri Jul 25 18:00:00 2008 Tom "spot" Callaway - 1.2-8 - fix license tag * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 1.2-7 - Autorebuild for GCC 4.3 gstreamer-0.10.20-6.fc10 ------------------------ * Sun Sep 14 18:00:00 2008 - Bastien Nocera - 0.10.20-6 - Hopefully fix RPM provides problem when the GStreamer plugin requires a library installed by the package itself gstreamer-plugins-base-0.10.20-6.fc10 ------------------------------------- * Wed Sep 24 18:00:00 2008 Jeremy Katz - 0.10.20-6 - gst-visualize is just a test program that we don't really need to include and having it means that perl gets pulled into small images (#462620) gstreamer-plugins-farsight-0.12.9-3.fc10 ---------------------------------------- * Fri Sep 19 18:00:00 2008 Brian Pepple - 0.12.9-3 - rebuilt for new libjingle. * Fri Sep 12 18:00:00 2008 Brian Pepple - 0.12.9-2 - Rebuild for new gst. gthumb-2.10.10-1.fc10 --------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.10.10-1 - Update to 2.10.10 gtk-gnutella-0.96.5-3.fc10 -------------------------- * Fri Sep 26 18:00:00 2008 Dmitry Butskoy - 0.96.5-3 - pass compiler correctly for Configure script gtk-sharp2-2.12.3-1.fc10 ------------------------ * Thu Sep 18 18:00:00 2008 Nigel Jones - 2.12.3-1 - New minor release (.3) gtk-vnc-0.3.7-2.fc10 -------------------- * Thu Sep 25 18:00:00 2008 Daniel P. Berrange - 0.3.7-2.fc10 - Allow pointer ungrab keysequence if already grabbed (rhbz #463729) gtk2-2.14.3-2.fc10 ------------------ * Thu Sep 25 18:00:00 2008 Matthias Clasen - 2.14.3-2 - Move message catalogs for properties to the -devel package * Wed Sep 24 18:00:00 2008 Matthias Clasen - 2.14.3-1 - Update to 2.14.3 * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.14.2-5 - Rebuild - Fix a filechooser crash * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.14.2-3 - BR libXdamage-devel (#462971, Owen Taylor) - Plug some memory leaks * Thu Sep 18 18:00:00 2008 Matthias Clasen - 2.14.2-1 - Update to 2.14.2 gtk2-engines-2.16.0-1.fc10 -------------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.16.0-1 - Update to 2.16.0 gtkhtml3-3.24.0-1.fc10 ---------------------- * Mon Sep 22 18:00:00 2008 Matthew Barnes - 3.24.0-1.fc10 - Update to 3.24.0 gtkmm24-2.14.0-1.fc10 --------------------- * Tue Sep 23 18:00:00 2008 Denis Leroy - 2.14.0-1 - Update to stable 2.14.0 gtksourceview2-2.4.0-1.fc10 --------------------------- * Sun Sep 21 18:00:00 2008 Matthias Clasen - 2.4.0-1 - Update to 2.4.0 gucharmap-2.24.0-1.fc10 ----------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 gvfs-1.0.1-1.fc10 ----------------- * Wed Sep 24 18:00:00 2008 Matthias Clasen - 1.0.1-1 - Update to 1.0.1 * Mon Sep 22 18:00:00 2008 Matthias Clasen - 1.0.0-2 - Update to 1.0.0 * Fri Sep 19 18:00:00 2008 - Bastien Nocera - 0.99.8-6 - Update patch for missing file * Fri Sep 19 18:00:00 2008 - Bastien Nocera - 0.99.8-5 - Updated patch, fixed deadlock whilst mounting gwibber-0.7-4.102bzr.fc10 ------------------------- * Thu Sep 11 18:00:00 2008 Ian Weller 0.7-4.102bzr - Update upstream - Fix requires: s/pywebkitgui/pywebkitgtk/ - Fix requires: python-simplejson >= 1.9.1 * Sat Aug 30 18:00:00 2008 Ian Weller 0.7-3.101bzr - Update upstream to webkitui branch gxemul-0.4.6.5-1.fc10 --------------------- * Fri Sep 12 18:00:00 2008 Tom "spot" Callaway - 0.4.6.5-1 - update to 0.4.6.5 hamster-applet-2.24.0-1.fc10 ---------------------------- * Tue Sep 23 18:00:00 2008 Mads Villadsen - 2.24.0-1 - Update to latest upstream release hdf5-1.8.1-2.fc10 ----------------- * Fri Sep 26 18:00:00 2008 Orion Poplawski 1.8.1-2 - Add patch to filter -little as option used on sh arch (#464052) hplip-2.8.7-2.fc10 ------------------ * Fri Sep 26 18:00:00 2008 Tim Waugh 2.8.7-2 - Moved Python extension into libs sub-package (bug #461236). ht2html-2.0-7.fc10 ------------------ * Tue Sep 16 18:00:00 2008 Matt Domsch - 2.0-7 - BR python, fixes FTBFS BZ#440916 * Thu Jul 31 18:00:00 2008 Tom "spot" Callaway 2.0-6 - fix license tag hunspell-1.2.7-3.fc10 --------------------- * Mon Sep 15 18:00:00 2008 Caolan McNamara - 1.2.7-3 - Workaround rhbz#462184 uniq/sort problems with viramas hunspell-ca-0.20080915-1.fc10 ----------------------------- * Mon Sep 15 18:00:00 2008 Caolan McNamara - 0.20080915-1 - latest version * Tue Jul 8 18:00:00 2008 Caolan McNamara - 0.20080706-2 - Catalan is spoken in Andora, France and Italy as well ibus-0.1.1.20080917-1.fc10 -------------------------- * Wed Sep 17 18:00:00 2008 Huang Peng - 0.1.1.20080917-1 - Update to 0.1.1.20080917. * Tue Sep 16 18:00:00 2008 Huang Peng - 0.1.1.20080916-1 - Update to 0.1.1.20080916. * Mon Sep 15 18:00:00 2008 Huang Peng - 0.1.1.20080914-1 - Update to 0.1.1.20080914. ibus-anthy-0.1.1.20080912-1.fc10 -------------------------------- * Fri Sep 12 18:00:00 2008 Huang Peng - 0.1.1.20080912-1 - Update to 0.1.1.20080912. ibus-chewing-0.1.1.20080917-1.fc10 ---------------------------------- * Wed Sep 17 18:00:00 2008 Huang Peng - 0.1.1.20080917-1 - Update to 0.1.1.20080917. * Tue Sep 16 18:00:00 2008 Huang Peng - 0.1.1.20080916-1 - Update to 0.1.1.20080916. ibus-pinyin-0.1.1.20080918-1.fc10 --------------------------------- * Thu Sep 18 18:00:00 2008 Huang Peng - 0.1.1.20080918-1 - Update version to 0.1.1.20080918. igraph-0.5-14.fc10 ------------------ * Thu Sep 18 18:00:00 2008 Neal Becker - 0.5-14 - Add BR libxml2-devel to get graphml support. ikiwiki-2.64-1.fc10 ------------------- * Fri Sep 19 18:00:00 2008 Thomas Moschny - 2.64-1 - Update to 2.64. imlib-1.9.15-9.fc10 ------------------- * Tue Sep 23 18:00:00 2008 Paul Howarth 1:1.9.15-9 - specify Instruction Set Architecture (%{?_isa}) in devel package requires (where available) imsettings-0.104.1-1.fc10 ------------------------- * Thu Sep 25 18:00:00 2008 Akira TAGOH - 0.104.1-1 - New upstream release. - Fix a segfault issue. (#462899) - Suppress the unnecessary notification. (#463797) - Add .schemas file missing. real fix of #460703. intltool-0.40.4-1.fc10 ---------------------- * Sun Sep 21 18:00:00 2008 Matthias Clasen - 0.40.4-1 - Update to 0.40.4 ipcalculator-0.41-7.fc10 ------------------------ * Sun Sep 21 18:00:00 2008 Ville Skytt?? - 0.41-7 - Fix Patch0:/%patch mismatch. iputils-20071127-6.fc10 ----------------------- * Fri Sep 26 18:00:00 2008 Jiri Skala - 20071127-6 - #455713 not accepted - suid is back iscsi-initiator-utils-6.2.0.870-0.0.fc9 --------------------------------------- * Mon Jun 30 18:00:00 2008 Mike Christie - 6.2.0.870 - Rebase to open-iscsi-2-870 - 453282 Handle sysfs changes. iso-codes-3.3-1.fc10 -------------------- * Sat Sep 20 18:00:00 2008 Ville Skytt?? - 3.3-1 - Update to 3.3. - Address minor issues in merge review (#225918): update %description, don't use %makeinstall, drop unneeded %debug_package override, use parallel build. itpp-4.0.0-5.fc10 ----------------- * Sun Sep 14 18:00:00 2008 Manuel "lonely wolf" Wolfshant - 4.0.0-5 - Fix building with gcc4.3 * Fri May 23 18:00:00 2008 Jon Stanley - 4.0.0-4 - Fix license tag * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 4.0.0-3 - Autorebuild for GCC 4.3 iverilog-0.9.20080905-1.fc10 ---------------------------- * Fri Sep 12 18:00:00 2008 Balint Cristian 0.9.20080905-1 - new snapshot release upstream. iw-0.9.5-3.fc10 --------------- * Sun Sep 28 18:00:00 2008 Adel Gadllah 0.9.5-3 - Use offical tarball * Sun Sep 28 18:00:00 2008 Adel Gadllah 0.9.5-2 - Fix BuildRequires * Sun Sep 28 18:00:00 2008 Adel Gadllah 0.9.5-1 - Update to 0.9.5 jabbim-0.4.3-3.fc10 ------------------- * Mon Sep 15 18:00:00 2008 Michal Schmidt - 0.4.3-3 - Fix mistaken parentheses in the previous patch. * Mon Sep 15 18:00:00 2008 Michal Schmidt - 0.4.3-2 - Doubleclicking on bookmarks did not open the chat window. Caused by a change in PyQt in constructing QVariants from lists of strings. jabbin-2.0-0.6.beta2a.fc10 -------------------------- java-1.6.0-openjdk-1.6.0.0-0.21.b12.fc10 ---------------------------------------- * Wed Sep 24 18:00:00 2008 Lillian Angel - 1:1.6.0-0.21.b12 - Updated icedteasnapshot. - Updated release. - Updated openjdkver. - Updated openjdkdate. * Wed Sep 24 18:00:00 2008 Lillian Angel - 1:1.6.0-0.19.b09 - Removed all instances of security jars. * Mon Sep 22 18:00:00 2008 Lillian Angel - 1:1.6.0-0.20.b11 - Removed update-desktop-database dependency. - Resolves: rhbz#463046 * Mon Sep 8 18:00:00 2008 Lillian Angel - 1:1.6.0-0.20.b11 - Added rhino requirement. - Resolves: rhbz#461336 jd-2.0.3-0.1.svn2361_trunk.fc10 ------------------------------- * Tue Sep 23 18:00:00 2008 Mamoru Tasaka - rev 2361 * Sat Sep 20 18:00:00 2008 Mamoru Tasaka - 2.0.2-1 - 2.0.2 * Tue Sep 16 18:00:00 2008 Mamoru Tasaka - 2.0.1-2 - Patch to cope with occasional cookie change * Sun Sep 14 18:00:00 2008 Mamoru Tasaka - 2.0.1-1 - 2.0.1 jhead-2.82-2.fc10 ----------------- * Wed Sep 24 18:00:00 2008 Adrian Reber - 2.82-2 - rebased makefile patch jpackage-utils-1.7.5-1.6.fc10 ----------------------------- * Wed Sep 24 18:00:00 2008 Deepak Bhole 1.7.5-1.6 - Update enable-gcj-support.patch to remove fuzz. kanyremote-5.3-1.fc10 --------------------- * Wed Sep 24 18:00:00 2008 Mikhail Fedotov - 5.3-1 - Add icons to menu and buttons. kbackup-0.5.4-1.fc10 -------------------- * Sun Sep 14 18:00:00 2008 Paul F. Johnson 0.5.4-1 - bump to new version - desktop patch fix kde-filesystem-4-19.fc10 ------------------------ * Sat Sep 13 18:00:00 2008 Than Ngo 4-19 - it's not needed to bump _kde4_macros_api - use macro * Sat Sep 13 18:00:00 2008 Than Ngo 4-18 - remove redundant FEDORA, use CMAKE_BUILD_TYPE=release kde-l10n-4.1.2-1.fc10 --------------------- * Fri Sep 26 18:00:00 2008 Rex Dieter 4.1.2-1 - 4.1.2 - reenable Kurdish, Lithuanian, Malayalam * Wed Sep 10 18:00:00 2008 Kevin Kofler 4.1.1-2 - reenable Frisian and Kazakh kde-settings-4.0-29.fc10 ------------------------ * Sat Sep 27 18:00:00 2008 Kevin Kofler 4.0-29 - remove /etc/kde/env/pulseaudio.sh, no longer needed in F10 (#448477) * Sat Sep 27 18:00:00 2008 Kevin Kofler 4.0-28 - kxkbrc: set default keyboard model to evdev (matches F10+ X11 setup, #464101) * Tue Sep 16 18:00:00 2008 Than Ngo 4.0-27 - remove unneeded symlinks in Fedora-KDE icon theme * Tue Sep 16 18:00:00 2008 Than Ngo 4.0-26 - fix, systemsettings->icons doesn't show icons by Fedora-KDE icon theme kdeaccessibility-4.1.2-1.fc10 ----------------------------- * Fri Sep 26 18:00:00 2008 Rex Dieter 4.1.2-1 - 4.1.2 kdeaddons-3.5.10-2.fc10 ----------------------- * Wed Sep 17 18:00:00 2008 Kevin Kofler 3.5.10-2 - build without libkdegames.so symlink kdeadmin-4.1.2-2.fc10 --------------------- * Sun Sep 28 18:00:00 2008 Rex Dieter 4.1.2-2 - (re)add unpackaged HTML/en/kcontrol/ files * Fri Sep 26 18:00:00 2008 Rex Dieter 4.1.2-1 - 4.1.2 kdeartwork-4.1.2-1.fc10 ----------------------- * Fri Sep 26 18:00:00 2008 Rex Dieter 4.1.2-1 - 4.1.2 kdebase-4.1.2-1.fc10 -------------------- * Fri Sep 26 18:00:00 2008 Rex Dieter 4.1.2-1 - 4.1.2 * Thu Sep 18 18:00:00 2008 Than Ngo 4.1.1-2 - make bookmark silent kdebase-runtime-4.1.2-1.fc10 ---------------------------- * Fri Sep 26 18:00:00 2008 Rex Dieter 4.1.1-3 - fix inherit issue in iconthemes, preview icons do not show kdebase-workspace-4.1.2-2.fc10 ------------------------------ * Sun Sep 28 18:00:00 2008 Rex Dieter 4.1.2-2 - make VERBOSE=1 - respin against new(er) kde-filesystem * Fri Sep 26 18:00:00 2008 Rex Dieter 4.1.2-1 - 4.1.2 kdebase3-3.5.10-2.fc10 ---------------------- * Sun Sep 21 18:00:00 2008 Kevin Kofler - 3.5.10-2 - fix libkrdb_dep patch not to call runRdb which is not being linked in - don't apply libkrdb_dep patch on F8- kdebindings-4.1.2-1.fc10 ------------------------ * Fri Sep 26 18:00:00 2008 Rex Dieter 4.1.2-1 - 4.1.2 * Thu Sep 25 18:00:00 2008 Rex Dieter 4.1.1-2 - respin (for qscintilla) kdebluetooth-0.2-3.fc10 ----------------------- * Mon Sep 15 18:00:00 2008 Gilboa Davara - 0.2-3 - Use versioned obsoletes. * Sun Sep 14 18:00:00 2008 Gilboa Davara - 0.2-2 - Use epoch instead of obsolete. - Revert to old kdebluetooth description. (Taken from kdebluetooth website) kdeedu-4.1.2-1.fc10 ------------------- * Fri Sep 26 18:00:00 2008 Rex Dieter 4.1.2-1 - 4.1.2 kdegames-4.1.2-1.fc10 --------------------- * Fri Sep 26 18:00:00 2008 Rex Dieter 4.1.2-1 - 4.1.2 * Thu Sep 18 18:00:00 2008 Kevin Kofler 4.1.1-2 - drop no longer needed devel symlink hacks kdegames3-3.5.10-2.fc10 ----------------------- * Wed Sep 17 18:00:00 2008 Kevin Kofler - 3.5.10-2 - remove no longer used libkdegames development files kdegraphics-4.1.2-1.fc10 ------------------------ * Fri Sep 26 18:00:00 2008 Rex Dieter 4.1.2-1 - 4.1.2 kdelibs-4.1.2-2.fc10 -------------------- * Sun Sep 28 18:00:00 2008 Rex Dieter 4.1.2-2 - make VERBOSE=1 - respin against new(er) kde-filesystem * Thu Sep 25 18:00:00 2008 Rex Dieter 4.1.2-1 - kde-4.1.2 * Fri Sep 19 18:00:00 2008 Kevin Kofler 4.1.1-12 - make "Stop Animations" work again in Konqueror (KDE 4 regression kde#157789) * Thu Sep 18 18:00:00 2008 Than Ngo 4.1.1-11 - apply upstream patch to fix the regression - drop the kdelibs-4.1.1-bz#461725-regression.patch * Thu Sep 18 18:00:00 2008 Luk???? Tinkl 4.1.1-10 - Fix file association bug, the global mimeapps.list file had priority over the local one. - khtml scroll crash fix (kdebug:170880) - Don't eat text when the emoticons were not installed. This fixes mail text not being displayed in KMail when kdebase-runtime wasn't installed. * Wed Sep 17 18:00:00 2008 Than Ngo 4.1.1-9 - #461725, revert the patch to fix the regression * Sat Sep 13 18:00:00 2008 Than Ngo 4.1.1-8 - fix kdelibs-4.1.1-kdeui-widgets-fixes.patch * Sat Sep 13 18:00:00 2008 Than Ngo 4.1.1-7 - remove redundant FEDORA, use CMAKE_BUILD_TYPE=release - fix install problem with cmake > 2.5 * Mon Sep 8 18:00:00 2008 Luk???? Tinkl 4.1.1-6 - fix crashes in plugin selector - fix problems in various kdeui widgets kdenetwork-4.1.2-1.fc10 ----------------------- * Fri Sep 26 18:00:00 2008 Rex Dieter 4.1.2-1 - 4.1.2 kdepim-4.1.2-1.fc10 ------------------- * Fri Sep 26 18:00:00 2008 Rex Dieter 4.1.2-1 - 4.1.2 kdepimlibs-4.1.2-2.fc10 ----------------------- * Sun Sep 28 18:00:00 2008 Rex Dieter 4.1.2-2 - make VERBOSE=1 - respin against new(er) kde-filesystem * Fri Sep 26 18:00:00 2008 Rex Dieter 4.1.2-1 - 4.1.2 kdesdk-4.1.2-1.fc10 ------------------- * Fri Sep 26 18:00:00 2008 Rex Dieter 4.1.2-1 - 4.1.2 * Wed Sep 24 18:00:00 2008 Than Ngo 4.1.1-2 - show quit in the menu kdetoys-4.1.2-1.fc10 -------------------- * Fri Sep 26 18:00:00 2008 Rex Dieter 4.1.2-1 - 4.1.2 kdeutils-4.1.2-2.fc10 --------------------- * Sun Sep 28 18:00:00 2008 Rex Dieter 4.1.2-2 - (re)add unpackaged HTML/en/kcontrol/ files * Fri Sep 26 18:00:00 2008 Rex Dieter 4.1.2-1 - 4.1.2 kernel-2.6.27-0.354.rc7.git3.fc10 --------------------------------- * Wed Sep 24 18:00:00 2008 Dave Jones - 2.6.27-rc7-git3 * Wed Sep 24 18:00:00 2008 Dave Jones - 2.6.27-rc7-git2 kerneloops-0.12-1.fc10 ---------------------- kexec-tools-2.0.0-2.fc10 ------------------------ * Mon Sep 15 18:00:00 2008 Neil Horman - 2.0.0-2 - Fix sysconfig files to not specify --args-linux on x86 (bz 461615) kile-2.0.2-1.fc10 ----------------- * Sun Sep 28 18:00:00 2008 Kevin Kofler 2.0.2-1 - update to 2.0.2 (#464320) kita-0.177.5-1.fc10 ------------------- * Tue Sep 23 18:00:00 2008 Mamoru Tasaka - 0.177.5-1 - 0.177.5 - cookie-change.patch accepted by upstream * Wed Sep 17 18:00:00 2008 Mamoru Tasaka - 0.177.4-1 - 0.177.4 * Tue Sep 16 18:00:00 2008 Mamoru Tasaka - 0.177.3-14 - Workaround to 2ch cookie style change kmenu-gnome-0.7.4-1.fc10 ------------------------ * Mon Sep 15 18:00:00 2008 Ariszlo - 0.7.4-1 - release 0.7.4 * Thu Aug 28 18:00:00 2008 Ariszlo - 0.7.3-3 - Replaced '== 8' with '< 9' kmymoney2-0.9.2-3.fc10 ---------------------- * Mon Sep 15 18:00:00 2008 Rex Dieter 0.9.2-3 - respun tarball * Sun Sep 14 18:00:00 2008 Rex Dieter 0.9.2-1 - kmymoney2-0.9.2 knetworkmanager-0.7-0.6.20080926svn.fc10 ---------------------------------------- * Wed Sep 24 18:00:00 2008 Dennis Gilmore - 0.7-0.6.20080926svn - update to 20080926 snapshot koan-1.2.5-1.fc10 ----------------- * Fri Sep 26 18:00:00 2008 Michael DeHaan - 1.2.5-1 - Upstream changes (see CHANGELOG) kst-1.7.0-2.fc10 ---------------- * Fri Sep 19 18:00:00 2008 Matthew Truch - 1.7.0-2 - Allow build from netcdf version 4. * Fri Sep 19 18:00:00 2008 Matthew Truch - 1.7.0-1 - Update to upstream 1.7.0. - Re-enable ppc64 build of netcdf subpackage. * Sat May 10 18:00:00 2008 Matthew Truch - 1.6.0-4 - ExcludeArch ppc64 for netcdf subpackage as netcdf is disabled on ppc64. * Sat May 10 18:00:00 2008 Matthew Truch - 1.6.0-3 - Pick up patch from upstream fixing -F command line option Upstream KDE svn revision 805176 Fixes upstream reported KDE BUG:161766 kvm-74-4.fc10 ------------- * Mon Sep 15 18:00:00 2008 Glauber Costa - 74-4 - fix page_find out of bounds access - #462380 latexmk-4.00e-1.fc10 -------------------- * Wed Sep 24 18:00:00 2008 Jerry James - 4.00e-1 - New version 4.00e. - Drop the perl patch; the script finds it just fine lib3ds-1.3.0-5.fc10 ------------------- * Wed Sep 24 18:00:00 2008 Ralf Cors??pius - 1.3.0-5 - Fix silly typo in previous change. * Wed Sep 24 18:00:00 2008 Ralf Cors??pius - 1.3.0-4 - Work around rpmbuild having stopped supporting %patch -P N. libUnihan-0.5.1-0.fc10 ---------------------- * Tue Sep 23 18:00:00 2008 Ding-Yi Chen - 0.5.1-0 - New Features: + PinYin accent format conversion functions (C and SQL scalar). + ZhuYin tone mark format conversion functions (C and SQL scalar). + PinYin <--> ZhuYin conversion functions (C and SQL scalar). + Display as ZhuYin. - Fixed: + Correct counting in FreqRank field of kMandarin table. + The query functions such as unihan_find_all_matched() returns SQL_Results type, to avoid the memory leaking problems. - Changed: + unihanDb_open() now supports the R/W control. + Changed CMakefile.txt to reflects the version scheme change of UnihanDb + StringList type for storing const string arrays. + Add test suite. + Where-clause-generator is now able to escape the quote character('). + unihan_field_validation is moved to test/, therefore it will not be in binary package. + New make targets: rpm, srpm, rpm_db and srpm_db to generate rpm and srpm for libUnihan and UnihanDb. - Removed: + unihanSql_get_result_table(). As it uses sqlite3_get_table() which might cause memory leak. libX11-1.1.4-4.fc10 ------------------- * Wed Sep 17 18:00:00 2008 Adam Jackson 1.1.4-4 - libX11-1.1.4-xcb-xreply-leak.patch: Fix the BadFont case. * Wed Sep 17 18:00:00 2008 Adam Jackson 1.1.4-3 - libX11-1.1.4-xcb-xreply-leak.patch: Fix a leak when the client has a non-fatal error handler. (mclasen, fdo #17616) libbonobo-2.24.0-1.fc10 ----------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 * Sat Sep 20 18:00:00 2008 Peter Robinson - 2.23.1-2 - Kill dependency on perl RHBZ #462901 libbonoboui-2.24.0-1.fc10 ------------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 libcdio-0.80-3.fc10 ------------------- * Fri Sep 12 18:00:00 2008 Adrian Reber - 0.80-3 - fixed #462125 (Multilib conflict) libchewing-0.3.0.901-0.fc10 --------------------------- * Wed Sep 17 18:00:00 2008 Ding-Yi Chen - 0.3.0.901-0 - Upstream update. * Thu May 29 18:00:00 2008 Tom "spot" Callaway - 0.3.0-12 - fix license tag libcmpiutil-0.4-3.fc10 ---------------------- * Wed Sep 3 18:00:00 2008 Kaitlin Rupert - 0.4-3 - Added add handle_inv_class.patch to handle invalid classes in mof parser libepc-0.3.5-3.fc10 ------------------- * Sat Sep 20 18:00:00 2008 Brian Pepple - 0.3.5-3 - Add patch to fix building from source. libewf-20080501-3.fc10 ---------------------- * Mon Sep 15 18:00:00 2008 kwizart < kwizart at gmail.com > - 20080501-3 - Update mount_ewf to 20080910 - Switch URL to sourceforge site libgail-gnome-1.20.1-1.fc10 --------------------------- * Tue Sep 23 18:00:00 2008 Matthias Clasen - 1.20.1-1 - Update to 1.20.1 libgeotiff-1.2.5-2.fc10 ----------------------- * Mon Sep 15 18:00:00 2008 Balint Cristian - 1.2.5-2 - disable smp build for koji * Mon Sep 15 18:00:00 2008 Balint Cristian - 1.2.5-1 - new bugfix release libglademm24-2.6.7-1.fc10 ------------------------- * Wed Sep 24 18:00:00 2008 Denis Leroy - 2.6.7-1 - Update to upstream 2.6.7 libgnome-2.24.1-2.fc10 ---------------------- * Thu Sep 25 18:00:00 2008 Matthias Clasen - 2.24.1-2 - Save some space * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.1-1 - Update to 2.24.1 * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-2 - Update to 2.24.0 libgnomekbd-2.24.0-1.fc10 ------------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 libgnomemm26-2.24.0-1 --------------------- * Wed Sep 24 18:00:00 2008 Denis Leroy - 2.24.0-1 - Update to upstream 2.24.0 libgnomeprint22-2.18.5-1.fc10 ----------------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.18.5-1 - Update to 2.18.5 * Wed May 21 18:00:00 2008 Tom "spot" Callaway - 2.18.4-2 - fix license tag libgnomeprintui22-2.18.3-1.fc10 ------------------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.18.3-1 - Update to 2.18.3 * Wed May 21 18:00:00 2008 Tom "spot" Callaway - 2.18.2-2 - fix license tag libgnomeui-2.24.0-2.fc10 ------------------------ * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-2 - Update to 2.24.0 * Sat Sep 20 18:00:00 2008 Matthias Clasen - 2.23.90-3 - Plug a memory leak * Fri Sep 19 18:00:00 2008 Matthias Clasen - 2.23.90-2 - Plug a memory leak libgnomeuimm26-2.24.0-1.fc10 ---------------------------- * Wed Sep 24 18:00:00 2008 Denis Leroy - 2.24.0-1 - Update to upstream 2.24.0 libgphoto2-2.4.2-2.fc10 ----------------------- * Tue Sep 23 18:00:00 2008 Jindrich Novy 2.4.2-2 - convert all shipped docs to UTF-8 libgsf-1.14.9-2.fc10 -------------------- * Tue Sep 23 18:00:00 2008 Matthias Clasen - 1.14.9-2 - Drop the ImageMagick dependency again, since it causes size problems on the live cd libgtop2-2.24.0-1.fc10 ---------------------- * Tue Sep 23 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 libgweather-2.24.0-2.fc10 ------------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen 2.24.0-2 - Apply %lang tags to localized xml files * Mon Sep 22 18:00:00 2008 Matthias Clasen 2.24.0-1 - Update to 2.24.0 libjingle-0.3.12-1.fc10 ----------------------- * Wed Sep 17 18:00:00 2008 Brian Pepple - 0.3.12-1 - Update to 0.3.12. - Add hack to remove rpath. - Update source url. - Drop gcc patch. Fixed upstream. - Drop expat-devel BR. Not needed anymore. - Drop *.pc files no longer available. libjpeg-6b-43.fc10 ------------------ * Thu Sep 25 18:00:00 2008 Tom Lane - 6b-43 - Revert to using .gz instead of .bz2 tarball Resolves: #463903 libksba-1.0.4-1.fc10 -------------------- * Tue Sep 23 18:00:00 2008 Rex Dieter 1.0.4-1 - libksba-1.0.4 libmtp-0.3.3-1.fc10 ------------------- * Fri Sep 26 18:00:00 2008 Linus Walleij 0.3.3-1 - New upstream bugfix release. * Sat Sep 20 18:00:00 2008 Linus Walleij 0.3.2-1 - New upstream version. (API and ABI compatible.) Fixes bugs on Creative devices. libmusicbrainz3-3.0.2-1.fc10 ---------------------------- * Tue Sep 16 18:00:00 2008 Rex Dieter 3.0.2-1 - libmusicbrainz3-3.0.2 libpng10-1.0.40-1.fc10 ---------------------- * Fri Sep 19 18:00:00 2008 Paul Howarth 1.0.40-1 - update to 1.0.40 libprelude-0.9.21-1.fc10 ------------------------ * Fri Sep 19 18:00:00 2008 Steve Grubb - 0.9.21-1 - New upstream bugfix release libpreludedb-0.9.15.1-1.fc10 ---------------------------- * Sun Sep 14 18:00:00 2008 Steve Grubb 0.9.15.1-1 - new upstream bugfix release libpst-0.6.19-1.fc10 -------------------- * Sun Sep 14 18:00:00 2008 Carl Byington - 0.6.19-1 - Fix base64 encoding that could create long lines. - Initial work on a .so shared library from Bharath Acharya. * Thu Aug 28 18:00:00 2008 Carl Byington - 0.6.18-1 - Fixes for iconv on Mac from Justin Greer. libresample-0.1.3-6.fc10 ------------------------ * Thu Sep 11 18:00:00 2008 Jeffrey C. Ollie - 0.1.3-6 - Add a patch that switches to cmake for building and build a shared library. librsvg2-2.22.3-1.fc10 ---------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.22.3-1 - Update to 2.22.3 * Thu Sep 18 18:00:00 2008 Matthias Clasen - 2.22.2-2 - Plug a memory leak libselinux-2.0.71-6.fc10 ------------------------ * Fri Sep 26 18:00:00 2008 Dan Walsh - 2.0.71-6 - Fix matchpathcon -V call libsemanage-2.0.28-1.fc10 ------------------------- * Mon Sep 15 18:00:00 2008 Dan Walsh - 2.0.28-1 - Update to upstream * allow fcontext and seuser changes without rebuilding the policy from Dan Walsh libsexy-0.1.11-9.fc10 --------------------- * Sun Sep 21 18:00:00 2008 Brian Pepple - 0.1.11-9 - Backport fix for clipboard & color support in sexy-url-label. libsoup-2.24.0.1-1.fc10 ----------------------- * Wed Sep 24 18:00:00 2008 Matthias Clasen - 2.24.0.1-1 - Update to 2.24.0.1 * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 libtirpc-0.1.9-5.fc10 --------------------- * Tue Sep 16 18:00:00 2008 Steve Dickson 0.1.9-5 - Fix for taddr2addr conversion bug of local addresses - Fixed some of warnings in: src/auth_time.c, src/clnt_dg.c and src/clnt_raw.c - Added some #ifdef NOTUSED around some code in src/rpbc_clnt.c that was not being used... libunwind-0.99-0.6.frysk20070405cvs.fc10 ---------------------------------------- * Mon Sep 22 18:00:00 2008 Jan Kratochvil - 0.99-0.6.frysk20070405cvs - Fix build error due to a `dprintf' conflict on recent glibc. - New rpmbuild parameter: --without check libusb1-0.9.3-0.1.fc10 ---------------------- * Tue Sep 23 18:00:00 2008 Jindrich Novy 0.9.3-0.1 - update to 0.9.3 libv4l-0.5.0-1.fc10 ------------------- * Mon Sep 15 18:00:00 2008 Hans de Goede 0.5.0-1 - New upstream release 0.5.0 libvirt-0.4.6-3.fc10 -------------------- * Wed Sep 24 18:00:00 2008 Daniel Veillard - 0.4.6-3.fc10 - apply the python makefile patch for #463733 * Wed Sep 24 18:00:00 2008 Daniel Veillard - 0.4.6-2.fc10 - upstream release 0.4.6 - fixes some problems with 0.4.5 libvirt-cim-0.5.1-5.fc10 ------------------------ * Tue Sep 23 18:00:00 2008 Kaitlin Rupert - 0.5.1-5 - Added vsmigser_schema patch to remove dup method name from VSMigrationService - Added mem_parse patch to set proper mem max_size and mem values - Added mig_prof_ver patch to report the proper Migration Profile version - Added hyp_conn_fail patch to fix when not connecting to hyp returns a failure - Added rm_def_virtdev patch to remove default DiskRADSD virtual device - Added rm_eafp_err patch to remove error status when EAFP no pool link exists - Added sdc_unsup patch to make SDC not return unsup for RASD to AC case * Wed Aug 27 18:00:00 2008 Kaitlin Rupert - 0.5.1-4 - Added nostate patch to consider XenFV no state guests as running guests - Added createsnap_override patch to add vendor defined values to CreateSnapshot - Added add_shutdown_rsc patch to add support for shutdown operation - Added vsmc_add_remove patch to expose Add/Remove resources via VSMC - Added override_refconf patch to fix dup devs where ID matches refconf dev ID libwnck-2.24.0-1.fc10 --------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 libxcb-1.1.91-2.fc10 -------------------- * Thu Sep 11 18:00:00 2008 Adam Jackson 1.1.91-2 - Enable x-selinux bindings. libxklavier-3.7-3.fc10 ---------------------- * Fri Sep 19 18:00:00 2008 Matthias Clasen - 3.7-3 - Plug a memory leak lightning-1.2c-1.fc10 --------------------- * Sun Sep 28 18:00:00 2008 Jochen Schmitt 1.2c-1 - New upstream release lighttpd-1.4.20-0.1.r2303.fc10 ------------------------------ * Mon Sep 22 18:00:00 2008 Matthias Saou 1.4.20-0.1.r2303 - Update to 1.4.20 r2303 pre-release. * Mon Sep 22 18:00:00 2008 Matthias Saou 1.4.19-5 - Include memory leak patch (changeset #2305 from ticket #1774). lincity-ng-1.92-0.3.beta.fc10 ----------------------------- * Thu Sep 25 18:00:00 2008 Tom "spot" Callaway 1.92-0.3.beta - fix f9 crash (upstream bug #14544) * Tue Sep 23 18:00:00 2008 Tom "spot" Callaway 1.92-0.2.beta - fix typo in spec file * Tue Sep 23 18:00:00 2008 Tom "spot" Callaway 1.92-0.1.beta - update to 1.92.beta lineak-xosdplugin-0.9-5.fc10 ---------------------------- * Tue Sep 16 18:00:00 2008 Matt Domsch - 0.9-5 - fix FTBFS BZ#434522 by #including cstdlib and cstring * Thu Aug 7 18:00:00 2008 Tom "spot" Callaway - 0.9-4 - fix license tag * Wed Feb 20 17:00:00 2008 Fedora Release Engineering - 0.9-3 - Autorebuild for GCC 4.3 linpsk-0.9-4.fc10 ----------------- * Tue Sep 16 18:00:00 2008 Tom "spot" Callaway 0.9-4 - BR: qt3-devel linuxdcpp-1.0.2-2.fc10 ---------------------- * Thu Sep 25 18:00:00 2008 Marcin Garski 1.0.2-2 - Use XDG Downloads directory (#460749) lirc-0.8.4-0.1.pre1.fc10 ------------------------ * Wed Sep 24 18:00:00 2008 - Jarod Wilson - 0.8.4-0.1.pre1 - Update to 0.8.4pre1 - Drop upstream patches - Adds support for the CommandIR II userspace driver * Tue Sep 16 18:00:00 2008 - Jarod Wilson - 0.8.3-7 - Fix multilib upgrade path from F8 (Nicolas Chauvet, #462435) logwatch-7.3.6-28.fc10 ---------------------- * Mon Sep 15 18:00:00 2008 Ivana Varekova 7.3.6-28 - fix postfix script problem (#462174) lostlabyrinth-3.2.1-1.fc10 -------------------------- * Sun Sep 14 18:00:00 2008 Hans de Goede 3.2.1-1 - New upstream release 3.2.1 lostlabyrinth-graphics-3.2.1-1.fc10 ----------------------------------- * Sun Sep 14 18:00:00 2008 Hans de Goede 3.2.1-1 - New upstream version 3.2.1 lostlabyrinth-sounds-3.2.1-1.fc10 --------------------------------- * Sun Sep 14 18:00:00 2008 Hans de Goede 3.2.1-1 - Same old sounds as from the 2.5.2 release, but now packaged with the new 3.2.1 sound packer lrmi-0.10-5.fc10 ---------------- * Wed Sep 17 18:00:00 2008 Tom "spot" Callaway - 0.10-5 - fix compile against modern kernel headers - add BR: kernel-headers lyx-1.6.0-0.8.rc3.fc10 ---------------------- * Fri Sep 26 18:00:00 2008 Rex Dieter - 1.6.0-0.8.rc3 - lyx-1.6.0rc3-svn26576 * Fri Sep 12 18:00:00 2008 Rex Dieter - 1.6.0-0.7.rc2 - lyx-1.6.0rc2 make-3.81-14.fc10 ----------------- * Mon Sep 22 18:00:00 2008 Petr Machata - 1:3.81-14 - Fix patches to apply cleanly with fuzz=0 * Tue Sep 16 18:00:00 2008 Petr Machata - 1:3.81-13 - Mark opened files as cloexec to prevent their leaking through fork - Resolves: #462090 man-1.6f-11.fc10 ---------------- * Tue Sep 16 18:00:00 2008 Ivana Varekova - 1.6f-11 - Resolves: #460765 remove makewhatis patch which adds data from rpm database * Fri Sep 12 18:00:00 2008 Ivana Varekova - 1.6f-10 - Resolves: #461775 man needs lzma man-pages-3.09-2.fc10 --------------------- * Mon Sep 15 18:00:00 2008 Ivana Varekova - 3.09-2 - remove numa_maps.5 man page (part of numactl) * Fri Sep 12 18:00:00 2008 Ivana Varekova - 3.09-1 - update to 3.09 man-pages-ko-20050219-5.fc10 ---------------------------- * Mon Sep 15 18:00:00 2008 Ding-Yi Chen - 2:20050219-5 - Fix Bug 462197 - File conflict between man-pages-ko and rpm mapnik-0.5.2-0.4.svn738.fc10 ---------------------------- * Wed Sep 24 18:00:00 2008 Balint Cristian - 0.5.2-0.4.svn738 - use relative path in a demo file - enable mapnik.pc * Fri Sep 12 18:00:00 2008 Balint Cristian - 0.5.2-0.3.svn738 - enable libicu wrap * Fri Sep 12 18:00:00 2008 Balint Cristian - 0.5.2-0.2.svn738 - fix koji build - disable smp build with upstream scons * Thu Sep 11 18:00:00 2008 Balint Cristian - 0.5.2-0.1.svn738 - new cvs snapshot, x86_64 should work for now - new cairo dep added metacity-2.24.0-2.fc10 ---------------------- * Thu Sep 25 18:00:00 2008 Matthias Clasen - 2.24.0-2 - Save some space * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 * Fri Sep 19 18:00:00 2008 Matthias Clasen - 2.23.610-2 - Fix some memory leaks mfiler3-2.0.8a-3.fc10 --------------------- * Sat Sep 27 18:00:00 2008 Mamoru Tasaka - 2.0.8a-3 - Better system-wide cmigemo patch * Sat Sep 27 18:00:00 2008 Mamoru Tasaka - 2.0.8a-2 - Fix sparc64 build error * Fri Sep 26 18:00:00 2008 Mamoru Tasaka - 2.0.8a-1 - 2.0.8a - More better upgrade compat patch * Sun Sep 14 18:00:00 2008 Mamoru Tasaka - 2.0.7-2 - 2.0.7 - Workaround patch to deal with segv after upgrade microcode_ctl-1.17-1.46.fc10 ---------------------------- * Fri Sep 12 18:00:00 2008 Dave Jones - update to microcode 20080910 mimetic-0.9.3-5.fc10 -------------------- * Tue Sep 16 18:00:00 2008 Matt Domsch - 0.9.3-5 - fix FTBFS BR#434086 with several #include s * Fri Aug 8 18:00:00 2008 Tom "spot" Callaway - 0.9.3-4 - fix license tag * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 0.9.3-3 - Autorebuild for GCC 4.3 mod_perl-2.0.4-6 ---------------- mono-2.0-8.fc10 --------------- * Thu Sep 18 18:00:00 2008 Paul F. Johnson 2.0-8 - MimeIcon patch added * Wed Sep 17 18:00:00 2008 Paul F. Johnson 2.0-7 - TableLayoutSettings fix (bz 462005) monotone-0.41-1.fc10 -------------------- * Fri Sep 12 18:00:00 2008 Thomas Moschny - 0.41-1 - Updated for 0.41 release. - Added mtnopt helper. * Mon Aug 11 18:00:00 2008 Tom "spot" Callaway - 0.40-2 - fix license tag * Mon Apr 14 18:00:00 2008 Roland McGrath - 0.40-1 - Updated for 0.40 release. - Tweaked trivia for packaging guidelines nits. moreutils-0.31-1.fc10 --------------------- * Thu Aug 21 18:00:00 2008 Marc Bradshaw 0.31-1.fc10 - new upstream version 0.31 released with these changes - * pee.1: Document difference with tee in stdout. - * ts: Support displaying fractional seconds via a "%.S" conversion specification. mousetweaks-2.24.0-1.fc10 ------------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 mt-daapd-0.2.4.2-3.fc10 ----------------------- * Fri Sep 26 18:00:00 2008 W. Michael Petullo - 0.2.4.2-3 - Update init script, fix Fedora Bugzilla #461719. mtr-0.75-1.fc10 --------------- * Tue Sep 23 18:00:00 2008 Zdenek Prikryl - 2:0.75-1 - Updated to 0.75 - Removed confusing underflow patch - Removed format patch bacause of -w option muine-scrobbler-0.1.8-7.fc10 ---------------------------- * Wed Sep 17 18:00:00 2008 Tom "spot" Callaway - 0.1.8-7 - fix compile (not sure how well this works, but it builds now) * Wed Jun 4 18:00:00 2008 Sindre Pedersen Bj??rdal - 0.1.8-6 - rebuild for dependancies mx-3.1.1-2.fc10 --------------- * Mon Sep 15 18:00:00 2008 Toshio Kuratomi 3.1.1-2 - Restore debug package - Clean up the python site-packages handling - Clean up handling of documentation, examples, scripts * Mon Sep 15 18:00:00 2008 Paul F. Johnson 3.1.1-1 - bump to newest release - patch fixes - spec file fixes - branch new devel sub package - fixes to permissions - removed debug-package (empty) mysql-gui-tools-5.0r12-9.fc10 ----------------------------- * Mon Sep 15 18:00:00 2008 Dennis Gilmore - 5.0r12-9 - apply patch from Pavel Alexeev for gtk - bugzilla #433987 mysqltuner-0.9.9-1 ------------------ * Thu Sep 11 18:00:00 2008 Ville Skytt?? - 0.9.9-1 - 0.9.9. - Update description. nagi-2.06-6.fc10 ---------------- * Fri Sep 12 18:00:00 2008 Jon Ciesla 2.06-6 - Patch fuzz workaround, will fix. nagios-plugins-1.4.13-4.fc10 ---------------------------- * Sun Sep 28 18:00:00 2008 Mike McGrath 1.4.13-4 - Upstream released new version #464419 - Added patch fix for check_linux_raid #253898 - Upstream releases fix for #451015 - check_ntp_peers - Upstream released fix for #459309 - check_ntp - Added Provides Nagios::Plugins for #457404 - Fixed configure line for #458985 check_procs nautilus-2.24.0-2.fc10 ---------------------- * Thu Sep 25 18:00:00 2008 Matthias Clasen - 2.24.0-2 - Save some space * Sun Sep 21 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 * Sat Sep 20 18:00:00 2008 Matthias Clasen - 2.23.92-3 - Plug some memory leaks * Fri Sep 19 18:00:00 2008 Matthias Clasen - 2.23.92-2 - Plug some memory leaks nautilus-cd-burner-2.24.0-1.fc10 -------------------------------- * Tue Sep 23 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 nautilus-python-0.5.1-1.fc10 ---------------------------- * Wed Sep 24 18:00:00 2008 Trond Danielsen - 0.5.1-1 - New upstream version nautilus-sendto-1.1.0-1.fc10 ---------------------------- * Tue Sep 23 18:00:00 2008 - Bastien Nocera - 1.1.0 - Update to 1.1.0 nedit-5.5-19.fc10 ----------------- * Fri Sep 26 18:00:00 2008 Jindrich Novy 5.5-19 - rediff security patch to be applicable with zero fuzz nemiver-0.6.3-1.fc10 -------------------- * Sun Sep 28 18:00:00 2008 Peter Gordon - 0.6.3-1 - Update to new upstream release (0.6.3). - Set the minimum required version of gtkmm-24 to 2.12.7; and update the Summary field to reflect the current state of upstream, as recommended by Dodji Seketeli. - Resolves: #464413 (Nemiver 0.6.3 has been released upstream) * Sat Sep 13 18:00:00 2008 Peter Gordon - 0.6.2-1 - Update to new upstream release (0.6.2). net-snmp-5.4.2-3.fc10 --------------------- * Fri Sep 26 18:00:00 2008 Jan Safranek 5.4.2-3 - further tune up the distribution of files among subpackages and dependencies * Fri Sep 26 18:00:00 2008 Jan Safranek 5.4.2-2 - redistribute the perl scripts to the net-snmp package, net-snmp-utils doesn't depend on perl now (#462484) * Wed Sep 17 18:00:00 2008 Jan Safranek 5.4.2-1 - update to net-snmp-5.4.2 * Wed Sep 10 18:00:00 2008 John A. Khvatov 5.4.1-22 - add net-snmp-python netbeans-6.1-5.fc10 ------------------- * Mon Sep 15 18:00:00 2008 Victor G. Vasilyev 6.1-5 - A location of the productid file is changed - The swingapp module is removed from the small IDE configuration (netbeans-6.1-60-small-ide-config.patch) netbeans-platform8-6.1-5.fc10 ----------------------------- * Mon Sep 22 18:00:00 2008 Victor Vasilyev 6.1-5 - Patch3: Issue http://www.netbeans.org/issues/show_bug.cgi?id=143729 netgen-1.3.7-17.fc10 -------------------- * Mon Sep 15 18:00:00 2008 Chitlesh Goorah - 1.3.7-16 - rebuild for rawhide * Sun Apr 6 18:00:00 2008 Thibault North -1.3.7-15 - fixed compilation for current Tk version netpbm-10.35.52-1.fc10 ---------------------- * Sat Sep 27 18:00:00 2008 Jindrich Novy 10.35.52-1 - update to 10.35.52 - fixes crash of libppmd/ppmdraw when line is completely out of frame * Thu Sep 18 18:00:00 2008 Jindrich Novy 10.35.51-1 - update to netpbm-10.35.51 - make it actually compilable by removing duplicated function in pamcomp.c nntpgrab-0.3.91-2.fc10 ---------------------- * Sat Sep 13 18:00:00 2008 Erik van Pienbroek - 0.3.91-2 - BR: libtool added * Sat Sep 13 18:00:00 2008 Erik van Pienbroek - 0.3.91-1 - Update to 0.3.91 - Added a patch to use NSS instead of OpenSSL (with the help of nss_compat_ossl) - The .htaccess file was missing in the nntpgrab-web subpackage * Thu Aug 28 18:00:00 2008 Michael Schwendt - 0.3.90-3 - Include %_libdir/nntpgrab directory. nspluginwrapper-1.1.0-7.fc10 ---------------------------- * Wed Sep 17 18:00:00 2008 Martin Stransky 1.1.0-7 - Added libcurl to requires (#460988) nss-3.12.1.1-3.fc10 ------------------- * Wed Sep 24 18:00:00 2008 Kai Engert - 3.12.1.1-3 - bug 456847, move pkgconfig requirement to devel package nss_compat_ossl-0.9.3-1.fc10 ---------------------------- * Fri Sep 12 18:00:00 2008 Rob Crittenden - 0.9.3-1 - update to 0.9.3 nted-1.2.1-1.fc10 ----------------- * Fri Sep 19 18:00:00 2008 Hans Ulrich Niedermann - 1.2.1-1 - Update to upstream's 1.2.1 release. ntfs-3g-1.2926-0.1.RC.fc10 -------------------------- * Mon Sep 22 18:00:00 2008 Tom "spot" Callaway - 2:1.2926-0.1.RC - update to 1.2926-RC (rawhide, F10) nut-2.2.2-3.fc10 ---------------- * Mon Sep 15 18:00:00 2008 Tomas Smetana 2.2.2-3 - fix #461374 - add missing udev rules obex-data-server-0.3.4-8.fc10 ----------------------------- * Mon Sep 15 18:00:00 2008 - Bastien Nocera - 0.3.4-8 - Add ImageMagic BR * Mon Sep 15 18:00:00 2008 - Bastien Nocera - 0.3.4-7 - Add missing patch * Mon Sep 15 18:00:00 2008 - Bastien Nocera - 0.3.4-6 - Update to latest SVN trunk, with BlueZ 4 patch * Fri Sep 12 18:00:00 2008 - Bastien Nocera - 0.3.4-5 - Another BlueZ 4.x patch update * Fri Sep 12 18:00:00 2008 - Bastien Nocera - 0.3.4-4 - Update bluez 4.x patch for the latest D-Bus API ocaml-lablgtk-2.10.1-5.fc10 --------------------------- * Mon Sep 22 18:00:00 2008 Richard W.M. Jones - 2.10.1-5 - Ignore bogus requires GtkSourceView_types. * Thu Sep 18 18:00:00 2008 Richard W.M. Jones - 2.10.1-4 - Add missing BR for gtksourceview-devel (rhbz#462651). ochusha-0.5.99.66-0.6.cvs070110.fc10 ------------------------------------ * Sun Sep 21 18:00:00 2008 Mamoru Tasaka - ochusha-0.5.99.66-0.6.cvs070110 - Patch to deal with occational cookie change ode-0.10.1-1.fc10 ----------------- * Mon Sep 15 18:00:00 2008 Hans de Goede 0.10.1-1 - New upstream release 0.10.1 (bz 460033) oggconvert-0.3.2-1.fc10 ----------------------- * Tue Sep 16 18:00:00 2008 Matt Domsch - 0.3.2-1 - upgrade to 0.3.2, fix FTBFS BZ#440943 opal-3.4.1-1.fc10 ----------------- * Tue Sep 23 18:00:00 2008 Peter Robinson - 3.4.1-1 - Update to new stable release for ekiga 3 open-cobol-1.0.90-4.fc10 ------------------------ * Mon Sep 15 18:00:00 2008 Jochen Schmitt 1.0.90-4 - Remove _FORTIFY_SOURCE as adviced by the upstream openais-0.91-1.fc10 ------------------- * Fri Aug 15 18:00:00 2008 Steven dake 0.91-1 - Upgrade to work with upstream corosync cluster engine. openoffice.org-3.0.0-7.1.fc10 ----------------------------- * Sun Sep 21 18:00:00 2008 Caol??n McNamara - 1:3.0.0-7.1 - Tswana, Ukrainian, Urdu spellcheckers - Resolves: rhbz#462833 openoffice.org-3.0.0.ooo94069.psprint.defconfig.patch - Resolves: rhbz#463050 rejig desktop-file-utils, shared-mime-info usage * Tue Sep 16 18:00:00 2008 Caol??n McNamara - 1:3.0.0-6.1 - next candidate - use system jfreereport - Basque, Ndebele, Swati, Southern Sotho, Northern Sotho, Tsonga, Venda, Xhosa spellcheckers - add openoffice.org-3.0.0.ooo93419.svx.accessibity-loops.patch - add openoffice.org-3.0.0.ooo93949.sw.better_rtf_encodings.patch openswan-2.6.16-2.fc10 ---------------------- * Fri Sep 12 18:00:00 2008 Avesh Agarwal - 2.6.16-2 - added initscript patch to prevent openswan service start by default orca-2.24.0-1.fc10 ------------------ * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 oyranos-0.1.7-12.fc10 --------------------- * Sun Sep 28 18:00:00 2008 kwizart < kwizart at gmail.com > - 0.1.7-12 - Fix patch fuzz pam-1.0.2-2.fc10 ---------------- * Tue Sep 23 18:00:00 2008 Tomas Mraz 1.0.2-2 - new password quality checks in pam_cracklib - report failed logins from btmp in pam_lastlog - allow larger groups in modutil functions - fix leaked file descriptor in pam_tally pango-1.22.0-1.1.fc10 --------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 1.22.0-1 - Update to 1.22.0 * Mon Sep 22 18:00:00 2008 Behdad Esfahbod - 1.22.0-1.1 - Rebuild against cairo 1.7.6 - Update cairo and glib required versions pangomm-2.14.0-1.fc10 --------------------- * Tue Sep 23 18:00:00 2008 Denis Leroy - 2.14.0-1 - Update to stable 2.14.0 pciutils-3.0.2-1.fc10 --------------------- * Mon Sep 22 18:00:00 2008 Michal Hlavinka 3.0.1-1 - version 3.0.2 * Fri Sep 19 18:00:00 2008 Michal Hlavinka 3.0.1-1 - version 3.0.1 - add support for Super-H (sh3,sh4) (#446600) - fix: broken -L in libpci.pc (#456469) pcmanx-gtk2-0.3.8-2.fc10 ------------------------ * Thu Sep 25 18:00:00 2008 Tom "spot" Callaway - 0.3.8-2 - rebuild against xulrunner 1.9.0.2 pdns-2.9.21.1-2.fc10 -------------------- * Fri Sep 12 18:00:00 2008 Ruben Kerkhof 2.9.21.1-2 - Fix handling of AAAA records (bz #461768) pekwm-0.1.5-8.fc10 ------------------ * Wed Sep 17 18:00:00 2008 Matt Domsch - 0.1.5-8 - fix FTBFS BZ#434089 * Thu Aug 28 18:00:00 2008 Tom "spot" Callaway - 0.1.5-7 - fix license tag * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 0.1.5-6 - Autorebuild for GCC 4.3 perl-5.10.0-44.fc10 ------------------- * Wed Sep 17 18:00:00 2008 Marcela Maslanova 4:5.10.0-44.fc10 - remove Tar.pm from Archive-Extract - fix version of Test::Simple in spec - update Test::Simple - update Archive::Tar to 1.38 * Tue Sep 16 18:00:00 2008 Marcela Maslanova 4:5.10.0-43.fc10 - 462444 update Test::Simple to 0.80 * Thu Aug 14 18:00:00 2008 Stepan Kasal - 4:5.10.0-42.fc10 - move libnet to the right directory, along Net/Config.pm perl-Catalyst-Plugin-Authentication-0.10007-1.fc10 -------------------------------------------------- * Thu Sep 25 18:00:00 2008 Chris Weyl 0.10007-1 - update to 0.10007 perl-Class-Data-Accessor-0.04004-1.fc10 --------------------------------------- * Thu Sep 25 18:00:00 2008 Chris Weyl 0.04004-1 - update to 0.04004 perl-Class-Factory-1.06-1.fc10 ------------------------------ * Thu Sep 25 18:00:00 2008 Chris Weyl 1.06-1 - update to 1.06 perl-Config-Any-0.14-1.fc10 --------------------------- * Thu Sep 25 18:00:00 2008 Chris Weyl 0.14-1 - update to 0.14 - add XML::LibXML to br's perl-Crypt-SSLeay-0.57-8.fc10 ----------------------------- * Wed Sep 24 18:00:00 2008 Marcela Maslanova - 0.57-8 - fix patches for fuzz perl-Data-Dump-1.11-1.fc10 -------------------------- * Thu Sep 25 18:00:00 2008 Chris Weyl 1.11-1 - update to 1.11 perl-DateTime-Format-Strptime-1.0800-1.fc10 ------------------------------------------- * Fri Aug 29 18:00:00 2008 Steven Pritchard 1.0800-1 - Update to 1.0800. - Update versions on build dependencies. perl-GraphViz-2.03-1.fc10 ------------------------- * Thu Sep 25 18:00:00 2008 Chris Weyl 2.03-1 - update to 2.03 perl-IO-Multiplex-1.10-1.fc10 ----------------------------- * Mon Sep 15 18:00:00 2008 Tom "spot" Callaway - 1.10-1 - update to 1.10, upstream found and relicensing has happened! perl-IO-Socket-SSL-1.16-1.fc10 ------------------------------ * Mon Sep 22 18:00:00 2008 Paul Howarth - 1.16-1 - Update to latest upstream version: 1.16 perl-PDL-2.4.3-14.fc10 ---------------------- * Thu Sep 18 18:00:00 2008 Marcela Maslanova - 2.4.3-14 - 461803 Missing Functions from PDL::Graphics::PLplot perl-Perl-MinimumVersion-1.19-1.fc10 ------------------------------------ * Tue Sep 16 18:00:00 2008 Ralf Cors??pius - 1.19-1 - Upstream update. perl-TAP-Harness-Archive-0.12-1.fc10 ------------------------------------ * Tue Sep 23 18:00:00 2008 Lubomir Rintel (Good Data) - 0.12-1 - New upstream version perl-Test-AutoBuild-1.2.2-5.fc10 -------------------------------- * Tue Sep 23 18:00:00 2008 Daniel P. Berrange - 1.2.2-5.fc10 - Don't use -A to clear sticky tag when specifying a branch - Perform 'mtn db migrate' when running monotone test suite - Drop noarch until ghc comes to ppc/alpha * Thu Sep 18 18:00:00 2008 Jens Petersen - 1.2.2-4.fc10 - exclude darcs subpackage on ppc64 and alpha where there is no ghc currently perl-Test-ClassAPI-1.05-3.fc10 ------------------------------ * Tue Sep 16 18:00:00 2008 Ralf Cors??pius - 1.05-3 - Reflect perl(Test::CPAN::Meta) >= 0.12 finally being available in Fedora. perl-Test-Expect-0.31-1.fc10 ---------------------------- * Tue Sep 16 18:00:00 2008 Ralf Cors??pius - 0.31-1 - Upgrade to 0.31 (Required by rt3's testsuite, BZ 462440). perl-bioperl-1.5.2_102-13.fc10 ------------------------------ * Thu Sep 25 18:00:00 2008 Alex Lancaster - 1.5.2_102-13 - Fix patch fuzz perl-libwww-perl-5.814-2.fc10 ----------------------------- * Thu Sep 18 18:00:00 2008 Marcela Maslanova 5.814-2 - use untaint patch from Villa Skyte * Thu Sep 18 18:00:00 2008 Marcela Maslanova 5.814-1 - update to 5.814 - remove patch, now we have all upstream tests on petitboot-0.0.1-10.fc10 ----------------------- * Thu Sep 18 18:00:00 2008 Matt Domsch - 0.0.1-10 - Build fix: include in devices/udev-helper.c. FTBFS BZ#434110 * Wed Apr 23 18:00:00 2008 David Woodhouse 0.0.1-9 - Build fix: include in devices/udev-helper.c * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 0.0.1-8 - Autorebuild for GCC 4.3 phonon-4.2.0-5.fc10 ------------------- * Wed Sep 17 18:00:00 2008 Rex Dieter 4.2.0-5 - Requires: phonon-backend-xine php-5.2.6-5 ----------- * Sat Sep 13 18:00:00 2008 Remi Collet 5.2.6-5 - enable XPM support in php-gd - Fix BR for php-gd php-ZendFramework-1.6.0-1.fc10 ------------------------------ * Sat Sep 13 18:00:00 2008 Alexander Kahl - 1.6.0-1 - update to 1.6.0 stable (full version) - create list of invalid executables in %build for upstream - new components Captcha, Dojo, Service-ReCaptcha, Wildfire, Zend_Tool - BuildRequire symlinks to sanitize zf -> zf.sh symlink php-pear-Date-Holidays-0.20.1-1.fc10 ------------------------------------ * Fri Sep 12 18:00:00 2008 Christopher Stone 0.20.1-1 - Upstream sync php-pear-HTTP-1.4.1-2.fc10 -------------------------- * Sat Sep 13 18:00:00 2008 Remi Collet 1.4.1-2 - Fix BR for PEAR >= 1.7.1 php-pear-HTTP-Request-1.4.3-1.fc10 ---------------------------------- * Fri Sep 12 18:00:00 2008 Christopher Stone 1.4.3-1 - Upstream sync - Update Requires php-pear-Pager-2.4.7-1.fc10 --------------------------- * Fri Sep 12 18:00:00 2008 Christopher Stone 2.4.7-1 - Upstream sync php-pecl-memcache-3.0.2-1.fc10 ------------------------------ * Thu Sep 11 18:00:00 2008 Remi Collet 3.0.2-1 - new version 3.0.2 * Thu Sep 11 18:00:00 2008 Remi Collet 2.2.4-1 - new version 2.2.4 (bug fixes) phpMyAdmin-2.11.9.2-1.fc10 -------------------------- * Mon Sep 22 18:00:00 2008 Robert Scheck 2.11.9.2-1 - Upstream released 2.11.9.2 (#463260) * Tue Sep 16 18:00:00 2008 Robert Scheck 2.11.9.1-1 - Upstream released 2.11.9.1 (#462430) phpldapadmin-1.1.0.5-2.fc10 --------------------------- * Fri Sep 26 18:00:00 2008 Dmitry Butskoy - 1.1.0.5-2 - update config patch pic2aa-0.2.1-3.fc10 ------------------- picviz-0.2.3-2.fc10 ------------------- * Mon Sep 22 18:00:00 2008 Tomas Heinrich 0.2.3-2 - fix plugin path (#462700) pidgin-2.5.1-3.fc10 ------------------- * Tue Sep 16 18:00:00 2008 Stu Tomlinson 2.5.1-3 - Backport fixes from upstream: Add "Has You:" back to MSN tooltips Fix crash during removal of your own buddy icon Fix crash when handling self signed certificate with NSS SSL * Tue Sep 16 18:00:00 2008 Stu Tomlinson 2.5.1-2 - Fix a crash with GNOME proxy enabled (#461951) pigment-0.3.8-1.fc10 -------------------- * Fri Sep 12 18:00:00 2008 Matthias Saou 0.3.8-1 - Update to 0.3.8. pigment-python-0.3.6-1.fc10 --------------------------- * Fri Sep 12 18:00:00 2008 Matthias Saou 0.3.6-1 - Update to 0.3.6. pilot-link-0.12.3-18.fc10 ------------------------- * Tue Sep 23 18:00:00 2008 Ivana Varekova - 2:0.12.3-18 - extend clio patch - thanks Kevin R. Page * Fri Sep 19 18:00:00 2008 Ivana Varekova - 2:0.12.3-17 - split perl subpackage (461758) - thanks Peter Robinson - spec file cleanup * Fri Sep 19 18:00:00 2008 Ivana Varekova - 2:0.12.3-16 - add clio patch (454178) - thanks Michael Ekstrand pinot-0.89-1.fc10 ----------------- * Sun Sep 21 18:00:00 2008 Adel Gadllah 0.89-1 - Update to 0.89 * Sat Aug 30 18:00:00 2008 Adel Gadllah 0.88-2 - Fix build * Sat Aug 30 18:00:00 2008 Adel Gadllah 0.88-1 - Update to 0.88 pixman-0.12.0-1.fc10 -------------------- * Wed Sep 17 18:00:00 2008 Soren Sandmann 0.12.0-1 - Upgrade to 0.12.0. Drop stripes patch. pl-5.6.60-2.fc10 ---------------- * Fri Sep 19 18:00:00 2008 Tom "spot" Callaway - 5.6.60-2 - forgot to remove ANNOUNCE from doc list * Fri Sep 19 18:00:00 2008 Tom "spot" Callaway - 5.6.60-1 - update to 5.6.60 - use openjdk (FIXME: there may be a way to make this more generic) plague-0.4.5.6-1.fc10 --------------------- * Sun Sep 21 18:00:00 2008 Michael Schwendt - 0.4.5.6-1 - update to 0.4.5.6 * Sat Sep 20 18:00:00 2008 Michael Schwendt - 0.4.5.5-2 - add fix for sqlite's limited ALTER TABLE planner-0.14.3-4.fc10 --------------------- * Tue Sep 16 18:00:00 2008 Caol??n McNamara - 0.14.3-4 - remove some .la files plexus-runtime-builder-1.0-0.2.a9.1.6.fc10 ------------------------------------------ * Wed Sep 24 18:00:00 2008 Deepak Bhole 1.0-0.2.a9.1.6 - Add proper patch number plexus-xmlrpc-1.0-0.2.b4.2.11.fc10 ---------------------------------- * Wed Sep 24 18:00:00 2008 Deepak Bhole 1.0-0.2.b4.2.11 - Update xmlrpc-add-codec-dep.patch to remove fuzz... for real this time * Wed Sep 24 18:00:00 2008 Deepak Bhole 1.0-0.2.b4.2.10 - Update patch0 to remove fuzz. plt-scheme-4.1-1.fc10 --------------------- * Mon Sep 15 18:00:00 2008 Gerard Milmeister - 1:4.1-1 - new release 4.1 plymouth-0.6.0-0.2008.09.25.1.fc10 ---------------------------------- * Thu Sep 25 18:00:00 2008 Ray Strode 0.5.0-0.2008.09.25.1 - Add new snapshot to fold in Will Woods progress bar, and move ajax's splash upstream, putting the old text splash in a "pulser" subpackage * Tue Sep 23 18:00:00 2008 Ray Strode 0.5.0-0.2008.09.23.1 - Last snapshot was broken * Mon Sep 22 18:00:00 2008 Ray Strode 0.5.0-0.2008.09.22.1 - Update to latest snapshot to get better transition support * Fri Sep 19 18:00:00 2008 Ray Strode 0.5.0-0.2008.09.15.2 - Turn on gdm trigger for transition * Mon Sep 15 18:00:00 2008 Ray Strode 0.5.0-0.2008.09.15.1 - add quit command with --retain-splash option to client pmount-0.9.17-3.fc10 -------------------- * Thu Sep 25 18:00:00 2008 Patrice Dumas 0.9.17-3 - rediff nosetuid patch pnm2ppa-1.04-16.fc10 -------------------- * Wed Sep 24 18:00:00 2008 Tim Waugh 1:1.04-16 - Removed patch fuzz. policycoreutils-2.0.56-1.fc10 ----------------------------- * Fri Sep 12 18:00:00 2008 Dan Walsh 2.0.56-1 - Fix semanage help display - Update to upstream * fixfiles will now remove all files in /tmp and will check for unlabeled_t in /tmp and /var/tmp from Dan Walsh. * add glob support to restorecond from Dan Walsh. * allow semanage to handle multi-line commands in a single transaction from Dan Walsh. postfix-2.5.5-1.fc10 -------------------- * Wed Sep 17 18:00:00 2008 Thomas Woerner 2:2.5.5-1 - new version 2.5.5 fixes CVE-2008-2936, CVE-2008-2937 and CVE-2008-3889 (rhbz#459101) postgresql-8.3.4-1.fc10 ----------------------- * Thu Sep 25 18:00:00 2008 Tom Lane 8.3.4-1 - Update to PostgreSQL 8.3.4. powerman-2.2-1.fc10 ------------------- * Mon Sep 15 18:00:00 2008 Steven M. Parrish 2.2-1 - New upstream release preupgrade-0.9.8-1.fc10 ----------------------- * Thu Sep 18 18:00:00 2008 Will Woods - 0.9.8-1 - GUI version prompts to resume interrupted runs - Checks for available disk space before downloading / rebooting - Does not change boot target until you hit the Reboot button - Handle invalid treeinfo gracefully (bug #459935) - Use UUID=xxx for devices - makes finding devices much more robust - No more network dialog for missing packages - Use anaconda's own depsolving tweaks (whiteout/blacklist) - Use kickstart to automate installs pspp-0.6.0-8.fc10 ----------------- * Thu Sep 25 18:00:00 2008 Mat??j Cepl - 0.6.0-8 - Fix wrong CFLAGS -- add -fgnu89-inline pstoedit-3.45-4.fc10 -------------------- * Wed Sep 24 18:00:00 2008 Denis Leroy - 3.45-4 - Fixed cxxflags patch fuziness issue ptlib-2.4.1-1.fc10 ------------------ * Tue Sep 23 18:00:00 2008 Peter Robinson - 2.4.1-1 - Update to new stable release for ekiga 3, disable v4l1 pyOpenSSL-0.7-2.fc10 -------------------- * Fri Sep 19 18:00:00 2008 Dennis Gilmore - 0.7-2 - update threadsafe patch - bug#462807 * Mon Sep 15 18:00:00 2008 Paul F. Johnson 0.7-1 - bump to new release - the inevitable patch fixes pyPdf-1.12-1.fc10 ----------------- * Mon Sep 15 18:00:00 2008 Felix Schwarz 1.12-1 - update to 1.12 pybackpack-0.5.6-1.fc10 ----------------------- * Fri Sep 26 18:00:00 2008 Andy Price - 0.5.6-1 - Updated RPM to 0.5.6 - Spec updated to handle installation of translations pydot-1.0.2-1.fc10 ------------------ * Fri Sep 12 18:00:00 2008 Tom "spot" Callaway - 1.0.2-1 - update to 1.0.2 pygame-1.8.1-2.fc10 ------------------- * Wed Sep 17 18:00:00 2008 Robin Norwood 1.8.1-2 - Bump release to trump F9 version. pygtksourceview-2.4.0-1.fc10 ---------------------------- * Sun Sep 21 18:00:00 2008 Matthias Clasen - 2.4.0-1 - Update to 2.4.0 pyke-0.4-1.fc10 --------------- * Fri Sep 12 18:00:00 2008 Tom "spot" Callaway 0.4-1 - update to 0.4 pykickstart-1.44-1.fc10 ----------------------- * Mon Sep 22 18:00:00 2008 Chris Lumens - 1.44-1 - Add support for reverse CHAP to the kickstart iscsi command (hans) - Fix typo (katzj) pyorbit-2.24.0-1.fc10 --------------------- * Tue Sep 23 18:00:00 2008 Matthew Barnes - 2.24.0-1.fc10 - Update to 2.24.0 * Fri Aug 29 18:00:00 2008 Tom "spot" Callaway - 2.14.3-3 - fix license tag python-durus-3.5-6.fc10 ----------------------- * Tue Sep 16 18:00:00 2008 Matt Domsch - 3.5-6 - fix FTBFS BZ#434427 * Fri Mar 7 17:00:00 2008 Jesse Keating - 3.5-5 - Drop the pyver stuff, no longer needed. * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 3.5-4 - Autorebuild for GCC 4.3 python-elixir-0.6.1-1.fc10 -------------------------- * Wed Sep 17 18:00:00 2008 James Bowes 0.6.1-1 - Update to 0.6.1 python-fedora-0.3.6-2.fc10 -------------------------- * Mon Sep 15 18:00:00 2008 Toshio Kuratomi - 0.3.6-2 - Add python-sphinx to the buildrequires. * Mon Sep 15 18:00:00 2008 Toshio Kuratomi - 0.3.6-1 - New upstream. No longer deps on koji. python-gammu-0.26-3.fc10 ------------------------ * Sun Sep 14 18:00:00 2008 Xavier Lamien - 0.26-3 - Rebuild. * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 0.26-2 - fix license tag python-html2text-2.33-1.1 ------------------------- * Sat Sep 27 18:00:00 2008 Thorsten Leemhuis - 2.33-1 - update to 2.33 python-markdown2-1.0.1.9-1.fc10 ------------------------------- * Fri Sep 12 18:00:00 2008 Thomas Moschny - 1.0.1.9-1 - Update to 1.0.1.9. python-netaddr-0.5.1-1.fc10 --------------------------- * Tue Sep 23 18:00:00 2008 John Eckersberg - 0.5.1-1 - New upstream version, bug fixes for 0.5 * Sun Sep 21 18:00:00 2008 John Eckersberg - 0.5-1 - New upstream version python-pp-1.5.6-1.fc10 ---------------------- * Sun Sep 14 18:00:00 2008 Steve 'Ashcrow' Milner - 1.5.6-1 - Updated to upstream latest stable. python-pygments-0.11.1-1.fc10 ----------------------------- * Sun Sep 14 18:00:00 2008 Steve 'Ashcrow' Milner - 0.11.1-1 - Updated for upstream 0.11. python-simplejson-1.9.3-1.fc10 ------------------------------ * Wed Sep 24 18:00:00 2008 Luke Macken - 1.9.3-1 - Update to 1.9.3, which includes a significant decoding speed boost, and various bug fixes. python-simpletal-4.1-8.fc10 --------------------------- * Mon Sep 15 18:00:00 2008 Tom "spot" Callaway - 4.1-8 - fix missing egg-info * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 4.1-7 - drop old abi Requires * Wed Sep 3 18:00:00 2008 Tom "spot" Callaway - 4.1-6 - fix license tag python-slip-0.1.14-1.fc10 ------------------------- * Mon Sep 15 18:00:00 2008 Nils Philippsen - 0.1.14 - clarify examples a bit python-turbojson-1.2.1-2.fc10 ----------------------------- * Wed Sep 17 18:00:00 2008 Luke Macken 1.2.1-2 - Require python-prioritized-methods > 0.2 * Tue Sep 16 18:00:00 2008 Luke Macken 1.2.1-1 - Latest release of the 1.2.x series - Require python-peak-rules (#459157, #459117) pytrainer-1.6.0.5-2.fc10 ------------------------ * Tue Sep 23 18:00:00 2008 Douglas E. Warner 1.6.0.5-2 - replacing environ hack patch with shell script - adding patch to clean up desktop file * Mon Sep 15 18:00:00 2008 Douglas E. Warner 1.6.0.5-1 - updating to 1.6.0.5 qscintilla-2.3-1.fc10 --------------------- * Mon Sep 22 18:00:00 2008 Rex Dieter - 2.3-1 - Qscintilla-gpl-2.3 - scintilla_ver is missing (#461777) qt-4.4.3-1.fc10 --------------- * Sun Sep 28 18:00:00 2008 Rex Dieter 4.4.3-1 - 4.4.3 * Wed Sep 24 18:00:00 2008 Rex Dieter 4.4.2-2 - omit systray patch (for now) * Sat Sep 20 18:00:00 2008 Than Ngo 4.4.2-1 - 4.4.2 qt3-3.3.8b-15.fc10 ------------------ * Sat Sep 20 18:00:00 2008 Kevin Kofler - 3.3.8b-15 - set _default_patch_fuzz (fixes FTBFS) quassel-0.3.0.1-1.fc10 ---------------------- * Tue Sep 16 18:00:00 2008 Steven M. Parrish 0.3.0.1-1 - New upstream release rafkill-1.2.3-2.fc10 -------------------- * Fri Sep 12 18:00:00 2008 Jon Ciesla - 1.2.3-2 - Added patch fuxx workaround, will fix. - Fixed license tag. rawstudio-1.1-1.fc10 -------------------- * Tue Sep 16 18:00:00 2008 Gianluca Sforna - 1.1-1 - new upstream release rhpl-0.216-2 ------------ * Wed Sep 24 18:00:00 2008 Adam Jackson 0.216-2 - rhpl-0.216-no-model.patch: Don't set XKB model, it's not meaningful for evdev keyboards and it makes your arrow keys not work. (#461832) ricci-0.15.0-4.fc10 ------------------- * Fri Sep 26 18:00:00 2008 Fabio M. Di Nitto 0.15.0-4 - Drop BuildRequires on cman-devel as it's not required. * Fri Sep 26 18:00:00 2008 Fabio M. Di Nitto 0.15.0-3 - Add versioned BR on cman-devel rkhunter-1.3.2-5.fc10 --------------------- * Wed Sep 3 18:00:00 2008 Kevin Fenzi - 1.3.2-5 - Patch debug tmp file issue - bug #460628 rpcbind-0.1.6-2.fc10 -------------------- * Tue Sep 16 18:00:00 2008 Steve Dickson 0.1.6-2 - Added usptream patches 01 thru 03 that do: * Introduce helpers for ipprot/netid mapping * Change how we decide on the netids to use for portmap * Simplify port live check in pmap_svc.c rpm-4.5.90-0.git8461.8 ---------------------- * Thu Sep 25 18:00:00 2008 Jindrich Novy - don't treat %patch numberless if -P parameter is present (#463942) rpmlint-0.84-3.fc10 ------------------- * Fri Sep 12 18:00:00 2008 Tom "spot" Callaway - 0.84-3 - Sync Fedora license list with Wiki revision 1.09 rpmreaper-0.1.5-1.fc10 ---------------------- * Fri Sep 19 18:00:00 2008 Miroslav Lichvar 0.1.5-1 - update to 0.1.5 rrdtool-1.3.3-1.fc10 -------------------- * Mon Sep 15 18:00:00 2008 Jarod Wilson 1.3.3-1 - Update to rrdtool 1.3.3 * fixes segfault on graph creation regression in 1.3.2 (#462301) rsyslog-3.21.3-4.fc10 --------------------- * Mon Sep 15 18:00:00 2008 Peter Vrabec 3.21.3-4 - use RPM_OPT_FLAGS - use same pid file and logrotate file as syslog-ng (#441664) - mark config files as noreplace (#428155) ruby-RMagick-2.6.0-1.fc10 ------------------------- * Thu Sep 18 18:00:00 2008 Mamoru Tasaka - 2.6.0-1 - 2.6.0 ruby-aws-0.4.3-1.fc10 --------------------- * Thu Sep 25 18:00:00 2008 Mamoru Tasaka - 0.4.3-1 - 0.4.3 * Thu Sep 18 18:00:00 2008 Mamoru Tasaka - 0.4.2-1 - 0.4.2 ruby-bdb-0.6.5-1.fc10 --------------------- * Wed Sep 17 18:00:00 2008 Matt Domsch - 0.6.5-1 - update to 0.6.5, fix FTBFS BZ#434090 * Fri Jun 20 18:00:00 2008 Tom "spot" Callaway - 0.6.4-1 - update to 0.6.4 * Mon Feb 18 17:00:00 2008 Fedora Release Engineering - 0.6.0-2 - Autorebuild for GCC 4.3 ruby-gettext-package-1.93.0-1.fc10 ---------------------------------- * Thu Sep 18 18:00:00 2008 Mamoru Tasaka - 1.93.0-1 - 1.93.0 ruby-gnome2-0.17.0-3.fc10 ------------------------- * Thu Sep 18 18:00:00 2008 Mamoru Tasaka 0.17.0-3 - Patch from svn to fix Ruby/Glib bug (bug 456816) * Fri Sep 12 18:00:00 2008 Allisson Azevedo 0.17.0-2 - Rebuild against new gstreamer-devel ruby-mechanize-0.8.0-1.fc10 --------------------------- * Thu Sep 25 18:00:00 2008 Mamoru Tasaka - 0.8.0-1 - 0.8.0 rubygem-actionmailer-2.1.1-1.fc10 --------------------------------- * Tue Sep 16 18:00:00 2008 David Lutterkort - 2.1.1-1 - New version (fixes CVE-2008-4094) rubygem-actionpack-2.1.1-1.fc10 ------------------------------- * Tue Sep 16 18:00:00 2008 David Lutterkort - 2.1.1-1 - New version (fixes CVE-2008-4094) rubygem-activerecord-2.1.1-1.fc10 --------------------------------- * Tue Sep 16 18:00:00 2008 David Lutterkort - 2.1.1-2 - New version (fixes CVE-2008-4094) rubygem-activeresource-2.1.1-1.fc10 ----------------------------------- * Tue Sep 16 18:00:00 2008 David Lutterkort - 2.1.1-1 - New version (fixes CVE-2008-4094) rubygem-activesupport-2.1.1-1.fc10 ---------------------------------- * Tue Sep 16 18:00:00 2008 David Lutterkort - 2.1.1-1 - New version (fixes CVE-2008-4094) rubygem-rails-2.1.1-2.fc10 -------------------------- * Tue Sep 16 18:00:00 2008 David Lutterkort - 2.1.1-2 - require rubygems >= 1.1.1; the rails code checks that at runtime * Tue Sep 16 18:00:00 2008 David Lutterkort - 2.1.1-1 - New version (fixes CVE-2008-4094) rubygems-1.2.0-2.fc10 --------------------- * Tue Sep 16 18:00:00 2008 David Lutterkort - 1.2.0-2 - Bump release because I forgot to check in newer patch * Tue Sep 16 18:00:00 2008 David Lutterkort - 1.2.0-1 - Updated for new setup.rb - Simplified by removing conditionals that were needed for EL-4; there's just no way we can support that with newer rubygems s3cmd-0.9.8.3-4.fc10 -------------------- * Fri Sep 26 18:00:00 2008 Lubomir Rintel (Good Data) - 0.9.8.3-4 - Try 3/65536 * Fri Sep 26 18:00:00 2008 Lubomir Rintel (Good Data) - 0.9.8.3-3 - Whoops, forgot to actually apply the patch. * Fri Sep 26 18:00:00 2008 Lubomir Rintel (Good Data) - 0.9.8.3-2 - Fix listing of directories with special characters in names sabayon-2.22.1-1.fc10 --------------------- * Tue Sep 23 18:00:00 2008 Matthias Clasen - 2.22.1-1 - Update to 2.22.1 samba-3.2.4-0.22.fc10 --------------------- * Thu Sep 18 18:00:00 2008 Guenther Deschner - 3.2.4-0.22 - Update to 3.2.4 - resolves: #456889 - move cifs.upcall to /usr/sbin * Wed Aug 27 18:00:00 2008 Guenther Deschner - 3.2.3-0.21 - Security fix for CVE-2008-3789 * Mon Aug 25 18:00:00 2008 Guenther Deschner - 3.2.2-0.20 - Update to 3.2.2 samyak-fonts-1.2.1-1.fc10 ------------------------- * Thu Sep 18 18:00:00 2008 Pravin Satpute 1.2.1-1 - upstream release 1.2.1 - Added Unicode 5.1 support in Samyak-Devanagari sbcl-1.0.20-3.fc10 ------------------ * Mon Sep 22 18:00:00 2008 Anthony Green - 1.0.20-3 - Create missing directories. * Sun Sep 21 18:00:00 2008 Anthony Green - 1.0.20-2 - Add common-lisp-controller bits. scalapack-1.7.5-4.fc10 ---------------------- * Tue Sep 23 18:00:00 2008 Tom "spot" Callaway 1.7.5-4 - incorporate Deji Akingunola's changes (bz 462424) - build against openmpi instead of lam schroedinger-1.0.5-3.fc10 ------------------------- * Fri Sep 12 18:00:00 2008 Jeffrey C. Ollie - 1.0.5-3 - Bump release and rebuild against latest gstreamer-* packages to pick - up special gstreamer codec provides. scim-1.4.7-32.fc10 ------------------ * Fri Sep 19 18:00:00 2008 Huang Peng - 1.4.7-32 - Resolve: bug 462820 by Parag. scim-bridge-0.4.15-7.fc10 ------------------------- * Tue Sep 16 18:00:00 2008 Huang Peng - 0.4.15-7 - Resolves: bug 461373 (Focus switch causes selected text to be deleted) scim-chewing-0.3.1.901-0.fc10 ----------------------------- * Wed Sep 17 18:00:00 2008 Ding-Yi Chen - 0.3.1.901-0 - Upstream update. * Thu May 29 18:00:00 2008 Tom "spot" Callaway 0.3.1-16 - fix license tag scim-skk-0.5.2-11.fc10 ---------------------- * Tue Sep 16 18:00:00 2008 Matt Domsch - 0.5.2-11 - fix FTBFS BZ#434419 * Thu Sep 4 18:00:00 2008 Tom "spot" Callaway - 0.5.2-10 - fix license tag * Tue Feb 19 17:00:00 2008 Fedora Release Engineering - 0.5.2-9 - Autorebuild for GCC 4.3 * Wed Jul 4 18:00:00 2007 Jens Petersen - remove with_libstdc_preview macro seahorse-2.24.0-2.fc10 ---------------------- * Sun Sep 21 18:00:00 2008 Matthias Clasen 2.24.0-2 - Update to 2.24.0 seahorse-plugins-2.24.0-2.fc10 ------------------------------ * Sun Sep 21 18:00:00 2008 Matthias Clasen 2.24.0-2 - Update to 2.24.0 seamonkey-1.1.12-1.fc9 ---------------------- * Thu Sep 25 18:00:00 2008 Christopher Aillon - 1.1.12-1 - Update to 1.1.12 selinux-policy-3.5.9-1.fc10 --------------------------- * Wed Sep 24 18:00:00 2008 Dan Walsh 3.5.9-1 - Upgrade to upstream * Tue Sep 23 18:00:00 2008 Dan Walsh 3.5.8-7 - Allow confined users to login with dbus * Mon Sep 22 18:00:00 2008 Dan Walsh 3.5.8-6 - Fix transition to nsplugin * Mon Sep 22 18:00:00 2008 Dan Walsh 3.5.8-5 - Add file context for /dev/mspblk.* * Sun Sep 21 18:00:00 2008 Dan Walsh 3.5.8-4 - Fix transition to nsplugin ' * Thu Sep 18 18:00:00 2008 Dan Walsh 3.5.8-3 - Fix labeling on new pm*log - Allow ssh to bind to all nodes * Thu Sep 11 18:00:00 2008 Dan Walsh 3.5.8-1 - Merge upstream changes - Add Xavier Toth patches * Wed Sep 10 18:00:00 2008 Dan Walsh 3.5.7-2 - Add qemu_cache_t for /var/cache/libvirt sepostgresql-8.3.3-2.1042.fc10 ------------------------------ setroubleshoot-2.0.11-1.fc10 ---------------------------- * Mon Sep 22 18:00:00 2008 Dan Walsh - 2.0.11-1 - Update to upstream - 2008-10-22 - Fix pruning code - Fix time stamps shadow-utils-4.1.2-8.fc10 ------------------------- * Wed Sep 24 18:00:00 2008 Peter Vrabec 2:4.1.2-8 - groupmems: check username for valid character (#455603) - groupmems: don't segfault on nonexistent group (#456088) * Thu Sep 11 18:00:00 2008 Peter Vrabec 2:4.1.2-7 - fix usermod SELinux user mappings change (#458766) shorewall-4.0.14-1.fc10 ----------------------- * Sun Sep 28 18:00:00 2008 Jonathan G. Underwood - 4.0.14-1 - Update to version 4.0.14 slim-1.3.0-6.fc10 ----------------- * Wed Sep 24 18:00:00 2008 Anders F Bjorklund 1.3.0-6 - fix patch fuzz smart-1.0-55.fc10 ----------------- * Sat Sep 13 18:00:00 2008 Axel Thimm - 1.0-55 - Fix bad smart.pam commit. soprano-2.1.1-1.fc10 -------------------- * Sun Sep 28 18:00:00 2008 Kevin Kofler 2.1.1-1 - update to 2.1.1 sound-juicer-2.24.0-1.fc10 -------------------------- * Sun Sep 21 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 ssmtp-2.61-11.6.fc10.1 ---------------------- * Fri Sep 12 18:00:00 2008 Manuel "lonely wolf" Wolfshant 2.61-11.6.1 - use conditionals to consolidate specs for Fedora and EPEL stellarium-0.10.0-1.fc10 ------------------------ * Wed Sep 24 18:00:00 2008 Jochen Schmitt 0.10.0-1 - New upstream release * Sat Sep 6 18:00:00 2008 Tom "spot" Callaway 0.9.1-7 - fix license tag streamtuner-0.99.99-23.fc10 --------------------------- * Wed Sep 17 18:00:00 2008 Matthias Haase - 0.99.99-23 - shoutcast-base-url patch added to shoutcast patch stunnel-4.26-1 -------------- * Mon Sep 22 18:00:00 2008 Miloslav Trma?? - 4.26-1 - Update to stunnel-4.26. sugar-0.82.9-1.fc10 ------------------- * Thu Sep 25 18:00:00 2008 Marco Pesenti Gritti - 0.82.9-1 - #7969 Accidental searches lead to a "blank" Home screen - #8662 xo man jumps around while zooming - #8642 Bug in WPA key dialog prevents certain passwords from being accepted - #8657 Help activity doesn't show up on a clean install. - #8234 Software update (in Control Panel) crashes X-server. * Sat Sep 20 18:00:00 2008 Marco Pesenti Gritti - 0.82.8-1 - #8554 Indicate connected AP in Neighborhood view. - #7987 Home view XO icon palette for Control Panel has wrong icon - #7685 Alternate home layouts; fixed ring scaling; better modularization of layouts - #8148 control panel does have layout problems with languages like mongolian - #8485 Switching between zoom levels seem to leak * Tue Sep 16 18:00:00 2008 Simon Schampijer - 0.82.7-1 - remove numpy finally * Sat Sep 13 18:00:00 2008 Simon Schampijer - 0.82.6-1 - #8438 control panel fails when run with python -OO - #8470 SpreadLayout leaks self._collisions - #8375 gst usage in the shell wastes 2.6mb - #8372 Remove numpy usage from the shell * Fri Sep 12 18:00:00 2008 Marco Pesenti Gritti - 0.82.5-1 - #8427 Sugar does not send SetActive(True) - #8409 Sugar does not save network's BSSIDs in networks.cfg sugar-artwork-0.82.3-1.fc10 --------------------------- * Tue Sep 23 18:00:00 2008 Simon Schampijer - 0.82.3-1 - Fix corrupted network-wireless-060.svg * Sat Sep 20 18:00:00 2008 Marco Pesenti Gritti - 0.82.2-1 - #7685 Alternate home layouts; fixed ring scaling; better modularization of layouts - #8554 Indicate connected AP in Neighborhood view. - #8198 Use a plainer "wrench" for the Settings icon - #7987 Home view XO icon palette for Control Panel has wrong icon sugar-toolkit-0.82.11-1.fc10 ---------------------------- * Wed Sep 24 18:00:00 2008 Marco Pesenti Gritti - 0.82.11-1 - #8626 Icons overlap unnecessarily in crowded neighborhood view. * Sat Sep 20 18:00:00 2008 Marco Pesenti Gritti - 0.82.10-1 - #8532 SIGCHLD fights with threads. - #8485 Switching between zoom levels seem to leak * Tue Sep 16 18:00:00 2008 Marco Pesenti Gritti - 0.82.8-2 - Fix a crash when we cannot access the alsa device * Sat Sep 13 18:00:00 2008 Simon Schampijer - 0.82.7-1 - #8375 gst usage in the shell wastes 2.6mb - #8394 sugar shell leaks presence service info - #8469 palette.menu is leaked sunbird-0.9-2.fc10 ------------------ * Wed Sep 24 18:00:00 2008 Lubomir Rintel 0.9-2 - Fix problem with symbol visibility and newer gcc I introduced with libical patch * Tue Sep 23 18:00:00 2008 Lubomir Rintel 0.9-1 - 0.9 GOLD - Fix use of system nss and nspr4 - Link against system libical (#459923) - Add language packs for lightning (#449770) sysklogd-1.5-2.fc10 ------------------- * Fri Aug 8 18:00:00 2008 Jeroen van Meeuwen 1.5-2 - Remove more -devel (#313090) * Fri Jun 6 18:00:00 2008 Jeroen van Meeuwen 1.5-1 - New upstream version syslog-ng-2.0.8-3.fc10 ---------------------- * Mon Sep 15 18:00:00 2008 Peter Vrabec 2.0.8-3 - do not conflicts with rsyslog, both rsyslog and syslog-ng use same pidfile and logrotate file (#441664) sysstat-8.0.4-5.fc10 -------------------- * Mon Sep 22 18:00:00 2008 Ivana Varekova - 8.0.4-5 - Resolves: #463066 - Fix Patch0:/%patch mismatch system-config-bind-4.0.11-2.fc10 -------------------------------- * Mon Sep 22 18:00:00 2008 Jaroslav Reznik - 4.0.11-2 - Fixes modal dialog refuses to die (rhbz#462847) * Tue Sep 16 18:00:00 2008 Jaroslav Reznik - 4.0.11-1 - Missing translations * Mon Sep 15 18:00:00 2008 Jaroslav Reznik - 4.0.10-1 - Fixes listen-on ACL bug (rhbz#449046) - Repackage with new translations system-config-firewall-1.2.11-1.fc10 ------------------------------------ * Fri Sep 19 18:00:00 2008 Thomas Woerner 1.2.11-1 - use dialogs for parser errors in tui (rhbz#457485) - enable to add protocol specific (IPv4, IPv6) icmp types for ICMP filtering - updated translations for he, ja, ko and zh_CN system-config-language-1.3.2-1.fc10 ----------------------------------- * Wed Sep 17 18:00:00 2008 Pravin Satpute - 1.3.2-1 - upstream realease 1.3.2 - fix bug 444568, 462439 tachyon-0.98-0.7.20070319.fc10 ------------------------------ * Fri Sep 26 18:00:00 2008 Dominik 'Rathann' Mierzejewski 0.98-0.7.20070319 - fix build with new lam package - use generic BR for libGLU-devel - move tree cleanup to %prep to fix short-circuit builds tanukiwrapper-3.2.3-2.3.fc10 ---------------------------- * Wed Sep 24 18:00:00 2008 Deepak Bhole 3.2.3-2.3 - Update nosun-jvm-64.patch to remove fuzz telepathy-glib-0.7.16-1.fc10 ---------------------------- * Fri Sep 26 18:00:00 2008 Brian Pepple - 0.7.16-1 - Update to 0.7.16. * Fri Sep 19 18:00:00 2008 Brian Pepple - 0.7.15-1 - Update to 0.7.15. - Bump min version of glib needed. - Update broken-pkgconfig patch. telepathy-haze-0.2.1-1.fc10 --------------------------- * Fri Sep 12 18:00:00 2008 Peter Gordon - 0.2.1-1 - Update to new upstream release (0.2.1) telepathy-mission-control-4.67-1.fc10 ------------------------------------- * Sat Sep 27 18:00:00 2008 Brian Pepple - 4.67-1 - Update to 4.67. * Fri Sep 26 18:00:00 2008 Brian Pepple - 4.65-3 - Enable gnome-keyring support. telepathy-salut-0.3.5-1.fc10 ---------------------------- * Wed Sep 17 18:00:00 2008 Brian Pepple - 0.3.5-1 - Update to 0.3.5. telepathy-stream-engine-0.5.3-2.fc10 ------------------------------------ * Fri Sep 19 18:00:00 2008 Brian Pepple - 0.5.3-2 - rebuilt for new libjingle. tellico-1.3.4-1.fc10 -------------------- * Thu Sep 18 18:00:00 2008 Jos?? Matos - 1.3.4-1 - update to 1.3.4 thttpd-2.25b-17.fc10 -------------------- * Thu Sep 25 18:00:00 2008 Matthias Saou 2.25b-17 - Update patches to remove fuzz. thunderbird-2.0.0.16-1.fc10 --------------------------- * Wed Jul 23 18:00:00 2008 Christopher Aillon 2.0.0.16-1 - Update to 2.0.0.16 tig-0.12-1.fc10 --------------- * Sat Sep 27 18:00:00 2008 Todd Zullinger 0.12-1 - tig-0.12 tinyerp-4.2.3.3-1.fc10 ---------------------- * Tue Sep 16 18:00:00 2008 Dan Horak 4.2.3.3-1 - update to upstream version 4.2.3.3 tomboy-0.12.0-1.fc10 -------------------- * Tue Sep 23 18:00:00 2008 Matthias Clasen - 0.12.0-1 - Update to 0.12.0 tomcat-native-1.1.15-1.fc9 -------------------------- * Thu Sep 11 18:00:00 2008 Ville Skytt?? - 1.1.15-1 - 1.1.15. totem-2.24.0-1.fc10 ------------------- * Sun Sep 21 18:00:00 2008 - Bastien Nocera - 2.24.0-1 - Update to 2.24.0 totem-pl-parser-2.24.0-1.fc10 ----------------------------- * Sun Sep 21 18:00:00 2008 - Bastien Nocera - 2.24.0-1 - Update to 2.24.0 trac-bazaar-plugin-0.2-7.20080925bzr49.fc10 ------------------------------------------- * Fri Sep 26 18:00:00 2008 Toshio Kuratomi - 0.2-7.20080925bzr49 - Patches to fix: lp:274609, lp:263300, lp:267700 * Thu Sep 25 18:00:00 2008 Toshio Kuratomi - 0.2-6.20080925bzr49 - New upstream snapshot that includes our patches, fixes for bzr-1.6+ and trac-0.11. traceroute-2.0.12-1.fc10 ------------------------ * Wed Sep 17 18:00:00 2008 Dmitry Butskoy - 3:2.0.12-1 - update to 2.0.12 (fixes #461278 and #461626) - this release adds support for icmp extensions (including MPLS), which was expected for a long time (#176588) - drop "tracert" symlink (#461109) transmission-1.34-1.fc10 ------------------------ * Sun Sep 28 18:00:00 2008 Denis Leroy - 1.34-1 - Update to upstream 1.34 - Added patch to link with distributed libevent library trustyrc-0.1.2-1.fc10 --------------------- * Sun Sep 28 18:00:00 2008 Nicoleau Fabien 0.1.2-1 - rebuild for 0.1.2 tuxtype2-1.5.17-1.fc10 ---------------------- * Mon Sep 15 18:00:00 2008 Tom "spot" Callaway - 1.5.17-1 - update to 1.5.17 (incorporate Jonathan Dieter's changes) tzclock-2.7.2-1.fc10 -------------------- * Thu Sep 25 18:00:00 2008 Mamoru Tasaka - 2.7.2-1 - 2.7.2 tzdata-2008f-1.fc10 ------------------- * Tue Sep 16 18:00:00 2008 Petr Machata - 2008f-1 - Upstream 2008f - Changes for Mauritius (extends DST to years to come) - Palestine changes clocks for the duration of Ramadan - Argentina will start DST on Sunday October 19, 2008 - Brazil will start DST on 2008-10-19 - Drop Pakistan and Morocco patches udns-0.0.9-3.fc10 ----------------- * Sun Sep 14 18:00:00 2008 Adrian Reber - 0.0.9-3 - removed rblcheck binary to resolve conflict with package rblcheck udunits-1.12.9-2.fc10 --------------------- * Fri Sep 12 18:00:00 2008 Tom "spot" Callaway - 1.12.9-2 - missing BR: byacc * Fri Sep 12 18:00:00 2008 Tom "spot" Callaway - 1.12.9-1 - update to 1.12.9 vdr-sudoku-0.3.2-1.fc10 ----------------------- * Sun Sep 28 18:00:00 2008 Ville Skytt?? - 0.3.2-1 - 0.3.2. viewvc-1.0.6-1.fc10 ------------------- * Fri Sep 19 18:00:00 2008 Bojan Smojver - 1.0.6-1 - Bump up to 1.0.6 vinagre-2.24.0-1.fc10 --------------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 vino-2.24.0-1.fc10 ------------------ * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 vte-0.17.4-1.fc10 ----------------- * Mon Sep 22 18:00:00 2008 Matthias Clasen - 0.17.4-1 - Update to 0.17.4 vtk-5.0.4-24.fc9 ---------------- * Mon Aug 25 18:00:00 2008 Axel Thimm - 5.0.4-24 - Change java build dependencies from java-devel to gcj. * Sun Aug 24 18:00:00 2008 Axel Thimm - 5.0.4-23 - %check || : does not work anymore. - enable java by default. * Wed May 21 18:00:00 2008 Tom "spot" Callaway - 5.0.4-22 - fix license tag wesnoth-1.4.5-1.fc10 -------------------- * Tue Sep 9 18:00:00 2008 Jon Ciesla - 1.4.5-1 - New upstream release. wine-1.1.5-1.fc10 ----------------- * Sat Sep 20 18:00:00 2008 Andreas Bierfert - 1.1.5-1 - version upgrade * Fri Sep 5 18:00:00 2008 Andreas Bierfert - 1.1.4-1 - version upgrade - drop wine-prefixfonts.patch (#460745) * Fri Aug 29 18:00:00 2008 Andreas Bierfert - 1.1.3-1 - version upgrade wmctrl-1.07-5.fc10 ------------------ * Sun Sep 28 18:00:00 2008 Patrice Dumas - 1.07-5 - apply debian patcheset, to fix #426383 ws-commons-util-1.0.1-10.fc10 ----------------------------- * Fri Sep 12 18:00:00 2008 Andrew Overholt 1.0.1-9 - Add ppc64. * Fri Sep 12 18:00:00 2008 Andrew Overholt 1.0.1-10 - Bump so I can chain-build with xmlrpc3. wxGTK-2.8.9-1.fc10 ------------------ * Mon Sep 22 18:00:00 2008 Dan Horak - 2.8.9-1 - update to 2.8.9 xbae-4.60.4-10.fc10 ------------------- * Sat Sep 20 18:00:00 2008 Patrice Dumas 4.60.4-10 - use %patch0 instead of %patch (#463002) xchat-gnome-0.24.0-1.fc10 ------------------------- * Tue Sep 23 18:00:00 2008 Brian Pepple - 0.24.0-1 - Update to 0.24.0. - Drop deps patch. Fixed upstream. xenner-0.46-1.fc10 ------------------ * Fri Sep 26 18:00:00 2008 Gerd Hoffmann - 0.46-1.fc10 - update to version 0.46 * Wed Sep 24 18:00:00 2008 Gerd Hoffmann - 0.45-1.fc10 - update to version 0.45 xenwatch-0.5.3-1.fc10 --------------------- * Tue Sep 23 18:00:00 2008 Gerd Hoffmann - 0.5.3-1 - update to 0.5.3. xinetd-2.3.14-21.fc10 --------------------- * Thu Sep 18 18:00:00 2008 Jan Safranek - 2:2.3.14-21 - fix glitches found during package review (#226560) - make all files in .debuginfo package readable by everyone xkeyboard-config-1.3-2.fc10 --------------------------- * Mon Sep 29 18:00:00 2008 Peter Hutterer - 1.3-2 - xkeyboard-config-1.3-AC11-mapping-is.patch: fix AC11 mapping for icelandic keyboard layout (#241564) xlog-1.8.1-1.fc10 ----------------- * Mon Sep 22 18:00:00 2008 Lucian Langa - 1.8.1-1 - new upstream versuion - change category to HamRadio * Fri Aug 29 18:00:00 2008 Michael Schwendt - 1.7-4 - include /usr/share/xlog xml-commons-apis-1.3.04-1.3.fc10 -------------------------------- * Fri Sep 19 18:00:00 2008 Matt Wringe - 0:1.3.04-1.3 - Remove natively compiled bits from the javadoc package (462809) xmlrpc3-3.0-2.7.fc10 -------------------- * Fri Sep 12 18:00:00 2008 Andrew Overholt 3.0-2.7 - Add ppc64. xmoto-0.4.2-2.fc10 ------------------ * Fri Sep 12 18:00:00 2008 Jon Ciesla 0.4.2-2 - Introducted patch fuzz workaround, will fix. xorg-x11-drv-ati-6.9.0-18.fc10 ------------------------------ * Sat Sep 27 18:00:00 2008 Dave Airlie 6.9.0-18 - fix fb contents patch - EXA speedup from otaylor. * Fri Sep 26 18:00:00 2008 Dave Airlie 6.9.0-17 - exa offset fixes for changes in X server * Fri Sep 26 18:00:00 2008 Dave Airlie 6.9.0-16 - rebase to a later tree - still not fully up to git master - add some fixes to the resize stuff - not fully done * Fri Sep 19 18:00:00 2008 Kristian H??gsberg - 6.9.0-15 - Add copy-fb-contents.patch to initialize the root window contents with the fbdev contents for slick startup. xorg-x11-drv-radeonhd-1.2.1-3.9.20080917git.fc10 ------------------------------------------------ * Wed Sep 17 18:00:00 2008 Hans Ulrich Niedermann - 1.2.1-3.9.20080917git - Fix build on rawhide/F10 by defining cpp macros __user and DEPRECATED - New snapshot (upstream commit 07408e8518e4e19663c109ea8ad765686ea4e01e): - 07408e85: AtomBIOS: Fail driver instance if AtomBIOS mode setting is requested but no BIOS image found. * Sat Sep 6 18:00:00 2008 Hans Ulrich Niedermann - 1.2.1-3.8.20080906git - New snapshot (upstream commit f1c6cc865d8d0703478c3eedea2e706e911f9965): Upstream has merged their QnD and AtomBIOS branches to master a few weeks time ago, so there are way too many changes to list here. xorg-x11-drv-synaptics-0.15.2-1.fc10 ------------------------------------ * Wed Sep 17 18:00:00 2008 Peter Hutterer 0.15.2-1 - update to 0.15.2 - remove patches merged upstream. - xf86-input-synaptics-0.15.2-maxtapmove.patch: scale MaxTapMove parameter depending on touchpad height #462211 xorg-x11-server-1.5.1-2.fc10 ---------------------------- * Thu Sep 25 18:00:00 2008 Dave Airlie 1.5.1-2 - fix crash with x11perf on r500 modesetting * Tue Sep 23 18:00:00 2008 Adam Jackson 1.5.1-1 - xserver 1.5.1 - Trim %changelog. xterm-237-1.fc10 ---------------- * Tue Sep 16 18:00:00 2008 Miroslav Lichvar 237-1 - update to 237 xulrunner-1.9.0.2-2.fc10 ------------------------ * Thu Sep 25 18:00:00 2008 Martin Stransky 1.9.0.2-2 - Build with system cairo (#463341) * Tue Sep 23 18:00:00 2008 Christopher Aillon 1.9.0.2-1 - Update to 1.9.0.2 yelp-2.24.0-2.fc10 ------------------ * Wed Sep 24 18:00:00 2008 Christopher Aillon - 2.24.0-2 - Rebuild against newer gecko * Mon Sep 22 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update ot 2.24.0 yoltia-0.22.1-3.fc10 -------------------- * Tue Sep 16 18:00:00 2008 Tom "spot" Callaway - 0.22.1-3 - adjust BR to qt3-devel ypserv-2.19-10.fc10 ------------------- * Thu Sep 25 18:00:00 2008 Vitezslav Crhonek - 2.19-10 - Rediff all patches to work with patch --fuzz=0 yum-utils-1.1.17-1.fc10 ----------------------- * Wed Sep 17 18:00:00 2008 Tim Lauridsen - mark as 1.1.17 zenity-2.24.0-1.fc10 -------------------- * Tue Sep 23 18:00:00 2008 Matthias Clasen - 2.24.0-1 - Update to 2.24.0 Summary: Added Packages: 73 Removed Packages: 3 Modified Packages: 633 Broken deps for i386 ---------------------------------------------------------- ant-manual-1.7.1-7.1.fc10.i386 requires perl(the) beagle-evolution-0.3.8-6.fc10.i386 requires mono(evolution-sharp) = 0:3.0.0.0 crystalspace-1.2-7.fc10.i386 requires libode.so.0 epiphany-extensions-2.23.91-1.fc10.i386 requires gecko-libs = 0:1.9.0.1 gtkmozembedmm-1.4.2.cvs20060817-21.fc10.i386 requires gecko-libs = 0:1.9.0.1 kipi-plugins-0.2.0-0.1.beta1.fc10.i386 requires libkexiv2.so.6 kipi-plugins-0.2.0-0.1.beta1.fc10.i386 requires libkdcraw.so.5 kphotoalbum-3.2-0.1.20080802svn.fc10.i386 requires libkdcraw.so.5 lvm2-cluster-2.02.39-3.fc10.i386 requires libcman.so.2 lvm2-cluster-2.02.39-3.fc10.i386 requires libdlm.so.2 machineball-1.0-5.fc9.i386 requires libode.so.0 mozvoikko-0.9.5-2.fc10.i386 requires gecko-libs = 0:1.9.0.1 ppl-swiprolog-0.9-24.fc10.i386 requires libpl.so.5.6.57 pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0 python-pyblock-0.31-4.i386 requires libdmraid.so.1.0.0.rc14 python-pyblock-0.31-4.i386 requires libdmraid.so.1.0.0.rc14(Base) pytrainer-1.6.0.5-2.fc10.noarch requires xulrunner = 0:1.9.0.1 raydium-1.2-9.fc10.i386 requires libode.so.0 rcssserver3d-0.6-4.fc10.i386 requires libode.so.0 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so sepostgresql-8.3.3-2.1042.fc10.i386 requires postgresql-server = 0:8.3.3 stormbaancoureur-2.1.4-1.fc10.i386 requires libode.so.0 xmoto-0.4.2-2.fc10.i386 requires libode.so.0 Broken deps for x86_64 ---------------------------------------------------------- ant-manual-1.7.1-7.1.fc10.x86_64 requires perl(the) beagle-evolution-0.3.8-6.fc10.x86_64 requires mono(evolution-sharp) = 0:3.0.0.0 crystalspace-1.2-7.fc10.i386 requires libode.so.0 crystalspace-1.2-7.fc10.x86_64 requires libode.so.0()(64bit) epiphany-extensions-2.23.91-1.fc10.x86_64 requires gecko-libs = 0:1.9.0.1 gtkmozembedmm-1.4.2.cvs20060817-21.fc10.i386 requires gecko-libs = 0:1.9.0.1 gtkmozembedmm-1.4.2.cvs20060817-21.fc10.x86_64 requires gecko-libs = 0:1.9.0.1 kipi-plugins-0.2.0-0.1.beta1.fc10.i386 requires libkexiv2.so.6 kipi-plugins-0.2.0-0.1.beta1.fc10.i386 requires libkdcraw.so.5 kipi-plugins-0.2.0-0.1.beta1.fc10.x86_64 requires libkexiv2.so.6()(64bit) kipi-plugins-0.2.0-0.1.beta1.fc10.x86_64 requires libkdcraw.so.5()(64bit) kphotoalbum-3.2-0.1.20080802svn.fc10.x86_64 requires libkdcraw.so.5()(64bit) lvm2-cluster-2.02.39-3.fc10.x86_64 requires libcman.so.2()(64bit) lvm2-cluster-2.02.39-3.fc10.x86_64 requires libdlm.so.2()(64bit) machineball-1.0-5.fc9.x86_64 requires libode.so.0()(64bit) mozvoikko-0.9.5-2.fc10.x86_64 requires gecko-libs = 0:1.9.0.1 ppl-swiprolog-0.9-24.fc10.x86_64 requires libpl.so.5.6.57()(64bit) pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) python-pyblock-0.31-4.x86_64 requires libdmraid.so.1.0.0.rc14(Base)(64bit) python-pyblock-0.31-4.x86_64 requires libdmraid.so.1.0.0.rc14()(64bit) pytrainer-1.6.0.5-2.fc10.noarch requires xulrunner = 0:1.9.0.1 raydium-1.2-9.fc10.i386 requires libode.so.0 raydium-1.2-9.fc10.x86_64 requires libode.so.0()(64bit) rcssserver3d-0.6-4.fc10.i386 requires libode.so.0 rcssserver3d-0.6-4.fc10.x86_64 requires libode.so.0()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) sepostgresql-8.3.3-2.1042.fc10.x86_64 requires postgresql-server = 0:8.3.3 stormbaancoureur-2.1.4-1.fc10.x86_64 requires libode.so.0()(64bit) xmoto-0.4.2-2.fc10.x86_64 requires libode.so.0()(64bit) Broken deps for ppc ---------------------------------------------------------- ant-manual-1.7.1-7.1.fc10.ppc requires perl(the) beagle-evolution-0.3.8-6.fc10.ppc requires mono(evolution-sharp) = 0:3.0.0.0 crystalspace-1.2-7.fc10.ppc requires libode.so.0 epiphany-extensions-2.23.91-1.fc10.ppc requires gecko-libs = 0:1.9.0.1 gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc requires gecko-libs = 0:1.9.0.1 gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc64 requires gecko-libs = 0:1.9.0.1 kipi-plugins-0.2.0-0.1.beta1.fc10.ppc requires libkexiv2.so.6 kipi-plugins-0.2.0-0.1.beta1.fc10.ppc requires libkdcraw.so.5 kipi-plugins-0.2.0-0.1.beta1.fc10.ppc64 requires libkexiv2.so.6()(64bit) kipi-plugins-0.2.0-0.1.beta1.fc10.ppc64 requires libkdcraw.so.5()(64bit) kphotoalbum-3.2-0.1.20080802svn.fc10.ppc requires libkdcraw.so.5 lvm2-cluster-2.02.39-3.fc10.ppc requires libcman.so.2 lvm2-cluster-2.02.39-3.fc10.ppc requires libdlm.so.2 machineball-1.0-5.fc9.ppc requires libode.so.0 mozvoikko-0.9.5-2.fc10.ppc requires gecko-libs = 0:1.9.0.1 ppl-swiprolog-0.9-24.fc10.ppc requires libpl.so.5.6.57 pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0 python-pyblock-0.31-4.ppc requires libdmraid.so.1.0.0.rc14 python-pyblock-0.31-4.ppc requires libdmraid.so.1.0.0.rc14(Base) pytrainer-1.6.0.5-2.fc10.noarch requires xulrunner = 0:1.9.0.1 raydium-1.2-9.fc10.ppc requires libode.so.0 raydium-1.2-9.fc10.ppc64 requires libode.so.0()(64bit) rcssserver3d-0.6-4.fc10.ppc requires libode.so.0 rcssserver3d-0.6-4.fc10.ppc64 requires libode.so.0()(64bit) ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so sepostgresql-8.3.3-2.1042.fc10.ppc requires postgresql-server = 0:8.3.3 stapitrace-1.0.0-12.20080622cvs_alpha.fc10.ppc requires libopcodes-2.18.50.0.9-1.fc10.so stapitrace-1.0.0-12.20080622cvs_alpha.fc10.ppc requires libbfd-2.18.50.0.9-1.fc10.so stormbaancoureur-2.1.4-1.fc10.ppc requires libode.so.0 xmoto-0.4.2-2.fc10.ppc requires libode.so.0 Broken deps for ppc64 ---------------------------------------------------------- ant-manual-1.7.1-7.1.fc10.ppc64 requires perl(the) crystalspace-1.2-7.fc10.ppc64 requires libode.so.0()(64bit) epiphany-extensions-2.23.91-1.fc10.ppc64 requires gecko-libs = 0:1.9.0.1 gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc64 requires gecko-libs = 0:1.9.0.1 kipi-plugins-0.2.0-0.1.beta1.fc10.ppc64 requires libkexiv2.so.6()(64bit) kipi-plugins-0.2.0-0.1.beta1.fc10.ppc64 requires libkdcraw.so.5()(64bit) kphotoalbum-3.2-0.1.20080802svn.fc10.ppc64 requires libkdcraw.so.5()(64bit) livecd-tools-018-1.fc10.ppc64 requires yaboot lvm2-cluster-2.02.39-3.fc10.ppc64 requires libcman.so.2()(64bit) lvm2-cluster-2.02.39-3.fc10.ppc64 requires libdlm.so.2()(64bit) machineball-1.0-5.fc9.ppc64 requires libode.so.0()(64bit) mozvoikko-0.9.5-2.fc10.ppc64 requires gecko-libs = 0:1.9.0.1 ppl-swiprolog-0.9-24.fc10.ppc64 requires libpl.so.5.6.57()(64bit) pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) python-pyblock-0.31-4.ppc64 requires libdmraid.so.1.0.0.rc14(Base)(64bit) python-pyblock-0.31-4.ppc64 requires libdmraid.so.1.0.0.rc14()(64bit) pytrainer-1.6.0.5-2.fc10.noarch requires xulrunner = 0:1.9.0.1 raydium-1.2-9.fc10.ppc64 requires libode.so.0()(64bit) rcssserver3d-0.6-4.fc10.ppc64 requires libode.so.0()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) sepostgresql-8.3.3-2.1042.fc10.ppc64 requires postgresql-server = 0:8.3.3 stormbaancoureur-2.1.4-1.fc10.ppc64 requires libode.so.0()(64bit) xmoto-0.4.2-2.fc10.ppc64 requires libode.so.0()(64bit) From tcallawa at redhat.com Mon Sep 29 13:58:29 2008 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 29 Sep 2008 09:58:29 -0400 Subject: PackageKit-gstreamer-plugin replacing codeina In-Reply-To: <1222683978.3385.22.camel@hughsie-laptop> References: <1222683978.3385.22.camel@hughsie-laptop> Message-ID: <1222696709.4087.9.camel@localhost.localdomain> On Mon, 2008-09-29 at 11:26 +0100, Richard Hughes wrote: > So what I'm really asking is, do we really want people to be able to: > > 1. use codeina in F10 > 2. install PackageKit-gstreamer-plugin and codeina at the same time I think the idea is to retire codeina in F10, and IMHO, it is what we should do. ~spot From mike at miketc.net Mon Sep 29 13:29:43 2008 From: mike at miketc.net (Mike Chambers) Date: Mon, 29 Sep 2008 08:29:43 -0500 Subject: rawhide report: 20080929 changes In-Reply-To: <20080929122731.3983E1F825C@releng2.fedora.phx.redhat.com> References: <20080929122731.3983E1F825C@releng2.fedora.phx.redhat.com> Message-ID: <1222694983.24172.3.camel@scrappy.miketc.net> On Mon, 2008-09-29 at 12:27 +0000, Rawhide Report wrote: > evolution-2.24.0-2.fc10 > ----------------------- > * Thu Sep 25 18:00:00 2008 Matthew Barnes - 2.24.0-2.fc10 > - Strip unneeded translations from .mo files (RH bug #463887). > - Split Perl-based utilities into a "perl" subpackage (RH bug #462345). > > * Mon Sep 22 18:00:00 2008 Matthew Barnes - 2.24.0-1.fc10 > - Update to 2.24.0 > > > evolution-brutus-1.2.27-1.fc10 > ------------------------------ > * Sun Sep 21 18:00:00 2008 Alex Lancaster - 1.2.27-1 > - Update to 1.2.27 > > * Thu Sep 11 18:00:00 2008 Jesse Keating - 1.2.17-2 > - Rebuild for broken deps. > > > evolution-data-server-2.24.0-1.fc10 > ----------------------------------- > * Mon Sep 22 18:00:00 2008 Matthew Barnes - 2.24.0-1.fc10 > - Update to 2.24.0 > > > evolution-exchange-2.24.0-1.fc10 > -------------------------------- > * Mon Sep 22 18:00:00 2008 Matthew Barnes - 2.24.0-1.fc10 > - Update to 2.24.0 > > * Thu Sep 18 18:00:00 2008 Matthew Barnes - 2.23.92-2.fc10 > - Fix unowned directories (RH bug #462346). > > > evolution-rss-0.1.1-3.fc10 > -------------------------- > * Sat Sep 27 18:00:00 2008 Lucian Langa - 0.1.1-3 > - new upstream snapshot for 0.1.1 > > > evolution-sharp-0.18.0-1.fc10 > ----------------------------- > * Thu Sep 25 18:00:00 2008 Matthew Barnes - 0.18.0-1.fc10 > - Update to 0.18.0 > > * Wed Sep 10 18:00:00 2008 Matthew Barnes - 0.17.5-1.fc10 > - Update to 0.17.5 Any chance any of the evolution packages have a fix or the bogofilter error? When evolution-bogofilter is installed, checking for junk mail gets failures until I can delete it. Didn't get them in F9 nor with it uninstalled. Any chance this is known already or do I need to file a bug? -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From bpepple at fedoraproject.org Mon Sep 29 14:49:09 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Mon, 29 Sep 2008 10:49:09 -0400 Subject: PackageKit-gstreamer-plugin replacing codeina In-Reply-To: <1222683978.3385.22.camel@hughsie-laptop> References: <1222683978.3385.22.camel@hughsie-laptop> Message-ID: <1222699749.1004.2.camel@kennedy> On Mon, 2008-09-29 at 11:26 +0100, Richard Hughes wrote: > > So what I'm really asking is, do we really want people to be able to: > > 1. use codeina in F10 > 2. install PackageKit-gstreamer-plugin and codeina at the same time > > Advice welcome. I believe the plan is that Codeina will be retired once the GStreamer dependencies in RPM/PackageKit work was finished. Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jarod at redhat.com Mon Sep 29 15:32:28 2008 From: jarod at redhat.com (Jarod Wilson) Date: Mon, 29 Sep 2008 11:32:28 -0400 Subject: PackageKit-gstreamer-plugin replacing codeina In-Reply-To: <1222683978.3385.22.camel@hughsie-laptop> References: <1222683978.3385.22.camel@hughsie-laptop> Message-ID: <48E0F50C.8050607@redhat.com> Richard Hughes wrote: > When I build the new version of PackageKit today, it will have a new > subpackage, PackageKit-gstreamer-plugin. > > This provides the optional binary /usr/libexec/pk-gstreamer-install > which is symlinked to gst-install-plugins-helper. > > This means we get UI like this > http://packagekit.org/img/gpk-client-codecs.png rather than being > prompted to pay for codecs using codeina. > > Should I just add: > > Obsoletes: codeina < 0.10.1-8 > Provides: codeina = 0.10.1-8 > > to the gstreamer-plugin part of the spec file and be done away with > codeina? This would allow people to remove PackageKit-gstreamer-plugin > and install codeina if they really wanted, but by default we get the > "right" thing installed for the release. > > Also, we can't do an "everything" install, as both packages provide the > gst-install-plugins-helper file. One option might be for the gstreamer > package to install a bash script gst-install-plugins-helper, which > directs to either codeina, or PackageKit. > > So what I'm really asking is, do we really want people to be able to: > > 1. use codeina in F10 > 2. install PackageKit-gstreamer-plugin and codeina at the same time > > Advice welcome. I have one minor concern here. Currently, codeina gives users a pointer to a location where they can get codecs from, in the case where they aren't supported within the Fedora repositories. While pointing people to Fluendo to buy codec packs isn't exactly the greatest feature to preserve, we at least offer a solution to folks following a clean install. So far as I can tell, this PK solution does nothing for the user if they haven't already configured a 3rd-party repository where the necessary codec might be available. *I* know where to find that stuff and make this solution work as expected, but a new user might not, meaning the search would fail, and they'd think there's no way to play back their WMV crapola, complain loudly, etc., so this would be something of a regression from F9, IMO. Of course, if there's actually something in there that says "hey, you need to set up a 3rd-party repo and/or you can get codecs from Fluendo", then no problem. -- Jarod Wilson jarod at redhat.com From skvidal at fedoraproject.org Mon Sep 29 15:35:08 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 29 Sep 2008 11:35:08 -0400 Subject: PackageKit-gstreamer-plugin replacing codeina In-Reply-To: <48E0F50C.8050607@redhat.com> References: <1222683978.3385.22.camel@hughsie-laptop> <48E0F50C.8050607@redhat.com> Message-ID: <1222702508.20082.55.camel@rosebud> On Mon, 2008-09-29 at 11:32 -0400, Jarod Wilson wrote: > I have one minor concern here. Currently, codeina gives users a pointer to a > location where they can get codecs from, in the case where they aren't > supported within the Fedora repositories. While pointing people to Fluendo to > buy codec packs isn't exactly the greatest feature to preserve, we at least > offer a solution to folks following a clean install. So far as I can tell, > this PK solution does nothing for the user if they haven't already configured > a 3rd-party repository where the necessary codec might be available. *I* know > where to find that stuff and make this solution work as expected, but a new > user might not, meaning the search would fail, and they'd think there's no way > to play back their WMV crapola, complain loudly, etc., so this would be > something of a regression from F9, IMO. Of course, if there's actually > something in there that says "hey, you need to set up a 3rd-party repo and/or > you can get codecs from Fluendo", then no problem. > Which is, in fact, the whole point. Codeina meant that fedora was endorsing and encouraging the software fluendo offered. That was the problem, imo. -sv -- I only speak for me. From hughsient at gmail.com Mon Sep 29 15:36:46 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 29 Sep 2008 16:36:46 +0100 Subject: PackageKit-gstreamer-plugin replacing codeina In-Reply-To: <48E0F50C.8050607@redhat.com> References: <1222683978.3385.22.camel@hughsie-laptop> <48E0F50C.8050607@redhat.com> Message-ID: <1222702606.3953.14.camel@hughsie-laptop> On Mon, 2008-09-29 at 11:32 -0400, Jarod Wilson wrote: > "hey, you need to set up a 3rd-party repo and/or > you can get codecs from Fluendo", then no problem. No, there's not, but that's a good idea. What about something like: ---- No plugins were found to play back this media type: You may need to enable or set up a 3rd party software source to find these plugins. You can buy media plugins from "Fluendo Codec Store" but these will not be supported by your vendor. ---- The Fluendo Codec Store link could be just disabled in gconf, or patched out by free software distros. Richard. From jspaleta at gmail.com Mon Sep 29 15:53:32 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 29 Sep 2008 07:53:32 -0800 Subject: PackageKit-gstreamer-plugin replacing codeina In-Reply-To: <1222702606.3953.14.camel@hughsie-laptop> References: <1222683978.3385.22.camel@hughsie-laptop> <48E0F50C.8050607@redhat.com> <1222702606.3953.14.camel@hughsie-laptop> Message-ID: <604aa7910809290853s298d4d98n203f82dce5417fac@mail.gmail.com> On Mon, Sep 29, 2008 at 7:36 AM, Richard Hughes wrote: > No, there's not, but that's a good idea. What about something like: > The Fluendo Codec Store link could be just disabled in gconf, or patched > out by free software distros. And other distros might have their own storefronts for codecs, with alternative pricing. You probably do not want to hardcode a specific vendor location as a preferred vendor in PackageKit itself. -jef From bnocera at redhat.com Mon Sep 29 16:00:36 2008 From: bnocera at redhat.com (Bastien Nocera) Date: Mon, 29 Sep 2008 17:00:36 +0100 Subject: PackageKit-gstreamer-plugin replacing codeina In-Reply-To: <1222702606.3953.14.camel@hughsie-laptop> References: <1222683978.3385.22.camel@hughsie-laptop> <48E0F50C.8050607@redhat.com> <1222702606.3953.14.camel@hughsie-laptop> Message-ID: <1222704036.3311.82.camel@cookie.hadess.net> On Mon, 2008-09-29 at 16:36 +0100, Richard Hughes wrote: > On Mon, 2008-09-29 at 11:32 -0400, Jarod Wilson wrote: > > "hey, you need to set up a 3rd-party repo and/or > > you can get codecs from Fluendo", then no problem. > > No, there's not, but that's a good idea. What about something like: > > ---- > > No plugins were found to play back this media type: > > You may need to enable or set up a 3rd party software source to find > these plugins. > > You can buy media plugins from "Fluendo Codec Store" but these will not > be supported by your vendor. > > ---- > > The Fluendo Codec Store link could be just disabled in gconf, or patched > out by free software distros. I'd rather it didn't appear at all. People can swap out the helpers if they want. From jarod at redhat.com Mon Sep 29 16:30:20 2008 From: jarod at redhat.com (Jarod Wilson) Date: Mon, 29 Sep 2008 12:30:20 -0400 Subject: PackageKit-gstreamer-plugin replacing codeina In-Reply-To: <1222702508.20082.55.camel@rosebud> References: <1222683978.3385.22.camel@hughsie-laptop> <48E0F50C.8050607@redhat.com> <1222702508.20082.55.camel@rosebud> Message-ID: <48E1029C.1040709@redhat.com> seth vidal wrote: > On Mon, 2008-09-29 at 11:32 -0400, Jarod Wilson wrote: > >> I have one minor concern here. Currently, codeina gives users a pointer to a >> location where they can get codecs from, in the case where they aren't >> supported within the Fedora repositories. While pointing people to Fluendo to >> buy codec packs isn't exactly the greatest feature to preserve, we at least >> offer a solution to folks following a clean install. So far as I can tell, >> this PK solution does nothing for the user if they haven't already configured >> a 3rd-party repository where the necessary codec might be available. *I* know >> where to find that stuff and make this solution work as expected, but a new >> user might not, meaning the search would fail, and they'd think there's no way >> to play back their WMV crapola, complain loudly, etc., so this would be >> something of a regression from F9, IMO. Of course, if there's actually >> something in there that says "hey, you need to set up a 3rd-party repo and/or >> you can get codecs from Fluendo", then no problem. >> > > Which is, in fact, the whole point. Apparently not, based on Richard's reply. ;) > Codeina meant that fedora was > endorsing and encouraging the software fluendo offered. That was the > problem, imo. I agree that endorsing and encouraging non-free codec usage, particularly from a 3rd-party charging money for them, is sub-optimal for a distro all about Freedom. However, we got a big thumbs up when we started including Codeina, as it makes life much easier for end-users, while also educating them a bit. If we remove that, I think we're right back to everyone bitching about Fedora being user-unfriendly wrt codecs. -- Jarod Wilson jarod at redhat.com From jarod at redhat.com Mon Sep 29 16:33:02 2008 From: jarod at redhat.com (Jarod Wilson) Date: Mon, 29 Sep 2008 12:33:02 -0400 Subject: PackageKit-gstreamer-plugin replacing codeina In-Reply-To: <1222702606.3953.14.camel@hughsie-laptop> References: <1222683978.3385.22.camel@hughsie-laptop> <48E0F50C.8050607@redhat.com> <1222702606.3953.14.camel@hughsie-laptop> Message-ID: <48E1033E.2080300@redhat.com> Richard Hughes wrote: > On Mon, 2008-09-29 at 11:32 -0400, Jarod Wilson wrote: >> "hey, you need to set up a 3rd-party repo and/or >> you can get codecs from Fluendo", then no problem. > > No, there's not, but that's a good idea. What about something like: > > ---- > > No plugins were found to play back this media type: > > You may need to enable or set up a 3rd party software source to find > these plugins. > > You can buy media plugins from "Fluendo Codec Store" but these will not > be supported by your vendor. > > ---- > > The Fluendo Codec Store link could be just disabled in gconf, or patched > out by free software distros. I do feel something like this is unavoidable, lest we face the wrath of users and reviewers complaining about us being uncaring about their need to use non-Free codecs. Perhaps something a bit more wordy though, explaining *why* these codecs aren't included in Fedora (a la Codeina). -- Jarod Wilson jarod at redhat.com From skvidal at fedoraproject.org Mon Sep 29 16:32:36 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 29 Sep 2008 12:32:36 -0400 Subject: PackageKit-gstreamer-plugin replacing codeina In-Reply-To: <48E1029C.1040709@redhat.com> References: <1222683978.3385.22.camel@hughsie-laptop> <48E0F50C.8050607@redhat.com> <1222702508.20082.55.camel@rosebud> <48E1029C.1040709@redhat.com> Message-ID: <1222705956.20082.68.camel@rosebud> On Mon, 2008-09-29 at 12:30 -0400, Jarod Wilson wrote: > seth vidal wrote: > > On Mon, 2008-09-29 at 11:32 -0400, Jarod Wilson wrote: > > > >> I have one minor concern here. Currently, codeina gives users a pointer to a > >> location where they can get codecs from, in the case where they aren't > >> supported within the Fedora repositories. While pointing people to Fluendo to > >> buy codec packs isn't exactly the greatest feature to preserve, we at least > >> offer a solution to folks following a clean install. So far as I can tell, > >> this PK solution does nothing for the user if they haven't already configured > >> a 3rd-party repository where the necessary codec might be available. *I* know > >> where to find that stuff and make this solution work as expected, but a new > >> user might not, meaning the search would fail, and they'd think there's no way > >> to play back their WMV crapola, complain loudly, etc., so this would be > >> something of a regression from F9, IMO. Of course, if there's actually > >> something in there that says "hey, you need to set up a 3rd-party repo and/or > >> you can get codecs from Fluendo", then no problem. > >> > > > > Which is, in fact, the whole point. > > Apparently not, based on Richard's reply. ;) Richard doesn't set fedora policy afaik. Nor do I, to be clear. > I agree that endorsing and encouraging non-free codec usage, particularly from > a 3rd-party charging money for them, is sub-optimal for a distro all about > Freedom. However, we got a big thumbs up when we started including Codeina, as > it makes life much easier for end-users, while also educating them a bit. If > we remove that, I think we're right back to everyone bitching about Fedora > being user-unfriendly wrt codecs. Which is the problem. I'd rather be free software-friendly, first. -sv From skvidal at fedoraproject.org Mon Sep 29 16:36:01 2008 From: skvidal at fedoraproject.org (seth vidal) Date: Mon, 29 Sep 2008 12:36:01 -0400 Subject: PackageKit-gstreamer-plugin replacing codeina In-Reply-To: <48E1033E.2080300@redhat.com> References: <1222683978.3385.22.camel@hughsie-laptop> <48E0F50C.8050607@redhat.com> <1222702606.3953.14.camel@hughsie-laptop> <48E1033E.2080300@redhat.com> Message-ID: <1222706161.20082.72.camel@rosebud> On Mon, 2008-09-29 at 12:33 -0400, Jarod Wilson wrote: > Richard Hughes wrote: > > On Mon, 2008-09-29 at 11:32 -0400, Jarod Wilson wrote: > >> "hey, you need to set up a 3rd-party repo and/or > >> you can get codecs from Fluendo", then no problem. > > > > No, there's not, but that's a good idea. What about something like: > > > > ---- > > > > No plugins were found to play back this media type: > > > > You may need to enable or set up a 3rd party software source to find > > these plugins. > > > > You can buy media plugins from "Fluendo Codec Store" but these will not > > be supported by your vendor. > > > > ---- > > > > The Fluendo Codec Store link could be just disabled in gconf, or patched > > out by free software distros. > > I do feel something like this is unavoidable, lest we face the wrath of users > and reviewers complaining about us being uncaring about their need to use > non-Free codecs. Perhaps something a bit more wordy though, explaining *why* > these codecs aren't included in Fedora (a la Codeina). > I think, if we have upstream projects encouraging and/or pointing to for-pay services in this manner we may have to evaluate them more closely. please note my sig -sv -- I only speak for me. From jarod at redhat.com Mon Sep 29 16:51:39 2008 From: jarod at redhat.com (Jarod Wilson) Date: Mon, 29 Sep 2008 12:51:39 -0400 Subject: PackageKit-gstreamer-plugin replacing codeina In-Reply-To: <1222705956.20082.68.camel@rosebud> References: <1222683978.3385.22.camel@hughsie-laptop> <48E0F50C.8050607@redhat.com> <1222702508.20082.55.camel@rosebud> <48E1029C.1040709@redhat.com> <1222705956.20082.68.camel@rosebud> Message-ID: <48E1079B.2010406@redhat.com> seth vidal wrote: > On Mon, 2008-09-29 at 12:30 -0400, Jarod Wilson wrote: >> seth vidal wrote: >>> On Mon, 2008-09-29 at 11:32 -0400, Jarod Wilson wrote: >>> >>>> I have one minor concern here. Currently, codeina gives users a pointer to a >>>> location where they can get codecs from, in the case where they aren't >>>> supported within the Fedora repositories. While pointing people to Fluendo to >>>> buy codec packs isn't exactly the greatest feature to preserve, we at least >>>> offer a solution to folks following a clean install. So far as I can tell, >>>> this PK solution does nothing for the user if they haven't already configured >>>> a 3rd-party repository where the necessary codec might be available. *I* know >>>> where to find that stuff and make this solution work as expected, but a new >>>> user might not, meaning the search would fail, and they'd think there's no way >>>> to play back their WMV crapola, complain loudly, etc., so this would be >>>> something of a regression from F9, IMO. Of course, if there's actually >>>> something in there that says "hey, you need to set up a 3rd-party repo and/or >>>> you can get codecs from Fluendo", then no problem. >>>> >>> Which is, in fact, the whole point. >> Apparently not, based on Richard's reply. ;) > > Richard doesn't set fedora policy afaik. Nor do I, to be clear. Oh, I know, just sayin' that nuking all refs to Fluendo wasn't an explicit goal of Richard's. :) Removing the Fluendo refs actually *would* be Richard setting policy, IMO. Continuing to include them maintains current policy. >> I agree that endorsing and encouraging non-free codec usage, particularly from >> a 3rd-party charging money for them, is sub-optimal for a distro all about >> Freedom. However, we got a big thumbs up when we started including Codeina, as >> it makes life much easier for end-users, while also educating them a bit. If >> we remove that, I think we're right back to everyone bitching about Fedora >> being user-unfriendly wrt codecs. > > Which is the problem. I'd rather be free software-friendly, first. As suggested, by Josh Boyer on IRC, this is probably something for the Fedora Advisory Board to discuss. I'm all for free, but I think free needs to be balanced with the needs of users. I'm certainly not the one to set policy either, just trying to be sure we're considering all the angles here. -- Jarod Wilson jarod at redhat.com From hughsient at gmail.com Mon Sep 29 16:53:16 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 29 Sep 2008 17:53:16 +0100 Subject: PackageKit-gstreamer-plugin replacing codeina In-Reply-To: <1222706161.20082.72.camel@rosebud> References: <1222683978.3385.22.camel@hughsie-laptop> <48E0F50C.8050607@redhat.com> <1222702606.3953.14.camel@hughsie-laptop> <48E1033E.2080300@redhat.com> <1222706161.20082.72.camel@rosebud> Message-ID: <1222707196.3953.21.camel@hughsie-laptop> On Mon, 2008-09-29 at 12:36 -0400, seth vidal wrote: > > I do feel something like this is unavoidable, lest we face the wrath > of users > > and reviewers complaining about us being uncaring about their need > to use > > non-Free codecs. Perhaps something a bit more wordy though, > explaining *why* > > these codecs aren't included in Fedora (a la Codeina). > > > > I think, if we have upstream projects encouraging and/or pointing to > for-pay services in this manner we may have to evaluate them more > closely. :-) I'm not going to, but _if_ there was a link to Fluendo upstream, it would be a one line patch in a spec file to remove it for Fedora. Please don't make this a storm in a teacup. Richard. From hughsient at gmail.com Mon Sep 29 16:55:45 2008 From: hughsient at gmail.com (Richard Hughes) Date: Mon, 29 Sep 2008 17:55:45 +0100 Subject: PackageKit-gstreamer-plugin replacing codeina In-Reply-To: <1222705956.20082.68.camel@rosebud> References: <1222683978.3385.22.camel@hughsie-laptop> <48E0F50C.8050607@redhat.com> <1222702508.20082.55.camel@rosebud> <48E1029C.1040709@redhat.com> <1222705956.20082.68.camel@rosebud> Message-ID: <1222707346.3953.25.camel@hughsie-laptop> On Mon, 2008-09-29 at 12:32 -0400, seth vidal wrote: > Richard doesn't set fedora policy afaik. Nor do I, to be clear. No, I don't -- but I want to make PK _upstream_ to be suitable for all distros with all freedom policies. I don't think Fedora should ever show links to Fluendo again, but a distro like Ubuntu might want to. Richard. From jspaleta at gmail.com Mon Sep 29 17:07:38 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 29 Sep 2008 09:07:38 -0800 Subject: PackageKit-gstreamer-plugin replacing codeina In-Reply-To: <1222707346.3953.25.camel@hughsie-laptop> References: <1222683978.3385.22.camel@hughsie-laptop> <48E0F50C.8050607@redhat.com> <1222702508.20082.55.camel@rosebud> <48E1029C.1040709@redhat.com> <1222705956.20082.68.camel@rosebud> <1222707346.3953.25.camel@hughsie-laptop> Message-ID: <604aa7910809291007s61195a1ep5e7083141016ef33@mail.gmail.com> On Mon, Sep 29, 2008 at 8:55 AM, Richard Hughes wrote: > I don't think Fedora should ever show links to Fluendo again, but a > distro like Ubuntu might want to. Or a distro like that, might prefer to point to Canonical's storefront.....which has alternative pricing for Fluendo codecs. -jef From cddesjardins at gmail.com Mon Sep 29 17:09:46 2008 From: cddesjardins at gmail.com (Christopher David Desjardins) Date: Mon, 29 Sep 2008 12:09:46 -0500 Subject: Computerized Adaptive Math Program Message-ID: <48E10BDA.6030706@gmail.com> Hi, I'm sorry if this is off-topic. If someone could point me to the right forum I'd be happy to post this there. Anyways, my name is Chris Desjardins and I am Ph.D. student at the University of Minnesota and I'm interested in computerized adaptive testing/software. For my dissertation, I'm interested in the use of Bayesian approaches in item response theory. My reason for posting to this list is that I am interested in developing a math software program, primarily geared towards the XO laptops, that would use algorithms that I develop to be adaptive and essentially create an artificial intelligence where the software learns to adapt more to the student and gives them more individualized instruction with the hope that this would increase student achievement. Now I can't really program but I'd like to develop a program in python/GTK with an open source license so that it could be available for students that need the most help with mathematics and could be easily altered to adapt to different environments (cultures, languages, etc). I was curious if anyone out here would be interested in helping me with some of the programming. This project is in it's infancy. Thanks and I'm sorry if this is way off-topic. Cheers, Chris Desjardins From vonbrand at inf.utfsm.cl Mon Sep 29 17:59:01 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 29 Sep 2008 13:59:01 -0400 Subject: unfrozen repo somewhere? In-Reply-To: <1222666171.3564.392.camel@beck.corsepiu.local> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> <1222659465.3564.332.camel@beck.corsepiu.local> <200809290437.m8T4bAAH011491@laptop14.inf.utfsm.cl> <1222666171.3564.392.camel@beck.corsepiu.local> Message-ID: <200809291759.m8THx1lf004358@laptop14.inf.utfsm.cl> Ralf Corsepius wrote: > On Mon, 2008-09-29 at 00:37 -0400, Horst H. von Brand wrote: > > Ralf Corsepius wrote: > > > On Sun, 2008-09-28 at 22:38 -0400, Horst H. von Brand wrote: > > > > Ralf Corsepius wrote: > > > > > On Sun, 2008-09-28 at 14:31 -0400, Horst H. von Brand wrote: > > > > > > Ralf Corsepius wrote: > > > > > > > On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote: [...] > > > > > What I would like to see it Rel-Eng to adopt the development > > > > > principles, most other developments apply: > > > > > > > > > > Decouple "product development" (here: FC) development from > > > > > bleeding edge "unstable/experimental" "head development" (here: > > > > > rawhide). > > > > Needs more hands. Starves the "product development" of developers and > > > > testers. > > > > > I don't see this - To the contrary. I feel the current model is driving > > > away developers and testers, esp. packagers. > > Any hard (or even mushy) data to support this? > I am only speaking for myself here. I see. > > > > Was the idea in Linux before 2.6, was abandoned for exactly the > > > > above reasons. > > > ... but it is the idea which is being applied almost anywhere else. > > Examples? > ... GNOME, GCC, binutils, gdb. > > > Ask yourself: Is the current development model in Fedora a success? > > Need to define what "success" means... if it is keeping a very popular, > > solid distribution moving forward, and gathering more packages, I'd have to > > say it is. > > > I don't think so. > > How do you define "success" then? > In the sense of "development model assists to achieve a functional and > stable product". > > Where is Fedora lacking? > > 2 fundamental issues: > * Stability: Initial Fedora CD/DVD releases tend to be pretty buggy and > often are unusable. At least to me, most Fedora releases so far only > have reached a point of "acceptable quality" several weeks after > release. OK. Need more testers, more shaking out (and fixing!) bugs. Splitting the user community into "rawhide rollercoaster", "beta testers", "waiting in the wings" doesn't help here (beta testers will be a tiny miniority). The problems lie elsewhere: - How do we recruit more beta testers? Give them a "I was a beta tester" badge of sorts, for example, listing all people who reported a bug in beta in a "Thank you for testing Fedora XI" page? Other ideas? - Make the beta process more effective. Make it last somewhat longer (so there is more testing)? Define a set of "standard tests" that any user can run on the beta and report back with detailed configuration/setup? Perhaps there should be more in the way of regression tests for each package? > * Support to packagers/ease of use of the infrastructure: > One detail amongst many: The freezes are a major handicap to packagers. I just don't see how. One the one hand you complain that rawhide changes too fast to be a reliable platform on which to develop; on the other hand you don't want it to slow down ever, not even to shake out last bugs. [...] > > > - Fedora releases essentially are rawhide snapshots. Packages from > > > rawhide automatically become "stable" (Lack of "rawhide/testing"). E.g. > > > I have package upgrades pending, I currently don't want to push to > > > Fedora, because I fear them to be too unstable for a product. > > Then they should go to rawhide? > If Fedora was using release branches, then this would be a possibility. Or you could wait a week or so, or (if /really/ urgent) push it upstream. > I'd push these packages to rawhide now, and would push them to an FC10 > release branch when having gained confidence these upgrades are stable > enough for FC10. And next to nobody will test what is in the beta, as we all follow rawhide. What if the changes turn out bad, and you have to rely on what is in FC10? > The current development model causes me to withhold these upgrades to > avoid endangering FC10. Rightly so. > => These upgrades with likely be missing in initial FC10 and may (or may > not) be added to FC10 later (or never). Tough. They will be in FC11 then. It's not that that will take three or four years... > > Go into your local, > That's what they do now => Little attention, little testing. > => These upgrades with likely be missing in initial FC10 and may (or may > not) be added to FC10 later (or never). Why /must/ they be in FC10? It isn't exactly the last of the line... > == Missed opportunities. > > > > - Fedora's release process starves package development. E.g. I have > > > several (upstream) package upgrades pending, I can't push to Fedora > > > because to the freezes are permanently interfering. > > > > Please elaborate. Freezes are far in between, it would be phenomenal bad > > luck if many important upstream just happen to fall into those. And those > > can presumably be applied after the freeze is lifted. > The problem is: Neither a packager's nor an upstreams' workflow are > necessarily synchronized with Rel-Eng's workflow or Fedora release > cycles (And if they are, things occasionally tend to get worse.) So what? There has been whining that Gnome version something wasn't included, or that GCC missed the deadline, or KDE, or... and that was smoothed out by including them later (if stable enough) or just in the next round (if not). Works as designed for me. > > > - rawhide is too volatile to be usable for many testers, esp. packagers > > > testing their packages. > > Heck, rawhide is stable enough for me to use as a regular workstation (with > > some precautions), how would that be /so/ different than deoing development > > work? > A matter of personal objectives: You probably are working on the "Fedora > distro". I am working on applications and am using Fedora as a vehicle. No, Im currently /using/ Fedora as a workstation for day to day use, doing a bit of development and some testing of bleeding-egde packages. Plus reporting whenever something blows up, and backtracking. > > > - The current process introduces a bloated bureaucracy to work around > > > the side-effects of "not-branches". > > Please elaborate. I'm sure the people involved would love to get that > > workload diminished... > /me feels a lot of the bureaucracy and other churn Rel-Eng is imposing > on packagers actually is them playing with symptoms of them not applying > release branches. Please explain with apples and oranges /what/ the excessive bureacracy consists of, and how exactly having to juggle four branches (FC8, FC9, FC10 beta, rawhide) instead of three (FC8, FC9, FC10 beta) helps in reducing overhead and streamlining the release process. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From notting at redhat.com Mon Sep 29 18:34:36 2008 From: notting at redhat.com (Bill Nottingham) Date: Mon, 29 Sep 2008 14:34:36 -0400 Subject: PackageKit-gstreamer-plugin replacing codeina In-Reply-To: <604aa7910809290853s298d4d98n203f82dce5417fac@mail.gmail.com> References: <1222683978.3385.22.camel@hughsie-laptop> <48E0F50C.8050607@redhat.com> <1222702606.3953.14.camel@hughsie-laptop> <604aa7910809290853s298d4d98n203f82dce5417fac@mail.gmail.com> Message-ID: <20080929183436.GA20449@nostromo.devel.redhat.com> Jeff Spaleta (jspaleta at gmail.com) said: > On Mon, Sep 29, 2008 at 7:36 AM, Richard Hughes wrote: > > No, there's not, but that's a good idea. What about something like: > > The Fluendo Codec Store link could be just disabled in gconf, or patched > > out by free software distros. > > And other distros might have their own storefronts for codecs, with > alternative pricing. You probably do not want to hardcode a specific > vendor location as a preferred vendor in PackageKit itself. Yeah, this seems like a policy decision, best left out of any tooling. Bill From vonbrand at inf.utfsm.cl Mon Sep 29 18:39:29 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 29 Sep 2008 14:39:29 -0400 Subject: unfrozen repo somewhere? In-Reply-To: <1222667193.3564.406.camel@beck.corsepiu.local> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> <25665.1222660262@sss.pgh.pa.us> <1222663773.3564.355.camel@beck.corsepiu.local> <200809290526.m8T5QPGw012980@laptop14.inf.utfsm.cl> <1222667193.3564.406.camel@beck.corsepiu.local> Message-ID: <200809291839.m8TIdTKk004426@laptop14.inf.utfsm.cl> Ralf Corsepius wrote: > On Mon, 2008-09-29 at 01:26 -0400, Horst H. von Brand wrote: > > Ralf Corsepius wrote: > > > On Sun, 2008-09-28 at 23:51 -0400, Tom Lane wrote: > > > > "Horst H. von Brand" writes: > > > > > Ralf Corsepius wrote: > > > > > To imagine that it's workable for the majority of > > > > projects is to demonstrate lack of connection to reality. > > > Pardon, but you probably can relate, why I have to disagree on this. > > > I would turn this argument around: The apparent lack of quality of the > > > distro, the amount of bureaucracy and ineffectiveness the Fedora > > > approach cause are a living proof for a non-functional approach. > > How do you measure "distro quality", > My subjective measure is "distro works for me without major effort". Done long ago. Sure, some rough edges do remain always, but it isn't "major effort" for Fedora (hasn't really been for all of Red Hat then Fedora history as long back as I remember). > Reality is: This doesn't apply. > > "amount of bureacracy" (and how much > > of that is "too much"), "effectiveness"? > koji, bodhi, packagedb, acls, freezes, bugzilla, trac, wikis, All tools meant to /decrease/ workload (or make it more productive). > mails to > rel-eng/, Sad fact of life is that once the crowd grows too large, some explicit coordination has to come in. > the "incident", Not Rel-Eng's fault, I'd sincerely hope. Sure, it would have been better to have procedures in place to handle such in a more streamlined way, but then again that would either mean the incidents are so frequent that everybody knows in their sleep how to handle them, or having a think-tank planing out all possible (and imposible) scenarios and lines of action, resulting in a lot of extra bureacracy and friction. > the triagers, What is the problem with them? They are supposed to validate that bugs are for real, so I can't see how they hinder development progress. To the contrary, they should prevent developer's inboxes clogged with useless bug reports. > server > downtimes, Always bad, true. How do you propose help here? > mirror latencies, Not Fedora's fault; more the contrary, as Fedora is popular more mirrors are needed (and problems with any one get more visible). > bugs not getting fixed, ... Developer's fault. How do you want to fix this? Training camp for newbie developers? Make bug fixing more attractive (i.e., page of "Helped fix bugs in Fedora 10" listing patch contributors, bug triagers, ...)? User's fault (Yes, I've been known to vanish from sight and not following up on my own bug reports when I was too busy elsewhere). > All together (not worth mentioning all the bugs and nits they suffer > from) have a massive impact on effectiveness. Openly said, it has hardly > ever been less effective to contribute to Fedora as it is in recent > past. Please, /show/ how to make it better. /Tell/ where or how the workflow could be streamlined. "More branches" just makes for a swampy river delta, not smoother flow AFAIKS. > > I'd say the fact that we are discussing this shows that the qualility is at > > least decent enough for serious consideration. > Certainly - Otherwise, I wasn't be using Fedora. It's certainly not perfect, but good enough for me (and fun to booth!). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From seg at haxxed.com Mon Sep 29 18:51:16 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 29 Sep 2008 13:51:16 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1222174952.3564.75.camel@beck.corsepiu.local> References: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <20080922233924.GA20911@tango.0pointer.de> <20080923085417.GA18032@mokona.greysector.net> <20080923122126.GB7596@tango.0pointer.de> <1222173537.3564.69.camel@beck.corsepiu.local> <20080923124710.GF7596@tango.0pointer.de> <1222174952.3564.75.camel@beck.corsepiu.local> Message-ID: <1222714276.3549.3.camel@localhost.localdomain> On Tue, 2008-09-23 at 15:02 +0200, Ralf Corsepius wrote: > ioctl's are a well defined _low level_ interface, providing a clean and > "natural" separation between kernel and userspace. http://www.catb.org/esr/writings/taoup/html/ch20s03.html > To make them easily applicable in high-level userspace applications, > they are supposed to be wrapped. That's just hiding the problem. Unfortunately, that's the best we can do at the moment. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Mon Sep 29 18:51:16 2008 From: seg at haxxed.com (Callum Lerwick) Date: Mon, 29 Sep 2008 13:51:16 -0500 Subject: Pulseaudio : lots of issues, how can I help? In-Reply-To: <1222174952.3564.75.camel@beck.corsepiu.local> References: <389d123ba021a0f052ea0e92419028ae.squirrel@rousalka.dyndns.org> <20080915105704.GG20342@mokona.greysector.net> <3f1510c7fd46b7d74b4c8ff4813bd113.squirrel@rousalka.dyndns.org> <20080915120457.GH20342@mokona.greysector.net> <7e65991b1e84967bfc037632ff8a86e1.squirrel@rousalka.dyndns.org> <20080915140703.GI20342@mokona.greysector.net> <20080922233924.GA20911@tango.0pointer.de> <20080923085417.GA18032@mokona.greysector.net> <20080923122126.GB7596@tango.0pointer.de> <1222173537.3564.69.camel@beck.corsepiu.local> <20080923124710.GF7596@tango.0pointer.de> <1222174952.3564.75.camel@beck.corsepiu.local> Message-ID: <1222714276.3549.3.camel@localhost.localdomain> On Tue, 2008-09-23 at 15:02 +0200, Ralf Corsepius wrote: > ioctl's are a well defined _low level_ interface, providing a clean and > "natural" separation between kernel and userspace. http://www.catb.org/esr/writings/taoup/html/ch20s03.html > To make them easily applicable in high-level userspace applications, > they are supposed to be wrapped. That's just hiding the problem. Unfortunately, that's the best we can do at the moment. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From nicolas.mailhot at laposte.net Mon Sep 29 19:07:39 2008 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 29 Sep 2008 21:07:39 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <200809291759.m8THx1lf004358@laptop14.inf.utfsm.cl> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> <1222659465.3564.332.camel@beck.corsepiu.local> <200809290437.m8T4bAAH011491@laptop14.inf.utfsm.cl> <1222666171.3564.392.camel@beck.corsepiu.local> <200809291759.m8THx1lf004358@laptop14.inf.utfsm.cl> Message-ID: <1222715259.7795.5.camel@arekh.okg> Le lundi 29 septembre 2008 ? 13:59 -0400, Horst H. von Brand a ?crit : > - Make the beta process more effective. Make it last somewhat longer (so > there is more testing)? Totally useless. The #1 problem in testing is processing bug reports before they go stale or the reporter gets fed up and starts doing something else. Increasing the beta window will just make it harder for testers and developpers to meet themselves on the timeline. -- 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 vonbrand at inf.utfsm.cl Mon Sep 29 19:16:38 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 29 Sep 2008 15:16:38 -0400 Subject: rawhide report: 20080929 changes In-Reply-To: <20080929122731.3983E1F825C@releng2.fedora.phx.redhat.com> References: <20080929122731.3983E1F825C@releng2.fedora.phx.redhat.com> Message-ID: <200809291916.m8TJGcJ8004701@laptop14.inf.utfsm.cl> Rawhide Report wrote: [...] > New package moe > A powerful clean text editor The description seems to say that it doesn't support UTF-8, just Latin-X. If that is true, it has no place in (all-UTF) Fedora... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From lesmikesell at gmail.com Mon Sep 29 19:18:14 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 29 Sep 2008 14:18:14 -0500 Subject: unfrozen repo somewhere? In-Reply-To: <1222715259.7795.5.camel@arekh.okg> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> <1222659465.3564.332.camel@beck.corsepiu.local> <200809290437.m8T4bAAH011491@laptop14.inf.utfsm.cl> <1222666171.3564.392.camel@beck.corsepiu.local> <200809291759.m8THx1lf004358@laptop14.inf.utfsm.cl> <1222715259.7795.5.camel@arekh.okg> Message-ID: <48E129F6.5080801@gmail.com> Nicolas Mailhot wrote: > Le lundi 29 septembre 2008 ? 13:59 -0400, Horst H. von Brand a ?crit : > >> - Make the beta process more effective. Make it last somewhat longer (so >> there is more testing)? > > Totally useless. The #1 problem in testing is processing bug reports > before they go stale or the reporter gets fed up and starts doing > something else. Increasing the beta window will just make it harder for > testers and developpers to meet themselves on the timeline. You could probably pick up a whole lot more beta testers at a moment's notice if you'd roll a VMware image that anyone could download and run under most existing OS's. It wouldn't test all the hardware drivers but the apps, filesystems, etc. would all run the same. -- Les Mikesell lesmikesell at gmail.com From lesmikesell at gmail.com Mon Sep 29 19:07:15 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 29 Sep 2008 14:07:15 -0500 Subject: unfrozen repo somewhere? In-Reply-To: <200809291839.m8TIdTKk004426@laptop14.inf.utfsm.cl> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> <25665.1222660262@sss.pgh.pa.us> <1222663773.3564.355.camel@beck.corsepiu.local> <200809290526.m8T5QPGw012980@laptop14.inf.utfsm.cl> <1222667193.3564.406.camel@beck.corsepiu.local> <200809291839.m8TIdTKk004426@laptop14.inf.utfsm.cl> Message-ID: <48E12763.6020200@gmail.com> Horst H. von Brand wrote: > >> bugs not getting fixed, ... > > Developer's fault. It's not the developer's fault that you _ship_ new bugs. > How do you want to fix this? Training camp for newbie > developers? Make bug fixing more attractive (i.e., page of "Helped fix bugs > in Fedora 10" listing patch contributors, bug triagers, ...)? Just don't ship them. If someone has to fix bugs in a released Fedora as opposed to rawhide or upstream before the version is packaged, you've already lost. > Please, /show/ how to make it better. /Tell/ where or how the workflow > could be streamlined. "More branches" just makes for a swampy river delta, > not smoother flow AFAIKS. You probably can't match RHEL's QA for free, but testing - and not shipping things that don't pass - is the only way things can get better. >>> I'd say the fact that we are discussing this shows that the qualility is at >>> least decent enough for serious consideration. > >> Certainly - Otherwise, I wasn't be using Fedora. > > It's certainly not perfect, but good enough for me (and fun to booth!). I've heard the term used as in "an instrument's tuning is 'good enough' for folk music" or "an approximation is 'good enough' for government work". What's 'good enough' for an operating system? -- Les Mikesell lesmikesell at gmail.com From rc040203 at freenet.de Mon Sep 29 20:14:01 2008 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 29 Sep 2008 22:14:01 +0200 Subject: unfrozen repo somewhere? In-Reply-To: <200809291759.m8THx1lf004358@laptop14.inf.utfsm.cl> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> <1222659465.3564.332.camel@beck.corsepiu.local> <200809290437.m8T4bAAH011491@laptop14.inf.utfsm.cl> <1222666171.3564.392.camel@beck.corsepiu.local> <200809291759.m8THx1lf004358@laptop14.inf.utfsm.cl> Message-ID: <1222719241.3564.469.camel@beck.corsepiu.local> On Mon, 2008-09-29 at 13:59 -0400, Horst H. von Brand wrote: > Ralf Corsepius wrote: > > On Mon, 2008-09-29 at 00:37 -0400, Horst H. von Brand wrote: > > > Ralf Corsepius wrote: > > > > On Sun, 2008-09-28 at 22:38 -0400, Horst H. von Brand wrote: > > > > > Ralf Corsepius wrote: > > > > > > On Sun, 2008-09-28 at 14:31 -0400, Horst H. von Brand wrote: > > > > > > > Ralf Corsepius wrote: > > > > > > > > On Fri, 2008-09-26 at 11:11 +0200, Patrice Dumas wrote: > > [...] > > > > > > > What I would like to see it Rel-Eng to adopt the development > > > > > > principles, most other developments apply: > > > > > > > > > > > > Decouple "product development" (here: FC) development from > > > > > > bleeding edge "unstable/experimental" "head development" (here: > > > > > > rawhide). > > > > > > Needs more hands. Starves the "product development" of developers and > > > > > testers. > > > > > > > I don't see this - To the contrary. I feel the current model is driving > > > > away developers and testers, esp. packagers. > > > > Any hard (or even mushy) data to support this? > > > Where is Fedora lacking? > > > > 2 fundamental issues: > > > * Stability: Initial Fedora CD/DVD releases tend to be pretty buggy and > > often are unusable. At least to me, most Fedora releases so far only > > have reached a point of "acceptable quality" several weeks after > > release. > > OK. Need more testers, more shaking out (and fixing!) bugs. My view: Not the too few testers, but an effect of an unhealthy workflow and immature infrastructure. > Splitting the > user community into "rawhide rollercoaster", "beta testers", "waiting in > the wings" doesn't help here (beta testers will be a tiny miniority). Correct - These dedicated Fedora testers group can only iron out the worst "brown paperbag class" bugs and misc. random bug - They will never can compete with the amount of testing provided by the community. > The problems lie elsewhere: > > - How do we recruit more beta testers? My opinion: By changing the workflow, encouraging collaboration (e.g. abandoning ACLs) and by replacing certain people who are known to ignore bugs. > Give them a "I was a beta tester" > badge of sorts, for example, listing all people who reported a bug in > beta in a "Thank you for testing Fedora XI" page? Other ideas? > - Make the beta process more effective. Make it last somewhat longer (so > there is more testing)? Define a set of "standard tests" that any user > can run on the beta and report back with detailed configuration/setup? > Perhaps there should be more in the way of regression tests for each > package? > > > * Support to packagers/ease of use of the infrastructure: > > One detail amongst many: The freezes are a major handicap to packagers. > > I just don't see how. One the one hand you complain that rawhide changes > too fast to be a reliable platform on which to develop; on the other hand > you don't want it to slow down ever, not even to shake out last bugs. Note: RAWHIDE vs. PRODUCT * Rawhide is TOO unstable to be usable * Rawhide freezes are stalling the PRODUCT (Here: FC10 is killing FC9). > > I'd push these packages to rawhide now, and would push them to an FC10 > > release branch when having gained confidence these upgrades are stable > > enough for FC10. > > And next to nobody will test what is in the beta, as we all follow > rawhide. The situation would not change at all, because it's essentially the same as what currently is happening. The only difference: Freeze would not not block development. > > The current development model causes me to withhold these upgrades to > > avoid endangering FC10. > > Rightly so. > > > => These upgrades with likely be missing in initial FC10 and may (or may > > not) be added to FC10 later (or never). > > Tough. They will be in FC11 then. It's not that that will take three or > four years... > > > > Go into your local, > > That's what they do now => Little attention, little testing. > > => These upgrades with likely be missing in initial FC10 and may (or may > > not) be added to FC10 later (or never). > > Why /must/ they be in FC10? It isn't exactly the last of the line... Why should Fedora ship outdated stuff? To a community contributor, the purpose of Fedora is to serve as medium to distribute packages and to mutually share packages with other users. So to answer your question: It's Fedora's job. If Fedora's infrastructure is too inflexible to handle this, Fedora has failed. > > > > - Fedora's release process starves package development. E.g. I have > > > > several (upstream) package upgrades pending, I can't push to Fedora > > > > because to the freezes are permanently interfering. > > > > > > Please elaborate. Freezes are far in between, it would be phenomenal bad > > > luck if many important upstream just happen to fall into those. And those > > > can presumably be applied after the freeze is lifted. > > > The problem is: Neither a packager's nor an upstreams' workflow are > > necessarily synchronized with Rel-Eng's workflow or Fedora release > > cycles (And if they are, things occasionally tend to get worse.) > > So what? There has been whining that Gnome version something wasn't > included, or that GCC missed the deadline, or KDE, or... and that was > smoothed out by including them later (if stable enough) or just in the next > round (if not). Works as designed for me. Good for you - Unacceptable to me, as shame for Fedora. > > > > - The current process introduces a bloated bureaucracy to work around > > > > the side-effects of "not-branches". > > > > Please elaborate. I'm sure the people involved would love to get that > > > workload diminished... > > > /me feels a lot of the bureaucracy and other churn Rel-Eng is imposing > > on packagers actually is them playing with symptoms of them not applying > > release branches. > > Please explain with apples and oranges /what/ the excessive bureacracy > consists of, and how exactly having to juggle four branches (FC8, FC9, FC10 > beta, rawhide) instead of three (FC8, FC9, FC10 beta) helps in reducing > overhead and streamlining the release process. Please do yourselves the faviour and maintain some packages in Fedora. Then you'll probably notice the bureaucracy Rel-Eng has implemented and how immature many things are. Ralf From mdehaan at redhat.com Mon Sep 29 20:22:56 2008 From: mdehaan at redhat.com (Michael DeHaan) Date: Mon, 29 Sep 2008 16:22:56 -0400 Subject: Computerized Adaptive Math Program In-Reply-To: <48E10BDA.6030706@gmail.com> References: <48E10BDA.6030706@gmail.com> Message-ID: <48E13920.90200@redhat.com> Christopher David Desjardins wrote: > Hi, > that I develop to be adaptive and essentially create an artificial > intelligence where the software learns to adapt more to the student > and gives them more individualized instruction with the hope that this > would increase student achievement. > They tried this in Ender's game, it could be /really/ dangerous. --Michael From mattdm at mattdm.org Mon Sep 29 20:25:48 2008 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 29 Sep 2008 16:25:48 -0400 Subject: rawhide report: 20080929 changes In-Reply-To: <200809291916.m8TJGcJ8004701@laptop14.inf.utfsm.cl> References: <20080929122731.3983E1F825C@releng2.fedora.phx.redhat.com> <200809291916.m8TJGcJ8004701@laptop14.inf.utfsm.cl> Message-ID: <20080929202548.GA25965@jadzia.bu.edu> On Mon, Sep 29, 2008 at 03:16:38PM -0400, Horst H. von Brand wrote: > > New package moe > > A powerful clean text editor > The description seems to say that it doesn't support UTF-8, just > Latin-X. If that is true, it has no place in (all-UTF) Fedora... I just tested it, and it does indeed to horrible things to UTF-8 files. I don't know if that means it has no place, but it certainly makes it less useful. -- Matthew Miller Senior Systems Architect Cyberinfrastructure Labs Computing & Information Technology Harvard School of Engineering & Applied Sciences From jkeating at redhat.com Mon Sep 29 20:29:21 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 29 Sep 2008 13:29:21 -0700 Subject: unfrozen repo somewhere? In-Reply-To: <48E129F6.5080801@gmail.com> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> <1222659465.3564.332.camel@beck.corsepiu.local> <200809290437.m8T4bAAH011491@laptop14.inf.utfsm.cl> <1222666171.3564.392.camel@beck.corsepiu.local> <200809291759.m8THx1lf004358@laptop14.inf.utfsm.cl> <1222715259.7795.5.camel@arekh.okg> <48E129F6.5080801@gmail.com> Message-ID: <1222720161.23360.2.camel@luminos.localdomain> On Mon, 2008-09-29 at 14:18 -0500, Les Mikesell wrote: > > You could probably pick up a whole lot more beta testers at a moment's > notice if you'd roll a VMware image that anyone could download and run > under most existing OS's. It wouldn't test all the hardware drivers but > the apps, filesystems, etc. would all run the same. And why can't you do this with the live images? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From lesmikesell at gmail.com Mon Sep 29 20:56:22 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 29 Sep 2008 15:56:22 -0500 Subject: unfrozen repo somewhere? In-Reply-To: <1222720161.23360.2.camel@luminos.localdomain> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> <1222659465.3564.332.camel@beck.corsepiu.local> <200809290437.m8T4bAAH011491@laptop14.inf.utfsm.cl> <1222666171.3564.392.camel@beck.corsepiu.local> <200809291759.m8THx1lf004358@laptop14.inf.utfsm.cl> <1222715259.7795.5.camel@arekh.okg> <48E129F6.5080801@gmail.com> <1222720161.23360.2.camel@luminos.localdomain> Message-ID: <48E140F6.80608@gmail.com> Jesse Keating wrote: > On Mon, 2008-09-29 at 14:18 -0500, Les Mikesell wrote: >> You could probably pick up a whole lot more beta testers at a moment's >> notice if you'd roll a VMware image that anyone could download and run >> under most existing OS's. It wouldn't test all the hardware drivers but >> the apps, filesystems, etc. would all run the same. > > And why can't you do this with the live images? Don't you have (a) burn a CD, and (b) _stop_ running your current OS/apps to boot a live image, plus not being able to update them and save files conveniently? All of those are good reasons not to bother. And will the live image even run on an Intel Mac? I suppose you could run a CD live image inside of a bare VMware instance but you'd take a double hit or worse on performance plus wasting the time and plastic to burn the image. -- Les Mikesell lesmikesell at gmail.com From fedoraproject at cyberpear.com Mon Sep 29 21:06:54 2008 From: fedoraproject at cyberpear.com (James Cassell) Date: Mon, 29 Sep 2008 17:06:54 -0400 Subject: unfrozen repo somewhere? In-Reply-To: <48E140F6.80608@gmail.com> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> <1222659465.3564.332.camel@beck.corsepiu.local> <200809290437.m8T4bAAH011491@laptop14.inf.utfsm.cl> <1222666171.3564.392.camel@beck.corsepiu.local> <200809291759.m8THx1lf004358@laptop14.inf.utfsm.cl> <1222715259.7795.5.camel@arekh.okg> <48E129F6.5080801@gmail.com> <1222720161.23360.2.camel@luminos.localdomain> <48E140F6.80608@gmail.com> Message-ID: On Mon, 29 Sep 2008 16:56:22 -0400, Les Mikesell wrote: > I suppose you could run a CD live image inside of a bare VMware instance > but you'd take a double hit or worse on performance plus wasting the > time and plastic to burn the image. VMware will let you mount an iso as the boot device, so no plastic-wasting needed. (or perhaps, more specifically, let you set the CD-ROM device to "Use ISO image") -- James Cassell From jkeating at redhat.com Mon Sep 29 21:10:48 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 29 Sep 2008 14:10:48 -0700 Subject: unfrozen repo somewhere? In-Reply-To: <48E140F6.80608@gmail.com> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> <1222659465.3564.332.camel@beck.corsepiu.local> <200809290437.m8T4bAAH011491@laptop14.inf.utfsm.cl> <1222666171.3564.392.camel@beck.corsepiu.local> <200809291759.m8THx1lf004358@laptop14.inf.utfsm.cl> <1222715259.7795.5.camel@arekh.okg> <48E129F6.5080801@gmail.com> <1222720161.23360.2.camel@luminos.localdomain> <48E140F6.80608@gmail.com> Message-ID: <1222722648.23360.6.camel@luminos.localdomain> On Mon, 2008-09-29 at 15:56 -0500, Les Mikesell wrote: > Don't you have (a) burn a CD, No. > and (b) _stop_ running your current > OS/apps to boot a live image, No, you can boot the iso in a virt environment. It works great and is damned fast. > plus not being able to update them and > save files conveniently? Wrong and wrong. When using a USB key (which you can also do via virt systems) you can in fact update software, save files/settings. The thing you can't do at this point is update the kernel. > All of those are good reasons not to bother. Not to bother looking at what features it has also, obviously. > And will the live image even run on an Intel Mac? Yes, not only native, but also through virt technologies, such as vmware, kvm, xen, qemu on Linux, vmware and parallels on OS X. > > I suppose you could run a CD live image inside of a bare VMware instance > but you'd take a double hit or worse on performance plus wasting the > time and plastic to burn the image. How is it a double hit, especially if you're booting from the iso image rather than a burned media? -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From lesmikesell at gmail.com Mon Sep 29 21:47:58 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 29 Sep 2008 16:47:58 -0500 Subject: unfrozen repo somewhere? In-Reply-To: <1222722648.23360.6.camel@luminos.localdomain> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> <1222659465.3564.332.camel@beck.corsepiu.local> <200809290437.m8T4bAAH011491@laptop14.inf.utfsm.cl> <1222666171.3564.392.camel@beck.corsepiu.local> <200809291759.m8THx1lf004358@laptop14.inf.utfsm.cl> <1222715259.7795.5.camel@arekh.okg> <48E129F6.5080801@gmail.com> <1222720161.23360.2.camel@luminos.localdomain> <48E140F6.80608@gmail.com> <1222722648.23360.6.camel@luminos.localdomain> Message-ID: <48E14D0E.5080304@gmail.com> Jesse Keating wrote: > > Wrong and wrong. When using a USB key (which you can also do via virt > systems) you can in fact update software, save files/settings. The > thing you can't do at this point is update the kernel. Is the procedure for this documented somewhere? I didn't think the free vmware products would boot a usb image - but haven't tried it either. >> All of those are good reasons not to bother. > > Not to bother looking at what features it has also, obviously. So far I haven't seen anything in release notes that looks anywhere near as convenient as downloading a ready to run vmware image. The process to create a bootable USB looks like it requires a already-installed system, and I don't see any estimate of the disk space and time it will waste to do the 'install to hard drive' in a VM to get a writable system. I've also always had to track down hacks to make vmware tools work when I wanted to run fedora under vmware - is that still a problem? >> I suppose you could run a CD live image inside of a bare VMware instance >> but you'd take a double hit or worse on performance plus wasting the >> time and plastic to burn the image. > > How is it a double hit, especially if you're booting from the iso image > rather than a burned media? Isn't there an extra layer of filesystem compression happening to access the iso files? And on a real CD you have the slow seek time too. -- Les Mikesell lesmikesell at gmail.com From jkeating at redhat.com Mon Sep 29 21:55:21 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 29 Sep 2008 14:55:21 -0700 Subject: No dynamic groups in PackageKit In-Reply-To: <48D9397A.2060803@leemhuis.info> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> <1222150606.30758.65.camel@code.and.org> <48D897E6.4090600@googlemail.com> <48D923A0.4060001@leemhuis.info> <1222190549.4108.69.camel@luminos.localdomain> <48D92CE6.5000402@leemhuis.info> <1222192700.4108.74.camel@luminos.localdomain> <48D93237.5080101@leemhuis.info> <48D9397A.2060803@leemhuis.info> Message-ID: <1222725321.23360.13.camel@luminos.localdomain> On Tue, 2008-09-23 at 20:46 +0200, Thorsten Leemhuis wrote: > Done, but only for the "free" repo for now; new comps can be found for > review in CVS for RPM Fusion: > http://cvs.rpmfusion.org/viewvc/comps/comps-f10.xml.in?root=free&view=markup > > File is on the way to the repo and should be available at > http://download1.rpmfusion.org/free/fedora/development//os/comps.xml > in a few minutes. > > James, Jesse, does that look like it should look like? I think so. The real test is what does yum/anaconda see with these repos. Ideally it'd just be one instance of each group, with all the right content of the combined repos. > > Some questions: > > - Should I better remove the fields "<_name>", "<_description>" > "" and "" to avoid mixing up what comes from > Fedora's comps.xml? I'm honestly not sure what will happen. Worth testing I suppose. It may not work too well if people use the repo alone without a matching Fedora repo. Of course, that would be silly to do, but meh... > > - I don't define any category's; is that okay? I think that's fine, provided again that the user uses a Fedora repo with it to pick up that missing grouping information. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Mon Sep 29 21:57:15 2008 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 29 Sep 2008 14:57:15 -0700 Subject: F11 Spins process refinement In-Reply-To: References: Message-ID: <1222725435.23360.14.camel@luminos.localdomain> On Mon, 2008-09-22 at 23:33 -0400, Jon Stanley wrote: > Release Engineering > Board If I haven't missed it, I can show up on behalf of either of these groups. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From cmadams at hiwaay.net Mon Sep 29 21:59:17 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 29 Sep 2008 16:59:17 -0500 Subject: unfrozen repo somewhere? In-Reply-To: <48E14D0E.5080304@gmail.com> References: <1222659465.3564.332.camel@beck.corsepiu.local> <200809290437.m8T4bAAH011491@laptop14.inf.utfsm.cl> <1222666171.3564.392.camel@beck.corsepiu.local> <200809291759.m8THx1lf004358@laptop14.inf.utfsm.cl> <1222715259.7795.5.camel@arekh.okg> <48E129F6.5080801@gmail.com> <1222720161.23360.2.camel@luminos.localdomain> <48E140F6.80608@gmail.com> <1222722648.23360.6.camel@luminos.localdomain> <48E14D0E.5080304@gmail.com> Message-ID: <20080929215917.GA1188670@hiwaay.net> Once upon a time, Les Mikesell said: > So far I haven't seen anything in release notes that looks anywhere near > as convenient as downloading a ready to run vmware image. The process > to create a bootable USB looks like it requires a already-installed > system, and I don't see any estimate of the disk space and time it will > waste to do the 'install to hard drive' in a VM to get a writable > system. I've also always had to track down hacks to make vmware tools > work when I wanted to run fedora under vmware - is that still a problem? With qemu/qemu-kvm, you can download and run the LiveCD ISO image with "-cdrom /path/to/image.iso -boot d". If vmware makes it harder than that, then I'd say you should give an Open Source virtualization tool a try. If you really want to make a disk image to run from, you can set up an empty disk image file (allow several gig, but the qemu qcow2 image type only uses more-or-less what you use under the virtual image, so you can allow 10G or more and let it grow on demand), boot the ISO image, and transfer to the disk image. That isn't but a couple of extra steps and a few minutes of work (since you don't have to wait for CD/DVD seeks). The only "wasted" space is the ISO image (and if 700M is too much space for you, you probably don't have enough free space to run the virtual image anyway). So: qemu-img create -f qcow2 liveinst.img 10G sudo qemu-kvm -m 1024 -hda liveinst.img -cdrom /path/to/livecd.iso -boot d [click "transfer to disk" and shut down] rm /path/to/livecd.iso # (if space is at a premium) sudo qemu-kvm -m 1024 -hda liveinst.img -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jonstanley at gmail.com Mon Sep 29 22:04:05 2008 From: jonstanley at gmail.com (Jon Stanley) Date: Mon, 29 Sep 2008 18:04:05 -0400 Subject: [Fedora-spins] F11 Spins process refinement In-Reply-To: <1222725435.23360.14.camel@luminos.localdomain> References: <1222725435.23360.14.camel@luminos.localdomain> Message-ID: On Mon, Sep 29, 2008 at 5:57 PM, Jesse Keating wrote: > If I haven't missed it, I can show up on behalf of either of these > groups. Nope, you haven't missed it - since it didn't happen last week I'd like it to happen at some point this week. Just need a time that works for everyone. I'll throw out Wednesday at 1600UTC (noon Eastern, 9 pacific) as a starting point for discussion. From lesmikesell at gmail.com Mon Sep 29 22:20:07 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 29 Sep 2008 17:20:07 -0500 Subject: unfrozen repo somewhere? In-Reply-To: <20080929215917.GA1188670@hiwaay.net> References: <1222659465.3564.332.camel@beck.corsepiu.local> <200809290437.m8T4bAAH011491@laptop14.inf.utfsm.cl> <1222666171.3564.392.camel@beck.corsepiu.local> <200809291759.m8THx1lf004358@laptop14.inf.utfsm.cl> <1222715259.7795.5.camel@arekh.okg> <48E129F6.5080801@gmail.com> <1222720161.23360.2.camel@luminos.localdomain> <48E140F6.80608@gmail.com> <1222722648.23360.6.camel@luminos.localdomain> <48E14D0E.5080304@gmail.com> <20080929215917.GA1188670@hiwaay.net> Message-ID: <48E15497.4060603@gmail.com> Chris Adams wrote: > >> So far I haven't seen anything in release notes that looks anywhere near >> as convenient as downloading a ready to run vmware image. The process >> to create a bootable USB looks like it requires a already-installed >> system, and I don't see any estimate of the disk space and time it will >> waste to do the 'install to hard drive' in a VM to get a writable >> system. I've also always had to track down hacks to make vmware tools >> work when I wanted to run fedora under vmware - is that still a problem? > > With qemu/qemu-kvm, you can download and run the LiveCD ISO image with > "-cdrom /path/to/image.iso -boot d". If vmware makes it harder than > that, then I'd say you should give an Open Source virtualization tool a > try. It's easy enough to boot an iso or iso image file. But that won't be writable. > If you really want to make a disk image to run from, you can set up an > empty disk image file (allow several gig, but the qemu qcow2 image type > only uses more-or-less what you use under the virtual image, so you can > allow 10G or more and let it grow on demand), boot the ISO image, and > transfer to the disk image. That isn't but a couple of extra steps and > a few minutes of work (since you don't have to wait for CD/DVD seeks). Doing a couple of extra steps and wasting disk space is one thing for something I expect to be able to use. Doing it frequently to test something that probably isn't ready for prime time is something else. My point was, and is, that if you'd like more testers it would probably help to eliminate those extra steps that each would have to repeat. -- Les Mikesell lesmikesell at gmail.com From sundaram at fedoraproject.org Mon Sep 29 22:23:38 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 30 Sep 2008 03:53:38 +0530 Subject: unfrozen repo somewhere? In-Reply-To: <48E15497.4060603@gmail.com> References: <1222659465.3564.332.camel@beck.corsepiu.local> <200809290437.m8T4bAAH011491@laptop14.inf.utfsm.cl> <1222666171.3564.392.camel@beck.corsepiu.local> <200809291759.m8THx1lf004358@laptop14.inf.utfsm.cl> <1222715259.7795.5.camel@arekh.okg> <48E129F6.5080801@gmail.com> <1222720161.23360.2.camel@luminos.localdomain> <48E140F6.80608@gmail.com> <1222722648.23360.6.camel@luminos.localdomain> <48E14D0E.5080304@gmail.com> <20080929215917.GA1188670@hiwaay.net> <48E15497.4060603@gmail.com> Message-ID: <48E1556A.7080303@fedoraproject.org> Les Mikesell wrote: > Chris Adams wrote: >> >>> So far I haven't seen anything in release notes that looks anywhere >>> near as convenient as downloading a ready to run vmware image. The >>> process to create a bootable USB looks like it requires a >>> already-installed system, and I don't see any estimate of the disk >>> space and time it will waste to do the 'install to hard drive' in a >>> VM to get a writable system. I've also always had to track down >>> hacks to make vmware tools work when I wanted to run fedora under >>> vmware - is that still a problem? >> >> With qemu/qemu-kvm, you can download and run the LiveCD ISO image with >> "-cdrom /path/to/image.iso -boot d". If vmware makes it harder than >> that, then I'd say you should give an Open Source virtualization tool a >> try. > > It's easy enough to boot an iso or iso image file. But that won't be > writable. It would be if you make it a Live USB. http://fedorahosted.org/liveusb-creator Rahul From vonbrand at inf.utfsm.cl Mon Sep 29 22:38:06 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 29 Sep 2008 18:38:06 -0400 Subject: rawhide report: 20080929 changes In-Reply-To: <20080929202548.GA25965@jadzia.bu.edu> References: <20080929122731.3983E1F825C@releng2.fedora.phx.redhat.com> <200809291916.m8TJGcJ8004701@laptop14.inf.utfsm.cl> <20080929202548.GA25965@jadzia.bu.edu> Message-ID: <200809292238.m8TMc6MY016494@laptop14.inf.utfsm.cl> Matthew Miller wrote: > On Mon, Sep 29, 2008 at 03:16:38PM -0400, Horst H. von Brand wrote: > > > New package moe > > > A powerful clean text editor > > The description seems to say that it doesn't support UTF-8, just > > Latin-X. If that is true, it has no place in (all-UTF) Fedora... > I just tested it, and it does indeed to horrible things to UTF-8 files. I > don't know if that means it has no place, but it certainly makes it less > useful. File a bug then, please; perhaps suggest removing the package if not UTFable. Fedora moved to UTF-8 a while back, which was a large step forward for i18n; some (legacy) packages don't understand UTF-8 fully (yet?), but for a new package it is not excusable, IHVHO. And I was looking at this as a tiny editor that could be included in e.g. rescue images. Oh, well. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From pertusus at free.fr Mon Sep 29 22:40:00 2008 From: pertusus at free.fr (Patrice Dumas) Date: Tue, 30 Sep 2008 00:40:00 +0200 Subject: rawhide report: 20080929 changes In-Reply-To: <200809291916.m8TJGcJ8004701@laptop14.inf.utfsm.cl> References: <20080929122731.3983E1F825C@releng2.fedora.phx.redhat.com> <200809291916.m8TJGcJ8004701@laptop14.inf.utfsm.cl> Message-ID: <20080929224000.GA3042@free.fr> On Mon, Sep 29, 2008 at 03:16:38PM -0400, Horst H. von Brand wrote: > Rawhide Report wrote: > > [...] > > > New package moe > > A powerful clean text editor > > The description seems to say that it doesn't support UTF-8, just > Latin-X. If that is true, it has no place in (all-UTF) Fedora... Why? -- Pat From jkeating at j2solutions.net Mon Sep 29 22:46:50 2008 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 29 Sep 2008 15:46:50 -0700 Subject: [Fedora-spins] F11 Spins process refinement In-Reply-To: References: <1222725435.23360.14.camel@luminos.localdomain> Message-ID: <1222728410.23360.32.camel@luminos.localdomain> > On Mon, 2008-09-29 at 18:04 -0400, Jon Stanley wrote: > > Nope, you haven't missed it - since it didn't happen last week I'd > like it to happen at some point this week. Just need a time that works > for everyone. I'll throw out Wednesday at 1600UTC (noon Eastern, 9 > pacific) as a starting point for discussion. That bumps into the tail end of the QA meeting, which should be fine. Count me in. -- Jesse Keating RHCE (http://jkeating.livejournal.com) Fedora Project (http://fedoraproject.org/wiki/JesseKeating) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) identi.ca (http://identi.ca/jkeating) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From poelstra at redhat.com Mon Sep 29 22:54:29 2008 From: poelstra at redhat.com (John Poelstra) Date: Mon, 29 Sep 2008 15:54:29 -0700 Subject: [Fedora-spins] F11 Spins process refinement In-Reply-To: References: <1222725435.23360.14.camel@luminos.localdomain> Message-ID: <48E15CA5.3020209@redhat.com> Jon Stanley said the following on 09/29/2008 03:04 PM Pacific Time: > On Mon, Sep 29, 2008 at 5:57 PM, Jesse Keating wrote: > >> If I haven't missed it, I can show up on behalf of either of these >> groups. > > Nope, you haven't missed it - since it didn't happen last week I'd > like it to happen at some point this week. Just need a time that works > for everyone. I'll throw out Wednesday at 1600UTC (noon Eastern, 9 > pacific) as a starting point for discussion. > I can make it. I suggest people log in to gobby in advance in case we want to do some collaborative note taking. John From vonbrand at inf.utfsm.cl Mon Sep 29 22:57:59 2008 From: vonbrand at inf.utfsm.cl (Horst H. von Brand) Date: Mon, 29 Sep 2008 18:57:59 -0400 Subject: unfrozen repo somewhere? In-Reply-To: <48E12763.6020200@gmail.com> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> <25665.1222660262@sss.pgh.pa.us> <1222663773.3564.355.camel@beck.corsepiu.local> <200809290526.m8T5QPGw012980@laptop14.inf.utfsm.cl> <1222667193.3564.406.camel@beck.corsepiu.local> <200809291839.m8TIdTKk004426@laptop14.inf.utfsm.cl> <48E12763.6020200@gmail.com> Message-ID: <200809292257.m8TMvxJC016686@laptop14.inf.utfsm.cl> Les Mikesell wrote: > Horst H. von Brand wrote: > >> bugs not getting fixed, ... > > Developer's fault. > It's not the developer's fault that you _ship_ new bugs. OK, packager's fault in that case then. > > How do you want to fix this? Training camp for newbie > > developers? Make bug fixing more attractive (i.e., page of "Helped fix bugs > > in Fedora 10" listing patch contributors, bug triagers, ...)? > Just don't ship them. If you have some sort of bug-detector that I can wave over packages before letting them loose... > If someone has to fix bugs in a released Fedora > as opposed to rawhide or upstream before the version is packaged, > you've already lost. As things stand, I'd bet the very wast majority of people don't get "upstream" but something packaged by some distribution. If I'm right, the /only/ place where you can catch bugs is through the distribution... > > Please, /show/ how to make it better. /Tell/ where or how the workflow > > could be streamlined. "More branches" just makes for a swampy river delta, > > not smoother flow AFAIKS. > You probably can't match RHEL's QA for free, but testing - and not > shipping things that don't pass - is the only way things can get > better. Pray tell us, exactly how do we /do/ that? I think we all agree that that is the ideal, but I strongly believe it is unatainable in pratice. > >>> I'd say the fact that we are discussing this shows that the qualility > >>> is at least decent enough for serious consideration. > >> Certainly - Otherwise, I wasn't be using Fedora. > > It's certainly not perfect, but good enough for me (and fun to > > booth!). > I've heard the term used as in "an instrument's tuning is 'good > enough' for folk music" or "an approximation is 'good enough' for > government work". What's 'good enough' for an operating system? Works mostly. Doesn't crash too often. Doesn't destroy valuable data except under extremely unlikely circumstances. What "mostly", "too often", "extremely unlikely" mean in the above is up to the beholder. Yes, and ideal system won't ever do any of the above, but then the machine could get hit by a meteorite. Yes, there are systems that provably approach the above ideal, but they are extremely limited (so much that you'd yearn for the lush MS-DOS environment). This is engineering, not mathematics. And even in mathematics there have been mistakes... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513 From cmadams at hiwaay.net Mon Sep 29 21:59:17 2008 From: cmadams at hiwaay.net (Chris Adams) Date: Mon, 29 Sep 2008 16:59:17 -0500 Subject: unfrozen repo somewhere? In-Reply-To: <48E14D0E.5080304@gmail.com> References: <1222659465.3564.332.camel@beck.corsepiu.local> <200809290437.m8T4bAAH011491@laptop14.inf.utfsm.cl> <1222666171.3564.392.camel@beck.corsepiu.local> <200809291759.m8THx1lf004358@laptop14.inf.utfsm.cl> <1222715259.7795.5.camel@arekh.okg> <48E129F6.5080801@gmail.com> <1222720161.23360.2.camel@luminos.localdomain> <48E140F6.80608@gmail.com> <1222722648.23360.6.camel@luminos.localdomain> <48E14D0E.5080304@gmail.com> Message-ID: <20080929215917.GA1188670@hiwaay.net> Once upon a time, Les Mikesell said: > So far I haven't seen anything in release notes that looks anywhere near > as convenient as downloading a ready to run vmware image. The process > to create a bootable USB looks like it requires a already-installed > system, and I don't see any estimate of the disk space and time it will > waste to do the 'install to hard drive' in a VM to get a writable > system. I've also always had to track down hacks to make vmware tools > work when I wanted to run fedora under vmware - is that still a problem? With qemu/qemu-kvm, you can download and run the LiveCD ISO image with "-cdrom /path/to/image.iso -boot d". If vmware makes it harder than that, then I'd say you should give an Open Source virtualization tool a try. If you really want to make a disk image to run from, you can set up an empty disk image file (allow several gig, but the qemu qcow2 image type only uses more-or-less what you use under the virtual image, so you can allow 10G or more and let it grow on demand), boot the ISO image, and transfer to the disk image. That isn't but a couple of extra steps and a few minutes of work (since you don't have to wait for CD/DVD seeks). The only "wasted" space is the ISO image (and if 700M is too much space for you, you probably don't have enough free space to run the virtual image anyway). So: qemu-img create -f qcow2 liveinst.img 10G sudo qemu-kvm -m 1024 -hda liveinst.img -cdrom /path/to/livecd.iso -boot d [click "transfer to disk" and shut down] rm /path/to/livecd.iso # (if space is at a premium) sudo qemu-kvm -m 1024 -hda liveinst.img -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From mw_triad at users.sourceforge.net Mon Sep 29 23:04:38 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Mon, 29 Sep 2008 18:04:38 -0500 Subject: please deactivate services by default! In-Reply-To: <20080927112026.1238eef7@lain.camperquake.de> References: <1222287197.3941.7.camel@choeger6> <20080924212236.GJ1414283@hiwaay.net> <20080924213113.GK1414283@hiwaay.net> <1222294938.3941.20.camel@choeger6> <1222363259.3941.36.camel@choeger6> <1222377255.4083.5.camel@choeger6> <20080927112026.1238eef7@lain.camperquake.de> Message-ID: Ralf Ertzinger wrote: > On Thu, 25 Sep 2008 23:14:15 +0200, Christoph H?ger wrote >> You are the one talking about obfuscating sender ;) No, its just an ?, >> as in H?ger, my name. This mail should be encoded in utf-8 (hope that >> doesn't break your backup ;) I cannot efford a lawyer), so I assume >> your decoding doesn't work well. > > The header is encoded as ISO-8859-1, quoted printable, and looks fine. > If TB chokes on that you might want to file a bug. Huh. Nope, turns out to be my fault, "apply default encoding" (which never seems to work on message bodies) apparently *does* fiddle with headers. Thanks for the pointer; knowing what to look for made me think to try turning that off, which seems to have fixed it. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Microsoft, electricity, network connectivity. For a secure system pick any two. -- Iain D Broadfoot (paraphrased, from cluefire.net) From lesmikesell at gmail.com Mon Sep 29 23:37:40 2008 From: lesmikesell at gmail.com (Les Mikesell) Date: Mon, 29 Sep 2008 18:37:40 -0500 Subject: unfrozen repo somewhere? In-Reply-To: <200809292257.m8TMvxJC016686@laptop14.inf.utfsm.cl> References: <20080926091109.GF3149@free.fr> <1222425353.3564.248.camel@beck.corsepiu.local> <200809281831.m8SIVjjo005660@laptop14.inf.utfsm.cl> <1222651165.3564.314.camel@beck.corsepiu.local> <200809290238.m8T2cIdQ011245@laptop14.inf.utfsm.cl> <25665.1222660262@sss.pgh.pa.us> <1222663773.3564.355.camel@beck.corsepiu.local> <200809290526.m8T5QPGw012980@laptop14.inf.utfsm.cl> <1222667193.3564.406.camel@beck.corsepiu.local> <200809291839.m8TIdTKk004426@laptop14.inf.utfsm.cl> <48E12763.6020200@gmail.com> <200809292257.m8TMvxJC016686@laptop14.inf.utfsm.cl> Message-ID: <48E166C4.10600@gmail.com> Horst H. von Brand wrote: > >> It's not the developer's fault that you _ship_ new bugs. > > OK, packager's fault in that case then. More realistically, the packager not having encountered the bug. >> Just don't ship them. > > If you have some sort of bug-detector that I can wave over packages before > letting them loose... Large numbers of testers are the best way. There's nothing quite like the real world. >> You probably can't match RHEL's QA for free, but testing - and not >> shipping things that don't pass - is the only way things can get >> better. > > Pray tell us, exactly how do we /do/ that? I think we all agree that that > is the ideal, but I strongly believe it is unatainable in pratice. The big problem for me is that it's a package deal. I wouldn't mind beta testing a few apps at a time on my working system with a stable OS and libraries, but to run them you also have to take an experimental kernel and device drivers. And my history with those on fedora is that I waste too much time getting the hardware to work with new versions. Maybe that's changed... If you had a way to separate the apps from the OS, you might find people more willing to test the parts that interested them. >> I've heard the term used as in "an instrument's tuning is 'good >> enough' for folk music" or "an approximation is 'good enough' for >> government work". What's 'good enough' for an operating system? > > Works mostly. Doesn't crash too often. Doesn't destroy valuable data except > under extremely unlikely circumstances. Kernels that don't boot on machines where the last version worked or lose the ability to access devices like firewire drives isn't 'mostly' enough for me. > This is engineering, not mathematics. And even in mathematics there have > been mistakes... But would you want to test a plane where the engineers said it was probably good enough and didn't crash too often? -- Les Mikesell lesmikesell at gmail.com From stickster at gmail.com Mon Sep 29 23:53:17 2008 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 29 Sep 2008 19:53:17 -0400 Subject: [Fedora-spins] F11 Spins process refinement In-Reply-To: <48E15CA5.3020209@redhat.com> References: <1222725435.23360.14.camel@luminos.localdomain> <48E15CA5.3020209@redhat.com> Message-ID: <20080929235307.GD13015@victoria-eth.internal.frields.org> On Mon, Sep 29, 2008 at 03:54:29PM -0700, John Poelstra wrote: > Jon Stanley said the following on 09/29/2008 03:04 PM Pacific Time: >> On Mon, Sep 29, 2008 at 5:57 PM, Jesse Keating wrote: >> >>> If I haven't missed it, I can show up on behalf of either of these >>> groups. >> >> Nope, you haven't missed it - since it didn't happen last week I'd >> like it to happen at some point this week. Just need a time that works >> for everyone. I'll throw out Wednesday at 1600UTC (noon Eastern, 9 >> pacific) as a starting point for discussion. >> > > I can make it. I suggest people log in to gobby in advance in case we > want to do some collaborative note taking. I have it down on my calendar now, too. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wtogami at redhat.com Tue Sep 30 02:53:24 2008 From: wtogami at redhat.com (Warren Togami) Date: Mon, 29 Sep 2008 22:53:24 -0400 Subject: NetworkManager-vpnc gnome-keyring problem after F9 update Message-ID: <48E194A4.1010408@redhat.com> Today I did a pile of F9 updates for the first time since September 13th. The update log is attached. After rebooting I found that NetworkManager caused gnome-keyring to pop-up those "Always Allow" dialogs for all keys that it wanted to access. I had to click "Always Allow" on every key again. It successfully connected to WPA, but failed immediately to connect using NetworkManager-vpnc. /var/log/messages contains the following as I attempted to connect with vpnc a few times in a row. Sep 29 22:18:02 newcaprica NetworkManager: Starting VPN service 'org.freedesktop.NetworkManager.vpnc'... Sep 29 22:18:02 newcaprica NetworkManager: VPN service 'org.freedesktop.NetworkManager.vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 5152 Sep 29 22:18:02 newcaprica NetworkManager: VPN service 'org.freedesktop.NetworkManager.vpnc' just appeared, activating connections Sep 29 22:18:05 newcaprica NetworkManager: VPN plugin state changed: 3 Sep 29 22:18:05 newcaprica NetworkManager: VPN connection 'RHVPN' (Connect) reply received. Sep 29 22:18:05 newcaprica NetworkManager: VPN plugin state changed: 6 Sep 29 22:18:05 newcaprica NetworkManager: connection_state_changed(): Could not process the request because no VPN connection was active. Sep 29 22:18:09 newcaprica NetworkManager: VPN plugin state changed: 3 Sep 29 22:18:09 newcaprica NetworkManager: VPN connection 'RHVPN' (Connect) reply received. Sep 29 22:18:09 newcaprica NetworkManager: VPN plugin state changed: 6 Sep 29 22:18:09 newcaprica NetworkManager: connection_state_changed(): Could not process the request because no VPN connection was active. Sep 29 22:18:13 newcaprica NetworkManager: VPN plugin state changed: 3 Sep 29 22:18:13 newcaprica NetworkManager: VPN connection 'RHVPN' (Connect) reply received. Sep 29 22:18:13 newcaprica NetworkManager: VPN plugin state changed: 6 Sep 29 22:18:13 newcaprica NetworkManager: connection_state_changed(): Could not process the request because no VPN connection was active. Sep 29 22:18:35 newcaprica console-kit-daemon[2830]: WARNING: Couldn't read /proc/4855/environ: Error reading file '/proc/4855/environ': No such process Then I ran gnome-keyring-manager and this weird message showed up. Sep 29 22:25:08 newcaprica gnome-keyring-daemon[4626]: couldn't allocate secure memory to keep passwords and or keys from being written to the disk I eventually figured out that if I deleted the password key from gnome-keyring-manager, then NetworkManager-vpnc's next attempt asked me for a new password. Upon typing the new password it succeeded and is working now. I am posting this here because I do not have time to attempt to reproduce the problem and write a useful detailed bug report. I hope others who see similar bad behavior can share their experiences and someone else can write a detailed report from this. Warren Togami wtogami at redhat.com -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: SEPT29updates.txt URL: From fedora at leemhuis.info Tue Sep 30 04:55:28 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 30 Sep 2008 06:55:28 +0200 Subject: No dynamic groups in PackageKit In-Reply-To: <1222725321.23360.13.camel@luminos.localdomain> References: <48D542A9.1070600@leemhuis.info> <48D5552C.1000700@fedoraproject.org> <48D63D1E.4070806@leemhuis.info> <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <48D726C0.4060208@leemhuis.info> <1222066065.19471.6.camel@rousalka.okg> <1222072903.3330.3.camel@hughsie-work> <1222107615.4108.23.camel@luminos.localdomain> <1222115665.24063.14.camel@hughsie-work> <1222150606.30758.65.camel@code.and.org> <48D897E6.4090600@googlemail.com> <48D923A0.4060001@leemhuis.info> <1222190549.4108.69.camel@luminos.localdomain> <48D92CE6.5000402@leemhuis.info> <1222192700.4108.74.camel@luminos.localdomain> <48D93237.5080101@leemhuis.info> <48D9397A.2060803@leemhuis.info> <1222725321.23360.13.camel@luminos.localdomain> Message-ID: <48E1B140.60703@leemhuis.info> On 29.09.2008 23:55, Jesse Keating wrote: > On Tue, 2008-09-23 at 20:46 +0200, Thorsten Leemhuis wrote: >> Done, but only for the "free" repo for now; new comps can be found for >> review in CVS for RPM Fusion: >> http://cvs.rpmfusion.org/viewvc/comps/comps-f10.xml.in?root=free&view=markup >> File is on the way to the repo and should be available at >> http://download1.rpmfusion.org/free/fedora/development//os/comps.xml >> in a few minutes. >> James, Jesse, does that look like it should look like? > > I think so. The real test is what does yum/anaconda see with these > repos. Ideally it'd just be one instance of each group, with all the > right content of the combined repos. > [...] Thx for your comments Jesse. I'll give it a try over the next few days when I got some other things for RPM Fusion sorted out. If somebody else wants to try what happens in anaconda right now: go for it! CU knurd From denis at poolshark.org Tue Sep 30 06:53:06 2008 From: denis at poolshark.org (Denis Leroy) Date: Tue, 30 Sep 2008 08:53:06 +0200 Subject: NetworkManager-vpnc gnome-keyring problem after F9 update In-Reply-To: <48E194A4.1010408@redhat.com> References: <48E194A4.1010408@redhat.com> Message-ID: <48E1CCD2.1060704@poolshark.org> Warren Togami wrote: > Today I did a pile of F9 updates for the first time since September > 13th. The update log is attached. > > After rebooting I found that NetworkManager caused gnome-keyring to > pop-up those "Always Allow" dialogs for all keys that it wanted to > access. I had to click "Always Allow" on every key again. It > successfully connected to WPA, but failed immediately to connect using > NetworkManager-vpnc. Got burned by the same problem. Unfortunately I didn't catch it while it was in updates-testing as the "newkey" fedora release update disabled my testing repo silently... From mike at miketc.net Tue Sep 30 07:16:38 2008 From: mike at miketc.net (Mike Chambers) Date: Tue, 30 Sep 2008 02:16:38 -0500 Subject: Boot.iso in 64bit rawhide dir Message-ID: <1222758998.7351.2.camel@scrappy.miketc.net> I don't see an images dir (another one missing too, just don't recall the name of it) with the boot.iso in the 64bit rawhide dir. I do see one in the 386 dir though. Are we suppose to use the 386 one even for 64bit or do we need to wait for a good build and use the one for 64? -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From seg at haxxed.com Tue Sep 30 07:30:54 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 30 Sep 2008 02:30:54 -0500 Subject: Computerized Adaptive Math Program In-Reply-To: <48E13920.90200@redhat.com> References: <48E10BDA.6030706@gmail.com> <48E13920.90200@redhat.com> Message-ID: <1222759854.3549.7.camel@localhost.localdomain> On Mon, 2008-09-29 at 16:22 -0400, Michael DeHaan wrote: > Christopher David Desjardins wrote: > > Hi, > > that I develop to be adaptive and essentially create an artificial > > intelligence where the software learns to adapt more to the student > > and gives them more individualized instruction with the hope that this > > would increase student achievement. > > > > They tried this in Ender's game, it could be /really/ dangerous. Or for a more constructive story see The Diamond Age. Which should be required reading for OLPC developers if it isn't already. http://en.wikipedia.org/wiki/Diamond_Age -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From mls at suse.de Tue Sep 30 08:39:26 2008 From: mls at suse.de (Michael Schroeder) Date: Tue, 30 Sep 2008 10:39:26 +0200 Subject: How important is comps.xml to us these days? Which packages should be in comps.xml and which not? In-Reply-To: <1222172628.3265.65.camel@hughsie-work> References: <48D63F92.8000608@leemhuis.info> <48D67ED6.6040405@googlemail.com> <1222073364.3330.11.camel@hughsie-work> <1222156546.3265.13.camel@hughsie-work> <20080923080112.GA32652@suse.de> <1222157510.3265.16.camel@hughsie-work> <1222172342.4144.2.camel@rosebud> <1222172628.3265.65.camel@hughsie-work> Message-ID: <20080930083926.GB7304@suse.de> On Tue, Sep 23, 2008 at 01:23:48PM +0100, Richard Hughes wrote: > On Tue, 2008-09-23 at 08:19 -0400, seth vidal wrote: > > > > it's rhughes.fedorapeople.org > > > > and your quota is now raised to 400M > > Legend, thanks. I'll upload this afternoon. Any progress on the upload? Thanks, Michael. -- Michael Schroeder mls at suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} From rjones at redhat.com Tue Sep 30 09:09:56 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 30 Sep 2008 10:09:56 +0100 Subject: Sourceforge URLs (was: Re: Fever spamming) In-Reply-To: References: <668bb39a0809271600u4dc1a943x697acb022f1d7472@mail.gmail.com> Message-ID: <20080930090956.GA10598@amd.home.annexia.org> On Sun, Sep 28, 2008 at 01:12:35AM +0000, Kevin Kofler wrote: > I wrote: > > Anything we can do about that? > > Actually, I figured out a solution myself: You have to provide a showfiles link > with both a group_id and a package_id, e.g.: > http://sourceforge.net/project/showfiles.php?group_id=2917&package_id=2867 > instead of the previously used: > http://prdownloads.sourceforge.net/z88dk > format which redirects to just: > http://sourceforge.net/project/showfiles.php?group_id=2917 > which brings up the "simplified" layout which hides all the important > information. Ugh, I didn't realise it was this complicated ... Unfortunately a lot of these MinGW packages are hosted on SourceForge. Is the (draft) policy below still correct? https://fedoraproject.org/wiki/PackagingDrafts/SourceUrl#Sourceforge.net Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ From opensource at till.name Tue Sep 30 09:22:09 2008 From: opensource at till.name (Till Maas) Date: Tue, 30 Sep 2008 11:22:09 +0200 Subject: Sourceforge URLs (was: Re: Fever spamming) In-Reply-To: <20080930090956.GA10598@amd.home.annexia.org> References: <668bb39a0809271600u4dc1a943x697acb022f1d7472@mail.gmail.com> <20080930090956.GA10598@amd.home.annexia.org> Message-ID: <200809301122.25051.opensource@till.name> On Tue September 30 2008, Richard W.M. Jones wrote: > Ugh, I didn't realise it was this complicated ... Unfortunately a lot > of these MinGW packages are hosted on SourceForge. Is the (draft) > policy below still correct? > > https://fedoraproject.org/wiki/PackagingDrafts/SourceUrl#Sourceforge.net The final policy is located here: https://fedoraproject.org/wiki/Packaging/SourceURL Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From kevin.kofler at chello.at Tue Sep 30 09:44:27 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 30 Sep 2008 09:44:27 +0000 (UTC) Subject: Sourceforge URLs (was: Re: Fever spamming) References: <668bb39a0809271600u4dc1a943x697acb022f1d7472@mail.gmail.com> <20080930090956.GA10598@amd.home.annexia.org> Message-ID: Richard W.M. Jones redhat.com> writes: > Ugh, I didn't realise it was this complicated ... Unfortunately a lot > of these MinGW packages are hosted on SourceForge. Is the (draft) > policy below still correct? The source URLs in the packaging guidelines (i.e. what ends up in specfiles) still work fine. What needs to be fixed is the file list URLs used in FEver. This only affects FEver. Kevin Kofler From rawhide at fedoraproject.org Tue Sep 30 10:13:56 2008 From: rawhide at fedoraproject.org (Rawhide Report) Date: Tue, 30 Sep 2008 10:13:56 +0000 (UTC) Subject: rawhide report: 20080930 changes Message-ID: <20080930101356.E15E01F825C@releng2.fedora.phx.redhat.com> New package expendable Home finances modeling program New package gflags Library for commandline flag processing New package memtester Utility to test for faulty memory subsystem New package myanmar3-unicode-fonts Myanmar3 unicode font New package perl-File-Find-Rule-VCS Exclude files/directories for Version Control Systems New package perl-Module-Extract Base class for working with Perl distributions New package perl-Module-Manifest Parse and examine a Perl distribution MANIFEST file New package perl-Probe-Perl Information about the currently running perl New package php-manual-en Documentation for the PHP programming language Removed package pidgin-facebookchat Updated Packages: PackageKit-0.3.5-1.fc10 ----------------------- * Mon Sep 29 18:00:00 2008 Richard Hughes - 0.3.5-1 - New upstream version - Add a helper which can be used by GStreamer to install codecs. anyremote-4.9-1.fc10 -------------------- * Mon Sep 29 18:00:00 2008 Mikhail Fedotov - 4.9-1 - Get(version) command was introduced. Added possibility to create user-specific phone initialization. anyremote2html-0.6-1.fc10 ------------------------- * Mon Sep 29 18:00:00 2008 Mikhail Fedotov - 0.6 - New icon set. audio-entropyd-1.0.5-1.fc10 --------------------------- * Sun Sep 28 18:00:00 2008 Tom "spot" Callaway - 1.0.5-1 - update to 1.0.5 - drop debug patch, upstream fixed the problem in a different manner - add config file and fix initscript to use it (bz 463904) bluez-4.9-1.fc10 ---------------- * Mon Sep 29 18:00:00 2008 - Bastien Nocera - 4.9-1 - Update to 4.9 * Mon Sep 29 18:00:00 2008 - Bastien Nocera - 4.8-1 - Update to 4.8 bluez-gnome-1.6-1.fc10 ---------------------- * Mon Sep 29 18:00:00 2008 - Bastien Nocera - 1.6-1 - Update to 1.6 * Mon Sep 29 18:00:00 2008 - Bastien Nocera - 1.5-2 - Add another patch for Bluetooth sendto support for BlueZ 4.x cairo-dock-1.6.3-0.1.svn1325_trunk.fc10 --------------------------------------- * Tue Sep 30 18:00:00 2008 Mamoru Tasaka - rev 1325 cjkunifonts-0.2.20080216.1-3.fc10 --------------------------------- * Tue Sep 30 18:00:00 2008 Caius Chance - 0.2.20080216.1-3.fc10 - Resolves: rhbz#459680 (repatched) * Mon Sep 29 18:00:00 2008 Caius Chance - 0.2.20080216.1-2.fc10 - Resolves: rhbz#459680 (qt/kde: font antialiasing was disabled by uming fontconfig file.) cmake-2.6.2-1.fc10 ------------------ * Mon Sep 29 18:00:00 2008 Orion Poplawski - 2.6.2-1 - Update to 2.6.2 coreutils-6.12-10.fc10 ---------------------- * Mon Sep 29 18:00:00 2008 Ondrej Vasik - 6.12-10 - seq should no longer fail to display final number of some float usages of seq with utf8 locales(#463556) crystalspace-1.2-8.fc10 ----------------------- * Mon Sep 29 18:00:00 2008 Lubomir Rintel 1.2-8 - Rebuild for new libode dhcp-4.0.0-25.fc10 ------------------ * Mon Sep 29 18:00:00 2008 David Cantrell - 12:4.0.0-25 - Fix dhcpd so it can find configuration data via LDAP (#452985) elinks-0.12-0.5.pre2.fc10 ------------------------- * Mon Sep 29 18:00:00 2008 Ondrej Vasik 0.12-0.5.pre2 - new upstream bugfix prerelease - Removed already applied patches for tabreload and bittorrent emacs-vm-8.0.11.581-2.fc10 -------------------------- * Mon Sep 29 18:00:00 2008 Jonathan G. Underwood - 8.0.11.581-2 - Add vm-revno.el to lisp files epiphany-extensions-2.24.0-1.fc10 --------------------------------- * Mon Sep 29 18:00:00 2008 Peter Gordon - 2.24.0-1 - Update to new upstream release (2.24.0) * Wed Sep 24 18:00:00 2008 Christopher Aillon - 2.23.91-2 - Rebuild against newer gecko factory-3.0.3-4.fc10 -------------------- * Mon Sep 29 18:00:00 2008 Rex Dieter 3.0.3-4 - multiarch fix (sparc) fedora-ds-base-1.1.3-3.fc10 --------------------------- * Mon Sep 29 18:00:00 2008 Rich Megginson - 1.1.3-3 - added patch bug463991-bdb47.patch - make ds work with bdb 4.7 * Wed Sep 24 18:00:00 2008 Rich Megginson - 1.1.3-2 - rolled back bogus winsync memory leak fix * Tue Sep 23 18:00:00 2008 Rich Megginson - 1.1.3-1 - winsync api improvements for modify operations * Fri Jun 13 18:00:00 2008 Rich Megginson - 1.1.2-1 - This is the 1.1.2 release. The bugs fixed can be found here - https://bugzilla.redhat.com/showdependencytree.cgi?id=452721 - Added winsync-plugin.h to the devel subpackage filezilla-3.1.3.1-1.fc10 ------------------------ * Mon Sep 29 18:00:00 2008 kwizart < kwizart at gmail.com > - 3.1.3.1-1 - Update to 3.1.3.1 gedit-plugins-2.22.3-2.fc10 --------------------------- * Mon Sep 29 18:00:00 2008 Rakesh Pandit - 2.22.3-2 - Fixed buildrequires * Mon Sep 29 18:00:00 2008 Rakesh Pandit - 2.22.3-1 - Updated to 2.22.3 * Mon Sep 29 18:00:00 2008 Rakesh Pandit - 2.22.0-2 - rebuild to pick latest gucharmap gnome-chemistry-utils-0.9.92-1.fc10 ----------------------------------- * Mon Sep 29 18:00:00 2008 Julian Sikorski - 0.9.92-1 - Updated to 0.9.92 - Added hicolor-icon-theme to Requires gnome-packagekit-0.3.5-1.fc10 ----------------------------- grace-5.1.22-1.fc10 ------------------- * Mon Sep 29 18:00:00 2008 Jos?? Matos - 5.1.22-1 - new upstream release (5.1.22) - apply debian patches with -p1 groff-1.18.1.4-15.fc10 ---------------------- * Mon Sep 29 18:00:00 2008 Stepan Kasal - 1.18.1.14-15 - Replace groff-1.18-nohtml.patch by a code in spec file - fix groff-1.18-gzip.patch to apply cleanly - simplify the code for symlinking in %install gvfs-1.0.1-2.fc10 ----------------- * Mon Sep 29 18:00:00 2008 - Bastien Nocera - 1.0.1-2 - Update obexftp patch from upstream gwibber-0.7-5.102bzr.fc10 ------------------------- * Mon Sep 29 18:00:00 2008 Ian Weller 0.7-5.102bzr - Requires: mx hunspell-es-0.20051031-3.fc10 ----------------------------- * Mon Sep 29 18:00:00 2008 Caolan McNamara - 0.20051031-3 - add es_CU as Cuba for OOo ibus-0.1.1.20080930-1.fc10 -------------------------- * Tue Sep 30 18:00:00 2008 Huang Peng - 0.1.1.20080930-1 - Update to 0.1.1.20080930. * Tue Sep 23 18:00:00 2008 Huang Peng - 0.1.1.20080923-1 - Update to 0.1.1.20080923. imsettings-0.104.1-2.fc10 ------------------------- * Mon Sep 29 18:00:00 2008 Akira TAGOH - 0.104.1-2 - Fix a gconf error in %pre. (#464453) jd-2.0.3-0.1.svn2378_trunk.fc10 ------------------------------- * Tue Sep 30 18:00:00 2008 Mamoru Tasaka - rev 2378 kdeaccessibility-4.1.2-2.fc10 ----------------------------- * Mon Sep 29 18:00:00 2008 Rex Dieter 4.1.2-2 - make VERBOSE=1 - respin against new(er) kde-filesystem kdeadmin-4.1.2-3.fc10 --------------------- * Mon Sep 29 18:00:00 2008 Rex Dieter 4.1.2-3 - make VERBOSE=1 - respin against new(er) kde-filesystem kdeartwork-4.1.2-2.fc10 ----------------------- * Mon Sep 29 18:00:00 2008 Rex Dieter 4.1.2-2 - make VERBOSE=1 - respin against new(er) kde-filesystem kdebase-4.1.2-2.fc10 -------------------- * Mon Sep 29 18:00:00 2008 Rex Dieter 4.1.2-2 - make VERBOSE=1 - respin against new(er) kde-filesystem kdebase-runtime-4.1.2-2.fc10 ---------------------------- * Sun Sep 28 18:00:00 2008 Rex Dieter 4.1.2-2 - make VERBOSE=1 - respin against new(er) kde-filesystem - grow -libs, kde4 styles are unavailable for i386 applications (#456826) kdebindings-4.1.2-2.fc10 ------------------------ * Mon Sep 29 18:00:00 2008 Rex Dieter 4.1.2-2 - make VERBOSE=1 - respin against new(er) kde-filesystem kdeedu-4.1.2-2.fc10 ------------------- * Mon Sep 29 18:00:00 2008 Rex Dieter 4.1.2-2 - make VERBOSE=1 - respin against new(er) kde-filesystem kdegames-4.1.2-2.fc10 --------------------- * Mon Sep 29 18:00:00 2008 Rex Dieter 4.1.2-2 - make VERBOSE=1 - respin against new(er) kde-filesystem kdegraphics-4.1.2-2.fc10 ------------------------ * Mon Sep 29 18:00:00 2008 Rex Dieter 4.1.2-2 - make VERBOSE=1 - respin against new(er) kde-filesystem kdenetwork-4.1.2-2.fc10 ----------------------- * Mon Sep 29 18:00:00 2008 Rex Dieter 4.1.2-2 - make VERBOSE=1 - respin against new(er) kde-filesystem kdeplasma-addons-4.1.2-2.fc10 ----------------------------- * Mon Sep 29 18:00:00 2008 Rex Dieter 4.1.2-2 - make VERBOSE=1 - respin against new(er) kde-filesystem * Fri Sep 26 18:00:00 2008 Rex Dieter 4.1.2-1 - 4.1.2 kdesdk-4.1.2-2.fc10 ------------------- * Mon Sep 29 18:00:00 2008 Rex Dieter 4.1.2-2 - make VERBOSE=1 - respin against new(er) kde-filesystem kdesvn-1.2.0-0.20080926.1.fc10 ------------------------------ * Mon Sep 29 18:00:00 2008 - Orion Poplawski - 1.2.0-0.20080926.1 - Update to 1.2.0.20080926, KDE4 version * Mon Sep 29 18:00:00 2008 - Orion Poplawski - 1.0.2-1 - Update to 1.0.2 - Add BR sqlite-devel needed for Qt3 build kdetoys-4.1.2-2.fc10 -------------------- * Mon Sep 29 18:00:00 2008 Rex Dieter 4.1.2-2 - make VERBOSE=1 - respin against new(er) kde-filesystem kdeutils-4.1.2-3.fc10 --------------------- * Mon Sep 29 18:00:00 2008 Rex Dieter 4.1.2-3 - make VERBOSE=1 - respin against new(er) kde-filesystem kernel-2.6.27-0.370.rc8.fc10 ---------------------------- * Mon Sep 29 18:00:00 2008 Roland McGrath - 2.6.27-rc8 * Mon Sep 29 18:00:00 2008 Dave Jones - Turn off CONFIG_USB_DEBUG. It's noisy, and of no real value right now. * Mon Sep 29 18:00:00 2008 Dave Jones - Kill of config-ia64. for real this time. * Mon Sep 29 18:00:00 2008 Adam Jackson - Kill the useless "Kernel alive" early_printk()'s * Sun Sep 28 18:00:00 2008 Chuck Ebbert - make XEN__SAVE_RESTORE denpend on XEN * Fri Sep 26 18:00:00 2008 Dave Jones - 2.6.27-rc7-git5 * Thu Sep 25 18:00:00 2008 Peter Jones - Remove i8042 "No controller found." noise. * Thu Sep 25 18:00:00 2008 Dave Jones - Drop duplicated eeepc sata patch. * Thu Sep 25 18:00:00 2008 Dave Jones - Drop a bunch of unused/old patches. Rediff & Reapply PPC32/Sparc SELinux mprotect patches. * Thu Sep 25 18:00:00 2008 Dave Jones - Disable the BT_HCIUSB driver. It sucks more power than BT_HCIBTUSB which has the same functionality. kipi-plugins-0.2.0-0.2.beta1.fc10 --------------------------------- * Mon Sep 29 18:00:00 2008 Rex Dieter 0.2.0-0.2.beta1 - respin (against newer kdegraphics) kphotoalbum-3.2-0.2.20080929svn.fc10 ------------------------------------ * Mon Sep 29 18:00:00 2008 Rex Dieter 3.2-0.2.20080929svn - respin against newer kdegraphics - kphotoalbum-20080929svn snapshot libsigsegv-2.4-7.fc10 --------------------- * Mon Sep 29 18:00:00 2008 Rex Dieter 2.4-7 - multilib (sparc) fixes mesa-7.2-0.3.fc10 ----------------- * Mon Sep 29 18:00:00 2008 Adam Jackson 7.2-0.3 - Add xdriinfo. (#464388) mod_wsgi-2.1-2.fc10 ------------------- * Mon Sep 29 18:00:00 2008 James Bowes 2.1-2 - Remove requires on httpd-devel mozvoikko-0.9.5-3.fc10 ---------------------- * Mon Sep 29 18:00:00 2008 Ville-Pekka Vainio - 0.9.5-3 - Rebuild against newer gecko net-tools-1.60-90.fc10 ---------------------- * Thu Sep 25 18:00:00 2008 Zdenek Prikryl - 1.60-90 - fixed ifconfig's man page (#454271, #432328) ntl-5.4.2-3.fc10 ---------------- * Mon Sep 29 18:00:00 2008 Rex Dieter 5.4.2-3 - multilib fixes numactl-2.0.2-2.fc10 -------------------- * Mon Sep 29 18:00:00 2008 Neil Horman - 2.0.2-2 - Fix build break due to register selection in asm * Mon Sep 29 18:00:00 2008 Neil Horman - 2.0.2-1 - Update rawhide to version 2.0.2 of numactl obex-data-server-0.3.99-1.fc10 ------------------------------ * Mon Sep 29 18:00:00 2008 - Bastien Nocera - 0.3.99-1 - Update to rev 1977 openoffice.org-3.0.0-8.1.fc10 ----------------------------- * Sun Sep 28 18:00:00 2008 Caol??n McNamara - 1:3.0.0-8.1 - next candidate - Resolves: rhbz#463884 openoffice.org-3.0.0.ooo94318.greekmenu.crash - Resolves: rhbz#464109 lohit-fonts-marathi oprofile-0.9.4-3.fc10 --------------------- * Mon Sep 29 18:00:00 2008 Dennis Gilmore - 0.9.4-3 - build sparcv9 not sparc python-biopython-1.48-1.fc10 ---------------------------- * Mon Sep 29 18:00:00 2008 Alex Lancaster - 1.48-1 - Update to latest upstream (1.48) pytrainer-1.6.0.5-3.fc10 ------------------------ * Mon Sep 29 18:00:00 2008 Douglas E. Warner 1.6.0.5-3 - fixing gecko-libs requirement rcssserver3d-0.6-5.fc10 ----------------------- * Mon Sep 29 18:00:00 2008 Hedayat Vatankhah 0.6-5 - Rebuilding the package to use ODE 0.10. - Added dInitODE patch for physicsserver.cpp revisor-2.1.1-7.fc10 -------------------- * Mon Sep 29 18:00:00 2008 Jeroen van Meeuwen 2.1.1-7 - Latest rebuild - Minor bugfixes (#344 pkgorder traceback) - Add SELinux Check sepostgresql-8.3.4-2.1067.fc10 ------------------------------ * Sat Sep 27 18:00:00 2008 - 8.3.3-2.1066 - update base version to 8.3.4 - sepostgresql.pp was marked as obsolute * Tue Sep 23 18:00:00 2008 - 8.3.3-2.1043 - bugfix: a case when INSERT a FK reference to invisible PK sqlite-3.5.9-2.fc10 ------------------- * Mon Sep 22 18:00:00 2008 Panu Matilainen - 3.5.9-2 - Remove references to temporary registers from cache on release (#463061) - Enable loading of external extensions (#457433) squirrelmail-1.4.16-1.fc10 -------------------------- * Mon Sep 29 18:00:00 2008 Michal Hlavinka - 1.4.16-1 * updates to 1.4.16 (fixes CVE-2008-3663) system-config-printer-1.0.8-2.fc10 ---------------------------------- * Mon Sep 29 18:00:00 2008 Tim Waugh 1.0.8-2 - Removed patch (no longer needed). * Mon Sep 29 18:00:00 2008 Tim Waugh 1.0.8-1 - 1.0.8: - Use modelName from custom PPD to suggest name for new printer (trac #97). - Avoid display problem with installable options. - Better matching for Lexmark printers. - Catch exceptions from advanced server settings dialog (Ubuntu - Added some missing OpenPrinting query fields. - Jockey support added. - Lots of translations updated. tclx-8.4.0-12.fc10 ------------------ * Mon Sep 29 18:00:00 2008 Marcela Ma??l????ov?? - 8.4.0-12 - review, thanks for help to Patrice Dumas * Tue Sep 23 18:00:00 2008 Marcela Maslanova - 8.4.0-11 - change macros telepathy-gabble-0.7.9-1.fc10 ----------------------------- * Mon Sep 29 18:00:00 2008 Brian Pepple - 0.7.9-1 - Update to 0.7.9. time-1.7-34.fc10 ---------------- * Sun Sep 21 18:00:00 2008 Ville Skytt?? - 1.7-34 - Fix Patch:/%patch0 mismatch. Resolves: #463067 workrave-1.9.0-1.fc10 --------------------- * Fri Sep 26 18:00:00 2008 Tomas Mraz - 1.9.0-1 - new upstream version wxPython-2.8.9.0-1.fc10 ----------------------- * Mon Sep 29 18:00:00 2008 Dan Horak - 2.8.9.0-1 - update to 2.8.9.0 xfce4-dict-0.4.1-2.fc10 ----------------------- * Tue Sep 30 18:00:00 2008 Christoph Wickert - 0.4.1-2 - BuildRequire intltool * Tue Sep 30 18:00:00 2008 Christoph Wickert - 0.4.1-1 - Update to 0.4.1 - Require xdg-utils as xdg-open is the preferred command to open URLs now xorg-x11-drv-ati-6.9.0-20.fc10 ------------------------------ * Mon Sep 29 18:00:00 2008 Dave Airlie 6.9.0-20 - fix collision with copy fb contents patch * Mon Sep 29 18:00:00 2008 Dave Airlie 6.9.0-19 - fix textured video + merge otaylor fix into exa fixes patch Summary: Added Packages: 9 Removed Packages: 1 Modified Packages: 72 Broken deps for i386 ---------------------------------------------------------- ant-manual-1.7.1-7.1.fc10.i386 requires perl(the) beagle-evolution-0.3.8-6.fc10.i386 requires mono(evolution-sharp) = 0:3.0.0.0 gtkmozembedmm-1.4.2.cvs20060817-21.fc10.i386 requires gecko-libs = 0:1.9.0.1 lvm2-cluster-2.02.39-3.fc10.i386 requires libcman.so.2 lvm2-cluster-2.02.39-3.fc10.i386 requires libdlm.so.2 machineball-1.0-5.fc9.i386 requires libode.so.0 ppl-swiprolog-0.9-24.fc10.i386 requires libpl.so.5.6.57 pyclutter-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.i386 requires libclutter-gtk-0.6.so.0 python-pyblock-0.31-4.i386 requires libdmraid.so.1.0.0.rc14(Base) python-pyblock-0.31-4.i386 requires libdmraid.so.1.0.0.rc14 raydium-1.2-9.fc10.i386 requires libode.so.0 ruby-rpm-1.2.3-4.fc9.i386 requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.i386 requires librpmbuild-4.4.so stormbaancoureur-2.1.4-1.fc10.i386 requires libode.so.0 xmoto-0.4.2-2.fc10.i386 requires libode.so.0 Broken deps for x86_64 ---------------------------------------------------------- ant-manual-1.7.1-7.1.fc10.x86_64 requires perl(the) beagle-evolution-0.3.8-6.fc10.x86_64 requires mono(evolution-sharp) = 0:3.0.0.0 gtkmozembedmm-1.4.2.cvs20060817-21.fc10.i386 requires gecko-libs = 0:1.9.0.1 gtkmozembedmm-1.4.2.cvs20060817-21.fc10.x86_64 requires gecko-libs = 0:1.9.0.1 lvm2-cluster-2.02.39-3.fc10.x86_64 requires libcman.so.2()(64bit) lvm2-cluster-2.02.39-3.fc10.x86_64 requires libdlm.so.2()(64bit) machineball-1.0-5.fc9.x86_64 requires libode.so.0()(64bit) ppl-swiprolog-0.9-24.fc10.x86_64 requires libpl.so.5.6.57()(64bit) pyclutter-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.x86_64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.x86_64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.x86_64 requires libclutter-gtk-0.6.so.0()(64bit) python-pyblock-0.31-4.x86_64 requires libdmraid.so.1.0.0.rc14(Base)(64bit) python-pyblock-0.31-4.x86_64 requires libdmraid.so.1.0.0.rc14()(64bit) raydium-1.2-9.fc10.i386 requires libode.so.0 raydium-1.2-9.fc10.x86_64 requires libode.so.0()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.x86_64 requires librpmbuild-4.4.so()(64bit) stormbaancoureur-2.1.4-1.fc10.x86_64 requires libode.so.0()(64bit) xmoto-0.4.2-2.fc10.x86_64 requires libode.so.0()(64bit) Broken deps for ppc ---------------------------------------------------------- ant-manual-1.7.1-7.1.fc10.ppc requires perl(the) beagle-evolution-0.3.8-6.fc10.ppc requires mono(evolution-sharp) = 0:3.0.0.0 gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc requires gecko-libs = 0:1.9.0.1 gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc64 requires gecko-libs = 0:1.9.0.1 lvm2-cluster-2.02.39-3.fc10.ppc requires libcman.so.2 lvm2-cluster-2.02.39-3.fc10.ppc requires libdlm.so.2 machineball-1.0-5.fc9.ppc requires libode.so.0 ppl-swiprolog-0.9-24.fc10.ppc requires libpl.so.5.6.57 pyclutter-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-cairo-0.6.so.0 pyclutter-cairo-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-gst-0.6.so.0 pyclutter-gst-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-glx-0.6.so.0 pyclutter-gtk-0.6.2-2.fc9.ppc requires libclutter-gtk-0.6.so.0 python-pyblock-0.31-4.ppc requires libdmraid.so.1.0.0.rc14(Base) python-pyblock-0.31-4.ppc requires libdmraid.so.1.0.0.rc14 raydium-1.2-9.fc10.ppc requires libode.so.0 raydium-1.2-9.fc10.ppc64 requires libode.so.0()(64bit) ruby-rpm-1.2.3-4.fc9.ppc requires librpmdb-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpm-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmio-4.4.so ruby-rpm-1.2.3-4.fc9.ppc requires librpmbuild-4.4.so stapitrace-1.0.0-12.20080622cvs_alpha.fc10.ppc requires libopcodes-2.18.50.0.9-1.fc10.so stapitrace-1.0.0-12.20080622cvs_alpha.fc10.ppc requires libbfd-2.18.50.0.9-1.fc10.so stormbaancoureur-2.1.4-1.fc10.ppc requires libode.so.0 xmoto-0.4.2-2.fc10.ppc requires libode.so.0 Broken deps for ppc64 ---------------------------------------------------------- ant-manual-1.7.1-7.1.fc10.ppc64 requires perl(the) gtkmozembedmm-1.4.2.cvs20060817-21.fc10.ppc64 requires gecko-libs = 0:1.9.0.1 livecd-tools-018-1.fc10.ppc64 requires yaboot lvm2-cluster-2.02.39-3.fc10.ppc64 requires libcman.so.2()(64bit) lvm2-cluster-2.02.39-3.fc10.ppc64 requires libdlm.so.2()(64bit) machineball-1.0-5.fc9.ppc64 requires libode.so.0()(64bit) ppl-swiprolog-0.9-24.fc10.ppc64 requires libpl.so.5.6.57()(64bit) pyclutter-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-cairo-0.6.2-2.fc9.ppc64 requires libclutter-cairo-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gst-0.6.2-2.fc9.ppc64 requires libclutter-gst-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-glx-0.6.so.0()(64bit) pyclutter-gtk-0.6.2-2.fc9.ppc64 requires libclutter-gtk-0.6.so.0()(64bit) python-pyblock-0.31-4.ppc64 requires libdmraid.so.1.0.0.rc14(Base)(64bit) python-pyblock-0.31-4.ppc64 requires libdmraid.so.1.0.0.rc14()(64bit) raydium-1.2-9.fc10.ppc64 requires libode.so.0()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmio-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpm-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmdb-4.4.so()(64bit) ruby-rpm-1.2.3-4.fc9.ppc64 requires librpmbuild-4.4.so()(64bit) stormbaancoureur-2.1.4-1.fc10.ppc64 requires libode.so.0()(64bit) xmoto-0.4.2-2.fc10.ppc64 requires libode.so.0()(64bit) From hughsient at gmail.com Tue Sep 30 10:52:33 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 30 Sep 2008 11:52:33 +0100 Subject: Please recompile GStreamer codecs -- AKA: how to make things just work with PackageKit Message-ID: <1222771953.3291.12.camel@hughsie-laptop> I've been playing with the new code in PackageKit for codec installing with external repos. It was a little disappointed to find some external repos have not recompiled packages with a new gstreamer-devel and rpm. This means packages display this: [hughsie at localhost docs]$ rpm -qp /home/hughsie/gstreamer-ffmpeg-0.10.4-1.rph10.x86_64.rpm --provides libgstffmpeg.so()(64bit) libgstpostproc.so()(64bit) gstreamer-ffmpeg = 0.10.4-1.lvn10 rather than this: [hughsie at localhost docs]$ rpm -qp --provides /home/hughsie/rpmbuild/RPMS/gstreamer-ffmpeg-0.10.4-1.rph10.x86_64.rpm gstreamer0.10(decoder-application/gxf)()(64bit) gstreamer0.10(decoder-application/mxf)()(64bit) gstreamer0.10(decoder-application/ogg)()(64bit) .. a million mode code strings... libgstffmpeg.so()(64bit) libgstpostproc.so()(64bit) gstreamer-ffmpeg = 0.10.4-1.lvn10 All you need to do is recompile, and everything will be done automatically. It would be disappointing to not have this fixed before F10. Thanks, Richard. From fedora at leemhuis.info Tue Sep 30 11:13:41 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 30 Sep 2008 13:13:41 +0200 Subject: Please recompile GStreamer codecs -- AKA: how to make things just work with PackageKit In-Reply-To: <1222771953.3291.12.camel@hughsie-laptop> References: <1222771953.3291.12.camel@hughsie-laptop> Message-ID: <48E209E5.5070705@leemhuis.info> On 30.09.2008 12:52, Richard Hughes wrote: > I've been playing with the new code in PackageKit for codec installing > with external repos. It was a little disappointed to find some external > repos have not recompiled packages with a new gstreamer-devel and rpm. Be sure to not check repos that will be EOL real soon now, as a few package maintainers already stopped updating their packages there; look at the successor repos. Instruction how to use those repos easily were just posted yesterday: http://lists.rpmfusion.org/pipermail/rpmfusion-developers/2008-September/001326.html In short: If you are on rawhide run: rpm -ivh \ http://download1.rpmfusion.org/free/fedora/development/i386/os/rpmfusion-free-release-9.90-2.noarch.rpm \ http://download1.rpmfusion.org/nonfree/fedora/development/i386/os/rpmfusion-nonfree-release-9.90-2.noarch.rpm If you are on F8 or F9: rpm -ivh \ http://download1.rpmfusion.org/nonfree/fedora/updates/testing/8/i386/rpmfusion-nonfree-release-8-2.noarch.rpm \ http://download1.rpmfusion.org/free/fedora/updates/testing/8/i386/rpmfusion-free-release-8-2.noarch.rpm \ Please note that the new repos don't have entries for all their packages in bugzilla.rpmfusion.org yet; thus please file bugs simply against "advancescan" (that the first one in the package list); someone will reassign the bug later. Package owners can also be found in owners.list for the free and nonfree repos: http://cvs.rpmfusion.org/viewvc/owners/owners.list?root=free&view=markup http://cvs.rpmfusion.org/viewvc/owners/owners.list?root=nonfree&view=markup CU knurd P.S.: I plan to stop updating livna-devel real soon now. The plan is to put the rpmfusion-release rpms into the livna devel repo and add a hard dependency on them in a updated livna-release package; that way users that installed livna will normally automatically be moved over to the maintained successor repo From hughsient at gmail.com Tue Sep 30 11:31:30 2008 From: hughsient at gmail.com (Richard Hughes) Date: Tue, 30 Sep 2008 12:31:30 +0100 Subject: Please recompile GStreamer codecs -- AKA: how to make things just work with PackageKit In-Reply-To: <48E209E5.5070705@leemhuis.info> References: <1222771953.3291.12.camel@hughsie-laptop> <48E209E5.5070705@leemhuis.info> Message-ID: <15e53e180809300431h50a7eebk9ff90f445a83095e@mail.gmail.com> On Tue, Sep 30, 2008 at 12:13 PM, Thorsten Leemhuis wrote: > On 30.09.2008 12:52, Richard Hughes wrote: >> >> I've been playing with the new code in PackageKit for codec installing >> with external repos. It was a little disappointed to find some external >> repos have not recompiled packages with a new gstreamer-devel and rpm. > > Be sure to not check repos that will be EOL real soon now, as a few package > maintainers already stopped updating their packages there; look at the > successor repos. Instruction how to use those repos easily were just posted > yesterday: Ahh, thanks. I'll try those now. In some places he repo files mention: download.rpmfusion.org -- shouldn't that be download1.rpmfusion.org? Also, http://download1.rpmfusion.org/free/fedora/development/x86_64/debug/repodata/repomd.xml doesn't seem to exist. Richard. From dcbw at redhat.com Tue Sep 30 11:36:16 2008 From: dcbw at redhat.com (Dan Williams) Date: Tue, 30 Sep 2008 07:36:16 -0400 Subject: NetworkManager-vpnc gnome-keyring problem after F9 update In-Reply-To: <48E194A4.1010408@redhat.com> References: <48E194A4.1010408@redhat.com> Message-ID: <1222774576.2826.1.camel@localhost.localdomain> On Mon, 2008-09-29 at 22:53 -0400, Warren Togami wrote: > Today I did a pile of F9 updates for the first time since September > 13th. The update log is attached. Any AVCs? > After rebooting I found that NetworkManager caused gnome-keyring to > pop-up those "Always Allow" dialogs for all keys that it wanted to > access. I had to click "Always Allow" on every key again. It > successfully connected to WPA, but failed immediately to connect using > NetworkManager-vpnc. > > /var/log/messages contains the following as I attempted to connect with > vpnc a few times in a row. > > Sep 29 22:18:02 newcaprica NetworkManager: Starting VPN service > 'org.freedesktop.NetworkManager.vpnc'... > Sep 29 22:18:02 newcaprica NetworkManager: VPN service > 'org.freedesktop.NetworkManager.vpnc' started > (org.freedesktop.NetworkManager.vpnc), PID 5152 > Sep 29 22:18:02 newcaprica NetworkManager: VPN service > 'org.freedesktop.NetworkManager.vpnc' just appeared, activating connections > Sep 29 22:18:05 newcaprica NetworkManager: VPN plugin state > changed: 3 > Sep 29 22:18:05 newcaprica NetworkManager: VPN connection > 'RHVPN' (Connect) reply received. > Sep 29 22:18:05 newcaprica NetworkManager: VPN plugin state > changed: 6 > Sep 29 22:18:05 newcaprica NetworkManager: > connection_state_changed(): Could not process the request because no VPN > connection was active. > Sep 29 22:18:09 newcaprica NetworkManager: VPN plugin state > changed: 3 > Sep 29 22:18:09 newcaprica NetworkManager: VPN connection > 'RHVPN' (Connect) reply received. > Sep 29 22:18:09 newcaprica NetworkManager: VPN plugin state > changed: 6 > Sep 29 22:18:09 newcaprica NetworkManager: > connection_state_changed(): Could not process the request because no VPN > connection was active. > Sep 29 22:18:13 newcaprica NetworkManager: VPN plugin state > changed: 3 > Sep 29 22:18:13 newcaprica NetworkManager: VPN connection > 'RHVPN' (Connect) reply received. > Sep 29 22:18:13 newcaprica NetworkManager: VPN plugin state > changed: 6 > Sep 29 22:18:13 newcaprica NetworkManager: > connection_state_changed(): Could not process the request because no VPN > connection was active. > Sep 29 22:18:35 newcaprica console-kit-daemon[2830]: WARNING: Couldn't > read /proc/4855/environ: Error reading file '/proc/4855/environ': No > such process > > Then I ran gnome-keyring-manager and this weird message showed up. > > Sep 29 22:25:08 newcaprica gnome-keyring-daemon[4626]: couldn't allocate > secure memory to keep passwords and or keys from being written to the disk > > I eventually figured out that if I deleted the password key from > gnome-keyring-manager, then NetworkManager-vpnc's next attempt asked me > for a new password. Upon typing the new password it succeeded and is > working now. Odd; I will re-test the update on F9. Dan > I am posting this here because I do not have time to attempt to > reproduce the problem and write a useful detailed bug report. I hope > others who see similar bad behavior can share their experiences and > someone else can write a detailed report from this. > > Warren Togami > wtogami at redhat.com > plain text document attachment (SEPT29updates.txt) > Sep 29 12:57:41 Updated: glib2-2.16.6-1.fc9.x86_64 > Sep 29 12:57:42 Updated: libxml2-2.7.1-1.fc9.x86_64 > Sep 29 12:57:44 Updated: alsa-lib-1.0.17-2.fc9.x86_64 > Sep 29 12:57:50 Updated: initscripts-8.76.3-1.x86_64 > Sep 29 12:57:50 Updated: 1:cups-libs-1.3.8-2.fc9.x86_64 > Sep 29 12:57:51 Updated: audit-libs-1.7.5-1.fc9.x86_64 > Sep 29 12:57:56 Updated: poppler-0.8.1-2.fc9.x86_64 > Sep 29 12:57:58 Updated: 8:arts-1.5.10-1.fc9.x86_64 > Sep 29 12:57:59 Updated: 1:enchant-1.4.2-2.fc9.x86_64 > Sep 29 12:58:00 Updated: xen-libs-3.2.0-15.fc9.x86_64 > Sep 29 12:58:01 Updated: sqlite-3.5.9-1.fc9.x86_64 > Sep 29 12:58:01 Updated: poppler-qt4-0.8.1-2.fc9.x86_64 > Sep 29 12:58:03 Updated: glibmm24-2.16.4-1.fc9.x86_64 > Sep 29 12:58:14 Updated: wireshark-1.0.3-1.fc9.x86_64 > Sep 29 12:58:16 Updated: iptables-1.4.1.1-2.fc9.x86_64 > Sep 29 12:58:19 Updated: 12:dhclient-4.0.0-17.fc9.x86_64 > Sep 29 12:58:22 Updated: tomcat5-servlet-2.4-api-5.5.27-0jpp.2.fc9.x86_64 > Sep 29 12:58:23 Updated: iscsi-initiator-utils-6.2.0.870-0.0.fc9.x86_64 > Sep 29 12:58:23 Updated: xorg-x11-xkb-utils-7.2-6.fc9.x86_64 > Sep 29 12:58:25 Updated: postgresql-libs-8.3.4-1.fc9.x86_64 > Sep 29 12:58:26 Installed: libssh2-0.18-7.fc9.x86_64 > Sep 29 12:58:27 Updated: wavpack-4.50.1-2.fc9.x86_64 > Sep 29 12:58:28 Updated: link-grammar-4.3.5-1.fc9.x86_64 > Sep 29 12:58:29 Updated: 12:libdhcp4client-4.0.0-17.fc9.x86_64 > Sep 29 12:58:31 Updated: libchewing-0.3.0.901-0.fc9.x86_64 > Sep 29 12:58:32 Updated: mpfr-2.3.1-1.fc9.x86_64 > Sep 29 12:58:32 Updated: tomcat5-jsp-2.0-api-5.5.27-0jpp.2.fc9.x86_64 > Sep 29 12:58:34 Updated: iptables-ipv6-1.4.1.1-2.fc9.x86_64 > Sep 29 12:58:34 Updated: audit-libs-python-1.7.5-1.fc9.x86_64 > Sep 29 12:58:36 Updated: audit-1.7.5-1.fc9.x86_64 > Sep 29 12:58:38 Updated: alsa-utils-1.0.17-2.fc9.x86_64 > Sep 29 12:59:33 Updated: wesnoth-1.4.4-1.fc9.x86_64 > Sep 29 12:59:35 Updated: 12:dhcp-4.0.0-17.fc9.x86_64 > Sep 29 12:59:36 Updated: python-simplejson-1.9.1-1.fc9.x86_64 > Sep 29 12:59:37 Updated: arj-3.10.22-6.fc9.x86_64 > Sep 29 12:59:38 Updated: 2:ntfs-3g-1.2918-1.fc9.x86_64 > Sep 29 12:59:39 Updated: MAKEDEV-3.23-5.fc9.x86_64 > Sep 29 12:59:45 Updated: mercurial-1.0.2-1.fc9.x86_64 > Sep 29 12:59:55 Updated: oxygen-icon-theme-4.1.1-2.fc9.noarch > Sep 29 12:59:56 Updated: 6:kdelibs-common-4.1.1-12.fc9.x86_64 > Sep 29 12:59:59 Updated: selinux-policy-3.3.1-91.fc9.noarch > Sep 29 12:59:59 Updated: xorg-x11-server-common-1.5.0-2.fc9.x86_64 > Sep 29 12:59:59 Updated: gnome-python2-extras-2.19.1-18.fc9.x86_64 > Sep 29 13:00:15 Updated: selinux-policy-devel-3.3.1-91.fc9.noarch > Sep 29 13:01:05 Updated: selinux-policy-targeted-3.3.1-91.fc9.noarch > Sep 29 13:01:05 Updated: scim-lang-oriya-1.4.7-24.fc9.x86_64 > Sep 29 13:01:05 Updated: ltsp-vmclient-5.1.23-1.fc9.x86_64 > Sep 29 13:01:14 Updated: fedora-release-notes-9.0.2-1.noarch > Sep 29 13:01:14 Updated: scim-lang-bengali-1.4.7-24.fc9.x86_64 > Sep 29 13:01:14 Updated: scim-lang-telugu-1.4.7-24.fc9.x86_64 > Sep 29 13:01:15 Updated: scim-lang-malayalam-1.4.7-24.fc9.x86_64 > Sep 29 13:01:15 Updated: scim-lang-japanese-1.4.7-24.fc9.x86_64 > Sep 29 13:01:15 Updated: scim-lang-gujarati-1.4.7-24.fc9.x86_64 > Sep 29 13:01:17 Updated: kernel-headers-2.6.26.3-29.fc9.x86_64 > Sep 29 13:01:18 Updated: scim-lang-hindi-1.4.7-24.fc9.x86_64 > Sep 29 13:01:22 Updated: tzdata-2008f-1.fc9.noarch > Sep 29 13:01:25 Updated: xorg-x11-proto-devel-7.3-12.1.fc9.noarch > Sep 29 13:01:25 Updated: setup-2.6.17-1.fc9.noarch > Sep 29 13:01:25 Updated: scim-lang-tamil-1.4.7-24.fc9.x86_64 > Sep 29 13:01:26 Updated: scim-lang-punjabi-1.4.7-24.fc9.x86_64 > Sep 29 13:01:29 Updated: wordpress-2.6.2-1.fc9.noarch > Sep 29 13:01:30 Updated: libsilc-1.1.7-2.fc9.x86_64 > Sep 29 13:01:30 Updated: scim-lang-marathi-1.4.7-24.fc9.x86_64 > Sep 29 13:01:31 Updated: koji-1.2.6-1.fc9.noarch > Sep 29 13:01:31 Updated: scim-lang-korean-1.4.7-24.fc9.x86_64 > Sep 29 13:01:33 Updated: glib2-2.16.6-1.fc9.i386 > Sep 29 13:01:44 Updated: gtk2-2.12.12-1.fc9.x86_64 > Sep 29 13:01:48 Updated: PolicyKit-0.8-3.fc9.x86_64 > Sep 29 13:01:52 Updated: libxml2-2.7.1-1.fc9.i386 > Sep 29 13:01:53 Updated: scim-libs-1.4.7-24.fc9.x86_64 > Sep 29 13:01:54 Updated: sqlite-3.5.9-1.fc9.i386 > Sep 29 13:01:56 Updated: nss-3.12.1.1-1.fc9.x86_64 > Sep 29 13:01:56 Updated: libcurl-7.18.2-6.fc9.x86_64 > Sep 29 13:02:00 Updated: xulrunner-1.9.0.2-1.fc9.x86_64 > Sep 29 13:02:01 Updated: 1:cups-libs-1.3.8-2.fc9.i386 > Sep 29 13:02:03 Updated: libvirt-0.4.5-2.fc9.x86_64 > Sep 29 13:02:04 Updated: gtk-vnc-0.3.7-2.fc9.x86_64 > Sep 29 13:02:05 Updated: 2:gimp-libs-2.4.7-3.fc9.x86_64 > Sep 29 13:02:07 Updated: scim-1.4.7-24.fc9.x86_64 > Sep 29 13:02:08 Installed: scim-thai-0.1.1-2.fc9.x86_64 > Sep 29 13:02:08 Updated: poppler-glib-0.8.1-2.fc9.x86_64 > Sep 29 13:02:12 Updated: goffice-0.6.5-1.fc9.x86_64 > Sep 29 13:02:17 Updated: gtk2-2.12.12-1.fc9.i386 > Sep 29 13:02:23 Updated: nss-3.12.1.1-1.fc9.i386 > Sep 29 13:02:26 Installed: libssh2-0.18-7.fc9.i386 > Sep 29 13:02:26 Updated: libcurl-7.18.2-6.fc9.i386 > Sep 29 13:02:28 Updated: alsa-lib-1.0.17-2.fc9.i386 > Sep 29 13:02:28 Updated: wireshark-gnome-1.0.3-1.fc9.x86_64 > Sep 29 13:02:43 Updated: drivel-2.1.1-0.6.20071130svn.fc9.x86_64 > Sep 29 13:03:00 Updated: 2:gimp-2.4.7-3.fc9.x86_64 > Sep 29 13:03:01 Updated: scim-gtk-1.4.7-24.fc9.x86_64 > Sep 29 13:03:02 Updated: scim-rawcode-1.4.7-24.fc9.x86_64 > Sep 29 13:03:02 Updated: gtk-vnc-python-0.3.7-2.fc9.x86_64 > Sep 29 13:03:03 Updated: libvirt-python-0.4.5-2.fc9.x86_64 > Sep 29 13:03:05 Updated: transmission-1.33-1.fc9.x86_64 > Sep 29 13:03:06 Updated: 1:grip-3.2.0-22.fc9.x86_64 > Sep 29 13:03:07 Updated: curl-7.18.2-6.fc9.x86_64 > Sep 29 13:03:10 Updated: gnupg2-2.0.9-2.fc9.x86_64 > Sep 29 13:03:11 Updated: libxml2-python-2.7.1-1.fc9.x86_64 > Sep 29 13:03:26 Updated: gnome-system-monitor-2.22.4-1.fc9.x86_64 > Sep 29 13:03:29 Updated: gnome-python2-libegg-2.19.1-18.fc9.x86_64 > Sep 29 13:03:30 Updated: gnome-python2-gtkhtml2-2.19.1-18.fc9.x86_64 > Sep 29 13:04:06 Installed: kernel-2.6.26.3-29.fc9.x86_64 > Sep 29 13:04:08 Updated: libcurl-devel-7.18.2-6.fc9.x86_64 > Sep 29 13:04:09 Updated: libcurl-devel-7.18.2-6.fc9.i386 > Sep 29 13:04:09 Updated: scim-lang-thai-1.4.7-24.fc9.x86_64 > Sep 29 13:04:14 Updated: firefox-3.0.2-1.fc9.x86_64 > Sep 29 13:04:16 Updated: nss-devel-3.12.1.1-1.fc9.x86_64 > Sep 29 13:04:21 Updated: seamonkey-1.1.12-1.fc9.x86_64 > Sep 29 13:04:24 Updated: libxml2-devel-2.7.1-1.fc9.x86_64 > Sep 29 13:04:24 Updated: 1:NetworkManager-glib-0.7.0-0.11.svn4022.fc9.x86_64 > Sep 29 13:04:26 Updated: xorg-x11-server-Xorg-1.5.0-2.fc9.x86_64 > Sep 29 13:04:27 Updated: totem-xine-2.23.2-7.fc9.x86_64 > Sep 29 13:04:28 Updated: 1:NetworkManager-0.7.0-0.11.svn4022.fc9.x86_64 > Sep 29 13:04:29 Updated: xorg-x11-drv-evdev-2.0.4-1.fc9.x86_64 > Sep 29 13:04:29 Updated: 1:perl-Pod-Escapes-1.04-33.fc9.x86_64 > Sep 29 13:04:30 Updated: xorg-x11-drv-openchrome-0.2.903-1.fc9.x86_64 > Sep 29 13:04:32 Updated: 1:NetworkManager-gnome-0.7.0-0.11.svn4022.fc9.x86_64 > Sep 29 13:04:34 Updated: 1:NetworkManager-vpnc-0.7.0-0.10.svn4024.fc9.x86_64 > Sep 29 13:04:36 Updated: totem-mozplugin-2.23.2-7.fc9.x86_64 > Sep 29 13:04:37 Updated: xorg-x11-drv-ati-6.8.0-19.fc9.x86_64 > Sep 29 13:04:56 Updated: totem-2.23.2-7.fc9.x86_64 > Sep 29 13:05:01 Updated: totem-gstreamer-2.23.2-7.fc9.x86_64 > Sep 29 13:05:01 Updated: 3:perl-version-0.74-33.fc9.x86_64 > Sep 29 13:05:01 Updated: totem-nautilus-2.23.2-7.fc9.x86_64 > Sep 29 13:05:02 Updated: phonon-4.2.0-5.fc9.x86_64 > Sep 29 13:05:03 Installed: phonon-backend-xine-4.1.1-2.fc9.x86_64 > Sep 29 13:05:03 Updated: 4:perl-libs-5.10.0-33.fc9.x86_64 > Sep 29 13:05:04 Updated: phonon-backend-gstreamer-4.2.0-5.fc9.x86_64 > Sep 29 13:05:13 Updated: 4:perl-5.10.0-33.fc9.x86_64 > Sep 29 13:05:28 Updated: 6:kdelibs-4.1.1-12.fc9.x86_64 > Sep 29 13:05:33 Updated: kdepimlibs-4.1.1-2.fc9.x86_64 > Sep 29 13:05:34 Updated: kdeedu-libs-4.1.1-1.fc9.x86_64 > Sep 29 13:05:49 Updated: kdelibs3-3.5.10-1.fc9.x86_64 > Sep 29 13:06:07 Updated: kdebase-runtime-4.1.1-2.fc9.x86_64 > Sep 29 13:06:10 Updated: perl-Compress-Raw-Zlib-2.008-33.fc9.x86_64 > Sep 29 13:06:11 Updated: 4:perl-devel-5.10.0-33.fc9.x86_64 > Sep 29 13:06:13 Updated: perl-IO-Compress-Base-2.008-33.fc9.x86_64 > Sep 29 13:06:16 Updated: docbook-dtds-1.0-38.fc9.noarch > Sep 29 13:06:20 Updated: 6:kdepim-libs-3.5.10-1.fc9.x86_64 > Sep 29 13:06:23 Updated: 7:kdenetwork-libs-4.1.1-1.fc9.x86_64 > Sep 29 13:06:25 Updated: 6:kdebase-libs-4.1.1-1.fc9.x86_64 > Sep 29 13:06:29 Updated: 7:kdegraphics-libs-4.1.1-1.fc9.x86_64 > Sep 29 13:06:31 Updated: 6:kdegames-libs-4.1.1-1.fc9.x86_64 > Sep 29 13:06:32 Updated: 6:kdemultimedia-libs-4.1.1-2.fc9.x86_64 > Sep 29 13:06:33 Updated: perl-IO-Compress-Zlib-2.008-33.fc9.x86_64 > Sep 29 13:06:35 Updated: perl-Compress-Zlib-2.008-33.fc9.x86_64 > Sep 29 13:06:36 Updated: perl-Test-Harness-2.64-33.fc9.x86_64 > Sep 29 13:06:38 Updated: perl-ExtUtils-MakeMaker-6.36-33.fc9.x86_64 > Sep 29 13:06:40 Updated: 1:perl-Pod-Simple-3.05-33.fc9.x86_64 > Sep 29 13:06:41 Updated: 1:perl-ExtUtils-ParseXS-2.18-33.fc9.x86_64 > Sep 29 13:06:42 Updated: 1:perl-Module-Pluggable-3.60-33.fc9.x86_64 > Sep 29 13:06:44 Updated: kdebase3-pim-ioslaves-3.5.10-2.fc9.x86_64 > Sep 29 13:07:02 Updated: 6:kdepim-3.5.10-1.fc9.x86_64 > Sep 29 13:07:09 Updated: kdeedu-kstars-4.1.1-1.fc9.x86_64 > Sep 29 13:07:17 Updated: 1:cups-1.3.8-2.fc9.x86_64 > Sep 29 13:07:20 Updated: glib2-devel-2.16.6-1.fc9.x86_64 > Sep 29 13:07:25 Updated: kdeedu-math-4.1.1-1.fc9.x86_64 > Sep 29 13:07:26 Updated: ksysguardd-4.1.1-1.fc9.x86_64 > Sep 29 13:07:42 Updated: foomatic-3.0.2-67.fc9.x86_64 > Sep 29 13:07:47 Updated: ghostscript-8.63-1.fc9.x86_64 > Sep 29 13:07:54 Updated: gtk2-devel-2.12.12-1.fc9.x86_64 > Sep 29 13:07:58 Updated: 7:kdegraphics-4.1.1-1.fc9.x86_64 > Sep 29 13:08:15 Updated: 6:kdegames-4.1.1-1.fc9.x86_64 > Sep 29 13:08:25 Updated: yelp-2.22.1-5.fc9.x86_64 > Sep 29 13:08:28 Updated: 1:perl-IO-Zlib-1.07-33.fc9.x86_64 > Sep 29 13:08:29 Updated: perl-Archive-Tar-1.37-33.fc9.x86_64 > Sep 29 13:08:30 Updated: docbook-utils-0.6.14-14.fc9.noarch > Sep 29 13:08:31 Updated: rkhunter-1.3.2-5.fc9.noarch > Sep 29 13:08:32 Updated: rpmdevtools-6.7-1.fc9.noarch > Sep 29 13:08:33 Updated: kdebase-workspace-libs-4.1.1-1.fc9.x86_64 > Sep 29 13:08:43 Updated: kdebase-workspace-4.1.1-1.fc9.x86_64 > Sep 29 13:08:55 Updated: 6:kdebase-4.1.1-1.fc9.x86_64 > Sep 29 13:09:03 Updated: 1:kdeaccessibility-4.1.1-1.fc9.x86_64 > Sep 29 13:09:07 Updated: 6:kdemultimedia-4.1.1-2.fc9.x86_64 > Sep 29 13:09:31 Updated: kdeedu-4.1.1-1.fc9.x86_64 > Sep 29 13:09:35 Updated: kdeplasma-addons-4.1.1-1.fc9.x86_64 > Sep 29 13:09:41 Updated: 6:kdeutils-4.1.1-1.fc9.x86_64 > Sep 29 13:09:49 Updated: 7:kdenetwork-4.1.1-1.fc9.x86_64 > Sep 29 13:09:53 Updated: kdeartwork-4.1.1-1.fc9.x86_64 > Sep 29 13:13:27 Installed: kernel-2.6.26.3-29.fc9.x86_64 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From fedora at leemhuis.info Tue Sep 30 11:42:10 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 30 Sep 2008 13:42:10 +0200 Subject: Please recompile GStreamer codecs -- AKA: how to make things just work with PackageKit In-Reply-To: <15e53e180809300431h50a7eebk9ff90f445a83095e@mail.gmail.com> References: <1222771953.3291.12.camel@hughsie-laptop> <48E209E5.5070705@leemhuis.info> <15e53e180809300431h50a7eebk9ff90f445a83095e@mail.gmail.com> Message-ID: <48E21092.4090601@leemhuis.info> On 30.09.2008 13:31, Richard Hughes wrote: > On Tue, Sep 30, 2008 at 12:13 PM, Thorsten Leemhuis > wrote: >> On 30.09.2008 12:52, Richard Hughes wrote: >>> I've been playing with the new code in PackageKit for codec installing >>> with external repos. It was a little disappointed to find some external >>> repos have not recompiled packages with a new gstreamer-devel and rpm. >> Be sure to not check repos that will be EOL real soon now, as a few package >> maintainers already stopped updating their packages there; look at the >> successor repos. Instruction how to use those repos easily were just posted >> yesterday: > > Ahh, thanks. I'll try those now. In some places he repo files mention: > download.rpmfusion.org -- > shouldn't that be download1.rpmfusion.org? Yes > Also, http://download1.rpmfusion.org/free/fedora/development/x86_64/debug/repodata/repomd.xml > doesn't seem to exist. > Use http://download1.rpmfusion.org/free/fedora/development/x86_64/os/debug/repodata/repomd.xml for now. I'll try to fix both things later today. CU knurd From jkeating at redhat.com Tue Sep 30 14:12:14 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 30 Sep 2008 07:12:14 -0700 Subject: Cambridge (F-10) Beta release announcement Message-ID: <1222783934.3985.2.camel@luminos.localdomain> Fedora 10 Beta: Cambridge's foundations are laid Just on the heels of the Fedora Project's fifth anniversary, the Beta of Fedora Linux version 10 (code-named Cambridge) is now available: http://fedoraproject.org/get-prerelease There is also a Beta contest! Test five things in the Beta that are important to you as a user. If you find a bug *and* report it, you get the free attention of a package maintainer on a problem personally important to you! https://bugzilla.redhat.com Do your part to make Fedora 10 that much better. Among the new, fun, and interesting features: * New NetworkManager with connection sharing * Improved printer handling * Remote virtualization and easier virt storage * Sectool, an auditing and security testing framework * RPM 4.6, the first big RPM change in several years ... and more ... * New version of PackageKit for managing software, with more fixes and enhancements (which benefits all distributions) * New version of PulseAudio (which benefits all distributions) * Kernel 2.6.27, including better support for WiFi * Better support for the EFI for Apple Macintosh hardware * Faster graphical start-up by Plymouth, replacing the venerable RHGB * Better support for webcams through the hard work in kernel 2.6.27 (which benefits all distributions) * New icon theme "Echo", to be completed with the theme graphic "Solar" in the Fedora 10 release * Gnome 2.24 * KDE 4.1 * Adding the NetBeans IDE * Eclipse 3.4 * Automatic installation of multimedia codecs * Better HDTV support in X.org * "Sugar" graphical environment (from OLPC) available for use, testing, and development A more complete list and details of each new cited feature is available: http://fedoraproject.org/wiki/Releases/10/FeatureList For release information, including common and known bugs, please see our release notes: http://fedoraproject.org/wiki/Releases/10/Beta/ReleaseNotes -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: -------------- next part -------------- _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce From mike at miketc.net Tue Sep 30 14:33:35 2008 From: mike at miketc.net (Mike Chambers) Date: Tue, 30 Sep 2008 09:33:35 -0500 Subject: Cambridge (F-10) Beta release announcement In-Reply-To: <1222783934.3985.2.camel@luminos.localdomain> References: <1222783934.3985.2.camel@luminos.localdomain> Message-ID: <1222785215.14748.1.camel@scrappy.miketc.net> On Tue, 2008-09-30 at 07:12 -0700, Jesse Keating wrote: > Fedora 10 Beta: Cambridge's foundations are laid > > Just on the heels of the Fedora Project's fifth anniversary, the Beta of > Fedora Linux version 10 (code-named Cambridge) is now available: > > http://fedoraproject.org/get-prerelease Bits still not released or at least permissions not taken off mirrors yet? I guess I am finally on top of a release and catching the announcement early for once and takes time for the permissions to catch on? -- Mike Chambers Fedora Project - Ambassador, Bug Zapper, Tester, User, etc.. mikec302 at fedoraproject.org From sundaram at fedoraproject.org Tue Sep 30 14:37:49 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Tue, 30 Sep 2008 20:07:49 +0530 Subject: Cambridge (F-10) Beta release announcement In-Reply-To: <1222785215.14748.1.camel@scrappy.miketc.net> References: <1222783934.3985.2.camel@luminos.localdomain> <1222785215.14748.1.camel@scrappy.miketc.net> Message-ID: <48E239BD.4040304@fedoraproject.org> Mike Chambers wrote: > On Tue, 2008-09-30 at 07:12 -0700, Jesse Keating wrote: >> Fedora 10 Beta: Cambridge's foundations are laid >> >> Just on the heels of the Fedora Project's fifth anniversary, the Beta of >> Fedora Linux version 10 (code-named Cambridge) is now available: >> >> http://fedoraproject.org/get-prerelease > > Bits still not released or at least permissions not taken off mirrors > yet? I guess I am finally on top of a release and catching the > announcement early for once and takes time for the permissions to catch > on? Yes, just wait for a (short) while. Rahul From choeger at cs.tu-berlin.de Tue Sep 30 15:43:03 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 30 Sep 2008 17:43:03 +0200 Subject: Cambridge (F-10) Beta release announcement In-Reply-To: <1222785215.14748.1.camel@scrappy.miketc.net> References: <1222783934.3985.2.camel@luminos.localdomain> <1222785215.14748.1.camel@scrappy.miketc.net> Message-ID: <1222789383.6512.13.camel@choeger6> Does installing the beta mean to use rawhide? or is there an easy way to get stable repositories of Fedora 10 when they're out? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From pbrobinson at gmail.com Tue Sep 30 15:51:17 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 30 Sep 2008 16:51:17 +0100 Subject: Cambridge (F-10) Beta release announcement In-Reply-To: <1222789383.6512.13.camel@choeger6> References: <1222783934.3985.2.camel@luminos.localdomain> <1222785215.14748.1.camel@scrappy.miketc.net> <1222789383.6512.13.camel@choeger6> Message-ID: <5256d0b0809300851v6a4c278cjbd108f402b273b7f@mail.gmail.com> > Does installing the beta mean to use rawhide? or is there an easy way to > get stable repositories of Fedora 10 when they're out? Just before the final release is done the rawhide will point to the stable F-10 repos so that when F-10 is out you will be running the stable version and have to actively move back to the unstable rawhide. Peter From choeger at cs.tu-berlin.de Tue Sep 30 16:00:57 2008 From: choeger at cs.tu-berlin.de (Christoph =?ISO-8859-1?Q?H=F6ger?=) Date: Tue, 30 Sep 2008 18:00:57 +0200 Subject: Cambridge (F-10) Beta release announcement In-Reply-To: <5256d0b0809300851v6a4c278cjbd108f402b273b7f@mail.gmail.com> References: <1222783934.3985.2.camel@luminos.localdomain> <1222785215.14748.1.camel@scrappy.miketc.net> <1222789383.6512.13.camel@choeger6> <5256d0b0809300851v6a4c278cjbd108f402b273b7f@mail.gmail.com> Message-ID: <1222790457.6512.15.camel@choeger6> Am Dienstag, den 30.09.2008, 16:51 +0100 schrieb Peter Robinson: > > Does installing the beta mean to use rawhide? or is there an easy way to > > get stable repositories of Fedora 10 when they're out? > > Just before the final release is done the rawhide will point to the > stable F-10 repos so that when F-10 is out you will be running the > stable version and have to actively move back to the unstable rawhide. > > Peter > Nice. Thanks for the answer :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From fedora at leemhuis.info Tue Sep 30 16:20:14 2008 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 30 Sep 2008 18:20:14 +0200 Subject: Please recompile GStreamer codecs -- AKA: how to make things just work with PackageKit In-Reply-To: <15e53e180809300431h50a7eebk9ff90f445a83095e@mail.gmail.com> References: <1222771953.3291.12.camel@hughsie-laptop> <48E209E5.5070705@leemhuis.info> <15e53e180809300431h50a7eebk9ff90f445a83095e@mail.gmail.com> Message-ID: <48E251BE.2090209@leemhuis.info> On 30.09.2008 13:31, Richard Hughes wrote: > On Tue, Sep 30, 2008 at 12:13 PM, Thorsten Leemhuis > wrote: >> On 30.09.2008 12:52, Richard Hughes wrote: >>> I've been playing with the new code in PackageKit for codec installing >>> with external repos. It was a little disappointed to find some external >>> repos have not recompiled packages with a new gstreamer-devel and rpm. >> Be sure to not check repos that will be EOL real soon now, as a few package >> maintainers already stopped updating their packages there; look at the >> successor repos. Instruction how to use those repos easily were just posted >> yesterday: > > Ahh, thanks. I'll try those now. In some places he repo files mention: > download.rpmfusion.org -- > shouldn't that be download1.rpmfusion.org? > > Also, http://download1.rpmfusion.org/free/fedora/development/x86_64/debug/repodata/repomd.xml > doesn't seem to exist. Both issues fixed; new release-rpms in the repo; the old ones got deleted, thus eveyone please use this command to get the repo files from now on: === == rawhide == rpm -ivh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-rawhide.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-rawhide.noarch.rpm == Fedora 8 and 9 == rpm -ivh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm === The plan is to let those symbolic links on the server side always point to the latest release-rpms. But I have to create those links manually each time something changes -- so if I forget that then please just let me know by mail. tia! Cu knurd From bpepple at fedoraproject.org Tue Sep 30 16:47:39 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 30 Sep 2008 12:47:39 -0400 Subject: Plan for tomorrows (20081001) FESCO meeting Message-ID: <1222793259.12855.5.camel@truman> Hi, Please find below the list of topics that are likely to come up in the next FESCo meeting that is scheduled for tomorrow, Wednesday at 17:00 UTC in #fedora-meeting on irc.freenode.org (NOTE: Please note that we've moved our start time an hour earlier): /topic FESCo meeting -- Any objection to last week's report from FPC at https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02133.html /topic FESCo-Meeting -- Features - all /topic FESCo-Meeting -- MinGW follow-up? - all /topic FESCo meeting -- Free discussion around Fedora You want something to be discussed? Send a note to the list in reply to this mail and I'll add it to the schedule. You can also propose topics in the meeting while it is in the "Free discussion around Fedora" phase. Later, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rjones at redhat.com Tue Sep 30 17:05:28 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 30 Sep 2008 18:05:28 +0100 Subject: Plan for tomorrows (20081001) FESCO meeting In-Reply-To: <1222793259.12855.5.camel@truman> References: <1222793259.12855.5.camel@truman> Message-ID: <20080930170528.GA12353@amd.home.annexia.org> On Tue, Sep 30, 2008 at 12:47:39PM -0400, Brian Pepple wrote: > /topic FESCo-Meeting -- MinGW follow-up? - all If you want, although we're still waiting for infrastructure to decide if they can create a repository[1]. Mike McGrath is looking at this request at the moment. Meanwhile I'm continuing to port packages and update the public repo: http://hg.et.redhat.com/misc/fedora-mingw--devel/ http://www.annexia.org/tmp/mingw/ Rich. [1] https://fedorahosted.org/fedora-infrastructure/ticket/807 -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From rjones at redhat.com Tue Sep 30 17:13:32 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 30 Sep 2008 18:13:32 +0100 Subject: Running Xvfb during a package build -- good idea? Message-ID: <20080930171332.GB12353@amd.home.annexia.org> We have a package (mingw32-openssl) which has some tests that run under Wine. Strictly speaking, running the tests isn't necessary, but because it's such an important package I feel that we should run the tests. Anyhow, Wine needs an X server, although it doesn't really use it for anything. To provide one, I'm using Xvfb like this: BuildRequires: wine BuildRequires: xorg-x11-server-Xvfb #... display=:21 Xvfb $display & xpid=$! trap "kill -TERM $xpid ||:" EXIT sleep 3 DISPLAY=$display export DISPLAY make -C test tests This works, but there are two problems. Firstly there isn't a good way to choose a free display number, so I'm just picking one at random here. This assumes that port 6021 is free, also disallows any builds that happen in parallel. Secondly, will Koji let me do such a thing at all? Is there another / a better way? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From jkeating at redhat.com Tue Sep 30 17:19:36 2008 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 30 Sep 2008 10:19:36 -0700 Subject: Running Xvfb during a package build -- good idea? In-Reply-To: <20080930171332.GB12353@amd.home.annexia.org> References: <20080930171332.GB12353@amd.home.annexia.org> Message-ID: <1222795176.3985.17.camel@luminos.localdomain> On Tue, 2008-09-30 at 18:13 +0100, Richard W.M. Jones wrote: > Is there another / a better way? Do your testing outside of Koji? Sure we don't provide any testing infrastructure, but I think this is something of an abuse of our build infrastructure. -- Jesse Keating Fedora -- Freedom? is a feature! identi.ca: http://identi.ca/jkeating -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From dan at danny.cz Tue Sep 30 17:18:20 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Tue, 30 Sep 2008 19:18:20 +0200 Subject: Running Xvfb during a package build -- good idea? In-Reply-To: <20080930171332.GB12353@amd.home.annexia.org> References: <20080930171332.GB12353@amd.home.annexia.org> Message-ID: <1222795100.3601.29.camel@eagle.danny.cz> Richard W.M. Jones p??e v ?t 30. 09. 2008 v 18:13 +0100: > We have a package (mingw32-openssl) which has some tests that run > under Wine. Strictly speaking, running the tests isn't necessary, but > because it's such an important package I feel that we should run the > tests. > > Anyhow, Wine needs an X server, although it doesn't really use it for > anything. To provide one, I'm using Xvfb like this: > > BuildRequires: wine > BuildRequires: xorg-x11-server-Xvfb > > #... > > display=:21 > Xvfb $display & xpid=$! > trap "kill -TERM $xpid ||:" EXIT > sleep 3 > DISPLAY=$display > export DISPLAY > make -C test tests > > This works, but there are two problems. Firstly there isn't a good > way to choose a free display number, so I'm just picking one at random > here. This assumes that port 6021 is free, also disallows any builds > that happen in parallel. Secondly, will Koji let me do such a thing > at all? Is there another / a better way? > Running Xvfb during build works, we have it in the tinyerp package (display is :69). Dan From rjones at redhat.com Tue Sep 30 17:22:35 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 30 Sep 2008 18:22:35 +0100 Subject: Running Xvfb during a package build -- good idea? In-Reply-To: <1222795176.3985.17.camel@luminos.localdomain> References: <20080930171332.GB12353@amd.home.annexia.org> <1222795176.3985.17.camel@luminos.localdomain> Message-ID: <20080930172235.GC12353@amd.home.annexia.org> On Tue, Sep 30, 2008 at 10:19:36AM -0700, Jesse Keating wrote: > On Tue, 2008-09-30 at 18:13 +0100, Richard W.M. Jones wrote: > > Is there another / a better way? > > Do your testing outside of Koji? Sure we don't provide any testing > infrastructure, but I think this is something of an abuse of our build > infrastructure. Well this is just running the unit tests on a built package destined for Fedora. I don't see it as any abuse of the build infrastructure. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From bpepple at fedoraproject.org Tue Sep 30 17:23:54 2008 From: bpepple at fedoraproject.org (Brian Pepple) Date: Tue, 30 Sep 2008 13:23:54 -0400 Subject: Plan for tomorrows (20081001) FESCO meeting In-Reply-To: <20080930170528.GA12353@amd.home.annexia.org> References: <1222793259.12855.5.camel@truman> <20080930170528.GA12353@amd.home.annexia.org> Message-ID: <1222795434.13276.2.camel@truman> On Tue, 2008-09-30 at 18:05 +0100, Richard W.M. Jones wrote: > On Tue, Sep 30, 2008 at 12:47:39PM -0400, Brian Pepple wrote: > > /topic FESCo-Meeting -- MinGW follow-up? - all > > If you want, although we're still waiting for infrastructure to decide > if they can create a repository[1]. Mike McGrath is looking at this > request at the moment. I was just looking for an update on the status since I hadn't heard anything about it since last week's meeting. I'll go ahead and bump it to next week since it looks like it's still being worked on. Thanks, /B -- Brian Pepple https://fedoraproject.org/wiki/User:Bpepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From wtogami at redhat.com Tue Sep 30 17:24:36 2008 From: wtogami at redhat.com (Warren Togami) Date: Tue, 30 Sep 2008 13:24:36 -0400 Subject: NetworkManager-vpnc gnome-keyring problem after F9 update In-Reply-To: <1222774576.2826.1.camel@localhost.localdomain> References: <48E194A4.1010408@redhat.com> <1222774576.2826.1.camel@localhost.localdomain> Message-ID: <48E260D4.1050804@redhat.com> Dan Williams wrote: > On Mon, 2008-09-29 at 22:53 -0400, Warren Togami wrote: >> Today I did a pile of F9 updates for the first time since September >> 13th. The update log is attached. > > Any AVCs? No AVC's. Warren From mikeb at redhat.com Tue Sep 30 17:47:28 2008 From: mikeb at redhat.com (Mike Bonnet) Date: Tue, 30 Sep 2008 13:47:28 -0400 Subject: Running Xvfb during a package build -- good idea? In-Reply-To: <20080930171332.GB12353@amd.home.annexia.org> References: <20080930171332.GB12353@amd.home.annexia.org> Message-ID: <1222796848.5387.9.camel@burren.bos.redhat.com> On Tue, 2008-09-30 at 18:13 +0100, Richard W.M. Jones wrote: > We have a package (mingw32-openssl) which has some tests that run > under Wine. Strictly speaking, running the tests isn't necessary, but > because it's such an important package I feel that we should run the > tests. > > Anyhow, Wine needs an X server, although it doesn't really use it for > anything. To provide one, I'm using Xvfb like this: > > BuildRequires: wine > BuildRequires: xorg-x11-server-Xvfb > > #... > > display=:21 > Xvfb $display & xpid=$! > trap "kill -TERM $xpid ||:" EXIT > sleep 3 > DISPLAY=$display > export DISPLAY > make -C test tests > > This works, but there are two problems. Firstly there isn't a good > way to choose a free display number, so I'm just picking one at random > here. This assumes that port 6021 is free, also disallows any builds > that happen in parallel. Secondly, will Koji let me do such a thing > at all? Is there another / a better way? Ignoring the question of whether this is a good idea or not, why not do something like: display=:$(($RANDOM % 100)) Not fool-proof, but it should result in fewer port conflicts. Also, you may want to call "kill -KILL" from your trap instead, to be more sure you're actually cleaning up the Xvfb. From jeff at ocjtech.us Tue Sep 30 17:55:04 2008 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Tue, 30 Sep 2008 12:55:04 -0500 Subject: Zabbix 1.6 in Rawhide Message-ID: <935ead450809301055k4b3548f6nd252c3f28e8893b5@mail.gmail.com> I've updated Zabbix in Rawhide to the recently released version 1.6. It's a fairly significant upgrade so I'm going to wait a while before pushing it to F-9, F-8, or EL-5. -- Jeff Ollie "You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." -- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon" From seg at haxxed.com Tue Sep 30 18:04:20 2008 From: seg at haxxed.com (Callum Lerwick) Date: Tue, 30 Sep 2008 13:04:20 -0500 Subject: Running Xvfb during a package build -- good idea? In-Reply-To: <20080930171332.GB12353@amd.home.annexia.org> References: <20080930171332.GB12353@amd.home.annexia.org> Message-ID: <1222797860.3864.10.camel@localhost.localdomain> On Tue, 2008-09-30 at 18:13 +0100, Richard W.M. Jones wrote: > Anyhow, Wine needs an X server, although it doesn't really use it for > anything. To provide one, I'm using Xvfb like this: Hmmm, I could have sworn Wine can run console Win32 apps without an X server. In fact, I just tried it, a simple hello world app runs just find on a vconsole with no accessible X server. Though I notice trying to run a GUI app fails: $ DISPLAY="" wine ./gtk-demo.exe Application tried to create a window, but no driver could be loaded. Make sure that your X server is running and that $DISPLAY is set correctly. Application tried to create a window, but no driver could be loaded. Make sure that your X server is running and that $DISPLAY is set correctly. err:ole:apartment_createwindowifneeded CreateWindow failed with error 2 wine: Unhandled page fault on read access to 0x00000000 at address 0x6c37ea4e (thread 0019), starting debugger... [etc etc] Are the unit tests GUI for some reason? I'd advise patching them to be console only... -mwindows doesn't seem to make a difference. Wine seems to wait for the app to actually open a window regardless of the subsystem set in the EXE headers. http://support.microsoft.com/kb/90493 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From rjones at redhat.com Tue Sep 30 18:13:01 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 30 Sep 2008 19:13:01 +0100 Subject: Running Xvfb during a package build -- good idea? In-Reply-To: <1222797860.3864.10.camel@localhost.localdomain> References: <20080930171332.GB12353@amd.home.annexia.org> <1222797860.3864.10.camel@localhost.localdomain> Message-ID: <20080930181301.GA12712@amd.home.annexia.org> On Tue, Sep 30, 2008 at 01:04:20PM -0500, Callum Lerwick wrote: > Hmmm, I could have sworn Wine can run console Win32 apps without an X > server. In fact, I just tried it, a simple hello world app runs just > find on a vconsole with no accessible X server. Though I notice trying > to run a GUI app fails: > > $ DISPLAY="" wine ./gtk-demo.exe > Application tried to create a window, but no driver could be loaded. > Make sure that your X server is running and that $DISPLAY is set > correctly. [...] > Are the unit tests GUI for some reason? I'd advise patching them to be > console only... Lots of the tests run without X, but not all of them, although the ones which require it don't seem to actually do anything (displaying a window etc.) They give the same error as above. Yes, these should be patched ... At the moment I'm just trying to work out why the tests sometimes fail unpredictably (about 50% of the time a test will fail at some random place). Here's the spec file: http://hg.et.redhat.com/misc/fedora-mingw--devel/?f=05fcc324edbd;file=openssl/mingw32-openssl.spec I found I had to add -noreset to the Xvfb command line, otherwise it exits after the first X program goes away. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora From mw_triad at users.sourceforge.net Tue Sep 30 18:30:45 2008 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 30 Sep 2008 13:30:45 -0500 Subject: Please recompile GStreamer codecs -- AKA: how to make things just work with PackageKit In-Reply-To: <48E251BE.2090209@leemhuis.info> References: <1222771953.3291.12.camel@hughsie-laptop> <48E209E5.5070705@leemhuis.info> <15e53e180809300431h50a7eebk9ff90f445a83095e@mail.gmail.com> <48E251BE.2090209@leemhuis.info> Message-ID: Thorsten Leemhuis wrote: > [...]eveyone please use this command to get the repo files from now on: > > == Fedora 8 and 9 == > > rpm -ivh > http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm > http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm Given the recent security scare, is this information (along with keys, I hope!) also posted somewhere "trustworthy"? Would it be possible to drop a new-release rpm into livna so that livna users can get the new repo rpm from livna rather than having to trust the URL in (if you'll pardon me) some random e-mail? -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- What, no punchline? From mr.ecik at gmail.com Tue Sep 30 18:34:42 2008 From: mr.ecik at gmail.com (=?ISO-8859-2?Q?Micha=B3_Bentkowski?=) Date: Tue, 30 Sep 2008 20:34:42 +0200 Subject: Sourceforge URLs (was: Re: Fever spamming) In-Reply-To: References: <668bb39a0809271600u4dc1a943x697acb022f1d7472@mail.gmail.com> <20080930090956.GA10598@amd.home.annexia.org> Message-ID: <668bb39a0809301134k7c4c7b8dw6f3a4da659c1cf42@mail.gmail.com> 2008/9/30 Kevin Kofler : > What needs to be fixed is the file list URLs used in FEver. This only affects > FEver. > All sourceforge URLs in FEver has already been fixed. Now it works just fine. -- Micha? Bentkowski mr.ecik at gmail.com From kevin.kofler at chello.at Tue Sep 30 19:11:03 2008 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 30 Sep 2008 19:11:03 +0000 (UTC) Subject: Running Xvfb during a package build -- good idea? References: <20080930171332.GB12353@amd.home.annexia.org> Message-ID: Richard W.M. Jones redhat.com> writes: > We have a package (mingw32-openssl) which has some tests that run > under Wine. Isn't that a noarch target package? If so, it can't run WINE, because it could be built on a PPC host where WINE won't work. IMHO, MinGW target binaries should be handled as foreign binaries, i.e. binaries which can't be run in the host environment. Any package which requires WINE is not a clean cross-compilation package. So I think the pain of running the tests is really not worth it. And as I said, it won't even work reliably, because noarch packages can be assigned to PPC hosts in Koji. Kevin Kofler From pbrobinson at gmail.com Tue Sep 30 19:24:37 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 30 Sep 2008 20:24:37 +0100 Subject: F10 beta from LiveCD Message-ID: <5256d0b0809301224t3579b43by4067056a1eebf187@mail.gmail.com> Hi All, A couple of queries about the F10 Beta live CD and installing to HDD from it. Firstly is it possible to enable ext4 from the LiveCD install? Secondly on an eeePC 901 the partitioning tool layout is a bit messed up. I took a screen shot of it to file as a bug and saved it to the "USB Stick" which was the device from which I had booted the LiveCD but it didn't seem to stick around when I put the stick into another machine to log the bug. Other than that it looks good.... but I knew that already :-) Peter From david at hlacik.eu Tue Sep 30 19:25:45 2008 From: david at hlacik.eu (=?ISO-8859-2?Q?David_Hl=E1=E8ik?=) Date: Tue, 30 Sep 2008 21:25:45 +0200 Subject: xen kernel with dom0 in Fedora 10? Message-ID: Hi , guys, I have found in Fedora 10 Features , that there is still a lot of work to provide xen kernel with dom0 support to Fedora 10 GA. For my future project, which at 90 percent depends on virtualization technology I am deciding between XEN or KVM virtualization. I am experienced XEN user, KVM is new for me. But as I am aware of, Qumranet was bought by RedHat which predicts something ... Thanks in advance! David From rjones at redhat.com Tue Sep 30 19:35:59 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 30 Sep 2008 20:35:59 +0100 Subject: Running Xvfb during a package build -- good idea? In-Reply-To: References: <20080930171332.GB12353@amd.home.annexia.org> Message-ID: <20080930193559.GA12982@amd.home.annexia.org> On Tue, Sep 30, 2008 at 07:11:03PM +0000, Kevin Kofler wrote: > Richard W.M. Jones redhat.com> writes: > > We have a package (mingw32-openssl) which has some tests that run > > under Wine. > > Isn't that a noarch target package? If so, it can't run WINE, > because it could be built on a PPC host where WINE won't work. Yes, you are very right on this. It's a bit worse than that as well because I've just discovered that this package needs Wine to build as well as to run the tests :-( Ho hmmm, back to the drawing board ... Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From rjones at redhat.com Tue Sep 30 19:37:05 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Tue, 30 Sep 2008 20:37:05 +0100 Subject: xen kernel with dom0 in Fedora 10? In-Reply-To: References: Message-ID: <20080930193705.GB12982@amd.home.annexia.org> On Tue, Sep 30, 2008 at 09:25:45PM +0200, David Hl??ik wrote: > Hi , guys, I have found in Fedora 10 Features , that there is still a > lot of work to provide xen kernel with dom0 support to Fedora 10 GA. > For my future project, which at 90 percent depends on virtualization > technology I am deciding between XEN or KVM virtualization. I am > experienced XEN user, KVM is new for me. But as I am aware of, > Qumranet was bought by RedHat which predicts something ... Yup, KVM is cool, much easier to use, and with virtio-enabled guests it's about the same speed as Xen. So what was your question :-? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From katzj at redhat.com Tue Sep 30 19:37:28 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 30 Sep 2008 15:37:28 -0400 Subject: F10 beta from LiveCD In-Reply-To: <5256d0b0809301224t3579b43by4067056a1eebf187@mail.gmail.com> References: <5256d0b0809301224t3579b43by4067056a1eebf187@mail.gmail.com> Message-ID: <1222803448.22634.17.camel@aglarond.local> On Tue, 2008-09-30 at 20:24 +0100, Peter Robinson wrote: > A couple of queries about the F10 Beta live CD and installing to HDD from it. > > Firstly is it possible to enable ext4 from the LiveCD install? No -- the live install just copies the filesystem that's used from the live image to the target disk. And since the source filesystem is ext3 ... While you could then enable extents, you're not going to get most of the advantages until all the files are rewritten > Secondly on an eeePC 901 the partitioning tool layout is a bit messed > up. I took a screen shot of it to file as a bug and saved it to the > "USB Stick" which was the device from which I had booted the LiveCD > but it didn't seem to stick around when I put the stick into another > machine to log the bug. This had been filed with Fedora 9 and I actually got around to fixing it up yesterday Jeremy From itamar at ispbrasil.com.br Tue Sep 30 19:42:06 2008 From: itamar at ispbrasil.com.br (Itamar - IspBrasil) Date: Tue, 30 Sep 2008 16:42:06 -0300 Subject: clustered filesystem - howto Message-ID: <48E2810E.60209@ispbrasil.com.br> whats the best option available for clustered filesystem ? drdb, clvm, etc.... ? can you recomend a howto about this ? From james at fedoraproject.org Tue Sep 30 19:51:07 2008 From: james at fedoraproject.org (James Antill) Date: Tue, 30 Sep 2008 15:51:07 -0400 Subject: Heads up, python-2.5.2 just built in rawhide Message-ID: <1222804267.9274.45.camel@code.and.org> This shouldn't be a rebuild the world kind of update, but 2.5.2 has just built for rawhide and it isn't a trivial update (some of our patches had to be altered etc.) ... so there's some room for weirdness, so if you see anything please BZ etc. For the impatient the koji build was: http://koji.fedoraproject.org/koji/taskinfo?taskID=852968 -- James Antill Fedora From mmcgrath at redhat.com Tue Sep 30 19:52:06 2008 From: mmcgrath at redhat.com (Mike McGrath) Date: Tue, 30 Sep 2008 14:52:06 -0500 (CDT) Subject: clustered filesystem - howto In-Reply-To: <48E2810E.60209@ispbrasil.com.br> References: <48E2810E.60209@ispbrasil.com.br> Message-ID: On Tue, 30 Sep 2008, Itamar - IspBrasil wrote: > whats the best option available for clustered filesystem ? > > drdb, clvm, etc.... ? > > can you recomend a howto about this ? > drdb and clvm are not file systems. take a look at gfs. -Mike From berrange at redhat.com Tue Sep 30 19:54:23 2008 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 30 Sep 2008 20:54:23 +0100 Subject: [Fedora-xen] xen kernel with dom0 in Fedora 10? In-Reply-To: References: Message-ID: <20080930195423.GB15434@redhat.com> On Tue, Sep 30, 2008 at 09:25:45PM +0200, David Hl??ik wrote: > Hi , guys, I have found in Fedora 10 Features , that there is still a > lot of work to provide xen kernel with dom0 support to Fedora 10 GA. > For my future project, which at 90 percent depends on virtualization > technology I am deciding between XEN or KVM virtualization. I am > experienced XEN user, KVM is new for me. But as I am aware of, > Qumranet was bought by RedHat which predicts something ... There is pretty much zero chance that Fedora 10 will include a Xen Dom0 host. While upstream Xen developers are making good progress on porting Dom0 to paravirt_ops, there is simply too little time for this to be ready for Fedora 10. So if you need to use Fedora 10 as a host, then KVM is your only viable option at this time. If you can wait for Fedora 11 (or use RHEL-5 / CentOS-5) then Xen may be an option for you. I'll let other people comment on the pros/cons of Xen vs KVM outside the kernel availability issue. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| From email.ahmedkamal at googlemail.com Tue Sep 30 20:04:02 2008 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Tue, 30 Sep 2008 22:04:02 +0200 Subject: clustered filesystem - howto In-Reply-To: <48E2810E.60209@ispbrasil.com.br> References: <48E2810E.60209@ispbrasil.com.br> Message-ID: <3da3b5b40809301304w2a64a45yb4f1d9bab20fd209@mail.gmail.com> Basic info: http://en.wikipedia.org/wiki/Shared_disk_file_system You might want to look at lustre too On Tue, Sep 30, 2008 at 9:42 PM, Itamar - IspBrasil wrote: > whats the best option available for clustered filesystem ? > > drdb, clvm, etc.... ? > > can you recomend a howto about this ? > > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbrobinson at gmail.com Tue Sep 30 20:04:45 2008 From: pbrobinson at gmail.com (Peter Robinson) Date: Tue, 30 Sep 2008 21:04:45 +0100 Subject: F10 beta from LiveCD In-Reply-To: <1222803448.22634.17.camel@aglarond.local> References: <5256d0b0809301224t3579b43by4067056a1eebf187@mail.gmail.com> <1222803448.22634.17.camel@aglarond.local> Message-ID: <5256d0b0809301304r3a3a8d67h73b2f02b1a5c72fa@mail.gmail.com> >> A couple of queries about the F10 Beta live CD and installing to HDD from it. >> >> Firstly is it possible to enable ext4 from the LiveCD install? > > No -- the live install just copies the filesystem that's used from the > live image to the target disk. And since the source filesystem is > ext3 ... > > While you could then enable extents, you're not going to get most of the > advantages until all the files are rewritten OK, I figured as much, I was actually wanting it for a /home dir. Is that possible? >> Secondly on an eeePC 901 the partitioning tool layout is a bit messed >> up. I took a screen shot of it to file as a bug and saved it to the >> "USB Stick" which was the device from which I had booted the LiveCD >> but it didn't seem to stick around when I put the stick into another >> machine to log the bug. > > This had been filed with Fedora 9 and I actually got around to fixing it > up yesterday Nice :-) Cheers, Peter From katzj at redhat.com Tue Sep 30 20:12:09 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 30 Sep 2008 16:12:09 -0400 Subject: F10 beta from LiveCD In-Reply-To: <5256d0b0809301304r3a3a8d67h73b2f02b1a5c72fa@mail.gmail.com> References: <5256d0b0809301224t3579b43by4067056a1eebf187@mail.gmail.com> <1222803448.22634.17.camel@aglarond.local> <5256d0b0809301304r3a3a8d67h73b2f02b1a5c72fa@mail.gmail.com> Message-ID: <1222805529.22634.18.camel@aglarond.local> On Tue, 2008-09-30 at 21:04 +0100, Peter Robinson wrote: > >> A couple of queries about the F10 Beta live CD and installing to HDD from it. > >> > >> Firstly is it possible to enable ext4 from the LiveCD install? > > > > No -- the live install just copies the filesystem that's used from the > > live image to the target disk. And since the source filesystem is > > ext3 ... > > > > While you could then enable extents, you're not going to get most of the > > advantages until all the files are rewritten > > OK, I figured as much, I was actually wanting it for a /home dir. Is > that possible? You probably have to a) boot with 'ext4' on the kernel command line b) manually load the ext4 module c) do manual partitioning. But with those things done, no reason it wouldn't work for /home Jeremy From opensource at till.name Tue Sep 30 20:43:00 2008 From: opensource at till.name (Till Maas) Date: Tue, 30 Sep 2008 22:43:00 +0200 Subject: Cambridge (F-10) Beta release announcement In-Reply-To: <1222783934.3985.2.camel@luminos.localdomain> References: <1222783934.3985.2.camel@luminos.localdomain> Message-ID: <200809302243.05507.opensource@till.name> On Tue September 30 2008, Jesse Keating wrote: > Fedora 10 Beta: Cambridge's foundations are laid > > Just on the heels of the Fedora Project's fifth anniversary, the Beta of > Fedora Linux version 10 (code-named Cambridge) is now available: > > http://fedoraproject.org/get-prerelease I am probably the only one trying to do this, but how can I verify the SHA1SUM files for the i686 Live iso? I did not investigate it completely, but it seems that it is only signed with some new key, that is not listed here: https://fedoraproject.org/keys The os dir of a nearby mirror contains several gpg key files with different sizes and names, that are also not mentioned in above webpage. > There is also a Beta contest! Test five things in the Beta that are > important to you as a user. If you find a bug *and* report it, you get > the free attention of a package maintainer on a problem personally > important to you! I hope I can join the contest with my current findings. ;-) Regards, Till -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. URL: From jarod at redhat.com Tue Sep 30 20:59:12 2008 From: jarod at redhat.com (Jarod Wilson) Date: Tue, 30 Sep 2008 16:59:12 -0400 Subject: make mail go somewhere by default In-Reply-To: <48DBF3F5.3080806@redhat.com> References: <20080924212236.GJ1414283@hiwaay.net> <48DBED58.3040307@gmail.com> <48DBF3F5.3080806@redhat.com> Message-ID: <200809301659.12364.jarod@redhat.com> On Thursday 25 September 2008 16:26:29 Jarod Wilson wrote: > Les Mikesell wrote: > > Matthew Miller wrote: > >> On Wed, Sep 24, 2008 at 04:39:26PM -0700, Jesse Keating wrote: > >>> Which is why we shouldn't be using local delivery for this stuff. > >>> Instead we should ask in firstboot where you'd want the mail delivered > >>> to. > >> > >> Ooh! And do it this way! > >> > >> https://bugzilla.redhat.com/show_bug.cgi?id=143437 > > > > That's a good technique, but wouldn't it follow the system style more > > closely to put install/firstboot setting snippets somewhere under > > /etc/sysconfig with the stock alias file including from there? > > Hm... I wrote a firstboot patch ages ago (almost 3 years ago?) that let you > say "send root mail to this user" when you added a user in firstboot... Its > even in bz somewhere, iirc... Thar she blows: https://bugzilla.redhat.com/show_bug.cgi?id=135592 -- Jarod Wilson jarod at redhat.com From Matt_Domsch at dell.com Tue Sep 30 19:01:58 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 30 Sep 2008 14:01:58 -0500 Subject: Fedora rawhide rebuild in mock status 2008-09-30 i386 Message-ID: <20080930190158.GA28271@mock.linuxdev.us.dell.com> Fedora Rawhide-in-Mock Build Results for i386 This is not a full rebuild of everything, merely a rebuild of packages failing to build over the last few weeks, using the newly-unfrozen rawhide of 9/29/2008. Failures here will cause new bugzilla bugs to be created, which will block the 'F10FTBFS' bug. My hope is that we can resolve all these before the Fedora 10 Release Candidate. 76 of these failures are due to patch fuzz. Each of those should be reviewed to ensure upstream has not already fixed the problem the patch addressed, either by applying the patch or by fixing it in another way. If the problem persists, please rebase the patch to the current source code, so it applies without fuzz, and forward your patch to the upstream package maintainer. Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ 1 Open Bugs which now build, and can be marked CLOSED RAWHIDE: file: [u'463809'] Total packages: 6262 Number failed to build: 174 Number expected to fail due to ExclusiveArch or ExcludeArch: 14 Leaving: 160 Of those expected to have worked... Without a bug filed: 155 ---------------------------------- UnihanDb-5.1.0-7.fc10 (build/make) dchen amarok-1.90-1.fc10 (build/make) abompard,rdieter,tuxbrewr arm-gp2x-linux-gcc-4.1.2-8.fc9 (build/make) jwrdegoede atitvout-0.4-8 (patch_fuzz) awjb atlas-3.6.0-15.fc10 (build/make) deji,deji audacious-plugin-fc-0.2-7 (build/make) mschwendt automake15-1.5-23 (patch_fuzz) karsten avr-binutils-2.18-2.fc9 (patch_fuzz) tnorth,trondd avr-gcc-4.1.2-6.fc9 (build/make) tnorth,trondd azureus-3.0.4.2-16.fc10 (build/make) langel,langel bigboard-0.6.2-2.fc10 (build/make) walters bit-0.4.1-3.fc9 (build/make) rvinyard bluez-utils-3.36-2.fc10 (build/make) dwmw2,hadess boost-1.34.1-16.fc10 (patch_fuzz) bkoz,pmachata bsd-games-2.17-23.fc9 (patch_fuzz) wart cernlib-2006-30.fc10 (patch_fuzz) pertusus cernlib-g77-2006-30.fc10 (patch_fuzz) pertusus classpathx-jaf-1.0-12.fc10 (build/make) devrim compat-gcc-34-3.4.6-9 (patch_fuzz) jakub conexus-0.5.3-4.fc9 (build/make) rvinyard conexusmm-0.5.0-3.fc7 (build/make) rvinyard cpan2rpm-2.028-2.fc8.1 (build/make) ghenry,perl-sig ctemplate-0.91-3.fc10 (build/make) rakesh cyphesis-0.5.16-3.fc10 (build/make) wart dia-0.96.1-6.fc10 (patch_fuzz) huzaifas,huzaifas dnssec-tools-1.4.1-2.fc10 (build/make) hardaker dosbox-0.72-4.fc9 (build/make) awjb dump-0.4b41-8.fc10 (patch_fuzz) atkac eclipse-gef-3.3.0-2.fc9 (build/make) overholt eclipse-mylyn-3.0.1-2.fc10 (build/make) overholt eclipse-rpm-editor-0.4.0-1.fc10 (build/make) alcapcom,overholt eclipse-subclipse-1.2.4-11.fc9 (patch_fuzz) robmv fedora-ds-base-1.1.1-2.fc10 (build/make) rmeggins,nkinder,nhosoi fltk-1.1.8-1.fc9 (patch_fuzz) rdieter,pertusus frysk-0.4-0.fc10 (build/make) cagney,pmuldoon,swagiaal galeon-2.0.6-1.fc10 (patch_fuzz) denis gambas-1.0.19-6.fc9 (patch_fuzz) spot gdesklets-0.36-1.fc9 (unpackaged_files/python-egg-info?) luya,owentl gdmap-0.7.5-6.fc6 (build/make) splinux geronimo-specs-1.0-2.M2.fc10 (build/make) fnasser gimmix-0.4.2-3.fc9 (build/make) awjb glade2-2.12.2-2.fc9 (build/make) mclasen gmpc-0.15.5.0-3.fc9 (patch_fuzz) adrian gnome-python2-extras-2.19.1-18.fc9 (patch_fuzz) mbarnes gnumeric-1.8.2-2.fc9 (patch_fuzz) huzaifas,huzaifas goocanvas-0.10-1.fc10 (build/make) bjohnson groff-1.18.1.4-14.fc9 (patch_fuzz) kasal gtk+-1.2.10-61.fc9 (patch_fuzz) rdieter gweled-0.7-11.1 (patch_fuzz) thl hardinfo-0.4.2.3-6.fc10 (build/make) drago01 hdf-4.2r3-2.fc9 (build/make) orion,pertusus hfsutils-3.2.6-14.fc9 (patch_fuzz) dwmw2 ifplugd-0.28-11.fc9 (build/make) jamatos,rakesh indent-2.2.10-1.fc9 (patch_fuzz) rrakus ip-sentinel-0.12-11.fc9 (build/make) ensc isdn4k-utils-3.2-58.fc9 (patch_fuzz) than isomaster-1.3.3-1.fc10 (patch_fuzz) szpak jakarta-commons-net-1.4.1-4.2.fc10 (patch_fuzz) pcheung k3b-1.0.5-5.fc10 (build/make) rrakus,rdieter,tuxbrewr kaffeine-0.8.7-2.fc10 (build/make) rdieter,scop,mef kdemultimedia-4.1.1-1.fc10 (build/make) than,rdieter,kkofler,tuxbrewr,ltinkl,jreznik koffice-langpack-1.6.3-1.fc8 (build/make) awjb ladspa-1.12-9.fc9 (build/make) thomasvs lazarus-0.9.24-4.fc10 (patch_fuzz) joost libAfterImage-1.15-4.fc9 (patch_fuzz) awjb libXTrap-1.0.0-6.fc10 (build/make) ssp libXfontcache-1.0.4-5.fc9 (build/make) ssp,fonts-sig libgnomecups-0.2.3-3.fc9 (patch_fuzz) davidz libkexif-0.2.5-4.fc9 (patch_fuzz) abompard,rdieter libmatheval-1.1.5-2.fc9 (patch_fuzz) edhill libnasl-2.2.10-5.fc9 (patch_fuzz) awjb libpciaccess-0.10.3-2.fc9 (patch_fuzz) ajax librra-0.11.1-1.fc9 (build/make) awjb,abompard libzzub-0.2.3-12.fc9 (patch_fuzz) linkage-0.2.0-2.fc10 (build/make) drago01 linux-atm-2.5.0-5 (build/make) dwmw2 lock-keys-applet-1.0-14.fc9 (build/make) jorge lockdev-1.0.1-12.fc9.1 (patch_fuzz) kzak ltrace-0.5-11.45svn.fc10 (patch_fuzz) pmachata lvm2-2.02.39-3.fc10 (build/make) lvm-team,agk,mornfall,bmr,mbroz,mauelsha,dwysocha,bmarzins lybniz-1.3.2-1.fc9 (patch_fuzz) firewing mailgraph-1.14-2.fc9 (patch_fuzz) bjohnson,mfleming maven-wagon-1.0-0.1.a5.3.3.fc10 (build/make) mwringe mdadm-2.6.7-1.fc10 (patch_fuzz) dledford mediatomb-0.11.0-1.fc9 (build/make) mwiriadi mgetty-1.1.36-1.fc10 (patch_fuzz) jskala,jskala mod_python-3.3.1-7 (build/make) jorton mtools-3.9.11-4.fc9 (patch_fuzz) atkac nagios-3.0.3-6.fc10 (patch_fuzz) mmcgrath,wtogami,romal,sebastian nessus-core-2.2.10-4.fc9 (patch_fuzz) awjb netatalk-2.0.3-19.fc9 (build/make) jskala nethogs-0.7-3.20080627cvs.fc10 (build/make) afsilva nfs4-acl-tools-0.3.2-2.fc9 (patch_fuzz) steved ocsinventory-agent-0.0.9.2-1.fc10 (patch_fuzz) remi openal-0.0.9-0.15.20060204cvs.fc9 (patch_fuzz) awjb openjpeg-1.3-2.fc9 (patch_fuzz) seg osiv-2.0.0-0.4.beta.fc9 (build/make) edhill papyrus-0.7.1-3.fc9 (build/make) rvinyard pards-0.4-6.fc9 (build/make) masahase pcre-7.3-4.fc10 (patch_fuzz) kasal,lkundrak pdfedit-0.4.1-1.fc10 (patch_fuzz) bjohnson perl-Apache2-SOAP-0.73-1.fc10 (build/make) remi perl-CGI-SpeedyCGI-2.22-2.fc10 (build/make) robert perl-Catalyst-Plugin-ConfigLoader-0.20-1.fc10 (build/make) cweyl,perl-sig perl-DBIx-Class-0.08010-6.fc10 (patch_fuzz) cweyl,perl-sig perl-Event-Lib-1.03-3.fc10 (build/make) kwizart,perl-sig perl-PDF-API2-0.69-5.fc10 (patch_fuzz) bjohnson,perl-sig perl-RRD-Simple-1.43-3.fc9 (build/make) cweyl,perl-sig perl-SVN-Mirror-0.73-3.fc9 (build/make) iburrell,perl-sig piklab-0.15.3-1.fc10 (patch_fuzz) chitlesh planet-2.0-5.fc9 (patch_fuzz) richdawe poker-network-1.6.0-1.fc10 (patch_fuzz) xulchris polyxmass-bin-0.9.7-2.fc8 (build/make) awjb pyclutter-0.6.2-2.fc9 (build/make) allisson pysvn-1.5.3-1.fc10 (patch_fuzz) ravenoak python-imaging-1.1.6-10.fc10 (patch_fuzz) jamatos,jgranado python-markdown2-1.0.1.9-1.fc10 (build/make) thm pywbxml-0.1-3.fc9 (build/make) awjb pyzor-0.4.0-11.fc7 (build/make) ixs qemu-0.9.1-10.fc10 (patch_fuzz) dwmw2 qgo-1.5.4r2-1.fc9 (build/make) kaboom quake3-1.34-0.9.rc4.fc9 (patch_fuzz) laxathom queuegraph-1.1-3.fc9 (patch_fuzz) bjohnson rasqal-0.9.15-1.fc9 (build/make) thomasvs rsh-0.17-50.fc10 (patch_fuzz) atkac ruby-gnome2-0.17.0-3.fc10 (build/make) allisson ruby-rpm-1.2.3-4.fc9 (build/make) lutter,stahnma seahorse-plugins-2.24.0-2.fc10 (unpackaged_files/python-egg-info?) mclasen seamonkey-1.1.12-1.fc9 (patch_fuzz) gecko-maint,kengert seq24-0.8.7-13.fc10 (patch_fuzz) green smarteiffel-2.3-2.fc9 (build/make) gemi squid-3.0.STABLE7-1.fc10 (patch_fuzz) jskala,jsteffan,mnagy,hno,jskala straw-0.27-12.fc9 (build/make) subhodip sundials-2.3.0-6.fc9 (build/make) jpye sysvinit-2.86-24 (patch_fuzz) notting tcltls-1.5.0-16.fc9 (patch_fuzz) tjikkun tiger-3.2.1-8.fc9 (patch_fuzz) abompard time-1.7-33.fc9 (build/make) rrakus tla-1.3.5-5.fc9 (build/make) rishi uw-imap-2007b-1.fc10 (patch_fuzz) rdieter,jorton valgrind-3.3.0-3 (patch_fuzz) jakub vnc-4.1.2-34.fc10 (patch_fuzz) atkac vtk-5.0.4-24.fc9 (patch_fuzz) athimm,orion w3c-libwww-5.4.1-0.10.20060206cvs.fc9 (patch_fuzz) awjb w3lib-1.6-3.fc10 (build/make) pertusus wcstools-3.7.0-2.fc9 (build/make) sergiopr,mmahut wp_tray-0.5.3-7.fc9 (patch_fuzz) denis x3270-3.3.6-5.fc9 (patch_fuzz) karsten xautolock-2.2-5.fc9 (build/make) ianweller xdelta-1.1.4-3.fc9 (patch_fuzz) atkac xdoclet-1.2.3-9.2.fc10 (patch_fuzz) mwringe xdx-2.4-2.fc9 (build/make) bjensen,sindrepb,sconklin xfce4-panel-4.4.2-4.fc9 (patch_fuzz) kevin,cwickert xscorch-0.2.0-12.fc8 (build/make) mgarski zsh-4.3.4-8.fc9 (patch_fuzz) james With bugs filed: 5 ---------------------------------- alsa-firmware-1.0.17-1.fc10 [u'463814 NEW'] (build/make) timj gcl-2.6.7-18.fc9 [u'440913 ASSIGNED'] (build/make) gemi,green gtk-sharp-1.0.10-12.fc7 [u'434373 ASSIGNED'] (build/make) pfj libFoundation-1.1.3-11.fc9 [u'440564 ASSIGNED'] (build/make) athimm qtiplot-0.9-8.fc9 [u'434100 ASSIGNED'] (build/make) frankb ---------------------------------- Packages by owner: abompard: amarok,libkexif,librra,tiger adrian: gmpc afsilva: nethogs agk: lvm2 ajax: libpciaccess alcapcom: eclipse-rpm-editor allisson: pyclutter,ruby-gnome2 athimm: libFoundation,vtk atkac: dump,mtools,rsh,vnc,xdelta awjb: atitvout,dosbox,gimmix,koffice-langpack,libAfterImage,libnasl,librra,nessus-core,openal,polyxmass-bin,pywbxml,w3c-libwww bjensen: xdx bjohnson: goocanvas,mailgraph,pdfedit,perl-PDF-API2,queuegraph bkoz: boost bmarzins: lvm2 bmr: lvm2 cagney: frysk chitlesh: piklab cweyl: perl-Catalyst-Plugin-ConfigLoader,perl-DBIx-Class,perl-RRD-Simple cwickert: xfce4-panel davidz: libgnomecups dchen: UnihanDb deji: atlas,atlas denis: galeon,wp_tray devrim: classpathx-jaf dledford: mdadm drago01: hardinfo,linkage dwmw2: bluez-utils,hfsutils,linux-atm,qemu dwysocha: lvm2 edhill: libmatheval,osiv ensc: ip-sentinel firewing: lybniz fnasser: geronimo-specs fonts-sig: libXfontcache frankb: qtiplot gecko-maint: seamonkey gemi: gcl,smarteiffel ghenry: cpan2rpm green: gcl,seq24 hadess: bluez-utils hardaker: dnssec-tools hno: squid huzaifas: dia,dia,gnumeric,gnumeric ianweller: xautolock iburrell: perl-SVN-Mirror ixs: pyzor jakub: compat-gcc-34,valgrind jamatos: ifplugd,python-imaging james: zsh jgranado: python-imaging joost: lazarus jorge: lock-keys-applet jorton: mod_python,uw-imap jpye: sundials jreznik: kdemultimedia jskala: mgetty,mgetty,netatalk,squid,squid jsteffan: squid jwrdegoede: arm-gp2x-linux-gcc kaboom: qgo karsten: automake15,x3270 kasal: groff,pcre kengert: seamonkey kevin: xfce4-panel kkofler: kdemultimedia kwizart: perl-Event-Lib kzak: lockdev langel: azureus,azureus laxathom: quake3 lkundrak: pcre ltinkl: kdemultimedia lutter: ruby-rpm luya: gdesklets lvm-team: lvm2 masahase: pards mauelsha: lvm2 mbarnes: gnome-python2-extras mbroz: lvm2 mclasen: glade2,seahorse-plugins mef: kaffeine mfleming: mailgraph mgarski: xscorch mmahut: wcstools mmcgrath: nagios mnagy: squid mornfall: lvm2 mschwendt: audacious-plugin-fc mwiriadi: mediatomb mwringe: maven-wagon,xdoclet nhosoi: fedora-ds-base nkinder: fedora-ds-base notting: sysvinit orion: hdf,vtk overholt: eclipse-gef,eclipse-mylyn,eclipse-rpm-editor owentl: gdesklets pcheung: jakarta-commons-net perl-sig: cpan2rpm,perl-Catalyst-Plugin-ConfigLoader,perl-DBIx-Class,perl-Event-Lib,perl-PDF-API2,perl-RRD-Simple,perl-SVN-Mirror pertusus: cernlib,cernlib-g77,fltk,hdf,w3lib pfj: gtk-sharp pmachata: boost,ltrace pmuldoon: frysk rakesh: ctemplate,ifplugd ravenoak: pysvn rdieter: amarok,fltk,gtk+,k3b,kaffeine,kdemultimedia,libkexif,uw-imap remi: ocsinventory-agent,perl-Apache2-SOAP richdawe: planet rishi: tla rmeggins: fedora-ds-base robert: perl-CGI-SpeedyCGI robmv: eclipse-subclipse romal: nagios rrakus: indent,k3b,time rvinyard: bit,conexus,conexusmm,papyrus sconklin: xdx scop: kaffeine sebastian: nagios seg: openjpeg sergiopr: wcstools sindrepb: xdx splinux: gdmap spot: gambas ssp: libXTrap,libXfontcache stahnma: ruby-rpm steved: nfs4-acl-tools subhodip: straw swagiaal: frysk szpak: isomaster than: isdn4k-utils,kdemultimedia thl: gweled thm: python-markdown2 thomasvs: ladspa,rasqal timj: alsa-firmware tjikkun: tcltls tnorth: avr-binutils,avr-gcc trondd: avr-binutils,avr-gcc tuxbrewr: amarok,k3b,kdemultimedia walters: bigboard wart: bsd-games,cyphesis wtogami: nagios xulchris: poker-network -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From Matt_Domsch at dell.com Tue Sep 30 19:01:35 2008 From: Matt_Domsch at dell.com (Matt Domsch) Date: Tue, 30 Sep 2008 14:01:35 -0500 Subject: Fedora rawhide rebuild in mock status 2008-09-30 x86_64 Message-ID: <20080930190134.GA28051@mock.linuxdev.us.dell.com> Fedora Rawhide-in-Mock Build Results for x86_64 This is not a full rebuild of everything, merely a rebuild of packages failing to build over the last few weeks, using the newly-unfrozen rawhide of 9/29/2008. Failures here will cause new bugzilla bugs to be created, which will block the 'F10FTBFS' bug. My hope is that we can resolve all these before the Fedora 10 Release Candidate. 76 of these failures are due to patch fuzz. Each of those should be reviewed to ensure upstream has not already fixed the problem the patch addressed, either by applying the patch or by fixing it in another way. If the problem persists, please rebase the patch to the current source code, so it applies without fuzz, and forward your patch to the upstream package maintainer. Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ 1 Open Bugs which now build, and can be marked CLOSED RAWHIDE: file: [u'463809'] Total packages: 6261 Number failed to build: 210 Number expected to fail due to ExclusiveArch or ExcludeArch: 33 Leaving: 177 Of those expected to have worked... Without a bug filed: 173 ---------------------------------- PyAmanith-0.3.35-3.fc10 (build/make) spot PythonCard-0.8.2-1.fc10 (build/make) mmahut UnihanDb-5.1.0-7.fc10 (build/make) dchen amarok-1.90-1.fc10 (build/make) abompard,rdieter,tuxbrewr arm-gp2x-linux-gcc-4.1.2-8.fc9 (build/make) jwrdegoede audacious-plugin-fc-0.2-7 (build/make) mschwendt automake15-1.5-23 (patch_fuzz) karsten avr-binutils-2.18-2.fc9 (patch_fuzz) tnorth,trondd avr-gcc-4.1.2-6.fc9 (build/make) tnorth,trondd axis-1.2.1-4.fc10 (build/make) pcheung azureus-3.0.4.2-16.fc10 (build/make) langel,langel bigboard-0.6.2-2.fc10 (build/make) walters bit-0.4.1-3.fc9 (build/make) rvinyard bluez-utils-3.36-2.fc10 (build/make) dwmw2,hadess boost-1.34.1-16.fc10 (patch_fuzz) bkoz,pmachata bsd-games-2.17-23.fc9 (patch_fuzz) wart cernlib-2006-30.fc10 (patch_fuzz) pertusus cernlib-g77-2006-30.fc10 (patch_fuzz) pertusus classpathx-jaf-1.0-12.fc10 (build/make) devrim compat-gcc-34-3.4.6-9 (patch_fuzz) jakub conexus-0.5.3-4.fc9 (build/make) rvinyard conexusmm-0.5.0-3.fc7 (build/make) rvinyard cpan2rpm-2.028-2.fc8.1 (build/make) ghenry,perl-sig ctemplate-0.91-3.fc10 (build/make) rakesh cyphesis-0.5.16-3.fc10 (build/make) wart dia-0.96.1-6.fc10 (patch_fuzz) huzaifas,huzaifas dnssec-tools-1.4.1-2.fc10 (build/make) hardaker dosbox-0.72-4.fc9 (build/make) awjb dump-0.4b41-8.fc10 (patch_fuzz) atkac eclipse-gef-3.3.0-2.fc9 (build/make) overholt eclipse-mylyn-3.0.1-2.fc10 (build/make) overholt eclipse-rpm-editor-0.4.0-1.fc10 (build/make) alcapcom,overholt eclipse-subclipse-1.2.4-11.fc9 (patch_fuzz) robmv fedora-ds-base-1.1.1-2.fc10 (build/make) rmeggins,nkinder,nhosoi firewalk-5.0-2.fc9 (build/make) sindrepb fltk-1.1.8-1.fc9 (patch_fuzz) rdieter,pertusus freefem++-2.24-4.2.fc10 (build/make) rathann frysk-0.4-0.fc10 (build/make) cagney,pmuldoon,swagiaal galeon-2.0.6-1.fc10 (patch_fuzz) denis gauche-0.8.13-2.fc10 (build/make) gemi gauche-gl-0.4.4-3.fc9 (build/make) gemi gauche-gtk-0.4.1-17.fc9 (build/make) gemi gcombust-0.1.55-13 (build/make) thias gdesklets-0.36-1.fc9 (unpackaged_files/python-egg-info?) luya,owentl gdmap-0.7.5-6.fc6 (build/make) splinux geronimo-specs-1.0-2.M2.fc10 (build/make) fnasser gimmix-0.4.2-3.fc9 (build/make) awjb glade2-2.12.2-2.fc9 (build/make) mclasen gmpc-0.15.5.0-3.fc9 (patch_fuzz) adrian gnome-python2-extras-2.19.1-18.fc9 (patch_fuzz) mbarnes gnome-specimen-0.3-2.fc10 (unpackaged_files/python-egg-info?) splinux gnumeric-1.8.2-2.fc9 (patch_fuzz) huzaifas,huzaifas goocanvas-0.10-1.fc10 (build/make) bjohnson groff-1.18.1.4-14.fc9 (patch_fuzz) kasal gtk+-1.2.10-61.fc9 (patch_fuzz) rdieter gweled-0.7-11.1 (patch_fuzz) thl hardinfo-0.4.2.3-6.fc10 (build/make) drago01 hdf-4.2r3-2.fc9 (build/make) orion,pertusus hfsutils-3.2.6-14.fc9 (patch_fuzz) dwmw2 ifplugd-0.28-11.fc9 (build/make) jamatos,rakesh indent-2.2.10-1.fc9 (patch_fuzz) rrakus ip-sentinel-0.12-11.fc9 (build/make) ensc isdn4k-utils-3.2-58.fc9 (patch_fuzz) than isomaster-1.3.3-1.fc10 (patch_fuzz) szpak jakarta-commons-net-1.4.1-4.2.fc10 (patch_fuzz) pcheung k3b-1.0.5-5.fc10 (build/make) rrakus,rdieter,tuxbrewr kaffeine-0.8.7-2.fc10 (build/make) rdieter,scop,mef kdemultimedia-4.1.1-1.fc10 (build/make) than,rdieter,kkofler,tuxbrewr,ltinkl,jreznik koffice-langpack-1.6.3-1.fc8 (build/make) awjb ladspa-1.12-9.fc9 (build/make) thomasvs lazarus-0.9.24-4.fc10 (patch_fuzz) joost libAfterImage-1.15-4.fc9 (patch_fuzz) awjb libXTrap-1.0.0-6.fc10 (build/make) ssp libXfontcache-1.0.4-5.fc9 (build/make) ssp,fonts-sig libgii-1.0.2-6.fc9 (build/make) kwizart libgnomecups-0.2.3-3.fc9 (patch_fuzz) davidz libkexif-0.2.5-4.fc9 (patch_fuzz) abompard,rdieter libmatheval-1.1.5-2.fc9 (patch_fuzz) edhill libnasl-2.2.10-5.fc9 (patch_fuzz) awjb libpciaccess-0.10.3-2.fc9 (patch_fuzz) ajax librra-0.11.1-1.fc9 (build/make) awjb,abompard libstroke-0.5.1-17.fc9 (build/make) chitlesh libzzub-0.2.3-12.fc9 (patch_fuzz) linkage-0.2.0-2.fc10 (build/make) drago01 linux-atm-2.5.0-5 (build/make) dwmw2 lock-keys-applet-1.0-14.fc9 (build/make) jorge lockdev-1.0.1-12.fc9.1 (patch_fuzz) kzak lout-3.36-2.fc9 (build/make) spot ltrace-0.5-11.45svn.fc10 (patch_fuzz) pmachata lvm2-2.02.39-3.fc10 (build/make) lvm-team,agk,mornfall,bmr,mbroz,mauelsha,dwysocha,bmarzins lybniz-1.3.2-1.fc9 (patch_fuzz) firewing mailgraph-1.14-2.fc9 (patch_fuzz) bjohnson,mfleming maven-wagon-1.0-0.1.a5.3.3.fc10 (build/make) mwringe mdadm-2.6.7-1.fc10 (patch_fuzz) dledford mediatomb-0.11.0-1.fc9 (build/make) mwiriadi mgetty-1.1.36-1.fc10 (patch_fuzz) jskala,jskala mod_python-3.3.1-7 (build/make) jorton mtools-3.9.11-4.fc9 (patch_fuzz) atkac mysql-connector-java-3.1.12-6.fc10 (build/make) ifoox nagios-3.0.3-6.fc10 (patch_fuzz) mmcgrath,wtogami,romal,sebastian nessus-core-2.2.10-4.fc9 (patch_fuzz) awjb netatalk-2.0.3-19.fc9 (build/make) jskala nethogs-0.7-3.20080627cvs.fc10 (build/make) afsilva nfs4-acl-tools-0.3.2-2.fc9 (patch_fuzz) steved ocsinventory-agent-0.0.9.2-1.fc10 (patch_fuzz) remi openal-0.0.9-0.15.20060204cvs.fc9 (patch_fuzz) awjb openjpeg-1.3-2.fc9 (patch_fuzz) seg osiv-2.0.0-0.4.beta.fc9 (build/make) edhill papyrus-0.7.1-3.fc9 (build/make) rvinyard pards-0.4-6.fc9 (build/make) masahase pcre-7.3-4.fc10 (patch_fuzz) kasal,lkundrak pdfedit-0.4.1-1.fc10 (patch_fuzz) bjohnson perl-Apache2-SOAP-0.73-1.fc10 (build/make) remi perl-CGI-SpeedyCGI-2.22-2.fc10 (build/make) robert perl-Catalyst-Plugin-ConfigLoader-0.20-1.fc10 (build/make) cweyl,perl-sig perl-DBIx-Class-0.08010-6.fc10 (patch_fuzz) cweyl,perl-sig perl-Event-Lib-1.03-3.fc10 (build/make) kwizart,perl-sig perl-PDF-API2-0.69-5.fc10 (patch_fuzz) bjohnson,perl-sig perl-PDL-2.4.3-14.fc10 (build/make) kasal,orion,rnorwood,mmaslano perl-RRD-Simple-1.43-3.fc9 (build/make) cweyl,perl-sig perl-SVN-Mirror-0.73-3.fc9 (build/make) iburrell,perl-sig piklab-0.15.3-1.fc10 (patch_fuzz) chitlesh planet-2.0-5.fc9 (patch_fuzz) richdawe poker-network-1.6.0-1.fc10 (patch_fuzz) xulchris polyxmass-bin-0.9.7-2.fc8 (build/make) awjb pyclutter-0.6.2-2.fc9 (build/make) allisson pysvn-1.5.3-1.fc10 (patch_fuzz) ravenoak python-imaging-1.1.6-10.fc10 (patch_fuzz) jamatos,jgranado python-markdown2-1.0.1.9-1.fc10 (build/make) thm python-reportlab-2.1-2.fc9 (build/make) bpepple pywbxml-0.1-3.fc9 (build/make) awjb pyzor-0.4.0-11.fc7 (build/make) ixs qemu-0.9.1-10.fc10 (patch_fuzz) dwmw2 qgo-1.5.4r2-1.fc9 (build/make) kaboom quake3-1.34-0.9.rc4.fc9 (patch_fuzz) laxathom queuegraph-1.1-3.fc9 (patch_fuzz) bjohnson rasqal-0.9.15-1.fc9 (build/make) thomasvs rsh-0.17-50.fc10 (patch_fuzz) atkac ruby-gnome2-0.17.0-3.fc10 (build/make) allisson ruby-rpm-1.2.3-4.fc9 (build/make) lutter,stahnma seahorse-plugins-2.24.0-2.fc10 (unpackaged_files/python-egg-info?) mclasen seamonkey-1.1.12-1.fc9 (patch_fuzz) gecko-maint,kengert seq24-0.8.7-13.fc10 (patch_fuzz) green smarteiffel-2.3-2.fc9 (build/make) gemi squid-3.0.STABLE7-1.fc10 (patch_fuzz) jskala,jsteffan,mnagy,hno,jskala straw-0.27-12.fc9 (build/make) subhodip sundials-2.3.0-6.fc9 (build/make) jpye sysvinit-2.86-24 (patch_fuzz) notting tclparser-1.4-4.20061030cvs.fc9 (build/make) wart tcltls-1.5.0-16.fc9 (patch_fuzz) tjikkun tiger-3.2.1-8.fc9 (patch_fuzz) abompard time-1.7-33.fc9 (build/make) rrakus tla-1.3.5-5.fc9 (build/make) rishi tomcat5-5.5.26-1.5.fc10 (build/make) devrim,devrim uw-imap-2007b-1.fc10 (patch_fuzz) rdieter,jorton valgrind-3.3.0-3 (patch_fuzz) jakub vnc-4.1.2-34.fc10 (patch_fuzz) atkac vtk-5.0.4-24.fc9 (patch_fuzz) athimm,orion w3c-libwww-5.4.1-0.10.20060206cvs.fc9 (patch_fuzz) awjb w3lib-1.6-3.fc10 (build/make) pertusus wcstools-3.7.0-2.fc9 (build/make) sergiopr,mmahut wp_tray-0.5.3-7.fc9 (patch_fuzz) denis x3270-3.3.6-5.fc9 (patch_fuzz) karsten xautolock-2.2-5.fc9 (build/make) ianweller xcb-proto-1.2-2.fc10 (unpackaged_files/python-egg-info?) ajax xdelta-1.1.4-3.fc9 (patch_fuzz) atkac xdoclet-1.2.3-9.2.fc10 (patch_fuzz) mwringe xdx-2.4-2.fc9 (build/make) bjensen,sindrepb,sconklin xfce4-panel-4.4.2-4.fc9 (patch_fuzz) kevin,cwickert xlhtml-0.5-8.fc9 (build/make) abompard xmms-cdread-0.14-13.fc9 (build/make) jsoeterb xscorch-0.2.0-12.fc8 (build/make) mgarski zsh-4.3.4-8.fc9 (patch_fuzz) james With bugs filed: 4 ---------------------------------- alsa-firmware-1.0.17-1.fc10 [u'463814 NEW'] (build/make) timj gtk-sharp-1.0.10-12.fc7 [u'434373 ASSIGNED'] (unpackaged_files/python-egg-info?) pfj libFoundation-1.1.3-11.fc9 [u'440564 ASSIGNED'] (build/make) athimm qtiplot-0.9-8.fc9 [u'434100 ASSIGNED'] (build/make) frankb ---------------------------------- Packages by owner: abompard: amarok,libkexif,librra,tiger,xlhtml adrian: gmpc afsilva: nethogs agk: lvm2 ajax: libpciaccess,xcb-proto alcapcom: eclipse-rpm-editor allisson: pyclutter,ruby-gnome2 athimm: libFoundation,vtk atkac: dump,mtools,rsh,vnc,xdelta awjb: dosbox,gimmix,koffice-langpack,libAfterImage,libnasl,librra,nessus-core,openal,polyxmass-bin,pywbxml,w3c-libwww bjensen: xdx bjohnson: goocanvas,mailgraph,pdfedit,perl-PDF-API2,queuegraph bkoz: boost bmarzins: lvm2 bmr: lvm2 bpepple: python-reportlab cagney: frysk chitlesh: libstroke,piklab cweyl: perl-Catalyst-Plugin-ConfigLoader,perl-DBIx-Class,perl-RRD-Simple cwickert: xfce4-panel davidz: libgnomecups dchen: UnihanDb denis: galeon,wp_tray devrim: classpathx-jaf,tomcat5,tomcat5 dledford: mdadm drago01: hardinfo,linkage dwmw2: bluez-utils,hfsutils,linux-atm,qemu dwysocha: lvm2 edhill: libmatheval,osiv ensc: ip-sentinel firewing: lybniz fnasser: geronimo-specs fonts-sig: libXfontcache frankb: qtiplot gecko-maint: seamonkey gemi: gauche,gauche-gl,gauche-gtk,smarteiffel ghenry: cpan2rpm green: seq24 hadess: bluez-utils hardaker: dnssec-tools hno: squid huzaifas: dia,dia,gnumeric,gnumeric ianweller: xautolock iburrell: perl-SVN-Mirror ifoox: mysql-connector-java ixs: pyzor jakub: compat-gcc-34,valgrind jamatos: ifplugd,python-imaging james: zsh jgranado: python-imaging joost: lazarus jorge: lock-keys-applet jorton: mod_python,uw-imap jpye: sundials jreznik: kdemultimedia jskala: mgetty,mgetty,netatalk,squid,squid jsoeterb: xmms-cdread jsteffan: squid jwrdegoede: arm-gp2x-linux-gcc kaboom: qgo karsten: automake15,x3270 kasal: groff,pcre,perl-PDL kengert: seamonkey kevin: xfce4-panel kkofler: kdemultimedia kwizart: libgii,perl-Event-Lib kzak: lockdev langel: azureus,azureus laxathom: quake3 lkundrak: pcre ltinkl: kdemultimedia lutter: ruby-rpm luya: gdesklets lvm-team: lvm2 masahase: pards mauelsha: lvm2 mbarnes: gnome-python2-extras mbroz: lvm2 mclasen: glade2,seahorse-plugins mef: kaffeine mfleming: mailgraph mgarski: xscorch mmahut: PythonCard,wcstools mmaslano: perl-PDL mmcgrath: nagios mnagy: squid mornfall: lvm2 mschwendt: audacious-plugin-fc mwiriadi: mediatomb mwringe: maven-wagon,xdoclet nhosoi: fedora-ds-base nkinder: fedora-ds-base notting: sysvinit orion: hdf,perl-PDL,vtk overholt: eclipse-gef,eclipse-mylyn,eclipse-rpm-editor owentl: gdesklets pcheung: axis,jakarta-commons-net perl-sig: cpan2rpm,perl-Catalyst-Plugin-ConfigLoader,perl-DBIx-Class,perl-Event-Lib,perl-PDF-API2,perl-RRD-Simple,perl-SVN-Mirror pertusus: cernlib,cernlib-g77,fltk,hdf,w3lib pfj: gtk-sharp pmachata: boost,ltrace pmuldoon: frysk rakesh: ctemplate,ifplugd rathann: freefem++ ravenoak: pysvn rdieter: amarok,fltk,gtk+,k3b,kaffeine,kdemultimedia,libkexif,uw-imap remi: ocsinventory-agent,perl-Apache2-SOAP richdawe: planet rishi: tla rmeggins: fedora-ds-base rnorwood: perl-PDL robert: perl-CGI-SpeedyCGI robmv: eclipse-subclipse romal: nagios rrakus: indent,k3b,time rvinyard: bit,conexus,conexusmm,papyrus sconklin: xdx scop: kaffeine sebastian: nagios seg: openjpeg sergiopr: wcstools sindrepb: firewalk,xdx splinux: gdmap,gnome-specimen spot: PyAmanith,lout ssp: libXTrap,libXfontcache stahnma: ruby-rpm steved: nfs4-acl-tools subhodip: straw swagiaal: frysk szpak: isomaster than: isdn4k-utils,kdemultimedia thias: gcombust thl: gweled thm: python-markdown2 thomasvs: ladspa,rasqal timj: alsa-firmware tjikkun: tcltls tnorth: avr-binutils,avr-gcc trondd: avr-binutils,avr-gcc tuxbrewr: amarok,k3b,kdemultimedia walters: bigboard wart: bsd-games,cyphesis,tclparser wtogami: nagios xulchris: poker-network -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux