Re: jpegxl soname bump

[Nicolas Chauvet]

Le ven. 3 déc. 2021 à 17:17, Sérgio Basto  a écrit :
>
> On Fri, 2021-12-03 at 15:36 +, Michael J Gruber wrote:
> > F35 updates has libaom-3.2.0-2 and libjxl-0.6.1-6 already - so did
> > the buildroot go through?
> > (This conflicts with heif from rpmfusion, which I can't complain
> > about here, of course.)
>
> yes , buildroot go through , rpmfusion packages are fixed just need to
> be published in repos
Problem was not only about rpmfusion packages rebuilt, but also a lot
of missing fedora rebuilt.
To this date, there are still missing rebuilds, so was my -1 for this update.

@besser Can you clarify why you have pushed this update to stable
despite my notice ?
This is not the first time this problem occurs with aom and some
fedora rebuilds are not done.

Someone will have to fix the missing piece...
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: phoronix-test-suite 10.6.1 in Rawhide and F35

[Reon Beon via devel]

Could please you post the rawhide/36 version?

Thanks for your work.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Test-Announce] Proposal to CANCEL: 2021-12-06 Fedora QA Meeting

[Adam Williamson]

Hi folks! I'm proposing we cancel the QA meeting on Monday. I don't
have anything urgent for this week. As a heads up, I'll be off work
from December 15 through Jan 3, so I'm planning to run a final meeting
for the year next week on December 13, then pick up again next year.

If you're aware of anything it would be useful to discuss this week,
please do reply to this mail and we can go ahead and run the meeting.

Thanks!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
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

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-b9fd954bc5   
seamonkey-2.53.10-2.el8


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

cswrap-2.1.0-1.el8
fira-code-fonts-6.1-1.el8
holland-1.2.9-1.el8
icewm-2.9.1-1.el8
lockfile-progs-0.1.17-13.el8
perl-Net-BGP-0.18-1.el8
python-peewee-3.14.8-1.el8
wsdd-0.7.0-1.el8

Details about builds:



 cswrap-2.1.0-1.el8 (FEDORA-EPEL-2021-ce244f5ac8)
 Generic compiler wrapper

Update Information:

- update to latest upstream release

ChangeLog:

* Fri Dec  3 2021 Kamil Dudka  2.1.0-1
- update to latest upstream




 fira-code-fonts-6.1-1.el8 (FEDORA-EPEL-2021-d1982966a2)
 Monospaced font with programming ligatures

Update Information:

Update to 6.1

ChangeLog:

* Fri Dec  3 2021 Michael Kuhn  - 6.1-1
- Update to 6.1
* Mon Nov 29 2021 Michael Kuhn  - 6-1
- Update to 6
* Wed Jul 21 2021 Fedora Release Engineering  - 5.2-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild

References:

  [ 1 ] Bug #2027533 - fira-code-fonts-6 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2027533




 holland-1.2.9-1.el8 (FEDORA-EPEL-2021-c8021171b1)
 Pluggable Backup Framework

Update Information:

Latest upstream release.

ChangeLog:

* Fri Dec  3 2021 survi...@fedoraproject.org - 1.2.9-1
- Latest upstream release.




 icewm-2.9.1-1.el8 (FEDORA-EPEL-2021-b4ddea1dc9)
 Window manager designed for speed, usability, and consistency

Update Information:

Update to latest version

ChangeLog:

* Fri Dec  3 2021 Artem Polishchuk  - 2.9.1-1
- chore(update): 2.9.1




 lockfile-progs-0.1.17-13.el8 (FEDORA-EPEL-2021-23b4b86236)
 Command-line programs to safely lock and unlock files and mailboxes

Update Information:

new package

ChangeLog:

* Thu Jul 22 2021 Fedora Release Engineering  - 
0.1.17-13
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
* Tue Jan 26 2021 Fedora Release Engineering  - 
0.1.17-12
- Rebuilt for https://fedoraproject.org/wiki/Fedora_34_Mass_Rebuild
* Tue Jul 28 2020 Fedora Release Engineering  - 
0.1.17-11
- Rebuilt for https://fedoraproject.org/wiki/Fedora_33_Mass_Rebuild
* Wed Jan 29 2020 Fedora Release Engineering  - 
0.1.17-10
- Rebuilt for https://fedoraproject.org/wiki/Fedora_32_Mass_Rebuild
* Thu Jul 25 2019 Fedora Release Engineering  - 
0.1.17-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild
* Fri Feb  1 2019 Fedora Release Engineering  - 
0.1.17-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild
* Fri Jul 13 2018 Fedora Release Engineering  - 
0.1.17-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild
* Tue Mar 13 2018 Matthias Runge  - 0.1.17-6
- add gcc build requirement
* Thu Feb  8 2018 Fedora Release Engineering  - 
0.1.17-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Thu Aug  3 2017 Fedora Release Engineering  - 
0.1.17-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Binutils_Mass_Rebuild
* Wed Jul 26 2017 Fedora Release Engineering  - 
0.1.17-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild
* Fri Feb 10 2017 Fedora Release Engineering  - 
0.1.17-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
* Wed Aug 17 2016 Matthias Runge  - 0.1.17-1
- update to 0.1.17 

Re: F36 Change: Users are administrators by default in the installer GUI. (Self-Contained Change proposal)

[Michel Alexandre Salim]

On Wed, Dec 01, 2021 at 04:53:20PM -0500, Colin Walters wrote:
> 
> 
> On Wed, Dec 1, 2021, at 4:34 PM, Chris Adams wrote:
> > Once upon a time, Colin Walters  said:
> >> https://github.com/coreos/fedora-coreos-config/commit/eb74f2ea3e9b453902315539e4f327481162c4f8
> >
> > Missed this message earlier... this seems like this should be the
> > default on pretty much all Fedora setups, with documentation on how to
> > change it if you secure the boot loader.
> 
> Yeah, I agree.  Also related is
> https://github.com/coreos/fedora-coreos-tracker/issues/134
> 
> Basically systemd doesn't know whether or not the bootloader is locked.
> Longer term, perhaps there could be some standard variable for this passed 
> from the bootloader to kernel/systemd that says whether or not the bootloader 
> allows unauthenticated interactive keyboard changes (as grub does on default 
> Fedora setups).  If it does, we can just unceremoniously drop to a root shell.

I've submitted https://fedoraproject.org/wiki/Changes/FixRescueMode to
make this default on Fedora setups (it should be officially
announced by Monday).

I'm interested in the longer-term followup too - should we discuss that
separately and cc: grub and systemd development lists?

Best,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


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: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Richard W.M. Jones]

On Fri, Dec 03, 2021 at 06:08:49PM +, Davide Cavalca via devel wrote:
> Broadly speaking, fs-verity makes it possible to ensure that files that
> were installed via an RPM have not been modified. It is useful in
> environments where an attacker might be able to modify system files
> (say, replace /bin/ls with a compromised version) and you want to
> protect against that. For example, consider an appliance-like system
> placed in an untrusted location where you may not be able to control
> who has physical access (this could be a server, but it could also be a
> kiosk in an internet point or a school). In this scenario, fs-verity
> can be one of the building blocks to ensure and maintain system trust.

I'm unclear about the threat model - this is an attacker who is
someone able to overwrite single files (eg. /bin/ls) but cannot turn
off the fs-verity system as a whole?

Also if RPM can update /bin/ls then surely an attacker who can widely
compromise system files must also be able to update /bin/ls in the
same way?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[Bug 2028263] perl-Test2-Suite-0.000144 is available

[bugzilla]

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

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Test2-Suite-0.000143   |perl-Test2-Suite-0.000144
   |is available|is available



--- Comment #1 from Upstream Release Monitoring 
 ---
Latest upstream release: 0.000144
Current version/release in rawhide: 0.000141-1.fc35
URL: http://search.cpan.org/dist/Test2-Suite/

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


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


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


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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2028263
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: cmake on Rawhide is broken

[Miro Hrončok]

On 03. 12. 21 18:41, Daniel P. Berrangé wrote:

On Fri, Dec 03, 2021 at 05:41:31PM +0100, Miro Hrončok wrote:

On 03. 12. 21 16:06, Miro Hrončok wrote:

On 03. 12. 21 15:59, Miro Hrončok wrote:

On 03. 12. 21 15:49, Miro Hrončok wrote:

On 03. 12. 21 15:45, Kamil Dudka wrote:

On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote:


It seems that libarchive still requires libcrypto.so.1.1()(64bit)

But on x86_64, opae-devel provides that with:

ExclusiveArch:  x86_64

I'll report that.


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


The problem is now fixed. The bundled openssl in opae worries me still, but
that's not causing issues in dependency resolution any more.


Bundling pre-built openssl is a serious problem, because Fedora
is required to strip various functionality from openssl at the
source level. We cannot ship these binaries in the RPM, nor can
we even have them in the source tarball AFAIK.

IOW, stripping the dependancies from the RPM here is not sufficient.
IIUC, the tarball needs to be unpacked, the openssl binaries removed,
and a new tarball created for import into Fedora dist-git lookside
archive storage.


I agree. I applied the smallest possible bandaid to unblock other packagers, 
but the original cause of this problem remains to be solved by the package 
maintainers. Thta is why https://bugzilla.redhat.com/2028852 remains open.


--
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: cmake on Rawhide is broken

[Miro Hrončok]

On 03. 12. 21 18:48, Simo Sorce wrote:

Do we know who is the current maintainer?
The changelog seem to imply Intel dropped it into Fedora and never
maintained it after Sep 17 2020 ...


Tom Rix from Red Hat. Username trix.

--
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: why do elf dependency generators cover libraries in paths outside of the library load paths?

[Richard W.M. Jones]

On Fri, Dec 03, 2021 at 10:04:05PM +0100, Miro Hrončok wrote:
> On 03. 12. 21 22:01, Richard W.M. Jones wrote:
> >I don't follow this part of the original message.  In, for example,
> >nbdkit-curl-plugin we have:
> >
> >$ rpm -qf /usr/lib64/nbdkit/plugins/nbdkit-curl-plugin.so
> >nbdkit-curl-plugin-1.29.6-1.fc36.x86_64
> >$ eu-readelf -d /usr/lib64/nbdkit/plugins/nbdkit-curl-plugin.so  | grep 
> >NEEDED
> >   NEEDEDShared library: [libcurl.so.4]
> >   NEEDEDShared library: [libgcc_s.so.1]
> >   NEEDEDShared library: [libc.so.6]
> >
> >and we definitely*do*  want those automatically generated
> >dependencies, and at the moment we get them.
> 
> Yes for Requires, that would remaian the same.
> But we don't want to Provide nbdkit-curl-plugin.so automatically.

Oh I get what you mean now, in that case I agree.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.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: why do elf dependency generators cover libraries in paths outside of the library load paths?

[Miro Hrončok]

On 03. 12. 21 21:46, Chris Adams wrote:

Also: why are you using a private bundled copy of OpenSSL?  Isn't that
against the packaging guidelines?


Well, that is clearly a bug, that's why https://bugzilla.redhat.com/2028852 is 
still open.


--
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: why do elf dependency generators cover libraries in paths outside of the library load paths?

[Miro Hrončok]

On 03. 12. 21 22:01, Richard W.M. Jones wrote:

I don't follow this part of the original message.  In, for example,
nbdkit-curl-plugin we have:

$ rpm -qf /usr/lib64/nbdkit/plugins/nbdkit-curl-plugin.so
nbdkit-curl-plugin-1.29.6-1.fc36.x86_64
$ eu-readelf -d /usr/lib64/nbdkit/plugins/nbdkit-curl-plugin.so  | grep NEEDED
   NEEDEDShared library: [libcurl.so.4]
   NEEDEDShared library: [libgcc_s.so.1]
   NEEDEDShared library: [libc.so.6]

and we definitely*do*  want those automatically generated
dependencies, and at the moment we get them.


Yes for Requires, that would remaian the same.
But we don't want to Provide nbdkit-curl-plugin.so automatically.

--
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: why do elf dependency generators cover libraries in paths outside of the library load paths?

[Richard W.M. Jones]

On Fri, Dec 03, 2021 at 09:23:39PM +0100, Miro Hrončok wrote:
> On 03. 12. 21 21:10, Miro Hrončok wrote:
> >On 03. 12. 21 20:53, Zbigniew Jędrzejewski-Szmek wrote:
> >>We had an incident today [1] that opae-devel has auto-generated provides
> >>like libcrypto.so.1.1()(64bit), generated for the bundled copy of openssl
> >>(/usr/lib/python3.10/site-packages/pacsign/hsm_managers/openssl/library/libcrypto.so).
> >>
> >>It was pulled into the buildroot instead of the expected openssl1.1 package.
> >>Those deps are generated by /usr/lib/rpm/elfdeps, which is configured in
> >>/usr/lib/rpm/fileattrs/elf.attr to act on anything that matches the
> >>file magic of '^(setuid,? )?(setgid,? )?(sticky )?ELF (32|64)-bit.*$'.
> >>
> >>My question: shouldn't we limit the elfdeps generator to files which
> >>are in paths that can be loaded automatically by the linker? (This
> >>could be implemented as e.g. the paths that are default like
> >>/usr/lib64, /usr/local/lib64, …, depending on the architecture, and if
> >>the package installs anything in /etc/ld.so/, also the paths listed there.)
> >>
> >>I always understood those Provides/Requires to be used for library
> >>dependency resolution, and it doesn't seem to make sense to generate
> >>them for plugins and other "private" objects outside of the linker
> >>load paths.

