EPEL blas-devel lapack-devel texinfo-tex are absent in epel-release-7-0.2.noarch
I tried to install R.x86_64 (R-core) on RHEL7 But blas-devel and lapack-devel texinfo-tex unavailable in EPEL repositories. --- Package R-core-devel.x86_64 0:3.1.0-5.el7 will be installed --More--Error: Package: R-core-devel-3.1.0-5.el7.x86_64 (epel) Requires: *blas-devel* = 3.0 Error: Package: R-core-devel-3.1.0-5.el7.x86_64 (epel) Requires: *lapack-devel* Error: Package: R-core-devel-3.1.0-5.el7.x86_64 (epel) Requires: *texinfo-tex* epel-release-7-0.2.noarch ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL Probs with epel beta7 clamav and amavisd-new
Hi there, I want to setup a test system with clamav and amavisd-new, but I can't find clamav: [root@mail1 ~]# yum install amavisd-new Geladene Plugins: fastestmirror, priorities Loading mirror speeds from cached hostfile * epel: mirror.vutbr.cz 11 packages excluded due to repository priority protections Abhängigkeiten werden aufgelöst -- Transaktionsprüfung wird ausgeführt --- Paket amavisd-new.noarch 0:2.9.1-1.el7 markiert, um installiert zu werden -- Abhängigkeit clamav-server-systemd wird für Paket amavisd-new-2.9.1-1.el7.noarch verarbeitet -- Abhängigkeit clamav-server wird für Paket amavisd-new-2.9.1-1.el7.noarch verarbeitet -- Abhängigkeitsauflösung beendet Fehler: Paket: amavisd-new-2.9.1-1.el7.noarch (epel) Benötigt: clamav-server-systemd Fehler: Paket: amavisd-new-2.9.1-1.el7.noarch (epel) Benötigt: clamav-server Sie können versuchen, mit --skip-broken das Problem zu umgehen. Sie könnten Folgendes versuchen: rpm -Va --nofiles --nodigest [root@mail1 ~]# Mit freundlichen Grüßen Andreas ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL R.x86_64 (R-core) yum installation problem
I think that requires the 'optional' repo in RHEL7 From: epel-devel-boun...@lists.fedoraproject.org [mailto:epel-devel-boun...@lists.fedoraproject.org] On Behalf Of Semi Sent: 02 July 2014 12:59 To: epel-devel@lists.fedoraproject.org Subject: EPEL R.x86_64 (R-core) yum installation problem I tried to install R.x86_64 (R-core) on RHEL7 But blas-devel and lapack-devel texinfo-tex unavailable in EPEL repositories. --- Package R-core-devel.x86_64 0:3.1.0-5.el7 will be installed --More--Error: Package: R-core-devel-3.1.0-5.el7.x86_64 (epel) Requires: blas-devel = 3.0 Error: Package: R-core-devel-3.1.0-5.el7.x86_64 (epel) Requires: lapack-devel Error: Package: R-core-devel-3.1.0-5.el7.x86_64 (epel) Requires: texinfo-tex epel-release-7-0.2.noarch ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
dnf-0.5.3 and dnf-core-plugins-0.1.1 released
Hi, the packages are in Rawhide now. Should move to F20 next week too. There's the protected_packages plugin now. Release notes: http://akozumpl.github.io/dnf/release_notes.html http://akozumpl.github.io/dnf-plugins-core/release_notes.html Release announcement: https://dnf.baseurl.org/2014/07/03/dnf-0-5-3-and-core-dnf-plugins-0-1-1-released/ Ales -- 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: delta rpms - can we turn them off
On Wed, Jul 2, 2014 at 6:04 PM, Reindl Harald h.rei...@thelounge.net wrote: but it's just dangerous to assume that will be forever true Agreed with this, but: and as you can see below with gzip you have *always* different results for the same data This is not true, see below. [harry@srv-rhsoft:~/Desktop]$ tar -p -czf 1.tar.gz test.bin [harry@srv-rhsoft:~/Desktop]$ tar -p -czf 2.tar.gz test.bin [harry@srv-rhsoft:~/Desktop]$ tar -p -czf 3.tar.gz test.bin [harry@srv-rhsoft:~/Desktop]$ tar -p -czf 4.tar.gz test.bin [harry@srv-rhsoft:~/Desktop]$ tar -p -czf 5.tar.gz test.bin [harry@srv-rhsoft:~/Desktop]$ md5sum *.gz 8f132cafffe6d7a613a480a5e593abc8 1.tar.gz 3cf402bbbde27db631a2896af9365275 2.tar.gz 5cb1fc9f6628a41d71572862ea4c19a1 3.tar.gz bd51a4779ca4e2e9377488dc64ccaf1c 4.tar.gz 5506a0cfbf39cb28b05babba6755049a 5.tar.gz These tests are faulty, they're not testing gzip with the same data. You're (well tar is internally) gzipping five temporary tarballs that have different timestamps and/or filenames, and gzip's default behavior is to store original file's filename and timestamp so naturally they differ. To actually test gzip, do for example: $ gzip -c test.bin 1.gz $ gzip -c test.bin 2.gz $ md5sum *gz aca340cd42ffd3b2c6a25b646637cae5 1.gz aca340cd42ffd3b2c6a25b646637cae5 2.gz ...or if you want to do it with tar, need to tell it to pass -n to gzip, for example: $ tar c test.bin -I gzip -n 1.tar.gz $ tar c test.bin -I gzip -n 2.tar.gz $ md5sum *gz 03d30b886f9a2f5219909662586e44b5 1.tar.gz 03d30b886f9a2f5219909662586e44b5 2.tar.gz -- 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: dnf-0.5.3 and dnf-core-plugins-0.1.1 released
Am 03.07.2014 10:22, schrieb Ales Kozumplik: the packages are in Rawhide now. Should move to F20 next week too. There's the protected_packages plugin now. Release notes: http://akozumpl.github.io/dnf/release_notes.html http://akozumpl.github.io/dnf-plugins-core/release_notes.html Release announcement: https://dnf.baseurl.org/2014/07/03/dnf-0-5-3-and-core-dnf-plugins-0-1-1-released/ thanks for Bug 1049310 - Keep running kernel Bug 855 - DNF needs to protect the basesystem but that is *not* working [root@rawhide ~]# cat /etc/dnf/protected.d/dnf.conf dnf dnf remove python ends in remove dnf and yum too as weel as dnf remove kernel still offers to remove both 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
request for pygrib packaging debug help
Hi everyone,
I am having a small issue with the pygrib package that I am maintaining.
The package depends on pyproj, but when I install it with yum it also
pulls in python3-pyproj.
All python3 related things are wrapped in %if 0%{?with_python3}
macros, so this should not happen I think.
Clearly I am overlooking some dependency issue in my spec file.
Any help would be appreciated.
Best regards,
Jos de Kloe
--
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: [ACTION REQUIRED][FINAL NOTICE] Retiring packages for Fedora 21 v4
On Jul 2, 2014 11:33 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Tue, Jul 01, 2014 at 07:55:42PM +0200, Till Maas wrote: The following packages are orphaned or did not build for two releases and will be retired when Fedora (F21) is branched, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life According to https://fedoraproject.org/wiki/Schedule branching will occur on 2014-07-08. The packages will be retired starting 2014-07-04. If you intend to claim a package, please take it now. Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Package(co)maintainers === [...] mule orphan, tspauld98 The upstream developer turned up on devel last week wishing to maintain this package. He is not a packager yet. Can it be saved? I noticed this yesterday and took it back for now. (Alternatively, perhaps it could do with a re-review ...) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- 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: request for pygrib packaging debug help
- Original Message -
From: Jos de Kloe josdek...@gmail.com
To: Development discussions related to Fedora
devel@lists.fedoraproject.org
Sent: Thursday, 3 July, 2014 12:07:28 PM
Subject: request for pygrib packaging debug help
Hi everyone,
I am having a small issue with the pygrib package that I am maintaining.
The package depends on pyproj, but when I install it with yum it also
pulls in python3-pyproj.
All python3 related things are wrapped in %if 0%{?with_python3}
macros, so this should not happen I think.
Clearly I am overlooking some dependency issue in my spec file.
Any help would be appreciated.
Best regards,
Jos de Kloe
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
You must move Python 3 Requires into Python 3 subpackage
between lines 89 and 101 in your specfile.
Regards,
Robert Kuska
-
rkuska @
#fedora-devel on freenode
#brno #gulag #software-collections on brq.redhat
--
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: request for pygrib packaging debug help
- Original Message -
Hi everyone,
I am having a small issue with the pygrib package that I am maintaining.
The package depends on pyproj, but when I install it with yum it also
pulls in python3-pyproj.
All python3 related things are wrapped in %if 0%{?with_python3}
macros, so this should not happen I think.
Clearly I am overlooking some dependency issue in my spec file.
Any help would be appreciated.
You have correctly wrapped the Requires: python3-pyproj line in with_python3,
but you put it in the *main* package. You need to move it to the %package -n
python3-%{name} section.
Best regards,
Jos de Kloe
--
Regards,
Bohuslav Slavek Kabrda.
--
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: Handling package conflicts caused by arch specific doc files
On 07/02/2014 04:15 PM, Ankur Sinha wrote: Hi, I was wondering if there's a standard way of solving package conflicts that arise from arch specific doc files. An example is here: https://bugzilla.redhat.com/show_bug.cgi?id=565676 The conflict is because the docs are generated during the build, and the files, even though they are installed in the same location, differ. Splitting the docs to a separate (noarch) sub-package is a commonly used, simple and sane solution. - Panu - -- 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: Handling package conflicts caused by arch specific doc files
On Wed, Jul 2, 2014 at 5:01 PM, Kalev Lember kalevlem...@gmail.com wrote: On 07/02/2014 03:15 PM, Ankur Sinha wrote: I was wondering if there's a standard way of solving package conflicts that arise from arch specific doc files. An example is here: https://bugzilla.redhat.com/show_bug.cgi?id=565676 The conflict is because the docs are generated during the build, and the files, even though they are installed in the same location, differ. My personal take on this is that multilibbed -devel packages are rarely tested and largely useless. Most people use mock (or some other chroot mechanism or a VM) for building 32 bit packages on 64 bit hosts instead. Where is the data that backs up the most people claim. -devel packages are also used to build stuff locally there are not only for rpms (and even in the rpm case using local builds is way more convient then using mock or even a VM *sigh*). Multilibbing libs makes a lot of sense, but -devel packages, not so much. I wonder how many users would miss this if we were to blacklist all -devel packages in mash. Anyway, having said that, I've hopefully now fixed it in libchamplain-0.12.8-1.fc21 build. That's what we should do ... fix bugs and not just use the big hammer because some package had a bug. -- 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: Handling package conflicts caused by arch specific doc files
Am 03.07.2014 12:56, schrieb drago01: On Wed, Jul 2, 2014 at 5:01 PM, Kalev Lember kalevlem...@gmail.com wrote: On 07/02/2014 03:15 PM, Ankur Sinha wrote: I was wondering if there's a standard way of solving package conflicts that arise from arch specific doc files. An example is here: https://bugzilla.redhat.com/show_bug.cgi?id=565676 The conflict is because the docs are generated during the build, and the files, even though they are installed in the same location, differ. My personal take on this is that multilibbed -devel packages are rarely tested and largely useless. Most people use mock (or some other chroot mechanism or a VM) for building 32 bit packages on 64 bit hosts instead. Where is the data that backs up the most people claim. -devel packages are also used to build stuff locally there are not only for rpms (and even in the rpm case using local builds is way more convient then using mock or even a VM *sigh*) correct, see below, a dedicated virtual machine only for building RPM packages which is the core of my admin work over the last 6 years to override server packages with my own ones, build packages with my own ones as well as do major upgrades seperated from dist-upgrades the opposite is true: most ordinary people don't use mock [builduser@buildserver64:~]$ ls -R /home/builduser/rpmbuild/ /home/builduser/rpmbuild/: total 80K drwxr-xr-x 2 builduser builduser 4.0K 2014-07-02 22:44 BUILD drwx-- 2 builduser builduser 4.0K 2014-07-02 22:41 BUILDROOT drwxrwxr-x 4 builduser builduser 4.0K 2013-02-25 12:46 RPMS drwxrwxr-x 2 builduser builduser 24K 2014-07-02 21:30 SOURCES drwxrwxr-x 2 builduser builduser 12K 2014-07-02 22:41 SPECS drwxrwxr-x 4 builduser builduser 20K 2014-07-02 22:42 SRPMS drwxrwxr-x 2 builduser builduser 4.0K 2012-09-13 14:42 TMP drwxr-xr-x 2 builduser builduser 4.0K 2014-06-29 13:04 rebuild -rw-rw-r-- 1 builduser builduser0 2014-05-03 00:31 build-php.log /home/builduser/rpmbuild/BUILD: total 0 /home/builduser/rpmbuild/BUILDROOT: total 0 /home/builduser/rpmbuild/RPMS: total 44K drwxr-xr-x 2 builduser builduser 4.0K 2014-06-30 17:09 noarch drwxr-xr-x 2 builduser builduser 36K 2014-07-02 22:44 x86_64 /home/builduser/rpmbuild/RPMS/noarch: total 0 /home/builduser/rpmbuild/RPMS/x86_64: total 0 /home/builduser/rpmbuild/SOURCES: total 128M -rwxr-xr-x 1 builduser builduser 1.7K 2014-01-08 06:46 mysqld-wait-ready -rw-r- 1 builduser builduser 105K 2013-06-28 01:11 aespipe-v2.4c.tar.bz2 -rw-r- 1 builduser builduser 799K 2014-04-19 14:06 apr-1.5.1.tar.bz2 -rw-r- 1 builduser builduser 680K 2013-11-26 22:36 apr-util-1.5.3.tar.bz2 -rw-r- 1 builduser builduser 1.6M 2014-04-14 02:24 cantata-1.3.4.tar.bz2 -rw-r- 1 builduser builduser 2.2M 2014-06-15 18:56 dbmail-8a042214ae1d120581740020f4e73c3cf8d3a6c0.tar.bz2 -rw-rw-r-- 1 builduser builduser 6.4M 2014-06-23 18:14 ffmpeg-2.1.5.tar.bz2 -rw-r- 1 builduser builduser 6.7M 2014-06-24 16:33 ffmpeg-20140624.tar.bz2 -rw-r- 1 builduser builduser 4.8M 2014-03-13 18:59 httpd-2.4.9.tar.bz2 -rw-r- 1 builduser builduser 102K 2013-06-28 01:11 iat-0.1.7.tar.bz2 -rw-r- 1 builduser builduser 115K 2013-06-28 01:11 mpdscribble-0.22.tar.bz2 -rw-r- 1 builduser builduser 13M 2014-06-26 21:37 php-5.5.14.tar.bz2 -rw-r- 1 builduser builduser 477K 2013-06-28 01:11 pure-ftpd-1.0.36.tar.bz2 -rw-r- 1 builduser builduser 113K 2013-12-23 02:00 squirrelmail-20131222_0201-SVN.imap_proxy.tar.bz2 -rw-r- 1 builduser builduser 7.1M 2014-06-24 15:50 trafficserver-5.0.0.tar.bz2 -rw-r- 1 builduser builduser 621K 2014-05-22 11:52 x264-20140522.tar.bz2 -rw-r- 1 builduser builduser 819 2014-05-12 21:12 zram-1.0.1.tar.bz2 -rw-r- 1 builduser builduser 2.9K 2011-04-20 20:05 fsync-tester.c -rw-r--r-- 1 builduser builduser 35 2013-07-23 19:29 openvpn-tmpfile.conf -rw-r--r-- 1 builduser builduser 76 2013-06-28 01:11 postfix-pam.conf -rw-r--r-- 1 builduser builduser 2.1K 2013-06-28 01:11 pulsed-daemon.conf -rw-r--r-- 1 builduser builduser 820 2013-06-28 01:11 roadwarrior-client.conf -rw-r--r-- 1 builduser builduser 1.5K 2013-06-28 01:11 roadwarrior-server.conf -rw-r--r-- 1 builduser builduser 2.9K 2013-06-28 01:11 vnstat.conf -rw-r--r-- 1 builduser builduser 133 2013-06-28 01:11 dbmail.cron -rw-r--r-- 1 builduser builduser 80 2013-06-28 01:11 hylafax_daily.cron -rw-r--r-- 1 builduser builduser 39 2013-06-28 01:11 hylafax_hourly.cron -rw-r--r-- 1 builduser builduser 4.9K 2014-05-08 15:17 phpMyAdmin.custom.css -rw-r--r-- 1 builduser builduser 35 2013-07-23 19:26 dbmail.tmpfiles.d -rw-r--r-- 1 builduser builduser 33 2013-07-23 19:26 mysql.tmpfiles.d -rw-r--r-- 1 builduser builduser 39 2013-06-28 01:11 vnstat.tmpfiles.d -rw-r- 1 builduser builduser 21K 2013-06-28 01:11 Class-Std-Fast-v0.0.8.tar.gz -rw-r- 1 builduser builduser 706K 2013-12-26 19:26 GeoIP-1.6.0.tar.gz -rw-r- 1 builduser builduser 19K 2013-08-24 10:56 IO-Socket-INET6-2.71.tar.gz -rw-r- 1
Re: Handling package conflicts caused by arch specific doc files
On 07/03/2014 01:05 PM, Reindl Harald wrote: /home/builduser/rpmbuild/RPMS: total 44K drwxr-xr-x 2 builduser builduser 4.0K 2014-06-30 17:09 noarch drwxr-xr-x 2 builduser builduser 36K 2014-07-02 22:44 x86_64 Thanks, this actually backs up what I claimed -- that it's uncommon to build i686 packages on an x86_64 host. You only have an x86_64 directory here. Out of curiosity, I know you are administering a number of systems -- do you only have x86_64 installations or do you use a different host for building i686 packages? -- Thanks, Kalev -- 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: Review swaps
On Wed, 2014-07-02 at 12:56 +0800, Christopher Meng wrote: Swap ZODB, sphinx-rtd-theme and BTrees with 1. osh - V6 Thompson Shell Port https://bugzilla.redhat.com/show_bug.cgi?id=1115121 2. zsh-lovers - A collection of tips, tricks and examples for the Z shell (This package is pretty easy as it only contains a manpage) https://bugzilla.redhat.com/show_bug.cgi?id=1115122 3. vinterm - Vintage-style terminal emulator https://bugzilla.redhat.com/show_bug.cgi?id=1098950 Thanks. Yours sincerely, Christopher Meng Noob here. http://cicku.me Hi Christopher, I grabbed the zsh-lovers for a formal review. 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
Re: Review swaps
On Thu, Jul 3, 2014 at 7:24 PM, Jason Taylor jason.tay...@secure-24.com wrote: Hi Christopher, I grabbed the zsh-lovers for a formal review. Thank you. Yours sincerely, Christopher Meng Noob here. http://cicku.me -- 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: dnf-0.5.3 and dnf-core-plugins-0.1.1 released
On 07/03/2014 12:04 PM, Reindl Harald wrote: dnf remove python ends in remove dnf and yum too as weel as dnf remove kernel still offers to remove both protected_packages.py is missing from the package. Looks like an upstream bug - it's not referenced in plugins/CMakeLists.txt Michal -- 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: Handling package conflicts caused by arch specific doc files
On Thu, Jul 3, 2014 at 1:20 PM, Kalev Lember kalevlem...@gmail.com wrote: On 07/03/2014 01:05 PM, Reindl Harald wrote: /home/builduser/rpmbuild/RPMS: total 44K drwxr-xr-x 2 builduser builduser 4.0K 2014-06-30 17:09 noarch drwxr-xr-x 2 builduser builduser 36K 2014-07-02 22:44 x86_64 Thanks, this actually backs up what I claimed -- that it's uncommon to build i686 packages on an x86_64 host. You only have an x86_64 directory here. Again -devel packages are not only used / useful for building rpms. -- 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: Handling package conflicts caused by arch specific doc files
Am 03.07.2014 13:20, schrieb Kalev Lember: On 07/03/2014 01:05 PM, Reindl Harald wrote: /home/builduser/rpmbuild/RPMS: total 44K drwxr-xr-x 2 builduser builduser 4.0K 2014-06-30 17:09 noarch drwxr-xr-x 2 builduser builduser 36K 2014-07-02 22:44 x86_64 Thanks, this actually backs up what I claimed -- that it's uncommon to build i686 packages on an x86_64 host. You only have an x86_64 directory here. that is indeed true, a samll build-VM with only i686 is more comfortable / less error prone than cross-building Out of curiosity, I know you are administering a number of systems -- do you only have x86_64 installations or do you use a different host for building i686 packages? until 2011 i had a buildserver32.vmware.local to feed my notebook with the exact same configuration and a sync-script, finally all packages are grabbed from another host providing repos now only x86_64 and luckily the oldest CPU to support is SandyBridge, hence the 1:1 rebuilds of some packages which are not modified from the src.rpm in /home/builduser/rpmbuild/rebuild optflags: x86_64 -m64 -O2 -march=corei7-avx -mtune=corei7-avx -fopenmp -mmmx -msse2 -msse3 -msse4.1 -msse4.2 -mavx -maes -mfpmath=sse -pipe -fomit-frame-pointer -finline-functions -finline-limit=60 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 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: Handling package conflicts caused by arch specific doc files
Am 03.07.2014 13:33, schrieb drago01: On Thu, Jul 3, 2014 at 1:20 PM, Kalev Lember kalevlem...@gmail.com wrote: On 07/03/2014 01:05 PM, Reindl Harald wrote: /home/builduser/rpmbuild/RPMS: total 44K drwxr-xr-x 2 builduser builduser 4.0K 2014-06-30 17:09 noarch drwxr-xr-x 2 builduser builduser 36K 2014-07-02 22:44 x86_64 Thanks, this actually backs up what I claimed -- that it's uncommon to build i686 packages on an x86_64 host. You only have an x86_64 directory here. Again -devel packages are not only used / useful for building rpms that's true but usually you don't ./configure make make install for a i686 binary on a x86_64 machine since it's anyways a local build 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: dnf-0.5.3 and dnf-core-plugins-0.1.1 released
Am 03.07.2014 13:32, schrieb Michal Schmidt: On 07/03/2014 12:04 PM, Reindl Harald wrote: dnf remove python ends in remove dnf and yum too as weel as dnf remove kernel still offers to remove both protected_packages.py is missing from the package. Looks like an upstream bug - it's not referenced in plugins/CMakeLists.txt thanks for feedback, does it need a bugreport or can we assume since the thread is started by the upstream maintainer it get fixed anyways? BTW: how do we handle the protection for systemd which is in case of YUM provided by the systemd package but DNF is not mandatory in F21 - so /etc/dnf/protected.d/ is only conditional available rpm -q --file /etc/yum/protected.d/systemd.conf systemd-208-19.fc20.x86_64 cat /etc/yum/protected.d/systemd.conf systemd 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: Handling package conflicts caused by arch specific doc files
On Thu, Jul 3, 2014 at 1:37 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 03.07.2014 13:33, schrieb drago01: On Thu, Jul 3, 2014 at 1:20 PM, Kalev Lember kalevlem...@gmail.com wrote: On 07/03/2014 01:05 PM, Reindl Harald wrote: /home/builduser/rpmbuild/RPMS: total 44K drwxr-xr-x 2 builduser builduser 4.0K 2014-06-30 17:09 noarch drwxr-xr-x 2 builduser builduser 36K 2014-07-02 22:44 x86_64 Thanks, this actually backs up what I claimed -- that it's uncommon to build i686 packages on an x86_64 host. You only have an x86_64 directory here. Again -devel packages are not only used / useful for building rpms that's true but usually you don't ./configure make make install for a i686 binary on a x86_64 machine since it's anyways a local build Skip the make install part ... Also sometimes I do write code myself that for whatever reason I have to give out as 32bit binary ... which requires -devel packages when a library is used. -- 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: dnf-0.5.3 and dnf-core-plugins-0.1.1 released
On 07/03/2014 01:32 PM, Michal Schmidt wrote: protected_packages.py is missing from the package. Looks like an upstream bug - it's not referenced in plugins/CMakeLists.txt Michal Thanks for the notice, should be good now: http://koji.fedoraproject.org/koji/taskinfo?taskID=7103767 Ales -- 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: request for pygrib packaging debug help
Robert, Bohuslav,
Thanks a lot!
I've been staring at this for a long time, but sometimes you just don't
notice your own silly mistakes...
Best regards,
Jos
On 07/03/2014 12:27 PM, Robert Kuska wrote:
- Original Message -
From: Jos de Kloe josdek...@gmail.com
To: Development discussions related to Fedora
devel@lists.fedoraproject.org
Sent: Thursday, 3 July, 2014 12:07:28 PM
Subject: request for pygrib packaging debug help
Hi everyone,
I am having a small issue with the pygrib package that I am maintaining.
The package depends on pyproj, but when I install it with yum it also
pulls in python3-pyproj.
All python3 related things are wrapped in %if 0%{?with_python3}
macros, so this should not happen I think.
Clearly I am overlooking some dependency issue in my spec file.
Any help would be appreciated.
Best regards,
Jos de Kloe
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
You must move Python 3 Requires into Python 3 subpackage
between lines 89 and 101 in your specfile.
Regards,
Robert Kuska
-
rkuska @
#fedora-devel on freenode
#brno #gulag #software-collections on brq.redhat
--
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: dnf-0.5.3 and dnf-core-plugins-0.1.1 released
Am 03.07.2014 14:09, schrieb Ales Kozumplik: On 07/03/2014 01:32 PM, Michal Schmidt wrote: protected_packages.py is missing from the package. Looks like an upstream bug - it's not referenced in plugins/CMakeLists.txt Michal Thanks for the notice, should be good now: http://koji.fedoraproject.org/koji/taskinfo?taskID=7103767 confirmed - thanks! in case of kernel the behavior of YUM just skip the running one but remove all others is more appealing, however the really important thing not destroy the complete system by mistake is achieved [root@rawhide ~]# dnf remove python Dependencies resolved. Error: The operation would result in removing the following protected packages: dnf. [root@rawhide ~]# dnf remove kernel Dependencies resolved. Error: The operation would result in removing the booted kernel: kernel-core-3.16.0-0.rc3.git2.1.fc21.x86_64. [root@rawhide ~]# yum remove kernel Skipping the running kernel: kernel-core-3.16.0-0.rc3.git2.1.fc21.x86_64 Resolving Dependencies -- Running transaction check --- Package kernel-core.x86_64 0:3.16.0-0.rc3.git1.1.fc21 will be erased -- Finished Dependency Resolution -- Finding unneeded leftover dependencies Found and removing 0 unneeded dependencies Dependencies Resolved === Package Arch Version Repository Size === Removing: kernel-core x86_64 3.16.0-0.rc3.git1.1.fc21 installed 41 M Transaction Summary === Remove 1 Package Installed size: 41 M Is this ok [y/N]: 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: Handling package conflicts caused by arch specific doc files
Panu Matilainen wrote: On 07/02/2014 04:15 PM, Ankur Sinha wrote: Hi, I was wondering if there's a standard way of solving package conflicts that arise from arch specific doc files. An example is here: https://bugzilla.redhat.com/show_bug.cgi?id=565676 The conflict is because the docs are generated during the build, and the files, even though they are installed in the same location, differ. Splitting the docs to a separate (noarch) sub-package is a commonly used, simple and sane solution. And, will catch errors like this automatically, since koji enforces that noarch content be identical on all archs. -- 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
defining firewalld services
I'm looking into providing a predefined firewalld service definition for
kde-connect, per
https://bugzilla.redhat.com/show_bug.cgi?id=1115547
Looks like it's as easy as dropping an xml snippet into
/usr/lib/firewalld/services/
I'm also noticing currently that the only package besides fallwalld itself
doing this is cockpit, which includes a %post scriptlet:
# firewalld only partially picks up changes to its services files
# without this
test -f %{_bindir}/firewall-cmd firewall-cmd --reload --quiet || true
Is this the recommended approach? If so, I'll follow this lead, and maybe
start work on drafting some packaging guidelines.
-- 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
Introducing Python 3.5 nightly builds for Fedora
Hi everybody, I'd like to introduce a new project of Slavek Kabrda and mine: Copr repository with nightly builds of development version of Python 3. http://copr.fedoraproject.org/coprs/churchyard/python3-nightly/ How does it work? = Each night, at 00:01 CET/CEST, dgroc [1] is run and checks out if any of the following upstream projects has some new commits in master/default branch: * cpython * setuptools * pip * wheel If so, it creates SRPM with code from that specific new commit and builds it in the copr repository. Is is being built as a software collection, not to break system python3 package (that being in critpath once Python 3 will be the default). Benefits This will let us know immediately when our patches of Python 3 package are broken. We can react when that happens a we know exactly what commit (or at lest what day) broke it. This will avoid a big fix all the patches spree once Python 3.5 is stable and hits Fedora. The builds also run the test suite, so we can see regressions when they happen and we can communicate with Python upstream fast and flexible (again, instead of a mass failure once Python 3.5 hits Fedora). It also let us and you to test if your packages build and run with Python 3.5, so we can avoid more confusion once Python 3.5... you see what I mean. Other than the packaging reasons: Fedora might attract Python enthusiasts and developers as it is most likely the only Linux distro that has development version of Python packaged nightly. Developers and powerusers can play with new features committed yesterday just by doing `dnf update`. How to use it = Ad the repository (with dnf copr plugin, or manually), and install python35 package. That installs the software collection and you can use it as any other software collection: $ scl enable python35 python Or $ scl enable python35 bash You can also install packages from PyPI: # scl enable python35 bash # pip install ipython How to (test)build my package against Python 3.5 If you want to build your package against Python 3.5, you can do it in the following way: 1. Update the spec by adding SCL related macros, see [2][3] 2. In mock or Copr, add the repository and add the following packages to the chroot: scl-utils-build python35-build [4][5] 3. Build and profit [1] https://github.com/pypingou/dgroc [2] http://docs.fedoraproject.org/en-US/Fedora_Contributor_Documentation/1/html/Software_Collections_Guide/sect-Converting_a_Conventional_Spec_File.html [3] https://bitbucket.org/bkabrda/spec2scl/ [4] https://lists.fedorahosted.org/pipermail/softwarecollections/2012-November/18.html [5] http://mmaslano.livejournal.com/9668.html -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok -- 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-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/03/2014 01:42 AM, William wrote: On Wed, 2014-07-02 at 20:40 -0700, Samuel Sieb wrote: On 07/02/2014 06:55 PM, William wrote: First of all, I'd like to formally propose that each of the products will have a fedora-release-$PRODUCT (and corresponding generic-release-$PRODUCT) package. This package will meet several needs (with magical hand-waving in this initial email). How will this work with fedup from 20 to 21? Will there be multiple upgrade targets? Why would that be necessary? All packages are in one repository, so fedora-release-$PRODUCT will be upgraded to the next version and everything will be fine. My machine doesn't currently have a fedora-release-$PRODUCT package installed. So how will fedup work out what one to put on my system? Will these packages be added to 20, and the user need to preinstall before fedup? It won't put one on your system. Upgrades from a non-Productized Fedora will remain non-Productized. It's not *less* Fedora than before. The Products are basically a statement that this minimal set of packages and services are available on the system. A non-productized Fedora install is essentially just a continuation of the classic do-it-yourself approach that Fedora has been up to this point. I hope that clarifies things for you. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlO1YTIACgkQeiVVYja6o6OKuwCgsetv/Dr3umWKlCLvgEeqIJat i30An3NCXXVeYe6K5iEYhEWe1yPjhor0 =mBtM -END PGP 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: [fedora-arm] Fedora ARM Status Meeting Minutes - 2014-07-02
* 1) Kernel Status Update (pwhalen, 20:07:46) * Peter's '3.15 Fedora ARM kernel status' (pwhalen, 20:08:13) * LINK: http://nullr0ute.com/2014/06/3-15-fedora-arm-kernel-status/ (pwhalen, 20:08:13) The beaglebone patchset was rebased for this release so please test. * kernel testing needed on Utilite (pwhalen, 20:10:03) The first revision of this patch adds support for MMC/sata/serial and one of the NICs via device tree. I plan to evolve it over the coming weeks. * 2b) F21 Alpha Status - Open ARM bugs (pwhalen, 20:20:43) * dracut unable to boot 3.16 most of the time (pwhalen, 20:21:57) This should in theory be fixed with the latest util-linux. Please test! * 2c) F21 Alpha Status - Other Planning ? (pwhalen, 20:30:42) * 3) Aarch64 Status update (pwhalen, 20:34:43) * The v8 package isn't built, blocking some packages. A v8 port for aarch64 is available however. Investigation ongoing. (bconoboy, 20:40:59) The issue with v8 is we're stuck on 3.14.x due to nodejs, mongodb and possibly chromium. Aarch64 support was added upstream in a much later release, 3.25.x I believe. Not sure if there's plans to rebase at some point. * kernel-3.16.0-0.rc3.git1.1.fc21 should have all patches needed to boot on mustang board (bconoboy, 20:41:29) And in theory AMD Seattle if you're lucky enough to have such as device * If you want to make changes in packages for arm related things, that's awesome. but please coordinate with the arm team. Please do so by cc'ing the arm list on discussions and patches amd block the arm tracker for bugs. (pwhalen, 20:52:02) YES!! This has caused us a quite a bit of heartache and me and others a lot of time because people focus on their individual device and now how it impacts ARM as a whole. Peter -- 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-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On Thu, Jul 3, 2014 at 9:57 AM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/03/2014 01:42 AM, William wrote: On Wed, 2014-07-02 at 20:40 -0700, Samuel Sieb wrote: On 07/02/2014 06:55 PM, William wrote: First of all, I'd like to formally propose that each of the products will have a fedora-release-$PRODUCT (and corresponding generic-release-$PRODUCT) package. This package will meet several needs (with magical hand-waving in this initial email). How will this work with fedup from 20 to 21? Will there be multiple upgrade targets? Why would that be necessary? All packages are in one repository, so fedora-release-$PRODUCT will be upgraded to the next version and everything will be fine. My machine doesn't currently have a fedora-release-$PRODUCT package installed. So how will fedup work out what one to put on my system? Will these packages be added to 20, and the user need to preinstall before fedup? It won't put one on your system. Upgrades from a non-Productized Fedora will remain non-Productized. It's not *less* Fedora than before. The Products are basically a statement that this minimal set of packages and services are available on the system. A non-productized Fedora install is essentially just a continuation of the classic do-it-yourself approach that Fedora has been up to this point. That's misleading. Fedora hasn't been releasing do-it-yourself releases. Our previous install images were composed and tested by QA, including testing fedup upgrades from the previous release. With Fedora.next, we don't have an install image that is an equivalent of = F20. Perhaps I have missed them, but I've seen no discussion or plans around testing upgrades to F21 from F20. Unless the Products intend to test upgrading from F20, and/or QA intends to somehow test fedup from F20 to F21 in a non-product manner, we're essentially changing the semantics of upgrades. I agree it should still work, but saying it's a continuation of existing practice when it isn't is wrong. josh -- 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: Review swaps
On Wed, Jul 02, 2014 at 12:56:48PM +0800, Christopher Meng wrote: Swap ZODB, sphinx-rtd-theme and BTrees with 1. osh - V6 Thompson Shell Port https://bugzilla.redhat.com/show_bug.cgi?id=1115121 I'll take it. -- Regards,-- Sir Raorn. --- https://plus.google.com/+AlexeyFroloff pgp3P6b8AgZmr.pgp Description: PGP 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: Review swaps
On Thu, Jul 3, 2014 at 10:36 PM, Alexey I. Froloff ra...@raorn.name wrote: On Wed, Jul 02, 2014 at 12:56:48PM +0800, Christopher Meng wrote: Swap ZODB, sphinx-rtd-theme and BTrees with 1. osh - V6 Thompson Shell Port https://bugzilla.redhat.com/show_bug.cgi?id=1115121 I'll take it. Thank you. One thing forgot to mention in the spec is the /etc/shells file, I will address this later. Just give the initial version a try ;) Yours sincerely, Christopher Meng Noob here. http://cicku.me -- 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: Koschei - continuous rebuilds for packages
Hi Michael, Detecting soname bumps and doing real rebuilds instead of scratch build should be possible. Koschei could automatically start rebuilding dependent packages AFTER you update the library in rawhide. That's the goal. But if you want to know what will break before you do the update then it will be more complicated, because Koschei will need to manage separate Koji tags and obviously first get permission to do so and I'm not sure whether relengs would be willing to make this happen. That would be convenient - at least for critical-path packages. Anyway, lets ask lkocman (CC) about Koji tags. And for both solutions Koschei would need to get provenpackager-like priviledges to be able to bump the release. Regarding remote interface - there is none, but I can make it as soon as it's needed. I didn't have use case for it yet. Great to hear it. Thank you. Kind regards, -- Jan Pacner -- 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: dnf-0.5.3 and dnf-core-plugins-0.1.1 released
On 07/03/2014 01:45 PM, Reindl Harald wrote: BTW: how do we handle the protection for systemd which is in case of YUM provided by the systemd package but DNF is not mandatory in F21 - so /etc/dnf/protected.d/ is only conditional available The dnf plugins looks at /etc/yum/protected.d/ too, so we can just leave systemd's dropin file where it is now. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rpmbuild w2.xzdio and multithreading
is there any way to set the two options below in .rpmmacros to use multi-threading? the shell-script below works in case of tar but XZ_OPT env is ignored by rpmbuild and seeking two hours the internet don't give any answer in case of tar --threads=0 improves performance dramatically on a modern CPU most of the time with a lot of idle cores %_binary_payload w2.xzdio %_source_payload w2.xzdio __ #!/bin/bash export XZ_OPT=-2 --threads=0 /usr/bin/nice -n 19 /usr/bin/tar -p -cJf $1.tar.xz $1 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: defining firewalld services
On 03.07.2014 15:39, Rex Dieter wrote:
I'm looking into providing a predefined firewalld service definition for
kde-connect, per
https://bugzilla.redhat.com/show_bug.cgi?id=1115547
Looks like it's as easy as dropping an xml snippet into
/usr/lib/firewalld/services/
I'm also noticing currently that the only package besides fallwalld itself
doing this is cockpit, which includes a %post scriptlet:
# firewalld only partially picks up changes to its services files
# without this
test -f %{_bindir}/firewall-cmd firewall-cmd --reload --quiet || true
Is this the recommended approach? If so, I'll follow this lead, and maybe
start work on drafting some packaging guidelines.
Thomas Woerner would be the one to work out those guidelines.
But to explain ... apparently there are two firewalld environments.
When you install a service file it only affects the installed
environment (used after a reboot) and not the current runtime environment.
This means that a user can't immediately use your service definition in
a command like:
$ firewall-cmd --add-service=cockpit
The command:
$ firewall-cmd --reload
... makes newly installed service files available in the runtime
environment. I guess this is sorta analogous to 'systemctl daemon-reload'.
Stef
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
mock error in koji: No such file or directory: '%{buildroot}/etc/mtab'
A koji rawhide build [1] just failed with: INFO: Mock Version: 1.1.39 Start: chroot ['fedpkg', 'sources'] Start: device setup Finish: device setup Finish: chroot ['fedpkg', 'sources'] ERROR: [Errno 2] No such file or directory: '/var/lib/mock/f21-build-2179813-398918/root/etc/mtab' Traceback (most recent call last): File /usr/sbin/mock, line 306, in module def do_buildsrpm(config_opts, chroot, options, args): File /usr/sbin/mock, line 579, in main chroot.chroot(args, options) File /usr/lib/python2.7/site-packages/mockbuild/backend.py, line 832, in chroot self._setupFiles() File peak.util.decorators.rewrap wrapping mockbuild.backend._setupFiles at 0x01FED050, line 3, in _setupFiles def _setupFiles(self): return __decorated(self) File /usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py, line 70, in trace result = func(*args, **kw) File /usr/lib/python2.7/site-packages/mockbuild/backend.py, line 552, in _setupFiles mockbuild.util.touch(item) File peak.util.decorators.rewrap wrapping mockbuild.util.touch at 0x01FA7B18, line 3, in touch def touch(fileName): return __decorated(fileName) File /usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py, line 70, in trace result = func(*args, **kw) File /usr/lib/python2.7/site-packages/mockbuild/util.py, line 77, in touch fo = open(fileName, 'w') IOError: [Errno 2] No such file or directory: '/var/lib/mock/f21-build-2179813-398918/root/etc/mtab' It might have something to do with yesterday's util-linux update in rawhide? [2] But /etc/mtab still shows up on that build's filelist in koji, so I'm not sure why it's missing in the buildroot. Thanks! -T.C. [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=7105815 [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=541536 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] July 2014 Rawhide validation matrices are up!
Hey folks! Just a note that we've put up the validation matrices for July 2014. Thanks to satellit for the reminder, and to roshi for creating the Install page - I've just added the Base page, and sent out this reminder. https://fedoraproject.org/wiki/Test_Results:Fedora_21_Rawhide_2014_07_Install https://fedoraproject.org/wiki/Test_Results:Fedora_21_Rawhide_2014_07_Base please enter results from Rawhide testing during July in these pages, not the 2014_05 or 2014_06 ones. Those are archived for posterity now. :) In case anyone needs a refresher on this testing - https://lists.fedoraproject.org/pipermail/test/2014-April/120792.html , https://lists.fedoraproject.org/pipermail/test/2014-April/120931.html . I've transferred the 201406 results folks had put in the 201405 pages across. This should be the last month we use this setup, as we should start rolling Alpha TCs soon...eep! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-release-$PRODUCT, /etc/issue, /etc/os-release, Per-Product Configs and more!
On Mon, Jun 30, 2014 at 11:14:52PM +0200, Lennart Poettering wrote: In a sense, there's a certain amount of this definition that every Fedora install will have. The Products then add to this definition. A basic piece of it is mandatory, but the outer edges are add-ons. I am not sure this is really what /etc/os-release is for. It's for declaring operating system names and versions, not really for containing a list of packages you have installed. We're not (ultimately, at least), just talking about a list of packages. It is like a sub-version of the operating system. A flavor, perhaps. Using a different ID and ID_LIKE=fedora seems a) far too heavy and b) expressive of a much larger difference. I *do* like that you're planning to move this to /usr/lib. It never made sense to me as _configuration_. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- 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: PostgreSQL systemd config scheme change
On Mon, 23.06.14 16:23, Pavel Raiskup (prais...@redhat.com) wrote: Hello all, there is currently not so much things to configure in PostgreSQL from systemd's service point of view (not taking postgresql.conf into account), concretely, we configure PGPORT and PGDATA, from which the later is important (and often re-configured to point e.g. to some dedicated mount point, etc.). That tells systemd's unit file where it should start PostgreSQL server from. What does not seem to be quite 100% OK is that, when user wants to change PGDATA, we instruct him to make a separate service file: $ cat /etc/systemd/system/postgresql.service .include /usr/lib/systemd/system/postgresql.service Please migrate away from .include, please use .d/ drop-ins instead. We kinda are deprecating .include, only support it for compatibility instead. [Service] Environment=PGDATA=/some/other/place/than/default This works OK -- but the problem is that it is quite too much for just changing one simple directory path. What seems to be better approach is to have real configuration file, such one for which '$ rpm -qc postgresql-server' would not be quiet. Lets say: $ cat /etc/postgresql/postgresql PGDATA=/some/other/place/than/default With some additional packager's work, that allows us to do yet another configuration easily - and that is multiple PostgreSQL running on one single machine (on different ports or IPs). The only thing would be to create yet another file: $ cat /etc/postgresql/postgresql@com_example PGDATA=/some/path/pg/com_example PGPORT=@SOMEPORT@ $ systemctl start postgresql@com_example Would you see something bad on that approach (please, take into account that we would not stop supporting the old way, we just want to make future configuration easier and straight-forward). Unit files are configuration files. It's OK to copy unit files from /usr/lib/systemd/system into /etc/systemd/system and edit it there. I'd always advise against inventing addition configuration files that are neither the daemons own, nor systemd's. Lennart -- Lennart Poettering, Red Hat -- 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: mock error in koji: No such file or directory: '%{buildroot}/etc/mtab'
On Thu, 3 Jul 2014 14:26:04 -0700 T.C. Hollingsworth tchollingswo...@gmail.com wrote: A koji rawhide build [1] just failed with: ...snip... It might have something to do with yesterday's util-linux update in rawhide? [2] But /etc/mtab still shows up on that build's filelist in koji, so I'm not sure why it's missing in the buildroot. Nope. This is due to the just landed systemd in the buildroot. I have just untagged it, as soon as the buildroot regenerates it should be back to normal. I've filed: https://bugzilla.redhat.com/show_bug.cgi?id=1116158 to get this sorted out. kevin signature.asc Description: PGP 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: PostgreSQL systemd config scheme change
On Thu, 03.07.14 19:11, Tom Lane (t...@sss.pgh.pa.us) wrote: Lennart Poettering mzerq...@0pointer.de writes: Please migrate away from .include, please use .d/ drop-ins instead. We kinda are deprecating .include, only support it for compatibility instead. ... Unit files are configuration files. It's OK to copy unit files from /usr/lib/systemd/system into /etc/systemd/system and edit it there. FWIW, I don't think that's OK at all, and that's what I tried to avoid in the original layout for Postgres' systemd files. If people create the files for secondary postmasters by cloning the entire unit file, then there is no way for us to push out fixes in the unit file; or at least none that doesn't break secondary servers. If unit files tended to be trivial two-line affairs, this concern might not have much force, but they're generally not. Certainly the Postgres one isn't. Link? Are you sure that you didn't make them this complex because you wanted to not simply allow people to copy them? So I think deprecation of .include is *seriously* misguided. We really need a way to create secondary-server unit files that don't contain anything more than alternate PGPORT and PGDATA settings plus an inclusion of a master unit file. (I'll grant that there might be other ways to mechanize such a behavior, but if you're telling me I don't need this, you're mistaken, sir.) Well, the .include stuff is awful, since it's incredible hard to figure out when they are out of date, and whether there are loops in the include chain. The .d/ drop-ins don't suffer by the problem. Also note that we do provide template units, for the cases where people want to run multiple instances. You can even mix .d and template units: postgresql@foobar.service postgresql@foobar.service/addition.conf postgresql@waldo.service postgresql@waldo.service/extension.conf And so on... Lennart -- Lennart Poettering, Red Hat -- 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: Introducing Python 3.5 nightly builds for Fedora
On Thu, Jul 03, 2014 at 03:55:51PM +0200, Miro Hrončok wrote: Other than the packaging reasons: Fedora might attract Python enthusiasts and developers as it is most likely the only Linux distro that has development version of Python packaged nightly. Developers and powerusers can play with new features committed yesterday just by doing `dnf update`. Hi, looks like something I might use for development of Python software. But for this to be truly useful, I'd need a bunch of stuff on top, at least numpy/scipy, but also pytables, matplotlib. Without that it would be even hard to test building of packages, since they often depend on those modules (and others of course). Is there any chance you could add cascaded builds of the most popular extensions? 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
[Bug 1112609] perl-PPI-Tester-0.15-3.fc21 FTBFS: %check phase fails because of Xvfb
https://bugzilla.redhat.com/show_bug.cgi?id=1112609 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||xorg-x11-server-1.15.99.903 ||-3.fc21 Resolution|--- |RAWHIDE Last Closed||2014-07-03 02:48:56 -- 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=T2FgNCKyYaa=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 1112571] perl-Gtk3-WebKit-0.06-2.fc21 FTBFS:
https://bugzilla.redhat.com/show_bug.cgi?id=1112571 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||xorg-x11-server-1.15.99.903 ||-3.fc21 Resolution|--- |RAWHIDE Last Closed||2014-07-03 03:21:19 -- 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=PhPiN6OIU8a=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 1115913] New: Can't call method get_value on an undefined value at /bin/mimeopen line 162
https://bugzilla.redhat.com/show_bug.cgi?id=1115913 Bug ID: 1115913 Summary: Can't call method get_value on an undefined value at /bin/mimeopen line 162 Product: Fedora Version: 20 Component: perl-File-MimeInfo Severity: low Assignee: jples...@redhat.com Reporter: gree...@greenrd.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, ktdre...@ktdreyer.com, perl-devel@lists.fedoraproject.org, pertu...@free.fr Description of problem: When I opened a PNG file from the command line using xdg-open, I got this error message. Version-Release number of selected component (if applicable): perl-File-MimeInfo-0.17-2.fc20.noarch How reproducible: Always Steps to Reproduce: 1. xdg-open some.png Actual results: File opens in Firefox; however, error message is shown in terminal. Expected results: No error message -- 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=cyE2eTN4Lha=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 1055054] segfault when running example from manual page
https://bugzilla.redhat.com/show_bug.cgi?id=1055054 Christopher Meng i...@cicku.me changed: What|Removed |Added CC||jples...@redhat.com, ||mmasl...@redhat.com, ||perl-devel@lists.fedoraproj ||ect.org, psab...@redhat.com Component|perl-PDL-Graphics-PLplot|perl-PDL Assignee|i...@cicku.me |jples...@redhat.com -- 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=FZVSI6Zyg3a=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 1055054] segfault when running example from manual page
https://bugzilla.redhat.com/show_bug.cgi?id=1055054 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Flags||needinfo?(i...@cicku.me) --- Comment #7 from Jitka Plesnikova jples...@redhat.com --- Could you please give me any reason why you change the component to perl-PDL? Did you investigate the issue and find that source of problem is at perl-PDL? -- 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=fuAmq4eTl8a=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 1067003] Review Request: perl-Time-ParseDate - Perl modules for parsing dates and times
https://bugzilla.redhat.com/show_bug.cgi?id=1067003 --- Comment #13 from Jon Ciesla limburg...@gmail.com --- Git done (by process-git-requests). -- 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=1a2pBxgm22a=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 1067003] Review Request: perl-Time-ParseDate - Perl modules for parsing dates and times
https://bugzilla.redhat.com/show_bug.cgi?id=1067003 Jon Ciesla limburg...@gmail.com changed: What|Removed |Added Flags|fedora-cvs? |fedora-cvs+ -- 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=H25P4rE8FFa=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 1115971] New: perl-Test-Apocalypse-1.002-7.fc21 FTBFS: 'Test::Apocalypse::Dependencies loaded ok' t/00-compile.t test fails with YAML 0.95
https://bugzilla.redhat.com/show_bug.cgi?id=1115971 Bug ID: 1115971 Summary: perl-Test-Apocalypse-1.002-7.fc21 FTBFS: 'Test::Apocalypse::Dependencies loaded ok' t/00-compile.t test fails with YAML 0.95 Product: Fedora Version: rawhide Component: perl-Test-Apocalypse Assignee: ppi...@redhat.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com perl-Test-Apocalypse-1.002-7.fc21 fails to build due failing test: $ prove -b -v t/00-compile.t t/00-compile.t .. 1..36 ok 1 - Test::Apocalypse loaded ok ok 2 - Test::Apocalypse::AutoLoader loaded ok ok 3 - Test::Apocalypse::CPANMeta loaded ok ok 4 - Test::Apocalypse::CPANMeta_JSON loaded ok ok 5 - Test::Apocalypse::CPANMeta_YAML loaded ok ok 6 - Test::Apocalypse::CheckChanges loaded ok ok 7 - Test::Apocalypse::Compile loaded ok ok 8 - Test::Apocalypse::ConsistentVersion loaded ok ok 9 - Test::Apocalypse::DOSnewline loaded ok YAML::Any does not define $YAML::Any::VERSION--version check failed at lib/Test/Apocalypse/Dependencies.pm line 22. BEGIN failed--compilation aborted at lib/Test/Apocalypse/Dependencies.pm line 22. Compilation failed in require at -e line 1. not ok 10 - Test::Apocalypse::Dependencies loaded ok # Failed test 'Test::Apocalypse::Dependencies loaded ok' # at t/00-compile.t line 46. # '' # doesn't match '(?^s:^\s*Test::Apocalypse::Dependencies ok)' This is caused by upgrading perl-YAML from 0.94 to 0.95. The code checks for YAML modules version, but YAML-0.95 changes how the YAML's version is declared: -$YAML::VERSION = '0.94'; +our $VERSION = '0.95'; -- 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=QgKEO8pugda=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 1115971] perl-Test-Apocalypse-1.002-7.fc21 FTBFS: 'Test::Apocalypse::Dependencies loaded ok' t/00-compile.t test fails with YAML 0.95
https://bugzilla.redhat.com/show_bug.cgi?id=1115971 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC|mmasl...@redhat.com,| |ppi...@redhat.com | External Bug ID||CPAN 96911 -- 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=hfXi5FMSu3a=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 1115971] perl-Test-Apocalypse-1.002-7.fc21 FTBFS: 'Test::Apocalypse::Dependencies loaded ok' t/00-compile.t test fails with YAML 0.95
https://bugzilla.redhat.com/show_bug.cgi?id=1115971 --- Comment #1 from Petr Pisar ppi...@redhat.com --- This is about YAML::Any. The version has been removed. It was: package YAML::Any; $YAML::Any::VERSION = '0.94'; There is no $YAML::Any::VERSION in YAML::Any 0.95. This looks like YAML::Any broke compatibility: perl -e 'use YAML::Any 0.1' YAML::Any does not define $YAML::Any::VERSION--version check failed at -e line 1. BEGIN failed--compilation aborted at -e line 1. -- 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=AArrhQcPBfa=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 1115971] YAML::Any does not declare VERSION since YAML-0.95
https://bugzilla.redhat.com/show_bug.cgi?id=1115971 Petr Pisar ppi...@redhat.com changed: What|Removed |Added URL||https://github.com/ingydotn ||et/yaml-pm/issues/30 CC||psab...@redhat.com, ||st...@silug.org Component|perl-Test-Apocalypse|perl-YAML Assignee|ppi...@redhat.com |st...@silug.org Summary|perl-Test-Apocalypse-1.002- |YAML::Any does not declare |7.fc21 FTBFS: |VERSION since YAML-0.95 |'Test::Apocalypse::Dependen | |cies loaded ok' | |t/00-compile.t test fails | |with YAML 0.95 | --- Comment #2 from Petr Pisar ppi...@redhat.com --- This is a bug in YAML-0.95. I reported it https://github.com/ingydotnet/yaml-pm/issues/30. -- 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=mqS6UruBHla=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 1115971] YAML::Any does not declare VERSION since YAML-0.95
https://bugzilla.redhat.com/show_bug.cgi?id=1115971 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Assignee|st...@silug.org |ppi...@redhat.com -- 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=vucuzwBXbia=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 1115971] YAML::Any does not declare VERSION since YAML-0.95
https://bugzilla.redhat.com/show_bug.cgi?id=1115971 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-YAML-0.95-2.fc21 Resolution|--- |RAWHIDE Last Closed||2014-07-03 10:29:04 -- 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=jB5PjFKNXFa=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 1029710] Amavisd fails to identify attached zipped files with .exe extensions
https://bugzilla.redhat.com/show_bug.cgi?id=1029710 Juan Orti Alcaine juan.o...@miceliux.com changed: What|Removed |Added Flags||needinfo?(s10...@elrepo.org ||) --- Comment #5 from Juan Orti Alcaine juan.o...@miceliux.com --- (In reply to Steve Tindall from comment #4) On a macro level, I define the bug as amavisd failing to quarantine a mail with a zipped exe attachment under SELinux Enforcing Policy. I'm also testing on the same SELinux policy version in enforced mode. # rpm -q amavisd-new selinux-policy selinux-policy-targeted amavisd-new-2.8.0-8.el6.noarch selinux-policy-3.7.19-231.el6_5.3.noarch selinux-policy-targeted-3.7.19-231.el6_5.3.noarch # sestatus SELinux status: enabled SELinuxfs mount:/selinux Current mode: enforcing Mode from config file: enforcing Policy version: 24 Policy from config file:targeted # semanage boolean -l |grep virus antivirus_use_jit (off , off) Determine whether can antivirus programs use JIT compiler. antivirus_can_scan_system (off , off) Allow antivirus programs to read non security files on a system By failure to reproduce the bug, do you mean that you created a zipped exe file (as detailed above in Description), attached it to a mail, sent the mail and observed the mail being quarantined/rejected under Enforcing Policy? I have zipped a couple of exe files with the method you describe, and they are correctly uncompressed and blocked. Also, the sender should get a rejection notice and a maillog entry containing ...Blocked BANNED (.asc,contains_zip.exe)... or similar text should be present. In my tests, the sender receives an informational email with the subject BANNED contents from you (...) Yes, localamavisd is local SELinux policy described in Comment 1 that allows 7za to be called by amavisd. With localamavisd installed under Enforcing Policy, mail with a zipped exe attachment is quarantined, whereas with localamavisd removed, the mail is transmitted without being quarantined. My amavis configuration is almost identical to stock, could you attach yours? Could you test removing the localamavisd module and relabeling your system? # semodule -r localamavisd # touch /.autorelabel # reboot -- 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=Fgonf3J3CSa=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 1067003] Review Request: perl-Time-ParseDate - Perl modules for parsing dates and time
https://bugzilla.redhat.com/show_bug.cgi?id=1067003 Denis Fateyev de...@fateyev.com changed: What|Removed |Added Summary|Review Request: |Review Request: |perl-Time-ParseDate - Perl |perl-Time-ParseDate - Perl |modules for parsing dates |modules for parsing dates |and times |and time -- 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=ubfgFU0kiha=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 1029710] Amavisd fails to identify attached zipped files with .exe extensions
https://bugzilla.redhat.com/show_bug.cgi?id=1029710 Steve Tindall s10...@elrepo.org changed: What|Removed |Added Flags|needinfo?(s10...@elrepo.org | |) | --- Comment #6 from Steve Tindall s10...@elrepo.org --- Created attachment 914596 -- https://bugzilla.redhat.com/attachment.cgi?id=914596action=edit Modified amavisd.conf Requested amavisd.conf Deviations from the stock config file are preceded by # MODIFICATION -- 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=c1V1UjQIpYa=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 1029710] Amavisd fails to identify attached zipped files with .exe extensions
https://bugzilla.redhat.com/show_bug.cgi?id=1029710 --- Comment #7 from Steve Tindall s10...@elrepo.org --- Starting at the bottom of your comments... The requested amavisd.conf is attached above. As suggested, I removed the local amavisd policy, relabeled the filesystem and rebooted. A test mail with an attached zipped exe file is no longer quarantined and is passed undetected to the outgoing mail queue. As I understand the underlying process, 7za lists the contents of the zip, amavisd identifies a file ending in exe and amavisd quarantines the mail. No viral scan (locally clamd.amavisd) is actually performed. Is it possible that your viral scan is detecting the file and not amavisd directly? -- 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=ApDoAng0FVa=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 1115913] Can't call method get_value on an undefined value at /bin/mimeopen line 162
https://bugzilla.redhat.com/show_bug.cgi?id=1115913 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added CC||gree...@greenrd.org Flags||needinfo?(greenrd@greenrd.o ||rg) --- Comment #1 from Jitka Plesnikova jples...@redhat.com --- Could you please give me an example of error message which you get? -- 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=QSf447peika=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
