openSUSE Packaging January 2014

packaging@lists.opensuse.org

41 participants
28 discussions

by Matwey V. Kornilov

Hi Dirk and all, Some time in the past, I've integrated my rpmlint check (ErlangCheck.py) to openSUSE's checks. It is in Factory's rpmlint for a long time. Now, I would like to continue and make my check available as option to maintainers in OBS. The dependencies to ErlangCheck.py are python-pybeam, python-construct and python-six. All of them are in Factory for a long time. I need to modify rpmlint-mini to pack parts of python-pybeam, python-construct in order to make ErlangCheck.py working in OBS workers. I see that rpmlint-mini.spec is full of magic. What is the preferred way to pick python modules from %python_sitelib? Should I add another deps.txt and yet another loop...? I can make this is hundred different ways but it is better to ask prior. -- With best regards, Matwey V. Kornilov http://blog.matwey.name xmpp:0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 years, 1 month

[opensuse-packaging] krb5 dependency in Base:System

by Stephan Kulow

Hi, It's currently impossible to submit packages from Base:System due to repo-checker blocking submissions as base packages suddenly require krb5. This is due to a change in libtirpc, that creates a huge cycle. As I'm protecting Factory from having that cycle too, I block such updates. Unfortunately the check hits other packages in the cycle too, so this means: unless this change is reverted, it won't be possible to submit base packages. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 years, 2 months

[opensuse-packaging] Adding a new package which depends on others

by Guillaume Gardet

Hi, I would like to add a new package (pocl) which depends on non-standard packages : * hwloc-devel which is in Factory and developped at devel:libraries:c_c++ * ocl-icd-devel which is in Education * opencl-headers which is in Education * uthash which is in devel:libraries:c_c++ I think devel:libraries:c_c++ or devel:tools projects may be fine for pocl package. Is there anything better? What would be the best way to integrate all of thoses deps? Not sure about the right RPM Group: 'Productivity/Other' or 'System/Libraries'? Guillaume -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 years, 3 months

[opensuse-packaging] apache2-mod_authnz_external depending on Apache version

by vetter＠physik.uni-wuerzburg.de

Hi, this is probably answered before, but I didn't find anything in the archives and Packaging Guidelines. apache2-mod_authnz_external comes upstream in different versions for different apache versions: 3.3.x is for Apache 2.3/2.4 3.2.x is for Apache 2.2 Currently in https://build.opensuse.org/project/show/Apache:Modules we have version 3.2.6, working and compiling only for apache 2.2. So it does not build for newer distros, i.e. openSUSE 13.1 and newer. I branched and updated my branch to 3.3.2. It builds for the openSUSE 13.1 and newer and for most Apache_* targets. What is the best way to bring 3.2.6 for older distros and 3.3.2 for newer distros to the Repositories? I thought about including version number in the package name. That would probably mean to also change name of the existing package? Is there is a way to build different versions depending on either distribution/repository or even better depending on apache version? TIA. -- Mit freundlichen Gruessen, Andreas Vetter -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 years, 3 months

[opensuse-packaging] debuginfo

by Wolfgang Rosenauer

Hi, some years ago I understood some of the stuff but apparently forgot almost everything again. I'm hunting an issue that the Firefox debugsymbols (the google-breakpad ones) which are created in the build step do not match the binaries ending up in the package. This means that crashreports sent to Mozilla cannot be decoded and are useless. Nothing changed in the packages and the way all that is handled and it worked in the past (I cannot exactly tell when it stopped working). For verifying which step of the build could be culprit I've disabled the debuginfo flag in OBS and rebuilt the package. Afterwards the breakpad symbols did match again. I've also verified that stripping the binaries via command strip does not change the ID and therefore stripping itself is not hurting the procedure. Therefore I'm pretty sure something in RPMs find-debuginfo.sh is doing something which changes the breakpad ID. I cannot tell what it is but it wasn't an issue in the past. So the following question: - what does find-debuginfo.sh do which changes the breakpad ID And as a sidequestion out of curiousity: - what is expected when the debuginfo flag is removed from OBS? Do binaries still contain debugsymbols? (apparently no) Do shared libs still contain debugsymbols? (apparently yes) Is that expected? I need to find a solution since the breakpad symbols are actually more useful for me since users don't have to do anything special (using gdb) to report crashes. But the "distro" way is to have the debuginfo packages usable with gdb. If both cannot be achieved at the same time, I'm not sure what to do. Thanks, Wolfgang -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 years, 3 months

[opensuse-packaging] Can a package be updated as a newer version has been released.

by doiggl＠velocitynet.com.au

Hello Can a package be updated[1] as a newer version has been released[2] I tried the newer version and it works[3] Thanks Glenn [1]https://build.opensuse.org/package/show/system:packagemanager/smart [2] https://launchpad.net/smart/+milestone/1.4.1 https://launchpad.net/smart/trunk/1.4.1/+download/smart-1.4.1.tar.bz2 [3]https://build.opensuse.org/package/show/home:doiggl:branches:system:packa… -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 years, 3 months

[opensuse-packaging] NOTE: auto-cleanup of ~:branches: projects is active now!

by Adrian Schröter

To reduce the build load of our build.opensuse.org instance we did activate the new auto-cleanup mechanism of OBS now. This means, by default all default branch projects (home:<ACCOUNT>:branches:...) get an attribute to self-destruct after a given time (currently 60 days). No panic, this is less grave as you may think now, because: * The deletion will happen via a request. If you decline that one the project will stay. * Delete requests will not created if there are still running requests involving this project. * there is the "osc undelete" command to bring the project sources back * You can Opt-Out by removing the OBS:AutoCleanup attribute This will free hopefully lots of build power and make us more responsive again :) thank you adrian -- Adrian Schroeter email: adrian(a)suse.de SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 years, 3 months

[opensuse-packaging] exfat-nofuse in factory or at least consolidated in filesystem

by Bruno Friedmann

For the shake, it would be wonderful to synchronize the different offer we have on obs about exfat. For example have the best of dkms alternative available here https://build.opensuse.org/package/show/home:aevseev/exfat-nofuse-dkms or native https://build.opensuse.org/package/show/home:Akoellh:Kernelmodules/exfat-no… and the fuse exfat-utils https://build.opensuse.org/package/show/home:seife:testing/exfat-utils https://build.opensuse.org/package/view_file/home:seife:testing/fuse-exfat Would be nice to have all effort submitted to filesystems repository and then pushed to factory. Also the different packagers could work together offering a perfect need for our end-users community I know that could submit them to filesystems devel repo, but I would prefer to see a (small) debate on the pro & cons by people who knows what they are doing ;-) Truly yours. -- Bruno Friedmann openSUSE Member GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 years, 3 months

[opensuse-packaging] Modified files? What does it mean?

by Ilya Chernykh

rpm build checks I receive the following message: [ 1168s] /usr/bin/chkstat modified files that are not properly handled! [ 1168s] this will break rpm -V, ask ro for details. What does it mean? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 years, 3 months

[opensuse-packaging] Fwd: Replace setuid bit to cap_net_raw capability

by Andrei Dziahel

Hello list, I'm Ubuntu fugitive and frequent user of mtr utility (https://build.opensuse.org/package/show/network:utilities/mtr). In ubuntu mtr could be run by restricted user, but not in OpenSUSE, complaining with "unable to get raw sockets" message. By adding cap_net_raw capability to /usr/sbin/mtr with > sudo /sbin/setcap cap_net_raw+ep /usr/sbin/mtr (found in libcap-progs package) and then fixing permissions by removing suid bit and making all users run it with > sudo chmod -s+rx /usr/sbin/mtr I've managed to successfully run mtr as unprivileged user. I'm almost sure that capabilities cannot be transferred across rpm which means I should add libcap-progs as a runtime dependency, and update permissions/add capability during package installation. Am I right? Thanks in advance. -- Regards, Andrei Dziahel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 years, 3 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging January 2014