Re: The new Update Acceptance Criteria are broken
On Fri, Nov 12, 2010 at 01:14:12PM -0700, Kevin Fenzi wrote: No. The issue is that in the past sometimes security updates have been rushed out with no testing and broken things badly. ;( See http://fedoraproject.org/wiki/Updates_Lessons For some small number of examples (yes, anyone is welcome to please add others you have run into to the page). The documented issues do not seem to be as bad as a system being exploited. It is only about dependency breakage or services not working anymore. There is no major data corruption requiring access to backups and restoring the whole system. But this is what people using Fedora with proftpd and being exploited have to do. Regards Till pgpICiImShN3l.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On Fri, Nov 12, 2010 at 11:19:22AM -0800, Adam Williamson wrote: Thanks for flagging this up. I'm wondering if perhaps we should devise a system - maybe a sub-group of proventesters - to ensure timely testing of security updates. wdyt? I am not sure if a smaller group would help here. But what is certainly missing is proper monitoring of updates that need to be tested asap and notify testers or people in charge of untested updates. Regards Till pgpwTifkIi9b8.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101113 changes
Compose started at Sat Nov 13 08:15:05 UTC 2010 Broken deps for x86_64 -- apcupsd-3.14.8-3.fc15.x86_64 requires libnetsnmp.so.20()(64bit) balsa-2.4.7-2.fc14.x86_64 requires libnotify.so.1()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0()(64bit) beagle-0.3.9-19.fc14.x86_64 requires libmono.so.0(VER_1)(64bit) bognor-regis-0.6.11-1.fc15.i686 requires libnotify.so.1 bognor-regis-0.6.11-1.fc15.x86_64 requires libnotify.so.1()(64bit) cluster-glue-1.0.6-1.fc14.x86_64 requires libnetsnmp.so.20()(64bit) cluster-snmp-0.18.1-1.fc15.x86_64 requires libnetsnmp.so.20()(64bit) clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) 0:1.3.0 clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) 0:1.3.0 db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0 dh-make-0.55-2.fc15.noarch requires debhelper edje-0.9.99.49898-1.fc14.i686 requires libecore_evas-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libecore_imf-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libembryo-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libecore-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libecore_imf_evas-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libeina-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libecore_file-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.i686 requires libevas-ver-svn-06.so.0 edje-0.9.99.49898-1.fc14.x86_64 requires libevas-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libeina-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libecore_file-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libembryo-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libecore_evas-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libecore_imf-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libecore-ver-svn-06.so.0()(64bit) edje-0.9.99.49898-1.fc14.x86_64 requires libecore_imf_evas-ver-svn-06.so.0()(64bit) edje-devel-0.9.99.49898-1.fc14.i686 requires pkgconfig(eina-0) edje-devel-0.9.99.49898-1.fc14.x86_64 requires pkgconfig(eina-0) efreet-0.5.0.49898-1.fc14.i686 requires libecore-ver-svn-06.so.0 efreet-0.5.0.49898-1.fc14.i686 requires libeina-ver-svn-06.so.0 efreet-0.5.0.49898-1.fc14.i686 requires libecore_file-ver-svn-06.so.0 efreet-0.5.0.49898-1.fc14.x86_64 requires libeina-ver-svn-06.so.0()(64bit) efreet-0.5.0.49898-1.fc14.x86_64 requires libecore-ver-svn-06.so.0()(64bit) efreet-0.5.0.49898-1.fc14.x86_64 requires libecore_file-ver-svn-06.so.0()(64bit) efreet-devel-0.5.0.49898-1.fc14.i686 requires pkgconfig(eina-0) efreet-devel-0.5.0.49898-1.fc14.x86_64 requires pkgconfig(eina-0) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libeconnman-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libevas-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libeina-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libehal-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_input_evas-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libedbus-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_input-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_file-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_evas-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libebluez-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libeofono-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_x-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_imf-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_con-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_ipc-ver-svn-06.so.0()(64bit) enlightenment-0.16.999.49898-1.fc14.x86_64 requires libecore_imf_evas-ver-svn-06.so.0()(64bit) enlightenment-devel-0.16.999.49898-1.fc14.i686 requires pkgconfig(eina-0) enlightenment-devel-0.16.999.49898-1.fc14.x86_64 requires pkgconfig(eina-0) eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit)
Re: Orphaning my packages
Hello, Le 21/10/2010 21:12, Roozbeh Pournader a écrit : pyfribidi I take this one that childsplay depends on. Regards, Johan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
2010/11/12 Kevin Fenzi ke...@scrye.com: * Can we finally remove hal? (xfce4.8 shouldn't need it anymore with any luck). For the record, you can check the current status here: [1] Also, the tracker bug in GNOME bugzilla: [2] Regards [1] http://fedoraproject.org/wiki/Features/HalRemoval [2] https://bugzilla.gnome.org/show_bug.cgi?id=593938 -- Javier Jardón Cabezas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Confused with budhi: my package is pushed to stable, but resides in updates-testing!?!
Hi all, According to [1], my updated simspark package has been pushed to stable; but it is not! The package is available in updates-testing. I wonder if it is expected considering the new updating criteria or it is a bug. Anyway, it is confusing. What's happening? Finally a question: this update is simply a rebuild of the package and I wanted it to reside in updates repository ASAP (For whatever reason, the previous build causes an application using this library to crash; but it is fixed with a rebuild of the packages. I don't know why, but a rebuild fixes the problem.). Thanks, Hedayat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On Sat, Nov 13, 2010 at 10:21:30AM +0100, Till Maas wrote: The documented issues do not seem to be as bad as a system being exploited. It is only about dependency breakage or services not working anymore. There is no major data corruption requiring access to backups and restoring the whole system. But this is what people using Fedora with proftpd and being exploited have to do. If security updates break functionality then people will stop applying security updates. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On 11/12/2010 11:14 PM, Tom Lane wrote: Clyde E. Kunkelclydekunkel7...@cox.net writes: snip The major packages that I work with have regression test suites, which in fact get run as part of the RPM build sequence. It's not apparent to me that I should need to invent some more tests. I did not know that. Good to know. Would it help if the test cases were mentioned so their use could be considered in providing karma? Or, even if they were made available? Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Fri, 2010-11-12 at 18:07 -0500, Sam Varshavchik wrote: Kevin Fenzi writes: * gnome3 / gnome-shell default And what about systems with hardware that does not support accelerated 3D? There will be a fallback to gnome-panel, Metacity, and notification-daemon * The fallback components have been adapted to work better with GNOME 3 applications; for example notification behavior is more like the GNOME 3 behavior where notifications that time out can still be accessed, so you don't need a status icon just so the user can see that something happened (ABRT, PackageKit reboot notifications, etc.) * But there is no attempt to make it seamless; we won't be going to a black panel for GNOME 2 or having a 2D-graphics Activities Overview replacement. * Some features may be missing as compared to GNOME 2 when running in fallback mode. One example is that there will be no desktop magnifier in the fallback. - Owen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On 11/13/2010 10:45 AM, Owen Taylor wrote: On Fri, 2010-11-12 at 18:07 -0500, Sam Varshavchik wrote: Kevin Fenzi writes: * gnome3 / gnome-shell default Does anyone happen to know how to mimic the equivalent of panel applets esp those which are not a part of fedora e.g. I use mathematica all the time and in gnome 2.x I put an icon on the panel. The only way I could see so far from looking at the gnome-3 website is to ALT-F2 to start an application - then right click to add the app to 'favorites' ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Confused with budhi: my package is pushed to stable, but resides in updates-testing!?!
/*Hedayat Vatankhah hedayat@gmail.com*/ wrote on 11/13/2010 5:28:49 PM +0350: Hi all, According to [1], my updated simspark package has been pushed to stable; but it is not! The package is available in updates-testing. I wonder if it is expected considering the new updating criteria or it is a bug. Anyway, it is confusing. What's happening? Finally a question: this update is simply a rebuild of the package and I wanted it to reside in updates repository ASAP (For whatever reason, the previous build causes an application using this library to crash; but it is fixed with a rebuild of the packages. I don't know why, but a rebuild fixes the problem.). Thanks, Hedayat Oops, sorry: [1] https://admin.fedoraproject.org/updates/simspark-0.2.1-3.fc14?_csrf_token=eb47995b995f378b3b59fdc2b2cc12da44330ef9 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
Le jeudi 11 novembre 2010 à 21:05 -0500, Ding Yi Chen a écrit : Well, actually input methods can do that. :-) They know exactly what language you are typing, and some do basic spelling check in the language they support. Sorry, but no. Appart from the well known stability problems, which means input methods are not enabled by default for most users, and badly integrated into apps, input methods *still* confuse input system and langage, and assume that you need a qwerty layout to type English. I despair of making *nix input people understand that LANGAGE ≠ INPUT Please stop trying to derive one from the other, they are *distinct* and one can (and often does) use a non-english layout to type English. It's about as smart as trying to find German people in Europe by searching for Volkswagen cars. Sometimes it will be right, most often it will be terribly wrong. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
/*Kevin Fenzi ke...@scrye.com*/ wrote on 11/12/2010 8:05:54 PM +0350: Greetings. Fedora 14 was a pretty relaxing and stable release. I'm thinking that Fedora 15 may be much more exciting. ;) Things I know of so far: * systemd * gnome3 / gnome-shell default * removing a bunch of suid stuff in favor of capabilities * xfce 4.8 (with any luck). Things that are out there, but no idea if anyone is working on them or if they might be ready by f15: * grub2 (no one is driving for this that I know of, but has some advantages over our grub1 if someone is willing to run with it, although it may be a lot of work to get it to where we need it). * btrfs (Is this ready to be default? :) If so, would that warrant a change in our lvm by default setup? * Can we finally remove hal? (xfce4.8 shouldn't need it anymore with any luck). * Will NM finally be able to do bridging? * Some kind of packaged wayland to play with, even if it doesn't do much? Any other exciting work in progress that might land in F15 that people are actively working on? We at Fedora Robotics SIG are working on Fedora Robotics Spin for Fedora 15. It's a bit special purpose but it might look interesting too :) kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Retiring genesis
Hi all, I've read some months late the following announcement regarding genesis: https://launchpad.net/genesis-sync/+announcement/5958 Genesis is now strictly linked to Ubuntu development deprecating the system tray altogether and encouraging the use of application indicators. Moreover the focus is now on quick access to basic sync operations, leaving configuration tasks and fine-grained control to syncevolution-gtk. I do not think it is still valuable to have genesis in Fedora. What kind of retirement policy do you suggest? I.e. when do you think I should retire it? This would be the first package I retire. If I understand correctly I have to follow this process: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Regards, Andrea. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
orphaning a bunch of packages
Hi all, I haven't had the time to even look at these packages and keep them up to date, so I'm orphaning them. Please take them if they are important to you :) Many of these have either dead/slow upstreams, or I'm too dead/slow to update them in time. ezstream gnome-gmail-notifier irclog2html lordsawar odfpy python-flickrapi python-mwlib python-transitfeed rsstool wordpress-plugin-add-to-any wordpress-plugin-add-to-any-subscribe -- Ian Weller i...@ianweller.org Where open source multiplies: http://opensource.com pgpWg3ZUyp2Me.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ubuntu moving towards Wayland
On Sat, Nov 13, 2010 at 18:01, Nicolas Mailhot nicolas.mail...@laposte.net wrote: I despair of making *nix input people understand that LANGAGE ≠ INPUT Please stop trying to derive one from the other, they are *distinct* and one can (and often does) use a non-english layout to type English. It's about as smart as trying to find German people in Europe by searching for Volkswagen cars. Sometimes it will be right, most often it will be terribly wrong. Yes, and it has nothing to do with system-wide or even session-wide settings IMHO. I'm a French guy living in GB. I type on French AZERTY or UK QWERTY hardware layouts, occasionally German QWERTZ. My software layout layout is always QWERTY US. I mostly use the en_US.UTF-8 locale, but some systems use en_GB.UTF-8. My timezone is Europe/London on my desktop, UTC in my servers and most virtual machines. And the one time I could really significantly benefit from a spell checking mechanism is when I try to improve my Spanish on #fedora-es. Only the application can often have lucky guesses or can be efficiently taught, unless one comes up with über-heuristics (for #fedora-es, the IRC client based on the channel I'm in). If you have good reasons to put language information in the input layer of the UI infrastructure, I'd love to hear which :) And I'd be really pleased if software kept letting me get rid of the Magic most might want. That's one big criteria when I pick my alternatives. Cheers, -- Pierre Carrier -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Updates to static library packages
Hi, I maintain LibRaw, which is only a static library -- upstream has rejected the idea of maintaining dynamic libs since they would have to take care of ABI compatibility across releases. I wanted to know if there are any other only-static libraries out there and how they maintainers manage releases. I had packaged this to build Shotwell 0.6.x but I understand there are a couple of other apps too that build against this now. Do i have to keep track of all of them and coordinate releases with them, i.e. announce an update, have them test and then push a build? Or do I just go ahead and build in rawhide and then wait for someone to complain? Thanks, Siddhesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: still a 2TB limit in F14 Anaconda, for LVM PV size
On Fri, Nov 12, 2010 at 09:28:06AM +0100, Hans de Goede wrote: Boot the installer into rescue mode and run parted /dev/path-to-entire-disk And in parted do: mklabel gpt For VMs you can do: guestfish -a /dev/path-to-VM-disk run : part-init gpt (which destroys any data on /dev/path-to-VM-disk), and then proceed with virt-install/whatever as usual. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Fri, Nov 12, 2010 at 06:26:48PM +, Jóhann B. Guðmundsson wrote: *DE could consider switching the default to use EXT4 directly without LVM. [1] 1. http://fedoraproject.org/wiki/Features/NoDefaultLVM The Detailed Description seems contradictory: | LVM provides very little benefit for most Fedora users, at the cost of | performance and complexity: | | * Certain filesystem features (ext3 barriers) are unavailable when run | on top of LVM. Isn't this just a bug which should be fixed? (I actually thought this had been fixed already) | * Software RAID performance is greatly reduced when layered on LVM. But the stated task is to get rid of LVM except for experts in storage administration (from the next section of the same document). Who will presumably be the only ones wanting Software RAID. The non-experts won't know anything about Software RAID, so they won't be affected by this performance problem with LVM. | * LVM partitions are not automatically assembled by the desktop systems. I'm not sure what this one means. assembled as in what happens when you spread a VG over multiple block devices? Anyway, I think LVM is jolly useful: - You can expand the root filesystem (eg. into spare space or across block devices). - You can live pvmove filesystems from one device to another. It may be that the tooling is not there to make these features available for non-experts, but that's a problem with lack of tools, not with LVM. Partition tables are horrible and inflexible in comparison to LVM. Can we at the very least have some numbers backing up the supposed performance problems? 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
Taking owernship of djvulibre (orphaned) in EPEL*
Hello packagers, As djvulibre is (optionally, build-time choice) required by apvlv, which I am currently packaging ( http://pcarrier.fedorapeople.org/wip/apvlv/ ), I am taking ownership of the package in EPEL4,5,6. No bug reports related to EPEL ATM. Cheers, -- Pierre Carrier -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sat, 13.11.10 23:41, Richard W.M. Jones (rjo...@redhat.com) wrote: On Fri, Nov 12, 2010 at 06:26:48PM +, Jóhann B. Guðmundsson wrote: *DE could consider switching the default to use EXT4 directly without LVM. [1] 1. http://fedoraproject.org/wiki/Features/NoDefaultLVM Anyway, I think LVM is jolly useful: - You can expand the root filesystem (eg. into spare space or across block devices). - You can live pvmove filesystems from one device to another. It may be that the tooling is not there to make these features available for non-experts, but that's a problem with lack of tools, not with LVM. Partition tables are horrible and inflexible in comparison to LVM. Well, there's no doubt that LVM has its uses, but that doesn't mean we should install it by default on every Fedora installation. LVM actually slows down boot considerably. Not primarily because its code was slow or anything, but simply because it isn't really written in the way that things are expected to work these days. The LVM assembly at boot is expected to be run at a time where all disks have been found by the kernel and identified. However, the idea that such a time exists is out-of-date on modern systems. There is simply no point in time where all disks have been enumerated, because they can always come and go and on many busses (for example USB), you never know whether you have enumerated all devices, because the bus doesn't support a notion like that. The right way how to implement a logic like this is to wait exactly until all disks actually *needed* have shown up and at that time assemble LVM. Currently, to make LVM work, we however try to wait until *everything* thinkable is enumerated, not only the disks that are actually needed. The fact that on many busses this point in time doesn't really exist is ignored, and awful hacks such as modprobe scsi_wait_scan are used to work around this out-of-date design on the other busses. To get to a fast system however, you should minimize the time you waste and continue withthe next step of booting the moment you have collected all devices you need for assembly. We definitely should stop setting up LVM by default on Fedora, because it allows us to disable these unnecessary enumeration delays that are broken by design anyway. If we don't have LVM on default installs, we also don't need scsi_wait_scan anymore, and that would be great. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
build rpm packages such as Redhat/Fedora
Hello Fedora Devel List, Im a newcomer with mock and rpmbuild. How can I rebuild el6 packages such as Redhat? My idea would be yum install mock useradd mockbuild usermod -G mock mockbuild mock rebuild -r epel-6-x86_64 /home/mockbuild/kernel-2.6.32-71.7.1.el6.src.rpm Is that right? Should I use Fedora (13,14) or Redhat Enterprise Linux 6? Chris -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Updates to static library packages
Michel Alexandre Salim wrote: Incidentally, does anyone know how to keep track of which package lists something as a *build* requirement? repoquery has --whatrequires and --tree-whatrequires, and has an --srpm option that seems promising, but does not seem to do the trick. Thanks to http://yum.baseurl.org/wiki/RepoQuery If you need to figure out which srpms have a buildrequirement on a particular pkgname run: repoquery --archlist=src --repoid=some_repo_with_srpms \ -q --whatrequires pkgname -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
On Sun, 2010-11-14 at 10:56 +1000, Chris Jones wrote: On Sun, 2010-11-14 at 01:14 +0100, Lennart Poettering wrote: LVM actually slows down boot considerably. Not primarily because its code was slow or anything, but simply because it isn't really written in the way that things are expected to work these days. This is true and all. But it's easily worked around by keeping /boot on a non-LVM partition. I use a LVM setup and it works flawlessly. /boot on ext2, and / on LVM ext4. And you can't really complain at a 5-6 second boot time with the aforementioned setup. There's absolutely no reason to remain on old style DOS partitioning setups on Linux. As I read lennart's post, he's talking about regular old init, after the kernel and initrd have come up. so what you do with /boot is irrelevant. -- 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 15, new and exciting plans (biosdevname)
On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote: Greetings. Fedora 14 was a pretty relaxing and stable release. I'm thinking that Fedora 15 may be much more exciting. ;) biosdevname installed by default, used in the installer and at runtime to rename Dell and HP server onboard NICs from non-deterministic ethX to clearly labeled lomX matching the chassis silkscreen. http://marc.info/?l=linux-hotplugm=128892593821639w=2 Exciting, not really. Necessary, absolutely! Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning a bunch of packages
On Sat, Nov 13, 2010 at 12:50:51PM -0600, Ian Weller wrote: Hi all, I haven't had the time to even look at these packages and keep them up to date, so I'm orphaning them. Please take them if they are important to you :) Many of these have either dead/slow upstreams, or I'm too dead/slow to update them in time. irclog2html I think Fedora Infrastructure uses this for zodbot logs, yes? I've used it for Town Hall log postings predating zodbot. I or someone in FI should take it if it's actively used... -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: boot.fedoraproject.org default repo on installation
On Fri, Nov 12, 2010 at 02:02:28PM +0100, Rudolf Kastl wrote: Heyyas. I actually gave boot.fedoraproject.org a testrun and i realized that by default a repository called installation is selected with a static repo url. instead i have actually figured that selecting the usual standard fedora repositories work aswell and they point to the mirrorlist instead. Why is a seperate installation repo selected by default? I use this setup for installs from behind my firewalls, where I would need an HTTP proxy to reach the normal Fedora mirrorlist public repos, but where my installation repo is inside the firewall, so install can complete, and I can later instruct yum to use a proxy to get updates etc. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning a bunch of packages
On Sat, Nov 13, 2010 at 08:37:19PM -0600, Matt Domsch wrote: On Sat, Nov 13, 2010 at 12:50:51PM -0600, Ian Weller wrote: Hi all, I haven't had the time to even look at these packages and keep them up to date, so I'm orphaning them. Please take them if they are important to you :) Many of these have either dead/slow upstreams, or I'm too dead/slow to update them in time. irclog2html I think Fedora Infrastructure uses this for zodbot logs, yes? I've used it for Town Hall log postings predating zodbot. I or someone in FI should take it if it's actively used... supybot-meetbot, which is what we use these days for zodbot, does its own log creation, not using irclog2html. I withdraw my offer to take this then. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On Sat, Nov 13, 2010 at 08:34:54PM -0600, Matt Domsch wrote: On Fri, Nov 12, 2010 at 09:35:54AM -0700, Kevin Fenzi wrote: Greetings. Fedora 14 was a pretty relaxing and stable release. I'm thinking that Fedora 15 may be much more exciting. ;) biosdevname installed by default, used in the installer and at runtime to rename Dell and HP server onboard NICs from non-deterministic ethX to clearly labeled lomX matching the chassis silkscreen. http://marc.info/?l=linux-hotplugm=128892593821639w=2 Exciting, not really. Necessary, absolutely! Feature page: https://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: The new Update Acceptance Criteria are broken
On Sat, 2010-11-13 at 14:22 +, Matthew Garrett wrote: On Sat, Nov 13, 2010 at 10:21:30AM +0100, Till Maas wrote: The documented issues do not seem to be as bad as a system being exploited. It is only about dependency breakage or services not working anymore. There is no major data corruption requiring access to backups and restoring the whole system. But this is what people using Fedora with proftpd and being exploited have to do. If security updates break functionality then people will stop applying security updates. That may be true in general, but I think Till has given a compelling example in which many (most?) users would prefer an update with some probability of being broken to no update. If necessary, we could have a separate repository of urgent updates that sysadmins could choose to enable or not based on their security and stability needs. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans (biosdevname)
On 11/13/2010 06:34 PM, Matt Domsch wrote: biosdevname installed by default, used in the installer and at runtime to rename Dell and HP server onboard NICs from non-deterministic ethX to clearly labeled lomX matching the chassis silkscreen. http://marc.info/?l=linux-hotplugm=128892593821639w=2 In that message I see: ** No rename for all others ethX (no change for NICs in PCI slots/USB/others) I'd like an option to assign ethX to NICs in /sys/devices/pci* order. This matches chassis PCI slot order on many, many motherboards. I get confused when ethX is assigned in a different order. You can bind ethX to a specific card [not slot] by using HWADDR= in /etc/sysconfig/network-scripts/ifcfg-ethX. That's fine, but I prefer an option to assign ethX by PCI slot, because that's what I can see when I plug in the cables. My NICs are various brands and models, but I treat them all as generic because that is much simpler, especially in the beginning. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 590074] RFE : please build perl-Net-CUPS for EPEL
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=590074 Remi Collet fed...@famillecollet.com changed: What|Removed |Added Priority|low |high --- Comment #1 from Remi Collet fed...@famillecollet.com 2010-11-13 03:14:15 EST --- Can you please create el5 and el6 branch ? Version 0.61 build fine for both release. If you don't want to maintain this package in EPEL, please ask for branch and set me as the owner. -- 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
[perl-Email-Send] Created tag perl-Email-Send-2.198-1.el6
The lightweight tag 'perl-Email-Send-2.198-1.el6' was created pointing to: 1c87058... Merge remote branch 'origin/master' into el6/master -- 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
[perl-Text-SpellChecker/el6/master] (3 commits) ...Merge remote branch 'origin/master' into el6/master
Summary of changes: c7b01fd... Update to 0.07 and use hunspell backend (*) 4675315... Update to 0.08 (*) 246f748... Merge remote branch 'origin/master' into el6/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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Text-SpellChecker/el6/master: 3/3] Merge remote branch 'origin/master' into el6/master
commit 246f74875966ef3d0f37aeb49125a3de8b2cce4f Merge: f6d8753 4675315 Author: Paul Howarth p...@city-fan.org Date: Sat Nov 13 08:24:07 2010 + Merge remote branch 'origin/master' into el6/master .gitignore |2 +- Text-SpellChecker-0.07-dictpath.patch | 20 +++ Text-SpellChecker-0.08-testsuite.patch | 23 ++ perl-Text-SpellChecker.spec| 41 +--- sources|2 +- 5 files changed, 77 insertions(+), 11 deletions(-) --- -- 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
[perl-Text-SpellChecker] Created tag perl-Text-SpellChecker-0.08-1.el6
The lightweight tag 'perl-Text-SpellChecker-0.08-1.el6' was created pointing to: 246f748... Merge remote branch 'origin/master' into el6/master -- 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 626218] Missing perl-Email-Send in EPEL6
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=626218 Paul Howarth p...@city-fan.org changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Email-Send-2.198-1.el6 Resolution||NEXTRELEASE Last Closed||2010-11-13 03:41:16 --- Comment #2 from Paul Howarth p...@city-fan.org 2010-11-13 03:41:16 EST --- The EPEL-6 buildroot now contains perl-MIME-tools and I have been able to build perl-Email-Send. -- 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
[perl-Math-GMP/el6/master] Use hunspell dictionary for spell check test
commit cc82cc2052aa2fd3f095010dae2f4811af3c62d5 Author: Paul Howarth p...@city-fan.org Date: Sat Nov 13 09:33:36 2010 + Use hunspell dictionary for spell check test Change BR: aspell-en to hunspell-en now that Text::SpellChecker uses a hunspell back-end, adding patch for words missing from EL-6 dictionary 161C06B1.asc | 68 ++ perl-Math-GMP-2.06-stopwords.patch | 72 perl-Math-GMP.spec | 15 ++- 3 files changed, 152 insertions(+), 3 deletions(-) --- diff --git a/161C06B1.asc b/161C06B1.asc new file mode 100644 index 000..0e66bed --- /dev/null +++ b/161C06B1.asc @@ -0,0 +1,68 @@ +-BEGIN PGP PUBLIC KEY BLOCK- +Version: GnuPG v1.4.10 (GNU/Linux) + +mQGiBDQq3yMRBADjxe7/+OMSOtCbYBNqxPyTj9ZIIeJ/KuB6rNocwl4FexgEG8yO +sOoShE6dTmJwx7NKnOUSuc8Ujz6tpdspJ9z40Kiv/J83aZfJwTNos9NsRK7y6y4F +kFlrqXN+PVZ+F3J/4Qp0xPB16F51LCnjTscs4Q9SoOa9iK2qsut/uC3wGQCg//tO +0PDbeCRuLY4+BNjLqZeUTCsD/1H92+BpSsmHSm2bRFPaiRysUpvINaMfByqMbppF +Mi5Eth3Tk8vD4dsLi4VMD7cT/4MYDGe/lW9eJSfWvXl2iG4/gx8iKH6DYaCPdnWK +g/mb6ena16ulNPV8VdTTAfjrdSky5kz7nE8ayYuICOuwInbA6MNTHZscfnGPlT/6 +jTXcA/9Vu47w8TlDiUMFCXaIQPHpp+GO2e23Ty2Qe0/Jc7lRIkseJrhsBBT056LX +C9O1BV3lLC0ug5rdGIi30U6Ou+mp1OxoNa44vyZVPtYWWphYnAA5Yvq6xnG8Gdqr +6vOvQ0dSQpdUHE2qtB8CdXIp3bocQj08Sj8JNpYr2MMx9X7IqbQgUGF1bCBIb3dh +cnRoIDxwYXVsQGNpdHktZmFuLm9yZz6IUQQQEQIACQUCO7xEoQIZAQASCRB6ZZLP +FhwGsQdlR1BHAAEBxTYAn0kB5mJCH1eRJ0ncSO83+T/5ZPfjAJ9q5stitnLZrNeH +iz8a7DM9bRTPu4hGBBARAgAGBQI7vFaEAAoJEOC+acm1aousyHUAoIgghFArB3Tv +eXw/xt7/s+a1iPSeAKCf7Le7jndBue1pAYKedcBC4NjrzrQnUGF1bCBIb3dhcnRo +IDxwYXVsX2hvd2FydGhAeHlyYXRleC5jb20+iGQEMBECACUFAkU/MYEeHSBJIG5v +IGxvbmdlciB3b3JrIGZvciBYeXJhdGV4AAoJEHplks8WHAax0YAAmNklElyY3KuX +HKUQQ2x7CfIZzk8AoNrTx29F1Wb52z+zsgD/kAh/0JitiFwEExECABwFAj6WbmoC +GwMECwcDAgMVAgMDFgIBAh4BAheAAAoJEHplks8WHAaxykkAoLZxrDi5nPQdGXFn +38Q7zViViWbEAJ9QxIRPxECd/PgC26LYhLw2aN+tNLQdUGF1bCBIb3dhcnRoIDxw +YXVsQHB4LnVrLmNvbT6IRgQQEQIABgUCO7wwJgAKCRDgvmnJtWqLrH6jAJ0bF8es +u7M1pdU5AFPKkP6F5YA6pgCggX/wR5UgsM8WmRyaVC0AB54nTp2ISwQQEQIACwUC +NCwzuAQLAwECAAoJEHplks8WHAaxQRIAnA8dUSRA0ylKGNHdsjhzjJcPbij4AKCx +EnoFxZxNL3fjgje4aObjgxIGFIhOBBARAgAOBQI7vDE4BAsDAQICGQEACgkQemWS +zxYcBrGlWQCggWEMBk0iBFnt4cDoOuJY3ZAi04sAn1ssGGwZsVG9jEUP2VfcpPvo +cVbKiE4EEBECAA4FAju8RKEECwMBAgIZAAAKCRB6ZZLPFhwGsfvLAJ9chzGi6iO+ +uY/85WM0hK/U9780SgCfaUndKMbmvJPXZO1v3A4f4+B2tMCIbQQwEQIALQUCPpZw +FCYdIEkgbm8gbG9uZ2VyIHdvcmsgZm9yIFBvd2VyIFggTGltaXRlZAAKCRB6ZZLP +FhwGsY0YAKCzNPyp30P1xpiJZgIRl0h870opSQCgoSfRi4tqGt1mlyRIGa/7uKWw +7h20I1BhdWwgSG93YXJ0aCA8cGF1bEBiYWRieS51LW5ldC5jb20+iD8DBRA0Ku+O +ABW0pKpY0ccRAgrQAKCpF564MUn7HK/lqK2ISTnQGbcrdwCfc0uFZsj+YjwTnWnr +DaivRg0+2GKIPwMFEDTkWaomOWfdMj+qAhECo/0AnjNrGNFkAS9mMnBVwTR5D45C +SWIJAJ9l+Y9IqZBf8wTpDPHtJF/hY+leXohGBBARAgAGBQI7vDAhAAoJEOC+acm1 +aousdbMAoIH/kswOufRM/zOcAciXghC6NHZMAKCJ9j68YEs68FJPU2dNDyVgk0Ay +uYhLBBARAgALBQI0Kt8jBAsDAQIACgkQemWSzxYcBrH3BgCg7BXf01OuZN/N4bSx +Iv5xVgyMtI0AoOBztF6GBvC30Gd1tVOG22bmynyAiGwEMBECAC0FAj6WcBomHSBJ +IG5vIGxvbmdlciB3b3JrIGZvciBQb3dlciBYIExpbWl0ZWQACgkQemWSzxYcBrEq +3QCXe7Z1MG0zVJcEOhJtEHoexnu8+wCeLuqwlkkh+gt07qYSFY3K71SUwrO0J1Bh +dWwgSG93YXJ0aCA8cGF1bEBwb3dlci14LmRlbW9uLmNvLnVrPohLBBARAgALBQI0 +LDPhBAsDAQIACgkQemWSzxYcBrHl1wCfUL+qGt0jAKo931FhshVaL3h01VkAnjih +r0l8RtMOm36bYGo0dXppF/qEiGIEMBECACIFAju8VT4bHSBBZGRyZXNzIG5vIGxv +bmdlciBpbiB1c2UuAAoJEHplks8WHAaxApoAoJgTlcWKxbj4nthy8PWi44Q2OWWV +AJ0chniYjAS2twP5TD6Oauw2zGhcRLQuUGF1bCBIb3dhcnRoIDxwYXVsLmhvd2Fy +dGhAcG93ZXJ4bmV0d29ya3MuY29tPohGBBARAgAGBQI7vDFrAAoJEHplks8WHAax +dBAAnR2A6paz9ipeEJXjeV5gG9Lxum1aAKDiNXO59trc71qMTIgMGxMWwKxyNohG +BBARAgAGBQI7vFZWAAoJEOC+acm1aousAvwAnjOWlfaEmaXtd6DDlEydbmNdE5XQ +AJ48C3Uwh52TbGD2e0fJ2qq0N3YZu4htBDARAgAtBQI+lnAeJh0gSSBubyBsb25n +ZXIgd29yayBmb3IgUG93ZXIgWCBMaW1pdGVkAAoJEHplks8WHAax448An2VbMj9W +2ZK8HQo0nLdwL2NvAqqTAJ94pxZwSZrBgZVF/oZUF2JC8benErQpUGF1bCBIb3dh +cnRoIDxwYXVsX2hvd2FydGhAdmlydGVuc3lzLmNvbT6IYAQTEQIAIAUCRT8xxgIb +AwYLCQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJEHplks8WHAaxQCMAoJFZLvN61Tgc +s2eS0uF6/qDIxNj2AKC8g8B07FkVK+0v2emTIH2GDqx5urkCDQQ0Kt8jEAgA9kJX +twh/CBdyorrWqULzBej5UxE5T7bxbrlLOCDaAadWoxTpj0BV89AHxstDqZSt90xk +hkn4DIO9ZekX1KHTUPj1WV/cdlJPPT2N286Z4VeSWc39uK50T8X8dryDxUcwYc58 +yWb/Ffm7/ZFexwGq01uejaClcjrUGvC/RgBYK+X0iP1YTknbzSC0neSRBzZrM2w4 +DUUdD3yIsxx8Wy2O9vPJI8BD8KVbGI2Ou1WMuF040zT9fBdXQ6MdGGzeMyEstSr/ +POGxKUAYEY18hKcKctaGxAMZyAcpesqVDNmWn6vQClCbAkbTCD1mpF1Bn5x8vYlL +IhkmuquiXsNV6TILOwACAgf7Bwe65KQhXUW87GyRuJIDCwfUy+NqO24Us1SChlrL +DHfWPtYEtUHYwUOmVt09ZbaVkztUdYHOzksayyJ1XhW8xEWa8h52HYMEaPCedg5N +8Eg3DG/fpBeM1RR/NO41Zq/ZgHlY//JluyLghY5HsXeyIJ91zU/txQpYWKk5dSmc +m2J5aykh+8f1+bY6wmzhkhNgEiI9uDZtMuWsFAiP6+D3X+3ETRTB+uJvYiXn39L5 +lzn4kpD4pDsBbxPajBKDYt/lkymt+h6v/toLIPwMPZ/3pDZyNKJ4h0C2MmZUSljU +e4PZfjCk6+V6GqR4XDCz7VRqoypi4oqaSeMt4yzeaUmAYYg/AwUYNCrfI3plks8W +HAaxEQJIgACcClwpW0SA4lA7FO8c2SxOQHuVKxsAn0Sb7/HDpCrcuRKMUeT2xitA +EdfI +=8A2Q +-END PGP PUBLIC KEY BLOCK- diff --git a/perl-Math-GMP-2.06-stopwords.patch
[perl-Math-GMP] Created tag perl-Math-GMP-2.06-5.el6
The lightweight tag 'perl-Math-GMP-2.06-5.el6' was created pointing to: cc82cc2... Use hunspell dictionary for spell check test -- 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 Moose-1.12.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Moose: bc84d50ea36942693a29b16eb1e7bc36 Moose-1.12.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
[perl-Net-SSH-Perl] Created tag perl-Net-SSH-Perl-1.34-9.el6
The lightweight tag 'perl-Net-SSH-Perl-1.34-9.el6' was created pointing to: dee0b34... Use hunspell back-end for spell check test -- 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 631391] FTBFS perl-GD-2.44-4.fc14
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=631391 Emmanuel Seyman emmanuel.sey...@club-internet.fr changed: What|Removed |Added Status|NEW |CLOSED CC||emmanuel.sey...@club-intern ||et.fr Resolution||RAWHIDE Last Closed||2010-11-13 14:20:01 --- Comment #7 from Emmanuel Seyman emmanuel.sey...@club-internet.fr 2010-11-13 14:20:01 EST --- Fixed in rawhide, apparently. http://koji.fedoraproject.org/koji/taskinfo?taskID=2599212 -- 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
[Bug 649418] perl-Lingua-EN-Tagger-debuginfo is empty
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=649418 --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2010-11-13 16:59:59 EST --- perl-Lingua-EN-Tagger-0.16-4.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. -- 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
[Bug 649418] perl-Lingua-EN-Tagger-debuginfo is empty
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=649418 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Lingua-EN-Tagger-0.16- ||4.fc14 Resolution||ERRATA Last Closed||2010-11-13 17:00:04 -- 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
[Bug 649418] perl-Lingua-EN-Tagger-debuginfo is empty
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=649418 --- Comment #5 from Fedora Update System upda...@fedoraproject.org 2010-11-13 17:04:36 EST --- perl-Lingua-EN-Tagger-0.16-4.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report. -- 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
[Bug 649418] perl-Lingua-EN-Tagger-debuginfo is empty
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=649418 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-Lingua-EN-Tagger-0.16- |perl-Lingua-EN-Tagger-0.16- |4.fc14 |4.fc13 -- 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
