Mock v5.5 released (and mock-core-configs v40.1)

[Pavel Raiskup]

Hello maintainers!

Let me announce a new release of Mock v5.5, the chroot build environment
manager for building RPMs.

First and foremost, this update ships with updated
mock-core-configs v40.1, bringing Fedora 40 configs as "branched"
separately from Fedora Rawhide (Fedora 41 now equals to Fedora Rawhide).

The Mock 5.5 release then mostly brings a few important bug-fixes (fix
for bash-completion multi-argument options, fixing in-chroot file and
process group ownership, root_cache invalidation by configuration
changes), but there are also a few new (rather small) features.

Since we needed to fix fedora-rawhide builds, this update also landed
Fedora Copr production yesterday.

In case of any trouble, please report issues upstream:
https://github.com/rpm-software-management/mock/issues

Full release notes:
https://rpm-software-management.github.io/mock/Release-Notes-5.5

The updated packages are in Bodhi:

[Fedora 39]: https://bodhi.fedoraproject.org/updates/FEDORA-2024-1171d69465
[Fedora 38]: https://bodhi.fedoraproject.org/updates/FEDORA-2024-15b5461dd0
[EPEL 9]: 
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-fd971ca651
[EPEL 8]: 
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-e9e1b2dad6

Happy building!
Pavel


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

Re: Why branched config pointed to rolling config?

[Miroslav Suchý]

Dne 15. 02. 24 v 6:38 Mikhail Gavrilov napsal(a):

I think that getting the f41 package with fedora-40 config looks at
least odd. And one of the solutions is making rolling config pointed
to branch config rather than the other way around.


Than you will get f40 packages with rawhide config. There is no clean winner in 
this race.

--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Why branched config pointed to rolling config?

[Mikhail Gavrilov]

I think that getting the f41 package with fedora-40 config looks at
least odd. And one of the solutions is making rolling config pointed
to branch config rather than the other way around.

-- 
Best Regards,
Mike Gavrilov.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

List of long term FTBFS packages to be retired in 2 weeks

[Miro Hrončok]

NOTE: This was not sent to individual maintainers, as @fedoraproject.org
aliases are currently broken
https://pagure.io/fedora-infrastructure/issue/11768

---

Dear maintainers.

Based on the current fail to build from source policy, the following packages
should be retired from Fedora 40 approximately one week before branching.

5 weekly reminders are required, hence the retirement will happen
approximately in 2 weeks, i.e. around 2024-02-28.
Since this is unfortunately after the branching,
packages will be retired on rawhide and f40.

I apologize for starting this process a bit later than required again.
Unfortunately, I had other work obligations.
Volunteers to take over this are always welcome.

Policy: 
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/


The packages in rawhide were not successfully built at least since Fedora 37.

This report is based on dist tags.

Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ftbfs-retirements.ipynb

If you see a package that was built, please let me know.
If you see a package that should be exempted from the process,
please let me know and we can work together to get a FESCo approval for that.

If you see a package that can be rebuilt, please do so.

Package  (co)maintainers

erlang-jose@erlang-maint-sig, bowlofeggs, jcline, peter
golang-github-acme-lego@go-sig, eclipseo
golang-github-genuinetools-pkg @go-sig, eclipseo
golang-github-gobs-pretty  @go-sig, eclipseo
golang-github-pierrre-compare  @go-sig, eclipseo
golang-github-smartystreets-goconvey  @go-sig, alexsaezm, jchaloup
golang-gvisor @go-sig, eclipseo, elmarco
golang-opentelemetry-otel-0.20@go-sig, alexsaezm
golang-sigs-k8s-kustomize @go-sig, dcavalca
golang-vitess @go-sig, eclipseo
infinipath-psmhonli
j4-dmenu-desktop  ibotty
jackson-dataformats-binarymbooth
jackson-dataformats-text  mbooth
java-1.8.0-openjdk-aarch32akasko, jvanek
jreen rdieter
libdeltacloud clalance
mingw-clucene greghellings
mingw-speexdspjanisozaur
nbd-runnerxiubli
nodejs-generic-pool   patches, piotrp
ofono njha, thunderbirdtr
pesign-test-app   javierm, nfrayer, pjones, rharwood
pthsemixs
rust-drg  @rust-sig, jbtrystram

The following packages require above mentioned packages:
Depending on: erlang-jose (1)
erlang-p1_acme (maintained by: @erlang-maint-sig, bowlofeggs, peter)
erlang-p1_acme-1.0.8-9.fc40.noarch requires erlang-jose
erlang-p1_acme-1.0.8-9.fc40.src requires erlang-jose

Depending on: golang-github-genuinetools-pkg (1)
reg (maintained by: @go-sig, @infra-sig, mattia)
reg-0.16.1-15.fc40.src requires 
golang(github.com/genuinetools/pkg/cli)

Depending on: golang-github-gobs-pretty (2)
golang-github-vinyldns (maintained by: @go-sig, eclipseo)
		golang-github-vinyldns-0.9.13-1.fc40.2.src requires 
golang(github.com/gobs/pretty)


golang-github-acme-lego (maintained by: @go-sig, eclipseo)
		golang-github-acme-lego-4.4.0-8.fc37.src requires 
golang(github.com/vinyldns/go-vinyldns/vinyldns)
		golang-github-acme-lego-devel-4.4.0-8.fc37.noarch requires 
golang(github.com/vinyldns/go-vinyldns/vinyldns)


Depending on: golang-github-smartystreets-goconvey (23)
golang-github-afex-hystrix (maintained by: @go-sig, alexsaezm)
		golang-github-afex-hystrix-0-0.14.20190622gitfa1af6a.fc40.src requires 
golang(github.com/smartystreets/goconvey/convey)


golang-github-cucumber-godog (maintained by: @go-sig, eclipseo)
		golang-github-cucumber-godog-0.12.1-10.fc40.src requires 
golang(github.com/smartystreets/goconvey/convey)


golang-github-macaron-inject (maintained by: @go-sig, mikelo2)
		golang-github-macaron-inject-0-0.22.20210110git138e592.fc40.src requires 
golang(github.com/smartystreets/goconvey/convey)


golang-github-powerman-check (maintained by: @go-sig, eclipseo)
		golang-github-powerman-check-1.7.0-3.fc40.src requires 
golang(github.com/smartystreets/goconvey/convey), 
golang(github.com/smartystreets/goconvey/convey/reporting)
		golang-github-powerman-check-devel-1.7.0-3.fc40.noarch requires 
golang(github.com/smartystreets/goconvey/convey/reporting)


golang-github-unknwon-com (maintained by: @go-sig, agerstmayr, nathans)
		golang-github-unknwon-com-1:1.0.1-9.fc40.src requires 
golang(github.com/smartystreets/goconvey/convey)


golang-github-unknwon-goconfig 

Is Yatin Karel still around?

[Orion Poplawski]

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

no activity for over two years.

--
Orion Poplawski
he/him/his  - surely the least important thing about me
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301 https://www.nwra.com/


smime.p7s
Description: S/MIME Cryptographic 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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2262901] perl-LWP-Protocol-https-6.13 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-LWP-Protocol-https-6.1
   ||3-1.fc39
 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
Last Closed||2024-02-15 00:59:45



--- Comment #4 from Fedora Update System  ---
FEDORA-2024-c436309954 (perl-LWP-Protocol-https-6.13-1.fc39) has been pushed to
the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2262901

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202262901%23c4
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [heads up] update to jpegxl-0.9.2 with soname bump in rawhide

[Michael Catanzaro]

On Wed, Feb 14 2024 at 09:38:39 PM +00:00:00, Sérgio Basto 
 wrote:

I found "cc1plus: out of memory allocating 603 bytes after a total
of 86921216 bytes"



Thanks. This was a big help.

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

Re: [heads up] update to jpegxl-0.9.2 with soname bump in rawhide

[Sérgio Basto]

On Wed, 2024-02-14 at 12:57 -0600, Michael Catanzaro wrote:
> 
> I checked the build log for 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=113473592 but 
> unfortunately I don't actually see any error message. I searched for 
> "error:" (indicating a compiler error) and I also searched for
> "Killed" 
> (indicating OOM).
> 

I found "cc1plus: out of memory allocating 603 bytes after a total
of 86921216 bytes" 

on https://koji.fedoraproject.org/koji/taskinfo?taskID=113499057

FAILED:
Source/WebCore/CMakeFiles/WebCore.dir/__/__/WebCore/DerivedSources/unif
ied-sources/UnifiedSource-3a52ce78-89.cpp.o 
/usr/bin/g++ -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -
DBUILDING_WITH_CMAKE=1 -DBUILDING_WebCore -
DBWRAP_EXECUTABLE=\"/usr/bin/bwrap\" -
DDBUS_PROXY_EXECUTABLE=\"/usr/bin/xdg-dbus-proxy\" -
DGETTEXT_PACKAGE=\"WebKitGTK-6.0\" -DHAVE_CONFIG_H=1 -
DJSC_GLIB_API_ENABLED -DPAS_BMALLOC=1 -DSTATICALLY_LINKED_WITH_PAL -
DUSE_SYSTEM_EGL -I/builddir/build/BUILD/webkitgtk-2.43.4/redhat-linux-
build/webkitgtk-6.0 -I/builddir/build/BUILD/webkitgtk-2.43.4/redhat-
linux-build/webkitgtk-6.0/WebCore/DerivedSources -
I/builddir/build/BUILD/webkitgtk-2.43.4/Source/WebCore -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/ShapeDetection -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/ShapeDetection/Interfaces -
I/builddir/build/BUILD/webkitgtk-2.43.4/Source/WebCore/Modules/WebGPU -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/WebGPU/InternalAPI -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/WebGPU/Implementation -
I/builddir/build/BUILD/webkitgtk-2.43.4/Source/WebCore/Modules/airplay
-I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/applepay -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/applepay/paymentrequest -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/applicationmanifest -
I/builddir/build/BUILD/webkitgtk-2.43.4/Source/WebCore/Modules/async-
clipboard -I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/audiosession -
I/builddir/build/BUILD/webkitgtk-2.43.4/Source/WebCore/Modules/badge -
I/builddir/build/BUILD/webkitgtk-2.43.4/Source/WebCore/Modules/beacon -
I/builddir/build/BUILD/webkitgtk-2.43.4/Source/WebCore/Modules/cache -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/compression -
I/builddir/build/BUILD/webkitgtk-2.43.4/Source/WebCore/Modules/contact-
picker -I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/cookie-consent -
I/builddir/build/BUILD/webkitgtk-2.43.4/Source/WebCore/Modules/cookie-
store -I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/credentialmanagement -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/encryptedmedia -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/encryptedmedia/legacy -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/entriesapi -
I/builddir/build/BUILD/webkitgtk-2.43.4/Source/WebCore/Modules/fetch -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/filesystemaccess -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/geolocation -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/highlight -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/indexeddb -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/indexeddb/client -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/indexeddb/server -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/indexeddb/shared -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/mediacapabilities -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/mediacontrols -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/mediarecorder -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/mediasession -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/mediasource -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/mediastream -
I/builddir/build/BUILD/webkitgtk-2.43.4/Source/WebCore/Modules/model-
element -I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/model-element/dummy -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/navigatorcontentutils -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/notifications -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/paymentrequest -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/permissions -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/pictureinpicture -
I/builddir/build/BUILD/webkitgtk-2.43.4/Source/WebCore/Modules/plugins
-I/builddir/build/BUILD/webkitgtk-2.43.4/Source/WebCore/Modules/push-
api -I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/remoteplayback -
I/builddir/build/BUILD/webkitgtk-
2.43.4/Source/WebCore/Modules/reporting -

[Bug 2264268] New: F40FailsToInstall: perl-Alien-pkgconf

[bugzilla]

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

Bug ID: 2264268
   Summary: F40FailsToInstall: perl-Alien-pkgconf
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Alien-pkgconf
  Assignee: ppi...@redhat.com
  Reporter: fti-b...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
Blocks: 2231790 (F40FailsToInstall)
  Target Milestone: ---
Classification: Fedora



Hello,

Please note that this comment was generated automatically by
https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py
If you feel that this output has mistakes, please open an issue at
https://pagure.io/releng/

Your package (perl-Alien-pkgconf) Fails To Install in Fedora 40:

can't install perl-Alien-pkgconf:
  - nothing provides libpkgconf-devel(x86-64) = 1.9.5 needed by
perl-Alien-pkgconf-0.19-7.fc40.x86_64

If you know about this problem and are planning on fixing it, please
acknowledge so by setting the bug status to ASSIGNED. If you don't have time to
maintain this package, consider orphaning it, so maintainers of dependent
packages realize the problem.


If you don't react accordingly to the policy for FTBFS/FTI bugs
(https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/),
your package may be orphaned in 8+ weeks.


P.S. The data was generated solely from koji buildroot, so it might be newer
than the latest compose or the content on mirrors. To reproduce, use the
koji/local repo only, e.g. in mock:

$ mock -r fedora-40-x86_64 --config-opts mirrored=False install
perl-Alien-pkgconf


P.P.S. If this bug has been reported in the middle of upgrading multiple
dependent packages, please consider using side tags:
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages

Thanks!



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2231790
[Bug 2231790] Fedora 40 Fails To install Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2264268

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202264268%23c0
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2264260] New: F41FailsToInstall: perl-Alien-pkgconf

[bugzilla]

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

Bug ID: 2264260
   Summary: F41FailsToInstall: perl-Alien-pkgconf
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Alien-pkgconf
  Assignee: ppi...@redhat.com
  Reporter: fti-b...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
Blocks: 2260877 (F41FailsToInstall,RAWHIDEFailsToInstall)
  Target Milestone: ---
Classification: Fedora



Hello,

Please note that this comment was generated automatically by
https://pagure.io/releng/blob/main/f/scripts/ftbfs-fti/follow-policy.py
If you feel that this output has mistakes, please open an issue at
https://pagure.io/releng/

Your package (perl-Alien-pkgconf) Fails To Install in Fedora 41:

can't install perl-Alien-pkgconf:
  - nothing provides libpkgconf-devel(x86-64) = 1.9.5 needed by
perl-Alien-pkgconf-0.19-7.fc40.x86_64

If you know about this problem and are planning on fixing it, please
acknowledge so by setting the bug status to ASSIGNED. If you don't have time to
maintain this package, consider orphaning it, so maintainers of dependent
packages realize the problem.


If you don't react accordingly to the policy for FTBFS/FTI bugs
(https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fails_to_install/),
your package may be orphaned in 8+ weeks.


P.S. The data was generated solely from koji buildroot, so it might be newer
than the latest compose or the content on mirrors. To reproduce, use the
koji/local repo only, e.g. in mock:

$ mock -r fedora-41-x86_64 --config-opts mirrored=False install
perl-Alien-pkgconf


P.P.S. If this bug has been reported in the middle of upgrading multiple
dependent packages, please consider using side tags:
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updating-inter-dependent-packages

Thanks!



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2260877
[Bug 2260877] Fedora 41 Fails To install Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2264260

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202264260%23c0
--
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [heads up] update to jpegxl-0.9.2 with soname bump in rawhide

[Adam Williamson]

On Wed, 2024-02-14 at 12:57 -0600, Michael Catanzaro wrote:
> I checked the build log for 
> https://koji.fedoraproject.org/koji/taskinfo?taskID=113473592 but 
> unfortunately I don't actually see any error message. I searched for 
> "error:" (indicating a compiler error) and I also searched for "Killed" 
> (indicating OOM).
> 
> No doubt something is wrong somewhere in that build log, but I'm not 
> sure where.

We have untagged the update for now -
https://pagure.io/releng/issue/11952 - so this won't break Rawhide.
Once webkitgtk is buildable we can figure out how to take another cut
at this (I'm not sure exactly what the procedure is to get a side tag
update like this edited and retagged, we may *possibly* have to create
a new side tag, tag all the existing builds onto that, add a webkitgtk
build, and create a new update?)
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

Re: [heads up] update to jpegxl-0.9.2 with soname bump in rawhide

[Michael Catanzaro]

I checked the build log for 
https://koji.fedoraproject.org/koji/taskinfo?taskID=113473592 but 
unfortunately I don't actually see any error message. I searched for 
"error:" (indicating a compiler error) and I also searched for "Killed" 
(indicating OOM).


No doubt something is wrong somewhere in that build log, but I'm not 
sure where.


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

Re: Why branched config pointed to rolling config?

[Miroslav Suchý]

Dne 14. 02. 24 v 14:56 Michael J Gruber napsal(a):

Why branched config pointed to rolling config?
# ls -ln | grep fedora-40
lrwxrwxrwx. 1 0 135   26 Jan 11 20:46 fedora-40-aarch64.cfg -> 
fedora-rawhide-aarch64.cfg
lrwxrwxrwx. 1 0 135   23 Jan 11 20:46 fedora-40-i386.cfg -> 
fedora-rawhide-i386.cfg
lrwxrwxrwx. 1 0 135   26 Jan 11 20:46 fedora-40-ppc64le.cfg -> 
fedora-rawhide-ppc64le.cfg
lrwxrwxrwx. 1 0 135   24 Jan 11 20:46 fedora-40-s390x.cfg -> 
fedora-rawhide-s390x.cfg
lrwxrwxrwx. 1 0 135   25 Jan 11 20:46 fedora-40-x86_64.cfg -> 
fedora-rawhide-x86_64.cfg

... because on Jan 25th, f40 was rawhide.

We branched yesterday. So, either you wait for updated mock-config to
land in f40, or you roll it yourself. It's no mock science 


And if you check Bodhi, it is sitting there and waiting for you guys :)

https://bodhi.fedoraproject.org/updates/?search=mock-core-configs

--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Does splint work for anyone?

[Stephen Smoogen]

On Fri, 9 Feb 2024 at 17:17, Ian Laurie  wrote:

> On 2/10/24 05:06, Stephen Smoogen wrote:
> >
> > I was trying out the splint program on some code and found that it
> > doesn't seem to work on any recent release due to changes in various
> > header files
> I tried using splint many years ago in connection with embedded
> programming, and even though the GCC based embedded compiler I was using
> was several major version numbers behind what was natively in Fedora, I
> found splint to be hopelessly behind the times and utterly unusable.  I
> don't know why it is even packaged in Fedora.
>
> I wish I had the skills necessary to bring it up to date but I don't.
>
>
Me too. I saw it is FTBFS in F40 and added my data to
https://bugzilla.redhat.com/show_bug.cgi?id=2261709



> --
> Ian Laurie
> FAS: nixuser | IRC: nixuser
> TZ: Australia/Sydney
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

JACK rtprio=60, PipeWire rtprio=88: Why?

[Runiq via devel]

Hey,

I intend to pull the rtirq package [1] back into this decade and 
realized there's a discrepancy between the priorities of JACK and 
PipeWire realtime threads.


JACK's is at 60, per the decision made in Fedora 17 [2]:

```
$ ps -p 109009 -Lo tid,class,pri,rtprio,command 


TID CLS PRI RTPRIO COMMAND
 109009 TS   19  - jackd --realtime -dalsa -dhw:0 -r48000 -p512 -n2
 109023 TS   19  - jackd --realtime -dalsa -dhw:0 -r48000 -p512 -n2
 109024 TS   19  - jackd --realtime -dalsa -dhw:0 -r48000 -p512 -n2
 109025 FF   60 20 jackd --realtime -dalsa -dhw:0 -r48000 -p512 -n2
 109026 TS   19  - jackd --realtime -dalsa -dhw:0 -r48000 -p512 -n2
```

Accordingly, the jackuser group rtprio limit is set to 70:

```
# /etc/security/limits.d/95-jack.conf
@jackuser - rtprio 70
@jackuser - memlock 4194304

@pulse-rt - rtprio 20
@pulse-rt - nice -20
```

On the other hand, PipeWire's realtime thread runs with prio 88:

```
$ ps -p 4453 -Lo tid,class,pri,rtprio,command
TID CLS PRI RTPRIO COMMAND
   4453 TS   30  - /usr/bin/pipewire
   4460 FF  128 88 /usr/bin/pipewire
```

And the group gets an rtprio limit of 95:

```
# /etc/security/limits.d/25-pw-rlimits.conf
@pipewire   - rtprio  95
@pipewire   - nice-19
@pipewire   - memlock 4194304
```

Is there a reason for this discrepancy? Apart from the already mentioned 
email acknowledging the policy change in Fedora 17 [2], I couldn't find 
anything else about that. Since both Pipewire and JACK fill similar 
roles, I would have expected them to both have similar rtprio values.


I've also posted this to Ask Fedora [3].

Best regards,
Patrice

[1] https://src.fedoraproject.org/rpms/rtirq
[2] https://cm-mail.stanford.edu/pipermail/planetccrma/2012-May/018018.html
[3] https://discussion.fedoraproject.org/t/105188
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [heads up] update to jpegxl-0.9.2 with soname bump in rawhide

[Fabio Valentini]

On Wed, Feb 14, 2024 at 7:00 PM Sérgio Basto  wrote:
>
> On Wed, 2024-02-14 at 16:41 +0100, Fabio Valentini wrote:
> > On Wed, Feb 14, 2024 at 2:53 PM Sérgio Basto 
> > wrote:
> > >
> > > On Fri, 2024-02-09 at 13:28 +, Sérgio Basto wrote:
> > > > Hi,
> > > > I will start a mass rebuild [1] in a side-tag, very soon , the
> > > > goal
> > > > is
> > > > finish and merge it before branch of Fedora 40, please let me
> > > > know we
> > > > have any objection that prevent to proceeding.
> > > >
> > >
> > > As we already have the new branch f40, I started the rebuild for
> > > f41.
> > >
> > > I added  `%global build_type_safety_c 0` to gimp.spec and
> > > workaround
> > > modern C and build gimp
> > >
> > > but seamokey , gthumbs and webkitgtk-2.43.4-4.fc41 failed to build
> > > [1]
> > >
> > > webkitgtk just failed on i686 , should I processed to F40 ?
> >
> > webkitgtk is a critical package that would likely cause composes to
> > fail.
> > I don't think the side tag should be merged unless this package is
> > fixed and can be rebuilt.
>
>
> side-tag for rawhide (f41) was pushed before I started to write
>
> but webkitgtk also FTBFS in F40 without any modification :
>
> cd webkitgtk
> git checkout f40
> fedpkg  scratch-build --arch=i686

That doesn't really matter, but now it also will fail to *install* in
addition to failing to build (which is *not good*) ...
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [heads up] update to jpegxl-0.9.2 with soname bump in rawhide

[Sérgio Basto]

On Wed, 2024-02-14 at 16:41 +0100, Fabio Valentini wrote:
> On Wed, Feb 14, 2024 at 2:53 PM Sérgio Basto 
> wrote:
> > 
> > On Fri, 2024-02-09 at 13:28 +, Sérgio Basto wrote:
> > > Hi,
> > > I will start a mass rebuild [1] in a side-tag, very soon , the
> > > goal
> > > is
> > > finish and merge it before branch of Fedora 40, please let me
> > > know we
> > > have any objection that prevent to proceeding.
> > > 
> > 
> > As we already have the new branch f40, I started the rebuild for
> > f41.
> > 
> > I added  `%global build_type_safety_c 0` to gimp.spec and
> > workaround
> > modern C and build gimp
> > 
> > but seamokey , gthumbs and webkitgtk-2.43.4-4.fc41 failed to build 
> > [1]
> > 
> > webkitgtk just failed on i686 , should I processed to F40 ?
> 
> webkitgtk is a critical package that would likely cause composes to
> fail.
> I don't think the side tag should be merged unless this package is
> fixed and can be rebuilt.


side-tag for rawhide (f41) was pushed before I started to write 

but webkitgtk also FTBFS in F40 without any modification : 

cd webkitgtk
git checkout f40
fedpkg  scratch-build --arch=i686

113499057 buildArch (webkitgtk-2.43.4-3.fc40.src.rpm, i686): open
(buildhw-x86-04.iad2.fedoraproject.org) -> FAILED: BuildError: error
building package (arch i686), mock exited with status 1; see build.log
or root.log for more information

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

-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: do we need CONFIG_UPROBES=y in our kernels?

[Andrew Lutomirski]

> On Feb 12, 2024, at 10:18 AM, Marius Schwarz  wrote:
>
> Hi,
>
> I excuse myself if this has been already discussed, bastion ML server was 
> blacklisted (has been removed btw).
>
> Short summary(for details use the source link):
>
> In a german developer blog article was the topic raised, that with uprobes 
> enabled, userland apps can i.e. circumvent tls security(and other 
> protections),
> by telling the kernel to probe the function calls with the uprobes api. As 
> this enables i.e. the hosting system of a vm or container, to track activity 
> inside the container, trust is lost i.e. from customer to hoster. To be fair, 
> you need to be root on the host to do this, but as it "wasn't possible 
> before", and it is "now" ( out in a greater public ), it tends to create 
> trust issues, just for being there*.
>
> As this only works with uprobes enabled and has no use case besides a 
> developer debugging apps, the question is:

With my kernel developer hat on, this is ridiculous.  Of course the
host of a container or VM can see what’s going on inside the
container/VM, and no amount of changing Fedora’s kernel configuration
will make a difference. The host can use a hypervisor or run a
different kernel or use ptrace or use perf or use nsenter or look at
/proc or use kprobes or use bpfttrace or use *any* bpf program with
memory-reading permission [0].

 This proposed change would serve to annoy Fedora users and have no
other benefit.

[0] it’s surprisingly poorly advertised, but, while BPF itself is
nominally memory-safe, eBPF usually exposes a function that serves as
a fairly complete escape hatch for reading user and kernel memory.


>
> Do we need this for all others out there enabled by default?
>
> If noone can name an app/lib that needs this outside of the C* development 
> process, a change proposal would be wise. maybe adding a kernel boot argument 
> switch?
>
> Source: http://blog.fefe.de/?ts=9b3a23b2
>
> *) You may not have a clue, what security auditors tell you about "a 
> vulnerability & it's just there, but inexploitable". I had a case 2 weeks 
> ago, about a missing patch for the ssh-agent CVE vulnerability in fedora's 
> openssh. Trust me, it will create trouble the more the topic is discussed in 
> the pubic.
>
>
> Best regards,
> Marius Schwarz
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora 40 Mass Branching complete

[Samyak Jain]

Hi All,

Fedora Linux f40 has now been branched, please be sure to do a
'git fetch -v' to pick up the new branch. As an additional reminder,
rawhide/f40 has been completely isolated from previous releases, which
means that anything you do for 40 you also have to do in the rawhide
branch and do a build there. There is already a Fedora Linux 39 compose
at[1].

Bodhi is currently enabled in the f40 branch like it is for rawhide, with
automatic update creation. At the hit Beta change freeze point in the
Fedora Linux 40 schedule [2] updates-testing will be enabled and manual
bodhi updates will be required as in all stable releases.

Thanks for understanding.

Regards,
Samyak Jain
Fedora Release Engineering

[1] https://dl.fedoraproject.org/pub/fedora/linux/development/40/
[2] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora 40 Mass Branching complete

[Samyak Jain]

Hi All,

Fedora Linux f40 has now been branched, please be sure to do a
'git fetch -v' to pick up the new branch. As an additional reminder,
rawhide/f40 has been completely isolated from previous releases, which
means that anything you do for 40 you also have to do in the rawhide
branch and do a build there. There is already a Fedora Linux 39 compose
at[1].

Bodhi is currently enabled in the f40 branch like it is for rawhide, with
automatic update creation. At the hit Beta change freeze point in the
Fedora Linux 40 schedule [2] updates-testing will be enabled and manual
bodhi updates will be required as in all stable releases.

Thanks for understanding.

Regards,
Samyak Jain
Fedora Release Engineering

[1] https://dl.fedoraproject.org/pub/fedora/linux/development/40/
[2] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html
--
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Orphaned packages looking for new maintainers

[Maxwell G]

NOTE: This was not sent to individual maintainers, as @fedoraproject.org
aliases are currently broken
(https://pagure.io/fedora-infrastructure/issue/11768).
I will send another announcement once that's fixed.

---

Report started at 2024-02-13 01:07:53 UTC

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

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

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

Full report available at:
https://a.gtmx.me/orphans/orphans.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package   (co)maintainers  Status Change

3proxy orphan  0 weeks ago  
R-presser  @r-maint-sig, orphan1 weeks ago  
applet-window-buttons  @kde-sig, orphan2 weeks ago  
atinoutorphan  0 weeks ago  
bismuth@kde-sig, orphan2 weeks ago  
callaudiod orphan  0 weeks ago  
drumstick0 orphan, yanqiyu 3 weeks ago  
elpa   @scitech_sig, orphan5 weeks ago  
gnome-translateorphan  2 weeks ago  
golang-github- @go-sig, ngompa, orphan 0 weeks ago  
googlecloudplatform-guest-  
logging 
golang-gocloud @go-sig, orphan 0 weeks ago  
golang-storj-uplink@go-sig, orphan 1 weeks ago  
google-compute-engine-guest-   ngompa, orphan  0 weeks ago  
configs 
google-disk-expand orphan  0 weeks ago  
google-guest-agent @go-sig, ngompa, orphan 0 weeks ago  
google-osconfig-agent  @go-sig, orphan 0 weeks ago  
kpipewire5 @kde-sig, orphan4 weeks ago  
ksysguard  @kde-sig, orphan1 weeks ago  
libmodulemd1   @copr-sig, orphan   1 weeks ago  
libtranslate   orphan  2 weeks ago  
lightlyorphan  2 weeks ago  
ocaml-newt orphan  1 weeks ago  
perl-PDF-Haru  orphan  0 weeks ago  
phosh-mobile-settings  orphan  0 weeks ago  
php-PHP-CSS-Parser orphan  5 weeks ago  
php-doctrine-persistence2  orphan  1 weeks ago  
php-doctrine-persistence3  orphan  1 weeks ago  
php-echonest-api   orphan  2 weeks ago  
php-endroid-qrcode orphan  1 weeks ago  
php-interfasys-lognormalizer   orphan  1 weeks ago  
php-ircmaxell-random-lib   orphan  1 weeks ago  
php-ircmaxell-security-lib orphan  1 weeks ago  
php-kukulich-fshl  orphan  1 weeks ago  
php-mikealmond-musicbrainz orphan  2 weeks ago  
php-nyholm-psr7orphan  1 weeks ago  
php-pear-MDB2-Schema   orphan  1 weeks ago  
php-phpdocumentor-reflection-  orphan  1 weeks ago  
docblock
php-symfony-monolog-bundle orphan  1 weeks ago  
php-true-punycode  orphan  1 weeks ago  
purple-mm-sms  orphan  0 weeks ago  

Re: Unresponsive maintainer: petersen / Pandoc package not updated since June 2023: Security vulnerability, CVE-2023-35936 (medium)

[Michel Lind]

As a pandoc user, I'm happy to help with any reviews. Is there a list
where this tends to get posted, apart from devel?

Thanks,

Michel

On Fri, Feb 09, 2024 at 11:26:33PM +0800, Jens-Ulrik Petersen wrote:
> I should also have added there's an increasing amount of technical debt
> with the pandoc packaging - I guess I need to beg people to help with
> package reviews: also reminded of our packaging (review) streamlining
> discussion from Flock last year.
> 
> Jens
> 
> On Fri, 9 Feb 2024, 23:23 Jens-Ulrik Petersen,  wrote:
> 
> > Hello I am here - thanks for contacting me.
> >
> > I was hoping to cover this as part of my F40 Change, but unfortunately I
> > haven't gotten to it, so the Change is now at risk of being deferred to F41.
> >
> > Nevertheless I will see what I can do about this for F40: maybe a backport
> > can also be done for F39.
> >
> > Next time you could also comment on the relevant bug:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1996301 - that would be
> > appreciated.
> >
> > Thanks, Jens
> >
> > PS Special thanks to Neal Gompa for pinging me in Matrix. 
> >
> >
> > On Fri, 9 Feb 2024, 20:05 Christopher Klooz,  wrote:
> >
> >> I cannot reach the maintainer petersen (see mail below): The package
> >> "pandoc" remains at 3.1.3 in Fedora, but pandoc is already at 3.1.11.1.
> >> Among the updates since 3.1.3, there have been two security-critical
> >> (including the medium CVE-2023-35936. Security fixes are in 3.1.4 & 3.1.6).
> >>
> >> The actual risk is limited, but these should be updated nevertheless.
> >>
> >> Does anyone know how to reach him by other means?
> >>
> >> Regards,
> >> Chris
> >>
> >>
> >>  Forwarded Message 
> >> Subject: Fedora package "pandoc" outdated and contains security
> >> vulnerability
> >> Date: Thu, 1 Feb 2024 15:55:09 +0100
> >> From: py0...@posteo.net
> >> To: peter...@fedoraproject.org
> >>
> >> Hi petersen,
> >>
> >> I am reaching out because of the package "pandoc", which you maintain.
> >>
> >> I have seen that the package is still at version 3.1.3 [1] when I tried
> >> to install it with dnf, whereas the current version is 3.1.11.1 [2]: is
> >> this intended or an accident?
> >>
> >> It has to be noted that the updates that have been added in the meantime
> >> contain fixes for security vulnerabilities (at least CVE-2023-35936; I have
> >> just roughly skimmed the changelogs). So at the moment, it seems the Fedora
> >> build can be exploited by attackers in some circumstances [3] [4] because
> >> it is still at 3.1.3.
> >>
> >> Regards & thanks for maintaining,
> >>
> >> Chris
> >>
> >> [1] https://koji.fedoraproject.org/koji/packageinfo?packageID=11560
> >>
> >> [2] https://hackage.haskell.org/package/pandoc &
> >> https://github.com/jgm/pandoc
> >>
> >> [3] https://github.com/jgm/pandoc/releases?page=1
> >>
> >> [4] https://github.com/jgm/pandoc/releases?page=2
> >>
> >> --
> >> ___
> >> devel mailing list -- devel@lists.fedoraproject.org
> >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >> Fedora Code of Conduct:
> >> https://docs.fedoraproject.org/en-US/project/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, report it:
> >> https://pagure.io/fedora-infrastructure/new_issue
> >>
> >

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


-- 
Michel Lind (né Salim)
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Question about conditional BuildRequires lines

[David Abdurachmanov]

On Wed, Feb 14, 2024 at 5:55 PM Tom Hughes via devel
 wrote:
>
> On 14/02/2024 15:48, Richard W.M. Jones wrote:
> > On Wed, Feb 14, 2024 at 03:21:38PM +, Tom Hughes wrote:
> >> On 14/02/2024 14:54, Richard W.M. Jones wrote:
> >>
> >>> https://src.fedoraproject.org/rpms/rapidjson/pull-request/7
> >>>
> >>> I don't think what Tom is saying there is correct, or is it?
> >>
> >> The answer is that I'm wrong about it breaking things, because
> >> koji uses the unpacked spec file to install dependencies not the
> >> requires from the srpm.
> >>
> >> However the guidelines whilst not mentioning this case do prohibit
> >> the use of %{_isa} in BRs because it produces incorrect dependencies
> >> in the srpm - the only real difference is that this case give you
> >> a missing dependency rather than a broken one.
> >
> > I was hoping that people with more experience would comment on the
> > bug, and they did, so thanks.
> >
> > The issue we have is that valgrind is simply not a package on RISC-V.
> > Valgrind requires upstream porting work which is only partially
> > complete (and IIRC not upstream yet).  I don't know any other way to
> > express this other than using:
>
> As it happens I'm an upstream valgrind developer and yes there
> are patches around but they're not merged yet.
>
> I'm not saying I won't take the patch I was just surprised it
> was allowed and/or worked and was trying to find out more details
> before I did anything.

There are a number of _arches macros defined in Fedora. Usually that's
language specific, but not always (e.g. qt webengine). Those are
mostly used for BuildRequires, ExclusiveArch, enabling/disabled
configure/test/etc. flags.

Cheers,
david

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

Re: Question about conditional BuildRequires lines

[Tom Hughes via devel]

On 14/02/2024 15:48, Richard W.M. Jones wrote:

On Wed, Feb 14, 2024 at 03:21:38PM +, Tom Hughes wrote:

On 14/02/2024 14:54, Richard W.M. Jones wrote:


https://src.fedoraproject.org/rpms/rapidjson/pull-request/7

I don't think what Tom is saying there is correct, or is it?


The answer is that I'm wrong about it breaking things, because
koji uses the unpacked spec file to install dependencies not the
requires from the srpm.

However the guidelines whilst not mentioning this case do prohibit
the use of %{_isa} in BRs because it produces incorrect dependencies
in the srpm - the only real difference is that this case give you
a missing dependency rather than a broken one.


I was hoping that people with more experience would comment on the
bug, and they did, so thanks.

The issue we have is that valgrind is simply not a package on RISC-V.
Valgrind requires upstream porting work which is only partially
complete (and IIRC not upstream yet).  I don't know any other way to
express this other than using:


As it happens I'm an upstream valgrind developer and yes there
are patches around but they're not merged yet.

I'm not saying I won't take the patch I was just surprised it
was allowed and/or worked and was trying to find out more details
before I did anything.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Question about conditional BuildRequires lines

[Richard W.M. Jones]

On Wed, Feb 14, 2024 at 03:21:38PM +, Tom Hughes wrote:
> On 14/02/2024 14:54, Richard W.M. Jones wrote:
> 
> >https://src.fedoraproject.org/rpms/rapidjson/pull-request/7
> >
> >I don't think what Tom is saying there is correct, or is it?
> 
> The answer is that I'm wrong about it breaking things, because
> koji uses the unpacked spec file to install dependencies not the
> requires from the srpm.
> 
> However the guidelines whilst not mentioning this case do prohibit
> the use of %{_isa} in BRs because it produces incorrect dependencies
> in the srpm - the only real difference is that this case give you
> a missing dependency rather than a broken one.

I was hoping that people with more experience would comment on the
bug, and they did, so thanks.

The issue we have is that valgrind is simply not a package on RISC-V.
Valgrind requires upstream porting work which is only partially
complete (and IIRC not upstream yet).  I don't know any other way to
express this other than using:

%ifarch %{valgrind_arches}
BuildRequires: valgrind
%endif

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [heads up] update to jpegxl-0.9.2 with soname bump in rawhide

[Fabio Valentini]

On Wed, Feb 14, 2024 at 2:53 PM Sérgio Basto  wrote:
>
> On Fri, 2024-02-09 at 13:28 +, Sérgio Basto wrote:
> > Hi,
> > I will start a mass rebuild [1] in a side-tag, very soon , the goal
> > is
> > finish and merge it before branch of Fedora 40, please let me know we
> > have any objection that prevent to proceeding.
> >
>
> As we already have the new branch f40, I started the rebuild for f41.
>
> I added  `%global build_type_safety_c 0` to gimp.spec and workaround
> modern C and build gimp
>
> but seamokey , gthumbs and webkitgtk-2.43.4-4.fc41 failed to build  [1]
>
> webkitgtk just failed on i686 , should I processed to F40 ?

webkitgtk is a critical package that would likely cause composes to fail.
I don't think the side tag should be merged unless this package is
fixed and can be rebuilt.

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

Re: Why branched config pointed to rolling config?

[Sérgio Basto]

On Wed, 2024-02-14 at 13:38 +, Mikhail Gavrilov wrote:
> Why branched config pointed to rolling config?
> # ls -ln | grep fedora-40
> lrwxrwxrwx. 1 0 135   26 Jan 11 20:46 fedora-40-aarch64.cfg ->
> fedora-rawhide-aarch64.cfg
> lrwxrwxrwx. 1 0 135   23 Jan 11 20:46 fedora-40-i386.cfg -> fedora-
> rawhide-i386.cfg
> lrwxrwxrwx. 1 0 135   26 Jan 11 20:46 fedora-40-ppc64le.cfg ->
> fedora-rawhide-ppc64le.cfg
> lrwxrwxrwx. 1 0 135   24 Jan 11 20:46 fedora-40-s390x.cfg -> fedora-
> rawhide-s390x.cfg
> lrwxrwxrwx. 1 0 135   25 Jan 11 20:46 fedora-40-x86_64.cfg -> fedora-
> rawhide-x86_64.cfg
> 
> I build every day mesa snapshot, but today `mock -r fedora-rawhide-
> i386 ...` beginning create packages of 41 branch. And I can't fix it
> by `mock -r fedora-40-i386 ...` because 40 means rawhide now :(

we need update mock-core-configs, but is not yet available , I'm going
check it with Fedora Build System group 

-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Question about conditional BuildRequires lines

[Tom Hughes via devel]

On 14/02/2024 14:54, Richard W.M. Jones wrote:


https://src.fedoraproject.org/rpms/rapidjson/pull-request/7

I don't think what Tom is saying there is correct, or is it?


The answer is that I'm wrong about it breaking things, because
koji uses the unpacked spec file to install dependencies not the
requires from the srpm.

However the guidelines whilst not mentioning this case do prohibit
the use of %{_isa} in BRs because it produces incorrect dependencies
in the srpm - the only real difference is that this case give you
a missing dependency rather than a broken one.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Question about conditional BuildRequires lines

[Richard W.M. Jones]

https://src.fedoraproject.org/rpms/rapidjson/pull-request/7

I don't think what Tom is saying there is correct, or is it?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20240214.n.1 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20240212.n.0
NEW: Fedora-Rawhide-20240214.n.1

= SUMMARY =
Added images:3
Dropped images:  3
Added packages:  8
Dropped packages:6
Upgraded packages:   217
Downgraded packages: 0

Size of added packages:  13.01 MiB
Size of dropped packages:491.29 MiB
Size of upgraded packages:   5.73 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Server raw-xz aarch64
Path: Server/aarch64/images/Fedora-Server-Rawhide-20240214.n.1.aarch64.raw.xz
Image: Comp_Neuro live x86_64
Path: Labs/x86_64/iso/Fedora-Comp_Neuro-Live-x86_64-Rawhide-20240214.n.1.iso
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20240214.n.1.iso

= DROPPED IMAGES =
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20240212.n.0.iso
Image: Onyx ociarchive x86_64
Path: Onyx/x86_64/images/Fedora-Onyx-Rawhide.20240212.n.0.ociarchive
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20240212.n.0.iso

= ADDED PACKAGES =
Package: intel-llvm-vc-intrinsics11-0.17.0-1.20240206git1ba2c43.fc40
Summary: New intrinsics on top of core LLVM 11 IR instructions
RPMs:intel-llvm-vc-intrinsics11-devel
Size:714.29 KiB

Package: libva-intel-hybrid-driver-1.0.2-28.fc40
Summary: VA driver for Intel G45 & HD Graphics family
RPMs:libva-intel-hybrid-driver
Size:882.60 KiB

Package: lld16-16.0.6-3.fc40
Summary: The LLVM Linker
RPMs:lld16-devel lld16-libs
Size:5.87 MiB

Package: rust-socks-0.3.4-1.fc40
Summary: SOCKS proxy clients
RPMs:rust-socks+default-devel rust-socks-devel
Size:27.03 KiB

Package: rust-titlecase-2.2.1-2.fc41
Summary: Capitalize text according to the Daring Fireball style
RPMs:rust-titlecase+default-devel rust-titlecase-devel
Size:22.22 KiB

Package: rust-v_htmlescape-0.15.8-1.fc40
Summary: Simd optimized HTML escaping code
RPMs:rust-v_htmlescape+buf-min-devel rust-v_htmlescape+bytes-buf-devel 
rust-v_htmlescape+default-devel rust-v_htmlescape-devel
Size:39.59 KiB

Package: spirv-llvm-translator11-11-1.20240131git2e025e4.fc40
Summary: LLVM 11 to SPIRV Translator
RPMs:spirv-llvm-translator11 spirv-llvm-translator11-devel 
spirv-llvm-translator11-tools
Size:3.74 MiB

Package: webrtc-audio-processing0.3-0.3.1-12.fc40
Summary: Library for echo cancellation
RPMs:webrtc-audio-processing0.3 webrtc-audio-processing0.3-devel
Size:1.76 MiB


= DROPPED PACKAGES =
Package: intel-llvm8.0-vc-intrinsics-0-6.20211222git753ad50.fc40
Summary: New intrinsics on top of core LLVM IR instructions
RPMs:intel-llvm8.0-vc-intrinsics intel-llvm8.0-vc-intrinsics-devel
Size:692.74 KiB

Package: llvm7.0-7.0.1-7.fc40.10
Summary: The Low Level Virtual Machine
RPMs:llvm7.0 llvm7.0-devel llvm7.0-doc llvm7.0-libs llvm7.0-static
Size:194.46 MiB

Package: llvm8.0-8.0.1-7.fc40
Summary: The Low Level Virtual Machine
RPMs:llvm8.0 llvm8.0-devel llvm8.0-doc llvm8.0-libs llvm8.0-static
Size:270.14 MiB

Package: ocaml-migrate-parsetree-2.4.0-4.fc38
Summary: Convert OCaml parsetrees between different major versions
RPMs:ocaml-migrate-parsetree ocaml-migrate-parsetree-devel
Size:23.08 MiB

Package: perl-Test-Vars-0.015-9.fc39
Summary: Detects unused variables
RPMs:perl-Test-Vars
Size:26.17 KiB

Package: spirv-llvm8.0-translator-8-7.20211223gita44863e.fc40
Summary: LLVM 8.0 to SPIRV Translator
RPMs:spirv-llvm8.0-translator spirv-llvm8.0-translator-devel 
spirv-llvm8.0-translator-tools
Size:2.90 MiB


= UPGRADED PACKAGES =
Package:  OpenIPMI-2.0.34-1.fc40
Old package:  OpenIPMI-2.0.32-13.fc40
Summary:  IPMI (Intelligent Platform Management Interface) library and tools
RPMs: OpenIPMI OpenIPMI-devel OpenIPMI-lanserv OpenIPMI-libs
Dropped RPMs: OpenIPMI-perl python3-openipmi
Size: 4.57 MiB
Size change:  -1.26 MiB
Changelog:
  * Sun Feb 11 2024 Pavel Cahyna  - 2.0.34-1
  - Update to 2.0.34 (rhbz#2105023)
  - Resolve issues found by rpmdiff
- add a patch to fix getaddrinfo detection to avoid using gethostbyname
- add explicit Requires: on subpackages to avoid the need to test
  interoperability between the various combinations of old and new
  subpackages
  - Conditional Perl & Python module build, by default disabled


Package:  abrt-2.17.4-1.fc40
Old package:  abrt-2.17.1-5.fc40
Summary:  Automatic bug detection and reporting tool
RPMs: abrt abrt-addon-ccpp abrt-addon-kerneloops abrt-addon-pstoreoops 
abrt-addon-upload-watch abrt-addon-vmcore abrt-addon-xorg abrt-atomic abrt-cli 
abrt-console-notification abrt-dbus abrt-desktop abrt-devel abrt-gui 
abrt-gui-devel abrt-gui-libs abrt-libs abrt-plugin-bodhi abrt-plugin-machine-id 
abrt-tui python3-abrt python3-abrt-addon python3-abrt-contain

Re: Why branched config pointed to rolling config?

[Michael J Gruber]

Am Mi., 14. Feb. 2024 um 14:48 Uhr schrieb Mikhail Gavrilov
:
>
> Why branched config pointed to rolling config?
> # ls -ln | grep fedora-40
> lrwxrwxrwx. 1 0 135   26 Jan 11 20:46 fedora-40-aarch64.cfg -> 
> fedora-rawhide-aarch64.cfg
> lrwxrwxrwx. 1 0 135   23 Jan 11 20:46 fedora-40-i386.cfg -> 
> fedora-rawhide-i386.cfg
> lrwxrwxrwx. 1 0 135   26 Jan 11 20:46 fedora-40-ppc64le.cfg -> 
> fedora-rawhide-ppc64le.cfg
> lrwxrwxrwx. 1 0 135   24 Jan 11 20:46 fedora-40-s390x.cfg -> 
> fedora-rawhide-s390x.cfg
> lrwxrwxrwx. 1 0 135   25 Jan 11 20:46 fedora-40-x86_64.cfg -> 
> fedora-rawhide-x86_64.cfg

... because on Jan 25th, f40 was rawhide.

We branched yesterday. So, either you wait for updated mock-config to
land in f40, or you roll it yourself. It's no mock science :)

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

Re: [heads up] update to jpegxl-0.9.2 with soname bump in rawhide

[Sérgio Basto]

On Fri, 2024-02-09 at 13:28 +, Sérgio Basto wrote:
> Hi, 
> I will start a mass rebuild [1] in a side-tag, very soon , the goal
> is
> finish and merge it before branch of Fedora 40, please let me know we
> have any objection that prevent to proceeding.
> 

As we already have the new branch f40, I started the rebuild for f41.

I added  `%global build_type_safety_c 0` to gimp.spec and workaround
modern C and build gimp  

but seamokey , gthumbs and webkitgtk-2.43.4-4.fc41 failed to build  [1]

webkitgtk just failed on i686 , should I processed to F40 ? 


Best regards, 

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

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

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

https://bodhi.fedoraproject.org/updates/FEDORA-2024-72fe625282

> Best regards,
> 
> [1]
> dnf repoquery --disablerepo=* --enablerepo={rpmfusion-{non,}free-
> ,}rawhide --whatrequires "libjxl*"  --qf "%{repoid} %{sourcerpm}" |
> pkgname  
> rawhide ImageMagick
> rawhide aom
> rawhide darktable
> rawhide efl
> rawhide ffmpeg
> rawhide geeqie
> rawhide gimp
> rawhide gthumb
> rawhide imlib2
> rawhide jpegxl
> rawhide kf5-kimageformats
> rawhide kf6-kimageformats
> rawhide krita
> rawhide seamonkey
> rawhide vips
> rawhide webkit2gtk4.0
> rawhide webkitgtk
> rawhide xine-lib
> -- 
> 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, report it:
> https://pagure.io/fedora-infrastructure/new_issue

-- 
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Why branched config pointed to rolling config?

[Mikhail Gavrilov]

Why branched config pointed to rolling config?
# ls -ln | grep fedora-40
lrwxrwxrwx. 1 0 135   26 Jan 11 20:46 fedora-40-aarch64.cfg -> 
fedora-rawhide-aarch64.cfg
lrwxrwxrwx. 1 0 135   23 Jan 11 20:46 fedora-40-i386.cfg -> 
fedora-rawhide-i386.cfg
lrwxrwxrwx. 1 0 135   26 Jan 11 20:46 fedora-40-ppc64le.cfg -> 
fedora-rawhide-ppc64le.cfg
lrwxrwxrwx. 1 0 135   24 Jan 11 20:46 fedora-40-s390x.cfg -> 
fedora-rawhide-s390x.cfg
lrwxrwxrwx. 1 0 135   25 Jan 11 20:46 fedora-40-x86_64.cfg -> 
fedora-rawhide-x86_64.cfg

I build every day mesa snapshot, but today `mock -r fedora-rawhide-i386 ...` 
beginning create packages of 41 branch. And I can't fix it by `mock -r 
fedora-40-i386 ...` because 40 means rawhide now :(
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Why branched config pointed to rolling config?

[Mikhail Gavrilov]

Why branched config pointed to rolling config?

# ls -ln | grep fedora-40
lrwxrwxrwx. 1 0 135   26 Jan 11 20:46 fedora-40-aarch64.cfg -> 
fedora-rawhide-aarch64.cfg
lrwxrwxrwx. 1 0 135   23 Jan 11 20:46 fedora-40-i386.cfg -> 
fedora-rawhide-i386.cfg
lrwxrwxrwx. 1 0 135   26 Jan 11 20:46 fedora-40-ppc64le.cfg -> 
fedora-rawhide-ppc64le.cfg
lrwxrwxrwx. 1 0 135   24 Jan 11 20:46 fedora-40-s390x.cfg -> 
fedora-rawhide-s390x.cfg
lrwxrwxrwx. 1 0 135   25 Jan 11 20:46 fedora-40-x86_64.cfg -> 
fedora-rawhide-x86_64.cfg

I build every day mesa snapshot, but today `mock -r fedora-rawhide-i386 ...` 
beginning create packages of 41 branch. And I can't fix it by `mock -r 
fedora-40-i386 ...` because 40 means rawhide now :(
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: A note about riscv64 changes

[Dan Horák]

On Wed, 14 Feb 2024 12:29:00 +
Peter Robinson  wrote:

> On Wed, 14 Feb 2024 at 12:07, David Abdurachmanov
>  wrote:
> >
> > On Wed, Feb 14, 2024 at 12:49 PM Dan Horák  wrote:
> > >
> > > On Wed, 14 Feb 2024 10:42:52 +
> > > "Richard W.M. Jones"  wrote:
> > >
> > > > On Wed, Feb 14, 2024 at 10:27:53AM +, Peter Robinson wrote:
> > > > > Hi Richard,
> > > > >
> > > > > > A quick note that you may be seeing pull requests for riscv64 
> > > > > > changes
> > > > > > against your packages, like these examples:
> > > > > >
> > > > > > https://src.fedoraproject.org/rpms/ghc/pull-request/7
> > > > > > https://src.fedoraproject.org/rpms/zlib-ng/pull-request/11
> > > > > > https://src.fedoraproject.org/rpms/gdal/pull-request/21
> > > > > >
> > > > > > For many years we have been building Fedora for the RISC-V
> > > > > > architecture on a separate build system at
> > > > > > http://fedora.riscv.rocks/koji/ , and maintaining downstream patches
> > > > > > against dist-git in http://fedora.riscv.rocks:3000/rpms/
> > > > > > (Most of this work was done by David Abdurachmanov, not me.)
> > > > >
> > > > > I'm very happy to see these start to land, let me know if you need any
> > > > > assistance.
> > > > >
> > > > > > I'm trying to get as much of this stuff back into Fedora dist-git,
> > > > > > although only (hopefully!) where it doesn't break ordinary builds 
> > > > > > and
> > > > > > isn't intrusive.  Obviously I may get this wrong sometimes so feel
> > > > > > free to make comments if you disagree with changes.
> > > > > >
> > > > > > Some time, with any luck soon, we will be creating a new Koji 
> > > > > > instance
> > > > > > with FAS authentication which will allow anyone to optionally build
> > > > > > their packages on RISC-V builders.  And then later in the year we 
> > > > > > may
> > > > > > be in a position with the availability of new hardware to discuss
> > > > > > adding RISC-V as a regular architecture.  (We're not there yet as
> > > > > > current hardware is far too slow to force it on Fedora developers.)
> > > > >
> > > > > Will this instance run with koji-shadow to properly mirror the builds
> > > > > with all the appropriate NVR dependencies to properly mirror Fedora
> > > > > primary builds?
> > > >
> > > > TBD.
> > > >
> > > > Koji-shadow specifically is unmaintained.  Maybe we'll try to hack
> > > > something together with scripts, or get koji-shadow working.
> > >
> > > on the other hand, it's still tags, targets, buildroots in koji ...
> > >
> > > I should be able dig out some koji-shadow know-how out of my memory if
> > > needed. Those were wonderful years :-)
> >
> > Many years ago I tried using koji-shadow, but I didn't like what it
> > was doing. Cooking something custom seemed easier at that point. These
> 
> Yes, it was never a particularly nice process, but the advantage it
> has was it made sure that a package build used the exact same packages
> as on the mainline build so you could end up with identical builds and
> that was very useful for bugs and build process problems.

and with that technique it solves the soname bumps and the use of side
tags very effectively, I would consider this the main benefit of
koji-shadow


Dan
 
> > days we also have side tags, and thus some bootstrap operations happen
> > there. Sadly those get removed relatively soonish after the tag gets
> > merged. Sometimes before I get a chance to grab it. Otherwise I have a
> > good picture of Fedora package land over so many years.
> >
> > Our "dist-git overlay" is relatively small these days. Should be <300
> > packages, and majority of it was used to bump NVR for rebuilds.
> >
> > Cheers,
> > david
> >
> > >
> > > Dan
> > > --
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct: 
> > > https://docs.fedoraproject.org/en-US/project/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, report it: 
> > > https://pagure.io/fedora-infrastructure/new_issue
> > --
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/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, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 

Re: A note about riscv64 changes

[Stephen Gallagher]

On Wed, Feb 14, 2024 at 7:30 AM Peter Robinson  wrote:
>
> On Wed, 14 Feb 2024 at 12:07, David Abdurachmanov
>  wrote:
> >
> > On Wed, Feb 14, 2024 at 12:49 PM Dan Horák  wrote:
> > >
> > > On Wed, 14 Feb 2024 10:42:52 +
> > > "Richard W.M. Jones"  wrote:
> > >
> > > > On Wed, Feb 14, 2024 at 10:27:53AM +, Peter Robinson wrote:
> > > > > Hi Richard,
> > > > >
> > > > > > A quick note that you may be seeing pull requests for riscv64 
> > > > > > changes
> > > > > > against your packages, like these examples:
> > > > > >
> > > > > > https://src.fedoraproject.org/rpms/ghc/pull-request/7
> > > > > > https://src.fedoraproject.org/rpms/zlib-ng/pull-request/11
> > > > > > https://src.fedoraproject.org/rpms/gdal/pull-request/21
> > > > > >
> > > > > > For many years we have been building Fedora for the RISC-V
> > > > > > architecture on a separate build system at
> > > > > > http://fedora.riscv.rocks/koji/ , and maintaining downstream patches
> > > > > > against dist-git in http://fedora.riscv.rocks:3000/rpms/
> > > > > > (Most of this work was done by David Abdurachmanov, not me.)
> > > > >
> > > > > I'm very happy to see these start to land, let me know if you need any
> > > > > assistance.
> > > > >
> > > > > > I'm trying to get as much of this stuff back into Fedora dist-git,
> > > > > > although only (hopefully!) where it doesn't break ordinary builds 
> > > > > > and
> > > > > > isn't intrusive.  Obviously I may get this wrong sometimes so feel
> > > > > > free to make comments if you disagree with changes.
> > > > > >
> > > > > > Some time, with any luck soon, we will be creating a new Koji 
> > > > > > instance
> > > > > > with FAS authentication which will allow anyone to optionally build
> > > > > > their packages on RISC-V builders.  And then later in the year we 
> > > > > > may
> > > > > > be in a position with the availability of new hardware to discuss
> > > > > > adding RISC-V as a regular architecture.  (We're not there yet as
> > > > > > current hardware is far too slow to force it on Fedora developers.)
> > > > >
> > > > > Will this instance run with koji-shadow to properly mirror the builds
> > > > > with all the appropriate NVR dependencies to properly mirror Fedora
> > > > > primary builds?
> > > >
> > > > TBD.
> > > >
> > > > Koji-shadow specifically is unmaintained.  Maybe we'll try to hack
> > > > something together with scripts, or get koji-shadow working.
> > >
> > > on the other hand, it's still tags, targets, buildroots in koji ...
> > >
> > > I should be able dig out some koji-shadow know-how out of my memory if
> > > needed. Those were wonderful years :-)
> >
> > Many years ago I tried using koji-shadow, but I didn't like what it
> > was doing. Cooking something custom seemed easier at that point. These
>


One tool to look into could be the one we use for automatically
rebuilding Rawhide packages for Fedora ELN:
https://gitlab.com/redhat/centos-stream/ci-cd/distrosync/distrobuildsync

I'd be happy to work with you to extend it for RISC use (though
probably not sooner than March, as we've got kind of a lot going on
with the CentOS Stream 10 fork from ELN this week and next).
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: A note about riscv64 changes

[Peter Robinson]

On Wed, 14 Feb 2024 at 12:07, David Abdurachmanov
 wrote:
>
> On Wed, Feb 14, 2024 at 12:49 PM Dan Horák  wrote:
> >
> > On Wed, 14 Feb 2024 10:42:52 +
> > "Richard W.M. Jones"  wrote:
> >
> > > On Wed, Feb 14, 2024 at 10:27:53AM +, Peter Robinson wrote:
> > > > Hi Richard,
> > > >
> > > > > A quick note that you may be seeing pull requests for riscv64 changes
> > > > > against your packages, like these examples:
> > > > >
> > > > > https://src.fedoraproject.org/rpms/ghc/pull-request/7
> > > > > https://src.fedoraproject.org/rpms/zlib-ng/pull-request/11
> > > > > https://src.fedoraproject.org/rpms/gdal/pull-request/21
> > > > >
> > > > > For many years we have been building Fedora for the RISC-V
> > > > > architecture on a separate build system at
> > > > > http://fedora.riscv.rocks/koji/ , and maintaining downstream patches
> > > > > against dist-git in http://fedora.riscv.rocks:3000/rpms/
> > > > > (Most of this work was done by David Abdurachmanov, not me.)
> > > >
> > > > I'm very happy to see these start to land, let me know if you need any
> > > > assistance.
> > > >
> > > > > I'm trying to get as much of this stuff back into Fedora dist-git,
> > > > > although only (hopefully!) where it doesn't break ordinary builds and
> > > > > isn't intrusive.  Obviously I may get this wrong sometimes so feel
> > > > > free to make comments if you disagree with changes.
> > > > >
> > > > > Some time, with any luck soon, we will be creating a new Koji instance
> > > > > with FAS authentication which will allow anyone to optionally build
> > > > > their packages on RISC-V builders.  And then later in the year we may
> > > > > be in a position with the availability of new hardware to discuss
> > > > > adding RISC-V as a regular architecture.  (We're not there yet as
> > > > > current hardware is far too slow to force it on Fedora developers.)
> > > >
> > > > Will this instance run with koji-shadow to properly mirror the builds
> > > > with all the appropriate NVR dependencies to properly mirror Fedora
> > > > primary builds?
> > >
> > > TBD.
> > >
> > > Koji-shadow specifically is unmaintained.  Maybe we'll try to hack
> > > something together with scripts, or get koji-shadow working.
> >
> > on the other hand, it's still tags, targets, buildroots in koji ...
> >
> > I should be able dig out some koji-shadow know-how out of my memory if
> > needed. Those were wonderful years :-)
>
> Many years ago I tried using koji-shadow, but I didn't like what it
> was doing. Cooking something custom seemed easier at that point. These

Yes, it was never a particularly nice process, but the advantage it
has was it made sure that a package build used the exact same packages
as on the mainline build so you could end up with identical builds and
that was very useful for bugs and build process problems.

> days we also have side tags, and thus some bootstrap operations happen
> there. Sadly those get removed relatively soonish after the tag gets
> merged. Sometimes before I get a chance to grab it. Otherwise I have a
> good picture of Fedora package land over so many years.
>
> Our "dist-git overlay" is relatively small these days. Should be <300
> packages, and majority of it was used to bump NVR for rebuilds.
>
> Cheers,
> david
>
> >
> > Dan
> > --
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/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, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: A note about riscv64 changes

[David Abdurachmanov]

On Wed, Feb 14, 2024 at 12:49 PM Dan Horák  wrote:
>
> On Wed, 14 Feb 2024 10:42:52 +
> "Richard W.M. Jones"  wrote:
>
> > On Wed, Feb 14, 2024 at 10:27:53AM +, Peter Robinson wrote:
> > > Hi Richard,
> > >
> > > > A quick note that you may be seeing pull requests for riscv64 changes
> > > > against your packages, like these examples:
> > > >
> > > > https://src.fedoraproject.org/rpms/ghc/pull-request/7
> > > > https://src.fedoraproject.org/rpms/zlib-ng/pull-request/11
> > > > https://src.fedoraproject.org/rpms/gdal/pull-request/21
> > > >
> > > > For many years we have been building Fedora for the RISC-V
> > > > architecture on a separate build system at
> > > > http://fedora.riscv.rocks/koji/ , and maintaining downstream patches
> > > > against dist-git in http://fedora.riscv.rocks:3000/rpms/
> > > > (Most of this work was done by David Abdurachmanov, not me.)
> > >
> > > I'm very happy to see these start to land, let me know if you need any
> > > assistance.
> > >
> > > > I'm trying to get as much of this stuff back into Fedora dist-git,
> > > > although only (hopefully!) where it doesn't break ordinary builds and
> > > > isn't intrusive.  Obviously I may get this wrong sometimes so feel
> > > > free to make comments if you disagree with changes.
> > > >
> > > > Some time, with any luck soon, we will be creating a new Koji instance
> > > > with FAS authentication which will allow anyone to optionally build
> > > > their packages on RISC-V builders.  And then later in the year we may
> > > > be in a position with the availability of new hardware to discuss
> > > > adding RISC-V as a regular architecture.  (We're not there yet as
> > > > current hardware is far too slow to force it on Fedora developers.)
> > >
> > > Will this instance run with koji-shadow to properly mirror the builds
> > > with all the appropriate NVR dependencies to properly mirror Fedora
> > > primary builds?
> >
> > TBD.
> >
> > Koji-shadow specifically is unmaintained.  Maybe we'll try to hack
> > something together with scripts, or get koji-shadow working.
>
> on the other hand, it's still tags, targets, buildroots in koji ...
>
> I should be able dig out some koji-shadow know-how out of my memory if
> needed. Those were wonderful years :-)

Many years ago I tried using koji-shadow, but I didn't like what it
was doing. Cooking something custom seemed easier at that point. These
days we also have side tags, and thus some bootstrap operations happen
there. Sadly those get removed relatively soonish after the tag gets
merged. Sometimes before I get a chance to grab it. Otherwise I have a
good picture of Fedora package land over so many years.

Our "dist-git overlay" is relatively small these days. Should be <300
packages, and majority of it was used to bump NVR for rebuilds.

Cheers,
david

>
> Dan
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: dnf-4.19.0 without filelists in Rawhide soon

[Jan Kolarik]

Yep, this is a topic for potential improvement. Currently, there's a simple
file path detection, like "arg[0] == '/' || (arg[0] == '*' && arg[1] ==
'/')", and filelists are always additionally downloaded in such cases. The
situation aligns with dnf5 at the moment, and there's already a tracking
issue for this: https://bugzilla.redhat.com/show_bug.cgi?id=2263771.

Jan

On Wed, Feb 14, 2024 at 12:09 PM Vít Ondruch  wrote:

> /usr/bin/BINARYNAME is part of the primary metadata AFAIK
>
>
> Vít
>
>
> Dne 14. 02. 24 v 10:49 Jan Kolarik napsal(a):
>
> Hi Marcin,
>
> > So no more "dnf install /usr/bin/BINARYNAME" in default setup?
>
> In the case where a file path argument is provided to dnf, it will
> automatically attempt to download the missing filelists metadata. Sorry, I
> forgot to explicitly mention this use case.
>
> Jan
>
> On Wed, Feb 14, 2024 at 10:42 AM Marcin Juszkiewicz <
> mjuszkiew...@redhat.com> wrote:
>
>> W dniu 9.02.2024 o 14:02, Jan Kolarik pisze:
>> > Just a heads up that a new DNF version (4.19.0) is on its way to
>> Rawhide
>> > and is expected to land within the next several hours. This update
>> > brings a system-wide change
>> > 
>> related
>> > to not downloading filelists metadata by default.
>>
>> So no more "dnf install /usr/bin/BINARYNAME" in default setup?
>> --
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/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, report it:
>> https://pagure.io/fedora-infrastructure/new_issue
>>
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: dnf-4.19.0 without filelists in Rawhide soon

[Vít Ondruch]

/usr/bin/BINARYNAME is part of the primary metadata AFAIK


Vít


Dne 14. 02. 24 v 10:49 Jan Kolarik napsal(a):

Hi Marcin,

> So no more "dnf install /usr/bin/BINARYNAME" in default setup?

In the case where a file path argument is provided to dnf, it will 
automatically attempt to download the missing filelists metadata. 
Sorry, I forgot to explicitly mention this use case.


Jan

On Wed, Feb 14, 2024 at 10:42 AM Marcin Juszkiewicz 
 wrote:


W dniu 9.02.2024 o 14:02, Jan Kolarik pisze:
> Just a heads up that a new DNF version (4.19.0) is on its way to
Rawhide
> and is expected to land within the next several hours. This update
> brings a system-wide change
> 
related
> to not downloading filelists metadata by default.

So no more "dnf install /usr/bin/BINARYNAME" in default setup?
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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, report it:
https://pagure.io/fedora-infrastructure/new_issue


--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/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, report 
it:https://pagure.io/fedora-infrastructure/new_issue


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

Re: do we need CONFIG_UPROBES=y in our kernels?

[Clemens Lang]

Hi,

> On 12. Feb 2024, at 19:15, Marius Schwarz  wrote:
> 
> In a german developer blog article was the topic raised, that with uprobes 
> enabled, userland apps can i.e. circumvent tls security(and other 
> protections),
> by telling the kernel to probe the function calls with the uprobes api. As 
> this enables i.e. the hosting system of a vm or container, to track activity 
> inside the container, trust is lost i.e. from customer to hoster. To be fair, 
> you need to be root on the host to do this, but as it "wasn't possible 
> before", and it is "now" ( out in a greater public ), it tends to create 
> trust issues, just for being there*.

How was this not possible before? If I’m root on the host, I could always start 
a gdb and attach it to a process running in a container. I could also always 
have replaced a file in the container (e.g., the libssl.so library with an 
instrumented one that just writes the TLS communication in clear text into a 
pipe). On a kernel with /dev/mem, the host could probably have located the 
encryption keys directly in memory, too.

It really sounds to me like the incorrect assumption here is that the host was 
not already able to do these things.

If you don’t trust your host, look into confidential computing and confidential 
containers. Those also don’t solve every single problem, but they get you 
closer.


-- 
Clemens Lang
RHEL Crypto Team
Red Hat


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

Re: A note about riscv64 changes

[Dan Horák]

On Wed, 14 Feb 2024 10:42:52 +
"Richard W.M. Jones"  wrote:

> On Wed, Feb 14, 2024 at 10:27:53AM +, Peter Robinson wrote:
> > Hi Richard,
> > 
> > > A quick note that you may be seeing pull requests for riscv64 changes
> > > against your packages, like these examples:
> > >
> > > https://src.fedoraproject.org/rpms/ghc/pull-request/7
> > > https://src.fedoraproject.org/rpms/zlib-ng/pull-request/11
> > > https://src.fedoraproject.org/rpms/gdal/pull-request/21
> > >
> > > For many years we have been building Fedora for the RISC-V
> > > architecture on a separate build system at
> > > http://fedora.riscv.rocks/koji/ , and maintaining downstream patches
> > > against dist-git in http://fedora.riscv.rocks:3000/rpms/
> > > (Most of this work was done by David Abdurachmanov, not me.)
> > 
> > I'm very happy to see these start to land, let me know if you need any
> > assistance.
> > 
> > > I'm trying to get as much of this stuff back into Fedora dist-git,
> > > although only (hopefully!) where it doesn't break ordinary builds and
> > > isn't intrusive.  Obviously I may get this wrong sometimes so feel
> > > free to make comments if you disagree with changes.
> > >
> > > Some time, with any luck soon, we will be creating a new Koji instance
> > > with FAS authentication which will allow anyone to optionally build
> > > their packages on RISC-V builders.  And then later in the year we may
> > > be in a position with the availability of new hardware to discuss
> > > adding RISC-V as a regular architecture.  (We're not there yet as
> > > current hardware is far too slow to force it on Fedora developers.)
> > 
> > Will this instance run with koji-shadow to properly mirror the builds
> > with all the appropriate NVR dependencies to properly mirror Fedora
> > primary builds?
> 
> TBD.
> 
> Koji-shadow specifically is unmaintained.  Maybe we'll try to hack
> something together with scripts, or get koji-shadow working.

on the other hand, it's still tags, targets, buildroots in koji ...

I should be able dig out some koji-shadow know-how out of my memory if
needed. Those were wonderful years :-)


Dan
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: A note about riscv64 changes

[Richard W.M. Jones]

On Wed, Feb 14, 2024 at 10:27:53AM +, Peter Robinson wrote:
> Hi Richard,
> 
> > A quick note that you may be seeing pull requests for riscv64 changes
> > against your packages, like these examples:
> >
> > https://src.fedoraproject.org/rpms/ghc/pull-request/7
> > https://src.fedoraproject.org/rpms/zlib-ng/pull-request/11
> > https://src.fedoraproject.org/rpms/gdal/pull-request/21
> >
> > For many years we have been building Fedora for the RISC-V
> > architecture on a separate build system at
> > http://fedora.riscv.rocks/koji/ , and maintaining downstream patches
> > against dist-git in http://fedora.riscv.rocks:3000/rpms/
> > (Most of this work was done by David Abdurachmanov, not me.)
> 
> I'm very happy to see these start to land, let me know if you need any
> assistance.
> 
> > I'm trying to get as much of this stuff back into Fedora dist-git,
> > although only (hopefully!) where it doesn't break ordinary builds and
> > isn't intrusive.  Obviously I may get this wrong sometimes so feel
> > free to make comments if you disagree with changes.
> >
> > Some time, with any luck soon, we will be creating a new Koji instance
> > with FAS authentication which will allow anyone to optionally build
> > their packages on RISC-V builders.  And then later in the year we may
> > be in a position with the availability of new hardware to discuss
> > adding RISC-V as a regular architecture.  (We're not there yet as
> > current hardware is far too slow to force it on Fedora developers.)
> 
> Will this instance run with koji-shadow to properly mirror the builds
> with all the appropriate NVR dependencies to properly mirror Fedora
> primary builds?

TBD.

Koji-shadow specifically is unmaintained.  Maybe we'll try to hack
something together with scripts, or get koji-shadow working.

At the moment David rebuilds packages from regular Koji in
fedora.riscv.rocks by hand, I think, or at least using some scripts
that he has devised.

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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: A note about riscv64 changes

[Peter Robinson]

Hi Richard,

> A quick note that you may be seeing pull requests for riscv64 changes
> against your packages, like these examples:
>
> https://src.fedoraproject.org/rpms/ghc/pull-request/7
> https://src.fedoraproject.org/rpms/zlib-ng/pull-request/11
> https://src.fedoraproject.org/rpms/gdal/pull-request/21
>
> For many years we have been building Fedora for the RISC-V
> architecture on a separate build system at
> http://fedora.riscv.rocks/koji/ , and maintaining downstream patches
> against dist-git in http://fedora.riscv.rocks:3000/rpms/
> (Most of this work was done by David Abdurachmanov, not me.)

I'm very happy to see these start to land, let me know if you need any
assistance.

> I'm trying to get as much of this stuff back into Fedora dist-git,
> although only (hopefully!) where it doesn't break ordinary builds and
> isn't intrusive.  Obviously I may get this wrong sometimes so feel
> free to make comments if you disagree with changes.
>
> Some time, with any luck soon, we will be creating a new Koji instance
> with FAS authentication which will allow anyone to optionally build
> their packages on RISC-V builders.  And then later in the year we may
> be in a position with the availability of new hardware to discuss
> adding RISC-V as a regular architecture.  (We're not there yet as
> current hardware is far too slow to force it on Fedora developers.)

Will this instance run with koji-shadow to properly mirror the builds
with all the appropriate NVR dependencies to properly mirror Fedora
primary builds?

Peter
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

A note about riscv64 changes

[Richard W.M. Jones]

A quick note that you may be seeing pull requests for riscv64 changes
against your packages, like these examples:

https://src.fedoraproject.org/rpms/ghc/pull-request/7
https://src.fedoraproject.org/rpms/zlib-ng/pull-request/11
https://src.fedoraproject.org/rpms/gdal/pull-request/21

For many years we have been building Fedora for the RISC-V
architecture on a separate build system at
http://fedora.riscv.rocks/koji/ , and maintaining downstream patches
against dist-git in http://fedora.riscv.rocks:3000/rpms/
(Most of this work was done by David Abdurachmanov, not me.)

I'm trying to get as much of this stuff back into Fedora dist-git,
although only (hopefully!) where it doesn't break ordinary builds and
isn't intrusive.  Obviously I may get this wrong sometimes so feel
free to make comments if you disagree with changes.

Some time, with any luck soon, we will be creating a new Koji instance
with FAS authentication which will allow anyone to optionally build
their packages on RISC-V builders.  And then later in the year we may
be in a position with the availability of new hardware to discuss
adding RISC-V as a regular architecture.  (We're not there yet as
current hardware is far too slow to force it on Fedora developers.)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Unresponsive maintainer: petersen / Pandoc package not updated since June 2023: Security vulnerability, CVE-2023-35936 (medium)

[Richard W.M. Jones]

Re: pandoc, we managed to build it on RISC-V thanks to the changes you
merged in ghc:

  $ uname -a
  Linux vf2.home.annexia.org 5.15.0-starfive #1 SMP Sun Jun 11 07:48:39 UTC 
2023 riscv64 GNU/Linux
  $ rpm -q pandoc
  pandoc-3.1.3-27.fc41.riscv64
  $ pandoc --version
  pandoc 3.1.3
  Features: -server +lua
  Scripting engine: Lua 5.4
  User data directory: /home/rjones/.local/share/pandoc
  Copyright (C) 2006-2023 John MacFarlane. Web: https://pandoc.org
  This is free software; see the source for copying conditions. There is no
  warranty, not even for merchantability or fitness for a particular purpose.

Is it possible you could bump and rebuild the ghc package in Rawhide?
That will allow us to rebuild our downstream ghc package
(http://fedora.riscv.rocks/koji/buildinfo?buildID=281302) without the
'.0.riscv64' extension.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: dnf-4.19.0 without filelists in Rawhide soon

[Jan Kolarik]

Hi Marcin,

> So no more "dnf install /usr/bin/BINARYNAME" in default setup?

In the case where a file path argument is provided to dnf, it will
automatically attempt to download the missing filelists metadata. Sorry, I
forgot to explicitly mention this use case.

Jan

On Wed, Feb 14, 2024 at 10:42 AM Marcin Juszkiewicz 
wrote:

> W dniu 9.02.2024 o 14:02, Jan Kolarik pisze:
> > Just a heads up that a new DNF version (4.19.0) is on its way to Rawhide
> > and is expected to land within the next several hours. This update
> > brings a system-wide change
> > 
> related
> > to not downloading filelists metadata by default.
>
> So no more "dnf install /usr/bin/BINARYNAME" in default setup?
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/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, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: dnf-4.19.0 without filelists in Rawhide soon

[Marcin Juszkiewicz]

W dniu 9.02.2024 o 14:02, Jan Kolarik pisze:
Just a heads up that a new DNF version (4.19.0) is on its way to Rawhide 
and is expected to land within the next several hours. This update 
brings a system-wide change 
 related 
to not downloading filelists metadata by default.


So no more "dnf install /usr/bin/BINARYNAME" in default setup?
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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, report it: 
https://pagure.io/fedora-infrastructure/new_issue