Re: [ACTION REQUIRED] orphaned packages in F-14
2010/8/5 Kevin Kofler : > Bill Nottingham wrote: >> Orphan: nas >> gstreamer-plugins-bad-free requires nas-devel = 1.9.1-6.fc12 >> gstreamer-plugins-bad-free-extras requires libaudio.so.2 >> speech-dispatcher requires libaudio.so.2 >> speech-dispatcher requires nas-devel = 1.9.1-6.fc12 > > I suggest that these be just built without NAS support. NAS is basically an > older competitor to PulseAudio with fewer features (it focuses on network > transparency, which is just one of the things PulseAudio does), it is not > compatible with PulseAudio, few to no people use it. > > Kevin Kofler > > -- Agree. nas is almost dead in upstream. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
On 08/04/2010 06:32 PM, Bill Nottingham wrote: > Unblocked orphan perl-Geo-IPfree > Unblocked orphan perl-libwhisker2 I can take these two. -- Marcela Mašláňová BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
It seems a lot of java packages will be orphaned, should we contact JAVA-SIG and maven2/eclipse/intellij-idea maintainers? Regrads, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
Excerpts from Chen Lei's message of Thu Aug 05 09:10:25 +0200 2010: > It seems a lot of java packages will be orphaned, should we contact > JAVA-SIG and maven2/eclipse/intellij-idea maintainers? Unfortunately there is no JAVA-SIG though I was thinking about starting one. There has been some effort ~2 years ago but AFAIK it didn't go anywhere. See http://www.spinics.net/linux/fedora/fedora-devel-java/msg02546.html I'll be unavailable for two weeks now, but after I get back I plan to look into it more seriously... But for now I am at least letting fedora-java ML know about this (in a few minutes) Oh and taking these (most have co-maintainers, but more would be REALLY REALLY welcome): > Unblocked orphan checkstyle > Unblocked orphan junit > Unblocked orphan maven-doxia > Unblocked orphan maven-jxr > Unblocked orphan maven-surefire > Unblocked orphan velocity -- Stanislav Ochotnicky Associate Software Engineer - Base Operating Systems Brno PGP: 71A1677C Red Hat Inc. http://cz.redhat.com signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] adding missing systemd links in rawhide/F14 upgrades
On 04/08/10 20:41, "Jóhann B. Guðmundsson" wrote: > Disable selinux in grub and boot with upstart > > Grap the latest systemd packages from koji ( systemd and systemd-units ) > > Remove systemd and systemd-units ( rpm -e systemd systemd-units ) > > Reinstall systemd and systemd unit. > > reboot and allow selinux to relable the filesystem and voila > ( at least that works for me ) > > JBG Tried this, no go for me. Completly borked the system. even init-/sbin/upstart won't boot afterwards. I'll do a fresh F13 > F14-Br -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100805 changes
Compose started at Thu Aug 5 08:15:11 UTC 2010 Broken deps for x86_64 -- Mayavi-3.3.0-1.fc13.x86_64 requires python(abi) = 0:2.6 Mayavi-3.3.0-1.fc13.x86_64 requires libpython2.6.so.1.0()(64bit) PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit) PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit) QuantLib-test-1.0.1-3.fc14.x86_64 requires libboost_unit_test_framework.so.1.41.0()(64bit) 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2 1:anjuta-2.30.0.0-2.fc14.i686 requires libdevhelp-1.so.1 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libdevhelp-1.so.1()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 barry-0.17-0.1.20100329git.fc14.x86_64 requires libboost_serialization.so.1.41.0()(64bit) cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10 cairo-java-1.0.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) cyphesis-0.5.21-2.fc13.x86_64 requires libpython2.6.so.1.0()(64bit) ekg2-python-0.2-0.12.rc1.fc14.x86_64 requires libpython2.6.so.1.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(64bit) fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10 fmt-ptrn-java-1.3.20-5.fc13.x86_64 requires libgcj.so.10()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_system-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_program_options-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_iostreams-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_serialization-mt.so.1.41.0()(64bit) glib-java-0.2.6-16.fc12.i686 requires libgcj.so.10 glib-java-0.2.6-16.fc12.x86_64 requires libgcj.so.10()(64bit) 1:gnome-bluetooth-2.90.0-4.fc15.x86_64 requires gnome-bluetooth-libs = 0:2.90.0-4.fc15 1:gnome-bluetooth-libs-devel-2.90.0-4.fc15.i686 requires gnome-bluetooth-libs = 0:2.90.0-4.fc15 1:gnome-bluetooth-libs-devel-2.90.0-4.fc15.x86_64 requires gnome-bluetooth-libs = 0:2.90.0-4.fc15 1:gnome-bluetooth-moblin-2.90.0-4.fc15.x86_64 requires gnome-bluetooth-libs = 0:2.90.0-4.fc15 gnomeradio-1.8-6.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) hugin-2010.0.0-3.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) hugin-base-2010.0.0-3.fc14.i686 requires libboost_thread-mt.so.1.41.0 hugin-base-2010.0.0-3.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples kdeedu-math-4.4.95-1.fc14.py27.x86_64 requires libboost_python-mt.so.1.41.0()(64bit) libgconf-java-2.12.4-14.fc12.i686 requires libgcj.so.10 libgconf-java-2.12.4-14.fc12.x86_64 requires libgcj.so.10()(64bit) libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10 libglade-java-2.12.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10 libgnome-java-2.12.4-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgtk-java-2.8.7-13.fc13.i686 requires libgcj.so.10 libgtk-java-2.8.7-13.fc13.x86_64 requires libgcj.so.10()(64bit) 1:libguestfs-1.5.2-4.fc14.i686 requires /lib/libxtables.so.4 1:libguestfs-1.5.2-4.fc14.x86_64 requires /lib64/libxtables.so.4 libope
Re: [ACTION REQUIRED] orphaned packages in F-14
On 2010-08-04, Kevin Kofler wrote: > Bill Nottingham wrote: >> Orphan: nas >> gstreamer-plugins-bad-free requires nas-devel = 1.9.1-6.fc12 >> gstreamer-plugins-bad-free-extras requires libaudio.so.2 >> speech-dispatcher requires libaudio.so.2 >> speech-dispatcher requires nas-devel = 1.9.1-6.fc12 > > I suggest that these be just built without NAS support. NAS is basically an > older competitor to PulseAudio with fewer features (it focuses on network > transparency, which is just one of the things PulseAudio does), it is not > compatible with PulseAudio, few to no people use it. > I agree NAS is very old audio system, but it has history. It works (or should work) across operating systems (do not think only about Linux). In addition it supports bidirectional sound transmission (from microphone). PulseAudio is interresting project, but it's absolutely unusable on old slow hardware. Last time I checked it out on Pentium TSC (no MMX) running at 200 MHz, it consumed 20 % of CPU just in idle mode. While `playing', it congested CPU, printed some warnings about stream buffer overflow and terminated gracefully complaining about no CPU cycles. NAS or Esound work on the machine fluently. Thus I took NAS maintainance over and I'm going to resurrect it. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
EsounD (was: Re: [ACTION REQUIRED] orphaned packages in F-14)
On Thu, 5 Aug 2010 10:46:42 + (UTC), Petr wrote: > I agree NAS is very old audio system, but it has history. It works (or > should work) across operating systems (do not think only about Linux). > In addition it supports bidirectional sound transmission (from > microphone). > > PulseAudio is interresting project, but it's absolutely unusable on old > slow hardware. Last time I checked it out on Pentium TSC (no MMX) > running at 200 MHz, it consumed 20 % of CPU just in idle mode. While > `playing', it congested CPU, printed some warnings about stream buffer > overflow and terminated gracefully complaining about no CPU cycles. NAS > or Esound work on the machine fluently. > > Thus I took NAS maintainance over and I'm going to resurrect it. Does anybody think the same about EsounD? We still include it in Fedora. We still build lots of audio packages for it. But is it still being used by anyone? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] adding missing systemd links in rawhide upgrades
On 04/08/10 00:10, Lennart Poettering wrote: > Heya, > > just a little heads up for when you upgrade a rawhide system that is a > few weeks old to current rawhide: since we changed the way how some of > the default symlinks of systemd are created you will end up with an > installation that lacks many of the necessary symlinks -- but only if > you upgrade from a systemd version from older rawhide to current > rawhide. It's really only a problem in this case. It is not a problem > with fresh F14 installations, and it is not a problem with upgrades from > F13. The fix is easy: after upgrading just run this command as root and > the missing links should be created: > > # systemctl enable ge...@.service prefdm.service getty.target > rc-local.service remote-fs.target > > And that should make things work again. > > Sorry for the late heads-up. > > Lennart > Ah, thanks. You've saved my day. Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: EsounD (was: Re: [ACTION REQUIRED] orphaned packages in F-14)
On 2010-08-05, Michael Schwendt wrote: > On Thu, 5 Aug 2010 10:46:42 + (UTC), Petr wrote: > >> I agree NAS is very old audio system, but it has history. It works (or >> should work) across operating systems (do not think only about Linux). >> In addition it supports bidirectional sound transmission (from >> microphone). >> >> PulseAudio is interresting project, but it's absolutely unusable on old >> slow hardware. Last time I checked it out on Pentium TSC (no MMX) >> running at 200 MHz, it consumed 20 % of CPU just in idle mode. While >> `playing', it congested CPU, printed some warnings about stream buffer >> overflow and terminated gracefully complaining about no CPU cycles. NAS >> or Esound work on the machine fluently. >> >> Thus I took NAS maintainance over and I'm going to resurrect it. > > Does anybody think the same about EsounD? > We still include it in Fedora. We still build lots of audio packages > for it. But is it still being used by anyone? Frankly, I prefer EsounD over NAS as it supports IPv6 and does not have problems with volume control. Also it does not depend on X11. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F14TC2 x86_64 problem
Hi, Is there a way around this problem? I'm trying to install from DVD the TC2 image on the laptop (HP DV6 2113SA). When I click to trash the HD, the installer dies on me saying there is an error and asking me if I want to debug. I get the same problem if I try to do a custom set up. Trying the other options - shrink thinks everything is 0Mb in size and everything else is just not happy. TTFN Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F14 gnome-control-panel appearance
On Wed, 2010-08-04 at 22:58 +0200, Martin Sourada wrote: > On Wed, 2010-08-04 at 13:47 -0700, Adam Williamson wrote: > > On Wed, 2010-08-04 at 22:36 +0200, Martin Sourada wrote: > > > On Wed, 2010-08-04 at 17:33 +0100, Bastien Nocera wrote: > > > > On Wed, 2010-08-04 at 09:18 -0400, Matthias Clasen wrote: > > > > > On Wed, 2010-08-04 at 05:01 -0500, Mike Chambers wrote: > > > > > > Is this hidden somewhere, missing or not included any longer? I > > > > > > can't > > > > > > seem to find it at all. > > > > > > > > > > Parts of it will reappear soon, in different form. > > > > > > > > The whole of it will reappear for F14, it will be gone gone in F15 (eg. > > > > with GNOME 3). > > > > > > > Means with Gnome3 we'll be stuck with whatever the default > > > gtk(3)-engine, mutter/metacity theme, notification-daemon engine, fonts, > > > cursors, backgrounds will be or we will have to resort to gconf (dconf?) > > > handywork? Seems like a huge step backwards to me... > > > > He didn't say there would be nothing to *replace* it. > > I didn't understand whether he meant it will be gone altogether or > whether it will be replaced by something else -- hence the question. I'm > sorry if I phrased it too poorly... The new personalisation panel will only allow you to change background and screensaver. Changing themes/fonts of all kinds for accessibility purposes will be in the a11y panel (should already be in master upstream). If you want to tweak your UI, either use dconf/GConf, or wait until Vincent writes (or start writing it, the control-center API is exported :): http://www.hadess.net/2010/02/were-removing-settings-again.html Cheers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F14TC2 x86_64 problem
On 08/05/2010 09:06 AM, Paul Johnson wrote: > Hi, > > Is there a way around this problem? > > I'm trying to install from DVD the TC2 image on the laptop (HP DV6 > 2113SA). When I click to trash the HD, the installer dies on me saying > there is an error and asking me if I want to debug. I get the same > problem if I try to do a custom set up. Trying the other options - > shrink thinks everything is 0Mb in size and everything else is just not > happy. > > TTFN > > Paul > > See comment 9 in https://bugzilla.redhat.com/show_bug.cgi?id=620900 Worked for me. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[pkgdb] perl-IO-Compress-Bzip2 (un)retirement
Package perl-IO-Compress-Bzip2 in Fedora devel has been retired by pghmcfc To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-IO-Compress-Bzip2 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-IO-Compress-Zlib (un)retirement
Package perl-IO-Compress-Zlib in Fedora devel has been retired by pghmcfc To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-IO-Compress-Zlib -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
haldaemon seems dead...
Hi, I've installed F13 on my home box, updated and then moved it to rawhide. Everything seems more or less happy now, but it looks like haldaemon is dead. I can't burn to DVD, USB pens won't mount, the printer is unrecognised and the SCSI scanner has gone. All worked fine under F13. Any clues on how to get things running? Last updated the machine this morning (it will have caught yesterdays updates) TTFN Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: perl-IO-Compress-{Base,Bzip2,Zlib} retirment
On 05/08/10 14:35, Marcela Mašláňová wrote:
> On 08/05/2010 02:52 PM, Paul Howarth wrote:
>> The packages perl-IO-Compress-{Base,Bzip2,Zlib} are currently orphaned
>> for devel but since those modules are now bundled with perl-IO-Compress
>> (and the packages are obsoleted by it), wouldn't it be better to just
>> retire them now so they don't show up on the list of orphaned packages?
> I've marked them as dead in cvs. Pkgdb didn't contain option retire
> package. Is there anything else, what I can do with them?
If you're logged in there should be a "Retire Package" button next to
the "Take Ownership" button for orphaned packages; I retired these three
myself since you were in agreement.
Cheers, Paul.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
feature freeze?
Hello, According to schedule, there is now a feature freeze in effect. I read http://fedoraproject.org/wiki/ReleaseEngineering/FeatureFreezePolicy but it's not clear for me if I'm too late to ask a minor version update. Syslog-ng 3.1.2 was released yesterday (for details, check https://lists.balabit.hu/pipermail/syslog-ng/2010-August/014606.html ). This is a minor version update with many bugfixes. Syslog-ng is a leaf package, AFAIK, nothing depends on it. Can I still add a version update request to bugzilla, or it is too late to be included in Fedora 14? BTW: once upon a time, syslog-ng was rejected as default syslog because of its license: https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02385.html While I guess, it's too late now to make a switch now, here is some good news: http://bazsi.blogs.balabit.com/2010/07/syslog-ng-contributions-redefined.html Dual licensing will be gone with the upcoming syslog-ng v3.2. Bye, CzP / from syslog-ng upstream... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: feature freeze?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 IMO, it shouldn't be a problem for syslog-ng 3.1.2 to go in. I'll try to get to it today or tomorrow before I go on vacation. - -Doug On 08/05/2010 10:31 AM, Peter Czanik wrote: > Hello, > > According to schedule, there is now a feature freeze in effect. I read > http://fedoraproject.org/wiki/ReleaseEngineering/FeatureFreezePolicy but > it's not clear for me if I'm too late to ask a minor version update. > > Syslog-ng 3.1.2 was released yesterday (for details, check > https://lists.balabit.hu/pipermail/syslog-ng/2010-August/014606.html ). > This is a minor version update with many bugfixes. Syslog-ng is a leaf > package, AFAIK, nothing depends on it. Can I still add a version update > request to bugzilla, or it is too late to be included in Fedora 14? > > BTW: once upon a time, syslog-ng was rejected as default syslog because > of its license: > https://www.redhat.com/archives/fedora-devel-list/2007-June/msg02385.html > While > I guess, it's too late now to make a switch now, here is some good news: > http://bazsi.blogs.balabit.com/2010/07/syslog-ng-contributions-redefined.html > Dual licensing will be gone with the upcoming syslog-ng v3.2. > > Bye, > CzP / from syslog-ng upstream... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iD8DBQFMWsuEJV36su0A0xIRAtvMAJ92+25k1uT7w3Rjp6qufSaRljtYyACgwj4i 3XUOln91CQ/YOjQFbDRDiWM= =0c15 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] adding missing systemd links in rawhide/F14 upgrades
On 08/04/2010 02:54 AM, Lennart Poettering wrote: > On Wed, 04.08.10 02:40, Lennart Poettering (mzerq...@0pointer.de) wrote: > >> >> On Wed, 04.08.10 00:10, Lennart Poettering (mzerq...@0pointer.de) wrote: >> >> Small addition. When I was referring to rawhide I meant both F-14 and >> the new rawhide. i.e. both F-14 and F-15. > > And here's another addition: you might also want to run this command > when upgrading from older rwahide to current F-14/rawhide: > > # systemctl enable graphical.target > > This makes sure the default.target link is created properly > > Lennart > Hi, I tried that with no success. $ systemctl enable graphical.target Segmentation faults (core dumped) -> filled rhbz#621584 If you want some additional info, just send me an email, I'll be happy to help you debug this. Jirka -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RCS keywords rewritten in dist-git conversion?
On 02/08/10 20:53, Jesse Keating wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 08/02/2010 11:55 AM, Adam Goode wrote: >> Didn't want this to get lost, thanks for fixing this on IRC, but I don't >> have an f14 branch now. > > Got that fixed for ya. Same thing (RCS keywords rewritten) happened with php-5.3.3-aconf26x.patch in the php repo. Can that be fixed too please? Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Please help test 389 Directory Server 1.2.6 Release Candidate 6
The 389 team is pleased to announce the availability of Release Candidate 6 of version 1.2.6. This release has several bug fixes. Note: RC4 and RC5 were never released. ***We need your help! Please help us test this software.*** It is a release candidate, so it may have a few glitches, but it has been tested for regressions and for new feature bugs. The Fedora system strongly encourages packages to be in Testing until verified and pushed to Stable. If we don't get any feedback while the packages are in Testing, the packages will remain in limbo, or get pushed to Stable. The more testing we get, the faster we can release these packages to Stable. See the Release Notes for information about how to provide testing feedback (or just send an email to 389-us...@lists.fedoraproject.org). The packages that need testing are: * 389-ds-base-1.2.6.rc6 - 389-ds-base * 389-admin-1.1.11.rc2 - 389-admin More information * Release Notes - http://port389.org/wiki/Release_Notes * Install_Guide - http://port389.org/wiki/Install_Guide * Download - http://port389.org/wiki/Download === Bugs Fixed === This release contains several bug fixes. The complete list of bugs fixed is found at the link below. Note that bugs marked as MODIFIED have been fixed but are still in testing. * Tracking bug for 1.2.6 release - https://bugzilla.redhat.com/showdependencytree.cgi?id=543590&hide_resolved=0 ** Bug 617013 - repl-monitor.pl use cpu upto 90% ** Bug 616618 - 389 v1.2.5 accepts 2 identical entries with different DN format ** Bug 547503 - replication broken again, with 389 MMR replication and TCP errors ** Bug 613833 - Allow dirsrv_t to bind to rpc ports ** Bug 612242 - membership change on DS does not show on AD ** Bug 617629 - Missing aliases in new schema files ** Bug 619595 - Upgrading sub suffix under non-normalized suffix disappears ** Bug 616608 - SIGBUS in RDN index reads on platforms with strict alignments ** Bug 617862 - Replication: Unable to delete tombstone errors ** Bug 594745 - Get rid of dirsrv_lib_t label ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File CPAN-Meta-2.102160.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-CPAN-Meta: ce3149bb970fd7e14b84b348da21e696 CPAN-Meta-2.102160.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CPAN-Meta] (6 commits) ...update to 2.102160
Summary of changes: 6b047ca... Initialize branch F-13 for perl-CPAN-Meta (*) 900df03... initial import (*) ab1bfb1... - update to latest upstream (*) 9a03b8a... dist-git conversion (*) 4ae3734... Merge remote branch 'origin/f13/master' 317a986... update to 2.102160 (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CPAN-Meta: 5/6] Merge remote branch 'origin/f13/master'
commit 4ae37341bed91f2266feb4ca4e239414cd25bff5 Merge: 919c854 9a03b8a Author: Iain Arnell Date: Thu Aug 5 17:18:43 2010 +0200 Merge remote branch 'origin/f13/master' --- -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CPAN-Meta: 6/6] update to 2.102160
commit 317a98627ff629c1cf08f1c47395039ba5cc7508
Author: Iain Arnell
Date: Thu Aug 5 17:21:00 2010 +0200
update to 2.102160
.gitignore |1 +
perl-CPAN-Meta.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index eecbe6f..e00876e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
CPAN-Meta-2.101670.tar.gz
+CPAN-Meta-2.102160.tar.gz
diff --git a/perl-CPAN-Meta.spec b/perl-CPAN-Meta.spec
index 66402a9..78f8158 100644
--- a/perl-CPAN-Meta.spec
+++ b/perl-CPAN-Meta.spec
@@ -1,5 +1,5 @@
Name: perl-CPAN-Meta
-Version:2.101670
+Version:2.102160
Release:1%{?dist}
Summary:Distribution metadata for a CPAN dist
License:GPL+ or Artistic
@@ -54,6 +54,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Aug 05 2010 Iain Arnell 2.102160-1
+- update to latest upstream
+
* Wed Jun 16 2010 Iain Arnell 2.101670-1
- update to latest upstream
diff --git a/sources b/sources
index b71421c..6dbb9a6 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-fa84bb39653a6901ff1fe6a99ed20d8a CPAN-Meta-2.101670.tar.gz
+ce3149bb970fd7e14b84b348da21e696 CPAN-Meta-2.102160.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CPAN-Meta/f14/master] (6 commits) ...update to 2.102160
Summary of changes: 6b047ca... Initialize branch F-13 for perl-CPAN-Meta (*) 900df03... initial import (*) ab1bfb1... - update to latest upstream (*) 9a03b8a... dist-git conversion (*) 4ae3734... Merge remote branch 'origin/f13/master' (*) 317a986... update to 2.102160 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CPAN-Meta/f13/master] (7 commits) ...update to 2.102160
Summary of changes: d26a58c... initial import (*) 061f0a3... - rebuild for perl-5.12 (*) c1d42ee... - update to latest upstream (*) ae1c1e8... - update to latest upstream (*) 919c854... dist-git conversion (*) 4ae3734... Merge remote branch 'origin/f13/master' (*) 317a986... update to 2.102160 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File CPAN-Uploader-0.102150.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-CPAN-Uploader: c6f5c3a7252125f878a208f0c6ff504c CPAN-Uploader-0.102150.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CPAN-Uploader] update to 0.102150
commit 50856c23550fdc27d49605acf015339f1d607805
Author: Iain Arnell
Date: Thu Aug 5 17:28:05 2010 +0200
update to 0.102150
.gitignore |1 +
perl-CPAN-Uploader.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8485d18..7563bdd 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
CPAN-Uploader-0.101670.tar.gz
+CPAN-Uploader-0.102150.tar.gz
diff --git a/perl-CPAN-Uploader.spec b/perl-CPAN-Uploader.spec
index dba85bc..9105c02 100644
--- a/perl-CPAN-Uploader.spec
+++ b/perl-CPAN-Uploader.spec
@@ -1,5 +1,5 @@
Name: perl-CPAN-Uploader
-Version:0.101670
+Version:0.102150
Release:1%{?dist}
Summary:Upload things to the CPAN
License:GPL+ or Artistic
@@ -65,6 +65,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Aug 05 2010 Iain Arnell 0.102150-1
+- update to latest upstream
+
* Fri Jun 18 2010 Iain Arnell 0.101670-1
- update to latest upstream
diff --git a/sources b/sources
index e88ce87..cc86029 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-644b8650166bf9bcb91b1ddde1a58e82 CPAN-Uploader-0.101670.tar.gz
+c6f5c3a7252125f878a208f0c6ff504c CPAN-Uploader-0.102150.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CPAN-Uploader/f14/master] update to 0.102150
Summary of changes: 50856c2... update to 0.102150 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: EsounD (was: Re: [ACTION REQUIRED] orphaned packages in F-14)
On Thu, 05.08.10 12:58, Michael Schwendt (mschwe...@gmail.com) wrote: > On Thu, 5 Aug 2010 10:46:42 + (UTC), Petr wrote: > > > I agree NAS is very old audio system, but it has history. It works (or > > should work) across operating systems (do not think only about Linux). > > In addition it supports bidirectional sound transmission (from > > microphone). > > > > PulseAudio is interresting project, but it's absolutely unusable on old > > slow hardware. Last time I checked it out on Pentium TSC (no MMX) > > running at 200 MHz, it consumed 20 % of CPU just in idle mode. While > > `playing', it congested CPU, printed some warnings about stream buffer > > overflow and terminated gracefully complaining about no CPU cycles. NAS > > or Esound work on the machine fluently. > > > > Thus I took NAS maintainance over and I'm going to resurrect it. > > Does anybody think the same about EsounD? > We still include it in Fedora. We still build lots of audio packages > for it. But is it still being used by anyone? Well, we actually wanted to orphan it a couple of releases ago. However I took up nominal maintainership of the package, simply because some closed source stuff still speaks the esd proto and I need something to test the PA proto implementation against. So I basically consider esd package a test case for myself, and that's the sole reason I maintain it. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-CPAN-Uploader] (5 commits) ...Merge remote branch 'origin/f13/master'
Summary of changes: 0e8c20a... Initialize branch F-13 for perl-CPAN-Uploader (*) 5db7aec... initial import (*) 71fd375... - update to latest upstream (*) 708ba4c... dist-git conversion (*) e3a77fa... Merge remote branch 'origin/f13/master' (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CPAN-Uploader: 5/5] Merge remote branch 'origin/f13/master'
commit e3a77fa65db0e97554ff58ed90fbb8b2217fa68e Merge: 50856c2 708ba4c Author: Iain Arnell Date: Thu Aug 5 17:33:58 2010 +0200 Merge remote branch 'origin/f13/master' --- -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CPAN-Uploader/f13/master] (9 commits) ...Merge remote branch 'origin/f13/master'
Summary of changes: b8b9a5a... initial import (*) a33e406... - Mass rebuild with perl-5.12.0 (*) 27473af... - update to latest upstream (*) 22c95f3... - bump release for rebuild with perl-5.12.0 (*) 0fb9505... - update to latest upstream (*) 05fcdc7... - update to latest upstream (*) a241413... dist-git conversion (*) 50856c2... update to 0.102150 (*) e3a77fa... Merge remote branch 'origin/f13/master' (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CPAN-Uploader/f14/master] (5 commits) ...Merge remote branch 'origin/f13/master'
Summary of changes: 0e8c20a... Initialize branch F-13 for perl-CPAN-Uploader (*) 5db7aec... initial import (*) 71fd375... - update to latest upstream (*) 708ba4c... dist-git conversion (*) e3a77fa... Merge remote branch 'origin/f13/master' (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
boot.fedoraproject.org
At first glance, this new way of installation seems great for remote installing: exactly what I was expecting for months. However I have some problems using it on a 2006 IBM xServer. After reading the BFO FAQ, I have searched for a website where to get more help and/or report bugs, without success: every link I found sent me to BKO or etherboot.org, nothing specific to BFO. _ Does anybody know about some support structure (BZ or whatever) for this product ? _ Where to get the full sources to rebuild it ? Thanks in advance for any hint. Patrick -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boot.fedoraproject.org
On 05/08/10 17:02, Patrick MONNERAT wrote: > Thanks in advance for any hint. > > Patrick > send an email to: ad...@fedoraproject.org Subject: BFO The right people will get back to you. -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Perl-MinimumVersion-1.26.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-Perl-MinimumVersion: faf35e902d98fdfeca35f298d1553a68 Perl-MinimumVersion-1.26.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 620937] perl-Compress-Raw-Zlib "update" does not update
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=620937 --- Comment #6 from Michal Jaegermann 2010-08-05 12:51:33 EDT --- (In reply to comment #5) > Thank you Paul for great explanation. > > Michael, do you have any other questions. As long as everybody involved is fully aware what is happening then I think this is OK. OTOH I know that situations "(nearly) the same thing in two different independent places" on a long range have a nasty habit of biting back one way or another. Myself I would try hard not to get into something like that. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Perl-MinimumVersion] * Thu Aug 05 2010 Ralf Corsépius - 1.26-1 - Upstream update.
commit 6b79a7e2940d359dad79433f4e8272f94ae0745d
Author: Ralf Corsépius
Date: Thu Aug 5 18:50:54 2010 +0200
* Thu Aug 05 2010 Ralf Corsépius - 1.26-1
- Upstream update.
* Tue May 04 2010 Marcela Maslanova - 1.24-3
- Mass rebuild with perl-5.12.0
.gitignore|1 +
perl-Perl-MinimumVersion.spec |9 +
sources |2 +-
3 files changed, 7 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 6dae4bb..51239c5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Perl-MinimumVersion-1.24.tar.gz
+Perl-MinimumVersion-1.26.tar.gz
diff --git a/perl-Perl-MinimumVersion.spec b/perl-Perl-MinimumVersion.spec
index d6c685a..4f62d68 100644
--- a/perl-Perl-MinimumVersion.spec
+++ b/perl-Perl-MinimumVersion.spec
@@ -1,12 +1,11 @@
Name: perl-Perl-MinimumVersion
-Version:1.24
-Release:3%{?dist}
+Version:1.26
+Release:1%{?dist}
Summary:Find a minimum required version of perl for Perl code
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Perl-MinimumVersion/
Source0:
http://search.cpan.org/CPAN/authors/id/A/AD/ADAMK/Perl-MinimumVersion-%{version}.tar.gz
-Patch0: Perl-MinimumVersion-25.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
$version))
@@ -34,7 +33,6 @@ Find a minimum required version of perl for Perl code
%prep
%setup -q -n Perl-MinimumVersion-%{version}
-%patch0 -p1
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
@@ -62,6 +60,9 @@ make test AUTOMATED_TESTING=1
%{_mandir}/man3/*
%changelog
+* Thu Aug 05 2010 Ralf Corsépius - 1.26-1
+- Upstream update.
+
* Tue May 04 2010 Marcela Maslanova - 1.24-3
- Mass rebuild with perl-5.12.0
diff --git a/sources b/sources
index 6d6b7a5..8c53c93 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-307a1ebae711026396ba307d2ef7e4ab Perl-MinimumVersion-1.24.tar.gz
+faf35e902d98fdfeca35f298d1553a68 Perl-MinimumVersion-1.26.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Perl-MinimumVersion] * Thu Aug 05 2010 Ralf Corsépius - 1.26-1 - Upstream update.
commit 2e91a0db2a086b0caf10277b50b48dd6c09982bb Author: Ralf Corsépius Date: Thu Aug 5 18:55:48 2010 +0200 * Thu Aug 05 2010 Ralf Corsépius - 1.26-1 - Upstream update. * Tue May 04 2010 Marcela Maslanova - 1.24-3 - Mass rebuild with perl-5.12.0 Perl-MinimumVersion-25.patch | 2107 -- 1 files changed, 0 insertions(+), 2107 deletions(-) -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
root-doc subpackage slightly obese
So I'm syncing up our school's local mirror over our rather slow internet connection and I notice that the root-doc subpackage (which is part of the root package) has just hit the slightly obese size of 687MB [1]. For reference, the root source rpm is 27MB [2]. Now, I don't know if we have a policy for autogenerated documentation, but this seems a bit over the top to me, especially since the 20153 files in this package seem to have increased the size of filelists.xml.gz by 200KB (this is a guess based on the fact that that's how much filelists.xml.gz has increased in the last push). So now I've added root-docs to my manual rsync excludes (which only had kdelibs-apidocs in it before now). Can we have a guideline added to the packaging guidelines that basically says, "Make sure autogenerated documentation isn't ridiculously large". Jonathan "I need to go on a diet" Dieter [1] http://koji.fedoraproject.org/koji/rpminfo?rpmID=2101751 [2] http://koji.fedoraproject.org/koji/rpminfo?rpmID=2101735 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Alpha Can Still Ship on Time IF these bugs get attention TODAY
John Poelstra said the following on 08/04/2010 10:48 AM Pacific Time: > > In order for Release Engineering to create the Fedora 14 Alpha RC, all > of the bugs below must be in a state of CLOSED or ON_QA by > tomorrow--Bodhi updates have been submitted and the packages are in > updates-testing. And, no new blocker bugs are identified before then. > > If there are other bugs that are of concern that you believe meet the > release criteria, add 'f14alpha' as a blocker or ask for help on #fedora-qa. > Going solely by the bugzilla comments which is where the latest information should be, it is very unclear (I would suggest unlikely) that we will be able to request a Release Candidate compose for the Fedora 14 Alpha from Release Engineering today. I know folks are busy with lots of different things. Without more information about what is happening or planned to happen next we don't have any other options. The result will be late release. John Here are the unfixed bugs we are waiting for more information on: 583731 [NEW - high - m...@romal.de - --- -] man-pages-de has file conflicts with man-db [See dependency tree for bug 583731] 596985 [NEW - urgent - jgli...@redhat.com - --- - Triaged] hang at start of X11 on fresh install from DVD [See dependency tree for bug 596985] 597858 [NEW - high - dwa...@redhat.com - --- -] "SELinux is preventing firefox from making its memory writable and executable." crashes rawhide firefox start 512845 [ASSIGNED - high - stran...@redhat.com - --- - Reopened, Security, SELinux, Triaged] setroubleshoot: SELinux is preventing firefox from changing a writable memory segment executable. 620623 [ASSIGNED - medium - nott...@redhat.com - --- -] Packages with unresolved dependencies [See dependency tree for bug 620623] 620949 [ASSIGNED - medium - rstr...@redhat.com - --- -] [abrt] gnome-panel-2.31.4-3.fc14: Process /usr/bin/gnome-panel was killed by signal 11 (SIGSEGV) 621030 [ASSIGNED - medium - wwo...@redhat.com - --- -] Fail to save traceback to bugzilla ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Alpha Can Still Ship on Time IF these bugs get attention TODAY
On 08/05/2010 12:59 PM, John Poelstra wrote: > 597858 [NEW - high - dwa...@redhat.com - --- -] "SELinux is preventing > firefox from making its memory writable and executable." crashes rawhide > firefox start The update to fix this one out is here: https://admin.fedoraproject.org/updates/selinux-policy-3.8.8-10.fc14 ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F14 gnome-control-panel appearance
On Thu, 2010-08-05 at 14:09 +0100, Bastien Nocera wrote: > The new personalisation panel will only allow you to change background > and screensaver. Changing themes/fonts of all kinds for accessibility > purposes will be in the a11y panel (should already be in master > upstream). > Interesting design decision, although I can see the connection of themes/fonts to a11y, I fail to see why the splitting of the appearance settings... Anyway thanks for the answer :) > If you want to tweak your UI, either use dconf/GConf, or wait until > Vincent writes (or start writing it, the control-center API is > exported :): > http://www.hadess.net/2010/02/were-removing-settings-again.html > Hehe, nice :) Cheers, Martin signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Alpha Can Still Ship on Time IF these bugs get attention TODAY
On Thu, 2010-08-05 at 13:08 -0400, Tom "spot" Callaway wrote: > On 08/05/2010 12:59 PM, John Poelstra wrote: > > 597858 [NEW - high - dwa...@redhat.com - --- -] "SELinux is preventing > > firefox from making its memory writable and executable." crashes rawhide > > firefox start > > The update to fix this one out is here: > > https://admin.fedoraproject.org/updates/selinux-policy-3.8.8-10.fc14 Can someone add bug#597858 to the list of bugs fixed by that bodhi update? Thanks, James signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100805 changes
On Thu, Aug 05, 2010 at 10:46:08AM +, Rawhide Report wrote: > 1:libguestfs-1.5.2-4.fc14.i686 requires /lib/libxtables.so.4 > 1:libguestfs-1.5.2-4.fc14.x86_64 requires /lib64/libxtables.so.4 Unfortunately qemu isn't installable at the moment so I can't rebuild this. The error is: DEBUG util.py:255: Error: Package: 2:qemu-system-x86-0.13.0-0.2.20100727gitb81fe95.fc14.x86_64 (build) DEBUG util.py:255: Requires: /usr/share/gpxe/e1000-0x100e.rom Also I'm on vacation at the moment, but if anyone else wants to try rebuilding, then a simple 'fedpkg build' should work once the above is fixed. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Creating private branches under fedpkg/git
On Wed, Aug 04, 2010 at 11:01:45PM +0100, M A Young wrote: > What is the policy on creating private branches under fedpkg/git? Can it > be done by anyone with acl commit or do you need special permissions? > > My interest is that I had a private branch of the kernel package under CVS > which I used to build pvops enabled kernels so that the more adventurous > could use a Fedora based Domain-0 kernel with xen. However this branch > hasn't been copied across (presumably because of the difficulties in > transfering the kernel package) though I could easily continue from a new > branch if that is appropriate. Surely with git you just make a branch in your own repository? Or do you need private branches which are shared with some others? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root-doc subpackage slightly obese
On Thu, 2010-08-05 at 19:56 +0300, Jonathan Dieter wrote: > So I'm syncing up our school's local mirror over our rather slow > internet connection and I notice that the root-doc subpackage (which is > part of the root package) has just hit the slightly obese size of 687MB > [1]. For reference, the root source rpm is 27MB [2]. > > Now, I don't know if we have a policy for autogenerated documentation, > but this seems a bit over the top to me, especially since the 20153 > files in this package seem to have increased the size of > filelists.xml.gz by 200KB (this is a guess based on the fact that that's > how much filelists.xml.gz has increased in the last push). > > So now I've added root-docs to my manual rsync excludes (which only had > kdelibs-apidocs in it before now). > > Can we have a guideline added to the packaging guidelines that basically > says, "Make sure autogenerated documentation isn't ridiculously large". > grumble. Thank you for noting this. Jonathan, - dish this to fesco and/or the Packaging Committee - it's a good point. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
On 08/04/2010 12:32 PM, Bill Nottingham wrote: > Each release, we undergo the effort to track down owners for orphaned > packages in the release, and block those orphaned packages where > necessary. It's that time again for Fedora 14. > minirpc was orphaned because development has stopped upstream, there are memory corruption bugs that have not been successfully tracked down (after lots of attempts), and there are no known users. So it can pretty much be retired. Adam signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F14 gnome-control-panel appearance
On Thu, Aug 5, 2010 at 19:14, Martin Sourada wrote: > On Thu, 2010-08-05 at 14:09 +0100, Bastien Nocera wrote: > >> If you want to tweak your UI, either use dconf/GConf, or wait until >> Vincent writes (or start writing it, the control-center API is >> exported :): >> http://www.hadess.net/2010/02/were-removing-settings-again.html >> > Hehe, nice :) Reminds me of the gdmsetup removal (was it 2008 ?). I had a look around today and found some of the options in accounts-dialog . Changing the default background is in Appearance Preference, which seems to go away again now. I love progress, but it does not love me back :-) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Alpha Can Still Ship on Time IF these bugs get attention TODAY
Am Thu, 05 Aug 2010 09:59:52 -0700 schrieb John Poelstra: > John Poelstra said the following on 08/04/2010 10:48 AM Pacific Time: > Here are the unfixed bugs we are waiting for more information on: > > 583731 [NEW - high - m...@romal.de - --- -] man-pages-de has file > conflicts with man-db [See dependency tree for bug 583731] [snip] This should be fixed in: https://admin.fedoraproject.org/updates/man-pages-de-0.5-4.fc14 Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root-doc subpackage slightly obese
On Thu, Aug 05, 2010 at 01:23:24PM -0400, seth vidal wrote: > On Thu, 2010-08-05 at 19:56 +0300, Jonathan Dieter wrote: > > So I'm syncing up our school's local mirror over our rather slow > > internet connection and I notice that the root-doc subpackage (which is > > part of the root package) has just hit the slightly obese size of 687MB > > [1]. For reference, the root source rpm is 27MB [2]. > > > > Now, I don't know if we have a policy for autogenerated documentation, > > but this seems a bit over the top to me, especially since the 20153 > > files in this package seem to have increased the size of > > filelists.xml.gz by 200KB (this is a guess based on the fact that that's > > how much filelists.xml.gz has increased in the last push). > > > > So now I've added root-docs to my manual rsync excludes (which only had > > kdelibs-apidocs in it before now). > > > > Can we have a guideline added to the packaging guidelines that basically > > says, "Make sure autogenerated documentation isn't ridiculously large". > > > > grumble. > > Thank you for noting this. > > Jonathan, - dish this to fesco and/or the Packaging Committee - it's a > good point. > I don't think we could just say don't package documentation that's ridiculously large but perhaps we could make some sort of guideline about not duplicating formats on extra large docs. Is the case with root-docs (and/or kdelibs-apidocs) that we have docs in text + html + tex + pdf + your_format_here? -Toshio pgpFSyurWZi12.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: haldaemon seems dead...
On Thu, 2010-08-05 at 14:53 +0100, Paul Johnson wrote: > Hi, > > I've installed F13 on my home box, updated and then moved it to > rawhide. Everything seems more or less happy now, but it looks like > haldaemon is dead. I can't burn to DVD, USB pens won't mount, the > printer is unrecognised and the SCSI scanner has gone. All worked fine > under F13. None of this uses HAL... > Any clues on how to get things running? Last updated the machine this > morning (it will have caught yesterdays updates) > > TTFN > > Paul > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Build on dist-git for F-14: FAILED: GenericError: Build already exists
Hi,
I'm trying to build gource for F-14 and I get the following error:
=
[siddh...@spoyarek gource]$ git branch
* f14
master
[siddh...@spoyarek gource]$ fedpkg build
Created task: 2382335
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=2382335
Watching tasks (this may be safely interrupted)...
2382335 build (dist-f14-updates-candidate,
/gource:94e27ff92af9990ba724746702f7e34c50af0ae1): free
2382335 build (dist-f14-updates-candidate,
/gource:94e27ff92af9990ba724746702f7e34c50af0ae1): free -> open
(x86-10.phx2.fedoraproject.org)
2382337 buildSRPMFromSCM (/gource:94e27ff92af9990ba724746702f7e34c50af0ae1):
open (x86-01.phx2.fedoraproject.org)
2382337 buildSRPMFromSCM (/gource:94e27ff92af9990ba724746702f7e34c50af0ae1):
open (x86-01.phx2.fedoraproject.org) -> closed
0 free 1 open 1 done 0 failed
2382335 build (dist-f14-updates-candidate,
/gource:94e27ff92af9990ba724746702f7e34c50af0ae1): open
(x86-10.phx2.fedoraproject.org) -> FAILED: GenericError: Build already exists
(id=188463, state=COMPLETE): {'name': 'gource', 'task_id': 2382335, 'pkg_id':
9935, 'epoch': None, 'completion_time': None, 'state': 0, 'version': '0.27',
'owner': 1323, 'release': '1', 'id': 188463}
0 free 0 open 1 done 1 failed
2382335 build (dist-f14-updates-candidate,
/gource:94e27ff92af9990ba724746702f7e34c50af0ae1) failed
=
snippet of .git/config to ensure that branches are pointing to the
correct remote:
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "f14"]
remote = origin
merge = refs/heads/f14/master
=
Is anyone facing a similar problem? I guess I may be doing something
wrong in the process, but I haven't been able to figure out yet. I was
able to build successfully for rawhide, which is the build that the
above build claims to be the duplicate of:
http://koji.fedoraproject.org/koji/buildinfo?buildID=188463
Also, probably an unrelated question, but aren't tags added to the scm
anymore with the build? I expected a 0.27 tag to be added to master,
but that did not happen.
--
Thanks,
Siddhesh
PS: I like the look of dist-git with the _real_ branches. Thanks for
all the awesome work!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Alpha Can Still Ship on Time IF these bugs get attention TODAY
Tom "spot" Callaway said the following on 08/05/2010 10:08 AM Pacific Time: > On 08/05/2010 12:59 PM, John Poelstra wrote: >> 597858 [NEW - high - dwa...@redhat.com - --- -] "SELinux is preventing >> firefox from making its memory writable and executable." crashes rawhide >> firefox start > > The update to fix this one out is here: > > https://admin.fedoraproject.org/updates/selinux-policy-3.8.8-10.fc14 > > ~spot That's excellent information to put in the bug. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Alpha Can Still Ship on Time IF these bugs get attention TODAY
Thomas Spura said the following on 08/05/2010 11:22 AM Pacific Time: > Am Thu, 05 Aug 2010 09:59:52 -0700 > schrieb John Poelstra: > >> John Poelstra said the following on 08/04/2010 10:48 AM Pacific Time: >> Here are the unfixed bugs we are waiting for more information on: >> >> 583731 [NEW - high - m...@romal.de - --- -] man-pages-de has file >> conflicts with man-db [See dependency tree for bug 583731] > [snip] > > This should be fixed in: > https://admin.fedoraproject.org/updates/man-pages-de-0.5-4.fc14 > > Thomas Please put that information in the bug. Thanks, John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Build on dist-git for F-14: FAILED: GenericError: Build already exists
On Fri, 6 Aug 2010 00:17:23 +0530, Siddhesh wrote:
> Hi,
>
> I'm trying to build gource for F-14 and I get the following error:
> 2382335 build (dist-f14-updates-candidate,
> /gource:94e27ff92af9990ba724746702f7e34c50af0ae1): open
> (x86-10.phx2.fedoraproject.org) -> FAILED: GenericError: Build already exists
> (id=188463, state=COMPLETE): {'name': 'gource', 'task_id': 2382335, 'pkg_id':
> 9935, 'epoch': None, 'completion_time': None, 'state': 0, 'version': '0.27',
> 'owner': 1323, 'release': '1', 'id': 188463}
> 0 free 0 open 1 done 1 failed
> http://koji.fedoraproject.org/koji/buildinfo?buildID=188463
You don't use %{?dist} in your "Release" value, and the 0.27-1 build
is already done. There can be only one build with that version-release.
> Also, probably an unrelated question, but aren't tags added to the scm
> anymore with the build? I expected a 0.27 tag to be added to master,
> but that did not happen.
It's not done yet. Where you want tags, you could use:
git tag $(fedpkg verrel)
git push --tags
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Alpha Can Still Ship on Time IF these bugs get attention TODAY
On Thu, 2010-08-05 at 11:46 -0700, John Poelstra wrote: > Tom "spot" Callaway said the following on 08/05/2010 10:08 AM Pacific Time: > > On 08/05/2010 12:59 PM, John Poelstra wrote: > >> 597858 [NEW - high - dwa...@redhat.com - --- -] "SELinux is preventing > >> firefox from making its memory writable and executable." crashes rawhide > >> firefox start > > > > The update to fix this one out is here: > > > > https://admin.fedoraproject.org/updates/selinux-policy-3.8.8-10.fc14 > > > > ~spot > > That's excellent information to put in the bug. Bodhi does this automatically if you add the bug number to the update when you create it [1]; not sure if it does it when adding a bug to an already-created update. In my mind, bodhi ought to moved NEW and ASSIGNED bugs to MODIFIED when an update is created that references them, to signify that a build is available for testing, but is not yet known to fix the bug. However it doesn't seem to do this. Is this a policy decision in Fedora's bug workflow, or merely an RFE I need to file against Bodhi? Hope this is helpful Dave [1] This is very useful for maintaining one's sanity when handling large numbers of updates -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Alpha Can Still Ship on Time IF these bugs get attention TODAY
On Thu, 2010-08-05 at 09:59 -0700, John Poelstra wrote: [snip] > Here are the unfixed bugs we are waiting for more information on: [snip] > 621030 [ASSIGNED - medium - wwo...@redhat.com - --- -] Fail to save > traceback to bugzilla wwoods created a patch which has seen some testing; update has been created (which is listed in the bug) http://admin.fedoraproject.org/updates/python-bugzilla-0.6.1-3.fc14 This update needs testing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root-doc subpackage slightly obese
On Thu, 2010-08-05 at 14:24 -0400, Toshio Kuratomi wrote: > I don't think we could just say don't package documentation that's > ridiculously large but perhaps we could make some sort of guideline about > not duplicating formats on extra large docs. Is the case with root-docs > (and/or kdelibs-apidocs) that we have docs in text + html + tex + pdf > + your_format_here? The problem is that, at least for root-doc (not sure about kdelibs-apidocs), it's all html. Please note that I'm not saying "don't package documentation that's ridiculously large", but rather, "don't package automatically generated documentation that's ridiculously large". Jonathan signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Integrity protection of fetches
On Wed, 04 Aug 2010 22:03:14 +0200 Till Maas wrote: > On Wed, Aug 04, 2010 at 09:42:01AM -0700, Adam Williamson wrote: > > > I suspect it might short-circuit the 'ahhh, but what about...' > > 'oooh, but then I can...' nature of the conversation if you just > > put together a proof-of-concept attack and document it somewhere. I > > suspect the git maintainers might be interested at that point as > > well. :) > > The attack is quite trivial: > 1) clone the git pkg Fedora repos > 2) commit some nasty change > 3) publish the repo on some server > 4) if the victim wants to fetch from the Fedora pkg repo, use the MITM > attack to make him fetch from the server set up in step 3. Steps 1-3 > can obviously be done on-demand. > > If this is e.g. done on a conference / FUDCon / Fedora Action Day, the > attack can easily targeted to make the change in step 2 be expected to > be fast forward. E.g. if packages simply need to be bumped for a > rebuild, a upload of a bad tarball and modification of the sources > file might be unnoticed. Just to clarify, as this is a long thread: This only works if people are using git:// urls, not the default for fedora ssh: ones, right? (provided you have connected before to pkgs.fedoraproject.org and have the known_hosts entry?) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Alpha Can Still Ship on Time IF these bugs get attention TODAY
On Thu, 2010-08-05 at 15:07 -0400, David Malcolm wrote: > On Thu, 2010-08-05 at 09:59 -0700, John Poelstra wrote: > > [snip] > > > Here are the unfixed bugs we are waiting for more information on: > > [snip] > > > 621030 [ASSIGNED - medium - wwo...@redhat.com - --- -] Fail to save > > traceback to bugzilla > wwoods created a patch which has seen some testing; update has been > created (which is listed in the bug) Bug 621298, actually; 621030 got marked as a dup of this. http://admin.fedoraproject.org/updates/python-bugzilla-0.6.1-3.fc14 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root-doc subpackage slightly obese
On Thu, Aug 5, 2010 at 3:11 PM, Jonathan Dieter wrote: > On Thu, 2010-08-05 at 14:24 -0400, Toshio Kuratomi wrote: >> I don't think we could just say don't package documentation that's >> ridiculously large but perhaps we could make some sort of guideline about >> not duplicating formats on extra large docs. Is the case with root-docs >> (and/or kdelibs-apidocs) that we have docs in text + html + tex + pdf >> + your_format_here? > > The problem is that, at least for root-doc (not sure about > kdelibs-apidocs), it's all html. > > Please note that I'm not saying "don't package documentation that's > ridiculously large", but rather, "don't package automatically generated > documentation that's ridiculously large". > Is it generated by doxygen? In that case, doxy files usually have options to disable building certain portions of the documentation. For example, when building a library package, we don't want the full source documentation. We only want the documentation of the API the library is exposing. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Alpha Can Still Ship on Time IF these bugs get attention TODAY
On Thu, Aug 05, 2010 at 02:55:05PM -0400, David Malcolm wrote: > workflow, or merely an RFE I need to file against Bodhi? The RFE is already there: https://fedorahosted.org/bodhi/ticket/343 Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root-doc subpackage slightly obese
On Thu, 2010-08-05 at 15:19 -0400, Orcan Ogetbil wrote: > On Thu, Aug 5, 2010 at 3:11 PM, Jonathan Dieter wrote: > > Please note that I'm not saying "don't package documentation that's > > ridiculously large", but rather, "don't package automatically generated > > documentation that's ridiculously large". > > > > Is it generated by doxygen? In that case, doxy files usually have > options to disable building certain portions of the documentation. > > For example, when building a library package, we don't want the full > source documentation. We only want the documentation of the API the > library is exposing. I don't know if root-doc or kdelibs-apidocs are generated using doxygen. If so, this sounds like it may be an easy fix. Jonathan signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-Config-Model
perl-Config-Model has broken dependencies in the F-14 tree: On x86_64: perl-Config-Model-1.205-2.fc14.noarch requires perl(YAML::Any) >= 0:0.303 On i386: perl-Config-Model-1.205-2.fc14.noarch requires perl(YAML::Any) >= 0:0.303 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Data-Alias
perl-Data-Alias has broken dependencies in the F-14 tree: On x86_64: perl-Data-Alias-1.07-6.fc13.x86_64 requires perl(:MODULE_COMPAT_5.10.1) On i386: perl-Data-Alias-1.07-6.fc13.i686 requires perl(:MODULE_COMPAT_5.10.1) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the F-14 tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires perl(:MODULE_COMPAT_5.10.1) On i386: perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires perl(:MODULE_COMPAT_5.10.1) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Call for testers - f14 critpath update: mdadm
I've submitted an updated f14 mdadm package (3.1.3-0.git20100804.2).
This update should fix a race condition in the handling of the mdadm
device map file. This file is responsible for mdadm knowing what
devices it has already seen during incremental assembly so that as new
devices show up, they can be added to the already created arrays. There
was a race condition in the locking around that file, which was fixed
with a patch I wrote. That patch didn't deal properly with dangling
lock files and so mdadm could hang if there was a stale lock file.
Upstream modified my patch to fix operation in the face of a stale lock
file (you can still generate a stale lock file, but now we deal with it
gracefully). I would very much like for this update to make it into f14
before we cut a release candidate, but since it's a critpath package,
that means it needs lots of positive karma and some QE love (I've
disabled karma automatism on the update, but I still need the karma to
push the update from testing to stable).
In particular, any testing that stresses simultaneous incremental
assembly is appreciated. For my own purposes, I created a series of
loopback devices, made a raid1 array on every pair of devices (I had 6
arrays total), then I would stop all arrays and run this command on the
command line:
for dev in loop{0..11}; do (mdadm -I /dev/$dev &); done
and check for proper assembly of all arrays. This could also be
beneficial with random killing of mdadm instances immediately after
putting them all in the background (at least some will be waiting on the
lock of the device map file, and they would be easy targets to kill I
would think...I'll leave that exercise up to the tester) followed by
rerunning the killed mdadm instances and making sure they recover from
the stale lock file and being killed mid operation OK.
In addition, it needs to be tested in a dracut environment just to make
sure that the initramfs generation hasn't been negatively impacted by
the update.
Obviously, the normal "it worked with my raid arrays" testing is also
much appreciated, but the above targeted testing is what's needed to
verify specifically the changes between the existing f14 build and the
current f14 build.
Any help getting this tested would be much appreciated.
The bodhi ticket:
https://admin.fedoraproject.org/updates/mdadm-3.1.3-0.git20100804.2.fc14
And if you feel like testing it on earlier releases, the other bodhi
tickets:
https://admin.fedoraproject.org/updates/mdadm-3.1.3-0.git20100804.2.fc13
https://admin.fedoraproject.org/updates/mdadm-3.1.3-0.git20100804.2.fc12
Since the package has yet to hit the updates-testing repo, the package
link in the bodhi ticket will allow you to directly download the packages.
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
F-14 Branched report: 20100805 changes
Compose started at Thu Aug 5 17:15:21 UTC 2010 Broken deps for x86_64 -- CGAL-3.6.1-1.fc14.i686 requires libboost_thread-mt.so.1.41.0 CGAL-3.6.1-1.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_system-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_program_options-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_serialization-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_regex-mt.so.1.41.0()(64bit) LuxRender-0.6.1-3.fc14.x86_64 requires libboost_iostreams-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_system-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_program_options-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_iostreams-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_serialization-mt.so.1.41.0()(64bit) LuxRender-core-0.6.1-3.fc14.x86_64 requires libboost_regex-mt.so.1.41.0()(64bit) Mayavi-3.3.0-1.fc13.x86_64 requires python(abi) = 0:2.6 Mayavi-3.3.0-1.fc13.x86_64 requires libpython2.6.so.1.0()(64bit) PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit) PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit) QuantLib-test-1.0.1-3.fc14.x86_64 requires libboost_unit_test_framework.so.1.41.0()(64bit) 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2 1:anjuta-2.30.0.0-2.fc14.i686 requires libdevhelp-1.so.1 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libdevhelp-1.so.1()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 avogadro-1.0.1-2.fc14.x86_64 requires libboost_python-mt.so.1.41.0()(64bit) avogadro-libs-1.0.1-2.fc14.i686 requires libboost_python-mt.so.1.41.0 avogadro-libs-1.0.1-2.fc14.x86_64 requires libboost_python-mt.so.1.41.0()(64bit) bastet-0.43-7.fc13.x86_64 requires libboost_program_options.so.1.41.0()(64bit) cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10 cairo-java-1.0.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) cyphesis-0.5.21-2.fc13.x86_64 requires libpython2.6.so.1.0()(64bit) easystroke-0.5.3-1.fc14.x86_64 requires libboost_serialization-mt.so.1.41.0()(64bit) ekg2-python-0.2-0.12.rc1.fc14.x86_64 requires libpython2.6.so.1.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-sharp-0.21.1-7.fc14.x86_64 requires libecal-1.2.so.7()(64bit) fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10 fmt-ptrn-java-1.3.20-5.fc13.x86_64 requires libgcj.so.10()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) fuse-encfs-1.5-12.fc14.i686 requires libboost_filesystem-mt.so.1.41.0 fuse-encfs-1.5-12.fc14.i686 requires libboost_serialization-mt.so.1.41.0 fuse-encfs-1.5-12.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) fuse-encfs-1.5-12.fc14.x86_64 requires libboost_serialization-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_system-mt.so.1.41.0()(64bit) fusecompress-2.6-6.20100223git754bc0de.fc14.x86_64 requires libboost_program_options-mt.so.1.41.0()(64bit) fusecompress-2.6-6.
Re: rawhide report: 20100805 changes
On Thu, Aug 05, 2010 at 06:21:00PM +0100, Richard W.M. Jones wrote: > On Thu, Aug 05, 2010 at 10:46:08AM +, Rawhide Report wrote: > > 1:libguestfs-1.5.2-4.fc14.i686 requires /lib/libxtables.so.4 > > 1:libguestfs-1.5.2-4.fc14.x86_64 requires /lib64/libxtables.so.4 > > Unfortunately qemu isn't installable at the moment so I can't rebuild > this. The error is: > > DEBUG util.py:255: Error: Package: > 2:qemu-system-x86-0.13.0-0.2.20100727gitb81fe95.fc14.x86_64 (build) > DEBUG util.py:255: Requires: /usr/share/gpxe/e1000-0x100e.rom That's due to the new gpxe I built this morning changing the name of that ROM file. jforbes says he'll get to it over the next few days. However, the f14 build shouldn't have even hit updates-testing yet, much less into the alpha compose. There is no bodhi update with it yet exactly because of this... -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Integrity protection of fetches
On Thu, Aug 05, 2010 at 01:11:24PM -0600, Kevin Fenzi wrote: > On Wed, 04 Aug 2010 22:03:14 +0200 > Till Maas wrote: > > The attack is quite trivial: > > 1) clone the git pkg Fedora repos > > 2) commit some nasty change > > 3) publish the repo on some server > > 4) if the victim wants to fetch from the Fedora pkg repo, use the MITM > > attack to make him fetch from the server set up in step 3. Steps 1-3 > > can obviously be done on-demand. > > > > If this is e.g. done on a conference / FUDCon / Fedora Action Day, the > > attack can easily targeted to make the change in step 2 be expected to > > be fast forward. E.g. if packages simply need to be bumped for a > > rebuild, a upload of a bad tarball and modification of the sources > > file might be unnoticed. > > Just to clarify, as this is a long thread: > > This only works if people are using git:// urls, not the default for > fedora ssh: ones, right? (provided you have connected before to > pkgs.fedoraproject.org and have the known_hosts entry?) Yes ssh is secure if used properly. To get the proper known_hosts entry, one has to download https://admin.fedoraproject.org/ssh_known_hosts btw. Regards Till pgpTOv2d3CtC1.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Alpha Can Still Ship on Time IF these bugs get attention TODAY
David Malcolm said the following on 08/05/2010 11:55 AM Pacific Time: > On Thu, 2010-08-05 at 11:46 -0700, John Poelstra wrote: >> Tom "spot" Callaway said the following on 08/05/2010 10:08 AM Pacific Time: >>> On 08/05/2010 12:59 PM, John Poelstra wrote: 597858 [NEW - high - dwa...@redhat.com - --- -] "SELinux is preventing firefox from making its memory writable and executable." crashes rawhide firefox start >>> >>> The update to fix this one out is here: >>> >>> https://admin.fedoraproject.org/updates/selinux-policy-3.8.8-10.fc14 >>> >>> ~spot >> >> That's excellent information to put in the bug. > > Bodhi does this automatically if you add the bug number to the update > when you create it [1]; not sure if it does it when adding a bug to an > already-created update. The biggest time consumer for me (and several people behind the scenes) this release (actually it probably happens every release, but I haven't taken this active a role before) has been pinging bugs where there is not enough information tell what is going on. There has to be a better way. If each person took a minute or two to add a comment of "what the next step is" or what they are waiting for, we'd have a much clearer picture of where the release stands. The alternatives are to do nothing and miss our dates or spam the list and ping bugs until we get to the finish line. Flags, better tooling, or more blocker meetings aren't the solution--people communicating proactively is. Are there any other things I can do to help make this go more smoothly? Are there any other people willing to formally step up and help me do this? John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root-doc subpackage slightly obese
On Thu, Aug 05, 2010 at 03:19:46PM -0400, Orcan Ogetbil wrote: > On Thu, Aug 5, 2010 at 3:11 PM, Jonathan Dieter wrote: > > On Thu, 2010-08-05 at 14:24 -0400, Toshio Kuratomi wrote: > >> I don't think we could just say don't package documentation that's > >> ridiculously large but perhaps we could make some sort of guideline about > >> not duplicating formats on extra large docs. Is the case with root-docs > >> (and/or kdelibs-apidocs) that we have docs in text + html + tex + pdf > >> + your_format_here? > > > > The problem is that, at least for root-doc (not sure about > > kdelibs-apidocs), it's all html. > > > > Please note that I'm not saying "don't package documentation that's > > ridiculously large", but rather, "don't package automatically generated > > documentation that's ridiculously large". > > > > Is it generated by doxygen? In that case, doxy files usually have > options to disable building certain portions of the documentation. > > For example, when building a library package, we don't want the full > source documentation. We only want the documentation of the API the > library is exposing. > Yaah -- so if it's useful documentation, then I'd be against creating a rule that bans it. The next question would be whether it's useful or not Public vs private certainly sounds like one thing to look at. However, some libraries might want to ship information about their private interfaces for people who want to help hack on the library so it's not a 100% thing that I'd want to enforce with a Guideline Perhaps in these two specific cases it would be best to open bugs for the maintainers to look at whether some of the documentation in here isn't considered useful and could be left out. -Toshio pgpvCWxQkXeIr.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: haldaemon seems dead...
Hi, > I've installed F13 on my home box, updated and then moved it to > > rawhide. Everything seems more or less happy now, but it looks like > > haldaemon is dead. I can't burn to DVD, USB pens won't mount, the > > printer is unrecognised and the SCSI scanner has gone. All worked fine > > under F13. > > None of this uses HAL... > k3b is moaning that haldaemon is dead and so can't work. If it's not hal, any ideas what it is? Wonder if dbus is being silly... TTFN Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: [Bug 194531] db2bak is too noisy
https://bugzilla.redhat.com/show_bug.cgi?id=194531 https://bugzilla.redhat.com/attachment.cgi?id=436980&action=diff https://bugzilla.redhat.com/attachment.cgi?id=436980&action=edit Description: Added -v option to db2bak and bak2db and moved the Backing up/ Restoring logs to the verbose mode output. To implement the backend verbose mode, log level SLAPI_LOG_BACKLDBM has been introduced. Usage: db2bak [archivedir] [-v] Usage: bak2db archivedir [-n backendname] [-v] Files: ldap/admin/src/scripts/template-bak2db.in ldap/admin/src/scripts/template-db2bak.in ldap/include/ldaplog.h ldap/servers/slapd/back-ldbm/archive.c ldap/servers/slapd/back-ldbm/dblayer.c ldap/servers/slapd/log.c ldap/servers/slapd/main.c ldap/servers/slapd/slapi-plugin.h Thanks, --noriko smime.p7s Description: S/MIME Cryptographic Signature -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Integrity protection of fetches
On Thu, 5 Aug 2010, Till Maas wrote: > On Thu, Aug 05, 2010 at 01:11:24PM -0600, Kevin Fenzi wrote: > > On Wed, 04 Aug 2010 22:03:14 +0200 > > Till Maas wrote: > > > > The attack is quite trivial: > > > 1) clone the git pkg Fedora repos > > > 2) commit some nasty change > > > 3) publish the repo on some server > > > 4) if the victim wants to fetch from the Fedora pkg repo, use the MITM > > > attack to make him fetch from the server set up in step 3. Steps 1-3 > > > can obviously be done on-demand. > > > > > > If this is e.g. done on a conference / FUDCon / Fedora Action Day, the > > > attack can easily targeted to make the change in step 2 be expected to > > > be fast forward. E.g. if packages simply need to be bumped for a > > > rebuild, a upload of a bad tarball and modification of the sources > > > file might be unnoticed. > > > > Just to clarify, as this is a long thread: > > > > This only works if people are using git:// urls, not the default for > > fedora ssh: ones, right? (provided you have connected before to > > pkgs.fedoraproject.org and have the known_hosts entry?) > > Yes ssh is secure if used properly. To get the proper known_hosts entry, > one has to download https://admin.fedoraproject.org/ssh_known_hosts btw. > We also use SSHFP records for those of you that want to enable VerifyHostKeyDNS yes in their ~/.ssh/config files. Not all of our hosts have it but many of our 'user' based external hosts do (pkgs, fedorapeople, fedorahosted, etc) -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: haldaemon seems dead...
Paul Johnson wrote: >> I've installed F13 on my home box, updated and then moved it to >> > rawhide. Everything seems more or less happy now, but it looks like >> > haldaemon is dead. I can't burn to DVD, USB pens won't mount, the >> > printer is unrecognised and the SCSI scanner has gone. All worked fine >> > under F13. >> >> None of this uses HAL... >> > > k3b is moaning that haldaemon is dead and so can't work. If it's not hal, > any ideas what it is? Wonder if dbus is being silly... rpm -q k3b kdelibs kdebase-runtime hal-storage-addon ? -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
dbus not responding to a large number of things
Hi, It looks like dbus is failing to respond on my box correctly. For example, if I try to run system-config-services as a normal user, I get the following [p...@pb3 ~]$ system-config-services ** (system-config-services:11277): WARNING **: AT-SPI: Accessibility bus not found - Using session bus. (system-config-services:11277): Bonobo-WARNING **: Bonobo must be initialized before use Traceback (most recent call last): File "/usr/bin/system-config-services", line 1040, in GUI(use_dbus=use_dbus).run() File "/usr/bin/system-config-services", line 957, in __init__ bus = slip.dbus.SystemBus() File "", line 2, in SystemBus File "/usr/lib/python2.7/site-packages/dbus/_dbus.py", line 202, in __new__ private=private) File "/usr/lib/python2.7/site-packages/dbus/_dbus.py", line 108, in __new__ bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop) File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 125, in __new__ bus = cls._new_for_bus(address_or_type, mainloop=mainloop) dbus.exceptions.DBusException: org.freedesktop.DBus.Error.FileNotFound: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory This dbus exception is showing up in a large number of places (including when I attempt to mount a CD or USB pen or use the scanner). I thought it was haldaemon being silly to start with, but I'm seeing the exception a lot. Using dbus-1.3.2-0.1.885483.fc15.i686 Any help or advice appreciated. TTFN Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: haldaemon seems dead...
Hi, > k3b is > moaning that haldaemon is dead and so can't work. If it's not hal, > > any > ideas what it is? Wonder if dbus is being silly... > > rpm -q k3b kdelibs > [p...@pb3 ~]$ rpm -q k3b kdelibs k3b-2.0.0-2.fc14.i686 kdelibs-4.4.95-1.fc14.i686 > kdebase-runtime hal-storage-addon > kdebase-runtime doesn't exist. I've done a clean reinstall of it, but I suspect dbus is more the problem than anything... TTFN Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20100805 changes
On Thu, Aug 05, 2010 at 03:14:05PM -0500, Matt Domsch wrote: > On Thu, Aug 05, 2010 at 06:21:00PM +0100, Richard W.M. Jones wrote: > > On Thu, Aug 05, 2010 at 10:46:08AM +, Rawhide Report wrote: > > > 1:libguestfs-1.5.2-4.fc14.i686 requires /lib/libxtables.so.4 > > > 1:libguestfs-1.5.2-4.fc14.x86_64 requires /lib64/libxtables.so.4 > > > > Unfortunately qemu isn't installable at the moment so I can't rebuild > > this. The error is: > > > > DEBUG util.py:255: Error: Package: > > 2:qemu-system-x86-0.13.0-0.2.20100727gitb81fe95.fc14.x86_64 (build) > > DEBUG util.py:255: Requires: /usr/share/gpxe/e1000-0x100e.rom > > That's due to the new gpxe I built this morning changing the name of > that ROM file. jforbes says he'll get to it over the next few days. > However, the f14 build shouldn't have even hit updates-testing yet, > much less into the alpha compose. There is no bodhi update with it > yet exactly because of this... I'm rebuilding libguestfs.f14. However I think the original message refers to Rawhide (ie. F15), despite having ..fc14.. in the package name. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 branching and dist-git roll out
On Thu, Jul 29, 2010 at 11:25:42AM -0700, Jesse Keating wrote: > fedpkg push (this step could be skipped with "fedpkg commit -p") Is there any essential difference between 'fedpkg push' and plain 'git push'? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 branching and dist-git roll out
> "RWMJ" == Richard W M Jones writes: RWMJ> Is there any essential difference between 'fedpkg push' and plain RWMJ> 'git push'? def push(self): """Push changes to the main repository""" cmd = ['git', 'push'] _run_command(cmd) return So looks like no. - J< -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: EsounD (was: Re: [ACTION REQUIRED] orphaned packages in F-14)
Michael Schwendt wrote: > Does anybody think the same about EsounD? > We still include it in Fedora. We still build lots of audio packages > for it. But is it still being used by anyone? PulseAudio emulates the ESounD protocol and for some legacy applications (not even all proprietary), it's the best or even the only way to get them to talk to PulseAudio. We also don't ship the esd daemon itself, only the libraries and protocol emulation in PulseAudio. That's quite different from the situation with NAS, where the only implementation is NAS itself, which is incompatible with PulseAudio and which is supported by few applications. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
Petr Pisar wrote: > PulseAudio is interresting project, but it's absolutely unusable on old > slow hardware. Last time I checked it out on Pentium TSC (no MMX) > running at 200 MHz, Fedora doesn't support that hardware anymore (the minimum is i686 = Pentium Pro). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: feature freeze?
Peter Czanik wrote: > While I guess, it's too late now to make a switch now, here is some good > news: > http://bazsi.blogs.balabit.com/2010/07/syslog-ng-contributions- redefined.html > Dual licensing will be gone with the upcoming syslog-ng v3.2. Nothing has really changed for practical purposes. There's still a non-Free "Premium Edition" with added features and a crippleware "Open Source Edition". The only thing which has changed is the way the non-Free features are delivered (as plugins instead of relicensing the whole thing). This doesn't resolve the complaint that upstream will be unwilling to add features which are specific to the non-Free edition. Crippleware "OSE"s suck. Fedora should not encourage this practice. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root-doc subpackage slightly obese
Toshio Kuratomi wrote: > I don't think we could just say don't package documentation that's > ridiculously large but perhaps we could make some sort of guideline about > not duplicating formats on extra large docs. Is the case with root-docs > (and/or kdelibs-apidocs) that we have docs in text + html + tex + pdf > + your_format_here? kdelibs-apidocs is only in one format (HTML). However, we may want to add a second format (QCH, which is basically an archive of HTML files) soon because that way we could get Qt Assistant, and with minimal code changes also KDevelop, to display that documentation. (It would be a separate subpackage.) Though shipping only the QCH might also be worth considering. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Alpha Can Still Ship on Time IF these bugs get attention TODAY
Tom "spot" Callaway wrote: > On 08/05/2010 12:59 PM, John Poelstra wrote: >> 597858 [NEW - high - dwa...@redhat.com - --- -] "SELinux is preventing >> firefox from making its memory writable and executable." crashes rawhide >> firefox start > > The update to fix this one out is here: > > https://admin.fedoraproject.org/updates/selinux-policy-3.8.8-10.fc14 As much as I dislike SELinux (and would thus generally tend towards lax SELinux policies), allowing a browser (!!!) to bypass memory protection strikes me as an awfully bad idea. Those JavaScript JITs are a really bad security risk. :-( Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dist-git tag question
On 04.08.2010 07:05, Peter Hutterer wrote:
>
> I don't think git hashes are an equivalent to the nvr tags though. I may
> have multiple commits for each nvr, a tag that explicitly specifies which
> version ended up as an rpm in koji would be quite helpful. I have troubles
> remembering hashes long-term, nvr is marginally easier. it also simplifies
> things like "git diff foo-1.2-1..foo-1.2-2" or the automation of that
> process.
>
> Cheers,
>Peter
I had similar problems identifying the correct git hash for my secondary arch rebuilds and
complained about in in my blog on http://karstenhopp.livejournal.com/.
The attached patch adds a --commitinfo parameter to koji's buildinfo and
latest-pkg commands.
P.e. koji buildinfo --commitinfo hwdata-0.227-1.fc14 returns
git://pkgs.fedoraproject.org/hwdata?#21d5786ad6701422e71b3952ea3c8103c5ee72e2
The patch is for koji-1.4.0-2.fc13.noarch, but should be easy to adapt to latest
Karsten
--- /usr/bin/koji 2010-07-09 04:04:26.0 +0200
+++ /home/devel/karsten/tmp/koji2010-08-06 01:51:44.0 +0200
@@ -2058,6 +2058,7 @@
parser.add_option("--all", action="store_true", help=_("List all of the
latest packages for this tag"))
parser.add_option("--quiet", action="store_true", help=_("Do not print the
header information"), default=options.quiet)
parser.add_option("--paths", action="store_true", help=_("Show the file
paths"))
+parser.add_option("--commitinfo", action="store_true", help=_("Show git
commit information used for this build"))
parser.add_option("--type", help=_("Show builds of the given type only.
Currently supported types: maven"))
(options, args) = parser.parse_args(args)
if len(args) == 0:
@@ -2105,6 +2106,12 @@
for x in data:
x['path'] = pathinfo.build(x)
fmt = "%(path)-40s %(tag_name)-20s %(owner_name)s"
+if options.commitinfo:
+for x in data:
+x['request'] =
session.getTaskInfo(session.getBuild(x['build_id'])['task_id'],
request=True)['request'][0]
+fmt = "%(request)-80s"
+options.quiet = True
+# label = koji.taskLabel(self.info)
else:
if options.type == 'maven':
fmt = "%(nvr)-40s %(tag_name)-20s %(maven_group_id)-20s
%(maven_artifact_id)-20s %(owner_name)s"
@@ -2680,6 +2687,7 @@
usage += _("\n(Specify the --help global option for a list of other help
options)")
parser = OptionParser(usage=usage)
parser.add_option("--changelog", action="store_true", help=_("Show the
changelog for the build"))
+parser.add_option("--commitinfo", action="store_true", help=_("Show commit
information used to build this package n-v-r"))
(options, args) = parser.parse_args(args)
if len(args) < 1:
parser.error(_("Please specify a build"))
@@ -2692,26 +2700,29 @@
if info is None:
print "No such build: %s\n" % build
continue
-taglist = []
-for tag in session.listTags(build):
-taglist.append(tag['name'])
-if info['epoch'] is None:
-info['epoch'] = ""
+if options.commitinfo:
+print "%s" % session.getTaskInfo(info['task_id'],
request=True)['request'][0]
else:
-info['epoch'] = str(info['epoch']) + ":"
-info['name'] = info['package_name']
-info['arch'] = 'src'
-info['state'] = koji.BUILD_STATES[info['state']]
-rpms = session.listRPMs(buildID=info['id'])
-print "BUILD: %(name)s-%(version)s-%(release)s [%(id)d]" % info
-print "State: %(state)s" % info
-print "Built by: %(owner_name)s" % info
-print "Task: %(task_id)s" % info
-print "Finished: %s" % koji.formatTimeLong(info['completion_time'])
-print "Tags: %s" % ' '.join(taglist)
-print "RPMs:"
-for rpm in rpms:
-print os.path.join(koji.pathinfo.build(info),
koji.pathinfo.rpm(rpm))
+taglist = []
+for tag in session.listTags(build):
+taglist.append(tag['name'])
+if info['epoch'] is None:
+info['epoch'] = ""
+else:
+info['epoch'] = str(info['epoch']) + ":"
+info['name'] = info['package_name']
+info['arch'] = 'src'
+info['state'] = koji.BUILD_STATES[info['state']]
+rpms = session.listRPMs(buildID=info['id'])
+print "BUILD: %(name)s-%(version)s-%(release)s [%(id)d]" % info
+print "State: %(state)s" % info
+print "Built by: %(owner_name)s" % info
+print "Task: %(task_id)s" % info
+print "Finished: %s" % koji.formatTimeLong(info['completion_time'])
+print "Tags: %s" % ' '.join(taglist)
+print "RPMs:"
+for rpm in rpms:
+print os
Re: haldaemon seems dead...
Paul Johnson wrote: > Hi, > >> k3b is >> moaning that haldaemon is dead and so can't work. If it's not hal, >> > any >> ideas what it is? Wonder if dbus is being silly... >> >> rpm -q k3b kdelibs >> > > [p...@pb3 ~]$ rpm -q k3b kdelibs > k3b-2.0.0-2.fc14.i686 > kdelibs-4.4.95-1.fc14.i686 > > >> kdebase-runtime hal-storage-addon >> > > kdebase-runtime doesn't exist. I've done a clean reinstall of it, but I > suspect dbus is more the problem than anything... k3b is supposed to have a dependency on kdebase-runtime, and some of the hal-related functionality it requires are lacking without it and hal-storage-addon -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] orphaned packages in F-14
On Thu, 2010-08-05 at 10:46 +, Petr Pisar wrote: > PulseAudio is interresting project, but it's absolutely unusable on old > slow hardware. Last time I checked it out on Pentium TSC (no MMX) > running at 200 MHz, it consumed 20 % of CPU just in idle mode. While > `playing', it congested CPU, printed some warnings about stream buffer > overflow and terminated gracefully complaining about no CPU cycles. NAS > or Esound work on the machine fluently. PA uses a more correct but more CPU-intensive resampling method than ALSA by default. On very slow systems it's a good idea to edit /etc/pulse/daemon.conf and change the 'resample-method' parameter. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Alpha Can Still Ship on Time IF these bugs get attention TODAY
On Thu, 2010-08-05 at 13:39 -0700, John Poelstra wrote: > David Malcolm said the following on 08/05/2010 11:55 AM Pacific Time: > > On Thu, 2010-08-05 at 11:46 -0700, John Poelstra wrote: > >> Tom "spot" Callaway said the following on 08/05/2010 10:08 AM Pacific Time: > >>> On 08/05/2010 12:59 PM, John Poelstra wrote: > 597858 [NEW - high - dwa...@redhat.com - --- -] "SELinux is preventing > firefox from making its memory writable and executable." crashes rawhide > firefox start > >>> > >>> The update to fix this one out is here: > >>> > >>> https://admin.fedoraproject.org/updates/selinux-policy-3.8.8-10.fc14 > >>> > >>> ~spot > >> > >> That's excellent information to put in the bug. > > > > Bodhi does this automatically if you add the bug number to the update > > when you create it [1]; not sure if it does it when adding a bug to an > > already-created update. > > The biggest time consumer for me (and several people behind the scenes) > this release (actually it probably happens every release, but I haven't > taken this active a role before) has been pinging bugs where there is > not enough information tell what is going on. > > There has to be a better way. > > If each person took a minute or two to add a comment of "what the next > step is" or what they are waiting for, we'd have a much clearer picture > of where the release stands. > > The alternatives are to do nothing and miss our dates or spam the list > and ping bugs until we get to the finish line. Flags, better tooling, > or more blocker meetings aren't the solution--people communicating > proactively is. > > Are there any other things I can do to help make this go more smoothly? > > Are there any other people willing to formally step up and help me do this? Well, I can give you a tip - always check Bodhi and Koji for updates to the package you're currently looking at the bug report for, it saves a lot of time. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 Alpha Can Still Ship on Time IF these bugs get attention TODAY
On Thu, 2010-08-05 at 14:55 -0400, David Malcolm wrote: > On Thu, 2010-08-05 at 11:46 -0700, John Poelstra wrote: > > Tom "spot" Callaway said the following on 08/05/2010 10:08 AM Pacific Time: > > > On 08/05/2010 12:59 PM, John Poelstra wrote: > > >> 597858 [NEW - high - dwa...@redhat.com - --- -] "SELinux is preventing > > >> firefox from making its memory writable and executable." crashes rawhide > > >> firefox start > > > > > > The update to fix this one out is here: > > > > > > https://admin.fedoraproject.org/updates/selinux-policy-3.8.8-10.fc14 > > > > > > ~spot > > > > That's excellent information to put in the bug. > > Bodhi does this automatically if you add the bug number to the update > when you create it [1]; not sure if it does it when adding a bug to an > already-created update. > > In my mind, bodhi ought to moved NEW and ASSIGNED bugs to MODIFIED when > an update is created that references them, to signify that a build is > available for testing, but is not yet known to fix the bug. However it > doesn't seem to do this. Is this a policy decision in Fedora's bug > workflow, or merely an RFE I need to file against Bodhi? IIRC, it sets ON_QA when the update is *pushed* to -testing - not when it's *submitted*. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: root-doc subpackage slightly obese
On Fri, Aug 06, 2010 at 01:45:08AM +0200, Kevin Kofler wrote: > Toshio Kuratomi wrote: > > I don't think we could just say don't package documentation that's > > ridiculously large but perhaps we could make some sort of guideline about > > not duplicating formats on extra large docs. Is the case with root-docs > > (and/or kdelibs-apidocs) that we have docs in text + html + tex + pdf > > + your_format_here? > > kdelibs-apidocs is only in one format (HTML). However, we may want to add a > second format (QCH, which is basically an archive of HTML files) soon > because that way we could get Qt Assistant, and with minimal code changes > also KDevelop, to display that documentation. (It would be a separate > subpackage.) Though shipping only the QCH might also be worth considering. > Depending on the technologies and applications involved I could see duplication being okay when one format is meant for people utilizing less /usr/share/doc/foo/* vs running /usr/bin/documentationviewer or /usr/bin/programmer-ide -Toshio pgp2oLKZvitgq.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dbus not responding to a large number of things
On Thu, 2010-08-05 at 22:37 +0100, Paul Johnson wrote: > Hi, > > It looks like dbus is failing to respond on my box correctly. For > example, if I try to run system-config-services as a normal user, I > get the following > > [p...@pb3 ~]$ system-config-services > > ** (system-config-services:11277): WARNING **: AT-SPI: Accessibility > bus not found - Using session bus. > > > (system-config-services:11277): Bonobo-WARNING **: Bonobo must be > initialized before use > Traceback (most recent call last): > File "/usr/bin/system-config-services", line 1040, in > GUI(use_dbus=use_dbus).run() > File "/usr/bin/system-config-services", line 957, in __init__ > bus = slip.dbus.SystemBus() > File "", line 2, in SystemBus > File "/usr/lib/python2.7/site-packages/dbus/_dbus.py", line 202, in > __new__ > private=private) > File "/usr/lib/python2.7/site-packages/dbus/_dbus.py", line 108, in > __new__ > bus = BusConnection.__new__(subclass, bus_type, mainloop=mainloop) > File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 125, in > __new__ > bus = cls._new_for_bus(address_or_type, mainloop=mainloop) > dbus.exceptions.DBusException: > org.freedesktop.DBus.Error.FileNotFound: Failed to connect to > socket /var/run/dbus/system_bus_socket: No such file or directory > > This dbus exception is showing up in a large number of places > (including when I attempt to mount a CD or USB pen or use the > scanner). I thought it was haldaemon being silly to start with, but > I'm seeing the exception a lot. > > Using dbus-1.3.2-0.1.885483.fc15.i686 > > Any help or advice appreciated. Is dbus actually running? ps aux | grep bus Does it work if you boot with upstart? Edit your kernel params and add 'init=/sbin/upstart' What I'm betting is that you got systemd 5-2 on your upgrade, and that version has a known problem whereby systemctl segfaults whenever you try to enable a systemd unit with it. the systemd %post does this to enable dbus. So it failed to enable dbus for systemd, so dbus isn't being started. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Build on dist-git for F-14: FAILED: GenericError: Build already exists
On Thu, Aug 05, 2010 at 08:53:17PM +0200, Michael Schwendt wrote:
> On Fri, 6 Aug 2010 00:17:23 +0530, Siddhesh wrote:
>
> > Hi,
> >
> > I'm trying to build gource for F-14 and I get the following error:
>
> > 2382335 build (dist-f14-updates-candidate,
> > /gource:94e27ff92af9990ba724746702f7e34c50af0ae1): open
> > (x86-10.phx2.fedoraproject.org) -> FAILED: GenericError: Build already
> > exists (id=188463, state=COMPLETE): {'name': 'gource', 'task_id': 2382335,
> > 'pkg_id': 9935, 'epoch': None, 'completion_time': None, 'state': 0,
> > 'version': '0.27', 'owner': 1323, 'release': '1', 'id': 188463}
> > 0 free 0 open 1 done 1 failed
>
> > http://koji.fedoraproject.org/koji/buildinfo?buildID=188463
>
> You don't use %{?dist} in your "Release" value, and the 0.27-1 build
> is already done. There can be only one build with that version-release.
>
Doh! I knew it was something very trivial; thanks for pointing out. I
accidentally removed it while changing release numbers from the
previous beta release.
> > Also, probably an unrelated question, but aren't tags added to the scm
> > anymore with the build? I expected a 0.27 tag to be added to master,
> > but that did not happen.
>
> It's not done yet. Where you want tags, you could use:
>
> git tag $(fedpkg verrel)
> git push --tags
Thanks,
Siddhesh
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The move to git!
Congratulations guys, this is awesome work. I know it has been painful and I have a rough idea about the level of effort involved. Looking over the transition, this is truly solid work, and I am confident it will carry (and exceed) the packager's needs for at least another 13 releases or so... :-) Oh, yeah, and Jesse - thank you, for now people can finally stop mumbling blames my way. ;) Cristian Gafton On Thu, Jul 29, 2010 at 8:55 PM, Jesse Keating wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > This evening we opened up dist-git for business. Dist-git is our git > based replacement for dist-cvs, the source control system we were using > for our package specs, patches, and source files. This has been a long > time coming and a massive effort. I want to take a little time here to > outline what we've done and where we are going. > > First a brief outline of how our CVS system worked. CVS is a daemon of > sorts, and all repos typically live within a single CVSROOT. Within > this CVSROOT we had an 'avail' system to make use of, that we could > populate with data from Fedora Account System and dump into this file. > Avail worked on path names, relative to the CVSROOT. Since we used > directories for each Fedora release as pseudo branches we could set > avail info on each release "branch". CVS also used some filesystem > symlink tricks to create a "common" subdir for every package module, and > this is where we stuffed common scripts and Makefile content. Pretty > clever on one hand, we can make updates to the make system without > touching every single package, but it is pretty hackish and we had > constant issues where somebody would attempt an action using old common > content and stuff would fall over. > > Now we look at git. Git is for the most part a daemonless system. Each > repository is completely stand alone and generally does not require any > other infrastructure to be useful. You can interact with a repository > directly on the filesystem using /usr/bin/git or you can interact with > it through say ssh, again using /usr/bin/git (your local /usr/bin/git > will call a remote /usr/bin/git). Generally there is no running daemon > to connect to and authenticate with. Basic authentication of who can > check out what and commit where with git happens at the filesystem > permissions level. One twist with this is that with git, we wanted to > use real branches within a package repo to reflect the different > Fedora/EPEL releases. In repo branches are not reflected with path > names that we could set filesystem ACLs upon, so this posed a problem > for our conversion. > > Enter gitolite. Gitolite ( http://github.com/sitaramc/gitolite )is an > addon system to git that provides ACL functionality including different > rights for different branches within a given repository, and more! By > using gitolite as a replacement for /usr/bin/git when a user connects to > our git server we can again utilize the information we have within the > Fedora Package Database and properly allow / restrict changes on > specific branches for specific developers. The gitolite upstream ( > Sitaram Chamarty, sita...@atc.tcs.com ) has been fantastically > responsive to our needs, which are admittedly a little unique. We have > a very large set of repositories (over 10.5K) and a largish number of > contributors (1050). The combination of the two leads to a very very > large and complex ACL structure that at first broke the system quite > badly. Upstream was very quick to create a "bigconfig" method of > compiling the ACLs without crashing the box. Our other unique needs > involve having individual accounts for each committer instead of a > shared account with a large list of allowed SSH keys. Add to that some > of our accounts need to be able to ssh shell into the git server for > administrative duties. Throughout our trials and testing with gitolite > every time we've ran into some issue that just didn't fit the mold, > Sitaram has been there with a smile and a fix. At this point our > production server is a whopping one line different from current gitolite > upstream. This is a fantastic win for us, for our sustainability, and > for the next large group that wants to make use of gitolite. > > Once we had a plan for ACLs and for branches, we had to decide if we > were going to replace the Make system and with what. I had never been a > fan of Make, it was entirely too difficult to modify and innovate with. > Since I was the one pushing this transition forward, I decided to write > a new tool in my favorite language, python. The fedpkg tool was born > and took off. fedpkg was born around January 4th, 2010 and has since > grown into 1,523 (via sloccount) lines of code. While far from > complete, it is a great start (if I do say so myself!) at replacing the > make system. Because it is written in python (or maybe just !Make) it > seems to be easier to contribute to, and I've already gotten
Re: haldaemon seems dead...
On Thu 5 August 2010 18:01:58 Rex Dieter wrote: > Paul Johnson wrote: > > Hi, > > > >> k3b is > >> moaning that haldaemon is dead > > and so can't work. If it's not hal, > > >> > any > >> > >> ideas what it is? Wonder > > if dbus is being silly... > > >> rpm -q k3b kdelibs > > > > [p...@pb3 ~]$ > > rpm -q k3b kdelibs > > > k3b-2.0.0-2.fc14.i686 > > kdelibs-4.4.95-1.fc14.i686 > > > >> kdebase-runtime hal-storage-addon > > > > kdebase-runtime doesn't > > exist. I've done a clean reinstall of it, but I > > > suspect dbus is more the > > problem than anything... > > k3b is supposed to have a dependency on > kdebase-runtime, and some of the hal-related functionality it requires are > lacking without it and hal-storage-addon > > -- Rex I have a feeling there was a misunderstanding here... > >> rpm -q k3b kdelibs > > > > [p...@pb3 ~]$ > > rpm -q k3b kdelibs > > > k3b-2.0.0-2.fc14.i686 > > kdelibs-4.4.95-1.fc14.i686 > > > >> kdebase-runtime hal-storage-addon > > > > kdebase-runtime doesn't > > exist. I've done a clean reinstall of it, but I because kdepimlibs broke the quoting... :) That should be rpm -q k3b kdelibs kdebase-runtime hal-storage-addon kdebase-runtime isn't a command. :*) (Rex, you should rebuild the kdeppimlibs snapshot in kde-redhat ;) ) Ryan -- Ryan Rix == http://hackersramblings.wordpress.com | http://rix.si/ == == http://rix.si/page/contact/ if you need a word == signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
