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
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
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
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
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
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
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
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
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
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