[EPEL-devel] How to retire/delete an EPEL branch?

[Ding Yi Chen]

I received a bug[1] asking to remove EPEL7 branch, as the package
LibRaw, is already in RHEL.

How should I do that?

Regards,


1. https://bugzilla.redhat.com/show_bug.cgi?id=1526701
-- 
Ding-Yi CHEN

Software Engineer, Globalization Group
Red Hat Asia-Pacific Pty Ltd
dc...@redhat.com
Twitter: @redhatway | Instagram: @redhatinc | Snapchat: @redhatsnaps 
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: rpcgen?

[Florian Weimer]

On 01/10/2018 04:20 AM, Ian Kent wrote:


Note that the plan is that the new package will provide rpcgen, so you can just 
use

BuildRequires: rpcgen

and you'll get the new package once it becomes available.


What can I do in the meantime to build autofs in Rawhide?


You can use rpcgen today, it's provided by glibc-rpcgen, but the package 
providing it will change.


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

[389-devel] Do aci's work in nested groups?

[William Brown]

If I have:

(targetattr=x)(version 3.0;  allow(read, search)(groupdn=cn=x);)

If cn=x has member cn=y, and cn=y member uid=z

Does uid=z have permission to the targetattr here? IE do our aci's work
through nested groups? 



-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

ISC DHCP license change notificcation

[Pavel Zhukov]

Hello,
Internet Systems Consortium, has changed license of DHCP from ISC to
MPL 2.0 [1] since 4.4.0 (which will land rawhide soon).

[1] https://www.isc.org/blogs/isc-dhcp-moves-to-mpl-2-0-license/

--
Pavel Zhukov
Software Engineer
IRC: landgraf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] Re: Improve the demo objects from install

[Alisha Aneja]

I think I agree with William, since the world is diverse and I don't think
we can cater to *everyone*.

On Wed, Jan 10, 2018 at 3:44 PM, William Brown  wrote:

> On Wed, 2018-01-10 at 04:26 +, Máirín Duffy wrote:
> > Hi William,
> >
> > I'm one of the Fedora UX designers and was pointed to this thread by
> > charcol on another list.
> >
> > I would like to express enthusiastic support for having by default a
> > display name field and a legal name field. This is of particular
> > benefit and interest to women as you clearly recognize. My legal name
> > is not what people know me by yet it's important for various gov't
> > docs that my legal name be used. In most contexts the name I go by is
> > more appropriate and recognizable for everyone. Red Hat allows me as
> > an employee to choose a displayname for my first name but not my last
> > - my legal last name is not what I go by. This has definitely caused
> > me some serious real world challenges.
>
> Thanks! I'm glad to see that this idea is supported. I have always
> wanted to improve this, and this seems like a great time to achieve it.
>
> >
> > One question I have about having multiple names in one field, from a
> > UX designer POV - often when retrieving lists of names for display in
> > interfaces, in a Western context they are often listed lastname
> > firstname in alphaorder. If the field is freeform and the person
> > inputs first middle last or even more names, how can the lastname be
> > identified so that a given user can be located in an alphabetically
> > ordered list?
>
> You can sort on displayname, but that's about it - The challenge get's
> worse in this case.
>
> firstname lastname
> singlename
> firstname familyname1 familyname2
> firstname middlename lastname
>
> Which do we sort on? I know in spain they have a non-hypenated pair of
> family names. And then you have individuals with single names.
>
> So sadly, there is no *truly* consitent answer here.
>
> In the "surname" case you would have:
>
>  [   surname field ]
>
> firstnamelastname
> singlename   
> firstnamefamilyname1 familyname2
> firstname middlename lastname
>
> So already, we have a broken design in trying to sort on "lastname,
> firstname" in the western context because of the individual with the
> singlename.
>
> Additionally, some people may not even enter the surnames correctly - I
> know one spanish lady who consistently had issues with the Australian
> government insisting that familyname2 was her surname. So she would be
> put into systems as:
>
>   [ surname field ]
> firstname familyname1 familyname2
>
> Again, the surname doesn't "sort" correctly, because her true
> familyname1 is not in the surname field.
>
>
> With displayname you can only sort by "order of the displaynames". So
> we can at least consistently sort this given the scenario above!
>
> To *search* for surnames however, now you can do a substring search in
> the displayName field. I'm not sure of your LDAP profficency, but the
> search would be:
>
> (displayName=*lastname)
>
> So for me, I would choose my display name to be:
>
> "William Brown"
>
> To find me would be:
>
> (displayName=*Brown)
>
> For a legal version, you now need to search the legal name field, and
> again, the same search syntax is possible
>
> (legalName=*Brown)
>
> >  This seems like a core front end use case and I wonder if condensing
> > down to one field is going to cause problems for systems connecting
> > to the directory.
>
> *thankfully* most LDAP connections default to the current system of uid
> OR displayName, so this is already taken care of!
>
> >  Another consideration - names may be listed in different orders
> > depending on locale. Eg typical Western format is given middle
> > surname but other locales (Japan comes to mind) is surname given. Can
> > applications connecting to the directory be able to display names
> > appropriately for a given locale if there isnt a way to parse them
> > out correctly? This locale ordering isnt an issue for single names,
> > but 3+ names make it I am
> >  imagining nearly impossible to programmatically parse the user input
> > in any reliably correct way.
>
> We already have complete UTF8 handling in the server, with sorting and
> ordering available.
>
> In terms of "displaying this in correct order" you are right that
> Japanese prefer family name: This is still already a challenge in the
> current design of the server regardless of the field used because of:
>
> uid
> cn
> givenName
> surname
>
> None of these properly encapsulate the "international" nature of names.
> They are very "western". If we display:
>
> givenName surname
>
> We work for western cultures, but not japanese
>
> If we do:
>
> surname, givenName
>
> We may work better for japanese, but this isn't consistent to western
> standards.
>
> And finally, to make it fun - singlenames. How can we handle this?

[389-devel] Re: Improve the demo objects from install

[William Brown]

On Wed, 2018-01-10 at 04:26 +, Máirín Duffy wrote:
> Hi William,
> 
> I'm one of the Fedora UX designers and was pointed to this thread by
> charcol on another list.
> 
> I would like to express enthusiastic support for having by default a
> display name field and a legal name field. This is of particular
> benefit and interest to women as you clearly recognize. My legal name
> is not what people know me by yet it's important for various gov't
> docs that my legal name be used. In most contexts the name I go by is
> more appropriate and recognizable for everyone. Red Hat allows me as
> an employee to choose a displayname for my first name but not my last
> - my legal last name is not what I go by. This has definitely caused
> me some serious real world challenges.

Thanks! I'm glad to see that this idea is supported. I have always
wanted to improve this, and this seems like a great time to achieve it.

> 
> One question I have about having multiple names in one field, from a
> UX designer POV - often when retrieving lists of names for display in
> interfaces, in a Western context they are often listed lastname
> firstname in alphaorder. If the field is freeform and the person
> inputs first middle last or even more names, how can the lastname be
> identified so that a given user can be located in an alphabetically
> ordered list?

You can sort on displayname, but that's about it - The challenge get's
worse in this case.

firstname lastname
singlename
firstname familyname1 familyname2
firstname middlename lastname

Which do we sort on? I know in spain they have a non-hypenated pair of
family names. And then you have individuals with single names. 

So sadly, there is no *truly* consitent answer here.

In the "surname" case you would have:

 [   surname field ]

firstnamelastname
singlename   
firstnamefamilyname1 familyname2
firstname middlename lastname

So already, we have a broken design in trying to sort on "lastname,
firstname" in the western context because of the individual with the
singlename.

Additionally, some people may not even enter the surnames correctly - I
know one spanish lady who consistently had issues with the Australian
government insisting that familyname2 was her surname. So she would be
put into systems as:

  [ surname field ]
firstname familyname1 familyname2

Again, the surname doesn't "sort" correctly, because her true
familyname1 is not in the surname field.


With displayname you can only sort by "order of the displaynames". So
we can at least consistently sort this given the scenario above!

To *search* for surnames however, now you can do a substring search in
the displayName field. I'm not sure of your LDAP profficency, but the
search would be:

(displayName=*lastname)

So for me, I would choose my display name to be:

"William Brown"

To find me would be:

(displayName=*Brown)

For a legal version, you now need to search the legal name field, and
again, the same search syntax is possible

(legalName=*Brown)

>  This seems like a core front end use case and I wonder if condensing
> down to one field is going to cause problems for systems connecting
> to the directory.

*thankfully* most LDAP connections default to the current system of uid
OR displayName, so this is already taken care of!

>  Another consideration - names may be listed in different orders
> depending on locale. Eg typical Western format is given middle
> surname but other locales (Japan comes to mind) is surname given. Can
> applications connecting to the directory be able to display names
> appropriately for a given locale if there isnt a way to parse them
> out correctly? This locale ordering isnt an issue for single names,
> but 3+ names make it I am 
>  imagining nearly impossible to programmatically parse the user input
> in any reliably correct way.

We already have complete UTF8 handling in the server, with sorting and
ordering available. 

In terms of "displaying this in correct order" you are right that
Japanese prefer family name: This is still already a challenge in the
current design of the server regardless of the field used because of:

uid
cn
givenName
surname

None of these properly encapsulate the "international" nature of names.
They are very "western". If we display:

givenName surname

We work for western cultures, but not japanese

If we do:

surname, givenName

We may work better for japanese, but this isn't consistent to western
standards.

And finally, to make it fun - singlenames. How can we handle this?


Thus we arrive at the conclusion - we have a cultural and social
concept, that technology can not represent simply. To have a single
"displayName" and "legalName" field, allow expression of all cultures
names and styles, and we can choose how they are filled in in a way
that is meaningful to a human. We can use ldap's fast querying to help
humans search these fields and still get meaningful data, 

[389-devel] Re: Improve the demo objects from install

[Máirín Duffy]

Hi William,

I'm one of the Fedora UX designers and was pointed to this thread by charcol on 
another list.

I would like to express enthusiastic support for having by default a display 
name field and a legal name field. This is of particular benefit and interest 
to women as you clearly recognize. My legal name is not what people know me by 
yet it's important for various gov't docs that my legal name be used. In most 
contexts the name I go by is more appropriate and recognizable for everyone. 
Red Hat allows me as an employee to choose a displayname for my first name but 
not my last - my legal last name is not what I go by. This has definitely 
caused me some serious real world challenges.

One question I have about having multiple names in one field, from a UX 
designer POV - often when retrieving lists of names for display in interfaces, 
in a Western context they are often listed lastname firstname in alphaorder. If 
the field is freeform and the person inputs first middle last or even more 
names, how can the lastname be identified so that a given user can be located 
in an alphabetically ordered list? This seems like a core front end use case 
and I wonder if condensing down to one field is going to cause problems for 
systems connecting to the directory. Another consideration - names may be 
listed in different orders depending on locale. Eg typical Western format is 
given middle surname but other locales (Japan comes to mind) is surname given. 
Can applications connecting to the directory be able to display names 
appropriately for a given locale if there isnt a way to parse them out 
correctly? This locale ordering isnt an issue for single names, but 3+ names 
make it I am 
 imagining nearly impossible to programmatically parse the user input in any 
reliably correct way.

Hope this feedback is helpful.

Cheers,
~m
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: Intent to retire jenkins.fedorainfracloud.org

[Brian Stinson]

On Jan 09 14:41, Pierre-Yves Chibon wrote:
> On Tue, Jan 09, 2018 at 02:29:38PM +0100, Dan Horák wrote:
> > On Tue, 9 Jan 2018 11:03:28 +0100
> > Pierre-Yves Chibon  wrote:
> > 
> > > Dear all,
> > > 
> > > The Fedora Infrastructure team has had a jenkins instance running at
> > > jenkins.fedorainfracloud.org for a little while now. This instance was
> > > maintained on a best-effort basis though and we often had outage and
> > > issues when upgrading it.
> > > Originally the jenkins master was running on RHEL using the RPMs
> > > provided by upstream jenkins. When jenkins became available in
> > > Fedora, we switched our master to be Fedora using the RPMs from
> > > Fedora. However, nowadays Jenkins is no longer packaged for Fedora,
> > > our jenkins master is therefore outdated.
> > > 
> > > On the other side of the fence, with our dear friends from CentOS, is
> > > a brand new, shiny and well supported Jenkins instance.
> > > So we thought it may be good to leverage the CentOS infrastructure to
> > > alleviate our infrastructure and maintenance.
> > > 
> > > We are currently working on setting up a Jenkins master in
> > > ci.centos.org that would be dedicated to projects ran in pagure.io.
> > > It needs a small change to pagure.io and some work on the CentOS side
> > > but nothing hard and we expect to be able to migrate the first
> > > volunteer projects by early next week.
> > 
> > do you plan to use the dynamically provisioned workers like the
> > current CentOS CI or will it use the static workers like the Fedora
> > Jenkins?
> 
> My understanding is to start with static workers as we have now in Fedora to
> ease the migration (no config change needed) and work from there to migrate to
> dynamically provisioned workers as the rest of CentOS CI does.
> 
> 
> Pierre
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

That's correct, we'll do static agents that match existing Jenkins
labels (EL6, EL7, F25, F25-ppc64le, and F26). 

Longer term, we'll work 1:1 with job owners to migrate to dynamic
provisioning.

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

Re: Intent to retire jenkins.fedorainfracloud.org

[Brian Stinson]

On Jan 09 09:25, Adam Williamson wrote:
> On Tue, 2018-01-09 at 11:03 +0100, Pierre-Yves Chibon wrote:
> > Dear all,
> > 
> > The Fedora Infrastructure team has had a jenkins instance running at
> > jenkins.fedorainfracloud.org for a little while now. This instance was
> > maintained on a best-effort basis though and we often had outage and issues 
> > when
> > upgrading it.
> > Originally the jenkins master was running on RHEL using the RPMs provided by
> > upstream jenkins. When jenkins became available in Fedora, we switched our
> > master to be Fedora using the RPMs from Fedora. However, nowadays Jenkins 
> > is no
> > longer packaged for Fedora, our jenkins master is therefore outdated.
> > 
> > On the other side of the fence, with our dear friends from CentOS, is a 
> > brand
> > new, shiny and well supported Jenkins instance.
> > So we thought it may be good to leverage the CentOS infrastructure to 
> > alleviate
> > our infrastructure and maintenance.
> > 
> > We are currently working on setting up a Jenkins master in ci.centos.org 
> > that
> > would be dedicated to projects ran in pagure.io.
> > It needs a small change to pagure.io and some work on the CentOS side but
> > nothing hard and we expect to be able to migrate the first volunteer 
> > projects by
> > early next week.
> > 
> > Once the first migrations have happened and the first rough edges have been
> > smoothed we will be announcing an official retirement date for
> > jenkins.fedorainfracloud.org and migrate all the projects hosted there to
> > ci.centos.org, and of course help with the potential questions raising from
> > this.
> 
> Will there be a standard / automated migration path for projects that
> have followed documented steps to implement a CI workflow through this
> Jenkins instance, like these:
> 
> https://docs.pagure.org/pagure/usage/pagure_ci_jenkins.html
> 
> ? Thanks!
> -- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

The plan is to automatically import the existing job configs from
jenkins.fedorainfracloud to the new tenant in ci.centos.org 

Changing the Build trigger in the repo settings to point at the new
instance -may, or may not- be a manual step, but there will be, at the
very least, a documented procedure for that.

