[RFH] Implementing Homepage: field support in lintian/linda
Changes to lintian/linda are often mentioned in that discussion. Roughly speaking, we need these tools to: - no longer complain about Homepage: being an unknown field - warn people currently using the trick of mentioning the Home Page in the package's description and suggest them to move this to the new field The latter should probably be quite conservative and only detect something like: ^ +[Hh]ome *[Pp]age:.* in the package description. I would like to have something ready for lintian and linda so that it could be proposed to their respective maintainer when it's time to do so. Could some knowledgeable people propose some possible patches? I can coordinate that stuff, but proposing patches is better left to Those Who Know... signature.asc Description: Digital signature
Re: [RFH] Implementing Homepage: field support in lintian/linda
On 9/22/07, Christian Perrier [EMAIL PROTECTED] wrote: Could some knowledgeable people propose some possible patches? I can coordinate that stuff, but proposing patches is better left to Those Who Know... I offered to update the lintian patch I submitted years ago for checking for a proper Homepage psuedo-field to a check for the new Homepage field, Russ said policy/devref should be updated first. Personally, I think updating everything at the same time is the right order. Anyways, I'll work on the patch so it is ready for when lintian will accept it. Also: I think a debtags-like system (stored/maintained separately to the packages and merged into the Sources/Packages files behind the scenes) is more appropriate for homepages, since they can change independently from a package and also it doesn't take much skill to add them, so an army of users could add homepages to all those packages that the maintainer won't be uploading just to add a homepage or where the maintainer won't bother to add one. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFH] Implementing Homepage: field support in lintian/linda
Christian Perrier wrote: The latter should probably be quite conservative and only detect something like: ^ +[Hh]ome *[Pp]age:.* in the package description. /^ (web|home)( *)?(site|page) *(:| at| is).*/i seems to catch more (1905 hits) Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFH] Implementing Homepage: field support in lintian/linda
Quoting Faidon Liambotis ([EMAIL PROTECTED]): Christian Perrier wrote: The latter should probably be quite conservative and only detect something like: ^ +[Hh]ome *[Pp]age:.* in the package description. /^ (web|home)( *)?(site|page) *(:| at| is).*/i seems to catch more (1905 hits) and no false positives? (that was the point of my 'be quite conservative' comment) signature.asc Description: Digital signature
Re: [RFH] Implementing Homepage: field support in lintian/linda
Christian Perrier wrote: The latter should probably be quite conservative and only detect something like: ^ +[Hh]ome *[Pp]age:.* in the package description. /^\s+(web|home)\s*(site|page)\s*(:| at| is).*/i seems to catch more (5087 hits) with few false positives. Also, matching http:// would catch even more but with many false positives so I'm not sure if it's a good idea. Regards, Faidon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: getting unstable lintian linda into stable
Hi Christoph, On Friday, 11 Nov 2005, you wrote: Maybe lintian could detect if if was running on stable when it should be on unstable, and warn the user. I'm not sure how to do this, since there are legitimate uses on stable where you wouldn't want to get the warning. it could parse the changelog entry and try to detect if the upload is for stable-(security|proposed-updates). If not, and APT prefers stable (stolen from reportbug), lintian/linda could give a warning. This requires lintian/linda to run in the same enviroment than the package has been build (ie. a chroot). Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: getting unstable lintian linda into stable
[Alexander Schmehl] Curently it's quite easy to run unstables lintian, debootstrap and pbuilder on system running stable for the other packages. So I don't see a big problem creating and testing packages on a stable system. It would make more sense to me to run lintian *inside* pbuilder, then. Which I assume is what pdebuild does, not that I've looked at it closely to verify this. signature.asc Description: Digital signature
getting unstable lintian linda into stable
Hi, It seems that not every new maintainer is building a package on an unstable system which is recommended (or at least a version with the current policy version). So there are errors in packages which come to debian-mentors which are checked with an old version of the debian policy. So what about a special exception which provides updated lintian linda packages for the stable distribution? Is it technical possible? I mean becaused it should be fixed. If not it would be great to add some kind of Warning to the source code which checks the Debian versions and warns the user that it is normally recommended to built on a newer version. Maybe this idea is crap but I think somehow it would be great to wanr users building on stable (not an error because of backports etc.) Regards Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org Forget about that mouse with 3/4/5 buttons - gimme a keyboard with 103/104/105 keys! pgpb2V6iDDmRu.pgp Description: PGP signature
Re: getting unstable lintian linda into stable
Re: Nico Golde in [EMAIL PROTECTED] So what about a special exception which provides updated lintian linda packages for the stable distribution? Is it technical possible? I mean becaused it should be fixed. This doesn't make sense. You need unstable to build on unstable, and only updating lintian and linda doesn't change that. If not it would be great to add some kind of Warning to the source code which checks the Debian versions and warns the user that it is normally recommended to built on a newer version. Maybe lintian could detect if if was running on stable when it should be on unstable, and warn the user. I'm not sure how to do this, since there are legitimate uses on stable where you wouldn't want to get the warning. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: getting unstable lintian linda into stable
On Fri, Nov 11, 2005 at 03:28:31PM +0100, Nico Golde wrote: So what about a special exception which provides updated lintian linda packages for the stable distribution? Is it technical possible? I mean becaused it should be fixed. It might not be necessary as an exception: perhaps the rule sets could be provided, in a seperate package, via volatile.debian.net ? If not it would be great to add some kind of Warning to the source code which checks the Debian versions and warns the user that it is normally recommended to built on a newer version. I expect that could be implemented as a rule, and I think on it's own it is a good idea, as I often forget to make sure I'm in an unstable system when building packages. -- Jon Dowland http://jon.dowland.name/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: getting unstable lintian linda into stable
Hi! * Nico Golde [EMAIL PROTECTED] [05 15:28]: So what about a special exception which provides updated lintian linda packages for the stable distribution? Is it technical possible? I mean becaused it should be fixed. Curently it's quite easy to run unstables lintian, debootstrap and pbuilder on system running stable for the other packages. So I don't see a big problem creating and testing packages on a stable system. Yours sincerely, Alexander -- http://learn.to/quote/ http://www.catb.org/~esr/faqs/smart-questions.html signature.asc Description: Digital signature
Re: getting unstable lintian linda into stable
Op vr, 11-11-2005 te 15:28 +0100, schreef Nico Golde: So what about a special exception which provides updated lintian linda packages for the stable distribution? Doesn't sound like a particularly good idea to me. You need no just unstable's linda/lintian; you also need unstable's libraries to be able to make sure your package will work and build on unstable. There's no way around that; there's way too many libraries that might have their SONAME bumped, way too many packages that might have been split (or merged) so that the packages you need to build-dep on in stable don't exist anymore in unstable (or vice versa), etc. Just including linda/lintian in stable doesn't fix that. If not it would be great to add some kind of Warning to the source code which checks the Debian versions and warns the user that it is normally recommended to built on a newer version. That could work. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: getting unstable lintian linda into stable
On Fri, Nov 11, 2005 at 03:28:31PM +0100, Nico Golde wrote: [...] So what about a special exception which provides updated lintian linda packages for the stable distribution? Is it technical possible? I mean becaused it should be fixed. That's imho wrong idea because of at least one very important reason. Let's say that policy of unstable has changed and now it is required to put some kind of binaries in /foo/bar/, and lintian warns if you're going to put them in other place. It's possible that stable distribution even doesn't contain /foo/bar/ directory or some other needed tool which are now required in unstable. regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: getting unstable lintian linda into stable
Hi, * Wouter Verhelst [EMAIL PROTECTED] [2005-11-11 23:41]: Op vr, 11-11-2005 te 15:28 +0100, schreef Nico Golde: So what about a special exception which provides updated lintian linda packages for the stable distribution? Doesn't sound like a particularly good idea to me. You need no just unstable's linda/lintian; you also need unstable's libraries to be able to make sure your package will work and build on unstable. There's no way around that; there's way too many libraries that might have their SONAME bumped, way too many packages that might have been split (or merged) so that the packages you need to build-dep on in stable don't exist anymore in unstable (or vice versa), etc. Just including linda/lintian in stable doesn't fix that. [...] Yes you are right. Should I file a wishlist bug against linda and lintian to answer for the described warning procedure? Regards Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org Forget about that mouse with 3/4/5 buttons - gimme a keyboard with 103/104/105 keys! pgpttGsaEbsmG.pgp Description: PGP signature
Re: lintian linda (was: Automatic testing of Debian packages)
Josselin Mouette([EMAIL PROTECTED])@2005-04-12 09:20: Why? When you don't know Perl, and you feel like improving a software in Perl is like eating oysters with skiing gloves, LOL rewriting the software in Python so that you can work on it seems like the best solution. An even better solution is to rewrite it in ruby so it doesn't have to converted from python to ruby at a later date :-) S. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian linda (was: Automatic testing of Debian packages)
On Mon, 11 Apr 2005, Martin Schulze wrote: Why are there Vi and Emacs? Different taste of the users - valid reason. Why are there Perl and Python? Different taste of programmers - valid reason. Why are there viewcvs and cvsweb? Why are there cvs-syncmail and cvs-mailcommit? Why are there tkirc and xchat? Why are there whois and gwhois? Don't know enought about these. Why are there dupload and dput? Very good question! The only example which falls in the lintian / linda category. Oh no - it is even more stupid ... Why are there KDE and GNOME? Different taste of users - valid reason. Why are there icewm and windowmaker? Why are there mailman, smartlist and ecartis? Don't know enought about these. Guess some people have preferences for either languages or other. The reason: I just rewrite an application because the language it is written in. sounds a very stupid reason to me. Something else has to be broken with this application to make a real reason. (If not I now go and start programming a random application written in TCL/TK - feel free to insert any other language and spare the flameware.) Additionally, competing projects often improve the development of both projects. Sure, were competition makes sense from a usage point of view. But some applications (like dupload/dput and lintian/linda) have such a simple and clear purpose that it would be enouth if they would just work. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian linda (was: Automatic testing of Debian packages)
Le mardi 12 avril 2005 à 08:31 +0200, Andreas Tille a écrit : The reason: I just rewrite an application because the language it is written in. sounds a very stupid reason to me. Why? When you don't know Perl, and you feel like improving a software in Perl is like eating oysters with skiing gloves, rewriting the software in Python so that you can work on it seems like the best solution. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: lintian linda (was: Automatic testing of Debian packages)
* Andreas Tille [EMAIL PROTECTED] [050412 08:31]: Guess some people have preferences for either languages or other. The reason: I just rewrite an application because the language it is written in. sounds a very stupid reason to me. It doesn't for me after I heard, that foo was orhpaned. None volunteered to adopt it, but someone volunteered to write something, that does work in his prefered language. Sometimes it is easier to restart from scratch than to try to adopt an foreign thing. So we have linda and lintian. So what? Yours sincerely, Alexander signature.asc Description: Digital signature
Re: lintian linda (was: Automatic testing of Debian packages)
On Tue, 12 Apr 2005, Alexander Schmehl wrote: It doesn't for me after I heard, that foo was orhpaned. None volunteered to adopt it, but someone volunteered to write something, that does work in his prefered language. Sometimes it is easier to restart from scratch than to try to adopt an foreign thing. If we talk about foo you are right. But we talked about lintian which is a tool I expect to be needed by a lot of skilled perl programmers. Anybody of them will care about lintian before I finish my rewriting job. So we have linda and lintian. So what? So nothing. I was just wondering why people spend there time with things I would not really call effectice. Others play doom or whatever. I prefer people spending their time with redoing things which are just done. So thanks to the linda programmers to not just play shot-em-up games or eating oysters with skiing gloves or whatever. But the question was about the sense and I told here I fail to see the sense (ins this special case) as I fail to see the sense of shot-em-up games (in any case). Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian linda (was: Automatic testing of Debian packages)
On Mon, April 11, 2005 22:26, Emanuele Rocca said: Well some differences came out: - linda has proper l10n strings for most errors (in German) - different output formats - different test sets - linda is faster So, linda is better than lintian? Faster and localized, that sound like good benefits to me. I haven't heard anyone listing the benefits of lintian over linda. Why aren't we using linda then instead of lintian and merge any tests that lintian has and linda doesn't into linda? That would give us all a better tool, right? These programs have a very limited scope; it's better compared with creating www1.debian.org and www2.debian.org that both have different content and features than comparing it with vi/emacs. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian linda (was: Automatic testing of Debian packages)
Hello Emanuele, * Emanuele Rocca [EMAIL PROTECTED] [2005-04-12 07:53]: * [ 11-04-05 - 22:03 ] Nico Golde [EMAIL PROTECTED] wrote: * Martin Schulze [EMAIL PROTECTED] [2005-04-11 22:00]: Why are there Vi and Emacs? Why are there Perl and Python? [...] But thats not my problem. The programs etc. you showed are very different in using, look etc. What I dont know is what is the difference except the programming language in the case of lintian and linda. Nobody told me yet. Well some differences came out: - linda has proper l10n strings for most errors (in German) - different output formats http://lists.debian.org/debian-devel/2005/04/msg00484.html - different test sets - linda is faster http://lists.debian.org/debian-devel/2005/04/msg00489.html Ok thanks for sum up the points! Regards and thanks to all Nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred pgpYmihae70Or.pgp Description: PGP signature
Re: lintian linda (was: Automatic testing of Debian packages)
On Tue, Apr 12, 2005 at 09:20:28AM +0200, Josselin Mouette wrote: Le mardi 12 avril 2005 à 08:31 +0200, Andreas Tille a écrit : The reason: I just rewrite an application because the language it is written in. sounds a very stupid reason to me. Why? When you don't know Perl, and you feel like improving a software in Perl is like eating oysters with skiing gloves, rewriting the software in Python so that you can work on it seems like the best solution. Hi those who breathe life into code, could the 'test' that linda and lintian use be written in a 'common' format -- heaven forfend something like xml x-) just a thought, Kev -- counter.li.org #238656 -- goto counter.li.org and be counted! _, _, ,'`. `$$' `$$' `. ,' $$ $$`' $$ $$ _, _ ,d$$$g$$ ,d$$$b. $$,d$$$b.`$$' g$b.`$$,d$$b. ,$P' `$$ ,$P' `Y$. $$$' `$$ $$ ' `$$ $$$' `$$ $$'$$ $$' `$$ $$'$$ $$ ,g$$ $$' $$ $$ $$ $$g$$ $$ $$ $$ ,$P $$ $$$$ $$,$$ $$. $$,$P $$ $$' ,$$ $$$$ `$g. ,$$$ `$$._ _., $$ _,g$P' $$ `$b. ,$$$ $$$$ `Y$$P'$$. `YP',P' ,$$. `Y$$P'$$.$$. ,$$. signature.asc Description: Digital signature
Re: lintian linda (was: Automatic testing of Debian packages)
Hello Josselin, * Josselin Mouette [EMAIL PROTECTED] [2005-04-12 11:53]: Le mardi 12 avril 2005 à 08:31 +0200, Andreas Tille a écrit : The reason: I just rewrite an application because the language it is written in. sounds a very stupid reason to me. Why? When you don't know Perl, and you feel like improving a software in Perl is like eating oysters with skiing gloves, rewriting the software in Python so that you can work on it seems like the best solution. That wasn't the point. The question was. What is improved? But it should be clear now. Regards Nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred pgpzFhkoj9WpO.pgp Description: PGP signature
Re: lintian linda
On Mon, 2005-04-11 at 07:36 +0200, Andreas Tille wrote: On Sun, 10 Apr 2005, Bernd Eckenfels wrote: [snip] Which is if course a big point if you consider programmers can only help in one but not the other. Hmmm - I wonder whether rewriting an application wouldn't take more time than doing the usual things in free software: 1) Write bug reports. 2) Provide patches - well a programmer who is skilled enouth to rewrite a complete application is definitely skilled enouth to learn a quite common programming language in a shorter time than the rewrite would take - at least good enouth to provide patches. Then why was aptitude written? Why not send patches against apt-get and dselect? ISTM that the good reason for writing-from-scratch duplicate functionality is if you have a Better Idea (better data structures, better interfaces, extra functionality, etc, etc) that are so fundamental that You Can't Get There From Here by patching existing code. [snip] -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. More things in politics happen by accident or exhaustion than happen by conspiracy. Jeff Greenfield, CNN political analyst signature.asc Description: This is a digitally signed message part
Re: lintian linda
On Mon, 11 Apr 2005, Ron Johnson wrote: Then why was aptitude written? Why not send patches against apt-get and dselect? I just use apt-get so I'm not completely competent to answer this question. But IMHO aptitude was written to *replace* dselect. If we agree that a certain application can not be enhanced a rewrite makes perfectly sense. My arguing was against: I do not understand this programming language and thus I rewrite this application in my favourite language. ISTM that the good reason for writing-from-scratch duplicate functionality is if you have a Better Idea (better data structures, better interfaces, extra functionality, etc, etc) that are so fundamental that You Can't Get There From Here by patching existing code. Definitely. But this is the first time I read this argument in this thread. From a users point of view up to this day I have not found any important difference between lintian and linda (from time to time one finds more problems than the other, but there is no tendency which one finds more). From a users point of view I found LOTS of differences between dselect and aptitude (even at first glance). Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian linda
* [ 11-04-05 - 09:14 ] Ron Johnson [EMAIL PROTECTED] wrote: ISTM that the good reason for writing-from-scratch duplicate functionality is if you have a Better Idea (better data structures, better interfaces, extra functionality, etc, etc) that are so fundamental that You Can't Get There From Here by patching existing code. Everybody agrees here, but (AFAIK) this is not the situation we are discussing. No 'Better Ideas' in linda. ciao, ema -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian linda
In article [EMAIL PROTECTED] you wrote: Everybody agrees here, but (AFAIK) this is not the situation we are discussing. No 'Better Ideas' in linda. You have to see that in the context. Linda was written while lintian was not-so-good maintained. And of course if somebody decides to pick up a problem and solve it he/she is free to pick the tool he likes. Now that both are equally well maintained, there is no point in complaining and everybody can pick one. Sooner or later one of both will fall behind or diverge in another direction. And most likely this is due to the internal differences and the thinking of the authors. One spin-off I could for example imagine (even unlikely) is a generic package verification tool or a dpkg-api rewrite. BTW: linda and lindian are as different as 2 VI clones are... Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian linda
Emanuele Rocca wrote: * [ 11-04-05 - 09:14 ] Ron Johnson [EMAIL PROTECTED] wrote: ISTM that the good reason for writing-from-scratch duplicate functionality is if you have a Better Idea (better data structures, better interfaces, extra functionality, etc, etc) that are so fundamental that You Can't Get There From Here by patching existing code. Everybody agrees here, but (AFAIK) this is not the situation we are discussing. No 'Better Ideas' in linda. From a QA POV it is surely beneficial to have two independent implementations of the same QA tool. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian linda
On Mon, 11 Apr 2005 09:45:04 +0200, Emanuele Rocca uttered Everybody agrees here, but (AFAIK) this is not the situation we are discussing. No 'Better Ideas' in linda. Speak for yourself. Here are three (off the top of my head) that spring to mind that lintian can't do, and I feel better serve users. 1) Proper English descriptions, rather than tags. [EMAIL PROTECTED]:~% linda /var/cache/apt/archives/abiword_2.2.7-1_i386.deb E: abiword; No manual page for binary AbiWord-2.2. 2) Proper l10n strings for most errors (in German, anyway) [EMAIL PROTECTED]:~% LANG=de_DE linda /var/cache/apt/archives/abiword_2.2.7-1_i386.deb E: abiword; Keine Handbuchseite für Binary AbiWord-2.2. 3) Different output formats. [EMAIL PROTECTED]:~% linda -f long /var/cache/apt/archives/abiword_2.2.7-1_i386.deb Package: abiword Type: Error Description: No manual page for binary AbiWord-2.2. One very pissed off developer, -- Steve Why does everyone say 'Relax' when they're about to do something terrible? - Ensign Harry Kim, USS Voyager
Re: lintian linda
Hi Steve, * [ 11-04-05 - 12:39 ] Steve Kowalik [EMAIL PROTECTED] wrote: On Mon, 11 Apr 2005 09:45:04 +0200, Emanuele Rocca uttered Everybody agrees here, but (AFAIK) this is not the situation we are discussing. No 'Better Ideas' in linda. Speak for yourself. I obiouvsly speak for myself and I said AFAIK because I didn't know what features differences lintian and linda and (until your reply) nobody explained me them. Here are three (off the top of my head) that spring to mind that lintian can't do, and I feel better serve users. Wonderful, this is what I was trying to understand. 1) Proper English descriptions, rather than tags. [EMAIL PROTECTED]:~% linda /var/cache/apt/archives/abiword_2.2.7-1_i386.deb E: abiword; No manual page for binary AbiWord-2.2. 2) Proper l10n strings for most errors (in German, anyway) [EMAIL PROTECTED]:~% LANG=de_DE linda /var/cache/apt/archives/abiword_2.2.7-1_i386.deb E: abiword; Keine Handbuchseite für Binary AbiWord-2.2. 3) Different output formats. [EMAIL PROTECTED]:~% linda -f long /var/cache/apt/archives/abiword_2.2.7-1_i386.deb Package: abiword Type: Error Description: No manual page for binary AbiWord-2.2. It would be very nice to add these to linda's description. This way, every user can decide to install linda rather than lintian if they need these specific features. One very pissed off developer, It was not my intention to be rude, I am sorry. ciao, ema -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian linda
ma, 2005-04-11 kello 13:19 +0200, Emanuele Rocca kirjoitti: It would be very nice to add these to linda's description. This way, every user can decide to install linda rather than lintian if they need these specific features. Given that the two tools have different sets of tests, even if many of them overlap, there is no point in not installing and using both. The fact that they have different tests is pretty obvious in that they are different programs, so I don't even feel there is a point in enumerating the tests in the descriptions, or anything. lintian *.changes linda *.changes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian linda
Hi Lars, * [ 11-04-05 - 13:25 ] Lars Wirzenius [EMAIL PROTECTED] wrote: ma, 2005-04-11 kello 13:19 +0200, Emanuele Rocca kirjoitti: It would be very nice to add these to linda's description. This way, every user can decide to install linda rather than lintian if they need these specific features. Given that the two tools have different sets of tests, even if many of them overlap, there is no point in not installing and using both. The fact that they have different tests is pretty obvious in that they are different programs, so I don't even feel there is a point in enumerating the tests in the descriptions, or anything. The fact that they run different sets of tests is not so obiouvs; the Developer's Reference states it [1] and I don't see why it should not be noted in the long description too. The extended description should describe what the package does and how it relates to the rest of the system. [2] It seems that there is also a difference in the execution speed, which is IMHO worth mentioning. ...she (linda) checks packages a lot faster than lintian. [3] Lintian, although written in Perl, is unwieldy and slow. [4] Moreover, since it is useful to run both of them, they could mutually add their 'relative' in the Suggests field. My 2 cents. ciao, ema [1] http://www.debian.org/doc/manuals/developers-reference/ap-tools.en.html#s-linda [2] http://www.debian.org/doc/debian-policy/ch-binary.html#s-extendeddesc [3] http://www.debian.org/News/weekly/2002/12/ [4] http://people.debian.org/~stevenk/linda/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian linda
On Monday 11 April 2005 03:14 am, Ron Johnson wrote: Then why was aptitude written? Why not send patches against apt-get and dselect? The correct question is why not send patches against console-apt, which you youngsters might not remember ;-). In fact, I did exactly that -- I sent about two patches to fix problems with it before deciding that the design was fundamentally flawed and there was a better way to do things. (hey, hubris is one virtue of a programmer, right? :) ) Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ | Will the last person to leave the Universe please | | turn off the lights and close the door? | \- A duck! -- http://www.python.org / pgp2drf7N9U0n.pgp Description: PGP signature
Re: lintian linda
On Monday 11 April 2005 06:39 am, Steve Kowalik wrote: 1) Proper English descriptions, rather than tags. [EMAIL PROTECTED]:~% linda /var/cache/apt/archives/abiword_2.2.7-1_i386.deb E: abiword; No manual page for binary AbiWord-2.2. -i. Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ | He had a terrible memory. He remembered everything.| \-- Listener-supported public radio -- NPR -- http://www.npr.org ---/ pgpV37gxmNS99.pgp Description: PGP signature
Re: lintian linda
Hello Bernd, * Bernd Eckenfels [EMAIL PROTECTED] [2005-04-11 15:07]: In article [EMAIL PROTECTED] you wrote: Sure, but only if two projects have at least some differences; in 'The Cathedral and the Bazaar' popclient becomes fetchmail. There are a lot differences between linda and lintian, especially the programming language. Which is if course a big point if you consider programmers can only help in one but not the other. Yes maybe but I think this shouldn't be the write way. If this would be the case we would ahve more programms written in different languages but in the same purpose. There are some but in my opinion this is *not* the way open source works in general. The program is designed for users and users in most cases don't recognize in which language the program is written. And I don't think that there aren't enough skilled people who aren't able to provide patches. Regards Nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred pgpYu7YwSOo6d.pgp Description: PGP signature
Re: lintian linda
Hello Bernd, * Bernd Eckenfels [EMAIL PROTECTED] [2005-04-11 15:09]: In article [EMAIL PROTECTED] you wrote: Everybody agrees here, but (AFAIK) this is not the situation we are discussing. No 'Better Ideas' in linda. You have to see that in the context. Linda was written while lintian was not-so-good maintained. Yes ok. But now it is. That's why I asked. Maybe it would be a good time to combine the forces. [...] kind regards Nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred pgpYvvdE5VsCF.pgp Description: PGP signature
Re: lintian linda
Hello Marc, * Marc 'HE' Brockschmidt [EMAIL PROTECTED] [2005-04-11 15:08]: Nico Golde [EMAIL PROTECTED] writes: Sometimes there is the case that major design decisions are too different from the original source so there is no other way. but is this the case with lintian and linda? Yes. linda is written in Python and lintian in Perl. That's a major difference and is the reason why we don't share code. Ok thats a point. But if the differences are in design ideas it wouldn't be too difficult to transfer python to perl or other way round. Regards Nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred pgpp2QLx8sUr0.pgp Description: PGP signature
Re: lintian linda (was: Automatic testing of Debian packages)
Nico Golde wrote: There is another thing that I don't understand often. Why are there linda and lintian? In my opinion this makes things difficulter. Both have to coordinate themselves and keep their policy rules up to date. Why are there Vi and Emacs? Why are there Perl and Python? Why are there viewcvs and cvsweb? Why are there cvs-syncmail and cvs-mailcommit? Why are there tkirc and xchat? Why are there whois and gwhois? Why are there dupload and dput? Why are there KDE and GNOME? Why are there icewm and windowmaker? Why are there mailman, smartlist and ecartis? Guess some people have preferences for either languages or other. Additionally, competing projects often improve the development of both projects. Regards, Joey -- If nothing changes, everything will remain the same. -- Barne's Law Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian linda
In article [EMAIL PROTECTED] you wrote: There are some but in my opinion this is *not* the way open source works in general. The program is designed for users and users in most cases don't recognize in which language the program is written. No open source is not about the user it is about the developers ego and skills in the first place. And I don't think that there aren't enough skilled people who aren't able to provide patches. You cant force an active community to stop working on a project, and I doubt you can force a perl geek to indent code or have a python fan use cryptic single character variables. All they want to do is having fun while beeeing helpfull. And of course they like the competition and are proud of their work. Its about humans. Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian linda (was: Automatic testing of Debian packages)
* Martin Schulze [EMAIL PROTECTED] [2005-04-11 22:00]: Nico Golde wrote: There is another thing that I don't understand often. Why are there linda and lintian? In my opinion this makes things difficulter. Both have to coordinate themselves and keep their policy rules up to date. Why are there Vi and Emacs? Why are there Perl and Python? [...] But thats not my problem. The programs etc. you showed are very different in using, look etc. What I dont know is what is the difference except the programming language in the case of lintian and linda. Nobody told me yet. I don't want to rant about the projectsi just want to know things. Regards Nico -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian linda (was: Automatic testing of Debian packages)
* [ 11-04-05 - 22:03 ] Nico Golde [EMAIL PROTECTED] wrote: * Martin Schulze [EMAIL PROTECTED] [2005-04-11 22:00]: Why are there Vi and Emacs? Why are there Perl and Python? [...] But thats not my problem. The programs etc. you showed are very different in using, look etc. What I dont know is what is the difference except the programming language in the case of lintian and linda. Nobody told me yet. Well some differences came out: - linda has proper l10n strings for most errors (in German) - different output formats http://lists.debian.org/debian-devel/2005/04/msg00484.html - different test sets - linda is faster http://lists.debian.org/debian-devel/2005/04/msg00489.html ciao, ema -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian linda (was: Automatic testing of Debian packages)
* [ 08-04-05 - 15:38 ] Nico Golde [EMAIL PROTECTED] wrote: There is another thing that I don't understand often. Why are there linda and lintian? In my opinion this makes things difficulter. Both have to coordinate themselves and keep their policy rules up to date. [...] The only difference I can see is that they are programmed in different programming languages and minor things. Yep, it seems that the main difference is the programming language [0]. Peter Makholm asked [1] to add a note in Linda's description that points out the difference between the two checkers, but the only reference to Lintian seems to be 'much like lintian'. :) The main reason for the existence of Linda seems to be that at the time the author wrote it, Lintian was unmanintained. [2] In my opinion it is not productive to have two tools for internal debian use which provides pretty much the same things. I agree. Otherwise, if the two tools have got different features, these should be noted in the respective descriptions. ciao, ema [0] http://lists.debian.org/debian-mentors/2003/07/msg00045.html [1] http://lists.debian.org/debian-wnpp/2002/06/msg00065.html [2] http://comas.linux-aktivaattori.org/debconf5/general/proposals/35 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian linda (was: Automatic testing of Debian packages)
Hallo Emanuele, * Emanuele Rocca [EMAIL PROTECTED] [2005-04-10 19:21]: * [ 08-04-05 - 15:38 ] Nico Golde [EMAIL PROTECTED] wrote: There is another thing that I don't understand often. Why are there linda and lintian? In my opinion this makes things difficulter. Both have to coordinate themselves and keep their policy rules up to date. [...] The only difference I can see is that they are programmed in different programming languages and minor things. Yep, it seems that the main difference is the programming language [0]. Peter Makholm asked [1] to add a note in Linda's description that points out the difference between the two checkers, but the only reference to Lintian seems to be 'much like lintian'. :) The main reason for the existence of Linda seems to be that at the time the author wrote it, Lintian was unmanintained. [2] Ok thats a reason. But why not merge these projects now? I really recommend this because in my opinion this are two projects which do the same job twice which is in my eyes contraproductive. Same thing for dput and dupload. In my opinion it is not productive to have two tools for internal debian use which provides pretty much the same things. I agree. Otherwise, if the two tools have got different features, these should be noted in the respective descriptions. But why have they? I mean they are both tools for internal debian use. Regards Nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred pgp5qlQVvloWj.pgp Description: PGP signature
Re: lintian linda
In article [EMAIL PROTECTED] you wrote: Ok thats a reason. But why not merge these projects now? I really recommend this because in my opinion this are two projects which do the same job twice which is in my eyes contraproductive. Actually that is how open source works. I often also feel that this duplicate work, most often driven by personal preferences is wasted time, but then I get out my Kathedral and Bazaar book and read it again and come to the conclushion that competition and alternatives are good (in the long term). Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian linda
Hi Bernd, * [ 10-04-05 - 20:28 ] Bernd Eckenfels [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED] you wrote: Ok thats a reason. But why not merge these projects now? I really recommend this because in my opinion this are two projects which do the same job twice which is in my eyes contraproductive. Actually that is how open source works. I often also feel that this duplicate work, most often driven by personal preferences is wasted time, but then I get out my Kathedral and Bazaar book and read it again and come to the conclushion that competition and alternatives are good (in the long term). Sure, but only if two projects have at least some differences; in 'The Cathedral and the Bazaar' popclient becomes fetchmail. Whenever someone submits an ITP for the software A, whose functionality is already provided in Debian by B, the standard question is Why is A better than B? From your long description it is not clear which are the aspect that make them different. ciao, ema -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian linda
Hello Bernd, * Bernd Eckenfels [EMAIL PROTECTED] [2005-04-10 22:17]: In article [EMAIL PROTECTED] you wrote: Ok thats a reason. But why not merge these projects now? I really recommend this because in my opinion this are two projects which do the same job twice which is in my eyes contraproductive. Actually that is how open source works. No I don't think so. Open source would be to share the improvements, as people sent their improvements to rms instead of writing own editors in the past Sometimes there is the case that major design decisions are too different from the original source so there is no other way. but is this the case with lintian and linda? I mean basically they do check policy rules. I often also feel that this duplicate work, most often driven by personal preferences is wasted time, but then I get out my Kathedral and Bazaar book and read it again and come to the conclushion that competition and alternatives are good (in the long term). I don't think that fork projects is wasted time in general (i am one of the mutt forkers with mutt-ng) but i am not quite shure if it makes sence in this case. maybe the authors of linda and lintian could say something about this. regards nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred pgpVND9cTLdFn.pgp Description: PGP signature
Re: lintian linda
Hallo Emanuele, * Emanuele Rocca [EMAIL PROTECTED] [2005-04-10 23:01]: * [ 10-04-05 - 20:28 ] Bernd Eckenfels [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED] you wrote: Ok thats a reason. But why not merge these projects now? I really recommend this because in my opinion this are two projects which do the same job twice which is in my eyes contraproductive. Actually that is how open source works. I often also feel that this duplicate work, most often driven by personal preferences is wasted time, but then I get out my Kathedral and Bazaar book and read it again and come to the conclushion that competition and alternatives are good (in the long term). Sure, but only if two projects have at least some differences; in 'The Cathedral and the Bazaar' popclient becomes fetchmail. Whenever someone submits an ITP for the software A, whose functionality is already provided in Debian by B, the standard question is Why is A better than B? From your long description it is not clear which are the aspect that make them different. Thats what I think too. What do others think about this? Regards Nico -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred pgpjoVHYEruYB.pgp Description: PGP signature
Re: lintian linda
On Sun, Apr 10, 2005 at 11:26:43PM +0200, Nico Golde wrote: Sure, but only if two projects have at least some differences; in 'The Cathedral and the Bazaar' popclient becomes fetchmail. Whenever someone submits an ITP for the software A, whose functionality is already provided in Debian by B, the standard question is Why is A better than B? From your long description it is not clear which are the aspect that make them different. Thats what I think too. What do others think about this? I think it's a person decision what is he/she doing with his/her free time. If someone wants to create third policy checker in Ruby, then I have nothing against it. Sure there are many other more important things to do, but hey, don't demand particular tasks from someone who wants to do something else. Just my $0,03. regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: lintian linda
In article [EMAIL PROTECTED] you wrote: Sure, but only if two projects have at least some differences; in 'The Cathedral and the Bazaar' popclient becomes fetchmail. There are a lot differences between linda and lintian, especially the programming language. Which is if course a big point if you consider programmers can only help in one but not the other. Whenever someone submits an ITP for the software A, whose functionality is already provided in Debian by B, the standard question is Why is A better than B? From your long description it is not clear which are the aspect that make them different. This standard question is annoying and unneeded. There is no point in deciding for one or the other package. And this is a quite new trend that debian community start to think they have the right to pick. Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian linda
Hi Bernd, * [ 10-04-05 - 23:33 ] Bernd Eckenfels [EMAIL PROTECTED] wrote: There are a lot differences between linda and lintian, especially the programming language. We would like to know which are these differences. :) Nico's original question was why are there linda and lintian?. http://lists.debian.org/debian-devel/2005/04/msg00396.html Do they provide different *features*? Which is if course a big point if you consider programmers can only help in one but not the other. You're right here. Whenever someone submits an ITP for the software A, whose functionality is already provided in Debian by B, the standard question is Why is A better than B? From your long description it is not clear which are the aspect that make them different. This standard question is annoying and unneeded. There is no point in deciding for one or the other package. And this is a quite new trend that debian community start to think they have the right to pick. I actually think that this question is not so unneeded. The ITP could simply miss to mention the important features, and asking such a question can lead to an improved long description. Potential problems with packages which provide *exactly the same functionalities* are: duplication of efforts on the developers' side, user confusion, waste of archive space... ciao, ema -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian linda
Nico Golde [EMAIL PROTECTED] writes: Sometimes there is the case that major design decisions are too different from the original source so there is no other way. but is this the case with lintian and linda? Yes. linda is written in Python and lintian in Perl. That's a major difference and is the reason why we don't share code. Marc, stating the obvious -- $_=')(hBCdzVnS})3..0}_$;//::niam/s~=)]3[))_$(rellac(=_$({pam(esrever })e$.)4/3* )e$(htgnel+23(rhc,u(kcapnu ,nioj ;|_- |/+9-0z-aZ-A|rt~=e$;_$=e${pam tnirp{y V2ajFGabus} yV2ajFGa{gwmclBHIbus}gwmclBHI{yVGa09mbbus}yVGa09mb{hBCdzVnSbus'; s/\n//g;s/bus/\nbus/g;eval scalar reverse # mailto:[EMAIL PROTECTED] pgpVpaFvYtzlx.pgp Description: PGP signature
Re: duplicate functionality in packages [was: lintian linda]
On Sun, Apr 10, 2005 at 11:33:24PM +0200, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: [mjp: I sure didn't write this, but that's how it's been attributed...] Whenever someone submits an ITP for the software A, whose functionality is already provided in Debian by B, the standard question is Why is A better than B? From your long description it is not clear which are the aspect that make them different. This standard question is annoying and unneeded. There is no point in deciding for one or the other package. And this is a quite new trend that debian community start to think they have the right to pick. There's two reasons for this trend, IMO (as one who asks these questions on occasion): 1) If there are differences with other existing packages, they should be properly enumerated to give potential users the best chance of picking the correct package for their needs. 2) The potential maintainer may not have chosen to duplicate existing functionality, but has merely missed the alternatives in the insanity that is the Debian software archive. In that case, pointing out the existence of alternatives may cause the packager to use the existing code instead of making another new package (thus bloating the archive still further). Before you say but that might leave a superior alternative out of Debian, note that: (a) it might also leave an inferior alternative out of Debian, and (b) If the new package is superior, then it's unlikely that the potential packager will choose to use the inferior one anyway. - Matt (Combating archive bloat via ITP-analysis since 2003) signature.asc Description: Digital signature
Re: lintian linda
On Sun, 10 Apr 2005, Bernd Eckenfels wrote: There are a lot differences between linda and lintian, especially the programming language. A very important difference. This might result in several further applications doing the very same job (more or less) for several other programming languages (Ruby, why not C, C++ or even FORTRAN). My impression was that applications are written for *users* not for programmers. Mentioning the different programming languages as a difference of the applications is the wrong point of view. Which is if course a big point if you consider programmers can only help in one but not the other. Hmmm - I wonder whether rewriting an application wouldn't take more time than doing the usual things in free software: 1) Write bug reports. 2) Provide patches - well a programmer who is skilled enouth to rewrite a complete application is definitely skilled enouth to learn a quite common programming language in a shorter time than the rewrite would take - at least good enouth to provide patches. This standard question is annoying and unneeded. In fact you are right, because discussing this question does not lead to any reasonable result. Everybody is free to spend his time as he likes and there will be people in the future who will continue in rewriting applications just because they have other preferences in the choice of programming language or just a different toolkit. On the other hand why not educating people that they should focus on their users instead on their programming preferences from time to time? There is no point in deciding for one or the other package. And this is a quite new trend that debian community start to think they have the right to pick. Sorry, we have to pick. Imaginge a maintainer has time to build a package of exactly one application which fulfills a certain purpose. Furthermore imagine there are three applications which fulfill this purpose available. A person with limited time frame has to pick one. I would consider it as good style if he would also give reasons for the decision why he picked this application and I really hope that the choice of programming language would not be the main reason (except if he has to leave out an application which is written in a language which requires non-free tools - this is a reason to stay away from certain applications). Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
lintian linda (was: Automatic testing of Debian packages)
Hallo Mads, * Mads Lindstrøm [EMAIL PROTECTED] [2005-04-08 14:08]: I am writing this email as I think there could be done more to automatically test Debian packages. This would improve quality, as discovering errors is the first step in correcting them. I am not a Debian maintainer, but have been using Debian for 4+ years. As I am not an insider, I am likely to overlook some relevant information and I would be happy if people will correct me. I have looked at the Debian homepage to investigate what kind of auto-testing are performed. I found the auto-builder network (http://www.nl.debian.org/devel/buildd/), Lintian [...] There is another thing that I don't understand often. Why are there linda and lintian? In my opinion this makes things difficulter. Both have to coordinate themselves and keep their policy rules up to date. The only difference I can see is that they are programmed in different programming languages and minor things. In my opinion it is not productive to have two tools for internal debian use which provides pretty much the same things. Why not merge this two projects? Regards Nico P.S. I mostly use lintian so if I have forgotten to mention something please correct me. -- Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org VIM has two modes - the one in which it beeps and the one in which it doesn't -- encrypted mail preferred pgpK3Qx88qr3z.pgp Description: PGP signature
idea for lintian/linda check (Re: NEW handling ...)
On Thursday 17 March 2005 23:06, Matthew Palmer wrote: On Thu, Mar 17, 2005 at 10:15:50PM +0100, Sven Luther wrote: To know in how many packages to split or not to split the packages ? That would be one of the things that maintainers have gotten wrong in the past, yes. Would it be possible to code a check for lintian/linda how much space is used by the package in /usr/share and report an error when crossing a threshold (100kb? 500kB?) for Arch != all? Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir ber ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
Re: idea for lintian/linda check (Re: NEW handling ...)
On Thu, Mar 17, 2005 at 11:14:05PM +0100, David Schmitt wrote: On Thursday 17 March 2005 23:06, Matthew Palmer wrote: On Thu, Mar 17, 2005 at 10:15:50PM +0100, Sven Luther wrote: To know in how many packages to split or not to split the packages ? That would be one of the things that maintainers have gotten wrong in the past, yes. Would it be possible to code a check for lintian/linda how much space is used by the package in /usr/share and report an error when crossing a threshold (100kb? 500kB?) for Arch != all? Lintian has had a check in it for a while now for du -s /usr/share (I think) 1MB in arch != all packages. It could be a percentage check as well / instead, I don't recall the details. - Matt signature.asc Description: Digital signature