September 2013 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Proper version scheme for packages from git, hg, svn, ...
by Sascha Peilicke 24 Jan '14

24 Jan '14

Hi guys, I'd like to gather some input on versioning schemes used for packaging SCM snapshots. Why do we care at all? Ignoring the source pkg and the changes file for the moment, the package version is meant to tell the user exactly which state of the software was provided to him. When you package an upstream tarball, you implicitly provide information about what was released and when. And the package build is reproducable, it won't change how often you download the tarball referenced in Source:. Thus it's enough to just have sth. like this in your spec file: Version: 1.2.3 So if you have to package a (random) SCM snapshot, you want to make sure that it's obvious which commit you picked, so that others can confirm and eventually repeat the build. Here's a small list of flavors that I've come across or used myself. Please not that I replaced the stable (upstream) version with X, since that's not the part I'm interested here. Also, the word "git" can be replaced by whatever SCM at hand: 1) X+git 2) X_20041122git 3) X+git20111213 4) X.a258.g003e7e3 5) X+git.1363873583.8dfab15 Albeit you can discuss the format differences, 2) and 3) are much better than 1) since they at least broadly state when the SCM snapshot was taken. 4) Does a better job by providing the commit number/hash but breaks RPM upgradeability. Random commit hashes aren't upgradeable right? So the best version is indeed number 5), where the first number is the commit date and the second one is the commit hash. The date assures upgradability, because it increments always linearly and the commit hash provides for reproducability. You can of course argue about dots vs, any other separating paragraph. Also, instead of "+git", you may prefer sth. different (along as it won't break RPM's version comparison mechanism). TL;DR ===== My recommendation would be to (at least loosely) follow pattern 5) versioning if you ever have to package from SCMs. While devel projects are rather free to do whatever they prefer, I'd say it's appropriate for Factory submissions. Bonus ===== There is absolutely no reason to do this manually. Use the tar_scm source service (in disabled or local_only mode !!!) if you want to fully automate this. Here are some examples: Cloud:OpenStack:Master / openstack-utils devel:languages:go / go-assert -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

21 132

[opensuse-packaging] CrossToolchain question
by Matwey V. Kornilov 25 Oct '13

25 Oct '13

Hi, In CrossToolchain:avr, I see avr-gcc-* and cross-avr-gcc. What is the difference? What is correct naming? (I suppose the last one). What guidelines/rules should I follow to create CrossToolchain subproject for yet unsupported arch? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 22

[opensuse-packaging] prosody-relates sr's to server:messaging / lua packaging
by Sascha Peilicke 14 Oct '13

14 Oct '13

Hi Marguerite, it seems like it's time to review your requests, it's only been 2 months :-/ While the submits look mostly fine to me, I wonder whether the lua dependencies should go into devel:languages:lua following the package style / naming there and be linked instead into server:messaging? From glimpsing at d:l:lua, it's in a really sorry state and needs a lot of love. I don't know if you'd be interested in working on that, thus I'm opening this up to the wider community. -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)

4 8

[opensuse-packaging] Making packages ccbuild and bobcat or help doing so
by Daniël Huisman 04 Oct '13

04 Oct '13

Hi all, I'm not sure this is the right mailing list but here I go. After a long search on howto making packeges and a lot of try and more error I was hoping you all could help. For a development project I have to run ccbuild, it makes dynamic makefiles. But I can't find any package to install it. I don't like building and running from source. It prevents from keeping track of what is installed. That said I have a spec-file for ccbuild that looks okay. But it needs bobcat (Brokken's Own Base Classes And Templates). And that's where the big problem is. I can't seem to get a spec-file to build it. I always get an error on the directory or the files in use. So I was hoping you could help me making a package for ccbuild and/or bobcat. I even think that there will be dev how would like to see them in openSUSE. Best regarts Daniël Huisman bobcat: http://bobcat.sourceforge.net/ made my Frans Brokken the same one as icmake ccbuild http://www.logfish.net/pr/ccbuild/ spec-file at https://build.opensuse.org/package/view_file/home:Drunken/ccbuild/ccbuild.s… -- 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] firefox-esr
by Felix Miata 04 Oct '13

04 Oct '13

I'm asking Wolfgang directly instead of only a list because of firefox-esr changelog, and http://lists.opensuse.org/ doesn't indicate a good place for Mozilla questions spanning different OS releases. IIUC, 24 is scheduled to take over esr soon. I don't want anything newer than 22 installed as default Firefox anywhere around here. Its UI has been dumbed down too much. I'd rather 17 for normal use as long as it's viable, with SeaMonkey and Konq for things requiring latest features and/or security updates. Maybe others have similar feelings and would like access to a 17-latest rpm in 13.1 now that beta1 has been announced. 12.3 has latest, 17.0.9, available in mozilla/openSUSE_12.3 repo. 13.1 has 6 month old 17.0.4 available in mozilla:/experimentalopenSUSE_Factory repo. 1-Is old version for 13.1 oversight? 2-Can 12.3's rpm be installed in 13.1 without need to backlevel deps/libs? 3-Why isn't esr available in a standard Factory/13.1 repo instead of "experimental"? Why does BS have a lot of what looks like the same thing under two different names? e.g. mozilla/ mozilla:/ Other than different names and different subdirs, what's the distinction between those with and without ":"? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 4

[opensuse-packaging] antRun issue - symlink solution
by Denny Beyer 02 Oct '13

02 Oct '13

Dear all, there seems to be a setup issue for antRun that makes the scala builds fail, as antRun could not be found. By creating a symlink by hand from "/usr/share/ant/bin/antRun" to "/usr/bin/antRun" could possibly fix it, but I didn't get it to work. I tried the following in build section of the spec: # Create symlink to fix antRun setup bug mkdir -p %{buildroot}/usr/share/ant/bin/ cd %{buildroot}/usr/share/ant/bin/ ln -s ../../../bin/antRun as suggested, but this didn't work. Any idea, how to get this working again? Sorry for crossposting, but this seems a better place to ask. project : devel:languages:scala package: scala Thanks, Denny -- 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] new factory build failure - I used to be able to read a c compiler error, but apparently no longer
by Greg Freemyer 01 Oct '13

01 Oct '13