The goal here is to, first get a supported jenkins instance available,
try a migration of a 'friendly' project (thanks Pingou for
volunteering!) and then work out the procedures for retirement. 

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

Re: rpcgen?

[Ian Kent]

On 09/01/18 23:31, Florian Weimer wrote:
> On 01/09/2018 03:32 PM, Steve Dickson wrote:
>>
>>
>> On 01/09/2018 06:10 AM, Richard W.M. Jones wrote:
>>>
>>> https://fedoraproject.org/w/index.php?title=Changes/SunRPCRemoval=508864
>>> says:
>>>
>>>    "Packages which need rpcgen will have to add BuildRequires: 
>>> libtirpc-devel to their spec files."
>>>
>>> but libtirpc-devel (1.0.2-4.fc28.x86_64) doesn't contain rpcgen.
>> Nor will it... There is going to be a new package call rpcsvc-proto
>> that will contain the rpcgen command along with other things
>> like header files... There is the upstream git tree:
>>     http://github.com/thkukuk/rpcsvc-proto
>>
>> Here is the Review Request for the package, if interested.
>>     https://bugzilla.redhat.com/show_bug.cgi?id=1532364
> 
> Note that the plan is that the new package will provide rpcgen, so you can 
> just use
> 
> BuildRequires: rpcgen
> 
> and you'll get the new package once it becomes available.

What can I do in the meantime to build autofs in Rawhide?

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

Re: F28 Self Contained Change: Avoid /usr/bin/python in RPM build

[Nick Coghlan]

On 10 January 2018 at 11:30, Jason L Tibbitts III  wrote:
> In the end I just can't shake the notion that it's bad to have some
> random non-python-related environment variable basically breaking
> python.

Aye, I think you've hit on the main problem: if this is keyed off
RPM_BUILD_ROOT, then it will impact all RPM builds that use a Fedora
provided Python, even if those builds aren't otherwise required to
abide by Fedora's policy settings.

With a dedicated environment variable instead, that could look something like:

PYTHON_DISALLOW_AMBIGUOUS_VERSION=0 # Status quo
PYTHON_DISALLOW_AMBIGUOUS_VERSION=1 # Hard failure
PYTHON_DISALLOW_AMBIGUOUS_VERSION=warn # Deprecation warning

Then either Koji can take care of setting that (and including it in
the mock configs it generates), or else it can be included in some of
the Fedora specific RPM setup.

Cheers,
Nick.

P.S. Using a dedicated environment variable would have the advantage
of allowing anyone else that *also* wanted to look for and remove
unqualified references to Python 2 to set it.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1528963] perl-Digest-SHA-6.01 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Digest-SHA-6.01-1.fc27 has been pushed to the Fedora 27 stable repository.
If problems still persist, please make note of it in this bug report.

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

[Bug 1528821] ack-2.22 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|ack-2.22-1.fc26 |ack-2.22-1.fc26
   ||ack-2.22-1.fc27



--- Comment #10 from Fedora Update System  ---
ack-2.22-1.fc27 has been pushed to the Fedora 27 stable repository. If problems
still persist, please make note of it in this bug report.

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

[Bug 1528083] perl-HTTP-Message-6.14 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-HTTP-Message-6.14-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1528483] perl-Module-CoreList-5.20171220 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Module-CoreList-5.20171220-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1528493] perl-Time-HiRes-1.9749 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Time-HiRes-1.9749-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1528090] perl-Module-Manifest-1.09 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Module-Manifest-1.09-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1528276] perl-CPAN-Perl-Releases-3.44 is available

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.44-1.fc27 has been pushed to the Fedora 27 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1527521] perl-SOAP-Lite-1.23 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-SOAP-Lite-1.24-1.fc27
 Resolution|--- |ERRATA
Last Closed|2017-12-20 02:15:53 |2018-01-09 21:01:29



--- Comment #8 from Fedora Update System  ---
perl-SOAP-Lite-1.24-1.fc27 has been pushed to the Fedora 27 stable repository.
If problems still persist, please make note of it in this bug report.

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

[Bug 1527723] perl-SOAP-Lite-1.24 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-SOAP-Lite-1.24-1.fc27
 Resolution|--- |ERRATA
Last Closed||2018-01-09 21:01:24



--- Comment #5 from Fedora Update System  ---
perl-SOAP-Lite-1.24-1.fc27 has been pushed to the Fedora 27 stable repository.
If problems still persist, please make note of it in this bug report.

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

[Bug 1526665] perl-PPI-XS-0.910 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-PPI-XS-0.910-1.fc27 has been pushed to the Fedora 27 stable repository. If
problems still persist, please make note of it in this bug report.

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

Re: F28 Self Contained Change: Avoid /usr/bin/python in RPM build

[Jason L Tibbitts III]

> "JK" == Jan Kurik  writes:

JK> Python 2, when called as python or /usr/bin/python at RPM build time
JK> (as identified by the RPM_BUILD_ROOT environment variable), will
JK> print a deprecation warning to stderr. (Any program invoked during
JK> build that invokes /usr/bin/python will cause this warning as well.)

I applaud the effort and think the idea is a good one.  However, I'm
vaguely uneasy about hanging this off of the seemingly unrelated
RPM_BUILD_ROOT.

My initial idea was to simply decide on another variable to use such as
AMBIGUOUS_PYTHON_VERSION_WARNING, and then set that in our rpm
configuration.  (Most likely in %__build_pre, which is defined by the
macros in the rpm package, not redhat-rpm-config.)  But it occurs to me
that in the end this has the same result; you get complaints even if
you're building non-Fedora packages (where our guidelines don't apply).
It's just that the involved variable is slightly more obvious.

I guess if we did that Python would only need to check one environment
variable, but that's not really much of a concern.  It would also mean
that "unset RPM_BUILD_ROOT" would never occur to someone as a potential
solution.

In the end I just can't shake the notion that it's bad to have some
random non-python-related environment variable basically breaking
python.

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

Re: [HUP] [critpath] Upgrade soname version of qrencode in Rawhide

[Matthew Miller]

On Tue, Jan 09, 2018 at 11:06:11PM +0100, Casper wrote:
> I will miss the next mass-rebuild because of your shitty mind

Hey. Please remember the Fedora friends foundation — and our code of
conduct. Directing this kind of comment at another contributor is not
okay.


-- 
Matthew Miller

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

[389-devel] Please review: improve ds* cli tool tests

[William Brown]

https://pagure.io/389-ds-base/issue/49527

https://pagure.io/389-ds-base/issue/raw/files/702f95e1e28cf3948b45fd399
7ed3dd552ab729d112c30e6608977be8bce838d-0001-Ticket-49527-Improve-ds-
cli-tool-testing.patch



-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[testing] community-mysql update needs testing!

[Michal Schorm]

Hello,

I'm in a hurry for this update to get to the stable repository, however it
contains OpenSSL update, which should be tested by many more users, to be
sure.

All karma - positive or neagitve - will be welcomed!

https://bodhi.fedoraproject.org/updates/FEDORA-2018-b7b2c36b14

Thanks!

--

Michal Schorm
Associate Software Engineer
Core Services - Databases Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1532914] New: perl-Socket-2.025 is available

[bugzilla]

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

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



Latest upstream release: 2.025
Current version/release in rawhide: 2.024-5.fc27
URL: http://search.cpan.org/dist/Socket/

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

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

[Bug 1532908] New: perl-SQL-Translator-0.11024 is available

[bugzilla]

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

Bug ID: 1532908
   Summary: perl-SQL-Translator-0.11024 is available
   Product: Fedora
   Version: rawhide
 Component: perl-SQL-Translator
  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,
trem...@tremble.org.uk



Latest upstream release: 0.11024
Current version/release in rawhide: 0.11023-1.fc28
URL: http://search.cpan.org/dist/SQL-Translator/

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

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

[389-devel] Improve the demo objects from install

[William Brown]

Hi all,

It's time that I'm looking at:
https://pagure.io/389-ds-base/issue/49425

There are some great reasons to freshen up the default objects we
install. The current design isn't really reflective of modern directory
usage, the aci's are not "great" examples, and it's not a super-useful
foundation out of the box.

As a result, I have some improvements I want to make here. Let's start
with the simple ones:

Tree layout:

dc=example,dc=com
cn=389_ds_system,dc=example,dc=com
ou=people,dc=example,dc=com
ou=groups,dc=example,dc=com
ou=services,dc=example,dc=com
ou=permissions,dc=example,dc=com

This is the structure I want us to ship with: groups, people, service
accounts, and permission groups. I additionally add an
nscontainer|ldapsubentry 389_ds_system, which is the "hidden" config
area that we could start to use for things like pwpolicy, keepalive
entries, replication service accounts and more. I don't think anything
here is too controversial :)

Next, demo objects!

uid=demo_user,ou=people,dc=example,dc=com
cn=demo_group,ou=groups,dc=example,dc=com

These can show a user and group, and lets the cli tools have something
to show, and how they can be integrated with *acis*.

Again, nothing complex :) 

Permissions! This is where we start to add aci's and get's a bit fun.

I want to ship with a few useful permisisons and acis. The thinking is:

* anonymous read to public ou=People and user attributes (ie Sssd
should work oob)
* anonymous read to groups attributes (ie Sssd should work oob)
* a permission group where members can alter group members
* a permission group where members can alter users
* a permission group where members can reset user passwords
* a permission group where members can create/delete users
* a permission group where members can create/delete groups

This is a pretty simple set of acis, but I want them to show how
delegation of permissions can be done safely, and act as examples and
templates for admins - as well as just being simple and useful for
small deployments out of the box!


Now, this is the final suggestion: I'd like to add some extra schema
and change user objects by default that we create. 

I would like to add:

nsPerson

I would like them to contain the following:

nsPerson:
MAY: userPassword, telephoneNumber, seeAlso, description, legalName
MUST: cn, displayName


This is a shift from the traditional person object and there is a
really good reason - 
internationalisation. (we replace sn with legalName and make it may,
and add
displayName).


The current person account *requires* the sn field. However surname
*does not*
translate across many cultural boundaries. Some people have multiple
surnames, some
have no concept of a surname.

What people do have is a *legal name* which is their full name - for me
that would be
givennames + surname. For others just their single name. having a
single legalName
field correctly represents this case. And additionally many
applications don't
even need a legal name, *only* a displayName of the users choice.

The second reason is identity related. There are many people whos
chosen name
for the world (displayName) differs from their actual legal name. As a
result
having a displayname field where the user can *choose* how they are
represented
is highly important. Consider divorced people (who haven't yet changed
legal names)
victims of crime (who need to hide their identity) and more.

I think our current schema doesn't current reflect the "best" in
identity management
and by adding nsPerson like this, we can really do the right thing
here, by
default.

*obivously* this is a new schema, not changing existing items, so
existing deployments
will keep using whatever they want (person etc) - more that new
deployments will
see a modern, best practice that they can follow,


I'd like to get feedback on this soon, as I'd like to have this in the
cli
tool demo I want to release soon.

Thanks everyone,


-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: [HUP] [critpath] Upgrade soname version of qrencode in Rawhide

[Kevin Kofler]

Casper wrote:
> I will miss the next mass-rebuild because of your shitty mind

The mass rebuild cannot happen with your incompatible package because many 
packages indirectly depend on systemd.

At the very least, systemd needs to be rebuilt against the new qrencode. And 
systemd itself drags in systemd as a build dependency, then it cannot be 
built at all without either something providing libqrencode.so.3 or building 
a systemd without qrencode support BEFORE the bumped qrencode.

Also, missing the mass rebuild is not a reason to panic, anything depending 
on libqrencode.so.3 will have to be rebuilt anyway.

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

Re: F28 Self Contained Change: Avoid /usr/bin/python in RPM build

[Kevin Kofler]

Jan Kurik wrote:
> Currently in Fedora (package names, executable names, etc.), python
> means Python 2.
> We would like to change it to mean Python 3, but to do that, we need
> to free it of the current meaning.
> This means explicitly using either "python2" or "python3" throughout
> Fedora.

Are you sure that this is worth the pain? Unsuffixed qmake is still the Qt 3 
QMake (not even Qt 4), unsuffixed kde-config is still the KDE 3 kde-config 
(not even KDE 4), etc., for backwards compatibility. I think changing the 
meaning of "python" is unhelpful and counterproductive. Sure, without this 
change, more and more users will eventually end up with not having an 
unsuffixed "python" installed at all, but IMHO that's better than silently 
changing its meaning.

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

Re: [HUP] [critpath] Upgrade soname version of qrencode in Rawhide

[Adam Williamson]

On Tue, 2018-01-09 at 23:06 +0100, Casper wrote:
> no kidding, it's a critpath, and one day it will be updated in
> development branch (which is called "Rawhide").
> 
> you want a rendez-vous or what ?

There's a process you're meant to follow:

https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master

"For updates to rawhide packages, Maintainers SHOULD:

...

* A WEEK IN ADVANCE, notify maintainers who depend on their package
  to rebuild when there are abi/api changes that require rebuilds in
  other packages or offer to do these rebuilds for them.
* Use a separate buildsystem tag when dealing with mass builds of many
  packages, so they can land at the same time. File a ticket with
  https://fedorahosted.org/rel-eng/newticket for this."

I don't know if enough things depend on qrencode for it to be worth
setting up a buildsystem tag to do the rebuilds, but the first of those
two points *certainly* applies to your case. Rather than notifying at
the time you did the rebuild, you should have sent out a mail a week in
advance. Ideally it would be best to co-ordinate with the maintainers
of dependent packages so that builds of the library and the
dependencies land in the same compose and there is no breakage -
certainly for something as critical as systemd, without which nothing
works at all.

