November 2014 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Usage of gpg_verify in .spec files
by Dimstar / Dominique Leuenberger 17 Nov '14

17 Nov '14

Hi geeko packagers, Please note that we are receiving a new version of gpg (2.1.0) in Factory probably rather soon... One thing to note is that the current version of %gpg_verify passes --gpg2 to the command, which is no longer understood. There are obviously two ways to fix it: - Fix %gpg_verify to no longer pass --gpg; surely simple, but I don't prefer the solution - Remove the gpg_verify commands from the .spec files; In fact, usage of gpg_verify has been deprecated in favor of the obs service source_validator (which runs at each osc ci call or you can call it using osc service lr source_validator). As we already have implicit verification of the signatures there, it is of no use to verify the signature during build again. Which is also the reason why option one is not that appealing. Can I please ask the package maintainers to work with us and eliminate this wherever it is still used in Factory? Thanks a lot! -- Dimstar / Dominique Leuenberger <dimstar(a)opensuse.org> -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 7

[opensuse-packaging] [Nodejs] Can we give some more love and care?
by marguerite 13 Nov '14

13 Nov '14

Hi, This is a complaint. The mess in this repo still happens. Just saw a bug report filed about npm for Tumbleweed, and fixed another bunch of packages again. Although most of the mess come from the fragment of nodejs package system, the massive & strict (introduced by nodejs-packaging) dependencies, and the migration from macros.nodejs to nodejs-packagin, there're still things we can take care of: 0. factory auto SRs. If it's accepted, that's okay. But if it's rejected, please at least take some time to see what's wrong and fix it. 1. care. I saw two of the commits that said "use nodejs-packaging to package" but no BuildRequires: nodejs-packaging at all. That shouldn't happen. 2. changelog. I saw patches were not mentioned in many of the rejected auto SRs. And what's most important: please do not alter the packages directly. because: 0. other maintainers will not receive any notification for that. so no one else will be awared of what's going on, review, and cover for us. 1. it'll not forward to Factory. that's why auto SRs were triggered. Most of the times, auto SRs may be likely to be ignored. I know there are so many packages in this repo, which makes such suggestion ridiculous, but think about devel:languages:python (it has many more packages I think). Again we can develop a script to do the SRs from branched projects to the devel repo itself. And a few more things: 0. wiki should be updated. because the new nodejs-packaging tool 1. Is there any function in nodejs-packaging that can alter the auto detected/parsed dependencies? I remember I saw such things in Fedora. now we use patches, which is hard to track and mostly do a simple same thing. 2. Is nodejs so strict about package versions? because I saw many SRs trying to submit old versions of packages, and we did lots of rollback things. How did we verify if a package really can't use a newer version? and what to do/how to do when it needs to have two versions of the same packages in our repo (I saw two situations: one just renames the module to, like, nan-0_8; another uses update-alternatives)? we may need to discuss and develop a policy for that. Marguerite

2 1

[opensuse-packaging] Faling build for Tumbleweed build target
by Todd Rme 12 Nov '14

12 Nov '14

It looks like at least some repositories are having issues with the Tumbleweed build target. Packages that work fine for the openSUSE_Factory snapshot build target are failing to build for openSUSE_Tumbleweed. The failure in all cases is "error: Failed build dependencies:" In all cases, this failure always happens for BuildRequires that are enabled only for openSUSE versions > 13.1. The dependencies in all cases are available and build properly. The really strange thing is that when I branch the package, it builds just fine. It also builds fine when I try to build locally. And forcing a rebuild does not work. So this has made debugging the problem hard, since I don't want to potentially break other working build targets. Does anyone know what might be going on and how it can be fixed? Here is an example: https://build.opensuse.org/package/show/devel:languages:python/python-matpl… The failure: [ 318s] + exec rpmbuild -ba --define '_srcdefattr (-,root,root)' --nosignature --define '_build_create_debug 1' --define 'disturl obs://build.opensuse.org/devel:languages:python/openSUSE_Tumbleweed/cb5af0d…' /home/abuild/rpmbuild/SOURCES/python-matplotlib.spec [ 320s] error: Failed build dependencies: [ 320s] python-qt5 is needed by python-matplotlib-1.4.2-89.2.i586 [ 320s] python-qt5-devel is needed by python-matplotlib-1.4.2-89.2.i586 The relevant portion of the spec file is line 76-79: %if 0%{?suse_version} > 1310 BuildRequires: python-qt5 BuildRequires: python-qt5-devel %endif -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

Re: [opensuse-packaging] systemd service presets: branding files or packages?
by Stanislav Brabec 11 Nov '14

11 Nov '14

Andrei Borzenkov wrote: > В Tue, 11 Nov 2014 17:33:02 +0100 > Stanislav Brabec <sbrabec(a)suse.cz> пишет: > Just like using preset if it is called on update. It will not overwrite > current state if it is called only on initial install. The only > difference between preset and enable is where decision comes from. Imagine preset like a way to implement "Reset to default" button. Without preset, there can not be "Reset to default". > But somehow I'm not sure I follow the logic. If installed package is > not functional without active service, service should be statically > enabled. If it is intended to leave decision to enable service to > admin, package should be useable without active service. The question her is not "Activate this service?" but "Activate this service by package preset or branding preset?" Or even better: Where should be the border line between "package is not functional without active service" (and preset should be probably part of the package) and "package activation should be brand-able" (and preset should be probably part of the branding). > > Package should use presets. Then %service_add_post is sufficient. It > > does one time set to preset, and on the next update, service will stay > > in the previous state, > > Not because it is preset, but simply because preset is called only on > initial install. Correct. The current implementation %service_add_post does it in smart way only for presets.* If somebody adds "systemctl enable" to %post, then one-shot activation needs to be handled by package maintainer. (*) Well, the smart way works only if the preset is introduced together with the service. Hopefully, there is an easy trick to introduce one-time preset call even if preset is introduced later: if [ $1 -gt 1 ] ; then if ! {test if preset exists in file or branding file} ; then echo -n "" >/run/rpm-%{name}-update-{service name}-new-in-upgrade fi fi > If security team has to approve each preset for each package, what > advantage shipping them as part of each package has? Policy change for particular package does not involve change of all existing branding files. (openSUSE distributes just one branding file, but authors of derived products can create their own branding files.) -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec(a)suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- 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] Fwd: Branching a specific revision of package
by Greg Freemyer 11 Nov '14

11 Nov '14

All, Given merge conflicts in an older package revision, how can I branch the older revision of the package regardless? == details For one of my tools I need to have python-psutil v1.2.1 available in my repo. That is in rev 26 of d:l:p python-psutil, so I tried: > osc bco -r 26 devel:languages:python python-psutil But I'm getting an error: "Server returned an error: HTTP Error 400: Bad Request conflict in file python-psutil.spec" Adding -f (force) doesn't help. -- For now I just used "osc mkpac" to create a new package and populated it with the old files, but branching the old revision I assume is preferred. Thanks Greg -- Greg Freemyer -- 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] SUSE:SLE-12:GA project is there
by Adrian Schröter 07 Nov '14

07 Nov '14

Good news everyone .... more work for OBS and all of us :) SLE 12 got imported. Right now only the x86_64 architecture is usable. ppc64le will come when we have the hardware in place. SLE 12 got added to the simple default target list in webui or when you want to add it manually use SUSE:SLE-12:GA / standard repository. Please note that the former existing SUSE:SLE-12 project got removed. -- 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

10 15

[opensuse-packaging] Re: Cinnamon Stable repo for openSUSE X11:Cinnamon?
by marguerite 06 Nov '14

06 Nov '14

Hi, Cinnamon 2.4.0 is now landing in X11:Cinnamon:Factory. * MDM not updated yet (need a new splash instead of the old ugly one) * Artwork not updated yet. * Some package like patterns-openSUSE-Cinnamon not created yet. (so you have to install package by package if you want to be the early bird. maybe tomorrow) When all done, packages will be copied and the new Current repo will launch. The launch note will not be published in opensuse-"packaging", but in openSUSE-"factory" ML. Not working: cinnamon-bluetooth. because it's written to be used with gnome-bluetooth 3.8. We have 3.10 for a long time. And I have no plan to fix it by providing an outdated gnome-bluetooth 3.8 as Linux Mint does. NOTICE: Currently the whole thing is not tested, at all. Because I'm updating my Factory box so zypper can't do the two things together. PS: X11:Cinnamon:Current will be the "Stable" branch you asked for. It'll track upstream "stable" releases at https://github.com/linuxmint according to the version number scheme you mentioned in previous posts. X11:Cinnamon:Factory then goes it's own way...eg: another 2.5.0 may be landing there because I myself have neither battery nor bluetooth devices :-) That is, there'll be no such thing like X11:Cinnamon:Stable which would track like: what Linux Mint uses. Because I have made my point of view clear on our wiki: Cinnamon is _NOT_ a desktop environment. It's a community project by Linux Mint. The best experience you can get will always from Linux Mint itself, if you don't care deb system or outdated fundamental softwares. Clearly I'm an openSUSE user, so I'll try to provide the best I can produce using openSUSE instead of simulating another distribution. That is, such way, eg, the way Arch Linux used to provide like Unity by creating every packages Ubuntu uses, is out of my way. We're not faking Linux Mint, but making an openSUSE spin. (Of course, bugfix from those versions Linux Mint use, should be added if someone open bugreports for any specific bug) X11:Cinnamon:* are development repositories, why manually add "freeze" for it? Marguerite

1 0

[opensuse-packaging] Missing packages for SLE_12 target
by Dmitry Roshchin 06 Nov '14

06 Nov '14

Some packages from SUSE:SLE-12:GA are missing for SLE_12 target. For example glew, wxWidgets-3_0 (nothing provides <package name>). Target: <repository name="SLE_12"> <path project="SUSE:SLE-12:GA" repository="standard"/> <arch>x86_64</arch> </repository> What is wrong? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

8 11

[opensuse-packaging] What provides this-is-only-for-build-envs?
by Andrei Borzenkov 05 Nov '14

05 Nov '14

bor@opensuse:~/obs/home:arvidjaar:bnc:902612:13.1/systemd> osc results -v standard i586 unresolvable: nothing provides this-is-only-for-build-envs needed by libudev-mini1 nothing provides this-is-only-for-build-envs needed by udev-mini standard x86_64 unresolvable: nothing provides this-is-only-for-build-envs needed by libudev-mini1 nothing provides this-is-only-for-build-envs needed by udev-mini ports aarch64 blocked: systemd-mini, libudev-mini1, udev-mini ports armv7l blocked: systemd-mini, libudev-mini1, udev-mini ports ppc succeeded(unpublished) ports ppc64 succeeded(unpublished) ??? It was successful on ppc, so it is not really package issue ... -- 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] Recommends tag
by Jean Delvare 05 Nov '14

05 Nov '14

Hi all, I have a package which builds fine for all SUSE targets in OBS, but fails for Redhat-like distributions with the following error: error: line 68: Unknown tag: Recommends: procmail I seem to understand that Redhat's rpm does not support the "Recommends" tag, is that right? I would like to know what is the proper way to deal with this. I could not find anything related to this topic in the packager's guidelines. The first thing I would try is: %if 0%{?suse_version} > 0 Recommends: procmail %endif Is that the right approach? Or is there a different tag I should use for non-SUSE targets? Either way, I am surprised that OBS does not handle this all by itself, as this seems to be a fairly generic problem. Thanks, -- Jean Delvare SUSE L3 Support -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

10 34