June 2011 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] preprocessor sanity checks ?
by Cristian Rodríguez 15 Jun '11

15 Jun '11

Hi: Is there any way to enable some kind of preprocessor basic sanity checks... ? found a package that used #defina instead of #define .. and no warning was emitted .. hints ? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

8 13

[opensuse-packaging] SLES_9 - Server returned an error: HTTP Error 404: Not Found
by Per Jessen 15 Jun '11

15 Jun '11

How should I interpret this: osc results SLES_9 x86_64 Server returned an error: HTTP Error 404: Not Found SLES_9 I see this for SLES_9 i586 and x86_64. -- Per Jessen, Zürich (16.2°C) -- 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 2 is next week
by openSUSE Roadmap Reminder 15 Jun '11

15 Jun '11

Hello all, openSUSE 12.1 Milestone 2 will be released next week, on Wednesday 22 June 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

1 0

[opensuse-packaging] Watch out configure scripts detecting kernel version
by Cristian Rodríguez 14 Jun '11

14 Jun '11

Hi: Just a heads-up, I'm already seeing configure scripts who do not handle new linux kernel version scheme, in particular ones that assume that linux version starts with number 2. Next time you build your packages ensure there is no buggy regular expression checking the value of uname -r. Cheers. -- 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] unresolvable confusion
by Robert Schweikert 14 Jun '11

14 Jun '11

Hi, Could someone take a look at https://build.opensuse.org/project/show?project=Virtualization%3ACloud%3AOp… and help me figure out why for the SLES 11 SP1 build pwgen shows up as unresolvable? I added pwgen to the project via _aggregate yesterday and https://build.opensuse.org/package/show?package=pwgen&project=Virtualizatio… shows that it built successfully for SLES 11 SP1. pwgen is part of the openSUSE distributions, thus it is disabled for those repositories. Shouldn't pwgen be picked up for the SLES 11 SP1 build. Confused, help is appreciated. Thanks, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rschweikert(a)novell.com rschweikert(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] Re: [packman] mjpegtools 2.0.0-1
by Dave Plater 12 Jun '11

12 Jun '11

On 06/12/2011 02:38 PM, Manfred Tremmel wrote: > Am Sonntag, 12. Juni 2011 schrieb Dave Plater: >> On 06/09/2011 08:15 PM, Manfred Tremmel wrote: >>> Am Donnerstag, 9. Juni 2011 schrieb yahoo-pier_andreit: >>>> from tumbleweed I'm trying to update to mjpegtools 2.0.0-1 from >>>> 1.9.0.0 but yast shows me this conflicts: >>> I'll take a look on it this weekend. If I'm not able to fix the >>> gstreamer incompatibility with mjpegtools 2.0.0 I'll add a >>> mjpegtools compatibility package with the old libs. >> The developers of mjpegtools are misguided about library versioning. > So it is. > >> I attempted to update openSUSE multimedia:libs to 2.0.0rc1 last >> December and eventually reverted to the existing 1.9.0. The >> libraries are at major version 2 and they end up like this >> "liblavfile-2.0.so.0.0.0" but the unversioned devel link is >> "liblavfile.so". There's no logic here at all, if the developer >> wanted parallel installable libraries why not match the devel parts >> too and install the headers in versioned directories. To cut a long >> story short I filed an upstream bug and started to fix the library >> build to give proper so numbers because 2.0.0rc1 broke gstreamer in >> factory and because there was plenty of other things to update and >> fix for the looming release of 11.4, I reverted to the old version >> and gstreamer was happy. If you patch gstreamer to work with a > Sounds good. > >> broken package it will complicate matters more, rather revert to >> 1.9.0 and help to fix the real problem with 2.0.0.. When I saw >> Packman had 2.0.0 I thought that it would have a fixed build, >> unfortunately not. > I've done a quick and dirty solution at packman now. I've splitted out > the libs into a mjpegtools-lib package and readded mjpegtools 1.9.0 as > mjpegtools19. Both library packages (mjpegtools-lib and mjpegtools19- > lib) can be installed without conflicts. Packagis having problems to > build against mjpegtools 2.0.0 can use BuildRequires: mjpegtools19-devel > >> As all this happened at the beginning of >> February I can't be sure but AFAIR I had gone as far as tracing the >> gstreamer problem to the lib builds in mjpegtools, I've started to >> pick at mjpegtools again and it will become priority one after I've >> finished a few other packages. I have to cope with openSUSE library >> policy and I'm not sure what the eventual outcome of library >> developers making their own method of shared library parallel >> installation, I'm working on a new package where the dev has done >> the same as this but it's new and not as important as mjpegtools >> which can silently break plenty of packages and render multimedia >> unusable. > Thanks for your engagemnet. > >> I'm about too collapse into bed, coffee doesn't work anymore so >> please ask for clarification on anything I've said that sounds >> insulting because that's not my intention. I'm cc ing >> opensuse-packaging for comments and guidance. > Sorry I can't do much on this topic. My skills in c programming are not > so great and I've to big projects @work, so my sparetime is extremely > limited. > The move to get openSUSE multimedia involved in Packman can only reduce your workload. Sorry I can't say much I've got things to do, read the email I cced to the Packman list when you've got time it's long. Regards 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] Re: [packman] mjpegtools 2.0.0-1
by Dave Plater 12 Jun '11