Rawhide is a development release, but that doesn't mean that it's OK to
just break it whenever you like. We are trying to keep Rawhide at
consistent Alpha quality (that's what the previous cycle's "No More
Alphas" Change was about). That certainly involves making sure the init
system always works.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Get stubby into Fedora to provide safe DNS resolution via DNS-over-TLS

[rugk]

Providing privacy and security for DNS! (especially after dnscrypt is 
discontinued now).
It would be nice to have this in Fedora.

https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby
GitHub: https://github.com/getdnsapi/stubby
For distro status see: https://repology.org/metapackage/stubby/versions
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

HEADS UP - Changes to Ghostscript package in F28

[David Kaspar [Dee'Kej]]

​​Hello guys! :)

Initial NOTE: I have made some bigger changes in Ghostscript package during
the cleanup, which should be self-contained. In my opinion those changes
are not so significant to create "self-contained change" wiki page for it
(for F28), but if the consensus of people here will be the opposite, then I
will create it additionally...



I would like to inform you that Ghostscript package has received proper
cleanup in accordance to Fedora Packaging Guidelines (FPG), and comments
from upstream were also incorporated into the changes.

The aim was to simplify the package maintenance, to bring the Fedora's
Ghostscript package as close as possible to upstream's vanilla build, to
completely debundle the Ghostscript package of software/resources that we
already have available (packaged) in Fedora, and to transform the layout of
subpackages to be more sane and granular...

The changes are described more in detail below:

* libijs -- the IJS library has been debundled and is now provided as a
separate package: https://src.fedoraproject.org/rpms/libijs

* libgs -- new separate package, created from Ghostscript's shared library.
It contains all necessary files for other software/packages that are build
upon Ghostscript's functionality.
* libgs-devel -- new separate subpackage, for development purposes or
Fedora's build process. The 'ghostscript-devel' is still provided for now
as a virtual subpackage.

->> This particular change will allow packages depending on Ghostscript
functionality (like evince for example) to only require 'libgs', instead of
requiring almost the whole Ghostscript (and thus pulling in files that many
users don't want/need or might even never use).

* ghostscript -- is no longer a metapackage. It's a regular package
instead, and it contains Ghostscript's binaries as well as some typical
conversion scripts people are used to (and expect to have
  installed together with Ghostscript by default).

* ghostscript-tools-fonts -- new subpackage that contains 3 scripts that
are useful only for people who are working with AFM, PFB or PFA files
(conversions usually).
* ghostscript-tools-printing -- new subpackage that contains only utilities
for formatting and printing text files using either Ghostscript, or
BubbleJet, DeskJet, DeskJet 500, & LaserJet printers.

->> These subpackages contain files that only a small amount of people will
ever need. Having them in a separate subpackages will avoid polluting
users' filesystem after fresh F28+ installations.

* ghostscript-core -- has became an empty metapackage for upgrade purposes.
It will be removed once Fedora 28 is EOL, and all other packages has
updated their specfiles to require correct subpackages.

->> This metapackage makes sure that upgrade from old package layout to new
package layout should be smooth (tested in F27).

* LPR setup scripts are no longer being shipped. In case people still need
those, then 'ghostscript-tools-lpr' will be created for it.
* examples/ from 'ghostscript-doc' are no longer shipped.
* Documentation and resources paths no longer contain version string inside
of them.

* Support for /usr/share/ghostscript/conf.d/ folder was dropped to use
Ghostscript's default choice for rendering of CJK glyphs, which is Google
Droid Sans Fallback font. In case this proves insufficient, the conf.d/
folder support will be re-established.

->> This change is still being discussed with Peng Wu and Akira Tagoh. So
far, we have agreed to this change, but I will be ready to revert it in
case people depending on printing CJK-based texts will have any problems.
In case the Ghostscript's default functionality would prove to be sufficent
and work OK, then the 'ghostscript-chinese' package could be retired as a
result.
->> For now, we are also waiting for rebase of 'google-droid-fonts' for
Ghostscript to have the latest version of Droid Sans Fallback font and thus
the latest CJK glyphs coverage.

* Symbolic links for direct resources locations have been added to speedup
Ghostscript's startup time.
* Ghostscript's search path was updated to include only fonts locations,
which will be used only as a backup (in case of broken symbolic links).

->> This change is a preferred method (advised) from upstream.

* Ghostscript itself (as a whole) has been completely debundled (to a
  point where it still makes sense). It newly requires these packages:

  https://src.fedoraproject.org/rpms/adobe-mappings-cmap
  https://src.fedoraproject.org/rpms/adobe-mappings-pdf
  https://src.fedoraproject.org/rpms/libijs
  https://src.fedoraproject.org/rpms/urw-base35-fonts
  https://src.fedoraproject.org/rpms/google-droid-fonts

->> I will send additional separate e-mails to this mailing list tomorrow
to inform others of availability of some of these packages.

* As a result of debundling, 'poppler-data' is no longer a requirement for
Ghostscript, and it is no longer necessary to do a rebuild of
'poppler-data' when Ghostscript is rebased.

Re: Security updates and batched pushes

[Tim Landscheidt]

Kevin Fenzi  wrote:

> […]

 I really don't understand why we do this "batched" thing to begin with.

>>> To reduce the constant flow of updates that are very minor or affect
>>> very few mixed in with the major updates that affect lots of people and
>>> are urgent.

>> But the users were already able to opt to update only weekly. So why force a
>> fixed schedule on them?

> To save all the Fedora users in the world from having to update metadata
> for minor changes. Since there's a hourly dnf makecache every user in
> the world pulls down new metadata ever time we update a repo. If we
> update a repo for some minor enhancements it means everyone in the world
> has to pay for that. If we just push all those out every tuesday and
> don't update those unless there's something urgent we save everyone a
> lot of bandwith and us computing time/resources.

> […]

BTW, are there technical reasons why the metadata is updated
en bloc and not incrementally like for example delta RPMs,
or is it just that nobody bothered to implement something
like that yet for metadata?

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

Re: [HUP] [critpath] Upgrade soname version of qrencode in Rawhide

[Casper]

first, thanks for your remarks.

the build has been untagged (thanks for releng reactivity), so it
won't be a melodramatic movie about rawhide which is broken... oh
wait! look the mass-rebuild showing the point of its nose...

seriously.

I will miss the next mass-rebuild because of your shitty mind

no kidding, it's a critpath, and one day it will be updated in
development branch (which is called "Rawhide").

you want a rendez-vous or what ?

Sérgio Basto a écrit :
> On Tue, 2018-01-09 at 21:12 +0100, Igor Gnatenko wrote:
> > On Tue, 2018-01-09 at 20:37 +0100, Casper wrote:
> > > Dear Fedora Devops,
> > > 
> > > qrencode (critpath) package has been updated in rawhide branch.
> > > 
> > > Major change:
> > > from: libqrencode.so.3.4.4
> > > to: libqrencode.so.4.0.0
> > > 
> > > If you need to report any issue:
> > >   https://bugzilla.redhat.com/show_bug.cgi?id=1510097
> > > 
> > > Koji build:
> > >   https://koji.fedoraproject.org/koji/taskinfo?taskID=24100494
> > > 
> > > Many packages requires libqrencode (systemd, etc...) so take care
> > > about compatibility breakage.
> > 
> > Does it mean that maintainers of those packages should take care of
> > them or
> > will you?
> > 
> > Sending email when you **broke** all builds in rawhide is pretty
> > bad...
> 
> nothing provides libqrencode.so.3()(64bit) needed by systemd-236-
> 1.fc28.aarch64 
> 
> seems to me pretty serious 
> 
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> -- 
> Sérgio M. B.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

-- 
GPG Key ID: 83288189 @ hkp://keys.fedoraproject.org
Empreinte: CC26 692F 5205 AC8F 7912  7783 D7A7 F4C5 8328 8189

x509 C.A.: https://dl.casperlefantom.net/pub/root.pem
Empreinte: 0975 864A 2036 0F94 A139  114A D32E 8EBE 30F2 2429


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

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jan 09, 2018 at 04:30:56PM +0100, Pavel Březina wrote:
> On 01/05/2018 05:21 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >On Fri, Jan 05, 2018 at 02:50:45PM +0100, Jan Kurik wrote:
> >>= System Wide Change: Make authselect default tool instead of authconfig =
> >>https://fedoraproject.org/wiki/Changes/AuthselectAsDefault
> >
> >Does this change do anything to reduce the number of files in /etc
> >that do not contain local configuration? PAM is currently one of the
> >worst offenders, with /etc/pam.d full of "configuration" files.
> 
> No. The files must stay since it would require changes in pam itself
> and that is out of scope of authselect. Each file corresponds to
> individual pam service and is read when pam_start(service_name, ...)
> is called.
> 
> >Elsewhere in the thread /usr/share/authselect/custom is metioned as
> >directory for admin config. That's OK-ish, as long as you also allow
> >a directory in /etc for the same purpose. /usr must be allowed to be
> >immutable.
> 
> Would /usr/local be OK as well?

/usr/local is special. Packages are not allowed to put stuff there [1],
and it is instead an alternate install location that is under the
control of the administrator. It seems reasonable to support
authselect configuration located there.

/usr/share/authselect and /etc/authselect are the two main locations
that should be supported, and /usr/local/share/autselect would be an
additional option.

[1] 
https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_under_.2Fsrv.2C_.2Fusr.2Flocal.2C_or_.2Fhome.2F.24USER

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

Re: Disable a package for Fedora 26

[Kevin Kofler]

Jonny Heggheim wrote:
> I think the best solution, based on my knowledge and available time, is
> to upgrade Fedora 26 to the latest upstream.

So please do that then. The sooner, the better.

> The fixes from upstream are spread on several commits and releases.

That is also the case with, e.g., Firefox, whose maintainers also always 
upgrade rather than backporting. So I think you will be best off upgrading 
your package too.

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

Planned Outage - Taskotron update - 2018-01-09 @ 22:00 UTC

[Tim Flink]

Apologies on not announcing this farther ahead of time.

There will be an outage starting at 2018-01-09 22:00:00 UTC, which will
last 4-6 hours.

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run:

date -d '2018-01-09 22:00:00 UTC'

Reason for outage:

We are upgrading the hosts which run the services required for
Taskotron. This will not affect resultsdb as this will be upgraded at a
later date.

Affected Services:

taskotron.fedoraproject.org

Contact Information:

Please join #fedora-admin or #fedora-noc on irc.freenode.net


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

Re: Security updates and batched pushes

[Kevin Kofler]

Matthew Miller wrote:
> Also, I think everyone in this discussion on _this_ list who would like
> updates faster should probably be using updates-testing. Or at least
> _looking_ at updates-testing. You can always pull individual updates
> from there on a per-package basis, and doing this helps everyone else.

I want tested updates faster. I don't want untested updates.

I also don't think it would be a productive use of my time to go through all 
testing updates every day to see which ones are batched for stable. This is 
something that could easily be automated by software (i.e., by having Bodhi 
push the updates to a fast track repository), why should I be doing this by 
hand?

What I do normally do is read the update notes of every update that I am 
about to apply. This is also a reason why I hate the batching, because the 
batches are huge and painful to check through. I prefer more frequent 
smaller pushes that I can easily read through. But what I can definitely 
tell you is that most updates do not contain enough information in the 
update notes to really know their impact, so using that as a basis for 
applying or not applying some update from updates-testing is not going to 
scale either.

By the way, the reason I did not voice these complaints in the thread 
initially announcing this change is that I was both too angry and too busy 
at that time to come up with a polite reply, and besides, the change was 
already implemented when announced anyway.

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

Re: Security updates and batched pushes

[Kevin Kofler]

Kevin Fenzi wrote:
> You also don't want updates-testing to even exist right?

That is not true. I want to leave the decision whether and for how long an 
update needs to be tested to the package maintainer instead of enforcing 
minimum testing requirements in the software, because the software can never 
understand the exact context. Removing updates-testing entirely is not what 
I want! But this is unrelated to the current issue of artificially delaying 
updates that satisfy all the criteria for being pushed to stable.

> To save all the Fedora users in the world from having to update metadata
> for minor changes. Since there's a hourly dnf makecache every user in
> the world pulls down new metadata ever time we update a repo.

So to save people the download, you make a change that totally defeats the 
point of dnf checking for updates every hour to begin with?

> If we update a repo for some minor enhancements it means everyone in the
> world has to pay for that. If we just push all those out every tuesday and
> don't update those unless there's something urgent we save everyone a
> lot of bandwith and us computing time/resources.

This does not work in practice because there are always updates that are not 
batched.

> There are definitely more days when there are no updates for a
> particular repo now. Of course there would be even more if you (or those
> who do likewise) wouldn't skip batched, but probibly we need to explain
> why more clearly.

Are there really? The last couple days, there were basically daily pushes 
with around 2 updates each.

The batching only makes the daily pushes smaller and not empty, which does 
not help at all for reducing repodata download size, because there are still 
no repodata deltas implemented.

> because it would be a ton more infrastructure and resources.

Really? Bodhi composes (or triggers the compose of, let's please not discuss 
the technical details down to that level) 2 repositories per release at each 
push, of which one (updates-testing) already works pretty much the way the 
fast track repository would work (updates transit there, but leave again 
when they reach the next level). How would adding a third level require a 
ton more resources? It would just need some small changes to the Bodhi 
implementation ("pushes to batched" would have to be actually pushed, to the 
fast track repository) and could otherwise use all the existing mirroring 
infrastructure. And users would be able to opt in to getting stable updates 
without batching. And even if those users keep the regular repodata 
downloads enabled, the downloads for fast track would still be much smaller 
than the repodata downloads for all of stable. And having fast track 
available would also reduce the proportion of updates that skip batched. (I 
know I would think twice about skipping batched for my updates if I knew 
that the users have a way to opt out of the batching. Right now, I don't 
even consider using batched.)

I see only advantages of such an approach, for minimal infrastructure costs. 
Almost everything you need is already there!

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

Fwd: F28 Self Contained Change: Avoid /usr/bin/python in RPM build

[Miro Hrončok]

 Forwarded Message 
Subject: F28 Self Contained Change: Avoid /usr/bin/python in RPM build
Date: Tue, 9 Jan 2018 20:13:58 +0100
From: Jan Kurik 
Reply-To: Development discussions related to Fedora 

To: Development discussions related to Fedora 
, devel-annou...@lists.fedoraproject.org


= Proposed Self Contained Change: Avoid /usr/bin/python in RPM build =
https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build

Change owner(s):
* Petr Viktorin 
* Miro Hrončok 

Deprecate, and later disable, running /usr/bin/python (as opposed to
/usr/bin/python3 or /usr/bin/python2) during RPM build.
Changes will be driven by Python SIG, but a few packages may fail to
build (with the failure message providing an easy workaround).


== Detailed Description ==
=== Motivation ===

Currently in Fedora (package names, executable names, etc.), python
means Python 2.
We would like to change it to mean Python 3, but to do that, we need
to free it of the current meaning.
This means explicitly using either "python2" or "python3" throughout Fedora.
This is a multi-release effort tracked in Python SIG's "Finalizing
Fedora Switch to Python3" document.
This page describes a very focused subset of it.

Renaming packages (and associated changes to, for example, "Requires:"
directives) is relatively straightforward, but making all
Fedora-provided code avoid /usr/bin/python (as opposed to
/usr/bin/python2) is both harder to achieve and harder to keep track
of.

We would like to start deprecating /usr/bin/python (as opposed to
/usr/bin/python2) at RPM build time.
RPM build is a controlled environment: changes to it will not be felt
by end users, breakages are almost immediately visible, and output of
Koji builds can be nicely tracked and analyzed.

=== Specification ===

Python 2, when called as python or /usr/bin/python at RPM build time
(as identified by the RPM_BUILD_ROOT environment variable), will print
a deprecation warning to stderr. (Any program invoked during build
that invokes /usr/bin/python will cause this warning as well.)

A new Taskotron check will be implemented to look for this warning and
fail if it's found.
We will look at the Taskotron results and work with packagers to
switch to update the affected packages. (We'll look at the results to
determine if we'll use automated pull requests, mass bug filing, or
something else.)

The warning itself may cause some packages to fail to build, for
example if a test relies on exact stderr contents.
For these cases, it will be possible to turn the warning off using an
environment variable, but we ask packagers that use of this workaround
is tracked in Bugzilla. See Opt-Out below.

After all packages that BuildRequire python2 are re-built with this
check passing, python will be switched to fail after printing the
message.

The warning will not be effective if stderr output is hidden. So,
after switching /usr/bin/python to fail, some packages may start
failing to build. We will work with the packagers to fix these. (We'll
look at results from the "warnings phase" to see how proactive we'll
need to be here.)

The warning text will be:

DEPRECATION WARNING: python2 invoked with /usr/bin/python.
Use /usr/bin/python3 or /usr/bin/python2
/usr/bin/python will be removed or switched to Python 3 in the future.
If you cannot make the switch now, please follow instructions at
https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build#Quick_Opt-Out

(Using the Wiki link allows us to easily revise the instructions.)

=== Quick Opt-Out ===

In case switching to /usr/bin/python2 or /usr/bin/python3 is
non-trivial, do these two things:

* Set the environment variable
DISABLE_AMBIGUOUS_PYTHON_VERSION_WARNING=1 when calling
/usr/bin/python
* File a Bugzilla, and make it block our tracking bug (XXX - link)

All such bugs will need to be fixed before we make /usr/bin/python fail 
hard.



== Scope ==
* Proposal owners:
Patch python2, write the Taskotron check, deal with warnings and failures.

* Other developers:
Switch to using /usr/bin/python3 or /usr/bin/python2 explicitly at RPM
build time (with help from Proposal owners if needed). Also tools that
are invoked during build time of other packages that themselves use
/usr/bin/python will need to be fixed.

* Release engineering:
#7257: https://pagure.io/releng/issue/7257
Note: Depending on the timing, separate targeted rebuilds may be
needed, but we can do these as Proven Packagers, no side-tags are
required

* List of deliverables:
N/A

* Policies and guidelines:
Already existing "packages in Fedora ... MUST call the proper
executable for the needed python major version directly, either
/usr/bin/python2 or /usr/bin/python3 as appropriate" from
Packaging:Python#Multiple_Python_Runtimes

* Trademark approval:
N/A (not needed for this Change)
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., 

Re: F28 System Wide Change: GCC8

[Jakub Jelinek]

On Tue, Jan 09, 2018 at 07:50:10PM +, Stephen Gallagher wrote:
> > Well, true, but then just like every year, we'll wind up doing a lot of
> > the spadework of fixing things to build with the new GCC. And probably
> > at first some critical things will fail to build and that'll mess up
> > the stability of the distro for a couple of weeks. I guess if everyone
> > else is still loving that grind, hey.
> >
> 
> 
> This is the cost of being "First". Fedora has long enjoyed a tight coupling
> with the GCC upstream. It's a symbiosis: they use our mass-rebuild to help
> identify any issues before GCC goes stable and in turn Fedora gets to have
> the newest compiler features before anyone else.

To be fair, Ubuntu (or Debian or both, dunno) has already performed test mass
rebuilds with GCC 8 prerelease some time ago and OpenSUSE usually performs them
roughly at the same time as we do.  We are likely the first one or one of
the first ones to deploy it as a stable compiler in the distro and it is
mutually beneficial both for the distro and for GCC.

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

Re: [HUP] [critpath] Upgrade soname version of qrencode in Rawhide

[Sérgio Basto]

On Tue, 2018-01-09 at 21:12 +0100, Igor Gnatenko wrote:
> On Tue, 2018-01-09 at 20:37 +0100, Casper wrote:
> > Dear Fedora Devops,
> > 
> > qrencode (critpath) package has been updated in rawhide branch.
> > 
> > Major change:
> > from: libqrencode.so.3.4.4
> > to: libqrencode.so.4.0.0
> > 
> > If you need to report any issue:
> >   https://bugzilla.redhat.com/show_bug.cgi?id=1510097
> > 
> > Koji build:
> >   https://koji.fedoraproject.org/koji/taskinfo?taskID=24100494
> > 
> > Many packages requires libqrencode (systemd, etc...) so take care
> > about compatibility breakage.
> 
> Does it mean that maintainers of those packages should take care of
> them or
> will you?
> 
> Sending email when you **broke** all builds in rawhide is pretty
> bad...

nothing provides libqrencode.so.3()(64bit) needed by systemd-236-
1.fc28.aarch64 

seems to me pretty serious 

> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: provenpackager request: Re: [HEADS UP] opencv 3.3.1 is going to rawhide

[Sérgio Basto]

On Tue, 2018-01-09 at 18:28 +0100, Till Hofmann wrote:
> 
> On 01/09/2018 05:53 PM, Sérgio Basto wrote:
> > Packages remaining to rebuild:
> > digikam
> > fawkes
> > kf5-libkface
> > nomacs
> > player
> > simon
> > 
> > Provenpackager request for: 
> > Do fedpkg build in fawkes master [3] 
> > [3]
> > https://src.fedoraproject.org/rpms/fawkes/commits/master
> > 
> 
> 
> That won't help because fawkes ist still FTBFS after the last
> protobuf
> bump: https://bugzilla.redhat.com/show_bug.cgi?id=1523093

I need more one help from provenpackager merge and build player [1]
from what I see to build fawkes, you just need rebuild player. I had
confused the deps around package player but all builds correctly on
copr [2] 

[1] 
https://src.fedoraproject.org/rpms/player/pull-request/1

[2]
https://copr.fedorainfracloud.org/coprs/sergiomb/opencv/builds/

> Regards,
> Till
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HUP] [critpath] Upgrade soname version of qrencode in Rawhide

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2018-01-09 at 20:37 +0100, Casper wrote:
> Dear Fedora Devops,
> 
> qrencode (critpath) package has been updated in rawhide branch.
> 
> Major change:
> from: libqrencode.so.3.4.4
> to: libqrencode.so.4.0.0
> 
> If you need to report any issue:
>   https://bugzilla.redhat.com/show_bug.cgi?id=1510097
> 
> Koji build:
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=24100494
> 
> Many packages requires libqrencode (systemd, etc...) so take care
> about compatibility breakage.

Does it mean that maintainers of those packages should take care of them or
will you?

Sending email when you **broke** all builds in rawhide is pretty bad...
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpVIh8ACgkQaVcUvRu8
X0xSsg/9Fh6ZI3szUCJsnhUlqm9NIomkMirw5N2iDhMoa+eHZAInJGymsV4yFL3D
zWXYLh9NbX3rZRlLT3uRRLpl/Vhbw2pB/5TkQhiIfyYcCE1XvktJk7gkxNPewOUj
c2mrHaclfc44IMtwrnELJK0A8dfdjp9dwWn8A9gLfTU+mrSE49p3PcYTNtWRVBGD
DJXUZASBDqZIRR0tzQ6/5rLRktLoQ7g2UCUVcQzHEY+wdX3Vv0wdwJv8TCZ+yh/l
dJZQvtbls0GqM46g3riiK5x5y5osV1YbDaJVPwOdorLMPlCCaF3sbtlEqMdGPqy1
+VTUz1dul6p6u2OIwFAK47XL2Z5tnahKKBxT4dqQBJD4iQkf/oGylQvsQBAEJEB9
JjTdhsiFnQYPdJQprzF3sIncj5CwOyB+7cQQPKsjngsbtRhT0wMRFVP10g+CSlYh
F/0AAwfIprfGtBtnhaG3DK+H2W2bsUJCvZz0rtqDr3xMC07BQs4dOMNBtRsqCrW0
CLCHxadBWr2WF3X3R17335IpTQ4kVyCU3Ezu/HanvKOWF6gad/2NRuAc2f2oPG/j
RZ9UNBaD1Rl32QdBmuY9KYz/4qnuZzfq2qAAqTvm+t4w6NmN5sVm1Rzb8h9FtkAn
GTF3R5LmZSzJjtdMW31XA5Hxic04s7lkI0xtFt5TahucQgzSwR8=
=GMzm
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: GCC8

[Stephen Gallagher]

On Tue, Jan 9, 2018 at 12:58 PM Adam Williamson 
wrote:

> On Tue, 2018-01-09 at 18:45 +0100, Jakub Jelinek wrote:
> > On Tue, Jan 09, 2018 at 09:39:41AM -0800, Adam Williamson wrote:
> > > The timing on this looks a bit awkward when compared with the current
> > > schedule, which has the Beta going out in March and Final early in May:
> > >
> > > https://fedoraproject.org/wiki/Releases/28/Schedule
> > >
> > > That would appear to mean we'd have to do a mass rebuild with a pre-
> > > release GCC, or do a mass rebuild between Beta and Final, or suddenly
> > > introduce a new compiler post-Beta, potentially meaning that we need to
> > > rebuild something to fix a blocker bug quite late in the release and
> > > discover that the new GCC which has suddenly appeared causes problems
> > > with building it. None of those sound like great options to me.
> >
> > Mass rebuild with a prerelease version of the compiler, like every year
> at
> > least in the past 10 years in Fedora.
>
> Well, true, but then just like every year, we'll wind up doing a lot of
> the spadework of fixing things to build with the new GCC. And probably
> at first some critical things will fail to build and that'll mess up
> the stability of the distro for a couple of weeks. I guess if everyone
> else is still loving that grind, hey.
>


This is the cost of being "First". Fedora has long enjoyed a tight coupling
with the GCC upstream. It's a symbiosis: they use our mass-rebuild to help
identify any issues before GCC goes stable and in turn Fedora gets to have
the newest compiler features before anyone else.

Realistically, since Fedora is the first real-world exercise of new GCC, if
we waited for the upstream stable release, it would be exactly as it is
now. Fedora would hit all the same issues and GCC would have to release
updates to fix them for us.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[HUP] [critpath] Upgrade soname version of qrencode in Rawhide

[Casper]

Dear Fedora Devops,

qrencode (critpath) package has been updated in rawhide branch.

Major change:
from: libqrencode.so.3.4.4
to: libqrencode.so.4.0.0

If you need to report any issue:
  https://bugzilla.redhat.com/show_bug.cgi?id=1510097

Koji build:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=24100494

Many packages requires libqrencode (systemd, etc...) so take care
about compatibility breakage.

best regards,
-- 
GPG Key ID: 83288189 @ hkp://keys.fedoraproject.org
Empreinte: CC26 692F 5205 AC8F 7912  7783 D7A7 F4C5 8328 8189

x509 C.A.: https://dl.casperlefantom.net/pub/root.pem
Empreinte: 0975 864A 2036 0F94 A139  114A D32E 8EBE 30F2 2429


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

Re: Copr dependency rebuild with circular dependencies

[James Paul Turner]

Thanks Nicolas. That makes sense.

Would you advise that the compatibility package remains in rawhide
after the mass rebuild?

Best,
James.

On Tue, 2018-01-09 at 20:06 +0100, nicolas.mail...@laposte.net wrote:
> Hi,
> 
> Regardless of the build infra, you will need to create a compat
> package with the old lib version to make it available during
> bootstraping
> 
> Regards,
> 
> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
James Paul Turner
Freenode / Fedora: jamesturner246
The Arpra Project: https://github.com/jamesturner246/arpra
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Disable a package for Fedora 26

[Jonny Heggheim]

Hi Kevin, thanks for your feedback.


On 01/09/2018 11:36 AM, Kevin Kofler wrote:
> … if you can't do the backport in a reasonable time frame (This 
> vulnerability is very critical, since it allows remote money stealing!), the 
> recommendation is to just upgrade to the latest upstream immediately (i.e., 
> your first option). E.g., this (just upgrade to the latest version, even if 
> there are breaking changes) is also how Firefox handles security updates.
>
> Upgrading vs. backporting is always a tradeoff. Upgrading keeps you closer 
> to upstream, backporting means fewer unexpected changes for users of stable 
> releases. There are instances of both in Fedora, depending on what changed 
> in the new upstream release and/or how hard it is to backport the security 
> fixes to the old release.

I think the best solution, based on my knowledge and available time, is
to upgrade Fedora 26 to the latest upstream.
The fixes from upstream are spread on several commits and releases.



> This (your third option) is the worst possible option. It is better to just 
> push the new version, which is surely better than nothing (and also better 
> than doing nothing and letting websites steal the user's money).
I agree, this is the most user unfriendly, but better than loosing money.


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

F28 Self Contained Change: Avoid /usr/bin/python in RPM build

[Jan Kurik]

= Proposed Self Contained Change: Avoid /usr/bin/python in RPM build =
https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build

Change owner(s):
* Petr Viktorin 
* Miro Hrončok 

Deprecate, and later disable, running /usr/bin/python (as opposed to
/usr/bin/python3 or /usr/bin/python2) during RPM build.
Changes will be driven by Python SIG, but a few packages may fail to
build (with the failure message providing an easy workaround).


== Detailed Description ==
=== Motivation ===

Currently in Fedora (package names, executable names, etc.), python
means Python 2.
We would like to change it to mean Python 3, but to do that, we need
to free it of the current meaning.
This means explicitly using either "python2" or "python3" throughout Fedora.
This is a multi-release effort tracked in Python SIG's "Finalizing
Fedora Switch to Python3" document.
This page describes a very focused subset of it.

Renaming packages (and associated changes to, for example, "Requires:"
directives) is relatively straightforward, but making all
Fedora-provided code avoid /usr/bin/python (as opposed to
/usr/bin/python2) is both harder to achieve and harder to keep track
of.

We would like to start deprecating /usr/bin/python (as opposed to
/usr/bin/python2) at RPM build time.
RPM build is a controlled environment: changes to it will not be felt
by end users, breakages are almost immediately visible, and output of
Koji builds can be nicely tracked and analyzed.

=== Specification ===

Python 2, when called as python or /usr/bin/python at RPM build time
(as identified by the RPM_BUILD_ROOT environment variable), will print
a deprecation warning to stderr. (Any program invoked during build
that invokes /usr/bin/python will cause this warning as well.)

A new Taskotron check will be implemented to look for this warning and
fail if it's found.
We will look at the Taskotron results and work with packagers to
switch to update the affected packages. (We'll look at the results to
determine if we'll use automated pull requests, mass bug filing, or
something else.)

The warning itself may cause some packages to fail to build, for
example if a test relies on exact stderr contents.
For these cases, it will be possible to turn the warning off using an
environment variable, but we ask packagers that use of this workaround
is tracked in Bugzilla. See Opt-Out below.

After all packages that BuildRequire python2 are re-built with this
check passing, python will be switched to fail after printing the
message.

The warning will not be effective if stderr output is hidden. So,
after switching /usr/bin/python to fail, some packages may start
failing to build. We will work with the packagers to fix these. (We'll
look at results from the "warnings phase" to see how proactive we'll
need to be here.)

The warning text will be:

DEPRECATION WARNING: python2 invoked with /usr/bin/python.
Use /usr/bin/python3 or /usr/bin/python2
/usr/bin/python will be removed or switched to Python 3 in the future.
If you cannot make the switch now, please follow instructions at
https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build#Quick_Opt-Out

(Using the Wiki link allows us to easily revise the instructions.)

=== Quick Opt-Out ===

In case switching to /usr/bin/python2 or /usr/bin/python3 is
non-trivial, do these two things:

* Set the environment variable
DISABLE_AMBIGUOUS_PYTHON_VERSION_WARNING=1 when calling
/usr/bin/python
* File a Bugzilla, and make it block our tracking bug (XXX - link)

All such bugs will need to be fixed before we make /usr/bin/python fail hard.


== Scope ==
* Proposal owners:
Patch python2, write the Taskotron check, deal with warnings and failures.

* Other developers:
Switch to using /usr/bin/python3 or /usr/bin/python2 explicitly at RPM
build time (with help from Proposal owners if needed). Also tools that
are invoked during build time of other packages that themselves use
/usr/bin/python will need to be fixed.

* Release engineering:
#7257: https://pagure.io/releng/issue/7257
Note: Depending on the timing, separate targeted rebuilds may be
needed, but we can do these as Proven Packagers, no side-tags are
required

* List of deliverables:
N/A

* Policies and guidelines:
Already existing "packages in Fedora ... MUST call the proper
executable for the needed python major version directly, either
/usr/bin/python2 or /usr/bin/python3 as appropriate" from
Packaging:Python#Multiple_Python_Runtimes

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F28 Self Contained Change: Avoid /usr/bin/python in RPM build

[Jan Kurik]

= Proposed Self Contained Change: Avoid /usr/bin/python in RPM build =
https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build

Change owner(s):
* Petr Viktorin 
* Miro Hrončok 

Deprecate, and later disable, running /usr/bin/python (as opposed to
/usr/bin/python3 or /usr/bin/python2) during RPM build.
Changes will be driven by Python SIG, but a few packages may fail to
build (with the failure message providing an easy workaround).


== Detailed Description ==
=== Motivation ===

Currently in Fedora (package names, executable names, etc.), python
means Python 2.
We would like to change it to mean Python 3, but to do that, we need
to free it of the current meaning.
This means explicitly using either "python2" or "python3" throughout Fedora.
This is a multi-release effort tracked in Python SIG's "Finalizing
Fedora Switch to Python3" document.
This page describes a very focused subset of it.

Renaming packages (and associated changes to, for example, "Requires:"
directives) is relatively straightforward, but making all
Fedora-provided code avoid /usr/bin/python (as opposed to
/usr/bin/python2) is both harder to achieve and harder to keep track
of.

We would like to start deprecating /usr/bin/python (as opposed to
/usr/bin/python2) at RPM build time.
RPM build is a controlled environment: changes to it will not be felt
by end users, breakages are almost immediately visible, and output of
Koji builds can be nicely tracked and analyzed.

=== Specification ===

Python 2, when called as python or /usr/bin/python at RPM build time
(as identified by the RPM_BUILD_ROOT environment variable), will print
a deprecation warning to stderr. (Any program invoked during build
that invokes /usr/bin/python will cause this warning as well.)

A new Taskotron check will be implemented to look for this warning and
fail if it's found.
We will look at the Taskotron results and work with packagers to
switch to update the affected packages. (We'll look at the results to
determine if we'll use automated pull requests, mass bug filing, or
something else.)

The warning itself may cause some packages to fail to build, for
example if a test relies on exact stderr contents.
For these cases, it will be possible to turn the warning off using an
environment variable, but we ask packagers that use of this workaround
is tracked in Bugzilla. See Opt-Out below.

After all packages that BuildRequire python2 are re-built with this
check passing, python will be switched to fail after printing the
message.

The warning will not be effective if stderr output is hidden. So,
after switching /usr/bin/python to fail, some packages may start
failing to build. We will work with the packagers to fix these. (We'll
look at results from the "warnings phase" to see how proactive we'll
need to be here.)

The warning text will be:

DEPRECATION WARNING: python2 invoked with /usr/bin/python.
Use /usr/bin/python3 or /usr/bin/python2
/usr/bin/python will be removed or switched to Python 3 in the future.
If you cannot make the switch now, please follow instructions at
https://fedoraproject.org/wiki/Changes/Avoid_usr_bin_python_in_RPM_Build#Quick_Opt-Out

(Using the Wiki link allows us to easily revise the instructions.)

=== Quick Opt-Out ===

In case switching to /usr/bin/python2 or /usr/bin/python3 is
non-trivial, do these two things:

* Set the environment variable
DISABLE_AMBIGUOUS_PYTHON_VERSION_WARNING=1 when calling
/usr/bin/python
* File a Bugzilla, and make it block our tracking bug (XXX - link)

All such bugs will need to be fixed before we make /usr/bin/python fail hard.


== Scope ==
* Proposal owners:
Patch python2, write the Taskotron check, deal with warnings and failures.

* Other developers:
Switch to using /usr/bin/python3 or /usr/bin/python2 explicitly at RPM
build time (with help from Proposal owners if needed). Also tools that
are invoked during build time of other packages that themselves use
/usr/bin/python will need to be fixed.

* Release engineering:
#7257: https://pagure.io/releng/issue/7257
Note: Depending on the timing, separate targeted rebuilds may be
needed, but we can do these as Proven Packagers, no side-tags are
required

* List of deliverables:
N/A

* Policies and guidelines:
Already existing "packages in Fedora ... MUST call the proper
executable for the needed python major version directly, either
/usr/bin/python2 or /usr/bin/python3 as appropriate" from
Packaging:Python#Multiple_Python_Runtimes

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Copr dependency rebuild with circular dependencies

[nicolas . mailhot]

Hi,

Regardless of the build infra, you will need to create a compat package with 
the old lib version to make it available during bootstraping

Regards,

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

Can't capture vmcore?

[Maxim Burgerhout]

I'm getting kernel panics in a VM that functions as a hypervisor, the
moment I spin up the nested guest (on AMD ThreadRipper / Fedora 27). That
is annoying, of course, so I try to be a good citizen and file a bug.

For some reason though, I cannot get the core dumped. I get a core fine
with sysrq, but not with this actual panic. I've followed [1] to set up
kdump and crash, but everytime I trigger the crash and see my VM reboot, I
see an empty /var/crash afterwards.

As was able to get the vmcore written to /var/crash on in a RHEL7 guest,
I'm starting to suspect a bug, but I'm unsure.

Any pointers on how to debug this?

[1] https://fedoraproject.org/wiki/How_to_use_kdump_to_debug_kernel_crashes
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Copr dependency rebuild with circular dependencies

[James Paul Turner]

Hi all. Apologies for cross-posting, but I am running out of ideas.

Suppose one updates libmpfr in a copr repository, which bumps the
soname. Both GCC and libmpc depend on libmpfr, and so must be rebuilt,
but neither GCC nor libmpc can be rebuilt without an existing libmpc,
which, in turn, depends on the old soname version of the recently
updated libmpfr. Can somebody please advise the best way to go in cases
like these?

Is a copr mass rebuild even the right solution for this, or should one
really be using a side tag in koji? - though it is unclear to me what
difference that will make.

Happy to provide more info. All the best,
James.

-- 
James Paul Turner
Freenode / Fedora: jamesturner246
The Arpra Project: https://github.com/jamesturner246/arpra
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

REMINDER: January 2018 Elections: Nomination & Campaign period in progress

[Jan Kurik]

This is just a reminder that tomorrow on 2018-Jan-10 at 23:59:59 UTC
we will close the Nomination window of January 2018 Elections.
Please check the nomination pages [1][2][3] and apply, if you are
interested to work in FESCo, Council or Mindshare teams.

[1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
[2] https://fedoraproject.org/wiki/Council/Nominations
[3] https://fedoraproject.org/wiki/Mindshare/Nominations

Regards,
Jan

On Wed, Jan 3, 2018 at 9:16 AM, Brian Exelbierd  wrote:
> Today we are starting the Nomination & Campaign period during which
> we accept nominations to the "steering bodies" of the following teams:
>
> * FESCo (Engineering) (5 seats) [1]
> * Fedora Council (2 seats) [2]
> * Mindshare (2 seats) [3]
>
> This period is open until 2018-Jan-10 at 23:59:59 UTC.
>
> The nominees can already start preparing their answers for
> questions in the Election Questionnaire.  The questions can
> be found in the template files[4], however this election
> features a new way to submit questionnaires.
>
> Nominees submit their questionnaire answers via a private
> Pagure issue[5].  The Election Wrangler or their backup will
> publish the interviews to the Community Blog [6] on the
> first day of the Voting period (2018-Jan-17).
>
> Please note that the interview is mandatory for all nominees.
> Nominees not having their interview ready by end of the
> Interview period (2018-Jan-15) will be disqualified and removed
> from the election.  Nominees may submit their interview answers
> immediately and may edit them until the end of the interview period.
>
> Nominees are encouraged to begin their interview answers as
> soon as they accept their nomination.
>
> The full schedule of the January 2018 Elections is available on the
> Elections wiki page [8].
>
> [1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations
> [2] https://fedoraproject.org/wiki/Council/Nominations
> [3] https://fedoraproject.org/wiki/Mindshare/Nominations
> [4] 
> https://pagure.io/fedora-project-schedule/blob/master/f/elections/2018-January
> [5] https://pagure.io/fedora-project-schedule/issues
> [6] http://communityblog.fedoraproject.org/
> [8] https://fedoraproject.org/wiki/Elections
>
> regards,
>
> bex
> --
> Brian (bex) Exelbierd | bexel...@redhat.com | b...@pobox.com
> Fedora Community Action & Impact Coordinator
> Backup Election Wrangler
> @bexelbie | http://www.winglemeyer.org
> ___
> ambassadors mailing list -- ambassad...@lists.fedoraproject.org
> To unsubscribe send an email to ambassadors-le...@lists.fedoraproject.org



-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28 Change Checkpoint: Proposal submission deadline (Changes requiring mass rebuild & system wide changes)

[Jan Kurik]

Greetings!

Today, on 2018-Jan-09, we have reached Fedora 28 Change Checkpoint:
Proposal submission deadline (Changes requiring mass rebuild & system
wide changes) [1].

At this point, only Self Contained Changes will be accepted for Fedora
28. Any Change Proposal requiring mass rebuild or a System wide Change
should be scheduled for a later Fedora release.

Self Contained Changes are still accepted until 2018-Jan-30, as
published in the F28 schedule [1].

On 2018-Feb-20 is planned "Change Checkpoint Completion deadline
(testable)" where all Changes should be implemented and testable.

[1] https://fedoraproject.org/wiki/Releases/28/Schedule

Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Binutils version 2.29.1

[Jan Pokorný]

On 09/01/18 16:16 +0100, Tomasz Torcz ️ wrote:
> On Tue, Jan 09, 2018 at 12:11:31PM +0100, Jan Kurik wrote:
>> = System Wide Change: Binutils version 2.29.1 =
>> https://fedoraproject.org/wiki/Changes/BINUTILS2291
>> 
>> Change owner(s):
>> * Nick Clifton 
>> 
>> Rebase the binutils package from version 2.29 to version 2.29.1. This
>> will bring in the bug-fixes from the 2.29.1 point release, but not add
>> any new features.
>> 
> 
>> Change the source parameter in the binutils.spec rpm and adjust the
>> local patches to take account of the bugs that are now already fixed.
> 
>   I'm a bit perplexed by this change.  It looks like minor version
>  update, in such case it need no to be announced so widely.
>   On the other hand, you are changing the source.  According to the
>  guidelines, changing source requires re-review.
>   So why this is a system-wide change?

I think I have something to add here as if no other package, libqb was
quite affected with the former change of binutils 2.28 -> 2.29 coming
to Fedora 27:
  https://bugzilla.redhat.com/show_bug.cgi?id=1478089
+ binutils bug:
  https://bugzilla.redhat.com/show_bug.cgi?id=1477354
(TL;DR eventually, libqb adopted measures to overcome changed
visibility of some symbols, binutils didn't go back in its behaviour)

In parallel, there was a separate discussion directly with upstream:
  https://lists.gnu.org/archive/html/bug-binutils/2017-08/msg00195.html
which resulted in
  
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f399679112df997c1416f7993eaac0f5fd76c144
that is part of 2.29.1 and which actually forced an existing prototype
of the libqb fix to be refined once more because, suddenly, some new
configure-time checks were to loose to detect the necessity to apply
said measures (while they were working fine with 2.29 alone).

So I can attest this change has a merit (compare with unannounced 2.29
change that hit libqb hard), even though it's not expected the number
of packages relying on some rather obscure linker features (that are
hence not under constant coverage) will be notable.  But keep in mind
that a single broken package can spoil some other, dependent packages,
as was the case with libqb.

Thanks for playing it considerately now, Nick.

-- 
Jan (Poki)


pgpQVdHIQl60o.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 28 Change Checkpoint: Proposal submission deadline (Changes requiring mass rebuild & system wide changes)

[Jan Kurik]

Greetings!

Today, on 2018-Jan-09, we have reached Fedora 28 Change Checkpoint:
Proposal submission deadline (Changes requiring mass rebuild & system
wide changes) [1].

At this point, only Self Contained Changes will be accepted for Fedora
28. Any Change Proposal requiring mass rebuild or a System wide Change
should be scheduled for a later Fedora release.

Self Contained Changes are still accepted until 2018-Jan-30, as
published in the F28 schedule [1].

On 2018-Feb-20 is planned "Change Checkpoint Completion deadline
(testable)" where all Changes should be implemented and testable.

[1] https://fedoraproject.org/wiki/Releases/28/Schedule

Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

[smooge]

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2018-01-10 from 18:00:00 to 19:00:00 GMT
   At fedora-meet...@irc.freenode.net

The meeting will be about:
The EPEL Steering Committee will have a weekly meeting to cover current tasks 
and problems needed to keep EPEL going.


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

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

Re: Security updates and batched pushes

[Kevin Fenzi]

On 01/08/2018 10:53 AM, Kevin Kofler wrote:
> Kevin Fenzi wrote:
>> Well, if this firefox update was urgent, shouldn't it have been marked
>> urgent?
> 
> Urgency is always in the eye of the beholder. I as a user consider all 
> security updates "urgent", and in addition, I want ALL updates as soon as 
> they passed testing no matter whether they actually are urgent.

You also don't want updates-testing to even exist right?

> 
>>> I really don't understand why we do this "batched" thing to begin with.
>>
>> To reduce the constant flow of updates that are very minor or affect
>> very few mixed in with the major updates that affect lots of people and
>> are urgent.
> 
> But the users were already able to opt to update only weekly. So why force a 
> fixed schedule on them?

To save all the Fedora users in the world from having to update metadata
for minor changes. Since there's a hourly dnf makecache every user in
the world pulls down new metadata ever time we update a repo. If we
update a repo for some minor enhancements it means everyone in the world
has to pay for that. If we just push all those out every tuesday and
don't update those unless there's something urgent we save everyone a
lot of bandwith and us computing time/resources.

>> To save users downloads of repodata.
> 
> This does not work in practice because there is almost always at least one 
> urgent update that requires downloading the whole repodata. (And also 
> because maintainers are free to skip batched without giving a reason. I 
> always do this because I consider batching a disservice to my users.)

There are definitely more days when there are no updates for a
particular repo now. Of course there would be even more if you (or those
who do likewise) wouldn't skip batched, but probibly we need to explain
why more clearly.

...snip...
>> I would be very much against additional repos like this.
> 
> Why? It would allow you to keep the server-side batching while still 
> allowing those users like me to opt out of it. And the repodata download 
> size for fast track would be minimal if updates that went out to stable get 
> removed from fast track.

because it would be a ton more infrastructure and resources.

kevin



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

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 1037  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 800  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 382  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-04bc9dd81d   
libbsd-0.8.3-1.el7
 279  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d241156dfe   
mod_cluster-1.3.3-10.el7
 111  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e27758bd23   
libmspack-0.6-0.1.alpha.el7
  48  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-e64eeb6ece   
nagios-4.3.4-5.el7
  37  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-d704442ae7   
qpid-cpp-1.37.0-1.el7
  18  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-957aa05f33   
heketi-5.0.1-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-8d57a2487b   
monit-5.25.1-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-753e392fc4   
xrdp-0.9.5-1.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2e2d08b1ff   
awstats-7.6-4.el7
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-49ca8440a1   
gifsicle-1.90-1.el7


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

easy-rsa-3.0.3-1.el7
librdkafka-0.11.3-1.el7
mint-x-icons-1.4.6-5.el7
mint-y-icons-1.1.3-2.el7
paper-icon-theme-1.4.0-2.el7
php-bartlett-php-compatinfo-db-1.28.0-1.el7
python-pymod2pkg-0.11.0-1.el7
rdopkg-0.45.0-5.el7
rho-0.0.31-1.el7
tcl-tclnagios-1.3-5.el7

Details about builds:



 easy-rsa-3.0.3-1.el7 (FEDORA-EPEL-2018-f3e8fb0991)
 Simple shell based CA utility

Update Information:

Update to 3.0.3 for modern openssl and ciphers.




 librdkafka-0.11.3-1.el7 (FEDORA-EPEL-2018-e49cc220fa)
 The Apache Kafka C library

Update Information:

Default changes  Change default queue.buffering.max.kbytes and
queued.max.message.kbytes to 1GB (#1304) win32: Use
sasl.kerberos.service.name for broker principal, not sasl.kerberos.principal
(#1502)  Enhancements  Default producer message offsets to OFFSET_INVALID
rather than 0 new nuget package layout + debian9 librdkafka build (#1513,
@mhowlett) Allow for calling rd_kafka_queue_io_event_enable() from the C++
world (#1483, @akhi3030) rdkafka_performance: allow testing latency with
different size messages (#1482, @tbsaunde)  Fixes  Improved stability on
termination (internal queues, ERR__DESTROY event) offsets_for_times() return
ERR__TIMED_OUT if brokers did not respond in time Let list_groups() return
ERR__PARTIAL with a partial group list (#1508) Properly handle infinite (-1)
rd_timeout:s throughout the code (#1539) Fix offsets_store() return value
when at least one valid partition portability: rdendian: add le64toh() alias
for older glibc (#1463) Add MIPS build and fix CRC32 to work on big endian
CPUs (@andoma, closes #1498) osx: fix endian checking for software crc32c
Fix comparison in rd_list_remove_cmp (closes #1493) stop calling
cnd_timedwait() with a timeout of 0h (#1481, @tbsaunde) Fix DNS cache logic
broker.address.ttl (#1491, @dacjames) Fix broker thread "hang" in CONNECT
state (#1397) Reset rkb_blocking_max_ms on broker DOWN to avoid busy-loop
during CONNECT (#1397) Fix memory leak when producev() fails (#1478)
Raise cmake minimum version to 3.2 (#1460) Do not assume LZ4 worst (best?)
case 255x compression (#1446 by @tudor) Fix ALL_BROKERS_DOWN re-generation
(fix by @ciprianpascu, #1101) rdkafka-performance: busy wait to wait short
periods of time  source: https://github.com/edenhill/librdkafka/releases




 mint-x-icons-1.4.6-5.el7 (FEDORA-EPEL-2018-5e92e7eb55)
 Icon theme for Linux Mint

Update Information:

- Use rpm filetriggers on Fedora and/or RHEL >= 8




 mint-y-icons-1.1.3-2.el7 (FEDORA-EPEL-2018-d86af40c33)
 The Mint-Y icon theme

Update Information:

- Use rpm filetriggers on Fedora and/or RHEL >= 8

F28 System Wide Change: NIS switching to new libnsl to support IPv6

[Jan Kurik]

= System Wide Change: NIS switching to new libnsl to support IPv6 =
https://fedoraproject.org/wiki/Changes/NISIPv6

Change owner(s):
* Matej Muzila 
* Honza Horak 

This system-wide change covers the switch of NIS components to the new
client side implementation in order to support IPv6, while detaching
libnsl and nss_nis packages, previously bundled together with glibc.

== Detailed Description ==
glibc bundles the client part of NIS, while this implementation is not
compatible with IPv6, due to the way addresses are represented. NIS
upstream added NIS support for the server and client tools, but for
being able to use this feature, the libnsl and nss_nis needs to be
rebased to the new version. Since NIS has been part of glibc for long
time and it doesn't seem to be necessary (especially given the NIS is
an obsoleted technology for years), it is better to detach those two
packages and deliver them as a separate library.

This change is also related to Sun RPC Removal Change
[https://fedoraproject.org/wiki/Changes/SunRPCRemoval].


== Scope ==
* Proposal owners:
Provide the NIS client implementation as separate packages, and adjust
the glibc packaging to remove the nss_nis subpackage, the NIS header
files, and move libnsl to a new subpackage.

* Other developers:
Packages which used to depend on the libnsl library from glibc will
need to add BuildRequires: libnsl2-devel.

* Release engineering:
#7256: https://pagure.io/releng/issue/7256

* List of deliverables: N/A

* Policies and guidelines:
N/A (not needed for this Change; covered by the existing Packaging Guidelines)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F28 System Wide Change: NIS switching to new libnsl to support IPv6

[Jan Kurik]

= System Wide Change: NIS switching to new libnsl to support IPv6 =
https://fedoraproject.org/wiki/Changes/NISIPv6

Change owner(s):
* Matej Muzila 
* Honza Horak 

This system-wide change covers the switch of NIS components to the new
client side implementation in order to support IPv6, while detaching
libnsl and nss_nis packages, previously bundled together with glibc.

== Detailed Description ==
glibc bundles the client part of NIS, while this implementation is not
compatible with IPv6, due to the way addresses are represented. NIS
upstream added NIS support for the server and client tools, but for
being able to use this feature, the libnsl and nss_nis needs to be
rebased to the new version. Since NIS has been part of glibc for long
time and it doesn't seem to be necessary (especially given the NIS is
an obsoleted technology for years), it is better to detach those two
packages and deliver them as a separate library.

This change is also related to Sun RPC Removal Change
[https://fedoraproject.org/wiki/Changes/SunRPCRemoval].


== Scope ==
* Proposal owners:
Provide the NIS client implementation as separate packages, and adjust
the glibc packaging to remove the nss_nis subpackage, the NIS header
files, and move libnsl to a new subpackage.

* Other developers:
Packages which used to depend on the libnsl library from glibc will
need to add BuildRequires: libnsl2-devel.

* Release engineering:
#7256: https://pagure.io/releng/issue/7256

* List of deliverables: N/A

* Policies and guidelines:
N/A (not needed for this Change; covered by the existing Packaging Guidelines)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 910  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 800  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 771  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 382  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e3e50897ac   
libbsd-0.8.3-2.el6
 111  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-4c76ddcc92   
libmspack-0.6-0.1.alpha.el6
  30  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6aaee32b7e   
optipng-0.7.6-6.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-6e4ce19598   
monit-5.25.1-1.el6
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-37c8dbd6f1   
gifsicle-1.90-1.el6
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-8c9006d462   
heimdal-7.5.0-1.el6


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

easy-rsa-3.0.3-1.el6
rho-0.0.31-1.el6

Details about builds:



 easy-rsa-3.0.3-1.el6 (FEDORA-EPEL-2018-4a6cbdd222)
 Simple shell based CA utility

Update Information:

Update to 3.0.3 for modern openssl and ciphers.




 rho-0.0.31-1.el6 (FEDORA-EPEL-2018-4846ddf8ae)
 An SSH system profiler

Update Information:

# Testing Rho  To set up Rho, you create profiles that control how to run each
scan. - Authentication profiles contain user credentials for a user with
sufficient authority to complete the scan (for example, a root user or one with
root-level access obtained through -sudo privilege escalation). - Network
profiles contain network identifiers (for example, a hostname, IP address, or
range of IP addresses) and the authentication profiles to be used for a scan.
Complete the following steps, repeating them as necessary to access all parts of
your environment that you want to scan: 1. Create at least one authentication
profile with root-level access to Rho: ``` rho auth add --name auth_name
--username root_name(--sshkeyfile key_file | --password) ```  a. At the Rho
vault password prompt, create a new Rho vault password. This password is
required to access the encrypted Rho data, such as authentication and network
profiles, scan data, and other information.  b. If you did not use the
sshkeyfile option to provide an SSH key for the username value, enter the
password of the user with root-level access at the connection password prompt.
For example, for an authentication profile where the authentication profile name
is roothost1, the user with root-level access is root, and the SSH key for the
user is in the path ~/.ssh/id_rsa, you would enter the following command: ```
rho auth add --name roothost1 --username root --sshkeyfile ~/.ssh/id_rsa ``` You
can also use the sudo-password option to create an authentication profile for a
user with root-level access who requires a password to obtain this privilege.
You can use the sudo-password option with either the sshkeyfile or the password
option. For example, for an authentication profile where the authentication
profile name is sudouser1, the user with root-level access is sysadmin, and the
access is obtained through the password option, you would enter the following
command: ``` rho auth add --name sudouser1 --username sysadmin --password
--sudo-password ```  After you enter this command, you are prompted to enter two
passwords. First, you would enter the connection password for the username user,
and then you would enter the password for the sudo command.  2. Create at least
one network profile that specifies one or more network identifiers, such as a
host name, an IP address, a list of IP addresses, or an IP range, and one or
more authentication profiles to be used for the scan: ``` rho profile add --name
profile_name --hosts host_name_or_file --auth auth_name ```  For example, for a
network profile where the name of the network profile is mynetwork, the network
to be scanned is the 192.0.2.0/24 subnet, and the authentication profiles that
are used to run the scan are roothost1 and roothost2, you would enter the
following command: ``` rho profile add --name mynetwork --hosts 192.0.2.[1:254]
--auth roothost1 roothost2 ```  You can also use a file to pass in the network
identifiers. If you use a file to enter multiple network identifiers, such as
multiple individual IP addresses, enter each on a single line. For example, for
a network profile where the path to this file is /home/user1/hosts_file, you
would enter the following command: ``` rho profile add 

Re: F28 System Wide Change: GCC8

[Adam Williamson]

On Tue, 2018-01-09 at 18:45 +0100, Jakub Jelinek wrote:
> On Tue, Jan 09, 2018 at 09:39:41AM -0800, Adam Williamson wrote:
> > The timing on this looks a bit awkward when compared with the current
> > schedule, which has the Beta going out in March and Final early in May:
> > 
> > https://fedoraproject.org/wiki/Releases/28/Schedule
> > 
> > That would appear to mean we'd have to do a mass rebuild with a pre-
> > release GCC, or do a mass rebuild between Beta and Final, or suddenly
> > introduce a new compiler post-Beta, potentially meaning that we need to
> > rebuild something to fix a blocker bug quite late in the release and
> > discover that the new GCC which has suddenly appeared causes problems
> > with building it. None of those sound like great options to me.
> 
> Mass rebuild with a prerelease version of the compiler, like every year at
> least in the past 10 years in Fedora.

Well, true, but then just like every year, we'll wind up doing a lot of
the spadework of fixing things to build with the new GCC. And probably
at first some critical things will fail to build and that'll mess up
the stability of the distro for a couple of weeks. I guess if everyone
else is still loving that grind, hey.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Anaconda modularization

[Adam Williamson]

On Tue, 2018-01-09 at 11:28 -0500, Matthew Miller wrote:
> On Tue, Jan 09, 2018 at 05:17:40PM +0100, Martin Kolman wrote:
> > As mentioned by jkonecny, we have updated the change page, including
> > the contingency plan.
> 
> Thanks -- that's much more clear. And I see the deadline has been moved
> back to a week before Final Freeze. Sounds good to me assuming QA feels
> comfortable with this.

It sounds fairly workable to me, yeah. I can foresee perhaps we're not
successful in keeping the fallback branch 100% up to the criteria, but
at least it should be fairly close and only cause a short delay to
bring things up to scratch if we have to use it. Thanks to Martin and
the team for adjusting the proposal.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 Self Contained Change: Anaconda modularization

[jkonecny]

Hi all,

Based on the feedback we modified the change:

* There is a more formal contingency plan in place.
* Contingency deadline is moved one week earlier.
* Detailed description contains explanation of what we want to achieve
for F28. We don't aim to have everything in F28.
* It is System Wide Change now.


Thank you all for your feedback,
Jirka
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F28 System Wide Change: Replace glibc's libcrypt with libxcrypt

[Jan Kurik]

= System Wide Change: Replace glibc's libcrypt with libxcrypt =
https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt

Change owner(s):
* Björn Esser 
* Florian Weimer 

There are plans to remove libcrypt from glibc, so we should have a replacement.


== Detailed Description ==
Since there has been some discussion in the last time about removing
libcrypt from glibc in some time and splitting it out into a separate
project which can evolve quicker, Zack Weinberg and I put some work
into libxcrypt to make it a basically suitable replacement.

It comes with a set of extended interfaces pioneered by Openwall
Linux, crypt_rn, crypt_ra, crypt_gensalt, crypt_gensalt_rn, and
crypt_gensalt_ra.

The crypt and gensalt functions are supporting all (except for
Crypt16, which was used on Ultrix and Tru64, only) widely used
password hashing algorithms, which before were specific to just some
operating system's implementations of libcrypt.


== Scope ==
* Proposal owners:
- Apply needed packaging changes to glibc
- Review, import and build libxcrypt for Fedora 28

* Other developers:
Test their applications using one of the following interfaces for
unexpected changes in functionality:
- crypt()
- crypt_r()
- encrypt()
- encrypt_r()
- fcrypt()
- setkey()
- setkey_r()

Release engineering:
#7160 https://pagure.io/releng/issue/7160
none expected

* Policies and guidelines:
N/A (not needed for this Change)

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: GCC8

[Jakub Jelinek]

On Tue, Jan 09, 2018 at 09:39:41AM -0800, Adam Williamson wrote:
> The timing on this looks a bit awkward when compared with the current
> schedule, which has the Beta going out in March and Final early in May:
> 
> https://fedoraproject.org/wiki/Releases/28/Schedule
> 
> That would appear to mean we'd have to do a mass rebuild with a pre-
> release GCC, or do a mass rebuild between Beta and Final, or suddenly
> introduce a new compiler post-Beta, potentially meaning that we need to
> rebuild something to fix a blocker bug quite late in the release and
> discover that the new GCC which has suddenly appeared causes problems
> with building it. None of those sound like great options to me.

Mass rebuild with a prerelease version of the compiler, like every year at
least in the past 10 years in Fedora.

> Is there significant enough benefit from the new GCC to outweigh all
> these potential negative impacts to it going stable between our Beta
> and Final releases?

Yes.

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

[Bug 1532593] perl-Encode-2.94 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
perl-Encode-2.94-16.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-c7cbaa1fcc

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

Re: Changelog between OS states (ie: VMs)

[Adam Williamson]

On Tue, 2018-01-09 at 11:13 +, Richard W.M. Jones wrote:
> On Mon, Jan 08, 2018 at 12:59:20PM -0500, Martin Langhoff wrote:
> > I have two VMs, or OS states I can `rpm -qa` on. Is there a script to
> > diff the output of the two listings, and then query the package
> > changelogs to generate an overall OS-wide changelog?
> > 
> > Use case: I generated an F26 OVA image using imagefactory 30 days ago,
> > then I generated a new F26 image today. I'd export rpm -qa listings
> > from both, and then get a changelog showing all the package updates,
> > expecting to see the kernel package with the recent CVEs fixed.
> > 
> > Does such a tool exist?
> 
> virt-inspector can show the differences in packages installed
> between two VMs (run it once on each VM and diff the output).
> 
> For more sophisticating diffing, use virt-diff:
> 
>   http://libguestfs.org/virt-diff.1.html

I think the interesting part of the request is the combination of
*first* getting the information on what package NEVRs differ between
the two, *then* generating a selective changelog from that list (i.e.
if you know one instance has foo-2.0-1 and the other has foo-2.1-3,
including only the changes between foo-2.0-1 and foo-2.1-3 in the
changelog). I can think of lots of ways to do the first and there are
probably lots of existing implementations of it, but doing the second
is rather less common AFAIK.

The closest existing tool to this that I can think of is the one used
to generate the daily compose reports, which is the `compose-changelog` 
tool in this repo:

https://pagure.io/compose-utils

that may be of interest to the original poster.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: GCC8

[Adam Williamson]

On Tue, 2018-01-09 at 12:11 +0100, Jan Kurik wrote:
> = System Wide Change: GCC8 =
> https://fedoraproject.org/wiki/Changes/GCC8
> 
> Change owner(s):
> * Jakub Jelínek 
> 
> Switch GCC in Fedora 28 to 8.x.y, rebuild all packages with it, or
> optionally rebuild just some packages with it and rebuild all packages
> only in Fedora 29.
> 
> 
> == Detailed Description ==
> GCC 8 is currently in stage3, will move to stage4 on January 14th, in
> prerelease state with only regression bugfixes and documentation fixes
> allowed. The release will happen probably in the middle of April. We
> are working on scratch gcc rpms and will perform a test mass rebuild.

The timing on this looks a bit awkward when compared with the current
schedule, which has the Beta going out in March and Final early in May:

https://fedoraproject.org/wiki/Releases/28/Schedule

That would appear to mean we'd have to do a mass rebuild with a pre-
release GCC, or do a mass rebuild between Beta and Final, or suddenly
introduce a new compiler post-Beta, potentially meaning that we need to
rebuild something to fix a blocker bug quite late in the release and
discover that the new GCC which has suddenly appeared causes problems
with building it. None of those sound like great options to me.

Is there significant enough benefit from the new GCC to outweigh all
these potential negative impacts to it going stable between our Beta
and Final releases?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Package Question

[Adam Williamson]

On Mon, 2018-01-08 at 12:21 -0500, Steve Dickson wrote:
> Hello,
> 
> Is it a problem for a package to pull from two different 
> upstream tar balls? Basically have 
> 
> Source0: http://server.com/package1/package1.tar
> Source1: http://server.com/package2/package2.tar
> 
> Then I would, by hand, untar Source1 into Source0 directory.

Just to state something explicitly that others have mentioned in
passing: you do not have to do this by hand, RPM provides extensive
support for this kind of scenario. Maximum RPM is still the best doc I
know of for this kind of stuff:

http://ftp.rpm.org/max-rpm/s1-rpm-specref-macros.html

Specifically, you'll want to look at -b and -a, and the examples of how
each is used.

As others have said, this isn't *necessarily* "a problem" and there are
several cases of existing packages that do it, but without further
details, no-one can give you an informed opinion on whether it makes
sense to do things this way in your specific case.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: provenpackager request: Re: [HEADS UP] opencv 3.3.1 is going to rawhide

[Till Hofmann]

On 01/09/2018 05:53 PM, Sérgio Basto wrote:
> Packages remaining to rebuild:
> digikam
> fawkes
> kf5-libkface
> nomacs
> player
> simon
> 
> Provenpackager request for: 
> Do fedpkg build in fawkes master [3] 

> [3]
> https://src.fedoraproject.org/rpms/fawkes/commits/master
>


That won't help because fawkes ist still FTBFS after the last protobuf
bump: https://bugzilla.redhat.com/show_bug.cgi?id=1523093

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

Re: Intent to retire jenkins.fedorainfracloud.org

[Adam Williamson]

On Tue, 2018-01-09 at 11:03 +0100, Pierre-Yves Chibon wrote:
> Dear all,
> 
> The Fedora Infrastructure team has had a jenkins instance running at
> jenkins.fedorainfracloud.org for a little while now. This instance was
> maintained on a best-effort basis though and we often had outage and issues 
> when
> upgrading it.
> Originally the jenkins master was running on RHEL using the RPMs provided by
> upstream jenkins. When jenkins became available in Fedora, we switched our
> master to be Fedora using the RPMs from Fedora. However, nowadays Jenkins is 
> no
> longer packaged for Fedora, our jenkins master is therefore outdated.
> 
> On the other side of the fence, with our dear friends from CentOS, is a brand
> new, shiny and well supported Jenkins instance.
> So we thought it may be good to leverage the CentOS infrastructure to 
> alleviate
> our infrastructure and maintenance.
> 
> We are currently working on setting up a Jenkins master in ci.centos.org that
> would be dedicated to projects ran in pagure.io.
> It needs a small change to pagure.io and some work on the CentOS side but
> nothing hard and we expect to be able to migrate the first volunteer projects 
> by
> early next week.
> 
> Once the first migrations have happened and the first rough edges have been
> smoothed we will be announcing an official retirement date for
> jenkins.fedorainfracloud.org and migrate all the projects hosted there to
> ci.centos.org, and of course help with the potential questions raising from
> this.

Will there be a standard / automated migration path for projects that
have followed documented steps to implement a CI workflow through this
Jenkins instance, like these:

https://docs.pagure.org/pagure/usage/pagure_ci_jenkins.html

? Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

provenpackager request: Re: [HEADS UP] opencv 3.3.1 is going to rawhide

[Sérgio Basto]

Packages remaining to rebuild:
digikam
fawkes
kf5-libkface
nomacs
player
simon

Provenpackager request for: 

Merge and fedpkg build [1] and [2] in master branch. 
Do fedpkg build in fawkes master [3] 

[1]
https://src.fedoraproject.org/rpms/nomacs/pull-request/1
[2]
https://src.fedoraproject.org/rpms/simon/pull-request/1
[3]
https://src.fedoraproject.org/rpms/fawkes/commits/master

Best regards,

On Sun, 2017-12-31 at 19:56 +, Sérgio Basto wrote:
> On Sat, 2017-12-23 at 15:23 +, Sérgio Basto wrote:
> > Hello. 
> > I'm going submit  opencv 3.1 in rawhide to fix a lots of CVE(s) [1]
> > and
> > new feature also have a new module with compatibly with mlt 
> > TBH I though/expect someone from RedHat take care of it . 
> >  
> > I will send more new after the submit about  broken deps and proven
> > packages required 
> > 
> > dnf repoquery --disablerepo='*' --enablerepo=rawhide --whatrequires
> > opencv\*  --alldeps --qf "%{sourcerpm} %{repoid}"  
> > 
> > OpenImageIO-1.7.17-2.fc28.src.rpm rawhide
> > YafaRay-3.3.0-3.fc28.src.rpm rawhide
> > digikam-5.7.0-3.fc28.src.rpm rawhide
> > fawkes-1.0.1-13.fc28.src.rpm rawhide
> > frei0r-plugins-1.6.1-2.fc27.src.rpm rawhide
> > gmic-1.7.2-5.fc27.src.rpm rawhide
> > libfreenect-0.5.5-2.fc27.src.rpm rawhide
> > mlt-6.5.0-0.6.20171114git73bfefd.fc28.src.rpm rawhide
> > mrpt-1.4.0-5.fc28.src.rpm rawhide
> > nomacs-3.6.1-5.fc28.src.rpm rawhide
> > opencv-3.2.0-13.fc28.src.rpm rawhide
> > os-autoinst-4.5-1.20171220git25191d5.fc28.src.rpm rawhide
> > php-facedetect-1.1.0-9.fc28.src.rpm rawhide
> > player-3.1.0-4.fc27.src.rpm rawhide
> > shogun-6.0.0-5.fc27.src.rpm rawhide
> > simarrange-0.0-12.20170309git3300eb5.fc27.src.rpm rawhide
> > simon-0.4.1-11.fc27.src.rpm rawhide
> > siril-0.9.7-1.fc28.src.rpm rawhide
> > 
> > [1]
> > https://bugzilla.redhat.com/show_bug.cgi?id=1484397
> > 
> 
> A new repoquery  [1], the previous one just work when we don't have
> brokendeps (I think) , brokendeps calculated with script in attach : 
> 
> digikam
> fawkes
> frei0r-plugins
> gmic
> kf5-libkface
> libfreenect
> mlt
> mrpt
> nomacs
> OpenImageIO
> os-autoinst
> php-facedetect
> player
> simarrange
> simon
> siril
> YafaRay
> 
> 
> Packages remaining to rebuild: 
>  
> digikam
> fawkes
> gmic
> kf5-libkface
> nomacs
> OpenImageIO
> os-autoinst
> player
> simon
> 
> [1]
> dnf repoquery --disablerepo='*' --enablerepo=rawhide --whatrequires
> "libopencv*"  --alldeps --srpm --quiet | sed 's|\(-[^-
> ]\+\)\{2\}.src||' 
> > sort -u  
> 
> Happy new year
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1528821] ack-2.22 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||ack-2.22-1.fc26
 Resolution|--- |ERRATA
Last Closed||2018-01-09 11:49:03



--- Comment #9 from Fedora Update System  ---
ack-2.22-1.fc26 has been pushed to the Fedora 26 stable repository. If problems
still persist, please make note of it in this bug report.

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

[Bug 1528493] perl-Time-HiRes-1.9749 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Time-HiRes-1.9749-1.fc26 has been pushed to the Fedora 26 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1528276] perl-CPAN-Perl-Releases-3.44 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-CPAN-Perl-Releases-3.44-1.fc26 has been pushed to the Fedora 26 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1528483] perl-Module-CoreList-5.20171220 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-Module-CoreList-5.20171220-1.fc26 has been pushed to the Fedora 26 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1528090] perl-Module-Manifest-1.09 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-Module-Manifest-1.09-1.fc26 has been pushed to the Fedora 26 stable
repository. If problems still persist, please make note of it in this bug
report.

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

[Bug 1526665] perl-PPI-XS-0.910 is available

[bugzilla]

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



--- Comment #6 from Fedora Update System  ---
perl-PPI-XS-0.910-1.fc26 has been pushed to the Fedora 26 stable repository. If
problems still persist, please make note of it in this bug report.

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

Re: F28 Self Contained Change: Anaconda modularization

[Matthew Miller]

On Tue, Jan 09, 2018 at 05:17:40PM +0100, Martin Kolman wrote:
> As mentioned by jkonecny, we have updated the change page, including
> the contingency plan.

Thanks -- that's much more clear. And I see the deadline has been moved
back to a week before Final Freeze. Sounds good to me assuming QA feels
comfortable with this.

-- 
Matthew Miller

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

Re: F28 Self Contained Change: Anaconda modularization

[Martin Kolman]

On Mon, 2018-01-08 at 09:01 -0500, Matthew Miller wrote:
> On Mon, Jan 08, 2018 at 07:04:31AM -0500, Martin Kolman wrote:
> > Yep - basically, there will be no "old" and "new, DBUS/modular"
> > Anaconda, the plan is to turn the current Anaconda to the new one one
> > step at a time.
> > 
> > This should allow us to fix bugs as usual and handle any unforeseen
> > modularization issues early on one-by-one as they show up.
> 
> It sounds like there actually isn't a contingency plan as such. Do you
> think that this could all be reverted on Final Freeze day if we would
> decide it's not working out? If not, let's not call that a contingency.
> 
> I'm not saying we shouldn't do this, but let's be honest with
> ourselves. If the contingency plan is "None: we'll have to hold up the
> release for fixes if it's not ready", the Change plan should say that.
As mentioned by jkonecny, we have updated the change page, including the 
contingency plan.

The idea is that we will kreate a fallback branch just before we enable the 
first modularization
changes and keep the fallback branch functional by backporting critical fixes 
and blockers.

The master branch (and after branching the f28-branch) will host the 
incremental modularization
work and will be used for Rawhide/F28 Anaconda builds.

If everything works fine, the fallback branch will not be needed and will be 
discontinued after F28 GA.

If we need to activate the contingency plan, we will switch F28 Anaconda builds 
to the fallback branch,
effectively falling back to the non-modularized code for the F28 timeframe.

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

Claiming a retired package: gcin

[Zamir SUN]

Hi,

Based on the claiming guideline[1], I am writing to claim the package
gcin. The package gcin was retired because previous maintainer cicku was
not responsive at that time[2]. Since I hear this package is still
useful for some users, I updated the spec file and filed a review
request here[3].

Thanks.


[1]
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package
[2]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/4LK26PNK22QTNVSZ26KWIFA5G4SXUHWC/
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1532696
-- 
Ziqian SUN (Zamir)
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
Want to know more about Fedora?
Visit https://fedoraproject.org/wiki/
Ready to contribute? See https://whatcanidoforfedora.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Test-Announce] Call for testing: updates to address today's CPU/kernel vulnerability

[Matthew Miller]

On Tue, Jan 09, 2018 at 08:44:50AM -0600, Justin Forbes wrote:
> > Does this mean we should do a mass rebuild once those patches have
> > landed? We have a mass rebuild scheduled for Jan 31st (basically three
> > weeks from now). Is that too soon?
> I do not have an answer to this just yet.  I mean theoretically yes,
> retpoline goes into GCC, packages are changed to use the features, and
> a mass rebuild happens. More likely retpoline goes into gcc, and a
> subset of important packages are rebuilt to utilize it. As for timing,
> no clue.  When I asked Jakub about retpoline for Fedora gcc, he said
> the patches hadn't even been posted to the gcc list for review yet.
> That has now happened, but I haven't been following the review on that
> end yet.  I am hoping to get some more answers on retpoline over the
> next couple of days.

Thanks. I hate to say this, because I really value predictable
releases, but we should at least put delaying the mass rebuild for this
into consideration, depending on what the GCC and security teams say.

-- 
Matthew Miller

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

Re: Enabling smoother upgrades in the face of multilib compose changes

[Florian Weimer]

On 01/09/2018 03:16 PM, Igor Gnatenko wrote:


So after all I would file bug against DNF to automatically mark all packages
from non-primary arch (given they are non-noarch) as allowuinstall.


I don't really understand what you wrote.

I doubt there is an automated solution without packaging changes because 
DNF does not know that both glibc-headers are equivalent, so both could 
have been installed deliberately, and removing one automatically would 
be wrong.


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

Re: rpcgen?

[Florian Weimer]

On 01/09/2018 03:32 PM, Steve Dickson wrote:



On 01/09/2018 06:10 AM, Richard W.M. Jones wrote:


https://fedoraproject.org/w/index.php?title=Changes/SunRPCRemoval=508864
says:

   "Packages which need rpcgen will have to add BuildRequires: libtirpc-devel to 
their spec files."

but libtirpc-devel (1.0.2-4.fc28.x86_64) doesn't contain rpcgen.

Nor will it... There is going to be a new package call rpcsvc-proto
that will contain the rpcgen command along with other things
like header files... There is the upstream git tree:
http://github.com/thkukuk/rpcsvc-proto

Here is the Review Request for the package, if interested.
https://bugzilla.redhat.com/show_bug.cgi?id=1532364


Note that the plan is that the new package will provide rpcgen, so you 
can just use


BuildRequires: rpcgen

and you'll get the new package once it becomes available.

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

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Pavel Březina]

On 01/05/2018 05:21 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Fri, Jan 05, 2018 at 02:50:45PM +0100, Jan Kurik wrote:

= System Wide Change: Make authselect default tool instead of authconfig =
https://fedoraproject.org/wiki/Changes/AuthselectAsDefault


Does this change do anything to reduce the number of files in /etc
that do not contain local configuration? PAM is currently one of the
worst offenders, with /etc/pam.d full of "configuration" files.


No. The files must stay since it would require changes in pam itself and 
that is out of scope of authselect. Each file corresponds to individual 
pam service and is read when pam_start(service_name, ...) is called.



Elsewhere in the thread /usr/share/authselect/custom is metioned as
directory for admin config. That's OK-ish, as long as you also allow
a directory in /etc for the same purpose. /usr must be allowed to be
immutable.


Would /usr/local be OK as well?



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


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

Re: F28 Self Contained Change: Anaconda modularization

[jkonecny]

Hi all,

Based on the feedback we modified the change:

* There is a more formal contingency plan in place.
* Contingency deadline is moved one week earlier.
* Detailed description contains explanation of what we want to achieve
for F28. We don't aim to have everything in F28.
* It is System Wide Change now.


Thank you all for your feedback,
Jirka
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Binutils version 2.29.1

[Tomasz Torcz ️]

On Tue, Jan 09, 2018 at 12:11:31PM +0100, Jan Kurik wrote:
> = System Wide Change: Binutils version 2.29.1 =
> https://fedoraproject.org/wiki/Changes/BINUTILS2291
> 
> Change owner(s):
> * Nick Clifton 
> 
> Rebase the binutils package from version 2.29 to version 2.29.1. This
> will bring in the bug-fixes from the 2.29.1 point release, but not add
> any new features.
> 

> Change the source parameter in the binutils.spec rpm and adjust the
> local patches to take account of the bugs that are now already fixed.

  I'm a bit perplexed by this change.  It looks like minor version
 update, in such case it need no to be announced so widely.
  On the other hand, you are changing the source.  According to the
 guidelines, changing source requires re-review.
  So why this is a system-wide change?


-- 
Tomasz TorczOnly gods can safely risk perfection,
xmpp: zdzich...@chrome.pl it's a dangerous thing for a man.  -- Alia
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Test-Announce] Call for testing: updates to address today's CPU/kernel vulnerability

[Justin Forbes]

On Mon, Jan 8, 2018 at 7:27 PM, Matthew Miller  wrote:
> On Mon, Jan 08, 2018 at 04:49:44PM -0600, Justin Forbes wrote:
>> combination of the 2.  Unfortunately both have external requirements.
>> Retpoline requires GCC patches, and microcode updates for some CPUs.
>> IBRS requires microcode updates. While RHEL has done quite a bit of
>
> Does this mean we should do a mass rebuild once those patches have
> landed? We have a mass rebuild scheduled for Jan 31st (basically three
> weeks from now). Is that too soon?
>
I do not have an answer to this just yet.  I mean theoretically yes,
retpoline goes into GCC, packages are changed to use the features, and
a mass rebuild happens. More likely retpoline goes into gcc, and a
subset of important packages are rebuilt to utilize it. As for timing,
no clue.  When I asked Jakub about retpoline for Fedora gcc, he said
the patches hadn't even been posted to the gcc list for review yet.
That has now happened, but I haven't been following the review on that
end yet.  I am hoping to get some more answers on retpoline over the
next couple of days.

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

Re: rpcgen?

[Steve Dickson]

On 01/09/2018 06:10 AM, Richard W.M. Jones wrote:
> 
> https://fedoraproject.org/w/index.php?title=Changes/SunRPCRemoval=508864
> says:
> 
>   "Packages which need rpcgen will have to add BuildRequires: libtirpc-devel 
> to their spec files."
> 
> but libtirpc-devel (1.0.2-4.fc28.x86_64) doesn't contain rpcgen.
Nor will it... There is going to be a new package call rpcsvc-proto 
that will contain the rpcgen command along with other things 
like header files... There is the upstream git tree:
   http://github.com/thkukuk/rpcsvc-proto

Here is the Review Request for the package, if interested. 
   https://bugzilla.redhat.com/show_bug.cgi?id=1532364

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

Re: Enabling smoother upgrades in the face of multilib compose changes

[Igor Gnatenko]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, 2018-01-09 at 15:05 +0100, Florian Weimer wrote:
> On 01/09/2018 03:01 PM, Igor Gnatenko wrote:
> > Well, from my user perspective I think they are supported "as long as it
> > works". The multilib generation is very hacky/tricky.
> > 
> > I would open a ticket for releng to fix such issues.
> 
> I don't think there is anything wrong with the composes.  It is not 
> necessary to install glibc-headers.i686 and glibc-headers.x86_64 in 
> parallel.  It's just that those who have done so in the past are now 
> stuck with the i686 package.

This is easy to play with..

repo system 0 testtags 
#>=Pkg: foo 1 1 i686
#>=Pkg: foo 1 1 x86_64
#>=Pkg: wine 1 1 x86_64
#>=Req: foo
repo available 0 testtags 
#>=Pkg: foo 2 1 x86_64

system x86_64 rpm system

poolflags implicitobsoleteusescolors
solverflags allowvendorchange keepexplicitobsoletes bestobeypolicy keeporphans
yumobsoletes

job update all packages [forcebest]
result transaction,problems 
#>problem f47534b4 info cannot install both foo-2-1.x86_64 and foo-1-1.x86_64
#>problem f47534b4 solution 0fb8e991 allow foo-1-1.i686@system
#>problem f47534b4 solution 14ee0c1c allow foo-1-1.x86_64@system
#>problem f47534b4 solution 4d28f814 erase foo-1-1.i686@system
#>upgrade foo-1-1.x86_64@system foo-2-1.x86_64@available

nextjob

job update all packages [forcebest]
job allowuninstall pkg foo-1-1.i686@system
result transaction,problems 
#>erase foo-1-1.i686@system
#>upgrade foo-1-1.x86_64@system foo-2-1.x86_64@available


So after all I would file bug against DNF to automatically mark all packages
from non-primary arch (given they are non-noarch) as allowuinstall.
- -- 
- -Igor Gnatenko
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlpUzr0ACgkQaVcUvRu8
X0yt8w/9GrJ0nbo1/UUZb2o/7ekFltni7i26qq7YvWM2WkAz1xsrtVVpti2rz8Ee
pX/LeNn4vyrwts4S5v+z3KtOsfhDQWzCwTwa76sSqB+Hket4MrrcD64ILJvCQ4cx
dNZ4qOQglFZJ69Jz1f9NbcBnMp5/98YohkoavWP+f17MofIXBEP0vS5SwD/OPGpa
/CL+C2L6tWjtY+b3z5+zzwQNDFsRaYMOtVRq/0Xy/wWSFSqp/c+t7ZsWylQplO4v
N7ALCTpO3kx3XnTWc1BIiHN4HlvwB8O3/u2xDFMSv7ltP76e5W0Tq30xqg1ITPlg
cHQ/rT/BMQizYFGLk+GyXcWJ2l3JdRoGDdeiCdBS1lAYU20xW/AqS3RXg3mhjSiM
AniyT2yusTf4C8v0FbdukOOtaXVCOssX/mVD96bTijUmAt7ThsPHxMHp+sl+KGzZ
lEiLNFDSY4a8UlBlAPLDwvw0j0F7uw6lfHLO1tz0fOYq73wjMAlGtXceDC1T/Z01
MV4eWqpWtF/egc/FvAnJkJACzF6ocn+NzbEzoho/DeER8s7+H/NVoPN6r4YZyro/
j7IIpiVIF0ruWVjoPNhMqmHRs1ziN2wfDGEw4ZHWQq3817EPVbhW8Bna6CdTBMB/
1xPYVBwBa7SOOMUCIVDNX9/t9PFI/LjvC9H/k8452XCwsYzdKNU=
=JP+8
-END PGP SIGNATURE-
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc

[Charalampos Stratakis]

- Original Message -
> From: "Florian Weimer" 
> To: "Development discussions related to Fedora" 
> , "Charalampos Stratakis"
> 
> Sent: Tuesday, January 9, 2018 12:30:39 PM
> Subject: Re: F28 System Wide Change: Removal of Sun RPC Interfaces From glibc
> 
> On 01/09/2018 11:32 AM, Charalampos Stratakis wrote:
> > Python is currently being addressed upstream [0] and the fix will be
> > backported soon to fedora's packages.
> > 
> > [0]https://github.com/python/cpython/pull/5137
> 
> Has this been tested on OpenSUSE or Gentoo (I think either has already
> fully made the transition)?
> 
> I'm asking we still have some NIS bits sticking around, and we need to
> remove° them as well for the transition to an IPv6-capable NIS.
> 
> ° As usual, we'll keep support existing binaries.
> 
> Thanks,
> Florian
> 

It seems that there was a previous bug report about the same issue for gentoo 
[0][1].

Python doesn't actually fail to build, it's that it utilizes those headers to 
build a specific module (which is not really used nowadays).

And upstream is in favor of deprecating the module that requires those headers.

[0] https://bugs.python.org/issue32007
[1] https://bugs.gentoo.org/631488

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F28 System Wide Change: IBus Unicode Typing

[Jan Kurik]

= System Wide Change: IBus Unicode Typing =
https://fedoraproject.org/wiki/Changes/IBus_Unicode_Typing

Change owner(s):
* Takao Fujiwara 

IBus core provides an Emoji dialog which users can type emoji
annotations and output the emoji character using IBus (E.g. Typing
"football" shows U+26BD). The proposal is the dialog also supports to
type Unicode names (E.g. Typing "copyright sign" shows U+00A9).


== Detailed Description ==
IBus core provides an Emoji dialog and it can be launched with
Ctrl-Shift-e shortcut key in non-GNOME desktop and `ibus emoji`
command is available for GNOME desktop [1]. Users can select an emoji
in emoji lists on the emoji dialog or type an emoji annotation in an
input entry on the emoji dialog and output the selected emoji using
IBus.

The proposal is that emoji dialog also supports to type Unicode names
in the input entry and output the selected Unicode character.

E.g. Typing "copyright sign" shows U+00A9

[1] because gnome-shell has its owned keyboard indicator instead of
/usr/libexec/ibus-ui-gtk3 and GTK itself also has the similar emoji
dialog and the emoji implementation is under the consideration in
GNOME.



== Scope ==
* Proposal owners:
IBus core will include the dictionary of Unicode names

* Other developers:
N/A

* Release engineering:
https://pagure.io/releng/issue/7255

* List of deliverables:
N/A

* Policies and guidelines:
N/A

* Trademark approval:
N/A
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F28 System Wide Change: Fedora 28 Boost 1.66 upgrade

[Jan Kurik]

= System Wide Change: Fedora 28 Boost 1.66 upgrade =
https://fedoraproject.org/wiki/Changes/F28Boost166

Change owner(s):
* Jonathan Wakely 

This change brings Boost 1.66.0 to Fedora 28. This will mean F28 ships
with a recent upstream Boost release.


== Detailed Description ==
The aim is to synchronize Fedora with the most recent Boost release.
Because ABI stability is one of explicit Boost non-goals, this entails
rebuilding of all dependent packages. This has also always entailed
yours truly assisting maintainers of client packages in decoding
cryptic boost-ese seen in output from g++. Such care is to be expected
this time around as well.

The equivalent changes for previous releases were Fedora 22 Change and
Fedora 23 Change and Fedora 24 Change and Fedora 26 Change and Fedora
27 Change.


== Scope ==
* Proposal owners:
- Build will be done with Boost.Build v2 (which is the
upstream-sanctioned way of building Boost)
- Request a "f28-boost" build system tag (discussion):
https://fedorahosted.org/rel-eng/ticket/6235 → f24-boost
- Build boost into that tag (take a look at the build #606493 for inspiration)
- Post a request for rebuilds to fedora-devel
- Work on rebuilding dependent packages in the tag.
- When most is done, re-tag all the packages to rawhide
- Watch fedora-devel and assist in rebuilding broken Boost clients (by
fixing the client, or Boost).

* Other developers:
Those who depend on Boost DSOs will have to rebuild their packages.
Feature owners will alleviate some of this work as indicated above,
and will assist those whose packages fail to build in debugging them.

* Release engineering:
#7254 https://pagure.io/releng/issue/7254

* List of deliverables:
All deliverables will include updated Boost packages

* Policies and guidelines:
Apart from scope, this is business as usual, so no policies, no guidelines.

* Trademark approval:
N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

Re: Enabling smoother upgrades in the face of multilib compose changes

[Florian Weimer]

On 01/09/2018 03:01 PM, Igor Gnatenko wrote:

Well, from my user perspective I think they are supported "as long as it
works". The multilib generation is very hacky/tricky.

I would open a ticket for releng to fix such issues.


I don't think there is anything wrong with the composes.  It is not 
necessary to install glibc-headers.i686 and glibc-headers.x86_64 in 
parallel.  It's just that those who have done so in the past are now 
stuck with the i686 package.


This is not releng issue #4048, it's different.

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

F28 System Wide Change: OpenLDAP defaults to use only Shared System Certificates

[Jan Kurik]

= System Wide Change: OpenLDAP defaults to use only Shared System Certificates =
https://fedoraproject.org/wiki/Changes/OpenLDAPdefaultSharedSystemCertificates

Change owner(s):
* Matus Honek 

In order to go forward with adoption of SharedSystemCertificates [1]
after this change OpenLDAP clients and server will default to use only
the system-wide certificates store.


== Detailed Description ==
Currently, OpenLDAP defaults to trust CA certificates located in
/etc/openldap/certs. In order to comply with SharedSystemCertificates
[1] we will remove the default explicit configuration options that
point to /etc/openldap/certs. Therefore, OpenLDAP will let its crypto
library (OpenSSL) load the default CA certificates as described in the
SharedSystemCertificates [1] description. For a convenience, where
possible, configuration files will contain a commentary with an
explanation of the new behaviour.


== Scope ==
* Proposal owners:
change of default shipped configuration.

* Other developers:
check your application trusts whom you want it to trust

* Release engineering:
https://pagure.io/releng/issue/7252

* List of deliverables:
N/A

* Policies and guidelines:
None.

* Trademark approval:
None. (not needed for this Change).



[1] https://fedoraproject.org/wiki/Features/SharedSystemCertificates
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F28 System Wide Change: OpenLDAP without Non-threaded Libraries

[Jan Kurik]

= System Wide Change: OpenLDAP without Non-threaded Libraries =
https://fedoraproject.org/wiki/Changes/OpenLDAPwithoutNonthreadedLibraries

Change owner(s):
* Matus Honek 

OpenLDAP will not ship non-threaded versions of its libraries.
Instead, it will link these to their threaded counterparts.


== Detailed Description ==
After this change the non-threaded versions of OpenLDAP libraries will
not be shipped any more. Instead, these file will rather symlink to
their threaded representatives (i.e. libldap -> libldap_r, etc.). This
has been previously discussed in [Bugzilla] and other distributions
where this change already happened. Upstream still supports
non-threaded versions of their libraries as these might be used on
processors where threads are not supported. However, when these two
versions happen to be loaded at the same time (as discussed about Curl
in the Bugzilla [https://bugzilla.redhat.com/show_bug.cgi?id=1370065])
symbol names overlap which may result in unpredictable behaviour. As
the most convenient solution arises the one proposed hereby.

== Scope ==
* Proposal owners:
update SPEC file so that some files are not shipped and replaced with
appropriate symlinks.

* Other developers:
None. Issues should not occur.

* Release engineering:
https://pagure.io/releng/issue/7253

* List of deliverables:
N/A

* Policies and guidelines:
None.

* Trademark approval:
(not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org