Re: perl-Readonly in EL 7
Hi Paul, Whoops, thanks for pointing that out. The thing that confused me is that perl-Readonly and perl-Readonly-XS are missing from rhel-everything-7.0-beta-1-x86_64-dvd.iso . - Ken On Fri, Jan 24, 2014 at 9:50 AM, Paul Howarth p...@city-fan.org wrote: Hi Ken, On 24/01/14 16:29, Ken Dreyer wrote: Hi folks, RHEL 7 does not ship perl-Readonly. This package is a dependency for perl-boolean, which is a dependency for perl-MongoDB, so I'd like to have it in EPEL 7. Would one of you mind branching and building it for EPEL 7? Both perl-Readonly and perl-Readonly-XS are included in RHEL-7 beta - see: https://fedoraproject.org/wiki/EPEL/epel7 http://ftp.redhat.com/redhat/rhel/beta/7/x86_64/os/Packages/ What made you think they weren't there? Cheers, Paul. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
perl-Readonly in EL 7
Hi folks, RHEL 7 does not ship perl-Readonly. This package is a dependency for perl-boolean, which is a dependency for perl-MongoDB, so I'd like to have it in EPEL 7. Would one of you mind branching and building it for EPEL 7? I did a scratch-build unmodified from perl-Readonly in Rawhide, and it builds successfully: http://koji.fedoraproject.org/koji/taskinfo?taskID=6449883 - Ken -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fedora.next in 2014 -- Big Picture and Themes
On Sat, Jan 25, 2014 at 11:20:33AM +0100, Thorsten Leemhuis wrote: Hi! On 23.01.2014 19:26, Josh Boyer wrote: On Thu, Jan 23, 2014 at 1:03 PM, Thorsten Leemhuis fed...@leemhuis.info wrote: The packaging guidelines are very daunting. Automating as much of that as possible, either through spec creation tooling or package review tooling would help. I think it's not only the packaging guidelines imho, it's the whole processes around package maintenance -- for existing packagers and newcomers. I for example recently saw that a package I used to maintain long ago was outdated in fedora 20. I chose to ignore it in the end, as I didn't want to nag the current maintainers via bugzilla (yes, I should have done that; sorry, was overly careful or lazy, but that's how people are quite often afaics); I would have preferred to simply do a fedpkg clone foo; update, build, quick test run and then submit it to rawhide, without fearing somebody might yell at me(¹). IOW: like editing a wikipedia page, even if that's in the end more work that simply filing a bug. (¹) Yes, I still have provenpackager rights, so I could have done that, but that wouldn't be considered appropriate under current rules In pkgdb2, I'm replacing the wording 'Owner' by 'Point of contact' for this exact reason, trying to get people to change their relation to 'their' package into a relation where they are simply the primary point of contact, not a big deal if someone updates it in rawhide w/o breaking too much. Hopefully with time it will help changing things :) Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
EPEL epel beta report: 20140127 changes
Compose started at Mon Jan 27 08:15:02 UTC 2014 Broken deps for x86_64 -- ansible-1.4.3-1.el7.noarch requires python-httplib2 bodhi-server-0.9.7-1.el7.noarch requires python-simplemediawiki 1:centerim-4.22.10-14.el7.x86_64 requires perl(Time::ParseDate) check-mk-1.2.2p2-2.el7.x86_64 requires nagios check-mk-1.2.2p2-2.el7.x86_64 requires mod_python docker-io-0.7.6-4.el7.x86_64 requires lxc globus-gram-job-manager-pbs-1.6-7.el7.x86_64 requires torque-client globus-gram-job-manager-sge-1.7-2.el7.x86_64 requires gridengine imapsync-1.580-1.el7.noarch requires perl(Data::Uniqid) imapsync-1.580-1.el7.noarch requires perl(Authen::NTLM) koji-vm-1.8.0-2.el7.noarch requires python-virtinst mirrorbrain-scanner-2.17.0-4.el7.x86_64 requires perl(Config::IniFiles) perl-Test-WWW-Selenium-1.36-1.el7.noarch requires perl(Devel::REPL::Plugin) puppet-3.4.2-2.el7.noarch requires hiera = 0:1.0.0 python-sphinxcontrib-httpdomain-1.1.8-3.el7.noarch requires python-sphinx10 snmptt-1.4-0.9.beta2.el7.noarch requires perl-Net-SNMP snmptt-1.4-0.9.beta2.el7.noarch requires perl(Config::IniFiles) spectrwm-2.4.0-2.el7.x86_64 requires xlockmore spectrwm-2.4.0-2.el7.x86_64 requires dmenu supervisor-3.0-1.el7.noarch requires python-meld3 = 0:0.6.5 x2goagent-3.5.0.22-2.el7.x86_64 requires x2goserver Broken deps for ppc64 -- TurboGears-1.1.3-8.el7.noarch requires python-simplejson = 0:1.9.1 ansible-1.4.3-1.el7.noarch requires python-httplib2 bodhi-client-0.9.7-1.el7.noarch requires python-simplejson bodhi-server-0.9.7-1.el7.noarch requires python-simplemediawiki 1:centerim-4.22.10-14.el7.ppc64 requires perl(Time::ParseDate) check-mk-1.2.2p2-2.el7.ppc64 requires nagios check-mk-1.2.2p2-2.el7.ppc64 requires mod_python fedmsg-0.7.2-1.el7.noarch requires python-simplejson fedmsg-0.7.2-1.el7.noarch requires python-requests globus-gram-job-manager-pbs-1.6-7.el7.ppc64 requires torque-client globus-gram-job-manager-sge-1.7-2.el7.ppc64 requires gridengine imapsync-1.580-1.el7.noarch requires perl(Data::Uniqid) imapsync-1.580-1.el7.noarch requires perl(Authen::NTLM) koji-vm-1.8.0-2.el7.noarch requires python-virtinst mirrorbrain-scanner-2.17.0-4.el7.ppc64 requires perl(Config::IniFiles) perl-Test-WWW-Selenium-1.36-1.el7.noarch requires perl(Devel::REPL::Plugin) puppet-3.4.2-2.el7.noarch requires hiera = 0:1.0.0 python-django-1.5.4-2.el7.noarch requires python-simplejson python-fedora-0.3.33-1.el7.noarch requires python-simplejson python-fedora-0.3.33-1.el7.noarch requires python-requests python-requests-kerberos-0.3-2.el7.noarch requires python-requests = 0:1.0 python-sphinxcontrib-httpdomain-1.1.8-3.el7.noarch requires python-sphinx10 python-toscawidgets-0.9.12-4.el7.noarch requires python-simplejson python-turboflot-0.7.0-4.el7.noarch requires python-simplejson python-turbojson-1.3.2-5.el7.noarch requires python-simplejson = 0:1.9.1 python-tw2-core-2.1.5-4.el7.noarch requires python-simplejson = 0:2.0 python-webflash-0.1-0.8.a9.el7.noarch requires python-simplejson skeinforge-12.03.14-16.el7.noarch requires pypy snmptt-1.4-0.9.beta2.el7.noarch requires perl-Net-SNMP snmptt-1.4-0.9.beta2.el7.noarch requires perl(Config::IniFiles) spectrwm-2.4.0-2.el7.ppc64 requires xlockmore spectrwm-2.4.0-2.el7.ppc64 requires dmenu supervisor-3.0-1.el7.noarch requires python-meld3 = 0:0.6.5 x2goagent-3.5.0.22-2.el7.ppc64 requires x2goserver New package: bleachbit-1.0-1.el7 Remove unnecessary files, free space, and maintain privacy New package: nbd-3.6-1.el7 Network Block Device user-space tools (TCP version) Updated Packages: gssntlmssp-0.3.1-0.el7 -- * Sun Jan 26 2014 Simo Sorce s...@samba.org - 0.3.1-0 - Fixes #1058025 - New upstream release 0.3.1: * Fix segfault in init context. php-horde-Horde-Cache-2.4.0-1.el7 - * Sat Jan 25 2014 Remi Collet r...@fedoraproject.org - 2.4.0-1 - Update to 2.4.0 - add (optional) requires for Horde_HashTable, Horde_Mongo Summary: Added Packages: 2 Removed Packages: 0 Modified Packages: 2 ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Source string contextualization
On 24 January 2014 17:52, Nilamdyuti Goswami ngosw...@redhat.com wrote: Hi all, While translating some of the fedora packages we often come across some source strings whose context or meaning is not clear. This results in wrong translations which is discovered later while using the actual application. This in turn effects the concerned application. To solve this issue, we have formed a Fedora SIG named Source String Contextualizing Group [1] aimed at providing concise yet meaningful description of the concerned source strings in the source code itself to ensure the correctness and quality in the resulting translations. We welcome feedback and suggestions. I liked this. I think this should become habit/protocol for translation community over a period. Whenever one find any confusing string, they should report it back to developer saying we need context Or they can give patch or suggestion for same. If every translator keeps on following it, in long term we will definitely have term with good information. Same time more information is not required for each and every word, only for confusing terms. It make this task more achievable. Regards, Pravin Satpute -- 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: Source string contextualization
On 27-01-2014 02:08 অপৰাহ্ন, pravin@gmail.com wrote: On 24 January 2014 17:52, Nilamdyuti Goswami ngosw...@redhat.com mailto:ngosw...@redhat.com wrote: Hi all, While translating some of the fedora packages we often come across some source strings whose context or meaning is not clear. This results in wrong translations which is discovered later while using the actual application. This in turn effects the concerned application. To solve this issue, we have formed a Fedora SIG named Source String Contextualizing Group [1] aimed at providing concise yet meaningful description of the concerned source strings in the source code itself to ensure the correctness and quality in the resulting translations. We welcome feedback and suggestions. I liked this. I think this should become habit/protocol for translation community over a period. Whenever one find any confusing string, they should report it back to developer saying we need context Or they can give patch or suggestion for same. If every translator keeps on following it, in long term we will definitely have term with good information. Same time more information is not required for each and every word, only for confusing terms. It make this task more achievable. Regards, Pravin Satpute Thanks Pravin. We hope it's implementation can help us yield quality translations. Regards, Nilamdyuti -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review swap or Sponser request: the_silver_searcher
On Sun, Jan 26, 2014 at 11:39 AM, Matthias Runge mru...@matthias-runge.de wrote: On 01/26/2014 09:09 AM, Kenjiro Nakayama wrote: Hi, List Can anyone swap review or take it as sponsor? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1008063 Kenjiro, in order to get a package approved, you must be the reporter of a review request. When looking for a sponsor, it definitely helps, if you review other packages as well. Hi Kenjiro, I would have happily reviewed the package but I've been swamped for a few weeks, and I didn't know how to handle the takeover. Also as Christopher mentioned, I'm not a sponsor, so I can't approve the submission (I'm aware of that). I've stepped down and removed the review flag because I don't know whether I can review it and let a sponsor then approve it. Now once a new review request is submitted, and if I can review it and let the sponsor handle the rest, you can count on me. Best Regards, Dridi 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Tk-Pod] Enable dependency on Text::English
commit 533b1f620cba7391323f2dd7dc460a92c8466a85
Author: Petr Písař ppi...@redhat.com
Date: Mon Jan 27 10:24:55 2014 +0100
Enable dependency on Text::English
perl-Tk-Pod.spec |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
---
diff --git a/perl-Tk-Pod.spec b/perl-Tk-Pod.spec
index f1ee681..4f0a8b4 100644
--- a/perl-Tk-Pod.spec
+++ b/perl-Tk-Pod.spec
@@ -2,7 +2,7 @@
Name: perl-Tk-Pod
Version:0.9942
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Pod browser top-level widget
License:GPL+ or Artistic
Group: Development/Libraries
@@ -116,8 +116,6 @@ Requires: perl(URI::Escape)
# Remove under-specified dependencies
%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(Tk(::Pod)?\\)\\s*$
-# Remove not-yet-packages optional dependencies
-%global __requires_exclude %__requires_exclude|^perl\\(Text::English\\)
%description
Simple Pod browser with hypertext capabilities in a Toplevel widget.
@@ -150,6 +148,9 @@ find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {}
\;
%{_mandir}/man1/*
%changelog
+* Mon Jan 27 2014 Petr Pisar ppi...@redhat.com - 0.9942-2
+- Enable dependency on Text::English
+
* Tue Nov 19 2013 Petr Pisar ppi...@redhat.com - 0.9942-1
- 0.9942 bump
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 645 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 135 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11560/fail2ban-0.8.10-4.el5 99 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 74 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12091/bip-0.8.9-1.el5 65 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12169/gc-7.1-6.el5 16 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0132/graphviz-2.12-10.el5 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0203/transifex-client-0.10-1.el5 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0201/drupal7-7.26-1.el5 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0200/drupal6-6.30-1.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing drupal6-imageapi-1.10-4.el5 drupal6-imagecache-2.0-6.rc1.el5 drupal6-imagecache_profiles-1.4-0.2.rc1.el5 drupal6-user_badges-2.0-1.el5 drupal7-path_breadcrumbs-3.0-0.7.rc1.el5 drupal7-variable-2.4-1.el5 freecolor-0.9.2-1.el5 Details about builds: drupal6-imageapi-1.10-4.el5 (FEDORA-EPEL-2014-0360) ImageAPI supporting multiple toolkits Update Information: This API is meant to be used in place of the API provided by image.inc. You probably do not need to install this module unless another module are you using requires it. It provides no new features to your Drupal site. It only provides an API other modules can leverage. Currently GD2 and ImageMagick support are distributed with ImageAPI. This package provides the following Drupal modules: * imageapi * imageapi_gd * imageapi_imagemagick References: [ 1 ] Bug #829067 - Review Request: drupal6-imageapi - Image API Module for Drupal6 https://bugzilla.redhat.com/show_bug.cgi?id=829067 drupal6-imagecache-2.0-6.rc1.el5 (FEDORA-EPEL-2014-0345) Dynamic image manipulator and cache Update Information: ImageCache allows you to setup presets for image processing. If an ImageCache derivative doesn't exist the web server's rewrite rules will pass the request to Drupal which in turn hands it off to ImageCache to dynamically generate the file. ImageCache allows you to setup presets for image processing. This package provides the following Drupal modules: * imagecache * imagecache_ui References: [ 1 ] Bug #829714 - Review Request: drupal6-imagecache - Image Cache module for drupal6 https://bugzilla.redhat.com/show_bug.cgi?id=829714 [ 2 ] Bug #656179 - Review Request: drupal6-imagecache - ImageCache allows you to setup presets for image processing https://bugzilla.redhat.com/show_bug.cgi?id=656179 drupal6-imagecache_profiles-1.4-0.2.rc1.el5 (FEDORA-EPEL-2014-0357) Utilizes image styles for user profile pictures Update Information: ImageCache_Profiles module allows you to set user profile pictures that are consistent throughout your site and allows avatars on the user profile pages, nodes and comments to be a different size. This package provides the following Drupal module: * imagecache_profiles References: [ 1 ] Bug #1025986 - drupal6-imagecache_profiles-1.4-rc1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1025986 [ 2 ] Bug #829718 - Review Request: drupal6-imagecache_profiles - Image cache for User Profiles for Drupal6 https://bugzilla.redhat.com/show_bug.cgi?id=829718 drupal6-user_badges-2.0-1.el5 (FEDORA-EPEL-2014-0361) Enables assignment of graphical badges to users and roles Update Information: Updated to 2.0 * Release notes: https://drupal.org/node/2170813 ChangeLog:
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 645 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 101 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11865/quassel-0.9.1-1.el6 74 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12079/bip-0.8.9-1.el6 38 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12427/seamonkey-2.21-3.esr2.el6 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0166/mediawiki119-1.19.10-1.el6 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0197/drupal7-7.26-1.el6 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0202/transifex-client-0.10-1.el6 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0205/drupal6-6.30-1.el6 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0233/libreswan-3.8-1.el6 4 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0282/moodle-2.4.8-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing drupal6-imageapi-1.10-4.el6 drupal6-imagecache-2.0-6.rc1.el6 drupal6-imagecache_profiles-1.4-0.2.rc1.el6 drupal6-user_badges-2.0-1.el6 drupal7-path_breadcrumbs-3.0-0.7.rc1.el6 drupal7-variable-2.4-1.el6 freecolor-0.9.2-1.el6 perl-Capture-Tiny-0.23-1.el6 perl-File-chdir-0.1008-1.el6 php-Monolog-1.7.0-3.el6 x2goserver-4.0.1.13-1.el6 Details about builds: drupal6-imageapi-1.10-4.el6 (FEDORA-EPEL-2014-0346) ImageAPI supporting multiple toolkits Update Information: This API is meant to be used in place of the API provided by image.inc. You probably do not need to install this module unless another module are you using requires it. It provides no new features to your Drupal site. It only provides an API other modules can leverage. Currently GD2 and ImageMagick support are distributed with ImageAPI. This package provides the following Drupal modules: * imageapi * imageapi_gd * imageapi_imagemagick References: [ 1 ] Bug #829067 - Review Request: drupal6-imageapi - Image API Module for Drupal6 https://bugzilla.redhat.com/show_bug.cgi?id=829067 drupal6-imagecache-2.0-6.rc1.el6 (FEDORA-EPEL-2014-0350) Dynamic image manipulator and cache Update Information: ImageCache allows you to setup presets for image processing. If an ImageCache derivative doesn't exist the web server's rewrite rules will pass the request to Drupal which in turn hands it off to ImageCache to dynamically generate the file. ImageCache allows you to setup presets for image processing. This package provides the following Drupal modules: * imagecache * imagecache_ui References: [ 1 ] Bug #829714 - Review Request: drupal6-imagecache - Image Cache module for drupal6 https://bugzilla.redhat.com/show_bug.cgi?id=829714 [ 2 ] Bug #656179 - Review Request: drupal6-imagecache - ImageCache allows you to setup presets for image processing https://bugzilla.redhat.com/show_bug.cgi?id=656179 drupal6-imagecache_profiles-1.4-0.2.rc1.el6 (FEDORA-EPEL-2014-0352) Utilizes image styles for user profile pictures Update Information: ImageCache_Profiles module allows you to set user profile pictures that are consistent throughout your site and allows avatars on the user profile pages, nodes and comments to be a different size. This package provides the following Drupal module: * imagecache_profiles References: [ 1 ] Bug #1025986 - drupal6-imagecache_profiles-1.4-rc1 is available https://bugzilla.redhat.com/show_bug.cgi?id=1025986 [ 2 ] Bug #829718 - Review Request: drupal6-imagecache_profiles - Image cache for User Profiles for Drupal6 https://bugzilla.redhat.com/show_bug.cgi?id=829718 drupal6-user_badges-2.0-1.el6 (FEDORA-EPEL-2014-0349) Enables assignment of graphical badges to users and roles Update
Re: Fedora.next in 2014 -- Big Picture and Themes
On 23 January 2014 21:57, Adam Williamson awill...@redhat.com wrote: On Thu, 2014-01-23 at 16:54 -0500, Josh Boyer wrote: On Thu, Jan 23, 2014 at 4:49 PM, Adam Williamson awill...@redhat.com wrote: On Thu, 2014-01-23 at 13:48 -0500, Josh Boyer wrote: To be honest my concerns are more with my user hat on than my contributor hat - that we will lose the gold standard unified packaging standards and single source and mechanism for installing packages. I haven't seen anything from any WG that would suggest a deviation from RPM packaging guidelines or using separate repositories. It is a valid concern and one we need to keep an eye on. Um. As I read it, three out of four WGs - desktop, server, and cloud - have at least discussed the possibility of implementing what are, in essence, secondary package management layers. The details differ - 'app bundles' for desktop, 'containers' or whatever for server and cloud - but the effect is the same. Secondary being the key word. None of them are proposing alternate RPM repositories or changing the Fedora packaging guidelines. Tom was expressing that he is concerned the Fedora repos would go away or be of decreased quality. None of the WG proposals are altering those repos. They will still exist, much as they do today. The repos will still exist, but things will be different. At present, the Fedora repos are the single unified official Fedora method for deploying software on Fedora products. Any other method you can use to deploy software is not an 'official Fedora' thing. If these plans go ahead, we will have multiple official/blessed methods for deploying software on Fedora, potentially with different policies about what software they can include and how that software should be arranged, how dependencies should be handled, and all the rest of it. Some of these methods will be shared between products, and some will either only exist in certain products, or at least be clearly associated with and 'owned' by those products. So without, unfortunately, the time to read through reams of stuff on this and with my user hat on (don't think I've seen any discussion of this on the users list), if it means how fedora actually works is better thought out then that's a good thing, but does this mean there will be things unavailable on some 'products' that are not on others? At the minute you install a spin and can add whatever other packages. That's great if you want to do something like set up a quick web server for testing or stream some music without creating VMs everywhere. It sounds a bit like this plan may end up with finding you can't do X on a Fedora system because you installed the wrong flavour. -- 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
Re: icecat or/and firefox?
Hello all, I haven't thought about possible replacement plans, in my opinion it's too early to talk about that now. As for the packaging process, the package requires some rework and improvement - it's actually in the process. It takes some time and efforts from a submitter (Antonio Trande), we'll see what will happen.. Everyone is encouraged to take part in the discussion, share some thoughts, etc. Any ideas are welcome. --- wbr, Denis. On Mon, Jan 27, 2014 at 11:36 AM, Ralf Corsepius rc040...@freenet.dewrote: On 01/27/2014 05:08 AM, Christopher Meng wrote: Hi, Here is an interesting package icecat[1], which is a more free version firefox. Do we allow this in Fedora now? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: icecat or/and firefox?
On 27 January 2014 05:36, Ralf Corsepius rc040...@freenet.de wrote: On 01/27/2014 05:08 AM, Christopher Meng wrote: Hi, Here is an interesting package icecat[1], which is a more free version firefox. I'd argue it's *less* free since it seeks to restrict what you can do: Finally, we need to change free browsers to detect and block nontrivial nonfree JavaScript in web pages. But: My view: It's a package like any arbitrary other. So, if it complies to the rules applied elsewhere, I don't see much reasons why it can not be part of Fedora. If people do want to use and someone willing to maintain it I don't see why not. -- 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
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-de...@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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-qpid_proton
perl-qpid_proton has broken dependencies in the rawhide tree: On x86_64: perl-qpid_proton-0.6-1.fc21.x86_64 requires perl(qpid_proton) perl-qpid_proton-0.6-1.fc21.x86_64 requires perl(qpid::proton::ExceptionHandling) On i386: perl-qpid_proton-0.6-1.fc21.i686 requires perl(qpid_proton) perl-qpid_proton-0.6-1.fc21.i686 requires perl(qpid::proton::ExceptionHandling) On armhfp: perl-qpid_proton-0.6-1.fc21.armv7hl requires perl(qpid_proton) perl-qpid_proton-0.6-1.fc21.armv7hl requires perl(qpid::proton::ExceptionHandling) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Review swap or Sponser request: the_silver_searcher
On 01/27/2014 09:51 AM, Dridi Boukelmoune wrote: I would have happily reviewed the package but I've been swamped for a few weeks, and I didn't know how to handle the takeover. Also as Christopher mentioned, I'm not a sponsor, so I can't approve the submission (I'm aware of that). I've stepped down and removed the review flag because I don't know whether I can review it and let a sponsor then approve it. Now once a new review request is submitted, and if I can review it and let the sponsor handle the rest, you can count on me. Thank you Dridi for stepping up here: One nit: https://fedoraproject.org/wiki/Package_Review_Process#Reviewer states clearly: If it is the first package of a Contributor, the Reviewer must be in the Sponsor group Nevertheless, a review will help anyway, as it should clear all issues with the package. 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
[perl-version] Specify all dependencies
commit 8eb59884dd4adae4db89049d91790be2a9f5de37
Author: Petr Písař ppi...@redhat.com
Date: Mon Jan 27 13:09:12 2014 +0100
Specify all dependencies
perl-version.spec |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
---
diff --git a/perl-version.spec b/perl-version.spec
index 868552b..895cf4a 100644
--- a/perl-version.spec
+++ b/perl-version.spec
@@ -2,7 +2,7 @@ Name: perl-version
Epoch: 3
Version:0.99.07
%global module_version 0.9907
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Perl extension for Version Objects
License:GPL+ or Artistic
Group: Development/Libraries
@@ -17,8 +17,10 @@ BuildRequires: perl(Data::Dumper)
BuildRequires: perl(ExtUtils::CBuilder)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Basename)
+BuildRequires: perl(File::Copy)
BuildRequires: perl(File::Spec)
BuildRequires: perl(File::Temp) = 0.13
+BuildRequires: perl(if)
# IO::Handle is optional
BuildRequires: perl(lib)
BuildRequires: perl(List::Util)
@@ -32,6 +34,7 @@ BuildRequires: perl(Test::Harness)
BuildRequires: perl(UNIVERSAL)
BuildRequires: perl(vars)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(locale)
Requires: perl(UNIVERSAL)
Requires: perl(XSLoader)
@@ -77,6 +80,9 @@ make test
%{_mandir}/man3/version::Internals.3pm*
%changelog
+* Mon Jan 27 2014 Petr Pisar ppi...@redhat.com - 3:0.99.07-2
+- Specify all dependencies
+
* Wed Jan 15 2014 Petr Šabata con...@redhat.com - 3:0.99.07-1
- 0.9907 bugfix bump
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: .spec file Source0 magic for github release source tarballs?
Dne 21.1.2014 18:01, Kaleb KEITHLEY napsal(a): Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases, where there's a button for Source code (tar.gz) pointing at https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz. If I click on that link the downloaded file is named nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition http header. Likewise if I use `curl -L ...` the downloaded file is named nfs-ganesha-2.0.0.tar.gz. But for my nfs-ganesha.spec file, if I use the github link shown above, I have to load a file V2.0.0.tar.gz into the look-aside cache. Anything else and rpm and rpmlint whine. Is there a best practice here that I'm missing? Thanks, -- Kaleb Just thinking loud Wouldn't be useful to have some macro for sources from GitHub? It could look like: Source0: %source_github(name, project, hash) ... Vít -- 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 Event-RPC-1.04.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Event-RPC: d40147fe814a5c5c976a940b68db3029 Event-RPC-1.04.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Event-RPC] 1.04 bump
commit 1c8dcf301f21cfd65d3fef96d7b703c86d713de8
Author: Petr Písař ppi...@redhat.com
Date: Mon Jan 27 13:28:50 2014 +0100
1.04 bump
.gitignore |1 +
perl-Event-RPC.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 727783b..bb1828f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
Event-RPC-1.01.tar.gz
/Event-RPC-1.03.tar.gz
+/Event-RPC-1.04.tar.gz
diff --git a/perl-Event-RPC.spec b/perl-Event-RPC.spec
index 4ac692d..3c791f9 100644
--- a/perl-Event-RPC.spec
+++ b/perl-Event-RPC.spec
@@ -1,6 +1,6 @@
Name: perl-Event-RPC
-Version:1.03
-Release:3%{?dist}
+Version:1.04
+Release:1%{?dist}
Summary:Event based transparent client/server RPC framework
Group: Development/Libraries
License:GPL+ or Artistic
@@ -66,6 +66,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Mon Jan 27 2014 Petr Pisar ppi...@redhat.com - 1.04-1
+- 1.04 bump
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.03-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index 06c03cc..5679744 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-1539ff86cfbdef1a40c502a6454100cf Event-RPC-1.03.tar.gz
+d40147fe814a5c5c976a940b68db3029 Event-RPC-1.04.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: .spec file Source0 magic for github release source tarballs?
Indeed, as well as in other places e. g., the iconcache snippets. --alec On 1/27/14, Vít Ondruch vondr...@redhat.com wrote: Dne 21.1.2014 18:01, Kaleb KEITHLEY napsal(a): Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases, where there's a button for Source code (tar.gz) pointing at https://github.com/nfs-ganesha/nfs-ganesha/archive/V2.0.0.tar.gz Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz. If I click on that link the downloaded file is named nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition http header. Likewise if I use `curl -L ...` the downloaded file is named nfs-ganesha-2.0.0.tar.gz. But for my nfs-ganesha.spec file, if I use the github link shown above, I have to load a file V2.0.0.tar.gz into the look-aside cache. Anything else and rpm and rpmlint whine. Is there a best practice here that I'm missing? Thanks, -- Kaleb Just thinking loud Wouldn't be useful to have some macro for sources from GitHub? It could look like: Source0: %source_github(name, project, hash) ... Vít -- 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
[Bug 1058004] perl-Event-RPC-1.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1058004 --- Comment #1 from Petr Pisar ppi...@redhat.com --- This is a bug-fix release suitable for F≥20. -- 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=joL2w39tHxa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Event-RPC/f20] 1.04 bump
Summary of changes: 1c8dcf3... 1.04 bump (*) (*) 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fedora.next in 2014 -- Big Picture and Themes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/27/2014 05:36 AM, Ian Malone wrote: So without, unfortunately, the time to read through reams of stuff on this and with my user hat on (don't think I've seen any discussion of this on the users list), if it means how fedora actually works is better thought out then that's a good thing, but does this mean there will be things unavailable on some 'products' that are not on others? At the minute you install a spin and can add whatever other packages. That's great if you want to do something like set up a quick web server for testing or stream some music without creating VMs everywhere. It sounds a bit like this plan may end up with finding you can't do X on a Fedora system because you installed the wrong flavour. No. The Products will be defining an environment and a standard install set. They may have separate initial *installation* repositories if they need to provide different options to Anaconda, but beyond that the intent is for all of the Products to continue to draw from the same store of packages together. If (for example) we got ourselves into a situation where you couldn't install Fedora Server and then also install the GNOME desktop environment on that Server, this would be considered a major bug and one that we would need to reconcile immediately. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLmWdMACgkQeiVVYja6o6P0twCfRk46ssphyt3+iZUnbh/t4TrG +FEAoINANDTuTrd+jEY8rFLydsna8obW =bmho -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: gitflow and branch naming conventions
- Original Message - From: Kamil Paral kpa...@redhat.com To: Fedora QA Development qa-de...@lists.fedoraproject.org Sent: Friday, January 24, 2014 4:03:40 PM Subject: gitflow and branch naming conventions So, we're going the gitflow way [1][2]. However, when I looked at our bitbucket repositories today, only the libtaskotron branch uses 'develop' branch, all other projects use only 'master' branch - even taskotron-trigger or task-rpmlint. Does it mean we use gitflow only for libtaskotron? Or is it a repo author's choice? I'm a bit afraid it's going to be chaos - you'll need to inspect available branches every time to decide against which branch to base a patch or into which branch to commit. I wonder, could we use gitflow but drop the idea of misusing 'master' branch name for something else than usual? Because that's the main grievance I have against gitflow, otherwise it's a neat workflow. I believe gitflow should have never used master for something else, it should have used 'stable' branch instead for stable releases (i.e. 'gitflow/master' should have been 'traditional/stable' and 'gitflow/develop' should have been 'traditional/master'). All the tools (and most of the users) expect 'master' to be the main development branch. Git init creates master by default. Git clone checks out master by default. Github/Bitbucket displays master by default. Arcanist merges to master by default. Users clone and send patches against master by default. Usually you can adjust the tools, but what's the benefit? Why all the mess? I simply don't get it. (Also notice people criticizing it under one of the most famous blogposts [3] and offering the same suggestions as I do). I am not against the idea but just a note, we'd need to change this for projects that have been using gitflow/develop style branch (blockerbugs) as well. Thanks, Martin So, if we use gitflow with traditional master meaning, and stable branch for stable releases, I see it as a win-win. Regardless whether that particular repo uses gitflow or not, you known what branch to work with automatically. You don't need to change configuration in your tools. Everything works, and you get the benefits. If you have installed the gitflow RPM package (it adds the git flow subcommand), it asks you initially what naming conventions you like to use. So if you like that tool, there's no problem using it with the traditional 'master' meaning. [1] https://fedoraproject.org/wiki/User:Tflink/taskotron_contribution_guide [2] http://nvie.com/posts/a-successful-git-branching-model/ [3] http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/ ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Fedora.next in 2014 -- Big Picture and Themes
On 27 January 2014 13:06, Stephen Gallagher sgall...@redhat.com wrote: On 01/27/2014 05:36 AM, Ian Malone wrote: does this mean there will be things unavailable on some 'products' that are not on others? No. The Products will be defining an environment and a standard install set. They may have separate initial *installation* repositories if they need to provide different options to Anaconda, but beyond that the intent is for all of the Products to continue to draw from the same store of packages together. If (for example) we got ourselves into a situation where you couldn't install Fedora Server and then also install the GNOME desktop environment on that Server, this would be considered a major bug and one that we would need to reconcile immediately. Cool. If I was to take this one step further then, an issue for Fedora Jam is we were limited in the customisations the could be made for a spin (e.g. defaulting users into certain groups to allow real time audio). While there's not enough of the developer base to make it an official product would there be a way to slot this into that framework? -- 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
Re: Fedora.next in 2014 -- Big Picture and Themes
On Sat, 2014-01-25 at 12:04 +0100, Alec Leamas wrote:
After hacking a simple tool which provides a GUI for a repository file
it's possible to create repository packages complete with desktop and
appdata file. I have some 5-10 such repository packages under way, my
plan is to push them into rpmfusion.
http://rpmfusion.org/Contributors#Read_the_packaging_guidelines
RPM Fusion follows the Fedora packaging guidelines, make sure you've
read and understood these:
Naming Guidelines
Guidelines is a link to
https://fedoraproject.org/wiki/Packaging:Guidelines :
Configuration for package managers in Fedora MUST ONLY reference the
official Fedora repositories in their default enabled and disabled state
(see the yum repo configuration in the fedora-release package for the
canonical list). Unofficial and third-party repositories that contain
only packages that it is legal for us to direct people to in Fedora (see
the Forbidden items and Licensing:Main pages for an explanation of what
is legal) may be shipped in %{_docdir}. The idea is that the system
administrator would need to explicitly copy the configuration file from
doc into the proper location on the filesystem if they want to enable
the repository.
Presumably one is to s/Fedora/RPMFusion and Fedora/g/ when reading that
as applying to Fusion, but still, Fusion's policies would appear to
forbid you to ship packages that contain 'active' external repository
configuration.
If there will be a way for users to aggregate appdata from different
sources such as rpmfusion (don't fully really understand this process
right now) users will be able to search and find also non-free items
as long there is a packaged repository for them. It should work out of
the box right now using old-school tools based on package metadata.
Not ideal, but perhaps something.
So I found this point interesting in thinking about these issues this
morning. There was a post of Hughesie's (I think) in another thread
which was also illuminating: it suggested the design of Software is to
be a generic 'software' installer - to provide as much 'software' from
as many sources as possible, under the 'it's all just software' theory,
guess.
I think the assumption that this is obviously the right design is
interesting, because I strongly disagree - not just for legal or policy
reasons, but because that's most definitely *not* what I want. I
cut]
---
Sorry for badly formatted reply - lost the original in my mailbox and
only have this web UI right now :(.
Anyway, I have submitted [1], a rpmfusion review request for
dropbox-repo. A real case should hopefully provide a sound base for
remaining things to discuss.
--alec
[1] https://bugzilla.rpmfusion.org/show_bug.cgi?id=3152
On 1/27/14, Stephen Gallagher sgall...@redhat.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/27/2014 05:36 AM, Ian Malone wrote:
So without, unfortunately, the time to read through reams of stuff
on this and with my user hat on (don't think I've seen any
discussion of this on the users list), if it means how fedora
actually works is better thought out then that's a good thing, but
does this mean there will be things unavailable on some 'products'
that are not on others? At the minute you install a spin and can
add whatever other packages. That's great if you want to do
something like set up a quick web server for testing or stream some
music without creating VMs everywhere. It sounds a bit like this
plan may end up with finding you can't do X on a Fedora system
because you installed the wrong flavour.
No.
The Products will be defining an environment and a standard install
set. They may have separate initial *installation* repositories if
they need to provide different options to Anaconda, but beyond that
the intent is for all of the Products to continue to draw from the
same store of packages together.
If (for example) we got ourselves into a situation where you couldn't
install Fedora Server and then also install the GNOME desktop
environment on that Server, this would be considered a major bug and
one that we would need to reconcile immediately.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLmWdMACgkQeiVVYja6o6P0twCfRk46ssphyt3+iZUnbh/t4TrG
+FEAoINANDTuTrd+jEY8rFLydsna8obW
=bmho
-END PGP SIGNATURE-
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Owner-change] Fedora packages ownership change
Change in ownership over the last 168 hours === 2 packages were orphaned xom [EL-6] was orphaned by gil XML Pull Parser https://admin.fedoraproject.org/pkgdb/acls/name/xom mlton [EL-5] was orphaned by agoode Optimizing compiler for Standard ML https://admin.fedoraproject.org/pkgdb/acls/name/mlton 9 packages unorphaned - pghmcfc unorphaned : perl-File-chdir [EL-5,EL-6] nb unorphaned : ingo [EL-5] jplesnikunorphaned : perl-Test-Most [epel7] mmilata unorphaned : system-config-kdump [devel,f19,f20] lkundrakunorphaned : perl-Lingua-Stem-Snowball [EL-6] lkundrakunorphaned : perl-Class-Autouse [EL-6] lkundrakunorphaned : perl-Lingua-StopWords [EL-6] averi unorphaned : imapfilter [EL-6,devel,f19,f20] pghmcfc unorphaned : perl-ExtUtils-Depends [epel7] 8 packages were retired zif [f19] was retired by rhughes Simple wrapper for rpm https://admin.fedoraproject.org/pkgdb/acls/name/zif piggyback [devel] was retired by spot Utility for making net-bootable sparc kernel image files https://admin.fedoraproject.org/pkgdb/acls/name/piggyback mediawiki [EL-5] was retired by vicodan A wiki engine https://admin.fedoraproject.org/pkgdb/acls/name/mediawiki perl-HTML-Tree [EL-6,epel7] was retired by notting HTML tree handling modules for Perl https://admin.fedoraproject.org/pkgdb/acls/name/perl-HTML-Tree ghc-feldspar-language [EL-6] was retired by petersen Functional Embedded Language for DSP and PARallelism https://admin.fedoraproject.org/pkgdb/acls/name/ghc-feldspar-language xferstats [devel,f19,f20] was retired by jsynacek Compiles information about file transfers from logfiles https://admin.fedoraproject.org/pkgdb/acls/name/xferstats libnftables [devel] was retired by kevin Library for low-level interaction with nftables Netlink's API over libmnl https://admin.fedoraproject.org/pkgdb/acls/name/libnftables udisks2-lvm [devel] was retired by puiterwijk LVM DBus add-on for udisks https://admin.fedoraproject.org/pkgdb/acls/name/udisks2-lvm 38 packages changed owner - limbgave to sparks : gpredict [epel7] limbgave to lkundrak : perl-Locale-US [epel7] limbgave to cicku : NetPIPE [EL-6,epel7] limbgave to remi : php-pear-Net-DNS [EL-6,epel7] limbgave to lkundrak : perl-Want [epel7] limbgave to lkundrak : perl-Tie-ToObject [epel7] limbgave to ralph : python-requests-oauthlib [EL-6,epel7] limbgave to notting: perl-HTML-Element-Extended [epel7] limbgave to cicku : python-pymtp [epel7] limbgave to lkundrak : perl-File-Flat [epel7] limbgave to jcollie: python-paramiko [EL-6] limbgave to cicku : nbd [epel7,epel7] limbgave to cicku : ascii-design [epel7] limbgave to cicku : lfcbase [epel7] limbgave to rlandmann : perl-IO-Compress [EL-5,EL-6] limbgave to rnovacek : krusader [EL-6] limbgave to ralph : python-oauthlib [EL-6,epel7] jplesnikgave to pghmcfc: perl-Data-Dumper-Names [epel7] limbgave to lkundrak : perl-Algorithm-Dependency [epel7] limbgave to maxamillion: psad [EL-6,epel7] kevin gave to akurtakov : eclipse-egit-github [devel,f19,f20] limbgave to cicku : vttest [epel7] limbgave to cicku : python-eyed3 [epel7] jplesnikgave to pghmcfc: perl-Test-Most [epel7] limbgave to jdornak: python-social-auth [EL-6,epel7] limbgave to remi : php-pear-Net-IPv4 [EL-6,epel7] limbgave to spot : perl-HTML-Tree [EL-6,epel7] limbgave to rlandmann : perl-Locale-Msgfmt [EL-5,EL-6] limbgave to cicku : cdk [EL-6,epel7] limbgave to maxamillion: bluebird [EL-6,epel7] limbgave to mcepl : python-mccabe [EL-6] limbgave to jjames : python-manuel [EL-6,epel7] limbgave to lkundrak : perl-File-chmod [epel7] limbgave to cicku : bleachbit [epel7] limbgave to maxamillion: perl-IPTables-ChainMgr [epel7] limbgave to nmav : ocserv [EL-6,epel7] limbgave to lkundrak : perl-Test-Inline [epel7] mmaslanogave to lkundrak : perl-KinoSearch [epel7] Sources: https://github.com/pypingou/fedora-owner-change --
Re: I want to turn on a part of the kernel to make SELinux checking more stringent.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/26/2014 03:49 PM, Andrew Lutomirski wrote: On Sun, Jan 26, 2014 at 12:38 PM, Richard W.M. Jones rjo...@redhat.com wrote: Slightly OT, but is SELinux stopping programs from executing code at address zero? (And how can I stop it doing that?) JONESFORTH, a public domain FORTH I wrote, is written in x86 assembler and prefers to put its threaded interpreter at address 0. This worked fine before, but has now stopped working, and this is reported to be due to SELinux. IIRC, in new kernels, /proc/sys/vm/mmap_min_addr and MAC policy both have to allow the mmap call. In older kernels, only one of them had to allow it. Maybe some day SMAP-capable machines (e.g. Haswell, I think) will ignore these settings entirely -- I think that SMAP covers all the cases that mmap_min_addr was meant to pretect against. --Andy setsebool -P mmap_low_allowed 1 Will turn off this protection from an SELinux point of view, although you should be careful with this. http://rwmj.wordpress.com/2010/08/07/jonesforth-git-repository/#comment-6591 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLmfwEACgkQrlYvE4MpobOECwCfVZ5Q7fMjcYQQ/KHRZF2krmq3 07EAn0BUTIuX/i3WtlEd3MBaMXqpj5Xl =dnIj -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: I want to turn on a part of the kernel to make SELinux checking more stringent.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/24/2014 07:29 PM, Alek Paunov wrote: On 24.01.2014 21:20, Daniel J Walsh wrote: No, we pretty much allow executable stack/memory from user processes now and block it for most daemons, except for those that need it. My understanding of this change is that the kernel was not doing complete checking, but most apps at this point do the right thing. We will turn it on in Rawhide and through the beta. If we see problems we will revert. It is now a one line change in SELinux newbie question: Where the daemons exception is actually defined. My practical interest is: What should be added to LuaJIT [1] to be able to run e.g. non-packaged web servers like [2]? Thanks, Alek [1] http://pkgs.fedoraproject.org/cgit/luajit.git/plain/luajit.spec [2] https://github.com/kernelsauce/turbo I don't really understand your question. When you run your Web Server does SELinux actually block anything? -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLmf1EACgkQrlYvE4MpobMNAQCeKcLabW047Plzf6MDdXUIfBEk uBMAn3Oq2ZBEnvDQcKLdV8u/iKEz3CTu =mdtX -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review swap or Sponser request: the_silver_searcher
OK, I created new report[1] to be the reporter of a review request.*1 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1057991 Dridi, can you please review it, if you can. I know I still need to look for the sponsor, but it is helpful. Thank you in advance, *1 I closed old report as duplicated. I sent e-mail Henrik. Altough have not get a reply yet, according to old report's comment #34, it will be ok. Kenjiro - 元のメッセージ - 差出人: Matthias Runge mru...@matthias-runge.de 宛先: devel@lists.fedoraproject.org 送信済み: 2014年1月27日, 月曜日 午後 9:02:33 件名: Re: Review swap or Sponser request: the_silver_searcher On 01/27/2014 09:51 AM, Dridi Boukelmoune wrote: I would have happily reviewed the package but I've been swamped for a few weeks, and I didn't know how to handle the takeover. Also as Christopher mentioned, I'm not a sponsor, so I can't approve the submission (I'm aware of that). I've stepped down and removed the review flag because I don't know whether I can review it and let a sponsor then approve it. Now once a new review request is submitted, and if I can review it and let the sponsor handle the rest, you can count on me. Thank you Dridi for stepping up here: One nit: https://fedoraproject.org/wiki/Package_Review_Process#Reviewer states clearly: If it is the first package of a Contributor, the Reviewer must be in the Sponsor group Nevertheless, a review will help anyway, as it should clear all issues with the package. 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
2014-01-26 Michael Scherer m...@zarb.org: Le dimanche 26 janvier 2014 à 18:14 +0100, Heiko Adams a écrit : Am Sonntag, den 26.01.2014, 12:01 -0500 schrieb Rahul Sundaram: Hi On Sun, Jan 26, 2014 at 11:57 AM, drago01 wrote: No this isn't an issue at all. No one is saying that non gui apps are useless or should be removed. The point is that gui installer installs gui apps. If you want to install a command line tool whats wrong with using the command line for that? If you don't know how to use the command line there is no point in installing it in the first place. I can use yum just fine but I don't find it convenient to go to the gui for gui apps and then remember to go use yum to install command line apps. Following this logic users have to use yum, dnf, yumex oder gnome-packagekit-installer to install i.e. additional GUI-Themes or mouse-cursors because they are no apps and for that reason not listed in gnome-software, right? If yes, that's IMHO absolute bullshit! It would make more sense to install them directly from the tool that set the mouse cursors, or the theme. Why switch to a different tool ( ie, a software installer ) to install something that is not a software ? So every application that could be extended would have to be rewritten? How would you solve stuff like extra gvfs-components? Have that support in nautilus? /Andreas Tunek -- Michael Scherer -- 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: Drawing lessons from fatal SELinux bug #1054350
On Fri, Jan 24, 2014 at 11:46:41PM +0100, Michael Schwendt wrote: Any ideas how to attract more testers? How to make the updates-testing repo more sexy? * More automated smoke-tests, so that: a) you know the most boring tests have been handled so you can focus on more interesting apsects of the update a) it's less likely that something broken will slip through, so it's more safe to keep the testing repo active * possibly adding a what should users test? field to the update info. I know that there's a notes field in the update, but maybe it'd help to explicitly include testing instructions? Each package in the pkgdb (or in git, or wherever) could have a standard list included in each update as the default (for example, for 'calc', it might be to try `calc -q read /usr/share/calc/regress.cal`. That would duplicate a likely smoke-test, though, so maybe also run interactively and make sure basic math works. Then, each update could also optionally (and this would be presented in bold if it were used) say something like New release adds log() function; please test that it works, or Severe bug where 1+1=3 corrected; please test that the answer now corresponds with consensus reality. * badges! We already have this, but making them more visible would help. People on Stack Exchange get crazily obsessed with quality control all in exchange for digital gold stars. * In fact, this ties into the general problem that various bits of Fedora are disconnected and not particularly discoverable. You can find them if you're looking, but mostly out-of-site, out-of-mind. Unless one is already engaged, how would one even know that this is really an easy way to help? * Present pending updates in a more informative way. Let's say I'm in the mood to be helpful and test some stuff and earn some badges. I go to https://admin.fedoraproject.org/updates/ (because I have that bookmarked; see the previous point). I see a list of package names, and update types. Maybe I recognize something, maybe I don't. I don't right now, it happens, so I think okay, there's xflr5. Maybe that's interesting. I click on https://admin.fedoraproject.org/updates/xflr5-6.09.06-1.fc20, and am immediately shown that this is only a package I should care about if I already know what it is -- that is, there's no description at all. The update note is reasonably helpful as these things go (it's an update to a new upstream version), but the URL isn't hyperlinked, and when I go there, Sourceforge and makes me wait and then makes the file download instead of displaying it. And then I see that this program is very a technical airplane engineering program and I'm not qualified to test it. Okay, there went five minutes of my life. Shall I guess another one? Hmmm, maybe alleyoop. Will there be cavemen? Okay, also no description, so I'll do yum info in a shell. Ah, okay, memory debugger GUI. Okay, I can test that one but it's not necessarily gonna be quick Anyway. The list could be more informative. Maybe I could even star particular packages I'm interested in, and future updates would show up first. And after choosing something, the above idea of having a quick description of what to test would help here too. * Silly, but... remember my login in bodhi longer, so there are fewer steps. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.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: Fedora.next in 2014 -- Big Picture and Themes
On 01/27/2014 01:06 PM, Stephen Gallagher wrote: No. The Products will be defining an environment and a standard install set. They may have separate initial*installation* repositories if they need to provide different options to Anaconda, but beyond that the intent is for all of the Products to continue to draw from the same store of packages together. If (for example) we got ourselves into a situation where you couldn't install Fedora Server and then also install the GNOME desktop environment on that Server, this would be considered a major bug and one that we would need to reconcile immediately. So what exactly changes if the above step is considered a major bug? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
Le lundi 27 janvier 2014 à 17:11 +0100, Andreas Tunek a écrit : 2014-01-26 Michael Scherer m...@zarb.org: Le dimanche 26 janvier 2014 à 18:14 +0100, Heiko Adams a écrit : Am Sonntag, den 26.01.2014, 12:01 -0500 schrieb Rahul Sundaram: Hi On Sun, Jan 26, 2014 at 11:57 AM, drago01 wrote: No this isn't an issue at all. No one is saying that non gui apps are useless or should be removed. The point is that gui installer installs gui apps. If you want to install a command line tool whats wrong with using the command line for that? If you don't know how to use the command line there is no point in installing it in the first place. I can use yum just fine but I don't find it convenient to go to the gui for gui apps and then remember to go use yum to install command line apps. Following this logic users have to use yum, dnf, yumex oder gnome-packagekit-installer to install i.e. additional GUI-Themes or mouse-cursors because they are no apps and for that reason not listed in gnome-software, right? If yes, that's IMHO absolute bullshit! It would make more sense to install them directly from the tool that set the mouse cursors, or the theme. Why switch to a different tool ( ie, a software installer ) to install something that is not a software ? So every application that could be extended would have to be rewritten? not rewritten, but extended. How would you solve stuff like extra gvfs-components? Have that support in nautilus? like we do for gstreamer or fonts. In the case of gvfs, this could manifests by people trying to connect to ftp, and then showing a popup this url is not supported, but we can install it. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Class-Data-Inheritable] Created tag perl-Class-Data-Inheritable-0.08-0.3.1.el6
The lightweight tag 'perl-Class-Data-Inheritable-0.08-0.3.1.el6' was created pointing to: 5ed815e... Prefix release with 0. for limited-arch EPEL support -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: icecat or/and firefox?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Icecat package review has NOT the goal to replace Firefox in Fedora. I wish to offer the opportunity to everyone of try a browser like so a GNU user would do. - -- Antonio Trande mailto: sagitterATfedoraproject.org http://www.fedoraos.worpress.com https://fedoraproject.org/wiki/User:Sagitter GPG Key: D400D6C4 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS5peJAAoJED2vIvfUANbEKfcP/jqhZxxm/ynh/3M8JYVaapTR 8hPpKW+ihSAsM96cYXMjMifQ+OcG5RhL+usjvL8p2IJRWEbiQuY66zla7/XQ03B3 8dLPbxgU6PlKw5hkR3+yS5rylyIp89SOWh1hDaag13UDUrPIm5tyr6UzHK+kZfkr tb6N9LUuXodTW2HlPuEuCkO8rKYrlEaEKAIT1FKIVB9oOhnYAeHrHPevLhXsORz1 eZHs8bPzorJLCRvv3PhMF9AswIlBU6X9gi1bPTx2R7jvM0hrFlE2NcyNd2Y/FbsF 9+pjR/eqCnq5boy6y3Go6ah9WFto81DcnsSyvaVWxEA9MfuLFUyohV2yqOM5PBFO wGz0cq24dTrXIISquhdyLoougxezRGCdJt4QwGuCbGuWYgDJOrD6R7UGGW6BJRVP c4aiMKSGxJ6MTkSzNGWBSoTJyhOUCbMRpNL6O31R/l1SQqrg1uKeNcpt0dyvENyd eyzCbS65w3uS5QwS7lzzYIxxnQQRF2u7JaN0dbgTU2fTbMWQd15/V3QcEbpRXHTY 8IFbCNH9C2Acc+JWzDX8uX+Mkc8nrFouYmgcmP6Jm81/nbrJyBghIWrsBt5eMITH hOcaHgztBzBW3VLYrxiJWD2poxfiukfKhVUAQS/6koSXWLxYObobBfGpBu4NFisD NKjvyxhnvhHNqgUVRxL2 =7n9z -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: .spec file Source0 magic for github release source tarballs?
On Fri, Jan 24, 2014 at 4:57 PM, Adam Williamson awill...@redhat.com wrote: On Fri, 2014-01-24 at 08:13 -0500, Stephen Gallagher wrote: Interesting... However, if you're working with an actual release tag, I would think Peter's method would be much better. It is a good idea to use a specific commit as your source, not a tag, because the tag can be silently edited, and then you lose source reproducibility. Yes, this is a problem with tarballs too - upstream can always ninja the tarball - but look at it this way: github affords us the ability to avoid that problem, and so we should take it. Actually, it's not a problem with tarballs. That's *precisely* why we store the tarball hashes. This way, we at least know whether they still match. It's still better to avoid the problem than to know it exists...I don't think we disagree, I'm just explaining why (I think) it's a good idea to use a commit ID for a github project even if a tarball is available. I'm currently working on a way to prove that a tarball matches a git commit id. It's maybe 1/4 done. The idea is that you could do $ xzcat tarball.tar.xz |git untar --commit=1234abc38387272... --prefix=project-1.23 And you'd get an error if the tarball has been tampered with. (Or if the packager messed up.) The main gotcha I can think of so far is that a lot of projects have release scripts that generate autotools files and such. Those wouldn't be compatible with this scheme (or those files could be stripped back out at untar time and regenerated by a specfile, perhaps). If/when this is done and makes it into upstream git, it would be nice to integrate this into rpm / fedpkg / wherever it goes. I know nothing about rpm internals, though. FWIW, heavyweight git tags can't be rewritten. --Andy -- 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.next: I would like working configurations
Hi, might be totaly out of scope for Fedora.next, but this is what I would like to get better in Fedora. If I install a Windows-Server with some services like DHCP or file services, I get a working configuration. - If I install a Fedora-server with dhcpd, dhcpd doesn't do anything - If I install tftpd and syslinux, I don't get a working pxe-config - If I install postfix, I don't get a working mail-server - If I install Nagios, it does not monitor report anything ... I have no idea, how to change this. Debian uses some interactive stuff to create a more or less working configuration while installing a package. This resembles the Microsoft installation tools. But rpm is strictly non-interactive, so this would not work for Fedora. I think this is a real problem. The missing working default-configs are a real hassle for replacing small servers in Windows-shops with Linux as the non-expert-Linux-admin has an enormous entry-barrier to get some minumum working configuration from which he can start. To build a Fedora-Server which does the needed ip address management stuff for a modern network (dhcpd with dynamic bind-updates for IPv4 and IPv6 plus forwarding to the isp) is non-trivial, even for a long time admin. Perhaps meta-packages (call them roles or stacks if you like) like ipam (pulls in dhcpd, bind, ... plus some config-files) or mail-server (pulls in postfix, imap, fetchmail, ...) might be the solution. I have no idea how to do this. Combing several packages and integrating them would produce some interessting test-problems. How to avoid colliding apache-configs done by different meta-packages, ... cu romal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/27/2014 01:31 PM, Robert M. Albrecht wrote: Hi, might be totaly out of scope for Fedora.next, but this is what I would like to get better in Fedora. If I install a Windows-Server with some services like DHCP or file services, I get a working configuration. - If I install a Fedora-server with dhcpd, dhcpd doesn't do anything - If I install tftpd and syslinux, I don't get a working pxe-config - If I install postfix, I don't get a working mail-server - If I install Nagios, it does not monitor report anything ... I have no idea, how to change this. Debian uses some interactive stuff to create a more or less working configuration while installing a package. This resembles the Microsoft installation tools. But rpm is strictly non-interactive, so this would not work for Fedora. I think this is a real problem. The missing working default-configs are a real hassle for replacing small servers in Windows-shops with Linux as the non-expert-Linux-admin has an enormous entry-barrier to get some minumum working configuration from which he can start. To build a Fedora-Server which does the needed ip address management stuff for a modern network (dhcpd with dynamic bind-updates for IPv4 and IPv6 plus forwarding to the isp) is non-trivial, even for a long time admin. Perhaps meta-packages (call them roles or stacks if you like) like ipam (pulls in dhcpd, bind, ... plus some config-files) or mail-server (pulls in postfix, imap, fetchmail, ...) might be the solution. I have no idea how to do this. Combing several packages and integrating them would produce some interessting test-problems. How to avoid colliding apache-configs done by different meta-packages, ... cu romal What you are describing is the exact problem space we intend to address in the Fedora Server product with Server Roles. I strongly suggest reading the Server Roles section of our PRD[1] and then joining the discussion that was just started on the Fedora Server development list[2] DHCP is certainly a useful example (and called out in our PRD as one of the cases we'd like to address eventually). Right now we're focusing our intent on delivering a single end-to-end Server Role for Fedora 21. We're probably going to select the FreeIPA Domain Controller for this purpose, but if we determine that we don't have sufficient time for that, we may go for a smaller initial target. DHCP might be a good one. Anyway, your ideas are good, Robert. They line up well with what we want to do, so I very much hope you'll join the conversation (and implementation!). [1] https://fedoraproject.org/wiki/Server/Product_Requirements_Document#Featured_Server_Roles [2] https://lists.fedoraproject.org/pipermail/server/2014-January/000717.html -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLmqp4ACgkQeiVVYja6o6NZFwCgmg68rV9ratWZg1hg/Kkgrkei rdgAoJtiwrIZ7EF/jeWD/ENymj0npdxr =TlRM -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: icecat or/and firefox?
On 27.01.2014 05:08, Christopher Meng wrote: Hi, Here is an interesting package icecat[1], which is a more free version firefox. Do we allow this in Fedora now? Thanks. [1]--https://bugzilla.redhat.com/show_bug.cgi?id=1048493 http://copr.fedoraproject.org/coprs/sagitter/Icecat/ http://copr.fedoraproject.org/coprs/sagitter/Icecat/repo/fedora-20-i386/ gpgcheck=0 !? Signing Built RPMs http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch11s04.html poma -- 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: icecat or/and firefox?
On Mon, 27 Jan 2014 19:45:48 +0100 poma pomidorabelis...@gmail.com wrote: On 27.01.2014 05:08, Christopher Meng wrote: Hi, Here is an interesting package icecat[1], which is a more free version firefox. Do we allow this in Fedora now? Thanks. [1]--https://bugzilla.redhat.com/show_bug.cgi?id=1048493 http://copr.fedoraproject.org/coprs/sagitter/Icecat/ http://copr.fedoraproject.org/coprs/sagitter/Icecat/repo/fedora-20-i386/ gpgcheck=0 !? Signing Built RPMs http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch11s04.html copr has no provision currently to sign packages. I think it's on the todo list, but it will not be easy to implement in a secure way. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
On Mon, Jan 27, 2014 at 19:31:58 +0100, Robert M. Albrecht li...@romal.de wrote: I think this is a real problem. The missing working default-configs are a real hassle for replacing small servers in Windows-shops with Linux as the non-expert-Linux-admin has an enormous entry-barrier to get some minumum working configuration from which he can start. You seem to be conflating two things. One is reasonable default configuration and the other is turning on services by default. I think the first is reasonable, but that the second is a bad idea. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/27/2014 01:50 PM, Bruno Wolff III wrote: On Mon, Jan 27, 2014 at 19:31:58 +0100, Robert M. Albrecht li...@romal.de wrote: I think this is a real problem. The missing working default-configs are a real hassle for replacing small servers in Windows-shops with Linux as the non-expert-Linux-admin has an enormous entry-barrier to get some minumum working configuration from which he can start. You seem to be conflating two things. One is reasonable default configuration and the other is turning on services by default. I think the first is reasonable, but that the second is a bad idea. He's not suggesting turning services on by default just by installing pacakges (I don't think). I think his request here is similar to our Fedora Server Roles idea where there are special packages (possibly meta-packages) that are separate from the simple installed bits. So you might have the server-role-dhcp package that 'Requires: dhcp' but also provides either a default (and reasonably-secure) configuration or some mechanism to interactively configure and deploy a DHCP server. So if someone installed the 'dhcp' package on its own, this would not autostart it. However, if someone deployed the DHCP Server role, that should be considered a sufficiently intentional action to start it. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLmrQwACgkQeiVVYja6o6MG8QCgsQDPrJx7IhGcKK0TfiruFxhJ 1BEAoKo3ze3+vEzGUZ9L3tIDoa4K1lbQ =vGV/ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20
On Sat, 2014-01-25 at 17:24 +0100, Kevin Kofler wrote: Paolo Bonzini wrote: From the BlueZ 5.0 release notes: Remove internal support for telephony (HFP and HSP) profiles. They should be implemented using the new Profile interface preferably by the telephony subsystem of choice (e.g. oFono which already supports this) For Fedora this means PulseAudio. This is a recurring problem in Fedora: Developers of software X think that feature Z is better done in software Y and happily remove Z from X, often without even talking to the developers of Y, and always without waiting for Y to actually implement the feature. In some cases, it is not even clear whether Z can be implemented properly (i.e., to the extent it was in X) in Y, I don't know whether that's the case here or whether it's just a matter of time. Features MUST NOT get removed without a working replacement! Unfortunately, it's upstream Bluez that removed/changed these features for version 5. And the upstream Bluez developers stopped working on Bluez4 in mid-2012. So staying with Bluez4 would have meant using a very, very out-of-date Bluez that Fedora developers would have to maintain, since upstream clearly wasn't interested. Dan -- 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: icecat or/and firefox?
On 27.01.2014 19:52, Kevin Fenzi wrote: copr has no provision currently to sign packages. I think it's on the todo list, but it will not be easy to implement in a secure way. Ouch! poma -- 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: icecat or/and firefox?
http://copr.fedoraproject.org/coprs/sagitter/Icecat/builds/ Results: http://copr-be.cloud.fedoraproject.org/results/sagitter/Icecat/ http://copr-be.cloud.fedoraproject.org/results/sagitter/Icecat/fedora-20-x86_64/ http://copr-be.cloud.fedoraproject.org/results/sagitter/Icecat/fedora-20-x86_64/icecat-24.0-1.fc20/icecat-24.0-1.fc20.src.rpm Package URLs: http://sagitter.fedorapeople.org/Icecat/icecat-24.0-1.fc20.src.rpm Not Found The requested URL /Icecat/icecat-24.0-1.fc20.src.rpm was not found on this server. Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request. http://sagitter.fedorapeople.org/Icecat/ Name Last modified Size Parent Directory- icecat-24.0-2.fc20.src.rpm 08-Jan-2014 16:23 157M icecat-24.0-3.fc20.src.rpm 16-Jan-2014 18:07 157M icecat.spec16-Jan-2014 18:08 9.4K The multitude of all kinds of links! :) poma -- 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: icecat or/and firefox?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/27/2014 07:56 PM, poma wrote: http://copr.fedoraproject.org/coprs/sagitter/Icecat/builds/ Results: http://copr-be.cloud.fedoraproject.org/results/sagitter/Icecat/ http://copr-be.cloud.fedoraproject.org/results/sagitter/Icecat/fedora-20-x86_64/ http://copr-be.cloud.fedoraproject.org/results/sagitter/Icecat/fedora-20-x86_64/icecat-24.0-1.fc20/icecat-24.0-1.fc20.src.rpm Package URLs: http://sagitter.fedorapeople.org/Icecat/icecat-24.0-1.fc20.src.rpm Not Found The requested URL /Icecat/icecat-24.0-1.fc20.src.rpm was not found on this server. Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request. http://sagitter.fedorapeople.org/Icecat/ Name Last modified Size Parent Directory - icecat-24.0-2.fc20.src.rpm 08-Jan-2014 16:23 157M icecat-24.0-3.fc20.src.rpm 16-Jan-2014 18:07 157M icecat.spec 16-Jan-2014 18:08 9.4K The multitude of all kinds of links! :) I don't know what you mean. In copr there is first release of Icecat that I've built. In fedorapeople.org I upload all later releases little by little package review advances. Latest release is here: http://koji.fedoraproject.org/koji/taskinfo?taskID=6455790 - -- Antonio Trande mailto: sagitterATfedoraproject.org http://www.fedoraos.worpress.com https://fedoraproject.org/wiki/User:Sagitter GPG Key: D400D6C4 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS5rDXAAoJED2vIvfUANbEHGoP/0QPLFA5+Ohbazk1mJbC7NTu JuWe/i6uZ439de8Et3frIEe3vdKiuISAM43y1zWk7BZvvrYSLhHt4ISpKkloUhP4 w6RgseLyjNdTZ0zisdxLGcU+TkmHxPsY1C5n+K4Rp3JUXaOisejYSePlEZ/GdsE2 sI5U9kkrqBt7xkZVhe1vEsDbLPxgIjCrsVgdTolderWynQ+x3uuKKWsuOUN3FQL+ JAMtWPI0qe26de52haDO4buCEBxNXZJK213bCfHeUswcJTbRSEOYWg33I9VIlB4m PeJYOAPKegcOS89Vpfdb6oOzbwy2c0w98Poub+KQfV53fGqLW11B4i3TuZ/vuuPh NqKyrO2xrSbL2S3R76CXdRHFAb99AprlCDPS8QxkJJkRwaQkmYzhO4J3d28vfKL9 2wtMzd8LSgxquOKLbKat8rsjkhtxLpAzdWJh9HvqX1K8GqeU2HpvGFVQMYsHpNnU FiI9IYFP5nTlDhP+JPlLSIJtZtKTJYB1qFVeAmqlVF/IBa3pcAJc3LwxvMDQg3A4 m4vJIjZO8s8aXoOIzIzoRW9kk1iXTBBIooCERacf00C3YyiAyPeKffzFozKgw+Yr bLLJj4Cg4FUpTItrX588ykr7PhR2fi/962PZmvcIp2wCx3KCX/4v64x28RKO/0c8 Jc6hZjzR9/Q2OmnJYdF9 =DzKo -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
On Sun, 2014-01-26 at 13:05 +0100, drago01 wrote: Installing an application and then not finding it anywhere is confusing. So we limit it to visible apps i.e GUI apps. Before people get too angry about this: Software is being designed as a tool to do what's being discussed in this thread, i.e. install things that actually count as 'Software a user might want to install from a tool for installing software'. It doesn't have a monopoly on the Graphical Tool To Install Things space. The old gnome-packagekit installer still exists, and you could still work on that. yumex still exists, and you can work on that. All desktops and spins and so on can choose to include whatever graphic tool(s) for package installation they see fit. The fact that Software is being designed to do a particular job does not preclude anyone from working on or using alternative tools designed to do different jobs. -- 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: icecat or/and firefox?
On Mon, Jan 27, 2014 at 10:59 AM, poma pomidorabelis...@gmail.com wrote: On 27.01.2014 19:52, Kevin Fenzi wrote: copr has no provision currently to sign packages. I think it's on the todo list, but it will not be easy to implement in a secure way. Ouch! I'm skeptical about the whole package-signing thing. Why don't we sign repository metadata and have that metadata store hashes of the appropriate packages? Then adding a key for a repository wouldn't magically allow that key to sign packages claiming to come from a different repository. It would also prevent various replay-old-package attacks. Configuration could be simpler, too: [some-copr-repo] name=Name metalink=whatever metalink_key=[private key, specified right here] gpgcheck=0 I doubt that GPG's keyring concepts or web-of-trust stuff add any security whatsoever to things like rpm and yum. They do, however, make configuration unnecessarily arcane. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
Once upon a time, Robert M. Albrecht li...@romal.de said: If I install a Windows-Server with some services like DHCP or file services, I get a working configuration. Can you be more specific on what you mean by working configuration? As far as I know, you still have to configure the service on Windows before it does anything. How could a default install of a DHCP service possibly know what to do without configuration? -- Chris Adams li...@cmadams.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: Fedora.next: I would like working configurations
Most of the services you described do have a working configuration but the service is not turned on. You are right though, when you install a Windows CA it's ready to go. In regards to DHCP, the dhcpd.conf file has a commented sample that needs to be edited and then turned on. Is this what you are looking for? On 27/01/14 14:33, Chris Adams wrote: Once upon a time, Robert M. Albrecht li...@romal.de said: If I install a Windows-Server with some services like DHCP or file services, I get a working configuration. Can you be more specific on what you mean by working configuration? As far as I know, you still have to configure the service on Windows before it does anything. How could a default install of a DHCP service possibly know what to do without configuration? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up; F22 will require applications to ship appdata to be listed in software center
2014-01-27 Michael Scherer m...@zarb.org: Le lundi 27 janvier 2014 à 17:11 +0100, Andreas Tunek a écrit : 2014-01-26 Michael Scherer m...@zarb.org: Le dimanche 26 janvier 2014 à 18:14 +0100, Heiko Adams a écrit : Am Sonntag, den 26.01.2014, 12:01 -0500 schrieb Rahul Sundaram: Hi On Sun, Jan 26, 2014 at 11:57 AM, drago01 wrote: No this isn't an issue at all. No one is saying that non gui apps are useless or should be removed. The point is that gui installer installs gui apps. If you want to install a command line tool whats wrong with using the command line for that? If you don't know how to use the command line there is no point in installing it in the first place. I can use yum just fine but I don't find it convenient to go to the gui for gui apps and then remember to go use yum to install command line apps. Following this logic users have to use yum, dnf, yumex oder gnome-packagekit-installer to install i.e. additional GUI-Themes or mouse-cursors because they are no apps and for that reason not listed in gnome-software, right? If yes, that's IMHO absolute bullshit! It would make more sense to install them directly from the tool that set the mouse cursors, or the theme. Why switch to a different tool ( ie, a software installer ) to install something that is not a software ? So every application that could be extended would have to be rewritten? not rewritten, but extended. How would you solve stuff like extra gvfs-components? Have that support in nautilus? like we do for gstreamer or fonts. In the case of gvfs, this could manifests by people trying to connect to ftp, and then showing a popup this url is not supported, but we can install it. So someone has to rewrite nautilus (and a lot of other apps) then? /Andreas -- Michael Scherer -- 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
[perl-Test-Mojibake] Bootstrap epel7 build
commit f1bf3e60921e3d9d3972503e735499de5c2778ab
Author: Paul Howarth p...@city-fan.org
Date: Mon Jan 27 20:26:25 2014 +
Bootstrap epel7 build
perl-Test-Mojibake.spec | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
---
diff --git a/perl-Test-Mojibake.spec b/perl-Test-Mojibake.spec
index eb08224..4fdbf1b 100644
--- a/perl-Test-Mojibake.spec
+++ b/perl-Test-Mojibake.spec
@@ -4,9 +4,14 @@
# noarch, but to avoid debug* files interfering with manifest test:
%global debug_package %{nil}
+# bootstrap epel7 build
+%if 0%{?rhel}
+%global perl_bootstrap 1
+%endif
+
Name: perl-Test-Mojibake
Version: 0.9
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: Check your source for encoding misbehavior
Group: Development/Libraries
License: GPL+ or Artistic
@@ -144,6 +149,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/Test::Mojibake.3pm*
%changelog
+* Mon Jan 27 2014 Paul Howarth p...@city-fan.org - 0.9-2
+- Bootstrap epel7 build
+
* Mon Jan 20 2014 Paul Howarth p...@city-fan.org - 0.9-1
- Update to 0.9
- More consistent UTF-8 naming in docs
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fedora.next: I would like working configurations
Hi, dhcpd is just an (maybe bad) example. But even dhcpd needs a lot of work. I need to configure ranges, options (which could like gateqway and dns partly automagically gathered from the exsting network configuration), ... binding dhcpd to bind to enable dynamic updates, ... and double this stuff for IPv4 and IPv6. I used this only as an example to show that nearly all daemons are not ready-to-run. cups and apache are not sharing user-groups with samba and nagios, ... Integration of services is often possible, but not done when doing a fresh Fedora installation. What I would like is more integration to produce a working server. If I create a user group, it should be known in all installed services. This might not be restricted to servers: all audio-components are there to do some professional work: jack, pulseuaudio, alsa, Audacity, plugins, ... but I have to fiddle them together myself. cu romal Am 27.01.14 21:01, schrieb Dan Lavu: Most of the services you described do have a working configuration but the service is not turned on. You are right though, when you install a Windows CA it's ready to go. In regards to DHCP, the dhcpd.conf file has a commented sample that needs to be edited and then turned on. Is this what you are looking for? On 27/01/14 14:33, Chris Adams wrote: Once upon a time, Robert M. Albrecht li...@romal.de said: If I install a Windows-Server with some services like DHCP or file services, I get a working configuration. Can you be more specific on what you mean by working configuration? As far as I know, you still have to configure the service on Windows before it does anything. How could a default install of a DHCP service possibly know what to do without configuration? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
Hi, if the server sits in a RFC1918 network (192.168.1.0/16), has a static IP and a configured gateway and DNS, it might be reasonable to assume, the dhcpd should operate in this range and set the options for DNS and gateway accordingly. At least the installation could produce a sample-config-file, which reflects the running configuration. Also it could to talk to firewalld to configure the firewall. But I used dhcpd just as a (maybe bad) exmaple to explain my problem. cu romal Am 27.01.14 20:33, schrieb Chris Adams: Once upon a time, Robert M. Albrecht li...@romal.de said: If I install a Windows-Server with some services like DHCP or file services, I get a working configuration. Can you be more specific on what you mean by working configuration? As far as I know, you still have to configure the service on Windows before it does anything. How could a default install of a DHCP service possibly know what to do without configuration? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
Hi, He's not suggesting turning services on by default just by installing pacakges (I don't think). I think his request here is similar to our Fedora Server Roles idea where there are special packages (possibly meta-packages) that are separate from the simple installed bits. So you might have the server-role-dhcp package that 'Requires: dhcp' but also provides either a default (and reasonably-secure) configuration or some mechanism to interactively configure and deploy a DHCP server. So if someone installed the 'dhcp' package on its own, this would not autostart it. However, if someone deployed the DHCP Server role, that should be considered a sufficiently intentional action to start it. Perfect. You are a mind-reader :-) cu romal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Test-Version] Bootstrap build for epel7 done
commit dc1038373c2318e653d59e7442b051f9863befdf
Author: Paul Howarth p...@city-fan.org
Date: Mon Jan 27 21:13:48 2014 +
Bootstrap build for epel7 done
perl-Test-Version.spec | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
---
diff --git a/perl-Test-Version.spec b/perl-Test-Version.spec
index 854896e..8d431e6 100644
--- a/perl-Test-Version.spec
+++ b/perl-Test-Version.spec
@@ -1,14 +1,9 @@
# noarch, but to avoid debug* files interfering with manifest test:
%global debug_package %{nil}
-# bootstrap epel7 build
-%if 0%{?rhel}
-%global perl_bootstrap 1
-%endif
-
Name: perl-Test-Version
Version: 1.002004
-Release: 2%{?dist}
+Release: 3%{?dist}
Summary: Check to see that versions in modules are sane
License: Artistic 2.0
Group: Development/Libraries
@@ -103,6 +98,9 @@ make test %{!?perl_bootstrap:AUTHOR_TESTING=1
RELEASE_TESTING=1}
%{_mandir}/man3/Test::Version.3pm*
%changelog
+* Mon Jan 27 2014 Paul Howarth p...@city-fan.org - 1.002004-3
+- Bootstrap build for epel7 done
+
* Mon Jan 27 2014 Paul Howarth p...@city-fan.org - 1.002004-2
- Bootstrap epel7 build
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fedora.next: I would like working configurations
On 27 January 2014 14:01, Robert M. Albrecht li...@romal.de wrote: Hi, dhcpd is just an (maybe bad) example. But even dhcpd needs a lot of work. I need to configure ranges, options (which could like gateqway and dns partly automagically gathered from the exsting network configuration), ... binding dhcpd to bind to enable dynamic updates, ... The reason why these daemons are not ready to run is that when they used to be ready to run, they caused problems with whatever environment was already there. We used to ship tools which could do what was thought to be a reasonable job of configuring them but it quickly turned into that no one does their environment the same way and doesn't want to be told to do it like anyone else. Being ready out of the box though is not always desirable. I have regularly seen networks go offline because someone installed Microsoft DHCP but not taken into account the already configured DHCP boxes. [The same with AD and other items...] Being ready to work works well in small environments but quickly causes more headaches in more complex ones. Having to account for that is where most of the things that need the admin to really know what is going on in their environment and being able to translate to making the computer do what is needed versus what is wanted. It isn't an insurmountable problem, and I guess the Server Roles or something similar will help do that but it will take a lot of work to get there. -- 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: Drawing lessons from fatal SELinux bug #1054350
On Mon, 27 Jan 2014 10:18:56 -0500 Matthew Miller mat...@fedoraproject.org wrote: snip * possibly adding a what should users test? field to the update info. I know that there's a notes field in the update, but maybe it'd help to explicitly include testing instructions? Each package in the pkgdb (or in git, or wherever) could have a standard list included in each update as the default (for example, for 'calc', it might be to try `calc -q read /usr/share/calc/regress.cal`. That would duplicate a likely smoke-test, though, so maybe also run interactively and make sure basic math works. Then, each update could also optionally (and this would be presented in bold if it were used) say something like New release adds log() function; please test that it works, or Severe bug where 1+1=3 corrected; please test that the answer now corresponds with consensus reality. I could have sworn we already had something like this where bodhi would add a link to a wiki page for test plan on a package if that wiki page existed. I can't seem to find it now, so perhaps it was just something we talked about, but never implemented. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: icecat or/and firefox?
On 27.01.2014 20:17, Antonio Trande wrote: On 01/27/2014 07:56 PM, poma wrote: http://copr.fedoraproject.org/coprs/sagitter/Icecat/builds/ … Package URLs: http://sagitter.fedorapeople.org/Icecat/icecat-24.0-1.fc20.src.rpm Not Found The requested URL /Icecat/icecat-24.0-1.fc20.src.rpm was not found on this server. Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request. … I don't know what you mean. In copr there is first release of Icecat that I've built. … Say whaaat? :) At least one broken link!? I know there is a repo, but nonetheless. poma -- 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: icecat or/and firefox?
On 27.01.2014 20:28, Andrew Lutomirski wrote: On Mon, Jan 27, 2014 at 10:59 AM, poma pomidorabelis...@gmail.com wrote: On 27.01.2014 19:52, Kevin Fenzi wrote: copr has no provision currently to sign packages. I think it's on the todo list, but it will not be easy to implement in a secure way. Ouch! I'm skeptical about the whole package-signing thing. Why don't we sign repository metadata and have that metadata store hashes of the appropriate packages? Then adding a key for a repository wouldn't magically allow that key to sign packages claiming to come from a different repository. It would also prevent various replay-old-package attacks. Configuration could be simpler, too: [some-copr-repo] name=Name metalink=whatever metalink_key=[private key, specified right here] gpgcheck=0 I doubt that GPG's keyring concepts or web-of-trust stuff add any security whatsoever to things like rpm and yum. They do, however, make configuration unnecessarily arcane. We shouldn't change so easily tried and tested methods just because you doubt. :) Ouch[2]! poma -- 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: icecat or/and firefox?
On Mon, 27 Jan 2014 20:41:35 +0100 poma pomidorabelis...@gmail.com wrote: On 27.01.2014 20:28, Andrew Lutomirski wrote: On Mon, Jan 27, 2014 at 10:59 AM, poma pomidorabelis...@gmail.com wrote: ...snip... I'm skeptical about the whole package-signing thing. skeptical in what way? Why don't we sign repository metadata and have that metadata store hashes of the appropriate packages? Then adding a key for a repository wouldn't magically allow that key to sign packages claiming to come from a different repository. It would also prevent various replay-old-package attacks. Sure, but if you install a package not from the repo you have no way to know it's valid without that repodata being available to check against. Also, old packages won't be verifable anymore when repodata changes to drop them. Configuration could be simpler, too: [some-copr-repo] name=Name metalink=whatever metalink_key=[private key, specified right here] gpgcheck=0 Something would need to generate the metalinks then... Feel free to file it as a RFE for copr... perhaps it would work out there. I doubt that GPG's keyring concepts or web-of-trust stuff add any security whatsoever to things like rpm and yum. They do, however, make configuration unnecessarily arcane. We shouldn't change so easily tried and tested methods just because you doubt. :) Ouch[2]! Well, there are advantages to moving to signing repodata. There's also disadvantages. For Fedora repos, it's not worth it. It might be the tradeoffs are different in copr and it's a better option there. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
On 27.01.2014 22:01, Robert M. Albrecht wrote: Hi, dhcpd is just an (maybe bad) example. It is good example. See dhcp configuration in your home router - it requires some attention. Then try some Cisco or HP router and its dhcp configuration. This smart devices are not so smart to work for everybody out of the box. This is also true for Linux versions of this daemon. But even dhcpd needs a lot of work. I need to configure ranges, options (which could like gateqway and dns partly automagically gathered from the exsting network configuration), ... binding dhcpd to bind to enable dynamic updates, ... and double this stuff for IPv4 and IPv6. You can disable IPv6 if you don't need it. How can any software possibly know your network address before you enter it during installation? How would dhcpd daemon know IP ranges you want to lease to hosts on your network? Read your mind? I used this only as an example to show that nearly all daemons are not ready-to-run. cups and apache are not sharing user-groups with samba and nagios, ... Because I don't want that functionality. If it's what you need, please learn how to do it and just do it. No one is preventing you from doing that. Integration of services is often possible, but not done when doing a fresh Fedora installation. Because different people need to integrate different things. But it's not entirely true what you said, take a look at FreeIPA, perfect example of integrated service. What I would like is more integration to produce a working server. If I create a user group, it should be known in all installed services. It is... or you're doing something wrong. What kind of user accounts are not recognized by what software? This might not be restricted to servers: all audio-components are there to do some professional work: jack, pulseuaudio, alsa, Audacity, plugins, ... but I have to fiddle them together myself. What? Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
On Jan 27, 2014, at 2:16 PM, Stephen John Smoogen smo...@gmail.com wrote: The reason why these daemons are not ready to run is that when they used to be ready to run, they caused problems with whatever environment was already there. We used to ship tools which could do what was thought to be a reasonable job of configuring them but it quickly turned into that no one does their environment the same way and doesn't want to be told to do it like anyone else. At least with something cleanly installed, I'd like it to work with Fedora's best practices in mind, understanding what is best practices is often in flux. One thing I see Fedora doing is helping me sharpen the saw, not do things my way. Best practices doesn't necessarily mean on by default, however. 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: Fedora.next: I would like working configurations
On 27.01.2014 22:05, Robert M. Albrecht wrote: Hi, if the server sits in a RFC1918 network (192.168.1.0/16), has a static IP and a configured gateway and DNS, it might be reasonable to assume, the dhcpd should operate in this range and set the options for DNS and gateway accordingly. Imagine Linux box with three NICs, each on different network. To simplify things let there be NAT and and two public addresses (some kind of failover.) What interface should dhcp server operate on? What address pools should be used there? It can't be easily deduced without admin intervention. Too much use cases. Mateusz Marzantowicz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Heads up: libxcb (partial) soname bumps in Rawhide
Two of the libraries emitted by libxcb (for XKB and SYNC extension support) have changed soname in 1.10. Sorry about that. Outside of libxcb itself the only packages affected are qt5-qtbase, kde-workspace, sddm, and weston; all have been rebuilt. Thanks to Rex Dieter for helping work around the qt5 bootstrap issues. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next: I would like working configurations
On Monday 27 January 2014 14:01:32 Stephen Gallagher wrote: ... or some mechanism to interactively configure and deploy a DHCP server. IMO, that's exactly the crux of the matter. Most non-trivial services requires some administrative decisions to configure them properly. Since rpm does not allow interactive query of the user (IMO rightfully), everybody implement custom solutions: * Some custom scripts (e.g: freeipa-server-install) * Only hand configuration (e.g: dhcpd) * Some web-based PHP configuration (many php web-applications that look for an easy solution to a tough problem and forget about security along the way...) Just like packaging systems implemented a common framework to install software, we need a common framework to *configure* it (at least base configuration if the full configuration management problem is too tough). My suggestion is to look first at the debconf abstract model. Let's start with one design decision which I think we should avoid: * Debian triggers debconf operations from the package installer. This means package installation is potentially interactive (not good). I think the configuration mechanism should be explicitly called from elsewhere. (e.g: when administrator want to activate/configure the service). But now, let's look at the good properties which we can learn from: * All configuration options are name-spaced (in debconf it's done by package name) * Each configuration option has specific *type* info (string, boolean, multi-select, etc.) * A package installation register its configuration options in a system-wide database. * This also contains end-user visible text for each option including i18n. * The debconf database may be populated via different front-ends: GUI, TUI, command-line, web-based (experimental), preseed (for kickstart install). * All front ends need only understand the generic types of the options. (I.e: they provide generic configuration UI widgets which aren't modified when new packages/options are added) * The debconf API allows fetching any option from the database and the values of these options are used to configure the actual software. Note: I tried to abstract away the properties, because I don't think the debconf *implementation* fits what we need. However, the model shows how very different packages can use a common framework for basic configuration, just like RPM shows how very different packages can use a common framework for installation. Having such a framework would allow a *standard* way of configuring a set of packages for specific roles. -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron I love deadlines, especially the whooshing sound they make as they go by. -- Douglas Adams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
New version of Copr
Hi, I just deployed new version of Copr. Changes: * copr-cli has been build for epel6 (no planned build for el5 due dependency on python-requests) * you should see less internal server errors. Especially when deleting tasks with multiple srpm * All packages produced by Copr now have as vendor Fedora Project COPR (username/project) * if you add new chroot to your project, you can easily resubmit missing builds from Monitor tab. * if you are logged in, then time in output respect your timezone which you have in FAS. * previously sometime yum repo was not updated after successful build - this has been fixed Enjoy: http://copr.fedoraproject.org/ Mirek Suchy -- 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: Drawing lessons from fatal SELinux bug #1054350
On Mon, 2014-01-27 at 15:11 -0700, Kevin Fenzi wrote: On Mon, 27 Jan 2014 10:18:56 -0500 Matthew Miller mat...@fedoraproject.org wrote: snip * possibly adding a what should users test? field to the update info. I know that there's a notes field in the update, but maybe it'd help to explicitly include testing instructions? Each package in the pkgdb (or in git, or wherever) could have a standard list included in each update as the default (for example, for 'calc', it might be to try `calc -q read /usr/share/calc/regress.cal`. That would duplicate a likely smoke-test, though, so maybe also run interactively and make sure basic math works. Then, each update could also optionally (and this would be presented in bold if it were used) say something like New release adds log() function; please test that it works, or Severe bug where 1+1=3 corrected; please test that the answer now corresponds with consensus reality. I could have sworn we already had something like this where bodhi would add a link to a wiki page for test plan on a package if that wiki page existed. I can't seem to find it now, so perhaps it was just something we talked about, but never implemented. Nope, you're right. :) https://github.com/fedora-infra/bodhi/blob/develop/bodhi/model.py#L191 For example, the test case pages for the package 'foo' need to be added to the 'Category:Package foo test cases' category. There's also an option in the config file which must be switched on for this to work: 'query_wiki_test_cases' And here is an update where this is, in fact, actually used: https://admin.fedoraproject.org/updates/FEDORA-2014-1465/ -- Mathieu -- 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: Drawing lessons from fatal SELinux bug #1054350
On Tue, 2014-01-28 at 10:39 +0800, Mathieu Bridon wrote: On Mon, 2014-01-27 at 15:11 -0700, Kevin Fenzi wrote: On Mon, 27 Jan 2014 10:18:56 -0500 Matthew Miller mat...@fedoraproject.org wrote: snip * possibly adding a what should users test? field to the update info. I know that there's a notes field in the update, but maybe it'd help to explicitly include testing instructions? Each package in the pkgdb (or in git, or wherever) could have a standard list included in each update as the default (for example, for 'calc', it might be to try `calc -q read /usr/share/calc/regress.cal`. That would duplicate a likely smoke-test, though, so maybe also run interactively and make sure basic math works. Then, each update could also optionally (and this would be presented in bold if it were used) say something like New release adds log() function; please test that it works, or Severe bug where 1+1=3 corrected; please test that the answer now corresponds with consensus reality. I could have sworn we already had something like this where bodhi would add a link to a wiki page for test plan on a package if that wiki page existed. I can't seem to find it now, so perhaps it was just something we talked about, but never implemented. Nope, you're right. :) https://github.com/fedora-infra/bodhi/blob/develop/bodhi/model.py#L191 For example, the test case pages for the package 'foo' need to be added to the 'Category:Package foo test cases' category. There's also an option in the config file which must be switched on for this to work: 'query_wiki_test_cases' And here is an update where this is, in fact, actually used: https://admin.fedoraproject.org/updates/FEDORA-2014-1465/ This is the package test plan thing - the QA docs on it are at https://fedoraproject.org/wiki/QA:SOP_package_test_plan_creation . I usually use xorg-x11-drv-nouveau updates as a handy example of it in action. You can create a test case for a package and add it to the category Category:Package_(packagename)_test_cases (where 'packagename' is the .src.rpm name), and it will show up in Bodhi like this. -- 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: New version of Copr
On Mon, Jan 27, 2014 at 5:12 PM, Miroslav Suchy msu...@redhat.com wrote: Hi, I just deployed new version of Copr. Changes: * copr-cli has been build for epel6 (no planned build for el5 due dependency on python-requests) * you should see less internal server errors. Especially when deleting tasks with multiple srpm * All packages produced by Copr now have as vendor Fedora Project COPR (username/project) * if you add new chroot to your project, you can easily resubmit missing builds from Monitor tab. * if you are logged in, then time in output respect your timezone which you have in FAS. * previously sometime yum repo was not updated after successful build - this has been fixed Thanks! Are there plans to add ARM? Enjoy: http://copr.fedoraproject.org/ Mirek Suchy -- 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: icecat or/and firefox?
On Mon, 2014-01-27 at 11:52 +, Ian Malone wrote: On 27 January 2014 05:36, Ralf Corsepius rc040...@freenet.de wrote: On 01/27/2014 05:08 AM, Christopher Meng wrote: Hi, Here is an interesting package icecat[1], which is a more free version firefox. I'd argue it's *less* free since it seeks to restrict what you can do: Congratulations! You are the millionth person to regurgitate this entirely fruitless argument on the internet. You win no prize. -- 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: icecat or/and firefox?
On Mon, 2014-01-27 at 22:48 -0800, Adam Williamson wrote: On Mon, 2014-01-27 at 11:52 +, Ian Malone wrote: On 27 January 2014 05:36, Ralf Corsepius rc040...@freenet.de wrote: On 01/27/2014 05:08 AM, Christopher Meng wrote: Hi, Here is an interesting package icecat[1], which is a more free version firefox. I'd argue it's *less* free since it seeks to restrict what you can do: Congratulations! You are the millionth person to regurgitate this entirely fruitless argument on the internet. You win no prize. I should note, I take no position. I just have seen enough instances of the permissive is more free! NO, copyleft is more free! argument for: a) today b) this week c) a lifetime d) the lifetime of the universe -- 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
[perl-File-Fetch] 0.46 bump
commit 2016014d90af6512c1d2ab5c93365e0b0213e454
Author: Petr Písař ppi...@redhat.com
Date: Mon Jan 27 13:37:05 2014 +0100
0.46 bump
perl-File-Fetch.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-File-Fetch.spec b/perl-File-Fetch.spec
index f6cf568..22436c0 100644
--- a/perl-File-Fetch.spec
+++ b/perl-File-Fetch.spec
@@ -1,5 +1,5 @@
Name: perl-File-Fetch
-Version:0.46
+Version:0.48
Release:1%{?dist}
Summary:Generic file fetching mechanism
License:GPL+ or Artistic
@@ -68,6 +68,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Jan 27 2014 Petr Pisar ppi...@redhat.com - 0.48-1
+- 0.48 bump
+
* Thu Nov 28 2013 Petr Pisar ppi...@redhat.com - 0.46-1
- 0.46 bump
--
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 1058005] perl-File-Fetch-0.48 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1058005 --- Comment #1 from Petr Pisar ppi...@redhat.com --- This release fixes tests on NetBSD. -- 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=2FcUT9msg9a=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 1058004] perl-Event-RPC-1.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1058004 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Event-RPC-1.04-1.fc21 -- 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=w9p2l0e72fa=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 1058004] perl-Event-RPC-1.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1058004 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-Event-RPC-1.04-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-Event-RPC-1.04-1.fc20 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=EXhL8ExJJQa=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-File-Fetch/f20] 0.46 bump
Summary of changes: 2016014... 0.46 bump (*) (*) 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
File File-Fetch-0.48.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-File-Fetch: 319dcd7886b3a51f54836915eecd7d53 File-Fetch-0.48.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-File-Fetch] Cache 0.48 sources
commit 5f13d11e8fb161e3640865738091bfe074459b08 Author: Petr Písař ppi...@redhat.com Date: Mon Jan 27 13:43:47 2014 +0100 Cache 0.48 sources .gitignore |1 + sources|2 +- 2 files changed, 2 insertions(+), 1 deletions(-) --- diff --git a/.gitignore b/.gitignore index 2b6c199..bdab2d7 100644 --- a/.gitignore +++ b/.gitignore @@ -3,3 +3,4 @@ File-Fetch-0.14.tar.gz /File-Fetch-0.42.tar.gz /File-Fetch-0.44.tar.gz /File-Fetch-0.46.tar.gz +/File-Fetch-0.48.tar.gz diff --git a/sources b/sources index 1dda9bc..0251513 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -f0e74b2f7da5105c42d699a845cde1b1 File-Fetch-0.46.tar.gz +319dcd7886b3a51f54836915eecd7d53 File-Fetch-0.48.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-File-Fetch/f20] Cache 0.48 sources
Summary of changes: 5f13d11... Cache 0.48 sources (*) (*) 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
File Module-Load-0.30.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Module-Load: 828060b6c19f63f474957cf54bd46c68 Module-Load-0.30.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-Module-Load] 0.30 bump
commit ca82bcad09c6f3961f86313fd46eca8ab968572f
Author: Petr Písař ppi...@redhat.com
Date: Mon Jan 27 13:50:41 2014 +0100
0.30 bump
.gitignore|1 +
perl-Module-Load.spec |6 +-
sources |2 +-
3 files changed, 7 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 742fc15..b10a959 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
Module-Load-0.12.tar.gz
/Module-Load-0.24.tar.gz
/Module-Load-0.28.tar.gz
+/Module-Load-0.30.tar.gz
diff --git a/perl-Module-Load.spec b/perl-Module-Load.spec
index 8310961..f3c4e02 100644
--- a/perl-Module-Load.spec
+++ b/perl-Module-Load.spec
@@ -1,7 +1,7 @@
Name: perl-Module-Load
# Epoch to compete with perl.spec
Epoch: 1
-Version:0.28
+Version:0.30
Release:1%{?dist}
Summary:Run-time require of both modules and files
License:GPL+ or Artistic
@@ -14,6 +14,7 @@ BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(strict)
# Run-time:
BuildRequires: perl(File::Spec)
+BuildRequires: perl(warnings)
# Tests:
BuildRequires: perl(Exporter)
BuildRequires: perl(lib)
@@ -54,6 +55,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Jan 27 2014 Petr Pisar ppi...@redhat.com - 1:0.30-1
+- 0.30 bump
+
* Tue Jan 07 2014 Petr Pisar ppi...@redhat.com - 1:0.28-1
- 0.28 bump
diff --git a/sources b/sources
index 001c9e2..78f4a0d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-93164909fa15c61d26c03f930ef345e6 Module-Load-0.28.tar.gz
+828060b6c19f63f474957cf54bd46c68 Module-Load-0.30.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 1058005] perl-File-Fetch-0.48 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1058005 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-File-Fetch-0.48-1.fc21 -- 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=BPxftnJRhSa=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 1058005] perl-File-Fetch-0.48 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1058005 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-File-Fetch-0.48-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-File-Fetch-0.48-1.fc20 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=a23QVEt9q9a=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 Module-Load-Conditional-0.62.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Module-Load-Conditional: 93481bb58cb008b235825cb9bcee89da Module-Load-Conditional-0.62.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 1058006] perl-Module-Load-0.30 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1058006 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Module-Load-0.30-1.fc2 ||1 Resolution|--- |RAWHIDE Last Closed||2014-01-27 08:04:05 -- 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=KJu8xHoTYha=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-Module-Load-Conditional] 0.62 bump
commit 8b33df4568b943e7ef53f04dad32813187c8603a
Author: Petr Písař ppi...@redhat.com
Date: Mon Jan 27 14:02:25 2014 +0100
0.62 bump
.gitignore|1 +
perl-Module-Load-Conditional.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 5fb1a90..da16c12 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ Module-Load-Conditional-0.24.tar.gz
/Module-Load-Conditional-0.54.tar.gz
/Module-Load-Conditional-0.58.tar.gz
/Module-Load-Conditional-0.60.tar.gz
+/Module-Load-Conditional-0.62.tar.gz
diff --git a/perl-Module-Load-Conditional.spec
b/perl-Module-Load-Conditional.spec
index 826a787..e92d4d0 100644
--- a/perl-Module-Load-Conditional.spec
+++ b/perl-Module-Load-Conditional.spec
@@ -1,5 +1,5 @@
Name: perl-Module-Load-Conditional
-Version:0.60
+Version:0.62
Release:1%{?dist}
Summary:Looking up module information and loading at run-time
License:GPL+ or Artistic
@@ -63,6 +63,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Jan 27 2014 Petr Pisar ppi...@redhat.com - 0.62-1
+- 0.62 bump
+
* Mon Jan 20 2014 Petr Pisar ppi...@redhat.com - 0.60-1
- 0.60 bump
diff --git a/sources b/sources
index ffad76d..7a068ca 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-1e0ad0077241c32eba7af9cb7c443dc8 Module-Load-Conditional-0.60.tar.gz
+93481bb58cb008b235825cb9bcee89da Module-Load-Conditional-0.62.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 1033514] Retire perl-Class-Accessor in EPEL6
https://bugzilla.redhat.com/show_bug.cgi?id=1033514 --- Comment #3 from Jon Ciesla limburg...@gmail.com --- Should be handled in rel-eng ticket and pkgdb. -- 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=4lbilXslIwa=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 1033514] Retire perl-Class-Accessor in EPEL6
https://bugzilla.redhat.com/show_bug.cgi?id=1033514 Jon Ciesla limburg...@gmail.com changed: What|Removed |Added Flags|fedora-cvs? | -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=RL6EBRQw9va=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 1033515] Retire perl-Class-Data-Inheritable in EPEL6
https://bugzilla.redhat.com/show_bug.cgi?id=1033515 --- Comment #3 from Jon Ciesla limburg...@gmail.com --- Should be handled in rel-eng ticket and pkgdb. -- 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=CbVG5LdswQa=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 1033515] Retire perl-Class-Data-Inheritable in EPEL6
https://bugzilla.redhat.com/show_bug.cgi?id=1033515 Jon Ciesla limburg...@gmail.com changed: What|Removed |Added Flags|fedora-cvs? | -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Jk4lCR9tLDa=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 1058007] perl-Module-Load-Conditional-0.62 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1058007 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Module-Load-Conditiona ||l-0.62-1.fc21 Resolution|--- |RAWHIDE Last Closed||2014-01-27 08:29:35 -- 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=m9kLwvDdkba=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-File-MMagic] Created tag perl-File-MMagic-1.30-1.el7
The lightweight tag 'perl-File-MMagic-1.30-1.el7' was created pointing to: 2e64dea... 1.30 bump -- 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-Module-Find] Created tag perl-Module-Find-0.11-5.el7
The lightweight tag 'perl-Module-Find-0.11-5.el7' was created pointing to: 66e874d... - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Text-Haml/f19] Initial import
Summary of changes: 5a1164e... Initial import (*) (*) 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-Text-Haml/f20] Initial import
Summary of changes: 5a1164e... Initial import (*) (*) 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