I don't follow this part of the original message.  In, for example,
nbdkit-curl-plugin we have:

$ rpm -qf /usr/lib64/nbdkit/plugins/nbdkit-curl-plugin.so 
nbdkit-curl-plugin-1.29.6-1.fc36.x86_64
$ eu-readelf -d /usr/lib64/nbdkit/plugins/nbdkit-curl-plugin.so  | grep NEEDED
  NEEDEDShared library: [libcurl.so.4]
  NEEDEDShared library: [libgcc_s.so.1]
  NEEDEDShared library: [libc.so.6]

and we definitely *do* want those automatically generated
dependencies, and at the moment we get them.

> >>I think it's much much more common to have .so libraries outside of
> >>the linker paths for which we don't want the automatic provides
> >>(python modules, java extensions, various loadable plugins), than to
> >>have shared libraries in some custom directory. This should eliminate
> >>most of the stupid issues where a "private" dependency leaks and
> >>breaks other packages.
> >>
> >>[1] bugzilla.redhat.com/2028852
> >
> >As one of the Fedora's Python maintainers, I fully support the
> >idea of only generating provides from "normal" library
> >directories.
> >
> >We still have Python packages that accidentally provide stuff like:
> >
> >lib.cpython-310-x86_64-linux-gnu.so()(64bit)
> >libcalignedsegment.cpython-310-x86_64-linux-gnu.so()(64bit)
> >libcalignmentfile.cpython-310-x86_64-linux-gnu.so()(64bit)
> >libcbcf.cpython-310-x86_64-linux-gnu.so()(64bit)
> >libcbcftools.cpython-310-x86_64-linux-gnu.so()(64bit)
> >libcbgzf.cpython-310-x86_64-linux-gnu.so()(64bit)
> >libcfaidx.cpython-310-x86_64-linux-gnu.so()(64bit)
> >libchtslib.cpython-310-x86_64-linux-gnu.so()(64bit)
> >libcsamfile.cpython-310-x86_64-linux-gnu.so()(64bit)
> >libcsamtools.cpython-310-x86_64-linux-gnu.so()(64bit)
> >libctabix.cpython-310-x86_64-linux-gnu.so()(64bit)
> >libctabixproxies.cpython-310-x86_64-linux-gnu.so()(64bit)
> >libcutils.cpython-310-x86_64-linux-gnu.so()(64bit)
> >libcvcf.cpython-310-x86_64-linux-gnu.so()(64bit)
> >libexiv2python.cpython-310-x86_64-linux-gnu.so()(64bit)
> >libguestfsmod.cpython-310-x86_64-linux-gnu.so()(64bit)
> >libhivexmod.cpython-310-x86_64-linux-gnu.so()(64bit)
> >libiscsi.cpython-310-x86_64-linux-gnu.so()(64bit)
> >liblo.cpython-310-x86_64-linux-gnu.so()(64bit)
> >libpyuhd.cpython-310-x86_64-linux-gnu.so()(64bit)
> >libtorrent.cpython-310-x86_64-linux-gnu.so()(64bit)

However these Python ones do seem like they could be wrong, but I'm
not sure if they are harmful.

What's bad about these?

Rich.

> >(This is actually from Fedora Rawhide, as of today.)
> 
> For completeness, they can/should be removed by:
> 
>   %global __provides_exclude_from ^(%{python_sitearch}/.*\\.so)$
> 
> The list of components:
> 
> hivex:
> libhivexmod.cpython-310-x86_64-linux-gnu.so()(64bit)
> 
> iscsi-initiator-utils:
> libiscsi.cpython-310-x86_64-linux-gnu.so()(64bit)
> 
> libguestfs:
> libguestfsmod.cpython-310-x86_64-linux-gnu.so()(64bit)
> 
> pyliblo:
> liblo.cpython-310-x86_64-linux-gnu.so()(64bit)
> 
> python-pandas:
> lib.cpython-310-x86_64-linux-gnu.so()(64bit)
> 
> python-pysam:
> libcalignedsegment.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcalignmentfile.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcbcf.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcbcftools.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcbgzf.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcfaidx.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcsamfile.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcsamtools.cpython-310-x86_64-linux-gnu.so()(64bit)
> libctabix.cpython-310-x86_64-linux-gnu.so()(64bit)
> libctabixproxies.cpython-310-x86_64-linux-gnu.so()(64bit)
>  

Re: why do elf dependency generators cover libraries in paths outside of the library load paths?

[Chris Adams]

Once upon a time, Zbigniew Jędrzejewski-Szmek  said:
> My question: shouldn't we limit the elfdeps generator to files which
> are in paths that can be loaded automatically by the linker? (This
> could be implemented as e.g. the paths that are default like
> /usr/lib64, /usr/local/lib64, …, depending on the architecture, and if
> the package installs anything in /etc/ld.so/, also the paths listed there.)

Filtering those out would break auto-generated dependencies.

Also: why are you using a private bundled copy of OpenSSL?  Isn't that
against the packaging guidelines?

-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Josh Boyer]

On Fri, Dec 3, 2021 at 1:15 PM Davide Cavalca  wrote:
>
> On Thu, 2021-12-02 at 19:10 -0500, Josh Boyer wrote:
> > On Thu, Dec 2, 2021, 5:33 PM Davide Cavalca via devel
> >  wrote:
> >
> > > Correct, XFS doesn't support fs-verity at the moment (though it
> > > could
> > > be implemented if one wanted to).
> >
> > That means it would exclude Fedora Server and ELN as they are XFS
> > based.
>
> There isn't any impact on XFS-based editions by default. Building and
> signing RPMs with fs-verity works fine, as there's no filesystem
> dependency for that. Installing RPMs also works fine, with one caveat:
> if you're running a system with an unsupported filesystem and have rpm-
> plugin-fsverity (which is not installed by default), fs-verity will not
> be enabled for the installed files so there will be no verification
> (but the RPM installation itself should succeed).

Yes, thank you.  I meant it would render those Editions/projects
unable to use this Change.  It's not the end of the world, just an
observation.

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: why do elf dependency generators cover libraries in paths outside of the library load paths?

[Miro Hrončok]

On 03. 12. 21 21:10, Miro Hrončok wrote:

On 03. 12. 21 20:53, Zbigniew Jędrzejewski-Szmek wrote:

We had an incident today [1] that opae-devel has auto-generated provides
like libcrypto.so.1.1()(64bit), generated for the bundled copy of openssl
(/usr/lib/python3.10/site-packages/pacsign/hsm_managers/openssl/library/libcrypto.so). 


It was pulled into the buildroot instead of the expected openssl1.1 package.
Those deps are generated by /usr/lib/rpm/elfdeps, which is configured in
/usr/lib/rpm/fileattrs/elf.attr to act on anything that matches the
file magic of '^(setuid,? )?(setgid,? )?(sticky )?ELF (32|64)-bit.*$'.

My question: shouldn't we limit the elfdeps generator to files which
are in paths that can be loaded automatically by the linker? (This
could be implemented as e.g. the paths that are default like
/usr/lib64, /usr/local/lib64, …, depending on the architecture, and if
the package installs anything in /etc/ld.so/, also the paths listed there.)

I always understood those Provides/Requires to be used for library
dependency resolution, and it doesn't seem to make sense to generate
them for plugins and other "private" objects outside of the linker
load paths.

I think it's much much more common to have .so libraries outside of
the linker paths for which we don't want the automatic provides
(python modules, java extensions, various loadable plugins), than to
have shared libraries in some custom directory. This should eliminate
most of the stupid issues where a "private" dependency leaks and
breaks other packages.

[1] bugzilla.redhat.com/2028852


As one of the Fedora's Python maintainers, I fully support the idea of only 
generating provides from "normal" library directories.


We still have Python packages that accidentally provide stuff like:

lib.cpython-310-x86_64-linux-gnu.so()(64bit)
libcalignedsegment.cpython-310-x86_64-linux-gnu.so()(64bit)
libcalignmentfile.cpython-310-x86_64-linux-gnu.so()(64bit)
libcbcf.cpython-310-x86_64-linux-gnu.so()(64bit)
libcbcftools.cpython-310-x86_64-linux-gnu.so()(64bit)
libcbgzf.cpython-310-x86_64-linux-gnu.so()(64bit)
libcfaidx.cpython-310-x86_64-linux-gnu.so()(64bit)
libchtslib.cpython-310-x86_64-linux-gnu.so()(64bit)
libcsamfile.cpython-310-x86_64-linux-gnu.so()(64bit)
libcsamtools.cpython-310-x86_64-linux-gnu.so()(64bit)
libctabix.cpython-310-x86_64-linux-gnu.so()(64bit)
libctabixproxies.cpython-310-x86_64-linux-gnu.so()(64bit)
libcutils.cpython-310-x86_64-linux-gnu.so()(64bit)
libcvcf.cpython-310-x86_64-linux-gnu.so()(64bit)
libexiv2python.cpython-310-x86_64-linux-gnu.so()(64bit)
libguestfsmod.cpython-310-x86_64-linux-gnu.so()(64bit)
libhivexmod.cpython-310-x86_64-linux-gnu.so()(64bit)
libiscsi.cpython-310-x86_64-linux-gnu.so()(64bit)
liblo.cpython-310-x86_64-linux-gnu.so()(64bit)
libpyuhd.cpython-310-x86_64-linux-gnu.so()(64bit)
libtorrent.cpython-310-x86_64-linux-gnu.so()(64bit)

(This is actually from Fedora Rawhide, as of today.)


For completeness, they can/should be removed by:

  %global __provides_exclude_from ^(%{python_sitearch}/.*\\.so)$

The list of components:

hivex:
libhivexmod.cpython-310-x86_64-linux-gnu.so()(64bit)

iscsi-initiator-utils:
libiscsi.cpython-310-x86_64-linux-gnu.so()(64bit)

libguestfs:
libguestfsmod.cpython-310-x86_64-linux-gnu.so()(64bit)

pyliblo:
liblo.cpython-310-x86_64-linux-gnu.so()(64bit)

python-pandas:
lib.cpython-310-x86_64-linux-gnu.so()(64bit)

python-pysam:
libcalignedsegment.cpython-310-x86_64-linux-gnu.so()(64bit)
libcalignmentfile.cpython-310-x86_64-linux-gnu.so()(64bit)
libcbcf.cpython-310-x86_64-linux-gnu.so()(64bit)
libcbcftools.cpython-310-x86_64-linux-gnu.so()(64bit)
libcbgzf.cpython-310-x86_64-linux-gnu.so()(64bit)
libcfaidx.cpython-310-x86_64-linux-gnu.so()(64bit)
libcsamfile.cpython-310-x86_64-linux-gnu.so()(64bit)
libcsamtools.cpython-310-x86_64-linux-gnu.so()(64bit)
libctabix.cpython-310-x86_64-linux-gnu.so()(64bit)
libctabixproxies.cpython-310-x86_64-linux-gnu.so()(64bit)
libcutils.cpython-310-x86_64-linux-gnu.so()(64bit)
libcvcf.cpython-310-x86_64-linux-gnu.so()(64bit)
libchtslib.cpython-310-x86_64-linux-gnu.so()(64bit)

python3-exiv2:
libexiv2python.cpython-310-x86_64-linux-gnu.so()(64bit)

rb_libtorrent:
libtorrent.cpython-310-x86_64-linux-gnu.so()(64bit)

uhd:
libpyuhd.cpython-310-x86_64-linux-gnu.so()(64bit)


Maintainers by package:
hivexmdbooth rjones
iscsi-initiator-utils cleech grover jwrdegoede
libguestfs   mdbooth rjones
pyliblo  fab
python-pandaskushal orion sergiopr wakko666
python-pysam davidsch
python3-exiv2asn
rb_libtorrentfale mooninite
uhd  jskarvad

Packages by maintainer (BCC'ed):
asnpython3-exiv2
cleech iscsi-initiator-utils
davidsch   python-pysam
fabpyliblo
fale   rb_libtorrent
grover iscsi-initiator-utils
jskarvad   uhd
jwrdegoede iscsi-initiator-utils
kushal python-pandas

Re: why do elf dependency generators cover libraries in paths outside of the library load paths?

[Vitaly Zaitsev via devel]

On 03/12/2021 20:53, Zbigniew Jędrzejewski-Szmek wrote:

My question: shouldn't we limit the elfdeps generator to files which
are in paths that can be loaded automatically by the linker? (This
could be implemented as e.g. the paths that are default like
/usr/lib64, /usr/local/lib64, …, depending on the architecture, and if
the package installs anything in/etc/ld.so/, also the paths listed there.)


+1. Manual filtering of Provides is a pain.

--
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: why do elf dependency generators cover libraries in paths outside of the library load paths?

[Neal Gompa]

On Fri, Dec 3, 2021 at 3:10 PM Miro Hrončok  wrote:
>
> On 03. 12. 21 20:53, Zbigniew Jędrzejewski-Szmek wrote:
> > We had an incident today [1] that opae-devel has auto-generated provides
> > like libcrypto.so.1.1()(64bit), generated for the bundled copy of openssl
> > (/usr/lib/python3.10/site-packages/pacsign/hsm_managers/openssl/library/libcrypto.so).
> > It was pulled into the buildroot instead of the expected openssl1.1 package.
> > Those deps are generated by /usr/lib/rpm/elfdeps, which is configured in
> > /usr/lib/rpm/fileattrs/elf.attr to act on anything that matches the
> > file magic of '^(setuid,? )?(setgid,? )?(sticky )?ELF (32|64)-bit.*$'.
> >
> > My question: shouldn't we limit the elfdeps generator to files which
> > are in paths that can be loaded automatically by the linker? (This
> > could be implemented as e.g. the paths that are default like
> > /usr/lib64, /usr/local/lib64, …, depending on the architecture, and if
> > the package installs anything in /etc/ld.so/, also the paths listed there.)
> >
> > I always understood those Provides/Requires to be used for library
> > dependency resolution, and it doesn't seem to make sense to generate
> > them for plugins and other "private" objects outside of the linker
> > load paths.
> >
> > I think it's much much more common to have .so libraries outside of
> > the linker paths for which we don't want the automatic provides
> > (python modules, java extensions, various loadable plugins), than to
> > have shared libraries in some custom directory. This should eliminate
> > most of the stupid issues where a "private" dependency leaks and
> > breaks other packages.
> >
> > [1] bugzilla.redhat.com/2028852
>
> As one of the Fedora's Python maintainers, I fully support the idea of only
> generating provides from "normal" library directories.
>
> We still have Python packages that accidentally provide stuff like:
>
> lib.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcalignedsegment.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcalignmentfile.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcbcf.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcbcftools.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcbgzf.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcfaidx.cpython-310-x86_64-linux-gnu.so()(64bit)
> libchtslib.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcsamfile.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcsamtools.cpython-310-x86_64-linux-gnu.so()(64bit)
> libctabix.cpython-310-x86_64-linux-gnu.so()(64bit)
> libctabixproxies.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcutils.cpython-310-x86_64-linux-gnu.so()(64bit)
> libcvcf.cpython-310-x86_64-linux-gnu.so()(64bit)
> libexiv2python.cpython-310-x86_64-linux-gnu.so()(64bit)
> libguestfsmod.cpython-310-x86_64-linux-gnu.so()(64bit)
> libhivexmod.cpython-310-x86_64-linux-gnu.so()(64bit)
> libiscsi.cpython-310-x86_64-linux-gnu.so()(64bit)
> liblo.cpython-310-x86_64-linux-gnu.so()(64bit)
> libpyuhd.cpython-310-x86_64-linux-gnu.so()(64bit)
> libtorrent.cpython-310-x86_64-linux-gnu.so()(64bit)
>
> (This is actually from Fedora Rawhide, as of today.)
>

The issue is self-Requires. Because the RPM dependency generator
doesn't cancel out self-Requires, filtering out Provides leads to
broken Requires in a lot of cases.



-- 
真実はいつも一つ！/ 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: why do elf dependency generators cover libraries in paths outside of the library load paths?

[Miro Hrončok]

On 03. 12. 21 20:53, Zbigniew Jędrzejewski-Szmek wrote:

We had an incident today [1] that opae-devel has auto-generated provides
like libcrypto.so.1.1()(64bit), generated for the bundled copy of openssl
(/usr/lib/python3.10/site-packages/pacsign/hsm_managers/openssl/library/libcrypto.so).
It was pulled into the buildroot instead of the expected openssl1.1 package.
Those deps are generated by /usr/lib/rpm/elfdeps, which is configured in
/usr/lib/rpm/fileattrs/elf.attr to act on anything that matches the
file magic of '^(setuid,? )?(setgid,? )?(sticky )?ELF (32|64)-bit.*$'.

My question: shouldn't we limit the elfdeps generator to files which
are in paths that can be loaded automatically by the linker? (This
could be implemented as e.g. the paths that are default like
/usr/lib64, /usr/local/lib64, …, depending on the architecture, and if
the package installs anything in /etc/ld.so/, also the paths listed there.)

I always understood those Provides/Requires to be used for library
dependency resolution, and it doesn't seem to make sense to generate
them for plugins and other "private" objects outside of the linker
load paths.

I think it's much much more common to have .so libraries outside of
the linker paths for which we don't want the automatic provides
(python modules, java extensions, various loadable plugins), than to
have shared libraries in some custom directory. This should eliminate
most of the stupid issues where a "private" dependency leaks and
breaks other packages.

[1] bugzilla.redhat.com/2028852


As one of the Fedora's Python maintainers, I fully support the idea of only 
generating provides from "normal" library directories.


We still have Python packages that accidentally provide stuff like:

lib.cpython-310-x86_64-linux-gnu.so()(64bit)
libcalignedsegment.cpython-310-x86_64-linux-gnu.so()(64bit)
libcalignmentfile.cpython-310-x86_64-linux-gnu.so()(64bit)
libcbcf.cpython-310-x86_64-linux-gnu.so()(64bit)
libcbcftools.cpython-310-x86_64-linux-gnu.so()(64bit)
libcbgzf.cpython-310-x86_64-linux-gnu.so()(64bit)
libcfaidx.cpython-310-x86_64-linux-gnu.so()(64bit)
libchtslib.cpython-310-x86_64-linux-gnu.so()(64bit)
libcsamfile.cpython-310-x86_64-linux-gnu.so()(64bit)
libcsamtools.cpython-310-x86_64-linux-gnu.so()(64bit)
libctabix.cpython-310-x86_64-linux-gnu.so()(64bit)
libctabixproxies.cpython-310-x86_64-linux-gnu.so()(64bit)
libcutils.cpython-310-x86_64-linux-gnu.so()(64bit)
libcvcf.cpython-310-x86_64-linux-gnu.so()(64bit)
libexiv2python.cpython-310-x86_64-linux-gnu.so()(64bit)
libguestfsmod.cpython-310-x86_64-linux-gnu.so()(64bit)
libhivexmod.cpython-310-x86_64-linux-gnu.so()(64bit)
libiscsi.cpython-310-x86_64-linux-gnu.so()(64bit)
liblo.cpython-310-x86_64-linux-gnu.so()(64bit)
libpyuhd.cpython-310-x86_64-linux-gnu.so()(64bit)
libtorrent.cpython-310-x86_64-linux-gnu.so()(64bit)

(This is actually from Fedora Rawhide, as of today.)

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

why do elf dependency generators cover libraries in paths outside of the library load paths?

[Zbigniew Jędrzejewski-Szmek]

We had an incident today [1] that opae-devel has auto-generated provides
like libcrypto.so.1.1()(64bit), generated for the bundled copy of openssl
(/usr/lib/python3.10/site-packages/pacsign/hsm_managers/openssl/library/libcrypto.so).
It was pulled into the buildroot instead of the expected openssl1.1 package.
Those deps are generated by /usr/lib/rpm/elfdeps, which is configured in
/usr/lib/rpm/fileattrs/elf.attr to act on anything that matches the
file magic of '^(setuid,? )?(setgid,? )?(sticky )?ELF (32|64)-bit.*$'.

My question: shouldn't we limit the elfdeps generator to files which
are in paths that can be loaded automatically by the linker? (This
could be implemented as e.g. the paths that are default like
/usr/lib64, /usr/local/lib64, …, depending on the architecture, and if
the package installs anything in /etc/ld.so/, also the paths listed there.)

I always understood those Provides/Requires to be used for library
dependency resolution, and it doesn't seem to make sense to generate
them for plugins and other "private" objects outside of the linker
load paths.

I think it's much much more common to have .so libraries outside of
the linker paths for which we don't want the automatic provides
(python modules, java extensions, various loadable plugins), than to
have shared libraries in some custom directory. This should eliminate
most of the stupid issues where a "private" dependency leaks and
breaks other packages.

[1] bugzilla.redhat.com/2028852

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: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Boris Burkov via devel]

Errors at installation time should be fully diagnosable, and even if the output 
today doesn't make it totally obvious what happened, it would be easy to fix in 
rpm.

The errors post-install are a bit trickier. Imagine you install your rpm, and 
kick off some long running daemon from it. A month later, a block gets 
corrupted in a way fs checksums don't catch (e.g. ext4, btrfs nodatasum, evil 
maid), and suddenly that daemon receives a SIGBUS and crashes. You would be 
able to see clearly that it was a verity issue in dmesg, but I don't think the 
binary could reasonably know what happened or write a meaningful log. In that 
sense, I think it's actually pretty similar to the experience if you have 
corruption in your disk and start getting btrfs checksum errors on a 
file--you'd have to look in dmesg to know why your file is broken.

The middle ground is when opening/exec-ing the file fails. In that case, you 
might get a sufficiently specific error code you could figure out it's verity, 
and the full error would be in dmesg as well.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Tom Seewald]

> I think there are two cases of interest:
> 
> 1) a file or signature in the rpm is corrupted, the signature doesn't have a 
> matching
> cert installed, etc...
> in this case, if the plugin is present, when you attempt to install the rpm 
> the verity
> enable ioctl will explicitly fail, and presumably so will the rpm install. 
> You can see
> most of the details for this sort of case here in the rpm plugin code:
> https://github.com/rpm-software-management/rpm/blob/master/plugins/fsveri
> 
> 2) after installation, a file from an fs-verity enabled rpm gets one or more 
> blocks
> corrupted
> The first read of a corrupted block from disk (the good uncorrupted page 
> might survive in
> page cache for a while) will result in EIO for read-like system calls and 
> SIGBUS if the
> file is mapped (executables, mmap).

Thanks for the information. So in the event of an error, it's expected that the 
user would be informed that the error was due to a rpm-fsverity check and they 
could potentially reinstall the rpm from a trusted source to resolve the 
problem? Of course there's the underlying issue of _why_ it happened, but from 
the standpoint of wanting an immediate path forward.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

phoronix-test-suite 10.6.1 in Rawhide and F35

[Michel Alexandre Salim]

Hi,

On Fri, Dec 03, 2021 at 05:26:42AM -, Reon Beon via devel wrote:
> https://src.fedoraproject.org/rpms/phoronix-test-suite/pull-request/3

I've just put up an update for F35, please test

https://bodhi.fedoraproject.org/updates/FEDORA-2021-b353ab9902

Given this is a major upgrade from the previous 9.0.1 we shipped, I've
left the autokarma setting to requiring +3 to make sure this does not
get prematurely pushed.

As stated before, comaintainers welcome.

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


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: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Boris Burkov via devel]

I omitted one more interesting case.

If the verity metadata (signature, root hash) is corrupted after installation 
but before the file is opened, then opening/exec-ing the file can fail. Also, 
if pages from a binary read in during the exec itself are corrupted, the system 
call itself could fail (rather than the process getting sigbus like for a 
random page during execution)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Davide Cavalca via devel]

On Thu, 2021-12-02 at 19:10 -0500, Josh Boyer wrote:
> On Thu, Dec 2, 2021, 5:33 PM Davide Cavalca via devel
>  wrote:
> 
> > Correct, XFS doesn't support fs-verity at the moment (though it
> > could
> > be implemented if one wanted to).
> 
> That means it would exclude Fedora Server and ELN as they are XFS
> based.

There isn't any impact on XFS-based editions by default. Building and
signing RPMs with fs-verity works fine, as there's no filesystem
dependency for that. Installing RPMs also works fine, with one caveat:
if you're running a system with an unsupported filesystem and have rpm-
plugin-fsverity (which is not installed by default), fs-verity will not
be enabled for the installed files so there will be no verification
(but the RPM installation itself should succeed).

Cheers
Davide
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Is there a problem if we add ~4 thousand automatically generated obsoletes?

[Kevin Fenzi]

On Wed, Dec 01, 2021 at 02:06:41PM +0100, Miro Hrončok wrote:
> See 
> https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/2OCCFIKT7LZ7IPO3OKIEH3TDTGERSORM/
> 
> Would adding automatically generated obsoletes to 3624 Python packages have
> any observable negative impact (e.g. on the repodata size or time to resolve
> deps)?

I think that would increase the size of the primary repodata...

I guess by number * length of obsolete, so might not be that bad?

It would likely affect dnf processing time as well, but not sure how
much. 

It seems like something to try and avoid if possible.

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: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Davide Cavalca via devel]

On Thu, 2021-12-02 at 20:05 -0500, Josh Boyer wrote:
> Yes, I saw that and I appreciate it.  That's a comparison between the
> two implementations.  I am asking about what benefits and use cases
> fs-verity solves in Fedora.  Right now, the change simply says:
> 
> "The main benefit is the ability to do block-level verification of
> RPM-installed files. In turn, this can be used to implement
> usecase-specific validation and verification policies depending on
> the
> environment requirements."
> 
> which is also largely true of IMA.  The IMA change went into more
> detailed use cases, which perhaps may have been it's downfall.  So
> can
> you describe what most Fedora users would use this for or benefit
> from
> it?  Or if "most users" is not an applicable qualifier, can you at
> least give some more detailed use cases that you would expect people
> to use it for?

Broadly speaking, fs-verity makes it possible to ensure that files that
were installed via an RPM have not been modified. It is useful in
environments where an attacker might be able to modify system files
(say, replace /bin/ls with a compromised version) and you want to
protect against that. For example, consider an appliance-like system
placed in an untrusted location where you may not be able to control
who has physical access (this could be a server, but it could also be a
kiosk in an internet point or a school). In this scenario, fs-verity
can be one of the building blocks to ensure and maintain system trust.

This Change is mostly about putting in place the necessary plumbing for
this to be at all possible. We'll try to expand the Change proposal and
flesh out potential usecases a bit more.

> OK.  I guess I was looking for some side-by-side data comparisons in
> the overhead between IMA metadata and fs-verity.  "1/127th of the
> original Merkel tree size" doesn't tell me much.
> 
> Are there some test runs with numbers to show before/after data for
> both the RPM size and installed FS usage?  Perhaps with an example
> install.  The IMA change attempted to document this and seeing a 1.1%
> average increase in RPM size was easier to understand.

We've done some empirical testing on this (showing neglibible
increases), but still need to gather more formal data. We'll try to
prioritize that and add it to the Change once it's available.

Cheers
Davide
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)

[Cristian Ciupitu]

`plocate` does not have an option which `mlocate` [1] has:

>  -A, --all
>Print only names which match all non-option arguments, not
>those matching one or more non-option arguments.

The same could be achieved using extended regular expressions i.e.
`--regex`, but it's cumbersome.

Say I want to find out all documents about Fedora IoT security. Compare:

mlocate -i -A fedora iot security

with:

plocate -i --regex 
'fedora.*iot.*security|fedora.*security.*iot|iot.*fedora.*security|iot.*security.*fedora|security.*fedora.*iot|security.*iot.*fedora'

This is needed because the order of the words is not fixed; results
could include for example `Security/Fedora IoT.pdf` or
`Fedora/IoT/Security.pdf`.

Speaking of security, `systemd-analyze security plocate-updatedb.service`
suggests a couple of improvements which could be made, e.g.
LockPersonality or ProtectClock.



[1]: https://man7.org/linux/man-pages/man1/locate.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: cmake on Rawhide is broken

[Tom Hughes via devel]

On 03/12/2021 17:48, Simo Sorce wrote:

On Fri, 2021-12-03 at 17:25 +, Tom Hughes via devel wrote:

On 03/12/2021 17:16, Vitaly Zaitsev via devel wrote:

On 03/12/2021 17:41, Miro Hrončok wrote:


The bundled openssl in opae worries me still, but that's not causing
issues in dependency resolution any more.


I think FESCo should create a strict policy on bundling cryptographic
libraries.


Well bundling a binary from upstream is already against policy
so I don't see how that helps.

The problem isn't a lack of policy, it's that the packager didn't
notice those files or didn't realise they weren't allowed.


So the opae-2.0.0 tarball has libcrypto embedded-in what is the process
now ?

This stuff is used for a Python tool that is used to sign some binary,
almost certainly there is absolutely no reason to bundle libcrypto, the
tool should probably be unbundled and turned into a regular python
module opae depends on.


It has an openssl.py that dlopen's the so:

  def _find_openssl_so(self, version, *paths):

candidates = list(paths)

crypto = util.find_library('crypto')
if crypto:

  candidates.insert(0, crypto)

for c in candidates:

  dll = CDLL(c)


So that might already find the system one if you have it
but probably only if you have openssl-devel installed to
get the .so link with no version.

But dropping the binaries and doing a relatively minor
patch to that is likely all that is needed.


Do we know who is the current maintainer?
The changelog seem to imply Intel dropped it into Fedora and never
maintained it after Sep 17 2020 ...


Well src.fpo says trix aka Tom Rix is the maintainer.

Tom

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

[EPEL-devel] EPEL 9 is now available

[Troy Dawson]

On behalf of the EPEL Steering Committee, I’m pleased to announce the
availability of EPEL 9. This is the culmination of five months of work
between the EPEL Steering Committee, the Fedora Infrastructure and Release
Engineering team, and other contributors. Package maintainers can now
request dist-git branches, trigger Koji builds, and submit Bodhi updates
for EPEL 9 packages.

Instructions to enable the EPEL repository are available in our
documentation.[1] If there is a Fedora package you would like to see added
to EPEL 9, please let the relevant package maintainer know with a package
request.[2]

Read more, including a FAQ, on the Fedora Blog.
https://communityblog.fedoraproject.org/epel-9-is-now-available/

Troy

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

[Bug 2028913] New: Please branch and build perl-GDGraph in epel9

[bugzilla]

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

Bug ID: 2028913
   Summary: Please branch and build perl-GDGraph in epel9
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-GDGraph
  Assignee: spo...@gmail.com
  Reporter: sa...@waytotheweb.com
QA Contact: extras...@fedoraproject.org
CC: jose.p.oliveira@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org, spo...@gmail.com
  Target Milestone: ---
Classification: Fedora



Please branch and build perl-GDGraph in epel9


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2028913
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2028912] New: Please branch and build perl-Linux-Inotify2 in epel9

[bugzilla]

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

Bug ID: 2028912
   Summary: Please branch and build perl-Linux-Inotify2 in epel9
   Product: Fedora EPEL
   Version: epel9
Status: NEW
 Component: perl-Linux-Inotify2
  Assignee: jples...@redhat.com
  Reporter: sa...@waytotheweb.com
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Please branch and build perl-Linux-Inotify2 in epel9


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2028912
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Boris Burkov via devel]

I think there are two cases of interest:

1) a file or signature in the rpm is corrupted, the signature doesn't have a 
matching cert installed, etc...
in this case, if the plugin is present, when you attempt to install the rpm the 
verity enable ioctl will explicitly fail, and presumably so will the rpm 
install. You can see most of the details for this sort of case here in the rpm 
plugin code: 
https://github.com/rpm-software-management/rpm/blob/master/plugins/fsverity.c#L114.

2) after installation, a file from an fs-verity enabled rpm gets one or more 
blocks corrupted
The first read of a corrupted block from disk (the good uncorrupted page might 
survive in page cache for a while) will result in EIO for read-like system 
calls and SIGBUS if the file is mapped (executables, mmap).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Davide Cavalca via devel]

On Fri, 2021-12-03 at 12:21 +0100, Vitaly Zaitsev via devel wrote:
> On 02/12/2021 20:36, Ben Cotton wrote:
> > Enable the use of fsverity for installed RPM files validation.
> 
> -1. RPM already supports files validation and this feature will waste
> file system space.

To clarify: RPM does support files validation, but fs-verity is more
than just that. With RPM, the validation only happens on install time,
and when one runs rpm -V manually. With fs-verity, the validation
happens on-demand whenever a block of a file that originated from an
RPM is accessed. This means, for example, that if an attacker replaces
/bin/ls on disk with a compromised one, the next time it's read from
disk (e.g. because you ran it) you will see a validation failure and
the syscall will be blocked, preventing the compromised code from being
executed.

About filesystem usage: unless you install rpm-plugin-fsverity (which
is not and will not be installed by default), there is no disk space
increase for verity-signed RPM packages. If you do install rpm-plugin-
fsverity, some disk space will be used for the Merkle tree as described
in the Change.

Cheers
Davide
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: cmake on Rawhide is broken

[Simo Sorce]

On Fri, 2021-12-03 at 17:25 +, Tom Hughes via devel wrote:
> On 03/12/2021 17:16, Vitaly Zaitsev via devel wrote:
> > On 03/12/2021 17:41, Miro Hrončok wrote:
> > 
> > > The bundled openssl in opae worries me still, but that's not causing 
> > > issues in dependency resolution any more. 
> > 
> > I think FESCo should create a strict policy on bundling cryptographic 
> > libraries.
> 
> Well bundling a binary from upstream is already against policy
> so I don't see how that helps.
> 
> The problem isn't a lack of policy, it's that the packager didn't
> notice those files or didn't realise they weren't allowed.

So the opae-2.0.0 tarball has libcrypto embedded-in what is the process
now ?

This stuff is used for a Python tool that is used to sign some binary,
almost certainly there is absolutely no reason to bundle libcrypto, the
tool should probably be unbundled and turned into a regular python
module opae depends on.

Do we know who is the current maintainer?
The changelog seem to imply Intel dropped it into Fedora and never
maintained it after Sep 17 2020 ...

Simo.

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

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc



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

Re: cmake on Rawhide is broken

[Daniel P . Berrangé]

On Fri, Dec 03, 2021 at 05:41:31PM +0100, Miro Hrončok wrote:
> On 03. 12. 21 16:06, Miro Hrončok wrote:
> > On 03. 12. 21 15:59, Miro Hrončok wrote:
> > > On 03. 12. 21 15:49, Miro Hrončok wrote:
> > > > On 03. 12. 21 15:45, Kamil Dudka wrote:
> > > > > On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel 
> > > > > wrote:
> > > 
> > > It seems that libarchive still requires libcrypto.so.1.1()(64bit)
> > > 
> > > But on x86_64, opae-devel provides that with:
> > > 
> > > ExclusiveArch:  x86_64
> > > 
> > > I'll report that.
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=2028852
> 
> The problem is now fixed. The bundled openssl in opae worries me still, but
> that's not causing issues in dependency resolution any more.

Bundling pre-built openssl is a serious problem, because Fedora
is required to strip various functionality from openssl at the
source level. We cannot ship these binaries in the RPM, nor can
we even have them in the source tarball AFAIK.

IOW, stripping the dependancies from the RPM here is not sufficient.
IIUC, the tarball needs to be unpacked, the openssl binaries removed,
and a new tarball created for import into Fedora dist-git lookside
archive storage.

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: rust: Request for packaging rust-html-escape and rust-smallbitvec

[Aleksei Bavshin]

On 12/3/21 03:15, Andreas Schneider wrote:

On Thursday, December 2, 2021 9:07:06 PM CET Aleksei Bavshin wrote:

`smallbitvec` deps are only needed for benchmark, so the test suite is
actually passing without these. Should be safe to drop with metadata patch.

rust-tiny_http 0.8.2 also has a benchmark-only dependency `fdlimit`
which we can drop.

The situation with tree-sitter-cli testsuite is complicated: it requires
a few other github repos with a grammar definitions and who knows what
else. I haven't succeeded in running it so far, so we can keep it turned
off. And that would make `rust-spin` update unnecessary.

The draft packages are available from
https://copr.fedorainfracloud.org/coprs/alebastr/rust-tree-sitter-cli/;
seems working with available grammar files (with exception of
`build-wasm` and `playground` subcommands which require emscripten).


This is great work, thank you very much. I didn't know that the tree-sitter-
cli needs it own package and can't be built in the current tree-sitter
package. So I will just continue to take care of tree-sitter and just build
the lib.

So having tree-sitter-cli in the next fedora version would be awesome.


Reviews (and PR for rust-tiny_http update) are sent.

Upstream issue for missing license file: 
https://github.com/tree-sitter/tree-sitter/issues/1520


Andreas, do you want to have comaintainer access to the tree-sitter-cli 
packages?




Best regards


Andreas



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: cmake on Rawhide is broken

[Vitaly Zaitsev via devel]

On 03/12/2021 18:25, Tom Hughes wrote:

Well bundling a binary from upstream is already against policy
so I don't see how that helps.


Yes, no pre-built binaries are allowed.


The problem isn't a lack of policy, it's that the packager didn't
notice those files or didn't realise they weren't allowed. 


I mean, FESCo should prohibit bundling of any cryptographic libraries 
because these libraries are the main source of critical vulnerabilities.


--
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: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Boris Burkov via devel]

The top-level hash is calculated for each file, then that hash is signed with 
the inputted rsa key pair and the signed hash is appended to the array of 
signed hashes in the rpm metadata. I am guessing the way we worded the proposal 
is a little unclear because we call it "the" signature when it's one rpm 
metadata item that's an array of the signatures.

fs-verity the kernel feature operates on a per-file basis, and since the 
ultimate goal is to deliver fs-verity enabled files on the installer's system, 
we need each file's signature in the rpm. At install, we call the fs-verity 
enable ioctl for each file, passing in its signature to make use of the kernel 
authentication functionality.

I'm happy to explain the exact flow at signing and at install in more detail if 
that would be helpful.

Boris
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: cmake on Rawhide is broken

[Tom Hughes via devel]

On 03/12/2021 17:16, Vitaly Zaitsev via devel wrote:

On 03/12/2021 17:41, Miro Hrončok wrote:

The bundled openssl in opae worries me still, but that's not causing 
issues in dependency resolution any more. 


I think FESCo should create a strict policy on bundling cryptographic 
libraries.


Well bundling a binary from upstream is already against policy
so I don't see how that helps.

The problem isn't a lack of policy, it's that the packager didn't
notice those files or didn't realise they weren't allowed.

Tom

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

Re: cmake on Rawhide is broken

[Vitaly Zaitsev via devel]

On 03/12/2021 17:41, Miro Hrončok wrote:

The problem is now fixed.


I can confirm. Many thanks.

The bundled openssl in opae worries me still, but that's not causing issues in dependency resolution any more. 


I think FESCo should create a strict policy on bundling cryptographic 
libraries.


--
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: cmake on Rawhide is broken

[Miro Hrončok]

On 03. 12. 21 16:06, Miro Hrončok wrote:

On 03. 12. 21 15:59, Miro Hrončok wrote:

On 03. 12. 21 15:49, Miro Hrončok wrote:

On 03. 12. 21 15:45, Kamil Dudka wrote:

On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote:

Hello all.

Cmake on Rawhide x86_64 tries to load legacy OpenSSL 1.1 with
libcrypto.so.1.1 and fails:

+ /usr/bin/cmake -S . -B redhat-linux-build
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF
-DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include
-DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
-DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
-DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DCMAKE_BUILD_TYPE=Release
RPM build errors:
/usr/bin/cmake: error while loading shared libraries: libcrypto.so.1.1:
cannot open shared object file: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build)
  Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build)
Child return code was: 1

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


Same issue with my build of cswrap.  It is weird that it happens on x86_64 
only:


 https://koji.fedoraproject.org/koji/taskinfo?taskID=79545725


This has surfaced by the last package in the default buildroot dropping the 
dependency on openssl1.1:


https://bugzilla.redhat.com/show_bug.cgi?id=2022026#c7


I see more apps affected:

 sh-5.1$ cmake --help
cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open 
shared object file: No such file or directory


 sh-5.1$ appstream-util --help
appstream-util: error while loading shared libraries: libcrypto.so.1.1: 
cannot open shared object file: No such file or directory


It seems that something still pulls in openssl1.1 on other architectures, 
e.g. in this build:


https://koschei.fedoraproject.org/build/11634367

Both aarch64 and ppc64le have openssl1.1 in the root.log


It seems that libarchive still requires libcrypto.so.1.1()(64bit)

But on x86_64, opae-devel provides that with:

ExclusiveArch:  x86_64

I'll report that.


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


The problem is now fixed. The bundled openssl in opae worries me still, but 
that's not causing issues in dependency resolution any more.


--
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: [Fedocal] Reminder meeting : ELN SIG

[Neal Gompa]

On Fri, Dec 3, 2021 at 11:13 AM Michel Alexandre Salim
 wrote:
>
> On Fri, Dec 03, 2021 at 08:45:05AM -0500, Stephen Gallagher wrote:
> > On Thu, Dec 2, 2021 at 11:05 AM Stephen Gallagher  
> > wrote:
> > >
> > > On Thu, Dec 2, 2021 at 7:00 AM  wrote:
> > > >
> > > > Dear all,
> > > >
> > > > You are kindly invited to the meeting:
> > > >ELN SIG on 2021-12-03 from 12:00:00 to 13:00:00 US/Eastern
> > > >At fedora-meet...@irc.libera.chat
> > > >
> > > > The meeting will be about:
> > >
> > > I don't currently have any items for the agenda this time, so I'll
> > > cancel the meeting unless someone replies to this email with a topic
> > > before I get in to work tomorrow morning.
> >
> >
> > The ELN SIG meeting today is cancelled. I will not be available to run
> > one on Dec. 17th... do we want to have one next week instead?
> Next week sounds good.
>

I'm fine with next week as well.



-- 
真実はいつも一つ！/ 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: jpegxl soname bump

[Sérgio Basto]

On Fri, 2021-12-03 at 15:36 +, Michael J Gruber wrote:
> F35 updates has libaom-3.2.0-2 and libjxl-0.6.1-6 already - so did
> the buildroot go through?
> (This conflicts with heif from rpmfusion, which I can't complain
> about here, of course.)

yes , buildroot go through , rpmfusion packages are fixed just need to
be published in repos 


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

Re: Koji scratch builds with old build repos ?

[Daniel P . Berrangé]

On Thu, Dec 02, 2021 at 03:00:54PM +0100, Florian Weimer wrote:
> * Daniel P. Berrangé:
> 
> > Basically I'd like to try a build in koji with each of the glibc
> > versions in:
> >   https://kojipkgs.fedoraproject.org/packages/glibc/2.34.9000/
> > to see if any one of those was the trigger.
> 
> And to answer your question: “fedpkg request-side-tag”, and then “koji
> tag” the older glibc builds into the side tag.

Thanks, that was exactly what I needed to learn !

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: Koji scratch builds with old build repos ?

[Daniel P . Berrangé]

On Thu, Dec 02, 2021 at 02:58:52PM +0100, Florian Weimer wrote:
> * Daniel P. Berrangé:
> 
> >
> > The same srpm builds fine in F35 build roots, but fails in F36 build
> > roots with bizarre make errors.  make appears to "loose" a bunch of
> > the rules in the makefile, despite them still actually existing when
> > I dump a copy of the makefile contents immediately before running
> > make. It is as if it sees only partial or corrupt content for the
> > makefile when it reads it.
> 
> Welcome to the club:
> 
>   [F36] OpenJDK fails to build (in virtualized env like koji builders)
>   
> 
> I'm beginning to suspect a bug in the glibc string functions. 8-(
> 
> I've been staring at the assembler code for a bit, but I don't see it.

If anyone else is seeing wierd build failures in F36 rawhide,
I'd encourage trying to set this env variable in the specfile
as a temporary workaround:

  export GLIBC_TUNABLES=glibc.cpu.hwcaps=-AVX512VL

This has allowed EDK2 to build successfully.

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: phoronix-test-suite pull request is there for 6 months

[Michel Alexandre Salim]

On Fri, Dec 03, 2021 at 08:25:45AM -0500, Neal Gompa wrote:
> On Fri, Dec 3, 2021 at 8:21 AM Richard Shaw  wrote:
> >
> > On Fri, Dec 3, 2021 at 7:15 AM Richard Shaw  wrote:
> >>
> >> On Thu, Dec 2, 2021 at 11:27 PM Reon Beon via devel 
> >>  wrote:
> >>>
> >>> https://src.fedoraproject.org/rpms/phoronix-test-suite/pull-request/3
> >>
> >>
> >> This is unfortunate and as much as I hate doing it sometimes you have to 
> >> "ping" people. They might have seen it initially but got busy with 
> >> something else and forgot.
> >>
> >> I would:
> >> 1. Update the PR so it can be merged again
> >> 2. Comment on the PR or maybe better send a ping email to 
> >> "phoronix-test-suite-maintain...@fedoraproject.org" which will send an 
> >> email to all maintainers (if there's more than one).
> >>
> >> There's a non-response procedure for maintainers but hopefully it will not 
> >> be necessary.
> >
> >
> > Replying to myself here after digging a bit, the only maintainer is on over 
> > 2400 packages, and their activity has been pretty light:
> >
> > https://src.fedoraproject.org/user/salimma
> >

Ah, that's a bit misleading, most of those are packages I have access to
via my Python SIG membership ;)

We really should consider changing that default view.

> > I scrolled through the commits briefly and didn't see one commit they made. 
> > I could have missed it, but that's hardly the point, other people have 
> > obviously been maintaining the package.
> >
> > The package probably needs a new maintainer or at least a co-maintainer.
> >
> 
> I don't think Michel was the maintainer of the package when he made
> the PR, he most likely got it recently and forgot about the PR to
> merge it. I've pinged him about it so he can take care of it.
> 
Yeah, I requested to take the package because of stalled PRs and branch
requests, but was on leave when I finally inherited it. Thanks for the
reminder!

That being said, I do welcome co-maintainers.

Best,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


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: [Fedocal] Reminder meeting : ELN SIG

[Michel Alexandre Salim]

On Fri, Dec 03, 2021 at 08:45:05AM -0500, Stephen Gallagher wrote:
> On Thu, Dec 2, 2021 at 11:05 AM Stephen Gallagher  wrote:
> >
> > On Thu, Dec 2, 2021 at 7:00 AM  wrote:
> > >
> > > Dear all,
> > >
> > > You are kindly invited to the meeting:
> > >ELN SIG on 2021-12-03 from 12:00:00 to 13:00:00 US/Eastern
> > >At fedora-meet...@irc.libera.chat
> > >
> > > The meeting will be about:
> >
> > I don't currently have any items for the agenda this time, so I'll
> > cancel the meeting unless someone replies to this email with a topic
> > before I get in to work tomorrow morning.
> 
> 
> The ELN SIG meeting today is cancelled. I will not be available to run
> one on Dec. 17th... do we want to have one next week instead?
Next week sounds good.

Best,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


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: Fedora 35 update failure from libjxl

[Felix Schwarz]

Am 03.12.21 um 16:19 schrieb Steven A. Falco:

What is the proper procedure to escalate this?  Should I create a bug?


Either create a bug or write to this mailing list (as you did).

I use bodhi only to give simple feedback or post easy workarounds. The interface 
is not suitable for discussions.


Regarding your last bodhi comment [1]:

> @fschwarz, so I get it right next time, are the errors below sufficient to
> justify the negative karma?

Not sure which package causes the problem. I could update libjxl to 0.6.1-6.fc35 
(which worked after removing the gimp heif plugin).


In general negative karma is not useful after the package went to stable. Just 
file a bug in that case and don't be afraid of filing issues which may get 
closed as "CANTFIX" or "NOTABUG". As long as you are respectful and employ 
common courtesy everything should be ok :-)



Felix

[1] 
https://bodhi.fedoraproject.org/updates/FEDORA-2021-ee6b5b458e#comment-2300180
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: jpegxl soname bump

[Michael J Gruber]

F35 updates has libaom-3.2.0-2 and libjxl-0.6.1-6 already - so did the 
buildroot go through?
(This conflicts with heif from rpmfusion, which I can't complain about here, of 
course.)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Fedora 35 update failure from libjxl

[Felix Schwarz]

Hi Steven,

Am 03.12.21 um 16:19 schrieb Steven A. Falco:

There was an update [1] to libjxl that appears to have broken some
dependencies (gimp-jxl-plugin, jxl-pixbuf-loader, libaom, etc.).

I'm not sure if the negative karma is helpful, since this update has already 
been pushed to stable a few days ago.


libheif is not part of Fedora (likely installed from rpmfusion-free) and
the update was not coordinated between Fedora + RPM Fusion (as expected - 
RPMFusion is an independent 3rd party repo.


I think there is some progress to rebuild the package but you should watch 
RPMFusion bug 6158: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6158


HTH
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

Fedora 35 update failure from libjxl

[Steven A. Falco]

There was an update [1] to libjxl that appears to have broken some dependencies 
(gimp-jxl-plugin, jxl-pixbuf-loader, libaom, etc.).

I'm not sure if the negative karma is helpful, since this update has already 
been pushed to stable a few days ago.

What is the proper procedure to escalate this?  Should I create a bug?

Steve

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2021-ee6b5b458e
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: cmake on Rawhide is broken

[Miro Hrončok]

On 03. 12. 21 15:59, Miro Hrončok wrote:

On 03. 12. 21 15:49, Miro Hrončok wrote:

On 03. 12. 21 15:45, Kamil Dudka wrote:

On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote:

Hello all.

Cmake on Rawhide x86_64 tries to load legacy OpenSSL 1.1 with
libcrypto.so.1.1 and fails:

+ /usr/bin/cmake -S . -B redhat-linux-build
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF
-DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include
-DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
-DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
-DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DCMAKE_BUILD_TYPE=Release
RPM build errors:
/usr/bin/cmake: error while loading shared libraries: libcrypto.so.1.1:
cannot open shared object file: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build)
  Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build)
Child return code was: 1

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


Same issue with my build of cswrap.  It is weird that it happens on x86_64 
only:


 https://koji.fedoraproject.org/koji/taskinfo?taskID=79545725


This has surfaced by the last package in the default buildroot dropping the 
dependency on openssl1.1:


https://bugzilla.redhat.com/show_bug.cgi?id=2022026#c7


I see more apps affected:

 sh-5.1$ cmake --help
cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open 
shared object file: No such file or directory


 sh-5.1$ appstream-util --help
appstream-util: error while loading shared libraries: libcrypto.so.1.1: 
cannot open shared object file: No such file or directory


It seems that something still pulls in openssl1.1 on other architectures, 
e.g. in this build:


https://koschei.fedoraproject.org/build/11634367

Both aarch64 and ppc64le have openssl1.1 in the root.log


It seems that libarchive still requires libcrypto.so.1.1()(64bit)

But on x86_64, opae-devel provides that with:

ExclusiveArch:  x86_64

I'll report that.


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

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

pghmcfc pushed to perl-MCE-Shared (rawhide). "Update to 1.875 (..more)"

[notifications]

Notification time stamped 2021-12-03 14:59:42 UTC

From e7a8dd1f6509de6c80fed28fd16bfc6f320aa1f2 Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Dec 03 2021 14:59:06 +
Subject: Update to 1.875


- New upstream release 1.875
  - Resolved edge case with _fill_index in MCE::Shared::Ordhash
  - Updated STORE, DELETE, and internal _fill_index
  - Added tests to t/07_shared_ordhash.t

---

diff --git a/perl-MCE-Shared.spec b/perl-MCE-Shared.spec
index d5bbcf0..5417d67 100644
--- a/perl-MCE-Shared.spec
+++ b/perl-MCE-Shared.spec
@@ -1,5 +1,5 @@
 Name:  perl-MCE-Shared
