Re: python2->python3 mass rebuild and auto tools

[Miro Hrončok]

On 01. 08. 19 23:44, Steve Grubb wrote:

On Thursday, August 1, 2019 4:37:01 AM EDT Miro Hrončok wrote:

On 01. 08. 19 4:43, Steve Grubb wrote:

Audit. But is seems that autotools shoul hard code the old sematics so
that all packages do the right thing. It seems that python3 equivalents
have been introduced. They do the right thing with the python migration.
But there are things that are expectd to defaulto python 2.


https://src.fedoraproject.org/rpms/audit/pull-request/4

Autotools usually already does the right thing, aka choosing python2 if it
cannot find python. Using "python" in Fedora packages is forbidden anyway.


I applied your patch. Thanks.

But I am concerned that this is a bandaid because it patches the spec file and
all distributions will have to do the same thing.


How does this Fedora impact other distributions?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: friday roundup of failing images in rawhide

[Luya Tshimbalanga]

On 2019-07-19 6:16 p.m., Kevin Fenzi wrote:
> hey folks, here is a list of currently failing images in rawhide. > Please 
> fix if you can. > > 1. design-suite lab: >
https://koji.fedoraproject.org/koji/taskinfo?taskID=36353212 > >
probibly should drop sparkleshare, or someone needs to fix it: > >
Problem: conflicting requests > - nothing provides mono(gdk-sharp) =
3.0.0.0 needed by > sparkleshare-1.5.0-5.fc30.x86_64 > - nothing
provides mono(glib-sharp) = 3.0.0.0 needed by >
sparkleshare-1.5.0-5.fc30.x86_64 > - nothing provides mono(gtk-sharp) =
3.0.0.0 needed by > sparkleshare-1.5.0-5.fc30.x86_64 > - nothing
provides mono(gio-sharp) = 3.0.0.0 needed by >
sparkleshare-1.5.0-5.fc30.x86_64 > - nothing provides mono(pango-sharp)
= 3.0.0.0 needed by > sparkleshare-1.5.0-5.fc30.x86_64 > Bug filed
https://bugzilla.redhat.com/show_bug.cgi?id=1731619

It appears the current packaged version is far behind the upstream
release. It would be nice a proven package release an updated version.


Luya


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

Re: python2->python3 mass rebuild and auto tools

[Steve Grubb]

On Thursday, August 1, 2019 6:37:47 PM EDT Miro Hrončok wrote:
> On 01. 08. 19 23:44, Steve Grubb wrote:
> > On Thursday, August 1, 2019 4:37:01 AM EDT Miro Hrončok wrote:
> >> On 01. 08. 19 4:43, Steve Grubb wrote:
> >>> Audit. But is seems that autotools shoul hard code the old sematics so
> >>> that all packages do the right thing. It seems that python3 equivalents
> >>> have been introduced. They do the right thing with the python
> >>> migration.
> >>> But there are things that are expectd to defaulto python 2.
> >> 
> >> https://src.fedoraproject.org/rpms/audit/pull-request/4
> >> 
> >> Autotools usually already does the right thing, aka choosing python2 if
> >> it
> >> cannot find python. Using "python" in Fedora packages is forbidden
> >> anyway.
> > 
> > I applied your patch. Thanks.
> > 
> > But I am concerned that this is a bandaid because it patches the spec
> > file and all distributions will have to do the same thing.
> 
> How does this Fedora impact other distributions?

Because eventually we all (distros) have to go through it. So, if autotools 
handled this gracefully, I and everyone else would have a configure.ac file and 
Makefile.am that just does the right thing. So, I am faced with making an 
announcement on my project's mail list that maintainer on other distros have 
to do this hack because autotools is incapable of doing the right thing. 
There is no migration plan for autotools. We could have got in front of this 
and helped make it smooth.

My package is now built in rawhide thanks to your patch. Fedora is OK. I just 
worry about bug reports rolling in on other distros upstream.

-Steve


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

Re: python2->python3 mass rebuild and auto tools

[Miro Hrončok]

On 02. 08. 19 5:21, Steve Grubb wrote:

On Thursday, August 1, 2019 6:37:47 PM EDT Miro Hrončok wrote:

On 01. 08. 19 23:44, Steve Grubb wrote:

On Thursday, August 1, 2019 4:37:01 AM EDT Miro Hrončok wrote:

On 01. 08. 19 4:43, Steve Grubb wrote:

Audit. But is seems that autotools shoul hard code the old sematics so
that all packages do the right thing. It seems that python3 equivalents
have been introduced. They do the right thing with the python
migration.
But there are things that are expectd to defaulto python 2.


https://src.fedoraproject.org/rpms/audit/pull-request/4

Autotools usually already does the right thing, aka choosing python2 if
it
cannot find python. Using "python" in Fedora packages is forbidden
anyway.


I applied your patch. Thanks.

But I am concerned that this is a bandaid because it patches the spec
file and all distributions will have to do the same thing.


How does this Fedora impact other distributions?


Because eventually we all (distros) have to go through it. So, if autotools
handled this gracefully, I and everyone else would have a configure.ac file and
Makefile.am that just does the right thing. So, I am faced with making an
announcement on my project's mail list that maintainer on other distros have
to do this hack because autotools is incapable of doing the right thing.


Oh, now I understand. Sorry for the confusion.

I don't really understand autotools that much, but I'm quite confident that 
there is A Proper Way™ to have --with-python2 and --with-python3 (instead of 
--with-python). I've seen projects in Fedora have that.


Hopefully somebody more experienced in autotools can help here.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Orphaned pykalman---inactive upstream

[Ankur Sinha]

Hello,

pykalman is no longer maintained upstream. I have, therefore, orphaned
it.
https://src.fedoraproject.org/rpms/python-pykalman

It is now suggested to use other libraries:
https://github.com/pykalman/pykalman/issues/86

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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

Re: python2->python3 mass rebuild and auto tools

[Miro Hrončok]

On 02. 08. 19 10:57, Miro Hrončok wrote:

On 02. 08. 19 5:21, Steve Grubb wrote:

On Thursday, August 1, 2019 6:37:47 PM EDT Miro Hrončok wrote:

On 01. 08. 19 23:44, Steve Grubb wrote:

On Thursday, August 1, 2019 4:37:01 AM EDT Miro Hrončok wrote:

On 01. 08. 19 4:43, Steve Grubb wrote:

Audit. But is seems that autotools shoul hard code the old sematics so
that all packages do the right thing. It seems that python3 equivalents
have been introduced. They do the right thing with the python
migration.
But there are things that are expectd to defaulto python 2.


https://src.fedoraproject.org/rpms/audit/pull-request/4

Autotools usually already does the right thing, aka choosing python2 if
it
cannot find python. Using "python" in Fedora packages is forbidden
anyway.


I applied your patch. Thanks.

But I am concerned that this is a bandaid because it patches the spec
file and all distributions will have to do the same thing.


How does this Fedora impact other distributions?


Because eventually we all (distros) have to go through it. So, if autotools
handled this gracefully, I and everyone else would have a configure.ac file and
Makefile.am that just does the right thing. So, I am faced with making an
announcement on my project's mail list that maintainer on other distros have
to do this hack because autotools is incapable of doing the right thing.


Oh, now I understand. Sorry for the confusion.

I don't really understand autotools that much, but I'm quite confident that 
there is A Proper Way™ to have --with-python2 and --with-python3 (instead of 
--with-python). I've seen projects in Fedora have that.


Hopefully somebody more experienced in autotools can help here.


I've tried https://github.com/linux-audit/audit-userspace/pull/102 but honestly 
have no idea if I'm not reinventing the wheel.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: systemd-243-rc1

[Fabio Valentini]

On Fri, Aug 2, 2019, 11:33 Adam Williamson 
wrote:

