September 2011 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Desktop-related macros for scriptlets
by Vincent Untz 20 Nov '11

20 Nov '11

Hi, Something I probably failed to document properly in 11.4 is the new macros that got introduced for desktop-related things (some of them being, arguably, GTK+-only). They were introduced to fix various issues, and move away from the SuSEconfig scripts. With rpm 4.9, we might be able to use another solution. In that case, the macros listed below will just expand to an empty string and do nothing. So it won't harm to use them either. Desktop-related macros ====================== a) Package installs a .desktop file in /usr/share/applications Macros: %desktop_database_post/%desktop_database_postun What it does: calls update-desktop-database to update a cache mapping MIME types to apps handling them. This is needed to make the desktops aware that an app can handle a MIME type. b) Package installs a MIME definition (in /usr/share/mime): Macros: %mime_database_post/%mime_database_postun What it does: calls update-mime-database to update the database containing information about all MIME definitions. c) Package installs an icon in hicolor (/usr/share/icons/hicolor): Macros: %icon_theme_cache_post/%icon_theme_cache_postun What it does: calls gtk-update-icon-cache (if existing) to update the GTK+ icon cache for hicolor, as specified by the spec. This is needed to make the icon visible to GTK+ apps. d) Package installs an icon in another icon theme (let's say "geeko" theme, /usr/share/icons/geeko) Macros: %icon_theme_cache_post geeko / %icon_theme_cache_postun geeko What it does: calls gtk-update-icon-cache (if existing) to update the GTK+ icon cache for geeko. This is needed to make the icon visible to GTK+ apps. e) Package installs a GSettings schema (in /usr/share/glib-2.0/schemas): Macros: %glib2_gsettings_schema_post/%glib2_gsettings_schema_postun %glib2_gsettings_schema_requires (similar to %py_requires) What it does: calls glib-compile-schemas to build the blob containing the data for all schemas. This is needed to have your app not crash :-) f) Package installs a gio module (in /usr/lib/gio/modules): Macros: %glib2_gio_module_post/%glib2_gio_module_postun %glib2_gio_module_requires (similar to %py_requires) What it does: calls gio-querymodules to update a cache listing all gio modules and the extension points they are using. This is needed to make the gio module known to gio. g) Package installs a gdk-pixbuf loader (in /usr/lib/gdk-pixbuf-2.0/2.10.0/loaders): Macros: %gdk_pixbuf_loader_post/%gdk_pixbuf_loader_postun %gdk_pixbuf_loader_requires (similar to %py_requires) What it does: calls gdk-pixbuf-query-loaders to update a cache listing all gdk-pixbuf loaders and their abilities. This is needed to make the gdk-pixbuf loader known to gdk-pixbuf. h) Package installs a GTK+ (2 or 3) IM module (in /usr/lib/gtk-2.0/2.10.0/immodules or /usr/lib/gtk-3.0/3.0.0/immodules): Macros: %gtk2_immodule_post/%gtk2_immodule_postun %gtk2_immodule_requires %gtk3_immodule_post/%gtk3_immodule_postun %gtk3_immodule_requires What it does: calls gtk-query-immodules-2.0/gtk-query-immodules-3.0 to build a cache listing all IM modules and the locale/language they apply to. You obviously need to only call the gtk2/gtk3 version, depending on which version of GTK+ you target. This is needed to make the IM module known to GTK+. i) Package installs a pango module (in /usr/lib/pango/1.6.0/modules): Macros: %pango_module_post/%pango_module_postun %pango_module_requires (similar to %py_requires) What it does: calls pango-querymodules to update a cache listing all pango modules and information about what they handle. This is needed to make the module known to pango. Thanks, Vincent -- Les gens heureux ne sont pas pressés. -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

5 10

[opensuse-packaging] review split glibc-devel-static
by Rüdiger Meier 19 Oct '11

19 Oct '11

Hi, Even I've tripped over the separated static libc into the new package glibc-devel-static. reference http://old.nabble.com/glibc-devel-static-coming-to-Factory-tt31860569.html#… I think the split itself is a good idea but is the package name well choosen? Fedora/CentOS/RedHat have made the split into glibc-static Mandriva calls it glibc-static-devel Now suse invents glibc-devel-static IMO this is a pain for people trying to make portable spec files depending on static libc. So if possible I would suggest to follow Fedora (because they did that already years ago) and rename it to glibc-static too. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 3

[opensuse-packaging] Obsoletes < vs Obsoletes <=
by Jan Engelhardt 10 Oct '11

10 Oct '11

Hi, in discussions etc. people say one should use < in the obsoletes/provides relation: Obsoletes: foo < %version Provides: foo = %version However this does not reliably "work" when %version did not change across the change (e.g. changing EV from foo-1.0 towards libfoo-1.0), the old foo-1.0 will stick around because it is not obsoleted by libfoo-1.0. So "foo < %version" is actually bogus and should be either <=, or actually foo < %version-%release. <= makes technology unhappy ("package obsoletes itself"), so that leaves us with the %version-%release approach. Does baselibs.conf support obsoletes "foo < <version>-<release>" actually? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 6

[opensuse-packaging] libray whitelist - packages not found help
by Robert Schweikert 30 Sep '11

30 Sep '11

Hi, After some more digging and lots of clicking ;) I end up with the following entries in the whitelist that do not appear to match anything. "libartskde1" : "no package found", "libevolutionglue" : "no package found", "libgladesharpglue-2" : "no package found", "libglibsharpglue-2" : "no package found", "libgnomesharpglue-2" : "no package found", "libgsfglue" : "no package found", "libICE6" : "no package found", "libind_helper0" : "no package found", "libmdbodbc0" : "no package found", "libQtSql4" : "no package found", "libSM6" : "no package found", "libz1" : "no package found", If anyone recognizes one of these names and can confirm that it really no longer exists I would appreciate it. On the contrary, if you do recognize a name and the package still exists in the project please point me to the project and spec that produces the library in question. I'll rip these out within the next couple of days if I do not hear anything back. Help is appreciated, Thanks, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei(a)suse.com rschweik(a)ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 4

[opensuse-packaging] The source service validator is creating havoc in my home project
by Dave Plater 30 Sep '11

