date:20180604

On Mon, Jun 04, 2018 at 10:07:55PM -0400, Matthew Miller wrote:
> But, my gut feeling is that about half of those are not using a current
> release _anyway_. Honest question: do you think that 12k would still
> count as a healthy number? I mean, it's not peanuts. But maybe it'd be

Ooh, I should read whole threads before replying. (Thanks, Smooge!)
Looks like it's more like 4k than 12k.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZH46J4PP2NRWQCA47N3D4YCYUQ4YKUAT/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 04, 2018 at 03:50:34PM -0400, Jeff Backus wrote:
> Thanks for the data. 25k is still a pretty healthy number. :) I realize

Yeah, absolutely. And it's likely that those mirror numbers undercount,
because not every system checks in daily, and then there's also NAT.

But, my gut feeling is that about half of those are not using a current
release _anyway_. Honest question: do you think that 12k would still
count as a healthy number? I mean, it's not peanuts. But maybe it'd be
better served by a Fedora remix (or similar) specifically targetting
older and low-powered systems?

> that there are a lot of unknowns in the data, so it is difficult to draw
> any hard conclusions, but 25k is still much larger than 0. Splitting into
> i686 into i586 and i686 would give more insight into who still needs
> non-SSE2... Probably hurts my argument, though. :)

Soo this is the kind of thing that more a detailed hardware
census could really help us with!

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TDDINBL32E2UCMD2QDVLGDFZOODH55YD/

Re: Release criteria proposal: drop kickstart package criterion

2018-06-04 Thread Peter Robinson

On Tue, Jun 5, 2018 at 12:39 AM, Adam Williamson
 wrote:
> Hi, folks!
>
> We currently have a Final release criterion that reads as follows:
>
> "A spin-kickstarts package which contains the exact kickstart files
> used to build the release must be present in the release repository.
> The included kickstarts must define the correct set of release
> repositories.
>
> Why?
>
> This is considered part of Fedora's duty to be 'self-hosting': the
> kickstarts used to produce the release images are a vital piece of
> information required to duplicate that release, so they must be
> preserved along with the release."
>
> Lately this requirement has been fairly annoying in practice. Updating
> the package prior to release does not appear to be in anyone's regular
> schedule, so invariably what happens is shortly before the release
> deadline I realize we haven't built a 'release' spin-kickstarts package
> and have to file a blocker bug and ping people with the necessary
> permissions (of which there are only a few) to build one in a tearing
> hurry. Then we have to approve the blocker bug and push the updated
> package through the freeze, all wasting time we could be spending on
> more important fixes.
>
> The benefit here is really fairly tiny, as well. It's arguable whether
> anyone cares particularly whether a Fedora release, as a frozen
> artifact, is 100% internally reproducible (and I'm not sure whether our
> releases actually *are* reproducible in any case, these days, I'm not
> at all sure we ship all the necessary metadata and so on for *every
> single deliverable* within the distribution).
>
> These days I'd suggest it should be quite acceptable to simply use git
> tags for this purpose. It should be quite easy for rel-eng to adjust
> the release scripts to create a tag in the fedora-kickstarts repo (and
> why not fedora-comps too, while we're at it) for each 'candidate'
> compose, named for the compose ID. That would make it very easy to
> access the correct kickstarts for any Fedora candidate compose just by
> a 'git checkout', with no need for the cumbersome work of getting the
> package into the compose.
>
> Naturally this would go along with updates to any relevant docs or wiki
> pages, recommending to use the git repository instead of the RPM
> packages, and explaining the tagging scheme. As for the package, we
> could either keep it but not sweat about updating it for each release,
> retire it entirely, or change it to contain only a text file pointing
> to the git repository (or to the doc / wiki page that explains the git
> repo location and tagging strategy).
>
> Thoughts? Thanks!

It makes perfect sense, the package is not actually shipped as part of
any of the actual deliverable artifacts and they're widely available
in a public git repository for people to consume so it's not reducing
the ability to reproduce Fedora, we don't rush around and ensure all
the tools that might need last minute patches in the compose process
are all tagged stable in the release either so I don't see actually
shipping this package as stable makes any difference in reality, we
don't even use the package in the compose process, we pull the
kickstarts directly from git.

Peter
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Z5IKRMU2AKGMCF3FB2WNWVM6ZD2EYTYK/

[Bug 1585854] New: perl-Locale-TextDomain-OO-Util-4.001 is available

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

Bug ID: 1585854
   Summary: perl-Locale-TextDomain-OO-Util-4.001 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Locale-TextDomain-OO-Util
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 4.001
Current version/release in rawhide: 3.008-3.fc28
URL: http://search.cpan.org/dist/Locale-TextDomain-OO-Util/

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/15617/

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/3NB3TNN2LTG4SLPHTBPP6ISPELXL6HNW/

[Bug 1585853] New: perl-FFI-CheckLib-0.20 is available

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

Bug ID: 1585853
   Summary: perl-FFI-CheckLib-0.20 is available
   Product: Fedora
   Version: rawhide
 Component: perl-FFI-CheckLib
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.20
Current version/release in rawhide: 0.19-1.fc29
URL: http://search.cpan.org/dist/FFI-CheckLib/

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/13614/

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/VQUIK2J3YWCSJZEYFFNOQVRQJKOEO7LV/

[Bug 1585850] New: perl-Devel-NYTProf-6.06 is available

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

Bug ID: 1585850
   Summary: perl-Devel-NYTProf-6.06 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Devel-NYTProf
  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: 6.06
Current version/release in rawhide: 6.05-1.fc29
URL: http://search.cpan.org/dist/Devel-NYTProf/

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/5897/

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/JLGPEZU6NLXVSXSPLP6DFTXTWW6C3PQM/

Release criteria proposal: drop kickstart package criterion

2018-06-04 Thread Adam Williamson

Hi, folks!

We currently have a Final release criterion that reads as follows:

"A spin-kickstarts package which contains the exact kickstart files
used to build the release must be present in the release repository.
The included kickstarts must define the correct set of release
repositories.

Why?

This is considered part of Fedora's duty to be 'self-hosting': the
kickstarts used to produce the release images are a vital piece of
information required to duplicate that release, so they must be
preserved along with the release."

Lately this requirement has been fairly annoying in practice. Updating
the package prior to release does not appear to be in anyone's regular
schedule, so invariably what happens is shortly before the release
deadline I realize we haven't built a 'release' spin-kickstarts package
and have to file a blocker bug and ping people with the necessary
permissions (of which there are only a few) to build one in a tearing
hurry. Then we have to approve the blocker bug and push the updated
package through the freeze, all wasting time we could be spending on
more important fixes.

The benefit here is really fairly tiny, as well. It's arguable whether
anyone cares particularly whether a Fedora release, as a frozen
artifact, is 100% internally reproducible (and I'm not sure whether our
releases actually *are* reproducible in any case, these days, I'm not
at all sure we ship all the necessary metadata and so on for *every
single deliverable* within the distribution).

These days I'd suggest it should be quite acceptable to simply use git
tags for this purpose. It should be quite easy for rel-eng to adjust
the release scripts to create a tag in the fedora-kickstarts repo (and
why not fedora-comps too, while we're at it) for each 'candidate'
compose, named for the compose ID. That would make it very easy to
access the correct kickstarts for any Fedora candidate compose just by
a 'git checkout', with no need for the cumbersome work of getting the
package into the compose.

Naturally this would go along with updates to any relevant docs or wiki
pages, recommending to use the git repository instead of the RPM
packages, and explaining the tagging scheme. As for the package, we
could either keep it but not sweat about updating it for each release,
retire it entirely, or change it to contain only a text file pointing
to the git repository (or to the doc / wiki page that explains the git
repo location and tagging strategy).

Thoughts? Thanks!
-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/X4YKEUQYAKLRGEPDJOOIMZNJZMM23CMU/

Re: equivalent of Debian config-package?

2018-06-04 Thread devzero2000

Il gio 31 mag 2018, 13:42 Neal Gompa  ha scritto:

> On Thu, May 31, 2018 at 6:54 AM Dave Love 
> wrote:
> >
> > Is there any existing system for rpm like the Debian one
> >  for building local
> > configuration packages?  If not, would it be feasible to implement one?
>
> No such thing currently exists, because an equivalent to `dpkg-divert`
> does not exist in RPM.
>
> It is technically possible to implement such a mechanism, but it does
> not exist right now.
>
> A toy WIP never completed is here :
>

https://github.com/yersinia/rpm-gen-rpm-configuration

>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BMDUJ3ANQG6OJRWBWOOFU72OJ56WVF2G/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZJVWOABDP3WIZUECMRFVNMBJ7PX5PLUL/

[Fedocal] Reminder meeting : Modularity Office Hours

2018-06-04 Thread nils

Dear all,

You are kindly invited to the meeting:
   Modularity Office Hours on 2018-06-05 from 10:00:00 to 11:00:00 US/Eastern
   At fedora-modular...@chat.freenode.net

The meeting will be about:
This is where you ask the Fedora Modularity Team questions (and we try to 
answer them)!

Join us on [IRC](irc://chat.freenode.net/#fedora-modularity): 
#fedora-modularity on [FreeNode](https://freenode.net)


Source: https://apps.fedoraproject.org/calendar/meeting/5910/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NCRNMB7WVE7ZNKXE2G34PPLM4OQEUKVN/

Re: [X86] Re: Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Justin Forbes

On Mon, Jun 4, 2018 at 3:08 PM, Jeff Backus  wrote:
>
>
> On Mon, Jun 4, 2018 at 3:53 PM, Stephen John Smoogen 
> wrote:
>>
>> On 4 June 2018 at 14:18, Matthew Miller  wrote:
>> > On Mon, Jun 04, 2018 at 02:01:13PM -0400, Matthew Miller wrote:
>> >> > >>support long NOPs, for Intel CET.  However, the majority of
>> >> > >>installations of i686 packages is for use on x86_64 systems, as
>> >> > >>multi-lib RPMs.
>> >> > >Based on what data?
>> >> > The mirror data I've seen, but it's really outdated at this point.
>> >> There are currently about 275,000 IP address checking in with x86_64
>> >> systems every day. and 25,000 x86_32. So it's about 11:1.
>> >
>> > Here's a breakdown as arch percentage over time:
>> >
>> > https://twitter.com/mattdm/status/1003701941724172295
>> >
>> > Looks like the 50:50 point was about five years ago.
>> >
>>
>> For F26,F27,F28 for the first 150 days of the year:
>>
>> Days:  150
>> X86_32: 3769.4 avg/day
>> X86_64: 159540 avg/day
>> Ratio (32/64) 0.0236267 (1:42)
>>
>> The reason is that the majority of i386 users are not moving off of
>> dead/old releases. For the month of May
>>
>> Avg/day release
>> 28623.7 epel6
>> 16009.2 epel5
>> 4043.37 f25
>> 3318.53 f20
>> 2759.2 f08
>> 2127.8 f23
>> 1589.63 f27
>> 1401.7 f22
>> 1371 f26
>> 1277.53 f21
>> 1056.33 f28
>> 874.2 f24
>> 733.8 f14
>> 562.533 f19
>> 509.067 f11
>>
>> In comparison, x86_64 is mostly living on the latest release:
>> [smooge@data-analysis01 mirrors]$ grep '^2018-05-.* x86_64' out-2018
>> | awk '{print $3}' | sort | uniq -c | sort -bnr | head -n 15 | awk
>> '{print $1/30, $2}'
>> 671455 epel7
>> 605436 epel6
>> 87367.4 f27
>> 60159.7 f28
>> 37857.6 epel5
>> 34421.4 f26
>> 27011 f25
>> 19115.4 f23
>> 14292.2 f24
>> 8627.47 f22
>> 6603.3 f20
>> 5863.47 f21
>> 1413.37 modular_f28
>> 1091.87 f19
>> 868.833 f18
>>
>> The 30 is because only 30 days of May have been analyzed. [And yes
>> there are still many Fedora 08 systems showing up for x86_32]
>>
>> Personally I think the number of those systems which are running
>> Pentium III hardware with the latest OS are probably already on this
>> mailing list.. I expect that they would also be looking at only
>> needing to support a small subset of the software since running
>> GNOME/KDE with usually 128->512 MB of RAM is not possible. It also
>> would probably want a very stripped down installer since anaconda is
>> aimed at 'current' hardware... probably something like the images that
>> ARM-32 makes.
>
>
> Very good point!
>
> And wow! Fedora 08 was quite some time ago... :)


It was, and it was used as a long time as a base image for VMs
somewhere, which is probably where a lot of those numbers are coming
from. It would be really interesting if we could see a breakdown of VM
vs raw metal, as I am guessing a whole lot of the i686 is VM traffic.
I know I have at least 4 of those VMs per release checking in just for
kernel testing bits.  For a long time there was also a trend of people
running 32bit guests wherever they could to reduce memory footprint.

>
> --
> Jeff Backus
> jeff.bac...@gmail.com
> http://github.com/jsbackus
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DZW44V5B32MCO7AKTBSMT3HMTKRQRKTF/
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AZA7QEFYYV5X4PJNR3JPQIRAEOBZYHXU/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 4:41 PM, Rex Dieter  wrote:

> Jeff Backus wrote:
>
> > On Mon, Jun 4, 2018 at 1:45 PM, Rex Dieter  wrote:
> >
> >> Jeff Backus wrote:
> >>
> >>
> >> > Until (unless?) we have data indicating that this is a major drain on
> >> > community resources, I'd push back on a change that actively excludes
> >> part
> >> > of the community. Now, if we do have data indicating that supporting
> >> > non-SSE2 systems with the i686 architecture is a not-insignificant
> >> > burden on the community, then I ask that this proposal be updated to
> >> > include a solution that allows us to not push out part of the
> >> > community, e.g.
> >> Ajax's
> >> > i586 suggestion.
> >>
> >> Fwiw, Qt5 officially doesn't support non-sse2 systems either.  kde-sig
> >> has had to carry patches/hacks to make it work (or at least be
> >> buildable), but I'd love to be able to not have to do that anymore.
> >>
> >>
> > Hmm.. Yes, we've had discussions within the SIG re: window managers that
> > support i586/i686, and KDE was on the list of WMs that no longer support
> > our target system. Do these patches/hacks only apply to KDE or do they
> > apply to Qt in general?
>
> I'm speaking about Qt5 here
>
>
I was afraid of that. I would like to express my heartfelt gratitude to you
and the rest of the KDE-SIG for all of the effort you folks make. :)

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YSZSH3Y4TOKKED3Z5R4HOFM6VOBCC2VV/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Rex Dieter

Jeff Backus wrote:

> On Mon, Jun 4, 2018 at 1:45 PM, Rex Dieter  wrote:
> 
>> Jeff Backus wrote:
>>
>>
>> > Until (unless?) we have data indicating that this is a major drain on
>> > community resources, I'd push back on a change that actively excludes
>> part
>> > of the community. Now, if we do have data indicating that supporting
>> > non-SSE2 systems with the i686 architecture is a not-insignificant
>> > burden on the community, then I ask that this proposal be updated to
>> > include a solution that allows us to not push out part of the
>> > community, e.g.
>> Ajax's
>> > i586 suggestion.
>>
>> Fwiw, Qt5 officially doesn't support non-sse2 systems either.  kde-sig
>> has had to carry patches/hacks to make it work (or at least be
>> buildable), but I'd love to be able to not have to do that anymore.
>>
>>
> Hmm.. Yes, we've had discussions within the SIG re: window managers that
> support i586/i686, and KDE was on the list of WMs that no longer support
> our target system. Do these patches/hacks only apply to KDE or do they
> apply to Qt in general?

I'm speaking about Qt5 here

-- Rex

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3MCCFNKJR624URBSLXWESH5S4J35VEDK/

Re: equivalent of Debian config-package?

2018-06-04 Thread Stephen John Smoogen

On 4 June 2018 at 14:29, Dave Love  wrote:
> You wrote:
>
>> I think generally the Fedora/RH-ecosystem answer is to use Ansible for
>> configuration, rather than configuration packages.
>>
>> That's not sayin' there can't be another answer, but in general that's
>> the route *I'd* take to solve this problem on my systems.
>
> I guess we disagree about what the problem is, but it's unfortunate if
> Fedora/RH isn't interested in the sort of environment for which
> config-package was developed.

1. Do not strip out who you are replying to. There are hundreds of
people on this list and people come in at different times... and I am
not sure who "You" was.
2. Saying that Fedora/RH isn't interested by 1-2 comments is like me
walking into Debian lists getting 1 person saying "noone would ever
use Ansible" and assuming they speak for all of Debian.
3. There are people who do system management by rpm as can be seen by
various emails. Even Red Hat does so for the deployment of in the
field laptops who aren't getting regular checkins for a puppet or
ansible to work on.
4. System administration/configuration management is 99% "I have a
solution I endure and I don't have time to re-engineer it." and 1% "Oh
I think I want to write my own configuration management toolkit
because I can't endure what I am doing now." You are going to get
pushback from any site you are proposing this to until you show it is
useful for them.

So let us roll this discussion back a bit. There isn't an existing
system to do this. Most sites I have worked with roll their own using
different amounts of cron, config files, scripts in /usr/local/sbin
and rpms with %post/%pre and lots of %triggers. The ones who do this
would probably enjoy a tool which automated most of this work for
them, but they are all expecting someone else to write it for them.
And then because these solutions (even the Debian one) can go wrong
badly.. they are hesitant to use some other one until they see it
works.

-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B26CFSANPZKFFMS7IU6W7OWMNYAKA2K6/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 4:00 PM, Michael Cronenworth  wrote:

> On 06/04/2018 02:50 PM, Jeff Backus wrote:
>
>> Thanks for the data. 25k is still a pretty healthy number. :) I realize
>> that there are a lot of unknowns in the data, so it is difficult to draw
>> any hard conclusions, but 25k is still much larger than 0. Splitting into
>> i686 into i586 and i686 would give more insight into who still needs
>> non-SSE2... Probably hurts my argument, though. :)
>>
>>
> Jeff,
>
> If you want to do the work involved to split up the 32-bit arches please
> do it.
>
> The discussion going on here is not a democratic vote on if non-x86_64
> CPUs are supported. :)
>
>
Fair point. :)

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WNMZXU23ME5KYXO4B77HLKSLUJUEBIBL/

