December 2017 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Moving kubernetes and friends to CaaSP specific repos
by Jordi Massaguer Pla 20 Dec '17

20 Dec '17

Hi, we are moving kubernetes package along with others* that are CaaSP specific (Container as a Service Platform), from Virtualization:containers to the CaaSP repo devel:CaaSP:Head:ControllerNode. The reason is that these packages were duplicated on both projects, V:c and d:C:H:CN and that was creating confusion. The packages will effectively be removed from V:c on January 19th, thus if you have any tool that depends on them, please update it to use the CaaSP repo. Sorry for any inconvenience and we hope this will remove the confusion on where these packages are developed. Please forward this announcement to who ever you think can be interested, including mailing lists or user groups. Regards jordi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 1

[opensuse-packaging] Re: RFC Generic Packaging for Languages that have vendor/ Trees
by Jordi Massaguer Pla 20 Dec '17

20 Dec '17

> Provides: bundled(rust:nix) = 0.8.1 > > Or something more involved to be extra paranoid: > > Provides: bundled(rust:registry+https://github.com/rust-lang/crates.io-index:nix) = 0.8.1 > > I like the "Provides: bundled" idea. We can even use the commit sha instead of the version number on those libraries that we vendor from a specific commit. -- 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] No %if inside %with?
by Sebastian 18 Dec '17

18 Dec '17

Hi, For the package python-termstyle[0] I want to deactivate the tests because of problems with the default encoding which I can't solve. The requirement of the project maintainers is to not comment them out but change the `%bcond_without tests` to `%bcond_with tests`. But now I have a problem inside %check, which looks like this: %if %{with tests} %check export LANG=C.UTF-8 %ifpython2 python2 setup.py test -s test2 %endif %ifpython3 python3 setup.py test -s test3 %endif %endif With `%bcond_without tests`, rpm does not complain (the checks fail, but we know that already), but when I use `%bcond_with tests` I get: [ 52s] error: /home/abuild/rpmbuild/SOURCES/python-termstyle.spec:72: Got a %endif with no %if Where lne 72 is the last %endif in that section. If I comment out both %ifpythons, then it works. Does someone maybe has a clue why this is happening? Sebastian [0]: https://build.opensuse.org/package/show/home:sebix:branches:devel:languages… -- python programming - mail server - photo - video - https://sebix.at cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers

5 6

[opensuse-packaging] Converting a package to singlespec: two questions
by Lee Duncan 13 Dec '17

13 Dec '17

Hello: I am converting a package, targetcli-fb, to singlespec. I have already converted the packages it relies on. I have a couple of problems: 1. The package is called "targetcli-fb". Since this does not follow the "pyton-PACKAGENAME" convention, what should the python3 version of the package be called? Perhaps something like targetcli-fb-python3? or "python3-targetcli-fb"? I don't like either. 2. This package installs some stuff that should be invariant with respect to python version, such as the directory /etc/target, and the systemd service unit file /usr/lib/systemd/system/targetcli.service. I know I can use update-alternatives to handle the man pages and binaries (scripts) in a singlespec package, but I do not think that approach will work for a data directory nor for a systemd unit file. Ideally, as I think about it, I do not want users to be able to install both the python2 and the python3 version of this package at the same time. Does it make sense to do that with a singlespec package? If so, how do I specify this in the SPEC file? I'm tempted to just create a separate package, make it singlespec and python3 only. But that doesn't seem much better. -- Lee Duncan SUSE Labs -- 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] nonspammy KDE builds?
by Mathias Homann 12 Dec '17

12 Dec '17

Hi, I have a failing build in home:lemmy04/digikam. HOW can i make the build process NOT throw up gigabytes of ascii progress all over the logfile so that I can actually FIND the error? I've already changed VERBOSE=1 to VERBOSE=0 in the spec file, which did ... exactly... nothing. Anyone got any ideas? Thanks Mathias -- Mathias Homann Senior Systems Engineer, IT Consultant. IT Trainer Mathias.Homann(a)openSUSE.org http://www.tuxonline.tech gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

12 26

[opensuse-packaging] Packages enabling their systemd services at their own
by Thorsten Kukuk 12 Dec '17

12 Dec '17

Hi, the official mechanismus to enable systemd services by default during installation is, to use the systemd preset functionallty. Unfortunately, some packages still enable their services at their own by calling systemctl enable in the %post install section. This will break in the future for fresh installations! Why? We have a problem with dependencies for systemd, dependency loops and packages, where we are not able to enable them with the preset mechanism during initial installation. The reason is, that systemd with it's many dependencies can only be installed late, but some packages have to be installed earlier. The same is true for build dependencies. If we require a PreReq systemd for all packages having systemd units, we will end in a dependency loop nightmare. Instead, we decided, that we will call a systemctl preset-all in the %posttrans of systemd-presets-branding-* packages for fresh installations. Since we do this only for fresh installations, old init scripts and all the other stuff does not matter. But all packages, which do not follow our policy using the preset-branding package, but enabling themself in the post install section, will of course now fail. Which also leads to a better package quality, since all the hacks have now to be fixed! Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 17

[opensuse-packaging] OBS: Temporary failure in name resolutio
by Michael Ströder 10 Dec '17

10 Dec '17

HI! For all Factory and Tumbleweed repos I get build failures with this message: [ 34s] Download error on https://pypi.python.org/simple/: [Errno -3] Temporary failure in name resolution -- Some packages may not be found! Re-triggering the build several times within a longer timespan did not help. It works for SLES and Leap build targets. Any clue what's wrong there? Ciao, Michael.

2 2

[opensuse-packaging] Is their a script to produce the install openSUSE isos, ? if so, where is it located and is there any documentation about it ?
by doiggl＠velocitynet.com.au 08 Dec '17

08 Dec '17

Hello, Is their a script to produce the install isos, ? if so, where is it located and is there any documentation about it ? I Want to know how it is constructed. Thanks --Glenn http://ftp5.gwdg.de/pub/opensuse/distribution/leap/15.0/iso/ openSUSE-Leap-15.0-NET-x86_64-Current.iso openSUSE-Leap-15.0-DVD-x86_64-Current.iso -- 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 do not use otherproviders() anymore
by Michael Schroeder 06 Dec '17

06 Dec '17

Hi Packagers, I was asked to clarify if/when "Conflicts: otherproviders(...)" has to be used. The answer is that it should not be used at all anymore. Upstream rpm allows self-conflicts since the year 2011 (commit b9f5062c227f4a8feff83c0ee1cde2929da7cd3e), it is included in SLES-12 (rpm-4.11.2) but not SLES-11 (rpm-4.4.2.3). So if you're not targeting SLES-11 it's safe to use a real self-conflict instead of that ugly otherproviders() workaround. The advantage is that rpm will also understand it and not just zypper/libzypp. Cheers, Michael. -- Michael Schroeder mls(a)suse.de SUSE LINUX GmbH, GF Jeff Hawn, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- 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] Can reiser4progs[ be updated to reiser4progs-1.2.1.tar.gz please. -https://build.opensuse.org/package/show/filesystems/reiser4progs
by doiggl＠velocitynet.com.au 04 Dec '17

04 Dec '17

Hello, Can reiser4progs[1] be updated to reiser4progs-1.2.1.tar.gz please. [1] https://build.opensuse.org/package/show/filesystems/reiser4progs - https://sourceforge.net/projects/reiser4/files/reiser4-utils/reiser4progs/r… Info: http://www.spinics.net/lists/reiserfs-devel/msg05652.html Thanks --Glenn -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 2