Offline Until the New Year!
Hi, all. Sincerest apologies for the lack of recent activity and the short notice here, but I'm going to be vacationing with family for the next couple of weeks. I'll return to active Fedora duty on January 2, 2010. Until then, I would very much appreciate others taking care of my packages: https://admin.fedoraproject.org/pkgdb/users/packages/pgordon Thanks very much, and have a great holiday season! :) -- Peter Gordon (codergeek42) pe...@thecodergeek.com Who am I? :: http://thecodergeek.com/about-me signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: autofs not installed by default
2009/12/18 Todd Volkert tvolk...@gmail.com: Hi Yaakov, Thanks for the response. I'm actually only installing it on one local machine, but I upgrade every Fedora release and have noticed this behavior the past few releases. I work at VMware, where every developer can install whatever OS they want to work in, and in Linux, you use ypbind to get access to your network login and shared folders. Thus, I'm using a simple install DVD. I'll look into a kickstart file, though for one machine, it sounds like it might not be worth it. Writing a kickstart is pretty easy, there are enough examples around, but going through the trouble for a once every six month process doesn't seem worth it. How do you normally install Fedora? Are you using the DVD Installer or a Live setup? With the DVD installer, you can customize the packages at install time, so you can make sure autofs is present before the machine boots up the first time. For your particular edge case, this seems like the safest bet. Kickstart is more useful for deploying larger rollouts, for example when you have three desktop machines that should all behave the same. The time it costs to set up your workflow, namely how you get the bits to the machine, say via a respun DVD via revisor or via a cobbler server makes more sense when you're doing this more than twice a year. It can turn a point and click festival into a press a button and wait experience. How much is your time at VMWare worth? -Yaakov signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
tor 2009-12-17 klockan 22:08 +0100 skrev nodata: I wish mailing list discussions were point-for-point for-and-against. It would be so much easier. You can easily accomplish this by quoting only the necessary text of the parent post and commenting between the lines. My Evolution preview window shows 38 lines of text. When _all_ of those are quoted text, the person who sent that mail did something wrong. (I'm not picking on you specifically, I think it's a general problem on this list.) Here is my point: Windows requires a reboot less often than Linux. Argue all you want, it's true. Like has been pointed out before, Fedora does not force a reboot at all. All it does is show an icon in the corner, telling me I need to log out or I need to reboot. It could gain more options, like need to restart Firefox. Linux has quicker security updates than Linux. That's an advantage. ksplice can patch a running kernel... I want suspend and resume with a new kernel. Also, ponies. :) /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
moonlight and the new covenant
Hi, according to Miguel [1], the moonlight covenant was updated and now allows for redistribution by third parties. Does it change anything wrt. its inclusion in Fedora? Julian [1] http://tirania.org/blog/archive/2009/Dec-17.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: moonlight and the new covenant
On 19/12/09 10:36, Julian Sikorski wrote according to Miguel [1], the moonlight covenant was updated and now allows for redistribution by third parties. Does it change anything wrt. its inclusion in Fedora? I doubt it's worth asking until the new covenant is actually published, which is supposed to happen next week. If what they are saying, that people who get Moonlight without being a Novell customer are covered by the patent covenant, I would hope that removes whatever stumbling block remains. Cheers Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: moonlight and the new covenant
Am Samstag, den 19.12.2009, 11:36 +0100 schrieb Julian Sikorski: Hi, according to Miguel [1], the moonlight covenant was updated and now allows for redistribution by third parties. Does it change anything wrt. its inclusion in Fedora? Julian [1] http://tirania.org/blog/archive/2009/Dec-17.html I've read that as well and was asking myself the same question. This link may be of interest as well: http://www.microsoft.com/interop/msnovellcollab/moonlight.mspx signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: moonlight and the new covenant
Am Samstag, den 19.12.2009, 10:47 + schrieb Alex Hudson: On 19/12/09 10:36, Julian Sikorski wrote according to Miguel [1], the moonlight covenant was updated and now allows for redistribution by third parties. Does it change anything wrt. its inclusion in Fedora? I doubt it's worth asking until the new covenant is actually published, which is supposed to happen next week. If what they are saying, that people who get Moonlight without being a Novell customer are covered by the patent covenant, I would hope that removes whatever stumbling block remains. Cheers Alex. The covenant is published as far as I can see here: http://www.microsoft.com/interop/msnovellcollab/moonlight.mspx I'm not a lawyer, but this does not read like it is very permissive. Just a short quote: Microsoft reserves the right to update (including discontinue) the foregoing covenant pursuant to the terms of the Moonlight for Linux Collaboration Agreement between Novell and Microsoft that was publicly announced on September 5, 2007 (the “Agreement”); however, the foregoing covenant will continue as to specific copies of Moonlight Implementations distributed by Novell before any such update. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: moonlight and the new covenant
On 19/12/09 11:00, Julian Aloofi wrote: Am Samstag, den 19.12.2009, 10:47 + schrieb Alex Hudson: I doubt it's worth asking until the new covenant is actually published, which is supposed to happen next week. The covenant is published as far as I can see here: No, that's the previous one which was not good enough. The new one is not yet published. Thanks Alex. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: moonlight and the new covenant
Am Samstag, den 19.12.2009, 11:03 + schrieb Alex Hudson: On 19/12/09 11:00, Julian Aloofi wrote: Am Samstag, den 19.12.2009, 10:47 + schrieb Alex Hudson: I doubt it's worth asking until the new covenant is actually published, which is supposed to happen next week. The covenant is published as far as I can see here: No, that's the previous one which was not good enough. The new one is not yet published. Thanks Alex. OK, thank you for clarification. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Etherpad for Fedora?
http://code.google.com/p/etherpad/ ... is anybody tempted? Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC Our lives are spectacles of powerlessness. -- Richard Rohr -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On 12/19/2009 12:31 AM, Jesse Keating wrote: Phase two, write access with ACLs, is ready for testing. Please not that URLs have changed since my original announcement. git clone ssh://[fedoraacco...@]pkgs.fedoraproject.org/package will get you a cone via ssh, in which you can git pull and git push. The repos are the same from phase1, although I've done a few commits here and there to test things. They are not tied to the CVS repos, so changes you make here are truly throw away. Please test cloning and writing to packages and branches of packages that you would normally have write access to, or normally would /not/ have write access to. I'm interested in seeing both of those cases tried. Thanks again for your help in this project! Checked that I can checkout yumex and commit at change to yumex.spec to master and F-12 branch. Checked hat I can checkout kernel (F-10 and master) and i get a W access for kernel DENIED to timlau fatal: The remote end hung up unexpectedly If i try to commit some changes to the kernel.spec So it look like it work as expected. Tim -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
2009/12/18 Jesse Keating jkeat...@redhat.com: Phase two, write access with ACLs, is ready for testing. Please not that URLs have changed since my original announcement. git clone ssh://[fedoraacco...@]pkgs.fedoraproject.org/package will get you a cone via ssh, in which you can git pull and git push. The repos are the same from phase1, although I've done a few commits here and there to test things. They are not tied to the CVS repos, so changes you make here are truly throw away. Please test cloning and writing to packages and branches of packages that you would normally have write access to, or normally would /not/ have write access to. I'm interested in seeing both of those cases tried. I checked out emacs-vm and the commited and pushed a change to the spec file and was quite surprised to find that the change was pushed to all branches. Is that intended ? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: mono and snk key files
2009/12/15 Adam Goode a...@spicenitz.org: On 12/13/2009 06:16 AM, Christopher Brown wrote: 2009/12/11 Adam Goode a...@spicenitz.org: We should definitely use Debian's key, right? Otherwise some Fedora CLI libraries would be unnecessarily incompatible with Debian, and whoever else uses Debian's key. The whole business of not shipping code-signing keys is a little contrary to open source. I think this is something that GPLv3 would prohibit. We should use a single well-known signing key for any package that we don't have the keys for, I think. You're right. This has already been resolved in devel by added mono.snk to the mono-devel package. I'm just waiting on commit access to make the required changes to F-11 and F-12 unless someone else wants to do it. It looks like spot generated a new mono.snk. I was arguing to use Debian's mono.snk, for cross-distro compatibility. Shouldn't everyone should use Debian's key unless a package provides its own? Ideally we (Fedora and Debian) should use a single key generated by upstream but as this issue is only problematic due to cyclic dep problems in the build process I think that using our own is enough. Unfortunately I don't care enough to chase this issue further. -- Christopher Brown -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: packages requiring me to reboot...
tor 2009-12-17 klockan 20:21 + skrev Ewan Mac Mahon: Simply killing the process is actually less disruptive. Yes. Please do not send close events to my Firefox windows. Do keep in mind that Firefox is pretty much broken and might not even be able to show a Do you want to restart? dialog by the time the RPM transaction is rolling, so if it's going to involve user interaction, that will have to happen in the PackageKit GUI. Another option is to make Firefox notice internally how broken it is and try to restart itself. It would need to somehow wait until the transaction is done, though. /abo -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
2009/12/19 Jonathan Underwood jonathan.underw...@gmail.com: I checked out emacs-vm and the commited and pushed a change to the spec file and was quite surprised to find that the change was pushed to all branches. Is that intended ? Er, ignore that, I was confusing myself. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Question about a lib requires
Kevin Kofler kevin.kof...@chello.at writes: Nicoleau Fabien wrote: I think I'll use : Requires: /usr/bin/jpegtran Requires: /usr/bin/tiffinfo so if one day these files are put in a different package than the lib, I won't be surprised Yeah, I've seen some libs grow a -tools subpackage for that sort of binaries. ... as, indeed, libtiff just did a few days ago. regards, tom lane -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Koji stuck?
Hi, I kicked off a couple of builds last night which appear stuck on koji. I had checked they build locally with a make mockbuild before submitting and all was fine. The builds are: http://koji.fedoraproject.org/koji/buildinfo?buildID=147755 http://koji.fedoraproject.org/koji/buildinfo?buildID=147756 Should I just cancel and resubmit, or? Cheers, Jonathan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Dec 19, 2009, at 8:42, Jonathan Underwood jonathan.underw...@gmail.com wrote: 2009/12/18 Jesse Keating jkeat...@redhat.com: Phase two, write access with ACLs, is ready for testing. Please not that URLs have changed since my original announcement. git clone ssh://[fedoraacco...@]pkgs.fedoraproject.org/package will get you a cone via ssh, in which you can git pull and git push. The repos are the same from phase1, although I've done a few commits here and there to test things. They are not tied to the CVS repos, so changes you make here are truly throw away. Please test cloning and writing to packages and branches of packages that you would normally have write access to, or normally would /not/ have write access to. I'm interested in seeing both of those cases tried. I checked out emacs-vm and the commited and pushed a change to the spec file and was quite surprised to find that the change was pushed to all branches. Is that intended ? Um, no. I'll look at this module and see what happened. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
Hi, On Fri, Dec 18, 2009 at 6:31 PM, Jesse Keating jkeat...@redhat.com wrote: Phase two, write access with ACLs, is ready for testing. Please not that URLs have changed since my original announcement. git clone ssh://[fedoraacco...@]pkgs.fedoraproject.org/package will get you a cone via ssh, in which you can git pull and git push. The repos are the same from phase1, although I've done a few commits here and there to test things. They are not tied to the CVS repos, so changes you make here are truly throw away. Please test cloning and writing to packages and branches of packages that you would normally have write access to, or normally would /not/ have write access to. I'm interested in seeing both of those cases tried. So one thing I tried is to create a custom topic branch (a la private- branches in pkgs cvs), and pushing it failed. Is this something we want to support? Or should topic branches be pushed to separate private respositories? --Ray -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Pulseaudio problem with xine, xmms and mplayer
Hi, Whenever I try to run xine, xmms or mplayer from the command line, I keep getting an error from pulseaudio Assertion 'pthread_mutex_unlock(m-mutex) == 0' failed at pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting. It makes no difference if I try to use ogg, mp3 or wav files, they all fail and die with the same error. I'm using pulseaudio-0.9.21-3.fc13 and the 2.6.32-0.65.rc8.git5.fc13.i686.PAE kernel PAM fires up and reports all the audio devices are running fine. Any ideas? TTFN Paul -- Sie können mich aufreizen und wirklich heiß machen! signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Sat, 2009-12-19 at 12:41 -0500, Ray Strode wrote: So one thing I tried is to create a custom topic branch (a la private- branches in pkgs cvs), and pushing it failed. Is this something we want to support? Or should topic branches be pushed to separate private respositories? We definitely want to allow topic branches pushed to the main repo. I think we'll have to agree on a namespace to use for these, perhaps following the dist-cvs example and call them private-* The way the ACL system works is that it matches on the refs you're pushing up, so for packages that have per-branch ACLs only the refs that match the branch have ACLs on them, and the assumption is that without an ACL you have no rights to it. That's likely why your push failed, but I'd like to see the message to confirm. It shouldn't be too hard to tweak the ACL creation script to add W access to anybody who has W access already to the private-* namespace. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Orphaned some packages
Hi all, fresh orphaned packages: (EL-4,EL-5) (Fedora) apt-mirror: APT sources mirroring tool Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/apt-mirror backintime: Simple backup system Bugs: 3 https://admin.fedoraproject.org/pkgdb/packages/bugs/backintime barrage: Kill and destroy as many targets as possible within 3 minutes Bugs: 1 https://admin.fedoraproject.org/pkgdb/packages/bugs/barrage bastet: An evil falling bricks game Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/bastet bauble: Biodiversity collection manager Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/bauble biniax: A unique arcade logic game Bugs: 1 https://admin.fedoraproject.org/pkgdb/packages/bugs/biniax fbpanel: A lightweight X11 desktop panel Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/fbpanel griffith: Media collection manager Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/griffith griv: A GTK-Chat based on the RIV-Chat-protocol Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/griv libwps: Library for reading and converting Microsoft Works word processor documents Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/libwps (EL-5) (Fedora) nssbackup: (Not so) Simple Backup Suite for desktop use Bugs: 1 https://admin.fedoraproject.org/pkgdb/packages/bugs/nssbackup peppy: Editor written in python Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/peppy python-rabbyt: Sprite library for Python Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/python-rabbyt (EL-5) (Fedora) sbackup: Simple Backup Suite for desktop use Bugs: 1 (2 on QA) https://admin.fedoraproject.org/pkgdb/packages/bugs/sbackup (EL-5) tor: Anonymizing overlay network for TCP (The onion router) Bugs: 0 (for EPEL) https://admin.fedoraproject.org/pkgdb/packages/bugs/tor (EL-5) vidalia: Controller GUI for the Tor Onion Routing Network Bugs: 0 (for epel) https://admin.fedoraproject.org/pkgdb/packages/bugs/vidalia xpad: Sticky notepad for GTK+2 Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/xpad xqf: A server browser for many popular games Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/xqf -- Mit freundlichen Grüßen aus dem schönen Hainzell Simon Wesp http://www.fedoraproject.org/wiki/SimonWesp -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Koji stuck?
On Sat, 19 Dec 2009 17:02:24 + Jonathan Underwood jonathan.underw...@gmail.com wrote: Hi, I kicked off a couple of builds last night which appear stuck on koji. I had checked they build locally with a make mockbuild before submitting and all was fine. The builds are: http://koji.fedoraproject.org/koji/buildinfo?buildID=147755 http://koji.fedoraproject.org/koji/buildinfo?buildID=147756 Should I just cancel and resubmit, or? I've seen this same thing in some other emacs packages builds. Something just causes them to get stuck. ;( I guess I would say try canceling and re-submitting, if that doesn't work, try a local mock and see if you can see where it's getting stuck. kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
Hi, We definitely want to allow topic branches pushed to the main repo. I think we'll have to agree on a namespace to use for these, perhaps following the dist-cvs example and call them private-* The way the ACL system works is that it matches on the refs you're pushing up, so for packages that have per-branch ACLs only the refs that match the branch have ACLs on them, and the assumption is that without an ACL you have no rights to it. That's likely why your push failed, but I'd like to see the message to confirm. $ git push origin private-topic-branch Total 0 (delta 0), reused 0 (delta 0) W refs/heads/private-topic-branch plymouth rstrode DENIED by fallthru error: hooks/update exited with error code 255 error: hook declined to update refs/heads/private-topic-branch To ssh://rstr...@pkgs.stg.fedoraproject.org/plymouth ! [remote rejected] private-topic-branch - private-topic-branch (hook declined) error: failed to push some refs to 'ssh://rstr...@pkgs.stg.fedoraproject.org/plymouth' --Ray -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Koji stuck?
On Sat, Dec 19, 2009 at 4:11 PM, Kevin Fenzi wrote: On Sat, 19 Dec 2009 17:02:24 + Jonathan Underwood wrote: Hi, I kicked off a couple of builds last night which appear stuck on koji. I had checked they build locally with a make mockbuild before submitting and all was fine. The builds are: http://koji.fedoraproject.org/koji/buildinfo?buildID=147755 http://koji.fedoraproject.org/koji/buildinfo?buildID=147756 Should I just cancel and resubmit, or? I've seen this same thing in some other emacs packages builds. Something just causes them to get stuck. ;( There is a -O2 flag issue that causes some builds to hang. Maybe those emacs hangs are related to this bug in gcc It happened to 2 of my packages. Removing -O2 makes things compile in my packages. (No I didn't do official builds without -O2 flag) Someone filed a bug about this a while ago but unfortunately gcc maintainers don't seem to care much. Anything we can do about this? Can we use -O1 instead? The fact is these packages will not compile if there will be a mass rebuild. And this needs to be fixed at some point before F-13 is out. Orcan PS: Some references: https://bugzilla.redhat.com/show_bug.cgi?id=548826 https://bugzilla.redhat.com/show_bug.cgi?id=531218 https://bugzilla.redhat.com/show_bug.cgi?id=538233 https://bugzilla.redhat.com/show_bug.cgi?id=539636 There are a couple more. Just search for gcc+hangs+slow etc. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
Sorry, if I missed this in previous messages... Are the cvs tags going to become git tags, or git branches? When I checked out ~48 hours ago, it seemed like everything was a git branch, which is not what I expected for the build tags. kernel.org admins recommend either 'git tag -a' or 'git tag -s' tags, and not plain 'git tag'. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Orphaned some packages
Am Samstag, den 19.12.2009, 21:44 +0100 schrieb Simon Wesp: Hi all, fresh orphaned packages: ... xpad: Sticky notepad for GTK+2 Bugs: 0 https://admin.fedoraproject.org/pkgdb/packages/bugs/xpad I have taken xpad (at least on F11 and F12, package-db wouldn't let me take it on rawhide). Regards, Christoph -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Koji stuck?
On Sat, 19 Dec 2009 17:19:37 -0500, Orcan wrote: On Sat, Dec 19, 2009 at 4:11 PM, Kevin Fenzi wrote: On Sat, 19 Dec 2009 17:02:24 + Jonathan Underwood wrote: Hi, I kicked off a couple of builds last night which appear stuck on koji. I had checked they build locally with a make mockbuild before submitting and all was fine. The builds are: http://koji.fedoraproject.org/koji/buildinfo?buildID=147755 http://koji.fedoraproject.org/koji/buildinfo?buildID=147756 Should I just cancel and resubmit, or? I've seen this same thing in some other emacs packages builds. Something just causes them to get stuck. ;( There is a -O2 flag issue that causes some builds to hang. Maybe those emacs hangs are related to this bug in gcc They just seem to hang. It happened to 2 of my packages. Removing -O2 makes things compile in my packages. (No I didn't do official builds without -O2 flag) Someone filed a bug about this a while ago but unfortunately gcc maintainers don't seem to care much. There has been activity in bugzilla.redhat.com related to this, however. See e.g. http://bugz.fedoraproject.org/gcc and look for eternity: http://bugzilla.redhat.com/532763 The temporary work-around is to compile with -fno-var-tracking-assignments and that also works for lv2-c++-tools in the review queue, btw. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Koji stuck?
On 09-12-19 17:19:37, Orcan Ogetbil wrote:
...
There is a -O2 flag issue that causes some builds to hang. Maybe
those emacs hangs are related to this bug in gcc
It happened to 2 of my packages. Removing -O2 makes things compile in
my packages. (No I didn't do official builds without -O2 flag)
Someone filed a bug about this a while ago but unfortunately gcc
maintainers don't seem to care much. Anything we can do about this?
Can we use -O1 instead? The fact is these packages will not compile
if there will be a mass rebuild. And this needs to be fixed at some
point before F-13 is out.
`man gcc` suggests that one can find out the differences between -On
levels with:
$ gcc -c -Q -O2 --help=optimizers /tmp/O2-opts
$ gcc -c -Q -O1 --help=optimizers /tmp/O1-opts
$ diff /tmp/O{1,2}-opts | grep enabled
(and the man page also lists differences).
Perhaps only one of the added optimizations is the problem and
disabling that one will fix it. A bug report about that particular
optimization on a particular file might get better results. I suppose
I'd disable half of the added optimizations at a time on a problem file
until I found the one that causes the hangs.
--
TonyN.:' mailto:tonynel...@georgeanelson.com
' http://www.georgeanelson.com/
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Koji stuck?
On Sat, Dec 19, 2009 at 6:30 PM, Michael Schwendt wrote: The temporary work-around is to compile with -fno-var-tracking-assignments and that also works for lv2-c++-tools in the review queue, btw. Thanks! Yes, with that flag I was able to finish compiling muse and lv2-c++-tools. Will that break the debuginfo package or anything else? Orcan -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Offline Until the New Year!
Safe travels! See you next year. :) -Adam (From Android - CM) On Dec 19, 2009 2:16 AM, Peter Gordon pe...@thecodergeek.com wrote: Hi, all. Sincerest apologies for the lack of recent activity and the short notice here, but I'm going to be vacationing with family for the next couple of weeks. I'll return to active Fedora duty on January 2, 2010. Until then, I would very much appreciate others taking care of my packages: https://admin.fedoraproject.org/pkgdb/users/packages/pgordon Thanks very much, and have a great holiday season! :) -- Peter Gordon (codergeek42) pe...@thecodergeek.com Who am I? :: http://thecodergeek.com/about-me -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On Dec 19, 2009, at 15:02, Jeff Garzik jgar...@pobox.com wrote: Sorry, if I missed this in previous messages... Are the cvs tags going to become git tags, or git branches? When I checked out ~48 hours ago, it seemed like everything was a git branch, which is not what I expected for the build tags. kernel.org admins recommend either 'git tag -a' or 'git tag -s' tags, and not plain 'git tag'. The cvs tags should become gi tags. If they aren't I'll have to look into it. -- Jes -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Pulseaudio problem with xine, xmms and mplayer
On Sat, Dec 19, 2009 at 18:33:38 +, Paul p...@all-the-johnsons.co.uk wrote: Whenever I try to run xine, xmms or mplayer from the command line, I keep getting an error from pulseaudio Assertion 'pthread_mutex_unlock(m-mutex) == 0' failed at pulsecore/mutex-posix.c:108, function pa_mutex_unlock(). Aborting. It makes no difference if I try to use ogg, mp3 or wav files, they all fail and die with the same error. I'm using pulseaudio-0.9.21-3.fc13 and the 2.6.32-0.65.rc8.git5.fc13.i686.PAE kernel PAM fires up and reports all the audio devices are running fine. Any ideas? This has been reported as: https://bugzilla.redhat.com/show_bug.cgi?id=548989 It isn't specifically tied to the 2.6.32 kernel, as I am using the 2.6.31 due to problems with the rawhide kernel. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: FESCo election results December 2009
On 12/18/09 12:19 PM, Paul W. Frields wrote: Election Results for FESCo - Fedora 13 Cycle Voting Period: 05 December 2009 00:00:00 UTC to 16 December 2009 23:59:59 UTC Nominations: * Adam Jackson (ajax) * Christoph Wickert (cwickert) * Justin M. Forbes (jforbes) * Matthew Garrett (mjg59) * Peter Jones (pjones) * Richard June (rjune) * Robert Scheck (rsc) Outcomes: As defined in the election text, the four (4) candidate(s) with the greatest number of votes will be elected for full 2 release term. Information: At close of voting there were: 216 valid ballots Using the Fedora Range Voting method, each candidate could attain a maximum of 864 votes (4*216). Results: 1. Adam Jackson (ajax) 1028 2. Christoph Wickert (cwickert) 934 3. Peter Jones (pjones) 820 4. Matthew Garrett (mjg59)753 * * * * * 5. Robert Scheck (rsc)663 6. Justin M. Forbes (jforbes) 535 7. Richard June (rjune) 415 As such, Adam Jackson, Christoph Wickert, Peter Jones, and Matthew Garrett are elected to FESCo for a full 2 release term. As others have said to *me* recently for other reasons... Congrats and condolences to the new FESCo members. ;) -- Jarod Wilson ja...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: dist-git proof of concept phase 2 ready for testing
On 12/19/2009 08:04 PM, Jesse Keating wrote: On Dec 19, 2009, at 15:02, Jeff Garzik jgar...@pobox.com wrote: Sorry, if I missed this in previous messages... Are the cvs tags going to become git tags, or git branches? When I checked out ~48 hours ago, it seemed like everything was a git branch, which is not what I expected for the build tags. kernel.org admins recommend either 'git tag -a' or 'git tag -s' tags, and not plain 'git tag'. The cvs tags should become gi tags. If they aren't I'll have to look into it. Yep, current pull looks fine that way. Everything is git tags, with zero git branches. Jeff -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Pyclutter Timelines -- what am I missing?
Hello everyone, I am trying to use Pyclutter to get a nice working interface for Fedora-tour since standard pygtk doesn't really fit the needs for the dynamic user interface we want to create. Unfortunately, the code I'm trying to use to create a Timeline doesn't work, and the documentation on pyclutter seems to be fairly sparse. self.timeline = clutter.Timeline() self.timeline.set_duration(500) self.timeline.set_speed(20) This should create a working timeline according to [1] but it doesn't, with python complaining about the set_duration method and, I'd assume, the set_speed method. The constructor for the Timeline should support setting these, but that also dies horribly... Could someone with some expertise in pyclutter give me a helping hand with this code? [1]: http://www.clutter-project.org/docs/pyclutter/0.9/class- cluttertimeline.html Ryan Rix -- Ryan Rix Fedora KDE SIG Member, Phoenix AZ Ambassador, News KDE Beat writer New Mail address: phrkonale...@gmail.com - r...@n.rix.si !! http://hackersramblings.wordpress.com | http://identi.ca/phrkonaleash XMPP: phrkonale...@gmail.com | MSN: phrkonale...@yahoo.com AIM: phrkonaleash| Yahoo: phrkonaleash IRC: phrkon...@irc.freenode.net/#srcedit,#plugaz,#fedora-kde and countless other FOSS channels. signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Create a -cli package without a different executable
On Fri, Dec 18, 2009 at 10:39:18PM +0100, Julian Aloofi wrote:
Am Freitag, den 18.12.2009, 18:12 +0100 schrieb Nicoleau Fabien:
Hi,
I'm packaging phatch that provides /usr/bin/phatch, a graphical
application to manage some operations on photos. It handles command
line parameters so that it can be used in a script, without a GUI :
if no parameters are given, a GUI is displayed, otherwise it acts as a
console application.
Upstream asked me if it's possible to keep phatch package, containing
the graphical requirements (and requires) and requires phatch-cli, and
create a phatch-cli, that provides /usr/bin/phatch. With this way,
people could just install phatch-cli on a server and use it with
command line parameters (but it would crash if it's not launched with
parameters).
My question is :
is it good to provide a -cli package that does not provides a separate
script or executable file, and that will work only if the user is
carefull to not launch it in a way that it does not require a graphic
lib (without parameters in that context) ?
Sounds like the goal is good but the implementation is not.
I see phatch is a python package, so I think a little trick could be
possible:
%package cli:
BuildRequires:python-devel
Requires: non-gui-dependencies
%files
{_bindir}/phatch
and for the main package:
Requires: phatch-cli
Requires: pygtk2, gui-dependencies
[install desktop file etc...]
This way users could explicitly install phatch-cli, and it would only
not start up properly if called without arguments on a terminal, and the
main package (gui version) would contain the program and pull in the
graphical dependencies.
I don't know the program though, and if the cli version depends on gui
libraries to work properly as well it wouldn't work.
This is not ideal but it needs some coding to come up with something better.
Possibilities:
* phatch with no options can attempt to import a gui lib. If that
succeeds it launches the graphical interface. If it does not succeed, it
displays the usage/help message.
* phatch is a command line app. When invoked as gphatch it starts as
a gui app instead. The phatch-gui subpackage installs a symlink from
/usr/bin/gpatch to /usr/bin/phatch as well as .desktop files.
Basically, it's great to have the option to get the functionality of the
program without having to install the GUI environment. But the program
tracebacking when the GUI environment is not present and the user typed the
command name without options is not good behaviour for a program.
-Toshio
pgpVg7jjCn8DD.pgp
Description: PGP signature
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
