Re: Packages FTBFS with Python 3.6

[Miro Hrončok]

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 a side tag. I will notify you when the
side tag gets merged.


The 'gettext' FTBFS is not related only to Python 3.6 tag [1, FWIW, still
without answer].  Once I resolve those issues, am I expected to build the
package against both 'f26' and (with bumped version) 'f26-python3' targets?



I've built it in side tag by trial and error.


When do you expect merging 'f26-python3' into f26?


ASAP, already requested it.



[1] 
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/PQD576JZLERFY6ROI3GF7UYXKZIRI33G/

Pavel



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

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

[Sérgio Basto]

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 IMHO. We shouldn't shorter the next release when we
slip. 
But I remember when we got a big slip (because Fedora have one of the
first releases that support secure boot), I saw a big concern with
marketing , that was a bad image (the big slip) etc etc. 
So I think this rule was created by marketing/image of the Fedora to
outside. So at least we should assume that we may do less 2 release per
year and break the cycle of releases on May/Jun and Nov/Dec.  
One more note , I didn't agree that slip was bad , Fedora software is
based in many upstream software if other parts slip we may/should also
slip until get things stable. So maybe here is more a question of
marketing to have more freedom in choice of the cycles. Maybe we can do
a schedule with more 3 or 4 week and instead slip we could anticipate
the release, I don't know just another idea.  


>    This doesn't seem like it's the ideal for the above — maybe we can
>    get the engineering processes streamlined enough to make it
>    comfortable, but there's still the matter of marketing and the
> rest.


-- 
Sérgio M. B.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packages FTBFS with Python 3.6

[Pavel Raiskup]

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 the 
> side tag gets merged.

The 'gettext' FTBFS is not related only to Python 3.6 tag [1, FWIW, still
without answer].  Once I resolve those issues, am I expected to build the
package against both 'f26' and (with bumped version) 'f26-python3' targets?
When do you expect merging 'f26-python3' into f26?

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/PQD576JZLERFY6ROI3GF7UYXKZIRI33G/

Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[William Brown]

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 message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

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

[Rahul Sundaram]

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.
>
>
> That's ok... I don't think you'd get the point - as I said the context was
> the thread.
>

I have read the thread.  If you are going to insist that I missed a context
repeatedly, I would recommend you explicitly state what it is without
making any assumptions about whether the other person can understand it.


Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Adam Williamson]

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
> default installs of the KDE live, Server netinst and Server DVD, and
> the 'KDE package set' install test from the Server DVD, all install
> fine, but just get stuck at a black screen after grub when trying to
> boot the installed system. Minimal installs, however - like the default
> install of the Everything netinst, and the 'universal' tests which
> explicitly select the 'Fedora Custom Operating System' package set
> (which is basically the same thing as 'minimal install') - boot fine.
> 
> I'll poke into this a bit more manually.

So this seems to be some kind of kernel issue which showed up with
kernel 4.10; when the openQA VMs are run with '-cpu host', this problem
happens. I poked into it a bit and filed
https://bugzilla.redhat.com/show_bug.cgi?id=1406609 . Running the tests
with '-cpu Nehalem' instead seems to work fine, so I've changed both
openQA instances over to that for now, and done a full re-run of the
20161219.n.0 tests on both instances (those are running now).
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Gerald B. Cox]

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 point - as I said the context was
the thread.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Rahul Sundaram]

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 that comment in context
> of the entire thread.
>

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.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 23 End Of Life

[Mohan Boddu]

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 one month after the release of Fedora 26.
The maintenance schedule of Fedora releases is documented on the
Fedora Project wiki [1]. The Fedora Project wiki also contains
instructions [2] on how to upgrade from a previous release of Fedora
to a version receiving updates.

Mohan Boddu.

[0]https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/HLHKRTIB33EDZXP624GHF2OZLHWAGKSJ/#Q5O44X4BEBOYEKAEVLSXVI44DSNVHBYG
[1]https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule
[2]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 23 End Of Life

[Mohan Boddu]

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 one month after the release of Fedora 26.
The maintenance schedule of Fedora releases is documented on the
Fedora Project wiki [1]. The Fedora Project wiki also contains
instructions [2] on how to upgrade from a previous release of Fedora
to a version receiving updates.

Mohan Boddu.

[0]https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/HLHKRTIB33EDZXP624GHF2OZLHWAGKSJ/#Q5O44X4BEBOYEKAEVLSXVI44DSNVHBYG
[1]https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule
[2]https://fedoraproject.org/wiki/Upgrading?rd=DistributionUpgrades
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

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

[Gerald B. Cox]

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, you have to take that comment in context
of the entire thread.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Rahul Sundaram]

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 the whole thread.
>

What makes you assume I didn't?  I am quoting you again

" 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."
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Gerald B. Cox]

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 the whole thread.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Rahul Sundaram]

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 everything else be updated piecemeal.
>

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.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Gerald B. Cox]

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 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.   Seems
>> like we're just making this more complicated than it is.
>>
>
> You can't keep things simmering in updates-stable for a long time.  What
> if you need to push a bug fix or security fix that is not tied to a new
> major upstream release?
>
> Rahul
>

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 everything else be updated piecemeal.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1304825] rt-4.4.0 is available

[bugzilla]

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 are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[Rahul Sundaram]

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 possible.  If the GNOME
> folks would like
> their updates to age for six months, they can just keep them in
> updates-testing.   Seems
> like we're just making this more complicated than it is.
>

You can't keep things simmering in updates-stable for a long time.  What if
you need to push a bug fix or security fix that is not tied to a new major
upstream release?

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Peter Robinson]

>> 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 currently do zero QA
> on our updates because it's an unmanageable rolling stream of a
> bazillion separate updates. With batched updates, you can test a batch
> with the same overall criteria used for releases to see if it's
> botched. That's the advantage of batching over simply extending the
> amount of time spent in updates-testing.

I've not seen that proposed anywhere, I'm not sure QA has the
resources to actually do that.

>> Which makes the question whether botched updates happen because not
>> enough people use testing, or because there are enough people using
>> it
>> but they don't have enough time to spot the problems before the
>> updates
>> get pushed.
>
> We indeed do not need batched updates to extend the length of time
> updates remain in testing. We could (and should) do that immediately.

At the moment the time is a week, basically I don't see any real
proposal to extend that overall, just to batch updates out on a Monday
(not sure that is the best day if no one  tests over a weekend). Most
of the updates that go out quicker than a week are due to receiving
the explicitly requested amount of karma.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[bugzilla]

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
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 5.20161220
Current version/release in rawhide: 5.20161120-1.fc26
URL: http://search.cpan.org/dist/Module-CoreList/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/3080/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[bugzilla]

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.
See for details and report the eventual error to rebase-helper
https://github.com/phracek/rebase-helper/issues.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[bugzilla]

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: co...@gnome.eu.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: co...@gnome.eu.org, perl-devel@lists.fedoraproject.org



Latest upstream release: 1.40
Current version/release in rawhide: 1.39-1.fc26
URL: http://search.cpan.org/dist/PDF-Create/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/5987/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[bugzilla]

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.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[bugzilla]

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.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[bugzilla]

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
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 0.27
Current version/release in rawhide: 0.25-5.fc25
URL: http://search.cpan.org/dist/Lingua-EN-Tagger/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/6665/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[bugzilla]

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
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 3.02
Current version/release in rawhide: 3.00-1.fc26
URL: http://search.cpan.org/dist/CPAN-Perl-Releases/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/5881/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: New sources format

[Christopher]

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: `shasum -c sources` or `sha512sum -c sources`?
> >
> > Is there any standard command-line tool to parse this new format, or do
> I just gotta grep/awk/bash my way through it?
>
> As far as I can see it's using the BSD tagged format,
> which the coreutils sha512sum command can parse.
> I.E. the following format is supported since v8.20 (2012-10-23)
>
>   SHA512 (filename) = ...
>
> cheers,
> Pádraig
>

Ah, okay, my mistake. `sha512sum -c sources` works fine. I accidentally ran
`shasum -c sources` twice!

Thanks! I wasn't previously aware of this format being a standard anywhere.
`man sha512sum` has enlightened me :)
-- 
Christopher
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: New sources format

[Pádraig Brady]

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 tool to parse this new format, or do I 
> just gotta grep/awk/bash my way through it?

As far as I can see it's using the BSD tagged format,
which the coreutils sha512sum command can parse.
I.E. the following format is supported since v8.20 (2012-10-23)

  SHA512 (filename) = ...

cheers,
Pádraig
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Packages FTBFS with Python 3.6

[Miro Hrončok]

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 by one to investigate the issue.


I've attached the list of failed packages (failed.txt). You can search 
Koji to find out, what went wrong. Sometimes, it's just  missing 
dependency. That dependency should be on this list as well. If it is 
not,  maybe we lost it, please tell us if that's the case. Maybe the 
dependency is circular and something needs to be bootstrapped. If you 
need provenpackager powers, let me know.


Everything currently happens in a side tag. I will notify you when the 
side tag gets merged.


To build your package in mock, I've attached a configuration file for it 
(fedora-rawhide-x86_64-p36.cfg).


Some useful commands:

fedpkg build --target=f26-python3 # build in Koji from git

fedpkg build --target=f26-python3 --scratch # scratch build in Koji from git

koji build f26-python3 --scratch  # scratch build in Koji from SRPM

fedpkg srpm && mock -r fedora-rawhide-x86_64-p36  # mock build

Thanks for your help.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
anjuta
APLpy
atomic
autoarchive
autowrap
aws-shell
borgbackup
btest
cantor
collectd
diffoscope
dnssec-trigger
elastic-curator
fedmsg
fence-agents
frepple
gcc-python-plugin
gerrymander
ginga
glom
gnome-abrt
gnome-builder
gnome-shell
google-api-python-client
graphite-api
gtimelog
gumbo-parser
gutenprint
heat-cfntools
hgsvn
hplip
initial-setup
insight
Io-language
kdevelop-python
lcgdm
libcec
libguestfs
libproxy
libreoffice
libreswan
libuser
libvirt-python
lvm2
netcdf4-python
netstat-monitor
openwsman
orca
orca
pag
pcs
pdc-client
pidgin
pidgin
ProDy
pyatspi
python-acme
python-adal
python-anyjson
python-astroML-addons
python-astroML
python-astropy
python-astroquery
python-astroscrappy
python-autobahn
python-beanbag
python-behave
python-billiard
python-blivet
python-blosc
python-boto3
python-breathe
python-BTrees
python-cached_property
python-cachetools
python-cassandra-driver
python-castellan
python-catkin_tools
python-ccdproc
python-ceilometerclient
python-cerberus
python-congressclient
python-cornice
python-csvkit
python-cups
python-cursive
python-deap
python-defusedxml
python-diff-cover
python-dill
python-django-admin-honeypot
python-django-avatar
python-django-countries
python-django-federated-login
python-django-filter
python-django-formtools
python-django-jsonfield
python-django-model-utils
python-django-mptt
python-django-notifications-hq
python-django-openstack-auth
python-django-pyscss
python-django-tinymce
python-dmidecode
python-envisage
python-fastcache
python-fastimport
python-fedmsg-meta-fedora-infrastructure
python-flask-migrate
python-flask-oidc
python-flask-openid
python-flask-script
python-flower
python-freezegun
python-gatspy
python-gensim
python-geoip2
python-gerritlib
python-glue
python-hacking
python-hglib
python-characteristic
python-inflect
python-jinja2_pluralize
python-kdcproxy
python-keystoneauth1
python-keystoneclient
python-keystonemiddleware
python-kitchen
python-kombu
python-k8sclient
python-lazr-smtptest
python-llfuse
python-magnumclient
python-manilaclient
python-marrow-mailer
python-mdp
python-microversion-parse
python-moksha-common
python-more-itertools
python-moss
python-mwclient
python-natsort
python-netdiff
python-networkx
python-nipy
python-novaclient-os-networks
python-novaclient-os-virtual-interfaces
python-oauth2client
python-openid-cla
python-openid-teams
python-openstacksdk
python-orderedset
python-os-brick
python-osc-lib
python-os-client-config
python-oslo-cache
python-oslo-concurrency
python-oslo-context
python-oslo-db
python-oslo-log
python-oslo-messaging
python-oslo-middleware
python-oslo-policy
python-oslo-reports
python-oslo-rootwrap
python-oslo-serialization
python-oslo-service
python-oslo-utils
python-oslo-versionedobjects
python-oslo-vmware
python-osrf-pycommon
python-parsedatetime
python-photutils
python-profilehooks
python-prov
python-pybtex-docutils
python-pybtex
python-pyface
python-pyopencl
python-pyramid-mako
python-pyramid
python-pyramid-tm
python-pytest-pep8
python-pytest-testmon
python-pyvo
python-recommonmark
python-repoze-who-plugins-sa
python-reproject
python-requests-mock
python-rows
python-scikit-image
python-seesaw
python-smartcols
python-sphinxcontrib-bibtex
python-sphinxcontrib-programoutput
python-sphinxcontrib-spelling
python-sqlacodegen
python-statsd
python-stem
python-structlog
python-suds
python-sure
python-swiftclient
python-s3transfer
python-tackerclient
python-taskw
python-tosca-parser
python-traitsui
python-troveclient
python-txaio
python-wcsaxes
python-wikitcms
python-xlwt
python-zc-lockfile
python-ZEO
python-ZODB
python-zope-configuration
python-zope-filerepresentation
python-zope-schema
python-zope-testrunner
python3-cherrypy
python3-openid

[Bug 1406558] New: build for EPEL7

[bugzilla]

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
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org



I'm a co-maintainer of uwsgi in Fedora and EPEL.  Uwsgi has a subpackage for a
coroae plugin, but it is disabled on EPEL7 because it needs this package. 
Please consider adding an EPEL7 branch for perl-Coro so that I can enable the
uwsgi-plugin-coroae subpackage for EPEL7.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[Sandro Mani]

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 branch: master, has it already been 
requested?


It looks like the denied request still counts as pending request?

Thanks
Sandro
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

New sources format

[Christopher]

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 grep/awk/bash my way through it?

-- 
Christopher
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[updates]

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  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23fa04bf1c   
redis-3.2.3-1.el7
 117  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e8f4ff76b3   
chicken-4.11.0-3.el7
  60  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-ee3cc4d1b6   
compat-guile18-1.8.8-14.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-090cbd0a83   
botan-1.10.14-3.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-73b4fc1c78   
chromium-55.0.2883.87-1.el7.1
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-d21e337184   
hdf5-1.8.12-8.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-0899019edf   
game-music-emu-0.6.1-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-911ea9b639   
fedfind-3.2.3-1.el7 python-wikitcms-2.1.9-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-17165c490b   
nagios-plugins-2.1.4-2.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-857dac8710   
tarantool-1.6.9.52-2.el7 msgpuck-1.1.3-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

bonnie++-1.97.3-1.el7
drush-8.1.8-3.el7
opendmarc-1.3.2-0.12.el7
php-horde-Horde-Browser-2.0.13-1.el7
php-horde-Horde-Compress-2.1.6-1.el7
php-horde-Horde-Core-2.27.6-1.el7
php-horde-Horde-Crypt-2.7.5-1.el7
php-horde-Horde-CssMinify-1.0.3-1.el7
php-horde-Horde-Date-2.3.2-1.el7
php-horde-Horde-Imap-Client-2.29.12-1.el7
php-horde-Horde-Kolab-Storage-2.2.3-1.el7
php-horde-Horde-Pack-1.0.7-1.el7
php-horde-horde-5.2.13-2.el7
php-horde-imp-6.2.17-2.el7
php-horde-ingo-3.2.13-2.el7
php-horde-kronolith-4.2.19-2.el7
php-horde-mnemo-4.2.12-2.el7
php-horde-nag-4.2.13-2.el7
php-horde-passwd-5.0.6-2.el7
php-horde-turba-4.2.18-2.el7
php-horde-wicked-2.0.7-2.el7
python-winrm-0.2.1-3.el7
rsnapshot-1.4.2-2.el7

Details about builds:



 bonnie++-1.97.3-1.el7 (FEDORA-EPEL-2016-aa287b30ba)
 Filesystem and disk benchmark & burn-in suite

Update Information:

- Rebuilt for new upstream release 1.97.3, fixes rhbz #1114277

References:

  [ 1 ] Bug #1145291 - Please build an EPEL7 build of bonnie++
https://bugzilla.redhat.com/show_bug.cgi?id=1145291
  [ 2 ] Bug #928385 - bonnie++ produces + instead of actual values for file 
create timings
https://bugzilla.redhat.com/show_bug.cgi?id=928385
  [ 3 ] Bug #1114277 - bonnie++-1.97.3 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1114277




 drush-8.1.8-3.el7 (FEDORA-EPEL-2016-1041b3bef8)
 Command line shell and scripting interface for Drupal

Update Information:

**RPM fix:** Add missing `php-composer(fedora/autoloader)` dependency

References:

  [ 1 ] Bug #1406416 - EL7 autoload.php requires Fedora Autoloader
https://bugzilla.redhat.com/show_bug.cgi?id=1406416




 opendmarc-1.3.2-0.12.el7 (FEDORA-EPEL-2016-61b2a31c65)
 A Domain-based Message Authentication, Reporting & Conformance (DMARC) milter 
and library

Update Information:

