Hi,
It's a rarely case, but I need the link /usr/lib/libboost_filesystem.so
-> /usr/lib/libboost_filesystem.so.1.76.0
for building 32bit-64bit version of yabridge
https://github.com/robbert-vdh/yabridge
keep an own branch of boost scares me a bit
maybe there is a some trick where I can make a stump package with that
link?
Hi,
I noticed that the devel package is broken for python-flask-jwt-
extended [1]. It seems like the link is invalid. Any ideas on how to
get this fixed so the package starts building again in devel and also
in factory?
[1]
https://build.opensuse.org/package/show/devel:languages:python:flask/python…
Thanks,
Sean
Hi,
The suse-module-tools package ships a couple of (default) configuration
files that are currently installed under /etc/modprobe.d. I want to
migrate them to /lib/modprobe.d (to be further migrated to /usr/lib
when the usr merge happens).
These files were meant to be user-modifyable, and were labelled with
%config(noreplace) for that reason.
How should I deal with modified files? The files under /etc aren't
owned by the new package any more, as it now owns the corresponding
files under /lib only. In the upgrade process, when the old version is
uninstalled, rpm will notice the %config(noreplace) files being
removed, and will rename them to .rpmsave. That's bad, because user
modifications won't be applied any more. The system may fail to boot or
otherwise misbehave. rpm will log these renames:
warning: /etc/modprobe.d/60-blacklist_fs-nilfs2.conf saved as /etc/modprobe.d/60-blacklist_fs-nilfs2.conf.rpmsave
but these messages might be easily overlooked, in particular if the
user works with packagekit or the like.
I've considered to detect these ".conf.rpmsave" files in a %posttrans
script and rename them back to ".conf". That would work AFAICS, but I'm
not sure if I can exclude weird side effects; in particular, I must
take care not to restore previously created .rpmsave files, and I
should only do this once, when upgrading from a previous version that
still owned the files under /etc (I don't know how to detect that). In
general, this approach feels pretty much like a hack.
Another option I've tried is to add the /etc/modprobe.d/ files to the
new package as %ghost files. That "works", too, the files aren't
renamed to .rpmsave any more, and no immediate damage is done. The
drawback is that every conf file is preserved, even those that were
unchanged by the user (the "normal" case being that the user didn't
modify any of these files). Thus my newly installed files under /lib
wouldn't take effect. Future changes of the default configuration would
be silently masked.
What would be the preferred approach? Or is there another, better
solution that I am overlooking?
Hints welcome,
Martin
Hi,
I have a package in factory python3-img-proof which got new
requirements on Aliyun SDK packages. Since the requirements were added
the package (img-proof) fails to update in factory due to unresolvables
[1].
I submitted the Aliyun SDK core package to factory but it fails because
devel:languages:python:aliyun [2] is not a devel project of factory
[3]. Can someone help get d:l:p:aliyun added as a devel project so
these SDK packages can be included in factory?
[1] https://build.opensuse.org/request/show/892113
[2]
https://build.opensuse.org/project/show/devel:languages:python:aliyun
[3] https://build.opensuse.org/request/show/895205
Thanks,
Sean
Hi guys,
I am having an extremely weird problem with two packages that I'm building.
I have been packaging the apps in question for years now, but now I'm trying
to get OBS to produce a working rpm on Tumbleweed and it just DOES NOT WORK.
The build on OBS succeeds just fine, but if I install the package the
application crashes on start.
The packages for Leap 15.2 and 15.3 built from the same spec and sources work
just fine, even to the point that right now I'm using the 15.3 package on
tumbleweed.
and here is the REALLY weird part:
If I take the whole content of the package directory from my obs project and
copy it to rpmbuild/SOURCES on a Tumbleweed machine,. and build it locally
with rpmbuild, the package I get works just fine.
If I build locally with "obs build" the resulting binary crashes.
I have NO idea where to begin looking - all I know right now is that a
backtrace in gdb wasn't really helpful either... the crash happens somewhere
in libstdc++ o.0
Anyone got any ideas? the packages in question are in home:lemmy04:snowglobe/
phoenix-firestorm-lgpl and home:lemmy04:phoenix-firestorm-release ...
Cheers
MH
--
Mathias Homann
Mathias.Homann(a)openSUSE.org
OBS: lemmy04
Jabber (XMPP): lemmy(a)tuxonline.tech
IRC: [Lemmy] on freenode and ircnet (bouncer active)
telegram: https://telegram.me/lemmy98
keybase: https://keybase.io/lemmy
gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
Hi,
with the pending submission of Dracut 054, which removes mkinitrd from
the upstream sources, it's time to finally remove mkinitrd in Factory, too:
Changes starting with 054
-------------------------
- mkinitrd will temporarily live in its own dracut-mkinitrd-deprecated
package. It will still be installed when requiring "mkinitrd" and
requires dracut, so nothing changes here.
- If you only required dracut, but meant to require mkinitrd, you need
to change this temporarily or change your scripts to directly call dracut.
Rationale
---------
mkinitrd has always been a rather mediocre wrapper that claimed to keep
compatibility with the SLES 11 implementation. However:
- it has a lot of bugs, quite some documented (!) flags have never
worked, others are marked unimplemented or will say so only if invoked.
I see little point in doing that given
- it adds little value over just using plain Dracut
Differences in calling dracut over calling mkinitrd:
----------------------------------------------------
- Dracut only updates the initrd for the currently running kernel,
unless either a kernel version or --regenerate-all is called
- mkinitrd updates the bootloader by default. Dracut has no such option.
Then again, those are two different concerns that are only merged into a
single command for convenience. Usually this should be invoked from the
kernel install script.
- mkinitrd parses the no longer existing /etc/sysconfig/kernel file.
- mkinitrd handles xen-specific modules. I have not enough understanding
of the state of Xen in Factory to judge whether this is still required.
If so, it should be handled in a dracut module. However, judging by the
fact that the default is sourced from the defunc'ed kernel sysconfig
file, this is probably also dead.
- mkinitrd has slightly different semantics on how to specify a boot
device for NFS & Co.
Point of Contact
----------------
If you have concerns how this affects your package, please let us (me,
Thomas Blume or Neil) know. For the Kernel and other packages that are
definitely impacted once mkinitrd would go away (e.g. YaST), we will
reach out separately and / or file bugzilla issues.
--
Daniel Molkentin <daniel.molkentin(a)suse.com>
Senior Software Engineeer
System Boot and Init
SUSE Software Solutions Germany GmbH
Maxfeldstrasse 5, 90409 Nuernberg, Germany
HRB 36809 (AG Nürnberg)
Geschäftsführer: Felix Imendörffer
I try to package a multi-python application and I got the build working
so far, but when adding a desktop file I get this rpmlint problems:
[ 42s] warning: absolute symlink: /usr/bin/NanoVNASaver ->
/etc/alternatives/NanoVNASaver
[ 42s] warning: absolute symlink:
/usr/share/applications/nanovna-saver.desktop ->
/etc/alternatives/nanovna-saver.desktop
[ 42s] warning: absolute symlink: /usr/share/pixmaps/nanovna-saver.png
-> /etc/alternatives/nanovna-saver.png
[ 43s] error: lua script failed: [string "<lua>"]:4: cannot open file
'/home/abuild/rpmbuild/BUILDROOT/nanovna-saver-0.3.8-2.1.x86_64/usr/share/applications/nanovna-saver.desktop'
(No such file or directory)
and finally:
[ 46s] RPMLINT report:
[ 46s] ===============
[ 47s]
/tmp/rpmlint.python39-nanovna-saver-0.3.8-2.1.noarch.rpm.jgk388ja/usr/share/applications/nanovna-saver.desktop:
file does not exist
[ 47s] 0 packages and 0 specfiles checked; 0 errors, 3 warnings.
[ 47s] Traceback (most recent call last):
[ 47s] File "rpmlint.py", line 378, in <module>
[ 47s] File "rpmlint.py", line 166, in main
[ 47s] File "rpmlint.py", line 224, in runChecks
[ 47s] File "AbstractCheck.py", line 51, in check
[ 47s] File "AbstractCheck.py", line 101, in check_binary
[ 47s] File "MenuXDGCheck.py", line 92, in check_file
[ 47s] File "MenuXDGCheck.py", line 34, in parse_desktop_file
[ 47s] File "./codecs.py", line 905, in open
[ 47s] FileNotFoundError: [Errno 2] No such file or directory:
'/tmp/rpmlint.python39-nanovna-saver-0.3.8-2.1.noarch.rpm.jgk388ja/usr/share/applications/nanovna-saver.desktop'
The package is built here:
https://build.opensuse.org/package/show/home:frank_kunz/nanovna-saver
I used this package as example
https://build.opensuse.org/package/show/openSUSE:Factory/python-Twisted
since this has man pages handled by python_alternative and my idea was
to do it the same for a desktop file. I'm not sure if python_alternative
is the right way to go for desktop files, or if there is an other
possibility. The python packaging
wiki(https://en.opensuse.org/openSUSE:Packaging_Python) does not list
that. How can I fix that problem, or, if any, what is the better way to
package the desktop file?
Br,
Frank
X11:lxde/mtpaint is broken, because it's linked to openSUSE:Factory, but
it was removed from there. It's still possible to see original files
under "Show unmerged sources" link in web ui.
If I try to branch it, I get an error:
BuildService API error: failed to branch: openSUSE:Factory/mtpaint:
package 'mtpaint' does not exist
Is it possible to branch it in a way that would give me unmerged sources?