Re: [X86] Re: Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 3:53 PM, Stephen John Smoogen 
wrote:

> On 4 June 2018 at 14:18, Matthew Miller  wrote:
> > On Mon, Jun 04, 2018 at 02:01:13PM -0400, Matthew Miller wrote:
> >> > >>support long NOPs, for Intel CET.  However, the majority of
> >> > >>installations of i686 packages is for use on x86_64 systems, as
> >> > >>multi-lib RPMs.
> >> > >Based on what data?
> >> > The mirror data I've seen, but it's really outdated at this point.
> >> There are currently about 275,000 IP address checking in with x86_64
> >> systems every day. and 25,000 x86_32. So it's about 11:1.
> >
> > Here's a breakdown as arch percentage over time:
> >
> > https://twitter.com/mattdm/status/1003701941724172295
> >
> > Looks like the 50:50 point was about five years ago.
> >
>
> For F26,F27,F28 for the first 150 days of the year:
>
> Days:  150
> X86_32: 3769.4 avg/day
> X86_64: 159540 avg/day
> Ratio (32/64) 0.0236267 (1:42)
>
> The reason is that the majority of i386 users are not moving off of
> dead/old releases. For the month of May
>
> Avg/day release
> 28623.7 epel6
> 16009.2 epel5
> 4043.37 f25
> 3318.53 f20
> 2759.2 f08
> 2127.8 f23
> 1589.63 f27
> 1401.7 f22
> 1371 f26
> 1277.53 f21
> 1056.33 f28
> 874.2 f24
> 733.8 f14
> 562.533 f19
> 509.067 f11
>
> In comparison, x86_64 is mostly living on the latest release:
> [smooge@data-analysis01 mirrors]$ grep '^2018-05-.* x86_64' out-2018
> | awk '{print $3}' | sort | uniq -c | sort -bnr | head -n 15 | awk
> '{print $1/30, $2}'
> 671455 epel7
> 605436 epel6
> 87367.4 f27
> 60159.7 f28
> 37857.6 epel5
> 34421.4 f26
> 27011 f25
> 19115.4 f23
> 14292.2 f24
> 8627.47 f22
> 6603.3 f20
> 5863.47 f21
> 1413.37 modular_f28
> 1091.87 f19
> 868.833 f18
>
> The 30 is because only 30 days of May have been analyzed. [And yes
> there are still many Fedora 08 systems showing up for x86_32]
>
> Personally I think the number of those systems which are running
> Pentium III hardware with the latest OS are probably already on this
> mailing list.. I expect that they would also be looking at only
> needing to support a small subset of the software since running
> GNOME/KDE with usually 128->512 MB of RAM is not possible. It also
> would probably want a very stripped down installer since anaconda is
> aimed at 'current' hardware... probably something like the images that
> ARM-32 makes.
>

Very good point!

And wow! Fedora 08 was quite some time ago... :)

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DZW44V5B32MCO7AKTBSMT3HMTKRQRKTF/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Michael Cronenworth


On 06/04/2018 02:50 PM, Jeff Backus wrote:
Thanks for the data. 25k is still a pretty healthy number. :) I realize that there 
are a lot of unknowns in the data, so it is difficult to draw any hard 
conclusions, but 25k is still much larger than 0. Splitting into i686 into i586 
and i686 would give more insight into who still needs non-SSE2... Probably hurts 
my argument, though. :)




Jeff,

If you want to do the work involved to split up the 32-bit arches please do it.

The discussion going on here is not a democratic vote on if non-x86_64 CPUs are 
supported. :)


Thanks,
Michael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KKS3QTVPVGWGE4QG2YI7ES2J5P3GSKBG/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 2:18 PM, Matthew Miller 
wrote:

> On Mon, Jun 04, 2018 at 02:01:13PM -0400, Matthew Miller wrote:
> > > >>support long NOPs, for Intel CET.  However, the majority of
> > > >>installations of i686 packages is for use on x86_64 systems, as
> > > >>multi-lib RPMs.
> > > >Based on what data?
> > > The mirror data I've seen, but it's really outdated at this point.
> > There are currently about 275,000 IP address checking in with x86_64
> > systems every day. and 25,000 x86_32. So it's about 11:1.
>
> Here's a breakdown as arch percentage over time:
>
> https://twitter.com/mattdm/status/1003701941724172295
>
> Looks like the 50:50 point was about five years ago.
>

Thanks! Very helpful to see x86_32 compared to ARM. Trajectory is very
important, but laying that aside, x86_32 a) significantly larger than both
ARM arches combined, and b) roughly 10% of the "user base".

jeff

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/U5NQTR3ILSAD4XCQJ2N2O33FZFYYHK2U/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Stephen John Smoogen

On 4 June 2018 at 14:18, Matthew Miller  wrote:
> On Mon, Jun 04, 2018 at 02:01:13PM -0400, Matthew Miller wrote:
>> > >>support long NOPs, for Intel CET.  However, the majority of
>> > >>installations of i686 packages is for use on x86_64 systems, as
>> > >>multi-lib RPMs.
>> > >Based on what data?
>> > The mirror data I've seen, but it's really outdated at this point.
>> There are currently about 275,000 IP address checking in with x86_64
>> systems every day. and 25,000 x86_32. So it's about 11:1.
>
> Here's a breakdown as arch percentage over time:
>
> https://twitter.com/mattdm/status/1003701941724172295
>
> Looks like the 50:50 point was about five years ago.
>

For F26,F27,F28 for the first 150 days of the year:

Days:  150
X86_32: 3769.4 avg/day
X86_64: 159540 avg/day
Ratio (32/64) 0.0236267 (1:42)

The reason is that the majority of i386 users are not moving off of
dead/old releases. For the month of May

Avg/day release
28623.7 epel6
16009.2 epel5
4043.37 f25
3318.53 f20
2759.2 f08
2127.8 f23
1589.63 f27
1401.7 f22
1371 f26
1277.53 f21
1056.33 f28
874.2 f24
733.8 f14
562.533 f19
509.067 f11

In comparison, x86_64 is mostly living on the latest release:
[smooge@data-analysis01 mirrors]$ grep '^2018-05-.* x86_64' out-2018
| awk '{print $3}' | sort | uniq -c | sort -bnr | head -n 15 | awk
'{print $1/30, $2}'
671455 epel7
605436 epel6
87367.4 f27
60159.7 f28
37857.6 epel5
34421.4 f26
27011 f25
19115.4 f23
14292.2 f24
8627.47 f22
6603.3 f20
5863.47 f21
1413.37 modular_f28
1091.87 f19
868.833 f18

The 30 is because only 30 days of May have been analyzed. [And yes
there are still many Fedora 08 systems showing up for x86_32]

Personally I think the number of those systems which are running
Pentium III hardware with the latest OS are probably already on this
mailing list.. I expect that they would also be looking at only
needing to support a small subset of the software since running
GNOME/KDE with usually 128->512 MB of RAM is not possible. It also
would probably want a very stripped down installer since anaconda is
aimed at 'current' hardware... probably something like the images that
ARM-32 makes.



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/CKOZSPOK63LLQK5MOVV6J4JX4COYI7XK/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 2:01 PM, Matthew Miller 
wrote:

> On Mon, Jun 04, 2018 at 04:04:30PM +0200, Florian Weimer wrote:
> > >>only addition over the i686/Pentium Pro baseline is a requirement to
> > >>support long NOPs, for Intel CET.  However, the majority of
> > >>installations of i686 packages is for use on x86_64 systems, as
> > >>multi-lib RPMs.
> > >Based on what data?
> > The mirror data I've seen, but it's really outdated at this point.
>
> There are currently about 275,000 IP address checking in with x86_64
> systems every day. and 25,000 x86_32. So it's about 11:1.
>
> However, that includes systems going back to FC6; if we looked at just
> recent releases it'd be even more tilted. (I don't have a quick way to
> break that out at my fingertips, but could ask for it if it's really
> helpful.)
>

Thanks for the data. 25k is still a pretty healthy number. :) I realize
that there are a lot of unknowns in the data, so it is difficult to draw
any hard conclusions, but 25k is still much larger than 0. Splitting into
i686 into i586 and i686 would give more insight into who still needs
non-SSE2... Probably hurts my argument, though. :)

jeff

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VRNHT4KNFXRAQ6CTN6NCD6OZLXE45XR6/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 1:45 PM, Rex Dieter  wrote:

> Jeff Backus wrote:
>
>
> > Until (unless?) we have data indicating that this is a major drain on
> > community resources, I'd push back on a change that actively excludes
> part
> > of the community. Now, if we do have data indicating that supporting
> > non-SSE2 systems with the i686 architecture is a not-insignificant burden
> > on the community, then I ask that this proposal be updated to include a
> > solution that allows us to not push out part of the community, e.g.
> Ajax's
> > i586 suggestion.
>
> Fwiw, Qt5 officially doesn't support non-sse2 systems either.  kde-sig has
> had to carry patches/hacks to make it work (or at least be buildable), but
> I'd love to be able to not have to do that anymore.
>
>
Hmm.. Yes, we've had discussions within the SIG re: window managers that
support i586/i686, and KDE was on the list of WMs that no longer support
our target system. Do these patches/hacks only apply to KDE or do they
apply to Qt in general?

jeff

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OROU4NJTSJELPTGQ4GNUTTCZGFNFVB4I/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 1:46 PM, Josh Boyer 
wrote:

> On Mon, Jun 4, 2018 at 12:55 PM Jeff Backus  wrote:
> >
> >
> >
> > On Mon, Jun 4, 2018 at 12:11 PM, Florian Weimer 
> wrote:
> >>
> >> On 06/04/2018 05:55 PM, Jeff Backus wrote:
> >>>
> >>> Would you please provide more detail on what problem or problems we
> are trying to solve? Is this purely for efficiency reasons?
> >>
> >>
> >> Mainly developer efficiency.  There will be fewer test suite problems
> due to excess precision (a bunch of packages carry patches which introduce
> -ffloat-store on i686 to work around them).  Packagers will not have to
> figure out a way how to build for compatibility with non-SSE2 systems
> (which some upstreams do not support anymore).
> >>
> >> Furthermore, the divergence from downstream is troubling to Red Hatters
> for various reasons.  (Red Hat Enterprise Linux 7 already underwent a
> similar change.)
> >>
> >
> > Thanks for the insight. Yes, I can see the advantages. However, have
> things really gotten so bad that it justifies ejecting part of the
> community? Yes, a minor part of the community, but a part of the community
> none the less. As you mentioned, the excess precision issue has a known
> work around. And for packages where upstream does not support non-SSE2,
> packagers can raise a flag with the x86 SIG. If there isn't enough interest
> or bandwidth to add support for non-SSE2 systems, then I think it is
> perfectly reasonable to add a note in the package description and move on.
> I believe packages such as Dark Table already do this?
>
> You're describing the status quo today.
>

Yes, I am arguing in favor of the status quo.


>
> > Until (unless?) we have data indicating that this is a major drain on
> community resources, I'd push back on a change that actively excludes part
> of the community. Now, if we do have data indicating that supporting
> non-SSE2 systems with the i686 architecture is a not-insignificant burden
> on the community, then I ask that this proposal be updated to include a
> solution that allows us to not push out part of the community, e.g. Ajax's
> i586 suggestion.
>
> How about data that indicates it's less performant for other usecase
> applications?  There are a number of situations where 32-bit binaries
> would possibly be preferable, such as limited memory VMs, etc.
> However, because the tuning is aimed at hardware that is so old, the
> performance is worse.  Or if we're looking at multi-lib situations,
> what if a 32-bit application that requires a 32-bit library happens to
> be built with SSE2 enabled?  The application can benefit from the
> hardware, but the libraries the OS provides cannot.  That is an odd
> mix.
>

I agree that this is a valid use case. The i586 arch would be reasonable
compromise, depending on the amount of effort required to split i686.


>
> At some point in time, a determination needs to be made on when to
> move on and take advantage of advances in computing hardware.
> Continuing to not leverage newer 32-bit hardware seems folly.
>

Agreed. I'm just arguing for choosing a path that excludes as few users as
possible.


>
> > Not trying to be quarrelsome. I understand the desire to focus efforts,
> however, I hope we can also appreciate the concerns of those of us with
> currently supported hardware that would be affected by this proposal.
>
> We should really stop using the word "support" here.  It implies that
> an entity, the Fedora project in this case, is responsible for keeping
> it working or treating it as a regression if it does not work.  That
> is not an accurate description of the situation.  We should talk about
> i686 hardware as community maintained, which implies the onus is on
> those that want it to work to get it to work.  One could say "but
> Fedora is a community project" and they'd be completely correct but
> "support" has too much baggage to use with Fedora in general.
>
>
Good point, and, yes, I should have used a more precise term. Secondary
arches definitely fall under the purview of 'community maintained'. I stand
corrected.

jeff


-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/2ZHT6DR7O4VXMJB55I7M64KYLVHCYY4W/

Re: F29 System Wide Change: Hide the grub menu

