I'm tripping over an "Invalid license" error with some python
[ 57s] python-backports.csv.src: E: invalid-license (Badness: 100000)
[ 57s] python2-backports.csv.noarch: E: invalid-license (Badness:
[ 57s] python3-backports.csv.noarch: E: invalid-license (Badness:
[ 57s] The specified license string is not recognized. Please refer to
[ 57s] https://spdx.org/licenses/ for the list of known licenses and
[ 57s] spelling.
The thing is, "PSF-2.0" is in fact listed in that list of valid
What can I do?
irc: [lemmy] on freenode and ircnet
gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
I would like to package influxdb2: https://github.com/influxdata/influxdb
that is the next major version for server:database/influxdb
Probably, they will coexist for some time, but it doesn't matter currently.
I've found that influxdb2 is provided with a built in WebUI interface based
on nodejs(?) and it requires about 2000 packages from npm to be built. Even
though I can do it manually, there is no internet connection in OBS. I have
not found any info on the wifi how to overcome this issue. Probably I need
to preferetch these sources from npm and put them as a tarball.
With best regards,
Matwey V. Kornilov
python-sip, python-qt5 and co. have always been kind of a foreign body
to C++ focused KDE:Qt5. May I propose to create
devel:languages:python:pyqt and put related packages into that one?
Maintainers could be python and QT/KDE people together.
## List of existing packages to be considered:
## New packages to be created (using the PyPI names as naming template
instead of continuing the legacy rpm package names. Of course
appropriate `Provides:` tags for the rpm names should be included):
python-PyQt6 (also providing python-qt6)
python-PyQt6-sip (also providing python-qt6-sip)
python-PyQt6-3D (also providing python-qt3d-qt6)
python-PyQt6-NetworkAuth (also providing python-networkauth-qt6)
python-sip6 (see below)
... and more of the family as they are released upstream.
## Not PyQt but closely related or the "competitor":
python-PySide2 (currently python3-pyside2)
There is also SIP v6 now. Some packages still depend on SIP v4 (e.g.
cura libraries) or use the legacy features of SIP v5 (e.g. the sip5
executable), so we can't just have a single up to date python-sip. After
some discussion with DimStar a few days ago, I propose, what I call the
"tornado approach", because it is what python-tornado is doing right now:
* Have python-sip4, python-sip5, python-sip6, all providing python-sip
* Make python-sip a meta package and have it require the currently
preferred default (python-sip5 at the moment).
* Have the appropriate `Prefer:` tags in prjconf.
Thoughts and comments welcome!
we sign our packages with our own keys.
What is the best way to deliver this keys? I tried it like opensuse does
it with their opensuse-build-key RPM package.
The keys are placed on /usr/lib/rpm/gnupg/keys (as the opensuse package
does), but they are not recognized by rpm.
How do I import them correct?
Daniel Spannbauer Systemadministration
marco Systemanalyse und Entwicklung GmbH Tel +49 8333 9233-27 Fax -11
Rechbergstr. 4-6, D 87727 Babenhausen Mobil +49 171 4033220
http://www.marco.de/ Email ds(a)marco.de
Geschäftsführer Martin Reuter HRB 171775 Amtsgericht München
I'm not sure how this dependency generator sets dependencies for subpackages.
I have a package FOO with a subpackage FOO-Special
FOO-Special adds some functionality and requires some additional pacakges,
that most users of FOO will not need.
So it would be a waste of resources if all the additional packages from FOO-
Special would be installed with FOO as well.
So do I need to call the macro in each sub-package, or is a single call
How can I make sure that all dependencies are detected? From a first test I
found at least one that is not fulflled....
I'm wondering how it could be that a freshly branched maintenance project in Leap:15.3 fails to build?
It looks as if the coreutils package was once built and copied from SLE,
and then a newer glibs>=2.28 was installed in Leap:15.3 without triggering
a rebuild of coreutils.
Is this true? Why?
Shouldn't have a new build cycle been started when updating glibc?
$ osc branch -M openSUSE:Leap:15.3:Update coreutils home:berny:leap153/coreutils
$ osc co home:berny:leap153/coreutils.openSUSE_Leap_15.3_Update
$ cd home:berny:leap153/coreutils.openSUSE_Leap_15.3_Update
$ osc build --noverify coreutils.spec
FWIW: I needed the --noverify because of this:
/var/tmp/osbuild-packagecache/openSUSE:Backports:SLE-15-SP3/standard/x86_64/libpopt0-1.16-bp153.1.14.x86_64.rpm : public key not available
/var/tmp/osbuild-packagecache/openSUSE:Backports:SLE-15-SP3/standard/noarch/rpmlint-Factory-1.0-bp153.2.6.noarch.rpm : public key not available
/var/tmp/osbuild-packagecache/openSUSE:Backports:SLE-15-SP3/standard/noarch/rpmlint-Factory-strict-1.0-bp153.2.6.noarch.rpm : public key not available
[ 158s] gcc -I. -I./lib -Ilib -I./lib -Isrc -I./src -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables
-fstack-clash-protection -g -c -o lib/fseeko.o lib/fseeko.c
[ 158s] lib/freadahead.c: In function 'freadahead':
[ 158s] lib/freadahead.c:97:3: error: #error "Please port gnulib freadahead.c to your platform! Look at the definition of fflush, fread, ungetc on your system, then report this to bug-gnulib."
[ 158s] #error "Please port gnulib freadahead.c to your platform! Look at the definition of fflush, fread, ungetc on your system, then report this to bug-gnulib."
[ 158s] ^~~~~
[ 158s] lib/freadahead.c:99:1: warning: control reaches end of non-void function [-Wreturn-type]
[ 158s] }
[ 158s] ^
[ 158s] make: *** [Makefile:9139: lib/freadahead.o] Error 1
The glibc change requires this gnulib patch:
Have a nice day,
some days ago I got aware of the OpenBoard package, which is built in the openSUSE Education project. As my wife is a teacher, she was very happy that this was available for openSUSE Leap 15.2. I then wanted to switch from the latest release evrsion 1.5.4 to the current release candidate of 1.6.1. Additionally, I created a new tool to draw a coordinate system on the board. This is available in a fork on github at https://github.com/letsfindaway/OpenBoard.
To package this work, I did the following:
- I did an osc copypac to copy the Education:OpenBoard package to my home project at home:letsfindaway.
- I updated the source with the zip archive downloaded from my project at github.
- I updated one of the patches and removed two others, which have been upstreamed since 1.5.4.
This works well, but I have a few questions:
1. Is copypac the right way?
Is copypac the right way to create an own package which is quite similar to an existing one? How close is the binding to the original package after copypack? Are they independent or will the copy inherit any modifications to the original?
2. Best way to add own modifications
First I thought I could just use the source zip from the original OpenBoard repository and add my modifications as a patch. However as my work contains a new image file in png format, I did not find a good way to put this file in a patch. Are there any recommendations how to do this? What about multiple Source specifiers in the spec file? Would they be approriate? How are they handled?
3. Version specification for such derived work
Currently I'm just using 1.6.1 as the version specifier, which does not indicate that the package contains additional work. What would be the best way to express this in a version number?
Finally I just want to thank the openSUSE people for providing such an awesome service as the OBS for such anybody!