This update providees version 1.3.2 Beta 1. See See:
https://sourceforge.net/p/opendmarc/activity/ for details on changes in 1.3.2
Beta 0 and 1. It contains additional bug fixes from Juri Haberland's [tracking
page](http://batleth.sapienti-sat.org/projects/opendmarc/). It fixes a bug that
would cause opendmarc to crash soon after starting up. See [RHBZ
#1398444](https://bugzilla.redhat.com/show_bug.cgi?id=1398444) and upstream
[#185](https://sourceforge.net/p/opendmarc/tickets/185/).

References:

  [ 1 ] Bug #1398444 - [abrt] opendmarc: mlfi_connect(): opendmarc killed by 
SIGSEGV
https://bugzilla.redhat.com/show_bug.cgi?id=1398444
  [ 2 ] Bug #1293279 - opendkim miss LDAP support
https://bugzilla.redhat.com/show_bug.cgi?id=1293279
  [ 3 ] Bug #1287176 - OpenDMARC does 

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

[updates]

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  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8156   
nagios-4.0.8-1.el6
 415  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 386  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 117  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8594ed3a53   
chicken-4.11.0-3.el6
  56  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-cb5398893b   
nodejs-0.10.48-3.el6
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-851b04cffd   
golang-1.7.4-1.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-681fa1a146   
hdf5-1.8.5.patch1-10.el6
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-a9e593c654   
game-music-emu-0.6.1-1.el6
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-dc9e470823   
nagios-plugins-2.1.4-2.el6


The following builds have been pushed to Fedora EPEL 6 updates-testing

opendmarc-1.3.2-0.12.el6
php-horde-Horde-Browser-2.0.13-1.el6
php-horde-Horde-Compress-2.1.6-1.el6
php-horde-Horde-Core-2.27.6-1.el6
php-horde-Horde-Crypt-2.7.5-1.el6
php-horde-Horde-CssMinify-1.0.3-1.el6
php-horde-Horde-Date-2.3.2-1.el6
php-horde-Horde-Imap-Client-2.29.12-1.el6
php-horde-Horde-Kolab-Storage-2.2.3-1.el6
php-horde-Horde-Pack-1.0.7-1.el6
php-horde-horde-5.2.13-2.el6
php-horde-imp-6.2.17-2.el6
php-horde-ingo-3.2.13-2.el6
php-horde-kronolith-4.2.19-2.el6
php-horde-mnemo-4.2.12-2.el6
php-horde-nag-4.2.13-2.el6
php-horde-passwd-5.0.6-2.el6
php-horde-turba-4.2.18-2.el6
php-horde-wicked-2.0.7-2.el6
rsnapshot-1.4.2-2.el6

Details about builds:



 opendmarc-1.3.2-0.12.el6 (FEDORA-EPEL-2016-23163acc27)
 A Domain-based Message Authentication, Reporting & Conformance (DMARC) milter 
and library

Update Information:

This update providees version 1.3.2 Beta 1. See See:
https://sourceforge.net/p/opendmarc/activity/ for details on changes in 1.3.2
Beta 0 and 1. It contains additional bug fixes from Juri Haberland's [tracking
page](http://batleth.sapienti-sat.org/projects/opendmarc/). It fixes a bug that
would cause opendmarc to crash soon after starting up. See [RHBZ
#1398444](https://bugzilla.redhat.com/show_bug.cgi?id=1398444) and upstream
[#185](https://sourceforge.net/p/opendmarc/tickets/185/).

References:

  [ 1 ] Bug #1398444 - [abrt] opendmarc: mlfi_connect(): opendmarc killed by 
SIGSEGV
https://bugzilla.redhat.com/show_bug.cgi?id=1398444
  [ 2 ] Bug #1293279 - opendkim miss LDAP support
https://bugzilla.redhat.com/show_bug.cgi?id=1293279
  [ 3 ] Bug #1287176 - OpenDMARC does not accept valid mail size limiting 
syntax in DMARC record
https://bugzilla.redhat.com/show_bug.cgi?id=1287176
  [ 4 ] Bug #1331971 - wrong result with self SPF check
https://bugzilla.redhat.com/show_bug.cgi?id=1331971
  [ 5 ] Bug #1332521 - opendmarc always adds  spf=pass
https://bugzilla.redhat.com/show_bug.cgi?id=1332521




 php-horde-Horde-Browser-2.0.13-1.el6 (FEDORA-EPEL-2016-e4b4066b3f)
 Horde Browser API

Update Information:

Horde_Browser 2.0.13  * [jan] Update German translation.




 php-horde-Horde-Compress-2.1.6-1.el6 (FEDORA-EPEL-2016-2d2b9e3d81)
 Horde Compression API

Update Information:

**Horde_Compress 2.1.6**  * [jan] Update German translation.




 php-horde-Horde-Core-2.27.6-1.el6 (FEDORA-EPEL-2016-d538f0c332)
 Horde Core Framework libraries

Update Information:

Horde_Core 2.27.6  * [jan] Don't show apps with 'admin' status in menu (Bug
#14526).




 

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

[updates]

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  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-582c8075e6   
thttpd-2.25b-24.el5


The following builds have been pushed to Fedora EPEL 5 updates-testing

opendmarc-1.3.2-0.12.el5
rsnapshot-1.4.2-2.el5

Details about builds:



 opendmarc-1.3.2-0.12.el5 (FEDORA-EPEL-2016-16c55d3061)
 A Domain-based Message Authentication, Reporting & Conformance (DMARC) milter 
and library

Update Information:

This update providees version 1.3.2 Beta 1. See See:
https://sourceforge.net/p/opendmarc/activity/ for details on changes in 1.3.2
Beta 0 and 1. It contains additional bug fixes from Juri Haberland's [tracking
page](http://batleth.sapienti-sat.org/projects/opendmarc/). It fixes a bug that
would cause opendmarc to crash soon after starting up. See [RHBZ
#1398444](https://bugzilla.redhat.com/show_bug.cgi?id=1398444) and upstream
[#185](https://sourceforge.net/p/opendmarc/tickets/185/).

References:

  [ 1 ] Bug #1398444 - [abrt] opendmarc: mlfi_connect(): opendmarc killed by 
SIGSEGV
https://bugzilla.redhat.com/show_bug.cgi?id=1398444
  [ 2 ] Bug #1293279 - opendkim miss LDAP support
https://bugzilla.redhat.com/show_bug.cgi?id=1293279
  [ 3 ] Bug #1287176 - OpenDMARC does not accept valid mail size limiting 
syntax in DMARC record
https://bugzilla.redhat.com/show_bug.cgi?id=1287176
  [ 4 ] Bug #1331971 - wrong result with self SPF check
https://bugzilla.redhat.com/show_bug.cgi?id=1331971
  [ 5 ] Bug #1332521 - opendmarc always adds  spf=pass
https://bugzilla.redhat.com/show_bug.cgi?id=1332521




 rsnapshot-1.4.2-2.el5 (FEDORA-EPEL-2016-220a6d678c)
 Local and remote filesystem snapshot utility

Update Information:

Revised update for EPEL with LVM functionality not broken    Update to 1.4.2

References:

  [ 1 ] Bug #1375289 - rsnapshot out of date, new 1.4.2 version and new 
upstream source
https://bugzilla.redhat.com/show_bug.cgi?id=1375289
  [ 2 ] Bug #1117966 - rsnapshot.conf using deprecated "interval" instead of 
new "retain" keyword
https://bugzilla.redhat.com/show_bug.cgi?id=1117966

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

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

[Dennis Gilmore]

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 want to make sure they have updated to
> > the 
> > following package versions (some may be in testing as of this
> > email):
> > 
> >  python-cccolutils-1.4-1
> >  fedpkg-1.26-2
> >  fedora-packager-0.6.0.0-1
> >  pyrpkg-1.47-3
> >  koji-1.11.0-1
> > 
> > Please also see the following links for up to date information: 
> > 
> > https://fedoraproject.org/wiki/ReleaseEngineering/FlagDay2016
> > 
> > The following changes were made:
> > 
> > * koji and the source lookaside were changed to use kerberos
> > authentication
> > instead of ssl certificates. All maintainers will need to:
> > 
> > kinit your-fas-accountn...@fedoraaproject.org
> > 
> > to get a valid kerberos TGT and be able to authenticate to koji
> > and 
> > the lookaside upload cgi. 
> 
> Will this include a switch to GSSAPI for SSH? As it is now the SSH
> private key is still needed to commit to git repositories, even if a
> valid ticket is present.

Maybe down the road. but certainly not in the immediate future.

Dennis

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Mark Reynolds]

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 389-devel-le...@lists.fedoraproject.org

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

[bugzilla]

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 https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2016-85dffa754f

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Enabling "new koji build" Taskotron checks on scratch builds

[Jeremy Cline]

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 version.

There are a lot of problems with this process and for the most part it
does not work. I started a discussion on the issue tracker about
removing rebase-helper[2] as a dependency. Kamil Páral mentioned that
there has been discussion about running the "new koji build" Taskotron
checks for scratch builds. This would be great for the-new-hotness since
it would do everything and more that rebase-helper currently does with
respect to testing.

How do people feel about this? Are there any obstacles?

Thanks!


[0] https://github.com/fedora-infra/the-new-hotness/
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1404680
[2] https://github.com/fedora-infra/the-new-hotness/issues/145

-- 
Jeremy Cline
XMPP: jer...@jcline.org
IRC:  jcline



signature.asc
Description: OpenPGP digital signature
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-devel-le...@lists.fedoraproject.org

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

[notifications]

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 deletions(-)

diff --git a/rt.spec b/rt.spec
index ed37041..3e01f27 100644
--- a/rt.spec
+++ b/rt.spec
@@ -39,7 +39,7 @@
 
 Name:  rt
 Version:   4.4.1
-Release:   1%{?dist}
+Release:   2%{?dist}
 Summary:   Request tracker
 
 Group: Applications/Internet
@@ -141,8 +141,7 @@ BuildRequires: perl(Locale::Maketext::Fuzzy) >= 0.11
 BuildRequires: perl(Locale::Maketext::Lexicon) >= 0.32
 BuildRequires: perl(Locale::PO)
 BuildRequires: perl(Log::Dispatch) >= 2.23
-# Optional, N/A in Fedora. RHBZ#1312303
-# BuildRequires: perl(Net::LDAP::Server::Test)
+BuildRequires: perl(Net::LDAP::Server::Test)
 %{?with_devel_mode:BuildRequires: perl(Log::Dispatch::Perl)}
 BuildRequires: perl(LWP)
 BuildRequires: perl(LWP::UserAgent)
@@ -312,8 +311,7 @@ Requires:   perl(DBD::SQLite)
 Requires:  perl(GnuPG::Interface)
 # Bug: The testsuite unconditionally depends upon perl(GraphViz)
 Requires:  perl(GraphViz)
-# Optional, N/A in Fedora.
-# Requires:perl(Net::LDAP::Server::Test)
+Requires:  perl(Net::LDAP::Server::Test)
 Requires:  perl(Plack::Handler::Apache2)
 Requires:  perl(Set::Tiny)
 Requires:  perl(String::ShellQuote)
@@ -608,6 +606,9 @@ fi
 %endif
 
 %changelog
+* Tue Dec 20 2016 Ralf Corsépius  - 4.4.1-2
+- Add perl(Net::LDAP::Server::Test).
+
 * Thu Jul 28 2016 Ralf Corsépius  - 4.4.1-1
 - Update to rt-4.4.1.
 - Reflect upstream URLs having changed.
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/rt.git/commit/?h=f25=d8f9ee67df7d88fab20d53925640559a60976e5b
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1308365

Fedora End Of Life  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |EOL
Last Closed||2016-12-20 13:44:03



--- Comment #5 from Fedora End Of Life  ---
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[Matthew Miller]

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 possible. If the GNOME folks would like their
> updates to age for six months, they can just keep them in
> updates-testing. Seems like we're just making this more complicated
> than it is.

Right, KDE on Fedora is more like a rolling release. TBH, this is
something of a luxury because none of the Editions are dependent on
KDE. If Workstation were KDE-based, I'd be inclined to push back
against the practice.

I don't think anyone said we want the GNOME updates to "age" for six
months. What I'm saying is that the release model allows us to provide
a new shiny version quickly after the upstream release, but users get
to choose if they want it right now. If we did this by putting a big GNOME
update into updates-testing, a) people would have to opt into getting
testing updates to get it, or do the even more advanced thing of
cherry-picking from the updates repo, and b) once having done that,
would presumably get all future updates to that stack through
updates-testing, and c) if there's a fix to the older GNOME, we
wouldn't have a way to provide it.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Stephen John Smoogen]

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
>> updates-testing testers.
>
> I've given this in several ways across the thread, but I don't mind
> restating. :)
>
> 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 marketing, ambassadors, design, docs, and others. One possible
>way to reduce this is to have major releases less frequently. I want
>a cadence that gives us the highest return on effort. Maybe that's
>six months — and maybe it isn't.
>
> 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 doesn't seem like it's the ideal for the above — maybe we can
>get the engineering processes streamlined enough to make it
>comfortable, but there's still the matter of marketing and the rest.
>
> 3. The modularity initiative will mean that different big chunks of
>what we use to compose the OS can update at different speeds and
>have different lifecycles. That gives us a lot more flexibility in
>the above, and I'd like us to start thinking about what we *want*
>to.
>

I am having a hard time reconciling 2 and 3. We want to have regular
releases AND we want them to be whenever we want... this is Quantum
Mechanics all over... the release is both a particle and a wave.. and
the cat is both alive and dead.

The difference is that only one of the two events is 'real' after you
have opened the box. Do we end up with a release which is regular? Or
do we end up with a release which has different life-cycles? If the
answer is 'yes', ok but we will need to be clearer when and how we
measure both.

> I suggested one release a year as an alternative to the current two per
> year. I guess three per year would be possible (but seems counter to
> the above); other plans like eight- or nine-month cycles don't have the
> fixed-calendar property I'm looking for (and I'm pretty sure no one
> wants to go to one every two years).
>
> The proposals previously in this thread are ideas aimed at presenting
> users with an annual release from a marketing/ambassadors/design, etc.,
> point of view, but also addressing our upstream stakeholders' desire to
> have Fedora ship their software fast. (For example, GNOME.) I hoped we
> could find ways to make them also reduce release effort for developers,
> packagers, releng, and QA, but from the feedback so far people don't
> really feel like those particular suggestions do.
>

The only way I can see that working is that QA, releng, etc only deal
with a small part of the OS that the rest of the OS is built from.
Everything else above either a sack of potatoes or a well oiled
machine but it depends on the group (be it KDE, GNOME,
Docker/Atomic/etc, i386/ppc/arm, etc) putting the work into it to make
it so. It may make things look like 'second class citizens' but every
group has called itself that when it doesn't get its way so it just
makes it clearer.



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[notifications]

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 deletions(-)

diff --git a/rt.spec b/rt.spec
index ed37041..3e01f27 100644
--- a/rt.spec
+++ b/rt.spec
@@ -39,7 +39,7 @@
 
 Name:  rt
 Version:   4.4.1
-Release:   1%{?dist}
+Release:   2%{?dist}
 Summary:   Request tracker
 
 Group: Applications/Internet
@@ -141,8 +141,7 @@ BuildRequires: perl(Locale::Maketext::Fuzzy) >= 0.11
 BuildRequires: perl(Locale::Maketext::Lexicon) >= 0.32
 BuildRequires: perl(Locale::PO)
 BuildRequires: perl(Log::Dispatch) >= 2.23
-# Optional, N/A in Fedora. RHBZ#1312303
-# BuildRequires: perl(Net::LDAP::Server::Test)
+BuildRequires: perl(Net::LDAP::Server::Test)
 %{?with_devel_mode:BuildRequires: perl(Log::Dispatch::Perl)}
 BuildRequires: perl(LWP)
 BuildRequires: perl(LWP::UserAgent)
@@ -312,8 +311,7 @@ Requires:   perl(DBD::SQLite)
 Requires:  perl(GnuPG::Interface)
 # Bug: The testsuite unconditionally depends upon perl(GraphViz)
 Requires:  perl(GraphViz)
-# Optional, N/A in Fedora.
-# Requires:perl(Net::LDAP::Server::Test)
+Requires:  perl(Net::LDAP::Server::Test)
 Requires:  perl(Plack::Handler::Apache2)
 Requires:  perl(Set::Tiny)
 Requires:  perl(String::ShellQuote)
@@ -608,6 +606,9 @@ fi
 %endif
 
 %changelog
+* Tue Dec 20 2016 Ralf Corsépius  - 4.4.1-2
+- Add perl(Net::LDAP::Server::Test).
+
 * Thu Jul 28 2016 Ralf Corsépius  - 4.4.1-1
 - Update to rt-4.4.1.
 - Reflect upstream URLs having changed.
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/rt.git/commit/?h=master=d8f9ee67df7d88fab20d53925640559a60976e5b
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[Gerald B. Cox]

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
> > infrastructure for Kevin's suggestion
> > is in place now - KDE has been using it and it works.
>
> This has the same downside as a rolling release to end users. It asks
> them to take a big user interface / user experience update whenever we
> push it, or else disable all updates including security fixes and
> bugfixes that do not change user experience.
>
> Modularity, however, will allow us to update module stacks — like GNOME
> or KDE — while still also maintaining older versions for some time...
> without tying the whole release to that cycle.


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 possible.  If the GNOME
folks would like
their updates to age for six months, they can just keep them in
updates-testing.   Seems
like we're just making this more complicated than it is.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Pavel Raiskup]

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 cost of releasing a *botched* update. The advantage of
> batched updates is we reduce the risk of releasing botched updates. If we
> batch the updates together and release them all at once, possibly with new
> installation media, then that's something that we can QA, and that reduces the
> risk of a botched update.

Not always, unless we have https://fedorahosted.org/bodhi/ticket/663 fixed
first.  Packages which depend like:

A -> concrete_version_of(B) -> concrete_version_of(C)

.. are now updated in "batches".  People interested in 'C' give karma to 'C',
but also approve 'A' and 'B' (without paying attention to test those packages
independently).  But breaking 'A' or 'B' breaks stable release anyway.  So
batched update _increases_ the risk of a "botched" update.

Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Matthew Miller]

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.

This has the same downside as a rolling release to end users. It asks
them to take a big user interface / user experience update whenever we
push it, or else disable all updates including security fixes and
bugfixes that do not change user experience.

Modularity, however, will allow us to update module stacks — like GNOME
or KDE — while still also maintaining older versions for some time...
without tying the whole release to that cycle.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Brendan Conoboy]

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 of this is that you have to try and figure out
which bit of the batched update actually caused the bug you saw.


Or to be even more specific:

1. Batched update testing is more work.

2. Fixing bugs found in batched updates is more work.

Of the two I think we already end up doing #2, it's just a question of 
when.


--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Pavel Raiskup]

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 comes down to: "Upgrades are painful and scary." We have
> been working really hard on making upgrades fast and seamless, so we
> need to deliver that message to users (and of course work to make
> further improvements).

Indeed, I don't remember when I had troubles with N->N+1 major fedora
upgrade last time (though I always do distro-sync) on _my workstation_.

Upgrades on production servers (services built on top of Fedora) is
probably what scares users (with N->N+1 you can always expect a lot of
library API changes).  But maybe this is the thing which might be solved
by modularity;  one version of "module"  version to span multiple Fedora
major versions...

Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Gerald B. Cox]

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  wrote:

> However, I also do not see why we cannot just do such big updates through
> the regular update process rather than in a big .1 drop. The KDE SIG has
> experience with pushing big grouped updates that look a lot like a .1
> release for Plasma users. They go through the regular update process just
> fine. Grouping them together with updates to GNOME, LibreOffice etc. in one
> batch is not necessary and would only add unnecessary delays.
>
> I think pushing all updates in a big drop will actually make them LESS
> tested than if they just trickle through one at a time.
>

That is an excellent point.  KDE for some time has been pushing out large
updates
using the regular update process.  What is the issue with just doing this?
It certainly seems
much more straight forward and easier than ~.x updates.  Fedora version
releases could then be
reserved for structural / architectural concerns rather than software
updates and bug fixes.

Fedora stays fast moving and Fedora X releases come less often - seems like
a win / win.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Tom Hughes]

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 instance, since F25 came out,
218 people have filed 1,404 items of feedback on F25 updates in Bodhi.


I wonder how many have updates-testing enabled, and how many have just 
installed particular updates to test them...


I don't have updates-testing enabled, but I will test specific updates 
that relate to bugs I have filed by updating that package with 
"--enablerepo=updates-testing" and then file feedback,.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Michael Catanzaro]

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 sense to do a weekly batch. I was thinking
monthly.

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Adam Williamson]

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 filed 1,404 items of feedback on F25 updates in Bodhi.
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1295439

Fedora End Of Life  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |EOL
Last Closed||2016-12-20 12:36:09



--- Comment #3 from Fedora End Of Life  ---
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1295437

Fedora End Of Life  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |EOL
Last Closed||2016-12-20 12:36:02



--- Comment #4 from Fedora End Of Life  ---
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[bugzilla]

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|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |EOL



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[bugzilla]

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 |Added

 Status|NEW |CLOSED
 Resolution|--- |EOL



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[Adam Williamson]

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 out
which bit of the batched update actually caused the bug you saw.
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Adam Williamson]

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 get all test updates ASAP.
> 
> > 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 currently do zero QA
> on our updates because it's an unmanageable rolling stream of a
> bazillion separate updates.

This is an exaggeration. We do test updates. We could always test
everything *better*, and that applies to updates, but it is not true to
say we 'do zero QA' on them.

>  With batched updates, you can test a batch
> with the same overall criteria used for releases to see if it's
> botched. That's the advantage of batching over simply extending the
> amount of time spent in updates-testing.

This is also an exaggeration, or at least it's a long way from
proven. I don't think we could say that just batching updates would
suddenly allow us to QA them as extensively as we QA a release. Release
testing involves a lot of work by a lot of people; especially desktop
validation is rather onerous. 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.

We could in theory apply what automated functional testing we have to
batched updates, but it's not at all a simple thing to do, and we could
in fact apply it to *non*-batched updates too. It's something I've been
wanting to do for a while, just have not had time for yet.
-- 
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
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Chris Murphy]

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 batches instead.  we would push
>> daily security fixes and updates-testing.  However this would make atomic 
>> host
>> 2 week releases much less useful, as there would be no updates except for 
>> once
>> a month.
>
> 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
> not RHEL or Microsoft or Adobe. I'm convinced that having bug fixes
> available as soon as they're ready is valuable (even if you choose to
> wait before installing them). Also, as was pointed out elsewhere in this
> subthread, updates get tested only after they're released to stable very
> often, so it's also valuable to get the feedback earlier rather than in
> a month.


I keep hearing different opinions on update frequency, and it suggests
a discoverable dial is needed on the users' end of this equation.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Chris Murphy]

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 batches instead.  we would push
>> daily security fixes and updates-testing.  However this would make atomic 
>> host
>> 2 week releases much less useful, as there would be no updates except for 
>> once
>> a month.
>
> 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
> not RHEL or Microsoft or Adobe. I'm convinced that having bug fixes
> available as soon as they're ready is valuable (even if you choose to
> wait before installing them). Also, as was pointed out elsewhere in this
> subthread, updates get tested only after they're released to stable very
> often, so it's also valuable to get the feedback earlier rather than in
> a month.