30 Sep '11

The above mentioned monstrosity is creating havoc with packages I maintain especially the ones with links eg. ladspa has linked package ladspa-devel and ladspa won't build until it's devel one has. I work with the main package locally it's normally not necessary to download the liked package at double the bandwidth. I'm amusing myself cleaning up ladspa and fixing hydrogen, failing in factory for a few months which uses ladspa-devel and version 0.9.6 builds happily except that my ladspa-devel which hydrogen has difficulty in finding keeps on getting screwed up by the source service validator. Can someone please commit it to staging and fix it before unleashing it on the world. I might add that I'm amusing myself with this work while waiting for an extremely sluggish factory to allow guile1 and guile and lilypond to complete builds. Dave -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] library policy whitelist
by Robert Schweikert 30 Sep '11

30 Sep '11

Hi, As agreed at osc11 I am working to add version numbers to the library whitelist such that we can gradually eliminate the list and enforce the library policy on all appropriate packages. While processing the list I have found a number of packages listed that no longer exist, such as libEMF1 or libglibsharpglue-2. IMHO we should just remove these from the list. There should be no harm, unless there are false positives, i.e. packages I was not able to find but they exist. One such example may be libXrender. libXrender is listed in the whitelist as libXrender1 and it cannot be found using "osc bse". However, using the web search interface one can find xorg-x11-libXrender. This leads me to my next question. How is the whitelist used? Exact matches or loose matches, i.e. the libXrender1 listing matches xorg-x11-libXrender and thus exempts it from the policy or, libXrender1 does not match xorg-x11-libXrender and therefore there is no exemption. Next are the entries in the list that list packages in home: projects. IMHO these should also be removed from the list. Of course we can discuss whether or not packaging policies should be enforced in home projects, but I'd rather not go down that rat hole. Finally some statistics: Current total entries in the whitelist: 119 Packages only in home: projects: 14 Packages not found: 63 Thus the list would only have 42 entries if we decide to remove everything that cannot be found based on the listed name and things that are in home: projects. Thought/Comments? Thanks, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei(a)suse.com rschweik(a)ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 6

[opensuse-packaging] help with naming please - shared library policy naming problem
by Robert Schweikert 29 Sep '11

29 Sep '11

Yes, very ironic.... I am fiddling around with swfdec in home:rjschwei:openshot/libswfdec and am running into a problem with the naming. The build process, by default, produces 2 libraries, one just the decoder (libswfdec) and another bound to GTK+ (libswfdec-gtk). I'd like to keep these separate but am running into trouble. The spec file starts out with: Name: libswfdec-0_8-0 this will meet the shared library policy for "libswfdec" :) . I also have a section in the spec file for the gtk library; this looks as follows: %package gtk ..... This of course produces a package name of "libswfdec-0_8-0-gtk" when I really want "libswfdec-gtk-0_8-0". How do I beat this naming issue into submission. I can disable the build of the gtk library, which avoids the problem of course, but I'd rather not. Help is appreciated. Thanks, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei(a)suse.com rschweik(a)ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 6

[opensuse-packaging] Rationale behind X-SuSE-Unimportant in .desktop files?
by Vincent Untz 29 Sep '11

29 Sep '11

Hi, We have an extension for .desktop files that enables us to say when an application is unimportant; the result is that the application does not appear in the menus by default. To do this, we just add X-SuSE-Unimportant=True to the .desktop file. On my machine, this is used in those files: $ grep -rl X-SuSE-Unimportant /usr/share/applications /usr/share/applications/xload.desktop /usr/share/applications/xclipboard.desktop /usr/share/applications/Xrefresh.desktop /usr/share/applications/Xkill.desktop /usr/share/applications/xcalc.desktop /usr/share/applications/math.desktop /usr/share/applications/xmag.desktop They come from xorg-x11, and libreoffice (math.desktop). This non-standard key is a bit of an issue, as it means that all implementations of the menu specification have to be patched to support this flag. And therefore, I'm wondering: is there any use for this? If we want to hide an application by default, then let's just do it with NoDisplay=true or Hidden=true, and the user can then chooses to display this application with a menu editor. Is there anybody opposed to killing this? Or am I missing something? FWIW, killing this might be as easy as updating update-desktop-files so that passing -u will add NoDisplay=true or Hidden=true, instead of adding X-SuSE-Unimportant=True. Thanks, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 1

[opensuse-packaging] Dropping google-gadgets
by Vincent Untz 29 Sep '11

29 Sep '11

Hi, Unless someone steps in, I'll drop google-gadgets from Factory in a few days. I know of nobody using the package, it was already kind of dead upstream, and with Google killing the non-Linux version, I don't think there's any hope to see this code get really alive again. If you want to maintain it, then you're most welcome :-) I can help you start, if needed. Cheers, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 1

Re: [opensuse-packaging] Request for perl help
by Joop Boonen 29 Sep '11

29 Sep '11

On Mon, September 26, 2011 11:49 pm, Greg Freemyer wrote: > On Mon, Sep 26, 2011 at 4:29 PM, Joop Boonen <joop.boonen(a)boonen.org> wrote: >> Hi Greg, >> >> As you can see this perl module (2.0.15) is quite old because of this probably doesn't support per 5.12 any more. >> http://search.cpan.org/~pmqs/IO-Compress-Bzip2-2.015/ >> I think it's better to use a more resent version. >> http://search.cpan.org/~pmqs/IO-Compress-2.037/ >> Contains IO:Compress:Bzip2 >> http://search.cpan.org/~pmqs/IO-Compress-2.037/lib/IO/Compress/Bzip2.pm >> >> I see that this package already exists: perl-IO-Compress in >> devel:languages:perl >> >> Regards, >> >> Joop. >> > > Joop, > > Thanks but this looking a little more complex. > > perl-IO-Compress won't install because it requires perl-Compress-Raw-Zlib > > perl-Compress-Raw-Zlib won't install because it is obsoleted by > perl-5.12.3-11.16.1.x86_64 > > Assuming that means what it says I'm testing this specfile change to perl-IO-Compress > I would use (if it works, I didn't test it). The reason is because perl 5.12 wouldn't work for example openSuSE 11.3.: %if perl < 5.12 in stead of %if 0%{suse_version} < 1140 > ============ > # Compress::Raw::Zlib is now a core perl function > %if 0%{suse_version} < 1140 > BuildRequires: perl(Compress::Raw::Zlib) >= %{version} > Requires: perl(Compress::Raw::Zlib) >= %{version} > %endif > ============ > > Can you (or anyone else) confirm that the above is accurate. > > Thanks > Greg > -- Regards, Joop. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 3

[opensuse-packaging] Lilypond won't work with guile 2.0, What can I do to prevent it being dropped? Do we really want guile 2.0 yet?
by Dave Plater 28 Sep '11

28 Sep '11

OpenSUSE has jumped way ahead of all the other major distributions by pushing guile-2.0 to factory, this may cause problems for packages such as gnucash if it uses guile to the extent that lilypond does. Lilypond uses guile extensively and are working on porting lily to guile 2.0 but this is their timeline quoted from one of my emails from Graham Percival to the devel list please note that lilypond 2.16.0 may not be released before openSUSE 12.1 and I'm working on 2.14.2 atm the current release : There is absolutely zero chance of lilypond 2.16 using guile 2.0. There is maybe a 10% chance that any version of lilypond will support guile 2.0 in 2011. Total guesswork for future predictions: 50% chance of supporting guile 2.0 before July 2012, 80% chance of support guile 2.0 before the end of 2012. What that means for opensuse is up to you. If you particularly want guile 2.0, then by all means jump in; the more people working on it, the higher the chances are that it'll get done sooner. But based on the amount of work that currently goes into guile 2.0, those are my estimates. Cheers, - Graham and I think this is also relevant, another lily developers reply from the same message: Given that the upcoming ubuntu oneiric apparently does not include guile 2.0, I also don't see a switch to guile 2.0 in the near future. I suppose that we should ask the ubuntu people when they'll finally package guile 2.0. Cheers, Reinhold I've looked at parallel installation of guile 1.8.8 (we jumped from 1.8.7 to 2.0.1) and it doesn't look easy otherwise I would have submitted guile1 but I'm still working on it although I'm not that familiar with the autoconf/automake build system at this level. What this means for openSUSE, lilypond is a very popular musical notation type setting program, the developers pride themselves in the accuracy of the notation positions, it is also used, for musical notation by rosegarden, a popular music and midi composition program. Both of these applications have no substitutes in the open source world and only have costly equivalents in the ms windows world, neither being available for ms windows although there are requests to port for both this won't happen in the immediate future. Rosegarden can work without lilypond as it is only bound to lilyponds notation fonts but the sheet music it exports will be useless so it will lose major functionality. Lilypond won't even be able to be installed via tarball on openSUSE 12.1 without the user removing guile 2.0 completely and installing guile 1.8 via tarball, as a result these users of lilypond and rosegarden will drop openSUSE. I started as a community maintainer by saving both lilypond and rosegarden from being dropped, I'm now very active in maintaining multimedia apps and libs and losing these programs will mean losing a large section of professionals in music related professions that have migrated from the windows world including the people that I've converted from ms windows just by showing them rosegarden although ms's change from xp to vista also helped. For the other packages that directly depend on guile : guile aisleriot gnucash autogen and slib, the change back to guile-1.8.8 won't AFAICS have any negative effects, all of these packages simply have patches for guile 2.0 and after looking at the patches, will most probably build with the patches still in place. I don't know what the situation is with guile users but it is an app for use by apps and not a direct users app. Guile-1.8.7 builds for factory, guile-1.8.7 doesn't build for 11.4. What are we going to do? Drop lilypond, I will keep it alive in home:plater:lilypond with guile-1.8.8 to replace guile-2.0.2 or revert to guile-1.8.8 in line with the other linux distributions? Thanks Dave Plater -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 3

[opensuse-packaging] Request for perl help
by Greg Freemyer 28 Sep '11

28 Sep '11

All, Can someone who knows perl take a look at perl-IO-Compress-Bzip2 and get it to compile for openSUSE and then enable the opensuse repos for it? That seems like it would be useful module for lots of perl programs, so I assume there are other packages that would benefit from it being available. == why I need it I'm trying to update a perl app/module (perl::Image::ExifTool) that has a new requires (per the readme) and now it needs IO::Compress::Bzip2 We have that in D:L:P, but it is disabled for opensuse builds: https://build.opensuse.org/package/show?package=perl-IO-Compress-Bzip2&proj… I branched it to my home to see what happens with openSUSE builds. They all fail: https://build.opensuse.org/package/show?package=perl-IO-Compress-Bzip2&proj… I tried a local build, and it is apparently the self tests that fail === Test Summary Report ------------------- t/100generic-bzip2.t (Wstat: 1792 Tests: 670 Failed: 7) Failed tests: 3-4, 12-13, 15, 125, 131 Non-zero exit status: 7 t/105oneshot-bzip2.t (Wstat: 3584 Tests: 970 Failed: 14) Failed tests: 476-477, 480-481, 484-485, 502, 507, 558-559 562-563, 566-567 Non-zero exit status: 14 t/107multi-bzip2.t (Wstat: 65024 Tests: 694 Failed: 300) Failed tests: 12, 19, 28-32, 34, 36, 40, 48-52, 54, 56 60, 73-74, 80-81, 89-93, 95-101, 103, 105 109, 117-121, 123-129, 131, 133, 137, 152-153 159-160, 168-172, 174-180, 182-188, 190 192, 196, 204-208, 210-216, 218-224, 226 228, 232, 243, 250, 259-263, 265, 267, 271 279-283, 285, 287, 291, 304-305, 311-312 320-324, 326-332, 334, 336, 340, 348-352 354-360, 362, 364, 368, 383-384, 390-391 399-403, 405-411, 413-419, 421, 423, 427 435-439, 441-447, 449-455, 457, 459, 463 474, 481, 490-494, 496, 498, 502, 510-514 516, 518, 522, 535-536, 542-543, 551-555 557-563, 565, 567, 571, 579-583, 585-591 593, 595, 599, 614-615, 621-622, 630-634 636-642, 644-650, 652, 654, 658, 666-670 672-678, 680-686, 688, 690, 694 Non-zero exit status: 254 Files=14, Tests=8339, 15 wallclock secs ( 2.57 usr 0.19 sys + 9.76 cusr 2.07 csys = 14.59 CPU) Result: FAIL Failed 3/14 test programs. 321/8339 subtests failed. === Since, I'm not an experienced perl programmer this is over my depth. Thanks Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 1

[opensuse-packaging] unresolvable: nothing provides device-mapper-devel-32bit
by Per Jessen 28 Sep '11

28 Sep '11

This is really a continuation of a thread from July: http://lists.opensuse.org/archive/opensuse-packaging/2011-06/msg00146.html I'm updating lilo to 23.2 - when I try to build for openSUSE 11.3 and SLE_11_SP1, I see this error. What am I supposed to do about it, if anything? > osc results openSUSE_11.3 x86_64 unresolvable openSUSE_11.3 i586 succeeded openSUSE_11.4 i586 succeeded openSUSE_11.4 x86_64 finished openSUSE_Factory x86_64 finished openSUSE_Factory i586 succeeded SLE_11_SP1 i586 succeeded SLE_11_SP1 x86_64 unresolvable thanks Per -- Per Jessen, Zürich (14.9°C) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 6

[opensuse-packaging] ANNOUNCE: systemd service packaging
by Frederic Crozat 27 Sep '11

27 Sep '11

Hi everyone, I just finished merging the migration macros into the "main" systemd macros, so here is the final result for macros (see file attached). Usage would be like this (it will be hard to put macros in the wrong section ;) : Add : %systemd_requires and if you are compiling your package for old distributions : %if 0%{suse_version} <= 1140 %define systemd_requires %{nil} %endif for scripts : %post %service_add_pre demo.service demo1.service %post %service_add_post demo.service demo1.service %preun %service_del_preun demo.service demo1.service %postun %service_del_postun demo.service demo1.servoce Please note those macros are "systemd preset" aware (this was discussed on this mailing list in july) : you don't need to enable a service in % post : if it is specified in the default preset policy as "enabled by default", it will be handled automatically. These defaults will be in systemd-default-presets package (not yet created, probably tomorrow). -- Frederic Crozat <fcrozat(a)suse.com> SUSE # RPM macros for packages installing systemd unit files # ### # # When a package install systemd unit files, it should use the following macros: # # add %systemd_requires in the specfile # # %post # %service_add_pre demo.service demo1.service # # %post # %service_add_post demo.service demo1.service # # %preun # %service_del_preun demo.service # # %postun # %service_del_postun demo.service # ### # This is for /bin/systemctl %systemd_requires \ Requires(pre): systemd \ Requires(post): systemd \ Requires(preun): systemd \ Requires(postun): systemd \ %_unitdir /lib/systemd/system %service_add_pre() \ test -n "$FIRST_ARG" || FIRST_ARG=$1 \ # disable migration if initial install under systemd \ if [ $FIRST_ARG -eq 1 ]; then \ for service in %{?*} ; do \ sysv_service=`echo $service | sed -e 's/\\.[a-z]*//g'` \ touch "/var/lib/systemd/migrated/$sysv_service" \ done \ else \ for service in %{?*} ; do \ sysv_service=`echo $service | sed -e 's/\\.[a-z]*//g'` \ if [ ! -e "/var/lib/systemd/migrated/$sysv_service" ]; then \ services_to_migrate="$services_to_migrate $sysv_service" \ fi \ done \ if [ -n "$services_to_migrate" ]; then \ /usr/sbin/systemd-sysv-convert --save $services_to_migrate >/dev/null 2>&1 || : \ fi \ fi \ %{nil} # On install, tell systemd to reload its unit files %service_add_post() \ test -n "$FIRST_ARG" || FIRST_ARG=$1 \ for service in %{?*} ; do \ sysv_service=`echo $service | sed -e 's/\\.[a-z]*//g'` \ if [ ! -e "/var/lib/systemd/migrated/$sysv_service" ]; then \ services_to_migrate="$services_to_migrate $sysv_service" \ touch "/var/lib/systemd/migrated/$sysv_service" \ fi \ done \ if [ -n "$services_to_migrate" ]; then \ /usr/sbin/systemd-sysv-convert --apply $services_to_migrate >/dev/null 2>&1 || : \ fi \ /bin/systemctl daemon-reload >/dev/null 2>&1 || : \ /bin/systemctl preset %{?*} >/dev/null 2>&1 || : \ %{nil} # On uninstall, disable and stop services %service_del_preun() \ test -n "$FIRST_ARG" || FIRST_ARG=$1 \ if [ $FIRST_ARG -eq 0 ]; then \ # Package removal, not upgrade \ /bin/systemctl --no-reload disable %{?*} > /dev/null 2>&1 || : \ /bin/systemctl stop %{?*} > /dev/null 2>&1 || : \ fi \ %{nil} # On uninstall, tell systemd to reload its unit files %service_del_postun() \ test -n "$FIRST_ARG" || FIRST_ARG=$1 \ if [ $FIRST_ARG -ge 1 ]; then \ # Package upgrade, not uninstall \ /bin/systemctl try-restart %{?*} >/dev/null 2>&1 || : \ else # package uninstall \ for service in %{?*} ; do \ sysv_service=`echo $service | sed -e 's/\\.[a-z]*//g'` \ rm -f "/var/lib/systemd/migrated/$sysv_service" 2> /dev/null \ done \ /bin/systemctl daemon-reload >/dev/null 2>&1 || : \ fi \ %{nil}

6 13

[opensuse-packaging] download_file services not working
by Stefan Seyfried 27 Sep '11

27 Sep '11

see CrossToolchain:avr/avrdude Is this supposed to work? It works locally with "osc build". -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 1

Re: [opensuse-packaging] Request for perl help
by Greg Freemyer 26 Sep '11

26 Sep '11

