openSUSE Packaging July 2009

packaging@lists.opensuse.org

33 participants
26 discussions

[opensuse-packaging] renaming for nagios-nrpe

by Christian

Hi, I am not very happy with naming of nrpe and its sub-pkg. we have nagios-nrpe-client, nagios-nrpe-server While seeing the client pkg I'll be misled to install this pkg on the remote box and vice versa. But the "client" pkg has to be installed on the nagios box. That's why I am thinking of: - nagios-nrpe it is the package to be installed on the remote box. - nagios-nrpe-plugin or nagios-plugins-nrpe just the name will let you associate to install this pkg on the nagios box. What do you think ? Any recommendations are welcome Kind Regards Chris -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

10 years, 8 months

[opensuse-packaging] Re: --as-needed and pthread

by Michael Matz

Hi, [including some random mailing list, so that the text isn't lost :) ] On Thu, 18 Jun 2009, Cristian Rodríguez wrote: > > there are some packages that fail to build because they miss phtread > > symbols. I have always have the doubt about why there is the > > "-pthread" gcc flag... somewhere I read that's the correct thing to > > do, that using -lpthread is wrong, but without explanations. What > > should I use in these cases? I suppose use -lpthread would be the > > equivalent to what they did without --as-needed... but perhaps the > > behavior without --as-needed was already wrong. > > matz is the right person to answer your question, as far as I know, the > right way is using -lpthread instead of -pthread , is that correct ? Nope, -pthread is better than -lpthread (see below). It's completely possible that something is broken with as-needed vs. pthreads. Those cases have to be identified and then worked around (export SUSE_AS_NEEDED=0), or better, analyzed for the root cause. I didn't get the complete thread, only this forward, so I don't know what the nature of the breakage is, so I can give only speculations: I would think that if something with pthread and as-needed breaks it doesn't get exposed as missing symbols or the like (so that apps don't even start) but rather mysterious breakages related to non-thread-aware functions being used even though -pthread was given as compile and link flag. [background] Regarding the explanation of -pthread/-lpthread: Unfortunately the initial threading support for UNIX was a bit like bolted onto the existing (non thread-aware) libc. For various reasons it was decided that users that aren't interested in threading are not supposed to pay the cost of _potential_ thread safety. This cost is mostly associated with locking some shared data structures for libc and the process output (e.g. output of printf() ). Now, given this criteria, there's not much choice. Basically the user has to announce to the system if or if not the application is thread aware, so that it (the system) can chose between thread-aware or non thread-aware functions. This announcement is done by the -pthread flag. The difference to the -lpthread flag is that it is not only a link time flag (saying that the libpthread library has to be put into the dependence libraries) but also a compile time flag. So for compiling .c to .o files for a thread aware program it's necessary to include -pthread into the compile flags. The effect of that option is system dependend. Usually it will result in the compiler defining some preprocessor symbols (_REENTRANT) so that system headers can choose between different implementations of various posix functions (where the API doesn't make a difference between thread-safe and -unsafe functions) and internal data structures. So, for memoizing the difference: -lpthread is a link time only flag, simply telling the linker to include libpthread into the application. -pthread (without the "l") is a link time _and compile time flag_. Because sometimes different code has to be emitted (for the runtime system including libc) for programs supposed to be thread-safe, this can't be announced only at the link phase, the compiler has to know about this. [more magic] Now, for linux there's a bit magic involved. To make the cost for non thread-safe programs really low some routines in libc _are not thread-safe_. That's fine, those programs aren't linked against libpthread, so they have announced to be not interested in threads. libpthread.so provides thread-aware variants of some functions that are also provided by libc itself. For instance open() and friends is such function. The libpthread variant includes some locking for shared data structures. (Apart from these overriding functions it also includes the usual pthread functions, pthread_*, e.g. pthread_spin_lock). How this all works is because ELF symbols resolution rules say so. If an application calls "open" and is linked against libpthread and libc (which both provide a version of "open", one thread-aware the other not) then the dynamic linker will chose the first it finds. Other things (gcc .spec files) make sure that libpthread is linked in _before_ libc when -pthread is given. This can't be ensured for -lpthread, the latter being simply a request for a random other library, as far as the system knows. So only -pthread, not -lpthread, makes really sure that libpthread is linked at the right place vs. libc, so that it can override the non thread-aware functions of it. [less magic] Having said all this, it usually is just fine to simply link against libpthread (via -lpthread) with linux, as long as you don't mention -lc before. This is because most headers don't care about the _REENTRANT preprocessor define, i.e. they don't change their content depending on the flag, and because ELF rules will still make the functions from libpthread be preferred. But for cross-platform compatibility it's important to use -pthread, _not_ -lpthread. And as it's important for others, and at least good under linux, you can just as well use it always if you need. Ciao, Michael.

11 years, 1 month

[opensuse-packaging] Import of Fedora Packaging Guidelines

by Michal Vyskocil

Hi all, as you know I wrote a post about Fedora Packaging Guidelines [1]. I was working on it during last three weeks (but a little, so it takes a long time :)) and nowadays I'm ready to import a Fedora's content to en.opensuse.org wiki. Now it is on pack.suse.cz [2]. I also checked that none of that page conflicts with an existing content on openSUSE wiki, so it can be imported easily. Tom Callaway [3] from RedHat confirms me that a Guidelines are under Open Publication License [4] and we can use it for SUSE without restrictions. He was also interested on future collaboration and offers some meeting on LinuxTag - it would be nice if anyone from SUSE will be ready to start a discussion. Before import I'd like to ask: Which pages should be excluded for openSUSE? Some pages seems that they are not interesting for SUSE (like Packaging:OldJPackagePolicy [5], Packaging:SugarActivities [6]). Import it, or don't? Second one is how to edit the text and adapt it for SUSE? Change the existing text or leave it and add a SUSE specifics to the beginning or end of page (as suggests Vladimir)? The second way should help us with synchronizing of changes. After that I'll add a warning [7] on the beginning of every page to prevent that some users will use those guidelines and ask for help with editing ;-) [1] http://lists.opensuse.org/opensuse-packaging/2009-02/msg00043.html [2] http://pack.suse.cz/mvyskocil/fedora-packaging-guidelines/ [3] https://fedoraproject.org/wiki/TomCallaway [4] http://fedoraproject.org/wiki/Legal/Licenses/OPL [5] http://fedoraproject.org/wiki/Packaging:OldJPackagePolicy [6] http://fedoraproject.org/wiki/Packaging:SugarActivityGuidelines [7] http://en.opensuse.org/Template:Warning1 Best regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

11 years, 3 months

[opensuse-packaging] New packages for factory

by Stephan Kulow

Hi, I would like to point out something that seems not obvious to everyone: Everyone can maintain packages in factory now There is no limitation anymore on who can maintain packages, _BUT_: - the package has to be submitted and reviewed into an _existant_ devel project - it has to build successfully against factory - the devel project has set a bugowner and maintainer for the package - preferably someone else from the devel project submits it to factory, but this is not a strict requirement - the submitrequest contains a note with informations about the package. Preferably you introduce the package to a mailing list (either topic or opensuse-factory) and point to that introduction in your submitrequest. The information we need are things like this: - who is the bugowner (has to be set in the package)? - how long has it been around? - how well has it been tested? - what is the upstream project? - does it have a track record of security issues? - what is the purpose of having it in the distribution? - what are its users? - what is the license (has to be set in the package)? The main purpose of requiring this informations in the submitrequest is that you think about such things before you write a script that dumps all of freshmeat into factory. I don't want to stop anyone from maintaining a package in our distribution, but I want every package to be maintained, not to be packaged - I hope you understand the difference. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

11 years, 3 months

[opensuse-packaging] Doc files and shared library packaging (Re: /mounts/work_src_done/STABLE/libwebkit not checked in)

by Vincent Untz

Hi, Sending this to opensuse-packaging because I'm not sure about the policy... Le vendredi 31 juillet 2009, à 20:06 +0200, lrupp(a)suse.de a écrit : > Script 'mail_helper' called by lrupp > > Hi vuntz(a)novell.com, > /mounts/work_src_done/STABLE/libwebkit was not checked in by lrupp for the following reasons: > > Packaging documentation in library packages is not allowed: > http://en.opensuse.org/Packaging/Shared_Library_Packaging_Policy#Package_Co… (note that the doc files in question are only license files + NEWS, not API documentation, or "how to use this library" documentation) I made the change, but I consider the policy broken here: if libwebkit11 is LGPLv2 and libwebkit12 is LGPLv3, then I can only have one libwebkit-devel, and therefore one of those two packages won't have the right license installed. Can someone clarify if I'm right or wrong, and if we need to adapt a bit the policy? :-) 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

11 years, 4 months

[opensuse-packaging] bugowner

by Stephan Kulow

Hi, I updated http://www.suse.de/~coolo/factory-status.html with another feature (note that you have to click "show all" - by default it will only show failing packages) This time I mark the devel project red when there is either a cycle in the definition (should soon no longer happen) or if there is no devel project defined. And additionally I try to show the status for bugs: the maintainer column is red if there is no unique "bugowner" in either the package or the project defined and orange if there is at least an unique maintainer defined. The thing is we reach the beta phase and not too far away we will put 11.2 into maintenance and then we need to know who to assign bugs to, so it has to be unique - even if it's a mailing list (with a novell acount :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

11 years, 4 months

[opensuse-packaging] Assuma Project

by Sascha 'saigkill' Manns

Project: home:saigkill Package: assuma Hello Mates, atm i'm trying to create assuma. Compiling runs, but make install not. He says: + make DESTDIR=/var/tmp/assuma-3.0-build install make: Nothing to be done for `install'. How can i define the place who are must installed the files? -- Sincerely yours Sascha Manns openSUSE Ambassador openSUSE Marketing Team openSUSE Build Service Web: http://saschamanns.gulli.to Project-Blog: http://lizards.opensuse.org/author/saigkill Private-Blog: http://saschasbacktrace.blogspot.com

11 years, 4 months

[opensuse-packaging] Upstream version integrated into factory-status.html

by Stephan Kulow

Hi, Freshmeat Digger aka Marcus was so kind to put his data into a file I can read, so I integrated the version infos into http://www.suse.de/~coolo/factory-status.html and added a comment "needs update" when there is a newer version available. Please note that the upstream version does not necessarly refer to our version or is a beta version or whatever. So if you see something with a newer upstream version, try your luck and do a submitreqest (of course unless the devel project already has it). Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

11 years, 4 months

[opensuse-packaging] Build failures regarding debug information

by Richard Guenther

If you experience strange build failures complaining that some debug information files were installed but not packaged you are likely using the %exclude mechanism in a way it wasn't designed for. You should use %exclude if you want to use globs to fill in the files sections but put selected single files into different sub-packages. You should _not_ use %exclude to exclude files from packaging at all! Instead remove the affected files at the end of the %install section. Richard. -- Richard Guenther <rguenther(a)suse.de> Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

11 years, 4 months

[opensuse-packaging] /etc/modprobe.* changes

by Michal Marek

Hi, the new module-init-tools, which will appear in Factory soon, deprecated /etc/modprobe.conf(.local) and only uses /etc/modprobe.d/*.conf configuration files (files without the .conf suffix are still read, but cause a warning). I tried to find and fix packages that install modprobe config files, but in case I missed some, the fix is simple: change /etc/modprobe.d/$name to /etc/modprobe.d/50-$name.conf. Also, mkinitrd should be updated to not copy /etc/modprobe.conf* if it's not there. Michal -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

11 years, 4 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging July 2009