Fedora-Cloud-33-20210616.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Old soft failures (same test soft failed in Fedora-Cloud-33-20210615.0):

ID: 909322  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/909322
ID: 909329  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/909329

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Introduction: Trevor McKay

[Felix Schwarz]

Am 16.06.21 um 05:12 schrieb Trevor McKay:

My name is Trevor and I was hoping to contribute to the Fedora project
in the form of packaging.


Welcome!


introduce myself here. I have a few years of Linux experience as well as
Rust, Python and C/C++ development. I am, however, completely new to
packaging and contributing to open-source, so any advice is very much
welcome.


I think Fedora has pretty nice Python packaging and I think rust skills are also 
a welcome addition as there is a growing number of rust software in the open 
source ecosystem.


You can check out the SIG pages for Rust+Python. There are separate mailing 
lists for these SIGs (though fedora-devel works as well):


https://fedoraproject.org/wiki/SIGs/Python
https://fedoraproject.org/wiki/SIGs/Rust


I am interested in packing `bottom`, a package for system monitoring
that I find fairly useful.


There is a Fedora package by "atim" (real name AFAIK "Artem Polishchuk", 
ego.corda...@gmail.com) in COPR:


https://copr.fedorainfracloud.org/coprs/atim/bottom/

Probably there is a reason why this is not yet in Fedora (missing dependencies? 
licensing?) so you could ask him and maybe help getting this into Fedora.


Sometimes you need to spend a lot of effort to get upstream's build system in 
line with Fedora's policies (no network access during build, so all dependencies 
must be packaged inside Fedora) but together we can create a really nice 
platform which can be used for stuff nobody envisioned at the beginning.
(For example I'm using Fedora's mingw packaging to cross-compile a commercial 
application for Windows and I spent several days before discovering Fedora's 
packages. Also more time with Linux instead of fighting Visual Studio => sanity++)


Anyway: If you have any questions, just ask. (And if you are not comfortable 
asking publicly, just contact me privately. Not much time here but I'm happy to 
help new Fedora contributors.)


Felix
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

[Alfredo Moralejo Alonso]

On Tue, Jun 15, 2021 at 7:41 PM Miro Hrončok  wrote:

> On 15. 06. 21 19:34, Ewoud Kohl van Wijngaarden wrote:
> > And for those of us who also maintain packages for EL7/8, what's the
> > availability of these macros?
>
> Whenever technically possible, we add our new Python macros to EPEL 7+.
> Sometimes, we even backport them to plain RHEL 8+.
>
> This can (and will) be done for the proposed "import test" macro.
>
>
I can assume the new import test macro will be included in Centos stream 9
macros, right?


> However, the pyproject RPM macros use RPM features not yet available in
> RHEL 8,
> so we won't be adding those.
>
> --
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Daniel P . Berrangé]

On Tue, Jun 15, 2021 at 05:34:02PM -0400, Neal Gompa wrote:
> Hey all,
> 
> Earlier this week, I was helping with processing features for openSUSE
> Leap 15.4[1] and I discovered that they're planning on introducing
> x86_64-v2 to openSUSE soon. The reference for this change was that
> RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions
> have been considering bumping up to v2 or v3[3][4].
> 
> Some cursory examination of the new x86_64 sublevels seem to indicate
> that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the
> first couple of generations of x86_64 CPUs from Intel and AMD. I
> personally don't have any computers that don't have support for
> x86_64-v2 anymore.

Yes, you loose primarily Intel Conroe and Penryn generations and
AMD Opteron Gen 1 -> Gen 3. I doubt this is a significant portion
of Fedora installs.

Slight tangent but I find Fedora's approach to hardware somewhat
at odds with our approach to software.

On the one hand we portray our project as a place for cutting
edge Linux software & innovation.

On the other hand we hold back our software by trying to keep
supporting long obsolete hardware.

There is of course always a balance between bumping min hardware
specs and the impact on maintainers & users, but I'm not convinced
that we have the balance right in targeting our x86_64 baseline at
the very first generation of 64-bit CPUs from 15 years ago. I can't
imagine such old CPUs makes up a significant portion of our users.

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

[Miro Hrončok]

On 16. 06. 21 10:10, Alfredo Moralejo Alonso wrote:



On Tue, Jun 15, 2021 at 7:41 PM Miro Hrončok > wrote:


On 15. 06. 21 19:34, Ewoud Kohl van Wijngaarden wrote:
 > And for those of us who also maintain packages for EL7/8, what's the
 > availability of these macros?

Whenever technically possible, we add our new Python macros to EPEL 7+.
Sometimes, we even backport them to plain RHEL 8+.

This can (and will) be done for the proposed "import test" macro.


I can assume the new import test macro will be included in Centos stream 9 
macros, right?


Yes, once it is available in Fedora Rawhide, I'll continue with:

 - Fedora 34
 - Fedora 33
 - CentOS Stream 9
 - EPEL 8
 - EPEL 7

Later, maybe, it might (or not) be added to RHEL 8 proper (and removed from 
EPEL 8).


That is the normal procedure for new Python macros that are backwards 
compatible.
--
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Mateusz Jończyk]

Hello,

I have already benchmarked this when Arch was considering a similar move:

https://openbenchmarking.org/result/2103142-HA-UARCHLEVE55

There is no or negligible performance benefit of compiling for x86_64-v2 versus 
amd64 baseline. For discussion see [1]. Beforehand, I have explicitly selected 
benchmarks that gave the largest performance difference when run with -O1 and 
-O3 compiler flags and were expected to show the biggest benefit from uarch 
optimizations.


I think that there is really no point in requiring x86_64-v2 as the compilers 
simply do not take much advantage from it.


Some cursory examination of the new x86_64 sublevels seem to indicate that 
x86_64-v2 goes back to roughly 2007~2008, merely cutting off the first couple 
of generations of x86_64 CPUs from Intel and AMD.

AMD introduced SSE4.2 much later then Intel - starting with Jaguar in 2013-2014.

Greetings,

Mateusz

[1] https://lists.archlinux.org/pipermail/arch-general/2021-March/048739.html
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Bringing glibc 2.34 snapshots to Fedora 35 and CentOS Stream 9

[Florian Weimer]

glibc-2.33.9000-18.fc35 with the first set of changes has been tagged
into Fedora rawhide.

Thanks,
Florian

> TL;DR: glibc 2.34 snapshots are coming. libpthread as a separate library
> creates problems, so we are removing it.  There may be some
> hickups. Full updates with “dnf update” are recommended.
>
>
> We expect that we will soon be able to import glibc upstream snapshots
> regularly into Fedora 35 and CentOS Stream 9.  We did such regular
> imports for the past couple of Fedora rawhide releases, but the
> situation will be slightly different, as explained below.  The snapshots
> will also land in CentOS Stream 9, after a delay as the result of a
> different testing pipeline.
>
> glibc 2.33 and earlier accidentally provided an very generic ROP gadget
> in the statically linked startup code that is present in every program
> (even dynamically linked ones).  We have removed the ROP gadget and
> moved that particular initialization code into the dynamically linked
> part, but that means that the interface between the startup code and the
> dynamically loaded glibc parts had to change.  As a result, any program
> linked against glibc 2.34 will not run with glibc 2.33 or any earlier
> version.  (Some of you may remember the memcpy@GLIBC_2.14 issue, it was
> similar.)  This version requirement will be properly reflected in RPM
> dependencies.
>
> glibc 2.34 removes libpthread as a separate library.  This is based on
> the observation that most processes load libpthread anyway.  (On this
> system, I count 141 out of 159 processes that load libpthread.)  One
> particularly thorny issue is that certain NSS modules depend on
> libpthread, and if the main program is not linked (indirectly) against
> libpthread, loading such NSS modules effectively loads libpthread via
> dlopen, which is something that glibc has never supported well.
> Furthermore, the availability of some pthread_* functions without
> -lpthread has been a source of confusion to developers, resulting in
> both overlinking and underlinking.
>
> We started the libpthread transition in glibc 2.33 when we added the
> __libc_single_threaded variable as a replacement for the weak symbol
> hacks that some libraries use to detect single-threaded processes.  (For
> example, libstdc++ used to do this to avoid using atomic instructions in
> std::shared_ptr.)  Backwards compatibility for dynamically linked
> binaries should be preserved (as usual), but we know of one issue on
> ppc64le, where the weak symbol hacks resulted in slightly corrupt
> binaries.  Upstream glibc did not accept the proposed backwards
> compatibility enhancement so far.  Instead, we will rebuild affected
> distribution binaries with a binutils version which handles weak symbols
> slightly differently, avoiding the corruption.  As we plan to perform
> these rebuilds before the new glibc lands in the buildroot, the
> requirement to upgrade to the new binaries before or at the same time of
> the upgrade to the glibc upstream snapshot will NOT be reflected in RPM
> dependencies.  A full upgrade using “dnf update” will work, however.
>
> In addition to the removal of libpthread, I also hope to remove libdl
> and librt.  This means that new GLIBC_2.34 symbols will be added to
> libc.so.6 (e.g., timer_create@GLIBC_2.34).  The librt removal in
> particular will probably not land with the first imported snapshot.
> This is unfortunate because RPM does not have a way to express this:
> there's just a blanket Provides: libc.so.6(GLIBC_2.34), which will
> already be included in the first snapshot that adds the symbol
> __lib_start_main@@GLIBC_2.34 (whether or not the RPM package includes
> timer_create@GLIBC_2.34 as well).  Some tools in the fedpkg/centpkg/mock
> sphere try to install builds from the Koji buildroot into installations
> from composes, without upgrading everything to the current buildroot, so
> it's possible that glibc won't be upgraded to match the requirements of
> RPMs directly imported from the buildroot.  Developers encountered
> similar issues with glibc snapshot imports (e.g., around the symbol
> pthread_getattr_np).  Our RPM infrastructure does not have per-symbol
> dependencies, so there isn't much we can do about it at the packaging
> level.  It's a transitory issue during rawhide/CentOS Stream 9
> development; the finished release will add all GLIBC_2.34 symbols in one
> upgrade, so end users won't see it in a Fedora 34 to Fedora 35 upgrade
> or a CentOS Stream 8 to CentOS Stream 9 upgrade.
>
> We think there is value in providing access to these snapshots early,
> and will try to make the transitions as smooth as possible, within the
> constraints outlined above.
>
> 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://fedorapro

Fedora-Cloud-34-20210616.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 8/8 (x86_64)

Old failures (same test failed in Fedora-Cloud-34-20210615.0):

ID: 909368  Test: x86_64 Cloud_Base-qcow2-qcow2 base_package_install_remove
URL: https://openqa.fedoraproject.org/tests/909368
ID: 909369  Test: x86_64 Cloud_Base-qcow2-qcow2 base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/909369
ID: 909370  Test: x86_64 Cloud_Base-qcow2-qcow2 base_reboot_unmount
URL: https://openqa.fedoraproject.org/tests/909370
ID: 909371  Test: x86_64 Cloud_Base-qcow2-qcow2 base_services_start
URL: https://openqa.fedoraproject.org/tests/909371
ID: 909372  Test: x86_64 Cloud_Base-qcow2-qcow2 base_selinux
URL: https://openqa.fedoraproject.org/tests/909372
ID: 909373  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/909373
ID: 909374  Test: x86_64 Cloud_Base-qcow2-qcow2 base_system_logging
URL: https://openqa.fedoraproject.org/tests/909374
ID: 909375  Test: x86_64 Cloud_Base-qcow2-qcow2 base_update_cli
URL: https://openqa.fedoraproject.org/tests/909375

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

Old soft failures (same test soft failed in Fedora-Cloud-34-20210615.0):

ID: 909380  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/909380

Passed openQA tests: 7/8 (aarch64)
-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Hans de Goede]

Hi,

On 6/16/21 10:28 AM, Daniel P. Berrangé wrote:
> On Tue, Jun 15, 2021 at 05:34:02PM -0400, Neal Gompa wrote:
>> Hey all,
>>
>> Earlier this week, I was helping with processing features for openSUSE
>> Leap 15.4[1] and I discovered that they're planning on introducing
>> x86_64-v2 to openSUSE soon. The reference for this change was that
>> RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions
>> have been considering bumping up to v2 or v3[3][4].
>>
>> Some cursory examination of the new x86_64 sublevels seem to indicate
>> that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the
>> first couple of generations of x86_64 CPUs from Intel and AMD. I
>> personally don't have any computers that don't have support for
>> x86_64-v2 anymore.
> 
> Yes, you loose primarily Intel Conroe and Penryn generations and
> AMD Opteron Gen 1 -> Gen 3. I doubt this is a significant portion
> of Fedora installs.
> 
> Slight tangent but I find Fedora's approach to hardware somewhat
> at odds with our approach to software.
> 
> On the one hand we portray our project as a place for cutting
> edge Linux software & innovation.
> 
> On the other hand we hold back our software by trying to keep
> supporting long obsolete hardware.
> 
> There is of course always a balance between bumping min hardware
> specs and the impact on maintainers & users, but I'm not convinced
> that we have the balance right in targeting our x86_64 baseline at
> the very first generation of 64-bit CPUs from 15 years ago. I can't
> imagine such old CPUs makes up a significant portion of our users.

I don't know about that, all I can offer is my own anecdotal to
the contrary. Of the 7 PCs/laptops which are in more or less
daily use in our houshold 3 of them are still core2 duo systems.

Once the core2 duo / amd64 machines came out we really started hitting
the point of diminishing returns wrt PC performance for day 2 day
use. For a lot of simple day2  day use there really is no reason
to replace and x86_64-v1 capable machines unless they are
actually broken.

Perhaps more importantly though, is that there we are also very
much at the point where bumping the processor architecture
requirements also leads to strongly diminishing returns.

Also see Mateusz Jończyk excellent reply in this thread, how
rebuilding packages for x86_64-v2 vs x86_64 results in a barely
measurable performance improvement.

Of course there are some specific algorithms which greatly
benefit from sse4.2, but those typically benefit even more
from avx/avx2 which are not included in x86_64-v2; and often
libraries already contain avx optimized code-paths for this
which they automatically use where possible.

You talk about we "hold back our software by trying to keep
supporting long obsolete hardware". Let me flip the question
can you provide hard proof, as in concrete numbers showing
significant improvements, that switching to x86_64-v2
actually buys us anything meaningful ?

Because this whole switch to x86_64-v2 sounds to me like
it is mostly being pursued because it is a higher number so
it must be better...

Dropping 32 bit x86 support was a good thing to do because
the virtual memory space offered by 32 bits was simply
becoming too small for many desktop applications like
web-browsers; and things were starting to become noticeably
broken there because upstream where no longer testing on it.

Forcing all Fedora PC users to move to x86_64 users as such
was a good thing to do and also had a significant benefits
in the form of lessening maintainer loads. Switching to
x86_64-v2 OTOH simply does not seem to give any significant
benefits.

Regards,

Hans

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-IoT-34-20210616.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 2/16 (x86_64), 3/15 (aarch64)

Old failures (same test failed in Fedora-IoT-34-20210610.0):

ID: 909339  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/909339
ID: 909340  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/909340
ID: 909355  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/909355
ID: 909358  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/909358
ID: 909367  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/909367

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

Old soft failures (same test soft failed in Fedora-IoT-34-20210610.0):

ID: 909344  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/909344

Passed openQA tests: 13/16 (x86_64), 12/15 (aarch64)

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
System load changed from 0.20 to 0.35
Previous test data: https://openqa.fedoraproject.org/tests/904980#downloads
Current test data: https://openqa.fedoraproject.org/tests/909353#downloads
-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Daniel P . Berrangé]

On Wed, Jun 16, 2021 at 12:01:29PM +0200, Hans de Goede wrote:
> Hi,
> 
> On 6/16/21 10:28 AM, Daniel P. Berrangé wrote:
> > On Tue, Jun 15, 2021 at 05:34:02PM -0400, Neal Gompa wrote:
> >> Hey all,
> >>
> >> Earlier this week, I was helping with processing features for openSUSE
> >> Leap 15.4[1] and I discovered that they're planning on introducing
> >> x86_64-v2 to openSUSE soon. The reference for this change was that
> >> RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions
> >> have been considering bumping up to v2 or v3[3][4].
> >>
> >> Some cursory examination of the new x86_64 sublevels seem to indicate
> >> that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the
> >> first couple of generations of x86_64 CPUs from Intel and AMD. I
> >> personally don't have any computers that don't have support for
> >> x86_64-v2 anymore.
> > 
> > Yes, you loose primarily Intel Conroe and Penryn generations and
> > AMD Opteron Gen 1 -> Gen 3. I doubt this is a significant portion
> > of Fedora installs.
> > 
> > Slight tangent but I find Fedora's approach to hardware somewhat
> > at odds with our approach to software.
> > 
> > On the one hand we portray our project as a place for cutting
> > edge Linux software & innovation.
> > 
> > On the other hand we hold back our software by trying to keep
> > supporting long obsolete hardware.
> > 
> > There is of course always a balance between bumping min hardware
> > specs and the impact on maintainers & users, but I'm not convinced
> > that we have the balance right in targeting our x86_64 baseline at
> > the very first generation of 64-bit CPUs from 15 years ago. I can't
> > imagine such old CPUs makes up a significant portion of our users.
> 
> I don't know about that, all I can offer is my own anecdotal to
> the contrary. Of the 7 PCs/laptops which are in more or less
> daily use in our houshold 3 of them are still core2 duo systems.
> 
> Once the core2 duo / amd64 machines came out we really started hitting
> the point of diminishing returns wrt PC performance for day 2 day
> use. For a lot of simple day2  day use there really is no reason
> to replace and x86_64-v1 capable machines unless they are
> actually broken.
> 
> Perhaps more importantly though, is that there we are also very
> much at the point where bumping the processor architecture
> requirements also leads to strongly diminishing returns.
> 
> Also see Mateusz Jończyk excellent reply in this thread, how
> rebuilding packages for x86_64-v2 vs x86_64 results in a barely
> measurable performance improvement.
> 
> Of course there are some specific algorithms which greatly
> benefit from sse4.2, but those typically benefit even more
> from avx/avx2 which are not included in x86_64-v2; and often
> libraries already contain avx optimized code-paths for this
> which they automatically use where possible.
> 
> You talk about we "hold back our software by trying to keep
> supporting long obsolete hardware". Let me flip the question
> can you provide hard proof, as in concrete numbers showing
> significant improvements, that switching to x86_64-v2
> actually buys us anything meaningful ?

I wasn't so much thinking about the performance benefit,
rather the CMPXCHG16B support which IIUC is required for
atomics on 128 bit quantities and isn't present in the
x86_64 baseline. QEMU already unconditionally adds -mcx16
to its CFLAGS to enable usage of this instruction. 

I did think there might be some performance benefits too,
so it was interesting to see the disappointing results
posted elsewhere in this thread.

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Hans de Goede]

Hi,

On 6/16/21 12:19 PM, Daniel P. Berrangé wrote:
> On Wed, Jun 16, 2021 at 12:01:29PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 6/16/21 10:28 AM, Daniel P. Berrangé wrote:
>>> On Tue, Jun 15, 2021 at 05:34:02PM -0400, Neal Gompa wrote:
 Hey all,

 Earlier this week, I was helping with processing features for openSUSE
 Leap 15.4[1] and I discovered that they're planning on introducing
 x86_64-v2 to openSUSE soon. The reference for this change was that
 RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions
 have been considering bumping up to v2 or v3[3][4].

 Some cursory examination of the new x86_64 sublevels seem to indicate
 that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the
 first couple of generations of x86_64 CPUs from Intel and AMD. I
 personally don't have any computers that don't have support for
 x86_64-v2 anymore.
>>>
>>> Yes, you loose primarily Intel Conroe and Penryn generations and
>>> AMD Opteron Gen 1 -> Gen 3. I doubt this is a significant portion
>>> of Fedora installs.
>>>
>>> Slight tangent but I find Fedora's approach to hardware somewhat
>>> at odds with our approach to software.
>>>
>>> On the one hand we portray our project as a place for cutting
>>> edge Linux software & innovation.
>>>
>>> On the other hand we hold back our software by trying to keep
>>> supporting long obsolete hardware.
>>>
>>> There is of course always a balance between bumping min hardware
>>> specs and the impact on maintainers & users, but I'm not convinced
>>> that we have the balance right in targeting our x86_64 baseline at
>>> the very first generation of 64-bit CPUs from 15 years ago. I can't
>>> imagine such old CPUs makes up a significant portion of our users.
>>
>> I don't know about that, all I can offer is my own anecdotal to
>> the contrary. Of the 7 PCs/laptops which are in more or less
>> daily use in our houshold 3 of them are still core2 duo systems.
>>
>> Once the core2 duo / amd64 machines came out we really started hitting
>> the point of diminishing returns wrt PC performance for day 2 day
>> use. For a lot of simple day2  day use there really is no reason
>> to replace and x86_64-v1 capable machines unless they are
>> actually broken.
>>
>> Perhaps more importantly though, is that there we are also very
>> much at the point where bumping the processor architecture
>> requirements also leads to strongly diminishing returns.
>>
>> Also see Mateusz Jończyk excellent reply in this thread, how
>> rebuilding packages for x86_64-v2 vs x86_64 results in a barely
>> measurable performance improvement.
>>
>> Of course there are some specific algorithms which greatly
>> benefit from sse4.2, but those typically benefit even more
>> from avx/avx2 which are not included in x86_64-v2; and often
>> libraries already contain avx optimized code-paths for this
>> which they automatically use where possible.
>>
>> You talk about we "hold back our software by trying to keep
>> supporting long obsolete hardware". Let me flip the question
>> can you provide hard proof, as in concrete numbers showing
>> significant improvements, that switching to x86_64-v2
>> actually buys us anything meaningful ?
> 
> I wasn't so much thinking about the performance benefit,
> rather the CMPXCHG16B support which IIUC is required for
> atomics on 128 bit quantities and isn't present in the
> x86_64 baseline. QEMU already unconditionally adds -mcx16
> to its CFLAGS to enable usage of this instruction. 

CMPXCHG16B is indeed supported on pretty much any x86_64 machine,
including on Intel Conroe and Penryn AFAICT.

Only very old AMD64 CPUs, which are still using DDR1 don't
support this (AFAICT).

So yes requiring that is probably fine.

> I did think there might be some performance benefits too,
> so it was interesting to see the disappointing results
> posted elsewhere in this thread.

Ack, I suspect that the cases where there are really significant
gains in using SSE4 are already covered by (optional) SSE4 
optimized code paths.

I think it would be better if we want to look into using newer
instructions into looking into things like this.

E.g. if there is some library which does significantly benefit
from gcc's auto-vectorisation with sse4 and/or avx then we
could build it multiple times with different settings and use
the hwcaps based library loading mechanism to make an optimized
version get loaded on hw which supports it. This way we can even
use avx / x86_64-v3 / -v4 in cases where this actually is worth
the extra effort + diskspace.

Regards,

Hans
___
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/

Re: x86_64-v2 in Fedora

[Eugene Syromiatnikov]

On Wed, Jun 16, 2021 at 09:28:47AM +0100, Daniel P. Berrangé wrote:
> On Tue, Jun 15, 2021 at 05:34:02PM -0400, Neal Gompa wrote:
> > Hey all,
> > 
> > Earlier this week, I was helping with processing features for openSUSE
> > Leap 15.4[1] and I discovered that they're planning on introducing
> > x86_64-v2 to openSUSE soon. The reference for this change was that
> > RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions
> > have been considering bumping up to v2 or v3[3][4].
> > 
> > Some cursory examination of the new x86_64 sublevels seem to indicate
> > that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the
> > first couple of generations of x86_64 CPUs from Intel and AMD. I
> > personally don't have any computers that don't have support for
> > x86_64-v2 anymore.
> 
> Yes, you loose primarily Intel Conroe and Penryn generations and
> AMD Opteron Gen 1 -> Gen 3. I doubt this is a significant portion
> of Fedora installs.

What many seem to confuse here is when there were the first CPUs
that support a particular set of instruction versus the last one that
does not.  Intel almost prides itself on its product segmentation,
and there is a ton of recently (in 2020!) released Pentium/Celeron/Atom
CPUs that still do not support even AVX[1][2].

[1] 
https://ark.intel.com/content/www/us/en/ark/products/203896/intel-pentium-gold-g6400e-processor-4m-cache-3-80-ghz.html
released in Q2 2020, only SSE4.1/4.2 is listed, cf.

https://ark.intel.com/content/www/us/en/ark/products/199283/intel-core-i3-10100-processor-6m-cache-up-to-4-30-ghz.html
[2] 
https://www.tomshardware.com/news/intels-latest-celeron-and-pentium-cpus-finally-get-avx2-avx-512-support
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Eugene Syromiatnikov]

On Wed, Jun 16, 2021 at 12:37:57PM +0200, Eugene Syromiatnikov wrote:
> On Wed, Jun 16, 2021 at 09:28:47AM +0100, Daniel P. Berrangé wrote:
> > On Tue, Jun 15, 2021 at 05:34:02PM -0400, Neal Gompa wrote:
> > > Hey all,
> > > 
> > > Earlier this week, I was helping with processing features for openSUSE
> > > Leap 15.4[1] and I discovered that they're planning on introducing
> > > x86_64-v2 to openSUSE soon. The reference for this change was that
> > > RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions
> > > have been considering bumping up to v2 or v3[3][4].
> > > 
> > > Some cursory examination of the new x86_64 sublevels seem to indicate
> > > that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the
> > > first couple of generations of x86_64 CPUs from Intel and AMD. I
> > > personally don't have any computers that don't have support for
> > > x86_64-v2 anymore.
> > 
> > Yes, you loose primarily Intel Conroe and Penryn generations and
> > AMD Opteron Gen 1 -> Gen 3. I doubt this is a significant portion
> > of Fedora installs.
> 
> What many seem to confuse here is when there were the first CPUs
> that support a particular set of instruction versus the last one that
> does not.  Intel almost prides itself on its product segmentation,
> and there is a ton of recently (in 2020!) released Pentium/Celeron/Atom
> CPUs that still do not support even AVX[1][2].
> 
> [1] 
> https://ark.intel.com/content/www/us/en/ark/products/203896/intel-pentium-gold-g6400e-processor-4m-cache-3-80-ghz.html
> released in Q2 2020, only SSE4.1/4.2 is listed, cf.
> 
> https://ark.intel.com/content/www/us/en/ark/products/199283/intel-core-i3-10100-processor-6m-cache-up-to-4-30-ghz.html
> [2] 
> https://www.tomshardware.com/news/intels-latest-celeron-and-pentium-cpus-finally-get-avx2-avx-512-support

Oops, I confused "Gen 3" above with x86_64-v3; however, with regards to
v2 support, Westmere-based Pentiums/Celerons were released in 2011
and do not support SSE4.1/4.2.

[1] https://www.cpu-world.com/sspec/SL/SLBT6.html
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Unannounced pcre2-posix SONAME bump, I think

[Richard W.M. Jones]

https://koji.fedoraproject.org/koji/rpminfo?rpmID=26566365

Seems to have gone from:
/usr/lib64/libpcre2-posix.so.2
to:
/usr/lib64/libpcre2-posix.so.3

This broke a few things, notably util-linux.  My attempt to rebuild
util-linux failed, so I'm still looking at that.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unannounced pcre2-posix SONAME bump, I think

[Richard W.M. Jones]

On Wed, Jun 16, 2021 at 12:00:37PM +0100, Richard W.M. Jones wrote:
> 
> https://koji.fedoraproject.org/koji/rpminfo?rpmID=26566365
> 
> Seems to have gone from:
> /usr/lib64/libpcre2-posix.so.2
> to:
> /usr/lib64/libpcre2-posix.so.3
> 
> This broke a few things, notably util-linux.  My attempt to rebuild
> util-linux failed, so I'm still looking at that.

Oh woe is me, util-linux build depends on util-linux (not directly,
but because the basic Koji build environment needs it).  So I don't
see how we will be able to rebuild this.

Could someone untag the broken pcre2 package from Rawhide?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora rawhide compose report: 20210616.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20210615.n.1
NEW: Fedora-Rawhide-20210616.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  10
Dropped packages:1
Upgraded packages:   33
Downgraded packages: 0

Size of added packages:  1.48 MiB
Size of dropped packages:448.48 KiB
Size of upgraded packages:   1.06 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   1.34 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: dm-zoned-tools-2.1.2-1.fc35
Summary: Provides utilities to format, check and repair Linux dm-zoned devices
RPMs:dm-zoned-tools
Size:244.25 KiB

Package: golang-github-brunnre8-notmuch-0-0.1.20210615gitcaa2daf.fc35
Summary: Go language bindings for notmuch mail
RPMs:golang-github-brunnre8-notmuch-devel
Size:36.24 KiB

Package: golang-github-ddevault-libvterm-0-0.1.20210615gitb7d861d.fc35
Summary: Aerc fork of go-libvterm
RPMs:golang-github-ddevault-libvterm-devel
Size:46.84 KiB

Package: golang-github-emersion-sasl-0-0.1.20210615git7bfe0ed.fc35
Summary: SASL library written in Go
RPMs:golang-github-emersion-sasl-devel
Size:15.90 KiB

Package: golang-github-emersion-textwrapper-0-0.1.20210615git65d8968.fc35
Summary: Writer that wraps long text lines to a specified length
RPMs:golang-github-emersion-textwrapper-devel
Size:10.89 KiB

Package: golang-github-kyoh86-xdg-1.2.0-1.fc35
Summary: Light weight helper functions for the XDG Base Directory Specification
RPMs:golang-github-kyoh86-xdg-devel
Size:14.77 KiB

Package: golang-github-miolini-datacounter-1.0.2-1.fc35
Summary: Golang counters for readers/writers
RPMs:golang-github-miolini-datacounter-devel
Size:11.37 KiB

Package: golang-github-protonmail-crypto-0-0.1.20210615git11f6ee2.fc35
Summary: Go supplementary cryptography libraries
RPMs:golang-github-protonmail-crypto-devel
Size:1.08 MiB

Package: golang-github-riywo-loginshell-0-0.1.20210615git7d26008.fc35
Summary: Golang library to get the login shell of the current user
RPMs:golang-github-riywo-loginshell-devel
Size:10.81 KiB

Package: golang-sr-sircmpwn-getopt-0-0.1.20210615git23622cc.fc35
Summary: POSIX-compatible getopt implementation for Go
RPMs:golang-sr-sircmpwn-getopt-devel
Size:17.37 KiB


= DROPPED PACKAGES =
Package: vecmath-1.6.0-0.17.20130710git41fddda.fc34
Summary: The 3D vector math Java package, javax.vecmath
RPMs:vecmath vecmath-javadoc
Size:448.48 KiB


= UPGRADED PACKAGES =
Package:  awscli-1.19.95-1.fc35
Old package:  awscli-1.19.94-1.fc35
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 2.05 MiB
Size change:  175 B
Changelog:
  * Tue Jun 15 2021 Gwyn Ciesla  - 1.19.95-1
  - 1.19.95


Package:  blktrace-1.3.0-2.fc35
Old package:  blktrace-1.3.0-1.fc35
Summary:  Utilities for performing block layer IO tracing in the Linux 
kernel
RPMs: blktrace iowatcher
Size: 991.93 KiB
Size change:  862 B
Changelog:
  * Tue Jun 15 2021 Eric Sandeen  - 1.3.0-2
  - Use plaintext version of signature file


Package:  cabextract-1.9.1-1.fc35
Old package:  cabextract-1.9-7.fc35
Summary:  Utility for extracting cabinet (.cab) archives
RPMs: cabextract
Size: 342.88 KiB
Size change:  -3.47 KiB
Changelog:
  * Wed Jun 16 2021 Robert Scheck  - 1.9.1-1
  - Update to 1.9.1 (#1684967)


Package:  certmonger-0.79.14-1.fc35
Old package:  certmonger-0.79.13-2.fc34
Summary:  Certificate status monitor and PKI enrollment client
RPMs: certmonger
Size: 2.87 MiB
Size change:  87.23 KiB
Changelog:
  * Tue Jun 15 2021 Rob Crittenden  - 0.79.14-1
  - Update to upstream 0.79.14


Package:  date-3.0.1^20210518git052eeba-1.fc35
Old package:  date-3.0.0-5.20200708git6952fb5.fc35
Summary:  Date and time library based on the C++11/14/17  header
RPMs: date-devel libdate-tz
Size: 574.57 KiB
Size change:  27.36 KiB
Changelog:
  * Tue Jun 15 2021 Aleksei Bavshin  - 
3.0.1^20210518git052eeba-1
  - Upstream release 3.0.1 (+ 2 fixes from git master)
  - Apply new versioning guidelines for snapshots


Package:  direnv-2.28.0-2.fc35
Old package:  direnv-2.27.0-2.fc34
Summary:  Per-directory shell configuration tool
RPMs: direnv golang-github-direnv-devel
Size: 10.83 MiB
Size change:  -72.38 KiB
Changelog:
  * Tue Jun 15 2021 Ed Marshall  - 2.28.0-1
  - Update to 2.28.0a
  - Close: rhbz#1938419


Package:  dummy-test-package-gloster-0-4050.fc35
Old package:  dummy-test-package-gloster-0-4046.fc35
Summary:  Dummy Test Package called Gloster
RPMs: dummy-test-package-gloster
Size: 250.22 KiB
Size change:  244 B
Changelog:
  * Tue Jun 15 2021 packagerbot  - 0-4047
  - rebuilt

  * Tue Jun 15 2021 packagerbot  - 0-4048
  - rebuilt

  * Wed Jun 16 2021 packagerbot  - 0-4049
  - rebuilt

  * Wed Jun 16 2021

Re: Unannounced pcre2-posix SONAME bump, I think

[Lukas Javorsky]

Hello,

I'm the one to blame, I'm really sorry about that, it was a new experience
for me and I didn't know it has its own workflow.

Could you please help me with "How to untag it" properly and that this
change doesn't break anything else?

Thank you so much and apologies for the inconvenience
Lukas

On Wed, Jun 16, 2021 at 1:05 PM Richard W.M. Jones 
wrote:

> On Wed, Jun 16, 2021 at 12:00:37PM +0100, Richard W.M. Jones wrote:
> >
> > https://koji.fedoraproject.org/koji/rpminfo?rpmID=26566365
> >
> > Seems to have gone from:
> > /usr/lib64/libpcre2-posix.so.2
> > to:
> > /usr/lib64/libpcre2-posix.so.3
> >
> > This broke a few things, notably util-linux.  My attempt to rebuild
> > util-linux failed, so I'm still looking at that.
>
> Oh woe is me, util-linux build depends on util-linux (not directly,
> but because the basic Koji build environment needs it).  So I don't
> see how we will be able to rebuild this.
>
> Could someone untag the broken pcre2 package from Rawhide?
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://people.redhat.com/~rjones/virt-df/
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
S pozdravom/ Best regards

Lukáš Javorský

Associate Software Engineer, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.com

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)

[Vít Ondruch]

Dne 15. 06. 21 v 19:34 Ewoud Kohl van Wijngaarden napsal(a):

On Tue, Jun 15, 2021 at 01:51:12PM +0200, Miro Hrončok wrote:

On 15. 06. 21 13:46, Vitaly Zaitsev via devel wrote:

If that is not possible with reasonable effort,
at least a basic smoke test (such as importing the packaged module)
*MUST* be run in `+%check+`.


A simple scriplet should be introduced I think:

%check
%do_import_test


Already on it:
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99


This may be not be the right place, but in Foreman's Ruby packaging 
we've also felt a similar pain. Mostly with C extensions that were 
built in the wrong directory. We also added a %check section to do a 
basic "import" (require) test.


Is there a similar macro for Ruby smoke testing?



No, there is no similar macro for Ruby. Historically, it was not clear 
what should be actually required. With Bundler putting into place more 
conventions, the situation is better.


Nevertheless, what is the specific issue you are referring to above? 
There are many examples of fixing such issue, e.g.


https://src.fedoraproject.org/rpms/rubygem-bcrypt/blob/rawhide/f/rubygem-bcrypt.spec#_52

And there are probably more complex cases.




And for those of us who also maintain packages for EL7/8, what's the 
availability of these macros?



RHEL7 is in Maintenance Support 2 Phase [1], so don't expect too much. 
There are better chances to get such macro into RHEL8, but in the 
context of Ruby, there are 3 supported versions ATM, therefore it might 
get complex.


Anyway, it is good idea to use such macros in the following way:


~~~

%{?import_smoke_test}

~~~


This does the right thing where such macro is supported and is ignored 
elsewhere, where such macro is not available.



Vít


[1] https://access.redhat.com/support/policy/updates/errata

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unannounced pcre2-posix SONAME bump, I think

[Richard W.M. Jones]

On Wed, Jun 16, 2021 at 01:10:48PM +0200, Lukas Javorsky wrote:
> Hello,
> 
> I'm the one to blame, I'm really sorry about that, it was a new experience for
> me and I didn't know it has its own workflow.
> 
> Could you please help me with "How to untag it" properly and that this change
> doesn't break anything else?

I believe we need a Fedora administrator of some kind to
untag it.

The bigger problem is how can we build util-linux against the new
library.  I guess pcre2 will have to supply a compat subpackage ...

Rich.

> Thank you so much and apologies for the inconvenience
> Lukas
> 
> On Wed, Jun 16, 2021 at 1:05 PM Richard W.M. Jones  wrote:
> 
> On Wed, Jun 16, 2021 at 12:00:37PM +0100, Richard W.M. Jones wrote:
> >
> > https://koji.fedoraproject.org/koji/rpminfo?rpmID=26566365
> >
> > Seems to have gone from:
> > /usr/lib64/libpcre2-posix.so.2
> > to:
> > /usr/lib64/libpcre2-posix.so.3
> >
> > This broke a few things, notably util-linux.  My attempt to rebuild
> > util-linux failed, so I'm still looking at that.
> 
> Oh woe is me, util-linux build depends on util-linux (not directly,
> but because the basic Koji build environment needs it).  So I don't
> see how we will be able to rebuild this.
> 
> Could someone untag the broken pcre2 package from Rawhide?
> 
> Rich.
> 
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/
> ~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://people.redhat.com/~rjones/virt-df/
> ___
> 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
> Do not reply to spam on the list, report it: https://pagure.io/
> fedora-infrastructure
> 
> 
> 
> --
> S pozdravom/ Best regards
> 
> Lukáš Javorský
> 
> Associate Software Engineer, Core service - Databases
> 
> Red Hat
> 
> Purkyňova 115 (TPB-C)
> 
> 612 00 Brno - Královo Pole
> 
> ljavo...@redhat.com
> 
> [logo--200]
> 
> 

> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure


-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unannounced pcre2-posix SONAME bump, I think

[Lukas Javorsky]

> I believe we need a Fedora administrator of some kind to
> untag it.
Do you know where I could find some?

> The bigger problem is how can we build util-linux against the new
> library.  I guess pcre2 will have to supply a compat subpackage ...
Yes, we will discuss this for sure, we'll just discuss it in the team first
and then we'll let you know

On Wed, Jun 16, 2021 at 1:20 PM Richard W.M. Jones 
wrote:

> On Wed, Jun 16, 2021 at 01:10:48PM +0200, Lukas Javorsky wrote:
> > Hello,
> >
> > I'm the one to blame, I'm really sorry about that, it was a new
> experience for
> > me and I didn't know it has its own workflow.
> >
> > Could you please help me with "How to untag it" properly and that this
> change
> > doesn't break anything else?
>
> I believe we need a Fedora administrator of some kind to
> untag it.
>
> The bigger problem is how can we build util-linux against the new
> library.  I guess pcre2 will have to supply a compat subpackage ...
>
> Rich.
>
> > Thank you so much and apologies for the inconvenience
> > Lukas
> >
> > On Wed, Jun 16, 2021 at 1:05 PM Richard W.M. Jones 
> wrote:
> >
> > On Wed, Jun 16, 2021 at 12:00:37PM +0100, Richard W.M. Jones wrote:
> > >
> > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=26566365
> > >
> > > Seems to have gone from:
> > > /usr/lib64/libpcre2-posix.so.2
> > > to:
> > > /usr/lib64/libpcre2-posix.so.3
> > >
> > > This broke a few things, notably util-linux.  My attempt to rebuild
> > > util-linux failed, so I'm still looking at that.
> >
> > Oh woe is me, util-linux build depends on util-linux (not directly,
> > but because the basic Koji build environment needs it).  So I don't
> > see how we will be able to rebuild this.
> >
> > Could someone untag the broken pcre2 package from Rawhide?
> >
> > Rich.
> >
> > --
> > Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/
> > ~rjones
> > Read my programming and virtualization blog:
> http://rwmj.wordpress.com
> > virt-df lists disk usage of guests without needing to install any
> > software inside the virtual machine.  Supports Linux and Windows.
> > http://people.redhat.com/~rjones/virt-df/
> > ___
> > 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
> > Do not reply to spam on the list, report it: https://pagure.io/
> > fedora-infrastructure
> >
> >
> >
> > --
> > S pozdravom/ Best regards
> >
> > Lukáš Javorský
> >
> > Associate Software Engineer, Core service - Databases
> >
> > Red Hat
> >
> > Purkyňova 115 (TPB-C)
> >
> > 612 00 Brno - Královo Pole
> >
> > ljavo...@redhat.com
> >
> > [logo--200]
> >
> >
>
> > ___
> > 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
> > Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://people.redhat.com/~rjones/virt-df/
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
S pozdravom/ Best regards

Lukáš Javorský

Associate Software Engineer, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.com

___
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/
L

Re: x86_64-v2 in Fedora

[Solomon Peachy]

On Wed, Jun 16, 2021 at 12:52:22PM +0200, Eugene Syromiatnikov wrote:
> Oops, I confused "Gen 3" above with x86_64-v3; however, with regards to
> v2 support, Westmere-based Pentiums/Celerons were released in 2011
> and do not support SSE4.1/4.2.

And until the Silvermont core (in 2013) the Atom family didn't support 
SSE4.1/4.2 either.

AMD supported SSE4.1/4.2 starting with Bulldozer in 2011, but their 
embedded series didn't get it until 2013 with Jaguar.

Oh, one other data point -- VIA didn't support SSE4.2 until their Nano C 
in 2015, though they had support for SSE4.1 starting with their Nano 
3000 series in 2009.

Anyway. Personally, I only have one Fedora system still in use that 
isn't at least x86_64v2 -- a dual-socket pre-Bulldozer Opteron server 
that is probably the single most important system I have.

 - Solomon
-- 
Solomon Peachypizza at shaftnet dot org (email&xmpp)
  @pizza:shaftnet dot org   (matrix)
High Springs, FL  speachy (libra.chat)


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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Can't login with kinit using 2FA

[Vít Ondruch]

Dne 15. 06. 21 v 23:26 Michael Catanzaro napsal(a):

On Tue, Jun 15 2021 at 09:18:34 PM +0200, Dan Horák  wrote:

make sure you have the fedora-packager-kerberos package installed, I
suspect the last update of fedora-packager wasn't right


Whatever is needed for Fedora kerberos to work needs to be a 
dependency of gnome-online-accounts, since Fedora account is a 
supported account type there. You shouldn't need to install anything 
extra.


FWIW I don't have fedora-packager-kerberos installed, and kerberos is 
still working perfectly fine for me as of today.



It depends how recent your Fedora is. Neither I had installed 
fedora-packager-kerberos up until yesterday, because the package is 
quite fresh:


https://src.fedoraproject.org/rpms/fedora-packager/c/a7fde86069c3595fdaf8b7bcfe22c231f55b48de?branch=rawhide

So can I uninstall it if I am using GOA?


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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unannounced pcre2-posix SONAME bump, I think

[Richard W.M. Jones]

On Wed, Jun 16, 2021 at 01:23:02PM +0200, Lukas Javorsky wrote:
> > I believe we need a Fedora administrator of some kind to
> > untag it.
> Do you know where I could find some?

I'm hoping on this mailing list :-)

Rich.

> > The bigger problem is how can we build util-linux against the new
> > library.  I guess pcre2 will have to supply a compat subpackage ...
> Yes, we will discuss this for sure, we'll just discuss it in the team first 
> and
> then we'll let you know
> 
> On Wed, Jun 16, 2021 at 1:20 PM Richard W.M. Jones  wrote:
> 
> On Wed, Jun 16, 2021 at 01:10:48PM +0200, Lukas Javorsky wrote:
> > Hello,
> >
> > I'm the one to blame, I'm really sorry about that, it was a new
> experience for
> > me and I didn't know it has its own workflow.
> >
> > Could you please help me with "How to untag it" properly and that this
> change
> > doesn't break anything else?
> 
> I believe we need a Fedora administrator of some kind to
> untag it.
> 
> The bigger problem is how can we build util-linux against the new
> library.  I guess pcre2 will have to supply a compat subpackage ...
> 
> Rich.
> 
> > Thank you so much and apologies for the inconvenience
> > Lukas
> >
> > On Wed, Jun 16, 2021 at 1:05 PM Richard W.M. Jones 
> wrote:
> >
> >     On Wed, Jun 16, 2021 at 12:00:37PM +0100, Richard W.M. Jones wrote:
> >     >
> >     > https://koji.fedoraproject.org/koji/rpminfo?rpmID=26566365
> >     >
> >     > Seems to have gone from:
> >     > /usr/lib64/libpcre2-posix.so.2
> >     > to:
> >     > /usr/lib64/libpcre2-posix.so.3
> >     >
> >     > This broke a few things, notably util-linux.  My attempt to 
> rebuild
> >     > util-linux failed, so I'm still looking at that.
> >
> >     Oh woe is me, util-linux build depends on util-linux (not directly,
> >     but because the basic Koji build environment needs it).  So I don't
> >     see how we will be able to rebuild this.
> >
> >     Could someone untag the broken pcre2 package from Rawhide?
> >
> >     Rich.
> >
> >     --
> >     Richard Jones, Virtualization Group, Red Hat 
> http://people.redhat.com
> /
> >     ~rjones
> >     Read my programming and virtualization blog: http://
> rwmj.wordpress.com
> >     virt-df lists disk usage of guests without needing to install any
> >     software inside the virtual machine.  Supports Linux and Windows.
> >     http://people.redhat.com/~rjones/virt-df/
> >     ___
> >     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
> >     Do not reply to spam on the list, report it: https://pagure.io/
> >     fedora-infrastructure
> >
> >
> >
> > --
> > S pozdravom/ Best regards
> >
> > Lukáš Javorský
> >
> > Associate Software Engineer, Core service - Databases
> >
> > Red Hat
> >
> > Purkyňova 115 (TPB-C)
> >
> > 612 00 Brno - Královo Pole
> >
> > ljavo...@redhat.com
> >
> > [logo--200]
> >
> >
> 
> > ___
> > 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
> > Do not reply to spam on the list, report it: https://pagure.io/
> fedora-infrastructure
> 
> 
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/
> ~rjones
> Read my programming and virtualization blog: http://rwmj.wordpress.com
> virt-df lists disk usage of guests without needing to install any
> software inside the virtual machine.  Supports Linux and Windows.
> http://people.redhat.com/~rjones/virt-df/
> ___
> 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 Developer Portal update

[Pavel Valena]

Hello,

Fedora Developer Portal just got an update.

Notable changes:
  - Added R language pages [1]
  - Added Maven section to Java page [2]
  - Updated Python pages [3]

Any feedback is welcome!

[1] https://developer.fedoraproject.org/tech/languages/r/r-installation.html
[2] 
https://developer.fedoraproject.org/tech/languages/java/java-build-tools-installation.html
[3] 
https://developer.fedoraproject.org/tech/languages/python/python-installation.html

Regards,
--
Pavel Valena
Software Engineer, Red Hat
Brno, Czech Republic
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Rubygem package smoke testing [was: Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)]

[Ewoud Kohl van Wijngaarden]

On Wed, Jun 16, 2021 at 01:17:31PM +0200, Vít Ondruch wrote:


Dne 15. 06. 21 v 19:34 Ewoud Kohl van Wijngaarden napsal(a):

On Tue, Jun 15, 2021 at 01:51:12PM +0200, Miro Hrončok wrote:

On 15. 06. 21 13:46, Vitaly Zaitsev via devel wrote:

If that is not possible with reasonable effort,
at least a basic smoke test (such as importing the packaged module)
*MUST* be run in `+%check+`.


A simple scriplet should be introduced I think:

%check
%do_import_test


Already on it:
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99


This may be not be the right place, but in Foreman's Ruby packaging 
we've also felt a similar pain. Mostly with C extensions that were 
built in the wrong directory. We also added a %check section to do a 
basic "import" (require) test.


Is there a similar macro for Ruby smoke testing?



No, there is no similar macro for Ruby. Historically, it was not clear 
what should be actually required. With Bundler putting into place more 
conventions, the situation is better.


Nevertheless, what is the specific issue you are referring to above? 
There are many examples of fixing such issue, e.g.


https://src.fedoraproject.org/rpms/rubygem-bcrypt/blob/rawhide/f/rubygem-bcrypt.spec#_52

And there are probably more complex cases.


Perhaps we should take this to a separate discussion, but we found that 
there are various bugs in SCL macros that s.o ended up in the wrong 
directories so it wouldn't load.


Our specific case is that we have our own SCL that depends on rh-ruby27 
and must override GEM_PATH[1], GEM_HOME[2] and replace %%gem_install[3]. 
We forgot this at some point. Providing the explicit paths masked this 
failure. Perhaps this simply can't work inside RPM builds and you need 
to really install it in some chroot to test it.


[1]: 
https://github.com/theforeman/foreman-packaging/blob/7b1dd67c08f4f17b818dd0b7d2b80e243c652211/packages/foreman/tfm/tfm.spec#L220
[2]: 
https://github.com/theforeman/foreman-packaging/blob/7b1dd67c08f4f17b818dd0b7d2b80e243c652211/packages/foreman/tfm/tfm.spec#L221
[3]: 
https://github.com/theforeman/foreman-packaging/blob/7b1dd67c08f4f17b818dd0b7d2b80e243c652211/packages/foreman/tfm/macros.tfm#L1-L13



And for those of us who also maintain packages for EL7/8, what's the 
availability of these macros?



RHEL7 is in Maintenance Support 2 Phase [1], so don't expect too much. 
There are better chances to get such macro into RHEL8, but in the 
context of Ruby, there are 3 supported versions ATM, therefore it 
might get complex.


Anyway, it is good idea to use such macros in the following way:


~~~

%{?import_smoke_test}

~~~


This does the right thing where such macro is supported and is ignored 
elsewhere, where such macro is not available.


Thanks! That makes sense.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Björn Persson]

Stephen John Smoogen wrote:
> #!/usr/bin/awk -f
> 
> BEGIN {
> while (!/flags/) if (getline < "/proc/cpuinfo" != 1) exit 1
> if (/lm/&&/cmov/&&/cx8/&&/fpu/&&/fxsr/&&/mmx/&&/syscall/&&/sse2/) level = 
> 1
> if (level == 1 &&
> /cx16/&&/lahf/&&/popcnt/&&/sse4_1/&&/sse4_2/&&/ssse3/) level = 2
> if (level == 2 &&
> /avx/&&/avx2/&&/bmi1/&&/bmi2/&&/f16c/&&/fma/&&/abm/&&/movbe/&&/xsave/)
> level = 3
> if (level == 3 &&
> /avx512f/&&/avx512bw/&&/avx512cd/&&/avx512dq/&&/avx512vl/) level = 4
> if (level > 0) { print "CPU supports x86-64-v" level; exit level + 1 }
> exit 1
> }

That script says "x86-64-v1" on my previous workstation, which is now a
server. But I'm already planning to reinstall that one with Debian, to
get less upgrade churn while keeping Ada and ZFS, so it won't hurt me
if Fedora stops working there.

Björn Persson


pgptuEq6E5mQJ.pgp
Description: OpenPGP digital signatur
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unannounced pcre2-posix SONAME bump, I think

[Lukas Javorsky]

The build has been untagged.

I want to apologize one more time.
This experience will be written in my mind forever.

Thank you to everyone who helped with this

On Wed, Jun 16, 2021 at 1:30 PM Richard W.M. Jones 
wrote:

> On Wed, Jun 16, 2021 at 01:23:02PM +0200, Lukas Javorsky wrote:
> > > I believe we need a Fedora administrator of some kind to
> > > untag it.
> > Do you know where I could find some?
>
> I'm hoping on this mailing list :-)
>
> Rich.
>
> > > The bigger problem is how can we build util-linux against the new
> > > library.  I guess pcre2 will have to supply a compat subpackage ...
> > Yes, we will discuss this for sure, we'll just discuss it in the team
> first and
> > then we'll let you know
> >
> > On Wed, Jun 16, 2021 at 1:20 PM Richard W.M. Jones 
> wrote:
> >
> > On Wed, Jun 16, 2021 at 01:10:48PM +0200, Lukas Javorsky wrote:
> > > Hello,
> > >
> > > I'm the one to blame, I'm really sorry about that, it was a new
> > experience for
> > > me and I didn't know it has its own workflow.
> > >
> > > Could you please help me with "How to untag it" properly and that
> this
> > change
> > > doesn't break anything else?
> >
> > I believe we need a Fedora administrator of some kind to
> > untag it.
> >
> > The bigger problem is how can we build util-linux against the new
> > library.  I guess pcre2 will have to supply a compat subpackage ...
> >
> > Rich.
> >
> > > Thank you so much and apologies for the inconvenience
> > > Lukas
> > >
> > > On Wed, Jun 16, 2021 at 1:05 PM Richard W.M. Jones <
> rjo...@redhat.com>
> > wrote:
> > >
> > > On Wed, Jun 16, 2021 at 12:00:37PM +0100, Richard W.M. Jones
> wrote:
> > > >
> > > > https://koji.fedoraproject.org/koji/rpminfo?rpmID=26566365
> > > >
> > > > Seems to have gone from:
> > > > /usr/lib64/libpcre2-posix.so.2
> > > > to:
> > > > /usr/lib64/libpcre2-posix.so.3
> > > >
> > > > This broke a few things, notably util-linux.  My attempt to
> rebuild
> > > > util-linux failed, so I'm still looking at that.
> > >
> > > Oh woe is me, util-linux build depends on util-linux (not
> directly,
> > > but because the basic Koji build environment needs it).  So I
> don't
> > > see how we will be able to rebuild this.
> > >
> > > Could someone untag the broken pcre2 package from Rawhide?
> > >
> > > Rich.
> > >
> > > --
> > > Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com
> > /
> > > ~rjones
> > > Read my programming and virtualization blog: http://
> > rwmj.wordpress.com
> > > virt-df lists disk usage of guests without needing to install
> any
> > > software inside the virtual machine.  Supports Linux and
> Windows.
> > > http://people.redhat.com/~rjones/virt-df/
> > > ___
> > > 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
> > > Do not reply to spam on the list, report it:
> https://pagure.io/
> > > fedora-infrastructure
> > >
> > >
> > >
> > > --
> > > S pozdravom/ Best regards
> > >
> > > Lukáš Javorský
> > >
> > > Associate Software Engineer, Core service - Databases
> > >
> > > Red Hat
> > >
> > > Purkyňova 115 (TPB-C)
> > >
> > > 612 00 Brno - Královo Pole
> > >
> > > ljavo...@redhat.com
> > >
> > > [logo--200]
> > >
> > >
> >
> > > ___
> > > 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
> > > Do not reply to spam on the list, report it: https://pagure.io/
> > fedora-infrastructure
> >
> >
> > --
> > Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/
> > ~rjones
> > Read my programming and virtualization blog:
> http://rwmj.wordpress.com
> > virt-df lists disk usage of guests without needing to install any
> > software inside the virtual machine.  Supports Linux and Windows.
> > http://p

Experience on src.fedoraproject.org as non-packager

[Ewoud Kohl van Wijngaarden]

Hello everyone,

Even though I've now been sponsored as a packager, I did want to share 
my experience since it was a bit frustrating.


If you do have a FAS account, you can log in on src.fedoraproject.org 
and can even fork repositories. However, on the clone URL you only see 
the anonymous git URL. That means you have no way to push changes to 
your fork. That also means you can't submit a PR to repositories using 
your fork. The end result is that it's very hard to contribute to 
repositories.


My suggestion is to either give non-packagers the URL (and if needed 
permission) to push to their own forks or remove the ability to fork a 
repository.


Regards,
Ewoud Kohl van Wijngaarden
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unannounced pcre2-posix SONAME bump, I think

[Karel Zak]

On Wed, Jun 16, 2021 at 12:19:48PM +0100, Richard W.M. Jones wrote:
> On Wed, Jun 16, 2021 at 01:10:48PM +0200, Lukas Javorsky wrote:
> > Hello,
> > 
> > I'm the one to blame, I'm really sorry about that, it was a new experience 
> > for
> > me and I didn't know it has its own workflow.
> > 
> > Could you please help me with "How to untag it" properly and that this 
> > change
> > doesn't break anything else?
> 
> I believe we need a Fedora administrator of some kind to
> untag it.
> 
> The bigger problem is how can we build util-linux against the new
> library.  I guess pcre2 will have to supply a compat subpackage ...

util-linux should be ready to be build without pcre2-posix, it uses
old good regex.h as a fallback solution if there is no libpcre2-posix.pc.

I'm able to locally compile upstream tree without libpcre2-posix.pc.

 Karel

-- 
 Karel Zak  
 http://karelzak.blogspot.com
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Stephen John Smoogen]

On Wed, 16 Jun 2021 at 04:29, Daniel P. Berrangé 
wrote:

> On Tue, Jun 15, 2021 at 05:34:02PM -0400, Neal Gompa wrote:
> > Hey all,
> >
> > Earlier this week, I was helping with processing features for openSUSE
> > Leap 15.4[1] and I discovered that they're planning on introducing
> > x86_64-v2 to openSUSE soon. The reference for this change was that
> > RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions
> > have been considering bumping up to v2 or v3[3][4].
> >
> > Some cursory examination of the new x86_64 sublevels seem to indicate
> > that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the
> > first couple of generations of x86_64 CPUs from Intel and AMD. I
> > personally don't have any computers that don't have support for
> > x86_64-v2 anymore.
>
> Yes, you loose primarily Intel Conroe and Penryn generations and
> AMD Opteron Gen 1 -> Gen 3. I doubt this is a significant portion
> of Fedora installs.
>
> Slight tangent but I find Fedora's approach to hardware somewhat
> at odds with our approach to software.
>
> On the one hand we portray our project as a place for cutting
> edge Linux software & innovation.
>
> On the other hand we hold back our software by trying to keep
> supporting long obsolete hardware.
>
>
I think it comes down to what various people who maintain or help maintain
large amounts of hardware have available to use or feel comfortable using.
People in academia usually have tight capex budgets and when they get a
system they like, they are probably going to be using it for decades.
[Queue several universities in the last 10 years I have seen where people
have computers older than they are on their desks as their work computer.]
Other people have other concerns and find newer systems not able to meet
them (screen may be wrong, keyboard feels wrong, their lab is still running
N year old hardware etc.) [Looking at the many internal mailing lists where
people would prefer not to have their hardware updated every 3 years but
still pine for that 10 year old computer they started with and none of the
others have been as good as.]

Finally, most of the changes in the architecture code don't really make
things 'faster' in ways that 'matter'. Using AVX2 versus SSE2 versus SSE
does not make compilations faster



> There is of course always a balance between bumping min hardware
> specs and the impact on maintainers & users, but I'm not convinced
> that we have the balance right in targeting our x86_64 baseline at
> the very first generation of 64-bit CPUs from 15 years ago. I can't
> imagine such old CPUs makes up a significant portion of our users.
>
>
In this case it doesn't 'matter' it is a small segment of users. It is a
segment of our maintainers who are. We either have to listen to them, 'fire
them', or buy them replacement hardware. Since we are already overloaded,
firing them has not been on the table. Buying replacement hardware is
expensive in multiple ways (time, capex, and various legal aspects). That
leaves listening to the maintainers.



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law.
All those moments will be lost in time... like posts on  BBS... time to
reboot.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Florian Weimer]

* Stephen John Smoogen:

> I used this
> https://unix.stackexchange.com/questions/631217/how-do-i-check-if-my-cpu-supports-x86-64-v2
> to see what cpu instructions are at each level
>
> ```
> #!/usr/bin/awk -f
>
> BEGIN {
> while (!/flags/) if (getline < "/proc/cpuinfo" != 1) exit 1
> if (/lm/&&/cmov/&&/cx8/&&/fpu/&&/fxsr/&&/mmx/&&/syscall/&&/sse2/) level = 
> 1
> if (level == 1 && /cx16/&&/lahf/&&/popcnt/&&/sse4_1/&&/sse4_2/&&/ssse3/) 
> level = 2
> if (level == 2 && 
> /avx/&&/avx2/&&/bmi1/&&/bmi2/&&/f16c/&&/fma/&&/abm/&&/movbe/&&/xsave/) level 
> = 3
> if (level == 3 && 
> /avx512f/&&/avx512bw/&&/avx512cd/&&/avx512dq/&&/avx512vl/) level = 4
> if (level > 0) { print "CPU supports x86-64-v" level; exit level + 1 }
> exit 1
> }
> ```

Hmm.  I believe the script is almost correct, not sure about “xsave” part.
The “fma” match is problematic because it also applies to “fma4”, which
is definitely not correct.

On Fedora 34 or later, you can use “/lib64/ld-linux-x86-64.so.2 --help”.
If x86-64-v2 shows up as “supported”, there is compatibile:

| Subdirectories of glibc-hwcaps directories, in priority order:
|   x86-64-v4
|   x86-64-v3 (supported, searched)
|   x86-64-v2 (supported, searched)

On older Fedora, you can run:

  podman run fedora:latest /lib64/ld-linux-x86-64.so.2 --help

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Rubygem package smoke testing [was: Re: F35 Change: Python Packaging Guidelines overhaul (System-Wide Change proposal)]

[Vít Ondruch]

Dne 16. 06. 21 v 13:36 Ewoud Kohl van Wijngaarden napsal(a):

On Wed, Jun 16, 2021 at 01:17:31PM +0200, Vít Ondruch wrote:


Dne 15. 06. 21 v 19:34 Ewoud Kohl van Wijngaarden napsal(a):

On Tue, Jun 15, 2021 at 01:51:12PM +0200, Miro Hrončok wrote:

On 15. 06. 21 13:46, Vitaly Zaitsev via devel wrote:

If that is not possible with reasonable effort,
at least a basic smoke test (such as importing the packaged module)
*MUST* be run in `+%check+`.


A simple scriplet should be introduced I think:

%check
%do_import_test


Already on it:
https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/99


This may be not be the right place, but in Foreman's Ruby packaging 
we've also felt a similar pain. Mostly with C extensions that were 
built in the wrong directory. We also added a %check section to do a 
basic "import" (require) test.


Is there a similar macro for Ruby smoke testing?



No, there is no similar macro for Ruby. Historically, it was not 
clear what should be actually required. With Bundler putting into 
place more conventions, the situation is better.


Nevertheless, what is the specific issue you are referring to above? 
There are many examples of fixing such issue, e.g.


https://src.fedoraproject.org/rpms/rubygem-bcrypt/blob/rawhide/f/rubygem-bcrypt.spec#_52 



And there are probably more complex cases.


Perhaps we should take this to a separate discussion, but we found 
that there are various bugs in SCL macros that s.o ended up in the 
wrong directories so it wouldn't load.



SCLs or not, this is what always happens for several reasons:

1) While upstream leaves the .so files along side other parts of the 
library, we place the platform independent code in /usr/share while 
placing the platform dependent code into /usr/lib. This is done via [1] 
and it was actually supposed to be default in RubyGems 3, but 
unfortunately with change of upstream maintainers, it got forgotten [2].


2) The paths used during rpmbuild are never on Ruby LOAD_PATH. Upstream 
might add the `lib` directory on the load path, which be defaults 
contains the .so file. But that is not case on Fedora as I explained in 
(1), therefore it is always necessary to add the directory with .so file 
on the LOAD_PATH explicitly.


In theory, we could somehow extend the GEM_PATH to include the RPM 
directories, but upstream test suites are not prepared for this 
scenario, so it would not help.



Really, majority of Ruby packages has fragments like `-Ilib` or 
`-Ilib:test` in the `%check` section. This is grep across the Fedora 
.spec files [3]:


~~~

$ find . -name rubygem\* -exec grep ' \-I' {} \; | wc -l
311

~~~

You just need to add the path to the .so file on the LOAD_PATH similarly.


Vít



[1] 
https://src.fedoraproject.org/rpms/ruby/blob/rawhide/f/operating_system.rb#_143


[2] 
https://src.fedoraproject.org/rpms/ruby/blob/rawhide/f/operating_system.rb#_138


[3] https://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz


___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Rawhide-20210616.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
4 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 27/134 (aarch64), 22/198 (x86_64)

New failures (same test not failed in Fedora-Rawhide-20210615.n.1):

ID: 909564  Test: aarch64 Minimal-raw_xz-raw.xz base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/909564
ID: 909578  Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/909578
ID: 909742  Test: aarch64 universal install_simple_free_space@uefi
URL: https://openqa.fedoraproject.org/tests/909742
ID: 909763  Test: aarch64 universal install_serial_console@uefi
URL: https://openqa.fedoraproject.org/tests/909763

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

ID: 909457  Test: x86_64 Server-dvd-iso server_remote_logging_server
URL: https://openqa.fedoraproject.org/tests/909457
ID: 909458  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/909458
ID: 909471  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/909471
ID: 909478  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/909478
ID: 909479  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/909479
ID: 909480  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/909480
ID: 909488  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/909488
ID: 909492  Test: x86_64 Server-dvd-iso server_remote_logging_client
URL: https://openqa.fedoraproject.org/tests/909492
ID: 909495  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/909495
ID: 909540  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/909540
ID: 909554  Test: x86_64 Cloud_Base-qcow2-qcow2 base_package_install_remove
URL: https://openqa.fedoraproject.org/tests/909554
ID: 909555  Test: x86_64 Cloud_Base-qcow2-qcow2 base_service_manipulation
URL: https://openqa.fedoraproject.org/tests/909555
ID: 909556  Test: x86_64 Cloud_Base-qcow2-qcow2 base_reboot_unmount
URL: https://openqa.fedoraproject.org/tests/909556
ID: 909557  Test: x86_64 Cloud_Base-qcow2-qcow2 base_services_start
URL: https://openqa.fedoraproject.org/tests/909557
ID: 909558  Test: x86_64 Cloud_Base-qcow2-qcow2 base_selinux
URL: https://openqa.fedoraproject.org/tests/909558
ID: 909559  Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud **GATING**
URL: https://openqa.fedoraproject.org/tests/909559
ID: 909560  Test: x86_64 Cloud_Base-qcow2-qcow2 base_system_logging
URL: https://openqa.fedoraproject.org/tests/909560
ID: 909561  Test: x86_64 Cloud_Base-qcow2-qcow2 base_update_cli
URL: https://openqa.fedoraproject.org/tests/909561
ID: 909584  Test: aarch64 Server-dvd-iso server_remote_logging_server@uefi
URL: https://openqa.fedoraproject.org/tests/909584
ID: 909594  Test: aarch64 Server-dvd-iso 
server_role_deploy_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/909594
ID: 909603  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_master@uefi
URL: https://openqa.fedoraproject.org/tests/909603
ID: 909604  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_replica@uefi
URL: https://openqa.fedoraproject.org/tests/909604
ID: 909605  Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/909605
ID: 909606  Test: aarch64 Server-dvd-iso server_remote_logging_client@uefi
URL: https://openqa.fedoraproject.org/tests/909606
ID: 909615  Test: aarch64 Server-dvd-iso realmd_join_sssd@uefi
URL: https://openqa.fedoraproject.org/tests/909615
ID: 909616  Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/909616
ID: 909617  Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/909617
ID: 909618  Test: aarch64 Server-dvd-iso 
server_freeipa_replication_client@uefi
URL: https://openqa.fedoraproject.org/tests/909618
ID: 909643  Test: aarch64 Cloud_Base-qcow2-qcow2 
base_package_install_remove@uefi
URL: https://openqa.fedoraproject.org/tests/909643
ID: 909644  Test: aarch64 Cloud_Base-qcow2-qcow2 base_reboot_unmount@uefi
URL: https://openqa.fedoraproject.org/tests/909644
ID: 909645  Test: aarch64 Cloud_Base-qcow2-qcow2 base_services_start@uefi
URL: https://openqa.fedoraproject.org/tests/909645
ID: 909646  Test: aarch64 Cloud_Base-qcow2-qcow2 base_selinux@uefi
URL: https://openqa.fedoraproject.org/tests/909646
ID: 909647  Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_auto

Re: Experience on src.fedoraproject.org as non-packager

[Ankur Sinha]

On Wed, Jun 16, 2021 14:03:26 +0200, Ewoud Kohl van Wijngaarden wrote:
> Hello everyone,

Hi Ewoud,

> Even though I've now been sponsored as a packager, I did want to share my
> experience since it was a bit frustrating.
> 
> If you do have a FAS account, you can log in on src.fedoraproject.org and
> can even fork repositories. However, on the clone URL you only see the
> anonymous git URL. That means you have no way to push changes to your fork.
> That also means you can't submit a PR to repositories using your fork. The
> end result is that it's very hard to contribute to repositories.
> 
> My suggestion is to either give non-packagers the URL (and if needed
> permission) to push to their own forks or remove the ability to fork a
> repository.

Thanks for the feedback. Do these instructions not work? They indicate
that one is able to push to their forks. If this doesn't work,
something's broken somewhere and will need looking into.

https://fedoraproject.org/wiki/Package_maintenance_guide#Using_fedpkg_anonymously

(linked from: 
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#One-off_contributions)

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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Peter Boy]

> Am 16.06.2021 um 13:47 schrieb Björn Persson :
>  But I'm already planning to reinstall that one with Debian, 
> ... so it won't hurt me
> if Fedora stops working there.

Do we really want to recommend this to our users?  

The ability to continue using ‚mature', functional hardware was and is one of 
the significant arguments in favor of Linux. 


___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Stephen John Smoogen]

On Wed, 16 Jun 2021 at 08:19, Florian Weimer  wrote:

> * Stephen John Smoogen:
>
> > I used this
> >
> https://unix.stackexchange.com/questions/631217/how-do-i-check-if-my-cpu-supports-x86-64-v2
> > to see what cpu instructions are at each level
> >
> > ```
> > #!/usr/bin/awk -f
> >
> > BEGIN {
> > while (!/flags/) if (getline < "/proc/cpuinfo" != 1) exit 1
> > if (/lm/&&/cmov/&&/cx8/&&/fpu/&&/fxsr/&&/mmx/&&/syscall/&&/sse2/)
> level = 1
> > if (level == 1 &&
> /cx16/&&/lahf/&&/popcnt/&&/sse4_1/&&/sse4_2/&&/ssse3/) level = 2
> > if (level == 2 &&
> /avx/&&/avx2/&&/bmi1/&&/bmi2/&&/f16c/&&/fma/&&/abm/&&/movbe/&&/xsave/)
> level = 3
> > if (level == 3 &&
> /avx512f/&&/avx512bw/&&/avx512cd/&&/avx512dq/&&/avx512vl/) level = 4
> > if (level > 0) { print "CPU supports x86-64-v" level; exit level + 1
> }
> > exit 1
> > }
> > ```
>
> Hmm.  I believe the script is almost correct, not sure about “xsave” part.
> The “fma” match is problematic because it also applies to “fma4”, which
> is definitely not correct.
>
>
I think changing that to /fma[[:space:]]/ would fix that..



> On Fedora 34 or later, you can use “/lib64/ld-linux-x86-64.so.2 --help”.
> If x86-64-v2 shows up as “supported”, there is compatibile:
>
> | Subdirectories of glibc-hwcaps directories, in priority order:
> |   x86-64-v4
> |   x86-64-v3 (supported, searched)
> |   x86-64-v2 (supported, searched)
>
> On older Fedora, you can run:
>
>   podman run fedora:latest /lib64/ld-linux-x86-64.so.2 --help
>
>
oh cool. this even works on CentOS and RHEL systems:
```
smooge@xanadu ~]$ podman run fedora:latest /lib64/ld-linux-x86-64.so.2
--help
...
Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)

Legacy HWCAP subdirectories under library search path directories:
  haswell (AT_PLATFORM; supported, searched)
  tls (supported, searched)
  avx512_1
  x86_64 (supported, searched)
[smooge@xanadu ~]$ uname -a
Linux xanadu.int.smoogespace.com 4.18.0-305.0.1.el8.x86_64 #1 SMP Fri May
28 11:04:28 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
```
from my oldest system.


> Thanks,
> Florian
>
>

-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law.
All those moments will be lost in time... like posts on  BBS... time to
reboot.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Frantisek Zatloukal]

On Wed, Jun 16, 2021 at 2:20 PM Florian Weimer  wrote:

> On Fedora 34 or later, you can use “/lib64/ld-linux-x86-64.so.2 --help”.
> If x86-64-v2 shows up as “supported”, there is compatibile:
>
> | Subdirectories of glibc-hwcaps directories, in priority order:
> |   x86-64-v4
> |   x86-64-v3 (supported, searched)
> |   x86-64-v2 (supported, searched)
>
>
Hmm, I am wondering if we can't use output from that and gather this
information as a part of DNF Count Me?

We'll at least gather information about capabilities of Fedora users
hardware.


-- 

Best regards / S pozdravem,

František Zatloukal
Quality Engineer
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Stephen John Smoogen]

On Wed, 16 Jun 2021 at 08:16, Stephen John Smoogen  wrote:

>
>
> On Wed, 16 Jun 2021 at 04:29, Daniel P. Berrangé 
> wrote:
>
>> On Tue, Jun 15, 2021 at 05:34:02PM -0400, Neal Gompa wrote:
>> > Hey all,
>> >
>> > Earlier this week, I was helping with processing features for openSUSE
>> > Leap 15.4[1] and I discovered that they're planning on introducing
>> > x86_64-v2 to openSUSE soon. The reference for this change was that
>> > RHEL 9 is going to use x86_64-v2[2]. Additionally, other distributions
>> > have been considering bumping up to v2 or v3[3][4].
>> >
>> > Some cursory examination of the new x86_64 sublevels seem to indicate
>> > that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the
>> > first couple of generations of x86_64 CPUs from Intel and AMD. I
>> > personally don't have any computers that don't have support for
>> > x86_64-v2 anymore.
>>
>> Yes, you loose primarily Intel Conroe and Penryn generations and
>> AMD Opteron Gen 1 -> Gen 3. I doubt this is a significant portion
>> of Fedora installs.
>>
>> Slight tangent but I find Fedora's approach to hardware somewhat
>> at odds with our approach to software.
>>
>> On the one hand we portray our project as a place for cutting
>> edge Linux software & innovation.
>>
>> On the other hand we hold back our software by trying to keep
>> supporting long obsolete hardware.
>>
>>
> I think it comes down to what various people who maintain or help maintain
> large amounts of hardware have available to use or feel comfortable using.
> People in academia usually have tight capex budgets and when they get a
> system they like, they are probably going to be using it for decades.
> [Queue several universities in the last 10 years I have seen where people
> have computers older than they are on their desks as their work computer.]
> Other people have other concerns and find newer systems not able to meet
> them (screen may be wrong, keyboard feels wrong, their lab is still running
> N year old hardware etc.) [Looking at the many internal mailing lists where
> people would prefer not to have their hardware updated every 3 years but
> still pine for that 10 year old computer they started with and none of the
> others have been as good as.]
>
> Finally, most of the changes in the architecture code don't really make
> things 'faster' in ways that 'matter'. Using AVX2 versus SSE2 versus SSE
> does not make compilations faster
>
>
sorry my editing skills are poor this morning. I meant that things like
compilations, tools and graphics don't really increase for the things that
maintainers care about.

-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law.
All those moments will be lost in time... like posts on  BBS... time to
reboot.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Peter Boy]

> Am 16.06.2021 um 14:16 schrieb Stephen John Smoogen :
> 
> 
> 
> …
> feel comfortable using. People in academia usually have tight capex budgets

++1

As an example, we have still to use as a server for production

> [root@hydra ~]# cat /proc/cpuinfo
> processor : 0
> vendor_id : GenuineIntel
> cpu family: 6
> model : 23
> model name: Intel(R) Xeon(R) CPU   E5440  @ 2.83GHz
> stepping  : 6
> ...
> cpuid level   : 10
> wp: yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
> pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm 
> constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 
> monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 lahf_lm pti 
> tpr_shadow vnmi flexpriority vpid dtherm
> 


The machine is an IBM blade center from shortly after 2010. It's not 
necessarily a joy, but it's not a particular limitation for mail and web. 

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Vitaly Zaitsev via devel]

On 16.06.2021 14:45, Frantisek Zatloukal wrote:
We'll at least gather information about capabilities of Fedora users 
hardware.


Telemetry is evil. It must not be allowed.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Neal Gompa]

On Wed, Jun 16, 2021 at 8:57 AM Vitaly Zaitsev via devel
 wrote:
>
> On 16.06.2021 14:45, Frantisek Zatloukal wrote:
> > We'll at least gather information about capabilities of Fedora users
> > hardware.
>
> Telemetry is evil. It must not be allowed.
>

So how do you propose we figure out what kind of hardware we need to
work with, further develop, or such? We used such telemetry in the
past to do targeted improvements to hardware support (cf Smolt and
graphics support).



-- 
真実はいつも一つ！/ 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Experience on src.fedoraproject.org as non-packager

[Ewoud Kohl van Wijngaarden]

On Wed, Jun 16, 2021 at 01:33:08PM +0100, Ankur Sinha wrote:

On Wed, Jun 16, 2021 14:03:26 +0200, Ewoud Kohl van Wijngaarden wrote:

Hello everyone,


Hi Ewoud,


Even though I've now been sponsored as a packager, I did want to share my
experience since it was a bit frustrating.

If you do have a FAS account, you can log in on src.fedoraproject.org and
can even fork repositories. However, on the clone URL you only see the
anonymous git URL. That means you have no way to push changes to your fork.
That also means you can't submit a PR to repositories using your fork. The
end result is that it's very hard to contribute to repositories.

My suggestion is to either give non-packagers the URL (and if needed
permission) to push to their own forks or remove the ability to fork a
repository.


Thanks for the feedback. Do these instructions not work? They indicate
that one is able to push to their forks. If this doesn't work,
something's broken somewhere and will need looking into.

https://fedoraproject.org/wiki/Package_maintenance_guide#Using_fedpkg_anonymously

(linked from: 
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#One-off_contributions)


Interesting, I had not tried that.

What I used was the clone button. That shows a small dialog with this 
(as packager):


   Source Code

 SSH 
 GIT 

As non-packager it does NOT have the SSH URL. So what I initially did 
was to manually clone it with git, not fedpkg. Then you have no way to 
push.


It looks like fedpkg clone does configure a credential helper which 
probably allows you to push via SSH.


It would be my recommendation to add a third "URL" to it and that's the 
fedpkg command to clone.


If a non-packager can push using SSH, I would also add that URL 
unconditonally. I could not find the URL as non-packager so I can't say 
if you have that permission. It would make sense to me that you do.


This may be difficult. It looks like this is the relevant template:

https://pagure.io/pagure/blob/master/f/pagure/templates/repo_master.html

That suggests it can't easily be modified just for Fedora.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Vitaly Zaitsev via devel]

On 16.06.2021 15:00, Neal Gompa wrote:

So how do you propose we figure out what kind of hardware we need to
work with, further develop, or such?


No way. And that's fine.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-IoT-35-20210616.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 2/16 (x86_64), 3/15 (aarch64)

Old failures (same test failed in Fedora-IoT-35-20210613.0):

ID: 909778  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_server
URL: https://openqa.fedoraproject.org/tests/909778
ID: 909779  Test: x86_64 IoT-dvd_ostree-iso iot_zezere_ignition
URL: https://openqa.fedoraproject.org/tests/909779
ID: 909794  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_server@uefi
URL: https://openqa.fedoraproject.org/tests/909794
ID: 909797  Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/909797
ID: 909806  Test: aarch64 IoT-dvd_ostree-iso iot_zezere_ignition@uefi
URL: https://openqa.fedoraproject.org/tests/909806

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

Old soft failures (same test soft failed in Fedora-IoT-35-20210613.0):

ID: 909776  Test: x86_64 IoT-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/909776
ID: 909783  Test: x86_64 IoT-dvd_ostree-iso iot_clevis
URL: https://openqa.fedoraproject.org/tests/909783
ID: 909787  Test: x86_64 IoT-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/909787
ID: 909792  Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/909792

Passed openQA tests: 11/15 (aarch64), 11/16 (x86_64)

New passes (same test not passed in Fedora-IoT-35-20210613.0):

ID: 909802  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_overlay@uefi
URL: https://openqa.fedoraproject.org/tests/909802
ID: 909804  Test: aarch64 IoT-dvd_ostree-iso iot_rpmostree_rebase@uefi
URL: https://openqa.fedoraproject.org/tests/909804

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default_upload: 
Used mem changed from 197 MiB to 177 MiB
System load changed from 0.45 to 0.20
Previous test data: https://openqa.fedoraproject.org/tests/906997#downloads
Current test data: https://openqa.fedoraproject.org/tests/909776#downloads

Installed system changes in test x86_64 IoT-dvd_ostree-iso 
install_default@uefi: 
Used mem changed from 198 MiB to 178 MiB
Previous test data: https://openqa.fedoraproject.org/tests/907008#downloads
Current test data: https://openqa.fedoraproject.org/tests/909787#downloads

Installed system changes in test aarch64 IoT-dvd_ostree-iso 
install_default_upload@uefi: 
Used mem changed from 214 MiB to 191 MiB
System load changed from 0.91 to 0.31
Previous test data: https://openqa.fedoraproject.org/tests/907013#downloads
Current test data: https://openqa.fedoraproject.org/tests/909792#downloads
-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Stephen John Smoogen]

On Wed, 16 Jun 2021 at 08:46, Frantisek Zatloukal 
wrote:

>
>
> On Wed, Jun 16, 2021 at 2:20 PM Florian Weimer  wrote:
>
>> On Fedora 34 or later, you can use “/lib64/ld-linux-x86-64.so.2 --help”.
>> If x86-64-v2 shows up as “supported”, there is compatibile:
>>
>> | Subdirectories of glibc-hwcaps directories, in priority order:
>> |   x86-64-v4
>> |   x86-64-v3 (supported, searched)
>> |   x86-64-v2 (supported, searched)
>>
>>
> Hmm, I am wondering if we can't use output from that and gather this
> information as a part of DNF Count Me?
>
> We'll at least gather information about capabilities of Fedora users
> hardware.
>
>
Not really.. adding in exact architectures and stuff starts getting into
areas where GDPR and similar regulations consider profiling even if it
isn't easy for us or what we want to do. [And no it doesn't matter if
people who have read the various regulations say that isn't really what
GDPR says.. the courts and lawyers have said that once you add in all the
back laws, rulings and other things.. it is what the GDPR (and other laws)
become. ]

At best we can try some sort of 'volunteer' popcorn/smolt system, but it is
rife with needing to design in 2 things common with them:
1. The information being given is going to be abused by malefactors  so you
need to make sure it is filtered.
2. The information even if volunteered can and must be expunged when the
volunteer wants it to be.

Those two items are a lot of work which usually is more than anyone wants
to put into a survey system.

-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law.
All those moments will be lost in time... like posts on  BBS... time to
reboot.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Introduction: Trevor McKay

[Trevor McKay]

> Welcome!

Thanks!

> I think Fedora has pretty nice Python packaging and I think rust skills are 
> also
> a welcome addition as there is a growing number of rust software in the open
> source ecosystem.
>
> You can check out the SIG pages for Rust+Python. There are separate mailing
> lists for these SIGs (though fedora-devel works as well):
>
> https://fedoraproject.org/wiki/SIGs/Python
> https://fedoraproject.org/wiki/SIGs/Rust

This looks great. I'm gonna start getting familiar with these SIGs and
I'm sure I can find something to work on. Thanks for the thorough
response Felix!


Trevor

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Introduction: Trevor McKay

[Robert-André Mauchin]

On 6/16/21 5:11 AM, Trevor McKay wrote:

Hello everyone,

My name is Trevor and I was hoping to contribute to the Fedora project
in the form of packaging. I was told the first step would be to
introduce myself here. I have a few years of Linux experience as well as
Rust, Python and C/C++ development. I am, however, completely new to
packaging and contributing to open-source, so any advice is very much
welcome.

I am interested in packing `bottom`, a package for system monitoring
that I find fairly useful. I'd also be cool with picking up an abandoned
package, if anything is desperately needed. Come to think of it, I would
also like to do some development work, but I figured packaging was a
good start. Anyway, just looking to contribute where I can.

Cheers,
Trevor mcKay


Welcome Trevor, don't hesitate to ask for help o/
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Introduction: Trevor McKay

[Major Hayden]

On 6/15/21 10:11 PM, Trevor McKay wrote:

Hello everyone,

My name is Trevor and I was hoping to contribute to the Fedora project
in the form of packaging. I was told the first step would be to
introduce myself here. I have a few years of Linux experience as well as
Rust, Python and C/C++ development. I am, however, completely new to
packaging and contributing to open-source, so any advice is very much
welcome.


Welcome to the fun! 🎉

Give us a shout if you need anything along the way.

--
Major Hayden


OpenPGP_0x737051E0C1011FB1.asc
Description: OpenPGP public key


OpenPGP_signature
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[przemek klosowski via devel]

On 6/16/21 8:45 AM, Stephen John Smoogen wrote:

oh cool. this even works on CentOS and RHEL systems:
```
smooge@xanadu ~]$ podman run fedora:latest /lib64/ld-linux-x86-64.so.2 
--help

...
Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)

Legacy HWCAP subdirectories under library search path directories:
  haswell (AT_PLATFORM; supported, searched)
  tls (supported, searched)
  avx512_1
  x86_64 (supported, searched)
[smooge@xanadu ~]$ uname -a
Linux xanadu.int.smoogespace.com 
 
4.18.0-305.0.1.el8.x86_64 #1 SMP Fri May 28 11:04:28 UTC 2021 x86_64 
x86_64 x86_64 GNU/Linux

```
from my oldest system.


I'm missing something---I get identicaloutput on my v3 Core i7-4810MQ

Is this supposed to run HWCAP and show the result, or just show the 
HWCAP configuration and possible choices?


___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

rpmautospec deployment into production

[Nils Philippsen]

Hi everybody,

we've scheduled the rpmautospec plugin to be deployed into production
for tomorrow, from 14:00 UTC on.

This means installing the relevant packages and restarting kojid
processes on the builders, which will restart any tasks which are being
processed at that time, i.e. expect delays for builds in-flight at the
time.

We'll announce when the deployment is done.

Cheers,
Nils
-- 
Nils Philippsen "Those who would give up Essential Liberty to
Software Engineer purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: D0C1 1576 CDA6 5B6E BBAE 95B2 7D53 7FCA E9F6 395D
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Florian Weimer]

* Neal Gompa:

> On Wed, Jun 16, 2021 at 8:57 AM Vitaly Zaitsev via devel
>  wrote:
>>
>> On 16.06.2021 14:45, Frantisek Zatloukal wrote:
>> > We'll at least gather information about capabilities of Fedora users
>> > hardware.
>>
>> Telemetry is evil. It must not be allowed.
>>
>
> So how do you propose we figure out what kind of hardware we need to
> work with, further develop, or such? We used such telemetry in the
> past to do targeted improvements to hardware support (cf Smolt and
> graphics support).

We can change glibc to enforce hardware requirements before the entire
distribution and see how many people complain.  This way, going back to
the earlier state doesn't require a fresh mass rebuild.

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Florian Weimer]

* przemek klosowski via devel:

> I'm missing something---I get identicaloutput on my v3 Core i7-4810MQ

Why do you expect different output?

> Is this supposed to run HWCAP and show the result, or just show the
> HWCAP configuration and possible choices?

It shows capabilities (as defined by the hardware, the kernel and glibc)
and indicates which are supported in the current execution environment.

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[przemek klosowski via devel]

On 6/16/21 12:09 PM, Florian Weimer wrote

I'm missing something---I get identicaloutput on my v3 Core i7-4810MQ

Why do you expect different output?


Stephen was showing off his 'oldest' system and I assumed that it was 
some Penryn-era relic, so I expected a <= v1 result. One cohort of 
people in this discussion argue that even the oldest systems are quite 
capable, and another cohort argues the opposite by showing off their 
'black beauty' (CarTalk(TM)) antiques that they are loathe to retire. I 
mistook Stephen for the latter :)


In my limited understanding of HWCAPs, it run-time switches between 
different code paths for differently capable exec environments---and 
misreading Stephen's post made me wonder if it somehow emulates the 
newer ones, which didn't make sense.


___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Can't login with kinit using 2FA

[Kevin Fenzi]

On Wed, Jun 16, 2021 at 01:24:58PM +0200, Vít Ondruch wrote:
> 
> Dne 15. 06. 21 v 23:26 Michael Catanzaro napsal(a):
> > On Tue, Jun 15 2021 at 09:18:34 PM +0200, Dan Horák  wrote:
> > > make sure you have the fedora-packager-kerberos package installed, I
> > > suspect the last update of fedora-packager wasn't right
> > 
> > Whatever is needed for Fedora kerberos to work needs to be a dependency
> > of gnome-online-accounts, since Fedora account is a supported account
> > type there. You shouldn't need to install anything extra.

Well, it depends (see below)

> > 
> > FWIW I don't have fedora-packager-kerberos installed, and kerberos is
> > still working perfectly fine for me as of today.

It depends on if you have a OTP enrolled or not. 

> It depends how recent your Fedora is. Neither I had installed
> fedora-packager-kerberos up until yesterday, because the package is quite
> fresh:
> 
> https://src.fedoraproject.org/rpms/fedora-packager/c/a7fde86069c3595fdaf8b7bcfe22c231f55b48de?branch=rawhide
> 
> So can I uninstall it if I am using GOA?

If you do not have a OTP enrolled: yes. Everything is as it was before,
you can let GOA handle things and it will work fine. 

If you DO have a OTP enrolled, GOA won't work at all and you will need
to have fedora-packager-kerberos installed and manually use 'fkinit' to
get a ticket. 

I think there are plans to improve this use case in krb5 utils. 
I suppose we could also see if GOA could support this case somehow and
add a dep on fedora-packager-kerberos. Where should I file that? gitlab?
Or would someone else like to do so?

kevin


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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Experience on src.fedoraproject.org as non-packager

[Kevin Fenzi]

On Wed, Jun 16, 2021 at 03:05:59PM +0200, Ewoud Kohl van Wijngaarden wrote:
> Interesting, I had not tried that.
> 
> What I used was the clone button. That shows a small dialog with this (as
> packager):
> 
>Source Code
> 
>  SSH 
>  GIT 
> 
> As non-packager it does NOT have the SSH URL. So what I initially did was to
> manually clone it with git, not fedpkg. Then you have no way to push.

You can stll use 'fedpkg push' in this case and it will setup things and
push. But you have to use fedpkg for one of clone/push. 

> 
> It looks like fedpkg clone does configure a credential helper which probably
> allows you to push via SSH.

It's via https and a token. fedpkg sets up the token for you. After the
initial setup in fedpkg, you can use normal git for everything. 

> It would be my recommendation to add a third "URL" to it and that's the
> fedpkg command to clone.

Yeah, might be a reasonable idea indeed. Can you file a issue at
https://pagure.io/pagure/issues/ ?

> If a non-packager can push using SSH, I would also add that URL
> unconditonally. I could not find the URL as non-packager so I can't say if
> you have that permission. It would make sense to me that you do.

non-packager cannot push via ssh at all. 

> This may be difficult. It looks like this is the relevant template:
> 
> https://pagure.io/pagure/blob/master/f/pagure/templates/repo_master.html
> 
> That suggests it can't easily be modified just for Fedora.

Yeah, might need some configurability added. 

kevin


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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Can't login with kinit using 2FA

[Vít Ondruch]

Dne 16. 06. 21 v 18:54 Kevin Fenzi napsal(a):

On Wed, Jun 16, 2021 at 01:24:58PM +0200, Vít Ondruch wrote:

Dne 15. 06. 21 v 23:26 Michael Catanzaro napsal(a):

On Tue, Jun 15 2021 at 09:18:34 PM +0200, Dan Horák  wrote:

make sure you have the fedora-packager-kerberos package installed, I
suspect the last update of fedora-packager wasn't right

Whatever is needed for Fedora kerberos to work needs to be a dependency
of gnome-online-accounts, since Fedora account is a supported account
type there. You shouldn't need to install anything extra.

Well, it depends (see below)


FWIW I don't have fedora-packager-kerberos installed, and kerberos is
still working perfectly fine for me as of today.

It depends on if you have a OTP enrolled or not.


It depends how recent your Fedora is. Neither I had installed
fedora-packager-kerberos up until yesterday, because the package is quite
fresh:

https://src.fedoraproject.org/rpms/fedora-packager/c/a7fde86069c3595fdaf8b7bcfe22c231f55b48de?branch=rawhide

So can I uninstall it if I am using GOA?

If you do not have a OTP enrolled: yes. Everything is as it was before,
you can let GOA handle things and it will work fine.



I don't have enrolled my OTP. I am afraid, that once I enroll my OPT, 
I'd need to use it every time to refresh my kerberos ticket. That would 
destroy the GOA experience.


If I needed to confirm myself with OTP once in a while, that would be 
different story.



Vít




If you DO have a OTP enrolled, GOA won't work at all and you will need
to have fedora-packager-kerberos installed and manually use 'fkinit' to
get a ticket.

I think there are plans to improve this use case in krb5 utils.
I suppose we could also see if GOA could support this case somehow and
add a dep on fedora-packager-kerberos. Where should I file that? gitlab?
Or would someone else like to do so?

kevin

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Date format

[Rémi Lauzier via devel]

So it seem that the date format for changelog in .spec file are somewhat 
different between package. Rust2rpm produce a format, the same that automatic 
scratch build produce. But there are developer that use another format in there 
package.
https://src.fedoraproject.org/rpms/rust-owned_ttf_parser/pull-request/1

Maybe fedora should have a standard to follow to have less confusion between 
packager and reduce the burden to know the preference of the packager of each 
package.

i have no preference over one another, be it without precise time or with it 
down to the seconds. I think fedora should have a standard to follow.

Sent with ProtonMail Secure Email.

publickey - remilauzier@protonmail.com - 0xC69091A8.asc
Description: application/pgp-keys


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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Stephen John Smoogen]

On Wed, 16 Jun 2021 at 12:45, przemek klosowski via devel
 wrote:
>
>
> On 6/16/21 12:09 PM, Florian Weimer wrote
> >> I'm missing something---I get identicaloutput on my v3 Core i7-4810MQ
> > Why do you expect different output?
>
> Stephen was showing off his 'oldest' system and I assumed that it was
> some Penryn-era relic, so I expected a <= v1 result. One cohort of
> people in this discussion argue that even the oldest systems are quite
> capable, and another cohort argues the opposite by showing off their
> 'black beauty' (CarTalk(TM)) antiques that they are loathe to retire. I
> mistook Stephen for the latter :)
>

Sorry I did not give enough information. I was mainly using it to show
that the command Florian gave works on CentOS-8 systems. That said, I
thought my oldest system was a 2009 system but it turns out it is a
2012 system. [I forgot the 2009 system lost some capacitors a couple
of years ago.]

> In my limited understanding of HWCAPs, it run-time switches between
> different code paths for differently capable exec environments---and
> misreading Stephen's post made me wonder if it somehow emulates the
> newer ones, which didn't make sense.
>
> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on  BBS...
time to reboot.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Can't login with kinit using 2FA

[Michael Catanzaro]

On Wed, Jun 16 2021 at 07:16:09 PM +0200, Vít Ondruch 
 wrote:
I don't have enrolled my OTP. I am afraid, that once I enroll my OPT, 
I'd need to use it every time to refresh my kerberos ticket. That 
would destroy the GOA experience.


The other problem is that once you enroll an OTP, it's not possible to 
remove it. Hence, I've been afraid to enable it. I'd like to be able to 
change my mind later. I never even considered that g-o-a wouldn't be 
able to handle it, but I guess now that it's been pointed out, this 
should be pretty obvious. It doesn't have any way to store anything 
other than a static password, so of course it would not work. I would 
be *very* unhappy had I turned on the OTP, discovered it broke g-o-a, 
and then found myself unable to downgrade.


Michael

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Can't login with kinit using 2FA

[Michael Catanzaro]

On Wed, Jun 16 2021 at 09:54:02 AM -0700, Kevin Fenzi  
wrote:

I think there are plans to improve this use case in krb5 utils.
I suppose we could also see if GOA could support this case somehow and
add a dep on fedora-packager-kerberos. Where should I file that? 
gitlab?

Or would someone else like to do so?


Do you have an account on GNOME GitLab? That would be the best place. I 
can report it for you if not.


___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Can't login with kinit using 2FA

[Kevin Fenzi]

On Wed, Jun 16, 2021 at 07:16:09PM +0200, Vít Ondruch wrote:
> 
> I don't have enrolled my OTP. I am afraid, that once I enroll my OPT, I'd
> need to use it every time to refresh my kerberos ticket. That would destroy
> the GOA experience.

yes, once enrolled you do have to always use it. 

But you can just not enroll one, it's not at all manditory... 

kevin


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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fwd: OpenSceneGraph and gdal need to be rebuild for Fedora 34

[Jiri Kucera]

Adding devel-list for a broader audience. My side tag will expire for a
couple of days. Can some proven packager add me please to gdal,
OpenSceneGraph, and vtk as a co-maintainer so I can do rebuilds for libgta?

Cheers,
Jiri


-- Forwarded message -
From: Jiri Kucera 
Date: Fri, Jun 11, 2021 at 10:29 AM
Subject: OpenSceneGraph and gdal need to be rebuild for Fedora 34
To: , , 


Hi Sandro, Ralph, and Orion,

I rebuilt[1] libgta with sidetag f34-build-side-42373 for Fedora 34, which
bumps libgta.so.0 to libgta.so.1. Please,
rebuild your packages against this sidetag:
* gdal need to be probably rebased to 3.3.0 (I did a scratch build[2]
against the sidetag from f34 branch and its succeeded, but the scratch
build[3] of OpenSceneGraph failed[4])
* after gdal OpenSceneGraph and vtk need to be rebuilt
* last, opencv need to be rebuilt (I do this by myself)

Regards,
Jiri

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1766154
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=69770320
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=69836182
[4] Excerpt from the mock_output.log:
Error:
 Problem: package gdal-devel-3.2.2-1.fc34.x86_64 requires
libgdal.so.28()(64bit), but none of the providers can be installed

  - package gdal-devel-3.2.2-1.fc34.x86_64 requires gdal-libs(x86-64)
= 3.2.2-1.fc34, but none of the providers can be installed
  - conflicting requests
  - nothing provides libgta.so.0()(64bit) needed by
gdal-libs-3.2.2-1.fc34.x86_64
(try to add '--skip-broken' to skip uninstallable packages)
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Date format

[Fabio Valentini]

On Wed, Jun 16, 2021 at 7:27 PM Rémi Lauzier via devel
 wrote:
>
> So it seem that the date format for changelog in .spec file are somewhat 
> different between package. Rust2rpm produce a format, the same that automatic 
> scratch build produce. But there are developer that use another format in 
> there package.
> https://src.fedoraproject.org/rpms/rust-owned_ttf_parser/pull-request/1
>
> Maybe fedora should have a standard to follow to have less confusion between 
> packager and reduce the burden to know the preference of the packager of each 
> package.
>
> i have no preference over one another, be it without precise time or with it 
> down to the seconds. I think fedora should have a standard to follow.

Well, *technically*, the "old" format without the time and timezone is
the only one that's really supported everywhere, so I guess that's the
standard.
rpmdev-bumpspec changed to use the format with time+timezone for a
while, but was met with harsh opposition, so the change was reverted.
All tools in Fedora - except rust2rpm - use the format without
time+timezone. I just didn't have time to patch rust2rpm to use that
format again too.

Fabio
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fwd: OpenSceneGraph and gdal need to be rebuild for Fedora 34

[Björn 'besser82' Esser]

Am Mittwoch, dem 16.06.2021 um 19:53 +0200 schrieb Jiri Kucera:
> Adding devel-list for a broader audience. My side tag will expire for
> a couple of days. Can some proven packager add me please to gdal,
> OpenSceneGraph, and vtk as a co-maintainer so I can do rebuilds for
> libgta?
> 
> Cheers,
> Jiri
> 
> 
> -- Forwarded message -
> From: Jiri Kucera 
> Date: Fri, Jun 11, 2021 at 10:29 AM
> Subject: OpenSceneGraph and gdal need to be rebuild for Fedora 34
> To: , ,
> 
> 
> 
> Hi Sandro, Ralph, and Orion,
> 
> I rebuilt[1] libgta with sidetag f34-build-side-42373 for Fedora 34,
> which bumps libgta.so.0 to libgta.so.1. Please,
> rebuild your packages against this sidetag:
> * gdal need to be probably rebased to 3.3.0 (I did a scratch build[2]
> against the sidetag from f34 branch and its succeeded, but the scratch
> build[3] of OpenSceneGraph failed[4])
> * after gdal OpenSceneGraph and vtk need to be rebuilt
> * last, opencv need to be rebuilt (I do this by myself)
> 
> Regards,
> Jiri
> 
> [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1766154
> [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=69770320
> [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=69836182
> [4] Excerpt from the mock_output.log:


I'll take care of the needed rebuilds in your sidetag as a
provenpackager, and will give you a short notice, as soon as you can
start rebuilding opencv.

Cheers,
Björn


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fwd: OpenSceneGraph and gdal need to be rebuild for Fedora 34

[Zbigniew Jędrzejewski-Szmek]

Björn answered the other part, so I'm responding to this part:

On Wed, Jun 16, 2021 at 07:53:11PM +0200, Jiri Kucera wrote:
> Can some proven packager add me please to gdal,
> OpenSceneGraph, and vtk as a co-maintainer so I can do rebuilds for libgta?

This is a misconception: provenpackagers can build packages, but they
cannot change ownership or packages. You'll have to ask the owners of those
packages if you want to become comaintainer. (Co-maitainership is generally
encouraged, especially if there are dependendency chains like this.)

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Experience on src.fedoraproject.org as non-packager

[Otto Urpelainen]

Kevin Fenzi kirjoitti 16.6.2021 klo 19.57:

On Wed, Jun 16, 2021 at 03:05:59PM +0200, Ewoud Kohl van Wijngaarden wrote:

It would be my recommendation to add a third "URL" to it and that's the
fedpkg command to clone.


Yeah, might be a reasonable idea indeed. Can you file a issue at
https://pagure.io/pagure/issues/ ?



I like this.

Even better, fedpkg could be the first option, and there could be a 
warning text about the other two saying something like "Pushing to 
Fedora Package Sources requires use of fedpkg". Something simple that 
leads the potential contributors to choose the method that does not lead 
to an auth error later on.


The warning could be hidden in case the user is already in the packagers 
group and has ssh configured, assuming Pagure gets this information from 
Accounts.


Pull requests ("I fixed it") are much preferable over Bugzillas ("could 
you fix it?"), hence creating one should be as easy as possible. They 
are also a low barrier way to get involved in packaging. I am quite sure 
that there are many more people who are willing to submit a PR than 
those who are willing to go through the "find something you use but that 
is not already in the repo, get it reviewed, get sponsored" process 
which is quite intimidating for a newcomer.


Otto
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Benjamin Beasley]

> In this case it doesn't 'matter' it is a small segment of users. It is
> a
> segment of our maintainers who are. We either have to listen to them, 'fire
> them', or buy them replacement hardware. Since we are already overloaded,
> firing them has not been on the table. Buying replacement hardware is
> expensive in multiple ways (time, capex, and various legal aspects). That
> leaves listening to the maintainers.

At the risk of overextending an already well-elaborated thread, I would like to 
point out that my main workstation, for Fedora packaging and other purposes, 
has an Intel Q6600 (Core 2 Quad) that does NOT meet the requirements for 
x86_64-v2. I built it in 2007, and it has exceeded all expectations for how 
long it would remain useful. The desktop I maintain for my parents uses an AMD 
Phenom II X4 965 processor, circa 2009-2010, and it doesn’t support x86_64-v2 
either—but it just keeps on working.

Now, I can afford to replace my own workstation if I must—and I’m planning to 
do so in another year or two when the rolling component shortages settle out a 
little—but I suspect there are still many others like me, some of whom might 
not be in a position to just sigh and buy new hardware. Even for those who can, 
the pandemic and the crypto crazes have made it an exceptionally bad time to be 
forced into an upgrade.
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Matthew Miller]

On Wed, Jun 16, 2021 at 02:57:17PM +0200, Vitaly Zaitsev via devel wrote:
> >We'll at least gather information about capabilities of Fedora
> >users hardware.
> Telemetry is evil. It must not be allowed.

Well, that's certainly A Position. I don't think it's anything nearly so
absolute, though, and depends on what, who, how, why, and a host of other
things. And "it can help us answer questions like this for our community" is
a pretty non-evil "why".



-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Fabio Valentini]

On Wed, Jun 16, 2021 at 9:52 PM Benjamin Beasley
 wrote:
>
> At the risk of overextending an already well-elaborated thread, I would like 
> to point out that my main workstation, for Fedora packaging and other 
> purposes, has an Intel Q6600 (Core 2 Quad) that does NOT meet the 
> requirements for x86_64-v2. I built it in 2007, and it has exceeded all 
> expectations for how long it would remain useful. The desktop I maintain for 
> my parents uses an AMD Phenom II X4 965 processor, circa 2009-2010, and it 
> doesn’t support x86_64-v2 either—but it just keeps on working.
>
> Now, I can afford to replace my own workstation if I must—and I’m planning to 
> do so in another year or two when the rolling component shortages settle out 
> a little—but I suspect there are still many others like me, some of whom 
> might not be in a position to just sigh and buy new hardware. Even for those 
> who can, the pandemic and the crypto crazes have made it an exceptionally bad 
> time to be forced into an upgrade.

So ... maybe the following approach would be a way forward that would
benefit everybody (TM):

1. stay with x86-64-baseline for Fedora for now (performance critical
software often has runtime CPU feature detection and dynamic dispatch
anyway)
2. identify "performance sensitive" libraries in Fedora that do not
have runtime CPU feature detection, and which would benefit from
having the instructions that are added with x86-64-v2 available (looks
like the the performance benefit of enabling this overall is small
(?), but maybe there are exceptions, where bumping from x86-64 to
x86-64-v2 would make a bigger difference for some library)
3. make it easy to build the libraries identified under 2. twice (or
three times, with x86-64-v3?) and install them in the locations where
the loader can find them (leveraging the new HWCAPS functionality)

This approach would allow older machines to continue to run the latest
Fedora just fine, while libraries that *would* benefit from more
available CPU instructions would run faster for the people who have
newer hardware.

Fabio
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)

[Charalampos Stratakis]

On Wed, Jun 16, 2021 at 1:56 AM Tom Stellard  wrote:

> On 5/7/21 10:48 AM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Broken_RPATH_will_fail_rpmbuild
> >
> > == Summary ==
> > Enable broken RPATH detection
> > [
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_brp_buildroot_policy_scripts
> > buildroot policy] script by default. This will make the RPM build fail
> > once a broken RPATH was detected within a binary or a shared library
> > file. An opt-out mechanism will be provided as well.
> >
> > == Owner ==
> > * Name: [[User:cstratak| Charalampos Stratakis]]
> > * Email: cstratak AT redhat.com
> >
> >
>
> Hi,
>
> Was there any testing done to determine how much this script would increase
> build times?  I've noticed it takes quite a while on the kernel builds, and
> I'm curious what factors influence how long the script takes.  Is it
> number of binaries, binary sizes, etc?
>
> -Tom
> ___
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>

Hey Tom,

Unfortunately no, a potential increase in build time was not taken into
account at the time of the implementation of this change, as it never came
up when considering other buildroot policy scripts as well.

Here is the actual script that runs:
https://github.com/rpm-software-management/rpm/blob/rpm-4.16.x/scripts/check-rpaths-worker

Could you try and compare two scratch builds? One as is and one by
adding %global
__brp_check_rpaths %{nil} at the SPEC?

Also adding here for completion that the script will also check for RUNPATH
as of rpm 4.17:
https://github.com/rpm-software-management/rpm/pull/1487/files

-- 
Regards,

Charalampos Stratakis
Senior Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Kevin Kofler via devel]

Neal Gompa wrote:
> Yeah, I think that proposal was not workable because of AVX2. The
> x86_64-v2 subarch adds SSSE3, SSE4.2, POPCNT, and CMPXCHG16B to the
> current x86_64 baseline. All of these instructions were present in the
> first Intel Macs launched in 2007, as I recall.

Still means my Core 2 Duo notebook would no longer be able to run Fedora.

>> Different question: How is the runtime CPU feature detection /
>> dispatch support in glibc coming along? Shouldn't this "work" by now?
> 
> No idea, good question, though!

Indeed, runtime detection is clearly the way to go.

Why does this proposal to desupport hardware for no good reason (because the 
performance gain can be obtained in a compatible way, where it is even 
noticeable at all) keep coming up again and again?

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Kevin Kofler via devel]

Florian Weimer wrote:
> Right, I have yet to encounter anyone who can't run the new el9 binaries
> on their hardware.  We had a few issues, but they were all
> misconfiguration of hypervisors or software emulators.

Let me introduce you to my notebook:

[kevin@laptop64 ~]$ cat /etc/fedora-release
Fedora release 33 (Thirty Three)
[kevin@laptop64 ~]$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Core(TM)2 Duo CPU T7700  @ 2.40GHz
stepping: 10
microcode   : 0x95
cpu MHz : 1197.087
cache size  : 4096 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm pti tpr_shadow vnmi 
flexpriority vpid dtherm
vmx flags   : vnmi flexpriority tsc_offset vtpr vapic
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf 
mds swapgs itlb_multihit
bogomips: 4788.34
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Core(TM)2 Duo CPU T7700  @ 2.40GHz
stepping: 10
microcode   : 0x95
cpu MHz : 1197.075
cache size  : 4096 KB
physical id : 0
siblings: 2
core id : 1
cpu cores   : 2
apicid  : 1
initial apicid  : 1
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 
monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm pti tpr_shadow vnmi 
flexpriority vpid dtherm
vmx flags   : vnmi flexpriority tsc_offset vtpr vapic
bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf 
mds swapgs itlb_multihit
bogomips: 4788.34
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

As you can see from fedora-release, it runs Fedora 33 just fine. I have yet 
to try Fedora 34 on it, but I expect that to work fine, too. But anything 
requiring flags like sse4_1 sse4_2 popcnt etc. will not.

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Package maintainer docs: Package Retirement: `git rm` all files in the other branches

[Kevin Kofler via devel]

Otto Urpelainen wrote:
> Also, if the intent is to get rid of the package completely, should not
> adding it to fedora-obsolete-packages be required as well?

Why? Adding working packages to fedora-obsolete-packages forces removing 
them from users' machines just because they are no longer in the repository. 
That is a major disservice to the users. fedora-obsolete-packages makes 
sense to use only when having the package still present actually breaks 
something (and I personally think that it is unhelpful even in that case, 
that is really what dnf --allowerasing is for, at least when we are talking 
about package-level conflicts).

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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

RFP: Just

[Casey Rodarmor]

Hi there,

I maintain a command runner, written in Rust:

https://github.com/casey/just

It's very much like make, except a lot nicer, and doesn't have a build
system, so it's just for saving and running commands. It's reasonably
popular, and I wanted to request that it be packaged Fedora, since
although I'm not a Fedora user, there are some users of Just who are.

Just wanted to put the request out there, and note that I'm super
happy to make changes on my end that might make packaging Just easier.

Thanks!

Best,
Casey
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Fedocal] Reminder meeting : Fedora Classroom - RPM Packaging 101

[t0xic0der]

Dear all,

You are kindly invited to the meeting:
   Fedora Classroom - RPM Packaging 101 on 2021-06-17 from 12:00:00 to 13:30:00 
UTC
   At https://bluejeans.com/473822117

The meeting will be about:
# Fedora Classroom on RPM packaging

Join the classroom by following [this link](https://bluejeans.com/473822117).

For commands and notes discussed, point your IRC client to 
`irc.libera.chat:6697` and join the `#fedora-classroom` room.


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

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Fedocal] Reminder meeting : Fedora Classroom - RPM Packaging 101

[t0xic0der]

Dear all,

You are kindly invited to the meeting:
   Fedora Classroom - RPM Packaging 101 on 2021-06-17 from 12:00:00 to 13:30:00 
UTC
   At https://bluejeans.com/473822117

The meeting will be about:
# Fedora Classroom on RPM packaging

Join the classroom by following [this link](https://bluejeans.com/473822117).

For commands and notes discussed, point your IRC client to 
`irc.libera.chat:6697` and join the `#fedora-classroom` room.


Source: https://calendar.fedoraproject.org//meeting/10002/

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Neal Gompa]

On Wed, Jun 16, 2021 at 6:08 PM Kevin Kofler via devel
 wrote:
>
> Neal Gompa wrote:
> > Yeah, I think that proposal was not workable because of AVX2. The
> > x86_64-v2 subarch adds SSSE3, SSE4.2, POPCNT, and CMPXCHG16B to the
> > current x86_64 baseline. All of these instructions were present in the
> > first Intel Macs launched in 2007, as I recall.
>
> Still means my Core 2 Duo notebook would no longer be able to run Fedora.
>
> >> Different question: How is the runtime CPU feature detection /
> >> dispatch support in glibc coming along? Shouldn't this "work" by now?
> >
> > No idea, good question, though!
>
> Indeed, runtime detection is clearly the way to go.
>
> Why does this proposal to desupport hardware for no good reason (because the
> performance gain can be obtained in a compatible way, where it is even
> noticeable at all) keep coming up again and again?
>

It keeps coming up because we don't have support for subarches in RPM
for anything but ARM architectures. That deficiency forces us to keep
considering raising the baseline instead of being able to have select
packages with subarch content. This is important because not
everything *can* use glibc-hwcap hardware detection at runtime, and
sometimes you need optimized binaries.



--
真実はいつも一つ！/ 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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Orcan Ogetbil]

On Thu, 27 May 2021 at 11:55, Tom Callaway  wrote:
>
> FWIW, I have retired xmms. Upstream is long gone, and it was being held 
> together by spider-webs anyways.

Is there any copr where this is somewhat maintained? gtk+ was the best
gtk (yeah just because of xmms), it's sad to see it go.

Thanks,
Orcan
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Let's retire original glib and gtk+

[Jerry James]

Sorry, didn't see this when it first came through.

On Mon, May 31, 2021 at 4:18 AM Sérgio Basto  wrote:
> I propose, for F36, the retire of Gconf2 (1)
>
> dnf repoquery --disablerepo='*' \
> --enablerepo={rpmfusion-{non,}free-,}rawhide --recursive \
> --whatrequires "libgconf*" --qf "%{repoid} %{sourcerpm}"  -q

[snip]

> rawhide frama-c-22.0-10.fc35.src.rpm
> rawhide ocaml-cairo-0.6.1-11.fc35.src.rpm
> rawhide ocaml-camlimages-4.2.5-28.fc35.src.rpm
> rawhide ocaml-dose3-5.0.1-32.20200502git24316fe.fc35.src.rpm
> rawhide ocaml-lablgtk-2.18.11-6.fc35.src.rpm
> rawhide ocaml-ocamlgraph-1.8.8-25.fc35.src.rpm
> rawhide ocaml-ocamlnet-4.1.8-4.fc35.src.rpm
> rawhide ocaml-xmlrpc-light-0.6.1-61.fc35.src.rpm

These packages are very useful, and have active upstreams.  They are
all in the process of switching from gtk2 to gtk3, but haven't
completed the transition yet.  The ocaml-cairo package, for example,
is an OCaml interface to cairo.  It has a cairo-gtk subpackage for
rendering cairo on a gtk2 canvas, and a cairo-pango subpackage for
using pango with cairo in OCaml programs.  The ocaml-lablgtk3 package,
which is an OCaml interface to gtk3, depends on the non-gtk2 parts of
ocaml-cairo.

We might be able to excise the gtk2 parts of these packages, but it
would not be simple, nor something that could be done overnight.  A
little more time for the upstreams to make more progress would be
greatly appreciated.
-- 
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

systemd unit auto-enabling question

[Peter Hutterer]

I'm running around in circles here not getting anywhere, so maybe someone
on this list has the answer :)

I have three packages [1], lets call them
- server
- manager (Conflicts: alternative-manager)
- alternative-manager (Conflicts: manager)

The server on its own is relatively dumb, it needs a manager to function
(there are niche cases where only the server should exist). The server is
socket-activated and server.socket is enabled in the systemd presets so that
will start as part of the user session.

In the manager's .service file I have
[Unit]
BindsTo=server.service

[Install]
WantedBy=server.service

This ties it to the server and starts/stops it automatically.
But: this only happens once I *manually* run systemctl enable manager.service.

What I need is manager.service being auto-enabled at install time. How do I
get this done?

I cannot rely on it from server.service either because alternative-manager
may be installed with a different .service file.

Any ideas?

Cheers,
   Peter

[1] the actual packages are pipewire, pipewire-media-session and wireplumber
but doesn't matter for the approach here
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[HEADS UP] Moving to sip 5 in Rawhide

[Scott Talbert]

Hi,

Just a heads-up, I've been working on converting packages from sip 4 to 
sip 5 in Rawhide.  (sip is the Python bindings generation system used by 
PyQt and wxPython.)


I'm planning on opening pull requests against the affected packages soon. 
Please DO NOT merge these PRs yet - they need to be merged and built in a 
side tag in order to build them in the correct order.  Please DO review 
and comment on the PRs though.  Kevin and Rex will be helping merge and 
build once the changes are reviewed.


The sip 5 changes are planned for F35+ only.  Please let me know in the PR 
if you prefer the changes to be fast-forwardable to older releases and 
I'll %if guard them.


The affected packages are:
python-pyqt5-sip -> NEW package
calibre
krita
plplot
pyqtwebengine
python-pyqtchart
python-qt5
python3-poppler-qt5
qgis
qhexedit2
qscintilla
scidavis
sip
veusz

Thanks,
Scott
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] Moving to sip 5 in Rawhide

[Elliott Sales de Andrade]

On Wed, 16 Jun 2021 at 22:51, Scott Talbert  wrote:
>
> Hi,
>
> Just a heads-up, I've been working on converting packages from sip 4 to
> sip 5 in Rawhide.  (sip is the Python bindings generation system used by
> PyQt and wxPython.)
>

I see we have Qt6, but not PyQt6, in Fedora 34. Is this what's
required to make that available, or is it just that no-one has gotten
around to it?

> I'm planning on opening pull requests against the affected packages soon.
> Please DO NOT merge these PRs yet - they need to be merged and built in a
> side tag in order to build them in the correct order.  Please DO review
> and comment on the PRs though.  Kevin and Rex will be helping merge and
> build once the changes are reviewed.
>
> The sip 5 changes are planned for F35+ only.  Please let me know in the PR
> if you prefer the changes to be fast-forwardable to older releases and
> I'll %if guard them.
>
> The affected packages are:
> python-pyqt5-sip -> NEW package
> calibre
> krita
> plplot
> pyqtwebengine
> python-pyqtchart
> python-qt5
> python3-poppler-qt5
> qgis
> qhexedit2
> qscintilla
> scidavis
> sip
> veusz
>
> Thanks,
> Scott
> ___
> 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
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Elliott
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [HEADS UP] Moving to sip 5 in Rawhide

[Scott Talbert]

On Wed, 16 Jun 2021, Elliott Sales de Andrade wrote:



Hi,

Just a heads-up, I've been working on converting packages from sip 4 to
sip 5 in Rawhide.  (sip is the Python bindings generation system used by
PyQt and wxPython.)



I see we have Qt6, but not PyQt6, in Fedora 34. Is this what's
required to make that available, or is it just that no-one has gotten
around to it?


It's probably part of what's required for PyQt6 (although sip 5 is already 
available).  The other part is actually packaging PyQt6.  :-)


This change is mostly a non-user facing change to the way PyQt5 related 
applications and libraries are built.  It's mostly required because some 
appllications (e.g., calibre) only build with sip5+.


Scott
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Package maintainer docs: Package Retirement: `git rm` all files in the other branches

[przemek klosowski via devel]

On 6/16/21 6:26 PM, Kevin Kofler via devel wrote:

Otto Urpelainen wrote:

Also, if the intent is to get rid of the package completely, should not
adding it to fedora-obsolete-packages be required as well?

Why? Adding working packages to fedora-obsolete-packages forces removing
them from users' machines just because they are no longer in the repository.
That is a major disservice to the users. fedora-obsolete-packages makes
sense to use only when having the package still present actually breaks
something (and I personally think that it is unhelpful even in that case,
that is really what dnf --allowerasing is for, at least when we are talking
about package-level conflicts).


This is correct from the strict OS packaging point of view, but I think 
we should be concerned about the accumulation of detritus: packages that 
broke over time and simply do not work any more, for example like this one


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

If unchecked, they make the system look like the FTP archives of last 
century---strewn with broken, unmaintained stuff.


Of course new installs would not get these packages, only the old, 
upgraded releases, so it only affects the people who update a lot.


Unfortunately, the tooling to clean it up is not that nice: the 
%{RELEASE} RPM querytag is noisy so it needs to be touched up


rpm -qa --queryformat "%{release}\n" | perl -ne 'next unless /(fc\d+)/; 
print "$1\n"'  | sort  | uniq -c | sort -n


  1 fc28
  2 fc30
  3 fc29
 14 fc31
 15 fc32
 33 fc33
   4895 fc34

I sometimes run this on my systems and investigate why do I still have 
FC2x package. Usually it is just some abandonware; in this case,


rpm -qa | grep fc2

    glibc-arm-linux-gnu-2.27-4.fc29.x86_64
    emacs-verilog-mode-531-13.fc29.noarch
    emacs-php-mode-1.18.2-2.fc28.noarch
    emacs-mew-6.8-2.fc29.x86_64

I think quietly deleting this stuff would be a little harsh, but maybe 
it should be flagged in some way or at least easier to find and clean up?


BTW, I remember a discussion about obsolete gpg-pubkeys being a security 
hole; again, cleaning them up would make sense. They are not included in 
the list above---their %{release} sadly doesn't include the fedora 
version; it is only informally (?) mentioned in the %{PACKAGER} and 
%{SUMMARY} tags, making it hard to automate.


So, I'd like to at least propose that gpg-pubkeys packages have the 
Fedora version they pertain to in their %{RELEASE} tag.

___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: x86_64-v2 in Fedora

[Dan Čermák]

On June 17, 2021 12:08:44 AM UTC, Neal Gompa  wrote:
>On Wed, Jun 16, 2021 at 6:08 PM Kevin Kofler via devel
> wrote:
>>
>> Neal Gompa wrote:
>> > Yeah, I think that proposal was not workable because of AVX2. The
>> > x86_64-v2 subarch adds SSSE3, SSE4.2, POPCNT, and CMPXCHG16B to the
>> > current x86_64 baseline. All of these instructions were present in
>the
>> > first Intel Macs launched in 2007, as I recall.
>>
>> Still means my Core 2 Duo notebook would no longer be able to run
>Fedora.
>>
>> >> Different question: How is the runtime CPU feature detection /
>> >> dispatch support in glibc coming along? Shouldn't this "work" by
>now?
>> >
>> > No idea, good question, though!
>>
>> Indeed, runtime detection is clearly the way to go.
>>
>> Why does this proposal to desupport hardware for no good reason
>(because the
>> performance gain can be obtained in a compatible way, where it is
>even
>> noticeable at all) keep coming up again and again?
>>
>
>It keeps coming up because we don't have support for subarches in RPM
>for anything but ARM architectures. That deficiency forces us to keep
>considering raising the baseline instead of being able to have select
>packages with subarch content. This is important because not
>everything *can* use glibc-hwcap hardware detection at runtime, and
>sometimes you need optimized binaries.

Honestly, this sounds to me like we rather should find a solution how to "fix" 
this in RPM (I know of the previous unsuccessful attempts). Otherwise I don't 
really see compelling reasons why we should raise the baseline to x86_64v2 when 
it provides very small gain. Because in contrast to runtime detection or 
cutting edge software, this has the disadvantage that once you raise it, you 
throw people out. So it better be worth it and ATM I don't see why it is.


>
>
>--
>真実はいつも一つ！/ 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
>Do not reply to spam on the list, report it:
>https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Schedule for Thursday's FPC Meeting (2021-06-17 16:00 UTC)

[James Antill]

NOTE: This is the second meeting we'll have on IRC.LIBERA.CHAT

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2021-06-17 16:00 UTC in #fedora-meeting-1 on
irc.libera.chat.

 Local time information (via. uitime):

= Day: Thursday ==
2021-06-17 09:00 PDT  US/Pacific
2021-06-17 12:00 EDT  --> US/Eastern <--
2021-06-17 16:00 UTC  UTC   
2021-06-17 17:00 BST  Europe/London 
2021-06-17 18:00 CEST Europe/Berlin 
2021-06-17 18:00 CEST Europe/Paris  
2021-06-17 21:30 IST  Asia/Calcutta 
 New Day: Friday -
2021-06-18 00:00 HKT  Asia/Hong_Kong
2021-06-18 00:00 +08  Asia/Singapore
2021-06-18 01:00 JST  Asia/Tokyo
2021-06-18 02:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

= Followup Actions =

#topic #pr-814
 * mhroncok
   talk to authors again, having a working example might help a lot

= Followup Issues =

#topic #886 Enable BRP for detecting RPATH 
.fpc 886
https://pagure.io/packaging-committee/issue/886

#topic #907 Which %__foo macros for executables are acceptable? 
.fpc 907
https://pagure.io/packaging-committee/issue/907

#topic #1058 How to handle %lang files in package owned directories? .fpc 1058
https://pagure.io/packaging-committee/issue/1058

= Followup Pull Requests =

#topic #pr-814 Add SELinux Independent Policy Guidelines.
https://pagure.io/packaging-committee/pull-request/814

#topic #pr-1045 WIP: Add discussion of macro names beginning with underscores.
https://pagure.io/packaging-committee/pull-request/1045

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * 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.


___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Package maintainer docs: Package Retirement: `git rm` all files in the other branches

[Otto Urpelainen]

przemek klosowski via devel kirjoitti 17.6.2021 klo 6.21:


On 6/16/21 6:26 PM, Kevin Kofler via devel wrote:

Otto Urpelainen wrote:

Also, if the intent is to get rid of the package completely, should not
adding it to fedora-obsolete-packages be required as well?

Why? Adding working packages to fedora-obsolete-packages forces removing
them from users' machines just because they are no longer in the 
repository.

That is a major disservice to the users. fedora-obsolete-packages makes
sense to use only when having the package still present actually breaks
something (and I personally think that it is unhelpful even in that case,
that is really what dnf --allowerasing is for, at least when we are 
talking

about package-level conflicts).


This is correct from the strict OS packaging point of view, but I think 
we should be concerned about the accumulation of detritus: packages that 
broke over time and simply do not work any more, for example like this one


Note that the documentation in question is not about normal package 
retirement, it is about the case where "there are special factors at 
work, like licensing issues, or package being removed completely from 
Fedora". That is quite muddy, but it is clear that the procedure is only 
intended for some special case where it is considered important to 
somehow erase the whole package, end-of-life releases and all.


The only example that is given are "licensing issues" with no 
explanation. I imagine what is meant is that it turns out that package 
useful-app is packaged in Fedora, then later it turns out it actually it 
has a proprietary license and Fedora has no right to distribute it. So 
distribution is ceased by removing the package from all channels, 
including end-of-life releases. In this case, the question is, is Fedora 
also obliged to do a recall the copies that were already illegally 
distributed. Obsoleting it would help with that.


Another case I could imagine would be that a package is found to contain 
malware, in which case I suppose it would be a good idea to attempt to 
remove it from as many installations as possible.


From documentation point of view, the problem is that a large and 
complicated topic is just hinted at when describing a different procedure.


Anyhow, since the obsoletes part is unclear and it was my own invention 
anyhow, I edited the page a bit to just say that it should be considered 
in that situation.


Otto
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)

[Tom Stellard]

On 6/16/21 2:11 PM, Charalampos Stratakis wrote:

On Wed, Jun 16, 2021 at 1:56 AM Tom Stellard mailto:tstel...@redhat.com>> wrote:

On 5/7/21 10:48 AM, Ben Cotton wrote:
 > https://fedoraproject.org/wiki/Changes/Broken_RPATH_will_fail_rpmbuild 

 >
 > == Summary ==
 > Enable broken RPATH detection
 > 
[https://docs.fedoraproject.org/en-US/packaging-guidelines/#_brp_buildroot_policy_scripts
 

 > buildroot policy] script by default. This will make the RPM build fail
 > once a broken RPATH was detected within a binary or a shared library
 > file. An opt-out mechanism will be provided as well.
 >
 > == Owner ==
 > * Name: [[User:cstratak| Charalampos Stratakis]]
 > * Email: cstratak AT redhat.com 
 >
 >

Hi,

Was there any testing done to determine how much this script would increase
build times?  I've noticed it takes quite a while on the kernel builds, and
I'm curious what factors influence how long the script takes.  Is it
number of binaries, binary sizes, etc?

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

Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure 



Hey Tom,

Unfortunately no, a potential increase in build time was not taken into account 
at the time of the implementation of this change, as it never came up when 
considering other buildroot policy scripts as well.

Here is the actual script that runs: 
https://github.com/rpm-software-management/rpm/blob/rpm-4.16.x/scripts/check-rpaths-worker
 


Could you try and compare two scratch builds? One as is and one by adding 
|%global __brp_check_rpaths %{nil} |at the SPEC?|
|



Instead of doing two scratch builds, I just added:
%global __brp_check_rpaths time /usr/lib/rpm/check-rpaths to the spec file
and did a scratch build[1].

The results on x86_64 were:

real13m51.517s
user8m53.216s
sys 7m34.105s

Overall build time for the scratch build was 88m37s, so  that means check-rpaths
accounted for 15% of the build time.  I'm going to do some more tests on some
of the larger packages I maintain (llvm and clang) and see what the impact is.

I do think it would be worth trying to profile the script and see if there is
room for optimization.

- Tom

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




Also adding here for completion that the script will also check for RUNPATH as of rpm 
4.17: https://github.com/rpm-software-management/rpm/pull/1487/files 


--
Regards,

Charalampos Stratakis
Senior Software Engineer
Python Maintenance Team, Red Hat

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jun 16, 2021 at 10:58:13PM -0700, Tom Stellard wrote:
> On 6/16/21 2:11 PM, Charalampos Stratakis wrote:
> >On Wed, Jun 16, 2021 at 1:56 AM Tom Stellard  >> wrote:
> >
> >On 5/7/21 10:48 AM, Ben Cotton wrote:
> > > 
> > https://fedoraproject.org/wiki/Changes/Broken_RPATH_will_fail_rpmbuild 
> > 
> > >
> > > == Summary ==
> > > Enable broken RPATH detection
> > > 
> > [https://docs.fedoraproject.org/en-US/packaging-guidelines/#_brp_buildroot_policy_scripts
> >  
> > 
> > > buildroot policy] script by default. This will make the RPM build fail
> > > once a broken RPATH was detected within a binary or a shared library
> > > file. An opt-out mechanism will be provided as well.
> > >
> > > == Owner ==
> > > * Name: [[User:cstratak| Charalampos Stratakis]]
> > > * Email: cstratak AT redhat.com 
> > >
> > >
> >
> >Hi,
> >
> >Was there any testing done to determine how much this script would 
> > increase
> >build times?  I've noticed it takes quite a while on the kernel builds, 
> > and
> >I'm curious what factors influence how long the script takes.  Is it
> >number of binaries, binary sizes, etc?
> >
> >-Tom
> >___
> >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 
> > 
> >Do not reply to spam on the list, report it: 
> > https://pagure.io/fedora-infrastructure 
> > 
> >
> >
> >Hey Tom,
> >
> >Unfortunately no, a potential increase in build time was not taken into 
> >account at the time of the implementation of this change, as it never came 
> >up when considering other buildroot policy scripts as well.
> >
> >Here is the actual script that runs: 
> >https://github.com/rpm-software-management/rpm/blob/rpm-4.16.x/scripts/check-rpaths-worker
> > 
> >
> >
> >Could you try and compare two scratch builds? One as is and one by adding 
> >|%global __brp_check_rpaths %{nil} |at the SPEC?|
> >|
> >
> 
> Instead of doing two scratch builds, I just added:
> %global __brp_check_rpaths time /usr/lib/rpm/check-rpaths to the spec file
> and did a scratch build[1].
> 
> The results on x86_64 were:
> 
> real  13m51.517s
> user  8m53.216s
> sys   7m34.105s

An fairly easy fix might be to stuff 'parallel --group' there, to at
least process different files concurrently.

> Overall build time for the scratch build was 88m37s, so  that means 
> check-rpaths
> accounted for 15% of the build time.  I'm going to do some more tests on some
> of the larger packages I maintain (llvm and clang) and see what the impact is.
> 
> I do think it would be worth trying to profile the script and see if there is
> room for optimization.
> 
> - Tom
> 
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=70270039
> 
> 
> 
> >Also adding here for completion that the script will also check for RUNPATH 
> >as of rpm 4.17: 
> >https://github.com/rpm-software-management/rpm/pull/1487/files 
> >

From a quick look, that looks like it'll double the time.

What about:
-check_rpath $i "RPATH"
-check_rpath $i "RUNPATH"
+check_rpath $i "RPATH|RUNPATH"

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fwd: OpenSceneGraph and gdal need to be rebuild for Fedora 34

[Björn 'besser82' Esser]

Am Mittwoch, dem 16.06.2021 um 21:18 +0200 schrieb Björn 'besser82'
Esser:
> Am Mittwoch, dem 16.06.2021 um 19:53 +0200 schrieb Jiri Kucera:
> > Adding devel-list for a broader audience. My side tag will expire
> > for
> > a couple of days. Can some proven packager add me please to gdal,
> > OpenSceneGraph, and vtk as a co-maintainer so I can do rebuilds for
> > libgta?
> > 
> > Cheers,
> > Jiri
> > 
> > 
> > -- Forwarded message -
> > From: Jiri Kucera 
> > Date: Fri, Jun 11, 2021 at 10:29 AM
> > Subject: OpenSceneGraph and gdal need to be rebuild for Fedora 34
> > To: , ,
> > 
> > 
> > 
> > Hi Sandro, Ralph, and Orion,
> > 
> > I rebuilt[1] libgta with sidetag f34-build-side-42373 for Fedora 34,
> > which bumps libgta.so.0 to libgta.so.1. Please,
> > rebuild your packages against this sidetag:
> > * gdal need to be probably rebased to 3.3.0 (I did a scratch
> > build[2]
> > against the sidetag from f34 branch and its succeeded, but the
> > scratch
> > build[3] of OpenSceneGraph failed[4])
> > * after gdal OpenSceneGraph and vtk need to be rebuilt
> > * last, opencv need to be rebuilt (I do this by myself)
> > 
> > Regards,
> > Jiri
> > 
> > [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1766154
> > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=69770320
> > [3] https://koji.fedoraproject.org/koji/taskinfo?taskID=69836182
> > [4] Excerpt from the mock_output.log:
> 
> 
> I'll take care of the needed rebuilds in your sidetag as a
> provenpackager, and will give you a short notice, as soon as you can
> start rebuilding opencv.


gdal and OpenSceneGraph have been seccessfully rebuilt in the sidetag. 
vtk is still building.


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure