Re: [opensuse-packaging] I'm having a problem building packages for openSUSE...
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:
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
On 12/03/2015 08:38 PM, Andrei Borzenkov wrote: 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: https://github.com/assimilation/assimilation-official/blob/master/docker/Cen... 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 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.
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.
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 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 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? 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.
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. osc se osc maintainer and so on. Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team + SUSE Labs SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
Am 5. Dezember 2015 14:39:43 GMT-03:00, schrieb "Lars Müller"
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
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:
https://github.com/assimilation/assimilation-official/blob/master/docker/Cen... Create a project in the openSUSE Build Service (OBS) which pulls in
was... I 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 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.
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.
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 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.
...and If you need speed, build locally and check in once the result is satisfying; osc build.... Cheers Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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:
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
On 12/03/2015 08:38 PM, Andrei Borzenkov wrote: 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: https://github.com/assimilation/assimilation-official/blob/master/docker/Cen... 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 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.
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 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? 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
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.
Cheers,
Lars
-- Alan Robertson / CTO AlanR@AssimilationSystems.com mailto:AlanR@AssimilationSystems.com/ +1 303.947.7999 Assimilation Systems Limited http://AssimilationSystems.com Twitter https://twitter.com/ossalanr Linkedin https://www.linkedin.com/in/alanr skype https://htmlsig.com/skype?username=alanr_unix.sh -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
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
participants (3)
-
Alan Robertson -
Axel Braun -
Lars Müller