January 2017 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] release-notes-openSUSE requires google-opensans-fonts
by Felix Miata 23 Apr '17

23 Apr '17

TW $SUBJECT can't be right, but trying to zypper rm opensans wants to remove releasenotes. :-( -- "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

5 8

[opensuse-packaging] not restarting the docker service on running zypper update?
by Jordi Massaguer Pla 03 Feb '17

03 Feb '17

Hi packagers, I am packaging docker and we have this problem that if a user runs an unattended update, docker gets updated and so restarted. However, this is causing downtime issues on their services which are inside containers. I know there is the "--skip-interactive" flag for zypper ... So my question is. Should we mark docker as "interactive" and if so, how do we do that? Should we not restart docker when installing? I think you should, but am I wrong? Are there other packages with similar problems? mariadb? thanks in advance jordi -- 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] What's the easiest way to find python script dependencies?
by Dave Plater 02 Feb '17

02 Feb '17

Hi, is there a python tool to find dependencies of a python script in a package? 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

4 6

[opensuse-packaging] What had happen with my work at home:WernerFink:branches:multimedia:apps/morituri
by Dr. Werner Fink 31 Jan '17

31 Jan '17

Hi, I had done some work on multimedia:apps/morituri in my branch home:WernerFink:branches:multimedia:apps/morituri. Now the branch as well as the submit request is gone and a recreation of home:WernerFink:branches:multimedia:apps/morituri had destoyed my work: werner/morituri> osc up D 01f07c5.patch D 4830c16.patch D 4bfbc90.patch D 607f3e9.patch D 7bf7554.patch D 926ce46.patch D d81dd33.patch D f08d0a2.patch D morituri-improve-manpage-sections.patch U morituri.changes U morituri.spec At revision 8e333febd3e77640803d02eb6e25ba55. how can I get back my work? ???? Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

2 1

[opensuse-packaging] how do i package a rubygem?
by Mathias Homann 31 Jan '17

31 Jan '17

Hi, I'm trying to package a rubygem as rpm, but I have not that much experience with ruby... how do I proceed? The upstream site does not have much to say about packaging it, only about manual local installation (gem install $name)... Any hints welcomed! Cheers Mathias -- 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] Can cacti be updated to 1.0.0x [from 0.8.8f]
by doiggl＠velocitynet.com.au 31 Jan '17

31 Jan '17

Hello, Can cacti be updated to 1.0.0x [from 0.8.8f] thank you --Glenn https://build.opensuse.org/package/show/openSUSE:Leap:42.3/cacti http://www.cacti.net/download_cacti.php http://www.cacti.net/downloads/cacti-1.0.0.tar.gz http://www.cacti.net/downloads/cacti-1.0.0.zip http://www.cacti.net/release_notes_1_0_0.php -- 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] Package groups and desktop categories for CAD/CAM software
by Jarek Cora 30 Jan '17

30 Jan '17

Hi everyone, I'd like to start a discussion regarding RPM groups and desktop categories for CAD/CAM software. 1) CAD software, like OpenSCAD, FreeCAD, LibreCAD etc For RPM groups, we obviously have Productivity/Graphics/CAD [1] For desktop categories, there is no obvious choice. Some packagers use Graphics;3DGraphics or Graphics;2DGraphics but it seems wrong, because this way CAD software ends up in the same place as GIMP, digikam, gwenview and these two types of application have very little in common. Looking in the Freedesktop spec [4], the correct category for CAD is "Engineering", but our guidelines [3] allow Engineering only in "Science" or "Education", and both seem wrong in this case. 2) CAM software, like Cura, Slic3r, Printrun etc Here the situation is basically hopeless, as there is neither RPM group nor desktop category suitable for CAM software. For RPM groups, Fedora [2] uses Application/Engineering, but our guidelines [1] do not allow it. For desktop categories, one could use the "Engineering" in "Science" or "Education" but just like with CAD it seems like a stretch. Relevant links: [1] openSUSE groups: https://en.opensuse.org/openSUSE:Package_group_guidelines [2] Fedora groups: https://fedoraproject.org/wiki/RPMGroups [3] openSUSE categories: https://en.opensuse.org/openSUSE:Packaging_desktop_menu_categories [4] Freedesktop categories: https://specifications.freedesktop.org/menu-spec/latest/apas02.html We advertise as openSUSE as "The makers' choice...", so I hope we could address these concerns, as they affect software typically used by makers. It's a bit funny we (and Freedesktop) have a designated category for Spirituality software, but not for 3D printing :) Any thoughts? -- Jarek -- 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] changing a sysconfig file on an update
by Jordi Massaguer Pla 27 Jan '17

