devel August 2021

devel@lists.stg.fedoraproject.org

183 participants
358 discussions

Re-Launching the Java SIG
by Fabio Valentini 15 Sep '21

15 Sep '21

This past weekend I finally decided to jump off the cliff and attempt to re-launch the Java SIG. It seems there's some interest in keeping the Java stack maintained, it's just not focused or organized right now. What we did when starting the Stewardship SIG seems to have worked out pretty well, so I'm trying to follow in those footsteps here: - new proper FAS / pkgdb group: java-maint-sig ("java-sig" is occupied by an old, unused bot account) - new private mailing list: java-maint-sig (for RHBZ bugs - so, possibly, also CVEs - hence, private) - tracking project on pagure: https://pagure.io/java-maint-sig (for maintenance scripts, tracking tickets, awesome package dashboards, etc.) There's already a public fedora mailing list for Java (java-devel), and and IRC channel (#fedora-java on freenode.net) which we will continue to use. Sadly, the existing wiki page for the Java SIG is hopelessly outdated, so I'm tempted to just scrap it and point readers to the pagure tracking project once it's set up beyond a basic README file. Major upcoming projects for the "new" Java Package Maintainers group include: - managing OpenJDK 11 / Java 11 transition for hundreds of Java packages in fedora 33 - starting to transition well-maintained Java packages from the Stewardship SIG back into Java SIG - possibly porting packages from gradle to maven to fix build issues and broken dependencies - transitioning from old java.net / JavaEE projects to the new ones now under the eclipse-ee4j umbrella I know that - among others - the PKI team, Neuro SIG, and Eclipse maintainers depend on parts of the java stack for their packages, so I hope that we can work together with them on these things, as well. So, if you're interested, please consider joining this group effort. I'll get new members set up with the FAS group / pagure project / mailing list. Let's make this happen. Fabio

36 90

Linux 5.13 To Allow Zstd Compressed Modules, Zstd Update Pending With Faster Performance
by Reon Beon 12 Sep '21

12 Sep '21

LINUX KERNEL -- Adding to the variety of places where the Linux kernel supports making use of Zstd compression, kernel modules moving forward can now enjoy size reductions with Zstd. Linux already supports optional Gzip and XZ compression of kernel modules while beginning with Linux 5.13 there is support added for Zstd. In user-space, KMOD 28 already supports dealing with Zstd-compressed modules. The compressed modules are suffixed .ko.zst. The support for Zstd compressed kernel modules was sent in as part of the Kbuild updates for the Linux 5.13 merge window. The Kbuild updates also include more LLVM Clang compiler handling work and other alterations, including an indicator whether the kernel was built with link-time optimizations (LTO). Separate from the Kbuild updates and likely for post-5.13, there is renewed work on getting the latest Zstd code within the kernel updated against the upstream state. These patches get the Zstd code in the kernel updated against the latest upstream code, which is much newer than the current Zstd 1.3.1 derived code in the kernel. The Zstd kernel code is now generated automatically from the upstream Zstd code. With this pending Zstd code update for the kernel, Btrfs with Zstd compression is 5~15% faster, SquashFS decompression is ~15% faster, F2FS Zstd is 3~20% faster, kernel Zstd decompression is 35% faster, Zram decompression and read is 30% faster, and initramfs Zstd compression is around 5% faster. Plus there are bug fixes and other improvements in re-basing the kernel's Zstd code-base. https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.13-Zstd-Modules

6 12

Announcing fmt library soversion bump
by Vitaly Zaitsev 09 Sep '21

09 Sep '21

Hello. fmt 8.0.x update will include soversion bump from .7 to .8. All dependent packages must be rebuilt in Rawhide. -- Sincerely, Vitaly Zaitsev (vitaly(a)easycoding.org)

7 19

pdftk retired?
by Michael J Gruber 08 Sep '21

08 Sep '21

I just git a "broken dependencies" notice for a package that I maintain. The reason is that "pdftk" got retired just the other day. I may have missed a corresponding post on fedora-devel, but I think a heads up notice to maintainers of depending packages may be in order before you retire a package, as a general idea. You see, unretiring a package is so much more work than changing maintainership. As for pdftk: I see 2 failed builds for version 1.45 and none for the current version 2.02 (which probably breaks the api anyways). What are the plans? Retire pdftk completely? Start fresh with pdftk2? pdflabs, the maker of pdftk, provide binary as well as source rpms for pdftk 2.02, by the way. I might even look into packaging it but don't want to duplicate any existing efforts. Michael

17 26

perl-Data-Properties License change
by Emmanuel Seyman 07 Sep '21

07 Sep '21

Hello, folks. Sometime over the coming week, I'm going to update the perl-Data-Properties package from the current 0.02 to 1.05. Among other changes, the license changes from ASL 2.0 to the Perl license (GPL+ or Artistic). Please holler if this creates a problem for you. Regards, Emmanuel

1 1

ARM 32-bit failure for wine
by Michael Cronenworth 04 Sep '21

04 Sep '21

Hi, I've had some life events keep me from pushing package updates for about a month. My attempt at pushing the latest wine update resulted in an ARM build failure that seems to indicate either a toolchain changes or compiler error. I couldn't find any Fedora 36 changes to match. Any ideas? Build error: https://koji.fedoraproject.org/koji/getfile?taskID=74819672&volume=DEFAULT&… Full build page: https://koji.fedoraproject.org/koji/taskinfo?taskID=74819487 Thanks, Michael

3 5

f35-backgrounds ready for review
by Luya Tshimbalanga 04 Sep '21

04 Sep '21

Hello team, f35-backgrounds is ready for review which is trivia to do. It is needed for the beta release along desktop-background. See https://bugzilla.redhat.com/show_bug.cgi?id=1997854 Thanks in advance -- Luya Tshimbalanga Fedora Design Team Fedora Design Suite maintainer

12 22

replace memtest86+ with pcmemtest, needs maintainer
by Chris Murphy 03 Sep '21

03 Sep '21

[Bug 1988142] memtest boot entry on Fedora install media does not work since Fedora-Rawhide-20210728.n.3 https://bugzilla.redhat.com/show_bug.cgi?id=1988142 This bug might be gcc, but also includes a note about the upstream being kinda weak, possibly non-existent these days. Neal Gompa mentioned pcmemtest earlier this year https://github.com/martinwhitaker/pcmemtest It would need a maintainer. Any takers? Fedora doesn't have a release criterion covering the memory tester, or really any option appearing in the install media's boot menu other than the one that launches the installer. But I think it's better to not ship a memory tester at all, than to ship a broken one (given the options). Memtest86+ is bios only, where pcmemtest can be compiled to run on either firmware type. If we want it to work with UEFI Secure Boot enabled, it'd need to be signed with Fedora's key (I think the same as the one used for GRUB and/or the kernel?). This would be in scope for Fedora 36, assuming the above bug can be easily fixed. But if that bug is hard to fix, and pcmemtest could be a drop-in replacement (i.e. bios only, just like now) maybe that's doable for Fedora 35, and better than having no memory tester. Chris Murphy -- Chris Murphy

12 27

SONAME BUMP HEADS-UP: ntfs-3g update for fixing multiple CVEs
by Neal Gompa 02 Sep '21

02 Sep '21

Hey all, ntfs-3g 2021.8.22 was released yesterday to resolve multiple CVEs[1]. With permission from Tom Callaway (the ntfs-3g maintainer), I am preparing updates for Fedora and EPEL now for Tom. As part of this, I'll rebuild all reverse dependencies for this. Based on a repoquery, that is: * libguestfs * ntfs-3g-system-compression * partclone * testdisk * wimlib Sorry for the inconvenience. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1999788 -- 真実はいつも一つ！/ Always, there's only one truth!

3 5

Package Maintainer Docs published
by Otto Urpelainen 31 Aug '21

31 Aug '21

Greetings, Some months ago, I announced [0] that I will move the package maintainer docs from wiki to docs.fedoraproject.org. I am happy to announce that this task is complete and the docs are public in their new location now [1]. Hopefully, this will allow existing and new packagers to find relevant documentation more easily, and foster more concentrated efforts to make it better. Let me explain how the docs are set up now. I worked mainly alone to get the actual move done. From this point on, I hope that maintenance is done by all package maintainers collectively, similarly to how the wiki documentation was under shared ownership. This also means that everything here is a draft, open for changes based on your feedback. Comments are welcome! The imported content was selected by going through wiki category Package Maintainers [2] and choosing the pages that seemed useful. In general, the pages were imported without modification, however in some cases there were such serious issues that I did some editing. Going forward, documentation for package maintainers should be added to this repo, instead of wiki. There is an issue for replacing the imported wiki pages with pointers to the new urls [3] which will be done soon. Policies, guidelines and other material owned by FESCo or the Packaging Committee is excluded from this repository and is handled like before. One change that moving from wiki to a Git repository at pagure.io brings is access control. I would like to allow all members of the 'packager' group, but unfortunately that group is not visible at pagure.io. So instead I wrote this in the README, to serve as a basis for iterating a good solution: > All changes to the documentation is intended to happen through pull > requests. However, following the spirit of earlier wiki based > documentation, the documentation is intended to be maintainer > collectively by all Fedora packagers. > > Due to technical issues, the packager group from Fedora Account > System cannot be granted access, so there is a separate group > package-maintainer-docs with commit access. Membership is granted to > any packager requesting it. Please file an issue in the repository if > you want to join. If you have any interest in the docs at all, I hope you file an issue for membership, or just reply to this mail and I will add you. Currently, I am the maintainer of the repository. There are four other people listed as admins: pingou, mattdm, kevin, codeblock. This list of a leftover from an older, unpublished iteration of the docs. To my understanding, none of these people have expressed interest in maintaining the repository, for whatever tasks there may be that cannot be handled by the committer group. So, I plan to remove everybody but myself. Naturally, to avoid non-responsive admins situation, there should be more than one admin. If you are interested, please let me know an I will add you. Otto [0]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… [1]: https://docs.fedoraproject.org/en-US/package-maintainers/ [2]: https://fedoraproject.org/wiki/Category:Package_Maintainers [3]: https://pagure.io/fedora-docs/package-maintainer-docs/issue/20

5 5

← Newer
1
2
3
4
5
6
7
...
36
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel August 2021