Re: opensubdiv: strange failure on doc subpackage

On 2023-01-02 16:44, Todd Zullinger wrote: Hi, Luya Tshimbalanga wrote: Hello team, While building opensubdiv, the failure[1] occurred on doc subpackage with the following line: BuildError: The following noarch package built differently on different architectures: opensubdiv-doc-3.5.0-1.fc3

Orphaning dlib

Hello team, I am orphaning dlib as I no longer need it for dependencies like howdly (Windows Hello type authentication app) and I no longer have a 2018 HP Envy 2-in-1 device for testing. The package is well maintained and  up to date with upstream. Feel free to take it. Reference: https://sr

Re: Orphaned packages looking for new maintainers

On Mon, Jan 2, 2023 at 7:21 PM Dale Turner via devel wrote: > > As I mentioned last week, I would be interested in xaos. BUT, I am not > presently a packager/maintainer... Hi Dale, Unfortunately there's nothing that can be done (except perhaps delaying the retirement of xaos) until you become a

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

Dne 02. 01. 23 v 22:39 Otto Liljalaakso napsal(a): Also, 'mock --buildsrpm' will not convert them. Perhaps Vitaly meant mock should support such usage? Mock cannot add such support, because Mock rarely operate on top of dist-git (or even git). So there is no way how to retrieve git log. Miro

Re: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)

On Mon, Jan 2, 2023 at 10:52 PM Demi Marie Obenour wrote: > > On 1/2/23 22:30, Kevin Kofler via devel wrote: > > Fabio Valentini wrote: > >> - incompatible compile-time options (i.e. resulting in conditional > >> compilation): different packages depend on crates with different sets > >> of feature

Re: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)

On 1/2/23 22:30, Kevin Kofler via devel wrote: > Fabio Valentini wrote: >> - incompatible compile-time options (i.e. resulting in conditional >> compilation): different packages depend on crates with different sets >> of features enabled, sometimes with conflicting options. Even with a >> stable AB

Re: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)

Fabio Valentini wrote: > - incompatible compile-time options (i.e. resulting in conditional > compilation): different packages depend on crates with different sets > of features enabled, sometimes with conflicting options. Even with a > stable ABI, you'd need to build crates for all necessary combi

Re: Orphaned packages looking for new maintainers

On Mon Jan 2, 2023 at 11:46 -0600, Robby Callicotte via devel wrote: > I went ahead and took vim-nerdtree. FYI: Nerdtree is unmaintained upstream: https://github.com/preservim/nerdtree/issues/1280 -- Maxwell G (@gotmax23) Pronouns: He/Him/His ___ devel

Re: opensubdiv: strange failure on doc subpackage

Hi, Luya Tshimbalanga wrote: > Hello team, > > While building opensubdiv, the failure[1] occurred on doc subpackage with > the following line: > > BuildError: The following noarch package built differently on different > architectures: opensubdiv-doc-3.5.0-1.fc38.noarch.rpm > rpmdiff output was

Re: Orphaned packages looking for new maintainers

On Mon, 2023-01-02 at 17:02 +0100, Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproj

Re: HEADS UP: icu 72 coming to rawhide

On Sat, Dec 31, 2022 at 2:30 PM Pete Walter wrote: > This is now done. The following 4 packages failed to rebuild. The rest of > 102 packages built fine and are all rebuilt in rawhide. > > mozjs78: https://koji.fedoraproject.org/koji/taskinfo?taskID=95691022 > mozjs91: https://koji.fedoraproject.

opensubdiv: strange failure on doc subpackage

Hello team, While building opensubdiv, the failure[1] occurred on doc subpackage with the following line: BuildError: The following noarch package built differently on different architectures: opensubdiv-doc-3.5.0-1.fc38.noarch.rpm rpmdiff output was: added /usr/share/doc/opensubdiv/dox

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Mon, Jan 2, 2023 at 4:40 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Jan 02, 2023 at 05:59:07PM +0100, mkol...@redhat.com wrote: > > On Mon, 2023-01-02 at 15:42 +0100, Gerd Hoffmann wrote: > > > On Thu, Dec 22, 2022 at 04:53:47PM +0100, Jiri Konecny wrote: > > > > Hi all, > > > > > > > >

Re: UEFI HTTP boot (was: Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal))

On Monday, 02 January 2023 at 17:25, Gerd Hoffmann wrote: > On Mon, Jan 02, 2023 at 04:06:29PM +0100, Dominik 'Rathann' Mierzejewski > wrote: > > On Monday, 02 January 2023 at 15:42, Gerd Hoffmann wrote: > > [...] > > > Note that uefi http boot can also work with iso images, i.e. you can > > > hav

Re: Orphaned packages looking for new maintainers

On Mon, Jan 02, 2023 at 05:02:41PM +0100, Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fed

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

Zbigniew Jędrzejewski-Szmek kirjoitti 2.1.2023 klo 22.44: On Sun, Jan 01, 2023 at 03:10:22PM +0100, Florian Weimer wrote: * Vitaly Zaitsev via devel: On 30/12/2022 20:01, Ben Cotton wrote: This document represents a proposed Change. As part of the Changes process, proposals are publicly annou

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Mon, Jan 02, 2023 at 05:59:07PM +0100, mkol...@redhat.com wrote: > On Mon, 2023-01-02 at 15:42 +0100, Gerd Hoffmann wrote: > > On Thu, Dec 22, 2022 at 04:53:47PM +0100, Jiri Konecny wrote: > > > Hi all, > > > > > > > == Benefit to Fedora == > > > > * Better secure boot support (specifically the

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

Dne 02. 01. 23 v 22:01 Richard Shaw napsal(a): Also mock builds seem fine. I tested this now on F37 with a few different scenarios: - fedpkg mockbuild - git commit --allow-empty -m Rebuild && fedpkg mockbuild - fedpkg srpm && mock *.src.rpm seem to generate the expected vers

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Mon, Jan 02, 2023 at 03:01:16PM -0600, Richard Shaw wrote: > On Mon, Jan 2, 2023 at 2:44 PM Zbigniew Jędrzejewski-Szmek < > zbys...@in.waw.pl> wrote: > > > On Sun, Jan 01, 2023 at 03:10:22PM +0100, Florian Weimer wrote: > > > * Vitaly Zaitsev via devel: > > > > > > > On 30/12/2022 20:01, Ben Co

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Sun, Jan 01, 2023 at 12:06:51PM -0500, Neal Gompa wrote: > On Sat, Dec 31, 2022 at 11:44 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Sat, Dec 31, 2022 at 11:23:35AM -0500, Neal Gompa wrote: > > > On Sat, Dec 31, 2022 at 11:17 AM Miro Hrončok wrote: > > > > > > > > On 31. 12. 22 15:07, J

Re: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)

On Mon, Jan 02, 2023 at 01:06:52PM +0100, Kevin Kofler via devel wrote: > Matthew Miller wrote: > > Okay. no. This is not how we do things here. > Apologies for my snide remark that visibly came out rude, sorry. Thank you, Kevin. -- Matthew Miller Fedora Project Leader

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Mon, Jan 2, 2023 at 2:44 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Sun, Jan 01, 2023 at 03:10:22PM +0100, Florian Weimer wrote: > > * Vitaly Zaitsev via devel: > > > > > On 30/12/2022 20:01, Ben Cotton wrote: > > >> This document represents a proposed Change. As part of th

Re: Rpmautospec howto do a rebuild for something

On 2023-01-02 04:52, Maxwell G via devel wrote: On Mon Jan 2, 2023 at 12:32 +, Sérgio Basto wrote: I need rebuild a package that is using rpmautospec , how I can rebuild the package and increase relversion ? `git commit --allow-empty -m "Changelog entry here"` will do what you want. The em

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Sun, Jan 01, 2023 at 03:10:22PM +0100, Florian Weimer wrote: > * Vitaly Zaitsev via devel: > > > On 30/12/2022 20:01, Ben Cotton wrote: > >> This document represents a proposed Change. As part of the Changes > >> process, proposals are publicly announced in order to receive > >> community feedb

Copr - look back at 2022

Let me sum up what the Copr team did during 2022. The review of 2021 can be found at https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/R2MWYN7CRF34WKSRUUYNLAISQB47MHXI/

Re: Orphaned packages looking for new maintainers

Hello. As I mentioned last week, I would be interested in xaos. BUT, I am not presently a packager/maintainer... Dale Sent with Proton Mail secure email. --- Original Message --- On Monday, January 2nd, 2023 at 12:02 PM, Miro Hrončok wrote: > The following packages are orphaned