27 Jan '17

Hi, we have this problem on the docker package that could be fixed by adding a configuration option in /etc/sysconfig/docker ... However, I believe it is not good practice to update configuration files .... is it? Can I just update the /adm/fillup-templates/sysconfig.docker and expect that the %fillup_only macro will take care of that? thanks -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 2

[opensuse-packaging] Correctly naming a python package
by Johannes Kastl 26 Jan '17

26 Jan '17

Dear all, I had the need for a little python bindings package, that is available in pypi as lxc-python2. https://pypi.python.org/pypi/lxc-python2 https://github.com/lxc/python2-lxc As this is required for setting up lxc containers via ansible, I guess this might be useful in factory. But what would be the correct name for the package? python-lxc-python2 python2-lxc-python2 python2-lxc ... Johannes P.S.: The bindings themselves have not changed for a long time, so this should be easy to maintain...

3 6

[opensuse-packaging] How to update patterns-openSUSE?
by Takashi Iwai 25 Jan '17

25 Jan '17

Hi, is there a special method to update patterns-openSUSE package? I thought there were some magic procedure in the past, but nowadays may I just do osc SR with the desired change? And what about the patterns of the released product (e.g. openSUSE-42.2)? Do MR similarly? I'm trying to fix the long-standing issue in boo#1010202 to drop gsynaptics, and stumbled upon these questions. thanks, Takashi -- 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] need help to fix postgresql related troubles
by Bruno Friedmann 23 Jan '17

23 Jan '17

Hello my buddies :-) I need a bit of help to understand (at least just my concerning part) of something I would qualify as "messy" Here's what I normally understand of normal submission In server:database:postgresql, I've postgresql-plr disabled build package which auto-created (+/- sometimes I need one of server:database:postgresql maintainer to create a link when a new version comes.) Now, after an update to last upstream version, I was in the process to send sr to factory but found uncomprehensible things for my part time contributor. s:d:p/postgresql91-plr and s:d:p/postgresql92-plr are link back to s:d:p/postgresql-plr We can let them as they are, no more present in openSUSE:Factory. Now I've two specials s:d:p/postgresql93-plr and s:d:p/postgresql94-plr which are marked as devel package for Factory but they link to https://build.opensuse.org/package/show/openSUSE:Factory/postgresql94-plr As such they are not "magically" updated when I update postgresql-plr and never propose a submission to Factory ? This is what I don't understand ... How can we fix those Also both of them have only the corresponding PG_Version only spec and changes files. Also I would like to submit the 2 missing postgresql95-plr and postgresql96- plr. What is the best way to do it ? Thanks for your help https://build.opensuse.org/package/show/server:database:postgresql/postgres… -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship 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 3

[opensuse-packaging] prefered libjawt.so in openSUSE_13.2 needs to be specified
by Olaf Hering 19 Jan '17

19 Jan '17

In Packman the pkg Extra/IfcOpenShell can not build due to a missing Prefer in the global 13.2 prjconf: have choice for libjawt.so()(64bit) needed by vtk-devel: java-1_7_0-openjdk-headless java-1_8_0-openjdk-devel java-1_8_0-openjdk java-1_7_0-openjdk-bootstrap-headless have choice for libjawt.so(SUNWprivate_1.1)(64bit) needed by vtk-devel: java-1_7_0-openjdk-headless java-1_8_0-openjdk-devel java-1_8_0-openjdk java-1_7_0-openjdk-bootstrap-headless I have not followed this pkg, appearently this bug was introduced after 2016-11-04. Olaf

2 3

[opensuse-packaging] RFC: moving from separate users to user monitoring for everything
by Lars Vogdt 17 Jan '17

17 Jan '17

Hi I'm maintaining some packages in the server:monitoring repository and want to make my live a bit easier in the future (and I hope that also our users will benefit from it)... At the moment, we follow upstream very close regarding the names of the users and groups used for monitoring related packages (and especially daemons): Package | User(s) | Group(s) ------------------------------------------------ icinga | icinga | icinga, icingacmd naemon | naemon | naemon nagios | nagios | nagios, nagcmd shinken | shinken | shinken zabbix | zabbix, zabbixs | zabbix, zabbixs Please note that at least icinga, naemon, nagios and shinken are very similar and even their configuration is more or less compatible. So you can easily migrate between the different daemons without too much administration overhead. While - from a security stand point - the current approach to use the upstream users/groups is very smart, as it allows you to run multiple daemons on a single host that can not influence each other, it becomes more and more a nightmare from a packaging (and customer) view: A lot of 3rd party applications want to get access to sockets, directories or other parts, that belong to the corresponding daemon (check_mk*, pnp4nagios, BPView, {nagios-,icinga-www} - as both can run also on the other core, nagiosgrapher, nagiosgraph, nagserv, nsca, ... just to name a few). As result, there have to be either "permission" files to change the ownerships after installation of sucha 3rd party application - or even separate $pkg-$daemon sub-packages that come with the correct owner:group setup for the $daemon part. The problem with "permissions": * there is a small, but important time frame between installing a package update and executing "chkstat --system --set" on the host to correct the ownerships again * it needs additional openSUSE specific READMEs and support for users that are not aware of the fact that they might need to edit a file, that is not mentioned upstream, before the application works * our security team does not seem to like the approach ;-) The problem with a separate sub-package: * Some (older?) openSUSE distribution checks had problems with files and directories that were packaged in multiple sub-packages (even if the sub-packages conflicted with each other). Which made it impossible to get the package in Factory at all. * Even with "supplements" and "suggests", people might have to choose their sub-package manually, if there is just a small mistake. * it becomes a packagers nightmare to adapt all the available plugins and 3rd party apps for all the possible monitoring daemons... So instead of maintaining a growing list of packages that require more and more time for packaging and maintenance (to support users by providing help to install 3rd party app X together with daemon Y), I like to get your feedback about the following approach: * use only the following users - at least for the packages icinga, nagios, naemon and shinken: monitoring * use only the following main group: monitoring * use only the following sub-group: monitorcmd That would allow the 3rd party applications/packages to use the same user/group without any modifications. From a security stand point, this might be a nightmare, correct. But please think how often a user is running more than one monitoring solution in parallel on the same machine? Instead: how often might it be that a user wants to migrate from one monitoring solution to another and has to go through a lot of config files and filesystem permissions before he can start with the real migration? We need to document the new "generic/default monitoring user/group on openSUSE", of course. But we also would need more and more documentation if we follow the current approach - so I do not see this as negative impact. An alternative might be to reduce the available monitoring packages for openSUSE to get more time for packaging and documentation if we stay on the current system. But I like freedome, so I do not like this point ;-) As far as I found out (but I did only a small research), other distributions like Debian are using also just one set of monitoring users/groups for the compatible monitoring applications. If someone knows more, I would be very happy to hear. So my question is: what is your opinion? CU, Lars -- 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] how to avoid SUSE-Backports-policy-SLE-conflict
by Olaf Hering 17 Jan '17

17 Jan '17

How is this supposed to be fixed? [ 86s] build-compare.noarch: E: SUSE-Backports-policy-SLE-conflict (Badness: 10000) Package with name build-compare already in SLE This seems to happen with <repository name="SLE_12"> <path project="openSUSE.org:openSUSE:Backports:SLE-12-SP2" repository="standard"/> <arch>x86_64</arch> </repository> Olaf

6 25

[opensuse-packaging] sync of tumbleweed repos with factory project
by Jordi Massaguer Pla 17 Jan '17

17 Jan '17

Hi, I am not sure if this is the right m.l. so if not, please advice me where to send this question. I am having some trouble with an image that we are creating in obs that has openSUSE:Factory as a repo. The problem happens when we try to, when booting the image on libvirtd, install a package that requires libsystemd-devel, because in the image we have version 232 (which comes from the obs repo), but in the public repo we have version 228, so zypper "complains" and "advices" to do a downgrade. Are other people having this same kind of problem? Is this somehow expected? How long should it take for a package to be in the tumbleweed repo? Should I build my image in a different way? thanks public repo: http://download.opensuse.org/tumbleweed/repo/oss/suse/x86_64/ the image: https://build.opensuse.org/package/show/Virtualization:containers:images:KV… -- 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 help me with kicad-doc-4.0.5 build
by Dave Plater 12 Jan '17

12 Jan '17

I have a problem where kicad-doc update doesn't build in obs home:plater/kicad-doc but builds on my local machine. Using build with a chrooted build I get the same error as in obs but if I then chroot into the build, the command that fails succeeds. In fact I can make clean and make and it succeeds. How can I nail down this problem? My knowledge of dblatex is weak maybe somebody can look at the build log. I've enabled every debug option in dblatex that I can find. 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

2 2

[opensuse-packaging] build of osp-toolkit fails only for Factory
by Michael Ströder 11 Jan '17

11 Jan '17

HI! Why does the build of osp-toolkit fails only for Factory? https://build.opensuse.org/package/show/network:telephony/osp-toolkit Are there relevant differences in compiler version and options? Any way to work around this (preferrably without patching upstream source)? Ciao, Michael.

2 1

[opensuse-packaging] Need help with the failure of "build"
by Dave Plater 11 Jan '17

11 Jan '17

Hi, I've limited internet bandwidth so I can't use osc build, I normally survive with reading online build logs to find problems. Now I've a problem with kicad-docs where a dependency causes a failure but it passes on my local machine. To fix this I'm using "build" direct with my local /var/cache/zypp/packages and the dvd image as the main repos and the update and oss online repos for anything that's not cached. I get a failure after the packages are downloaded when the system is supposed to be installed: [ 73s] [1/29] preinstalling filesystem... [ 73s] error: open of build-root/.init_b_cache/rpms/filesystem.rpm failed: No such file or directory [ 73s] rpm2cpio: build-root/.init_b_cache/rpms/filesystem.rpm: No such file or directory [ 73s] [2/29] preinstalling glibc... [ 73s] /usr/lib/build/init_buildsystem: line 218: cd: build-root: No such file or directory "build-root" is the buildroot specified by "--root build-root". My command line is: build --repo /var/cache/zypp/packages/ --repo /data/packages/RPMS/ --repo /mnt --repo ftp://ftp.up.ac.za/mirrors/opensuse/opensuse/update/leap/42.2/oss --repo http://download.opensuse.org/distribution/leap/42.2/repo/oss/suse/ --root build-root SPECS/kicad-doc.spec My rpmbuild setup points to /data/packages which contains the SPECS, BUILDROOT etc directories due to my root filesystem being on one partition. /etc/rpm/macros.local contains the lines: %vendor "davepl@Arbuthnot" %_topdir /data/packages Thanks Dave Plater -- 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] What can cause this script to fail in Factory/Tumbleweed.
by Dave Plater 10 Jan '17

10 Jan '17

I'm having a problem dvdisaster's bash-based-configure script where it checks for make. It fails in Factory but passes in 42.2 downwards. This is it: # Check for tools # function REQUIRE_GMAKE() { if test -n "$cfg_help_mode"; then return 0 fi echo -n "Checking for gmake: " if (gmake -v | grep "GNU Make") > /dev/null 2>&1 ; then echo "yes" echo "MAKE = `which gmake`" >>Makefile.config return 0 fi; if (make -v | grep "GNU Make") > /dev/null 2>&1 ; then echo "yes" echo "MAKE = `which make`" >>Makefile.config return 0 fi; echo "no" echo "This package requires GNU make (gmake)." exit 1; } The output of make -v is identical in Tumbleweed and 42.2 all I can think of is either bash or grep have changed. I worked around the problem by patching in "echo "MAKE = `which make`" >>Makefile.config" as an else statement but I'd love to know what is actually wrong. 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 8

[opensuse-packaging] How can I find the python package to satisfy a missing python script dependency?
by Dave Plater 10 Jan '17

10 Jan '17

The script with this header works on my local machine but fails in obs, how can I find the python package that provides xml.etree.ElementTree : import xml.etree.ElementTree as etree import os import shutil import re from subprocess import call I've googled xml.etree.ElementTree and found that it exists as ElementTree.py, from that I used find to locate it under /usr/lib64/python2.7/ and used rpm to locate the package which turns out to be "python-xml" but I thought that maybe there was a python tool that could parse the headers and give me the package name. 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 4

Re: [opensuse-packaging] libqt5
by Karl Cheng 09 Jan '17

09 Jan '17

Hi, in openSUSE I believe the Qt 5 version is found in `/usr/bin/qmake-qt5`. You can find the package which has it by running `cnf qmake-qt5`. On Tue, 3 Jan 2017, 01:27 Axel Braun <axelbraun(a)arcor.de> wrote: > > Hello Karl, > > Am Montag, 2. Januar 2017, 20:39:50 CET schrieben Sie: > > With Qt 5 there isn't "one" devel package -- you'll have to look > > through the build scripts and figure out what modules are required. > > > > In your case, this project seems to be using qmake. In the file > > "src/zyGrib.pro", you should see the following: > > > > ``` > > QT += widgets xml > > QT += printsupport > > [snip] > > QT += network xml > > ``` > > > > You'll now need to find the corresponding module name on the Qt > > website[1]. In this case, this project requires the following modules: > > > > - Qt Core > > - Qt GUI > > - Qt Widgets > > - Qt Print Support > > - Qt Network > > - Qt XML > > > > Note that the Core and GUI modules are included by qmake by default, > > and should be included as dependencies in the spec file. > > > > To do so, use the C++ include name, but replace "Qt" with "Qt5" and > > wrap the name inside "pkgconfig()". For example, if you need the "Qt > > D-Bus" module: > > > > ``` > > Requires: pkgconfig(Qt5DBus) >= x.y.z > > ``` > > > > This should work for the vast majority of (if not all) cases -- please > > correct me if something is incorrect or missing. > > > > [1]: http://doc.qt.io/qt-5/qtmodules.html > > That was very helpful, thanks a lot! > One more thing, as I'm not a C++ developer - where is qmake included? I could > not find it as package in one of the standard repos > > docb@T520:~> zypper se --provides qmake > S | Name | Zusammenfassung > | Typ > --+---------------- > +----------------------------------------------------------------+------ > | codelite | Powerful open-source, cross platform code editor for the > C/C++ | Paket > | debhelper | Helper programs for debian/rules > | Paket > | kdevelop5 | C++ IDE using KDE technologies based on KDevelop Platform > | Paket > | libqt5-creator | Lightweight IDE > | Paket > > I tried the mentioned packages as build requirement, but still run into the > problem: > > [ 94s] make[1]: /usr/bin/qmake: Command not found > > Thanks > Axel -- 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] specfile autoformat during submit request
by Olaf Hering 09 Jan '17

09 Jan '17

What can be done to avoid such breakage from the specfile autoformat which runs during submit request? @@ -62,8 +63,8 @@ %package devel Summary: C++ Template Library for Linear Algebra -Group: Development/Libraries/C and C++ # libeigen3-devel was last used at openSUSE 13.1 (version 3.2.0) +Group: Development/Libraries/C and C++ Provides: libeigen3-devel = %{version} Obsoletes: libeigen3-devel < %{version} There no reason to move comments around. Olaf

6 6

[opensuse-packaging] zypp dependencies
by Wolfgang Rosenauer 05 Jan '17

05 Jan '17

Hi, during upgrade to 42.2 I found a small dependency problem which is not resolved correctly with zypper (in my opinion) but probably I missed something. (Someone else just reported the same symptom in bugzilla but closed it again because he fixed it manually.) Hygiea:~ # rpm -q --recommends MozillaFirefox | grep avcodec libavcodec-full >= 0.10.16 Hygiea:~ # zypper search -s --provides libavcodec-full Repository-Daten werden geladen... Installierte Pakete werden gelesen... S | Name | Typ | Version | Arch | Repository --+--------------+-------+------------+--------+----------------------------- i | libavcodec56 | Paket | 2.8.8-24.1 | x86_64 | openSUSE-42.2-0 v | libavcodec56 | Paket | 2.8.8-25.2 | x86_64 | Packman repository (Factory) v | libavcodec57 | Paket | 3.2-4.1 | x86_64 | openSUSE-Leap-42.2-Update v | libavcodec57 | Paket | 3.1.3-2.1 | x86_64 | openSUSE-42.2-0 i | libavcodec57 | Paket | 3.2-6.2 | x86_64 | Packman repository (Factory) I think here is the problem. This output suggests that both variants for those package (openSUSE and packman) provide that. But this is not the case as can be seen here: Hygiea:~ # rpm -q --whatprovides libavcodec-full libavcodec57-3.2-6.2.x86_64 Therefore this is a typical upgrade problem when the upgrade is performed via dup and non-official repos turned off which I would consider best practice but even if the packman repo is enabled again the recommended package is not automatically being pulled. Is this a dependency resolving bug in libzypp or did I miss something? Wolfgang -- 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] Conflicting gcc versions?
by Marco Varlese 05 Jan '17

05 Jan '17

Hi, I have two packages (one linked to the other) to build on different architectures and platforms. In order to build the code for a specific platform I need a specific version of gcc (v.6.0) but when the build kicks off for OpenSuse 42.2 I get the following error despite the fact that gcc6 is available on that distro. unresolvable: conflict for provider of libgcc_s1 >= 6.1.1+r238085-1.12 needed by gcc6 (provider libgcc_s1-gcc6 is conflicted by installed libgcc_s1) I'd like to keep the two .spec files as aligned as possible (hence keeping the dependency in both of them) to avoid bugs introduced in one version of the file vs the other. The build is successful for the Factory repos. Is there a way to fix this problem (i.e. force OBS to use/install a specific version of gcc) ? On an installed distro (42.2), this works fine by installing one version of gcc rather than the other... Thanks, Marco -- 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] libqt5
by Axel Braun 02 Jan '17

02 Jan '17

Hi, I want to build a package that was migrated from qt4 to qt5. Can one of the QT-Experts point me to the right devel packages? a libqt5-devel seems not to exist. https://build.opensuse.org/package/show/home:DocB:branches:Application:Geo/ zyGrib Thanks Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 2