December 2015 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] devel:languages:R:released and leap
by Sebastian Schubert 11 Dec '15

11 Dec '15

Hi, I am not sure whether this is the right place to ask but I'll give it a try: Could anyone please correct the 42.1 repositories of devel:languages:R:released to openSUSE_Leap_42.1 and add openSUSE_Leap_42.1 to the other subprojects? Thanks a lot, Sebastian -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] E: krb5 64bit-portability-issue ldap_principal2.c:687
by Michael Ströder 09 Dec '15

09 Dec '15

HI! Building krb5-1.14 fails with the following message: [ 235s] E: krb5 64bit-portability-issue ldap_principal2.c:687 It seems the RPMs were written: https://build.opensuse.org/package/live_build_log/home:stroeder:branches:ne… How to deal with that? Simply disable this check? If yes, how? Ciao, Michael.

2 2

[opensuse-packaging] storeBackup - where to submit?
by Thomas Wagner 09 Dec '15

09 Dec '15

Hi, I found a bug in storebackup which is fixed upstream. So I branched from storeBackup from openSUSE:Leap:42.1 https://build.opensuse.org/package/show?project=openSUSE%3ALeap%3A42.1&pack… to my home-project and included the patch. Now I struggle with submitting it. In other branched projects I used the submit button which was prefilled with the parent project. But not so with storeBackup. There is no link-diff there https://build.opensuse.org/package/show/home:Aikhjarto:branches:openSUSE:Le… Can anyone tell me what project to submit my update to? BR Thomas -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 4

[opensuse-packaging] packaging lib with plugins (the suil case)
by Roman Evstifeev 08 Dec '15

08 Dec '15

Hi. I am still trying to figure out the right way to package somewhat complex suil library. It consists of library itself and four "wrap modules": /usr/lib64/libsuil-0.so.0 /usr/lib64/libsuil-0.so.0.8.2 /usr/lib64/suil-0/libsuil_gtk2_in_qt4.so /usr/lib64/suil-0/libsuil_qt4_in_gtk2.so /usr/lib64/suil-0/libsuil_x11_in_gtk2.so /usr/lib64/suil-0/libsuil_x11_in_qt4.so Historically wrap modules was all in individual packages, called "libsuil-gtk2-in-qt4", etc. This was wrong, as far as i understood from previous discussions on the list. So right now i am trying to make it right. Can i move all these wrap modules into libsuil package itself (libsuil-0-0 that is)? The reason for this is that library is useless without these modules. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 7

Re: [opensuse-packaging] I'm having a problem building packages for openSUSE...
by Lars Müller 05 Dec '15

05 Dec '15

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: > >> https://github.com/assimilation/assimilation-official/blob/master/docker/Ce… > > 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

3 3

[opensuse-packaging] I'm having a problem building packages for openSUSE...
by Alan Robertson 05 Dec '15

05 Dec '15

