EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 711 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 58 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0440/fwsnort-1.6.4-1.el6 53 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0483/boinc-client-7.2.33-3.git1994cc8.el6 43 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0590/oath-toolkit-2.0.2-4.el6 18 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0846/mediawiki119-1.19.13-1.el6 14 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0888/v8-3.14.5.10-7.el6 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0938/seamonkey-2.21-5.ESR_24.4.0.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0980/perl-YAML-LibYAML-0.38-4.el6 4 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0996/munin-2.0.20-1.el6 4 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0990/libyaml-0.1.6-1.el6 2 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1011/php-ZendFramework-1.12.5-1.el6 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1020/php-ZendFramework2-2.2.6-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1039/mod_security-2.7.3-3.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1044/ansible-1.5.4-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1050/check-mk-1.2.4p1-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing ansible-1.5.4-1.el6 check-mk-1.2.4p1-1.el6 nodejs-exit-0.1.2-1.el6 nodejs-faye-websocket-0.7.2-2.el6 nodejs-getobject-0.1.0-1.el6 nodejs-grunt-0.4.4-1.el6 nodejs-grunt-compare-size-0.4.0-1.el6 nodejs-grunt-contrib-watch-0.6.1-1.el6 nodejs-grunt-git-authors-1.2.0-2.el6 nodejs-grunt-legacy-util-0.1.2-1.el6 nodejs-noptify-0.0.3-2.el6 nodejs-testswarm-1.1.0-1.el6 nodejs-tiny-lr-fork-0.0.5-2.el6 nodejs-websocket-driver-0.3.2-2.el6 perl-Business-Stripe-0.04-1.el6 stonevpn-0.4.15-1.el6 subnetcalc-2.2.1-1.el6 Details about builds: ansible-1.5.4-1.el6 (FEDORA-EPEL-2014-1044) SSH-based configuration management, deployment, and task execution system Update Information: https://github.com/ansible/ansible/blob/release1.5.4/CHANGELOG.md * Security fix for safe_eval, which further hardens the checking of the evaluation function. * Fix for accelerate mode * Add a missing dependency on python-setuptools ChangeLog: * Wed Apr 2 2014 Toshio Kuratomi tos...@fedoraproject.org - 1.5.4-1 - Update to 1.5.4 - Add upstream patch to fix accelerator mode - Merge fedora and el6 spec files * Fri Mar 14 2014 Kevin Fenzi ke...@scrye.com 1.5.3-2 - Update to NEW 1.5.3 upstream release. - Add missing dependency on python-setuptools (el6 build) * Thu Mar 13 2014 Kevin Fenzi ke...@scrye.com 1.5.3-1 - Update to 1.5.3 - Fix ansible-vault for newer python-crypto dependency (el6 build) References: [ 1 ] Bug #1083419 - Missing dependency python-setuptools https://bugzilla.redhat.com/show_bug.cgi?id=1083419 check-mk-1.2.4p1-1.el6 (FEDORA-EPEL-2014-1050) A new general purpose Nagios-plugin for retrieving data Update Information: Fixes CVEs: - CVE-2014-2329 - CVE-2014-2330 - CVE-2014-2331 - CVE-2014-2332 ChangeLog: * Wed Apr 2 2014 Andrea Veri av...@fedoraproject.org - 1.2.4p1-1 - New upstream release. Fixes the missing two CVEs that were still left unfixed on 1.2.4: - CVE-2014-2330 - CVE-2014-2331 * Tue Mar 25 2014 Andrea Veri av...@fedoraproject.org - 1.2.4-1 - New upstream release. Fixes the following CVEs: - CVE-2014-2329 - CVE-2014-2332 References: [ 1 ] Bug #1080303 - CVE-2014-2329 CVE-2014-2330 CVE-2014-2331 CVE-2014-2332 check-mk: multiple flaws fixed in versions 1.2.2p3 and 1.2.3i5 https://bugzilla.redhat.com/show_bug.cgi?id=1080303 nodejs-exit-0.1.2-1.el6 (FEDORA-EPEL-2014-1045) A process.exit alternative that ensures STDIO are fully drained before exiting
Re: Heads up: retiring xorg-x11-drv-mouse and xorg-x11-drv-keyboard
On Thu, Apr 03, 2014 at 12:40:45AM -0400, Gary Gatling wrote: On Thu, Apr 3, 2014 at 12:09 AM, Peter Hutterer peter.hutte...@who-t.netwrote: My plan is to retire these two xorg input drivers in rawhide in a week or two. They are superseded by the evdev driver which is the default driver for input devices in Linux. Speak up now, or forever hold yada yada... Hello Peter, With the software bumblebee, there seems to be a need for these packages. But I am not really sure why. I don't know if the evdev driver could work around this problem? If the packages are not installed, then the error message one gets is: [ 901.442296] [ERROR]Cannot access secondary GPU - error: XORGhttps://github.com/Bumblebee-Project/Bumblebee/issues/EEFailed to load module mouse The solution I was told on github is to install xorg-x11-drv-mouse and xorg-x11-drv-keyboard packages. Which did indeed solve the problem in fedora 20. The xorg.conf file in this case is: /etc/bumblebee/xorg.conf.nvidia The bumblebee developers have set Option AutoAddDevices false Should that / can that be changed do you think? That's exactly one of the examples I mentioned in my original email: _why_ is this line there? :) If fixes the problem but that doesn't tell the whole story. You have a conf that implicitly says load the mouse driver and then fails because you didn't have the mouse driver installed. Which is fair enough, the question here is why is that setting there in the first place? Is the goal to not add any devices, or is this just an accidental leftover? the git history of that file doesn't really provide any hints here, unfortunately. Cheers, Peter Just wanted to mention this in case other fedora users have optimus laptops they use with the nvidia drivers? bumblebee is a solution that has been invented for hybrid graphics laptops with intel and Nvidia GPUs. It runs another X server in memory and copies the visuals with software. Either with VirtualGL or primus. Cheers, -- 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: bumblebee reviewer needed (Was: Re: Heads up: retiring xorg-x11-drv-mouse and xorg-x11-drv-keyboard)
On 3 April 2014 06:50, Christopher Meng cicku...@gmail.com wrote: Just another note that due to my knowledge on optimus I decide to drop the review of bumblebee[1], and someone told me it's just a dirty hack. I personally think it as a hack as well. Problems with Nouveau performance and power managment aside, current Prime with open drivers is a much better and elegant solution. Regards, --Simone -- You cannot discover new oceans unless you have the courage to lose sight of the shore (R. W. Emerson). http://xkcd.com/229/ http://negativo17.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: lbzip2 as default bzip2 implementation
On Wed, Apr 2, 2014 at 11:27 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: ** possibly adjust spec files to require or build-require lbzip2 instead of bzip2. Is this necessary? I don't think so. A better way would be to change them to depend on the actual executables they use, /usr/bin/bzip2 etc. Naturally, the lbzip2/bzip2 alternative packaging needs to be properly done so that this is possible, but I assume that's going to be done in any case. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Packaging of libdb-6+
Hello, as Oracle is unlikely to re-license the libdb6 back to GPL, I like to bring up the possibility of the libdb6 package. The idea is that the current libdb package would still provide the libdb-5+, which is still under GPL, and the new package would provide the newest, AGPL-ed libdb. I would like to hear opinions on this idea, and any suggestions are welcome. Cheers, Jan -- Jan Stanek - Red Hat Associate Developer Engineer - Databases Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging of libdb-6+
Since AGPL is fedora-compliant license, there's no blocker to get libdb6 into packages collection. Besides, libdb5 is still critical for many packages (like RM), until we get rid of it, I can only agree with your proposal. Maybe, it's still time to rename the current libdb = libdb5 and get newer releases named libdb starting F21 best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 04/03/2014 03:47 AM, Chris Adams wrote: Many of the common users (such as rpm) are linked against the library and don't use the command, so they won't be impacted. rpm does use bzip2 *command* and it would be impacted by this change. rpm uses libbz2 only for compression and decompression of rpm package payloads. Since Fedora uses LZMA compression, libbz2 is used only when installing some older third-party packages which happen to be compressed with bzip2. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Self Introduction: Oden Eriksson
Hello, Been active with packaging, productization and maintaining packages for Mandriva Linux since 1999 and thought I should give it a try at fedora. First cut is this one: https://bugzilla.redhat.com/show_bug.cgi?id=1083962 And, it seems I need a sponsor here. Anyone? Cheers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: lbzip2 as default bzip2 implementation
On Thu, Apr 3, 2014 at 1:03 PM, Mikolaj Izdebski mizde...@redhat.com wrote: rpm does use bzip2 *command* To be more precise, I believe only rpmbuild does. -- 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 1081883] perl-Scriptalicious-1.16 tests hang randomly
https://bugzilla.redhat.com/show_bug.cgi?id=1081883 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-Scriptalicious-1.17-1. ||fc21 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=BdpW4XNO4Na=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Meeting minutes from Env-and-Stacks WG meeting (2014-04-01)
On 04/03/2014 03:46 AM, Toshio Kuratomi wrote: I saw that this got voted on in the meeting even though it didn't get recorded as such for the meeting minutes. The proposal seemed to be: use obs-sign to sign packages. That's not actually a proposal that we can approve here. The proposal here should probably be: is signing of packages a blocker for making the playground repo, nice to have, or optional? In terms of how to get the packages signed, that's something that the infrastructure team has to decide. IIRC past conversations correctly, adding another signing server (meaning a different code base) to infrastructure is at the bottom of their list of ways to sign packages in copr (and by extension in the playground repo). When I saw the vote in the meeting logs I mentioned it to nirik. In turn he told me that he hadn't heard anything about this and had only glanced briefly at obs-sign (mentioning that it wasn't even packaged for Fedora yet). As I related to tjanez on IRC today, I think lack of packaging probably slows down infra's ability to deploy it but is only a foottnote to the real problems. Compromising signing servers and gaining access to the private keys on them is a very high value target for an attacker. The more signing servers we have the greater the attack surface infrastructure has to protect. probably in the ideal scenario infra would run a single signing server and everything needing signing would be sent to that. (Jesse Kating had that use in mind when he designed sigul but I don't know if that design goal actually became part of the software that we are currently running). A step down from there might be running multiple instances of the same signing software to handle the various needs as infra would then have to protect the keys on these multiple hosts. At the bottom of the list is running separate signing software as that places the additional burden of auditing and protecting the software stack of the multiple signing servers. For whoever is going to approach infra about signing the packages in copr it probably makes more sense to either talk about enhancing sigul to work with copr or getting obs-sign to be able to sign packages from koji. We'd probably also want to ask bressers or someone else from the security team to do some sort of evaluation of the code bases that we're looking at. That would be probably me. I mean the guy who will be implementing signing of packages in Copr. I investigated several possibilities and talked to several people. But you are correct that I did not send conclusion to mailing list yet. Maybe it is right time to do it now. One of the guy to who I talked to is Miroslav Trmac, who is current maintainer and main author of Sigul since 2009. The conclusion from discussion with him is that: * we would need need different instance, because to use the same instance for main distribution and for relaxed ring (Copr, Playground...) is not best idea. Neither from security POV nor for technical implementation. (*) * we would need to do some development of Sigul before deploying new instance * and we would likely should migrate to gpg2 (from gpg1) * Sigul have very restricted network setup, which is probably not needed for Copr On the other hand obs-sign: * is actively maintained * is more simple * used in OBS as well (which mean community and so on) * have security model and network setup good enough for Copr (I arranged meeting of Adrian Shröter from OBS and Mirek Trmač during DevConf.cz where they discussed technical details and none of them seen any blocker). Yes, obs-sign is not packaged for Fedora (yet), but the spec exists and I can get it in Fedora withing week. I do not see that as problem. If I sum it up, then obs-sign is clear winner to me. Therefore this is the way I would like to go in Copr. But it still does not bubble up in my TODO list. So we have plenty of time for discussion :) (*) You suggested that having one signing server is better as The more signing servers we have the greater the attack surface infrastructure has to protect. I disagree. First: it is not technical possible. Because Koji and current Sigul is in different networks and I'm not sure if we want to change it. Likely not. Second: if you compromise Copr signing server then you have compromised main distribution. Therefore even from security POV is better to have different signing server for main distribution and for Copr. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
On Wed, 2014-04-02 at 19:15 -0400, Matthew Miller wrote: On Wed, Apr 02, 2014 at 02:12:50PM -0400, Simo Sorce wrote: How does someone express strong disagreement to this change ? Posting here is a good start. You can also add a note in the FESCo ticket for approval once one is filed, and if you are incredibly passionate you can come to the FESCo meeting (although I'm hoping we can make those meetings more efficient, so that's not a good place for back and forth -- if possible we should work out the issues before the meeting). Ticket number ? This change makes it very hard to do necessary maintenance. I can understand blocking SSH login as root with password by default, but I do not understand what is the point of blocking console login as root. I assume that it's for a kiosk or public (or at least managed) lab situation. It makes sense for that, but I'm not convinced of a benefit otherwise, and I don't think that situation is the default I am not even sure it makes sense in a kiosk, unless people want to use password as their root password. But even if it made sense in that situation it is far from being a useful *default*. This kind of severely restricting measure is best left to hardening manuals. 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: Meeting minutes from Env-and-Stacks WG meeting (2014-04-01)
On 04/03/2014 02:29 PM, Miroslav Suchý wrote: On 04/03/2014 03:46 AM, Toshio Kuratomi wrote: I saw that this got voted on in the meeting even though it didn't get recorded as such for the meeting minutes. The proposal seemed to be: use obs-sign to sign packages. That's not actually a proposal that we can approve here. The proposal here should probably be: is signing of packages a blocker for making the playground repo, nice to have, or optional? In terms of how to get the packages signed, that's something that the infrastructure team has to decide. IIRC past conversations correctly, adding another signing server (meaning a different code base) to infrastructure is at the bottom of their list of ways to sign packages in copr (and by extension in the playground repo). When I saw the vote in the meeting logs I mentioned it to nirik. In turn he told me that he hadn't heard anything about this and had only glanced briefly at obs-sign (mentioning that it wasn't even packaged for Fedora yet). As I related to tjanez on IRC today, I think lack of packaging probably slows down infra's ability to deploy it but is only a foottnote to the real problems. Compromising signing servers and gaining access to the private keys on them is a very high value target for an attacker. The more signing servers we have the greater the attack surface infrastructure has to protect. probably in the ideal scenario infra would run a single signing server and everything needing signing would be sent to that. (Jesse Kating had that use in mind when he designed sigul but I don't know if that design goal actually became part of the software that we are currently running). A step down from there might be running multiple instances of the same signing software to handle the various needs as infra would then have to protect the keys on these multiple hosts. At the bottom of the list is running separate signing software as that places the additional burden of auditing and protecting the software stack of the multiple signing servers. For whoever is going to approach infra about signing the packages in copr it probably makes more sense to either talk about enhancing sigul to work with copr or getting obs-sign to be able to sign packages from koji. We'd probably also want to ask bressers or someone else from the security team to do some sort of evaluation of the code bases that we're looking at. That would be probably me. I mean the guy who will be implementing signing of packages in Copr. I investigated several possibilities and talked to several people. But you are correct that I did not send conclusion to mailing list yet. Maybe it is right time to do it now. One of the guy to who I talked to is Miroslav Trmac, who is current maintainer and main author of Sigul since 2009. The conclusion from discussion with him is that: * we would need need different instance, because to use the same instance for main distribution and for relaxed ring (Copr, Playground...) is not best idea. Neither from security POV nor for technical implementation. (*) * we would need to do some development of Sigul before deploying new instance * and we would likely should migrate to gpg2 (from gpg1) * Sigul have very restricted network setup, which is probably not needed for Copr On the other hand obs-sign: * is actively maintained * is more simple * used in OBS as well (which mean community and so on) * have security model and network setup good enough for Copr (I arranged meeting of Adrian Shröter from OBS and Mirek Trmač during DevConf.cz where they discussed technical details and none of them seen any blocker). Yes, obs-sign is not packaged for Fedora (yet), but the spec exists and I can get it in Fedora withing week. I do not see that as problem. If I sum it up, then obs-sign is clear winner to me. Therefore this is the way I would like to go in Copr. But it still does not bubble up in my TODO list. So we have plenty of time for discussion :) (*) You suggested that having one signing server is better as The more signing servers we have the greater the attack surface infrastructure has to protect. I disagree. First: it is not technical possible. Because Koji and current Sigul is in different networks and I'm not sure if we want to change it. Likely not. Second: if you compromise Copr signing server then you have compromised main distribution. Therefore even from security POV is better to have different signing server for main distribution and for Copr. The summary of Mirek's notes was for a long time in Open Questions section [1]. I removed it yesterday, because it was voted for obs-signd. Mirek is member of infra, so I leave the discussion up to him. [1] https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft%29#Open_Questions Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: retiring xorg-x11-drv-mouse and xorg-x11-drv-keyboard
2014-04-03 6:09 GMT+02:00 Peter Hutterer peter.hutte...@who-t.net: This _will_ break some setups. If you have AutoAddDevices off in your xorg.conf then this will break. The main question to ask here is: do these setups still exist and if so why do you have that option set and can we fix the reason for it being set in the first place? Would it be at all possible to write a %post script that modifies the configs to keep users' systems working? I suspect the answer is no but it's still worth asking. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging of libdb-6+
On 04/03/2014 11:20 AM, H. Guémar wrote: Since AGPL is fedora-compliant license, there's no blocker to get libdb6 into packages collection. Besides, libdb5 is still critical for many packages (like RM), until we get rid of it, I can only agree with your proposal. Maybe, it's still time to rename the current libdb = libdb5 and get newer releases named libdb starting F21 This would be possible only by co-operation with the depended packages, since they usually use BuildRequire: libdb-devel. So after just rebuilding those to link against libdb-6, some of the packages would start to suffer from license incompatibilities. But I agree that libdb-6.x + libdb5-5.x scenario looks better than libdb-5.x + libdb6-6.x. Anyway, to make some marketing for this change, we should have a Self contained change page for this [1]. Change Proposals Submission Deadline is 2014-04-08 btw. [1] http://fedoraproject.org/wiki/Changes/Policy#Self_contained_changes Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: RPM-4.12
On 04/02/2014 07:47 PM, Jaroslav Reznik wrote: * Support for weak dependencies Does this mean that rpm-build will be able to create packages with weak dependencies? Will Fedora packages be allowed to declare weak dependencies? Is dependency generator interface going to be extended so that we can generate auto-recommends and auto-suggests for packages? * Support for packaging files 4GB * Support for real package reinstallation * New API for accessing files and file contents * New tool for converting rpm packages to tar files * Internal plugin interface Are there any details abuout this interface available somewhere? Will packages be able to provide plugins, like for example they can install RPM macros now? -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: retiring xorg-x11-drv-mouse and xorg-x11-drv-keyboard
On Thu, 2014-04-03 at 16:35 +1000, Peter Hutterer wrote: If fixes the problem but that doesn't tell the whole story. You have a conf that implicitly says load the mouse driver and then fails because you didn't have the mouse driver installed. Which is fair enough, the question here is why is that setting there in the first place? Is the goal to not add any devices, or is this just an accidental leftover? I think the goal _is_ to not add any devices, yes. Bumblebee is basically a second X server to run on the nvidia gpu and pipe the pixels off that to the integrated gpu. So input only ever happens on the integrated gpu's server, so you want to keep the bumblebee server away from event devices. (I think; I've never actually run it.) - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GnuTLS issue (Mandos Server/Client)
On Wed, 2014-04-02 at 10:50 -0600, Nathanael D. Noblet wrote: CentOS 6 = gnutls 2.8.5 F20 = gnutls 3.1.20 The server is a python app and sets the priority string as follows: priority=SECURE256:!CTYPE-X.509:+CTYPE-OPENPGP this is fed to some gnutls function somewhere in the stack. Does it really use TLS with openpgp certificates? If yes, I doubt you could make 2.8.5 interoperate with gnutls 3.1.20. GnuTLS was modified in 3.1.x to adhere with RFC6091 which was incompatible the previous attempt to have openpgp keys to TLS. regards, Nikos -- 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 1084058] New: perl-MooseX-Types-DateTime-MoreCoercions-0.11-2.fc21 FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1084058 Bug ID: 1084058 Summary: perl-MooseX-Types-DateTime-MoreCoercions-0.11-2.fc21 FTBFS Product: Fedora Version: rawhide Component: perl-MooseX-Types-DateTime-MoreCoercions Assignee: ppi...@redhat.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: perl-de...@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com perl-MooseX-Types-DateTime-MoreCoercions-0.11-2.fc21 fails to build in F21: Provádění(%build): /bin/sh -e /var/tmp/rpm-tmp.miIpx2 + umask 022 + cd /builddir/build/BUILD + cd MooseX-Types-DateTime-MoreCoercions-0.11 + perl Makefile.PL INSTALLDIRS=vendor include /builddir/build/BUILD/MooseX-Types-DateTime-MoreCoercions-0.11/inc/Module/Install.pm include inc/Module/Install/Metadata.pm include inc/Module/Install/Base.pm include inc/Module/Install/Makefile.pm include inc/Module/Install/AutoInstall.pm include inc/Module/Install/Include.pm include inc/Module/AutoInstall.pm *** Module::AutoInstall version 1.06 *** Checking for Perl dependencies... [Core Features] - Test::use::ok ...loaded. (0.11 = 0.02) - Test::Exception ...loaded. (0.32 = 0.27) - Test::More ...loaded. (1.001003) - Moose ...loaded. (2.1005 = 0.41) - MooseX::Types ...loaded. (0.35 = 0.04) - namespace::clean...loaded. (0.25 = 0.08) - Time::Duration::Parse ...loaded. (0.11 = 0.06) - MooseX::Types::Moose...loaded. (0.35 = 0.04) - MooseX::Types::DateTime ...loaded. (0.08 = 0.07) - DateTime...loaded. (1.08 = 0.4302) - DateTime::Duration ...loaded. (1.08 = 0.4302) - DateTimeX::Easy ...loaded. (0.089 = 0.085) *** Module::AutoInstall configuration finished. include inc/Module/Install/WriteAll.pm include inc/Module/Install/Win32.pm include inc/Module/Install/Can.pm include inc/Module/Install/Fetch.pm Checking if your kit is complete... Looks good Generating a Unix-style Makefile Writing Makefile for MooseX::Types::DateTime::MoreCoercions Writing MYMETA.yml and MYMETA.json Error reading from file 'META.yml': utf8 \xE5 does not map to Unicode at /usr/share/perl5/vendor_perl/Module/Install/Admin/Metadata.pm line 14. The META.yml file is not in Unicode and unbundled modules in F21 are stricter and bail out. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=WvI6OXYlrBa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Considering GNOME 3.12 as an F20 update
Hey, so the time has come to consider this - thanks to the great work of Richard and Kalev on the copr, we have a set of 3.12 packages that have already received fairly wide testing. But we should be careful, so I want to ask for concrete problem reports with the copr packages, besides dependency problems caused by the parallel nature of the copr itself. Did any of your gnome-shell extensions break ? Did you experience crashes or other serious problems with applications ? If so, please let us know on the desktop list. If I don't hear of major problems by next week, I'll file a Fesco ticket to ask for an exception. Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1084058] perl-MooseX-Types-DateTime-MoreCoercions-0.11-2.fc21 FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1084058 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-MooseX-Types-DateTime- ||MoreCoercions-0.11-3.fc21 Resolution|--- |RAWHIDE Last Closed||2014-04-03 10:23:14 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=LDR8Qu0YuBa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Heads up: retiring xorg-x11-drv-mouse and xorg-x11-drv-keyboard
On Thu, Apr 3, 2014 at 9:58 AM, Adam Jackson a...@redhat.com wrote: I think the goal _is_ to not add any devices, yes. Bumblebee is basically a second X server to run on the nvidia gpu and pipe the pixels off that to the integrated gpu. So input only ever happens on the integrated gpu's server, so you want to keep the bumblebee server away from event devices. (I think; I've never actually run it.) - ajax Thanks a lot for the feedback. I have asked the developers for input. I opened a issue of the github issue tracker here: https://github.com/Bumblebee-Project/Bumblebee/issues/568 Cheers, -- 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: [CHANGE PROPOSAL] The securetty file is empty by default
This change will not affect logging into the console using the local account and then doing su to get root privileges. Is there a problem with logging into the local user account and then typing su and the root password? You are as such prompted to make a local user account when doing an install from the Live CD. 3.1.4.2.2. Disabling Root Logins To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty file. This file lists all devices the root user is allowed to log into. If the file does not exist at all, the root user can log in through any communication device on the system, whether via the console or a raw network interface. This is dangerous, because a user can log in to his machine as root via Telnet, which transmits the password in plain text over the network. By default, Fedora's /etc/securetty file only allows the root user to log in at the console physically attached to the machine. To prevent root from logging in, remove the contents of this file by typing the following command: echo /etc/securetty Warning A blank /etc/securetty file does not prevent the root user from logging in remotely using the OpenSSH suite of tools because the console is not opened until after authentication. The change will NOT affect: Programs that do not log in as root, but perform administrative tasks through setuid or other mechanisms...The following programs are NOT PREVENTED from accessing the root account: su, sudo, ssh, scp, sftp On Thu, Apr 3, 2014 at 6:06 AM, Simo Sorce s...@redhat.com wrote: On Wed, 2014-04-02 at 19:15 -0400, Matthew Miller wrote: On Wed, Apr 02, 2014 at 02:12:50PM -0400, Simo Sorce wrote: How does someone express strong disagreement to this change ? Posting here is a good start. You can also add a note in the FESCo ticket for approval once one is filed, and if you are incredibly passionate you can come to the FESCo meeting (although I'm hoping we can make those meetings more efficient, so that's not a good place for back and forth -- if possible we should work out the issues before the meeting). Ticket number ? This change makes it very hard to do necessary maintenance. I can understand blocking SSH login as root with password by default, but I do not understand what is the point of blocking console login as root. I assume that it's for a kiosk or public (or at least managed) lab situation. It makes sense for that, but I'm not convinced of a benefit otherwise, and I don't think that situation is the default I am not even sure it makes sense in a kiosk, unless people want to use password as their root password. But even if it made sense in that situation it is far from being a useful *default*. This kind of severely restricting measure is best left to hardening manuals. 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 -- 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: [CHANGE PROPOSAL] The securetty file is empty by default
Am 03.04.2014 16:32, schrieb quickbooks office: This change will not affect logging into the console using the local account and then doing su to get root privileges. Is there a problem with logging into the local user account and then typing su and the root password? i do *not* need a local user account on machines typically running without any local user and *if i need to login there* i do that *because* i need to maintain that machine as root and that is why i *do not* have a user besides root because all other users for cronjobs and services have no shell at all so no, don't break useful setups with defaults 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: [CHANGE PROPOSAL] The securetty file is empty by default
On Thu, 2014-04-03 at 07:32 -0700, quickbooks office wrote: This change will not affect logging into the console using the local account and then doing su to get root privileges. What local account ? Is there a problem with logging into the local user account and then typing su and the root password? Yes, in most installation I do not have any local user, I have only users coming via LDAP, and if the problem I need to solve is that the LDAP part of the equation is broken I have no user to log in if root is disabled. You are as such prompted to make a local user account when doing an install from the Live CD. Which is not the only mean of installing, nor the main mean for me (I never used the LiveCD for installing). You are clearly making assumptions that do not hold for the general case. Simo. 3.1.4.2.2. Disabling Root Logins To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty file. This file lists all devices the root user is allowed to log into. If the file does not exist at all, the root user can log in through any communication device on the system, whether via the console or a raw network interface. This is dangerous, because a user can log in to his machine as root via Telnet, which transmits the password in plain text over the network. By default, Fedora's /etc/securetty file only allows the root user to log in at the console physically attached to the machine. To prevent root from logging in, remove the contents of this file by typing the following command: echo /etc/securetty Warning A blank /etc/securetty file does not prevent the root user from logging in remotely using the OpenSSH suite of tools because the console is not opened until after authentication. The change will NOT affect: Programs that do not log in as root, but perform administrative tasks through setuid or other mechanisms...The following programs are NOT PREVENTED from accessing the root account: su, sudo, ssh, scp, sftp On Thu, Apr 3, 2014 at 6:06 AM, Simo Sorce s...@redhat.com wrote: On Wed, 2014-04-02 at 19:15 -0400, Matthew Miller wrote: On Wed, Apr 02, 2014 at 02:12:50PM -0400, Simo Sorce wrote: How does someone express strong disagreement to this change ? Posting here is a good start. You can also add a note in the FESCo ticket for approval once one is filed, and if you are incredibly passionate you can come to the FESCo meeting (although I'm hoping we can make those meetings more efficient, so that's not a good place for back and forth -- if possible we should work out the issues before the meeting). Ticket number ? This change makes it very hard to do necessary maintenance. I can understand blocking SSH login as root with password by default, but I do not understand what is the point of blocking console login as root. I assume that it's for a kiosk or public (or at least managed) lab situation. It makes sense for that, but I'm not convinced of a benefit otherwise, and I don't think that situation is the default I am not even sure it makes sense in a kiosk, unless people want to use password as their root password. But even if it made sense in that situation it is far from being a useful *default*. This kind of severely restricting measure is best left to hardening manuals. 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: F21 System Wide Change: RPM-4.12
Mikolaj Izdebski wrote: Re: F21 System Wide Change: RPM-4.12 From: Mikolaj Izdebski mizde...@redhat.com Reply-To: Development discussions related to Fedora devel@lists.fedoraproject.org Date: Thursday, April 03, 2014 08:54:18 AM To: devel@lists.fedoraproject.org Groups: gmane.linux.redhat.fedora.devel References: 1 On 04/02/2014 07:47 PM, Jaroslav Reznik wrote: * Support for weak dependencies Does this mean that rpm-build will be able to create packages with weak dependencies? Yes. Will Fedora packages be allowed to declare weak dependencies? I suspect the best short answer would be: no (for now), at least until packaging tools (yum, dnf, packagekit) and some packaging guidelines are written to support this new feature. -- Rex -- 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: Considering GNOME 3.12 as an F20 update
On Thu, Apr 03, 2014 at 10:20:30AM -0400, Matthias Clasen wrote: Did any of your gnome-shell extensions break ? Isn't this inevitable? If any extensions only claim to support 3.10 then they'll stop working until updated. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: retiring xorg-x11-drv-mouse and xorg-x11-drv-keyboard
On Thu, Apr 3, 2014 at 10:23 AM, Gary Gatling gsgat...@ncsu.edu wrote: Thanks a lot for the feedback. I have asked the developers for input. I opened a issue of the github issue tracker here: https://github.com/Bumblebee-Project/Bumblebee/issues/568 After further experimentation it seems that xorg-x11-drv-mouse and xorg-x11-drv-keyboard are not needed for bumblebee after all in fedora. So I don't have any objections to you retiring both of those packages. Thanks a lot for all the useful feedback on this. -- 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: Considering GNOME 3.12 as an F20 update
2014-04-03 16:52 GMT+02:00 Matthew Garrett mj...@srcf.ucam.org: On Thu, Apr 03, 2014 at 10:20:30AM -0400, Matthias Clasen wrote: Did any of your gnome-shell extensions break ? Isn't this inevitable? If any extensions only claim to support 3.10 then they'll stop working until updated. One, at least theoretical, way to resolve this would be to update all extensions hosted at extensions.gnome.org to support 3.12. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
Once upon a time, quickbooks office quickbooks.off...@gmail.com said: This change will not affect logging into the console using the local account and then doing su to get root privileges. The only local account on many (most?) systems with network authentication is root. -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
On Thu, 3 Apr 2014, Simo Sorce wrote: On Thu, 2014-04-03 at 07:32 -0700, quickbooks office wrote: This change will not affect logging into the console using the local account and then doing su to get root privileges. What local account ? Is there a problem with logging into the local user account and then typing su and the root password? Yes, in most installation I do not have any local user +1 The ability to login as root over the (virtual) serial console is very important. If anything, securetty should include all those (virtual) serials ports per default. 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: Considering GNOME 3.12 as an F20 update
On Thu, Apr 03, 2014 at 04:57:10PM +0200, Miloslav Trmač wrote: 2014-04-03 16:52 GMT+02:00 Matthew Garrett mj...@srcf.ucam.org: Isn't this inevitable? If any extensions only claim to support 3.10 then they'll stop working until updated. One, at least theoretical, way to resolve this would be to update all extensions hosted at extensions.gnome.org to support 3.12. Don't the extensions end up in the user's home directory? How can we forcibly update them? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Considering GNOME 3.12 as an F20 update
On 04/03/2014 02:20 PM, Matthias Clasen wrote: Hey, so the time has come to consider this - thanks to the great work of Richard and Kalev on the copr, we have a set of 3.12 packages that have already received fairly wide testing. But we should be careful, so I want to ask for concrete problem reports with the copr packages, besides dependency problems caused by the parallel nature of the copr itself. Did any of your gnome-shell extensions break ? Did you experience crashes or other serious problems with applications ? If so, please let us know on the desktop list. If I don't hear of major problems by next week, I'll file a Fesco ticket to ask for an exception. Are you going to be delivering drastic changes to peoples UI interface by updating Gnome to a new Gnome release in a middle of GA cycle? Has FESCo approved this? JBG -- 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: Considering GNOME 3.12 as an F20 update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2014 10:52 AM, Matthew Garrett wrote: On Thu, Apr 03, 2014 at 10:20:30AM -0400, Matthias Clasen wrote: Did any of your gnome-shell extensions break ? Isn't this inevitable? If any extensions only claim to support 3.10 then they'll stop working until updated. There's an option in Gnome Shell buried in the gsettings that allows you to ignore this check and just run them. I've got that on and it worked successfully with all the extensions I run[1] (I need to go and inform the extension upstreams of that fact). One option we could look into would be for GNOME to set this option on by default for a month or so to give extension authors time to catch up while not breaking any user extension that works unmodified. [1] http://sgallagh.wordpress.com/2013/06/27/one-week-with-gnome-3-classic-twenty-eight-days-later/ -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM9ej4ACgkQeiVVYja6o6MrOACgnyrLB0/y1E94hdoTs7PAdSnf fOQAmwZBcaIzX4RJ4bp3/EepKI0n2XhS =moGK -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Considering GNOME 3.12 as an F20 update
On Thu, Apr 3, 2014 at 5:07 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: On 04/03/2014 02:20 PM, Matthias Clasen wrote: Hey, so the time has come to consider this - thanks to the great work of Richard and Kalev on the copr, we have a set of 3.12 packages that have already received fairly wide testing. But we should be careful, so I want to ask for concrete problem reports with the copr packages, besides dependency problems caused by the parallel nature of the copr itself. Did any of your gnome-shell extensions break ? Did you experience crashes or other serious problems with applications ? If so, please let us know on the desktop list. If I don't hear of major problems by next week, I'll file a Fesco ticket to ask for an exception. Are you going to be delivering drastic changes to peoples UI interface by updating Gnome to a new Gnome release in a middle of GA cycle? Has FESCo approved this? Did you read more than just the subject? -- 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: Considering GNOME 3.12 as an F20 update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/03/2014 11:07 AM, Jóhann B. Guðmundsson wrote: On 04/03/2014 02:20 PM, Matthias Clasen wrote: Hey, so the time has come to consider this - thanks to the great work of Richard and Kalev on the copr, we have a set of 3.12 packages that have already received fairly wide testing. But we should be careful, so I want to ask for concrete problem reports with the copr packages, besides dependency problems caused by the parallel nature of the copr itself. Did any of your gnome-shell extensions break ? Did you experience crashes or other serious problems with applications ? If so, please let us know on the desktop list. If I don't hear of major problems by next week, I'll file a Fesco ticket to ask for an exception. Are you going to be delivering drastic changes to peoples UI interface by updating Gnome to a new Gnome release in a middle of GA cycle? Has FESCo approved this? Your question was answered in the quote you included: he's asking for the general devel list to discuss this before he brings it to FESCo for their approval or refusal. Also, as someone who has been testing this update in the COPR for about a month now, there are a few striking changes (the redesign of gedit is thoroughly perplexing), but on the whole I haven't found anything fundamentally out of place in the desktop environment (just in a few of the apps). -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM9ey4ACgkQeiVVYja6o6PDFgCePoMjYKi+F5bNcEsTvnJ04uVM fyEAnR701UCZzN0t5Jth6p5ka4ROiRCI =IhU8 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1084093] New: perl-CPAN-Inject-1.14-4.fc21 FTBFS in non-koji mock
https://bugzilla.redhat.com/show_bug.cgi?id=1084093 Bug ID: 1084093 Summary: perl-CPAN-Inject-1.14-4.fc21 FTBFS in non-koji mock Product: Fedora Version: rawhide Component: perl-CPAN-Inject Assignee: jples...@redhat.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-de...@lists.fedoraproject.org perl-CPAN-Inject-1.14-4.fc21 fails to build in local mock environment. A test fails: t/01_compile.t .. ok Use of uninitialized value $ping_cache_limit in numeric gt () at /usr/share/per l5/CPAN/Mirrors.pm line 384. Use of uninitialized value $ping_cache_limit in numeric gt () at /usr/share/per l5/CPAN/Mirrors.pm line 384. Attempting to create directory /builddir/perl5 Use of uninitialized value in pattern match (m//) at /usr/share/perl5/CPAN/Distr ibution.pm line 2685. The directory 't/sources' does not exist at t/02_main.t line 100. # Looks like you planned 24 tests but ran 15. # Looks like your test exited with 2 just after 15. t/02_main.t . Dubious, test returned 2 (wstat 512, 0x200) Failed 9/24 subtests (less 1 skipped subtest: 14 okay) Test Summary Report --- t/02_main.t (Wstat: 512 Tests: 15 Failed: 0) Non-zero exit status: 2 Parse errors: Bad plan. You planned 24 tests but ran 15. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=5yuerY1C89a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Considering GNOME 3.12 as an F20 update
On Thu, Apr 03, 2014 at 03:52:49PM +0100, Matthew Garrett wrote: Did any of your gnome-shell extensions break ? Isn't this inevitable? If any extensions only claim to support 3.10 then they'll stop working until updated. I've had a pretty good experience here this time around. Almost everything worked when I told it to not do the check, and others were updated. Also, when I look at https://extensions.gnome.org/ sorted by popularity, _most_ of the top ones are already updated. I'd like to see an effort to get the remaining few that are on the top N pages updated, and then I'd be pretty comfortable recommending this as an F20 update. When I'm _running_ 3.12, I can get the web site to give me a list of all the extensions sorted by popularity, with the ones that aren't compatible grayed out. Can one do that _for 3.12_ from a 3.10 system? Then I can send out a link that says Check if the stuff you really care about needs a update. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- 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: Considering GNOME 3.12 as an F20 update
On Thu, Apr 03, 2014 at 11:11:58AM -0400, Stephen Gallagher wrote: One option we could look into would be for GNOME to set this option on by default for a month or so to give extension authors time to catch up while not breaking any user extension that works unmodified. My understanding was that there was no mechanism for automatically updating extensions at present. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Considering GNOME 3.12 as an F20 update
On Thu, Apr 03, 2014 at 04:23:02PM +0100, Matthew Garrett wrote: One option we could look into would be for GNOME to set this option on by default for a month or so to give extension authors time to catch up while not breaking any user extension that works unmodified. My understanding was that there was no mechanism for automatically updating extensions at present. Hmmm, yeah; I'm fairly diligent about going to the https://extensions.gnome.org/local/ and clicking the update button. I can see the reservations with doing this automatically. Is an upgrade helper app of some sort a good idea? For the future, maybe we need to look at shipping more of these as RPMs. I know RPMs are not the General Statement for the Future Of Distros, but it is an existing mechanism we have for solving basically this exact problem. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- 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: Considering GNOME 3.12 as an F20 update
Matthias Clasen mclasen at redhat.com writes: Did any of your gnome-shell extensions break ? gnome-shell-extension-fedmsg is still not working in Rawhide (see https://bugzilla.redhat.com/show_bug.cgi?id=1045669 ). This only affects Fedora so thought I should mention it here. -- 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: Considering GNOME 3.12 as an F20 update
On 04/03/2014 03:15 PM, Stephen Gallagher wrote: Also, as someone who has been testing this update in the COPR for about a month now Did you ( and others ) run through QA release blocking test cases for Gnome or is this more I have been running Gnome for about a month now kinda thing? , there are a few striking changes (the redesign of gedit is thoroughly perplexing), but on the whole I haven't found anything fundamentally out of place in the desktop environment (just in a few of the apps). Let me rephrase my question Do we allow for ui changes being made how small they might be or how big they might be to our default desktop on GA releases? If the answer is yes, Gnome would be allowed to be made rebase-able between release If the answer is no well things remain the same. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: lbzip2 as default bzip2 implementation
2014-04-02 19:24 GMT+02:00 Jaroslav Reznik jrez...@redhat.com: = Proposed System Wide Change: lbzip2 as default bzip2 implementation = https://fedoraproject.org/wiki/Changes/lbzip2 While the speedup is desirable, it's not really obvious that this is the right time to do the change. Looking at http://lbzip2.org/news , lbzip2 is still fixing crashes during compression and decompression. That's rather troubling: we need the bzip2 implementation to be roughly as stable as file system*.* The Change page implies that bzip2 is not actively maintained; that may be true but looking at bugzilla.redhat.com, there has AFAICT never been a bug reporting that something can't be compressed or decompressed--that's a *very* high bar to match. (I do appreciate that assertion failure and silent miscompression are not the same thing.) Having the library implementation and the command-line implementation completely separate may frustrate debugging efforts when using an application-builtin compression and saving uncompressed and compressing manually may give different results. That's not a deal-breaker but having a single implementation would certainly simplify things. Ultimately the easiest way to make this implementation change happen, not only in Fedora but in all distributions, would be for the improvements to be integrated into the upstream bzip2 codebase; has that possibility been explored at all? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Considering GNOME 3.12 as an F20 update
On 04/03/2014 04:20 PM, Matthias Clasen wrote: Hey, so the time has come to consider this - thanks to the great work of Richard and Kalev on the copr, we have a set of 3.12 packages that have already received fairly wide testing. But we should be careful, so I want to ask for concrete problem reports with the copr packages, besides dependency problems caused by the parallel nature of the copr itself. Did any of your gnome-shell extensions break ? Did you experience crashes or other serious problems with applications ? If so, please let us know on the desktop list. If I don't hear of major problems by next week, I'll file a Fesco ticket to ask for an exception. You didn't mention the most important question: Did the API or ABI change in backward-incompatible way? If the answer to this question is yes, then the answer to updating to gnome-3.12 needs to be no, because such changes in released versions of Fedora are not allowed. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Considering GNOME 3.12 as an F20 update
On Thu, Apr 03, 2014 at 06:09:43PM +0200, Ralf Corsepius wrote: You didn't mention the most important question: Did the API or ABI change in backward-incompatible way? If the answer to this question is yes, then the answer to updating to gnome-3.12 needs to be no, because such changes in released versions of Fedora are not allowed. I think we should ground the discussion in the actual policy, which doesn't say that, but does say ABI changes in general are very strongly discouraged and Avoid Major version updates, ABI breakage or API changes if at all possible. That is significantly more qualifed. And more to the point, it says Some classes of software will not fit in these guidelines. If your package does not fit in one of the classes below, but you think it should be allowed to update more rapidly, propose a new exception class to FESCO and/or request an exception for your specific update case. Note that you should open this dialog BEFORE you build or push updates. which is exactly what is happening here. http://fedoraproject.org/wiki/Updates_Policy Now, in reading that policy, there are quite a few things that match the Things that would make it less likely to grant a request list. But, on the other hand, by having a longer-than-typical Fedora release cycle this time around, we are already in special circumstances territory. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- 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: Considering GNOME 3.12 as an F20 update
On 04/03/2014 04:22 PM, Matthew Miller wrote: Now, in reading that policy, there are quite a few things that match the Things that would make it less likely to grant a request list. But, on the other hand, by having a longer-than-typical Fedora release cycle this time around, we are already in special circumstances territory. Gnome community is not know for their stability in their UI so we are talking about user visible changes. Sysadmins on these parts brought out their voodoo dolls and started stabbing them while cursing the new and improved//network settings that came with F20 and Gnome 3.10 and other docket breakage that followed in other words Gnome community is not know for their stability in their UI so we are talking about user visible changes being introduced into GA release. And I have yet to see any request have been made to the test list to at least do the same validation on Gnome as is done before we release an new GA release. JBG -- 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: [CHANGE PROPOSAL] The securetty file is empty by default
2014-04-03 15:06 GMT+02:00 Simo Sorce s...@redhat.com: On Wed, 2014-04-02 at 19:15 -0400, Matthew Miller wrote: On Wed, Apr 02, 2014 at 02:12:50PM -0400, Simo Sorce wrote: How does someone express strong disagreement to this change ? Posting here is a good start. You can also add a note in the FESCo ticket for approval once one is filed, and if you are incredibly passionate you can come to the FESCo meeting (although I'm hoping we can make those meetings more efficient, so that's not a good place for back and forth -- if possible we should work out the issues before the meeting). Ticket number ? The ticket will be filed around the end of the comment period (which hasn't even started for this change, because it hasn't been announced by the Wrangler), and visible to devel@ in the FESCo agenda mail usually sent about a day before the meeting. (Yes, you would need to do some work to track all of this. But you should expect FESCo members to carefully read all comments on the mailing list without having to explicitly raise concerns in the ticket.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
2014-04-02 20:12 GMT+02:00 Simo Sorce s...@redhat.com: On Wed, 2014-04-02 at 09:12 -0700, quickbooks office wrote: [CHANGE PROPOSAL] The securetty file is empty by default All the info has been sitting here @ https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default I often install machines with root only as my users are all in my FreeIPA/LDAP server and I expect to be able to login as root on the console for maintenance purposes. This change makes it very hard to do necessary maintenance. I can understand blocking SSH login as root with password by default, but I do not understand what is the point of blocking console login as root. In larger organizations there is a legitimate need to be able to attribute every action as root to a specific individual, which is easiest to do by requiring a login from a non-root account to establish the session, and then tracking actions done by that session. OTOH this all works reliably enough only with a non-default auditing setup, so restricting root logins by default is alone not at all sufficient. Please explain the logic of blocking console logins but allowing SSH logins, it is completely backwards. Of the various problems with the proposal[1], this one seems the easiest to fix :) Mirek [1] I'm not listing them here; I'd much rather have the Change officially announced and have the official comment period, instead of starting a tradition of pre-announcements. -- 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: Considering GNOME 3.12 as an F20 update
On Thu, 2014-04-03 at 16:32 +, Jóhann B. Guðmundsson wrote: On 04/03/2014 04:22 PM, Matthew Miller wrote: Now, in reading that policy, there are quite a few things that match the Things that would make it less likely to grant a request list. But, on the other hand, by having a longer-than-typical Fedora release cycle this time around, we are already in special circumstances territory. Gnome community is not know for their stability in their UI so we are talking about user visible changes. Sysadmins on these parts brought out their voodoo dolls and started stabbing them while cursing the new and improved network settings that came with F20 and Gnome 3.10 and other docket breakage that followed in other words Gnome community is not know for their stability in their UI so we are talking about user visible changes being introduced into GA release. And I have yet to see any request have been made to the test list to at least do the same validation on Gnome as is done before we release an new GA release. Note that I am not asking about armchair opinions about whether this idea would theoretically fit the guidelines. Neither am I asking for war stories of sysadmins whose life was ruined by f20. I am interested in concrete problems that have been experienced by the people who have tried out Richards copr. If you are not in that group of people, maybe you should actually try the copr before participating in this discussion. Thanks, Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GnuTLS issue (Mandos Server/Client)
On Thu, 2014-04-03 at 16:05 +0200, Nikos Mavrogiannopoulos wrote: On Wed, 2014-04-02 at 10:50 -0600, Nathanael D. Noblet wrote: CentOS 6 = gnutls 2.8.5 F20 = gnutls 3.1.20 The server is a python app and sets the priority string as follows: priority=SECURE256:!CTYPE-X.509:+CTYPE-OPENPGP this is fed to some gnutls function somewhere in the stack. Does it really use TLS with openpgp certificates? If yes, I doubt you could make 2.8.5 interoperate with gnutls 3.1.20. GnuTLS was modified in 3.1.x to adhere with RFC6091 which was incompatible the previous attempt to have openpgp keys to TLS. Hello, Yes it uses TLS and opengpg certificates. So gnutls 3.1.20 can't use both new and old methods I presume? -- 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: Considering GNOME 3.12 as an F20 update
Hi On Thu, Apr 3, 2014 at 10:20 AM, Matthias Clasen mcla...@redhat.com wrote: Did any of your gnome-shell extensions break ? Yes but I got updates for most of them. Couple of them are still broken https://extensions.gnome.org/extension/8/places-status-indicator/ https://extensions.gnome.org/extension/696/skype-integration/ Did you experience crashes or other serious problems with applications ? Nope. GNOME Shell used to crash now and then earlier but not anymore. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Considering GNOME 3.12 as an F20 update
On Thu, Apr 3, 2014 at 7:50 PM, Matthias Clasen mcla...@redhat.com wrote: Did you experience crashes or other serious problems with applications ? Hi Matthias, I had a problem with the new totem/Videos having a non-responsive UI. I'm away on a work assignment until the 13th so unfortunately I can't verify that it's still a problem or if it was some bad configuration that I had. From what I remember, videos directly in my home directory were displayed as thumbnails on the main window and they would play fine. If I tried to add/open a local video from another location (even subdirectory of my home) by clicking on the + at the corner, nothing happened. I wasn't given an open file dialog or anything like that. As I said, it may not actually still be a problem. Maybe someone else can verify? Thanks, Gerard. -- 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: Considering GNOME 3.12 as an F20 update
On Thu, Apr 03, 2014 at 01:09:32PM -0400, Matthias Clasen wrote: And I have yet to see any request have been made to the test list to at least do the same validation on Gnome as is done before we release an new GA release. Note that I am not asking about armchair opinions about whether this idea would theoretically fit the guidelines. Let's keep this friendly and in line with the be excellent guideline, please. I know you are both very passionate about this. Phrasing aside, the basic concern about bad user experience due to changing UI mid-cycle is completely valid and has nothing to do with any general perception of Gnome. That's why the policy is there, after all. There's no reason any contributor can't raise those sort of points even if it wasn't what you asked. It's an important point of the overall decision. And, Jóhann's note about working with the QA team to develop a test plan and run through it seems worth pursuing if the members of QA team are interested and willing (or interested in helping Gnome people or volunteers figure out how it's normally done). I think it's pretty reasonable to assume that extra review would making doing the rebase a lot more comfortable -- anecdotal reports from people running Rawhide or using the Copr are useful for what they are, but they're not formal QA. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- 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: systemd bugs in F20/F21 - bug against the distribution?
On Thu, Apr 3, 2014 at 7:31 PM, Reindl Harald h.rei...@thelounge.net wrote: will that below ever get fixed in F20? Maybe ... maybe not. should i file a bug against the distribution? No .. this makes no sense. should i file a bug against Red Hat as upstream employer? Neither does this (unless you have a support contract but last time I checked they do not offer one for fedora). and if someone asks why i called Lennart in #1072368 names - [..] That does not help your case at all ... you cannot force people to do work for you that's not how open source works. So your options are either: 1) Convince someone to fix it (that works by rational arguments not by calling people idiots) or 2) Fix it and file patches or 3) Pay someone to do 2) Note: I didn't look at the bugs. -- 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: systemd bugs in F20/F21 - bug against the distribution?
Am 03.04.2014 19:47, schrieb drago01: Note: I didn't look at the bugs then please don't answer at all signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd bugs in F20/F21 - bug against the distribution?
On Thu, Apr 3, 2014 at 7:52 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 03.04.2014 19:47, schrieb drago01: Note: I didn't look at the bugs then please don't answer at all What I wrote does not depend on what the bugs actually are. -- 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: systemd bugs in F20/F21 - bug against the distribution?
Am 03.04.2014 19:54, schrieb drago01: On Thu, Apr 3, 2014 at 7:52 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 03.04.2014 19:47, schrieb drago01: Note: I didn't look at the bugs then please don't answer at all What I wrote does not depend on what the bugs actually are it does and honestly bugs which are reported before release and open 7 months later in a core-component ar enot doing the distribution a favour as well as upstream developers of such a component even discuss against kernel upstream that they are doing the right thing until Linus has that muche enough to impend prohibit one of the core developers to commit code in the future this ignorance against downstream and users and break things careless which where not broken, make maintaining machines more and more complicated by spew nonsense in the logs and demand users to change their way of work to make upstream happy is a real bad attitude and in case of but reportes are not friendly enough - well, cause and effect It does become a problem when you have a system service developer who thinks the universe revolves around him, and nobody else matters, and people sending him bug-reports are annoyances that should be ignored rather than acknowledged and fixed. At that point, it's a problem. 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: systemd bugs in F20/F21 - bug against the distribution?
Hi On Thu, Apr 3, 2014 at 2:01 PM, Reindl Harald wrote: Am 03.04.2014 19:54, schrieb drago01: Am 03.04.2014 19:47, schrieb drago01: What I wrote does not depend on what the bugs actually are it does No. You are not entitled to escalate it to any employer unless you have a commercial agreement with them. If some maintainer closes a bug prematurely (which does happen more than once in any major component), it still doesn't mean you get to call them names and it does not excuse your behavior. You should really apologize. Learn to work with people better as has been suggested to you strongly many times before. If you continue to ignore the advice and keep resorting to calling people names now and then, you will likely get yourself moderated from Bugzilla and/or Fedora mailing lists again. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: lbzip2 as default bzip2 implementation
On 04/03/2014 06:08 PM, Miloslav Trmač wrote: Looking at http://lbzip2.org/news , lbzip2 is still fixing crashes during compression and decompression. That's rather troubling: we need the bzip2 implementation to be roughly as stable as file system*.* They say that every non-trivial piece of software has at least one bug. bzip2 also has bugs, myself I am aware of a few of them. The Change page implies that bzip2 is not actively maintained; that may be true but looking at bugzilla.redhat.com, there has AFAICT never been a bug reporting that something can't be compressed or decompressed--that's a *very* high bar to match. (I do appreciate that assertion failure and silent miscompression are not the same thing.) Neither was for lbzip2. And as a matter of fact, bzip2 is compiled with most of assertions disabled. But I understand the point. It may be true that bzip2 is more stable, but that's because it has been given a chance being included in popular operating systems and after initial bugs were fixed it has been there without any changes for years. I care about lbzip2 quality very much. I run a test suite consisting of over 320,000 automated test cases, I compile it with all possible warnings enabled I test it with multiple static analysis tools. Any bugs that may be found during testing in Fedora will be taken care of with high priority. I believe that lbzip2 deserves to be given a chance and if for some reason it turns out not to be ready, the Change can be reverted very easily with a single spec file modification. Having the library implementation and the command-line implementation completely separate may frustrate debugging efforts when using an application-builtin compression and saving uncompressed and compressing manually may give different results. That's not a deal-breaker but having a single implementation would certainly simplify things. Users will still be able to run bzip2 explicitly if needed or configure alternatives to used it as implementation of /usr/bin/bzip2 on their systems. Besides that I am willing to provide a library interface for lbzip2 in future if there is demand. Ultimately the easiest way to make this implementation change happen, not only in Fedora but in all distributions, would be for the improvements to be integrated into the upstream bzip2 codebase; has that possibility been explored at all? lbzip2 as it is now is a merger of 2 projects -- a parallel bzip2-like tool using libbz2 by Laszlo Ersek (started in 2008) and improved low-level bzip2 library by me (started in 2007). The 2 projects were merged in 2010 and since then I took maintenance of lbzip2. While I would like the improvements and new features of lbzip2 to be included in bzip2, I lost my hopes of this ever happening. Both Laszlo me and tried contacting Julian Seward (the author or bzip2) and contributing to bzip2, but without any success. Initially Julian admited that it would be desirable to parallelise bzip2. The plan was to evaluate existing implementations and decide which one to integrate with bzip2, or start the work from scratch. But nothing of that happened. The last conversation about improving bzip2 took place in 2009 and only a single patch was included in bzip2 since then -- a fix for important security bug which I discovered (CVE-2010-0405 [1], it took it 6 months to be applied in bzip2). That said, I am still willing to cooperate with Julian and discuss possibilities of merging some code or improving bzip2 in any way. [1] https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-0405 -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk -- 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: systemd bugs in F20/F21 - bug against the distribution?
On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote: and if someone asks why i called Lennart in #1072368 names We didn't, and no justification would matter. It's not acceptable behaviour, and you need to knock it off. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd bugs in F20/F21 - bug against the distribution?
Am 03.04.2014 20:00, schrieb Adam Jackson: On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote: and if someone asks why i called Lennart in #1072368 names We didn't, and no justification would matter. It's not acceptable behaviour, and you need to knock it off. i know that - on the other hand developers need to knock out the reflex your bugreport annoys me and close it within minutes because they don't care about users and only if *both sides* starts to play nicely it can work and one part of that is to *respect* reporters and realize taht report bugs and describe problems in daily use is a important sort of contribution - i am developer too and i am well aware without the users point of view i would develop blindly - anybody not awawre of this should stop calling himslef a serious developer developers need to knock of that attitude: https://bugs.freedesktop.org/show_bug.cgi?id=76935#c10 without users the developers would be meaningless 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: Considering GNOME 3.12 as an F20 update
On Thu, Apr 3, 2014 at 8:30 PM, Gerard Ryan gali...@fedoraproject.orgwrote: I had a problem with the new totem/Videos having a non-responsive UI. Probably https://bugzilla.gnome.org/show_bug.cgi?id=725063 -- -Elad Alfassa. -- 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: Packaging of libdb-6+
On Thu, 03 Apr 2014 15:53:04 +0200 Honza Horak hho...@redhat.com wrote: On 04/03/2014 11:20 AM, H. Guémar wrote: Since AGPL is fedora-compliant license, there's no blocker to get libdb6 into packages collection. Besides, libdb5 is still critical for many packages (like RM), until we get rid of it, I can only agree with your proposal. Maybe, it's still time to rename the current libdb = libdb5 and get newer releases named libdb starting F21 This would be possible only by co-operation with the depended packages, since they usually use BuildRequire: libdb-devel. So after just rebuilding those to link against libdb-6, some of the packages would start to suffer from license incompatibilities. But I agree that libdb-6.x + libdb5-5.x scenario looks better than libdb-5.x + libdb6-6.x. Anyway, to make some marketing for this change, we should have a Self contained change page for this [1]. Change Proposals Submission Deadline is 2014-04-08 btw. [1] http://fedoraproject.org/wiki/Changes/Policy#Self_contained_changes It's not a self-contained change really. Without a good deal of co-ordination it'll end up causing problems like https://bugzilla.redhat.com/show_bug.cgi?id=768846 in which there are symbol conflicts when a process ends up trying to load two different versions of libdb. 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: systemd bugs in F20/F21 - bug against the distribution?
On Thu, Apr 3, 2014 at 3:08 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 03.04.2014 20:00, schrieb Adam Jackson: On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote: and if someone asks why i called Lennart in #1072368 names We didn't, and no justification would matter. It's not acceptable behaviour, and you need to knock it off. i know that - Then do. Your behavior is toxic, don't excuse it with others' behavior. m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- 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: systemd bugs in F20/F21 - bug against the distribution?
Am 03.04.2014 21:44, schrieb Martin Langhoff: On Thu, Apr 3, 2014 at 3:08 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 03.04.2014 20:00, schrieb Adam Jackson: On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote: and if someone asks why i called Lennart in #1072368 names We didn't, and no justification would matter. It's not acceptable behaviour, and you need to knock it off. i know that - Then do. Your behavior is toxic, don't excuse it with others' behavior as explained most of that behavior started with F15 and destroy years of optimization on perfect running systems which now repeats by put the head in the sand, ignore problems over months and if a reaction besides ignore happens it is close because i don't care there is a reason today even Linus choosed words like and I personally find it annoying that it's always the same f*cking primadonna involved in direction of systemd-upstream 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: systemd bugs in F20/F21 - bug against the distribution?
Bad behavior in response to bad behavior just feeds a positive feedback cycle ( http://en.wikipedia.org/wiki/Positive_feedback ). The way to break out of it is for the person you control (namely YOU) to behave well. If others don't do so, things can calmly escalate and proper measures taken. So, be reasonable. Use logical arguments to convince maintainers that your bug is reasonable and your proposed solutions or patches are also reasonable. If you cannot do this, step back and let others do so. If the problems are persistent or highly impact-full, it's likely that higher levels of project management may get involved, but only in good time and after looking at the behavior of all the parties involved. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd bugs in F20/F21 - bug against the distribution?
Am 03.04.2014 22:04, schrieb Kevin Fenzi: Bad behavior in response to bad behavior just feeds a positive feedback cycle ( http://en.wikipedia.org/wiki/Positive_feedback ). The way to break out of it is for the person you control (namely YOU) to behave well. If others don't do so, things can calmly escalate and proper measures taken. So, be reasonable. Use logical arguments to convince maintainers that your bug is reasonable and your proposed solutions or patches are also reasonable. If you cannot do this, step back and let others do so. what logical arguments do you have if the developer is living in his own world where he is happy about every log message his baby writes while at the same time that burries critical and relevant messages for anybody else who cares? you can come up with logical arguments in case of interested developers but not in case of we do what we want, break what we want when we want to break it and everything falling left and right is buggy and wrong developers If the problems are persistent or highly impact-full, it's likely that higher levels of project management may get involved, but only in good time and after looking at the behavior of all the parties involved. writing thousands of log-lines on a completly stripped down Rawhide VM with only the default cronjobs *is highly impact-full* because on production workloads and a central machine receiving all that messages and store them in a database that is a DOS attack if there would be a prefix or a specific binary thrwoing all that messages you could filter them out in rsyslog.conf (by keep useless overhead burried) but not the way it is implemented use journalctl and filter out is pure ignorance 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: systemd bugs in F20/F21 - bug against the distribution?
On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote: will that below ever get fixed in F20? https://bugzilla.redhat.com/show_bug.cgi?id=1072368 The developer does not consider it to be a bug. You may disagree, but so far, you don't seem to have convinced him or any other systemd developers or, well, anyone else. https://bugzilla.redhat.com/show_bug.cgi?id=1010572 This is an entirely trivial issue: a failed attempt to access something with no apparent negative consequences. Doesn't seem like it'd be a high priority. It also doesn't seem like it would be too difficult to track down and propose a fix, if it's bugging you so much. https://bugzilla.redhat.com/show_bug.cgi?id=626477 You yourself have reported in https://bugzilla.redhat.com/show_bug.cgi?id=626477#c44 that this is fixed on the systemd 208 branch, which F20 is tracking. Then you went nuts and started yelling at people, which as you've been told fifty six thousand goddamn times by now, never ever helps. From the latest comments it sounds like whenever f20 is updated to the latest systemd-208 code, this fix will come in. It's up to the package maintainer when they want to do that. https://bugzilla.redhat.com/show_bug.cgi?id=1047148 Apparently fixed in 20 and Rawhide, you just want a backport to 19? https://bugzilla.redhat.com/show_bug.cgi?id=1024379 Is another extremely trivial one: you're throwing your toys out of the pram over slightly sub-optimal autocomplete? Really? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd bugs in F20/F21 - bug against the distribution?
On 3 April 2014 20:00, Adam Jackson a...@redhat.com wrote: We didn't, and no justification would matter. It's not acceptable behaviour, and you need to knock it off. I'm not the only developer considering unsubscribing from fedora-devel because of emails like the original email. Either the moderators start enforcing stricter rules, warning and then banning certain users, on the number of developers on this -devel mailing list is going to start going down really fast. Without developers this mailing list is pointless. 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
Re: systemd bugs in F20/F21 - bug against the distribution?
Am 03.04.2014 22:32, schrieb Adam Williamson: On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote: will that below ever get fixed in F20? https://bugzilla.redhat.com/show_bug.cgi?id=1072368 The developer does not consider it to be a bug. You may disagree, but so far, you don't seem to have convinced him or any other systemd developers or, well, anyone else. than the developer should explain his point of view and ask for further input instead react with WONT FIX https://bugzilla.redhat.com/show_bug.cgi?id=1010572 This is an entirely trivial issue: a failed attempt to access something with no apparent negative consequences. Doesn't seem like it'd be a high priority. It also doesn't seem like it would be too difficult to track down and propose a fix, if it's bugging you so much. i expect from a serious developer to face that message because i expect that he reads his syslogs, if it is meaningless than the code around of that is also meaningless and has to be removed for the sake of clean software https://bugzilla.redhat.com/show_bug.cgi?id=626477 You yourself have reported in https://bugzilla.redhat.com/show_bug.cgi?id=626477#c44 that this is fixed on the systemd 208 branch, which F20 is tracking. Then you went nuts and started yelling at people, which as you've been told fifty six thousand goddamn times by now, never ever helps. From the latest comments it sounds like whenever f20 is updated to the latest systemd-208 code, this fix will come in. It's up to the package maintainer when they want to do that. well, if someone reports problems and even has testing environments as well is willing to verify and test he can expect respect in form of a scratch build https://bugzilla.redhat.com/show_bug.cgi?id=1047148 Apparently fixed in 20 and Rawhide, you just want a backport to 19? since the no distributeable systemctl reboot and much more the scary fact that a workaround is based ona typo prevents from update any production server to F20 i will face that until F20 is useable in production which is not the case caused by systemd - chicken/egg problem https://bugzilla.redhat.com/show_bug.cgi?id=1024379 Is another extremely trivial one: you're throwing your toys out of the pram over slightly sub-optimal autocomplete? Really? it's anotehr drop into a full sea and affects my workload all the time because i distribute commands from one machine having all packages installed systemctl stop whatever.service; do something; do something; systemctl start whatever.service 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: systemd bugs in F20/F21 - bug against the distribution?
On Thu, Apr 3, 2014 at 4:41 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 03.04.2014 22:32, schrieb Adam Williamson: On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote: will that below ever get fixed in F20? https://bugzilla.redhat.com/show_bug.cgi?id=1072368 The developer does not consider it to be a bug. You may disagree, but so far, you don't seem to have convinced him or any other systemd developers or, well, anyone else. than the developer should explain his point of view and ask for further input instead react with WONT FIX Reindl. You are reading to retort, not to understand. Please take a long moment to try to understand -- many folks that would in some cases agree with some of your points think that overall you are way wrong. You should not answer every email addressed to you. Instead of answering... read it :-) m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- 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: systemd bugs in F20/F21 - bug against the distribution?
Am 03.04.2014 22:37, schrieb Richard Hughes: On 3 April 2014 20:00, Adam Jackson a...@redhat.com wrote: We didn't, and no justification would matter. It's not acceptable behaviour, and you need to knock it off. I'm not the only developer considering unsubscribing from fedora-devel because of emails like the original email. what exactly is your personal problem with that original mail? exceot taht you don't like me? Either the moderators start enforcing stricter rules, warning and then banning certain users, on the number of developers on this -devel mailing list is going to start going down really fast. Without developers this mailing list is pointless. speak for yourself and not for others - opposite to people like Lennart, Kay and yourself other including me don't need moderation and killfiles to not face critism 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: systemd bugs in F20/F21 - bug against the distribution?
Am 03.04.2014 22:46, schrieb Martin Langhoff: On Thu, Apr 3, 2014 at 4:41 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 03.04.2014 22:32, schrieb Adam Williamson: On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote: will that below ever get fixed in F20? https://bugzilla.redhat.com/show_bug.cgi?id=1072368 The developer does not consider it to be a bug. You may disagree, but so far, you don't seem to have convinced him or any other systemd developers or, well, anyone else. than the developer should explain his point of view and ask for further input instead react with WONT FIX Reindl. You are reading to retort, not to understand i understand more than you imagine but you need also to understand that a WON'T FIX for the reporter of a bug is the same as spit into his face and so the only correct reaction of a developer is: * explain his point of view * wait for a addtional response * hestitate to press NO BUG or WON'T FIX aka leave me in peace if developers are not greatful for users input users are not greatful for breaking and changing things right and left of them which worked as expected before 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: systemd bugs in F20/F21 - bug against the distribution?
On Thu, Apr 03, 2014 at 10:41:58PM +0200, Reindl Harald wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1072368 The developer does not consider it to be a bug. You may disagree, but so far, you don't seem to have convinced him or any other systemd developers or, well, anyone else. than the developer should explain his point of view and ask for further input instead react with WONT FIX The developer is under no obligation at all. As Fedora, we *do* have a degree of collective concern -- although, still, no _obligation_, because that's not the way community support works either. But, when you start calling names, it *completely* cancels the ability for anyone to help you. So don't do that. It is actively counter-productive for your goals. Even if you feel the other person is being unreasonable, *take the high road*. It will win in the end. You've gotten a lot of reasonable advice from other people here already. I've seen you *give* reasonable advice in other threads. Relax, calm down, come back, and let's work on building things and fixing things instead of fighting. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- 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: systemd bugs in F20/F21 - bug against the distribution?
On Thu, 3 Apr 2014 22:37:19 +0200 Richard Hughes hughsi...@gmail.com wrote: On 3 April 2014 20:00, Adam Jackson a...@redhat.com wrote: We didn't, and no justification would matter. It's not acceptable behaviour, and you need to knock it off. I'm not the only developer considering unsubscribing from fedora-devel because of emails like the original email. Either the moderators start enforcing stricter rules, warning and then banning certain users, on the number of developers on this -devel mailing list is going to start going down really fast. Without developers this mailing list is pointless. Feel free to actually mail the moderator(s): devel-ow...@lists.fedoraproject.org when you feel moderation is required. As one of the list moderators, I will tell you that for the most part I value any input to the list and try and avoid moderation. If you don't think this is good, feel free to file a fesco or board ticket to replace me with different moderators that moderate differently. I have also closed this thread and warned the orig poster. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [CHANGE PROPOSAL] The securetty file is empty by default
On 04/03/2014 10:32 AM, quickbooks office wrote: 3.1.4.2.2. Disabling Root Logins To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty file. This is done in the name of accountability, by forcing an administrative login through an account attributable to a specific person. This, however, only makes sense if there _actually_are_ such individual accounts on the system. Would this proposal be acceptable if it wasn't implemented if 'root' is the only account? I personally don't think even such amended proposal is a reasonable default configuration, because systems authenticating against a domain, and having only one local (root) account, could lock the admin out if something happens to the network or to the domain server. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Heads up: retiring xorg-x11-drv-mouse and xorg-x11-drv-keyboard
On Thu, Apr 03, 2014 at 09:58:59AM -0400, Adam Jackson wrote: On Thu, 2014-04-03 at 16:35 +1000, Peter Hutterer wrote: If fixes the problem but that doesn't tell the whole story. You have a conf that implicitly says load the mouse driver and then fails because you didn't have the mouse driver installed. Which is fair enough, the question here is why is that setting there in the first place? Is the goal to not add any devices, or is this just an accidental leftover? I think the goal _is_ to not add any devices, yes. Bumblebee is basically a second X server to run on the nvidia gpu and pipe the pixels off that to the integrated gpu. So input only ever happens on the integrated gpu's server, so you want to keep the bumblebee server away from event devices. (I think; I've never actually run it.) hmm, in that case that line wouldn't actually do what it should. AutoAddDevices off enables the old defaults, i.e. the mouse and keyboard drivers. The mouse driver hooks onto /dev/input/mice and would receive events. The correct solution here is to explicitly ignore devices: Section InputClass Identifier ignore all event devices MatchDevicePath /dev/input/event* Option Ignore on EndSection I'll post that on the github bug as well Cheers, Peter -- 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: [CHANGE PROPOSAL] The securetty file is empty by default
On Thu, Apr 3, 2014 at 2:46 PM, Przemek Klosowski przemek.klosow...@nist.gov wrote: On 04/03/2014 10:32 AM, quickbooks office wrote: 3.1.4.2.2. Disabling Root Logins To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty file. This is done in the name of accountability, by forcing an administrative login through an account attributable to a specific person. This, however, only makes sense if there _actually_are_ such individual accounts on the system. Would this proposal be acceptable if it wasn't implemented if 'root' is the only account? I personally don't think even such amended proposal is a reasonable default configuration, because systems authenticating against a domain, and having only one local (root) account, could lock the admin out if something happens to the network or to the domain server. It's worse: the admin could lock themselves out just by creating another user account. --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
sextractor license change
sextractor (source extraction from astronomical images) has change its license from CeCiLL to GPLv3+ in upstream version 2.19.5 Regards -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
swarp license change
swarp (astronomical imaging resampling and coadding) has change its license from CeCILL to GPLv3+ in upstream version 2.38.0 Regards, Sergio Pascual -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Reinstalling the bootloader
Once upon a time (Fedora 15? -- I've lost track), it was possible to reinstall the bootloader using grub-install. Nowadays it's a clusterfsck. I've managed to screw up my bootloader. Is there a way to reinstall it without reinstalling the world? Would it make sense to split the whole bootloader thing out of Anaconda such that it would be possible to re-run it? I can access my install just fine using chroot. FWIW, the same question applies to upgrading the bootloader. Somehow I'm on Fedora 20 using grub 0.97. --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: Reinstalling the bootloader
Am 04.04.2014 03:08, schrieb Andrew Lutomirski: Once upon a time (Fedora 15? -- I've lost track), it was possible to reinstall the bootloader using grub-install. besides that it is the wrong list: grub2-install Nowadays it's a clusterfsck. I've managed to screw up my bootloader. Is there a way to reinstall it without reinstalling the world? Would it make sense to split the whole bootloader thing out of Anaconda such that it would be possible to re-run it? I can access my install just fine using chroot. FWIW, the same question applies to upgrading the bootloader. Somehow I'm on Fedora 20 using grub 0.97 how comes? grub2 took over with F16 or F17 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
[perl-HTML-FormatText-WithLinks/el6] new package for el6
commit 6ada91085a2fa69ef7fc111ad871505bc4bf596d Author: Ruediger Landmann r.landm...@redhat.com Date: Thu Apr 3 14:05:56 2014 +1000 new package for el6 perl-HTML-FormatText-WithLinks.spec | 115 --- 1 files changed, 26 insertions(+), 89 deletions(-) --- diff --git a/perl-HTML-FormatText-WithLinks.spec b/perl-HTML-FormatText-WithLinks.spec index c780bfa..a79bdee 100644 --- a/perl-HTML-FormatText-WithLinks.spec +++ b/perl-HTML-FormatText-WithLinks.spec @@ -1,118 +1,55 @@ Name: perl-HTML-FormatText-WithLinks Version:0.14 -Release:6%{?dist} +Release:1%{?dist} Summary:HTML to text conversion with links as footnotes - -Group: Development/Libraries License:GPL+ or Artistic -URL:http://search.cpan.org/dist/HTML-FormatText-WithLinks -Source0: http://search.cpan.org/CPAN/authors/id/S/ST/STRUAN/HTML-FormatText-WithLinks-%{version}.tar.gz +Group: Development/Libraries +URL:http://search.cpan.org/dist/HTML-FormatText-WithLinks/ +Source0: http://www.cpan.org/authors/id/S/ST/STRUAN/HTML-FormatText-WithLinks-%{version}.tar.gz BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) - BuildArch: noarch -BuildRequires: perl(ExtUtils::MakeMaker) -BuildRequires: perl(HTML::FormatText) perl(HTML::TreeBuilder) +BuildRequires: perl(HTML::FormatText) = 2 +BuildRequires: perl(HTML::TreeBuilder) +BuildRequires: perl(Module::Build) +BuildRequires: perl(Test::More) BuildRequires: perl(URI::WithBase) -BuildRequires: perl(Test::MockObject) perl(Test::Pod::Coverage) -BuildRequires: perl(Test::Pod) perl(Test::More) -Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version)) -# not picked up automatically since it is called through SUPER -Requires: perl(HTML::FormatText) = 2 +Requires: perl(HTML::FormatText) = 2 +Requires: perl(HTML::TreeBuilder) +Requires: perl(URI::WithBase) +Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version)) %description -HTML::FormatText::WithLinks takes HTML and turns it into plain text but -prints all the links in the HTML as footnotes. By default, it attempts -to mimic the format of the lynx text based web browser's --dump option. +HTML::FormatText::WithLinks takes HTML and turns it into plain text but +prints all the links in the HTML as footnotes. By default, it attempts to +mimic the format of the lynx text based web browser's --dump option. %prep %setup -q -n HTML-FormatText-WithLinks-%{version} - %build -%{__perl} Makefile.PL INSTALLDIRS=vendor -make %{?_smp_mflags} - +%{__perl} Build.PL installdirs=vendor +./Build %install rm -rf $RPM_BUILD_ROOT -make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT -find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';' -find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2/dev/null ';' -chmod -R u+w $RPM_BUILD_ROOT/* +./Build install destdir=$RPM_BUILD_ROOT create_packlist=0 +find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \; -%check -make test +%{_fixperms} $RPM_BUILD_ROOT/* +%check +./Build test %clean rm -rf $RPM_BUILD_ROOT - %files %defattr(-,root,root,-) -%doc Changes README +%doc Changes examples README %{perl_vendorlib}/* -%{_mandir}/man3/*.3* - +%{_mandir}/man3/* %changelog -* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.14-6 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild - -* Thu Jun 21 2012 Petr Pisar ppi...@redhat.com - 0.14-5 -- Perl 5.16 rebuild - -* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.14-4 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild - -* Wed Jul 20 2011 Petr Sabata con...@redhat.com - 0.14-3 -- Perl mass rebuild - -* Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.14-2 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild - -* Mon Dec 13 2010 Petr Sabata psab...@redhat.com - 0.14-1 -- 0.14 bump - -* Thu Dec 2 2010 Petr Sabata psab...@redhat.com - 0.12-1 -- 0.12 bump - -* Wed Sep 15 2010 Petr Pisar ppi...@redhat.com - 0.11-1 -- 0.11 bump - -* Sun May 02 2010 Marcela Maslanova mmasl...@redhat.com - 0.09-8 -- Mass rebuild with perl-5.12.0 - -* Mon Dec 7 2009 Stepan Kasal ska...@redhat.com - 0.09-7 -- rebuild against perl 5.10.1 - -* Sat Jul 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.09-6 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild - -* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.09-5 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild - -* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.09-4 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild - -* Fri Jul 11 2008 Tom spot Callaway tcall...@redhat.com - 0.09-3 -- fix license
Re: Considering GNOME 3.12 as an F20 update
On 04/03/2014 06:22 PM, Matthew Miller wrote: On Thu, Apr 03, 2014 at 06:09:43PM +0200, Ralf Corsepius wrote: You didn't mention the most important question: Did the API or ABI change in backward-incompatible way? If the answer to this question is yes, then the answer to updating to gnome-3.12 needs to be no, because such changes in released versions of Fedora are not allowed. I think we should ground the discussion in the actual policy, which doesn't say that, but does say ABI changes in general are very strongly discouraged and Avoid Major version updates, ABI breakage or API changes if at all possible. That is significantly more qualifed. And more to the point, it says Some classes of software will not fit in these guidelines. If your package does not fit in one of the classes below, but you think it should be allowed to update more rapidly, propose a new exception class to FESCO and/or request an exception for your specific update case. Note that you should open this dialog BEFORE you build or push updates. You should take the spirit behind this into account: ABI/API breakages are bad and should be avoided, unless they are inevitable, because they break and disturb user installations. which is exactly what is happening here. That's why I am asking. I want Mr. Clasen or somebody else from Gnome to provide a clear answer. So far, as I perceive Mr. Clasen, he deliberately avoided to answer. http://fedoraproject.org/wiki/Updates_Policy Now, in reading that policy, there are quite a few things that match the Things that would make it less likely to grant a request list. But, on the other hand, by having a longer-than-typical Fedora release cycle this time around, we are already in special circumstances territory. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Reinstalling the bootloader
On Apr 3, 2014 7:18 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 04.04.2014 03:08, schrieb Andrew Lutomirski: Once upon a time (Fedora 15? -- I've lost track), it was possible to reinstall the bootloader using grub-install. besides that it is the wrong list: What's the right list? grub2-install $ grub2-install /usr/sbin/grub2-probe: error: cannot find a GRUB drive for /dev/sda1. Check your device.map. This is with efi. WTF is a GRUB drive? Will this set up the boot menu in anything resembling a sensible manner? (I doubt it, since I don't consider having kernel entries listed in the ESP to be sensible, but that's a separate issue.) Will it set up EFI boot manager entries? Is the efibootmgr program usable by mortals? For non-EFI, I have to do some i386-pc crap. At least I think I have some idea how that's supposed to work. FWIW, the last time I got grub2-mkconfig to work, it generated a config that, strictly speaking, functioned, but it spewed warnings every time I booted. That was a while ago. Nowadays it's a clusterfsck. I've managed to screw up my bootloader. Is there a way to reinstall it without reinstalling the world? Would it make sense to split the whole bootloader thing out of Anaconda such that it would be possible to re-run it? I can access my install just fine using chroot. FWIW, the same question applies to upgrading the bootloader. Somehow I'm on Fedora 20 using grub 0.97 how comes? grub2 took over with F16 or F17 Upgrades. --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
Self Introduction: Michael McCune
hi all, I'm writing today because I have just submitted my first package for review, huzzah! My name is Michael McCune and I am a newly minted associate at Red Hat. I have been a software developer for just shy of 20 years, doing most of my work in the embedded realm of automotive GPS devices. Within the last 7-8 years I have started to do an increasing amount of work building virtual machine infrastructures and coding higher up the stack than the C code of the embedded world. I have had a long term interest with Linux and have wanted to become more involved with the community since I helped bring a custom kernel and open source based root filesystem to the last two products I was involved with. The last month or so has been a whirlwind experience for me, and a dream come true. Hopefully I have dotted my i's and crossed my t's with this initial package request. I am, of course, looking for a sponsor. https://bugzilla.redhat.com/show_bug.cgi?id=1084246 is the review I am submitting. This review is not only a version upgrade but a rename as well. hope to hear from you all soon, mike -- 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: Considering GNOME 3.12 as an F20 update
On Thu, 2014-04-03 at 23:00 +0530, Gerard Ryan wrote: From what I remember, videos directly in my home directory were displayed as thumbnails on the main window and they would play fine. If I tried to add/open a local video from another location (even subdirectory of my home) by clicking on the + at the corner, nothing happened. I wasn't given an open file dialog or anything like that. As I said, it may not actually still be a problem. Maybe someone else can verify? Hey Gerard, This looks like https://bugzilla.gnome.org/show_bug.cgi?id=725063 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Reinstalling the bootloader
On Thu, 2014-04-03 at 18:08 -0700, Andrew Lutomirski wrote: Once upon a time (Fedora 15? -- I've lost track), it was possible to reinstall the bootloader using grub-install. Just wondering if you've read this page yet: https://fedoraproject.org/wiki/GRUB_2?rd=Grub2 -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG 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
Diagrams and images used in documentation
Hi, What is the software that is used to make images like : http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/images/IPA_arch.png Or http://docs.fedoraproject.org/en-US/Fedora/18/html-single/System_Administrators_Guide/images/Network_Interfaces-bridge-with-bond.png I haven't been able to find references to this, but would like to be able to use this style of images in my own documentation. -- William Brown will...@firstyear.id.au signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Reinstalling the bootloader
On Thu, Apr 3, 2014 at 8:09 PM, Ankur Sinha sanjay.an...@gmail.com wrote: On Thu, 2014-04-03 at 18:08 -0700, Andrew Lutomirski wrote: Once upon a time (Fedora 15? -- I've lost track), it was possible to reinstall the bootloader using grub-install. Just wondering if you've read this page yet: https://fedoraproject.org/wiki/GRUB_2?rd=Grub2 I did, but this: This is an untested write-up from memory and guessing - be careful didn't inspire much confidence. --Andy -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG -- 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: Considering GNOME 3.12 as an F20 update
Matthias Clasen wrote: so the time has come to consider this - thanks to the great work of Richard and Kalev on the copr, we have a set of 3.12 packages that have already received fairly wide testing. I'll share here what I mentioned on desktop list... The gnome-3.12 copr includes a couple of low-level package updates that change abi/api that affects other desktops, notably: upower-0.99 PackageKit-0.9.x Are these 2 required by gnome-3.12 or would it be possible to use the (current) f20 versions? If required, then some extra work will be required (particularly for upower) to minimize the chances of breakage outside of gnome. One example, I'm not entirely sure if cinnamon-settings-daemon is fully ready yet, see also https://bugzilla.redhat.com/show_bug.cgi?id=1048276 -- Rex -- 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: Diagrams and images used in documentation
On Apr 3, 2014 9:27 PM, William Brown will...@firstyear.id.au wrote: Hi, What is the software that is used to make images like : http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/images/IPA_arch.png Or http://docs.fedoraproject.org/en-US/Fedora/18/html-single/System_Administrators_Guide/images/Network_Interfaces-bridge-with-bond.png I haven't been able to find references to this, but would like to be able to use this style of images in my own documentation. -- William Brown will...@firstyear.id.au -- Didn't want to cross post, but I've passed this on to the Docs list. --Pete -- 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: Diagrams and images used in documentation
On Fri, Apr 4, 2014 at 8:57 AM, William Brown will...@firstyear.id.au wrote: Hi, What is the software that is used to make images like : http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/images/IPA_arch.png Or http://docs.fedoraproject.org/en-US/Fedora/18/html-single/System_Administrators_Guide/images/Network_Interfaces-bridge-with-bond.png I haven't been able to find references to this, but would like to be able to use this style of images in my own documentation. It is called Inkscape [1]. [1] http://inkscape.org/en/ Kushal -- http://fedoraproject.org http://kushaldas.in -- 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: Diagrams and images used in documentation
Libreoffice Draw works just fine too in some simpler cases. Inkscape however is more comprehensive. Libreoffice Draw can export in svg format also so that your graphic can later on be edited/enhanced in Inkscape. -- Suchakra On Fri, Apr 4, 2014 at 1:11 AM, Kushal Das kushal...@gmail.com wrote: On Fri, Apr 4, 2014 at 8:57 AM, William Brown will...@firstyear.id.au wrote: Hi, What is the software that is used to make images like : http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/images/IPA_arch.png Or http://docs.fedoraproject.org/en-US/Fedora/18/html-single/System_Administrators_Guide/images/Network_Interfaces-bridge-with-bond.png I haven't been able to find references to this, but would like to be able to use this style of images in my own documentation. It is called Inkscape [1]. [1] http://inkscape.org/en/ Kushal -- http://fedoraproject.org http://kushaldas.in -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1083915] New: perl-CPAN-Checksums-2.08-8.fc21 FTBFS in non-koji mock
https://bugzilla.redhat.com/show_bug.cgi?id=1083915 Bug ID: 1083915 Summary: perl-CPAN-Checksums-2.08-8.fc21 FTBFS in non-koji mock Product: Fedora Version: rawhide Component: perl-CPAN-Checksums Assignee: jples...@redhat.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com External Bug ID: CPAN 94397 Non-koji mock allows DNS resolution, but forbids network connections. This causes a test to fail: + make test PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -MTest::Harness -e undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch') t/*. t gpg: new configuration file `/builddir/.gnupg/gpg.conf' created gpg: WARNING: options in `/builddir/.gnupg/gpg.conf' are not yet active during t his run gpgkeys: HTTP fetch error 7: Failed to connect to pool.sks-keyservers.net port 1 1371: Network is unreachable gpg: Signature made Tue Aug 30 08:30:20 2011 CEST using DSA key ID A317C15D gpg: requesting key A317C15D from hkp server pool.sks-keyservers.net gpg: no valid OpenPGP data found. gpg: Can't check signature: public key not found == BAD/TAMPERED signature detected! == t/00signature.t .. Failed 1/1 subtests This is causes by insufficient skip-test condition in t/00signature.t. Reported to upstream https://rt.cpan.org/Public/Bug/Display.html?id=94397 with proposed fix. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=1b68frENYIa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1083915] perl-CPAN-Checksums-2.08-8.fc21 FTBFS in non-koji mock
https://bugzilla.redhat.com/show_bug.cgi?id=1083915 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|jples...@redhat.com |ppi...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=u3ctm47krIa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-CPAN-Checksums] Fix test skip-condition to pass in mock
commit 2f5171ebe57317144913e65115ad3082b3089106 Author: Petr Písař ppi...@redhat.com Date: Thu Apr 3 09:13:12 2014 +0200 Fix test skip-condition to pass in mock CPAN-Checksums-2.08-New-signature.patch| 61 ...Try-to-connect-to-pool.sks-keyservers.net.patch | 45 ++ perl-CPAN-Checksums.spec | 11 +++- 3 files changed, 116 insertions(+), 1 deletions(-) --- diff --git a/CPAN-Checksums-2.08-New-signature.patch b/CPAN-Checksums-2.08-New-signature.patch new file mode 100644 index 000..d5524fb --- /dev/null +++ b/CPAN-Checksums-2.08-New-signature.patch @@ -0,0 +1,61 @@ +From 6d03608c83e9ac68492ab03a208cc1499d7af96b Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= ppi...@redhat.com +Date: Thu, 3 Apr 2014 11:16:26 +0200 +Subject: [PATCH] New signature +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +This resigns 2.08 with CPAN RT #94397 patch. + +Signed-off-by: Petr Písař ppi...@redhat.com +--- + SIGNATURE | 14 +++--- + 1 file changed, 7 insertions(+), 7 deletions(-) + +diff --git a/SIGNATURE b/SIGNATURE +index 23272c4..627fae8 100644 +--- a/SIGNATURE b/SIGNATURE +@@ -1,5 +1,5 @@ + This file contains message digests of all files listed in MANIFEST, +-signed via the Module::Signature module, version 0.68. ++signed via the Module::Signature module, version 0.73. + + To verify the content in this distribution, first make sure you have + Module::Signature installed, then type: +@@ -12,7 +12,7 @@ the distribution may already have been compromised, and you should + not run its Makefile.PL or Build.PL. + + -BEGIN PGP SIGNED MESSAGE- +-Hash: SHA1 ++Hash: SHA256 + + SHA1 6587f782cbd9cb71036f2e2492ca3daa389521c3 MANIFEST + SHA1 1c21142a9af69d1da5c027b924b8b0c052beb1da MANIFEST.SKIP +@@ -22,7 +22,7 @@ SHA1 98d4acdec8e5b42574f8f32f453c0c0933fa569f Makefile.PL + SHA1 378ba4b97d5a989790877de0214ca23ac5aeef37 README + SHA1 b929ff9f01730419548cab2dfcc30003b49fbbfb Todo + SHA1 b8158703f7dbb962c56a07183b375a766951e4f1 lib/CPAN/Checksums.pm +-SHA1 8091e870af6f081607bab636ab1e8fcfa18b12be t/00signature.t ++SHA1 89bb8f97f25483d5f618e6a63d2a4361ed0bb84c t/00signature.t + SHA1 51e1c061bc02e9a38948a5d8e3ca7352830f0fac t/42.gz + SHA1 23e182506f4b883d8aae3d29d08e044c55b04deb t/43 + SHA1 0d942b3ef6791694fde4693d3329a0ff924cb583 t/44.bz2 +@@ -31,9 +31,9 @@ SHA1 2d74a36030efca3a42026e2ceab6837c052e8a53 t/CHECKSUMS + SHA1 6a79f15a10337bd3450604abf39d4462df2a550b t/pod.t + SHA1 3a73818d40fce12a21bf9d4d2c38ee2145cc0628 t/updatedir.t + -BEGIN PGP SIGNATURE- +-Version: GnuPG v1.4.11 (GNU/Linux) ++Version: GnuPG v2.0.22 (GNU/Linux) + +-iEYEARECAAYFAk5cg3wACgkQ7IA58KMXwV0uzQCfc/vBboe7anyS25qj+zBglXSv +-gJkAn2f3uvbHfXjdSN/XXNvss5YLH1Yc +-=snWE ++iF4EAREIAAYFAlM9KBsACgkQEsnFx2fG+qLnuwD9Ekd3QDUjoSTbmrL4/UMZvNFa ++J6Zdq6cawLqWI6L6PZcA/3s0NjLsWiwVTvb7ddsuYnGldjSF1JFFSs3lyTBYXnZG ++=I43x + -END PGP SIGNATURE- +-- +1.9.0 + diff --git a/CPAN-Checksums-2.08-Try-to-connect-to-pool.sks-keyservers.net.patch b/CPAN-Checksums-2.08-Try-to-connect-to-pool.sks-keyservers.net.patch new file mode 100644 index 000..b7c7711 --- /dev/null +++ b/CPAN-Checksums-2.08-Try-to-connect-to-pool.sks-keyservers.net.patch @@ -0,0 +1,45 @@ +From 341641c72e5c102b37bdaf349cb718f086e0e9c5 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= ppi...@redhat.com +Date: Thu, 3 Apr 2014 09:07:29 +0200 +Subject: [PATCH] Try to connect to pool.sks-keyservers.net +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +t/00signature.t fails if pool.sks-keyservers.net can be resolved, but +you cannot connect to it. This patch augments the Cannot connect to +the keyserver precheck to do real TCP connect. + +Signed-off-by: Petr Písař ppi...@redhat.com +--- + t/00signature.t | 14 +- + 1 file changed, 13 insertions(+), 1 deletion(-) + +diff --git a/t/00signature.t b/t/00signature.t +index c7da469..75ae6d4 100644 +--- a/t/00signature.t b/t/00signature.t +@@ -49,7 +49,19 @@ BEGIN { + } + } + unless ($exit_message) { +-if (!eval { require Socket; Socket::inet_aton('pool.sks-keyservers.net') }) { ++if (!eval { ++use Socket qw(AF_INET SOCK_STREAM pack_sockaddr_in inet_aton); ++my $socket; ++socket($socket, AF_INET, SOCK_STREAM, 0) and ++connect( ++$socket, ++pack_sockaddr_in( ++scalar getservbyname('hkp', 'tcp'), ++inet_aton('pool.sks-keyservers.net') ++) ++) and ++close($socket) ++}) { + $exit_message = Cannot connect to the keyserver; + } + } +-- +1.9.0 + diff --git a/perl-CPAN-Checksums.spec b/perl-CPAN-Checksums.spec index 192c0b2..da35a14 100644 ---
[Bug 1083960] New: perl-autodie-2.25 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1083960 Bug ID: 1083960 Summary: perl-autodie-2.25 is available Product: Fedora Version: rawhide Component: perl-autodie 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.25 Current version/release in Fedora Rawhide: 2.24-1.fc21 URL: http://search.cpan.org/dist/autodie/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ynYezuc623a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1083961] New: perl-Carp-1.3301 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1083961 Bug ID: 1083961 Summary: perl-Carp-1.3301 is available Product: Fedora Version: rawhide Component: perl-Carp Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 1.3301 Current version/release in Fedora Rawhide: 1.33-1.fc21 URL: http://search.cpan.org/dist/Carp/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=bjM150WSNga=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1083964] New: perl-File-MimeInfo-0.24 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1083964 Bug ID: 1083964 Summary: perl-File-MimeInfo-0.24 is available Product: Fedora Version: rawhide Component: perl-File-MimeInfo Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, pertu...@free.fr, ppi...@redhat.com Latest upstream release: 0.24 Current version/release in Fedora Rawhide: 0.22-1.fc21 URL: http://search.cpan.org/dist/File-MimeInfo/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=JdCqXMS0jHa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel