January 2020 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Re: [opensuse-factory] OBS in cold start after regression
by Adrian Schröter 31 Jan '20

31 Jan '20

On Freitag, 31. Januar 2020, 12:27:42 CET Aleksa Sarai wrote: > On 2020-01-31, Adrian Schröter <adrian(a)suse.de> wrote: > > we had a serious regression in spec file parser of OBS > > since yesterday. > > > > We need therefore a cold start of the schedulers to get into > > guaranteed clean state again. > > I hate to add more fuel to the fire -- but it looks like OBS is down > now? I get "Sorry, our script crashed." errors after a really long > timeout. The storage was not able to handle the load of all the scheduler cold starts... We do it incremental now. -- Adrian Schroeter <adrian(a)suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany (HRB 247165, AG München), Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] OBS in cold start after regression
by Adrian Schröter 31 Jan '20

31 Jan '20

Hi, we had a serious regression in spec file parser of OBS since yesterday. We need therefore a cold start of the schedulers to get into guaranteed clean state again. sorry adrian -- Adrian Schroeter <adrian(a)suse.de> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany (HRB 247165, AG München), Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] zypper seriously mislead me
by Felix Miata 25 Jan '20

25 Jan '20

In an attempt to QA https://bugzilla.opensuse.org/show_bug.cgi?id=1161763 I thought I needed to do: # zypper -v in android-studio which is http://download.opensuse.org/repositories/home:/jayvdb:/android/openSUSE_Tu… 42K Zypper reported extracted size to be 50.1K. I thought, no big deal, so I proceeded. Freespace on / when I started was 81%. Installation was taking a seriously long time for a 50K installation, so I checked with lsof to find a zip file in /opt growing to 1015M. # excerpted tail of /var/log/zypp/history 2020-01-03 14:29:10|install|frameworkintegration-plugin|5.65.0-1.1|x86_64|root@p5bse|OSS|d094dddd716eed86e157577a29cb3b54c57e5959fa382a1f19c53b5b38c685ec| 2020-01-24 22:25:10|command|root@p5bse|'zypper' 'rm' 'kernel-default-4.20.13'| 2020-01-24 22:25:34|remove |kernel-default|4.20.13-1.2|x86_64|root@p5bse| 2020-01-24 22:29:16|command|root@p5bse|'zypper' '-v' 'in' 'android-studio'| # 2020-01-24 22:42:43 android-studio-3.3.2-2.4.x86_64.rpm installed ok # Additional rpm output: # /var/tmp/rpm-tmp.bQj4UK: line 5: /tmp/apps-scripts/android-studio.txt: Nosuch file or directory # --2020-01-24 22:29:18-- https://dl.google.com/dl/android/studio/ide-zips/3.3.2.0/android-studio-ide… # Resolving dl.google.com (dl.google.com) 64.233.185.190, 64.233.185.93, 64.233.185.136, ... # Connecting to dl.google.com (dl.google.com)|64.233.185.190|:443... connected. # HTTP request sent, awaiting response... 200 OK # Length: 1064031415 (1015M) [application/zip] # Saving to: '/opt/android-studio-ide-182.5314842-linux.zip' # # 0K .......... .......... .......... .......... .......... 0% 962K 18m0s # 50K .......... .......... .......... .......... .......... 0% 1.84M 13m36s ... # 499500K .......... .......... .......... .......... .......... 48% 1.34M 6m40s # 499550K .......... .......... .......... .......... .......... 48% 1.47M 6m40s # [truncated] # 2020-01-24 22:42:43|install|android-studio|3.3.2-2.4|x86_64|root@p5bse|homeJayvdbAndroid|077b7bba49ae36178706c3e19e5999ada1f88493a30d6baa28417b1befafb05f| >From the description at https://software.opensuse.org/package/android-studio?search_term=android-st… I had no clue that the android-studio rpm was merely an installer for a very much larger package. Zypper gave no clue that the post script was exhausting freespace wgetting a 1015M file that would leave insufficient space to extract its contents. Did the android-studio packager not do something he should have done? Is there something that could be done to prevent exhausting freespace by installing a 50K rpm without any warning what was really going to result? -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 2

[opensuse-packaging] how to add new bitmap fonts directory?
by Ludwig Nussel 21 Jan '20

21 Jan '20

Hi, How does one package a new bitmap font that also ships a fonts.alias into the font search path? Obviously /usr/share/fonts/misc can't be used as /usr/share/fonts/misc/fonts.alias is already owned by xorg-x11-fonts-core Just using another directory in /usr/share/fonts doesn't seem to work either. Some config file somewhere that I missed? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 4

Fwd: Re: [opensuse-packaging] STK-4.6.1 and Licensing
by Konstantin Voinov 21 Jan '20

21 Jan '20

Ok, I see. Gonna prepare a package at first. On 2020-01-20 23:22, Dan Čermák wrote: > Hi Konstantin, > > Dan Čermák <dcermak(a)suse.com> writes: > >> Hi Konstantin, >> >> Konstantin Voinov <kv(a)kott.no-ip.biz> writes: >> .. >> >> It appears that the problematic lines were removed from soundcard.h on >> September 29 2013: >> https://github.com/thestk/stk/commit/fc877b87bf9ce2cda33766e37835cff297848b… >> >> So _in theory_¹ you should now be allowed to update stk and submit the >> changes to Factory (where licensedigger and the legal team will >> evaluate >> that). > > I've ran a scan using FOSSA on the stk sources and it found the > following licenses in the source code: > > BSD 2-Clause "Simplified" License: > - src/include/soundcard.h > > Public Domain: > - doc/treesed.html > - src/include/iasiothiscallresolver.h > - README.md > > GPL-3.0-with-GCC-exception: > - config/config.sub > - config/config.guess > > MIT (this is the LICENSE file) > > > There's however another issue, see the section > https://github.com/thestk/stk#legal-and-ethical: > > --8<---------------cut here---------------start------------->8--- > Some of the concepts are covered by various patents, some known to us > and likely others which are unknown. Many of the ones known to us are > administered by the Stanford Office of Technology and Licensing. > --8<---------------cut here---------------end--------------->8--- > > which could be a show stopper for shipping this in openSUSE... > > > Cheers, > > Dan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] STK-4.6.1 and Licensing
by Konstantin Voinov 20 Jan '20

20 Jan '20

Hi, The STK in openSUSE is quite old (4.5.0 vs 4.6.1) and has crippled content due license problems. I cannot open original bug https://bugzilla.novell.com/show_bug.cgi?id=760936 just found this in mail-lists: https://cm-mail.stanford.edu/pipermail/stk/2012-May/000922.html >> The openSUSE legal team wrote this about the legal status of stk, for >> inclusion in the distribution: >> >> "The next issue is that the README for the package has the following >> paragraph >> (starts at line 35) that seems to prohibit commercial usage (which >> would also >> fall outside the Open Source Definition): >> >> The Synthesis ToolKit is free for non-commercial use. The only >> classes of the Synthesis ToolKit that are platform-dependent concern >> sockets, threads, mutexes, and real-time audio and MIDI input and >> output. The interface for MIDI input and the simple Tcl/Tk graphical >> user interfaces (GUIs) provided is the same, so it's easy to >> experiment in real time using either the GUIs or MIDI. The Synthesis >> ToolKit can generate simultaneous SND (AU), WAV, AIFF, and MAT-file >> output soundfile formats (as well as realtime sound output), so you >> can view your results using one of a large variety of sound/signal >> analysis tools already available (e.g. Snd, Cool Edit, Matlab). >> >> The situation is confused by the paragraphs starting at line 125 >> (LEGAL AND >> ETHICAL). The first one seems to reinforce the non-commercial >> statement made >> previously ('and for free') whereas the next paragraph is a relatively >> standard, liberal, open source license." >> >> Could you please simplify the legal requirements to make it clear if >> the software is "Open Source" (as the OSI defines it) or not? >> Specifically you should be able to use it for whatever use you want, >> even commercial, and you should be able to charge for it. Now, there no such statements in README[1], LICENSE[2] and FAQ[3]. And there is a notice from authors: https://ccrma.stanford.edu/software/stk/faq.html So, is it necessary for SUSE Legal team to review STK License or I can simple build it in my repo without worries? :) [1]https://github.com/thestk/stk/blob/master/LICENSE [2]https://github.com/thestk/stk/blob/master/README.md [3]https://github.com/thestk/stk/blob/master/doc/doxygen/faq.txt -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 2

