Re: Updating xorg-x11-server

[Sérgio Basto]

On Fri, 2024-09-06 at 14:57 +0200, Simone Caronni wrote:
> On Fri, Sep 6, 2024 at 2:50 PM Sérgio Basto 
> wrote:
> > I'd like to understand, so what in "X server 21.1" broke ? from
> > this
> > thread [1] only 340xx driver stopped to work , 390xx supports xorg-
> > 21.1
> 
> Both these branches are dead, 340 in 2019 and 390 in 2022.


xorg-x11-server is ready, I just fixed last issue which was with
Nouveau drive
https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/-/merge_requests/10

Best regards,
-- 
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: Updating xorg-x11-server

[Sérgio Basto]

On Fri, 2024-09-06 at 13:58 +0200, Neal Gompa wrote:
> On Fri, Sep 6, 2024 at 1:47 PM Sérgio Basto 
> wrote:
> > 
> > On Thu, 2024-09-05 at 18:54 +0200, Neal Gompa wrote:
> > > My understanding is the reason we hadn't was because of the
> > > NVIDIA
> > > binary driver. For the desktops that still use X11 and the X11
> > > DDX
> > > instead of the modesetting driver, that could be a problem if the
> > > ABI
> > > broke.
> > 
> > Here it says, some NVIDIA binary driver needs X11 DDX , that why I
> > wrote that seems possible re-add X11 DDX
> > 
> > https://www.phoronix.com/news/DMX-DDX-Dropping-2021
> > https://www.phoronix.com/news/X.Org-DMX-Dropped
> > 
> > https://gitlab.freedesktop.org/xorg/xserver/-/commit/b3b81c8c2090cd49410960a021baf0d27fdd2ab3
> 
> DDX refers to Device-Dependent-X11 driver, the NVIDIA driver provides
> its own binary module for it. Of course, it's also not necessary if
> the NVIDIA driver exposes kernel modesetting, then the regular
> modesetting DDX that Xorg uses by default should be sufficient.
> 
> DMX is something else entirely.

OK , Thanks for the explanation 

I'd like to understand, so what in "X server 21.1" broke ? from this
thread [1] only 340xx driver stopped to work , 390xx supports xorg-21.1

[1]
https://forums.developer.nvidia.com/t/xorg-server-21-1-released-any-eta-on-compatible-nvidia-drivers/193422/4


-- 
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: Updating xorg-x11-server

[Sérgio Basto]

On Thu, 2024-09-05 at 18:54 +0200, Neal Gompa wrote:
> My understanding is the reason we hadn't was because of the NVIDIA
> binary driver. For the desktops that still use X11 and the X11 DDX
> instead of the modesetting driver, that could be a problem if the ABI
> broke.

Here it says, some NVIDIA binary driver needs X11 DDX , that why I
wrote that seems possible re-add X11 DDX 

https://www.phoronix.com/news/DMX-DDX-Dropping-2021
https://www.phoronix.com/news/X.Org-DMX-Dropped

https://gitlab.freedesktop.org/xorg/xserver/-/commit/b3b81c8c2090cd49410960a021baf0d27fdd2ab3
-- 
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: Updating xorg-x11-server

[Sérgio Basto]

On Thu, 2024-09-05 at 22:41 +, Leigh Scott wrote:
> Neal Gompa wrote:
> > > My understanding is the reason we hadn't was because of the
> > > NVIDIA
> > binary driver. 
> 
> It doesn't matter if it breaks 340xx,  it's in a poor state due to
> legacy drm removal.

X11 DDX was remove because, IIRC someone 10 years ago claim that nobody
use it. i.e. As far as I understand the propose of dropping X11 DDX it
was because we have replacement and nobody use it for years etc, so it
was approved. I think if we readd the code, we don't have reason to not
work and is just revert this commit [1] . If we need it for nvidia
340xx legacy drive.

[1]
https://gitlab.freedesktop.org/xorg/xserver/-/commit/b3b81c8c2090cd49410960a021baf0d27fdd2ab3

-- 
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: Updating xorg-x11-server

[Sérgio Basto]

On Thu, 2024-09-05 at 16:54 +0200, Simone Caronni wrote:
> Hi everyone,
> 
> I've noticed that we're really behind on xorg-x11-server releases
> (almost 3 years!) and that by rebasing we would drop tons of
> patches that have already been upstreamed during this time.
> 
> No one that is listed in the maintainer list of that package seems to
> have been active on it for quite some time, so I would like to step
> up (proven packager).
> 
> If there are no objections, I will create an update, make a few tests
> (also at work, where we have plenty of legacy X
> applications, different Nvidia drivers and any possible proprietary
> screen sharing solution to test) and then post an update with a long
> karma threshold for those karma farmers.
> 
> If there are no objections I will proceed starting from the current
> pull request that has been sitting there for a few months now.
> 

I already did the PR 

https://src.fedoraproject.org/rpms/xorg-x11-server/pull-request/21

https://copr.fedorainfracloud.org/coprs/sergiomb/xorg-x11-server/builds/


> Thanks,
> --Simone
> 
> -- 
> You cannot discover new oceans unless you have the courage to lose
> sight of the shore (R. W. Emerson).
> 
> http://xkcd.com/229/
> http://negativo17.org/

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

[EPEL-devel] Can someone approve my msg ? Fwd: Your message to epel-annou...@lists.fedoraproject.org awaits moderator approval

[Sérgio Basto]

Hi,

Can someone approve my msg ?
Thank you 

 Forwarded Message 
From: epel-announce-boun...@lists.fedoraproject.org
To: ser...@serjux.com
Subject: Your message to epel-annou...@lists.fedoraproject.org awaits
moderator approval
Date: 30/08/2024 16:16:55

Your mail to 'epel-annou...@lists.fedoraproject.org' with the subject

    Re: EPEL-8 upgrade Clamav  from 0.103.11 to 1.0.x LTS

Is being held until the list moderator can review it for approval.

The message is being held because:

    The message comes from a moderated member

Either the message will get posted to the list, or you will receive
notification of the moderator's decision.

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

Re: collect2: fatal error: cannot find ‘ld’

[Sérgio Basto]