Having bug fixes available sooner also means having regressions. It's
inevitable. And that's why there's updates-testing repo, and why it's
not enabled by default on release.

Why is user opt in to updates-testing insufficient?

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Tom Hughes]

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 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.



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 currently do zero QA
on our updates because it's an unmanageable rolling stream of a
bazillion separate updates. With batched updates, you can test a batch
with the same overall criteria used for releases to see if it's
botched. That's the advantage of batching over simply extending the
amount of time spent in updates-testing.


Well yes obviously if those batched updates get some formal QA then 
that's a different matter, but I didn't realise that was proposed.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Matthew Miller]

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 for rolling distro (while Rawhide is _almost_
> there).  It is sad we loose those users.

I have a two-pronged approach here.

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 comes down to: "Upgrades are painful and scary." We have
been working really hard on making upgrades fast and seamless, so we
need to deliver that message to users (and of course work to make
further improvements).

Second, yeah, for the enthusiasts and people who really _do_ want
the *bleeding* edge and do not mind all that entails, let's improve
Rawhide (and/or Bikeshed).

> > The proposals previously in this thread are ideas aimed at presenting
> > users with an annual release from a marketing/ambassadors/design, etc.,
> > point of view, but also addressing our upstream stakeholders' desire to
> > have Fedora ship their software fast. (For example, GNOME.)
> Would the 'rolling release' approach help WRT upstream stakeholders, even
> if we had longer major release cycle?

Maybe? I think the value in getting the upstream software into Fedora
is getting it to more mainstream users, and I think rolling-Fedora via
Rawhide/Bikeshed would still be niche.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Brendan Conoboy]

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 this in several ways across the thread, but I don't mind
restating. :)

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 marketing, ambassadors, design, docs, and others. One possible
   way to reduce this is to have major releases less frequently. I want
   a cadence that gives us the highest return on effort. Maybe that's
   six months — and maybe it isn't.

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 doesn't seem like it's the ideal for the above — maybe we can
   get the engineering processes streamlined enough to make it
   comfortable, but there's still the matter of marketing and the rest.

3. The modularity initiative will mean that different big chunks of
   what we use to compose the OS can update at different speeds and
   have different lifecycles. That gives us a lot more flexibility in
   the above, and I'd like us to start thinking about what we *want*
   to.


I'd like to clarify what people have in mind here because it's pretty 
fundamental to how to take the proposal.  More on my interpretation below.



I suggested one release a year as an alternative to the current two per
year. I guess three per year would be possible (but seems counter to
the above); other plans like eight- or nine-month cycles don't have the
fixed-calendar property I'm looking for (and I'm pretty sure no one
wants to go to one every two years).

The proposals previously in this thread are ideas aimed at presenting
users with an annual release from a marketing/ambassadors/design, etc.,
point of view, but also addressing our upstream stakeholders' desire to
have Fedora ship their software fast. (For example, GNOME.) I hoped we
could find ways to make them also reduce release effort for developers,
packagers, releng, and QA, but from the feedback so far people don't
really feel like those particular suggestions do.

Another  possibility would be to simply keep releases as normal but go
revist the "tick-tock" cadence we talked about a while ago: that is, a
May/June release aimed at features, and faster Oct/Nov release where we
concentrate on infrastructure — and then call that second release each
year the ".1".

And yet another possibility is that we keep things as they are. If
that's the overall consensus, okay. :)


You can't implement modularity *and* keep things as they are.  So 
here's how I take your proposal:


Once per year a new base Fedora release comes out.  It has a nice new 
stable glibc, gcc, etc.  This is the content that all editions and 
spins have in common.


Each edition or spin makes releases of their content layered on top of 
the above package stream, but they can inject packages that are unique 
to their edition.  So the desktop edition can still make multiple 
releases per year if they want, but they're layering on top of the 
basic annual Fedora release.


Is that what people have in mind, or something else?

--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Pavel Raiskup]

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 marketing, ambassadors, design, docs, and others. One possible
>way to reduce this is to have major releases less frequently. I want
>a cadence that gives us the highest return on effort. Maybe that's
>six months — and maybe it isn't.

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 for rolling distro (while Rawhide is _almost_
there).  It is sad we loose those users.

> I suggested one release a year as an alternative to the current two per
> year.

I don't have a strong opinion here ... but I personally like the idea
about annual "major release" cycle (supporting one stable fedora for 2Y+).

> The proposals previously in this thread are ideas aimed at presenting
> users with an annual release from a marketing/ambassadors/design, etc.,
> point of view, but also addressing our upstream stakeholders' desire to
> have Fedora ship their software fast. (For example, GNOME.)

Would the 'rolling release' approach help WRT upstream stakeholders, even
if we had longer major release cycle?

Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Brendan Conoboy]

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
batched updates is we reduce the risk of releasing botched updates. If
we batch the updates together and release them all at once, possibly
with new installation media, then that's something that we can QA, and
that reduces the risk of a botched update.


Surely it's more likely that it just delays the discovery of the
botched update?

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.

Which makes the question whether botched updates happen because not
enough people use testing, or because there are enough people using it
but they don't have enough time to spot the problems before the
updates get pushed.


Batched updates are valuable when testing happens with the whole.  It 
sorts out complex interactions between multiple package updates by 
testing them all together.  It's a thing that could be adopted whether 
or not Fedora moves to a once-a-year release and it could be done in 
addition to rolling updates.


--
Brendan Conoboy / RHEL Development Coordinator / Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Michael Catanzaro]

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 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 currently do zero QA
on our updates because it's an unmanageable rolling stream of a
bazillion separate updates. With batched updates, you can test a batch
with the same overall criteria used for releases to see if it's
botched. That's the advantage of batching over simply extending the
amount of time spent in updates-testing.

> Which makes the question whether botched updates happen because not 
> enough people use testing, or because there are enough people using
> it 
> but they don't have enough time to spot the problems before the
> updates 
> get pushed.

We indeed do not need batched updates to extend the length of time
updates remain in testing. We could (and should) do that immediately.

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[notifications]

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 
 perl-Storable.spec   | 10 +-
 2 files changed, 70 insertions(+), 1 deletion(-)
 create mode 100644 perl-5.25.7-Fix-Storable-segfaults.patch

diff --git a/perl-5.25.7-Fix-Storable-segfaults.patch 
b/perl-5.25.7-Fix-Storable-segfaults.patch
new file mode 100644
index 000..8934a13
--- /dev/null
+++ b/perl-5.25.7-Fix-Storable-segfaults.patch
@@ -0,0 +1,61 @@
+From fecd3be8dbdb747b9cbf4cbb9299ce40faabc8e6 Mon Sep 17 00:00:00 2001
+From: John Lightsey 
+Date: Mon, 14 Nov 2016 11:56:15 +0100
+Subject: [PATCH] Fix Storable segfaults.
+
+Fix a null pointed dereference segfault in storable when the
+retrieve_code logic was unable to read the string that contained
+the code.
+
+Also fix several locations where retrieve_other was called with a
+null context pointer. This also resulted in a null pointer
+dereference.
+---
+ dist/Storable/Storable.xs | 10 +++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/dist/Storable/Storable.xs b/dist/Storable/Storable.xs
+index 053951c..caa489c 100644
+--- a/dist/Storable/Storable.xs
 b/dist/Storable/Storable.xs
+@@ -5647,6 +5647,10 @@ static SV *retrieve_code(pTHX_ stcxt_t *cxt, const char 
*cname)
+   CROAK(("Unexpected type %d in retrieve_code\n", type));
+   }
+ 
++  if (!text) {
++  CROAK(("Unable to retrieve code\n"));
++  }
++
+   /*
+* prepend "sub " to the source
+*/
+@@ -5767,7 +5771,7 @@ static SV *old_retrieve_array(pTHX_ stcxt_t *cxt, const 
char *cname)
+   continue;   /* av_extend() already 
filled us with undef */
+   }
+   if (c != SX_ITEM)
+-  (void) retrieve_other(aTHX_ (stcxt_t *) 0, 0);  /* Will 
croak out */
++  (void) retrieve_other(aTHX_ cxt, 0);/* Will croak 
out */
+   TRACEME(("(#%d) item", i));
+   sv = retrieve(aTHX_ cxt, 0);
/* Retrieve item */
+   if (!sv)
+@@ -5844,7 +5848,7 @@ static SV *old_retrieve_hash(pTHX_ stcxt_t *cxt, const 
char *cname)
+   if (!sv)
+   return (SV *) 0;
+   } else
+-  (void) retrieve_other(aTHX_ (stcxt_t *) 0, 0);  /* Will 
croak out */
++  (void) retrieve_other(aTHX_ cxt, 0);/* Will croak 
out */
+ 
+   /*
+* Get key.
+@@ -5855,7 +5859,7 @@ static SV *old_retrieve_hash(pTHX_ stcxt_t *cxt, const 
char *cname)
+ 
+   GETMARK(c);
+   if (c != SX_KEY)
+-  (void) retrieve_other(aTHX_ (stcxt_t *) 0, 0);  /* Will 
croak out */
++  (void) retrieve_other(aTHX_ cxt, 0);/* Will croak 
out */
+   RLEN(size); /* Get 
key size */
+   KBUFCHK((STRLEN)size);  /* Grow 
hash key read pool if needed */
+   if (size)
+-- 
+2.10.2
+
diff --git a/perl-Storable.spec b/perl-Storable.spec
index e8bd48f..114efee 100644
--- a/perl-Storable.spec
+++ b/perl-Storable.spec
@@ -3,7 +3,7 @@
 Name:   perl-Storable
 Epoch:  1
 Version:2.53
-Release:348%{?dist}
+Release:349%{?dist}
 Summary:Persistence for Perl data structures
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -13,6 +13,9 @@ Source0:
http://www.cpan.org/authors/id/A/AM/AMS/Storable-%{base_version}
 Patch0: Storable-2.51-Upgrade-to-2.53.patch
 # Avoid loading optional modules from default . (CVE-2016-1238)
 Patch1: 
Storable-2.53-CVE-2016-1238-avoid-loading-optional-modules-from.patch
+# Fix crash in Storable when deserializing malformed code reference, RT#68348,
+# RT130098
+Patch2: perl-5.25.7-Fix-Storable-segfaults.patch
 BuildRequires:  perl
 BuildRequires:  perl(Config)
 BuildRequires:  perl(ExtUtils::MakeMaker)
