Re: Packages FTBFS with Python 3.6

On 21.12.2016 07:41, Pavel Raiskup wrote: On Wednesday, December 21, 2016 12:18:47 AM CET Miro Hrončok wrote: Hi all, We've recently tried to rebuild all Python packages with Python 3.6. However, we currently have bunch of packages that simply fail to build. ... Everything currently happens in

Re: release cycle thread (motivations, and... revisiting tick-tock?)

On Ter, 2016-12-20 at 11:20 -0500, Matthew Miller wrote: > 2. I really want releases to come at a known time every year, +/- two >    weeks. Keeping to this with six month targets means that if > (when!) >    we slip, the next release may only have five or four months to > bake. This is a problem

Re: Packages FTBFS with Python 3.6

On Wednesday, December 21, 2016 12:18:47 AM CET Miro Hrončok wrote: > Hi all, > We've recently tried to rebuild all Python packages with Python 3.6. > However, we currently have bunch of packages that simply fail to build. > ... > Everything currently happens in a side tag. I will notify you when

[389-devel] Please review: Readme for nunc-stans for pagure

https://pagure.io/nunc-stans/issue/72 https://pagure.io/nunc-stans/issue/raw/files/52eb1aca39cb95dd608f30fa6ab523b7f2705afdea6e1e7ceb0e2c78ffbf1577-0001-Ticket-72-Add-readme-to-pagure.patch -- William Brown signature.asc Description: This is a digitally signed

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 10:25 PM Gerald B. Cox wrote: > > On Tue, Dec 20, 2016 at 7:10 PM, Rahul Sundaram wrote: > > I don't see any context missing in a direct quote which I responded to. > If you believe otherwise, feel free to summarize your position and include > any context you need to. > >

Re: Fedora Rawhide-20161219.n.0 compose check report

On Mon, 2016-12-19 at 15:46 -0800, Adam Williamson wrote: > > * Installs or upgrades of any package set besides minimal seem to hang > during boot > > That second one is a doozy - it causes most of the failures - and I'm > going to look into it a bit more now. But it's at least the case that >

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 7:10 PM, Rahul Sundaram wrote: > I don't see any context missing in a direct quote which I responded to. > If you believe otherwise, feel free to summarize your position and include > any context you need to. > That's ok... I don't think you'd get the

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 9:59 PM Gerald B. Cox wrote: > > " KDE folks by and large want the updates as fast as possible. If the > GNOME folks would like > their updates to age for six months, they can just keep them in > updates-testing." > > > Obviously you missed it. Again, you have to take

Fedora 23 End Of Life

As of the 20th of December 2016, Fedora 23 has reached its end of life for updates and support. No further updates, including security updates, will be available for Fedora 23. A previous reminder was sent on 28th of November 2016 [0]. Fedora 24 will continue to receive updates until approximately

Fedora 23 End Of Life

As of the 20th of December 2016, Fedora 23 has reached its end of life for updates and support. No further updates, including security updates, will be available for Fedora 23. A previous reminder was sent on 28th of November 2016 [0]. Fedora 24 will continue to receive updates until approximately

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 6:41 PM, Rahul Sundaram wrote: > > " KDE folks by and large want the updates as fast as possible. If the > GNOME folks would like > their updates to age for six months, they can just keep them in > updates-testing." > Obviously you missed it. Again,

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 9:33 PM Gerald B. Cox wrote: > > > Right. I understand that but the solution of letting things stay in > updates-testing for a long time isn't a great way to implement that. It an > abuse of updates-testing. > > > No one is doing that. You have to read

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 6:30 PM, Rahul Sundaram wrote: > > Right. I understand that but the solution of letting things stay in > updates-testing for a long time isn't a great way to implement that. It an > abuse of updates-testing. > No one is doing that. You have to read

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 9:26 PM Gerald B. Cox wrote: > > I was just repeating what I thought was a good suggestion - which is based > upon what has > already been implemented using the current infrastructure. Reserve "new" > releases only for things > that absolutely require it and let

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 5:45 PM, Rahul Sundaram wrote: > Well, it isn't some theoretical construct... it's being done now with KDE >> and has >> been working just fine. It stays in updates-testing until you decide to >> push it to stable. KDE >> folks by and large want the

[Bug 1304825] rt-4.4.0 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1304825 --- Comment #6 from Fedora Update System --- rt-4.4.1-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-3370809994 -- You are receiving this mail because: You

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 1:23 PM Gerald B. Cox wrote: > Well, it isn't some theoretical construct... it's being done now with KDE > and has > been working just fine. It stays in updates-testing until you decide to > push it to stable. KDE > folks by and large want the updates as fast as

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

>> The only way it reduces the risk of releasing a botched update is >> the >> the updates somehow get more testing just by staying in the testing >> channel longer. > > ...and actual QA, from the professionals and volunteers on the QA team, > who are very good at finding bugs pre-release but

[Bug 1406587] New: perl-Module-CoreList-5.20161220 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1406587 Bug ID: 1406587 Summary: perl-Module-CoreList-5.20161220 is available Product: Fedora Version: rawhide Component: perl-Module-CoreList Keywords: FutureFeature, Triaged

[Bug 1406586] perl-PDF-Create-1.40 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1406586 --- Comment #2 from Upstream Release Monitoring --- Created attachment 1234163 --> https://bugzilla.redhat.com/attachment.cgi?id=1234163=edit Rebase-helper rebase-helper-debug.log log file.

[Bug 1406586] New: perl-PDF-Create-1.40 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1406586 Bug ID: 1406586 Summary: perl-PDF-Create-1.40 is available Product: Fedora Version: rawhide Component: perl-PDF-Create Keywords: FutureFeature, Triaged Assignee:

[Bug 1406586] perl-PDF-Create-1.40 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1406586 --- Comment #1 from Upstream Release Monitoring --- Patching or scratch build for perl-PDF-Create-1.39 failed. -- You are receiving this mail because: You are on the CC list for the bug.

[Bug 1406586] perl-PDF-Create-1.40 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1406586 --- Comment #3 from Upstream Release Monitoring --- Patches were not touched. All were applied properly -- You are receiving this mail because: You are on the CC list for the bug.

[Bug 1406583] New: perl-Lingua-EN-Tagger-0.27 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1406583 Bug ID: 1406583 Summary: perl-Lingua-EN-Tagger-0.27 is available Product: Fedora Version: rawhide Component: perl-Lingua-EN-Tagger Keywords: FutureFeature, Triaged

[Bug 1406581] New: perl-CPAN-Perl-Releases-3.02 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1406581 Bug ID: 1406581 Summary: perl-CPAN-Perl-Releases-3.02 is available Product: Fedora Version: rawhide Component: perl-CPAN-Perl-Releases Keywords: FutureFeature, Triaged

Re: New sources format

On Tue, Dec 20, 2016 at 6:31 PM Pádraig Brady wrote: > On 20/12/16 22:28, Christopher wrote: > > What's with the new sources format? > > The old format, I could do `md5sum -c sources` > > Why not make the new format with SHA512 follow the same pattern, so I > could do:

Re: New sources format

On 20/12/16 22:28, Christopher wrote: > What's with the new sources format? > The old format, I could do `md5sum -c sources` > Why not make the new format with SHA512 follow the same pattern, so I could > do: `shasum -c sources` or `sha512sum -c sources`? > > Is there any standard command-line

Packages FTBFS with Python 3.6

Hi all, We've recently tried to rebuild all Python packages with Python 3.6. However, we currently have bunch of packages that simply fail to build. As the list contains >200 packages, it would be very helpful, if you (package maintainers) could help us solve the issues, as we cannot go one

[Bug 1406558] New: build for EPEL7

https://bugzilla.redhat.com/show_bug.cgi?id=1406558 Bug ID: 1406558 Summary: build for EPEL7 Product: Fedora EPEL Version: epel7 Component: perl-Coro Assignee: emman...@seyman.fr Reporter: carl.geo...@rackspace.com

pkgdb: Could not save the request for branch: master, has it already been requested?

Hi I filed the request to unretire eigen2, but I accidentally specified only the rhbz ticket number instead of the full URL so it got denied with "Invalid review BZ". I now tried filing a new unretirement request with the full ticket url, but now I'm getting Could not save the request for

New sources format

What's with the new sources format? The old format, I could do `md5sum -c sources` Why not make the new format with SHA512 follow the same pattern, so I could do: `shasum -c sources` or `sha512sum -c sources`? Is there any standard command-line tool to parse this new format, or do I just gotta

[EPEL-devel] Fedora EPEL 7 updates-testing report

The following Fedora EPEL 7 Security updates need testing: Age URL 652 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087 dokuwiki-0-0.24.20140929c.el7 415 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f mcollective-2.8.4-1.el7 133

[EPEL-devel] Fedora EPEL 6 updates-testing report

The following Fedora EPEL 6 Security updates need testing: Age URL 531 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031 python-virtualenv-12.0.7-1.el6 525 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168 rubygem-crack-0.3.2-2.el6 456

[EPEL-devel] Fedora EPEL 5 updates-testing report

The following Fedora EPEL 5 Security updates need testing: Age URL 772 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-3849 sblim-sfcb-1.3.8-2.el5 415 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-edbea40516 mcollective-2.8.4-1.el5 386

Re: ssh using kerberos (was: Packagers - Flag day 2016 Important changes)

On Mon, 2016-12-19 at 12:45 +0100, Nikos Mavrogiannopoulos wrote: > On Sun, 2016-12-11 at 18:34 -0600, Dennis Gilmore wrote: > > Greetings.  > > > > As previously announced, releng has made a number of changes as > > part > > of > > it's 2016 "flag day".  > > > > All package maintainers will

[389-devel] please review: Ticket 49072 - validate memberOf fixup task args

https://fedorahosted.org/389/ticket/49072 https://fedorahosted.org/389/attachment/ticket/49072/0001-Ticket-49072-validate-memberof-fixup-task-args.patch ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to

[Bug 1242980] -Wcast-qual compiler warnings in hv_func.h

https://bugzilla.redhat.com/show_bug.cgi?id=1242980 --- Comment #10 from Fedora Update System --- perl-5.22.2-365.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See

Enabling "new koji build" Taskotron checks on scratch builds

Hi everyone, I recently started maintaining the-new-hotness[0]. In case anyone isn't familiar with it, it's responsible for filing bugs[1] when a new release is made upstream. One of its components, rebase-helper, currently tries to run a set of tests on packages when upstream releases a new

corsepiu pushed to rt (f25). "Add perl(Net::LDAP::Server::Test)."

From d8f9ee67df7d88fab20d53925640559a60976e5b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ralf=20Cors=C3=A9pius?= Date: Tue, 20 Dec 2016 19:17:54 +0100 Subject: Add perl(Net::LDAP::Server::Test). --- rt.spec | 11 ++- 1 file changed, 6 insertions(+), 5

[Bug 1308365] slic3r crashes when loading known good stl files

https://bugzilla.redhat.com/show_bug.cgi?id=1308365 Fedora End Of Life changed: What|Removed |Added Status|NEW |CLOSED

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 10:22:41AM -0800, Gerald B. Cox wrote: > Well, it isn't some theoretical construct... it's being done now with > KDE and has been working just fine. It stays in updates-testing until > you decide to push it to stable. KDE folks by and large want the > updates as fast as

Re: release cycle thread (motivations, and... revisiting tick-tock?)

On 20 December 2016 at 11:20, Matthew Miller wrote: > On Tue, Dec 20, 2016 at 04:48:44PM +0100, Pavel Raiskup wrote: >> I probably lost the context ... what real-world problems are trying to fix? >> Everything which comes to my mind should be solved by better tooling for

corsepiu pushed to rt (master). "Add perl(Net::LDAP::Server::Test)."

From d8f9ee67df7d88fab20d53925640559a60976e5b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ralf=20Cors=C3=A9pius?= Date: Tue, 20 Dec 2016 19:17:54 +0100 Subject: Add perl(Net::LDAP::Server::Test). --- rt.spec | 11 ++- 1 file changed, 6 insertions(+), 5

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 10:08 AM, Matthew Miller wrote: > On Tue, Dec 20, 2016 at 10:01:57AM -0800, Gerald B. Cox wrote: > > I'll repost this because I believe Kevin had a good point: > > > > I don't understand why we are trying to reinvent the wheel here. The > >

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