> On Thu, 2019-08-01 at 14:36 +0200, Nicolas Mailhot via devel wrote:
> > Le jeudi 01 août 2019 à 14:19 +0200, Lennart Poettering a écrit :
> > > On Do, 01.08.19 10:14, Fabio Valentini (decatho...@gmail.com) wrote:
> > >
> > > > Since these things are both the case, a simple 1:1 mapping from "-"
> > > > to
> > > > "~" (and even back) is exactly correct.
> > > > So I think the systemd.spec is doing exactly the right thing here.
> > > >
> > > > The only issue I see is the arbitrary (?) restriction that git tags
> > > > cannot contain the tilde character.
> > > > Or is that there for filesystem compatibility, because tags are
> > > > just files?
> > >
> > > git uses "~" for referencing commits relative to a commit identifier,
> > > see:
> > >
> > >
> https://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse.txt-emltrevgtltngtemegemHEADmaster3em
> > >
> > > Hence they do not allow it in tag names, to avoid the ambiguity.
> > >
> > > I guess RPM is the outlier for using ~ the way it uses it, I don't
> > > think much other software does that.
> >
> > ~ is a debianism, introduced in rpm because some felt it was going to
> > satisfy uptream needs for irregular preversiob versioning
> >
> > what rpm likes, and pretty much all component management stacks like
> > and support, is pure series of numbers separated with dots, without the
> > -foo pre-version madness that breaks everywhere in slightly different
> > ways.
> >
> > Don't release anything that is not a series of numbers separated with
> > dots, no one ever managed to define anything else that works for
> > everyone (and many tried).
> >
> > The preversion in semver is basically "it will break right and left,
> > who cares, no one will use it". Written by idealists that forgot the
> > point of preversions is to be used and deployed so some testing is done
> > before final release.
>
> Hmm. I never really chipped into the ~ discussion, but it just occurred
> to me it intersects with a discussion I care quite a lot about: RPM
> version comparison. Especially RPM version comparison when all you have
> to deal with is a string that represents an RPM N(E)VR(A) somehow
> (that's 'name', 'epoch', 'version', 'release', 'arch').
>
> This is a corner case quite a few of us run into (it can happen for
> e.g. when you're working off a fedmsg which just gives you a NEVRA
> string) and it has some surprising properties, like: there isn't really
> a 'good' standard way to do it. RPM doesn't expose this in its public
> APIs. The best way anyone seems to know of to do it in Python, for
> instance, is using `hawkey.split_nevra`...only hawkey is a bit weird,
> it's provided by libdnf and is not in pypi, which means running tests
> on code that uses it using standard stuff like tox-in-a-container is
> difficult. Also, DNF folks have suggested they want it to go away.
>
> You can split a N(E)VR(A) string into components quite easily and
> reliably with standard string manipulations, but comparing the
> components the way RPM does it is difficult to re-implement...and of
> course, the more weird rules like ~ we introduce, the harder it gets.
>
> Anyhow, it occurred to me to try out how hawkey.split_nevra handles
> this tilde scenario, and the answer seems to be "a bit oddly":
>
> >>> tildenevra = hawkey.split_nevra('systemd-243~rc1-1.fc31')
> >>> releasenevra = hawkey.split_nevra('systemd-243-1.fc31')
> >>> releasenevra > tildenevra
> True
> >>> releasenevra.version
> '243'
> >>> tildenevra.version
> '243~rc1'
> >>> releasenevra.version > tildenevra.version
> False
> >>> tildenevra.version > releasenevra.version
> True
>
> So...basically, it thinks the entire NEVRA object you get from the
> string 'systemd-243-1.fc31' is "higher versioned" than the NEVRA object
> you get from the string 'systemd-243~rc1-1.fc31'. Which is good, that's
> correct. However, it thinks the version component of 'systemd-243~rc1-
> 1.fc31' is higher than the version component of 'systemd-243-1.fc31'.
> Which I believe is wrong, and also, it's a bit baffling, because if it
> thinks that, I don't understand how it gets to the (correct) conclusion
> that the entire tildenevra is lower versioned than the releasenevra,
> since the 'name' and 'epoch' ('systemd' and 0, respectively) are the
> same for both...
>
> Anyone see what I'm missing?
>

You have to be careful with comparisons here. if the .version attribute is
just a string, then python will do just a string comparison (which is
sometimes wrong compared to RPM version comparisons).

Fabio

-- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-c

Re: systemd-243-rc1

[Fabio Valentini]

On Fri, Aug 2, 2019, 11:39 Fabio Valentini  wrote:

> On Fri, Aug 2, 2019, 11:33 Adam Williamson 
> wrote:
>
>> On Thu, 2019-08-01 at 14:36 +0200, Nicolas Mailhot via devel wrote:
>> > Le jeudi 01 août 2019 à 14:19 +0200, Lennart Poettering a écrit :
>> > > On Do, 01.08.19 10:14, Fabio Valentini (decatho...@gmail.com) wrote:
>> > >
>> > > > Since these things are both the case, a simple 1:1 mapping from "-"
>> > > > to
>> > > > "~" (and even back) is exactly correct.
>> > > > So I think the systemd.spec is doing exactly the right thing here.
>> > > >
>> > > > The only issue I see is the arbitrary (?) restriction that git tags
>> > > > cannot contain the tilde character.
>> > > > Or is that there for filesystem compatibility, because tags are
>> > > > just files?
>> > >
>> > > git uses "~" for referencing commits relative to a commit identifier,
>> > > see:
>> > >
>> > >
>> https://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse.txt-emltrevgtltngtemegemHEADmaster3em
>> > >
>> > > Hence they do not allow it in tag names, to avoid the ambiguity.
>> > >
>> > > I guess RPM is the outlier for using ~ the way it uses it, I don't
>> > > think much other software does that.
>> >
>> > ~ is a debianism, introduced in rpm because some felt it was going to
>> > satisfy uptream needs for irregular preversiob versioning
>> >
>> > what rpm likes, and pretty much all component management stacks like
>> > and support, is pure series of numbers separated with dots, without the
>> > -foo pre-version madness that breaks everywhere in slightly different
>> > ways.
>> >
>> > Don't release anything that is not a series of numbers separated with
>> > dots, no one ever managed to define anything else that works for
>> > everyone (and many tried).
>> >
>> > The preversion in semver is basically "it will break right and left,
>> > who cares, no one will use it". Written by idealists that forgot the
>> > point of preversions is to be used and deployed so some testing is done
>> > before final release.
>>
>> Hmm. I never really chipped into the ~ discussion, but it just occurred
>> to me it intersects with a discussion I care quite a lot about: RPM
>> version comparison. Especially RPM version comparison when all you have
>> to deal with is a string that represents an RPM N(E)VR(A) somehow
>> (that's 'name', 'epoch', 'version', 'release', 'arch').
>>
>> This is a corner case quite a few of us run into (it can happen for
>> e.g. when you're working off a fedmsg which just gives you a NEVRA
>> string) and it has some surprising properties, like: there isn't really
>> a 'good' standard way to do it. RPM doesn't expose this in its public
>> APIs. The best way anyone seems to know of to do it in Python, for
>> instance, is using `hawkey.split_nevra`...only hawkey is a bit weird,
>> it's provided by libdnf and is not in pypi, which means running tests
>> on code that uses it using standard stuff like tox-in-a-container is
>> difficult. Also, DNF folks have suggested they want it to go away.
>>
>> You can split a N(E)VR(A) string into components quite easily and
>> reliably with standard string manipulations, but comparing the
>> components the way RPM does it is difficult to re-implement...and of
>> course, the more weird rules like ~ we introduce, the harder it gets.
>>
>> Anyhow, it occurred to me to try out how hawkey.split_nevra handles
>> this tilde scenario, and the answer seems to be "a bit oddly":
>>
>> >>> tildenevra = hawkey.split_nevra('systemd-243~rc1-1.fc31')
>> >>> releasenevra = hawkey.split_nevra('systemd-243-1.fc31')
>> >>> releasenevra > tildenevra
>> True
>> >>> releasenevra.version
>> '243'
>> >>> tildenevra.version
>> '243~rc1'
>> >>> releasenevra.version > tildenevra.version
>> False
>> >>> tildenevra.version > releasenevra.version
>> True
>>
>> So...basically, it thinks the entire NEVRA object you get from the
>> string 'systemd-243-1.fc31' is "higher versioned" than the NEVRA object
>> you get from the string 'systemd-243~rc1-1.fc31'. Which is good, that's
>> correct. However, it thinks the version component of 'systemd-243~rc1-
>> 1.fc31' is higher than the version component of 'systemd-243-1.fc31'.
>> Which I believe is wrong, and also, it's a bit baffling, because if it
>> thinks that, I don't understand how it gets to the (correct) conclusion
>> that the entire tildenevra is lower versioned than the releasenevra,
>> since the 'name' and 'epoch' ('systemd' and 0, respectively) are the
>> same for both...
>>
>> Anyone see what I'm missing?
>>
>
(snip)


> You have to be careful with comparisons here. if the .version attribute is
> just a string, then python will do just a string comparison (which is
> sometimes wrong compared to RPM version comparisons).
>
> Fabio
>

Also, you can use rpm.labelCompare() from the RPM python bindings to check
for version ordering, since rpm.labelCompare() gives you a total order over
(epoch, version, release) string triples. It's easy to wrap that inside an
"idiomatic" pyth

Re: Fwd: Sunset of infinote (Gobby) service

[Matthew Miller]

On Thu, Aug 01, 2019 at 11:10:35AM +0200, Clement Verna wrote:
> The Fedora Infrastructure is planning to retire the infinote [0]
> service. This service allows text collaboration using the Gobby
> client[1] and was mainly used by the Infrastructure team to coordinate
> our weekly meeting and the mass update & reboot of the machines.

I know the Board used to use this a long time ago (to keep minutes for
private meetings), but we haven't used it in the Council at all (for one
thing, we don't have private meetings except in exceptional circumstances).

-- 
Matthew Miller

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

Re: systemd-243-rc1

[Matthew Miller]

On Thu, Aug 01, 2019 at 10:16:40AM -0700, Adam Williamson wrote:
> Hmm. I never really chipped into the ~ discussion, but it just occurred
> to me it intersects with a discussion I care quite a lot about: RPM
> version comparison. Especially RPM version comparison when all you have
> to deal with is a string that represents an RPM N(E)VR(A) somehow
> (that's 'name', 'epoch', 'version', 'release', 'arch').

I think we should do away with NEVRA comparison entirely and just use "R",
which would be an integer which would increase with each git commit and
never reset. Third party repos which want to override the base could use
modules to do so. (So it'd become NMRA.) There would be no need for
complicated parsing or ordering logic, and we wouldn't need to care what the
upstream scheme is. Upstream could use rainbow color order and everything
would be fine. Plus, we could easily decide that _we_ need to go back to an
older version without introducing epoch madness.

-- 
Matthew Miller

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

Re: python2->python3 mass rebuild and auto tools

[Miro Hrončok]

On 02. 08. 19 5:21, Steve Grubb wrote:

On Thursday, August 1, 2019 6:37:47 PM EDT Miro Hrončok wrote:

On 01. 08. 19 23:44, Steve Grubb wrote:

On Thursday, August 1, 2019 4:37:01 AM EDT Miro Hrončok wrote:

On 01. 08. 19 4:43, Steve Grubb wrote:

Audit. But is seems that autotools shoul hard code the old sematics so
that all packages do the right thing. It seems that python3 equivalents
have been introduced. They do the right thing with the python
migration.
But there are things that are expectd to defaulto python 2.


https://src.fedoraproject.org/rpms/audit/pull-request/4

Autotools usually already does the right thing, aka choosing python2 if
it
cannot find python. Using "python" in Fedora packages is forbidden
anyway.


I applied your patch. Thanks.

But I am concerned that this is a bandaid because it patches the spec
file and all distributions will have to do the same thing.


How does this Fedora impact other distributions?


Because eventually we all (distros) have to go through it. So, if autotools
handled this gracefully, I and everyone else would have a configure.ac file and
Makefile.am that just does the right thing. So, I am faced with making an
announcement on my project's mail list that maintainer on other distros have
to do this hack because autotools is incapable of doing the right thing.
There is no migration plan for autotools. We could have got in front of this
and helped make it smooth.

My package is now built in rawhide thanks to your patch. Fedora is OK. I just
worry about bug reports rolling in on other distros upstream.


I've talked to my friend at SUSE, who I know is much better with autotools than 
me and also knows Python. He expressed one thing that I think is worth 
mentioning here:


There is no point to "fix" AM_PATH_PYTHON to search for Python 2 only, 
introducing AM_PATH_PYTHON3 etc. just for the remaining 5 months of Python 2 
lifetime.


Instead, please focus on getting rid of python2-audit (required bya udit-viewer 
and python2-policycoreutils (that is required only by dokuwiki-selinux and vdsm 
(broken since Fedora 28))).


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: systemd-243-rc1

[Zbigniew Jędrzejewski-Szmek]

On Thu, Aug 01, 2019 at 10:16:40AM -0700, Adam Williamson wrote:
> On Thu, 2019-08-01 at 14:36 +0200, Nicolas Mailhot via devel wrote:
> > Le jeudi 01 août 2019 à 14:19 +0200, Lennart Poettering a écrit :
> > > On Do, 01.08.19 10:14, Fabio Valentini (decatho...@gmail.com) wrote:
> > > 
> > > > Since these things are both the case, a simple 1:1 mapping from "-" 
> > > > to
> > > > "~" (and even back) is exactly correct.
> > > > So I think the systemd.spec is doing exactly the right thing here.
> > > > 
> > > > The only issue I see is the arbitrary (?) restriction that git tags
> > > > cannot contain the tilde character.
> > > > Or is that there for filesystem compatibility, because tags are
> > > > just files?
> > > 
> > > git uses "~" for referencing commits relative to a commit identifier,
> > > see:
> > > 
> > > https://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse.txt-emltrevgtltngtemegemHEADmaster3em
> > > 
> > > Hence they do not allow it in tag names, to avoid the ambiguity.
> > > 
> > > I guess RPM is the outlier for using ~ the way it uses it, I don't
> > > think much other software does that. 
> > 
> > ~ is a debianism, introduced in rpm because some felt it was going to
> > satisfy uptream needs for irregular preversiob versioning
> > 
> > what rpm likes, and pretty much all component management stacks like
> > and support, is pure series of numbers separated with dots, without the
> > -foo pre-version madness that breaks everywhere in slightly different
> > ways.
> > 
> > Don't release anything that is not a series of numbers separated with
> > dots, no one ever managed to define anything else that works for
> > everyone (and many tried).
> > 
> > The preversion in semver is basically "it will break right and left,
> > who cares, no one will use it". Written by idealists that forgot the
> > point of preversions is to be used and deployed so some testing is done
> > before final release. 
> 
> Hmm. I never really chipped into the ~ discussion, but it just occurred
> to me it intersects with a discussion I care quite a lot about: RPM
> version comparison. Especially RPM version comparison when all you have
> to deal with is a string that represents an RPM N(E)VR(A) somehow
> (that's 'name', 'epoch', 'version', 'release', 'arch').
> 
> This is a corner case quite a few of us run into (it can happen for
> e.g. when you're working off a fedmsg which just gives you a NEVRA
> string) and it has some surprising properties, like: there isn't really
> a 'good' standard way to do it. RPM doesn't expose this in its public
> APIs. The best way anyone seems to know of to do it in Python, for
> instance, is using `hawkey.split_nevra`...only hawkey is a bit weird,
> it's provided by libdnf and is not in pypi, which means running tests
> on code that uses it using standard stuff like tox-in-a-container is
> difficult. Also, DNF folks have suggested they want it to go away.
> 
> You can split a N(E)VR(A) string into components quite easily and
> reliably with standard string manipulations, but comparing the
> components the way RPM does it is difficult to re-implement...and of
> course, the more weird rules like ~ we introduce, the harder it gets.
> 
> Anyhow, it occurred to me to try out how hawkey.split_nevra handles
> this tilde scenario, and the answer seems to be "a bit oddly":
> 
> >>> tildenevra = hawkey.split_nevra('systemd-243~rc1-1.fc31')
> >>> releasenevra = hawkey.split_nevra('systemd-243-1.fc31')
> >>> releasenevra > tildenevra
> True
> >>> releasenevra.version
> '243'
> >>> tildenevra.version
> '243~rc1'
> >>> releasenevra.version > tildenevra.version
> False
> >>> tildenevra.version > releasenevra.version
> True
> 
> So...basically, it thinks the entire NEVRA object you get from the
> string 'systemd-243-1.fc31' is "higher versioned" than the NEVRA object
> you get from the string 'systemd-243~rc1-1.fc31'. Which is good, that's
> correct. However, it thinks the version component of 'systemd-243~rc1-
> 1.fc31' is higher than the version component of 'systemd-243-1.fc31'.
> Which I believe is wrong, and also, it's a bit baffling, because if it
> thinks that, I don't understand how it gets to the (correct) conclusion
> that the entire tildenevra is lower versioned than the releasenevra,
> since the 'name' and 'epoch' ('systemd' and 0, respectively) are the
> same for both...

My guess would be that release.version is just a string, and
doesn't override the __lt__.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Muneendra

[Matthew Miller]

On Thu, Aug 01, 2019 at 05:55:45PM +0530, Muneendra Kumar M wrote:
> Hi Matthew,
> I have submitted a new package and the details are below.
> The main purpose of this daemon is to add FC network intelligence in host
> and host intelligence in FC network. This daemon would interoperate with
> Brocade FC fabric in order to improve the response time of the MPIO
> failovers. In future, it can also collect the congestion related details and
> perform workload analysis, and provide QOS at application level by
> interoperating with application performance profiling software.
> 
> The linux  changes necessary for this package is already available in
> upsteam.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1735762

Do you know if those changes have already landed in a kernel shipping in
Fedora (for example, in Rawhide)?

-- 
Matthew Miller

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

Re: systemd-243-rc1

[Adam Williamson]

On Fri, 2019-08-02 at 11:47 +0200, Fabio Valentini wrote:
> 
> > > Hmm. I never really chipped into the ~ discussion, but it just occurred
> > > to me it intersects with a discussion I care quite a lot about: RPM
> > > version comparison. Especially RPM version comparison when all you have
> > > to deal with is a string that represents an RPM N(E)VR(A) somehow
> > > (that's 'name', 'epoch', 'version', 'release', 'arch').
> > > 
> > > This is a corner case quite a few of us run into (it can happen for
> > > e.g. when you're working off a fedmsg which just gives you a NEVRA
> > > string) and it has some surprising properties, like: there isn't really
> > > a 'good' standard way to do it. RPM doesn't expose this in its public
> > > APIs. The best way anyone seems to know of to do it in Python, for
> > > instance, is using `hawkey.split_nevra`...only hawkey is a bit weird,
> > > it's provided by libdnf and is not in pypi, which means running tests
> > > on code that uses it using standard stuff like tox-in-a-container is
> > > difficult. Also, DNF folks have suggested they want it to go away.
> > > 
> > > You can split a N(E)VR(A) string into components quite easily and
> > > reliably with standard string manipulations, but comparing the
> > > components the way RPM does it is difficult to re-implement...and of
> > > course, the more weird rules like ~ we introduce, the harder it gets.
> > > 
> > > Anyhow, it occurred to me to try out how hawkey.split_nevra handles
> > > this tilde scenario, and the answer seems to be "a bit oddly":
> > > 
> > > > > > tildenevra = hawkey.split_nevra('systemd-243~rc1-1.fc31')
> > > > > > releasenevra = hawkey.split_nevra('systemd-243-1.fc31')
> > > > > > releasenevra > tildenevra
> > > True
> > > > > > releasenevra.version
> > > '243'
> > > > > > tildenevra.version
> > > '243~rc1'
> > > > > > releasenevra.version > tildenevra.version
> > > False
> > > > > > tildenevra.version > releasenevra.version
> > > True
> > > 
> > > So...basically, it thinks the entire NEVRA object you get from the
> > > string 'systemd-243-1.fc31' is "higher versioned" than the NEVRA object
> > > you get from the string 'systemd-243~rc1-1.fc31'. Which is good, that's
> > > correct. However, it thinks the version component of 'systemd-243~rc1-
> > > 1.fc31' is higher than the version component of 'systemd-243-1.fc31'.
> > > Which I believe is wrong, and also, it's a bit baffling, because if it
> > > thinks that, I don't understand how it gets to the (correct) conclusion
> > > that the entire tildenevra is lower versioned than the releasenevra,
> > > since the 'name' and 'epoch' ('systemd' and 0, respectively) are the
> > > same for both...
> > > 
> > > Anyone see what I'm missing?
> > > 
> (snip)
> 
> 
> > You have to be careful with comparisons here. if the .version attribute is
> > just a string, then python will do just a string comparison (which is
> > sometimes wrong compared to RPM version comparisons).
> > 
> > Fabio
> > 
> 
> Also, you can use rpm.labelCompare() from the RPM python bindings to check
> for version ordering, since rpm.labelCompare() gives you a total order over
> (epoch, version, release) string triples. It's easy to wrap that inside an
> "idiomatic" python NEVR class that has the desired ordering properties and
> overrides >,<, etc. correctly.
> 
> I hope this helps.

Thanks. I was actually assuming the version property wasn't just a
string but was some more sophisticated object with custom comparisons,
but apparently not.

rpm.labelCompare sounds like it could definitely be very useful, thanks
for that.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: python2->python3 mass rebuild and auto tools

[Steve Grubb]

On Friday, August 2, 2019 8:15:24 AM EDT Miro Hrončok wrote:
> On 02. 08. 19 5:21, Steve Grubb wrote:
> > On Thursday, August 1, 2019 6:37:47 PM EDT Miro Hrončok wrote:
> >> On 01. 08. 19 23:44, Steve Grubb wrote:
> >>> On Thursday, August 1, 2019 4:37:01 AM EDT Miro Hrončok wrote:
>  On 01. 08. 19 4:43, Steve Grubb wrote:
> > Audit. But is seems that autotools shoul hard code the old sematics
> > so
> > that all packages do the right thing. It seems that python3
> > equivalents
> > have been introduced. They do the right thing with the python
> > migration.
> > But there are things that are expectd to defaulto python 2.
>  
>  https://src.fedoraproject.org/rpms/audit/pull-request/4
>  
>  Autotools usually already does the right thing, aka choosing python2
>  if
>  it
>  cannot find python. Using "python" in Fedora packages is forbidden
>  anyway.
> >>> 
> >>> I applied your patch. Thanks.
> >>> 
> >>> But I am concerned that this is a bandaid because it patches the spec
> >>> file and all distributions will have to do the same thing.
> >> 
> >> How does this Fedora impact other distributions?
> > 
> > Because eventually we all (distros) have to go through it. So, if
> > autotools handled this gracefully, I and everyone else would have a
> > configure.ac file and Makefile.am that just does the right thing. So, I
> > am faced with making an announcement on my project's mail list that
> > maintainer on other distros have to do this hack because autotools is
> > incapable of doing the right thing. There is no migration plan for
> > autotools. We could have got in front of this and helped make it smooth.
> > 
> > My package is now built in rawhide thanks to your patch. Fedora is OK. I
> > just worry about bug reports rolling in on other distros upstream.
> 
> I've talked to my friend at SUSE, who I know is much better with autotools
> than me and also knows Python. He expressed one thing that I think is
> worth mentioning here:
> 
> There is no point to "fix" AM_PATH_PYTHON to search for Python 2 only,
> introducing AM_PATH_PYTHON3 etc. just for the remaining 5 months of Python
> 2 lifetime.

Sure. I can understand that python2 is coming to an end. However, audit 
installs and runs fine on very old versions of Linux. As soon as I make it 
require only recent kernels/environments, I'll start getting issues opened 
asking to fix the breakage.
 
> Instead, please focus on getting rid of python2-audit (required by
> audit-viewer

This ^^^ should go end of life asap.

> and python2-policycoreutils (that is required only by
> dokuwiki-selinux and vdsm (broken since Fedora 28))).

I'd love to quit building the python2 extensions. I can't drop them any time 
soon upstream.

There must be other upstream developers that have these same issues/concerns.

-Steve

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

Re: Join the new Minimization Team

[Zbigniew Jędrzejewski-Szmek]

On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
> I've already done some experiments with that. I used multi-stage builds
> with podman, but it's the same in principle. And yes, the sizes are
> smaller. What was interesting though that some additional packages (ones
> that wouldn't appear in the images using the Fedora base image) has been
> dragged in as dependencies. Some of them are even related to hardware. (See
> the report [1] and the github repo [2].)

It'd be nice to rebase this to F30 or even F31. F29 is not interesting
anymore.

A lot of the stuff in those images seems completely unnecessary:
device-mapper, device-mapper-libs, dracut, cpio, glibc-all-langpacks,
grubby, systemd-bootchart, systemd-udev.

> So that might be one area to focus on — to make sure that these "from
> scratch" installations don't drag unnecessary stuff.

Yep, that sounds like a good start. I suspect that F30 might be already
better in this regard.

Zbyszek


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

Orphaning some packages

[Pierre-Yves Chibon]

Good Morning Everyone,

I think it's time I make amends and recognize that I've been a terrible
maintainer for a number of my packages.
So I'd like to orphan the following packages hoping they can find a better home.

I no longer use R, so all of my R libraries:
rpms/R-affy
rpms/R-affydata
rpms/R-affyio
rpms/R-ALL
rpms/R-AnnotationDbi
rpms/R-Biobase
rpms/R-BiocGenerics
rpms/R-Biostrings
rpms/R-BSgenome
rpms/R-BSgenome.Celegans.UCSC.ce2
rpms/R-BufferedMatrix
rpms/R-BufferedMatrixMethods
rpms/R-caTools
rpms/R-DynDoc
rpms/R-fibroEset
rpms/R-GenomicFeatures
rpms/R-GenomicRanges
rpms/R-hgu133acdf
rpms/R-hgu95av2cdf
rpms/R-hgu95av2probe
rpms/R-IRanges
rpms/rkward
rpms/R-maanova
rpms/R-multtest
rpms/R-pls
rpms/R-preprocessCore
rpms/R-qvalue
rpms/R-rlecuyer
rpms/R-ROC
rpms/R-RUnit
rpms/R-sandwich
rpms/R-statmod
rpms/R-timeDate
rpms/R-tkWidgets
rpms/R-widgetTools
rpms/R-XML
rpms/R-xtable

rpms/trac-mastertickets-plugin
   No longer used in infra

rpms/libdivecomputer
rpms/subsurface
  Upstream (of the later) does a lot of bundling and I've had a hard time
  keeping up with it. I think this one may be more suitable for a flatpack tbh.
  libdivecomputer is a dependency of subsurface.

rpms/igraph
rpms/python-igraph
  I picked these two when I was looking at graph libraries but I've never done
  anything with them

rpms/python-rdfextras
  I took over this one but I'm not using it anywhere and not keeping up with
  upstream


Let me know if you are interested in any of them and I'll give them to you.
Otherwise I'll likely orphan them when I can back from flock.



Best,
Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Michal Schorm]

I personally use:

https://src.fedoraproject.org/rpms/galera/blob/master/f/galera.spec#_40
| %build
| %{set_build_flags}
|
| # FTBFS with the GLIBCXX_ASSERTIONS; #1546787
| CPPFLAGS=`echo $CPPFLAGS| sed -e "s|-Wp,-D_GLIBCXX_ASSERTIONS||g" `
| CFLAGS=`echo $CFLAGS| sed -e "s|-Wp,-D_GLIBCXX_ASSERTIONS||g" `
| CXXFLAGS=`echo $CXXFLAGS| sed -e "s|-Wp,-D_GLIBCXX_ASSERTIONS||g" `
| export CPPFLAGS CFLAGS CXXFLAGS

until it's solved.

Of course, if somebody has some more elegant solution, I'll be happy
to adopt it.

Michal

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Fri, Aug 2, 2019 at 5:01 PM Steven A. Falco  wrote:
>
> The upstream KiCAD project has requested that I remove GLIBCXX_ASSERTIONS 
> from the Fedora package, as described here: 
> https://bugs.launchpad.net/kicad/+bug/1838448
>
> What is the best way to do that?  I can add "%undefine _hardened_build" 
> (which I am testing now) but I think that will remove other hardening 
> features that I might want to leave enabled.
>
> Steve
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Tom Hughes]

On 01/08/2019 19:28, Steven A. Falco wrote:

The upstream KiCAD project has requested that I remove GLIBCXX_ASSERTIONS from 
the Fedora package, as described here: 
https://bugs.launchpad.net/kicad/+bug/1838448

What is the best way to do that?  I can add "%undefine _hardened_build" (which 
I am testing now) but I think that will remove other hardening features that I might want 
to leave enabled.


Well you just need to add -U_GLIBCXX_ASSERTIONS to the end of the
compiler flags.

But I think upstream is giving very bad advice...

That define does not "add extra crashes" in the way that they
seem to think - well I mean it does literally but those crashes
are reports of program errors on their part.

Specifically in this case they appear to be accessing a
std::vector at an index beyond the end, so they are accessing
memory that may not be allocated at all, and if it is does
not belong to the vector in question. So the program is quite
likely to crash there one day anyway, the extra assertion just
makes sure it always does.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Vitaly Zaitsev via devel]

Hello, Steven A. Falco.

Thu, 1 Aug 2019 14:28:31 -0400 you wrote:

> What is the best way to do that?  I can add "%undefine _hardened_build" 
> (which I am testing now) but I think that will remove other hardening 
> features that I might want to leave enabled.
%global optflags %(echo %{optflags} | sed 's/-Wp,-D_GLIBCXX_ASSERTIONS//')

--
Sincerely,
 Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Steven A. Falco]

On 8/2/19 11:09 AM, Tom Hughes wrote:
> On 01/08/2019 19:28, Steven A. Falco wrote:
>> The upstream KiCAD project has requested that I remove GLIBCXX_ASSERTIONS 
>> from the Fedora package, as described here: 
>> https://bugs.launchpad.net/kicad/+bug/1838448
>>
>> What is the best way to do that?  I can add "%undefine _hardened_build" 
>> (which I am testing now) but I think that will remove other hardening 
>> features that I might want to leave enabled.
> 
> Well you just need to add -U_GLIBCXX_ASSERTIONS to the end of the
> compiler flags.
> 
> But I think upstream is giving very bad advice...
> 
> That define does not "add extra crashes" in the way that they
> seem to think - well I mean it does literally but those crashes
> are reports of program errors on their part.
> 
> Specifically in this case they appear to be accessing a
> std::vector at an index beyond the end, so they are accessing
> memory that may not be allocated at all, and if it is does
> not belong to the vector in question. So the program is quite
> likely to crash there one day anyway, the extra assertion just
> makes sure it always does.

I agree that it sounds like bad advice, and I've raised that exact issue in 
comment #22 (https://bugs.launchpad.net/kicad/+bug/1838448/comments/22).  We'll 
see if I can convince upstream to rethink this.

Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

RE: Self Introduction: Muneendra

[Muneendra Kumar M via devel]

Hi Matthew,
The changes are available in open source from 5.2 onwards.
Below is the link which points the same.
https://patchwork.kernel.org/cover/10887947/#22575061

And the below are the commit ids:

https://github.com/torvalds/linux/commit/1a61e5486aeb90d94dd6116c9749e36ed
d10bf9b
https://github.com/torvalds/linux/commit/c39e0af64bce3bba61c3986d6083df7b8
f29a310
https://github.com/torvalds/linux/commit/2b1be55819dc7ae35576b3ba621c7fed0
c323e04
https://github.com/torvalds/linux/commit/a7dff3ad4787381a3aa831d558fb720b8
f354435

What I want to say is it is available in the open source and iam not sure
about fedora.
Sorry I couldn't check the same in fedora .
Could you please point me to the link where I can look the fedora
(Rawhide) source code or rpms .
So that I can check the same.

Regards,
Muneendra.

-Original Message-
From: Matthew Miller [mailto:mat...@fedoraproject.org]
Sent: Friday, August 2, 2019 6:35 PM
To: Muneendra Kumar M 
Cc: Development discussions related to Fedora

Subject: Re: Self Introduction: Muneendra

On Thu, Aug 01, 2019 at 05:55:45PM +0530, Muneendra Kumar M wrote:
> Hi Matthew,
> I have submitted a new package and the details are below.
> The main purpose of this daemon is to add FC network intelligence in
> host and host intelligence in FC network. This daemon would
> interoperate with Brocade FC fabric in order to improve the response
> time of the MPIO failovers. In future, it can also collect the
> congestion related details and perform workload analysis, and provide
> QOS at application level by interoperating with application performance
profiling software.
>
> The linux  changes necessary for this package is already available in
> upsteam.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1735762

Do you know if those changes have already landed in a kernel shipping in
Fedora (for example, in Rawhide)?

--
Matthew Miller

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

Re: Self Introduction: Muneendra

[Matthew Miller]

On Fri, Aug 02, 2019 at 08:59:29PM +0530, Muneendra Kumar M wrote:
> What I want to say is it is available in the open source and iam not sure
> about fedora.
> Sorry I couldn't check the same in fedora .
> Could you please point me to the link where I can look the fedora
> (Rawhide) source code or rpms .
> So that I can check the same.

Sure! The source package for the kernel is in dist-git at
https://src.fedoraproject.org/rpms/kernel/ or you can see
the whole rawhide tree at 
https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/source/tree/Packages/
(Rawhide is our development branch).

I can see there that we actually have a kernel-5.3.0-0.rc1.git3.1.fc31.src.rpm 
build today, so that should be well ahead of what you need.

-- 
Matthew Miller

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

Re: How do I remove GLIBCXX_ASSERTIONS?

[Florian Weimer]

* Steven A. Falco:

> The upstream KiCAD project has requested that I remove
> GLIBCXX_ASSERTIONS from the Fedora package, as described here:
> https://bugs.launchpad.net/kicad/+bug/1838448

I commented on the bug.  I think removal of these security checks is not
the right thing to do.

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

Re: corrupt GNU_PROPERTY_TYPE (5) size: 0, bad GNU build attribute

[Florian Weimer]

* Miro Hrončok:

> I get a FTBFS with micropython that I fail to parse.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1736114
>
> Does anybody know what this means and how shall I fix this?
> May it be a glibc regression?

It's a binutils issue.  I updated the bug.

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

Re: How do I remove GLIBCXX_ASSERTIONS?

[mcatanzaro]

On Thu, Aug 1, 2019 at 1:28 PM, Steven A. Falco  
wrote:

What is the best way to do that?


Don't. As Florian has pointed out in Launchpad, this would convert the 
nice crash into a security vulnerability. The assertions have a 
negligible impact on performance, so better leave them enabled and 
focus on fixing your software bug instead.


Michael

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

RE: Self Introduction: Muneendra

[Muneendra Kumar M via devel]

Hi Mathew,

Thanks for providing the info.
One quick question.
Robert-Andre has given some review(feedaback) on my spec.
Once I update the changes do I need to reply in the comments or is there
any other procedure.
If there is any link to the same if so could you please point me the same.
This info  would help me a lot.

Regards,
Muneendra.


-Original Message-
From: Matthew Miller [mailto:mat...@fedoraproject.org]
Sent: Friday, August 2, 2019 9:08 PM
To: Muneendra Kumar M 
Cc: Development discussions related to Fedora

Subject: Re: Self Introduction: Muneendra

On Fri, Aug 02, 2019 at 08:59:29PM +0530, Muneendra Kumar M wrote:
> What I want to say is it is available in the open source and iam not
> sure about fedora.
> Sorry I couldn't check the same in fedora .
> Could you please point me to the link where I can look the fedora
> (Rawhide) source code or rpms .
> So that I can check the same.

Sure! The source package for the kernel is in dist-git at
https://src.fedoraproject.org/rpms/kernel/ or you can see the whole
rawhide tree at
https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everythi
ng/source/tree/Packages/
(Rawhide is our development branch).

I can see there that we actually have a
kernel-5.3.0-0.rc1.git3.1.fc31.src.rpm
build today, so that should be well ahead of what you need.

--
Matthew Miller

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

Re: How do I remove GLIBCXX_ASSERTIONS?

[Susi Lehtola]

On 8/1/19 9:28 PM, Steven A. Falco wrote:

The upstream KiCAD project has requested that I remove
GLIBCXX_ASSERTIONS from the Fedora package, as described here:
https://bugs.launchpad.net/kicad/+bug/1838448

What is the best way to do that?  I can add "%undefine
_hardened_build" (which I am testing now) but I think that will
remove other hardening features that I might want to leave enabled.


Looks like you're using CMake. This should do the trick

export CFLAGS=$(echo "%{optflags}" |
 sed "s|-Wp,-D_GLIBCXX_ASSERTIONS||g")
export CXXFLAGS=$(echo "%{optflags}" |
 sed "s|-Wp,-D_GLIBCXX_ASSERTIONS||g")
--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Steven A. Falco]

On 8/2/19 11:39 AM, Florian Weimer wrote:
> * Steven A. Falco:
> 
>> The upstream KiCAD project has requested that I remove
>> GLIBCXX_ASSERTIONS from the Fedora package, as described here:
>> https://bugs.launchpad.net/kicad/+bug/1838448
> 
> I commented on the bug.  I think removal of these security checks is not
> the right thing to do.
> 
> Thanks,
> Florian
> 

Thanks for doing that.  The more I think about it, the less I like removing the 
GLIBCXX_ASSERTIONS.

Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Self Introduction: Muneendra

[Matthew Miller]

On Fri, Aug 02, 2019 at 09:18:35PM +0530, Muneendra Kumar M wrote:
> Hi Mathew,
> 
> Thanks for providing the info.
> One quick question.
> Robert-Andre has given some review(feedaback) on my spec.
> Once I update the changes do I need to reply in the comments or is there
> any other procedure.
> If there is any link to the same if so could you please point me the same.
> This info  would help me a lot.


Sure -- the process is documented here: 
https://fedoraproject.org/wiki/Package_Review_Process

Do you have a sponsor into the packaging group? You'll need that as well.

-- 
Matthew Miller

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

RE: Self Introduction: Muneendra

[Muneendra Kumar M via devel]

Hi Mathew,
I don't have sponsor.
I need a sponsor any help here would be great.

Regards,
Muneendra.


-Original Message-
From: Matthew Miller [mailto:mat...@fedoraproject.org]
Sent: Friday, August 2, 2019 9:25 PM
To: Muneendra Kumar M 
Cc: Development discussions related to Fedora

Subject: Re: Self Introduction: Muneendra

On Fri, Aug 02, 2019 at 09:18:35PM +0530, Muneendra Kumar M wrote:
> Hi Mathew,
>
> Thanks for providing the info.
> One quick question.
> Robert-Andre has given some review(feedaback) on my spec.
> Once I update the changes do I need to reply in the comments or is
> there any other procedure.
> If there is any link to the same if so could you please point me the
same.
> This info  would help me a lot.


Sure -- the process is documented here:
https://fedoraproject.org/wiki/Package_Review_Process

Do you have a sponsor into the packaging group? You'll need that as well.

--
Matthew Miller

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

Re: How do I remove GLIBCXX_ASSERTIONS?

[Simo Sorce]

On Thu, 2019-08-01 at 14:28 -0400, Steven A. Falco wrote:
> The upstream KiCAD project has requested that I remove
> GLIBCXX_ASSERTIONS from the Fedora package, as described here: 
> https://bugs.launchpad.net/kicad/+bug/1838448
> 
> What is the best way to do that?  I can add "%undefine
> _hardened_build" (which I am testing now) but I think that will
> remove other hardening features that I might want to leave enabled.

The best way is "Do not do that".

These flags are finding *actual* bugs in the program (out of bound
errors). Upstream should find out what is causing those and fix the
source of the bug, not hide it (it may cause memory corruption or worse
down the road).

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



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

Re: How do I remove GLIBCXX_ASSERTIONS?

[Iñaki Ucar]

Steve, as you said in that thread, actually those assertions have
helped uncover a bug (tagged as "critical")! I don't see any way in
which they could "add additional crashes" if upstream does their
homework. So I don't think it's a good idea to remove them.

Iñaki

On Fri, 2 Aug 2019 at 17:47, Steven A. Falco  wrote:
>
> The upstream KiCAD project has requested that I remove GLIBCXX_ASSERTIONS 
> from the Fedora package, as described here: 
> https://bugs.launchpad.net/kicad/+bug/1838448
>
> What is the best way to do that?  I can add "%undefine _hardened_build" 
> (which I am testing now) but I think that will remove other hardening 
> features that I might want to leave enabled.
>
> Steve
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Minimization Objective report

[Adam Samalik]

Congratulations! You're reading the very first Minimization Objective [1]
update.

== New Minimization Team ==

A new team is being formed, having 9 members already!
Read the team page [2] for more information, including how to join.

Welcome, everyone!

== Communication channels ==

Following are the communication channels preferred to discuss anything
Minimization:

* real-time discussions on #fedora-devel IRC on FreeNode
* longer discussions in issues at pagure/minimization [3] — they support
multiple threads/topics (issues), easy to link to and easy to reply to
right from the link, anyone within Fedora can be easily pinged
* some discussions might also happen here on the devel list
* Bugzilla bug to track all actual packaging changes [4]

== Regular meeting ==

A new regular meeting is being put in place [5], likely Wednesday 15:00 GMT
on one of the fedora IRC meeting channels.

== What's next ==

We have an action plan [6] indicating four main areas of interest:

1/ Prototyping simple tooling
2/ Ecosystems exploration
3/ Stacks analysis
4/ Content strategy

This page will be expanded with more specific actionable items.


Please let me know if you have any feedback or questions.

Cheers!
Adam


[1] Objective: https://docs.fedoraproject.org/en-US/minimization/
[2] Team: https://docs.fedoraproject.org/en-US/minimization/team/
[3] Pagure issues: https://pagure.io/minimization/issues
[4] Bugzilla tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1734342
[5] Meeting: https://pagure.io/minimization/issue/1
[6] Action plan:
https://docs.fedoraproject.org/en-US/minimization/action-plan/

-- 

Adam Šamalík
---
Senior Software Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Björn 'besser82' Esser]

Am Donnerstag, den 01.08.2019, 14:28 -0400 schrieb Steven A. Falco:
> The upstream KiCAD project has requested that I remove
> GLIBCXX_ASSERTIONS from the Fedora package, as described here: 
> https://bugs.launchpad.net/kicad/+bug/1838448
> 
> What is the best way to do that?  I can add "%undefine
> _hardened_build" (which I am testing now) but I think that will remove
> other hardening features that I might want to leave enabled.
> 
>   Steve

Simply add this to your spec file:

# Upstream recommends to turn off _GLIBCXX_ASSERTIONS.
# See: $UPSTREAM_BUG
%global optflags %optflags -U_GLIBCXX_ASSERTIONS


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Rolling out Phase I of rawhide package gating

[Florian Weimer]

* Pierre-Yves Chibon:

> When you run `fedpkg build` on Rawhide, your package will be built in
> a new koji tag (which will be the default target for Rawhide). The
> package will be picked up from this koji tag, signed and moved onto a
> second tag. Bodhi will be notified by koji once this new build is
> signed and will automatically create an update for it (you will be
> notified about this by email by bodhi directly) with a “Testing”
> status. If the package maintainer has not opted in into the CI
> workflow, the update will be pushed to “Stable” and the build will be
> pushed into the regular Rawhide tag, making it available in the
> Rawhide buildroot, just as it is today.

I see both “Status stable” and a “Push to Testing” button in the upper
right here:

  

Is this a UI issue?

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

Fw: jkeating's privoxy-3.0.3-9.2.2 completed

[Gwyn Ciesla via devel]

I have to say, I've never received a 12-year old koji notification before. :)


-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Friday, August 2, 2019 1:42 PM,  wrote:

> Notification time stamped 2019-08-02 18:40:43 UTC
> 

> jkeating's privoxy-3.0.3-9.2.2 completed
> http://koji.fedoraproject.org/koji/buildinfo?buildID=953
> 

> -
> 

> You received this message due to your preference settings at
> https://apps.fedoraproject.org/notifications/limb.id.fedoraproject.org/email/22030



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Ancient build notifications

[Susi Lehtola]

Hello,


is anyone else experiencing weird build notifications? I just got one 
for gsl-1.8-1.1 built by jkeating... on 5 Apr 2007.

--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 31 Beta blocker status email #2

[Ben Cotton]

Action summary


Accepted blockers
-
1. dracut-modules-olpc — Cannot be installed due to unsatisfied
'bitfrost' dependency — NEW
ACTION: dracut-modules-olpc to resolve dependency on desired bitfrost package.

Proposed blockers
-
1. gnome-initial-setup —
https://bugzilla.redhat.com/show_bug.cgi?id=1734198 — NEW
ACTION: gnome-initia-setup maintainers to fix crash when timedatex
service is unavailable.

2. kernel — https://bugzilla.redhat.com/show_bug.cgi?id=1733388
ACTION: QA team to determine if btrfs should be excluded from blocker
criteria and perhaps propose dropping it from the installer

3. selinux-policy —
https://bugzilla.redhat.com/show_bug.cgi?id=1734831 — ASSIGNED
ACTION: Identify cause of the AVC denial
NEEDINFO: msekl...@redhat.com

4. selinux-policy-targeted —
https://bugzilla.redhat.com/show_bug.cgi?id=1734197 — POST
ACTION: selinux-policy-targeted maintainers to update package with
potential fix.


Bug-by-bug detail
=

Accepted blockers
-
1. dracut-modules-olpc — Cannot be installed due to unsatisfied
'bitfrost' depndency — NEW
Cannot be installed due to unsatisfied 'bitfrost' dependency

bitfrost package was retired, which prevents dractu-modules-olpc from
building. However there is some discussion as to whether it's
reasonable for that package to be added to the
Server DVD. Currently, "dracut*" is added to Server, Workstation, and
Everything builds:
https://pagure.io/pungi-fedora/blob/master/f/fedora.conf#_130

Proposed blockers
-
1. gnome-initial-setup —
https://bugzilla.redhat.com/show_bug.cgi?id=1734198 — NEW
g-i-s crashes if timedatex.service isn't running

Crash caused by the SELinux denial in BZ 1734197. gnome-initial-setup
should handle that failure case gracefully. Note that systemd
maintainers are looking to obsolete timedatex:
https://bugzilla.redhat.com/show_bug.cgi?id=1735584

2. kernel — https://bugzilla.redhat.com/show_bug.cgi?id=1733388 — NEW
Circular locking often causes btrfs installs to hang with
kernel-5.3.0-0.rc0.git7.1.fc31 and later

Installations since kernel-5.3.0-0.rc0.git7.1.fc31 often fail during
package installation. The the QA team will consider excluding btrfs
from any blocker criteria.

3. selinux-policy —
https://bugzilla.redhat.com/show_bug.cgi?id=1734831 — ASSIGNED
SELinux is preventing (modprobe) from create access on the directory linger

Logins fail because modprobe cannot create on systemd's linger directory.

4. selinux-policy-targeted —
https://bugzilla.redhat.com/show_bug.cgi?id=1734197 — POST
SELinux denial "denied { send_msg } for
scontext=system_u:system_r:timedatex_t:s0
tcontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tclass=dbus"
prevents timedatex.service
from starting in current Rawhide

See also BZ 1734198. Upstream PR
(https://github.com/fedora-selinux/selinux-policy-contrib/pull/129)
merged with a potential fix.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Feedback on Application Streams and modularity

[Terry Bowling]

Hello Fedora friends!

I would like to follow up and collect your input on Application Streams and
modularity after all of the discussions over the past month.  We have been
listening and brainstorming on how to proceed with both the tooling, user
experience, and communicating better upstream for this process.

The team working on modularity in Fedora posted some revisions to the Fedora
modularity documentation .
Additionally, I described the end user experience expectations in this
thread
,
essentially describing why fully automated stream switching cannot occur
for a sane distro environment- at least at our current level of
understanding and tooling.  While my description was certainly focused on
the RHEL user perspective, as a long time Fedora user I will say this is
equally true for many Fedora users.

That said, I am hoping you could share your collective wisdom and provide
us feedback on the following:

1.  Have we better communicated the current features and goals of
Application Streams and modularity, primarily focused on end users?

2.  Does this help developers better understand the current limiting state
and challenges for both stream and other tooling limitations?


3. What can you share from commercial ISV and/or community developer
perspectives, and with respect to the user experience and stable distro
goals previously described for Application Streams, do you have
recommendations or requests for specific behaviors or tooling needed to
benefit the Fedora and RHEL ecosystems?  Such as but not limited :


a. How to provide the ability to switch streams without breaking a user's
choice or need for a different AppStream in the dependency chain.


b. What feature or tooling gaps still exist for creating community or
commercial products for RHEL & Fedora?

c. Anything I did not think to ask?


Thank you for your feedback!
-Terry
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Tom Callaway]

I think this is what you want:

%global optflags %(echo %{optflags} | sed 's/-Wp,-D_GLIBCXX_ASSERTIONS / /')

Tom

On Fri, Aug 2, 2019 at 11:00 AM Steven A. Falco 
wrote:

> The upstream KiCAD project has requested that I remove GLIBCXX_ASSERTIONS
> from the Fedora package, as described here:
> https://bugs.launchpad.net/kicad/+bug/1838448
>
> What is the best way to do that?  I can add "%undefine _hardened_build"
> (which I am testing now) but I think that will remove other hardening
> features that I might want to leave enabled.
>
> Steve
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora Updates issues

[Jerry James]

I just visited https://bodhi.fedoraproject.org/ to check on my updates
in testing.  I clicked on my profile.  The section named "jjames's
latest updates" used to show me the most recent few updates I have
submitted for stable branches.  Now it is completely full of Rawhide
builds.  I don't want to see those.  They don't require any action
from me.  Can we hide those Rawhide updates?

So I clicked on "Testing".  That brings up an empty list, showing
"Page 1 of 0".  That is wrong.  I have one update in Fedora 30 testing
(normaliz and polymake, which is broken...).  Why isn't it listed?

The ">>" button is the only clickable element of the list, so I
clicked on it.  (Why?  Because it's there.)  That takes me to a page
that says:

400 Bad Request
0 is less than minimum value 1

Right!  So the ">>" should not be clickable, then, yes?
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Untag a build?

[Steven A. Falco]

A bug was discovered in a pending KiCAD rawhide build, so I'd like to untag 
kicad-5.1.3-1.fc31 to keep it from going into rawhide.  Koji ID 1344019.

I've never done that before, but I tried doing "koji untag-build 
f31-updates-pending kicad-5.1.3-1.fc31", which gave me an error:

koji: ActionNotAllowed: tag requires admin permission

Is that the correct command, and if so, is there a way for me to get suitable 
permissions, or can someone with permissions do it?

I'd also like to untag kicad-5.1.3-1.fc30 from f30-updates-candidate.  I 
"unpushed" it in bohdi, but I'm not sure if that is sufficient to kill it.  
Koji ID 1344020.

Steve
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

error: More than one file on a line

[Christoph Junghans]

Hi,

related to https://src.fedoraproject.org/rpms/kim-api/pull-request/1
I am getting a strange error:

RPM build errors:
BUILDSTDERR: More than one file on a line: /_kim-api-collections-management
BUILDSTDERR: More than one file on a line:
/kim-api-collections-management.bash
(see https://koji.fedoraproject.org/koji/taskinfo?taskID=36767148)
I remember I have seen this before for bash-completion files, but I
can unfortunately not remember what the solution was.

the lines in the spec triggering this install are:
%files
...
%{z_compdir}/_kim-api-collections-management
%{z_compdir}/kim-api-collections-management.bash
with:
%global z_compdir "%{_datadir}/zsh/site-functions"
which is given to CMake
%{cmake3}  -DZSH_COMPLETION_COMPLETIONSDIR=%{z_compdir} ..
and picked up correctly:
-- Installing: 
/builddir/build/BUILDROOT/kim-api-2.1.2-1.fc31.i386/usr/share/zsh/site-functions/_kim-api-collections-management
-- Installing: 
/builddir/build/BUILDROOT/kim-api-2.1.2-1.fc31.i386/usr/share/zsh/site-functions/kim-api-collections-management.bash
nagement

Any ideas?

Christoph



-- 
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: systemd-243-rc1

[Elliott Sales de Andrade]

On Fri, 2 Aug 2019 at 05:33, Adam Williamson  wrote:
>
> On Thu, 2019-08-01 at 14:36 +0200, Nicolas Mailhot via devel wrote:
> > Le jeudi 01 août 2019 à 14:19 +0200, Lennart Poettering a écrit :
> > > On Do, 01.08.19 10:14, Fabio Valentini (decatho...@gmail.com) wrote:
> > >
> > > > Since these things are both the case, a simple 1:1 mapping from "-"
> > > > to
> > > > "~" (and even back) is exactly correct.
> > > > So I think the systemd.spec is doing exactly the right thing here.
> > > >
> > > > The only issue I see is the arbitrary (?) restriction that git tags
> > > > cannot contain the tilde character.
> > > > Or is that there for filesystem compatibility, because tags are
> > > > just files?
> > >
> > > git uses "~" for referencing commits relative to a commit identifier,
> > > see:
> > >
> > > https://git-scm.com/docs/git-rev-parse#Documentation/git-rev-parse.txt-emltrevgtltngtemegemHEADmaster3em
> > >
> > > Hence they do not allow it in tag names, to avoid the ambiguity.
> > >
> > > I guess RPM is the outlier for using ~ the way it uses it, I don't
> > > think much other software does that.
> >
> > ~ is a debianism, introduced in rpm because some felt it was going to
> > satisfy uptream needs for irregular preversiob versioning
> >
> > what rpm likes, and pretty much all component management stacks like
> > and support, is pure series of numbers separated with dots, without the
> > -foo pre-version madness that breaks everywhere in slightly different
> > ways.
> >
> > Don't release anything that is not a series of numbers separated with
> > dots, no one ever managed to define anything else that works for
> > everyone (and many tried).
> >
> > The preversion in semver is basically "it will break right and left,
> > who cares, no one will use it". Written by idealists that forgot the
> > point of preversions is to be used and deployed so some testing is done
> > before final release.
>
> Hmm. I never really chipped into the ~ discussion, but it just occurred
> to me it intersects with a discussion I care quite a lot about: RPM
> version comparison. Especially RPM version comparison when all you have
> to deal with is a string that represents an RPM N(E)VR(A) somehow
> (that's 'name', 'epoch', 'version', 'release', 'arch').
>
> This is a corner case quite a few of us run into (it can happen for
> e.g. when you're working off a fedmsg which just gives you a NEVRA
> string) and it has some surprising properties, like: there isn't really
> a 'good' standard way to do it. RPM doesn't expose this in its public
> APIs. The best way anyone seems to know of to do it in Python, for
> instance, is using `hawkey.split_nevra`...only hawkey is a bit weird,
> it's provided by libdnf and is not in pypi, which means running tests
> on code that uses it using standard stuff like tox-in-a-container is
> difficult. Also, DNF folks have suggested they want it to go away.
>
> You can split a N(E)VR(A) string into components quite easily and
> reliably with standard string manipulations, but comparing the
> components the way RPM does it is difficult to re-implement...and of
> course, the more weird rules like ~ we introduce, the harder it gets.
>
> Anyhow, it occurred to me to try out how hawkey.split_nevra handles
> this tilde scenario, and the answer seems to be "a bit oddly":
>
> >>> tildenevra = hawkey.split_nevra('systemd-243~rc1-1.fc31')
> >>> releasenevra = hawkey.split_nevra('systemd-243-1.fc31')
> >>> releasenevra > tildenevra
> True
> >>> releasenevra.version
> '243'
> >>> tildenevra.version
> '243~rc1'
> >>> releasenevra.version > tildenevra.version
> False
> >>> tildenevra.version > releasenevra.version
> True
>

In [15]: type(releasenevra)
Out[15]: _hawkey.NEVRA

In [16]: type(releasenevra.version)
Out[16]: str

The former probably has a custom __lt__ comparison method, while the
latter is just a regular string and compares using regular string
semantics. Longer (but otherwise the same) strings are "greater" than
shorter strings.

> So...basically, it thinks the entire NEVRA object you get from the
> string 'systemd-243-1.fc31' is "higher versioned" than the NEVRA object
> you get from the string 'systemd-243~rc1-1.fc31'. Which is good, that's
> correct. However, it thinks the version component of 'systemd-243~rc1-
> 1.fc31' is higher than the version component of 'systemd-243-1.fc31'.
> Which I believe is wrong, and also, it's a bit baffling, because if it
> thinks that, I don't understand how it gets to the (correct) conclusion
> that the entire tildenevra is lower versioned than the releasenevra,
> since the 'name' and 'epoch' ('systemd' and 0, respectively) are the
> same for both...
>
> Anyone see what I'm missing?
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net

-- 
Elliott
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an em

Fedora-Rawhide-20190802.n.1 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
13 of 45 required tests failed, 8 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cloud.all

Failed openQA tests: 40/147 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-Rawhide-20190730.n.0):

ID: 428859  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/428859
ID: 428870  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/428870
ID: 428871  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/428871
ID: 428873  Test: x86_64 Server-dvd-iso server_cockpit_basic
URL: https://openqa.fedoraproject.org/tests/428873
ID: 428874  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/428874
ID: 428875  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/428875
ID: 428876  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/428876
ID: 428877  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/428877
ID: 428878  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/428878
ID: 428879  Test: x86_64 Server-dvd-iso server_role_deploy_database_server 
**GATING**
URL: https://openqa.fedoraproject.org/tests/428879
ID: 428880  Test: x86_64 Server-dvd-iso server_database_client **GATING**
URL: https://openqa.fedoraproject.org/tests/428880
ID: 428881  Test: x86_64 Server-dvd-iso server_remote_logging_server
URL: https://openqa.fedoraproject.org/tests/428881
ID: 428882  Test: x86_64 Server-dvd-iso server_remote_logging_client
URL: https://openqa.fedoraproject.org/tests/428882
ID: 428884  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/428884
ID: 428899  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/428899
ID: 428906  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/428906
ID: 428907  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/428907
ID: 428908  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/428908
ID: 428917  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/428917
ID: 428932  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/428932
ID: 428954  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/428954
ID: 428986  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/428986
ID: 428990  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/428990
ID: 428991  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/428991
ID: 428994  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/428994

Old failures (same test failed in Fedora-Rawhide-20190730.n.0):

ID: 428865  Test: x86_64 Server-dvd-iso mediakit_repoclosure
URL: https://openqa.fedoraproject.org/tests/428865
ID: 428889  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/428889
ID: 428890  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/428890
ID: 428902  Test: x86_64 Workstation-boot-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/428902
ID: 428905  Test: x86_64 Workstation-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/428905
ID: 428920  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/428920
ID: 428922  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/428922
ID: 428923  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/428923
ID: 428984  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/428984
ID: 428985  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/428985
ID: 428987  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/428987
ID: 428992  Test: x86_64 universal upgrade_desktop_encrypted_64

(very delayed list email) Re: python2->python3 mass rebuild and auto tools

[Samuel Sieb]

On 8/1/19 2:44 PM, Steve Grubb wrote:
[snip]

I don't know if any list admins are following this list, but this email 
was delayed almost two days.  From the headers (included below) it looks 
like it might have been stuck in a moderation queue.  Is that what 
happened?  I've noticed a few older emails showing up today.


Received: from mailman01.phx2.fedoraproject.org 
(mailman01.phx2.fedoraproject.org [10.5.126.36])

by bastion01.phx2.fedoraproject.org (Postfix) with ESMTP id 
10DD360B3E82;
Sat,  3 Aug 2019 06:47:18 + (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 bastion01.phx2.fedoraproject.org 
10DD360B3E82

Received: from mailman01.phx2.fedoraproject.org (localhost [IPv6:::1])
by mailman01.phx2.fedoraproject.org (Postfix) with ESMTP id 
8FBF8586B06CB;
Sat,  3 Aug 2019 06:47:17 + (UTC)

--> right here on the same server

Received: by mailman01.phx2.fedoraproject.org (Postfix, from userid 991)
id E6F9D586AF363; Thu,  1 Aug 2019 21:44:22 + (UTC)
Received: from smtp-mm-ib01.fedoraproject.org 
(smtp-mm-ib01.vpn.fedoraproject.org [192.168.1.83])

by mailman01.phx2.fedoraproject.org (Postfix) with ESMTP id 
AE50C586B06D9
for ; Thu,  1 Aug 2019 21:44:21 + 
(UTC)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Intention to retire Release Notes RPM

[Neal Gompa]

On Sat, Aug 3, 2019 at 3:10 AM Brian (bex) Exelbierd
 wrote:
>
> Hi All,
>
> Barring objection, I plan to retire the release notes package from
> Fedora on or after August 9, 2019.  The package has not been updated
> since F28.  Despite the fact that we have literally shipped a package
> containing the F28 release notes in F29 and F30, there have been no
> comments.  This has been discussed with the docs team and is
> supported.  I am not aware of any dependencies and I believe it was
> removed from release criteria in F29.
>
> I will run `fedpkg retire` and further request removal via
> https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&version=rawhide&component=fedora-obsolete-packages
>
> Please reply on list if you have any questions or concerns.
>

Does Anaconda not support showing the release notes _anywhere_? That
was the original impetus for shipping it that way...



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

Re: python2->python3 mass rebuild and auto tools

[Björn 'besser82' Esser]

Am Donnerstag, den 01.08.2019, 17:44 -0400 schrieb Steve Grubb:
> On Thursday, August 1, 2019 4:37:01 AM EDT Miro Hrončok wrote:
> > On 01. 08. 19 4:43, Steve Grubb wrote:
> > > Audit. But is seems that autotools shoul hard code the old
> > > sematics so
> > > that all packages do the right thing. It seems that python3
> > > equivalents
> > > have been introduced. They do the right thing with the python
> > > migration.
> > > But there are things that are expectd to defaulto python 2.
> > 
> > https://src.fedoraproject.org/rpms/audit/pull-request/4
> > 
> > Autotools usually already does the right thing, aka choosing python2
> > if it
> > cannot find python. Using "python" in Fedora packages is forbidden
> > anyway.
> 
> I applied your patch. Thanks.
> 
> But I am concerned that this is a bandaid because it patches the spec
> file and 
> all distributions will have to do the same thing.


Just until the end of this year, as Python2 will be finally dead on
2020-01-01.

Anyways, there are easy ways in Autotools to archieve this, and I can
craft a patch, if you guide me to the canonical upstream of audit.

Björn


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Kevin Kofler]

Steven A. Falco wrote:
> The upstream KiCAD project has requested that I remove GLIBCXX_ASSERTIONS
> from the Fedora package, as described here:
> https://bugs.launchpad.net/kicad/+bug/1838448
> 
> What is the best way to do that?  I can add "%undefine _hardened_build"
> (which I am testing now) but I think that will remove other hardening
> features that I might want to leave enabled.

Just don't do it. That buffer overflow needs fixing either way. And the 
security implications of disabling the assertions have already been pointed 
out in the upstream bug report.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Sundials2 and review swap

[Antonio Trande]

Hi all.

Package review of Sundials2:
https://bugzilla.redhat.com/show_bug.cgi?id=1733704

Available to reviewing another package in return.

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x6e0331dd1699e4d7
GPG key server: https://keys.openpgp.org/



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Rolling out Phase I of rawhide package gating

[Kevin Fenzi]

On 8/2/19 11:13 AM, Florian Weimer wrote:
> * Pierre-Yves Chibon:
> 
>> When you run `fedpkg build` on Rawhide, your package will be built in
>> a new koji tag (which will be the default target for Rawhide). The
>> package will be picked up from this koji tag, signed and moved onto a
>> second tag. Bodhi will be notified by koji once this new build is
>> signed and will automatically create an update for it (you will be
>> notified about this by email by bodhi directly) with a “Testing”
>> status. If the package maintainer has not opted in into the CI
>> workflow, the update will be pushed to “Stable” and the build will be
>> pushed into the regular Rawhide tag, making it available in the
>> Rawhide buildroot, just as it is today.
> 
> I see both “Status stable” and a “Push to Testing” button in the upper
> right here:
> 
>   
> 
> Is this a UI issue?

It's an issue of some kind definitely... either it should not show that
or not allow it.

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
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: systemd-243-rc1

[Fabio Valentini]

On Sat, Aug 3, 2019, 20:19 Matthew Miller  wrote:

> On Thu, Aug 01, 2019 at 10:16:40AM -0700, Adam Williamson wrote:
> > Hmm. I never really chipped into the ~ discussion, but it just occurred
> > to me it intersects with a discussion I care quite a lot about: RPM
> > version comparison. Especially RPM version comparison when all you have
> > to deal with is a string that represents an RPM N(E)VR(A) somehow
> > (that's 'name', 'epoch', 'version', 'release', 'arch').
>
> I think we should do away with NEVRA comparison entirely and just use "R",
> which would be an integer which would increase with each git commit and
> never reset. Third party repos which want to override the base could use
> modules to do so. (So it'd become NMRA.)


I'd prefer if modules even worked internally - before we start having
third-party developers depend on them.

There would be no need for

complicated parsing or ordering logic, and we wouldn't need to care what the
> upstream scheme is. Upstream could use rainbow color order and everything
> would be fine. Plus, we could easily decide that _we_ need to go back to an
> older version without introducing epoch madness.
>

You know, we *could* drop Epoch in rawhide entirely. Some few packages that
have explicit requires with an Epoch would need to be fixed, but otherwise,
everything would be fine, since release upgrades are distro-syncs anyway
(only rawhide users would need to do dnf distro-sync instead of a simple
upgrade, and only once). The packaging committee has been exploring that
option some time ago.

Fabio


> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Test-Announce] Proposal to CANCEL: 2019-08-05 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel the QA meeting on Monday: it's a
public holiday here in Canada again, and also there isn't a lot for the
agenda. If anyone feels we really need to meet, you can go ahead and
take over by just sending out an announcement email with an agenda like
the ones I usually send.

Thanks, everyone!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Test-Announce] Proposal to CANCEL: 2019-08-05 Fedora 31 Blocker Review Meeting

[Adam Williamson]

Hey folks! I'm proposing we cancel the blocker review meeting for
Monday; we don't have a big list of proposed blockers (only 4) and it's
a public holiday here in Canada so I won't be around to run the
meeting. We can pick back up the following week. If anyone really
thinks we need to do the review this week, you can go ahead and take
over, just send out an announcement mail and be ready to run the
meeting on Monday, following
https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting . But if no-
one does that...see you on the 12th!

Thanks everyone!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning some packages

[Gwyn Ciesla via devel]

I'll take the python packagesand igraph.

Sent from ProtonMail mobile

 Original Message 
On Aug 2, 2019, 10:00 AM, Pierre-Yves Chibon wrote:

> Good Morning Everyone,
>
> I think it's time I make amends and recognize that I've been a terrible
> maintainer for a number of my packages.
> So I'd like to orphan the following packages hoping they can find a better 
> home.
>
> I no longer use R, so all of my R libraries:
> rpms/R-affy
> rpms/R-affydata
> rpms/R-affyio
> rpms/R-ALL
> rpms/R-AnnotationDbi
> rpms/R-Biobase
> rpms/R-BiocGenerics
> rpms/R-Biostrings
> rpms/R-BSgenome
> rpms/R-BSgenome.Celegans.UCSC.ce2
> rpms/R-BufferedMatrix
> rpms/R-BufferedMatrixMethods
> rpms/R-caTools
> rpms/R-DynDoc
> rpms/R-fibroEset
> rpms/R-GenomicFeatures
> rpms/R-GenomicRanges
> rpms/R-hgu133acdf
> rpms/R-hgu95av2cdf
> rpms/R-hgu95av2probe
> rpms/R-IRanges
> rpms/rkward
> rpms/R-maanova
> rpms/R-multtest
> rpms/R-pls
> rpms/R-preprocessCore
> rpms/R-qvalue
> rpms/R-rlecuyer
> rpms/R-ROC
> rpms/R-RUnit
> rpms/R-sandwich
> rpms/R-statmod
> rpms/R-timeDate
> rpms/R-tkWidgets
> rpms/R-widgetTools
> rpms/R-XML
> rpms/R-xtable
>
> rpms/trac-mastertickets-plugin
> No longer used in infra
>
> rpms/libdivecomputer
> rpms/subsurface
> Upstream (of the later) does a lot of bundling and I've had a hard time
> keeping up with it. I think this one may be more suitable for a flatpack tbh.
> libdivecomputer is a dependency of subsurface.
>
> rpms/igraph
> rpms/python-igraph
> I picked these two when I was looking at graph libraries but I've never done
> anything with them
>
> rpms/python-rdfextras
> I took over this one but I'm not using it anywhere and not keeping up with
> upstream
>
> Let me know if you are interested in any of them and I'll give them to you.
> Otherwise I'll likely orphan them when I can back from flock.
>
> Best,
> Pierre
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Steven A. Falco]

On 8/2/19 1:13 PM, Björn 'besser82' Esser wrote:
> Am Donnerstag, den 01.08.2019, 14:28 -0400 schrieb Steven A. Falco:
>> The upstream KiCAD project has requested that I remove
>> GLIBCXX_ASSERTIONS from the Fedora package, as described here: 
>> https://bugs.launchpad.net/kicad/+bug/1838448
>>
>> What is the best way to do that?  I can add "%undefine
>> _hardened_build" (which I am testing now) but I think that will remove
>> other hardening features that I might want to leave enabled.
>>
>>  Steve
> 
> Simply add this to your spec file:
> 
> # Upstream recommends to turn off _GLIBCXX_ASSERTIONS.
> # See: $UPSTREAM_BUG
> %global optflags %optflags -U_GLIBCXX_ASSERTIONS

Thanks for all the replies!  I will resist turning off the glibcxx assertions - 
I am convinced now that it would be a bad idea.

But at least now I know how to do that sort of thing, if I ever do need to 
modify the default flags in the future.

Steve



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Join the new Minimization Team

[Clement Verna]

On Sat, 3 Aug 2019 at 20:34, Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Aug 01, 2019 at 10:25:55AM +0200, Adam Samalik wrote:
> > I've already done some experiments with that. I used multi-stage builds
> > with podman, but it's the same in principle. And yes, the sizes are
> > smaller. What was interesting though that some additional packages (ones
> > that wouldn't appear in the images using the Fedora base image) has been
> > dragged in as dependencies. Some of them are even related to hardware. (See
> > the report [1] and the github repo [2].)
>
> It'd be nice to rebase this to F30 or even F31. F29 is not interesting
> anymore.
>
> A lot of the stuff in those images seems completely unnecessary:
> device-mapper, device-mapper-libs, dracut, cpio, glibc-all-langpacks,
> grubby, systemd-bootchart, systemd-udev.
>
> > So that might be one area to focus on — to make sure that these "from
> > scratch" installations don't drag unnecessary stuff.
>
> Yep, that sounds like a good start. I suspect that F30 might be already
> better in this regard.

Yes quite a bit has happened on the base image since F29, we have
removed quite a few things and trimmed down the latest rawhide to
208MB. I am sure that can still be improved and I welcome any help on
that :-).

>
> Zbyszek
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Test-Announce] Fedora 31 Rawhide 20190802.n.1 nightly compose nominated for testing

[rawhide]

Announcing the creation of a new nightly release validation test event
for Fedora 31 Rawhide 20190802.n.1. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20190726.n.0: anaconda-31.21-1.fc31.src, 20190802.n.1: 
anaconda-31.22-1.fc31.src
python-blivet - 20190726.n.0: python-blivet-3.1.4-2.fc31.src, 20190802.n.1: 
python-blivet-3.1.4-3.fc31.src
pyparted - 20190726.n.0: pyparted-3.11.2-1.fc30.src, 20190802.n.1: 
pyparted-3.11.2-2.fc31.src
parted - 20190726.n.0: parted-3.2-42.fc31.src, 20190802.n.1: 
parted-3.2-43.fc31.src
pykickstart - 20190726.n.0: pykickstart-3.20-3.fc31.src, 20190802.n.1: 
pykickstart-3.20-4.fc31.src
lorax - 20190726.n.0: lorax-31.8-1.fc31.src, 20190802.n.1: lorax-31.9-1.fc31.src
pungi - 20190726.n.0: pungi-4.1.38-1.fc31.src, 20190802.n.1: 
pungi-4.1.38-2.fc31.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/31

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190802.n.1_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190802.n.1_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190802.n.1_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190802.n.1_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190802.n.1_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190802.n.1_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_31_Rawhide_20190802.n.1_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Updates issues

[Clement Verna]

Hi

On Sat, Aug 3, 2019, 21:31 Jerry James  wrote:

> I just visited https://bodhi.fedoraproject.org/ to check on my updates
> in testing.  I clicked on my profile.  The section named "jjames's
> latest updates" used to show me the most recent few updates I have
> submitted for stable branches.  Now it is completely full of Rawhide
> builds.  I don't want to see those.  They don't require any action
> from me.  Can we hide those Rawhide updates?
>

This has already been reported here
https://github.com/fedora-infra/bodhi/issues/3429.

>
> So I clicked on "Testing".  That brings up an empty list, showing
> "Page 1 of 0".  That is wrong.  I have one update in Fedora 30 testing
> (normaliz and polymake, which is broken...).  Why isn't it listed?
>
> The ">>" button is the only clickable element of the list, so I
> clicked on it.  (Why?  Because it's there.)  That takes me to a page
> that says:
>
> 400 Bad Request
> 0 is less than minimum value 1
>
> Right!  So the ">>" should not be clickable, then, yes?
>

Can you check if there is already a ticket for that ? Otherwise can create
one ?

Thanks for the feedbacks.

> --
> Jerry James
> http://www.jamezone.org/
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: error: More than one file on a line

[Elliott Sales de Andrade]

On Sat, Aug 3, 2019, 3:49 PM Christoph Junghans,  wrote:

> Hi,
>
> related to https://src.fedoraproject.org/rpms/kim-api/pull-request/1
> I am getting a strange error:
>
> RPM build errors:
> BUILDSTDERR: More than one file on a line:
> /_kim-api-collections-management
> BUILDSTDERR: More than one file on a line:
> /kim-api-collections-management.bash
> (see https://koji.fedoraproject.org/koji/taskinfo?taskID=36767148)
> I remember I have seen this before for bash-completion files, but I
> can unfortunately not remember what the solution was.
>
> the lines in the spec triggering this install are:
> %files
> ...
> %{z_compdir}/_kim-api-collections-management
> %{z_compdir}/kim-api-collections-management.bash
> with:
> %global z_compdir "%{_datadir}/zsh/site-functions"
> which is given to CMake
> %{cmake3}  -DZSH_COMPLETION_COMPLETIONSDIR=%{z_compdir} ..
> and picked up correctly:
> -- Installing:
> /builddir/build/BUILDROOT/kim-api-2.1.2-1.fc31.i386/usr/share/zsh/site-functions/_kim-api-collections-management
> -- Installing:
> /builddir/build/BUILDROOT/kim-api-2.1.2-1.fc31.i386/usr/share/zsh/site-functions/kim-api-collections-management.bash
> nagement
>
> Any ideas?


Remove the quotes on the %global and only use them for the shell
invocations (or not at all because there won't be any spaces in the path
anyway.)

Christoph
>
>
>
> --
> Christoph Junghans
> Web: http://www.compphys.de
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Updates issues

[Kevin Fenzi]

On 8/2/19 1:38 PM, Jerry James wrote:
> I just visited https://bodhi.fedoraproject.org/ to check on my updates
> in testing.  I clicked on my profile.  The section named "jjames's
> latest updates" used to show me the most recent few updates I have
> submitted for stable branches.  Now it is completely full of Rawhide
> builds.  I don't want to see those.  They don't require any action
> from me.  Can we hide those Rawhide updates?
> 
> So I clicked on "Testing".  That brings up an empty list, showing
> "Page 1 of 0".  That is wrong.  I have one update in Fedora 30 testing
> (normaliz and polymake, which is broken...).  Why isn't it listed?
> 
> The ">>" button is the only clickable element of the list, so I
> clicked on it.  (Why?  Because it's there.)  That takes me to a page
> that says:
> 
> 400 Bad Request
> 0 is less than minimum value 1
> 
> Right!  So the ">>" should not be clickable, then, yes?

Can you file these at

https://github.com/fedora-infra/bodhi/issues

Thanks,

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
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Untag a build?

[Gergely Gombos]

Hi,

I think that you can just correct the bug, bump the release version, add 
a changelog entry describing the fix and build that. If stuff breaks (or 
stays broken for a while) in Rawhide, it's okay and expected- that's 
what Rawhide is for.


If you unpushed the update in bodhi, it should be sufficent to prevent 
it from getting into stable. You can just let the buggy build sit on top 
of the f30 branch, it won't affect anything as long as a bodhi update is 
not pushed to stable.


If you're unsure, you can create a scratch build to test the next build 
without getting it into rawhide.


Best regards,

Greg
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: (very delayed list email) Re: python2->python3 mass rebuild and auto tools

[Kevin Fenzi]

On 8/3/19 12:01 AM, Samuel Sieb wrote:
> On 8/1/19 2:44 PM, Steve Grubb wrote:
> [snip]
> 
> I don't know if any list admins are following this list, but this email
> was delayed almost two days.  From the headers (included below) it looks
> like it might have been stuck in a moderation queue.  Is that what
> happened?  I've noticed a few older emails showing up today.

No. It was delayed due to commits in epel8/epel8-playground branches.
There's about 70,000 (so far) commit emails there going to the
scm-commits list, so the list server has been swamped processing all those.

Hopefully it will catch up soon.

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
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: python2->python3 mass rebuild and auto tools

[Dridi Boukelmoune]

> Anyways, there are easy ways in Autotools to archieve this, and I can
> craft a patch, if you guide me to the canonical upstream of audit.

And even if you don't patch it, the need to export [1] a PYTHON
variable in the environment is exactly what should be done.

The tragedy of autotools is that people end up expecting everything to
be handled _auto_matically. Where we sit downstream we should never
ever need to worry about configure.ac files coming from upstream. One
of the goals of autotools is to allow upstream to redistribute a
bootstrapped archive, one that has already gone through the various
auto* utilities (and the controversial libtool) with a simple `make
dist`.

In the case of this package, you already _don't_ run the configure
script vanilla:

%configure --sbindir=/sbin --libdir=/%{_lib} --with-python=yes \
--with-python3=yes \
--enable-gssapi-krb5=yes --with-arm --with-aarch64 \
--with-libcap-ng=yes --enable-zos-remote \
--enable-systemd

And I assume you don't complain that audit's configure script doesn't
figure automagically that on Fedora it should --enable or build --with
exactly that configuration. Upstream gives you a choice regarding what
you may take from the build.

Auto-detection works the same, if it doesn't yield the results you
need downstream, you have an escape hatch:

./configure --help
[...]
Some influential environment variables:
  [...]
  PYTHON  the Python interpreter
[...]

There is nothing worrying about having to help the configure script,
in some cases you have to to ensure a reproducible build.

It does suck when you need to apply a similar tweak everywhere, but it
could be something handled by the %configure macro if it starts
showing up in more than just the audit package, or simply as part of
the python-means-python3 change (except that here it's the other way
around, which we probably don't want).

Cheers,
Dridi

[1] preferred way for autoconf would be %configure ... PYTHON=python2
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Non-responsive maintainer: dridi

[Dridi Boukelmoune]

> What is certain is that I won't have time to proverbially sit down (on
> my standing desk) and track bugs down, either as a reporter or as a
> maintainer. Same thing for my stalled review requests I was hoping to
> get done much sooner.

I may be back on track in a couple weeks actually, I may have been too
pessimistic in the first place :]

Dridi
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

koji build archiving

[Kevin Fenzi]

Koji.fedoraproject.org currently stores every rpm ever shipped to users
since the Fedora 7 days, along with a lot of information about every
build it’s ever made, even if not distributed. We have continued to grow
the storage backing koji over time, but it is close to reaching a size
we can no longer expand (75TB).

We are going to start moving builds off our main storage volume on to
slower (but still accessible) volumes in order to shrink our main volume
of active releases and make it easier to move and expand. There may be
slowdowns of builds and composes during the time we are moving builds,
but we will try and make it as transparent as possible.

All builds will continue to be available via koji.fedoraproject.org, but
you may notice a new volume name in the download path of some older
packages.

As part of initial testing of this move, we moved the *fc6* tagged
builds and this generated a number of 'buildsys.state.changed'
notifications to maintainers. We have since corrected the koji
fedora-messaging plugin to not emit these volume change events. Sorry
for the extra emails.

Please let us know if you experience excessive slowdowns or issues
related to this move.

This work is being tracked in
https://pagure.io/fedora-infrastructure/issue/8065

Thanks,

kevin



signature.asc
Description: OpenPGP digital signature
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fw: jkeating's privoxy-3.0.3-9.2.2 completed

[Kevin Fenzi]

On 8/2/19 11:45 AM, Gwyn Ciesla via devel wrote:
> I have to say, I've never received a 12-year old koji notification before. :)

Well, you still haven't. ;)

This was because I was testing our koji build archiving on the old fc6
tagged packages. Our koji fedora-messaging plugin saw the event and
emitted it as a 'buildsys.status.change' event, which is the same topic
as used for when a build completes. In this case however, the thing that
changed was the volume the build was stored on. ;)

In any event, I have modified the plugin to not emit messages on volume
change events, so hopefully no more of these go out.

I've since moved f7 and am moving f8 now, so it seems all is well.

Sorry for the emails everyone...

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
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Ancient build notifications

[Kevin Fenzi]

On 8/2/19 12:27 PM, Susi Lehtola wrote:
> Hello,
> 
> 
> is anyone else experiencing weird build notifications? I just got one
> for gsl-1.8-1.1 built by jkeating... on 5 Apr 2007.

Yeah, this was my testing our koji build archiving. Unfortunately our
message bus plugin saw this and emitted messages on the volume changes.

I've fixed that to not happen moving forward. See the post on
devel-announce for more information.

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
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Untag a build?

[Kevin Fenzi]

On 8/2/19 2:05 PM, Steven A. Falco wrote:
> A bug was discovered in a pending KiCAD rawhide build, so I'd like to untag 
> kicad-5.1.3-1.fc31 to keep it from going into rawhide.  Koji ID 1344019.
> 
> I've never done that before, but I tried doing "koji untag-build 
> f31-updates-pending kicad-5.1.3-1.fc31", which gave me an error:
> 
> koji: ActionNotAllowed: tag requires admin permission
> 
> Is that the correct command, and if so, is there a way for me to get suitable 
> permissions, or can someone with permissions do it?

If the build has gone out in a rawhide compose, you need to just push
out a fixed build. That could be something to fix it, or adding an Epoch
and downgrading back to a previous version.

If it's not yet gone out in a compose, you can file a releng ticket to
have someone untag it, or you can tag the previous version into
f31-updates-candidate and it will get pushed out instead. ie:

koji tag-pkg f31-updates-candidate 

But you should only do that if it's not gone out in a compose.
In this case it looks like that build has gone out. ;(

> 
> I'd also like to untag kicad-5.1.3-1.fc30 from f30-updates-candidate.  I 
> "unpushed" it in bohdi, but I'm not sure if that is sufficient to kill it.  
> Koji ID 1344020.

That will remove it from updates-testing yeah.

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
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Dropping -devel subpackage

[Iñaki Ucar]

Hi,

Quick question not found in the docs. There's a package with a -devel
subpackage. No package depends on this -devel and upstream removes the
development files in the new release, so I just dropped the -devel
subpackage.

Now, it's improbable, but if the old -devel subpackage was installed,
then "dnf upgrade" complains, obviously:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-f8c8592ad6

So the question is: should I add "Obsoletes: pkg-devel < $new_version"
to pkg's SPEC? Is this a proper use of "Obsoletes"?

Regards,
-- 
Iñaki Úcar
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Dropping -devel subpackage

[Miro Hrončok]

On 04. 08. 19 1:14, Iñaki Ucar wrote:

Hi,

Quick question not found in the docs. There's a package with a -devel
subpackage. No package depends on this -devel and upstream removes the
development files in the new release, so I just dropped the -devel
subpackage.

Now, it's improbable, but if the old -devel subpackage was installed,
then "dnf upgrade" complains, obviously:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-f8c8592ad6

So the question is: should I add "Obsoletes: pkg-devel < $new_version"
to pkg's SPEC? Is this a proper use of "Obsoletes"?


Yes. Exactly a right thing to do.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Sam Varshavchik]

Tom Hughes writes:


But I think upstream is giving very bad advice...

That define does not "add extra crashes" in the way that they
seem to think - well I mean it does literally but those crashes
are reports of program errors on their part.

Specifically in this case they appear to be accessing a
std::vector at an index beyond the end, so they are accessing
memory that may not be allocated at all, and if it is does
not belong to the vector in question. So the program is quite
likely to crash there one day anyway, the extra assertion just
makes sure it always does.


I believe that the following construct trips this assertion:

# std::vector foo;
#
# std::vector bar;
#
# // Populate foo with something.
#
# std::copy(&foo[0], &foo[foo.size()], std::back_insert_iterator{bar});

There's nothing wrong with this. There is no out of bounds access. I do not  
believe that this is undefined behavior. The defined semantics of  
std::vector, and its operator[], are well defined here.


I ran into these new assertions with my own code as well, after updating to  
F28 (where they were enabled by default the first time, IIRC, not sure why  
this shows up only now, for that package).


I ended up tweaking my code to avoid the assertions, rather than disabling  
them. For this particular situation, my original change was to try


std::copy(&foo[0], &foo[0]+foo.size(), std::back_insert_iterator{bar});

But that still tripped the assertion when the foo vector was empty, so I had  
wrap this inside an if().


This was a somewhat silly excersize. But, I do agree that these assertions  
are better to have, than have not.




pgpy7LcRQEQTX.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Andrew Lutomirski]

On Sat, Aug 3, 2019 at 4:30 PM Sam Varshavchik  wrote:
>
> Tom Hughes writes:
>
> > But I think upstream is giving very bad advice...
> >
> > That define does not "add extra crashes" in the way that they
> > seem to think - well I mean it does literally but those crashes
> > are reports of program errors on their part.
> >
> > Specifically in this case they appear to be accessing a
> > std::vector at an index beyond the end, so they are accessing
> > memory that may not be allocated at all, and if it is does
> > not belong to the vector in question. So the program is quite
> > likely to crash there one day anyway, the extra assertion just
> > makes sure it always does.
>
> I believe that the following construct trips this assertion:
>
> # std::vector foo;
> #
> # std::vector bar;
> #
> # // Populate foo with something.
> #
> # std::copy(&foo[0], &foo[foo.size()], std::back_insert_iterator{bar});
>
> There's nothing wrong with this. There is no out of bounds access.

You just formed a reference past the end of an array.  I doubt that is
valid according to the standard.  It certainly fails the smell test.

I *think* the standard defines &foo[foo.size] as being equivalent to
&*(foo.begin() + foo.size()), which certainly appears to be invalid.
On a cursory search of the standard, I couldn't find where it says
what operator* on this type of iterator does at all, let alone whether
it's valid for one-past-the-end iterators, but I'm pretty sure that
your code is, indeed, wrong.

> I do not
> believe that this is undefined behavior. The defined semantics of
> std::vector, and its operator[], are well defined here.
>
> I ran into these new assertions with my own code as well, after updating to
> F28 (where they were enabled by default the first time, IIRC, not sure why
> this shows up only now, for that package).
>
> I ended up tweaking my code to avoid the assertions, rather than disabling
> them. For this particular situation, my original change was to try
>
> std::copy(&foo[0], &foo[0]+foo.size(), std::back_insert_iterator{bar});
>

What you want is foo.begin() and foo.end() or, if you really want to
play with pointers, foo.data().
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: error: More than one file on a line

[Christoph Junghans]

On Sat, Aug 3, 2019 at 3:27 PM Elliott Sales de Andrade
 wrote:
>
>
>
> On Sat, Aug 3, 2019, 3:49 PM Christoph Junghans,  wrote:
>>
>> Hi,
>>
>> related to https://src.fedoraproject.org/rpms/kim-api/pull-request/1
>> I am getting a strange error:
>>
>> RPM build errors:
>> BUILDSTDERR: More than one file on a line: 
>> /_kim-api-collections-management
>> BUILDSTDERR: More than one file on a line:
>> /kim-api-collections-management.bash
>> (see https://koji.fedoraproject.org/koji/taskinfo?taskID=36767148)
>> I remember I have seen this before for bash-completion files, but I
>> can unfortunately not remember what the solution was.
>>
>> the lines in the spec triggering this install are:
>> %files
>> ...
>> %{z_compdir}/_kim-api-collections-management
>> %{z_compdir}/kim-api-collections-management.bash
>> with:
>> %global z_compdir "%{_datadir}/zsh/site-functions"
>> which is given to CMake
>> %{cmake3}  -DZSH_COMPLETION_COMPLETIONSDIR=%{z_compdir} ..
>> and picked up correctly:
>> -- Installing: 
>> /builddir/build/BUILDROOT/kim-api-2.1.2-1.fc31.i386/usr/share/zsh/site-functions/_kim-api-collections-management
>> -- Installing: 
>> /builddir/build/BUILDROOT/kim-api-2.1.2-1.fc31.i386/usr/share/zsh/site-functions/kim-api-collections-management.bash
>> nagement
>>
>> Any ideas?
>
>
> Remove the quotes on the %global and only use them for the shell invocations 
> (or not at all because there won't be any spaces in the path anyway.)
Thanks, that did the trick!

Christoph
>
>> Christoph
>>
>>
>>
>> --
>> Christoph Junghans
>> Web: http://www.compphys.de
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org



-- 
Christoph Junghans
Web: http://www.compphys.de
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Sam Varshavchik]

Andrew Lutomirski writes:


On a cursory search of the standard, I couldn't find where it says
what operator* on this type of iterator does at all, let alone whether
it's valid for one-past-the-end iterators, but I'm pretty sure that
your code is, indeed, wrong.


This finally piqued my curiosity enough to take some time to look into this.  
That expression applied the "*" operator to a random access iterator. So,  
going down the path:


# [random.access.iterators]
#
# A class or pointer type X satisfies the requirements of a random access 
# iterator if, in addition to satisfying the requirements for bidirectional 
# iterators, ...


In a similar fashion, a bidirectional iterator delegates some requirements  
to a forward iterator.


The forward iterator delegates some of its requirements to an input iterator.

At the end of the road, in [input.iterators]:

#  *a  reference,   convertible to T Requires: a is dereferenceable.

Then, finally, in [iterator.requirements.general]:

# Values of an iterator i for which the expression *i is defined are called 
# dereferenceable.


This reads to me like a definition that circularly defines itself. 
[input.iterators] says "*a requires that a is dereferencable". And  
[iterator.requirements.general] says that something is dereferencable if "*"  
for it is defined. That certainly clears that up…


Full disclosure: it's true that the next sentence is:

# The library never assumes that past-the-end values are dereferenceable.

But this only states that the library assumes that, it doesn't  
authoritatively state that.


But going back to the previous point, if we also want to see what going down  
"*i refers the unary * operator" route, as a means of avoiding the self- 
definition, we see that:


# [expr.unary.op]
#
# The unary * operator performs indirection: … the result is an lvalue

Nothing here requires the pointer to be valid, just that "*" gives you an  
lvaule. Nothing more, nothing else. That's it. Whether the pointer is valid,  
this gets punted only when the lvalue-to-rvalue conversion take place:


# [conv.lval]
#
# ... if the object to which the glvalue refers contains an invalid pointer
# value the behavior is implementation-defined.

But if you immediately apply the & operator, this conversion never takes  
place.


The C standard is even more explicit, and even blesses this  
construct, verbatim:


# The unary & operator yields the address of its operand.
# [ … ]
#
# if the operand is the result of a [] operator, neither the & operator  
# nor the unary * that is implied by the [] is evaluated and the result is as  
# if the & operator were removed and the [] operator were changed to a +  
# operator


I could not find some similar verbiage in the C++ standard, but based on all  
of the above I have to conclude that this is …too late today, and I should  
really get some sleep…


But not after rereading the specification for a vector itself, where I found  
something I glossed over the first time:


# [vector]
#
# A vector satisfies all of the requirements of a container and … of a 
# contiguous container.


The reference from "contiguous container" goes to:

# [container.requirements.general]
#
# A contiguous container is a container that supports random access iterators
# and whose member types iterator and const_iterator are contiguous iterators.

The reference from "contiguous iterators" goes to:

# [iterator.requirements.general]
#
# Iterators that further satisfy the requirement that, for integral values
# n and dereferenceable iterator values a and (a + n), *(a + n) is
# equivalent to *(addressof(*a) + n), are called contiguous iterators.

There might be more to the "contiguous" semantics that reflects on whether  
or not "&foo[foo.size()]" is defined behavior, or not, but here  
addressof(*a) already puts us squarely in pointer equivalence territory, and  
seems to again go into the unary "*" operator direction here, despite the  
conflicting wording.


…now it's definitely too late in the day.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Georg Sauthoff]

On Sat, Aug 03, 2019 at 07:29:34PM -0400, Sam Varshavchik wrote:
> I believe that the following construct trips this assertion:
> 
> # std::vector foo;
> #
> # std::vector bar;
> #
> # // Populate foo with something.
> #
> # std::copy(&foo[0], &foo[foo.size()], std::back_insert_iterator{bar});

It's true that something like

copy(&foo[0], &foo[foo.size()], back_inserter(bar));

triggers an assertion when compiled with -D_GLIBCXX_ASSERTIONS.  Because
the checking code just can't look at the context of its invocation.
Which is fine, because you really don't need to use such constructs.
 
> There's nothing wrong with this. There is no out of bounds access. I do not
> believe that this is undefined behavior. The defined semantics of
> std::vector, and its operator[], are well defined here.

It's defined behaviour but there is something wrong with it: it isn't
idiomatic C++ and it's tedious and error-prone.

> I ran into these new assertions with my own code as well, after updating to
> F28 (where they were enabled by default the first time, IIRC, not sure why
> this shows up only now, for that package).
> 
> I ended up tweaking my code to avoid the assertions, rather than disabling
> them. For this particular situation, my original change was to try
> 
> std::copy(&foo[0], &foo[0]+foo.size(), std::back_insert_iterator{bar});
> 
> But that still tripped the assertion when the foo vector was empty, so I had
> wrap this inside an if().

But why don't you use the idiomatic

copy(foo.begin(), foo.end(), back_inserter(bar));

?

No need to wrap it into an extra if statement.

With GCC, the generated code is basically the same as when using:

copy(foo.data(), foo.data()+foo.size(), back_inserter(bar));

vector::data() is available since C++11. This doesn't trigger
any assertion and works with an empty source vector, as well.

What also works in general and doesn't trigger any assertion is the
'ultra ugly':

copy(&*foo.begin(), &*foo.end(), back_inserter(bar));

But there is also really no need to use an back_insert_iterator here - a
direct solution:

bar.insert(bar.end(), foo.begin(), foo.end());


Best regards
Georg
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org