On Tue, 2024-07-30 at 01:31 +0200, Miro Hrončok wrote:
> On 30. 07. 24 1:20, Miro Hrončok wrote:
> > Hello,
> > 
> > I got build failure of pypy3.9 and pypy3.10 on x86_64 only, with:
> > 
> >  collect2: fatal error: cannot find ‘ld’
> >  compilation terminated.
> > 
> > See the CI results of (the rawhide results):
> > 
> > https://src.fedoraproject.org/rpms/pypy3.9/pull-request/55
> > https://src.fedoraproject.org/rpms/pypy3.10/pull-request/20
> > 
> > This is with binutils 2.42.90-1.fc41
> > 
> > It takes 40+ minutes to failure. Any ideas what might be causing
> > this are 
> > appreciated.
> 
> There is:
> 
> %ifarch %{ix86} x86_64 %{arm}
>    sed -i -r 's/\$\(LDFLAGSEXTRA\)/& -fuse-ld=gold/' 
> ./rpython/translator/platform/posix.py
> %endif
> 
> In the spec. Which might explain why this only happens on x86_64
> (%{ix86} is 
> ExcludeArched, %{arm} is EOL).
> 
> 
> Actually, I see binutils-gold installed in the f40 root.log, but not
> in the 
> rawhide root.log.
> 
> So this is likely the reason it fails, binutils-gold not installed. I
> will 
> BuildRequire it.
> 
> https://src.fedoraproject.org/rpms/binutils/c/2175d42ba13c8999c2cc61813978f66ad8089980
> 
>    Remove "Requires: binutils-gold" from binutils sub-package.
> 
> This was done, but not communicated :(

Hi,

On 21 Jun 2023 4:07 p.m. in devel mailing list was announce the drop of
binutils-gold [1]. 
BTW and regarding this topic, should we start avoid build with golden
linker ? i.e for example, qt5-qtwebengine [2] should we add   
BuildRequires: binutils-gold or should we try built with other linker
(ldd IIRC) ? 

Best regards,  

[2]https://src.fedoraproject.org/rpms/qt5-qtwebengine/c/46c62e5dc1e31dfec74d20d2338f99f5f7abe100?branch=rawhide


[1] 
https://lists.fedorahosted.org/archives/list/devel@lists.fedoraproject.org/thread/QBK4XTL62XVHTVZ6YONOAMWPI5BUVIST/

21 Jun 2023 4:07 p.m. 
Re: PR #47: binutils: drop gold

Hey Nick,

I submitted

https://src.fedoraproject.org/rpms/binutils/pull-request/47

yesterday to not build gold by default.

Creating this thread here to ensure you see this, and also a chance
to
discuss the change via email rather than on the PR.

Cheers,

Amit



> -- 
> Miro Hrončok
> -- 
> Phone: +420777974800
> Fedora Matrix: mhroncok
> 

-- 
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: [Head ups] opencv update to 4.10.0 with a soname bump in rawhide

[Sérgio Basto]

side-tag f41-build-side-92992 pushed to rawhide 

sdrangel doesn't build due a problem with dependencies , gr-funcube
doesn't built with new fmt 

On Thu, 2024-07-25 at 22:22 +0100, Sérgio Basto wrote:
> Hi, 
> 
> from 
> https://bugzilla.redhat.com/show_bug.cgi?id=2290312
> 
> we will rebuild [1] on a side-tag f41-build-side-92992 except python-
> torch I don't expect any problem 
> 
> [1]
> rawhide OpenImageIO
> rawhide YafaRay
> rawhide caffe
> rawhide digikam
> rawhide dtkmultimedia
> rawhide frei0r-plugins
> rawhide gmic
> rawhide gstreamer1-plugins-bad-free
> rawhide libfreenect
> rawhide libopenshot
> rawhide mlt
> rawhide nomacs
> rawhide opencv
> rawhide opentoonz
> rawhide os-autoinst
> rawhide php-facedetect
> rawhide player
> rawhide psmoveapi
> rawhide python-torch
> rawhide qimgv
> rawhide sdrangel
> rawhide simarrange
> rawhide siril
> rawhide spectacle
> 
> 

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

[Head ups] opencv update to 4.10.0 with a soname bump in rawhide

[Sérgio Basto]

Hi, 

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

we will rebuild [1] on a side-tag f41-build-side-92992 except python-
torch I don't expect any problem 

[1]
rawhide OpenImageIO
rawhide YafaRay
rawhide caffe
rawhide digikam
rawhide dtkmultimedia
rawhide frei0r-plugins
rawhide gmic
rawhide gstreamer1-plugins-bad-free
rawhide libfreenect
rawhide libopenshot
rawhide mlt
rawhide nomacs
rawhide opencv
rawhide opentoonz
rawhide os-autoinst
rawhide php-facedetect
rawhide player
rawhide psmoveapi
rawhide python-torch
rawhide qimgv
rawhide sdrangel
rawhide simarrange
rawhide siril
rawhide spectacle


-- 
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: [Java related] packaging Italian ID card middleware

[Sérgio Basto]

Hi,

On Thu, 2024-07-18 at 16:42 +0200, Germano Massullo wrote:
> Hello, I discussed the feasibility of packaging
> https://github.com/italia/cie-middleware-linux
> in Fedora devel Matrix channel with Cristian Le and xvitaly. With the
> help of Cristian Le I wrote the following [1] draft that will be used
> to 
> open an upstream ticket to request various improvements to make it 
> possible to include the software in the Fedora repository.
> We ended up needing the comment from Java package maintainers, if
> they 
> see any other no-go. I am in particular concerned about
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_pre_built_dependencies
> 

I don't know if it helps, I don't know even if the projects are
similar. I did packaging for Portuguese ID [1] , maybe we can join
efforts together , I built it on copr [2] . 

[1] 
https://github.com/sergiomb2/autenticacao.gov_rpms/

[2]
https://copr.fedorainfracloud.org/coprs/sergiomb/pteid-mw/

> Thank you
> 
> [1]: https://germano.fedorapeople.org/canc/cie_middleware.md

-- 
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: Epel8 build with python > 3.6?

[Sérgio Basto]

On Mon, 2024-07-15 at 12:56 +0200, Mark E. Fuller via devel wrote:
>  I want to make a minor update to an EPEL 8 package, but the default
> Python is 3.6 where the update requires >=3.7 
> 
> Is this possible to do (with modules?)? How would I specify it in the
> spec file if it is? 
> 

you have python 3.12 in Centos Stream 8 (without modules) 

dnf install python3.12

rpm -q python3.12 -i 
Name: python3.12
Version : 3.12.1
Release : 4.el8



>  Mark E. Fuller, Ph.D. 
> ful...@fedoraproject.org 
> ful...@mefuller.dev 
> @fuller:fedora.im 
> @fuller:one.ems.host 
> https://mefuller.dev 
> PGP Fingerprint: 73F1 A30C BDF4 DB4B C75F FD0F D599 E76C FFCA BF60 
>  
>  

-- 
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: F42 Change Proposal: Enable Drm Panic (system-wide)

[Sérgio Basto]

On Sun, 2024-07-14 at 12:29 -0500, Ian Pilcher wrote:
> On 7/13/24 4:39 AM, Sérgio Basto wrote:
> > 
> > 
> > if I don't like this functionality, can I have my vt consoles back
> > ?
> > 
> 
> It seems that you will need to compile your own kernel in order to do
> so.
> 

"this is not about enabling or disabling to have VTs/fbcon
but just to make the kernel output its messages on the default VT (tt0
or any other tty? specified with the console= kernel cmdline parameter.
" 

if is just about for where output messages goes it's LGTM 


> -- 
> =
> ===
> If your user interface is intuitive in retrospect ... it isn't
> intuitive
> =
> ===
> 

-- 
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: F42 Change Proposal: Enable Drm Panic (system-wide)

[Sérgio Basto]

if I don't like this functionality, can I have my vt consoles back ? 

and please stop use the argument of the security , I don't know how
write it with nice words , but saying one untested software have better
security that an very old one is not fair to me , is just not a good
argument to me. 

On Fri, 2024-07-12 at 17:53 +0100, Aoife Moloney wrote:
> Wiki - https://fedoraproject.org/wiki/Changes/EnableDrmPanic
> Discussion Thread -
> https://discussion.fedoraproject.org/t/f42-change-proposal-enable-drm-panic-system-wide/125542
> 
> This is a proposed Change for Fedora Linux.
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if
> approved
> by the Fedora Engineering Steering Committee.
> 
> == Summary ==
> Drm_panic is a new feature in the Linux kernel that displays a panic
> screen when a kernel panic occurs. This proposal is to enable
> DRM_PANIC in the Fedora kernel, to improve the kernel panic user
> experience.
> 
> 
> == Owner ==
> 
> * Name: [[User:jfalempe| Jocelyn Falempe]], [[User:Javierm| Javier
> Martinez Canillas]]
> 
> * Email: , 
> 
> 
> == Detailed Description ==
> When the linux kernel panics in Fedora 40, in most cases, the screen
> just freezes.
> If you're in a VT console, you'll be able to see the kernel debug
> information, but that is pretty hard to understand for users that are
> not kernel developers.
> With this feature, they will see a message saying the computer has
> crashed, and they need to reboot the computer.
> Drm_panic has been introduced in kernel v6.10, but is still under
> active development.
> 
> In order to enable DRM_PANIC, you need to disable VT_CONSOLE in the
> kernel, this is to prevent a race condition, that if you are in a VT
> console when the panic occurs, both fbcon and drm_panic will write to
> the framebuffer at the same time, leading to corrupted output.
> https://patchwork.freedesktop.org/series/134831/
> The drawback is that tty0 won't show the kernel kmsg, and it can be
> harder to debug boot issues. But plymouth already takes care of this,
> and can display the boot kmsg when no VT console is present.
> https://gitlab.freedesktop.org/plymouth/plymouth/-/merge_requests/224
> And the user experience would be better, because plymouth has better
> font and color support than fbcon.
> 
> Supported drivers are simpledrm, mgag200, ast, (and imx, tidss, on
> aarch64). I'm working on nouveau support, and I hope i915 and amdgpu
> will add support too.
> If the driver is not supported, you won't see the panic screen, but
> it
> won't be worse than what you have today.
> 
> Drm panic provides different panic screens. The default is "user"
> which will display a simple friendly message telling the user to
> reboot the computer. But for kernel developers, you can also set it
> to
> "kmsg", to see the last kmsg lines (so this is equivalent to the
> current fbcon). You can select the panic screen in Kconfig, or as a
> module parameter (drm.panic_screen=user) or at runtime with "echo -n
> kmsg > /sys/module/drm/parameters/panic_screen"
> 
> I've also made a proof of concept to add a panic screen with a QR
> code
> with debugging information, which will make it easier for users to
> report kernel panic in Fedora. An example can be seen here:
> https://github.com/kdj0c/panic_report/issues/1
> 
> == Feedback ==
> 
> 
> == Benefit to Fedora ==
> This change will improve the user experience when a kernel panic
> occurs.
> 
> It's also a first step to switch to userspace console, and being able
> to disable CONFIG_VT in the kernel.
> VT and fbcon are legacy part of the kernel, that would reduce
> maintenance burden if we can disable them, and
> It will also reduce CVE impact, as userspace vulnerabilities are
> usually less critical.
> 
> == Scope ==
> * Proposal owners:
> 
> Write documentation on how-to debug boot issues without VT_CONSOLE.
> Maybe also change the systemd log configuration, so that it default
> to
> writing the log to the console.
> 
> * Other developers:
> 
> * Release engineering: [https://pagure.io/releng/issues #Releng issue
> number
> 
> I'm unsure if it has impact on the installer.
> 
> * Policies and guidelines: N/A (not needed for this Change)
> 
> * Trademark approval: N/A (not needed for this Change)
> 
> * Alignment with the Fedora Strategy:
> I think it perfectly fit the "Fedora is for everyone" goal, as the
> current kernel panic (either UI freeze or kmsg output in VT) is not
> user-friendly.
> 
> == Upgrade/compatibility impact ==
> Enabling DRM_PANIC should be transparent to user, but disabling
> VT_CONSOLE may have a visible impact.
> Fortunately since Fedora 40, plymouth is able to display the kmsg
> messages.
> 
> For non-graphical boot, you can use systemd.log_target=console
> systemd.log_level=info and remove rhgb and quiet to see the kernel
> boot message.
> 
> But this needs to be document

Re: F41 Change Proposal: Anaconda as native Wayland application (System Wide)

[Sérgio Basto]

On Sat, 2024-07-06 at 08:06 -0400, Neal Gompa wrote:
> On Sat, Jul 6, 2024 at 7:55 AM Sérgio Basto 
> wrote:
> > 
> > On Tue, 2024-06-04 at 10:34 +0200, Hans de Goede wrote:
> > > Hi Ian,
> > > 
> > > On 6/4/24 5:39 AM, Ian Laurie via devel wrote:
> > > > On 6/1/24 1:04 AM, Adam Williamson wrote:
> > > > > On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
> > > > > > To my knowledge it shouldn't be. Fedora Workstation is
> > > > > > already
> > > > > > running
> > > > > > on Wayland by default for quite some time and even Live ISO
> > > > > > is
> > > > > > already
> > > > > > Wayland. To my knowledge Wayland don't have issues with
> > > > > > graphics cards
> > > > > > in general.
> > > > > 
> > > > > GNOME has a fallback mechanism where it automatically runs
> > > > > the
> > > > > X.org
> > > > > session if the Wayland session doesn't work. I believe that
> > > > > is
> > > > > active
> > > > > on the live image. Of course, as telemetry is evil, we have
> > > > > absolutely
> > > > > no idea how many Fedora users actually hit this mechanism.
> > > > 
> > > > One comment I would make is that VirtualBox doesn't *properly*
> > > > support
> > > > Wayland [yet] requiring GNOME to be run as an Xorg session (of
> > > > course
> > > > not an issue for Xfce etc).
> > > 
> > > I'm a bit surprised by this. I use VirtualBox both as host under
> > > a
> > > GNOME
> > > wayland session and the guests inside that VirtualBox host also
> > > use
> > > Wayland.
> > > 
> > > The only feature which I'm aware of which does not work is the
> > > mode
> > > where only the guest windows are shown. Everything else works
> > > fine.
> > > 
> > > What exactly is not working for you when you run a GNOME Wayland
> > > session inside a VirtualBox guest ?
> > 
> > 
> > I think kde sessions and sddm-wayland as guest and VirtualBox as
> > server
> > on KDE , are all broken with wayland
> > 
> > Also this may impact on this subject (Anaconda as native Wayland
> > application)
> > 
> > We receive an email from a user report that reports that:
> > https://lists.rpmfusion.org/archives/list/rpmfusion-us...@lists.rpmfusion.org/thread/XL4XR5X2JAOFV3N2CP2KGA2A7ASLZD5R/?sort=thread
> > 
> > I don't want to start this discussion again, but I think people
> > should
> > be aware of what's going on around them.
> > 
> > And Hans, you are the only person I know who has the knowledge to
> > fix
> > this.
> > 
> 
> For KDE Plasma, you need to enable 3D acceleration (which is not on
> by default).
> 
> See this post:
> https://pointieststick.com/2024/03/08/psa-enable-3d-acceleration-in-your-virtualbox-vms/
> 
> 

For VitualBox as server seems that doesn't work Frédéric replied 

"Thanks for the tip. You are right, I did not have acceleration
enabled. However, it did not help to make it work with wayland." 


> -- 
> 真実はいつも一つ！/ Always, there's only one truth!

-- 
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: F41 Change Proposal: Anaconda as native Wayland application (System Wide)

[Sérgio Basto]

On Tue, 2024-06-04 at 10:34 +0200, Hans de Goede wrote:
> Hi Ian,
> 
> On 6/4/24 5:39 AM, Ian Laurie via devel wrote:
> > On 6/1/24 1:04 AM, Adam Williamson wrote:
> > > On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
> > > > To my knowledge it shouldn't be. Fedora Workstation is already
> > > > running
> > > > on Wayland by default for quite some time and even Live ISO is
> > > > already
> > > > Wayland. To my knowledge Wayland don't have issues with
> > > > graphics cards
> > > > in general.
> > > 
> > > GNOME has a fallback mechanism where it automatically runs the
> > > X.org
> > > session if the Wayland session doesn't work. I believe that is
> > > active
> > > on the live image. Of course, as telemetry is evil, we have
> > > absolutely
> > > no idea how many Fedora users actually hit this mechanism.
> > 
> > One comment I would make is that VirtualBox doesn't *properly*
> > support
> > Wayland [yet] requiring GNOME to be run as an Xorg session (of
> > course
> > not an issue for Xfce etc).
> 
> I'm a bit surprised by this. I use VirtualBox both as host under a
> GNOME
> wayland session and the guests inside that VirtualBox host also use
> Wayland.
> 
> The only feature which I'm aware of which does not work is the mode
> where only the guest windows are shown. Everything else works fine.
> 
> What exactly is not working for you when you run a GNOME Wayland
> session inside a VirtualBox guest ?


I think kde sessions and sddm-wayland as guest and VirtualBox as server
on KDE , are all broken with wayland 

Also this may impact on this subject (Anaconda as native Wayland
application)

We receive an email from a user report that reports that:
https://lists.rpmfusion.org/archives/list/rpmfusion-us...@lists.rpmfusion.org/thread/XL4XR5X2JAOFV3N2CP2KGA2A7ASLZD5R/?sort=thread

I don't want to start this discussion again, but I think people should
be aware of what's going on around them.

And Hans, you are the only person I know who has the knowledge to fix
this.

Thank you and best regards,

> Regards,
> 
> Hans
> 
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, 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: Automatic detection of unused BuildRequires

[Sérgio Basto]

On Wed, 2024-07-03 at 18:02 +0200, Marián Konček wrote:
> > As many of you know, as packages change, so do their BuildRequires.
> > In 
> > the current state, maintaining them requires some manual work from
> > the 
> > maintainer.
> > 
> > 1. So I got around the idea of a simple tool that checks file
> > accesses 
> > during the build and using RPM queries, detects whether some
> > package's 
> > files are not accessed at all therefore the package is not needed
> > for
> > the build. To my knowledge there is no such project. 

yes , no such project and I also think that project may be useful .

I notice with [1] and with new [2] we can check if src requires
something-devel  and the binary don't requires the libsomthing.so.etc 

to exemplify (result in attachment) :
./dep_checker.py --max_deps 0 glib gtk+ libbonoboui libgnome libgnomeui
GConf2  

we got may cases of 
somepackge.src requires GConf2-devel but his bin doesn't requires
libgconf-2.so

I can deduce that we can remove the "Builrequires: GConf2-devel" . But
we have other cases that is not true , like headers packages and things
that used scripts and more cases that I don't recall ATM . So I did't
find any formula or linear method , but I hope that dep_checker.py can
help you , I hadn't finish the development yet ...


[1] 
https://pagure.io/releng/blob/main/f/scripts/orphaned-packages-process
[2]
https://pagure.io/fork/sergiomb/releng/blob/main/f/scripts/orphaned-packages-process/dep_checker.py

> > The project is
> > here: https://github.com/mkoncek/unbreq
> > 
> > It may not be completely reliable, but it also may be good enough
> > to 
> > catch simple mistakes.
> > 
> > 2. At least in the case of maven build system, this tool does not
> > help 
> > with `mvn(foo:bar)` dependencies, as maven unconditionally reads
> > all
> > the 
> > files present in /usr/share/maven-metadata, from which it deduces
> > the
> > associations between jars and artifact coordinates. I imagine other
> > build systems employ a similar strategy.
> > 
> > 3. In the case of maven, we have a manual tool: xmvn-builddep,
> > which 
> > reads the build.log and constructs the actual BuildRequires from
> > it, 
> > using knowledge about the build procedure. This could be used as an
> > additional step of this tool, having similar tools for other
> > languages.
> > 
> > Ultimately, I am interested in the possibility of having automated 
> > unused BuildRequires detection as part of rpmbuild / mockbuild.
> > 


> > -- 
> > Marián Konček
> > 

-- 
Sérgio M. B.
Report started at 2024-07-03 18:46:13 UTC


Depending on: GConf2 (34)
GtkAda
GtkAda-2.24.2-48.fc40.src requires GConf2-devel = 3.2.6-41.fc40

alexandria
alexandria-0.7.9-7.fc40.noarch requires GConf2 = 3.2.6-41.fc40
alexandria-0.7.9-7.fc40.src requires GConf2 = 3.2.6-41.fc40

apcupsd
apcupsd-3.14.14-31.fc40.src requires GConf2-devel = 
3.2.6-41.fc40
apcupsd-gui-3.14.14-31.fc40.x86_64 requires 
libgconf-2.so.4()(64bit)

cdcollect
cdcollect-0.6.0-42.fc40.x86_64 requires GConf2 = 3.2.6-41.fc40

cdrdao
cdrdao-1.2.5-9.fc40.src requires GConf2-devel = 3.2.6-41.fc40

evolution-rspam
evolution-rspam-0.6.0-43.fc40.src requires GConf2-devel = 
3.2.6-41.fc40

florence
florence-0.6.3-23.fc41.src requires GConf2-devel = 3.2.6-41.fc40

gconf-editor
gconf-editor-3.0.1-29.fc40.src requires GConf2-devel = 
3.2.6-41.fc40
gconf-editor-3.0.1-29.fc40.x86_64 requires GConf2 = 
3.2.6-41.fc40, libgconf-2.so.4()(64bit)

gconfmm26
gconfmm26-2.28.3-74.fc41.i686 requires libgconf-2.so.4
gconfmm26-2.28.3-74.fc41.src requires pkgconfig(gconf-2.0) = 
3.2.6
gconfmm26-2.28.3-74.fc41.x86_64 requires 
libgconf-2.so.4()(64bit)
gconfmm26-devel-2.28.3-74.fc41.i686 requires 
GConf2-devel(x86-32) = 3.2.6-41.fc40, pkgconfig(gconf-2.0) = 3.2.6
gconfmm26-devel-2.28.3-74.fc41.x86_64 requires 
GConf2-devel(x86-64) = 3.2.6-41.fc40, pkgconfig(gconf-2.0) = 3.2.6

geany-plugins
geany-plugins-2.0-3.fc40.src requires GConf2-devel = 
3.2.6-41.fc40

gnome-do
gnome-do-0.95.3-27.fc40.src requires GConf2-devel = 
3.2.6-41.fc40
gnome-do-0.95.3-27.fc40.x86_64 requires GConf2 = 3.2.6-41.fc40

gnome-phone-manager
gnome-phone-manager-0.69-45.fc40.src requires GConf2-devel = 
3.2.6-41.fc40
gnome-phone-manager-0.69-45.fc40.x86_64 requires 
libgconf-2.so.4()(64bit)

gnome-sharp
gnome-sharp-2.24.2-34.fc40.x86_64 requires 
libgconf-2.so.4()(64bit)

gnome-vfs2
gnome-vfs2-2.24.4-45.fc40.i686 requires libgconf-2.so.4
gnome-vfs2-2.24.4-45.fc40.src requires GConf2-devel = 
3.2.6-41.fc40
gnom

Re: 2FA policy for provenpackagers is now active

[Sérgio Basto]

On Sun, 2024-06-23 at 09:50 +, Leigh Scott wrote:
> How do I disable this?, it has made kerberos login much harder.
> I'm considering ditching provenpackager rights if that is a
> condition.

This (2FA) is not enforced or checked,


-- 
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: [Node.js] Stepping down as Node.js Maintainer in Fedora

[Sérgio Basto]

On Fri, 2024-05-31 at 07:58 +0200, Felix Schwarz wrote:
> also a huge thank you from my side.
> You did an excellent job to keep nodejs in Fedora!

I'd like send the same message 
- also a huge thank you from my side. 
- You did an excellent job to keep nodejs in Fedora 


-- 
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: F41 Change Deadlines and other important deadlines!

[Sérgio Basto]

Hello,

I saw in key tasks:  "Mass Rebuild: RPMs first, then modules", modules
aren't over ? 
BTW we continue to receive CVE's bugzilla reports on modules for
nextcloud on epel 8 for example , how we stop that ? 

Thank you


On Tue, 2024-06-18 at 09:46 +0100, Aoife Moloney wrote:
> Hi folks,
> 
> 
> A quick reminder that for the F41 development cycle[1], the system-
> wide changes submission deadline is today, June 18th. 
> This does not mean your change has to be accepted, it just means that
> you need to get your proposal filed by this date[2]. So if you are
> thinking of proposing a change, even if it's not fully fleshed out,
> consider submitting it anyway today and make use of our great
> community to iterate on your proposal in real time. 
> The self-contained change proposal deadline is July 16th
> 
> It's important to also note that the 'testable' deadline[3] for
> changes is August 6th, however please be mindful that this is also
> our branching date from Rawhide so it would be preferable to have
> your changes landed in rawhide and available for testing before this
> date. 
> 
> Your change, once approved to F41, landed in Rawhide for branching
> and testable, must then be 100% code complete[4] before we enter Beta
> Freeze on 20th August, or it will most likely need to be retargeted
> to F42.
> 
> Changes that are not code complete by the Beta Freeze date puts a big
> strain on the folks involved with each Fedora release, so by adhering
> to these dates, it helps the overall release process run much
> smoother, we all benefit from a higher quality release and a slightly
> less stressful crunch time at the end :) So thank you in advance for
> getting your changes ready in time for these milestones, it's hugely
> appreciated.
> 
> 
> Please dont hesitate to reach out with questions or if I can be of
> any help.
> 
> 
> Kindest regards,
> Aoife 
> 
> 
> [1] https://fedorapeople.org/groups/schedule/f-41/f-41-key-tasks.html
> [2]
> https://docs.fedoraproject.org/en-US/program_management/changes_policy/
> [3][4]
> https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_change_process_milestones
> 
> 
> -- 
> 
>  
> Aoife Moloney 
>  
> Fedora Operations Architect
>  
> Fedora Project
> Matrix: @amoloney:fedora.im
> IRC: amoloney
> 
>  
> --
> ___
> 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: F41 Change Proposal: GIMP Version 3 (self-contained)

[Sérgio Basto]

On Mon, 2024-06-17 at 14:00 -0400, Przemek Klosowski via devel wrote:
> On 6/17/24 02:39, Vitaly Zaitsev via devel wrote:
> > On 16/06/2024 18:24, Aoife Moloney wrote:
> > > This release of Fedora Linux ships version 3 of the GNU Image
> > > Manipulation Program, with many new features and improved user
> > > experience. The package is called gimp3, the old
> > > version
> > > will still be available under the old name, gimp for
> > > users who need it for existing projects.
> > 
> > +1 to the proposal, but -1 to the quoted statement.
> > 
> > GIMP 3 should go to the gimp package and the gimp2 legacy 
> > compatibility package should be introduced.
> > 
> Vitaly got it right---it should be a major exception to introduce 
> versioned software naming, i.e. only when there are major system-
> level 
> implications, like for Python2->3 transition. I do appreciate that 
> people may have gimp application-level workflows [1] but Fedora
> should 
> not be expected to fix them, given the upstream policy of releasing
> the 
> new GIMP.


I don't agree with you , First where it is write that major release
must be the un-version package ? 

keep gimp2 as gimp and do gimp3 package will not force modify any other
package and we won't have broken things , which may happen if you build
one package for gimp2 when there is gimp3 already and no one notice,
but that is my opinion . 

Historically we got some cases , like wxGTK, wxGTK3, openjpeg and
openjpeg2  ( btw openjpeg is not used by any package and openjpeg2
should move to openjpeg ) 


> Speaking of gimp2, it looks like the GIMP upstream is planning to 
> publish a gimp 2.10.x stable branch 
> https://developer.gimp.org/core/roadmap/ but with a low priority.
> 
> [1] obligatory XKCD reference: https://m.xkcd.com/1172/
> --
> ___
> 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: F41 Change Proposal: Nvidia Driver Installation with Secure Boot Support (self-contained)

[Sérgio Basto]

On Mon, 2024-06-17 at 12:44 +0100, Aoife Moloney wrote:
> Wiki -
> https://fedoraproject.org/wiki/Changes/NvidiaInstallationWithSecureboot
> Discussion Thread -
> https://discussion.fedoraproject.org/t/f41-change-proposal-nvidia-driver-installation-with-secure-boot-support-self-contained/120330
> 
> This is a proposed Change for Fedora Linux.
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if
> approved
> by the Fedora Engineering Steering Committee.
> 
> 
> == Summary ==
> 
> Nvidia Drivers have been removed from GNOME Software because it
> didn't
> support Secure Boot which is increasingly often enabled. This change
> brings the option back with Secure Boot supported.
> 
> == Owner ==
> 
> * Name: [[User:eischmann|Jiří Eischmann]]
> * Name: Milan Crha
> 
> * Email: eischm...@redhat.com
> * Email: mc...@redhat.com
> 
> 
> == Detailed Description ==
> 
> The goal is this change is to provide an easy way to install Nvidia
> drivers in Fedora Workstation. It was removed from GNOME Software
> because the original mechanism didn't support Secure Boot. When users
> installed the drivers with Secure Boot enabled, they could not boot
> the OS.
> What we're doing this time is using mokutil to create a key for the
> user to self-sign the drivers. When installing the drivers, the user
> is asked to provide a password for the key. On the next reboot the
> user is presented with the mokutil interface to enroll the key.

I don't know if you are aware akmods already support secure boot since
F36 [1] and in "Importing the key" is described on enroll the public
self sign key 


[1]
https://rpmfusion.org/Howto/Secure%20Boot




> See the
> [https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/2034
> upstream merge request] for more details and screenshots.
> 
> == Feedback ==
> 
> 
> == Benefit to Fedora ==
> The Nvidia drivers are necessary not only for gaming, but especially
> for CUDA and AI/LLM workloads. The Nvidia drivers can't be part of
> Fedora because of their license, but Fedora should offer an easy
> installation of them to stay relevant in the respective fields.
> 
> == Scope ==
> 
> * Proposal Owners: The feature will be implemented in GNOME Software
> 47 and will be shipped in the gnome-software package in Fedora Linux
> 41.
> 
> * Other Developers: No work required from other Fedora developers.
> The
> only requirement outside of the scope of the proposal owners is to
> reintroduce AppStream metadata into the Nvidia driver repo on
> RPMFusion.org.
> 
> * Release Engineering:
> 
> * Policies and Guidelines:
> 
> * Trademark approval:
> 
> * Alignment with Community Initiatives:
> 
> == Upgrade/compatibility impact ==
> 
> No impact is expected.
> 
> == How To Test ==
> 
> 1. Open GNOME Software.
> 2. Search for "nvidia".
> 3. Choose the Nvidia driver, click Install and follow the
> prompts.
> 4. Reboot and enroll the self-signing key in the mokutil tool
> following <>
> 5. The OS should boot up with the Nvidia driver enabled.
> 
> == User Experience ==
> 
> This change aims to improve user experience of installing the
> proprietary Nvidia driver.
> 
> == Contingency Plan ==
> If the feature is not implemented on time for Fedora Linux 41, we can
> simply remove AppStream metadata from the Nvidia driver repo and the
> driver will not show up in GNOME Software like in Fedora Linux 40.
> 
> == Documentation ==
> The GNOME Software part is intuitive and doesn't require
> documentation. The mokutil part is less intuitive and will be
> documented in the Fedora Workstation section on
> docs.fedoraproject.org. The docs will be published when the feature
> lands in Fedora Linux 41.
> 
> == Release Notes ==
> 
> -- 
> Aoife Moloney
> 
> Fedora Operations Architect
> 
> Fedora Project
> 
> Matrix: @amoloney:fedora.im
> 
> IRC: amoloney
> --
> ___
> 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://p

Re: F41 Change Proposal: Anaconda as native Wayland application (System Wide)

[Sérgio Basto]

On Tue, 2024-06-11 at 19:48 +0200, Marc Deop i Argemí wrote:
> On Tuesday 11 June 2024 14:52:19 CEST Sérgio Basto wrote:
> 
> I had enough with you an your attitude. You have been abusing the
> good will 
> and temperament of many Fedora contributors for too long. Somebody
> must put a 
> stop to your comments and behavior.
> 
> > If you can't support X11 together with Wayland on boot.iso , why
> > you
> > want move to Wayland ?
> 
> The explanation to this is very clearly explained in the == Detailed 
> Description === section




> > it is stupid break Linux user experience just
> > because Wayland is fancy , 
> 
> Refrain from calling our actions or (implicitly) our contributors
> _stupid_
> 

I don't want that you deduce that.

OK I 'll try be more inclusive BTW I confused you with user moceap.
yeah I think try removing X11 is not right path that is my opinion.
And you don't have the right of remove X11 software from Fedora .
You aren't adding software, you are trying removing X11 and impose
Wayland because, I think,  you want that people test wayland, you think
if people test more, the things will be fixed by them self but I don't
think that is true, see the case of btrfs , still missing core
functionalities, hopefully nobody tried to remove ext4. 
Moreover I won't test wayland, wayland simple is not ready for me. I
don't use wayland and I want maintain X11 

About benefit to Fedora
https://fedoraproject.org/wiki/Changes/Anaconda_As_Native_Wayland_Application#Benefit_to_Fedora

- RDP is more secure that VNC ? this is not an argument, and typically
is not an honest argument. VNC works over ssh, is more light, is more
quick and is better in all aspect that I can think of. So RDP is not a
benefit is an escape to VNC problem .  
 
- This change will enable removal of X11 dependencies from the Anaconda
which may result in reduction of installed software ? you don't even
know if reduce the installed software , so in my conclusion also is not
an argument . 

So zero benefits to Fedora, on other hand any old computer with a
graphic where drives don't support wayland will have problems .


So is the same problem of kde-X11 and is not just me, several people
already state the same. 

And I'd like discuss this 

> That is just not acceptable. Period.

What for me is not acceptable disable kwin-x11, just because yes  , and
give a bunch of work to the others , everywhere forum,  discourse ,
chat , email bugzilla, we have to explain what happened , with X11 ,
how reinstall X11 , so is just not me . 

> Not to mention that nobody is breaking any user experience. Your mind
> is so 
> distorted that whenever you see "Wayland" you get immediately
> triggered and 
> you fight whatever is going on in the discussion.

The problem is not Wayland , the problem is remove X11, and the x11
experience . If you enable wayland but keep X11 as fallback I hadn't
any problem .



> > what we get with Wayland that we don't get
> > with X11 ?
> 
> This has been explained so many times that the fact that you keep
> asking this 
> over and over and over is just making you look like somebody one
> cannot have a 
> conversation with.
> 
> > if you need remove X11 to add Wayland, don't do it ! . 
> 
> Again, the reasoning has been explained in the == Detailed
> Description == 
> section
> 
> > Don't
> > break the other Linux user systems . 
> 
> Nobody is breaking anything. Stop spreading FUD.

No, is not FUD, because we got this experience in Fedora 40, _all_ old
nvidia drives simple don't support wayland .

> > Is difficult understand that you
> > should not remove components without agreement of everyone ?
> > 
> 
> yes, sure, like absolutely everything in our society needs to be
> agreed by  
> 100% of the people. Of course.
> 
> Do you realize how non nonsensical that sounds

Until a few weeks ago, there was always agreement and consensus among
everyone, here in Fedora, in 20 years I don't remember any discussion
like these one. 


> > Linux should support all kind of hardware, if Wayland don't, you
> > should
> > provide at least fall backs , and not just ignore the others .
> 
> That is only *your* view. Please explain me why I cannot install
> Fedora in my 
> AMD K6-2 or my Pentium 200 MMX (because I cannot, it is not supported
> anymore).
> 
> Linux should support all kind of hardware, right?
> ¯\_(ツ)_/¯

:thumbs up:

> > 
> > The removal of X11 from KDE , just because KDE SIG decide without
> > consent of many members of Fedora which contribute to Fedora KDE ,
> > should not be acceptable .
> 
> Why on earth would you bring this here? I am not sure you can
> u

Re: F41 Change Proposal: Anaconda as native Wayland application (System Wide)

[Sérgio Basto]

On Tue, 2024-06-04 at 14:26 +0200, Jiri Konecny wrote:
> On 04. 06. 24 5:39, Ian Laurie via devel wrote:
> > On 6/1/24 1:04 AM, Adam Williamson wrote:
> > > On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
> > > > To my knowledge it shouldn't be. Fedora Workstation is already
> > > > running
> > > > on Wayland by default for quite some time and even Live ISO is
> > > > already
> > > > Wayland. To my knowledge Wayland don't have issues with
> > > > graphics cards
> > > > in general.
> > > 
> > > GNOME has a fallback mechanism where it automatically runs the
> > > X.org
> > > session if the Wayland session doesn't work. I believe that is
> > > active
> > > on the live image. Of course, as telemetry is evil, we have
> > > absolutely
> > > no idea how many Fedora users actually hit this mechanism.
> > 
> > One comment I would make is that VirtualBox doesn't *properly*
> > support
> > Wayland [yet] requiring GNOME to be run as an Xorg session (of
> > course
> > not an issue for Xfce etc).
> > 
> > If Anaconda is to be Wayland, my concern is that it may make all
> > DEs
> > uninstallable, even ones like Xfce far removed from Wayland.
> > 
> You should be able to install from Live ISO which we are not
> modifying 
> (depends on environment set by SIG owners). However, we won't support
> X11 together with Wayland on boot.iso. That would be hard to achieve 
> given to the big amount of changes we are required to do now to
> support 
> Wayland.


If you can't support X11 together with Wayland on boot.iso , why you
want move to Wayland ? it is stupid break Linux user experience just
because Wayland is fancy , what we get with Wayland that we don't get
with X11 ? if you need remove X11 to add Wayland, don't do it ! . Don't
break the other Linux user systems . Is difficult understand that you
should not remove components without agreement of everyone ? 

Linux should support all kind of hardware, if Wayland don't, you should
provide at least fall backs , and not just ignore the others .

The removal of X11 from KDE , just because KDE SIG decide without
consent of many members of Fedora which contribute to Fedora KDE ,
should not be acceptable .

Waste my energy discussing things that should be obvious , make me
think if I still should contribute to this project . 

Like Linus says "DON'T BREAK THE USER SPACE"

Best regards, 

> Jirka
> > -- 
> > 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
> --
> ___
> 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: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

[Sérgio Basto]

On Mon, 2024-05-06 at 13:56 +0200, Florian Festi wrote:
> As this change does not affect the resulting binary packages an
> immediate rebuild is not needed. The change will "only" ensure the
> packages still build with the new version of RPM.

I think you should rebuild the packages because at the moment , koschei
[1] is saying that all that 1800 packages are FTBFS 

[1] 
https://koschei.fedoraproject.org/


Best regards,
-- 
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: F41 Change Proposal: Anaconda as native Wayland application (System Wide)

[Sérgio Basto]

On Fri, 2024-05-31 at 08:04 -0700, Adam Williamson wrote:
> On Fri, 2024-05-31 at 13:36 +0200, Jiri Konecny wrote:
> > To my knowledge it shouldn't be. Fedora Workstation is already
> > running 
> > on Wayland by default for quite some time and even Live ISO is
> > already 
> > Wayland. To my knowledge Wayland don't have issues with graphics
> > cards 
> > in general.
> 
> GNOME has a fallback mechanism where it automatically runs the X.org
> session if the Wayland session doesn't work. I believe that is active
> on the live image. Of course, as telemetry is evil, we have
> absolutely
> no idea how many Fedora users actually hit this mechanism.

TL;DR; if you may fallback to X11 , I don't have problems. 
If we don't have way to use X11 , is just break Linux for many users 

-- 
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: Node.js 22.x coming to Rawhide/F41

[Sérgio Basto]

On Sun, 2024-05-26 at 21:29 +0200, Robert-André Mauchin wrote:
> On 21/05/2024 15:53, Stephen Gallagher wrote:
> > tl;dr I screwed up and accidentally made two critical mistakes:
> > 
> > 1) Node.js 22 got into Rawhide as the default early. I'm not sure
> > of
> > how to back that out safely.
> > 2) A change made in Node.js 20 to split out two libraries
> > (cjs-module-lexer and undici) that we were bundling in prior
> > releases
> > has introduced issues with Node.js 22 because it can't find them
> > (and
> > the ones from Node.js 20 are older). I'll probably re-bundle them
> > in
> > the short term to unbreak things.
> 
> Hello,
> 
> Do we have a fix for this, I still see several package failure. Do we
> have to change something in dependent SPEC?
> 

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

nodejs22-22.2.0-9.fc41 works for me 

> Thanks,
> 
> Robert-André
> --
> ___
> 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: Announcement: pagure release 5.14.1 available

[Sérgio Basto]

On Fri, 2024-05-24 at 16:55 +0200, Dominik Wombacher wrote:
> [4] https://src.fedoraproject.org/rpms/pagure

good news and thanks, I want to test in my local machine,  to do that I
need the package updated, please add some builds .

Best regards,
-- 
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: Node.js 22.x coming to Rawhide/F41

[Sérgio Basto]

Hi,
Since the thread is in top posting, I will top posting too ... 

I also saw a "Native stack trace" [1] on Rawhide on nodejs-electron [2]

Best regards,

[2]
https://copr.fedorainfracloud.org/coprs/sergiomb/electrons/build/7462286/

[1]
[432/39358] python3 ../../tools/polymer/html_to_wrapper.py --in_folder
gen/components/flags_ui/resources/preprocessed --out_folder
gen/components/flags_ui/resources/preprocessed --in_files
experiment.html app.html --template native --minify
FAILED:
gen/components/flags_ui/resources/preprocessed/experiment.html.ts
gen/components/flags_ui/resources/preprocessed/app.html.ts 
python3 ../../tools/polymer/html_to_wrapper.py --in_folder
gen/components/flags_ui/resources/preprocessed --out_folder
gen/components/flags_ui/resources/preprocessed --in_files
experiment.html app.html --template native --minify
Traceback (most recent call last):
  File
"/builddir/build/BUILD/src/out/Release/../../tools/polymer/html_to_wrap
per.py", line 242, in 
main(sys.argv[1:])
  File
"/builddir/build/BUILD/src/out/Release/../../tools/polymer/html_to_wrap
per.py", line 175, in main
raise err
  File
"/builddir/build/BUILD/src/out/Release/../../tools/polymer/html_to_wrap
per.py", line 170, in main
node.RunNode(
  File "/builddir/build/BUILD/src/third_party/node/node.py", line 34,
in RunNode
raise RuntimeError('Command \'%s\' failed\n%s' % (' '.join(cmd),
err))
RuntimeError: Command
'/builddir/build/BUILD/src/third_party/node/linux/node-linux-
x64/bin/node
/builddir/build/BUILD/src/out/Release/../../tools/polymer/html_minifier
.js
/builddir/build/BUILD/src/out/Release/gen/components/flags_ui/resources
/preprocessed
/builddir/build/BUILD/src/out/Release/gen/components/flags_ui/resources
/preprocessed/tmpf1m6ift1 experiment.html app.html' failed
Cannot load externalized builtin: "internal/deps/cjs-module-
lexer/lexer:/usr/lib/node_modules/cjs-module-lexer/lexer.js".
- Native stack trace -

 1: 0x7f16cd92a585
node::builtins::BuiltinLoader::AddExternalizedBuiltin(char const*, char
const*) [/lib64/libnode.so.127]
 2: 0x7f16cd92a763 node::builtins::BuiltinLoader::BuiltinLoader()
[/lib64/libnode.so.127]
 3: 0x7f16cd88ee61 node::InitializePrimordials(v8::Local)
[/lib64/libnode.so.127]
 4: 0x7f16cd88efa0 node::GetPerContextExports(v8::Local)
[/lib64/libnode.so.127]
 5: 0x7f16cd88ed68 node::InitializePrimordials(v8::Local)
[/lib64/libnode.so.127]
 6: 0x7f16cd88f080
node::InitializeMainContextForSnapshot(v8::Local)
[/lib64/libnode.so.127]
 7: 0x7f16cd88f0a5 node::InitializeContext(v8::Local)
[/lib64/libnode.so.127]
 8: 0x7f16cd88f109 node::NewContext(v8::Isolate*,
v8::Local) [/lib64/libnode.so.127]
 9: 0x7f16cd9aa564
node::NodeMainInstance::CreateMainEnvironment(node::ExitCode*)
[/lib64/libnode.so.127]
10: 0x7f16cd9aa6bb node::NodeMainInstance::Run()
[/lib64/libnode.so.127]
11: 0x7f16cd90d85f node::Start(int, char**) [/lib64/libnode.so.127]
12: 0x7f16ccbb81c8  [/lib64/libc.so.6]
13: 0x7f16ccbb828b __libc_start_main [/lib64/libc.so.6]
14: 0x55af7f18a035 _start
[/builddir/build/BUILD/src/third_party/node/linux/node-linux-
x64/bin/node]



On Tue, 2024-05-21 at 11:26 +0200, Sandro Mani wrote:
> I also get a crash when running npm install: 
> https://bugzilla.redhat.com/show_bug.cgi?id=2282103
> 
> Sandro
> 
> On 21.05.24 09:57, Vít Ondruch wrote:
> > It seems that it breaks at least two of my packages unfortunately:
> > 
> > https://koschei.fedoraproject.org/package/rubygem-ejs
> > 
> > https://koschei.fedoraproject.org/package/rubygem-execjs
> > 
> > The former is using the latter, so the real issue is likely in the 
> > latter. I don't have cycles to investigate more :(
> > 
> > BTW these are likely used in some other components of Ruby on
> > Rails, 
> > so the potential for breakage is higher. But Koschei is
> > experiencing 
> > some issue, so hard to tell.
> > 
> > 
> > Vít
> > 
> > 
> > 
> > Dne 17. 05. 24 v 14:28 Stephen Gallagher napsal(a):
> > > As of today, I have built Node.js 22.2.0 for Fedora Rawhide. It
> > > is
> > > currently available as a non-default package (Node.js 20 remains
> > > the
> > > default during this short transition period).
> > > 
> > > If you maintain a package that depends on Node.js (either runtime
> > > or
> > > build-time), please take some time in the next week or so to
> > > verify
> > > whether it continues to work properly with Node.js 22. I plan to
> > > switch the default in Rawhide over to 22.x as per the
> > > recently-approved Change[1] on or shortly after May 27th.
> > > 
> > > If you encounter a significant problem with Node.js 22, please
> > > contact
> > > the nod...@fedoraproject.org mailing list and we will try to help
> > > you.
> > > 
> > > 
> > > [1] https://fedoraproject.org/wiki/Changes/Nodejs22
> > > -- 
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to
> > > devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct: 
> > > http

Re: Intent to start ARC investigation git-forge replacement

[Sérgio Basto]

On Tue, 2024-04-23 at 12:06 +0200, Tomas Hrcka wrote:
>  1. Suitability for dist-git and src.fedoraproject.org replacement

Can someone explain me what is the problem of pagure ? 

please join to 
https://discussion.fedoraproject.org/t/2024-git-forge-evaluation/111795/20

Thanks 
-- 
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: When is Fedora 38 going EOL?

[Sérgio Basto]

On Tue, 2024-05-14 at 14:53 +0200, Miro Hrončok wrote:
> Hi,
> 
> When is Fedora 38 going EOL?
> 
> https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html say
> s today
> https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html say
> next week
> 
> Which one is correct?

Bodhi says: 

The following releases are appoaching End-Of-Life:

Fedora 38 Containers will go EOL on 2024-05-21
Fedora 38 Flatpaks will go EOL on 2024-05-21
Fedora 38 Modular will go EOL on 2024-05-21
Fedora 38 will go EOL on 2024-05-21 

Consider that before submitting any update for those release



> 
> Thanks,
> -- 
> Miro Hrončok
> -- 
> Phone: +420777974800
> IRC: mhroncok
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, 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: GIMP 3.0 in F41?

[Sérgio Basto]

On Sun, 2024-05-12 at 17:00 -0600, Neal Gompa wrote:
> On Sun, May 12, 2024 at 4:59 PM Sérgio Basto 
> wrote:
> > 
> > 
> > 
> > https://src.fedoraproject.org/rpms/gimp3
> > 
> 
> What the heck? This should have been gimp2 for the old version, not
> gimp3 for the new version...

Well I'm thinking how build imageMagick 7 on epel 9 

could be an idea , So you suggest on epel9, ImageMagick move to
ImageMagick6 ? and build imagemagick 7 on imagemagick ?  






> 
> -- 
> 真実はいつも一つ！/ Always, there's only one truth!
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, 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: GIMP 3.0 in F41?

[Sérgio Basto]

https://src.fedoraproject.org/rpms/gimp3



On Wed, 2024-05-08 at 20:43 +0200, Josef Řídký wrote:
> I believe once the GIMP 3.0 is out the Fedora version will follow
> almost immediately.
> 
> Josef
> GIMP co-maintainer 
> 
> Dne po 6. 5. 2024 22:13 uživatel Dominik 'Rathann' Mierzejewski
>  napsal:
> > Hi!
> > 
> > I noticed that GIMP 3.0 is scheduled[1] for release in June. It'd
> > be
> > nice to have it in F41. Are there any plans to do so? Do the
> > maintainers
> > (Cc'd) need any help?
> > 
> > [1] https://gitlab.gnome.org/GNOME/gimp/-/issues/10373#timeline
> > 
> > Regards,
> > Dominik
> > --
> > ___
> > 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: The GRUB2 Bootloader – Installation and Configuration

[Sérgio Basto]

On Sat, 2024-05-04 at 07:53 +0200, Peter Boy wrote:
> 
> 
> > Am 04.05.2024 um 05:41 schrieb Sérgio Basto :
> > 
> > Hi, 
> > About this documentation [0], finally talks about rescue a
> > bootloader
> > with live images ... (but I will wrote about that in another time)
> 
> That doc is quite old, last review 2012-05-11! As a member of the
> docs board it tried to get it updated by an expert Fedorian,
> unfortunately without success. Grub changes only slowly and
> carefully. Basically, the text is still OK in my opinion, but some
> things are missing. 
> 
> 
> > I run in trouble on cloning a disk from an old computer and
> > starting
> > booting on a new computer , security get the thing more
> > complicated, I
> > had to disable secure boot and selinux not sure , but I advice boot
> > with kernel parameter selinux=0
> 
> To set selinux=0 is a bad idea. All the issues you describe have
> nothing to do with selinux.
> 
> > my old computer was bios legacy and the new have UEFI and here
> > starts
> > the challenge .
> 

also this documentation can be wrong 
https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/kernel-module-driver-configuration/Working_with_the_GRUB_2_Boot_Loader/#sec-grub2-reinstall_on_UEFI-Based_Machines


> That’s really a challenge. You don’t describe what you did in detail.

I did some notes, some years ago on https://www.serjux.com/clone/ and I
will update it after write this email .

First I installed Fedora 39 on new computer with an usb stick with
Network Install iso , is only useful to make the partitions ...
After I just copied the disks from old computer to the new computer
over the network, something like this [1] to an /mnt/new directory, in
old computer previously I logged out all sessions and run as root init
3.
After with same "Network Install iso", I boot again in new computer but
in rescue mode and I delete root and boot of the previous installation
and move data (of old computer) from /mnt/new folder to / and /boot 

The next is just change on /etc/fstab the new location of / and /boot
[2], ATM we also need edit /etc/kernel/cmdline [3] with the same new
location of root partition.

and reboot again several times in rescue mode, until restore the GRUB2
Bootloader  ,

Notes for boot into rescue mode :

As I mention I disable secured boot on bios and think I needed to boot
"Network Install iso" with selinux=0 in grub command line [4].  
 
if /etc/fstab doesn't have the correct paths, we may not have LVM
active, so to activate it we need run : `lvm vgchange -a y`

disable bell: `rmmod pcspkr`
change keyboard layout: `loadkeys pt`

chroot /mnt/sysimage/ or chroot /mnt/sysroot (it will be printed by
rescue system) 
 
dnf reinstall shim-* grub2-efi-* grub2-common (where I think is
important boot with selinux=0 or else you may got spurious messages
[4])

grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

grubby --info=ALL


[1]
mkdir /mnt/new
cd /mnt/new/
ssh root@192.168.1.102 "dump -0 -f - / " | cat - | restore -r -f -
ssh root@192.168.1.102 "dump -0 -f - /boot " | cat - | restore -r -f - 

[2]
/dev/mapper/fedora_legion-root / ext4defaults1 1
UUID=a5d616ff-f93c-4887-9b8f-7895628ff787 /boot  ext4defaults 
1 2

[3]
root=/dev/mapper/fedora_legion-root ro audit=0 selinux=0

[4]
https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/kernel-module-driver-configuration/Working_with_the_GRUB_2_Boot_Loader/#sec-Terminal_Menu_Editing_During_Boot

edit menu during the boot to add selinux=0 
 
> But the first think is that you can’t clone the disk. Your old BIOS
> boot system probably uses an MBR partition scheme. Your new computer
> with UEFI, on the other hand, requires a GPT partitioning scheme. 
> 
> You will have to make a lot of manual adjustments to transfer the
> system. 
> You can convert your disk to GPT [a]. I never did this and I’m
> wondering how successful it works. 
> 
> 
> I never did this, but I guess the best option is to keep your new
> computer on UEFI, do a complete new installation, but use ANACONDA
> from the live image to replace btrfs by a LVM system reproducing your
> old LVM partitions as close as possible and use grub2 (maybe you have
> to use the everything net install medium). When the system boots,
> clone your LVM partitions (each partition separately, not the
> complete disk). Most importantly you should preserver the respective
> partition numbers. And find out what else to adjust (e.g. the uuids).
> That will we a lot of work, I guess. 
> 
> 
> 
> 
> 
> [a]
> https://serverfault.com/questions/963178/how-do-i-convert-my-linux-disk-from-mbr-to-gpt-with-uefi/963179#

The GRUB2 Bootloader – Installation and Configuration

[Sérgio Basto]

Hi, 
About this documentation [0], finally talks about rescue a bootloader
with live images ... (but I will wrote about that in another time) 

I run in trouble on cloning a disk from an old computer and starting
booting on a new computer , security get the thing more complicated, I
had to disable secure boot and selinux not sure , but I advice boot
with kernel parameter selinux=0

my old computer was bios legacy and the new have UEFI and here starts
the challenge .

I think just after do the lvm steps (my disks have lvm partitons) [1] I
start to boot correctly and the problem (I think) was that I need to
run one time 
'grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg' . I think is wrong 
use grub2-mkconfig -o /boot/grub2/grub.cfg , like it is wrote on grub2
on a uefi system [2], should we fix it ? and the advice of boot with
selinux=0 ? 

Best regards,

[0]
https://docs.fedoraproject.org/en-US/quick-docs/grub2-bootloader/

[1]
https://docs.fedoraproject.org/en-US/quick-docs/grub2-bootloader/#_lvm_steps
 
[2]https://docs.fedoraproject.org/en-US/quick-docs/grub2-bootloader/#_installing_grub2_on_a_uefi_system
-- 
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

orphaning wdune

[Sérgio Basto]

Hi, 

wdune is FTBFS on F40 and FTI on F41 and I haven't time to fix it 

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

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

Best regards, 
-- 
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: Picking up protobuf

[Sérgio Basto]

On Wed, 2024-04-17 at 21:51 -0500, Michel Lind wrote:
> Hi all,
> 
> protobuf was recently orphaned without any announcement to this list.
> 
> I've picked it up since et depends on it.
> 

Update protobuf is a huge task 

see https://src.fedoraproject.org/rpms/protobuf/pull-request/26 ( move
from protobuf-3.19.6 to 3.25.1 ) 

I think we should try enforce the update on rawhide , and just after
look to protobuf-3.26.

Best regards,

-- 
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: clang: error: unsupported argument 'gnu2' to option '-mtls-dialect=' for target 'x86_64-redhat-linux-gnu'

[Sérgio Basto]

On Mon, 2024-04-15 at 10:55 +0100, Richard W.M. Jones wrote:
> 
> Anyone got any idea about this build failure?
> 

I think is this bug https://bugzilla.redhat.com/show_bug.cgi?id=2263180


> https://koji.fedoraproject.org/koji/taskinfo?taskID=116395331
> 
> [+] All set and ready to build.
> clang: warning: -Wl,-z,relro: 'linker' input unused [-Wunused-
> command-line-argument]
> clang: warning: -Wl,--as-needed: 'linker' input unused [-Wunused-
> command-line-argument]
> clang: warning: -Wl,-z,pack-relative-relocs: 'linker' input unused [-
> Wunused-command-line-argument]
> clang: warning: -Wl,-z,now: 'linker' input unused [-Wunused-command-
> line-argument]
> clang: warning: -Wl,--build-id=sha1: 'linker' input unused [-Wunused-
> command-line-argument]
> clang: warning: -ldl: 'linker' input unused [-Wunused-command-line-
> argument]
> clang: warning: -lrt: 'linker' input unused [-Wunused-command-line-
> argument]
> clang: warning: -lm: 'linker' input unused [-Wunused-command-line-
> argument]
> clang: error: unsupported argument 'gnu2' to option '-mtls-dialect='
> for target 'x86_64-redhat-linux-gnu'
> 
> AFAICT -mtls-dialect=gnu2 is not added by anything in the spec file
> or
> in AFL++ sources, so it must be coming from RPM macros?
> 
> 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

-- 
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: convert everything to rpmautospec?

[Sérgio Basto]

On Sun, 2024-04-07 at 15:15 +, Zbigniew Jędrzejewski-Szmek wrote:
> Hi everyone,
> 
> I'm revisting the topic of rpmautospec because I was doing some work
> on various packages, and it's annoying that some packages are using
> rpmautospec and others are not.
> 
> All my packages have been converted, so in day-to-day work, I don't
> even think about %changelog. When working with other packages, I'll
> forget to update the Relase and/or %changelog. Today I was rebasing
> some pull requests in pagure, and the _only_ conflicts that I had
> were
> about Release and %changelog.
> 
> I think it's time to switch to rpmautospec completely.
> Thus, the proposal:
> - new packages MUST use rpmautospec
> - packagers SHOULD convert their packages
> - provenpackagers MAY convert existing packages
>   (e.g. when they want to push some fix or separately from other
>    work)
> - people submitting pull requests against src.fp.o MAY also
>   include a conversion in the pull request and packagers SHOULD
>   merge it.
> 
> (FTR, 'rpmautospec convert' does the conversion, incl. the commit
> to dist-git. Manual conversion should not be used.)


I also still see some issues in %autorelease , why fix a typo is a new
release ? 

in  %{forgesource} , as I mention in 
https://src.fedoraproject.org/rpms/rawstudio/pull-request/2#comment-167038
"forge date should be the date of the last commit upstream of upstream
git (i.e. git log -1 --format=%cd --date=short | tr -d -)" 

and the most important, I don't see "great" benefits and give me more
work . 

Best regards,
-- 
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: So you can't just copy 'sources' from one package to another?

[Sérgio Basto]

On Fri, 2024-03-08 at 16:19 +, Richard W.M. Jones wrote:
> For mingw-* packages we (sometimes) have a separate package from the
> native package, eg. libgcrypt vs mingw-libgcrypt.  Therefore two
> different packages are sometimes built with the exact same sources.
> 
> However I discovered copying 'sources' (ie the file) from libgcrypt
> dist-git to mingw-libgcrypt dist-git alone isn't sufficient to get
> the
> package to build.  You still have to download the source tarballs in
> libgcrypt, copy them to mingw-libgcrypt, and 'fedpkg new-sources
> ' to upload them again.
> 
> Isn't the lookaside cache shared across the whole of Fedora?
> 
> (This doesn't matter, I was just wondering aloud.)


you may request an RFE on fedpkg-minimal [1] , fedpkg-minimal is
responsible for download the sources of the packages when koji starts
the builds. Take a look in fedpkg-base [2] is a very simple script , 
It shouldn't be difficult do what you ask, I think, it will be more
complicated define the concept and be accepted by upstream . 

Best regards


[1]
https://pagure.io/fedpkg-minimal 

[2]
https://pagure.io/fedpkg-minimal/blob/master/f/bin/fedpkg-base

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

shogun-data should be retired since shogun is retired

[Sérgio Basto]

Hi, 
Some days ago I notice that shogun-data still in Fedora [1] but shogun
is retired for 4 years [2], just run `fedpkg retire DESCRIPTION` is
enough ? 

Thank you, 

[1]
https://src.fedoraproject.org/rpms/shogun-data 
[2]
https://src.fedoraproject.org/rpms/shogun
-- 
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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Sérgio Basto]

On Tue, 2024-03-19 at 14:22 +0100, Allan via devel wrote:
> På Tue, 19 Mar 2024 09:09:26 -0400
> "Garry T. Williams"  skrev:
> > On Monday, March 18, 2024 4:46:01 PM EDT Sérgio Basto wrote:
> > > On Mon, 2024-03-18 at 16:17 -0400, Garry T. Williams wrote:  
> > > > On Wednesday, February 7, 2024 4:06:46 AM EDT Kevin Kofler via
> > > > devel wrote:  
> > > > > Garry T. Williams wrote:  
> > > > > > I hope my report can be resolved before I am forced to use
> > > > > > Wayland.  
> > > > > 
> > > > > You will not be forced to use Wayland. Stay tuned.  
> > > > 
> > > > In an effort to test a Wayland bug I reported upstream, I
> > > > upgraded my laptop to f40.  (I am holding off on upgrading my
> > > > workstation.)  My reported bug is still there, but here I am
> > > > without x11.  I installed kwin-x11.  My login screen no longer
> > > > offers to run it instead of kwin-wayland.   Is there a way to
> > > > run
> > > > x11 on f40?  (There are still several annoying bugs in Wayland
> > > > that I would like to avoid.)  
> > > 
> > >  "kwin-wayland replaces kwin-x11 , on upgrade" → When upgrading
> > > to
> > > Fedora 40
> > > 
> > > you may reinstall the package, it will not be obsoleted anymore.
> > > 
> > > I don't agree with this behavior   
> > 
> > OK, but how do I run kwin-x11 instead of -wayland?
> > 
> 
> You need plasma-workspace-x11  too.


After reinstall kwin-x11 and plasma-workspace-x11 , in desktop display
manager (for example sddm) you should have the option to login in
plasma-x11 


-- 
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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Sérgio Basto]

On Mon, 2024-03-18 at 16:17 -0400, Garry T. Williams wrote:
> On Wednesday, February 7, 2024 4:06:46 AM EDT Kevin Kofler via devel
> wrote:
> > Garry T. Williams wrote:
> > > I hope my report can be resolved before I am forced to use
> > > Wayland.
> > 
> > You will not be forced to use Wayland. Stay tuned.
> 
> In an effort to test a Wayland bug I reported upstream, I upgraded my
> laptop to f40.  (I am holding off on upgrading my workstation.)  My
> reported bug is still there, but here I am without x11.  I installed
> kwin-x11.  My login screen no longer offers to run it instead of
> kwin-wayland.   Is there a way to run x11 on f40?  (There are still
> several annoying bugs in Wayland that I would like to avoid.)
> 

 "kwin-wayland replaces kwin-x11 , on upgrade" → When upgrading to
Fedora 40

you may reinstall the package, it will not be obsoleted anymore.


I don't agree with this behavior 


-- 
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: [heads up] update to jpegxl-0.10.2 with soname bump in rawhide

[Sérgio Basto]

jpegxl-0.10.2 with soname bump is in rawhide [1]

only seamonkey failed to build



[1] 
https://bodhi.fedoraproject.org/updates/FEDORA-2024-0416713440](https://bodhi.fedoraproject.org/updates/FEDORA-2024-0416713440)

aom-3.8.0-7.fc41  
darktable-4.6.1-3.fc41  
efl-1.27.0-9.fc41  
ffmpeg-6.1.1-11.fc41  
geeqie-2.2-3.fc41  
gimp-2.10.36-7.fc41  
gthumb-3.12.6-2.fc41  
ImageMagick-7.1.1.26-7.fc41  
imlib2-1.11.1-7.fc41  
imv-4.5.0-2.fc41  
jpegxl-0.10.2-0.2.0~sonamebump.fc41  
kf5-kimageformats-5.115.0-3.fc41  
kf6-kimageformats-6.0.0-3.fc41  
krita-5.2.2-8.fc41  
SDL2_image-2.8.2-5.fc41  
vips-8.15.1-4.fc41  
webkit2gtk4.0-2.42.5-3.fc41  
webkitgtk-2.43.4-5.fc41  
xine-lib-1.2.13-13.fc41

On Wed, 2024-03-13 at 01:39 +, Sérgio Basto wrote:

> new try, now with version 0.10.2 
> 
> side-tag:  f41-build-side-85651
> 
> 
> On Wed, 2024-02-14 at 16:14 -0600, Michael Catanzaro wrote:
> 
> > On Wed, Feb 14 2024 at 09:38:39 PM +00:00:00, Sérgio Basto 
> > <[ser...@serjux.com](mailto:ser...@serjux.com)> 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](mailto:devel@lists.fedoraproject.org)
> > To unsubscribe send an email to
[devel-le...@lists.fedoraproject.org](mailto:devel-le...@lists.fedoraproject.org
)
> > Fedora Code of Conduct:
> >
[https://docs.fedoraproject.org/en-US/project/code-of-conduct/](https://docs.fedoraproject.org/en-US/project/code-of-conduct/)
> > List Guidelines:
> >
[https://fedoraproject.org/wiki/Mailing_list_guidelines](https://fedoraproject.org/wiki/Mailing_list_guidelines)
> > List Archives:
> >
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org](https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org)
> > Do not reply to spam, report it:
> >
[https://pagure.io/fedora-infrastructure/new_issue](https://pagure.io/fedora-infrastructure/new_issue)
> 
> 
> -- 
> Sérgio M. B.
> --
> ___
> devel mailing list --
[devel@lists.fedoraproject.org](mailto:devel@lists.fedoraproject.org)
> To unsubscribe send an email to
[devel-le...@lists.fedoraproject.org](mailto:devel-le...@lists.fedoraproject.org
)
> Fedora Code of Conduct:
[https://docs.fedoraproject.org/en-US/project/code-of-conduct/](https://docs.fedoraproject.org/en-US/project/code-of-conduct/)
> List Guidelines:
[https://fedoraproject.org/wiki/Mailing_list_guidelines](https://fedoraproject.org/wiki/Mailing_list_guidelines)
> List Archives:
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org](https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org)
> Do not reply to spam, report it:
[https://pagure.io/fedora-infrastructure/new_issue](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: [heads up] update to jpegxl-0.10.2 with soname bump in rawhide

[Sérgio Basto]

new try, now with version 0.10.2 

side-tag:  f41-build-side-85651


On Wed, 2024-02-14 at 16:14 -0600, Michael Catanzaro wrote:
> 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

-- 
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: perl segfault in F40

[Sérgio Basto]

On Mon, 2024-03-11 at 15:11 +0100, Fabio Valentini wrote:
> On Mon, Mar 11, 2024, 04:07 Jerry James  wrote:
> > On Sun, Mar 10, 2024 at 10:38 AM Orion Poplawski 
> > wrote:
> > > I'm starting to see this building perl-Alien-CFITSIO in F40 (not
> > > rawhide):
> > > 
> > > + cd Alien-CFITSIO-v4.4.0.1
> > > + perl Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
> > > NO_PERLLOCAL=1
> > > Alien::Build::Plugin::PkgConfig::Negotiate> Using PkgConfig
> > > plugin:
> > > PkgConfig::LibPkgConf
> > > RPM build errors:
> > > 
> > > I can't reproduce it locally except in mock.  Even in mock though
> > > if I
> > > enter the chroot with a shell and run rpmbuid it works, so I'm
> > > guessing
> > > its tty related.
> > > 
> > > Is anyone else seeing this?
> > 
> > Yes.  GDB says:
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x77a93584 in _IO_new_fclose (fp=0x1) at iofclose.c:48
> > Downloading source file /usr/src/debug/glibc-2.39-
> > 2.fc40.x86_64/libio/iofclose.c
> > 48        if (fp->_flags & _IO_IS_FILEBUF)
> > (gdb) bt
> > #0  0x77a93584 in _IO_new_fclose (fp=0x1) at iofclose.c:48
> > #1  0x76f690db in XS_PkgConfig__LibPkgConf__Client_DESTROY
> > (my_perl=, cv=)
> >     at /usr/src/debug/perl-PkgConfig-LibPkgConf-0.11-
> > 17.fc40.x86_64/LibPkgConf.xs:311
> > #2  0x77d1288a in Perl_pp_entersub (my_perl=0x92a0)
> >     at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/pp_hot.c:
> > #3  0x77d03718 in Perl_runops_standard
> > (my_perl=0x92a0)
> >     at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/run.c:41
> > #4  0x77c484da in Perl_call_sv (my_perl=0x92a0,
> > sv=, flags=)
> >     at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/perl.c:3150
> > #5  0x77d1b9cf in S_curse
> > (my_perl=my_perl@entry=0x92a0, sv=sv@entry=0x57dba810,
> >     check_refcnt=check_refcnt@entry=true) at
> > /usr/src/debug/perl-5.38.2-506.fc40.x86_64/sv.c:7144
> > #6  0x77d1c1c0 in Perl_sv_clear
> > (my_perl=my_perl@entry=0x92a0,
> > orig_sv=orig_sv@entry=0x57dba810)
> >     at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/sv.c:6685
> > #7  0x77d16482 in Perl_sv_free2 (my_perl=0x92a0,
> > sv=0x57dba810, rc=)
> >     at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/sv.c:7244
> > #8  0x77d4d025 in Perl_leave_scope
> > (my_perl=my_perl@entry=0x92a0, base=)
> >     at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/scope.c:1429
> > #9  0x77d52658 in Perl_dounwind (cxix=,
> > my_perl=)
> >     at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/pp_ctl.c:1669
> > #10 Perl_dounwind (my_perl=my_perl@entry=0x92a0, cxix=10)
> >     at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/pp_ctl.c:1658
> > #11 0x77d52b19 in Perl_die_unwind (my_perl=0x92a0,
> > msv=)
> >     at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/pp_ctl.c:1901
> > #12 0x77ce0b8b in Perl_croak_sv (my_perl=0x92a0,
> > baseex=)
> >     at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/util.c:1861
> > #13 0x77ce0b9d in Perl_die_sv (my_perl=,
> > baseex=)
> >     at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/util.c:1780
> > #14 0x77d61061 in Perl_pp_die (my_perl=0x92a0)
> >     at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/pp_sys.c:509
> > #15 0x77d03718 in Perl_runops_standard
> > (my_perl=0x92a0)
> >     at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/run.c:41
> > #16 0x77c47899 in S_run_body (oldscope=,
> > my_perl=)
> >     at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/perl.c:2807
> > #17 perl_run (my_perl=0x92a0) at
> > /usr/src/debug/perl-5.38.2-506.fc40.x86_64/perl.c:2727
> > #18 0x5342 in main (argc=,
> > argv= > out>, env=)
> >     at /usr/src/debug/perl-5.38.2-506.fc40.x86_64/perlmain.c:127
> > 
> > Frame 1 is this code:
> > 
> > void
> > DESTROY(self)
> >     my_client_t *self;
> >   CODE:
> >     if(self->auditf != NULL)
> >     {
> >       fclose(self->auditf);
> >       self->auditf = NULL;
> >     }
> >     pkgconf_client_deinit(&self->client);
> >     SvREFCNT_dec(self->error_handler);
> >     Safefree(self);
> > 
> > and indeed, self->auditf != NULL, because it is equal to 1, so it
> > is
> > passed to fclose, triggering the segfault.  Setting a hardware
> > watchpoint to catch the transition to the value 1 turns up this:
> > 
> > Old value = (FILE *) 0x0
> > New value = (FILE *) 0x1
> > pkgconf_cache_add (client=0x57f4cd70, pkg=0x57f4d320) at
> > libpkgconf/cache.c:136
> > Downloading source file
> > /usr/src/debug/pkgconf-2.1.0-1.fc40.x86_64/libpkgconf/cache.c
> > 136             client->cache_table =
> > pkgconf_reallocarray(client->cache_table,
> > (gdb) bt
> > #0  pkgconf_cache_add (client=0x57f4cd70, pkg=0x57f4d320)
> > at
> > libpkgconf/cache.c:136
> > #1  pkgconf_cache_add (client=client@entry=0x57f4cd70,
> > pkg=pkg@entry=0x57f4d320) at libpkgconf/cache.c:123
> > #2  0x76f5c6af in pkgconf_pk

Re: Donate 1 minute of your time to test upgrades from F39 to F40

[Sérgio Basto]

On Thu, 2024-03-07 at 11:15 +, Sérgio Basto wrote:
> On Thu, 2024-03-07 at 10:27 +, Barry Scott wrote:
> >  
> > 
> >  
> >  
> > On 21/02/2024 07:11, Miroslav Suchý wrote:
> >  
> > >  
> > > dnf --releasever=40 --setopt=module_platform_id=platform:f40 \
> > > --enablerepo=updates-testing \
> > > $(rpm -q fedora-repos-modular >/dev/null && echo --
> > > enablerepo=updates-testing-modular) \
> > > --assumeno distro-sync
> > >  
> >  
> > Fedora KDE spin - Intel CPU AMD GPU -
> >  
> > Error: 
> >  Problem: problem with installed package blender-1:4.0.2-
> > 1.fc39.x86_64
> >   - blender-1:4.0.2-1.fc39.x86_64 from @System  does not belong to
> > a distupgrade repository
> >   - nothing provides libopenvdb.so.10.1()(64bit) needed by blender-
> > 1:4.0.2-1.fc40.x86_64 from fedora
> > (try to add '--skip-broken' to skip uninstallable packages)
> 
> is the combination of 
> Bug 2259558 - F40FailsToInstall: blender
> Bug 2261013 - blender: FTBFS in Fedora rawhide/f40
> 

Blender is FTBFS because :

DEBUG util.py:461: Failed to resolve the transaction:
DEBUG util.py:461: Problem 1: package usd-devel-23.11-2.fc40.aarch64
requires libusd_ms.so.0.23.11()(64bit), but none of the providers can
be installed
DEBUG util.py:461: - package usd-devel-23.11-2.fc40.aarch64 requires
usd-libs(aarch-64) = 23.11-2.fc40, but none of the providers can be
installed
DEBUG util.py:461: - conflicting requests
DEBUG util.py:461: - nothing provides
libboost_python312.so.1.81.0()(64bit) needed by usd-libs-23.11-
2.fc40.aarch64
DEBUG util.py:461: - nothing provides libopenvdb.so.10.1()(64bit)
needed by usd-libs-23.11-2.fc40.aarch64
DEBUG util.py:461: - nothing provides libdraco.so.8()(64bit) needed by
usd-libs-23.11-2.fc40.aarch64
DEBUG util.py:461: Problem 2: package openshadinglanguage-devel-
1.12.14.0-9.fc40.aarch64 requires liboslquery.so.1.12()(64bit), but
none of the providers can be installed
DEBUG util.py:461: - package openshadinglanguage-devel-1.12.14.0-
9.fc40.aarch64 requires liboslexec.so.1.12()(64bit), but none of the
providers can be installed
DEBUG util.py:461: - package openshadinglanguage-devel-1.12.14.0-
9.fc40.aarch64 requires liboslcomp.so.1.12()(64bit), but none of the
providers can be installed
DEBUG util.py:461: - package openshadinglanguage-devel-1.12.14.0-
9.fc40.aarch64 requires liboslnoise.so.1.12()(64bit), but none of the
providers can be installed
DEBUG util.py:461: - package openshadinglanguage-devel-1.12.14.0-
9.fc40.aarch64 requires libtestshade.so.1.12()(64bit), but none of the
providers can be installed
DEBUG util.py:461: - package openshadinglanguage-devel-1.12.14.0-
9.fc40.aarch64 requires openshadinglanguage-libs(aarch-64) = 1.12.14.0-
9.fc40, but none of the providers can be installed
DEBUG util.py:461: - conflicting requests
DEBUG util.py:461: - nothing provides
libboost_thread.so.1.81.0()(64bit) needed by openshadinglanguage-libs-
1.12.14.0-9.fc40.aarch64
DEBUG util.py:461: Problem 3: package OpenImageIO-devel-2.4.17.0-
1.fc40.aarch64 requires libOpenImageIO_Util.so.2.4()(64bit), but none
of the providers can be installed
DEBUG util.py:461: - package OpenImageIO-devel-2.4.17.0-1.fc40.aarch64
requires libOpenImageIO.so.2.4()(64bit), but none of the providers can
be installed
DEBUG util.py:461: - package OpenImageIO-devel-2.4.17.0-1.fc40.aarch64
requires OpenImageIO(aarch-64) = 2.4.17.0-1.fc40, but none of the
providers can be installed
DEBUG util.py:461: - conflicting requests
DEBUG util.py:461: - nothing provides
libboost_thread.so.1.81.0()(64bit) needed by OpenImageIO-2.4.17.0-
1.fc40.aarch64
DEBUG util.py:461: - nothing provides libopenvdb.so.10.1()(64bit)
needed by OpenImageIO-2.4.17.0-1.fc40.aarch64
DEBUG util.py:461: Problem 4: package openshadinglanguage-common-
headers-1.12.14.0-9.fc40.noarch requires openshadinglanguage =
1.12.14.0-9.fc40, but none of the providers can be installed
DEBUG util.py:461: - package openshadinglanguage-1.12.14.0-
9.fc40.aarch64 requires liboslquery.so.1.12()(64bit), but none of the
providers can be installed
DEBUG util.py:461: - package openshadinglanguage-1.12.14.0-
9.fc40.aarch64 requires liboslexec.so.1.12()(64bit), but none of the
providers can be installed
DEBUG util.py:461: - package openshadinglanguage-1.12.14.0-
9.fc40.aarch64 requires liboslcomp.so.1.12()(64bit), but none of the
providers can be installed
DEBUG util.py:461: - conflicting requests
DEBUG util.py:461: - nothing provides
libboost_thread.so.1.81.0()(64bit) needed by openshadinglanguage-libs-
1.12.14.0-9.fc40.aarch64
DEBUG util.py:610: Child return code was: 1
DEBUG util.py:185: kill orphans in chroot /var/lib/mock/f40-build-
48392202-5759785/root


> > Fedora Server as router - Intel CPU
> > - No problems.
> >  
> > Fe

Re: Donate 1 minute of your time to test upgrades from F39 to F40

[Sérgio Basto]

On Thu, 2024-03-07 at 10:27 +, Barry Scott wrote:
>  
> 
>  
>  
> On 21/02/2024 07:11, Miroslav Suchý wrote:
>  
> >  
> > dnf --releasever=40 --setopt=module_platform_id=platform:f40 \
> > --enablerepo=updates-testing \
> > $(rpm -q fedora-repos-modular >/dev/null && echo --
> > enablerepo=updates-testing-modular) \
> > --assumeno distro-sync
> >  
>  
> Fedora KDE spin - Intel CPU AMD GPU -
>  
> Error: 
>  Problem: problem with installed package blender-1:4.0.2-
> 1.fc39.x86_64
>   - blender-1:4.0.2-1.fc39.x86_64 from @System  does not belong to a
> distupgrade repository
>   - nothing provides libopenvdb.so.10.1()(64bit) needed by blender-
> 1:4.0.2-1.fc40.x86_64 from fedora
> (try to add '--skip-broken' to skip uninstallable packages)

is the combination of 
Bug 2259558 - F40FailsToInstall: blender
Bug 2261013 - blender: FTBFS in Fedora rawhide/f40


> Fedora Server as router - Intel CPU
> - No problems.
>  
> Fedora Server as router - RaspberryPi
> - No problems.
>  
> Fedora Server as file server/imapl server/prometheus - Intel CPU
> - No problems
>  
> Fedora KODI media player - Intel CPU
> - No problems
>  
> Barry
>  
> 
>  
>  
> 
>  
>  
> 
>  
>  
> --
> ___
> 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: GStreamer 1.24 Released With Vulkan H.264/H.265 Decode & Many Enhancements

[Sérgio Basto]

On Tue, 2024-03-05 at 21:36 +, Ryan Bach via devel wrote:
> > The Fedora gstreamer maintainers regularly and actively update and
> > maintain the GST stack, I'm not sure what a message with just a
> > link
> > provides, did you have a particular query you wanted answered about
> > the release in the context of Fedora?
> > 
> > Peter
> No, I just thought someone here would be interested in news about it.


I just notice that  GStreamer 1.24 is arriving to rawhide 



> Thank you.
> --
> ___
> 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: GStreamer 1.24 Released With Vulkan H.264/H.265 Decode & Many Enhancements

[Sérgio Basto]

On Tue, 2024-03-05 at 03:28 +, Ryan Bach via devel wrote:
> https://www.phoronix.com/news/GStreamer-1.24-Released

AFAIK Fedora can't have H264 neither H265 decoding or encoding because
these codecs are patented and have royalties and you don't have way to
get around. 

The solution is to use free (free from the word freedom) codecs


Best regards,
-- 
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

[off-topic] Re: help needed with failing eccodes build for f40

[Sérgio Basto]

On Thu, 2024-02-29 at 19:19 +0900, Mamoru TASAKA wrote:
> Petr Pisar wrote on 2024/02/29 18:35:
> > V Thu, Feb 29, 2024 at 10:02:32AM +0100, Jos de Kloe napsal(a):
> > > Dear all,
> > > 
> > > while doing koji builds for the latest eccodes version 2.34.1 I
> > > ran in to an
> > > issue that is puzzling to me, and I have no idea to solve this.
> > > 
> > > The build runs just fine for f38, f39 and f41/rawhide, but for
> > > f40 I get a
> > > number of g++ errors like this:
> > > 
> > >   error: ‘opj_destroy_decompress’ was not declared in this scope;
> > > did you
> > > mean ‘opj_end_decompress’?
> > >    209 | opj_destroy_decompress(dinfo);
> > >    | ^~
> > >    | opj_end_decompress
> > > 
> > > see:
> > > https://koji.fedoraproject.org/koji/buildinfo?buildID=2412368
> > > 
> > > Does anyone have an idea what is happening here and how this can
> > > be solved?
> > > 
> > The function is supposed to be declared in openjpeg.h header file
> > which is
> > supposed to be packaged in openjpeg2-devel.
> > 
> > Checking root.log files of eccodes builds, F40 used
> > openjpeg2-devel-2.5.1-1.fc40, while F41 used openjpeg2-devel-2.5.2-
> > 1.fc41.
> > 
> > It's quite possible that opj_destroy_decompress was added in 2.5.2
> > and does
> > not exist in 2.5.1. If it is so, you should specify the minimal
> > version among
> > BuildRequires: openjpeg2-devel >= 2.5.2.
> > 
> > Why is openjpeg2-devel-2.5.2-1.fc40 not available in F40 build
> > root? It is
> > because that build has not been submitted to Bodhi and has not
> > passed into
> > updates repository.
> > 
> > I recommend creating a side tag for F40, tag openjpeg2-devel-2.5.2-
> > 1.fc40
> > there, build eccodes there, and both builds push into a single
> > Bodhi update.
> > 
> > -- Petr
> > 
> 
> openjpeg2 header file is broken in 2.5.1:
> https://github.com/uclouvain/openjpeg/issues/1514
> due to this commit:
> https://github.com/uclouvain/openjpeg/commit/c4b3a91ede1d0301f7f5f50287c0bda35aa7ca7e
> 
> and fixed in 2.5.2:
> https://github.com/uclouvain/openjpeg/pull/1515
> https://github.com/uclouvain/openjpeg/commit/e521a5094be3be4f8657a2253958b0d752616479
> 
> So F39 and F38 buildroot openjpeg2  (2.5.0) is okay, F41 buildroot
> openjpeg2 (2.5.2) is
> also okay, really current F40 buildroot openjpeg2 (2.5.1) is broken.

BTW I think package openjpeg2 should be renamed to openjpeg since
openjpeg (1) was retired and for example is openjpeg.h header file not
openjpeg2.h header file 

Best regards,
-- 
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: Donate 1 minute of your time to test upgrades from F39 to F40

[Sérgio Basto]

On Sat, 2024-02-24 at 09:47 +0100, Ralf Corsépius wrote:
> 
> 
> Am 24.02.24 um 01:36 schrieb Samuel Sieb:
> > On 2/23/24 15:38, Sérgio Basto wrote:
> > > On Sat, 2024-02-24 at 00:06 +0100, Ralf Corsépius wrote:
> > > > 
> > > > 
> > > > Am 23.02.24 um 22:37 schrieb Samuel Sieb:
> > > > > On 2/23/24 10:50, Ralf Corsépius wrote:
> > > > > > 
> > > > > > # dnf system-upgrade download --releasever=40
> > > > > > ...
> > > > > > No match for group package "multican"
> > > > > > ...
> > > > > > 
> > > > > > WTH?
> > > > > 
> > > > > It was a program for controlling Canon cameras that has been
> > > > > retired.
> > > > > Some group you have installed has that package listed in it.
> > > > Ah, this likely explains why neither "dnf repoquery" nor "dnf
> > > > group
> > > > list" could find "multican".
> > > > 
> > > > >   The comps
> > > > > groups need to be cleaned out and that's just a warning.
> > > > Well, ... IMHO, most about comps and groups is in an
> > > > embarrassing
> > > > unusable shape.
> > > > 
> > > No match for group package "baekmuk-ttf-batang-fonts"
> > [snip]
> > > No match for group package "util-linux-user"
> > > 
> > > I got these ones , is something on my rpm db ?
> 
> I am seeing these on another machine, too.
> 
> > No.  Well, sort of.  As mentioned, those are packages that have
> > been 
> > removed from the distro, but are still listed in the comps groups. 
> > dnf 
> > checks the installed groups for packages that need to be updated
> > and 
> > can't find these ones.
> Really? How do I check for which groups I have installed?
> 
> At least I haven't found any way to check for them, neither with rpm
> nor 
> with dnf.
> 
> 
> Finally, another issue:
> ...
> Error:
>   Problem: conflicting requests
>    - package libva-intel-media-driver-24.1.3-1.fc40.i686 from fedora 
> conflicts with intel-media-driver provided by 
> intel-media-driver-24.1.3-1.fc40.x86_64 from rpmfusion-nonfree
>    - package libva-intel-media-driver-24.1.3-1.fc40.x86_64 from
> fedora 
> conflicts with intel-media-driver provided by 
> intel-media-driver-24.1.3-1.fc40.x86_64 from rpmfusion-nonfree
>    - problem with installed package intel-media-driver-23.4.3-
> 1.fc39.x86_64
>    - intel-media-driver-23.4.3-1.fc39.x86_64 from @System  does not 
> belong to a distupgrade repository
> (try to add '--allowerasing' to command line to replace conflicting 
> packages or '--skip-broken' to skip uninstallable packages)
> 
> I see 2 potential issues in there:
> 1. I think, I once "dnf swapped" these packages => Does "dnf 
> system-upgrade" handle "swapped" packages correctly?
> 
> 2. Why does dnf system-upgrade wants to pull-in a i686 package in
> this 
> case? IMO, this doesn't make sense.

we are trying fix this one in here :
https://bugzilla.rpmfusion.org/show_bug.cgi?id=6861


-- 
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: Donate 1 minute of your time to test upgrades from F39 to F40

[Sérgio Basto]

On Sat, 2024-02-24 at 00:06 +0100, Ralf Corsépius wrote:
> 
> 
> Am 23.02.24 um 22:37 schrieb Samuel Sieb:
> > On 2/23/24 10:50, Ralf Corsépius wrote:
> > > 
> > > # dnf system-upgrade download --releasever=40
> > > ...
> > > No match for group package "multican"
> > > ...
> > > 
> > > WTH?
> > 
> > It was a program for controlling Canon cameras that has been
> > retired.
> > Some group you have installed has that package listed in it.
> Ah, this likely explains why neither "dnf repoquery" nor "dnf group 
> list" could find "multican".
> 
> >  The comps 
> > groups need to be cleaned out and that's just a warning.
> Well, ... IMHO, most about comps and groups is in an embarrassing 
> unusable shape.
> 


No match for group package "baekmuk-ttf-batang-fonts"
No match for group package "baekmuk-ttf-dotum-fonts"
No match for group package "baekmuk-ttf-gulim-fonts"
No match for group package "baekmuk-ttf-hline-fonts"
No match for group package "cdac-sakal-marathi-fonts"
No match for group package "fedora-repos-modular"
No match for group package "fontawesome-fonts"
No match for group package "gimp-heif-plugin"
No match for group package "google-noto-emoji-color-fonts"
No match for group package "google-noto-looped-thai-fonts"
No match for group package "google-noto-sans-phags-pa-fonts"
No match for group package "ht-caladea-fonts"
No match for group package "ibus-bogo"
No match for group package "iwl1000-firmware"
No match for group package "iwl100-firmware"
No match for group package "iwl105-firmware"
No match for group package "iwl135-firmware"
No match for group package "iwl2000-firmware"
No match for group package "iwl2030-firmware"
No match for group package "iwl3160-firmware"
No match for group package "iwl3945-firmware"
No match for group package "iwl4965-firmware"
No match for group package "iwl5000-firmware"
No match for group package "iwl5150-firmware"
No match for group package "iwl6000-firmware"
No match for group package "iwl6000g2a-firmware"
No match for group package "iwl6000g2b-firmware"
No match for group package "iwl6050-firmware"
No match for group package "iwl7260-firmware"
No match for group package "iwlax2xx-firmware"
No match for group package "kalapi-fonts"
No match for group package "kde-print-manager"
No match for group package "layla-arcyarc-fonts"
No match for group package "layla-basic-arabic-fonts"
No match for group package "layla-boxer-fonts"
No match for group package "layla-digital-fonts"
No match for group package "layla-diwani-fonts"
No match for group package "layla-koufi-fonts"
No match for group package "layla-ruqaa-fonts"
No match for group package "layla-thuluth-fonts"
No match for group package "libertas-usb8388-firmware"
No match for group package "libproxy-duktape"
No match for group package "lohit-malayalam-fonts"
No match for group package "lohit-nepali-fonts"
No match for group package "lohit-tamil-classical-fonts"
No match for group package "multican"
No match for group package "nafees-naskh-fonts"
No match for group package "nafees-nastaleeq-fonts"
No match for group package "nafees-pakistani-naskh-fonts"
No match for group package "nafees-pakistani-web-naskh-fonts"
No match for group package "nafees-riqa-fonts"
No match for group package "nafees-tehreer-naskh-fonts"
No match for group package "nafees-web-naskh-fonts"
No match for group package "paktype-ajrak-fonts"
No match for group package "samyak-devanagari-fonts"
No match for group package "samyak-gujarati-fonts"
No match for group package "samyak-malayalam-fonts"
No match for group package "samyak-odia-fonts"
No match for group package "samyak-tamil-fonts"
No match for group package "scim-sayura"
No match for group package "thai-scalable-garuda-fonts"
No match for group package "thai-scalable-kinnari-fonts"
No match for group package "thai-scalable-laksaman-fonts"
No match for group package "thai-scalable-loma-fonts"
No match for group package "thai-scalable-norasi-fonts"
No match for group package "thai-scalable-purisa-fonts"
No match for group package "thai-scalable-sawasdee-fonts"
No match for group package "thai-scalable-tlwgmono-fonts"
No match for group package "thai-scalable-tlwgtypewriter-fonts"
No match for group package "thai-scalable-tlwgtypist-fonts"
No match for group package "thai-scalable-tlwgtypo-fonts"
No match for group package "thai-scalable-umpush-fonts"
No match for group package "thai-scalable-waree-fonts"
No match for group package "util-linux-user"

I got these ones , is something on my rpm db ? 


> Ralf
> 
> 
> --
> ___
> 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:
> htt

Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)

[Sérgio Basto]

On Fri, 2024-02-23 at 12:57 -0500, Stephen Smoogen wrote:
> 
> 
> On Fri, 23 Feb 2024 at 08:04, Sérgio Basto  wrote:
> > On Thu, 2024-02-22 at 20:36 -0500, Neal Gompa wrote:
> > > On Thu, Feb 22, 2024 at 8:32 PM Sérgio Basto 
> > 
> > > No. This is one of those many myths about the "Unix FHS". And it
> > > doesn't even matter much these days anyway, since most newer
> > > administrative tools don't install in sbin anyway.
> > > 
> > 
> > name it one , I'm not aware.
> > 
> > Fedora old school (or just me I don't know ) don't use sudo , sudo
> > is a
> > bad idea that came from Ubuntu and turn computer much more insecure
> > ,
> > 
> 
> 
> sudo has been part of the Red Hat/Fedora family since Red Hat Linux
> 7.0 
> https://archive.download.redhat.com/pub/redhat/linux/7.0/en/os/i386/R
> edHat/RPMS/ (2000-09) and had been in powertools since at least
> 5.2 https://archive.download.redhat.com/pub/redhat/linux/5.2/en/power
> tools/i386/ (1998-11). Both of those dates vastly predate Ubuntu.
> While they had been part of Debian before that they were included in
> Powertools in 5 due to requests for it being used on Unix systems
> which were being replaced with Red Hat Linux. [sudo was already a
> preferred tool in various university and corporate environments
> because it did allow for all kinds of policy decisions which were
> easily updated versus the standard at that time to make a chroot
> wrapper and control via group permissions. Many times these wrappers
> were the most insecure thing on a system. ]

I don't use sudo or my regular user is not in sudo users , sudo is
needed for others things like wheel group and always have been present
in Linux 

I mean using sudo and can't login as root or root don't have password ,
like in Ubuntu model and if you are admin you do sudo for everything . 


> > since if a regular user is compromised the access to all computer
> > is
> > much more easier .
> > 
> 
> 
> https://xkcd.com/1200/
> 


This xkcd is not new for me and made me think, I already stated my
opinion don't want lose much time on this subject 

> > And PATH at root user have sbin and PATH of regular user should not
> > have /sbin/ 
> > 
> > but checking we got this pearl in /etc/profile 
> > 
> > 
> > if [ "$EUID" = "0" ]; then
> > pathmunge /usr/sbin
> > pathmunge /usr/local/sbin
> > else
> > pathmunge /usr/local/sbin after
> > pathmunge /usr/sbin after
> > fi
> > 
> > 
> 
> 
> There have been holy wars over /usr/sbin:/sbin:/usr/local/bin for as
> long as I have been a systems administrator in the 1980's. Different
> schools of thought have their world view of when/who/how people
> should have access to it and it would be even split into which Unix
> you used because of what was needed to act per system. 
> 
> In the end, this choice tends to be deeply personal where each person
> assumes the world should follow their model and then get
> increasingly angry that is not the case. I have seen it create
> complete forks of an operating system due to needing to compile in
> such paths in various tools. 
>  
> > 
> > --
> > ___
> > 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: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)

[Sérgio Basto]

On Fri, 2024-02-23 at 09:17 -0500, Neal Gompa wrote:
> On Fri, Feb 23, 2024 at 8:04 AM Sérgio Basto 
> wrote:
> > 
> > On Thu, 2024-02-22 at 20:36 -0500, Neal Gompa wrote:
> > > On Thu, Feb 22, 2024 at 8:32 PM Sérgio Basto 
> > > wrote:
> > > > 
> > > > On Sun, 2024-01-28 at 20:14 +, Neal Gompa wrote:
> > > > > On Sun, Jan 28, 2024 at 7:54 PM Gary Buhrmaster
> > > > >  wrote:
> > > > > > 
> > > > > > On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney
> > > > > > 
> > > > > > wrote:
> > > > > > > 
> > > > > > > Wiki ->
> > > > > > > https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
> > > > > > > 
> > > > > > 
> > > > > > One additional item to consider is to review
> > > > > > the packager guidelines for use of /sbin
> > > > > > (and /usr/sbin) in additional locations from
> > > > > > those involved directly with installing binaries.
> > > > > > 
> > > > > > In particular, I am thinking of the sysusers
> > > > > > examples where the use of /sbin/nologin
> > > > > > should, perhaps, be changed to /usr/bin/nologin.
> > > > > > 
> > > > > > There are almost certainly other places
> > > > > > in the docs/guidelines.
> > > > > > 
> > > > > > The documentation updates are always
> > > > > > the most annoying in my experience.
> > > > > 
> > > > > We cannot change this without breaking backward
> > > > > compatibility.
> > > > > It'll
> > > > > have to stay that way until RHEL 9 falls out of support.
> > > > 
> > > > 
> > > > That is a good argument to not change it , why we need break
> > > > backward
> > > > compatibility ?
> > > > 
> > > 
> > > Nah. It just means we don't change any configuration or PATH
> > > stuff,
> > > which is fine because the sbin -> bin symlink will cover it.
> > > 
> > 
> > I strongly disagree with you , we should avoid break backward
> > compatibility , unless we got a very good reason , which is not the
> > case
> > 
> 
> We're not breaking backward compatibility. We would install a symlink
> pointing sbin to bin, which ensures any absolute path usage of
> binaries formerly in sbin will still work.


Good 


> > > > is not sbin for super users and bin for users ?
> > > > 
> > > 
> > > No. This is one of those many myths about the "Unix FHS". And it
> > > doesn't even matter much these days anyway, since most newer
> > > administrative tools don't install in sbin anyway.
> > > 
> > 
> > name it one , I'm not aware.
> > 
> 
> Sure: dnf.

Not convinced, dnf repoquery can be used by any user.
I don't see any major problem but also I don't see any great
benefit, so I don't think we should change that, as it will be, most
likely, a lot of work to everyone 


-- 
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: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)

[Sérgio Basto]

On Thu, 2024-02-22 at 20:36 -0500, Neal Gompa wrote:
> On Thu, Feb 22, 2024 at 8:32 PM Sérgio Basto 
> wrote:
> > 
> > On Sun, 2024-01-28 at 20:14 +, Neal Gompa wrote:
> > > On Sun, Jan 28, 2024 at 7:54 PM Gary Buhrmaster
> > >  wrote:
> > > > 
> > > > On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney
> > > > 
> > > > wrote:
> > > > > 
> > > > > Wiki ->
> > > > > https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
> > > > > 
> > > > 
> > > > One additional item to consider is to review
> > > > the packager guidelines for use of /sbin
> > > > (and /usr/sbin) in additional locations from
> > > > those involved directly with installing binaries.
> > > > 
> > > > In particular, I am thinking of the sysusers
> > > > examples where the use of /sbin/nologin
> > > > should, perhaps, be changed to /usr/bin/nologin.
> > > > 
> > > > There are almost certainly other places
> > > > in the docs/guidelines.
> > > > 
> > > > The documentation updates are always
> > > > the most annoying in my experience.
> > > 
> > > We cannot change this without breaking backward compatibility.
> > > It'll
> > > have to stay that way until RHEL 9 falls out of support.
> > 
> > 
> > That is a good argument to not change it , why we need break
> > backward
> > compatibility ?
> > 
> 
> Nah. It just means we don't change any configuration or PATH stuff,
> which is fine because the sbin -> bin symlink will cover it.
> 

I strongly disagree with you , we should avoid break backward
compatibility , unless we got a very good reason , which is not the
case 

> > is not sbin for super users and bin for users ?
> > 
> 
> No. This is one of those many myths about the "Unix FHS". And it
> doesn't even matter much these days anyway, since most newer
> administrative tools don't install in sbin anyway.
> 

name it one , I'm not aware.

Fedora old school (or just me I don't know ) don't use sudo , sudo is a
bad idea that came from Ubuntu and turn computer much more insecure ,
since if a regular user is compromised the access to all computer is
much more easier .
And PATH at root user have sbin and PATH of regular user should not
have /sbin/ 

but checking we got this pearl in /etc/profile 


if [ "$EUID" = "0" ]; then
pathmunge /usr/sbin
pathmunge /usr/local/sbin
else
pathmunge /usr/local/sbin after
pathmunge /usr/sbin after
fi


-- 
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: Kickstart install of Rawhide fails

[Sérgio Basto]

On Thu, 2024-02-22 at 16:28 -0800, Adam Williamson wrote:
> On Thu, 2024-02-22 at 15:32 -0700, Orion Poplawski wrote:
> > I've seeing:
> > 
> > INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Ins
> > talled:
> > glibc-common-2.39.9000-
> > 1.fc41.x86_64 1708040026
> > e4113ddcb7a4bf591492c0bf4644932b0dad7691ff19c65111751675336cb0c8
> > INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Ins
> > talled:
> > bash-5.2.26-3.fc40.x86_64 1707490454
> > 3d71ab445ce95481fcd0b367a2541260323b11cff351df8dc8f88df4a5d928df
> > INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Con
> > figuring
> > (running scriptlet for): bash-5.2.26-3.fc40.x86_64 1707490454
> > 3d71ab445ce95481fcd0b367a2541260323b11cff351df8dc8f88df4a5d928df
> > INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Ins
> > talled:
> > dbus-common-1:1.14.10-3.fc40.noarch 1706087027
> > 4501dd43017c1bef93ca8edaae3cbaa501aef60b53e9f7edbe0b5f326d6d471d
> > INFO:anaconda.modules.payloads.payload.dnf.transaction_progress:Con
> > figuring
> > (running scriptlet for): dbus-common-1:1.14.10-3.fc40.noarch
> > 1706087027
> > 4501dd43017c1bef93ca8edaae3cbaa501aef60b53e9f7edbe0b5f326d6d471d
> > INFO:dnf.rpm:error: failed to exec scriptlet interpreter /bin/sh:
> > No such file
> > or directory
> > warning: %post(dbus-common-1:1.14.10-3.fc40.noarch) scriptlet
> > failed, exit
> > status 127
> > 
> > ERROR:dnf.rpm:Error in POSTIN scriptlet in rpm package dbus-common
> > ERROR:anaconda.modules.payloads.payload.dnf.transaction_progress:Er
> > ror in
> > POSTIN scriptlet in rpm package dbus-common
> > 
> > 
> > But /bin/sh is present and runnable when I try in /mnt/sysroot (the
> > log shows
> > that bash was just installed as well).
> > 
> > Anyone else hitting this?
> 
> Yes, someone else is, when installing in VirtualBox:
> https://bugzilla.redhat.com/show_bug.cgi?id=2244744
> 

by excluding parts (por exclusão de partes)  I don't know if is well
translated , my guess is
https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin


> It's confusing, isn't it? Are you using VirtualBox?
> -- 
> 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

-- 
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: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)

[Sérgio Basto]

On Sun, 2024-01-28 at 20:14 +, Neal Gompa wrote:
> On Sun, Jan 28, 2024 at 7:54 PM Gary Buhrmaster
>  wrote:
> > 
> > On Wed, Dec 20, 2023 at 7:54 PM Aoife Moloney 
> > wrote:
> > > 
> > > Wiki -> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin
> > > 
> > 
> > One additional item to consider is to review
> > the packager guidelines for use of /sbin
> > (and /usr/sbin) in additional locations from
> > those involved directly with installing binaries.
> > 
> > In particular, I am thinking of the sysusers
> > examples where the use of /sbin/nologin
> > should, perhaps, be changed to /usr/bin/nologin.
> > 
> > There are almost certainly other places
> > in the docs/guidelines.
> > 
> > The documentation updates are always
> > the most annoying in my experience.
> 
> We cannot change this without breaking backward compatibility. It'll
> have to stay that way until RHEL 9 falls out of support.


That is a good argument to not change it , why we need break backward
compatibility ? 

is not sbin for super users and bin for users ? 

-- 
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: Feedback wanted - pruning old rawhide chroots in Copr

[Sérgio Basto]

On Sun, 2024-02-18 at 23:45 +0100, Fabio Valentini wrote:
> On Sun, Feb 18, 2024 at 4:25 PM Michael J Gruber
>  wrote:
> > 
> 
> (snip)
> 
> > 
> > I see this somehow connected to the discussion about signing keys
> > that
> > we had recently. A radical solution would be: branch rawhide, not
> > from
> > rawhide. So, at the "F40 branch point we had last week", we would:
> > - switch the "alias" rawhide from "meaning f40" to "meaning f41"
> > - rename rawhide chroots to f40 in copr
> > - set up new rawhide chroots ("follow [up] fedora branching")
> > 
> > In most cases, "forked" packages in copr are misleading - they are
> > in
> > a chroot without having been built against any version of it.
> > 
> > copr users would have to hit "rebuild", which should be OK.
> 
> I like this idea. Move things that were built for "rawhide" into the
> "fedora-40" chroot, and start Rawhide empty, requiring fresh builds
> of
> things.
> Since there is no equivalent to the mass rebuild in COPR, that would
> also solve the problem of "stale" packages in Rawhide chroots.


I like the idea , instead Fedora 40 have the fork of rawhide build, it
became rawhide that have the fork of Fedora 40 build ... 


I realize if build have {?dist} macro is easy if it is 3 or 4 release
old can be deleted . 
And if not have {?dist} macro  , they have the build date ... 

for example
https://download.copr.fedorainfracloud.org/results/sergiomb/SambaAD/fedora-rawhide-x86_64/01177931-samba/

> 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: Need help with incompatible pointer types on i686

[Sérgio Basto]

On Fri, 2024-02-16 at 14:01 +0100, Florian Weimer wrote:
> * Orion Poplawski:
> 
> > It seems that numpy is defining a uint32_t type as long unsigned
> > int
> > on i686, while glibc(?) is defining it as unsigned int.  Now what
> > puzzles me a little is that on i686 aren't these both 4-byte
> > integers
> > and no not incompatible at all?
> 
> The types int and long are distinct according to C rules.
> 
> The problem seems to be in h5py/api_types_ext.pxd:
> 
> from numpy cimport int8_t, uint8_t, int16_t, uint16_t, int32_t,
> uint32_t, int64_t, uint64_t
> 
> I think it should use the types from  instead, at least in
> the
> global scope.  For certain Numpy functions, it may be required to
> reference them as numpy.uint32_t etc.


this is over complicated to me , we can disable this check with: 

%global build_type_safety_c 0

> Thanks,
> Florian
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, 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: Why branched config pointed to rolling config?

[Sérgio Basto]

On Wed, 2024-02-14 at 15:38 +, Sérgio Basto wrote:
> 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 

After update mock-core-configs with [1] the problem should be fixed 

[1]
dnf update --enablerepo=updates-testing --refresh mock-core-configs

-- 
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: [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 -
I/builddir/build/BUILD/webkitgtk-2.43.4/Source/WebCore/Modules/

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

Re: exiv2 and protobuf hard to do soname bump without turbulence

[Sérgio Basto]

On Fri, 2024-02-09 at 16:53 +, Gary Buhrmaster wrote:
> On Fri, Feb 9, 2024 at 4:23 PM Sérgio Basto 
> wrote:
> > 
> > Hi,
> > 
> > I'd like to bring to your attention that Fedora would benefit with
> > update of exiv2 [1] and  protobuf [2] but these packages have lots
> > of
> > dependencies and the update of the dependent packages is not
> > trivial .
> > tips, ideas and opinions ? to do these soname updates
> > 
> 
> While understandably annoying, last I knew the patent
> issue IRT BMFF was not yet resolved for exiv2 (waiting
> on RH legal).  As I understand it, once the issue is raised,
> one is required to wait for a formal decision to be made,
> and there no time frame for that to occur.
> 
> If you are willing to strip the sources of the BMFF support
> until such time as a decision as to whether to allow it
> to be included is made that should be a way forward
> more quickly.

"In order to update Exiv2, we need to know if this is okay to enable
BMFF support. Patents have theorically expired and it is enabled by
default in the latest version."

until isn't clear by legal it should be disabled , if default is enable
,we should disable it and move on , it is not a show stopper 


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

exiv2 and protobuf hard to do soname bump without turbulence

[Sérgio Basto]

Hi,

I'd like to bring to your attention that Fedora would benefit with
update of exiv2 [1] and  protobuf [2] but these packages have lots of
dependencies and the update of the dependent packages is not trivial .
tips, ideas and opinions ? to do these soname updates 

thank you


[1]
https://src.fedoraproject.org/rpms/exiv2/pull-request/6

[2]
https://src.fedoraproject.org/rpms/protobuf/pull-request/26
-- 
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

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

[Sérgio Basto]

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.

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

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Sérgio Basto]

On Fri, 2024-02-09 at 13:21 +0100, Marc Deop i Argemí wrote:
> On Friday, 9 February 2024 11:53:01 CET Sérgio Basto wrote:
> > so you agree that are giving the overhead to us (the people who
> > want
> > keep X11 as it is )
> 
> Yes!!! OF COURSE!
> 
> If you wanna maintain something you need to handle the overhead! Not
> the other 
> way around!

ah ok, you can give overhead to others because is not your problem, but
others can't maintain X11 because gives overhead to you. 

-- 
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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Sérgio Basto]

On Thu, 2024-02-08 at 22:04 -0500, Steve Cossette wrote:
> I
> On Thu, Feb 8, 2024 at 9:51 PM Sérgio Basto 
> wrote:
> > On Thu, 2024-02-08 at 20:43 +0100, Fabio Valentini wrote:
> > > On Thu, Feb 8, 2024 at 12:33 PM Sérgio Basto 
> > > wrote:
> > > > 
> > > > On Wed, 2024-02-07 at 16:03 +0100, Marc Deop i Argemí wrote:
> > > > > We are not banning nor deleting anything. We are not
> > > > > _supporting_
> > > > > it.
> > > > 
> > > > 
> > > > you are removing X11 from the builds deliberately , when
> > > > many people , members of Fedora on devel mailing list, express
> > > > that
> > > > they want have X11 , in fact we have many people that defend
> > > > keep
> > > > X11 .
> > > 
> > > One thing that seems to be overlooked in many of the posts on
> > > this
> > > thread:
> > > 
> > > Nobody can *force* the KDE Plasma maintainers to do *anything*,
> > > just
> > > like nobody can force *any* packager to do anything. 
> > 
> > nobody can force me use wayland , we volunteer maintain KDE Plasma
> > X11
> > , why do you think, we want force someone to do anything ? they are
> > force us do a new packages, they remove X11 without consensus, they
> > can
> > leave the packages alone . 
> > 
> > > Fedora a
> > > volunteer-run project. We're mostly doing this "for fun" (or at
> > > least,
> > > some definition of "fun"). So if the KDE Plasma maintainers / the
> > > KDE
> > > SIG decides that they do not want to keep supporting the Plasma /
> > > X11
> > > session, that is their choice. However, I am not sure whether I
> > > like
> > > it or not that there's an ongoing effort to add this
> > > functionality
> > > back with separate packages.
> > > 
> > > For me, the only acceptable way to do this would be in a way that
> > > does
> > > in no way make maintaining the Plasma / Wayland packages more
> > > difficult or burdensome, since the original intent of dropping
> > > the
> > > Plasma / X11 session was to *lower* the maintenance burden.
> > 
> > It is a false excuse and not true, is not more difficult nor
> > burdensome, we had many burdensome with the default be wayland and
> > hundreds of bugs opened and never fixed with crashes only on
> > wayland
> > session .  
> > 
> > >   Adding
> > > back the Plasma / X11 session with separate packages might cause
> > > additional overhead for the KDE SIG (for example, needing to
> > > update
> > > kwin-x11 whenever there is a kwin update). 
> > 
> > is the opposite, KDE SIG are causing additional overhead to who
> > want
> > use X11 and the package maintainer forcing use of wayland and why
> > does
> > the will of KDE SIG have to prevail? 
> > 
> > I also maintain many KDE packages and I had a overhead with wayland
> > crashes 
> > 
> > > That would be the "usual"
> > > way to handle this according to Fedora policies.
> > > 
> > 
> > The usual is, if someone want maintain the package , they can
> > maintain
> > it, no one complains about an hypothetical burden
> > 
> > > However, that would be counter to the original purpose of
> > > dropping
> > > the
> > > functionality from the packages maintained by the KDE SIG. But
> > > again,
> > > nobody can *force* package maintainers to support something they
> > > don't
> > > want to support. 
> > 
> > They don't have support X11 , they have the work of keep the
> > removal of
> > X11 in their packages  .
> > 
> > Other thing that KDE SIG misses , is how testing , let says, as
> > usual,
> > some app crash , and we ask have you wayland session or X11
> > session, if
> > you have wayland try X11 , if it runs at X11 and crash on wayland ,
> > this fact can help find the problem and not the opposite . 
> > 
> > also in kde-wayland you can run in x11 envoirment with env
> > QT_QPA_PLATFORM=xcb 
> > 
> > So just thinking removing this part of the functionalities on KDE ,
> > IMHO is lack of knowledge of graphics and bad for Fedora. IMHO the
> > future is have both technologies and not replace it 
> > 
> > 
> > Is very sad read that some people think in remove it and force
> > people
> > 

Re: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Sérgio Basto]

On Thu, 2024-02-08 at 20:43 +0100, Fabio Valentini wrote:
> On Thu, Feb 8, 2024 at 12:33 PM Sérgio Basto 
> wrote:
> > 
> > On Wed, 2024-02-07 at 16:03 +0100, Marc Deop i Argemí wrote:
> > > We are not banning nor deleting anything. We are not _supporting_
> > > it.
> > 
> > 
> > you are removing X11 from the builds deliberately , when
> > many people , members of Fedora on devel mailing list, express that
> > they want have X11 , in fact we have many people that defend keep
> > X11 .
> 
> One thing that seems to be overlooked in many of the posts on this
> thread:
> 
> Nobody can *force* the KDE Plasma maintainers to do *anything*, just
> like nobody can force *any* packager to do anything. 

nobody can force me use wayland , we volunteer maintain KDE Plasma X11
, why do you think, we want force someone to do anything ? they are
force us do a new packages, they remove X11 without consensus, they can
leave the packages alone . 

> Fedora a
> volunteer-run project. We're mostly doing this "for fun" (or at
> least,
> some definition of "fun"). So if the KDE Plasma maintainers / the KDE
> SIG decides that they do not want to keep supporting the Plasma / X11
> session, that is their choice. However, I am not sure whether I like
> it or not that there's an ongoing effort to add this functionality
> back with separate packages.
> 
> For me, the only acceptable way to do this would be in a way that
> does
> in no way make maintaining the Plasma / Wayland packages more
> difficult or burdensome, since the original intent of dropping the
> Plasma / X11 session was to *lower* the maintenance burden.

It is a false excuse and not true, is not more difficult nor
burdensome, we had many burdensome with the default be wayland and
hundreds of bugs opened and never fixed with crashes only on wayland
session .  

>  Adding
> back the Plasma / X11 session with separate packages might cause
> additional overhead for the KDE SIG (for example, needing to update
> kwin-x11 whenever there is a kwin update). 

is the opposite, KDE SIG are causing additional overhead to who want
use X11 and the package maintainer forcing use of wayland and why does
the will of KDE SIG have to prevail? 

I also maintain many KDE packages and I had a overhead with wayland
crashes 

> That would be the "usual"
> way to handle this according to Fedora policies.
> 

The usual is, if someone want maintain the package , they can maintain
it, no one complains about an hypothetical burden

> However, that would be counter to the original purpose of dropping
> the
> functionality from the packages maintained by the KDE SIG. But again,
> nobody can *force* package maintainers to support something they
> don't
> want to support. 

They don't have support X11 , they have the work of keep the removal of
X11 in their packages  .

Other thing that KDE SIG misses , is how testing , let says, as usual,
some app crash , and we ask have you wayland session or X11 session, if
you have wayland try X11 , if it runs at X11 and crash on wayland ,
this fact can help find the problem and not the opposite . 

also in kde-wayland you can run in x11 envoirment with env
QT_QPA_PLATFORM=xcb 

So just thinking removing this part of the functionalities on KDE ,
IMHO is lack of knowledge of graphics and bad for Fedora. IMHO the
future is have both technologies and not replace it 


Is very sad read that some people think in remove it and force people
use an technology that they think that don't have some important
features and issues in his opinions , is less important than false
argumentation , that will give burden . when they are burned to who
want use X11 




> So in this case, I think it would be good to have
> something like a clarification to the Updates Policy (and / or other
> policies, as necessary) for this case to resolve the contradiction -
> something like "updates for KDE Plasma packages are not required to
> be
> coordinated with packages for the Plasma / X11 session".
> 
> I'm also unsure how handling bug reports would best work in this
> situation. People *will* report bugs against the wrong components,
> causing additional work for the KDE SIG. (Hell, I'm getting bug
> reports filed against elementary / Pantheon packages, and there's not
> even a usable Pantheon session in Fedora yet!)
> 
> 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 Arch

Re: [heads up] mass rebuild for opencv 4.9.0 with soname bump on rawhide

[Sérgio Basto]

On Tue, 2024-02-06 at 16:06 +0100, Frantisek Zatloukal wrote:
> 
> 
> On Tue, Feb 6, 2024 at 3:55 PM Sérgio Basto 
> wrote:
> > On Tue, 2024-02-06 at 15:43 +0100, Frantisek Zatloukal wrote:
> > > 
> > > 
> > > On Tue, Feb 6, 2024 at 1:50 PM Sérgio Basto 
> > > wrote:
> > > > Mass rebuild finished and merge to rawhide [1].
> > > > Packages player and MLT are already FTBFS on Rawhide so I
> > > > didn't
> > > > touch
> > > > them .
> > > > 
> > > 
> > > 
> > > mlt is now FTI, do you plan to introduce opencv-compat to resolve
> > > that? 
> > 
> > I'm waiting for the gcc [1] fix, until then I think the best
> > solution
> > is not to update opencv.
> > 
> > Best regards,
> > 
> > [1]
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205
> > 
> 
> 
> Sure, wfm, I'll just keep in mind to rebuild krita then which will
> get doube-FTI'd after merging libjpeg-turbo (it currently is because 
> of mlt too). 

MLT built [1] (with one workaround for GCC for x86_64). 

[1]
https://bodhi.fedoraproject.org/updates/FEDORA-2024-7b5199d4f6

> 
> -- 
> 
> Best regards / S pozdravem,
> 
> František Zatloukal
> Senior Quality Engineer
> Red Hat

-- 
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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Sérgio Basto]

On Wed, 2024-02-07 at 16:03 +0100, Marc Deop i Argemí wrote:
> We are not banning nor deleting anything. We are not _supporting_ it.


you are removing X11 from the builds deliberately , when 
many people , members of Fedora on devel mailing list, express that
they want have X11 , in fact we have many people that defend keep X11 .

you set %bcond to 0 on kwin.spec [1] and plasma-workspace.spec [2]

on kwin.spec [3] you add 
%if ! %{with x11}
# Obsolete kwin-x11 as we are dropping the package
Obsoletes: %{name}-x11 < %{version}-%{release}
Conflicts: %{name}-x11 < %{version}-%{release}
%endif

[1]
https://src.fedoraproject.org/rpms/kwin/blob/rawhide/f/kwin.spec#_2

[2]
https://src.fedoraproject.org/rpms/plasma-workspace/blob/rawhide/f/plasma-workspace.spec#_2

[3]
https://src.fedoraproject.org/rpms/kwin/blob/rawhide/f/kwin.spec#_148


you are trying discuss semantic ?

http://languagelog.ldc.upenn.edu/myl/SemanticArgument1.png



Best regards,
-- 
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: Interesting difference between Koji and COPR (_isa macro)

[Sérgio Basto]

On Wed, 2024-01-24 at 17:56 +0100, Lumír Balhar wrote:
> Hello.
> 
> Today I found out an interesting difference between Koji and COPR. 
> autowrap package has this in its specfile:
> 
> Requires: python%{python3_pkgversion}-Cython%{?_isa}
> 
> Which is incorrect for noarch package but hold on. The resulting
> package 
> from Koji requires:
> 
> python3-Cython
> 
> but in COPR, the result requires:
> 
> python3-Cython(x86-64)
> 
> and that breaks subsequent builds in COPR because python3-Cython does
> not provide python3-Cython(x86-64).
> 
> In other words, if I rebuild autowrap in COPR and some other build
> later 
> tries to install it, the installation fails because nothing provides 
> python3-Cython(x86-64).
> 
> It seems like %{?_isa} is not defined for noarch packages in Koji but
> it 
> is in COPR. Is that a known problem/feature?
> 

Hi,
Maybe is off-topic, but I found other difference of building in corp
and building in koji and is trick one 

if I build a new package in copr, to exemplify, opencv where I removed
opencv.pc file, so every package that requires opencv.pc i.e. every
package which requires pkgconfig(opencv) will fail to build on koji ,
but not on copr, because koji works as just have one repo and there
just have the last opencv built while in copr opencv last build is
ignored and copr will use the previous opencv package that is in Fedora
repo.

In resume, please check if copr is pulling the correct packages to lead
to the right conclusions.  

Best regards,

> Thank you.
> 
> Lumír
> 
> P.S.: fix for autowrap: 
> https://src.fedoraproject.org/rpms/autowrap/pull-request/3
> --
> ___
> 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: [heads up] mass rebuild for opencv 4.9.0 with soname bump on rawhide

[Sérgio Basto]

On Tue, 2024-02-06 at 12:30 -0500, Yaakov Selkowitz wrote:
> On Tue, 2024-02-06 at 12:48 +0000, Sérgio Basto wrote:
> > On Mon, 2024-02-05 at 20:36 +0000, Sérgio Basto wrote:
> > > On Sun, 2024-02-04 at 19:59 +, Sérgio Basto wrote:
> > > > Hi,
> > > > 
> > > > I will start a mass rebuild 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 thing that prevent to proceeding.
> > > > 
> > > 
> > > mass rebuild started on side-tag  f40-build-side-82977
> > > 
> > 
> > Mass rebuild finished and merge to rawhide [1].
> > Packages player and MLT are already FTBFS on Rawhide so I didn't
> > touch
> > them .
> > 
> > [1]
> > https://bodhi.fedoraproject.org/updates/FEDORA-2024-f6619127ec
> 
> gstreamer1-plugins-bad-free was missed from this rebuild, which I
> just
> discovered thanks to an FTI bug.  I have kicked off a new build, but
> next time, please make sure you have a complete and current list of
> reverse dependencies.

OK, thanks, I did the check and also miss the caffe package , I'm
kicking the build now .

Best regards,
-- 
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: [heads up] mass rebuild for opencv 4.9.0 with soname bump on rawhide

[Sérgio Basto]

On Tue, 2024-02-06 at 15:43 +0100, Frantisek Zatloukal wrote:
> 
> 
> On Tue, Feb 6, 2024 at 1:50 PM Sérgio Basto 
> wrote:
> > Mass rebuild finished and merge to rawhide [1].
> > Packages player and MLT are already FTBFS on Rawhide so I didn't
> > touch
> > them .
> > 
> 
> 
> mlt is now FTI, do you plan to introduce opencv-compat to resolve
> that? 

I'm waiting for the gcc [1] fix, until then I think the best solution
is not to update opencv.

Best regards,

[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205

> -- 
> 
> Best regards / S pozdravem,
> 
> František Zatloukal
> Senior Quality Engineer
> Red Hat

-- 
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: [heads up] mass rebuild for opencv 4.9.0 with soname bump on rawhide

[Sérgio Basto]

On Mon, 2024-02-05 at 20:36 +, Sérgio Basto wrote:
> On Sun, 2024-02-04 at 19:59 +0000, Sérgio Basto wrote:
> > Hi,
> > 
> > I will start a mass rebuild 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 thing that prevent to proceeding.
> > 
> 
> mass rebuild started on side-tag  f40-build-side-82977
> 

Mass rebuild finished and merge to rawhide [1].
Packages player and MLT are already FTBFS on Rawhide so I didn't touch
them .

[1]
https://bodhi.fedoraproject.org/updates/FEDORA-2024-f6619127ec

> Best regards,
> 
> -- 
> 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

Re: [heads up] mass rebuild for opencv 4.9.0 with soname bump on rawhide

[Sérgio Basto]

On Sun, 2024-02-04 at 19:59 +, Sérgio Basto wrote:
> Hi,
> 
> I will start a mass rebuild 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 thing that prevent to proceeding.
> 

mass rebuild started on side-tag  f40-build-side-82977

Best regards,

-- 
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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Sérgio Basto]

On Sun, 2024-02-04 at 03:55 +0100, Kevin Kofler via devel wrote:
> Neal Gompa wrote:
> > It's extremely obvious that people want to use it. You replied to
> > someone who did and denigrated their opinion. Frankly, I'm
> > disappointed in your response as well as the tone of you and Kevin.
> 
> I cannot really speak for Sérgio. I do think his choice of words in
> the 
> particular mail you are referring to could have been better. (In
> particular, 
> I would not have used the word "crap" there.) But please keep in mind
> that 
> he (like me) is not a native English speaker.
> 

I haven't time to read all messages on this thread 

My conclusion is, we have false arguments , that Xorg is old, that is
not maintained, that will give more work , even we got some lies on
some arguments and when we disassemble these arguments, they came up
with new ones, now is the tone . I know would be very fancy only have 
wayland , modern  etc etc . But the true is they have the work of
remove X11 and not the opposite.

Other thought it is obvious that KDE 6 will be a disaster, I remember
Kevin step up from leader of KDE SIG, after move from KDE 3 for 4 or 4
for 5 because the work was too much and we need have a life. 

And the problem here is, we haven't an agreement , since the first day
of proposal many people said that was not acceptable and there opinions
were ignored and the proposal haven't changed one bit. 

I think, I and Kevin so be added to the KDE SIG , please add me at
least (here is the request) . 

I think is stupid and a waste of energy, IMO, do a kwin-x11 and plasma
-x11 , like I said KDE SIG had the work of remove X11 from the builds,
to enable kwin-x11 on Fedora Rawhide is just set %bcond to 1 on
kwin.spec [1] and plasma-workspace.spec [2], so I think that should be
enable. 
Another way is build the entire package with X11 and conflict with the
original because will give us less work and we will have less doubts or
user use packages from KDE SIG or user use packages from KDE-X11 SIG
and can't use both. Like happens with ffmpeg where also Neal haven't
reach to an agreement with members of RPMFusion , so now we have ffmpeg
from  RPMFUSion with one freeworld sub-package and we have fffmpeg-free
from Fedora and ffmpeg(s) conflicts each other .

It never happened to me such thing , except recently and all cases with
Neal directly involved, so I see Neal as the problem, was ImageMagick ,
was ffmpeg, was LSB , now KDE and one honest advice for Neal who
appears everywhere, try to do fewer things but be more focused


[1]
https://src.fedoraproject.org/rpms/kwin/blob/rawhide/f/kwin.spec#_2

[2]
https://src.fedoraproject.org/rpms/plasma-workspace/blob/rawhide/f/plasma-workspace.spec#_2




> I can, though, speak for myself, and I am frankly surprised that you
> are 
> offended by the tone of my messages. Are you sure that it is not the
> content 
> that upsets you rather than the tone? And if it is, try asking you
> why the 
> content upsets you. Maybe because it points out inconvenient facts?
> 
> > Neither of you are aligning with the Fedora Foundation of Friends,
> > and
> > the personal attacks were unwarranted and unwanted.
> 
> We (the KDE SIG and me) stopped being Friends when you (the KDE SIG) 
> unilaterally decided to ban me from all your communication channels,
> a ban 
> that has still not been lifted years after the alleged misconduct (on
> IRC 
> only, but the ban was extended to the mailing list and even your
> Pagure 
> issue trackers!) you accused me of.
> 
> Nevertheless, I am really trying hard to not make this personal. What
> I 
> disagree with is the technical decision to remove X11 support from
> the 
> Fedora Plasma packaging. I also objected right when you filed your
> Change 
> Proposal that the KDE SIG has no authority to declare in the Change
> that 
> Fedora will NOT ship something because other packagers are free to
> package 
> it. A belief that at the time was actually shared by the KDE SIG, or
> at 
> least by the one KDE SIG member who has publicly commented on it:
> https://discussion.fedoraproject.org/t/f40-change-proposal-kde-plasma-6-system-wide/89794/11
> Though the wording in the Change Proposal was not changed. Possibly
> because 
> you did not believe at the time that I was serious about submitting
> those 
> packages, just like others did not believe you were serious about
> removing 
> X11 support from Plasma packaging. But I am of the kind that when I
> promise 
> something, I tend to deliver on it.
> 
> > What we're doing is bold for sure, but aligns with two more of the
> > Fedora
> > Foundations, First and Features.
> 
> I can see how it aligns with "First", but how does removing a major
> feature 
> that users rely on align with "Features"?
> 
> I also believe that denying users the choice of continuing to use X11
> despite upstream still supporting it does not align with the
> "Freedom" and 
> "Friends" principles.
> 
> > And for the first time in a long time, Fedora KD

[heads up] mass rebuild for opencv 4.9.0 with soname bump on rawhide

[Sérgio Basto]

Hi,

I will start a mass rebuild 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 thing that prevent to proceeding.


Best regards,
-- 
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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Sérgio Basto]

On Fri, 2024-02-02 at 14:42 +0100, Kevin Kofler via devel wrote:
> Peter Hutterer wrote:
> > Fedora still ships the previous release, server 1.20.x
> 
> So should we not upgrade that to the latest upstream release (Xorg
> 21.0)?


I'm working on one pull request 
 
https://src.fedoraproject.org/fork/sergiomb/rpms/xorg-x11-server/c/ac2a6dbc9caa351f650f08461afe4196c756c801?branch=rawhide

builds still fails here: 
+ cp hw/dmx/doxygen/doxygen.conf.in /builddir/build/BUILDROOT/xorg-x11-
server-21.1.11-1.fc38.x86_64//usr/share/xorg-x11-server-
source/hw/dmx/doxygen/doxygen.conf.in
cp: cannot stat 'hw/dmx/doxygen/doxygen.conf.in': No such file or
directory



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


>     Kevin Kofler
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Sérgio Basto]

On Fri, 2024-02-02 at 01:34 -0600, Jonathan Bennett via devel wrote:
> Hey folks, outside observer, and long-time Fedora user weighing in
> with 
> some thoughts. First off, I've been hyped to see Fedora lead the way 
> with finally making a real move to Wayland, and retire X11. And now
> I'm 
> fairly disappointed to hear that there's a real chance that move will
> get killed. And especially that it's not because of a technical
> problem 
> or blocker bug.

I don't understand , why you want the others use a crap of software,
fully buggy, without many features , which is not supported by many
(like nvidia) , because is new ? 

Who wants use Wayland and test it, may use wayland and test it, it is
even the default .

It is really difficult to me understand your point of view , users
should be free to use what they want and have choices, It is really
weird (for me) that you want that I use wayland and test wayland .





> It really seems like KDE-x11 would do better to live in a copr, with 
> whatever packages needs rebuilt to make it work. Probably a better 
> experience for everyone.
> 



> The proposal was to go to KDE 6 and drop X11 support. " KDE Plasma
> will 
> not offer an X11 session" That change was approved by FESCo. And from
> my 
> perspective running Fedora  Rawhide and KDE 6, it looks great. We
> even 
> have HDR working! That's amazing! So let's go all in.
> 
> 
> --Jonathan Bennett
> --
> ___
> 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Sérgio Basto]

On Thu, 2024-02-01 at 15:31 +0100, Leon Fauster via devel wrote:
> Am 01.02.24 um 14:18 schrieb Sérgio Basto:
> 
> 
> > The problem is not KDE SIG not support X11, the problem is KDE SIG
> > want
> > drop X11 and force user to use wayland .
> 
> 
> Looking from the side I wonder If its the SIG or more the
> circumstances
> that everything is in a forward flow and the SIG is facing it. So, if
> the best time was not two or one year ago, and obviously also not
> now.
> When then? The fact is that there must be a point in time when the 
> display server takes an evolution step forward.
> 
> Pressure in such transition helps to get forward, so I understand the
> SIGs POV. Albeit, from the practical POV there are some issue and 
> therefore X11 is still the place to be.
> 
> Maybe some elaboration should be done about the current state of X11
> vs
> Wayland (is it just nvidia?) and a timeframe calculation to have a 
> resolution. Maybe it won't look so bad then and a interim solution is
> then more acceptable.


I have an obvious answer is when the authors decide, in this case Xorg,
when Xorg decides that it will stop supporting X11, like happened to
Python2 or PHP5 and 7 or Gnome 

In fact, it is something I've been thinking about, IMHO, downstream
shouldn't decide when software is deprecated or not like KDE and Red
HAt did , it's weird to me [1], although in RHEL we could have the
packages via EPEL, I think, and RHEL 10 is only in a year and a half 


[1]
https://www.reddit.com/r/linux/comments/13c7hfk/red_hat_considers_xorg_deprecated_and_will_remove/


> --
> Leon
> 
> 
> 
> 
> 
> 
> --
> ___
> 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Sérgio Basto]

On Thu, 2024-02-01 at 07:08 -0500, Steve Cossette wrote:
> So, if you all don't mind, I'd like to steer this discussion in a
> slightly different way: 
> 
> What is the definition of a Fedora Change Proposal?

Proposal was not accepted by many members of the community try accept
that .


> I was under the impression it was an announcement of intent by the
> maintainers of a specific subset of the fedora project to "change"
> something. Once said announcement has been discussed publicly, Fesco
> (Sorry if the capitals are incorrect) discusses it internally
> (albeit, publicly) and either blocks or approves the change, making
> it official.
> 
> (Please note: The following paragraphs will use "we" as a pronoun
> which is intended to be the Fedora project as a whole)
> 
> Once approved, we announced our intent to drop X11 from the KDE spin
> of Fedora. That announcement has gained traction everywhere, got
> publicized and everything. As Neal Gompa also stated, it has already
> caused some substantial development effort upstream to effectively
> iron out the rough edges of many of the problems, with what I assume
> is more to come.
> 
> My fear is that, while those x11 libraries/runtimes/... would indeed
> no longer be maintained by the KDE sig, we would basically just be
> partially rolling back that initial proposal. And the quality of said
> packages would also maybe suffer from them being updated separately,
> which might also reflect poorly on us (again, in this context, "us" =
> the Fedora Project).

First, KDE SIG people are not the only persons that support and
maintain KDE , I'm maintainer of smb4k , kdenlive, kwave , smplayer and
more packages related with KDE and Qt .

The problem is not KDE SIG not support X11, the problem is KDE SIG want
drop X11 and force user to use wayland .

The other problem is not reach to an agreement with some members of KDE
SIG , which they think that can impose his decisions .

> 
> It would also introduce a precedent: What if later a proposal is made
> to remove some old drivers from, let's say, the kernel, and someone
> decides to package it, undermining the general efforts of that
> proposal?
> 
> Hopefully I'm making sense. Writing this 30mins after waking up might
> not have helped. What I'm trying to say basically is, I get that for
> some legacy nvidia users the Wayland experience may not be optimal.
> But will it ever be? Does that mean we can never drop x11? Will
> anyone ever update those legacy nvidia drivers? Could they be?
> 
> Le mar. 30 janv. 2024, à 07 h 48, Sérgio Basto  a
> écrit :
> > Link to the FESCo ticket: https://pagure.io/fesco/issue/3165
> > 
> > and I'm very upset 
> > 
> > --
> > ___
> > 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: just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Sérgio Basto]

On Tue, 2024-01-30 at 09:57 -0500, Steven A. Falco wrote:
> On 1/30/24 08:55 AM, Richard W.M. Jones wrote:
> > On Tue, Jan 30, 2024 at 08:38:51AM -0500, Stephen Gallagher wrote:
> > > 3) Fedora has a long-standing and well-communicated stance that
> > > we are
> > > a Wayland distribution first and foremost and that X11 support is
> > > intended as a migration-support tool rather than a first-class
> > > citizen.
> > 
> > Does it?  This is very much news to me, so I don't think you can
> > call
> > it "well-communicated".  We also have an XFCE desktop spin and
> > probably others that require X11.
> > https://fedoraproject.org/uk/spins/xfce/
> > 
> > In addition Wayland doesn't actually replace all the basic
> > functionality of X11 even after all these years, which is why I
> > need
> > to use it.
> 
> I'm in the same boat.  Back in September when this topic came up,
> folks were invited to write bugs so the missing functionality could
> presumably be worked on.
> 
> I wrote two bugs:
> 
> Bug 2239016 - Plasma(Wayland) does not honor window positioning when
> setting window geometry
> Bug 2239029 - Plasma(Wayland) does not save windows between sessions
> 
> For 2239016 the response was "That's just how wayland works" and for
> 2239029 someone added a reference to an upstream KDE bug (from 2021).
> 
> I realize that this is a volunteer-driven project, and that I cannot
> expect someone to address the above wayland limitations, especially
> since the wayland design philosophy appears to exclude such features.
> 
> But that doesn't change the fact that I need the missing
> functionality, and based on how this discussion is going, I
> personally doubt wayland will ever meet my needs.
> 
> I'm delighted that there are like-minded folks who want to maintain
> X11.  Please allow them to do so.
> 
> Steve


Steven, thank you for the serene explanations and for highlighting an
important point about waynland, wayland seems to miss some important
features. 



> > > 4) There was a comment on the FESCo ticket to the effect of '"you
> > > must
> > > move to Wayland because no one maintains X11!". Here are some
> > > people
> > > who are maintaining X11 packages, so let them do their thing.'
> > > This is
> > > misleading, as the move to Wayland is specifically because the
> > > upstream of X11 *itself* is largely unmaintained. These packages
> > > are
> > > not maintaining X11, they are adding new dependencies on it.
> > 
> > They're maintaining parts of the X11 stack.
> > 
> > > My proposal for consideration is this:
> > > "FESCo will allow these packages in the main Fedora repositories,
> > > however they may not be included by default on any release-
> > > blocking
> > > deliverable (ISO, image, etc.)"
> > 
> > It seems quite strong.  I'm unclear why having X11 packages and
> > spins
> > for those that want to use them is a problem.  It seems like the
> > missing functionality of Wayland is the bigger issue that needs to
> > be
> > addressed.
> > 
> > Rich.
> > 
> --
> ___
> 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: A reminder: you cannot just "revert" package version bumps

[Sérgio Basto]

On Mon, 2024-01-29 at 16:33 -0800, Adam Williamson wrote:
> On 2024-01-29 16:00, Sérgio Basto wrote:
> > 
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_rawhide_is_allowed_to_lag_temporarily
> > 
> > you may do a new build with lower EVR
> 
> That is not what that guideline says. It says the Rawhide build can
> be 
> lower-versioned than a current build from *a different branch* 
> *temporarily*. It says nothing about allowing a new Rawhide build to
> be 
> lower versioned than the previous one.

that is what happened




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

just to let you know FESCo agreed to a preliminary injunction while we consider this issue

[Sérgio Basto]

Link to the FESCo ticket: https://pagure.io/fesco/issue/3165

and I'm very upset 
 
-- 
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: A reminder: you cannot just "revert" package version bumps

[Sérgio Basto]

On Mon, 2024-01-29 at 15:43 -0800, Adam Williamson wrote:
> nirik ran a script that checks for versioning issues in Rawhide
> today, 
> and it found several:
> https://pagure.io/releng/issue/11922#comment-893797
> 
> Some of these followed a pattern, so I figured a reminder was in
> order. 
> In all these cases, a new version was pushed to Rawhide, then
> "reverted" 
> some time later:
> 
> golang-github-nats-io-jwt - bumped to 2.4.1 in July, reverted to
> 1.2.2 
> in September
> golang-google-grpc - bumped to 1.58.0 in September, reverted to
> 1.48.0 
> in October; no 1.58.0 build ever landed, but the revert left the 
> %release much lower than before
> python-mizani - bumped to 0.10.0 on September 10, reverted to 0.9.3
> on 
> September 12
> python-pywlroots - bumped to 0.16.6 on November 4, reverted to 0.16.4
> later the same day
> 
> so the reminder is this: you cannot simply "downgrade" RPM package 
> versions like this. Especially not if the upgraded version ever made
> it 
> into a Rawhide compose.
> 
> If a Rawhide user has your package installed, and got the upgraded 
> version, they will be marooned on that build forever unless they 
> manually run `dnf distro-sync`. A `dnf upgrade` will not downgrade
> the 
> package to the build you now consider to be the "current" one.

yes rawhide user should use dnf distro-sync not dnf upgrade 

https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_rawhide_is_allowed_to_lag_temporarily

you may do a new build with lower EVR 


> If you have to downgrade a package that made it to a Rawhide compose,
> you must use an epoch. If the package did not have an epoch before,
> make 
> it `Epoch: 1`. If it had an epoch already, bump it by 1. People tend
> not 
> to like epochs, so *try* not to have to do this. Be really certain 
> before pushing out version bumps.
> 
> If the "upgraded" build never made it into a compose (as is likely
> the 
> case for python-pywlroots) you're *probably* okay, but it's still 
> something to be careful about - for instance you might fall into the 
> trap golang-google-grpc fell into with the %release tag.
> 
> Thanks folks!
> -- 
> 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

-- 
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: HELP! What's up with OpenVDB?

[Sérgio Basto]

On Sun, 2024-01-28 at 15:57 -0600, Richard Shaw wrote:
> On Sun, Jan 28, 2024 at 9:55 AM Ben Beasley 
> wrote:
> > Blender already excludes i686:
> > 
> > https://src.fedoraproject.org/rpms/blender/blob/8088da10c20e53ab0e1dd5de6fd3a2344bd288aa/f/blender.spec#_207
> > 
> > So does prusa-slicer:
> > 
> > https://src.fedoraproject.org/rpms/prusa-slicer/blob/44359e4b53c503cb61a60842abf991a01d1cb9db/f/prusa-slicer.spec#_68
> > 
> > Packages depending directly on openvdb are:
> > 
> > $ fedrq wrsrc -s openvdb
> > OpenImageIO-2.4.17.0-1.fc40.src
> > blender-1:4.0.2-1.fc40.src
> > luxcorerender-2.7-0.10.beta1.fc40.src
> > openvkl-2.0.0-5.fc40.src
> > prusa-slicer-2.4.2-13.fc40.src
> > usd-23.11-2.fc40.src
> > 
> > Of these, it looks like only OpenImageIO builds on i686. Packages 
> > depending on it are:
> > 
> > $ fedrq wrsrc -s OpenImageIO
> > OpenColorIO-2.2.1-6.fc40.src
> > blender-1:4.0.2-1.fc40.src
> > embree-4.3.0-2.fc40.src
> > luxcorerender-2.7-0.10.beta1.fc40.src
> > oidn-2.1.0-1.fc40.src
> > openshadinglanguage-1.12.14.0-9.fc40.src
> > usd-23.11-2.fc40.src
> > 
> > Of those, only OpenColorIO builds on i686. Packages depending on it
> > are:
> > 
> > $ fedrq wrsrc -s OpenColorIO
> > OpenImageIO-2.4.17.0-1.fc40.src
> > blender-1:4.0.2-1.fc40.src
> > calligra-3.2.1-25.fc39.src
> > krita-5.2.2-1.fc40.src
> > luxcorerender-2.7-0.10.beta1.fc40.src
> > usd-23.11-2.fc40.src
> > 
> > Of those, only calligra builds on i686, and it’s a leaf package.
> > So, if 
> > I haven’t missed anything, as long as i686 support is dropped from
> > all 
> > of calligra, OpenColorIO, OpenImageIO, and openvdb, then it should
> > be OK.
> > 
> 
> 
> Well I just re-tried openvdb with _smp_build_ncpus 1 and it still
> failed so I don't think we have a choice at this point. Perhaps it
> was hitting the 4GB max per process due to being 32bit?
> 

Have you try set in build the ulimit [1] .
On copr, copr already set the max number of files already by default
[2] have you check if you can build it on copr ? 


[1]
%build 
ulimit -n 4096

[2]
https://pagure.io/fedora-infra/ansible/blob/main/f/roles/copr/backend/files/provision/files/mock/site-defaults.cfg
https://pagure.io/fedora-infra/ansible/blob/main/f/roles/copr/backend/files/provision/provision_builder_tasks.yml#_176-186


> Thanks,
> Richard
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, 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

Heads Up: lxc-5.0.x on rawhide

[Sérgio Basto]

Hi, 

Unfortunately, I pushed  the commit to rawhide when I just wanted just
it to my fork first and make one PR. 

Anyway, lxc was ready to go and also lxc is a leaf package so the
impact should be small (otherwise it would have already reverted it).
So I triggered the build but if there is any inconvenient I may roll
back it. 

Happy hacking !
-- 
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

internal compiler error: in backward_pass, at tree-vect-slp.cc

[Sérgio Basto]

Hi,

MLT failed to build [2] with [1] , what do you suggest ? 

Best regards,

[1] 
builddir/build/BUILD/mlt-7.22.0/src/modules/gdk/pixops.c: In function
‘scale_line_22_yuv’:
/builddir/build/BUILD/mlt-7.22.0/src/modules/gdk/pixops.c:188:1:
internal compiler error: in backward_pass, at tree-vect-slp.cc:5346
  188 | scale_line_22_yuv ( int *weights, int n_x, int n_y,
  | ^
[ 33%] Building C object
src/modules/kdenlive/CMakeFiles/mltkdenlive.dir/filter_wave.c.o

[2] 
https://koji.fedoraproject.org/koji/buildinfo?buildID=2376836
https://kojipkgs.fedoraproject.org//work/tasks/7413/112327413/build.log

-- 
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: List of long term FTBFS packages to be retired in February

[Sérgio Basto]

On Wed, 2024-01-24 at 17:38 +0100, Miro Hrončok wrote:
> lmms thm

I fixed the build ,  I base it on opensuse packages
https://build.opensuse.org/package/rdiff/openSUSE:Backports:SLE-15-SP6/lmms?linkrev=base&rev=9


> lxc  hguemar, sagarun, thm

I'm also thinking update lxc from 4 to 5 based on
https://build.opensuse.org/package/show/openSUSE:Factory/lxc


-- 
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: Fedora 40 Mass Rebuild *finish* delayed

[Sérgio Basto]

On Wed, 2024-01-24 at 05:05 -0500, Neal Gompa wrote:
> On Wed, Jan 24, 2024 at 5:01 AM Miroslav Suchý 
> wrote:
> > 
> > Dne 24. 01. 24 v 10:51 Aoife Moloney napsal(a):
> > > 
> > > All other milestones remain the same at this time and the
> > > published schedule[4] has been updated to reflect these changes.
> > 
> > https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html
> > 
> > Branching is set to 2024-02-06 while mass rebuilds are supposed to
> > finish by 2024-02-20. That means we will branch
> > during mass rebuilds?
> > 
> > Historically we always branched *after* the mass rebuilds finishes.
> > 
> 
> Branching is supposed to move until after mass rebuild is done.

I hope so , we need clarify when branching will happen , I'm aware of 3
soname bump for post-mass-rebuild, protobuf [1] , opencv and jpegxl

[1] 
https://src.fedoraproject.org/rpms/protobuf/pull-request/26
thank you 

> -- 
> 真実はいつも一つ！/ Always, there's only one truth!
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, 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: Fedora 40 mass rebuild has begun

[Sérgio Basto]

On Fri, 2024-01-19 at 15:50 +0530, Samyak Jain wrote:
> Hi all,
> 
> Per the Fedora Linux f40 schedule [1] we started a mass rebuild on
> 2024-01-17 for Fedora f40 but due to various reasons such as dnf
> issues, and other side-tags not getting merged we had to stop it.
> But we finally managed to overcome those, and we fired the mass
> rebuild today
> We are running this mass rebuild for the changes listed in:
> 
> https://pagure.io/releng/issues?status=Open&tags=mass+rebuild&tags=f40&tags=changes
> 
> This mass rebuild is done in a side tag (f40-rebuild) and merged
> when completed.
> 
> Failures can be seen
> https://kojipkgs.fedoraproject.org/mass-rebuild/f40-failures.html
> 
> 

We should fix builds to rawhide , right ? or should we build in tag
f40-rebuild ?

> Things still need rebuilding
> https://kojipkgs.fedoraproject.org/mass-rebuild/f40-need-rebuild.html
> <
> https://kojipkgs.fedoraproject.org/mass-rebuild/f40-need-rebuild.html>
> 
> FTBFS (Fails To Build From Source) bugs will be filed after the
> mass rebuild is complete.
> 
> Please let releng know if you see any bugs in the reporting.
> You can contact releng in the #releng:fedoraproject.org room on
> Matrix,
> by dropping an email to our list [2] or filing an issue in pagure
> [3].
> 
> This email template is also in https://pagure.io/releng if you wish
> to
> propose improvements or changes to it.
> 
> Regards,
> Samyak Jain
> Fedora Release Engineering
> 
> [1] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html
> [2]
> https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
> [3] https://pagure.io/releng/
> --
> ___
> 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

-- 
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: Mass rebuild: git push --no-verify

[Sérgio Basto]

On Thu, 2024-01-18 at 09:13 -0700, Jerry James wrote:
> On Tue, Jan 16, 2024 at 3:32 PM Sérgio Basto 
> wrote:
> > You got mass rebuild script here [1] in massrebuildsinfo.py [2] you
> > may
> > define what packages you are going to rebuild ,  in line 93 of
> > mass-
> > rebuild.py [3] you got the list of packages that you go rebuild
> > and since line 132 [4] you have the commands that will run .
> > Is rpmdev-bumpspec that fails ?
> 
> Thank you for the pointer, Sérgio.  I have opened
> https://pagure.io/releng/pull-request/11897.
> 
> It is not rpmdev-bumpspec that fails.  That works just fine.  But any
> package that uses the %{fontpkgname1}, %{fontpkgname2}, ... macros
> requires --no-verify today when pushing to git, due to the referenced
> bug.  That's merely annoying for a human, but fatal to an automated
> build script that doesn't pass --noverify.

ok, is git push that fails .
As an idea , you may do "no verify" build option like noautobuild, in
line 143 of mass-rebuild.py [1] we have "Check for a noautobuild file"
to optout to skip mass rebuild, we may add an option in similar way for
noverify push, for example file "noverifybuild" . 

Kodi use noautobuild (and it works :) ) :
https://github.com/rpmfusion/kodi/ 
 
[1]
https://pagure.io/releng/blob/main/f/scripts/mass-rebuild.py#_143


> -- 
> Jerry James
> http://www.jamezone.org/
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, 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: HEADSUP boost and tbb rebuilds starting in a side tag

[Sérgio Basto]

On Fri, 2024-01-19 at 00:21 +, Jonathan Wakely wrote:
> On Fri, 19 Jan 2024 at 00:10, Jonathan Wakely 
> wrote:
> > 
> > On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely 
> > wrote:
> > > 
> > > I'll be building boost, tbb, and the packages that depend on them
> > > in
> > > the f40-build-side-81691
> > > side tag over the next few hours (in advance of the mass rebuild
> > > tomorrow).
> > > 
> > > If your package gets a "Rebuilt for Boost 1.83.0" comment, please
> > > don't rebuild it in rawhide, we're building it in the side tag
> > > and
> > > will merge it back to rawhide. If you need to update your package
> > > before the mass rebuild, please let me and Patrick (CC'd) know
> > > and
> > > your changes can be built in the side tag too.
> > 
> > Please DO NOT build your package in rawhide if we're rebuilding it
> > in
> > the boost side tag. It will require another rebuild in the side tag
> > and another bodhi update and delay the mass rebuild by several more
> > hours while the gating tests run.
> 
> OK, the side tag has been merged. Builds can be done in rawhide again
> now.


not yet , ttps://bodhi.fedoraproject.org/updates/FEDORA-2024-7c21b7afa2
needs pass in all "Test Gating" or is running again "Test Gating" for
new build(s)

> --
> ___
> 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: Mass rebuild: git push --no-verify

[Sérgio Basto]

On Tue, 2024-01-16 at 14:50 -0700, Jerry James wrote:
> Given the problems we had with font packages not being rebuilt in the
> last mass rebuild, can we ensure that the mass rebuild script uses
> "git push --no-verify" instead of plain "git push"?
> 
> See:
> - https://bugzilla.redhat.com/show_bug.cgi?id=2233878
> -
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7IIZPEC6B4BEOOOV5YFEUGOONNOH5LZO/


You got mass rebuild script here [1] in massrebuildsinfo.py [2] you may
define what packages you are going to rebuild ,  in line 93 of mass-
rebuild.py [3] you got the list of packages that you go rebuild  
and since line 132 [4] you have the commands that will run . 
Is rpmdev-bumpspec that fails ? 


[1]
https://pagure.io/releng/blob/main/f/scripts/mass-rebuild.py

[2]
https://pagure.io/releng/blob/main/f/scripts/massrebuildsinfo.py


[3] 
https://pagure.io/releng/blob/main/f/scripts/mass-rebuild.py#_93

[4]
https://pagure.io/releng/blob/main/f/scripts/mass-rebuild.py#_132

> -- 
> Jerry James
> http://www.jamezone.org/
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, 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: side-tag with GCC 14.0.1 snapshot for Fedora 40

[Sérgio Basto]

On Mon, 2024-01-15 at 14:01 +0100, Jakub Jelinek wrote:
> Hi!
> 
> The f40-build-side-81394 side-tag contains new
> gcc, annobin, libtool and redhat-rpm-config for f40, meant to be
> tagged into rawhide shortly before the mass rebuild.
> 
> If there is anything you'd like to rebuild against it before the mass
> rebuild (such as packages depending on Ada which like every year
> bumped
> sonames of its shared libraries), please do so soon.


I'd like bump soname of libjxl [1] and opencv 

[1]
https://src.fedoraproject.org/rpms/jpegxl 


> Jakub
> --
> ___
> 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: Proven to be sickened

[Sérgio Basto]

On Thu, 2023-12-07 at 11:41 +0100, Michal Schorm wrote:
> On Thu, Dec 7, 2023 at 11:21 AM Florian Weimer 
> wrote:
> > Asking individual maintainers for trivial changes does not scale. 
> > The
> > alternative would be not to address FTBFS and other build issues,
> > maybe
> > file bugs, and rely on active maintainers instead.
> 
> The alternative we want to achieve is:
> (1) write useful commit messages, so the reasons and goal of the
> proven package's commit would be clear
> and
> (2) give the maintainers the possibility to react. E.g. with a PR.
> No one responded to the PR in a week? Force merge it with proven
> packager rights.
> 

TL;DR;

Maybe we should have a flag in the src.fp.o package for the maintainer
to request a PR before committing to have a window for review, or like
me, the maintainer would like to not be bothered with things that
proven package can do by itself .

Another thing is some proven packager which wants force the move to
autothings , which I don't like use it, ATM, because in my opinion
still have many problems . 

> Even though I would want a longer time window and multiple iterations
> of trying to contact the maintainer,
> putting the PR up just for a week would make the current situation
> considerably better than it is.
> 
> I would expect the maintainers to only react on PRs in three general
> ways:
> (1) asking for more information = likely means you haven't explained
> the commit or the problem well
> that marks problem on your side
> (2) rejecting the PR for a good reason = likely means there's a
> problem with the implementation of your solution.
> that marks problem on your side
> (3) coming up with an alternative solution = likely means you haven't
> thought of package specific approaches
> You might find out the packager has a better idea how to solve the
> problem in general.
> Or you just collaborated nicely.
> 
> Each way leads to a valuable end, I believe.
> 
> There may be more ways to react (e.g. not react at all), but for now
> let's assume they are not significant, as you'd end up anyway using
> the proven packagers rights to force merge.
> 
> Michal
> 
> --
> 
> Michal Schorm
> Software Engineer
> Core Services - Databases Team
> Red Hat
> 
> --
> 
> On Thu, Dec 7, 2023 at 11:21 AM Florian Weimer 
> wrote:
> > 
> > * Kevin Kofler via devel:
> > 
> > > Michael J Gruber wrote:
> > > > I am sick of this. Really. I am so sick of this way of stomping
> > > > on each
> > > > others' feet.
> > > 
> > > My pet peeve is provenpackagers or comaintainers who add unwanted
> > > automagic (autorelease, autosetup, autochangelog) to my packages.
> > > I do
> > > not want any of that in my packages, it just makes my work harder
> > > (or
> > > in practice, just wastes my time for the revert that I am
> > > inevitably
> > > going to do).
> > 
> > If the package does not contain any patches yet, it's not really
> > possible to infer the maintainer intentions.  %setup vs %autosetup
> > doesn't matter much in that case, so it doesn't really tell us
> > anything.
> > Likewise if the package uses %autosetup, but without -p1, and there
> > are
> > no patches.  Does the maintainer really prefer those awkarward -p-
> > less
> > patches?  We don't know.
> > 
> > Asking individual maintainers for trivial changes does not scale. 
> > The
> > alternative would be not to address FTBFS and other build issues,
> > maybe
> > file bugs, and rely on active maintainers instead.  But I don't
> > think
> > that can work for Fedora, practically speaking.  Fedora lacks
> > Debian's
> > ban on forcing packagers to do certain work.  In the past, FESCo
> > has
> > used that to order that certain packagers must keep carrying out
> > certain
> > work they do not want to do, but I think that only means anything
> > if the
> > victim packager is a Red Hatter on certain teams, I think.  Others
> > will
> > just quit if they disagree.
> > 
> > Thanks,
> > Florian
> > --
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> > Do not reply to spam, 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-infrast

Re: Proven to be sickened

[Sérgio Basto]

On Fri, 2023-12-01 at 16:26 +0100, Michael J Gruber wrote:
> So, due to me following my package (notmuch) upstream and testing
> early against upstream's git, reporting and working with upstream, I
> noticed a FTBFS and helped fixing it. Nothing urgent since it was
> basically just a test failing for the wrong reasons.
> 
> Within a few days, upstream releases a patch release. Within hours,
> I'm testing (again, since it's basically what was on git already) on
> copr and koji, writing a nice commit message, push to rawhide ...
> 
> ... and get a reject because someone thought that pushing directly
> without asking or at least notifying the maintainer would be in
> order:
> 
> https://src.fedoraproject.org/rpms/notmuch/c/f0d84b417694430874a150293ffdb1fdc35c7b31?branch=rawhide


> Why? For a FTBFS due to a test? No bugzilla, no FTI, no security
> issue whatsoever?
> 

You may kindly ask to mtasaka why did it ? , and also alert him that
package is well maintain and have a quick response and kindly ask to do
PR instead , he is one provenpackager and I sure that he did that in
hope of improve the package, I'm sure that he will understand. 

Best regards,



> I am sick of this. Really. I am so sick of this way of stomping on
> each others' feet.
> 
> It's made worse by failing automated notifications, of course. Not
> from pagure about the push nor from koji about the build nor from
> bodhi about the update.
> 
> Dunno whether it's the new fmn or what. That works for *my* actions
> with pagure/bodhi/koji but fails to report copr actions to me, and
> apparently also actions by others.
> 
> Thanks for listening ...
> 
> 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

-- 
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: How can I delete a rawhide Bodhi update?

[Sérgio Basto]

On Thu, 2023-11-23 at 20:40 +0100, Florian Weimer wrote:
> * Mattia Verga via devel:
> 
> > Il 23/11/23 16:40, Florian Weimer ha scritto:
> > > I've got an update that I don't see pushed to stable.  How do I
> > > make
> > > sure that doesn't happen?
> > > 
> > > As it's for rawhide, I didn't create the Bodhi update, and I
> > > don't see
> > > an option to delete it.
> > > 
> > There's no option to delete Bodhi updates. It can only be done by 
> > hacking the database directly, but it is usually never necessary.
> > 
> > I assume you're referring to 
> > https://bodhi.fedoraproject.org/updates/FEDORA-2023-13783978e8.
> > That 
> > update will never be pushed to stable, since it is gated by failed 
> > tests.
> 
> Half a dozen people can waive those tests, and there have been
> incorrect
> waivers before. 8-/
> 

https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_rawhide_is_allowed_to_lag_temporarily

you may do a new build with lower EVR 


> I just want to make sure the update  doesn't proceed because I'm not
> entirely confident that the fix I have is logically correct.
> 
> Thanks,
> Florian
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, 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