January 2022 - openSUSE Packaging - openSUSE Mailing Lists

Re: /work/src/done/SLE15-SP4-STAGING/libstorage-ng not checked in
by Steffen Winterfeldt 13 Jan '22

13 Jan '22

On 13 Jan 2022, mrueckert wrote: > 2. set a proper email address in the service used for building the tarballs? > opensuse-packaging(a)opensuse.org - this should not be there Better suggestion for Weblate submissions? Steffen

1 0

Re: devel:languages:python:backports and enabled repositories
by Ben Greiner 10 Jan '22

10 Jan '22

Am 10.01.22 um 20:18 schrieb Dirk Müller: > On Montag, 10. Januar 2022 13:18:35 CET Ben Greiner wrote: > > Hi Ben, > >> See my initial post about an explanation why you see "deleted" entries >> in your projects. (I include :backports:fixups into the definition of >> "your"). TL;DR: An overeager user managed to get his wish granted that >> stuff got deleted. The restoration afterwards did not fix your now >> broken projects. > The :fixups is needed in devel:languages:python:backports to get it back to > building, not in "my" project. As mentioned by Axel, someone even added :fixups to the path in d:l:p now. I am not sure if that is a good idea for any of the use cases discussed in this thread. > > I have over 1000 unresolvables and over 200 failures now. > >> Also, as discussed in the thread, you probably want paths to the :Update >> repos either in your projects or in d:l:p:backports directly. > that causes rpmlint-backports to be included which wipes the binaries, not a > good idea. > > so I'm going over things and revert it into a working state. so the plan was > to delete SLE_15_SP3 repository and then to add 15.3, and instead 15.3 got > deleted? I think there was no real "plan", just some misguided user requests which were acted upon. When I called out the actors on it I only got childish reactions and harassment but no sign of thinking along. - 15.3 got deleted - openSUSE_Leap_15.3 got created - 15.3 got recreated - openSUSE_Leap_15.3 got deleted - SLE_15_SP3 got deleted Not necessarily in that order. In the end its irrelevant. All we want is a sane state. > Thanks, > Dirk > Thanks for fixing it up! It's always good to have someone look over it who actually uses the stuff. BTW, SLE_15_SP2 in d:l:p is still using :backports. Whichever route you want to go, please at least make it consistent or provide a good reason why it should be different. - Ben

1 0

Re: devel:languages:python:backports and enabled repositories
by Ben Greiner 10 Jan '22

10 Jan '22

Hi Dirk, Am 10.01.22 um 12:58 schrieb Dirk Müller: > On Montag, 10. Januar 2022 11:19:48 CET Simon Lees wrote: > >> In the past we have shipped similar updates to rpm-macros into the >> Update repo and not released them to customers then with the updates >> repo enabled they can still be used for builds. That is probably the >> best solution to this problem or we update the wiki to indicate these >> features don't exist in 15.3. > untili recently we used to have devel:languages:python:backports:fixups to > address python 3.6 issues in devel:languages:python:backports. > > I've been maintaining that for at least a year, if not two years, and kept > things building in devel:languages:python:backports for 15.3. > > coming back from a two day vacation, I notice that all my projects have been > deleted links, all the CI jobs have been red, and the project configuration has > been completely changed, and now hundreds to thousands of build failures. > > Is there any chance that I can get back a working setup please? what issue has > been tried to be solved with the changes and how can I get a state that works? See my initial post about an explanation why you see "deleted" entries in your projects. (I include :backports:fixups into the definition of "your"). TL;DR: An overeager user managed to get his wish granted that stuff got deleted. The restoration afterwards did not fix your now broken projects. You think can fix them by adjusting your meta configuration to <repository name="15.3"> <path project="devel:languages:python:backports" repository="15.3"/> <arch>x86_64</arch> </repository> <repository name="15.4"> <path project="devel:languages:python:backports" repository="15.4"/> <arch>x86_64</arch> </repository> Also, as discussed in the thread, you probably want paths to the :Update repos either in your projects or in d:l:p:backports directly. - Ben

2 1

