Ruby upstream is implementing more and more stuff directly in Ruby. We
already had issues, that build of Ruby required Ruby when we did some
modifications . In subsequent ticket, one of Ruby committers said :
> ... snip ...
> BASERUBY is already a build requirement
> ... snip ...
> I would like to implement more of Ruby using Ruby, so miniruby may
depend on prelude one day.
With recent changes, such as , I am afraid that the day has come.
Previously, if you wanted to patch lets say "gem_prelude.rb", it was
enough to patch it. But now you *need* Ruby to process it into
miniprelude.c. There are possibly 4 ways out of this.
1) Build Ruby in two stages. a) build (mini)ruby, apply patches b) build
Ruby using the previously built (mini)ruby.
2) Use previous version of Ruby available in Fedora to bootstrap Ruby.
But this does not work ATM, at least when RubyGems are installed. And
upstream is doing what they can to make RubyGems inseparable .
3) Prepare patches locally and apply the required changes also to the
pregenerated files. But the problem here is, that the patches might
unpredictably fail between updates. I don't think that they keep any
API/ABI promises for the tools used to generate those files.
4) Don't use the upstream tarball, but generate it from sources with
I think we should probably start to take look at 1), specifically into
the *miniruby* variant if that is enough. If that is done, the 2) could
optionally blend in. And in the mean time use 3) because otherwise I
really don't know how to integrate the ABRT hook support. I don't like
4) at all, unless we have some Fedora standardized way of doing so.
On the positive side, 1(2) would allow us to stay better in line with
"Pregenerated code" guidelines , because there is already quite a lot
of pre-generated code shipped in Ruby release tarball.
On 07. 12. 19 11:53, Henrique Castro wrote:
> Pymol is a package that, integrated with python-rdkit and other python packages,
> makes the lives of people working with drug discovery (and chemistry in general
> too) much easier. Unfortunately, the package is broken and not even build into
> F31. The maintainer has not replied to a BZ ticket open months ago.
> At this point, the absence of the package is realy making an impact in science
> made with Fedora.
Unfortunately, pymol needs an active maintainer. Since it is retired, any Fedora
packager can request it to be unretired and become the owner of it.
So I again looked at https://fedorapeople.org/groups/schedule/f-32/f-32-key-tasks.html
and proposal submission deadline for changes requiring mass rebuild is due today
(2019/12/31). If I am correct we have not seen any proposal for gcc10 on Fedora 32 yet.
If "today" means 2019/12/31 0:00 UTC, it already passed and we don't see gcc10 on
-----BEGIN PGP SIGNED MESSAGE-----
I've been using Linux in one way or another since 2015, around the same
time I got into software development. I'm self-taught, though I'd like
to go to school eventually. I started out doing web development and
Linux system administration but nowadays I work as an Android
developer. I'm interested in moving to either OS development, embedded
software development, or infosec, though I'd be happy to pitch in
wherever help is needed. For 2020 I've decided I want to begin
contributing to a Linux distro on a regular basis as most of the open
source work I've done so far has been on new projects I've started
myself on Android and iOS. I think my time would be better spent giving
back to existing projects that I already use on a day-to-day basis, and
seeing as I prefer Fedora for my desktop, I figured this would be a
good place to start. I'm proficient in Java, Kotlin, Python, and C, so
I figured I'd find some packages that need help with maintenance to get
familiar with the community and build up from there. I'd appreciate any
suggestions or guidance and I look forward to getting to involved in
the community! I'll try to make a more conscious effort to hang around
#fedora and #fedora-devel on freenode.
GPG Key Fingerprint:
58BB 3566 6F8B D4F1 895E 5120 8FF1 2381 C6C9 0D35
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
Based on the latest fail to build from source policy, the following packages
will be retired from Fedora 32 approximately one week before branching (February
The packages in rawhide were not successfully built at least since Fedora 30.
This report is based on dist tags.
Packages collected via:
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me
know and we can work together to get a FESCo approval for that.
If you see a package that can be rebuilt, please do so.
Package (co)maintainers Latest build
elasticsearch hubbitus, jvanek, lbazan, Fedora 24
expresso jamielinux, nodejs-sig, Fedora 28
libocrdma ocrdma Fedora 27
nuvola-app-google-calendar martinkg Fedora 29
nuvola-app-groove martinkg Fedora 28
nuvola-app-logitech-media- martinkg Fedora 29
nuvola-app-plex martinkg Fedora 29
nuvola-app-soundcloud martinkg Fedora 29
nuvola-app-yandex-music martinkg Fedora 29
shim-unsigned-aarch64 pjones Fedora 28
shim-unsigned-x64 pjones Fedora 28
The following packages require above mentioned packages:
Depending on: expresso (1)
nodejs-chrono (maintained by: jamielinux, nodejs-sig, tomh)
nodejs-chrono-1.0.5-10.fc31.src requires npm(expresso) = 0.9.2
martinkg: nuvola-app-soundcloud, nuvola-app-logitech-media-server,
nuvola-app-yandex-music, nuvola-app-groove, nuvola-app-google-calendar,
pjones: shim-unsigned-aarch64, shim-unsigned-x64