Hi,
I noticed that on my private instance, my packages always have the
debuginfo package built, despite of whether the flag is on or off on the
project repository page. Am I missing anything?
Thanks,
Kai
Hi,
there was recently a post that mentioned that invalid users on OBS should be
cleaned-up.
I would like to ask what the status/progress of this is....
Thanks
Axel
Hi all,
I am sorry for reviving this old thread, but unfortunately this is still a thing.
The science gpg key is still using dsa1024 which is considered too weak especially by Ubuntu systems.
As the key will expire soon (2021-11-11), is there any chance to upgrade to another signature algorithm?
pub dsa1024 2008-01-22 [SC] [expires: 2021-11-11]
D1DD7ACD6D68A0B43081B15801DB7302943D8BB8
uid science OBS Project <science(a)build.opensuse.org <mailto:science@build.opensuse.org>>
Best
Christian
> On 8. May 2018, at 19:14, Felder, Christian <c.felder(a)fz-juelich.de> wrote:
>
> On 2. May 2018, at 19:11, Adrian Schröter <adrian(a)suse.de <mailto:adrian@suse.de>> wrote:
>>
>> On Mittwoch, 2. Mai 2018, 18:06:08 CEST wrote Stanislav Brabec:
>>> Yes, there is DSA1024 key used in science:
>>> osc signkey science | gpg
>>> returns
>>> pub dsa1024 2008-01-22 [SC] [expires: 2019-09-17]
>>> D1DD7ACD6D68A0B43081B15801DB7302943D8BB8
>>> uid science OBS Project <science(a)build.opensuse.org <mailto:science@build.opensuse.org>>
>>>
>>> science:gr-framework inherits it from science.
>>>
>>> The key is still valid, but DSA1024 seems to be considered as weak, so
>>> we probably have to create a new one.
>>>
>>> Henne, could you confirm that? Should I use:
>>> osc signkey --create science
>>>
>>> It will trigger rebuild of all packages in all science sub-projects.
>>
>> and you should tell the users, since it will be a new key. So it will
>> look for someone as a breach ...
>>
>> (zypp is not supporting a key upgrade, it will just tell it is different and ask to
>> to accept or refuse)
>
> The key has to be upgraded anyway at some point. As SHA1 encryption has been
> declared as completely insecure I would prefer to generate a new key asap (and revoke the
> previous key but this is probably not possible).
>
>>
>>> Felder, Christian wrote:
>>>> Hi,
>>>>
>>>> I am writing this mail to you guys because you are listed as maintainers
>>>> of the science namespace at opensuse build service (build.opensuse.org <http://build.opensuse.org/>
>>>> <http://build.opensuse.org <http://build.opensuse.org/>>)
>>>> and I could not reach you guys either on IRC or via bug reporting which
>>>> seems to be just on GitHub nowadays (previously there was some bug
>>>> tracker based on redmine).
>>>> My issue on github got just closed with the information I should contact
>>>> you guys directly…
>>>> (https://github.com/openSUSE/open-build-service/issues/4937 <https://github.com/openSUSE/open-build-service/issues/4937>)
>>>>
>>>> Hi, we get errors on gpg signature checks using the science:
>>>> repositories (e.g. on Ubuntu 17.04, Ubuntu 18.04). Some time ago we also
>>>> got errors that the key uses weak encryption (SHA1)
>>>>
>>>> |W: GPG error:
>>>> http://download.opensuse.org/repositories/science:/gr-framework/xUbuntu_18.… <http://download.opensuse.org/repositories/science:/gr-framework/xUbuntu_18.…>
>>>> Release: The following signatures were invalid:
>>>> D1DD7ACD6D68A0B43081B15801DB7302943D8BB8 E: The repository
>>>> 'http://download.opensuse.org/repositories/science:/gr-framework/xUbuntu_18.…
>>>> Release' is not signed. N: Updating from such a repository can't be done
>>>> securely, and is therefore disabled by default. |
>>>>
>>>> Is there anything we can do from our side or do you have to replace the
>>>> science: signing key?
>>>>
>>>> Probably it is sufficient to renew the gpg key for science: which cannot
>>>> be done by myself.
>>>> Any help would be appreciated. Thanks in advance.
>>>> Christian
>>>>
>>>> Christian Felder M. Sc.
>>>>
>>>> Jülich Centre for Neutron Science JCNS
>>>> at Heinz Maier-Leibnitz Zentrum MLZ
>>>> Forschungszentrum Jülich GmbH
>>>> Lichtenbergstraße 1
>>>> 85747 Garching
>>>> GERMANY
>>>>
>>>> Telefon: +49 - 89 289 10 773
>>>> Telefax: +49 - 89 289 10 799
>>>>
>>>
>>>
>>
>>
>> --
>>
>> Adrian Schroeter
>> email: adrian(a)suse.de <mailto:adrian@suse.de>
>>
>> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
>>
>> Maxfeldstraße 5
>> 90409 Nürnberg
>> Germany
Hey all,
So I've been trying to build packages for CentOS Stream 9[1] and all
the ppc64le builds are failing because POWER9 is required.
Pretty much all the builds have some variation of the following error
for ppc64le:
[ 24s] Fatal glibc error: CPU lacks ISA 3.00 support (POWER9 or
later required)
Are there POWER9 builders in the pool, and if so, can we make sure
those are used for CentOS Stream 9 ppc64le builds?
Thanks in advance!
[1]: https://build.opensuse.org/project/show/home:Pharaoh_Atem:CS9EPELDev
--
真実はいつも一つ！/ Always, there's only one truth!
Hi experts,
Sometimes I would like to disable the %check stage in my test build as
for some packages it take quite some time, while I just would like to
know if it builds and packages well.
I know I can wrap the whole %check section in a %if macro and check for
some conditions defined in the project config. The problem is I'm too
lazy to make that change to all the packages I'm building.
I noticed that the /usr/bin/build script has a --no-checks option which
passes to rpmbuild. This seems is exactly what I need. But how can I
pass this to the /usr/bin/build script in OBS? I looked around but can't
find an obvious way.
Regards,
Kai
Hello List,
I have a query regarding building a product based on SLE15 in a private OBS
instance. I've defined a product which contains a set of packages that we want
to include in our DVD image.
When building the product, I'm observing something strange - at least, it is
strange to me!
# grep 'name="kernel-preempt"' /srv/obs/jobs/local/home:srinidhi::images::000product:MyProduct-dvd5-DVD-x86_64-dabfdd0ba6d86f38c4469612433abf91
<bdep name="kernel-preempt" version="5.3.18" release="57.3" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP3:GA" repository="pool" repoarch="x86_64" package="kernel-preempt" />
<bdep name="kernel-preempt" version="5.3.18" release="24.83.2" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP2:Update" repository="pool" repoarch="x86_64" package="kernel-preempt.21097" />
<bdep name="kernel-preempt" version="5.3.18" release="24.78.1" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP2:Update" repository="pool" repoarch="x86_64" package="kernel-preempt.20693" />
<bdep name="kernel-preempt" version="5.3.18" release="24.75.3" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP2:Update" repository="pool" repoarch="x86_64" package="kernel-preempt.20456" />
<bdep name="kernel-preempt" version="5.3.18" release="24.70.1" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP2:Update" repository="pool" repoarch="x86_64" package="kernel-preempt.20295" />
<bdep name="kernel-preempt" version="5.3.18" release="24.67.4" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP2:Update" repository="pool" repoarch="x86_64" package="kernel-preempt.19865" />
<bdep name="kernel-preempt" version="5.3.18" release="24.64.1" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP2:Update" repository="pool" repoarch="x86_64" package="kernel-preempt.19476" />
<bdep name="kernel-preempt" version="5.3.18" release="24.61.1" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP2:Update" repository="pool" repoarch="x86_64" package="kernel-preempt.18992" />
<bdep name="kernel-preempt" version="5.3.18" release="24.53.4.1" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP2:Update" repository="pool" repoarch="x86_64" package="kernel-preempt.18619" />
<bdep name="kernel-preempt" version="5.3.18" release="24.52.1" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP2:Update" repository="pool" repoarch="x86_64" package="kernel-preempt.18518" />
<bdep name="kernel-preempt" version="5.3.18" release="24.49.2" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP2:Update" repository="pool" repoarch="x86_64" package="kernel-preempt.18105" />
<bdep name="kernel-preempt" version="5.3.18" release="24.46.1" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP2:Update" repository="pool" repoarch="x86_64" package="kernel-preempt.17781" />
<bdep name="kernel-preempt" version="5.3.18" release="24.43.2" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP2:Update" repository="pool" repoarch="x86_64" package="kernel-preempt.17491" />
<bdep name="kernel-preempt" version="5.3.18" release="24.37.1" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP2:Update" repository="pool" repoarch="x86_64" package="kernel-preempt.17045" />
<bdep name="kernel-preempt" version="5.3.18" release="24.34.1" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP2:Update" repository="pool" repoarch="x86_64" package="kernel-preempt.16900" />
<bdep name="kernel-preempt" version="5.3.18" release="24.29.2" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP2:Update" repository="pool" repoarch="x86_64" package="kernel-preempt.16796" />
<bdep name="kernel-preempt" version="5.3.18" release="24.24.1" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP2:Update" repository="pool" repoarch="x86_64" package="kernel-preempt.16628" />
<bdep name="kernel-preempt" version="5.3.18" release="24.15.1" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP2:Update" repository="pool" repoarch="x86_64" package="kernel-preempt.16351" />
<bdep name="kernel-preempt" version="5.3.18" release="24.12.1" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP2:Update" repository="pool" repoarch="x86_64" package="kernel-preempt.16309" />
<bdep name="kernel-preempt" version="5.3.18" release="24.9.1" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP2:Update" repository="pool" repoarch="x86_64" package="kernel-preempt.15761" />
<bdep name="kernel-preempt" version="5.3.18" release="22.2" arch="x86_64" project="openSUSE.org:SUSE:SLE-15-SP2:GA" repository="pool" repoarch="x86_64" package="kernel-preempt" />
Why does the buildinfo contain binaries from each of the update package instead
of the binaries mentioned in the container (link) package?
Here, "kernel-preempt" is just one example. I see this for every package that
has had, at least, maintenance update released since SUSE:SLE-15:GA was frozen.
This has adverse affects on the worker machine where all of these binaries are
downloaded and never to be considered by KIWI:
# du -sh /abuild/obs/workers/root_2/.build-srcdir/repos/
107G /abuild/obs/workers/root_2/.build-srcdir/repos/
The build that has been triggered under the "root_2" build root is still
fetching binaries - since exactly 24 hours now!! The final DVD images would
hardly be more than 12-14GB in size.
Downloading this much of unnecessary data over the WAN when using the OBS
interconnect is extremely costly - bandwidth and time - in my opinion.
Is this happening due to something that I am doing? Is this a bug? Any help or
pointers would be greatly appreciated!
Regards,
Srinidhi.
Hey,
CentOS Stream 9 is now "released" and a formal announcement will come
any day now. Can we get CentOS Stream 9 added to OBS now?
I've attached project meta and project configuration that can be used
for this, tested locally on my system.
Thanks in advance and best regards!
--
真実はいつも一つ！/ Always, there's only one truth!
Hello,
I get mails from my OBS instance with the content
Additional projects in backend:
["Test"]
What is the problem and how do I fix the issue?
Best regards,
Mark Morschhäuser
