Re: 2015-06-01 Fedora QA Devel Meeting Minutes
* tflink to pester jskladan Sorry about that, /me misread some old let's cancel the meeting email... ad Testdays: The Testday revamp is about half-done, as the process was interrupted by testing spree. I'm all in for 'killing' the old cloud machine, and I think it can be done ASAP. The new code will be ready long before the new cycle of Testdays, and it should be deployed by Ansible, as was mentioned during the meeting. ad git in Phab: I tend to agree with kparal - as long as it's quite easy to setup repos, I do not really care, where is the repo hosted - especially if Phab is able to push to remote repos, thus keeping the (IMO) more visible Bitbucket repos up to date. ad meeting time: I'm OK with the current time, I'll just need to be more careful with marking emails as read on my phone *facepalm* J. ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Fedora 22: cannot use rpmsign in script - problem with pinentry-gtk-2
On 2015-06-02, Pavel Lisý pavel.l...@gmail.com wrote: I've used rpmsign in script for long time. I worked fine. After upgrade to Fedora 22 (from Fedora 20) something changed [...] is starting now pinentry-gtk-2 and forces me to put passphrase to modal window. Is any possibility how to disable this behaviour? Whatever I've found through google didn't work for me. gnupg2 changed. Maybe you look for gpg-preset-passphrase tool https://www.gnupg.org/documentation/manuals/gnupg/gpg_002dpreset_002dpassphrase.html. Also the gpg-agent is not located by environment variables but by socket. And the gpg-agent will be spawned automatically if it does not run. Also handling password file descriptor behaves differently. See http://thread.gmane.org/gmane.comp.encryption.gpg.devel/19353/. -- 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
[Bug 1227175] fails to run with symbol lookup error: .../BibTeX.so: undefined symbol: Perl_Gthr_key_ptr
https://bugzilla.redhat.com/show_bug.cgi?id=1227175 --- Comment #4 from Petr Pisar ppi...@redhat.com --- (In reply to Petr Pisar from comment #3) (In reply to John Heidemann from comment #0) In addition, then I get conflicts on install file /usr/lib64/perl5/vendor_perl/Text from install of perl-Text-BibTeX-0.70-4.fc22.x86_64 conflicts with file from package perl-Text-Soundex-3.04-294.fc22.x86_64 This looks like the two packages disagree on mode or ownership of /usr/lib64/perl5/vendor_perl/Text directory. This is a packaging bug. The correct ownership should be root:root and mode 0755. I checked the two packages and they are fine. Even I can install both of them at the same time. I guess the packages are not genuine Fedora 22 packages. -- You are receiving this mail because: You are on the CC list for the bug. -- 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 1227175] fails to run with symbol lookup error: .../BibTeX.so: undefined symbol: Perl_Gthr_key_ptr
https://bugzilla.redhat.com/show_bug.cgi?id=1227175
--- Comment #5 from John Heidemann jo...@isi.edu ---
Thanks for the quick reply.
Sigh, you're correct. I should have seen it was /usr/local and so my fault. I
will close this as NOTABUG.
Wrt the conflict on /usr/lib64/perl5/vendor_perl/Text, Text::BibTeX's spec
calls %{_fixperms}. I don't know if that is The Right Thing or not. But I
will leave that for another ticket.
--
You are receiving this mail because:
You are on the CC list for the bug.
--
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
Re: F23 System Wide Change: Default Local DNS Resolver
Le Lun 1 juin 2015 21:25, Reindl Harald a écrit : surely there are many environments beside mine and *that* is why it's not smart to consider a local dns cache on each and every server There are many environments that benefit from a local DNS cache (for example FAI with flacky DNS, people will local cache have perfect service while others wonder why they are disconnected all the time), it can implement DNS features third party DNS miss (so apps don't have to deal with buggy DNSes), and anyone dealing with DNS ops MUST already factor TTLs in since many systems already use DNS caches. The braindamaged thing is to deal with DNS warts localy in all apps instead of using a central system-wide component that can get enough attention to be solid. Regards, -- Nicolas Mailhot -- 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: F23 System Wide Change: Default Local DNS Resolver
On 06/01/2015 10:57 PM, Andrew Lutomirski wrote: This is glibc we're talking about, though. Have you tried to get a glibc bug fixed? It's not a pleasant experience. It is possible, but it requires effort. Admittedly, sometimes that effort appears disproportionate to what is being fixed. In this particularly case, only *very* few people are familiar with resolv/, and test coverage for that part is extremely poor. For example, the bug I reported has a candidate patch. That patch isn't applied, and the patch looks like the bug might be a security issue. It's been in that state for months. This is not unusual for glibc. Can you explain why you think it is a security issue? In any case, the impact from accidentally triggering this bug seems more severe. Anyway, even on a LAN, the overhead of a network round trip per cacheable DNS query may be non-negligable for some use cases. A local caching resolver fixes that, too. Right, and it isolates resolvers from the impact of buggy application which enter an infinite loop if a service becomes unavailable (i.e., they do a new DNS lookup for each refused TCP connection). -- Florian Weimer / Red Hat Product Security -- 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: F23 System Wide Change: Default Local DNS Resolver
Ryan S. Brown rya...@redhat.com wrote: I disagree; for server cloud deployments it doesn't make sense to duplicate a DNS server on *every* host, and if you care about DNSSEC you likely already run a trusted resolver. The trust and management models for Server are fundamentally different from those of Workstation, since servers don't usually get tossed in a backpack and put on potentially-hostile coffee shop wi-fi. They also generally try to run fewer services than a workstation. The datacenter network is generally trusted, and a shared DNSSEC resolver makes way more sense. It may be beneficial from a security PoV to have DNSSEC resolution, but it isn't beneficial to have to patch 1 million copies of unbound if a vuln is discovered instead of just a few shared resolvers for the whole DC. Servers don't only exist in big datacenters where everything is managed by the same team of sysadmins. There are countless servers in homes and small offices around the world, connected to all sorts of more or less trustworthy networks. Some of my current customers have a single server in a collocation facility somewhere. Everything outside of the Ethernet port is managed by other people and shouldn't be trusted any more than necessary. In one of my previous jobs we had servers at multiple geographically separate collocation sites. At each site we'd rent a quarter-height rack with locked doors and install some five or so servers. The network inside the rack was trusted. Beyond the doors was the Internet. Installing redundant dedicated DNS resolvers at each site would have been overkill. The DNS servers we had were authoritative servers for our own domain. If we'd had DNSsec back then it would have made a lot of sense to validate locally on each server. For small offices and home users every little thing that needs to be configured is an additional burden, and chances are that they won't get around to learning how to configure a local validating resolver if it's not there by default. Big data centers, on the other hand, will have automated routines for installing new servers without configuring each one individually. If they choose to delegate the validation to a set of trusted DNS servers, then they can easily configure that in whatever central configuration tool they use, and be done with it. I'll refrain from saying anything about clouds and containers, but for the Server product, like for Workstation, common sense suggests that the default installation should assume as little as possible about its surroundings. It should definitely not assume that there won't ever be any adversaries in the local network when it doesn't know anything about the local network. There should therefore be a local validating DNS resolver by default, and good documentation on how to replace it with trusted external resolvers for those who want to do that. Björn Persson pgpyOjJq4gh_H.pgp Description: OpenPGP digital signatur -- 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: F23 System Wide Change: Default Local DNS Resolver
On 06/01/2015 09:33 PM, Reindl Harald wrote: Am 01.06.2015 um 21:28 schrieb Andrew Lutomirski: On Mon, Jun 1, 2015 at 12:25 PM, Ryan S. Brown rya...@redhat.com wrote: A local DNS resolver would certainly be a surprise to me. Again, this comes back to the expectation that a server isn't hopping networks or running somewhere un-trusted where there's a high risk of bad actors. It's not just bad actors. Sometimes things break or you need to reconfigure your upstream resolvers. With a local caching resolver, this Just Works (tm). With the status quo, it requires restarting everything WHAT - the opposite is true, Andrew is right, glibc caches the name server *settings* (/etc/resolv.conf contents), but not the responses received. The recommended workaround is to use nscd, but this has issues of its own. -- Florian Weimer / Red Hat Product Security -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 22: cannot use rpmsign in script - problem with pinentry-gtk-2
Hello
I've used rpmsign in script for long time. I worked fine. After upgrade to
Fedora 22 (from Fedora 20) something changed
This script:
- cut --
export LANG=cs_CZ.UTF-8
if [ -n $PASSPHRASE ] ; then
/usr/bin/expect -f - EOF
spawn rpmsign --addsign $RPMS_TO_SIGN
match_max 10
fork
expect Vložte heslovou frázi:
send -- ${PASSPHRASE}\r
expect eof
EOF
else
echo Set PASSPHRASE variable first
fi
- cut --
is starting now pinentry-gtk-2 and forces me to put passphrase to modal
window.
Is any possibility how to disable this behaviour? Whatever I've found
through google didn't work for me.
Do you use rpmsign in script?
Pavel
--
Pavel Lisý pavel.l...@gmail.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: Fedora 22: cannot use rpmsign in script - problem with pinentry-gtk-2
Petr, do you know if --passphrase-fd should still work? Because that is the way how rpm pass passphrase to gpg and it doesn't seem to work. Lubos - Original Message - From: Petr Pisar ppi...@redhat.com To: devel@lists.fedoraproject.org Sent: Tuesday, June 2, 2015 9:57:38 AM Subject: Re: Fedora 22: cannot use rpmsign in script - problem with pinentry-gtk-2 On 2015-06-02, Pavel Lisý pavel.l...@gmail.com wrote: I've used rpmsign in script for long time. I worked fine. After upgrade to Fedora 22 (from Fedora 20) something changed [...] is starting now pinentry-gtk-2 and forces me to put passphrase to modal window. Is any possibility how to disable this behaviour? Whatever I've found through google didn't work for me. gnupg2 changed. Maybe you look for gpg-preset-passphrase tool https://www.gnupg.org/documentation/manuals/gnupg/gpg_002dpreset_002dpassphrase.html. Also the gpg-agent is not located by environment variables but by socket. And the gpg-agent will be spawned automatically if it does not run. Also handling password file descriptor behaves differently. See http://thread.gmane.org/gmane.comp.encryption.gpg.devel/19353/. -- 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 22: cannot use rpmsign in script - problem with pinentry-gtk-2
Now, I see that, the answer is in the second link. - Original Message - From: Lubos Kardos lkar...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Tuesday, June 2, 2015 10:52:37 AM Subject: Re: Fedora 22: cannot use rpmsign in script - problem with pinentry-gtk-2 Petr, do you know if --passphrase-fd should still work? Because that is the way how rpm pass passphrase to gpg and it doesn't seem to work. Lubos - Original Message - From: Petr Pisar ppi...@redhat.com To: devel@lists.fedoraproject.org Sent: Tuesday, June 2, 2015 9:57:38 AM Subject: Re: Fedora 22: cannot use rpmsign in script - problem with pinentry-gtk-2 On 2015-06-02, Pavel Lisý pavel.l...@gmail.com wrote: I've used rpmsign in script for long time. I worked fine. After upgrade to Fedora 22 (from Fedora 20) something changed [...] is starting now pinentry-gtk-2 and forces me to put passphrase to modal window. Is any possibility how to disable this behaviour? Whatever I've found through google didn't work for me. gnupg2 changed. Maybe you look for gpg-preset-passphrase tool https://www.gnupg.org/documentation/manuals/gnupg/gpg_002dpreset_002dpassphrase.html. Also the gpg-agent is not located by environment variables but by socket. And the gpg-agent will be spawned automatically if it does not run. Also handling password file descriptor behaves differently. See http://thread.gmane.org/gmane.comp.encryption.gpg.devel/19353/. -- 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 -- 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: F23 System Wide Change: Default Local DNS Resolver
On Tue, 2 Jun 2015, Simo Sorce wrote: and just because you have a local resolver firefox won't stop it's behavior It can, w/o a local resolver FF developers will definitely keep caching on their own, with a decent local resolver they can allow themselves to disable their own and go back to rely on the system one, perhaps. I don't think so. Firefox does that to avoid DNS rebinding attacks. 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: F23 System Wide Change: Default Local DNS Resolver
Am 02.06.2015 um 19:49 schrieb Simo Sorce: On Mon, 2015-06-01 at 23:15 +0200, Reindl Harald wrote: a sane system should be as simple as possible so that *one* human is able to determine what is happening without hire 10 specialists for each layer There is no human able to understand a complex system like modern computers and OSs, it is just an illusion *because* more and more complexity is added with each release and then another layer of complexity is added in the next release to mask the impact on a stripped down Fedora 9 system the output of htop even on a notebook did fit on a screen without scrolling the whole purpose of Linux systems was to have open systems, open means also basically understandable and not just you can grab the source signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On 06/02/2015 06:44 PM, Paul Wouters wrote: On Tue, 2 Jun 2015, David Howells wrote: Install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. The automatic name server entries received via dhcp/vpn/wireless configurations should be stored separately (e.g. this is stored in the NetworkManager internal state), as transitory name servers to be used by the trusted local resolver. In all cases, DNSSEC validation will be done locally. How does this interact with dnsmasq which also wants to be the only name server entry in resolv.conf? dnsmasq is not the default entry in /etc/resolv.conf. It can be used with NM, but unbound can be, too. dnsmasq was integrated with NM sooner, since it didn't have DNSSEC support, which made a lot of corner cases and issues basically non-existing. Unbound it relatively simple and single purpose DNS resolver that was designed with DNSSEC in mind from the beginning... in comparison to dnsmasq. dnsmasq is a Swiss knife that is good for simple solutions hacked together with single component (since it supports DHCPv4/6, TFPT and also DNS+DNSSEC). Not well? The problem is dnsmasq is not as feature complete as unbound (and its dnssec implementation is very new). I agree, and as a previous maintainer of dnsmasq, I think unbound is better option. Although dnsmasq has a simple DBus API, it is mostly for DHCP. Also unbound has modular design and easy interface (unbound-control) enabling to reconfigure it dynamically. I think most people end up running dnsmasq because of KVM/libvirtd ? I think those dnsmasq's should be run in dhcp only mode and point to the hosts's unbound. Right. dnsmasq run by libvirtd uses the default configuration WRT resolv.conf. So it uses the servers from resolv.conf for resolution - which will be unbound. There are not conflicts between unbound running as local resolver and dnsmasq instances run by libvirtd. Tomas -- 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: F23 System Wide Change: Default Local DNS Resolver
On Tue, 2015-06-02 at 19:56 +0200, Reindl Harald wrote: Am 02.06.2015 um 19:49 schrieb Simo Sorce: On Mon, 2015-06-01 at 23:15 +0200, Reindl Harald wrote: a sane system should be as simple as possible so that *one* human is able to determine what is happening without hire 10 specialists for each layer There is no human able to understand a complex system like modern computers and OSs, it is just an illusion *because* more and more complexity is added with each release and then another layer of complexity is added in the next release to mask the impact on a stripped down Fedora 9 system the output of htop even on a notebook did fit on a screen without scrolling the whole purpose of Linux systems was to have open systems, open means also basically understandable and not just you can grab the source It would be nice if we were able to address complex problem always with simple solutions, but we are humans, and we are not generally capable to do that at the complexity level of a modern computer. The solution proposed in this thread addresses real problems and real pain. For the workstation product it is really a no-brainer, especially when installed on laptops. For server it also have notable advantages as others have eloquently illustrated. Then there are a few corner cases where things can go south. All considered the people that care for the Workstation and Server product generally thinks the advantages *greatly* outweigh the disadvantages in most situations and so a local resolver is seen as a good idea to have enabled by default. Not everyone can be pleased, and your points have actually already been discussed and pondered before multiple times, I've seen nothing new in your last messages. Can we please get productive and bring up new data, if any, or stop assaulting the list with I do not like it! kind of messages. We got that you do not like it, but we do not need to turn everything you do not like into a tragedy of the commons. Take a step back and put this into perspective please, and let people that specialize in DNS related matters do their job and trust their judgment once they explained to you the reasons why a change has been proposed. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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: F23 System Wide Change: Default Local DNS Resolver
On Tue, Jun 02, 2015 at 08:12:23PM +0200, Reindl Harald wrote: the whole purpose of Linux systems was to have open systems, open means also basically understandable and not just you can grab the source Linux is not, and has never been, UNIX your phrase has nothing to with the paragraph you quoted UNIX's primary goal was ease (and understandability) of implementation, even at the expense of performance or capability. the main idea auf GNU (you know what GNU means?) is a fully open and controllable system which is defeated by adding more and more complexity in default installs GNU's Not Unix -- And, I might add, Linux isn't GNU. Complexity has nothing to do with openness or controllability. Those exist on different axes, so please stop conflating them. again: if somebody wants the behavior of OSX he can go out and by an Apple machine - guess why i did not switch to Apple from Windows - just because i don't like the Apple philosophy Who said anything about OSX or Windows? Please, stick to the subject at hand. - Solomon -- Solomon Peachy pizza at shaftnet dot org Delray Beach, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum viditur. pgp3PvxJ4UUc1.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
spot pushed to perl-Test-MockModule (master). 0.10
From 7a76667abfabd2a2d14f3900f1c69632107fce98 Mon Sep 17 00:00:00 2001
From: Tom Callaway s...@fedoraproject.org
Date: Tue, 2 Jun 2015 14:23:17 -0400
Subject: 0.10
diff --git a/.gitignore b/.gitignore
index 94deb53..f7cb76c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
Test-MockModule-0.05.tar.gz
/Test-MockModule-0.09.tar.gz
+/Test-MockModule-0.10.tar.gz
diff --git a/perl-Test-MockModule.spec b/perl-Test-MockModule.spec
index 44becdb..5840651 100644
--- a/perl-Test-MockModule.spec
+++ b/perl-Test-MockModule.spec
@@ -1,5 +1,5 @@
Name: perl-Test-MockModule
-Version:0.09
+Version:0.10
Release:1%{?dist}
Summary:Override subroutines in a module for unit testing
Group: Development/Libraries
@@ -36,6 +36,9 @@ chmod -R u+w $RPM_BUILD_ROOT/*
%{_mandir}/man3/*.3*
%changelog
+* Tue Jun 2 2015 Tom Callaway s...@fedoraproject.org - 0.10-1
+- update to 0.10
+
* Fri Mar 27 2015 Tom Callaway s...@fedoraproject.org - 0.09-1
- update to 0.09
diff --git a/sources b/sources
index 0c215e3..154011a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-0006964fcda710fcf2832924cdb67546 Test-MockModule-0.09.tar.gz
+d931925162c3abc9f27df7f7b0335346 Test-MockModule-0.10.tar.gz
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Test-MockModule.git/commit/?h=masterid=7a76667abfabd2a2d14f3900f1c69632107fce98
--
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
Re: F23 System Wide Change: Default Local DNS Resolver
Am 02.06.2015 um 19:45 schrieb Simo Sorce: On Mon, 2015-06-01 at 21:44 +0200, Reindl Harald wrote: it don't cache dns respones - try it out in your local network *client applications* may cache respones try it out in your local network * enter a non existing subdomain in firefox * add the hostname to your LAN nameserver * try again: firefox refuses * restart just firefox * it resolves without any delay a) that proves no systemwide cachae b) it proves with introduce a local systemdwide cache you introduce a problem not existing before If you have nscd running glibc caches, so it is a matter of configuration. completly different topic if i install a local resolver and start it it caches - so what - the same for nscd which is not default, so you can't blame glibc because caching of an additional package The *only* reason why Firefox caches Names is because we do not have a local dns caching resolver, so Firefox had to implement its own. If you had a local caching resolver Firefox could be changed to stop caching on its own instead tell me one reason why *any* application has to cache DNS results at it's own - it don't matter at all if the machine has a local resolver/cache or not, it's not the business of any user application and just because you have a local resolver firefox won't stop it's behavior signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Tue, Jun 02, 2015 at 07:56:21PM +0200, Reindl Harald wrote: the whole purpose of Linux systems was to have open systems, open means also basically understandable and not just you can grab the source Linux is not, and has never been, UNIX. - Solomon -- Solomon Peachy pizza at shaftnet dot org Delray Beach, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum viditur. pgpggWR0B6rOS.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
spot uploaded Test-MockModule-0.10.tar.gz for perl-Test-MockModule
d931925162c3abc9f27df7f7b0335346 Test-MockModule-0.10.tar.gz http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Test-MockModule/Test-MockModule-0.10.tar.gz/d931925162c3abc9f27df7f7b0335346/Test-MockModule-0.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
Re: F23 System Wide Change: Default Local DNS Resolver
On Tue, 2015-06-02 at 19:51 +0200, Reindl Harald wrote: Am 02.06.2015 um 19:45 schrieb Simo Sorce: On Mon, 2015-06-01 at 21:44 +0200, Reindl Harald wrote: it don't cache dns respones - try it out in your local network *client applications* may cache respones try it out in your local network * enter a non existing subdomain in firefox * add the hostname to your LAN nameserver * try again: firefox refuses * restart just firefox * it resolves without any delay a) that proves no systemwide cachae b) it proves with introduce a local systemdwide cache you introduce a problem not existing before If you have nscd running glibc caches, so it is a matter of configuration. completly different topic if i install a local resolver and start it it caches - so what - the same for nscd which is not default, so you can't blame glibc because caching of an additional package If you knew what you are talkign about, you would know glibc's documentation tells you their recommended way to deal with changing resolv.conf files is to install and use nscd. So, yes, I can totally blame glibc as nscd is aprt of glibc and they recommend you run it. It is therefore the same topic. The *only* reason why Firefox caches Names is because we do not have a local dns caching resolver, so Firefox had to implement its own. If you had a local caching resolver Firefox could be changed to stop caching on its own instead tell me one reason why *any* application has to cache DNS results at it's own - it don't matter at all if the machine has a local resolver/cache or not, it's not the business of any user application Because at least user applications need to be quick, and can't give user a bad experience simply because the local DNS has gone out for lunch (which happens pretty consistently in home routers and end-user ISP netowrks), so apps end up doing what they can to avoid getting blamed by the user, that turns out to be: cache DNS replies. It doesn't matter whether you like it or not, this is the reality and we have to cope with reality not our desire of what reality should be. By adding a local caching resolver by default, then apps *by default* won't see DNS as a problem anymore and will stop implement half-ass-ed caching. Ultimately leading to the result you want in your case, apps will stop caching on their own, and when you remove the local resolver in your setup you'll be happy top observe the flooding of DNS requests w/o any application caching. You should be happy about this change I guess :) and just because you have a local resolver firefox won't stop it's behavior It can, w/o a local resolver FF developers will definitely keep caching on their own, with a decent local resolver they can allow themselves to disable their own and go back to rely on the system one, perhaps. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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: F23 System Wide Change: Default Local DNS Resolver
Am 02.06.2015 um 20:04 schrieb Solomon Peachy: On Tue, Jun 02, 2015 at 07:56:21PM +0200, Reindl Harald wrote: the whole purpose of Linux systems was to have open systems, open means also basically understandable and not just you can grab the source Linux is not, and has never been, UNIX your phrase has nothing to with the paragraph you quoted the main idea auf GNU (you know what GNU means?) is a fully open and controllable system which is defeated by adding more and more complexity in default installs again: if somebody wants the behavior of OSX he can go out and by an Apple machine - guess why i did not switch to Apple from Windows - just because i don't like the Apple philosophy signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Context menu icons in Gnome 3.16
Hi, I'm messing with an old gtk+ program, that I think it's dead upstream and I'm trying to see if I can resurrect it. Among other issues, it should add some entries to nautilus' context menus (which it does) but I can't get their icons to show. Then I noticed that I'm missing all of my context menu icons, even though they are enabled in gsettings. Is this a bug or a feature? -- 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: F23 System Wide Change: Default Local DNS Resolver
On Tue, 2 Jun 2015, David Howells wrote: I'm using dnsmasq to look up *.redhat.com addresses over VPN whilst looking up other addresses from my ISP. That is automatically handled for you if you use libreswan for your VPN and unbound is running. It will add a forward for the domain (redhat.com) received over the VPN to the received IP addresses of the nameservers. I've been running like that for years now. It even flushes the cache and request queue for related entries when you bring the VPN up and down, so things like bugzilla.redhat.com will work on the external IP or internal IP without you needing to do a thing. 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: F23 System Wide Change: Default Local DNS Resolver
Paul Wouters p...@nohats.ca wrote: I think most people end up running dnsmasq because of KVM/libvirtd ? I think those dnsmasq's should be run in dhcp only mode and point to the hosts's unbound. I'm using dnsmasq to look up *.redhat.com addresses over VPN whilst looking up other addresses from my ISP. David -- 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 1226496] perl-PDL-2.011 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1226496 --- Comment #4 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Failed to kick off scratch build. spectool was unable to grab new sources old source: PDL-2.008.tar.gz old sha256: 44f1246ee5fb6f7252870aa0afe11f3c05d7e5c70bfdf5677fa20da19212d9b8 new source: ./PDL-2.008.tar.gz new sha256: 44f1246ee5fb6f7252870aa0afe11f3c05d7e5c70bfdf5677fa20da19212d9b8 -- You are receiving this mail because: You are on the CC list for the bug. -- 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 1226496] perl-PDL-2.011 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1226496 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-PDL-2.009 is available |perl-PDL-2.011 is available --- Comment #3 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 2.011 Current version/release in rawhide: 2.8.0-1.fc23 URL: http://search.cpan.org/dist/PDL/ 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 Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. -- You are receiving this mail because: You are on the CC list for the bug. -- 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
Re: New ABRT CLI
On Tue, 2015-06-02 at 15:45 +0200, Richard Marko wrote: Hi, over last two weeks I completely rewrote abrt-cli to make life easier for users and developers. It now supports tab completion and few new commands like abrt gdb and abrt debuginfo-install. Without any arguments these commands will use the last crash that occurred on your system. Ooooh, 'abrt gdb' in particular sounds like fun. :) Michael -- 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 1227546] perl-Test-Run-CmdLine-0.0127 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1227546 --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Created attachment 1034088 -- https://bugzilla.redhat.com/attachment.cgi?id=1034088action=edit [patch] Update to 0.0127 (#1227546) -- You are receiving this mail because: You are on the CC list for the bug. -- 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 1227546] New: perl-Test-Run-CmdLine-0.0127 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1227546 Bug ID: 1227546 Summary: perl-Test-Run-CmdLine-0.0127 is available Product: Fedora Version: rawhide Component: perl-Test-Run-CmdLine Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com Latest upstream release: 0.0127 Current version/release in rawhide: 0.0126-1.fc23 URL: http://search.cpan.org/dist/Test-Run-CmdLine/ 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 Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. -- You are receiving this mail because: You are on the CC list for the bug. -- 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 1227546] perl-Test-Run-CmdLine-0.0127 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1227546 --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Scratch build succeeded http://koji.fedoraproject.org/koji/taskinfo?taskID=9924192 -- You are receiving this mail because: You are on the CC list for the bug. -- 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
Re: gcc5 C++11 ABI rebuilds and FTBFS packages
On Wed, May 6, 2015 at 9:10 AM, Dave Johansen davejohan...@gmail.com wrote: On Mon, May 4, 2015 at 4:09 AM, Kalev Lember kalevlem...@gmail.com wrote: iwyu: http://koji.fedoraproject.org/koji/taskinfo?taskID=9651015 A clang/llvm 3.6 compatible version of include-what-you-use (iwyu) hasn't been released yet. Once that's available, I will update iwyu and rebuild. iwyu has been updated to 0.4 and rebuilt: http://koji.fedoraproject.org/koji/taskinfo?taskID=9924511 -- 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 1139700] CVE-2014-4330 perl-Data-Dumper: deep recursion stack overflow
https://bugzilla.redhat.com/show_bug.cgi?id=1139700 Tomas Hoger tho...@redhat.com changed: What|Removed |Added Whiteboard|impact=low,public=20140918, |impact=low,public=20140918, |reported=20140909,source=up |reported=20140909,source=up |stream,cvss2=2.6/AV:N/AC:H/ |stream,cvss2=2.6/AV:N/AC:H/ |Au:N/C:N/I:N/A:P,cwe=CWE-67 |Au:N/C:N/I:N/A:P,cwe=CWE-67 |4,rhel-4/perl=wontfix,rhel- |4,rhel-4/perl=wontfix,rhel- |5/perl=wontfix,rhel-6/perl= |5/perl=wontfix,rhel-6/perl= |defer,rhel-7/perl=notaffect |defer,rhel-7/perl=notaffect |ed,fedora-all/perl=notaffec |ed,fedora-all/perl=notaffec |ted,rhel-7/perl-Data-Dumper |ted,rhel-7/perl-Data-Dumper |=defer,rhscl-1/perl516-perl |=defer,rhscl-2/perl516-perl |-Data-Dumper=defer,fedora-a |-Data-Dumper=defer,rhscl-2/ |ll/perl-Data-Dumper=affecte |rh-perl520-perl-Data-Dumper |d |=notaffected,fedora-all/per ||l-Data-Dumper=affected -- You are receiving this mail because: You are on the CC list for the bug. -- 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
jplesnik pushed to perl-podlinkcheck (master). Disable optional BR Devel::FindRef for Perl 5.22
From 349c163412559c88cde60bfae763da32118e0108 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova jples...@redhat.com
Date: Tue, 2 Jun 2015 14:10:26 +0200
Subject: Disable optional BR Devel::FindRef for Perl 5.22
diff --git a/perl-podlinkcheck.spec b/perl-podlinkcheck.spec
index 2bc9305..0e14f69 100644
--- a/perl-podlinkcheck.spec
+++ b/perl-podlinkcheck.spec
@@ -1,6 +1,6 @@
Name: perl-podlinkcheck
Version:12
-Release:5%{?dist}
+Release:6%{?dist}
Summary:Check Perl POD L link references
License:GPLv3+
Group: Development/Libraries
@@ -33,7 +33,10 @@ BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Test::More)
# Optional tests:
BuildRequires: perl(Data::Dumper)
+# Disable BR Devel::FindRef, because it does not built with Perl 5.22
+%if ! 0%(perl -e 'print $] = 5.022')
BuildRequires: perl(Devel::FindRef)
+%endif
BuildRequires: perl(Devel::StackTrace)
BuildRequires: perl(File::HomeDir)
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
@@ -78,6 +81,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Jun 02 2015 Jitka Plesnikova jples...@redhat.com - 12-6
+- Disable optional BR Devel::FindRef for Perl 5.22
+
* Wed Aug 27 2014 Jitka Plesnikova jples...@redhat.com - 12-5
- Perl 5.20 rebuild
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-podlinkcheck.git/commit/?h=masterid=349c163412559c88cde60bfae763da32118e0108
--
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
default btrfs partitioning setup
I have an older setup created by anaconda from 2013, and it looks like UUID=7246327b-1905-4fe2-9b6b-b9376017264f / btrfs subvolid=5,subvol=root00 0 0 UUID=2c04be93-34c1-4016-ba41-60fd9fd90616 /boot ext4 defaults1 2 UUID=7246327b-1905-4fe2-9b6b-b9376017264f /home btrfs subvol=home 0 0 So we have only 1 disk. There is 1 btrfs partition, but root and home are 2 different btrfs subvolumes. This is a good setup IMO, since I can reinstall the OS without touching home. I recently got a laptop and did F21 install using btrfs, and I believe I used automatic partitioning. This time, I got just 1 btrfs subvol with home as a subdir, which does not offer the flexibility. I suggest the default for btrfs should be as shown above, with home on a separate subvol. -- Those who fail to understand recursion are doomed to repeat it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
jplesnik pushed to perl-POE-Component-SSLify (master). Disable using of Test::Apocalypse
From 7dbb05d750aecc869a51eff4cace4f942b812da5 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova jples...@redhat.com
Date: Tue, 2 Jun 2015 13:32:39 +0200
Subject: Disable using of Test::Apocalypse
diff --git a/perl-POE-Component-SSLify.spec b/perl-POE-Component-SSLify.spec
index f328fab..08ebf33 100644
--- a/perl-POE-Component-SSLify.spec
+++ b/perl-POE-Component-SSLify.spec
@@ -1,6 +1,6 @@
Name: perl-POE-Component-SSLify
Version:1.012
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Makes using SSL in the world of POE easy!
License:GPL+ or Artistic
Group: Development/Libraries
@@ -37,7 +37,11 @@ BuildRequires: perl(Test::More) = 1.001002
# Optional tests:
# CPAN::Meta not usefull
BuildRequires: perl(IO::Prompt::Tiny)
+# Disable using of Test::Apocalypse, because it cannot be built with Perl 5.22
+# due to failing perl-Test-Vars
+%if ! 0%(perl -e 'print $] = 5.022')
BuildRequires: perl(Test::Apocalypse) = 1.000
+%endif
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(POE) = 1.267
Requires: perl(warnings)
@@ -75,6 +79,9 @@ AUTOMATED_TESTING=0 ./Build test
%{_mandir}/man3/*
%changelog
+* Tue Jun 02 2015 Jitka Plesnikova jples...@redhat.com - 1.012-3
+- Disable using of Test::Apocalypse
+
* Mon May 18 2015 Petr Pisar ppi...@redhat.com - 1.012-2
- Do not use SSLv3 in tests
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-POE-Component-SSLify.git/commit/?h=masterid=7dbb05d750aecc869a51eff4cace4f942b812da5
--
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
jplesnik pushed to perl-Math-NumSeq (master). Disable optional BR Devel::FindRef
From 121f390b30c6c740d152987eb1d365e077eea510 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova jples...@redhat.com
Date: Tue, 2 Jun 2015 13:48:44 +0200
Subject: Disable optional BR Devel::FindRef
diff --git a/perl-Math-NumSeq.spec b/perl-Math-NumSeq.spec
index ea7e16e..9cd0231 100644
--- a/perl-Math-NumSeq.spec
+++ b/perl-Math-NumSeq.spec
@@ -1,6 +1,6 @@
Name: perl-Math-NumSeq
Version:71
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Number sequences
License:GPLv3+
Group: Development/Libraries
@@ -15,7 +15,10 @@ BuildRequires: perl(constant::defer) = 1
BuildRequires: perl(Carp)
BuildRequires: perl(Cwd)
BuildRequires: perl(Data::Dumper)
+# Disable optional BR Devel::FindRef, because it does not built with Perl 5.22
+%if ! 0%(perl -e 'print $] = 5.022')
BuildRequires: perl(Devel::FindRef)
+%endif
BuildRequires: perl(Devel::StackTrace)
BuildRequires: perl(Exporter)
BuildRequires: perl(ExtUtils::MakeMaker)
@@ -96,6 +99,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Jun 02 2015 Jitka Plesnikova jples...@redhat.com - 71-3
+- Disable optional BR Devel::FindRef for Perl 5.22
+
* Fri Aug 29 2014 Jitka Plesnikova jples...@redhat.com - 71-2
- Perl 5.20 rebuild
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Math-NumSeq.git/commit/?h=masterid=121f390b30c6c740d152987eb1d365e077eea510
--
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 1227175] fails to run with symbol lookup error: .../BibTeX.so: undefined symbol: Perl_Gthr_key_ptr
https://bugzilla.redhat.com/show_bug.cgi?id=1227175 --- Comment #7 from Colin Macdonald c...@m.fsf.org --- Oops notice that Petr also cannot reproduce. So if you can reliably reproduce with Fedora packages, then file another bug :-) -- You are receiving this mail because: You are on the CC list for the bug. -- 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
Re: Reviving Fedora MIPS
On Mon, Jun 01, 2015 at 10:10:17PM +0200, Michal Toman wrote: Apart from mips64el, we have lately started working on 32-bit mipsel, to be ran on the Creator CI20 Borad [4]. This is basically 3 months behind mips64el so there are no significant results yet, but hopefully will be soon. I have the Creator CI20 board. Does this mean ImgTec are going to bring out a 64 bit development board :-? I guess you won't be able to tell me .. Anyway my CI20 is currently running Debian, but I'll give Fedora a go when I have the time. Any help would be appreciated, especially in the area of kernel, u-boot and some specific languages - haskell, erlang, ocaml etc. I have already been playing with some of those and there is a list of issues on the wiki. There's no OCaml 32 bit MIPS backend upstream, but there used to be one. An older version of it can be found here: https://github.com/retired-camels/ocaml Claims to support BE and LE and uses the n32 ABI, whatever that means. It would require a certain amount of work to bring that up to date, but it's not impossible. As far as I can tell there is no 64 bit MIPS backend at all and never has been. Depending on how different 32 bit and 64 bit MIPS are that might be a lot of work to implement. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
jplesnik uploaded perl-5.22.0.tar.bz2 for perl
f67b152160431b3180fb766bdc2d02e2 perl-5.22.0.tar.bz2 http://pkgs.fedoraproject.org/lookaside/pkgs/perl/perl-5.22.0.tar.bz2/f67b152160431b3180fb766bdc2d02e2/perl-5.22.0.tar.bz2 -- 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
Re: Reviving Fedora MIPS
On Mon, Jun 1, 2015 at 4:10 PM, Michal Toman michal.to...@gmail.com wrote: Greetings everyone, you might know me from my former work on ABRT, or later Power and s390. For the last few months however, I have been collaborating with Imagination Technologies to bring back Fedora for MIPS. A brief history - some effort to bootstrap Fedora for MIPS has been done around Fedora 11/12/13, but died afterwards because of lack of interest. Even though the RPMs were labelled with mips64el architecture, they were using the hybrid n32 ABI with 32-bit pointers and 64-bit data, rather than the full 64-bit n64 ABI. Since we decided to go with n64 rather than n32, we have tried to bootstrap the distribution from scratch (well, almost) to see how much problems we will run into. I need to say that I was very surprised that a majority of packages build fine with no or just minor tweaks to specfiles and very few packages do require actual code patching. Anyway, we have now arrived into a state where Fedora mips64el userspace can be booted and played with. I have created a QEMU image [1] and all the packages and repositories are available from mipsfedora.imgtec.com [2]. I have also created some wiki pages [3] briefly describing what we are doing and will continue to expand them in the following days to be more detailed. Apart from mips64el, we have lately started working on 32-bit mipsel, to be ran on the Creator CI20 Borad [4]. This is basically 3 months behind mips64el so there are no significant results yet, but hopefully will be soon. Future plans are, naturally, to turn MIPS into a fully-fledged secondary architecture, deploy koji-shadow, compose releases and do everything other secondary archs do. Build hardware is likely to be donated by Imagination Technologies. Any help would be appreciated, especially in the area of kernel, u-boot and some specific languages - haskell, erlang, ocaml etc. I have already been playing with some of those and there is a list of issues on the wiki. Hopefully you will like Fedora MIPS back Regards, Michal [1] http://mipsfedora.imgtec.com/development/22/mips64el/images/20150601/ [2] http://mipsfedora.imgtec.com/development/22/mips64el/ [3] https://fedoraproject.org/wiki/Architectures/MIPS/2015Bootstrap [4] http://community.imgtec.com/platforms/creator-ci20/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct I'm very pleased to see Fedora MIPS make a return. While I personally do not own any MIPS hardware at this time, I'd definitely love to play with Fedora MIPS if I can get some hardware to use. -- 真実はいつも一つ！/ Always, there's only one truth! -- 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 1227175] fails to run with symbol lookup error: .../BibTeX.so: undefined symbol: Perl_Gthr_key_ptr
https://bugzilla.redhat.com/show_bug.cgi?id=1227175 Colin Macdonald c...@m.fsf.org changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |NOTABUG Last Closed||2015-06-02 08:17:02 --- Comment #6 from Colin Macdonald c...@m.fsf.org --- I cannot reproduce the conflict. Can you file another bug and explain how to see it? Thanks. -- You are receiving this mail because: You are on the CC list for the bug. -- 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
jplesnik pushed to perl-MouseX-SimpleConfig (master). Disable using of Test::Vars with Perl 5.22
From bc98f5a5efe6e3d22a53b72cf3f4ef162983afb1 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova jples...@redhat.com
Date: Tue, 2 Jun 2015 16:14:35 +0200
Subject: Disable using of Test::Vars with Perl 5.22
diff --git a/perl-MouseX-SimpleConfig.spec b/perl-MouseX-SimpleConfig.spec
index 5c5dd50..38175ac 100644
--- a/perl-MouseX-SimpleConfig.spec
+++ b/perl-MouseX-SimpleConfig.spec
@@ -4,7 +4,7 @@
Name: perl-MouseX-SimpleConfig
Summary: A Mouse role for setting attributes from a simple configfile
Version: 0.11
-Release: 5%{?dist}
+Release: 6%{?dist}
License: GPL+ or Artistic
URL: http://search.cpan.org/dist/MouseX-SimpleConfig/
Source0:
http://search.cpan.org/CPAN/authors/id/M/MJ/MJGARDNER/MouseX-SimpleConfig-%{version}.tar.gz
@@ -49,7 +49,11 @@ BuildRequires: perl(Test::NoTabs)
BuildRequires: perl(Test::Pod) = 1.41
BuildRequires: perl(Test::Pod::Coverage) = 1.08
BuildRequires: perl(Test::Portability::Files)
+# Disable using of Test::Vars, because it fails with Perl 5.22.0
+# There is not a properly fix for it yet
+%if ! 0%(perl -e 'print $] = 5.022')
BuildRequires: perl(Test::Vars)
+%endif
# Runtime
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
@@ -85,6 +89,9 @@ make test RELEASE_TESTING=1
%{_mandir}/man3/MouseX::SimpleConfig.3*
%changelog
+* Tue Jun 02 2015 Jitka Plesnikova jples...@redhat.com - 0.11-6
+- Disable using of Test::Vars with Perl 5.22
+
* Tue Sep 02 2014 Jitka Plesnikova jples...@redhat.com - 0.11-5
- Perl 5.20 rebuild
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-MouseX-SimpleConfig.git/commit/?h=masterid=bc98f5a5efe6e3d22a53b72cf3f4ef162983afb1
--
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
Fedora 22 for POWER is here!
We are proud to announce the official release of Fedora 22 for POWER, the community-driven and community-built operating system now available in Cloud and Server editions. If that's all you need to hear, jump over to Get Fedora to download -- or for current users, run the FedUp upgrade tool. * https://fedoraproject.org/wiki/PowerPC/F22/Installation * https://fedoraproject.org/wiki/FedUp In addition to the latest versions of all your favorite free and open source software, Fedora 22 marks our second release with distinctly-targeted offerings for cloud computing, and the server room. Thanks to the hard work of developers, designers, packagers, translators, testers, documentation writers, and everyone else, we're incredibly confident in saying that this is our best and most polished release yet. Also with this release, we return to our traditional six-month cadence -- we'll see you back here sometime around Halloween! Highlights in the Fedora 22 release === Every Fedora release has its own character. If this release had a human analogue, it'd be Fedora 21 after it'd been to college, landed a good job, and kept its New Year's Resolution to go to the gym on a regular basis. What we're saying is that Fedora 22 has built on the foundation we laid with Fedora 21 and the work to create distinct editions of Fedora focused on the desktop, server, and cloud (respectively). It's not radically different, but there are a fair amount of new features coupled with features we've already introduced but have improved for Fedora 22. Fedora Cloud The Fedora 22 Cloud edition has debuted for POWER in this release. In it's first release there are base cloud images that should be of interest to users and developers. * Fedora cloud base edition for qcow2 and raw images. Fedora Server - * Database Server Role -- The Fedora Server edition focuses on easy of different server roles. Fedora 21 debuted with an Domain Controller Role featuring FreeIPA. For this release, we've added a Database Server role, built around PostgreSQL. * Default to XFS filesystem -- The default file system type for Fedora Server installs will be XFS running atop LVM for all partitions except /boot. The /boot partition will remain a non-LVM, ext4 partition due to technological limitations of the bootloader. * Cockpit will be compatible between OS releases -- Cockpit is a server manager that makes it easy to administer your GNU/Linux servers via a web browser. - Easy to use. Cockpit is perfect for new sysadmins, allowing them to easily perform simple tasks such as storage administration, inspecting journals and starting and stopping services. - No interference. Jumping between the terminal and the web tool is no problem. A service started via Cockpit can be stopped via the terminal. Likewise, if an error occurs in the terminal, it can be seen in the Cockpit journal interface. - Multi-server. You can monitor and administer several servers at the same time. Other changes of note = Faster and better dependency management with DNF With Fedora 22, we're introducing a major change under the hood. Specifically, we're now using DNF and hawkey to manage packages. DNF is much like the Yum software package manager (it's largely command-line compatible), but re-written and re-engineered to provide optimal performance and (along with Hawkey) provide a strict API definition for plugins and extending projects. DNF also makes use of the libsolv library initially pioneered by the openSUSE Project to provide faster and better dependency management. It also boasts a better performance and memory footprint vs. Yum, and is designed to have a cleaner codebase and be easier to maintain. If you're using the Fedora 22 Workstation edition, and managing packages with the Software Application, odds are you won't notice a difference. Server and Cloud users who fall back on Yum commands will receive a reminder (courtesy of dnf-yum) that Yum is deprecated and DNF is now the default package manager. DNF has been in development for quite some time, so we're confident it's ready for prime time. The classic Yum command line tool has been renamed to yum-deprecated as a transitional step for tools still using it. See Read The Docs for compatibility changes from Yum to DNF in detail. GNU Compiler Collection 5 - Fedora 22 comes with GCC 5.1 as the primary compiler suite. Downloads, upgrades, documentation, and common bugs == You can start by downloading Fedora 22: * https://fedoraproject.org/wiki/PowerPC/F22/Installation If you are upgrading from a previous release of Fedora, refer to: * http://fedoraproject.org/wiki/Upgrading Fedora's FedUp utility enables an easy upgrade to Fedora 22 from previous releases. See the FedUp
[Bug 1227122] perl-Date-Manip-6.50 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1227122 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- perl-Date-Manip-6.50-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/perl-Date-Manip-6.50-1.fc22 -- You are receiving this mail because: You are on the CC list for the bug. -- 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
Fedora 22 for POWER is here!
We are proud to announce the official release of Fedora 22 for POWER, the community-driven and community-built operating system now available in Cloud and Server editions. If that's all you need to hear, jump over to Get Fedora to download -- or for current users, run the FedUp upgrade tool. * https://fedoraproject.org/wiki/PowerPC/F22/Installation * https://fedoraproject.org/wiki/FedUp In addition to the latest versions of all your favorite free and open source software, Fedora 22 marks our second release with distinctly-targeted offerings for cloud computing, and the server room. Thanks to the hard work of developers, designers, packagers, translators, testers, documentation writers, and everyone else, we're incredibly confident in saying that this is our best and most polished release yet. Also with this release, we return to our traditional six-month cadence -- we'll see you back here sometime around Halloween! Highlights in the Fedora 22 release === Every Fedora release has its own character. If this release had a human analogue, it'd be Fedora 21 after it'd been to college, landed a good job, and kept its New Year's Resolution to go to the gym on a regular basis. What we're saying is that Fedora 22 has built on the foundation we laid with Fedora 21 and the work to create distinct editions of Fedora focused on the desktop, server, and cloud (respectively). It's not radically different, but there are a fair amount of new features coupled with features we've already introduced but have improved for Fedora 22. Fedora Cloud The Fedora 22 Cloud edition has debuted for POWER in this release. In it's first release there are base cloud images that should be of interest to users and developers. * Fedora cloud base edition for qcow2 and raw images. Fedora Server - * Database Server Role -- The Fedora Server edition focuses on easy of different server roles. Fedora 21 debuted with an Domain Controller Role featuring FreeIPA. For this release, we've added a Database Server role, built around PostgreSQL. * Default to XFS filesystem -- The default file system type for Fedora Server installs will be XFS running atop LVM for all partitions except /boot. The /boot partition will remain a non-LVM, ext4 partition due to technological limitations of the bootloader. * Cockpit will be compatible between OS releases -- Cockpit is a server manager that makes it easy to administer your GNU/Linux servers via a web browser. - Easy to use. Cockpit is perfect for new sysadmins, allowing them to easily perform simple tasks such as storage administration, inspecting journals and starting and stopping services. - No interference. Jumping between the terminal and the web tool is no problem. A service started via Cockpit can be stopped via the terminal. Likewise, if an error occurs in the terminal, it can be seen in the Cockpit journal interface. - Multi-server. You can monitor and administer several servers at the same time. Other changes of note = Faster and better dependency management with DNF With Fedora 22, we're introducing a major change under the hood. Specifically, we're now using DNF and hawkey to manage packages. DNF is much like the Yum software package manager (it's largely command-line compatible), but re-written and re-engineered to provide optimal performance and (along with Hawkey) provide a strict API definition for plugins and extending projects. DNF also makes use of the libsolv library initially pioneered by the openSUSE Project to provide faster and better dependency management. It also boasts a better performance and memory footprint vs. Yum, and is designed to have a cleaner codebase and be easier to maintain. If you're using the Fedora 22 Workstation edition, and managing packages with the Software Application, odds are you won't notice a difference. Server and Cloud users who fall back on Yum commands will receive a reminder (courtesy of dnf-yum) that Yum is deprecated and DNF is now the default package manager. DNF has been in development for quite some time, so we're confident it's ready for prime time. The classic Yum command line tool has been renamed to yum-deprecated as a transitional step for tools still using it. See Read The Docs for compatibility changes from Yum to DNF in detail. GNU Compiler Collection 5 - Fedora 22 comes with GCC 5.1 as the primary compiler suite. Downloads, upgrades, documentation, and common bugs == You can start by downloading Fedora 22: * https://fedoraproject.org/wiki/PowerPC/F22/Installation If you are upgrading from a previous release of Fedora, refer to: * http://fedoraproject.org/wiki/Upgrading Fedora's FedUp utility enables an easy upgrade to Fedora 22 from previous releases. See the FedUp
Re: Fedora.next PRD refresh
On Tue, Jun 02, 2015 at 09:08:05AM -0400, Stephen Gallagher wrote: I am just curious why it would not be held from this year? because of time constrains? We had already communicated to several groups that we wanted to refresh it before Alpha this cycle (Cloud in particular had moved far from its original PRD). We decided to keep that plan and adjust the future. And, yeah, it's really too late to be putting more demands on this year's Flock. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20150602 changes
Compose started at Tue Jun 2 05:15:03 UTC 2015 Broken deps for i386 -- [OpenTK] OpenTK-1.1-1.4c.fc22.noarch requires mono(mscorlib) = 0:2.0.0.0 OpenTK-1.1-1.4c.fc22.noarch requires mono(System.Xml) = 0:2.0.0.0 OpenTK-1.1-1.4c.fc22.noarch requires mono(System.Windows.Forms) = 0:2.0.0.0 OpenTK-1.1-1.4c.fc22.noarch requires mono(System.Drawing) = 0:2.0.0.0 OpenTK-1.1-1.4c.fc22.noarch requires mono(System) = 0:2.0.0.0 [RepetierHost] RepetierHost-0.90D-2.fc21.noarch requires mono(mscorlib) = 0:2.0.0.0 RepetierHost-0.90D-2.fc21.noarch requires mono(System.Xml) = 0:2.0.0.0 RepetierHost-0.90D-2.fc21.noarch requires mono(System.Windows.Forms) = 0:2.0.0.0 RepetierHost-0.90D-2.fc21.noarch requires mono(System.Drawing) = 0:2.0.0.0 RepetierHost-0.90D-2.fc21.noarch requires mono(System.Core) = 0:3.5.0.0 RepetierHost-0.90D-2.fc21.noarch requires mono(System) = 0:2.0.0.0 [ambari] ambari-server-1.5.1-3.fc22.noarch requires mvn(com.sun.jersey:jersey-server) ambari-server-1.5.1-3.fc22.noarch requires mvn(com.sun.jersey:jersey-json) ambari-server-1.5.1-3.fc22.noarch requires mvn(com.sun.jersey:jersey-client) ambari-server-1.5.1-3.fc22.noarch requires mvn(com.sun.jersey.contribs:jersey-multipart) ambari-server-1.5.1-3.fc22.noarch requires mvn(com.sun.jersey.contribs:jersey-guice) ambari-views-1.5.1-3.fc22.noarch requires mvn(com.sun.jersey:jersey-core) [bless] bless-0.6.0-14.fc22.i686 requires mono(mscorlib) = 0:2.0.0.0 bless-0.6.0-14.fc22.i686 requires mono(System.Xml) = 0:2.0.0.0 bless-0.6.0-14.fc22.i686 requires mono(System) = 0:2.0.0.0 bless-0.6.0-14.fc22.i686 requires mono(Mono.Posix) = 0:2.0.0.0 [boo] boo-0.9.4.9-11.fc22.i686 requires mono(mscorlib) = 0:2.0.0.0 boo-0.9.4.9-11.fc22.i686 requires mono(System.Xml) = 0:2.0.0.0 boo-0.9.4.9-11.fc22.i686 requires mono(System.Core) = 0:3.5.0.0 boo-0.9.4.9-11.fc22.i686 requires mono(System) = 0:2.0.0.0 boo-0.9.4.9-11.fc22.i686 requires mono(Microsoft.Build.Utilities) = 0:2.0.0.0 boo-0.9.4.9-11.fc22.i686 requires mono(Microsoft.Build.Tasks) = 0:2.0.0.0 boo-0.9.4.9-11.fc22.i686 requires mono(Microsoft.Build.Framework) = 0:2.0.0.0 boo-devel-0.9.4.9-11.fc22.i686 requires mono(mscorlib) = 0:2.0.0.0 boo-devel-0.9.4.9-11.fc22.i686 requires mono(System.Xml) = 0:2.0.0.0 boo-devel-0.9.4.9-11.fc22.i686 requires mono(System.Core) = 0:3.5.0.0 boo-devel-0.9.4.9-11.fc22.i686 requires mono(System) = 0:2.0.0.0 boo-devel-0.9.4.9-11.fc22.i686 requires mono(NAnt.DotNetTasks) = 0:0.90.3780.0 boo-devel-0.9.4.9-11.fc22.i686 requires mono(NAnt.Core) = 0:0.90.3780.0 [dmlite-plugins-memcache] dmlite-plugins-memcache-0.5.0-7.fc20.i686 requires libprotobuf.so.8 [hadoop] hadoop-common-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-servlet) hadoop-common-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-common-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hadoop-common-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hadoop-hdfs-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-hdfs-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hadoop-mapreduce-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-mapreduce-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey.contribs:jersey-guice) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-servlet) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-client) hadoop-tests-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey.contribs:jersey-guice) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey:jersey-client) hadoop-yarn-2.4.1-8.fc22.noarch requires mvn(com.sun.jersey.contribs:jersey-guice) [hbase] hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-json) hbase-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-core) hbase-tests-0.98.3-4.fc22.noarch requires mvn(com.sun.jersey:jersey-server) hbase-tests-0.98.3-4.fc22.noarch requires
[Bug 1227122] perl-Date-Manip-6.50 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1227122 --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-Date-Manip-6.50-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/perl-Date-Manip-6.50-1.fc21 -- You are receiving this mail because: You are on the CC list for the bug. -- 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
jplesnik pushed to perl-Software-License-CCpack (master). Disable using of Test::Vars with Perl 5.22
From df7d44b9f69c07c85cc6db4d811cb6849f509483 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova jples...@redhat.com
Date: Tue, 2 Jun 2015 16:02:13 +0200
Subject: Disable using of Test::Vars with Perl 5.22
diff --git a/perl-Software-License-CCpack.spec
b/perl-Software-License-CCpack.spec
index 1b9b568..c622898 100644
--- a/perl-Software-License-CCpack.spec
+++ b/perl-Software-License-CCpack.spec
@@ -5,7 +5,7 @@
Name: perl-Software-License-CCpack
Version: 1.11
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: Software::License pack for Creative Commons' licenses
License: LGPLv3
URL: http://search.cpan.org/dist/Software-License-CCpack/
@@ -40,7 +40,11 @@ BuildRequires: perl(Test::Pod) = 1.41
BuildRequires: perl(Test::Pod::Coverage) = 1.08
BuildRequires: perl(Test::Portability::Files)
BuildRequires: perl(Test::Synopsis)
+# Disable using of Test::Vars, because it fails with Perl 5.22.0
+# There is not a properly fix for it yet
+%if ! 0%(perl -e 'print $] = 5.022')
BuildRequires: perl(Test::Vars)
+%endif
# Runtime
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
@@ -101,6 +105,9 @@ make test TEST_FILES=$(echo $(find xt/ -name '*.t'))
RELEASE_TESTING=1
%{_mandir}/man3/Software::License::CC_PDM_1_0.3*
%changelog
+* Tue Jun 02 2015 Jitka Plesnikova jples...@redhat.com - 1.11-2
+- Disable using of Test::Vars with Perl 5.22
+
* Mon Oct 20 2014 Paul Howarth p...@city-fan.org - 1.11-1
- Update to 1.11
- Include all versions of licenses, including the new 4.0 ones
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Software-License-CCpack.git/commit/?h=masterid=df7d44b9f69c07c85cc6db4d811cb6849f509483
--
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 1206915] Segfault during upgrade; Segmentation fault (core dumped) perl -MXML::SAX -e XML::SAX-add_parser(q($p))-save_parsers() 2 /dev/null
https://bugzilla.redhat.com/show_bug.cgi?id=1206915 Jan Pokorný jpoko...@redhat.com changed: What|Removed |Added CC||jpoko...@redhat.com --- Comment #1 from Jan Pokorný jpoko...@redhat.com --- Same observation, this time during fedup upgrade (phase between reboots), with officially blessed Fedora 22. perl-XML-SAX-0.99-13.fc22.noarch.rpm Note that the installation order was as follows: [...] perl-XML-SAX-Base-1.08-12.fc22.noarch.rpm [...] perl-XML-SAX-0.99-13.fc22.noarch.rpm perl-XML-LibXML-2.0121-1.fc22.x86_64.rpm [...] -- You are receiving this mail because: You are on the CC list for the bug. -- 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
Re: Fedora 22: cannot use rpmsign in script - problem with pinentry-gtk-2
Petr Pisar píše v Út 02. 06. 2015 v 07:57 +:
On 2015-06-02, Pavel Lisý pavel.l...@gmail.com wrote:
I've used rpmsign in script for long time. I worked fine. After upgrade
to
Fedora 22 (from Fedora 20) something changed
[...]
is starting now pinentry-gtk-2 and forces me to put passphrase to modal
window.
Is any possibility how to disable this behaviour? Whatever I've found
through google didn't work for me.
gnupg2 changed. Maybe you look for gpg-preset-passphrase tool
https://www.gnupg.org/documentation/manuals/gnupg/gpg_002dpreset_002dpas
sphrase.html.
Also the gpg-agent is not located by environment variables but by
socket. And the gpg-agent will be spawned automatically if it does not
run.
Also handling password file descriptor behaves differently. See
http://thread.gmane.org/gmane.comp.encryption.gpg.devel/19353/.
-- Petr
Here is working solution:
add this lines to ~/.rpmmacros
%__gpg /usr/bin/gpg2
%__gpg_check_password_cmd %{__gpg} \
gpg --batch --no-verbose --passphrase-fd 3 --pinentry-mode loopback -u
%{_gpg_name} -so -
Pavel
--
Pavel Lisý pavel.l...@gmail.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
[Bug 1227327] perl-Getopt-Long-2.46 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1227327 --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Created attachment 1033738 -- https://bugzilla.redhat.com/attachment.cgi?id=1033738action=edit [patch] Update to 2.46 (#1227327) -- You are receiving this mail because: You are on the CC list for the bug. -- 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 1227327] New: perl-Getopt-Long-2.46 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1227327 Bug ID: 1227327 Summary: perl-Getopt-Long-2.46 is available Product: Fedora Version: rawhide Component: perl-Getopt-Long 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: 2.46 Current version/release in rawhide: 2.45-1.fc23 URL: http://search.cpan.org/dist/Getopt-Long/ 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 Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. -- You are receiving this mail because: You are on the CC list for the bug. -- 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
ppisar uploaded Getopt-Long-2.46.tar.gz for perl-Getopt-Long
0bcbf60153bfd4c2de6ac59bb7c81d99 Getopt-Long-2.46.tar.gz http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Getopt-Long/Getopt-Long-2.46.tar.gz/0bcbf60153bfd4c2de6ac59bb7c81d99/Getopt-Long-2.46.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
Re: Fedora.next PRD refresh
On Tue, 2015-06-02 at 09:55 +0700, Truong Anh Tuan wrote: - Original Message - From: Stephen Gallagher sgall...@redhat.com To: Server SIG ser...@lists.fedoraproject.org, desk...@lists.fedoraproject.org, devel-annou...@lists.fedoraproject.org, cl...@lists.fedoraproject.org Sent: Tuesday, June 2, 2015 2:03:44 AM Subject: Fedora.next PRD refresh snipped == Future PRD Refreshes == Starting at Flock 2016 (yes, *next* calendar year), each working group will have a workshop scheduled at Flock to go over its PRD and plan for the following year. Note: because Flock generally falls between Alpha and Beta of a Fedora release, all PRD planning is presumed to be a directive for Fedora N+1 and N+2 at that time, not retroactively applied to the current release. The workshops are expected to cover the majority of the update, and then they will be brought back to the respective mailing lists for further review before being due to the Council one month after Flock concludes. +1. This is a good idea and it is important to push products toward on the right way. I am just curious why it would not be held from this year? because of time constrains? We had already communicated to several groups that we wanted to refresh it before Alpha this cycle (Cloud in particular had moved far from its original PRD). We decided to keep that plan and adjust the future. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ppisar pushed to perl-Getopt-Long (f20). 2.46 bump
From c04de40ceac1253a6017b902504af9d495a75003 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= ppi...@redhat.com
Date: Tue, 2 Jun 2015 15:06:33 +0200
Subject: 2.46 bump
diff --git a/.gitignore b/.gitignore
index 902668c..f3c8aba 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@
/Getopt-Long-2.43.tar.gz
/Getopt-Long-2.44.tar.gz
/Getopt-Long-2.45.tar.gz
+/Getopt-Long-2.46.tar.gz
diff --git a/perl-Getopt-Long.spec b/perl-Getopt-Long.spec
index 7b5a3d0..8c1e567 100644
--- a/perl-Getopt-Long.spec
+++ b/perl-Getopt-Long.spec
@@ -1,5 +1,5 @@
Name: perl-Getopt-Long
-Version:2.45
+Version:2.46
Release:1%{?dist}
Summary:Extended processing of command line options
License:GPLv2+ or Artistic
@@ -7,6 +7,8 @@ Group: Development/Libraries
URL:http://search.cpan.org/dist/Getopt-Long/
Source0:
http://www.cpan.org/authors/id/J/JV/JV/Getopt-Long-%{version}.tar.gz
BuildArch: noarch
+BuildRequires: findutils
+BuildRequires: make
BuildRequires: perl
BuildRequires: perl(Config)
BuildRequires: perl(ExtUtils::MakeMaker) = 5.0
@@ -57,6 +59,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Jun 02 2015 Petr Pisar ppi...@redhat.com - 2.46-1
+- 2.46 bump
+
* Tue Feb 24 2015 Petr Pisar ppi...@redhat.com - 2.45-1
- 2.45 bump
diff --git a/sources b/sources
index 01b7d02..90ddbe9 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ea5c085b30915efe522f9ac58fcc343d Getopt-Long-2.45.tar.gz
+0bcbf60153bfd4c2de6ac59bb7c81d99 Getopt-Long-2.46.tar.gz
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Getopt-Long.git/commit/?h=f20id=c04de40ceac1253a6017b902504af9d495a75003
--
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: Fedmsg Emitting
Before we start sending fedmsgs we need to discuss a few things. We don't have to find solutions to all these problems, just keep them in mind when designing the solution we're going to start with: 1. How often do we send fedmsg a) per-task b) per-update c) per-build ... That leaves us with c) Seems reasonable to me. I guess c) allows to easier filtering in FMN. c) not only allows for easier filtering in FMN but it's also more compatible with how I think that releng would like to see build gating done. Assuming that we eventually get into the rawhide space, we'll have to start emitting stuff per-build anyways :) I'm of the opinion that c) is going to be best here. In the past, we've done a lot of results on a per-update basis but unless I'm forgetting something, we could transition to more of a per-build system. For example - depcheck processes updates - if one build in that update fails, the whole update fails. While I think that this the best choice, I also think that logic should be handled in bodhi instead of us trying to emulate what bodhi is doing. As far as I know, this is happening with bodhi2 - they're assuming that we'll be emitting per-build fedmsgs and the logic for failing/passing an update will lie in bodhi and not rely on our emulation of bodhi's processes. That's great to hear. 2. Who do we target: users, systems or both The issue here is with tasks that repeatedly test one update. Currently we check if there's a bodhi update comment with the same result already and if so, we don't post the comment again. To do something like that with fedmsgs we'd have to have a code running somewhere that would check against its database whether an incoming result is a duplicate or not. The question is where the code would run. Bodhi comes to mind since it already has information about updates and so is good for tasks that work with bodhi updates. However, there might be tasks that work with something else, like composes. In this case we'd probably have the code on taskotron systems. I think that how we handle scheduling of some of our current checks (depcheck and upgradepath) is a byproduct of trying to make a repo-level check look like a build/update-level check. I can't think of many more tasks that would run into the same problem of repeated runs. I agree that depcheck and upgradepath are somewhat special here. Once Fedora Infra sees how many results we publish daily, especially during freeze periods (when there are lots of packaging pending stable), they might ask us to come up with a better solution, I'm afraid. I'm not sure if there are better ways to handle it, either way, there will probably always be some kind of check that will require this kind of constant re-running. But it seems reasonable to assume that it will be a small minority in the overall task pool. For the majority of tasks, I see the process as being similar to: 1. trigger task $x for $y 2. run task $x with $y as input 3. report result for $x($y) With this, we'd be running $x for each $y and the reporting would only happen for each unique ($x, $y) assuming that something wasn't rescheduled or forced to re-run. I think it would be best to have consistent behavior for our fedmsg emitting. If most tasks will only emit fedmsgs once, we should take our minority tasks that emit more than one fedmsg per item and deduplicate before the messages are emitted. Or, you can say that most tasks emit fedmsgs always (even though that means just once), and therefore the minority tasks should also emit it always :) I agree with having a consistent behavior. But I think it's possible to find a solution side-stepping this. See below. So if we target systems we'd just send all results in fedmsgs and let the systems consume them and do whatever they want to do with them (e.g. bodhi can squash all the tasks relevant to specific update and notify the maintainer of the package via fedmsg about the result). If we target users, we'd have to have some logic to limit rate of fedmsgs ourselves but that would mean hiding some of the results (although duplicates) from the world. I'd like to see us do the deduplication in resultsdb (assuming that's where the fedmsg emission will be happening). I think that we already have a table for items and I don't think that keeping track of is_emitted and the last state emitted (so we can track changes in state) would be too bad. Then again, I'm not the one working in the code and I could be wrong :) We talked with Martin about this in length some time ago, and I raised the question of different consumers. I see two groups here - machines and humans. If I understand you correctly, what you propose up there is to hardcode the system to fit human preferences. If I misunderstood it, then the whole rest of the mail is based on wrong assumptions, but it's still an interesting topic
[Bug 1227327] perl-Getopt-Long-2.46 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1227327 --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- perl-Getopt-Long-2.46-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/perl-Getopt-Long-2.46-1.fc21 -- You are receiving this mail because: You are on the CC list for the bug. -- 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 1227327] perl-Getopt-Long-2.46 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1227327 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- perl-Getopt-Long-2.46-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/perl-Getopt-Long-2.46-1.fc22 -- You are receiving this mail because: You are on the CC list for the bug. -- 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 1227327] perl-Getopt-Long-2.46 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1227327 --- Comment #7 from Fedora Update System upda...@fedoraproject.org --- perl-Getopt-Long-2.46-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-Getopt-Long-2.46-1.fc20 -- You are receiving this mail because: You are on the CC list for the bug. -- 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
Re: Fedmsg Emitting
On Wed, 20 May 2015 09:02:49 -0400 (EDT) Martin Krizek mkri...@redhat.com wrote: snip So if we target systems we'd just send all results in fedmsgs and let the systems consume them and do whatever they want to do with them (e.g. bodhi can squash all the tasks relevant to specific update and notify the maintainer of the package via fedmsg about the result). If we target users, we'd have to have some logic to limit rate of fedmsgs ourselves but that would mean hiding some of the results (although duplicates) from the world. I'd like to see us do the deduplication in resultsdb (assuming that's where the fedmsg emission will be happening). I think that we already have a table for items and I don't think that keeping track of is_emitted and the last state emitted (so we can track changes in state) would be too bad. Then again, I'm not the one working in the code and I could be wrong :) Can you think of a use case when someone would want to receive all results including duplicates? For the per-repo checks that we're changing to emulate the behavior of per-build/update checks? No, I can't think of a reason why anyone other than us would be interested in getting all that data. Tim pgpMdf0ZhVDhH.pgp Description: OpenPGP digital signature ___ qa-devel mailing list qa-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
psabata pushed to perl-Date-Manip (f22). 6.50 bump, bugfixes and new tzdata
From cef4f47e5dfa8c8642ede9af3eedfe954c8a1208 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= con...@redhat.com
Date: Tue, 2 Jun 2015 15:42:01 +0200
Subject: 6.50 bump, bugfixes and new tzdata
diff --git a/.gitignore b/.gitignore
index 34286af..11c9673 100644
--- a/.gitignore
+++ b/.gitignore
@@ -27,3 +27,4 @@ Date-Manip-6.07.tar.gz
/Date-Manip-6.47.tar.gz
/Date-Manip-6.48.tar.gz
/Date-Manip-6.49.tar.gz
+/Date-Manip-6.50.tar.gz
diff --git a/perl-Date-Manip.spec b/perl-Date-Manip.spec
index 6eaf93b..3ed3633 100644
--- a/perl-Date-Manip.spec
+++ b/perl-Date-Manip.spec
@@ -1,5 +1,5 @@
Name: perl-Date-Manip
-Version:6.49
+Version:6.50
Release:1%{?dist}
Summary:Date manipulation routines
Group: Development/Libraries
@@ -14,6 +14,7 @@ BuildRequires: perl(strict)
BuildRequires: perl(warnings)
# Runtime
BuildRequires: perl(Carp)
+# XXX: BuildRequires: perl(Data::Dumper)
BuildRequires: perl(Encode)
BuildRequires: perl(Exporter)
BuildRequires: perl(integer)
@@ -61,6 +62,9 @@ perl Build.PL installdirs=vendor
%{_bindir}/dm_*
%changelog
+* Tue Jun 02 2015 Petr Šabata con...@redhat.com - 6.50-1
+- 6.50 bump, bugfixes and new tzdata
+
* Tue Mar 03 2015 Petr Šabata con...@redhat.com - 6.49-1
- 6.49 bugfix bump
diff --git a/sources b/sources
index 59888d2..7bacad2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4a07d42b0e47a48c4df0af22fcefc6be Date-Manip-6.49.tar.gz
+62c86841f9c57ebe663178195c1df272 Date-Manip-6.50.tar.gz
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Date-Manip.git/commit/?h=f22id=cef4f47e5dfa8c8642ede9af3eedfe954c8a1208
--
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
psabata pushed to perl-Date-Manip (master). 6.50 bump, bugfixes and new tzdata
From cef4f47e5dfa8c8642ede9af3eedfe954c8a1208 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= con...@redhat.com
Date: Tue, 2 Jun 2015 15:42:01 +0200
Subject: 6.50 bump, bugfixes and new tzdata
diff --git a/.gitignore b/.gitignore
index 34286af..11c9673 100644
--- a/.gitignore
+++ b/.gitignore
@@ -27,3 +27,4 @@ Date-Manip-6.07.tar.gz
/Date-Manip-6.47.tar.gz
/Date-Manip-6.48.tar.gz
/Date-Manip-6.49.tar.gz
+/Date-Manip-6.50.tar.gz
diff --git a/perl-Date-Manip.spec b/perl-Date-Manip.spec
index 6eaf93b..3ed3633 100644
--- a/perl-Date-Manip.spec
+++ b/perl-Date-Manip.spec
@@ -1,5 +1,5 @@
Name: perl-Date-Manip
-Version:6.49
+Version:6.50
Release:1%{?dist}
Summary:Date manipulation routines
Group: Development/Libraries
@@ -14,6 +14,7 @@ BuildRequires: perl(strict)
BuildRequires: perl(warnings)
# Runtime
BuildRequires: perl(Carp)
+# XXX: BuildRequires: perl(Data::Dumper)
BuildRequires: perl(Encode)
BuildRequires: perl(Exporter)
BuildRequires: perl(integer)
@@ -61,6 +62,9 @@ perl Build.PL installdirs=vendor
%{_bindir}/dm_*
%changelog
+* Tue Jun 02 2015 Petr Šabata con...@redhat.com - 6.50-1
+- 6.50 bump, bugfixes and new tzdata
+
* Tue Mar 03 2015 Petr Šabata con...@redhat.com - 6.49-1
- 6.49 bugfix bump
diff --git a/sources b/sources
index 59888d2..7bacad2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4a07d42b0e47a48c4df0af22fcefc6be Date-Manip-6.49.tar.gz
+62c86841f9c57ebe663178195c1df272 Date-Manip-6.50.tar.gz
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Date-Manip.git/commit/?h=masterid=cef4f47e5dfa8c8642ede9af3eedfe954c8a1208
--
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
psabata uploaded Date-Manip-6.50.tar.gz for perl-Date-Manip
62c86841f9c57ebe663178195c1df272 Date-Manip-6.50.tar.gz http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Date-Manip/Date-Manip-6.50.tar.gz/62c86841f9c57ebe663178195c1df272/Date-Manip-6.50.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
Re: [Base] Base Design WG agenda meeting 1st June 2015 14:15 UTC on #fedora-meeting-2
On Tue, Jun 2, 2015 at 2:47 AM, Václav Pavlín vpav...@redhat.com wrote: Hi guys, I am sorry I missed the meeting yesterday - I had a training I completely forgot about, but anyway, my comments to the topic(s) follow: Gathering of an information for the modularization proposal should surely be a common effort of es and Base - as both WGs has edditions/spins as their users From my pov Base should own intersection of the package set from (all?) editions/spins/WGs. Thus if we agree on using scl for our modularization, then yes, it should be in Base's hands to add it the core pkg set. But also as jreznik said, we screwed up in generating requirements for such minimal/common package set:). On the other hand whatever is optional and not THE ONE technology we choose to support should be probably in hands of es so that we don't add bloat to base system. 14:47:53 langdon msekleta, i guess i am making the argument that if es says this is how we do x, which relies on y then es needs to work with base to get y included in base for use by the editions (or other WGs in general) If it is agreed upon that all editions will benefit from that x and y, then yes. But let's imagine Workstation decides to use xdg-apps and server decides to use Docker for similar use cases - how do es or Base get involved in here? By providing a common underlying OS platform layer, whether it be as a set of packages and comps groups, or an Atomic base image. ES can further aid this by providing additional layers that help the WGs provide API compatibility through scl or whatever other mechanism. Your question is a good one, but xdg-apps and docker are pretty high on the layer stack. They are only one layer down from end user developer/app, so there are lots of things that they need to work well. Maybe Langdon can draw some awesome ascii art to illustrate the layers he's thinking about. I would try, but gmail would mess it up. 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
jplesnik pushed to perl-Exception-Base (master). Fixed issue which appeared for Perl 5.21.2 and higher
From 4cbc3566f213bae19c460399d5d6207df4124ea8 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova jples...@redhat.com
Date: Tue, 2 Jun 2015 15:04:21 +0200
Subject: Fixed issue which appeared for Perl 5.21.2 and higher
diff --git a/Exception-Base-0.25-Fix-redundant-argument-in-sprintf.patch
b/Exception-Base-0.25-Fix-redundant-argument-in-sprintf.patch
new file mode 100644
index 000..8861cfb
--- /dev/null
+++ b/Exception-Base-0.25-Fix-redundant-argument-in-sprintf.patch
@@ -0,0 +1,49 @@
+From 1cb0ea6afd4bb76e5a1d759efe27ea0f18306a82 Mon Sep 17 00:00:00 2001
+From: Lee Johnson l...@givengain.ch
+Date: Thu, 1 Jan 2015 22:33:54 +
+Subject: [PATCH] resolve #1 - fix warnings new since perl 5.21.2
+
+Redundant argument in %s - this is because the various calls to the
+sprintf function offset the arrays by 1 (since the first element of
+the array is the sprintf string) but use @_ (the number of elements
+in the array) in the range: 1 .. @_
+
+since it's offset by 1 we are going beyond the end of the array and
+so sprintf consequently warns that we sent more arguments than it
+expected. fix this by using @_ -1 in the range (number of elements
+in the array minus 1)
+---
+ lib/Exception/Base.pm | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/lib/Exception/Base.pm b/lib/Exception/Base.pm
+index 8dce19f..096e2a5 100644
+--- a/lib/Exception/Base.pm
b/lib/Exception/Base.pm
+@@ -1362,7 +1362,7 @@ sub matches { ## no critic qw(ProhibitExcessComplexity)
+ local $_ = ref $self-{$key} eq 'ARRAY'
+? sprintf(
+ @{$self-{$key}}[0],
+- @{$self-{$key}}[1..@{$self-{$key}}]
++ @{$self-{$key}}[1..@{$self-{$key}}-1]
+ )
+: $self-{$key};
+ if (ref $arrval eq 'CODE') {
+@@ -1393,7 +1393,7 @@ sub matches { ## no critic qw(ProhibitExcessComplexity)
+ local $_ = ref $self-{$key} eq 'ARRAY'
+? sprintf(
+ @{$self-{$key}}[0],
+- @{$self-{$key}}[1..@{$self-{$key}}]
++ @{$self-{$key}}[1..@{$self-{$key}}-1]
+ )
+: $self-{$key};
+
+@@ -1613,7 +1613,7 @@ sub _string_attributes {
+ my ($self) = @_;
+
+ return map { ref $_ eq 'ARRAY'
+- ? sprintf(@$_[0], @$_[1..@$_])
++ ? sprintf(@$_[0], @$_[1..@$_-1])
+ : $_ }
+grep { defined $_ and (ref $_ or $_ ne '') }
+map { $self-{$_} }
diff --git a/perl-Exception-Base.spec b/perl-Exception-Base.spec
index 4ec4b99..254772a 100644
--- a/perl-Exception-Base.spec
+++ b/perl-Exception-Base.spec
@@ -1,11 +1,14 @@
Name: perl-Exception-Base
Version:0.2500
-Release:5%{?dist}
+Release:6%{?dist}
Summary:Lightweight exceptions
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Exception-Base/
Source0:
http://www.cpan.org/authors/id/D/DE/DEXTER/Exception-Base-0.25.tar.gz
+# Fixed redundant argument in %s - appeared with perl 5.21.2
+# https://github.com/dex4er/perl-Exception-Base/issues/1
+Patch0: Exception-Base-0.25-Fix-redundant-argument-in-sprintf.patch
BuildArch: noarch
BuildRequires: perl(Module::Build)
@@ -23,6 +26,7 @@ default verbosity is uppered for debugging purposes.
%prep
%setup -q -n Exception-Base-0.25
+%patch0 -p1
%build
%{__perl} Build.PL installdirs=vendor
@@ -43,6 +47,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_mandir}/man3/*
%changelog
+* Tue Jun 02 2015 Jitka Plesnikova jples...@redhat.com - 0.2500-6
+- Fixed issue which appeared for Perl 5.21.2 and higher
+
* Wed Aug 27 2014 Jitka Plesnikova jples...@redhat.com - 0.2500-5
- Perl 5.20 rebuild
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Exception-Base.git/commit/?h=masterid=4cbc3566f213bae19c460399d5d6207df4124ea8
--
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
ppisar pushed to perl-Getopt-Long (f22). 2.46 bump
From 559f4e2100a6991bfa66cd18d9075d0dd42d0f46 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= ppi...@redhat.com
Date: Tue, 2 Jun 2015 15:06:33 +0200
Subject: 2.46 bump
diff --git a/.gitignore b/.gitignore
index 902668c..f3c8aba 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@
/Getopt-Long-2.43.tar.gz
/Getopt-Long-2.44.tar.gz
/Getopt-Long-2.45.tar.gz
+/Getopt-Long-2.46.tar.gz
diff --git a/perl-Getopt-Long.spec b/perl-Getopt-Long.spec
index ae8ad49..e4475cf 100644
--- a/perl-Getopt-Long.spec
+++ b/perl-Getopt-Long.spec
@@ -1,5 +1,5 @@
Name: perl-Getopt-Long
-Version:2.45
+Version:2.46
Release:1%{?dist}
Summary:Extended processing of command line options
License:GPLv2+ or Artistic
@@ -7,6 +7,8 @@ Group: Development/Libraries
URL:http://search.cpan.org/dist/Getopt-Long/
Source0:
http://www.cpan.org/authors/id/J/JV/JV/Getopt-Long-%{version}.tar.gz
BuildArch: noarch
+BuildRequires: findutils
+BuildRequires: make
BuildRequires: perl
BuildRequires: perl(Config)
BuildRequires: perl(ExtUtils::MakeMaker) = 5.0
@@ -57,6 +59,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Jun 02 2015 Petr Pisar ppi...@redhat.com - 2.46-1
+- 2.46 bump
+
* Tue Feb 24 2015 Petr Pisar ppi...@redhat.com - 2.45-1
- 2.45 bump
diff --git a/sources b/sources
index 01b7d02..90ddbe9 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ea5c085b30915efe522f9ac58fcc343d Getopt-Long-2.45.tar.gz
+0bcbf60153bfd4c2de6ac59bb7c81d99 Getopt-Long-2.46.tar.gz
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Getopt-Long.git/commit/?h=f22id=559f4e2100a6991bfa66cd18d9075d0dd42d0f46
--
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
Re: Fedora.next PRD refresh
On Tue, 2015-06-02 at 09:55 +0700, Truong Anh Tuan wrote: - Original Message - From: Stephen Gallagher sgall...@redhat.com To: Server SIG ser...@lists.fedoraproject.org, desk...@lists.fedoraproject.org, devel-announce@lists.fedoraproject.org, cl...@lists.fedoraproject.org Sent: Tuesday, June 2, 2015 2:03:44 AM Subject: Fedora.next PRD refresh snipped == Future PRD Refreshes == Starting at Flock 2016 (yes, *next* calendar year), each working group will have a workshop scheduled at Flock to go over its PRD and plan for the following year. Note: because Flock generally falls between Alpha and Beta of a Fedora release, all PRD planning is presumed to be a directive for Fedora N+1 and N+2 at that time, not retroactively applied to the current release. The workshops are expected to cover the majority of the update, and then they will be brought back to the respective mailing lists for further review before being due to the Council one month after Flock concludes. +1. This is a good idea and it is important to push products toward on the right way. I am just curious why it would not be held from this year? because of time constrains? We had already communicated to several groups that we wanted to refresh it before Alpha this cycle (Cloud in particular had moved far from its original PRD). We decided to keep that plan and adjust the future. signature.asc Description: This is a digitally signed message part ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
[Bug 1227327] perl-Getopt-Long-2.46 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1227327 --- Comment #4 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- ppisar's perl-Getopt-Long-2.46-1.fc23 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=640624 -- You are receiving this mail because: You are on the CC list for the bug. -- 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
Orphaning/retiring 2 packages
Hi, I don't use these 2 packages any more, and don't want to continue maintaining them. If someone want to take over, I'll be happy to pass them. But if nobody express their interest in the next few days, I'll just retire them. # weighttp This package hasn't had any upstream release since 2011. Well, upstream didn't actually release anything, they just tagged the commit with v0.3, so I was generating the tarball myself. There have been 6 commits in master since the last release, all in 2013. So all in all, upstream is dormant, at best. # docx2txt Last release was in 2014, I guess it works overall, but like I said I don't use it myself any more. Cheers, -- 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
[Bug 1227327] perl-Getopt-Long-2.46 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1227327 --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Scratch build succeeded http://koji.fedoraproject.org/koji/taskinfo?taskID=9916741 -- You are receiving this mail because: You are on the CC list for the bug. -- 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
ppisar pushed to perl-Getopt-Long (master). 2.46 bump
From 559f4e2100a6991bfa66cd18d9075d0dd42d0f46 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= ppi...@redhat.com
Date: Tue, 2 Jun 2015 15:06:33 +0200
Subject: 2.46 bump
diff --git a/.gitignore b/.gitignore
index 902668c..f3c8aba 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@
/Getopt-Long-2.43.tar.gz
/Getopt-Long-2.44.tar.gz
/Getopt-Long-2.45.tar.gz
+/Getopt-Long-2.46.tar.gz
diff --git a/perl-Getopt-Long.spec b/perl-Getopt-Long.spec
index ae8ad49..e4475cf 100644
--- a/perl-Getopt-Long.spec
+++ b/perl-Getopt-Long.spec
@@ -1,5 +1,5 @@
Name: perl-Getopt-Long
-Version:2.45
+Version:2.46
Release:1%{?dist}
Summary:Extended processing of command line options
License:GPLv2+ or Artistic
@@ -7,6 +7,8 @@ Group: Development/Libraries
URL:http://search.cpan.org/dist/Getopt-Long/
Source0:
http://www.cpan.org/authors/id/J/JV/JV/Getopt-Long-%{version}.tar.gz
BuildArch: noarch
+BuildRequires: findutils
+BuildRequires: make
BuildRequires: perl
BuildRequires: perl(Config)
BuildRequires: perl(ExtUtils::MakeMaker) = 5.0
@@ -57,6 +59,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Jun 02 2015 Petr Pisar ppi...@redhat.com - 2.46-1
+- 2.46 bump
+
* Tue Feb 24 2015 Petr Pisar ppi...@redhat.com - 2.45-1
- 2.45 bump
diff --git a/sources b/sources
index 01b7d02..90ddbe9 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ea5c085b30915efe522f9ac58fcc343d Getopt-Long-2.45.tar.gz
+0bcbf60153bfd4c2de6ac59bb7c81d99 Getopt-Long-2.46.tar.gz
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Getopt-Long.git/commit/?h=masterid=559f4e2100a6991bfa66cd18d9075d0dd42d0f46
--
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 1227327] perl-Getopt-Long-2.46 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1227327 --- Comment #3 from Petr Pisar ppi...@redhat.com --- A bug-fix release suitable for all Fedoras. -- You are receiving this mail because: You are on the CC list for the bug. -- 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
psabata uploaded CPAN-Perl-Releases-2.22.tar.gz for perl-CPAN-Perl-Releases
b625ff552df9ddb4f830e92102f82c83 CPAN-Perl-Releases-2.22.tar.gz http://pkgs.fedoraproject.org/lookaside/pkgs/perl-CPAN-Perl-Releases/CPAN-Perl-Releases-2.22.tar.gz/b625ff552df9ddb4f830e92102f82c83/CPAN-Perl-Releases-2.22.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
psabata pushed to perl-CPAN-Perl-Releases (master). 2.22 bump, updated for v5.22.0
From be1ae21a8391c5fe6bac43c3395941580d86e8de Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= con...@redhat.com
Date: Tue, 2 Jun 2015 15:10:57 +0200
Subject: 2.22 bump, updated for v5.22.0
diff --git a/.gitignore b/.gitignore
index ed0c947..c060135 100644
--- a/.gitignore
+++ b/.gitignore
@@ -22,3 +22,4 @@
/CPAN-Perl-Releases-2.14.tar.gz
/CPAN-Perl-Releases-2.16.tar.gz
/CPAN-Perl-Releases-2.18.tar.gz
+/CPAN-Perl-Releases-2.22.tar.gz
diff --git a/perl-CPAN-Perl-Releases.spec b/perl-CPAN-Perl-Releases.spec
index 7be2139..ce69bbb 100644
--- a/perl-CPAN-Perl-Releases.spec
+++ b/perl-CPAN-Perl-Releases.spec
@@ -1,5 +1,5 @@
Name: perl-CPAN-Perl-Releases
-Version:2.18
+Version:2.22
Release:1%{?dist}
Summary:Mapping Perl releases on CPAN to the location of the tarballs
License:GPL+ or Artistic
@@ -50,6 +50,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Jun 02 2015 Petr Šabata con...@redhat.com - 2.22-1
+- 2.22 bump, updated for v5.22.0
+
* Mon May 25 2015 Petr Šabata con...@redhat.com - 2.18-1
- 2.18 bump, updated for v5.22.0-rc2
diff --git a/sources b/sources
index f0a869c..b068633 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ae35667a830550bbe3ab89bd7ee16e99 CPAN-Perl-Releases-2.18.tar.gz
+b625ff552df9ddb4f830e92102f82c83 CPAN-Perl-Releases-2.22.tar.gz
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-CPAN-Perl-Releases.git/commit/?h=masterid=be1ae21a8391c5fe6bac43c3395941580d86e8de
--
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 1227121] perl-CPAN-Perl-Releases-2.22 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1227121 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-CPAN-Perl-Releases-2.2 ||2-1.fc23 Resolution|--- |RAWHIDE Last Closed||2015-06-02 09:11:28 -- You are receiving this mail because: You are on the CC list for the bug. -- 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
New ABRT CLI
Hi, over last two weeks I completely rewrote abrt-cli to make life easier for users and developers. It now supports tab completion and few new commands like abrt gdb and abrt debuginfo-install. Without any arguments these commands will use the last crash that occurred on your system. New cli is available in abrt-cli-ng subpackage and will replace old abrt-cli command in the future. Please help with testing according to instructions in the following copr: https://copr.fedoraproject.org/coprs/rmarko/abrt/ Feedback is highly appreciated. Thanks! -- Richard irc: impure_hate -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
ppisar pushed to perl-Getopt-Long (f21). 2.46 bump
From 8c336c3f164b709ef354a7d2479e7af200d6e9a7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= ppi...@redhat.com
Date: Tue, 2 Jun 2015 15:06:33 +0200
Subject: 2.46 bump
diff --git a/.gitignore b/.gitignore
index 902668c..f3c8aba 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@
/Getopt-Long-2.43.tar.gz
/Getopt-Long-2.44.tar.gz
/Getopt-Long-2.45.tar.gz
+/Getopt-Long-2.46.tar.gz
diff --git a/perl-Getopt-Long.spec b/perl-Getopt-Long.spec
index 984cd92..6f0f7e3 100644
--- a/perl-Getopt-Long.spec
+++ b/perl-Getopt-Long.spec
@@ -1,5 +1,5 @@
Name: perl-Getopt-Long
-Version:2.45
+Version:2.46
Release:1%{?dist}
Summary:Extended processing of command line options
License:GPLv2+ or Artistic
@@ -7,6 +7,8 @@ Group: Development/Libraries
URL:http://search.cpan.org/dist/Getopt-Long/
Source0:
http://www.cpan.org/authors/id/J/JV/JV/Getopt-Long-%{version}.tar.gz
BuildArch: noarch
+BuildRequires: findutils
+BuildRequires: make
BuildRequires: perl
BuildRequires: perl(Config)
BuildRequires: perl(ExtUtils::MakeMaker) = 5.0
@@ -57,6 +59,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Jun 02 2015 Petr Pisar ppi...@redhat.com - 2.46-1
+- 2.46 bump
+
* Tue Feb 24 2015 Petr Pisar ppi...@redhat.com - 2.45-1
- 2.45 bump
diff --git a/sources b/sources
index 01b7d02..90ddbe9 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ea5c085b30915efe522f9ac58fcc343d Getopt-Long-2.45.tar.gz
+0bcbf60153bfd4c2de6ac59bb7c81d99 Getopt-Long-2.46.tar.gz
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Getopt-Long.git/commit/?h=f21id=8c336c3f164b709ef354a7d2479e7af200d6e9a7
--
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 1227327] perl-Getopt-Long-2.46 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1227327 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Getopt-Long-2.46-1.fc2 ||3 -- You are receiving this mail because: You are on the CC list for the bug. -- 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
psabata pushed to perl-Date-Manip (f21). 6.50 bump, bugfixes and new tzdata
From cef4f47e5dfa8c8642ede9af3eedfe954c8a1208 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20=C5=A0abata?= con...@redhat.com
Date: Tue, 2 Jun 2015 15:42:01 +0200
Subject: 6.50 bump, bugfixes and new tzdata
diff --git a/.gitignore b/.gitignore
index 34286af..11c9673 100644
--- a/.gitignore
+++ b/.gitignore
@@ -27,3 +27,4 @@ Date-Manip-6.07.tar.gz
/Date-Manip-6.47.tar.gz
/Date-Manip-6.48.tar.gz
/Date-Manip-6.49.tar.gz
+/Date-Manip-6.50.tar.gz
diff --git a/perl-Date-Manip.spec b/perl-Date-Manip.spec
index 6eaf93b..3ed3633 100644
--- a/perl-Date-Manip.spec
+++ b/perl-Date-Manip.spec
@@ -1,5 +1,5 @@
Name: perl-Date-Manip
-Version:6.49
+Version:6.50
Release:1%{?dist}
Summary:Date manipulation routines
Group: Development/Libraries
@@ -14,6 +14,7 @@ BuildRequires: perl(strict)
BuildRequires: perl(warnings)
# Runtime
BuildRequires: perl(Carp)
+# XXX: BuildRequires: perl(Data::Dumper)
BuildRequires: perl(Encode)
BuildRequires: perl(Exporter)
BuildRequires: perl(integer)
@@ -61,6 +62,9 @@ perl Build.PL installdirs=vendor
%{_bindir}/dm_*
%changelog
+* Tue Jun 02 2015 Petr Šabata con...@redhat.com - 6.50-1
+- 6.50 bump, bugfixes and new tzdata
+
* Tue Mar 03 2015 Petr Šabata con...@redhat.com - 6.49-1
- 6.49 bugfix bump
diff --git a/sources b/sources
index 59888d2..7bacad2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4a07d42b0e47a48c4df0af22fcefc6be Date-Manip-6.49.tar.gz
+62c86841f9c57ebe663178195c1df272 Date-Manip-6.50.tar.gz
--
cgit v0.10.2
http://pkgs.fedoraproject.org/cgit/perl-Date-Manip.git/commit/?h=f21id=cef4f47e5dfa8c8642ede9af3eedfe954c8a1208
--
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 1227122] perl-Date-Manip-6.50 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1227122 --- Comment #3 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- psabata's perl-Date-Manip-6.50-1.fc23 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=640642 -- You are receiving this mail because: You are on the CC list for the bug. -- 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 1225047] Upgrade perl-Curses
https://bugzilla.redhat.com/show_bug.cgi?id=1225047 --- Comment #1 from Fedora Update System upda...@fedoraproject.org --- perl-Curses-1.32-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/FEDORA-2015-9342/perl-Curses-1.32-1.fc22 -- You are receiving this mail because: You are on the CC list for the bug. -- 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 1226484] perl-CGI-4.20 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1226484 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- Package perl-CGI-4.20-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-CGI-4.20-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-9305/perl-CGI-4.20-1.fc22 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. -- 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 1225047] Upgrade perl-Curses
https://bugzilla.redhat.com/show_bug.cgi?id=1225047 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- Package perl-Curses-1.32-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Curses-1.32-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-9342/perl-Curses-1.32-1.fc22 then log in and leave karma (feedback). -- You are receiving this mail because: You are on the CC list for the bug. -- 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
Re: F23 System Wide Change: Default Local DNS Resolver
Jan Kurik jku...@redhat.com wrote: Install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. The automatic name server entries received via dhcp/vpn/wireless configurations should be stored separately (e.g. this is stored in the NetworkManager internal state), as transitory name servers to be used by the trusted local resolver. In all cases, DNSSEC validation will be done locally. How does this interact with dnsmasq which also wants to be the only name server entry in resolv.conf? David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Docker base image naming for non-x86_64
Hello all, There was recently a thread on the Fedora ARM mailing list[0] about getting a Fedora ARM image into the official Docker Hub. That discussion lead down the trail of how to best handle the naming for all of this. The current questions are either using Fedora's namespace and just making a new image (using Fedora ARM as an example), this would be the FROM line for a Dockerfile FROM fedora/armhfp Which would then contain all the standard tags for latest, rawhide, f22, etc. Or alternatively, have each architecture maintain their own namespace within the Hub which would look a little more like: FROM fedora-arm I'm personally a fan of the first option because it keeps things under the Fedora umbrella and also allows for flexibility of aarch64, POWER, etc as Docker supports more architectures. However the one thing I see there that could be problematic is the possibility for users to be confused if they don't search on the Docker Hub webUI and see the associated documentation highlighting that the base image is for a different architecture but instead just search from the docker command line and end up with an image that won't run. Looking forward to feedback on the topic. Thanks, -AdamM [0] - https://lists.fedoraproject.org/pipermail/arm/2015-June/009526.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Perl 5.22 upgrade
Hello, We have acquired `f23-perl' build-root. Perl 5.22 mass rebuild can start. I will start tomorrow morning and you can be notified via mail about commits and builds in next days. Please do not build anything into `f23-perl'. Boot-strapping core modules is very peculiar. I also track all changes. You can do your upgrades into rawhide freely in parallel. You can check status on Perl 5.22 change page https://fedoraproject.org/wiki/Changes/perl5.22 Regards, Jitka -- 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
Re: F23 System Wide Change: Default Local DNS Resolver
On Mon, Jun 01, 2015 at 09:31:14PM +0200, Reindl Harald wrote: Am 01.06.2015 um 20:30 schrieb Andrew Lutomirski: I would think that avoiding a single point of failure (your LAN nameserver) would be a *good* thing and your holy one and only resolver on localhost is not a single point of failure? in fact it would take much longer to recognize a failing and exclusive local resolver on 2 out of 1000 servers why it gets visible from the first second if your central nameservers have problems and BTW glibc has no problem with the first nameserver in /etc/resolv.conf failing as long as the slave responds, it may take a little time but that don't matter as long as we are not talking about a incoming mail exchanger I'm sorry, but saying that it may take a little time is a non-starter. For anyone who says this, I challenge you to set your system's resolv.conf so that the first listed nameserver is a completely offline IP address, and the second/third listed ones are your normal nameservers. Note that the first one must be completely offline, not an IP that is up but just doesn't have a listening nameserver, but an IP that is non-existent on your local network. E.g. if your local network is 192.168.1.0/24, set it to 192.168.1.unassigned-to-any-host. Make sure you can't ping the unassigned IP. There are many services that will choke in this sort of configuration. Not just mail servers, but RADIUS servers, LDAP servers, Samba servers, web servers depending on the configuration, SSH servers and clients, etc. Sure, if you test everything in this exact failure scenario, you may be able to work around this problem (e.g. turn off reverse DNS lookups in Apache and sshd, etc.) but if you run a LAN or data center with many different groups maintaining different systems, you can't guarantee that everyone has done this sort of rigorous testing and configurations to avoid problems, if it is even possible for some services which it may not be. Of course a localhost resolver is also a single point of failure. But the important property is that it is very much FATE SHARED with the rest of the system. So when you reboot the system to apply a security update, it doesn't matter that the localhost resolver is offline, because the services on that box are offline too. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
AppData Guidelines
I've reviewed Packaging:AppData https://fedoraproject.org/wiki/Packaging:AppData and have some questions. When running fedpkg lint, I receive:*copyq.x86_64: E: invalid-appdata-file /usr/share/appdata/copyq.appdata.xml* I then issue appstream-util validate copyq.appdata.xml and receive: *copyq.appdata.xml: FAILED: • tag-missing : name is not present • tag-missing : summary is not present Validation of files failed* However, when I run appstream-util validate-relax, it passes. The guidelines indicate you MUST follow the AppData Specification Page http://people.freedesktop.org/~hughsient/appdata/; but it doesn't really give an indication of what is required, and what is optional. It only says should; however: If you read the description of name and summary it says the contents for both of those fields are usually the same as the desktop file - which indicates it is known to be a duplicate of what is in the desktop file, but yet implies it is still required - otherwise why bother to point out the correlation to the desktop file. Upstream response is if they are duplicated in the desktop file, then they aren't needed in the appdata file. There is also a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1185361 which discusses rpmlint and validate-relax. It touches upon the fact that validate-relax may be missing some things, but doesn't appear to reach any conclusion. The Fedora guidelines say to use validate-relax, but rpmlint appears to use validate. Which is correct? Is name and summary optional or required? -- 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: F23 System Wide Change: Default Local DNS Resolver
On Tue, Jun 2, 2015 at 2:44 AM, Florian Weimer fwei...@redhat.com wrote: On 06/01/2015 10:57 PM, Andrew Lutomirski wrote: This is glibc we're talking about, though. Have you tried to get a glibc bug fixed? It's not a pleasant experience. It is possible, but it requires effort. Admittedly, sometimes that effort appears disproportionate to what is being fixed. In this particularly case, only *very* few people are familiar with resolv/, and test coverage for that part is extremely poor. For example, the bug I reported has a candidate patch. That patch isn't applied, and the patch looks like the bug might be a security issue. It's been in that state for months. This is not unusual for glibc. Can you explain why you think it is a security issue? I don't have any very specific reason, but it's a load from an array with the entirely wrong index, and the code is inscrutable. I don't know whether n is attacker-controlled. As a mitigating factor, it's a load, so it's probably not so terrible. Regardless, this seems like a bug wrangling failure. The fix was committed AFAICT, but no one updated the bug. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: AppData Guidelines
On 2 June 2015 at 17:17, Gerald B. Cox gb...@bzb.us wrote: Upstream response is if they are duplicated in the desktop file, then they aren't needed in the appdata file. This is old advice and no longer true. One mistake I made when first pushing AppStream was to fall back to the .desktop file Name= and Comment= lines even with AppData. This was bad for two reasons: * We can't validate the AppData file without the presence of the .desktop file * We rarely want the same desktop comment and the one-line software center summary; it can be and if it is then the translators don't have to do any more work as it's extracted and deduplicated but ideally the summary is a one line sell line. * It's a bit magic and makes things more complicated to explain The Fedora guidelines say to use validate-relax, but rpmlint appears to use validate. Which is correct? Is name and summary optional or required? If i was to have my time again, I'd say required, but I don't want to start ignoring AppData files that were once valid. Relaxed validation is probably the right thing to do to also ignore the style guideline which sometimes are false positives in some cases. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
no product firewall-config in bugzilla?
rpm -qf /usr/bin/firewall-config firewall-config-0.3.13-7.fc22.noarch But I can't select firewall-config in BZ! I filed my bug under firewalld instead. https://bugzilla.redhat.com/show_bug.cgi?id=1227419 -- Those who fail to understand recursion are doomed to repeat it -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: Default Local DNS Resolver
On Tue, 2 Jun 2015, David Howells wrote: Install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. The automatic name server entries received via dhcp/vpn/wireless configurations should be stored separately (e.g. this is stored in the NetworkManager internal state), as transitory name servers to be used by the trusted local resolver. In all cases, DNSSEC validation will be done locally. How does this interact with dnsmasq which also wants to be the only name server entry in resolv.conf? Not well? The problem is dnsmasq is not as feature complete as unbound (and its dnssec implementation is very new). I think most people end up running dnsmasq because of KVM/libvirtd ? I think those dnsmasq's should be run in dhcp only mode and point to the hosts's unbound. 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: no product firewall-config in bugzilla?
On Tue, 02 Jun 2015 11:50:07 -0400 Neal Becker ndbeck...@gmail.com wrote: rpm -qf /usr/bin/firewall-config firewall-config-0.3.13-7.fc22.noarch But I can't select firewall-config in BZ! I filed my bug under firewalld instead. https://bugzilla.redhat.com/show_bug.cgi?id=1227419 Yes, thats the right place. firewall-config is a subpackage of firewalld. See: https://apps.fedoraproject.org/packages/firewall-config/overview/ components are by source rpm. kevin pgpPYBpcvUGt2.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 22 for IBM z Systems is here!
We are proud to announce the official release of Fedora 22 for IBM z Systems, the community-driven and community-built operating system now available in Server edition. If that's all you need to hear, jump over to Get Fedora to download -- or for current users, run the FedUp upgrade tool. * https://fedoraproject.org/wiki/Architectures/s390x/22 * https://fedoraproject.org/wiki/FedUp In addition to the latest versions of all your favorite free and open source software, Fedora 22 marks our second release with distinctly-targeted offerings for cloud computing, and the server room. Thanks to the hard work of developers, designers, packagers, translators, testers, documentation writers, and everyone else, we're incredibly confident in saying that this is our best and most polished release yet. Also with this release, we return to our traditional six-month cadence -- we'll see you back here sometime around Halloween! Highlights in the Fedora 22 release === Every Fedora release has its own character. If this release had a human analogue, it'd be Fedora 21 after it'd been to college, landed a good job, and kept its New Year's Resolution to go to the gym on a regular basis. What we're saying is that Fedora 22 has built on the foundation we laid with Fedora 21 and the work to create distinct editions of Fedora focused on the desktop, server, and cloud (respectively). It's not radically different, but there are a fair amount of new features coupled with features we've already introduced but have improved for Fedora 22. Fedora Server - * Database Server Role -- The Fedora Server edition focuses on easy of different server roles. Fedora 21 debuted with an Domain Controller Role featuring FreeIPA. For this release, we've added a Database Server role, built around PostgreSQL. * Default to XFS filesystem -- The default file system type for Fedora Server installs will be XFS running atop LVM for all partitions except /boot. The /boot partition will remain a non-LVM, ext4 partition due to technological limitations of the bootloader. * Cockpit will be compatible between OS releases -- Cockpit is a server manager that makes it easy to administer your GNU/Linux servers via a web browser. - Easy to use. Cockpit is perfect for new sysadmins, allowing them to easily perform simple tasks such as storage administration, inspecting journals and starting and stopping services. - No interference. Jumping between the terminal and the web tool is no problem. A service started via Cockpit can be stopped via the terminal. Likewise, if an error occurs in the terminal, it can be seen in the Cockpit journal interface. - Multi-server. You can monitor and administer several servers at the same time. Other changes of note = Faster and better dependency management with DNF With Fedora 22, we're introducing a major change under the hood. Specifically, we're now using DNF and hawkey to manage packages. DNF is much like the Yum software package manager (it's largely command-line compatible), but re-written and re-engineered to provide optimal performance and (along with Hawkey) provide a strict API definition for plugins and extending projects. DNF also makes use of the libsolv library initially pioneered by the openSUSE Project to provide faster and better dependency management. It also boasts a better performance and memory footprint vs. Yum, and is designed to have a cleaner codebase and be easier to maintain. If you're using the Fedora 22 Workstation edition, and managing packages with the Software Application, odds are you won't notice a difference. Server and Cloud users who fall back on Yum commands will receive a reminder (courtesy of dnf-yum) that Yum is deprecated and DNF is now the default package manager. DNF has been in development for quite some time, so we're confident it's ready for prime time. The classic Yum command line tool has been renamed to yum-deprecated as a transitional step for tools still using it. See Read The Docs for compatibility changes from Yum to DNF in detail. GNU Compiler Collection 5 - Fedora 22 comes with GCC 5.1 as the primary compiler suite. Downloads, upgrades, documentation, and common bugs == You can start by downloading Fedora 22: * https://fedoraproject.org/wiki/Architectures/s390x/22 If you are upgrading from a previous release of Fedora, refer to: * http://fedoraproject.org/wiki/Upgrading Fedora's FedUp utility enables an easy upgrade to Fedora 22 from previous releases. See the FedUp page on the Fedora wiki for more information: * https://fedoraproject.org/wiki/FedUp Documentation - Read the full release notes for Fedora 22, guides for several languages, and learn about known bugs and how to report new ones: *
Re: F23 System Wide Change: Default Local DNS Resolver
On Mon, 2015-06-01 at 21:31 +0200, Reindl Harald wrote: Am 01.06.2015 um 20:30 schrieb Andrew Lutomirski: I would think that avoiding a single point of failure (your LAN nameserver) would be a *good* thing and your holy one and only resolver on localhost is not a single point of failure? No more than glibc, or any other component you have. in fact it would take much longer to recognize a failing and exclusive local resolver on 2 out of 1000 servers why it gets visible from the first second if your central nameservers have problems This is orthogonal to the problem being solved. and BTW glibc has no problem with the first nameserver in /etc/resolv.conf failing as long as the slave responds, it may take a little time but that don't matter as long as we are not talking about a incoming mail exchanger Yes there are situation where it doesn't matter ... and there are situation where it does. A local resolver has many advantages and very few disadvantages for the *general* case. Take it easy, it is not the end of the world. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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: F23 System Wide Change: Default Local DNS Resolver
On Mon, 2015-06-01 at 21:33 +0200, Reindl Harald wrote: Am 01.06.2015 um 21:28 schrieb Andrew Lutomirski: On Mon, Jun 1, 2015 at 12:25 PM, Ryan S. Brown rya...@redhat.com wrote: A local DNS resolver would certainly be a surprise to me. Again, this comes back to the expectation that a server isn't hopping networks or running somewhere un-trusted where there's a high risk of bad actors. It's not just bad actors. Sometimes things break or you need to reconfigure your upstream resolvers. With a local caching resolver, this Just Works (tm). With the status quo, it requires restarting everything WHAT - the opposite is true, glibc don't cache nameserver respones and *now* if you change something on your central resolvers it gets visible on any machine in your network with having a local cache on 1000 nodes *then* it requires restarting everyting - so exactly the opposite you are saying You are assuming a specific configuration where the local resolver caches for the full ttl period and also caches negative hits. That's not necessarily true. With a caching period that does not exceed the ttl (but usually much shorter) for positive resolution and very short caching for negative results you would experience very little latency and generally not see any impact. Stop assuming how it works, and ask first, please. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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: F23 System Wide Change: Default Local DNS Resolver
On Mon, 2015-06-01 at 21:44 +0200, Reindl Harald wrote: Am 01.06.2015 um 21:38 schrieb Andrew Lutomirski: On Mon, Jun 1, 2015 at 12:29 PM, Chris Adams li...@cmadams.net wrote: Once upon a time, Andrew Lutomirski l...@mit.edu said: I'm with Jason here. Glibc's resolver is amazingly buggy, and things break randomly and unreproducibly when this happens. A good setup would have a local resolver and glibc would be configured to cache nothing whatsoever. Then, if you need to perform maintenance on the local DNS cache, you can do it by flushing your local resolver rather than trying to figure out how you're going to persuade every running program to tell glibc to flush its cache. glibc doesn't have a cache, except each process caching the settings in /etc/resolv.conf. That's part of the problem, because there's no way to cache first server in resolv.conf is not responding, so each lookup has to figure that out for itself (many timeouts). Glibc caches *something* that enabled the bug I hit. I don't know exactly what it's trying to cache, but it's certainly stateful it don't cache dns respones - try it out in your local network *client applications* may cache respones try it out in your local network * enter a non existing subdomain in firefox * add the hostname to your LAN nameserver * try again: firefox refuses * restart just firefox * it resolves without any delay a) that proves no systemwide cachae b) it proves with introduce a local systemdwide cache you introduce a problem not existing before If you have nscd running glibc caches, so it is a matter of configuration. The *only* reason why Firefox caches Names is because we do not have a local dns caching resolver, so Firefox had to implement its own. If you had a local caching resolver Firefox could be changed to stop caching on its own instead. Which would be a plus, I often have way too many tabs open to consider restarting firefox unless the website with issues is really important. If i had a local resolver it would be easy to just flush that one and have FF back in business immediately. As you see it is a matter of perspective. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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: F23 System Wide Change: Default Local DNS Resolver
On Mon, 2015-06-01 at 23:15 +0200, Reindl Harald wrote: a sane system should be as simple as possible so that *one* human is able to determine what is happening without hire 10 specialists for each layer There is no human able to understand a complex system like modern computers and OSs, it is just an illusion. But we can improve user's lives better by providing defaults that make the system work better in the general case and leave to specialists with special needs to tweak the system or remove unwanted layers. in short: leave me in peace with defaults raising complexity more and more, i have enough with dbus, a now essential service which cant be restarted after updates of underlying libraries while it was no problem over many years to type chkconfig messagebus off on servers and have no single process except the services you installed and configured You are free to keep using your kickstart files, nobody is going to mess with those. you already have many other special needs apparently, so can you stop getting mad whenever there is *any* change ? The world is not static, it keeps changing and we can adapt or die. We, as a community, are adapting, but you as an individual are free to diverge with your personal configuration. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
