January 2017 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] need help to fix postgresql related troubles
by Bruno Friedmann 23 Jan '17

23 Jan '17

Hello my buddies :-) I need a bit of help to understand (at least just my concerning part) of something I would qualify as "messy" Here's what I normally understand of normal submission In server:database:postgresql, I've postgresql-plr disabled build package which auto-created (+/- sometimes I need one of server:database:postgresql maintainer to create a link when a new version comes.) Now, after an update to last upstream version, I was in the process to send sr to factory but found uncomprehensible things for my part time contributor. s:d:p/postgresql91-plr and s:d:p/postgresql92-plr are link back to s:d:p/postgresql-plr We can let them as they are, no more present in openSUSE:Factory. Now I've two specials s:d:p/postgresql93-plr and s:d:p/postgresql94-plr which are marked as devel package for Factory but they link to https://build.opensuse.org/package/show/openSUSE:Factory/postgresql94-plr As such they are not "magically" updated when I update postgresql-plr and never propose a submission to Factory ? This is what I don't understand ... How can we fix those Also both of them have only the corresponding PG_Version only spec and changes files. Also I would like to submit the 2 missing postgresql95-plr and postgresql96- plr. What is the best way to do it ? Thanks for your help https://build.opensuse.org/package/show/server:database:postgresql/postgres… -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship 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

2 3

[opensuse-packaging] prefered libjawt.so in openSUSE_13.2 needs to be specified
by Olaf Hering 19 Jan '17

19 Jan '17

In Packman the pkg Extra/IfcOpenShell can not build due to a missing Prefer in the global 13.2 prjconf: have choice for libjawt.so()(64bit) needed by vtk-devel: java-1_7_0-openjdk-headless java-1_8_0-openjdk-devel java-1_8_0-openjdk java-1_7_0-openjdk-bootstrap-headless have choice for libjawt.so(SUNWprivate_1.1)(64bit) needed by vtk-devel: java-1_7_0-openjdk-headless java-1_8_0-openjdk-devel java-1_8_0-openjdk java-1_7_0-openjdk-bootstrap-headless I have not followed this pkg, appearently this bug was introduced after 2016-11-04. Olaf

2 3

[opensuse-packaging] RFC: moving from separate users to user monitoring for everything
by Lars Vogdt 17 Jan '17

17 Jan '17

Hi I'm maintaining some packages in the server:monitoring repository and want to make my live a bit easier in the future (and I hope that also our users will benefit from it)... At the moment, we follow upstream very close regarding the names of the users and groups used for monitoring related packages (and especially daemons): Package | User(s) | Group(s) ------------------------------------------------ icinga | icinga | icinga, icingacmd naemon | naemon | naemon nagios | nagios | nagios, nagcmd shinken | shinken | shinken zabbix | zabbix, zabbixs | zabbix, zabbixs Please note that at least icinga, naemon, nagios and shinken are very similar and even their configuration is more or less compatible. So you can easily migrate between the different daemons without too much administration overhead. While - from a security stand point - the current approach to use the upstream users/groups is very smart, as it allows you to run multiple daemons on a single host that can not influence each other, it becomes more and more a nightmare from a packaging (and customer) view: A lot of 3rd party applications want to get access to sockets, directories or other parts, that belong to the corresponding daemon (check_mk*, pnp4nagios, BPView, {nagios-,icinga-www} - as both can run also on the other core, nagiosgrapher, nagiosgraph, nagserv, nsca, ... just to name a few). As result, there have to be either "permission" files to change the ownerships after installation of sucha 3rd party application - or even separate $pkg-$daemon sub-packages that come with the correct owner:group setup for the $daemon part. The problem with "permissions": * there is a small, but important time frame between installing a package update and executing "chkstat --system --set" on the host to correct the ownerships again * it needs additional openSUSE specific READMEs and support for users that are not aware of the fact that they might need to edit a file, that is not mentioned upstream, before the application works * our security team does not seem to like the approach ;-) The problem with a separate sub-package: * Some (older?) openSUSE distribution checks had problems with files and directories that were packaged in multiple sub-packages (even if the sub-packages conflicted with each other). Which made it impossible to get the package in Factory at all. * Even with "supplements" and "suggests", people might have to choose their sub-package manually, if there is just a small mistake. * it becomes a packagers nightmare to adapt all the available plugins and 3rd party apps for all the possible monitoring daemons... So instead of maintaining a growing list of packages that require more and more time for packaging and maintenance (to support users by providing help to install 3rd party app X together with daemon Y), I like to get your feedback about the following approach: * use only the following users - at least for the packages icinga, nagios, naemon and shinken: monitoring * use only the following main group: monitoring * use only the following sub-group: monitorcmd That would allow the 3rd party applications/packages to use the same user/group without any modifications. From a security stand point, this might be a nightmare, correct. But please think how often a user is running more than one monitoring solution in parallel on the same machine? Instead: how often might it be that a user wants to migrate from one monitoring solution to another and has to go through a lot of config files and filesystem permissions before he can start with the real migration? We need to document the new "generic/default monitoring user/group on openSUSE", of course. But we also would need more and more documentation if we follow the current approach - so I do not see this as negative impact. An alternative might be to reduce the available monitoring packages for openSUSE to get more time for packaging and documentation if we stay on the current system. But I like freedome, so I do not like this point ;-) As far as I found out (but I did only a small research), other distributions like Debian are using also just one set of monitoring users/groups for the compatible monitoring applications. If someone knows more, I would be very happy to hear. So my question is: what is your opinion? CU, Lars -- 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] how to avoid SUSE-Backports-policy-SLE-conflict
by Olaf Hering 17 Jan '17

17 Jan '17

How is this supposed to be fixed? [ 86s] build-compare.noarch: E: SUSE-Backports-policy-SLE-conflict (Badness: 10000) Package with name build-compare already in SLE This seems to happen with <repository name="SLE_12"> <path project="openSUSE.org:openSUSE:Backports:SLE-12-SP2" repository="standard"/> <arch>x86_64</arch> </repository> Olaf

6 25

[opensuse-packaging] sync of tumbleweed repos with factory project
by Jordi Massaguer Pla 17 Jan '17

17 Jan '17

Hi, I am not sure if this is the right m.l. so if not, please advice me where to send this question. I am having some trouble with an image that we are creating in obs that has openSUSE:Factory as a repo. The problem happens when we try to, when booting the image on libvirtd, install a package that requires libsystemd-devel, because in the image we have version 232 (which comes from the obs repo), but in the public repo we have version 228, so zypper "complains" and "advices" to do a downgrade. Are other people having this same kind of problem? Is this somehow expected? How long should it take for a package to be in the tumbleweed repo? Should I build my image in a different way? thanks public repo: http://download.opensuse.org/tumbleweed/repo/oss/suse/x86_64/ the image: https://build.opensuse.org/package/show/Virtualization:containers:images:KV… -- 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] Please help me with kicad-doc-4.0.5 build
by Dave Plater 12 Jan '17

12 Jan '17

I have a problem where kicad-doc update doesn't build in obs home:plater/kicad-doc but builds on my local machine. Using build with a chrooted build I get the same error as in obs but if I then chroot into the build, the command that fails succeeds. In fact I can make clean and make and it succeeds. How can I nail down this problem? My knowledge of dblatex is weak maybe somebody can look at the build log. I've enabled every debug option in dblatex that I can find. 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

2 2

[opensuse-packaging] build of osp-toolkit fails only for Factory
by Michael Ströder 11 Jan '17

11 Jan '17

HI! Why does the build of osp-toolkit fails only for Factory? https://build.opensuse.org/package/show/network:telephony/osp-toolkit Are there relevant differences in compiler version and options? Any way to work around this (preferrably without patching upstream source)? Ciao, Michael.

2 1

[opensuse-packaging] Need help with the failure of "build"
by Dave Plater 11 Jan '17

11 Jan '17

Hi, I've limited internet bandwidth so I can't use osc build, I normally survive with reading online build logs to find problems. Now I've a problem with kicad-docs where a dependency causes a failure but it passes on my local machine. To fix this I'm using "build" direct with my local /var/cache/zypp/packages and the dvd image as the main repos and the update and oss online repos for anything that's not cached. I get a failure after the packages are downloaded when the system is supposed to be installed: [ 73s] [1/29] preinstalling filesystem... [ 73s] error: open of build-root/.init_b_cache/rpms/filesystem.rpm failed: No such file or directory [ 73s] rpm2cpio: build-root/.init_b_cache/rpms/filesystem.rpm: No such file or directory [ 73s] [2/29] preinstalling glibc... [ 73s] /usr/lib/build/init_buildsystem: line 218: cd: build-root: No such file or directory "build-root" is the buildroot specified by "--root build-root". My command line is: build --repo /var/cache/zypp/packages/ --repo /data/packages/RPMS/ --repo /mnt --repo ftp://ftp.up.ac.za/mirrors/opensuse/opensuse/update/leap/42.2/oss --repo http://download.opensuse.org/distribution/leap/42.2/repo/oss/suse/ --root build-root SPECS/kicad-doc.spec My rpmbuild setup points to /data/packages which contains the SPECS, BUILDROOT etc directories due to my root filesystem being on one partition. /etc/rpm/macros.local contains the lines: %vendor "davepl@Arbuthnot" %_topdir /data/packages 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

1 0

[opensuse-packaging] What can cause this script to fail in Factory/Tumbleweed.
by Dave Plater 10 Jan '17

10 Jan '17

I'm having a problem dvdisaster's bash-based-configure script where it checks for make. It fails in Factory but passes in 42.2 downwards. This is it: # Check for tools # function REQUIRE_GMAKE() { if test -n "$cfg_help_mode"; then return 0 fi echo -n "Checking for gmake: " if (gmake -v | grep "GNU Make") > /dev/null 2>&1 ; then echo "yes" echo "MAKE = `which gmake`" >>Makefile.config return 0 fi; if (make -v | grep "GNU Make") > /dev/null 2>&1 ; then echo "yes" echo "MAKE = `which make`" >>Makefile.config return 0 fi; echo "no" echo "This package requires GNU make (gmake)." exit 1; } The output of make -v is identical in Tumbleweed and 42.2 all I can think of is either bash or grep have changed. I worked around the problem by patching in "echo "MAKE = `which make`" >>Makefile.config" as an else statement but I'd love to know what is actually wrong. 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

3 8

[opensuse-packaging] How can I find the python package to satisfy a missing python script dependency?
by Dave Plater 10 Jan '17

10 Jan '17

The script with this header works on my local machine but fails in obs, how can I find the python package that provides xml.etree.ElementTree : import xml.etree.ElementTree as etree import os import shutil import re from subprocess import call I've googled xml.etree.ElementTree and found that it exists as ElementTree.py, from that I used find to locate it under /usr/lib64/python2.7/ and used rpm to locate the package which turns out to be "python-xml" but I thought that maybe there was a python tool that could parse the headers and give me the package name. 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

3 4