Re: FESCO request to revert password confirmation change in F22
On Fri, 2015-03-06 at 19:25 -0500, Miloslav Trmač wrote: The way we deploy LUKS, a single password guess takes one second on a comparable hardware, so the fuzz factor is not actually as large as it might seem. Wow, I had no clue it was that good. OK, so making one guess at the user account password every ~three seconds would not be an unreasonable attack, once you've stolen the computer, given how slow it would be to attack LUKS. I had incorrectly assumed that the difference in speed would be orders of magnitude. Still, this is not a realistic threat for most users, and it would take forever to attack either way, so this really just convinces me that I can be safe with a much weaker disk encryption password than I had previously imagined. :) -- 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: FESCo Meeting Minutes (2015-03-04)
Stephen John Smoogen wrote: It is a two way street. You own the device. They make the OS. Each is their own 'ball' if I am using your original metaphor appropriately. Each sees the other as the field the ball gets played on. If you don't like the field that your ball is playing on you are free to ask for something to be changed. If it doesn't get changed you can go find another field to play on. And vice versa. The idea that the OS manufacturers get to control what you do with your machine is a totally proprietary attitude that absolutely goes against the spirit of Free Software. This control-freakiness is exactly what we hate about proprietary software! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCO request to revert password confirmation change in F22
On Fri, 2015-03-06 at 12:00 -0700, Kevin Fenzi wrote: * The workstation folks think this change could drive away some of their potential users for not much gain. In their case, sshd is not enabled/running and additional security for a device that sits in your home isn't worth the additional complexity. Regarding Workstation: I don't think it provides any additional safety, TBH. I see two cases: * Case 1: The attacker has physical access to your computer. The user account password is no protection: I think pretty much all of us know how to boot a live image and copy files off the disk that way. A BIOS password would actually help somewhat, to delay the attacker as long as it takes the attacker to drain your battery to reset it. A disk encryption password would be real security. No, the real security is actually the minimum of (disk encryption password)*fuzz, (user account/screen lock password); with a fuzz factor accounting for the fact that disk encryption password can be broken off-line, at full speed, farming it out to thousands of machines, but a screen lock password needs to be typed (or perhaps brute-forced using a keyboard-mimicking USB device, still slower than full speed, and restricted to one guess at a time). The way we deploy LUKS, a single password guess takes one second on a comparable hardware, so the fuzz factor is not actually as large as it might seem. The screen lock password still matters, though it does not need to be as strong as the disk encryption password. 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
[Bug 1195862] Review Request: perl-Class-Virtual - Base class for virtual base classes in Perl
https://bugzilla.redhat.com/show_bug.cgi?id=1195862 --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- perl-Class-Virtual-0.07-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/perl-Class-Virtual-0.07-1.fc22 -- 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=OXNWjYmOrka=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 1195862] Review Request: perl-Class-Virtual - Base class for virtual base classes in Perl
https://bugzilla.redhat.com/show_bug.cgi?id=1195862 --- Comment #7 from Fedora Update System upda...@fedoraproject.org --- perl-Class-Virtual-0.07-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/perl-Class-Virtual-0.07-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=of58WMlvLDa=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
Re: FESCO request to revert password confirmation change in F22
Hi! On Fri, 2015-03-06 at 23:01 +0100, Björn Persson wrote: or if the attacker snuck into your room when you left it to fetch some coffee, and needs to unlock your console, implant a backdoor and sneak back out before you return, or otherwise can't reboot your computer because you would notice it, Well... yes, I suppose if you've left your computer on and locked, and the attacker wants to make sure you do not notice the reboot, or wants to get a RAM dump that would be lost when shut down (e.g. for my gnome-keyring passwords), then there is some benefit, but to a quite limited extent IMO: the attacker is still limited by the speed at which PAM and gdm allow you to try logging in. Every guess takes something like three seconds. So I think a weak password suffices. In the previous paragraph you wrote that it does matter. It seems that what you're actually arguing is that the threshold should be very low. Personally, I'd be fine with the password strength check if the threshold was very low, but my proposed threshold is *way* lower than libpwquality can be configured to accept. Different thresholds could make sense for different products. Obviously many other folks want it completely gone. Changing libpwquality would be quite desirable so we can close the upstream bugs in gnome-control-center and gnome-initial-setup. Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1199680] New: perl-DBD-MySQL-4.031 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1199680 Bug ID: 1199680 Summary: perl-DBD-MySQL-4.031 is available Product: Fedora Version: rawhide Component: perl-DBD-MySQL Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 4.031 Current version/release in rawhide: 4.029-1.fc22 URL: http://search.cpan.org/dist/DBD-mysql/ 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=bRTYRtfdQFa=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 1199687] perl-threads-1.99 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1199687 --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Scratch build succeeded http://koji.fedoraproject.org/koji/taskinfo?taskID=9162268 -- 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=jOskNP0u6Ha=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
Re: FESCo Meeting Minutes (2015-03-04)
On 6 March 2015 at 17:11, Kevin Kofler kevin.kof...@chello.at wrote: Stephen John Smoogen wrote: It is a two way street. You own the device. They make the OS. Each is their own 'ball' if I am using your original metaphor appropriately. Each sees the other as the field the ball gets played on. If you don't like the field that your ball is playing on you are free to ask for something to be changed. If it doesn't get changed you can go find another field to play on. And vice versa. The idea that the OS manufacturers get to control what you do with your machine is a totally proprietary attitude that absolutely goes against the spirit of Free Software. This control-freakiness is exactly what we hate about proprietary software! Kevin Kofler Here is my point . Here is where you guys think it is --30 light years . The point I am worried about is that Chris and you are treating this as a binary problem versus a spectrum one. I am more worried about the general case of the process of this 'request for change'. If all it is going to take to make a team do something would be a lot of email requests.. what happens when every person you ever peeved off starts a thread on moving KDE back to 3.5 because the current software interferes with their hardware. If it is their ball and you have to do whatever they say... I can see a LOT of petty wars brought up, fought and no one winning. [And no one say 'common sense' will prevent that. When most every email has been assailing the others decision as lack of common sense.. we already threw that out.] I would say that this is madness.. but I am afraid that someone will kick me in a well and say that this is Fedora. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1196784] perl-CHI: epel7 branch
https://bugzilla.redhat.com/show_bug.cgi?id=1196784 Denis Fateyev de...@fateyev.com changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |WONTFIX Last Closed||2015-03-06 18:58:07 --- Comment #2 from Denis Fateyev de...@fateyev.com --- Indeed, due a plenty of dependencies it takes a lot of time which I currently do not have. Maybe, somebody else interested in packaging it for EPEL7. Thanks for supporting it for Fedora. -- 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=jpfblEXjnca=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 1195862] Review Request: perl-Class-Virtual - Base class for virtual base classes in Perl
https://bugzilla.redhat.com/show_bug.cgi?id=1195862 --- Comment #10 from Fedora Update System upda...@fedoraproject.org --- perl-Class-Virtual-0.07-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/perl-Class-Virtual-0.07-1.el6 -- 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=snRFTYEEOBa=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 1195862] Review Request: perl-Class-Virtual - Base class for virtual base classes in Perl
https://bugzilla.redhat.com/show_bug.cgi?id=1195862 --- Comment #8 from Fedora Update System upda...@fedoraproject.org --- perl-Class-Virtual-0.07-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-Class-Virtual-0.07-1.fc20 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=XgW5b5g3ssa=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 1195862] Review Request: perl-Class-Virtual - Base class for virtual base classes in Perl
https://bugzilla.redhat.com/show_bug.cgi?id=1195862 --- Comment #9 from Fedora Update System upda...@fedoraproject.org --- perl-Class-Virtual-0.07-1.el7 has been submitted as an update for Fedora EPEL 7. https://admin.fedoraproject.org/updates/perl-Class-Virtual-0.07-1.el7 -- 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=SVtCdXWXWha=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
Re: FESCO request to revert password confirmation change in F22
Hello, On Fri, Mar 06, 2015 at 09:43:33AM -0500, Adam Jackson wrote: As resolved by FESCO in our meeting on 4 March 2015, FESCO requests that anaconda revert a password behaviour change in the UI from F22, restoring the double-click to confirm weak password behaviour from F21 and earlier. From what I'm reading in the meeting logs and the ticket comments, it appears the revert decision is basically a temporary solution and a more formal security policy will be discussed later. We had technical arguments in favor of the change originally, but I have yet to see technical arguments against the change come together in any sort of concrete policy. There were quite a few use cases that just don’t warrant that strong a password, and where the insistence on a strong password is only annoying. Even if we completely discounted the Fedora testers, there are personal VMs, and there is Workstation with disabled ssh. Are these not “technical arguments against the change”? Sure, they are disconnected and don’t come packaged in a neat distribution-wide policy, but then neither does the anaconda change. 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: FESCO request to revert password confirmation change in F22
On Fri, 2015-03-06 at 19:35 -0500, Miloslav Trmač wrote: There is another very important case where this falls down: the computer is enrolled into AD/IPA and the password is used throughout the organization. Just looking at a local machine does not necessarily tell you what the needed password strength is. This is of course not an argument in favor of making the policy stricter, but it does mean that _every_ way to change the password should respect the system-wide libpwsafe configuration. If the site administrator, along with enrolling into IPA/AD, sets up libpwquality to set up password strength restriction they deem appropriate, _all_ of Workstation should enforce these restrictions. Now perhaps the right default is to _have_ no restrictions but they need to be enforced the moment someone sets them up. I doubt anyone will argue against this. :) Um, “we can’t do $this so we need to leave other parts of the system insecure” is really not sound logic. At the very least we have the option of giving up on VNC instead. And I don’t really see why it would be impossible to add a password strength check for VNC at all; in the worst case we could just store the libpwquality score when the password is set / changed somewhere, and use this stored score to decide whether to warn the user before enabling VNC (storing the scores like this, and telling the attacker which accounts are weak, would be bad on multi-user desktops, but those are rare nowadays and the admin wouldn’t want individual users to go enabling services on such machines anyway). What am I missing? Eh, well by my logic they are both so closely-related that it's nonsense to treat them differently... but that comment was more a wishful somebody please fix VNC or rewrite history than anything. I have no clue why VNC passwords are limited/truncated to eight characters, but it seems like that limitation makes the protocol not worth supporting at all, let alone worth promoting in System Settings. I wonder how well FreeRDP is coming along -- 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: FESCo Meeting Minutes (2015-03-04)
Note that in upstream bug #735578 I have failed to build consensus on any form of password strength checking, let alone the strict checking that is done by libpwquality, so there is little chance at this point of GNOME upstream adhering to any policy you come up with. The status quo is that if libpwquality is in the PAM stack, as on Fedora, then gnome-initial-setup is broken, and we will probably change gnome-control-center to break as well (by not enforcing the password strength check that PAM will enforce). (Ah, this is the mail I wanted to reply to, sorry. Just for the record, then:) Consider a client enrolled in AD/IPA. Then password policies are much more important than for a local-only account, and we _need_ gnome-control-center (and gnome-initial-setup if it can be used to change passwords or create IPA accounts) to enforce them. Perhaps the Workstation default configuration of libpwquality should be fairly lax, I don’t know, I haven’t looked in to this. But inappropriate default configuration is not a sufficient reason not to have enforcement in there. 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: FESCO request to revert password confirmation change in F22
I have no clue why VNC passwords are limited/truncated to eight characters, but it seems like that limitation makes the protocol not worth supporting at all, let alone worth promoting in System Settings. The only VNC authentication mechanism standardized in RFC 6143 uses the password as a DES key, which limits it to 8 (7-bit) bytes. The VNC protocol can, however, support several different kinds of authentication, and several have been defined as vendor extensions. See e.g. http://sourceforge.net/p/tigervnc/code/HEAD/tree/rfbproto/rfbproto.rst#security-types . Restricting to non-standard authentication types, would, of course, impact interoperability. 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: FESCO request to revert password confirmation change in F22
Hello, On Fri, 2015-03-06 at 12:00 -0700, Kevin Fenzi wrote: * The workstation folks think this change could drive away some of their potential users for not much gain. In their case, sshd is not enabled/running and additional security for a device that sits in your home isn't worth the additional complexity. Regarding Workstation: I don't think it provides any additional safety, TBH. I see two cases: * Case 1: The attacker has physical access to your computer. * Case 2: The attacker doesn't have physical access to your computer. The user account password is irrelevant. My argument in Case 2 does fall down if the user enables SSH in the Sharing panel of System Settings. That's indeed disabled by default, though. It also falls down if the user enables VNC in the Sharing panel, but that is an orthogonal issue as that's not your user account password, and it's limited to eight characters regardless. There is another very important case where this falls down: the computer is enrolled into AD/IPA and the password is used throughout the organization. Just looking at a local machine does not necessarily tell you what the needed password strength is. This is of course not an argument in favor of making the policy stricter, but it does mean that _every_ way to change the password should respect the system-wide libpwsafe configuration. If the site administrator, along with enrolling into IPA/AD, sets up libpwquality to set up password strength restriction they deem appropriate, _all_ of Workstation should enforce these restrictions. Now perhaps the right default is to _have_ no restrictions but they need to be enforced the moment someone sets them up. I mention it because I hesitate to add a password strength check when enabling SSH unless we do so for VNC as well, which would be impossible. Um, “we can’t do $this so we need to leave other parts of the system insecure” is really not sound logic. At the very least we have the option of giving up on VNC instead. And I don’t really see why it would be impossible to add a password strength check for VNC at all; in the worst case we could just store the libpwquality score when the password is set / changed somewhere, and use this stored score to decide whether to warn the user before enabling VNC (storing the scores like this, and telling the attacker which accounts are weak, would be bad on multi-user desktops, but those are rare nowadays and the admin wouldn’t want individual users to go enabling services on such machines anyway). What am I missing? 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
[Bug 1199687] New: perl-threads-1.99 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1199687 Bug ID: 1199687 Summary: perl-threads-1.99 is available Product: Fedora Version: rawhide Component: perl-threads 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.99 Current version/release in rawhide: 1.98-1.fc23 URL: http://search.cpan.org/dist/threads/ 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=nlL5JgEz7ua=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
Re: FESCO request to revert password confirmation change in F22
On 6 March 2015 at 19:13, Michael Catanzaro mcatanz...@gnome.org wrote: On Fri, 2015-03-06 at 19:35 -0500, Miloslav Trmač wrote: Eh, well by my logic they are both so closely-related that it's nonsense to treat them differently... but that comment was more a wishful somebody please fix VNC or rewrite history than anything. I have no clue why VNC passwords are limited/truncated to eight characters, but it seems like that limitation makes the protocol not worth supporting at all, let alone worth promoting in System Settings. I wonder how well FreeRDP is coming along Wasn't http://www.spice-space.org/ a solution to be looked at also? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1199680] perl-DBD-MySQL-4.031 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1199680 --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Scratch build succeeded http://koji.fedoraproject.org/koji/taskinfo?taskID=9161745 -- 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=cxG6OBkMjpa=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
Re: FESCO request to revert password confirmation change in F22
David Cantrell wrote: From what I'm reading in the meeting logs and the ticket comments, it appears the revert decision is basically a temporary solution and a more formal security policy will be discussed later. We had technical arguments in favor of the change originally, but I have yet to see technical arguments against the change come together in any sort of concrete policy. [...] Without an official policy on the matter and only a temporary solution for now, upstream won't be changing. Fedora will need to carry this deviation as a patch in package git for F-22. In other words, you want to give in only temporarily for one release and we will have to fight this nonsense again at every single release? Why can't you just take a no as a no? It is not Anaconda's job to reject perfectly valid passwords just because it doesn't like them. Even the empty string is a valid password. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCo Meeting Minutes (2015-03-04)
On Fri, 2015-03-06 at 19:40 -0500, Miloslav Trmač wrote: Consider a client enrolled in AD/IPA. I agree. We can meet both sets of goals with modifications to libpwquality to allow a *dramatically* weaker default configuration, and then a corporate deployment can set of pwquality.conf however it likes. We could even package different configuration files. -- 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: [EPEL-devel] [EPEL] #31: Broken EPEL 7 ppc64 koji
#31: Broken EPEL 7 ppc64 koji --+ Reporter: ellert | Owner: epel-wranglers Type: defect | Status: closed Priority: blocker | Milestone: Component: Package request |Version: Resolution: fixed| Keywords: --+ Changes (by ellert): * resolution: = fixed * status: new = closed Comment: Seems to be fixed now. -- Ticket URL: https://fedorahosted.org/epel/ticket/31#comment:1 EPEL https://fedoraproject.org/wiki/EPEL Extra Packages for Enterprise Linux ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
[Bug 1199537] New: perl-DBI ships with a module released under Artistic (only) license
https://bugzilla.redhat.com/show_bug.cgi?id=1199537 Bug ID: 1199537 Summary: perl-DBI ships with a module released under Artistic (only) license Product: Red Hat Enterprise Linux 5 Version: 5.11 Component: perl-DBI Severity: urgent Assignee: perl-maint-l...@redhat.com Reporter: psab...@redhat.com QA Contact: qe-baseos-daem...@redhat.com CC: extras...@fedoraproject.org, jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com +++ This bug was initially created as a clone of Bug #1199532 +++ DBI::FAQ (lib/DBI/FAQ.pm) contains the following copyright notice: ### This document is Copyright (c)1994-2000 Alligator Descartes, with portions ### Copyright (c)1994-2000 their original authors. This module is released under ### the 'Artistic' license which you can find in the perl distribution. This is not a FSF free license; please, remove the file from the distribution. The upstream tarball needs to be modified so this file isn't distributed with our SRPMs either. If possible, convince upstream to re-license this file under a FSF free license. -- 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=XaZjwqETsha=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 1199540] New: perl-DBI ships with a module released under Artistic (only) license
https://bugzilla.redhat.com/show_bug.cgi?id=1199540 Bug ID: 1199540 Summary: perl-DBI ships with a module released under Artistic (only) license Product: Red Hat Enterprise Linux 7 Version: 7.1 Component: perl-DBI Severity: urgent Assignee: perl-maint-l...@redhat.com Reporter: psab...@redhat.com QA Contact: qe-baseos-daem...@redhat.com CC: extras...@fedoraproject.org, jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com +++ This bug was initially created as a clone of Bug #1199532 +++ DBI::FAQ (lib/DBI/FAQ.pm) contains the following copyright notice: ### This document is Copyright (c)1994-2000 Alligator Descartes, with portions ### Copyright (c)1994-2000 their original authors. This module is released under ### the 'Artistic' license which you can find in the perl distribution. This is not a FSF free license; please, remove the file from the distribution. The upstream tarball needs to be modified so this file isn't distributed with our SRPMs either. If possible, convince upstream to re-license this file under a FSF free license. -- 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=QeSHtBrPApa=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-Path-Tiny] Created tag perl-Path-Tiny-0.065-1.fc22
The lightweight tag 'perl-Path-Tiny-0.065-1.fc22' was created pointing to: dee36f8... Update to 0.065 -- 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-Path-Tiny] Created tag perl-Path-Tiny-0.065-1.fc23
The lightweight tag 'perl-Path-Tiny-0.065-1.fc23' was created pointing to: dee36f8... Update to 0.065 -- 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
FESCO request to revert password confirmation change in F22
As resolved by FESCO in our meeting on 4 March 2015, FESCO requests that anaconda revert a password behaviour change in the UI from F22, restoring the double-click to confirm weak password behaviour from F21 and earlier. As for how that's realized: I'm not picky. If it makes more sense from a development or maintenance perspective to keep the revert in fedora package git rather than rhinstaller upstream, that's fine; if it makes more sense to revert upstream as well, that's fine too. FESCO is prepared to work with anaconda and other stakeholders to define security models for the various Fedora products. By clarifying our needs we hope to avoid this kind of contention in the future. For FESCO, - 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
[perl-Exporter-Tiny] Correct license tagging (#1199491)
commit beac3f9442cac4607d5d214d5a8cdb0cb37094a5
Author: Paul Howarth p...@city-fan.org
Date: Fri Mar 6 15:15:28 2015 +
Correct license tagging (#1199491)
perl-Exporter-Tiny.spec | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
---
diff --git a/perl-Exporter-Tiny.spec b/perl-Exporter-Tiny.spec
index 4da41ee..9a2cb6c 100644
--- a/perl-Exporter-Tiny.spec
+++ b/perl-Exporter-Tiny.spec
@@ -7,9 +7,9 @@
Name: perl-Exporter-Tiny
Version: 0.042
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: An exporter with the features of Sub::Exporter but only core
dependencies
-License: GPL+ or Artistic
+License: (GPL+ or Artistic) and Public Domain and (GPL+ or Artistic or
CC-BY-SA)
Group: Development/Libraries
URL: http://search.cpan.org/dist/Exporter-Tiny/
Source0:
http://search.cpan.org/CPAN/authors/id/T/TO/TOBYINK/Exporter-Tiny-%{version}.tar.gz
@@ -72,18 +72,27 @@ make test
rm -rf %{buildroot}
%files
+# COPYRIGHT is Public Domain, LICENSE is GPL+ or Artistic
%if 0%{?_licensedir:1}
%license COPYRIGHT LICENSE
%else
%doc COPYRIGHT LICENSE
%endif
-%doc Changes CONTRIBUTING CREDITS README
+# GPL+ or Artistic or CC-BY-SA
+%doc CONTRIBUTING
+# Public Domain
+%doc CREDITS
+# GPL+ or Artistic
+%doc Changes README
%doc examples/
%{perl_vendorlib}/Exporter/
-%{_mandir}/man3/Exporter::Tiny.3pm*
-%{_mandir}/man3/Exporter::Shiny.3pm*
+%{_mandir}/man3/Exporter::Tiny.3*
+%{_mandir}/man3/Exporter::Shiny.3*
%changelog
+* Fri Mar 6 2015 Paul Howarth p...@city-fan.org - 0.042-2
+- Correct license tagging (#1199491)
+
* Thu Oct 9 2014 Paul Howarth p...@city-fan.org - 0.042-1
- Update to 0.042
- Add an 'unimport' feature
--
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 1199538] New: perl-DBI ships with a module released under Artistic (only) license
https://bugzilla.redhat.com/show_bug.cgi?id=1199538 Bug ID: 1199538 Summary: perl-DBI ships with a module released under Artistic (only) license Product: Red Hat Enterprise Linux 6 Version: 6.7 Component: perl-DBI Severity: urgent Assignee: perl-maint-l...@redhat.com Reporter: psab...@redhat.com QA Contact: qe-baseos-daem...@redhat.com CC: extras...@fedoraproject.org, jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com +++ This bug was initially created as a clone of Bug #1199532 +++ DBI::FAQ (lib/DBI/FAQ.pm) contains the following copyright notice: ### This document is Copyright (c)1994-2000 Alligator Descartes, with portions ### Copyright (c)1994-2000 their original authors. This module is released under ### the 'Artistic' license which you can find in the perl distribution. This is not a FSF free license; please, remove the file from the distribution. The upstream tarball needs to be modified so this file isn't distributed with our SRPMs either. If possible, convince upstream to re-license this file under a FSF free license. -- 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=rjgktkKfb3a=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
[PkgDB] limb updated perl-SOAP-Lite
user: limb created branch el6 on package perl-SOAP-Lite To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-SOAP-Lite -- 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
[PkgDB] limb:perl-SOAP-Lite approveacls set to Approved
user: limb set for eseyman acl: approveacls of package: perl-SOAP-Lite from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-SOAP-Lite -- 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 1199491] Incorrect license tag for perl-Exporter-Tiny
https://bugzilla.redhat.com/show_bug.cgi?id=1199491 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-Exporter-Tiny-0.042-2.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/perl-Exporter-Tiny-0.042-2.fc22 -- 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=rVsPJMUorWa=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 1199532] New: perl-DBI ships with a module released under Artistic (only) license
https://bugzilla.redhat.com/show_bug.cgi?id=1199532 Bug ID: 1199532 Summary: perl-DBI ships with a module released under Artistic (only) license Product: Fedora Version: 20 Component: perl-DBI Severity: urgent Assignee: jples...@redhat.com Reporter: psab...@redhat.com QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com DBI::FAQ (lib/DBI/FAQ.pm) contains the following copyright notice: ### This document is Copyright (c)1994-2000 Alligator Descartes, with portions ### Copyright (c)1994-2000 their original authors. This module is released under ### the 'Artistic' license which you can find in the perl distribution. This is not a FSF free license; please, remove the file from the distribution. The upstream tarball needs to be modified so this file isn't distributed with our SRPMs either. If possible, convince upstream to re-license this file under a FSF free license. -- 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=3GjNuVSyIua=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 1199491] Incorrect license tag for perl-Exporter-Tiny
https://bugzilla.redhat.com/show_bug.cgi?id=1199491 --- Comment #2 from Paul Howarth p...@city-fan.org --- I can't find anything that rpmlint is completely happy with so I'm going to go with: (GPL+ or Artistic) and Public Domain and (GPL+ or Artistic or CC-BY-SA) -- 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=ELmvKCGzZqa=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
[PkgDB] limb:perl-SOAP-Lite commit set to Approved
user: limb set for eseyman acl: commit of package: perl-SOAP-Lite from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-SOAP-Lite -- 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
[PkgDB] limb:perl-SOAP-Lite watchcommits set to Approved
user: limb set for eseyman acl: watchcommits of package: perl-SOAP-Lite from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-SOAP-Lite -- 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
[PkgDB] limb:perl-SOAP-Lite watchbugzilla set to Approved
user: limb set for eseyman acl: watchbugzilla of package: perl-SOAP-Lite from: to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-SOAP-Lite -- 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-Exporter-Tiny/f22] Correct license tagging (#1199491)
Summary of changes: beac3f9... Correct license tagging (#1199491) (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: FESCo Meeting Minutes (2015-03-04)
On Thu, 2015-03-05 at 13:10 -0700, Chris Murphy wrote: On Thu, Mar 5, 2015 at 8:41 AM, Adam Jackson a...@redhat.com wrote: On Thu, 2015-03-05 at 00:45 +0100, Kevin Kofler wrote: What better solutions? What password I pick should be none of the installer's business. False. It's entirely reasonable for a product to mandate an appropriate security policy, snip My device? I have the ball. You wanna try and take it away from me? *grin* I'm not daring you or anything. This wasn't my idea. I really don't want to fight. But when you say appropriate as an adjective, I hear it as a verb which means to take something away without my permission. So this entire thing is about you reading as a verb something clearly syntactically an adjective? I'm not sure how I can respond to that. - 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: Lots of emails about `pkgdb created branch 'f21' ...'
On Fri, 6 Mar 2015 13:48:26 + Richard W.M. Jones rjo...@redhat.com wrote: The other one was: Subject: pkgdb created branch 'el6' for the 'mingw-zlib' package But actually I think that was is correct, since that branch *was* created a little earlier than the email. Yeah, so the problem is that our script looks for branch heads in git/refs/heads/ which is fine, but git helpfully 'packs' this stuff if it decides it's a good idea. It did this for the libguestfs repo. ;( So, we need to adjust our script to run git show-refs --heads instead of just looking in the directory. Oh, as a side note, I see you updated f20 branch, but not f21? Was that intentional? The upgrade path is broken by that... kevin pgp_10n0nkcS9.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1199543] New: perl-DBI ships with a module released under Artistic (only) license
https://bugzilla.redhat.com/show_bug.cgi?id=1199543 Bug ID: 1199543 Summary: perl-DBI ships with a module released under Artistic (only) license Product: Red Hat Software Collections Version: rh-perl520 Component: perl-DBI Severity: urgent Assignee: perl-maint-l...@redhat.com Reporter: psab...@redhat.com QA Contact: qe-baseos-a...@redhat.com CC: extras...@fedoraproject.org, jples...@redhat.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com +++ This bug was initially created as a clone of Bug #1199532 +++ DBI::FAQ (lib/DBI/FAQ.pm) contains the following copyright notice: ### This document is Copyright (c)1994-2000 Alligator Descartes, with portions ### Copyright (c)1994-2000 their original authors. This module is released under ### the 'Artistic' license which you can find in the perl distribution. This is not a FSF free license; please, remove the file from the distribution. The upstream tarball needs to be modified so this file isn't distributed with our SRPMs either. If possible, convince upstream to re-license this file under a FSF free license. -- 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=ijznX9UEw0a=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-Exporter-Tiny] Created tag perl-Exporter-Tiny-0.042-2.fc23
The lightweight tag 'perl-Exporter-Tiny-0.042-2.fc23' was created pointing to: beac3f9... Correct license tagging (#1199491) -- 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-Exporter-Tiny] Created tag perl-Exporter-Tiny-0.042-2.fc22
The lightweight tag 'perl-Exporter-Tiny-0.042-2.fc22' was created pointing to: beac3f9... Correct license tagging (#1199491) -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Path-Tiny-0.065.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Path-Tiny: d0cc4ebe40e639c5c2942fe3abb27fc8 Path-Tiny-0.065.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1199331] perl-Net-GitHub-0.73 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1199331 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Net-GitHub-0.73-1.fc23 Resolution|--- |RAWHIDE Last Closed||2015-03-06 07:30:31 -- 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=C6CY9SzCzDa=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
Self introduction: Jonathan Wakely
Hi, I'm planning to become a Fedora packager so am introducing myself here. I started using Red Hat Linux in about 1996 or 1997 and have used GNU/Linux for all my personal computers ever since (moving from RHL to Fedora Core and then to Fedora). I've used a variety of unix-like systems at work, but mainly Red Hat derivatives (RHEL, Fedora, CentOS and Scientific Linux). I've been involved with GCC for many years and am one of the maintainers of the C++ runtime libraries (libstdc++). Since January 2014 I've been doing that full-time, working at Red Hat in the Tools team. I'm also the author of one package included in Fedora, pstreams-devel, so would be happy to help with the packaging for that. I'm looking forward to contributing to Fedora, after getting so much enjoyment and benefit from it for so long. Jonathan -- 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 1199491] New: Incorrect license tag for perl-Exporter-Tiny
https://bugzilla.redhat.com/show_bug.cgi?id=1199491 Bug ID: 1199491 Summary: Incorrect license tag for perl-Exporter-Tiny Product: Fedora Version: rawhide Component: perl-Exporter-Tiny Assignee: p...@city-fan.org Reporter: psab...@redhat.com QA Contact: extras...@fedoraproject.org CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org +++ This bug was initially created as a clone of Bug #1199489 +++ In addition to `GPL+ or Artistic' the following should be added: * CC-BY-SA (the CONTRIBUTING file) * Public Domain (the COPYRIGHT and CREDITS files; see COPYRIGHT) -- 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=ZkaiTsAAR9a=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
Re: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6
On Fri, 6 Mar 2015 14:11:03 +0100 Michael Schwendt mschwe...@gmail.com wrote: On Fri, 06 Mar 2015 12:49:12 +0300, Pavel Alexeev wrote: Hello. ImageMagick itself built in rawhide. just go ahead an rebuild pfstools, please. I'll intervene only in the case something goes wrong. First attempt fails [1] with: pfsinimgmagick.opfsoutimgmagick.o: : InIn functionfunction ``writeFrames(readFramesint(,int ,char* *char)**)': /builddir/'build:/ BUILD/builddir/build/BUILD//pfstools-1.8.5/src/fileformatpfstools/-pfsinimgmagick.cpp1.8.5/:src112/:fileformat/ pfsoutimgmagick.cppundefined: 194:reference undefined toreference `to Magick`:Magick:::ImageImageImage(Imageunsigned( intstd,: :unsigned __cxx11int:,: stdbasic_string::__cxx11char:,: basic_stringstdchar:, :std:char_traits:char_traitscharchar, , stdstdallocatorallocatorcharchar const ,const MagickCore):': StorageType, void const*)' /builddir/build/BUILD/pfstools-1.8.5/src/fileformat/pfsoutimgmagick.cpp:198: undefined reference to `Magick::Image::write(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const)' collect2: error: ld returned 1 exit status But I think it is not ImageMagick issue, but GCC5 instead[2]. I had try add -D_GLIBCXX_USE_CXX11_ABI=0, and error gone, but now it is: /usr/include/OpenEXR/ImfAttribute.h:295: undefined reference to `Imf_2_2::TypedAttributestd::string::staticTypeName()' pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x30): undefined reference to `Imf_2_2::TypedAttributestd::string::writeValueTo(Imf_2_2::OStream, int) const' pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x38): undefined reference to `Imf_2_2::TypedAttributestd::string::readValueFrom(Imf_2_2::IStream, int, int)' Right now unsure how to handle it. But I continue digging. [1] https://kojipkgs.fedoraproject.org//work/tasks/6035/9146035/build.log [2] http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/ It wasn't build with your upgrade, but an older one: https://kojipkgs.fedoraproject.org//work/tasks/6035/9146035/root.log DEBUG util.py:388: ImageMagick i686 6.8.8.10-7.fc22 build 159 k DEBUG util.py:388: ImageMagick-c++ i686 6.8.8.10-7.fc22 build 167 k DEBUG util.py:388: ImageMagick-libsi686 6.8.8.10-7.fc22 build 2.0 M You may need to look into using koji wait-repo … to give koji some time to recreate the buildroot repo metadata after including a new build. It may take roughly up to 20 minutes for a build to be included. Meanwhile, the buildroot should be up-to-date, so give it another try. Thanks. You were faster... I'm also afraid the example above shows building only the ImageMagick direct dependencies might not be sufficient. Seems that right now there are some packages that have been rebuilt with gcc-5 and some not yet. This may lead to more linker failures when one binary wants to link with several libraries with incompatible ABIs... Regards, -- Tomáš Smetana Platform Engineering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File Net-GitHub-0.73.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Net-GitHub: f77f9cfdf230912efafbb0f79f4558da Net-GitHub-0.73.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-GitHub] 0.73 bump
commit 39abf577ec8d83281ac75b7db2f68698c3c15966
Author: Petr Šabata con...@redhat.com
Date: Fri Mar 6 13:29:55 2015 +0100
0.73 bump
.gitignore | 1 +
perl-Net-GitHub.spec | 7 +--
sources | 2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 46bc6df..9f8bac0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -26,3 +26,4 @@ Net-GitHub-0.22.tar.gz
/Net-GitHub-0.69.tar.gz
/Net-GitHub-0.71.tar.gz
/Net-GitHub-0.72.tar.gz
+/Net-GitHub-0.73.tar.gz
diff --git a/perl-Net-GitHub.spec b/perl-Net-GitHub.spec
index 3bf6ab5..911d483 100644
--- a/perl-Net-GitHub.spec
+++ b/perl-Net-GitHub.spec
@@ -1,6 +1,6 @@
Name: perl-Net-GitHub
Summary:Perl interface for github.com
-Version:0.72
+Version:0.73
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
@@ -24,7 +24,7 @@ BuildRequires: perl(vars)
BuildRequires: perl(Carp)
BuildRequires: perl(HTTP::Request)
BuildRequires: perl(HTTP::Request::Common)
-BuildRequires: perl(JSON::Any)
+BuildRequires: perl(JSON::MaybeXS)
BuildRequires: perl(LWP::UserAgent)
BuildRequires: perl(MIME::Base64)
BuildRequires: perl(Moo)
@@ -64,6 +64,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Fri Mar 06 2015 Petr Šabata con...@redhat.com - 0.73-1
+- 0.73 bump
+
* Tue Feb 10 2015 Petr Šabata con...@redhat.com - 0.72-1
- 0.72 bump
diff --git a/sources b/sources
index 20f0709..5a52a47 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-bd9dff198a07978ff9ed8a06dfc6e494 Net-GitHub-0.72.tar.gz
+f77f9cfdf230912efafbb0f79f4558da Net-GitHub-0.73.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Path-Tiny] Update to 0.065
commit dee36f85d16b0271f4adac26134cedf21083908a
Author: Paul Howarth p...@city-fan.org
Date: Fri Mar 6 12:31:03 2015 +
Update to 0.065
- New upstream release 0.065
- Added 'assert' method
- Added 'visit' method
- Added support for a negative count for 'lines' to get the last lines of
a
file
- Fixed tilde expansion if path has spaces
- Make realpath non-fatal if the parent path exists and only the final
path
component does not (was fatal on Windows and some Unixes)
- Removed rendundant locking on tempfile use for spewing
- Work around File::Temp bugs on older ActiveState Windows Perls
https://bugs.activestate.com/show_bug.cgi?id=104767
- Fixed SYNOPSIS example
perl-Path-Tiny.spec | 20 ++--
sources | 2 +-
2 files changed, 19 insertions(+), 3 deletions(-)
---
diff --git a/perl-Path-Tiny.spec b/perl-Path-Tiny.spec
index f60b88d..13423c3 100644
--- a/perl-Path-Tiny.spec
+++ b/perl-Path-Tiny.spec
@@ -1,5 +1,5 @@
Name: perl-Path-Tiny
-Version: 0.061
+Version: 0.065
Release: 1%{?dist}
Summary: File path utility
Group: Development/Libraries
@@ -21,6 +21,7 @@ BuildRequires:perl(Digest::SHA) = 5.45
BuildRequires: perl(Exporter) = 5.57
BuildRequires: perl(Fcntl)
BuildRequires: perl(File::Copy)
+BuildRequires: perl(File::Glob)
BuildRequires: perl(File::Path) = 2.07
BuildRequires: perl(File::Spec) = 3.40
BuildRequires: perl(File::stat)
@@ -50,6 +51,7 @@ Requires: perl(Digest::MD5)
Requires: perl(Digest::SHA) = 5.45
Requires: perl(Fcntl)
Requires: perl(File::Copy)
+Requires: perl(File::Glob)
Requires: perl(File::Path) = 2.07
Requires: perl(File::stat)
Requires: perl(File::Temp) = 0.18
@@ -96,9 +98,23 @@ make test
%license LICENSE
%doc Changes CONTRIBUTING.mkdn README
%{perl_vendorlib}/Path/
-%{_mandir}/man3/Path::Tiny.3pm*
+%{_mandir}/man3/Path::Tiny.3*
%changelog
+* Fri Mar 6 2015 Paul Howarth p...@city-fan.org - 0.065-1
+- Update to 0.065
+ - Added 'assert' method
+ - Added 'visit' method
+ - Added support for a negative count for 'lines' to get the last lines of a
+file
+ - Fixed tilde expansion if path has spaces
+ - Make realpath non-fatal if the parent path exists and only the final path
+component does not (was fatal on Windows and some Unixes)
+ - Removed rendundant locking on tempfile use for spewing
+ - Work around File::Temp bugs on older ActiveState Windows Perls
+https://bugs.activestate.com/show_bug.cgi?id=104767
+ - Fixed SYNOPSIS example
+
* Fri Nov 14 2014 Paul Howarth p...@city-fan.org - 0.061-1
- Update to 0.061
- Fixed append_utf8 and append_raw with 'truncate' option
diff --git a/sources b/sources
index 49c447a..b0ad902 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b82cb206a44b7408b11b991001c45e49 Path-Tiny-0.061.tar.gz
+d0cc4ebe40e639c5c2942fe3abb27fc8 Path-Tiny-0.065.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Lots of emails about `pkgdb created branch 'f21' ...'
Like the ones attached (and not just for libguestfs, but for other packages too). AFAIK no one is creating branches .. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ---BeginMessage--- pkgdb created branch 'f21' for the 'libguestfs' package http://pkgs.fedoraproject.org/cgit/libguestfs.git/log/?h=f21 -- You received this message due to your preference settings at https://apps.fedoraproject.org/notifications//rjones.id.fedoraproject.org/email/23926 ---End Message--- ---BeginMessage--- pkgdb created branch 'f21' for the 'libguestfs' package http://pkgs.fedoraproject.org/cgit/libguestfs.git/log/?h=f21 -- You received this message due to your preference settings at https://apps.fedoraproject.org/notifications//rjones.id.fedoraproject.org/email/23926 ---End Message--- ---BeginMessage--- pkgdb created branch 'f21' for the 'libguestfs' package http://pkgs.fedoraproject.org/cgit/libguestfs.git/log/?h=f21 -- You received this message due to your preference settings at https://apps.fedoraproject.org/notifications//rjones.id.fedoraproject.org/email/23926 ---End Message--- ---BeginMessage--- pkgdb created branch 'f21' for the 'libguestfs' package http://pkgs.fedoraproject.org/cgit/libguestfs.git/log/?h=f21 -- You received this message due to your preference settings at https://apps.fedoraproject.org/notifications//rjones.id.fedoraproject.org/email/23926 ---End Message--- ---BeginMessage--- pkgdb created branch 'f21' for the 'libguestfs' package http://pkgs.fedoraproject.org/cgit/libguestfs.git/log/?h=f21 -- You received this message due to your preference settings at https://apps.fedoraproject.org/notifications//rjones.id.fedoraproject.org/email/23926 ---End Message--- -- 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: Lots of emails about `pkgdb created branch 'f21' ...'
On Fri, 6 Mar 2015 13:22:43 + Richard W.M. Jones rjo...@redhat.com wrote: Like the ones attached (and not just for libguestfs, but for other packages too). AFAIK no one is creating branches .. I saw the error about libguestfs this morning and was going to investigate. I've filed: https://fedorahosted.org/fedora-infrastructure/ticket/4680 with some more info and we will update that with what we find. I can only assume our genacls/make new branch script got confused by something. ;( kevin pgp9QugTCHOzw.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Lots of emails about `pkgdb created branch 'f21' ...'
On Fri, Mar 06, 2015 at 06:31:10AM -0700, Kevin Fenzi wrote: On Fri, 6 Mar 2015 13:22:43 + Richard W.M. Jones rjo...@redhat.com wrote: Like the ones attached (and not just for libguestfs, but for other packages too). AFAIK no one is creating branches .. I saw the error about libguestfs this morning and was going to investigate. I've filed: https://fedorahosted.org/fedora-infrastructure/ticket/4680 with some more info and we will update that with what we find. I can only assume our genacls/make new branch script got confused by something. ;( The other one was: Subject: pkgdb created branch 'el6' for the 'mingw-zlib' package But actually I think that was is correct, since that branch *was* created a little earlier than the email. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.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: FESCo Meeting Minutes (2015-03-04)
On Thu, 2015-03-05 at 15:54 +, Jóhann B. Guðmundsson wrote: On 03/05/2015 03:52 PM, Adam Jackson wrote: On Thu, 2015-03-05 at 09:06 +, Jóhann B. Guðmundsson wrote: An typical outcome from a group of individuals that do not know what they are doing and are making decisions based on their own personal feeling and popularity rather then common sense, practicality and hard technical facts. If you're going to insult the quality of my work you could at least wait until after I've done it. I did ( until after you voted ) Right, fine. It's clear you have a grudge about whatever, and no diplomacy on my part is likely to fix that. I don't need this kind of abuse; I _certainly_ don't need it for making a good-faith effort to finish a class of work that that _you_ also think needs doing. I'm done talking to you. Keep it up and I'll be done listening to you, too. - 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
[perl-Text-Template] Correct license declaration to ((GPL+ or Artistic) and (GPLv2+ or Artistic))
commit 6b6264f16521af3d73fdd207fa93adc1630c
Author: Petr Písař ppi...@redhat.com
Date: Fri Mar 6 13:33:44 2015 +0100
Correct license declaration to ((GPL+ or Artistic) and (GPLv2+ or Artistic))
perl-Text-Template.spec | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
---
diff --git a/perl-Text-Template.spec b/perl-Text-Template.spec
index c3bf408..25636da 100644
--- a/perl-Text-Template.spec
+++ b/perl-Text-Template.spec
@@ -1,10 +1,13 @@
Name: perl-Text-Template
Version:1.45
-Release:17%{?dist}
+Release:18%{?dist}
Summary:Expand template text with embedded Perl
Group: Development/Libraries
-License:GPL+ or Artistic
+# See CPAN RT#102523
+# lib/Text/Template.pm: (GPL+ or Artistic) and (GPLv2+ or Artistic)
+# other files: (GPLv2+ or Artistic)
+License:(GPL+ or Artistic) and (GPLv2+ or Artistic)
URL:http://search.cpan.org/dist/Text-Template/
Source0:
http://www.cpan.org/authors/id/M/MJ/MJD/Text-Template-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
@@ -63,6 +66,10 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Fri Mar 06 2015 Petr Pisar ppi...@redhat.com - 1.45-18
+- Correct license declaration to ((GPL+ or Artistic) and (GPLv2+ or Artistic))
+ (bug #1198991)
+
* Thu Jan 15 2015 Petr Pisar ppi...@redhat.com - 1.45-17
- Specify all dependencies
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6
On Fri, 06 Mar 2015 12:49:12 +0300, Pavel Alexeev wrote: Hello. ImageMagick itself built in rawhide. just go ahead an rebuild pfstools, please. I'll intervene only in the case something goes wrong. First attempt fails [1] with: pfsinimgmagick.opfsoutimgmagick.o: : InIn functionfunction ``writeFrames(readFramesint(,int ,char* *char)**)': /builddir/'build:/ BUILD/builddir/build/BUILD//pfstools-1.8.5/src/fileformatpfstools/-pfsinimgmagick.cpp1.8.5/:src112/:fileformat/ pfsoutimgmagick.cppundefined: 194:reference undefined toreference `to Magick`:Magick:::ImageImageImage(Imageunsigned( intstd,: :unsigned __cxx11int:,: stdbasic_string::__cxx11char:,: basic_stringstdchar:, :std:char_traits:char_traitscharchar, , stdstdallocatorallocatorcharchar const ,const MagickCore):': StorageType, void const*)' /builddir/build/BUILD/pfstools-1.8.5/src/fileformat/pfsoutimgmagick.cpp:198: undefined reference to `Magick::Image::write(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const)' collect2: error: ld returned 1 exit status But I think it is not ImageMagick issue, but GCC5 instead[2]. I had try add -D_GLIBCXX_USE_CXX11_ABI=0, and error gone, but now it is: /usr/include/OpenEXR/ImfAttribute.h:295: undefined reference to `Imf_2_2::TypedAttributestd::string::staticTypeName()' pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x30): undefined reference to `Imf_2_2::TypedAttributestd::string::writeValueTo(Imf_2_2::OStream, int) const' pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x38): undefined reference to `Imf_2_2::TypedAttributestd::string::readValueFrom(Imf_2_2::IStream, int, int)' Right now unsure how to handle it. But I continue digging. [1] https://kojipkgs.fedoraproject.org//work/tasks/6035/9146035/build.log [2] http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/ It wasn't build with your upgrade, but an older one: https://kojipkgs.fedoraproject.org//work/tasks/6035/9146035/root.log DEBUG util.py:388: ImageMagick i686 6.8.8.10-7.fc22 build 159 k DEBUG util.py:388: ImageMagick-c++ i686 6.8.8.10-7.fc22 build 167 k DEBUG util.py:388: ImageMagick-libsi686 6.8.8.10-7.fc22 build 2.0 M You may need to look into using koji wait-repo … to give koji some time to recreate the buildroot repo metadata after including a new build. It may take roughly up to 20 minutes for a build to be included. Meanwhile, the buildroot should be up-to-date, so give it another try. -- 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: Questions about font packaging, hinting and non-responsive maintainer process
On Fri, Mar 6, 2015 at 5:04 AM, Kevin Kofler kevin.kof...@chello.at wrote: I think we are much better off shipping the unhinted version then, letting the Freetype autohinter do its job. Agreed. So that takes care of the question of including the HTML file with the comparison of the two. As far as the doc package is concerned, should I include the separate Symbola.pdf with all the glyphs? Would it be preferable to include the MS Word file (after a conversion) which also contains a changelog? Should I package both or neither? Also, should I start the process for a non-responsive maintainer from the beginning, do I need to file a new bug or can I take it from starting a thread 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
perl-Text-Template license correction
perl-Text-Template users, please note the license tag was corrected from (GPL+ or Artistic) to ((GPL+ or Artistic) and (GPLv2+ or Artistic)). -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Path-Tiny/f22] Update to 0.065
Summary of changes: dee36f8... Update to 0.065 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1199491] Incorrect license tag for perl-Exporter-Tiny
https://bugzilla.redhat.com/show_bug.cgi?id=1199491 Paul Howarth p...@city-fan.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Paul Howarth p...@city-fan.org --- Actually CONTRIBUTING is (GPL+ or Artistic) or CC-BY-SA. So should the overall license be: (GPL+ or Artistic) and Public Domain and ((GPL+ or Artistic) or CC-BY-SA) ? -- 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=PsbzauDHcfa=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
Re: Minifying a javascript library
On 6 March 2015 at 03:18, Kevin Kofler kevin.kof...@chello.at wrote: Tom Hughes wrote: That may not be possible if the minimiser upstream is using is not, or maybe even cannot be, packaged for Fedora. Unfortunately, the popular minifier JSMin is non-Free (it contains the no evil clause, see http://tanguy.ortolo.eu/blog/article46/json-license ) and thus cannot be shipped in Fedora. Minifiers available in Fedora include uglify-js and python-slimit. Thanks Kevin - I'll ask the FPC to consider adding that info to the packaging guidelines for js packages. Jonathan -- 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 1198991] License tag should mention GPLv2+
https://bugzilla.redhat.com/show_bug.cgi?id=1198991 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|tcall...@redhat.com |ppi...@redhat.com --- Comment #1 from Petr Pisar ppi...@redhat.com --- I will change it into more conservative (GPL+ or Artistic) and (GPLv2+ or Artistic). -- 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=GTcoM6sVp9a=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
Re: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6
Hello. 06.03.2015 16:51, Tomáš Smetana wrote: On Fri, 6 Mar 2015 14:11:03 +0100 Michael Schwendt mschwe...@gmail.com wrote: On Fri, 06 Mar 2015 12:49:12 +0300, Pavel Alexeev wrote: Hello. ImageMagick itself built in rawhide. just go ahead an rebuild pfstools, please. I'll intervene only in the case something goes wrong. First attempt fails [1] with: pfsinimgmagick.opfsoutimgmagick.o: : InIn functionfunction ``writeFrames(readFramesint(,int ,char* *char)**)': /builddir/'build:/ BUILD/builddir/build/BUILD//pfstools-1.8.5/src/fileformatpfstools/-pfsinimgmagick.cpp1.8.5/:src112/:fileformat/ pfsoutimgmagick.cppundefined: 194:reference undefined toreference `to Magick`:Magick:::ImageImageImage(Imageunsigned( intstd,: :unsigned __cxx11int:,: stdbasic_string::__cxx11char:,: basic_stringstdchar:, :std:char_traits:char_traitscharchar, , stdstdallocatorallocatorcharchar const ,const MagickCore):': StorageType, void const*)' /builddir/build/BUILD/pfstools-1.8.5/src/fileformat/pfsoutimgmagick.cpp:198: undefined reference to `Magick::Image::write(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const)' collect2: error: ld returned 1 exit status But I think it is not ImageMagick issue, but GCC5 instead[2]. I had try add -D_GLIBCXX_USE_CXX11_ABI=0, and error gone, but now it is: /usr/include/OpenEXR/ImfAttribute.h:295: undefined reference to `Imf_2_2::TypedAttributestd::string::staticTypeName()' pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x30): undefined reference to `Imf_2_2::TypedAttributestd::string::writeValueTo(Imf_2_2::OStream, int) const' pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x38): undefined reference to `Imf_2_2::TypedAttributestd::string::readValueFrom(Imf_2_2::IStream, int, int)' Right now unsure how to handle it. But I continue digging. [1] https://kojipkgs.fedoraproject.org//work/tasks/6035/9146035/build.log [2] http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/ It wasn't build with your upgrade, but an older one: https://kojipkgs.fedoraproject.org//work/tasks/6035/9146035/root.log DEBUG util.py:388: ImageMagick i686 6.8.8.10-7.fc22 build 159 k DEBUG util.py:388: ImageMagick-c++ i686 6.8.8.10-7.fc22 build 167 k DEBUG util.py:388: ImageMagick-libsi686 6.8.8.10-7.fc22 build 2.0 M You may need to look into using koji wait-repo … to give koji some time to recreate the buildroot repo metadata after including a new build. It may take roughly up to 20 minutes for a build to be included. Meanwhile, the buildroot should be up-to-date, so give it another try. Thanks. Thanks. You were faster... I'm also afraid the example above shows building only the ImageMagick direct dependencies might not be sufficient. Seems that right now there are some packages that have been rebuilt with gcc-5 and some not yet. This may lead to more linker failures when one binary wants to link with several libraries with incompatible ABIs... And how we should deal with it? According to https://fedoraproject.org/wiki/Changes/GCC5 there no planned mass-rebuild for GCC5. I could try rebuild dependencies, but should I use -D_GLIBCXX_USE_CXX11_ABI=0? Do we have some policy about it? 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
[Bug 1199491] Incorrect license tag for perl-Exporter-Tiny
https://bugzilla.redhat.com/show_bug.cgi?id=1199491 --- Comment #4 from Petr Šabata psab...@redhat.com --- (In reply to Paul Howarth from comment #2) I can't find anything that rpmlint is completely happy with so I'm going to go with: (GPL+ or Artistic) and Public Domain and (GPL+ or Artistic or CC-BY-SA) I would say this is correct :) -- 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=OR8aogvc41a=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
Re: FESCo Meeting Minutes (2015-03-04)
On Fri, Mar 6, 2015 at 7:15 AM, Adam Jackson a...@redhat.com wrote: So this entire thing is about you reading as a verb something clearly syntactically an adjective? I'm not sure how I can respond to that. Do you acknowledge it's a historical fact that the user password for a local device has been exclusively user domain? If no, give counterfactual examples. You said a product can properly mandate otherwise. Where does the authority or sanction come from to do this? Just by saying it is so, and then just by doing it? -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 22 Alpha status is Go, release on March 10, 2015
At the Fedora 22 Alpha Go/No-Go Meeting #2 that just occurred, it was agreed to Go with the Fedora 22 Alpha by Fedora QA, Release Engineering and Development. Fedora 22 Alpha will be publicly available on Tuesday, March 10, 2015. Meeting details can be seen here: Minutes: http://bit.ly/17Y8Je5 Log: http://bit.ly/1Em9JXo Thanks everyone! It's pretty solid Alpha release and on time :). Jaroslav ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-DateTime] Comment on the misleading license header in XS
commit 0bec7a0d16606a9e87edf6f315c49c74709f4774
Author: Petr Šabata con...@redhat.com
Date: Fri Mar 6 17:10:57 2015 +0100
Comment on the misleading license header in XS
perl-DateTime.spec | 4
1 file changed, 4 insertions(+)
---
diff --git a/perl-DateTime.spec b/perl-DateTime.spec
index 379024f..d25216d 100644
--- a/perl-DateTime.spec
+++ b/perl-DateTime.spec
@@ -3,6 +3,10 @@ Epoch: 2
Version:1.18
Release:1%{?dist}
Summary:Date and time object for Perl
+# Even though lib/DateTime.xs says `the same as Perl', it also points to the
+# LICENSE file (Artistic 2.0). Reading the changelog entry for v0.56 suggests
+# this was simply overlooked when re-licensing.
+# Reported as rt#102546
License:Artistic 2.0
Group: Development/Libraries
URL:http://search.cpan.org/dist/DateTime/
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6
On Fri, 6 Mar 2015 11:31:45 -0500 Rich Mattes richmat...@gmail.com wrote: There's no planned f22 rebuild for gcc5, as f22 defaults to -D_GLIBCXX_USE_CXX11_ABI=0. These issues are cropping up in f23. There should probably be a mass rebuild for f23, and sooner rather than later as rawhide is currently a big game of whack-a-mole when building c++ packages. As soon as gcc folks say things are settled down enough to do one, we can look at scheduling one. ;) It would be a shame to do it too soon though and have a bug requiring another one. I've been rebuilding things as I run into them being broken. (The other day it was the gobby stack: net6, libxml++, obby, gobby). kevin pgp3Qnz9Gr_A0.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora 22 Alpha status is Go, release on March 10, 2015
At the Fedora 22 Alpha Go/No-Go Meeting #2 that just occurred, it was agreed to Go with the Fedora 22 Alpha by Fedora QA, Release Engineering and Development. Fedora 22 Alpha will be publicly available on Tuesday, March 10, 2015. Meeting details can be seen here: Minutes: http://bit.ly/17Y8Je5 Log: http://bit.ly/1Em9JXo Thanks everyone! It's pretty solid Alpha release and on time :). Jaroslav ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
Re: FESCO request to revert password confirmation change in F22
On Fri, 2015-03-06 at 10:52 -0500, David Cantrell wrote: I wish a formal distribution and/or per-variant security policy would come from FESCo (or a committee directed by FESCo) so we could resolve the concerns now and going forward. I don't see the revert decision as being a good step in that direction, only because there was really no technical discussion or reasoning around it. Speaking only for myself: yeah, I didn't like it either. I voted against it (asking for a revert) in the 28 February meeting because I was hoping the engineering teams actually involved would be willing to work with each other. That appears not to have happened, which I consider deeply disappointing all around. There wasn't _no_ technical discussion. Plenty of people were willing to point out that pwquality being overzealous was making it reject passwords that would otherwise have passed on F21, or would be expected to be sufficiently strong according to whatever metric. Plenty of people were willing to point out the ways policy might vary here depending on the deployment scenario. But nobody was willing to make those ideas manifest in, you know, code. So the technical consideration (I felt) we were left with was not regressing relative to F21. That is a stunningly weak justification, given that what we're regressing from wasn't especially well-defined and that we change plenty of things in every release, but here we are. FESCO is prepared to work with anaconda and other stakeholders to define security models for the various Fedora products. By clarifying our needs we hope to avoid this kind of contention in the future. The discussion for this might as well start now -or- at least early enough so it's not too late for F-23. Indeed. I'll bring this back to fesco to find someone to head this up. - 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
[389-devel] please review: Ticket 48102 - nunc-stans - allow replacing event framework memory allocation functions
https://fedorahosted.org/389/ticket/48102 https://fedorahosted.org/389/attachment/ticket/48102/0001-Ticket-48102-allow-replacing-event-framework-memory-.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6
On Fri, Mar 6, 2015 at 11:04 AM, Pavel Alexeev fo...@hubbitus.com.ru wrote: According to https://fedoraproject.org/wiki/Changes/GCC5 there no planned mass-rebuild for GCC5. There's no planned f22 rebuild for gcc5, as f22 defaults to -D_GLIBCXX_USE_CXX11_ABI=0. These issues are cropping up in f23. There should probably be a mass rebuild for f23, and sooner rather than later as rawhide is currently a big game of whack-a-mole when building c++ packages. Rich -- 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-SOAP-Lite/el6] Branch version 0.716 for EPEL6
commit 5645476577f1a09ea5f16e304e00591528cc8485
Author: Emmanuel Seyman emman...@seyman.fr
Date: Fri Mar 6 17:36:23 2015 +0100
Branch version 0.716 for EPEL6
filter-requires.sh| 3 -
perl-SOAP-Lite-0.715-IO-modules.patch | 425 ++
perl-SOAP-Lite-0.716-test.patch | 13 ++
perl-SOAP-Lite.spec | 142 +---
sources | 2 +-
5 files changed, 494 insertions(+), 91 deletions(-)
---
diff --git a/perl-SOAP-Lite-0.715-IO-modules.patch
b/perl-SOAP-Lite-0.715-IO-modules.patch
new file mode 100644
index 000..8c7c9fc
--- /dev/null
+++ b/perl-SOAP-Lite-0.715-IO-modules.patch
@@ -0,0 +1,425 @@
+From e5091cc065b492cfaba9896cb488035e291555e6 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Petr=20=C5=A0abata?= con...@redhat.com
+Date: Thu, 2 Aug 2012 17:10:04 +0200
+Subject: [PATCH] Add IO::SessionDat and IO::SessionSet from SOAP::Lite 0.714
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+
+Signed-off-by: Petr Šabata con...@redhat.com
+---
+ lib/IO/SessionData.pm | 230 +
+ lib/IO/SessionSet.pm | 163 ++
+ 2 files changed, 393 insertions(+), 0 deletions(-)
+ create mode 100644 lib/IO/SessionData.pm
+ create mode 100644 lib/IO/SessionSet.pm
+
+diff --git a/lib/IO/SessionData.pm b/lib/IO/SessionData.pm
+new file mode 100644
+index 000..de85382
+--- /dev/null
b/lib/IO/SessionData.pm
+@@ -0,0 +1,230 @@
++# ==
++#
++# Copyright (C) 2000 Lincoln D. Stein
++# Slightly modified by Paul Kulchenko to work on multiple platforms
++# Formatting changed to match the layout layed out in Perl Best Practices
++# (by Damian Conway) by Martin Kutter in 2008
++#
++# ==
++
++package IO::SessionData;
++
++use strict;
++use Carp;
++use IO::SessionSet;
++use vars '$VERSION';
++$VERSION = 1.02;
++
++use constant BUFSIZE = 3000;
++
++BEGIN {
++my @names = qw(EWOULDBLOCK EAGAIN EINPROGRESS);
++my %WOULDBLOCK =
++(eval {require Errno}
++? map {
++Errno-can($_)
++? (Errno-can($_)-() = 1)
++: (),
++} @names
++: ()
++),
++(eval {require POSIX}
++? map {
++POSIX-can($_) eval { POSIX-can($_)-() }
++? (POSIX-can($_)-() = 1)
++: ()
++} @names
++: ()
++);
++
++sub WOULDBLOCK { $WOULDBLOCK{$_[0]+0} }
++}
++
++# Class method: new()
++# Create a new IO::SessionData object. Intended to be called from within
++# IO::SessionSet, not directly.
++sub new {
++my $pack = shift;
++my ($sset,$handle,$writeonly) = @_;
++# make the handle nonblocking (but check for 'blocking' method first)
++# thanks to Jos Clijmans jos.clijm...@recyfin.be
++$handle-blocking(0) if $handle-can('blocking');
++my $self = bless {
++outbuffer = '',
++sset= $sset,
++handle = $handle,
++write_limit = BUFSIZE,
++writeonly = $writeonly,
++choker = undef,
++choked = 0,
++},$pack;
++$self-readable(1) unless $writeonly;
++return $self;
++}
++
++# Object method: handle()
++# Return the IO::Handle object corresponding to this IO::SessionData
++sub handle {
++return shift-{handle};
++}
++
++# Object method: sessions()
++# Return the IO::SessionSet controlling this object.
++sub sessions {
++return shift-{sset};
++}
++
++# Object method: pending()
++# returns number of bytes pending in the out buffer
++sub pending {
++return length shift-{outbuffer};
++}
++
++# Object method: write_limit([$bufsize])
++# Get or set the limit on the size of the write buffer.
++# Write buffer will grow to this size plus whatever extra you write to it.
++sub write_limit {
++my $self = shift;
++return defined $_[0]
++? $self-{write_limit} = $_[0]
++: $self-{write_limit};
++}
++
++# set a callback to be called when the contents of the write buffer becomes
larger
++# than the set limit.
++sub set_choke {
++my $self = shift;
++return defined $_[0]
++? $self-{choker} = $_[0]
++: $self-{choker};
++}
++
++# Object method: write($scalar)
++# $obj-write([$data]) -- append data to buffer and try to write to handle
++# Returns number of bytes written, or 0E0 (zero but true) if data queued but
not
++# written. On other errors, returns undef.
++sub write {
++my $self = shift;
++return unless my $handle = $self-handle; # no handle
++return unless defined $self-{outbuffer}; # no buffer for queued data
++
++$self-{outbuffer} .= $_[0] if defined $_[0];
++
++my $rc;
++if ($self-pending) { # data in the out buffer to write
[perl-SOAP-Lite] Created branch el6
The branch 'el6' was created pointing to: 340a568... 1.13 bugfix bump -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [Base] Base Design WG meeting summary for 2015-03-06
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 == #fedora-meeting: Fedora Base Design Working Group (2015-03-06) == Meeting started by haraldh at 14:08:05 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2015-03-06/fedora_base_design_working_group.2015-03-06-14.08.log.html . Meeting summary - - --- * candidates for new memberships (haraldh, 14:09:52) * Open Floor (haraldh, 14:21:03) * LINK: https://registry.hub.docker.com/u/armv7/armhf-fedora/ (dgilmore, 14:27:59) * LINK: https://github.com/umiddelb/armhf/wiki/Installing,-running,-using-docker-on-armhf-%28ARMv7%29-devices#installing-docker-on-fedora-21-armhfp (dgilmore, 14:30:27) * LINK: http://paste.fedoraproject.org/194274/14256527/ (dgilmore, 14:38:37) * LINK: https://registry.hub.docker.com/u/mazzolino/qemu-arm-static/dockerfile/ (dgilmore, 14:41:40) Meeting ended at 14:50:54 UTC. Action Items - - Action Items, by person - - --- * **UNASSIGNED** * (none) People Present (lines said) - - --- * dgilmore (47) * vpavlin (25) * haraldh (16) * masta (10) * zodbot (4) * sgallagh (3) * jreznik (2) * lnykryn (1) * msekleta (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJU+d2NAAoJEH7ltONmPFDRYicP/0z4u12HVn9XIKL9w199+io/ IQzUFyd4hiJnn1VTyM9wkOKBVJIv+S+8CJb/L2uCMPEnK524XUrP3KHjxereV9iH fLvOWExswFaaD85989iMLYsfm32ftG5tc8GpA+4jYuYs4RDDOl35NSskAWSLLptx JYeVZafy5fg875DwlH4AkirBPvNRePGWVm6wLMBrch3OgdQlLBI5jkHCj2I5BWEc i4bpYdtE5UNG59phlIgHKfT8yEBTcn4n3G5uCMhXs15CvQqKZXTJ5/CzgiMAI1I4 kX9roParjwt2F5A5joTa8oTXcx3cyr9tYilgj2GLeTmYQ2ic1MMKiFkUTOS1IlNo HbNMKqbGMEp9YYekYlsS13l/GyLFMgg7VlYHWw9oohAd0cer/yv2lBpDOebvo1Fk yaiQm2mOdI8OXdhxhII831kQPsGuwg0FTbMSqlb/YS5R156t5Xhm8KzUrDyC6wdH PR9k68L4ug69g6MOOKKWlzfklIP4lIWqJn+Jy5kYNnEhf6Ozd2xLuZAX/vzcONqH OONUNkrKiTr8YXy22Mc8LMkKt+me6WohlYoMKHRE/5OC3o+HKC6q3h53hpmz6erf +kUKZEkUVEMjBu0vwoGGmzR7zJrV8jQmZ+bbLJ+yg13ldGfzCGNjvls7R+B3VIpX wz8m3JCYxkwHXwvwMAtz =6A7t -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: FESCO request to revert password confirmation change in F22
On Fri, Mar 06, 2015 at 09:43:33AM -0500, Adam Jackson wrote: As resolved by FESCO in our meeting on 4 March 2015, FESCO requests that anaconda revert a password behaviour change in the UI from F22, restoring the double-click to confirm weak password behaviour from F21 and earlier. From what I'm reading in the meeting logs and the ticket comments, it appears the revert decision is basically a temporary solution and a more formal security policy will be discussed later. We had technical arguments in favor of the change originally, but I have yet to see technical arguments against the change come together in any sort of concrete policy. I wish a formal distribution and/or per-variant security policy would come from FESCo (or a committee directed by FESCo) so we could resolve the concerns now and going forward. I don't see the revert decision as being a good step in that direction, only because there was really no technical discussion or reasoning around it. As for how that's realized: I'm not picky. If it makes more sense from a development or maintenance perspective to keep the revert in fedora package git rather than rhinstaller upstream, that's fine; if it makes more sense to revert upstream as well, that's fine too. Without an official policy on the matter and only a temporary solution for now, upstream won't be changing. Fedora will need to carry this deviation as a patch in package git for F-22. FESCO is prepared to work with anaconda and other stakeholders to define security models for the various Fedora products. By clarifying our needs we hope to avoid this kind of contention in the future. The discussion for this might as well start now -or- at least early enough so it's not too late for F-23. Thanks, -- David Cantrell dcantr...@redhat.com Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- 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: [EPEL-devel] EpSCO Meeting Agenda: 06-Mar-2015 17:00 UTC
- Original Message - Sorry for the delay in getting this out. We will be continuing the EPEL Python discussion We will be in #epel on Freenode for our weekly EPEL Steering Committee meeting Friday 06-Mar-2015 at 17:00 UTC. Proposed Agenda items: 1.) Python 3.X Discussion - Dual stack support? - Macros? - How can people help? Hi, I'm sorry but I won't be able to attend today's meeting for some personal reasons that appeared suddenly. I believe the proposal is in a good shape and most pressing concerns have been discussed on the ML. If any more are concerns are voiced on the meeting, I'll try to handle them during next Monday. Also, since I've been in a huge time press lately, I'd like to pass ownership of this proposal to someone else during next week or week after that. One of my colleagues, Matej Stuchlik (CCed), has expressed an interest and would be willing to take this - that's unless someone else who's participated up until now wants to take it. I'll still be around doing suggestions and trying to help, I just don't have the time to really drive this effort and do all the hard work. I'll try to ask Matej to come to the meeting, assuming he has the time today. Thanks for understanding, Slavek 2) Keep the meeting at the same UTC time? [I would like to do so.] 3) Open Floor / Other Items -- Stephen J Smoogen. ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Packagers: incomplete Obsoletes and undead packages
On Thu, Jan 29, 2015 at 10:37 AM, Michael Schwendt mschwe...@gmail.com wrote: Dead and all builds obsoleted: -- python-twisted-conch obsoleted by: python-twisted python-twisted-lore obsoleted by: python-twisted python-twisted-mail obsoleted by: python-twisted python-twisted-names obsoleted by: python-twisted python-twisted-news obsoleted by: python-twisted python-twisted-runner obsoleted by: python-twisted python-twisted-web2 obsoleted by: python-twisted python-twisted-words obsoleted by: python-twisted Can this be related to the failure trying to build buildobt in mock? Using metadata from Fri Mar 6 09:35:17 2015 Error: package python-twisted-14.0.2-1.fc22.x86_64 obsoletes python-twisted-core 14 provided by python-twisted-core-12.2.0-4.fc21.x86_64. package python-twisted-words-12.2.0-4.fc21.x86_64 requires python-twisted-web, but none of the providers can be installed ERROR: Exception(buildbot-0.8.10-2.fc23.src.rpm) Config(fedora-rawhide-x86_64) 4 minutes 18 seconds INFO: Results and/or logs in: /var/lib/mock/fedora-rawhide-x86_64/result ERROR: Command failed. See logs for output. # /usr/bin/dnf builddep --installroot /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever 23 /var/lib/mock/fedora-rawhide-x86_64/root//builddir/build/SRPMS/buildbot-0.8.10-2.fc23.src.rpm --setopt=tsflags=nocontexts -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File Sys-Virt-1.2.13.tar.gz uploaded to lookaside cache by berrange
A file has been added to the lookaside cache for perl-Sys-Virt: 80bd23071fbbe62c4c8c47c8770c48a9 Sys-Virt-1.2.13.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Sys-Virt] Update to 1.2.13 release
commit 1f6dbba6c910217bf378fd8d94f72ac46559184d
Author: Daniel P. Berrange berra...@redhat.com
Date: Fri Mar 6 10:45:57 2015 +
Update to 1.2.13 release
perl-Sys-Virt.spec | 5 -
sources| 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-Sys-Virt.spec b/perl-Sys-Virt.spec
index 34d7005..941f92f 100644
--- a/perl-Sys-Virt.spec
+++ b/perl-Sys-Virt.spec
@@ -1,7 +1,7 @@
# Automatically generated by perl-Sys-Virt.spec.PL
Name: perl-Sys-Virt
-Version:1.2.12
+Version:1.2.13
Release:1%{?dist}%{?extra_release}
Summary:Represent and manage a libvirt hypervisor connection
License:GPLv2+ or Artistic
@@ -59,6 +59,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Fri Mar 6 2015 Daniel P. Berrange berra...@redhat.com - 1.2.13-1
+- Update to 1.2.13 release
+
* Tue Jan 27 2015 Daniel P. Berrange berra...@redhat.com - 1.2.12-1
- Update to 1.2.12 release
diff --git a/sources b/sources
index b73b1fc..be51ad8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-6b88d53b940998cc8bec755108d2cea5 Sys-Virt-1.2.12.tar.gz
+80bd23071fbbe62c4c8c47c8770c48a9 Sys-Virt-1.2.13.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: polymake
polymake has broken dependencies in the F-22 tree: On x86_64: polymake-2.13-18.git20141013.fc22.x86_64 requires perl = 4:5.20.1 On i386: polymake-2.13-18.git20141013.fc22.i686 requires perl = 4:5.20.1 On armhfp: polymake-2.13-18.git20141013.fc22.armv7hl requires perl = 4:5.20.1 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Sys-Virt/f22] Update to 1.2.13 release
Summary of changes: 1f6dbba... Update to 1.2.13 release (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6
Hello. ImageMagick itself built in rawhide. 05.03.2015 15:52, Tomáš Smetana wrote: On Thu, 05 Mar 2015 02:09:00 +0300 Pavel Alexeev fo...@hubbitus.com.ru wrote: Hello. I have long outstanding update of ImageMagick[1] and plan do it in rawhide in 1-3 days. ... Affected packages needs to be rebuild: ... pfstools Package owners in cc. Please let me known if you wish me to rebuild your package. Hi, just go ahead an rebuild pfstools, please. I'll intervene only in the case something goes wrong. First attempt fails [1] with: pfsinimgmagick.opfsoutimgmagick.o: : InIn functionfunction ``writeFrames(readFramesint(,int ,char* *char)**)': /builddir/'build:/ BUILD/builddir/build/BUILD//pfstools-1.8.5/src/fileformatpfstools/-pfsinimgmagick.cpp1.8.5/:src112/:fileformat/ pfsoutimgmagick.cppundefined: 194:reference undefined toreference `to Magick`:Magick:::ImageImageImage(Imageunsigned( intstd,: :unsigned __cxx11int:,: stdbasic_string::__cxx11char:,: basic_stringstdchar:, :std:char_traits:char_traitscharchar, , stdstdallocatorallocatorcharchar const ,const MagickCore):': StorageType, void const*)' /builddir/build/BUILD/pfstools-1.8.5/src/fileformat/pfsoutimgmagick.cpp:198: undefined reference to `Magick::Image::write(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const)' collect2: error: ld returned 1 exit status But I think it is not ImageMagick issue, but GCC5 instead[2]. I had try add -D_GLIBCXX_USE_CXX11_ABI=0, and error gone, but now it is: /usr/include/OpenEXR/ImfAttribute.h:295: undefined reference to `Imf_2_2::TypedAttributestd::string::staticTypeName()' pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x30): undefined reference to `Imf_2_2::TypedAttributestd::string::writeValueTo(Imf_2_2::OStream, int) const' pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x38): undefined reference to `Imf_2_2::TypedAttributestd::string::readValueFrom(Imf_2_2::IStream, int, int)' Right now unsure how to handle it. But I continue digging. [1] https://kojipkgs.fedoraproject.org//work/tasks/6035/9146035/build.log [2] http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/ Thanks and 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
Re: ImageMagick update to 6.9.0-9. So-name bump: libMagick++-6.Q16.so.3 - libMagick++-6.Q16.so.6
On Fri, 06 Mar 2015 12:49:12 +0300 Pavel Alexeev fo...@hubbitus.com.ru wrote: Hello. ImageMagick itself built in rawhide. pfsinimgmagick.opfsoutimgmagick.o: : InIn functionfunction ``writeFrames(readFramesint(,int ,char* *char)**)': /builddir/'build:/ BUILD/builddir/build/BUILD//pfstools-1.8.5/src/fileformatpfstools/-pfsinimgmagick.cpp1.8.5/:src112/:fileformat/ pfsoutimgmagick.cppundefined: 194:reference undefined toreference `to Magick`:Magick:::ImageImageImage(Imageunsigned( intstd,: :unsigned __cxx11int:,: stdbasic_string::__cxx11char:,: basic_stringstdchar:, :std:char_traits:char_traitscharchar, , stdstdallocatorallocatorcharchar const ,const MagickCore):': StorageType, void const*)' /builddir/build/BUILD/pfstools-1.8.5/src/fileformat/pfsoutimgmagick.cpp:198: undefined reference to `Magick::Image::write(std::__cxx11::basic_stringchar, std::char_traitschar, std::allocatorchar const)' collect2: error: ld returned 1 exit status ... But I think it is not ImageMagick issue, but GCC5 instead[2]. I had try add -D_GLIBCXX_USE_CXX11_ABI=0, and error gone, but now it is: /usr/include/OpenEXR/ImfAttribute.h:295: undefined reference to `Imf_2_2::TypedAttributestd::string::staticTypeName()' pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x30): undefined reference to `Imf_2_2::TypedAttributestd::string::writeValueTo(Imf_2_2::OStream, int) const' pfsoutexr.o:(.data.rel.ro._ZTVN7Imf_2_214TypedAttributeISsEE[_ZTVN7Imf_2_214TypedAttributeISsEE]+0x38): undefined reference to `Imf_2_2::TypedAttributestd::string::readValueFrom(Imf_2_2::IStream, int, int)' Right now unsure how to handle it. But I continue digging. Hi, thanks for the effort... I'll see if I could do something about this. Regards, -- Tomáš Smetana Platform Engineering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: FESCo Meeting Minutes (2015-03-04)
On 6 March 2015 at 10:13, Chris Murphy li...@colorremedies.com wrote: On Fri, Mar 6, 2015 at 7:15 AM, Adam Jackson a...@redhat.com wrote: So this entire thing is about you reading as a verb something clearly syntactically an adjective? I'm not sure how I can respond to that. Do you acknowledge it's a historical fact that the user password for a local device has been exclusively user domain? If no, give counterfactual examples. You need to dial back the dialogue a bit. The original email came across as an out of control rant that lost me after the third sentence. If instead of trying to win Flame of the Day award and being less metaphorical and more factual.. it might go a long way to having a conversation versus a man and a soap box in a park. You said a product can properly mandate otherwise. Where does the authority or sanction come from to do this? Just by saying it is so, and then just by doing it? It is a two way street. You own the device. They make the OS. Each is their own 'ball' if I am using your original metaphor appropriately. Each sees the other as the field the ball gets played on. If you don't like the field that your ball is playing on you are free to ask for something to be changed. If it doesn't get changed you can go find another field to play on. And vice versa. I am not saying this is the best way to handle things, but when everyone seems that the only way to communicate is jumping up and down on a soap box claiming the other side is completely in the wrong.. how to handle things better has long been thrown out. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Lots of emails about `pkgdb created branch 'f21' ...'
On Fri, Mar 06, 2015 at 08:08:58AM -0700, Kevin Fenzi wrote: On Fri, 6 Mar 2015 13:48:26 + Richard W.M. Jones rjo...@redhat.com wrote: The other one was: Subject: pkgdb created branch 'el6' for the 'mingw-zlib' package But actually I think that was is correct, since that branch *was* created a little earlier than the email. Yeah, so the problem is that our script looks for branch heads in git/refs/heads/ which is fine, but git helpfully 'packs' this stuff if it decides it's a good idea. It did this for the libguestfs repo. ;( So, we need to adjust our script to run git show-refs --heads instead of just looking in the directory. Oh, as a side note, I see you updated f20 branch, but not f21? Was that intentional? The upgrade path is broken by that... I think it was temporarily in that state this morning, but it should be fixed by now. However I realized that I didn't file a Bodhi update for f20, which I've just done. F20 (1.26.10): https://admin.fedoraproject.org/updates/libguestfs-1.26.10-1.fc20 F21 (1.28.6): https://admin.fedoraproject.org/updates/FEDORA-2015-1691/libguestfs-1.28.6-1.fc21 F22 (1.29.29): https://admin.fedoraproject.org/updates/libguestfs-1.29.29-1.fc22 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Hardened builds
On 02/24/2015 06:44 PM, Jerry James wrote: How is this really supposed to be done? If I'm doing it the right way, then the current method is broken. %undefine _hardened_build -- 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: FESCO request to revert password confirmation change in F22
On Fri, 6 Mar 2015 10:52:34 -0500 David Cantrell dcantr...@redhat.com wrote: From what I'm reading in the meeting logs and the ticket comments, it appears the revert decision is basically a temporary solution and a more formal security policy will be discussed later. We had technical arguments in favor of the change originally, but I have yet to see technical arguments against the change come together in any sort of concrete policy. I think there were technical arguments, but they were hard to find in a bunch of heated rhetoric in many cases. From my view: * Making this change in isolation now and then having to change it again to match a policy seems like a waste. If we revert enough of it now so we have time to make a policy we can just change it hopefully once. * The workstation folks think this change could drive away some of their potential users for not much gain. In their case, sshd is not enabled/running and additional security for a device that sits in your home isn't worth the additional complexity. * There's lots of questions around libpwquality and how well it works and what values it should be set at when. * There's lots of UI questions. Currently anaconda says That password is bad but it doesn't say why, or how to choose a good one, leading to some folks getting frustrated because they don't know the rules,etc. I wish a formal distribution and/or per-variant security policy would come from FESCo (or a committee directed by FESCo) so we could resolve the concerns now and going forward. I don't see the revert decision as being a good step in that direction, only because there was really no technical discussion or reasoning around it. I'd LOVE a security policy to give you, but there's pretty much no way we could have such a policy before F22 Alpha, so I think it's reasonable to ask for a (partial) revert so we can try and gather time and people and come up with something for F23. Without an official policy on the matter and only a temporary solution for now, upstream won't be changing. Fedora will need to carry this deviation as a patch in package git for F-22. ok. FESCO is prepared to work with anaconda and other stakeholders to define security models for the various Fedora products. By clarifying our needs we hope to avoid this kind of contention in the future. The discussion for this might as well start now -or- at least early enough so it's not too late for F-23. Absolutely it should. kevin pgpLnYYTxzjio.pgp Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[389-devel] Please review: Ticket #48105 create tests - tests subdir - test server/client programs - test scripts
https://fedorahosted.org/389/attachment/ticket/48105/0001-Ticket-48105-create-tests-tests-subdir-test-server-c.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: FESCo Meeting Minutes (2015-03-04)
On Fri, Mar 6, 2015 at 11:07 AM, Stephen John Smoogen smo...@gmail.com wrote: Do you acknowledge it's a historical fact that the user password for a local device has been exclusively user domain? If no, give counterfactual examples. You need to dial back the dialogue a bit. The original email came across as an out of control rant that lost me after the third sentence. If instead of trying to win Flame of the Day award and being less metaphorical and more factual.. it might go a long way to having a conversation versus a man and a soap box in a park. That the metaphor doesn't work for you is fine. However, while you castigate the method, you ignore the questions seeking out the facts = that which is not in dispute. You said a product can properly mandate otherwise. Where does the authority or sanction come from to do this? Just by saying it is so, and then just by doing it? It is a two way street. You own the device. They make the OS. Each is their own 'ball' if I am using your original metaphor appropriately. Each sees the other as the field the ball gets played on. If you don't like the field that your ball is playing on you are free to ask for something to be changed. If it doesn't get changed you can go find another field to play on. And vice versa. Your version is not at all the direction I was going in. But I'll go along with your version No other field (OS) asserts any concern for what ball (password) I bring. Any ball shape and size is accepted. Suddenly, one field's referee asserts rules that only particular ball sizes and shapes are allowed. The rules aren't actually specified anywhere, I must show the ball and the referee either accepts or rejects it on a pass fail basis. The minimum ball size and acceptable shapes aren't stated in advance. I merely get binary feedback. By iterating, and making some assumptions, I can infer the requirement means I can bring a large box instead of a ball. And after I pass the referee, I can remove my ball from the box and use it on the field. Ergo, I'm simply being harassed. I can't take the referee seriously at all, just appease his demand. Next, the referee asks for a field wide enforcement of his rule that no one clearly understands or agrees with; and none of the field managers (product working groups) even asked for the rule in the first place. I am not saying this is the best way to handle things, but when everyone seems that the only way to communicate is jumping up and down on a soap box claiming the other side is completely in the wrong.. how to handle things better has long been thrown out. Fedora has a rather Socratic mechanism for avoiding this. Twice now, Anaconda hasn't voluntarily submitted to this process on the same issue of password UI behavior. And therefore a heated debate was inevitable in my opinion. Anaconda has made an unasked for and abrupt change without having met a reasonable burden of proof for the claim this is necessary, again this is two for two. Then, as now, in over 100 emails, there are no proponents for the change outside Anaconda. And now, no proponents of the change by any product working groups. Leading a present or future conversation on platform security policy should probably not lead with we can take your ball away anytime we want. I estimate it's in the vicinity of distinctly unhelpful for positively progressing the conversation. I'm open to suggestions. -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
E: [pulseaudio] main.c: Starting the daemon failed.
hi after the latest update (qt , systemd, ...) i have this problem E: [pulseaudio] main.c: Starting the daemon failed. no audio only some buzz or click any ideas? regards gil -- 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: FESCO request to revert password confirmation change in F22
On Fri, 2015-03-06 at 12:00 -0700, Kevin Fenzi wrote: * The workstation folks think this change could drive away some of their potential users for not much gain. In their case, sshd is not enabled/running and additional security for a device that sits in your home isn't worth the additional complexity. Regarding Workstation: I don't think it provides any additional safety, TBH. I see two cases: * Case 1: The attacker has physical access to your computer. The user account password is no protection: I think pretty much all of us know how to boot a live image and copy files off the disk that way. A BIOS password would actually help somewhat, to delay the attacker as long as it takes the attacker to drain your battery to reset it. A disk encryption password would be real security. * Case 2: The attacker doesn't have physical access to your computer. The user account password is irrelevant. --- This is a pretty simple argument, can anyone point out a flaw? --- My argument in Case 2 does fall down if the user enables SSH in the Sharing panel of System Settings. That's indeed disabled by default, though. It also falls down if the user enables VNC in the Sharing panel, but that is an orthogonal issue as that's not your user account password, and it's limited to eight characters regardless. I mention it because I hesitate to add a password strength check when enabling SSH unless we do so for VNC as well, which would be impossible. Maybe someone else has a good idea here. What if the attacker is not after any files on your computer, but just your password so that he can reuse it somewhere else? In that case, password strength still doesn't matter: if he can see the hash of your password in /etc/shadow to try cracking it, he has already pwned you and might as well log your keystrokes. If the attacker is unskilled and doesn't know how to boot a live image, and the password is *exceedingly* bad (123, alice, mcatanzaro etc.), then it would matter if the attacker could guess it. I personally see little harm in taking the ball away from those who'd use passwords like those. Possibly there is something I have missed -- if someone can set me straight as to a safety issue I am missing, that'd be dandy -- but I for one have yet to see an argument that the strength of the password matters at all! Now, enforcing a strong *disk encryption password* and turning on disk encryption by default (at least for laptops): that would be some actual security. :) Michael 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: FESCO request to revert password confirmation change in F22
On Fri, 2015-03-06 at 15:14 -0600, Michael Catanzaro wrote: On Fri, 2015-03-06 at 12:00 -0700, Kevin Fenzi wrote: * The workstation folks think this change could drive away some of their potential users for not much gain. In their case, sshd is not enabled/running and additional security for a device that sits in your home isn't worth the additional complexity. Regarding Workstation: I don't think it provides any additional safety, TBH. I see two cases: I don't care of have a password strength, maybe like 8 characters and one being a number, should be enough. But they made it so strong, and no information at all on what the problem was, nor info on minimum it took to create one. That and, guess I missed those millions of emails that complained on passwords getting cracked and stolen from all the linux computers in the world, that had to all of a sudden cause a panic to strengthen passwords in the installer. -- Mike Chambers Madisonville, KY Best little town on Earth! -- 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: FESCO request to revert password confirmation change in F22
On Fri, 2015-03-06 at 23:09 +0100, Björn Persson wrote: Adam Jackson wrote: FESCO is prepared to work with anaconda and other stakeholders to define security models for the various Fedora products. By clarifying our needs we hope to avoid this kind of contention in the future. The discussion for this might as well start now -or- at least early enough so it's not too late for F-23. Indeed. I'll bring this back to fesco to find someone to head this up. I hope https://xkcd.com/936/will be among the inputs to that discussion. I'm fond of noting that pwquality has not yet blacklisted any variant of correcthorsebatterystaple. I've been using correcthorse as my stock anaconda testing password, since the strength check has been enforced... -- 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: FESCO request to revert password confirmation change in F22
On 6 Mar 2015, at 23:49, Adam Williamson wrote: On Fri, 2015-03-06 at 23:09 +0100, Björn Persson wrote: I hope https://xkcd.com/936/will be among the inputs to that discussion. I'm fond of noting that pwquality has not yet blacklisted any variant of correcthorsebatterystaple. I've been using correcthorse as my stock anaconda testing password, since the strength check has been enforced... It won't stand up to a combinator attack: https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html -- 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
[Test-Announce] 2015-03-09 @ ** 15:00 ** UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2015-03-09 # Time: ** 15:00 UTC ** NOTE TIME CHANGE (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's QA meeting time again! Daylight savings kicks in in North America (at least, my bit of it) this weekend, so I'm scheduling this meeting for 15:00 UTC. If your clocks go back this weekend, the meeting should be at the same local time as it was before. If your clocks don't go back, it will be one hour earlier. We signed off on Fedora 22 Alpha on Friday, so let's check we've done all the rest of the necessary work around Alpha and do a bit of planning ahead for Beta. We can also check in on upcoming Test Day events. If you have any other topic ideas, please reply to this mail and we'll add them in the meeting! Thanks folks. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 22 Alpha final check-in 3. Fedora 22 Beta planning 4. Test Day check-in 5. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File threads-1.98.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-threads: 3eb1691199b7f23506fb7ba86cf22218 threads-1.98.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
