Re: Fedora has become fat!
Hi, Maybe somehow fluid-soundfont-gm or fluid-soundfont-lite-patches is getting dragged in ? Those are quite big. Regards, Hans On 03/22/2010 01:50 AM, Christoph Wickert wrote: Why has Fedora become so fat in the F13 development cycle? * The LXDE Spin has grown from 464 MB to 509 MB [1] without a single change in the Spin. There actually was a change, SLIM was replaced with LXDM, but LXDM is actually smaller because it doesn't require the desktop-brackgrounds package * The Xfce spin has grown from 697 MB to 744 MB [2] without major changes. In fact, we dropped totem and gftp, which is at least 10 MB. Any ideas what made Fedora become so fat or how to further investigate this? Regards, Christoph [1] http://alt.fedoraproject.org/pub/alt/nightly-composes/lxde/logs/SIZEHISTORY-i386 [2] http://alt.fedoraproject.org/pub/alt/nightly-composes/xfce/logs/SIZEHISTORY-i386 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Privoxy have a lot openbugs in F12
Hi all, The privoxy current in F12 is a beta version and had a lot of bugs. See https://bugzilla.redhat.com/buglist.cgi?component=privoxyproduct=Fedora Can anyone tell Karsten to fix those bugs? Regard. Chen Lei-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora has become fat!
Am Montag, den 22.03.2010, 09:43 +0100 schrieb Hans de Goede: Hi, Maybe somehow fluid-soundfont-gm or fluid-soundfont-lite-patches is getting dragged in ? Nope, according to the logs [1+2] they are not in there. Also it's a steady growth instead of some big changes. Regards, Christoph [1] http://alt.fedoraproject.org/pub/alt/nightly-composes/xfce/logs/ [2] http://alt.fedoraproject.org/pub/alt/nightly-composes/lxde/logs/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora has become fat!
On Mon, Mar 22, 2010 at 12:50 AM, Christoph Wickert christoph.wick...@googlemail.com wrote: Why has Fedora become so fat in the F13 development cycle? * The LXDE Spin has grown from 464 MB to 509 MB [1] without a single change in the Spin. There actually was a change, SLIM was replaced with LXDM, but LXDM is actually smaller because it doesn't require the desktop-brackgrounds package * The Xfce spin has grown from 697 MB to 744 MB [2] without major changes. In fact, we dropped totem and gftp, which is at least 10 MB. Any ideas what made Fedora become so fat or how to further investigate this? I've found with Moblin and Sugar that one of the easiest/quickest but probably not the most eloquent way is to do a 'rpm -qa | sort rpm-out' and then using some horrible diff hacking to get a rough idea of what's changed. I know there's been some expansion of dependencies with the addition of gstreamer-plugins-bad-free and it looks like some other deps in some core things have been pulled in as well. I need to sit down in the next week or two and go through the ones I've noted mentally and follow up with bugs but my real life seems to keep getting in the way. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Privoxy have a lot openbugs in F12
Am 22.03.2010 09:45, schrieb Chen Lei: Hi all, The privoxy current in F12 is a beta version and had a lot of bugs. See https://bugzilla.redhat.com/buglist.cgi?component=privoxyproduct=Fedora https://bugzilla.redhat.com/buglist.cgi?component=privoxyproduct=Fedora Can anyone tell Karsten to fix those bugs? Regard. Chen Lei And this Bug too https://bugzilla.redhat.com/show_bug.cgi?id=567063 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Evolution trash folder
On Sun, 2010-03-21 at 20:53 -0500, Mike Chambers wrote: No checkmarks checked or unchecked that I could find. The only other explanation is if I did a clean setup (no backups) and see what that does. I might do that with a clean/new test user and see what happens. Hi, try to run Evolution from console, and see what it says, if anything, in time of deleting the message. One thing I do not understand from your description, when you delete message (press a Del button), the message is marked as deleted and either is removed from the message list or shown there with a strike out font. It should be also visible in the account's Trash folder. Because your Folder-Expunge does correct thing, then the message is marked as deleted. Thus I guess your UI is not showing the right thing, does it do at least one of the above mentioned? Maybe the index for a Trash folder is corrupted for some reason; you can try to stop Evolution and move out your ~/.evolution/mail/imap/account/folders.db file, but as it contains all your account index, then the next start will take some time, till it fills it again. Or you can drop only all Trash related tables from there, but it's not as that easy to do. If something goes wrong, then return the folders.db file back. Hope that helps, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Non-responsive maintainer Karsten Hopp? (was: Re: Privoxy have a lot openbugs in F12)
Hiyas, On Mon, Mar 22, 2010 at 04:45:25PM +0800, Chen Lei wrote: The privoxy current in F12 is a beta version and had a lot of bugs. See https://bugzilla.redhat.com/buglist.cgi?component=privoxyproduct=Fedora Can anyone tell Karsten to fix those bugs? I did not check any further, but did he maybe leave Red Hat? Karsten, do you maybe want someone else to maintainer privoxy for you? Please respond, otherwise I will start the non responsive maintainer procedure as it is outlined here: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers I just looked a little through the bugs and the oldest bug is nearly a year old without any response by Karsten. Also I could close 3 bugs as duplicates and one seems to be fixed upstream. Regards Till pgpLCY6Sj4ZA3.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
2010-03-19 - F-13 Beta Blocker Meeting Recap
Greetings, The second scheduled [1] Fedora 13 Beta blocker bug review [2] was held last Friday. The F13Beta blocker list [3] was reviewed and each bug was evaluated against the beta release criteria [4]. Thanks to all who helped move the meeting along. A meeting recap is attached and available at http://meetbot.fedoraproject.org/fedora-bugzappers/2010-03-19/f13beta-blocker-review.2010-03-19-16.04.html Thanks, James [1] http://poelstra.fedorapeople.org/schedules/f-13/f-13-quality-tasks.html [2] Say this five times fast [2] https://bugzilla.redhat.com/show_bug.cgi?id=F13Beta [3] https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria == #fedora-bugzappers: F13Beta-blocker-review == Meeting started by jlaska at 16:04:44 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-bugzappers/2010-03-19/f13beta-blocker-review.2010-03-19-16.04.log.html . Meeting summary --- * Gathering critmass (jlaska, 16:05:15) * Gathering crit-mass (jlaska, 16:08:35) * https://bugzilla.redhat.com/show_bug.cgi?id=574748 (adamw, 16:18:02) * adding this to F13Beta for discussion whether this bug affects the Alpha (jlaska, 16:18:25) * IDEA: Target bugs can be included in a crit-path package update, but at least one Blocker bug must also be present? (jlaska, 16:21:48) * AGREED: 574748 drops from blocker list, it's not severe enough (adamw, 16:24:05) * https://bugzilla.redhat.com/show_bug.cgi?id=574743 (adamw, 16:24:15) * AGREED: 574743 will be an easy fix. blocker status uncertain but not worth investing time in discussing (adamw, 16:30:14) * https://bugzilla.redhat.com/show_bug.cgi?id=572489 (adamw, 16:30:27) * LINK: http://lists.fedoraproject.org/pipermail/test/2010-March/089140.html (jlaska, 16:32:33) * AGREED: 572489 was agreed not to be a blocker last week but bugzilla was not updated; we will update bugzilla this week (adamw, 16:34:59) * https://bugzilla.redhat.com/show_bug.cgi?id=570302 (adamw, 16:35:04) * AGREED: we do not have enough information to fully evaluate 570302, will ask for further information from hans on the bug (adamw, 16:42:19) * https://bugzilla.redhat.com/show_bug.cgi?id=569377 (adamw, 16:43:24) * AGREED: 569377 is a blocker, clumens to poke pjones about it (adamw, 16:49:44) * ACTION: clumens to poke pjones to take action on 569377 (adamw, 16:49:54) * https://bugzilla.redhat.com/show_bug.cgi?id=539904 (adamw, 16:50:56) * IDEA: non-english languages are not represented in the current installer matrix (both graphical or text-mode) (jlaska, 16:54:00) * AGREED: 539904 is a blocker, a patch is in the bug, clumens is checking it (adamw, 16:55:46) * https://bugzilla.redhat.com/show_bug.cgi?id=505189 (adamw, 16:56:02) * LINK: http://git.fedorahosted.org/git/?p=anaconda.git;a=commit;h=f8c1f662b5195805d5fbde60c6593909cd8f4395 (jlaska, 17:00:17) * AGREED: 505189 is not quite a blocker, but nice to have, and the fix is simple: we will probably take it into beta (adamw, 17:03:27) * https://bugzilla.redhat.com/show_bug.cgi?id=567346 (adamw, 17:04:18) * AGREED: 567346 requires more information; hughsie believed it was fixed in latest gnome-packagekit but adamw is still experiencing. blocker status unclear but leaving on list at least until next week (adamw, 17:22:28) * ACTION: adamw to talk to hughsie about 567346 and try to diagnose (adamw, 17:22:39) * https://bugzilla.redhat.com/show_bug.cgi?id=568106 (adamw, 17:22:47) * ACTION: jlaska will attempt to reproduce 568106 on bare metal (jlaska, 17:30:40) * AGREED: 568106 blocker status uncertain, leaving on the list to discuss again next week after further testing (adamw, 17:32:56) * https://bugzilla.redhat.com/show_bug.cgi?id=533746 (adamw, 17:34:19) * AGREED: 533746 is blocker-y due to the large amount of systems affected, a fix is in progress and linville is hopeful it can land early next week in time for beta rc1 (adamw, 17:46:34) * https://bugzilla.redhat.com/show_bug.cgi?id=566425 (adamw, 17:46:50) * AGREED: 566425 is a blocker, jlaska will co-ordinate with cole to get a fixed package downstream in time for beta rc period (adamw, 17:51:37) * ACTION: jlaska to co-ordinate with crobinson to get a new libvirt package in (adamw, 17:51:56) * https://bugzilla.redhat.com/show_bug.cgi?id=559290 (adamw, 17:52:09) * LINK: http://docs.fedoraproject.org/release-notes/f12/en-US/html/index.html#sect-Release_Notes-Hardware_Requirements (jlaska, 17:56:11) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=499585 (adamw, 17:56:24) * LINK: https://fedoraproject.org/wiki/Documentation_Beats_Hardware_Overview looks like the beat (adamw, 17:59:42) * ACTION: jlaska will update 559290 given that it appears the reporter problem is resolved
Re: Akonadi's unix sockets location
On 03/21/2010 10:44 AM, Jonathan Underwood wrote: On 19 March 2010 23:52, Lennart Poetteringmzerq...@0pointer.de wrote: That is a security hole. Since /tmp knows no further access control an evil user can just create dirs there for each and every single user on the system. Those directories will then be owned by him, and all other users will a) either completely fail to work or b) happily connect to the evil user's services unless the software in question implements two-way credential passing and verification (which I'd bet akonadi doesn't do). So either this is a DoS vulnerability or an even worse security hole. So in short: don't do this. If you safely want to place a socket in /tmp, you need to place it in a random dir, and then symlink (or otherwise refer to it) from $HOME. Or better (as Colin suggested), just use D-Bus to pass around the randomized socket path. (or even better: use the new fd passing in D-Bus so that you don't need to socket path at all) Or even shorter: Unix sucks. At last year's FOSS.in I did a talk about issues like this in Unix and how to work around them in application and how incredibly hard it is to get this right. One of those days I hope to find the time to write a blog story about this. I personally believe introducing a per-user /var/run (maybe as /var/run/users/$USER which is created at login time) is cleanest way to fix all of this. I can't imagine what harm that would cause to default under /tmp? It's a shared namespace. As such it is a major source of vulnerabitilities, especially if the developers didn't have this particular use in mind. To what extent would the security issues associated with files in /tmp be mitigated with a polyinstantiated /tmp directories? Should Fedora move to that as a default? Yes a lot of this would be fixed, but it is very confusing to have different views of /tmp. I have it setup right now and am bit by root having a different view of /tmp then my user account. And I understand the technology. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora has become fat!
On Mon, 22 Mar 2010, Peter Robinson wrote:
On Mon, Mar 22, 2010 at 12:50 AM, Christoph Wickert
christoph.wick...@googlemail.com wrote:
Why has Fedora become so fat in the F13 development cycle?
* The LXDE Spin has grown from 464 MB to 509 MB [1] without a
single change in the Spin. There actually was a change, SLIM was
replaced with LXDM, but LXDM is actually smaller because it
doesn't require the desktop-brackgrounds package
* The Xfce spin has grown from 697 MB to 744 MB [2] without major
changes. In fact, we dropped totem and gftp, which is at least
10 MB.
Any ideas what made Fedora become so fat or how to further investigate
this?
I've found with Moblin and Sugar that one of the easiest/quickest but
probably not the most eloquent way is to do a 'rpm -qa | sort
rpm-out' and then using some horrible diff hacking to get a rough idea
of what's changed.
rpm -qa --qf %{name}\n | sort rpm-out
then you can diff the two more easily.
-sv
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora has become fat!
On Sun, Mar 21, 2010 at 7:50 PM, Christoph Wickert christoph.wick...@googlemail.com wrote: Why has Fedora become so fat in the F13 development cycle? * The LXDE Spin has grown from 464 MB to 509 MB [1] without a single change in the Spin. There actually was a change, SLIM was replaced with LXDM, but LXDM is actually smaller because it doesn't require the desktop-brackgrounds package * The Xfce spin has grown from 697 MB to 744 MB [2] without major changes. In fact, we dropped totem and gftp, which is at least 10 MB. Any ideas what made Fedora become so fat or how to further investigate this? Regards, Christoph [1] http://alt.fedoraproject.org/pub/alt/nightly-composes/lxde/logs/SIZEHISTORY-i386 [2] http://alt.fedoraproject.org/pub/alt/nightly-composes/xfce/logs/SIZEHISTORY-i386 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Could it be related to the dracut issue we ran into during the F12 build cycle? -AdamM -- http://maxamillion.googlepages.com - () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora has become fat!
On Mon, Mar 22, 2010 at 1:20 PM, Adam Miller maxamill...@fedoraproject.org wrote: On Sun, Mar 21, 2010 at 7:50 PM, Christoph Wickert christoph.wick...@googlemail.com wrote: Why has Fedora become so fat in the F13 development cycle? * The LXDE Spin has grown from 464 MB to 509 MB [1] without a single change in the Spin. There actually was a change, SLIM was replaced with LXDM, but LXDM is actually smaller because it doesn't require the desktop-brackgrounds package * The Xfce spin has grown from 697 MB to 744 MB [2] without major changes. In fact, we dropped totem and gftp, which is at least 10 MB. Any ideas what made Fedora become so fat or how to further investigate this? Regards, Christoph [1] http://alt.fedoraproject.org/pub/alt/nightly-composes/lxde/logs/SIZEHISTORY-i386 [2] http://alt.fedoraproject.org/pub/alt/nightly-composes/xfce/logs/SIZEHISTORY-i386 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Could it be related to the dracut issue we ran into during the F12 build cycle? Possibly. I'm also seeing packages pull in perl again (need to review and file bugs). anaconda/syslinux is one of the big ones here. It was always an issue but for some reason syslinux use to have the auto deps suppressed which stopped the perl dep. perl pulls in a good 40+ meg for a tiny little script that is used during a small component of the anaconda process that isn't used at all as part of the liveinst (or even a traditional install). See bug 544136 and its dependant bug. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora has become fat!
On Mon, 2010-03-22 at 01:50 +0100, Christoph Wickert wrote: Why has Fedora become so fat in the F13 development cycle? * The LXDE Spin has grown from 464 MB to 509 MB [1] without a single change in the Spin. There actually was a change, SLIM was replaced with LXDM, but LXDM is actually smaller because it doesn't require the desktop-brackgrounds package * The Xfce spin has grown from 697 MB to 744 MB [2] without major changes. In fact, we dropped totem and gftp, which is at least 10 MB. Any ideas what made Fedora become so fat or how to further investigate this? Download the ISOs, boot them in qemu, rpm -qa inside them... Shame that the compose logs only go back to February though. - ajax 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-Catalyst-Model-DBIC-Schema
perl-Catalyst-Model-DBIC-Schema has broken dependencies in the rawhide tree: On x86_64: perl-Catalyst-Model-DBIC-Schema-0.40-1.fc14.noarch requires perl(Catalyst::Model::DBIC::Schema::Types) On i386: perl-Catalyst-Model-DBIC-Schema-0.40-1.fc14.noarch requires perl(Catalyst::Model::DBIC::Schema::Types) 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
rawhide report: 20100322 changes
Compose started at Mon Mar 22 08:15:05 UTC 2010 Broken deps for i386 -- edje-0.9.93.063-1.fc14.i686 requires libembryo-ver-svn-05.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_job.so.0 emotion-0.1.0.042-5.fc12.i686 requires libevas.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_fb.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_x.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_txt.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_job.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_con.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedbus.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libevas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libehal.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_fb.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_x.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_ipc.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedje.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_file.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet_mime.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libedje.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 evolution-couchdb-0.3.2-2.fc13.i686 requires libcouchdb-glib-1.0.so.1 ewl-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet.so.0 ewl-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet_mime.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_evas.so.0 gvfs-afc-1.5.5-1.fc14.i686 requires libimobiledevice.so.0 hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0 inkscape-0.47-6.fc13.i686 requires libMagick++.so.2 inkscape-0.47-6.fc13.i686 requires libMagickCore.so.2 inkscape-view-0.47-6.fc13.i686 requires libMagick++.so.2 inkscape-view-0.47-6.fc13.i686 requires libMagickCore.so.2 libgpod-0.7.91-1.fc14.i686 requires libimobiledevice.so.0 murmur-1.1.8-15.fc12.i686 requires libIce.so.33 murmur-1.1.8-15.fc12.i686 requires libIceUtil.so.33 openvas-libnasl-2.0.2-3.fc13.i686 requires libopenvas.so.2 openvas-libnasl-2.0.2-3.fc13.i686 requires libopenvas_hg.so.2 paperbox-0.4.4-2.fc12.i686 requires libtrackerclient.so.0 perl-Catalyst-Model-DBIC-Schema-0.40-1.fc14.noarch requires perl(Catalyst::Model::DBIC::Schema::Types) php-pecl-imagick-2.2.2-4.fc12.i686 requires libMagickWand.so.2 php-pecl-imagick-2.2.2-4.fc12.i686 requires libMagickCore.so.2 pyclutter-gst-0.9.2-1.fc12.i686 requires libclutter-gst-0.10.so.0 python-gpod-0.7.91-1.fc14.i686 requires
Re: Akonadi's unix sockets location
On Sun, 21.03.10 14:44, Jonathan Underwood (jonathan.underw...@gmail.com) wrote: It's a shared namespace. As such it is a major source of vulnerabitilities, especially if the developers didn't have this particular use in mind. To what extent would the security issues associated with files in /tmp be mitigated with a polyinstantiated /tmp directories? Should Fedora move to that as a default? The major security issues would certainly go away that way, but I don't think that such a behaviourial change would be a good idea. /tmp has always been a shared namespace, and some apps might actually depend on that to exchange files between users. The FHS assumes a single namespace for the entire fs hierarchy and departing from that might create various unexpected problems. Starting from admins who don't expect a weirdness like this, but also applications that break with behaviour like that. To my knowledge the Debian folks experimented with this a couple of years ago, and even wanted to make it the default (but didn't in the end, afaics). Might be interesting to learn about the results of their experimenting. Instead of changing the semantics of /tmp which is already way to established with all its brokeness and weird semantics, I'd rather like to see a new dir added /var/run/users/$USER/ that does not suffer by all the problems and introduces new, clean and well defined semantics. Lennart -- Lennart PoetteringRed Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Live image from filesystem snapshot?
Not sure where to send this request, but since it was inspired by the Fedora has become fat! discussion, this seems like an appropriate place. I have a nicely tweaked installation of the LXDE spin sitting on my hard drive that I would like to snapshot and place on a live USB stick (ideally with persistent overlay). Is there a simple way to do this? I really don't want to have to mess around with revisor and custom kickstart files - been there, done that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Live image from filesystem snapshot?
I think this is a good idea because many of our users don't have access to any repositories I thought about rpmrebuild then creating a repo ... Name : rpmrebuild Description: A tool to build an RPM file from a package that has already been : installed. but that would be a big waste of resources and time ...etc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Catalyst-Model-DBIC-Schema/devel auto.ini, 1.1, 1.2 perl-Catalyst-Model-DBIC-Schema.spec, 1.7, 1.8
Author: cweyl
Update of /cvs/extras/rpms/perl-Catalyst-Model-DBIC-Schema/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv13775
Modified Files:
auto.ini perl-Catalyst-Model-DBIC-Schema.spec
Log Message:
* Mon Mar 22 2010 Chris Weyl cw...@alumni.drew.edu 0.40-2
- manually provide Catalyst::Model::DBIC::Schema::Types... le sigh
Index: auto.ini
===
RCS file: /cvs/extras/rpms/perl-Catalyst-Model-DBIC-Schema/devel/auto.ini,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- auto.ini21 Mar 2010 01:37:01 - 1.1
+++ auto.ini22 Mar 2010 15:31:32 - 1.2
@@ -8,3 +8,6 @@ perl(DBD::SQLite)=0
[add_requires]
perl(Hash::Merge)=0
perl(DBIx::Class::Schema::Loader)=0
+
+[add_provides]
+perl(Catalyst::Model::DBIC::Schema::Types)=0
Index: perl-Catalyst-Model-DBIC-Schema.spec
===
RCS file:
/cvs/extras/rpms/perl-Catalyst-Model-DBIC-Schema/devel/perl-Catalyst-Model-DBIC-Schema.spec,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -p -r1.7 -r1.8
--- perl-Catalyst-Model-DBIC-Schema.spec21 Mar 2010 01:35:39 -
1.7
+++ perl-Catalyst-Model-DBIC-Schema.spec22 Mar 2010 15:31:32 -
1.8
@@ -1,7 +1,7 @@
Name: perl-Catalyst-Model-DBIC-Schema
Summary:DBIx::Class::Schema Model Class
Version:0.40
-Release:1%{?dist}
+Release:2%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/R/RK/RKITOVER/Catalyst-Model-DBIC-Schema-%{version}.tar.gz
@@ -10,6 +10,8 @@ BuildRoot: %{_tmppath}/%{name}-%{ve
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildArch: noarch
+Provides: perl(Catalyst::Model::DBIC::Schema::Types)
+
BuildRequires: /usr/bin/catalyst.pl
BuildRequires: perl(Carp::Clan)
BuildRequires: perl(Catalyst::Runtime) = 5.80005
@@ -80,6 +82,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Mon Mar 22 2010 Chris Weyl cw...@alumni.drew.edu 0.40-2
+- manually provide Catalyst::Model::DBIC::Schema::Types... le sigh
+
* Fri Mar 12 2010 Chris Weyl cw...@alumni.drew.edu 0.40-1
- update by Fedora::App::MaintainerTools 0.006
- PERL_INSTALL_ROOT = DESTDIR
--
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: F13 install timings
On 03/19/2010 03:41 PM, John Reiser wrote: It's an http install to a local server, and there is no access during that stage (after is has all of the repodata files) until it starts fetching package headers. So, it seems like filing a bug is in order. Anaconda or yum? Anaconda, the program that you invoked. If anaconda can pass the blame along to yum, then I'm sure that they will :-) https://bugzilla.redhat.com/show_bug.cgi?id=575878 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora has become fat!
On Mon, Mar 22, 2010 at 7:13 AM, Seth Vidal skvi...@fedoraproject.org wrote:
On Mon, 22 Mar 2010, Peter Robinson wrote:
On Mon, Mar 22, 2010 at 12:50 AM, Christoph Wickert
christoph.wick...@googlemail.com wrote:
Why has Fedora become so fat in the F13 development cycle?
* The LXDE Spin has grown from 464 MB to 509 MB [1] without a
single change in the Spin. There actually was a change, SLIM was
replaced with LXDM, but LXDM is actually smaller because it
doesn't require the desktop-brackgrounds package
* The Xfce spin has grown from 697 MB to 744 MB [2] without major
changes. In fact, we dropped totem and gftp, which is at least
10 MB.
Any ideas what made Fedora become so fat or how to further investigate
this?
I've found with Moblin and Sugar that one of the easiest/quickest but
probably not the most eloquent way is to do a 'rpm -qa | sort
rpm-out' and then using some horrible diff hacking to get a rough idea
of what's changed.
rpm -qa --qf %{name}\n | sort rpm-out
then you can diff the two more easily.
I also like to do a
rpm -qa --qf '%{SIZE} %{NAME}\n | sort -n rpm-size-out
and one could do a
rpm -qa --qf '%{NAME} %{SIZE}\n' | sort rpm-size
and compare per package to see what has grown. Also are there extra
debugging being turned on for the alpha/betas? I know that a long time
ago (back when your pappy and I fought in the great Distro war) we
turned on extra stuff during alpha/betas to help find problems.
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive maintainer Karsten Hopp?
Am 22.03.2010 12:05, schrieb Till Maas: Hiyas, On Mon, Mar 22, 2010 at 04:45:25PM +0800, Chen Lei wrote: The privoxy current in F12 is a beta version and had a lot of bugs. See https://bugzilla.redhat.com/buglist.cgi?component=privoxyproduct=Fedora Can anyone tell Karsten to fix those bugs? I did not check any further, but did he maybe leave Red Hat? Karsten, do you maybe want someone else to maintainer privoxy for you? Please respond, otherwise I will start the non responsive maintainer procedure as it is outlined here: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers I just looked a little through the bugs and the oldest bug is nearly a year old without any response by Karsten. Also I could close 3 bugs as duplicates and one seems to be fixed upstream. Regards Till I'm still here, although quite busy with s390x as a secondary arch. If someone is willing to take over privoxy, I'd be happy to orphan it. Otherwise I'll try to find some time this week to update privoxy to 3.0.16. Karsten -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non-responsive maintainer Karsten Hopp?
On Mon, Mar 22, 2010 at 6:28 PM, Karsten Hopp kars...@redhat.com wrote: Am 22.03.2010 12:05, schrieb Till Maas: Hiyas, On Mon, Mar 22, 2010 at 04:45:25PM +0800, Chen Lei wrote: The privoxy current in F12 is a beta version and had a lot of bugs. See https://bugzilla.redhat.com/buglist.cgi?component=privoxyproduct=Fedora Can anyone tell Karsten to fix those bugs? I did not check any further, but did he maybe leave Red Hat? Karsten, do you maybe want someone else to maintainer privoxy for you? Please respond, otherwise I will start the non responsive maintainer procedure as it is outlined here: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers I just looked a little through the bugs and the oldest bug is nearly a year old without any response by Karsten. Also I could close 3 bugs as duplicates and one seems to be fixed upstream. Regards Till I'm still here, although quite busy with s390x as a secondary arch. If someone is willing to take over privoxy, I'd be happy to orphan it. Otherwise I'll try to find some time this week to update privoxy to 3.0.16. I will help you. -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 Branched report: 20100322 changes
Compose started at Mon Mar 22 09:15:08 UTC 2010 Broken deps for i386 -- hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0 pyclutter-gst-0.9.2-1.fc12.i686 requires libclutter-gst-0.10.so.0 zikula-module-menutree-2.2-1.fc13.noarch requires zikula = 0:1.2 Broken deps for x86_64 -- hornsey-1.5.2-0.1.fc13.x86_64 requires libclutter-gst-0.10.so.0()(64bit) pyclutter-gst-0.9.2-1.fc12.x86_64 requires libclutter-gst-0.10.so.0()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula = 0:1.2 New package cocot COde COnverter on Tty New package desktopcouch A CouchDB instance on every desktop New package fetch-crl Downloads Certificate Revocation Lists New package ibus-skk Japanese SKK input method for ibus New package ibus-table-yinma The phonetic tables for IBus-Table New package perl-CLASS Alias for __PACKAGE__ New package perl-opts Simple command line option parser New package qstardict StarDict clone written using Qt4 New package raw-thumbnailer Nautilus file manager thumbnailer for RAW images New package rawtherapee Raw image processing software New package uperf Network performance tool with modelling and replay support New package xfce4-remmina-plugin Xfce panel plugin for Remmina remote desktop client Updated Packages: FlightGear-Atlas-0.4.0-0.5.cvs20100226.fc13 --- * Thu Mar 11 2010 Fabrice Bellet fabr...@bellet.info 0.4.0-0.5.cvs20100226 - Fix graph axis formatting bug, by avoiding negative values in the format string GraphicsMagick-1.3.12-1.fc13 * Mon Mar 08 2010 Rex Dieter rdie...@fedoraproject.org - 1.3.12-1 - GraphicsMagick-1.3.12 * Tue Feb 23 2010 Rex Dieter rdie...@fedoraproject.org - 1.3.11-1 - GraphicsMagick-1.3.11 PyQt4-4.7-5.fc13 * Sun Mar 14 2010 Kevin Kofler ke...@tigcc.ticalc.org - 4.7-5 - fix implicit linking when checking for QtHelp and QtAssistant - remove Python 3 code from Python 2.6 directory, fixes FTBFS (#564633) * Sat Mar 13 2010 Kevin Kofler ke...@tigcc.ticalc.org - 4.7-4 - BR qt-assistant-adp-devel * Tue Feb 23 2010 Than Ngo t...@redhat.com - 4.7-3 - fix multilib conflict because of timestamp * Sun Feb 14 2010 Rex Dieter rdie...@fedoraproject.org - 4.7-2 - rebuild abrt-1.0.8-3.fc13 - * Sat Mar 13 2010 Jiri Moskovcak jmosk...@redhat.com 1.0.8-3 - fixed kerneloops reporting rhbz#570081 - fixed Source url - fixed debuginfo-install to work on F13 - improved debuginfo-install (vda.li...@googlemail.com) - fix debuginfo-install to work with yum = 3.2.26 (jmosk...@redhat.com) * Wed Mar 03 2010 Denys Vlasenko dvlas...@redhat.com 1.0.8-2 - fix initscript even more (npajk...@redhat.com) - remove -R2 from yum command line aide-0.14-1.fc13 * Tue Mar 16 2010 Steve Grubb sgr...@redhat.com - 0.14-1 - New upstream release final 0.14 anaconda-13.35-1.fc13 - * Mon Mar 15 2010 David Lehman dleh...@redhat.com - 13.35-1 - Fully qualify _ped.IOException. (dlehman) * Mon Mar 15 2010 David Lehman dleh...@redhat.com - 13.34-1 - parted.PartedDisk can throw IOExceptions too (#573539) (hdegoede) - Fix recognition of partitions on mdraid arrays (#569462) (hdegoede) - Use the disk name from kickstart in the shouldClear error message. (clumens) - Fix displaying error messages on cleanup/remove callback problems (#572893). (clumens) - Before running shouldClear, make sure a real disk was specified (#572523). (clumens) - exception.py: switch to tty1 before exit (#569071) (akozumpl) - Preserve encryption setting when re-editing new encrypted LVs. (#568547) (dlehman) - Never pass Not applicable as mountpoint to format constructors. (dlehman) - Fix up device dialogs' handling of preexisting formatting. (dlehman) - Set up devices using their original formats for certain action types. (#565848) (dlehman) - Keep a handle to devices' original format instance. (#565848) (dlehman) - Tell ld.so and friends not to use hardware optimized libs (#572178) (pjones) - By default, libcurl does not appear to follow redirects (#572528). (clumens) - Use '--keyword=P_:1,2' for plural gettext string extraction (#567417). (dcantrell) - fix: do not initialize the install interface whenever is is accessed (#565872) (akozumpl) - Select/Deselect All should only apply to the current tab (#516143, - Don't try to write firewall and auth information twice (#568528). (clumens) * Thu Mar 04 2010 Chris Lumens clum...@redhat.com - 13.33-1 - On live installs, the syslog is /var/log/dmesg. (#568814). (clumens) - Set up udev environment so anaconda's udev rules run in livecd. (#568460) (dlehman) - Ignore probably-spurious disklabels on unpartitionable devices. (#567832) (dlehman) - The
Re: Automatic Provides and Requires for Python modules
In general, +1 to this. On Sun, Mar 21, 2010 at 11:25:18AM +0100, Aurelien Bompard wrote: Hi people, At the top of our Python packaging page (https://fedoraproject.org/wiki/Packaging:Python), there's a note which reads 'In theory /usr/lib/rpm/pythondeps.sh would also automatically generate Provides lines' This is also true for python modules : distutils and setuptools have a way to specify provides and requires, but those are not reflected in the RPM. It means that they must be entered and maintained by hand in the spec file. In my opinion, this is not optimal. The perl modules have an interesting way of reflecting their dependencies in the rpm: they add a dependency on perl(Module::Name). I believe the same system can be applicable to python modules. Currently, there are two main packaging systems in python : distutils and setuptools. Distutils declares the dependencies in an egg-info file, which is RFC-822-formatted. Setuptools turns this file into a PKG-INFO file in a subdirectory, and adds a requires.txt files with additional dependencies, in a different format. Note that in some corner cases, the egg-info might not give you what you need. For instance, if we were to subpackage pkg_resources separately from setuptools we would only have one upstream egg-info that referenced setuptools, nothing referencing pkg_resources. Like I say, these are corner cases, though. The pythondeps.sh script should be able to extract requires from these files. To match the dependencies, pythondeps.sh should create virtual provides like python(ModuleName) = version. In describing this, module name is probably not the best word. ProjectName or EggName might be better. (Because there can multiple modules but they are all described by a single name in the egg-info). Also versions are more problematic than naming's corner cases. * If we backport a bugfix or feature to an old version, the EggInfo may require a newer version than we provide even though it would work fine with our version. * Upstreams frequently put a minimum version in that they have tested with rather than the true minimum version that the package will work with. That means the setup.py file (and thus egginfo) may say it requires SqlAlchemy-0.5.5 but it really works with the SQLAlchemy-0.5.2 that we ship. The good news is : I've written it already ;-) It's based on the pythondeps.sh script from Git master (which changed a little bit due to python3, see bug 532118). Also, the script does not try to be too smart with versionned dependencies, because the format is a little bit different in python and in rpm. For those complicated cases, handwritten requirements can still be added to the spec file. The script only covers the usual cases. For reference, the dependency format in distutils is described here: http://www.python.org/dev/peps/pep-0314/ The dependency format in setuptools is described here: http://peak.telecommunity.com/DevCenter/setuptools#declaring-dependencies Note: PEP about changing the version strings in distutils: http://www.python.org/dev/peps/pep-0386/ It's accepted but not yet implemented. When it is we will have something that we can map upstream versions to our version + release format (although, we'd probably only use the version portion in autodeps). Also PEPs that change the metadata format in distutils: http://www.python.org/dev/peps/pep-0376/ http://www.python.org/dev/peps/pep-0390/ A patch would not make much sense due to the size of the addition, so here's the full script: http://aurelien.bompard.org/projects/divers/pythondeps.sh Some specifics: # Handle alpha and rc releases: the version comparator will be rpm, not # python, so 1.0rc1 1.0. Deal with it by turning 1.0rc1 into 1.0-0.rc1 # (which is the recommended naming scheme anyway) echo $pyver | sed -e 's/\([0-9.]\+\)\([a-z].*\)/\1-0.\2/g' Actually, the naming scheme for Fedora would be: 1.0-0.1.rc1, 1.0-0.2.rc1, etc. If I'm reading the code correctly, these versions just get put in the autodeps, though, so that shouldn't matter. However, what does matter is that this sequence won't be parsed so that the sequence of versions is correct: 0.9 = 0.9 1.0rc1 = 1.0-0.rc1 1.0 = 1.0 1.0post1= 1.0-0.post1 That would order as 0.9, 1.0, 1.0-0.rc1, 1.0-0.post1 You want something more like this: 0.9 = 0.9-1 1.0rc1 = 1.0-0.rc1 1.0 = 1.0-1 1.0post1= 1.0-1.post1 0 and 1 are always added and denote pre release versus post release. The next problem is deciding which version strings you're going to target. Current distutils, setuptools, and the distutils PEP have three different algorithms for comparing versions. You can throw out current distutils because no one use it. Setuptools is something that the python community is trying to get rid of but it's the current de facto standard. It's version algorithm is a huge mess because it makes a lot of guesses about
Re: Fedora has become fat!
Am Montag, den 22.03.2010, 09:13 -0400 schrieb Seth Vidal:
On Mon, 22 Mar 2010, Peter Robinson wrote:
On Mon, Mar 22, 2010 at 12:50 AM, Christoph Wickert wrote
Any ideas what made Fedora become so fat or how to further investigate
this?
I've found with Moblin and Sugar that one of the easiest/quickest but
probably not the most eloquent way is to do a 'rpm -qa | sort
rpm-out' and then using some horrible diff hacking to get a rough idea
of what's changed.
rpm -qa --qf %{name}\n | sort rpm-out
then you can diff the two more easily.
I know how to use rpm, but as long as I don't have all the nightlies
there is not much to compare. All I can compare is the F12 spin with the
latest nightly and this wont tell me much about what happened in the
meantime.
Is there an easy way to get previous versions of a package if I have
full n-v-r, say from koji?
-sv
Regards,
Christoph
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
libgpod rebuilds needed in F-13/devel
Heya, libgpod has been rebuilt with a new libimobiledevice (1.0.0) and all the applications that link against libgpod will need a rebuilt. Rhythmbox is being rebuilt as we speak, I'll let others to their respective owners. Cheers -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora has become fat!
On Mon, 22 Mar 2010, Christoph Wickert wrote:
Am Montag, den 22.03.2010, 09:13 -0400 schrieb Seth Vidal:
On Mon, 22 Mar 2010, Peter Robinson wrote:
On Mon, Mar 22, 2010 at 12:50 AM, Christoph Wickert wrote
Any ideas what made Fedora become so fat or how to further investigate
this?
I've found with Moblin and Sugar that one of the easiest/quickest but
probably not the most eloquent way is to do a 'rpm -qa | sort
rpm-out' and then using some horrible diff hacking to get a rough idea
of what's changed.
rpm -qa --qf %{name}\n | sort rpm-out
then you can diff the two more easily.
I know how to use rpm, but as long as I don't have all the nightlies
there is not much to compare. All I can compare is the F12 spin with the
latest nightly and this wont tell me much about what happened in the
meantime.
Is there an easy way to get previous versions of a package if I have
full n-v-r, say from koji?
You can compare F12's list with the current one.
-Mike
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 2.6.5 and 3.1.2 likely to be released at the end of the week
On Mon, 2010-03-22 at 15:32 -0400, Luke Macken wrote: On Mon, Mar 22, 2010 at 12:44:13AM -0400, Toshio Kuratomi wrote: On Sun, Mar 21, 2010 at 05:22:48PM -0400, David Malcolm wrote: On Wed, 2010-03-17 at 02:51 -0400, Toshio Kuratomi wrote: On Tue, Mar 16, 2010 at 07:45:27PM -0400, David Malcolm wrote: Python 2.6.5 and 3.1.2 are due at the end of this week. I plan to build 2.6.5 and 3.1.2 into Fedora 14 as soon as they're released (though if any other maintainer wants to do this, feel free!) My feeling is that they're too late for F-13 at this point in the schedule [1]. Having said that, if enough people want to test them, I'd be willing to build them, for some definition of enough (the bump from 3.1.1 to 3.1.2 may be safer than that from 2.6.4 to 2.6.5, since the python 3 stack isn't on the critical path [2]) Dave [1] http://fedoraproject.org/wiki/Releases/13/Schedule [2] http://fedoraproject.org/wiki/Critical_Path_Packages I definitely agree with bumping the python3 package. People who want to try out python3 want to be working with the latest at this point and there's nothing critical path to break there. On the fence about bumping the python2.6 package. Upstream released 3.1.2 today; I've built it into Fedora 14: http://koji.fedoraproject.org/koji/buildinfo?buildID=162960 I haven't tested it yet. If it seems to work OK, then shall we build 3.1.2 into Fedora 13? +1 Sounds good to me, +1 I've built python 3.1.2 into Fedora 13 and created this update for it: https://admin.fedoraproject.org/updates/python3-3.1.2-1.fc13 Please test! (and please give positive and negative karma to that update as appropriate) Dave ___ python-devel mailing list python-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Fedora has become fat!
Am Montag, den 22.03.2010, 14:49 -0500 schrieb Mike McGrath:
On Mon, 22 Mar 2010, Christoph Wickert wrote:
Am Montag, den 22.03.2010, 09:13 -0400 schrieb Seth Vidal:
On Mon, 22 Mar 2010, Peter Robinson wrote:
On Mon, Mar 22, 2010 at 12:50 AM, Christoph Wickert wrote
Any ideas what made Fedora become so fat or how to further investigate
this?
I've found with Moblin and Sugar that one of the easiest/quickest but
probably not the most eloquent way is to do a 'rpm -qa | sort
rpm-out' and then using some horrible diff hacking to get a rough idea
of what's changed.
rpm -qa --qf %{name}\n | sort rpm-out
then you can diff the two more easily.
I know how to use rpm, but as long as I don't have all the nightlies
there is not much to compare. All I can compare is the F12 spin with the
latest nightly and this wont tell me much about what happened in the
meantime.
Is there an easy way to get previous versions of a package if I have
full n-v-r, say from koji?
You can compare F12's list with the current one.
Sure, but this wont help me understand what happened between
2009-11-11 and 2009-11-19 (+22 MB LXDE, +17 MB Xfce) or between
2010-01-05 and 2010-01-09 (+18 MB LXDE, +14 MB Xfce)
-Mike
Regards,
Christoph
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora has become fat!
On Mon, 22 Mar 2010 21:09:27 +0100, Christoph wrote:
rpm -qa --qf %{name}\n | sort rpm-out
then you can diff the two more easily.
I know how to use rpm, but as long as I don't have all the nightlies
there is not much to compare. All I can compare is the F12 spin with the
latest nightly and this wont tell me much about what happened in the
meantime.
Is there an easy way to get previous versions of a package if I have
full n-v-r, say from koji?
You can compare F12's list with the current one.
Sure, but this wont help me understand what happened between
2009-11-11 and 2009-11-19 (+22 MB LXDE, +17 MB Xfce) or between
2010-01-05 and 2010-01-09 (+18 MB LXDE, +14 MB Xfce)
Do you have the repodata for those days?
Then you could tweak /usr/bin/repodiff (from yum-utils) and make it
examine the changes more closely.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora has become fat!
Am Montag, den 22.03.2010, 21:24 +0100 schrieb Michael Schwendt:
On Mon, 22 Mar 2010 21:09:27 +0100, Christoph wrote:
rpm -qa --qf %{name}\n | sort rpm-out
then you can diff the two more easily.
I know how to use rpm, but as long as I don't have all the nightlies
there is not much to compare. All I can compare is the F12 spin with the
latest nightly and this wont tell me much about what happened in the
meantime.
Is there an easy way to get previous versions of a package if I have
full n-v-r, say from koji?
You can compare F12's list with the current one.
Sure, but this wont help me understand what happened between
2009-11-11 and 2009-11-19 (+22 MB LXDE, +17 MB Xfce) or between
2010-01-05 and 2010-01-09 (+18 MB LXDE, +14 MB Xfce)
Do you have the repodata for those days?
Unfortunately not and I have not idea how/where to get it.
Regards,
Christoph
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
rpm not finding python dependency
Hi, I'm trying to create a package [1], and run into a slight problem when running rpmlint on the resulting rpm: $ rpmlint -i googsystray-1.1.4-2.fc12.noarch.rpm googsystray.noarch: E: explicit-lib-dependency python-xlib You must let rpm find the library dependencies by itself. Do not put unneeded explicit Requires: tags. If i don't specify the 'Requires: python-xlib' line [2], the application doesn't work, because rpm won't find the dependency by itself. Since rpmlint shouldn't output any errors, i'm somewhat at a loss here. Advice would be welcome. [1] https://bugzilla.redhat.com/show_bug.cgi?id=545720 [2] http://leon.fedorapeople.org/files/googsystray/googsystray.spec $ rpm -q rpm rpmlint rpm-4.7.2-1.fc12.x86_64 rpmlint-0.95-2.fc12.noarch regards, Léon -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora has become fat!
On Mon, 22 Mar 2010, Christoph Wickert wrote: then you can diff the two more easily. I know how to use rpm, but as long as I don't have all the nightlies there is not much to compare. All I can compare is the F12 spin with the latest nightly and this wont tell me much about what happened in the meantime. Right so here's what I would do: 1. compare you spin in f12 to f13a - look to see what new pkgs are added and how much space that takes up 2. compare per-pkg how much they've grown - add that up 3. see if either of theabove account for the growth and if either of the above are fixable 4. then start chasing down individual changes in pkgs that could have caused the growth -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm not finding python dependency
On 03/22/2010 04:33 PM, Léon Keijser wrote: Hi, I'm trying to create a package [1], and run into a slight problem when running rpmlint on the resulting rpm: $ rpmlint -i googsystray-1.1.4-2.fc12.noarch.rpm googsystray.noarch: E: explicit-lib-dependency python-xlib You must let rpm find the library dependencies by itself. Do not put unneeded explicit Requires: tags. If i don't specify the 'Requires: python-xlib' line [2], the application doesn't work, because rpm won't find the dependency by itself. Since rpmlint shouldn't output any errors, i'm somewhat at a loss here. Advice would be welcome. Safe to ignore. rpmlint assumes all dependencies which contain the explicit string lib are traditional library (with .so files inside) packages and can be autodetected, as opposed to explicitly stated. In your case, the explicit Requires is correct. ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal
On Sat, 2010-03-20 at 07:14 +0100, Kevin Kofler wrote: Terry Barnaby wrote: Although I understand Fedora's frontier status, I think the graphics system changes could probably have been handled better. After the kernel and core shared libraries the graphics system is probably the next essential core OS subsystem (At least for desktop systems). It seems most of peoples stability issues with fedora stem from graphics. I do understand the difficulty with the multitude of different graphics chipsets out there. But this is where Fedora could shine with its close links to upstream development. It would have been good to be very upfront with this and get a group to define and setup some basic graphics tests and loudly promote users to perform tests with these both pre-release and post-release. This with a website with test status versus graphics board/chipsets and with good easy linkages to Bugzilla (more user friendly) and perhaps a separate graphics-testing repository to keep quick graphics updates away from the stable release etc. If enough upstream developers, Fedora packagers and testing users were in on this I think great inroads into getting stable and good graphics systems would be made in a relatively short time. Unfortunately, a sizeable portion of our users installs some crappy proprietary driver, sometimes not even a properly packaged one, but using some broken installation script directly from the hardware vendor's website, making this all moot. :-( While it is true that our Free drivers are far from perfect as well, most graphics-related problems are actually due to proprietary drivers. Just say NO to proprietary drivers! This isn't really true. Or at least, not a productive perspective for improving Fedora. There are certainly a lot of bugs in the open drivers shipped with Fedora, and there's a lot of work to do to fix them all. I sent my own reply to Terry explaining how we're handling this at present, but just waving the 'it's all NVIDIA's fault' stick at the problem won't make it go away :) -- 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: Evolution trash folder
On Mon, 2010-03-22 at 12:01 +0100, Milan Crha wrote: On Sun, 2010-03-21 at 20:53 -0500, Mike Chambers wrote: No checkmarks checked or unchecked that I could find. The only other explanation is if I did a clean setup (no backups) and see what that does. I might do that with a clean/new test user and see what happens. Hi, try to run Evolution from console, and see what it says, if anything, in time of deleting the message. One thing I do not understand from your description, when you delete message (press a Del button), the message is marked as deleted and either is removed from the message list or shown there with a strike out font. It should be also visible in the account's Trash folder. Because your Folder-Expunge does correct thing, then the message is marked as deleted. Thus I guess your UI is not showing the right thing, does it do at least one of the above mentioned? Maybe the index for a Trash folder is corrupted for some reason; you can try to stop Evolution and move out your ~/.evolution/mail/imap/account/folders.db file, but as it contains all your account index, then the next start will take some time, till it fills it again. Or you can drop only all Trash related tables from there, but it's not as that easy to do. If something goes wrong, then return the folders.db file back. Yes the message was indeed marked with a strike out font, but it was never sent to the trash folder. I did already remove my .evolution folder and restarted evolution again, and now the emails at least get moved to the trash folder when deleted. The only thing I see now, is when I close/exit evolution it doesn't automatically empty the trash folder, and it is set in my preferences to do it every time. Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
load a program automaticly as root(xinitrc-common not work any more)
Hi I used to use xinitrc-common to load my program as root automaticly,but this mothod stop working since FC11.What can I do if I still need to load my program as root (in system scripts)? Any kind of help will be appreciated because I can't manage to find any Docs about this change at all. Roy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
bug no: 552456 E620 not detected - 2nd Request
Hi all, I am trying to get my k3715 to work in F12 or F13. I have filled this bug report https://bugzilla.redhat.com/show_bug.cgi?id=552456 . It reports by dmesg as a E620. The modem works fine in F11 with no usb_modeswitch. But by default the CD Rom and Memory card a re disabled by default. In F12 and F13 the option driver reports a callback error of 108. But the CD Rom and Memory card are enabled. I tried usb_modeswitch. but this has no effect. In searching this seem to be Linux. wide problem across all distributions. And some distributions say that it is fixed. (not confirmed) See my bug report for more details. I am just trying to get this long standing problem fixed. Any help that I can be please ask. Steven Drinnan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: usb_modeswitch by default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rahul Sundaram wrote: Just to clarify, does ModemManager need to depend on usb_modeswitch? It currently does not. Dan, I guess its not such a bad idea to make it depend? Rahul - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas) GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/ iD8DBQFLqDMazHDc8tpb2uURAqpAAKCR3Nf3HtEbcGI3FiXvgKqF4xEqyQCfcrNL JQqNaOS8dvbtcDYdjLXeh3E= =NbZv -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 13 Beta TC#1 Available Now!
Hi all, F13 Beta TC1 has been uploaded, please follow the guidance in the below links: Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Many thanks, Hurry Forwarded Message From: He Rui r...@redhat.com Reply-to: fedora-test-l...@redhat.com To: test-announce test-annou...@lists.fedoraproject.org Subject: [Test-Announce] Fedora 13 Beta TC#1 Validation Test Date: Thu, 18 Mar 2010 16:00:25 +0800 Greetings, Fedora 13 Beta Test Compose test is arriving[1]. Thanks for the ones who attended/paid attention on alpha test and please continue enjoying the validation test on Beta. This time all the alpha and beta priority test cases of installation[2] and desktop[3] should be passed to ensure they meet the Beta Release Criteria [4]. You can follow the guidance and download the images(once it's available) to execute test cases at: Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Don't hesitate to leave your results on the above pages and please feel free to discuss queries/problems/issues on #fedora-qa or t...@lists.fedoraproject.org. Many thanks, Hurry [1] http://poelstra.fedorapeople.org/schedules/f-13/f-13-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [4] https://fedoraproject.org/wiki/Fedora_13_Beta_Release_Criteria -- Contacts FAS Name: Rhe Location: Beijing/UTC+8 TEL: 86-010-62608141 IRC nick: rhe #fedora-qa #fedora-zh ___ 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
[Bug 575807] New: Currently no EL builds for perl-Text-WikiFormat
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Currently no EL builds for perl-Text-WikiFormat https://bugzilla.redhat.com/show_bug.cgi?id=575807 Summary: Currently no EL builds for perl-Text-WikiFormat Product: Fedora EPEL Version: el5 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: perl-Text-WikiFormat AssignedTo: tcall...@redhat.com ReportedBy: trem...@tremble.org.uk QAContact: extras...@fedoraproject.org CC: tcall...@redhat.com, fedora-perl-devel-l...@redhat.com, trem...@tremble.org.uk Classification: Fedora I (tremble) am currently trying to get the various packages we use at work into EPEL, perl-Text-WikiFormat is one of these packages. While there is already an EL-5 branch for this package there do not appear to be any EPEL builds. Would it be possible for you to build perl-Text-WikiFormat and add it to EL-5 EPEL? I am willing to co-maintain the EL branch (and Fedora branches) if you would like. -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Text-WikiFormat/EL-5 perl-Text-WikiFormat.spec, 1.4, 1.5 sources, 1.4, 1.5
Author: spot
Update of /cvs/pkgs/rpms/perl-Text-WikiFormat/EL-5
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv24629
Modified Files:
perl-Text-WikiFormat.spec sources
Log Message:
sync to devel
Index: perl-Text-WikiFormat.spec
===
RCS file: /cvs/pkgs/rpms/perl-Text-WikiFormat/EL-5/perl-Text-WikiFormat.spec,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- perl-Text-WikiFormat.spec 31 Mar 2006 16:52:19 - 1.4
+++ perl-Text-WikiFormat.spec 22 Mar 2010 13:43:30 - 1.5
@@ -1,16 +1,15 @@
Name: perl-Text-WikiFormat
-Version:0.78
-Release:1%{?dist}
+Version:0.79
+Release:5%{?dist}
Summary:Translate Wiki formatted text into other formats
Group: Development/Libraries
-License:GPL or Artistic
+License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Text-WikiFormat/
Source0:
http://www.cpan.org/authors/id/C/CH/CHROMATIC/Text-WikiFormat-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
-BuildRequires: perl
BuildRequires: perl(Module::Build)
BuildRequires: perl(URI::Escape)
BuildRequires: perl(Scalar::Util) = 1.14
@@ -41,7 +40,6 @@ chmod -R u+w $RPM_BUILD_ROOT/*
%check
-mv t/developer/0-signature.t t/developer/0-signature.t.disable
PERL_RUN_ALL_TESTS=1 ./Build test
@@ -53,10 +51,25 @@ rm -rf $RPM_BUILD_ROOT
%defattr(-,root,root,-)
%doc ARTISTIC Changes GPL README
%{perl_vendorlib}/Text/
-%{_mandir}/man3/*.3*
+%{_mandir}/man3/*.3pm*
%changelog
+* Fri Dec 4 2009 Stepan Kasal ska...@redhat.com - 0.79-5
+- rebuild against perl 5.10.1
+
+* Sun Jul 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.79-4
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
+
+* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.79-3
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
+
+* Thu Mar 06 2008 Tom spot Callaway tcall...@redhat.com - 0.79-2
+Rebuild for new perl
+
+* Fri Jun 29 2007 Jose Pedro Oliveira jpo at di.uminho.pt - 0.79-1
+- Update to 0.79.
+
* Fri Mar 31 2006 Jose Pedro Oliveira jpo at di.uminho.pt - 0.78-1
- Update to 0.78.
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Text-WikiFormat/EL-5/sources,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- sources 31 Mar 2006 16:52:19 - 1.4
+++ sources 22 Mar 2010 13:43:31 - 1.5
@@ -1 +1 @@
-646c0ea411247a0293eb69a216451beb Text-WikiFormat-0.78.tar.gz
+7f3e888ff898f67332216c4a25523f30 Text-WikiFormat-0.79.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: vendor vs core?
- Chris Weyl cw...@alumni.drew.edu wrote: One thing we didn't talk about here -- given that the independent subpackages are replacing dual-lifed core modules, should we be using %perl_archlib/_privlib rather than %perl_vendorarch/_vendorlib? I realise this is mainly nomenclature here, as we currently have one set to the other, but it would seem to make sense (especially if we go back to having distinct vendor directories). I have a preference to using the core macros vs vendor macros, but am ok with it either way as long as we realize that we're making a choice here. -Chris -- Chris Weyl Ex astris, scientia -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel I agree with core macros. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 575807] Currently no EL builds for perl-Text-WikiFormat
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=575807 --- Comment #1 from Fedora Update System upda...@fedoraproject.org 2010-03-22 09:54:04 EDT --- perl-Text-WikiFormat-0.79-5.el5 has been submitted as an update for Fedora EPEL 5. http://admin.fedoraproject.org/updates/perl-Text-WikiFormat-0.79-5.el5 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Audio-Beep-0.11.tar.gz uploaded to lookaside cache by hpejakle
A file has been added to the lookaside cache for perl-Audio-Beep: 6956a8749c8dbdcbd44577f7900e85dc Audio-Beep-0.11.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Audio-Beep/devel import.log, NONE, 1.1 perl-Audio-Beep.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: hpejakle
Update of /cvs/pkgs/rpms/perl-Audio-Beep/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv26122/devel
Modified Files:
.cvsignore sources
Added Files:
import.log perl-Audio-Beep.spec
Log Message:
* Mon Mar 15 2010 Jan Klepek 0.11-1
- Specfile autogenerated by cpanspec 1.78.
--- NEW FILE import.log ---
perl-Audio-Beep-0_11-1_fc11:HEAD:perl-Audio-Beep-0.11-1.fc11.src.rpm:1269295229
--- NEW FILE perl-Audio-Beep.spec ---
Name: perl-Audio-Beep
Version:0.11
Release:1%{?dist}
Summary:Audio::Beep Perl module
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Audio-Beep/
Source0:
http://www.cpan.org/authors/id/G/GI/GIULIENK/Audio-Beep-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
Requires: beep
BuildArch: noarch
%{?perl_default_filter}
%description
Audio::Beep - Perl module to use your computer beeper in fancy ways
%prep
%setup -q -n Audio-Beep-%{version}
chmod -x music/*.pl
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README music
%{perl_vendorlib}/Audio*
%{_mandir}/man3/*
%changelog
* Mon Mar 15 2010 Jan Klepek 0.11-1
- Specfile autogenerated by cpanspec 1.78.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Audio-Beep/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 19 Mar 2010 20:09:02 - 1.1
+++ .cvsignore 22 Mar 2010 22:01:42 - 1.2
@@ -0,0 +1 @@
+Audio-Beep-0.11.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Audio-Beep/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 19 Mar 2010 20:09:02 - 1.1
+++ sources 22 Mar 2010 22:01:42 - 1.2
@@ -0,0 +1 @@
+6956a8749c8dbdcbd44577f7900e85dc Audio-Beep-0.11.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
