Re: AI-generated content in Fedora packages: do we have rules?

On Fri, Jul 18, 2025 at 11:38:27AM +0200, Florian Weimer wrote: > * Daniel P. Berrangé: > > > In practical terms, how can a contributor do due-diligence on the > > output of an AI generator ? The vast size of training material makes > > it hard, if not impossible validate

Re: AI-generated content in Fedora packages: do we have rules?

On Thu, Jul 17, 2025 at 07:24:22PM -0400, Simo Sorce wrote: > On Thu, 2025-07-17 at 15:26 -0700, Adam Williamson wrote: > > On Thu, 2025-07-17 at 15:18 -0400, Simo Sorce wrote: > > > In my opinion the situation is simple, as already several courts > > > hinted, the output of an AI cannot be copyrig

Re: AI-generated content in Fedora packages: do we have rules?

On Wed, Jul 16, 2025 at 04:09:41PM -0400, Stephen Gallagher wrote: > I'm thinking we should treat AI-generated code the same way that we > would treat sub-contracted code. I've worked at companies that > outsourced some software-development to subcontracting companies. The > way this would generall

Re: Fedora Virtualization Maintainers account disabled in Bugzilla

On Tue, Jul 15, 2025 at 12:07:26PM +0200, Miro Hrončok wrote: > On 15. 07. 25 12:00, Daniel P. Berrangé wrote: > > On Tue, Jul 15, 2025 at 11:48:50AM +0200, Miro Hrončok wrote: > > > Hello, > > > > > > There is a bug for qemu which was assigned to "Fe

Re: Introducing Provides bash(*)

On Tue, Jul 15, 2025 at 03:22:44PM +0200, Cristian Le via devel wrote: > Hi all, > > During the review of bash-preexec [1] we came up on the issue that according > to the documentation, this package would be in conflict with any other bash > script that use the variable `PROMPT_COMMAND` or `DEBUG`

Re: Fedora Virtualization Maintainers account disabled in Bugzilla

On Tue, Jul 15, 2025 at 11:48:50AM +0200, Miro Hrončok wrote: > Hello, > > There is a bug for qemu which was assigned to "Fedora Virtualization > Maintainers" in Bugzilla by default: > > https://bugzilla.redhat.com/2375004 > > But that account is disabled. > > """ > You can't ask Fedora Virtual

Re: Orphaning eza (rust-eza - maintained fork of exa)

On Fri, Jul 11, 2025 at 05:19:59PM +0200, Fabio Valentini wrote: > On Thu, Jul 3, 2025 at 6:40 PM Germano Massullo > wrote: > > > > Richard Fontana has given his answer to the license question > > https://gitlab.com/fedora/legal/fedora-license-data/-/issues/668#note_2600398017 > > > > I am plannin

Re: Missing SSE intrinsics on i686

On Wed, Jul 09, 2025 at 01:16:45PM +0200, Jan Stanek wrote: > Hello everyone! > I recently ran into build failure in the upcoming nodejs24, on i686 > architecture (yay!). It seems like some of the sse vector instructions > are not defined, on just this arch: > Side note, the code that is trying to

Re: Windows Secure Boot certificate expiration (June 2026)

On Tue, Jul 08, 2025 at 09:44:54PM -0300, Mateus Rodrigues Costa wrote: > Hello all, > > As you guys know Secure Boot is supported by Fedora Linux and it > relies on the Microsoft signing keys. > Well, recently I was looking at this month's Windows 11 cumulative > update and noticed this warning:

Re: F43 Change Proposal: Drop i686 support (system wide)

On Thu, Jun 26, 2025 at 11:07:11AM -0400, Solomon Peachy wrote: > On Thu, Jun 26, 2025 at 03:46:44PM +0100, Daniel P. Berrangé wrote: > > > Question: How are said containers to be constructed (much less > > > maintained) when working within the Fedora/RHEL ecosystem? >

Re: F43 Change Proposal: Drop i686 support (system wide)

On Thu, Jun 26, 2025 at 09:22:58AM -0400, Solomon Peachy wrote: > On Thu, Jun 26, 2025 at 08:50:48AM +0100, Daniel P. Berrangé wrote: > > Yes, I can understand the benefit of testing 64 vs 32 bit in general, > > as that's a frequent source of bugs in many apps still, alongsi

Re: F43 Change Proposal: Drop i686 support (system wide)

On Thu, Jun 26, 2025 at 12:16:21PM +0200, Fabio Valentini wrote: > On Thu, Jun 26, 2025 at 12:09 PM Daniel P. Berrangé > wrote: > > > > On Thu, Jun 26, 2025 at 11:50:10AM +0200, Fabio Valentini wrote: > > > On Thu, Jun 26, 2025 at 11:24 AM Vít Ondruch wrote: > >

Re: F43 Change Proposal: Drop i686 support (system wide)