-Version:   1.874
+Version:   1.875
 Release:   1%{?dist}
 Summary:   MCE extension for sharing data, supporting threads and processes
 License:   GPL+ or Artistic
@@ -93,6 +93,12 @@ make test
 %{_mandir}/man3/MCE::Shared::Server.3*
 
 %changelog
+* Fri Dec  3 2021 Paul Howarth  - 1.875-1
+- Update to 1.875
+  - Resolved edge case with _fill_index in MCE::Shared::Ordhash
+  - Updated STORE, DELETE, and internal _fill_index
+  - Added tests to t/07_shared_ordhash.t
+
 * Fri Dec  3 2021 Paul Howarth  - 1.874-1
 - Update to 1.874
   - Bumped MCE dependency to 1.874
diff --git a/sources b/sources
index 27f4187..48cfa7e 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (MCE-Shared-1.874.tar.gz) = 
371b156ec721e305dbd10e7951bc227e77659d77aaf228373b8081d804c18663faf6198dd38bcdc9ca119709e599037a37c881fff2f420fbdc160e0f11ad776f
+SHA512 (MCE-Shared-1.875.tar.gz) = 
40eff54c9204543b091dd6805b7f69a903ced9a576e744b436c84cf1d4380994775498acc21ef21ef0c77862f14784ce9446970c300fab198ae7e703288a9399



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

Re: cmake on Rawhide is broken

[Miro Hrončok]

On 03. 12. 21 15:49, Miro Hrončok wrote:

On 03. 12. 21 15:45, Kamil Dudka wrote:

On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote:

Hello all.

Cmake on Rawhide x86_64 tries to load legacy OpenSSL 1.1 with
libcrypto.so.1.1 and fails:

+ /usr/bin/cmake -S . -B redhat-linux-build
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF
-DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include
-DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
-DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
-DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DCMAKE_BUILD_TYPE=Release
RPM build errors:
/usr/bin/cmake: error while loading shared libraries: libcrypto.so.1.1:
cannot open shared object file: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build)
  Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build)
Child return code was: 1

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


Same issue with my build of cswrap.  It is weird that it happens on x86_64 only:

 https://koji.fedoraproject.org/koji/taskinfo?taskID=79545725


This has surfaced by the last package in the default buildroot dropping the 
dependency on openssl1.1:


https://bugzilla.redhat.com/show_bug.cgi?id=2022026#c7


I see more apps affected:

 sh-5.1$ cmake --help
cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open 
shared object file: No such file or directory


 sh-5.1$ appstream-util --help
appstream-util: error while loading shared libraries: libcrypto.so.1.1: cannot 
open shared object file: No such file or directory


It seems that something still pulls in openssl1.1 on other architectures, e.g. 
in this build:


https://koschei.fedoraproject.org/build/11634367

Both aarch64 and ppc64le have openssl1.1 in the root.log


It seems that libarchive still requires libcrypto.so.1.1()(64bit)

But on x86_64, opae-devel provides that with:

ExclusiveArch:  x86_64

I'll report that.

--
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: cmake on Rawhide is broken

[Miro Hrončok]

On 03. 12. 21 15:45, Kamil Dudka wrote:

On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote:

Hello all.

Cmake on Rawhide x86_64 tries to load legacy OpenSSL 1.1 with
libcrypto.so.1.1 and fails:

+ /usr/bin/cmake -S . -B redhat-linux-build
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF
-DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include
-DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc
-DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64
-DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DCMAKE_BUILD_TYPE=Release
RPM build errors:
/usr/bin/cmake: error while loading shared libraries: libcrypto.so.1.1:
cannot open shared object file: No such file or directory
error: Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build)
  Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build)
Child return code was: 1

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


Same issue with my build of cswrap.  It is weird that it happens on x86_64 only:

 https://koji.fedoraproject.org/koji/taskinfo?taskID=79545725


This has surfaced by the last package in the default buildroot dropping the 
dependency on openssl1.1:


https://bugzilla.redhat.com/show_bug.cgi?id=2022026#c7


I see more apps affected:

 sh-5.1$ cmake --help
cmake: error while loading shared libraries: libcrypto.so.1.1: cannot open 
shared object file: No such file or directory


 sh-5.1$ appstream-util --help
appstream-util: error while loading shared libraries: libcrypto.so.1.1: cannot 
open shared object file: No such file or directory


It seems that something still pulls in openssl1.1 on other architectures, e.g. 
in this build:


https://koschei.fedoraproject.org/build/11634367

Both aarch64 and ppc64le have openssl1.1 in the root.log

--
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: cmake on Rawhide is broken

[Kamil Dudka]

On Friday, December 3, 2021 2:58:24 PM CET Vitaly Zaitsev via devel wrote:
> Hello all.
> 
> Cmake on Rawhide x86_64 tries to load legacy OpenSSL 1.1 with 
> libcrypto.so.1.1 and fails:
> 
> + /usr/bin/cmake -S . -B redhat-linux-build 
> -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG 
> -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG 
> -DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG 
> -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF 
> -DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include 
> -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc 
> -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 
> -DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DCMAKE_BUILD_TYPE=Release
> RPM build errors:
> /usr/bin/cmake: error while loading shared libraries: libcrypto.so.1.1: 
> cannot open shared object file: No such file or directory
> error: Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build)
>  Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build)
> Child return code was: 1
> 
> Affected Koji build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=79545927

Same issue with my build of cswrap.  It is weird that it happens on x86_64 only:

https://koji.fedoraproject.org/koji/taskinfo?taskID=79545725

Kamil

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-20211203.n.0 compose check report

[Fedora compose checker]

No missing expected images.

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

Failed openQA tests: 5/208 (x86_64), 8/142 (aarch64)

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

ID: 1076447 Test: x86_64 Workstation-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1076447
ID: 1076457 Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/1076457
ID: 1076483 Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/1076483
ID: 1076602 Test: x86_64 universal install_blivet_with_swap
URL: https://openqa.fedoraproject.org/tests/1076602
ID: 1076671 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1076671
ID: 1076699 Test: aarch64 universal install_european_language@uefi
URL: https://openqa.fedoraproject.org/tests/1076699
ID: 1076700 Test: aarch64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/1076700
ID: 1076706 Test: aarch64 universal install_repository_http_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1076706
ID: 1076711 Test: aarch64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/1076711

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

ID: 1076463 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1076463
ID: 1076547 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1076547
ID: 1076576 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi
URL: https://openqa.fedoraproject.org/tests/1076576
ID: 1076581 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1076581

Soft failed openQA tests: 5/142 (aarch64), 7/208 (x86_64)
(Tests completed, but using a workaround for a known bug)

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

ID: 1076567 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1076567
ID: 1076575 Test: aarch64 Workstation-raw_xz-raw.xz evince@uefi
URL: https://openqa.fedoraproject.org/tests/1076575
ID: 1076582 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_update_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1076582

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

ID: 1076437 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1076437
ID: 1076452 Test: x86_64 Workstation-live-iso gedit
URL: https://openqa.fedoraproject.org/tests/1076452
ID: 1076486 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1076486
ID: 1076487 Test: x86_64 Silverblue-dvd_ostree-iso gedit
URL: https://openqa.fedoraproject.org/tests/1076487
ID: 1076488 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1076488
ID: 1076498 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1076498
ID: 1076590 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1076590
ID: 1076637 Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1076637
ID: 1076686 Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1076686

Passed openQA tests: 128/142 (aarch64), 196/208 (x86_64)

New passes (same test not passed in Fedora-Rawhide-20211201.n.0):

ID: 1076565 Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1076565
ID: 1076703 Test: aarch64 universal install_package_set_minimal@uefi
URL: https://openqa.fedoraproject.org/tests/1076703
ID: 1076710 Test: aarch64 universal upgrade_2_server_64bit@uefi
URL: https://openqa.fedoraproject.org/tests/1076710

Skipped non-gating openQA tests: 1 of 350

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
System load changed from 0.03 to 0.21
Previous test data: https://openqa.fedoraproject.org/tests/1074840#downloads
Current test data: https://openqa.fedoraproject.org/tests/1076369#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
2 packages(s) removed since previous compose: ipw2100-firmware, 
ipw2200-firmware
System load changed from 0.03 to 0.18
Previous test data: https://openqa.fedoraproject.org/tests/1074855#downloads
Current test data: https://openqa.fedoraproject.org/tests/1076384#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
Used mem changed from 208 MiB to 240 MiB
2 

Re: cmake on Rawhide is broken

[Vitaly Zaitsev via devel]

On 03/12/2021 15:05, Omair Majid wrote:

As a workaround, can you try a BuildRequires of `openssl1.1`? That
should get the libraries and let cmake proceed.


This is a dirty hack. You package can be linked with legacy openssl1.1 
and introduce another compatibility issues.


--
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: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Tom Seewald]

Perhaps I glossed over it in the description, but what is the expected user 
experience in the event of a RPM fs-verity mismatch/error?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: cmake on Rawhide is broken

[Omair Majid]

Hi,

Vitaly Zaitsev via devel  writes:

> /usr/bin/cmake: error while loading shared libraries:
> libcrypto.so.1.1: cannot open shared object file: No such file or
> directory

As a workaround, can you try a BuildRequires of `openssl1.1`? That
should get the libraries and let cmake proceed.

My scratch build with the added BuildRequires:

https://koji.fedoraproject.org/koji/taskinfo?taskID=79546890

Thanks,
Omair

--
PGP Key: B157A9F0 (http://pgp.mit.edu/)
Fingerprint = 9DB5 2F0B FD3E C239 E108  E7BD DF99 7AF8 B157 A9F0
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

cmake on Rawhide is broken

[Vitaly Zaitsev via devel]

Hello all.

Cmake on Rawhide x86_64 tries to load legacy OpenSSL 1.1 with 
libcrypto.so.1.1 and fails:


+ /usr/bin/cmake -S . -B redhat-linux-build 
-DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_Fortran_FLAGS_RELEASE:STRING=-DNDEBUG 
-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF 
-DCMAKE_INSTALL_PREFIX:PATH=/usr -DINCLUDE_INSTALL_DIR:PATH=/usr/include 
-DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc 
-DSHARE_INSTALL_PREFIX:PATH=/usr/share -DLIB_SUFFIX=64 
-DBUILD_SHARED_LIBS:BOOL=ON -G Ninja -DCMAKE_BUILD_TYPE=Release

RPM build errors:
/usr/bin/cmake: error while loading shared libraries: libcrypto.so.1.1: 
cannot open shared object file: No such file or directory

error: Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build)
Bad exit status from /var/tmp/rpm-tmp.y6BkQ1 (%build)
Child return code was: 1

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

--
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: [Fedocal] Reminder meeting : ELN SIG

[Stephen Gallagher]

On Thu, Dec 2, 2021 at 11:05 AM Stephen Gallagher  wrote:
>
> On Thu, Dec 2, 2021 at 7:00 AM  wrote:
> >
> > Dear all,
> >
> > You are kindly invited to the meeting:
> >ELN SIG on 2021-12-03 from 12:00:00 to 13:00:00 US/Eastern
> >At fedora-meet...@irc.libera.chat
> >
> > The meeting will be about:
>
> I don't currently have any items for the agenda this time, so I'll
> cancel the meeting unless someone replies to this email with a topic
> before I get in to work tomorrow morning.


The ELN SIG meeting today is cancelled. I will not be available to run
one on Dec. 17th... do we want to have one next week instead?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: phoronix-test-suite pull request is there for 6 months

[Neal Gompa]

On Fri, Dec 3, 2021 at 8:21 AM Richard Shaw  wrote:
>
> On Fri, Dec 3, 2021 at 7:15 AM Richard Shaw  wrote:
>>
>> On Thu, Dec 2, 2021 at 11:27 PM Reon Beon via devel 
>>  wrote:
>>>
>>> https://src.fedoraproject.org/rpms/phoronix-test-suite/pull-request/3
>>
>>
>> This is unfortunate and as much as I hate doing it sometimes you have to 
>> "ping" people. They might have seen it initially but got busy with something 
>> else and forgot.
>>
>> I would:
>> 1. Update the PR so it can be merged again
>> 2. Comment on the PR or maybe better send a ping email to 
>> "phoronix-test-suite-maintain...@fedoraproject.org" which will send an email 
>> to all maintainers (if there's more than one).
>>
>> There's a non-response procedure for maintainers but hopefully it will not 
>> be necessary.
>
>
> Replying to myself here after digging a bit, the only maintainer is on over 
> 2400 packages, and their activity has been pretty light:
>
> https://src.fedoraproject.org/user/salimma
>
> I scrolled through the commits briefly and didn't see one commit they made. I 
> could have missed it, but that's hardly the point, other people have 
> obviously been maintaining the package.
>
> The package probably needs a new maintainer or at least a co-maintainer.
>

I don't think Michel was the maintainer of the package when he made
the PR, he most likely got it recently and forgot about the PR to
merge it. I've pinged him about it so he can take care of it.



-- 
真実はいつも一つ！/ 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: phoronix-test-suite pull request is there for 6 months

[Richard Shaw]

On Fri, Dec 3, 2021 at 7:15 AM Richard Shaw  wrote:

> On Thu, Dec 2, 2021 at 11:27 PM Reon Beon via devel <
> devel@lists.fedoraproject.org> wrote:
>
>> https://src.fedoraproject.org/rpms/phoronix-test-suite/pull-request/3
>
>
> This is unfortunate and as much as I hate doing it sometimes you have to
> "ping" people. They might have seen it initially but got busy with
> something else and forgot.
>
> I would:
> 1. Update the PR so it can be merged again
> 2. Comment on the PR or maybe better send a ping email to "
> phoronix-test-suite-maintain...@fedoraproject.org" which will send an
> email to all maintainers (if there's more than one).
>
> There's a non-response procedure for maintainers but hopefully it will not
> be necessary.
>

Replying to myself here after digging a bit, the only maintainer is on over
2400 packages, and their activity has been pretty light:

https://src.fedoraproject.org/user/salimma

I scrolled through the commits briefly and didn't see one commit they made.
I could have missed it, but that's hardly the point, other people have
obviously been maintaining the package.

The package probably needs a new maintainer or at least a co-maintainer.

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

Re: phoronix-test-suite pull request is there for 6 months

[Richard Shaw]

On Thu, Dec 2, 2021 at 11:27 PM Reon Beon via devel <
devel@lists.fedoraproject.org> wrote:

> https://src.fedoraproject.org/rpms/phoronix-test-suite/pull-request/3


This is unfortunate and as much as I hate doing it sometimes you have to
"ping" people. They might have seen it initially but got busy with
something else and forgot.

I would:
1. Update the PR so it can be merged again
2. Comment on the PR or maybe better send a ping email to "
phoronix-test-suite-maintain...@fedoraproject.org" which will send an email
to all maintainers (if there's more than one).

There's a non-response procedure for maintainers but hopefully it will not
be necessary.

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

Re: /usr/bin/ld.so as a symbolic link for the dynamic loader

[Florian Weimer]

* Lennart Poettering:

> On Do, 02.12.21 19:38, Florian Weimer (fwei...@redhat.com) wrote:
>
>> It would go into glibc-common on x86-64, and the initial version won't
>> be able to launch 32-bit programs (“wrong ELF class: ELFCLASS32”).
>
> "the initial version"? That phrasing makes me wonder, what longer term
> plans do you have in mind for this? i.e. do you intend to support
> other archs, and if so, how? Chain-load the right ld.so in case the
> binary is not native?

Probably execve the other loader using the PT_INTERP path if it exists.
We need to avoid an infinite loop; probably we need to splice in a
command line option.  And we don't want to do this if the first
invocation wasn't an explicit loader invocation.  So there are a few
details to work out for the cross-architecture case.

(The execve is needed to trigger binfmt_misc handlers registered with
the kernel.)

> Another question: in systemd we have code to be able to boot from just
> a /usr/ partition, with the root file system being an empty tmpfs
> initially. For that to work we have to set up a basic file system
> tree, since /usr/ alone is not sufficient — most importantly we have
> to set up the right symlinks for /lib/ + /lib64/, since the ELF
> interpreter is after all hardcoded in the ELF headers of the various
> dynamic binaries in accordance with the ABI of the architecture, and
> the ELF interpreter for most archs is placed in /lib/ or
> /lib64/. Right now we include a table with the right symlinks we have
> to create for each architecture we want to support. If your new
> symlink in /usr/bin/ to the right ld.so becomes API though we could
> drop this table in the long run, and instead just readlink() your
> symlink and thus know which of /lib/ and /lib64/ we actually have to
> symlink. Hence my question: do you intend to make this API? i.e. that
> this is a symlink? Because only if it's officially API that this is a
> symlink (and not a regular file/hardlink) and that it always points to
> the interpreter for the primary architecture of the system, in
> accordance with the ELF ABI docs we can rely on it.

The symbolic link will be relative, so it won't give you the exact path
you need to use.  I don't know if the glibc installation path (which
/usr/bin/ld.so will point to) is the official ABI path for all
architectures.  It should be, but Fedora had some additional symbolic
links there historically.

We can likely add the official path to the dynamic linker as a macro in
.  This will not work for cross-initrd setups, but it
will be easier to process than /usr/bin/ld.so than the native case.
(The path in  will reflect glibc assumptions, so it
doesn't help with partial downstream customizations.)  For cross-initrd,
I think you need to parse the ELF and grab the interpreter path from
there.

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: /usr/bin/ld.so as a symbolic link for the dynamic loader

[Florian Weimer]

* Kamil Dudka:

> On Friday, December 3, 2021 7:25:19 AM CET Kamil Dudka wrote:
>> On Friday, December 3, 2021 12:33:58 AM CET Sérgio Basto wrote:
>> > On Thu, 2021-12-02 at 15:19 -0800, Samuel Sieb wrote:
>> > > On 12/2/21 15:08, Sérgio Basto wrote:
>> > > > I didn't understood . What is the difference for /lib64/ld-2.33.so
>> > > > or
>> > > > /lib/ld-2.33.so ?
>> > 
>> > rephrasing my question :
>> >  What is the difference of /usr/bin/ld.so  for /lib64/ld-2.33.so or
>> > 
>> > /lib/ld-2.33.so ?
>> 
>> /usr/bin/ld.so will have the same absolute path, regardless of glibc version.
>
> And /usr/bin also appears in default ${PATH} unlike /lib or /lib64.

Correct on both counts.

And Fedora 35 does not have /lib64/ld-2.34.so because it turned out it
caused a downgrade hazard due to the way RPM handles file removals.

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

Fedora rawhide compose report: 20211203.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20211201.n.0
NEW: Fedora-Rawhide-20211203.n.0

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

Size of added packages:  389.89 KiB
Size of dropped packages:344.83 KiB
Size of upgraded packages:   3.33 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20211203.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: rust-faccess-0.2.3-2.fc36
Summary: Simple file accessibility checks
RPMs:rust-faccess+default-devel rust-faccess-devel
Size:24.78 KiB

Package: rust-fasteval-0.2.4-3.fc36
Summary: Fast evaluation of algebraic expressions
RPMs:rust-fasteval+alpha-keywords-devel rust-fasteval+default-devel 
rust-fasteval+nightly-devel rust-fasteval+unsafe-vars-devel rust-fasteval-devel
Size:284.19 KiB

Package: rust-iptables-0.4.3-2.fc36
Summary: Rust bindings for iptables
RPMs:rust-iptables+default-devel rust-iptables-devel
Size:23.18 KiB

Package: rust-simple-error-0.2.3-2.fc36
Summary: Simple error type backed by a string
RPMs:rust-simple-error+default-devel rust-simple-error-devel
Size:30.16 KiB

Package: rust-zmq-sys-0.11.0-1.fc36
Summary: Low-level bindings to the zeromq library
RPMs:rust-zmq-sys+default-devel rust-zmq-sys-devel
Size:27.58 KiB


= DROPPED PACKAGES =
Package: ipw2100-firmware-1.3-29.fc35
Summary: Firmware for Intel?? PRO/Wireless 2100 network adaptors
RPMs:ipw2100-firmware
Size:148.21 KiB

Package: ipw2200-firmware-3.1-22.fc35
Summary: Firmware for Intel?? PRO/Wireless 2200 network adaptors
RPMs:ipw2200-firmware
Size:139.50 KiB

Package: rust-actix-macros0.1-0.1.3-2.fc35
Summary: Actix runtime macros
RPMs:rust-actix-macros0.1+actix-reexport-devel 
rust-actix-macros0.1+default-devel rust-actix-macros0.1-devel
Size:26.65 KiB

Package: rust-actix-rt1-1.1.1-2.fc35
Summary: Actix runtime
RPMs:rust-actix-rt1+default-devel rust-actix-rt1-devel
Size:30.47 KiB


= UPGRADED PACKAGES =
Package:  NetworkManager-1:1.36.0-0.2.fc36
Old package:  NetworkManager-1:1.36.0-0.1.fc36
Summary:  Network connection manager and user applications
RPMs: NetworkManager NetworkManager-adsl NetworkManager-bluetooth 
NetworkManager-cloud-setup NetworkManager-config-connectivity-fedora 
NetworkManager-config-server NetworkManager-dispatcher-routing-rules 
NetworkManager-libnm NetworkManager-libnm-devel NetworkManager-ovs 
NetworkManager-ppp NetworkManager-team NetworkManager-tui NetworkManager-wifi 
NetworkManager-wwan
Size: 28.42 MiB
Size change:  86.66 KiB
Changelog:
  * Thu Dec 02 2021 Wen Liang  - 1:1.36.0-0.2
  - update to an early 1.36 snapshot (1.35.2)


Package:  OpenImageIO-2.3.10.0-1.fc36
Old package:  OpenImageIO-2.3.9.1-3.fc36
Summary:  Library for reading and writing images
RPMs: OpenImageIO OpenImageIO-devel OpenImageIO-iv OpenImageIO-utils 
python3-openimageio
Size: 25.40 MiB
Size change:  4.47 MiB
Changelog:
  * Wed Dec 01 2021 Richard Shaw  - 2.3.10.0-1
  - Update to 2.3.10.0.


Package:  PyMca-5.6.7-2.fc36
Old package:  PyMca-5.6.5-1.fc36
Summary:  X-ray Fluorescence Toolkit
RPMs: PyMca PyMca-data
Size: 19.76 MiB
Size change:  2.79 KiB
Changelog:
  * Wed Dec 01 2021 Zbigniew J??drzejewski-Szmek  5.6.7-1
  - Version 5.6.7 (#2027722)

  * Wed Dec 01 2021 Zbigniew J??drzejewski-Szmek  5.6.7-2
  - Adjust dependencies and environment so that tests pass


Package:  SDL2-2.0.18-2.fc36
Old package:  SDL2-2.0.16-4.fc36
Summary:  Cross-platform multimedia library
RPMs: SDL2 SDL2-devel SDL2-static
Size: 9.98 MiB
Size change:  992.27 KiB
Changelog:
  * Wed Dec 01 2021 Neal Gompa  - 2.0.18-1
  - Update to 2.0.18

  * Wed Dec 01 2021 Neal Gompa  - 2.0.18-2
  - Use correct build options


Package:  anaconda-36.11-1.fc36
Old package:  anaconda-36.10-1.fc36
Summary:  Graphical system installer
RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui 
anaconda-install-env-deps anaconda-install-img-deps anaconda-live anaconda-tui 
anaconda-widgets anaconda-widgets-devel
Size: 20.34 MiB
Size change:  53.66 KiB
Changelog:
  * Thu Dec 02 2021 Packit Service  - 
36.11-1
  - New version - 36.11 (Martin Kolman)
  - Handle potential failure of `cd` (Vladimir Slavik)
  - Printf variables correctly (Vladimir Slavik)
  - Simplify debug printing (Vladimir Slavik)
  - Ignore use of local variables (Vladimir Slavik)
  - Fix wrong comparison operator (Vladimir Slavik)
  - Remove unused variables (Vladimir Slavik)
  - Ignore variables used across our dracut hooks (Vladimir Slavik)
  - Fix arithmetic operation on a variable (Vladimir Slavik)
  - Fix `read` calls in dracut

Re: Anaconda new community mailing list available

[Jiri Konecny]

Dne 02. 12. 21 v 17:04 Ben Cotton napsal(a):

On Thu, Dec 2, 2021 at 11:02 AM Jiri Konecny  wrote:

we (Anaconda team) have decided to migrate our old
anaconda-devel-l...@redhat.com mailing list under Fedora. This decision
was made to be closer to community and more discoverable in the Fedora
world.

This is great, thank you!


If you are interested about what is happening with your loved installer,
please subscribe here to the new mailing list:

https://lists.fedoraproject.org/admin/lists/anaconda-devel.lists.fedoraproject.org/

Will existing subscribers be migrated or will people need to
re-subscribe if they want to continue participating on the list?

Hi, unfortunately, I wasn't able to find a way to do the automatic 
re-subscribe. I did send mail to the old list that people need to 
re-subscribe, can't do much more.


Best Regards,
Jirka
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

[EPEL-devel] Re: EPEL9 Rollout Proposals

[Leon Fauster via epel-devel]

Am 03.12.21 um 02:12 schrieb Josh Boyer:

On Thu, Dec 2, 2021 at 4:29 PM Leon Fauster via epel-devel
 wrote:


Am 02.12.21 um 19:49 schrieb Carl George:

On Thu, Nov 18, 2021 at 1:32 PM Troy Dawson  wrote:


In our last EPEL Steering Committee meeting, Carl brought up a new proposal for 
our epel9 / epel9-next rollout.  Sometimes IRC isn't the best way to explain 
things like that, it got a little confusing.  Carl and I had a good video chat 
to clean up confusion and talk about some pros and cons of the various 
proposals.
Here are the three proposals.

* PLAN A
Plan A is basically what we've been working towards for the past couple of 
months.
- launch epel9-next now-ish (ideally aligned with c9s launch promotion)
- After RHEL9 goes GA
-- perform a mass branch and mass rebuild to populate epel9
-- launch epel9 after RHEL9 GA is launched.

** Plan A Pros:
- epel9-next and epel9 are only set up once, and not changed
- ready to go now

** Plan A Cons:
- complexity and added work of mass branch and mass rebuild
- mass rebuild will have a moderate rate of failure due to buildroot 
differences (unshipped devel packages)
- epel9 not available at rhel9 ga
- confusing messaging to packagers:
-- target epel9-next for ~6 months
-- after epel9 exists target that instead, only use epel9-next when needed
- confusing messaging to users:
-- use epel9-next now for c9s and rhel9 beta
-- use epel9-next temporarily at rhel9 launch but don’t leave it enabled
-- use epel9 primarily once it exists


* PLAN B
- epel9-next stays the way it is currently setup.
- Setup epel9 using RHEL9 Beta for the buildroot.
-- Pull in any errata as it comes.
-- Use the repos you would for RHEL9 GA: AppStream, BaseOS, CRB
- Launch epel9 and epel9-next together (In 1-2 weeks).
- When RHEL9 GA is released, switch epel9 buildroot from RHEL9 Beta to RHEL9 GA

** Plan B Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as 
epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB

** Plan B Cons:
- potential for large divergence between rhel9 beta and ga
- changing our messaging right before the launch


* PLAN C
- epel9-next stays the way it is currently setup.
- setup up epel9 using c9s for the buildroot
-- Use the repos you would for RHEL9: AppStream, BaseOS, CRB
- freeze epel9 buildroot before c9s switches to 9.1 content
- launch epel9 and epel9-next together (1-2 weeks)
- switch epel9 buildroot from frozen c9s to rhel9 ga later

** Plan C Pros:
- simple messaging to packagers:
-- epel9 is the primary target, use epel9-next only when needed (same as 
epel8-next)
- simple messaging to users:
-- use epel9 everywhere (epel-next-release is a recommends on c9s)
- no mass branching
- no mass rebuild
- No confusion from using the full CentOS Stream buildroot
-- epel9 buildroot will only have AppStream, BaseOS and CRB

** Plan C Cons:
- potential infrastructure complexity of freezing the epel9 buildroot
- changing our messaging right before the launch


Please let us know what you think.
If we do choose to go with Plan B or C we will need to make the decision fairly 
quickly.

Troy


Closing the loop here, at the 2021-11-24 EPEL Steering Committee
meeting we voted and selected plan C.

https://meetbot.fedoraproject.org/teams/epel/epel.2021-11-24-21.00.html

We are in the process of finishing up the EPEL9 implementation and
plan to launch EPEL9 and EPEL9 Next together with a formal
announcement very soon.  Until then you may notice parts of that
implementation coming online (repositories, release packages, etc.)
but we recommend waiting until the announcement for official
instructions.




That sounds nice! Just curious - what indicates the switch to 9.1
content? Any sample point(s) that indicates such "branch"?


There are none.  C9S is a continuously delivered distribution which
RHEL is derived from.  Equivalency to distinct RHEL minor releases at
point-in-time intervals isn't something that Stream does.

In talking with Carl directly, he was using this as shorthand for
instituting a freeze of the EPEL buildroot in preparation of
solidifying it for a RHEL GA.  RHEL's release cadence is publicly
documented, so my understanding is that the EPEL team will do some of
their own projections from the spring/fall RHEL release cadence
(typically May and Nov) and work backwards to what they feel is a safe
point in time to solidify.




Thank you Josh for taking the time explaining the approach.

--
Leon

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

[Test-Announce] Fedora 36 Rawhide 20211203.n.0 nightly compose nominated for testing

[rawhide]

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

Notable package version changes:
anaconda - 20211130.n.0: anaconda-36.10-1.fc36.src, 20211203.n.0: 
anaconda-36.11-1.fc36.src

Test coverage information for the current release can be seen at:
https://openqa.fedoraproject.org/testcase_stats/36

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

https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211203.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211203.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211203.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211203.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211203.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211203.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_36_Rawhide_20211203.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/test-annou...@lists.fedoraproject.org
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: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Vitaly Zaitsev via devel]

On 02/12/2021 20:36, Ben Cotton wrote:

Enable the use of fsverity for installed RPM files validation.


-1. RPM already supports files validation and this feature will waste 
file system space.


--
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: rust: Request for packaging rust-html-escape and rust-smallbitvec

[Andreas Schneider]

On Thursday, December 2, 2021 9:07:06 PM CET Aleksei Bavshin wrote:
> `smallbitvec` deps are only needed for benchmark, so the test suite is 
> actually passing without these. Should be safe to drop with metadata patch.
> 
> rust-tiny_http 0.8.2 also has a benchmark-only dependency `fdlimit` 
> which we can drop.
> 
> The situation with tree-sitter-cli testsuite is complicated: it requires 
> a few other github repos with a grammar definitions and who knows what 
> else. I haven't succeeded in running it so far, so we can keep it turned 
> off. And that would make `rust-spin` update unnecessary.
> 
> The draft packages are available from 
> https://copr.fedorainfracloud.org/coprs/alebastr/rust-tree-sitter-cli/; 
> seems working with available grammar files (with exception of 
> `build-wasm` and `playground` subcommands which require emscripten).

This is great work, thank you very much. I didn't know that the tree-sitter-
cli needs it own package and can't be built in the current tree-sitter 
package. So I will just continue to take care of tree-sitter and just build 
the lib.

So having tree-sitter-cli in the next fedora version would be awesome.


Best regards


Andreas

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

[Bug 2028698] perl-MCE-1.876 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
 Resolution|--- |RAWHIDE
 Status|NEW |CLOSED
   Fixed In Version||perl-MCE-1.876-1.fc36
Last Closed||2021-12-03 10:37:41



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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2028698
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

pghmcfc pushed to perl-MCE-Shared (rawhide). "Update to 1.874 (..more)"

[notifications]

Notification time stamped 2021-12-03 10:35:13 UTC

From 190b9d45757e4a797017f320340cda839b08bf9e Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Dec 03 2021 10:33:50 +
Subject: Update to 1.874


- New upstream release 1.874
  - Bumped MCE dependency to 1.874
  - MCE::Hobo update
- Improved _ordhash
- Renamed JOINED to REAPED in code for better clarity
- Specify a percentage for max_workers
- Added t/05_mce_hobo_max_workers.t

---

diff --git a/perl-MCE-Shared.rpmlintrc b/perl-MCE-Shared.rpmlintrc
deleted file mode 100644
index 52ea5aa..000
--- a/perl-MCE-Shared.rpmlintrc
+++ /dev/null
@@ -1,2 +0,0 @@
-from Config import *
-addFilter("spelling-error %description -l en_US parallelization -> ");
diff --git a/perl-MCE-Shared.spec b/perl-MCE-Shared.spec
index 069bd9b..d5bbcf0 100644
--- a/perl-MCE-Shared.spec
+++ b/perl-MCE-Shared.spec
@@ -1,6 +1,6 @@
 Name:  perl-MCE-Shared
-Version:   1.873
-Release:   4%{?dist}
+Version:   1.874
+Release:   1%{?dist}
 Summary:   MCE extension for sharing data, supporting threads and processes
 License:   GPL+ or Artistic
 URL:   https://metacpan.org/release/MCE-Shared
@@ -21,7 +21,7 @@ BuildRequires:perl(constant)
 BuildRequires: perl(Errno)
 BuildRequires: perl(if)
 BuildRequires: perl(IO::Handle)
-BuildRequires: perl(MCE) >= 1.873
+BuildRequires: perl(MCE) >= 1.876
 BuildRequires: perl(MCE::Mutex)
 BuildRequires: perl(MCE::Signal)
 BuildRequires: perl(MCE::Util)
@@ -45,7 +45,7 @@ BuildRequires:perl(utf8)
 # Runtime
 Requires:  perl(:MODULE_COMPAT_%(eval "$(perl -V:version)"; echo $version))
 Requires:  perl(IO::FDPass) >= 1.2
-Requires:  perl(MCE) >= 1.873
+Requires:  perl(MCE) >= 1.876
 Requires:  perl(overloading)
 Requires:  perl(POSIX)
 Requires:  perl(Storable) >= 2.04
@@ -93,6 +93,15 @@ make test
 %{_mandir}/man3/MCE::Shared::Server.3*
 
 %changelog
+* Fri Dec  3 2021 Paul Howarth  - 1.874-1
+- Update to 1.874
+  - Bumped MCE dependency to 1.874
+  - MCE::Hobo update
+- Improved _ordhash
+- Renamed JOINED to REAPED in code for better clarity
+- Specify a percentage for max_workers
+- Added t/05_mce_hobo_max_workers.t
+
 * Thu Jul 22 2021 Fedora Release Engineering  - 
1.873-4
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
 
diff --git a/sources b/sources
index bd901f6..27f4187 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (MCE-Shared-1.873.tar.gz) = 
7bbc10fdff62f42324e2fefb697147247ba58dd17bdb174d58da7153ec2e0264fa5c56d3c3da3f6e9d5dfa399573f49fdfca9eab4e3d98b011a9988bbb441bca
+SHA512 (MCE-Shared-1.874.tar.gz) = 
371b156ec721e305dbd10e7951bc227e77659d77aaf228373b8081d804c18663faf6198dd38bcdc9ca119709e599037a37c881fff2f420fbdc160e0f11ad776f



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

Re: Self Introduction: Diego Herrera

[Dominik 'Rathann' Mierzejewski]

On Thursday, 02 December 2021 at 21:18, Sebastian Crane wrote:
> Dear Diego,
> 
> Welcome! I'm also new to the Fedora community, so maybe we can share
> notes at some point :)

Welcome, both of you.

> As you're interested in packaging open source games for Fedora, I'll
> invite you to an IRC channel all about open source games! It's
> #libregamenight on Libera.Chat; there are plenty of people there who
> I'm sure would love to hear about your work.

There's also #fedora-games, the official Fedora Games SIG channel, but
it's not very alive.

I do some light gaming on Fedora from time to time and I maintain one of
the game engines (ags). I've also (re)packaged some of the proprietary
games from GOG and published the spec files on GitLab:
https://gitlab.com/greysector/rpms

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-Cloud-34-20211203.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-34-20211202.0):

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

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: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

> The signature size is roughly proportional to the number of files in
> the package.
Can you explain how the signature is performed? I assume that the verity
top-level hash is calculated for each file and then … ?
And if you have all the per-file hashes, why not do one more level of
Merkle and calculate a single hash for all the files in the rpm and sign
that (so that the signature overhead is of fixed size)? 

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

Fedora-Cloud-35-20211203.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-35-20211202.0):

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

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: /usr/bin/ld.so as a symbolic link for the dynamic loader

[Lennart Poettering]

On Do, 02.12.21 19:38, Florian Weimer (fwei...@redhat.com) wrote:

> It would go into glibc-common on x86-64, and the initial version won't
> be able to launch 32-bit programs (“wrong ELF class: ELFCLASS32”).

"the initial version"? That phrasing makes me wonder, what longer term
plans do you have in mind for this? i.e. do you intend to support
other archs, and if so, how? Chain-load the right ld.so in case the
binary is not native?

Another question: in systemd we have code to be able to boot from just
a /usr/ partition, with the root file system being an empty tmpfs
initially. For that to work we have to set up a basic file system
tree, since /usr/ alone is not sufficient — most importantly we have
to set up the right symlinks for /lib/ + /lib64/, since the ELF
interpreter is after all hardcoded in the ELF headers of the various
dynamic binaries in accordance with the ABI of the architecture, and
the ELF interpreter for most archs is placed in /lib/ or
/lib64/. Right now we include a table with the right symlinks we have
to create for each architecture we want to support. If your new
symlink in /usr/bin/ to the right ld.so becomes API though we could
drop this table in the long run, and instead just readlink() your
symlink and thus know which of /lib/ and /lib64/ we actually have to
symlink. Hence my question: do you intend to make this API? i.e. that
this is a symlink? Because only if it's officially API that this is a
symlink (and not a regular file/hardlink) and that it always points to
the interpreter for the primary architecture of the system, in
accordance with the ELF ABI docs we can rely on it.

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: /usr/bin/ld.so as a symbolic link for the dynamic loader

[Kamil Dudka]

On Friday, December 3, 2021 7:25:19 AM CET Kamil Dudka wrote:
> On Friday, December 3, 2021 12:33:58 AM CET Sérgio Basto wrote:
> > On Thu, 2021-12-02 at 15:19 -0800, Samuel Sieb wrote:
> > > On 12/2/21 15:08, Sérgio Basto wrote:
> > > > I didn't understood . What is the difference for /lib64/ld-2.33.so
> > > > or
> > > > /lib/ld-2.33.so ?
> > 
> > rephrasing my question :
> >  What is the difference of /usr/bin/ld.so  for /lib64/ld-2.33.so or
> > 
> > /lib/ld-2.33.so ?
> 
> /usr/bin/ld.so will have the same absolute path, regardless of glibc version.

And /usr/bin also appears in default ${PATH} unlike /lib or /lib64.

> Kamil
> 
> > > The lib64 one is 64-bit and the lib one is 32-bit.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Shouldn't Fedora 36/rawhide kernel be 5.17 not 5.16 rc3 git?

[Leigh Scott]

5.16 is the correct version, see

https://www.kernel.org/category/releases.html

5.16 will probably be released  late January next year.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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