Hi Alan, On Sat, Dec 05, 2015 at 12:10:43PM -0700, Alan Robertson wrote:
On 12/05/2015 10:39 AM, Lars Müller wrote:
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: [ 8< ] How are you creating the packages? Have you consider to make use of the OBS? 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.
Well, then it looks like it's good enough.
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 have non in mind. But here on this list should be many with the fitting skill level.
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.
SUSE runs on Power, S390, AArch, and anything else too. And luckily we finally dropped 32bit x86 support with openSUSE Leap 42.1.
Since the base docker images are very stripped down, I know for certain that I've documented all my dependencies.
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?
That's all done with the OBS. Either via the osc command line tool or the https://build.opensuse.org web UI. While I only occasionally use it.
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 instead? 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: https://bugzilla.opensuse.org/show_bug.cgi?id=958073
osc maintainer -e ... I've added Chritian to cc.
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 ;-)
No, no. Only a little. ;-)
osc se osc maintainer Are there corresponding web interfaces?
https://build.opensuse.org/ Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany