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

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

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

[EPEL-devel] Re: EPEL9 updates obsoleted

[Sérgio Basto]

Following Fabio Valentini tip ,

One thing you *could* try is do a new side-tag and move the builds to
there .

and example of move build : 

koji move-build epel8-testing-candidate epel8-build-side-52356
ImageMagick-6.9.12.44-1.el8


On Tue, 2024-04-09 at 11:46 +0200, Antonio T. sagitter wrote:
> Yes, but i can't because the side-tag is already used.
> 
> On 08/04/24 09:52, Sandro wrote:
> > On 07-04-2024 19:04, Antonio T. sagitter wrote:
> > > Can this update be re-activated or i have to rebuild everything?
> > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-c154b725ab
> > 
> > Have you tried re-submitting the side tag to Bodhi?
> > -- 
> > ___
> > epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> > To unsubscribe send an email to
> > epel-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: 
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> > Do not reply to spam, report it: 
> > https://pagure.io/fedora-infrastructure/new_issue
> 
> -- 
> ---
> Antonio Trande
> Fedora Project
> https://fedoraproject.org/wiki/User:Sagitter
> mailto: sagit...@fedoraproject.org
> GPG key: 0x40FDA7B70789A9CD
> GPG keys server: https://keys.openpgp.org/

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

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.
> >  
> > Fedora Serve

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

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 -

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
> > use an technology th

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 Archives:
> https://lists.fedoraproject.o

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 

[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=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=mass+rebuild=f40=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:
> 

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

Re: Why I won't run for FESCo

[Sérgio Basto]

On Wed, 2023-11-22 at 20:40 +0100, Miro Hrončok wrote:
> The communication channels 

yeah , I had to go back to IRC if I want to communicate with certain
groups.
We went to Matrix because there was a bridge with IRC, but many people
didn't switch from IRC, the bridge collapsed and now we have half the
people on one side and half on the other ...

https://matrix.org/blog/2023/08/libera-bridge-disabled/

Thank you Miro for all the work

Another though , IMO,  we should rethink the packaging rules, I have
always defended, we should avoid the excessive number of packages for
the same software and pack it all in one.
A simple example is rpkg , rpkg-utils , fedpkg and centospkg . I think
it should be one package or two and at most with several sub-packages.
Now, argue to me, that as they are different sources, they must be
different packages, when utils is one or two small files and doesn't
work without the main package rpkg. In my opinion, results in excessive
work without any benefit, just to comply with a rule or a guideline. 

Other example , for example is kmodtools and akmods , one doesn't work
without the other, why we should pack 2 packages, do 2 commits , 2 push
, 2 builds , 2 updates etc etc . and guarantee that versions match ! I
don't see any benefit .

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: Inactive packages removed from packager group

[Sérgio Basto]

On Mon, 2023-11-20 at 08:27 +1100, Arthur G wrote:
> I recall a number of years back a proposed gcc upgrade broke many
> builds. This required most maintainers to log in and refactor their
> source code against the new gcc (and new gcc options).
> 
> I hadn't logged into Fedora for years however I did do my due
> diligence and rather quickly logged in and fixed any issues.
> 
> The recent move to remove inactive maintainers from the maintainers
> group is something I fully agree with for reasons of security against
> the current limitations of the maintainer privileges framework.
> 
> However, this latest move to orphan packages that don't have
> maintainers seems rather clandestine as it's not related to security
> but rather a byproduct of the point mentioned above. If security
> wasn't an issue in the first place then we wouldn't be having this
> discussion.


orphan list is here:  https://churchyard.fedorapeople.org/orphans.txt 

you got the date and hour of report ( Report started at 2023-11-19
20:20:42 UTC ) so you know if is updated or not . 


> I wonder what spectacle will ensue should we ever need to refactor
> the source code again for extraneous reasons only to find a
> significant part of the maintainer cohort needs to go through the
> proven maintainer process again.
> 
> 
>  
> 
> On Sun, 19 Nov 2023 at 07:09, Kevin Fenzi  wrote:
> > Hi all,
> > 
> > Today, 2023-11-18, we have removed inactive packagers
> > from the packager group.
> > 
> > This is in accordance with the FESCo policy on inactive packagers:
> > https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/
> > 
> > If the removed user is 'main admin' for a package, this package
> > will be orphaned. If there are co-maintainers for the package,
> > one of them should take the role of 'main admin',
> > by clicking "✋ Take" on
> > `https://src.fedoraproject.org/rpms/`".
> > 
> > Otherwise any packager may take the package while it's orphaned.
> > After 6 weeks, the package will be retired.
> > After another 8 weeks, a new review is needed to unretire it.
> > see
> > https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_packages/
> > for more details.
> > 
> > More details available in
> > https://pagure.io/fedora-infrastructure/issue/11621
> > 
> > Packages that have been orphaned are:
> > 
> > rpms/gtksourceview5
> > rpms/python-typing-inspect
> > rpms/xorg-x11-drv-qxl
> > rpms/coin-or-lemon
> > rpms/fish
> > rpms/nvme-cli
> > rpms/u2f-hidraw-policy
> > rpms/virtme
> > rpms/elementary-onboarding
> > rpms/vala-language-server
> > rpms/perl-MooseX-Role-Matcher
> > rpms/perl-Net-Google-AuthSub
> > rpms/drupal7-advanced_help
> > rpms/drupal7-auto_nodetitle
> > rpms/drupal7-calendar
> > rpms/drupal7-ckeditor
> > rpms/drupal7-date_ical
> > rpms/drupal7-email
> > rpms/drupal7-features
> > rpms/drupal7-feeds
> > rpms/drupal7-flexifilter
> > rpms/drupal7-footnotes
> > rpms/drupal7-google_analytics
> > rpms/drupal7-honeypot
> > rpms/drupal7-job_scheduler
> > rpms/drupal7-mediawiki_api
> > rpms/drupal7-module_filter
> > rpms/drupal7-panels
> > rpms/drupal7-pathauto
> > rpms/drupal7-rules
> > rpms/drupal7-site_map
> > rpms/drupal7-strongarm
> > rpms/drupal7-theme-adaptivetheme
> > rpms/drupal7-token
> > rpms/drupal7-views_bulk_operations
> > rpms/drupal7-views_slideshow
> > rpms/drupal7-webform
> > rpms/drupal7-workbench
> > rpms/drupal7-workbench_moderation
> > rpms/drupal7-xmlsitemap
> > rpms/python-ironicclient
> > rpms/qtractor
> > rpms/rtirq
> > rpms/dropbear
> > rpms/byzanz
> > rpms/cairo
> > rpms/golang-github-elithrar-simple-scrypt
> > rpms/golang-github-kurin-blazer
> > rpms/golang-github-minio
> > rpms/golang-github-pkg-xattr
> > rpms/golang-github-restic-chunker
> > rpms/restic
> > rpms/aspell-ar
> > rpms/aspell-he
> > rpms/bidiv
> > rpms/hspell
> > rpms/hunspell-ar
> > rpms/python-pthreading
> > rpms/taarich
> > rpms/tex-fonts-hebrew
> > rpms/golang-rsc-pdf
> > rpms/wavbreaker
> > rpms/python-timeunit
> > rpms/python-vagrantpy
> > rpms/streamtuner
> > rpms/bird
> > rpms/ovirt-guest-agent
> > rpms/vsqlite++
> > rpms/dovecot-fts-xapian
> > rpms/VirtualGL
> > rpms/python-autograd
> > rpms/python-read-roi
> > rpms/byobu
> > rpms/kflickr
> > rpms/nfacct
> > rpms/perl-Audio-Beep
> > rpms/perl-CDDB
> > rpms/perl-Getopt-Simple
> > rpms/perl-NetPacket-LLC
> > rpms/perl-NetPacket-SpanningTree
> > rpms/perl-Pod-Coverage-Moose
> > rpms/perl-Proc-Simple
> > rpms/perl-XML-Parser-Lite-Tree-XPath
> > rpms/rust-atomic
> > rpms/rust-binascii
> > rpms/rust-cfb
> > rpms/rust-email-encoding
> > rpms/rust-infer
> > rpms/rust-inlinable_string
> > rpms/rust-multer
> > rpms/rust-rmpv
> > rpms/rust-serde_qs
> > rpms/rust-totp-lite
> > rpms/rust-ubyte
> > container/glusterfs
> > rpms/python-oslo-vmware
> > rpms/perl-Hash-Diff
> > rpms/perl-Test-Script-Run
> > rpms/esc
> > rpms/bash-completion-extras
> > rpms/apiextractor
> > rpms/appmenu-qt
> > rpms/arora
> > rpms/beefy-miracle-kde-theme
> > rpms/bluedevil
> > rpms/cagibi
> 

Re: Missing notifications

[Sérgio Basto]

I think the problem on src.fp.o
is 
https://lists.fedorahosted.org/archives/list/devel@lists.fedoraproject.org/message/EHDPRFVIWWN33XVWPPZ4HFADDZ64BPBK/
 

On Sun, 2023-11-19 at 15:13 -0500, Stephen Smoogen wrote:
> 
> It could be due to the retirement of the old notifications system
> earlier this month. See the email "intent to retire: fedmsg-irc, old
> fmn, osbs" sent to the mailing list earlier.
> 
> FMN is the tool which sends notifications and it was replaced with a
> newer version earlier this year. Here is the April announcement:
> ```
> The FMN replacement team has finished writing the new version of our
> notification system, and we are ready to deploy! We plan on deploying
> the new version on https://notifications.fedoraproject.org this week,
> we'll keep the old one around but move it to
> https://apps.fedoraproject.org/notifications-old, and redirect from
> https://apps.fedoraproject.org/notifications to the new place,
> notifications.fedoraproject.org.
> 
> You will thus still be able to access the current FMN, and it will
> keep running until F39. Due to the difference in features, we can't
> import existing rules into the new system, so we encourage you to
> create new rules that suit you as soon as the new system is up and
> running.
> 
> The change of URLs will happen with the planned outage set for
> 2023-04-24 08:30 UTC (this Wednesday), see ticket 11266
>  for details.
> 
> If you have issues with the new FMN, please open infra tickets at:
> https://pagure.io/fedora-infrastructure/new_issue
> 
> We hope you will enjoy the simpler UI and faster processing speed
> that
> the new FMN brings.
> ```
> 
> On Sun, 19 Nov 2023 at 14:45, Christiano Anderson
>  wrote:
> > Hi,
> > 
> > Same issue here. I noticed that I'm not getting regular
> > notifications, even from BZ.
> > 
> > Thanks 
> > 
> > On Sunday, 19 November 2023 at 20:19, Mikel Olasagasti
> >  wrote:
> > 
> > 
> > > Hi,
> > > 
> > > I'm not receiving mails from some updates like koschei build
> > status or
> > > src.f.o commits.
> > > 
> > > Has something changed in this regard or is it the mail service
> > having
> > > issues again?
> > > 
> > > Kind regards,
> > > Mikel
> > > --
> > > ___
> > > 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
> 
> 
> -- 
> 
> Stephen Smoogen, Red Hat Automotive
> Let us be kind to one another, for most of us are fighting a hard
> battle. -- Ian MacClaren
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

-- 
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: Inactive packages removed from packager group

[Sérgio Basto]

On Sat, 2023-11-18 at 21:57 +0100, Sandro wrote:
> On 18-11-2023 21:08, Kevin Fenzi wrote:
> > After 6 weeks, the package will be retired.
> > After another 8 weeks, a new review is needed to unretire it.
> > see
> > https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_re
> > tired_packages/
> > for more details.
> 
> I'm wondering if there shouldn't be some impact assessment comparable
> to 
> the "orphaned packages looking for new maintainer" mail.
> 
> Or will that happen with the next round of "orphaned packages ..."?


yes, in next "orphaned packages looking for new maintainer" these
packages will appear there 


> I think ordering the list of orphaned packages alphabetically would
> make 
> it easier to pinpoint packages one may be interested in or depend on.
> 
> -- Sandro
> --
> ___
> 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

[EPEL-devel] Re: Packages to be untagged from epel-next

[Sérgio Basto]

On Sat, 2023-11-18 at 09:35 +0200, Tuomo Soini wrote:
> On Fri, 17 Nov 2023 21:31:37 +
> Sérgio Basto  wrote:
> 
> > Hi, 
> > Is not an negative feedback, is a side note but I realize some time
> > ago that version with next is bigger than version without next [1]
> > therefore we should find a way that the el8 version be greater than
> > the el8.next version.
> > 
> > 
> > [1] 
> > 
> > rpmdev-vercmp 1.el8.next 1.el8
> > 
> > 1.el8.next > 1.el8
> > 
> 
> I already suggested adding requirement to do a release bump when
> building from epel-next to epel.
> 
> https://pagure.io/epel/pull-request/259
> 
> I find it important that new, compatible with new rhel build has
> bigger
> version-release than epel-next build.
> 

I just tested 

rpmdev-vercmp 1.el8.next 1.el8
1.el8.next > 1.el8

rpmdev-vercmp 1.el8.next 1.el8.1
1.el8.next < 1.el8.1


so rpmdev-bumpspec --rightmost is enough 


> -- 
> Tuomo Soini 
> Foobar Linux services
> +358 40 5240030
> Foobar Oy <https://foobar.fi/>
> --
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to
> epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

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

[EPEL-devel] Re: Packages to be untagged from epel-next

[Sérgio Basto]

Hi, 
Is not an negative feedback, is a side note but I realize some time
ago that version with next is bigger than version without next [1]
therefore we should find a way that the el8 version be greater than the
el8.next version.


[1] 

rpmdev-vercmp 1.el8.next 1.el8

1.el8.next > 1.el8



On Fri, 2023-11-17 at 09:24 -0800, Troy Dawson wrote:
> I haven't heard any negative feedback from these.
> I will untag these today.
> 
> On Wed, Nov 15, 2023 at 12:55 PM Troy Dawson 
> wrote:
> > The following packages have the same version in epel-next as in
> > epel.
> > I plan on untagging them from epel-next unless people tell me
> > otherwise.
> > 
> > epel8-next:
> > boinc-client-7.20.2-1.el8.next
> > darktable-3.8.1-2.el8.next
> > kimageannotator-0.6.1-1.el8.next
> > ksnip-1.10.1-1.el8.next
> > python3.11-dns-epel-2.2.1-2.el8.next
> > python3.11-jmespath-epel-1.0.1-1.el8.next
> > 
> > epel9-next:
> > cargo2rpm-0.1.13-1.el9.next
> > keepassxc-2.7.6-1.el9.next
> > python3.11-dns-epel-2.2.1-2.el9.next
> > python3.11-jmespath-epel-1.0.1-1.el9.next
> > python3.11-netaddr-epel-0.8.0-1.el9.next
> > python3.11-ntlm-auth-epel-1.5.0-1.el9.next
> > rust-addr2line-0.19.0-1.el9.next
> > rust-aho-corasick-1.1.2-1.el9.next
> > rust-ansiterm-0.12.2-1.el9.next
> > rust-arbitrary-1.3.0-1.el9.next
> > rust-automod-1.0.13-1.el9.next
> > rust-backtrace-0.3.67-2.el9.next
> > rust-bitflags-2.4.1-1.el9.next
> > rust-bstr0.2-0.2.17-1.el9.next
> > rust-bstr-1.7.0-1.el9.next
> > rust-bumpalo-3.14.0-1.el9.next
> > rust-bytesize-1.3.0-1.el9.next
> > rust-byte-unit-4.0.19-1.el9.next
> > rust-cargo-0.64.0-3.el9.next
> > rust-clap3-3.2.25-1.el9.next
> > rust-clap_complete3-3.2.5-1.el9.next
> > rust-clap_derive3-3.2.25-1.el9.next
> > rust-crossbeam-epoch-0.9.15-2.el9.next
> > rust-csv-1.3.0-1.el9.next
> > rust-csv-core-0.1.11-1.el9.next
> > rust-ctor-0.2.5-1.el9.next
> > rust-deranged-0.3.8-1.el9.next
> > rust-directories4-4.0.1-1.el9.next
> > rust-directories-5.0.1-1.el9.next
> > rust-env_logger-0.10.0-1.el9.next
> > rust-env_logger0.9-0.9.3-1.el9.next
> > rust-grep-cli-0.1.7-1.el9.next
> > rust-grep-printer-0.1.7-1.el9.next
> > rust-grep-regex-0.1.11-1.el9.next
> > rust-grep-searcher-0.1.11-1.el9.next
> > rust-half1-1.8.2-1.el9.next
> > rust-hashbrown-0.14.2-1.el9.next
> > rust-ignore-0.4.20-1.el9.next
> > rust-indexmap-2.0.2-1.el9.next
> > rust-is_executable-1.0.1-1.el9.next
> > rust-jobserver-0.1.27-1.el9.next
> > rust-lexopt-0.3.0-1.el9.next
> > rust-libc-0.2.149-1.el9.next
> > rust-libm-0.2.8-1.el9.next
> > rust-lock_api-0.4.11-1.el9.next
> > rust-memchr-2.6.4-1.el9.next
> > rust-miniz_oxide0.5-0.5.4-1.el9.next
> > rust-miniz_oxide-0.7.1-3.el9.next
> > rust-num_enum-0.5.11-1.el9.next
> > rust-num_enum_derive-0.5.11-1.el9.next
> > rust-num-traits-0.2.17-1.el9.next
> > rust-object-0.30.3-1.el9.next
> > rust-os_pipe0.9-0.9.2-3.el9.next
> > rust-os_str_bytes-6.6.1-1.el9.next
> > rust-packaging-25.2-1.el9.next
> > rust-parking_lot_core-0.9.9-1.el9.next
> > rust-predicates-core-1.0.6-1.el9.next
> > rust-print_bytes-1.2.0-1.el9.next
> > rust-proc-macro2-1.0.69-1.el9.next
> > rust-rayon-1.8.0-1.el9.next
> > rust-rayon-core-1.12.0-1.el9.next
> > rust-regex-1.10.2-1.el9.next
> > rust-regex-automata-0.4.3-1.el9.next
> > rust-regex-syntax0.7-0.7.5-1.el9.next
> > rust-regex-syntax-0.8.2-1.el9.next
> > rust-relative-path-1.9.0-1.el9.next
> > rust-roff0.1-0.1.0-1.el9.next
> > rust-roff-0.2.1-1.el9.next
> > rust-rpassword5-5.0.1-1.el9.next
> > rust-rpassword-7.2.0-1.el9.next
> > rust-rstest-0.18.2-1.el9.next
> > rust-rstest_macros-0.18.2-1.el9.next
> > rust-rstest_reuse-0.6.0-1.el9.next
> > rust-rtoolbox-0.0.1-1.el9.next
> > rust-rust_decimal-1.32.0-1.el9.next
> > rust-serde-1.0.189-1.el9.next
> > rust-serde_derive-1.0.189-1.el9.next
> > rust-serde_json-1.0.107-1.el9.next
> > rust-shared_child-1.0.0-3.el9.next
> > rust-smallvec-1.11.1-1.el9.next
> > rust-strip-ansi-escapes0.1-0.1.1-1.el9.next
> > rust-strip-ansi-escapes-0.2.0-1.el9.next
> > rust-syn-2.0.38-1.el9.next
> > rust-system-deps-6.1.2-1.el9.next
> > rust-tempfile-3.8.0-1.el9.next
> > rust-termcolor-1.3.0-1.el9.next
> > rust-terminal_size0.2-0.2.6-1.el9.next
> > rust-terminal_size-0.3.0-1.el9.next
> > rust-textwrap0.15-0.15.2-1.el9.next
> > rust-textwrap-0.16.0-1.el9.next
> > rust-thread-id-4.2.1-1.el9.next
> > rust-timeago-0.4.2-1.el9.next
> > rust-time-core-0.1.1-1.el9.next
> > rust-toml0.5-0.5.11-1.el9.next
> > rust-toml0.7-0.7.8-1.el9.next
> > rust-toml-0.8.2-1.el9.next
> > rust-toml_edit0.19-0.19.15-1.el9.next
> > rust-toml_edit-0.20.2-1.el9.next
> > rust-ucd-parse-0.1.10-1.el9.next
> > rust-winnow0.4-0.4.11-1.el9.next
> > rust-winnow-0.5.16-1.el9.next
> > rust-xml-rs-0.8.19-1.el9.next
> > 
> > 
> > Troy
> > 
> --
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to
> epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/

Re: Automate your Fedora package maintenance using Packit

[Sérgio Basto]

Hi, 

have we an example working ? 

 I'd like had packit
for https://src.fedoraproject.org/rpms/libphonenumber 

Upstream Release Monitoring report here:
https://bugzilla.redhat.com/show_bug.cgi?id=2237976


I'd like have the pull request , koji_build   and bohi update 


Thank you,




On Fri, 2023-09-15 at 09:22 +0200, Laura Barcziova wrote:
> If you're a Fedora package maintainer, we've got an exciting
> automation solution for you!
> 
> At the beginning of the year, we announced a new feature called
> pull_from_upstream that eases the process of bringing upstream
> releases into Fedora. This feature can be easily configured directly
> in the dist-git repository without access to the upstream (as opposed
> to our previously introduced automation). It is most suitable for
> simple packages with straightforward update processes (e.g. without
> patches, or need to build in side tags).
> 
> Our automation works on top of the Upstream Release Monitoring [1],
> and here's how to set it up:
> 
>    1. Enable Upstream Release Monitoring for your Fedora package: set
> the mapping of the project in Anitya and in the left column in
> https://src.fedoraproject.org/rpms/$YourPackage, change Monitoring
> status to Monitoring.
>    2. Add the Packit configuration with the pull_from_upstream job to
> your dist-git repository (see example
> https://packit.dev/docs/configuration/downstream/pull_from_upstream#e
> xample).
> Once set up, here's how it works:
>  * Upstream Release Monitoring creates a Bugzilla bug when new
> upstream versions are detected.
>  * As a reaction to that, Packit:
> - automatically uploads the upstream archive to the lookaside
> cache,
> - creates dist-git pull request(s) at
> https://src.fedoraproject.org/ with all the necessary changes, like
> updates to the specfile and sources.
> If you are interested in this, read the previously published full
> post with the details of the setup here:
> https://packit.dev/posts/pull-from-upstream. Since the publication of
> this post, many users have adopted this feature and provided valuable
> feedback, allowing us to enhance the UX. We're now excited to assist
> you in automating the process as well! 
> 
> In addition to creating pull requests in dist-git, Packit can also
> automate Koji builds and Bodhi updates:
>  * https://packit.dev/docs/configuration/downstream/koji_build 
>  * https://packit.dev/docs/configuration/downstream/bodhi_update
> 
> For complete automation documentation, don't miss our comprehensive
> Fedora release guide at: https://packit.dev/docs/fedora-releases-
> guide. It contains all the essential information and setup tips.
> 
> For any questions, feel free to contact us:
> https://packit.dev/#contact.
> 
> Best regards,
> 
> Packit team!
> 
> [1] https://docs.fedoraproject.org/en-US/package-
> maintainers/Upstream_Release_Monitoring/
> ___
> 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.fedoraproje
> ct.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: Update SFML from 2.5.1 to 2.6.1 with soname bump coming to rawhide (finished)

[Sérgio Basto]

On Sun, 2023-11-05 at 19:00 +, Sérgio Basto wrote:
> Hi,
> 
> SFML will be build in sidetag f40-build-side-77060 . 
> 
> These packages will be rebuild : 
> CSFML
> attract-mode
> dolphin-emu
> extremetuxracer
> gravity-beams-and-evaporating-stars
> marsshooter
> ostrichriders
> visualboyadvance-m
> 

All packages rebuilt successfully 

https://bodhi.fedoraproject.org/updates/FEDORA-2023-1acd529e5c


> 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

Heads up: Update SFML from 2.5.1 to 2.6.1 with soname bump coming to rawhide

[Sérgio Basto]

Hi,

SFML will be build in sidetag f40-build-side-77060 . 

These packages will be rebuild : 
CSFML
attract-mode
dolphin-emu
extremetuxracer
gravity-beams-and-evaporating-stars
marsshooter
ostrichriders
visualboyadvance-m

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: python-3.12 distutils removal just happened after python mass rebuild and Fedora mass rebuild ?

[Sérgio Basto]

On Fri, 2023-09-29 at 23:20 +0100, Sérgio Basto wrote:
> On Fri, 2023-09-29 at 23:42 +0200, Miro Hrončok wrote:
> > On 29. 09. 23 23:38, Miro Hrončok wrote:
> > > On 29. 09. 23 20:32, Sérgio Basto wrote:
> > > > Hi,
> > > 
> > > Hi.
> > > 
> > > > Recent build of some packages like opencv and an old gpgme
> > > > shows
> > > > that
> > > > python-3.12 disutils has gone for good , but just after all
> > > > mass
> > > > rebuilds and recently , what you advice to do ?
> > > 
> > > It has been gone for since the Python 3.12 rebuild in June.
> > > 
> > > Perhaps some required package transitively pulled in python3-
> > > setuptools? That 
> > > package provides it's own (forked) implementation of distutils.
> > > 
> > > > Any quick way to replace distutils ? the python 3.12 final
> > > > release,
> > > > currently is scheduled for 2023-10-02 ...
> > > 
> > > For building, I encourage trying to BuildRequire python3-
> > > setuptools
> > > and 
> > > observing if it helps.
> > > 
> 
> 
> aaah , BuildRequire python3-setuptools fix old gpgme package , and
> this
> is a good new for me :) 
> 
> without  python3-setuptools 
> https://copr.fedorainfracloud.org/coprs/sergiomb/python2/build/6475479/
> https://download.copr.fedorainfracloud.org/results/sergiomb/python2/fedora-39-aarch64/06475479-gpgme/builder-live.log.gz
> checking for the distutils Python package... no
> configure: error: cannot import Python module "distutils".
> Please check your Python installation. The error was:
> Traceback (most recent call last):
>   File "", line 1, in 
> ModuleNotFoundError: No module named 'distutils'
> 
> and with python3-setuptools 
> https://copr.fedorainfracloud.org/coprs/sergiomb/python2/build/6475513/
> 
> > > Some links with actual build failures would be helpful.
> > 
> > The failure in
> > https://koschei.fedoraproject.org/package/opencv looks
> > like:
> > 
> > Traceback (most recent call last):
> >    File "", line 1, in 
> > ModuleNotFoundError: No module named 'numpy.distutils'
> > 
> > That is related to this numpy update:
> > 
> > https://src.fedoraproject.org/rpms/numpy/c/200eb18e3f617dddb9702fcbc025236f81d6024f?branch=rawhide
> > 
> > I've added -1 karma to the Fedora 39 update.
> > 
> > https://bodhi.fedoraproject.org/updates/FEDORA-2023-e1b5f14c24
> 
> 
> huf , this is another issue, I already checked that builds for F39
> ... 
> 
> Thanks for all the support  


JFTR (In case someone googled this)

 - distutils was removed from Python 3.12 since almost the very
beginning
 - python3-setuptools provides its own (forked) distutils module --
many Fedora packages depending on distutils were fixed just by adding
BuildRequires: python3-setuptools
 - numpy.distutils (depends on distutils, either the one from Python or
the one from setuptools) was removed from NumPy 1.26




> 
> > -- 
> > Miro Hrončok
> 

-- 
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: Looking for a volunteer to automate the orphaned packages process

[Sérgio Basto]

On Thu, 2023-10-19 at 11:06 +0200, Miro Hrončok wrote:
> Hello folks,
> 
> you might know I run a script that generates
> 
> https://churchyard.fedorapeople.org/orphans.txt
> https://churchyard.fedorapeople.org/orphans.json
> 
> The script is located at
> https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py
> 
> I try to monitor the output and whenever it is stuck, I restart it.
> 
> Every 2 weeks I try to save a copy of the generated file and send it
> to the 
> devel list, devel announce list and the affected maintainers.
> 
> Every branching, the script needs (trivial) changes.
> 
> When I see packages orphaned for 6+ weeks, I retire them.
> 
> 
> I took this task a coupe years back because I was not satisfied with
> the status 
> quo at that time (packages orphaned for year+ lingering in the
> distro).
> 
> The task is semi-automated but not fully. After almost 5 years, I
> think it's 
> time to pass this to somebody else. Preferably to somebody who would
> enjoy 
> automating it entirely.
> 
> I can provide all the details about the operation if you want to
> become the 
> reaper's apprentice.
> 

yeah, as already mention, I think sometimes is reaped too much, but the
results, at the end of the day, are good, we have a better Fedora. I
know the balance is extremely difficult and needs lots of work.

I have some commits to improve find_unblocked_orphans.py (not yet
completely finished ) , the feature that I'd like implement is query
more than one repo , will be useful to query el + epel for example and
some optimizations IIRC. 


> Please do let me know. I believe this process is essential for the
> health of 
> Fedora but I'd like to be relieved of this task.
> 
> -- 
> 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

redhat-lsb-5.0 is arriving to rawhide, epel 9 and updates-testing of F39

[Sérgio Basto]

Hi,

I finally finished firts version of redhat-lsb-5.0, I tried to collect
all the commits that exist on the internet and organize them, I chose
to fork the official lsb_release from linuxfoundation.org [1], and add
the original redhat-lsb-4.1 and then apply some commits found on the
internet that I found useful, the result is here [2] .
Any feedback or help is welcome . 

[1]
https://github.com/LinuxStandardBase/lsb-samples

[2]
https://pagure.io/redhat-lsb 


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: Orphaning all my packages

[Sérgio Basto]

On Fri, 2023-10-06 at 16:11 +0200, Jens Kuehnel wrote:
> Sorry, my mailer did remove an imporant \n.
> 
> Am 04.10.23 um 01:16 schrieb Sérgio Basto:
> Hi Sérgio,
> 
> > I believe you, but this version is an "right most" bump and is
> > "just"
> > one security fix, when in Centos Stream [1], 6 months ago we
> > already
> > have a higher version, this seems a work of security team, not real
> > development ...  and if these security releases aren't published
> > anymore is an issue I understand but I don't understand why the
> > people
> > are so afraid of use Centos Stream version instead .
> 
> 
> I can only answer for me, but the main reason to avoid Stream on real
> Hardware (I use it on virtual Maschines) is the missing support for 
> elrepo.org kmod packages [1].
> 
> After RedHat dropped support for so many hardware, especially in EL9 
> [2], it is hard to run on older / unsupported hardware without the
> help 
> of elrepo.
> 

