Hi,
I'm tripping over an "Invalid license" error with some python
packages...
[ 57s] python-backports.csv.src: E: invalid-license (Badness: 100000)
PSF-2.0
[ 57s] python2-backports.csv.noarch: E: invalid-license (Badness:
100000) PSF-2.0
[ 57s] python3-backports.csv.noarch: E: invalid-license (Badness:
100000) PSF-2.0
[ 57s] The specified license string is not recognized. Please refer to
[ 57s] https://spdx.org/licenses/ for the list of known licenses and
their exact
[ 57s] spelling.
The thing is, "PSF-2.0" is in fact listed in that list of valid
licenses.
What can I do?
Cheers
MH
--
Mathias Homann
Mathias.Homann(a)openSUSE.org
telegram: https://telegram.me/lemmy98
irc: [lemmy] on freenode and ircnet
obs: lemmy04
gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
Guys,
Red Hat just announced a program where open source projects can get RHEL
subscriptions for free - wouldn't that be a good idea for the build
service?
Announcement here:
https://www.redhat.com/en/blog/extending-no-cost-red-hat-enterprise-linux-o…
Cheers
Mathias
--
Mathias Homann
Mathias.Homann(a)openSUSE.org
telegram: https://telegram.me/lemmy98
irc: [lemmy] on freenode and ircnet
obs: lemmy04
gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
Hi,
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
Hello,
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:
python-pyqt-builder
python-pyqt-rpm-macros
python-qt3d-qt5
python-qt5
python-qt5-sip
python-qtcharts-qt5
python-qtdatavis3d-qt5
python-qtwebengine-qt5
python-sip
python-sip4
qscintilla-qt5
## 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[56] but closely related or the "competitor":
python-PySide6
python-PySide2 (currently python3-pyside2)
python-QtAwesome
python-QtPy
python-poppler-qt5
qutebrowser
eric
...
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!
Ben
Hello,
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?
Regards
Daniel
--
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
Hi,
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
sufficient?
How can I make sure that all dependencies are detected? From a first test I
found at least one that is not fulflled....
Cheers
Axel
Hi *,
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?
Reproducer:
$ 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
Build error:
https://build.opensuse.org/package/show/home:berny:leap153/coreutils.openSU…
[ 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[2]: *** [Makefile:9139: lib/freadahead.o] Error 1
The glibc change requires this gnulib patch:
https://git.sv.gnu.org/cgit/gnulib.git/commit/?id=4af4a4a71827
Have a nice day,
Berny
Hi all,
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!
Hello, the proper way to set a prefix for qmake install is through PREFIX=%{prefix}, right?
If that is the case, is there a reason why it is not included in the %qmake5_install macro?