On Mon, Sep 26, 2011 at 4:29 PM, Joop Boonen <joop.boonen(a)boonen.org> wrote: > Hi Greg, > > As you can see this perl module (2.0.15) is quite old because of this > probably doesn't support per 5.12 any more. > http://search.cpan.org/~pmqs/IO-Compress-Bzip2-2.015/ > I think it's better to use a more resent version. > http://search.cpan.org/~pmqs/IO-Compress-2.037/ > Contains IO:Compress:Bzip2 > http://search.cpan.org/~pmqs/IO-Compress-2.037/lib/IO/Compress/Bzip2.pm > > I see that this package already exists: perl-IO-Compress in > devel:languages:perl > > Regards, > > Joop. > Joop, Thanks but this looking a little more complex. perl-IO-Compress won't install because it requires perl-Compress-Raw-Zlib perl-Compress-Raw-Zlib won't install because it is obsoleted by perl-5.12.3-11.16.1.x86_64 Assuming that means what it says I'm testing this specfile change to perl-IO-Compress ============ # Compress::Raw::Zlib is now a core perl function %if 0%{suse_version} < 1140 BuildRequires: perl(Compress::Raw::Zlib) >= %{version} Requires: perl(Compress::Raw::Zlib) >= %{version} %endif ============ Can you (or anyone else) confirm that the above is accurate. Thanks Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

Re: [opensuse-packaging] Request for perl help
by Joop Boonen 26 Sep '11

26 Sep '11

Hi Greg, As you can see this perl module (2.0.15) is quite old because of this probably doesn't support per 5.12 any more. http://search.cpan.org/~pmqs/IO-Compress-Bzip2-2.015/ I think it's better to use a more resent version. http://search.cpan.org/~pmqs/IO-Compress-2.037/ Contains IO:Compress:Bzip2 http://search.cpan.org/~pmqs/IO-Compress-2.037/lib/IO/Compress/Bzip2.pm I see that this package already exists: perl-IO-Compress in devel:languages:perl Regards, Joop. On Mon, September 26, 2011 9:43 pm, Greg Freemyer wrote: > All, > > Can someone who knows perl take a look at perl-IO-Compress-Bzip2 and get it to compile for openSUSE and then enable the opensuse repos for it? > > That seems like it would be useful module for lots of perl programs, so I assume there are other packages that would benefit from it being available. > > == why I need it > > I'm trying to update a perl app/module (perl::Image::ExifTool) that has a new requires (per the readme) and now it needs > IO::Compress::Bzip2 > > We have that in D:L:P, but it is disabled for opensuse builds: > > https://build.opensuse.org/package/show?package=perl-IO-Compress-Bzip2&proj… > > I branched it to my home to see what happens with openSUSE builds. They all fail: > > https://build.opensuse.org/package/show?package=perl-IO-Compress-Bzip2&proj… > > I tried a local build, and it is apparently the self tests that fail > > === > Test Summary Report > ------------------- > t/100generic-bzip2.t (Wstat: 1792 Tests: 670 Failed: 7) > Failed tests: 3-4, 12-13, 15, 125, 131 > Non-zero exit status: 7 > t/105oneshot-bzip2.t (Wstat: 3584 Tests: 970 Failed: 14) > Failed tests: 476-477, 480-481, 484-485, 502, 507, 558-559 > 562-563, 566-567 > Non-zero exit status: 14 > t/107multi-bzip2.t (Wstat: 65024 Tests: 694 Failed: 300) > Failed tests: 12, 19, 28-32, 34, 36, 40, 48-52, 54, 56 > 60, 73-74, 80-81, 89-93, 95-101, 103, 105 > 109, 117-121, 123-129, 131, 133, 137, 152-153 > 159-160, 168-172, 174-180, 182-188, 190 > 192, 196, 204-208, 210-216, 218-224, 226 > 228, 232, 243, 250, 259-263, 265, 267, 271 > 279-283, 285, 287, 291, 304-305, 311-312 > 320-324, 326-332, 334, 336, 340, 348-352 > 354-360, 362, 364, 368, 383-384, 390-391 > 399-403, 405-411, 413-419, 421, 423, 427 > 435-439, 441-447, 449-455, 457, 459, 463 > 474, 481, 490-494, 496, 498, 502, 510-514 > 516, 518, 522, 535-536, 542-543, 551-555 > 557-563, 565, 567, 571, 579-583, 585-591 > 593, 595, 599, 614-615, 621-622, 630-634 > 636-642, 644-650, 652, 654, 658, 666-670 > 672-678, 680-686, 688, 690, 694 > Non-zero exit status: 254 > Files=14, Tests=8339, 15 wallclock secs ( 2.57 usr 0.19 sys + 9.76 cusr 2.07 csys = 14.59 CPU) > Result: FAIL > Failed 3/14 test programs. 321/8339 subtests failed. > === > > Since, I'm not an experienced perl programmer this is over my depth. > > Thanks > Greg > -- > To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org > > -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] auto submit to factory?
by Stephan Kulow 26 Sep '11

26 Sep '11

Hi, During the conference there was some discussion that some developers would like to have something submit their packages as soon as they succeed for factory - if they are devel package of course. Some projects (like KDE and GNOME that follow release cycles) obviously do not want that, but it still sounds like we should discuss it. We can for sure implement something that does this, but we have several options: - We can have an option in osc that you need to enable, so osc ci will automatically submit too if it's a _link - We can have an attribute in the devel projects that either enables or disables that a script automatically submits factory devel packages with a diff in .changes file - We can do the above, but automatically open a review for the devel project to accept before the package is commited to factory. This has the drawback atm, that no mail notifcation will go out and people tend to ignore these reviews (only the webui will show them if you login). But this is something that needs fixing in hermes anyway. - We can rely purely on mail reminders in case of unsubmitted changes This mail reminder I want to implement most definitely - and with some chance I'll use next week for it, but I would still like to hear if people are interested in auto submit. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

8 10

[opensuse-packaging] Packaging .desktop files for GNOME
by Manu Gupta 26 Sep '11

26 Sep '11

Hi All I am trying to package sax3 and want to add a shortcut entry to gnome, how do I do it? I have a desktop file which I am attaching along with it and my package can be found at https://build.opensuse.org/package/files?package=sax3&project=X11%3Asax -- Regards Manu Gupta