[opensuse-packaging] Some help required with R-Studio packaging
by Marco Varlese 17 Jan '20

17 Jan '20

Dear all, I have spent sometime with putting together a package for R-Studio which compiles against Factory base. It required some work due to Java and Boost dependencies which the upstream version of R-Studio contemplates for older version of both tool/libraries. That said I reached the point now where the the compiled files require to be packaged and organized properly. I am not too familiar with applications packaging which have a UI front-end with icons, etc. I was wondering if anybody would be interested and has some spare time in helping out? In case you are, you can branch my package which can be found here: home:mvarlese/rstudio Any help would be truly appreciated! Kind regards, Marco

4 6

[opensuse-packaging] Building live CDs via KIWI
by Greg Freemyer 15 Jan '20

15 Jan '20

All, Attempting to do these builds I encountered: "KiwiCommandNotFound: Command "gfxboot" not found in the environment" I couldn't find a solution online, so for those coming behind me: You have to configure your overall project (not the package) to allow KIWI based live CD builds. I was working in the WebUI for build.opensuse.org. I had to create a custom repo named "images" in the meta tab: Add: <repository name="images"> <path project="openSUSE:Leap:15.1:Update" repository="standard"/> <path project="openSUSE:Leap:15.1" repository="standard"/> <arch>x86_64</arch> <arch>local</arch> </repository> Then in the "Project Config" tab I have: ==================================== %if "%_repository" == "images" Type: kiwi Repotype: none Patterntype: none %endif Preinstall: syslinux ===================================== I don't know which parts of that are critical, but that is allowing me to build a KIWI based openSUSE 15.1 live CD. Greg -- Greg Freemyer Advances are made by answering questions. Discoveries are made by questioning answers. — Bernard Haisch -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] Dropping asciidoc on TW (or other possible solutions)
by Takashi Iwai 14 Jan '20

14 Jan '20

Hi, among the recent action for python2 genocide on TW, asciidoc is also its target. Unfortunately, there are still lots of packages that rely on asciidoc for generating man pages and documents, hence simply dropping it shall result in many build breakage. Now my question is what action we should take. A: Drop asciidoc package now and let each package maintainer fixing each broken one. B: Find an alternative, python3 variant of asciidoc (likely a downstream one). C: Replace with asciidoctor. I've tested with a hackish bash script to make it more compatible with asciidoc. D: Any other option? For B and C, we need completely new packages. I have no idea about option B, so someone else needs to take care of it. The option C is tested in OBS home:tiwai:test:asciidoc-drop project, which contain two new packages, asciidoc-compat and rubygem-asciidoctor-docbook45. This solution would be on TW only if someone else takes over the maintenance of those two. I have no gut for maintaining them for TW. And, note that C would still result in lots of formatting issues because of subtle differences between asciidoc and asciidoctor (e.g. inapplicable config snippet, different syntax handling). Also a couple of packages still have some build issues wrt asciidoctor, so they need fixes in addition to a wrapper script. Last but not least, asciidoctor isn't included in the standard Leap 15.x releases, so unconditionally applying asciidoctor would break the builds in devel projects. So, please speak up for what way we should go. If anyone is willing to take over the maintenance (either new ones or old one), I'd be really happy, too. thanks, Takashi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 6

[opensuse-packaging] unwanted python2 dependcies
by Christian Goll 14 Jan '20

14 Jan '20

Hello, I just realized that some python3 packages install python2 packages. This is for example true for python3-networkx, which recommends graphiz that has dependency on python2 packages. As a workaround one can use zypper in --no-recommends which is not an ideal solution. Are there plans to resolve this in a more proper way? kind regards, Christian -- Christian Goll CGoll(a)suse.de SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1