Re: Orphaned packages looking for new maintainers

On Monday, January 2, 2023 10:02:41 AM CST Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for > sure that the package should be retired, please do so now with a proper > reason: > https:/

Re: Linking problem with ncurses on rawhide, not f37

* Miroslav Lichvar: > On Fri, Dec 16, 2022 at 09:55:11AM +0100, Florian Weimer wrote: >> It may work to use this for libtinfo.so: >> >> GROUP (/usr/lib64/ncurses-novs/libtinfo.so.6 AS_NEEDED >> (/usr/lib64/ncurses-novs/libncurses.so.6)) > > FWIW, I tried this and the error messages from the swif

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Mon, 2023-01-02 at 15:42 +0100, Gerd Hoffmann wrote: > On Thu, Dec 22, 2022 at 04:53:47PM +0100, Jiri Konecny wrote: > > Hi all, > > > > > == Benefit to Fedora == > > > * Better secure boot support (specifically the initrd is covered > > > by > > > the signature). > > > * Better confidential co

Re: Linking problem with ncurses on rawhide, not f37

On Fri, Dec 16, 2022 at 09:55:11AM +0100, Florian Weimer wrote: > It may work to use this for libtinfo.so: > > GROUP (/usr/lib64/ncurses-novs/libtinfo.so.6 AS_NEEDED > (/usr/lib64/ncurses-novs/libncurses.so.6)) FWIW, I tried this and the error messages from the swift-lang build changed from: /u

Re: UEFI HTTP boot (was: Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal))

On Mon, Jan 02, 2023 at 04:06:29PM +0100, Dominik 'Rathann' Mierzejewski wrote: > On Monday, 02 January 2023 at 15:42, Gerd Hoffmann wrote: > [...] > > Note that uefi http boot can also work with iso images, i.e. you can > > have the dhcp server hand out URLs to the fedora netboot iso. The > > fir

Orphaned packages looking for new maintainers

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

UEFI HTTP boot (was: Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal))