Maybe a bit bit off topic WRT $Subject, sorry if it is the case. On Tuesday, December 20, 2016 8:23:12 AM CET Michael Catanzaro wrote: > Batched updates are something I really want to do regardless. > Of course having fixes available sooner is valuable, but you have to weigh > that against the

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 10:01:57AM -0800, Gerald B. Cox wrote: > I'll repost this because I believe Kevin had a good point: > > I don't understand why we are trying to reinvent the wheel here. The > infrastructure for Kevin's suggestion > is in place now - KDE has been using it and it works.

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On 12/20/2016 09:34 AM, Adam Williamson wrote: On Tue, 2016-12-20 at 08:48 -0800, Brendan Conoboy wrote: Batched updates are valuable when testing happens with the whole. It sorts out complex interactions between multiple package updates by testing them all together. Of course, a corollary

Re: release cycle thread (motivations, and... revisiting tick-tock?)

On Tuesday, December 20, 2016 12:11:32 PM CET Matthew Miller wrote: > First, I very frequently hear this: "Fedora should have an LTS — or be > a rolling release." These two things are very far apart in actual > implication, but they have one big thing in common, and when pressed, > it usually

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

I'll repost this because I believe Kevin had a good point: I don't understand why we are trying to reinvent the wheel here. The infrastructure for Kevin's suggestion is in place now - KDE has been using it and it works. On Thu, Dec 8, 2016 at 9:07 PM, Kevin Kofler

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On 20/12/16 17:40, Adam Williamson wrote: On Tue, 2016-12-20 at 17:15 +, Tom Hughes wrote: I didn't think updates-testing would be, it's just I don't think many people use it so I'm not sure having things there for longer will actually help. We do in fact have numbers on this. For

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, 2016-12-20 at 09:33 -0800, Adam Williamson wrote: > If we're talking about *weekly* batched > updates, no, it is not at all practical to assume we'll magically be > able to find the time to do release-validation level testing of each > update batch every week. Of course it wouldn't make

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, 2016-12-20 at 17:15 +, Tom Hughes wrote: > I didn't think updates-testing would be, it's just I don't think many > people use it so I'm not sure having things there for longer will > actually help. We do in fact have numbers on this. For instance, since F25 came out, 218 people have

[Bug 1295439] CVE-2015-8509 bugzilla: information leak when parsing the CSV file [fedora-all]

https://bugzilla.redhat.com/show_bug.cgi?id=1295439 Fedora End Of Life changed: What|Removed |Added Status|NEW |CLOSED

[Bug 1295437] CVE-2015-8508 bugzilla: cross-site scripting when generating a dependency graph [fedora-all]

https://bugzilla.redhat.com/show_bug.cgi?id=1295437 Fedora End Of Life changed: What|Removed |Added Status|NEW |CLOSED

[Bug 1295436] CVE-2015-8508 bugzilla: cross-site scripting when generating a dependency graph

https://bugzilla.redhat.com/show_bug.cgi?id=1295436 Bug 1295436 depends on bug 1295437, which changed state. Bug 1295437 Summary: CVE-2015-8508 bugzilla: cross-site scripting when generating a dependency graph [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=1295437 What

[Bug 1295438] CVE-2015-8509 bugzilla: information leak when parsing the CSV file

https://bugzilla.redhat.com/show_bug.cgi?id=1295438 Bug 1295438 depends on bug 1295439, which changed state. Bug 1295439 Summary: CVE-2015-8509 bugzilla: information leak when parsing the CSV file [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=1295439 What|Removed

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, 2016-12-20 at 08:48 -0800, Brendan Conoboy wrote: > Batched updates are valuable when testing happens with the whole.  It > sorts out complex interactions between multiple package updates by > testing them all together. Of course, a corollary of this is that you have to try and figure

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, 2016-12-20 at 10:48 -0600, Michael Catanzaro wrote: > On Tue, 2016-12-20 at 14:27 +, Tom Hughes wrote: > > Surely it's more likely that it just delays the discovery of the > > botched  > > update? > > I don't think updates-testing should be batched. Testers should of > course still

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 2:32 AM, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 08 December 2016 at 19:26, Dennis Gilmore wrote: > [...] >> I would like to see us stop pushing non security updates to updates from >> updates-testing entirely and do it in monthly

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, Dec 20, 2016 at 2:32 AM, Dominik 'Rathann' Mierzejewski wrote: > On Thursday, 08 December 2016 at 19:26, Dennis Gilmore wrote: > [...] >> I would like to see us stop pushing non security updates to updates from >> updates-testing entirely and do it in monthly

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On 20/12/16 16:48, Michael Catanzaro wrote: On Tue, 2016-12-20 at 14:27 +, Tom Hughes wrote: Surely it's more likely that it just delays the discovery of the botched update? I don't think updates-testing should be batched. Testers should of course still get all test updates ASAP. I

