Re: The GRUB2 Bootloader – Installation and Configuration

[Peter Boy]

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

That’s really a challenge. You don’t describe what you did in detail. 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#963179
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Non-responsive maintainer check for lkundrak

[Tomi Lähteenmäki]

On ti, huhti 30 2024 at 14.07.47 +02:00:00, Miroslav Suchý 
 wrote:



 plus work related email (added to cc)


Thank you! I was able to get a reply in Mastodon.

-Tomi

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

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

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-c66806f4ad   
stb-0-0.45.20240213gitae721c5.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

csdiff-3.3.0-1.el7
python-rosdistro-0.9.1-1.el7
python-rospkg-1.5.1-1.el7
radsecproxy-1.10.1-1.el7
voms-2.1.0-0.34.rc4.el7

Details about builds:



 csdiff-3.3.0-1.el7 (FEDORA-EPEL-2024-595e3adf42)
 Non-interactive tools for processing code scan results in plain-text

Update Information:

cshtml: use the .json extension for JSON files (#176)
csdiff: match findings by line content without spaces if available (#168)
csgrep --hash-v1: match csdiff/v1 fingerprint prefix (#168)
sarif: initial implementation of csdiff/v1 fingerprints (#168)
sarif: add descriptions for ShellCheck rules (#170)

ChangeLog:

* Fri May  3 2024 Kamil Dudka  3.3.0-1
- update to latest upstream release




 python-rosdistro-0.9.1-1.el7 (FEDORA-EPEL-2024-b730553781)
 File format for managing ROS Distributions

Update Information:

Update to the latest ROS infrastructure package releases

ChangeLog:

* Fri May  3 2024 Scott K Logan  - 0.9.1-1
- Update to 0.9.1 (rhbz#2278971)

References:

  [ 1 ] Bug #2276182 - python-rospkg-1.5.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2276182
  [ 2 ] Bug #2276793 - python-rosdep-0.23.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2276793
  [ 3 ] Bug #2278971 - python-rosdistro-0.9.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2278971




 python-rospkg-1.5.1-1.el7 (FEDORA-EPEL-2024-b730553781)
 Utilities for ROS package, stack, and distribution information

Update Information:

Update to the latest ROS infrastructure package releases

ChangeLog:

* Fri May  3 2024 Scott K Logan  - 1.5.1-1
- Update to 1.5.1 (rhbz#2276182)

References:

  [ 1 ] Bug #2276182 - python-rospkg-1.5.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2276182
  [ 2 ] Bug #2276793 - python-rosdep-0.23.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2276793
  [ 3 ] Bug #2278971 - python-rosdistro-0.9.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2278971




 radsecproxy-1.10.1-1.el7 (FEDORA-EPEL-2024-e725d56fa0)
 Generic RADIUS proxy with RadSec support

Update Information:

radsecproxy 1.10.1 (2024-05-02)
Bug Fixes
Fix TCP connection not closed after idle timeout
Fix TLS/DTLS logging
Fix dynamic connection not re-established after timeout if both auth- and
accounting server are dynamically resolved
Fix error in dyndisc script result might cause radsecproxy to exit
Fix some TLS config errors not reported at startup
Fix referencing non-existant rewrite passed without error
Misc
Add Message-Authenticator to requests if missing

ChangeLog:

* Fri May  3 2024 Robert Scheck  1.10.1-1
- Upgrade to 1.10.1 (#2278768)
* Fri Jan 26 2024 Fedora Release Engineering  - 
1.10.0-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Mon Jan 22 2024 Fedora Release Engineering  - 
1.10.0-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Fri Jul 21 2023 Fedora Release Engineering  - 
1.10.0-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild

References:

  [ 1 ] Bug #2278768 - radsecproxy-1.10.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2278768

[EPEL-devel] Fedora EPEL 8 updates-testing report

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-f282573e05   
et-6.2.8-2.el8
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-6327fb701b   
stb-0-0.45.20240213gitae721c5.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

csdiff-3.3.0-1.el8
fonts-compare-1.5.0-1.el8
python-rosdep-0.23.0-1.el8
python-rosdistro-0.9.1-1.el8
python-rospkg-1.5.1-1.el8
radicale-3.2.0-1.el8
radsecproxy-1.10.1-1.el8
voms-2.1.0-0.34.rc4.el8
wsdd-0.8-1.el8

Details about builds:



 csdiff-3.3.0-1.el8 (FEDORA-EPEL-2024-a48d65da08)
 Non-interactive tools for processing code scan results in plain-text

Update Information:

cshtml: use the .json extension for JSON files (#176)
csdiff: match findings by line content without spaces if available (#168)
csgrep --hash-v1: match csdiff/v1 fingerprint prefix (#168)
sarif: initial implementation of csdiff/v1 fingerprints (#168)
sarif: add descriptions for ShellCheck rules (#170)

ChangeLog:

* Fri May  3 2024 Kamil Dudka  3.3.0-1
- update to latest upstream release




 fonts-compare-1.5.0-1.el8 (FEDORA-EPEL-2024-ec932d4615)
 Tool to compare fonts for a language

Update Information:

Initialize fonts-compare with language from cli "fonts-compare --lang ja"

ChangeLog:

* Thu May  2 2024 Sudip Shil  - 1.5.0-1
- Initialize fonts-compare with language from cli "fonts-compare --lang ja"
- Now user can turn off the Auto language detection for their words in edit 
label
- Now both buttons select different fonts. They will not select similar/same 
font
- fixed issue auto langdetect changing fonts for both fontbutton
- activate dark theme if system's dark mode is enabled, used libadwaita
- Avoiding the fontconfig limitation with locales like - Choosing -* giving 
same font
- droid fonts will never be selected
- changed README
* Wed Jan 24 2024 Fedora Release Engineering  - 
1.4.0-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Fri Jan 19 2024 Fedora Release Engineering  - 
1.4.0-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild




 python-rosdep-0.23.0-1.el8 (FEDORA-EPEL-2024-3adef4deb6)
 ROS System Dependency Installer

Update Information:

Update to the latest ROS infrastructure package releases

ChangeLog:

* Thu May  2 2024 Scott K Logan  - 0.23.0-1
- Update to 0.23.0 (rbhz#2276793)
- Drop Python 2 subpackage from spec file

References:

  [ 1 ] Bug #2276182 - python-rospkg-1.5.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2276182
  [ 2 ] Bug #2276793 - python-rosdep-0.23.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2276793
  [ 3 ] Bug #2278971 - python-rosdistro-0.9.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2278971




 python-rosdistro-0.9.1-1.el8 (FEDORA-EPEL-2024-3adef4deb6)
 File format for managing ROS Distributions

Update Information:

Update to the latest ROS infrastructure package releases

ChangeLog:

* Fri May  3 2024 Scott K Logan  - 0.9.1-1
- Update to 0.9.1 (rhbz#2278971)

References:

  [ 1 ] Bug #2276182 - python-rospkg-1.5.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2276182
  [ 2 ] Bug #2276793 - python-rosdep-0.23.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2276793
  [ 3 ] Bug #2278971 - python-rosdistro-0.9.1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2278971

[EPEL-devel] Fedora EPEL 9 updates-testing report

[updates]

The following Fedora EPEL 9 Security updates need testing:
 Age  URL
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-808f3961ef   
chromium-124.0.6367.118-1.el9
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-39387970e2   
stb-0^20240213gitae721c5-5.el9


The following builds have been pushed to Fedora EPEL 9 updates-testing

csdiff-3.3.0-1.el9
fonts-compare-1.5.0-1.el9
gdl-1.0.4-5.el9
nwg-panel-0.9.31-1.el9
openldap-epel-2.6.6-2.el9
plplot-5.15.0-65.el9
python-pox-0.3.4-1.el9
python-pyxdameraulevenshtein-1.8.0-1.el9
python-rosdep-0.23.0-1.el9
python-rosdistro-0.9.1-1.el9
python-rospkg-1.5.1-1.el9
radicale-3.2.0-1.el9
radsecproxy-1.10.1-1.el9
rust-clru-0.6.2-1.el9
rust-gix-filter-0.11.1-1.el9
rust-gix-packetline-blocking-0.17.4-1.el9
srcpd-2.1.7-1.el9
voms-2.1.0-0.34.rc4.el9
wsdd-0.8-1.el9

Details about builds:



 csdiff-3.3.0-1.el9 (FEDORA-EPEL-2024-f2a2e2976a)
 Non-interactive tools for processing code scan results in plain-text

Update Information:

cshtml: use the .json extension for JSON files (#176)
csdiff: match findings by line content without spaces if available (#168)
csgrep --hash-v1: match csdiff/v1 fingerprint prefix (#168)
sarif: initial implementation of csdiff/v1 fingerprints (#168)
sarif: add descriptions for ShellCheck rules (#170)

ChangeLog:

* Fri May  3 2024 Kamil Dudka  3.3.0-1
- update to latest upstream release




 fonts-compare-1.5.0-1.el9 (FEDORA-EPEL-2024-b4bb870854)
 Tool to compare fonts for a language

Update Information:

Initialize fonts-compare with language from cli "fonts-compare --lang ja"

ChangeLog:

* Thu May  2 2024 Sudip Shil  - 1.5.0-1
- Initialize fonts-compare with language from cli "fonts-compare --lang ja"
- Now user can turn off the Auto language detection for their words in edit 
label
- Now both buttons select different fonts. They will not select similar/same 
font
- fixed issue auto langdetect changing fonts for both fontbutton
- activate dark theme if system's dark mode is enabled, used libadwaita
- Avoiding the fontconfig limitation with locales like - Choosing -* giving 
same font
- droid fonts will never be selected
- changed README
* Wed Jan 24 2024 Fedora Release Engineering  - 
1.4.0-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild
* Fri Jan 19 2024 Fedora Release Engineering  - 
1.4.0-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_40_Mass_Rebuild




 gdl-1.0.4-5.el9 (FEDORA-EPEL-2024-d3bb8bd9d4)
 GNU Data Language

Update Information:

Re-enable qhull support

ChangeLog:

* Tue Feb 27 2024 Jiri Vanek  - 1.0.4-5
- Rebuilt for java-21-openjdk as system jdk




 nwg-panel-0.9.31-1.el9 (FEDORA-EPEL-2024-d753ea7358)
 GTK3-based panel for sway and Hyprland Wayland compositors

Update Information:

Automatic update for nwg-panel-0.9.31-1.el9.
Changelog for nwg-panel
* Fri May 03 2024 Packit  - 0.9.31-1
- Update to 0.9.31 upstream release
- Resolves: rhbz#2278993
* Thu May 02 2024 Packit  - 0.9.29-1
- Update to 0.9.29 upstream release
- Resolves: rhbz#2278111
* Tue Mar 26 2024 Packit  - 0.9.27-1
- [packit] 0.9.27 upstream release
- Resolves: rhbz#2271617
* Thu Mar 21 2024 Packit  - 0.9.26-1
- [packit] 0.9.26 upstream release
- Resolves rhbz#2270575

ChangeLog:

* Fri May  3 2024 Packit  - 0.9.31-1
- Update to 0.9.31 upstream release
- Resolves: rhbz#2278993
* Thu May  2 2024 Packit  - 0.9.29-1
- Update to 0.9.29 upstream release
- Resolves: rhbz#2278111
* Tue Mar 26 2024 Packit  - 0.9.27-1
- [packit] 0.9.27 upstream release
- Resolves: rhbz#2271617
* Thu Mar 21 2024 Packit  - 0.9.26-1
- [packit] 0.9.26 upstream release
- Resolves rhbz#2270575

References:

  [ 1 ] 

Orphaned packages looking for new maintainers

[Maxwell G]

Report started at 2024-04-27 20:06:57 UTC

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

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

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

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

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

Package  (co)maintainers   Status Change

bamf  orphan   0 weeks ago  
bti   orphan   0 weeks ago  
container-workflow-tool   orphan   4 weeks ago  
emacs-htmlize orphan   5 weeks ago  
golang-github-elves-elvish@go-sig, orphan  1 weeks ago  
golang-github-xiaq-persistent @go-sig, orphan  1 weeks ago  
jolokia-jvm-agent orphan   2 weeks ago  
mingw-freeimage   orphan   2 weeks ago  
php-aws-sdk3  orphan   4 weeks ago  
php-bantu-ini-get-wrapper adamwill, orphan 4 weeks ago  
php-christophwurst-id3parser  orphan   4 weeks ago  
php-deepdiver-zipstreamer orphan   4 weeks ago  
php-doctrine-dbal orphan, remi 4 weeks ago  
php-fgrosse-phpasn1   orphan   4 weeks ago  
php-giggsey-localeorphan   4 weeks ago  
php-guzzlehttp-guzzle6orphan   4 weeks ago  
php-league-uri-interfaces orphan   4 weeks ago  
php-opencloud-openstack   orphan   4 weeks ago  
php-opis-closure  orphan, remi 4 weeks ago  
php-pimpleorphan   4 weeks ago  
php-punic orphan   4 weeks ago  
php-ralouphie-getallheaders   orphan   4 weeks ago  
php-scssphp   orphan   4 weeks ago  
php-stecman-symfony-console-  orphan   4 weeks ago  
completion  
prometheus-jmx-exporter   orphan   2 weeks ago  
prometheus-simpleclient-java  orphan   2 weeks ago  
python-jose   orphan   3 weeks ago  
rust-stratisd_proc_macros @rust-sig, bgurney, mulhern, 0 weeks ago  
  orphan
snakeyaml mizdebsk, orphan, sbluhm 2 weeks ago  
vim-editorconfig  orphan   3 weeks ago  
wdune orphan   0 weeks ago  

The following packages require above mentioned packages:
Depending on: bamf (16), status change: 2024-04-22 (0 weeks ago)
deepin-daemon (maintained by: @deepinde-sig, @go-sig, cheeselee, zsun)
deepin-daemon-5.14.44-8.fc40.x86_64 requires bamf-daemon = 
0.5.6-1.fc41, deepin-session-ui = 5.6.2-3.fc40

plank (maintained by: filiperosset)
plank-0.11.89-15.20210202.git013d051.fc40.src requires 
pkgconfig(libbamf3) = 0.5.6
plank-0.11.89-15.20210202.git013d051.fc40.x86_64 requires 
bamf-daemon = 0.5.6-1.fc41
plank-devel-0.11.89-15.20210202.git013d051.fc40.i686 requires 
pkgconfig(libbamf3) = 0.5.6
plank-devel-0.11.89-15.20210202.git013d051.fc40.x86_64 requires 
pkgconfig(libbamf3) = 0.5.6
plank-libs-0.11.89-15.20210202.git013d051.fc40.i686 requires 
libbamf3.so.2
plank-libs-0.11.89-15.20210202.git013d051.fc40.x86_64 requires 
libbamf3.so.2()(64bit)

deepin-calendar (maintained by: @deepinde-sig, cheeselee, felixonmars, 
zsun)
deepin-calendar-5.10.0-3.fc40.x86_64 

Re: Notice of intent to orphan salt

[Robby Callicotte via devel]

On Thursday, May 2, 2024 1:55:07 PM CDT Gwyn Ciesla via devel wrote:
> salt-master has been broken on Fedora since Fedora 39, when we moved to
> Python 3.12. 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2250197
> 
> Upstream doesn't seem particularly interested in supporting anything outside
> of their 'onedir' packaging, which bundles it's own Python stack. Most of
> the work required to work on 3.12, I THINK, involves unbundling twisted,
> which is non-trival.
> 
> The good news is that they do that with the 3007.x series. The bad news is
> that that requires a recent version of python-cryptography that breaks
> several other packages:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=2257380
> 
> Since I needed something that works for config management, I've migrated my
> own stuff from salt to something that works with distro packaging and
> doesn't have odd version constraints¹.
> 
> As a consequence, I can no longer sufficiently test new releases. As a
> result, I've just sent 3006.8 to updates-testing for rawhide-f38, and will
> orphan salt on May 21 2024, when f38 is EOL.
> 
> If someone wants to take ownership before then, please let me know.
> 
> -Gwyn
> 
> 
> 1.  Ansible.
> 
> 
> 
> 
> 
> -- 
> Gwyn Ciesla
> she/her/hers
>  
> in your fear, seek only peace 
> in your fear, seek only love
> -d. bowie
> 
> 
> Sent with Proton Mail secure email.

I am wondering if we would be able to bundle the dependencies in accordance 
with the guidelines[1]???  The salt folks are bundling the dependencies, could 
we do the same (minus the python interpreter of course)??

Failing that, some folks on matrix were discussing just dropping the `salt-
master` package and building the rest the normal Fedora way.  Does that seem 
feasible?

[1] - https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/


--
Robby Callicotte
he/him/his
@rcallicotte:fedora.im


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Simpler first tutorial package for Package Maintainer Docs

[Kenneth Goldman]

A review from a complete newbie ...

1. The link points to a pull request.  Where is the actual tutorial?

2. The page refers to Pagure, Antora, ... I wonder if they're necessary for 
packaging.

As a newbie, I would like an example that looks like:

1. Push the main branch to github.
2. Do these steps.
n. Push the result to Fedora.

> -Original Message-
> From: Otto Liljalaakso 
> Sent: Monday, April 22, 2024 3:29 PM
> To: Development discussions related to Fedora
> 
> Subject: [EXTERNAL] Simpler first tutorial package for Package Maintainer
> Docs
>
> Hello everybody,
>
> I wrote a pull request for Package Maintainer Docs about adding a simpler
> tutorial package than GNU Hello [1]. Since it is a larger change and I have 
> not
> received any reviews yet, I would like to announce this work here, in hope 
> of
> getting some feedback, before just merging the change. Since I have already
> described the work in the pull request description, I will just copy it here
> below. Feel free to respond on the list or in pull request comments.
>
> [1]: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__pagure.io_fedora-2Ddocs_package-2Dmaintainer-2Ddocs_pull-
> 2Drequest_153=DwIGaQ=BSDicqBQBDjDI9RkVyTcHQ=H5QohD_RgG
> RTOmpJ5rew0X87YNwM_iH7SF9XZijdV0o=ZVYh2Pnj1mqVP5ceO87VGJei
> n8OQF7fgyLfPmsvXyFeH6tl2Kb4aaz2DxgI9q2Qq=9f59NzD15enLv7LSAINyq
> u2CgUH6sNGK-Cg0UcV6s0c=
>
>  > Add simpler Banner package to packaging tutorial  >  > Packaging 
> tutorial's
> approach of packaging GNU Hello has suffered from  > certain complexities in
> GNU Hello package. The package is quite old and  > uses some tooling from
> the GNU project that are not very widely used  > any more, such as Texinfo.
> Also, the package is old and thus suffers  > from e.g. having a file that is 
> not
> UTF-8 encoded. To avoid immediately  > exposing tutorial readers to these
> quirks, make GNU Hello part 2 of the  > tutorial and add a simpler package,
> Banner, as part 1. This way the  > reader can reach a complete specfile,
> compliant with Fedora guidelines,  > quicker, and still get a feeling for
> resolving packaging quirks in the  > second part.
>  >
>  > In the future, basing the first tutorial on real packages should  > 
> probably
> be switched to hosting dedicated "test project", which avoid  > any quirks
> and can be packaged to Fedora requirements using only  > Fedora's set of
> RPM macros. Such package should also avoid GNU  > Autotools and be based
> on CMake or Meson, which are simpler to  > understand and more
> widespread today.
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an
> email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__docs.fedoraproject.org_en-2DUS_project_code-2Dof-
> 2Dconduct_=DwIGaQ=BSDicqBQBDjDI9RkVyTcHQ=H5QohD_RgGRTO
> mpJ5rew0X87YNwM_iH7SF9XZijdV0o=ZVYh2Pnj1mqVP5ceO87VGJein8O
> QF7fgyLfPmsvXyFeH6tl2Kb4aaz2DxgI9q2Qq=tFCi6cDadUhB1bZclnUCohaFJ
> rgTkvR5NnS-SHMxdHc=
> List Guidelines: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__fedoraproject.org_wiki_Mailing-5Flist-
> 5Fguidelines=DwIGaQ=BSDicqBQBDjDI9RkVyTcHQ=H5QohD_RgGRT
> OmpJ5rew0X87YNwM_iH7SF9XZijdV0o=ZVYh2Pnj1mqVP5ceO87VGJein8
> OQF7fgyLfPmsvXyFeH6tl2Kb4aaz2DxgI9q2Qq=LceMIV98ssz8tBj3dPpYKoU
> Q_6FtslD2n8OplfoD2Gs=
> List Archives: https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lists.fedoraproject.org_archives_list_devel-
> 40lists.fedoraproject.org=DwIGaQ=BSDicqBQBDjDI9RkVyTcHQ=H5Q
> ohD_RgGRTOmpJ5rew0X87YNwM_iH7SF9XZijdV0o=ZVYh2Pnj1mqVP5ce
> O87VGJein8OQF7fgyLfPmsvXyFeH6tl2Kb4aaz2DxgI9q2Qq=tUj2hgkHU9Ysg
> n51Pm4QTFm10zvnF42eY0r-1BdLZUc=
> Do not reply to spam, report it:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_fedora-
> 2Dinfrastructure_new-
> 5Fissue=DwIGaQ=BSDicqBQBDjDI9RkVyTcHQ=H5QohD_RgGRTOmpJ
> 5rew0X87YNwM_iH7SF9XZijdV0o=ZVYh2Pnj1mqVP5ceO87VGJein8OQF7f
> gyLfPmsvXyFeH6tl2Kb4aaz2DxgI9q2Qq=H_CLa7ff1mo0zci91H2hQCFU8Q6jj
> c64N-4A_lQR_NU=


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

[Bug 2278978] New: perl-Graphics-TIFF-21 is available

[bugzilla]

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

Bug ID: 2278978
   Summary: perl-Graphics-TIFF-21 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Graphics-TIFF
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 21
Upstream release that is considered latest: 21
Current version/release in rawhide: 20-5.fc40
URL: https://metacpan.org/release/Graphics-TIFF

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/15735/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Graphics-TIFF


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202278978%23c0
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Feedback wanted: Testing side-tag for switching dnf5 in Rawhide

[Przemek Klosowski via devel]

On 5/2/24 16:28, Adam Williamson wrote:

On Thu, 2024-05-02 at 15:41 -0400, Przemek Klosowski via devel wrote:

On 5/2/24 14:34, Gary Buhrmaster wrote:

While I follow the philosophy of updating
regularly, there are likely some who install Fnn, and
never update, and then would expect an update to
Fnn+2 to work without issue(s).
--

The CLI update strongly suggests doing 'dnf update --refresh' before
system-upgrade. It doesn't require it though.

I always thought it's an odd workflow; why doesn't it just force it?
While it might take a long while to complete on a stale system, it's
recommended anyway, isn't it?

I would actually hugely prefer we amend that to say `dnf --refresh
offline-upgrade download; dnf offline-upgrade reboot` or so. It's a
footgun as it stands.


Even though my personal feet are unscathed by great many online 
upgrades, I agree it's a low-probability but high-potential-for-damage 
event. Having said that, in the case of system upgrade, a lot of 
problems of online upgrades (IPC  and ABI incompatibilities, etc)  are 
not very relevant---the system will instantly reboot for the upgrade, right?


The bottom line is I am old-school and hate rebooting and the associated 
loss of 'state', but OTOH most important user-oriented applications save 
and restore state already.  It's just feels inelegant and ad-hoc, but 
may be the price of progress.


I wonder if this means that ostree / CoreOS / Silverblue are the only 
way out of this conundrum.


--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: calendar.fp.o pointing to obsolete IRC for meetings

[Kevin Fenzi]

On Fri, May 03, 2024 at 12:24:57PM GMT, Stephen Gallagher wrote:
> On Fri, May 3, 2024 at 5:18 AM Daniel P. Berrangé  wrote:
> >
> > Somehow the news that various (some ? all? ) Fedora meetings have
> > moved off IRC, to Matrix passed me by. This is not helped by the
> > official project meeting calendar:
> >
> >https://calendar.fedoraproject.org/
> >
> > which continues to mislead people who want to attend, by publishing
> > libera.chat IRC as the venue for meetings which have definitely
> > moved to Matrix.
> >
> > Who's responsible for updating this, and is there somewhere issues
> > should be reported ? Presumably whomever owns each meeting is
> > responsible for updating it to point to the new Matrix locations,
> > but do we need a bulk update ?
> >
> 
> It gets worse; the calendar can't handle Matrix locations currently.
> It expects all locations to be of the form ircroom@irc.server and
> doesn't have any way to address Matrix channels.

Right. So, I guess fedora infrastructure is 'responsible'?
But its not been at the top of any of our lists due to all the other
more important things we have going on. :( 

So, help would definitely be welcome fixing the matrix/irc issues in the
code, and then we could look at mass updating it.

Or perhaps we should be looking at retiring fedocal, but would probibly
want an open source alternative we could use or deploy.

kevin


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

Re: OCaml flambda optimizations causing a compilation slow down

[Richard W.M. Jones]

On Fri, May 03, 2024 at 10:54:02AM -0600, Jerry James wrote:
> On Fri, May 3, 2024 at 6:22 AM Richard W.M. Jones  wrote:
> > In Fedora we enable flambda in our OCaml package.  Debian does not.
> 
> As the person who pushed to get flambda enabled in Fedora, I feel kind
> of responsible for this.

I'm not really sure it's a problem.  Annoying if you're compiling
coccinelle for sure, but it doesn't break anything.

> > We recently found that one package (coccinelle) takes much, much
> > longer to compile when this is enabled.  As in one particular file
> > goes from seconds -> 30 minutes to compile.  I investigated and the
> > difference is entirely explained by enabling flambda, and goes away
> > when disabled.  Apart from this being annoying, it doesn't seem to be
> > a problem in any other way (for example, the final program doesn't
> > noticable run faster or slower).  Upstream coccinelle seem to be using
> > Debian and therefore haven't seen the problem.
> >
> > Thread about all that:
> > https://lore.kernel.org/cocci/20240502085433.ga30...@redhat.com/
> >
> > This email is mostly to notify that this is happening.  I'm not sure
> > if a single package slowing down compilation means we need to do
> > anything here, but if anyone else sees similar symptoms, let us know.
> 
> Wow, that's an amazing blow up in compile time.  I note that the file
> in question is generated by menhir.  I remember seeing reports that
> some menhir features generate code that cause compile times to
> explode.  I can't seem to find a usable link to the menhir mailing
> list archives at the moment.  I can experiment with the different code
> generation options from menhir and see if anything helps.
> 
> Also, I was going to contact you about this today, but OCaml 5.2.0RC1
> was tagged yesterday.  I started doing test builds here:
> 
> https://copr.fedorainfracloud.org/coprs/jjames/OCaml5.2/

I was watching the bug and planning to ignore it until 5.2 was
released.  However it's great that you're doing test builds, thanks.

> I need to build a few more packages before coccinelle can be
> attempted, but it will be interesting to see if the build time
> improves.

I tested the tip of the 5.1 branch upstream and that still had the
issue.  I didn't test 5.2.

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

Re: OCaml flambda optimizations causing a compilation slow down

[Jerry James]

On Fri, May 3, 2024 at 6:22 AM Richard W.M. Jones  wrote:
> In Fedora we enable flambda in our OCaml package.  Debian does not.

As the person who pushed to get flambda enabled in Fedora, I feel kind
of responsible for this.

> We recently found that one package (coccinelle) takes much, much
> longer to compile when this is enabled.  As in one particular file
> goes from seconds -> 30 minutes to compile.  I investigated and the
> difference is entirely explained by enabling flambda, and goes away
> when disabled.  Apart from this being annoying, it doesn't seem to be
> a problem in any other way (for example, the final program doesn't
> noticable run faster or slower).  Upstream coccinelle seem to be using
> Debian and therefore haven't seen the problem.
>
> Thread about all that:
> https://lore.kernel.org/cocci/20240502085433.ga30...@redhat.com/
>
> This email is mostly to notify that this is happening.  I'm not sure
> if a single package slowing down compilation means we need to do
> anything here, but if anyone else sees similar symptoms, let us know.

Wow, that's an amazing blow up in compile time.  I note that the file
in question is generated by menhir.  I remember seeing reports that
some menhir features generate code that cause compile times to
explode.  I can't seem to find a usable link to the menhir mailing
list archives at the moment.  I can experiment with the different code
generation options from menhir and see if anything helps.

Also, I was going to contact you about this today, but OCaml 5.2.0RC1
was tagged yesterday.  I started doing test builds here:

https://copr.fedorainfracloud.org/coprs/jjames/OCaml5.2/

I need to build a few more packages before coccinelle can be
attempted, but it will be interesting to see if the build time
improves.
-- 
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

Re: calendar.fp.o pointing to obsolete IRC for meetings

[Stephen Gallagher]

On Fri, May 3, 2024 at 5:18 AM Daniel P. Berrangé  wrote:
>
> Somehow the news that various (some ? all? ) Fedora meetings have
> moved off IRC, to Matrix passed me by. This is not helped by the
> official project meeting calendar:
>
>https://calendar.fedoraproject.org/
>
> which continues to mislead people who want to attend, by publishing
> libera.chat IRC as the venue for meetings which have definitely
> moved to Matrix.
>
> Who's responsible for updating this, and is there somewhere issues
> should be reported ? Presumably whomever owns each meeting is
> responsible for updating it to point to the new Matrix locations,
> but do we need a bulk update ?
>

It gets worse; the calendar can't handle Matrix locations currently.
It expects all locations to be of the form ircroom@irc.server and
doesn't have any way to address Matrix channels.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: [Fedocal] Reminder meeting : ELN SIG

[Stephen Gallagher]

=
# #meeting:fedoraproject.org: eln
=

Meeting started by @sgallagh:fedora.im at 2024-05-03 16:02:32



Meeting summary
---
* TOPIC: Init Process (@sgallagh:fedora.im, 16:02:47)
* TOPIC: Agenda (@sgallagh:fedora.im, 16:05:27)
* INFO: Davide and Stephen will present on Fedora ELN at Red Hat
Summit's Community Day on Monday in Denver, Colorado.
(@sgallagh:fedora.im, 16:12:27)

Meeting ended at 2024-05-03 16:18:12

Action items


People Present (lines said)
---
* @sgallagh:fedora.im (13)
* @zodbot:fedora.im (4)
* @nhanlon:beeper.com (2)
* @meetbot:fedora.im (2)
* @yselkowitz:fedora.im (1)
* @davide:cavalca.name (1)

On Thu, May 2, 2024 at 8:00 AM  wrote:
>
> Dear all,
>
> You are kindly invited to the meeting:
>ELN SIG on 2024-05-03 from 12:00:00 to 13:00:00 US/Eastern
>At fedora-meet...@irc.libera.chat
>
> The meeting will be about:
>
>
>
> Source: https://calendar.fedoraproject.org//meeting/10568/
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Self Introduction: Jan André Reuter

[Benson Muite]

On 03/05/2024 12.29, Jan Andre Reuter wrote:
> Hey everyone,
> 
> I'd like to self introduce myself to the devel community.
> 
> My name is Jan, I'm 27 years old and working in the Jülich
> Supercomputing Centre (JSC) at the Research Center Jülich as a software
> developer and researcher. I've started working at the Research Center
> back in 2015, initially as a part of the vocational training for a
> mathematical technical software developer and since 2018 as a researcher
> working on software for HPC systems (full time since 2020, after
> finishing my masters). In December 2022, I switched institutes and
> joined the Parallel Performance team at JSC to work on the open-source
> performance infrastructure Score-P and improve its support for OpenMP
> (mostly via the OpenMP Tools Interface), compilers, and accelerators in
> general.
> 
> My interests in general involve everything around HPC development and
> performance analysis, and (on a less work-focused level) PC hardware and
> board games.
> 
> After our last release mid March, I've noticed that the Fedora package
> of Score-P was a few versions behind the current one. As we update most
> of the available install methods ourselves (like EasyBuild/Spack), I was
> also interested in providing a newer version for Fedora. Therefore, I
> decided to learn a bit about the packaging and open a PR to update it to
> the latest release. I have still a lot to learn, but I'm eager to learn
> more about the packaging and everything around it.
> 
> You can find my first PRs down below:
> 
> - Update Score-P to v8.4:
> https://src.fedoraproject.org/rpms/scorep/pull-request/1
> - Update OPARI2 to v2.0.8:
> https://src.fedoraproject.org/rpms/opari2/pull-request/1
> - Fix for update, since Score-P requires libunwind-devel to be present:
> https://src.fedoraproject.org/rpms/scorep/pull-request/2
> 
> In the long term, I'd love to help maintaining Score-P
>  and its associated packages
> (OPARI2 , Cube
> , Scalasca
> , OTF2
> ) for Fedora, since our
> releases are often coupled together and I have close contact to the
> people working on these packages.

Welcome Jan.  You might also consider joining the Science and Technology
and Heterogeneous Computing SIGs:
https://fedoraproject.org/wiki/Category:SciTech_SIG
https://fedoraproject.org/wiki/SIGs/HC

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

Re: Unresponsive packagers: suanand and vponcova

[Frantisek Zatloukal]

vponcova left Red Hat, and I don't think she'll be continuing to maintain
the packages,

Adding mkolman to CC.

On Fri, May 3, 2024 at 10:57 AM Pierre-Yves Chibon 
wrote:

> Good Morning Everyone,
>
> We have been emailing daily the following users to notify that the email
> they
> have set in FAS does not correspond to a valid bugzilla account.
> This is a requirement for Fedora packagers.
>
> Does someone know how to contact them?
>
> suanand - emailed since April 5th
>
> suanand is maintainer of rpms/gettext
> suanand is main admin of rpms/php-gettext-gettext
>   rpms/php-gettext-gettext co-maintainers: @petersen
> suanand has a bugzilla override on rpms/php-gettext-gettext
> suanand is main admin of rpms/php-gettext-languages
>   rpms/php-gettext-languages co-maintainers: @petersen
> suanand has a bugzilla override on rpms/php-gettext-languages
> suanand is maintainer of rpms/python-polib
> suanand is maintainer of rpms/python-tinydb
> suanand is maintainer of rpms/translate-toolkit
> suanand is maintainer of rpms/transtats-cli
> suanand is maintainer of rpms/zanata-python-client
>
> vponcova - emailed since February 26th
>
> vponcova is maintainer of rpms/anaconda
> vponcova is maintainer of rpms/pykickstart
> vponcova is maintainer of rpms/python-blivet
> vponcova is maintainer of rpms/python-dasbus
>
>
> Thanks for your help,
>
> Pierre
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 

Best regards / S pozdravem,

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

Fedora rawhide compose report: 20240503.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20240502.n.0
NEW: Fedora-Rawhide-20240503.n.0

= SUMMARY =
Added images:2
Dropped images:  0
Added packages:  3
Dropped packages:0
Upgraded packages:   112
Downgraded packages: 0

Size of added packages:  1.29 MiB
Size of dropped packages:0 B
Size of upgraded packages:   21.54 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Kinoite ociarchive ppc64le
Path: Kinoite/ppc64le/images/Fedora-Kinoite-Rawhide.20240503.n.0.ociarchive
Image: LXQt live aarch64
Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-Rawhide-20240503.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: mingw-directxmath-3.19-1.fc41
Summary: MinGW Windows directxmath library
RPMs:mingw32-directxmath mingw64-directxmath
Size:233.37 KiB

Package: psmoveapi-4.0.12^20240424git26e1446-1.fc41
Summary: Library for 6DoF tracking of the PS Move Motion Controller
RPMs:psmoveapi psmoveapi-devel psmoveapi-doc psmoveapi-examples 
psmoveapi-libs
Size:978.34 KiB

Package: python-crypt-r-3.13.1-1.fc41
Summary: A copy of the `crypt` module that was removed in Python 3.13
RPMs:python3-crypt-r
Size:107.44 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  NiaAML-GUI-0.3.0-1.fc41
Old package:  NiaAML-GUI-0.2.1-1.fc41
Summary:  GUI for NiaAML Python package
RPMs: NiaAML-GUI
Size: 90.40 KiB
Size change:  617 B
Changelog:
  * Thu May 02 2024 Benjamin A. Beasley  - 0.3.0-1
  - Update to 0.3.0 (close RHBZ#2278098)


Package:  anthy-unicode-1.0.0.20240502-1.fc41
Old package:  anthy-unicode-1.0.0.20211224-13.fc41
Summary:  Japanese character set input library for Unicode
RPMs: anthy-unicode anthy-unicode-devel emacs-anthy-unicode
Size: 28.48 MiB
Size change:  -22.04 KiB
Changelog:
  * Thu May 02 2024 Takao Fujiwara  - 1.0.0.20211224-15
  - Delete upstreamed anthy-unicode-HEAD.patch

  * Thu May 02 2024 Takao Fujiwara  - 1.0.0.20240502-1
  - Bump to 1.0.0.20240502


Package:  at-3.2.5-10.fc41
Old package:  at-3.2.5-9.fc40
Summary:  Job spooling tools
RPMs: at
Size: 247.38 KiB
Size change:  -2.30 KiB
Changelog:
  * Thu May 02 2024 Ond??ej Poho??elsk??  - 3.2.5-10
  - Corrected document-n patch
  - Resolves: rhbz#2276918


Package:  azote-1.12.7-1.fc41
Old package:  azote-1.12.5-1.fc41
Summary:  Wallpaper and color manager for Sway, i3 and some other WMs
RPMs: azote
Size: 7.65 MiB
Size change:  -717 B
Changelog:
  * Fri May 03 2024 Bob Hepple  - 1.12.7-1
  - new version


Package:  btrfs-progs-6.8.1-1.fc41
Old package:  btrfs-progs-6.8-1.fc41
Summary:  Userspace programs for btrfs
RPMs: btrfs-progs btrfs-progs-devel libbtrfs libbtrfsutil 
python3-btrfsutil
Size: 6.66 MiB
Size change:  -3.31 KiB

Package:  cascadia-code-fonts-2404.23-1.fc41
Old package:  cascadia-code-fonts-2111.01-8.fc40
Summary:  A mono-spaced font designed for programming and terminal emulation
RPMs: cascadia-code-fonts cascadia-code-nf-fonts cascadia-code-pl-fonts 
cascadia-fonts-all cascadia-mono-fonts cascadia-mono-nf-fonts 
cascadia-mono-pl-fonts
Added RPMs:   cascadia-code-nf-fonts cascadia-mono-nf-fonts
Size: 14.82 MiB
Size change:  10.19 MiB
Changelog:
  * Thu May 02 2024 Tom Callaway  - 2404.23-1
  - update to 2404.23
  - add "nerd fonts" variants and subpackages


Package:  chirp-0.4.0^20240429gitcab8248e-8.fc41
Old package:  chirp-0.4.0^20240429gitcab8248e-7.fc41
Summary:  A tool for programming two-way radio equipment
RPMs: chirp chirp+wx
Size: 2.43 MiB
Size change:  794 B
Changelog:
  * Thu May 02 2024 Jaroslav ??karvada  - 
0.4.0^20240429gitcab8248e-8
  - Dropped python3-future requirement from the tox
Related: rhbz#2276608


Package:  coccinelle-1.2-1.fc41
Old package:  coccinelle-1.1.1-31.20230624git0afff7f.fc41
Summary:  Semantic patching for Linux (spatch)
RPMs: coccinelle coccinelle-bash-completion coccinelle-doc 
coccinelle-examples
Size: 141.29 MiB
Size change:  19.36 MiB
Changelog:
  * Thu May 02 2024 Richard W.M. Jones  - 1.2-1
  - Update to 1.2 (RHBZ#2272154)


Package:  compiler-rt-18.1.3-2.fc41
Old package:  compiler-rt-18.1.3-1.fc41
Summary:  LLVM "compiler-rt" runtime libraries
RPMs: compiler-rt
Size: 8.69 MiB
Size change:  2.19 KiB
Changelog:
  * Sat Apr 27 2024 Songsong Zhang  - 18.1.3-2
  - Add riscv64 support


Package:  crun-1.15-1.fc41
Old package:  crun-1.14.4-5.fc41
Summary:  OCI runtime written in C
RPMs: crun crun-krun crun-wasm
Size: 965.25 KiB
Size change:  1.22 KiB
Changelog:
  * Thu May 02 2024 Packit  - 1.15-1
  - Update to 1.15 upstream release


Package:  distrobox-1.7.2.0-1.fc41
Old package:  distrobox-1.7.1-2.fc41
Summary:  Another tool for containerized comma

OCaml flambda optimizations causing a compilation slow down

[Richard W.M. Jones]

In Fedora we enable flambda in our OCaml package.  Debian does not.

Flambda is "a series of optimisation passes provided by the native
code compilers as of OCaml 4.03" and "aims to make it easier to write
idiomatic OCaml code without incurring performance penalties".  In
other words, it claims to be a better optimizer.

More here:
https://ocaml.org/manual/5.1/flambda.html

We recently found that one package (coccinelle) takes much, much
longer to compile when this is enabled.  As in one particular file
goes from seconds -> 30 minutes to compile.  I investigated and the
difference is entirely explained by enabling flambda, and goes away
when disabled.  Apart from this being annoying, it doesn't seem to be
a problem in any other way (for example, the final program doesn't
noticable run faster or slower).  Upstream coccinelle seem to be using
Debian and therefore haven't seen the problem.

Thread about all that:
https://lore.kernel.org/cocci/20240502085433.ga30...@redhat.com/

This email is mostly to notify that this is happening.  I'm not sure
if a single package slowing down compilation means we need to do
anything here, but if anyone else sees similar symptoms, let us know.

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

Re: SPDX Statistics - L'Aigle meteorite edition

[Miroslav Suchý]

Dne 03. 05. 24 v 10:44 dop. Tim Landscheidt napsal(a):

Maybe I misunderstood the original post, but I did not per-
ceive the intent of the data's publication to be informative
and useful, but to motivate (converting the licenses).


This.

And to provide at least some estimates. When we started with this, there were people estimating the work for few months. 
Others to decades.


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

Re: SPDX Statistics - L'Aigle meteorite edition

[Miroslav Suchý]

Dne 03. 05. 24 v 1:59 dop. Gary Buhrmaster napsal(a):

Joking aside, I do agree the non-trivial conversions are
likely to be the hard ones, and there will be a very long
tail (many years more) for 100% as the work to deal with
some of those hard ones may require expertise that is
in limited or even unavailable supply, and when they
require new (legal) license reviews and SPDX definitions
they can take quite some time.  Alternatively, it is possible
that there is a target (say, 95%) after which the SPDX
conversion project will be stated to be "essentially"
complete and is ended even if not 100%.


The current change

https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_4

is planned to be the last one. At the end of this phase - scheduled to 2024-08-06 - we plan to mark this conversion as 
"done". My estimation is that by that time 80% tags will be migrated. Everything remaining will treated as a bug. I will 
open BZ for every remaining package.


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

Self Introduction: Jan André Reuter

[Jan Andre Reuter]

Hey everyone,

I'd like to self introduce myself to the devel community.

My name is Jan, I'm 27 years old and working in the Jülich 
Supercomputing Centre (JSC) at the Research Center Jülich as a software 
developer and researcher. I've started working at the Research Center 
back in 2015, initially as a part of the vocational training for a 
mathematical technical software developer and since 2018 as a researcher 
working on software for HPC systems (full time since 2020, after 
finishing my masters). In December 2022, I switched institutes and 
joined the Parallel Performance team at JSC to work on the open-source 
performance infrastructure Score-P and improve its support for OpenMP 
(mostly via the OpenMP Tools Interface), compilers, and accelerators in 
general.


My interests in general involve everything around HPC development and 
performance analysis, and (on a less work-focused level) PC hardware and 
board games.


After our last release mid March, I've noticed that the Fedora package 
of Score-P was a few versions behind the current one. As we update most 
of the available install methods ourselves (like EasyBuild/Spack), I was 
also interested in providing a newer version for Fedora. Therefore, I 
decided to learn a bit about the packaging and open a PR to update it to 
the latest release. I have still a lot to learn, but I'm eager to learn 
more about the packaging and everything around it.


You can find my first PRs down below:

- Update Score-P to v8.4: 
https://src.fedoraproject.org/rpms/scorep/pull-request/1
- Update OPARI2 to v2.0.8: 
https://src.fedoraproject.org/rpms/opari2/pull-request/1
- Fix for update, since Score-P requires libunwind-devel to be present: 
https://src.fedoraproject.org/rpms/scorep/pull-request/2


In the long term, I'd love to help maintaining Score-P 
 and its associated packages 
(OPARI2 , Cube 
, Scalasca 
, OTF2 
) for Fedora, since our 
releases are often coupled together and I have close contact to the 
people working on these packages.


Jan

--
Jan André Reuter
Jülich Supercomputing Centre (JSC)
ATML Parallel Performance
Phone: +49-2461-61-8871
E-Mail:j.reu...@fz-juelich.de
Internet:http://www.fz-juelich.de

-
-
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Stefan Müller
Geschaeftsfuehrung: Prof. Dr. Astrid Lambrecht (Vorsitzende),
Karsten Beneke (stellv. Vorsitzender), Dr. Ir. Pieter Jansens, Prof. Dr. Frauke 
Melchior
-
-



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

calendar.fp.o pointing to obsolete IRC for meetings

[Daniel P . Berrangé]

Somehow the news that various (some ? all? ) Fedora meetings have
moved off IRC, to Matrix passed me by. This is not helped by the
official project meeting calendar:

   https://calendar.fedoraproject.org/

which continues to mislead people who want to attend, by publishing
libera.chat IRC as the venue for meetings which have definitely
moved to Matrix.

Who's responsible for updating this, and is there somewhere issues
should be reported ? Presumably whomever owns each meeting is
responsible for updating it to point to the new Matrix locations,
but do we need a bulk update ?

With regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: Drop Mandatory Requires on JRE (system-wide)

[Marián Konček]

Replying to some previous comments:

* OpenJDK 21 is the last version to support Java 8 AFAIK.
* Indeed it is possible to compile projects using the system JDK 
together with the -target + -source / --release flags.
* In the spirit of "staying close to the upstream", the our (Maven) 
ecosystem does not touch the compilation flags unless the project can 
not be built using the system JDK. In that case we tend to override the 
selected version to the closest version supported by the system JDK. 
(See how moving to to OpenJDK 21 required adding these flags in majority 
of the failing builds.)
* I am in favor of adding soft RPM constraints on the Java libraries 
regarding the bytecode version (like Recommends field) but this move is 
heavily dependent on what the OpenJDK Provides fields are. I heard there 
was evolution and some complex reasons why they decided to change the 
Provides. For this reason, I am not in favor of adding hard constraints 
(Requires) on Java packages.


On 3. 5. 2024 7:44, Christopher wrote:

On Thu, May 2, 2024 at 9:24 PM Kevin Kofler via devel
 wrote:

Christopher wrote:

So, I actually think that building with the *latest* JDK that we ship,
and using the `--release` flag during compilation is actually safer
than building against the lowest that we support, because it is most
likely to strictly enforce correct byte code generation for the target
JRE.

The problem is, without ALSO installing the JDK for the targeted version AND
explicitly pointing -bootclasspath to that JDK, this does NOT catch code
trying to use class library features (as opposed to language or bytecode

For context, the use of the bootclasspath is only applicable to
building for Java 8. (A related question that I don't know the answer
to: how much longer is Fedora going to include Java 8?)

However, I believe you are incorrect. JEP 247, which added the
`--release` flag, specifically made it replace the need for using
`-bootclasspath`. See https://openjdk.org/jeps/247 ; The problem I
described in the email you're replying to is specifically that the
`-bootclasspath` with JDK 8 will pick up class APIs *outside* of the
"", whereas the use of `--release 8` strictly
enforces that only the "" are available. This
is what I meant when I said that using the `--release` flag more
strictly enforces Java 8 language compliance than building with JDK 8.
I stand by that statement. It is the `-bootclasspath` that leads
people astray, and thus it has been removed for Java 9 and later.


features) from the newer JDK, and worse, in rare occasions, even if the
source code is in principle compatible with the targeted older Java, when
compiled with a newer compiler and older target release, it will fail to
actually run (!) with the latter (because the compiler picks up a subclass
override of a method added in the newer Java instead of the baseclass method
that was always available and, for performance reasons, tries calling the
override explicitly rather than going through the virtual method lookup).
One example of that latter issue is NetBeans, where versions 12.5 and 12.6
were supposed to be compatible with Java 8, but some upstream-published
binaries of 12.5 and all of 12.6 do not actually work properly on it because
they were built with Java 11 in "-release 8" mode: some editor features fail
with runtime exceptions. See
https://issues.apache.org/jira/browse/NETBEANS-6349 for details. (They
"fixed" it by just requiring Java 11 in NetBeans 13 and newer. No fixed 12.x
release was ever issued.)

The CharBuffer/ByteBuffer issues mentioned in that are specifically
issues that the use of `--release` resolves. I have fixed this in
several projects already who encountered this same issue. Digging into
the tickets you linked, it looks like the problem with that issue was
that the binaries were built with JDK 11 *without* the use of the
`--release` flag... or rather, it looks like somebody tried to use the
`--release` flag, but they also used `-Xbootclasspath`, which ended up
*disabling* the `--release` behavior. The problem isn't the use of
`--release`, it's the *non*-use of it... or the broken use of it,
because boot class path options are still being used when they
shouldn't. So again, I assert that it's the `-bootclasspath` option
that is leading people astray.


So I am AGAINST systematically using "-release" without "-bootclasspath",
even though that works in most cases and is often successfully used in
production (me and my employer use it, too, but on projects we control where
we will fix the source code or add a workaround to it if any issues come up
from that, not systematically on repackaging third-party projects). The
compiler even warns about the missing "-bootclasspath". And the potential to
cause subtle misbehavior that is a pain to debug is just too high,
especially if we have the actual older JDK available and could just
BuildRequire the correct version.

This doesn't make sense. The purpose of the `--release` flag was to

Unresponsive packagers: suanand and vponcova

[Pierre-Yves Chibon]

Good Morning Everyone,

We have been emailing daily the following users to notify that the email they
have set in FAS does not correspond to a valid bugzilla account.
This is a requirement for Fedora packagers.

Does someone know how to contact them?

suanand - emailed since April 5th

suanand is maintainer of rpms/gettext
suanand is main admin of rpms/php-gettext-gettext
  rpms/php-gettext-gettext co-maintainers: @petersen
suanand has a bugzilla override on rpms/php-gettext-gettext
suanand is main admin of rpms/php-gettext-languages
  rpms/php-gettext-languages co-maintainers: @petersen
suanand has a bugzilla override on rpms/php-gettext-languages
suanand is maintainer of rpms/python-polib
suanand is maintainer of rpms/python-tinydb
suanand is maintainer of rpms/translate-toolkit
suanand is maintainer of rpms/transtats-cli
suanand is maintainer of rpms/zanata-python-client

vponcova - emailed since February 26th

vponcova is maintainer of rpms/anaconda
vponcova is maintainer of rpms/pykickstart
vponcova is maintainer of rpms/python-blivet
vponcova is maintainer of rpms/python-dasbus


Thanks for your help,

Pierre
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: SPDX Statistics - L'Aigle meteorite edition

[Tim Landscheidt]

John Reiser  wrote:

>> New projection when we will be finished is 2025-04-06 (+5
>> days from last report).  Pure linear approximation.

> Such a linear approximation, based on the entire tracked history,
> is the second worst possible estimate.  (The worst possible estimate
> is the output of a random date generator.)

> Financial markets and other arenas using serious statistical forecasting
> have known for decades that it is much better to estimate by assuming
> a rate equal to the moving average rate over a fixed-length relevant
> period.  Repeatedly estimating based on the entire history does not
> meet the fixed-length requirement, because the entire history grows.
> Typical periods range from a small number of months to one year.
> For Fedora, one relevant period might be six months, the
> interval between scheduled releases.  Also useful are 90 and
> 120 days.

> Graphing the estimated completion date based on such a moving
> average rate would be much more informative and useful than the
> estimated dates which have been published so far.

Maybe I misunderstood the original post, but I did not per-
ceive the intent of the data's publication to be informative
and useful, but to motivate (converting the licenses).

Tim
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Is glibc32 retired?

[Fabio Valentini]

On Fri, May 3, 2024, 09:34 Florian Weimer  wrote:

> I didn't have a dist-git token for fedpkg, so retiring failed after
> doing some work the first time.  Is the package actually retired?
>

It looks like the retirement was successful

The dist-git token is only necessary for one API call - disabling the
"monitoring" setting. But that was already disabled for this package, so it
wouldn't have changed anything.


> This command
>
>   koji list-history --package=glibc32
>
> does not show any recent activity.  I would expect something to untag it
> from the buildroot.
>

This should happen when the retirement is processed during the next rawhide
compose.


> (Bonus question: can we retire the package from Fedora 40, too?)
>

No. Retirements can only happen until the start of the final freeze.

Fabio


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

Is glibc32 retired?

[Florian Weimer]

I didn't have a dist-git token for fedpkg, so retiring failed after
doing some work the first time.  Is the package actually retired?

This command

  koji list-history --package=glibc32

does not show any recent activity.  I would expect something to untag it
from the buildroot.

(Bonus question: can we retire the package from Fedora 40, too?)

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