Re: NoX idea
Scripsit Gustavo Noronha Silva [EMAIL PROTECTED] is rm /etc/rc2.d/S99gdm not easy enough for you ? Easy enough for me in my system. It would be nice to have a standard way of telling the system to not start X on any Debian system while keeping X start up being the default without the need of messing with /etc/rc?.d/ and/or /etc/inittab. Why? Using runlevels and appropriate local configuration of the rcN.d links *is* the official, standard, supported way of controlling which services get started when on Debian system (and most other unices with System V-like boot procedures). -- 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: self-depending packages
Scripsit Antti-Juhani Kaijanaho [EMAIL PROTECTED] On 20050301T122452+0100, Tollef Fog Heen wrote: apt invokes dpkg on the command line and due to maximum command line length it sometimes is split in an unfortunate place. I'll repeat what I wrote above: Doesn't apt usually unpack all packages first and then configure them in one run, so that shouldn't matter? I will refrain from repeating what Tollef wrote, but read it again anyway. Apt neither unpacks nor configures packages; it uses dpkg for that. -- 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: [OT] maildir
Scripsit Bernd Eckenfels [EMAIL PROTECTED] Thats why I responded, there is not really a need to modify maildir files, That depends. I sometimes want to archive the text people wrote to me without wasting disk space (and performance when I search my mail archive) on attachments that I don't need anymore. Mutt provides a nice UI for removing attachments, which involves modifying the message file. -- Henning Makholm ... and that Greek, Thucydides -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OT] maildir
Scripsit Brian May [EMAIL PROTECTED] Sure, these are implementation issues that could be solved, but currently mbox wins. Who says you have to use either one or the other for everything? I use maildir for incoming mail but mbox files for most of my old saved mail. Works nice and seamlessly. -- Henning Makholm `Update' isn't a bad word; in the right setting it is useful. In the wrong setting, though, it is destructive... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dehs will stop
Scripsit Bluefuture [EMAIL PROTECTED] There is no reason to put more work and effort on a community tool that community itself consider useless. The community might start considering it less useless if an explanation of what it is supposed to be good for was actually available. In particular, why should a maintainer care about watch files if he uses something else than uscan to keep track of upstream happenings? From time to time, these little microthreads start on d-d where somebody complains that so and so many packages do not have watch files, but it seems always to be left entirely to the reader's imagination to figure out why that is apparently a bad thing. If I go to, say, http://dehs.alioth.debian.org/ in search of information, I find not a single word of purpose or rationale. The only places I can see watch files mentioned in our general required reading documentation (twice in NM-guide and once in dev-ref), they are presented exclusively as a maintainer convenience tool. If people don't care as much about this as you think they should, perhaps it would be a good idea to try explaining why they *should* care, instead of just lamenting their lack of a telepathic understanding of your intentions? -- Henning MakholmNu kommer han. Kan du ikke høre knallerten?
Re: [OT] maildir
Scripsit Ron Johnson [EMAIL PROTECTED] On Mon, 2005-02-28 at 11:54 +1100, Paul Hampson wrote: I thought it was illegal to modify a message. Status: O? I don't know what that means. It means that the message is not marked 'new'. Many MUA's keep track of message flags by inserting this header into the message. -- 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: dehs will stop
Scripsit Bluefuture [EMAIL PROTECTED] If people don't care as much about this as you think they should, perhaps it would be a good idea to try explaining why they *should* care, instead of just lamenting their lack of a telepathic understanding of your intentions? This is not true. You are entitled to believe that the idea is not good. In that case, I wish you the best of luck. I'm not a debian developer, so i could not post on dda mailing list. How does not being a DD stop you from giving explanations elsewhere? Your postings give me the impression that you have control of the contents of dehs.alioth.d.o. Why do you not make that page link to an introduction and explanation before you complain that people cannot guess what would be there if you had bothered to write it? The only reply are: 1) Dehs is useless. 2) Submitting 6229 wishlist bug is not possible/is not the solution (without proposing alternatives method) Now you have a third reply: Explain why people should care, and someone might actually start caring. -- Henning Makholm Det nytter ikke at flygte der er henna overalt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OT] maildir
Scripsit Ron Johnson [EMAIL PROTECTED] Doing a select all, and mark as read on a multi-GB mbox file sounds painful. Indeed. Or just mark the first (or any) message as read. If one's MUA is the version of mutt shipped with woody one gets twice the pain because it will *first* write the updated folder to /tmp and *then* try to move it to the final destination, usually in a home directory on another partition. :-( (I haven't checked whether this happens in sarge's mutt too). -- Henning Makholm Det er trolddom og terror og jeg får en værre ballade når jeg kommer hjem!
Re: [OT] maildir
Scripsit Bernd Eckenfels [EMAIL PROTECTED] In article [EMAIL PROTECTED] you wrote: It means that the message is not marked 'new'. Many MUA's keep track of message flags by inserting this header into the message. You mark a message as new by moving it to the new directory, That's for a maildir. It won't help you for mbox folders. Which kind of was the point, as I understand it. -- 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.
Re: dehs will stop
Scripsit Lucas Wall [EMAIL PROTECTED] On 02/27/2005 11:15 PM, Henning Makholm wrote: Now you have a third reply: Explain why people should care, and someone might actually start caring. The core idea of dehs (as I understand it) is to keep track of [snip explanation] But why did I have to ask to get that information? Why wasn't it included in the intial gripe about people not writing watch files, or at least linked to? Why is it not available on the Dehs website itself? I do not think it is justified to complain it annoys me that people do not do X without at least referencing a place where people can learn why they should do X. -- 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: pwc-source headed for unstable this weekend
Scripsit Eduard Bloch [EMAIL PROTECTED] it might be a good idea for make-kpkg to check whether the necessary files are present in the kernel tree (and warn loudly if they are not) when one tries to build modules. On the other hand I have no idea what would be involved in checking this, so it might be probitively difficult. It is difficult. Many modules need just the kernel build scripts (which are included in most kernel-headers package nowadays, either completely or shared with others via the kernel-kbuild package). Hm, I thought it was just a matter of some generated .o file from which some magic checksum of struct_module was imported during the finalization process. Currently there is no see what the module-source really needs. Maintainers document that in README.Debian but nobody reads that. Not all maintainers do. I recently took over vaiostat-source after day of trial-and-error hocus pocus hacking made me able to compile it on 2.6 kernels. I would most happily document in README.Debian what it needs to have present, but I have no idea what the right answer is. This probably means that I shouldn't ever have thought of maintaining a kernel module package, but it works better now with recent kernels than the old maintainer was able to make it do [1], so I'm not too ashamed of myself. [1] Which was not his fault; he had the very excellent excuse of not anymore owning the hardware that the module is supposed to communicate with, and thus not being able to test anything himself. -- 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: The ghost of libc-dev
Scripsit Bill Allombert [EMAIL PROTECTED] On Sat, Feb 19, 2005 at 12:58:15AM +, Henning Makholm wrote: I don't think there can be much argument that anything that Provides c-compiler also has to make sure that standard header files like stdio.h or unistd.h are present on the system. Otherwise it wouln't be able to do its job, namely compiling C programs. There is no definition of c-compiler: bcc Provides c-compiler but generate 16bit 8086 code that don't run natively on Linux. This make the c-compiler virtual package quite useless. Erm.. right. That somewhat weakens my argument. I naively assumed without checking that c-compiler was something that provided a /usr/bin/cc alternative. On the other hand, the ISO C standard mandate stdio.h and unistd.h, so it seems reasonnable to expect ISO C compliants compilers to depend on libc-dev. On the other-other hand, doesn't the ISO C standard expliclily say that stdio.h and unistd.h do not need to be files in the file system? C89 did, at least. (No, I don't think this matters much.) Really, I think the simplest answer is a tool that detects *all* of the relevant -dev packages, in a simple and automated fashion, I agree with this - it would need some compile-time parallel to shlibs files in order to discover which possibly virtual package is the right one to depend on to get /usr/include/foo.h. Actually, there might be no need for virtual packages, since the tool will be run at compile time and can look up which libc is in use. Libc would not be the only thing decided. Imagine you're creating libbar-dev and one of the .h files you ship contains #include foo.h When the -dev package is built, dpkg says that /usr/include/foo.h comes from libfoo3-dev, which Provides libfoo-dev, libfoo3.1-dev and obsoletepackagename-dev. If you were an automated -dev detector, which package name would you let libbar-dev Depend on? You can't tell without knowing something about which binary and source compatibility policy libfoo tries to follow. However, for as long as we have to trace the dependencies by hand, I see little benefit in requiring an explicit dependency on a libc-dev. There is little benefit, yes. However I feel it is cleaner that way. The -dev package #include files from another -dev package and that warrant a dependency. It is cleaner to not make libc-dev an exception. I have no objections if you as a maintainer of a library package wishes to include libc-dev among the dependencies of your -dev. I don't think it hurts anybody much. But should it be a bug if somebody else does differently for his package? I don't think so. -- Henning MakholmBlessed are those with no shoes, for the earth shall kiss them. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pwc-source headed for unstable this weekend
Scripsit Eric Lavarde [EMAIL PROTECTED] So, basically, your saying that the right way to do this kind of things is to use the corresponding kernel-headers package, and apt-get tells me that I need as well kernel-kbuild to build out-of-tree kernel modules which seems to be exactly what I need. That's what I infer from my own experience. But the kbuild stuff in 2.6 is kinda hairy, and I did not attempt to trace the exact conditions after I found a way to do thing that seems to work consistently for me. This may even be documented somewhere, although it did not jump out and bite my nose when I tried to find out what went wrong. Given the tendency of people like me to just repeat the procedures that worked for 2.4, it might be a good idea for make-kpkg to check whether the necessary files are present in the kernel tree (and warn loudly if they are not) when one tries to build modules. On the other hand I have no idea what would be involved in checking this, so it might be probitively difficult. -- Henning Makholm Luk munden og se begavet ud! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The ghost of libc-dev
Scripsit Joel Aelwyn [EMAIL PROTECTED] The reason given in the origional thread was that these Depends are not solely for building Debian packages (when Build-Essential is reasonable to expect), but for I need to compile $userspace package, which does *not* require B-E be installed, according to current policy. But can one get a C compiler at all (at least a Debian-supplied one) without also pulling in an appropriate libc-dev? I would think that I need to compile $userspace package *did* require at least a compiler to be installed, regardless of policy. Libc6-dev does *recommend* c-compiler, but that does not help with I need to compile $userspace package if $userspace package does not happen to require any third-party libraries. -- Henning MakholmMy fate? Servitude to the Embodiment of Whoops. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The ghost of libc-dev
Scripsit Joel Aelwyn [EMAIL PROTECTED] On Fri, Feb 18, 2005 at 09:17:55PM +, Henning Makholm wrote: But can one get a C compiler at all (at least a Debian-supplied one) without also pulling in an appropriate libc-dev? I would think that I need to compile $userspace package *did* require at least a compiler to be installed, regardless of policy. I guess that depends on whether one wants to rely on every package which Provides c-compiler to also Depend on the correct libc*-dev package for the relevant platform(s). I don't think there can be much argument that anything that Provides c-compiler also has to make sure that standard header files like stdio.h or unistd.h are present on the system. Otherwise it wouln't be able to do its job, namely compiling C programs. I have no a priori opinion about whether such making sure should involve virtual packages, and if so which. However, a -dev packages that contains C(++) headers is obviously only useful if one already has a C compiler, so there should be no need to depend directly on a libc-dev. One might argue that any -dev package that provides a C interface should depend on c-compiler themselves, but our traditional answer to that one seems to be, don't be silly; a user should be able to figure out *that* by himself. Really, I think the simplest answer is a tool that detects *all* of the relevant -dev packages, in a simple and automated fashion, I agree with this - it would need some compile-time parallel to shlibs files in order to discover which possibly virtual package is the right one to depend on to get /usr/include/foo.h. However, for as long as we have to trace the dependencies by hand, I see little benefit in requiring an explicit dependency on a libc-dev. -- 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: The Debian exim 4 packages suck badly on exim-users@exim.org
Scripsit Thomas Bushnell BSG [EMAIL PROTECTED] The point is that I want to massage some parts of the configuration and not others. I want the others to continue to get updated by the normal package installation process. So is the whole thing essentially a workaround for dpkg's current lack of good conffile update management, or would you still prefer the separate files way if dpkg magically gained a well-tested and stable conflict resolution scheme with bells, whistles, and 3-way merges? -- Henning Makholm Gå ud i solen eller regnen, smil, køb en ny trøje, slå en sludder af med købmanden, puds dine støvler. Lev!
Re: The Debian exim 4 packages suck badly on exim-users@exim.org
Scripsit Blunt Jackson [EMAIL PROTECTED] As a general note, I find it annoying, frustrating, and confusing whenever ANY debian package has a substantially different installation or configuratin mechanism than the mechanism documented by the software publisher. Perhaps Debian is not the distribution for you, then. We have always prioritized constistency across the entire Debian OS over adherence to what upstream authors somehow chose to do. I maintain one package whose upstream author apparently thought that $PATH would be a good place to look for a system-wide configuration file. I changed that to look in /etc instead, which makes the configuration mechanism in Debian substantially different from upstream's. You may find this annoying, frustrating and confusing, but it's how Debian operates. -- Henning MakholmDe kan rejse hid og did i verden nok så flot Og er helt fortrolig med alverdens militær
Re: pwc-source headed for unstable this weekend
Scripsit sean finney [EMAIL PROTECTED] On Thu, Feb 17, 2005 at 09:08:11PM +0100, Eric Lavarde wrote: pwc: no version for struct_module found: kernel tainted. i'm guessing that this has to do with how you compiled the module. IME, this message is typically seen when one complies a module against a 2.6 kernel tree where 'make clean' has been run since the latest kernel build. The kernel-headers-2.6.*-foo packages should ship enough intermediate files in /usr/src/kernel-headers/* to prevent this problem, but one easily gets in trouble [1] if one compiles custom kernels without being aware of the problem. [1] Well, such as it is. As long as one does not get oneself in more trouble by trying to use the module against a different kernel build, the warning message at load time seems to be all that happens. -- 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: The Debian exim 4 packages suck badly on exim-users@exim.org
Scripsit John Hasler [EMAIL PROTECTED] Henning Makholm writes: I maintain one package whose upstream author apparently thought that $PATH would be a good place to look for a system-wide configuration file. I changed that to look in /etc instead, which makes the configuration mechanism in Debian substantially different from upstream's. I have made similar changes, but I also patched the documentation. Many DDs do not do so, confusing users. I agree that documentation has to be changed accordingly. Thought it was too obvious to mention. :-) -- Henning Makholm No one seems to know what distinguishes a bell from a whistle. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mplayer, the time has come
Scripsit A Mennucc [EMAIL PROTECTED] debianizer - isn't there a debian/rules way to do this now? no way at all Yes way. See debian/rules get-orig-source in policy. Rest of reply in debian-legal. Why are you posting the same thing separately to two different lists? -- 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: mplayer, the time has come
Scripsit [EMAIL PROTECTED] (A Mennucc) Solution: the DeCSS is deleted from the package proposed for Debian (for this reason, I upload mplayer as a native package); That is not a valid reason to pretend it is a native package. The correct thing to do is to create a new .orig.tar.gz with the offending files removed from it, but keep the rest of the .orig.tar.gz unchanged. Debian changes and package infrastructure should still go in a .diff.gz, and the package version should consist of an upstream version with a separate Debian revision. -- Henning MakholmWhat a hideous colour khaki is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: volunteering to help development
Scripsit Frederico Rodrigues Abraham [EMAIL PROTECTED] hi. i want to help developing for debian. how should i proceed? Start by reading some of the documentation on http://www.debian.org/devel/. The Developer's Reference and New Maintainer's Guide are invaluable for getting an overview of the structure of the project. Afterwards, subscribe to relevant mailing lists, participate in discussions, read the BTS lists for the packages you're interested in, fix bugs and forward fixes to the BTS, et cetera. -- Henning Makholm Hør, hvad er det egentlig der ikke kan blive ved med at gå?
Re: apply to NM? ha!
Scripsit Helen Faulkner [EMAIL PROTECTED] Based on comments made to me by a number of women who are interested in contributing more to Debian, the level of agressiveness on some of the mailing lists and IRC channels is a problem. Hmm... after I started wasting time on #debian-devel I have been struck by how much more friendly and easygoing it is that the mailing list of the same name. That is despite the significant overlap between the participant sets. I understand that some people have the opposite assessment, which boggles my mind. I do not believe that being thick-skinned enough to cope with people who are very agressive or insulting should be a requirement for involvement in Debian. I believe that it *should* be a requirement that one has enough calm to most of the time respond to (percieved or actual) aggression and insults in a less aggressive and insulting way than the other party uses. Otherwise the project will surely die (film at 11!) from runaway flamewar escalation. If you want to describe that as thick-skinned enough to cope (which, based on my understanding of English, would not be a bad description), then yes, somebody involved in Debian *should* be thick-skinned enough to cope. Shouldn't we be more interested in someone's technical skills, and their ability to work well with others? I'm lost here. It seems that you are arguing that you *don't* want ability to work well with others (which in my book includes enough thick-skinnedness not to escalate flamewars) to count? -- 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: policy-rc.d confusion
Scripsit Marc Haber [EMAIL PROTECTED] On Tue, 25 Jan 2005 18:44:42 +1100, Matthew Palmer Steve answered your first question. The second question makes no sense, since policy-rc.d is supposed to be written by the administrator to fit their local policy. So policy-rc.d needs to be in /usr/local, or we have a FHS violation. Hm, I would have guessed /etc - what am I missing? -- Henning Makholm Al lykken er i ét ord: Overvægtig!
Re: scripts to download porn in Debian?
Scripsit Sam Watkins [EMAIL PROTECTED] There is a difference between a general tool (web-browser) and a specific tool (the Sexy Losers script). The script is specifically designed to download a hard-core pornographic comic. FWIW, Sexy Losers is not hard-core pornographic. It does contain drawings of genitals and various sexual acts, and more often than not relies on taboo breaking for its points, but at the end of the day what it attempts to provoke in the reader is not sexual arousal but humorous amusement. This should be obvious to anyone who cares to sit down and actually read a couple dozen strips. Therefore it cannot reasonably be described as porn, although one would probably be justified in calling it offensive due to the general taboo breaking. -- 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: Release update: kde3.3, upload targets, kernels, infrastructure
Scripsit SR, ESC [EMAIL PROTECTED] Scripsit Geoff Bagley [EMAIL PROTECTED] Is it possible to transfer some of the packages, a few at a time, over into Woody, so that when we all change to Sarge, the servers will not suffer from too heavy an overload ? also the plain simple reason that woody's and sarge's libc6 are incompatible. we even coined a term for people installing sarge/sid s/w onto woody machines stupidly, unknowingly, or otherwise: Huh? I run one machine that is mostly woody but with sarge's libc6 and a few selected other sarge packages. This seems to work impeccably in general (I do know where to point my anger at when it doesn't, but in those casses libc has never been involved). If sarge's libc6 were *not* backwards compatible, it would have been called libc7. -- Henning MakholmThere 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: Proper way to remove a package from both sarge and sid
Scripsit Tollef Fog Heen [EMAIL PROTECTED] * Frederik Dannemare | Package in question is mozilla-firefox-locale-da which is to be replaced | by mozilla-firefox-locale-da-dk (not maintained by me) from source | package mozilla-firefox-locale-all. AFAIK, Danish is not spoken anywhere but in Denmark. Why do you want a m-f-l-da-dk rather than just a m-f-l-da ? Hey, I speak Danish and I'm in Scotland. But seriously, I can see benefits of sticking to a common convention for naming localization packages; for example that might make it easier later to add some front end that would automatically add all localization packages for the current locale where I have the underlying software installed. -- Henning MakholmLigger Öresund stadig i Middelfart?
Re: soname number in name of dev-package?
Scripsit Stephen Frost * Henning Makholm ([EMAIL PROTECTED]) wrote: In summary: Yes, one could probably work around the lack of versions in the -dev packages name, but the result would be (in my view) significantly less elegant than having it there. Trying to support unsupported versions of libraries is decidely worse. Is anybody advocating that we should try to support unsupported versions of libraries? I'm certainly not. If the API changes in an incompatible way then *fix* the things which use the library to use the new API. Users aren't affected- the old, already compiled package, works fine against the lib it depends on, the new package will fail when trying to build against the new API Exactly. Ensuring that the new API is not available under the old one's name will make sure that the new package does fail (because of a missing build-dependency) rather than trying silently to build against the new API as if it was the old, and possibly producing bad binaries. -- Henning MakholmThere 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: soname number in name of dev-package?
Scripsit Thomas Bushnell BSG Henning Makholm [EMAIL PROTECTED] writes: Is anybody advocating that we should try to support unsupported versions of libraries? I'm certainly not. Sure! That's what libc5 is. I'm not aware of even having mentioned libc5 in this thread (and I don't remember anybody else doing it either). -- Henning Makholm # good fish ... # goodfish, goodfish ... # good-good FISH! # -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soname number in name of dev-package?
Scripsit Thomas Bushnell BSG Henning Makholm [EMAIL PROTECTED] writes: Scripsit Thomas Bushnell BSG Henning Makholm [EMAIL PROTECTED] writes: Is anybody advocating that we should try to support unsupported versions of libraries? I'm certainly not. Sure! That's what libc5 is. I'm not aware of even having mentioned libc5 in this thread (and I don't remember anybody else doing it either). Libc5 is the counterexample to your implied assertion that nobody really cares about supporting unsupported versions of libraries. I'm lost now. As far as I can see, previously you were telling me that I was wrong for wanting to support unsupported versions of libraries. Now you're saying that I'm wrong for claiming that nobody cares about supporting unsupported versions of libraries. I still don't think I have said *anything* in this thread, implied or otherwise, about supporting unsupported versions of libraries. I have not said that we should do it, I have not said that we shouldn't, I have not said that nobody cares about it, and I have not said that somebody cares about it. Could you explain in little words exactly where you think I imply something about supporting unsupported libraries? Otherwise I'm afraid I'll be unable to reply meaningfully. -- 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: If *-module depends on *-utils, should *-source recommend it?
Scripsit Bernhard R. Link [EMAIL PROTECTED] The elegance is that dpkg is robust in that it can always install everything and can get cleanly from one state to another. However broken the packages are you never end in a sitation you cannot fix again. How would this property be lost if dpkg's default was check for consistency of the end result before it starts unpacking things? Without some full formalisation or anything else to make sure it cannot get out of this state, or can get back to that state easily, it is only a hack. Nobody claims what such checking will necessarily solve all of the world's problems. But it will make life easier for people who only use dpkg occasionally to install locally-built .debs. It would also break serialisation, as one would need to give a list of packages to install to dpkg all at once or in the correct serialisation, and no longer (with exception of configure cycles) beeing able to give them in whatever sequence as one is pleased to do. Nobody is suggesting that there should not be an option to override the default check for users (or front ends) who know what they are doing. -- 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: If *-module depends on *-utils, should *-source recommend it?
Scripsit Scott James Remnant [EMAIL PROTECTED] Forget the impact on debootstrap, the impact on APT and dselect is pretty huge. dpkg is designed to be able to unpack packages while their dependencies are not yet fulfilled. But don't apt and dselect already invoke dpkg with special options to the effect I'm a front end, I know what I'm doing, just carry out these operations, I take responsibility? What's interesting is nobody has jumped in on this thread to point out that dpkg *has* a dependency field for forcing checking of dependencies before the package is unpacked. Pre-Depends As far as I read the thread, this is not exactly what is being asked. My immediate thought, too, is that it would be sensible for dpkg to start by checking whether all dependencies of the packages it is being asked to install *will* be available after everything is finished, including the case where it is to be installed later in the run. A pre-depends is stronger than that; it asks to have checked that this-and-that dependency is *already* available and configured before the preinst. If given the front-end options dpkg would just omit this check, and unpack and later perhaps fail in the postinst phase. I can certainly accept and anticipate the objection that that would be difficult to implement, and nobody has cared to, but I still don't see why such a behavior would be *wrong*, per se. -- Henning Makholm Feet: Store in a cool dry place -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted vaiostat 1.2-7 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 2 Jan 2005 15:46:58 + Source: vaiostat Binary: vaiostat-source Architecture: source all Version: 1.2-7 Distribution: unstable Urgency: low Maintainer: Henning Makholm [EMAIL PROTECTED] Changed-By: Henning Makholm [EMAIL PROTECTED] Description: vaiostat-source - Sony Vaio status and control kernel module (source) Changes: vaiostat (1.2-7) unstable; urgency=low . * Clean up /proc entries properly in a bottom-up fashion; this prevents kernel warnings when unloading. * Permissions for /proc/vaio/status are now 444; it could never actually be written to. * Add 'umask' parameter. . * Fix permission bug from 1.2-6 that prevented module to be built without kernel-package. Files: 70140435cccab4ce01a5fc220b75dded 618 misc extra vaiostat_1.2-7.dsc 18577597b8807b20bcca9b36b04ca504 6714 misc extra vaiostat_1.2-7.diff.gz 29e86fe1494c6b0e565fc2646846b045 13888 misc extra vaiostat-source_1.2-7_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB5DMWsnG09+8vDf4RAjMaAJ9T4LADm4/gJQaeUdK5cINFKLRNDwCffYRR nhrsh1stVniN8ENWXM+ccUk= =C/0S -END PGP SIGNATURE- Accepted: vaiostat-source_1.2-7_all.deb to pool/main/v/vaiostat/vaiostat-source_1.2-7_all.deb vaiostat_1.2-7.diff.gz to pool/main/v/vaiostat/vaiostat_1.2-7.diff.gz vaiostat_1.2-7.dsc to pool/main/v/vaiostat/vaiostat_1.2-7.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rudeness in general
Scripsit Ron Johnson [EMAIL PROTECTED] On Mon, 2005-01-10 at 19:37 +, Henning Makholm wrote: Scripsit Ron Johnson [EMAIL PROTECTED] Do you *really* think that RTFM means Go read the documentation, that's what it's for? Yes, that's what it means. http://catb.org/~esr/jargon/html/R/RTFM.html You're confusing the historic origin of the letter combination with its meaning in actual use. -- Henning Makholm Check the sprog. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Always run dpkg --dry-run -i before running dpkg -i!
Scripsit Hamish Moffatt [EMAIL PROTECTED] As a workaround, the generated modules package could pre-depend on the utils package. That would stop dpkg from unpacking it and leaving a useless installation. Is the installation really more useless with the modules unpackaged-but-not-configured than with the modules not unpacked at all? I fail to imagine any situation where that could be the case. -- Henning MakholmUnmetered water, dear. Run it deep.
Accepted autotrace 0.31.1-8 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 3 Jan 2005 06:45:24 + Source: autotrace Binary: libautotrace-dev libautotrace3 autotrace Architecture: source i386 Version: 0.31.1-8 Distribution: unstable Urgency: low Maintainer: Henning Makholm [EMAIL PROTECTED] Changed-By: Henning Makholm [EMAIL PROTECTED] Description: autotrace - bitmap to vector graphics converter libautotrace-dev - bitmap to vector graphics converter, development files libautotrace3 - bitmap to vector graphics converter, shared library files Closes: 260938 Changes: autotrace (0.31.1-8) unstable; urgency=low . * Add watch file * Make lintian happy again my letting the Build-Depends line be a single (long) line. * Apply patch from Steve Langasek (in bug #262469) to remove direct dependencies from the autotrace binary package to libmagick. (Closes: #260938, as far as it is possible to do in the autotrace package). * Apply patch from Paul Sladen to eliminate redundant closepaths in pdf output. Files: f780fc02a99228ee25d6b7e1135a64af 698 graphics optional autotrace_0.31.1-8.dsc b44f2755fef352fe36ffcdb87ec2ba3e 287457 graphics optional autotrace_0.31.1-8.diff.gz 2cda200808a846fa4cad92e7678d7dcd 39612 graphics optional autotrace_0.31.1-8_i386.deb 48dce168ec25fea06a4093ce02989783 106556 libs optional libautotrace3_0.31.1-8_i386.deb afb9c4508af344f66ff15a7f9fcf 130544 libdevel optional libautotrace-dev_0.31.1-8_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB3thGobE/LCyLGVoRAll/AKC0ULyGsKbqVnEOmJYoW3g7IlGJRwCfS+q6 6U9jWfbECJeqehU1zgtUs9s= =VerF -END PGP SIGNATURE- Accepted: autotrace_0.31.1-8.diff.gz to pool/main/a/autotrace/autotrace_0.31.1-8.diff.gz autotrace_0.31.1-8.dsc to pool/main/a/autotrace/autotrace_0.31.1-8.dsc autotrace_0.31.1-8_i386.deb to pool/main/a/autotrace/autotrace_0.31.1-8_i386.deb libautotrace-dev_0.31.1-8_i386.deb to pool/main/a/autotrace/libautotrace-dev_0.31.1-8_i386.deb libautotrace3_0.31.1-8_i386.deb to pool/main/a/autotrace/libautotrace3_0.31.1-8_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Experimental gaim_1.1.1-2 for Alpha
Scripsit Steve Langasek [EMAIL PROTECTED] On Wed, Jan 05, 2005 at 11:47:57PM +, Henning Makholm wrote: Does it also apply to signing .dsc's? The archive scripts won't act on an uploaded .dsc without an accompanying .changes file, so this is not an issue. Moreover, signing your .dsc provides a trust path to your source code I think that is what I meant: If I sign a .dsc that is not intended to be uploaded, is there a risk that this trust path ends up in the archive because somebody else constructs a .changes to put them in? The somebody else would have to be a DD, but the signature the general public [1] would see in aptable source repositories would be mine. Or do the archive scripts check that the key that signed the .dsc is the same that signed the .changes accompanying them? [1] People with suffientent knowledge would know to look up the .changes in the PTS or the mailing list archives, but it is not generally distributed afaiu. -- 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.
Re: Experimental gaim_1.1.1-2 for Alpha
Scripsit Martin Michlmayr [EMAIL PROTECTED] * Steve Langasek [EMAIL PROTECTED] [2005-01-05 15:12]: Be careful: in general, you should *not* sign changes files for packages that are not intended to be included in the Debian archive. Once the changes file is signed, anyone can upload your package to the Debian archive whether that was your intent or not. Greg doesn't appear to be a Debian developer so neither of this applies. But if he later *does* become a DD, the archive scripts might retroactively accept his old changes file if somebody uploaded it, wouldn't they? (I'd be surprised if they checked the creation date of the signature, but things sometimes do surprise me). Here I ignore the fact that a newer version would probably be in the archive by then, for this particular package at least. The first paragraph is good advice in general, though. Does it also apply to signing .dsc's? -- Henning MakholmHe who joyfully eats soup has already earned my contempt. He has been given teeth by mistake, since for him the intestines would fully suffice.
Re: LCC and blobs
Scripsit Thomas Bushnell BSG [EMAIL PROTECTED] Matthew Garrett [EMAIL PROTECTED] writes: The obvious thing to do here is not to attempt to find a way that we can interpret the SC that makes sense - the obvious thing to do here is to decide what we want the SC to say and then change it so that it matches that desire. We already did that. The editorial changes to the SC did/will change depend on to require the use of, but that's as open to interpretation as the old wording. The problem has just shifted from the meaning of depend to the meaning of require and use - in either case one can imagine cases where there are two different but internally consistent and more-or-less reasonable views on whether the use of a non-free component is required. Some people, for example, would probably argue that one does not use firmware when it does not execute on the main CPU, or that a driver that is able to function if the firmware is already loaded by some other means does not itself require the firmware. I know what I think about such opinions, but the fact is that they are held by some, and in at least some cases probably sincerely. -- 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.
Re: LCC and blobs
Scripsit Anthony DeRobertis [EMAIL PROTECTED] Henning Makholm wrote: Scripsit Anthony DeRobertis [EMAIL PROTECTED] That would, however, cover firmware and wind up sending X to contrib. So maybe: ... iff it is stored on the local machine's file system. That would be my *intuitive* understanding of how the mail/contrib difference works. So would a web-based firmware loader, that never saved the firmware to disk allow the drivers to be in main? Hmm. Maybe. If it was properly documented in the package description for the driver that its proper function relies on an external website that the user presumably has no control over, then perhaps. But I don't think I would be really comfortable with it. The line is difficult to draw in the area of relying on external services. At one end of the spectrum is cases where what a typical user really wants to use is the external service; he knows that the service is external and views the client as a mere conduit to access something that he knows he does not control. I _think_ everybody agrees intuitively that such clients can be in main. The canonical example would be a client for proprietary IM systems, but the situation is somewhat similar with, say. IRC clients. Even though main does contain IRC server software, the vast majority of users want to connect to existing external IRC networks, so having the source does not really help them control the service that they use. Yet nobody would suggest that the client does not belong in main for this reason (except perhaps as part as a reductio-ad-absurdum argument about the true meaning of the SC). Things begin to get murky when the client provides a local service that is useful in its own right, and only incidentally needs to contact external network sites to provide it. One could imagine an anti-spam tool that submitted checksums of message fragments to a central server for correllation with other user's data. (Never mind that such an anti-spam measure would probably not be effective, at least not if it became popular). Or one could imagine a heuristic keyword extractor for plain text files which, behind the scenes, queried Google to find out how common cetain phrases. In these cases the user is not primarily interested in interacting with an external service but is probably still aware that the quality of the results he gets owe something to the use of external resources. At the extreeme other end is situations where the net service the user actually wants (I want to scan this photograph with my WinScanner) has no *extrinsic* reason to require a non-local resource. Web-based firmware loaders belong here. I have definite qualms about including something of the latter category in main, but I am not sure that I can support this judgement with deductions from a short clear-cut definition of what each word in the SC and Policy means. However, I don't think that such a deductive development is a necessary requirement for which policy the project should adopt. Bright-line tests are overrated anyway. -- Henning MakholmJeg køber intet af Sulla, og selv om uordenen griber planmæssigt om sig, så er vi endnu ikke nået dertil hvor ordentlige mennesker kan tillade sig at stjæle slaver fra hinanden. Så er det ligegyldigt, hvor stærke, politiske modstandere vi er.
Re: LCC and blobs
Scripsit Raul Miller [EMAIL PROTECTED] On Sat, Jan 01, 2005 at 11:33:21AM -0800, Josh Triplett wrote: Please suggest any case which you don't think this criteria adequately covers. The bios. Unless, we decide that the bios we put in non-free isn't the bios we need to boot the machine. On which architectures would we want to let anything declare a Depends: on a BIOS package? Granted, the only arch I'm really familiar with is i386, but most of those machines come with a sufficiently adequate BIOS in ROM that it would be rather silly for most packages, including stock kernels and boot loaders, to declare more than a Suggests: against an alternative BIOS. That would just bloat the user's file system without gaining him anything. -- Henning Makholm Det er du nok fandens ene om at mene. For det ligger i Australien!
Accepted bibclean 2.11.4-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 29 Dec 2004 14:27:06 + Source: bibclean Binary: bibclean Architecture: source i386 Version: 2.11.4-5 Distribution: unstable Urgency: low Maintainer: Henning Makholm [EMAIL PROTECTED] Changed-By: Henning Makholm [EMAIL PROTECTED] Description: bibclean - pretty-printer for BibTeX databases Changes: bibclean (2.11.4-5) unstable; urgency=low . * Support the new ISDN-13 format (validation and format canonicalization). * Update ISDN prefix range database in isbn.c with fresh data from www.isbn-international.org. Files: d444275ff63081a4672a2f6737ee850d 574 tex optional bibclean_2.11.4-5.dsc 149f91e604db955b686adbc344219321 31379 tex optional bibclean_2.11.4-5.diff.gz c7fd9f5c147f47dd06c0465bd84c486f 131474 tex optional bibclean_2.11.4-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFB1XOyHPo+jNcUXjARAhCJAJ9CUusjEAVCkuec98tiBDHRjKAZ8gCeKkAZ G8aY2eNmhkz0e7DFPva+GwM= =9Aqe -END PGP SIGNATURE- Accepted: bibclean_2.11.4-5.diff.gz to pool/main/b/bibclean/bibclean_2.11.4-5.diff.gz bibclean_2.11.4-5.dsc to pool/main/b/bibclean/bibclean_2.11.4-5.dsc bibclean_2.11.4-5_i386.deb to pool/main/b/bibclean/bibclean_2.11.4-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted vaiostat 1.2-6 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 27 Dec 2004 23:10:59 + Source: vaiostat Binary: vaiostat-source Architecture: source all Version: 1.2-6 Distribution: unstable Urgency: low Maintainer: Henning Makholm [EMAIL PROTECTED] Changed-By: Henning Makholm [EMAIL PROTECTED] Description: vaiostat-source - Sony Vaio status and control kernel module (source) Closes: 269615 Changes: vaiostat (1.2-6) unstable; urgency=low . * New maintainer . * Revised the entire module build system. New Makefile, new debian/rules. Some debian/rules items filched from thinkpad. . * Fix upstream bug (floating-point in kernel code), so the module now builds and loads successfully for kernel 2.6.8 and 2.4.27. (Closes: #269615) Files: bed03d4e7fb56b2a61e66a30da108b86 618 misc extra vaiostat_1.2-6.dsc 1102dc25b64f472a8766e56accdde9b9 5895 misc extra vaiostat_1.2-6.diff.gz e3a1574d689567106db5d5fe722c6a3d 13344 misc extra vaiostat-source_1.2-6_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFB0+saIblXXKfZFgIRAlzoAJ9uZl1IQvH+UHRSX8bVmR87g2ZdhgCfTIUl fygWMeH6pxFbG53pRnOenxQ= =E9MD -END PGP SIGNATURE- Accepted: vaiostat-source_1.2-6_all.deb to pool/main/v/vaiostat/vaiostat-source_1.2-6_all.deb vaiostat_1.2-6.diff.gz to pool/main/v/vaiostat/vaiostat_1.2-6.diff.gz vaiostat_1.2-6.dsc to pool/main/v/vaiostat/vaiostat_1.2-6.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#284283: ITP: fairuse -- spam filter based on sender identity verification
Scripsit Joe Wreschnig [EMAIL PROTECTED] So not only does it fail to stop spam in any useful way, it doesn't even fail to do so according to the standard, and it sends out more email noise while doing so. It gets worse yet: the FAQ says | Legitimate senders know immediately that you haven't received their | email, allowing them to click to deliver it. Meanwhile, they only | sit in the queue for an hour if they can't be delivered. Sigh. -- Henning Makholm Monarki, er ikke noget materielt ... Borger!
Re: Bug#283994: ITP: glastree -- builds live backup trees, with branches for each day
Scripsit Charles Fry [EMAIL PROTECTED] Is there any benefit to using glastree over dirvish or pdumpfs? The advantage of using glastree over pdumpfs is that it is implemented in Perl rather than Ruby (this is in fact the reason that I encountered it in the first place). How would this be relevant to the *user*? Usually I don't care which languages the software I use is written in, except perhaps when it breaks and I need to hack the source. However, all languages can be used to write horrible write-only code, so using software written in a known language is no guarantee. -- Henning Makholm Larry wants to replicate all the time ... ah, no, all I meant was that he likes to have a bang everywhere.
Re: Bug#283994: ITP: glastree -- builds live backup trees, with branches for each day
Scripsit Matthew Palmer [EMAIL PROTECTED] Meanwhile, what's the total installed space for glastree if you're not a Perl lover? Perl-base is 'Proirity: required' and 'Essential: yes'. It doesn't even have to be depended on. -- 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.
Re: remove me from callwave
Scripsit [EMAIL PROTECTED] remove me from callwave [EMAIL PROTECTED] This is getting as bad as the du*ling b*njos phenomenon. For some time I just thought that callwave must an AOLism for a discussion forum, and that the posters wanted to unsubscribe from debian-devel. However, Google does not support this hypothesis. On the other hand callwave.com markets something they call an internet answering machine, which seems to correlate with the talk of phones in some of the postings, for example http://lists.debian.org/debian-devel/2004/08/msg01826.html Debian-devel is now result number four when googling for callwave remove (without quotes). I still wonder what the people posting here are thinking, though. If they are thinking at all, that is. -- 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.
Re: Introducing pmount in Debian / New plugdev group
Scripsit [EMAIL PROTECTED] (Paul Hampson) On Tue, Nov 09, 2004 at 06:41:40PM +0100, Martin Pitt wrote: We solved (4) by introducing a new group called 'plugdev'. Every user who is a member of this group can access hotpluggable devices (digital cameras, USB drives etc.). pmount can only be executed by members of this group (it is root:plugdev 750), This must be be a typo. Surely such a program would need to be suid root, i.e. mode 4750 was meant rather than 750. In a Debian package it should have mode 4754; there is no reason to deny unprivileged users *reading* the binary as long as they cannot use the suid i-node to execute it. Policy §10.9, fifth paragraph. Hmm. What's to stop a user fetching their own version of the pmount binary? Nothing, anymore than there is something to stop a user compiling such a program himself. However, the kernel ought to stop said user from saving his binary in a file owned by root. As long as it's not owned and suid by root it cannot be used to do privileged operations. If so, then a+x mode is safe, and directed by Debian Policy (I think. If not, it's in the Developer's Reference as a good idea). The point of not having a+x is to allow the sysadmin to control who gets the privilege of using pmount. -- Henning Makholm `Update' isn't a bad word; in the right setting it is useful. In the wrong setting, though, it is destructive...
Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy
Scripsit Frank Küster [EMAIL PROTECTED] And if you take the combination of both: Upstream source that contains non-DFSG material and forbids to use the DFSG-free parts without explicitly referring to the removed non-DFSG-free parts, well, IANAL, and IANARODL[2], but I wouldn't like this. IAARODL. If the DFSG-free part cannot be distributed without the non-DFSG-free parts, then it was never DFSG-free in the first place. -- 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.
Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy
Scripsit Frank Küster [EMAIL PROTECTED] First, thank you for taking hand of this issue! |3. should, except where impossible for legal reasons, preserve the | entire building and portablility infrastructure provided by the | upstream author. For example, it is not appropriate to omit source | files that are used only when building on MS-DOS Unfortunately, there are lots of precedent for MS-DOS specific files to carry a non-free license, so removing them can be the safe option. That's why I (or Henning) wrote except where impossible for legal reasons. To prevent this misunderstanding, perhaps change to For example, it is not sufficient reason to omit a file that it is used only when buidling on MS-DOS. Similarly, a Makefile provided by upstream should not be omitted even if the first thing your debian/rules does is to overwrite it by running a configure script. Some minor typos, most certainly originally made by me: officially distributed to the upstream author: s/to/by/ non-DFGS-free material: s/GS/SG/ the latter two points it to let: s/it/is/ -- Henning Makholm Also, the letters are printed. That makes the task of identifying the handwriting much more difficult.
Re: Package name eMail or not?
Scripsit Millis Miller [EMAIL PROTECTED] The upstream has since released a newer version under the GPL and has indicated to me a willingness to have the package called eMail. My question is if this change of capitalization acceptable to Debian, or would it still insist on a different package name? A package in Debian cannot be called eMail - package names must be all lower case (policy §5.6.6) Having a package called just email would be very confusing for our users. I suggest you qualify the package name with e.g. the author's name [given that the author seems obstinately unwilling to give his software a non-generic name] or something like that. -- Henning MakholmVi 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!
Re: about volatile.d.o/n
Scripsit Sven Mueller [EMAIL PROTECTED] Henning Makholm [u] wrote on 11/10/2004 20:22: [volatile.debian.org] Security fixes should be handled by security.d.o. Perhaps yes, perhaps no. Security fixes *to* packages already in volatile is a grey area, yes. I thought I was talking about security fixes to stable packages going in volatilie instead of security.d.o. -- Henning Makholm You want to know where my brain is, spetsnaz girl? Do you? Look behind you.
Re: about volatile.d.o/n
Scripsit paddy [EMAIL PROTECTED] On Mon, Oct 11, 2004 at 07:22:15PM +0100, Henning Makholm wrote: Scripsit paddy [EMAIL PROTECTED] To be fair, the issue is that if were just rules, there wouldn't be a need. Why not? Well, the argument goes: that can be done out-of-band, But isn't volatile.d.o supposed to *be* the out-of-band mechanism (whatever out-of-band means here)? but some updates involve changes or additions to the engine. There is a class of such software. I don't see how that means that there wouldn't be a need for rule updates. SA3 has been on the cards for some time now. Is there a policy around name changes at these times? could you have pinned (3.0) ? Not according to my understanding of apt pinning. And in any case the point is that I want to run a *stable* box. I am not keeping consciously track with upstream changes to background software like spam filters, so I didn't *know* that a 3.0 version was about to happen. A user of stable should be *able* to remain ignorant about such chages. That's what stable means. At the end of the day, I'm not certain exactly what you wanted protecting from, See the long thread about spamassassin3. The highlight is that the new version has a non-backwards-compatible API which makes certain other software stop working. I did not personally have any local scripts that depended on the old API, but I might have had. but it's hard to be certain that volatile would give it to you. After all the point is to get (at least some) changes. The point is to get improved *classification* without changing the *interfaces*. Clearly, but the *format* in which the virus scanner reports its findings should stay stable. You'll get no argument from me on the priciple of that. But what is stable? What if a format needs extending to take account of some new circumstance? Then a decision has to be made respecting the users' interest in having whatever local scripts they are using keep working. For instance, suppose there are Packages A and B in volatile. (A) has an interface (1) that is only used by (B) in the whole of debian. In the whole of Debian is not the only concern here; I would say it is not even relevant. Admins of un*x systems are *supposed* to write a truckload of local scripts to adapt their system to their wishes. That's the way it works. And our commitment in calling stable stable is that those local scripts will keep working across security updates, unless breaking them is necessary to close a hole. Similarly, if volatile is to be any value added over pinning unstable or testing, it must respect the same commitment. but the case for eventually upgrading to (1+) is compelling: it is only a question of when and how. If upgrading will break existing interfaces, then when means after the current testing freezes and is released as stable. You've said mozilla belongs in backports, which I'll take to mean: mozilla does not belong in volatile. I'm saying that *new upstream versions* of mozilla with hundreds of little interface changes, new preferences file formats, et cetera, does not belong in volatile. So you're not advocating mozilla in volatile. It may be that someone will come along that will advocate it in a compelling fashion, but I'm not holding my breath. Until then, if no one is building it, then what is there to knock down ? I do not understand that question either. Concrete example: I care about virus detection in the first two weeks, and even more so in the first few hours. To me not detecting a virus, purely because someone is correcting spellings would be downtime. (of course, if it's because _I'm_ too busy or too lazy, that's a different matter ! ;) I'm not sure what consequences this example has for what should and what should not be accepted in volatile. If the volunteer who would be preparing a rule update would rather use his time correcting spellings, we cannot force him. But that is probably not what you're getting at? -- Henning Makholm I tried whacking myself repeatedly with the cluebat. Unfortunately, it was not as effective as whacking someone else.
Re: about volatile.d.o/n
Scripsit paddy [EMAIL PROTECTED] On Tue, Oct 12, 2004 at 03:05:05PM +0100, Henning Makholm wrote: But isn't volatile.d.o supposed to *be* the out-of-band mechanism (whatever out-of-band means here)? No. clamav virus signatures, for example, can be maintained by a program, freshclam, that downloads database updates from upstream. I know that, but as far as I under stande, the whole point of volatile is to replace exactly that with a situation where each maintainer does not have do program his own freshfoo system (and worry about finding a location to download from that is known in advance to stay availbale throughout the entire lifetime of the next stable release). I don't see how that means that there wouldn't be a need for rule updates. See above. The consensus seems to be that it would be undesirable to even try to push this data through the regular package-management channel. Whose consensus is this? The debian-devel feed that reaches me shows quite enthusiastic support for pushing rule updates through an aptable repository. And in any case the point is that I want to run a *stable* box. I am not keeping consciously track with upstream changes to background software like spam filters, so I didn't *know* that a 3.0 version was about to happen. A user of stable should be *able* to remain ignorant about such chages. Ah, but you weren't just a user of stable were you? You'd drunk from the forbidden waters of unstable! :) Because volatile does not currently exist. The point is to get improved *classification* without changing the *interfaces*. For me the point is to achieve function. Function may disappear totally if the update makes things break. If upgrading will break existing interfaces, then when means after the current testing freezes and is released as stable. Yes, for stable. Do we want 'just another stable' ? No, we want a way to push non-breaking data updates to stable users in a controlled way. They'll still be stable users, so they still want freedom from gratuitous breaking. If you s/mozilla/spamassassin/ I might want to argue the point. Well, I don't want to se an update to spamassassin in volatile if it breaks APIs that my scripts use. Raising spam detection rates from 97% to 98% is useless if the update makes my mail system go catatonic and deliver all incoming mail, spam or not, to /dev/null. I run stable on my mail server because I *don't* want random breakage, and if not having any random breakage means that I'll have do delete a bit more of my spam by hand, then so be it. If I wanted random breakage, I'd run testing on the server. But I don't. Why are we talking about mozilla? I don't know. You seem to have some kind of point about it, but I still cannot fathom what it is. -- Henning Makholm Occam was a medieval old fart. The simplest explanation that fits the facts is always, God did it.
Re: [OT:HUMOR] Re: software
Scripsit Kevin Mark [EMAIL PROTECTED] Price for Commercial Software: Cost: several hundreds dollar and vendor lock-in And even more if one wants legit copies. Membership has its privedleges! Which? No membership is required. -- Henning Makholm ... and that Greek, Thucydides
Re: about volatile.d.o/n
Scripsit Florian Weimer [EMAIL PROTECTED] Can volatile receive critical updates which are usually not applied to stable because backports are not available for some reason? Mozilla, GnuPG, and maybe even PHP 4, depending on sarge's lifetime. Other complex packages can easily enter this state, too, especially when sarge has been around for a year or two. I would advise not trying to overloade volatile with too many meanings. A backport of a new Mozilla release is something vastly different from new rules for a spam filter, and I see little value in lumping them together in the same add-on repository. I would like to see a volatile with a very strict mandate: 1. Volatile is a means for *pushing* updates to stable installations, where such updates are necessary for *preserving* the utility of packages due to changes of the outside world. 2. Necessary for preserving the utility should be judged under the assumption that the machine that runs stable does not itself change. (I.e., appeals to this is needed for modern hardware don't count). 3. No update pushed through volatile should ever change any user interfaces or programmatic interface. (How paranoid developers are expected to be in ensuring this is negotiable, but it must at least be the *goal* that no interfaces change.) The goal should be that I, as a user, can add volatile to my sources.list and periodically do an apt-get upgrade - without risking to suddenly have my web browser updated to a new major release where it starts behaving differently, all my users' preferences get out of kilter, etc. If I run a web browser on a stable machine, it is because I am satisfied with its behavior and capabilities. If I want a newer one, I can go to a regular backports repository and pick one by hand. I do not want to get a new version pushed at me simply because it becomes available. If I wanted that kind of behavior I would run testing or unstable, not stable. An update of mozilla-browser would be appropriate for volatile if it did not change the upstream codebase, but, say, updated the default SSL root certificate set in response to announcements from a well-known CA. An update that fixed the default style sheet to include new tags from XHTML 2.1, assuming that it was possible without code changes, would be borderline. Anything more involved than that - no thanks. -- Henning Makholm Punctuation, is? fun!
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
Scripsit George Danchev [EMAIL PROTECTED] IMHO a MTA must be capable acts as a client and as a server to transfer messages between machines and is responsible for properly routing messages to their destination, e.g. RFC 974. msmtp does not do all of these, therefor it is not a MTA, and might have nothing to do with /usr/sbin/sendmail. You are wrong. See nullmailer. The definition of mail-transport-agent is that it provides a /usr/sbin/sendmail that local software can use to submit emails for delivery to arbitrary addresses with some reasonable expectation that it will actually be delivered. It is *not* required that the package that provides mail-transport-agent must itself do any particular part of the delivery process, as long as its /usr/sbin/sendmail will *somehow* arrange for delivery. It would be perfectly good to have a package airgap-mailer whose /usr/sbin/sendmail will just *print* hardcopies of its input on a configured printer, with instructions to the human operator to type the email into the machine at the Internet-connected side of the air gap. This package would provide mail-transport-agent because it implements the policy-defined API for shipping email for delivery. Note that telnet does know nothing about smtp protocol. Neither does airgap-mailer. Note that a MTA isn't required to know ANYTHING about smtp. Suppose a package provides an sendmail that is an alias for 'ssh mailhub /usr/sbin/sendmail', then that package is a MTA. Such a package will require a dependency of ssh (at least) on the remote machine and you will be in a little trouble hacking your control file to satisfy things like that ;-) That is up to the system administrator to arrange. If it provides a /usr/sbin/sendmail, then it is an MTA. It does not make it any less an MTA that it requires some manual configuration before its /usr/sbin/sendmail can do anything useful with its input. Most MTA's do, actually. I think ssmtp is incorretly described as a MTA That must be because you don't understand what an MTA is. WARNING: the above is all it does; it does not receive mail, expand aliases or manage a queue. That belongs on a mail hub with a system administrator. Neither of these are necessary tasks for an MTA. -- Henning Makholm The spirits will have to knit like banshees, but with enough spirits it *can* be done!
Re: TG3 firmware report...
Scripsit sean finney [EMAIL PROTECTED] they may have released it under the GPL, but there's a strong case for arguing that they're in violation of their own licensing terms for not providing the source code to the firmware blobs. The copyright holder cannot logically be in violation of his own licensing terms. He does not need a license at all to distribute his own work, thus there is nothing for *him* to violate. -- Henning MakholmJeg køber intet af Sulla, og selv om uordenen griber planmæssigt om sig, så er vi endnu ikke nået dertil hvor ordentlige mennesker kan tillade sig at stjæle slaver fra hinanden. Så er det ligegyldigt, hvor stærke, politiske modstandere vi er.
Re: about volatile.d.o/n
Scripsit Andreas Barth [EMAIL PROTECTED] I could however see the possiblity to add a new package mozilla1.7, that users can optionally install. However, I also won't like it. Me neither. For example, if I was already using somebody else's backport of mozilla1.7, I wouldn't like it if volatile.d.o hijacked that package and attempted to update it with maintainer scripts that know nothing about the backport I'm using. All additions of new packages carry such a risk, and I don't think that volatile should take that risk unless demonstrably necessary for reaching the main goal of volatile. Which is not duplicating something that existing backports repositories do well. (For the same reason, any updates that add any _new_ /usr/lib/*.so files should be treated with extreme caution. Their name may clash with something I have in /usr/local/lib, and break things. On the other hand /usr/lib/packagename/*.so is fair game). -- 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 ...
Re: about volatile.d.o/n
Scripsit paddy [EMAIL PROTECTED] On Mon, Oct 11, 2004 at 05:06:21PM +0100, Henning Makholm wrote: A backport of a new Mozilla release is something vastly different from new rules for a spam filter, To be fair, the issue is that if were just rules, there wouldn't be a need. Why not? I pretty much want to have the spamfilter rules on my mail box updated from time to time. Currently that has lead me to put a low-pinned unstable in sources.list and get spamassassin from there. But it was not meant to suddenly pull in spamassassin3. If volatile had existed, I could have avoided that. MailScanner can be configured to send mail to an admin account warning of various events. I filter these with procmail. Recently these warnings changed. I would not want a volatile maintainer to be hamstrung in such a case if no package in debian uses the interface: I disagree here. One of the main reasons to run stable (apart from getting security updates) is that one can be sure that one's homegrown scripts will not suddenly stop working because some of the Debian-provided software changes the behavior. That means that updates should avoid *any* unnecessary interface changes, right down to preserving spelling errors in the messages used by the intially released version. Volatile should preserve that stability guarantee and stick to changing the internal processing to be up-to-date with the changed world. Clearly the names of virus identifications sometimes change. This is expected. I would say that the interface is _defined_ as volatile. Clearly, but the *format* in which the virus scanner reports its findings should stay stable. Playing the devil's advocate: Someone's going to say so don't do that then aren't they. They probably are, at least until we can agree what is and what is not the purpose of the facility. I'm arguing what *should* be the purpose. Are you saying you have a use for a volatile mozilla, or simply that you see potential problems? If it's the latter, then I agree, you have identified a potential problem area. I'm not sure that I understand that question. Also: for a web-browser, yes. For applications in more voltile domains I'm willing to be a little more flexible. But that's just me. Do you have an concrete example we can use to discuss where the line should be drawn? An update of mozilla-browser would be appropriate for volatile if it did not change the upstream codebase, but, say, updated the default SSL root certificate set in response to announcements from a well-known CA. It would seem a shame to have to do a whole mozilla-browser package just for that. First example that came to mind. A smart maintainer who anticipates doing such an update would probably separate out the root certificates in a small package that could be shared with other PKI-using packages. For all I know, this may already be how it works currently; I did not spend much time tracing the dependencies of the various mozilla packages. I think what you're saying is you don't want the browser to change very much. Yes. If it makes the keyboard shortcuts I'm used to work differently, then it's too much. I don't know how important fixing 'the default style sheet to include new tags from XHTML 2.1' is, but it sounds pretty unimportant to me. Yes. The point was that if somebody cared enough to do a volatile update for it I wouldn't find it totally out of line. But I would not expect anybody to care that much. Presumably, security fixes are more important. Security fixes should be handled by security.d.o. There may or may not be somebody who claims that they *are* not handled by s.d.o (I haven't seen that, but I haven't looked for it either). Even if true, that does not change the fact that s.d.o is where it *should* be handled. Introducing volatile just to make it a competing security team would be silly. I don't see any need to place obstacles in the way just in case. And I'm concerned that those obstacles might ultimately get in the way of packages _in_ volatile (when we have some). I'm not proposing any mozilla-specific obstacles, at least as not as far as I'm aware. -- Henning Makholm Slip den panserraket og læg dig på jorden med ansigtet nedad!
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
Scripsit George Danchev [EMAIL PROTECTED] On Monday 11 October 2004 19:18, Henning Makholm wrote: The definition of mail-transport-agent is that it provides a /usr/sbin/sendmail that local software can use to submit emails for delivery to arbitrary addresses with some reasonable expectation that it will actually be delivered. MTA is a software talking at least one Mail Transfer Protocol (like SMTP, UUCP, X.400 ...) That is not what mail-transport-agent means in Debian. It is *not* required that the package that provides mail-transport-agent must itself do any particular part of the delivery process, as long as its /usr/sbin/sendmail will *somehow* arrange for delivery. Are you talking about MDA here ;-). No. Delivery agents are used to place a message into a user's mail-box. Yes, and nullmailer (and probably msmtp) does not do that. A mail-transport-agent does not need to be a delivery agent too. Such a package must talk at least one Mail Trasfer Protocol to be called MTA. False, not for the meaning of mail-transport-agent we use in Debian. Providing /usr/sbin/sendmail is required but not enough to call it MTA. Providing /usr/sbin/sendmail is the necessary and sufficient condition to be a mail-transport-agent. msmtp has not the features of a MTA, As it has been explained her, msmsp has exactly the features of a mail-transport-agent. Providing /usr/sbin/sendmail is required, but not enough to call it MTA
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
Scripsit Christian Surchi [EMAIL PROTECTED] I'm not msmtp fan or user, but I lost two minutes to read the home page trying to understand the differences. msmtp is simply a way to delivery mail to a remote smtp server. For example you cannot have it listening on 25 port, so I cannot see it as a sendmail alternative, just like nullmailer or ssmtp or other ones... Nullmailer is simply a way to deliver mail to a remote SMTP server. For example you cannot have it listening on port 25. Nevertheless it quite correctly provides mail-transport-agent, and so on. -- Henning MakholmWhat a hideous colour khaki is.
Re: Bug#275685: ITP: msmtp -- smtp client which can be used as a smtp plugin with mutt
Scripsit Christian Surchi [EMAIL PROTECTED] msmtp is not an MTA: I think that msmtp simply will take the place of sendmail binary called by mutt. If it provides /usr/sbin/sendmail, then by definition it is a mail-transport-agent and should, if packaged, declare itself as such. If it provides the same functionality as /usr/sbin/sendmail but with a different command name, then somebody needs to explain why. -- 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.
Re: about volatile.d.o/n
Scripsit Andreas Barth [EMAIL PROTECTED] Some things are not so obvious: Should volatile include updates of packages such as debian-keyring? debian-policy and developers-reference? -- Henning Makholm Al lykken er i ét ord: Overvægtig!
Re: Bug#274923: ITP: wnpp -- C++ library for robust numerical and geometric computation
Scripsit Joachim Reichel [EMAIL PROTECTED] Uups, I missed that I might have to change the name of the library itself. Or is it possible to have a package named libcore++1 containing libraries libcore.so.1? (If yes, there is still the problem that a quite generic (file)name is used.) Unless there are two pacakges that provide technically interchangeable implementations of the same functionality, there is no reason to make package names more unique than the sonames of the libraries they provide. If the upstream source is written to create libcore.so.1 and there is no known conflicts with other libraries using the same name, I think Debian should provide the library under the same name. Client application source will be written to use -lcore, and we'd do nobody a service by forcing Debian users to change that manually. -- Henning Makholm Hele toget raslede imens Sjælland fór forbi.
Re: Installed-Size and block size
Scripsit Andre Majorel [EMAIL PROTECTED] Is the Installed-Size field supposed to be computed for a specific block size, or can I just go with a usual block size like 4k ? Do not try to compute Installed-Size by hand - dpkg-gencontrol will do it for you correctly. That is, unless you have a specific very good reason to bypass dpkg-gencontrol (or its debhelper wrapper). Do you? -- Henning Makholm Also, the letters are printed. That makes the task of identifying the handwriting much more difficult.
Re: possible mass bug filing: spamassassin 3
Scripsit Colin Watson [EMAIL PROTECTED] This is backwards. The conflicts must be added in spamassassin in order that we don't forget to remove said other packages from sarge if necessary. Won't work, at least not by itself. Since we expect the other packages to sooner or later be updated to work with spamassassin3, a conflict from spamassassin would need to be a versioned one. But how is the spamassassin maintainer to know which future version of the client package will work with spamassassin3? The only fully watertight solution would be to have spamassassin 3 declare Conflicts: client-package-1 (= $currentversion1), client-package-2 (= $currentversion2), ... client-package-N (= $currentversionN) and arrange for *each* *future* version of the client packages to declare Conflicts: spamassassin (= 3.0) until they have been fixed. (But release-manager intervention would still be needed for SA3 to proceed to testing before all current clients have been fixed). -- 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.
Re: Installed-Size and block size
Scripsit Andre Majorel [EMAIL PROTECTED] On 2004-10-06 16:09 +0100, Henning Makholm wrote: Do not try to compute Installed-Size by hand - dpkg-gencontrol will do it for you correctly. For my enlightenment, what does dpkg-gencontrol do that is more correct than summing st_blocks ? Use the source. It's free. (Answer: dpkg-gencontrol uses du -k) That is, unless you have a specific very good reason to bypass dpkg-gencontrol (or its debhelper wrapper). I only use dpkg-architecture and dpkg-deb -b. Everything under DEBIAN/ is generated by hand. Then you're asking for hardship. Have fun with it. Those are packages for a proprietary product. I looked into debhelper but it was just getting in the way dpkg-gencontrol is not part of debhelper. -- Henning Makholm Hi! I'm an Ellen Jamesian. Do you know what an Ellen Jamesian is?
Accepted autotrace 0.31.1-7 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 1 Aug 2004 12:05:45 +0100 Source: autotrace Binary: libautotrace-dev libautotrace3 autotrace Architecture: source i386 Version: 0.31.1-7 Distribution: unstable Urgency: medium Maintainer: Henning Makholm [EMAIL PROTECTED] Changed-By: Henning Makholm [EMAIL PROTECTED] Description: autotrace - bitmap to vector graphics converter libautotrace-dev - bitmap to vector graphics converter, development files libautotrace3 - bitmap to vector graphics converter, shared library files Changes: autotrace (0.31.1-7) unstable; urgency=medium . * Rebuild for libtiff4 transition Files: 9ac989cb782980c2f10c7455f42de832 702 graphics optional autotrace_0.31.1-7.dsc 80c2794b3aaf3f1bf9b60d3386bf6b7a 286300 graphics optional autotrace_0.31.1-7.diff.gz ad04aaa42c02401f8da095d75aaff154 39808 graphics optional autotrace_0.31.1-7_i386.deb 45a0c1b150975ca87a2c12ee9a60e42a 106404 libs optional libautotrace3_0.31.1-7_i386.deb 5510382b2227d2e1b0fd9307cea7ce89 130394 libdevel optional libautotrace-dev_0.31.1-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBDo5wobE/LCyLGVoRAo7WAKClqBPBjZvxoRzSGDezHjRmffrR1gCglU5d +ILQGeOWTmw2CM1KCmbwyd4= =2a2I -END PGP SIGNATURE- Accepted: autotrace_0.31.1-7.diff.gz to pool/main/a/autotrace/autotrace_0.31.1-7.diff.gz autotrace_0.31.1-7.dsc to pool/main/a/autotrace/autotrace_0.31.1-7.dsc autotrace_0.31.1-7_i386.deb to pool/main/a/autotrace/autotrace_0.31.1-7_i386.deb libautotrace-dev_0.31.1-7_i386.deb to pool/main/a/autotrace/libautotrace-dev_0.31.1-7_i386.deb libautotrace3_0.31.1-7_i386.deb to pool/main/a/autotrace/libautotrace3_0.31.1-7_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted autotrace 0.31.1-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 27 Mar 2004 03:42:14 + Source: autotrace Binary: libautotrace-dev libautotrace3 autotrace Architecture: source i386 Version: 0.31.1-5 Distribution: unstable Urgency: low Maintainer: Henning Makholm [EMAIL PROTECTED] Changed-By: Henning Makholm [EMAIL PROTECTED] Description: autotrace - bitmap to vector graphics converter libautotrace-dev - bitmap to vector graphics converter, development files libautotrace3 - bitmap to vector graphics converter, shared library files Closes: 239990 Changes: autotrace (0.31.1-5) unstable; urgency=low . * Copyright file now contains the actual copyright notices from the source. * Do not distribute the AUTHORS and README files, which tell nothing not already documented in the binary package. * However, README contained a minimal example of how to use the libautotrace library. Ship it as /usr/share/doc/libautotrace-dev/examples/sample.c, after fixing typo. * General cleanup of debian/rules. Explicitly suppress use of libming, to avoid FTBFS bugs caused by API changes in the library. * Re-computed build-dependencies from scratch. Libdps was not actually used. Liblcms1-dev, libfreetype6-dev, libtiff3g-dev, libxml2-dev, xlibs-dev, libbz2-dev, and libwmf-dev are all pulled in by libpstoedit-dev and/or libmagic-dev, and the source does not refer to any of their include files, so there should be no reason to build-depend on them explicitly. Libplot-dev can be removed from the control file once libpstoedit-dev has been fixed (#240382) to pull it in. * Fix dependencies for libautotrace-dev. (Closes: #239990). * Add manpage for autotrace-config. Files: 1357e80dc6169aea362b2d9a8db9c674 902 graphics optional autotrace_0.31.1-5.dsc 7887abbc6e42a0b507cc24d8e0e34c4f 257988 graphics optional autotrace_0.31.1-5.diff.gz 3f1e9cc61ce82ad8f62199959a060c52 48760 graphics optional autotrace_0.31.1-5_i386.deb cf23c18ef75fd066dcf60a653703e42d 105756 libs optional libautotrace3_0.31.1-5_i386.deb 102229045ff9a69f7b76c3fd28860791 130046 libdevel optional libautotrace-dev_0.31.1-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAepL5obE/LCyLGVoRAnpRAJ9JD30rZuM/CaHrbBfi/WgD+FmC0gCfVdnJ U+DKlI8pOLKDaXHSejSSKFQ= =Dw3B -END PGP SIGNATURE- Accepted: autotrace_0.31.1-5.diff.gz to pool/main/a/autotrace/autotrace_0.31.1-5.diff.gz autotrace_0.31.1-5.dsc to pool/main/a/autotrace/autotrace_0.31.1-5.dsc autotrace_0.31.1-5_i386.deb to pool/main/a/autotrace/autotrace_0.31.1-5_i386.deb libautotrace-dev_0.31.1-5_i386.deb to pool/main/a/autotrace/libautotrace-dev_0.31.1-5_i386.deb libautotrace3_0.31.1-5_i386.deb to pool/main/a/autotrace/libautotrace3_0.31.1-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted bibclean 2.11.4-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 24 Feb 2004 20:58:56 + Source: bibclean Binary: bibclean Architecture: source i386 Version: 2.11.4-3 Distribution: unstable Urgency: low Maintainer: Henning Makholm [EMAIL PROTECTED] Changed-By: Henning Makholm [EMAIL PROTECTED] Description: bibclean - pretty-printer for BibTeX databases Changes: bibclean (2.11.4-3) unstable; urgency=low . * Fix the autotools timestamp skew problem for configure/configure.in. Thanks to Martin Loschwitz for noticing that my previous attempt at fixing this did not work reliably (due to upstream shipping a Makefile in his tarball rather than just a Makefile.in). * Tune generation of the canned help text in bibclean.h such that its layout matches that distributed by upstream better. Files: 67d95e11c0943bd151de6525c670df9a 574 tex optional bibclean_2.11.4-3.dsc 0995915ea4afc41284631713695ad6aa 17594 tex optional bibclean_2.11.4-3.diff.gz 03d407475e4eb8ae9de416b951317e4a 127622 tex optional bibclean_2.11.4-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAQMrcobE/LCyLGVoRAp+AAJ94lYJBICJP4mBHnwADVX1ULvS2yQCgi5ZC Aw6HMAe0Y8rkHgnNbcfFKWs= =hokS -END PGP SIGNATURE- Accepted: bibclean_2.11.4-3.diff.gz to pool/main/b/bibclean/bibclean_2.11.4-3.diff.gz bibclean_2.11.4-3.dsc to pool/main/b/bibclean/bibclean_2.11.4-3.dsc bibclean_2.11.4-3_i386.deb to pool/main/b/bibclean/bibclean_2.11.4-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted autotrace 0.31.1-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 4 Jan 2004 10:59:32 + Source: autotrace Binary: libautotrace-dev libautotrace3 autotrace Architecture: source i386 Version: 0.31.1-4 Distribution: unstable Urgency: low Maintainer: Henning Makholm [EMAIL PROTECTED] Changed-By: Henning Makholm [EMAIL PROTECTED] Description: autotrace - bitmap to vector graphics converter libautotrace-dev - bitmap to vector graphics converter, development files libautotrace3 - bitmap to vector graphics converter, shared library files Closes: 226042 Changes: autotrace (0.31.1-4) unstable; urgency=low . * The libmagick saga continues; rebuild once again. (Closes: #226042). * Add debian/fixmagickversions, which creates conflicts against the versions of libmagick(++) that contained libraries with wrong sonames. Files: 83eb380c520f3bd6d80dc0543fd94104 939 graphics optional autotrace_0.31.1-4.dsc 56748053463a2ab80644707ef47bf2cf 280145 graphics optional autotrace_0.31.1-4.diff.gz 171d80ba20fb13a1021fb02d8abf4715 51214 graphics optional autotrace_0.31.1-4_i386.deb f23b46500160f8a711fac2068c33b5c8 104472 libs optional libautotrace3_0.31.1-4_i386.deb 5f13af9e26197a47abc0f57d5423809b 127334 libdevel optional libautotrace-dev_0.31.1-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAAyLoobE/LCyLGVoRArE1AJ0QzBM1BjC/1u25oqWymHdugUabZQCeOkvr GF1KeanMztvaZQIag35NS6E= =KwG/ -END PGP SIGNATURE- Accepted: autotrace_0.31.1-4.diff.gz to pool/main/a/autotrace/autotrace_0.31.1-4.diff.gz autotrace_0.31.1-4.dsc to pool/main/a/autotrace/autotrace_0.31.1-4.dsc autotrace_0.31.1-4_i386.deb to pool/main/a/autotrace/autotrace_0.31.1-4_i386.deb libautotrace-dev_0.31.1-4_i386.deb to pool/main/a/autotrace/libautotrace-dev_0.31.1-4_i386.deb libautotrace3_0.31.1-4_i386.deb to pool/main/a/autotrace/libautotrace3_0.31.1-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted autotrace 0.31.1-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 20 Dec 2003 01:32:54 + Source: autotrace Binary: libautotrace-dev libautotrace3 autotrace Architecture: source i386 Version: 0.31.1-3 Distribution: unstable Urgency: low Maintainer: Henning Makholm [EMAIL PROTECTED] Changed-By: Henning Makholm [EMAIL PROTECTED] Description: autotrace - bitmap to vector graphics converter libautotrace-dev - bitmap to vector graphics converter, development files libautotrace3 - bitmap to vector graphics converter, shared library files Closes: 224287 Changes: autotrace (0.31.1-3) unstable; urgency=low . * Rebuild against latest libs (again, again!). (Closes: #224287) * Fix bug in the redone autofoo stuff that caused 'debian/rules binary' to run the configure script once again. Files: 5777eef493f4d46e2da7364f3e85c24b 847 graphics optional autotrace_0.31.1-3.dsc 724d2663e0b5f60a6196bb1bd46711bb 279171 graphics optional autotrace_0.31.1-3.diff.gz 44227857fcc4b7cfc44474217040a85a 51078 graphics optional autotrace_0.31.1-3_i386.deb d5ad3ff4c1caddaa500bcb3e15dc53d6 104368 libs optional libautotrace3_0.31.1-3_i386.deb a64275cabe39868bbc63eb5377f17e3b 127212 libdevel optional libautotrace-dev_0.31.1-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/5Fk9obE/LCyLGVoRAsRmAJwP6eWAQvhjaW2BWZHTCiAjXOHA3wCfZ1Yw MA6DydilhEH9lRNhhEupCxA= =GHdH -END PGP SIGNATURE- Accepted: autotrace_0.31.1-3.diff.gz to pool/main/a/autotrace/autotrace_0.31.1-3.diff.gz autotrace_0.31.1-3.dsc to pool/main/a/autotrace/autotrace_0.31.1-3.dsc autotrace_0.31.1-3_i386.deb to pool/main/a/autotrace/autotrace_0.31.1-3_i386.deb libautotrace-dev_0.31.1-3_i386.deb to pool/main/a/autotrace/libautotrace-dev_0.31.1-3_i386.deb libautotrace3_0.31.1-3_i386.deb to pool/main/a/autotrace/libautotrace3_0.31.1-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Changes in formal naming for NetBSD porting effort(s)
Scripsit Kevin Kreamer [EMAIL PROTECTED] In the case of a NetBSD libc, you could use Debian NBSD/NBSD basically having the first half signify which libc is used. Wouldn't that be a major retcon? AFAIU the GNU/ in Debian GNU/Linux says that we're using GNU userland tools such as cp, mv, diff, cc, make, nroff, etc. That's prominently visible to users; the libc is a technical detail that most users wouldn't care about unless it breaks. -- 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.
Re: [OT] Re: Changes in formal naming for NetBSD porting effort(s)
Scripsit Joel Baker [EMAIL PROTECTED] On Thu, Dec 18, 2003 at 03:05:46PM +1100, Russell Coker wrote: On Thu, 18 Dec 2003 14:39, Joel Baker [EMAIL PROTECTED] wrote: Imagining it? I suppose it's possible that I've hallucinated the stated positions of the Catholic, Luthern, Episopalian, Baptist, and Mormon authorities (the latter not technically being considered a sect So which civil rights are you referring to? Details in a private reply So you're spewing slander across the broad spectrum of all or almost all Christians and refusing to back up your allegations in public? Yes, that will work well, methinks. -- 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.
Re: [OT] Re: Changes in formal naming for NetBSD porting effort(s)
Scripsit Joel Baker [EMAIL PROTECTED] The 'slander', if such it is (and I, obviously, don't consider it such) is against the named set of churches, and those that follow their doctrinal decrees Claiming that Christians are against civil liberties is slander in my book. You named, among other, a subset of Christians that I belong to, and claimed that our doctrinal decrees are against civil rights. I hold this to be untrue, and unless you can back up your claims, I am going to think of you as a liar. But, like I said. I'm willing to back it up, in private. If you're not willing to back up your accusations in public, you shouldn't make them in public. -- Henning Makholm Hele toget raslede imens Sjælland fór forbi.
Re: Changes in formal naming for NetBSD porting effort(s)
Scripsit Branden Robinson [EMAIL PROTECTED] On Thu, Dec 18, 2003 at 04:31:42AM +, Henning Makholm wrote: Which would amount to saying We won't tell you why, but please change your name. I think that would be discouteous in the extreme. No, they simply could have said that they were worried that people would be confused that NetBSD was a product of the Debian Project. Isn't that what they did? They added that such confusion might make it hard for them to defend their trademark. Is that a threat of litigation against Debian? I think not. It is simply an explanations of their misgivings. Possible approaches include: 1) don't ask, don't tell 2) order us to stop 3) grant us a license 4) Ask us nicely to stop. Not compatible with mention of trademark. Yes, because their trademark is one of the reasons why they would like us to stop. That is called being open, not being threatening. And (4). I don't think you have provided *any* evidence that (4) was not what they did, and I think that to react as if (2) was the case would be silly and excessively confrontational. There is no such thing as a common-law trademark. I don't see the connection between that and what I wrote. Telling someone that they are (or might be) diluting your trademark is putting them on notice that you think you have a potential tort claim against them. Perhaps it has that legal implication. You are claiming that this legal implication is *why* they told us about their misgivings. I find it hard to believe that, when the alternative explanation that they were just being polite is so much more likely. That's not polite in my book. I still don't see how you think they could have explained their problems in a polite way, then. Your book seems to say that being open is impolite. In yours, for all I know, it's a means of romantic flirtation. Please read what I wrote. Telling us why they are worried *is* polite. Just telling us that they are worred, and deliberately withholding information about why is impolite. -- Henning MakholmAnd 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.
Re: Changes in formal naming for NetBSD porting effort(s)
Scripsit Branden Robinson [EMAIL PROTECTED] On Mon, Dec 15, 2003 at 01:12:21AM +, Henning Makholm wrote: I think you trimmed away content that was crucial for understanding the parts you did quote, but whatever. If you need reptition or elaboration, I'll provide it. Please do. I found nothing in your article that seemed to provide answers to my questions. I ask again: How do you suggest that the NetBSD people should have communicated their misgivings to us? One possibility would have been to not raise the trademark issues at all. Which would amount to saying We won't tell you why, but please change your name. I think that would be discouteous in the extreme. Possible approaches include: 1) don't ask, don't tell 2) order us to stop 3) grant us a license 4) Ask us nicely to stop. 1) is no longer on the table. They didn't do 3), though they might still. That leaves 2). And (4). I don't think you have provided *any* evidence that (4) was not what they did, and I think that to react as if (2) was the case would be silly and excessively confrontational. I'm generally in favor of a use or lose it approach to intellectual property, but this is more like be an asshole or lose it. I still cannot see how you imagine that they could have *told* us about their misgivings at all in a way that you wouldn't equal with being an asshole. -- Henning Makholm In my opinion, this child don't need to have his head shrunk at all.
Re: Bug#223772: general: no md5sums for many packages (e.g. bc)
Scripsit [EMAIL PROTECTED] why is the md5sums file useless and space wasting especially in terms of security? until now, I was of the opinion, that the md5sum gives me the guarantee that a debian package is not penetrated before installation No, that's what the checksum of the entire .deb file in the Packages file is there for. An attacker who can tamper with /usr/bin/foo within the .deb can just as easily tamper with the md5sums file within the .deb. and further - after having the packages installed on a machine - the md5sum files give me the confidence that the debian binaries are correct and consistent. No. An attacker who changes the binaries can just as easily change the md5sum files stored in /var/lib/dpkg/info. If you go to a trusted copy of the .deb file for verifying your binaries, you have the original binaries right there, and do not need precomputed checksums for comparing them bit-for-bit with what's on your disk. It has been argued on debian-devel (read the thread!) that the md5sums files can be handy to have for detection of non-malicious random acts of God. But the sense of *security* gained by having the .deb install a set of checksums on the same machine as the package itself is false. -- Henning Makholm Det er du nok fandens ene om at mene. For det ligger i Australien!
Re: experimental codename
Scripsit Graham Wilson [EMAIL PROTECTED] However, I am not (nor do I believe a majority might be) that experimental should duplicate unstable, with only a few packages (the experimental ones) being newer. However, with the pool structure archive, this might not actually mean a duplication of too much space. Well, experimental's Packages file itself would become as large as the one for unstable. Most people would still want to have unstable as well as experimental in their sources.list, because the ride might get too rough if you pulled _everything_ from experimental that there is to pull. For example, one might be willing to help stress-test the packaging of perl6, but not at the same time as stress-testing new glibc packages. At least on my system, synchronizing the Packages file on a daily basis accounts for a significant fraction of the total amortized bandwith I use for tracking unstable, simply because I have to download it in full every day. So inflating experimental/Packages to full distribution size would probably have a measurable effect on mirror load level. -- Henning Makholm I've been staying out of family conversations. Do I get credit for that?
BTS and maintainer changes
How quickly is a change of maintainer supposed to propagate to the BTS?
I recently adopted autotrace, and had a package with an updated
control file uploaded; it has now been in the archive for several
days. I have checked that I am correctly listed as maintainer in
the unstable Sources file and in
http://ftp.debian.org/indices/Maintainers{,.gz}.
Nevertheless, the BTS persists in giving the QA group as the maintainer
at, say, http://bugs.debian.org/src:autotrace. I am worried that
this might mean that I am not notified of bug activity by email.
http://www.debian.org/Bugs/Developer indicates that the Maintainer
field should suffice to make the listing change, but also hints that
there is a behind-the-scenes override file at work. Is that override
file publically available anywhere such that I can check whether an
old override entry for the QA team is stuck there?
Or is the BTS just not yet completely up after the compromise?
--
Henning Makholm We can build reactors, we can melt
ice. Or engineers can be sent north for
re-education until they *do* understand ice.
Re: Changes in formal naming for NetBSD porting effort(s)
Scripsit Branden Robinson [EMAIL PROTECTED] On Sat, Dec 13, 2003 at 10:30:04PM +, Henning Makholm wrote: I think you're seing spectres. I think you didn't bother to read any of the parts of my message that you didn't quote. I did. But I trimmed away those that were not necessary for the reader to be reminded of the context. That is, I belive, common netiquette. I ask again: How do you suggest that the NetBSD people should have communicated their misgivings to us? As far as I can see, your complaint is that the misgivings they speak about *could* in theory be used as grounds for legal proceedings. If you insist on seeing evil intentions behind the mere mention of them, how on earth do you want them to act? -- Henning Makholm They discussed old Tommy Somebody and Jerry Someone Else.
Re: Proposed change to debian release system
Scripsit Andreas Metzler [EMAIL PROTECTED] Henning Makholm [EMAIL PROTECTED] wrote: Everybody seems to agree that new stable versions *should* be out about every 6 months. No. I stand corrected, apparently. (But I have yet to imagine which arguments would be used against doing a release if we happen to find testing in a freezeable state 6 months after sarge releases). -- 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.
Re: Changes in formal naming for NetBSD porting effort(s)
Scripsit Branden Robinson [EMAIL PROTECTED] On Sat, Dec 13, 2003 at 09:28:12AM +0430, Stephane Bortzmeyer wrote: Legally speaking, you're right. Now, on more practical grounds, I do not think that the NetBSD Foundation threatened to sue us. I didn't say they did. They did identify a legal theory for doing so in the future, though. It's not like there is a common law of trademark dilution, or a natural right of trademarks. Would you at least consider that possibility that they might have meant exactly what they said: We're somewhat worried that if someday we have to defend our trademark against a real villain, then the villain may be able to get off the hook by pointing to Debian/FreeBSD. Could we work together on finding another name that will let us sleep tighter? Just because the fear they related *could* be used as grounds for a lawsuit doesn't mean that it's not real. I think the polite thing to do, if one has no intention of suing someone, is not to speculate to a person's face about what the thrust of your court complaint might be. How would you expect them to that, if you insist of reading the mere mention of why they are uneasy as a veiled lawsuit threat? Should they just say: We humbly suggest that you change your name, but we cannot tell you why, because that would sound like a lawsuit threat? (BTW, to me it's immediately clear that it can't be a threat, because they know that we know that a threat would be completely empty, because we know that they know that they would earn an ocean of bad karma if they actually attacked another majour open-source project through the courts.) The TNF has made it clear enough that they feel they have legal remedies at their disposal if we don't handle their request in a manner to their liking. I think you're seing spectres. -- Henning Makholm ... and that Greek, Thucydides
Re: Proposed change to debian release system
Scripsit Arnaud Vandyck [EMAIL PROTECTED] Scott Minns [EMAIL PROTECTED] writes: Stable - released when the software is rock sold and very mature Current - This is software that has been in testing for six months and experienced no critical bugs, floors or dependency problems. A new version is released every six This is nearly impossible. I don't know if other developers will agree but IMHO, it's like having two `stable' releases! I concur. In particular, the process is already such that if we get even near something that fits this description of current, a big party will be thrown and that something will be frozen to become the next stable within a short timeframe. Everybody seems to agree that new stable versions *should* be out about every 6 months. The problem of getting testing into a freezeable state is not going to go away simply by calling the goal current instead of stable. -- Henning Makholm What has it got in its pocketses?
Re: Release-critical Bugreport for December 12, 2003
Scripsit Goswin von Brederlow [EMAIL PROTECTED] BugScan reporter [EMAIL PROTECTED] writes: Package: chrony (debian/main) Maintainer: John Hasler [EMAIL PROTECTED] [REMOVE] 223134 [] chrony: FTBFS: Errors in kernel headers Why is chrony getting removed? AFAIU, the [REMOVE] tag means that the release manager thinks that *if* we do not succeed in fixing this bug, *then* it is reasonable to remove the package from sarge rather than letting it delay the release. It does not imply that the bug is less likely to get fixed than bugs without the tag. (And if it does get fixed, of course it will not cause the package to be removed). The first step in getting concrete information is always to look at the bug in the BTS. Here you'll find that the maintainer of crony is working on the bug and has filed three comments within the last week. 223145 [] defrag: FTBFS: Errors in kernel headers (If the maintainer is unresponsive or something I would adopt either package.) This bug is less than a week old, so it's a little early to declare that the maintainer is unresponsive. -- Henning MakholmWhat the hedgehog sang is not evidence.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Bruce Sass [EMAIL PROTECTED] On Wed, 10 Dec 2003, Henning Makholm wrote: Have you quantified the bloat you are speaking about? Can the same argument not apply to any i18n effort? Yes, using KDE2. The script removed any lines with [stuff] in them from KDE files (was possible at the time without incurring breakage) Then it's not the format you're opposing, but the inclusion of extra content in the .debs. -- Henning Makholm Monarki, er ikke noget materielt ... Borger!
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Isaac Clerencia [EMAIL PROTECTED] I sincerely hope that some day further development of Debian's great package management system will make localepurge fully obsolete. brainstorm on I've been wondering whether the Right solution to this kind of problems might be to invent some concept of glue packages. In technical terms, that would be a way to tell apt-get and its ilk things like: - If frobnitz and locale-danish are both installed, then automatically try to install frobnitz-i18n-da. - If frobnitz and emacsen are both installed, then automatically try to install frobnitz-el. - If libx11 and tetex-base are both installed, then automatically try to install xdvi. - If ispell and locale-danish are both installed, then automatically try to install idanish. Then by installing appropriate locale-XXX packages, one would automatically pull in i18ns for the specified language for all packages that have been translated. Nobody would get bloated with translations of pacakges they don't use or translatations to languages they don't read. Most of the glue packages should be in a special section where they don't show up in package-selection interfaces. Possible exceptions would be things like idanish above - it's quite plausible to want Danish spell checking without also wanting one's tools in general to attempt to speak Danish in status and error messages. Since many glue packages will individually be quite small, some implementation engineering will be necessary in order to prevent bloat my maintainer scripts and standard /usr/share/doc/* contents. Some kind of by-demand distribution and assembly of Packages files might also be necessary in practise. /brainstorm -- Henning MakholmNej, hvor er vi altså heldige! Længe leve vor Buxgører Sansibar Bastelvel!
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Henning Makholm [EMAIL PROTECTED] Oops, possible meaning-disturbing typo: implementation engineering will be necessary in order to prevent bloat my maintainer scripts and standard /usr/share/doc/* contents. s/my/by/ -- Henning Makholm Det er du nok fandens ene om at mene. For det ligger i Australien!
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Bruce Sass [EMAIL PROTECTED] On Tue, 9 Dec 2003, Henning Makholm wrote: Scripsit Bruce Sass [EMAIL PROTECTED] On Tue, 9 Dec 2003, Moritz Moeller-Herrmann wrote: If you don't think the problem being discussed matters, why are you participating in the discussion? The problem is real, the format used to convey the data is immaterial. The format that should be used is what this thread is about discussing. If you want to discuss something different, that is fine, but it will be most practical if you do it in a different thread. the question should be, what requires more work: adding features to the existing menu system, or changing the entire menu system. Is there a difference? The changes being contemplated consist in adding features, and any addition of features constitute a change. Yes. relatively small change vs. rewriting almost from scratch Nobody has proposed rewriting almost from scratch. Please avoid strawman arguments; they convince nobody of anything and does nothing to forward a resultion of the question. Users and developers are also resisting the proposal. With few or no actual arguments about what would go bad. The pain is not worth the gain... Nobody has put forward any description of which pain it is that you speak. why should all the menu consumers need to redo their menu handling It is not being proposed that they should. Yes, but that does not buy KDE and Gnome users anything unless the .desktop files are in the .debs for the applications they use. We're discussions how to allow the .debs to contain them without duplication of information and needless redundancy. Ok. How about doing it so the vast majority of menu consumers are not stuck with a needless rewrite. They aren't. The fraction of Debian users who use KDE and Gnome is probably less than 90%, but I don't believe that it is small enough that it makes sense to oppose on principle their getting the information they want. All users should be able to get what they want, including those who don't want KDE or Gnome... saddling them with bloated .desktop files does not achieve that. Have you quantified the bloat you are speaking about? Can the same argument not apply to any i18n effort? Having a .desktop infrastructure is worth nothing if you dont have the data it works with. KDE and Gnome users would certainly benefit from having .desktop files in the .debs of the packages they use. Yes, but they would benefit in the same way if the KDE and Gnome specific bits were an addendum to the main menu data entries. At the cost of a more complicated system, which would by nobody anything. Only KDE and Gnome users stand to benefit, so they should be the ones with the added burden. Which burden? Just how much more time and resources would it take to convert .desktop files to Debian menu definitions? How often does it have to be done? 1 or 2 hundred bytes vs. a couple to few thousand bytes _per_entry_; I think we can spare that much memory while generating the menus. I would like to see: /usr/lib/menu/desktop /usr/lib/menu/desktop/gnome /usr/lib/menu/desktop/kde But for some reason you're wildly opposed to the idea that .debs can contain files that populate these directories. Why? -- Henning Makholm Larry wants to replicate all the time ... ah, no, all I meant was that he likes to have a bang everywhere.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Andrew Suffield [EMAIL PROTECTED] On Tue, Dec 09, 2003 at 02:51:53AM +0100, Moritz Moeller-Herrmann wrote: You do realize that the desktop standard has more features than the debian menu system? Like i18n, icon theming, dynamic construction of a menu hierarchy based on user /Desktop system preferences and so on? [...] Because you gain *nothing* Are you claiming that everyone who says that .desktop has technical advantages is a liar? These features actually do not exist in the desktop format? (It may be so; I have no firsthand information, but it does sound far out). -- 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.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Andrew Suffield [EMAIL PROTECTED] Straw man, again. The proposal was to rewrite all menu entries as .desktop files - Yes. That is a straw man. -- Henning MakholmNej, hvor er vi altså heldige! Længe leve vor Buxgører Sansibar Bastelvel!
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Andrew Suffield [EMAIL PROTECTED] On Tue, Dec 09, 2003 at 01:57:29PM +, Henning Makholm wrote: Are you claiming that everyone who says that .desktop has technical advantages is a liar? No. I'm claiming that everyone who says that only by using .desktop exclusively can we do these things is a liar. Then there are no liars on this list. Let's rejoice! -- Henning Makholm Uh ... a picture of me with my hair pinned up in a towel and standing in front of a grid without a trace of makeup? *Are you out of your rock-happy mind?*
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Bruce Sass [EMAIL PROTECTED] On Tue, 9 Dec 2003, Moritz Moeller-Herrmann wrote: In which format shall application packages store their menu information. It doesn't matter, If you don't think the problem being discussed matters, why are you participating in the discussion? the question should be, what requires more work: adding features to the existing menu system, or changing the entire menu system. Is there a difference? The changes being contemplated consist in adding features, and any addition of features constitute a change. Users and developers propose following the freedesktop standard and using this. Users and developers are also resisting the proposal. With few or no actual arguments about what would go bad. How is this logical? How does the freedesktop standard not gain us features? Because nobody but KDE and Gnome use those features and they already support .desktop files. Yes, but that does not buy KDE and Gnome users anything unless the .desktop files are in the .debs for the applications they use. We're discussions how to allow the .debs to contain them without duplication of information and needless redundancy. freedesktop entry features debian menu file features True, but everyone except KDE and Gnome will toss out the freedesktop features. Processing bloated .desktop files just to toss the results is a waste of resources. The fraction of Debian users who use KDE and Gnome is probably less than 90%, but I don't believe that it is small enough that it makes sense to oppose on principle their getting the information they want. Nobody benefits from the transition... not even KDE or Gnome, since they already support the features the freedesktop standard brings to the table. Having a .desktop infrastructure is worth nothing if you dont have the data it works with. KDE and Gnome users would certainly benefit from having .desktop files in the .debs of the packages they use. I regularily use KDE, UWM, pdmenu, and Fluxbox, I also have twm, xfce and mwm installed... processing the menues takes too much time and resources as it is, and you want to use up more, for what gain? Just how much more time and resources would it take to convert .desktop files to Debian menu definitions? How often does it have to be done? -- Henning MakholmI have seen men with a *fraction* of your trauma pray to their deity for death's release. And when death doesn't arrive immediately, they reject their deity and begin to beg to another.
Accepted autotrace 0.31.1-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 6 Dec 2003 14:15:01 + Source: autotrace Binary: libautotrace-dev libautotrace3 autotrace Architecture: source i386 Version: 0.31.1-2 Distribution: unstable Urgency: low Maintainer: Peter Makholm [EMAIL PROTECTED] Changed-By: Henning Makholm [EMAIL PROTECTED] Description: autotrace - bitmap to vector graphics converter libautotrace-dev - bitmap to vector graphics converter, development files libautotrace3 - bitmap to vector graphics converter, shared library files Closes: 206859 Changes: autotrace (0.31.1-2) unstable; urgency=low . * New maintainer. (Closes: #206859) * Redid autofoo stuff using autotools-dev Files: 54cfb85711af7e0a7f2f249ecda34f07 849 graphics optional autotrace_0.31.1-2.dsc 3d3a0dca75201b27c5822003e7b0ee50 278060 graphics optional autotrace_0.31.1-2.diff.gz d1c367b6a429d3cf972535fdb052362c 50922 graphics optional autotrace_0.31.1-2_i386.deb 546b482d1d8340547a8ef91604612e06 104252 libs optional libautotrace3_0.31.1-2_i386.deb a78d13dd1c826f10cc1bfb3b7f0aa2cc 126826 libdevel optional libautotrace-dev_0.31.1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/1kKbobE/LCyLGVoRAhTeAKC6m0KEdU1/07iBUz0u3wRevkkfBgCfRiyc RiaUl7kJj0/4xepHzDAlPMA= =/Xlh -END PGP SIGNATURE- Accepted: autotrace_0.31.1-2.diff.gz to pool/main/a/autotrace/autotrace_0.31.1-2.diff.gz autotrace_0.31.1-2.dsc to pool/main/a/autotrace/autotrace_0.31.1-2.dsc autotrace_0.31.1-2_i386.deb to pool/main/a/autotrace/autotrace_0.31.1-2_i386.deb libautotrace-dev_0.31.1-2_i386.deb to pool/main/a/autotrace/libautotrace-dev_0.31.1-2_i386.deb libautotrace3_0.31.1-2_i386.deb to pool/main/a/autotrace/libautotrace3_0.31.1-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted bibclean 2.11.4-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 6 Dec 2003 16:26:49 + Source: bibclean Binary: bibclean Architecture: source i386 Version: 2.11.4-2 Distribution: unstable Urgency: low Maintainer: Peter Makholm [EMAIL PROTECTED] Changed-By: Henning Makholm [EMAIL PROTECTED] Description: bibclean - pretty-printer for BibTeX databases Closes: 215863 Changes: bibclean (2.11.4-2) unstable; urgency=low . * Minor speling fixes (Closes: #215863) Files: 57c90b2eb620a74607434fc62f6a1196 574 tex optional bibclean_2.11.4-2.dsc 0796c65769fc515d24891cfed52a7210 22979 tex optional bibclean_2.11.4-2.diff.gz 749336520415bef6b6966dc60809234f 127890 tex optional bibclean_2.11.4-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/1j7NobE/LCyLGVoRAkxTAKCsLTGHgGMoEIE9CM9cCD+sckkmEwCfX7Ha Aqs/fpbDDX0EnI4pbyoI8g8= =4LNI -END PGP SIGNATURE- Accepted: bibclean_2.11.4-2.diff.gz to pool/main/b/bibclean/bibclean_2.11.4-2.diff.gz bibclean_2.11.4-2.dsc to pool/main/b/bibclean/bibclean_2.11.4-2.dsc bibclean_2.11.4-2_i386.deb to pool/main/b/bibclean/bibclean_2.11.4-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Revival of the signed debs discussion
Scripsit Goswin von Brederlow [EMAIL PROTECTED] If a package is compromised we can proof that the DD of the package either is malicious or incompetent. Say, we just had a major compromise on certain Debian machines. Pray tell, who do you think this proves is malicious or incompetent? We'd certainly want to toss out the culprit ASAP. -- 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.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Joey Hess [EMAIL PROTECTED] Mathieu Roy wrote: It doesn't need to be done in two days, does it? If new packages start directly with .desktop and others packages move to .desktop in the next year, it does not seems to be an awful load of extra work. If that happened then we would, for an undefined length of time that would probably span a Debian release, have two divergent sets of menus, with some programs randomly on the Debian menus, and some programs randomly on the free desktop menus. This would be unusable, and a bad regression. Evidently, so that's not what is proposed. The proposal is to enhance update-menus such that it knows how to parse .desktop files and feed the information from them transparently to menu methods that expect the Debian native format. Then debian-native menu systems would give the same user experience independently of which packages had transitioned to the .desktop format. Packages that uses the .desktop format natively already have maintainer scripts that know how to translate debianized menu entries into that. They may need some cooperation from update-menus in order to not show two entries for things that have .desktop entries of their own, but that is also minor. You speak of a transition, but I see no transition plan here. What do you expect from a transition plan then? Step 1a: Update menu infrastructure such that packages can transparently supply either .desktop files or Debian menu files. Step 1b: At the same time, update menu infrastructure such that WM packages providing menu methods can opt to receive package data in .desktop format (autotranslated from Debian menu files if necessary). Step 2: Packagers can now chose to supply .desktop files instead of the Debian format, with a versioned dependency on menu. Step 3: After a stable version with the updated infrastructure has been released, the Debian menufile format can be deprecated (should not happen before, because it would make backports harder). Step 4: When all (or most) menu methods have been converted to reading .desktop files, policy can be amended along the lines of *must* provide a .desktop file rather than the old Debian-specific menu format. Stem 5: Compatibility code for the old format in the menu infrastructure will be kept until it gets too much of a burden to maintain it. -- Henning MakholmWhat the hedgehog sang is not evidence.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Joey Hess [EMAIL PROTECTED] Henning Makholm wrote: The proposal is to enhance update-menus such that it knows how to parse .desktop files and feed the information from them transparently to menu methods that expect the Debian native format. The head of this thread is about someone asking several developers to drop .desktop files into their packages right now. Yes, so people got wiser along the way. Isn't that supposed to be what happens in these discussions? -- Henning MakholmWe can hope that this serious deficiency will be remedied in the final version of BibTeX, 1.0, which is expected to appear when the LaTeX 3.0 development is completed.
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
Scripsit Andrew Suffield [EMAIL PROTECTED] On Fri, Dec 05, 2003 at 08:05:34PM +, Henning Makholm wrote: Step 2: Packagers can now chose to supply .desktop files instead of the Debian format, with a versioned dependency on menu. I can see no reason to proceed any further than this. As far as I read this thread, the .desktop format is supposed to be able to encode more information and have better i18n than the Debian-native format. The underlying idea would be to reap the benefit of these capabilities for all packages with menu entries. There's basically two ways to do this: Migrate to .desktop or enhance the existing format. My sketch depicted the former. The idea of migration would seem to have the benefit of being directly compatible with the stuff non-Debian people produce. Absence of gratuitous differences in data formats across software and distributions is usually viewed as a Good Thing in itself; it is the Unix way of doing things, the Free Software way, and the insert-random-warm-and-fuzzy-buzzword-here way. This argument, of course, assumes that the differences between the (hypothetically enhanced) Debian syntax and the .desktop format *are* gratuitous. I don't know whether or not they are, but this thread does not seem to contain any replies to qestions of which technical advantages the Debian format has that .desktop hasn't, which would make a migration a Bad Thing, rather than just something that one personally doesn't want to spend time on. (Everyting resembling technical stuff above has been (mis)understood from this thread. I actually don't know much about the menu system; it doesn't seem to be available in a documented way to people who have their own $HOME/.fvwm2rc) -- Henning Makholm The trouble is that the chapter is entirely impenetrable. Its message is concealed behind not just thickets of formalism, but hedges, woods, and forests of formalism. There are whole pages with not even a paragraph break.
