Re: New maintainer for lirc/Jarod Wilson's packages
On Thu, Oct 10, 2013 at 03:12:51PM +0200, Alec Leamas wrote: I've been wating a little for raveit to respond, but none so far. Since I actually have spent some time on this already, I can take this package if it's OK with everyone. It looks like Jarod orphaned all of his packages, so you can pick lirc up now: https://admin.fedoraproject.org/pkgdb/acls/name/lirc Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New maintainer for lirc/Jarod Wilson's packages
On Tue, Oct 01, 2013 at 07:50:45PM +0200, Till Maas wrote: cx18-firmware -- Firmware for Conexant cx23418-based video capture devices libcrystalhd -- Broadcom Crystal HD device interface library lirc -- The Linux Infrared Remote Control package rinputd -- A server for receiving input events over the network wacomexpresskeys -- Wacom ExpressKeys and Touch Strips configuration utility The packages are now orphaned, so please pick them up. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New maintainer for lirc/Jarod Wilson's packages
On 10/12/2013 09:55 AM, Till Maas wrote: [cut] The packages are now orphaned, so please pick them up. Regards Till I have picked lirc. --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: boost141 and stability of Boost API?
Date: Sun, 6 Oct 2013 21:03:36 -0700 From: Dave Johansen davejohan...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Subject: Re: boost141 and stability of Boost API? Message-ID: CAAcYxUd9ng9_Q2m=WpA= wyne8tgs4m-zr8cc1hs45bg9pmn...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 On Sat, Oct 5, 2013 at 2:12 PM, Denis Arnaud denis.arnaud_fed...@m4x.org wrote: Hi Dave, note that Boost-1.48 has been packaged for EPEL 5 and 6, but not yet approved: http://bugzilla.redhat.com/show_bug.cgi?id=921134 In case it is useful to anyone, do not hesitate to approve it :) And if there is more love, we could even embark on the way to package Boost-1.54 for EPEL... But that is another story. That's good to hear because it's always good to have options, but newer versions just bring up the question of a moving target. Just like how you mentioned 1.54, if we're shooting for newer versions, then why not go with that one, or 1.55 after it? The point of RHEL is a stable platform and development environment and chasing the newest version of a library (especially one as volatile as Boost) just doesn't seem to fit the RHEL mentality. Note that those packages (boost141, boost148) are intended only for EPEL, IN ADDITION to the version officially supported by RedHat (Boost-1.31 on RHEL 5 and Boost-1.41 on RHEL 6). On Fedora, we strive to deliver the latest possible version of Boost every six months, not in between. Hence, EPEL packagers have the choice of the version of Boost they build upon, and are not forced to perform complex patch retrofits for their own packages (having dependencies on Boost). That does not impact AT ALL the EPEL packages built on top of the officially supported version of Boost. Kind regards Denis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New maintainer for lirc/Jarod Wilson's packages
On 10/12/2013 09:55 AM, Till Maas wrote:
On Tue, Oct 01, 2013 at 07:50:45PM +0200, Till Maas wrote:
cx18-firmware -- Firmware for Conexant cx23418-based video capture
devices
libcrystalhd -- Broadcom Crystal HD device interface library
lirc -- The Linux Infrared Remote Control package
rinputd -- A server for receiving input events over the network
wacomexpresskeys -- Wacom ExpressKeys and Touch Strips configuration
utility
The packages are now orphaned, so please pick them up.
Regards
Till
I have built a new release 15 which is available shortly in
updates-testing for f19 (not rawhide ATM). This is *huge* update, and
although many things hopefully are resolved chances are quite high for
new bugs. Please, test this package and give some karma. Without
feedback I'll really hesitate to push it, for sure.
--alec
BTW: If someone wants to see in detail what's done the best bet is the
commit log at https://github.com/leamas/lirc-pkg. Otherwise, here is the
changelog:
%changelog
* Thu Oct 10 2013 Alec Leamas leamas.a...@nowhere.net - 0.9.0-15
- Actually use sysconfig files (881976)
- Modify lirc.service to not fork.
- Add support for iguanaIR driver (#954146).
- Add hardened build flag (955144).
- Use actual systemd macros (850191).
- Clean up some nowadays not used directives.
- Run autoreconf by default (926082).
- Cleanup some obsoleted autotools usage, two new patches.
- Deactivate other decoders on start (923978).
- Filter away docdir dependencies.
- Remove obsolete F8 upgrade Obsoletes: (sic!).
- Fix inconsistent/duplicate /usr/share/lirc in %%files.
- Add %%doc (notably COPYING) to remotes subpackage.
- Claim /etc/lirc.
- Update to latest upstream (10 patches).
- Use /var and /etc instead of %%{_sysconfdir} and %%{localstatedir}.
- Removed obsolete code to move config files to /etc/lirc in %%post.
- Renamed main systemd service: lirc.service - lircd.service.
- Added socket activation support.
- Don't claim temporary files in /run/lirc, they are just transient.
- Initiate lircd.conf, lircmd.conf from external template.
- Bumping release, 14 is published.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Yum dependency resolving remove_leaf_only
Hello It is an often experience that I try to remove a package(ex: bluez, kernel, gnome-bluetooth) and yum(8) prompts me to remove nearly 200-300MB worth of critical packages, which has no connection(ex. kernel = Xchat OR bluez = gedit etc.) with the package I want to remove. Recently I was told to set remove_leaf_only=1 in yum.conf, which should help remove only the leaf node packages and nothing else. So I set it. But after setting remove_leaf_only=1, I can remove _none_ of the packages because of the dependency issues. Even when I try to remove _all_ of the dependency packages I'm barely allowed to remove but a single package. (see below) I wonder why is this so? Is this an error in the way packages are built OR isit yum(8)'s dependency resolving algorithm that is broken? I've also seen instances wherein yum installs _new_ package during yum update. All this does not seem good at all. Many of the folks, with whom I've argued for Fedora, cite yum(8) to be the foremost reason for not liking Fedora. Does the new DNF(https://fedoraproject.org/wiki/Features/DNF) plans to address these issues? Till then is there a known remedy for yum(8)'s illness?? === [~ @ 21:44]# yum remove bluez Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies -- Running transaction check --- Package bluez.x86_64 0:4.101-9.fc19 will be erased --- Keeping package: bluez-4.101-9.fc19.x86_64 due to pulseaudio-module-bluetooth-3.0-10.fc19.x86_64 -- Finished Dependency Resolution [~ @ 21:45]# [~ @ 21:46]# yum remove pulseaudio-module-bluetooth Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies -- Running transaction check --- Package pulseaudio-module-bluetooth.x86_64 0:3.0-10.fc19 will be erased --- Keeping package: pulseaudio-module-bluetooth-3.0-10.fc19.x86_64 due to 1:gnome-bluetooth-3.8.2.1-1.fc19.x86_64 -- Finished Dependency Resolution [~ @ 21:46]# [~ @ 21:46]# yum remove gnome-bluetooth Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies -- Running transaction check --- Package gnome-bluetooth.x86_64 1:3.8.2.1-1.fc19 will be erased --- Keeping package: 1:gnome-bluetooth-3.8.2.1-1.fc19.x86_64 due to bluez-4.101-9.fc19.x86_64 -- Finished Dependency Resolution [~ @ 21:46]# [~ @ 21:46]# yum remove gnome-bluetooth bluez pulseaudio-module-bluetooth Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies -- Running transaction check --- Package bluez.x86_64 0:4.101-9.fc19 will be erased --- Package gnome-bluetooth.x86_64 1:3.8.2.1-1.fc19 will be erased --- Keeping package: 1:gnome-bluetooth-3.8.2.1-1.fc19.x86_64 due to gnome-shell-3.8.4-2.fc19.x86_64 --- Package pulseaudio-module-bluetooth.x86_64 0:3.0-10.fc19 will be erased --- Keeping package: pulseaudio-module-bluetooth-3.0-10.fc19.x86_64 due to 1:gnome-bluetooth-3.8.2.1-1.fc19.x86_64 -- Finished Dependency Resolution Dependencies Resolved === Package Arch Version Repository Size === Removing: bluez x86_64 4.101-9.fc19 @updates 1.9 M Transaction Summary === Remove 1 Package Installed size: 1.9 M Is this ok [y/N]: N === Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
On Saturday, 12 October 2013 10:19 PM, Reindl Harald h.rei...@thelounge.net wrote: that's why i get that mad if packagers careless add new deps because they enable whatever function in a package instead split the new ones in additional subpackages I see. If it is a packaging error, how does DNF plan to address it? on a tiny setup one small added dependency often pulls *a lot* of other dependencies the user did not use and install for good reasons like keep the footprint small and make dist-upgrades fast True, couldn't agree more. I too strive to install the bare minimum required packages, but invariably I lose after the first $ yum update post system install. :( --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
On 10/12/2013 09:42 AM, P J P wrote: === Package Arch Version Repository Size === Removing: bluezx86_644.101-9.fc19 @updates1.9 M Transaction Summary === Remove 1 Package Installed size: 1.9 M Is this ok [y/N]: N === If there's a bug, then this is it. You should not be able to remove bluez because there are dependencies on it. Somehow, the combination of options you've used confused yum. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
On Saturday, 12 October 2013 10:31 PM, Samuel Sieb sam...@sieb.net wrote: If there's a bug, then this is it. You should not be able to remove bluez because there are dependencies on it. Well, remove_leaf_only=1 restricts dependency resolution to the leaf nodes only, that is why it allows removing bluez. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
On 10/12/2013 10:11 AM, P J P wrote: On Saturday, 12 October 2013 10:31 PM, Samuel Sieb sam...@sieb.net wrote: If there's a bug, then this is it. You should not be able to remove bluez because there are dependencies on it. Well, remove_leaf_only=1 restricts dependency resolution to the leaf nodes only, that is why it allows removing bluez. Seems like a really dangerous option then. If you actually went ahead with that removal then you're probably going to get yum errors every time you use it now. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
On Saturday, 12 October 2013 10:43 PM, Reindl Harald h.rei...@thelounge.net wrote: *why* should it be addressed in yum or DNF? if a package pulls un-needed dependencies the package has to be fixed and *not* worked around it - period Yes, agreed. But that might probably involve fixing the package review process wherein a new package is introduced. Once the package is approved and enters repositories, subsequent updates could introduce new dependencies. These updates do not go through any manual review process. Spotting dependency errors by inspecting the .spec file seems like quite a task, at least it's difficult to spot without manual inspection. One solution could be for Yum(8) or DNF to only list the dependency packages to caution a user that if you remove the said package, these many packages would be affected. But prompt him to remove only the selected package and not 100 others along with it. Ie. If I ask to remove package bluez, do let me know that 100 other packages might not work, but prompt me to remove only and only package bluez and not the 100 other affected packages. This would significantly simplify user's decision making and thus improve user experience too. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fonts rendering and hinting
Dridi Boukelmoune wrote: My guesses: - there are other legal issues - interested parties missed/forgot it - interested parties are working on it It's the first option. Both freetype and freetype-freeworld now include the bytecode interpreter, which is indeed no longer patented (so the blog post is incorrect when it claims the bytecode interpreter is only in freetype- freeworld!), but subpixel rendering is still patented and thus only available in freetype-freeworld. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
On Saturday, 12 October 2013 11:23 PM, Reindl Harald h.rei...@thelounge.net wrote: if you want get a feeling in waht these ends type the follwoing as root after you prepeared a rescue-disc because not rpm, nor yum nor even sshd will work any longer and you need to copy the package files by hand to their location - have fun, tried it in a VM rpm -e --nodeps nss-softokn-freebl Well, with --nodeps you already allow rpm to remove a package without knowing which other packages it might affect. I tried it with yum(8) instead, after resolving a huge list of dependencies possibly involving _every_ installed package it could find, including libc.so.6 systemd, finally yum refused to remove it. That is smart. === [~ @ 23:30]# yum remove nss-softokn-freebl ... -- Running transaction check --- Package foomatic-db.noarch 0:4.0-38.20130604.fc19 will be erased --- Package icc-profiles-basiccolor-printing2009.noarch 0:1.2.0-3.fc19 will be erased --- Package kernel-modules-extra.x86_64 0:3.11.3-201.fc19 will be erased -- Finished Dependency Resolution Error: Trying to remove systemd, which is protected Error: Trying to remove yum, which is protected === Yum(8) already has some intelligence built into it to protect a naive user from possible disasters. Considering that, it is okay to let user remove other packages at will. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
On Sun, Oct 13, 2013 at 00:42:43 +0800, P J P pj.pan...@yahoo.co.in wrote: It is an often experience that I try to remove a package(ex: bluez, kernel, gnome-bluetooth) and yum(8) prompts me to remove nearly 200-300MB worth of critical packages, which has no connection(ex. kernel = Xchat OR bluez = gedit etc.) with the package I want to remove. Recently I was told to set remove_leaf_only=1 in yum.conf, which should help remove only the leaf node packages and nothing else. So I set it. The connection may not be obvious to you, but it's there. You shouldn't ever remove kernel. You may want to remove a specific kernel (that you are't currently running), but then you need to include a version number. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
On Sunday, 13 October 2013 12:04 AM, Reindl Harald h.rei...@thelounge.net wrote: and your list possible affected packages but allow me to remove ends *exactly* there No, it does not. If yum is protecting users from un-installing a package which could render the whole system unusable or unresponsive, what remains is not-so important packages, which pull in 100 other _unrelated_ packages to the list of packages to be removed. And invariably user is left with no choice but to type - 'N'; unable to remove a package. BTW: thank you for quoting out of context and no i am too lazy to search your Sorry, I quoted out of context? --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
On Sun, Oct 13, 2013 at 03:13:41 +0800, P J P pj.pan...@yahoo.co.in wrote: No, it does not. If yum is protecting users from un-installing a package which could render the whole system unusable or unresponsive, what remains is not-so important packages, which pull in 100 other _unrelated_ packages to the list of packages to be removed. And invariably user is left with no choice but to type - 'N'; unable to remove a package. They aren't unrelated. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
On Sunday, 13 October 2013 12:50 AM, Reindl Harald h.rei...@thelounge.net wrote: there is no if and but if a package has a dependency than it has one - period Sure, it has dependency. That does not make it an _absolutely_ requirement to have a functional system. Because the dependency relationship could be broken. We already agreed on that, no? Ex. I try to remove package bluez, and yum prompts me to remove gnome-shell, gthumb, xchat and several other unrelated useful packages. Does that mean gnome-shell, xchat gthumb can not function without package bluez? No. It means dependency relationship is broken. That is why it is okay to let user remove package 'bluez'. If it breaks something, user can still re-install bluez without much hassle _if when_ he/she figures out that things aren't working as expected. Otherwise it's good riddance, one unwanted package less. === [~ @ 01:00]# yum remove bluez Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies -- Running transaction check --- Package bluez.x86_64 0:4.101-9.fc19 will be erased -- Processing Dependency: bluez = 4.34 for package: pulseaudio-module-bluetooth-3.0-10.fc19.x86_64 -- Processing Dependency: bluez = 4.42 for package: 1:gnome-bluetooth-3.8.2.1-1.fc19.x86_64 -- Running transaction check --- Package gnome-bluetooth.x86_64 1:3.8.2.1-1.fc19 will be erased -- Processing Dependency: gnome-bluetooth(x86-64) = 3.5.5 for package: gnome-shell-3.8.4-2.fc19.x86_64 -- Processing Dependency: libgnome-bluetooth-applet.so.0()(64bit) for package: gnome-shell-3.8.4-2.fc19.x86_64 --- Package pulseaudio-module-bluetooth.x86_64 0:3.0-10.fc19 will be erased -- Running transaction check --- Package gnome-shell.x86_64 0:3.8.4-2.fc19 will be erased ... === I wonder why is gnome-bluetooth required by gnome-shell, it should be the other way round, no? there are no soft-depencencies and any hack allow you to remove a pakcage which is required by another one and ignore this requirement is pretty dumb Heh, and leaving users unable to remove unnecessary packages by prompting them to remove 100 unrelated useful packages is not dumb? --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
On Sun, Oct 13, 2013 at 04:00:58 +0800, P J P pj.pan...@yahoo.co.in wrote: Does that mean gnome-shell, xchat gthumb can not function without package bluez? No. It means dependency relationship is broken. In the eyes of the gnome developers the answer is no, it won't work properly without bluez. That's why there is a dependency. Perhaps someone could do some work to make gnome work reasonably without bluez and changes comps so that bluez would get installed by default with gnome. (So that it would work the same as now in most cases.) And the benefit of this is to save a small amount of disk space. Given that, most people are likely to consider this a low priority task compared to other things they could do to make Fedora better. If this is really important to you, you should consider engaging the gnome developers to see if there would be acceptible way to make change and what kinds of tasks would need to be done. Your example of removing kernel is even more esoteric. Fedora wouldn't work at all without it. There may be some reason one might have for wanting a bunch of Fedora packages installed without the kernel, but you aren't likely to find anyone interested in making a way to do that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
On Sunday, 13 October 2013 1:46 AM, Bruno Wolff III br...@wolff.to wrote: Your example of removing kernel is even more esoteric. Fedora wouldn't work at all without it. Well, kernel one works when there are multiple kernels installed. It happens when yum installs a new kernel update. Each kernel brings along its respective kernel-devel, kernel-header packages. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Sunday 13th of October: SSD cache test day
On https://fedoraproject.org/wiki/Test_Day:2013-10-13_SSD_Cache Note the set uuid and attach /dev/sdb1 to /dev/sda2: echo set uuid /sys/block/bcache0/bcache/attach Maybe that can be enhanced to say cset.uuid instead of just uuid / set uuid? (for which i confused it with dev.uuid shown by blkid, since i never used bcache before). cset.uuid can be obtained from the output of bcache-show-super. Cheers. On Fri, Oct 11, 2013 at 6:46 PM, Igor Gnatenko i.gnatenko.br...@gmail.com wrote: On Thu, 2013-10-10 at 00:02 +0200, Rolf Fokkens wrote: Hi All, The Fedora SSD Cache is this sunday October 13th 2013. This Fedora Test Day will focus on bcache based SSD Caching in Fedora 20. https://fedoraproject.org/wiki/Test_Day:2013-10-13_SSD_Cache If you're interested in trying out the new bcache SSD caching functionality step by step instructions are available for: - bcache on physical hardware - bcache in a virtual machine - non-root FS on bcache (with or without LVM) - root FS on bcache (wtih or without LVM) The objective of this Test day is to demonstrate a working Fedora 20 system using bcache. Te be more specific: * The system boots OK; after booting bcache is operating as expected * The system updates (yum update) OK. After updating specifically the kernel the system boots OK. * The system is bootable when the caching device is disabled. Although testing on real hardware is closest to the real thing, testing in a VM may also provide good insights on the proper working of bcache (except for performance). If you can't make the date of the test day, adding test case results to the wiki anytime next week is fine as well. Though if you do plan on showing up to the test day, please add your name to the participant list on the wiki, and when the day arrives, pop into #fedora-test-day on freenode and give us a shout! If you can't make the date of the test day, adding test case results to the wiki anytime next week is fine as well. Though if you do plan on showing up to the test day, add your name to the participant list on the wiki, and when the day arrives, pop into #fedora-test-day on freenode and give us a shout! The Wiki page is still under development, so expect some improvements before sunday. Thanks, Igor Gnatenko Rolf Fokkens Today I've updated wiki page. At test day will be Kent Overstreet (py1hon) which author of bcache. -- Igor Gnatenko Fedora release 20 (Heisenbug) Linux 3.11.4-301.fc20.x86_64 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
On Sun, Oct 13, 2013 at 04:53:48 +0800, P J P pj.pan...@yahoo.co.in wrote: On Sunday, 13 October 2013 1:46 AM, Bruno Wolff III br...@wolff.to wrote: Your example of removing kernel is even more esoteric. Fedora wouldn't work at all without it. Well, kernel one works when there are multiple kernels installed. It happens when yum installs a new kernel update. Each kernel brings along its respective kernel-devel, kernel-header packages. Not exactly, but yes the kernel is set up so that multiple versions can be installed at the same time. You still can't erase them all; you need to specify versions when you do an erase. There all also depencies on miminum versions of the kernel, because some things won't work correctly with older kernels. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
On Sunday, 13 October 2013 1:47 AM, Reindl Harald h.rei...@thelounge.net wrote: *bullshit* you have no clue what the result of a specific broken dependency would be nor have yum, dnf or even god Well, when no-one has a clue, assuming the worst is just _one_ way of doing things. says who? in case of bluez it maybe does not make troubles and the dependency should be bluez-libs and if a package links to /usr/lib64/libbluetooth.so.3 and yum would allow you to remove it the app would *crash* Heh..that is what broken dependency means. *yum and whatever package managmement* are *not* repsponsible for wrong dependencies and since there are no soft-dpendencies in RPM implemented the only thing which is broken is the package pull braindead cross-deps Yes, we already agreed on this. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Sunday 13th of October: SSD cache test day
On 10/12/2013 10:58 PM, Reartes Guillermo wrote: Maybe that can be enhanced to say cset.uuid instead of just uuid / set uuid? (for which i confused it with dev.uuid shown by blkid, since i never used bcache before). cset.uuid can be obtained from the output of bcache-show-super. Cheers. Thanks, I updated the text! Rolf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Software management: Call for RFEs results!
On 04.10.2013 15:34, Jan Zelený wrote: If you have any other questions, comments or notes regarding the document, feel free to to use this list for the discussion. Where (list threads, wikis, sources) one should seek more details about the DB aspects of the plan, e.g.: * A1: Delta metadata in yum and dnf (format, replication mechanism) * B1-4: New format of rpmdb (db engine, schema, relation with the future yum/dnf db) Thanks, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
Am 12.10.2013 20:16, schrieb P J P: On Saturday, 12 October 2013 11:23 PM, Reindl Harald h.rei...@thelounge.net wrote: if you want get a feeling in what these ends type the follwoing as root after you prepeared a rescue-disc because not rpm, nor yum nor even sshd will work any longer and you need to copy the package files by hand to their location - have fun, tried it in a VM rpm -e --nodeps nss-softokn-freebl Well, with --nodeps you already allow rpm to remove a package without knowing which other packages it might affect and your list possible affected packages but allow me to remove ends *exactly* there BTW: thank you for quoting out of context and no i am too lazy to search your original quote, anybody whichg is interested in context may follow the whole thread signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
Am 12.10.2013 19:00, schrieb P J P: On Saturday, 12 October 2013 10:19 PM, Reindl Harald h.rei...@thelounge.net wrote: that's why i get that mad if packagers careless add new deps because they enable whatever function in a package instead split the new ones in additional subpackages I see. If it is a packaging error, how does DNF plan to address it? *why* should it be addressed in yum or DNF? if a package pulls un-needed dependencies the package has to be fixed and *not* worked around it - period signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
Am 12.10.2013 21:13, schrieb P J P: On Sunday, 13 October 2013 12:04 AM, Reindl Harald h.rei...@thelounge.net wrote: and your list possible affected packages but allow me to remove ends *exactly* there No, it does not. If yum is protecting users from un-installing a package which could render the whole system unusable or unresponsive, what remains is not-so important packages, which pull in 100 other _unrelated_ packages to the list of packages to be removed. And invariably user is left with no choice but to type - 'N'; unable to remove a package yum install yum-plugin-protectbase adn core-packages like yum/rpm/kernel are no longer removed by accident - but that does and *can not* reslove what you want there is no if and but if a package has a dependency than it has one - period there are no soft-depencencies and any hack allow you to remove a pakcage which is required by another one and ignore this requirement is pretty dumb signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
Am 12.10.2013 19:34, schrieb P J P: On Saturday, 12 October 2013 10:43 PM, Reindl Harald h.rei...@thelounge.net wrote: *why* should it be addressed in yum or DNF? if a package pulls un-needed dependencies the package has to be fixed and *not* worked around it - period Yes, agreed. But that might probably involve fixing the package review process wherein a new package is introduced. Once the package is approved and enters repositories, subsequent updates could introduce new dependencies. These updates do not go through any manual review process. and yum/dnf on the users end can't change anything here the manual review most likely also because if you compile with a additional --with-whatever flag you may introduce a dependency not visible in the SPEC nor on many machines which may have installed it already for other reasons this could only be done on the infrastructure by verify the implicit and explicit Requires against the previous build and supsend push the package until a manual review Ie. If I ask to remove package bluez, do let me know that 100 other packages might not work, but prompt me to remove only and only package bluez and not the 100 other affected packages. This would significantly simplify user's decision making and thus improve user experience too. if you understand how modern software with shared libraries is working you won't come to this idea - you have finally no clue which libraries and core components are broken by doing so and there is a good chance that you break the whole setup if you want get a feeling in waht these ends type the follwoing as root after you prepeared a rescue-disc because not rpm, nor yum nor even sshd will work any longer and you need to copy the package files by hand to their location - have fun, tried it in a VM rpm -e --nodeps nss-softokn-freebl signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
Am 12.10.2013 18:42, schrieb P J P: It is an often experience that I try to remove a package(ex: bluez, kernel, gnome-bluetooth) and yum(8) prompts me to remove nearly 200-300MB worth of critical packages, which has no connection(ex. kernel = Xchat OR bluez = gedit etc.) with the package I want to remove. Recently I was told to set remove_leaf_only=1 in yum.conf, which should help remove only the leaf node packages and nothing else. So I set it. But after setting remove_leaf_only=1, I can remove _none_ of the packages because of the dependency issues. Even when I try to remove _all_ of the dependency packages I'm barely allowed to remove but a single package. (see below) I wonder why is this so? Is this an error in the way packages are built OR isit yum(8)'s dependency resolving algorithm that is broken? I've also seen instances wherein yum installs _new_ package during yum update. All this does not seem good at all. Many of the folks, with whom I've argued for Fedora, cite yum(8) to be the foremost reason for not liking Fedora. dependency chains * many packages depend on others * they are depend on others too * they are depend on libraries * you want to remove something which provides required libraries/binaries that's why i get that mad if packagers careless add new deps because they enable whatever function in a package instead split the new ones in additional subpackages on a tiny setup one small added dependency often pulls *a lot* of other dependencies the user did not use and install for good reasons like keep the footprint small and make dist-upgrades fast signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
Am 12.10.2013 20:20, schrieb Bruno Wolff III: On Sun, Oct 13, 2013 at 00:42:43 +0800, P J P pj.pan...@yahoo.co.in wrote: It is an often experience that I try to remove a package(ex: bluez, kernel, gnome-bluetooth) and yum(8) prompts me to remove nearly 200-300MB worth of critical packages, which has no connection(ex. kernel = Xchat OR bluez = gedit etc.) with the package I want to remove. Recently I was told to set remove_leaf_only=1 in yum.conf, which should help remove only the leaf node packages and nothing else. So I set it. The connection may not be obvious to you, but it's there. You shouldn't ever remove kernel. You may want to remove a specific kernel (that you are't currently running), but then you need to include a version number. wrong yum remove kernel is uninstalling any *not running* kernel and if someone has not messed up his installation will never remove any ther package more true is that yum remove kernel is the way to go if you increased the amount of kernel-versions to preserve and want get rid of them all at once and keep only the running signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
Am 12.10.2013 22:00, schrieb P J P: On Sunday, 13 October 2013 12:50 AM, Reindl Harald h.rei...@thelounge.net wrote: there is no if and but if a package has a dependency than it has one - period Sure, it has dependency. That does not make it an _absolutely_ requirement to have a functional system. *bullshit* you have no clue what the result of a specific broken dependency would be nor have yum, dnf or even god Because the dependency relationship could be broken. We already agreed on that, no? *fix the package* and *not* the messenger Ex. I try to remove package bluez, and yum prompts me to remove gnome-shell, gthumb, xchat and several other unrelated useful packages. *fix the package* and *not* the messenger Does that mean gnome-shell, xchat gthumb can not function without package bluez? most likely in case they call libraries No says who? in case of bluez it maybe does not make troubles and the dependency should be bluez-libs and if a package links to /usr/lib64/libbluetooth.so.3 and yum would allow you to remove it the app would *crash* It means dependency relationship is broken there are no soft dependencies in RPM the whole topic is useless and misguided *yum and whatever package managmement* are *not* repsponsible for wrong dependencies and since there are no soft-dpendencies in RPM implemented the only thing which is broken is the package pull braindead cross-deps signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
Am 12.10.2013 22:00, schrieb P J P: That is why it is okay to let user remove package 'bluez' [harry@srv-rhsoft:~]$ rpm -qa | grep bluez bluez-libs-4.101-9.fc19.x86_64 [harry@srv-rhsoft:~]$ as you can see yum or dnf *are not* responsible ask gnome-upstream why they are too stupid to run without bluez while KDE proves there can be a desktop environment not doing so and so please realize that the whole thread including it's subject is worthless signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
Am 12.10.2013 22:53, schrieb P J P: On Sunday, 13 October 2013 1:46 AM, Bruno Wolff III br...@wolff.to wrote: Your example of removing kernel is even more esoteric. Fedora wouldn't work at all without it. Well, kernel one works when there are multiple kernels installed. It happens when yum installs a new kernel update. Each kernel brings along its respective kernel-devel, kernel-header packages. the kernel is a *special* package, however kernel-header is updated like any other package and only installed in *one* version, only kernel and kernel-devel are in context of installonly_limit may i suggest that you learn basics about dependencies, how linking works and how dependencies for packages are generated respecting the linking before you start the next time such a thread? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Yum dependency resolving remove_leaf_only
Am 12.10.2013 23:32, schrieb P J P: On Sunday, 13 October 2013 1:47 AM, Reindl Harald h.rei...@thelounge.net wrote: *bullshit* you have no clue what the result of a specific broken dependency would be nor have yum, dnf or even god Well, when no-one has a clue, assuming the worst is just _one_ way of doing things. no it's the best instead having unpredictable behavior all over the distribution says who? in case of bluez it maybe does not make troubles and the dependency should be bluez-libs and if a package links to /usr/lib64/libbluetooth.so.3 and yum would allow you to remove it the app would *crash* Heh..that is what broken dependency means and why do you want yum/dnf to allow this? *yum and whatever package managmement* are *not* repsponsible for wrong dependencies and since there are no soft-dpendencies in RPM implemented the only thing which is broken is the package pull braindead cross-deps Yes, we already agreed on this so *what* is your topic about? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Math-NumSeq] New version 65 (#1016246)
commit 92d66ff68e74264c9407b512205d1b444d831e3c
Author: Miro Hrončok m...@hroncok.cz
Date: Sat Oct 12 12:41:45 2013 +0200
New version 65 (#1016246)
.gitignore|1 +
perl-Math-NumSeq.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 1072efd..81669ae 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
/Math-NumSeq-62.tar.gz
/Math-NumSeq-63.tar.gz
/Math-NumSeq-64.tar.gz
+/Math-NumSeq-65.tar.gz
diff --git a/perl-Math-NumSeq.spec b/perl-Math-NumSeq.spec
index a18b748..936b8f5 100644
--- a/perl-Math-NumSeq.spec
+++ b/perl-Math-NumSeq.spec
@@ -1,5 +1,5 @@
Name: perl-Math-NumSeq
-Version:64
+Version:65
Release:1%{?dist}
Summary:Number sequences
License:GPLv3+
@@ -96,6 +96,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Sat Oct 12 2013 Miro Hrončok mhron...@redhat.com - 65-1
+- New version 65 (#1016246)
+
* Tue Sep 17 2013 Miro Hrončok mhron...@redhat.com - 64-1
- New version 64 (#1008403)
diff --git a/sources b/sources
index cf77cf6..3edbbca 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a1b7833d5da6381b1ee1ce5158e19ebf Math-NumSeq-64.tar.gz
+5a5383d88e6b8fe9b1186897d6169c74 Math-NumSeq-65.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-Math-NumSeq/f20] New version 65 (#1016246)
Summary of changes: 92d66ff... New version 65 (#1016246) (*) (*) 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-Math-NumSeq/f18] New version 65 (#1016246)
Summary of changes: 92d66ff... New version 65 (#1016246) (*) (*) 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-Math-NumSeq/f19] New version 65 (#1016246)
Summary of changes: 92d66ff... New version 65 (#1016246) (*) (*) 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
[Bug 1018334] Please build for EPEL-6
https://bugzilla.redhat.com/show_bug.cgi?id=1018334 --- Comment #3 from Alec Leamas leamas.a...@gmail.com --- Done: https://bugzilla.redhat.com/show_bug.cgi?id=794988#c15 @Paul: thanks! -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=tZpXK9WQcqa=cc_unsubscribe -- 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
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the F-20 tree: On x86_64: perl-PDL-2.4.10-6.fc19.x86_64 requires perl(:MODULE_COMPAT_5.16.2) perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit) On i386: perl-PDL-2.4.10-6.fc19.i686 requires perl(:MODULE_COMPAT_5.16.2) perl-PDL-2.4.10-6.fc19.i686 requires libgd.so.2 Please resolve this as soon as possible. -- 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
Broken dependencies: slic3r
slic3r has broken dependencies in the F-20 tree: On x86_64: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On i386: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On armhfp: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-MIME-Lite-HTML
perl-MIME-Lite-HTML has broken dependencies in the F-20 tree: On x86_64: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- 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 1016246] perl-Math-NumSeq-65 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1016246 --- Comment #1 from Fedora Update System upda...@fedoraproject.org --- perl-Math-NumSeq-65-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-Math-NumSeq-65-1.fc20 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=m7kcDeKXv1a=cc_unsubscribe -- 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
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the F-20 tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-MooseX-TrackDirty-Attributes
perl-MooseX-TrackDirty-Attributes has broken dependencies in the F-20 tree: On x86_64: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Padre
perl-Padre has broken dependencies in the F-20 tree: On x86_64: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- 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 1016246] perl-Math-NumSeq-65 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1016246 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-Math-NumSeq-65-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-Math-NumSeq-65-1.fc19 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=vPT2HEDOPEa=cc_unsubscribe -- 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
Broken dependencies: perl-MIME-Lite-HTML
perl-MIME-Lite-HTML has broken dependencies in the rawhide tree: On x86_64: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-MIME-Lite-HTML-1.24-4.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Padre
perl-Padre has broken dependencies in the rawhide tree: On x86_64: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On i386: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) On armhfp: perl-Padre-0.90-6.fc18.noarch requires perl(:MODULE_COMPAT_5.16.0) Please resolve this as soon as possible. -- 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
Broken dependencies: slic3r
slic3r has broken dependencies in the rawhide tree: On x86_64: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On i386: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) On armhfp: slic3r-0.9.10b-2.fc20.noarch requires perl(:MODULE_COMPAT_5.16.3) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-MooseX-TrackDirty-Attributes
perl-MooseX-TrackDirty-Attributes has broken dependencies in the rawhide tree: On x86_64: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-MooseX-TrackDirty-Attributes-2.002-2.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the rawhide tree: On x86_64: perl-PDL-2.4.10-6.fc19.x86_64 requires perl(:MODULE_COMPAT_5.16.2) perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit) On i386: perl-PDL-2.4.10-6.fc19.i686 requires perl(:MODULE_COMPAT_5.16.2) perl-PDL-2.4.10-6.fc19.i686 requires libgd.so.2 Please resolve this as soon as possible. -- 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 Test-Simple-0.99.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Test-Simple: 0ff8a222d0c0be5a2ada2881a053e2b1 Test-Simple-0.99.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-Test-Simple] Update to 0.99
commit 752e31006bf3feb5a6d832f5f6c493359bd34c79
Author: Paul Howarth p...@city-fan.org
Date: Sat Oct 12 20:40:11 2013 +0100
Update to 0.99
- 0.99 bump
- This release by RJBS - update source URL
.gitignore|5 +
perl-Test-Simple.spec | 10 +++---
sources |2 +-
3 files changed, 9 insertions(+), 8 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index ad329f5..1a09d80 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,4 +1 @@
-Test-Simple-0.94.tar.gz
-/Test-Simple-0.96.tar.gz
-/Test-Simple-0.98.tar.gz
-/Test-Simple-0.98_05.tar.gz
+/Test-Simple-[0-9._]*.tar.gz
diff --git a/perl-Test-Simple.spec b/perl-Test-Simple.spec
index 18e01f5..fc64316 100644
--- a/perl-Test-Simple.spec
+++ b/perl-Test-Simple.spec
@@ -1,12 +1,12 @@
-%global cpan_version 0.98_05
+%global cpan_version 0.99
Name: perl-Test-Simple
Summary:Basic utilities for writing tests
Version:%(echo '%{cpan_version}' | tr _ .)
-Release:3%{?dist}
+Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Test-Simple
-Source0:
http://search.cpan.org/CPAN/authors/id/M/MS/MSCHWERN/Test-Simple-%{cpan_version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/R/RJ/RJBS/Test-Simple-%{cpan_version}.tar.gz
# https://github.com/schwern/test-more/issues/387
Patch0: Test-Simple-0.98_05-Pass-regular-expression-intact.patch
BuildArch: noarch
@@ -87,6 +87,10 @@ make test
%{_mandir}/man3/Test::Tutorial.3pm*
%changelog
+* Sat Oct 12 2013 Paul Howarth p...@city-fan.org - 0.99-1
+- 0.99 bump
+- This release by RJBS - update source URL
+
* Fri Aug 09 2013 Petr Pisar ppi...@redhat.com - 0.98.05-3
- Pass regular expression intact
diff --git a/sources b/sources
index 05cbe80..1bff21a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2d51e2e69435dc666405b6a8b2265992 Test-Simple-0.98_05.tar.gz
+0ff8a222d0c0be5a2ada2881a053e2b1 Test-Simple-0.99.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-Test-Simple] Created tag perl-Test-Simple-0.99-1.fc21
The lightweight tag 'perl-Test-Simple-0.99-1.fc21' was created pointing to: 752e310... Update to 0.99 -- 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-Test-Simple] Created tag perl-Test-Simple-0.99-1.fc20
The lightweight tag 'perl-Test-Simple-0.99-1.fc20' was created pointing to: 752e310... Update to 0.99 -- 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 967719] Segfault in Perl_gv_fetchpvn_flags when trying to initialize back_perl openldap backend
https://bugzilla.redhat.com/show_bug.cgi?id=967719 Howard Chu h...@symas.com changed: What|Removed |Added CC||h...@symas.com --- Comment #8 from Howard Chu h...@symas.com --- Please also followup to OpenLDAP ITS#7573 with any conclusions you reach, thanks. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=bJ5cMkjyVJa=cc_unsubscribe -- 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
Broken dependencies: perl-Authen-Simple
perl-Authen-Simple has broken dependencies in the epel-6 tree: On ppc64: perl-Authen-Simple-0.4-5.el6.noarch requires perl(Crypt::PasswdMD5) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-WWW-GoodData
perl-WWW-GoodData has broken dependencies in the epel-5 tree: On ppc: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 On i386: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 Please resolve this as soon as possible. -- 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
Broken dependencies: perl-WWW-GoodData
perl-WWW-GoodData has broken dependencies in the epel-5 tree: On ppc: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 On i386: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 Please resolve this as soon as possible. -- 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
