[EPEL-devel] Orphaned some packages in EL5 and EL6
I no longer have access to nor need for EL5 and EL6 boxes so I have orphaned the following packages in those branches: abcde bash-completion ccache colordiff reptyr rpmdevtools tomcat-native ...and I've also orphaned javasqlite in all branches (including Fedora) as I'm not using it any more. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: AppData Screenshot Requirements
On 13 December 2014 at 01:05, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: I think you should step back and consider this in context. *Everything* we do in Fedora, and more generally speaking in open source, is a work in progress. 100% agree, I couldn't have said this better myself. The only way for a standard to remain relevant and useful is to allow it to slowly evolve. There's no way to point out issues except by showing examples. Anything else would be too handwavy. Jerry: I didn't consider this would be insulting, and I'm really sorry if it came across like that. I certainly wasn't aiming to ridicule you, just to show an actual example. In this case I showed it's clearly not a screenshot and just a resized thumbnail. Because another screenshot is listed in the proofgeneral AppData file http://alt.fedoraproject.org/pub/alt/screenshots/f22/source/proofgeneral-da9c07acd86cdb0fb302139636d2996f.png that does look good and fits all the size criteria I didn't email you directly. Anyway, rhughes has put an incredible amount of work into this and is doing a lot to coordinate various steps required to make this work. ...in his free time, in this case late on a Friday night. I do get paid to hack on some of this stuff working at Red Hat, but a lot of the more dull, time-consuming emailing and upstream bug-opening happens in my spare time. I'm trying my best to make this work, and I'm heartened to see the number of AppData-enabled applications is going up nearly every day, with newly added applications more-often-than-not having validated AppData files without any nagging from me. Richard -- 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: F22 System Wide Change: Change xorg input stack to use libinput
On 13/12/14 01:10, Kevin Kofler wrote: An additional objection I have to this change proposal is that libinput (deliberately) only implements a small subset of the configurability of the old drivers, and thus, if we are going to remove the old drivers entirely, we are taking away flexibility from our users. Indeed. Is it, for example, still the case that the libinput developers are refusing to consider things like definable button areas on clickpads so you can create a proper middle button? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
javasqlite orphaned
Hi, I'm not using javasqlite any more so I've orphaned it in all branches (including EPEL). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20141213 changes
Compose started at Sat Dec 13 05:15:03 UTC 2014 Broken deps for i386 -- [3Depict] 3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [bibletime] bibletime-2.10.1-4.fc22.i686 requires libsword-1.7.3.so [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [gcc-python-plugin] gcc-python2-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python2-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python3-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 gcc-python3-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22 [glances] glances-2.1.2-2.fc22.noarch requires python-psutil = 0:2.0.0 [kdeplasma-addons] plasma-wallpaper-marble-4.14.3-1.fc22.i686 requires libmarblewidget.so.19 [nwchem] nwchem-openmpi-6.3.2-11.fc21.i686 requires libmpi_usempi.so.1 [openstack-neutron-gbp] openstack-neutron-gbp-2014.2-0.2.acb85f0git.fc22.noarch requires openstack-neutron = 0:2014.2 [pam_mapi] pam_mapi-0.2.0-3.fc22.i686 requires libmapi.so.0 [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [rubygem-wirb] rubygem-wirb-1.0.3-2.fc21.noarch requires rubygem(paint) 0:0.9 [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [subsurface] subsurface-4.2-3.fc22.i686 requires libmarblewidget.so.19 [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.i686 requires libmongoclient.so uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.i686 requires libmongoclient.so [vfrnav] vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16 vfrnav-utils-20140510-2.fc22.i686 requires libpolyclipping.so.16 Broken deps for x86_64 -- [3Depict] 3Depict-0.0.16-3.fc22.x86_64 requires libmgl.so.7.2.0()(64bit) [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [bibletime] bibletime-2.10.1-4.fc22.x86_64 requires libsword-1.7.3.so()(64bit) [cab] cab-0.1.9-12.fc22.x86_64 requires cabal-dev [dnssec-check] dnssec-check-1.14.0.1-4.fc20.x86_64 requires libval-threads.so.14()(64bit) dnssec-check-1.14.0.1-4.fc20.x86_64 requires libsres.so.14()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.13-2.fc22.x86_64 requires gcc = 0:4.9.2-1.fc22 gcc-python2-plugin-0.13-2.fc22.x86_64 requires gcc = 0:4.9.2-1.fc22 gcc-python3-debug-plugin-0.13-2.fc22.x86_64 requires gcc = 0:4.9.2-1.fc22 gcc-python3-plugin-0.13-2.fc22.x86_64 requires gcc = 0:4.9.2-1.fc22 [glances] glances-2.1.2-2.fc22.noarch requires python-psutil = 0:2.0.0 [kdeplasma-addons] plasma-wallpaper-marble-4.14.3-1.fc22.x86_64 requires libmarblewidget.so.19()(64bit) [nwchem] nwchem-openmpi-6.3.2-11.fc21.x86_64 requires libmpi_usempi.so.1()(64bit) [openstack-neutron-gbp] openstack-neutron-gbp-2014.2-0.2.acb85f0git.fc22.noarch requires openstack-neutron = 0:2014.2 [pam_mapi] pam_mapi-0.2.0-3.fc22.i686 requires libmapi.so.0 pam_mapi-0.2.0-3.fc22.x86_64 requires libmapi.so.0()(64bit) [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [rubygem-wirb] rubygem-wirb-1.0.3-2.fc21.noarch requires rubygem(paint) 0:0.9 [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [subsurface] subsurface-4.2-3.fc22.x86_64 requires libmarblewidget.so.19()(64bit) [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.x86_64 requires libmongoclient.so()(64bit) uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.x86_64 requires libmongoclient.so()(64bit) [vfrnav] vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16 vfrnav-20140510-2.fc22.x86_64 requires libpolyclipping.so.16()(64bit) vfrnav-utils-20140510-2.fc22.x86_64 requires libpolyclipping.so.16()(64bit) Broken deps for armhfp -- [3Depict] 3Depict-0.0.16-3.fc22.armv7hl requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [avro] avro-mapred-1.7.5-9.fc22.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc22.noarch requires hadoop-client [bibletime] bibletime-2.10.1-4.fc22.armv7hl requires libsword-1.7.3.so [cab] cab-0.1.9-12.fc22.armv7hl requires cabal-dev [dnssec-check] dnssec-check-1.14.0.1-4.fc20.armv7hl requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.armv7hl requires libsres.so.14
Re: docker 1.4.0 available, fixes multiple CVEs - testing/karma needed
On 12/12/2014 03:34 PM, Lokesh Mandvekar wrote: On Fri, Dec 12, 2014 at 10:14:50AM -0800, M. Edward (Ed) Borasky wrote: Working here on F21 - karma logged! Thanks. Btw, could you also check if things work fine after restarting docker.service (if not tested already)? I see database locked errors after a restart on rawhide :\ On Fri, Dec 12, 2014 at 7:57 AM, Lokesh Mandvekar l...@fedoraproject.org wrote: I've updated docker to 1.4.0 for fedora and fedora epel. This release fixes: CVE-2014-9357: https://access.redhat.com/security/cve/CVE-2014-9357 CVE-2014-9358: https://access.redhat.com/security/cve/CVE-2014-9358 CVE-2014-9356: https://access.redhat.com/security/cve/CVE-2014-9356 It'd be great if people could test these and add karma/comments: https://admin.fedoraproject.org/updates/docker-io-1.4.0-1.fc21 https://admin.fedoraproject.org/updates/docker-io-1.4.0-1.fc20 https://admin.fedoraproject.org/updates/docker-io-1.4.0-1.fc19 https://admin.fedoraproject.org/updates/docker-io-1.4.0-1.el6 Thanks! -- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Twitter: http://twitter.com/znmeb; OSJourno: Robust Power Tools for Digital Journalists https://osjourno.com Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct docker in Rawhide is busted. According to docker there is a problem with their sqlite go bindings and golang-1.4. https://bugzilla.redhat.com/show_bug.cgi?id=1169334 The following temporarily works for me when this situation happens. rm -f /var/lib/docker/linkgraph.db; systemctl restart docker Works for me. Although you might need to run this command again when the database gets locked up. -- 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: Heads up: F21 LLVM rebase
On Fri, Dec 12, 2014 at 7:51 PM, Kevin Kofler kevin.kof...@chello.at wrote: Michael DePaulo wrote: I too come from an Ubuntu/Debian background. Like other major pieces of software, Ubuntu and Debian both make multiple 2.x or 3.x versions of LLVM available for each release of their OS. They do the following: 1. The major version is specified in the package name. For example, llvm-3.4 and llvm-3.5 are the names of separate packages. The actual package versions are like 3.4.2-13 3.5-6 respectively 2. The package llvm is a small package that depends on the recommended major version for developers. For example, in Jessie, 3.5 is the recommended major version, and Jessie llvm contains symlinks such as: /usr/bin/llvm-extract - /usr/bin/llvm-extract-3.5 Would Fedora permit someone like myself to contribute an LLVM packaging scheme like that? That would NOT be a good idea, for a simple reason: The version of LLVM Mesa (i.e., libGL) links ends up linked into MANY executables. If you link some other library against some other version of LLVM, and then an application ends up directly or indirectly linking both that library and libGL, it ends up indirectly linking the 2 incompatible versions of LLVM and crashing. We have already had this happen, and other distributions too, see e.g.: http://www.valdyas.org/fading/index.cgi/2011/10/08#llvm and still, months later (when it was already long fixed in Fedora by using a common shared LLVM, but apparently not on some other distributions): http://mail.kde.org/pipermail/kimageshop/2012-September/011387.html (Now, to be fair, it turns out that OpenGTL has since been removed from Fedora because Krita no longer uses it, but the exact same problem can happen with any of the other consumers of LLVM.) There can be only one version of LLVM in the whole distribution at a time. This topic has already come up several times on this mailing list (basically each time such a rebase was done), please read the archives, e.g., this thread: https://lists.fedoraproject.org/pipermail/devel/2014-March/197227.html and my reply to a proposal essentially identical to yours: https://lists.fedoraproject.org/pipermail/devel/2014-March/197278.html Kevin Kofler Understood, sorry for not searching the archives. -Mike -- 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: Qwt and QwtPolar for Qt5?
On Fri, Dec 12, 2014 at 1:29 PM, Rex Dieter rdie...@math.unl.edu wrote: Dave Johansen wrote: I would like to create Qwt and QwtPolar packages for Qt5 and before opening the Bugzilla I wanted to check if there was any feedback on here. I have spec files and source RPMs available at: https://daveisfera.fedorapeople.org/qwt-qt5/qwt-qt5.spec https://daveisfera.fedorapeople.org/qwt-qt5/qwt-qt5-6.1.1-3.el6.src.rpm https://daveisfera.fedorapeople.org/qwtpolar-qt5/qwtpolar-qt5.spec https://daveisfera.fedorapeople.org/qwtpolar-qt5/qwtpolar-qt5-1.1.1-2.el6.src.rpm I'm primarily interested in the RHEL 6/7 and haven't tested this on Fedora, so if anyone is willing to build it and do some testing, then that would be helpful as well. Qwt-qt5 support is in rawhide, but I was waiting for upstream to decide on a standard naming scheme before building for stable releases. (They previously used the same library sonames for both Qt4 and Qt5, which isn't nice when you want both to be parallel-installable). Will probably have to do the same for qwtpoloar. I didn't realize that had been done in rawhide. Your solution of having a single spec file to build both is probably easier to maintain and seems like the write way to go. I took the same approach of adding -qt5 to the .so files and such, but it sounds like it's worth waiting to see what upstream is going to do before committing to anything in EPEL and the Fedora stable releases. Is there any estimate of when that decision will be made? Thanks, Dave -- 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: is it possible to skip a noarch subpackage on certains archs (arm)
On Fri, Dec 12, 2014 at 1:09 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: Hi, I have a package (a C++ library), which generated doxygen documentation during build. The documentation lands in a noarch -doc subpackage, the rest in the main package or in subpackages, all arch-ed. The problem is that generating the documentation takes forever (6+ hours) on arm. The arch-ed parts build fairly quickly. Would it be possible to use %ifarch or equivalent to only build the (slow) -doc subpackage on x86_64 or i686 archs? Would arm then get the noarch subpackage from other archs? You *could*, it's a scripting language. I don't see how the noarch package would get migrated to the relevant arm repos. However, six hours to build documentation is a bit excessive. Would it be saner to make a separate SRPM that builds just the documentation, even if it uses the same source tarball? That way, minor version updates of the software would not force a rebuild of the documentation. -- 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 update failure in fedora19
Hi List, I've been facing a multilib protection failure in yum update. When I tried to clean /var/run/cache/yum/* as well passing setopt=protected_multilib=false as parameter in yum update, but none of them actually resolved the issue. After turning off protected_multilib, I am getting the following error: Error: Package: 1:NetworkManager-vpnc-0.9.9.0-6.git20140428.el7.x86_64 (epel) Requires: NetworkManager = 1:0.9.9.0 Installed: 1:NetworkManager-0.9.8.8-2.fc19.x86_64 (@updates) NetworkManager = 1:0.9.8.8-2.fc19 Available: 1:NetworkManager-0.9.8.2-2.fc19.i686 (fedora) NetworkManager = 1:0.9.8.2-2.fc19 Error: Package: 2:qemu-system-x86-2.0.0-1.el7.3.x86_64 (epel) Requires: libiscsi.so.2()(64bit) Any help would be appreciated. Regards, Atin -- 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 update failure in fedora19
On 13/12/14 15:19, Atin Mukherjee wrote: I've been facing a multilib protection failure in yum update. When I tried to clean /var/run/cache/yum/* as well passing setopt=protected_multilib=false as parameter in yum update, but none of them actually resolved the issue. After turning off protected_multilib, I am getting the following error: Error: Package: 1:NetworkManager-vpnc-0.9.9.0-6.git20140428.el7.x86_64 (epel) Requires: NetworkManager = 1:0.9.9.0 Installed: 1:NetworkManager-0.9.8.8-2.fc19.x86_64 (@updates) NetworkManager = 1:0.9.8.8-2.fc19 Available: 1:NetworkManager-0.9.8.2-2.fc19.i686 (fedora) NetworkManager = 1:0.9.8.2-2.fc19 Error: Package: 2:qemu-system-x86-2.0.0-1.el7.3.x86_64 (epel) Requires: libiscsi.so.2()(64bit) You appear to have a mixture of F19 and EPEL7 repos enabled which I'm guessing isn't what you intended... Try turning off the EPEL ones. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- 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 update failure in fedora19
On 12/13/2014 04:19 PM, Atin Mukherjee wrote: Hi List, I've been facing a multilib protection failure in yum update. When I tried to clean /var/run/cache/yum/* as well passing setopt=protected_multilib=false as parameter in yum update, but none of them actually resolved the issue. After turning off protected_multilib, I am getting the following error: Error: Package: 1:NetworkManager-vpnc-0.9.9.0-6.git20140428.el7.x86_64 (epel) Requires: NetworkManager = 1:0.9.9.0 Installed: 1:NetworkManager-0.9.8.8-2.fc19.x86_64 (@updates) NetworkManager = 1:0.9.8.8-2.fc19 Available: 1:NetworkManager-0.9.8.2-2.fc19.i686 (fedora) NetworkManager = 1:0.9.8.2-2.fc19 Error: Package: 2:qemu-system-x86-2.0.0-1.el7.3.x86_64 (epel) Requires: libiscsi.so.2()(64bit) I think your posting is off-topic for this list. us...@lists.fedoraproject.org would have been the correct one. Wrt. your issue: AFAIC, you seem to have mixed epel7 with fedora. This is not supposed to work, which means your system likely is quite messed up. You can try to disable all epel-repos and cleanup your installation, using yum distro-sync, package-cleanup --orphans and the like, aiming at removing all epel packages and to sync with fedora. Ralf -- 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: Qwt and QwtPolar for Qt5?
Dave Johansen wrote: I took the same approach of adding -qt5 to the .so files and such, but it sounds like it's worth waiting to see what upstream is going to do before committing to anything in EPEL and the Fedora stable releases. Is there any estimate of when that decision will be made? No estimate, but hopefully upstream is coming around to this being a good idea (there seems to be some resistance and misunderstanding from them that I just don't understand). Here's the start of the thread I started on the topic, http://sourceforge.net/p/qwt/mailman/qwt-interest/thread/54787E9A.6040108%40tigertal.de/#msg33089562 At least debian seems on board with my proposal now, so hopefully that will carry some weight. -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 downloads repository metadata in 3 places!
Hi! I noticed that F21 can potentially download repository metadata 3 times: 1. Yum cache 2. DNF cache 3. PackageKit cache! It really hurts to see how Fedora ignorance towards different kind of users is being increased as time passes. If Fedora is an international distro, it should try to consider condition of different users, not just a portion of them. Fedora repository metadata format was already hostile, it wastes bandwidth considerably downloading mostly useless data repeatedly. Things got worse for DNF as it decides to also always download filelists. Now, Fedora 21 contains yum, dnf and PackageKit (software center) with new backend. Surprisingly, PackageKit uses its own separate cache. DNF refreshes its cache automatically (without user's consent) every 3 hours by default (according to 'man dnf.conf'). PackageKit also does the same, but I don't know when it does (also without user's consent). Now, if you are exclusively a 'yum' user, you'll end up with 3 repository metadata downloads, two of which you are unaware of. Probably, it is OK for most of you having access to cheap, fast internet access. But not everybody in the world has such access. It was not long ago that dial-up internet access was a norm in my area (there are still some using it!). I'm not using dial-up, but still can't afford such a waste of bandwidth. I'm using a 'fast' internet access, which is 512Kb/sec, and have 6GiB for 3 months (with free access at nights, which I use to update/install Fedora packages). As I've described at [1], DNF alone can potentially consume all my internet credit very soon; even if I don't want to use any package manager at all. This will make many users with conditions like me very angry when they realize that Fedora has eaten their money silently. Another side of the story is how Fedora lacks any integration in this area. There are separate caches. Fedora doesn't tell you that it'll eat your internet. Also, there is nowhere you can tell Fedora 'Please don't eat my internet without my permission'. Even there is no single configuration option for it. You should manually disable automatic downloading for DNF, and then separately for gnome software using some obscure gsettings commands you should look for. Well, I've not tried other desktops, each one might have each own settings for that too! (though usually such ignorance is the worst in GNOME). It's so unfortunate to see how Fedora lacks any integration (one of the main things that a distro is expected to provide) in its package management software (one of the main distro specific software, where you fairly expect an integrated experience as an 'internal' software). As I was expecting, I've already seen how a user in our local community cried about Fedora 21 consuming his Internet credit the day after the release. The number of Fedora users around me were already low, and I expect it to become less if Fedora continues its ignorance trend. I'm not annoyed that much yet, as I'm just considering switching to a different DE after suffering GNOMEs decisions for a long time hoping that 'things will be better soon'; and finding out that my needs are something that 'THEY see no reasons to support'. P.S. sorry for the somewhat long email. I'm a little bit angry! :P Regards, Hedayat [1] https://hedayatvk.wordpress.com/2014/07/26/the-shiny-new-dnf-and-why-i-prefer-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: F21 downloads repository metadata in 3 places!
Am 13.12.2014 um 22:10 schrieb Hedayat Vatankhah: I noticed that F21 can potentially download repository metadata 3 times: 1. Yum cache 2. DNF cache 3. PackageKit cache! It really hurts to see how Fedora ignorance towards different kind of users is being increased as time passes. If Fedora is an international distro, it should try to consider condition of different users, not just a portion of them. Fedora repository metadata format was already hostile, it wastes bandwidth considerably downloading mostly useless data repeatedly. Things got worse for DNF as it decides to also always download filelists. Now, Fedora 21 contains yum, dnf and PackageKit (software center) with new backend. Surprisingly, PackageKit uses its own separate cache. DNF refreshes its cache automatically (without user's consent) every 3 hours by default (according to 'man dnf.conf'). PackageKit also does the same, but I don't know when it does (also without user's consent). the automatic metadata refresh is a no-go frankly in the meantime only the metadata are half as large as some of my server setups at all (our asterisk PBX needs 850 MB with F20) Now, if you are exclusively a 'yum' user, you'll end up with 3 repository metadata downloads systemctl mask dnf-makecache.timer stops the new nosense if you are not using GNOME and YUM from CLI you can remove package kit at all and frankly my typical command is rm -rf /var/cache/yum*; yum upgrade because when i look for updates i want the *now* recent metadata and don't need them refreshed one hour ago [harry@srv-rhsoft:~]$ rpm -qa | grep -i packagekit [harry@srv-rhsoft:~]$ sarcasmmaybe someone should place a bandwidh-limiting of 0.5 Mbit and a onhtly limit of 1 GB per month in front of developers to wake them up/sarcasm 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: is it possible to skip a noarch subpackage on certains archs (arm)
On Sat, Dec 13, 2014 at 10:00:00AM -0500, Nico Kadel-Garcia wrote: On Fri, Dec 12, 2014 at 1:09 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: Hi, I have a package (a C++ library), which generated doxygen documentation during build. The documentation lands in a noarch -doc subpackage, the rest in the main package or in subpackages, all arch-ed. The problem is that generating the documentation takes forever (6+ hours) on arm. The arch-ed parts build fairly quickly. Would it be possible to use %ifarch or equivalent to only build the (slow) -doc subpackage on x86_64 or i686 archs? Would arm then get the noarch subpackage from other archs? You *could*, it's a scripting language. I don't see how the noarch package would get migrated to the relevant arm repos. OK. However, six hours to build documentation is a bit excessive. That build seems to have hung... it never finished and I had to kill it. It now seems to run in ~2h. But the problem might have solved itself in a different way: I got the test suite to run properly, but it still fails on arm, so I might have to exclude that arch anyway. Would it be saner to make a separate SRPM that builds just the documentation, even if it uses the same source tarball? That way, minor version updates of the software would not force a rebuild of the documentation. Yeah, but that's additional work for each update... and more chance to make an error. I actually prefer for the build to be long. Zbyszek -- 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: F21 downloads repository metadata in 3 places!
/*Reindl Harald h.rei...@thelounge.net*/ wrote on Sat, 13 Dec 2014 22:19:25 +0100: Am 13.12.2014 um 22:10 schrieb Hedayat Vatankhah: I noticed that F21 can potentially download repository metadata 3 times: 1. Yum cache 2. DNF cache 3. PackageKit cache! It really hurts to see how Fedora ignorance towards different kind of users is being increased as time passes. If Fedora is an international distro, it should try to consider condition of different users, not just a portion of them. Fedora repository metadata format was already hostile, it wastes bandwidth considerably downloading mostly useless data repeatedly. Things got worse for DNF as it decides to also always download filelists. Now, Fedora 21 contains yum, dnf and PackageKit (software center) with new backend. Surprisingly, PackageKit uses its own separate cache. DNF refreshes its cache automatically (without user's consent) every 3 hours by default (according to 'man dnf.conf'). PackageKit also does the same, but I don't know when it does (also without user's consent). the automatic metadata refresh is a no-go frankly in the meantime only the metadata are half as large as some of my server setups at all (our asterisk PBX needs 850 MB with F20) Now, if you are exclusively a 'yum' user, you'll end up with 3 repository metadata downloads systemctl mask dnf-makecache.timer stops the new nosense if you are not using GNOME and YUM from CLI you can remove package kit at all and frankly my typical command is rm -rf /var/cache/yum*; yum upgrade because when i look for updates i want the *now* recent metadata and don't need them refreshed one hour ago *I* know how to disable them (or at least, I hope so! Maybe there is/will be a foo package who decides to download its own copy too!), but that's not the point of my post. What I expect is either: 1. disable all kinds of potentially demanding internet access by default and let people enable if they like; or 2. add an option to anaconda, or a post installation option, so that the user can decide if he wants automatic metadata/package updates for *Fedora* (not a specific DE/application) or not. And the options should be applied to the whole distribution consistently, even if you use multiple DEs. (And hey, you might find 'yum clean expire-cache' a better alternative for the 'rm -rf' command you use!) [harry@srv-rhsoft:~]$ rpm -qa | grep -i packagekit [harry@srv-rhsoft:~]$ sarcasmmaybe someone should place a bandwidh-limiting of 0.5 Mbit and a onhtly limit of 1 GB per month in front of developers to wake them up/sarcasm That would be great! ;) I think even 1 month of such experience should be more than enough! -- 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: Contacts for MinGW SIG
On 12/12/2014 08:02 AM, Michael Cronenworth wrote: You could either e-mail Erik directly or ping epienbroek in #fedora-mingw. I will offer to take up co-maintainership if he's too busy. I have pushed updates for all branches. Feel free to leave karma. -- 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: Contacts for MinGW SIG
On Dec 13, 2014, at 17:56, Michael Cronenworth m...@cchtml.com wrote: On 12/12/2014 08:02 AM, Michael Cronenworth wrote: You could either e-mail Erik directly or ping epienbroek in #fedora-mingw. I will offer to take up co-maintainership if he's too busy. I have pushed updates for all branches. Feel free to leave karma. Great, thank you! JT -- 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: Fedora Installation Needs Intelligence
On 12-12-14 08:25:56 Jan Kratochvil wrote: On Fri, 12 Dec 2014 08:17:45 +0100, Satyajit Sahoo wrote: Wireless is a requirement for laptops. For example, Macbook Air doesn't have an ethernet port. s/requirement for laptops/requirement for Macbook Air/ Well, my Dell XPS-13 didn't come with an Ethernet port either. (Yes, I bought a dongle, but just sayin'.) -- Garry T. Williams -- 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: Poll: How users use DNF
/*Radek Holy rh...@redhat.com*/ wrote on Tue, 9 Dec 2014 12:28:54 -0500 (EST): Dear users of YUM and DNF, I'm writing to you regarding a request for your feedback. I would be very grateful if you could send me a brief description of how you use YUM or DNF currently or how would you like to use it. I am particularly interested in the occurrences of dnf/yum install calls in your scripts. What does these scripts do and what do they expect when they call the install command in different situations? Please share with me the use cases, not the description of the install command. Think twice before you share something because I believe it's not as easy as it might seem. As an example I think it might be something like: - I call YUM install, because I want to get given packages into my system and I don't care whether it requires an upgrade or downgrade or what. or - I want to get them there but it should protect me against dangerous operations like downgrades or - I often make typos, so I expect that the program knows what I mean or - it would be nice if it would literally perform the installation; if any of the packages cannot be installed because of any reason, it should fail. Not something like: that's obvious that the install command should never downgrade packages. Please focus on *use cases*. The *real* (non-hypothetical) use cases. Not on the command's name as it might also result in a new command (while preserving the well-known install command together with an appropriate behaviour). I don't mind if you send it offlist (or to another list). I think there is no need to comment on anyone's use case. Every case is valid. Just not every case can be supported. Thank you very much in advance. 1. There are many cases that I want to install a package, but I don't care if it is the latest version available in the repos. So, I use '-C' regularly (currently doesn't work with yum, so I use dnf when I want to use -C to install a package without updating metadata). 2. I don't want dnf/yum/(any other software) to download data from internet at random times. If it wants to do it, it should do it on the networks I allowed, at the times I allowed. Not just when 'it can'. 3. When I want to install a package, I usually 'want' it. So, if it requires downgrade, I might be OK with it. I'd love to see a proposal with downgrades rather than saying that sorry, this package cannot be installed. 4. When I ask it to install some packages, I usually want it to do it with minimal downloads. I don't want it to update its dependencies if they are already installed, unless it is strictly necessary to install the package. Even in that case, I'd love to be able to tell the package manager (e.g. using a new command, or using an option to the install command) to install an older version of the package so that its dependencies doesn't need updating (instead of updating the dependencies to install the latest version, install an older version which matches the dependencies I've already got installed). Regards, Hedayat -- 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: Fedora Installation Needs Intelligence
On 12/12/2014 03:57 AM, Marcin Juszkiewicz wrote: There are still wireless cards which do not work with Linux out of box? (assuming that firmware is provided) The firmware is the problem. There are some Broadcom chipsets that need firmware to work, but that firmware is not allowed to be distributed. They might only be found in older laptops now, I've only run into them once or twice. It would be nice if the installer could at least warn about it. The wireless will work, but there are some manual steps required to install the firmware. -- 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: F21 downloads repository metadata in 3 places!
On 12/13/2014 01:10 PM, Hedayat Vatankhah wrote: Hi! I noticed that F21 can potentially download repository metadata 3 times: 1. Yum cache 2. DNF cache 3. PackageKit cache! It really hurts to see I'm not aware of the PackageKit cache, where is it? I did accidentally discover about dnf recently on some F20 systems. I don't remember if it was network traffic or disk space that tipped me off, but I discovered that dnf was downloading stuff when I didn't even know it was installed. I immediately disabled it, but that does seem like rather unfriendly behaviour... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1169750] CVE-2014-9130 perl-YAML-LibYAML: libyaml: assert failure when processing wrapped strings [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1169750 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-YAML-LibYAML-0.54-1.fc |perl-YAML-LibYAML-0.54-1.fc |21 |19 --- Comment #7 from Fedora Update System upda...@fedoraproject.org --- perl-YAML-LibYAML-0.54-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. -- 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=lSKBgc2l4ia=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
[Bug 1169369] CVE-2014-9130 libyaml: assert failure when processing wrapped strings
https://bugzilla.redhat.com/show_bug.cgi?id=1169369 --- Comment #11 from Fedora Update System upda...@fedoraproject.org --- perl-YAML-LibYAML-0.54-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. -- 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=bkz0LVwE8da=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
[Bug 1173066] perl-YAML-Syck-1.28 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1173066 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- Package perl-YAML-Syck-1.28-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-YAML-Syck-1.28-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-16809/perl-YAML-Syck-1.28-1.fc21 then log in and leave karma (feedback). -- 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=a0Wd6T2krya=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
[Bug 1169369] CVE-2014-9130 libyaml: assert failure when processing wrapped strings
https://bugzilla.redhat.com/show_bug.cgi?id=1169369 --- Comment #12 from Fedora Update System upda...@fedoraproject.org --- libyaml-0.1.6-6.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report. -- 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=CRHH6ZX7w0a=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
[Bug 1169369] CVE-2014-9130 libyaml: assert failure when processing wrapped strings
https://bugzilla.redhat.com/show_bug.cgi?id=1169369 Bug 1169369 depends on bug 1169371, which changed state. Bug 1169371 Summary: CVE-2014-9130 libyaml: assert failure when processing wrapped strings [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=1169371 What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA -- 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=HQdi6hWkT9a=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
[Bug 1173059] perl-DB_File-1.834 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1173059 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- Package perl-DB_File-1.834-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-DB_File-1.834-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-16849/perl-DB_File-1.834-1.fc20 then log in and leave karma (feedback). -- 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=v7W0lxhqMXa=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
[Bug 1172627] perl-Filter-1.51 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1172627 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- Package perl-Filter-1.51-1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Filter-1.51-1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-16855/perl-Filter-1.51-1.fc21 then log in and leave karma (feedback). -- 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=RcC0PMpEePa=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
[Bug 1169369] CVE-2014-9130 libyaml: assert failure when processing wrapped strings
https://bugzilla.redhat.com/show_bug.cgi?id=1169369 --- Comment #13 from Fedora Update System upda...@fedoraproject.org --- libyaml-0.1.6-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. -- 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=5WEELbNSBxa=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
[Bug 1173061] perl-IPC-Run-0.93 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1173061 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- Package perl-IPC-Run-0.93-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-IPC-Run-0.93-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-16872/perl-IPC-Run-0.93-1.fc20 then log in and leave karma (feedback). -- 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=4oYVBwmjvxa=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
[Bug 1169750] CVE-2014-9130 perl-YAML-LibYAML: libyaml: assert failure when processing wrapped strings [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1169750 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-YAML-LibYAML-0.54-1.fc |perl-YAML-LibYAML-0.54-1.fc |19 |20 --- Comment #8 from Fedora Update System upda...@fedoraproject.org --- perl-YAML-LibYAML-0.54-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- 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=RxKKKOPw3Pa=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
[Bug 1169369] CVE-2014-9130 libyaml: assert failure when processing wrapped strings
https://bugzilla.redhat.com/show_bug.cgi?id=1169369 --- Comment #14 from Fedora Update System upda...@fedoraproject.org --- perl-YAML-LibYAML-0.54-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- 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=snm80fnOwia=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
[Bug 1169369] CVE-2014-9130 libyaml: assert failure when processing wrapped strings
https://bugzilla.redhat.com/show_bug.cgi?id=1169369 --- Comment #15 from Fedora Update System upda...@fedoraproject.org --- libyaml-0.1.6-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- 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=zMG6IDWPzwa=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
[perl-Text-BibTeX] - fix build on non-x86 64-bit arches
commit 6868b5eeec5fb9863cb43db48cd561ef69af309b
Author: Dan Horák d...@danny.cz
Date: Sat Dec 13 12:03:45 2014 +0100
- fix build on non-x86 64-bit arches
perl-Text-BibTeX-secondary.patch | 12
perl-Text-BibTeX.spec|8 +++-
2 files changed, 19 insertions(+), 1 deletions(-)
---
diff --git a/perl-Text-BibTeX-secondary.patch b/perl-Text-BibTeX-secondary.patch
new file mode 100644
index 000..27bc703
--- /dev/null
+++ b/perl-Text-BibTeX-secondary.patch
@@ -0,0 +1,12 @@
+diff -up Text-BibTeX-0.70/Build.PL.secondary Text-BibTeX-0.70/Build.PL
+--- Text-BibTeX-0.70/Build.PL.secondary2014-12-13 11:46:40.0
+0100
Text-BibTeX-0.70/Build.PL 2014-12-13 11:47:27.0 +0100
+@@ -79,7 +79,7 @@ if ($^O =~ /mswin32/i) {
+ unlink catfile($libdir, $target);
+ }
+ } else {
+-if ($Config{archname} =~ /^x86_64/) {
++if ($Config{archname} =~ /^x86_64|^ppc64|^s390x|^aarch64/) {
+ $libdir =~ s/\bbin\b/lib64/;
+ if (!-d $libdir) {
+ my $test = $libdir;
diff --git a/perl-Text-BibTeX.spec b/perl-Text-BibTeX.spec
index 35e8ecb..1c9af2c 100644
--- a/perl-Text-BibTeX.spec
+++ b/perl-Text-BibTeX.spec
@@ -1,11 +1,13 @@
Name: perl-Text-BibTeX
Version:0.70
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Interface to read and parse BibTeX files
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Text-BibTeX/
Source0:
http://www.cpan.org/authors/id/A/AM/AMBS/Text-BibTeX-%{version}.tar.gz
+# fix build on non-x86 64-bit arches
+Patch0: perl-Text-BibTeX-secondary.patch
BuildRequires: perl
BuildRequires: perl(base)
BuildRequires: perl(lib)
@@ -44,6 +46,7 @@ entries, as well as other miscellaneous functions.
%prep
%setup -q -n Text-BibTeX-%{version}
+%patch0 -p1 -b .secondary
sed -ri 's#/usr/local/bin/perl5?#%{__perl}#' scripts/* examples/*
chmod a-x scripts/* examples/*
@@ -70,6 +73,9 @@ chrpath -d $RPM_BUILD_ROOT%{_bindir}/*
%{_libdir}/*.so
%changelog
+* Sat Dec 13 2014 Dan Horák dan[at]danny.cz 0.70-4
+- fix build on non-x86 64-bit arches
+
* Sat Nov 22 2014 Colin B. Macdonald c...@m.fsf.org 0.70-3
- install faq file.
- no need to split out btparse (used to be a standalone library but is
--
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-BibTeX/f21] - fix build on non-x86 64-bit arches
Summary of changes: 6868b5e... - fix build on non-x86 64-bit arches (*) (*) 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 1166504] Can't locate strict.pm: Permission denied error message does not report concerned file path
https://bugzilla.redhat.com/show_bug.cgi?id=1166504 --- Comment #15 from Doug Maxey d...@enoyolf.org --- Ok, turns out there was some junk older, like really older perl libs in /usr/local. So, with the security enhancement, had to clobber those. That, along with adding 'use lib ...' all is good now. -- 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=JMOFMHTvuXa=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
[Bug 1166504] Can't locate strict.pm: Permission denied error message does not report concerned file path
https://bugzilla.redhat.com/show_bug.cgi?id=1166504 Emmanuel Seyman emman...@seyman.fr changed: What|Removed |Added Status|MODIFIED|CLOSED Resolution|--- |NOTABUG Last Closed|2014-11-21 01:25:50 |2014-12-13 19:59:23 --- Comment #16 from Emmanuel Seyman emman...@seyman.fr --- (In reply to Doug Maxey from comment #15) Ok, turns out there was some junk older, like really older perl libs in /usr/local. Given this, I'm closing this bug NOTABUG. Emmanuel -- 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=3EnkQ12K4Ga=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
File Mojolicious-5.69.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Mojolicious: c7e86a9251e9c208938b06531f45de4e Mojolicious-5.69.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-Mojolicious] Update to 5.69
commit f7fd7392dff02e76ece83dcfc674bf93bdc42f33
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sun Dec 14 03:43:48 2014 +0100
Update to 5.69
.gitignore|1 +
perl-Mojolicious.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 87282e9..cdc0902 100644
--- a/.gitignore
+++ b/.gitignore
@@ -153,3 +153,4 @@ Mojolicious-0.26.tar.gz
/Mojolicious-5.63.tar.gz
/Mojolicious-5.67.tar.gz
/Mojolicious-5.68.tar.gz
+/Mojolicious-5.69.tar.gz
diff --git a/perl-Mojolicious.spec b/perl-Mojolicious.spec
index 98b92f0..635f58a 100644
--- a/perl-Mojolicious.spec
+++ b/perl-Mojolicious.spec
@@ -1,5 +1,5 @@
Name: perl-Mojolicious
-Version:5.68
+Version:5.69
Release:1%{?dist}
Summary:A next generation web framework for Perl
License:Artistic 2.0
@@ -62,6 +62,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Sun Dec 14 2014 Emmanuel Seyman emman...@seyman.fr - 5.69-1
+- Update to 5.69
+
* Thu Dec 04 2014 Emmanuel Seyman emman...@seyman.fr - 5.68-1
- Update to 5.68
diff --git a/sources b/sources
index ec6a1e1..9cae671 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-9f96145d31503c4e0e40be7f0397d18d Mojolicious-5.68.tar.gz
+c7e86a9251e9c208938b06531f45de4e Mojolicious-5.69.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-App-Nopaste] Update to 1.001
commit 1c5ab5611a4f1ac0b196922b06a7ea4cdda4b5f2
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sun Dec 14 03:54:45 2014 +0100
Update to 1.001
.gitignore|1 +
perl-App-Nopaste.spec |7 ++-
sources |2 +-
3 files changed, 8 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index f73c8b4..7308ab3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,3 +12,4 @@ App-Nopaste-0.22.tar.gz
/App-Nopaste-0.96.tar.gz
/App-Nopaste-0.98.tar.gz
/App-Nopaste-0.99.tar.gz
+/App-Nopaste-1.001.tar.gz
diff --git a/perl-App-Nopaste.spec b/perl-App-Nopaste.spec
index 53c22ee..52fc51b 100644
--- a/perl-App-Nopaste.spec
+++ b/perl-App-Nopaste.spec
@@ -1,5 +1,5 @@
Name: perl-App-Nopaste
-Version:0.99
+Version:1.001
Release:1%{?dist}
Summary:Easy access to any pastebin
License:GPL+ or Artistic
@@ -26,10 +26,12 @@ BuildRequires: perl(Module::Runtime)
BuildRequires: perl(POSIX)
BuildRequires: perl(URI::Escape)
BuildRequires: perl(WWW::Mechanize)
+BuildRequires: perl(namespace::clean)
# Tests only
BuildRequires: perl(File::Spec::Functions)
BuildRequires: perl(List::Util)
BuildRequires: perl(LWP::Protocol)
+BuildRequires: perl(Test::Deep)
BuildRequires: perl(Test::More)
BuildRequires: perl(version)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
@@ -89,6 +91,9 @@ make test
%{_mandir}/man1/*
%changelog
+* Sun Dec 14 2014 Emmanuel Seyman emman...@seyman.fr - 1.001-1
+- Update to 1.001
+
* Thu Dec 11 2014 Emmanuel Seyman emman...@seyman.fr - 0.99-1
- Update to 0.99
diff --git a/sources b/sources
index 942c453..5ebb90a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-e2761d7826a6470cde488c9b1869691e App-Nopaste-0.99.tar.gz
+2a349a17a3389a047fe31e5f763ab267 App-Nopaste-1.001.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
File HTML-Strip-2.08.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-HTML-Strip: 39ea9dfb58e9cc2db13916be805e0a55 HTML-Strip-2.08.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
Broken dependencies: perl-OpenOffice-UNO
perl-OpenOffice-UNO has broken dependencies in the epel-6 tree: On x86_64: perl-OpenOffice-UNO-0.07-4.el6.x86_64 requires libsal_textenc.so.3()(64bit) 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-qpid_proton
perl-qpid_proton has broken dependencies in the epel-6 tree: On x86_64: perl-qpid_proton-0.7-1.el6.x86_64 requires qpid-proton-c = 0:0.7 On i386: perl-qpid_proton-0.7-1.el6.i686 requires qpid-proton-c = 0:0.7 On ppc64: perl-qpid_proton-0.7-1.el6.ppc64 requires qpid-proton-c = 0:0.7 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-qpid_proton
perl-qpid_proton has broken dependencies in the epel-6 tree: On x86_64: perl-qpid_proton-0.7-1.el6.x86_64 requires qpid-proton-c = 0:0.7 On i386: perl-qpid_proton-0.7-1.el6.i686 requires qpid-proton-c = 0:0.7 On ppc64: perl-qpid_proton-0.7-1.el6.ppc64 requires qpid-proton-c = 0:0.7 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-OpenOffice-UNO
perl-OpenOffice-UNO has broken dependencies in the epel-6 tree: On x86_64: perl-OpenOffice-UNO-0.07-4.el6.x86_64 requires libsal_textenc.so.3()(64bit) 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-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-QWizard
perl-QWizard has broken dependencies in the epel-5 tree: On ppc: perl-QWizard-3.15-8.el5.noarch requires perl(Gtk2) On x86_64: perl-QWizard-3.15-8.el5.noarch requires perl(Gtk2) On i386: perl-QWizard-3.15-8.el5.noarch requires perl(Gtk2) 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-XML-Xerces
perl-XML-Xerces has broken dependencies in the epel-5 tree: On ppc: perl-XML-Xerces-2.7.0_0-4.el5.ppc requires libxerces-c.so.27 On x86_64: perl-XML-Xerces-2.7.0_0-4.el5.x86_64 requires libxerces-c.so.27()(64bit) On i386: perl-XML-Xerces-2.7.0_0-4.el5.i386 requires libxerces-c.so.27 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-Getopt-GUI-Long
perl-Getopt-GUI-Long has broken dependencies in the epel-5 tree: On ppc: perl-Getopt-GUI-Long-0.91-5.el5.noarch requires perl(Gtk2) On x86_64: perl-Getopt-GUI-Long-0.91-5.el5.noarch requires perl(Gtk2) On i386: perl-Getopt-GUI-Long-0.91-5.el5.noarch requires perl(Gtk2) 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-Getopt-GUI-Long
perl-Getopt-GUI-Long has broken dependencies in the epel-5 tree: On ppc: perl-Getopt-GUI-Long-0.91-5.el5.noarch requires perl(Gtk2) On x86_64: perl-Getopt-GUI-Long-0.91-5.el5.noarch requires perl(Gtk2) On i386: perl-Getopt-GUI-Long-0.91-5.el5.noarch requires perl(Gtk2) 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-XML-Xerces
perl-XML-Xerces has broken dependencies in the epel-5 tree: On ppc: perl-XML-Xerces-2.7.0_0-4.el5.ppc requires libxerces-c.so.27 On x86_64: perl-XML-Xerces-2.7.0_0-4.el5.x86_64 requires libxerces-c.so.27()(64bit) On i386: perl-XML-Xerces-2.7.0_0-4.el5.i386 requires libxerces-c.so.27 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-QWizard
perl-QWizard has broken dependencies in the epel-5 tree: On ppc: perl-QWizard-3.15-8.el5.noarch requires perl(Gtk2) On x86_64: perl-QWizard-3.15-8.el5.noarch requires perl(Gtk2) On i386: perl-QWizard-3.15-8.el5.noarch requires perl(Gtk2) On ppc: perl-QWizard-3.15-10.el5.noarch requires perl(Gtk2) On x86_64: perl-QWizard-3.15-10.el5.noarch requires perl(Gtk2) On i386: perl-QWizard-3.15-10.el5.noarch requires perl(Gtk2) 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
