EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 630 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 121 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11560/fail2ban-0.8.10-4.el5 85 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 60 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12091/bip-0.8.9-1.el5 50 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12159/389-ds-base-1.2.11.25-1.el5 50 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12169/gc-7.1-6.el5 2 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0112/drupal7-entity-1.3-1.el5 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0132/graphviz-2.12-10.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing python-dirq-1.5-1.el5 Details about builds: python-dirq-1.5-1.el5 (FEDORA-EPEL-2014-0148) Directory based queue Update Information: Update to upstream version, rhbz #1049761. ChangeLog: * Sat Jan 11 2014 Massimo Paladin massimo.pala...@gmail.com - 1.5-1 - Update to upstream version, rhbz #1049761. * Sun Aug 4 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.4-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild References: [ 1 ] Bug #1049761 - Upgrade to new upstream version https://bugzilla.redhat.com/show_bug.cgi?id=1049761 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing:
Age URL
630
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6
87
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11865/quassel-0.9.1-1.el6
60
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12079/bip-0.8.9-1.el6
24
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12427/seamonkey-2.21-3.esr2.el6
8
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0026/x2goserver-4.0.1.10-1.el6
2
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0110/drupal7-entity-1.3-1.el6
2
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0105/strongswan-5.1.1-4.el6
The following builds have been pushed to Fedora EPEL 6 updates-testing
dmtcp-2.1-2.el6
php-horde-Horde-Alarm-2.0.5-1.el6
php-horde-Horde-Auth-2.1.1-1.el6
php-horde-Horde-Browser-2.0.4-1.el6
php-horde-Horde-Cache-2.3.0-1.el6
php-horde-Horde-Cli-2.0.4-1.el6
php-horde-Horde-Compress-2.0.4-1.el6
php-horde-Horde-Compress-Fast-1.0.2-1.el6
php-horde-Horde-Crypt-2.4.0-1.el6
php-horde-Horde-Date-2.0.7-1.el6
php-horde-Horde-Db-2.0.4-1.el6
php-horde-Horde-Exception-2.0.4-1.el6
php-horde-Horde-Http-2.0.4-1.el6
php-horde-Horde-Icalendar-2.0.7-1.el6
php-horde-Horde-Image-2.0.5-2.el6
php-horde-Horde-Kolab-Format-2.0.5-1.el6
php-horde-Horde-Ldap-2.0.3-1.el6
php-horde-Horde-Log-2.1.0-1.el6
php-horde-Horde-Mail-2.1.2-1.el6
php-horde-Horde-Memcache-2.0.5-1.el6
php-horde-Horde-Mime-2.2.8-1.el6
php-horde-Horde-Perms-2.1.2-1.el6
php-horde-Horde-Prefs-2.5.2-1.el6
php-horde-Horde-Queue-1.1.1-1.el6
php-horde-Horde-SpellChecker-2.1.1-1.el6
php-horde-Horde-Stream-1.5.0-1.el6
php-horde-Horde-Stream-Filter-2.0.2-1.el6
php-horde-Horde-Support-2.1.1-1.el6
php-horde-Horde-Test-2.2.6-1.el6
php-horde-Horde-Text-Filter-2.2.0-1.el6
php-horde-Horde-Url-2.2.1-1.el6
php-horde-Horde-Vfs-2.1.2-2.el6
php-phpunit-DbUnit-1.3.0-1.el6
php-phpunit-File-Iterator-1.3.4-1.el6
php-phpunit-PHP-CodeCoverage-1.2.13-1.el6
php-phpunit-PHP-Invoker-1.1.3-2.el6
php-phpunit-PHP-Timer-1.0.5-1.el6
php-phpunit-PHP-TokenStream-1.2.1-1.el6
php-phpunit-PHPUnit-3.7.28-1.el6
php-phpunit-PHPUnit-Selenium-1.3.3-1.el6
python-dirq-1.5-1.el6
Details about builds:
dmtcp-2.1-2.el6 (FEDORA-EPEL-2014-0149)
Checkpoint/Restart functionality for Linux processes
Update Information:
Updated for upstream release 2.1.
ChangeLog:
* Fri Jan 10 2014 Kapil Arya ka...@ccs.neu.edu - 2.1-1
- Preparing for upstream release 2.1.
* Thu Dec 12 2013 Ville Skyttä ville.sky...@iki.fi - 1.2.8-2
- Install docs to %{_pkgdocdir} where available (#993726).
- Own package level doc dir.
php-horde-Horde-Alarm-2.0.5-1.el6 (FEDORA-EPEL-2014-0151)
Horde Alarm Libraries
Update Information:
Update various Horde components to latest upstream version.
ChangeLog:
* Tue Oct 22 2013 Remi Collet r...@fedoraproject.org - 2.0.5-1
- Update to 2.0.5
- add optional dependencies
php-horde-Horde-Auth-2.1.1-1.el6 (FEDORA-EPEL-2014-0151)
Horde Authentication API
Update Information:
Update various Horde components to latest upstream version.
ChangeLog:
* Tue Oct 15 2013 Remi Collet r...@fedoraproject.org - 2.1.1-1
- Update to 2.1.1
php-horde-Horde-Browser-2.0.4-1.el6 (FEDORA-EPEL-2014-0151)
Horde Browser API
Update Information:
Update various Horde components to latest upstream version.
ChangeLog:
* Tue Aug 27 2013 Remi Collet r...@fedoraproject.org - 2.0.4-1
- Update to 2.0.4
How to get packager sponsorship
Some thoughts: http://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html http://fedoraproject.org/PackageReviewStatus/ http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group There is a growing number of people in the NEEDSPONSOR queue, who have submitted a single package only and who don't attempt at doing a review of a different package in the various queues (not even a review of the own package). Many packager sponsors consider that a problem. I'm not the spokesperson of all packager sponsors, though. ;) It is not mandatory to hang out on IRC in hope of getting to know packager sponsors. Not all packager sponsors hang out on IRC either. So, what may work for some people may be seen as a hindrance by other new packagers. Following the various options in the HOWTO and searching the Fedora Account System (FAS) for packager sponsors has worked before, but requires a minimum amount of activity prior to contacting a packager sponsor privately. I highly recommend people in the NEEDSPONSOR queue to attempt at reviewing other packages in the NEW queue and to show at least some motivation. Especially if the self-submitted package is not free of packaging mistakes. Use the help of tools, such as fedora-review. Mention whether you've looked at mock and koji already. Please don't sit and wait for a sponsor for months without even trying to do a self-review of your own package. -- 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: How to get packager sponsorship
On Sun, Jan 12, 2014 at 10:29:54AM +0100, Michael Schwendt wrote: There is a growing number of people in the NEEDSPONSOR queue, who have submitted a single package only and who don't attempt at doing a review of a different package in the various queues (not even a review of the own package). Review your own package? I think the aim of the review process is, that a second one should have a look on your package to verify, that your package mmets the package guidelines and so on. Most people may be blind against thier onw mistakes, so it makes sense that anonther one take a look on the package which should introduced to Fedora. Best Regards: Jochen Schmitt -- 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: How to get packager sponsorship
Sometimes sponsorship is quite easy, this is unfair to other people around: https://bugzilla.redhat.com/show_bug.cgi?id=1048966 -- 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: How to get packager sponsorship
Hi, On Sun, Jan 12, 2014 at 3:46 PM, Jochen Schmitt joc...@herr-schmitt.dewrote: On Sun, Jan 12, 2014 at 10:29:54AM +0100, Michael Schwendt wrote: There is a growing number of people in the NEEDSPONSOR queue, who have submitted a single package only and who don't attempt at doing a review of a different package in the various queues (not even a review of the own package). Review your own package? New contributors can also review their own package and show what things they found in their package like how they found they have correct upstream source matching checksum, how they found license tag for their package, what rpmlint output they found etc. This applies even for other packages also waiting for review. But, here what Michael want to point out that people waiting for their package review who are also waiting for sponsorship should at least look into http://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html and provide their review findings so that other people will come to know any issues in their package and they can be updated/progressed further. I think the aim of the review process is, that a second one should have a look on your package to verify, that your package mmets the package guidelines and so on. For a new contributor, if he submitted many packages then whichever package first gets reviewed should get approved by sponsor member. Most people may be blind against thier onw mistakes, so it makes sense that anonther one take a look on the package which should introduced to Fedora. Regards, Parag -- 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: 20140112 changes
Compose started at Sun Jan 12 05:15:07 UTC 2014 Broken deps for i386 -- [OpenEXR_CTL] OpenEXR_CTL-1.0.1-16.fc20.i686 requires libImath.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIlmThread.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIlmImf.so.7 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIexMath.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libIex.so.6 OpenEXR_CTL-1.0.1-16.fc20.i686 requires libHalf.so.6 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIlmThread.so.6 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIlmImf.so.7 OpenEXR_CTL-libs-1.0.1-16.fc20.i686 requires libIex.so.6 [OpenEXR_Viewers] OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libImath-2_0.so.10 OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libIlmThread-2_0.so.10 OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libIlmImf-Imf_2_0.so.20 OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libIexMath-2_0.so.10 OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libIex-2_0.so.10 OpenEXR_Viewers-2.0.1-3.fc21.i686 requires libHalf.so.10 [R-maanova] R-maanova-1.30.0-2.fc20.i686 requires libRlapack.so R-maanova-1.30.0-2.fc20.i686 requires libRblas.so [derelict] derelict-tcod-3-20.20130626gite70c293.fc20.i686 requires tcod derelict-tcod-devel-3-20.20130626gite70c293.fc20.i686 requires tcod [gpsdrive] gpsdrive-2.11-20.fc20.i686 requires libgps.so.20 [gtkd] gtkd-2.0.0-29.20120815git9ae9181.fc18.i686 requires libphobos-ldc.so.60 [httpdtap] httpdtap-0.2-2.fc21.noarch requires kernel-debuginfo httpdtap-0.2-2.fc21.noarch requires httpd-debuginfo httpdtap-0.2-2.fc21.noarch requires apr-util-debuginfo httpdtap-0.2-2.fc21.noarch requires apr-debuginfo [kawa] 1:kawa-1.11-5.fc19.i686 requires servlet25 [koji] koji-vm-1.8.0-2.fc20.noarch requires python-virtinst [libghemical] libghemical-2.99.1-24.fc20.i686 requires libf77blas.so.3 libghemical-2.99.1-24.fc20.i686 requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.i686 requires libopenobex.so.1 [mojomojo] mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) [mpqc] mpqc-2.3.1-23.fc20.i686 requires libf77blas.so.3 mpqc-2.3.1-23.fc20.i686 requires libatlas.so.3 [netdisco] netdisco-1.1-6.fc20.noarch requires perl(SNMP::Info::Layer2::Bay) [nifti2dicom] nifti2dicom-0.4.6-3.fc20.i686 requires libvtksys.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkWidgets.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkVolumeRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkViews.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkTextAnalysis.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkParallel.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkInfovis.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkImaging.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkIO.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkHybrid.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkGraphics.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkGeovis.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkGenericFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkCommon.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libvtkCharts.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libitksys-4.4.so.1 nifti2dicom-0.4.6-3.fc20.i686 requires libitkopenjpeg-4.4.so.1 nifti2dicom-0.4.6-3.fc20.i686 requires libitkdouble-conversion-4.4.so.1 nifti2dicom-0.4.6-3.fc20.i686 requires libitkNetlibSlatec-4.4.so.1 nifti2dicom-0.4.6-3.fc20.i686 requires libgdcmMSFF.so.2.2 nifti2dicom-0.4.6-3.fc20.i686 requires libgdcmDICT.so.2.2 nifti2dicom-0.4.6-3.fc20.i686 requires libQVTK.so.5.10 nifti2dicom-0.4.6-3.fc20.i686 requires libITKznz-4.4.so.1 nifti2dicom-0.4.6-3.fc20.i686 requires libITKniftiio-4.4.so.1 nifti2dicom-0.4.6-3.fc20.i686 requires libITKgiftiio-4.4.so.1 nifti2dicom-0.4.6-3.fc20.i686 requires libITKWatersheds-4.4.so.1 nifti2dicom-0.4.6-3.fc20.i686 requires libITKVtkGlue-4.4.so.1 nifti2dicom-0.4.6-3.fc20.i686 requires libITKVideoIO-4.4.so.1 nifti2dicom-0.4.6-3.fc20.i686 requires libITKVideoCore-4.4.so.1 nifti2dicom-0.4.6-3.fc20.i686 requires libITKVTK-4.4.so.1 nifti2dicom-0.4.6-3.fc20.i686 requires libITKVNLInstantiation-4.4.so.1 nifti2dicom-0.4.6-3.fc20.i686 requires libITKStatistics-4.4.so.1 nifti2dicom-0.4.6-3.fc20.i686 requires
Re: How to get packager sponsorship
On 01/12/2014 10:29 AM, Michael Schwendt wrote: Some thoughts: http://fedoraproject.org/PackageReviewStatus/NEEDSPONSOR.html http://fedoraproject.org/PackageReviewStatus/ http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group There is a growing number of people in the NEEDSPONSOR queue, who have submitted a single package only and who don't attempt at doing a review of a different package in the various queues (not even a review of the own package). Many packager sponsors consider that a problem. I'm not the spokesperson of all packager sponsors, though. ;) Yes, I share this concern. Doing informal reviews is a significant part of getting sponsored. I'd expect packagers to review their own review requests (just to be sure, the first review doesn't fail for quite obvious reasons). Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Why authconfig create -ac files
I just wonder why `authconfig` creates: /etc/pam.d/system-auth - system-auth-ac /etc/pam.d/postlogin - postlogin-ac /etc/pam.d/password-auth - password-auth-ac etc. Why those links and why -ac suffix? Why it does not modify original files directly? Is there some story behind? Mirek -- 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: How to get packager sponsorship
On Sun, 12 Jan 2014 11:16:42 +0100, Jochen Schmitt wrote: There is a growing number of people in the NEEDSPONSOR queue, who have submitted a single package only and who don't attempt at doing a review of a different package in the various queues (not even a review of the own package). Review your own package? Of course! Everybody may review packages and even post the results. Approving packages is something else. I think the aim of the review process is, that a second one should have a look on your package to verify, that your package mmets the package guidelines and so on. Sure. That's the requirement for approval. You can only submit packages, which meet the guidelines, if you review your own package. ;) Most people may be blind against thier onw mistakes, so it makes sense that anonther one take a look on the package which should introduced to Fedora. According to that theory, they would introduce the same mistakes once the package has entered the collection, ... because there is no review process for updates/upgrades anymore. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 1-9-14 15:43:50 Ales Kozumplik wrote: New DNF release is out. See the blog [1], the release notes [2] and the F20 update [3]. Rawhide build went smooth this time too! I see this using 0.4.11. What am I doing wrong? garry@vfr$ sudo dnf --enablerepo=updates-testing update kernel\* [sudo] password for garry: Resolving dependencies -- Starting dependency resolution -- Finished dependency resolution Dependencies resolved. Nothing to do. garry@vfr$ sudo yum --enablerepo=updates-testing update kernel\* Loaded plugins: langpacks, refresh-packagekit [snip] Resolving Dependencies -- Running transaction check --- Package kernel.x86_64 0:3.12.7-300.fc20 will be installed --- Package kernel-devel.x86_64 0:3.12.7-300.fc20 will be installed --- Package kernel-headers.x86_64 0:3.12.6-300.fc20 will be updated --- Package kernel-headers.x86_64 0:3.12.7-300.fc20 will be an update -- Finished Dependency Resolution -- Finding unneeded leftover dependencies Found and removing 0 unneeded dependencies -- Running transaction check --- Package kernel.x86_64 0:3.11.8-200.fc19 will be erased --- Package kernel-devel.x86_64 0:3.11.8-200.fc19 will be erased -- Finished Dependency Resolution Dependencies Resolved PackageArch VersionRepository Size Installing: kernel x86_64 3.12.7-300.fc20updates-testing 30 M kernel-devel x86_64 3.12.7-300.fc20updates-testing 8.5 M Updating: kernel-headers x86_64 3.12.7-300.fc20updates-testing 913 k Removing: kernel x86_64 3.11.8-200.fc19@updates/19 128 M kernel-devel x86_64 3.11.8-200.fc19@updates/19 31 M Transaction Summary Install 2 Packages Upgrade 1 Package Remove 2 Packages Total download size: 40 M Is this ok [y/d/N]: n Exiting on user command Your transaction was saved, rerun it with: yum load-transaction /tmp/yum_save_tx.2014-01-12.11-20.aiCKeH.yumtx garry@vfr$ sudo dnf clean all Cleaning repos: fedora rpmfusion-free-updates adobe-linux-x86_64 : rpmfusion-nonfree-updates rpmfusion-free updates google-chrome : rpmfusion-nonfree Cleaning up Everything garry@vfr$ sudo dnf --enablerepo=updates-testing upgrade kernel\* Fedora 20 - x86_64 144 kB/s | 36 MB 04:14 RPM Fusion for Fedora 20 - Free - Updates97 kB/s | 72 kB 00:00 Adobe Systems Incorporated 8.7 kB/s | 1.8 kB 00:00 RPM Fusion for Fedora 20 - Nonfree - Updates 29 kB/s | 13 kB 00:00 RPM Fusion for Fedora 20 - Free 124 kB/s | 487 kB 00:03 Fedora 20 - x86_64 - Updates125 kB/s | 12 MB 01:38 google-chrome26 kB/s | 3.1 kB 00:00 RPM Fusion for Fedora 20 - Nonfree 113 kB/s | 289 kB 00:02 Resolving dependencies -- Starting dependency resolution -- Finished dependency resolution Dependencies resolved. Nothing to do. garry@vfr$ -- Garry T. Williams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 1-12-14 11:39:35 Rahul Sundaram wrote: On Sun, Jan 12, 2014 at 11:30 AM, Garry T. Williams wrote: On 1-9-14 15:43:50 Ales Kozumplik wrote: New DNF release is out. See the blog [1], the release notes [2] and the F20 update [3]. Rawhide build went smooth this time too! I see this using 0.4.11. What am I doing wrong? http://dnf.baseurl.org/2014/01/02/dnf-update-and-yum-update-produce-different-output/ Yes, I have reviewed all that. That reference says, The bottom line is: unless a real update problem occurs (i.e. DNF refuses to update a package that Yum updates) with the same set of metadata (dnf clean all; yum clean all), this is not an issue. I did dnf clean all and the updates-testing package is still not found by dnf. Hey, I'm just testing. It looks like a bug, but I wanted to see if I was overlooking something. -- Garry T. Williams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Inter-WG coordination: Stable application runtimes
Adam Williamson wrote: I'm coming to the conclusion that at some point distros have to give up swimming against the tide and just say, look, if this is the way this ecosystem wants to go, then it's your problem. Fedora's job for such ecosystems would simply be to make sure their distribution mechanism works on top of Fedora - if it's one we care about - and then butt out. I'm not sure we're achieving anything practical for anyone by bending PHP / Java / nodejs / Ruby packages 120 degrees out of shape to conform to Fedora's packaging guidelines (often at the cost that we have to turn stuff off, or break stuff, or be months or years behind upstream, or be massively incomplete), and I say this as someone who's spent the last couple of weeks whacking on a PHPland stack (Owncloud) with a wrench to achieve precisely that. At that point, we can just close shop, we are no longer fulfilling our role as a distribution. I also agree completely with Nicolas Mailhot's reply: That is NOT what our users want! Making the software conform to packaging best practices is exactly what we packagers are for. It is the only way to deploy software in a reliable, well-integrated, secure and space-efficient way. Having multiple competing deployment systems on the same machine invariably leads to integration issues (where the ones stacked on top can get surprised when a lower-level system changes or removes something like a system library, say because the user accidentally removed it, not knowing that something outside of the system package management requires it). And the security and disk space implications of bundling have been discussed many times already. So, like Matthew Miller, I think we cannot possibly punt on this issue, but I totally DISAGREE with his proposed solution of endorsing those bundling systems officially. Instead, we need to continue packaging things properly. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Inter-WG coordination: Stable application runtimes
On Sun, 2014-01-12 at 18:55 +0100, Kevin Kofler wrote: Adam Williamson wrote: I'm coming to the conclusion that at some point distros have to give up swimming against the tide and just say, look, if this is the way this ecosystem wants to go, then it's your problem. Fedora's job for such ecosystems would simply be to make sure their distribution mechanism works on top of Fedora - if it's one we care about - and then butt out. I'm not sure we're achieving anything practical for anyone by bending PHP / Java / nodejs / Ruby packages 120 degrees out of shape to conform to Fedora's packaging guidelines (often at the cost that we have to turn stuff off, or break stuff, or be months or years behind upstream, or be massively incomplete), and I say this as someone who's spent the last couple of weeks whacking on a PHPland stack (Owncloud) with a wrench to achieve precisely that. At that point, we can just close shop, we are no longer fulfilling our role as a distribution. I also agree completely with Nicolas Mailhot's reply: That is NOT what our users want! Making the software conform to packaging best practices is exactly what we packagers are for. It is the only way to deploy software in a reliable, well-integrated, secure and space-efficient way. Having multiple competing deployment systems on the same machine invariably leads to integration issues (where the ones stacked on top can get surprised when a lower-level system changes or removes something like a system library, say because the user accidentally removed it, not knowing that something outside of the system package management requires it). And the security and disk space implications of bundling have been discussed many times already. So, like Matthew Miller, I think we cannot possibly punt on this issue, but I totally DISAGREE with his proposed solution of endorsing those bundling systems officially. Instead, we need to continue packaging things properly. Have you looked at what people are installing on Fedora lately? Have you looked at how much PHP stuff there is out there vs. what we have packaged 'properly'? Java? Ruby? Do you know anyone who deploys Wordpress plugins via distribution packages? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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: Inter-WG coordination: Stable application runtimes
Am 12.01.2014 19:39, schrieb Adam Williamson: Have you looked at what people are installing on Fedora lately? Have you looked at how much PHP stuff there is out there vs. what we have packaged 'properly'? Java? Ruby? Do you know anyone who deploys Wordpress plugins via distribution packages? that has other reasons on a typical webserver you have not *the* wordpress and *the* wordpress plugins - you have 10,20,30,100,500 *independent* wordpress setups for production the only case where you can use distribution packages is if you have a dedicated machines / VM serving only one website signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 1-12-14 18:18:00 M A Young wrote: On Sun, 12 Jan 2014, Garry T. Williams wrote: On 1-9-14 15:43:50 Ales Kozumplik wrote: New DNF release is out. See the blog [1], the release notes [2] and the F20 update [3]. Rawhide build went smooth this time too! I see this using 0.4.11. What am I doing wrong? garry@vfr$ sudo dnf --enablerepo=updates-testing update kernel\* [sudo] password for garry: Resolving dependencies -- Starting dependency resolution -- Finished dependency resolution Dependencies resolved. Nothing to do. Try dnf clean expire-cache first. I don't think dnf checks whether its metadata is up to date as frequently as yum does. Ha! That was it. sudo dnf --enablerepo=updates-testing clean expire-cache sudo dnf --enablerepo=updates-testing upgrade kernel\* did the trick. -- Garry T. Williams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 12 January 2014 21:06, Garry T. Williams gtwilli...@gmail.com wrote: On 1-12-14 18:18:00 M A Young wrote: On Sun, 12 Jan 2014, Garry T. Williams wrote: On 1-9-14 15:43:50 Ales Kozumplik wrote: New DNF release is out. See the blog [1], the release notes [2] and the F20 update [3]. Rawhide build went smooth this time too! I see this using 0.4.11. What am I doing wrong? garry@vfr$ sudo dnf --enablerepo=updates-testing update kernel\* [sudo] password for garry: Resolving dependencies -- Starting dependency resolution -- Finished dependency resolution Dependencies resolved. Nothing to do. Try dnf clean expire-cache first. I don't think dnf checks whether its metadata is up to date as frequently as yum does. Ha! That was it. sudo dnf --enablerepo=updates-testing clean expire-cache sudo dnf --enablerepo=updates-testing upgrade kernel\* did the trick. 'dnf clean all' does what 'clean expire-cache' does, and more. (check the man page) It could be that dnf picked another mirror this time, or it used the same mirror and that mirror has synced with the master mirror(s). -- Garry T. Williams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Ahmad Samir -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 1-12-14 11:30:31 you wrote: On 1-9-14 15:43:50 Ales Kozumplik wrote: New DNF release is out. See the blog [1], the release notes [2] and the F20 update [3]. Rawhide build went smooth this time too! I see this using 0.4.11. What am I doing wrong? [snip] garry@vfr$ sudo dnf clean all Cleaning repos: fedora rpmfusion-free-updates adobe-linux-x86_64 : rpmfusion-nonfree-updates rpmfusion-free updates google-chrome : rpmfusion-nonfree Cleaning up Everything garry@vfr$ sudo dnf --enablerepo=updates-testing upgrade kernel\* The real problem was not including the updates-testing repo in the clean all command. And yes, as Michael commented, dnf doesn't expire meta-data as often as yum. -- Garry T. Williams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Inter-WG coordination: Stable application runtimes
On 10.01.2014 21:12, Matthew Miller wrote: On Thu, Jan 09, 2014 at 07:58:44PM -0800, Adam Williamson wrote: So the question becomes, what is it appropriate for a distribution to do in this situation? My personal opinion is that what's appropriate for a distribution to do is also, happily, what's easiest for a distribution to do: punt on it. Entirely punt on the whole thing. And, this ultimately makes a better experience for users, because if Fedora's included tools are aware of the native packaging system, we can do things like system auditing, security alerts (if not updates), maybe even integration with selinux policy. Basically, we don't hammer all of the possible universe into the distribution model, and we don't include all of the packages of everything in the base Fedora distribution as RPMs, but we do include those ecosystems in the Fedora _Project_, including the tools and documentation to make them feel natural. Your expression ... tools aware of the native packaging system and the Andrew comment about the pip behaviors above in the thread, encouraged me to share my big hammer of the DB plumber style :-) opinion on the problem. TL;DR: What follows is SCC: An idea for optional DB and service which caches bits from YumDB, the local state (RPMDB and /etc) plus the native systems like NPM in the unified way for the purposes of planning, resolving and performing system state transitions. Initially I meant to say just few words to mark the possibility, but obviously my English and talent for easy for reading and well focused messages are both far from good, so the whole thing become too long and I am going to split some additional notes into self replays - Excuses! RPMDB and YumDB are two rich datasets present on every Fedora instance representing respectively the local state and distribution+ state of the package universe. '+' because +Fusion*, +COPRs, +LocalOrg, etc. Unfortunately they are somewhat hidden in the dark, because lack of interfaces - we even missing SVG or other explorer for the YumDB graph. The (let think of them as virtual) Maven DB, PyPI DB, NPM DB, LuaRocks DB, etc, technically are subsets of YumDB (in sense richness of encoded logical relations between the DB nodes used in their schemes - e.g. PyPI DB, before the pip egg, do not knows which file from which module comes, nor have the concept of higher than package NV granularity of the requirement points - Provides and Requires in YumDB). Also, the depsolving of the native packaging systems is less sophisticated than both current yum and hawkey ones. These observation naturally lead to the idea of SCC: System Configuration Cache DB representing the merge of RPMDB, YumDB and e.g. local pip egs, PyPI DB (if e.g. additional python modules/versions are needed for the given deployment) where the depsolving could be shifted, somewhat in the same fashion as Data warehouse solutions are used in the enterprises for merging the significant datasets from various ERP systems into single DB for interactive time reporting and decision making. I am using the term SCC (vs. e.g. UPMC: Unified Package Metadata Cache) in attempt to cover a (paraphrased) Mirek question from the beginning of the thread - OK, we have Fedora and PyPI integrated, at one point of the time for a given instance, the Fedora packaged module has been chosen. What happens if we upgrade Fedora along with am incompatible version this Python module for given installed service - obviously we need to register in the SCC the dependencies of the installed machine roles with the same effect like Require clauses in the our packages, so the SCC machinery to validate (with negative result in this described case) the yum upgrade or to resolve the upgrade including installation of newest available compatible version from PyPI as an alternative provision during upgrade preparation. Further, I think that ideally SCC should parse/absorb as much as possible system object properties and relations from /etc (plus /lib and /var configuration areas) to allow sysadmins and devops to inject rules for effective use of these sets latter in the depsolving (and other DB functionality). That said, the integration with OpenLMI, or even implementing the whole thing under the OpenLMI umbrella, both seems natural. So, finally on that road we have: - choice for good enough DB engine for SCC, query language, compiler [*], etc. design decisions like sync protocol and plugable data sources. - Yum/RPM datasets: optional rpm, yum, hawkey hooks for syncing their DBs, alternatively just sync tools. - optional pip, npm, luarocks, etc. hooks for the same, alternatively just sync tools. - OpenLMI integration for absorbing system configuration, alternatively just Augeas import + transformation rules to sync the DB representation of the system objects. - sccd capable to: - depsolving (on top of cumulative - YumDB + native managers DBs, preferably providing interfaces to the system
Re: dnf-0.4.11
On 1-12-14 20:27:26 Reindl Harald wrote: dnf clean all without dnf --enablerepo=updates-testing clean all does exactly *nothing* in case of updates-testing, the same for YUM simply because folders of non-enabled repos are not relevant for any operation Yeah, I feel pretty stupid now. -- Garry T. Williams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
Am 12.01.2014 21:38, schrieb Garry T. Williams: On 1-12-14 20:27:26 Reindl Harald wrote: dnf clean all without dnf --enablerepo=updates-testing clean all does exactly *nothing* in case of updates-testing, the same for YUM simply because folders of non-enabled repos are not relevant for any operation Yeah, I feel pretty stupid now no - the better question is why all does not mean really *all* however, instead of yum clean all i use rm -rf /var/cache/yum/* for al least 7 years because *that* means really all, in case of DNF most likely rm -rf /var/cache/dnf/* would be required signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Inter-WG coordination: Stable application runtimes
On 12.01.2014 22:34, Alek Paunov wrote: [*] Crucial aspect of any sophisticated data management system is the data query and manipulation language. Unfortunately the choices are rather limited - Imperative approaches (recently resurrected by some NoSQL DBs) are weak and error prone; SQL and few more text prose languages have proven their incompatibility with the vast majority of the developers (these without years of specific experience around the data volumes processing). The predominant workaround seems to be ORMs, but ORMs and sophisticated/fast should not be mixed in same project :-). My personal preference leans towards rules approach (which e.g. is also adopted by at least one of the ERP innovation leaders - LogicBlox) and especially its variant of visual rules definition UIs, where the user describes dependencies (relations) between source and result trees of a operations using blocks and arrows, and then the compiler lowers the the whole transaction definition to executable (by the DB engine), procedure. IMHO, such kind of visual interface would be one of the possible adequate languages (Adequate to the DB specialization level of our target audience, including big share of the developers). My personal preferences for the lower level executable language and DB engine are LuaJIT procedures on top of SQlite4/LSM C API. -- 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: Grub installation. First potential Fedora killer
Installer sees the partitions of other Linuxes. But when rebooting after installation Fedora was the only choice. Running grub2-mkconfig fixed it, ie other distribution became available. Sort of. Problems: 1) Fedora was the default and there is no easy way (that is without reading the 150+ pages of Grub documentation to change that) 2) If user does not know about grub2-mkconfig he will believe he is trapped in Fedora and will be very, very angry 3) Every time he runs the other distribution and updates it he needs to rebooot into Fedora and run grub2-mkconfig On Mon, 6 Jan 2014 15:28:34 -0700 Chris Murphy li...@colorremedies.com wrote: On Jan 6, 2014, at 2:35 PM, Jean François Martinez jfm...@free.fr wrote: Centos 6 wasn't detected at install time. This is rather vague. Do you mean the installer doesn't see any of the CentOS partitions/LVs? Or CentOS isn't included as a grub menu item after installing Fedora 20? Chris Murphy -- Jean François Martinez jfm...@free.fr -- 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: Inter-WG coordination: Stable application runtimes - SCC: Fedora social
On 12.01.2014 22:34, Alek Paunov wrote: - sccd-web: WebUI exposing full functionality, alternatively Cockpit (OpenLMI WebUI) extension. ... - NTH: SCC local state inheritance between instances Fedora Social: Almost every developer or sysadmins like to demonstrate how clean and clever is his own design :-). Currently we do not have a service where Sandra, Joe and George [1] could: - show and share with the others their Fedora based setups - conveniently keep the setup for their own reuse in the future Once we have sccd-web and few NTHs, we will be nearly (at least as code) equipped to provide something like github for Fedora setups for publishing, referring in the e-mails and forking Fedora users work. [1] http://fedoraproject.org/wiki/Server/Personas -- 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: Inter-WG coordination: Stable application runtimes - SCC
On Jan 12, 2014, at 1:51 PM, Alek Paunov a...@declera.com wrote: Once we apply FS snapshotting, combined with the SCC NTHs above, there are at least two appealing use-cases: - reusing one base e.g. F20 server container image for both the host and the incompatible containers (e.g. when one application requires nodejs 0.8 and another nodejs 0.10) - easy testbed for resolving the upgrade path for an existing, possibly non pure Fedora server with care about the deployed services. I agree, there are quite a few use cases for file system snapshots. Do the snapshots need to be bootable? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 01/12/2014 08:27 PM, Reindl Harald wrote: dnf clean all without dnf --enablerepo=updates-testing clean all does exactly*nothing* in case of updates-testing, the same for YUM simply because folders of non-enabled repos are not relevant for any operation And is this correct behavior? (and yum behaves same way, so same question apply to yum as well). Man page for yum state: yum clean metadata Eliminate all of the files which yum uses to determine the remote availability of packages. Using this option will force yum to download all the metadata the next time it is run. There is no statement that it apply only for *currently enabled* repository. I would expect that it clean *all* metadata. I was recently very surprised that when I done : # rpm -q yum yum-3.4.3-128.fc20.noarch # yum clean all ... # du -sh /var/cache/yum/x86_64/* 225M/var/cache/yum/x86_64/19 111M/var/cache/yum/x86_64/20 406M/var/cache/yum/x86_64/rawhide that there is a lot of data in /var. To be precise - after this operation I would expect that /var/cache/yum/x86_64/ would have zero size. And not 730 MB. DNF is on the same boat: # rpm -q dnf dnf-0.4.9-1.fc20.noarch # dnf clean all Cleaning repos: fedora rpmfusion-free-updates adobe-linux-x86_64 Dropbox rpmfusion-nonfree-updates rpmfusion-free updates rpmfusion-nonfree Cleaning up Everything # du -sh /var/cache/dnf/x86_64/* 114M/var/cache/dnf/x86_64/19 34M /var/cache/dnf/x86_64/20 Do others feel that this is correct or incorrect behavior? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
Am 12.01.2014 22:42, schrieb Miroslav Suchy: On 01/12/2014 08:27 PM, Reindl Harald wrote: dnf clean all without dnf --enablerepo=updates-testing clean all does exactly *nothing* in case of updates-testing, the same for YUM simply because folders of non-enabled repos are not relevant for any operation And is this correct behavior? (and yum behaves same way, so same question apply to yum as well). no, i only explained the current state of play looking at the word all and it's meaing clearly *no* looking at the thread and result of the behavior clearely *no* looking at that people use updates-testing with --enablerepo *no* looking at the fact that i do not trust the word all clearly *no* Man page for yum state: yum clean metadata Eliminate all of the files which yum uses to determine the remote availability of packages. Using this option will force yum to download all the metadata the next time it is run. There is no statement that it apply only for *currently enabled* repository. I would expect that it clean *all* metadata. I was recently very surprised that when I done : # rpm -q yum yum-3.4.3-128.fc20.noarch # yum clean all ... # du -sh /var/cache/yum/x86_64/* 225M/var/cache/yum/x86_64/19 111M/var/cache/yum/x86_64/20 406M/var/cache/yum/x86_64/rawhide that there is a lot of data in /var. To be precise - after this operation I would expect that /var/cache/yum/x86_64/ would have zero size. And not 730 MB. and that is why i switched 7 years ago to rm -rf /var/cache/yum* signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
I have come to understand that for yum, commands like clean only applies to the actual buildroot. So without a -r argument, the cleaning is done on the default root, whatever this might be(?). Actually, there is probably nothing wrong with this - it works fine when using the -r option. Problems comes without it, when one thinks it applies to all buildroots. It would perhaps make sense outputting something like Using buildroot foo when there is no -r on the command line(?). On Sun, Jan 12, 2014 at 10:47 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 12.01.2014 22:42, schrieb Miroslav Suchy: On 01/12/2014 08:27 PM, Reindl Harald wrote: dnf clean all without dnf --enablerepo=updates-testing clean all does exactly *nothing* in case of updates-testing, the same for YUM simply because folders of non-enabled repos are not relevant for any operation And is this correct behavior? (and yum behaves same way, so same question apply to yum as well). no, i only explained the current state of play looking at the word all and it's meaing clearly *no* looking at the thread and result of the behavior clearely *no* looking at that people use updates-testing with --enablerepo *no* looking at the fact that i do not trust the word all clearly *no* Man page for yum state: yum clean metadata Eliminate all of the files which yum uses to determine the remote availability of packages. Using this option will force yum to download all the metadata the next time it is run. There is no statement that it apply only for *currently enabled* repository. I would expect that it clean *all* metadata. I was recently very surprised that when I done : # rpm -q yum yum-3.4.3-128.fc20.noarch # yum clean all ... # du -sh /var/cache/yum/x86_64/* 225M/var/cache/yum/x86_64/19 111M/var/cache/yum/x86_64/20 406M/var/cache/yum/x86_64/rawhide that there is a lot of data in /var. To be precise - after this operation I would expect that /var/cache/yum/x86_64/ would have zero size. And not 730 MB. and that is why i switched 7 years ago to rm -rf /var/cache/yum* -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
from a developers point of view the current behavior is clear and perfect what is not enabled is handeled as it would not exist means: repos with enabled=0 are completly ignored until --enablrepo with no but and if - clear and straight logical decision from a users point of view all has a different meaning well, i can live with both because i am developer and i know how these things are working, i know that the codebase is much cleaner the way it works currently personally i would draw the line in case if it is my code and act like the user expects it, not in general, but in that case of meaningless data which are refreshed and no bad impact if lost Am 12.01.2014 22:57, schrieb Alec Leamas: I have come to understand that for yum, commands like clean only applies to the actual buildroot. So without a -r argument, the cleaning is done on the default root, whatever this might be(?). Actually, there is probably nothing wrong with this - it works fine when using the -r option. Problems comes without it, when one thinks it applies to all buildroots. It would perhaps make sense outputting something like Using buildroot foo when there is no -r on the command line(?). On Sun, Jan 12, 2014 at 10:47 PM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: Am 12.01.2014 22:42, schrieb Miroslav Suchy: On 01/12/2014 08:27 PM, Reindl Harald wrote: dnf clean all without dnf --enablerepo=updates-testing clean all does exactly *nothing* in case of updates-testing, the same for YUM simply because folders of non-enabled repos are not relevant for any operation And is this correct behavior? (and yum behaves same way, so same question apply to yum as well). no, i only explained the current state of play looking at the word all and it's meaing clearly *no* looking at the thread and result of the behavior clearely *no* looking at that people use updates-testing with --enablerepo *no* looking at the fact that i do not trust the word all clearly *no* Man page for yum state: yum clean metadata Eliminate all of the files which yum uses to determine the remote availability of packages. Using this option will force yum to download all the metadata the next time it is run. There is no statement that it apply only for *currently enabled* repository. I would expect that it clean *all* metadata. I was recently very surprised that when I done : # rpm -q yum yum-3.4.3-128.fc20.noarch # yum clean all ... # du -sh /var/cache/yum/x86_64/* 225M/var/cache/yum/x86_64/19 111M/var/cache/yum/x86_64/20 406M/var/cache/yum/x86_64/rawhide that there is a lot of data in /var. To be precise - after this operation I would expect that /var/cache/yum/x86_64/ would have zero size. And not 730 MB. and that is why i switched 7 years ago to rm -rf /var/cache/yum* signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Grub installation. First potential Fedora killer
On Jan 12, 2014, at 1:58 PM, Jean François Martinez jfm...@free.fr wrote:
Installer sees the partitions of other Linuxes. But when rebooting after
installation Fedora was the only choice.
Running grub2-mkconfig fixed it, ie other distribution became available.
Sort of. Problems:
1) Fedora was the default and there is no easy way (that is without reading
the 150+ pages of Grub documentation to change that)
2) If user does not know about grub2-mkconfig he will believe he is
trapped in Fedora and will be very, very angry
3) Every time he runs the other distribution and updates it he needs to
rebooot into Fedora and run grub2-mkconfig
Right, I didn't mean to indicate that multiboot on linux doesn't completely
suck, or that linux distros are friendly to each other rather than behaving in
a cannibalistic fashion by default. GRUB2 really isn't meant for mortal users,
just for the members of the lunacy asylum, so this really should work better
than it does yet here we are.
Is this computer by any chance UEFI firmware based? Or is it BIOS? That matters.
On BIOS what's supposed to happen is anaconda calls grub2-mkconfig which in
turn uses os-prober to find other OS's and create something sensible in
grub.cfg. That doesn't always work for various reasons, in particular on UEFI.
What you're probably better off doing, is editing /etc/grub.d/40_custom to add
a very basic entry to locate the CentOS grub.conf. Something like this:
menuentry 'CentOS menu' {
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4
--hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4
d7bc9d0e-7706-44f9-b1a7-ff24b7c360a7
legacyconfigfile $prefix/grub.conf
}
Not all hints are needed. Obviously change hd0,gpt4 with the right hint for the
hard drive and partition and partition scheme for where CentOS /boot is
located. The important one, really, is the UUID at the end, which is the file
system UUID for the CentOS boot partition (or rootfs if /boot is a directory on
root). The legacyconfigfile command allows GRUB2 to read legacy GRUB
configuration files. $prefix you should replace with /boot/grub if /boot is a
directory on rootfs or /grub if it's on its own partition.
Now grub2-mkconfig -o /boot/grub2/grub.cfg and this entry will be added to your
Fedora 20 grub.cfg. You'll get an entry that points to the CentOS menu. If you
choose it, the CentOS menu list of kernels should appear. If you want to make
this a default behavior, you'll need to read about $menuentry_id_option for
your CentOS menu entry in the Fedora grub.cfg. By giving it a unique ID, you
can then specify it as the default by that same id in /etc/default/grub.
Yes it's like pulling teeth.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
Well, IMHO the docs are actually quite clear on that 'all' refers to all metadata rather than all repositories. That said, perhaps enough people has been confused by this to make some kind of improvement motivated. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On Sun, Jan 12, 2014 at 5:23 PM, Alec Leamas wrote: Well, IMHO the docs are actually quite clear on that 'all' refers to all metadata rather than all repositories. That said, perhaps enough people has been confused by this to make some kind of improvement motivated. I am pretty sure if you flip the current behavior and make 'clean all' act on disabled repos, some other subset of users (e.g. me) will be confused. Best, Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
Am 13.01.2014 00:17, schrieb Orcan Ogetbil: On Sun, Jan 12, 2014 at 5:23 PM, Alec Leamas wrote: Well, IMHO the docs are actually quite clear on that 'all' refers to all metadata rather than all repositories. That said, perhaps enough people has been confused by this to make some kind of improvement motivated. I am pretty sure if you flip the current behavior and make 'clean all' act on disabled repos, some other subset of users (e.g. me) will be confused please explain how you would be confused clean all would only delete metadata which are anyways refreshed at the next call with whatever repo enabled and clean all is there to make sure that *all* metadata is refreshed instead use maybe outdated signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
First of all, this is not, and have never been a question of disabled repos. Or should not have. yum clean all refers to cleaning all metadata, not all repos. It only operates on one single repo, be it implicit (the default link) or an explicit -r option. This is what confuses. I know: been there done that... Even though the documents are clear, the behaviour does indeed cause confusion for some reason even though it's well-defined. Of course, changing semantics for yum is a bad idea, agreed. I did not have anything like that in mind. At most, some info on what buildroot which is used in the output, or similar measures. For dnf, I guess one could possibly think somewhat more free. Personally, I tend to think that it's the implicit buildroot which causes much of this trouble. What happens if we get rid of the implcit buildroot, forcing us to specify it every time? With 'default' as a legal option? Personally, I tend to think this might make things a little clearer. Just my 5 öre --alec On Mon, Jan 13, 2014 at 12:17 AM, Orcan Ogetbil oget.fed...@gmail.comwrote: On Sun, Jan 12, 2014 at 5:23 PM, Alec Leamas wrote: Well, IMHO the docs are actually quite clear on that 'all' refers to all metadata rather than all repositories. That said, perhaps enough people has been confused by this to make some kind of improvement motivated. I am pretty sure if you flip the current behavior and make 'clean all' act on disabled repos, some other subset of users (e.g. me) will be confused. Best, Orcan -- 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: dnf-0.4.11
Am 13.01.2014 00:43, schrieb Alec Leamas: First of all, this is not, and have never been a question of disabled repos. Or should not have. yum clean all refers to cleaning all metadata, not all repos. It only operates on one single repo, be it implicit (the default link) or an explicit -r option. This is what confuses. I know: been there done that... Even though the documents are clear, the behaviour does indeed cause confusion for some reason even though it's well-defined. Of course, changing semantics for yum is a bad idea, agreed. I did not have anything like that in mind. At most, some info on what buildroot which is used in the output, or similar measures. For dnf, I guess one could possibly think somewhat more free. Personally, I tend to think that it's the implicit buildroot which causes much of this trouble. What happens if we get rid of the implcit buildroot, forcing us to specify it every time? With 'default' as a legal option? Personally, I tend to think this might make things a little clearer. *what* is a buildroot in case of YUM/DNF? in any case nothing relevant for a user and said that i use Fedora and YUM for many years, the only conetxt of buildroot for me is rpmbuild and that has no context to YUM/DNF at all signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
Yes, sorry, forget what I wrote. I messed up mock with yum, that's why. It's too late for me to chime in here. Sorry for the noise. On Mon, Jan 13, 2014 at 12:49 AM, Reindl Harald h.rei...@thelounge.netwrote: Am 13.01.2014 00:43, schrieb Alec Leamas: First of all, this is not, and have never been a question of disabled repos. Or should not have. yum clean all refers to cleaning all metadata, not all repos. It only operates on one single repo, be it implicit (the default link) or an explicit -r option. This is what confuses. I know: been there done that... Even though the documents are clear, the behaviour does indeed cause confusion for some reason even though it's well-defined. Of course, changing semantics for yum is a bad idea, agreed. I did not have anything like that in mind. At most, some info on what buildroot which is used in the output, or similar measures. For dnf, I guess one could possibly think somewhat more free. Personally, I tend to think that it's the implicit buildroot which causes much of this trouble. What happens if we get rid of the implcit buildroot, forcing us to specify it every time? With 'default' as a legal option? Personally, I tend to think this might make things a little clearer. *what* is a buildroot in case of YUM/DNF? in any case nothing relevant for a user and said that i use Fedora and YUM for many years, the only conetxt of buildroot for me is rpmbuild and that has no context to YUM/DNF at all -- 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: Inter-WG coordination: Stable application runtimes
On Sun, 2014-01-12 at 19:43 +0100, Reindl Harald wrote: Am 12.01.2014 19:39, schrieb Adam Williamson: Have you looked at what people are installing on Fedora lately? Have you looked at how much PHP stuff there is out there vs. what we have packaged 'properly'? Java? Ruby? Do you know anyone who deploys Wordpress plugins via distribution packages? that has other reasons on a typical webserver you have not *the* wordpress and *the* wordpress plugins - you have 10,20,30,100,500 *independent* wordpress setups for production the only case where you can use distribution packages is if you have a dedicated machines / VM serving only one website Sure, but that just backs up my point further. Even in the case where you have an 'appliance' style setup, you _can_ use distro packages, but why would you bother? If it's a single-purpose system then you don't get much benefit from doing so. Does RH base pre-rolled openshift gears on Fedora or RHEL distribution packages? I don't think so. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- 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: Inter-WG coordination: Stable application runtimes
On Sun, 2014-01-12 at 20:58 +0100, Till Maas wrote: On Sun, Jan 12, 2014 at 10:39:19AM -0800, Adam Williamson wrote: On Sun, 2014-01-12 at 18:55 +0100, Kevin Kofler wrote: So, like Matthew Miller, I think we cannot possibly punt on this issue, but I totally DISAGREE with his proposed solution of endorsing those bundling systems officially. Instead, we need to continue packaging things properly. Have you looked at what people are installing on Fedora lately? Have you looked at how much PHP stuff there is out there vs. what we have packaged 'properly'? Java? Ruby? Do you know anyone who deploys Wordpress plugins via distribution packages? Even if people do it, it does not meant that it is the best way to do it. Mixed packaging makes it a lot harder to properly update in case of security vulnerabilities. E.g. instead of only checking/ensuring proper RPM updates one need to check each distribution method for regular updates. Is there even some tooling available to check/update all e.g. rbenv or virtualenv setups properly? You're preaching to the choir. But if in practice people really don't deploy things via the distribution packages, it doesn't matter how awesomely secure the distribution packages are. Something that you're not using is never providing you with any additional security. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
non-responsive maintainer
I haven't been able to get in touch with Silas Sewell (silas) by email or by bugzilla. He is the owner of quite a few packages but I'm primarily only interested in two. They are redis and python-redis. They are both out of date and I'd like to see them get updated in EPEL. Here links to the bugzilla tickets: https://bugzilla.redhat.com/show_bug.cgi?id=1000697 https://bugzilla.redhat.com/show_bug.cgi?id=923970 I have never maintained packages in EPEL before but I wouldn't mind learning how. Either way I'd like to see these packages get updated. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 12 January 2014 21:27, Reindl Harald h.rei...@thelounge.net wrote: Am 12.01.2014 20:24, schrieb Ahmad Samir: On 12 January 2014 21:06, Garry T. Williams gtwilli...@gmail.com wrote: On 1-12-14 18:18:00 M A Young wrote: On Sun, 12 Jan 2014, Garry T. Williams wrote: On 1-9-14 15:43:50 Ales Kozumplik wrote: New DNF release is out. See the blog [1], the release notes [2] and the F20 update [3]. Rawhide build went smooth this time too! I see this using 0.4.11. What am I doing wrong? garry@vfr$ sudo dnf --enablerepo=updates-testing update kernel\* [sudo] password for garry: Resolving dependencies -- Starting dependency resolution -- Finished dependency resolution Dependencies resolved. Nothing to do. Try dnf clean expire-cache first. I don't think dnf checks whether its metadata is up to date as frequently as yum does. Ha! That was it. sudo dnf --enablerepo=updates-testing clean expire-cache sudo dnf --enablerepo=updates-testing upgrade kernel\* did the trick. 'dnf clean all' does what 'clean expire-cache' does, and more. (check the man page) dnf clean all without dnf --enablerepo=updates-testing clean all does exactly *nothing* in case of updates-testing, the same for YUM simply because folders of non-enabled repos are not relevant for any operation Right, I missed that bit. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Ahmad Samir -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
where to report bad dracut man page content
https://bugzilla.novell.com/show_bug.cgi?id=858448 is openSUSE bug. Is upstream better for a rough parallel for Fedora, or bugzilla.redhat.com, or something else? If upstream, where exactly is upstream for reporting poor man page content? -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On 01/12/2014 11:23 PM, Alec Leamas wrote: Well, IMHO the docs are actually quite clear on that 'all' refers to all metadata rather than all repositories. That said, perhaps enough people has been confused by this to make some kind of improvement motivated. Let leave yum as is, but let try to redefine this behavior for dnf: https://bugzilla.redhat.com/show_bug.cgi?id=1052020 Mirek -- 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 evolution-data-server/libcamel soname version bump
Hello, I'm just updating evolution-data-server to 3.11.4 in rawhide, which includes a soname version bump for libcamel (it happened before 3.11.3, but that version didn't reach Fedora rawhide for some reason). I'll rebuild all affected packages I have commit rights for. Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On Mon, 13 Jan 2014 07:51:22 +0200 Ahmad Samir ahmadsamir3...@gmail.com wrote: Right, I missed that bit. to be certain you can do dnf(yum) --enablerepo=* clean all if your intention is truly to remove all cache. ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Grub installation. First potential Fedora killer
On Sun, 12 Jan 2014 15:21:16 -0700
Chris Murphy li...@colorremedies.com wrote:
On Jan 12, 2014, at 1:58 PM, Jean François Martinez jfm...@free.fr wrote:
Installer sees the partitions of other Linuxes. But when rebooting after
installation Fedora was the only choice.
Running grub2-mkconfig fixed it, ie other distribution became available.
Sort of. Problems:
1) Fedora was the default and there is no easy way (that is without
reading the 150+ pages of Grub documentation to change that)
2) If user does not know about grub2-mkconfig he will believe he is
trapped in Fedora and will be very, very angry
3) Every time he runs the other distribution and updates it he needs to
rebooot into Fedora and run grub2-mkconfig
Right, I didn't mean to indicate that multiboot on linux doesn't completely
suck, or that linux distros are friendly to each other rather than behaving
in a cannibalistic fashion by default. GRUB2 really isn't meant for mortal
users, just for the members of the lunacy asylum, so this really should work
better than it does yet here we are.
It is refreshing to see I am not alone. Grub2 has the syndrome of developpers
becaming infatuated and not hiving a hoot about erfs err, I meant users. A
major problem in the Free Software field. Just take a look at this
sentence in the doc the booter is the most important program in the
computer. No, it is a means to an end.
Is this computer by any chance UEFI firmware based? Or is it BIOS? That
matters.
BIOS. GPT partitionning
On BIOS what's supposed to happen is anaconda calls grub2-mkconfig which in
turn uses os-prober to find other OS's and create something sensible in
grub.cfg. That doesn't always work for various reasons, in particular on
UEFI. What you're probably better off doing, is editing /etc/grub.d/40_custom
to add a very basic entry to locate the CentOS grub.conf. Something like this:
menuentry 'CentOS menu' {
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4
--hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4
d7bc9d0e-7706-44f9-b1a7-ff24b7c360a7
legacyconfigfile $prefix/grub.conf
}
Not all hints are needed. Obviously change hd0,gpt4 with the right hint for
the hard drive and partition and partition scheme for where CentOS /boot is
located. The important one, really, is the UUID at the end, which is the file
system UUID for the CentOS boot partition (or rootfs if /boot is a directory
on root). The legacyconfigfile command allows GRUB2 to read legacy GRUB
configuration files. $prefix you should replace with /boot/grub if /boot is a
directory on rootfs or /grub if it's on its own partition.
Now grub2-mkconfig -o /boot/grub2/grub.cfg and this entry will be added to
your Fedora 20 grub.cfg. You'll get an entry that points to the CentOS menu.
If you choose it, the CentOS menu list of kernels should appear. If you want
to make this a default behavior, you'll need to read about
$menuentry_id_option for your CentOS menu entry in the Fedora grub.cfg. By
giving it a unique ID, you can then specify it as the default by that same id
in /etc/default/grub.
Yes it's like pulling teeth.
In fact I was hinting about the need of a boot configurator in Fedora. If user
had somethig in the menus named Boot manager then the subject would
just be minor annoyance. But now a user who doesn't know about Grub2
intrincacies just sees he is trapped and there is no way to escape.
Chris Murphy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Jean François Martinez jfm...@free.fr
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf-0.4.11
On Mon, 13 Jan 2014 00:43:13 +0100 Alec Leamas leamas.a...@gmail.com wrote: First of all, this is not, and have never been a question of disabled repos. Or should not have. yum clean all refers to cleaning all metadata, not all repos. It only operates on one single repo, be it implicit (the default link) or an explicit -r option. man yum CLEAN OPTIONS The following are the ways which you can invoke yum in clean mode. Note that all files in the commands below means all files in currently enabled repositories. If you want to also clean any (temporarily) disabled repositories you need to use --enablerepo='*' option. ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken dependencies: perl-Catalyst-Controller-HTML-FormFu
perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide tree: On x86_64: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On i386: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On armhfp: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: mojomojo
mojomojo has broken dependencies in the rawhide tree: On x86_64: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On i386: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On armhfp: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Net-SSLeay-1.57.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Net-SSLeay: c0f359c7b0816e44a89fadd198c6563c Net-SSLeay-1.57.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-SSLeay] Update to 1.57
commit bd95528fcef2195b64fe2ab8414f12cf80d7a56e
Author: Paul Howarth p...@city-fan.org
Date: Sun Jan 12 15:40:54 2014 +
Update to 1.57
- New upstream release 1.57
- fixed remaining problems with test suite: pod coverage and kwalitee
tests
are only enabled with RELEASE_TESTING=1
perl-Net-SSLeay.spec | 17 -
sources |2 +-
2 files changed, 9 insertions(+), 10 deletions(-)
---
diff --git a/perl-Net-SSLeay.spec b/perl-Net-SSLeay.spec
index a956f93..30fa2e4 100644
--- a/perl-Net-SSLeay.spec
+++ b/perl-Net-SSLeay.spec
@@ -1,5 +1,5 @@
Name: perl-Net-SSLeay
-Version: 1.56
+Version: 1.57
Release: 1%{?dist}
Summary: Perl extension for using OpenSSL
Group: Development/Libraries
@@ -25,15 +25,9 @@ BuildRequires: perl(XSLoader)
BuildRequires: perl(File::Spec)
BuildRequires: perl(IO::Handle)
BuildRequires: perl(Test::Exception)
-# Test::Kwalitee = Module::CPANTS::Analyze = Net::HTTP = IO::Socket::SSL =
Net::SSLeay
-# Net::SSLeay in RHEL-7 cannot BR: Test::Kwalitee from EPEL-7
-%if 0%{!?perl_bootstrap:1} 0%{?rhel} 7
-BuildRequires: perl(Test::Kwalitee)
-%endif
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::NoWarnings)
-BuildRequires: perl(Test::Pod)
-BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(Test::Pod) = 1.0
BuildRequires: perl(Test::Warn)
BuildRequires: perl(threads)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
@@ -80,7 +74,7 @@ find %{buildroot} -type f -name '*.bs' -empty -exec rm -f {}
';'
rm -f %{buildroot}%{perl_vendorarch}/Net/ptrtstrun.pl
%check
-make test TEST_FILES=$(echo $(find t/ -name '*.t' | grep -Ev
'02_pod_coverage|/external/|kwalitee'))
+make test
%clean
rm -rf %{buildroot}
@@ -96,6 +90,11 @@ rm -rf %{buildroot}
%{_mandir}/man3/Net::SSLeay::Handle.3pm*
%changelog
+* Sun Jan 12 2014 Paul Howarth p...@city-fan.org - 1.57-1
+- Update to 1.57
+ - Fixed remaining problems with test suite: pod coverage and kwalitee tests
+are only enabled with RELEASE_TESTING=1
+
* Wed Jan 8 2014 Paul Howarth p...@city-fan.org - 1.56-1
- Update to 1.56
- Fixed a typo in documentation of BEAST Attack
diff --git a/sources b/sources
index b1cfccc..ec345a2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-1a5258167ad0ac6a2b695a6fdc0c6e60 Net-SSLeay-1.56.tar.gz
+c0f359c7b0816e44a89fadd198c6563c Net-SSLeay-1.57.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-SSLeay] Created tag perl-Net-SSLeay-1.56-1.fc21
The lightweight tag 'perl-Net-SSLeay-1.56-1.fc21' was created pointing to: 85b22ba... Update to 1.56 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-SSLeay] Created tag perl-Net-SSLeay-1.57-1.fc21
The lightweight tag 'perl-Net-SSLeay-1.57-1.fc21' was created pointing to: bd95528... Update to 1.57 -- 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-Razor-Agent/epel7] (2 commits) ...- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
Summary of changes: c233d86... Perl 5.18 rebuild (*) 08dea2e... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1048430] Missing dep perl(Module::Pluggable)
https://bugzilla.redhat.com/show_bug.cgi?id=1048430 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Email-Abstract-3.002-1 ||1.fc18 Resolution|--- |ERRATA Last Closed||2014-01-12 21:56:00 --- Comment #7 from Fedora Update System upda...@fedoraproject.org --- perl-Email-Abstract-3.002-11.fc18 has been pushed to the Fedora 18 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=UxPaD4Xegna=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 1048430] Missing dep perl(Module::Pluggable)
https://bugzilla.redhat.com/show_bug.cgi?id=1048430 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-Email-Abstract-3.002-1 |perl-Email-Abstract-3.002-1 |1.fc18 |1.fc20 --- Comment #8 from Fedora Update System upda...@fedoraproject.org --- perl-Email-Abstract-3.002-11.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=MNiwNzawBha=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 1051980] New: Please update to = 1.0.1 in F20
https://bugzilla.redhat.com/show_bug.cgi?id=1051980 Bug ID: 1051980 Summary: Please update to = 1.0.1 in F20 Product: Fedora Version: 20 Component: perl-XML-Catalog Assignee: jples...@redhat.com Reporter: r.landm...@redhat.com QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com Description of problem: Please update XML::Catalog to the latest upstream; I need at least version 1.0.1 as a dependency for the new XML::Treebuilder -- 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=86KG0efkFga=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 1051981] New: Please update to = 1.0.1 in F19
https://bugzilla.redhat.com/show_bug.cgi?id=1051981 Bug ID: 1051981 Summary: Please update to = 1.0.1 in F19 Product: Fedora Version: 19 Component: perl-XML-Catalog Assignee: jples...@redhat.com Reporter: r.landm...@redhat.com QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com Description of problem: Please update XML::Catalog to the latest upstream; I need at least version 1.0.1 as a dependency for the new XML::Treebuilder -- 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=TSSWZkzWNMa=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
about mod_wsgi for python3
Hi, I'm new in this mailing list. I want to use mod_wsgi with python 3. but someone tell me mod_wsgi in fedora is compiled with python 2 and suggest me to recompile it. However, when i recompile it, it show this message /usr/lib64/apr-1/build/libtool --silent --mode=link gcc -std=gnu99 -Wl,-z,relro,-z,now -o mod_wsgi.la -rpath /usr/lib64/httpd/modules -module -avoid-versionmod_wsgi.lo -L/usr/lib64 -L/usr/lib64/python3.3/config -lpython3.3 -lpthread -ldl -lutil -lm /usr/bin/ld: cannot find -lpython3.3 collect2: error: ld returned 1 exit status apxs:Error: Command failed with rc=65536 . make: *** [mod_wsgi.la] Error 1 My ./configure argument: ./configure --with-python=/usr/bin/python3 --with-apxs=/usr/bin/apxs --enable-shared I want to know what arguments fedora used. ___ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
