openSUSE Packaging March 2017

packaging@lists.opensuse.org

60 participants
48 discussions

[opensuse-packaging] Selecting GCC version
by Matthias Fehring 03 Apr '18

03 Apr '18

Hello, is there a simple way to force the GCC version used to build a package? openSUSE Leap 42.2 for example uses GCC 4.8 as default compiler, but also provides packages for GCC 5.3. Simply using BuildRequires gcc5 pulls gcc5 in but still uses gcc48 to build the package (especially in Build Service). So is there maybe some Buid Service or spec file switch (bcond) to select the used GCC version? Best greetings Matthias Fehring P.S. Not sure if it is a problem with my browser settings, but when I try to search lists.opensuse.org, it is not possible for me to limit the results to a specific list. Even if I set one, I get results from all lists, what makes searching almost impossible, because most results are commit messages. -- Das Gesetz hat zum Schneckengang verdorben, was Adlerflug geworden wäre. (Friedrich Schiller - Die Räuber) www.buschmann23.de GPG-Key: 0x614C3258 GPG Fingerprint: D786 DDF8 4CA9 00BC CDE0 9A5F CCC5 125D 6E87 D4FC

6 13

[opensuse-packaging] release-notes-openSUSE requires google-opensans-fonts
by Felix Miata 23 Apr '17

23 Apr '17

TW $SUBJECT can't be right, but trying to zypper rm opensans wants to remove releasenotes. :-( -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 8

[opensuse-packaging] devel:language:python Factory/Tumbleweed build target changes
by Todd Rme 16 Apr '17

16 Apr '17

I have just implemented some changes for the various factory targets of devel:languages:python. Most importantly, the openSUSE_Factory_ARM, openSUSE_Factory_PowerPC, and openSUSE_Factory_zSystems build targets have been rolled into the openSUSE_Tumbleweed build target. They are now architectures of openSUSE_Tumbleweed rather than stand-alone repositories. The existing repositories are still there. Assuming there are no problems they will be disabled on in 2 days (Sunday, April 2) and will be deleted in one week (Friday, April 7 2017). Second, the opensuse_factory_staging build target has already been deleted. It was purely a testing repository, so nobody should have been using it to begin with. Thank you, Todd -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 4

[opensuse-packaging] Package publishing: per target or per arch?
by Todd Rme 03 Apr '17

03 Apr '17

I am a bit unclear about the rules for when build packages are pushed to repositories. I have been told that it only occurs for a given build target when all architectures for that target have finished building. However, when I look at download.opensuse.org, it seems packages are getting pushed from one architecture while another is still building according to build.opensuse.org. So I was hoping to get a better understanding of how OSC decides whether to publish a package. It is important because it has an impact on how we structure our build targets. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 2

[opensuse-packaging] Need help with gcc7 error
by Dave Plater 31 Mar '17

31 Mar '17

Hi, I've been running around in circles trying to fix multimedia:libs/libdbus-c++'s gcc7 build errors, in home:plater. I fixed one which was a type conversion error but I'm struggling with this: In file included from ../../include/dbus-c++/server.h:34:0, from ../../include/dbus-c++/dbus.h:33, from propsgs-server.h:4, from propsgs-server.cpp:1: ../../include/dbus-c++/dispatcher.h: In static member function 'static void DBus::Threading<Mx, Cv>::init()': ../../include/dbus-c++/dispatcher.h:262:5: error: no matching function for call to '_init_threading(DBus::Mutex* (&)(), void (&)(DBus::Mutex*), void (&)(DBus::Mutex*), void (&)(DBus::Mutex*), DBus::CondVar* (&)(), void (&)(DBus::CondVar*), void (&)(DBus::CondVar*, DBus::Mutex*), bool (&)(DBus::CondVar*, DBus::Mutex*, int), void (&)(DBus::CondVar*), void (&)(DBus::CondVar*))' ); ^ ../../include/dbus-c++/dispatcher.h:247:13: note: candidate: void DBus::_init_threading() void DXXAPI _init_threading(); ^~~~~~~~~~~~~~~ ../../include/dbus-c++/dispatcher.h:247:13: note: candidate expects 0 arguments, 10 provided ../../include/dbus-c++/dispatcher.h:249:13: note: candidate: void DBus::_init_threading(DBus::MutexNewFn, DBus::MutexFreeFn, DBus::MutexLockFn, DBus::MutexUnlockFn, DBus::CondVarNewFn, DBus::CondVarFreeFn, DBus::CondVarWaitFn, DBus::CondVarWaitTimeoutFn, DBus::CondVarWakeOneFn, DBus::CondVarWakeAllFn) <near match> void DXXAPI _init_threading( ^~~~~~~~~~~~~~~ propsgs-server.cpp doesn't even call DBus::_init_threading() and although searching brings nothing up, if this isn't a gcc7 bug. These problems only occur in tests and examples so I can disable them but I would really like to understand this build error. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 20

[opensuse-packaging] -Wl,-rpath={%_libdir} has no effect when building using OBS
by Xing 31 Mar '17

31 Mar '17

Dear All, I'm trying to build and package openbabel. It needs the "RUNPATH" tag to run correctly or the "obabel" command will not find the plugin directories. Openbabel uses CMAKE and on OBS "-DCMAKE_SKIP_RPATH=ON" is set automatically by the %cmake marco. I can use "-DCMAKE_C_FLAGS="-Wl,-rpath={%_libdir}" and "-DCMAKE_CXX_FLAGS=-Wl,-rpath={%_libdir}" to force passing the flags to gcc and build with RUNPATH on my local computer directly (without using "osc build "). However it gcc will just ignore the "-Wl,-rpath" flag when I use "osc build" or the online building service and no RUNPATH information is written to the binary and .so files. Does any one know why gcc behaves differently like this (invoke directly vs via OBS) and how to insert the "RUNPATH" information into the final .rpm files? Thanks and best wishes, Xing -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 7

Re: [opensuse-packaging] Service for bitbucket
by Axel Braun 29 Mar '17

29 Mar '17

Hallo Frank, Am Montag, 27. März 2017, 14:47:37 CEST schrieb Frank Schreiner: > On Sonntag, 26. März 2017 10:48:52 CEST you wrote: > > Am Sonntag, 26. März 2017, 10:17:28 CEST schrieb Adrian Schröter: > > > On Sonntag, 26. März 2017, 09:56:06 CEST wrote Axel Braun: > > > > Morning all, > > > > > > > > does anyone know of an OBS Service to pull sources from bitbucket? > > > > I had a look at > > > > http://openbuildservice.org/help/manuals/obs-reference-guide/ > > > > cha.obs.source_service.html > > > > but there is nothing listed - overview of available sources would be > > > > great! > > > > > > It is not supported yet, but it should not be too hard to add. > > > > > > Just have a look at the tar/obs_scm service. But please look in this > > > repo > > > > > > here atm: > > > https://github.com/M0ses/obs-service-tar_scm/ > > > > Thanks Adrian, that helped a lot! > > Bitbucket talks hg, so that helps as well > > > > First test was half way successful, I could clone the source tree, but the > > service was looking for a 'hgreview': > > ... > > Command failed(255): "*** failed to import extension hgreview: No module > > named hgreview\nhg: parse error at 0: syntax error in revset '*** failed > > to > > import extension hgreview: No module named hgreview\n327'\n" > > Aborting: service call failed: /usr/lib/obs/service/tar_scm --scm hg > > --url > > https://bitbucket.org/jonaswolz/yajhfc --filename yajhfc --extension > > tar.bz > > -- outdir > > /home/docb/buildservice/home:DocB/yajhfc/tmpFeOoUT.tar_scm.service .... > > > > So is OBS Service expecting a module hgreview, or does the service need to > > import this (python) module? > > No, as far as I can see obs-service-tar_scm is only expecting a working "hg" > command installed. We are not using any hg related python libs. > > The following hg calls are executed by tar_scm > > ['hg', 'update', self.revision], > ['hg', 'clone', self.url, self.clone_dir] > ['hg', 'pull'], cwd=self.clone_dir, > ['hg', 'id', '-n'], self.clone_dir)[1] > ['hg', 'log', ...] > > for more information have a look into > > /usr/lib/obs/service/TarSCM/scm/hg.py > > For me, it looks like a broken installation of hg tools, as all of the above > commands worked well on our appliance. mercurial is installed and working. I can clone a git repositry from bitbucket, no problem when I run hg clone manually: hg clone https://bitbucket.org/jonaswolz/yajhfc *** failed to import extension hgreview: No module named hgreview So, for whatever reason my installation asks for this hgreview (funny enough, I had packed this some time ago myself) https://build.opensuse.org/package/show/devel:tools:scm/hgreview As this is now fixed, the service file works as well :-) Now I need to find out how to get the version number (0.6.1) into the filename - currently it seems to set the revision (327) Cheers Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] directories not owned by a package:
by Christian 29 Mar '17