12 Jun '11

On 06/09/2011 08:15 PM, Manfred Tremmel wrote: > Am Donnerstag, 9. Juni 2011 schrieb yahoo-pier_andreit: >> from tumbleweed I'm trying to update to mjpegtools 2.0.0-1 from >> 1.9.0.0 but yast shows me this conflicts: > I'll take a look on it this weekend. If I'm not able to fix the > gstreamer incompatibility with mjpegtools 2.0.0 I'll add a mjpegtools > compatibility package with the old libs. > > The developers of mjpegtools are misguided about library versioning. I attempted to update openSUSE multimedia:libs to 2.0.0rc1 last December and eventually reverted to the existing 1.9.0. The libraries are at major version 2 and they end up like this "liblavfile-2.0.so.0.0.0" but the unversioned devel link is "liblavfile.so". There's no logic here at all, if the developer wanted parallel installable libraries why not match the devel parts too and install the headers in versioned directories. To cut a long story short I filed an upstream bug and started to fix the library build to give proper so numbers because 2.0.0rc1 broke gstreamer in factory and because there was plenty of other things to update and fix for the looming release of 11.4, I reverted to the old version and gstreamer was happy. If you patch gstreamer to work with a broken package it will complicate matters more, rather revert to 1.9.0 and help to fix the real problem with 2.0.0.. When I saw Packman had 2.0.0 I thought that it would have a fixed build, unfortunately not. As all this happened at the beginning of February I can't be sure but AFAIR I had gone as far as tracing the gstreamer problem to the lib builds in mjpegtools, I've started to pick at mjpegtools again and it will become priority one after I've finished a few other packages. I have to cope with openSUSE library policy and I'm not sure what the eventual outcome of library developers making their own method of shared library parallel installation, I'm working on a new package where the dev has done the same as this but it's new and not as important as mjpegtools which can silently break plenty of packages and render multimedia unusable. I'm about too collapse into bed, coffee doesn't work anymore so please ask for clarification on anything I've said that sounds insulting because that's not my intention. I'm cc ing opensuse-packaging for comments and guidance. Regards Dave Plater Maintainer openSUSE multimedia libs and apps Packman user name davepl openSUSE user name plater -- 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] RFC: best way to deal with unresolvable state created by automatic Requires (for gobject-introspection)
by Vincent Untz 10 Jun '11

10 Jun '11

Hi, Thanks to Dominique, packages using gobject-introspection how have automatic typelib() Requires/Provides. For those who don't know, the introspection support is a way to easily use C libraries from the GNOME stack, from various other languages (js, python, vala, etc.). In concrete terms, libgtk-2_0-0 ships this file /usr/lib/girepository-1.0/Gtk-2.0.typelib and gets a typelib(Gtk) = 2.0 Provides. Similarly, libgtk-3-0 will get a typelib(Gtk) = 3.0 Provides. However, we're stuck with one issue: for packages depending on a typelib file, the Requires we get are not necessarily versioned, because there is not necessarily the information for which version to require in the code. And so we end up with this in the build service: "have choice for typelib(Gtk) needed by python-gobject: libgtk-2_0-0 libgtk-3-0" This is an issue in the build service, and it's also something that zypper would have to deal with (although it might just take the provider with the bigger version?). I'd like to hear what people think is the best way to solve this. The possible options we had so far were: 1) Explicitly require libgtk-3-0 so that there would be a provider anyway 2) Have a "Prefer: libgtk-3-0" in the prjconf (but that wouldn't help zypper) 3) Create some kind of manifest file for the package, where we tell which version of typelib(Gtk) is required, and use this data when generating the Requires. 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

2 1

[opensuse-packaging] manual page warning for factory builds
by Togan Muftuoglu 10 Jun '11

10 Jun '11

Hi When building packages locally with osc or in the OBS for factory RPMLINT reports the following for the man pages "manual-page-warning can't find macro file `deunicode.tmac' This man page may contain problems that can cause it not to be formatted as intended." The package builds fine for openSUSE_11.3 and openSUSE_11.4 Any ideas ? Thanks Togan -- 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] Chromium build problems on openSUSE with make 3.82
by Sankar P 10 Jun '11

10 Jun '11

Hi, I am trying to build chromium from the sources on openSUSE. During this, for any change I make in any file, all the sources of all the modules (dependents etc.) were getting recompiled. So, for a simple "cout " addition, it took about 3 hours to build. I asked for help in the chromium list and found that this issue has happened in fedora and openSUSE with the make version 3.82 and works fine in make version 3.81 Related bug ids: http://code.google.com/p/gyp/issues/detail?id=197 http://code.google.com/p/chromium/issues/detail?id=64703 Can someone help find out why this issue is happening and what is the right fix for this ? Should I file a regression bug on make 3.82 on openSUSE ? I did a google search and dug thru' man pages but with my inadequate packaging knowledge could not find out the right solution. Any help is appreciated. thanks. -- Sankar P http://psankar.blogspot.com -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

4 6