2018-06-04 Thread Adam Williamson

On Thu, 2018-05-31 at 12:43 +0200, Jan Kurik wrote:
> = Proposed System Wide Change: Hide the grub menu =
> https://fedoraproject.org/wiki/Changes/HiddenGrubMenu

We (QA) would like to note that the "How to test" section of this
Change seems heavily under-developed:

"1. Install Fedora in a fresh vm or select reclaim diskspace -> delete
all in the installer (od a single os install).
2. Boot the system the grub menu should not show
3. (Re)boot press F8 repeatedly when the firmware / vendor logo shows,
you should now get the grub menu"

I mean, that doesn't even consider testing that the change is *not*
applied when doing a "multi OS" install, which is explicitly part of
the Change. As a *bare minimum*, that needs to be covered.

It also doesn't cover other situations. One brought up at our QA
meeting was - what happens if you install Fedora first and then another
Linux distribution second?

The Change as a whole doesn't seem to consider what should happen in
this case, which seems like an omission; obviously if there *is* an
expected outcome in this case, the "How to test" section should cover
testing it.
--
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TBT36IKLIGGOUHXEWZ4W7BB6CKXHKUF2/

Fedora Rawhide-20180604.n.0 compose check report

2018-06-04 Thread Fedora compose checker

No missing expected images.

Failed openQA tests: 12/137 (x86_64), 5/24 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20180603.n.1):

ID: 244870  Test: x86_64 universal install_blivet_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/244870

Old failures (same test failed in Rawhide-20180603.n.1):

ID: 244825  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/244825
ID: 244826  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/244826
ID: 244827  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/244827
ID: 244828  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/244828
ID: 244829  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/244829
ID: 244831  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/244831
ID: 244840  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/244840
ID: 244841  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/244841
ID: 244874  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/244874
ID: 244890  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/244890
ID: 244899  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/244899
ID: 244904  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/244904
ID: 244913  Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/244913
ID: 244915  Test: x86_64 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/244915
ID: 244919  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/244919
ID: 244937  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/244937
ID: 244938  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/244938

Soft failed openQA tests: 4/137 (x86_64), 2/24 (i386)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Rawhide-20180603.n.1):

ID: 244802  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/244802
ID: 244803  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/244803
ID: 244804  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/244804
ID: 244856  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/244856
ID: 244907  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/244907
ID: 244908  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/244908

Passed openQA tests: 110/137 (x86_64), 17/24 (i386)

New passes (same test did not pass in Rawhide-20180603.n.1):

ID: 244781  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/244781
ID: 244810  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/244810
ID: 244920  Test: x86_64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/244920

Skipped openQA tests: 12 of 163

Installed system changes in test x86_64 Server-boot-iso install_default: 
1 packages(s) added since previous compose: lmdb-libs
1 packages(s) removed since previous compose: nss-pem
Previous test data: https://openqa.fedoraproject.org/tests/244518#downloads
Current test data: https://openqa.fedoraproject.org/tests/244780#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
System load changed from 1.59 to 1.47
Previous test data: https://openqa.fedoraproject.org/tests/244522#downloads
Current test data: https://openqa.fedoraproject.org/tests/244784#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
System load changed from 1.80 to 1.14
Previous test data: https://openqa.fedoraproject.org/tests/244524#downloads
Current test data: https://openqa.fedoraproject.org/tests/244786#downloads

Installed system changes in test i386 Server-boot-iso install_default: 
1 packages(s) removed since previous compose: nss-pem
Previous test data: https://openqa.fedoraproject.org/tests/244541#downloads
Current test data: https://openqa.fedoraproject.org/tests/244803#downloads

Installed system changes in test i386 Server-dvd-iso install_default: 
System load changed from 0.28 to 0.11
Previous test data:

Re: F29 System Wide Change: Strong crypto settings: phase 2

2018-06-04 Thread Adam Williamson

On Fri, 2018-06-01 at 13:40 +0200, Jan Kurik wrote:
> = Proposed System Wide Change: Strong crypto settings: phase 2 =
> https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2

The "how to test" section for this Change seems a little worryingly
barebones:

"Applications which follow the system-wide policy (e.g., curl,wget)
should be tested:

* whether they can connect to legacy (TLS1.0, TLS1.1) servers when
system is in legacy mode
* whether the previous connection breaks when system is in default mode
* whether the system can connect to TLS 1.2 servers when in default,
legacy or future mode."

That "e.g., curl,wget" especially is pretty slapdash. We (QA) would
suggest it's incumbent on the Change owners here to do a better job of
identifying things that respect the system-wide policy, especially
considering release-critical components. For instance, does Firefox
respect the policy? I believe the answer is "yes", but this should be
something the Change owners look into. For another instance, do
components of FreeIPA respect the policy, and if so, have we considered
how this will affect those when e.g. an F29 system is enrolled as a
member of a FreeIPA domain where the server is running on an older
Fedora, or RHEL, or something?

How about clients for networking with other OSes - e.g. Samba clients,
and the tools for enrolling systems as Active Directory domain members?
Do those respect the system policy? If so, have we considered the
impact of these changes on those configurations?
-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Q6WUF2FGZCRUOCGUI3R7FWC2AZGXA2TI/

Re: equivalent of Debian config-package?

2018-06-04 Thread Josh Boyer

On Mon, Jun 4, 2018 at 2:29 PM Dave Love  wrote:
>
> You wrote:
>
> > I think generally the Fedora/RH-ecosystem answer is to use Ansible for
> > configuration, rather than configuration packages.
> >
> > That's not sayin' there can't be another answer, but in general that's
> > the route *I'd* take to solve this problem on my systems.
>
> I guess we disagree about what the problem is, but it's unfortunate if
> Fedora/RH isn't interested in the sort of environment for which
> config-package was developed.

Can you elaborate more on what that environment is?  I read the
website you linked to, but I still don't understand how this wouldn't
be similarly solved with Ansible.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/L3B3VQSD5GL3PPQG67G3VR2EHQ3IX5UO/

Re: equivalent of Debian config-package?

2018-06-04 Thread Dave Love

You wrote: 

> Neal Gompa wrote:
>> No such thing currently exists, because an equivalent to `dpkg-divert`
>> does not exist in RPM.
>
> You are probably aware of this, but for the other readers of this thread:

I wasn't anyhow, thanks!

> File triggers can be (ab)used to do something like that, though it's not as 
> easy as running a `dpkg-divert` command, you have to build a dummy package 
> with a file trigger that munges the file.

Unfortunately they're not available on RHEL, which is the main target of
interest.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/DG6C4OFKE4Q52HTGD5NOCRV7GDAIPYND/

Re: equivalent of Debian config-package?

2018-06-04 Thread Dave Love

You wrote: 

> I think generally the Fedora/RH-ecosystem answer is to use Ansible for
> configuration, rather than configuration packages.
>
> That's not sayin' there can't be another answer, but in general that's
> the route *I'd* take to solve this problem on my systems.

I guess we disagree about what the problem is, but it's unfortunate if
Fedora/RH isn't interested in the sort of environment for which
config-package was developed.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WASK32G3OQEWODPV44O3HL7VNXHZOSPR/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 04, 2018 at 02:01:13PM -0400, Matthew Miller wrote:
> > >>support long NOPs, for Intel CET.  However, the majority of
> > >>installations of i686 packages is for use on x86_64 systems, as
> > >>multi-lib RPMs.
> > >Based on what data?
> > The mirror data I've seen, but it's really outdated at this point.
> There are currently about 275,000 IP address checking in with x86_64
> systems every day. and 25,000 x86_32. So it's about 11:1.

Here's a breakdown as arch percentage over time:

https://twitter.com/mattdm/status/1003701941724172295

Looks like the 50:50 point was about five years ago.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UQFO6ET7IHYYXJIMF2CCYR3OKEBTGK4Q/

Re: Introduction

2018-06-04 Thread Lukáš Tyrychtr


Hi and thank you. :)

L. T.

Dne 04.06.2018 v 18:55 Matthew Miller napsal(a):

On Mon, Jun 04, 2018 at 09:21:22AM +0200, Lukáš Tyrychtr wrote:

My name is Lukáš Tyrychtr and i am a student currently having an
intership at Red Hat. The objective of the internship is mainly
fixing accessibility bugs and overall improving the situation in
Fedora, so in the future you can expect some work in this regard,
currently i am working on a complete rewrite of the packages for the
Festival speech synthesis system.


Welcome Lukáš, and thanks for your work on this!


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GTRYYMRBLQTEAWN7HEFKDIJIXCNAAAI7/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 04, 2018 at 04:04:30PM +0200, Florian Weimer wrote:
> >>only addition over the i686/Pentium Pro baseline is a requirement to
> >>support long NOPs, for Intel CET.  However, the majority of
> >>installations of i686 packages is for use on x86_64 systems, as
> >>multi-lib RPMs.
> >Based on what data?
> The mirror data I've seen, but it's really outdated at this point.

There are currently about 275,000 IP address checking in with x86_64
systems every day. and 25,000 x86_32. So it's about 11:1.

However, that includes systems going back to FC6; if we looked at just
recent releases it'd be even more tilted. (I don't have a quick way to
break that out at my fingertips, but could ask for it if it's really
helpful.)

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IAO2TJVPNUNEZF33CTQUKNDKSAT35WZI/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Josh Boyer

On Mon, Jun 4, 2018 at 12:55 PM Jeff Backus  wrote:
>
>
>
> On Mon, Jun 4, 2018 at 12:11 PM, Florian Weimer  wrote:
>>
>> On 06/04/2018 05:55 PM, Jeff Backus wrote:
>>>
>>> Would you please provide more detail on what problem or problems we are 
>>> trying to solve? Is this purely for efficiency reasons?
>>
>>
>> Mainly developer efficiency.  There will be fewer test suite problems due to 
>> excess precision (a bunch of packages carry patches which introduce 
>> -ffloat-store on i686 to work around them).  Packagers will not have to 
>> figure out a way how to build for compatibility with non-SSE2 systems (which 
>> some upstreams do not support anymore).
>>
>> Furthermore, the divergence from downstream is troubling to Red Hatters for 
>> various reasons.  (Red Hat Enterprise Linux 7 already underwent a similar 
>> change.)
>>
>
> Thanks for the insight. Yes, I can see the advantages. However, have things 
> really gotten so bad that it justifies ejecting part of the community? Yes, a 
> minor part of the community, but a part of the community none the less. As 
> you mentioned, the excess precision issue has a known work around. And for 
> packages where upstream does not support non-SSE2, packagers can raise a flag 
> with the x86 SIG. If there isn't enough interest or bandwidth to add support 
> for non-SSE2 systems, then I think it is perfectly reasonable to add a note 
> in the package description and move on. I believe packages such as Dark Table 
> already do this?

You're describing the status quo today.

> Until (unless?) we have data indicating that this is a major drain on 
> community resources, I'd push back on a change that actively excludes part of 
> the community. Now, if we do have data indicating that supporting non-SSE2 
> systems with the i686 architecture is a not-insignificant burden on the 
> community, then I ask that this proposal be updated to include a solution 
> that allows us to not push out part of the community, e.g. Ajax's i586 
> suggestion.

How about data that indicates it's less performant for other usecase
applications?  There are a number of situations where 32-bit binaries
would possibly be preferable, such as limited memory VMs, etc.
However, because the tuning is aimed at hardware that is so old, the
performance is worse.  Or if we're looking at multi-lib situations,
what if a 32-bit application that requires a 32-bit library happens to
be built with SSE2 enabled?  The application can benefit from the
hardware, but the libraries the OS provides cannot.  That is an odd
mix.

At some point in time, a determination needs to be made on when to
move on and take advantage of advances in computing hardware.
Continuing to not leverage newer 32-bit hardware seems folly.

> Not trying to be quarrelsome. I understand the desire to focus efforts, 
> however, I hope we can also appreciate the concerns of those of us with 
> currently supported hardware that would be affected by this proposal.

We should really stop using the word "support" here.  It implies that
an entity, the Fedora project in this case, is responsible for keeping
it working or treating it as a regression if it does not work.  That
is not an accurate description of the situation.  We should talk about
i686 hardware as community maintained, which implies the onus is on
those that want it to work to get it to work.  One could say "but
Fedora is a community project" and they'd be completely correct but
"support" has too much baggage to use with Fedora in general.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WXCZSJGNHTGNASALYGZSD2CDCUZH3SRD/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Rex Dieter

Jeff Backus wrote:


> Until (unless?) we have data indicating that this is a major drain on
> community resources, I'd push back on a change that actively excludes part
> of the community. Now, if we do have data indicating that supporting
> non-SSE2 systems with the i686 architecture is a not-insignificant burden
> on the community, then I ask that this proposal be updated to include a
> solution that allows us to not push out part of the community, e.g. Ajax's
> i586 suggestion.

Fwiw, Qt5 officially doesn't support non-sse2 systems either.  kde-sig has 
had to carry patches/hacks to make it work (or at least be buildable), but 
I'd love to be able to not have to do that anymore.

-- Rex
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZLCNHV7UX5HKAIRW763U5ECPW6AKEH3E/

xpa license change

2018-06-04 Thread Sergio Pascual

The license in xpa has changed from LGPLv2+ in version 2.1.15 to MIT in xpa
2.1.18

Regards, Sergio
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GSN2MSQRTH5RZ2ZLVMOVHNQMYAKFZYE4/

Re: Introduction

On Mon, Jun 04, 2018 at 09:21:22AM +0200, Lukáš Tyrychtr wrote:
> My name is Lukáš Tyrychtr and i am a student currently having an
> intership at Red Hat. The objective of the internship is mainly
> fixing accessibility bugs and overall improving the situation in
> Fedora, so in the future you can expect some work in this regard,
> currently i am working on a complete rewrite of the packages for the
> Festival speech synthesis system.


Welcome Lukáš, and thanks for your work on this!

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZG2POP674HBTEHP7VYPNYCJNYH2FVECC/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 12:11 PM, Florian Weimer  wrote:

> On 06/04/2018 05:55 PM, Jeff Backus wrote:
>
>> Would you please provide more detail on what problem or problems we are
>> trying to solve? Is this purely for efficiency reasons?
>>
>
> Mainly developer efficiency.  There will be fewer test suite problems due
> to excess precision (a bunch of packages carry patches which introduce
> -ffloat-store on i686 to work around them).  Packagers will not have to
> figure out a way how to build for compatibility with non-SSE2 systems
> (which some upstreams do not support anymore).
>
> Furthermore, the divergence from downstream is troubling to Red Hatters
> for various reasons.  (Red Hat Enterprise Linux 7 already underwent a
> similar change.)
>
>
Thanks for the insight. Yes, I can see the advantages. However, have things
really gotten so bad that it justifies ejecting part of the community? Yes,
a minor part of the community, but a part of the community none the less.
As you mentioned, the excess precision issue has a known work around. And
for packages where upstream does not support non-SSE2, packagers can raise
a flag with the x86 SIG. If there isn't enough interest or bandwidth to add
support for non-SSE2 systems, then I think it is perfectly reasonable to
add a note in the package description and move on. I believe packages such
as Dark Table already do this?

Until (unless?) we have data indicating that this is a major drain on
community resources, I'd push back on a change that actively excludes part
of the community. Now, if we do have data indicating that supporting
non-SSE2 systems with the i686 architecture is a not-insignificant burden
on the community, then I ask that this proposal be updated to include a
solution that allows us to not push out part of the community, e.g. Ajax's
i586 suggestion.

Not trying to be quarrelsome. I understand the desire to focus efforts,
however, I hope we can also appreciate the concerns of those of us with
currently supported hardware that would be affected by this proposal.

jeff

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3K3SWOKJHZNRIVYN2WWASDSLVBZLQCBJ/

Re: F29 System Wide Change: Hide the grub menu

2018-06-04 Thread Przemek Klosowski

On 05/31/2018 04:54 PM, Jason L Tibbitts III wrote:

Plus, there's an upside: if you're hammering F11 or F8 or F12 or Esc or
whatever to try and get into the BIOS, and you miss it, then at least
you stop in grub instead of going straight into the OS.

A big part of the 'dark pattern' of the current boot process is that
there is rarely a feedback for all those keystroke events. We are
conditioned to go full Rachmaninoff on the keyboard---I usually try to
play chords and/or crescendos of Escape, F2, F8, F9 and F12.

Recent DELL BIOS/EFI firmware flashes short announcements ('Press F2 for
system configuration') and acknowledges seeing keystrokes ("Entering
boot selection menu"). Even though the response is not very real-time,
it's still a big improvement over the old "typing into the dark and
hoping something happens".

It would be a step forward if the proposed new boot process printed out
a message as soon as it saw something important happen, e.g.

"F12 key pressed; entering boot selection menu. Other keys include F8
for ... and Esc for ..."

"Previous OS boot incomplete or unsuccessful; entering boot selection menu"

"Unrecognized key pressed. Valid boot selection keys include F12 (boot
selection), F8 (...) ..."

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4C2PBRCQC6YUCYMF3WDH2ZYSYGEGZASA/

Re: F29 System Wide Change: Hide the grub menu

2018-06-04 Thread Chris Murphy

On Mon, Jun 4, 2018 at 1:22 AM, Till Maas  wrote:

>
> My proposal was for the instructions to recommend pressing a certain key
> but still accepting any key in grub, then there is no lie, since "Press
> space to enter grub" is still true when other keys allow the same.

I'm still not a fan because it's not accurate. But it isn't terrible
and isn't a hill I'm gonna die on.



>> >Also it would be awesome if it was still possible to easily
>> > reboot to grub after the kernel took over, e.g. from the harddisk
>> > password screen, GDM login screen and Gnome logout dialog. Then you can
>> > just make it user-friendly and obvious.
>>
>> password screen is a plymouth feature request; from what I'm looking
>> at gdm login and gnome logout dialog both have a restart option which
>> gets me back to GRUB so I'm not following what different behavior
>> you're proposing.
>
> My idea was to not have a short timeout when a user selects "Reboot to
> Bootloader" (to be implemented) as restart option, so that user do not
> have to fiddle with pressing the right key at the right time when they
> already know I want to get to the grub menu. Also when they missed the
> right time during boot, plymouth could recognise this, make sure the
> grub menu will be shown without a short timeout in the next boot and
> reboot.

Agreed but there are more options possible to help the user avoid the
mess that is keyboard shortcuts for firmware and bootloader:


Reboot to bootloader
Reboot to firmware setup
Reboot to macOS/Windows (upon detection one of those exists)




-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6HJ4ZVVQY4QLPAAHQTP5C5H2TAUFDBCU/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Emmanuel Seyman

