Re: http://rerun.lefant.net/checklib - stopped updating?
On Sun, Jan 28, 2007 at 12:12:16PM +0100, Pierre Habouzit wrote: > On Sun, Jan 28, 2007 at 12:00:58PM +0600, Mikhail Gusarov wrote: > > Hi, > > > > Is checklib stopped? Pages say sth like 'Last update: Sun, 08 Oct 2006 > > 17:26:18'. > > > > Has checklib been relocated to another place or just abandoned? > > actually, thanks to Ganneff and Lufthansa machines, we should be able > to setup some massive QA machine, chelib beeing among the tests suite we > will run IMHO. So even if the historical upstream has lost faith in that > project (if not, he will be welcomed to help !) that service is > scheduled for revival. Though there is absolutely no ETA more precise > that RSN. I haven't lost faith, I've lost time :-/ I'm currently in Sweden for an exchange semester during my chemistry studies, and I just don't have time to update it (or finally add a cron-job for updating). If you have any questions about setting up the beast, don't hasitate to mail me, though. Perhaps I'll even find some time to revive rerun.lefant.net/checklib Cheers, Christian Aichinger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Automatic elimination of useless dependencies using debhelper
On Fri, Sep 29, 2006 at 01:40:38PM -0400, Joey Hess wrote: > Christian Aichinger wrote: > > Yep, the program which actually removes the unnecessary needed > > entries should be seperate. My question was rather, would you accept > > a script which uses such a tool in debhelper? > > That depends. I may, for example, decide that it should just be put in > dh_strip or something. It's hard to tell without having the > implementation. I wouldn't have dared suggesting this since it's just so damn cool :) I'll go to work now. Cheers, Christian Aichinger signature.asc Description: Digital signature
Re: Automatic elimination of useless dependencies using debhelper
On Fri, Sep 29, 2006 at 12:21:24PM -0400, Joey Hess wrote: > Christian Aichinger wrote: > > Con's: > > * Debhelper is arch:all, thus the backend (that really strips the > > NEEDED entry) would have to be in a separate package (new > > dependency in debhelper). > > Yes, this needs to be a separate package anyway, since debhelper is > not intended to be the main point where things like this are > implemented. Yep, the program which actually removes the unnecessary needed entries should be seperate. My question was rather, would you accept a script which uses such a tool in debhelper? Cheers, Christian Aichinger signature.asc Description: Digital signature
Re: A plan to get rid of unnecessary package dependencies
On Wed, Sep 27, 2006 at 10:54:34AM -0700, Russ Allbery wrote: > > I'm not sure where to put it inside the -dev package though, perhaps > > in an /usr/share/debhelper/stripdeps/ file? > > Well, if we're talking about an external tool to strip unnecessary NEEDED > entries from the library, you could call it dh_striplibs, include it in > debhelper, and have the opt-in system be whether the maintainer chooses to > run it or not. That's what I was thinking of. > That doesn't help the folks who aren't using debhelper as > much, though. We could also put the flags in another location then under /usr/share/debhelper (or into the control tarball, though that sounds cumbersome), so other build systems could use it too. Ideas where to put such a thing? Cheers, Christian Aichinger signature.asc Description: Digital signature
Re: A plan to get rid of unnecessary package dependencies
On Wed, Sep 27, 2006 at 12:50:07PM +0100, Mark Brown wrote: > As a first approximation perhaps libraries with constructors or > destructors could be assumed to always be required? That would be more > conservative than required but perhaps so conservative as to be useless. The problematic sections seem to be .init and .fini. There are sections called .ctors and .dtors, but they aren't marked as executable. However both .init and .fini seem to be always present, and include code too. To see the sections in the ELF file: readelf -S To see the code in .init and .fini: objdump -D | sed -n -e '/\.init\|\.fini/,/^Dis/p' What I could imagine was some sort of opt-in system, where library maintainers could put a special marker into their -dev packages indicating "yes, please remove me if I'm not needed, it's save". I'm not sure where to put it inside the -dev package though, perhaps in an /usr/share/debhelper/stripdeps/ file? Cheers, Christian Aichinger signature.asc Description: Digital signature
Re: A plan to get rid of unnecessary package dependencies
On Wed, Sep 27, 2006 at 02:05:29PM +0530, Ganesan Rajagopal wrote: > Excellent work :-). Thanks :) > I didn't see a link to the checklib script itself. > Do you intend to release it some time? Thanks. It's linked at the bottom of all the pages, the link points to http://greek0.net/div/checklib.tar.gz> Cheers, Christian Aichinger signature.asc Description: Digital signature
Re: Top 20 unnecessary dependencies [was: Re: A plan to get rid of unnecessary package dependencies]
On Tue, Sep 26, 2006 at 11:41:33PM +0700, Mikhail Gusarov wrote: > Will this problem disappear if end programs will pass --as-needed flag > to the ld command line? As described in the other mails, --as-needed is a hack, and can cause trouble. I've also thought of a debhelper script stipping out useless NEEDED entries, but that suffers from the same problems as --as-needed (mostly related to init/fini functions). On IRC the idea came up to include such checks in piuparts, however I haven't yet investigated how this would fit with its architecture (conceptionally it should be the right place, though). It's really quite sad that we can't easily automate such checks during package build, as that would be the easiest way to get rid of all the dependencies. Cheers, Christian Aichinger signature.asc Description: Digital signature
Re: Top 20 unnecessary dependencies [was: Re: A plan to get rid of unnecessary package dependencies]
On Tue, Sep 26, 2006 at 09:36:08AM -0700, Kevin B. McCarty wrote: > In case it's of interest to anyone, I went through the checklib logs > available on the web page for "problems" and found the libraries that > are most often listed as bogus dependencies. This seriously rocks. Thanks. Actually that should be terribly easy to get this out of the DB checklib uses, but it isn't, mostly due to lazyness on my side. Might I include your script in checklib (under GPLv2+, if possible), and put the results on a seperate page on rerun.lefant.net/checklib? Cheers, Christian Aichinger signature.asc Description: Digital signature
Re: A plan to get rid of unnecessary package dependencies
On Tue, Sep 26, 2006 at 01:34:50PM +0200, Gabor Gombas wrote: > You could invent a mechanism to tag a library as "never to remove even > if no symbols appear to be referenced". Since this should be quite rare > even a single (config?) file listing all problematic libraries would be > enough, at least in the beginning. I could maintain such a list for checklib, that wouldn't be problematic. Doing such a thing for debhelper sounds evil though, I surely don't want to be responsible if packages fail to build (or run correctly) because a library was removed that shouldn't have been. Maintaining such information somewhere within the library package would be possible, but that sounds like a more complex plan, and I doubt that many library maintainers know if their lib uses such tricks or not. Cheers, Christian Aichinger signature.asc Description: Digital signature
Re: A plan to get rid of unnecessary package dependencies
On Mon, Sep 25, 2006 at 11:12:49PM -0700, Thomas Bushnell BSG wrote: > Hey. If we have a programmatic way of detecting this cases, why not > just fold that into the shlibdeps program, and be done with it? As pointed out by Russ Allbery, shlibdeps wouldn't do. It would be possible to stuff it into dh_strip or a new debhelper script, which just removes the unnecessary NEEDED entries. On Tue, 26 Sep 2006 10:39:29 +0200, Gabor Gombas wrote: > Note that if a shared object has constructor and/or destructor functions > then there is NO WAY to automatically decide if it is needed or not, > even if it does not even provide exported symbols. That's one major problem, which is also the reason why I haven't implemented a dh_ script. AIUI the number of libraries using such tricks is minor, so it is unnerving that we can't use the dh_ method because of that. I don't see any solution though :-/ Cheers, Christian Aichinger signature.asc Description: Digital signature
Re: A plan to get rid of unnecessary package dependencies
On Mon, Sep 25, 2006 at 02:40:49PM -0700, Kevin B. McCarty wrote: > (Sorry if you get this twice, I don't know whether you subscribe to > debian-devel.) I am subscribed here, also sorry about the broken MFT in the -announce mail :-/ > Thank you for this very cool effort! Might we see checklib packaged for > Debian soon? Thanks :) Aurélien GÉRÔME started an alioth project, I'm also member there: https://alioth.debian.org/projects/checklib/ Nothing there yet, as I wanted to get the announcement out before starting to work on the codebase again to clean it up (which is badly needed :-/). The current version of the source is linked on the bottom of the pages (updated 10 minutes ago, so please reload ;) > One thing I noticed is that there are a lot of "problems" (in your > terminology) caused by unneeded dependencies on libgcc1 > (/lib/libgcc_s.so.1). From my quick investigation, it appears that the > C++ and Fortran compilers (g++, g77, gfortran) introduce this dependency > automatically to programs linked with them. However, if gcc is instead > used in the linking step, no such dependency is created (at least on > amd64 where I'm testing). I'm not sure if libgcc_s.so.1 doesn't do some magic that checklib can't detect. Maybe one of the gcc maintainers could clarify if/when it's needed. If it really is needed it could be ignored for the results, that wouldn't be much of a problem. > Even though you are technically correct that libgcc1 is an unneeded > dependency, it may be hard for anyone (except maybe the gcc maintainers) > to do anything to fix this; could you have an option for libcheck to > ignore this library? I suspect if this was done, the proportion of > "problems" in your pie chart would shrink a fair bit. Could be done, however if the dependency is really unneeded, it might be interesting to fix it in gcc if possible and desirable (i.e. not unpractical for reasons unknown to me). One general comment: Checklib problems concern binary packages. So if there's a problem on one package, that doesn't necessarily mean that the corresponding source package is the correct place to fix it. As in this case the problem might originate in gcc, another common reason are broken .la/.pc files in -dev packages. Checklib just can't know where the problems come from, it can only see where they manifest themselves. Richard Atterer wrote: > Hmm, maybe the functionality could be included in lintian? I'd have to talk with the lintian maintainers, but it's not easy. Checklib needs a local Debian Mirror to work, and that sounds a bit problematic for inclusion in lintian :) There might be ways around this, I'll try to explore that. Cheers, Christian Aichinger signature.asc Description: Digital signature
Re: Successful and unsuccessful Debian development tools
On Tue, Aug 08, 2006 at 11:02:15AM +0200, Toni Mueller wrote: > On Mon, 07.08.2006 at 12:52:26 +0100, martin f krafft <[EMAIL PROTECTED]> > wrote: > > also sprach Toni Mueller <[EMAIL PROTECTED]> [2006.08.07.1126 +0100]: > > > what are your problems with CDBS? > > http://lists.debian.org/debian-devel/2006/06/msg00451.html > > http://lists.debian.org/debian-devel/2006/06/msg00467.html > > hmmm, for me, CDBS feels very much like BSD's ports system. > > That notwithstanding, it could be enhanced (what couldn't?). The problem some people see with CDBS is that you can't really see how a package will build from looking at debian/rules, instead you have to look it up in /usr/share/cdbs. That's not much of a problem with your own packages usually, but it can be unnerving if you're doing RC bugsquashing, looking at 10 packages per day, trying to figure out why something doesn't build. However pushing out as much build logic as possible from debian/rules is a central concept of CDBS, so this unlikely to ever change. Cheers, Christian Aichinger PS: We've already had this discussion, so let's try to skip the flamewar this time, can we? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Successful and unsuccessful Debian development tools
On Tue, Aug 01, 2006 at 10:24:32AM +, Reinhard Tartler wrote: > The sbuild package in debian however adds more features, like > schroot support. With this, it can use schroot to create > temporary, clean chroots from tarballs, block devices, create lvm > snapshots on the fly and so on. I read Roger, that even xen > support is planned. > > schroot is another very very useful tool. It gives me more or less > instant access to clean chroots on lvm snapshots for experimenting, > building, developing and testing. When I didn't know schroot could do this I wrote a script to do that myself: http://greek0.net/lvmchroot/lvmchroot_0.5-1.dsc It's geared towards creating and maintaining chroots on LVM logical volumes, creating snapshots as needed. It also takes care of creating the initial chroots on LVs, it can automatically upgrade them, etc. Plus they're better documented (IMHO) as schroot, for which I couldn't find any useful docs. If the schroot maintainers agree we could try to merge my stuff into schroot. Cheers, Christian Aichinger signature.asc Description: Digital signature
Re: Why apt-get is not a proper software search engine (was Re: And now for something completely different... etch!)
On Tue, Jun 07, 2005 at 10:44:53PM +0200, Javier Fernández-Sanguino Peña wrote: > - use package dependancies to ponder if this is an end-user package or > something pulled in by other packages (users typically look for end-user > programs) I do not think will work very well. Where do you set the dependency threshold for end-user packages? 0? Then you'll probably miss all packages that support plugins (e.g. sylpheed-claws, ion3, ..). More? Then you'll probably get lots of false positives. The reverse dependency count just isn't a very good metric for "is an end-user package". I think it's also a job for debtags or something like it, to tell us what is an end-user package and what isn't. Cheers, Christian Aichinger signature.asc Description: Digital signature
Re: automated updates of debian/changelog considered harmful
On Wed, Jun 08, 2005 at 07:09:35PM +0100, Andrew Suffield wrote: > Woah, it's not okay for sourceful uploads either. You *cannot* change > anything that goes into the source package at build time. This > includes the top entry in changelog and the source section of the > control file. Trying to do this *will not work*. > > At the point when the changes are made, the source package HAS ALREADY > BEEN BUILT. What happens is that the changes made in the currentx build > get included in the *next* source package you build from the same > tree, so the source and binary are perpetually out of sync. This is > BAD. Cdbs lets you generate debian/control dynamically, via a control.in file, where e.g. @cdbs@ is substituted for build-deps needed by cdbs (which already caused bugs in the past), among other things. (It's not documented, but it's easily found by grepping for @cdbs@ in buildcore.mk.) So if we're documenting all this somewhere, we should probably also mention that this is not the best cdbs feature to use. Cheers, Christian Aichinger signature.asc Description: Digital signature