29 Mar '17

Hi, don't think it is a good idea to have several packages owning 'same' directory, isn't it ? ovhpc-01:/usr/lib/tmpfiles.d # rpm -q --whatprovides $(pwd) dmraid-1.0.0.rc16-34.3.x86_64 clamav-0.99.2-25.1.x86_64 amavisd-new-2.8.1-11.1.x86_64 screen-4.0.4-21.2.x86_64 lvm2-2.02.120-72.8.x86_64 dirmngr-1.1.1-10.1.x86_64 systemd-228-135.1.x86_64 which one is the correct one ? and how to fix build error: [ 26s] xyzserver-1.67-0.x86_64.rpm: directories not owned by a package: [ 26s] - /usr/lib/tmpfiles.d without using... %dir %{_prefix}/lib/tmpfiles.d ...and producing a further package providing same DIR. Cheers -- Christian ------------------------------------------------------------ https://join.worldcommunitygrid.org?recruiterId=177038 ------------------------------------------------------------ http://www.sc24.de - Sportbekleidung ------------------------------------------------------------ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 11

[opensuse-packaging] Have you a link to the source code which builds the isos [openSUSE-xxxxx-NET-x86_64.iso]
by doiggl＠velocitynet.com.au 28 Mar '17

28 Mar '17

Hello, Have you a link to the source code which builds the iso[1] cd and links in the oss and non-oss parts to the build. It has links to /non-oss/ /oss/ Questions: - which files establish the links used in the built iso for /oss/ and /non-oss/? - Have you a link to a build log of a sucessful iso build ? Thanks --Glenn [1] e.g release for: http://ftp.gwdg.de/pub/opensuse/distribution/leap/42.2/iso/openSUSE-Leap-42… it has links for oss and non-oss in iso # other https://en.opensuse.org/Portal:Factory -- 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] Wrong naming of python-python-axolotl in the spec: python-python_axolotl (note the _)?
by Johannes Kastl 28 Mar '17

28 Mar '17

Hi guys, I just stumbled upon the python-python-axolotl package in d:l:p today. I linkpac'd it and it built, but was not enough to fulfill a dependency (gajim-plugin-gajim-omemo needs the axolotl stuff). I checked the spec and found a mismatch: devel:languages:python/python-python-axolotl The package is called python-python-axolotl The spec is called python-python-axolotl.spec In the spec, the name of the package is python-python_axolotl (note the "_" instead of the "-" ). Is there any reason for that? I changed my copy to have the same name in the spec as the package, and it builds and it works. (I also updated it to 0.1.39, but that's just a side note). If desired, I can sr it to d:l:p. But maybe there should be an additional "Obsoletes python-python_axolotl" in there, to make sure the transition smooth. Johannes

2 2

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging March 2017