* Chris Adams [04/06/2018 10:58] :
>
> I think you are missing a some of The Atom chips that are 32-bit only;
> there are versions that were released as late as 2010 that don't support
> 64-bit (I don't know when they were discontinued).

You're thinking of the Lincroft series of Intel CPUs:
http://www.cpu-world.com/CPUs/Atom/Intel-Atom%20Z650%20AY80609007296AA.html
http://www.cpu-world.com/CPUs/Atom/Intel-Atom%20Z670%20AY80609007293AA.html

They were introduced in 2011 and EOL-ed in 2013.

Emmanuel
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WMM6HM4V6FYBNMZ5BYLJWZLFWLAKO4EP/

Fedora rawhide compose report: 20180604.n.0 changes

2018-06-04 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20180603.n.1
NEW: Fedora-Rawhide-20180604.n.0

= SUMMARY =
Added images:4
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   36
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   700.23 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -30.16 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Python_Classroom vagrant-libvirt i386
Path: 
Labs/i386/images/Fedora-Python-Classroom-Vagrant-Rawhide-20180604.n.0.i386.vagrant-libvirt.box
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20180604.n.0.x86_64.vagrant-virtualbox.box
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20180604.n.0.x86_64.vagrant-libvirt.box
Image: Python_Classroom vagrant-virtualbox i386
Path: 
Labs/i386/images/Fedora-Python-Classroom-Vagrant-Rawhide-20180604.n.0.i386.vagrant-virtualbox.box

= DROPPED IMAGES =
Image: Container_Minimal_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Minimal-Base-Rawhide-20180603.n.1.aarch64.tar.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  ModemManager-1.8.0-1.fc29
Old package:  ModemManager-1.6.12-3.fc28
Summary:  Mobile broadband modem management service
RPMs: ModemManager ModemManager-devel ModemManager-glib 
ModemManager-glib-devel ModemManager-vala
Size: 11.91 MiB
Size change:  689.31 KiB
Changelog:
  * Tue Apr 24 2018 Lubomir Rintel  - 1.8.0-0.rc2.1
  - Update to 1.8 release candidate 2

  * Sun Jun 03 2018 Lubomir Rintel  - 1.8.0-1
  - Update to 1.8.0 release


Package:  awscli-1.15.31-1.fc29
Old package:  awscli-1.15.28-1.fc29
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 1.05 MiB
Size change:  20 B
Changelog:
  * Sun Jun 03 2018 Kevin Fenzi  - 1.15.31-1
  - Update to 1.15.31. Fixes bug #1583867


Package:  buildah-1.0-17.gitf90b6c0.fc29
Old package:  buildah-1.0-16.git70641ee.fc29
Summary:  A command line tool used for creating OCI Images
RPMs: buildah
Size: 17.59 MiB
Size change:  356 B
Changelog:
  * Mon Jun 04 2018 Lokesh Mandvekar (Bot)  - 
1.0-17.gitf90b6c0
  - autobuilt f90b6c0


Package:  calibre-3.25.0-1.fc29
Old package:  calibre-3.24.2-1.fc29
Summary:  E-book converter and library manager
RPMs: calibre
Size: 206.73 MiB
Size change:  -244.73 KiB
Changelog:
  * Sun Jun 03 2018 Kevin Fenzi  - 3.25.0-1
  - Update to 3.25.0. Fixes bug #1585171


Package:  julia-0.6.3-1.fc29
Old package:  julia-0.6.2-3.fc29
Summary:  High-level, high-performance dynamic language for technical 
computing
RPMs: julia julia-common julia-devel julia-doc
Size: 31.09 MiB
Size change:  -42.08 KiB
Changelog:
  * Sun Jun 03 2018 Milan Bouchet-Valat  - 0.6.3-1
  - New upstream release.


Package:  kf5-baloo-5.47.0-1.fc29
Old package:  kf5-baloo-5.46.0-1.fc29
Summary:  A Tier 3 KDE Frameworks 5 module that provides indexing and 
search functionality
RPMs: kf5-baloo kf5-baloo-devel kf5-baloo-file kf5-baloo-libs
Size: 4.36 MiB
Size change:  268.80 KiB
Changelog:
  * Sat Jun 02 2018 Rex Dieter  - 5.47.0-1
  - 5.47.0


Package:  kf5-frameworkintegration-5.47.0-1.fc29
Old package:  kf5-frameworkintegration-5.46.0-2.fc29
Summary:  KDE Frameworks 5 Tier 4 workspace and cross-framework integration 
plugins
RPMs: kf5-frameworkintegration kf5-frameworkintegration-devel 
kf5-frameworkintegration-libs
Size: 11.30 MiB
Size change:  1.11 KiB
Changelog:
  * Sat Jun 02 2018 Rex Dieter  - 5.47.0-1
  - 5.47.0


Package:  kf5-kactivities-5.47.0-1.fc29
Old package:  kf5-kactivities-5.46.0-1.fc29
Summary:  A KDE Frameworks 5 Tier 3 to organize user work into separate 
activities
RPMs: kf5-kactivities kf5-kactivities-devel kf5-kactivities-libs
Size: 1.31 MiB
Size change:  92.75 KiB
Changelog:
  * Sat Jun 02 2018 Rex Dieter  - 5.47.0-1
  - 5.47.0


Package:  kf5-kactivities-stats-5.47.0-1.fc29
Old package:  kf5-kactivities-stats-5.46.0-1.fc29
Summary:  A KDE Frameworks 5 Tier 3 library for accessing the usage data 
collected by the activities system
RPMs: kf5-kactivities-stats kf5-kactivities-stats-devel
Size: 868.64 KiB
Size change:  36.47 KiB
Changelog:
  * Sat Jun 02 2018 Rex Dieter  - 5.47.0-1
  - 5.47.0


Package:  kf5-kcmutils-5.47.0-1.fc29
Old package:  kf5-kcmutils-5.46.0-1.fc29
Summary:  KDE Frameworks 5 Tier 3 addon with extra API to write 
KConfigModules
RPMs: kf5-kcmutils kf5-kcmutils-devel
Size: 2.31 MiB
Size change:  40.14 KiB
Changelog:
  * Sat Jun 02 2018 Rex Dieter  - 5.47.0-1
  - 5.47.0


Package:  kf5-kdeclarative-5.47.0-1.fc29
Old package:  kf5-kdeclarative

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Florian Weimer


On 06/04/2018 05:55 PM, Jeff Backus wrote:
Would you please provide more detail on what problem or problems we are 
trying to solve? Is this purely for efficiency reasons?


Mainly developer efficiency.  There will be fewer test suite problems 
due to excess precision (a bunch of packages carry patches which 
introduce -ffloat-store on i686 to work around them).  Packagers will 
not have to figure out a way how to build for compatibility with 
non-SSE2 systems (which some upstreams do not support anymore).


Furthermore, the divergence from downstream is troubling to Red Hatters 
for various reasons.  (Red Hat Enterprise Linux 7 already underwent a 
similar change.)


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PN7J74LU7EOCY5UYPT4UTNSZCN2NWL2S/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 11:52 AM, Adam Jackson  wrote:

> On Mon, 2018-06-04 at 17:21 +0200, Florian Weimer wrote:
> > On 06/04/2018 05:07 PM, Adam Jackson wrote:
> > > On Mon, 2018-06-04 at 16:04 +0200, Florian Weimer wrote:
> > >
> > > > > > This proposal suggests to accept this reality and build the i686
> > > > > > packages in such a way that they require the ISA level of (early)
> > > > > > x86-64 CPUs.
> > > > >
> > > > > On which x86 CPU families will Fedora continue to work?
> > > >
> > > > Based on this proposed change, you will need an x86-64-capable CPU.
> > >
> > > That's not how I read the proposal. No reason a P4 shouldn't work if
> > > all you're requiring is SSE2+FXSR, right?
> >
> > It will probably work, but it's more of a happy accident than a
> > deliberate decision.  I would still suggest it if it were incompatible
> > with Pentium 4 CPUs without x86-64 support.  (The fewer of these
> > Netburst power guzzlers are running, the better, to be honest.)
>
> Certainly, I'm no netburst fan either. But the last[*] 32-bit-only
> Intel chip was Yonah (Core 1), which went out of production in 2008-
> ish, so there's about seven years worth of CPUs between the
> introductions of SSE2 and AMD64. So this isn't eliminating the
> possibility of extant i686 kernels, which "will need an x86-64-capable
> CPU" might otherwise imply.
>

Yeah, I have a handful of i686 hardware newer than 2001 that runs pretty
well.

jeff

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MFVSHYVEJA4KWCHFUTBGIYKD2LFG2KI4/

Re: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 11:01 AM, Adam Jackson  wrote:

> On Mon, 2018-06-04 at 08:59 -0500, Ian Pilcher wrote:
> > On 06/04/2018 04:28 AM, Florian Weimer wrote:
> > > It should, because -march=x86-64 implies just SSE2 and FXSR, and Xeon
> MP
> > > supports both.  But the intent is what the subject says: i686 binaries
> > > are for running legacy software on x86-64 systems, and nothing more.
> >
> > So the 32-bit x86 SIG would be required to rebuild all of the userspace
> > packages to run on actual 32-bit hardware, right?  (What would those be
> > called, since i686 is taken?)
>
> No. The 32-bit ABI level being targeted here is basically the Pentium
> 4, which was a 32-bit part. On a P3 or older, yes, you'd need a
> rebuild, but the P4 was 2001 so we're talking about hardware old enough
> to vote here.
>
> If we did want to allow for pre-P4 32-bit userspace, what I'd probably
> do is (mostly) change %_libdir to /usr/lib/sse2 for i686, and leave it
> as /usr/lib for a (reintroduced) i586 architecture.
>

If there is truly a pressing need to enable SSE2 for *all* i686 binaries,
I'd support this as a compromise.

jeff

-- 
Jeff Backus
jeff.bac...@gmail.com
http://github.com/jsbackus
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Q7ZN5JPBX44TSYF5KBUY2656BQ5PRFQE/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Chris Adams

Once upon a time, Adam Jackson  said:
> Certainly, I'm no netburst fan either. But the last[*] 32-bit-only
> Intel chip was Yonah (Core 1), which went out of production in 2008-
> ish, so there's about seven years worth of CPUs between the
> introductions of SSE2 and AMD64.

I think you are missing a some of The Atom chips that are 32-bit only;
there are versions that were released as late as 2010 that don't support
64-bit (I don't know when they were discontinued).  Whether that's a
target for Fedora i686, I don't know.

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LWHYMRNOWRTFDJ5YPPYFV6EF7FPARIDB/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

On Mon, Jun 4, 2018 at 7:20 AM, Florian Weimer  wrote:

> = Proposed System Wide Change: i686 Is For x86-64 =
> https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64
>
>
> Owner(s):
>   * Florian Weimer 
>
>
> Fedora builds its i686 packages for use on x86-64 systems as multi-lib
> RPMs.
>
>
>
> == Detailed description ==
> Currently, the i686 RPM packages are built in such a way that they are
> compatible with very old i686 systems, such as the Pentium III.  The
> only addition over the i686/Pentium Pro baseline is a requirement to
> support long NOPs, for Intel CET.  However, the majority of
> installations of i686 packages is for use on x86_64 systems, as
> multi-lib RPMs.  Furthermore, there are reports that the i686 kernel
> does not run stable on old hardware which is not x86-64-capable (
> https://lists.fedoraproject.org/archives/list/x...@lists.fedo
> raproject.org/thread/ZHV6I4IEO7GRYAZ4TUMO5VH2ZHLCNJZQ/
> ).
> This proposal suggests to accept this reality and build the i686
> packages in such a way that they require the ISA level of (early)
> x86-64 CPUs.
>

Would you please provide more detail on what problem or problems we are
trying to solve? Is this purely for efficiency reasons?

jeff
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MMJYA7KVFJ3UEYMVFQL3OFQLI7R27Z54/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Adam Jackson

On Mon, 2018-06-04 at 17:21 +0200, Florian Weimer wrote:
> On 06/04/2018 05:07 PM, Adam Jackson wrote:
> > On Mon, 2018-06-04 at 16:04 +0200, Florian Weimer wrote:
> > 
> > > > > This proposal suggests to accept this reality and build the i686
> > > > > packages in such a way that they require the ISA level of (early)
> > > > > x86-64 CPUs.
> > > > 
> > > > On which x86 CPU families will Fedora continue to work?
> > > 
> > > Based on this proposed change, you will need an x86-64-capable CPU.
> > 
> > That's not how I read the proposal. No reason a P4 shouldn't work if
> > all you're requiring is SSE2+FXSR, right?
> 
> It will probably work, but it's more of a happy accident than a 
> deliberate decision.  I would still suggest it if it were incompatible 
> with Pentium 4 CPUs without x86-64 support.  (The fewer of these 
> Netburst power guzzlers are running, the better, to be honest.)

Certainly, I'm no netburst fan either. But the last[*] 32-bit-only
Intel chip was Yonah (Core 1), which went out of production in 2008-
ish, so there's about seven years worth of CPUs between the
introductions of SSE2 and AMD64. So this isn't eliminating the
possibility of extant i686 kernels, which "will need an x86-64-capable
CPU" might otherwise imply.

[*] - Ignoring Quark, as the rest of the market did.

- ajax
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TGAZS4TK3F5XW4PIRXCJCLMQYVC4HCZP/

Re: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Al Dunsmuir

On Monday, June 4, 2018, 4:35:34 AM, Jan Kurik wrote:
> = Proposed System Wide Change: i686 Is For x86-64 =
> https://fedoraproject.org/wiki/Changes/i686_Is_For_x86-64

> Owner(s):
>   * Florian Weimer 

> Fedora builds its i686 packages for use on x86-64 systems as multi-lib RPMs.

> == Detailed description ==
> Currently, the i686 RPM packages are built in such a way that they are
> compatible with very old i686 systems, such as the Pentium III.  The
> only addition over the i686/Pentium Pro baseline is a requirement to
> support long NOPs, for Intel CET.  However, the majority of
> installations of i686 packages is for use on x86_64 systems, as
> multi-lib RPMs.  Furthermore, there are reports that the i686 kernel
> does not run stable on old hardware which is not x86-64-capable (
> https://lists.fedoraproject.org/archives/list/x...@lists.fedoraproject.org/thread/ZHV6I4IEO7GRYAZ4TUMO5VH2ZHLCNJZQ/
> ).
> This proposal suggests to accept this reality and build the i686
> packages in such a way that they require the ISA level of (early)
> x86-64 CPUs.


> == Scope ==
> * Proposal owners:
> Adjust the redhat-rpm-config, gcc, and glibc packages to switch to the
> new compiler flags. Except for mstackrealign, there is substantial
> experience with this configuration downstream.

> * Other developers:
> Other developers can enable SSE2 optimization in their packages if
> they want, where this has been a compile-time option only.

> * Release engineering:
> https://pagure.io/releng/issues/7543 #7543

> ** List of deliverables: TBD

> * Policies and guidelines:
> i686 is no longer a primary architecture. The Packaging Guidelines do
> not currently require support for non-SSE2 x86 systems, so no change
> is required there.

I think this change is fundamentally wrong.

If  you  have  the 64-bit capable hardware, should not the focus be on
the  X84-64  modules?   The 32-bit modules are targeted to an entirely
different audience, who have already decided to take a performance hit
by running in 32-bit mode.

Requiring  64-bit  hardware  to run the 32-bit modules does not simply
impact the i686 secondary architecture - it fundamentally breaks it.

I  don't see this change as being reasonable unless the i686 secondary
arch is going to get a full parallel build to support i686 hardware. I
don't see that happening either.

Al
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/X5MHFHEHQISB2YJBENM6JB3UUDPRJBSM/

Re: Hiding the grub menu by default on single OS installs

2018-06-04 Thread Vít Ondruch



Dne 1.6.2018 v 19:00 Jason L Tibbitts III napsal(a):
>> "TK" == Tomas Kovar  writes:
> TK> - this one is on the polish side of things:
> [don't keep bouncing to text mode]
>
> I might also add that as part of this, we'd also need to get rid of the
> very early message about EFI secure boot being enabled.  Then we'd be
> left only with the random kernel message spew that some machines have
> just before X starts up.  (For me it's usually something complaining
> about ACPI tables or somesuch.)

Good point, I see such messages + messages about high temperature and
throttling CPU every boot.

V.

 
>   But I'm sure Hans has already thought
> of all of that.
>
>  - J<
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GSXVCVYM2V7B43L6CXR26WPSM5TV3RWW/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B4H6S66BUBWP67BQJW55GXVWRLB27DT4/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Florian Weimer


On 06/04/2018 05:07 PM, Adam Jackson wrote:

On Mon, 2018-06-04 at 16:04 +0200, Florian Weimer wrote:


This proposal suggests to accept this reality and build the i686
packages in such a way that they require the ISA level of (early)
x86-64 CPUs.


On which x86 CPU families will Fedora continue to work?


Based on this proposed change, you will need an x86-64-capable CPU.


That's not how I read the proposal. No reason a P4 shouldn't work if
all you're requiring is SSE2+FXSR, right?


It will probably work, but it's more of a happy accident than a 
deliberate decision.  I would still suggest it if it were incompatible 
with Pentium 4 CPUs without x86-64 support.  (The fewer of these 
Netburst power guzzlers are running, the better, to be honest.)


Certainly, I don't see us jumping to long mode, doing the computation 
there, and jumping back, so it's hard to imagine that anything more than 
SSE2 (you need fxsr for SSE2 for the context switch AFAICS anyway) will 
be required by the i686 user space in the future.


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/T6TWR7E7DZK5YURPGNN26CD2S5T7YUZ6/

Re: F29 System Wide Change: Hide the grub menu

2018-06-04 Thread Vít Ondruch

Dne 1.6.2018 v 16:29 Ken Coar napsal(a):
> On 06/01/2018 05:06 AM, Vít Ondruch wrote:
>> It is irony, that people, who are capable to get into the grub menu if
>> they need, complain about it being hidden. So to say, I am 100% for
>> hiding the grub menu, speeding up the boot process, and if need it, I'll
>> find a way to get it.
> I fail to see any irony here.  When I need to get into the
> grub menu, it's usually an emergency (or at least highly-stressful)
> situation, with no documentation handy, and flailing about
> trying to figure out how to make it appear just adds to the
> stress and the blue tinge of the air in my vicinity.
>
> What *exactly* is this trying to solve?
>
> IIRC, the patch is to hide the grub menu IFF there's only one
> kernel because 'it serves no useful function.'  A number of
> people (myself included) have disputed that assertion.  If
> the assertion is invalid, the patch shouldn't be applied.
> Correct?  That seems simple enough.  Or maybe I don't understand
> the process, lacking sufficient Fedora-devel-fu karma.
>
> How many non-tech end users install Fedora straight
> from the distro, as opposed to those who install a frobbed
> version, with different defaults, from a repackager?
> _I.e._, repackagers can set grub up however they like.
>
> Is Fedora's goal to be end-user friendly, tech friendly, or
> the all-singing all-dancing Linux distro?

Talking from my experience running Rawhide on two my laptops for ~5
years, I really don't remember where I would really need to use older
kernel. If I had to, it was probably due to something like audio issues
with my docking station and that is hardly the situation you describe.

In my family, there are another 2 computers running Fedora. I don't
remember any kernel related issues. And if there were kernel issues,
explaining my sister that she should use older kernel would be similarly
difficult if the menu is displayed or not.

But the true is, that the computers are not using any proprietary
drivers, which might be issue.

V.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EUPTPHKWWMRBWLCN6KZTJCCQN6ZQ7GJF/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Adam Jackson

On Mon, 2018-06-04 at 16:04 +0200, Florian Weimer wrote:

> > > This proposal suggests to accept this reality and build the i686
> > > packages in such a way that they require the ISA level of (early)
> > > x86-64 CPUs.
> > 
> > On which x86 CPU families will Fedora continue to work?
> 
> Based on this proposed change, you will need an x86-64-capable CPU.

That's not how I read the proposal. No reason a P4 shouldn't work if
all you're requiring is SSE2+FXSR, right?

- ajax
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6OYP2FKS4ASPWQ4OAZFLPUXFDTNUUEGK/

Re: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Adam Jackson

On Mon, 2018-06-04 at 08:59 -0500, Ian Pilcher wrote:
> On 06/04/2018 04:28 AM, Florian Weimer wrote:
> > It should, because -march=x86-64 implies just SSE2 and FXSR, and Xeon MP 
> > supports both.  But the intent is what the subject says: i686 binaries 
> > are for running legacy software on x86-64 systems, and nothing more.
> 
> So the 32-bit x86 SIG would be required to rebuild all of the userspace
> packages to run on actual 32-bit hardware, right?  (What would those be
> called, since i686 is taken?)

No. The 32-bit ABI level being targeted here is basically the Pentium
4, which was a 32-bit part. On a P3 or older, yes, you'd need a
rebuild, but the P4 was 2001 so we're talking about hardware old enough
to vote here.

If we did want to allow for pre-P4 32-bit userspace, what I'd probably
do is (mostly) change %_libdir to /usr/lib/sse2 for i686, and leave it
as /usr/lib for a (reintroduced) i586 architecture.

- ajax
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5ZTMW77HAWOFQN3QTA2BJB7IYQXWRUQW/

Re: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Josh Boyer

On Mon, Jun 4, 2018 at 10:09 AM Ralf Corsepius  wrote:
>
> On 06/04/2018 11:28 AM, Florian Weimer wrote:
> > On 06/04/2018 10:50 AM, Guido Aulisi wrote:
>
> > It should, because -march=x86-64 implies just SSE2 and FXSR, and Xeon MP
> > supports both.  But the intent is what the subject says: i686 binaries
> > are for running legacy software on x86-64 systems, and nothing more.
>
> I do not agree with this sentiment all, as well as I can't deny finding
> your wording bewildering, because I think you actually are trying to say:
>
> - You (Florian) want to abandon the i686 architecture.
> - You (RH) want to play down the fact Fedora 28 is FUBARed on the PIII
> and instead of fixing the issues you want to kill it.

I'm going to be as clear as I possibly can here.  Red Hat, as a
company, is not going to put resources into fixing issues found on
Pentium III machines in Fedora, regardless of whether or not this
proposal passes.  There is an x86 SIG who was tasked with that kind of
activity.  The SIG should be fixing the issues it has responsibility
for.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JP7FTOLHV4M2ZCMBO7V7QKPSH3DTAAXR/

[Bug 1585352] perl-Locale-Codes-3.57 is available

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



--- Comment #5 from Fedora Update System  ---
perl-Locale-Codes-3.57-1.fc28 has been pushed to the Fedora 28 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-2018-b29cd0057d

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/AJQR2KHO7GYLJBYYJPNGFRWY5WKKFTDK/

[Bug 1585518] perl-Dist-Zilla-Plugin-GithubMeta-0.58 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Dist-Zilla-Plugin-GithubMeta-0.58-1.fc28 has been pushed to the Fedora 28
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-2018-21afd568f8

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/FUHBW4AJXCXRT6B6HBFH6ZQXVA27IZEX/

[Bug 1585175] perl-Log-Report-1.27 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Log-Report-1.27-1.fc28 has been pushed to the Fedora 28 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-2018-ad9da26b96

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/XMMGI3U2RMRMMTSWCW44YJ5CRPP6REXA/

[Bug 1582962] perl-Dist-Zilla-Plugin-GithubMeta-0.56 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Dist-Zilla-Plugin-GithubMeta-0.58-1.fc28 has been pushed to the Fedora 28
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-2018-21afd568f8

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/D3TEEV53APJ45UFBZCLHAOPZBLYTU4NO/

[Bug 1585179] perl-Perl-Critic-1.132 is available

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Perl-Critic-1.132-1.fc
   ||29
 Resolution|--- |RAWHIDE
Last Closed||2018-06-04 10:09:54



--- Comment #2 from Paul Howarth  ---
Build done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=27414775

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/CI5VDQCMDJV27ER4BMJXGDBJ56JL3HBY/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Florian Weimer


On 06/04/2018 02:39 PM, Alexander Ploumistos wrote:

== Detailed description ==
Currently, the i686 RPM packages are built in such a way that they are
compatible with very old i686 systems, such as the Pentium III.  The
only addition over the i686/Pentium Pro baseline is a requirement to
support long NOPs, for Intel CET.  However, the majority of
installations of i686 packages is for use on x86_64 systems, as
multi-lib RPMs.


Based on what data?


The mirror data I've seen, but it's really outdated at this point.


This proposal suggests to accept this reality and build the i686
packages in such a way that they require the ISA level of (early)
x86-64 CPUs.


On which x86 CPU families will Fedora continue to work?


Based on this proposed change, you will need an x86-64-capable CPU.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/6MNG7RWPR6DY6WZHI4SUAAF6VEAAENP4/

Re: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Ian Pilcher


On 06/04/2018 04:28 AM, Florian Weimer wrote:
It should, because -march=x86-64 implies just SSE2 and FXSR, and Xeon MP 
supports both.  But the intent is what the subject says: i686 binaries 
are for running legacy software on x86-64 systems, and nothing more.


So the 32-bit x86 SIG would be required to rebuild all of the userspace
packages to run on actual 32-bit hardware, right?  (What would those be
called, since i686 is taken?)

--

Ian Pilcher arequip...@gmail.com
 "I grew up before Mark Zuckerberg invented friendship" 

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WZMWAPNARRWXNJX5LOLUBJYDIOK2I7EU/

Re: CPAN Search Going Away

2018-06-04 Thread Petr Pisar

On Mon, Jun 04, 2018 at 01:53:07PM +0200, Petr Pisar wrote:
> On Thu, May 24, 2018 at 06:34:38PM +0200, Petr Pisar wrote:
> > I can mass update spec files for all Perl packages. I submitted this Fedora 
> > 29
> > change request 
> > 
> 
> The change was approved. I will start updating the packages soon.
> 
Finished.

The only remaining perl.spec will updated together Perl 5.28 upgrade next week
(not to impose git rebases on people uprading perl).

-- Petr


signature.asc
Description: PGP signature
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/A3VP2YDPHL7MEB5VZDVHA7BRICWAQJIF/

[Bug 1585352] perl-Locale-Codes-3.57 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Locale-Codes-3.57-1.fc27 has been pushed to the Fedora 27 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-2018-dfc9d42ae2

-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/NRMTENJQO7EUTP5ZXW3JHIYO4RGVNY24/

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

2018-06-04 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  57  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2c81054303   
remctl-3.14-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-860176245e   
gifsicle-1.91-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-48b823c3dc   
strongswan-5.6.2-6.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-90002f509e   
pdns-recursor-4.1.3-2.el7
   8  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-74ee3ae47e   
phpMyAdmin-4.4.15.10-3.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-65614e9fc9   
thunderbird-enigmail-2.0.6-1.el7
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-bbdc0ecf38   
cobbler-2.8.3-2.el7
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-297fb7f6c0   
chromium-66.0.3359.181-3.el7
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-7155fb2e51   
prosody-0.10.2-1.el7


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

odcs-0.2.4-1.el7
php-pear-crypt-gpg-1.6.3-1.el7
python-gitlab-1.3.0-3.el7.1
xfce4-taskmanager-1.2.1-1.el7

Details about builds:



 odcs-0.2.4-1.el7 (FEDORA-EPEL-2018-bf045176d7)
 The On Demand Compose Service

Update Information:

Update to new version 0.2.4.

ChangeLog:

* Mon Jun  4 2018 Jan Kaluza  - 0.2.4-1
- updated to new version 0.2.4




 php-pear-crypt-gpg-1.6.3-1.el7 (FEDORA-EPEL-2018-f4d2a2ea15)
 GNU Privacy Guard (GnuPG)

Update Information:

* Exclude tools/ and package.php from a composer archive. * Make possible to get
a list of GnuPG warnings collected on last operation. * Fix Bug pear#21242:
PHPUnit tests fail sometimes while deleting S.gpg-agent.extra. * Fix mode
argument type in docblock.

ChangeLog:

* Mon Jun  4 2018 Remi Collet  - 1.6.3-1
- update to 1.6.3




 python-gitlab-1.3.0-3.el7.1 (FEDORA-EPEL-2018-4619de4f36)
 Interact with GitLab API

Update Information:

First release

References:

  [ 1 ] Bug #1577217 - Review Request: python-gitlab -  Interact with GitLab API
https://bugzilla.redhat.com/show_bug.cgi?id=1577217




 xfce4-taskmanager-1.2.1-1.el7 (FEDORA-EPEL-2018-c09a26eb47)
 Taskmanager for the Xfce desktop environment

Update Information:

update to 1.2.1

ChangeLog:

* Sun Jun  3 2018 Mukundan Ragavan  - 1.2.1-1
- Update to 1.2.1
* Fri Feb  9 2018 Igor Gnatenko  - 1.2.0-5
- Escape macros in %changelog

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/ASUAYV6NSQSPWSXTXVHXO5XDIKR2SHOV/

[Bug 1585179] perl-Perl-Critic-1.132 is available

https://bugzilla.redhat.com/show_bug.cgi?id=1585179
Bug 1585179 depends on bug 1585587, which changed state.

Bug 1585587 Summary: Review Request: perl-PPIx-QuoteLike - Parse Perl string 
literals and string-literal-like things
https://bugzilla.redhat.com/show_bug.cgi?id=1585587

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |RAWHIDE



-- 
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
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/EOJ65YGFKRNQDESUA5LL2BUL2R5CBIUF/

Re: F29 System Wide Change: Perl Move to MetaCPAN

2018-06-04 Thread Petr Pisar

On 2018-06-04, Petr Pisar  wrote:
> On 2018-05-25, Jan Kurik  wrote:
>>= Proposed System Wide Change: Perl Move to MetaCPAN =
>> https://fedoraproject.org/wiki/Changes/Perl_Move_to_MetaCPAN
>>
> This change was approved and I will start updating the packages in a few
> moments.
>
> Each affected package will receive one commit with "cpan.org addresses
> moved to MetaCPAN
>" title.
> There won't be any Release number bump.
>
Done.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/A5LFUOUTUKIQB564SXSNKPPC5CYHHNPG/

Re: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Ralf Corsepius


On 06/04/2018 11:28 AM, Florian Weimer wrote:

On 06/04/2018 10:50 AM, Guido Aulisi wrote:


It should, because -march=x86-64 implies just SSE2 and FXSR, and Xeon MP 
supports both.  But the intent is what the subject says: i686 binaries 
are for running legacy software on x86-64 systems, and nothing more.


I do not agree with this sentiment all, as well as I can't deny finding 
your wording bewildering, because I think you actually are trying to say:


- You (Florian) want to abandon the i686 architecture.
- You (RH) want to play down the fact Fedora 28 is FUBARed on the PIII 
and instead of fixing the issues you want to kill it.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JBZVYP5F7XLNS4Q3KO5JNEUHOC5S3SIL/

Re: Change in Copr retention policy?

2018-06-04 Thread Miroslav Suchý

Dne 4.6.2018 v 10:03 Jan Pazdziora napsal(a):
> In any case, it'd be nice to notify the owners of those repos to give
> them chance to review what they have and potentially rebuild their
> content on newer buildroots, or just mark their repos "alive" and
> extend the expiration for another 180 days. Or something to that
> effect.

I like this idea.

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JCO5KN2BVBLHATMJ7GQHMYG7J5CGJ6PI/

ppisar pushed to perl-Types-Path-Tiny (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 13:16:58 UTC

From ae1817d41a6268fd739e6a5151f69782684753d8 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 13:16:55 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Types-Path-Tiny.spec b/perl-Types-Path-Tiny.spec
index 651506a..c09ef24 100644
--- a/perl-Types-Path-Tiny.spec
+++ b/perl-Types-Path-Tiny.spec
@@ -3,8 +3,8 @@ Version:0.006
 Release:1%{?dist}
 Summary:Path::Tiny types and coercions for Moose and Moo
 License:ASL 2.0
-URL:http://search.cpan.org/dist/Types-Path-Tiny/
-Source0:
http://www.cpan.org/authors/id/D/DA/DAGOLDEN/Types-Path-Tiny-%{version}.tar.gz
+URL:https://metacpan.org/release/Types-Path-Tiny
+Source0:
https://cpan.metacpan.org/authors/id/D/DA/DAGOLDEN/Types-Path-Tiny-%{version}.tar.gz
 
 BuildArch:  noarch
 



https://src.fedoraproject.org/rpms/perl-Types-Path-Tiny/c/ae1817d41a6268fd739e6a5151f69782684753d8?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/P56FGFGAVDIG7DT4K3ROWFJPE6VQXHD6/

ppisar pushed to perl-HTTP-MultiPartParser (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 13:16:42 UTC

From a7a206872ad9d104930033be13fd47bcce007894 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 13:16:39 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-HTTP-MultiPartParser.spec b/perl-HTTP-MultiPartParser.spec
index 9774fd4..271e57b 100644
--- a/perl-HTTP-MultiPartParser.spec
+++ b/perl-HTTP-MultiPartParser.spec
@@ -4,8 +4,8 @@ Release:4%{?dist}
 Summary:HTTP MultiPart Parser
 License:GPL+ or Artistic
 Group:  Development/Libraries
-URL:http://search.cpan.org/dist/HTTP-MultiPartParser/
-Source0:
http://www.cpan.org/authors/id/C/CH/CHANSEN/HTTP-MultiPartParser-%{version}.tar.gz
+URL:https://metacpan.org/release/HTTP-MultiPartParser
+Source0:
https://cpan.metacpan.org/authors/id/C/CH/CHANSEN/HTTP-MultiPartParser-%{version}.tar.gz
 
 BuildArch:  noarch
 BuildRequires:  perl-generators



https://src.fedoraproject.org/rpms/perl-HTTP-MultiPartParser/c/a7a206872ad9d104930033be13fd47bcce007894?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/V6VQKAUQDCH2XVHCSSOYIJVZPOWR7DJV/

Re: Hiding the grub menu by default on single OS installs

2018-06-04 Thread Hans de Goede


Hi,

On 04-06-18 09:16, Hans de Goede wrote:

Hi,

Note I've dropped the fedora-devel list (-ETOOMUCHBIKESHED)
and added Javier and Jan to the Cc.


Ugh, so clearly I failed to remove fedora-devel from the CC.

Ah well. I hope this mistake shows that there is nothing
nefarious going on here and that Javier, Peter and I are
really just working on trying making the boot experience
nicer for Workstation users, while at the same time very
thoroughly keeping in mind the rescue / things broke
scenario.

Regards,

Hans




On 01-06-18 20:03, Peter Jones wrote:

On Thu, May 31, 2018 at 05:47:36PM +0200, Hans de Goede wrote:

Hi,

On 31-05-18 15:20, Robert Marcano wrote:

On 05/31/2018 06:52 AM, Hans de Goede wrote:

...
This will basically get us back the F28 behavior of showing the
menu but only after a failed boot, I think that is a good
solution, do you agree?


What is the definition of a successful boot? I ask because a machine
could boot perfectly, and when you try to interact with it on the
login screen, bugs on the display driver can change the screen to
garbage (I have seen this kind on bug long time ago), or lockup. So,
the user will be unable to activate any kind of restart with menu
enabled in order to try an older kernel, or boot to rescue mode.

I think instead of only detecting a successful boot, a machine that
wasn't properly shutdown should enable the menu


A broken install may still shutdown properly after the using pressing
the power-button and/or trying ctrl+alt+del.

But this is an interesting suggestion, I think we should track both
separately, so successful shutdown and successful boot and show the
menu if either one is not true. That should make the chance of not
being able to get the menu a lot smaller.


In my mind, the mechanism here looks like what I've sketched out below,
and I think it encapsulates the above as well as most of what I've seen
on this thread already.

The workflow is something like this:

- user updates the OS[0]
   - we automatically set the new OS to be booted /once/.


Hmm, I see you also refer to atomic and there this makes sense, but
in the traditional distro model how would we implement this?

We could implement boot a new kernel once, but since a xserver /
mesa / gnome update might break things just as easily as a kernel
update can break things I'm not sure if adding boot-once functionality
to the traditional model is really helpful.

Reverting to the old kernel might help in some cases, but we are
also going to get false-positives. I've a feeling this is going to
become really messy. As such I don't think this is a change we
can "sell" easily. Some people really don't seem to like the idea of
any changes to the grub config / menu at all.

I've a feeling that selling the hidden menu by itself is enough
of a hassle without adding in booting a new kernel once to test it.
I realize that this in a way is a way to lessen the impact of the
menu being hidden, but I'm not 100% sold on this.

I would rather just show the menu after a failed boot and have
reverting to the kernel be a conscious choice of the user. I have
a number of reasons for this:

1) Don't revert to older kernel on false-positive failed boot detects
    (limit the result of a false-positive failed boot detect to showing
     the menu without any side

2) Updates typically come in batches and the boot failure may well be
    caused by something else, so we're not necessarily helping the user
    here, even if the user manages to fix things he will now be running
    an older kernel for no good reason.

3) Since reverting to the old kernel may not be enough, we still need
    to show the menu after a failed boot

4) Principle of least surprise, we are now making unrequested changes to
    the users system and not (really) notifying the user of this.
    For Atomic I envision that after switching back to the old snapshot /
    release the UI will show a dialog after login along the lines of:
    "The new 20190214 release did not work, we've reverted your machine
     to the 20190207 release" (but then better worded). We could do
    something similar for the kernel, assuming reverting to the old
    kernel will allow us to show the dialog, but we again have the whole
    false positive thing, so now we end up showing a scary dialog because
    of a false-positive failed-boot detect.

So all in all I'm not a big fan of the boot once concept for the
traditional Fedora version. I think it makes a lot of sense for Atomic
and we should do it there, but not for Fedora.

Another thing to keep in mind is that we don't really have much time
to get things in place for F29, so especially for F29 this seems
too complex and I would prefer to only add a "GRUB_AUTO_HIDE"
option to /etc/default/grub which when set will make grub2-mkconfig
generate a grub.cfg which will hides the menu unless a failed boot
is detected and not make any changes wrt which kernel to boot when.

This also has the added advantage that it

ppisar pushed to perl-Specio (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 13:10:19 UTC

From 2c0f3a05b46996643943a1c18bc49b43a3fc4336 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 13:10:17 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Specio.spec b/perl-Specio.spec
index 3f5a858..f2d6692 100644
--- a/perl-Specio.spec
+++ b/perl-Specio.spec
@@ -10,8 +10,8 @@ Version:  0.42
 Release:   2%{?dist}
 Summary:   Type constraints and coercions for Perl
 License:   Artistic 2.0
-URL:   http://search.cpan.org/dist/Specio/
-Source0:   
http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/Specio-%{version}.tar.gz
+URL:   https://metacpan.org/release/Specio
+Source0:   
https://cpan.metacpan.org/authors/id/D/DR/DROLSKY/Specio-%{version}.tar.gz
 BuildArch: noarch
 # Module Build
 BuildRequires: coreutils



https://src.fedoraproject.org/rpms/perl-Specio/c/2c0f3a05b46996643943a1c18bc49b43a3fc4336?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/DHHQ7S7IPBSK5YWWFOK7HVZTHF2FG2KJ/

ppisar pushed to perl-Module-Extract-Use (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 13:08:21 UTC

From 8d337ab05cbc19a92843e79d83b0dbecab0de1ac Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 13:08:19 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Module-Extract-Use.spec b/perl-Module-Extract-Use.spec
index e5fd287..7073a80 100644
--- a/perl-Module-Extract-Use.spec
+++ b/perl-Module-Extract-Use.spec
@@ -3,8 +3,8 @@ Name:   perl-Module-Extract-Use
 Version:   1.043
 Release:   5%{?dist}
 License:   Artistic 2.0
-URL:   http://search.cpan.org/dist/Module-Extract-Use/
-Source0:   
http://search.cpan.org/CPAN/authors/id/B/BD/BDFOY/Module-Extract-Use-%{version}.tar.gz
+URL:   https://metacpan.org/release/Module-Extract-Use
+Source0:   
https://cpan.metacpan.org/authors/id/B/BD/BDFOY/Module-Extract-Use-%{version}.tar.gz
 BuildArch: noarch
 # Module Build
 BuildRequires: coreutils



https://src.fedoraproject.org/rpms/perl-Module-Extract-Use/c/8d337ab05cbc19a92843e79d83b0dbecab0de1ac?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/L2737R3PDXMWUZASOGUET2VG6BL3YH4Q/

ppisar pushed to perl-MCE-Shared (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 13:07:24 UTC

From bc19e7ba29c58125b33cc5b4e3d8039130e0c932 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 13:07:22 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-MCE-Shared.spec b/perl-MCE-Shared.spec
index db765d0..b31acd4 100644
--- a/perl-MCE-Shared.spec
+++ b/perl-MCE-Shared.spec
@@ -3,8 +3,8 @@ Version:1.836
 Release:   1%{?dist}
 Summary:   MCE extension for sharing data, supporting threads and processes
 License:   GPL+ or Artistic
-URL:   http://search.cpan.org/dist/MCE-Shared/
-Source0:   
http://search.cpan.org/CPAN/authors/id/M/MA/MARIOROY/MCE-Shared-%{version}.tar.gz
+URL:   https://metacpan.org/release/MCE-Shared
+Source0:   
https://cpan.metacpan.org/authors/id/M/MA/MARIOROY/MCE-Shared-%{version}.tar.gz
 Patch0:MCE-Shared-1.831-Sereal-deps.patch
 BuildArch: noarch
 # Module Build



https://src.fedoraproject.org/rpms/perl-MCE-Shared/c/bc19e7ba29c58125b33cc5b4e3d8039130e0c932?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/JWVKYBIPGDHGZTEHYN3VDXJRJOTE7ZGT/

ppisar pushed to perl-Net-LDAP-SID (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 13:07:59 UTC

From 66b989437fdc456d90efc3d80aabf23ba5fd1989 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 13:07:57 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Net-LDAP-SID.spec b/perl-Net-LDAP-SID.spec
index c0c788b..73c47c8 100644
--- a/perl-Net-LDAP-SID.spec
+++ b/perl-Net-LDAP-SID.spec
@@ -3,8 +3,8 @@ Version:0.001
 Release:5%{?dist}
 Summary:Net::LDAP::SID Perl module
 License:Artistic 2.0
-URL:http://search.cpan.org/dist/Net-LDAP-SID/
-Source0:
http://www.cpan.org/authors/id/K/KA/KARMAN/Net-LDAP-SID-%{version}.tar.gz
+URL:https://metacpan.org/release/Net-LDAP-SID
+Source0:
https://cpan.metacpan.org/authors/id/K/KA/KARMAN/Net-LDAP-SID-%{version}.tar.gz
 BuildArch:  noarch
 
 BuildRequires:  perl-interpreter >= 0:5.008003



https://src.fedoraproject.org/rpms/perl-Net-LDAP-SID/c/66b989437fdc456d90efc3d80aabf23ba5fd1989?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/4NGOYKHFX33PLQIBIM2AXL7DU7VWX5TW/

ppisar pushed to perl-Ref-Util (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 13:05:29 UTC

From 6dd560a7ff0cd245e7bfb106bbc5ed972ceff2fb Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 13:05:27 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Ref-Util.spec b/perl-Ref-Util.spec
index 7f85838..4ae6f5d 100644
--- a/perl-Ref-Util.spec
+++ b/perl-Ref-Util.spec
@@ -10,8 +10,8 @@ Version:  0.204
 Release:   1%{?dist}
 Summary:   Utility functions for checking references
 License:   MIT
-URL:   http://search.cpan.org/dist/Ref-Util/
-Source0:   
http://search.cpan.org/CPAN/authors/id/A/AR/ARC/Ref-Util-%{version}.tar.gz
+URL:   https://metacpan.org/release/Ref-Util
+Source0:   
https://cpan.metacpan.org/authors/id/A/AR/ARC/Ref-Util-%{version}.tar.gz
 BuildArch: noarch
 # Build
 BuildRequires: coreutils



https://src.fedoraproject.org/rpms/perl-Ref-Util/c/6dd560a7ff0cd245e7bfb106bbc5ed972ceff2fb?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/CMOCZJW2MRJO567RIZQOEIK2ITORGC5C/

Ask for help with packaging of Pipenv deps

2018-06-04 Thread Michal Cyprian

Hi,

we added Pipenv, The higher level Python packaging tool [0], to Fedora recently.
It is a nice tool and it is also officially recommended from Python.org.
This is why we wanted to make it available to Fedora users as soon as possible.

The upstream Pipenv project contains a lot of bundled dependencies. Some of them
are not packaged for Fedora yet, so we were not able to unbundle them 
immediately.

The set of missing packages from PyPI is following:
* https://pypi.org/project/blindspin/
* https://pypi.org/project/delegator.py/
* https://pypi.org/project/first/
* https://pypi.org/project/pipreqs/
* https://pypi.org/project/pipdeptree/
* https://pypi.org/project/requirements-parser/
* https://pypi.org/project/shutilwhich/
* https://pypi.org/project/yarg/

In case you want to package some Python software for Fedora, we will appreciate 
your help.
Packages only for Python 3 version are needed. If you pick some of the 
packages, please respond
to this thread to prevent more packagers working on the same package. Also 
check if
the Review Request bug for the package doesn't exist already.
 
[0] https://src.fedoraproject.org/rpms/pipenv

Michal Cyprian
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/message/HJPSR4AUMJGKLST22YYU3FGMQPHMSKQM/

ppisar pushed to perl-Mail-Message (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 13:04:31 UTC

From a4f62f8ce92227c378677080fad359041a72a763 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 13:04:29 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Mail-Message.spec b/perl-Mail-Message.spec
index 2ccebc6..d730400 100644
--- a/perl-Mail-Message.spec
+++ b/perl-Mail-Message.spec
@@ -4,8 +4,8 @@ Release:2%{?dist}
 Summary:   MIME message handling
 Group: Development/Libraries
 License:   GPL+ or Artistic
-URL:   http://search.cpan.org/dist/Mail-Message/
-Source0:   
http://search.cpan.org/CPAN/authors/id/M/MA/MARKOV/Mail-Message-%{version}.tar.gz
+URL:   https://metacpan.org/release/Mail-Message
+Source0:   
https://cpan.metacpan.org/authors/id/M/MA/MARKOV/Mail-Message-%{version}.tar.gz
 BuildRequires: perl-generators
 BuildRequires: perl-interpreter
 BuildRequires: perl(base)



https://src.fedoraproject.org/rpms/perl-Mail-Message/c/a4f62f8ce92227c378677080fad359041a72a763?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/YZAO4DSG7L6U2D5XOIZCPCMGGDY2XF4V/

ppisar pushed to perl-IO-FDPass (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 12:54:49 UTC

From 59f2aa14a5a296720914ba8b57e99c39fe80c536 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:54:46 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-IO-FDPass.spec b/perl-IO-FDPass.spec
index 437ba67..d86b57e 100644
--- a/perl-IO-FDPass.spec
+++ b/perl-IO-FDPass.spec
@@ -3,7 +3,7 @@ Version:1.2
 Release:   6%{?dist}
 Summary:   Pass a file descriptor over a socket
 License:   GPL+ or Artistic
-URL:   http://search.cpan.org/dist/IO-FDPass/
+URL:   https://metacpan.org/release/IO-FDPass
 Source0:   
https://cpan.metacpan.org/authors/id/M/ML/MLEHMANN/IO-FDPass-%{version}.tar.gz
 # Module Build
 BuildRequires: coreutils



https://src.fedoraproject.org/rpms/perl-IO-FDPass/c/59f2aa14a5a296720914ba8b57e99c39fe80c536?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/YAM3THTYBRAS457KV5MKPA452732S76O/

ppisar pushed to perl-Sub-Infix (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 12:55:01 UTC

From a450bacd0aa8e1a0253c9579d7e09b06c897191c Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:54:58 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Sub-Infix.spec b/perl-Sub-Infix.spec
index 461d650..26163ef 100644
--- a/perl-Sub-Infix.spec
+++ b/perl-Sub-Infix.spec
@@ -3,8 +3,8 @@ Version:0.004
 Release:4%{?dist}
 Summary:Create a fake infix operator
 License:GPL+ or Artistic
-URL:http://search.cpan.org/dist/Sub-Infix/
-Source0:
http://www.cpan.org/authors/id/T/TO/TOBYINK/Sub-Infix-%{version}.tar.gz
+URL:https://metacpan.org/release/Sub-Infix
+Source0:
https://cpan.metacpan.org/authors/id/T/TO/TOBYINK/Sub-Infix-%{version}.tar.gz
 BuildArch:  noarch
 
 BuildRequires:  %{__perl}



https://src.fedoraproject.org/rpms/perl-Sub-Infix/c/a450bacd0aa8e1a0253c9579d7e09b06c897191c?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/TAQDPLYODRBTJ3EUCCHTHAG4TYCO2QGB/

ppisar pushed to perl-Type-Tie (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 12:51:31 UTC

From 68c41f461a7e173ddbf7846ffc3b0d92f81831f7 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:51:29 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Type-Tie.spec b/perl-Type-Tie.spec
index 2ecbe72..a61c4ab 100644
--- a/perl-Type-Tie.spec
+++ b/perl-Type-Tie.spec
@@ -4,8 +4,8 @@ Release:6%{?dist}
 Summary:Tie a variable to a type constraint
 # cf. README
 License:GPL+ or Artistic
-URL:http://search.cpan.org/dist/Type-Tie/
-Source0:
http://www.cpan.org/authors/id/T/TO/TOBYINK/Type-Tie-%{version}.tar.gz
+URL:https://metacpan.org/release/Type-Tie
+Source0:
https://cpan.metacpan.org/authors/id/T/TO/TOBYINK/Type-Tie-%{version}.tar.gz
 BuildArch:  noarch
 
 BuildRequires:  %{__perl}



https://src.fedoraproject.org/rpms/perl-Type-Tie/c/68c41f461a7e173ddbf7846ffc3b0d92f81831f7?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/EYGSB2IHP2XSIFYSGM7FQPWLMWLOQVMZ/

ppisar pushed to perl-Return-Type (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 12:48:54 UTC

From 09616976992a0b2edfda915808f7fca661e5e300 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:48:52 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Return-Type.spec b/perl-Return-Type.spec
index 39903cf..de4b1e4 100644
--- a/perl-Return-Type.spec
+++ b/perl-Return-Type.spec
@@ -3,8 +3,8 @@ Version:0.005
 Release:4%{?dist}
 Summary:Specify a return type for a function
 License:GPL+ or Artistic
-URL:http://search.cpan.org/dist/Return-Type/
-Source0:
http://www.cpan.org/authors/id/T/TO/TOBYINK/Return-Type-%{version}.tar.gz
+URL:https://metacpan.org/release/Return-Type
+Source0:
https://cpan.metacpan.org/authors/id/T/TO/TOBYINK/Return-Type-%{version}.tar.gz
 BuildArch:  noarch
 
 BuildRequires:  %{__perl}



https://src.fedoraproject.org/rpms/perl-Return-Type/c/09616976992a0b2edfda915808f7fca661e5e300?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/OEP4IW2BWYQCSRBTERPIK3E64J25W3DR/

ppisar pushed to perl-WWW-Form-UrlEncoded (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 12:47:11 UTC

From 774598f9ab96efe6c893aa74e4dbf4e050955979 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:47:09 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-WWW-Form-UrlEncoded.spec b/perl-WWW-Form-UrlEncoded.spec
index 6c55585..f12c86c 100644
--- a/perl-WWW-Form-UrlEncoded.spec
+++ b/perl-WWW-Form-UrlEncoded.spec
@@ -3,8 +3,8 @@ Version:0.24
 Release:4%{?dist}
 Summary:Parser and builder for application/x-www-form-urlencoded
 License:GPL+ or Artistic
-URL:http://search.cpan.org/dist/WWW-Form-UrlEncoded/
-Source0:
http://www.cpan.org/authors/id/K/KA/KAZEBURO/WWW-Form-UrlEncoded-%{version}.tar.gz
+URL:https://metacpan.org/release/WWW-Form-UrlEncoded
+Source0:
https://cpan.metacpan.org/authors/id/K/KA/KAZEBURO/WWW-Form-UrlEncoded-%{version}.tar.gz
 
 # HACK: Do not install noarch files into arched dirs.
 Patch0: WWW-Form-UrlEncoded-0.23-arch.patch



https://src.fedoraproject.org/rpms/perl-WWW-Form-UrlEncoded/c/774598f9ab96efe6c893aa74e4dbf4e050955979?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/5EVXPJMJW6PPYRMCFVMDS25AVEEH5DJZ/

ppisar pushed to perl-Code-TidyAll-Plugin-Test-Vars (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 12:46:09 UTC

From f50a3d4709d6c33eb3e6518dfff548bbd0f1513a Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:46:07 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Code-TidyAll-Plugin-Test-Vars.spec 
b/perl-Code-TidyAll-Plugin-Test-Vars.spec
index bcd10c3..ddb2888 100644
--- a/perl-Code-TidyAll-Plugin-Test-Vars.spec
+++ b/perl-Code-TidyAll-Plugin-Test-Vars.spec
@@ -3,8 +3,8 @@ Version:0.04
 Release:5%{?dist}
 Summary:Provides Test::Vars plugin for Code::TidyAll
 License:GPL+ or Artistic
-URL:http://search.cpan.org/dist/Code-TidyAll-Plugin-Test-Vars/
-Source0:
http://search.cpan.org/CPAN/authors/id/M/MA/MAXMIND/Code-TidyAll-Plugin-Test-Vars-%{version}.tar.gz
+URL:https://metacpan.org/release/Code-TidyAll-Plugin-Test-Vars
+Source0:
https://cpan.metacpan.org/authors/id/M/MA/MAXMIND/Code-TidyAll-Plugin-Test-Vars-%{version}.tar.gz
 BuildArch:  noarch
 BuildRequires:  perl-interpreter >= 0:5.006
 BuildRequires:  perl-generators



https://src.fedoraproject.org/rpms/perl-Code-TidyAll-Plugin-Test-Vars/c/f50a3d4709d6c33eb3e6518dfff548bbd0f1513a?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/ZNM6UOBIVAZR2PEOTA3V6ZBX36TOIZW7/

ppisar pushed to perl-Net-LDAP-Server (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 12:45:48 UTC

From 526f506fd74fe541fa9c8d2681da769bfbeec58a Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:45:45 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Net-LDAP-Server.spec b/perl-Net-LDAP-Server.spec
index 10c261c..24f05e1 100644
--- a/perl-Net-LDAP-Server.spec
+++ b/perl-Net-LDAP-Server.spec
@@ -3,8 +3,8 @@ Version:0.43
 Release:6%{?dist}
 Summary:Net::LDAP::Server Perl module
 License:GPL+ or Artistic
-URL:http://search.cpan.org/dist/Net-LDAP-Server/
-Source0:
http://www.cpan.org/authors/id/A/AA/AAR/Net-LDAP-Server-%{version}.tar.gz
+URL:https://metacpan.org/release/Net-LDAP-Server
+Source0:
https://cpan.metacpan.org/authors/id/A/AA/AAR/Net-LDAP-Server-%{version}.tar.gz
 BuildArch:  noarch
 
 BuildRequires:  perl-interpreter



https://src.fedoraproject.org/rpms/perl-Net-LDAP-Server/c/526f506fd74fe541fa9c8d2681da769bfbeec58a?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/5ANBXAEAPS4A6RF5W4QYET3UXRHZPFP4/

ppisar pushed to perl-Encode-IMAPUTF7 (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 12:43:50 UTC

From f3edab4c7d0a0f9dde15dccf4b9b16136669d1f8 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:43:47 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
index dc7f660..bed6b4b 100644
--- a/perl-Encode-IMAPUTF7.spec
+++ b/perl-Encode-IMAPUTF7.spec
@@ -5,8 +5,8 @@ Version:1.05
 Release:6%{?dist}
 Summary:Process the special UTF-7 variant required by IMAP
 License:GPL+ or Artistic
-URL:http://search.cpan.org/dist/Encode-IMAPUTF7/
-Source0:
http://www.cpan.org/authors/id/P/PM/PMAKHOLM/Encode-IMAPUTF7-%{version}.tar.gz
+URL:https://metacpan.org/release/Encode-IMAPUTF7
+Source0:
https://cpan.metacpan.org/authors/id/P/PM/PMAKHOLM/Encode-IMAPUTF7-%{version}.tar.gz
 BuildArch:  noarch
 
 BuildRequires:  make perl-interpreter perl-generators



https://src.fedoraproject.org/rpms/perl-Encode-IMAPUTF7/c/f3edab4c7d0a0f9dde15dccf4b9b16136669d1f8?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/BXTBVDOV3IYLOHH5PPOBPZXXMOI7OLEB/

ppisar pushed to perl-Cookie-Baker (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 12:42:42 UTC

From f07cf7651c417df5e71030bbf645f1248b93d6a4 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:42:40 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Cookie-Baker.spec b/perl-Cookie-Baker.spec
index f32376b..0436c84 100644
--- a/perl-Cookie-Baker.spec
+++ b/perl-Cookie-Baker.spec
@@ -3,8 +3,8 @@ Version:0.09
 Release:1%{?dist}
 Summary:Cookie string generator / parser
 License:GPL+ or Artistic
-URL:http://search.cpan.org/dist/Cookie-Baker/
-Source0:
http://www.cpan.org/authors/id/K/KA/KAZEBURO/Cookie-Baker-%{version}.tar.gz
+URL:https://metacpan.org/release/Cookie-Baker
+Source0:
https://cpan.metacpan.org/authors/id/K/KA/KAZEBURO/Cookie-Baker-%{version}.tar.gz
 BuildArch:  noarch
 
 BuildRequires:  %{__perl}



https://src.fedoraproject.org/rpms/perl-Cookie-Baker/c/f07cf7651c417df5e71030bbf645f1248b93d6a4?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/I5HHAOJFWYCUAJXFTQB762PEOSC5ATN4/

Re: [X86] Fwd: F29 System Wide Change: i686 Is For x86-64

2018-06-04 Thread Alexander Ploumistos

> == Detailed description ==
> Currently, the i686 RPM packages are built in such a way that they are
> compatible with very old i686 systems, such as the Pentium III.  The
> only addition over the i686/Pentium Pro baseline is a requirement to
> support long NOPs, for Intel CET.  However, the majority of
> installations of i686 packages is for use on x86_64 systems, as
> multi-lib RPMs.

Based on what data?

>  Furthermore, there are reports that the i686 kernel
> does not run stable on old hardware which is not x86-64-capable (
> https://lists.fedoraproject.org/archives/list/x...@lists.fedoraproject.org/thread/ZHV6I4IEO7GRYAZ4TUMO5VH2ZHLCNJZQ/
> ).

On some, not all.

> This proposal suggests to accept this reality and build the i686
> packages in such a way that they require the ISA level of (early)
> x86-64 CPUs.

On which x86 CPU families will Fedora continue to work?
I think this change should have been discussed on the x86 SIG mailing
list first, as it essentially goes against what the SIG had been
trying to do and deprives it of its purpose.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/E2S74E7LIFWK65N2V6XHCPGUXD2LTCRF/

ppisar pushed to perl-List-MoreUtils-XS (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 12:37:28 UTC

From da9ad3dd3d1ba22a65265be3c7f6d7fbf5a9c662 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:37:25 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-List-MoreUtils-XS.spec b/perl-List-MoreUtils-XS.spec
index bcc2d2f..07c14ed 100644
--- a/perl-List-MoreUtils-XS.spec
+++ b/perl-List-MoreUtils-XS.spec
@@ -7,8 +7,8 @@ Summary:Provide compiled List::MoreUtils functions
 # "git blame" on the upstream repo will probably be needed to
 # determine the license of any particular chunk of code
 License:   (GPL+ or Artistic) and ASL 2.0
-URL:   http://search.cpan.org/dist/List-MoreUtils-XS/
-Source0:   
http://search.cpan.org/CPAN/authors/id/R/RE/REHSACK/List-MoreUtils-XS-%{version}.tar.gz
+URL:   https://metacpan.org/release/List-MoreUtils-XS
+Source0:   
https://cpan.metacpan.org/authors/id/R/RE/REHSACK/List-MoreUtils-XS-%{version}.tar.gz
 Patch0:List-MoreUtils-XS-0.428-unbundle.patch
 # Module Build
 BuildRequires: coreutils



https://src.fedoraproject.org/rpms/perl-List-MoreUtils-XS/c/da9ad3dd3d1ba22a65265be3c7f6d7fbf5a9c662?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/7K2WOBF2B3FUYKKAGJ2VZNTJZDUDOK3R/

ppisar pushed to perl-Class-Std-Fast (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 12:37:27 UTC

From 2905bacaa9ff10b900b5597165183e1670482b78 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:37:24 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Class-Std-Fast.spec b/perl-Class-Std-Fast.spec
index d0b6199..b9618ff 100644
--- a/perl-Class-Std-Fast.spec
+++ b/perl-Class-Std-Fast.spec
@@ -4,8 +4,8 @@ Release:6%{?dist}
 Summary:Faster but less secure replacement for Class::Std
 License:GPL+ or Artistic
 Group:  Development/Libraries
-URL:http://search.cpan.org/dist/Class-Std-Fast/
-Source0:
http://www.cpan.org/authors/id/A/AC/ACID/Class-Std-Fast-v%{version}.tar.gz
+URL:https://metacpan.org/release/Class-Std-Fast
+Source0:
https://cpan.metacpan.org/authors/id/A/AC/ACID/Class-Std-Fast-v%{version}.tar.gz
 # Based on the statement in the README file:
 # "This library is free software; you can redistribute it and/or modify
 # it under the same terms as Perl itself."



https://src.fedoraproject.org/rpms/perl-Class-Std-Fast/c/2905bacaa9ff10b900b5597165183e1670482b78?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/INAYZK5H2OZ3ZJA2KIJS6PW3PCOINNRD/

ppisar pushed to perl-Validation-Class (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 12:37:09 UTC

From be063ebf36a2c63eee9442d41da989a427e77872 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:37:07 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Validation-Class.spec b/perl-Validation-Class.spec
index 73f86ec..14538a7 100644
--- a/perl-Validation-Class.spec
+++ b/perl-Validation-Class.spec
@@ -3,8 +3,8 @@ Version:7.900057
 Release:5%{?dist}
 Summary:Powerful Data Validation Framework
 License:GPL+ or Artistic
-URL:http://search.cpan.org/dist/Validation-Class/
-Source0:
http://www.cpan.org/authors/id/A/AW/AWNCORP/Validation-Class-%{version}.tar.gz
+URL:https://metacpan.org/release/Validation-Class
+Source0:
https://cpan.metacpan.org/authors/id/A/AW/AWNCORP/Validation-Class-%{version}.tar.gz
 BuildArch:  noarch
 
 BuildRequires:  %{__perl}



https://src.fedoraproject.org/rpms/perl-Validation-Class/c/be063ebf36a2c63eee9442d41da989a427e77872?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/QAAVW337NRUO4OYRQCRS4U2IXHHUOFBR/

ppisar pushed to perl-namespace-sweep (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 12:31:12 UTC

From 8fa32462b569ac2aba0ff7f754567fc88c88b19e Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:31:10 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-namespace-sweep.spec b/perl-namespace-sweep.spec
index 039a238..36fe176 100644
--- a/perl-namespace-sweep.spec
+++ b/perl-namespace-sweep.spec
@@ -3,8 +3,8 @@ Version:0.006
 Release:4%{?dist}
 Summary:Sweep up imported subs in your classes
 License:GPL+ or Artistic
-URL:http://search.cpan.org/dist/namespace-sweep/
-Source0:
http://www.cpan.org/authors/id/F/FR/FRIEDO/namespace-sweep-%{version}.tar.gz
+URL:https://metacpan.org/release/namespace-sweep
+Source0:
https://cpan.metacpan.org/authors/id/F/FR/FRIEDO/namespace-sweep-%{version}.tar.gz
 BuildArch:  noarch
 
 BuildRequires:  %{__perl}



https://src.fedoraproject.org/rpms/perl-namespace-sweep/c/8fa32462b569ac2aba0ff7f754567fc88c88b19e?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/6CJP2ANDUP5JPKQQSY6T2G6CPQVEYVW3/

ppisar pushed to perl-Net-LDAP-Server-Test (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 12:29:38 UTC

From dd9337cfeaa78e1732877be68b13394be62a2005 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:29:36 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Net-LDAP-Server-Test.spec b/perl-Net-LDAP-Server-Test.spec
index 6086340..6c8df88 100644
--- a/perl-Net-LDAP-Server-Test.spec
+++ b/perl-Net-LDAP-Server-Test.spec
@@ -4,8 +4,8 @@ Release:5%{?dist}
 Summary:Test Net::LDAP code
 License:GPL+ or Artistic
 Group:  Development/Libraries
-URL:http://search.cpan.org/dist/Net-LDAP-Server-Test/
-Source0:
http://www.cpan.org/authors/id/K/KA/KARMAN/Net-LDAP-Server-Test-%{version}.tar.gz
+URL:https://metacpan.org/release/Net-LDAP-Server-Test
+Source0:
https://cpan.metacpan.org/authors/id/K/KA/KARMAN/Net-LDAP-Server-Test-%{version}.tar.gz
 BuildArch:  noarch
 BuildRequires:  perl-interpreter >= 0:5.008003
 



https://src.fedoraproject.org/rpms/perl-Net-LDAP-Server-Test/c/dd9337cfeaa78e1732877be68b13394be62a2005?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/ITHZMTUQ66DHB42XA4FYBDVHO7B6V4VW/

ppisar pushed to perl-DateTime-Calendar-Julian (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 12:24:02 UTC

From f9ff2be4bdc4bf683364e2ee345316fd1e3e2530 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:24:00 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-DateTime-Calendar-Julian.spec 
b/perl-DateTime-Calendar-Julian.spec
index f3b4434..654abb3 100644
--- a/perl-DateTime-Calendar-Julian.spec
+++ b/perl-DateTime-Calendar-Julian.spec
@@ -4,8 +4,8 @@ Release:8%{?dist}
 License:   GPL+ or Artistic 
 Group: Development/Libraries
 Summary:   Julian Calendar support for DateTime.pm 
-Url:   http://search.cpan.org/dist/DateTime-Calendar-Julian
-Source:
http://search.cpan.org/CPAN/authors/id/P/PI/PIJLL/DateTime-Calendar-Julian-%{version}.tar.gz
+Url:   https://metacpan.org/release/DateTime-Calendar-Julian
+Source:
https://cpan.metacpan.org/authors/id/P/PI/PIJLL/DateTime-Calendar-Julian-%{version}.tar.gz
 BuildArch: noarch
 BuildRequires: perl-generators, perl-interpreter, coreutils, findutils, make
 BuildRequires: perl(DateTime) >= 0.15



https://src.fedoraproject.org/rpms/perl-DateTime-Calendar-Julian/c/f9ff2be4bdc4bf683364e2ee345316fd1e3e2530?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/6U6WZFGWOUK5OGPOUFWKLPKEUF26GTUI/

Re: Nonresponsive maintainer: guidograzioli

2018-06-04 Thread Till Hofmann



On 06/04/2018 10:14 AM, Till Hofmann wrote:
> Hi all,
> 
> I'm trying to get in contact with Guido Graizoli (FAS guidograzioli). He
> has not responded to a bug report requesting an update of bibtex2html
> [1]. The package is currently also FTBFS [2], where he did not respond
> either. I also tried contacting him privately by e-mail, but I did not
> get a response.

I reached Guido through his private e-mail. He'll reassign/orphan some
of his packages and take care of the rest.

Kind regards,
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MUWMT2SCNSNPG2EMZ6B6OBNBGXRHDHB3/

ppisar pushed to perl-Test2-Plugin-NoWarnings (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 12:21:15 UTC

From 707df564df74c29247704e497b2aac5e7ed8d358 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:21:12 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Test2-Plugin-NoWarnings.spec 
b/perl-Test2-Plugin-NoWarnings.spec
index e7699bb..024e6cc 100644
--- a/perl-Test2-Plugin-NoWarnings.spec
+++ b/perl-Test2-Plugin-NoWarnings.spec
@@ -3,8 +3,8 @@ Version:0.06
 Release:   3%{?dist}
 Summary:   Fail if tests warn
 License:   Artistic 2.0
-URL:   http://search.cpan.org/dist/Test2-Plugin-NoWarnings/
-Source0:   
http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/Test2-Plugin-NoWarnings-%{version}.tar.gz
+URL:   https://metacpan.org/release/Test2-Plugin-NoWarnings
+Source0:   
https://cpan.metacpan.org/authors/id/D/DR/DROLSKY/Test2-Plugin-NoWarnings-%{version}.tar.gz
 BuildArch: noarch
 # Build
 BuildRequires: coreutils



https://src.fedoraproject.org/rpms/perl-Test2-Plugin-NoWarnings/c/707df564df74c29247704e497b2aac5e7ed8d358?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/TDBCYKALHKWQQOPQFO3OLJJJYE56EFZB/

ppisar pushed to perl-Ref-Util-XS (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 12:20:03 UTC

From be980a5a1d20bdd94abe24e879397548a2bb0302 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:20:01 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Ref-Util-XS.spec b/perl-Ref-Util-XS.spec
index cec7511..2c92e86 100644
--- a/perl-Ref-Util-XS.spec
+++ b/perl-Ref-Util-XS.spec
@@ -10,8 +10,8 @@ Version:  0.117
 Release:   2%{?dist}
 Summary:   Utility functions for checking references
 License:   MIT
-URL:   http://search.cpan.org/dist/Ref-Util-XS/
-Source0:   
http://search.cpan.org/CPAN/authors/id/X/XS/XSAWYERX/Ref-Util-XS-%{version}.tar.gz
+URL:   https://metacpan.org/release/Ref-Util-XS
+Source0:   
https://cpan.metacpan.org/authors/id/X/XS/XSAWYERX/Ref-Util-XS-%{version}.tar.gz
 # Build
 BuildRequires: coreutils
 BuildRequires: findutils



https://src.fedoraproject.org/rpms/perl-Ref-Util-XS/c/be980a5a1d20bdd94abe24e879397548a2bb0302?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/ZR7MKTG4FB32NS4OEDCDQ5NJ6WHFF7TQ/

ppisar pushed to perl-Params-ValidationCompiler (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 12:18:53 UTC

From 2dc52d32eb22341abb0910bb4b613f628b46de53 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:18:51 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Params-ValidationCompiler.spec 
b/perl-Params-ValidationCompiler.spec
index a012906..b461c33 100644
--- a/perl-Params-ValidationCompiler.spec
+++ b/perl-Params-ValidationCompiler.spec
@@ -10,8 +10,8 @@ Version:  0.27
 Release:   1%{?dist}
 Summary:   Build an optimized subroutine parameter validator once, use it 
forever
 License:   Artistic 2.0
-URL:   http://search.cpan.org/dist/Params-ValidationCompiler/
-Source0:   
http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/Params-ValidationCompiler-%{version}.tar.gz
+URL:   https://metacpan.org/release/Params-ValidationCompiler
+Source0:   
https://cpan.metacpan.org/authors/id/D/DR/DROLSKY/Params-ValidationCompiler-%{version}.tar.gz
 BuildArch: noarch
 # Build
 BuildRequires: coreutils



https://src.fedoraproject.org/rpms/perl-Params-ValidationCompiler/c/2dc52d32eb22341abb0910bb4b613f628b46de53?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/XPUN3KQWH6XNN77ZKRWE2RNHJOMFZOMH/

ppisar pushed to perl-Crypt-IDEA (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 12:17:16 UTC

From 11ba8e64ec05c0926d15170ad556c4d98efe9abd Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:17:14 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Crypt-IDEA.spec b/perl-Crypt-IDEA.spec
index 6e34701..9e98fa7 100644
--- a/perl-Crypt-IDEA.spec
+++ b/perl-Crypt-IDEA.spec
@@ -3,8 +3,8 @@ Name:   perl-Crypt-IDEA
 Version:   1.10
 Release:   11%{?dist}
 License:   BSD with advertising
-Url:   http://search.cpan.org/dist/Crypt-IDEA/
-Source0:   
http://search.cpan.org/CPAN/authors/id/D/DP/DPARIS/Crypt-IDEA-%{version}.tar.gz
+Url:   https://metacpan.org/release/Crypt-IDEA
+Source0:   
https://cpan.metacpan.org/authors/id/D/DP/DPARIS/Crypt-IDEA-%{version}.tar.gz
 # Build
 BuildRequires: coreutils
 BuildRequires: findutils



https://src.fedoraproject.org/rpms/perl-Crypt-IDEA/c/11ba8e64ec05c0926d15170ad556c4d98efe9abd?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/C7RT2GDUQVBOB6LZH6RKUPGQQEJUWEJC/

ppisar pushed to perl-Mock-Config (master). "cpan.org addresses moved to MetaCPAN "

Notification time stamped 2018-06-04 12:15:32 UTC

From 19c07c3f5f446721fb69b5e8dd45a3779f1a9772 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Jun 04 2018 12:15:29 +
Subject: cpan.org addresses moved to MetaCPAN 



---

diff --git a/perl-Mock-Config.spec b/perl-Mock-Config.spec
index 45bdf7f..bc21e45 100644
--- a/perl-Mock-Config.spec
+++ b/perl-Mock-Config.spec
@@ -3,8 +3,8 @@ Version:0.03
 Release:4%{?dist}
 Summary:Temporarily set Config or XSConfig values
 License:Artistic 2.0
-URL:http://search.cpan.org/dist/Mock-Config/
-Source0:
http://www.cpan.org/authors/id/R/RU/RURBAN/Mock-Config-%{version}.tar.gz
+URL:https://metacpan.org/release/Mock-Config
+Source0:
https://cpan.metacpan.org/authors/id/R/RU/RURBAN/Mock-Config-%{version}.tar.gz
 BuildArch:  noarch
 # Build
 BuildRequires:  make



https://src.fedoraproject.org/rpms/perl-Mock-Config/c/19c07c3f5f446721fb69b5e8dd45a3779f1a9772?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/XDPVLGWAWB6CHRAGFEGPJGJZKTX6MIFF/

ppisar pushed to perl-Mail-Transport (master). "cpan.org addresses moved to MetaCPAN "