[Bug 1828234] perl-Date-Holidays-DE-2.05 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1828234



--- Comment #10 from Fedora Update System  ---
FEDORA-EPEL-2020-c3f45edc3e has been pushed to the Fedora EPEL 7 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c3f45edc3e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


Re: Self Introduction: Jude Lee / judescripts

2020-04-27 Thread Robin Lee
On Tue, Apr 28, 2020 at 11:43 AM Jude Lee  wrote:
>
> Hi! my name is Jude and I am a fullstack / architect (github.com/judescripts 
> | linkedin.com/in/leejude).
>
> This is first time joining a fedora group and I've been wanting to become a 
> part of the open source project community for awhile now.
> I've mostly worked with debian based distros and some arch linux, but after 
> giving a go at fedora I fell in love.
> Would like to contribute more in the best way I can through this group and 
> hoping to learn and grow in this community and become a valuable contributor.
>
> Nice to meet you all and looking forward to getting to know the community 
> more :)
>
> Best,
>
> Jude
Welcome! It's a good idea to start with the packages that you actually use.
> ___
> 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


[Bug 1803531] perl-Test-mysqld-1.0013 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1803531

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Test-mysqld-1.0013-1.f |perl-Test-mysqld-1.0013-1.f
   |c32 |c32
   ||perl-Test-mysqld-1.0013-1.e
   ||l8



--- Comment #8 from Fedora Update System  ---
FEDORA-EPEL-2020-df373fbeba has been pushed to the Fedora EPEL 8 stable
repository.
If problem still persists, please make note of it in this bug report.


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


[Bug 1819677] perl-Sys-Statistics-Linux missing in EPEL-8

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1819677

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Sys-Statistics-Linux-0
   ||.66-21.el8
 Resolution|--- |ERRATA
Last Closed||2020-04-28 04:20:07



--- Comment #10 from Fedora Update System  ---
FEDORA-EPEL-2020-409a866a09 has been pushed to the Fedora EPEL 8 stable
repository.
If problem still persists, please make note of it in this bug report.


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


Re: Previous awesome background images

2020-04-27 Thread Jeremy Linton

Hi,

On 4/17/20 4:43 PM, Miro Hrončok wrote:

On 17. 04. 20 16:07, Kamil Paral wrote:
I'm disappointed with default wallpapers in the latest releases. I 
wonder if we could go back to more artistic images from previous 
releases? Here are some of my favorite ones:

https://fedoraproject.org/wiki/Wallpapers#Fedora_29
https://fedoraproject.org/wiki/Wallpapers#Fedora_27
https://fedoraproject.org/wiki/Wallpapers#Fedora_21
https://fedoraproject.org/wiki/Wallpapers#Fedora_16
https://fedoraproject.org/wiki/Wallpapers#Fedora_15
https://fedoraproject.org/wiki/Wallpapers#Fedora_11
https://fedoraproject.org/wiki/Wallpapers#Fedora_7

Especially the one in Fedora 15 (GNOME edition) and 16 was 
outstanding. Can we do more of those, please?


I love both the design and concept of the F25-F28 wallpapers.

"As of the past 3 releases, we choose a sequential letter of the 
alphabet and come up with a list of scientists / mathematicians / 
technologists to serve as an inspiration for the desktop background’s 
visual concept"


https://blog.linuxgrrl.com/2018/03/06/fedora-28s-desktop-background-design/

I am sad we haven't followed the pattern. (However I don't know the 
reasoning for stopping that.)


(I've changed the subject line, because I don't want to participate in 
what was in there.)




(agree)

IMHO, A desktop background serves a different purpose than a login/lock 
screen. A desktop background shouldn't be distracting, high contrast, or 
busy. Making beautiful art with those restrictions is quite difficult. 
The fedora backgrounds tend to grow on me over time, but I also tend to 
immediately just set my desktop background to straight black, with a 
dark theme (breeze dark variation) and reserve the fedora art for the 
screen lock.


The login/lock screen, should be looking for maximum impact. Its after 
all what people see as they walk by a fedora machine. In that regard 
something like the F7 image really wins.


So maybe this is a case of trying to answer to conflicting requirements. 
Maximum art, high contrast login screen, more soothing muted desktop 
backgrounds.



Anyway, i'm going to spread some love to another distro in this thread 
too. The Opensuse 12.3 theme/background was one of the few times I've 
left the default background on for any length of time. They seemed to 
have pulled off just the right amount of mostly non distracting 
background, yet somehow managed to still achieve that minimalist beauty 
everyone seems to be in search of these days. Its all gray tones, with a 
single green vine/logo. It fit with the theme in a way that made me 
think, now this is what a linux desktop should look and behave like.


https://news-cdn.softpedia.com/images/news2/openSUSE-12-3-Is-Approaching-End-of-Life-Fast-466700-2.jpg
___
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: Orphaned packages looking for new maintainers (anaconda also affected)

2020-04-27 Thread Sérgio Basto
On Mon, 2020-04-27 at 12:39 +0200, Miro Hrončok wrote:
> GConf2

GConf2 is orphan, why ? no maintainers or a task force to be removed ? 


Thanks, 
-- 
Sérgio M. B.
___
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


[Bug 1828234] perl-Date-Holidays-DE-2.05 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1828234



--- Comment #9 from Fedora Update System  ---
FEDORA-2020-153e823ca4 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-153e823ca4`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-153e823ca4

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


[Bug 1827253] perl-Date-Manip 6.81 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1827253



--- Comment #4 from Fedora Update System  ---
FEDORA-2020-465ccdced6 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-465ccdced6`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-465ccdced6

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


[Bug 1827726] perl-DateTime-TimeZone-2.39 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1827726



--- Comment #6 from Fedora Update System  ---
FEDORA-2020-8e37999a60 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-8e37999a60`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-8e37999a60

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


[Bug 1827726] perl-DateTime-TimeZone-2.39 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1827726



--- Comment #5 from Fedora Update System  ---
FEDORA-2020-bdbc8e8c25 has been pushed to the Fedora 30 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-bdbc8e8c25`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-bdbc8e8c25

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


Self Introduction: Jude Lee / judescripts

2020-04-27 Thread Jude Lee
Hi! my name is Jude and I am a fullstack / architect (github.com/judescripts | 
linkedin.com/in/leejude).

This is first time joining a fedora group and I've been wanting to become a 
part of the open source project community for awhile now.
I've mostly worked with debian based distros and some arch linux, but after 
giving a go at fedora I fell in love.
Would like to contribute more in the best way I can through this group and 
hoping to learn and grow in this community and become a valuable contributor.

Nice to meet you all and looking forward to getting to know the community more 
:)

Best,

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


[Bug 1828234] perl-Date-Holidays-DE-2.05 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1828234

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #8 from Fedora Update System  ---
FEDORA-2020-0959698d0f has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-0959698d0f`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-0959698d0f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


[Bug 1827253] perl-Date-Manip 6.81 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1827253

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-2020-1ad0f1e703 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-1ad0f1e703`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-1ad0f1e703

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


[Bug 1827726] perl-DateTime-TimeZone-2.39 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1827726

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-2020-3277a9e199 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing
--advisory=FEDORA-2020-3277a9e199`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-3277a9e199

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


Re: Orphaned packages looking for new maintainers (anaconda also affected)

2020-04-27 Thread Jerry James
On Mon, Apr 27, 2020 at 4:40 AM Miro Hrončok  wrote:
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

[snip]

> antlr4gil, jkastner, lef, mizdebsk,2 weeks ago
>orphan

This one has been replaced by antlr4-project, so I retired it with a
note saying so.
-- 
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


Re: RFC: Feature macros (aka USE flags)

2020-04-27 Thread clime
Few more notes:

I think an idea that build system could be simply passing
--with/--without options on mock's command-line should be
considered...then basically no change in spec files is needed (i.e. no
syntax change).

It would be great if rpm remembered either the rpmbuild's command-line
in case the solution above is chosen or the set of with options (and
the final values for them) that were used during build if the
buildroot config approach is chosen. I think that would be very useful
for debugging and inspection of rpms.

...that's probably it from me.

clime

On Tue, 28 Apr 2020 at 03:06, clime  wrote:
>
> On Mon, 27 Apr 2020 at 13:21, Petr Šabata  wrote:
> >
> > Based on the recent discussions around %fedora/%rhel macros and ELN,
> > and %bcond generally being confusing to work with, I came up with a
> > distribution-wide feature that defines generic feature keywords and
> > associated helper macros that packages can check in build-time
> > conditionals.
> >
> > The key advantage here is the defaults are defined by the buildroot,
> > not the package. The package is just a building block.
> >
> > I'd like some input to improve this and unless this turns out to be a
> > really bad idea, I intend to submit it as a change proposal. Even
> > though the more packages use it the more beneficial it gets, it's, of
> > course, perfectly optional.
> >
> > Details in the gist:
> > https://gist.github.com/contyk/0f0585c57976ca18a293b3566408
>
> Ad. Dan Mach's presented spec file:
>
> > https://github.com/rpm-software-management/libdnf/blob/dnf-5-devel/libdnf.spec
>
> I really like how all the switches are defined almost on top of the
> spec file so I think lots of inspiration can be drawn from that.
>
> Now I also think that introduction of the new %use scheme for build
> options instead of the current with/without scheme might be an
> overkill.
>
> I think lines like these:
>
> %bcond_with html
> %bcond_without man
>
> could be replaced by:
>
> %with_option_env html 0
> %with_option_env man 1
>
> i.e. %with_option_env  
>
> %with_option_env could be looking at an environmental buildroot
> setting with the possibility to be overridden on command-line by
> --with and --without as usual.
>
> There could be also:
> %with_option  
>
> which wouldn't look at environment settings so it would be the same
> thing as %bcond_with/%bcond_without but less confusing.
>
> So with this, you wouldn't need to change conditions like:
>
> %if %{with foo}
> ...
> %endif
>
> and
>
> %if %{without foo}
> ...
> %endif
>
> ...so fewer changes and less work. I also think these conditions are
> quite fine (except relying on with_foo being either defined or
> undefined, which is quite funky but I don't think it is a reason to
> replace them).
>
> ---
>
> The yml files and translation from them into the actual macro files
> are nice but I would consider if the hw dependent default values can
> be added in future as a feature.
>
> The local_.yml file seems somewhat out of place to me. I think it
> could be rather kept as an idea for future and for now we could just
> start with only buildroot configs?
>
> Best regards!
> clime
>
> >
> > Cheers,
> > P
> > ___
> > 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: RFC: Feature macros (aka USE flags)

2020-04-27 Thread clime
On Mon, 27 Apr 2020 at 13:21, Petr Šabata  wrote:
>
> Based on the recent discussions around %fedora/%rhel macros and ELN,
> and %bcond generally being confusing to work with, I came up with a
> distribution-wide feature that defines generic feature keywords and
> associated helper macros that packages can check in build-time
> conditionals.
>
> The key advantage here is the defaults are defined by the buildroot,
> not the package. The package is just a building block.
>
> I'd like some input to improve this and unless this turns out to be a
> really bad idea, I intend to submit it as a change proposal. Even
> though the more packages use it the more beneficial it gets, it's, of
> course, perfectly optional.
>
> Details in the gist:
> https://gist.github.com/contyk/0f0585c57976ca18a293b3566408

Ad. Dan Mach's presented spec file:

> https://github.com/rpm-software-management/libdnf/blob/dnf-5-devel/libdnf.spec

I really like how all the switches are defined almost on top of the
spec file so I think lots of inspiration can be drawn from that.

Now I also think that introduction of the new %use scheme for build
options instead of the current with/without scheme might be an
overkill.

I think lines like these:

%bcond_with html
%bcond_without man

could be replaced by:

%with_option_env html 0
%with_option_env man 1

i.e. %with_option_env  

%with_option_env could be looking at an environmental buildroot
setting with the possibility to be overridden on command-line by
--with and --without as usual.

There could be also:
%with_option  

which wouldn't look at environment settings so it would be the same
thing as %bcond_with/%bcond_without but less confusing.

So with this, you wouldn't need to change conditions like:

%if %{with foo}
...
%endif

and

%if %{without foo}
...
%endif

...so fewer changes and less work. I also think these conditions are
quite fine (except relying on with_foo being either defined or
undefined, which is quite funky but I don't think it is a reason to
replace them).

---

The yml files and translation from them into the actual macro files
are nice but I would consider if the hw dependent default values can
be added in future as a feature.

The local_.yml file seems somewhat out of place to me. I think it
could be rather kept as an idea for future and for now we could just
start with only buildroot configs?

Best regards!
clime

>
> Cheers,
> P
> ___
> 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


[389-devel] Re: Github / Gitter (Chat service)

2020-04-27 Thread William Brown


> On 27 Apr 2020, at 19:18, Matus Honek  wrote:
> 
> On Sat, Apr 25, 2020 at 7:57 AM William Brown  wrote:
>> 
>> Hi all,
>> 
>> In the past I have previously "name squatted" 389ds on github, which has 
>> meant that I'm able to reserve 389ds on gitter - gitter is a web based chat, 
>> similar to irc, but "cool" with all the kids these days (which really, I 
>> shouldn't throw shade, I'm a kid still ...)
>> 
>> Anyway, I have setup a channel here:
>> 
>> https://gitter.im/389ds/community
>> 
>> It could be useful to us, and I'm wondering if it's something we would want 
>> to adopt more over IRC?
>> 
>> Thoughts?
> 
> I was a bit sceptical (another RAM/CPU eater tab) but found out it has
> an IRC bridge (https://irc.gitter.im/) and also you can set up email
> notifications.

Yeah, it's pretty nice actually. :) 

> But first, I think we should set up a live sync to
> https://github.com/389ds/389-ds-base repo since it is confusing to
> find an empty repo on the official github 389ds account.
> 

Yep, that's a good idea. I'll look into how to mirror that content.


>> 
>> —
>> Sincerely,
>> 
>> William Brown
>> 
>> Senior Software Engineer, 389 Directory Server
>> SUSE Labs
>> ___
>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
>> To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org
> 
> 
> 
> -- 
> Matúš Honěk
> Software Engineer
> Red Hat Czech
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org

—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org


FedoraRespin-31-updates-20200427.0 compose check report

2020-04-27 Thread Fedora compose checker
No missing expected images.

Failed openQA tests: 3/37 (x86_64)

ID: 588095  Test: x86_64 KDE-live-iso release_identification
URL: https://openqa.fedoraproject.org/tests/588095
ID: 588117  Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/588117
ID: 588125  Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/588125

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

ID: 588109  Test: x86_64 KDE-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/588109
ID: 588110  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/588110
ID: 588127  Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/588127
ID: 588130  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/588130

Passed openQA tests: 30/37 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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


[Bug 1828234] perl-Date-Holidays-DE-2.05 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1828234



--- Comment #7 from Fedora Update System  ---
FEDORA-EPEL-2020-5ac0523f9d has been submitted as an update to Fedora EPEL 6.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5ac0523f9d


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


[Bug 1828234] perl-Date-Holidays-DE-2.05 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1828234



--- Comment #6 from Fedora Update System  ---
FEDORA-EPEL-2020-c3f45edc3e has been submitted as an update to Fedora EPEL 7.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c3f45edc3e


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


[Bug 1828234] perl-Date-Holidays-DE-2.05 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1828234



--- Comment #5 from Fedora Update System  ---
FEDORA-EPEL-2020-36162c5f0c has been submitted as an update to Fedora EPEL 8.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-36162c5f0c


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


[Bug 1828234] perl-Date-Holidays-DE-2.05 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1828234



--- Comment #4 from Fedora Update System  ---
FEDORA-2020-153e823ca4 has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-153e823ca4


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


[Bug 1828234] perl-Date-Holidays-DE-2.05 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1828234

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-2020-0959698d0f has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-0959698d0f


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


[389-devel] please review: PR 51055 - invalid ACI causes heap-buffer-overflow in ldap_utf8prev

2020-04-27 Thread Mark Reynolds

https://pagure.io/389-ds-base/pull-request/51055

--

389 Directory Server Development Team
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org


Re: Orphaned packages looking for new maintainers (anaconda also affected)

2020-04-27 Thread Martin Jackson
I would be happy to maintain it -and it looks like it needs an epel8 
build.  (FAS: mhjacks)


Thanks,

Marty

On 4/27/20 2:13 PM, David Cantrell wrote:

On Mon, Apr 27, 2020 at 12:39:38PM +0200, Miro Hrončok wrote:

ckermit orphan   2 weeks ago


I took ownership of this one and have fixed it in rawhide.  If anyone 
really
wants to own this one, just let me know.  I have no problems turning 
it over
to someone else, but if that's no one then I will just maintain it.  I 
would

like ckermit to still be available and usable in Fedora.

Thanks,


___
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: HEADS UP: repoquery --whatrequires yields incomplete results when run from Fedora 32+

2020-04-27 Thread Fabio Valentini
On Mon, Apr 27, 2020 at 10:03 PM Michel Alexandre Salim
 wrote:
>
>
>
> On 4/3/20 4:47 AM, Miro Hrončok wrote:
> > On 11. 03. 20 17:25, Miro Hrončok wrote:
> >> I have upgraded to Fedora 32 today and after a while I have noticed
> >> that `repoquery --whatrequires` yields incomplete results.
> >>
> >>  From Fedora 31:
> >>
> >> $ dnf --refresh repoquery --repo=rawhide{,-source} --whatrequires
> >> python3-flaky
> >> pipenv-0:2018.11.26-13.fc32.src
> >> python-ipykernel-0:5.1.4-1.fc33.src
> >>
> >>
> >>  From Fedora 32/33:
> >>
> >> $ dnf --refresh repoquery --repo=rawhide{,-source} --whatrequires
> >> python3-flaky
> >> python-ipykernel-0:5.1.4-1.fc33.src
> >>
> >>
> >> I have reported this here:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1812596
> >>
> >>
> >> Be extra careful when taking decisions based on `repoquery
> >> --whatrequires` (such as: I can safely retire this or upgrade that,
> >> nothing else requires it).
> >
> >
> > An update that fixes this is ready in:
> >
> > https://bodhi.fedoraproject.org/updates/FEDORA-2020-6ba2550a4e
> >
> I have a newer version of libdnf but - going through Miro's recent list
> of orphaned packages, couldn't find any usage of maven-release. Am I
> doing something wrong here?

It looks like nothing requires the maven-release package directly.
Only via the maven-release-plugin subpackage of maven-release is
depended on by other packages, not the main package itself - so you'd
just have to change your query from maven-release to
maven-release-plugin.

Fabio

> ~
> ❯ sudo dnf repoquery --repo rawhide{,-source} --alldeps --whatrequires
> maven-release
> Last metadata expiration check: 0:15:18 ago on Mon 27 Apr 2020 12:44:27
> PM PDT.
>
> ~
> ❯ rpm -q libdnf
> libdnf-0.47.0-1.fc32.x86_64
>
> Thanks,
>
> --
> Michel Alexandre Salim
> profile: https://keybase.io/michel_slm
> chat via email: https://delta.chat/
> GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
> ___
> 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: HEADS UP: repoquery --whatrequires yields incomplete results when run from Fedora 32+

2020-04-27 Thread Michel Alexandre Salim



On 4/3/20 4:47 AM, Miro Hrončok wrote:

On 11. 03. 20 17:25, Miro Hrončok wrote:
I have upgraded to Fedora 32 today and after a while I have noticed 
that `repoquery --whatrequires` yields incomplete results.


 From Fedora 31:

$ dnf --refresh repoquery --repo=rawhide{,-source} --whatrequires 
python3-flaky

pipenv-0:2018.11.26-13.fc32.src
python-ipykernel-0:5.1.4-1.fc33.src


 From Fedora 32/33:

$ dnf --refresh repoquery --repo=rawhide{,-source} --whatrequires 
python3-flaky

python-ipykernel-0:5.1.4-1.fc33.src


I have reported this here: 
https://bugzilla.redhat.com/show_bug.cgi?id=1812596



Be extra careful when taking decisions based on `repoquery 
--whatrequires` (such as: I can safely retire this or upgrade that, 
nothing else requires it).



An update that fixes this is ready in:

https://bodhi.fedoraproject.org/updates/FEDORA-2020-6ba2550a4e

I have a newer version of libdnf but - going through Miro's recent list 
of orphaned packages, couldn't find any usage of maven-release. Am I 
doing something wrong here?


~
❯ sudo dnf repoquery --repo rawhide{,-source} --alldeps --whatrequires 
maven-release
Last metadata expiration check: 0:15:18 ago on Mon 27 Apr 2020 12:44:27 
PM PDT.


~
❯ rpm -q libdnf
libdnf-0.47.0-1.fc32.x86_64

Thanks,

--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
chat via email: https://delta.chat/
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
___
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


[Bug 1828235] perl-Devel-PatchPerl-1.92 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1828235

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


Re: f32-backgrounds look like crap

2020-04-27 Thread Adam Williamson
On Mon, 2020-04-27 at 17:52 +0100, José Abílio Matos wrote:
> At the same time I also liked to hear some of reasoning behind the reasons 
> for the 
> wallpaper. IMHO it is shame that at least a short abstract it is not 
> available here.

https://pagure.io/design/issue/669
-- 
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: Orphaned packages looking for new maintainers (anaconda also affected)

2020-04-27 Thread David Cantrell

On Mon, Apr 27, 2020 at 12:39:38PM +0200, Miro Hrončok wrote:

ckermit   orphan   2 weeks ago


I took ownership of this one and have fixed it in rawhide.  If anyone really
wants to own this one, just let me know.  I have no problems turning it over
to someone else, but if that's no one then I will just maintain it.  I would
like ckermit to still be available and usable in Fedora.

Thanks,

--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
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


Logs for the Open NeuroFedora Meeting: 1800 UTC on Monday, 28th April

2020-04-27 Thread Aniket Pradhan
Hey there!

Thanks, everyone for attending the meeting. We shall meet in two
weeks' time, which is 12th May 2020, at 1800 UTC.

Links to the logs from today's meeting:
* 
https://meetbot.fedoraproject.org/fedora-neuro/2020-04-27/neurofedora.2020-04-27-18.01.log.html
* 
https://meetbot.fedoraproject.org/fedora-neuro/2020-04-27/neurofedora.2020-04-27-18.01.html

Minutes in text format for your convenience:

===
#fedora-neuro: NeuroFedora - 2020-04-27
===


Meeting started by MeWjOr at 18:01:11 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-neuro/2020-04-27/neurofedora.2020-04-27-18.01.log.html
.



Meeting summary
---
* Agenda for today's meeting  (MeWjOr, 18:02:30)
* Intro/roll call  (MeWjOr, 18:02:39)
* Tasks from last meeting
  
https://meetbot.fedoraproject.org/fedora-neuro/2020-04-07/neurofedora.2020-04-07-16.02.html
  (MeWjOr, 18:02:55)
* Pagure tickets:
  
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting
  (MeWjOr, 18:03:09)
* Bugzilla tickets https://tinyurl.com/neurofedora-bugs  (MeWjOr,
  18:03:26)
* compose status  (MeWjOr, 18:03:45)
* (neuro)science query of the week  (MeWjOr, 18:03:51)
* Next meeting, time, date, chair  (MeWjOr, 18:03:55)
* Open floor  (MeWjOr, 18:04:01)
* Intros/Roll call  (MeWjOr, 18:04:14)
  * @ankursinha: UTC+1, NeuroFedora, packaging, other misc bits
(FranciscoD, 18:04:57)

* Tasks from last meeting
  
https://meetbot.fedoraproject.org/fedora-neuro/2020-04-07/neurofedora.2020-04-07-16.02.html
  (MeWjOr, 18:09:20)
  *   (MeWjOr, 18:09:34)
  * FranciscoD Comment on the ticket to provide feedback on the
neurofedora brochure within the next week -- Done  (MeWjOr,
18:09:41)
  * https://pagure.io/design/issue/661 -> brochure ticket  (FranciscoD,
18:10:15)
  * ACTION: everyone please take a look at the brochure and provide
feedback: https://pagure.io/design/issue/661  (FranciscoD, 18:11:24)
  * lbazan to work on pending review tickets  (MeWjOr, 18:13:38)
  * LINK:

https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=0=lbazan_status=
(FranciscoD, 18:14:56)
  * numpoly is in testing:
https://bugzilla.redhat.com/show_bug.cgi?id=1808552  (FranciscoD,
18:15:32)
  * pydeps is also in testing:
https://bugzilla.redhat.com/show_bug.cgi?id=1741624  (FranciscoD,
18:15:52)

* Pagure tickets:
  
https://pagure.io/neuro-sig/NeuroFedora/issues?status=Open=S%3A+Next+meeting
  (MeWjOr, 18:16:57)
  * LINK: https://pagure.io/neuro-sig/NeuroFedora/issue/351
(FranciscoD, 18:18:32)
  * FranciscoD will write and publish a blog post to sync with F32
release: https://pagure.io/neuro-sig/NeuroFedora/issue/351
(FranciscoD, 18:18:44)
  * ACTION: FranciscoD share link to post here in the channel so we can
spread it on our social media channels  (FranciscoD, 18:19:46)

* Bugzilla bugs: https://tinyurl.com/neurofedora-bugs  (MeWjOr,
  18:21:53)
  * LINK:

https://bugzilla.redhat.com/buglist.cgi?classification=Fedora=python-tqdm_id=11020794=Fedora
(FranciscoD, 18:28:57)
  * LINK: https://paste.centos.org/view/d236c565 -> utils  (FranciscoD,
18:35:58)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1827957 +
https://bugzilla.redhat.com/show_bug.cgi?id=1828079  (FranciscoD,
18:40:35)
  * FranciscoD needs two packages reviewed:
https://bugzilla.redhat.com/show_bug.cgi?id=1828079 +
https://bugzilla.redhat.com/show_bug.cgi?id=1827957  (FranciscoD,
18:40:58)

* compose status  (MeWjOr, 18:42:29)
  * ACTION: FranciscoD update docs to remove info about the iso image we
generated  (FranciscoD, 18:47:08)
  * rawhide compose will start functioning once this PR is merged and
json pickle built:
https://src.fedoraproject.org/rpms/python-jsonpickle/pull-request/4
(FranciscoD, 18:47:28)
  * MeWjOr will monitor composes until we find another spin master
(FranciscoD, 18:48:08)
  * ACTION: FranciscoD e-mail devel list asking for volunteers
(FranciscoD, 18:48:21)
  * ACTION: FranciscoD add spin-master to list of open positions in blog
post  (FranciscoD, 18:48:30)
  * ACTION: FranciscoD e-mail neuroscience mailing lists about the
CompNeuro release  (FranciscoD, 18:50:35)

* neuroscience query of the week?  (MeWjOr, 18:51:32)
  * https://pagure.io/neuro-sig/NeuroFedora/issue/318  (MeWjOr,
18:52:09)

* open floor  (MeWjOr, 18:59:36)

Meeting ended at 19:03:45 UTC.




Action Items

* everyone please take a look at the brochure and provide feedback:
  https://pagure.io/design/issue/661
* FranciscoD share link to post here in the channel so we can spread it
  on our social media channels
* FranciscoD update docs to remove info about the iso image we generated
* FranciscoD e-mail devel list asking for volunteers
* FranciscoD add spin-master to list of open positions in blog post
* FranciscoD e-mail neuroscience mailing lists about the CompNeuro
  

Re: What CPU extensions can we assume are available by arch?

2020-04-27 Thread Steven Munroe
Dan writes:
>> Dave Love writes:
>> Well, what I've already said from some experience and research. Where's the 
>> POWER and >>S390 support? All I saw is x86 and arm. We've heard there's 
>> ppc64le compatibility support
>>anyhow, which is rising
>
>gcc provides compat x86 intrinsics via "x86intrin.h", they were successfully 
>used eg.
>by darktable (raw photo sw)

Yes there are some, looks like GCC8 and later. This is what is in GCC9:
$ find /opt/at13.0/ -name '*intrin.h'
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/bmi2intrin.h
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/mmintrin.h
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/x86intrin.h
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/htmintrin.h
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/pmmintrin.h
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/htmxlintrin.h
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/xmmintrin.h
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/tmmintrin.h
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/emmintrin.h
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/bmiintrin.h
/opt/at13.0/lib/gcc/powerpc64le-linux-gnu/9.2.1/include/smmintrin.h

So most of SSE, but not AVX yet.

If course this is compromise. May not be as optimal of a native
PowerISA implementation on POWER (CISC vs RISC out-of-order,
super-scalar ). This is what PVECLIB is for.
___
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


Summary/Minutes from today's FESCo Meeting (2020-04-27)

2020-04-27 Thread Aleksandra Fedorova

#fedora-meeting-1: fesco



Meeting started by bookwar at 15:00:30 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-1/2020-04-27/fesco.2020-04-27-15.00.log.html




Meeting summary
---
* init process  (bookwar, 15:00:54)

* #2372 F33 Self-contained Change: Network Time Security  (bookwar,
  15:02:34)
  * AGREED: postpone discussion until TBD items are resolved (+8, 0, 0)
(bookwar, 15:06:52)

* #2382 systemd default service exception for rpmdb-rebuild service
  (bookwar, 15:07:39)
  * ACTION: sgallagh to update the ticket with the new proposed approach
and try to help test it  (sgallagh, 15:17:01)

* #2371 F33 System-Wide Change: Removal of the glibc-headers package
  (bookwar, 15:17:52)
  * AGREED: APPROVED (+6, 2, 0)  (bookwar, 15:23:48)

* Next week's chair  (bookwar, 15:24:08)
  * ACTION: decathorpe to chair next one  (bookwar, 15:25:29)

* Open floor  (bookwar, 15:25:43)
  * Issue #2383: fesco statement on the dist-git change process
(bookwar, 15:57:02)

Meeting ended at 15:57:43 UTC.




Action Items

* sgallagh to update the ticket with the new proposed approach and try
  to help test it
* decathorpe to chair next one




Action Items, by person
---
* decathorpe
  * decathorpe to chair next one
* sgallagh
  * sgallagh to update the ticket with the new proposed approach and try
to help test it
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* bookwar (70)
* zbyszek (45)
* sgallagh (27)
* nirik (24)
* zodbot (19)
* adamw (13)
* mhroncok (6)
* bcotton (5)
* decathorpe (5)
* dcantrell (4)
* contyk (4)
* ignatenkobrain (0)


-- 
Aleksandra Fedorova
bookwar
___
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: What CPU extensions can we assume are available by arch?

2020-04-27 Thread Steven Munroe
Kevin Kofler wrote

>>Florian Weimer wrote:
>>...
>> In general, that is not true. You can use the target function attribute
and function
>> multiversioning instead in many cases.

>This may (or may not) have been recently fixed, but last I checked,
intrinsics for a vector
>instruction set XYZ2 were only available with the corresponding -mxyz2
flag, which could
>only be set per compilation unit (attempting to use the recently
introduced flag pragmas for
>this purpose was not supported either), and which would lead to GCC in
some cases
>(out of the library programmer's control) using XYZ2 instructions also in
other functions.
>As a result, the only safe way was to put all XYZ2 code in a separate
compilation unit
>compiled with -mxyz2 (and only that compilation unit can use that flag).
Has that situation
> mproved recently (and how so)?
>
>And that is just for C or non-template C++ code. C++
> template instantiations make the situation even messier.

Yes still true. I encounter this implement vec_int512_ppc.h for pveclib.
There a easy to use work around described here Putting the library in
PVECLIB. I
will not claim this is elegant but it does work.

My goal (pveclib) is to make it easier to write vector codes that CAN be
used in functions that CAN be built for multiple processor targets and
dynamic selection. My case is simpler then x86 (and SIMDE) as for ppc64le I
only have to deal with power8/9.

This a hard problem, and not solution is ease or perfect. But we can improve
___
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: RFC: Feature macros (aka USE flags)

2020-04-27 Thread Nicolas Mailhot via devel
Le lundi 27 avril 2020 à 19:12 +0200, Petr Šabata a écrit :
> 
> Yes, this is exactly what I'm trying to achieve -- to have
> distribution-wide generic keywords that control default build options
> in packages

It can be done at the rpm layer and in fact there are already quite a
lot of such tunables in the distribution that packagers rely on every
day without realising it.

The basic integration pattern is:
1. you define a set of nice useful macros (in redhat-rpm-config or in
your own foo-rpm-macros project)
2. you make their behaviour dependant on the value of nicely named
variables
3. you ship default distro-wide values for those variables in a
separate macro file
4. you document the whole thing, get it reviewed, added to Fedora
guidelines by FPC, and added to the default buidroot
5. you spend ~1 year helping people use it (after that there are enough
examples in the distro to cut & paste, that packagers feel autonomous)

From this point on you can control the default behaviour of all the
spec files that used you macros distro-wide by changing the default
value of your tunables. Downstreams can change the behaviour by
changing the default tunable values in their version of the central
macro package. Packagers can override the default in individual spec
files just by setting a variable in their spec file if the default does
not work for their project, etc.

It’s a huge amount of design and review work however. Once you play
with the default behaviour of just a few % of distribution packages,
you need to be extra careful. 

-- 
Nicolas Mailhot
___
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: RFC: Feature macros (aka USE flags)

2020-04-27 Thread Daniel Mach



Dne 27. 04. 20 v 19:00 Stephen Gallagher napsal(a):

On Mon, Apr 27, 2020 at 10:47 AM Daniel Mach  wrote:


I'm wondering if this is your personal initiative or if you're sync with
ELN people. I emailed them in January about the very same idea (and I
used the very same name; we both seem to like Gentoo), we exchanged
couple emails, but never got an answer if this is the way to go. Since I
have a lot of problems of my own (dnf, rpm, modularity), I did not want
to start this as my personal initiative.



Yes, Petr is in fact ELN people and he's working on this at least
partly within that context (though the benefits are not exclusive to
ELN).

We looked at your approach, but it seemed like you were advocating for
dealing with this somehow at the libdnf layer, which we didn't think
was the right place. If we misunderstood, that's on us.
Most likely. It had nothing to do with libdnf, it was a generic concept 
based on centralized macros defined in the build roots.





I'm really glad that someone's looking into this finally.
BTW, the new libdnf spec is using this approach already:
https://github.com/rpm-software-management/libdnf/blob/dnf-5-devel/libdnf.spec



Well, not exactly. But it's similar. The main advantage here is that
we can define some things globally for all packages.a

Yes, that was exactly the point in my proposal.
Building for another use case would mean just setting build root macros 
and building the package differently, no spec change needed.





Since I'm part of RPM team too, I hope they won't mind if I'll speak for
them :) Don't you rather want to work with us on extending the existing
with/without macros? I'd prefer to improve the existing approach over
creating something brand new. We could also reuse existing rpmbuild
--with/--without arguments and ideally remain backwards compatible.


Could you explain a bit more what this means to you? I'm not sure what
you would want to do in RPM itself.
rpmbuild supports --with and --without options for setting the %with 
macros already. That allows you to make a local build with custom %with 
values. I suppose you'll need something similar for the new feature. 
From my perspective it would be better to re-use the existing options 
rather than introducing --use/--dont-use or something similar.



___
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: f32-backgrounds look like crap

2020-04-27 Thread José Abílio Matos
On Friday, 17 April 2020 19.05.40 WEST Pierre-Yves Chibon wrote:
> I really do not see how you could construct this reply from Michael's.
> He clearly starts with IMO and the rest of is the expression of his opinion,
> he never calls anyone anything.
> 
> I'm confused here.
> 
> Pierre

I left this with no answer on purpose. I did not wanted to add further noise to 
this thread. 
I did not like the wallpaper initially but I do not subscribe to the title of 
the thread.

FWIW I think that Michael's answer was thoughtful and interesting to read.
By decomposing the reasons into the different layers I have associated the 
subject to 
deconstructionism.

At the same time there was a clear divide in the different opinions (likes or 
dislikes) 
regarding the different backgrounds: some more abstract like the F32 while 
others take an 
approach based on realism/naturalism or even other that follow modernism.

At the same time I also liked to hear some of reasoning behind the reasons for 
the 
wallpaper. IMHO it is shame that at least a short abstract it is not available 
here.

On the other hand one of reasons the reactions were in two very different 
fields, there was 
one more involved that defended the decision to go with this wallpaper based on 
a series 
of rational arguments. In the other field there was a more instinctive reaction 
of dislike.

That was the reason of my failed attempt to light the situation by referring 
to: 

"""
Abstract art can also make people uneasy because they don't automatically know 
what the 
art is "about" just by a cursory glance. Or they assume that because it doesn't 
look like 
anything, then it is not "about" anything.
"""
https://www.art-is-fun.com/understanding-abstract-art[1] 

I seems that I failed to convey that in the previous message. It was my fault. 
:-)
-- 
José Abílio


[1] https://www.art-is-fun.com/understanding-abstract-art
___
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: What CPU extensions can we assume are available by arch?

2020-04-27 Thread Jun Aruga
> gcc provides compat x86 intrinsics via "x86intrin.h", they were
> successfully used eg. by darktable (raw photo sw)

Okay. Thanks for the info.

-- 
Jun | He - His - Him
___
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: RFC: Feature macros (aka USE flags)

2020-04-27 Thread Petr Šabata
On Mon, Apr 27, 2020 at 6:38 PM Vít Ondruch  wrote:
>
>
> Dne 27. 04. 20 v 16:25 Petr Šabata napsal(a):
> > On Mon, Apr 27, 2020 at 3:01 PM Vít Ondruch  wrote:
> >>
> >> Dne 27. 04. 20 v 13:19 Petr Šabata napsal(a):
> >>> Based on the recent discussions around %fedora/%rhel macros and ELN,
> >>> and %bcond generally being confusing to work with, I came up with a
> >>> distribution-wide feature that defines generic feature keywords and
> >>> associated helper macros that packages can check in build-time
> >>> conditionals.
> >>
> >> The most confusing part of the %bcond is the definition itself. The rest
> >> is fine IMO. Therefore, I somehow don't understand why would you like to
> >> replace:
> >>
> >>
> >> ```
> >>
> >> %if %{with ssl}
> >> BuildRequires:  openssl-devel
> >> %endif
> >>
> >> ```
> >>
> >>
> >> by
> >>
> >>
> >> ```
> >>
> >> %if %{use ssl}
> >> BuildRequires:  openssl-devel
> >> %endif
> >>
> >> ```
> > The difference here is %use defaults are defined by the buildroot
> > while %with %bconds are defined by the package.
>
>
> Looking at the provided example and the binary RPM and what not, I am
> still confused and it is not clear to me what you actually want to achieve.
>
> I think the biggest issue I have is that you seems to propose to use the
> `%{use ssl}`, `%{use_enable ssl openssl}` and `%{?_use_ssl:-DSSL}` in
> places, where it would make more sense to use the well established
> `with/without` rpm(build) macros.
>
> Also, this `%{use_enable ssl openssl}` for example looks like you have
> some distribution wide `ssl` feature, but you want to locally implement
> it via openssl and moreover it seems you are trying to address the case
> where `configure` does not accept with/without but enable/disable
> instead (which was probably not an issue so far, otherwise rpmbuild
> would probably provide enable/disable options alongside with/without).

Yes, this is exactly what I'm trying to achieve -- to have
distribution-wide generic keywords that control default build options
in packages. In the example SSL support is enabled via the openssl
package.

The well-established with/without options and their defaults are bound
to the package, not the buildroot, which is the key idea behind this,
not the exact helper scripts. Considering it's a repeated point in
this thread, I should have done better job emphasizing it :)

> IOW it could be probably better if there was something like `%{use ssl
> openssl}` call on top of the .spec file, which would enable use of
> standard RPM macros instead of introducing set of new macros. This would
> also make the `general availability` section much shorter, because there
> would be probably need to check the macro existence on a single place.

Something like that could be done and would be an option if no one
cared for the helper macros (currently limited to autotools but the
list could grow). We could actually make this nice and SPECs more
readable.

P
___
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: What CPU extensions can we assume are available by arch?

2020-04-27 Thread Jun Aruga
> They're packages for a header-only system, not libraries, hence my
confusion.

Hi Dave, okay.

> Who's pushing this, and how do I present an HPC performance engineering
perspective?

I appreciate your interest in the bioinformatics in HPC.
The simde Fedora package: Me
The simde Debian package: Michael  (You can see his account in the
simde project. The author of the Common Workflow Language).

If you want to discuss something related to simde, opening the ticket
on the upstream might be good.
https://github.com/nemequ/simde

My target is to enable the set of bio tools RPMs used in COVID-19
analysis on ppc64le and aarch64 based HPC use cases.
As you know there are ppc64le and aarch64 based HPC where it's hard to
run some of the bio-tools.

> Well, what I've already said from some experience and research.  Where's
> the POWER and S390 support?  All I saw is x86 and arm.  We've heard
> there's ppc64le compatibility support anyhow, which is rising up my list
> to investigate for work.  Who's going to do bioinformatics on Blue
> Boxes?  Bioinf causes enough trouble on x86...

bowtie2
* POWER: supported from version 2.4.0.
  > Added preliminary support for ppc64le architectures with the help
of SIMDE project
  
https://github.com/BenLangmead/bowtie2/blob/b8c13c0401885873a99b229fca668deecde08749/NEWS#L46-L47
  Travis CI ppc64le job:
https://github.com/BenLangmead/bowtie2/blob/master/.travis.yml#L75
* s390x: Not supported yet. Some tests failed.
  https://github.com/BenLangmead/bowtie2/issues/286

minimap2
https://github.com/lh3/minimap2
There is no official support yet. But a little discussion about it.
You see Makefile.simde is added on the latest commits.
That means we can try to build it as potentially. I am planning to
contribute to the upstream for that.

> Who's going to do bioinformatics on Blue Boxes?  Bioinf causes enough trouble 
> on x86...

What is Blue Boxes and Bioinf?

> There's been an issue for bowtie2 for years, and I've long had it in
> copr, though it probably needs updating there.  Has someone done the
> unresponsive maintainer thing for Adam Huffman (who is, or was, back
> more in that area)?

You can pick up the bowtie2 latest version x86 and arm on my copr
repository here.
Copr does not have a ppc64le build root right now.
https://copr.fedorainfracloud.org/coprs/jaruga/staging/packages/
Or from my scratch build to pick up the ppc64le version.
https://koji.fedoraproject.org/koji/taskinfo?taskID=43660524

As I said, bowtie2 is in review status for the Fedora dist-git from last Friday.
I sometimes work with Adam for bioinformatics tools. He is busy with
his main job to respond.
I have been co-maintainer of some of his RPM packages such as
samtools, bwa, bowtie, working on it instead of him.

If you are interested in bioinformatics, DNA/RNA sequencing in Fedora,
Fedora medical-sig is the place. We can talk there.
You may see some information that you are interested in there.
https://fedoraproject.org/wiki/SIGs/Medical

Cheers,
Jun

-- 
Jun | He - His - Him
___
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


Node.js 14 in F33

2020-04-27 Thread Zuzana Svetlikova
Node.js v14.x was released last week, which should become LTS in autumn.
modular builds for stable releases and rawhide are already submitted in
Bodhi and should
be available soon. I'd like to make it the default stream for F33 once it's
tested a bit.

I'd like to ask maintainers and users of nodejs and nodejs packages to test
v14,
so we are aware of any issues that might arise. I'll submit the Change
Proposal to switch
the default to v14 rawhide sometime in May.
___
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: RFC: Feature macros (aka USE flags)

2020-04-27 Thread Stephen Gallagher
On Mon, Apr 27, 2020 at 10:47 AM Daniel Mach  wrote:
>
> I'm wondering if this is your personal initiative or if you're sync with
> ELN people. I emailed them in January about the very same idea (and I
> used the very same name; we both seem to like Gentoo), we exchanged
> couple emails, but never got an answer if this is the way to go. Since I
> have a lot of problems of my own (dnf, rpm, modularity), I did not want
> to start this as my personal initiative.
>

Yes, Petr is in fact ELN people and he's working on this at least
partly within that context (though the benefits are not exclusive to
ELN).

We looked at your approach, but it seemed like you were advocating for
dealing with this somehow at the libdnf layer, which we didn't think
was the right place. If we misunderstood, that's on us.

> I'm really glad that someone's looking into this finally.
> BTW, the new libdnf spec is using this approach already:
> https://github.com/rpm-software-management/libdnf/blob/dnf-5-devel/libdnf.spec
>

Well, not exactly. But it's similar. The main advantage here is that
we can define some things globally for all packages.a

> Since I'm part of RPM team too, I hope they won't mind if I'll speak for
> them :) Don't you rather want to work with us on extending the existing
> with/without macros? I'd prefer to improve the existing approach over
> creating something brand new. We could also reuse existing rpmbuild
> --with/--without arguments and ideally remain backwards compatible.

Could you explain a bit more what this means to you? I'm not sure what
you would want to do in RPM itself.
___
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


[389-devel] please review: PR 51053 - CLI - inconsistent confirmation prompts

2020-04-27 Thread Mark Reynolds

https://pagure.io/389-ds-base/pull-request/51053

--

389 Directory Server Development Team
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org


Re: RFC: Feature macros (aka USE flags)

2020-04-27 Thread Vít Ondruch

Dne 27. 04. 20 v 16:25 Petr Šabata napsal(a):
> On Mon, Apr 27, 2020 at 3:01 PM Vít Ondruch  wrote:
>>
>> Dne 27. 04. 20 v 13:19 Petr Šabata napsal(a):
>>> Based on the recent discussions around %fedora/%rhel macros and ELN,
>>> and %bcond generally being confusing to work with, I came up with a
>>> distribution-wide feature that defines generic feature keywords and
>>> associated helper macros that packages can check in build-time
>>> conditionals.
>>
>> The most confusing part of the %bcond is the definition itself. The rest
>> is fine IMO. Therefore, I somehow don't understand why would you like to
>> replace:
>>
>>
>> ```
>>
>> %if %{with ssl}
>> BuildRequires:  openssl-devel
>> %endif
>>
>> ```
>>
>>
>> by
>>
>>
>> ```
>>
>> %if %{use ssl}
>> BuildRequires:  openssl-devel
>> %endif
>>
>> ```
> The difference here is %use defaults are defined by the buildroot
> while %with %bconds are defined by the package.


Looking at the provided example and the binary RPM and what not, I am
still confused and it is not clear to me what you actually want to achieve.

I think the biggest issue I have is that you seems to propose to use the
`%{use ssl}`, `%{use_enable ssl openssl}` and `%{?_use_ssl:-DSSL}` in
places, where it would make more sense to use the well established
`with/without` rpm(build) macros.

Also, this `%{use_enable ssl openssl}` for example looks like you have
some distribution wide `ssl` feature, but you want to locally implement
it via openssl and moreover it seems you are trying to address the case
where `configure` does not accept with/without but enable/disable
instead (which was probably not an issue so far, otherwise rpmbuild
would probably provide enable/disable options alongside with/without).

IOW it could be probably better if there was something like `%{use ssl
openssl}` call on top of the .spec file, which would enable use of
standard RPM macros instead of introducing set of new macros. This would
also make the `general availability` section much shorter, because there
would be probably need to check the macro existence on a single place.


Vít



>
>> Also I don't understand, why there is exposed some underscore macro,
>> such as `make test %{?_use_ssl:-DSSL}`. Shouldn't the underscore macro
>> be just implementation detail? For `%bcond`s, the `_with` macros are
>> discouraged, so why would you encourage them?
> Yes, this should be an internal detail. I'd like to replace this with
> %use_defined or something similar.
>
> P
> ___
> 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: dropping NSS DBM format support in F33+

2020-04-27 Thread Ondrej Mosnacek
On Mon, Apr 27, 2020 at 5:54 PM Paul Moore  wrote:
> On Sat, Apr 25, 2020 at 1:21 PM Justin Forbes  wrote:
> > On Sat, Apr 25, 2020 at 10:21 AM Daiki Ueno  wrote:
> > >
> > > Hello Ondrej,
> > >
> > > Ondrej Mosnacek  writes:
> > >
> > > > On Fri, Apr 24, 2020 at 11:12 PM Ondrej Mosnacek  
> > > > wrote:
> > > >> On Fri, Apr 24, 2020 at 8:50 PM Ondrej Mosnacek  
> > > >> wrote:
> > > >> > On Wed, Apr 22, 2020 at 10:12 AM Daiki Ueno  
> > > >> > wrote:
> > > >> > > Hello,
> > > >> > >
> > > >> > > I am not sure if this deserves a Fedora Change proposal, so I'd 
> > > >> > > like to
> > > >> > > hear any opinions first before proceeding with the process.
> > > >> > >
> > > >> > > NSS (the crypto library used by Firefox) historically supports 2
> > > >> > > database formats: SQLite and DBM.  The latter is considered legacy 
> > > >> > > and
> > > >> > > we switched the default database format to SQLite in F28[1].  
> > > >> > > Since then
> > > >> > > I presume most of the applications have switched to the new format.
> > > >> > > Therefore we are planning to phase out the support of DBM, 
> > > >> > > targetting
> > > >> > > F33+.
> > > >> > >
> > > >> > > Please let me know if there is any concern.
> > > >> >
> > > >> > It seems this broke the kernel build. I did some scratch build today
> > > >> > to test some patches, but it failed with this:
> > > >> >
> > > >> > + /usr/bin/pesign -c 'Red Hat Test Certificate' --certdir
> > > >> > /etc/pki/pesign-rh-test -i arch/x86/boot/bzImage -o vmlinuz.signed -s
> > > >> > pesign: Could not initialize nss.
> > > >> > NSS says "The certificate/key database is in an old, unsupported
> > > >> > format." errno says "No such file or directory"
> > > >> > error: Bad exit status from /var/tmp/rpm-tmp.YKqoK0 (%build)
> > > >> > RPM build errors:
> > > >> > Bad exit status from /var/tmp/rpm-tmp.YKqoK0 (%build)
> > > >> > Child return code was: 1
> > > >>
> > > >> Probably related: https://github.com/rhboot/pesign/issues/34
> > > >
> > > > I filed a bug against pesign here:
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1827902
> > >
> > > Good catch, and thank you for filing the bug.  For the meantime I
> > > reverted the DBM disablement to unblock the kernel package build:
> > > https://src.fedoraproject.org/rpms/nss/c/fc0174ead16bac476cce55fb2918fbfd9b448023?branch=master
> > >
> >
> > Thanks for that, I know they were working on a fix for pesign on
> > Friday, but I am not sure what their timeframe is.
>
> I hit this over the weekend, does anyone have a workaround?

The NSS change has been reverted, so kernel builds should work now
(worked for me this morning [CEST]).

-- 
Ondrej Mosnacek 
Software Engineer, Security Technologies
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: [Fedora-packaging] Re: Macronize %pytest

2020-04-27 Thread Neal Gompa
On Mon, Apr 27, 2020 at 11:58 AM Nicolas Mailhot
 wrote:
>
> Le lundi 27 avril 2020 à 11:34 +0200, Miro Hrončok a écrit :
> > Hello Python packagers,
> >
> > Usage:
> >
> >%check
> >%pytest
> >
> > Or with options passed to pyets:
> >
> >%check
> >%pytest -v -m "not network" tests/
>
> I ended up renaming similar macros as %foocheck (after several false
> starts).
>
> Having a domain-specific macro named slightly differently than the rpm
> section it is supposed to occur in was tripping packagers all the time.
>

The problem in Python land is that there are multiple different
options for tests, even with setuptools or whatnot. So some knowledge
of the tool is required, since there is no standardized interface
anymore (setup.py test is going away).


-- 
真実はいつも一つ!/ Always, there's only one truth!
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/python-devel@lists.fedoraproject.org


Re: What CPU extensions can we assume are available by arch?

2020-04-27 Thread Dan Horák
On Mon, 27 Apr 2020 16:23:39 +0100
Dave Love  wrote:

> Jun Aruga  writes:
> 
> >> > For the better user experience, we are promoting the system
> >> > library for both RPM and Debian based Linux distributions.
> >>
> >> What system library, for what purpose?
> >
> > Hi Dave,
> > The simde system library is
> >
> > * simde-devel in Fedora and EPEL [1]
> > * libsimde-dev in Debian [2]
> 
> They're packages for a header-only system, not libraries, hence my
> confusion.
> 
> Who's pushing this, and how do I present an HPC performance
> engineering perspective?
> 
> > The purpose is to build and ship SIMD implemented software RPM such
> > as bowite2 [3] and minimap2 [4] on non-x86_64 CPU architecture such
> > as aarch64, ppc64le and s390x.
> 
> Well, what I've already said from some experience and research.
> Where's the POWER and S390 support?  All I saw is x86 and arm.  We've
> heard there's ppc64le compatibility support anyhow, which is rising

gcc provides compat x86 intrinsics via "x86intrin.h", they were
successfully used eg. by darktable (raw photo sw)


Dan

> up my list to investigate for work.  Who's going to do bioinformatics
> on Blue Boxes?  Bioinf causes enough trouble on x86...
> 
> There's been an issue for bowtie2 for years, and I've long had it in
> copr, though it probably needs updating there.  Has someone done the
> unresponsive maintainer thing for Adam Huffman (who is, or was, back
> more in that area)?
> ___
> 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: What CPU extensions can we assume are available by arch?

2020-04-27 Thread Dave Love
Jun Aruga  writes:

>> > For the better user experience, we are promoting the system library
>> > for both RPM and Debian based Linux distributions.
>>
>> What system library, for what purpose?
>
> Hi Dave,
> The simde system library is
>
> * simde-devel in Fedora and EPEL [1]
> * libsimde-dev in Debian [2]

They're packages for a header-only system, not libraries, hence my
confusion.

Who's pushing this, and how do I present an HPC performance engineering
perspective?

> The purpose is to build and ship SIMD implemented software RPM such as
> bowite2 [3] and minimap2 [4] on non-x86_64 CPU architecture such as
> aarch64, ppc64le and s390x.

Well, what I've already said from some experience and research.  Where's
the POWER and S390 support?  All I saw is x86 and arm.  We've heard
there's ppc64le compatibility support anyhow, which is rising up my list
to investigate for work.  Who's going to do bioinformatics on Blue
Boxes?  Bioinf causes enough trouble on x86...

There's been an issue for bowtie2 for years, and I've long had it in
copr, though it probably needs updating there.  Has someone done the
unresponsive maintainer thing for Adam Huffman (who is, or was, back
more in that area)?
___
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: What CPU extensions can we assume are available by arch?

2020-04-27 Thread Dave Love
Kevin Kofler  writes:

> Florian Weimer wrote:
>> In general, that is not true.  You can use the target function attribute
>> and function multiversioning instead in many cases.
>
> This may (or may not) have been recently fixed, but last I checked, 
> intrinsics for a vector instruction set XYZ2 were only available with the 
> corresponding -mxyz2 flag, which could only be set per compilation unit 
> (attempting to use the recently introduced flag pragmas for this purpose was 
> not supported either), and which would lead to GCC in some cases (out of the 
> library programmer's control) using XYZ2 instructions also in other 
> functions. As a result, the only safe way was to put all XYZ2 code in a 
> separate compilation unit compiled with -mxyz2 (and only that compilation 
> unit can use that flag). Has that situation improved recently (and how so)?

I haven't needed to try it so far, but I'd trust Florian on the topic,
given the GCC doc on function attributes and pragmas.  You might not
have intrinsics anyhow.
___
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


Unannounced soname bump: gecode

2020-04-27 Thread Jerry James
The gecode package was updated from version 5.1.0 to version 6.2.0
yesterday.  The update came with an soname bump, which was not
announced on fedora-devel-list; see:

https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#_rawhide_devel_master

This broke the mp package, at least, which I will rebuild.
-- 
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


Re: RFC: Feature macros (aka USE flags)

2020-04-27 Thread Daniel Mach
I'm wondering if this is your personal initiative or if you're sync with 
ELN people. I emailed them in January about the very same idea (and I 
used the very same name; we both seem to like Gentoo), we exchanged 
couple emails, but never got an answer if this is the way to go. Since I 
have a lot of problems of my own (dnf, rpm, modularity), I did not want 
to start this as my personal initiative.


I'm really glad that someone's looking into this finally.
BTW, the new libdnf spec is using this approach already: 
https://github.com/rpm-software-management/libdnf/blob/dnf-5-devel/libdnf.spec


Since I'm part of RPM team too, I hope they won't mind if I'll speak for 
them :) Don't you rather want to work with us on extending the existing 
with/without macros? I'd prefer to improve the existing approach over 
creating something brand new. We could also reuse existing rpmbuild 
--with/--without arguments and ideally remain backwards compatible.


Besides this, +1 from me


Dne 27. 04. 20 v 13:19 Petr Šabata napsal(a):

Based on the recent discussions around %fedora/%rhel macros and ELN,
and %bcond generally being confusing to work with, I came up with a
distribution-wide feature that defines generic feature keywords and
associated helper macros that packages can check in build-time
conditionals.

The key advantage here is the defaults are defined by the buildroot,
not the package. The package is just a building block.

I'd like some input to improve this and unless this turns out to be a
really bad idea, I intend to submit it as a change proposal. Even
though the more packages use it the more beneficial it gets, it's, of
course, perfectly optional.

Details in the gist:
https://gist.github.com/contyk/0f0585c57976ca18a293b3566408

Cheers,
P

___
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: RFC: Feature macros (aka USE flags)

2020-04-27 Thread Daniel Mach
I'm wondering if this is your personal initiative or if you're sync with 
ELN people. I emailed them in January about the very same idea (and I 
used the very same name; we both seem to like Gentoo), we exchanged 
couple emails, but never got an answer if this is the way to go. Since I 
have a lot of problems of my own (dnf, rpm, modularity), I did not want 
to start this as my personal initiative.


I'm really glad that someone's looking into this finally.
BTW, the new libdnf spec is using this approach already: 
https://github.com/rpm-software-management/libdnf/blob/dnf-5-devel/libdnf.spec


Since I'm part of RPM team too, I hope they won't mind if I'll speak for 
them :) Don't you rather want to work with us on extending the existing 
with/without macros? I'd prefer to improve the existing approach over 
creating something brand new. We could also reuse existing rpmbuild 
--with/--without arguments and ideally remain backwards compatible.


Besides this, +1 from me


Dne 27. 04. 20 v 13:19 Petr Šabata napsal(a):

Based on the recent discussions around %fedora/%rhel macros and ELN,
and %bcond generally being confusing to work with, I came up with a
distribution-wide feature that defines generic feature keywords and
associated helper macros that packages can check in build-time
conditionals.

The key advantage here is the defaults are defined by the buildroot,
not the package. The package is just a building block.

I'd like some input to improve this and unless this turns out to be a
really bad idea, I intend to submit it as a change proposal. Even
though the more packages use it the more beneficial it gets, it's, of
course, perfectly optional.

Details in the gist:
https://gist.github.com/contyk/0f0585c57976ca18a293b3566408

Cheers,
P

___
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: RFC: Feature macros (aka USE flags)

2020-04-27 Thread Petr Šabata
On Mon, Apr 27, 2020 at 4:04 PM Petr Pisar  wrote:
>
> On Mon, Apr 27, 2020 at 01:19:29PM +0200, Petr Šabata wrote:
> > Details in the gist:
> > https://gist.github.com/contyk/0f0585c57976ca18a293b3566408
> >
> I'm very interested in overriding the global settings:
>
> (1) Is it possible to override them from a modulemd when building a module?
>
> I guess the asnswer is define %_with_ and %_without_ macros in
> a buildopts/rpms/macros section of the module. Could elaborate more
> the "Compatibility with RPM's --with & --without options" section?

Yes, you can, and that's exactly how you would do that.

Currently the macros as defined with bconds, in the basic form for
enabled by default:

%_with_foo %{bcond_without foo}%{with foo}

> Please note hat the RPM options and the macros have three states (true, false,
> undefined) and %_with_foo 0 does not turn %bcond_without foo into false.
> I don't ask about preserving a compatibility with this silly semantics, but
> some clarification will be needed if this proposal becomes approved.

It might not work if with/without is set with these macros directly as
it is written right now. I'll have to test that.

> (2) Is it possible to override them on a per-package basis?
>
> E.g. I have ncurses in global.yaml:
>
> - name: ncurses
>   description: Add support for ncurses.
>   enabled: true
>
> and I have plenty of packages that use the ncurses feature in my module. What
> should I write to my modulemd so that "ncurses" feature for "pcre" package is
> disabled, but all the other packages have it enabled? Or is it a completelly
> illed request to have the same feature enabled at one package and disabled on
> another one?

It is and that's actually how the local is implemented. It extends the
basic definitions with %{name} checks like this:

%_use_ncurses %{lua:
if rpm.expand("%{name}") == "yourpackage1"
  or rpm.expand("%{name}") == "yourpackage2" then
  print(rpm.expand("%{bcond_with foo}%{with foo}"))
else
  print(rpm.expand("%{bcond_without foo}%{with foo}"))
end
}

I know it's not very user friendly. Maybe there's a better way that
doesn't blow up on recursive macro definition.

P
___
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: RFC: Feature macros (aka USE flags)

2020-04-27 Thread Petr Šabata
On Mon, Apr 27, 2020 at 3:01 PM Vít Ondruch  wrote:
>
>
> Dne 27. 04. 20 v 13:19 Petr Šabata napsal(a):
> > Based on the recent discussions around %fedora/%rhel macros and ELN,
> > and %bcond generally being confusing to work with, I came up with a
> > distribution-wide feature that defines generic feature keywords and
> > associated helper macros that packages can check in build-time
> > conditionals.
>
>
> The most confusing part of the %bcond is the definition itself. The rest
> is fine IMO. Therefore, I somehow don't understand why would you like to
> replace:
>
>
> ```
>
> %if %{with ssl}
> BuildRequires:  openssl-devel
> %endif
>
> ```
>
>
> by
>
>
> ```
>
> %if %{use ssl}
> BuildRequires:  openssl-devel
> %endif
>
> ```

The difference here is %use defaults are defined by the buildroot
while %with %bconds are defined by the package.

> Also I don't understand, why there is exposed some underscore macro,
> such as `make test %{?_use_ssl:-DSSL}`. Shouldn't the underscore macro
> be just implementation detail? For `%bcond`s, the `_with` macros are
> discouraged, so why would you encourage them?

Yes, this should be an internal detail. I'd like to replace this with
%use_defined or something similar.

P
___
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: RFC: Feature macros (aka USE flags)

2020-04-27 Thread Petr Šabata
On Mon, Apr 27, 2020 at 3:42 PM Robin Lee  wrote:
>
> On Mon, Apr 27, 2020 at 7:21 PM Petr Šabata  wrote:
> >
> > Based on the recent discussions around %fedora/%rhel macros and ELN,
> > and %bcond generally being confusing to work with, I came up with a
> > distribution-wide feature that defines generic feature keywords and
> > associated helper macros that packages can check in build-time
> > conditionals.
> >
> > The key advantage here is the defaults are defined by the buildroot,
> > not the package. The package is just a building block.
> >
> > I'd like some input to improve this and unless this turns out to be a
> > really bad idea, I intend to submit it as a change proposal. Even
> > though the more packages use it the more beneficial it gets, it's, of
> > course, perfectly optional.
> >
> > Details in the gist:
> > https://gist.github.com/contyk/0f0585c57976ca18a293b3566408
> Should the use flags be automatically recorded in Provides of binary packages?
> Package A "Provides: A(+feature)"
> Then package B may 'Requires: A(+feature)"
>
> That semantics is implemented in Gentoo.

Yes, I think that's a good idea. I already have that in the Ideas
section of the gist, although with a more verbose format.
P
___
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: RFC: Feature macros (aka USE flags)

2020-04-27 Thread Petr Šabata
On Mon, Apr 27, 2020 at 2:15 PM Daniel P. Berrangé  wrote:
>
> On Mon, Apr 27, 2020 at 01:19:29PM +0200, Petr Šabata wrote:
> > Based on the recent discussions around %fedora/%rhel macros and ELN,
> > and %bcond generally being confusing to work with, I came up with a
> > distribution-wide feature that defines generic feature keywords and
> > associated helper macros that packages can check in build-time
> > conditionals.
> >
> > The key advantage here is the defaults are defined by the buildroot,
> > not the package. The package is just a building block.
>
> IMHO it is valuable having the package self-contained as it is
> today, as both maintainers & users are able to see and control
> exactly what features are intended, from a single place.
>
> With this proposal they'd have to read the global.yml and the
> local.$PKG.yml and the $PKG.spec file to figure out what is going
> to be built. Some features will need to vary per-architecture too,
> so this will need a global-$ARCH.yml  and a local-$ARCH.$PKG.yml file
> too for each Fedora arch, or the global.yml file will need to ship
> different content on each arch somehow. So that's potentially 3-5
> files that need to be consulted to figure out what the enabled
> features are for a given package build.

Yes, there is this additional complexity of changing it / looking at
two different places but that's the price paid for having the package
itself independent and the features set by the environment. These
approaches are not exclusive, people can use whichever method,
although I obviously prefer the latter. Hence this proposal.

You're correct about the architecture-specific needs. I wanted to keep
this simple and have people check for that in their packages. However,
that might be contradicting the point above. Architecture-specific
macros would solve this but be more complex to navigate and maintain.

> > I'd like some input to improve this and unless this turns out to be a
> > really bad idea, I intend to submit it as a change proposal. Even
> > though the more packages use it the more beneficial it gets, it's, of
> > course, perfectly optional.
>
> > Details in the gist:
> > https://gist.github.com/contyk/0f0585c57976ca18a293b3566408
>
> IIUC, the global.yml file is intended to live in the use-macros
> package. It wasn't clear though where the local-$PKG.yml file is
> intended to live ? Is it for the use-macros too, or in the
> per-package dist-git ?

Both global and local macros live in the use-macros package. The YAMLs
are sources and generate a single file with all the macros defined in
it. Again, there's nothing binding the distribution local YAMLs to the
packages themselves; they could be built in completely different
buildroots with different macros set from exactly the same commit.

> I'd be concerned about the per-package yml file living in "use-macros"
> because that would means when package maintainers need to rebase to a
> newer release, they potentially have to wait for any "use-macros" update
> to be approved & built before they can update their specfile in Fedora
> and do a build based on those features. This could also be an impact for
> users trying to build new upstream releases in Copr, if the features for
> the new upstream release ned to be different from those in the existing
> release for that Fedora release stream.

It's true this requires some coordination or uglier package checks
(assume the originally submitted default value if undefined and
simplify it later).

> On the point about trying to maintain compat for existing distros which
> lack %use macros. I think the example shown is not the route I would take.
>
> Instead I'd just define a %{with_XXX} macro for the feature upfront, based
> on the %{use XXX} macro value, and then not use the %use macros at all.
> In fact I might be inclined to do this even ignoring the old distro compat
> question, because it makes it easy to override the %{use} global defaults
> in the package.
>
> %define with_foo %{?use:%{use foo}}%{!?use:1}
>
> %if %{with_foo}
> BuildRequires:  foo-devel
>
> % define foo_configure_arg --with-foo
> % define foo_test_arg -Dfoo
> %endif
>
> %prep
> %configure %{?foo_configure_arg}
>
> %check
> make test %{?foo_test_arg}

You should also explicitly define --without-foo here. Sure, you could
do it this way if you think it's nicer.

> NB The "%{use_enable ...}"  macro is targetting autoconf syntax, but
> autotools is not the only build system. Should this aim for a
> consistent approach - either provide macros for all build systems,
> or for none.

I started with these two helpers because autotools are extremely
common and because the source of inspiration, Gentoo, also defines
these. I have nothing against defining more for other build systems.

P
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

Re: RFC: Feature macros (aka USE flags)

2020-04-27 Thread Petr Pisar
On Mon, Apr 27, 2020 at 01:19:29PM +0200, Petr Šabata wrote:
> Details in the gist:
> https://gist.github.com/contyk/0f0585c57976ca18a293b3566408
>
I'm very interested in overriding the global settings:

(1) Is it possible to override them from a modulemd when building a module?

I guess the asnswer is define %_with_ and %_without_ macros in
a buildopts/rpms/macros section of the module. Could elaborate more
the "Compatibility with RPM's --with & --without options" section?

Please note hat the RPM options and the macros have three states (true, false,
undefined) and %_with_foo 0 does not turn %bcond_without foo into false.
I don't ask about preserving a compatibility with this silly semantics, but
some clarification will be needed if this proposal becomes approved.

(2) Is it possible to override them on a per-package basis?

E.g. I have ncurses in global.yaml:

- name: ncurses
  description: Add support for ncurses.
  enabled: true

and I have plenty of packages that use the ncurses feature in my module. What
should I write to my modulemd so that "ncurses" feature for "pcre" package is
disabled, but all the other packages have it enabled? Or is it a completelly
illed request to have the same feature enabled at one package and disabled on
another one?

-- Petr


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: Macronize %pytest

2020-04-27 Thread Scott Talbert

On Mon, 27 Apr 2020, Miro Hrončok wrote:


Hello Python packagers,

since there is no upstream supported universal test invocation for Python 
(`python setup.py test` is deprecated and the de-facto-standard `tox` doesn't 
always do what we want in RPM's %check and/or is not always used by 
upstreams) and a lot of upstreams use pytest, I'd like to propose a %pytest 
macros, for standardizing the way pytest is run.


Usage:

 %check
 %pytest

Or with options passed to pyets:

 %check
 %pytest -v -m "not network" tests/


(Here ends the tl;dr version.)


Why not just use `pytest` or `%{python3} -m pytest` instead of `%pytest`?

We want to *test the code we ship*. In the general case this involves:

1. Prepending sys.path with %{buildroot}%{python3_sitelib} (and/or sitearch)
2. Prepending $PATH with %{buildroot}%{_bindir}
3. Ensuring $PWD is not in sys.path


So the idea is (untested):

%pytest_cmd /usr/bin/pytest

%pytest %{expand:
PYTHONPATH="${PYTHONPATH:-%{buildroot}%{python3_sitearch}:%{buildroot}%{python3_sitelib}}" 
\

PATH="%{buildroot}%{_bindir}:$PATH" \
%pytest_cmd
}


Where PYTHONPATH solves (1), PATH solves (2) and using `/usr/bin/pytest` over 
`%{python3} -m pytest` kinda solves (3).


I say "kinda" because using `python -m pytest` explicitly adds $PWD to 
sys.path, but using `pytest` doesn't always prevent it.


https://docs.pytest.org/en/latest/usage.html#calling-pytest-through-python-m-pytest

I've been trying to completely solve (3) in my head in a general way, but it 
always involves `cd`ing to a temporary directory before running the tests, 
but plenty of test suites cannot handle that gracefully.


Unfortunately Python interpreter doesn't have a flag that says "don't add 
current directory to sys.path, but respect $PYTHONPATH". In the long term, we 
might propose to add it.


I like the idea!

I have run into the issue of not wanting $PWD in sys.path before as well, 
so it would be great to solve that.


The only other thing that I might suggest is to 
set PYTHONDONTWRITEBYTECODE=1 so we don't get pytest bytecode written out.


Scott___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/python-devel@lists.fedoraproject.org


Re: RFC: Feature macros (aka USE flags)

2020-04-27 Thread Robin Lee
On Mon, Apr 27, 2020 at 7:21 PM Petr Šabata  wrote:
>
> Based on the recent discussions around %fedora/%rhel macros and ELN,
> and %bcond generally being confusing to work with, I came up with a
> distribution-wide feature that defines generic feature keywords and
> associated helper macros that packages can check in build-time
> conditionals.
>
> The key advantage here is the defaults are defined by the buildroot,
> not the package. The package is just a building block.
>
> I'd like some input to improve this and unless this turns out to be a
> really bad idea, I intend to submit it as a change proposal. Even
> though the more packages use it the more beneficial it gets, it's, of
> course, perfectly optional.
>
> Details in the gist:
> https://gist.github.com/contyk/0f0585c57976ca18a293b3566408
Should the use flags be automatically recorded in Provides of binary packages?
Package A "Provides: A(+feature)"
Then package B may 'Requires: A(+feature)"

That semantics is implemented in Gentoo.
>
> Cheers,
> P
> ___
> 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: coreos-assembler v0.8.0

2020-04-27 Thread Micah Abbott
On Sat, Apr 25, 2020 at 4:01 PM Michel Alexandre Salim
 wrote:
>
> On 4/25/20 6:50 AM, Micah Abbott wrote:
> > The CoreOS team is pleased to announce the latest release of
> > `coreos-assembler` - our opinionated build tool that we use to build
> > and test Fedora CoreOS and Red Hat CoreOS.
> >
> > https://github.com/coreos/coreos-assembler/releases/tag/v0.8.0
> >
> > The team created `coreos-assembler` as a way to bind together
> > Ignition, `rpm-ostree`, and many other Fedora RPMs to build, test, and
> > deliver Fedora CoreOS and Red Hat CoreOS artifacts.
> > `coreos-assembler` is delivered as a container image
> > (quay.io/coreos/coreos-assembler), ready to be run via "rootless"
> > `podman`, and provides an easy on-ramp for people and projects that
> > want a "custom" Fedora CoreOS style system.
> >
> > Check out the release notes via the tag above and come talk to us at
> > our usual places:
> >- #fedora-coreos on Freenode
> >- CoreOS category on the forums -
> > https://discussion.fedoraproject.org/c/server/coreos/5
> >
> Really nice! Would it make sense to anounce this in the forum too, so
> questions about this can go on a single thread?

Done!  - https://discussion.fedoraproject.org/t/coreos-assembler-v0-8-0/19199

> Also curious if Silverblue is using this too, or do they have differing
> needs.

The Silverblue project is not currently using `coreos-assembler`.
Colin Walters has been tinkering with building Silverblue based on
Fedora CoreOS, but it is still a work in progress -
https://github.com/cgwalters/fedora-silverblue-config

> Cheers,
>
> --
> Michel Alexandre Salim
> profile: https://keybase.io/michel_slm
> GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
> ___
> 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 rawhide compose report: 20200426.n.1 changes

2020-04-27 Thread Fedora Rawhide Report
OLD: Fedora-Rawhide-20200425.n.0
NEW: Fedora-Rawhide-20200426.n.1

= SUMMARY =
Added images:4
Dropped images:  0
Added packages:  4
Dropped packages:0
Upgraded packages:   83
Downgraded packages: 0

Size of added packages:  969.71 KiB
Size of dropped packages:0 B
Size of upgraded packages:   660.99 MiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Container_Minimal_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20200426.n.1.ppc64le.tar.xz
Image: Cloud_Base vmdk ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200426.n.1.ppc64le.vmdk
Image: Cloud_Base raw-xz ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200426.n.1.ppc64le.raw.xz
Image: Cloud_Base qcow2 ppc64le
Path: Cloud/ppc64le/images/Fedora-Cloud-Base-Rawhide-20200426.n.1.ppc64le.qcow2

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: boinc-tui-2.5.0-2.fc33
Summary: Fullscreen Text Mode Manager For BOINC Client
RPMs:boinc-tui
Size:732.88 KiB

Package: golang-github-adrianmo-nmea-1.1.0-1.20200425git15313ad.fc33
Summary: NMEA parser library
RPMs:golang-github-adrianmo-nmea-devel
Size:31.62 KiB

Package: golang-github-antchfx-jsonquery-1.1.2-1.fc33
Summary: Jsonq package for Go
RPMs:golang-github-antchfx-jsonquery-devel
Size:14.62 KiB

Package: python-pyone-5.10.4-1.fc33
Summary: Python Bindings for OpenNebula XML-RPC API
RPMs:python3-pyone
Size:190.60 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  accerciser-3.36.1-1.fc33
Old package:  accerciser-3.36.0-1.fc33
Summary:  Interactive Python accessibility explorer for the GNOME desktop
RPMs: accerciser
Size: 1.73 MiB
Size change:  427 B
Changelog:
  * Sat Apr 25 2020 Kalev Lember  - 3.36.1-1
  - Update to 3.36.1


Package:  akonadi-calendar-tools-20.04.0-1.fc33
Old package:  akonadi-calendar-tools-19.12.3-1.fc33
Summary:  Akonadi Calendar Tools
RPMs: akonadi-calendar-tools
Size: 1.23 MiB
Size change:  6.67 KiB
Changelog:
  * Fri Apr 24 2020 Rex Dieter  - 20.04.0-1
  - 20.04.0


Package:  akonadi-import-wizard-20.04.0-1.fc33
Old package:  akonadi-import-wizard-19.12.3-1.fc33
Summary:  Akonadi Import Wizard
RPMs: akonadi-import-wizard akonadi-import-wizard-devel
Size: 2.80 MiB
Size change:  15.16 KiB
Changelog:
  * Fri Apr 24 2020 Rex Dieter  - 20.04.0-1
  - 20.04.0


Package:  akonadiconsole-20.04.0-1.fc33
Old package:  akonadiconsole-19.12.3-1.fc33
Summary:  Akonadi developer tool
RPMs: akonadiconsole
Size: 1.61 MiB
Size change:  43.07 KiB
Changelog:
  * Fri Apr 24 2020 Rex Dieter  - 20.04.0-1
  - 20.04.0


Package:  akregator-20.04.0-1.fc33
Old package:  akregator-19.12.3-1.fc33
Summary:  Feed Reader
RPMs: akregator akregator-libs
Size: 8.23 MiB
Size change:  45.32 KiB
Changelog:
  * Fri Apr 24 2020 Rex Dieter  - 20.04.0-1
  - 20.04.0


Package:  antlr3-1:3.5.2-26.fc33
Old package:  antlr3-1:3.5.2-25.fc32
Summary:  ANother Tool for Language Recognition
RPMs: antlr3-C antlr3-C++-devel antlr3-C-devel antlr3-C-docs 
antlr3-java antlr3-javadoc antlr3-javascript antlr3-tool
Size: 59.77 MiB
Size change:  -14.72 KiB
Changelog:
  * Sat Apr 25 2020 Fabio Valentini  - 1:3.5.2-26
  - Remove unnecessary dependency on deprecated parent pom.


Package:  awscli-1.18.46-1.fc33
Old package:  awscli-1.18.45-1.fc33
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 1.72 MiB
Size change:  -28 B
Changelog:
  * Sat Apr 25 2020 Gwyn Ciesla  - 1.18.46-1
  - 1.18.46


Package:  borgmatic-1.5.2-1.fc33
Old package:  borgmatic-1.5.1-1.fc32
Summary:  Simple Python wrapper script for borgbackup
RPMs: borgmatic
Size: 124.49 KiB
Size change:  782 B
Changelog:
  * Sat Apr 25 2020 Felix Kaechele  - 1.5.2-1
  - update to 1.5.2


Package:  cdbs-0.4.162-1.fc33
Old package:  cdbs-0.4.161-1.fc33
Summary:  Common build system for Debian packages
RPMs: cdbs
Size: 58.29 KiB
Size change:  103 B
Changelog:
  * Sun Apr 26 2020 Sandro Mani  - 0.4.162-1
  - Update to 0.4.162


Package:  cpprest-2.10.16-1.fc33
Old package:  cpprest-2.10.15-1.fc33
Summary:  C++ REST library
RPMs: cpprest cpprest-devel
Size: 5.74 MiB
Size change:  51.55 KiB
Changelog:
  * Sat Apr 25 2020 Wolfgang St??ggl  - 2.10.16-1
  - New upstream version 2.10.16
  - Update patch: cpprest-2.10.16-disable-outside-and-failing-tests.patch
Disable new outside tests:
  redirect_tests:does_not_follow_https_to_http_by_default
  redirect_tests:can_follow_https_to_http
  - Remove ||: from tests again


Package:  cri-o-2:1.17.4-1.module_f33+8730+0fe02917
Old package:  cri-o-2:1.17.2-2.module_f33+8429+4e04c869
Summary:  Kubernetes 

Re: What CPU extensions can we assume are available by arch?

2020-04-27 Thread Kevin Kofler
Florian Weimer wrote:
> In general, that is not true.  You can use the target function attribute
> and function multiversioning instead in many cases.

This may (or may not) have been recently fixed, but last I checked, 
intrinsics for a vector instruction set XYZ2 were only available with the 
corresponding -mxyz2 flag, which could only be set per compilation unit 
(attempting to use the recently introduced flag pragmas for this purpose was 
not supported either), and which would lead to GCC in some cases (out of the 
library programmer's control) using XYZ2 instructions also in other 
functions. As a result, the only safe way was to put all XYZ2 code in a 
separate compilation unit compiled with -mxyz2 (and only that compilation 
unit can use that flag). Has that situation improved recently (and how so)?

And that is just for C or non-template C++ code. C++ template instantiations 
make the situation even messier.

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


[Bug 1828254] New: perl-AnyEvent-HTTP-2.25 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1828254

Bug ID: 1828254
   Summary: perl-AnyEvent-HTTP-2.25 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-AnyEvent-HTTP
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, emman...@seyman.fr,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.25
Current version/release in rawhide: 2.24-6.fc32
URL: http://search.cpan.org/dist/AnyEvent-HTTP/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


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


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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


Re: RFC: Feature macros (aka USE flags)

2020-04-27 Thread Vít Ondruch

Dne 27. 04. 20 v 13:19 Petr Šabata napsal(a):
> Based on the recent discussions around %fedora/%rhel macros and ELN,
> and %bcond generally being confusing to work with, I came up with a
> distribution-wide feature that defines generic feature keywords and
> associated helper macros that packages can check in build-time
> conditionals.


The most confusing part of the %bcond is the definition itself. The rest
is fine IMO. Therefore, I somehow don't understand why would you like to
replace:


```

