Mailinglist Archive: opensuse-packaging (106 mails)

< Previous Next >
Re: [opensuse-packaging] I'm having a problem building packages for openSUSE...
On 12/05/2015 10:39 AM, Lars Müller wrote:
Hi Alan,

On Sat, Dec 05, 2015 at 10:14:10AM -0700, Alan Robertson wrote:
On 12/05/2015 09:29 AM, Lars Müller wrote:
On Sat, Dec 05, 2015 at 09:11:55AM -0700, Alan Robertson wrote:
On 12/03/2015 08:38 PM, Andrei Borzenkov wrote:
03.12.2015 23:34, Alan Robertson пишет:
Good point ;-). Thanks for reminding me.Not sure where my brain was... I
guess I was into wishful thinking - this was a known problem with a
simple workaround...
This is likely a common/known problem for people who use cmake and start
their RPM spec files working on that red distribution or one of its clones.

Apparently, on those distributions, they expect you to do the
mkdir+cd/pushd yourself - and SuSE does both for you.

But, it's now working quite nicely. The spec file is here:
Create a project in the openSUSE Build Service (OBS) which pulls in the
assimilation-cma.spec via git automatically.

Thanks to your help, the next Assimilation release will provide openSUSE
13.2 and 42.1 RPMs.
How are you creating the packages? Have you consider to make use of the
I did at one point. After spending a few hours reading the documents, I
couldn't figure it out. Also, I run tests on each platform. These tests
require root permissions.
Even that should be possible to handle. There was a recent discussion
regarding this.
But I am unmotivated to change what's working well for me. Perhaps if
someone comes along and wants it for a platform I can't build under
Docker, but is available under OBS.

Also I need a few python packages for which
there are no corresponding RPMs. One for building, a couple for testing,
and I think two for the installed CMA packages. None for the nanoprobes.
Well, then they need to be packaged too.
But they aren't my problem ;-) - and I don't have time to fix those
myself. Can you suggest someone who would be interested in packaging up
a few python modules?

I build them all on my desktop or laptop or whatever using Docker. It
works really well. It's quite fast, noticeably faster than a VM
environment. I have even rebuilt releases while traveling. My laptop
might be a half-hour slower than my desktop for the 10 versions of Linux
that we release it for, but it's quite acceptable. Most of the time is
spent running the tests. I build the software in two different ways,
then I install the package, and I run my tests. For 10 releases this
takes about 2 hours. Before putting out an official release, I run some
system-level tests, validate the versions for consistency, checksum the
packages, and other things.
Oh, you're on the docker wafe. Have a safe ride. ;)
I have seen reasons not to run it in production, but it's really good
for this kind of use.

I doubt OBS would be much if any faster than doing it on my own
hardware. There is an annoying Docker bug that keeps me from building
more than one at a time. I have plenty of resources to do it, but Docker
gets confused. I need to document that bug for them...
OBS isn't about speed. It's about reproduceability.
What I'm doing is very reproducible - as long as you only care about
64-bit Intel platforms running Linux. Since the base docker images are
very stripped down, I know for certain that I've documented all my

What I really like about building it all myself is that it's much faster
to debug than when I run into a problem. When it's working, I don't care
so much how fast it is ;-)

Unfortunately, I can't easily provide 13.1 releases (even though it's
been selected as long term) because there is no libsodium for 13.1.

*Is there any mechanism for requesting to have libsodium added to 13.1?
[or is it frozen?]*
All is possible and all you need to do is to file a maintenance request
against the openSUSE:13.1:Update OBS project.
Where do I go to do that?
Where do I do that nowadays?
And - for good measure, no one should be using or providing 1.0.0 of
libsodium due to a potentially fatal (crash) bug in the library. It's
quite unlikely to occur, but if if does, the client application will crash.
Which openSUSE versions make use of 1.0.0 and what should they use
13.2 provides 1.0.0. You can just use 1.0.1 - IIRC, it's mainly this bug
fix. I didn't run against any bugs in 1.0.1 or later. I run two of my
tests under valgrind, and those two failed with 1.0.0 - until I put in a
valgrind exception to allow for the bug in libsodium.
Then please start the update. The first step is to file a bugreport and
take the openSUSE securiry group in cc.
Although this is a security-related package, this isn't a security bug.
It's a potential crash bug. Here's the bug URL:

The bug goes like this: When encrypting, 1.0.0 reads two more bytes from
the buffer (or key?) than I told it to. Those bytes don't go into the
crypto stream and don't affect the results. If that buffer is exactly at
the end of a page, and the next page in your address space isn't there
(isn't valid), then you will crash.

This is very unlikely, but possible. I found the problem before 1.0.1
had come out, so I had to put in the workaround in my valgrind tests.
So, I would only care if one of my customers crashed as a result. Again,
it's very unlikely, but possible.

There have been no API changes at least up until 1.0.5. I've tested with
most of versions along the way. Not extensively, but enough to know that
they work fine and I haven't had to change my code at all. In fact, I've
never had to change my code for libsodium versions.

Better is to point the libsodium maintainer(s) to the particular commit
which addresses the crash bug. Then it's quite easy to add the required
commit(s) to the existimg sources. That's the general rule. Sometimes
we even do minor version updates.
I don't know who those maintainers are. I haven't done much with SuSE
since I got laid off in 2000.
Things changed heavily since 2000. osc is the openSUSE Build Service
command line utility.
I assumed it had changed a lot since then ;-)

osc se
osc maintainer
Are there corresponding web interfaces?

and so on.




Alan Robertson / CTO
AlanR@xxxxxxxxxxxxxxxxxxxxxxx <mailto:AlanR@xxxxxxxxxxxxxxxxxxxxxxx>/ +1

Assimilation Systems Limited

Twitter <> Linkedin
<> skype

To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups