March 2017 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] where are .desktop files stored?
by Olaf Hering 23 Mar '17

23 Mar '17

My silly grep over 10k .spec files gives this list of directories where *.desktop files are stored. Who is the consumer of .desktop files and why are there some many different places to store them? And: Is a simple "%_datadir/applications" not good enough for most of them? It would be so easy. And compatible. Olaf 560 %_datadir/applications 224 /opt/kde3/share/applications/kde 171 %_kf5_applicationsdir 140 /opt/kde3/share/services 122 %_kde4_servicesdir 105 %_kf5_servicesdir 63 %yast_desktopdir 58 %_kde4_applicationsdir 55 %_sysconfdir/xdg/autostart 30 %_kf5_servicetypesdir 29 %_datadir/xfce4/panel/plugins 28 /opt/kde3/share/servicetypes 28 /opt/kde3/share/services/kaddressbook 25 %_datadir/xsessions 22 /opt/kde3/share/applnk/.hidden 22 %_kde4_servicesdir/kded 20 /opt/kde3/share/mimelnk/application 16 /opt/kde3/share/services/kontact 13 /usr/share/applications 13 /opt/kde3/share/services/kded 13 %_kf5_configdir/autostart 11 %_datadir/mimelnk/application 9 /opt/kde3/share/autostart 8 /opt/kde3/share/applnk/System/ScreenSavers 8 %_kf5_sharedir/%name/extras/multimedia 7 /opt/kde3/share/apps/kicker/applets 7 %_kde4_servicesdir/ServiceMenus 7 %_datadir/applications/kde4 6 %desktopdir 6 %_kde4_servicetypes 6 %_datadir/xfce4/panel-plugins 5 /opt/kde3/share/apps/konqueror/servicemenus 5 /opt/kde3/share/appl*/* 5 %_kde4_servicetypesdir 5 %_datadir/kde4/services 5 %_datadir/autostart 4 %_libdir/gnome-settings-daemon-3.0/gtk-modules 4 %_kde4_appsdir/solid/actions 4 %_datadir/solid/actions 4 %_datadir/kservices5 3 /opt/kde3/share/mimelnk/text 3 /opt/kde3/share/mimelnk/fonts 3 /opt/kde3/share/applnk/Settings/WebBrowsing 3 %buildroot/%_datadir/applications 3 %_libdir/%name/share/applications 3 %_datadir/xgreeters 3 %_datadir/system-config-selinux 3 %_datadir/kde4/services/ServiceMenus 2 /usr/share/autoinstall/modules 2 /opt/kde3/share/services/kresources/kcal 2 /opt/kde3/share/services/kresources 2 /opt/kde3/share/services/kdemmbackends 2 /opt/kde3/share/apps/remoteview 2 %_prefix/share/applications/YaST2 2 %_kf5_servicesdir/ServiceMenus 2 %_kde4_servicesdir/phononbackends 2 %_kde4_appsdir/kwin 2 %_kde4_appsdir/konqueror/dirtree/remote 2 %_jvmdir/%sdkdir/jre/lib/desktop 2 %_datadir/wayland-sessions 2 %_datadir/kservices5/ServiceMenus 2 %_datadir/kde4/services/phononbackends 2 %_datadir/gnome/wm-properties 2 %_datadir/gnome/autostart 2 %_datadir/gdm/greeter/applications 2 %_datadir/applications/YaST2 1 Swift/resources 1 /usr/share/xsessions 1 /opt/kde3/share/services/searchproviders 1 /opt/kde3/share/mimelnk/interface 1 /opt/kde3/share/mimelnk/inode 1 /opt/kde3/share/mimelnk/audio 1 /opt/kde3/share/mimelnk/* 1 /opt/kde3/share/apps/kttsd 1 /opt/kde3/share/apps/konqueror/dirtree/remote 1 /opt/kde3/share/apps/kicker/extensions 1 /opt/kde3/share/apps/khtml/kpartplugins 1 /opt/kde3/share/apps/khelpcenter/searchhandlers 1 /opt/kde3/share/apps/kabc/formats 1 /opt/kde3/share/applnk/Development 1 /opt/kde3/share/applnk 1 /etc/xdg/autostart 1 %yast_desktopdir/groups 1 %kdeprefix/share/applications 1 %gnome_prefix/share/applications 1 %gnome_prefix/share/application-registry 1 %gnome_datadir/applications 1 %_kf5_sharedir/xsessions 1 %_kf5_sharedir/locale/* 1 %_kf5_sharedir/akonadi/agents 1 %_kf5_sharedir/%name/extras/system 1 %_kf5_servicesdir/kded 1 %_kde4_servicesdir/qimageioplugins 1 %_kde4_appsdir/remoteview 1 %_kde4_appsdir/konqsidebartng/virtual_folders/services 1 %_datadir/tracker/miners 1 %_datadir/susehelp/meta 1 %_datadir/services/kded 1 %_datadir/remoteview 1 %_datadir/konqsidebartng/virtual_folders/services 1 %_datadir/kdm/sessions 1 %_datadir/kde4/apps/ksmserver/windowmanagers 1 %_datadir/gdm/autostart/LoginWindow 1 %_datadir/applications/kde 1 %_datadir/appdata 1 %_datadir/akonadi/agents 1 %_datadir/Thunar/sendto

4 7

[opensuse-packaging] python singlespec: broken python3 packages
by Mikhail Terekhov 23 Mar '17

23 Mar '17

Hello, After conversion to singlespec some python3 packages became broken, ex: https://build.opensuse.org/package/show/KDE:Qt5/python-sip https://build.opensuse.org/package/show/KDE:Qt5/qscintilla-qt5 The logs in web interface say that patches to python3-* files could not be applied. Obviously the python3-* files has been deleted during conversion. I've tried to branch these packages but the branches also can't be compiled with the same errors. How to fix this problem? Regards, Mikhail -- 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] X11:wxWidgets/python-wxWidgets broken due to deleted link openSUSE:Factory/python-wxWidgets
by Joop Boonen 22 Mar '17

22 Mar '17

An OBS package issue exists. X11:wxWidgets/python-wxWidgets broken due to deleted link openSUSE:Factory/python-wxWidgets . https://build.opensuse.org/package/show/X11:wxWidgets/python-wxWidgets Warning: Files could not be expanded: openSUSE:Factory/python-wxWidgets: package 'python-wxWidgets' does not exist Can this please be fixed. By moving the openSUSE:Factory/python-wxWidgets to this location (X11:wxWidgets/python-wxWidgets). Reagds, Joop. -- 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] how will zypper treat conflicts/provides/obsoletes?
by jan matejek 22 Mar '17

22 Mar '17

hello, what will happen if a packageA has something like: Provides: packageB = %version-%release Obsoletes: packageB < %version-%release Conflicts: packageB < %version-%release will zypper use it to upgrade from packageB to packageA? will the Conflicts clause ensure that packageB is completely removed before installing packageA? will something else happen? will nothing at all happen? What I'm actually after is the second question - making sure that in an upgrade, packageB is completely removed, %postun scriptlets and all, before even starting to install packageA. Is a Conflics clause a way to ensure that? Are there any (other) options? thanks m.

4 5

[opensuse-packaging] Last AC3 patent expired
by Luigi Baldoni 21 Mar '17

21 Mar '17

See https://ac3freedomday.org. Is this of any relevance to multimedia:libs or multimedia:apps ? Can something be brought over from packman or enabled (e.g. in ffmpeg)? Regards -- View this message in context: http://opensuse.14.x6.nabble.com/Last-AC3-patent-expired-tp5083284.html Sent from the opensuse-packaging mailing list archive at Nabble.com. -- 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] Package scheduled for removal from openSUSE:Factory
by Dimstar / Dominique Leuenberger 17 Mar '17

17 Mar '17

Dear packagers and users, The package swipl has been scheduled for removal after it has been failing to build for 170 days without any reaction from the maintainers [0] >> zypper info swipl >Information for package swipl: >------------------------------ >Repository : Tumbleweed >Name : swipl >Version : 7.2.2-1.8 >Description : > Edinburgh-style Prolog compiler including modules, autoload, > libraries, Garbage collector, stack expandor, C interface, GNU > readline and GNU Emacs interface, a very fast compiler,and an X11 > interface using XPCE > (see http://www.swi.psy.uva.nl/projects/xpce). If you care for this package - then this is your chance now to step up and claim maintainership and save it - not by words, but by actions. If you intend on working on it, please shoot me a message so I'm aware of it, including an estimated timeframe when you expect to have a fix ready. A couple more days or less won't hurt of course. But without any reaction, this package is history in a couple days. Cheers, Dominique [0] https://bugzilla.opensuse.org/show_bug.cgi?id=1023722 -- Dimstar / Dominique Leuenberger <dimstar(a)opensuse.org>

2 2

[opensuse-packaging] Package using stdlib.h broken on Factory
by Ferdinand Thiessen 17 Mar '17

17 Mar '17

Hi, I noticed that if a package is using stdlib.h, then the build will fail on Factory with "E: a implicit-fortify-decl". To show this I have created this package: https://build.opensuse.org/package/show/home:susnux/a If I read the man page ( https://linux.die.net/man/3/ptsname ), it shows that only _XOPEN_SOURCE is needed for the prototype: > char *ptsname(int fd); But it only works on Factory if _GNU_SOURCE is defined. Do I miss something? Regards, Ferdinand -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 2

[opensuse-packaging] Move /etc/init.d hierachy to own RPM
by Thorsten Kukuk 17 Mar '17

17 Mar '17

Hi, All packages from my default installation are now free of init.d scripts/insserv usage (at least when the last package maintainers accept and/or submit their packages to Factory finally). I would like to use this opportunity to set an example and make it visible to people, that systemd is the default and init scripts are legacy, deprecated and should be converted to systemd units. Why? If you install a system, you will not have insserv or other tools to activate and run init scripts installed by default anymore. But there is still the /etc/init.d hierachy. So I would like to move that directories to an own RPM, prefereable "insserv-compat". Why "insserv-compat"? And what does this mean for existing packages? - packages having correct insserv requires will not notice this - packages with broken insserv requires, but which builds currently by accident, will continue to build by accident. - packages messing up with their requires and currently don't build, will continue to not build until somebody fixes them. But this is completly independent of this change - rpm will fail to build until either somebody converted rpmconfigcheck to a systemd unit file or we drop it. Opinions? Objections? If nobody has good reasons against this, I will make this change in 2-3 weeks. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 10

[opensuse-packaging] Build issues against openSUSE Tumbleweed
by Dimstar / Dominique Leuenberger 15 Mar '17

15 Mar '17

Dear hackers and packagers, My sincere apologies - once again we are struck by a delete request having impacts way beyond what we expect to to touch. As part of the cleanup activities, gcc5 has been removed from the distro. This also impacts libffi4; The distro has gained a new libffi implementation (libffi7, version 3.2.1) which has been around for a while. As we now deleted libffi4, though, it became apparent that not everything is yet rebuilt against libffi7 (no real surprise there: we have the rebuild strategy of least changes implemented) So far nothing bad - except: as libffi4 has been removed from openSUSE:Factory, this not only impacts /standard (which we would not have a problem - ever), but also /snapshot. Which means all the builds against openSUSE:Tumbleweed will be broken at least until the next snapshot can be published (0313 that is). I apologize for this issue caused and will be trying to find a workaround for now to get you guys going again. Please stay tuned. Cheers, Dominique -- Dimstar / Dominique Leuenberger <dimstar(a)opensuse.org>

3 5

[opensuse-packaging] update-alternatives and manpage conventions
by jan matejek 14 Mar '17

14 Mar '17

I am now writing better support for update-alternatives in the python singlespec macros. The way it works now, it is very well suited to enforce naming conventions. So.... what are these? :) Far as I could figure out, you install manpages as "manpage.1" and some magic converts it to "manpage.1.gz"? Should the alternatives entry be /etc/alternatives/manpage.1 or /etc/alternatives/manpage.1.gz ? Should the %ghost %{_mandir}/man1/manpage.1 be called that, or should it be manpage.1.gz? Or does it depend on whether the original manpage.1 is gzipped or not? -- at the moment, the enforced convention in singlespec is that base %_mandir names depend on the original file, and /etc/alternatives entries are always named without ".gz". Should that be changed to something else? -- Relatedly, is it common in any packages to make alternatives for something other than /usr/bin and %_mandir? I know that Java plays with /usr/lib/jvm, but other than that? thanks m.

2 2