Hi, I had a potential user ask me to provide the Assimilation project software for openSUSE. So, I started down that path to see if I could help him out. We have a good method of building packages for different distros using Docker - so that's what I did. I started with the Dockerfile I use to build CentOS and Fedora, but I ran into troubles on the 42.1 build. This is the version I get when I say "opensuse:latest" on Docker. Our code builds with cmake, not autotools. What's happens is that rpmbuild does a mkdir build, cd/pushd build twice. And then it invokes cmake with "*..*" as its argument. Either it needs to not do the mkdir/cd twice (which is what I suspect), or it needs to invoke cmake with "*../..*" as its argument. My annotations are on lines with ========= in them... Any idea what's going on here, and how I can work around this? Below is the output from the rpmbuild process... Step 24 : RUN rpmbuild -ba /root/assimilation/src/docker/CentOS6/assimilation-cma.spec --define="assimversion $GITPATH" ---> Running in 54a609390b06 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.uT0G2n [91m+ umask 022 + cd /usr/src/packages/BUILD [0m[91m+ /bin/pwd [0m/usr/src/packages/BUILD [91m+ ls -l [0mtotal 0 [91m+ cd /usr/src/packages/BUILD [0m[91m+ rm -rf assimilation-assimilation-official-662be35 [0m[91m+ /usr/bin/gzip -dc /usr/src/packages/SOURCES/assimilation-assimilation-official-662be35.tgz [0m[91m+ /bin/tar -xf - [0m[91m+ STATUS=0 [0m[91m+ '[' 0 -ne 0 ']' + cd assimilation-assimilation-official-662be35 [0m[91m+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w . [0m[91m+ exit 0 [0mExecuting(%build): /bin/sh -e /var/tmp/rpm-tmp.S47KBW [91m+ umask 022 + cd /usr/src/packages/BUILD [0m[91m+ /usr/bin/rm -rf /usr/src/packages/BUILDROOT/assimilation-cma-1.1.1-0.30.x86_64 [0m[91m++ dirname /usr/src/packages/BUILDROOT/assimilation-cma-1.1.1-0.30.x86_64 [0m[91m+ /usr/bin/mkdir -p /usr/src/packages/BUILDROOT [0m[91m+ /usr/bin/mkdir /usr/src/packages/BUILDROOT/assimilation-cma-1.1.1-0.30.x86_64 [0m[91m+ cd assimilation-assimilation-official-662be35 =============== this is the first mkdir/pushd ===================== [0m[91m+ *mkdir -p buil**d* [0m[91m+ *pushd build* [0m/usr/src/packages/BUILD/assimilation-assimilation-official-662be35/build /usr/src/packages/BUILD/assimilation-assimilation-official-662be35 [91m+ find . -name CMakeLists.txt -exec sed -i -re '/^[[:blank:]]*[sS][eE][tT][[:blank:]]*$[[:blank:]]*(CMAKE_BUILD_TYPE|CMAKE_COLOR_MAKEFILE|CMAKE_INSTALL_PREFIX|CMAKE_VERBOSE_MAKEFILE).*$/{s/^/#IGNORE /}' '{}' + =============== this is the second (extra/incorrect) mkdir/cd ============ [0m[91m+ *mkdir -p build* [0m[91m+ *cd build* =============== Here is the cmake that is going to fail ========== [0m[91m+***/usr/bin/cmake* *..* -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_INSTALL_LIBDIR:PATH=/usr/lib64 -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DCMAKE_BUILD_TYPE=None '-DCMAKE_C_FLAGS=-O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -DNDEBUG' '-DCMAKE_CXX_FLAGS=-O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -DNDEBUG' '-DCMAKE_Fortran_FLAGS=-O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -DNDEBUG' '-DCMAKE_EXE_LINKER_FLAGS=-Wl,--as-needed -Wl,--no-undefined -Wl,-z,now' '-DCMAKE_MODULE_LINKER_FLAGS=-Wl,--as-needed -Wl,--no-undefined -Wl,-z,now' '-DCMAKE_SHARED_LINKER_FLAGS=-Wl,--as-needed -Wl,--no-undefined -Wl,-z,now' -DLIB_SUFFIX=64 -DCMAKE_SKIP_RPATH:BOOL=ON -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_STATIC_LIBS:BOOL=OFF -DCMAKE_COLOR_MAKEFILE:BOOL=OFF -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_MODULES_INSTALL_DIR=/usr/share/cmake/Modules -DCMAKE_USER_MAKE_RULES_OVERRIDE=/usr/share/cmake/Modules/opensuse_rules.cmake .. -DCMAKE_SKIP_BUILD_RPATH=1 [0m[91mCMake Error: The source directory "/usr/src/packages/BUILD/assimilation-assimilation-official-662be35/build" does not appear to contain CMakeLists.txt. Specify --help for usage, or press the help button on the CMake GUI. [0m[91merror: Bad exit status from /var/tmp/rpm-tmp.S47KBW (%build) [0m[91m Bad exit status from /var/tmp/rpm-tmp.S47KBW (%build) [0m RPM build errors: time="2015-12-01T19:40:46-07:00" level=info msg="The command [/bin/sh -c rpmbuild -ba /root/assimilation/src/docker/CentOS6/assimilation-cma.spec --define=\"assimversion $GITPATH\"] returned a non-zero code: 1" What you find if you look at the directory structure is that in the source directory there is a directory named build, and under it is another directory named build. This matches the log information above, and the behavior I saw. Here's a summary of what happened: - mkdir -p build - pushd build - mkdir -p build - cd build Build fails because the CMakeLists.txt file is named "../../CMakeLists.txt", NOT "../CMakeLists.txt" -- Alan Robertson / CTO AlanR(a)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(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 6

[opensuse-packaging] How can I graph the memory and disk usage during a build?
by Dave Plater 05 Dec '15

05 Dec '15

Hi, I'm getting intermittent, memory related, OBS build failures with graphics/blender but it builds happily on my humble dual core pentium with 4 gig ram. I've cut them down by building one part, which failed almost every build. I'm playing with a _constraints file but I don't really know what I'm doing. What can I use to graph the memory and disk usage during the build? Thanks Dave Plater -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 3

[opensuse-packaging] Leap, %bcond_with and python?
by Greg Freemyer 05 Dec '15

05 Dec '15

I decided to give Leap a try. My main use case for production is a python app. The app is in OBS, but not in Leap. (I may be the only user, so it is not a big loss.) In trying to get it going I find that python-protobuf is not in Leap either. Now that surprises me. python-protobuf has been in openSUSE since at least 13.1 as a sub-project of protobuf. The Leap protobuf specfile is at: https://build.opensuse.org/package/view_file/openSUSE:Leap:42.1/protobuf/pr… Looking at the specfile for protobuf it says: %if 0%{?suse_version} > 1210 && 0%{?suse_version} != 1315 %bcond_without protobuf_python %else %bcond_with protobuf_python %endif I don't recall coming across bcond before, but that logic seems totally backwards to me. I gather that the suse_version being 1315 in Leap causes the python binding subproject not to be built. questions: - if I hard code "%bcond_without protobuf_python" then the python bindings subproject is built. In plain english, what does %bcond_without mean? - Is there some reason not to build the python bindings for Leap? - Is this just a simple bug that Leap is missing the python binding? I note the specfile from Factory has a different conditional, so just pushing it to Leap would probably do the trick assuming this was just an oversight. ==== # Don't build the python bindings in SLE12 or old distros %if ( 0%{?suse_version} == 1315 && !0%{?is_opensuse} ) || 0%{?suse_version} < 1210 %bcond_with protobuf_python %else %bcond_without protobuf_python %endif ==== Thanks Greg -- Greg Freemyer www.IntelligentAvatar.net -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 9

[opensuse-packaging] Create a rpm-spec which forces a higher version to be replaced be a lower version
by Johannes Weberhofer 02 Dec '15

02 Dec '15

Hello! I have the following problem: A package which has been versioned without number but with a date as version number ( mediawiki-math-1401961173 ) starting some month ago, the package has now a "real" version number (1.26). I'd like to use the new number, but I do not see how I could force a update then... Best regards, Johannes -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 10

[opensuse-packaging] cmake 3.4 fails to pass -I variables
by Olaf Hering 01 Dec '15

01 Dec '15

In packman cmake is linked from its devel project because the version included in the base distro is too old. The devel prj has cmake 3.4.0 since a while. This causes many build failures at least in 13.1, chromaprint for example. It seems the CXX_INCLUDES is not used anymore. Any ideas how to fix cmake? Olaf -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 2