Re: Next Debian Release
Scripsit "Allen" <[EMAIL PROTECTED]> > To whom it may concern, I was wondering if you have schedule or > roadmap for the next available release version of Debian. The next release of Debian will happen When It's Ready . Current projections indicate that it may possibly be realistic to expect it to be ready in early December, but predicting things is a tricky business, and while the schedule would lead to a December release [1] has some built-in leeway for unexpected problems to turn up and be solved along the way, there really is no telling whether more problems will turn up that this slack can handle. [1] http://lists.debian.org/debian-devel-announce/2006/08/msg5.html -- Henning Makholm"*Jeg* tænker *strax* på kirkemødet i Konstantinopel i 381 e.Chr. om det arianske kætteri..." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#380388: ITP: toga2 -- computer chess engine, calculates chess moves
Scripsit Oliver Korff <[EMAIL PROTECTED]> > Description : computer chess engine, calculates chess moves We seem to have several such engines already. Could the description please say something that distinguishes this from the other ones? > This is one of the strongest chess programs on the planet. > Hell of an opponent and stronger than 90% of the commercial > chess engines. Would X% of Debian's other free chess engines not be a more relevant comparison? -- Henning Makholm "sh: line 1: fortune: command not found" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#378112: ITP: gzrt -- gzip recovery toolkit
Scripsit [EMAIL PROTECTED] (Marco d'Itri) > On Jul 13, Peter Samuelson <[EMAIL PROTECTED]> wrote: >> Presumably he intends to merely Recommend cpio, in which case it's >> entirely appropriate to explain why in the description. > README.Debian maybe, but not in the description... The package description is the appropriate place to document what the recommendations are there for. Contrary to README.Debian, it is shown by apt frontends at the time where a user need to decide whether he can ignore the recommendation (for example, if the recommended packages are uninstallable on his system for some reason). -- Henning Makholm Set your feet free! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
Scripsit Lars Wirzenius <[EMAIL PROTECTED]> > If package maintainer wants to build it faster on their own machine, I > would imagine that checking for an environment variable (DEB_MAKE_OPTS > or something, perhaps?) and using that would be the way to go. By > default, build with a single processor. If I understand the problem correctly, it is not even necessary to modify debian/rules to get this behavior. If the interdependencies are properly declared, $ debian/rules -j42 binary should do the trick, as GNU make is smart enough to pass the option down to sub-makes that it starts. Then all one has to do is to create and submit a patch for dpkg-buildpackage that lets it specify this flag on invocation. Well, in fact also design a mechanism to share knowledge about which source packages may break if given a -j due to insufficiently specified dependencies. So perhaps using $(DEB_MAKE_J_OPTION) on the "$(MAKE) all" line in debian/rules is a better choice after all. (In any case there is no need to check specifically whether it exists before using it - if it doesn't, make will silently expand it to nothing). -- Henning Makholm"And why should I talk slaves' and fools' talk? I don't want him to live for ever, and I know that he's not going to live for ever whether I want him to or not." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Scripsit Goswin von Brederlow <[EMAIL PROTECTED]> > Henning Makholm <[EMAIL PROTECTED]> writes: >> Scripsit Falk Hueffner <[EMAIL PROTECTED]> >>> Henning Makholm wrote: >>>> Another related bug type that I found lurking in my packages when I >>>> investigated the warnings in this list, is trying to format a size_t >>>> value with a %u or %d format string, >>> Since any sane ABI pads arguments to word size, this is only a problem >>> on big endian 64-bit architectures (that is, no current release >>> architecture). >> Hm, that makes sense. Perhaps I should back out my (clumsy) fixes for >> it, then. > No, the bug remains and should be fixed. The fix should be somehow unclumsified, though. Currently I inject some horrible runtime testing in the configure script to find out whether the clib supports the %zu format of C99, but that breaks crosscompilability (which I'm not sure worked before, but still...) Would it be safe to assume that a size_t can always be cast losslessly to an unsigned long (and then printed with %lu), or are there systems on which only an unsigned long long will do? -- Henning Makholm "Jeg forstår mig på at anvende sådanne midler på folks legemer, at jeg kan varme eller afkøle dem, som jeg vil, og få dem til at kaste op, hvis det er det, jeg vil, eller give afføring og meget andet af den slags." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Scripsit Falk Hueffner <[EMAIL PROTECTED]> > Henning Makholm wrote: >> Another related bug type that I found lurking in my packages when I >> investigated the warnings in this list, is trying to format a size_t >> value with a %u or %d format string, which will break if size_t is 64 >> bits (unless the actual number is small and it is the last argument >> and the endianness of the architecture happens to match its stack >> growth direction). > Since any sane ABI pads arguments to word size, this is only a problem > on big endian 64-bit architectures (that is, no current release > architecture). Hm, that makes sense. Perhaps I should back out my (clumsy) fixes for it, then. -- Henning Makholm"*Jeg* tænker *strax* på kirkemødet i Konstantinopel i 381 e.Chr. om det arianske kætteri..." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC 4.1 now the default GCC version for etch
Scripsit Andreas Metzler <[EMAIL PROTECTED]> > On 2006-06-07 Matthias Klose <[EMAIL PROTECTED]> wrote: >> We did pick two compiler warnings and scanned the build logs of one >> archive rebuild on alpha (64bit), where wrong code may be generated. >> - cast from pointer to integer of different size >>cast to pointer from integer of different size > i.e. if a package is currently in the archive, suffers from this > issues and the binary packages *currently* in the archive have been > built with gcc-4.0, should I > b) simply continue, as the package won't be broken more with gcc-4.1 > than it was with gcc-4.0? If the code is really nont 64bit-clean (i.e. it tries to store a pointer in a 32-bit integer and expects to be able to cast it back and still locate the data the original pointer pointed to), I cannot see how gcc-4.0 would have been able to create working code either. As I read Matthias' posting, these warnings were ones that were found as a kind of bonus outcome from the compile-everything-with-gcc4.1 experiment. Another related bug type that I found lurking in my packages when I investigated the warnings in this list, is trying to format a size_t value with a %u or %d format string, which will break if size_t is 64 bits (unless the actual number is small and it is the last argument and the endianness of the architecture happens to match its stack growth direction). This too produces a warning on all relevant gcc versions, but only when compiling to a 64-bit target. Somebody ought to create a tool that could easily compare the buildd logs for a package on different architectures and flag warnings that appear only for some but not arches, indicating a possible portability bug. -- Henning Makholm"What the hedgehog sang is not evidence." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Hidden files
Scripsit Klaus Ethgen <[EMAIL PROTECTED]> > There are two reasons not to use hidden files in /usr, /var, /dev and > other: > 1. It generates false positives (as mention before). And to many false >positives only ends in overlook the real bad files and directories. > 2. There is absolutely no reason to hide think in this directories. The underlying bug seems to be the entire concept of "hidden files". It seems to me that on the whole they cause far more trouble than they help. If they are only supposed to be in $HOME (and a tidy $HOME should contain nothing but dotfiles and subdirectories anyway), it is rather excessive to let the hiddenness work everywhere else in the system. It's a pity that this is fundamentally unfixable because there is no knowing how many little scripts everywhere that depend on ls filtering out "hidden" files. But I don't think I have ever used ls from an interactive shell _without_ the -a flag. -- Henning Makholm "The compile-time type checker for this language has proved to be a valuable filter which traps a significant proportion of programming errors." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NMU procedure and /usr/bin/nmudiff defaults
Scripsit Adeodato Simó <[EMAIL PROTECTED]> > * Junichi Uekawa [Mon, 05 Jun 2006 07:36:43 +0900]: >> I don't think there is much harm in opening a new NMU bug. > No, there isn't. Plus has been the right way for years, AIUI, and > dev-ref explicitly mentions it. How is it righter than sending the NMU diff to the bug that led one to NMU in the first place? Dev-ref §5.11.4 describes attaching the diff to the original bug as the common case, and explicitly calls opening a fresh bug an alternative. (Presumably to be used when an NMU that fixes many bugs is not easily splittable into individual patches). > There is no need to specify the bug number, since it can be extracted > from the changelog. The question is whether the option shall be --new, > so the default is to send the diff to the fixed bug(s) (my patch), or it > should be --no-open instead, thus defaulting to opening a new bug. Perhaps then the default ought to send to the existing bug if the changelog closes exactly one bug, and open a new bug report otherwise. -- Henning Makholm "Skidt med din brud når der står et par nymfer i tyl og trikot i den lysegrønne skov!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
Scripsit Steve Langasek <[EMAIL PROTECTED]> > As beautiful as this irony is of a non-developer asserting on a developer > list that being involved in development is irrelevant, But being involved in development _is_ irrelevant as regards whether his arguments have merit or not. -- Henning Makholm "Larry wants to replicate all the time ... ah, no, all I meant was that he likes to have a bang everywhere." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Red team attacks vs. cracking
Scripsit Gunnar Wolf <[EMAIL PROTECTED]> > Henning Makholm dijo [Wed, May 31, 2006 at 04:10:51AM +0200]: >> A KSP that depends on there being any pre-existing trust to abuse is >> *completely worthless* as a KSP whether or not that trust is abused >> or not. > Ummm... There is a certain metric of pre-existing trust that _does_ > exist here. Lets go back to Martin's specific case, to exemplify. I'm not saying that the trust does not _exist_, just that it should not be _necessary_ for the proper functioning of the keysigning process. -- Henning Makholm "Der er ingen der sigter på slottet. D'herrer konger agter at triumfere fra balkonen når de har slået hinanden ihjel." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debconf-discuss] list of valid documents for KSPs
Scripsit Manoj Srivastava <[EMAIL PROTECTED]> > Nothing that a general software developer can do to check an > ID is proof against a determined individual, we all assume that there > is a gentleman's agreement in place that such an attack is not > mounted. If you _really_ believed that you could depend on people keeping any gentleman's agreement, the whole charade of holding a KSP would be completely pointless. The only reason to hold a KSP is that one _does not_ believe that people are capable of keeping gentlemen's agreements. And you calling me and others naive for pointing out this obvious fact is not going to change it. > good faith would have been to present the official ID and extend > the web of trust. A security mechanism that only works in the non-presense of fraudsters is no security mechanism at all. -- Henning Makholm "I can get fat! I can sing!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Red team attacks vs. cracking
Scripsit Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> > I do agree with Manoj that this was *not* a legitimate experiment (i.e. > not a "red team" test) and that Martin *did* abuse our [0] trust [1] A KSP that depends on there being any pre-existing trust to abuse is *completely worthless* as a KSP whether or not that trust is abused or not. Shooting the messenger will not change that, however loudly you try to make it look as if it was his fault that the thing is so broken that "betrayal of trust" is even a meaningful term to apply to any behavior a KSP participant coul exhibit. -- Henning Makholm "Jeg har tydeligt gjort opmærksom på, at man ved at følge den vej kun bliver gennemsnitligt ca. 48 år gammel, og at man sætter sin sociale situation ganske overstyr og, så vidt jeg kan overskue, dør i dybeste ulykkelighed og elendighed." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debconf-discuss] list of valid documents for KSPs
Scripsit Manoj Srivastava <[EMAIL PROTECTED]> > I see you have never been in a large key signing party. There > is a certain expectation of trust, since no one can actrually detect > delibrate forgeries. If a key-signing method needs any particularly trustworthy behavior from the people asking to have keys signed, it is broken, plan and simple. It was broken from day one, and it becomes neither more nor less broken because anybody in particular does not behave according to the rule. The entire _point_ of the web-of-trust is to not take people's claim about their identity at face value. It is a process rooted in _distrust_ and if the mechanisms end up with certified trust where none is warranted, the mechanisms are at fault. You seem to think that key-signing parties only work if all participants are honest. That may be so, but if all participants ARE honest, key-signing in general would be pointless. If the parties do not work in the presense of dishonest participants they are completely broken, serve no useless purpose, and might as well be abandoned. This is true whether or not any precense of dishonest participants have been speculated or confirmed, and if it is true after Martins experiment, it was equally true before it. > There items I used to check on were the photograph, seplling of the > name, expiration date for the document, and, optionally, age. If you do your checks on a way that assume honesty on the signee's part, then your checks are broken. When you sign keys you should _assume_ that the unknown person who wants you to sign a key is dishonest about who he claims to be, and only sign if you see something that positively convince you otherwise. > -- since good faith expectations were that people were not > trying to game the system. Good faith expectations have absolutely no place in a system that is based on distrusting people and demanding proof of their claims. > If people start bringing in forged documents, no amount of > caution on part of laypeople like most software developers is proof > against such deception. Correct. If you think the system depends on people being honest in the first place, the system has no conceivable useful purpose. -- Henning Makholm "Nemo enim fere saltat sobrius, nisi forte insanit." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debconf-discuss] list of valid documents for KSPs
Scripsit Gunnar Wolf <[EMAIL PROTECTED]> > There is something, though, that I think would be a worthy addition to > future KSPs, if we continue to hold them: Many of us have our photo as > part of our key. Maybe if the printed sheet was not plain-text but > included those photos that are available, it would be at least a > slight improvement? How exactly would that help anything? That is, under which attack model would it improve the security of the system? Note that when you stand before a stranger at a KSP, it is _not_ in doubt that he controls the _key_ that he wants you to sign. (Or rather: if he does not control it, he would have nothing to gain from having you sign it). Submitting a (signed) photo in avance would prove nothing but his control of the key, and that is not an intersting property. What _is_ in doubt is that his real-life identify is the same as the user id that he wants you to sign. And the fact that someone has a photograph of himself says nothing about what his name is. _Anybody_ can have a photograph of themselves, easily, no matter whether they are who they claim to be or not. Thus the relevant attack model is: An attacker creates a key and types in somebody else's name as an uid. He goes to key-signing parties and tries to get other participants to sign the connection between his actual key fingerprint and the false name he has assumed. How would it help prevent such an attack that the attacker could supply a photo of his own to the KSP organizers and have all of the participants check that he looks like he does? On the contrary, it would inspire confusion because some participants would _think_ that the fact that the fraudster looks exactly like the photo he himself supplied could somehow mitigate the mismatch with the photo on the official ID document he presents. -- Henning Makholm "Ambiguous cases are defined as those for which the compiler being used finds a legitimate interpretation which is different from that which the user had in mind." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sending debian-private postings to gmail
Scripsit "Kevin B. McCarty" <[EMAIL PROTECTED]>
> Taken to extremes, this implies that (1) DD's should only receive mail
> sent to boxes under their own control and (2) all mail passing through
> debian-private should, for each subscriber to the list, be encrypted
> individually to the public key on file for her/him.
> Come to think of it, (2) isn't a bad idea. Is it feasible for this to
> be done transparently?
It may or may not be feasible to do it transparently on the list
software side, but it certainly isn't feasible to do it on the reader
side. I for one certainly am not going to make a daily effort to move
mail from the internet-connected box to the one that knows my secret
key, and type in my 100+ character passphrase several times in order
just to get to know that ${INSERT_RANDOM_DD} will be on vacation.
Better to drop -private completely then, and what does that gain
anybody?
--
Henning Makholm "I Guds Faders namn, och Sonens, och den Helige
Andes! Bevara oss från djävulens verk och från Muhammeds,
den förbannades, illfundigheter! Med dig är det värre än med
någon annan, ty att lyssna till Muhammed är det värsta av allt."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reportbug defaults [Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email]
Scripsit Don Armstrong <[EMAIL PROTECTED]> > On Wed, 17 May 2006, Henning Makholm wrote: >> How does sending directly to from reportbug to an ISP's smarthost >> validate the user's email address better than sending directly from >> reportbug to a HTTP POST somewhere? > I'm talking about an HTTP access method in general; if it were to be > done, I'd expect that it validate the users email address before > actually forwarding bug reports from the user. Why don't you have the same expectation about SMTP access methods? >> It is not necessary that there is anywhere any HTML form that refers >> to the posting URL; only reportbug would need to know it. > Except for the fact that anyone can create a page which posts to that > url. ... with a big large text box in which a user is supposed to manually format some text that can be parsed properly by the unknown backend script? If anybody _really_ wanted to fake a bug report with a wrong user, it is much simpler to use an off-the-shelf MUA than to try to reverse-engineer the data format used by a the private reportbug HTTP application. -- Henning Makholm "Det er trolddom og terror og jeg får en værre ballade når jeg kommer hjem!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email
Scripsit Ron Johnson <[EMAIL PROTECTED]> > On Wed, 2006-05-17 at 11:35 +0200, Adam Borowski wrote: >> Except, this is _doubling_ a question that was already asked somewhere else, >> ie, a bug. The UNIX way of configuring the mail is setting up a binary that >> knows how to deliver it as "/usr/sbin/sendmail"; it doesn't matter whether >> that binary will do the work itself, run ssh -T foo sendmail, or toss the >> mail to a smarthost. The Debian way of configuring stuff is asking the >> admin the relevant questions only once, and keeping the config in a shared >> place. > You're free to file a bug against every "Provides: mail-reader" app. Serious bugs should certainly be filed against any MUA in Debian whose default configuration is not to use /usr/sbin/sendmail for outgoing mail. I don't know of any such packages in Debian; do you? Personally I use mutt, which has never had the audacity to ask me for external SMTP or IMAP addresses. I have no doubt that it would gladly _accept_ such a specification if I needed to and cared to look up how to configure it, but the _default_ configuration is to use the _default_ mail transport mechanism in Debian, which is how it should be. -- Henning Makholm "Punctuation, is? fun!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: reportbug defaults [Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email]
Scripsit Don Armstrong <[EMAIL PROTECTED]> >> What about modifying it to work through something like an http POST? > I'm personally not too terribly interested in implementing an HTTP > access method for the BTS, because it makes it more easy for bug > submissions to be sent from people who can not be accessed via e-mail. How does sending directly to from reportbug to an ISP's smarthost validate the user's email address better than sending directly from reportbug to a HTTP POST somewhere? It is not necessary that there is anywhere any HTML form that refers to the posting URL; only reportbug would need to know it. -- Henning Makholm "This imposes the restriction on any procedure statement that the kind and type of each actual parameter be compatible with the kind and type of the corresponding formal parameter." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email
Scripsit Ron Johnson <[EMAIL PROTECTED]> > On Tue, 2006-05-16 at 19:21 +0200, Henning Makholm wrote: >> The point is that they could if the wanted to. And if they did, it >> would work for _all_ programs, not just particular perl scripts that >> happen to use some obscure perl module to send mails. > mail-transport-agent postinst config scripts will have to be a > lot more clever, then, and explain things like relayhosts to non- > sysadmins. Are you implying that the perl library in question is able to figure out these things without guidance from the sysadmin? In that case the AI code that does it ought to be appropriated and worked into our MTA postinst scripts. -- Henning Makholm "Monarki, er ikke noget materielt ... Borger!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Scripsit "Olaf van der Spek" <[EMAIL PROTECTED]> > On 5/16/06, Dagfinn Ilmari Mannsåker <[EMAIL PROTECTED]> wrote: >> Here's an idea: store the configuration meta data in the file itself, >> say, in the first line, following a comment starting with an exclamation >> mark. > This would kill MD5 checksums of changed files... No it wouldn't. The metadata that says which version of Python the program is written in is put there by the Debian maintainer and stays content. The metadata the says which binary on the system implements that version of Python is represented by links in the file system. What do you think the problem is? -- Henning Makholm "Also, the letters are printed. That makes the task of identifying the handwriting much more difficult." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email
Scripsit Ron Johnson <[EMAIL PROTECTED]> > On Tue, 2006-05-16 at 11:04 +0200, Henning Makholm wrote: >> Scripsit "Steinar H. Gunderson" <[EMAIL PROTECTED]> >> > On Mon, May 15, 2006 at 02:13:46PM +0200, Henning Makholm wrote: >> >> Why not just install some software that can speak SMTP as the chroot's >> >> /usr/bin/sendmail? E.g. nullmailer. >> > nullmailer is, in general, broken. >> Then something else. One can easily envisage installing as >> /usr/bin/sendmail something that reads an email, immediately >> sends it to a smarthost via SMTP and exits with an error if a problem >> happened. No daemon, no local spool. > Not all people have their systems configured that way. The point is that they could if the wanted to. And if they did, it would work for _all_ programs, not just particular perl scripts that happen to use some obscure perl module to send mails. > On the "home desktop" reportbug uses Python's smtp library to send > email directly to the ISP's smtp server. And that's a good thing, > because, for a long time, reportbug did not have that feature, and > people who don't know how to configure MTAs were not able to send > bug reports. Reportbug may be a special case in that. >> There is a reason for having standardised interfaces. It is that they >> can be implemented in different ways. > Yes. The standardized interface is smtp. Not according to Debian policy. It is perfectly acceptable to have a way of moving mail to and from the machine that does not use SMTP at all, as long as it provides the standard /usr/sbin/sendmail interface for programs that need to send mail. -- Henning Makholm Science, by its nature, is an uncertain undertaking, and offers plenty of opportunity for failure no matter how you approach it. Yet among the myriad ways to get nowhere, the only fully reliable one is doing and thinking the same as everyone else. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email
Scripsit Krzysztof Krzyzaniak <[EMAIL PROTECTED]> >> That would be accessible to _all_ programs whether they are written in >> Perl or not. > But I still not get it why not to use Email::Send and choose method > there? Because one might not be programming in Perl. > Email::Send is not another sendmail replacement - it's abstract > method for using mailers in way you want to use. /usr/sbin/sendmail _is_ an abstract method for sending mail through the transport configured by the system administrator. -- Henning Makholm "... a specialist in the breakaway oxidation phenomena of certain nuclear reactors." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Scripsit "Olaf van der Spek" <[EMAIL PROTECTED]> > Not true. For example, the kernel could be changed to pick the right > Python binary if it sees #!/usr/bin/python. There is already a hook for doing that that in the kernel; no patching is required. See the system calls link(2) and symlink(2). The (Essential) coreutils package provides a userspace binary /bin/ln which makes these calls available to shell scripts. -- Henning Makholm"Grisene fik gåsehud" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email
Scripsit "Steinar H. Gunderson" <[EMAIL PROTECTED]> > On Mon, May 15, 2006 at 02:13:46PM +0200, Henning Makholm wrote: >> Why not just install some software that can speak SMTP as the chroot's >> /usr/bin/sendmail? E.g. nullmailer. > nullmailer is, in general, broken. Then something else. One can easily envisage installing as /usr/bin/sendmail something that reads an email, immediately sends it to a smarthost via SMTP and exits with an error if a problem happened. No daemon, no local spool. That would be accessible to _all_ programs whether they are written in Perl or not. There is a reason for having standardised interfaces. It is that they can be implemented in different ways. -- Henning Makholm "En tapper tinsoldat. En dame i spagat. Du er en lykkelig mand ..." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email
Scripsit Russ Allbery <[EMAIL PROTECTED]> > More generally, Perl modules to send mail rather than using > /usr/sbin/sendmail are often useful with web applications (or other > applications that need security isolation) that are running in a chroot. > To use /usr/sbin/sendmail in the chroot requires setting up a chroot > maildrop, and while there are packages to do this, using some module that > can speak SMTP is often the path of least resistance. Why not just install some software that can speak SMTP as the chroot's /usr/bin/sendmail? E.g. nullmailer. -- Henning Makholm "Wir kommen nun ans Ziel unserer Ausführungen." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email
Scripsit "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]> > Email::Send provides a very simple, very clean, very specific interface > to multiple Email mailers. The goal if this software is to be small > and simple, easy to use, and easy to extend. What's wrong with the legacy /usr/sbin/sendmail interface, mandated by policy, LSB, etc? -- Henning Makholm "We will discuss your youth another time." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Scripsit "Olaf van der Spek" <[EMAIL PROTECTED]> > Goswin von Brederlow <[EMAIL PROTECTED]> wrote: >> That would be total insanity. Just think about the number of scripts >> with "#!/usr/bin/python" in it that would have to be changed. And how > Shouldn't such hard-coded paths be avoided in the long term (anyway)? The Linux kernel requires a full path for #! scripts. This makes sense if one considers a #! program to be something that should have predictable behavior no matter what the user happens to have in his $PATH. In multiarch, the right approach to this particular problem is to arrange for /usr/bin/python to be a symlink to /usr/bin/$arch/python with $arch chosen (somehow) appropriately for a default python interpreter. -- Henning Makholm"Detta, sade de, vore rena sanningen; ty de kunde tala sanning lika väl som någon annan, när de bara visste vad det tjänade til." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: utnubu-desktop for the masses
Scripsit Joey Hess <[EMAIL PROTECTED]> > Henning Makholm wrote: >> Can tasksel tasks be manipulated programmatically with the same >> apt/aptitude inferfaces that metapackages can? > This question does not have a yes or no answer, the situation is rather > more complex than that. Concretely: In order to clean up when I have played around with new packages, I have a script that 1) runs 'aptitude search ~i' and parses the output 2) compares with a hand-maintained list of packages and metapackages that should be installed (with their dependencies) on my machine. 3) emits appropriate 'aptitude markauto foo' and 'aptitude install bar' commands to remove packages that should not be there and install any packages that have been lost (perhaps because I temporarily removed them due to conflicts). If the metapackages in my hand-maintiained list are changed to tasksel tasks, can I still use my script without adding a parallel block of code for handling the tasks? (How can that question not have a yes or no answer?) If I can't, then I oppose replacing those metapackages with tasks. -- Henning Makholm "However, the fact that the utterance by Epimenides of that false sentence could imply the existence of some Cretan who is not a liar is rather unsettling." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: utnubu-desktop for the masses
Scripsit Steve Langasek <[EMAIL PROTECTED]> > On Sun, Apr 23, 2006 at 07:56:18PM -0700, Mike Bird wrote: >> On Sun, 2006-04-23 at 19:42, Steve Langasek wrote: >> > Having the metapackage kicked out of testing and having the release team >> > refuse to help you get it back into the release because you ignored their >> > recommendations is, however, not subjective. >> What if metapackages only recommended? > I have a hard time imagining how this differs positively from tasksel's task > support. Can tasksel tasks be manipulated programmatically with the same apt/aptitude inferfaces that metapackages can? If yes: Then how do they differ from packages, and how to we need a secondary concept at all? If no: Then I would very much like to keep the metapackages I use as ordinary packages, thank you. -- Henning Makholm "Punctuation, is? fun!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Help] Versioning of a library
Scripsit Andreas Tille <[EMAIL PROTECTED]> > I'm the maintainer of libgtkdatabox-0.2.3.0-0. [...] > My guess is that there is an ABI change involved and thus I have to > rename the package to libgtkdatabox-0.5.2.0-X . My question is: > What is the right choice for 'X' if I skipped several upstream > versions inbetween? Why do you have an -X component in the package name, if the 0.5.2.0 is the full upstream version number? Seems superfluous to me. -- Henning Makholm "The great secret, known to internists and learned early in marriage by internists' wives, but still hidden from the general public, is that most things get better by themselves. Most things, in fact, are better by morning." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation is FANTASTIC!!!
Scripsit Wolfgang Lonien <[EMAIL PROTECTED]> > And for those who still are complaining about the installer not being > graphical: please, guys, there's more than your x86 machines. Keep that > in mind. And where is the difference between a mouse click and a return > key (yes, it's - mostly - that easy!)? I don't care much for mouse clicks, but "80x25 characters and a 8-bit font" is a very low common denominator for the amount of text one can show on the screen when selecting packages or answering complex debconf questions. The 8-bit-ness of the font is not a problem for people installing in English, but being able to see more lines at a time should benefit everybody who want or need more control than just accepting all of the defaults. -- Henning Makholm "The practical reason for continuing our system is the same as the practical reason for continuing anything: It works satisfactorily." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Guidelines for packaging projects on Alioth
Scripsit Raphael Hertzog <[EMAIL PROTECTED]> > I would be in favor of a tighter integration between the PTS and the > @packages.debian.org email address too for example. > > I could implement a default subscription to the PTS for package > maintainers but you first need to solve several problems: > - decide which keywords they will receive by default (all except bts, > bts-control and upload-binary is my choice, and maybe katie-other) Perhaps we could start by only auto-subscribing the maintainer to a currently unused keyword, say "pdo". The next step would be to start redirecting [EMAIL PROTECTED] to that keyword. Subsequently, services that currently send mail directly to maintainers could be migrated one by one to send only to the PTS, and at the same time the relevant keyword could be added to the auto-subscribe-the-maintainer set. (I would dearly love to do this with the testing migration notices I send out from my "trille" cronjob. There are a handful of maintainers who have asked for a way to opt out, which I have not got around to hack my own implementation for). The ideal, I think, would be to centralize in the PTS *all* automatic emailing to maintainers, such that all everyting be opted into or out of by a common interface. (Hm, one may need except Katie mail that gets sent as a result of the upload that changes the maintainer, but before the PTS gets a chance to take note of the change. Some thought will be needed here. Perhaps Katie ought to piggyback a "by the way, the latest maintainer is NNN" header onto such mail it sends to the PTS - which would also allow the PTS to take note immediately). > - when the maintainer changes, we logically need to unsubcribe the previous. > So this must be recorded somewhere. (it's not a subscription like the > others) This would appear to be main implementation challenge, yes, but I'm not sure I agree with your premise. I think I would find it tedious to distinguish between "keywords I subscribe to as maintainer" and "keywords I subscribe to as myself", so I would prefer a solution where this distinction does not exist, even if it means that I have to explicitly unsubscribe from packages I let go of. How about a crude strategy: Whenever the maintainer of the package changes, the new maintainer automatically gets subscribed to the default keywords *under his own address* and *iff he has no subscription at all to the package already*. The old maintainer does not get unsubscribed (the may still want to follow the package) but is sent a notice reminding him to unsubscribe manually if he wants to get rid of the PTS mail. This would have the advantage of simplicity, both for the implementor _and_ for the maintainers. > - in many cases, the maintainer doesn't want the "diff" since there's a > dedicated mailing list for that on alioth ... is it OK if we leave the > problem up to the maintainer to change the set of keyword accepted ? That would be the point, wouldn't it? Off the top of my head, I don't think that version diffs should be a maintainer-default keyword, for the reason you cite. (But I'm not personally affected by the choice either way, so my opinion may not be important). -- Henning Makholm "Larry wants to replicate all the time ... ah, no, all I meant was that he likes to have a bang everywhere." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#363250: general: Custom PAGER gives error on sid, but works on sarge
Scripsit Loïc Minier <[EMAIL PROTECTED]>
> I suggest you use:
> export PAGER="sh -c \"col -b | view -c 'set ft=man nomod nolist
> titlestring=MANPAGE' -\""
>
> which explicitely calls sh -c to handle pipes and quotes in the
> expected way.
Policy does not really specify how to handle $PAGER and its friends,
but I have always assumed that it was OK for a package to do things
like (error checking omitted for clarity):
if( fork() == 0 ) {
char *pager = getenv("PAGER");
if( pager == NULL ) pager = "/usr/bin/pager" ;
execlp(getenv("PAGER"),filename,NULL);
}
wait(NULL);
In that case, PAGER has to be set to just the name of a program, with
no parameters or metacharacters embedded.
> You may also use your own /usr/local/bin/pager with:
> #!/bin/sh
> col -b | view -c 'set ft=man nomod nolist titlestring=MANPAGE' -
> and with PAGER=/usr/local/bin/pager.
I think that is the more robust way for a user to do such things, and
the way that should be documented.
> I am reassigning to man for the man manpage to be clarified with
> respect to the way $PAGER is called.
Is this a man-specific problem? I would say it is a general problem of
policy being vague.
--
Henning Makholm "There were few families that didn't have at least
one hopeful who, from Reading Day on, was the great
hope because of the way he handled his trisyllabics."
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Light Desktop - meta package
Scripsit Don Armstrong <[EMAIL PROTECTED]> > Now, if you're arguing that this may not be appropriate for those who > are afraid of a command line or a program that has more than 50 > command line options, that may be the case... but it definetly gets > rid of the bloat present in other image viewers. Well, people who are unafraid of command lines could theoretically have a "light desktop" consisting of (1) xorg (2) xdm (3) a traditionalist window manager (fvwm, twm, ...) (4) xterm or an xterm replacement (5) tty or curses programs for actually getting work done (emacs/vi, tex, mutt, gnus, ...) (6) xdvi, gv, xpdf for viewing the results (7) large graphical programs when there is work to be done that inherently needs such things: web browser, gimp, xfig ... This is what I use on the computer on my desk. *BUT* ... it is not what people expect from a "desktop" software installation option, even a "light" one. There, I think, the defining characteristic is that one can get work done *without* meeting any command lines in one's day-to-day use of the computer. -- Henning Makholm"Anything you can discover we would be most happy to review." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Use clisp shiped with source or from Debian?
Scripsit Joerg Sommer <[EMAIL PROTECTED]> > I've got it managed to build with the clisp package from Debian. But I > have little problem and saw the Debian package depends on X11. Upstream > do not support other versions than this one shipped with the source and > depending on the clisp package would make more packages need to be > installed to use Xindy -- a simple text processor needs X11. It depends on only a few X11 client libraries with a total installed size of less than 2 megabytes. Including your own clisp will almost certainly lead to a larger waste of space than this. Debian policy (§11.8.1) explicitly requires that packages that _can_ be configured to use X _must_ be. The rationale is that the overhead of having some unused X client libraries on a system is too small to offset the adminstrative hell it would be to maintain versions with and versions without X in parallel. This reasoning also holds if the "version without" is internal to third package. -- Henning Makholm "Det er du nok fandens ene om at mene. For det ligger i Australien!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reforming the NM process
Scripsit "Rudi Cilibrasi" <[EMAIL PROTECTED]> > I wonder if the same could be applied to Debian? (note I am not a > NM/DD yet) I think Debian has really taken off as a new nexus for open > source and would expect if it were possible to make a money > contribution to speed up the NM queue many would be up for it. No [expletive deleted] way. Debian is a volunteer organization. This means that we don't get paid. Lots of the various kinds of work people do for debian are mind-bogglingly boring - one random thing that comes to mind is the work Frank Küster is doing on #218105. Singling out AMing in particular as work worth money would be far out of proportion. -- Henning Makholm "Punctuation, is? fun!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Eiffel.
Scripsit Katipo <[EMAIL PROTECTED]> > What's the general consensus on this? > http://www.eiffel.com/general/news/2006/2006_04_05_pr.html The press release ought to have been clearer. It took me about a dozen clicks from their press release to discover that the unspecified "Open source license" they talk about is actually the GPL. However, GPLing of formerly non-free software is always good. On the other hand, the tarball download located another half-dozen clicks away contains C files with no GPL blurb at the top, and no file named COPYING in the tarball. On the other hand, there's also a SVN download option which I have not tried, but it may be more explicitly released. -- Henning Makholm "Ambiguous cases are defined as those for which the compiler being used finds a legitimate interpretation which is different from that which the user had in mind." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Box does not switch of on halt
Scripsit Andreas Tille <[EMAIL PROTECTED]> > My fallback plan is to stupidly revert the changes and reboot my box. > If it is working again whe found the problem but I would prefer a more > clever method than trial and error. Why is that a _fallback_ plan? It should be the first thing to try. It's the simplest and most direct way to test your hypothesis that that particular package update is the cause of your problem. (And, yes it _it_ the clever way to start, rather than trying to dig into code changes that may and may not be related to the effect you're seeing). -- Henning Makholm "This imposes the restriction on any procedure statement that the kind and type of each actual parameter be compatible with the kind and type of the corresponding formal parameter." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#360340: ITP: libpcl1 -- the Portable Coroutine Library (PCL) implements the low level functionality for coroutines
Scripsit Damián Viano <[EMAIL PROTECTED]> > For a more complete definition of the term coroutine see The Art of > Computer Programming by Donald E. Knuth. I nominate this for the 2006 Most Precise Literature Reference in a Package Description award. -- Henning Makholm "That's okay. I'm hoping to convince the millions of open-minded people like Hrunkner Unnerby." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#358695: ITP: latex-utils -- utilities for LaTeX/xfig
Scripsit Vincent Danjean <[EMAIL PROTECTED]> > Package name : latex-compile > Description : easy compiling of complexe (and simple) LaTeX documents > This package provides several tools that aim to simplify the > compilation of LaTeX documents : I'm marginally unhappy with the word "compile" here. LaTeX programs are not being _compiled_; they are being _executed_ and their output are page descriptions. -- Henning Makholm "The man who catches a meniningococcus is in considerably less danger for his life, even without chemotherapy, than meningococci with the bad luck to catch a man." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Maintainers Guide
Scripsit Anthony DeRobertis <[EMAIL PROTECTED]> > On Tue, Mar 28, 2006 at 03:51:30PM +0200, Henning Makholm wrote: >> Only for some pretty strange values of "worthless". AFAIU the only >> legal effect of the notice requirements you cite is as defined by >> subsection (d): if a compliant notice is present, a defendant is >> excluded from the defense that he did not understand that the work was >> copyrighted. > Well, isn't prohibiting the "I didn't know it is copyrighted" defence > the only legal effect of having the notice nowadays, anyway? Yes. What I mean is that even a notice without a year will make it much easier for the plaintiff to shoot that defence down than it would be in the no-notice-at-all case - even if he has to do a slight bit more than just point to a rule of procedure. -- Henning Makholm "The compile-time type checker for this language has proved to be a valuable filter which traps a significant proportion of programming errors." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Maintainers Guide
Scripsit Anthony DeRobertis <[EMAIL PROTECTED]> > The year really should be included. At least in the US, not having a > year in the notice appears to make the notice worthless. Quoting Title > 17 USC Sec. 401(b): Only for some pretty strange values of "worthless". AFAIU the only legal effect of the notice requirements you cite is as defined by subsection (d): if a compliant notice is present, a defendant is excluded from the defense that he did not understand that the work was copyrighted. A non-compliant notice still leaves the plaintiff in a copyright infringement suit the option of arguing that the defendant did in fact know that the work was subject to copyright. The only difference is that the defendant gets to try to convince the court that he did not recognize the notice as an assertion that copyright exists. -- Henning Makholm"*Vi vil ha wienerbrød!*" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How (not) to write copyright files - take two
Scripsit Henrique de Moraes Holschuh <[EMAIL PROTECTED]> > On Mon, 27 Mar 2006, Henning Makholm wrote: >> > And we ignore any (C) FSF in generated autofoo stuff. >> The generated autofoo stuff does not end up in the .deb, so the >> copyright file needs not describe it. > It often ends up in the source package (depending when you run the > autotools), which we do distribute. But is the Debian copyright file supposed to describe the source package? Not according to my understanding; the source package already includes the various upstream copyright messages in their original positions. -- Henning Makholm"Most of us manage to keep our body count quite low. It's the neighborly way to live." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How (not) to write copyright files - take two
Scripsit Christoph Berg <[EMAIL PROTECTED]> > Re: Raphael Hertzog 2006-03-26 <[EMAIL PROTECTED]> >> Each package with translations has several dozens of copyright holder, >> we don't have to keep that list in the copyright file, do we ? > And we ignore any (C) FSF in generated autofoo stuff. The generated autofoo stuff does not end up in the .deb, so the copyright file needs not describe it. -- Henning Makholm "Vend dig ikke om! Det er et meget ubehageligt syn!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Уникальные семинары!
Scripsit Paul Johnson <[EMAIL PROTECTED]> > On Wednesday 22 March 2006 09:45, Henning Makholm wrote: >> Listmasters have been trying to >> identify the responsible subscriber with no luck > Why not just 500 all posts from sites known to use challenge-response? The challenges are send directly from the idiot site to the From address in the list posting. They do not pass through Debian machines. -- Henning Makholm "This imposes the restriction on any procedure statement that the kind and type of each actual parameter be compatible with the kind and type of the corresponding formal parameter." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Уникальные семинары!
Scripsit Daniel Gimpelevich <[EMAIL PROTECTED]> > Wonderful. I've now received an auto-generated reply from someone on this > list to my previous message asking me to confirm that I really sent it, in > an effort to reduce spam. Would I be wrong in deciding not to make this > confirmation? Also, I believe that it may be useful to inform certain > people as to the list-subscribed address that generated this auto-reply, If your reply comes from [EMAIL PROTECTED] (or another @uol.com.br adress), then the issue is very well known - see last week's thread on debian-project. Listmasters have been trying to identify the responsible subscriber with no luck. It is known that the address is not subscribed directly; somebody unknown is auto-forwarding emails from the list to uol.com.br. > but I won't pretend to be able to identify just whom it would be > appropriate to inform. If the address you have is _not_ at uol.com.br, inform listmaster at lists.debian.org with as much documentation as you can get, in particular full headers. -- Henning Makholm "It will be useful even at this early stage to review briefly the main features of the universe as they are known today." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: one binary package created by different source packages, will the old source package disappear?
Scripsit Frank Küster <[EMAIL PROTECTED]> > - Source package foo creates binary packages libfoo1 and libfoo-dev > - source package foo2 creates binary packages libfoo2 and libfoo2-dev > Since both versions are API-compatible, libfoo2-dev is renamed to > foo-dev, replacing the old binary package from source package foo. Will > the complete source package foo have to disappear, It absolutely _should_, or be reuploaded with new control and rules files to create only libfoo1. Otherwise an attempt to recompile source package foo (say, for a security fix) risks replacing the new libfoo-dev with an older one. Probably a better solution would be to rename libfoo-dev to libfoo1-dev such that if packages that link to libfoo1 reach stable there will still be a way to rebuild them for security updates without adding the new-bug risks of switching to a new implementation of the library. -- Henning Makholm"It's kind of scary. Win a revolution and a bunch of lawyers pop out of the woodwork." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request of expulsion of Zeke the Cat from the Debian Project
Scripsit Wouter Verhelst <[EMAIL PROTECTED]> > Please, people, the mere fact that we have an expulsion procedure should > *not* mean that we have to invoke it twice in a few weeks. Hear, hear! -- Henning Makholm "Nett hier. Aber waren Sie schon mal in Baden-Württemberg?" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GFDL question
Scripsit [EMAIL PROTECTED] (Andrew M.A. Cater) > On Tue, Mar 14, 2006 at 11:30:04AM +0100, Frank Küster wrote: >> Jacobo Tarrio <[EMAIL PROTECTED]> wrote: >> > So it is still not distributable. >> ... in main. > The Debian distribution _is_ main (and only main). The jargon in debian-legal traditionally distringuishes between a) "not distributable": Debian would be infringing copyright (or some other legal principle) if we put it anywhere on our ftp servers. and b) "not free": We may be legally able to distribute it, but we unilaterally _choose_ not to do so (... in main). The above sentence from Jacobo Tarrio seems to use "not distributable" in sense (b). Since this is not in fact -legal, I assume that we all actually agree and that JT is simply unfamiliar with the relevant jargon. -- Henning Makholm"Ligger Öresund stadig i Middelfart?" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: moleinvasion -- Jump'n run game with Tux
Scripsit Steve Kemp <[EMAIL PROTECTED]> > Please consider the following patch: Which, however, will not stop the code from dying horribly if $LANG does not contain an underscore (see /usr/share/locale/locale.alias), or if it contains an underscore that comes so late that there is no room for the LONG_TEXT_FILE string. (It does prevent executing arbitrary code taken from the environment variable _instead_ of dying horribly). -- Henning Makholm"There is a danger that curious users may occasionally unplug their fiber connector and look directly into it to watch the bits go by at 100 Mbps." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Delayed ldconfig execution in postinst step
Scripsit Ralf Wildenhues <[EMAIL PROTECTED]> > If someone happens to install sonamed libfoo.so only but rely on > ldconfig to create the libfoo.so.N symlink > Ralf (no I don't know whether Debian policy already forbids this setup) It takes about 20 seconds to find out that Debian policy does forbid such a packaging - see the last paragraph before section 8.1.1. -- Henning Makholm "And here we could talk about the Plato's Cave thing for a while---the Veg-O-Matic of metaphors---it slices! it dices!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Private.
Scripsit [EMAIL PROTECTED] > you are not francois massaquoi's son Indeed I am not. I see nothing can be hidden from you. Rather a brilliant display of observation and deduction, actually. I don't suppose we could interest you in a job at the Yard? -- Henning Makholm "I always thought being *real* sad would be *cooler* than acting *fake* sad, but it's not. It's not cool at *all*." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#355848: ITP: pcmanfm -- GPL'd lightweight file manager for X Window
Scripsit Tetralet <[EMAIL PROTECTED]> > Description : GPL'd lightweight file manager for X Window The license does not belong in the short description. Users may generally assume that software they find in main is free - only a small fraction of users are interested in precisely which free license a package has, and they can just look in the copyright file (which is available from p.d.o. when p.d.o. works fully). -- Henning Makholm "Jeg forstår mig på at anvende sådanne midler på folks legemer, at jeg kan varme eller afkøle dem, som jeg vil, og få dem til at kaste op, hvis det er det, jeg vil, eller give afføring og meget andet af den slags." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Box does not switch of on halt
Scripsit Andreas Tille <[EMAIL PROTECTED]> > So the question is: what package might be responsible that > entered testing for about three weeks and how can I get my > boxes working as expected again. Sysvinit migrated to testing on February 21, and was responsible for a similar error (#252547) for me a couple of years ago. However, the current sysvinit has no trouble shutting down my sid box. -- Henning Makholm "However, the fact that the utterance by Epimenides of that false sentence could imply the existence of some Cretan who is not a liar is rather unsettling." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New packages.debian.org
Scripsit Robert Lemmen <[EMAIL PROTECTED]> > really cool and thanks to schlund and partner, but the links to the > changelogs and the copyright file at the bottom of each packages page > don't work. probbaly just something really minor... Didn't such things use to be static and cronjob-maintained? Chances are good that they will be there come morning. -- Henning Makholm "It was intended to compile from some approximation to the M-notation, but the M-notation was never fully defined, because representing LISP functions by LISP lists became the dominant programming language when the interpreter later became available." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New packages.debian.org
Scripsit Wolfgang Jeltsch <[EMAIL PROTECTED]> > Am Montag, 6. März 2006 18:29 schrieb Martin Schulze: >> It is a DualCore Opteron and only runs this service for Debian >> users and developers. > What does it mean that the machine runs this service only for Debian > users and developers? It probably means that the machine is dedicated to being p.d.o and runs no other services. > How can the machine make sure that the person which accesses the > machine is either a user or a developer of Debian? It is probably thought that the fact that somebody wishes to look up a package on p.d.o. implicitly implies that this somebody must be Debian user or developer. -- Henning Makholm "The man who catches a meniningococcus is in considerably less danger for his life, even without chemotherapy, than meningococci with the bad luck to catch a man." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 4GB address space
Scripsit "Mad Props" <[EMAIL PROTECTED]> > So what I need to know is whether those modifications are rather > comprehensive/complicated or not and whether it is feasible to get finished > within 4 month... Debian-devel really is not the most natural place to ask such a questions. It does not appear to be directly relevant to the development of Debian, and I'd expect most people here haven't ever even looked at kernel source. -- Henning Makholm "Y'know, I don't want to seem like one of those hackneyed Jews that you see in heartwarming movies. But at times like this, all I can say is 'Oy, gevalt!'" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#354831: ITP: bfc -- Brainfuck compiler
Scripsit Panu Kalliokoski <[EMAIL PROTECTED]> > I only saw the last one of the flame wars you mention, and it didn't > even cross my mind that this ITP would gather similar attention. For the record, I don't care any which way about the name [1]; my reaction would have been the same if it was called "brownfox". I was reacting to the (to me) evident uselessness of the proposed package. [1] Except that I think it grossly overstates the strangeness of what is just a straightforward if rather verbose encoding of a well-known computation model, but that is not the packager's fault. -- Henning Makholm "Apologies if I am repeating obvious conclusions. My only gateway onto the Net is very expensive, and I miss many important postings... Please write to me and tell me what you think. I don't get much mail." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#354831: ITP: bfc -- Brainfuck compiler
Scripsit Andrea Bolognani <[EMAIL PROTECTED]> > BrainFuck is not just a proof-of-concept or a toy language. You can write > actual programs using it. > Seriously, there is even a complete textual adventure written in BrainFuck: > http://jonripley.com/i-fiction/games/LostKingdomBF.html Do you claim that this is _not_ just a proof-of-concept item? -- Henning Makholm "Man vælger jo selv sine forbilleder." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#354831: ITP: bfc -- Brainfuck compiler
Scripsit "Tim Olsen" <[EMAIL PROTECTED]> > A programming language with the minimum number of instructions > necessary to be turing-complete and have I/O may be more than a toy > for some people. Perhaps. But (1) brainfuck isn't that; it has twice as many basic instructions as combinatory lambda calculus, and (2) the use of toy languages generally do not depend on having a compiler for them. -- Henning Makholm "In my opinion, this child don't need to have his head shrunk at all." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#354831: ITP: bfc -- Brainfuck compiler
Scripsit The Fungi <[EMAIL PROTECTED]> > On Wed, Mar 01, 2006 at 12:59:12PM -0600, Ron Johnson wrote: >> Besides that? > It is essentially a toy, or a demonstration tool... depends on your > point of view. Why should we use mirror bandwidth on either? > BrainFuck, from what I can tell, has been around for years and is a > Turing-complete programming language consisting of only eight > commands: Basically just a horrible way to write down counter machines. Who would use that for anything? -- Henning Makholm "We will discuss your youth another time." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#354831: ITP: bfc -- Brainfuck compiler
Scripsit Panu Kalliokoski <[EMAIL PROTECTED]> > * License : BSD-like > Description : Brainfuck compiler What is this useful for? -- Henning Makholm "Ambiguous cases are defined as those for which the compiler being used finds a legitimate interpretation which is different from that which the user had in mind." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is there some guideline saying that native packages should be avoided?
Scripsit Hendrik Sattler <[EMAIL PROTECTED]> > Am Dienstag, 28. Februar 2006 21:26 schrieb Henning Makholm: >> Further, providing an .orig.tar.gz without the debian/ directory helps >> prevent confusion for users on non-Debian systems. > On the other side, some user may find it very useful. Then the user can easily download the .diff.gz too. -- Henning Makholm "Punctuation, is? fun!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is there some guideline saying that native packages should be avoided?
Scripsit Panu Kalliokoski <[EMAIL PROTECTED]> > It was pointed to me that packages should be preferably non-native, > even if no source release without the debian/ subdir has ever > existed. > I would like to ask whether there really is such a guideline, and if so, > which are the technical / political reasons that lead to it. In addition do the answers Lars gave, I think there is a major consideration to make for people who do _not_ use Debian but are still interested in your software. Because of the sheer size of Debian, it is not uncommon to use our source archive as a generic place to find free software sources - sort of a meta-CxAN. For this kind of users, a non-native package is a clear signal that the software is supposed to be generally useful on Linux and probably also other unices. Conversely, a Debian-native package may make people assume that you don't care a bit whether it compiles or runs on other OSes, and that you would be reluctant to accept patches for portability beyond Debian, or patches for easier installation in $HOME for users who are not root on their system, and so on. Further, providing an .orig.tar.gz without the debian/ directory helps prevent confusion for users on non-Debian systems. And if you do provide such a debian/-less tarball for nondebian users then of course you SHOULD use that as pristine source in the Debian package too. And last: if someday _you_ decide that you like, say, Ubuntu better than Debian and start releasing your master distribution there instead of here, confusion will result if the Ubuntu packaging in debian/ cannot be easily separated from the upstream source that a new Debian maintainer might want to package. It is easier to just do it right from the beginning. -- Henning Makholm "Jeg mener, at der eksisterer et hemmeligt selskab med forgreninger i hele verden, som arbejder i det skjulte for at udsprede det rygte at der eksisterer en verdensomspændende sammensværgelse." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Scripsit Tom Rauchenwald <[EMAIL PROTECTED]> > I am not a DD, so maybe my opinion is idiotic. But: the thing is free, > it allows people to use non-free drivers, but it is entirerly up to the > user to use those drivers. I don't know, but for me this discussion is > pointless. Does ndiswrapper require non-free packages? no. Well, that's the point of contention. I think it is not meaningful to speak about whether the software, viewed as a bag of bits that live in a vacuum, "requires" this or that other software. The question only makes sense when we put it in a context and ask: Does ndiswrapper require a non-free software *to do its thing*? Unfortunately the answer depends on what one takes "ndiswrapper's thing" to be. I think the schism in the current thread is based mostly on differing intitial assumptions about how one views the purpose of ndiswrapper. Case 1: Ndiswrapper is for users who have hardware XYZ; it promises to make this hardware useful with Linux. It cannot keep this promise without also having a driver, and the only existing driver for XYZ is non-free. From this viewpoint it is clear that ndiswrapper should be in contrib. Case 2: Ndiswrapper is for users who already have some driver software written to the NDIS specification, never mind where they got it, and want to run this driver. From this point of view, ndiswrapper is akin to a programming language implementation, or a shared library - it can be in main independently of the freedom of any programs that use it. Thus from this perspective it is clear that ndiswrapper should be in main. The tragedy is that both viewpoints - "I want to use this hardware" and "I want to run this driver" - are possible and legitimate and the package descriptions does not clearly invalidate one of them, yet they lead to incompatible conclusions about where the package should be filed. > if the user decides to use non-free drivers, then it's his choice, > not debian's, so what. The point of the distinction between main and contrib is to support the user in his choice. We want that if a user finds package that promises some functionality in 'main', then he can ideed get that functionality without resorting to software outside main. That is why the differing views of what functionality ndiswrapper promises is important. Personally I favor using a test somebody invented an earlier time we discussed a similar problem: To determine whether A "requires" B for the purpose of the social contract, assume hypothetically that B was free and packaged, and then ask whether ordinary packaging practice would lead to A a declaring a "Depends:" relationship on B in that situation. This test would allow us to move the question into the technical realm. I think that according to this test, we would conclude that ndiswrapper does not "require" the driver it wraps. If we had a handful of prackages that provided free NDIS drivers, the driver packages would depend on ndiswrapper, not the other way around. We don't let libfoo depend on , or let ruby depend on , even though we _could_ do this with virtual packages if we thought it would be useful. This is just parallel to the fact that we can have a library in main without having any clients for the library in main. An example is libc5 - it exists in sarge *only* to support old applications, presumably non-free and certainly not in main themselves. Yet I have not heard anybody suggest that it ought to have been in contrib for that reason. -- Henning Makholm "... a specialist in the breakaway oxidation phenomena of certain nuclear reactors." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Honesty in Debian (was Re: Amendment to GR on GFDL, and the changes to the Social Contract
Scripsit Gunnar Wolf <[EMAIL PROTECTED]> > Xavier Roche dijo [Mon, Feb 13, 2006 at 10:55:57AM +0100]: >> So a cat is a software, or a hardware ? Do I have to provide the sources >> (the DNA full sequence) if I want to give a kitten to someone, following >> the "free" spirit ? :p > A cat is not licensed under a viral license ;-) And, more important, > is not covered by copyright law Even more important: Debian does not distribute kittens at all. -- Henning Makholm "... and that Greek, Thucydides" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Library interface version question
Scripsit Shachar Shemesh <[EMAIL PROTECTED]> > Henning Makholm wrote: >>You are supposed to write an appropriate shlibs file, as described in >>policy �8.6. Have you done so? > My file is currently automatically generated by dh_shlibdeps, and says > "libargtable2 0 libargtable2-0". No it isn't. dh_shlibdeps is jus a wrapper around dkpg-shlibdeps, which does not generate shlibs files. It _reads_ shlibs files and collects substvars for use in your package's Depends line. Please do read the documentation. > I realize that I should place any version restrictions there, if I > want them. The question is whether I should just state the version > at which the interface advance there, or whether I should do some > other version tricks? You are the maintainer; it is your job to know which versions and packages it is appropriate for freshly compiled client programs to depend on. > In a nutshell - because then the information regarding which backwards > compatible interface to use is lost. You seem to be misunderstanding the purpose of /usr/lib symlinks. See Steve Langasek's answer. -- Henning Makholm "Wir kommen nun ans Ziel unserer Ausführungen." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Recommending an image viewer
I am packaging xcftools (ITP #349424) which will include a convenience wrapper script that displays an xcf file by converting it to either ppm or png and using an external image viewer found throuh printcap on the converted file. Since the wrapper will not work unless an appropriate external viewer cannot be found, I think I had better declare a Recommends against one. However, there appears to be a couple dozen packages that promise in their description to provide a suitable image viewer, and of course there is no virtual package for this functionality. Does anybody have a better idea than trying (in vain) to keep myself informed about the supply of image viewers in unstable and adjust the dependencies appropriately? Perhaps the recommendation could be omitted entirely; people who want to view xcf images will probably already have a way to view other images nevertheless. But that does not seem quite the Debian way of doing things. (On a related note, will I lose my position in the NEW queue by uploading improved versions of the package before it is accepted?) -- Henning Makholm"There is a danger that curious users may occasionally unplug their fiber connector and look directly into it to watch the bits go by at 100 Mbps." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Library interface version question
Scripsit Shachar Shemesh <[EMAIL PROTECTED]> > First, if I understand correctly, programs linked against this new > library (which should still be called "libargtable2-0") should have a > specific ">=" version in their dependencies. This does not currently > happen. You are supposed to write an appropriate shlibs file, as described in policy §8.6. Have you done so? > The second is that, again, if I understand correctly, a link should have > been created from libargtable2.so.0.1 to libargtable2.so.0.1.1. Why? This does not happen with the libraries with three-part version numbers that I have on my system. -- Henning Makholm"I, madam, am the Archchancellor! And I happen to run this University!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#352535: ITP: gitmail -- Very simple graphical mail user agent for sending mail (GTK)
Scripsit Ron Johnson <[EMAIL PROTECTED]> >>From http://gitmail.sourceforge.net/ : > This piece of software allows to send e-mails to any person > over the net with a fake email address, and also a fake name. Is this a feature, even? I should think all regular MUAs in Debian happily allow the user to put anything he wants in the From line -- they had better, as a MUA running on a NATted box with no global FQDN of its own has no way of knowing _any_ guaranteed-to-work sender address. There does not appear to be anything one can do with this software that is not straightforwardly possible with an off-the-shelf MUA that can be configured to send to a smarthost rather than to a local MTA. -- Henning Makholm "En tapper tinsoldat. En dame i spagat. Du er en lykkelig mand ..." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Automatic testing of .deb's
Scripsit Adrian von Bidder <[EMAIL PROTECTED]> > Ian: I add my voice to what you already perceive: these tests would be > welcome, and I'd probably accept them to my few packages. A very short > (one screenfull or so) HOWTO/README about how the whole system works linked > from the bug would be helpful, because I don't have the time to read up on > it now, but will want to when you file the first bug on my pkgs, FWIW, I agree with both of these points. -- Henning Makholm "This imposes the restriction on any procedure statement that the kind and type of each actual parameter be compatible with the kind and type of the corresponding formal parameter." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEWS.Debian abuse
Scripsit Kenneth Pronovici <[EMAIL PROTECTED]> > Ok, after a quick look through the existing NEWS.Debian files on my box, > I concede that this is the way most developers use the file. It's not a question of "the way most developers use the file". It's a question of what the file is _for_. NEWS.Debian is for information that should be shown to the administrator at upgrade file, because he needs to consider it and perhaps act on it to keep his system functional. Maintainer changes are simply not in that category. And the two notes in question should be retroactively removed from the NEWS file, such that users upgrading from sarge to etch won't be needlessly bothered. > I still maintain that the information provided was useful, Whether it is useful is the wrong question. Lots of things are "useful" but still not relevant to spam the sysadmin with during upgrades. -- Henning Makholm "Apologies if I am repeating obvious conclusions. My only gateway onto the Net is very expensive, and I miss many important postings... Please write to me and tell me what you think. I don't get much mail." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
Scripsit Manoj Srivastava <[EMAIL PROTECTED]> > If people find Perl too hard (feh), and python too ugly, > regressive syntactically, and counter intuitive, and want ruby, or > scheme, or haskell, what then? Unless there is a requirement that maintainer scripts have to be shipped in an ascii-based format (and TTBOMK there is not), Scheme and Haskell should be fine even now. Build-depend on an appropriate compiler, compile the script at build time, and ship the binary. The problem arises only when people want to write infrastructure scripts in languages that need an interpreter to run. -- Henning Makholm "... popping pussies into pies Wouldn't do in my shop just the thought of it's enough to make you sick and I'm telling you them pussy cats is quick ..." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#349424: ITP: xcftools -- command-line tools for extracting data for XCF files
Scripsit Daniel Kobras <[EMAIL PROTECTED]> > Imagemagick in general can handle multi-layered images just fine. I'm > not sure whether this is true for its xcf module already, but the > necessary framework is certainly there. So if you don't want to keep > maintaining a separate utility, merging it with the code in imagemagick > might be an option for you. At the moment I think it is easier for me to maintain a separate utility that does one thing but does it well, than to integrate the functionality I need into imagemagick sufficiently seamlessly to satisfy my technical pride. But thaks for pointing out that imagemagick does have some support for layers. This wasn't apparent to me the first 20 times I read the manpage :-) (In related news, an xcftools package is now in the NEW queue). -- Henning Makholm "... not one has been remembered from the time when the author studied freshman physics. Quite the contrary: he merely remembers that such and such is true, and to explain it he invents a demonstration at the moment it is needed." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#349424: ITP: xcftools -- command-line tools for extracting data for XCF files
Package: wnpp Severity: wishlist Owner: Henning Makholm <[EMAIL PROTECTED]> * Package name: xcftools Version : 0.5 Upstream Author : Henning Makholm <[EMAIL PROTECTED]> * URL : http://henning.makholm.net/software * License : GPLv2 Description : command-line tools for extracting data for XCF files This is a set of fast command-line tools for extracting information from the Gimp's native image file format XCF. The tools are designed to allow efficient use of layered XCF files as sources in a build system that use 'make' and similar tools to manage automatic processing of the graphics. These tools work independently of the Gimp engine and do not require the Gimp to even be installed. "xcf2pnm" converts XCF file to ppm, pgm or pbm format, flattening layers if necessary. If the image contains transparency, an alpha map can be written to a separate file, or a background color can be specified on the command line. The tool can either flatten the XCF file as given, or extract specific layers named on the command line. "xcfinfo" lists information about layers in an XCF file. ... Note that I am the upstream author myself. I wrote this tool because I need it myself and there seems to be nothing comparable available on the net. Then I put some extra work into polishing it up for general consumption, because it seemed to be the Right Thing to do - I cannot be the only one who have whished for such a tool to exist. There is a "xcftopnm" binary in gimp-perl, but it is very slow, starting the Gimp engine to do the work. "Convert" from imagemagick supposedly also understands XCF files, but not the ones I work with, and it would probably be overkill to try to extend its command-line interface to know about layers. Nonetheless, packaging one's own software does smell slightly of "vanity package" -- I'd appreciate comments. (IAADD, so I don't desperately _need_ to package this, but Debian is still the most convenient channel for making this widely available). -- Henning Makholm"Amanda, I'm a mad scientist! Testing crazy things on myself and those who are close to me is my job. It's what I do!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Derived distributions and the Maintainer: field
Scripsit Nathanael Nerode <[EMAIL PROTECTED]> > If they are also compiled with a toolchain unchanged from Debian, > the binaries can legitimately have the same Maintainer: field as in > Debian, because they are essentially the same package. > If not, the binary packages should have different Maintainer: > fields, unless the maintainer agrees to have his name on it. You seem to require a standard of attribution in the Maintainer field that Debian does not itself follow in our default procedures. To wit: NMUs _within_ Debian keep the Maintainer field unchanged. -- Henning Makholm "That's okay. I'm hoping to convince the millions of open-minded people like Hrunkner Unnerby." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libecw
Scripsit Miriam Ruiz <[EMAIL PROTECTED]> > I'm not sure if it's license ( > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293346 ) can be considered > free enough to be in main: [...] > ii) When modifications to the Software are released under this license, a > non-exclusive royalty-free right is granted to the initial > developer of the Software to distribute your modification in future versions > of the Software provided such versions remain available under > these terms in addition to any other license(s) of the initial developer. This is controversial at best. > iii) You are not permitted to change the ECW file format. This, however, directly kills DFSG-freedom as well as GPL compatibility. If the library is actually linked with GPL code, as the authors seem to expect, the entire think becomes legally undistributable even in non-free. -- Henning Makholm "Hi! I'm an Ellen Jamesian. Do you know what an Ellen Jamesian is?" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Aptitude question
Scripsit Miles Bader <[EMAIL PROTECTED]> > Though I love the aptitude interface and functionality, I've noticed > that on my home machine (not so fast, but not too bad with average > software), normal aptitude operation has been getting more and more > slothlike in recent times, to the point where I often just hit ^C to > exit after upgrading, instead of waiting ages for all the "updating > random stuff #11, very slowly... 2%" stuff to finish before I can > type "q" -- Henning Makholm "Logic is a system for talking about propositions that can be true or false, or at least enjoy properties that are generalized versions of truth and falsehood." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to Increase Contributions from Volunteers
Scripsit Manoj Srivastava <[EMAIL PROTECTED]> > People who do not want to undergo that process can just help > out current developers, fix bugs, send patches, etc. Why are you then disagreeing with Andreas when he said that we should make the possibility of doing this more visible? > I am merely vocing objections to lowering the bar for people who > are responsible for Debian packages, and can thus run code as root > on my machine. How on earth do you manage to interpret "promote the easy entry points to contributing to debian more prominently" as "lowering the bar"? -- Henning Makholm "Wir kommen nun ans Ziel unserer Ausführungen." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: something strange with rsh/ssh + bash/tcsh is happening. Please advise
Scripsit Yaroslav Halchenko <[EMAIL PROTECTED]> >-c string If the -c option is present, then commands are read > from string. If there are arguments after the > string, they are assigned to the positional > parameters, starting with $0. > so - sldkjf (if I read English correctly) should be assigned to $0 > (yikes again). Lets try: >> cat zzz.sh > #!/bin/bash > echo "#0=$0 #1=$1" > *> /bin/bash -c /home/yoh/zzz.sh sldkjf sdf sdf > #0=/home/yoh/zzz.sh #1= > so what the hell is right in this situation Bash behaves as the manual page says. The string is '/home/yoh/zzz.sh', and every $1 in that string did indeed get expanded to sdf, after which the command reads '/home/yoh/zzz.sh'. On the other hand: $ bash -c 'echo 0=$0 1=$1' sldkjf sdf sdf 0=sldkjf 1=sdf $ bash -c 'source zzz.sh' sldkjf sdf sdf #0=sldkjf #1=sdf $ The argument to the -c option is being interpreted as _a shell script_ itself. -- Henning Makholm "It will be useful even at this early stage to review briefly the main features of the universe as they are known today." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: not getting CCs from the bugs I reported
Scripsit Josselin Mouette <[EMAIL PROTECTED]> > Le mercredi 28 décembre 2005 à 23:49 -0600, Adam Heath a écrit : >> You'll only get mails if the sender sends to ###-submitter. >> Mail sent to just ### is not forwarded, and only stored. >> This is not a bug in the software, but in the person sending the mail. > I consider this a bug in the software. It's awkward not to receive some > communications on a bug you submitted. I think the theory is that a non-technical user who reports a bug might not be interested in reading a lot of mail where scary geeks throw incomprehensible jargon at each other while they figure out how to fix the problem. On the other hand, I do not think that most of the bugs in our BTS are reported by non-technical users. -- Henning Makholm "This imposes the restriction on any procedure statement that the kind and type of each actual parameter be compatible with the kind and type of the corresponding formal parameter." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
Scripsit Lars Wirzenius <[EMAIL PROTECTED]> > to, 2005-12-22 kello 10:20 +, Jon Dowland kirjoitti: >> On Sun, Dec 18, 2005 at 09:29:24PM +0200, Lars Wirzenius wrote: >> > su, 2005-12-18 kello 20:17 +0100, Norbert Tretkowski kirjoitti: >> > > We already have two editors in the base system, nvi and nano. >> > Yes, that being the bloat I was referring to. >> I think there should be at least one non-modal editor in base. > Behold the awesome non-modality of nano. Yes; therefore it is not bloat to have nvi and nano both in base; they satisfy different needs (having a vi because we're unix resp. having a non-modal editor for the rest of us). -- Henning Makholm"There is a danger that curious users may occasionally unplug their fiber connector and look directly into it to watch the bits go by at 100 Mbps." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
Scripsit Gabor Gombas <[EMAIL PROTECTED]> > But this is gnome-terminal, and _not_ xterm. xterm used a white > default background since prehistoric times, so when vim detects xterm, > it uses colors that look good with the traditional xterm colors. If it > detects the Linux console, it uses colors that look good on the console. > Now, if your terminal pretends to be xterm but does not use the color > scheme of xterm, how should vim know that? I would suggest that the right solution is that every program that sets foreground colors should also, as its default behavior, make sure to set a background color that goes well with the chosen foreground. The "if you pick one color, pick them all" maxim of web design works for non-web user interfaces, too. Even with a genuine xterm users can and do set their personal color scheme preferences in X resources. But if you're going to override the foreground color you might as well also override the background one. Of course any good program should offer per-user customization of its color scheme, and offer "default" as an option for background color, in case the user's preferred background is not among the ones that can be set with ordinary "setb/setab" strings. (Of course², nobody said that this will be easy to do for any particular program). -- Henning Makholm"Unmetered water, dear. Run it deep." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt PARALLELISM
Scripsit Olaf van der Spek <[EMAIL PROTECTED]> > On 12/13/05, Henning Makholm <[EMAIL PROTECTED]> wrote: >> Alternatively each user can spread his load over all three servers; >> his download now takes 5 minutes, and each server _still_ sees >> 600*5 = 3000 active connections at any time. Thus _all_ users get > That's not true. Suppose you've only got 3 users. If each user > connects to one (different) mirror, he gets 1/1 of that mirror's > bandwidth. No he won't, because the 14 users who started in the previous 14 minutes have not finished downloading yet. He can get 1/15 of the mirror's bandwidth. > If each user connects to each mirror, he only gets 1/3 of that > mirror's bandwidth. No. There will now be three new users connecting to the server that minute, but because all of the _previous_ users have finished faster, only the users from the previous *four* minutes will still be downloading. So each of the three new users get 1/15 of the server capacity (now 15 is 3 users from each of the previous 4 minutes plus three new users), but now each of them gets 1/15 of _each_ server's capacity. -- Henning Makholm "We're trying to get it into the parts per billion range, but no luck still." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt PARALLELISM
Scripsit Henrique de Moraes Holschuh <[EMAIL PROTECTED]> > THis is not something that would bother anyone if it is a single user... but > if you have 10k users doing that, often close enough in time, well, things > should get MUCH worse as far as I can see. If they are doing this at random > times in the day, OTOH, it would not be that bad, I guess. That's what I mean. People don't synchronize their updates - certainly I don't synchronize with anybody, and I don't know of any mechanism that I *could* use to sync with anybody if I wanted to. Assume a situation where mirror bandwidth is the limiting factor, and imagine a world with 3 mirrors. Say that during a certain time of the day 600 users each minute start to download updated x.org packages. Either they can do their download sequentially, choosing a random server; then their download will be finished in 15 minutes, and each server has a more-or-less constant 600/3*15 = 3000 connections active. Alternatively each user can spread his load over all three servers; his download now takes 5 minutes, and each server _still_ sees 600*5 = 3000 active connections at any time. Thus _all_ users get it faster by parallelizing. We get the same result if only some users parallelize - the mirrors do not see a diffence in load, the smart users get things faster, and the sequentially downloading users get it no slower than they would have otherwise. The calculation becomes more murky if there is backbone congestion which hits more than one mirror _and_ more than one end user. Then he who opens more connections at a time (whether to one server or several) will probably get an advantage at other users' expense. But I don't think that backbone congestion is such a universal condition that it should necessarily be the only scenario for making moral decisions about what apt should be _able_ to do. > Whether MY [a single individual] increased download speed is worth the extra > load on the mirror network, and whether it WOULD increase the load on the > mirror network is what we are asking here. Hm, you are not even asking whether the mirror load would go up? What _are_ you asking, then? > (and for the people who can't read whole threads, my position is that we > should never decrease the experience of a group of people to increase the > experience of an individual). I am questioning your assumption that doing parallel downloads will necessarily decrease the experience of a group of people at all. -- Henning Makholm"Vi skal nok ikke begynde at undervise hinanden i den store regnekunst her, men jeg vil foreslå, at vi fra Kulturministeriets side sørger for at fremsende tallene og også give en beskrivelse af, hvordan man læser tallene. Tak for i dag!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt PARALLELISM
Scripsit Henrique de Moraes Holschuh <[EMAIL PROTECTED]> > 1. We care about a large lot of people a lot more than we care for an >individual's downloading speed > 2. Thus we try to keep the mirror load down, and downloading hundreds of >megabytes using multiple connections to multiple sources of the same file >is heavily fronwed upon. Of course, trying to download the _same_ file from several different servers simultaneously would be very wasteful. However it seems to be not what the proposal in this thread is about. As far as I read the proposal, it is about downloading _different_ files from different mirrors - if you have 25 packages to get for your 'apt-get update' operation, download 5 packages from each of 5 different servers, with one connection to each server active at a time. While I cannot see any very common situation where such parallellism would be an advantage, it is not clear that it would increase the load of any or all servers. At least, I cannot see that there would be any ill effects of a hypothetical pseudo-parallel implementation that downloads 5 packages from each of the 5 servers, but sequentially such that only a single connection to a single server is active. And the difference from _that_ to an actual parallel implementation is just to shift the connections each server experiences a bit in time - the number of KB served by each server stays constant. Is your point that a server prefers to push bytes through the connection at a constant rate, and starts wasting resources if the available bandwidth fluctuates because the last-mile ADSL has to be shared with a shifting number of parallel downloads from other servers? But when the bottleneck is closest to the client, enabling parallel downloads would not make much sense anyway. (Of course, Goswin has a valid point that some people have their sources.list deliberately written with a remote, undesirable, server at the end as a _fallback_ option. Therefore parallelism should at best be an _option_, not something that apt starts doing unbidden). > I won't claim this is what happens in Internet-paradise countries, but here > there are two things that affect download speed the most after you get a > last-mile link that is not too slow (say, 384kbit/s or more): I have 768 kb/s at home, and my apt updates through that pipe operate close to its peak capacity. But they are at least one order of magnitude slower than from my desk at work (which is just two or three 100+ Mb/s hops away from the national research backbone). Same mirror in both cases. >From that experience, a last-mile link in the 1 Mb/s range would still seem to be the limiting factor - and therefore people at the end of such links would have little use for parallelism in the first place. -- Henning Makholm "What has it got in its pocketses?" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#341425: ITP: libmail-date-perl -- RFC2822 compliant date-time conversion
Scripsit Stephen Quinney <[EMAIL PROTECTED]> > The well-known RFC822 has been obsoleted by RFC2822 since April 2001 > and the standard format of expression for date-time was updated in > the RFC2822. How does this sentence belong in the package description? If there is a lot of software out there which is generating RFC822 dates (with two-digit years or idiosyncratic timezones) it has been a while since it has come to my attention. > This lightweight module provides a method for converting > the time in seconds since the epoch along with the local timezone > into the correctly formatted RFC2822 representation. Is this worth a package of its own? It's not as if generating RFC2822 dates in perl is hard - there are twoliners easily googleable. -- Henning Makholm"You are in a little twisting maze of passages, all different" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Scripsit Florian Weimer <[EMAIL PROTECTED]> > This means that it's dangerous to commit yourself to the contents of a > document, using a digital signature, unless you fully understand the > meaning of each byte in the document. So how do the MD5 sums of .debs end up in a Packages file signed with the archive key? Do the ftpmasters go over each file with a disassembler, fully understanding the meaning of each byte in the .deb? >>> (Note the "rub.de" part of the URL. A clear warning sign.) >> The nice thing about ad hominem arguments is that you can make them >> without ever having to argue the merits of your case. > *shrug* The computer security folks at that university started > spreading FUD about various security systems, mainly rehashing the > work of others. They seem to be in it mostly for the publicity. More ad hominem arguing. -- Henning Makholm "Jeg mener, at der eksisterer et hemmeligt selskab med forgreninger i hele verden, som arbejder i det skjulte for at udsprede det rygte at der eksisterer en verdensomspændende sammensværgelse." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Scripsit Florian Weimer <[EMAIL PROTECTED]> > * Jochen Voss: >> I found the example at http://www.cits.rub.de/MD5Collisions/ quite >> impressive. They have two different valid PostScript files with >> identical MD5 sums. I don't know how much computing time they used, >> though. They claim a few hours: | Based on [WY05] and the analysis described in [Da], we implemented | an attack to find random collisions for the MD5 compression | function. It took just a few hours on a customary PC. > None, many of these examples were created before the collision > generation tools were generally available. They did create or use a collision, as anyone can verify simply by downloading the files. Whether or not they used a generally available tool is not important to the fact that a collision was actually generated. > The "exploit" uses some properties of Postscript files which make > them not very desirable for storing electronic documents which > cannot be altered. There is absolutely no reason to put the word exploit in scare quotes here. You might want to notice that the "properties" you apparently think invalidate the example are also shared by many common formats for software. An ELF binary can easily be crafted to contain a blob of initialized data whose contents are only used for checking whether to enable some malicious machine code that is always present - and this would not be easily detectable at all. The only thing that would seem to make it less than straightforward to craft a similar attack consisting of two different .deb files with the same MD5 sum of which one behaves maliciously, is the need to trick the CRC-32 in the gzip trailer for data.tar.gz simultaneously with tricking MD5. But a CRC-32 is, to put it mildly, not much of a defense against a determined attacker! All it takes to beat *that* is finding at most 33 different MD5 single-block collisions in sequence; it is then a matter of extremely simple linear algebra find a nontrivial combination of them that cancel out each other's effect on the CRC. Note that the gzip compression format allows blocks of compressed data to specify use of the "no compression" algorithm, so injecting your collisions in a gzipped data stream is trivial, too. > (Note the "rub.de" part of the URL. A clear warning sign.) The nice thing about ad hominem arguments is that you can make them without ever having to argue the merits of your case. -- Henning Makholm "I always thought being *real* sad would be *cooler* than acting *fake* sad, but it's not. It's not cool at *all*." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Scripsit Anthony Towns > On Mon, Nov 28, 2005 at 10:15:34PM +0100, Henning Makholm wrote: >> I would expect something like >> $ dsum -a sha1 COPYING; sha1sum COPYING >> s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI COPYING > sha1sum already exists; and isn't that long. Do you mean sha256? Feh. Yes, I meant SHA-256. Sorry for the confusion. -- Henning Makholm "What has it got in its pocketses?" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Scripsit Peter Samuelson <[EMAIL PROTECTED]> > For large files, getting a cryptographic checksum is more about reading > blocks off the disk than about CPU time. So it wouldn't be completely > ridiculous to allow sha-1 to remain ambiguous with competing 160-bit > hashes, and have --check check for all of them (reading the file only > once). That sounds cryptographically unsafe. It would mean that a practical preimage attack against _any_ of the supported hashes would break the entire system. That's not the kind of algorithm agility we need. > I still think two-byte prefixes for non-md5-non-sha1 hashes makes some > sense, like s- for sha-256. That is much better. But let's use "s." as a prefix and do a [/+] -> [_-] substitution on the following base64 data. The dot in the prefix will prevent the prefix from being mistaken as part of a slightly larger non-tagged hash value. >> $ dsum -a sha1 foo; sha1sum foo >> f572d396fae9206628714fb2ce00f72e94f2258f foo >> f572d396fae9206628714fb2ce00f72e94f2258f foo There appears to be to few characters of hash there, at least unless it is a cosmically weird coincidence that it base64 encodes to all hex digits. :-) I would expect something like $ dsum -a sha1 COPYING; sha1sum COPYING s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI COPYING s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI COPYING $ dsum -a sha1 -a md5 COPYING s.w4runjyMTV1ZT_VIob4FRTAjAW1ihpMfZRLbIV7B_UI COPYING 4325afd396febcb659c36b49533135d4 COPYING $ echo moooo | sha1sum - s.-tUTs04N4IxBOtWpdoIXt1b0qgHIgNm9IC_OgYjm-mU - -- Henning Makholm"But I am a Sunni Muslim," the bemused Arab said. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340934: lintian check for unneeded/transitive shlibs dependencies
Scripsit Peter Samuelson > [Henning Makholm] > > I have written a Lintian check which attempts to flag instances of > > this problem. It looks for ELF objects that flag shared libraries in > > the default search path as NEEDED without actually importing symbols > > that the library exports. > This produces a lot of noise in a case where a package has multiple > binaries or libraries (sometimes in multiple packages), and a Makefile > that links everything to a common set of libs which not everything > needs. Your check flags this correctly, but it can be a real pain to > fix, and doesn't usually cause practical problems - particularly the > problem Steve writes about. Remember, the granularity of testing > migrations and library transitions is not the file or even the binary > package, but the source package. This appears to be a fair point. I think I'll revise my proposal so it works per .deb rather than per object file. I'd like to see some broader debate, however. I am not conviced that the entire _source_ package is the right level to check this at. Steve mentioned two problems - one is painfullness of library transitions, the other is segfaults in case of partial upgrades. While the first problem indeed works on the source package level, the second is often a matter between binary packages with the same source. For a concrete example, consider #260938. The autotrace source package builds binary packages libautotrace3 and autotrace; the latter contains a client for the library in the former. A user upgraded the client package without upgrading the library. This _ought_ to have worked because the ABI of the library itself was indeed unchanged. But the upgraded client spuriously pulled in different versions of some library that was, in fact, used only by libautotrace, and a segfault resulted. Had a lintian check for spurious linking existed at the time, I would have noticed that the client binary requested too many shared libs and have an opportunity to fix it because it hit a user with a sefault. -- Henning Makholm "This imposes the restriction on any procedure statement that the kind and type of each actual parameter be compatible with the kind and type of the corresponding formal parameter." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340934: lintian check for unneeded/transitive shlibs dependencies
Package: lintian
Severity: wishlist
Tags: patch
Steve Langasek wrote in
<http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html>:
> I would encourage you to read the presentation in question, but I will
> also summarize here: due to accidents of history, the convention when
> linking an executable or shared library is to tell ld to recursively add
> references to *all* libraries in the dependency tree below it. This is
> wrong for modern GNU/Linux systems when using dynamic linking, because
> the dynamic linker recurses the dependency tree on its own; and
> following this convention means that executables get not the needed one
> reference to the library, but two or more. Where things *really* go
> wrong is when the library goes through an soname change. If two
> different versions of the library are specified in the ELF header, then
> either users can't install the package, or they can install it and then
> it segfaults. In either case, this situation causes a lot more work for
> maintainers, autobuilders, and the release team (trying to get packages
> into testing) than it should.
[...]
> Moreover, this is a problem that happens over and over again, every time
> there's a library transition. It's not hard to look around and see that
> over the course of a release cycle, we spend a lot of time managing
> library transitions -- time that could be better spent on enhancements
> that actually matter to our users. Pruning our package dependencies is
> (ideally) a one-time fix for each package, with long-term time savings
> for each maintainer (and for the release team!). Think how nice it will
> be to have only a third as many dependencies, and only have to rebuild
> your package for a third as many transitions!
I have written a Lintian check which attempts to flag instances of
this problem. It looks for ELF objects that flag shared libraries in
the default search path as NEEDED without actually importing symbols
that the library exports.
The check is a bit unorthodox in that it needs to have the referenced
libraries present on the host system (where lintian is run) and runs
objdump over them to figure out which symbols they export. Linkage to
libraries that cannot be found at lintian time will be silently
accepted as "not superfluous".
Testing and comments solicited. To test, install
<http://henning.makholm.net/debian/lintian_1.23.13makholm_all.deb>,
or just drop the two attached files in /usr/share/lintian/checks/.
--
Henning Makholm "... not one has been remembered from the time
when the author studied freshman physics. Quite the
contrary: he merely remembers that such and such is true, and to
explain it he invents a demonstration at the moment it is needed."
# libneeded -- lintian check script
# Copyright (C) 2005 Henning Makholm
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, you can find it on the World Wide
# Web at http://www.gnu.org/copyleft/gpl.html, or write to the Free
# Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
# MA 02110-1301, USA.
package Lintian::libneeded;
use strict;
use Tags;
use Util;
# NOTE that this check depends on the linked-to libaries actually
# being present on the system where lintian runs.
# The check will _succeed_ silently if the necessary information
# is not present.
sub run {
my $pkg = shift;
my $type = shift;
my %WELLKNOWN ;
# Do not bother to check for spurious linkings to libc packages;
# they are ubiquitous anyway. Get the current list from their
# shlibs files.
# Other libraries to be ignored can be added to the foreach
# list.
foreach my $p ( map(m/(libc[0-9.]+)\.shlibs/ ? $1 : (),
glob "/var/lib/dpkg/info/libc*.shlibs") ) {
open(SHLIBS,"/var/lib/dpkg/info/$p.shlibs") or next ;
while( ) {
next unless m/^(\S+) (\d+) / ;
$WELLKNOWN{"$1.so.$2"} = 1 ;
}
}
sub checkit ($\%\%) {
my ($file,$libs,$syms) = @_ ;
my @unneeded ;
libloop:
for my $lib ( keys %$libs ) {
open(LIB,"-|","objdump -T $$libs{$lib}")
or fail ("cannot run objdump for $lib") ;
while() {
next if /^0+\s/ or /\s\*UND\*\s/ ;
if( m/\s(\S+)\s*$/ && exists $$sym
Re: dpkg-sig support wanted?
Scripsit Florian Weimer <[EMAIL PROTECTED]> > * Henning Makholm: >>> I wouldn't use real base64, though, because it would mean that you can >>> use its hashed output as a file name. >> Good point. One might replace "/" with "_" and omit the final "=". >> Having a "+" in the hash should be safe in most contexts. > It should be replaced with "-". Beyond alphanumerics, only ".", "_", > "-" are in the POSIX portable filename character set[1], and some > systems do not allow the character "+" in file names. However there are already plenty of files with "+" in their names involved in Debian (e.g. /usr/lib/libstdc++.so.6). Having every 64th hash-based filename start with "-" or "." would lead to failure modes for shell scripts (mistaking the filename for a command line option, resp. missing it in globs) that are just infrequent enough that they might not be observed before a quick-and-dirty script is deployed. I think the conclusion is that no simple substitution is at the same time Posix friendly and friendly towards quick-and-dirty scripting. (Yes: substitute /+ with _-, and then move the last character of the base64 encoding to the front. Due to zero padding it must come from the set [AEIMQUYcgkosw048].) -- Henning Makholm "You want to know where my brain is, spetsnaz girl? Do you? Look behind you." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Scripsit Florian Weimer <[EMAIL PROTECTED]> > * Henning Makholm: >> Why wait for the world to settle? Would there be anything wrong with >> writing a sha256sum program that outputs base64 right now? > I wouldn't use real base64, though, because it would mean that you can > use its hashed output as a file name. Good point. One might replace "/" with "_" and omit the final "=". Having a "+" in the hash should be safe in most contexts. -- Henning Makholm "We will discuss your youth another time." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
Scripsit Peter Samuelson <[EMAIL PROTECTED]> > You may laugh if you wish, but I think it's annoying to have to move to > a hash function whose hexadecimal representation takes 64 bytes, which > doesn't leave much room on an 80-column line to describe what the hash > is hashing. Maybe by the time coreutils ships a sha256sum program, the > world will have settled upon BASE64, which requires only 43 bytes. Why wait for the world to settle? Would there be anything wrong with writing a sha256sum program that outputs base64 right now? -- Henning Makholm "Lad min høne være." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Remove
Scripsit Benjamin Seidenberg <[EMAIL PROTECTED]> > Suggestion: Why don't all the readers of debian-devel put something > like this on their blogs: Good idea (but probably not Debian-specific blogs). One should not probably not copy this exact text; I imagine Google will think higher of the links they have _different_ contexts. Now we're at it, also add the link http://wwws.sheetmusicplus.com/sheetmusic/detail/WB.GS2001.html for "du*l*ng b*nj*s" (remember to spell du*l*ng with a single l, which is the spelling that has been misdirected to d-l). -- Henning Makholm "The Board views the endemic use of PowerPoint briefing slides instead of technical papers as an illustration of the problematic methods of technical communicaion at NASA." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Remove
Scripsit Chris Boyle <[EMAIL PROTECTED]> > On Thu, Nov 24, 2005 at 06:54:12PM +, paddy wrote: >> I though a robots.txt thingy on the list web archive is coming to the >> rescue ? > Huh? Isn't having the lists searchable generally a good thing? Yes, a very good thing in general. But excluding specifically the posts about c*llw*ve and d**l*ng b*nj*s might be worth a try. Of course, that is if somebody can be bothered to keep such exclusion lists up-to-date. On the other hand, l.d.o. is not the only place debian-devel is publicly archived, so it might not be worth the trouble to try to fix things locally. -- Henning Makholm "What has it got in its pocketses?" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#340606: ITP: libsub-name-perl -- Assigns a new name to referenced sub
Scripsit "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]> > This module has only one function, which is also exported by default: > subname NAME, CODEREF > Assigns a new name to referenced sub. > The name is only used for informative routines (caller, Carp, etc). Is this really useful enough to be worth the Packages.gz file space? -- Henning Makholm"*Vi vil ha wienerbrød!*" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
