Re: [EPEL-devel] EPEL Cloud-init in -7
On 10/11/2014 04:13 PM, Sam Kottler wrote: I’m the primary maintainer in EPEL + Fedora. Would certainly be able to help on the CentOS side as well and apply patches as needed. While some of the patches have different names, it looks like we (CentOS) have 4 patches that are not included in the epel cloud-init. Everything else is (other than the configured username). These add support for cloudstack and opennebula as providers, as well as fixing a hostname issue for centos 7 users. Sam, would you review the linked patches and commit them into the epel7 cloud-init? https://git.centos.org/blob/rpms!cloud-init.git/fdbbe746b0838a8957c8dbd1971d1a29a29532a7/SOURCES!cloud-init-centos-hostnamefix.patch https://git.centos.org/blob/rpms!cloud-init.git/fdbbe746b0838a8957c8dbd1971d1a29a29532a7/SOURCES!cloud-init-centos-opennebula.patch https://git.centos.org/blob/rpms!cloud-init.git/fdbbe746b0838a8957c8dbd1971d1a29a29532a7/SOURCES!cloud-init-centos-opennebula-requiretty.patch https://git.centos.org/blob/rpms!cloud-init.git/fdbbe746b0838a8957c8dbd1971d1a29a29532a7/SOURCES!cloud-init-centos-cloudstack-urlhandling.patch -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[EPEL-devel] Rails stack update in EL5
After a very long period of neglect, (sorry), I worked on updating the rails stack in EPEL5 to 2.3.18. This includes activesupport, activerecord and actionpack thus far. Rails still to come. Moving from 2.1.x to 2.3.x *should* be a clean upgrade, but I know in some cases it's not, as some security fixes required minor behavioral changes. I'd appreciate karma and feedback here if anybody is still using this old stack on EPEL5. https://admin.fedoraproject.org/updates/rubygem-actionpack-2.3.18-1.el5,rubygem-activerecord-2.3.18-1.el5,rubygem-activesupport-2.3.18-1.el5?_csrf_token=11f945c29f20072b1ae91f5b343b10334ab92758 The bugs and CVEs addressed are plentiful. - Bug 1095122 - CVE-2014-0130 - Bug 1095125 - CVE-2014-0130 - Bug 677626 - CVE-2011-0446 - Bug 677629 - CVE-2011-0446, CVE-2011-0447 - Bug 677631 - CVE-2011-0447 - Bug 731435 - CVE-2011-2932 - Bug 731438 - CVE-2011-2930 - Bug 731450 - CVE-2011-2932 - Bug 731453 - CVE-2011-2930 - Bug 744706 - CVE-2010-3933 - Bug 831583 - CVE-2012-2695 - Bug 843924 - CVE-2012-3424 - Bug 847202 - CVE-2013-0156 - Bug 891468 - CVE-2012-5664 - Bug 905373 - CVE-2013-0333 - Bug 921329 - CVE-2013-1854 - Bug 924297 - CVE-2013-1855, CVE-2013-1857 - Bug 924318 - CVE-2013-1854 - Bug 948706 - CVE-2013-0276 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[EPEL-devel] Fedora EPEL 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 913 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 368 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 132 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1626/puppet-2.7.26-1.el5 28 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2669/check-mk-1.2.4p5-1.el5 27 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2853/mediawiki119-1.19.18-1.el5 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3206/phpMyAdmin4-4.0.10.4-1.el5 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-/catdoc-0.94.2-10.el5 5 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3455/drupal7-7.32-1.el5 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3549/rubygem-actionpack-2.3.18-1.el5,rubygem-activerecord-2.3.18-1.el5,rubygem-activesupport-2.3.18-1.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing gfal2-util-1.0.0-2.el5 globus-gram-audit-4.3-2.el5 rubygem-actionpack-2.3.18-1.el5 rubygem-activerecord-2.3.18-1.el5 rubygem-activesupport-2.3.18-1.el5 Details about builds: gfal2-util-1.0.0-2.el5 (FEDORA-EPEL-2014-3532) GFAL2 utility tools Update Information: Patch for is_alive ChangeLog: * Wed Oct 22 2014 Alejandro Alvarez aalvarez at cern.ch - 1.0.0-2 - Patch for wrong use of is_alive (not available in Python 2.4) globus-gram-audit-4.3-2.el5 (FEDORA-EPEL-2014-3529) Globus Toolkit - GRAM Jobmanager Auditing Update Information: Remove unexpanded configure macro. ChangeLog: * Sun Oct 19 2014 Mattias Ellert mattias.ell...@fysast.uu.se - 4.3-2 - Remove unexpanded configure macro rubygem-actionpack-2.3.18-1.el5 (FEDORA-EPEL-2014-3549) Web-flow and rendering framework putting the VC in MVC Update Information: Rebase to 2.3.18 in EPEL5. This is a security rollup. - Bug 1095122 - CVE-2014-0130 - Bug 1095125 - CVE-2014-0130 - Bug 677626 - CVE-2011-0446 - Bug 677629 - CVE-2011-0446, CVE-2011-0447 - Bug 677631 - CVE-2011-0447 - Bug 731435 - CVE-2011-2932 - Bug 731438 - CVE-2011-2930 - Bug 731450 - CVE-2011-2932 - Bug 731453 - CVE-2011-2930 - Bug 744706 - CVE-2010-3933 - Bug 831583 - CVE-2012-2695 - Bug 843924 - CVE-2012-3424 - Bug 847202 - CVE-2013-0156 - Bug 891468 - CVE-2012-5664 - Bug 905373 - CVE-2013-0333 - Bug 921329 - CVE-2013-1854 - Bug 924297 - CVE-2013-1855, CVE-2013-1857 - Bug 924318 - CVE-2013-1854 - Bug 948706 - CVE-2013-0276 ChangeLog: * Tue Oct 21 2014 Michael Stahnke stah...@fedoraproject.org - 2.3.18-1 - Updated to 2.3.18 - Bug 677629 - CVE-2011-0446, CVE-2011-0447 fixed in 2.3.11 - Bug 847202 - CVE-2013-0156 fixed in 2.3.15 - Bug 924297 - CVE-2013-1855, CVE-2013-1857 fixed 2.3.18 - Bug 677626 - CVE-2011-0446 fixed in 2.3.11 - Bug 677631 - CVE-2011-0447 fixed in 2.3.11 - Bug 843924 - CVE-2012-3424 fixed by updating to 2.3.18 - Bug 1095122 - CVE-2014-0130 fixed in 2.3.18 * Fri Apr 30 2010 Jeroen van Meeuwen kana...@kanarip.com -2.1.1-6 - Apply fix for CVE-2009-3086 (bz #522162) References: [ 1 ] Bug #677626 - CVE-2011-0446 rubygem-actionpack: Multiple XSS flaws via crafted name or email value in the mail_to_helper https://bugzilla.redhat.com/show_bug.cgi?id=677626 [ 2 ] Bug #677631 - CVE-2011-0447 rubygem-actionpack: CSRF flaws due improper validation of HTTP headers containing X-Requested-With header https://bugzilla.redhat.com/show_bug.cgi?id=677631 [ 3 ] Bug #731435 - CVE-2011-2932 rubygem-activesupport: XSS vulnerability in escaping function (Ruby on Rails) https://bugzilla.redhat.com/show_bug.cgi?id=731435 [ 4 ] Bug #731438 - CVE-2011-2930 rubygem-activerecord: SQL injection vulnerability in quote_table_name (Ruby on Rails) https://bugzilla.redhat.com/show_bug.cgi?id=731438 [ 5 ] Bug #744706 - CVE-2010-3933 rubygem-activerecord: Improper nested attributes management
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 28 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2748/nodejs-0.10.32-1.el7,v8-3.14.5.10-14.el7 27 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2861/nodejs-qs-0.6.6-3.el7 27 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2870/nodejs-send-0.3.0-4.el7 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3236/python-oauth2-1.5.211-8.el7 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3283/php-ZendFramework2-2.3.3-1.el7 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3292/davfs2-1.4.7-6.el7 5 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3454/rubygem-httpclient-2.4.0-2.el7 5 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3432/drupal7-7.32-1.el7 5 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3328/zarafa-7.1.11-1.el7 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3530/phpMyAdmin-4.2.10.1-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing createrepo_c-0.7.0-1.el7 debootstrap-1.0.64-1.el7 fedora-review-0.5.2-1.el7 fldigi-3.22.01-1.el7 globus-gram-audit-4.3-2.el7 mate-themes-1.9.1-1.el7 mate-themes-extras-3.8.0-1.el7 nodejs-chainsaw-0.1.0-1.el7 ntfs-3g-2014.2.15-6.el7 phpMyAdmin-4.2.10.1-1.el7 python-django-pyscss-1.0.5-2.el7 python-pdfkit-0.4.1-5.el7 Details about builds: createrepo_c-0.7.0-1.el7 (FEDORA-EPEL-2014-3536) Creates a common metadata repository Update Information: Update to 0.7.0 ChangeLog: * Mon Oct 20 2014 Tomas Mlcoch tmlcoch at redhat.com - 0.7.0-1 - deltarpms: Update module to work with current version of drpm - mergerepo_c: Add --omit-baseurl option - craterepo_c: Gen empty repo if empty pkglist is used - Docs: Output python docs to separate directory - Several small fixes * Tue Aug 12 2014 Tomas Mlcoch tmlcoch at redhat.com - 0.6.1-1 - updateinfo: Use Python datetime objects in python bindings * Tue Aug 5 2014 Tomas Mlcoch tmlcoch at redhat.com - 0.6.0-1 - Support for updateinfo.xml manipulation (including Python bindings) * Fri Jul 18 2014 Tomas Mlcoch tmlcoch at redhat.com - 0.5.0-1 - Experimental delta rpm (DRPM) support (Disabled in Fedora build). * Thu Jun 26 2014 Tomas Mlcoch tmlcoch at redhat.com - 0.4.1-1 - Initialize threads correctly on old versions of GLib2 (RhBug: 1108787) - Do not print log domain (get rid off C_CREATEREPOLIB prefix in log messages) - Implements support for --cachedir - New option --retain-old-md-by-age - Few small API changes * Tue May 6 2014 Tomas Mlcoch tmlcoch at redhat.com - 0.4.0-1 - Change default behavior of repodata files handling. (RhBug: 1094539) See: https://github.com/Tojaj/createrepo_c/wiki/New-File-Handling By default, createrepo leaves old groupfiles (comps files) in the repodata/ directory during update. Createrepo_c did the same thing but the version 0.4.0 changes this behaviour. * Thu Apr 10 2014 Tomas Mlcoch tmlcoch at redhat.com - 0.3.1-2 - Support for weak and rich dependecies debootstrap-1.0.64-1.el7 (FEDORA-EPEL-2014-3546) Debian GNU/Linux bootstrapper Update Information: new upstream release ChangeLog: * Wed Oct 22 2014 Jan Vcelak jvce...@fedoraproject.org 1.0.64-1 - new upstream release: + Ubuntu vivid as a symlink to gutsy + move set -e out of shebang line (Debian: #762713) References: [ 1 ] Bug #1146866 - debootstrap-1.0.64 is available https://bugzilla.redhat.com/show_bug.cgi?id=1146866 fedora-review-0.5.2-1.el7 (FEDORA-EPEL-2014-3537) Review tool for fedora rpm packages Update Information: fedora-review for EPEL7 References: [ 1 ] Bug #1140900 - RFE: Please branch for EPEL7 https://bugzilla.redhat.com/show_bug.cgi?id=1140900 fldigi-3.22.01-1.el7 (FEDORA-EPEL-2014-3550)
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 913 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 132 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1616/puppet-2.7.26-1.el6 28 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2719/nodejs-0.10.32-1.el6,v8-3.14.5.10-14.el6 27 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2811/nodejs-qs-0.6.6-3.el6 27 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2821/nodejs-send-0.3.0-4.el6 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3202/python-oauth2-1.5.211-8.el6 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2850/nginx-1.0.15-8.el6 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3286/facter-1.6.18-5.el6 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3264/getmail-4.46.0-2.el6 11 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3279/php-ZendFramework-1.12.9-1.el6 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3297/catdoc-0.94.2-10.el6 5 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3427/rubygem-httpclient-2.4.0-2.el6 5 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3421/drupal7-7.32-1.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3434/pylint-1.3.1-1.el6,python-astroid-1.2.1-2.el6,python-logilab-common-0.62.1-2.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3527/asterisk-1.8.31.1-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3533/phpMyAdmin-4.0.10.5-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing asterisk-1.8.31.1-1.el6 createrepo_c-0.7.0-1.el6 debootstrap-1.0.64-1.el6 globus-gram-audit-4.3-2.el6 gnucash-2.4.15-4.el6 hdf5-1.8.5.patch1-9.el6 ntfs-3g-2014.2.15-6.el6 paraview-3.8.1-3.el6 phpMyAdmin-4.0.10.5-1.el6 pyelftools-0.22-0.6.git20130619.a1d9681.el6 scalapack-2.0.2-5.el6.1 Details about builds: asterisk-1.8.31.1-1.el6 (FEDORA-EPEL-2014-3527) The Open Source PBX Update Information: * Tue Oct 21 2014 Jeffrey C. Ollie j...@ocjtech.us - 1.8.31.1-1: The Asterisk Development Team has announced security releases for Certified Asterisk 1.8.28 and 11.6 and Asterisk 1.8, 11, 12, and 13. The available security releases are released as versions 1.8.28-cert2, 11.6-cert7, 1.8.31.1, 11.13.1, 12.6.1, and 13.0.0-beta3. These releases are available for immediate download at http://downloads.asterisk.org/pub/telephony/asterisk/releases The release of these versions resolves the following security vulnerability: * AST-2014-011: Asterisk Susceptibility to POODLE Vulnerability Asterisk is susceptible to the POODLE vulnerability in two ways: 1) The res_jabber and res_xmpp module both use SSLv3 exclusively for their encrypted connections. 2) The core TLS handling in Asterisk, which is used by the chan_sip channel driver, Asterisk Manager Interface (AMI), and Asterisk HTTP Server, by default allow a TLS connection to fallback to SSLv3. This allows for a MITM to potentially force a connection to fallback to SSLv3, exposing it to the POODLE vulnerability. These issues have been resolved in the versions released in conjunction with this security advisory. For more information about the details of this vulnerability, please read security advisory AST-2014-011, which was released at the same time as this announcement. For a full list of changes in the current releases, please see the ChangeLogs: http://downloads.asterisk.org/pub/telephony/certified-asterisk/releases/ChangeLog-1.8.28-cert2 http://downloads.asterisk.org/pub/telephony/certified-asterisk/releases/ChangeLog-11.6-cert7 http://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-1.8.31.1 http://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-11.13.1 http://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-12.6.1 http://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-13.0.0-beta3 The security advisory is available at: * http://downloads.asterisk.org/pub/security/AST-2014-011.pdf * Tue Oct 21 2014 Jeffrey C. Ollie j...@ocjtech.us - 1.8.31.0-1: The Asterisk Development Team has announced the release of Asterisk 1.8.31.0. This release is available for immediate download at http://downloads.asterisk.org/pub/telephony/asterisk The release of Asterisk 1.8.31.0 resolves several issues reported by the community and would have not been possible without your participation. Thank you! The following are the issues resolved in this release: Bugs fixed in this release: --- * ASTERISK-24032 - Gentoo compilation emits warning: _FORTIFY_SOURCE redefined
Re: Improving the offline updates user experience
On 10/21/2014 10:08 PM, Lennart Poettering wrote: Offline updates are more for the cases where things need to be reliable, because no well educated admin is available to instantly fix things. I will print it an pin up on my notice board. And the implication is that offline updates are not for readers of devel@lists.fedoraproject.org -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- 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: Broken deps in rawhide (coreutils)
On 10/21/2014 08:41 PM, Kevin Fenzi wrote: I'm not sure why koji buildroots aren't busted however, unless it's somehow the hosts yum (in the case of koji, f20 and copr el6) is doing things differently? Well, koji buildroots also seem to be affected E.g. https://kojipkgs.fedoraproject.org//packages/perl-Mail-Sender/0.8.23/1.fc22/data/logs/noarch/root.log Actually, I don't understand why they don't abort ;) 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
Looking for xorg-x11-* package co-maintainers
Hi All, As you probably know the graphics team always has more work to do then we've manpower. As the person taking care of various old xor-x11 apps / utilities and utility libraries I'm looking for co-maintainers to help with maintaining these. You do not need to be a hardcore X hacker to help here. 2 things with which I really could use help is keeping all the various bits and pieces up2date with upstream releases, and taking care of simple (packaging) bugs were possible. To give you an idea, currently I've this list of packages which still need to be synced with upstream for rawhide and Fedora-21 : -xcb-proto 1.11 -libxcb 1.11 -xrandr 1.4.3 -libXfont 1.5.0 -twm-1.0.8 -imake 1.0.7, gccmakedep 1.0.3 (imake) -libICE 1.0.9 -libXft 2.3.2 -intel-gpu-tools 1.8 -xkeyboard-config 2.13 -xcb-util 0.4.0 Note these are the upstream package names, the Fedora package names are not always the same. Also in some cases someone else may have updated them since I noticed that they were out of date, I've not rechecked the list recently. If you want to help out with maintaining these, please let me know! Regards, Hans -- 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: Broken deps in rawhide (coreutils)
On Wed, 22 Oct 2014 09:51:36 +0200, Ralf Corsepius wrote: On 10/21/2014 08:41 PM, Kevin Fenzi wrote: I'm not sure why koji buildroots aren't busted however, unless it's somehow the hosts yum (in the case of koji, f20 and copr el6) is doing things differently? Well, koji buildroots also seem to be affected E.g. https://kojipkgs.fedoraproject.org//packages/perl-Mail-Sender/0.8.23/1.fc22/data/logs/noarch/root.log Actually, I don't understand why they don't abort ;) There's something else I don't understand: fontconfig requires font(:lang=en) and this pulls in an arbitrary font package, lyx-fonts (A collection of Math symbol fonts for lyx). As why this is done, the %changelog points at early 2014: Add Requires: font(:lang=en) (#1025331, #845712) Let's see: Bug 1025331 - Firefox segfaults on headless systems Huh? Installing any font (whether used or not) may fix that indeed if it crashes because of missing fonts, but it still sounds like an ugly hack. Why not install a basic/useful font? And the other ticket? Bug 845712 - missing base fonts if no DE is installed Well, it has been reopened in April, because it is a display problem and is still reproducible. Obviously, Math symbol fonts are not really helpful in that case. -- 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: Looking for xorg-x11-* package co-maintainers
On 22 October 2014 11:25, Hans de Goede hdego...@redhat.com wrote: You do not need to be a hardcore X hacker to help here. 2 things with which I really could use help is keeping all the various bits and pieces up2date with upstream releases, and taking care of simple (packaging) bugs were possible. To give you an idea, currently I've this list of packages which still need to be synced with upstream for rawhide and Fedora-21 : -xcb-proto 1.11 -libxcb 1.11 -xrandr 1.4.3 -libXfont 1.5.0 -twm-1.0.8 -imake 1.0.7, gccmakedep 1.0.3 (imake) -libICE 1.0.9 -libXft 2.3.2 -intel-gpu-tools 1.8 -xkeyboard-config 2.13 -xcb-util 0.4.0 Note these are the upstream package names, the Fedora package names are not always the same. Also in some cases someone else may have updated them since I noticed that they were out of date, I've not rechecked the list recently. If you want to help out with maintaining these, please let me know! I'm no hacker, but I can help with packaging. Some packages of those need also to be put on par with recent packaging guidelines. What's the policy here? Always have the latest pushed to rawhide and follow the usual rules for releases in freeze (i.e. no big jumps)? Regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.org/ -- 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: Looking for xorg-x11-* package co-maintainers
Hi, On 10/22/2014 12:09 PM, Simone Caronni wrote: On 22 October 2014 11:25, Hans de Goede hdego...@redhat.com wrote: You do not need to be a hardcore X hacker to help here. 2 things with which I really could use help is keeping all the various bits and pieces up2date with upstream releases, and taking care of simple (packaging) bugs were possible. To give you an idea, currently I've this list of packages which still need to be synced with upstream for rawhide and Fedora-21 : -xcb-proto 1.11 -libxcb 1.11 -xrandr 1.4.3 -libXfont 1.5.0 -twm-1.0.8 -imake 1.0.7, gccmakedep 1.0.3 (imake) -libICE 1.0.9 -libXft 2.3.2 -intel-gpu-tools 1.8 -xkeyboard-config 2.13 -xcb-util 0.4.0 Note these are the upstream package names, the Fedora package names are not always the same. Also in some cases someone else may have updated them since I noticed that they were out of date, I've not rechecked the list recently. If you want to help out with maintaining these, please let me know! I'm no hacker, but I can help with packaging. Great! Note I'm still sorting out getting admin rights on these packages myself, so that I can grant others access. If you're a proven packager, just use your proven packager rights for now, if not just get everything ready, do a commit, followed by: git format-patch HEAD~ And then send me the resulting patch, and I'll apply it for now. If we go this route, please also let me know if I should apply this only to rawhide, or also to older releases (see below). Some packages of those need also to be put on par with recent packaging guidelines. Yes, cleaning up the specfiles would very much be welcome too. What's the policy here? Always have the latest pushed to rawhide Yes. and follow the usual rules for releases in freeze (i.e. no big jumps)? Yes, more or less, mostly just look at the changelog and apply common sense, also depends on the package a bit, e.g. intel-gpu-tools is part of xorg-x11-drv-intel bumping the actual driver needs to be done somewhat carefully, but bumping the tools is more or less always safe, as they are not that important. twm also is probably best just kept fully up2date with upstream in F-21. lib... OTOH may cause breakage (they should not but you never know), etc. Thanks Regards, Hans -- 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: Improving the offline updates user experience
On Tue, 16.09.14 13:35, Petr Pisar (ppi...@redhat.com) wrote: On 2014-09-16, Richard Hughes hughsi...@gmail.com wrote: The much bigger issues is if you're using a D-Bus service like most applications seem to do (and most use quite a few system and session, directly and indirectly) then you've also got to co-ordinate and handle changing D-Bus API (which typically isn't versioned). Maybe it's time to version the API. Look at microkernel based systems which utilize messaging heavily and the API consumers (applications or another subsystems) have to be prepared for spurious API provider (server) restarts. A server can refuse a message any time (especially if it does not understand the request). Simple operations are usualy implemented as a sequence of requests and responses where initial request obtains a descriptor (a session, a handle) and subsequent requests passe it as context (a session) identifier. If the server is restarted in between, the context identifier becomes unrecognized and it's up to the application to deal with it. Just the fact that somebody calls functions over dbus instead of jumping into a shared library do not free them from maintaing API. Well, the theory for this might be great. But reality tells us that code that isn't regularly tested tends to be broken. Hence: the assumption it would be reasonably possible to comprehensively test all kinds of updates between any combination of software versions, executed in any order, simultaneously with the user using the machine, then is simply wrong. You explode the test matrix, and without testing such upgrades will never be reliable. The offline update logic is about making the test matrix smaller, and adding determinism where it normally is missing. 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: Improving the offline updates user experience
On Wed, 17.09.14 13:58, Miroslav Suchý (msu...@redhat.com) wrote: On 09/17/2014 11:54 AM, Bastien Nocera wrote: All those OSes require reboots when updating the OS. Define OS. Firefox is definitely not OS. While systemd is OS. I am fine with reboot after systemd upgrade, but not after upgrading Firefox. Well, on Fedora and Unixes the apps are just part of the OS, they are all dropped into /usr, and not isolated out. It would be great if we could nicely isolate the apps from the OS so that we can restart the apps independently from the OS, but this requires isolating things first. We are working on app sandboxes, and they will make this available, but it's the traditional Linux model cannot really deliver this. 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
Proposal for integration tests infrastructure
Fedora lacks integration testing (unit testing done during build is not enough). Taskotron will be able to fill some gaps in the future, so maintainers will be able to set-up various tasks after their component is built. But even before this works we can benefit from having the tests already available (and run them manually if needed). Hereby, I'd like to get ideas and figure out answers for how and where to keep the tests. A similar discussion already took place before, which I'd like to continue in: https://lists.fedoraproject.org/pipermail/devel/2014-January/193498.html And some short discussion already took place here as well: https://lists.fedoraproject.org/pipermail/env-and-stacks/2014-October/000570.html Some high level requirements: * tests will be written by maintainers or broader community, not a dedicated team * tests will be easy to run on anybody's computer (but might be potentially destructive; some secure environment will not be part of tests) * tests will be run automatically after related components get built (probably by Taskotron) Where to keep tests? a/ in current dist-git for related components (problem with sharing parts of code, problem where to keep tests related for more components) b/ in separate git with similar functionality as dist-git (needs new infrastructure, components are not directly connected with tests, won't make mess in current dist-git) c/ in current dist-git but as ordinary components (no new infrastructure needed but components are not directly connected with tests) How to deliver tests? a/ just use them directly from git (we need to keep some metadata for dependencies anyway) b/ package them as RPMs (we can keep metadata there; e.g. Taskotron will run only tests that have Provides: ci-tests(mariadb) after mariadb is built; we also might automate packaging tests to RPMs) Structure for tests? a/ similar to what components use (branches for Fedora versions) b/ only one branch Test maintainers should be allowed to behave the same as package maintainers do -- one likes keeping branches the same and uses %if %fedora macros, someone else likes specs clean and rather maintain more different branches) -- we won't find one structure that would fit all, so allowing both ways seems better. Which framework to use? People have no time to learn new things, so we should let them to write the tests in any language and just define some conventions how to run them. Cheers, Honza -- 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: Looking for xorg-x11-* package co-maintainers
Out of the previous list, the only ones that have not been updated yet are: -intel-gpu-tools 1.8 (1.7 in rawhide/f21) -xkeyboard-config 2.13 (2.12 in rawhide/f21) -xcb-util 0.4.0 (0.3.9 in rawhide/f21) -libxcb 1.11 (1.10 in f21) -xrandr 1.4.3 (1.4.2 in f21) -twm-1.0.8 (1.0.7 in f21) -imake 1.0.7 (1.0.6 in f21) -gccmakedep 1.0.3 (1.0.2 in f21) On 22 October 2014 12:17, Hans de Goede hdego...@redhat.com wrote: I'm no hacker, but I can help with packaging. Great! Note I'm still sorting out getting admin rights on these packages myself, so that I can grant others access. If you're a proven packager, just use your proven packager rights for now, if not just get everything ready, do a commit, followed by: git format-patch HEAD~ And then send me the resulting patch, and I'll apply it for now. If we go this route, please also let me know if I should apply this only to rawhide, or also to older releases (see below). I'm no provenpackager, will send the patches for those later. Some packages of those need also to be put on par with recent packaging guidelines. Yes, cleaning up the specfiles would very much be welcome too. Will send a separate patch for those components above. After that, maybe I can ask request for commit on the other packages. Yes, more or less, mostly just look at the changelog and apply common sense, also depends on the package a bit, e.g. intel-gpu-tools is part of xorg-x11-drv-intel bumping the actual driver needs to be done somewhat carefully, but bumping the tools is more or less always safe, as they are not that important. twm also is probably best just kept fully up2date with upstream in F-21. lib... OTOH may cause breakage (they should not but you never know), etc. I will not be touching the intel driver :) All those libraries can be added to Upstream Tracker, I find it very handy. I've requested some components already in the past and I find the service very handy: http://upstream-tracker.org/ Regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.org/ -- 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: Improving the offline updates user experience
On Wed, Oct 22, 2014 at 08:48:59AM +0200, Miroslav Suchý wrote: Offline updates are more for the cases where things need to be reliable, because no well educated admin is available to instantly fix things. I will print it an pin up on my notice board. And the implication is that offline updates are not for readers of devel@lists.fedoraproject.org I don't think that's very fair, without the context. First, of course, we're developing for more than just ourselves. And second, this isn't a reversible statement: just because offline updates primarily target one user type doesn't mean that other user types can't or shouldn't use it. Why do I care about this? The non-techie user wants less rebooting too. I'd love to see the updates toolchain get more smarts about recognizing when an update is safe (or at least safer) and not reboot in those cases. That's possible but would be an investment of work. In the meantime, offline updates if you want simple and guaranteed, use yum or dnf online if you're able to handle unlikely but possible consequences seems workable enough. -- 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
rawhide report: 20141022 changes
Compose started at Wed Oct 22 05:15:02 UTC 2014 Broken deps for i386 -- [3Depict] 3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0 [Agda] ghc-Agda-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-Agda-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-Agda-2.3.2.2-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) [PyQuante] PyQuante-libint-1.6.4-11.fc22.1.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [audtty] audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.i686 requires libjson.so.0 [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [collectd] collectd-onewire-5.4.1-10.fc22.i686 requires libowcapi-2.9.so.7 [condor] condor-plumage-8.1.4-7.a1a7df5.fc22.i686 requires libmongoclient.so [darcs] darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so darcs-2.8.4-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) darcs-2.8.4-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-darcs-2.8.4-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-darcs-2.8.4-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-darcs-devel-2.8.4-5.fc22.i686 requires ghc-devel(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-darcs-devel-2.8.4-5.fc22.i686 requires ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) [debconf] debconf-1.5.53-1.fc22.noarch requires perl(:MODULE_COMPAT_5.18.2) [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [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 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc22.i686 requires libedelib.so edelib-devel-2.1-5.fc22.i686 requires libedelib.so [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires hibernate3-jbosscache = 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires libvala-0.24.so.0 [ghc-hjsmin] ghc-hjsmin-0.1.4.7-3.fc22.i686 requires libHSoptparse-applicative-0.9.0-ghc7.6.3.so [glances] glances-2.1.2-2.fc22.noarch requires python-psutil = 0:2.0.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [gorm] gorm-1.2.18-5.fc20.i686 requires libgnustep-gui.so.0.23 [gqrx] gqrx-2.2.0-12.fc22.i686 requires libgnuradio-runtime-3.7.5.so.0.0.0 gqrx-2.2.0-12.fc22.i686 requires libgnuradio-pmt-3.7.5.so.0.0.0 gqrx-2.2.0-12.fc22.i686 requires libgnuradio-filter-3.7.5.so.0.0.0 gqrx-2.2.0-12.fc22.i686 requires libgnuradio-fft-3.7.5.so.0.0.0 gqrx-2.2.0-12.fc22.i686 requires libgnuradio-blocks-3.7.5.so.0.0.0 gqrx-2.2.0-12.fc22.i686 requires libgnuradio-analog-3.7.5.so.0.0.0 [gr-air-modes] gr-air-modes-0-0.27.20140312gitcc0fa180.fc22.i686 requires libgnuradio-runtime-3.7.5.so.0.0.0 gr-air-modes-0-0.27.20140312gitcc0fa180.fc22.i686 requires libgnuradio-pmt-3.7.5.so.0.0.0 [gr-fcdproplus] gr-fcdproplus-0-0.3.20140920git1edbe523.fc22.i686 requires libgnuradio-runtime-3.7.5.so.0.0.0 gr-fcdproplus-0-0.3.20140920git1edbe523.fc22.i686 requires libgnuradio-blocks-3.7.5.so.0.0.0 gr-fcdproplus-0-0.3.20140920git1edbe523.fc22.i686 requires libgnuradio-audio-3.7.5.so.0.0.0 [gr-iqbal] gr-iqbal-0.37.2-2.fc22.i686 requires
Re: Looking for xorg-x11-* package co-maintainers
Le 22/10/2014 11:25, Hans de Goede a écrit : Hi All, As you probably know the graphics team always has more work to do then we've manpower. As the person taking care of various old xor-x11 apps / utilities and utility libraries I'm looking for co-maintainers to help with maintaining these. You do not need to be a hardcore X hacker to help here. 2 things with which I really could use help is keeping all the various bits and pieces up2date with upstream releases, and taking care of simple (packaging) bugs were possible. To give you an idea, currently I've this list of packages which still need to be synced with upstream for rawhide and Fedora-21 : -xcb-proto 1.11 -libxcb 1.11 -xrandr 1.4.3 -libXfont 1.5.0 -twm-1.0.8 -imake 1.0.7, gccmakedep 1.0.3 (imake) -libICE 1.0.9 -libXft 2.3.2 -intel-gpu-tools 1.8 -xkeyboard-config 2.13 -xcb-util 0.4.0 Note these are the upstream package names, the Fedora package names are not always the same. Also in some cases someone else may have updated them since I noticed that they were out of date, I've not rechecked the list recently. If you want to help out with maintaining these, please let me know! Hi, I'm not a packager but I'm interesting in helping. I'm not fully aware of all rules but I'm ready to learn :) Don't hesitate to ping me on irc (I'm starmad). Regards, Matthieu. Regards, Hans -- 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: Improving the offline updates user experience
On 10/21/2014 10:02 PM, Lennart Poettering wrote: Maybe that's actually a strategy to adopt here: upload the encryption keys into the firmware as efi vars, and then pull them out on next boots or so (assuming that efi vars can be marked to survive soft reboots without making them fully persistent...) Hmmm, surrendering your encryption keys to the only software part which you do not have control on? -- Roberto Ragusamail at robertoragusa.it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-21 Branched report: 20141022 changes
Compose started at Wed Oct 22 07:15:02 UTC 2014 Broken deps for armhfp -- [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [cduce] cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [cp2k] cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl requires hibernate3-jbosscache = 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires libmetacity-private.so.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.armv7hl requires libf77blas.so.3 libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1 [ltsp] ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [ocaml-pa-do] ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [openslides] openslides-1.3.1-3.fc21.noarch requires python-django 0:1.5 [openstack-nova] openstack-nova-compute-2014.1.2-1.fc21.noarch requires libvirt-daemon-xen [openvas-client] openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_omp.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_nasl.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_misc.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_hg.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_base.so.6 [perl-RT-Authen-ExternalAuth] perl-RT-Authen-ExternalAuth-0.11-5.fc21.noarch requires rt3 [perl-RT-Extension-CommandByMail] perl-RT-Extension-CommandByMail-0.07-10.fc21.noarch requires perl(RT::Interface::Email) [pipelight-selinux] pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight [pootle] pootle-2.1.6-8.fc21.noarch requires python-django14 [python-askbot-fedmsg] python-askbot-fedmsg-0.1.0-2.fc21.noarch requires askbot [python-coffin] python-coffin-0.3.7-3.fc21.noarch requires python-django14 [python-django-addons] python-django-addons-0.6.6-2.fc21.noarch requires python-django14 [python-django-longerusername] python-django-longerusername-0.4-5.20130204gite4e85d7d.fc21.noarch requires python-django14 [rubygem-linecache19] rubygem-linecache19-0.5.13-6.fc20.armv7hl requires libruby.so.2.0 [rubygem-rubigen] rubygem-rubigen-1.5.8-3.fc21.noarch requires rubygem(activesupport) 0:3.2.0 [rubygem-ruby-debug-base19] rubygem-ruby-debug-base19-0.11.26-6.fc20.armv7hl requires
Re: No more deltarpms by default
On 10/17/2014 05:52 AM, poma wrote: On 06.10.2014 16:46, Jaroslav Reznik wrote: - Original Message - On Mon, 2014-10-06 at 10:54 +0100, Ian Malone wrote: On 6 October 2014 09:41, Rahul Sundaram methe...@gmail.com wrote: Hi One of the long standing features that were enabled by default in yum is support for delta rpms. dnf developers have disabled this and I think this change deserves a broader discussion https://bugzilla.redhat.com/show_bug.cgi?id=1148208 I have an internet flatrate at 150 mbs, and downloading the full rpms is ALOT faster than the the work that the delta rpms requires. Wow. Good to see normal users are taken into account. The main argument from a distro point of view is reducing load on servers, but I don't know many people on 150Mbs either. Heck, I've just tested my work janet connection and that's 100Mbs in our office. At home 8Mbps is a good day. (I'm assuming mbs is a typo for Mbps and not milli bit seconds, where the very slow transfer speed declines exponentially as the connection progresses.) The deltarpms were meant to serve two purposes 1) (lesser) Address the needs of users in developing countries (where Fedora is fairly popular) and bandwidth concerns are very considerable. Many of these users have connections that are either metered or extremely slow, so deltarpms provides a way to get the data to them more economically. This of course can be handled with a non-default option, so we can talk about making that more discoverable if we disable them by default. This is a good point but even in developing countries internet access is getting better and better. A few years ago installation DVD was the only way how to access Fedora repo. It's not requested anymore. But yeah, I do not live there. I strongly disagree with this point. The internet access in developing countries may be getting better, but that is primarily city focused, and even in cities, the cost of internet access is still high. In a large developing country like India (where I live), a huge percentage of the population lives away from the cities. Unlike people living in the cities, the people in the small towns are more likely to be open to using Fedora, for reasons of both cost and principles. I work with the Fedora FreeMedia program, and I send out around 50 Fedora DVDs a month, out of which a good number is to individuals and organizations in rural areas. Regarding the use of deltarpms, if it were not for the availability of deltarpms, a large number of Fedora systems in developing countries will remain not updated, or very irregularly updated, which will result in a large number of Fedora users being exposed to security vulnerabilities. The users will not be able to help it, because the cost for internet access here is often tied to bandwidth usage, and even a weekly update of Fedora using the full rpms will be too expensive. Add to that the unreliability of the internet access, leading to download errors for bigger packages, and most users will choose not to update. So from what I know, based on my personal experience, and my experience in the Fedora FreeMedia program, the Fedora install and Live DVDs are still very relevant, and deltarpms are extremely relevant for developing countries. Please do not sound the death knell for these highly essential tools, based just on the experience in developed countries. p.s. Thanks to poma for bringing this mail thread to my attention. I was not on the Fedora devel list so far. I have now subscribed to the Fedora devel list, so as not to miss such important discussions. :-) -- Regards, Rejy M Cyriac (rmc) -- 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: Improving the offline updates user experience
On Wed, 22.10.14 14:11, Roberto Ragusa (m...@robertoragusa.it) wrote: On 10/21/2014 10:02 PM, Lennart Poettering wrote: Maybe that's actually a strategy to adopt here: upload the encryption keys into the firmware as efi vars, and then pull them out on next boots or so (assuming that efi vars can be marked to survive soft reboots without making them fully persistent...) Hmmm, surrendering your encryption keys to the only software part which you do not have control on? The firmware runs at the highest priviliges anyway, it can do whatever it wants... You don't have to surrender you keys to it. If it wants them it can take them anyway... 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
Fedora 21 Beta Release Readiness Meeting :: Thursday, Oct. 23, 19:00 UTC
Fedora 21 Beta Release Readiness Meeting. date: 2014-10-23 place: irc.freenode.net in #fedora-meeting-2 time: 19:00 UTC (3 PM EDT, 12 PM PDT, 21:00 CEST) This Thursday, October 23, we will meet to make sure we are coordinated and ready for the Beta release of Fedora 21 on Tuesday, October 28, 2014. Please note that this meeting will occur on October 23 even if the release is delayed at the Go/No-Go meeting on the same day two hours earlier. You may received this message several times, but I was asked to open this meeting to the teams and I'll also hope this will raise awareness and more team representatives will come to this meeting. This meeting works best when we have representatives from all of the teams. Also, there's a Fedora badge for active participants! Jaroslav ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-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
[Test-Announce] 2014-10-22 @ 1600 UTC ** Fedora 21 Blocker Review Meeting
# F21 Blocker Review meeting # Date: 2014-10-22 # Time: 16:00 UTC (12:00 EDT, 09:00 PDT) # Location: #fedora-blocker-review on irc.freenode.net We've already had one blocker review meeting this week (which is likely why I forgot to send this email until now), but it's time for another! With Go/No-Go being decided tomorrow we have plenty to do in order to be ready. So far we've got 9 proposed blockers and and 4 proposed freeze exceptions to look through for this meeting. If you want to take a look at the accepted blockers, the full list can be found here: https://qa.fedoraproject.org/blockerbugs/milestone/21/beta/buglist We'll be evaluating these bugs to see if they violate the Beta Release Criteria and warrant the blocking of a release if they're not fixed. Information on the release criteria for F21 can be found on the wiki [0]. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go and you want to run one - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting See you in a couple hours! [0] https://fedoraproject.org/wiki/Fedora_Release_Criteria -- // Mike -- Fedora QA freenode: roshi http://roshi.fedorapeople.org ___ 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: No more deltarpms by default
On Mon, Oct 6, 2014 at 10:41 AM, Rahul Sundaram methe...@gmail.com wrote: Hi One of the long standing features that were enabled by default in yum is support for delta rpms. dnf developers have disabled this and I think this change deserves a broader discussion https://bugzilla.redhat.com/show_bug.cgi?id=1148208 I don't know if this really will happen, but when I read this I had to think about this discussion. http://uk.reuters.com/article/2014/10/22/uk-hungary-internet-tax-idUKKCN0IB0RI20141022 So deltarpm might be a way of actually saving money ;-) -johannes Rahul -- 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: Looking for xorg-x11-* package co-maintainers
Hi, On 10/22/2014 01:44 PM, Simone Caronni wrote: Out of the previous list, the only ones that have not been updated yet are: -intel-gpu-tools 1.8 (1.7 in rawhide/f21) -xkeyboard-config 2.13 (2.12 in rawhide/f21) -xcb-util 0.4.0 (0.3.9 in rawhide/f21) -libxcb 1.11 (1.10 in f21) -xrandr 1.4.3 (1.4.2 in f21) -twm-1.0.8 (1.0.7 in f21) -imake 1.0.7 (1.0.6 in f21) -gccmakedep 1.0.3 (1.0.2 in f21) On 22 October 2014 12:17, Hans de Goede hdego...@redhat.com wrote: I'm no hacker, but I can help with packaging. Great! Note I'm still sorting out getting admin rights on these packages myself, so that I can grant others access. If you're a proven packager, just use your proven packager rights for now, if not just get everything ready, do a commit, followed by: git format-patch HEAD~ And then send me the resulting patch, and I'll apply it for now. If we go this route, please also let me know if I should apply this only to rawhide, or also to older releases (see below). I'm no provenpackager, will send the patches for those later. Sounds good, thanks. All those libraries can be added to Upstream Tracker, I find it very handy. I've requested some components already in the past and I find the service very handy: http://upstream-tracker.org/ That is a good idea, feel free to do that. Regards, Hans -- 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: Looking for xorg-x11-* package co-maintainers
Hi, On 10/22/2014 01:59 PM, Matthieu Gautier wrote: Le 22/10/2014 11:25, Hans de Goede a écrit : Hi All, As you probably know the graphics team always has more work to do then we've manpower. As the person taking care of various old xor-x11 apps / utilities and utility libraries I'm looking for co-maintainers to help with maintaining these. You do not need to be a hardcore X hacker to help here. 2 things with which I really could use help is keeping all the various bits and pieces up2date with upstream releases, and taking care of simple (packaging) bugs were possible. To give you an idea, currently I've this list of packages which still need to be synced with upstream for rawhide and Fedora-21 : -xcb-proto 1.11 -libxcb 1.11 -xrandr 1.4.3 -libXfont 1.5.0 -twm-1.0.8 -imake 1.0.7, gccmakedep 1.0.3 (imake) -libICE 1.0.9 -libXft 2.3.2 -intel-gpu-tools 1.8 -xkeyboard-config 2.13 -xcb-util 0.4.0 Note these are the upstream package names, the Fedora package names are not always the same. Also in some cases someone else may have updated them since I noticed that they were out of date, I've not rechecked the list recently. If you want to help out with maintaining these, please let me know! Hi, I'm not a packager but I'm interesting in helping. I'm not fully aware of all rules but I'm ready to learn :) Sorry, but I don't think that the xorg packages are a good place to start packaging. Regards, Hans -- 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: Improving the offline updates user experience
On 22 October 2014 04:31, Lennart Poettering mzerq...@0pointer.de wrote:
On Wed, 17.09.14 13:58, Miroslav Suchý (msu...@redhat.com) wrote:
On 09/17/2014 11:54 AM, Bastien Nocera wrote:
All those OSes require reboots when updating the OS.
Define OS.
Firefox is definitely not OS. While systemd is OS.
I am fine with reboot after systemd upgrade, but not after upgrading
Firefox.
Well, on Fedora and Unixes the apps are just part of the OS, they are
all dropped into /usr, and not isolated out.
It would be great if we could nicely isolate the apps from the OS so
that we can restart the apps independently from the OS, but this
requires isolating things first.
We are working on app sandboxes, and they will make this available,
but it's the traditional Linux model cannot really deliver this.
Well it depends on the traditional model that you are going to refer to. In
the model of the Unix systems I had to set up in the late 1980's and the
1990's... there was a separation in that items for the OS were in the root
directories (say /bin and /sbin), and stuff that was not OS critical but
user critical were in /usr/{bin,sbin}. And then local critical were in /opt
or /usr/local depending on the OS.
We (Linux distributions) lost that distinction sometime in the past decade
and then undid it completely with the various /usr/ merges. [This isn't
meant to open that can of worms.. the distinction was broken before the
merge.. the merge just made it clear.]
I am not sure how to best move from here. A complete reinvent of
hierarchies is always tempting.. but it has always been the deathknell of
every OS that has done it in the past due to chasm crossing issues (too
much old stuff needing old things causing any benefits from new stuff to be
actual detriments). Doing a more thorough job of packaging items so that
system only items were in /bin,/lib, etc has never worked because too many
things sit between the two. [its a user component AND a system component!]
At best I can say it comes down to operating systems are too damn
complicated and I need to go back to potato farming :)
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
--
Stephen J Smoogen.
--
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: Improving the offline updates user experience
On 10/22/2014 06:31, Lennart Poettering wrote: It would be great if we could nicely isolate the apps from the OS so that we can restart the apps independently from the OS, but this requires isolating things first. Isn't the differentiation between kernel space and user space sufficient for identifying what is the OS and what is an application? I know Windows blurred those lines during the Browser Wars with Netscape, but to my knowledge that separation still exists in Linux. Tom -- 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: Improving the offline updates user experience
On Wed, Oct 22, 2014 at 4:45 PM, Tom Rivers t...@impact-crater.com wrote: On 10/22/2014 06:31, Lennart Poettering wrote: It would be great if we could nicely isolate the apps from the OS so that we can restart the apps independently from the OS, but this requires isolating things first. Isn't the differentiation between kernel space and user space sufficient for identifying what is the OS and what is an application? I know Windows blurred those lines during the Browser Wars with Netscape, but to my knowledge that separation still exists in Linux. No the OS is more than just a kernel. -- 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: Improving the offline updates user experience
On 10/22/2014 10:58, drago01 wrote: No the OS is more than just a kernel. Kernel Space contains more than just the kernel. It also contains device drivers, kernel extensions, and other privileged processes that require full system access. User Space exists as a barrier to keep applications separate from the OS itself. Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora on Intel Edison
Hi, Is there anyone working on making Fedora work with the Intel Edison? Thx, -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Summary/Minutes from today's FESCo Meeting (2014-10-22)
=== #fedora-meeting: FESCO (2014-10-22) === Meeting started by mattdm at 17:00:22 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-10-22/fesco.2014-10-22-17.00.log.html . Meeting summary --- * init process (mattdm, 17:00:27) * #1355 Please select Engineering Representiatve for the new Fedora Council (mattdm, 17:03:20) * LINK: https://fedorahosted.org/fesco/ticket/1355 (mattdm, 17:03:25) * LINK: https://lists.fedoraproject.org/pipermail/devel/2014-October/203391.html (mattdm, 17:03:26) * LINK: https://fedoraproject.org/wiki/User:Jwboyer/Fedora_Council_Engineering_Rep (mattdm, 17:03:52) * AGREED: fedora council engineering representative draft is accepted as official fesco policy (+6 / 0 / -0) (mattdm, 17:06:05) * ACTION: jwb to move draft to somewhere official and add appropriate categories (mattdm, 17:08:38) * AGREED: FESCo selects Josh Boyer (jwb) as Engineering * Representative for Fedora Council (+6,-0,1) (mattdm, 17:17:51) * congratuations josh (mattdm, 17:18:13) * #1322 F21 Changes - Progress at Change Checkpoint: 100% Code Complete Deadline (mattdm, 17:18:43) * LINK: https://fedorahosted.org/fesco/ticket/1322 (mattdm, 17:18:46) * #1357 please consider django-1.7 as late feature for f21 (mattdm, 17:23:05) * LINK: https://fedorahosted.org/fesco/ticket/1357 (mattdm, 17:23:08) * LINK: https://packages.debian.org/jessie/python-django (mrunge, 17:26:06) * AGREED: no exception for 1.7; will stick to 1.6 (since fedora 22 release scheduled to be proper 6-month cycles) (no vote, just general agreement) (mattdm, 17:55:00) * a copr could address 1.7 for people who need it (mattdm, 17:56:17) * Next week's chair (mattdm, 17:56:36) * t8m and kalev to fight for the week AFTER next (mattdm, 17:57:49) * ACTION: sgallagh to chair next week (mattdm, 17:57:56) * updated meeting process at https://fedoraproject.org/wiki/FESCo_meeting_process (mattdm, 17:58:11) * Open Floor (mattdm, 17:58:25) * LINK: https://fedorahosted.org/fesco/ticket/1359 (mattdm, 17:58:49) * AGREED: rel-eng will drop workstation tree so it isn't confusing (currently installs server) (+5,-1) (mattdm, 18:31:19) Meeting ended at 18:32:20 UTC. Action Items * jwb to move draft to somewhere official and add appropriate * categories * sgallagh to chair next week Action Items, by person --- * jwb * jwb to move draft to somewhere official and add appropriate categories * sgallagh * sgallagh to chair next week * **UNASSIGNED** * (none) People Present (lines said) --- * mattdm (160) * sgallagh (84) * dgilmore (78) * mrunge (51) * kalev (49) * jwb (40) * mitr (35) * t8m (19) * stickster (9) * zodbot (7) * jreznik_pp (1) * mmaslano (0) * nirik (0) * thozza (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- 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
Headsup updating miglayout to 4.2 for F-21+
Hi, I'm working on updating freecol to 0.11 and that needs a new miglayout, so I'm updating miglayout too, and I'll push them in tandem. This should not be a problem, since according to repoquery freecol is the only user of miglayout. Regards, Hans -- 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: Broken deps in rawhide (coreutils)
On Tue, Oct 21, 2014 at 12:41 PM, Kevin Fenzi ke...@scrye.com wrote:
I am pointing the finger right now at icecat. It seems to be providing
all the nss libraries and 'winning' the dependency. It's making all the
buildroots a good deal larger than they need to be, and possibly making
them link to the wrong nss/nspr, etc. ;(
The icecat spec file needs something like this:
%global __provides_exclude_from ^%{_libdir}/%{name}-%{version}
And I believe that Requires: nspr and Requires: nss should be
removed. If icecat is linked against the system versions of those
libraries, then the dependencies should be generated automatically.
--
Jerry James
http://www.jamezone.org/
--
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: Improving the offline updates user experience
On 17.09.2014 13:58, Miroslav Suchý wrote: On 09/17/2014 11:54 AM, Bastien Nocera wrote: All those OSes require reboots when updating the OS. Define OS. Firefox is definitely not OS. While systemd is OS. I am fine with reboot after systemd upgrade, but not after upgrading Firefox. the important point in that case is not reboot after upgrading Firefox but *before* upgrading Firefox, which means that at the time of the upgrade no Firefox will be running and potentially crashing because one of the 100s of DSOs it loads on-demand has changed in an incompatible way. there used to be quite a few ABRT crashes reported against desktop applications with impossible looking stack traces (although with the automatic micro-reports it's less of a problem nowadays as they are easier to ignore), and sometimes the reporter gives feedback that the application was running across a yum update... -- 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: Broken deps in rawhide (coreutils)
On Wed, 2014-10-22 at 12:48 -0600, Jerry James wrote:
On Tue, Oct 21, 2014 at 12:41 PM, Kevin Fenzi ke...@scrye.com wrote:
I am pointing the finger right now at icecat. It seems to be providing
all the nss libraries and 'winning' the dependency. It's making all the
buildroots a good deal larger than they need to be, and possibly making
them link to the wrong nss/nspr, etc. ;(
The icecat spec file needs something like this:
%global __provides_exclude_from ^%{_libdir}/%{name}-%{version}
I tried that yesterday in a scratch-build. It didn't work. I've been too
swamped today to try another approach.
And I believe that Requires: nspr and Requires: nss should be
removed. If icecat is linked against the system versions of those
libraries, then the dependencies should be generated automatically.
--
Jerry James
http://www.jamezone.org/
signature.asc
Description: This is a digitally signed message part
--
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: Improving the offline updates user experience
On 22 October 2014 20:07, Michael Stahl mst...@redhat.com wrote: On 17.09.2014 13:58, Miroslav Suchý wrote: On 09/17/2014 11:54 AM, Bastien Nocera wrote: All those OSes require reboots when updating the OS. Define OS. Firefox is definitely not OS. While systemd is OS. I am fine with reboot after systemd upgrade, but not after upgrading Firefox. the important point in that case is not reboot after upgrading Firefox but *before* upgrading Firefox, which means that at the time of the upgrade no Firefox will be running and potentially crashing because one of the 100s of DSOs it loads on-demand has changed in an incompatible way. there used to be quite a few ABRT crashes reported against desktop applications with impossible looking stack traces (although with the automatic micro-reports it's less of a problem nowadays as they are easier to ignore), and sometimes the reporter gives feedback that the application was running across a yum update... While it can be a bit confusing the first time it happens to you, the solution is just to start and stop firefox again in that case. If it the goal is just to tidy ABRT crash reports (and I'm not sure it is) then forcing reboots on users wouldn't be very kind. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Announcing the Fedora 21 Alpha for the Aarch64 architecture!
I'm pleased to announce the arrival of the Fedora Alpha release for the ARM aarch64 architecture. Feel free to take it for a drive [1]. The initial release of Fedora for aarch64 focuses on the Fedora Base and Server product with support for hardware plarforms such as the APM Storm platform including devices like the Mustang board, AMD Seattle and ARM Versatile Express64 including the Foundation emulator and the Juno hardware platform. The aarch64 Server product supports all the features of the product that the mainline primary platforms support. We also support the Base product set and the vast majority of the 15K+ source package set of the entire Fedora release are now built. === Fedora 21 Base === Each of the products will build on the base set of packages for Fedora. For instance, each product will use the same packages for the kernel, RPM, yum, systemd, Anaconda, and so forth. The Base Working Group develops the standard platform for all Fedora products, which includes the installer, compose tools, and basic platform for the other products. Base is not a full product intended for use on its own, but to be kept as a small, stable platform for other products to build on. === Fedora 21 Server === The Fedora Server product is a common base platform that is meant to run featured application stacks, which are produced, tested, and distributed by the Server Working Group. Want to use Fedora as a Web server, file server, database server, or platform for an Infrastructure-as-a-Service? Fedora 21 Server is for you. == Issues and Details == This is an Alpha release. As such, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora ARM team via the arm mailing list or in #fedora-arm on freenode. The release can be found on the secondary architecture mirrors [2]. [1] https://fedoraproject.org/wiki/Architectures/AArch64/F21_Alpha/Installation [2] https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-server-21arch=aarch64 ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-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
File Dancer-1.3132.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-Dancer: d7e720e64a446748f77d938e7ef944c0 Dancer-1.3132.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
[Bug 1155268] epel7 build request
https://bugzilla.redhat.com/show_bug.cgi?id=1155268 Petr Pisar ppi...@redhat.com changed: What|Removed |Added CC||ppi...@redhat.com Assignee|psab...@redhat.com |ppi...@redhat.com --- Comment #1 from Petr Pisar ppi...@redhat.com --- I'm not interested in epel7 much. I can make you the maintainer in epel7. If you agree, send me your FAS account name. -- 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=vqPfmFbGmKa=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-Dancer] 1.3132 bump
commit acc84c249f8674449bb7e0af5fbe409831553205
Author: Jitka Plesnikova jples...@redhat.com
Date: Wed Oct 22 08:34:22 2014 +0200
1.3132 bump
.gitignore |1 +
perl-Dancer.spec |6 +-
sources |2 +-
3 files changed, 7 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 52f9aa5..0bf12f1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -28,3 +28,4 @@
/Dancer-1.3126.tar.gz
/Dancer-1.3129.tar.gz
/Dancer-1.3130.tar.gz
+/Dancer-1.3132.tar.gz
diff --git a/perl-Dancer.spec b/perl-Dancer.spec
index 5561cec..3aaa1a5 100644
--- a/perl-Dancer.spec
+++ b/perl-Dancer.spec
@@ -1,5 +1,5 @@
Name: perl-Dancer
-Version:1.3130
+Version:1.3132
Release:1%{?dist}
Summary:Lightweight yet powerful web application framework
License:GPL+ or Artistic
@@ -83,6 +83,7 @@ Requires: perl(HTTP::Server::Simple::PSGI) = 0.11
Requires: perl(LWP)
Requires: perl(Try::Tiny) = 0.09
Requires: perl(URI) = 1.59
+Requires: perl(YAML)
%{?perl_default_filter}
@@ -118,6 +119,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Oct 21 2014 Jitka Plesnikova jples...@redhat.com - 1.3132-1
+- 1.3132 bump
+
* Thu Sep 18 2014 Jitka Plesnikova jples...@redhat.com - 1.3130-1
- 1.3130 bump
diff --git a/sources b/sources
index 4d1847b..d838fd7 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4481ab3449d2b49970d444d0e7dd519e Dancer-1.3130.tar.gz
+d7e720e64a446748f77d938e7ef944c0 Dancer-1.3132.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
[Bug 1155130] perl-Dancer-1.3132 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1155130 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Dancer-1.3132-1.fc22 Resolution|--- |RAWHIDE Last Closed||2014-10-22 02:45:00 -- 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=8ywZZ19PHOa=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 1150091] CVE-2014-1571 CVE-2014-1572 CVE-2014-1573 bugzilla: security fixes release
https://bugzilla.redhat.com/show_bug.cgi?id=1150091 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- bugzilla-4.2.11-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=ERAWXROguLa=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 1150092] CVE-2014-1573 CVE-2014-1572 CVE-2014-1571 bugzilla: security fixes release [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1150092 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||bugzilla-4.2.11-1.fc19 Resolution|--- |ERRATA Last Closed||2014-10-22 04:50:39 --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- bugzilla-4.2.11-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=WbMQ845v8ya=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 1150091] CVE-2014-1571 CVE-2014-1572 CVE-2014-1573 bugzilla: security fixes release
https://bugzilla.redhat.com/show_bug.cgi?id=1150091 Bug 1150091 depends on bug 1150092, which changed state. Bug 1150092 Summary: CVE-2014-1573 CVE-2014-1572 CVE-2014-1571 bugzilla: security fixes release [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=1150092 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=lmKNn8lCBxa=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 1150092] CVE-2014-1573 CVE-2014-1572 CVE-2014-1571 bugzilla: security fixes release [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1150092 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|bugzilla-4.2.11-1.fc19 |bugzilla-4.2.11-1.fc20 --- Comment #7 from Fedora Update System upda...@fedoraproject.org --- bugzilla-4.2.11-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=aIXoxriUH6a=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 1150091] CVE-2014-1571 CVE-2014-1572 CVE-2014-1573 bugzilla: security fixes release
https://bugzilla.redhat.com/show_bug.cgi?id=1150091 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- bugzilla-4.2.11-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=EnMhPvvw2ca=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 1150530] perl-Redis-1.976 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1150530 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Redis-1.976-1.fc20 Resolution|--- |ERRATA Last Closed||2014-10-22 04:53:20 --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- perl-Redis-1.976-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=bmBGwUqxYMa=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 1155491] New: perl-Archive-Zip-1.39 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1155491 Bug ID: 1155491 Summary: perl-Archive-Zip-1.39 is available Product: Fedora Version: rawhide Component: perl-Archive-Zip Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, st...@silug.org Latest upstream release: 1.39 Current version/release in Fedora Rawhide: 1.38-1.fc22 URL: http://search.cpan.org/dist/Archive-Zip/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Soon this service will be implemented by a new system: https://github.com/fedora-infra/anitya/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- 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=gH5gT8tnIOa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Qt
perl-Qt has broken dependencies in the rawhide tree: On x86_64: perl-Qt-0.96.0-11.fc22.x86_64 requires perl(:MODULE_COMPAT_5.18.2) perl-Qt-0.96.0-11.fc22.x86_64 requires libperl.so.5.18()(64bit) On i386: perl-Qt-0.96.0-11.fc22.i686 requires perl(:MODULE_COMPAT_5.18.2) perl-Qt-0.96.0-11.fc22.i686 requires libperl.so.5.18 On armhfp: perl-Qt-0.96.0-11.fc22.armv7hl requires perl(:MODULE_COMPAT_5.18.2) perl-Qt-0.96.0-11.fc22.armv7hl requires libperl.so.5.18 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Archive-Zip-1.39.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-Archive-Zip: 851316e59625317a89e40418a26c676c Archive-Zip-1.39.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-Archive-Zip] 1.39 bump
commit 0cba5d48c607df915d93b8c4d47f2ba5d36761ee
Author: Jitka Plesnikova jples...@redhat.com
Date: Wed Oct 22 13:31:33 2014 +0200
1.39 bump
.gitignore |1 +
Archive-Zip-cpan-rt-54827.patch | 25 ++---
perl-Archive-Zip.spec | 25 ++---
sources |2 +-
4 files changed, 26 insertions(+), 27 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index d352068..9b4dff6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@ Archive-Zip-1.30.tar.gz
/Archive-Zip-1.36.tar.gz
/Archive-Zip-1.37.tar.gz
/Archive-Zip-1.38.tar.gz
+/Archive-Zip-1.39.tar.gz
diff --git a/Archive-Zip-cpan-rt-54827.patch b/Archive-Zip-cpan-rt-54827.patch
index e22477d..3ecb815 100644
--- a/Archive-Zip-cpan-rt-54827.patch
+++ b/Archive-Zip-cpan-rt-54827.patch
@@ -1,18 +1,21 @@
-diff -up Archive-Zip-1.33/lib/Archive/Zip/Member.pm.orig
Archive-Zip-1.33/lib/Archive/Zip/Member.pm
Archive-Zip-1.33/lib/Archive/Zip/Member.pm.orig2013-11-10
04:47:27.0 +0100
-+++ Archive-Zip-1.33/lib/Archive/Zip/Member.pm 2013-11-22 12:48:19.848476120
+0100
-@@ -167,13 +167,13 @@ sub bitFlag {
-
- # Set General Purpose Bit Flags according to the desiredCompressionLevel
setting
- if ( $self-desiredCompressionLevel == 1 ||
$self-desiredCompressionLevel == 2 ) {
+diff -up Archive-Zip-1.39/lib/Archive/Zip/Member.pm.orig
Archive-Zip-1.39/lib/Archive/Zip/Member.pm
+--- Archive-Zip-1.39/lib/Archive/Zip/Member.pm.orig2014-10-22
13:05:47.852592106 +0200
Archive-Zip-1.39/lib/Archive/Zip/Member.pm 2014-10-22 13:10:28.151696108
+0200
+@@ -159,16 +159,16 @@ sub bitFlag {
+ # Set General Purpose Bit Flags according to the desiredCompressionLevel
setting
+ if ( $self-desiredCompressionLevel == 1
+ || $self-desiredCompressionLevel == 2) {
-$self-{'bitFlag'} = DEFLATING_COMPRESSION_FAST;
+$self-{'bitFlag'} |= DEFLATING_COMPRESSION_FAST;
- } elsif ( $self-desiredCompressionLevel == 3 ||
$self-desiredCompressionLevel == 4
- || $self-desiredCompressionLevel == 5 ||
$self-desiredCompressionLevel == 6
- || $self-desiredCompressionLevel == 7 ) {
+ } elsif ($self-desiredCompressionLevel == 3
+ || $self-desiredCompressionLevel == 4
+ || $self-desiredCompressionLevel == 5
+ || $self-desiredCompressionLevel == 6
+ || $self-desiredCompressionLevel == 7) {
-$self-{'bitFlag'} = DEFLATING_COMPRESSION_NORMAL;
+$self-{'bitFlag'} |= DEFLATING_COMPRESSION_NORMAL;
- } elsif ( $self-desiredCompressionLevel == 8 ||
$self-desiredCompressionLevel == 9 ) {
+ } elsif ($self-desiredCompressionLevel == 8
+ || $self-desiredCompressionLevel == 9) {
-$self-{'bitFlag'} = DEFLATING_COMPRESSION_MAXIMUM;
+$self-{'bitFlag'} |= DEFLATING_COMPRESSION_MAXIMUM;
}
diff --git a/perl-Archive-Zip.spec b/perl-Archive-Zip.spec
index a53ba2d..fb946e2 100644
--- a/perl-Archive-Zip.spec
+++ b/perl-Archive-Zip.spec
@@ -1,5 +1,5 @@
Name: perl-Archive-Zip
-Version:1.38
+Version:1.39
Release:1%{?dist}
Summary:Perl library for accessing Zip archives
@@ -7,7 +7,6 @@ Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Archive-Zip/
Source0:
http://search.cpan.org/CPAN/authors/id/P/PH/PHRED/Archive-Zip-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
#https://rt.cpan.org/Public/Bug/Display.html?id=54827
Patch0: Archive-Zip-cpan-rt-54827.patch
@@ -19,9 +18,9 @@ BuildRequires: perl(strict)
# Run-time
BuildRequires: perl(bytes)
BuildRequires: perl(Carp)
+BuildRequires: perl(Compress::Raw::Zlib)
BuildRequires: perl(constant)
BuildRequires: perl(Cwd)
-BuildRequires: perl(Compress::Raw::Zlib)
BuildRequires: perl(Encode)
BuildRequires: perl(Exporter)
BuildRequires: perl(File::Basename)
@@ -45,7 +44,7 @@ BuildRequires: perl(warnings)
BuildRequires: unzip
BuildRequires: zip
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
The Archive::Zip module allows a Perl program to create, manipulate,
@@ -62,20 +61,18 @@ existing Zip files, or from existing directories, files, or
strings.
%prep
%setup -q -n Archive-Zip-%{version}
%patch0 -p1
-%{__perl} -pi -e 's|^#!/bin/perl|#!%{__perl}|' examples/*.pl
-%{__perl} -pi -e 's|^#!/usr/local/bin/perl|#!%{__perl}|' examples/selfex.pl
+perl -pi -e 's|^#!/bin/perl|#!%{__perl}|' examples/*.pl
+perl -pi -e 's|^#!/usr/local/bin/perl|#!%{__perl}|' examples/selfex.pl
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
[Bug 1155491] perl-Archive-Zip-1.39 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1155491 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Archive-Zip-1.39-1.fc2 ||2 Resolution|--- |RAWHIDE Last Closed||2014-10-22 08:04:24 -- 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=LRu42ksygMa=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-Mail-Sender/f21] (3 commits) ...Merge cleanup.
Summary of changes: d07bc6f... Perl 5.20 rebuild (*) dfd354b... Upstream update. (*) 4cbe194... Merge cleanup. (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Mail-Sender/f21: 3/3] Merge cleanup.
commit 4cbe194692cf17b00a9921c4939c2a7af26b4336 Author: Ralf Corsépius corse...@fedoraproject.org Date: Wed Oct 22 08:17:17 2014 +0200 Merge cleanup. perl-Mail-Sender.spec |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) --- diff --git a/perl-Mail-Sender.spec b/perl-Mail-Sender.spec index 459ebc9..35db140 100644 --- a/perl-Mail-Sender.spec +++ b/perl-Mail-Sender.spec @@ -58,9 +58,6 @@ make test - Upstream update. - Spec cleanup. -* Wed Aug 27 2014 Jitka Plesnikova jples...@redhat.com - 0.8.21-6 -- Perl 5.20 rebuild - * Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.8.21-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild -- 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 1155268] epel7 build request
https://bugzilla.redhat.com/show_bug.cgi?id=1155268 --- Comment #2 from Bill Pemberton wf...@worldbroken.com --- Sure, I'd be happy to maintain the epel7 branch. My FAS account name is wfp -- 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=cuwifJw6yka=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-Cpanel-JSON-XS] Break build cycles
commit 07af685218809324e51f08bbb10f44432437887a
Author: Petr Písař ppi...@redhat.com
Date: Wed Oct 22 14:56:52 2014 +0200
Break build cycles
perl-Cpanel-JSON-XS.spec | 21 ++---
1 files changed, 18 insertions(+), 3 deletions(-)
---
diff --git a/perl-Cpanel-JSON-XS.spec b/perl-Cpanel-JSON-XS.spec
index 7a1add2..e9578ee 100644
--- a/perl-Cpanel-JSON-XS.spec
+++ b/perl-Cpanel-JSON-XS.spec
@@ -1,7 +1,7 @@
Name: perl-Cpanel-JSON-XS
Summary: JSON::XS for Cpanel, fast and correct serializing
Version: 3.0104
-Release: 4%{?dist}
+Release: 5%{?dist}
License: GPL+ or Artistic
URL: http://search.cpan.org/dist/Cpanel-JSON-XS/
Source0:
http://search.cpan.org/CPAN/authors/id/R/RU/RURBAN/Cpanel-JSON-XS-%{version}.tar.gz
@@ -29,12 +29,23 @@ BuildRequires: perl(JSON)
BuildRequires: perl(JSON::XS)
BuildRequires: perl(strict)
BuildRequires: perl(Test)
-BuildRequires: perl(Test::LeakTrace)
BuildRequires: perl(Test::More) = 0.88
BuildRequires: perl(Tie::Array)
BuildRequires: perl(Tie::Hash)
BuildRequires: perl(utf8)
BuildRequires: perl(warnings)
+%if !%{defined perl_bootstrap}
+# Cycle: perl-Cpanel-JSON-XS → perl-Test-LeakTrace → perl-Module-Install
+# → perl-YAML-Tiny → perl-JSON-MaybeXS → perl-Cpanel-JSON-XS
+# Cycle: perl-Cpanel-JSON-XS → perl-Perl-MinimumVersion → perl-PPI
+# → perl-List-MoreUtils → perl-Test-LeakTrace → perl-Module-Install
+# → perl-YAML-Tiny → perl-JSON-MaybeXS → perl-Cpanel-JSON-XS
+# Cycle: perl-Cpanel-JSON-XS → perl-Test-MinimumVerion → perl-YAML-Tiny
+# → perl-JSON-MaybeXS → perl-Cpanel-JSON-XS
+# Cycle: perl-Cpanel-JSON-XS → perl-Test-Kwalitee → perl-Module-CPANTS-Analyse
+# → perl-JSON-MaybeXS → perl-Cpanel-JSON-XS
+# Optional tests:
+BuildRequires: perl(Test::LeakTrace)
# Maintainer Tests
BuildRequires: perl(File::Copy)
BuildRequires: perl(Perl::MinimumVersion) = 1.20
@@ -43,6 +54,7 @@ BuildRequires:perl(Test::Kwalitee)
BuildRequires: perl(Test::MinimumVersion) = 0.008
BuildRequires: perl(Test::Pod) = 1.00
BuildRequires: perl(Test::Pod::Coverage) = 1.04
+%endif
# Runtime
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(Carp)
@@ -80,7 +92,7 @@ find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm -f
{} ';'
%{_fixperms} %{buildroot}
%check
-make test IS_MAINTAINER=1 RELEASE_TESTING=1
+make test IS_MAINTAINER=1 %{!?perl_bootstrap:RELEASE_TESTING=1}
%files
%doc Changes COPYING README eg/
@@ -92,6 +104,9 @@ make test IS_MAINTAINER=1 RELEASE_TESTING=1
%{_mandir}/man3/Cpanel::JSON::XS::Boolean.3pm*
%changelog
+* Wed Oct 22 2014 Petr Pisar ppi...@redhat.com - 3.0104-5
+- Break build cycles
+
* Fri Aug 29 2014 Jitka Plesnikova jples...@redhat.com - 3.0104-4
- Perl 5.20 rebuild
--
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 1155268] epel7 build request
https://bugzilla.redhat.com/show_bug.cgi?id=1155268 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |DUPLICATE Last Closed||2014-10-22 09:46:20 --- Comment #3 from Petr Pisar ppi...@redhat.com --- *** This bug has been marked as a duplicate of bug 429081 *** -- 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=IwxbeoZxdea=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 IO-Socket-SSL-2.002.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-IO-Socket-SSL: 3b0753495a1ff043bd782a6b876d990f IO-Socket-SSL-2.002.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-IO-Socket-SSL] Update to 2.002
commit 1e5d92fafe016d879da73af0c68a1742c95241f7
Author: Paul Howarth p...@city-fan.org
Date: Wed Oct 22 18:29:57 2014 +0100
Update to 2.002
- New upstream release 2.002
- Fix check for (invalid) IPv4 when validating hostname against
certificate;
do not use inet_aton any longer because it can cause DNS lookups for
malformed IP (CPAN RT#99448)
- Update PublicSuffix with latest version from publicsuffix.org - lots of
new
top level domains
- Add exception to PublicSuffix for s3.amazonaws.com (CPAN RT#99702)
...-SSL-2.002-use-system-default-SSL-version.patch |2 +-
perl-IO-Socket-SSL.spec| 13 +++--
sources|2 +-
3 files changed, 13 insertions(+), 4 deletions(-)
---
diff --git a/IO-Socket-SSL-2.001-use-system-default-SSL-version.patch
b/IO-Socket-SSL-2.002-use-system-default-SSL-version.patch
similarity index 98%
rename from IO-Socket-SSL-2.001-use-system-default-SSL-version.patch
rename to IO-Socket-SSL-2.002-use-system-default-SSL-version.patch
index ddcaae8..3ed26c4 100644
--- a/IO-Socket-SSL-2.001-use-system-default-SSL-version.patch
+++ b/IO-Socket-SSL-2.002-use-system-default-SSL-version.patch
@@ -9,7 +9,7 @@
SSL_verify_callback = undef,
SSL_verifycn_scheme = undef, # fallback cn verification
SSL_verifycn_publicsuffix = undef, # fallback default list verification
-@@ -2056,7 +2056,7 @@ WARN
+@@ -2058,7 +2058,7 @@ WARN
$ssl_op |= Net::SSLeay::OP_SINGLE_DH_USE;
$ssl_op |= Net::SSLeay::OP_SINGLE_ECDH_USE if $can_ecdh;
diff --git a/perl-IO-Socket-SSL.spec b/perl-IO-Socket-SSL.spec
index dff1909..e014772 100644
--- a/perl-IO-Socket-SSL.spec
+++ b/perl-IO-Socket-SSL.spec
@@ -1,5 +1,5 @@
Name: perl-IO-Socket-SSL
-Version: 2.001
+Version: 2.002
Release: 1%{?dist}
Summary: Perl library for transparent SSL
Group: Development/Libraries
@@ -7,7 +7,7 @@ License:GPL+ or Artistic
URL: http://search.cpan.org/dist/IO-Socket-SSL/
Source0:
http://search.cpan.org/CPAN/authors/id/S/SU/SULLR/IO-Socket-SSL-%{version}.tar.gz
Patch0:IO-Socket-SSL-2.000-use-system-default-cipher-list.patch
-Patch1:IO-Socket-SSL-2.001-use-system-default-SSL-version.patch
+Patch1:IO-Socket-SSL-2.002-use-system-default-SSL-version.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
BuildRequires: openssl = 0.9.8
@@ -100,6 +100,15 @@ rm -rf %{buildroot}
%{_mandir}/man3/IO::Socket::SSL::Utils.3*
%changelog
+* Wed Oct 22 2014 Paul Howarth p...@city-fan.org - 2.002-1
+- Update to 2.002
+ - Fix check for (invalid) IPv4 when validating hostname against certificate;
+do not use inet_aton any longer because it can cause DNS lookups for
+malformed IP (CPAN RT#99448)
+ - Update PublicSuffix with latest version from publicsuffix.org - lots of new
+top level domains
+ - Add exception to PublicSuffix for s3.amazonaws.com (CPAN RT#99702)
+
* Tue Oct 21 2014 Paul Howarth p...@city-fan.org - 2.001-1
- Update to 2.001
- Add SSL_OP_SINGLE_(DH|ECDH)_USE to default options to increase PFS security
diff --git a/sources b/sources
index 83b81f1..60aa972 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-9562d344f0b3962b95303fad54277999 IO-Socket-SSL-2.001.tar.gz
+3b0753495a1ff043bd782a6b876d990f IO-Socket-SSL-2.002.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 JSON-MaybeXS-1.002006.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-JSON-MaybeXS: 3cd5a5f9504ee3c0cf5dd75770498804 JSON-MaybeXS-1.002006.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-JSON-MaybeXS] Update to 1.002006
commit 81c667448cc69478b174c77e336adf20224c0fc7
Author: Paul Howarth p...@city-fan.org
Date: Wed Oct 22 18:52:48 2014 +0100
Update to 1.002006
- New upstream release 1.002006
- Add some additional test diagnostics, to help find bad version
combinations
of JSON backends
perl-JSON-MaybeXS.spec |7 ++-
sources|2 +-
2 files changed, 7 insertions(+), 2 deletions(-)
---
diff --git a/perl-JSON-MaybeXS.spec b/perl-JSON-MaybeXS.spec
index 6852de5..07bff09 100644
--- a/perl-JSON-MaybeXS.spec
+++ b/perl-JSON-MaybeXS.spec
@@ -8,7 +8,7 @@
Name: perl-JSON-MaybeXS
Summary: Use Cpanel::JSON::XS with a fallback to JSON::XS and JSON::PP
-Version: 1.002005
+Version: 1.002006
Release: 1%{?dist}
License: GPL+ or Artistic
URL: http://search.cpan.org/dist/JSON-MaybeXS/
@@ -72,6 +72,11 @@ make test
%{_mandir}/man3/JSON::MaybeXS.3*
%changelog
+* Wed Oct 22 2014 Paul Howarth p...@city-fan.org - 1.002006-1
+- Update to 1.002006
+ - Add some additional test diagnostics, to help find bad version combinations
+of JSON backends
+
* Wed Oct 15 2014 Paul Howarth p...@city-fan.org - 1.002005-1
- Update to 1.002005
- Fix can I haz XS? logic precedence in Makefile.PL
diff --git a/sources b/sources
index aafc3e3..41d87b4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-87d68022483b34cade8b957b3a4d4240 JSON-MaybeXS-1.002005.tar.gz
+3cd5a5f9504ee3c0cf5dd75770498804 JSON-MaybeXS-1.002006.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-IO-Socket-SSL/f21] Update to 2.002
Summary of changes: 1e5d92f... Update to 2.002 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-IO-Socket-SSL] Created tag perl-IO-Socket-SSL-2.002-1.fc21
The lightweight tag 'perl-IO-Socket-SSL-2.002-1.fc21' was created pointing to: 1e5d92f... Update to 2.002 -- 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-IO-Socket-SSL] Created tag perl-IO-Socket-SSL-2.002-1.fc22
The lightweight tag 'perl-IO-Socket-SSL-2.002-1.fc22' was created pointing to: 1e5d92f... Update to 2.002 -- 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-JSON-MaybeXS] Created tag perl-JSON-MaybeXS-1.002006-1.fc22
The lightweight tag 'perl-JSON-MaybeXS-1.002006-1.fc22' was created pointing to: 81c6674... Update to 1.002006 -- 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-Mail-Sender/f20] (5 commits) ...Merge cleanup.
Summary of changes: 1ef234b... - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass (*) d07bc6f... Perl 5.20 rebuild (*) dfd354b... Upstream update. (*) 4cbe194... Merge cleanup. (*) 32f7bf9... Merge cleanup. (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Mail-Sender/f20: 5/5] Merge cleanup.
commit 32f7bf9ed73e255e6798d2d5797a042273393e3b Author: Ralf Corsépius corse...@fedoraproject.org Date: Wed Oct 22 15:37:36 2014 +0200 Merge cleanup. perl-Mail-Sender.spec |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) --- diff --git a/perl-Mail-Sender.spec b/perl-Mail-Sender.spec index 35db140..6843654 100644 --- a/perl-Mail-Sender.spec +++ b/perl-Mail-Sender.spec @@ -58,9 +58,6 @@ make test - Upstream update. - Spec cleanup. -* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.8.21-5 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild - * Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.8.21-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild -- 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
[389-devel] Build failed in Jenkins: 389-ds-base #435
See http://jenkins.cloud.fedoraproject.org/job/389-ds-base/435/ -- Started by user Richard Allen Megginson Building remotely on Fedora20 in workspace http://jenkins.cloud.fedoraproject.org/job/389-ds-base/ws/ Wiping out workspace first. Cloning the remote Git repository Cloning repository http://git.fedorahosted.org/git/389/ds.git git init http://jenkins.cloud.fedoraproject.org/job/389-ds-base/ws/ # timeout=10 Fetching upstream changes from http://git.fedorahosted.org/git/389/ds.git git --version # timeout=10 ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: java.lang.RuntimeException: Could not generate DH keypair at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkCredentials(CliGitAPIImpl.java:2198) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1152) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$200(CliGitAPIImpl.java:87) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:266) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:422) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) ERROR: null -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Jenkins build is back to normal : 389-ds-base #436
See http://jenkins.cloud.fedoraproject.org/job/389-ds-base/436/ -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review: [389 Project] #47928: Disable SSL v3, by default.
https://fedorahosted.org/389/ticket/47928 https://fedorahosted.org/389/attachment/ticket/47928/0001-Ticket-47928-Disable-SSL-v3-by-default.patch https://fedorahosted.org/389/attachment/ticket/47928/0002-Ticket-47928-CI-test-added-test-cases-for-ticket-479.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review (resend): [389 Project] #47380: Winsync loses connection with AD objects when they move from the console.
https://fedorahosted.org/389/ticket/47380 https://fedorahosted.org/389/attachment/ticket/47380/0001-Ticket-47380-RFE-Winsync-loses-connection-with-AD-ob.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Announcing the Fedora 21 Alpha for the Aarch64 architecture!
I'm pleased to announce the arrival of the Fedora Alpha release for the ARM aarch64 architecture. Feel free to take it for a drive [1]. The initial release of Fedora for aarch64 focuses on the Fedora Base and Server product with support for hardware plarforms such as the APM Storm platform including devices like the Mustang board, AMD Seattle and ARM Versatile Express64 including the Foundation emulator and the Juno hardware platform. The aarch64 Server product supports all the features of the product that the mainline primary platforms support. We also support the Base product set and the vast majority of the 15K+ source package set of the entire Fedora release are now built. === Fedora 21 Base === Each of the products will build on the base set of packages for Fedora. For instance, each product will use the same packages for the kernel, RPM, yum, systemd, Anaconda, and so forth. The Base Working Group develops the standard platform for all Fedora products, which includes the installer, compose tools, and basic platform for the other products. Base is not a full product intended for use on its own, but to be kept as a small, stable platform for other products to build on. === Fedora 21 Server === The Fedora Server product is a common base platform that is meant to run featured application stacks, which are produced, tested, and distributed by the Server Working Group. Want to use Fedora as a Web server, file server, database server, or platform for an Infrastructure-as-a-Service? Fedora 21 Server is for you. == Issues and Details == This is an Alpha release. As such, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora ARM team via the arm mailing list or in #fedora-arm on freenode. The release can be found on the secondary architecture mirrors [2]. [1] https://fedoraproject.org/wiki/Architectures/AArch64/F21_Alpha/Installation [2] https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-server-21arch=aarch64 ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