On Thu, Jun 26, 2025 at 11:50:10AM +0200, Fabio Valentini wrote: > On Thu, Jun 26, 2025 at 11:24 AM Vít Ondruch wrote: > > > > Reading through the feedback, wouldn't it be better to take a second > > look on the previous change: > > > > > > Dne 24. 06. 25 v 12:02 Aoife Moloney via devel-announce n

Re: F43 Change Proposal: Drop i686 support (system wide)

On Wed, Jun 25, 2025 at 09:14:20PM +0100, Jonathan Wakely wrote: > On Wed, 25 Jun 2025 at 20:55, Daniel P. Berrangé wrote: > > > > On Wed, Jun 25, 2025 at 08:45:33PM +0100, Jonathan Wakely wrote: > > > On Wed, 25 Jun 2025 at 16:08, Jakub Jelinek wrote: > > > >

Re: F43 Change Proposal: Drop i686 support (system wide)

On Wed, Jun 25, 2025 at 08:45:33PM +0100, Jonathan Wakely wrote: > On Wed, 25 Jun 2025 at 16:08, Jakub Jelinek wrote: > > > > And there is another aspect, Fedora being used often as a distribution used > > by developers working on compilers and other parts of toolchain. Not having > > at least bas

Re: F43 Change Proposal: Drop i686 support (system wide)

On Wed, Jun 25, 2025 at 10:42:22AM +0200, Fabio Valentini wrote: > On Tue, Jun 24, 2025 at 7:46 PM Eduard Lucena > wrote: > > > > Hello guys, > > > > As I did it in discussion.fp.o, I need to remind everyone that the latest > > update of Fedora Strategy [1] that one the objectives is to grow our

Re: F43 Change Proposal: Drop i686 support (system wide)

On Tue, Jun 24, 2025 at 08:04:52AM -0500, Chris Adams wrote: > Once upon a time, Daniel P. Berrangé said: > > What else would be high profile enough *in Fedora* to merit a > > blocker ? IMHO external apps should not influence our decision, > > and must adapt to what the dist

Re: F43 Change Proposal: Drop i686 support (system wide)

On Tue, Jun 24, 2025 at 11:02:56AM +0100, Aoife Moloney via devel-announce wrote: > == Detailed Description == snip > This Change Proposal implements the next two (and last) steps: > > * Packages built for the i686 architecture are no longer included in > x86_64 repositories (dropping "multilib

Re: F43 Change Proposal: Drop i686 support (system wide)

On Tue, Jun 24, 2025 at 12:26:27PM -0500, Michael Cronenworth wrote: > Red Hat's enterprise ambitions may not take it near Valve headquarters, but > I do not see why gaming has to be the primary selling point. RHEL 10 removed > i686 but I would not be surprised to see it return once customers attem

Re: F43 Change Proposal: Drop i686 support (system wide)

On Tue, Jun 24, 2025 at 09:25:23AM -0400, Stephen Smoogen wrote: > On Tue, 24 Jun 2025 at 09:09, Petr Pisar wrote: > > > V Tue, Jun 24, 2025 at 08:25:09AM -0400, Stephen Smoogen napsal(a): > > > I realized I wasn't clear on what I meant by a microOS. This would be > > only > > > the libraries and

Re: F43 Change Proposal: Drop i686 support (system wide)

On Tue, Jun 24, 2025 at 05:23:24PM +, Gary Buhrmaster wrote: > On Tue, Jun 24, 2025 at 1:45 PM Daniel P. Berrangé > wrote: > > > If we only want to build a small subset of packages as i686, then > > rather than doing it as an architecture in koji, IMHO, we could >

Re: F43 Change Proposal: Drop i686 support (system wide)

On Tue, Jun 24, 2025 at 05:52:02PM +0200, Florian Weimer wrote: > * Petr Pisar: > > > Is Fedora relevant for Steam? The download page > > only offers a Debian package and the > > only more verbose message I found > >

Re: Remove -mno-omit-leaf-frame-pointer from build flags

On Sun, Jun 22, 2025 at 11:41:48AM +0200, Florian Weimer wrote: > We currently use -mno-omit-leaf-frame-pointer on various architectures. > I think we should remove it because it does not work as expected. I was confused for a minute as my eye tuned out the word '-leaf' in the arg above, so I mist

Re: rpmlint: Question about SPDX-license and duplicat files

On Thu, May 22, 2025 at 12:00:04PM -, Martin Gansser wrote: > The second question concerns the listing of the individual files and the > assignment of the SPDX license [2] > in the rpm spec file. > > [2] https://martinkg.fedorapeople.org/ErrorReports/licensecheck_spdx.txt > [3] https://martin

Re: gettext 1.25 & error: possibly undefined macro: AM_GNU_GETTEXT

On Mon, May 19, 2025 at 06:25:27PM +0200, Michael Schwendt wrote: > On Mon, 19 May 2025 16:11:00 +0100, Daniel P. Berrangé wrote: > > > [...], avoiding the autopoint dance > > autoreconf is supposed to run autopoint according to the manual page, > and not even if runn

Re: gettext 1.25 & error: possibly undefined macro: AM_GNU_GETTEXT

On Mon, May 19, 2025 at 03:56:34PM +0100, Richard W.M. Jones wrote: > On Mon, May 19, 2025 at 03:22:48PM +0100, Richard W.M. Jones wrote: > > m4/guestfs-libraries.m4:158: warning: macro 'AM_GNU_GETTEXT' not found in > > library > > autoreconf: running: /usr/bin/autoconf --force > > configure

Re: grub2 NVR went backwards

On Thu, May 01, 2025 at 10:49:26AM -0400, Yaakov Selkowitz wrote: > Yesterday there was a build of grub2 (2.12-17) from the f40 branch which was > also built for rawhide/f43 and ELN. This was an NVR regression, as the > previous rawhide and ELN builds were 2.12-30 off the rawhide branch (as > expe

Re: Discussion about dropping qemu builds on i686

On Tue, Apr 15, 2025 at 03:56:28PM -0400, Cole Robinson wrote: > On 4/15/25 12:21 PM, Fabio Valentini wrote: > > On Tue, Apr 15, 2025, 18:14 Stephen Smoogen > <mailto:ssmoo...@redhat.com>> wrote: > > > > > > > > On Tue, 15 Apr 2025 at 1

Re: packages with files in /usr/sbin blocking bin-sbin merge

On Tue, Apr 15, 2025 at 11:20:29AM +, Zbigniew Jędrzejewski-Szmek wrote: > Hi, > > When a system is _upgraded_ to F42, we try to "merge", by making > /usr/sbin a symlink to /usr/bin. This is blocked when a package lists > files under /usr/sbin. Slight tangent, but I've just discovered an unan

Re: Discussion about dropping qemu builds on i686

On Tue, Apr 15, 2025 at 11:43:47AM -0500, Michael Catanzaro wrote: > On Tue, Apr 15 2025 at 05:40:43 PM +01:00:00, Richard W.M. Jones > wrote: > > I've no argument that Webex is hot proprietary garbage, just saying > > that it was once noted as being a blocker. > > Let's agree that anything we ca

Re: Discussion about dropping qemu builds on i686

On Tue, Apr 15, 2025 at 06:21:20PM +0200, Fabio Valentini wrote: > On Tue, Apr 15, 2025, 18:14 Stephen Smoogen wrote: > > > > > > > On Tue, 15 Apr 2025 at 12:10, Daniel P. Berrangé > > wrote: > > > >> On Tue, Apr 15, 2025 at 11:43:38AM -0400, Cole

Re: Discussion about dropping qemu builds on i686

On Tue, Apr 15, 2025 at 11:43:38AM -0400, Cole Robinson wrote: > > Has anyone gone through the effort of removing i686 from a wide reaching > non-leaf package? Any advice appreciated Can we just stop building for i686 in Fedora in general, instead of burning maintainer time figuring out deps prob

Re: packaging: prefer git archives to upstream archives for Source

On Mon, Mar 31, 2025 at 01:39:57PM +0200, Vitaly Zaitsev via devel wrote: > On 31/03/2025 12:53, Zbigniew Jędrzejewski-Szmek wrote: > > This is inspired by the discussion in "Reproducible Builds" mailing list, > > in particular [1]. > > But auto-generated Git archives are not reproducible. The gi

Re: packaging: prefer git archives to upstream archives for Source

On Mon, Mar 31, 2025 at 02:35:07PM +, Tim Landscheidt wrote: > Daniel P. Berrangé wrote: > > >> Let me also mention the case where we have to clean sources (proprietary > >> material) before committing to the look-aside cache. We should document > >> how

Re: SPDX Statistics - 115 packages remaining

On Mon, Mar 31, 2025 at 03:30:50PM +0200, Miroslav Suchý wrote: > Dne 31. 03. 25 v 2:14 odp. Vitaly Kuznetsov napsal(a): > > Miroslav Suchý writes: > > > > ... > > > > > Packages that are neither in SPDX nor in Callaway format (highest > > > priority for now) - 32 packages: > > > > > > https://p

Re: packaging: prefer git archives to upstream archives for Source

On Tue, Apr 01, 2025 at 10:49:59AM +0200, Alexander Sosedkin wrote: > On Mon, Mar 31, 2025 at 9:31 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Mon, Mar 31, 2025 at 01:24:06PM +0200, Alexander Sosedkin wrote: > > > On Mon, Mar 31, 2025 at 12:56 PM Zbigniew Jędrzejewski-Szmek > > > Just one q

Re: packaging: prefer git archives to upstream archives for Source

On Mon, Mar 31, 2025 at 07:59:50PM +, Zbigniew Jędrzejewski-Szmek wrote: > To expand on this one: it is true that the untrustworthy maintainer > would have been able to add files to git too. But it is also true that > people may much closer attention to the git commits than to the tarball. In

Re: packaging: prefer git archives to upstream archives for Source

On Mon, Mar 31, 2025 at 01:14:42PM +0200, Michael J Gruber wrote: > Let me also mention the case where we have to clean sources (proprietary > material) before committing to the look-aside cache. We should document > how to do so in spec. > > Ideally, one could: > - get original sources > - check

Re: Non-responsive maintainer check for dledford

On Thu, Mar 20, 2025 at 12:57:38PM +, Mattia Verga via devel wrote: > Il 20/03/25 10:14, Daniel P. Berrangé ha scritto: > > On Wed, Mar 19, 2025 at 03:22:08PM -0700, Davide Cavalca wrote: > >> On 2025-03-19 14:48, Peter Martuccelli wrote: > >>> Hi Davide, > >

Re: Non-responsive maintainer check for dledford

On Wed, Mar 19, 2025 at 03:22:08PM -0700, Davide Cavalca wrote: > On 2025-03-19 14:48, Peter Martuccelli wrote: > > Hi Davide, > > > > Please work with Dan, Cc'd, on any issues for Doug. > > Thanks Peter. My immediate concern is getting mstflint updated to 4.31 if > possible, and resolving the ou

Re: F43 Change Proposal: Package builds are expected to be reproducible (system-wide)

On Wed, Mar 19, 2025 at 06:48:21PM +, Aoife Moloney via devel-announce wrote: > > == Scope == > * Proposal owners: > ** Package [https://github.com/keszybz/fedora-repro-build > fedora-repro-build] to allow local rebuilds of historical koji builds > ** Make [https://github.com/kpcyrd/rebuilder

Re: sysusers scriptlet failed for softhsm on riscv64

On Mon, Mar 17, 2025 at 03:01:24PM -0400, Andrea Bolognani wrote: > Hi, > > attempting to install softhsm on riscv64 currently results in the > following error: > > # dnf install -y softhsm > ... > >>> Running pre-install scriptlet: softhsm-0:2.6.1-11.rvre0.fc42.riscv64 > >>> Error in pre

Re: F43 Change Proposal RPM 6.0 (system-wide)

On Mon, Mar 10, 2025 at 12:44:44PM +, Aoife Moloney via devel-announce wrote: > Wiki - https://fedoraproject.org/wiki/Changes/RPM-6.0 > Discussion thread - > https://discussion.fedoraproject.org/t/f43-change-proposal-rpm-6-0-system-wide/146855 > > This is a proposed Change for Fedora Linux. >

Re: Replacing regular file with directory on RPM upgrade ?

On Mon, Mar 10, 2025 at 10:26:12AM +0100, Miroslav Suchý wrote: > Dne 10. 03. 25 v 10:22 dop. Daniel P. Berrangé napsal(a): > > Did something change in cpio, or has it always been broken for regular file > > to directory replacement too, and our docs were thus always incomplet

Replacing regular file with directory on RPM upgrade ?

In the packaging guidelines we call out the problematic upgrades for replacing a directory with a non-directory, or replacing a symlink with a directory. We don't mention replacing a regular file with a directory though. Empirically that appears to be a broken scenario too. # ls -al /usr/lib64/gi

-gsplit-dwarf vs RPM find-debuginfo ?

The QEMU community is discussing possible use of -gsplit-dwarf as a default option for QEMU's build system: https://lists.nongnu.org/archive/html/qemu-devel/2025-03/msg00424.html This option causes debug symbols to be written to separate .dwo files instead of the .o files or final executables.

Re: F43 change Proposal: Disabling support of building OpenSSL engines (system-wide)

On Tue, Feb 25, 2025 at 03:48:43PM +, Richard W.M. Jones wrote: > On Tue, Feb 25, 2025 at 01:55:35PM +, Zbigniew Jędrzejewski-Szmek wrote: > > 'fedrq wr -b rawhide openssl-devel-engine | wc -l' says 62. > > That list should have been in the proposal! Here it is anyway ... To pick a few p

Re: F43 change Proposal: Disabling support of building OpenSSL engines (system-wide)

On Tue, Feb 25, 2025 at 01:57:35PM +0100, Clemens Lang wrote: > > > Providing a dummy engine.h that does not actually contain any of > > the definitions that engine.h is supposed to provide feels like > > the kind of thing we should not do downstream only. It is liable > > to break any configure t

Re: F43 change Proposal: Disabling support of building OpenSSL engines (system-wide)

On Mon, Feb 24, 2025 at 05:53:46PM +, Aoife Moloney via devel-announce wrote: > Wiki - https://fedoraproject.org/wiki/Changes/OpensslNoBuildEngine > Discussion thread - > https://discussion.fedoraproject.org/t/f43-change-proposal-disabling-support-of-building-openssl-engines-system-wide/145922

Re: libnfs soname bump

On Tue, Feb 18, 2025 at 02:38:14PM +, Richard W.M. Jones wrote: > On Fri, Dec 13, 2024 at 02:44:56PM +0100, Xavier Bachelot wrote: > > Hi, > > > > libnfs 6.0.0 bumps its soname from 14 to 16. > > > > Affected packages are: > > gvfs > > qemu > > vlc > > xine-lib > > kodi (RPM Fusion) > > mpd (

Re: bin-sbin merge case of packages which install to hardcoded $DESTDIR/usr/sbin

On Tue, Feb 04, 2025 at 02:54:30PM +, Sérgio Basto via devel wrote: > Hi, > In this case: "packages which install to hardcoded $DESTDIR/usr/sbin, > but then use %{_sbindir} in %files, will need to be adjusted." > > I did this [1] after the make install, is that correct ? > > [1] > %if "%{_

Re: Reflecting on Rings [was Re: Proposal for vendoring/bundling golang packages by default]

On Thu, Jan 30, 2025 at 11:31:33AM +0300, Benson Muite wrote: > On Wed, Jan 29, 2025, at 3:56 PM, Matthew Miller wrote: > > On Wed, Jan 22, 2025 at 09:51:28AM +0000, Daniel P. Berrangé wrote: > > What do we gain from building, say, Inkscape ourselves — other than allowing > >

Re: [rfc] mass package change to introduce sysusers.d configs

On Wed, Jan 29, 2025 at 03:37:07PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Jan 29, 2025 at 03:12:32PM +0000, Daniel P. Berrangé wrote: > > On Thu, Jan 23, 2025 at 08:51:16PM +, Zbigniew Jędrzejewski-Szmek wrote: > > > Hi! > > > > >

Re: [rfc] mass package change to introduce sysusers.d configs

On Wed, Jan 29, 2025 at 03:33:25PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Jan 29, 2025 at 02:59:04PM +0000, Daniel P. Berrangé wrote: > > On Wed, Jan 29, 2025 at 02:16:06PM +, Zbigniew Jędrzejewski-Szmek wrote: > > > On Sat, Jan 25, 2025 at 11:04:54AM +, Zbi

Re: [rfc] mass package change to introduce sysusers.d configs

On Thu, Jan 23, 2025 at 08:51:16PM +, Zbigniew Jędrzejewski-Szmek wrote: > Hi! > > In accordance with > https://docs.fedoraproject.org/en-US/fesco/Mass_package_changes/, > I plan to do a "mass package change" to add sysusers.d config files for all > packages > which currently call 'useradd'

Re: [rfc] mass package change to introduce sysusers.d configs

On Wed, Jan 29, 2025 at 02:16:06PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Jan 25, 2025 at 11:04:54AM +, Zbigniew Jędrzejewski-Szmek wrote: > > On Sat, Jan 25, 2025 at 10:16:01AM +, Zbigniew Jędrzejewski-Szmek wrote: > > > But I see that I didn't add packages that just call > >

Re: RFC: Additional checkpoint for major toolchain updates before mass rebuild

On Tue, Jan 28, 2025 at 11:19:02AM +0100, Vít Ondruch wrote: > I think we should stop and think again why we do mass rebuilds and why we do > them prior release. "The goal is to rebuild every single Fedora package, > regardless of content, before the Fedora 41 Change Deadline." [1] is not > very el

Re: Proposal for vendoring/bundling golang packages by default

On Wed, Jan 22, 2025 at 01:27:09PM +0100, Fabio Valentini wrote: > On Wed, Jan 22, 2025 at 10:52 AM Daniel P. Berrangé > wrote: > > > > An increasingly large part of the ecosystem is working and deploying > > a way that Fedora (and derivative distros) are relegated to on

Re: Proposal for vendoring/bundling golang packages by default

On Tue, Jan 21, 2025 at 12:49:17PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Jan 20, 2025 at 04:24:28PM +0100, Miroslav Suchý wrote: > > Dne 20. 01. 25 v 11:29 dop. Michael J Gruber napsal(a): > > > There is a second point to that, and that is Fedora as a development > > > platform (not j

Re: Proposal for vendoring/bundling golang packages by default

On Mon, Jan 20, 2025 at 11:29:55AM +0100, Michael J Gruber wrote: > Mikel Olasagasti venit, vidit, dixit 2025-01-20 08:02:18: > > Hi, > > > > Go-SIG has raised a ticket with FESCo [1] to propose a significant > > shift in Fedora's packaging approach for Go dependencies: moving to > > vendoring/bun

Re: forwarding aliases (was: Non-responsive maintainer sham1)

On Wed, Jan 15, 2025 at 07:03:23PM +0100, Björn Persson wrote: > Kevin Fenzi wrote: > > On Wed, Jan 15, 2025 at 04:15:11PM +0100, Cristian Le via devel wrote: > > > On 1/15/25 2:33 PM, Fabio Valentini wrote: > > > > > > > No, AFAIK the @fedoraproject.org email alias should work for > > > > all u

Re: Convention for naming patches

On Tue, Jan 14, 2025 at 11:36:59AM +0100, Vít Ondruch wrote: > Hi, > > Is there any convention for naming patches? I mildly remember that there > used to be some guideline suggesting form such as > `pagkage-name-version-description-of-patch.patch`. But I was not able to > find this codified in gui

Re: F42 Change Proposal: Optimized Binaries for the AMD64 / x86_64 Architecture (v2) (self-contained)

On Sun, Jan 12, 2025 at 07:08:05PM -0500, Neal Gompa wrote: > On Sun, Jan 12, 2025 at 4:36 PM Chris Adams wrote: > > > > Once upon a time, Neal Gompa said: > > > For stuff installed into /usr, we > > > should just allow packages to be optionally built with the higher > > > microarchitecture level

Re: F42 Change Proposal: Optimized Binaries for the AMD64 / x86_64 Architecture (v2) (self-contained)

On Fri, Jan 10, 2025 at 07:28:19PM +, Aoife Moloney via devel-announce wrote: > == Summary == > Individual packages can provide already optimized libraries via the > glibc-hwcaps mechanism. This approach will be extended to executables. > The package provides an optimized variant of a binary i

Re: AVX but not AVX2: F42 Change Proposal: Optimized Binaries for the AMD64 / x86_64

On Fri, Jan 10, 2025 at 01:45:44PM -0800, John Reiser wrote: > > A vendor-independent x86-64 psABI > > supplement defines four "microachitecture levels": `x86-64-v1` (the > > baseline, our code targets this), `x86-64-v2` (+`SSE3`, CentoOS > > targets this), `x86-64-v3` (+`AVX`), `x86-64-v4` (+`AVX5

Re: F42 Change Proposal: Optimized Binaries for the AMD64 / x86_64 Architecture (v2) (self-contained)

On Sun, Jan 12, 2025 at 12:08:20PM +0100, drago01 wrote: > On Sunday, January 12, 2025, Vitaly Zaitsev via devel < > devel@lists.fedoraproject.org> wrote: > > > On 10/01/2025 20:28, Aoife Moloney via devel-announce wrote: > > > >> Individual packages can provide already optimized libraries via the

Re: libnova: announcing soname bump

On Fri, Jan 10, 2025 at 11:33:35AM +, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Jan 06, 2025 at 01:18:35PM -0500, Stephen Smoogen wrote: > > On Mon, 6 Jan 2025 at 12:50, Fabio Valentini wrote: > > > > > > If this is not what 'proven packagers' are allowed to do, it might be > > > good to h

Re: Non-responsive maintainer ngompa

On Wed, Jan 08, 2025 at 11:04:53AM +0100, Michael J Gruber wrote: > Daniel P. Berrangé venit, vidit, dixit 2025-01-08 10:27:33: > > On Wed, Jan 08, 2025 at 09:01:33AM -, Hong Xu wrote: > > > This email follows week 0.step 3 in the nonresponsive > > > ma

Re: Non-responsive maintainer ngompa

On Wed, Jan 08, 2025 at 09:01:33AM -, Hong Xu wrote: > This email follows week 0.step 3 in the nonresponsive > maintainer page: > https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/#stesp > > If anyone knows how to contact ngompa, please let me know. The p

Re: Revocation of provenpackager access from pbrobinson

On Thu, Dec 19, 2024 at 10:51:30AM +0100, Vít Ondruch wrote: > > Dne 18. 12. 24 v 22:21 Matthew Miller napsal(a): > > On Tue, Dec 17, 2024 at 02:28:09PM +0100, Vít Ondruch wrote: > > > This is not recent example, but really bad example of PP's work IMHO: > > > https://src.fedoraproject.org/rpms/ru

Re: Revocation of provenpackager access from pbrobinson

On Thu, Dec 19, 2024 at 10:35:52AM +0100, Vít Ondruch wrote: > > Dne 19. 12. 24 v 9:55 Daniel P. Berrangé napsal(a): > > On Thu, Dec 19, 2024 at 09:26:37AM +0100, Vitaly Zaitsev via devel wrote: > > > On 18/12/2024 22:59, Simon de Vlieger wrote: > > > >

Re: Revocation of provenpackager access from pbrobinson

On Thu, Dec 19, 2024 at 09:26:37AM +0100, Vitaly Zaitsev via devel wrote: > On 18/12/2024 22:59, Simon de Vlieger wrote: > > What I'd like to see is to remove provenpackagers, do everything through > > PRs and have a separate SIG/group that can fast-track and merge any PR. > > Not an option becaus

Re: Promoting co-maintainer to main maintainer for orphaned packages?

On Wed, Dec 18, 2024 at 02:15:23PM +0100, Pierre-Yves Chibon wrote: > On Wed, Dec 18, 2024 at 09:03:45AM +0000, Daniel P. Berrangé wrote: > > On Wed, Dec 18, 2024 at 09:53:17AM +0100, Miroslav Suchý wrote: > > > Dne 18. 12. 24 v 1:38 dop. maxwell--- via devel-announce naps

Re: Promoting co-maintainer to main maintainer for orphaned packages?

On Wed, Dec 18, 2024 at 10:43:33AM +0100, Vít Ondruch wrote: > I would object! We've been there prior we arrived to the current workflow. > And the typical situation was that such package was moved from one > non-responsive maintainer to the other non-responsive maintainer. With my > handle beginni

Re: Promoting co-maintainer to main maintainer for orphaned packages?

On Wed, Dec 18, 2024 at 02:21:19AM -0700, Neal Gompa wrote: > On Wed, Dec 18, 2024 at 2:04 AM Daniel P. Berrangé > wrote: > > > > On Wed, Dec 18, 2024 at 09:53:17AM +0100, Miroslav Suchý wrote: > > > Dne 18. 12. 24 v 1:38 dop. maxwell--- via devel-announce napsa

Re: Promoting co-maintainer to main maintainer for orphaned packages?

On Wed, Dec 18, 2024 at 09:53:17AM +0100, Miroslav Suchý wrote: > Dne 18. 12. 24 v 1:38 dop. maxwell--- via devel-announce napsal(a): > > 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 p

Re: On revoking provenpackager from probinson

On Tue, Dec 17, 2024 at 01:49:27AM +0100, Fabio Valentini wrote: > On Mon, Dec 16, 2024 at 11:03 PM Adam Williamson > wrote: > > > > On Mon, 2024-12-16 at 15:42 -0500, David Cantrell wrote: > > > We neglected to make available the facts behind our decision quickly (In > > > some cases we were dea

Re: Revocation of provenpackager access from pbrobinson

On Mon, Dec 16, 2024 at 01:57:03PM +0100, Miroslav Suchý wrote: > Dne 16. 12. 24 v 11:17 dop. Daniel P. Berrangé napsal(a): > > By all means have personal preferences, but if someone is following > > documented Fedora procedures that should be considered fine, even if > >

Re: Revocation of provenpackager access from pbrobinson

On Mon, Dec 16, 2024 at 12:20:06PM +0100, Miro Hrončok wrote: > On 16. 12. 24 11:17, Daniel P. Berrangé wrote: > >"Prior to making changes, provenpackagers should try to communicate > > with owners of a package in bugzilla, dist-git pull requests, IRC, >

Re: Revocation of provenpackager access from pbrobinson

On Mon, Dec 16, 2024 at 12:18:00PM +0100, Michael J Gruber wrote: > Daniel P. Berrangé venit, vidit, dixit 2024-12-16 11:17:35: > > On Sun, Dec 15, 2024 at 04:49:32PM +, Richard W.M. Jones wrote: > [snip] > > [snip] > > > > > I do think we need a bit les

Re: Revocation of provenpackager access from pbrobinson

On Sun, Dec 15, 2024 at 04:49:32PM +, Richard W.M. Jones wrote: > On Sun, Dec 15, 2024 at 03:15:11PM +, Peter Robinson wrote: > [...] > > I'm a little surprised by Peter's email that he also has little > insight into why this was done. But I have no reason to believe one > person over ano

Re: Proposed qemu-srpm-macros

On Fri, Nov 29, 2024 at 04:16:51PM +, Richard W.M. Jones wrote: > On Fri, Nov 29, 2024 at 04:02:43PM +0000, Daniel P. Berrangé wrote: > > On Fri, Nov 29, 2024 at 03:48:02PM +, Richard W.M. Jones wrote: > > > On Fri, Nov 29, 2024 at 04:36:14PM +0100, Florian Weimer wrote:

Re: Proposed qemu-srpm-macros

On Fri, Nov 29, 2024 at 03:48:02PM +, Richard W.M. Jones wrote: > On Fri, Nov 29, 2024 at 04:36:14PM +0100, Florian Weimer wrote: > > * Daniel P. Berrangé: > > > > > I think I'd prefer to stay away from redhat-rpm-config. Not because it > > > is a proble

Re: Proposed qemu-srpm-macros

On Fri, Nov 29, 2024 at 03:36:44PM +0100, Miro Hrončok wrote: > On 28. 11. 24 23:49, Neal Gompa wrote: > > On Thu, Nov 28, 2024 at 4:30 AM Florian Weimer wrote: > > > > > > * Richard W. M. Jones: > > > > > > > One question is whether it's better to add this as a sub-package of > > > > qemu, or a

Re: Looking for advice on packaging newer version of ncdu

On Fri, Nov 22, 2024 at 12:29:26PM +, Richard Fearn wrote: > Hi all, > > ncdu is a text-mode disk usage analyzer: https://dev.yorhel.nl/ncdu > > I maintain the ncdu package in Fedora ( > https://src.fedoraproject.org/rpms/ncdu) which is currently ncdu 1.x > (written in C). > > There's a new

Re: Moving away from the term "karma" in Bodhi

On Mon, Nov 11, 2024 at 11:25:40AM -0500, Matthew Miller wrote: > On Mon, Nov 11, 2024 at 11:58:39AM +0100, Lukas Ruzicka wrote: > > Well, I am very sad about this step and I feel very sorry that you are > > trying to remove the word karma from the process. I believe that Karma > > denotes one of t

Re: Moving away from the term "karma" in Bodhi

On Tue, Nov 12, 2024 at 09:43:37AM +, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Nov 12, 2024 at 09:07:33AM +0000, Daniel P. Berrangé wrote: > >"Karma: Is the update generally functional?" > > > > The word "karma" is adding no value here,

Re: [Fedora-packaging] Packaging Guidelines for Applications using Git Submodules

On Tue, Nov 12, 2024 at 09:29:02AM -, Germano Massullo wrote: > Hello, I found out this old thread while searching for Fedora packaging > guidelines for Git submodules. > Are there any news about guidelines on how to deal with them? I could not > find any information on docs.fedoraproject.org

Re: Fedora 42: The Answer to Life, The Universe and Everything

On Mon, Nov 04, 2024 at 01:27:04PM -0600, Joe Doss wrote: > On 11/4/24 10:32 AM, Neal Gompa wrote: > > To be honest, I think we should bring back codenames overall, but I'll > > take the one-off for now. > > I am with you Neal. I loved codenames back in the day. Especially Fedora > 17's Beefy Mira

Re: Fedora 42: The Answer to Life, The Universe and Everything

On Mon, Nov 04, 2024 at 10:52:18AM -0500, Stephen Gallagher wrote: > I posted this discussion on Fedora Discussion[1] last week, but I'd > like to forward this discussion to devel-list for wider consideration. > For the sake of keeping the conversation in one place, I do ask that > you reply on the

Re: Updating Jansson in Rawhide

On Tue, Oct 22, 2024 at 01:34:43PM +0200, Thomas Haller wrote: > Hi, > > > On Tue, 2024-10-22 at 12:06 +0100, Richard W.M. Jones wrote: > > Jansson (a JSON library) in Rawhide is out of date compared to > > upstream.  The latest version in Rawhide is jansson-2.13.1-10.fc42 > > and > > the latest

Re: Updating Jansson in Rawhide

On Tue, Oct 22, 2024 at 01:43:55PM +0200, Thomas Haller wrote: > On Tue, 2024-10-22 at 13:34 +0200, Thomas Haller wrote: > > > > > > [But also, the reason I want to update is _because_ of symbol > > > versioning.  We are modifying libguestfs to change from Jansson to > > > json-c, but they share a

yajl - call for new maintainer and/or to stop using it

I've been maintainer of the yajl package in Fedora forever, as it was a dep of libvirt. yajl upstream has been dead since 2015, so the current release tarball has multiple CVEs, which I've patched downstream by grabbing patches from github issue comments from third parties or other distros [1]. I

Re: F42 Change Proposal: Integrate FEX in Fedora Linux (Self-Contained)

On Thu, Sep 12, 2024 at 04:50:39PM +0100, Aoife Moloney wrote: > == Owner == > * Name: [[User:dcavalca|Davide Cavalca]], [[User:ngompa|Neal Gompa]], > [[User:alyssa|Alyssa Rosenzweig]] > * Responsible Teams: [[SIGs/Asahi|Asahi SIG]], [[SIGs/KDE|KDE SIG]] > * Email: davide(at)cavalca.name, ngompa13(

Re: [SPDX] packages that are "not valid neither as Callaway nor as SPDX"

On Mon, Sep 09, 2024 at 04:00:57PM +0200, Miroslav Suchý wrote: > Dne 09. 09. 24 v 3:33 odp. Vít Ondruch napsal(a): > > > > Neat. This would allow to slap in some comments, right? E.g: > > > > > > ~~~ > > > > License:    %{shrink: > >     %dnl src/*.* > >     MIT AND

Re: [SPDX] packages that are "not valid neither as Callaway nor as SPDX"

On Fri, Sep 06, 2024 at 06:52:03AM -0500, Richard Shaw wrote: > I need a class again on how to do this... I remember years ago being told > we should try to come up with what the effective license is, so if the > package has sources that are both GPL--or-later and they have both GPL 2 > and GPL 3 s

Re: [SPDX] packages that are "not valid neither as Callaway nor as SPDX"

On Fri, Sep 06, 2024 at 10:49:07AM +0200, Miroslav Suchý wrote: > Bellow is list of packages that have licenses that are neither valid as > Callaway nor as SPDX. I.e. the license cannot be validated neither using > 'license-validate' nor using 'license-validate --old'. > > Some examples I checked

Re: How to handle nodejs bundling with native compiled modules ?

for it. > > As a consequence, there's currently *no good way* to package Node.js > stuff. The bundling exception and `nodejs-packaging-bundler` script > are stop-gap solutions to allow us to package at least something. > Basically any improvements and patches welcome, let me kn

How to handle nodejs bundling with native compiled modules ?

I'm working on packaging where one component is written in nodejs. The Fedora packaging guidelines are pretty explicit that I should be bundling all the 3rd party nodejs https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js "You can provide a package that uses nodejs, but you shou

Re: How to contact Fedora Security Team

On Tue, Aug 20, 2024 at 12:54:52PM +0200, Fabio Valentini wrote: > On Sun, Aug 18, 2024 at 5:23 PM Andrew Bauer > wrote: > > > > Thanks everyone for the great responses. > > > > I'll certainly check out the Matrix room if I have to, but I was hoping I > > could do this in a way that allows me to

  1   2   3   4   5   6   7   8   >