I contribute for https://gitlab.com/CentOS/kmods/rpms with
https://gitlab.com/CentOS/kmods/rpms/virtualbox-guest-additions , is a
kind of replacement of elrepo the CentOS Kmods SIG 
https://sigs.centos.org/kmods/ 

> CU
> Jens
> 
> [1] https://elrepo.org/tiki/About#What_is_ELRepo_
> 
> "ELRepo packages are not compatible with the CentOS Stream kernel"
> 
> [2] This is not a complain! I can understand to drop support for
> things 
> you do not have (anymore) or are not important for customers.
> ___
> 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: Orphaning all my packages

[Sérgio Basto]

On Tue, 2023-10-03 at 20:55 +0200, Leon Fauster via devel wrote:
> Am 03.10.23 um 20:46 schrieb Sérgio Basto:
> > On Tue, 2023-10-03 at 13:13 -0500, Michael Catanzaro wrote:
> > > On Tue, Oct 3 2023 at 01:19:20 PM -0400, Simo Sorce
> > > 
> > > wrote:
> > > > Additionally *all* of the code is fully available in git form
> > > > on
> > > > gitlab
> > > > as part of CentOS Stream.
> > > 
> > > We all know or should know that this is false. It's easy enough
> > > to
> > > disprove with a counterexample:
> > > 
> > > https://access.redhat.com/errata/RHSA-2023:1918
> > > 
> > > Try to find the code for that webkit2gtk3-2.36.7-
> > > 1.el9_1.3.src.rpm in
> > > CentOS Stream. It isn't there, and never will be.
> > > 
> > 
> > it is here :
> > https://git.centos.org/rpms/webkit2gtk3/c/2d1b790baa97d14849e56ed21d3f0145268283c2?branch=c9
> > 
> 
> 
> Since June 21 the strategy changed. Such commits do not get pushed 
> anymore. But you are right, to prove it a different example is
> necessary ...
> 


I believe you, but this version is an "right most" bump and is "just"
one security fix, when in Centos Stream [1], 6 months ago we already
have a higher version, this seems a work of security team, not real
development ...  and if these security releases aren't published
anymore is an issue I understand but I don't understand why the people
are so afraid of use Centos Stream version instead . 

[1]
https://gitlab.com/redhat/centos-stream/rpms/webkit2gtk3/-/commits/c9s/

> -- 
> 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: Orphaning all my packages

[Sérgio Basto]

On Tue, 2023-10-03 at 13:13 -0500, Michael Catanzaro wrote:
> On Tue, Oct 3 2023 at 01:19:20 PM -0400, Simo Sorce 
> wrote:
> > Additionally *all* of the code is fully available in git form on 
> > gitlab
> > as part of CentOS Stream.
> 
> We all know or should know that this is false. It's easy enough to 
> disprove with a counterexample:
> 
> https://access.redhat.com/errata/RHSA-2023:1918
> 
> Try to find the code for that webkit2gtk3-2.36.7-1.el9_1.3.src.rpm in
> CentOS Stream. It isn't there, and never will be.
> 

it is here :
https://git.centos.org/rpms/webkit2gtk3/c/2d1b790baa97d14849e56ed21d3f0145268283c2?branch=c9


> 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: Orphaning all my packages

[Sérgio Basto]

On Tue, 2023-10-03 at 10:25 -0400, Todd Zullinger wrote:
> a project
> where the primary sponsor and downstream no longer provides
> source code freely and openly

what you are talking about ? all RHEL Source are freely available on
Centos Stream , and RHEL never was free . 

-- 
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: python-3.12 distutils removal just happened after python mass rebuild and Fedora mass rebuild ?

[Sérgio Basto]

On Fri, 2023-09-29 at 23:42 +0200, Miro Hrončok wrote:
> On 29. 09. 23 23:38, Miro Hrončok wrote:
> > On 29. 09. 23 20:32, Sérgio Basto wrote:
> > > Hi,
> > 
> > Hi.
> > 
> > > Recent build of some packages like opencv and an old gpgme shows
> > > that
> > > python-3.12 disutils has gone for good , but just after all mass
> > > rebuilds and recently , what you advice to do ?
> > 
> > It has been gone for since the Python 3.12 rebuild in June.
> > 
> > Perhaps some required package transitively pulled in python3-
> > setuptools? That 
> > package provides it's own (forked) implementation of distutils.
> > 
> > > Any quick way to replace distutils ? the python 3.12 final
> > > release,
> > > currently is scheduled for 2023-10-02 ...
> > 
> > For building, I encourage trying to BuildRequire python3-setuptools
> > and 
> > observing if it helps.
> > 


aaah , BuildRequire python3-setuptools fix old gpgme package , and this
is a good new for me :) 

without  python3-setuptools 
https://copr.fedorainfracloud.org/coprs/sergiomb/python2/build/6475479/
https://download.copr.fedorainfracloud.org/results/sergiomb/python2/fedora-39-aarch64/06475479-gpgme/builder-live.log.gz
checking for the distutils Python package... no
configure: error: cannot import Python module "distutils".
Please check your Python installation. The error was:
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'distutils'

and with python3-setuptools 
https://copr.fedorainfracloud.org/coprs/sergiomb/python2/build/6475513/

> > Some links with actual build failures would be helpful.
> 
> The failure in https://koschei.fedoraproject.org/package/opencv looks
> like:
> 
> Traceback (most recent call last):
>    File "", line 1, in 
> ModuleNotFoundError: No module named 'numpy.distutils'
> 
> That is related to this numpy update:
> 
> https://src.fedoraproject.org/rpms/numpy/c/200eb18e3f617dddb9702fcbc025236f81d6024f?branch=rawhide
> 
> I've added -1 karma to the Fedora 39 update.
> 
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-e1b5f14c24


huf , this is another issue, I already checked that builds for F39 ... 

Thanks for all the support  

> -- 
> Miro Hrončok

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

python-3.12 distutils removal just happened after python mass rebuild and Fedora mass rebuild ?

[Sérgio Basto]

Hi,

Recent build of some packages like opencv and an old gpgme shows that
python-3.12 disutils has gone for good , but just after all mass
rebuilds and recently , what you advice to do ? 

Any quick way to replace distutils ? the python 3.12 final release,
currently is scheduled for 2023-10-02 ... 

Thank 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: Need help with build failure

[Sérgio Basto]

On Fri, 2023-09-08 at 21:27 +0100, Sérgio Basto wrote:
> On Fri, 2023-09-08 at 15:47 +0100, Sérgio Basto wrote:
> > On Fri, 2023-09-08 at 16:25 +0200, Lumír Balhar wrote:
> > > Hi.
> > > 
> > > Have you managed to fix the issue? The error is produce by the
> > > configure 
> > > script and the check is implemented there somewhere around line
> > > 4293
> > > but 
> > > I don't understand it well enough to tell you what causing it to
> > > detect 
> > > the cross compilation.
> > 
> > 
> > sorry for my previous message is not for this thread 
> > 
> > in this thread , 
> > I got the same problem and fix it with adding --host=$(uname -m)
> > [1]
> > 
> > but just need the fix to build in koji , if in a local build with
> > mock
> > on my laptop, I don't need the fix. 
> > 
> > [1] 
> > %configure --host=$(uname -m)
> 
> commmit [1] try to fix:
> configure: error: cannot run C++ compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
> 
> [1]
> https://pkgs.rpmfusion.org/cgit/free/libvlcpp.git/commit/?id=331cb7448337da30053badab2a7850fcfcb31aaa
> 
> this happened to me before on 2023-08-04 02:20:05 +0100 before branch
> F39 
> 
> In my case it builds locally without this hack, which is weird .
> 
> 

"
Well, I've solved the problem just by adding 'export
CPPFLAGS="$CXXFLAGS" at the start of the %build section...
I don't think the automatic exports in Fedora build system have
changed, did them?

Mattia
"

This is fixed for me no need more hacks (Mattia's or mime)

I checked and we have many commits on redhat-rpm-config [1] maybe this
one [2] I don't know , but seems it was fixed anyway .

Best regards, 

[1]
https://src.fedoraproject.org/rpms/redhat-rpm-config/commits/f39


[2]
https://src.fedoraproject.org/rpms/redhat-rpm-config/c/7692bbaf45de80df5a3b6564dfbcb882f545a456?branch=f39


> > > Lumír
> > > 
> > > On 9/6/23 14:54, Mattia Verga wrote:
> > > > python-calcephpy builds were FTB since between the F39 mass
> > > > rebuild
> > > > (which completed fine) and the Cython 3.x change (which started
> > > > to
> > > > fail).
> > > > While I was waiting for upstream to fix the package for
> > > > compatibility with Cython 3.x I tried to rebuild it forcing
> > > > cython
> > > > < 3.0, but I got an odd build failure to which I didn't pay
> > > > great
> > > > attention, I simply thought about some glitch trying to force
> > > > the
> > > > cython version to the compat package.
> > > > 
> > > > Now that upstream released a new version compatible with Cython
> > > > 3.x
> > > > I tried to update the package, but I still get the odd build
> > > > failure. It seems that during the configure script the package
> > > > complains about being cross-built... the latest build attempt
> > > > completed fine on i686 and ppc64le, while failed on other
> > > > architectures.
> > > > 
> > > > Does anyone have any idea about this?
> > > > Thanks
> > > > Mattia
> > > > 
> > > > [1]
> > > > https://koji.fedoraproject.org/koji/packageinfo?packageID=32685
> > > > [2]
> > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=105822496
> > > > ___
> > > > python-devel mailing list --
> > > > python-devel@lists.fedoraproject.org
> > > > To unsubscribe send an email to
> > > > python-devel-le...@lists.fedoraproject.org
> > > > Fedora Code of Conduct:
> > > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > > List Guidelines:
> > > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > > List Archives:
> > > > https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
> > > > Do not reply to spam, report it:
> > > > https://pagure.io/fedora-infrastructure/new_issue
> > > ___
> > > python-devel mailing list -- python-devel@lists.fedoraproject.org
> > > To unsubscribe send an email to
> > > python-devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct:
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines:
> > > https://fedoraproject.org/wiki/Mailing_list_gui

Re: F40 Change Proposal: KDE Plasma 6 (System Wide)

[Sérgio Basto]

On Sun, 2023-09-17 at 23:48 +0200, Kevin Kofler via devel wrote:
> Ian Laurie wrote:
> > I didn't think the greeter used Wayland?  So there may be something
> > else
> > going on.  I cannot swear to it, but I don't think I've noticed
> > problems
> > in the greeter before.
> >  
> > As Adam posted, the offset problem already has a bug for it. 
> > Wayland is
> > certainly unusable in VirtualBox, but now even the greeter has
> > issues,
> > and I think that's newish.
> 
> SDDM was switched to Wayland for F38 and newer. If you want it to use
> X11, 
> you have to edit /etc/sddm.conf and set:
> 
> [General]
> DisplayServer=x11
> 

Ah , thank you,  I also had problem with my laptop and nvidia prime
graphics 

BTW I want use KDE 5 plasma , because it is stable, I think for Fedora
40 is to early . I use KDE to work , I'm don't pretend to be a beta
tester , and by the experiences of the fiascos of kde 4 and kde 5 move
, I don't believe that KDE 6 will be different , Fedora 40 should have
the option of have KDE 5, IMHO .






> there.
> 
>     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: F40 Change Proposal: KDE Plasma 6 (System Wide)

[Sérgio Basto]

On Wed, 2023-09-13 at 19:52 +0200, Kevin Kofler via devel wrote:
> > For Fedora Linux, the transition to KDE Plasma 6 will also include
> > dropping support for the X11 session entirely, leaving only Plasma
> > Wayland
> > as the sole offered desktop mode.
> 
> Huh?! Why?! KDE upstream is still supporting X11 in Plasma 6. I see
> no 
> reason to force Wayland upon all users. I do not want Wayland on my
> desktop 
> (it is already enough of a pain that it is forced upon us by Plasma
> Mobile 
> on the PinePhone) and I will have to switch to another distribution
> and 
> orphan all my packages if this happens.
> 

+1 , I still not use wayland , it just crash all the time , smplayer
and I think many other apps simple doesn't work with wayland. other
packages we cann see Exec=env QT_QPA_PLATFORM=xcb /usr/bin/foo [1].
Also packages based on vnc , libvnc, x11vnc I think doesn't support
wayland, xpra also I think that still doesn't work with wayland. I
don't see why we want move to wayland if X11 works very well .  


[1]
https://pkgs.rpmfusion.org/cgit/free/ppsspp.git/tree/ppsspp-qt.desktop


>     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: Need help with build failure

[Sérgio Basto]

On Fri, 2023-09-08 at 15:47 +0100, Sérgio Basto wrote:
> On Fri, 2023-09-08 at 16:25 +0200, Lumír Balhar wrote:
> > Hi.
> > 
> > Have you managed to fix the issue? The error is produce by the
> > configure 
> > script and the check is implemented there somewhere around line
> > 4293
> > but 
> > I don't understand it well enough to tell you what causing it to
> > detect 
> > the cross compilation.
> 
> 
> sorry for my previous message is not for this thread 
> 
> in this thread , 
> I got the same problem and fix it with adding --host=$(uname -m) [1]
> 
> but just need the fix to build in koji , if in a local build with
> mock
> on my laptop, I don't need the fix. 
> 
> [1] 
> %configure --host=$(uname -m)

commmit [1] try to fix:
configure: error: cannot run C++ compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

[1]
https://pkgs.rpmfusion.org/cgit/free/libvlcpp.git/commit/?id=331cb7448337da30053badab2a7850fcfcb31aaa

this happened to me before on 2023-08-04 02:20:05 +0100 before branch
F39 

In my case it builds locally without this hack, which is weird .


> > Lumír
> > 
> > On 9/6/23 14:54, Mattia Verga wrote:
> > > python-calcephpy builds were FTB since between the F39 mass
> > > rebuild
> > > (which completed fine) and the Cython 3.x change (which started
> > > to
> > > fail).
> > > While I was waiting for upstream to fix the package for
> > > compatibility with Cython 3.x I tried to rebuild it forcing
> > > cython
> > > < 3.0, but I got an odd build failure to which I didn't pay great
> > > attention, I simply thought about some glitch trying to force the
> > > cython version to the compat package.
> > > 
> > > Now that upstream released a new version compatible with Cython
> > > 3.x
> > > I tried to update the package, but I still get the odd build
> > > failure. It seems that during the configure script the package
> > > complains about being cross-built... the latest build attempt
> > > completed fine on i686 and ppc64le, while failed on other
> > > architectures.
> > > 
> > > Does anyone have any idea about this?
> > > Thanks
> > > Mattia
> > > 
> > > [1]
> > > https://koji.fedoraproject.org/koji/packageinfo?packageID=32685
> > > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=105822496
> > > ___
> > > python-devel mailing list -- python-devel@lists.fedoraproject.org
> > > To unsubscribe send an email to
> > > python-devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct:
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines:
> > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > > https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
> > > Do not reply to spam, report it:
> > > https://pagure.io/fedora-infrastructure/new_issue
> > ___
> > python-devel mailing list -- python-devel@lists.fedoraproject.org
> > To unsubscribe send an email to
> > python-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> 

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

Re: SPDX MIT license , what todo ?

[Sérgio Basto]

On Fri, 2023-09-08 at 15:55 +0200, Michael J Gruber wrote:
> Am Fr., 8. Sept. 2023 um 15:45 Uhr schrieb Sérgio Basto
> :
> > 
> > On Fri, 2023-09-08 at 08:39 +0200, Sandro wrote:
> > > On 08-09-2023 02:36, Sérgio Basto wrote:
> > > > xdg-utils is a MIT License [1] what SPDX license have [2] ? if
> > > > it
> > > > is
> > > > already a valid SPDX formula , what I should write on changelog
> > > > ?
> > > 
> > > Something like:
> > > 
> > > - Migrated to SPDX license (noop)
> > > 
> > 
> > done [1] thanks , btw another question I don't need do a new build
> > isn't it ?
> 
> No, since there was no license change - in your case not even the
> specifier changed :)
> 

