openSUSE Packaging June 2009

packaging@lists.opensuse.org

43 participants
35 discussions

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

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

/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

Packages that Requires: pkg-config

by Cristian Rodríguez

Hi: There is a very common inconsistency in packages that include *.pc files, some do Requires: pkg-config while some others dont, I think we need to decide to either do require it or not, and raise an error when this policy is violated.. what you think ? should it be required or not ? My vote is that pkgconfig is a build dependecy only, and hence -devel packages should not require pkgconfig. -- 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

Factory submission overview page

by Stephan Kulow

Hi, Today I wrote a litte script to show the current status of factory package submissions. The result is http://www.suse.de/~coolo/factory-status.html - it's not yet updated regularly as I plan to integrated build failure status into it, so you guys have one place to look for things :) If you think this could be more useful, feel free to tell me about enhancements. There are various pending submitrequests to devel project and existing diffs in the devel project that aren't yet pushed. This may be wanted, but it shouldn't be for currently failing packages (which is why I want to integrate that too). 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

Packaging big files

by Cristian Morales Vega

What is the best way to package big/redistribution restricted files? Packman seems to use http://sourceforge.net/projects/autodownloader, but it has the problem that it isn't integrated with RPM. From an user POV you still get updates automatically, but you can't use rpm -V to check the installation integrity. There is anything better? Any plan for repositories with metadata that point to BitTorrent packages? A patched rpmbuild that adds the RPM headers for unpackaged files that get downloaded in a %pre scriptlet? In the worst case... from a quick look I didn't saw anything, but there is any library to easily access to the RPM DB so I could patch autodownloader? addFile(package, file_path)? ...and, we have any official "limit" to the file size of a package? When it's a problem for mirrors? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

11 years, 5 months

comps.xml for RH-style rpmmd repositories

by Schlomo Schapiro

Hi, I noticed that the repositories created by the build service for RHEL/CentOS/... do not contain the comps.xml file that is required by the installer to offer packages from them. Would it be possible to autocreate a comps.xml that contains one group (= name of project) and thus offers to install the packages from there? Or has this already been discussed elsewhere (Google did not help me whith this one)? Regards, Schlomo -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

11 years, 5 months

Re: [opensuse-buildservice] Build Service Project Cleanup Round

by Adrian Schröter

Small top-post heads up. Since we were not able to agree how to deal with removing the repositories, I will just disable build for the projects this week. This can get reverted in any case, nothing gets lost. (except for the projects where people wrote me not do it of course) But I really would like also free our stage server and the mirrors with not used packages also later .... I think this is acceptable so far for everybody. bye adrian Am Montag, 22. Juni 2009 17:11:48 schrieb Greg Freemyer: > On Mon, Jun 22, 2009 at 5:43 AM, Adrian Schröter<adrian(a)suse.de> wrote: > > Hello, > > > > we got more than 6500 projects since the start of the opensuse.org Build > > Service instance (plus the projects which got removed again by their > > owners). These projects contain more than 13000 repositories, which get > > need to get in sync by our service. > > > > This takes obviously resources on the server side and quite a number of > > these projects are not touched since a while. So I assume they are not > > needed anymore. > > > > So I think it is a good idea to free the resources from these projects > > and give it to us active people :) > > > > This will basically affect all projects, where no source changes happened > > since 1 year or more. > > I'm afraid that seems too aggressive. > > As an example I needed a little used package called open2300 for > opensuse 10.3 a few months ago. It was last fully released in 2005. > I doubt the source has been edited in a long time. It links to MySQL > so I think that means it should be rebuilt from time to time? > > I found it on that build service at > https://build.opensuse.org/package/show?package=open2300&project=home%3Afse >idel > > And as you can see the 10.3 version still builds. On the other hand > the 11.0 and 11.1 versions do not. > > Certainly if you totally dropped it because it had not seen any > activity in a while I would have not found it. Or are you just > proposing leaving it published in its last built state? > > Possibly even more important, I assume if you dropped it I would not > have even found the package when doing a search. Even if the builds > are broken, currently I can search for a package, grab the specfile, > etc. and create my own project with that as a starting point. > Otherwise I would have to start from scratch on the specfile. > > In fact, in this case I pulled open2300 from svn and built my own set > of projects. Having the several year old version around to leverage > simplified things somewhat. > > Thus if I understand your proposal, I don't care for it. > > I would prefer: > > If a package builds, keep building it regardless. > > If a package fails to build, only try again if there has been a source > change. > > If a package fails, have a new search option that allows me to search > for them so I can evaluate using that package as a launch point for > creating a new subproject. > > Thanks > Greg -- Adrian Schroeter SUSE Linux Products GmbH email: adrian(a)suse.de -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

11 years, 5 months

Supplements package && language, how?

by Cristian Morales Vega

I'm packaging the new fully GPLv2+ spanish voices for festival. I would like them to supplement festival + spanish language. Looking at bundle-lang-common-es in YaST I see it supplements things like "PackageKit & namespace:language(es)"... even if "rpm -q --supplements bundle-lang-common-es" doesn't returns anything. But when looking at the spec file I don't see any Supplements line. Some black magic that adds dependency info in repo metadata but no in the package... how could I use it for festival-spanish-voices? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

11 years, 5 months

Renaming packages...

by Karl Eichwalder

I'd like to rename the opensuse-manual_en package to opensuse-manuals_en (plural). Thus it would match sle[ds]-manuals_en. The package actually consists of several books and guides, thus it is probably to change it that way. If we would unify the package names, maintenance scripts could work more reliably. Is this the right list to announce such changes? -- Karl Eichwalder R&D / Documentation SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org

11 years, 5 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging June 2009