I maintain libprelude and it is now failing in factory. I assume a new gcc compiler went in recently. (It still builds fine in the 13.1 branch.) A local build log has these lines which I think are the critical ones: ============================= [ 191s] Making all in lua [ 191s] make[3]: Entering directory `/home/abuild/rpmbuild/BUILD/libprelude-1.0.1/bindings/lua' [ 191s] /usr/bin/swig -c++ -I../../bindings -I../../bindings/c++/include -I../../src/include -I../../src/libprelude-error -lua -o PreludeEasy.cxx libpreludecpp.i [ 191s] SWIG:1: Warning 125: Use of the include path to find the input file is deprecated and will not work with ccache. Please include the path when specifying the input file. [ 191s] ../../bindings/c++/include/prelude-error.hxx:48: Warning 503: Can't wrap 'operator const char*' unless renamed to a valid identifier. [ 191s] ../../bindings/c++/include/prelude-error.hxx:49: Warning 503: Can't wrap 'operator const std::string' unless renamed to a valid identifier. [ 191s] /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../src/include -I../../src/include -I../../src/libprelude-error -I../../bindings/c++/include -I../../libmissing -I../../libmissing -fomit-frame-pointer -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -c -o PreludeEasy.lo PreludeEasy.cxx [ 191s] libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../src/include -I../../src/include -I../../src/libprelude-error -I../../bindings/c++/include -I../../libmissing -I../../libmissing -fomit-frame-pointer -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -c PreludeEasy.cxx -fPIC -DPIC -o .libs/PreludeEasy.o [ 192s] PreludeEasy.cxx: In function 'int _wrap_IDMEFValue_Clone(lua_State*)': [ 192s] PreludeEasy.cxx:7154:9: warning: unused variable 'ret' [-Wunused-variable] [ 192s] int ret; [ 192s] ^ [ 192s] PreludeEasy.cxx: In function 'int _wrap_IDMEFPath_Get(lua_State*)': [ 192s] PreludeEasy.cxx:7376:9: warning: unused variable 'ret' [-Wunused-variable] [ 192s] int ret; [ 192s] ^ [ 192s] PreludeEasy.cxx: In function 'int _wrap_IDMEF_Get(lua_State*)': [ 192s] PreludeEasy.cxx:10519:9: warning: unused variable 'ret' [-Wunused-variable] [ 192s] int ret; [ 192s] ^ [ 192s] PreludeEasy.cxx: In function 'void luaopen_PreludeEasy_user(lua_State*)': [ 192s] PreludeEasy.cxx:11337:53: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] [ 192s] if ( idx >= ((sizeof(argv) / sizeof(char *)) - 1) ) [ 192s] ^ [ 192s] PreludeEasy.cxx: In function 'int SWIG_Lua_namespace_register(lua_State*, swig_lua_namespace*)': [ 192s] PreludeEasy.cxx:1278:1: warning: control reaches end of non-void function [-Wreturn-type] [ 192s] } [ 192s] ^ [ 192s] PreludeEasy.cxx: In function 'int SWIG_Lua_add_namespace_details(lua_State*, swig_lua_namespace*)': [ 192s] PreludeEasy.cxx:1248:1: warning: control reaches end of non-void function [-Wreturn-type] [ 192s] } [ 192s] ^ ================== The last 2 warnings are causing the build to fail (or so I believe). So you can see the compile is in the directory bindings/lua and the file PreludeEasy.cxx is being compiled. My confusion is when I go look in the source file at lines 1248 and 1278 I have: 1248: SWIGINTERN void SWIG_Lua_class_register(lua_State* L,swig_lua_class* clss) 1278: lua_rawset(L,-3); /* metatable into registry */ Neither of those look like they correspond to the warnings. Further if I search the source tree for SWIG_Lua_namespace_register or SWIG_Lua_add_namespace_details I don't find either one. Can someone help me try to track down how to patch this. fyi: I looked upstream and this hasn't yet been reported. I thought I wold try to provide a patch with my bug report, but I may have to just submit a bug report and wait for a patch from upstream. 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

4 6

[opensuse-packaging] openSUSE:13.1 created
by Stephan Kulow 30 Sep '13

30 Sep '13

Hi, We branched the sources of factory into openSUSE:13.1 and from now on I will cherry pick openSUSE:Factory submit requests to copy into 13.1 To ease my work there, it would be great if you document your expectations and the bugs you fixed. E.g. I agreed to take GNOME 3.10, but that does not mean every update of a package that has GNOME in the group tag is automatically going into 13.1. The accept message of your submit request will tell you if I copied to 13.1 or not. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

12 23

[opensuse-packaging] Any texlive packager willing to take care of texlive-cjk-latex-extras in M17N?
by Marguerite Su 26 Sep '13

26 Sep '13

Hi, packagers, I need help from texlive packagers with texlive-cjk-latex-extras in M17N. Personally I don't know how to package for texlive...and I didn't find tutorial on Portal:Packaging. It's now in a fail status for 13.1 and Factory. I read its URL tag in specfile, upstream now has a different source name "cjk-*" for it and released a lot of versions (the latest happened in late 2012) So just fix the package doesn't work, we need to update it. I think such an important update should be done by experts instead of a person who know nothing about it... Greetings Marguerite -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 4

[opensuse-packaging] How to unlink packages from Factory?
by Marguerite Su 26 Sep '13

26 Sep '13

Hi, I noticed some packages in M17N were dropped from Factory. But the links are still there, so they're all in a "broken" status. How can I remove the links and make them build inside M17N? Greetings Marguerite -- 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] Hermes mail about failure [Fwd: Build failure of Base:System/coreutils-testsuite openSUSE_Factory/x86_64]
by Bernhard Voelker 26 Sep '13

26 Sep '13

Hi *, I'm often receiving Hermes mails about build failures (like the following), but I can't see any problem in the log. Any hint? Thanks & have a nice day, Berny -------- Original Message -------- From: hermes(a)opensuse.org Subject: Build failure of Base:System/coreutils-testsuite openSUSE_Factory/x86_64 X-Hermes-Msg-Type: OBS_BUILD_FAIL X-Mailer: openSUSE Notification System Date: Thu, 26 Sep 2013 04:20:31 +0000 Message-Id: <20130926042031.CB84723C6C(a)dhl.opensuse.org> Package coreutils-testsuite (version 8.21-216.26) of project Base:System failed to build for openSUSE_Factory / x86_64. Review the build log: osc remotebuildlog Base:System coreutils-testsuite openSUSE_Factory x86_64 | less Check out the package for editing: osc checkout Base:System coreutils-testsuite -- Hermes messaging (http://hermes.opensuse.org) openSUSE Build Service (https://build.opensuse.org/) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 5

[opensuse-packaging] Can someone update this package ]from 1.3x to 1.4x please - https://build.opensuse.org/package/show/system:packagemanager/smart#
by doiggl＠velocitynet.com.au 25 Sep '13

25 Sep '13

Hello Can someone update this package [1]from 1.3x to 1.4x please. I am asking because I don’t see a package update/report update section. I am using the 1.4x version and it works. [2] see [2] for build details. Thank you Glenn source: http://launchpad.net/smart/trunk/1.4.1/+download/smart-1.4.1.tar.bz2 announcement: http://lists.labix.org/pipermail/smart-labix.org/2011-October/004210.html [1] https://build.opensuse.org/package/show/system:packagemanager/smart# openSUSE Build Service > Projects > system:packagemanager > smart [2] https://build.opensuse.org/package/show/home:doiggl/smart version 1.4x build details [ 125s] ... saving built statistics [ 125s] ... saving built packages [ 125s] /home/abuild/rpmbuild/RPMS/x86_64/smart-1.4.1-19.6.x86_64.rpm [ 125s] /home/abuild/rpmbuild/RPMS/x86_64/smart-debuginfo-1.4.1-19.6.x86_64.rpm [ 125s] /home/abuild/rpmbuild/RPMS/x86_64/smart-debugsource-1.4.1-19.6.x86_64.rpm [ 125s] /home/abuild/rpmbuild/RPMS/x86_64/smart-gui-gtk-1.4.1-19.6.x86_64.rpm [ 125s] /home/abuild/rpmbuild/RPMS/x86_64/smart-gui-qt3-1.4.1-19.6.x86_64.rpm [ 125s] /home/abuild/rpmbuild/RPMS/x86_64/smart-ksmarttray-1.4.1-19.6.x86_64.rpm [ 125s] /home/abuild/rpmbuild/RPMS/x86_64/smart-ksmarttray-debuginfo-1.4.1-19.6.x86_64.rpm [ 125s] /home/abuild/rpmbuild/SRPMS/smart-1.4.1-19.6.src.rpm [ 125s] /home/abuild/rpmbuild/OTHER/_statistics [ 125s] /home/abuild/rpmbuild/OTHER/rpmlint.log [ 125s] /home/abuild/rpmbuild/OTHER/smart-gui-gtk-appdata.xml [ 125s] /home/abuild/rpmbuild/OTHER/smart-gui-qt3-appdata.xml [ 125s] /home/abuild/rpmbuild/OTHER/smart-ksmarttray-appdata.xml [ 125s] [ 125s] cloud128 finished "build smart.spec" at Sun Sep 15 08:49:44 UTC 2013. [ 125s] [ 128s] [ 111.945064] SysRq : Power Off [ 128s] [ 111.956820] Power down. [ 128s] build: extracting built packages... [ 129s] smart-1.4.1-19.6.x86_64.rpm [ 129s] smart-debuginfo-1.4.1-19.6.x86_64.rpm [ 129s] smart-debugsource-1.4.1-19.6.x86_64.rpm [ 129s] smart-gui-gtk-1.4.1-19.6.x86_64.rpm [ 129s] smart-gui-qt3-1.4.1-19.6.x86_64.rpm [ 129s] smart-ksmarttray-1.4.1-19.6.x86_64.rpm [ 129s] smart-ksmarttray-debuginfo-1.4.1-19.6.x86_64.rpm [ 129s] smart-1.4.1-19.6.src.rpm [ 129s] _statistics [ 129s] rpmlint.log [ 129s] smart-gui-gtk-appdata.xml [ 129s] smart-gui-qt3-appdata.xml [ 129s] smart-ksmarttray-appdata.xml built rpms Architecture: i586 rpmlint.log smart-1.4.1-19.2.i586.rpm smart-1.4.1-19.2.src.rpm smart-debuginfo-1.4.1-19.2.i586.rpm smart-debugsource-1.4.1-19.2.i586.rpm smart-gui-gtk-1.4.1-19.2.i586.rpm smart-gui-gtk-appdata.xml smart-gui-qt3-1.4.1-19.2.i586.rpm smart-gui-qt3-appdata.xml smart-ksmarttray-1.4.1-19.2.i586.rpm smart-ksmarttray-appdata.xml smart-ksmarttray-debuginfo-1.4.1-19.2.i586.rpm Architecture: x86_64 rpmlint.log smart-1.4.1-19.2.src.rpm smart-1.4.1-19.2.x86_64.rpm smart-debuginfo-1.4.1-19.2.x86_64.rpm smart-debugsource-1.4.1-19.2.x86_64.rpm smart-gui-gtk-1.4.1-19.2.x86_64.rpm smart-gui-gtk-appdata.xml smart-gui-qt3-1.4.1-19.2.x86_64.rpm smart-gui-qt3-appdata.xml smart-ksmarttray-1.4.1-19.2.x86_64.rpm smart-ksmarttray-appdata.xml smart-ksmarttray-debuginfo-1.4.1-19.2.x86_64.rpm -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 6

[opensuse-packaging] ruby req/provs
by Matwey V. Kornilov 24 Sep '13

24 Sep '13

Hi, What is going on in devel:languages:ruby:extensions ? I am trying to install rubygem-vagrant which says that nothing provides rubygem(1.9.1:net-ssh:2.6) >= 2.6.6, net-ssh has been bumped to 2.7.0 version and provides rubygem(1.9.1:net-ssh:2.7). This should be auto-detected and reported to the maintainer. It is possible to run deps-resolver for every successfully built package, however, I think it is resource-consuming. Who need the repo providing not-installable packages. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 9

[opensuse-packaging] Broken i810 driver
by Felix Miata 23 Sep '13

23 Sep '13

Will the regression fix patch in http://lists.freedesktop.org/archives/intel-gfx/2013-September/033668.html once committed filter into 12.2 and 12.3 updates automatically? Will something more be necessary to make it happen? Does it qualify to happen at all? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- 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] scala packaging help needed
by Denny Beyer 17 Sep '13

17 Sep '13

Dear all, help is needed to package the latest scala version. Builds are broken for versions newer than v2.9.2. How you can help: 1) If you know how and have successfully build scala from source on opensuse, please provide some informations about setup / commandline build call with opts / required dependencies or 2) go directly to devel:languages:scala/scala and fix build issues. cheers, Denny -- 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] run-one-*
by Michael Riess 16 Sep '13

16 Sep '13

Hi packagers, are there any Scripts packaged like the run-one-* here: http://blog.dustinkirkland.com/2013/09/introducing-run-one-constantly-run-o… -- Michael Riess -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 5

[opensuse-packaging] packaging Perl modules with no hard Perl version dependency
by Adam Spiers 13 Sep '13

13 Sep '13

Adam Spiers (aspiers(a)suse.com) wrote to opensuse-factory: > Hi, > > Back in 2011 I became maintainer of GNU Stow, and since then have > built an package which lives in the OBS system:packagemanager project: > > https://build.opensuse.org/package/show/system:packagemanager/stow > > I would like it to be in Factory too, so I have submitted a request: > > https://build.opensuse.org/request/show/198646 During the review for this SR, I noticed this rpmlint warning: stow.noarch: W: no-dependency-on perl-base 5.18.1 It seems that currently my .spec results in the package containing files such as: /usr/lib/perl5/vendor_perl/5.18.1/Stow.pm which will only be found by the default @INC of a perl-5.18.1 package. However, I know for a fact that my non-binary modules will work with *any* Perl >= 5.6.1, and so would prefer to install them to a non-versioned directory, e.g. $ perl -V:vendorlib_stem vendorlib_stem='/usr/lib/perl5/vendor_perl'; However this is not on the default @INC. In contrast, sitelib_stem does seem to be, although my understanding is that "vendor" packages such as those from OBS should install to vendor* paths rather than site*. Is there a good reason for vendorlib_stem not being on @INC, and if so, is it OK for me to install to sitelib_stem instead? Thanks! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 8

[opensuse-packaging] run-one-*
by Michael Riess 12 Sep '13

12 Sep '13

Hi packagers, are there any Scripts packaged like the run-one-* here: http://blog.dustinkirkland.com/2013/09/introducing-run-one-constantly-run-o… -- Michael Riess -- 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] CMake and OBS
by Sankar P 11 Sep '13

11 Sep '13

Hi, Are there any best known methods to package CMake based projects using the open build service ? Specifically what I am looking forward to is a simplified way of: 1) Installing all the libraries that CMake generates to /usr/lib (or) /opt/<company>/lib 2) Installing all the binaries that CMake generates to /usr/bin (or) /opt/<company>/bin 3) Populate BuildRequires: based on the find_package inside the CMakeLists.txt( 4) Building only a small subset of all the targets supported by the CMake file in a project. To explain on this point. Assume that my project has 10 targets and I need only 5 targets (3 binaries and 2 libraries that they depend) to be shipped to the users. So, I want a way to generate a tarball with only these 3 binaries and their dependencies (2 libraries in our case), which can be used in a build-service project. If I am not using OBS for distributing the binaries, I can easily build the two binary targets alone and can ship the resultant binaries. But if I want to use CMake what is the best way for achieving this instead of creating a tarball with the sources for all the 10 targets ? I googled around a bit before asking here but could not find any relevant information. I see that CMake is used heavily in KDE and so some of the openSUSE packagers would have run into similar requirements and wanted to find out the best practices for using CMake in OBS. Thanks. Sankar -- 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] Reminder: Beta checkin this friday
by Stephan Kulow 11 Sep '13

11 Sep '13

Hi, I want to remind you that this friday is the checkin for the Beta (some call it Beta 1, but that somewhat implies that there is going to be another one, which is not in the plan :) All features should be done by then and submitted to openSUSE:Factory. Having it in SCM or the devel project does not help the Beta. Everyone without features to finish, please help getting the current number of build failures down - we're over 100 again ;( After the Beta I'm going to branch off openSUSE:13.1 and will only cherry-pick from factory. Greetings, Stephan -- A real gentleman never takes bases unless he really has to. -- Overheard in an algebra lecture. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 4

[opensuse-packaging] [reminder] openSUSE 13.1 Beta is next week
by openSUSE Roadmap Reminder 11 Sep '13

11 Sep '13

Hello all, openSUSE 13.1 Beta will be released next week, on Thursday 19 September 2013. Please submit your packages before Friday afternoon (UTC time) to make sure they will get included in this release. Leaf packages submitted during the week-end might also get accepted on Monday. For a quick overview of the openSUSE Roadmap, please see: http://en.opensuse.org/Roadmap Thanks, -- openSUSE Roadmap Reminder -- 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] Packaging Guideline enforcement
by Dominique Leuenberger a.k.a DimStar 10 Sep '13

10 Sep '13

Dear Factory contributors and packagers, As openSUSE 12.2 is frozen and Factory is 'open to go wild' again, I would like to announce that the packaging guidelines have some extensions (not really new) that will be stricter enforced than they used to be. Currently a common rule to be 'ignored' or packagers are not aware is around the topics of: - .Changes entries - Patches First, the .changes entry (rpm changelog) surves two purposes: - News for the user - History tracking of packaging changes (often referenced in bugs to verify if a user has the latest packaging bugfixeS). A simple "Update to version x.y.z" is, as before, not accepted. There should be some buzz around the update for the user; some major reasons to the upgrade should be listed Changes on the package itself should be mentioned in a way that any other contributor to the same package can follow traces of why something is the way it is. Commonly, Added (build)dependencies are interesting to be seen, special hacks to make something work in a particular way [..]: Always consider that package maintenance is a distributed task and various contributors need to be able to step up at will. Patches: The rules about patches are listed at http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines . Most prominent is likely the mentioning of the patches life cycle, which forces you to mention additions and removals of patches in the changelog. As history shows, this can be helpful if a patch got removed, and later a regression is reported; finding out when a patch was removed can be crucial in reconstructing feature sets (including contacting the contributor that dropped it.. which is easily extracted from the .changes if listed) The main appeal is to the devel project maintainers / reviewers, to keep out for those rules, to live according to them, as it is frustrating for everybody if a package needs to be declined by the Factory Review team: - The dev prj maintainer is the one getting the 'decline' (as it was usually a forwarded request), which often leaves the 'fixing' to the devel project maintainers, where the 'originator' of the fix would have been willing to actually do that... And the Factory Review team also prefers to see complying submissions to having to reject SRs... reject is not fun for anybody! Looking forward to many more SRs to accept! Dominique / DimStar -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

29 105

[opensuse-packaging] Application:Geo Upgrading postgis2 - Call for comments
by Bruno Friedmann 10 Sep '13

10 Sep '13

Postgis packages on obs are actually maintained with 2 versions. postgis = 1.5 series postgis2 = 2.0 series Upstream has released 2.1 : but this one raised some new dependencies which are no more available for SLE build. 2.1 need postgresql 9.0 SLE has only 8.x version. also geos has to be 3.4+ Discussing with postgis members on irc reveal that will become more strict on postgresql version The next 2.2 release will need 9.1 A 2.0.4 bug fixes release will be also made. (simple update of the actual 2.0.3) So what should we prepare ? have postgis21 package ? and then a postgis22 ? Windows packaging is like this, also Ubuntu seems to follow the same way. I've actually already have a project for the upgrade but this one would upgrade 2.0.3 to 2.1 (in term of postgis it's a soft upgrade for those running the 2.0.3) Any through ? -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch 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

2 2

[opensuse-packaging] how to include icons from an alternative theme?
by Marguerite Su 09 Sep '13

09 Sep '13

Hi, Recently I'm updating our LXDE, and I met a problem Their packages used a lot of icons from nuoveXT2-icon-theme in their desktop files. So I always get "Error Icon in /usr/share/applications/pcmanfm-desktop-pref.desktop not found "user-desktop". Usually if it's an icon in hicolor-icon-theme, you add a BuildRequires: hicolor-icon-theme Then it will be automatically resolved. But I added BuildRequires: nuoveXT2-icon-theme And nothing happened. Anyone know how to workaround this? Greetings Marguerite -- 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] packaging guidelines need more info about debuginfo mechanism
by Adam Spiers 09 Sep '13

09 Sep '13

http://en.opensuse.org/openSUSE:Packaging_guidelines#Debuginfo implies that package builds automatically result in -debuginfo packages and that you have to explicitly disable them if you don't want them, but it fails to mention: 1. how -debuginfo packages are automatically built, and 2. how to disable them. It links to http://old-en.opensuse.org/Packaging/Debuginfo which doesn't really answer either, save fleeting references to /usr/lib/rpm/find-debuginfo.sh. I found this thread: http://lists.opensuse.org/opensuse-factory/2012-11/msg00328.html but it doesn't appear to have a useful conclusion. Please can someone shed light? Thanks! -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 5