The following packages, previously owned by xgl-maint, are now up for grabs:
xorg-x11-xfs
xorg-sgml-doctools
xorg-x11-drv-v4l
xorg-x11-xsm
xorg-x11-twm
xorg-x11-drv-sisusb
xorg-x11-xdm
xorg-x11-docs
Upstream development on all of these is pretty much nil, so if you're
serious about picking up any of these you may also wish to take on the
module upstream:
https://gitlab.freedesktop.org/xorg
- ajax
Long story short I lost my home directory where I do all of my packager
activities (separate from my main user) so I'm setting things up from
scratch.
I created new ssh keys and uploaded the public key to
admin.fedoraproject.org and pasted into pagure.io. It's been over an hour
and I'm still getting:
$ fedpkg clone hamlib
Cloning into 'hamlib'...
hobbes1069(a)pkgs.fedoraproject.org: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Could not execute clone: Failed to execute command.
I've also updated my API tokens, which is STILL not well documented. I
pasted them in the appropriate spot in "/etc/rpkg/fedpkg.conf" which isn't
real intuitive.
Thanks,
Richard
https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs
== Summary ==
java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk and
java-latest-openjdk packages will no longer build i686 subpackages
== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email: <jvanek(a)redhat.com>
* Product: java and java stack
* Responsible WG: java-sig (java and java-maint)(which no longer exists)
=== Expected schedule ===
* during march, drop i686 builds from all jdks in fedora rawhide
== Detailed Description ==
Fedora currently ships:
* java-1.8.0-openjdk (LTS)
* java-11-openjdk (LTS)
* java-17-openjdk (LTS)
* java-latest-openjdk (STS, jdk18).
All those builds on all architectures except jdk8, where arm32 with
jit is built by different package.
Unluckily, the i686 bit builds of jdk are rotten in upstream. The
recent breakage of i686 JIT just before branching nearly killed jdk17
as system jdk feature.
The rotting have main visibility with newer GCCs. If GCC bump, and it
does, it always triggers new issues in i686 JIT, and there is less and
less people to somehow workaround them. Unluckily, there is probably
no longer anyone willing to really fix them
== Benefit to Fedora ==
The i686 builds are rotten in usptream, and to patch them localy had
become pain. We may be introducing very bugy i686 jdk. Better then to
do so, we would rather not ship that at all.
This will untie hands of both JDK and GCC developers, who will no
longer need to dive into nasty legacy code.
== Scope ==
==== Change owners ====
* we will simiply stop building i686 pkg in rawhide
==== Other developers ====
* may notice the multilib i686 java missing.
* it is up to them to drop i686 builds or to povide workaround (if possible)
==== Other ====
* Release engineering: https://pagure.io/releng/issue/10686
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
* The upgrade on multilib systems will lead to autoremoval of i686 javastack
* which should be minimum - 99% of javastack is noarch
== How To Test ==
install i686 java will result to not packages found
== User Experience ==
User experience on multilib systems will be bad. Bad reasonable.
== Dependencies ==
There are is unknown number of multilib java consumers. I expect some
of them may rise voice, but that will have to handled one by one.
== Contingency Plan ==
* Contingency mechanism: return i686 packages
* Contingency date: (not provided)
== Documentation ==
Will be neded...
== Release Notes ==
None yet...
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
Hi there, folks.
Delve[0] (a Golang debugger) was retired due to the impossibility of
building a new version of delve for dependencies issues. I would like
to claim the package and fix the situation. I already have one of the
dependencies[1] in the works.
I already talked with the original maintainer (he's in cc) and he is OK with it.
Thanks.
[0] https://src.fedoraproject.org/rpms/delve
[1] https://src.fedoraproject.org/rpms/golang-starlark
It's in redhat-rpm-config-118-1.fc30.
If it causes any problems for you - let me know. In the meantime, you can
use `%undefine _ld_as_needed` to disable it.
Thanks for attention!
--
-Igor Gnatenko
Hello all,
I'm a contributor to the Wine project. To summarize the following mail,
Wine needs special versions of some of its normal dependencies, such as
libfreetype and libgnutls, built using the MinGW cross-compiler, and I'm
sending out a mail to major distributions in order to get some feedback
from our packagers on how these should be built and packaged.
For a long time Wine has built all of its Win32 libraries (DLLs and
EXEs) as ELF binaries. For various reasons related to application
compatibility, we have started building our binaries as PE instead,
using the MinGW cross-compiler. It is our intent to expand this to some
of our dependencies as well. The list of dependencies that we intend to
build using MinGW is not quite fixed yet, but we expect it to include
and be mostly limited to the following:
* libvkd3d
* libFAudio
* libgnutls
* zlib (currently included via manual source import)
* libmpg123
* libgsm
* libpng
* libjpeg-turbo
* libtiff
* libfreetype
* liblcms2
* jxrlib
and dependencies of the above packages (not including CRT dependencies,
which Wine provides).
There is currently some internal discussion about how these dependencies
should be built and linked. There are essentially three questions I see
that need to be resolved, and while these resolutions have a significant
impact on the Wine building and development process, they also have an
impact on distributions, and accordingly I'd like to get input from our
packagers to ensure that their considerations are accurately taken into
account.
(1) Should we build via source import, or link statically, or dynamically?
Static linking and source imports are dispreferred by Fedora [1] [2], as
by many distributions, on the grounds that they cause duplication of
libraries on disk and in memory, and make it harder to update the
libraries in question (see also question 2). They also make building and
bisecting harder.
Note however that if they are linked dynamically, we need to make sure
that we load our packages instead of MinGW builds of open-source
libraries with applications ship with. Accordingly we need each library
to be renamed, and to link to renamed dependencies. For example, if
application X ships with its own copy of libfreetype-6.dll, we need to
make sure that our gdi32.dll links to libwinefreetype-6.dll instead, and
that libwinefreetype-6.dll links to libwineharfbuzz-0.dll and
winezlib.dll. I think, although I haven't completely verified yet, that
this can be done just with build scripts (i.e. no source patches), by
using e.g. --with-zlib=/path/to/winezlib.dll.
Accordingly, although static linking and source imports are generally
disprefered, it may quite likely be preferable in our case. We don't get
the benefits of on-disk deduplication, since Wine is essentially the
only piece of software which needs these libraries.
(2) If we use dynamic libraries, should dependencies be included in the
main wine package, or packaged separately?
This is mostly a question for packagers, although it also relates to (3).
I expect that Fedora (and most distributions) want to answer "packaged
separately" here, on the grounds that this lets them update (say) Wine's
libgnutls separately, and in sync with ELF libgnutls, if some security
fix is needed. There is a snag, though: we need libraries to be copied
into the prefix (there's some internal effort to allow using something
like symlinks instead, but this hard and not done yet). Normally we
perform this copy every time Wine is updated, but if Wine and its
dependencies aren't updated on the same schedule, we may end up loading
an old version of a dependency in the prefix, thus missing the point of
the update.
(3) If dependencies are packaged separately, should Wine build them as
part of its build tree (e.g. using submodules), or find and link
(statically or dynamically) to existing binaries?
Linking to existing binaries is generally preferable: it avoids
duplication on disk; it reduces compile times when compiling a single
package from source (especially the first time). However, we aren't
going to benefit from on-disk duplication. And, most importantly, unlike
with ELF dependencies, there is no standardized way to locate MinGW
libraries—especially if it comes to Wine-specific libraries. We would
need a way for Wine's configure script to find these packages—and
ideally find them automatically, or else fall back to a submodule-based
approach.
If we rely on distributions to provide our dependencies, the best idea I
have here would be something like a x86_64-w64-mingw32-pkg-config. And
if we use shared libraries rather than static, things get worse: we need
to know the exact path of each library and its dependencies so that we
can copy (or symlink) them into a user's WINEPREFIX.
For what it's worth, the current proposed solution (which has the
support of the Wine maintainer) involves source imports and submodules.
There's probably room for changing our approach even after things are
committed, but I'd still like to get early feedback from distributions,
and make sure that their interests are accurately represented, before we
commit. In short, it's not clear whether distributions want their
no-static-library policies to apply to us as well, or whether we're
enough of a special case and would be enough of a pain to package that
they'd rather we deal with the hard parts, and I don't want us to make
any assumptions.
ἔρρωσθε,
Zebediah
[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static…
[2] https://fedoraproject.org/wiki/Bundled_Libraries
Hello,
during the Fedora 34 development cycle a year ago, I've reported the following
buzgillas about packages that don't install:
https://bugzilla.redhat.com/buglist.cgi?bug_status=ASSIGNED&f1=blocked&f2=b…
They were set to ASSIGNED by their maintainers but since then, they still don't
install on Fedora 34, Fedora 35 or Fedora 36.
I see no point in keeping such packages in the repositories, yet the policy
does not currently allow to do anything other than keep them.
Should I take some steps, or do we keep building and shipping the broken
packages forever?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
Hello,
I have created two PRs against minizip which are yet to be merged:
- https://src.fedoraproject.org/rpms/minizip/pull-request/3
- https://src.fedoraproject.org/rpms/minizip/pull-request/4
The first one should be a low risk one and should allow pkg-config using
dependencies like (shameless self-interest plug) to build against system
minizip again.
The second one needs support from a provenpackager. I tried rebuilding
the 18 dependencies of minizip and this is a bit tricky for two reasons:
- libsmbl and libspatialite need to be rebuilt before the other dependencies
- I cannot figure out how to get fedpkg srpm to work with libspatialite,
I am getting a Package already exists: %package debuginfo error from the
%{?mingw_debug_package} line. I am sure this is something someone
familiar with mingw can fix in a shortest amount of time.
Other than that, I can confirm that 13 dependencies can be rebuilt with
no changes. How can we move this forward?
Best regards,
Julian