2 1

[opensuse-packaging] Take care all
by Nelson Marques 23 Sep '11

23 Sep '11

Hi all, I'm leaving, I would just like to thank everyone for the last year in which I've learned a lot from people. All the best, NM -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 1

[opensuse-packaging] make install fails with 'cannot create regular file `/sbin/lilo': Permission denied
by Per Jessen 23 Sep '11

23 Sep '11

I'm trying to update lilo to version 23.2, but I keep getting this error: cp lilo $DESTDIR/sbin/lilo cp: cannot create regular file `/sbin/lilo': Permission denied make[1]: *** [install] Error 1 make[1]: Leaving directory `/usr/src/packages/BUILD/lilo-23.2/lilo-23.2/src' make: *** [install] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.MMYvgO (%install) What's going wrong here? -- Per Jessen, Zürich (16.1°C) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 2

[opensuse-packaging] Required libs: gnome-vfs2 and libfam
by Karl Eichwalder 22 Sep '11

22 Sep '11

There was a strange bug about missing graphics in our docs (bnc#718743). It turned out inkscape was not able to convert SVGs to PNGs because gnome-vfs2 lacked libfam. After adding "BuildRequires: fam" it worked fine. Is this the proper fix? Why is this needed? "rpm -q --requires gnome-vfs2" lists libfam.so.0()(64bit), thus I'd expect that libfam would get installed automatically? -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 5

[opensuse-packaging] hunspell and mythes in lyx
by Cor Blom 22 Sep '11

22 Sep '11

Hi, In the lyx package I specify the paths for the myspell dictionaries and the mythes thesaurus files, so that spellingcontrol and thesaurus is working out of the box without the need for the user to set the right paths, but this is only usefull when there are dictionaries and thesaurus files installed. Installation of lyx does not trigger this at the moment. Using lyx I never noticed this, because I have libreoffice installed, and thus the spellingdictionary and thesaurus file for my language. My question: what do I add to the spec file to trigger the installation of the myspell dictionary and libreoffice-thesaurus in the right language? Regards, Cor -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] TeXmacs build failed: fatal error: guile/gh.h: No such file or directory
by Sascha Manns 22 Sep '11

22 Sep '11

Hello Mates, yesterday i've updated TeXmacs to the present version. Now it builds for 11.3 and 11.4, but not for Factory. It gives me: In file included from Guile/Glue/glue.hpp:19:0, from ./Guile/Scheme/evaluate.cpp:17: Guile/guile.hpp:54:22: fatal error: guile/gh.h: No such file or directory compilation terminated. The full bl can viewed there: http://bit.ly/qAijYd As i'm understanding it needs guile, but guile is included in Factory and it builds. Maybe anyone has an Idea? Have a nice day Sascha -- Sincereley yours Sascha Manns open-slx GmbH Community & Support Agent openSUSE Marketing Team http://saigkill.homelinux.net -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 1

[opensuse-packaging] Why has the Banshee/SLE_11_SP1 repository been removed?
by Manfred Hollstein 21 Sep '11

21 Sep '11

Hi there, - dunno if this is the right forum for such requests - if not, please suggest a different/the right one ;-) - can the Banshee/SLE_11_SP1 repo be re-established please? This application is really superior to the other potential candidates (which are mostly also not supported anymore). TIA, cheers. l8er manfred -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 4

[opensuse-packaging] Specfile Guidelines sweep over Factory
by Jan Engelhardt 21 Sep '11

21 Sep '11

vuntz mentioned it might be good to inform people, though I doubt anyone is going to read this.. As you may have noticed I am going through all factory packages to implement a few of the specfile guidelines[1] in semi-automated fashion, among them the following subtasks: [1] http://en.opensuse.org/openSUSE:Specfile_guidelines automated: - removal of '# norootforbuild' - removal of 'AutoReqProv: on' since this is default anyway manual: - removal of Authors list, no longer desired in factory - removal of %clean section, no longer required - removal of rm -Rf %buildroot in %install when spotted, [1] - changing %{?%jobs:-j%jobs} to %_smp_mflags, [1] - adding %{?_smp_mflags} whereever there is none, or - tagging places more explicitly where parallel build does not work by utilizing the grepable string "-j1" plus a comment if none exists - replacing CFLAGS="$RPM_OPT_FLAGS" ./configure --bindir=%_bindir --infodir=%_infodir ... (and similar) by %configure [shorter] - shlib policy where it seems quick - killing old %changelog (because it's in .changes already) Keep in mind: - obs-service-format_spec_file has been configured for a handful of projects and is adding more line noise besides my actual changes So far. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

14 37

[opensuse-packaging] Notes from packaging guidelines BoF at openSUSE Conference
by Vincent Untz 20 Sep '11

20 Sep '11

Hey, Here are some notes about the packaging guidelines BoF we had on Wednesday, at the openSUSE Conference. It'd be great to reflect what seems to have been agreed in our documentation. Any volunteer for that? Cheers, Vincent ===== Our packaging guidelines documentation - lots of discussion about the effort that was started a while ago to merge with Fedora - rough agreement that we should try to push the parts we both agree on (ie, most of the documentation) upstream, at rpm.org - needs to be discussed with Fedora Having a smaller set of groups - possibly use the same set as Fedora - improve spec-cleaner to do the automatic replacement - need to drop the groups view in the yast software installer Patch tags - long discussion about the merits of tags in the .spec file and inline description inside each patch - Recommendation (not enforced): use patch tags in .spec file as it makes things easier to review, and it's easier to jump in a package. However, in the end, it's up to the maintainer to choose the way he prefers - Rule: choose at least one of tags in .spec file or inline description, so that patches are described. - Rule that should be enforced: whatever patch guideline is used by a package, it should be applied consistently. This means: if you update a package using one approach, please use the same approach. Shared library packaging policy - we have a whitelist of packages that don't have to move to SLPP. That's blocking the enforcement of SLPP. - robjo will update the whitelist so that it tracks a list of packages/versions, instead of a list of packages; that means when a new version of a whitelisted package arrives, SLPP should be applied. - Reminder that it's wrong to obsolete an old version of the library: libfoo2 should not obsolete libfoo1. -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 3

[opensuse-packaging] Gconf header files cannot be found during compilation
by Kirill Kirillov 20 Sep '11

20 Sep '11

Hi! I'm trying to build gtk3 application Xiphos [1] with webkit backend for oS:Factory, but compilation fails with the following error: [ 45/130] cxx: src/main/display.cc -> build/default/src/main/display_1.o In file included from ../src/gui/debug_glib_null.h:36:0, from ../src/backend/sword_main.cc:52: ../src/gui/gui.h:8:32: fatal error: gconf/gconf-client.h: No such file or directory compilation terminated. Please help to fix this problem. gconf2-devel package is installed. [1] https://build.opensuse.org/package/show?package=xiphos&project=home% 3Akkirill -- Kirill Kirillov <>< -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 6

[opensuse-packaging] Forcing dash in library package name
by Jan Engelhardt 19 Sep '11

19 Sep '11

In build.opensuse.org/home:jengelh:dev/gf2x, I have a new package gf2x, where I decided to call the shared library package "libgf2x-1" instead of "libgf2x1" for purposes of clarity. Do Factory maintainers concur with this stance? If so, the shlib-policy check of rpmlint may need to be relaxed to allow the extra dash when $pkgname =~ /\d\w$/ (I don't see it yet necessary for \d\w+). libgf2x-1.x86_64: E: shlib-policy-name-error (Badness: 10000) libgf2x1 Your package contains a single shared library but is not named after its SONAME. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 1

[opensuse-packaging] example or documentation related to integrating Systemd in spec files
by Togan Muftuoglu 16 Sep '11

16 Sep '11

Hi, Is there an example or documentation related to integrating Systemd in spec files showing how to install and activate service files if system has systemd enabled. Ideally I would like to support both systemd enabled and the traditional init system in the spec. Thanks Togan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 8

[opensuse-packaging] [reminder] openSUSE 12.1 Milestone 6 is next week
by openSUSE Roadmap Reminder 15 Sep '11

15 Sep '11

Hello all, openSUSE 12.1 Milestone 6 will be released next week, on Thursday 22 September 2011. 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 For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 1

[opensuse-packaging] rpmlint no-changelogname-tag warning
by Javier Conti 15 Sep '11

15 Sep '11

Hi list, I'm trying to package a software named "pacparser" on OBS. After a few suggestions by experienced maintainers, I now get just a few warnings. Unfortunately, I can't understand what the "no-changelogname-tag" means. I tried putting a global "%changelog" tag and putting a "%changelog" tag for each subpackage, but still get this error for the main package and all subpackages, as shown here: RPMLINT report: =============== python-pacparser.x86_64: W: no-changelogname-tag pacparser.x86_64: W: no-changelogname-tag pacparser-devel.x86_64: W: no-changelogname-tag pacparser.src: W: no-changelogname-tag There is no %changelog tag in your spec file. To insert it, just insert a '%changelog' in your spec file and rebuild it. pacparser-devel.x86_64: W: no-version-dependency-on pacparser*/pacparser-libs/libpacparser 1.2.9 4 packages and 0 specfiles checked; 0 errors, 5 warnings. If I look at the changelog file, I have: $ osc vc pacparser.spec ------------------------------------------------------------------- Wed Sep 14 19:39:35 UTC 2011 - javier.conti(a)gmail.com - ------------------------------------------------------------------- Tue Sep 6 19:34:53 UTC 2011 - javier.conti(a)gmail.com - Cleaned up SPEC file, created devel subpackage ------------------------------------------------------------------- Mon Aug 29 19:10:30 UTC 2011 - javier.conti(a)gmail.com - First release I also can't find the specific warning in the rpmlint docs here: http://en.opensuse.org/openSUSE:Packaging_checks Any hints or pointers to documentation would be greatly appreciated. Thanks, Javier -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

6 8

[opensuse-packaging] server:php:applications ezcomponents-* are in bad shape and should be dropped
by Ralf Lang 14 Sep '11

14 Sep '11

Factory team just rejected the ezcomponents-* packages which I submitted to factory because I needed them as a dependency for phpunit. I looked at them and I am about to drop them from server:php:applications too. These packages are in a bad shape- each of them seems to consist of the complete ezcomponents framework. I will set up a bare minimum of ezcomponents pear packages which is sufficient to run phpunit. I will not maintain any other ezcomponents packages - but I am willing to help anybody who steps up and maintains or at least resubmits a clean version of the individual ezcomponents. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang(a)b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 1

[opensuse-packaging] please ignore --test--
by Robert Schweikert 14 Sep '11

14 Sep '11

-- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjschwei(a)suse.com rschweik(a)ca.ibm.com 781-464-8147 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] liballegro5_0.x86_64: E: shlib-fixed-dependency (Badness: 440) config(liballegro5_0) = 5.0.4-7.1
by Adam Mizerski 13 Sep '11

13 Sep '11

Hi! I'm improving allegro5 package (https://build.opensuse.org/package/show?package=allegro5&project=home% 3AetamPL%3Abranches%3Agames) and one of things I did was adding a allegro5rc config file. To liballegro5_0 file list I added line: %config(noreplace) %{_sysconfdir}/allegro5rc Now in Factory build I get the following error: liballegro5_0.x86_64: E: shlib-fixed-dependency (Badness: 440) config(liballegro5_0) = 5.0.4-7.1 Your shared library package requires a fixed version of another package. The intention of the Shared Library Policy is to allow parallel installation of multiple versions of the same shared library, hard dependencies likely make that impossible. Please remove this dependency and instead move it to the runtime uses of your library. And it's not true because this shared library package requires a fixed version of itself. Do you have any idea why this appeared and what to do with this? -- Adam Mizerski

1 0

[opensuse-packaging] %doc directive.
by Paul Elliott 11 Sep '11

11 Sep '11

I found out that you can have a built source in a %doc directive, but the filename must be relative to where make built it not where make install put it. Also under suse if you put any file in the same directory that %doc puts files, perhaps by make install, then you will get a cpio error complaining about magic numbers. if you create one file via the %doc directive then all files in that directory must be via the %doc directive to avoid this cpio magic number error. Fedroa rpm seems to be more forgiving. The section on The %doc Directive in http://www.rpm.org/max-rpm/s1-rpm-inside-files-list-directives.html says that the %doc directive puts your files into a data base. Could someone tell me more about this database? I am building pdfs and putting them in %doc directives. debian has a database of pdf and other documentation that one must take care of. Does suse have something similar? -- Paul Elliott 1(512)837-1096 pelliott(a)BlackPatchPanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117

1 0

[opensuse-packaging] Enabled source services
by Stephan Kulow 07 Sep '11

07 Sep '11

Hi, To avoid suprises on factory checkin, we want to get rid of the "Autobuild autoformatter" script. Actually we want so for ages, but never came around it. So what we now enabled for openSUSE:Factory is a project wide service that will format the spec file at the moment you commit. Newer osc (> 1.131 afaik) will read this service files and use local tools to format the spec files before commit. This osc has been released as update for all openSUSE release for quite some time, so this shouldn't be a problem, but older oscs will simply ignore the fact. Note that this service file applies to all packages linking against openSUSE:Factory. So if you branch from factory, edit something and commit you will get the formating valid for factory. This also means that it's valid to have a different formating in the future, but there will be a check to verify the format follows some guidelines. E.g. it's important to have a copyright/license header. Additionally we enabled the source validator for both osc and the server. So with new osc versions, you will get a local error - if your osc ignores the source service (or you use --skip-local-service-run), the server will put your package in "broken". This source validator has been alive for a while in the form of a osc plugin, so it shouldn't be news. What we did not yet enable is download_files. Adrian would really like to have the source of tars verified, but I think that downloading tar balls locally all the time is bad. So we're looking for the perfect match there yet. AND PLEASE: we enabled these source services to finally go forward with removing these extra steps at checkin, but osc can act at times a little strange with services. So please report bugs and misbehaviours as you see them, I hope we can sort it out for a better world :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

3 5

[opensuse-packaging] Another review step introduced
by Stephan Kulow 07 Sep '11

07 Sep '11

Hi, The "factory-auto" script is in use for quite some time now, and so far the requests ended directly in new from where they were checked in from the autobuild team. Now we made this more explicit. factory-auto will add "autobuild-team" group as reviewer once it's done and the autobuild-team will review the sources as it did before. The big advantage of having this seperate step is that we can checkin all requests in new in a fast loop. So once we have a new FTP tree or a new DVD we can checkin all changed packages reviewed at that time and then wait for another DVD to finish. And while this happens, autobuild team can continue reviewing. If you notice any problems with this or have a question, please tell. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

1 0

[opensuse-packaging] How often should I update factory?
by Manu Gupta 06 Sep '11

06 Sep '11

Hi How often should I update my factory repo? Also, what difference does it make to have a license as GPL v3 vs GPLv3+ -- Regards Manu Gupta -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 1

[opensuse-packaging] in a lib package, where does the copyright info go?
by Paul Elliott 06 Sep '11

06 Sep '11

As I look at already installed lib* packages I find different answers to this question. some have 3 packages 1) libFOO 2) libFOOX where X comes from the SONAME and contains the .so.x.x.x 3) libFOO-devel And I have seen case like this where the the copyright and other docs is in 1)libFOO I have also seen cases that look like this 1)libFOOX where X comes from the SONAME and contains the .so.x.x.x 2)libFOO-devel and the copyright was in libFOO-devel I have even seen cases where there was a copyright file in the libFOOX package! In the case of a library, which packages get the copyright file and which don't? When is there supposed to be the libFOO package (without the SONAME number)? I can not find where policy on this is documented for open suse. -- Paul Elliott 1(512)837-1096 pelliott(a)BlackPatchPanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117

6 9

Re: [opensuse-packaging] How often should I update factory?
by Milisav Radmanic 06 Sep '11

06 Sep '11

Am Dienstag, 6. September 2011, 11:01:43 schrieb Manu Gupta: > Hi > > How often should I update my factory repo? > > Also, what difference does it make to have a license as GPL v3 vs GPLv3+ The difference is that with the "+"-sign room for interpretation is opened up. The plus sign can be read as being just a part of the version name, but also in the meaning of "v3 and any later". Since nobody knows the license conditions of a GPL that is yet-to-come it might not be the best to leave it open to this interpretation. regards Milisav -- Milisav Radmanic Engineering Manager Server Technologies SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany

1 0

[opensuse-packaging] Dropping old failures
by Stephan Kulow 06 Sep '11

06 Sep '11

Hi, There are various packages that fail for >100 days and I'm going to drop them now. I can understand that not everyone can fix his package every week, but 100 days is a reasonable expectation. You can find the list when looking at openSUSE:Factory's project status - http://is.gd/OJ1xK8 Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

5 5

[opensuse-packaging] scala packages
by Denny Beyer 01 Sep '11

01 Sep '11

Dear all, I'm preparing the updated Scala packages at the moment. Two questions I would like to throw in and would like to get some feedback. 1. Where is a good place to keep and publish scala packages? It used to be in contrib up until now. I could imagine to have in parallel to java a scala directory with scala plus additional packages. It could also live in the java repo. 2. There are now two maintained stable scala versions: 2.8.x and the 2.9.x series. Should both be made available and what would be a good naming scheme for the packages? 3. Is anybody using the packages at all? I never received any requests/bug reports. cheers, Denny -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

2 1

[opensuse-packaging] linux-g++ scope is skipped by qmake
by Michal Vyskocil 01 Sep '11

01 Sep '11

Hi all, because of the last change in linker, Publishing/gle-graphics don't build because of the missing -ldl definition in linker. I went through makefiles and realized the problematic Makefile is generated using qmake from qgle.pro file, however it contains following definition linux-g++ { LIBS += -ldl } From my understanding of qmake: Project Files [1] this should be enabled in linux-g++ target. On the other hand qmake -d shows me the test fails, so this section is skipped. Can anyone tell me how to fix that in way, that will be upstreamable? I changed it to unix, but I am not sure that patch will be accepted. [1] http://doc.qt.nokia.com/latest/qmake-project-files.html Regards Michal Vyskocil

1 0