Re: F21 System Wide Change: BerkeleyDB 6
Dne 23.4.2014 20:23, Miloslav Trmač napsal(a): Hello, 2014-04-11 13:18 GMT+02:00 Jaroslav Reznik jrez...@redhat.com: = Proposed System Wide Change: BerkeleyDB 6 = https://fedoraproject.org/wiki/Changes/BerkeleyDB_6 At the FESCo meeting, we were unclear what happens to packages that don't get updated; will they sty at v5, or will they (immediately, or after a possible mass rebuild) start using v6? FESCo would prefer a transition plan in which we don't risk violating licenses by omission (e.g. requiring an active maintainer's action to move a package to v6, or having somebody sign up to verify all packages in case the owners forgot). Mirek Well, in the current plan (make libdb5 compat package and updating the libdb to v6), after the mass rebuild the packages would start using v6. We could do it other way around (keep libdb in v5 and make libdb6 package), but this approach invites future problems with consecutive versions (v7, v8 probably should not be packaged in libdb*6*). Using another naming scheme would take care of part of the problem. I would actually prefer somebody to verify all packages that Require libdb and work with maintainers of said packages to eventually update their requires. If no one signes up to this, I will do it as part of the change (but even the I could use some help). If this proposal seems good to you, I will update the wiki page to reflect the agreement. Regards, Jan -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team -- 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: Summary of accepted Fedora 21 Changes - weeks 13/14
On 2014-04-24, Kay Sievers k...@vrfy.org wrote: On Tue, Apr 8, 2014 at 10:35 AM, Petr Pisar ppi...@redhat.com wrote: What about D-Bus? D-Bus uses AF_UNIX currently. But as you can know, there is an aim to move D-Bus to a new protocol family. Is it possible that all the daemons with a D-Bus control interface will stop work then? If you mean kdbus, it is not related to network, it is based on character devices. I do. Then it's not affected. Thanks for the details. -- Petr -- 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: The Forgotten F: A Tale of Fedora's Foundations
Well my point is I spoke to Red Hat legal before I even posted the original proposal to open up to more 3rd party repositories some Months ago. There are a lot of repositories that it is perfectly fine for Fedora to include from a legal perspective. But they will need to be reviewed by legal on a case to case basis, going to legal up front and saying 'hey can I include a hypothetical repository' will only yield you the answer 'depends on the repository'. So decisions need to be general to allow us to look for a variety of options to fulfill them. Lets say Fedora decided we want to make it easier for our users to get more multimedia codecs. We would not get the go ahead from legal to include a repository which contains ffmpeg for instance, but legal would probably be perfectly fine with including a repository containing the Cisco H264 package or the Fluendo Mp3 plugin. So in the end this is not a legal question which needs the involvement of the lawyers at this point, but a question of the overall goals and values of Fedora, and how we best achieve those goals and values. Basically we first need to agree on the 'design' before distracting ourselves with 'implementation'. Christian - Original Message - From: drago01 drag...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Wednesday, April 23, 2014 4:37:40 PM Subject: Re: The Forgotten F: A Tale of Fedora's Foundations On Wed, Apr 23, 2014 at 4:24 PM, Stephen John Smoogen smo...@gmail.com wrote: On 23 April 2014 02:29, Christian Schaller cscha...@redhat.com wrote: Hi Mairin, Not sure exactly where you are coming from in terms of wanting legal to weigh in, but in general I don't think legals opinion is very relevant and this point. The first step here should always be us as a project deciding what user experience we want to offer our users, then once that is done go to legal and try to work with them to figure out how it can be done. The reason was that Legal was the big reason the rules are in place in the first place. They are not just in place because of software patents. They are in place because of different national laws on copyright, what is considered to be infringement or redistribution by even linking, trademark use (also dependent on nation etc), competition rules, and a probably another dozen other factors. All of this applies to any software regardless whether it is free or not (as I said in the other mail). Copyright law does not differentiate between free and non free software. -- 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
Copr and Playground plugin part of dnf-plugins-core?
In https://bugzilla.redhat.com/show_bug.cgi?id=1090516 Jiri asked for removing Copr (and Playground) DNF plugin out of dnf-plugins-core. Since this is not technical but merely political question I would like to ask wider audience: Put your voice here please: http://www.easypolls.net/poll.html?p=5358d77de4b06a67c5b08e05 If there will be significant votes for one option, I would do what most of you wish. Otherwise I will forward it to Fesco for decision. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The Forgotten F: A Tale of Fedora's Foundations
On 4/24/14, Christian Schaller cscha...@redhat.com wrote: So decisions need to be general to allow us to look for a variety of options to fulfill them. Lets say Fedora decided we want to make it easier for our users to get more multimedia codecs. We would not get the go ahead from legal to include a repository which contains ffmpeg for instance, but legal would probably be perfectly fine with including a repository containing the Cisco H264 package or the Fluendo Mp3 plugin. Which, long story short, isn't really what users want (they want all that codecs). So in the end this is not a legal question which needs the involvement of the lawyers at this point, but a question of the overall goals and values of Fedora, and how we best achieve those goals and values. Basically we first need to agree on the 'design' before distracting ourselves with 'implementation'. Agreed. And as far as I can see, the current design with the Fedora core repos + rpmfusion + COPR add-ons is a good design, given that US law is applicable to core Fedora and COPR. That said, these add-ons should IMHO be a fundamental part of the vision. To lijmit our thought to a user with just Fedora repos is, well, to limit our thoughts. Let's recognize the fact that users have needs which in many cases will make them use additional repos. We do provide a lot of hooks for this, but could be better. Partly, it's a question how we present things. Personally, I think Fedora core repos + rpmfusion should be a one-stop shop for most things. There's some work to be done on the rpmfusion side to for this, though. -- 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: When a yum update sets up an MTA ...
On 04/24/2014 01:57 AM, Andrew Lutomirski wrote: On Mon, Apr 21, 2014 at 12:17 AM, Florian Weimer fwei...@redhat.com wrote: On 04/21/2014 03:44 AM, Andrew Lutomirski wrote: Would it make sense to audit all spec files to look for instances of 'systemctl.*enable'? I'm attaching the hits for that pattern on the actual RPM scripts in Fedora rawhide (x86_64). This combines both regular scripts and trigger scripts. I can add additional columns with more information, but the text file will become a bit unwieldy. Can you double-check this? nfs-utils isn't in this list, but I think it should be. I accidentally used systemd.*enable as the pattern. The attached list was created using systemctl[^\n]*enable instead. Also, how did you generate this? I've got a tool which extracts interesting data from RPMs (metadata, but also Java method references, ELF symbols, Python imports). I've added the query I used as an example here: https://github.com/fweimer/symboldb/blob/master/doc/examples/rpm-scripts.txt -- Florian Weimer / Red Hat Product Security Team script.txt.gz Description: application/gzip -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Self Introduction : Marianne Lombard
Hi, I'm writing today because I have submitted my first package for review : https://bugzilla.redhat.com/show_bug.cgi?id=1090933 I'm a sysadmin since a few years in a public research center and we are using (a lot) of free and open-source software. So I will probably work on sysadmin / scientific tools. I will need a sponsor and I hope to find someone soon (probably a french like me because my english is not perfect) Marianne -- Marianne (Jehane) Lombard Geekfeminist and sysadmin -- 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: Self Introduction : Marianne Lombard
Heya ! Welcome here and I'm glad that you finally jumped onboard :) Feel free to ping me if you're looking for a sponsor. best regards, H. -- 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: Self Introduction : Marianne Lombard
Hi, All this time I thought you were already maintaining packages :) Cheers, Dridi On Thu, Apr 24, 2014 at 2:20 PM, Marianne Lombard maria...@tuxette.fr wrote: Hi, I'm writing today because I have submitted my first package for review : https://bugzilla.redhat.com/show_bug.cgi?id=1090933 I'm a sysadmin since a few years in a public research center and we are using (a lot) of free and open-source software. So I will probably work on sysadmin / scientific tools. I will need a sponsor and I hope to find someone soon (probably a french like me because my english is not perfect) Marianne -- Marianne (Jehane) Lombard Geekfeminist and sysadmin -- 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
Orphaning most of my packages
I am doing spring cleanup and getting rid of most of my packages. The full list is a bit too long (mizdebsk agreed to take over all of my Maven related packages as primary maintainer). Here's the remaining bits that need a new home: * plotutils * python-gudev * python-icalendar * python-webdav-library * freemind -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com pgpos11L87hEO.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Orphaning most of my packages
On Thu, Apr 24, 2014 at 7:46 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: I am doing spring cleanup and getting rid of most of my packages. The full list is a bit too long (mizdebsk agreed to take over all of my Maven related packages as primary maintainer). Here's the remaining bits that need a new home: * plotutils * python-gudev * python-icalendar I'll take python-icalendar, I need it for timeline. Thanks, J * python-webdav-library * freemind -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- 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: Orphaning most of my packages
On Thu, Apr 24, 2014 at 2:49 PM, Jon Ciesla limburg...@gmail.com wrote: On Thu, Apr 24, 2014 at 7:46 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: I am doing spring cleanup and getting rid of most of my packages. The full list is a bit too long (mizdebsk agreed to take over all of my Maven related packages as primary maintainer). Here's the remaining bits that need a new home: * plotutils * python-gudev * python-icalendar I'll take python-icalendar, I need it for timeline. Thanks, J * python-webdav-library * freemind freemind would need some considerable amount of work, because it's already several versions behind upstream. It's sad to see, but it's hard to package java stuff. I think best would be to either update it or just retire it properly, although a lot of my work might be lost. Johannes -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- 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: Orphaning most of my packages
- Original Message - From: Johannes Lips johannes.l...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, April 24, 2014 2:55:09 PM Subject: Re: Orphaning most of my packages On Thu, Apr 24, 2014 at 2:49 PM, Jon Ciesla limburg...@gmail.com wrote: On Thu, Apr 24, 2014 at 7:46 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: I am doing spring cleanup and getting rid of most of my packages. The full list is a bit too long (mizdebsk agreed to take over all of my Maven related packages as primary maintainer). Here's the remaining bits that need a new home: * plotutils * python-gudev * python-icalendar I'll take python-icalendar, I need it for timeline. Thanks, J * python-webdav-library * freemind freemind would need some considerable amount of work, because it's already several versions behind upstream. It's sad to see, but it's hard to package java stuff. I think best would be to either update it or just retire it properly, although a lot of my work might be lost. I'm taking freemind and will try to update it Johannes -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- 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 -- 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: Orphaning most of my packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/24/2014 02:46 PM, Stanislav Ochotnicky wrote: I am doing spring cleanup and getting rid of most of my packages. The full list is a bit too long (mizdebsk agreed to take over all of my Maven related packages as primary maintainer). Here's the remaining bits that need a new home: * plotutils * python-gudev * python-icalendar * python-webdav-library * freemind plotutils releases seems suspended since 2009. - -- 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/ iQIcBAEBAgAGBQJTWQp1AAoJED2vIvfUANbEJe4P/3rd3sSqaSYlNMZfN3plecEf WkauKvUCTBQQpkwV4zcKLk8cDWKtaSe/gr+M2CoHfXKS9N/c6lWKfrONV/GpoB/9 g+cH7lUddEfFS+v2EVklCGIuPxBU1diXP09kq5ucjc0EKU0BLbr73jbCOrKazQ4q 372YLhSSR2ragrrXtis5TbCGMCzMQYzsZfpF2/bgG3889LDN9x3bl4b67afPvH7W X5Ee6HCgSrows9ZiSYPUvEpKX9rKGYA57CGuxP5znB+2jgqXXYmjTxA+dXxE1Y7V zE6DtCR5yhhAdn9OKQy3gzeI7jLHU+lU7b56ZmhZqyeXLQVmEy7UYLcWMQbXky/j JhTD5YJWtQ/DiujSyD6ZFdiNM3cer4agz1u7oFyRwepKIKZwA4wRpTgscXFw2uvW CIc1N/lUQZZQ05ypEmb6w+p32tyA7mp5rjZRUN5f1QoEtyB1wy3RN0OJMHxLFEo+ fuJ45dnMeLgl3D1ZcIUYZuf0vVoWu/YFRTwKV1dkfr0SKbfknmB2fwc4H3pwyJLG DmbTSabfBjk9nUzOvjaRILYqv38hqR7kzWDrL9lI1sFgsQtW1JQq8TdKX/N7Ml0o KBCqRIgalkHYvzfNrYkMqbDYE0qycp+qVIcVB+IIUvKbSkGAjmBNaGHSs2UD3oa6 cL0rJySwFrKBGPt2fekV =HCzm -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: Orphaning most of my packages
On Thu, 2014-04-24 at 14:46 +0200, Stanislav Ochotnicky wrote: I am doing spring cleanup and getting rid of most of my packages. The full list is a bit too long (mizdebsk agreed to take over all of my Maven related packages as primary maintainer). Here's the remaining bits that need a new home: * python-gudev Isn't that obsoleted by the GObject-Introspection bindings? from gi.repository import GUdev -- 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
Automatically generated configuration files
I'm working on advice on automated X.509 certificate generation during package installation. One aspect is that these files obviously have to be generated on the system during installation (or first service start) and cannot be shipped in the package. Some existing RPMs just drop files into /etc/pki/certs and /etc/pki/tls/private, without marking them as ghost files or configuration files. (I'm not even sure if you can mark something for which no content is provided in the RPM as a configuration file.) I wonder what an ideal RPM package would do in this case? -- Florian Weimer / Red Hat Product Security Team -- 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: Maybe it's time to get rid of tcpwrappers/tcpd?
On Thu, 20.03.14 18:34, Lennart Poettering (mzerq...@0pointer.de) wrote: Heya! I wonder whether it wouldn't be time to say goodbye to tcpwrappers in Fedora. There has been a request in systemd upstream to disable support for it by default, but I am not sure I want to do that unless we can maybe say goodbye to it for the big picture too. To add to this old thread: OpenSSH has now also decided to drop tcpwrap. https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-April/032497.html Some of the posts in this thread are actually quite entertaining. For example, the first call of hosts_access() is setjmp(), which is just beautiful... We probably should make setjmp()-freeness a requirement for all code included in Fedora. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-MouseX-ConfigFromFile] Created tag perl-MouseX-ConfigFromFile-0.05-3.fc20
The lightweight tag 'perl-MouseX-ConfigFromFile-0.05-3.fc20' was created pointing to: 86c1077... Initial import (perl-MouseX-ConfigFromFile-0.05-3) -- 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-MouseX-ConfigFromFile] Created tag perl-MouseX-ConfigFromFile-0.05-3.el7
The lightweight tag 'perl-MouseX-ConfigFromFile-0.05-3.el7' was created pointing to: 86c1077... Initial import (perl-MouseX-ConfigFromFile-0.05-3) -- 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-MouseX-ConfigFromFile] Created tag perl-MouseX-ConfigFromFile-0.05-3.fc19
The lightweight tag 'perl-MouseX-ConfigFromFile-0.05-3.fc19' was created pointing to: 86c1077... Initial import (perl-MouseX-ConfigFromFile-0.05-3) -- 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-MouseX-ConfigFromFile] Created tag perl-MouseX-ConfigFromFile-0.05-3.fc21
The lightweight tag 'perl-MouseX-ConfigFromFile-0.05-3.fc21' was created pointing to: 86c1077... Initial import (perl-MouseX-ConfigFromFile-0.05-3) -- 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: Automatically generated configuration files
On Thu, 24 Apr 2014, Florian Weimer wrote: I'm working on advice on automated X.509 certificate generation during package installation. I would strongly recommend doing it on first service start. I've lived through the FreeS/WAN times and my experience with it for 15+ years caused us (in libreswan) to completely refrain from geenrating raw RSA keys or certificates. (But we don't need to do OE/anon TLS) Entropy was always a big issue. Even doing it automatically on first service start was problematic, as people would regularly kill processes of the service because it took too long. One big mistake we made back in those days was that the process was not atomic, so the file listing the available keys would be half written and corrupt. One aspect is that these files obviously have to be generated on the system during installation (or first service start) and cannot be shipped in the package. Some existing RPMs just drop files into /etc/pki/certs and /etc/pki/tls/private, without marking them as ghost files or configuration files. (I'm not even sure if you can mark something for which no content is provided in the RPM as a configuration file.) Those are global locations, right? While certs could go there, CAcerts should not just be dropped in there - especially not self-signed ones. I wonder what an ideal RPM package would do in this case? How many packages would actually perform any kind of opportunistic encryption? I know the mail servers prefer a selfsigned cert over no cert whatsoever, but what other applications have this issue of better unknown certificate than plaintext ? For example, I dont think a jabber server package should generate and use a self-signed cert. Paul (sorry, not really know the answer to your rpm question) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[RFC] plans for initscripts in F22
Hi, for the F22 I am planning some bigger changes regarding initscripts and I would like to ask for comments. Initscripts package was in the past a crucial part of the system. They basicaly set up whole system during the boot. Currently initscripts package contains support for initscripts (/etc/init.d/function, service command), network initscripts and tons of leftovers. So my plan is following: We must keep initscripts support, but I can imagine a setup where every service uses a systemd unit, so this part does not have to be installed by default, but could be pulled in as a dependency. Network initscript. This will be probably the most controversial part. In fedora 21 we will have three different tools for networking (initscripts, NetworkManager and systemd-networkd) and all of them will be installed by default. For various design reasons network initscripts does not have any future (it is completely synchronous and does not work with parallel boot very well). So I would like to split it in its own package and drop it in the future. For most of the use-cases NM is sufficient replacement and if somebody will miss a static configuration we are planning to replace network initscript functionality in networkd. Than there are scripts and configs like /etc/crypttab /etc/inittab /etc/profile.d/256term.sh /usr/lib/systemd/fedora-autorelabel /usr/bin/ipcalc /usr/bin/usleep /usr/sbin/consoletype /usr/sbin/genhostid /usr/sbin/sushell /var/log/btmp /var/log/wtmp I would like to find a new better home for them. So I am suggesting to start with splitting initscripts to these sub-packages. initscripts - initscripts support initscripts-core (looking for better name) - the leftovers which needs to by installed by default for now, but we will move everything from it to different components initscripts-network - network initscript initscripts-readonly - support for readonly root should be redesigned completelly initscripts-doc initscripts-locale initscripts-man For more details please see the new spec file: http://lnykryn.fedorapeople.org/initscripts/10/initscripts.spec And here is a test package and copr build: http://lnykryn.fedorapeople.org/initscripts/10/ http://copr.fedoraproject.org/coprs/lnykryn/Initscripts-10/builds/ Regards Lukas -- 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: Automatically generated configuration files
On Thu, 2014-04-24 at 15:47 +0200, Florian Weimer wrote: I'm working on advice on automated X.509 certificate generation during package installation. One aspect is that these files obviously have to be generated on the system during installation (or first service start) and cannot be shipped in the package. Some existing RPMs just drop files into /etc/pki/certs and /etc/pki/tls/private, without marking them as ghost files or configuration files. (I'm not even sure if you can mark something for which no content is provided in the RPM as a configuration file.) I wonder what an ideal RPM package would do in this case? If you know what service is going to require the cert, you might copy the pattern from openssh, where sshd-keygen.service runs as a prereq for sshd itself. - 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: Orphaning most of my packages
On 04/24/2014 02:57 PM, Michael Simacek wrote: - Original Message - From: Johannes Lips johannes.l...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, April 24, 2014 2:55:09 PM Subject: Re: Orphaning most of my packages freemind would need some considerable amount of work, because it's already several versions behind upstream. It's sad to see, but it's hard to package java stuff. I think best would be to either update it or just retire it properly, although a lot of my work might be lost. I'm taking freemind and will try to update it Great! I've been using freemind-1.0.0-RC2 from Johannes' repo and I haven't seen any problems. https://lists.fedoraproject.org/pipermail/devel/2013-March/180613.html -- Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: BerkeleyDB 6
On Thu, 24 Apr 2014 09:31:43 +0200 Jan Staněk jsta...@redhat.com wrote: Well, in the current plan (make libdb5 compat package and updating the libdb to v6), after the mass rebuild the packages would start using v6. Yeah, which makes technical sense... but the concern is packagers who aren't paying attention rebuild for some other reason and are not on v6 when it's a licensing problem. ;( We could do it other way around (keep libdb in v5 and make libdb6 package), but this approach invites future problems with consecutive versions (v7, v8 probably should not be packaged in libdb*6*). Using another naming scheme would take care of part of the problem. Right. I would actually prefer somebody to verify all packages that Require libdb and work with maintainers of said packages to eventually update their requires. If no one signes up to this, I will do it as part of the change (but even the I could use some help). Yeah. This could be tracked with a tracker bug and bugs against the remaining packages I guess. If this proposal seems good to you, I will update the wiki page to reflect the agreement. Yeah, seems fine to me... 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: Automatically generated configuration files
Paul Wouters p...@nohats.ca writes: [...] How many packages would actually perform any kind of opportunistic encryption? I know the mail servers prefer a selfsigned cert over no cert whatsoever, but what other applications have this issue of better unknown certificate than plaintext ? Probably all that listen on ssl/tls-capable sockets. (stap-server pcp happen to be ones freshly in mind). In the absence of network-layer opportunistic encryption, it's the best we can do. - FChE -- 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: Automatically generated configuration files
On 04/24/2014 04:20 PM, Paul Wouters wrote: On Thu, 24 Apr 2014, Florian Weimer wrote: I'm working on advice on automated X.509 certificate generation during package installation. I would strongly recommend doing it on first service start. I've lived through the FreeS/WAN times and my experience with it for 15+ years caused us (in libreswan) to completely refrain from geenrating raw RSA keys or certificates. (But we don't need to do OE/anon TLS) I don't think openssl genrsa 2048 has this issue on today's machines. (I know I saw it with GNUTLS.) One aspect is that these files obviously have to be generated on the system during installation (or first service start) and cannot be shipped in the package. Some existing RPMs just drop files into /etc/pki/certs and /etc/pki/tls/private, without marking them as ghost files or configuration files. (I'm not even sure if you can mark something for which no content is provided in the RPM as a configuration file.) Those are global locations, right? While certs could go there, CAcerts should not just be dropped in there - especially not self-signed ones. It would be a self-signed non-CA certificate. A package-specific directory would work as well. I wonder what an ideal RPM package would do in this case? How many packages would actually perform any kind of opportunistic encryption? I know the mail servers prefer a selfsigned cert over no cert whatsoever, but what other applications have this issue of better unknown certificate than plaintext ? It came up in the context of clustering software where the single certificate/key pair (shared across the cluster) would be used to secure cluster membership. The cluster nodes trust each other as a result of the protocol features, so they could access their private keys anyway, even if they were separate. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Mass bug: packages should not auto-enable systemd units
Hi everyone- This is a notice in accordance with the mass bug filing procedure. A number of packages install systemd units and enable them automatically. They should not. Please update these packages to use the macroized scriptlet (https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd). If your package has an exception from FESCo permitting it to enable itself, please make sure that the service in question is listed in the appropriate preset file. There is a general exception described here: https://fedoraproject.org/wiki/Starting_services_by_default If your package falls under the general exception, then it is possible that no change is required. Nevertheless, if you are relying on the exception, please make sure that your rpm scripts are sensible. The exception is: In addition, any service which does not remain persistent on the system (aka, it runs once then goes away), does not listen to incoming connections during initialization, and does not require configuration to be functional may be enabled by default (but is not required to do so). An example of runs once then goes away service is iptables. Given that this issue can affect Fedora 20 users who install your package as a dependency, these bugs should be fixed in Fedora 20 and Rawhide. The tracker bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=1090684 I created it early because three of the bugs are pre-existing. Next week, I'll file bugs against the packages below. If you fix your package in the mean time, please let me know. After three weeks, provenpackagers may step in and fix these issues. OpenIPMI at avahi avahi-dnsconfd bcfg2 bcfg2-server bwbar cronie deltacloud-core device-mapper-multipath dmapd fsniper gpm groonga hsqldb iscsi-initiator-utils jabberd libvirt libvirt-client lvm2 mailman mdadm monit openct opendkim openssh-server partimage rhnsd rinetd sendmail vdsm xrdp yum-updatesd It's possible that I'm missing some packages. I may follow up with an updated list. ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The Forgotten F: A Tale of Fedora's Foundations
On 24 April 2014 02:49, Christian Schaller cscha...@redhat.com wrote: Well my point is I spoke to Red Hat legal before I even posted the original proposal to open up to more 3rd party repositories some Months ago. There are a lot of repositories that it is perfectly fine for Fedora to include from a legal perspective. But they will need to be reviewed by legal on a case to case basis, going to legal up front and saying 'hey can I include a hypothetical repository' will only yield you the answer 'depends on the repository'. OK cool. What is the plan for when repositories change what they are carrying and add stuff that may be legal for them but not for others? Will there be periodic reviews to make sure that this hasn't happened or some way that we roll back what repositories we recommend? -- 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: F21 System Wide Change: BerkeleyDB 6
On Thu, Apr 24, 2014 at 8:50 AM, Kevin Fenzi ke...@scrye.com wrote: Yeah, which makes technical sense... but the concern is packagers who aren't paying attention rebuild for some other reason and are not on v6 when it's a licensing problem. ;( I need some advice on how to handle this for XEmacs, which is a GPLv3+ package. It provides some optional database functionality, but the underlying database can be any of libdb, gdbm, or postgresql. When I first turned this on for Fedora, in response to a request in bz 581614, I chose libdb for reasons that I no longer remember. So now I need to choose between: - libdb (going to AGPLv3+) - gdbm (GPLv3+) - postgresql (PostgreSQL, essentially MIT) Does the fact that multiple database implementations can be used mean that the coupling is loose enough that the libdb license won't taint XEmacs proper? If not, then I would rather migrate away from libdb than deal with the possible licensing consequences. But then I have to deal with user databases that are already in libdb format, and hence cannot be read by the new XEmacs build using gdbm or postgresql. That's the part I don't know how to handle. Do I provide some automated migration capability? I suspect that won't ever work properly, because I don't have any way to discover where all such possible databases are located. Do I put up big warning signs somewhere that say: You must convert all of your XEmacs databases before updating to Fedora 21, and here is a recipe to do so? (And, to be honest, I have no idea what that recipe would be.) Thanks in advance for any advice. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Automatically generated configuration files
On Thu, 24 Apr 2014, Florian Weimer wrote: I don't think openssl genrsa 2048 has this issue on today's machines. (I know I saw it with GNUTLS.) I was sceptical, so I tried this on a freshly booted VM: root@bofh:~# virsh start north Domain north started root@bofh:~# ssh root@north Last login: Wed Apr 23 11:54:46 2014 [root@north ~]# time openssl genrsa 2048 [...] real0m0.382s user0m0.267s sys 0m0.003s Call me very surprised! We finally have real entropy in VMs now. Good news! It came up in the context of clustering software where the single certificate/key pair (shared across the cluster) would be used to secure cluster membership. The cluster nodes trust each other as a result of the protocol features, so they could access their private keys anyway, even if they were separate. Ah.. understood. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: BerkeleyDB 6
2014-04-24 17:22 GMT+02:00 Jerry James loganje...@gmail.com: On Thu, Apr 24, 2014 at 8:50 AM, Kevin Fenzi ke...@scrye.com wrote: Yeah, which makes technical sense... but the concern is packagers who aren't paying attention rebuild for some other reason and are not on v6 when it's a licensing problem. ;( I need some advice on how to handle this for XEmacs, which is a GPLv3+ package. It provides some optional database functionality, but the underlying database can be any of libdb, gdbm, or postgresql. When I first turned this on for Fedora, in response to a request in bz 581614, I chose libdb for reasons that I no longer remember. So now I need to choose between: - libdb (going to AGPLv3+) - gdbm (GPLv3+) - postgresql (PostgreSQL, essentially MIT) You'll have the option of moving to libdb5 , without a license change or need to convert data. That should be easiest, at least in the medium term while libdb5 is actively maintained. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: BerkeleyDB 6
On Thu, Apr 24, 2014 at 9:39 AM, Miloslav Trmač m...@volny.cz wrote: You'll have the option of moving to libdb5 , without a license change or need to convert data. That should be easiest, at least in the medium term while libdb5 is actively maintained. Sure, but long term I still have the same problem, so I might as well suffer through the pain now and be done with it. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The Forgotten F: A Tale of Fedora's Foundations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/24/2014 11:01 AM, Stephen John Smoogen wrote: On 24 April 2014 02:49, Christian Schaller cscha...@redhat.com mailto:cscha...@redhat.com wrote: Well my point is I spoke to Red Hat legal before I even posted the original proposal to open up to more 3rd party repositories some Months ago. There are a lot of repositories that it is perfectly fine for Fedora to include from a legal perspective. But they will need to be reviewed by legal on a case to case basis, going to legal up front and saying 'hey can I include a hypothetical repository' will only yield you the answer 'depends on the repository'. OK cool. What is the plan for when repositories change what they are carrying and add stuff that may be legal for them but not for others? Will there be periodic reviews to make sure that this hasn't happened or some way that we roll back what repositories we recommend? At the risk of being glib: What's the plan for periodically re-reviewing every package in Fedora to make sure that its sources always remain legal? It's the same problem and it can only realistically be dealt with by If someone notices, deal with it then. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNZNCwACgkQeiVVYja6o6O76gCcC/QdnvusmdalnbqV/X2Bftw/ 8L4AoKtkgQGO4EhVGNlfXhgWe6GDgpBd =Gx5v -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] plans for initscripts in F22
Hello, 2014-04-24 16:38 GMT+02:00 Lukáš Nykrýn lnyk...@redhat.com: We must keep initscripts support, but I can imagine a setup where every service uses a systemd unit, so this part does not have to be installed by default, but could be pulled in as a dependency. Are you sure? If you take an existing RPM that ships a sysv file, that's alone an indication that it probably hasn't been significantly reworked, so noone is likely to have added an explicit requires: on this part. For extra credit, make sure that this works correctly with LSB-compliant RPMs that do nothing not required by LSB. It might be solvable, or you might have already solved this and tested this; but if not, it seems much simpler to me to just keep the few files in a package installed by default and not worry about the 13 kilobytes or whatever it is. So I am suggesting to start with splitting initscripts to these sub-packages. This seems to me to be going into the direction of too many sub-packages (and thus too much packaging effort), but if it's you doing the work it's really up to you. (Note that splitting the packages that finely may not even be saving disk space, when you count the size of the extra RPM headers and indexes, and yumdb.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The Forgotten F: A Tale of Fedora's Foundations
On Thu, Apr 24, 2014 at 11:56 AM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/24/2014 11:01 AM, Stephen John Smoogen wrote: On 24 April 2014 02:49, Christian Schaller cscha...@redhat.com mailto:cscha...@redhat.com wrote: Well my point is I spoke to Red Hat legal before I even posted the original proposal to open up to more 3rd party repositories some Months ago. There are a lot of repositories that it is perfectly fine for Fedora to include from a legal perspective. But they will need to be reviewed by legal on a case to case basis, going to legal up front and saying 'hey can I include a hypothetical repository' will only yield you the answer 'depends on the repository'. OK cool. What is the plan for when repositories change what they are carrying and add stuff that may be legal for them but not for others? Will there be periodic reviews to make sure that this hasn't happened or some way that we roll back what repositories we recommend? At the risk of being glib: What's the plan for periodically re-reviewing every package in Fedora to make sure that its sources always remain legal? It's the same problem and it can only realistically be dealt with by If someone notices, deal with it then. IIRC, the original discussion was framed around specific repositories with specific pieces of software. So a repository carrying e.g. Chrome and only Chrome. Not something like rpmfusion which carries a multitude of varied packages. So in that case, the audit becomes easier. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The Forgotten F: A Tale of Fedora's Foundations
On Thu, Apr 24, 2014 at 9:56 AM, Stephen Gallagher sgall...@redhat.com wrote: OK cool. What is the plan for when repositories change what they are carrying and add stuff that may be legal for them but not for others? Will there be periodic reviews to make sure that this hasn't happened or some way that we roll back what repositories we recommend? At the risk of being glib: What's the plan for periodically re-reviewing every package in Fedora to make sure that its sources always remain legal? It's the same problem and it can only realistically be dealt with by If someone notices, deal with it then. One practical difference is that there's no bug trackers for individual COPRs. At least when a package is in Fedora, communication can happen in a central place (Bugzilla), and there's an FE-LEGAL blocker mechanism, etc. That tooling is much easier than trying to handle things over private email, and none of that tooling exists outside the distro. I've looked through COPR's features and roadmap and I've not seen plans to add it, unfortunately. - Ken -- 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: The Forgotten F: A Tale of Fedora's Foundations
On Thu, 24 Apr 2014 10:04:41 -0600 Ken Dreyer ktdre...@ktdreyer.com wrote: One practical difference is that there's no bug trackers for individual COPRs. At least when a package is in Fedora, communication can happen in a central place (Bugzilla), and there's an FE-LEGAL blocker mechanism, etc. That tooling is much easier than trying to handle things over private email, and none of that tooling exists outside the distro. I've looked through COPR's features and roadmap and I've not seen plans to add it, unfortunately. Well, copr does have a 'legal flag' checkbox... when you check this on a copr, it sends email to a bunch of people who can look at the thing and see if it really has an issue and can mail the copr maintainer about it. Not as easy, but should be workable for things noticed... 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
[Base] Base Design WG agenda meeting 25. Apr 2014 15:00 UTC on #fedora-meeting
Agenda: - Status update on merge reviews, tech spec, securetty proposal - Open floor Thanks regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- 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] plans for initscripts in F22
On Thu, Apr 24, 2014 at 05:55:29PM +0200, Miloslav Trmač wrote: Hello, 2014-04-24 16:38 GMT+02:00 Lukáš Nykrýn lnyk...@redhat.com: We must keep initscripts support, but I can imagine a setup where every service uses a systemd unit, so this part does not have to be installed by default, but could be pulled in as a dependency. Are you sure? If you take an existing RPM that ships a sysv file, that's alone an indication that it probably hasn't been significantly reworked, so noone is likely to have added an explicit requires: on this part. For extra credit, make sure that this works correctly with LSB-compliant RPMs that do nothing not required by LSB. I may be wrong but I believe we could update our dependency-detection scripts to note when a package ships an init script and add the requirement automatically. As long as there's a mass rebuild between now and shipping that should take care of everyone. --CJD pgp0GQ_7Ia4Dx.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [Base] Base Design WG agenda meeting 25. Apr 2014 15:00 UTC on #fedora-meeting
On Thu, Apr 24, 2014 at 12:12 PM, Phil Knirsch pknir...@redhat.com wrote: Agenda: - Status update on merge reviews, tech spec, securetty proposal The securetty proposal was settled at yesterday's FESCo meeting. I doubt there's much to discuss further on it. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
2014-04-24 18:13 GMT+02:00 Casey Dahlin cdah...@redhat.com: On Thu, Apr 24, 2014 at 05:55:29PM +0200, Miloslav Trmač wrote: Hello, 2014-04-24 16:38 GMT+02:00 Lukáš Nykrýn lnyk...@redhat.com: We must keep initscripts support, but I can imagine a setup where every service uses a systemd unit, so this part does not have to be installed by default, but could be pulled in as a dependency. Are you sure? If you take an existing RPM that ships a sysv file, that's alone an indication that it probably hasn't been significantly reworked, so noone is likely to have added an explicit requires: on this part. For extra credit, make sure that this works correctly with LSB-compliant RPMs that do nothing not required by LSB. I may be wrong but I believe we could update our dependency-detection scripts to note when a package ships an init script and add the requirement automatically. As long as there's a mass rebuild between now and shipping that should take care of everyone. Only those that are maintained directly inside Fedora. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: The Forgotten F: A Tale of Fedora's Foundations
On Thu, Apr 24, 2014 at 10:07 AM, Kevin Fenzi ke...@scrye.com wrote: On Thu, 24 Apr 2014 10:04:41 -0600 Ken Dreyer ktdre...@ktdreyer.com wrote: One practical difference is that there's no bug trackers for individual COPRs. At least when a package is in Fedora, communication can happen in a central place (Bugzilla), and there's an FE-LEGAL blocker mechanism, etc. That tooling is much easier than trying to handle things over private email, and none of that tooling exists outside the distro. I've looked through COPR's features and roadmap and I've not seen plans to add it, unfortunately. Well, copr does have a 'legal flag' checkbox... when you check this on a copr, it sends email to a bunch of people who can look at the thing and see if it really has an issue and can mail the copr maintainer about it. Not as easy, but should be workable for things noticed... That's a good start at least. Thanks for pointing it out. - Ken -- 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: The Forgotten F: A Tale of Fedora's Foundations
On 24 April 2014 09:56, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/24/2014 11:01 AM, Stephen John Smoogen wrote: On 24 April 2014 02:49, Christian Schaller cscha...@redhat.com mailto:cscha...@redhat.com wrote: Well my point is I spoke to Red Hat legal before I even posted the original proposal to open up to more 3rd party repositories some Months ago. There are a lot of repositories that it is perfectly fine for Fedora to include from a legal perspective. But they will need to be reviewed by legal on a case to case basis, going to legal up front and saying 'hey can I include a hypothetical repository' will only yield you the answer 'depends on the repository'. OK cool. What is the plan for when repositories change what they are carrying and add stuff that may be legal for them but not for others? Will there be periodic reviews to make sure that this hasn't happened or some way that we roll back what repositories we recommend? At the risk of being glib: What's the plan for periodically re-reviewing every package in Fedora to make sure that its sources always remain legal? It's the same problem and it can only realistically be dealt with by If someone notices, deal with it then. There are a couple of differences. If we find that dvdcss was added to a package, we can rip out that package, put an update in the repository and people who do updates get a package without dvdcss. A third party repository is one we don't have any control over. If code that the 3rd party has no legal right to ship or fill in problem here, what is our remediation to our users? Are we in contributary infringement because we gave the users a way access to pirated software that we never intended in the first place? Is there an agreement between us and the third party that they are to be offering X, that they are legally able to offer X, and that if they are not they are to take all liability of offering X? These were things that people were wondering when this came up in the past. -- 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: Copr and Playground plugin part of dnf-plugins-core?
If you want people to vote for something, It would be a good idea to say why and what the pro/cons is for having copr as a separate package. Tim On Thu, Apr 24, 2014 at 11:29 AM, Miroslav Suchý msu...@redhat.com wrote: In https://bugzilla.redhat.com/show_bug.cgi?id=1090516 Jiri asked for removing Copr (and Playground) DNF plugin out of dnf-plugins-core. Since this is not technical but merely political question I would like to ask wider audience: Put your voice here please: http://www.easypolls.net/poll.html?p=5358d77de4b06a67c5b08e05 If there will be significant votes for one option, I would do what most of you wish. Otherwise I will forward it to Fesco for decision. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: Automatically generated configuration files
On 04/24/2014 05:39 PM, Paul Wouters wrote: On Thu, 24 Apr 2014, Florian Weimer wrote: I don't think openssl genrsa 2048 has this issue on today's machines. (I know I saw it with GNUTLS.) I was sceptical, so I tried this on a freshly booted VM: root@bofh:~# virsh start north Domain north started root@bofh:~# ssh root@north Last login: Wed Apr 23 11:54:46 2014 [root@north ~]# time openssl genrsa 2048 [...] real0m0.382s user0m0.267s sys0m0.003s Call me very surprised! We finally have real entropy in VMs now. Good news! I'm afraid your conclusion does not follow from the facts. openssl genrsa simply does not ensure that actual physical entropy is available. I'll make this quite explicit in my advice. Most of the openssl subcommands are tools for testing and debugging OpenSSL itself, and should not be used for other purposes. -- Florian Weimer / Red Hat Product Security Team -- 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: Copr and Playground plugin part of dnf-plugins-core?
On Thu, 24 Apr 2014 11:29:15 +0200 Miroslav Suchý msu...@redhat.com wrote: In https://bugzilla.redhat.com/show_bug.cgi?id=1090516 Jiri asked for removing Copr (and Playground) DNF plugin out of dnf-plugins-core. Since this is not technical but merely political question I would like to ask wider audience: Put your voice here please: http://www.easypolls.net/poll.html?p=5358d77de4b06a67c5b08e05 If there will be significant votes for one option, I would do what most of you wish. Otherwise I will forward it to Fesco for decision. I'm not sure a open vote is the way to go here. How about we try and figure this out on technical grounds? Personally I think it's fine to be in dnf-plugins-core, but the maintainers of dnf don't think so I guess, but that could just be that the audience isn't clear for the playground repo yet. It seems like something the env-and-stacks group could look into? ie, decide what the audience is for the playground repo. Is this intended only for advanced users/developers? Then, I suppose it could be a seperate package that they would have to know to install. If it's intended for general users if they know to look/enable it, then it needs to be at least installed by default. 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: Self Introduction : Marianne Lombard
Hello Marianne, On Thursday, 24 April 2014 at 14:20, Marianne Lombard wrote: Hi, I'm writing today because I have submitted my first package for review : https://bugzilla.redhat.com/show_bug.cgi?id=1090933 Welcome on board! I'm a sysadmin since a few years in a public research center and we are using (a lot) of free and open-source software. So I will probably work on sysadmin / scientific tools. I will need a sponsor and I hope to find someone soon (probably a french like me because my english is not perfect) I used to work at an academic institution and I still maintain a lot of scientific software packages. To be honest, I could use some help maintaining some of those which I don't use anymore. Feel free to ping me if you haven't found a sponsor already. I recommend you join the Science and Technology SIG: https://fedoraproject.org/wiki/Category:SciTech_SIG Regards, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations -- 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: The Forgotten F: A Tale of Fedora's Foundations
- Original Message - From: Stephen John Smoogen smo...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, April 24, 2014 6:46:03 PM Subject: Re: The Forgotten F: A Tale of Fedora's Foundations On 24 April 2014 09:56, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/24/2014 11:01 AM, Stephen John Smoogen wrote: On 24 April 2014 02:49, Christian Schaller cscha...@redhat.com mailto: cscha...@redhat.com wrote: Well my point is I spoke to Red Hat legal before I even posted the original proposal to open up to more 3rd party repositories some Months ago. There are a lot of repositories that it is perfectly fine for Fedora to include from a legal perspective. But they will need to be reviewed by legal on a case to case basis, going to legal up front and saying 'hey can I include a hypothetical repository' will only yield you the answer 'depends on the repository'. OK cool. What is the plan for when repositories change what they are carrying and add stuff that may be legal for them but not for others? Will there be periodic reviews to make sure that this hasn't happened or some way that we roll back what repositories we recommend? At the risk of being glib: What's the plan for periodically re-reviewing every package in Fedora to make sure that its sources always remain legal? It's the same problem and it can only realistically be dealt with by If someone notices, deal with it then. There are a couple of differences. If we find that dvdcss was added to a package, we can rip out that package, put an update in the repository and people who do updates get a package without dvdcss. A third party repository is one we don't have any control over. If code that the 3rd party has no legal right to ship or fill in problem here, what is our remediation to our users? Are we in contributary infringement because we gave the users a way access to pirated software that we never intended in the first place? Is there an agreement between us and the third party that they are to be offering X, that they are legally able to offer X, and that if they are not they are to take all liability of offering X? These were things that people were wondering when this came up in the past. Once again this is becoming a debate about hypotheticals which rarely leads anywhere constructive. To take a concrete case instead. Are you really worried about Google starting to ship dvdcss as part of their Chrome repository? Do you really think that is a question keeping our lawyers up at night? Are there repositories out there where we can not trust the person or company behind it enough to include it by default for legal reasons? Sure there is, but you can't say that just because we would not want to risk shipping the rpm-warez.tor.net repo by default all 3rd party repos are high risk and something our lawyers would be concerned about. Because that is the argument you in practice is making when you are posing hypothetical questions about the risk of 3rd party repos. Christian -- 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: The Forgotten F: A Tale of Fedora's Foundations
On 24 April 2014 16:06, Christian Schaller cscha...@redhat.com wrote: These were things that people were wondering when this came up in the past. Once again this is becoming a debate about hypotheticals which rarely leads anywhere constructive. It actually isn't hypothetical. I have had to deal with a lot of problems with 3rd party repositories at previous jobs. The easiest and most common one is where the 3rd party later ships something that conflicts with the main repository. The weirder ones are where a clean package got stuff added to it where it backdoored the desktop or where it added a P2P service which set off all kinds of emails from the RIAA to the universities legal. To take a concrete case instead. Are you really worried about Google starting to ship dvdcss as part of their Chrome repository? Do you really think that is a question keeping our lawyers up at night? I am more worried about the criteria we are using for choosing these repositories, how they are chosen, vetted and added and a basic How we plan to deal with problems when they occur versus the standard OMG THE SKY IS FALLING AND ITS ALL FILL-IN-BLANK FAULT. Because problems will occur and they will be at various very inconvenient times so having at least a We will contact X, we will turn off Y in package Z, we will then push an update with who to contact to deal with them. Are there repositories out there where we can not trust the person or company behind it enough to include it by default for legal reasons? Sure there is, but you can't say that just because we would not want to risk shipping the rpm-warez.tor.netrepo by default all 3rd party repos are high risk and something our lawyers would be concerned about. Because that is the argument you in practice is making when you are posing hypothetical questions about the risk of 3rd party repos. You seem to have completely misread me so it is clear we are talking past each other. Since I am not communicating clearly in a way you or others understand, I will stop and withdrawal until I can better do so. Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Self Introduction : Marianne Lombard
On 04/24/2014 04:02 PM, Dominik 'Rathann' Mierzejewski wrote: Hello Marianne, On Thursday, 24 April 2014 at 14:20, Marianne Lombard wrote: Hi, I'm writing today because I have submitted my first package for review : https://bugzilla.redhat.com/show_bug.cgi?id=1090933 Welcome on board! I'm a sysadmin since a few years in a public research center and we are using (a lot) of free and open-source software. So I will probably work on sysadmin / scientific tools. I will need a sponsor and I hope to find someone soon (probably a french like me because my english is not perfect) I used to work at an academic institution and I still maintain a lot of scientific software packages. To be honest, I could use some help maintaining some of those which I don't use anymore. Feel free to ping me if you haven't found a sponsor already. I recommend you join the Science and Technology SIG: https://fedoraproject.org/wiki/Category:SciTech_SIG Regards, Dominik Yes, welcome, and join the SIG such as it is. And yes, we need lots of help. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
On Thu, Apr 24, 2014 at 04:38:07PM +0200, Lukáš Nykrýn wrote: Hi, for the F22 I am planning some bigger changes regarding initscripts and I would like to ask for comments. Initscripts package was in the past a crucial part of the system. They basicaly set up whole system during the boot. Currently initscripts package contains support for initscripts (/etc/init.d/function, service command), network initscripts and tons of leftovers. So my plan is following: We must keep initscripts support, but I can imagine a setup where every service uses a systemd unit, so this part does not have to be installed by default, but could be pulled in as a dependency. Network initscript. This will be probably the most controversial part. In fedora 21 we will have three different tools for networking (initscripts, NetworkManager and systemd-networkd) and all of them will be installed by default. For various design reasons network initscripts does not have any future (it is completely synchronous and does not work with parallel boot very well). So I would like to split it in its own package and drop it in the future. For most of the use-cases NM is sufficient replacement and if somebody will miss a static configuration we are planning to replace network initscript functionality in networkd. Than there are scripts and configs like /etc/crypttab This should be moved to cryptsetup or systemd, probably the latter. /etc/inittab This should be moved to systemd, it is essentially a README. In addition, it contains outdated advice. /etc/profile.d/256term.sh /usr/lib/systemd/fedora-autorelabel /usr/bin/ipcalc /usr/bin/usleep /usr/sbin/consoletype /usr/sbin/genhostid /usr/sbin/sushell /var/log/btmp /var/log/wtmp + /var/run/utmp Those three could be picked up by systemd too. Even if the long-term plan is to get rid of them, systemd writes those files anyway. Also the sysctl stuff should be consumed by systemd: /usr/lib/sysctl.d/00-system.conf /etc/sysctl.conf /etc/sysctl.d/99-sysctl.conf Can we have a joint initscripts + systemd release in a few days to change ownership of those files? I would like to find a new better home for them. So I am suggesting to start with splitting initscripts to these sub-packages. initscripts - initscripts support initscripts-core (looking for better name) - the leftovers which needs to by installed by default for now, but we will move everything from it to different components initscripts-network - network initscript initscripts-readonly - support for readonly root should be redesigned completelly initscripts-doc initscripts-locale initscripts-man I too think that this split is a lot of work for small gain. Working out the full dependencies set of what needs what is going to take a while, but I think it would be better to simply shrink the package to nothing in small steps. Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Self Introduction: Dennis Payne
I've been using Fedora since it started and have packaged up personal programs before as rpms. After doing a presentation on Bt Builder for a local linux user group, the only option I had for them to try the program was to compile from source. (Which isn't hard but not the user experience I would like.) I figured I'd join Fedora so that it can be easily installed. The Bt Builder bugzilla request is: https://bugzilla.redhat.com/show_bug.cgi?id=1079064 I've contributed to a few other open source projects in the past including maintaining xwpe for several years. -- 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: Automatically generated configuration files
On Thu, Apr 24, 2014 at 10:10:15AM -0400, Adam Jackson wrote: On Thu, 2014-04-24 at 15:47 +0200, Florian Weimer wrote: I'm working on advice on automated X.509 certificate generation during package installation. One aspect is that these files obviously have to be generated on the system during installation (or first service start) and cannot be shipped in the package. Some existing RPMs just drop files into /etc/pki/certs and /etc/pki/tls/private, without marking them as ghost files or configuration files. (I'm not even sure if you can mark something for which no content is provided in the RPM as a configuration file.) I wonder what an ideal RPM package would do in this case? If you know what service is going to require the cert, you might copy the pattern from openssh, where sshd-keygen.service runs as a prereq for sshd itself. This, or first service start, are good ideas. Remember that your package may not be getting installed on the system where it eventually runs -- livecd's, cloud images, etc. can be created in situations where the build host is totally different from the final target. eg. creating an image inside a mock running on a RHEL6 system. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- 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: Copr and Playground plugin part of dnf-plugins-core?
I have started a new dnf-utils project for commuty plugins/addons there is not maintain by the core dnf team https://github.com/timlau/dnf-utils copr / playground is welcome here is the core dnf developers, think its dont fit into dnf-plugins.core It is not submitted as a fedora package yet, but that will happen soon Tim On Thu, Apr 24, 2014 at 11:29 AM, Miroslav Suchý msu...@redhat.com wrote: In https://bugzilla.redhat.com/show_bug.cgi?id=1090516 Jiri asked for removing Copr (and Playground) DNF plugin out of dnf-plugins-core. Since this is not technical but merely political question I would like to ask wider audience: Put your voice here please: http://www.easypolls.net/poll.html?p=5358d77de4b06a67c5b08e05 If there will be significant votes for one option, I would do what most of you wish. Otherwise I will forward it to Fesco for decision. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: Automatically generated configuration files
On 04/24/2014 08:39 AM, Paul Wouters wrote: On Thu, 24 Apr 2014, Florian Weimer wrote: I don't think openssl genrsa 2048 has this issue on today's machines. (I know I saw it with GNUTLS.) I was sceptical, so I tried this on a freshly booted VM: root@bofh:~# virsh start north Domain north started root@bofh:~# ssh root@north Last login: Wed Apr 23 11:54:46 2014 [root@north ~]# time openssl genrsa 2048 [...] real0m0.382s user0m0.267s sys0m0.003s Call me very surprised! We finally have real entropy in VMs now. Good news! That is surprising, I wonder if it's using /dev/random or /dev/urandom. Twice I've done an install of freeipa on a freshly installed vm and both times it wouldn't start. I finally figured out that named needs to read from /dev/random when starting up the first time and it wasn't getting anything. The first time I ran the command manually telling it to use /dev/urandom. The second time I ran it manually and did a lot of filesystem and network access, hoping that it would generate entropy. Which it did seem to do as the command ran successfully. -- 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 1086545] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=1086545 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- perl-No-Worries-1.2-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=Y3UFtlgwzTa=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 1085905] perl-Catalyst-Model-DBIC-Schema-0.61-1.fc21 FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1085905 --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- perl-Catalyst-Model-DBIC-Schema-0.60-5.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=KodU7wqweTa=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 1086545] Upgrade to new upstream version
https://bugzilla.redhat.com/show_bug.cgi?id=1086545 --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- perl-No-Worries-1.2-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=et3gfmwGdCa=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 1087327] perl-Locale-SubCountry-1.63 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087327 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-Locale-SubCountry-1.63-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=nYzbwEYELYa=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 1085905] perl-Catalyst-Model-DBIC-Schema-0.61-1.fc21 FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1085905 --- Comment #7 from Fedora Update System upda...@fedoraproject.org --- perl-Catalyst-Model-DBIC-Schema-0.61-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=gqN2outcZaa=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 1087327] perl-Locale-SubCountry-1.63 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087327 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- perl-Locale-SubCountry-1.63-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=tP4J26t9mBa=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 1087334] perl-Net-Twitter-4.01004 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087334 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Net-Twitter-4.01004-1. ||fc19 Resolution|--- |ERRATA Last Closed||2014-04-24 03:45:19 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-Net-Twitter-4.01004-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=tZ9qahY3Era=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 1087334] perl-Net-Twitter-4.01004 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1087334 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-Net-Twitter-4.01004-1. |perl-Net-Twitter-4.01004-1. |fc19|fc20 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- perl-Net-Twitter-4.01004-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=I6nnSoZ4aIa=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-Data-Section-Simple] Update to 0.07
commit e4f2bfec436f93e7371c4914953845ebb1dabb26
Author: Paul Howarth p...@city-fan.org
Date: Thu Apr 24 09:18:36 2014 +0100
Update to 0.07
- New upstream release 0.07
- Revert the change in 0.06
- Update patch for building with Test::More 0.88
... Data-Section-Simple-0.07-old-Test::More.patch | 19 ---
perl-Data-Section-Simple.spec |9 +++--
2 files changed, 7 insertions(+), 21 deletions(-)
---
diff --git a/Data-Section-Simple-0.06-old-Test::More.patch
b/Data-Section-Simple-0.07-old-Test::More.patch
similarity index 78%
rename from Data-Section-Simple-0.06-old-Test::More.patch
rename to Data-Section-Simple-0.07-old-Test::More.patch
index b27c74f..079fe1a 100644
--- a/Data-Section-Simple-0.06-old-Test::More.patch
+++ b/Data-Section-Simple-0.07-old-Test::More.patch
@@ -35,25 +35,6 @@
-
-
-
t/multi-processes.t
-+++ t/multi-processes.t
-@@ -1,6 +1,6 @@
- use strict;
- use Data::Section::Simple qw(get_data_section);
--use Test::More;
-+use Test::More tests = 1;
-
- my $expect =HTML;
- html
-@@ -22,8 +22,6 @@ while (waitpid(-1,0) 0) {
-
- ok(!$failed);
-
--done_testing;
--
- __DATA__
-
- @@ foo.html
--- t/no-datat.t
+++ t/no-datat.t
@@ -1,7 +1,5 @@
diff --git a/perl-Data-Section-Simple.spec b/perl-Data-Section-Simple.spec
index ec11d2b..b6985e2 100644
--- a/perl-Data-Section-Simple.spec
+++ b/perl-Data-Section-Simple.spec
@@ -2,14 +2,14 @@
%global old_test_more %(perl -MTest::More -e 'print (($Test::More::VERSION
0.88) ? 1 : 0);' 2/dev/null || echo 0)
Name: perl-Data-Section-Simple
-Version: 0.06
+Version: 0.07
Release: 1%{?dist}
Summary: Read data from __DATA__
License: GPL+ or Artistic
Group: Development/Libraries
URL: https://github.com/miyagawa/Data-Section-Simple
Source0:
http://cpan.metacpan.org/authors/id/M/MI/MIYAGAWA/Data-Section-Simple-%{version}.tar.gz
-Patch1:Data-Section-Simple-0.06-old-Test::More.patch
+Patch1:Data-Section-Simple-0.07-old-Test::More.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
# Build
@@ -67,6 +67,11 @@ rm -rf %{buildroot}
%{_mandir}/man3/Data::Section::Simple.3pm*
%changelog
+* Thu Apr 24 2014 Paul Howarth p...@city-fan.org - 0.07-1
+- Update to 0.07
+ - Revert the change in 0.06
+- Update patch for building with Test::More 0.88
+
* Sat Apr 12 2014 Paul Howarth p...@city-fan.org - 0.06-1
- Update to 0.06
- Fix race condition in a forked environment
--
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 Data-Section-Simple-0.07.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Data-Section-Simple: 5a079d3d7712fa3c8256494cf026a153 Data-Section-Simple-0.07.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-Data-Section-Simple] Upload Data-Section-Simple-0.07.tar.gz
commit 9494664acd481423e1d595b92e7aa5bb6f1320d0 Author: Paul Howarth p...@city-fan.org Date: Thu Apr 24 09:27:15 2014 +0100 Upload Data-Section-Simple-0.07.tar.gz sources |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) --- diff --git a/sources b/sources index 78e3a86..13649e6 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -e2cc4cecefb51a15250eda14563599d4 Data-Section-Simple-0.06.tar.gz +5a079d3d7712fa3c8256494cf026a153 Data-Section-Simple-0.07.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-Data-Section-Simple] Created tag perl-Data-Section-Simple-0.07-1.fc21
The lightweight tag 'perl-Data-Section-Simple-0.07-1.fc21' was created pointing to: 9494664... Upload Data-Section-Simple-0.07.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the epel-7 tree: On ppc64: perl-PDL-2.7.0-2.el7.1.ppc64 requires perl(PDL::Slatec) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1084093] perl-CPAN-Inject-1.14-4.fc21 FTBFS in non-koji mock
https://bugzilla.redhat.com/show_bug.cgi?id=1084093 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|jples...@redhat.com |ppi...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=fYZ5XNEIS5a=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 Starlet-0.23.tar.gz uploaded to lookaside cache by corsepiu
A file has been added to the lookaside cache for perl-Starlet: a5f51de210537229bfdc5615a7867dd1 Starlet-0.23.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-Starlet] Upstream update.
commit 1eb618f3082ba9fd4cda5a94a8e2e5fca20af0d6
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Thu Apr 24 12:35:51 2014 +0200
Upstream update.
.gitignore|2 +-
perl-Starlet.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index ee0f303..98fef2a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/Starlet-0.22.tar.gz
+/Starlet-0.23.tar.gz
diff --git a/perl-Starlet.spec b/perl-Starlet.spec
index d62f281..1410f28 100644
--- a/perl-Starlet.spec
+++ b/perl-Starlet.spec
@@ -1,5 +1,5 @@
Name: perl-Starlet
-Version:0.22
+Version:0.23
Release:1%{?dist}
Summary:Simple, high-performance PSGI/Plack HTTP server
License:GPL+ or Artistic
@@ -55,6 +55,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Apr 24 2014 Ralf Corsépius corse...@fedoraproject.org - 0.23-1
+- Upstream update.
+
* Mon Apr 14 2014 Ralf Corsépius corse...@fedoraproject.org - 0.22-1
- Upstream update.
diff --git a/sources b/sources
index 3e133a2..d7b7c83 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-bb5c8408dd816e2cc9c57bda86a138d2 Starlet-0.22.tar.gz
+a5f51de210537229bfdc5615a7867dd1 Starlet-0.23.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-Starlet/f20] Upstream update.
Summary of changes: 1eb618f... Upstream update. (*) (*) 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-CPAN-Inject] Run tests in a new home and noninteractively
commit 8169d89aaa094638f522bd300f8c66cd8c18e914
Author: Petr Písař ppi...@redhat.com
Date: Wed Apr 23 15:10:58 2014 +0200
Run tests in a new home and noninteractively
perl-CPAN-Inject.spec |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
---
diff --git a/perl-CPAN-Inject.spec b/perl-CPAN-Inject.spec
index 2ed336c..46c1039 100644
--- a/perl-CPAN-Inject.spec
+++ b/perl-CPAN-Inject.spec
@@ -1,6 +1,6 @@
Name: perl-CPAN-Inject
Version:1.14
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Base class for injecting distributions into CPAN sources
License:GPL+ or Artistic
Group: Development/Libraries
@@ -55,7 +55,9 @@ find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
-make test
+export HOME=$PWD/home
+mkdir $HOME
+make test /dev/null
%files
%doc Changes
@@ -65,6 +67,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Apr 23 2014 Petr Pisar ppi...@redhat.com - 1.14-5
+- Run tests in a new home and noninteractively
+
* Mon Aug 05 2013 Petr Pisar ppi...@redhat.com - 1.14-4
- Perl 5.18 rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CPAN-Inject] Work around CPAN bug mangling working directory
commit 66128023201f9e302e24484c1800bbd94c2caa50
Author: Petr Písař ppi...@redhat.com
Date: Thu Apr 24 12:34:52 2014 +0200
Work around CPAN bug mangling working directory
...king-directory-after-loading-CPAN-configu.patch | 66
perl-CPAN-Inject.spec |6 ++
2 files changed, 72 insertions(+), 0 deletions(-)
---
diff --git
a/CPAN-Inject-1.14-Restore-working-directory-after-loading-CPAN-configu.patch
b/CPAN-Inject-1.14-Restore-working-directory-after-loading-CPAN-configu.patch
new file mode 100644
index 000..0baf696
--- /dev/null
+++
b/CPAN-Inject-1.14-Restore-working-directory-after-loading-CPAN-configu.patch
@@ -0,0 +1,66 @@
+From 77e5e5d05f5b4df313b89ed96d5cc2e7d335dac5 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= ppi...@redhat.com
+Date: Thu, 24 Apr 2014 11:20:51 +0200
+Subject: [PATCH] Restore working directory after loading CPAN configuration
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Uninitialized CPAN can install local::lib and change working directory
+into last build directory (CPAN RT#52520).
+
+This is a work-around to restore the directory back.
+
+https://rt.cpan.org/Public/Bug/Display.html?id=94963
+
+Signed-off-by: Petr Písař ppi...@redhat.com
+---
+ Makefile.PL| 1 +
+ lib/CPAN/Inject.pm | 12
+ 2 files changed, 13 insertions(+)
+
+diff --git a/Makefile.PL b/Makefile.PL
+index 9c49730..e1e8ee8 100644
+--- a/Makefile.PL
b/Makefile.PL
+@@ -2,6 +2,7 @@ use inc::Module::Install 1.00;
+
+ name 'CPAN-Inject';
+ all_from 'lib/CPAN/Inject.pm';
++requires 'Cwd' = '0';
+ requires 'File::Spec' = '0.80';
+ requires 'File::stat' = '1.00';
+ requires 'File::chmod' = '0.30';
+diff --git a/lib/CPAN/Inject.pm b/lib/CPAN/Inject.pm
+index faec14c..86cf9ea 100644
+--- a/lib/CPAN/Inject.pm
b/lib/CPAN/Inject.pm
+@@ -205,6 +205,10 @@ sub from_cpan_config {
+ # Load the CPAN module
+ require CPAN;
+
++ # Remember working directory in case CPAN will change it, RT#94963
++ require Cwd;
++ my $origin_working_directory = Cwd::getcwd;
++
+ # Support for different mechanisms depending on the version
+ # of CPAN that is in use.
+ if ( defined $CPAN::HandleConfig::VERSION ) {
+@@ -213,6 +217,14 @@ sub from_cpan_config {
+ CPAN::Config-load;
+ }
+
++ # Restore working directory in case CPAN has changed it, RT#94963
++ if ($origin_working_directory ne Cwd::getcwd) {
++ chdir $origin_working_directory or
++ warn CPAN changed working directory .
++ and later restoration to .
++ $origin_working_directory failed: $!;
++ }
++
+ # Get the sources directory
+ my $sources = undef;
+ if ( defined $CPAN::Config-{keep_source_where} ) {
+--
+1.9.0
+
diff --git a/perl-CPAN-Inject.spec b/perl-CPAN-Inject.spec
index 46c1039..6a613ec 100644
--- a/perl-CPAN-Inject.spec
+++ b/perl-CPAN-Inject.spec
@@ -6,9 +6,12 @@ License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/CPAN-Inject/
Source0:
http://www.cpan.org/authors/id/P/PS/PSHANGOV/CPAN-Inject-%{version}.tar.gz
+# Work around CPAN bug mangling working directory, bug #1084093, CPAN RT#94963
+Patch0:
CPAN-Inject-1.14-Restore-working-directory-after-loading-CPAN-configu.patch
BuildArch: noarch
BuildRequires: perl(CPAN) = 1.36
BuildRequires: perl(CPAN::Checksums) = 1.05
+BuildRequires: perl(Cwd)
BuildRequires: perl(File::Basename) = 2.6
BuildRequires: perl(File::chmod) = 0.30
BuildRequires: perl(File::Copy) = 2.02
@@ -23,6 +26,7 @@ BuildRequires: perl(Test::More) = 0.42
BuildRequires: perl(Test::Script) = 1.02
Requires: perl(CPAN) = 1.36
Requires: perl(CPAN::Checksums) = 1.05
+Requires: perl(Cwd)
Requires: perl(File::Basename) = 2.6
Requires: perl(File::chmod) = 0.30
Requires: perl(File::Copy) = 2.02
@@ -39,6 +43,7 @@ created to add additional distributions into a minicpan
mirror.
%prep
%setup -q -n CPAN-Inject-%{version}
+%patch0 -p1
# Remove bundled libraries
rm -r inc
@@ -69,6 +74,7 @@ make test /dev/null
%changelog
* Wed Apr 23 2014 Petr Pisar ppi...@redhat.com - 1.14-5
- Run tests in a new home and noninteractively
+- Work around CPAN bug mangling working directory (bug #1084093)
* Mon Aug 05 2013 Petr Pisar ppi...@redhat.com - 1.14-4
- Perl 5.18 rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1084093] perl-CPAN-Inject-1.14-4.fc21 FTBFS in non-koji mock
https://bugzilla.redhat.com/show_bug.cgi?id=1084093 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-CPAN-Inject-1.14-5.fc2 ||1 Resolution|--- |RAWHIDE Last Closed||2014-04-24 06:50:58 --- Comment #2 from Petr Pisar ppi...@redhat.com --- I applied a work-around. -- 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=8FaMvJNe4ma=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-Fennec] Downgrade Module::Build version requirement to 0.40 (for EPEL-7)
commit c5c8d6905e75f5aaef9110925071a75dd83474da
Author: Paul Howarth p...@city-fan.org
Date: Thu Apr 24 12:09:49 2014 +0100
Downgrade Module::Build version requirement to 0.40 (for EPEL-7)
Fennec-2.017-M::B.patch | 22 ++
perl-Fennec.spec| 11 +--
2 files changed, 31 insertions(+), 2 deletions(-)
---
diff --git a/Fennec-2.017-M::B.patch b/Fennec-2.017-M::B.patch
new file mode 100644
index 000..1981461
--- /dev/null
+++ b/Fennec-2.017-M::B.patch
@@ -0,0 +1,22 @@
+--- META.json
META.json
+@@ -16,7 +16,7 @@
+prereqs : {
+ configure : {
+ requires : {
+-Module::Build : 0.42
++Module::Build : 0.40
+ }
+ },
+ runtime : {
+--- META.yml
META.yml
+@@ -4,7 +4,7 @@ author:
+ - 'Chad Granum exodi...@gmail.com'
+ build_requires: {}
+ configure_requires:
+- Module::Build: 0.42
++ Module::Build: 0.40
+ dynamic_config: 1
+ generated_by: 'Module::Build version 0.4205, CPAN::Meta::Converter version
2.120921'
+ license: perl
diff --git a/perl-Fennec.spec b/perl-Fennec.spec
index ada8f36..7324f41 100644
--- a/perl-Fennec.spec
+++ b/perl-Fennec.spec
@@ -3,15 +3,16 @@
Name: perl-Fennec
Version: 2.017
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: A tester's toolbox, and best friend
License: GPL+ or Artistic
URL: https://metacpan.org/release/Fennec
Source0:
http://cpan.metacpan.org/authors/id/E/EX/EXODIST/Fennec-%{version}.tar.gz
+Patch0:Fennec-2.017-M::B.patch
BuildArch: noarch
# Module Build
BuildRequires: perl
-BuildRequires: perl(Module::Build) = 0.42
+BuildRequires: perl(Module::Build) = 0.40
# Module Runtime
BuildRequires: perl(B)
BuildRequires: perl(base)
@@ -54,6 +55,9 @@ makes testing easier, and more useful.
%prep
%setup -q -n Fennec-%{version}
+# Downgrade Module::Build version requirement to 0.40 (for EPEL-7)
+%patch0
+
%build
perl Build.PL --installdirs=vendor
./Build
@@ -100,6 +104,9 @@ perl Build.PL --installdirs=vendor
%{_mandir}/man3/Test::Workflow::Test.3pm*
%changelog
+* Thu Apr 24 2014 Paul Howarth p...@city-fan.org - 2.017-2
+- Downgrade Module::Build version requirement to 0.40 (for EPEL-7)
+
* Wed Apr 23 2014 Paul Howarth p...@city-fan.org - 2.017-1
- Update to 2.017
- Require newer Child.pm
--
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-Fennec/epel7] (3 commits) ...Downgrade Module::Build version requirement to 0.40 (for EPEL-7)
Summary of changes: 018aa5f... Update to 2.016 (*) 146cddc... Update to 2.017 (*) c5c8d69... Downgrade Module::Build version requirement to 0.40 (for EP (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1090929] New: perl-Alien-SDL-1.442 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1090929 Bug ID: 1090929 Summary: perl-Alien-SDL-1.442 is available Product: Fedora Version: rawhide Component: perl-Alien-SDL Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 1.442 Current version/release in Fedora Rawhide: 1.440-3.fc20 URL: http://search.cpan.org/dist/Alien-SDL/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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=eSuO7PHfg4a=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 1090931] New: perl-DateTime-Format-Flexible-0.26 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1090931 Bug ID: 1090931 Summary: perl-DateTime-Format-Flexible-0.26 is available Product: Fedora Version: rawhide Component: perl-DateTime-Format-Flexible Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com Latest upstream release: 0.26 Current version/release in Fedora Rawhide: 0.25-3.fc20 URL: http://search.cpan.org/dist/DateTime-Format-Flexible/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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=ieWNMnoGUSa=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 1090932] New: perl-Digest-SHA-5.89 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1090932 Bug ID: 1090932 Summary: perl-Digest-SHA-5.89 is available Product: Fedora Version: rawhide Component: perl-Digest-SHA Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 5.89 Current version/release in Fedora Rawhide: 5.88-1.fc21 URL: http://search.cpan.org/dist/Digest-SHA/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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=H832gSeYw0a=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-Fennec] Created tag perl-Fennec-2.017-2.el7
The lightweight tag 'perl-Fennec-2.017-2.el7' was created pointing to: c5c8d69... Downgrade Module::Build version requirement to 0.40 (for EP -- 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-Fennec] Created tag perl-Fennec-2.017-2.fc21
The lightweight tag 'perl-Fennec-2.017-2.fc21' was created pointing to: c5c8d69... Downgrade Module::Build version requirement to 0.40 (for EP -- 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 1088892] perl-Text-Xslate-3.2.3 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1088892 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Text-Xslate-3.2.1 is |perl-Text-Xslate-3.2.3 is |available |available --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 3.2.3 Current version/release in Fedora Rawhide: 3.1.2-2.fc21 URL: http://search.cpan.org/dist/Text-Xslate/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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=zSzgd95w28a=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-Starlet/f19] (2 commits) ...Merge remote-tracking branch 'origin/f20' into f19
Summary of changes: 1eb618f... Upstream update. (*) f5e8cac... Merge remote-tracking branch 'origin/f20' into f19 (*) 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-Starlet/f19: 2/2] Merge remote-tracking branch 'origin/f20' into f19
commit f5e8cac31878542a0175b53b2250ba9f1aa6ea95 Merge: 8a4f8a5 1eb618f Author: Ralf Corsépius corse...@fedoraproject.org Date: Thu Apr 24 12:39:06 2014 +0200 Merge remote-tracking branch 'origin/f20' into f19 .gitignore|2 +- perl-Starlet.spec |5 - sources |2 +- 3 files changed, 6 insertions(+), 3 deletions(-) --- -- 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 MouseX-ConfigFromFile-0.05.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-MouseX-ConfigFromFile: f6dc7f738085611949510c07301402ca MouseX-ConfigFromFile-0.05.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-MouseX-ConfigFromFile] Initial import (perl-MouseX-ConfigFromFile-0.05-3)
commit 86c1077faa64212af1884ecabeb347b5bfa96f9e
Author: Paul Howarth p...@city-fan.org
Date: Thu Apr 24 14:06:07 2014 +0100
Initial import (perl-MouseX-ConfigFromFile-0.05-3)
This is an abstract role that provides an alternate constructor for creating
objects using parameters passed in from a configuration file. The actual
implementation of reading the configuration file is left to concrete
subroles.
It declares an attribute configfile and a class method new_with_config, and
requires that concrete roles derived from it implement the class method
get_config_from_file.
Attributes specified directly as arguments to new_with_config supercede
those
in the configfile.
.gitignore |1 +
perl-MouseX-ConfigFromFile.spec | 86 +++
sources |1 +
3 files changed, 88 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..f2288c0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/MouseX-ConfigFromFile-[0-9.]*.tar.gz
diff --git a/perl-MouseX-ConfigFromFile.spec b/perl-MouseX-ConfigFromFile.spec
new file mode 100644
index 000..546b19d
--- /dev/null
+++ b/perl-MouseX-ConfigFromFile.spec
@@ -0,0 +1,86 @@
+Name: perl-MouseX-ConfigFromFile
+Summary: An abstract Mouse role for setting attributes from a configfile
+Version: 0.05
+Release: 3%{?dist}
+License: GPL+ or Artistic
+URL: http://search.cpan.org/dist/MouseX-ConfigFromFile/
+Source0:
http://search.cpan.org/CPAN/authors/id/M/MA/MASAKI/MouseX-ConfigFromFile-%{version}.tar.gz
+BuildArch: noarch
+# Module Build
+BuildRequires: perl
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
+BuildRequires: perl(inc::Module::Install)
+BuildRequires: perl(Module::Install::AuthorTests)
+BuildRequires: perl(Module::Install::ReadmeFromPod)
+BuildRequires: perl(Module::Install::ReadmeMarkdownFromPod)
+BuildRequires: perl(Module::Install::Repository)
+# Module Runtime
+BuildRequires: perl(Mouse) = 0.39
+BuildRequires: perl(Mouse::Role)
+BuildRequires: perl(MouseX::Types::Path::Class) = 0.06
+# Test Suite
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(strict)
+BuildRequires: perl(Test::More) = 0.94
+BuildRequires: perl(Test::UseAllModules)
+# Author Tests
+BuildRequires: perl(Test::Pod) = 1.00
+BuildRequires: perl(Test::Pod::Coverage) = 1.04
+BuildRequires: perl(Test::Spelling), aspell-en
+# Runtime
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(Mouse) = 0.39
+
+%description
+This is an abstract role that provides an alternate constructor for creating
+objects using parameters passed in from a configuration file. The actual
+implementation of reading the configuration file is left to concrete subroles.
+
+It declares an attribute configfile and a class method new_with_config, and
+requires that concrete roles derived from it implement the class method
+get_config_from_file.
+
+Attributes specified directly as arguments to new_with_config supercede those
+in the configfile.
+
+%prep
+%setup -q -n MouseX-ConfigFromFile-%{version}
+
+# Unbundle Module::Install stuff and Test::UseAllModules
+# to check for issues with current toolchain modules
+rm -rf inc/
+perl -ni -e 'print unless /^inc\//;' MANIFEST
+
+# Avoid the need for Module::Install::AuthorRequires and
+# all of upstream's toolchain modules as a result of the unbundling
+perl -ni -e 'print unless /author_requires/;' Makefile.PL
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+%{_fixperms} %{buildroot}
+
+%check
+make test TEST_POD=1
+
+%files
+%doc Changes README
+%{perl_vendorlib}/MouseX/
+%{_mandir}/man3/MouseX::ConfigFromFile.3*
+
+%changelog
+* Wed Apr 23 2014 Paul Howarth p...@city-fan.org - 0.05-3
+- Incorporate feedback from package review (#1088946)
+ - Comment on module unbundling in %%prep
+ - Don't need to clean buildroot in %%install
+
+* Mon Apr 21 2014 Paul Howarth p...@city-fan.org - 0.05-2
+- Unbundle Module::Install stuff
+- Add buildreqs for author tests
+
+* Thu Apr 17 2014 Paul Howarth p...@city-fan.org - 0.05-1
+- Initial RPM version
diff --git a/sources b/sources
index e69de29..7b1dd4a 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+f6dc7f738085611949510c07301402ca MouseX-ConfigFromFile-0.05.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-MouseX-ConfigFromFile/epel7] Initial import (perl-MouseX-ConfigFromFile-0.05-3)
Summary of changes: 86c1077... Initial import (perl-MouseX-ConfigFromFile-0.05-3) (*) (*) 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-MouseX-ConfigFromFile/f20] Initial import (perl-MouseX-ConfigFromFile-0.05-3)
Summary of changes: 86c1077... Initial import (perl-MouseX-ConfigFromFile-0.05-3) (*) (*) 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 Search-Elasticsearch-1.10.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Search-Elasticsearch: de9b9cf28f6e7e83fb13f7b8d389f6fd Search-Elasticsearch-1.10.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-Search-Elasticsearch] Initial import.
commit 3e3284dfb1c07cb062b73eb74eff8515dfbf2249
Author: Emmanuel Seyman emman...@seyman.fr
Date: Thu Apr 24 15:26:18 2014 +0200
Initial import.
.gitignore |1 +
perl-Search-Elasticsearch.spec | 95
sources|1 +
3 files changed, 97 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..52ed067 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Search-Elasticsearch-1.10.tar.gz
diff --git a/perl-Search-Elasticsearch.spec b/perl-Search-Elasticsearch.spec
new file mode 100644
index 000..687c5df
--- /dev/null
+++ b/perl-Search-Elasticsearch.spec
@@ -0,0 +1,95 @@
+Name: perl-Search-Elasticsearch
+Version:1.10
+Release:3%{?dist}
+Summary:Official client for Elasticsearch
+License:ASL 2.0
+
+URL:http://search.cpan.org/dist/Search-Elasticsearch/
+Source0:
http://www.cpan.org/authors/id/D/DR/DRTECH/Search-Elasticsearch-%{version}.tar.gz
+
+BuildArch: noarch
+BuildRequires: perl(Any::URI::Escape)
+BuildRequires: perl(Data::Dumper)
+BuildRequires: perl(Encode)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(Hijk)
+BuildRequires: perl(HTTP::Headers)
+BuildRequires: perl(HTTP::Request)
+BuildRequires: perl(HTTP::Tiny)
+BuildRequires: perl(IO::Select)
+BuildRequires: perl(IO::Socket)
+BuildRequires: perl(IO::Socket::SSL)
+BuildRequires: perl(IO::Uncompress::Inflate)
+BuildRequires: perl(JSON)
+BuildRequires: perl(JSON::XS)
+BuildRequires: perl(lib)
+BuildRequires: perl(List::Util)
+BuildRequires: perl(Log::Any)
+BuildRequires: perl(Log::Any::Adapter)
+BuildRequires: perl(Log::Any::Adapter::Callback)
+BuildRequires: perl(LWP::UserAgent)
+BuildRequires: perl(MIME::Base64)
+BuildRequires: perl(Module::Runtime)
+BuildRequires: perl(Moo)
+BuildRequires: perl(Moo::Role)
+BuildRequires: perl(namespace::clean)
+BuildRequires: perl(overload)
+BuildRequires: perl(POSIX)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(strict)
+BuildRequires: perl(Sub::Exporter)
+BuildRequires: perl(Test::Deep)
+BuildRequires: perl(Test::Exception)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Time::HiRes)
+BuildRequires: perl(Try::Tiny)
+BuildRequires: perl(URI)
+BuildRequires: perl(URI::Escape::XS)
+BuildRequires: perl(warnings)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(IO::Socket::SSL)
+Requires: perl(IO::Uncompress::Inflate)
+Requires: perl(JSON::XS)
+Requires: perl(MIME::Base64)
+Requires: perl(URI::Escape::XS)
+
+%{?perl_default_filter}
+
+%description
+Search::Elasticsearch is the official Perl client for Elasticsearch,
+supported by elasticsearch.com. Elasticsearch itself is a flexible and
+powerful open source, distributed real-time search and analytics engine for
+the cloud. You can read more about it on elasticsearch.org.
+
+%prep
+%setup -q -n Search-Elasticsearch-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes LICENSE README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Wed Apr 23 2014 Emmanuel Seyman emman...@seyman.fr - 1.10-3
+- Take into account other comments
+
+* Sun Apr 20 2014 Emmanuel Seyman emman...@seyman.fr - 1.10-2
+- Take into account review comments (#1087988)
+
+* Sun Mar 09 2014 Emmanuel Seyman emman...@seyman.fr 1.10-1
+- Specfile autogenerated by cpanspec 1.78, with changes.
diff --git a/sources b/sources
index e69de29..1297902 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+de9b9cf28f6e7e83fb13f7b8d389f6fd Search-Elasticsearch-1.10.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: mojomojo
mojomojo has broken dependencies in the rawhide tree: On x86_64: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On i386: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On armhfp: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Search-Elasticsearch-1.11.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Search-Elasticsearch: 2ba179e636a26c88310c20e911663833 Search-Elasticsearch-1.11.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-MouseX-ConfigFromFile/f19] Initial import (perl-MouseX-ConfigFromFile-0.05-3)
Summary of changes: 86c1077... Initial import (perl-MouseX-ConfigFromFile-0.05-3) (*) (*) 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 Math-Pari-2.01080606.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Math-Pari: 84cdf890a82f06a8fa1307ecea5db76c Math-Pari-2.01080606.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-Math-Pari] Update to 2.01080606
commit c2eb2b0df2f2a3701587d38400f55e3fafe03731
Author: Paul Howarth p...@city-fan.org
Date: Thu Apr 24 16:24:29 2014 +0100
Update to 2.01080606
- New upstream release 2.01080606
- Fixes for downloading pari and Windows builds
- Fix dubious permissions from upstream's tarball
.gitignore |2 +-
perl-Math-Pari.spec | 21 ++---
sources |2 +-
3 files changed, 16 insertions(+), 9 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index d8b8c6b..e25e863 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,2 @@
-/Math-Pari-2.01080605.tar.gz
+/Math-Pari-[0-9.]*.tar.gz
/pari-2.3.5.tar.gz
diff --git a/perl-Math-Pari.spec b/perl-Math-Pari.spec
index e7668b2..1aa0f7b 100644
--- a/perl-Math-Pari.spec
+++ b/perl-Math-Pari.spec
@@ -1,9 +1,9 @@
-%global extraversion 05
+%global extraversion 06
Summary: Perl interface to PARI
Name: perl-Math-Pari
Version: 2.010806
-Release: 20%{?dist}
+Release: 21%{?dist}
License: GPL+ or Artistic
Group: Development/Libraries
Url: http://search.cpan.org/dist/Math-Pari/
@@ -12,6 +12,7 @@ Patch0: Math-Pari-2.010802-no-fake-version.patch
Patch1:Math-Pari-2.010802-docs-and-testsuite.patch
Patch2:Math-Pari-2.01080605-include-path.patch
BuildRequires: libpari23-devel
+BuildRequires: perl
BuildRequires: perl(Carp)
BuildRequires: perl(Cwd)
BuildRequires: perl(Exporter)
@@ -31,14 +32,16 @@ scientific/ number-theoretic calculations. It allows use of
most PARI functions
as Perl functions, and (almost) seamless merging of PARI and Perl data.
%prep
-%setup -q -n Math-Pari-%{version}%{extraversion}
-
-# Remove spurious executable permission bits
-chmod -c -x Changes README Pari.pm PariInit.pm func_codes.h Pari.xs
+# Fix missing read permissions in upstream's tarball
+%setup -q -c -T -n Math-Pari-%{version}%{extraversion}
+cd ..
+tar xfz %{SOURCE0}
+%{_fixperms} Math-Pari-%{version}%{extraversion}
+cd Math-Pari-%{version}%{extraversion}
# Don't use a fake version number when we can use a real one
%patch0 -p1
-pari_int_version=$(pkg-config --modversion libpari23 | perl -pi -e
's/(\d+)\.(\d+)\.(\d+)/sprintf(%d%03d%03d,$1,$2,$3)/e')
+pari_int_version=$(pkg-config --modversion libpari23 | perl -p -e
's/(\d+)\.(\d+)\.(\d+)/sprintf(%d%03d%03d,$1,$2,$3)/e')
sed -i -e s/@@@OUR-PARI-VERSION@@@/${pari_int_version}/ Makefile.PL
# We want to build the docs and test suite too
@@ -78,6 +81,10 @@ make test
%exclude %{_mandir}/man3/Math::libPARI.dumb.3pm*
%changelog
+* Thu Apr 24 2014 Paul Howarth p...@city-fan.org - 2.010806-21
+- Update to 2.01080606 (fixes for downloading pari and Windows builds)
+- Fix dubious permissions from upstream's tarball
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.010806-20
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index 747b530..a45c21e 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ccb3da2bdce184a5df3f52cfa8b43a85 Math-Pari-2.01080605.tar.gz
+84cdf890a82f06a8fa1307ecea5db76c Math-Pari-2.01080606.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Pod-Markdown-2.001.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-Pod-Markdown: 26dbe72090775a9b3ada904a36d1995f Pod-Markdown-2.001.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