@@ -64,6 +67,7 @@ can be conveniently stored to disk and retrieved at a later 
time.
 %setup -q -n Storable-%{base_version}
 %patch0 -p1
 %patch1 -p1
+%patch2 -p3
 # Remove bundled modules
 rm -rf t/compat
 sed -i -e '/^t\/compat\//d' MANIFEST
@@ -90,6 +94,10 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Dec 20 2016 Petr Pisar  - 1:2.53-349
+- Fix crash in Storable when deserializing malformed code reference
+  (RT#68348, RT#130098)
+
 * Wed Aug 03 2016 Jitka Plesnikova  - 1:2.53-348
 - Avoid loading optional modules from default . (CVE-2016-1238)
 
-- 
cgit v0.12

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

[notifications]

a04e811867ba1d5afa060ab9ea3e7408acb05ffeddcaa443a18dd3256654292cc746295490fd74a002cfb0fe57f1b0fa4c3b8a0331e7b543a456cc7524668f77
  Test2-Suite-0.65.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Test2-Suite/Test2-Suite-0.65.tar.gz/sha512/a04e811867ba1d5afa060ab9ea3e7408acb05ffeddcaa443a18dd3256654292cc746295490fd74a002cfb0fe57f1b0fa4c3b8a0331e7b543a456cc7524668f77/Test2-Suite-0.65.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[notifications]

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 --git a/perl-Storable.spec b/perl-Storable.spec
index 114efee..5f02e95 100644
--- a/perl-Storable.spec
+++ b/perl-Storable.spec
@@ -16,9 +16,13 @@ Patch1: 
Storable-2.53-CVE-2016-1238-avoid-loading-optional-modules-from.
 # Fix crash in Storable when deserializing malformed code reference, RT#68348,
 # RT130098
 Patch2: perl-5.25.7-Fix-Storable-segfaults.patch
+BuildRequires:  coreutils
+BuildRequires:  gcc
+BuildRequires:  make
 BuildRequires:  perl
 BuildRequires:  perl(Config)
 BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  sed
 # Run-time:
 # Carp substitutes missing Log::Agent
 BuildRequires:  perl(Carp)
@@ -80,8 +84,8 @@ make %{?_smp_mflags}
 
 %install
 make pure_install DESTDIR=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
+find $RPM_BUILD_ROOT -type f -name .packlist -delete
+find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -delete
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Storable.git/commit/?h=f24=d186884b5d6a726d37e3a85c91c56727aeb2fd9f
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[notifications]

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 
 perl-Storable.spec   | 10 +-
 2 files changed, 70 insertions(+), 1 deletion(-)
 create mode 100644 perl-5.25.7-Fix-Storable-segfaults.patch

diff --git a/perl-5.25.7-Fix-Storable-segfaults.patch 
b/perl-5.25.7-Fix-Storable-segfaults.patch
new file mode 100644
index 000..8934a13
--- /dev/null
+++ b/perl-5.25.7-Fix-Storable-segfaults.patch
@@ -0,0 +1,61 @@
+From fecd3be8dbdb747b9cbf4cbb9299ce40faabc8e6 Mon Sep 17 00:00:00 2001
+From: John Lightsey 
+Date: Mon, 14 Nov 2016 11:56:15 +0100
+Subject: [PATCH] Fix Storable segfaults.
+
+Fix a null pointed dereference segfault in storable when the
+retrieve_code logic was unable to read the string that contained
+the code.
+
+Also fix several locations where retrieve_other was called with a
+null context pointer. This also resulted in a null pointer
+dereference.
+---
+ dist/Storable/Storable.xs | 10 +++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/dist/Storable/Storable.xs b/dist/Storable/Storable.xs
+index 053951c..caa489c 100644
+--- a/dist/Storable/Storable.xs
 b/dist/Storable/Storable.xs
+@@ -5647,6 +5647,10 @@ static SV *retrieve_code(pTHX_ stcxt_t *cxt, const char 
*cname)
+   CROAK(("Unexpected type %d in retrieve_code\n", type));
+   }
+ 
++  if (!text) {
++  CROAK(("Unable to retrieve code\n"));
++  }
++
+   /*
+* prepend "sub " to the source
+*/
+@@ -5767,7 +5771,7 @@ static SV *old_retrieve_array(pTHX_ stcxt_t *cxt, const 
char *cname)
+   continue;   /* av_extend() already 
filled us with undef */
+   }
+   if (c != SX_ITEM)
+-  (void) retrieve_other(aTHX_ (stcxt_t *) 0, 0);  /* Will 
croak out */
++  (void) retrieve_other(aTHX_ cxt, 0);/* Will croak 
out */
+   TRACEME(("(#%d) item", i));
+   sv = retrieve(aTHX_ cxt, 0);
/* Retrieve item */
+   if (!sv)
+@@ -5844,7 +5848,7 @@ static SV *old_retrieve_hash(pTHX_ stcxt_t *cxt, const 
char *cname)
+   if (!sv)
+   return (SV *) 0;
+   } else
+-  (void) retrieve_other(aTHX_ (stcxt_t *) 0, 0);  /* Will 
croak out */
++  (void) retrieve_other(aTHX_ cxt, 0);/* Will croak 
out */
+ 
+   /*
+* Get key.
+@@ -5855,7 +5859,7 @@ static SV *old_retrieve_hash(pTHX_ stcxt_t *cxt, const 
char *cname)
+ 
+   GETMARK(c);
+   if (c != SX_KEY)
+-  (void) retrieve_other(aTHX_ (stcxt_t *) 0, 0);  /* Will 
croak out */
++  (void) retrieve_other(aTHX_ cxt, 0);/* Will croak 
out */
+   RLEN(size); /* Get 
key size */
+   KBUFCHK((STRLEN)size);  /* Grow 
hash key read pool if needed */
+   if (size)
+-- 
+2.10.2
+
diff --git a/perl-Storable.spec b/perl-Storable.spec
index c9de181..3574085 100644
--- a/perl-Storable.spec
+++ b/perl-Storable.spec
@@ -3,7 +3,7 @@
 Name:   perl-Storable
 Epoch:  1
 Version:2.56
-Release:366%{?dist}
+Release:367%{?dist}
 Summary:Persistence for Perl data structures
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -15,6 +15,9 @@ Patch0: Storable-2.51-Upgrade-to-2.53.patch
 Patch1: Storable-2.53-Upgrade-to-2.56.patch
 # Avoid loading optional modules from default . (CVE-2016-1238)
 Patch2: 
Storable-2.56-CVE-2016-1238-avoid-loading-optional-modules-from.patch
+# Fix crash in Storable when deserializing malformed code reference, RT#68348,
+# RT130098
+Patch3: perl-5.25.7-Fix-Storable-segfaults.patch
 BuildRequires:  perl
 BuildRequires:  perl-devel
 BuildRequires:  perl-generators
@@ -69,6 +72,7 @@ can be conveniently stored to disk and retrieved at a later 
time.
 %patch0 -p1
 %patch1 -p1
 %patch2 -p1
+%patch3 -p3
 # Remove bundled modules
 rm -rf t/compat
 sed -i -e '/^t\/compat\//d' MANIFEST
@@ -95,6 +99,10 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Dec 20 2016 Petr Pisar  - 1:2.56-367
+- Fix crash in Storable when deserializing malformed code reference
+  (RT#68348, RT#130098)
+
 * Wed Aug 03 2016 Jitka Plesnikova  - 1:2.56-366
 - Avoid loading optional modules from default . (CVE-2016-1238)
 
-- 
cgit v0.12

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

[notifications]

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 --git a/perl-Storable.spec b/perl-Storable.spec
index 3574085..72034b9 100644
--- a/perl-Storable.spec
+++ b/perl-Storable.spec
@@ -18,11 +18,15 @@ Patch2: 
Storable-2.56-CVE-2016-1238-avoid-loading-optional-modules-from.
 # Fix crash in Storable when deserializing malformed code reference, RT#68348,
 # RT130098
 Patch3: perl-5.25.7-Fix-Storable-segfaults.patch
+BuildRequires:  coreutils
+BuildRequires:  gcc
+BuildRequires:  make
 BuildRequires:  perl
 BuildRequires:  perl-devel
 BuildRequires:  perl-generators
 BuildRequires:  perl(Config)
 BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  sed
 # Run-time:
 # Carp substitutes missing Log::Agent
 BuildRequires:  perl(Carp)
@@ -85,8 +89,8 @@ make %{?_smp_mflags}
 
 %install
 make pure_install DESTDIR=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
+find $RPM_BUILD_ROOT -type f -name .packlist -delete
+find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -delete
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Storable.git/commit/?h=f25=e7c2f0067de8eb45edd0b66a23ff437238e06e50
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[notifications]

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 
 perl-Storable.spec   | 10 +-
 2 files changed, 70 insertions(+), 1 deletion(-)
 create mode 100644 perl-5.25.7-Fix-Storable-segfaults.patch

diff --git a/perl-5.25.7-Fix-Storable-segfaults.patch 
b/perl-5.25.7-Fix-Storable-segfaults.patch
new file mode 100644
index 000..8934a13
--- /dev/null
+++ b/perl-5.25.7-Fix-Storable-segfaults.patch
@@ -0,0 +1,61 @@
+From fecd3be8dbdb747b9cbf4cbb9299ce40faabc8e6 Mon Sep 17 00:00:00 2001
+From: John Lightsey 
+Date: Mon, 14 Nov 2016 11:56:15 +0100
+Subject: [PATCH] Fix Storable segfaults.
+
+Fix a null pointed dereference segfault in storable when the
+retrieve_code logic was unable to read the string that contained
+the code.
+
+Also fix several locations where retrieve_other was called with a
+null context pointer. This also resulted in a null pointer
+dereference.
+---
+ dist/Storable/Storable.xs | 10 +++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/dist/Storable/Storable.xs b/dist/Storable/Storable.xs
+index 053951c..caa489c 100644
+--- a/dist/Storable/Storable.xs
 b/dist/Storable/Storable.xs
+@@ -5647,6 +5647,10 @@ static SV *retrieve_code(pTHX_ stcxt_t *cxt, const char 
*cname)
+   CROAK(("Unexpected type %d in retrieve_code\n", type));
+   }
+ 
++  if (!text) {
++  CROAK(("Unable to retrieve code\n"));
++  }
++
+   /*
+* prepend "sub " to the source
+*/
+@@ -5767,7 +5771,7 @@ static SV *old_retrieve_array(pTHX_ stcxt_t *cxt, const 
char *cname)
+   continue;   /* av_extend() already 
filled us with undef */
+   }
+   if (c != SX_ITEM)
+-  (void) retrieve_other(aTHX_ (stcxt_t *) 0, 0);  /* Will 
croak out */
++  (void) retrieve_other(aTHX_ cxt, 0);/* Will croak 
out */
+   TRACEME(("(#%d) item", i));
+   sv = retrieve(aTHX_ cxt, 0);
/* Retrieve item */
+   if (!sv)
+@@ -5844,7 +5848,7 @@ static SV *old_retrieve_hash(pTHX_ stcxt_t *cxt, const 
char *cname)
+   if (!sv)
+   return (SV *) 0;
+   } else
+-  (void) retrieve_other(aTHX_ (stcxt_t *) 0, 0);  /* Will 
croak out */
++  (void) retrieve_other(aTHX_ cxt, 0);/* Will croak 
out */
+ 
+   /*
+* Get key.
+@@ -5855,7 +5859,7 @@ static SV *old_retrieve_hash(pTHX_ stcxt_t *cxt, const 
char *cname)
+ 
+   GETMARK(c);
+   if (c != SX_KEY)
+-  (void) retrieve_other(aTHX_ (stcxt_t *) 0, 0);  /* Will 
croak out */
++  (void) retrieve_other(aTHX_ cxt, 0);/* Will croak 
out */
+   RLEN(size); /* Get 
key size */
+   KBUFCHK((STRLEN)size);  /* Grow 
hash key read pool if needed */
+   if (size)
+-- 
+2.10.2
+
diff --git a/perl-Storable.spec b/perl-Storable.spec
index c9de181..3574085 100644
--- a/perl-Storable.spec
+++ b/perl-Storable.spec
@@ -3,7 +3,7 @@
 Name:   perl-Storable
 Epoch:  1
 Version:2.56