On Monday, 02 January 2023 at 15:42, Gerd Hoffmann wrote: [...] > Note that uefi http boot can also work with iso images, i.e. you can > have the dhcp server hand out URLs to the fedora netboot iso. The > firmware will fetch the iso, create a ramdisk, add a acpi table for > it so the OS finds it t

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Thu, Dec 22, 2022 at 04:53:47PM +0100, Jiri Konecny wrote: > Hi all, > > > == Benefit to Fedora == > > * Better secure boot support (specifically the initrd is covered by > > the signature). > > * Better confidential computing support (measurements are much more > > useful if we know what hashe

Re: Is there convenient way to setup Fedora compilation flags outside of the RPM build?

Florian Weimer writes: After installing redhat-rpm-config, this works in bash and similar shells: $ eval `rpm --eval %set_build_flags` Maybe we can make it more clear in buildflags.md that this macro is a shell script fragment? I find it more convenient to generate parameters for an autoconf

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

On Fri, Dec 23, 2022 at 09:01:52AM +0100, Vitaly Zaitsev via devel wrote: > I doubt that Fedora's shim+grub2 can boot Ubuntu kernels in Secure Boot mode > and vice versa. Needs installing the signing keys to the shim key database using mokutil, but should otherwise work just fine. take care, G

Re: F38 proposal: Unified Kernel Support Phase 1 (System-Wide Change proposal)

Hi, > A much better approach is to install a TPM-generated key in the TPM’s > NVRAM, with a policy that only allows the key to be used once a trusted > operating system has booted. That can be used as a trust anchor even > without support from buggy UEFI firmware. Side note: measuring kernel +

Re: Is there convenient way to setup Fedora compilation flags outside of the RPM build?

Dne 02. 01. 23 v 14:09 Florian Weimer napsal(a): * Vít Ondruch: And yes, that is the problem why upstream can't see the issues we see, despite they were so kind to test on Fedora. Luckily, there was analysis of the issue which initially triggered this discussion done by Mamoru [1] and it seem

Disabling Fedora 35 chroots in Copr

Hello, we have just disabled Fedora 35 chroots in Copr. According to the Fedora wiki [1], Fedora 35 reached the end of its life on 2022-12-13 and therefore we are disabling it in Copr. That effectively means that from this moment, it is no longer possible to submit builds for the following chroo

Re: Is there convenient way to setup Fedora compilation flags outside of the RPM build?

* Vít Ondruch: > And yes, that is the problem why upstream can't see the issues we see, > despite they were so kind to test on Fedora. Luckily, there was > analysis of the issue which initially triggered this discussion done > by Mamoru [1] and it seem that the issue are caused by > LTO. Neverthel

Re: Rpmautospec howto do a rebuild for something

On Mon Jan 2, 2023 at 12:32 +, Sérgio Basto wrote: > I need rebuild a package that is using rpmautospec , how I can rebuild > the package and increase relversion ? `git commit --allow-empty -m "Changelog entry here"` will do what you want. The empty commit will result in a release and changelo

Re: Rpmautospec howto do a rebuild for something

Hi Sérgio, Hau idatzi du Sérgio Basto (ser...@serjux.com) erabiltzaileak (2023 urt. 2, al. (13:40)): > > I need rebuild a package that is using rpmautospec , how I can rebuild > the package and increase relversion ? git commit --allow-empty -m "Rebuild because of X" __

Rpmautospec howto do a rebuild for something

Hi, I need rebuild a package that is using rpmautospec , how I can rebuild the package and increase relversion ? Thank you, -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedo

Re: Is there convenient way to setup Fedora compilation flags outside of the RPM build?

Dne 24. 12. 22 v 20:49 Florian Weimer napsal(a): * Vít Ondruch: Working with upstream on one issue [1], it seems that the culprit is in the Fedora compiler options. Is there some convenient way to set them up? Of course I can copy them from log, or somehow put together from the RPM macros, but

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

Dominik 'Rathann' Mierzejewski wrote: > Personally, I use the kernel's recommended commit to the oldest > supported branch and merge upwards workflow and I've learned not to be > afraid of merge commits. If any branch needs some specific fixes, > I just apply them there and only there, without usin

Re: F38 proposal: GNU Toolchain Update (gcc 13.0, binutils 2.39, glibc 2.37, gdb 12.1) (System-Wide Change proposal)

Matthew Miller wrote: > Okay. no. This is not how we do things here. Apologies for my snide remark that visibly came out rude, sorry. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le..

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Monday, 02 January 2023 at 09:57, Miroslav Suchý wrote: > Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a): > > produces bogus changelog messages and artificially > > inflates Release counters. > > I always wondered why people are afraid of gaps in numbering? It is > just a number

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

Similar situation happens if you have spec file in upstream. The problem is that mass rebuilds are adding entries to dowstream spec file only, so you have to manually merge the upstream and downstream or ideally do a backport upstream before realese. This is nice and easy solution for the issue

Fedora rawhide compose report: 20230102.n.0 changes

OLD: Fedora-Rawhide-20230101.n.0 NEW: Fedora-Rawhide-20230102.n.0 = SUMMARY = Added images:2 Dropped images: 0 Added packages: 1 Dropped packages:0 Upgraded packages: 55 Downgraded packages: 0 Size of added packages: 24.06 KiB Size of dropped packages:0 B

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Mon Jan 2, 2023 at 09:57 +0100, Miroslav Suchý wrote: > Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a): > > produces bogus changelog messages and artificially > > inflates Release counters. > > I always wondered why people are afraid of gaps in numbering? It is > just a number. T

Kernel 6.1 Test Week 2023-01-03 through 2023-01-08

Hey All, I would like to invite all of you to participate in the Kernel 6.1 Test week is happening from 2023-01-03 to 2023-01-08. It's fairly simple, head over to the wiki [0] and read in detail about the test week and simply run the test case mentioned in[1] and enter your results. As usual, the

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

Dne 02. 01. 23 v 9:38 Dominik 'Rathann' Mierzejewski napsal(a): produces bogus changelog messages and artificially inflates Release counters. I always wondered why people are afraid of gaps in numbering? It is just a number. The number will not object if you skip some of them. :) Or it is my

Re: F38 proposal: Rpmautospec by Default (System-Wide Change proposal)

On Sunday, 01 January 2022 at 20:51, Fabio Valentini wrote: [...] > Additionally, not having Release counter and changelog in the .spec > file means that you can usually freely cherry-pick or merge bug-fix > commits across different dist-git branches. This wasn't possible > without rpmautospec due