Re: [opensuse-packaging] New default warning for -Wall (-Wstrict-prototypes)
On Tuesday 29 January 2008, Stephan Kulow wrote: > But the warning is not fatal. It would mean way too many fallouts for false > positives. Well, it was just a general topic, but while we're talking on this specifically: by definition there can't be false positives for -Wstrict-prototypes. And the reason for them being turned on is (iirc) that the incorrect prototypes cause ABI issues (parameters passed incorrectly) and crashes. Therefore if we support an architecture where is indeed an ABI problem (think SLE), then we should weed them out of the source. Note that I'm not advocating to do that now - evaluation of the fallout has to happen first (in BETA IMHO). I just said that rather than implementing the failure in the autobuild check, it should be triggered by using the right gcc option for it. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] New default warning for -Wall (-Wstrict-prototypes)
On Wednesday 23 January 2008, Richard Guenther wrote: > > > > We will include -Wstrict-prototypes in RPM_OPT_FLAGS via enabling > > > > it for -Wall soon, which will warn about non-prototypes like > There might be adjustments to the autobuild checks that parse the log > file, but for now we'll just see what happens ;) Note that I consider the autobuild logfile parser to be deprecated in the longer future, so I would rather have a -Werror=strict-prototypes in the RPM_OPT_FLAGS than yet another custom weird hack. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] yauap package for sale
On Monday 14 January 2008, Sascha Sommer wrote: > as my time as working student is ending I'm looking for a new maintainer > for the yauap package. feel free to reassign it to me. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] openSUSE 11.0 - call for package updates
On Thursday 10 January 2008, Marcus Meissner wrote: > kde-maintainers kmobiletools0.4.3.30.5_beta1 > kde-maintainers kradio 1.0beta3b_ snapshot-2 these are false positives. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] problem with spec file for kdepim3
On Monday 31 December 2007, Rajko M. wrote: > I tried to build source package for kdepim and rpmbuild complained on > missing dependencies. while it might work with rpmbuild, please use "build" (available from openSUSE:Tools iirc) or "osc build" for building opensuse packages. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] package not name after its SONAME
On Tuesday 18 December 2007, Michael Skibbe wrote: > libeXosip2.i586: E: shlib-policy-name-error (Badness: 1) libeXosip2-4 > Your package contains a single shared library but is not named after its > SONAME. > > the soname is: > SONAME libeXosip2.so.4 > > i named the package libeXosip2-4 but build give me the same error. and "2-4" was part of %name (not version!)? > i also named the package liblibeXosip2-4 but nothing helps. > > how should i call my package? libeXosip2-4 -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] rpmbuild glibc for OpenSuse?
On Tuesday 27 November 2007, Jonathan E. Brickman wrote: > Should I be using a tool other than rpmbuild? We use "build" or "osc build" to build the packages in a controlled chroot environment with a defined list of packages. > Or is there a package I > am missing? I have tried a number of things, but haven't been able to > figure it out. does it work without --target? if yes, then you found a bug in our buildsystem (we only build optimized for i586 and again for i686 (two different trees). if it doesn`t, you found a bug in your setup. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] licenses.rpm again
On Friday 09 November 2007, Lukas Ocilka wrote: > I remember deciding that we'll not use the licenses.rpm... or am I > wrong? What's the current status, please :)? I don`t know either. Juergen, Coolo? Thanks, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] How to deal with Python .pyc and .pyo files?
On Wednesday 14 November 2007, Stephan Kulow wrote: > will look for .pyo and python looks for .pyc. So you need to > package both, but can hardlink them if they are the same (fdupes is your > friend) Oh, we did test meanwhile that this works? ;) judging from the strace it looks like python correctly unlinks the file before trying to re-write it, so it should be okay. -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] How to deal with Python .pyc and .pyo files?
On Thursday 15 November 2007, Johannes Meixner wrote: > Think about the "worst case" when the user replaces our Pyhon > with whatever self-compiled Pyhon. > > Are byte-compiled Python .pyc and .pyo files the same for any Python > and/or is any Python sufficiently smart to know when .pyc and/or .pyo > files are outdated (even if the matching .py files are unchanged)? they`re installed in a versioned directory. python does not do any checking other than timestamp comparison, so it will never read an outdated bytecompiled version. Thats about it. > I wonder why in this case small RPMs seem not to count. So far printing with more than 100MB of data is the bigger factor compared to a couple of mb we could save by not packaging pyc files. > I am no Python expert at all and I would be happy if a Python expert > could provide some background information. if you %fdupe the pyc/pyo files, the overhead is lower. and the parsing overhead is significant for smaller short lived python scripts. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] -mini packages purpose
On Friday 09 November 2007, Dirk Mueller wrote: > The long term plan is to add rpmlint checking to autobuild. see bug 297050 s,autobuild,buildservice, Sorry for the confusion, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] -mini packages purpose
On Friday 09 November 2007, Wolfgang Rosenauer wrote: > Absolutely not ;-) I was just mentioning that they obviously not only > live in autobuild and I wondered if it was intentionally or not but even > better if it is. The long term plan is to add rpmlint checking to autobuild. see bug 297050 Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-packaging] New rpmlint check in BETA
Hi, as a followup of the discussion of yesterday: There is a new check in BETA which will check for missing prerequires for your %pre/%post/%preun%postun scripts. An example would be : kdemultimedia3-extra.i586: E: no-prereq-on coreutils for mv which says, that kdemultimedia3-extra contains a %post script that contains a call to "/bin/mv", however coreutils or /bin/mv is not in the prereq for that package. The check is fatal for repeated abuse. for (other) details, please refer to http://en.opensuse.org/Packaging/RpmLint Please file bugreports if you run accross a false positive/false negative/do not understand the report/etc. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] *-examples subpackage
On Tuesday 06 November 2007, Stephan Kulow wrote: > > it's not possible to have source files in *-examples subpackage in beta? it is possible, it was a temporary bug that is meanwhile fixed. you`re looking at a build failure that is over a week old. Please take a look at the current build failures, where Source-Navigator builds again. Also please do not forget that I announced on October 29th on this very list that rpmlint in BETA is being upgraded and that you should NOT react to those reports. > Well, one or two - the badness is 50, so only 20 are a problem :) Wrong, Only in BETA. Scoring is different in STABLE. > You can mark them as %doc and then rpmlint will know Wrong as well. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] RPM dependencies vs. post-install scripts
On Tuesday 06 November 2007, Cristian Rodriguez wrote: > odbcinst from package unixODBC located in /usr/bin/odbcinst may be also > called while installing drivers on %post > > rpmlint may also enforce people using %install_info* macros to PreReq: > %install_info_prereq ;) thanks for all the suggestions in this thread, they`re now implemented and will move to factory soon. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] conjunction Supplements for packages
On Friday 02 November 2007, Stanislav Brabec wrote: > Hallo. > > I have more packages with following situation: > > I have package libgda > It has libgda-mysql plugin > > I want to have libgda-mysql automatically selected, if if both libgda > and mysql are going to be installed. %package -n libgda-mysql mysql Supplements: packageand(mysql:libgda) Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-packaging] please review your *rpmlintrc rules
Hi, rpmlint 0.81 has changed the output format: E: package check-id detail was the old format. the new format is .: E: check-id detail The new format is going to be active with the next checkin round to BETA. Please review your personal rpmlintrc rules and adapt them accordingly. I plan to merge the new checker, which has many improvements to Factory, within the next week and will cause new failures. I`ve fixed the non-leaf packages already myself. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] RPM dependencies vs. post-install scripts
On Friday 02 November 2007, Martin Vidner wrote: > > I hope, there's someone who does and is willing to help. > > Any volunteer? > here's a patch, untested. Many thanks, Martin! There was a small bug in it (\b has to be escaped, e.g. \\b). I`ve added a --info description and enabled the fix in BETA. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-packaging] New rpmlint in BETA
Hi, [external people: ignore on] There will be a new rpmlint in BETA. It might produce new fancy fallout. Do not panic, I`ll be watching it. I`ll let you know if you have to fix something in your package by personal email. [external people: ignore off] Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] 2nd reminder to fix your packages for compiling with GCC 4.3
On Monday 22 October 2007, Marcus Rueckert wrote: > we have the rule that a readme.suse or suse.tar.bz2 should be prefixed > with the package name to avoid collisions when installing the src rpm. > > that said it is not the smartest idea that many people call their > patches "gcc-4.3.diff". please prefix your patches atleast with the > package name. I think this rule should either be dropped or enforced. I disagree about the usefulness of this rule in general. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] GCC 4.3 transition and fallout in your packages
On Monday, 24. September 2007, Richard Guenther wrote: > The upcoming transition to GCC 4.3 will cause some common problems > in C and C++ source to become compile-time errors. You investigate > if your Factory package is affected by looking at the > home:dirkmueller:playground:gcc43 project which is currently rebuilding > (most of) Factory with GCC 4.3. .. and do not forget to mail the patch upstream! It seems that Ubuntu currently does a gcc 4.3 transition, so in some cases the bug might be already fixed upstream and all that you need to do is a new source drop. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] rpmlint-typo
On Tuesday, 18. September 2007, [EMAIL PROTECTED] wrote: > in the actual rpmlint package; rpmlint-0.80-118.3.noarch.rpm > is a small typo, leading to rpmlint-errors: please file a bugreport and assign it to [EMAIL PROTECTED] Thanks, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] [Fwd: [package check i386] sabayon-admin changes]
On Monday, 17. September 2007, Federico Mena Quintero wrote: > > if the latter description for requires-on-release is not understandable, > > then file a bugreport and suggest a description that you can understand. > What's the right product/component to file this in Bugzilla? the particular product you have the problem with. I guess this is openSUSE 10.3/Base -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] [Fwd: [package check i386] sabayon-admin changes]
On Friday, 14. September 2007, Martin Vidner wrote: > How about replacing cryptic-error-code in the report by > http://en.opensuse.org/Packaging/RpmLint#cryptic-error-code which > enables us to click and read the explanation? That would mean that somebody actually writes an explanation other than "it is a pain (because it writes emails)". actually, if you read the tail of your build log you will find the same error messages like you get with package check, except that there it has additional information printed below the check, which would explain what the check is good for. if the latter description for requires-on-release is not understandable, then file a bugreport and suggest a description that you can understand. Thanks, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] [Fwd: [package check i386] sabayon-admin changes]
On Thursday, 13. September 2007, Stephan Kulow wrote: > > Does anyone know why I get messages like the attached one once per > > day? :) Is there anything I should change in the Sabayon specfile? I > > couldn't see anything wrong in it. > Well, rpmlint doesn't like requires on release because they are usually a > pain (as in sending tons of mail :) rpmlint complains about requires-on-release because it makes maintenance harder, and because SUSE packaging conventions forbid it (Section 1.12). The mail-sending effect is more a reminder and could even be suppressed, but as you can see here, there is at least one package that got fixed due to it ;) Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Broken VirtualBox kernel module package.
On Monday, 3. September 2007, Rajko M. wrote: > http://download.opensuse.org/repositories/ > Virtualization:/VirtualBox/openSUSE_10.2_Update/i586/ > VirtualBox-kmp-default-1.4.0_2.6.18.8_0.3-20.1.i586.rpm > the packages missing vboxdrv, which makes VirtualBox useless on openSUSE > 10.2. Use the one from home:dirkmueller, that one works fine (is even tested). Greetings, Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] %fdupes
On Monday, 3. September 2007, Michael Matz wrote: > > Not sure what rsync has to do with the problem at hand. > Especially because it seems to handle copying hardlinks across > directories, when the target directories are on different filesystems just > fine. Just tested. would you please discuss this in the appropriate bugreport (bug 304167) instead of the list here, where it is likely getting forgotten again? Thanks a lot, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Re: Handling license symlinks
On Monday, 3. September 2007, Lukas Ocilka wrote: > Libzypp supports --nodeps as a fallback solution for installing RPMs. > First, it, of course, tries to install an RPM in a normal way, then > libzypp tries that with --nodeps automatically. Thats not a reason. we rely on package dependencies already for other licensing issues, and this would be no different. otherwise you could also say that if a user installs all his pacakges with all files but the COPYING file would also be a licensing violation. -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Re: Handling license symlinks
On Monday, 3. September 2007, Juergen Weigert wrote: > Does anybody know if the licenses package had a space > saving effect on the media? Well, the GPL roughly takes 3kb of space per rpm on the media. out of a default KDE installation, exactly 256 packages ship a copy of GPL, eating roughly 768kb of space on the media. the licenses packages is 432kb in size. So assuming that all those 256 packages would be fixed (noone fixes them currently, not even all the yast2 packages which contain COPYING twice are fixed even though I filed a bugreport a couple of months ago), we could save 336kb of space. thats not an awful lot, given that we have packages on the CD where we could save 5MB with a blink of an eye. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-packaging] new rpmlint check
Hi,
it turns out that using %fdupes unconditionally over all of %{buildroot} can
cause hardlinks to be created between files that are possibly installed on
different physical partitions on the customer`s system.
It turns out that RPM is unable to handle that gracefully. Therefore I`ve
added a new check which complains if there is a hardlink accross the first
two levels of a path.
These checks will be fatal in BETA (somewhen in the near future), please watch
for failures and fix your packages.
the always current list of affected packages (sorry guys, suse internal only):
$ grep hardlink-across ~dmueller/Export/pita/pita.lst
Greetings,
Dirk
--
RPMLINT information under http://en.opensuse.org/Packaging/RpmLint
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Re: Handling license symlinks
On Friday, 31. August 2007, Philipp Thomas wrote: > How about this (untestet): a) buildrequires licenses missing b) the %doc macro runs after postinstall scripts, so one still has to update the %doc macro specs an easier fix would be to add a post-prep script hook that will just replace "COPYING" in the source dir with a symlink, so that %doc just copies the symlink into the package. Greetings, Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Re: [Research] prelink
On Thursday, 30. August 2007, Jan Engelhardt wrote: > >And also, prelink was not considered helping speed ups that much, > >and we have added other measures that help more. > Is SUSE already using DT_GNU_HASH? Yes, since February 2nd, 2007. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] obsoletes / provides question
On Tuesday, 28. August 2007, Marcus Meissner wrote: > Name: opensuse-updater-kde > Provides: opensuse-updater = 0.5 > Obsoletes: opensuse-updater <= 0.5 > Does this work? Won't it obsolete/deinstall itself? "opensuse-updater-kde" != "opensuse-updater". -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] missed -devel subpackage splits
On Thursday, 23. August 2007, Michal Marek wrote: > Cool :) Are you also going to add some default suppresions for these > warnings? This is my current list: I haven`t done so yet, but if you could add this list to the patch I would be very happy. I`m not sure if I get around adding those false positives anytime soon. Thanks, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] missed -devel subpackage splits
On Monday, 20. August 2007, Michal Marek wrote: > during 10.3 development, many library packages were renamed and/or split > into a runtime and devel subpackage. The former doesn't cause any pain, > as the *.so provides / requires stay the same. Thats a very nice idea for a build check. You should have submitted it as a rpmlint enhancement request ;) I've added a small variation of this check to rpmlint now. Please watch out for the checks "non-devel-buildrequires" and "unnecessary-buildrequires" Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Shared Library Policy
On Wednesday, 22. August 2007, Vladimir Nadvornik wrote: > > not into the library package, no. > Why not? > > These files would go into /usr/share/doc/. There should not be > any conflict as long as there is no conflict in package names. where is the one following shared library policy? I guess thats okay, given that they cannot conflict. we probably even have to add the LICENSE file for legal reasons even. In general I would prefer library packages to be as small as possible, especially if they cannot be avoided. For example right now we have boost installed because of libzypp, and boost is not properly splitted. libzypp only requires boost_filesystem (a 71kb library), but the boost package itself is over 2MB. This 35:1 ratio isn't quite nice. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Shared Library Policy
On Wednesday, 22. August 2007, Richard Guenther wrote: > which is pointless. Current stable has 959 static libs in /usr/lib > including "interesting" stuff like libxml++-2.6.a. All in all 320MB > worth of static libs. Ugh. sorry, forgot to followup: all of those are -devel subpackages, or should be if they`re not already. The only thing that matters is if its statically linked in any binary that we ship. I have some tools to dig that up, and its surprising how many deep sqlite copies we have (being in one package, not statically linked from the system package). It would be a lot better overall to work on that instead, because it makes maintenance easier, reduces the size of the distribution overall and actually has some benefit for users (aka those that are not developers). currently I don`t have rpmlint integration for the code duplication checker but I guess that would be a very nice feature to have to be able to point out easily which packages are broken. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Shared Library Policy
On Wednesday, 22. August 2007, Richard Guenther wrote: > Like for example I have on my 10.2 system static boost libraries installed > which is pointless. boost breaks every so often, its okay to link it statically for special purposes. Speaking generally. and the static libs are only in the -devel subpackage, which a normal user doesn`t have installed. of course it would be nicer if libzypp would only have a libboost_filesystem instead of dragging in all of boost, but given that I removed the 10MB regex dependency, its your job to file a bugreport about splitting boost ;) Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Shared Library Policy
On Wednesday, 22. August 2007, Richard Guenther wrote: > Though in general we do not want to ship static libraries, so .la files > without a static library should be avoided. its imho fine shipping them in the -devel subpackage *if* its not a security relevant package. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Shared Library Policy
On Tuesday, 21. August 2007, JP Rosevear wrote: > 1) The "simple" example at the end does not take into account where %doc > files should go (AUTHORS, COPYING, README) etc. not into the library package, no. > 2) No reference to .la files > Do we finally want to kill those as a matter of policy? If so, should we > write a macro to do it? There is a build and a rpmlint check to discover unneccessary .la files, you can kill those. In general killing them is bad is it breaks static linking. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Package RDAC kernel module
On Tuesday, 7. August 2007, Jan Blunck wrote: > > gcc -D__KERNEL__ -I/lib/modules/2.6.16.46-0.7-xen/build/include > > mppLnx26_spinlock_size.c -o mppLnx_Spinlock_Size > Fix the broken userspace application its a kernel module! it looks more like the /include symlink is not set correctly. -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Building packages with linking a license from licenses.rpm
On Wednesday, 25. July 2007, Reinhard Max wrote: > GPLv2 says (section 1.) "[...] and give any other recipients of the > Program a copy of this License along with the Program." So are we distributing a program or are we distributing a distribution? If it is the latter, why do you think in the granularity level of a RPM package? But assuming that you read the whole paragraph which you quoted and which the "program" above is referring to: "you may copy and distribute verbatim copies of the Program's *source code*". Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Packages for sale
On Wednesday, 11. July 2007, Boyd Lynn Gerber wrote: > perl-Mail-SPF-Query has been replaced with perl-Mail-SPF which is rfc 4408 > compliant. Thanks for the information, dropped perl-Mail-SPF-Query. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-packaging] still packages for sale
Hi, the following packages have still no new maintainer: cmake dietlibc I've filed drop requests, but they have build-dependencies which will break nontrivial amount of packages. Anyone who wants to pick them up? -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Packages for sale
On Wednesday, 11. July 2007, Ladislav Michnovič wrote: > I can't find this one in PDb: > > listtre typo, sorry. its libtre, a library for fuzzy regular expressions. -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Packages for sale
On Wednesday, 11. July 2007, Stephan Kulow wrote: > It's update-desktop-files, which is my package. So Dirk is trying to make a > fortune in selling my packages. [EMAIL PROTECTED]:~> maintainer desktop-translations [EMAIL PROTECTED] Anyway, it is all yours now. Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Packages for sale
On Wednesday, 11. July 2007, Marcus Meissner wrote: > > what's the rationale behing the sale ? I can't maintain the listed packages anymore, if anyone else wants to pick them up, he should speak up now. > > /me does not get it :? > Internal redistribution of pakcage maintainer ship, but since our internal > packagers list is gone, on the external list. Its not really internal anymore, nowadays community members can maintain packages :) -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-packaging] Packages for sale
Hi, first come first serve arptables cgwd cgwd-devel clucene-core clucene-core-devel cmake crm114 dapi dapi-devel dapi-kde dietlibc dragonegg fdupes keepalived libdnet libdnet-devel libexiv2 libexiv2-devel listtre agrep libtre-devel libvisual libvisual-devel libvisual-plugins openntpd optipng perl-Chart perl-Mail-SPF-Query perl-Net-CIDR-Lite perl-Net-IRC perl-Sys-Hostname-Long re2c rpmlint-mini snort soprano libsoprano3 libsoprano-devel xdg-utils desktop-translations CrystalCursors LabPlot boson chmlib chmlib-devel flash-player kim-browser klamav knights knoda knoda-devel kover kradio krename libeigen libkdcraw0 libkexiv2 rsibreak taglib taglib-devel tellico viki xbase xbsql yzis libraptor1 libraptor-devel -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-packaging] RPMLINT: Shared Library Naming Policy not applied
Hi, The Dist Meeting decided yesterday that the Shared Library Naming Policy should be applied to new packages. I've submitted a rpmlint package yesterday that should contain a list of existing legacy exceptions. Obviously, due to a bug in one of the scripts I missed some. I've fixed that and the currently failing packages should build with the next rebuild. Thanks, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-packaging] Request for help: Please check init script dependencies
Hi, under http://www.suse.de/~dmueller/sysv5-deps.ps is a dot graph that shows the start dependencies of the /etc/init.d scripts that are on our DVD media (as of alpha5). Given that I found 3 errors in them in less than 5 minutes, I guess you could take a look yourself if your package has correct dependencies specified. Regarding boot time optimisation: it is a good idea to reduce the number of "levels" and increase parallelism, as modern machines are almost always SMP. Currently there is a hard sync point between runlevel B (the boot.* scripts) and all other runlevels. As you can see easily on this graph, this hard sync point doesn't really help boot time. Thanks, -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] new RPMLint checks
On Friday, 8. June 2007, Dirk Mueller wrote: > there are new checks being added to the Factory rpmlint package that will > become errors soon: As some people panic'ed already: This will happen way after Alpha5. Don't worry. Greetings, -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-packaging] new RPMLint checks
Hi, there are new checks being added to the Factory rpmlint package that will become errors soon: init-script-without-%stop_on_removal-preun package installs an /etc/init.d script, but doesn't run the %stop_on_removal macro in %preun init-script-without-%insserv_cleanup-postun package installs an /etc/init.d script, but doesn't run %insserv_cleanup in %postun for understanding why those are necessary, please read the packagers manual / suse packaging conventions. There are about 93 packages affected. I'd like to hear about false positives in order to improve the check. invalid-desktopfile package contains a .desktop file that doesn't validate. (use desktop-file-validate on it to understand why). 259 (!) packages are affected. untranslated-desktop-file package installs a .desktop file but doesn't run %suse_update_desktop_file on it. 138 packages are affected. The library policy checker has been updated to give more accurate information. Those warnings are not becoming an error any time soon, so consider them for information only. There is also an informational check for files that shouldn't be in a suse linux binary package, like the generic (source-) INSTALL instructions or README's for non-linux operating systems. I don't know exactly yet how many packages are affected, but its somewhere around 600. Greetings, Dirk -- RPMLINT information under http://en.opensuse.org/Packaging/RpmLint - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] libbz2 has been renamed to libbz2-1
On Monday, 4. June 2007, Cristian Rodriguez R. wrote: > Yes, and package managers are still unable to handle this split > properly, effectiely trashing RPM. There was an ugly prereq tag added to the spec file to fix this. if thats not working the corresponding bugreport should be reopened. Greetings, Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-packaging] rpmlint FAQ
Hi, I've started to maintain a couple of wiki sites under http://en.opensuse.org/Packaging and http://en.opensuse.org/Packaging/RpmLint to collect suggestions and frequently asked questions and their solutions. if you're looking for a current version of rpmlint, look into my homeproject in the buildservice (home:dirkmueller) Thanks, Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] rpmlint and /usr/bin/env
On Thursday, 31. May 2007, Stephan Kulow wrote: > Because /usr/bin/env takes the user's path into account and as such > makes the script unpredictable - and less secure. Actually, the answer is twofold: a) it was for testing purposes and is currently still in the rpmlint package b) the main reason is that correct file-requires are not added to the package. e.g if your script starts with "#!/usr/bin/env python", then /usr/bin/env will be required while actually /usr/bin/python should have been required. Debian for example goes down the long and ugly road of patching each and every script that contains /usr/bin/env - for the reason that coolo gave you. > I suggest we create a rpm macro to replace /usr/bin/env with the > correct path to ARG though as this might be a common task in quite some > packages. I agree, many packages are affected, and I was trying to look into fixing the rpm magic. But not enough time yet. Greetings, Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-packaging] Share your knowledge on http://en.opensuse.org/Packaging
Hi, To my horror I noticed that until an hour ago, http://en.opensuse.org/Packaging was entirely empty. Please help fill it with content to document common practices, so that others can learn from you or you can learn from others! Thanks, Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] %fdupes
On Wednesday, 16. May 2007, Stephan Kulow wrote: > I also added an rpmlint check that will give an error for the package if > it's wasting more than 20KB (which is basically a random number). Has been copied to http://en.opensuse.org/Packaging/SUSE_Macros Greetings, Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] rpmlint checks in Factory
On Tuesday, 29. May 2007, Karl Eichwalder wrote: > What does this mean? Do yout think it is better to add the version > number to the name of the library subpackage? yes, see http://en.opensuse.org/Shared_Library_Packaging_Policy Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] GPL file location
On Friday, 25. May 2007, Marcus Rueckert wrote: > > another solution that doesn't bloat your package is to symlink it from > > the licenses package. > did juergen finish that already? cdpac licenses Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] GPL file location
On Friday, 25. May 2007, Arun Singh wrote: > > %doc COPYING another solution that doesn't bloat your package is to symlink it from the licenses package. Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] policy for naming devel packages
On Wednesday, 23. May 2007, Stefan Dirsch wrote: > It's not a policy, but xorg-x11-server-sdk is the package name, that > other distributors use for these files as well. distributor_s_ ? I've checked. on debian/*ubuntu, the package is called xserver-xorg-dev. -dev is the -devel suffix for debian style distros. on mandriva, the package is named xorg-x11-server-devel. The only distro this is consistent with (while they're apparently inconsistent here with their own rules) is fedora. If you say that you don't want to rename it just for the purpose of renaming then thats fine, because we don't have a consistent naming policy anyway. Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-packaging] policy for naming devel packages
Hi, it was recently (in bugreport 277317) brought to my attention that we have three packages containing development files, but not being named with a "-devel" suffix: OpenOffice_org-sdk wnn-sdk xorg-x11-server-sdk I was wondering if there is a special policy regarding the -sdk suffix that I'm not aware of? Shouldn't those packages be named -devel? Thanks, Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] rpmlint checks in Factory
On Wednesday, 23. May 2007, Pavol Rusnak wrote: > Are we going to bzip2 all patches? I think it is necessary only for > large ones ... No, this warning is going to be suppressed completely. actually it seems to be a bug that it is not. Please ignore this one. > > W: plib no-cleaning-of-buildroot %install > > You should clean $RPM_BUILD_ROOT in the %clean section and just > > after the beginning of %install section. Use "rm -Rf $RPM_BUILD_ROOT". Same reason, it is supposed to be suppressed (and it is if you use the rpmlint package of STABLE on your package). it only happens with rpmlint-mini. I'll suppress it ASAP. Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] rpmlint checks in Factory
On Wednesday, 23. May 2007, Michal Marek wrote: > Also, what about excluding /usr/share/doc/** from the checks or > degrading errors to warnings here? Some of the checks make sense even in %_docdatadir. For example, we don't want arch dependant binaries under %_docdatadir. (except if they're stored in an arch specific subdirectory, like the tex packages do right now). Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] rpmlint checks in Factory
On Wednesday, 23. May 2007, Michal Marek wrote: > This is one too strict: There are -examples or -doc subpackages with > example source files, which is perfectly valid IMHO (we don't want to > put them into -devel directly in order not to bloat buildroots. You're right, I've also noticed it. Please file a bugreport so that I do not forget to fix the check. > Second, why sum the score for multiple instances of the same check? > Right now a package with 20+ *.c files will fail :( which package are you looking at? Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-packaging] rpmlint checks in Factory
Hi, There are new, considered to be experimental, checks for rpmlint diagnostics in Factory. So far, the following checks are enabled: arch-dependent-file-in-usr-share 590 infopage-not-gzipped 540 wrong-script-interpreter 533 arch-independent-package-contains-binary-or-object 499 library-without-ldconfig-postun 400 shlib-with-non-pic-code 223 files-duplicated-waste 100 summary-not-capitalized 63 spurious-executable-perm 50 devel-file-in-non-devel-package 50 wrong-file-end-of-line-encoding 1 Other checks are also perform and printed in the log file (autobuild only, opensuse buildservice will follow later), but they _do_ _not_ _matter_ right now. The number behind the check name above is the badness score that was assigned to it. if any build has a score above 1000, it is currently failed. There are some packages which might suffer from false positives of above checks. Please, in order to help clean that up, file a bugreport against me ([EMAIL PROTECTED]) mentioning package name and check that you consider false, and I'll fix it ASAP. About the warning only checks: If you encounter any of such checks that you feel are wrong, are not complying our best practices or are exceptions that should be suppressed, PLEASE tell me about it! Do not hack around them! So, if you have a failed build today, please look ONLY for '^E:' in the logfile to figure out why it was failed. Each line has a badness score besides it. Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] automatic packporting of Factory packages
On Friday, 18. May 2007, Stanislav Brabec wrote: > I wrote a script, which attempts to backport packages to be compilable > on older products. It means replacing of Requires and BuildRequires by > an appropriate %if. There is afaik a mapping for the opensuse buildservice. all it needs is actually telling the buildservice maintainers about missing mappings. Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] perl directories
On Wednesday, 16. May 2007, Marcus Rueckert wrote: > there are zero python noarch aswell wrong. rpmlint is noarch, just because I refuse to adhere to the python-packages-are-arch policy :) Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] suse_update_desktop_file
On Tuesday, 15. May 2007, Stephan Kulow wrote: > You only read the second paragraph, didn't you? Why do you write emails where one has to read the stuff between the first and the last word? Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] OpenSUSE base system package list
On Tuesday, 15. May 2007, Richard Guenther wrote: > Factory still has the unsplit perl... FWIW, ncurses is already fixed. Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] suse_update_desktop_file
On Tuesday, 15. May 2007, Stephan Kulow wrote: > If you have desktop files from SVN somewhere, make sure the translations > are either uptodate all the time or are stripped out of the files - > including the X-SuSE-translate line. The check is BTW already in rpmlint. Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Shared Library Packaging Policy (was: [opensuse-factory] Meeting Minutes Dist Meeting 2007-05-10)
On Monday, 14. May 2007, Andreas Schneider wrote: > I miss somthing in the new package conventions. We should start to avoid > -rpath. Packages should be built without -rpath and if they need a > special path, a file in /etc/ld.so.conf.d/ should be created. We're stripping rpath for all paths that are in /etc/ld.so.conf internally and also try to reject obviously stupid ones. So this is just about an enhancement request against the opensuse buildservice FYI. Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-packaging] Easy way to optimize startup time
Hi, for a few weeks now openSUSE Factory has a binutils which supports -Bsymbolic-functions. This option causes global symbol references inside a shared object to be resolved locally if that is possible, e.g. if a shared library calls within one of its functions another exported function that is defines itself, then that one is encoded via a local relative jump, rather than going through the complicated and slow ELF semantics. This does break if an application is interposing a symbol, e.g. tries to replace one of the libraries public functions by one it defines by its own and expects the library to call the one the application provides. This is however rare and usually even is an unintended symbol clash. So, whats the advantage? of course that depends on the library type: C++ benefits a lot more than plain C libraries. I've tested it however successfully against small c libraries (e.g.) ncurses or dbus-1 as well as big c++ libraries (libzypp, boost, libstdc++,qt3). For e.g. ncurses it resulted in a 1.2% disk space saving and roughly 25% reduced relocation time (granted, its only measurable via LD_DEBUG=statistics). For qt3, it results in a 38% relocation time improvement and a 5.5% disk space saving. So, in short: if you know what you're doing, then use $LDFLAGS=-Wl,-Bsymbolic-functions Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] [autobuild] Library packaging policy, verify in filelist check
On Tuesday, 3. April 2007, Richard Guenther wrote: > the filelist check for a better structured verification. Maybe a rpmlint > check is better for now. Might be a good idea, except that it is already done: $ grep -rl "devel-file-in-non-devel" /mounts/dist/data/i386/lint | wc -l 681 Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] [autobuild] Library packaging policy, verify in filelist check
On Tuesday, 3. April 2007, Richard Guenther wrote: > proposed library packaging policy are followed. It's non-fatal right now > as nearly every package fails it :P It is wrong, too. it shouldn't reject non-symlink .so files, or .so files pointing to modules. Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] .la files and dependencies, again
On Tuesday, 27. February 2007, Michal Marek wrote: > $ ./a2 > ./a2: error while loading shared libraries ... Well, if you link against it, then you want it to be used. Anyway, this has absolutely nothing to do with libtool. If you don't use -Wl,--as-needed, then you will get this behaviour. with -Wl,--as-needed it will work fine, because the linker drops unnecessary dependencies (increasing overall startup performance). Unfortunately, your depending libraries usually have to be fixed to work correctly with -Wl,--as-needed. I fixed a lot of instances of these kind of bugs for libraries that KDE depends but I totally ignored GNOME related bugs. Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] .la files and dependencies, again
On Monday, 26. February 2007, [EMAIL PROTECTED] wrote: > What happens if libfreetype.so.6 becomes libfreetype.so.7 and is really not > used? In such a case it can indeed break dependent packages unnecessarily. > > Or am I missing something? Yes, if it is not really used, then there is no dependent package. if there is a dependent package, then it is really used, and will break. Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] .la files and dependencies, again
On Tuesday, 20. February 2007 14:53, Richard Guenther wrote: > /usr/lib64/libxfce4mcs-client.a Well, tell the xfce maintainer ;) > which is unfortunately in libxfce4mcs-4.2.3-29 and not a -devel package > for example. Care to write a brp-check for .a and .so files not in a > -devel package? Can't be written as a brp check, because at the time they're running there is no package yet, so you don't know in which package it will end up. A rpmlint check for this would be accepted however (and I think it exists already). Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] .la files and dependencies, again
On Tuesday, 20. February 2007 13:40, Richard Guenther wrote: > Most .la files packaged in -devel packages can be removed in case > static linking is not required. .la files necessary at runtime to > make ltdlopen work should be packaged in the regular library package. in case of libpopt (which for very strange reasons is built by rpm), the .la file can just be deleted, because it doesn't have additional dependencies. > Now, whether we should stop packaging static libraries for each and > every library we have is another (valid) question. static libs should at least be in the -devel subpackage and removed if it is a library that likely suffers from security vulnerabilities (to avoid that the code is statically linked into some other package). Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