-Release:366%{?dist}
+Release:367%{?dist}
 Summary:Persistence for Perl data structures
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -15,6 +15,9 @@ Patch0: Storable-2.51-Upgrade-to-2.53.patch
 Patch1: Storable-2.53-Upgrade-to-2.56.patch
 # Avoid loading optional modules from default . (CVE-2016-1238)
 Patch2: 
Storable-2.56-CVE-2016-1238-avoid-loading-optional-modules-from.patch
+# Fix crash in Storable when deserializing malformed code reference, RT#68348,
+# RT130098
+Patch3: perl-5.25.7-Fix-Storable-segfaults.patch
 BuildRequires:  perl
 BuildRequires:  perl-devel
 BuildRequires:  perl-generators
@@ -69,6 +72,7 @@ can be conveniently stored to disk and retrieved at a later 
time.
 %patch0 -p1
 %patch1 -p1
 %patch2 -p1
+%patch3 -p3
 # Remove bundled modules
 rm -rf t/compat
 sed -i -e '/^t\/compat\//d' MANIFEST
@@ -95,6 +99,10 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Tue Dec 20 2016 Petr Pisar  - 1:2.56-367
+- Fix crash in Storable when deserializing malformed code reference
+  (RT#68348, RT#130098)
+
 * Wed Aug 03 2016 Jitka Plesnikova  - 1:2.56-366
 - Avoid loading optional modules from default . (CVE-2016-1238)
 
-- 
cgit v0.12

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

[notifications]

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 --git a/perl-Storable.spec b/perl-Storable.spec
index 3574085..72034b9 100644
--- a/perl-Storable.spec
+++ b/perl-Storable.spec
@@ -18,11 +18,15 @@ Patch2: 
Storable-2.56-CVE-2016-1238-avoid-loading-optional-modules-from.
 # Fix crash in Storable when deserializing malformed code reference, RT#68348,
 # RT130098
 Patch3: perl-5.25.7-Fix-Storable-segfaults.patch
+BuildRequires:  coreutils
+BuildRequires:  gcc
+BuildRequires:  make
 BuildRequires:  perl
 BuildRequires:  perl-devel
 BuildRequires:  perl-generators
 BuildRequires:  perl(Config)
 BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  sed
 # Run-time:
 # Carp substitutes missing Log::Agent
 BuildRequires:  perl(Carp)
@@ -85,8 +89,8 @@ make %{?_smp_mflags}
 
 %install
 make pure_install DESTDIR=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
+find $RPM_BUILD_ROOT -type f -name .packlist -delete
+find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -delete
 %{_fixperms} $RPM_BUILD_ROOT/*
 
 %check
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Storable.git/commit/?h=master=c4a917f963bd4b653c99c9e44c6822fb0fed97d7
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[Brian Exelbierd]

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 testers.
> 
> I've given this in several ways across the thread, but I don't mind
> restating. :)
> 
> 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 marketing, ambassadors, design, docs, and others. One possible
>way to reduce this is to have major releases less frequently. I want
>a cadence that gives us the highest return on effort. Maybe that's
>six months — and maybe it isn't.

If we prepare to do more "significant" updates during the release cycle
we are going to need to do some of this streamlining regardless.  It
sounds like this is worthy of exploring solely as a need to grow area.

> 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 doesn't seem like it's the ideal for the above — maybe we can
>get the engineering processes streamlined enough to make it
>comfortable, but there's still the matter of marketing and the rest.

We build Fedora for a lot of reasons, and I think this one is as
important as the others.  I believe that we will find an easier time
creating energy around our releases if they are more known in time.  I
am not sure they have to be once per year on a fixed calendar, but they
need to represent the culmination of work to introduce significant
features.  I actually would prefer to see a feature-gated release option
as opposed to only thinking in terms of time-gates.  I think having
something to say is more important than knowing when you're going to
speak.

> 3. The modularity initiative will mean that different big chunks of
>what we use to compose the OS can update at different speeds and
>have different lifecycles. That gives us a lot more flexibility in
>the above, and I'd like us to start thinking about what we *want*
>to.

Building on this, major module releases might be the feature-gate
trigger we need to do a new "release" while incremental improvement gets
pushed out as a .X release.

> I suggested one release a year as an alternative to the current two per
> year. I guess three per year would be possible (but seems counter to
> the above); other plans like eight- or nine-month cycles don't have the
> fixed-calendar property I'm looking for (and I'm pretty sure no one
> wants to go to one every two years).
> 
> The proposals previously in this thread are ideas aimed at presenting
> users with an annual release from a marketing/ambassadors/design, etc.,
> point of view, but also addressing our upstream stakeholders' desire to
> have Fedora ship their software fast. (For example, GNOME.) I hoped we
> could find ways to make them also reduce release effort for developers,
> packagers, releng, and QA, but from the feedback so far people don't
> really feel like those particular suggestions do.
> 
> Another  possibility would be to simply keep releases as normal but go
> revist the "tick-tock" cadence we talked about a while ago: that is, a
> May/June release aimed at features, and faster Oct/Nov release where we
> concentrate on infrastructure — and then call that second release each
> year the ".1".

Tick-tock makes me worried that people will begin to assume the Tick
isn't worthwhile and they should wait on Tock.

> And yet another possibility is that we keep things as they are. If
> that's the overall consensus, okay. :)

Now you're talking crazy :P j/k!

regards,

bex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Dave Johansen]

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: 
Date: Tue, Dec 20, 2016 at 9:20 AM
Subject: churchyard's python-breathe-4.2.0-5.fc26 failed to build
To: davejohan...@gmail.com


Package:python-breathe-4.2.0-5.fc26
Status: failed
Built by:   churchyard
ID: 827042
Started:Tue, 20 Dec 2016 16:06:40 UTC
Finished:   Tue, 20 Dec 2016 16:08:10 UTC

Closed tasks:
-
Task 16999383 on buildhw-06.phx2.fedoraproject.org
Task Type: build (noarch)
Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=16999383

error building package (arch noarch), mock exited with status 1; see
build.log for more information

Task 16999405 on buildvm-23.phx2.fedoraproject.org
Task Type: buildSRPMFromSCM (noarch)
Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=16999405
logs:
  https://kojipkgs.fedoraproject.org/work/tasks/9405/16999405/state.log
  https://kojipkgs.fedoraproject.org/work/tasks/9405/16999405/root.log
  https://kojipkgs.fedoraproject.org/work/tasks/9405/16999405/build.log
srpm:
  https://kojipkgs.fedoraproject.org/work/tasks/
9405/16999405/python-breathe-4.2.0-5.fc26.src.rpm

Task 16999816 on buildhw-04.phx2.fedoraproject.org
Task Type: buildArch (noarch)
Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=16999816

error building package (arch noarch), mock exited with status 1; see
build.log for more information

http://koji.fedoraproject.org/koji/buildinfo?buildID=827042

--
You received this message due to your preference settings at
https://apps.fedoraproject.org/notifications/daveisfera.
id.fedoraproject.org/email/27208
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Creating cores in f25

[Steve Dickson]

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 change the default RLIMIT_CORE (ulimit -c) 
> from "0" to unlimited, therefore ABRT must stop creating the core dump files 
> in CWD. 
> Otherwise, you will get core dumps spread all over your file system - 
> that is because of crashes of daemon that used to not crash with core 
> dump file (their RLIMIT_CORE were 0 by default; starting with systemd-229 
> the default RLIMIT_CORE is unlimited).
I guess I really don't care where the core dump is created... 
I just need one to be created!! ;-) 

steved.

> 
> 
> Regards,
> Jakub
> 
> -- Původní zpráva --
> Od: Steve Dickson 
> Komu: Development discussions related to Fedora 
> 
> Datum: 18. 12. 2016 17:35:43
> Předmět: Creating cores in f25
> 
> 
> Hello,
> 
> How do I get f25 to create cores, these days?
> 
> I'm getting the segfault
> [55108.290610] rpc.gssd[13264]: segfault at 0 ip 55dc90af9dde sp 
> 7f9fb73cb7c0 error 4 in rpc.gssd[55dc90af3000+14000]
> 
> but no core so those address are meaningless.
> 
> Everything in the kernel is set:
> f25# sysctl -a | grep kernel.core
> kernel.core_pattern = |/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t %P %I
> kernel.core_pipe_limit = 4
> kernel.core_uses_pid = 1
> 
> The abrtd daemon is up and running
> f25# ps ax | grep abrtd
> 713 ? Ssl 0:00 /usr/sbin/abrtd -d -s
> 
> What am I missing?
> 
> tia,
> 
> steved.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Matthew Miller]

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 I don't mind
restating. :)

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 marketing, ambassadors, design, docs, and others. One possible
   way to reduce this is to have major releases less frequently. I want
   a cadence that gives us the highest return on effort. Maybe that's
   six months — and maybe it isn't.

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 doesn't seem like it's the ideal for the above — maybe we can
   get the engineering processes streamlined enough to make it
   comfortable, but there's still the matter of marketing and the rest.

3. The modularity initiative will mean that different big chunks of
   what we use to compose the OS can update at different speeds and
   have different lifecycles. That gives us a lot more flexibility in
   the above, and I'd like us to start thinking about what we *want*
   to.

I suggested one release a year as an alternative to the current two per
year. I guess three per year would be possible (but seems counter to
the above); other plans like eight- or nine-month cycles don't have the
fixed-calendar property I'm looking for (and I'm pretty sure no one
wants to go to one every two years).

The proposals previously in this thread are ideas aimed at presenting
users with an annual release from a marketing/ambassadors/design, etc.,
point of view, but also addressing our upstream stakeholders' desire to
have Fedora ship their software fast. (For example, GNOME.) I hoped we
could find ways to make them also reduce release effort for developers,
packagers, releng, and QA, but from the feedback so far people don't
really feel like those particular suggestions do.

Another  possibility would be to simply keep releases as normal but go
revist the "tick-tock" cadence we talked about a while ago: that is, a
May/June release aimed at features, and faster Oct/Nov release where we
concentrate on infrastructure — and then call that second release each
year the ".1".

And yet another possibility is that we keep things as they are. If
that's the overall consensus, okay. :)


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Creating cores in f25

[Steve Dickson]

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
> 
> $ rpm -qf /usr/lib/sysctl.d/50-coredump.conf
> systemd-231-10.fc25.x86_64
Unfortunately this did not work... :-( Thanks though... 

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Pavel Raiskup]

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. Both of these are not taking modularity into account in
> any way; it's "how we could do this with our current distro-building
> process".
> 
> Option 1: Big batched update
> 
>   1. Release F26 according to schedule
>  https://fedoraproject.org/wiki/Releases/26/Schedule
> 
>   2. At the beginning of October, stop pushing non-security updates
>  from updates-testing to updates
> 
>   3. Bigger updates (desktop environment refreshes, etc.) allowed into
>  updates-testing at this time.
> 
>   4. Mid-October, freeze exceptions for getting into updates-testing
>  even.
> 
>   5. Test all of that together in Some Handwavy Way for serious
>  problems and regressions.
> 
>   6. Once all good, push from updates-testing to updates at end of
>  October or beginning of November.
> [..]

I'm lost.  I'm against prolonging delays before pushes from
updates-testing to updates if there's given karma, even for non-security
stuff.  If that's not enough, we should shape the karma-process.

> Option 2: Branching!
> [..]

Sounds really complicated to me.  What's the purpose?

--

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.

Have you considered the recent "bodhi for rawhide" proposal, too?

Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Making use of the new Fedora Container capabilities

[Matthew Miller]

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 dist-git docker namespace, rather
> than rpm?

Ooh. That's probably an oversight. The intention is for these to be in
the new namespace.


> Where there is no existing lower layer that would be useful (eg
> httpd+mod_php+mod_ssl) is it permitted to have a container that
> installs httpd, mod_php and mod_ssl for a PHP based application?

We're still working this out. For now, I think it's a judgement call,
and we can figure out how we want to standardize from there. If
something seems really basic and doesn't exist yet (like httpd +
mod_ssl), it's probably good to work on creating that as an underlying
layer, since it'll be so useful to so many other things.


> What is considered acceptable for volumes specified in the dockerfile?
> 
> Anywhere data or config is expected?
> 
> How should we provide instructions on how to run the container?
> 
> Just a readme.md in dist-git? Actually include something in the container?

These are all great questions. :)

> Is an entrypoint of ["/sbin/init"] permitted to make use of systemd
> for handling zombies and service unit files?
> 
> This of course would then limit the container to docker hosts that
> have oci-systemd-hook to work properly if so, but massively simplifies
> things for services.

I think it _should_ be permitted, but we need metadata and naming
standards to make it clear.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Koji builders' specs

[Pavel Raiskup]

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 reproduce hang in gnulib's test-lock [1] test case.
Unless I'm able to reproduce that somehow, I'll disable the test for the time
being (done in 'coreutils' and I guess elsewhere, too).

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=16970779

Thanks,
Pavel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Tom Hughes]

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 releasing botched updates. If
we batch the updates together and release them all at once, possibly
with new installation media, then that's something that we can QA, and
that reduces the risk of a botched update.


Surely it's more likely that it just delays the discovery of the botched 
update?


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.


Which makes the question whether botched updates happen because not 
enough people use testing, or because there are enough people using it 
but they don't have enough time to spot the problems before the updates 
get pushed.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Michael Catanzaro]

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
> not RHEL or Microsoft or Adobe. I'm convinced that having bug fixes
> available as soon as they're ready is valuable (even if you choose to
> wait before installing them). Also, as was pointed out elsewhere in
> this
> subthread, updates get tested only after they're released to stable
> very
> often, so it's also valuable to get the feedback earlier rather than
> in
> a month.

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 releasing botched updates. If
we batch the updates together and release them all at once, possibly
with new installation media, then that's something that we can QA, and
that reduces the risk of a botched update.

Last year we released several botched hawkey/hif updates (I lost count,
but I think it was three total?) that broke PackageKit updates, so
nontechnical users who don't know command line foo to recover their
systems got stuck forever, never to receive an update again. Ideally
that would never happen. Delaying updates by a couple of weeks seems
like a small price to reduce this risk.

Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[bugzilla]

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

 Status|ASSIGNED|CLOSED
 Resolution|--- |EOL



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1231244

Fedora End Of Life  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |EOL
Last Closed||2016-12-20 08:46:08



--- Comment #4 from Fedora End Of Life  ---
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1406382

Petr Pisar  changed:

   What|Removed |Added

 Depends On||1406428




Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1406428
[Bug 1406428] Review Request: perl-Term-Table - Format a header and rows
into a table
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1224727

Fedora End Of Life  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |EOL
Last Closed||2016-12-20 08:42:37



--- Comment #4 from Fedora End Of Life  ---
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1206053

Fedora End Of Life  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |EOL
Last Closed||2016-12-20 08:25:21



--- Comment #3 from Fedora End Of Life  ---
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1204870

Fedora End Of Life  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |EOL
Last Closed||2016-12-20 08:23:53



--- Comment #4 from Fedora End Of Life  ---
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[Igor Gnatenko]

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

[bugzilla]

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 list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[bugzilla]

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]
https://bugzilla.redhat.com/show_bug.cgi?id=1166800

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |EOL



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[bugzilla]

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]
https://bugzilla.redhat.com/show_bug.cgi?id=1166800

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |EOL



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[bugzilla]

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|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |EOL



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Making use of the new Fedora Container capabilities

[James Hogarth]

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 the dist-git docker namespace, rather
than rpm?

Where there is no existing lower layer that would be useful (eg
httpd+mod_php+mod_ssl) is it permitted to have a container that
installs httpd, mod_php and mod_ssl for a PHP based application?

What is considered acceptable for volumes specified in the dockerfile?

Anywhere data or config is expected?

How should we provide instructions on how to run the container?

Just a readme.md in dist-git? Actually include something in the container?

Is an entrypoint of ["/sbin/init"] permitted to make use of systemd
for handling zombies and service unit files?

This of course would then limit the container to docker hosts that
have oci-systemd-hook to work properly if so, but massively simplifies
things for services.

As a real world example I'd like to get out there I'm testing out a
container in the Fedora build infrastructure for owncloud.

Here's what I was playing with last night:

http://pkgs.fedoraproject.org/cgit/rpms/owncloud.git/tree/Dockerfile

Here's the task from koji:

https://koji.fedoraproject.org/koji/taskinfo?taskID=16992119

Does the --scratch option actually do anything, as it doesn't seem
reflected in that build?

That particular build can be tested and run by:

docker run -d -P
candidate-registry.fedoraproject.org/f25/owncloud:rawhide-docker-candidate-20161220120656
on any docker host that has the systemd oci hook.

It would be very useful to be able to provide some sort of upfront
readme/document that lists volumes used to persistence etc to aid
updates in future mapping to the same (named?) volume.

I think we need some of this detail added to the container build
guidelines for review reasons.

James
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[bugzilla]

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|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |EOL



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[bugzilla]

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

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |EOL



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[bugzilla]

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

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |EOL



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: cross-compiler support?

[Gerd Hoffmann]

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: cannot find crt1.o: No such file or directory
> > /usr/bin/arm-linux-gnu-ld: cannot find crti.o: No such file or directory
> > /usr/bin/arm-linux-gnu-ld: cannot find -lc
> > /usr/bin/arm-linux-gnu-ld: cannot find crtn.o: No such file or directory
> 
> Yeah - it's intended for building kernels (though it can build anything that
> provides its own userspace).

FYI: they also work great for building qemu firmware.

cheers,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Till Hofmann]

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 error:
>>>
>>> Error: Transaction check error:
>>>   file /usr/share/symlinktest/dir/subdir from install of
>>> symlinktest-1-2.fc25.x86_64 conflicts with file from package
>>> symlinktest-1-1.fc25.x86_64
>>
>>
>> Replacing a directory needs special lua scriptlet hackery:
>>
>> https://fedoraproject.org/wiki/Packaging:Directory_Replacement
>>
> 
> I'm not completely sure about this, but I think using Obsoletes in the
> successive version is supposed make RPM handle "internal" file
> conflicts properly, too.
> 
> 

I tested this by adding: Obsoletes: symlinktest < 1-2
But I still get the same error, so I guess that doesn't work and the
scriptlet is really needed.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org