%if %{with ssl}
BuildRequires:  openssl-devel
%endif

```


by


```

%if %{use ssl}
BuildRequires:  openssl-devel
%endif

```


Also I don't understand, why there is exposed some underscore macro,
such as `make test %{?_use_ssl:-DSSL}`. Shouldn't the underscore macro
be just implementation detail? For `%bcond`s, the `_with` macros are
discouraged, so why would you encourage them?


Vít


>
> The key advantage here is the defaults are defined by the buildroot,
> not the package. The package is just a building block.
>
> I'd like some input to improve this and unless this turns out to be a
> really bad idea, I intend to submit it as a change proposal. Even
> though the more packages use it the more beneficial it gets, it's, of
> course, perfectly optional.
>
> Details in the gist:
> https://gist.github.com/contyk/0f0585c57976ca18a293b3566408
>
> Cheers,
> P
> ___
> 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


tuxanci-0.21.0 license corrected to GPL+

2020-04-27 Thread Petr Pisar
When fixing a build failure of a tuxanci package I noticed a license tag is
not correct and changed it from "GPLv2" to "GPL+".

-- Petr


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: What CPU extensions can we assume are available by arch?

2020-04-27 Thread Richard Shaw
On Mon, Apr 27, 2020 at 7:26 AM Stephen Gallagher 
wrote:

> On Wed, Apr 22, 2020 at 10:52 AM Richard Shaw 
> wrote:
> > Could we treat them like arches?
> >  Something like:
> > X86_64 & X86_64-AVX2
> > armv7hf & armv7fh-NEON
> > etc...
> >
> > It would absolutely have to be OPT IN because once you enable it your
> system is no longer necessarily portable to other hardware.
> >
>
> FYI, you just described a major component of the ELN Compose we are
> working on for Fedora 33:
> https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose


I had been following the "lengthy" discussions on the list, but I thought
it was just targeting rawhide for some reason. That may work in the future,
so perhaps a less-than-ideal hack would work in the meantime.

Thanks,
Richard
___
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: What CPU extensions can we assume are available by arch?

2020-04-27 Thread Florian Weimer
* Kevin Kofler:

> Jun Aruga wrote:
>> simde is a header files only library. It's not a binary.
>
> Then it is inherently unsuitable for automatic runtime selection, and
> all the runtime selection still has to be done in the client program.
>
> GCC requires you to compile for separate vector instruction sets in
> separate compilation units. A header-only library cannot possibly do
> that for you.

In general, that is not true.  You can use the target function attribute
and function multiversioning instead in many cases.

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


Schedule for Mondays's FESCo Meeting (2020-04-27)

2020-04-27 Thread Aleksandra Fedorova
Following is the list of topics that will be discussed in the
FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.

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

or run:
  date -d '2020-04-27 15:00 UTC'

Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

Update libgit2 from 0.99.0 to 1.0.0 in F32 (post-release)
https://pagure.io/fesco/issue/2377
APPROVED (+3, 0, -0)

F33 System-Wide Change: Perl 5.32
https://pagure.io/fesco/issue/2376
APPROVED  (+6, 0, -0)

Remove appstream-data from automatic blockers
https://pagure.io/fesco/issue/2374
APPROVED  (+7, 0, -0)

F33 System-Wide Change: OpenSSL3.0
https://pagure.io/fesco/issue/2373
APPROVED (+7, 0, -0)


= Followups =

#topic #2372 F33 Self-contained Change: Network Time Security
https://pagure.io/fesco/issue/2372

= New business =

#topic #2382 systemd default service exception for rpmdb-rebuild service
https://pagure.io/fesco/issue/2382

#topic #2371 F33 System-Wide Change: Removal of the glibc-headers package
https://pagure.io/fesco/issue/2371

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.

-- 
Aleksandra Fedorova
bookwar
___
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: What CPU extensions can we assume are available by arch?

2020-04-27 Thread Stephen Gallagher
On Wed, Apr 22, 2020 at 10:52 AM Richard Shaw  wrote:
>
> On Wed, Apr 22, 2020 at 9:28 AM Artur Iwicki  wrote:
>>
>> Regarding x86_64 and AVX2, last year we had a very heated discussion about 
>> this on the mailing list.
>>
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/MPFXH4Y5LDC5L2VXWKUHAX3WAKBQXR4U/#MPFXH4Y5LDC5L2VXWKUHAX3WAKBQXR4U
>>
>> tl;dr: there was a proposal to make "x86_64" in Fedora mean "must support at 
>> least AVX2" and it met with a lot of backlash.
>
>
> Now that you mention it that does tickle some brain cells...
>
> So it seems what's really needed is a method to support software with 
> optimizations above the baseline without leaving other people behind.
>
> The only way I can think of to do that that would be to have optional 
> "enhanced" repos available that people can enable if their system supports 
> it. The hard part would be keeping it in sync with the main repo. It would 
> have to be a parallel build process and similar to the current process if one 
> fails the build is a NOGO across the board.
>
> Could we treat them like arches?
>  Something like:
> X86_64 & X86_64-AVX2
> armv7hf & armv7fh-NEON
> etc...
>
> It would absolutely have to be OPT IN because once you enable it your system 
> is no longer necessarily portable to other hardware.
>

FYI, you just described a major component of the ELN Compose we are
working on for Fedora 33:
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
___
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 packages looking for new maintainers (anaconda also affected)

2020-04-27 Thread Miro Hrončok

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2020-04-27.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers   Status Change

CPUFreqUtilityorphan   2 weeks ago
GConf2alexl, caillon, caolanm, 2 weeks ago
  gnome-sig, johnp, mbarnes,
  orphan, rhughes, ssp, walters
GREYCstorationorphan   2 weeks ago
abcm2ps   orphan   2 weeks ago
adapta-gtk-theme  orphan   2 weeks ago
antlr4gil, jkastner, lef, mizdebsk,2 weeks ago
  orphan
apache-commons-dbutilsmizdebsk, orphan 2 weeks ago
apache-commons-email  mizdebsk, orphan 2 weeks ago
apache-commons-jcijjelen, orphan   2 weeks ago
apache-commons-jcscquad, jjelen, orphan4 weeks ago
apanov-edrip-fontsfrixxon, orphan  2 weeks ago
apbs  orphan, rathann  2 weeks ago
artha orphan   2 weeks ago
avalon-framework  jerboaa, jjelen, mizdebsk,   4 weeks ago
  orphan
avr-gdb   giallu, orphan, trondd   2 weeks ago
biboumi   orphan   4 weeks ago
bmake orphan   0 weeks ago
bval  jjelen, orphan   2 weeks ago
bygfoot   orphan   2 weeks ago
cassandra-java-driver hhorak, jjanco, orphan   2 weeks ago
castorlef, orphan  2 weeks ago
catimgorphan   2 weeks ago
cdpr  orphan   2 weeks ago
ckermit   orphan   2 weeks ago
cmyktool  orphan   2 weeks ago
cog   orphan   2 weeks ago
containersorphan   5 weeks ago
coriander dajt, orphan 2 weeks ago
dateshift orphan   2 weeks ago
dibbler   orphan   2 weeks ago
docco nodejs-sig, orphan, patches  2 weeks ago
drbd  orphan   2 weeks ago
driftnet  orphan, pwouters 1 weeks ago
dsi   orphan   2 weeks ago
echoping  orphan   2 weeks ago
eclipse-avr   orphan   2 weeks ago
eclipse-egit-github   eclipse-sig, orphan  2 weeks ago
eclipse-m2e-core  eclipse-sig, galileo,2 weeks ago
  mizdebsk, orphan
eclipse-mylyn arobinso, eclipse-sig,   2 weeks ago
  jjohnstn, kdaniel, orphan,
  rgrunber
eclipse-photran   akurtakov, eclipse-sig, orphan   2 weeks ago
eclipse-ptp   eclipse-sig, jjohnstn,   2 weeks ago
  kdaniel, orphan
eclipse-remoteeclipse-sig, orphan  2 weeks ago
eclipse-subclipse eclipse-sig, kdaniel, orphan 2 weeks ago
eclipse-testngeclipse-sig, orphan  2 weeks ago
eclipse-webtools  eclipse-sig, galileo, orphan 2 weeks ago
emacs-mmm  

Re: RFC: Feature macros (aka USE flags)

2020-04-27 Thread Daniel P . Berrangé
On Mon, Apr 27, 2020 at 01:19:29PM +0200, Petr Šabata wrote:
> Based on the recent discussions around %fedora/%rhel macros and ELN,
> and %bcond generally being confusing to work with, I came up with a
> distribution-wide feature that defines generic feature keywords and
> associated helper macros that packages can check in build-time
> conditionals.
> 
> The key advantage here is the defaults are defined by the buildroot,
> not the package. The package is just a building block.

IMHO it is valuable having the package self-contained as it is
today, as both maintainers & users are able to see and control
exactly what features are intended, from a single place.

With this proposal they'd have to read the global.yml and the
local.$PKG.yml and the $PKG.spec file to figure out what is going
to be built. Some features will need to vary per-architecture too,
so this will need a global-$ARCH.yml  and a local-$ARCH.$PKG.yml file
too for each Fedora arch, or the global.yml file will need to ship
different content on each arch somehow. So that's potentially 3-5
files that need to be consulted to figure out what the enabled
features are for a given package build.

> I'd like some input to improve this and unless this turns out to be a
> really bad idea, I intend to submit it as a change proposal. Even
> though the more packages use it the more beneficial it gets, it's, of
> course, perfectly optional.

> Details in the gist:
> https://gist.github.com/contyk/0f0585c57976ca18a293b3566408

IIUC, the global.yml file is intended to live in the use-macros
package. It wasn't clear though where the local-$PKG.yml file is
intended to live ? Is it for the use-macros too, or in the
per-package dist-git ?

I'd be concerned about the per-package yml file living in "use-macros"
because that would means when package maintainers need to rebase to a
newer release, they potentially have to wait for any "use-macros" update
to be approved & built before they can update their specfile in Fedora
and do a build based on those features. This could also be an impact for
users trying to build new upstream releases in Copr, if the features for
the new upstream release ned to be different from those in the existing
release for that Fedora release stream.

On the point about trying to maintain compat for existing distros which
lack %use macros. I think the example shown is not the route I would take.

Instead I'd just define a %{with_XXX} macro for the feature upfront, based
on the %{use XXX} macro value, and then not use the %use macros at all.
In fact I might be inclined to do this even ignoring the old distro compat
question, because it makes it easy to override the %{use} global defaults
in the package.

%define with_foo %{?use:%{use foo}}%{!?use:1}

%if %{with_foo}
BuildRequires:  foo-devel

% define foo_configure_arg --with-foo
% define foo_test_arg -Dfoo
%endif

%prep
%configure %{?foo_configure_arg}

%check
make test %{?foo_test_arg}


NB The "%{use_enable ...}"  macro is targetting autoconf syntax, but
autotools is not the only build system. Should this aim for a
consistent approach - either provide macros for all build systems,
or for none. 

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
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


[Bug 1828234] perl-Date-Holidays-DE-2.05 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1828234



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Date-Holidays-DE-2.05-1.fc30.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=43855102


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


[Bug 1828235] New: perl-Devel-PatchPerl-1.92 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1828235

Bug ID: 1828235
   Summary: perl-Devel-PatchPerl-1.92 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Devel-PatchPerl
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.92
Current version/release in rawhide: 1.90-1.fc33
URL: http://search.cpan.org/dist/Devel-PatchPerl/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


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


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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


[Bug 1828234] perl-Date-Holidays-DE-2.05 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1828234



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1682143
  --> https://bugzilla.redhat.com/attachment.cgi?id=1682143=edit
[patch] Update to 2.05 (#1828234)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


[Bug 1828234] New: perl-Date-Holidays-DE-2.05 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1828234

Bug ID: 1828234
   Summary: perl-Date-Holidays-DE-2.05 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Date-Holidays-DE
  Keywords: FutureFeature, Triaged
  Assignee: redhat-bugzi...@linuxnetz.de
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
redhat-bugzi...@linuxnetz.de
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.05
Current version/release in rawhide: 2.03-2.fc32
URL: http://search.cpan.org/dist/Date-Holidays-DE/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


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


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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


Re: RFC: Feature macros (aka USE flags)

2020-04-27 Thread Petr Šabata
On Mon, Apr 27, 2020 at 1:24 PM Neal Gompa  wrote:
>
> On Mon, Apr 27, 2020 at 7:21 AM Petr Šabata  wrote:
> >
> > Based on the recent discussions around %fedora/%rhel macros and ELN,
> > and %bcond generally being confusing to work with, I came up with a
> > distribution-wide feature that defines generic feature keywords and
> > associated helper macros that packages can check in build-time
> > conditionals.
> >
> > The key advantage here is the defaults are defined by the buildroot,
> > not the package. The package is just a building block.
> >
> > I'd like some input to improve this and unless this turns out to be a
> > really bad idea, I intend to submit it as a change proposal. Even
> > though the more packages use it the more beneficial it gets, it's, of
> > course, perfectly optional.
> >
> > Details in the gist:
> > https://gist.github.com/contyk/0f0585c57976ca18a293b3566408
> >
>
> This looks pretty good! Have you considered submitting it into
> upstream RPM so that we don't wind up having so many catch-22s with
> its usability, though?

That would be an option, even though it would have to work somehow
differently, I presume.

P
___
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: What CPU extensions can we assume are available by arch?

2020-04-27 Thread Jun Aruga
> > For the better user experience, we are promoting the system library
> > for both RPM and Debian based Linux distributions.
>
> What system library, for what purpose?

Hi Dave,
The simde system library is

* simde-devel in Fedora and EPEL [1]
* libsimde-dev in Debian [2]

The purpose is to build and ship SIMD implemented software RPM such as
bowite2 [3] and minimap2 [4] on non-x86_64 CPU architecture such as
aarch64, ppc64le and s390x.

[1] https://src.fedoraproject.org/rpms/simde/
[2] https://wiki.debian.org/SIMDEverywhere
[3] 
https://raw.githubusercontent.com/junaruga/fedora-bowtie2/master/bowtie2.spec
 In review status on https://bugzilla.redhat.com/show_bug.cgi?id=1824348 .
[4] https://github.com/lh3/minimap2

-- 
Jun | He - His - Him
___
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: RFC: Feature macros (aka USE flags)

2020-04-27 Thread Neal Gompa
On Mon, Apr 27, 2020 at 7:21 AM Petr Šabata  wrote:
>
> Based on the recent discussions around %fedora/%rhel macros and ELN,
> and %bcond generally being confusing to work with, I came up with a
> distribution-wide feature that defines generic feature keywords and
> associated helper macros that packages can check in build-time
> conditionals.
>
> The key advantage here is the defaults are defined by the buildroot,
> not the package. The package is just a building block.
>
> I'd like some input to improve this and unless this turns out to be a
> really bad idea, I intend to submit it as a change proposal. Even
> though the more packages use it the more beneficial it gets, it's, of
> course, perfectly optional.
>
> Details in the gist:
> https://gist.github.com/contyk/0f0585c57976ca18a293b3566408
>

This looks pretty good! Have you considered submitting it into
upstream RPM so that we don't wind up having so many catch-22s with
its usability, though?



--
真実はいつも一つ!/ 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


RFC: Feature macros (aka USE flags)

2020-04-27 Thread Petr Šabata
Based on the recent discussions around %fedora/%rhel macros and ELN,
and %bcond generally being confusing to work with, I came up with a
distribution-wide feature that defines generic feature keywords and
associated helper macros that packages can check in build-time
conditionals.

The key advantage here is the defaults are defined by the buildroot,
not the package. The package is just a building block.

I'd like some input to improve this and unless this turns out to be a
really bad idea, I intend to submit it as a change proposal. Even
though the more packages use it the more beneficial it gets, it's, of
course, perfectly optional.

Details in the gist:
https://gist.github.com/contyk/0f0585c57976ca18a293b3566408

Cheers,
P
___
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


[Bug 1827253] perl-Date-Manip 6.81 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1827253



--- Comment #2 from Fedora Update System  ---
FEDORA-2020-465ccdced6 has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-465ccdced6


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


[Bug 1827253] perl-Date-Manip 6.81 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1827253

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2020-1ad0f1e703 has been submitted as an update to Fedora 32.
https://bodhi.fedoraproject.org/updates/FEDORA-2020-1ad0f1e703


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


Re: What CPU extensions can we assume are available by arch?

2020-04-27 Thread Dave Love
Jun Aruga  writes:

> For the better user experience, we are promoting the system library
> for both RPM and Debian based Linux distributions.

What system library, for what purpose?
___
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: What CPU extensions can we assume are available by arch?

2020-04-27 Thread Dave Love
Jun Aruga  writes:

> You do not need to care about the availability by arch or compiler
> when using this library.

As far as I can tell, it doesn't do dynamic dispatch.  Experimentally,
if you build with -mavx2 and run on ivybridge (or for skx and run on
haswell), the test code generates illegal instruction errors.  It's some
time ago since I looked at it, and I don't remember, but that's probably
why I thought it wasn't very useful, apart from only having x86 and arm
support.

Note also that there's typically rather more than SIMD to consider for
different micro-architectures, particularly fitting the memory
hierarchy.
___
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 election schedule update

2020-04-27 Thread Miro Hrončok

On 23. 04. 20 22:30, Ben Cotton wrote:

Haha, I tried to plan! Due to a change in the infrastructure move
timeline, the Elections app will now be available during the
originally-scheduled time. Instead of delaying the elections further,
we will just pretend I never made any changes and hold to the original
timeline:
https://communityblog.fedoraproject.org/fedora-32-election-schedule-again/


Whenever I try to see the actual schedule, I end up in 
https://docs.fedoraproject.org/en-US/program_management/elections/


But that one has not been updated since last elections.

I now there is 
https://fedorapeople.org/groups/schedule/f-32/f-32-elections-tasks.html but I 
find it very hard to google.


(The same applies to Fedora 33 release schedule, which is not on the wiki.)

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


[Bug 1826569] perl-Net-GitHub-1.01 is available

2020-04-27 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1826569

Jan Pazdziora  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
   Doc Type|--- |If docs needed, set a value



--- Comment #2 from Jan Pazdziora  ---
Built perl-Net-GitHub-1.01-1.fc33, errata
https://bodhi.fedoraproject.org/updates/FEDORA-2020-849e3ca909 was autofiled..


-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/perl-devel@lists.fedoraproject.org


Orphaned packages looking for new maintainers (anaconda also affected)

2020-04-27 Thread Miro Hrončok

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://churchyard.fedorapeople.org/orphans-2020-04-27.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers   Status Change

CPUFreqUtilityorphan   2 weeks ago
GConf2alexl, caillon, caolanm, 2 weeks ago
  gnome-sig, johnp, mbarnes,
  orphan, rhughes, ssp, walters
GREYCstorationorphan   2 weeks ago
abcm2ps   orphan   2 weeks ago
adapta-gtk-theme  orphan   2 weeks ago
antlr4gil, jkastner, lef, mizdebsk,2 weeks ago
  orphan
apache-commons-dbutilsmizdebsk, orphan 2 weeks ago
apache-commons-email  mizdebsk, orphan 2 weeks ago
apache-commons-jcijjelen, orphan   2 weeks ago
apache-commons-jcscquad, jjelen, orphan4 weeks ago
apanov-edrip-fontsfrixxon, orphan  2 weeks ago
apbs  orphan, rathann  2 weeks ago
artha orphan   2 weeks ago
avalon-framework  jerboaa, jjelen, mizdebsk,   4 weeks ago
  orphan
avr-gdb   giallu, orphan, trondd   2 weeks ago
biboumi   orphan   4 weeks ago
bmake orphan   0 weeks ago
bval  jjelen, orphan   2 weeks ago
bygfoot   orphan   2 weeks ago
cassandra-java-driver hhorak, jjanco, orphan   2 weeks ago
castorlef, orphan  2 weeks ago
catimgorphan   2 weeks ago
cdpr  orphan   2 weeks ago
ckermit   orphan   2 weeks ago
cmyktool  orphan   2 weeks ago
cog   orphan   2 weeks ago
containersorphan   5 weeks ago
coriander dajt, orphan 2 weeks ago
dateshift orphan   2 weeks ago
dibbler   orphan   2 weeks ago
docco nodejs-sig, orphan, patches  2 weeks ago
drbd  orphan   2 weeks ago
driftnet  orphan, pwouters 1 weeks ago
dsi   orphan   2 weeks ago
echoping  orphan   2 weeks ago
eclipse-avr   orphan   2 weeks ago
eclipse-egit-github   eclipse-sig, orphan  2 weeks ago
eclipse-m2e-core  eclipse-sig, galileo,2 weeks ago
  mizdebsk, orphan
eclipse-mylyn arobinso, eclipse-sig,   2 weeks ago
  jjohnstn, kdaniel, orphan,
  rgrunber
eclipse-photran   akurtakov, eclipse-sig, orphan   2 weeks ago
eclipse-ptp   eclipse-sig, jjohnstn,   2 weeks ago
  kdaniel, orphan
eclipse-remoteeclipse-sig, orphan  2 weeks ago
eclipse-subclipse eclipse-sig, kdaniel, orphan 2 weeks ago
eclipse-testngeclipse-sig, orphan  2 weeks ago
eclipse-webtools  eclipse-sig, galileo, orphan 2 weeks ago
emacs-mmm  

Fedora-Cloud-32-20200427.0 compose check report

2020-04-27 Thread Fedora compose checker
No missing expected images.

Soft failed openQA tests: 1/1 (x86_64)
(Tests completed, but using a workaround for a known bug)

ID: 587599  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/587599
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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: What CPU extensions can we assume are available by arch?

2020-04-27 Thread Kevin Kofler
Jun Aruga wrote:
> simde is a header files only library. It's not a binary.

Then it is inherently unsuitable for automatic runtime selection, and all 
the runtime selection still has to be done in the client program.

GCC requires you to compile for separate vector instruction sets in separate 
compilation units. A header-only library cannot possibly do that for you.

(This is an issue for all header-only vectorization libraries, e.g., Eigen.)

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


Re: What CPU extensions can we assume are available by arch?

2020-04-27 Thread Kevin Kofler
Richard Shaw wrote:
> It's funny we just had this conversation yesterday, I woke up to a pull
> request to add SSE support.
> 
> https://github.com/drowe67/LPCNet/pull/25

Unfortunately, that requires SSE4.1, which is still too much to assume.

Looking at the comments, the author actually tried SSE2, but it was too slow 
for real-time operation on his machines. Though really fast CPUs (such as 
your Ryzen 5 2600) can actually even run the unoptimized C in real time, but 
those are normally modern ones that also support the AVX and even AVX2 
optimizations (yours does), so it does not help us that much either.

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


Macronize %pytest

2020-04-27 Thread Miro Hrončok

Hello Python packagers,

since there is no upstream supported universal test invocation for Python 
(`python setup.py test` is deprecated and the de-facto-standard `tox` doesn't 
always do what we want in RPM's %check and/or is not always used by upstreams) 
and a lot of upstreams use pytest, I'd like to propose a %pytest macros, for 
standardizing the way pytest is run.


Usage:

  %check
  %pytest

Or with options passed to pyets:

  %check
  %pytest -v -m "not network" tests/


(Here ends the tl;dr version.)


Why not just use `pytest` or `%{python3} -m pytest` instead of `%pytest`?

We want to *test the code we ship*. In the general case this involves:

 1. Prepending sys.path with %{buildroot}%{python3_sitelib} (and/or sitearch)
 2. Prepending $PATH with %{buildroot}%{_bindir}
 3. Ensuring $PWD is not in sys.path


So the idea is (untested):

%pytest_cmd /usr/bin/pytest

%pytest %{expand:
PYTHONPATH="${PYTHONPATH:-%{buildroot}%{python3_sitearch}:%{buildroot}%{python3_sitelib}}" 
\

PATH="%{buildroot}%{_bindir}:$PATH" \
%pytest_cmd
}


Where PYTHONPATH solves (1), PATH solves (2) and using `/usr/bin/pytest` over 
`%{python3} -m pytest` kinda solves (3).


I say "kinda" because using `python -m pytest` explicitly adds $PWD to sys.path, 
but using `pytest` doesn't always prevent it.


https://docs.pytest.org/en/latest/usage.html#calling-pytest-through-python-m-pytest

I've been trying to completely solve (3) in my head in a general way, but it 
always involves `cd`ing to a temporary directory before running the tests, but 
plenty of test suites cannot handle that gracefully.


Unfortunately Python interpreter doesn't have a flag that says "don't add 
current directory to sys.path, but respect $PYTHONPATH". In the long term, we 
might propose to add it.




Where to have the macro defined? (Skip this part if not interested.)

I was thinking:

 a) pytest package
 b) pytest subpackage (required if rpm-build)
 c) python3-rpm-macros
 d) python-rpm-macros
 e) pyproject-rpm-macros

And here is the pros and cons:

a+) self contained, can change with upstream if needed
a+) always present with pytest
a-) pytest must co-own macro dir or depend on rpm-build


b+) same as a+, but not a-
b-) additional layer of complexity

c+) easy
c+) the macro doesn't need to require pytest, can be used with arbitrary command
c+) can be generalized to non-pytest later if desired
c-) when pytest CLI changes significantly, we need to change it in different 
package (but we are not using pytets CLI now at all, just Python/Shell 
environment variables)
c~) technically not always present with pytest, but always present with 
python3-devel


d+-) same as (c)
d-) the macro uses python3 specific things

e+) the new fancy macros are there
e-) the other macros from there (actually pyproject related) are not required 
for this

e-) not always present with pytest nor python3-devel


Hence, I'd go with (c) python3-rpm-macros.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
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/python-devel@lists.fedoraproject.org


timing window Rawhide tests and f32 release

2020-04-27 Thread Normand

Hello Adam,

seem there is a timing window problem between Rawhide tests and f32 
release as per failure https://openqa.fedoraproject.org/tests/587422

===
Cannot find HDD_1 asset hdd/disk_f32_support_5_x86_64.img!
===
failed Fedora-Rawhide-20200426.n.1  about an hour ago ( 0 )
failed Fedora-Rawhide-20200425.n.0  2 days ago ( 0 )
passed Fedora-Rawhide-20200423.n.0  4 days ago ( 02:00 minutes )
===

There is not yet a f32 in 
https://fr2.rpmfind.net/linux/fedora/linux/releases/

===
[DIR]   30/ 2019-04-26 22:58-   
[DIR]   31/ 2019-10-25 17:05-   
[DIR]   test/   2020-03-13 21:00-   
===


I experienced similar problem trying createhdds for ppc64le

--
Michel Normand
___
qa-devel mailing list -- qa-devel@lists.fedoraproject.org
To unsubscribe send an email to qa-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/qa-devel@lists.fedoraproject.org


[389-devel] Re: Github / Gitter (Chat service)

2020-04-27 Thread Matus Honek
On Sat, Apr 25, 2020 at 7:57 AM William Brown  wrote:
>
> Hi all,
>
> In the past I have previously "name squatted" 389ds on github, which has 
> meant that I'm able to reserve 389ds on gitter - gitter is a web based chat, 
> similar to irc, but "cool" with all the kids these days (which really, I 
> shouldn't throw shade, I'm a kid still ...)
>
> Anyway, I have setup a channel here:
>
> https://gitter.im/389ds/community
>
> It could be useful to us, and I'm wondering if it's something we would want 
> to adopt more over IRC?
>
> Thoughts?

I was a bit sceptical (another RAM/CPU eater tab) but found out it has
an IRC bridge (https://irc.gitter.im/) and also you can set up email
notifications. But first, I think we should set up a live sync to
https://github.com/389ds/389-ds-base repo since it is confusing to
find an empty repo on the official github 389ds account.

>
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> SUSE Labs
> ___
> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
> To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org



-- 
Matúš Honěk
Software Engineer
Red Hat Czech
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-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/389-devel@lists.fedoraproject.org


Re: CMake3-3.17.1 on EPEL7

2020-04-27 Thread Jun Aruga
Thanks for maintaining it. I did not know we can use CMake 3 with
cmake3 RPM on EPEL7.

Jun

-- 
Jun | He - His - Him
___
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


CMake3-3.17.1 on EPEL7

2020-04-27 Thread Antonio Trande
Hi all.

`CMake3` on EPEL7 has been updated to the release 3.17.1; it's available
for testing.

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b6a455afdf

-- 
---
Antonio Trande
Fedora Project
mailto 'sagitter at fedoraproject dot org'
GPG key: 0x7B30EE04E576AA84
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


[EPEL-devel] CMake3-3.17.1 on EPEL7

2020-04-27 Thread Antonio Trande
Hi all.

`CMake3` on EPEL7 has been updated to the release 3.17.1; it's available
for testing.

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-b6a455afdf

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



signature.asc
Description: OpenPGP digital signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://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/epel-devel@lists.fedoraproject.org


Fedora-Cloud-31-20200427.0 compose check report

2020-04-27 Thread Fedora compose checker
No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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: CPE Weekly: 2020-04-26

2020-04-27 Thread Pierre-Yves Chibon
On Mon, Apr 27, 2020 at 12:58:52AM +0200, Miro Hrončok wrote:
> On 26. 04. 20 20:12, Pierre-Yves Chibon wrote:
> >   We know some people are happy with it and at least one person is not
> 
> I hope you are not counting me as the not happy person.

No, I actually included you in the first group :)
 
> I am quite happy, but I just find that one tiny problem a blocker for me :D
> 
> https://pagure.io/Fedora-Infra/rpmautospec/issue/107

I realize it's annoying to you in the current state of rpmautospec but Nils,
Adam and I already chat a bit about this and we believe we can fix the situation
so it's no longer a blocker.
If the community deems our approach worthy of being pushed forward, we will
ensure you get to use this !


Thanks for your feedback and support on this!

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


Fedora-Cloud-30-20200427.0 compose check report

2020-04-27 Thread Fedora compose checker
No missing expected images.

Passed openQA tests: 1/1 (x86_64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
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: Orphaned rubygem-ruby_parser and rubygem-gettext_i18n_rails

2020-04-27 Thread Vít Ondruch
Actually, I have orphaned also rubygem-gettext_i18n_rails, which is
required only by rubygem-activeldap.


Vít


Dne 27. 04. 20 v 9:40 Vít Ondruch napsal(a):
> Hi,
>
> Since I have orphaned rubygem-ruby2ruby, I don't have any other use for
> rubygem-ruby_parser. While it is in dependency chain of
> rubygem-activeldap and rubygem-gettext_i18n_rails, I have not heard back
> from rubygem-activeldap maintainer, therefore I orphaned the package.
>
>
> Vít
>
>
___
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


  1   2   >