and if the license format changed , should we build a new release ? and
in all branches or just in rawhide ? 

Thank you 



> 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: Need help with build failure

[Sérgio Basto]

On Fri, 2023-09-08 at 16:25 +0200, Lumír Balhar wrote:
> Hi.
> 
> Have you managed to fix the issue? The error is produce by the
> configure 
> script and the check is implemented there somewhere around line 4293
> but 
> I don't understand it well enough to tell you what causing it to
> detect 
> the cross compilation.


sorry for my previous message is not for this thread 

in this thread , 
I got the same problem and fix it with adding --host=$(uname -m) [1]

but just need the fix to build in koji , if in a local build with mock
on my laptop, I don't need the fix. 

[1] 
%configure --host=$(uname -m)

> Lumír
> 
> On 9/6/23 14:54, Mattia Verga wrote:
> > python-calcephpy builds were FTB since between the F39 mass rebuild
> > (which completed fine) and the Cython 3.x change (which started to
> > fail).
> > While I was waiting for upstream to fix the package for
> > compatibility with Cython 3.x I tried to rebuild it forcing cython
> > < 3.0, but I got an odd build failure to which I didn't pay great
> > attention, I simply thought about some glitch trying to force the
> > cython version to the compat package.
> > 
> > Now that upstream released a new version compatible with Cython 3.x
> > I tried to update the package, but I still get the odd build
> > failure. It seems that during the configure script the package
> > complains about being cross-built... the latest build attempt
> > completed fine on i686 and ppc64le, while failed on other
> > architectures.
> > 
> > Does anyone have any idea about this?
> > Thanks
> > Mattia
> > 
> > [1] https://koji.fedoraproject.org/koji/packageinfo?packageID=32685
> > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=105822496
> > ___
> > python-devel mailing list -- python-devel@lists.fedoraproject.org
> > To unsubscribe send an email to
> > python-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> ___
> python-devel mailing list -- python-devel@lists.fedoraproject.org
> To unsubscribe send an email to
> python-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

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

Re: Need help with build failure

[Sérgio Basto]

On Fri, 2023-09-08 at 16:25 +0200, Lumír Balhar wrote:
> Hi.
> 
> Have you managed to fix the issue? The error is produce by the
> configure 
> script and the check is implemented there somewhere around line 4293
> but 
> I don't understand it well enough to tell you what causing it to
> detect 
> the cross compilation.


and if the license format changed , should we build a new release ? and
in all branches or just in rawhide ? 

Thank you 

> Lumír
> 
> On 9/6/23 14:54, Mattia Verga wrote:
> > python-calcephpy builds were FTB since between the F39 mass rebuild
> > (which completed fine) and the Cython 3.x change (which started to
> > fail).
> > While I was waiting for upstream to fix the package for
> > compatibility with Cython 3.x I tried to rebuild it forcing cython
> > < 3.0, but I got an odd build failure to which I didn't pay great
> > attention, I simply thought about some glitch trying to force the
> > cython version to the compat package.
> > 
> > Now that upstream released a new version compatible with Cython 3.x
> > I tried to update the package, but I still get the odd build
> > failure. It seems that during the configure script the package
> > complains about being cross-built... the latest build attempt
> > completed fine on i686 and ppc64le, while failed on other
> > architectures.
> > 
> > Does anyone have any idea about this?
> > Thanks
> > Mattia
> > 
> > [1] https://koji.fedoraproject.org/koji/packageinfo?packageID=32685
> > [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=105822496
> > ___
> > python-devel mailing list -- python-devel@lists.fedoraproject.org
> > To unsubscribe send an email to
> > python-devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> ___
> python-devel mailing list -- python-devel@lists.fedoraproject.org
> To unsubscribe send an email to
> python-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

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