jpegxl soname bump
by Scott Talbert
Hi @eclipseo,
Looks like jpegxl soname was bumped, breaking a bunch of stuff:
2021-11-21 20:20:51
Package resolution failed
Problem: package gd-2.3.3-3.fc36.x86_64 requires
libavif.so.12()(64bit), but none of the providers can be installed
- package graphviz-2.49.3-2.fc36.x86_64 requires libgd.so.3()(64bit),
but none of the providers can be installed
- package libavif-0.9.2-2.fc35.x86_64 requires libaom.so.3()(64bit),
but none of the providers can be installed
- conflicting requests
- nothing provides libjxl.so.0()(64bit) needed by
libaom-3.1.2-1.fc35.x86_64
- nothing provides libjxl.so.0(JXL_0)(64bit) needed by
libaom-3.1.2-1.fc35.x86_64
Problem: package graphviz-2.49.3-2.fc36.x86_64 requires
libgd.so.3()(64bit), but none of the providers can be installed
- package gd-2.3.3-3.fc36.x86_64 requires libavif.so.12()(64bit), but
none of the providers can be installed
- package doxygen-2:1.9.1-12.fc36.x86_64 requires graphviz, but none
of the providers can be installed
- package libavif-0.9.2-2.fc35.x86_64 requires libaom.so.3()(64bit),
but none of the providers can be installed
- conflicting requests
- nothing provides libjxl.so.0()(64bit) needed by
libaom-3.1.2-1.fc35.x86_64
- nothing provides libjxl.so.0(JXL_0)(64bit) needed by
libaom-3.1.2-1.fc35.x86_64
Thanks,
Scott
1 year, 1 month
F36 Change: ostree native containers / CoreOS layering (System-Wide
Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/OstreeNativeContainer
== Summary ==
Enhance the (rpm-)ostree stack to natively support OCI/Docker
containers as a transport and delivery mechanism for operating system
content.
This is the basis of
https://github.com/coreos/enhancements/blob/main/os/coreos-layering.md
== Owner ==
* Name: [[User:walters| Colin Walters]]
* Email: walters(a)verbum.org
== Detailed Description ==
Having the Fedora ecosystem (from users to release engineering)
maintain tooling that operates on all three of "container images",
RPMs, and OSTree updates is a maintenance burden.
This proposes that:
* The ostree stack is enhanced to support
encapsulating/unencapsulating ostree commits as OCI/Docker images
(DONE)
* rpm-ostree is updated to consume this, while still supporting all
its current features (e.g. per-machine package layering) (DONE)
* We ship e.g. `quay.io/fedora/coreos:stable` and
`quay.io/fedora/silverblue:36` etc.
* We support '''deriving''' new user custom images from these images
* We enhance this tooling to
[https://github.com/ostreedev/ostree-rs-ext/issues/69 support
chunking]
For more details, please see:
* [https://github.com/coreos/enhancements/blob/main/os/coreos-layering.md
CoreOS layering enhancement]
* [https://coreos.github.io/rpm-ostree/container/ rpm-ostree container docs]
* [https://github.com/ostreedev/ostree-rs-ext/ ostree-rs-ext project]
Note that significant effort has been invested in ensuring
compatibility between what exists in ostree today and OCI/Docker
container image "encapsulation". For example, we will continue to
reuse the GPG signature infrastructure on OSTree commits that exists
today - the ostree tooling knows how to verify the signature *inside*
the container image. In the future, we will also likely invest in
container-native signatures.
== Benefit to Fedora ==
* Stronger focus on Docker/OCI as transport for operating system and
applications
* New ability to easily create derived operating system images "server side"
* More benefit from e.g. work on container deltas
== Scope ==
* Proposal owners: Lots of detailed items listed in the rpm-ostree/CoreOS docs.
* Other developers: The "other" here is vague, but certainly
developing this so far has needed cooperation with e.g. the
containers/ organization etc.
* Release engineering: https://pagure.io/releng/issue/10399
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: No
== Upgrade/compatibility impact ==
Each individual edition/spin would need to choose when and how to make
a cutover to containers as a transport. The Fedora OSTree repository
would continue to be maintained until that is finished.
== How To Test ==
See the examples under https://coreos.github.io/rpm-ostree/container/
== User Experience ==
Users of rpm-ostree systems will primarily interact with container images.
== Dependencies ==
Release engineering.
== Contingency Plan ==
* Contingency mechanism: Continue to ship updates via baseline OSTree
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? No
== Documentation ==
Already linked above to avoid duplicating it here.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 1 month
Fedora 35 Cloud image && virt-sysprep
by Pavel Raiskup
Hello,
anyone had a successful experience with Fedora 35 Cloud images, and
guestfish/virt-sysprep?
Seems like we switched from ext4 or xfs to 'btrfs', and guestfish
doesn't work with the images, am I right? At least I had problems
on EL8 hypervisors so far.
Pavel
1 year, 1 month
Fedora EPEL 7 and enabling devtoolset
by David Sommerseth
Hi,
I'm starting to hit more and more challenges in the OpenVPN 3 Linux
project with the RHEL-7 GCC version (which is 4.8.5), especially when it
comes to C++ building. I've tried to keep the project compatible with
RHEL-7 as the oldest supported distro, but it is getting harder and
harder. In addition to newer C++ standards making the development of
the project easier.
I do see that RHEL/CentOS 7 has the needed compiler versions in the
devtoolset. I also stumbled across this blog post:
<https://smoogespace.blogspot.com/2018/03/using-red-hat-developer-toolset-...>
But ...
a) Is that blog post still relevant? I couldn't find anything in the
Fedora packaging guidelines giving any further advice.
b) By adding the devtoolset as a build dependency, is that enough?
Will the final .rpm need anything else installed to function? Like a
newer libstdc++?
c) Which other traps may I be facing using a devtoolset for EPEL-7 builds?
--
kin
d regards,
David Sommerseth
1 year, 1 month
packaging sourcegraph cli -- any volunteers?
by Matthew Miller
I've been talking with the awesome people at Sourcegraph, and they're
interested in indexing our packages. Still working out what that'l look like
exactly, but I'm pretty excited about it. (They're an open-source company
with a SaaS product. Also at least some of their folks run Fedora Linux, so
that's extra cool.)
In our conversation, they mentioned that it'd be nice to have their
command-line tool packaged. Anyone interested in taking that on? Looks
pretty straightforward, although I'm not sure of any Go lang pitfalls that
might await.
https://github.com/sourcegraph/src-cli
(Also, we already have a package named `src`, which is a apparently and RCS
(!!!!?!?!?!) wrapper. So we'll need to figure out a different comand name;
maybe src-cli, maybe 'sourcegraph', dunno.)
They'd also be interested in having the actual search engine tool itself
packaged (https://github.com/sourcegraph/sourcegraph) -- but that's a bigger
project. (Still, volunteers welcome!)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1 year, 1 month
java-17-openjdk mass-rebuild for f36 in copr I
by Jiri Vanek
Hello fellow java package maintainers!
We are planning to bump the JDK from java-11-openjdk to java-17-openjdk for f36. Please see https://fedoraproject.org/wiki/Changes/Java17
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 mass rebuild is launched
** See https://fedoraproject.org/wiki/Changes/Java17#copr_preliminary_rebuild
* If you do not want Fedora rotten 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 :
497 total; attempted to rebuild
107 failed; from those 75 are trivial failures (but if you fix it, there is no guarantee real troubles are not hidden behind that)
390 succeeded
2 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 yo 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 107 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.
1 year, 1 month
Trying to take an orphaned package
by Stephen Snow
Hello,
So I am back here to ask again if I can take a package on that is
currently orphaned as per
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedora...
And I login with my FAS ID and cannot "Take" the package since I am not
a packager.
So I ask again what steps am I missing here? I want to take over
packaging something that is about to be removed from Fedora Linux since
it has been orphaned, I have signed the agreements, I have asked to
become a packager, and this is actually the second package I am trying
to take over.
The package I am interested in taking/sharing maintaining with is
https://src.fedoraproject.org/rpms/Java-WebSocket
I think it is likely a maven plugin issue just looking at the root log.
Thoughts?
Regards,
Stephen
1 year, 1 month
Onboarding package
by Vít Ondruch
Hi,
Recently, there have been a lot of discussions on this list as well as
we have internally about onboarding. During our internal brainstorming,
we were initially discussing that it could be useful to have some
package one can experiment with without being too much worried about the
result.
However, discussing this back and forth, we figured that it might also
be good idea to actually have something such as "onboarding" package,
where new coming package maintainer could gradually gain experience with
the packaging workflows. So the simplest tasks could be:
1) Add changelog entry into onboarding package and open PR with the
change. This would not require too many privileges. Alternatively this
could include change to "CONTRIBUTORS" file. I suspect that also some
current Fedora contributors might be interested to send such PR ;)
2) Second step could be something similar, but that would require the
packager to be already sponsored and they could go through the whole
process themeselves just with some light guidance if needed.
This could be extended in the future. E.g. next step could be:
3) Submit module update.
Apart from gaining experience, this could also help with the common
question "where should I start". And of course our sponsoring guidelines
could be refreshed suggesting/requesting to take these steps at some point.
Thoughts?
Vít
1 year, 1 month
