openSUSE Packaging September 2017

packaging@lists.opensuse.org

28 participants
18 discussions

[opensuse-packaging] Selecting GCC version

by Matthias Fehring

Hello, is there a simple way to force the GCC version used to build a package? openSUSE Leap 42.2 for example uses GCC 4.8 as default compiler, but also provides packages for GCC 5.3. Simply using BuildRequires gcc5 pulls gcc5 in but still uses gcc48 to build the package (especially in Build Service). So is there maybe some Buid Service or spec file switch (bcond) to select the used GCC version? Best greetings Matthias Fehring P.S. Not sure if it is a problem with my browser settings, but when I try to search lists.opensuse.org, it is not possible for me to limit the results to a specific list. Even if I set one, I get results from all lists, what makes searching almost impossible, because most results are commit messages. -- Das Gesetz hat zum Schneckengang verdorben, was Adlerflug geworden wäre. (Friedrich Schiller - Die Räuber) www.buschmann23.de GPG-Key: 0x614C3258 GPG Fingerprint: D786 DDF8 4CA9 00BC CDE0 9A5F CCC5 125D 6E87 D4FC

3 years, 3 months

[opensuse-packaging] Java-build on TW fails suddenly: [javac] error: Source option 1.5 is no longer supported. Use 1.6 or later.

by Axel Braun

Hi, maybe we have a Java-Expert around that can support: projectlibre [1] suddenly fails to build on TW, with the error message: [ 31s] [ 31s] init: [ 31s] [mkdir] Created dir: /home/abuild/rpmbuild/BUILD/projectlibre-1.7.0/openproj_contrib/build [ 31s] [mkdir] Created dir: /home/abuild/rpmbuild/BUILD/projectlibre-1.7.0/openproj_contrib/tmp [ 31s] [ 31s] build: [ 31s] [javac] /home/abuild/rpmbuild/BUILD/projectlibre-1.7.0/openproj_contrib/build.xml:30: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds [ 31s] [javac] Compiling 10 source files to /home/abuild/rpmbuild/BUILD/projectlibre-1.7.0/openproj_contrib/build [ 31s] [javac] error: Source option 1.5 is no longer supported. Use 1.6 or later. [ 31s] [javac] error: Target option 1.5 is no longer supported. Use 1.6 or later. [ 31s] [ 31s] BUILD FAILED As the version setting is not explicit mentioned in the spec file I guess it is some implicit definition. Anyone an idea where to look forß Thanks Axel [1] https://build.opensuse.org/package/show/Office/projectlibre -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 years, 8 months

[opensuse-packaging] Fwd: Build failure of openSUSE:Tools/osc-plugin-install in Fedora_Rawhide/armv7l

by Oliver Kurz

Any Idea what that means "unknown host 'back-other-opensuse'" ? ---------- Forwarded Message ---------- Subject: Build failure of openSUSE:Tools/osc-plugin-install in Fedora_Rawhide/ armv7l Date: Wednesday, 27 September 2017, 18:22:35 CEST From: OBS Notification <admin(a)opensuse.org> To: okurz(a)suse.de Visit https://build.opensuse.org/package/live_build_log/openSUSE:Tools/osc-plugin… Package openSUSE:Tools/osc-plugin-install failed to build in Fedora_Rawhide/ armv7l Check out the package for editing: osc checkout openSUSE:Tools osc-plugin-install Last lines of build log: unknown host 'back-other-opensuse' -- Configure notifications at https://build.opensuse.org/user/notifications 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 years, 9 months

[opensuse-packaging] moving a binary from foo to bar package

by Jordi Massaguer Pla

Hi, I have this package, foo-1.0, which provides /usr/bin/foo. Then, I want to have foo-2.0 and bar-2.0 and make bar-2.0 provide /usr/bin/foo. At the same time, I make foo-2.0 require bar-2.0. However, if I do: zypper install foo-1.0 zypper install foo-2.0 zypper install --old-version foo-1.0 I get this error that the file /usr/bin/foo creates a conflict between foo-1.0 and bar-2.0. If I go on with the installation, I end up having foo-1.0 and bar-2.0 installed. Then, if I do zypper install foo-2.0 I will get foo-2.0 installed, bar-2.0 remains (no new install) and foo-1.0 gets removed. However, the latest, removing foo-1.0, causes /usr/bin/foo to be removed as well! Thus, I end up having foo-2.0, bar-2.0 but no /usr/bin/foo How could I make installing foo-1.0 remove bar-2.0? So all this works? thanks in advance jordi PD: substitute foo by docker, bar by docker-libnetwork, and /usr/bin/foo by /usr/bin/docker-proxy ;) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 years, 10 months

[opensuse-packaging] Packaging python singlespec applications

by Todd Rme

According to python packaging guidelines, python-based GUI applications should not have the "python-", "python2-", or "python3-" prefix. Ideally this wouldn't be a problem, since these are not dependent on the python version they use. However, a lot of them turn out to be either IDEs (e.g. Spyder), shells (e.g. jupyter's qtconsole or bpython), or other development tools that are dependent on the specific version of python they are built against. Such packages are hard to use with singlespec macros. One option would simply be to change or not follow the package naming guidelines for such packages. Some packages, such as jupyter, do not follow them, but others like spyder do. Another option would be to make the macros more useful with such packages. If we go this route, I see four changes that would be extremely helpful in this regard. First, it would be nice if %python_subpackages allowed us to specify additional packages to manage. These would be packages named using "%package -n foo" that we nevertheless want to have multiple versions of. The macros would then create a set of packages "foo-%{python_bin_suffix}". So for example we might say %{python_subpackages spyder}. If we did that, we would get "spyder-3.6" and "spyder-2.7", with Requires, Provides, Obsoletes, and %files all handled appropriately for the given python version. Second, it would be nice if there was some way to handle "%files -f file". This is pretty much mandatory for -lang packages. So perhaps something as bare-bones as allowing %files %{python_files foo -f foo-%{$python_bin_suffix}.bar}, or something more advanced like %{python_files foo -f foo.bar} which automatically inserts %{$python_bin_suffix} Third, it would be nice if %python_clone handled .desktop files and appdata.xml files, or there was some alternative macro for these. Fourth, it would be nice if there was a singlespec-aware version of %find_lang and perhaps even %lang_package. %find_lang is easy enough to handle manually with grep, but I have not found a good solution for %lang_package. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 years, 10 months

[opensuse-packaging] How do I make rpm output a message on installation?

by Dave Plater

The new blender-2.79 has a compatibility problem with the previous version. Do I simply use cat message file or echo in %postin to output a warning message or is there another way? 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 years, 10 months

[opensuse-packaging] was unable to be delivered to the list because of an access rule set up by the list administrator

by MANUEL Q

Hi, I wanted to send a query to the mailing list, but I get the following message: Hi, this is the Mlmmj program managing the <opensuse-packaging(a)opensuse.org> mailing list. The message from <manuel(a)favf.mx> with subject "Two branches with the same content different results (unresolvable)" was unable to be delivered to the list because of an access rule set up by the list administrator. (The denied message is below.) What are the rules of the list to be able to send queries? Thank you ---------- Forwarded message ---------- From: <opensuse-packaging+owner(a)opensuse.org> Date: 2017-09-15 14:06 GMT-06:00 Subject: Post to opensuse-packaging(a)opensuse.org denied: Two branches with the same content different results (unresolvable) To: manuel(a)favf.mx Hi, this is the Mlmmj program managing the <opensuse-packaging(a)opensuse.org> mailing list. The message from <manuel(a)favf.mx> with subject "Two branches with the same content different results (unresolvable)" was unable to be delivered to the list because of an access rule set up by the list administrator. (The denied message is below.) ---------- Mensaje reenviado ---------- From: MANUEL Q <manuel(a)favf.mx> To: opensuse-packaging(a)opensuse.org Cc: Bcc: Date: Fri, 15 Sep 2017 14:06:49 -0600 Subject: [opensuse-packaging] Two branches with the same content different results (unresolvable) Hello, I am new wanting to learn how to package in opensuse, if it is not much trouble I would like to help me understand some issues. As a practice, I decided to update the library: https://build.opensuse.org/package/show/games/allegro52 >From which you create a branch by clicking from that address in "Branch package". which I believe a subproject that would be as follows: https://build.opensuse.org/package/show/home:icomputo:branches:games/Allegro Next data update the source code and the .spec file. the result was: openSUSE_Leap_42.2 x86_64 succeeded openSUSE_Leap_42.3 x86_64 succeeded openSUSE_Tumbleweed i586 succeeded x86_64 succeeded Then, since I do not expect it to be posted at https://software.opensuse.org/search I decided to make a new branch linked to the same project ../games/allegro52 from my home obs, which was thus: https://build.opensuse.org/package/show/home:icomputo/Allegro In the same files were uploaded as in the subproject ../home:icomputo:branches:games/Allegro but in this case gave me errors, with the following result: openSUSE_Leap_42.2 x86_64 unresolvable openSUSE_Leap_42.3 x86_64 unresolvable the question is, because being the two branches descending from the same source, in the subproject if you find the library that has the project where the branch is connected, and the project that is in home: marks error of not finding the library. They have the same files, they decide the two branches of the same source project. Could someone help me clarify that? Thank you for the trouble of reading everything. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 years, 10 months

[opensuse-packaging] was unable to be delivered to the list because of an access rule set up by the list administrator.

by MANUEL Q

3 years, 10 months

[opensuse-packaging] Rethinking packaging vagrant: Build for multiple ruby versions (almost) like a normal rubygem

by Johannes Kastl

Crosspost on factory and packaging, please reply to factory... ###### Good evening everybody, over the last couple of months I have been on and off with an alternative approach to package vagrant. First off: This might not the bee's knees and the best way of packaging this. I also do not want to be rude to Duncan, Robert or the others that have taken care of vagrant so far. I just wanted to put it out there and get some opinions, if this might be a feasible approach for the future. For those not familiar with vagrant's packaging, the current package - creates a rubygem in %build and then packages it for the default ruby version hardcoded in the spec file and - ignore's vagrants requirement for ruby2.2 so it is installable on Leap 42.* which has ruby2.1. I had some issues getting the plugin installation to work, and found some things that I (as a not-ruby-expert) thought might be because of this 2.1-vs-2.2 thing. But how to solve this issue for Leap 42.2, which only has ruby2.1? Yesterday (I hope) I got the builds working: home:ojkastl_buildservice:Vagrant Basically, you can install vagrant in the flavour for the ruby version of your choice, which let's you install it with ruby2.4 on TW and ruby2.2 on Leap. Or ruby2.3 or ruby2.5. All dependencies that I found so far have been put into that project and have being modified, where needed, to also build for more than one ruby version. In my tests this worked, but then again one change somewhere and everything falls apart... ;-) Where possible I tried to narrow down the requirements so there should not be any "have choice" errors. But, as each package actually is five packages (one for each ruby in ruby{1,2,3,4,5}) with one status (successful or failed). Disclaimer: Due to the nature of ruby packages on the OBS it might happen occasionally, that during updating or adding packages, some of them might not get built for all ruby versions but are being shown as successful in the webUI. So, in case you think there is something missing, give me a call. (And, just to avoid misunderstandings, I think the way to build ruby packages on OBS is pretty cunning, even if there are corner cases now and then.) So, I am looking forward to your thoughts and feedback. Kind Regards, Johannes

3 years, 10 months

[opensuse-packaging] where (and how) to install shebang modification macros

by jan matejek

hello, in my private code stash I now have the following RPM macro: # (d)rop shebang (interpreter) line: %update_shebang -d <files...> # (s)et shebang (interpreter) line to /usr/bin/foo: %update_shebang -s /usr/bin/foo <files...> This is useful for python, but i don't want to put this in python-rpm-macros because it is going to be useful for other packages and languages as well. Instead I'd prefer to put this into /etc/rpm/macros.shebang, or /usr/lib/rpm/macros.d/macros.shebang (which of the two is preferred these days btw?) But I'm faced with the question of how to package it. ISTM this should be part of the default build environment. If we need a BuildRequires: shebang-macros, we can as well stick with adhoc "sed" invocations in every package. So i'd create the shebang-macros package and add it as Requires for ... what? rpm-build? rpm itself? Maybe instead add the macro to rpm and push upstream? This fully implicit installation won't be portable to other distros though. What then, invoke the macros always as %{?update_shebang:%update_shebang -d} ? That seems stupid. Maybe I'd keep it as a requirement to python-rpm-macros, and other potential users (perl, ruby) can add it as a requirement to their respective macro sets too? what do you folks think? m.

3 years, 10 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging September 2017