Golang SIG primary goals?
by Robert-André Mauchin
Hey guys and gals,
Can we start to discuss this SIG goals? What each of you are expecting?
A few ideas:
- Making https://fedoraproject.org/wiki/More_Go_packaging official and
working on bringing them to EPEL7
- Assigning current Go packages to the SIG so each member of the SIG can work
on them, similar to https://src.fedoraproject.org/group/rust-sig
Many Google packages are inter-dependent, this would ease synchronising them.
- Working toward packaging more: I'm thinking about unbundling kubernetes and
docker.
- Developing tools to maintain up-to-date our current set of Go packages,
some of which are left outdated since their creation.
Any other ideas? I'd like to move forward as soon as possible.
Best regards,
Robert-André
2 years, 6 months
Rawhide python3-devel conflict issue
by BJH2017
Hi,
I build Vim (bleeding-edge package, updated within a day of the latest
upstream release) for Fedora Rawhide, among many other platforms,
using the openSUSE Build Service and the delightful issue I've found
is that python3-devel cannot be installed by the OBS due to a conflict
between python3-rpm-generators and python-rpm-macros. If you suggest I
should ask the OBS developers for help on this don't bother because
I've asked them and they've told me this is an upstream issue you
folks need to fix. This issue has existed for over a week now, so it'd
be delightful if it could be fixed.
Thanks for your time and patience,
Brenton
2 years, 6 months
Heads-up: ImageMagick SONAME bump
by Michael Cronenworth
ImageMagick 6.9.9 => 6.9.10 introduces a SONAME bump from .so.5 to .so.6. I'll
rebuild what I can, but please help out if you have some spare cycles. Owners have
been BCC'd.
dnf repoquery --whatrequires libMagickCore-6.Q16.so.5\(\)\(64bit\) --releasever=30:
WINGs-libs-0:0.95.8-10.fc29.x86_64
WindowMaker-0:0.95.8-10.fc29.x86_64
autotrace-0:0.31.1-52.fc29.x86_64
chafa-0:0.9.0-1.fc29.x86_64
converseen-0:0.9.6.2-9.fc29.x86_64
dmtx-utils-0:0.7.6-2.fc29.x86_64
drawtiming-0:0.7.1-28.fc29.x86_64
emacs-1:26.1-6.fc29.x86_64
emacs-lucid-1:26.1-6.fc29.x86_64
gtatool-imagemagick-0:2.2.0-11.fc28.x86_64
imageinfo-0:0.05-31.fc29.x86_64
inkscape-0:0.92.3-5.fc29.x86_64
inkscape-view-0:0.92.3-5.fc29.x86_64
kxstitch-0:2.0.0-4.fc28.x86_64
perl-Image-SubImageFind-0:0.03-17.fc29.x86_64
pfstools-0:2.0.6-8.fc29.x86_64
pfstools-imgmagick-0:2.0.6-8.fc29.x86_64
php-pecl-imagick-0:3.4.3-8.fc29.x86_64
psiconv-0:0.9.8-25.fc28.x86_64
python2-vips-0:8.6.5-2.fc29.x86_64
q-magick-0:7.11-33.fc29.x86_64
ripright-0:0.11-10.fc29.x86_64
rss-glx-0:0.9.1.p-35.fc29.x86_64
rubygem-rmagick-0:2.16.0-16.fc29.x86_64
synfig-0:1.2.1-3.fc28.x86_64
synfigstudio-0:1.2.1-3.fc28.x86_64
vdr-scraper2vdr-0:1.0.9-4.20180104gitef448e1.fc29.x86_64
vips-0:8.6.5-2.fc29.x86_64
vips-tools-0:8.6.5-2.fc29.x86_64
Thanks,
Michael
2 years, 6 months
Heads-up: ImageMagick SONAME bump
by Michael Cronenworth
ImageMagick 6.9.9 => 6.9.10 introduces a SONAME bump from .so.5 to .so.6. I'll
rebuild what I can, but please help out if you have some spare cycles.
dnf repoquery --whatrequires libMagickCore-6.Q16.so.5\(\)\(64bit\) --releasever=30:
WINGs-libs-0:0.95.8-10.fc29.x86_64
WindowMaker-0:0.95.8-10.fc29.x86_64
autotrace-0:0.31.1-52.fc29.x86_64
chafa-0:0.9.0-1.fc29.x86_64
converseen-0:0.9.6.2-9.fc29.x86_64
dmtx-utils-0:0.7.6-2.fc29.x86_64
drawtiming-0:0.7.1-28.fc29.x86_64
emacs-1:26.1-6.fc29.x86_64
emacs-lucid-1:26.1-6.fc29.x86_64
gtatool-imagemagick-0:2.2.0-11.fc28.x86_64
imageinfo-0:0.05-31.fc29.x86_64
inkscape-0:0.92.3-5.fc29.x86_64
inkscape-view-0:0.92.3-5.fc29.x86_64
kxstitch-0:2.0.0-4.fc28.x86_64
perl-Image-SubImageFind-0:0.03-17.fc29.x86_64
pfstools-0:2.0.6-8.fc29.x86_64
pfstools-imgmagick-0:2.0.6-8.fc29.x86_64
php-pecl-imagick-0:3.4.3-8.fc29.x86_64
psiconv-0:0.9.8-25.fc28.x86_64
python2-vips-0:8.6.5-2.fc29.x86_64
q-magick-0:7.11-33.fc29.x86_64
ripright-0:0.11-10.fc29.x86_64
rss-glx-0:0.9.1.p-35.fc29.x86_64
rubygem-rmagick-0:2.16.0-16.fc29.x86_64
synfig-0:1.2.1-3.fc28.x86_64
synfigstudio-0:1.2.1-3.fc28.x86_64
vdr-scraper2vdr-0:1.0.9-4.20180104gitef448e1.fc29.x86_64
vips-0:8.6.5-2.fc29.x86_64
vips-tools-0:8.6.5-2.fc29.x86_64
Thanks,
Michael
2 years, 6 months
Maintenance of arbitrary branches of orphaned package
by Mikolaj Izdebski
Suppose I am main admin of a package which I would like to orphan in
release branches, but keep maintaining the package in arbitrary [1]
branches, which are used for building modules. Would this considered
as a valid approach?
How should I handle orphaning the package in this case? I can think
of at least two possibilities:
1. Keep myself as admin and set bugzilla_contact for product Fedora to
orphan.
2. Set orphan as main admin and demote myself to just admin.
In case no one adopts orphaned package and it is retired by Release
Engineering, should commiters be still able to commit to non-retired
arbitrary branches? I assume yes, but I'd rather ask in advance.
[1] https://fedoraproject.org/wiki/Changes/ArbitraryBranching
--
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
2 years, 6 months
RFC: Alternative -devel packaging
by Adam Jackson
Consider a library like libGL. At runtime, you want the drivers it
might load to be installed. But when building an application, you just
need the library itself. If the drivers themselves have non-trivial
dependencies, the buildroot is more likely to fail to compose.
The problem, in a sense, is that the devel package requires the package
providing the API library, _and_ said required package requires the
drivers. What if instead you had (in pseudo-spec):
%package devel
Requires: %{name}-sdk
%package sdk
%package libs
Requires: foo-drivers
where -libs and -sdk have identical %files, but -sdk has automatic
provides for library sonames turned off (so it never satisfies a
runtime dependency). This would duplicate some content on the mirrors,
but not the installed system, and it would let you compose a buildroot
with only the API surface you link against.
---
Is this all dodging the issue that nothing agrees what Recommends:
means? And that nobody's compose tools or comps files really understand
what drivers they want, and that propagating that information is an
unbounded task? Well, yeah, a bit. I still think it'd solve a real
problem, I'm just wondering if the idea is too ugly to consider.
- ajax
2 years, 6 months