October 2014 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Re:AW: Cinnamon Stable repo for openSUSE X11:Cinnamon?
by marguerite 16 Oct '14

16 Oct '14

Hi, Stefan, My opinion is: Actually it doesn't matter which upstream branch we use, but wether we can continuously focus on this project...eg, KDE 5 is considered unstable but our KDE team still do perfect things. So far upstream doesn't have a clear release schedule either. Although users would like to call eg. 2.2 stable, 2.3 unstable, something like that. But neither 2.2 nor 2.3 is stable. Because: 1. There's no backport support so far by Cinnamon upstream. So 2.2 just means old. They usually just fix things in newer versions... 2. Upstream officially doesn't support other distributions (That's why I didn't push Cinnamon an official spin into openSUSE Factory at the first time, and write something that "Cinnamon is not a DE but a community project of Linux Mint". Historically speaking Cinnamon is a "middle" product of Linux Mint for MATE DE) Even if upstream has backport support, we can't be sure that kinda backport works on openSUSE. 3. We don't have "time and programming skills" required to maintain such a so-called "stable" branch ourselves. It will just double our work and bug reports. 4. Upstream doesn't have clear dependency cycle. I tried to build 2.2 branch after 2.3's release, but eg. which version of muffin that Cinnamon 2.2 requires? No hints at all. If we built solid stuff on some liquid bases, then that's not stable but float... That's my considerations and that's why I always prefer concenterate on fixing existing stuff instead of providing something that we actually can't promise due to various facts. Greetings MargueriteN��r��y隊Z)z{.��ZrF��x>�{.n�+��Ǩ��r��i�m��0��ޙ��$j��0��Ǩ�

2 1

[opensuse-packaging] How to prepare a maintenance stack for openSUSE 13.2 before its release?
by marguerite 16 Oct '14

16 Oct '14

Hi, How can I prepare a maintenance stack for openSUSE 13.2 before its release? Currently `osc mbranch` can only create maintenance stuff for 12.3 and 13.1. If I ran `-m -c openSUSE:13.2`, it will just create a "home:MargueriteSu:branches:openSUSE:13.2", which can't be submitted as maintenance request (no such project) or normal one (~:branches:openSUSE:13.2 is not an official devel repo). Previously we have a sync robot that forward Factory SRs into 13.2, but I don't know if that still works after RC1. And there's already such update stacks (php ones) inside openSUSE:13.2:Update, so technically it's possible. So how did they achieve that? Thanks MargueriteN��r��y隊Z)z{.��ZrF��x>�{.n�+��Ǩ��r��i�m��0��ޙ��$j��0��Ǩ�

1 0

[opensuse-packaging] unable to branch libjpeg-turbo
by Olaf Hering 16 Oct '14

16 Oct '14

Petr, for some reason osc is unable to branch libjpeg-turbo properly. Its not possible to do a 'osc sr' from the resulting home:olh:branches:graphics/libjpeg62-turbo. Maybe with some extra effort osc would do it anyway. Please include the following patch manually in graphics/libjpeg-turbo. The existing Provides/Conflicts can not work with current pkg version. Thanks, Olaf Index: libjpeg-turbo.changes =================================================================== --- libjpeg-turbo.changes (revision 2) +++ libjpeg-turbo.changes (revision 3) @@ -1,4 +1,10 @@ ------------------------------------------------------------------- +Wed Oct 15 11:39:09 UTC 2014 - olaf(a)aepfle.de + +- Obsolete jpeg version 6b, 8.0.1 and 8.0.2 to avoid conflicts + during zypper dup + +------------------------------------------------------------------- Mon Mar 31 09:29:11 UTC 2014 - pgajdos(a)suse.com - update to 1.3.1: Index: libjpeg-turbo.spec =================================================================== --- libjpeg-turbo.spec (revision 2) +++ libjpeg-turbo.spec (revision 3) @@ -41,6 +41,9 @@ BuildRequires: gcc-c++ BuildRequires: libtool BuildRequires: yasm +Obsoletes: jpeg = 6b +Obsoletes: jpeg = 8.0.1 +Obsoletes: jpeg = 8.0.2 Provides: jpeg = %{version} Obsoletes: jpeg < %{version} BuildRoot: %{_tmppath}/%{name}-%{version}-build -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 10

[opensuse-packaging] find-lang error on SLE 11
by Erwin Waterlander 14 Oct '14

14 Oct '14

Hi, I'm working on a new package 'wcd' for Suse. In my home:waterlan project I have created a new package wcd. I'm trying to build packages for openSUSE_13.1, openSUSE_Factory, and SLE_11_SP3. The builds on openSUSE_13.1 and openSUSE_Factory succeeded, but the build on SLE_11_SP3 failed. This is the error I get: [ 65s] + /usr/lib/rpm/find-lang.sh '%{buildroot}' wcd --all-name --with-man [ 65s] /usr/lib/rpm/find-lang.sh: %{buildroot}: no such directory [ 65s] error: Bad exit status from /var/tmp/rpm-tmp.55835 (%install) See also https://build.opensuse.org/package/live_build_log/home:waterlan/wcd/SLE_11_… How can I fix this? best regards, Erwin Waterlander -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 3

[opensuse-packaging] How to package when upstream version is yyyymmdd
by Johannes Meixner 13 Oct '14

13 Oct '14

Hello I would like to know what to use as RPM package version when the upstream version is only a date like "yyyymmdd" (e.g. 20141013 for today). https://en.opensuse.org/openSUSE:Package_naming_guidelines mentiones "tilde versions" but "tilde versions" are unsupported in older openSUSE and SLE versions but intentionally the package should be also available for older openSUSE and SLE versions. Using a letter prefix like 'v.yyyymmdd' would work because zypper vcmp 'v.20141013' '0.0.1' results "v.20141013 is older than 0.0.1" (because 'v.*' is older than '0.*') This way if upstream might release a '0.0.1' version in the future an installed package of version 'v.20141013' could be upgraded. On the other hand I wonder if an openSUSE-specific artificial prefix to be prepared for potential upstream versioning changes in the future is overengineered and simply being in full compliance with upstream and just using the upstream version "yyyymmdd" is better? Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- 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] Don't install GIMP by default in LXDE
by jcsl 11 Oct '14

11 Oct '14

Hi. GIMP and mtPaint are both installed by default in LXDE, and both have the same goal. So one of them is redundant. Being mtPaint the lighter alternative, I'd like to have GIMP not installed by default. GIMP is not in LXDE's pattern. What do I have to do in patterns-openSUSE to prevent GIMP being installed by default? Greetings. -- 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] update seamonkey to version seamonkey-2.29.1.x
by doiggl＠velocitynet.com.au 06 Oct '14

06 Oct '14

Hello. FYI update SeaMonkey to version seamonkey-2.29.1x https://build.opensuse.org/package/show/mozilla:Factory/seamonkey src: https://download.mozilla.org/?product=seamonkey-2.29.1&os=linux&lang=en-US --Glenn -- 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] Rubygem-* packages started failing for devel_languages_ruby_* repos
by Robert Munteanu 03 Oct '14

03 Oct '14

Hi, I received a notification this morning that two rubygem packages that I maintain started failing for no apparent reason. One example is rubygem-gh [1] . It builds just fine for the main repositories ( openSUSE_* and SLE_* ) but fails for the devel_languages_ruby_* repos . One random build log [2] says [ 63s] ERROR: link target doesn't exist (neither in build root nor in installed system): [ 63s] /usr/share/doc/packages/rubygem-gh/LICENSE -> /usr/lib/ruby/gems/gems/gh-0.13.2/LICENSE [ 63s] Add the package providing the target to neededforbuild and Requires [ 63s] INFO: relinking /usr/share/doc/packages/rubygem-gh/LICENSE -> ../../../../lib/ruby/gems/gems/gh-0.13.2/LICENSE (was /usr/lib/ruby/gems//gems/gh-0.13.2/LICENSE) [ 63s] error: Bad exit status from /var/tmp/rpm-tmp.37574 (%install) That makes little sense to me, as the spec file is autogenerated, and furthermore it works on the other repos. Is this something that I should fix as a package maintainer? If it is, I'd appreciate any pointers on how to fix it. Thanks, Robert [1]: https://build.opensuse.org/package/show/devel:languages:ruby:extensions/rub… [2]: https://build.opensuse.org/package/live_build_log/devel:languages:ruby:exte… -- http://robert.muntea.nu/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 4