Re: release cycle thread (motivations, and... revisiting tick-tock?)

On Tue, Dec 20, 2016 at 05:51:33PM +0100, Pavel Raiskup wrote: > I believe in both -- and I believe Fedora could have both -- "rolling > release" and "major releases" as a separate "products". > > There are people in the wild who will never use Fedora as the workstation > system because they seek

Re: release cycle thread (motivations, and... revisiting tick-tock?)

On 12/20/2016 08:20 AM, Matthew Miller wrote: On Tue, Dec 20, 2016 at 04:48:44PM +0100, Pavel Raiskup wrote: I probably lost the context ... what real-world problems are trying to fix? Everything which comes to my mind should be solved by better tooling for updates-testing testers. I've given

Re: release cycle thread (motivations, and... revisiting tick-tock?)

On Tuesday, December 20, 2016 11:20:49 AM CET Matthew Miller wrote: > 1. I believe in the value of releases, for the project and for end >users — as opposed to a "rolling release" system. But major releases >are a lot of work across the project — not just release engineering, >but

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On 12/20/2016 06:27 AM, Tom Hughes wrote: On 20/12/16 14:23, Michael Catanzaro wrote: Batched updates are something I really want to do regardless. Of course having fixes available sooner is valuable, but you have to weigh that against the cost of releasing a *botched* update. The advantage of

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, 2016-12-20 at 14:27 +, Tom Hughes wrote: > Surely it's more likely that it just delays the discovery of the > botched  > update? I don't think updates-testing should be batched. Testers should of course still get all test updates ASAP. > The only way it reduces the risk of releasing

ppisar pushed to perl-Storable (f24). "Fix crash in Storable when deserializing malformed code reference"

From e0832acf79987dfcfbde84694c5c391f4de1755c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= Date: Tue, 20 Dec 2016 13:24:36 +0100 Subject: Fix crash in Storable when deserializing malformed code reference --- perl-5.25.7-Fix-Storable-segfaults.patch | 61

ppisar uploaded Test2-Suite-0.000065.tar.gz for perl-Test2-Suite

a04e811867ba1d5afa060ab9ea3e7408acb05ffeddcaa443a18dd3256654292cc746295490fd74a002cfb0fe57f1b0fa4c3b8a0331e7b543a456cc7524668f77 Test2-Suite-0.65.tar.gz

ppisar pushed to perl-Storable (f24). "Specify all dependencies"

From d186884b5d6a726d37e3a85c91c56727aeb2fd9f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= Date: Tue, 20 Dec 2016 13:27:35 +0100 Subject: Specify all dependencies --- perl-Storable.spec | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff

ppisar pushed to perl-Storable (f25). "Fix crash in Storable when deserializing malformed code reference"

From 036fc45229200e0df233ba77addea908667b39fa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= Date: Tue, 20 Dec 2016 13:24:36 +0100 Subject: Fix crash in Storable when deserializing malformed code reference --- perl-5.25.7-Fix-Storable-segfaults.patch | 61

ppisar pushed to perl-Storable (f25). "Specify all dependencies"

From e7c2f0067de8eb45edd0b66a23ff437238e06e50 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= Date: Tue, 20 Dec 2016 13:27:35 +0100 Subject: Specify all dependencies --- perl-Storable.spec | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff

ppisar pushed to perl-Storable (master). "Fix crash in Storable when deserializing malformed code reference"

From 2d6c9c3a895efea6531cee45a66ab5fca151f4a2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= Date: Tue, 20 Dec 2016 13:24:36 +0100 Subject: Fix crash in Storable when deserializing malformed code reference --- perl-5.25.7-Fix-Storable-segfaults.patch | 61

ppisar pushed to perl-Storable (master). "Specify all dependencies"

From c4a917f963bd4b653c99c9e44c6822fb0fed97d7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= Date: Tue, 20 Dec 2016 13:27:35 +0100 Subject: Specify all dependencies --- perl-Storable.spec | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff

Re: release cycle thread (motivations, and... revisiting tick-tock?)

