I've just faced an interesting issue.
As anybody knows, openSUSE Leap 15.3 partially inherits ready binary
packages from SUSE Linux Enterprise, and partially has its own packages
building from sources at OBS. This bundle is called openSUSE Leap 15.3
distro, and both binary rpms and source rpms (
http://download.opensuse.org/source/distribution/leap/15.3/ is empty now,
but I suppose something eventually will appear here) are provided to end
users. Lots was discussed about it.
Now, let me please introduce the following simple experiment.
Create an empty OBS subproject and assign openSUSE:Leap:15.3/standard as a
repo to it.
Then link e2fsprogs package from openSUSE:Leap:15.3 to your new empty home
osc linkpac openSUSE:Leap:15.3 e2fsprogs home:matwey:x
In other words, let's just rebuild e2fsprogs from Leap 15.3 against Leap
15.3. There is a little sense to do this because we expect that the result
will be the same.
So, wait for rebuilding and... see the error. I left a link to my version
of the log:
[ 52s] autoreconf: configure.ac: AM_GNU_GETTEXT is used, but not
[ 52s] ERROR: Use of AM_GNU_GETTEXT without [external] argument is no
[ 52s] configure.ac:857: warning: AM_INTL_SUBDIR is m4_require'd but not
[ 52s] aclocal.m4:69: AM_GNU_GETTEXT is expanded from...
[ 52s] configure.ac:857: the top level
[ 53s] configure:6517: error: possibly undefined macro: AM_INTL_SUBDIR
[ 53s] If this token and others are legitimate, please use
[ 53s] See the Autoconf documentation.
[ 53s] autoreconf: /usr/bin/autoconf failed with exit status: 1
[ 53s] error: Bad exit status from /var/tmp/rpm-tmp.eU0KwE (%build)
So, now we have a binary package (e2fsprogs) and sources for it, and we
cannot rebuild the binary from the sources. The reason is that gettext 0.20
is currently supplied by openSUSE:Leap:15.3, but at some point in the SLE's
past it was 0.19. And I bet that e2fsprogs was built against gettext 0.19
when the AM_GNU_GETTEXT macro worked without an error. But it came from SLE
and we don't have the build logs (or have we?)
However, the only we can see as a Leap 15.3 is a 'snapshot' of packages. So
I expect the same behaviour when some end user will obtain the srpm for
e2fsprogs and will try to rebuild it on his/her own box. Unfortunately, I
don't know if e2fsprogs is a single one such case.
This kind of inconsistency has a negative impact on having ports for
non-SLE architectures (like armv7l), complicates end-user impact on
debugging and modifying(?) stuff, and smells not quite well when we are
talking about 'open source principles'.
So, my question is how to avoid such issues and eventually have
self-consistent Leap 15.3.
With best regards,
Matwey V. Kornilov
I have submitted a new fonts package called iosevka-fonts. It's a very comprehensive open source font that
I would like to see included in the distro by default. I am not very experienced with packaging so there's
probably a lot of room for improvement. Let me know if that's the case.
GitHub repo: https://github.com/be5invis/Iosevka
Submit request: https://build.opensuse.org/request/show/867404
Lukas Kucharczyk — Technical Writer, SUSE Linux s.r.o.
Corso II, Křižíkova 148/34, 186-00 Praha 8 — Karlín, Czech Republic
Email: lukas.kucharczyk(a)suse.com - Office telephone: +420 284 084 000
quick question: I know Leap 15.1 has basically reached EOL, but
CVE-2021-3156 looks IMHO severe enough to justify fixing it still.
Is this currently being considered by the community / SUSE (or has it
been done and I simply overlooked it)?
I just ran the last / latest updates against a 15.1 system and it
appears to be still vulnerable. I can built packages with the fix myself
if needed, but an official update for this one could make a massive
difference. I can only guess how many people are still behind (like me
...) with updating to 15.2.
Dear Package maintainers and hackers.
Below package(s) in openSUSE:Factory have been failing to build for at
least 4 weeks. We tried to send out notifications to the
configured bugowner/maintainers of the package(s), but so far no
fix has been submitted. This probably means that the
maintainer/bugowner did not yet find the time to look into the
matter and he/she would certainly appreciate help to get this
Unless somebody is stepping up and submitting fixes, the listed
package(s) are going to be removed from openSUSE:Factory.
DimStar / Dominique Leuenberger <dimstar(a)opensuse.org>
I did purchase the HP Desktop 2720, an all-in-one printer/scanner/copier, for
which I found a solution for a proper printer driver. However I was unable to
install the driver for the scanner. This one is present in the newest version
of hplip, however I was unable to build that package for openSUSE.
Is it possible to have this newer version supported in openSUSE? I mainly do
my work in Tumbleweed.
Freek de Kruijf
2021 is here with a lot of interesting news, and YaST development is not
an exception. During the first sprint of the year we have worked on:
- Writing NetworkManager configuration during system installation
- Refining the mechanism to reuse existing EFI partitions
- Using better names to reference devices in the boot loader
- Improving AutoYaST behavior when no product has been specified
- Updating the roles offered by yast2-vm
- Many more small improvements here and there
Check the whole report at:
Ancor González Sosa
YaST Team at SUSE Linux GmbH
what is the status of package submissions to Leap 15.3
I see some SR in the queue for nearly 3 weeks now. Any reason why they are
building, but are not accepted?
With the release of bind 9.16.11 we will no longer distribute the
but will instead use systemd's restrictions to keep bind at bay.
The (main) bind package will obsolete bind-chrootenv.