Re: Building an NPM (or electron?) package (in my case https://github.com/kubernetes-sigs/kui)
by Dan Čermák 10 Jan '22

10 Jan '22

Hi Johannes, Johannes Kastl <kastl(a)b1-systems.de> writes: > Hi all, > > I tried the wiki and some search-foo but ended up with deprecated things on how > to build a NPM package (or something that looks like it). > > https://en.opensuse.org/openSUSE:Packaging_nodejs > > In my case I wanted to try building kui from > https://github.com/kubernetes-sigs/kui, which to me looks like NPM-Foo: > > Quoting the README: >> I don't trust the prebuilts >> >> We hear you. Choose your platform (e.g. mac:amd64), execute the following, then look in ./dist/electron. >> >> git clone git@github.com:kubernetes-sigs/kui.git && cd kui && npm ci && \ >> npm run build:electron:mac:amd64 > > Might not be the best package to get going with NPM, as it seems rather complex. Afaik the current recommended approach is to avoid packaging node.js applications ;-) Now for useful answers: a year ago I asked the same question and was pointed towards obs-service-node_modules[1], which should help you with bundling all the required dependencies. Unfortunately I'm afraid that's all I can help you with. Also, please be very careful with Electron: it's a licensing minefield due to the inclusion of ffmpeg and thus various video encoders/decoders. Iirc Tomáš Chvátal told me a few years ago how much of a pain in the rear it was to properly build Chromium offline (which is effectively Electron) and I'd rate that as a 1/10, would not recommend doing unless absolutely necessary. Hope this helps, Dan Footnotes: [1] https://github.com/openSUSE/obs-service-node_modules -- Dan Čermák <dcermak(a)suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev

2 1

Building an NPM (or electron?) package (in my case https://github.com/kubernetes-sigs/kui)
by Johannes Kastl 10 Jan '22

10 Jan '22

Hi all, I tried the wiki and some search-foo but ended up with deprecated things on how to build a NPM package (or something that looks like it). https://en.opensuse.org/openSUSE:Packaging_nodejs In my case I wanted to try building kui from https://github.com/kubernetes-sigs/kui, which to me looks like NPM-Foo: Quoting the README: > I don't trust the prebuilts > > We hear you. Choose your platform (e.g. mac:amd64), execute the following, then look in ./dist/electron. > > git clone git@github.com:kubernetes-sigs/kui.git && cd kui && npm ci && \ > npm run build:electron:mac:amd64 Might not be the best package to get going with NPM, as it seems rather complex. So any hints are highly appreciated. Kind Regards Johannes -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- Johannes Kastl Linux Consultant & Trainer Tel.: +49 (0) 151 2372 5802 Mail: kastl(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg http://www.b1-systems.de GF: Ralph Dehner Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

1 1

devel:languages:python:backports and enabled repositories
by Ben Greiner 10 Jan '22

10 Jan '22

Hello, Unfortunately, many builds for SLE and Leap in devel projects are currently broken. This is a result from some back and forth changes of enabled repositories in devel:languages:python:backports, which needs to be corrected in a consistent way.* Some history: devel:languages:python:backports had several repositories for the SLE/Leap 15 family enabled: - SLE_15 - SLE_15_SP1 - SLE_15_SP2 - SLE_15_SP3 - openSUSE_Leap_15.2 - openSUSE_Leap_15.3 - (openSUSE_Leap_15.4, not sure if this ever existed) - 15.3 - 15.4 Because of the unification between SLE and Leap from 15.3 onwards, some of these are identical duplicates but create the duplicate workload for the obs servers (all of Factory in this case!). So some time ago, there was a survey and poll how newly enabled projects should name their single SLE15SP3/Leap_15.3 repositories, and the decision was "15.3". I can't find the reference right now. Unfortunately there is no guideline or wiki page about it, only some mailinglist post. There was also a discussion on the packaging ML earlier last month, without a clear guideline. As a consequence, the web interface only lets you create one "15.3" repository, no matter on which distribution checkmark of the SLE/Leap family you click: <repository name="15.3"> <path project="openSUSE:Leap:15.3" repository="standard"/> <arch>x86_64</arch> </repository> Now, devel:languages:python, some of the subprojects there and possible other devel projects outside of this namespace had devel:languages:python:backports in their path like this: <repository name="15.3"> <path project="devel:languages:python:backports" repository="TARGETREPO"/> <path project="openSUSE:Leap:15.3" repository="standard"/> <arch>x86_64</arch> </repository> Unfortunately, among projects, TARGETREPO was not used consistently as "15.3" but used a variant of the duplicates above. Enter some user** who wanted to get "his" project fixed. His request: "Please delete the duplicates, please use openSUSE_Leap_15.3 as the proper name." His request was granted by the project maintainer. Unfortunately, this broke all the devel projects which used one of the deleted repositories 15.3, including devel:languages:python. The meta configuration now read: <repository name="15.3"> <path project="deleted" repository="deleted" /> <path project="openSUSE:Leap:15.3" repository="standard"/> <arch>x86_64</arch> </repository> Now, just re-adding 15.3 does not fix the "deleted" entries. You have to fix it manually. So my request to fix the path entries and use the repo names found by consensus was understood as to revert the previous users' request and recreate the "15.3" and "15.4" repositories in d:l:p:backports. On the other hand, openSUSE_Leap_15.3 and similar have been removed again (as they would indeed be duplicates). Now of course those projects having had those repositories in their path also have the "deleted" entries, while those from the previous deleted still have it too. In order to fix things and get consistent, I propose that all maintainers of devel projects making use of devel:languages:python:backports, devel:languages:python and any transitive projects check their repository configuration and adjust accordingly. In my eyes, the correct entries would be for all of them: <repository name="15.3"> <path project="devel:languages:python:backports" repository="15.3"/> <path project="openSUSE:Leap:15.3" repository="standard"/> <arch>x86_64</arch> </repository> <repository name="15.4"> <path project="devel:languages:python:backports" repository="15.4"/> <path project="openSUSE:Leap:15.4" repository="standard"/> <arch>x86_64</arch> </repository> - Ben [1] https://lists.opensuse.org/archives/list/packaging@lists.opensuse.org/threa… * Although the value of d:l:p:backports is vanishing fast anyway. Most packages in Factory have already dropped or will drop soon support for Python 3.6. ** name intentionally omitted, this is not a blame post but a request to get the technical situation corrected.

5 19