On Tue, Dec 20, 2016, at 05:20 PM, Matthew Miller wrote: > On Tue, Dec 20, 2016 at 04:48:44PM +0100, Pavel Raiskup wrote: > > I probably lost the context ... what real-world problems are trying to fix? > > Everything which comes to my mind should be solved by better tooling for > > updates-testing

Fwd: churchyard's python-breathe-4.2.0-5.fc26 failed to build

I updated python-breathe to 4.4.0 and it build successfully but it appears that happened right after the rebuild of 4.2.0 for Python 3.6 and it keeps retrying the failed build. Is there something I need to do to stop the retries? Thanks, Dave -- Forwarded message -- From:

Re: Creating cores in f25

On 12/19/2016 12:38 PM, jfi...@fedoraproject.org wrote: > Hi Steve, > > Please have a look at this email: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HQ4JFTYLPT5GRW6AD4M2MWGMRAPE7ITN/ Thanks for the pointer... > > systemd developers has decided to

release cycle thread (motivations, and... revisiting tick-tock?)

On Tue, Dec 20, 2016 at 04:48:44PM +0100, Pavel Raiskup wrote: > I probably lost the context ... what real-world problems are trying to fix? > Everything which comes to my mind should be solved by better tooling for > updates-testing testers. I've given this in several ways across the thread, but

Re: Creating cores in f25

On 12/18/2016 11:56 AM, Jan Kratochvil wrote: > On Sun, 18 Dec 2016 17:26:40 +0100, Steve Dickson wrote: >> How do I get f25 to create cores, these days? > > echo >/etc/sysctl.d/foo.conf "kernel.core_pattern=core"; reboot > > It gets broken by: > /usr/lib/sysctl.d/50-coredump.conf > > $

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Thursday, December 8, 2016 9:17:14 AM CET Matthew Miller wrote: > Trying to make this idea a little more concrete. Here's two suggestions > for how it might work. These are strawman ideas -- please provide > alternates, poke holes, etc. And particularly from a QA and rel-eng > point of view.

Re: Making use of the new Fedora Container capabilities

On Tue, Dec 20, 2016 at 01:00:32PM +, James Hogarth wrote: > I see that we just need a Dockerfile in dist-git and fedpkg > container-build can work from the existing git repo but is this > intended to be supported or do we need to provide a fresh review > request and then only build from the

Koji builders' specs

Hi all, where is documented what system/hw is used on (primary) Koji builders? I'm interested in memory, storage, filesystem, host operating system, guest operating system (if those are VMs), etc. The only thing I was able to find is version of mock in the log output. FWIW, I'd like to

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On 20/12/16 14:23, Michael Catanzaro wrote: Batched updates are something I really want to do regardless. Of course having fixes available sooner is valuable, but you have to weigh that against the cost of releasing a *botched* update. The advantage of batched updates is we reduce the risk of

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

On Tue, 2016-12-20 at 10:32 +0100, Dominik 'Rathann' Mierzejewski wrote: > You gave just one disadvantage of this proposal and no advantages at > all. Why do you think the above is a good idea? I, for one, do not > like > waiting a month to get bug fixes that are not security-related. We > are >

[Bug 1231883] perl-HTTP-Recorder-0.07-1.fc23 FTBFS with perl-5.22: unsatisfied dependency

https://bugzilla.redhat.com/show_bug.cgi?id=1231883 Bug 1231883 depends on bug 1231244, which changed state. Bug 1231244 Summary: perl-HTTP-Proxy-0.303-2.fc23 FTBFS: tests fail randomly https://bugzilla.redhat.com/show_bug.cgi?id=1231244 What|Removed |Added

[Bug 1231244] perl-HTTP-Proxy-0.303-2.fc23 FTBFS: tests fail randomly

https://bugzilla.redhat.com/show_bug.cgi?id=1231244 Fedora End Of Life changed: What|Removed |Added Status|ASSIGNED|CLOSED

[Bug 1406382] perl-Test2-Suite-0.000065 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1406382 Petr Pisar changed: What|Removed |Added Depends On||1406428 Referenced

[Bug 1224727] perl-Server-Starter-0.27-1.fc23 FTBFS: races in tests

https://bugzilla.redhat.com/show_bug.cgi?id=1224727 Fedora End Of Life changed: What|Removed |Added Status|NEW |CLOSED

[Bug 1206053] Please branch perl-Data-Validate-Domain for EPEL7

https://bugzilla.redhat.com/show_bug.cgi?id=1206053 Fedora End Of Life changed: What|Removed |Added Status|NEW |CLOSED

[Bug 1204870] perl-Gearman-Client-Async-0.94-19.fc23 FTBFS: t/ async.t fails randomly

https://bugzilla.redhat.com/show_bug.cgi?id=1204870 Fedora End Of Life changed: What|Removed |Added Status|NEW |CLOSED

scanmem lincese changes from GPLv2+ to GPLv3+ and LGPLv3+

Since 0.16 libscanmem is LGPLv3+ and the rest is GPLv3+. -- -Igor Gnatenko ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1406382] perl-Test2-Suite-0.000065 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1406382 --- Comment #1 from Petr Pisar --- This requires not yet packaged Term::Table. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing

[Bug 1166064] CVE-2012-6662 jquery-ui: XSS vulnerability in default content in Tooltip widget

https://bugzilla.redhat.com/show_bug.cgi?id=1166064 Bug 1166064 depends on bug 1166800, which changed state. Bug 1166800 Summary: CVE-2010-5312 python-tw2-jqplugins-flot: jquery-ui: XSS vulnerability in jQuery.ui.dialog title option [fedora-all]

[Bug 1166041] CVE-2010-5312 jquery-ui: XSS vulnerability in jQuery.ui.dialog title option

https://bugzilla.redhat.com/show_bug.cgi?id=1166041 Bug 1166041 depends on bug 1166800, which changed state. Bug 1166800 Summary: CVE-2010-5312 python-tw2-jqplugins-flot: jquery-ui: XSS vulnerability in jQuery.ui.dialog title option [fedora-all]

[Bug 1166064] CVE-2012-6662 jquery-ui: XSS vulnerability in default content in Tooltip widget

https://bugzilla.redhat.com/show_bug.cgi?id=1166064 Bug 1166064 depends on bug 1166766, which changed state. Bug 1166766 Summary: CVE-2010-5312 cobbler: jquery-ui: XSS vulnerability in jQuery.ui.dialog title option [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=1166766 What

Making use of the new Fedora Container capabilities

Hi all, So a couple of questions I'd like clarity on surrounding this... I see that we just need a Dockerfile in dist-git and fedpkg container-build can work from the existing git repo but is this intended to be supported or do we need to provide a fresh review request and then only build from

[Bug 1166041] CVE-2010-5312 jquery-ui: XSS vulnerability in jQuery.ui.dialog title option

https://bugzilla.redhat.com/show_bug.cgi?id=1166041 Bug 1166041 depends on bug 1166766, which changed state. Bug 1166766 Summary: CVE-2010-5312 cobbler: jquery-ui: XSS vulnerability in jQuery.ui.dialog title option [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=1166766 What

[Bug 1166064] CVE-2012-6662 jquery-ui: XSS vulnerability in default content in Tooltip widget

https://bugzilla.redhat.com/show_bug.cgi?id=1166064 Bug 1166064 depends on bug 1166758, which changed state. Bug 1166758 Summary: CVE-2010-5312 asterisk-gui: jquery-ui: XSS vulnerability in jQuery.ui.dialog title option [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=1166758

[Bug 1166041] CVE-2010-5312 jquery-ui: XSS vulnerability in jQuery.ui.dialog title option

https://bugzilla.redhat.com/show_bug.cgi?id=1166041 Bug 1166041 depends on bug 1166758, which changed state. Bug 1166758 Summary: CVE-2010-5312 asterisk-gui: jquery-ui: XSS vulnerability in jQuery.ui.dialog title option [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=1166758

Re: cross-compiler support?

On Di, 2016-12-20 at 09:28 +, David Howells wrote: > Igor Gnatenko wrote: > > > > Well there is gcc-arm-linux-gnu for example but that's for kernels per > > > description > > Didn't see it before... But looks like it doesn't work either: > > /usr/bin/arm-linux-gnu-ld:

Re: dnf error during upgrade that changes a directory into a symlink

On 20.12.2016 13:25, Neal Gompa wrote: > On Tue, Dec 20, 2016 at 7:20 AM, Tom Hughes wrote: >> On 20/12/16 12:15, Till Hofmann wrote: >> >>> I have a package that contains a subdirectory which is changed to a >>> symlink in the next release. When I upgrade, I get the following

  1   2   >