Self Introduction: Tom Deseyn
by Tom Deseyn
Hi everyone!
My name is Tom. I work on .NET and try to make it work well/better on Linux.
I maintain a few .NET libraries for interacting with D-Bus, systemd.
I'm joining the list because I'd like to help Omair Majid maintain
Fedora's .NET packages.
Thanks. Tom
2 years, 6 months
Re: [Fedocal] Reminder meeting : Prioritized bugs and issues
by Ben Cotton
On Tue, Dec 14, 2021 at 6:00 AM <bcotton(a)redhat.com> wrote:
>
> You are kindly invited to the meeting:
> Prioritized bugs and issues on 2021-12-15 from 11:00:00 to 12:00:00 America/Indiana/Indianapolis
> At fedora-meeting-1(a)libera.chat
>
> More information available at: https://docs.fedoraproject.org/en-US/program_management/prioritized_bugs/
There are no nominated or accepted bugs, so tomorrow's meeting is
canceled. The 29 December meeting is also canceled. If you have any
bugs to nominate, we'll review them on Wednesday 12 January 2022.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 6 months
wxGTK-devel vs wxGTK3-devel
by Steven A. Falco
The KiCad package is currently built using wxGTK3-devel (and python3-wxpython4). The upstream KiCad developers have an interest in switching to the 3.1 branch of wxGTK, available in the wxGTK-devel package.
I'm running a trial build of KiCad, substituting wxGTK-devel in place of wxGTK3-devel (via mock, configured for rawhide), but then I noticed that I have both wxGTK 3.1.5-2.fc35 and wxGTK3 3.0.5.1-6.fc36 in the mock root.log.
I also noticed that python3-wxpython4 appears to require the 3.0 branch, so that might be what is causing both 3.0 and 3.1 of wxGTK to be dragged in:
$ rpm -q --requires python3-wxpython4
...
libwx_baseu-3.0.so.0()(64bit)
...
Is there a version of python3-wxpython4 that uses 3.1? I really don't want both wxGTK versions in the build.
Steve
2 years, 6 months
The New Hotness 1.0.0 deployed on production
by Michal Konecny
Hello everyone,
The New Hotness 1.0.0 is now live in Fedora infra production
environment. For those who don't know what this app does, it basically
notifying packagers about new versions of packages by creating bugzilla
issues.
And what is new:
* The New Hotness was rewritten from scratch using clean architecture
design (it's now easier to maintain and less error prone)
* Documentation[0] was updated to be more useful and up to date
* The comments created in bugzilla should be more helpful and contain
info about errors if any happens during the scratch build
* The New Hotness now remembers the Koji Task ID,even if there is error
in post scratch build. In past the task ID was just lost and when the
build was finished The New Hotness couldn't recognize it
* We now have a containerized workflow for development
If you want to look at full changelog, please visit the-new-hotness
GitHub release page [1].
Thanks to everybody who contributed to this release!
Regards,
Michal
Mage from release-monitoring.org
[0] - https://the-new-hotness.readthedocs.io/en/stable/
[1] - https://github.com/fedora-infra/the-new-hotness/releases/tag/1.0.0
2 years, 6 months
Blender Wayland available on COPR
by Luya Tshimbalanga
Hello everyone,
Thanks to the work of one of Blender contributors [1], Blender runs on
Wayland with upstream patches yet to land mainline [2]. The method was
enabling "*WITH_GHOST_WAYLAND"*parameter along the patch setting
"BLENDER_WAYLAND" environment when running a Wayland session.
To see if the installed Blender[3], available on the COPR repository,
runs directly on Wayland, from the terminal, simply type
"WAYLAND_DEBUG=1 blender".
The side effect resolves an issue related to rendering with Open Shading
Language. The long term goal is to make Blender with Wayland support
available on the main repository starting from Rawhide and possibly the
current release i.e., Fedora 35.
Blender Wayland is available for both Rawhide, Fedora 35 and Fedora 34
for testing.[3]
References
---------------
[1] https://developer.blender.org/T90676
[2] https://developer.blender.org/D11489
[3] https://copr.fedorainfracloud.org/coprs/luya/blender-egl/build/3032066/
--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
2 years, 6 months
java-17-openjdk mass-rebuild for f36 in copr II
by Jiri Vanek
Hello fellow java package maintainers!
As you know we are buming the JDK from java-11-openjdk to java-17-openjdk for f36. Please see https://fedoraproject.org/wiki/Changes/Java17
I had updated the: https://github.com/judovana/FedoraSystemJdkBump/blob/main/scritps/spammer...
The diff is fun (https://github.com/judovana/FedoraSystemJdkBump/commit/b6d27776960146180c... :)
Small progress, quite a few source/target issues had changed to proper issues, and the https://fedoraproject.org/wiki/Changes/Java17#common_issues_packagers_can... got opulated a bit.
Still a way to go. Will compose individual summaries tomorrow.
I expect one more copr rebuild in early January, and side tag brew build at late January. Merging then during February.
Short Story:
* if you have some java package, be aware that we are bumping JDK in rawhide
* Ensure your package builds and runs fine with java-17-openjdk (see the https://copr.fedorainfracloud.org/coprs/jvanek/java17/builds/ )
* there is special tooling ready for this, before the mass rebuild is launched
** See https://fedoraproject.org/wiki/Changes/Java17#copr_preliminary_rebuild
* If you do not want Fedora to rot with java-11-openjdk for ever, continue reading
Long Story:
We ran a preliminary mass rebuild of javastack in copr repo https://copr.fedorainfracloud.org/coprs/jvanek/java17/builds/ (select "all" instead of "25" at the bottom), on packages requiring java,javac, java-devel, maven-local, ant, ivy &
comp. for build. You can see the result was quite interesting:
499 total; attempted to rebuild
77 failed; from those 44 are trivial failures (but if you fix it, there is no guarantee real troubles are not hidden behind that)
419 succeeded
3 not even srpm rebuilt - orphan? dead? (but orpahns and dead ones should be already excluded)
I would kindly ask you to search yourself in this list: https://github.com/judovana/FedoraSystemJdkBump/blob/main/scritps/fillCop...
If you are here, please check status of your package in https://github.com/judovana/FedoraSystemJdkBump/blob/main/scritps/spammer... (pain text of
https://copr.fedorainfracloud.org/coprs/jvanek/java17/builds/).
* If all your packages are "succeeded", congratulations nothing to do, and just keep en eye on JDK bump
* If there is "failed" but contains "- -" then even srpm built failes. If you wish to resurrect it, please ensure it runs against java-17-openjdk (see lower)
* If there is "failed" but failed in "seconds", then those packages failed so quickly, that the build was in initial phases. That usually mean that you build with source/target/release lower then 1.7. java-17-openjdk supports 1.7 and up.
We recommend to bump the source/target to 1.8, to allow existence of compact 1.8 packages alongside main javastack. See https://fedoraproject.org/wiki/Changes/Java17#Wrong_source.2Ftarget_version. Don't forget to upstream the patch, or
maybe it is enough to update to more fresh upstream release which supports java-17-openjdk? it may happen, that after the fix, your build will fail in more terrible way (see below)
* If there is "failed", and its none of above, then your package simply failed. Very often the scary error may be fixed by bump to latest upstream version. java-17-openjdk is out shortly, but changes against java-11-openjdk are minimal,
and upstreams keep an track. Please, try to fix the package. Don't hesitate to ask on devel(a)fedoraproject.org or java-devel(a)fedoraproject.org or directly to me jvanek(a)redhat.com. If you fix the fail, feel free to share your fix, it may help
others.
We are trying to gather the most common issues at https://fedoraproject.org/wiki/Changes/Java17#common_issues_packagers_can... . Feel free to enhance the page, or write us your case (possibly both with solution and
without) so we can add it here.
If your package is missing, and you wish it here, I will gladly add it! Just let me know - jvanek(a)redhat.com
Debugging Your failures.
The copr repo we maintain, contains builds of java-17-openjdk as system JDK, javapackages-tools, maven & comp. honoring that, and java-11-openjdk as non system JDK. Also it contains successfully rebuilt packages. You can directly use this
copr repo in several ways.
* first glance on error. On https://copr.fedorainfracloud.org/coprs/jvanek/java17/builds/ find your build (select "all" instead of "25" at the bottom),
** Click its number, select chroot (currently fedora-rawhide-x86_64 ) and check the logs. Main log is build.log.gz.
* anything you push to rawhide, will automatically rebuild here in fedora-rawhide-x86_64 chroot.
** It is the best approach. If you can fix your package in rawhide directly, without breaking the rawhide too much, go for it
** If you need to experiment, I have a mock config for you (generated from copr-cli mock-config jvanek/java17 fedora-rawhide-x86_64) which you can copy to your /etc/mock and use -
https://github.com/judovana/FedoraSystemJdkBump/blob/main/scritps/spammer... . Eg:
# as root, globally
sudo wget https://raw.githubusercontent.com/judovana/FedoraSystemJdkBump/main/scrit... -O /etc/mock/jvanek-java17-fedora-rawhide-x86_64.cfg
# or as user, locally (after creating ~/.config/mock/)
wget https://raw.githubusercontent.com/judovana/FedoraSystemJdkBump/main/scrit... -O ~/.config/mock/jvanek-java17-fedora-rawhide-x86_64.cfg
# change spec, bump sources, apply patches
fedpkg srpm
mock -r jvanek-java17-fedora-rawhide-x86_64 *.src.rpm
Or any other packaging workflow you use, and you can use against the copr repo.
Thank you very much for your help, there are 80 failures, and 270 java packagers, but only 2 active members of java sig. Without your help, the JDK bump will be very hard.
Thank You!
J.
--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09
2 years, 6 months
libwacom soname bump
by Peter Hutterer
Hi all,
libwacom had a soname bump for the upcoming release. I've already rebuilt
- libinput
- cinnamon, cinnamon-control-center and cinnamon-settings-daemon
- mutter, gnome-control-center, gnome-settings-daemon
- kcm_wacomtablet (FTBFS though, #2031611)
That should be it, if you have a package not in the above list that uses
libwacom please let me know though, I'd be interested to hear about it.
Cheers,
Peter
2 years, 6 months
