Re: Why does Debian distributed firmware not need to be Depends: upon? [was Re: LCC and blobs]
su, 2005-01-09 kello 16:52 +0100, Miguel Gea Milvaques kirjoitti: > Then if software as xpdf could be in main, software loading firmware > must be in main. Without commenting on the issue otherwise: This is not a working analogy. xpdf can load any PDF file. Device drivers can, typically, only load firmwares that are specific to the device in question, and the only existing firmwares for the devices tend to be non-free. (Reply-To set to -project, since this is more on-topic there than here.)
Re: Bug#293167: ITP: request-tracker3.4 -- Extensible trouble-ticket tracking system
ti, 2005-02-01 kello 15:25 +, Stephen Quinney kirjoitti: > This is the 3.4 series of RT, it can be installed alongside the 3.0 > and 3.2 series without any problems. This release is a big > improvement over previous versions and features many new features, > substantial performance improvements and a significant cleanup and > restructuring of the codebase. What is the a reason every version series of Request Tracker needs to be packaged, instead of having a single request-tracker package that gets updated with newer versions? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Ipw2100-devel] debian, ipw2200 and wlan0
ma, 2005-02-07 kello 16:50 +0100, Mike Hommey kirjoitti: > Debian is a distribution which tries to provide good software, implying > changes if necessary. I completely agree with this. If changing a program makes it better, Debian should do it even if upstream doesn't. Such changes should be justified, of course; preferably explicitly. > Wireless interfaces should be called wlan%d, not eth%d Why is this important? Why does the name of a network interface matter? All the tools in Debian that can deal with network interfaces are neutral about the name and the name isn't particularly significant to users either. If one is worried about which interface name corresponds to which physical device, guessing from the name is not a good way. Using ifconfig or iwconfig or other tools to do it is a better way. (I'm not saying that using wlan%d is bad or wrong, I am asking for justifications for that name over eth%d.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: volunteering to help development
to, 2005-02-10 kello 18:23 -0800, Frederico Rodrigues Abraham kirjoitti: > hi. i want to help developing for debian. > how should i proceed? > i have experience with computer graphics and mathematical tools > programming, but most interested in the computer graphics field, in > which i'm completing my master thesis. The simple first step could be to look at http://bugs.debian.org and look for bugs that you can fix, possibly in packages that interest you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian-policy: Virtual package: change mp3-encoder with music-encoder
su, 2005-02-13 kello 01:22 +0200, Jesus Climent kirjoitti: > Having no mp3 encoder in the archive, due to possible patent problems, i > believe it would be a wiser idea to have "music-encoder" as a virtual package > than "mp3-encoder". Wouldn't it be necessary for this to work for all music encoders to have the same command line interface? I haven't used MP3 encoders for many years, but in their simple forms, I vaguely recall them to have been at least somewhat similar in their command line syntax. They also produce the same type of output. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#295328: general: Help messages to stderr should be banned
ti, 2005-02-15 kello 10:19 +0100, Marco d'Itri kirjoitti: > On Feb 15, Justin Pryzby <[EMAIL PROTECTED]> wrote: > > > I suppose I will start filing minor bugs against packages that do > > this. I'd like to hear other people's opinions, though. (It occurs > > to me that help output to stderr is arguably appropriate if an invalid > > option is given). Part of the problem is that its fairly depressing > WTF? This is a long-time UNIX tradition, I'd summarily close such a bug > opened on one of my packages. In my opinion, if you give a wrong option (or do some other syntax error on the command line), the proper thing to do is to give an error message, preferably short, saying what the error was and how to get the full help text. This is an error message, so it should go to the standard error output. When the user explicitly requests for a help text, it is not an error and should go to the standard output. GNU tools work like this already, and have, to the best of my knowledge, worked like this for well over a decade. Tools that behave differently are also fairly common, so I guess tradition isn't clearcut here. I do claim that the GNU way is the right way here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: (forw) Packages not using po-debconf - more active actions to come
ke, 2005-02-16 kello 11:00 +0100, Tollef Fog Heen kirjoitti: > .. as usual, please include maintainer names with package lists like > this. (And thanks for assembling the list. :) I seem to have written a little script for this (attached). I don't see a similar thing in devscripts. Is that the right place to look for one? Would it be useful to have mine there or is there something better out there somewhere? If so, I'll write a manual page and maybe improve the script a little bit. dd-list Description: application/python
Re: Bug#297629: ITP: gallery2 -- web-based photo album written in PHP
ti, 2005-03-01 kello 16:46 -0500, Michael Schultheiss kirjoitti: > Gallery2 (G2) has been redesigned from the ground up and is database > driven. Two years of design and development have gone into G2. It has > customizable themes and layouts using XHTML compliant templates which > make it much easier for you to personalize your G2 install. G2 is > modularized and features can be enabled and disabled separately for > maximum control. Is there any way to let people upgrade to Gallery2 from the original Gallery? If so, then we could do without having two packages in the archive and our users wouldn't have to have both installed, either. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with - and ' in some man-pages
ke, 2005-03-02 kello 22:45 +0100, Bernd Eckenfels kirjoitti: > In article <[EMAIL PROTECTED]> you wrote: > > Unicode. If people want to use Unicode, this is fine; > > Unicode and utf-8 exist to be used, after all. However, > > restricted character sets (mainly ascii and Latin-1) > > offer several real practical benefits > > I dont think it is fine to use the wrong character for options. The command > option character in the man page must be the same which is used at the > command line. If the manual page source says \- instead of - (as it properly should, so that when typeset for hardcopy output) then a proper ASCII minus character is printed. The problem occurs when manual pages use unescaped minuses in the input and groff thinks it should output Unicode characters for hyphens. For terminal output, I wish it wouldn't. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dehs will stop
su, 2005-03-06 kello 19:28 +0100, Thiemo Seufer kirjoitti: > Jeroen van Wolffelaar wrote: > > Do *not* file 6229 bugs about the same subject. Never. > > Why not? As wishlist bugs with patch this seems sensible to me. Denial of service attacks on the bug tracking system, on mailing lists, mail servers, and maintainers is unappreciated. 6229 bug reports would result in all sorts of unnecessary and unwanted load on all sorts of systems and people. It is because of reasons like these that mass-filing of bugs must always be discussed on debian-devel beforehand, so that the utility of the bug reports can be weighed against the load and disruption they cause. In this situation, I think it is clear that filing 6229 *wishlist* bugs is completely unwarranted. > If upstream doesn't publish tarballs, e.g. In this case there won't be > a meaningful patch for a watchfile. In any case it's up to the > maintainer to decide about its inclusion. I believe most of them will > accept such a patch. Having the watch information in the package means the information becomes stale: when the package is part of a Debian release the watch information won't get updated when the upstream web site moves, or the download URL changes, or whatever. Having a centralized database (say, part of package.debian.org) allows that information to be updated centrally, continuously, and also without disturbing a thousand developers with it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dehs will stop
su, 2005-03-06 kello 20:11 +0100, Thiemo Seufer kirjoitti: > Since preparation of the accompanying patches would take some time, > it is unlikely to cause "denial of service" or "disruption". If they are sent at a slow pace, then the disruption is less, it is true. It is still detrimental to have thousands upon thousands of wishlist bugs for something like this. We don't have lintian report bugs for all the errors it finds for the same reason (well, one of the reasons): the volume would be too much. Increasing the number of open bugs in Debian with 10-20% just for watch files, or any other non-critical issue, is not a good idea. > Yes, it adds some (small) maintenance burden. In case it was unclear: I am not talking about the burden on the package maintainer, that is small enough to not worry about. I am talking about information that will not be updated at all, even if the package maintainer wants it to be updated and provides a new package with the new information. There is no point in flooding a Debian stable release with new package versions that merely change a watch URL. > > Having a centralized database (say, > > part of package.debian.org) allows that information to be updated > > centrally, continuously, and also without disturbing a thousand > > developers with it. > > Do you really expect such a centralized database would be updated > more consistently? By whom? Given that the distributed version won't be updated at all, there is a chance that a centralized database will be more up to date. Making it easy to update by, for example, providing a simple web interface that lets any DD log in and update any watch url should make it pretty likely that it actually happens. If Wikipedia can do it for tens of thousands of articles, surely we can do it for a few thousand URLs. (Or you can lobby for a virtual package in the bug tracking system and have people write bug reports when they notice a broken URL, and have a team dedicated to checking the URLs and updating the database. Or have a mail bot a la the one for db.debian.org. Or a structured wiki site.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dehs will stop
su, 2005-03-06 kello 21:09 +0100, Thiemo Seufer kirjoitti: > We don't talk about automated bug filing here. We're talking about filing over 6000 bugs for watch files. It may not be automated, but it is mass-filing. It doesn't matter if it takes weeks or months, it is still not a good idea. That is what I am primarily objecting to, and what I understand Jeroen also to be objecting to. Since there is no consensus, as far as I can see, that putting watch files into packages is a good thing, mass-filing bugs is a really bad idea. > If somebody writes > patches to fix (valid) lintian problems it is IMHO clearly legitimate > to file that as a wishlist bug. Of course there are bogus Lintian > triggers, this needs to be taken into account. Fixing packages one by one is not mass-filing bugs. > Why would it be impossible for the maintainer to update the watchfile > in his package? Getting the updated package into stable is the point. > And, just to point out the obvious, watch files are supposed to help > with development of new versions of a package. There's simply no point > to care about them aside from the one in the newest package. Packages in stable may be missing from unstable, or have a different name in unstable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NPTL and static linking
ti, 2005-03-08 kello 13:00 -0800, Blunt Jackson kirjoitti: > Does anyone know if this is an intentional decision on the part of the > glibc/nptl crew to refuse to support static linking of the pthreads > library (perhaps due to ongoing development)? I don't know the answer to your exact question, but I have general comment that might be useful as well. The glibc upstream maintainers have been against static linking for some years now, for reasons that seem valid, but which I forget now. I think there are problems with at least nss (name service switch), which requires dynamic linking. They don't really guarantee that static linking works for anything, even if doesn't use threads at all. See archives of the glibc-alpha mailing list, on for example http://dir.gmane.org/gmane.comp.lib.glibc.alpha, for more information. Asking them on the list is probably not a good idea, however. The FAQ in /usr/share/doc/libc6 is probably useful as well. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
manpages-zh/cman
ma, 2005-03-14 kello 13:42 +, Martin Michlmayr kirjoitti: > Anthony told me over dinner that people interested in adopting his > packages can go ahead. So please consider this an invitation to adopt > lilypond if you're serious about maintaining it. In this context, I'd like to point out the release critical bug that has removed manpages-zh from sid (though it is still in sarge): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=267236 To re-cap, manpages-zh had a source package cman, then a new package cman was uploaded with the same source package name, so it was treated as a new version of the old source package, removing manpages-zh from sid. Fixing this requires re-packaging either cman (the binary package) or manpages-zh. If the former is re-packaged, then the latter needs to be re-uploaded as well, so it gets back to sid. It might therefore be easiest to re-package manpages-zh. Any opinions? Anyone who understands Chinese willing to do the packaging? (I don't understand Chinese. I might be willing to sponsor an upload, but even that would be best done by someone who understands Chinese.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shall Debian's su conform to other implementations
Loudly promoting my own software here... la, 2005-11-12 kello 10:39 -0200, Henrique de Moraes Holschuh kirjoitti: > On Sat, 12 Nov 2005, Steve Langasek wrote: > > > Besides, depends/pre-depends and conflicts should be more than enough if > > > done right. > > > > Yes, this is what is meant by supporting partial upgrades. "Supporting > > Ah, ok. THAT is what I meant too, in a roundabout way. So we're in > agreement. > > > partial upgrades" doesn't mean "any given package should be upgradable on > > its own without upgrading any others"; it means "no apt-get install command > > should be able to break the system". > > Too bad this isn't really true, it is usually a bad idea to mix > oldstable+stable for more time than what is strictly necessary to upgrade > the entire system to stable. Not all dependencies are always correctly > expressed as versioned dependencies metadata. So you can get breakages that > the maintainers don't know about and would never test for explicitly. > > The people doing backports actually help a LOT to track down these bugs as > they happen :-) Another that developers can do is this: sudo piuparts -d sarge -d etch -d sid -al foo.log foo where foo is the name of their package. This needs a fairly fast access to a mirror, however, but that can be somewhat avoided by creating a chroot snapshot (see options -b and -s). I'm running this on all packages in sid, and filing bugs about any problems I find, but it does take time and it would be preferable that package maintainers who can do it themselves do so. Of course, what piuparts tests is not a complete test of all the functionality of the package, only that the basics of installation, upgrade, and removal work. Wait for version 2, please. :) -- Fundamental truth #4: Typing URLs always introduces errors. Always copy +paste. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Checksumming tool
ma, 2005-11-28 kello 19:07 +1000, Anthony Towns kirjoitti:
> Hrm, if we're writing our own thing, maybe we should do it properly:
> have a single program that can do multiple hash algorithms, have the
> default hash be secure, and update it in future, and so on.
As it happens, I've been wanting a really nice checksum program for a
couple of years now. When I burn a CD or DVD with files, I put a
checksum file ("md5sum.txt" usually) at the root, so that I can easily
check that the disk is still working years later. It would be nice to
not have a zillion different, incompatible checksum tools.
The md5sum program isn't very user friendly and my main motivation has
been for more usability (feedback of how long the check will still take,
and stuff like that). I have, however, also thought about other checksum
algorithms than MD5, and about a format that is extensible enough that
it won't need to be changed every time the algorithm changes. A few
thoughts:
1. Definitely use URL encoding for filenames. It's cheap, well
known, and usually not needed (% being a nicely rare character),
and sometimes it really is important to be able to deal with
pathnames with weird characters.
2. A little bit of verbosity doesn't add very much to the file
size, and will make dealing with the files much easier.
3. Who knows what else one might want in the file later.
4. md5sum and sha1sum compatibility is pretty much required for
the new tool. It makes the transition tolerable. I don't feel
new files need to be backwards compatible by default, however.
The best I've come up with so far is a pseudo rfc822 syntax:
File: foo%20bar/hellurei.txt
Size: 12345
MD5: 012345667
SHA-256: 0a0a0a0a0a0a0a0a0a0a0a0a
Mode: 0644
Empty lines separate blocks of "headers" for different files. This
should all be very simple to use and immediately logical and familiar to
anyone who'se seen e-mail headers.
It would be cool for file(1) or GNOME's and KDE's MIME type heuristics
to easily recognize the format, so that (eventually) a GUI tool can be
written to deal with such files.
I put an old draft of the manual page for my work-in-progress tool at
http://liw.iki.fi/liw/temp/summain.txt and the bzr (a.k.a. bazaar-ng)
repository at http://liw.iki.fi/liw/bzr/ in case anyone is interested. I
don't have all that much code (this being a project I hack on whenever I
don't have anything useful to do, like reading Debian mailing lists). It
tends to get rewritten every now and then (happiness is going NIH on
your own code). It shouldn't take that much effort to write the tool, so
most of my efforts have gone into thinking about the exactly correct
command line user interface features, and about the prettiest
implementation design.
I also write it in Python, and a pure C version would probably be
preferable for Debian's purposes. The file format is more important at
this point, though, and any sensible file format should be quite simple
to support in any language.
--
The most difficult thing in programming is to be simple and
straightforward.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Checksumming tool
ma, 2005-11-28 kello 18:20 -0600, Adam Heath kirjoitti: > On Mon, 28 Nov 2005, Lars Wirzenius wrote: > > > File: foo%20bar/hellurei.txt > > Size: 12345 > > MD5: 012345667 > > SHA-256: 0a0a0a0a0a0a0a0a0a0a0a0a > > Mode: 0644 > > Checksum: > md5: 0123456789[B > sha-256: 0a0a0a0a0a0a0a0a0a0a0a0a > > Having the names of the checksums be the header names could lead to clashes. That's a point. I think I'd leave out the colon after the checksum name, or possibly change it to an equals sign: Checksum: md5=123123123123123 sha-256=aaffaaffaaffaaffaaff Those are pretty small details, though, I could easily live with any of these. -- sic transit discus mundi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intel notebooks for needy developers in developing countries
la, 2005-12-10 kello 10:39 +0100, Daniel Baumann kirjoitti: > Christian Perrier wrote: > > We (Debian developers and contributors) certainly all agree on this > > (or, at least, the vast majority of us). > > Why then being so complicated? If there is a candidate in a country > doomed by US export laws, 'export' the notebook first to someone other > and ship if afterwards to Cuba. If the US law enforcement people learn about it, they will quite probably interpret it as an attempt to circumvent US laws, and act accordingly. That's a pretty fair interpretation, of course, since that is exactly what is going on. I don't like those laws, but publically urging people to violate them isn't going to do anyone any good. -- (def (reverse items) (accumulate (fn (so-far x) (cons x so-far)) nil items)) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
su, 2005-12-18 kello 13:38 -0500, Joey Hess kirjoitti: > One argument I can think of for keeping nvi in base is that it is the > closest to bug-compatible with the original vi. However, I don't think > that will prevent hardcore vi users from easily using vim-tiny if > it's in base. I'm one of the people who prefers nvi over vim. I do so quite strongly, because I find that nvi obeys my fingers and vim does not. The differences are minute, of course, but they are really irritating. Unfortunately, I can't enlist them properly, since my fingers don't talk to me: I notice vim's incompatibility from the fact that my fingers have to keep correcting text under vim, but not under nvi. On days when I'm generally annoyed already, if I accidentally use vim instead of nvi, I can get quite lyrical with my cursing. I'm not bothered at all by switching nvi with vim-tiny in base. As long as I can install nvi if I want to, I'm happy. I'd even be happy without any vi-like editor in base. As long as there is one editor in base that I can without great difficulty in an emergency (nano seems to qualify), I don't need anything more. In fact, given that it's good for base to be small, I'd like to suggest that we don't have more than one editor there. -- The most difficult thing in programming is to be simple and straightforward. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
su, 2005-12-18 kello 20:17 +0100, Norbert Tretkowski kirjoitti: > * Lars Wirzenius wrote: > > In fact, given that it's good for base to be small, I'd like to > > suggest that we don't have more than one editor there. > > We already have two editors in the base system, nvi and nano. Yes, that being the bloat I was referring to. -- C is the *wrong* language for your application. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run (was: Please test new sysvinit)
su, 2005-12-18 kello 20:18 +0100, Marco d'Itri kirjoitti: > > Sounds it sounds to me like it is a bad idea to use it. > Only because you have no clue of what you are talking about. Marco, would please keep the discussion technical, and not attack the people taking part, even if you think they're wrong? Concentrating on the issues is productive, discussing people isn't, in the long run. -- Never underestimate the power of a small tactical Lisp interpreter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
su, 2005-12-18 kello 14:57 -0500, Joey Hess kirjoitti: > Yeah, I understand the feeling (coming at it from the exact opposite > side). It would be helpful if there were an analysis of the major differences > somewhere; the ones I am most aware of incude: I'm not personally very interested in this. If the size of vim-tiny is not bigger than nvi, I really couldn't care less which one is the default. Either is good enough as a vi clone for base; the incompatibilities are small enough not to matter for that case. I don't want to spend any effort (again, personally) in convincing people to switch their preferred editor, or preferred vi clone. That being said, I'd like to point out the minor error in the list you wrote so far: > - vim supports multiple levels of undo; in nvi the second undo undoes your >undo In nvi, to undo more than one level, you use the "repeat last edit" command (bound to period); "u" undoes an undo (and period after that repeats, so undoes further undos). For some people this is quite logical, and it drives other people nuts. > IIRC the reason we have a vi in base, and at priority important at that > is because of the definition in policy that: > > `important' > Important programs, including those which one would expect to > find on any Unix-like system. If the expectation is that an > experienced Unix person who found it missing would say "What on > earth is going on, where is `foo'?", it must be an `important' > package. > > Which of course includes a vi. (Note that the paragraph goes on to explicitly > rule out emacs.) In the name of reducing base's size, I would support a policy change here, excempting vi clones, but I suspect I'd be shouted down. Personally, I think "standard" would be the appropriate priority for for the vi clone. -- Fundamental truth #2: Attitude is usually more important than skills. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: Bug#343662: fsck errors halting boot after upgrade]
ma, 2005-12-19 kello 10:21 -0500, Theodore Ts'o kirjoitti: > Specifically, what I would propose is /etc/localtime.conf contain > something like "US/Eastern", and let /etc/zoneinfo be a copy of the > file /usr/share/zoneinfo/`cat /etc/zoneinfo`. > > Does anyone have any objections with this proposal? I think it sounds quite acceptable. The (compiled) time zone data files are pretty small (there's just a lot of them, and the each use a disk block). -- Yet another quit message no-one will ever comment on. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Thoughts on Debian quality, including automated testing
Subject: Thoughts on Debian quality, including automated testing [ I'm subscribed to -devel, no Cc required. I apologize for the length, but it's only a bit over 3000 words. I hope the section titles help, if you want to skip parts. ] For some time now I have been thinking about ways to make Debian better from a technical point of view. Most of my actual efforts have gone into writing piuparts[1], running it against packages in the archive, and reporting any problems. I have also spent some time to think about related issues. [1] http://packages.debian.org/unstable/devel/piuparts This mail is primarily prompted by Ian Jackson's proposal[2] to specify a framework for automated testing. I meant to write and send it weeks ago, but for various reasons, I kept postponing finishing it. Sorry about that. Part of the reason is that as I kept thinking and writing about this, I kept expanding the scope. As a result, this mail is quite long. Sorry about that, too. Further, I keep mentioning piuparts in this mail. Sorry if it seems like I'm advertising it. I'll start by saying that I fully support writing automated tests for Debian packages. Automated tests can do very good things to development of single programs. They can also do so to Debian packages, and Debian as a whole. [2] http://lists.debian.org/debian-project/2005/11/msg00073.html and other threads Before I get down to details, I'd like to be a bit philosophical and preachy. You may want to skip a few paragraphs. The quality of Debian is not bad at all. Debian works quite well for a large number of people, and we get fairly few bug reports from them relative to the number of programs we have packaged. That's pretty much the only objective criterion we can currently use to determine real quality. Quality is sometimes hard to define. I claim that "package has few bug reports in proportion to its user base" is one important indicator of high quality. Still, we could do much better. Our two best known quality assurance tools, lintian and linda, are obviously not used by a lot of package maintainers[4], given the number of packages that have problems. Consider, for example, lintian's test for zero-byte files in the doc directory[5]. There are a hundred packages that fail that test. Yet the problem is really utterly simple to fix. [4] http://lintian.debian.org/reports/tags.html [5] http://lintian.debian.org/reports/Tzero-byte-file-in-doc-directory.html These zero-byte files are not a "real" problem: they use up an inode, and make people spend a few seconds extra when looking for information about the package, but they don't actually break anything. Yet the packages in question would be of higher quality if they were non-empty or didn't exist at all. They may also indicate other sloppiness, which may or may not be caught with automatic tools. Sloppiness tends to result in real problems sooner or later. I propose "respected automated tools find few problems" as the second indicator of quality. To improve the quality of Debian, we need to do several things: A) Prevent bugs from happening in the first place B) Find and report bugs C) Fix bugs that have been reported D) Prevent bugs from entering the archive I will now discuss each of these things. After that I'll finally get to discussing automated testing the way Ian Jackson proposed it. A) Prevent bugs from happening in the first place = In general, the way to prevent bugs from happening at all is by reducing complexity. Simple things are easier to get right. Most programmers find that using tools with higher abstraction levels reduces complexity and the number of bugs they create for a given task. As an example, writing the shell command "cat *.txt > all.dat" much more likely to work correctly than writing the same program in C, where you would have to open and read and write files yourself, checking for errors, etc. In a Debian packaging context, this might mean using packaging helpers to take care of the boring, repetitive chores that are the same from one package to the next. For example, debhelper is pretty good at reducing the debian/rules file to just a handful of simple invocations of the individual debhelper tool programs. Each invocation is very simple. Very simple bits of code are usually correct. Result: fewer bugs in packages and in Debian. Debhelper is a very good thing indeed. I'm not saying that using debhelper, or another packaging helper, should be mandatory. They are merely one way of reducing the probability of bugs, and because of that, I am happy that most packages in Debian do use them. On the whole, our quality is better thanks to that. If you can make bug free packages, by all means don't use a helper (I don't, my packages are simple enough as they are). There are other ways of combating complexity. Picking sensible defaults and not making the package
Re: Thoughts on Debian quality, including automated testing
ke, 2005-12-21 kello 10:28 +, Roger Leigh kirjoitti: > For this task, you might find schroot(1) useful. It's a means of > accessing chroot environments, but it supports LVM snapshots as one > method. Does this require the user to set up LVM somehow before using schroot? > This is a very quick method to create and destroy a test > environment (on my system, 2 seconds to create and 5 to destroy). For me, unpacking a tar file takes about 4 seconds (from a cold cache, machine had just been rebooted) and afterwards less than a second to remove (but then it was all in the cache). This is a small part of the whole process, which for piuparts can take several minutes, if it tests upgrades from stable via testing to unstable. -- Debian is a beast that speaks with many voices -- R.B. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
ke, 2005-12-21 kello 14:19 +, Roger Leigh kirjoitti: > The difference for a minimal chroot is not too great. The main > advantage of schroot LVM snapshotting is that the time is constant > irrespective of the size of the LV (it's copy-on-write), whereas for > tar it is linear. For slow machines and older architectures, this is > an advantage. Right. I'll postpone adding support for this until later, then. For the time being, I assume piuparts will mostly be run on relatively fast machines. Once slow machines become more relevant for piuparts, I'll return to this issue and will look at schroot in more detail. Thanks for pointing it out, I didn't know about it before. (Likewise, UML/Xen support will probably happen only later.) -- Never underestimate the power of a small tactical Lisp interpreter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
to, 2005-12-22 kello 10:20 +, Jon Dowland kirjoitti: > On Sun, Dec 18, 2005 at 09:29:24PM +0200, Lars Wirzenius wrote: > > su, 2005-12-18 kello 20:17 +0100, Norbert Tretkowski kirjoitti: > > > We already have two editors in the base system, nvi and nano. > > > > Yes, that being the bloat I was referring to. > > I think there should be at least one non-modal editor in base. Behold the awesome non-modality of nano. -- Boilerplate programming mean tools lack power. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian control field "depends"
ti, 2005-12-27 kello 20:56 +0100, Florian Ludwig kirjoitti: > Hello,... > > a short question: > has there to be a space between each dependes in the control field? > > i thought so and field in a bugreport [1] and didnt get an answer jet... > > florian ludwig > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=344344 >From the Policy Manual, 7.1 Syntax of relationship fields: Whitespace may appear at any point in the version specification subject to the rules in Syntax of control files, Section 5.1, and must appear where it's necessary to disambiguate; it is not otherwise significant. For consistency and in case of future changes to dpkg it is recommended that a single space be used after a version relationship and before a version number; it is also conventional to put a single space after each comma, on either side of each vertical bar, and before each open parenthesis. In other words, I don't think a space is necessary after the comma, but it's certainly nice (makes reading easier, if nothing else). -- Cameras don't shoot people. People shoot people. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian control field "depends"
ke, 2005-12-28 kello 10:59 +0100, Florian Ludwig kirjoitti: > There are some other packets with the same 'bug' - so i can fill a > wishlist report? Since it is not really a bug, I'd rather you didn't file bugs about it. The constructive thing would be to write a new test for lintian and/or linda so that they warn about it. -- Just GNU it! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian control field "depends"
ke, 2005-12-28 kello 13:48 +0100, Marc 'HE' Brockschmidt kirjoitti: > Lars Wirzenius <[EMAIL PROTECTED]> writes: > > ke, 2005-12-28 kello 10:59 +0100, Florian Ludwig kirjoitti: > >> There are some other packets with the same 'bug' - so i can fill a > >> wishlist report? > > Since it is not really a bug, I'd rather you didn't file bugs about it. > > The constructive thing would be to write a new test for lintian and/or > > linda so that they warn about it. > > I would not want lintian to warn about this issue, it's simply not a > problem. I would, because I would want to fix it if it happened to my package. Possibly a warning is too strong, Perhaps it could be disabled by default, or something. -- Pity the sysadmin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: switching to vim-tiny for standard vi?
to, 2005-12-29 kello 11:01 +0100, Toni Mueller kirjoitti: > I'm not used to nano, but the editor in base expected to be used for > working on system config files is imho required to respect tabs and eg. > *not* convert them to spaces unless told to do so, and also provide > means to enter new tabs. Does nano not do that for you? -- Pity the sysadmin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dependencies on makedev
to, 2005-12-29 kello 13:39 +0100, Marco d'Itri kirjoitti: > To prepare for the eventual removal of makedev, I propose that packages > currently depending on it will add an alternative dependency to udev. > Also, policy should be amended accordingly. > > The affected packages are: This is the same list, run through dd-list (from devscripts) to make it easier to find yourself (helpful for those who have lots of packages): Martin Albert <[EMAIL PROTECTED]> libggi Richard Atterer <[EMAIL PROTECTED]> udftools Julien BLACHE <[EMAIL PROTECTED]> sane-backends Edward Betts <[EMAIL PROTECTED]> joystick Markus Braun <[EMAIL PROTECTED]> tpb Mark Brown <[EMAIL PROTECTED]> powertweak x86info Giacomo Catenazzi <[EMAIL PROTECTED]> microcode.ctl Ben Collins <[EMAIL PROTECTED]> libraw1394 Hector Garcia <[EMAIL PROTECTED]> xcdroast Chris Hanson <[EMAIL PROTECTED]> powermgmt-base Thomas Hood <[EMAIL PROTECTED]> mwavem thinkpad Alberto Gonzalez Iniesta <[EMAIL PROTECTED]> irda-utils Aurelien Jarno <[EMAIL PROTECTED]> camstream lm-sensors Joerg Jaspert <[EMAIL PROTECTED]> cdrtools Guillem Jover <[EMAIL PROTECTED]> fbset Rene Mayrhofer <[EMAIL PROTECTED]> openswan Rene Mayrhofer <[EMAIL PROTECTED]> gibraltar-bootcd Michael Meskes <[EMAIL PROTECTED]> watchdog Andreas Rottmann <[EMAIL PROTECTED]> alevt Roberto C. Sanchez <[EMAIL PROTECTED]> toshutils David Schleef <[EMAIL PROTECTED]> comedilib Paul Slootman <[EMAIL PROTECTED]> isdnutils Joop Stakenborg <[EMAIL PROTECTED]> z8530-utils2 Debian VDR Team <[EMAIL PROTECTED]> linuxtv-dvb-apps nvram-wakeup vdr James Troup <[EMAIL PROTECTED]> gnupg Matthias Urlichs <[EMAIL PROTECTED]> gnupg2 Matt Zimmerman <[EMAIL PROTECTED]> uml-utilities Marco d'Itri <[EMAIL PROTECTED]> ppp Debian/Ubuntu mdadm maintainers <[EMAIL PROTECTED]> mdadm -- Fundamental truth #1: Complexity is the enemy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
ke, 2005-12-28 kello 02:00 +0100, Moritz Muehlenhoff kirjoitti: > Why don't we add a status field into the PTS, where a maintainer > can denote her "NMU policy" for a given source package? E.g. > a selection box, ranging from "Don't dare to touch this, I bite" > to "Feel free to 0d-NMU for every severity as long a you send the > patch". Or a free-form field, if that doesn't suffice. I started a list on wiki.debian.org for people who welcome low threshold NMUs for their packages. http://wiki.debian.org/LowThresholdNmu -- When in doubt, use brute force. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dependencies on makedev
pe, 2005-12-30 kello 09:34 +0100, Wouter Verhelst kirjoitti: > On Fri, Dec 30, 2005 at 05:31:09PM +1000, Anthony Towns wrote: > > On Fri, Dec 30, 2005 at 12:40:37AM -0600, Adam Heath wrote: > > > > Indeed. Editing plain text configuration files has never been the Unix > > > > way, and vi certainly isn't a standard unix tool. > > > No, I'm saying why are people attempting to replace what already works > > > with > > > something new and obfusicated? > [...] > > Though I have to say, that was a pretty amusing remark coming from one > > of the upstream authors of "shoop". > > shoop never replaced anything. Oh dear, I've been hoping it would replace C++. -- Pink timeout -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to Increase Contributions from Volunteers
ma, 2006-01-02 kello 09:03 +0100, Andreas Fester kirjoitti: > You are already a Maintainer as soon as you have a package > in the archive. Speaking of an "official title" as you suggested, > maybe something like the following stages could be reasonable: I find your title unambitious and suggest improvements. > - - Having at least one package in the archive: "Debian Maintainer" "Debian Vice President for Packaging Foo" > - - Having more packages in the archive, having contributed > patches (probably also to the base Debian system), > etc.: "Debian Contributor" "Debian Distinguished Fellow" > - - Being "Debian Contributor" for some time, having bug-free > packages, having shown continous activity, and fulfilling > all other requirements which are already necessary today: > "Debian Developer" "Debian Chairman of the Bored" (No, I don't really think titles will attract most of the productive kind contributors to Debian. Sorry.) -- It doesn't matter who you are, it's what you do that takes you far. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian for desktop - gnome in usnstable/experimantal more stable than in testing ?
ma, 2006-01-02 kello 22:16 -0500, Benjamin Mesing kirjoitti: > I admit I was imprecise, often it are conflicts (usually through library > stuff) that prevent packages from being installable when you have > certain other installed, even though you would want both. > But as mentioned I am only repeating the experiences of other users, I > never went with testing. It is best not to repeat rumors, or we'll never shut up. > Btw. can a package libterminal version 10 propagate to testing if > package myterm in testing depends on libterminal (<= 9)? Otherwise this > _could_ break the dependencies. The testing distribution is all about not adding packages if it breaks other packages. The determination of "breaks other packages" is done primarily by checking dependencies. As long as dependencies are correct, things won't break when packages in testing are updated or new packages are added, or packages are removed. (Except in exception circumstances, of course. Exceptions are not routine, though.) See http://www.debian.org/devel/testing for more detailed information. > But for example I can speak for my package (packagesearch) which broke, > when xterm changed how it handles command line arguments. Of course I > didn't knew this before, so my package depended on "xterm" (instead of > xterm<=x.y.z). After xterm was changed, it could propagate to testing, > breaking my package. That was a case where dependencies were insufficiently correct. > However due to the QT library transition my package > which I fixed in unstable at once has not entered testing yet... Propagation of packages into testing sometimes does sometimes take a long time, precisely because testing has been designed to avoid random breakage when packages are updated. Working on getting the Qt library transition over as quickly as possible is probably the best way to shorten the delay in this particular instance. -- Teaching: the proof is in the doing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345160: ITP: libgpod -- a library to read and write songs and artwork to an iPod
ti, 2006-01-03 kello 21:06 +0100, Josselin Mouette kirjoitti: > Le vendredi 30 décembre 2005 à 17:55 +0100, Mike Hommey a écrit : > > Something troubles me. You make unofficial packages while waiting for > > official > > packages. Aren't you DD ? Wouldn't uploading these unofficial packages > > in unstable make them official ? > > I don't think we need more packages maintained by Christian Marillat. We could do with fewer character assassinations, too. -- Pity the sysadmin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advices, comments? Bug#345651: passwd package should be essential?
pe, 2006-01-06 kello 18:38 +0100, Christian Perrier kirjoitti: > From: Kurt Roeckx <[EMAIL PROTECTED]> > > There are several things in the package that one might > want to run from one of the maintainer scripts from > debconf, like useradd, groupadd, userdel, ... Is there a problem with packages that need stuff from passwd simply depending on passwd? -- Fundamental truth #4: Typing URLs always introduces errors. Always copy +paste. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
ma, 2006-01-09 kello 21:15 +, Simon Huggins kirjoitti: > On Mon, Jan 09, 2006 at 07:20:46PM +0100, Bill Allombert wrote: > > Debian Xfce Maintainers <[EMAIL PROTECTED]> > > xfce4-mixer > > xfce4-mixer-alsa > > xfce4-mixer-oss > > Can you remind me why circular dependencies are so terrible? > > These packages install fine and upgraded fine. What did we miss? One things, if I've understood things correctly, is that it is not possible to reliably know how they're going to be removed -- dpkg will break the circle in a random place and this may or may not result in problems at the removal stage, depending on what the package does when being removed in various scenarios. Without circular dependencies, things are simpler and easier, since things happen in more deterministic ways. I don't know if that is sufficient reason to get rid of circular dependencies. -- On IRC, we sometimes like to watch silence. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Wig & Pen -- new source format roadmap?
su, 2006-01-15 kello 20:21 +, Mark Brown kirjoitti: > Deploying Wig & Pen would also help, of course. Speaking of which: what needs to happen for Wig & Pen (the new source format) to be usable? Is it possible to get it to happen within etch? What can we do to help with this? -- Those who do, decide. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
su, 2006-01-29 kello 04:35 +0100, Josselin Mouette kirjoitti: > Le samedi 28 janvier 2006 à 21:16 -0600, Manoj Srivastava a écrit : > > God. Is this supposed to be rational technical discussion, or > > an exercise in jejune mud slinging. > > Deliberate use of words a non-native English speaker cannot understand > won't help your argumentation. Language war bad. Bad. Bad language war. Bad, bad, bad. Language war: bad. No language war. No, no, no. No bad language war. Stop language war. Stop - language - war. Stop. Stop, stop, stop, stop, stop. Bad language war stop. Now. Stop bad language war now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
Thomas, how does responding to a flamey thread that had already died a week and a half earlier make anything better? (It doesn't even matter that the point had already been made.) Debian has a tendency to have many or most of its mailing list discussion turn into flame wars, and this is bad, because it deters people with constructive input from participating. If we are to ever improve the situation the least we can do is to not respond to mails in flame wars that have already died. Preferably, not responding to flame mails at all, but let's start with a small step. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: documentation types
pe, 2006-02-10 kello 07:36 -0500, Neil Roeth kirjoitti: > On Feb 10, Hendrik Sattler ([EMAIL PROTECTED]) wrote: > > I about packaging a library that ships an API reference in docbook SGML > and > > provides manual build targets for PDF, PS and HTML. > > > > Is there any preference on which type should be included in the -dev > package? > > I would prefer PDF: > > * one file only > > * easy to print > > * many viewers available > > Could it be a configure option, so that the first time the package is > installed it would ask which subset of the three to install (defaulting to PDF > only), and later, when upgrading the package, it would install the same > subset with no further interaction? This has been discussed a long time ago and there is a policy decided. >From the Policy Manual: 12.4 Preferred documentation formats The unification of Debian documentation is being carried out via HTML. If your package comes with extensive documentation in a markup format that can be converted to various other formats you should if possible ship HTML versions in a binary package, in the directory /usr/share/doc/appropriate-package or its subdirectories.[76] Other formats such as PostScript may be provided at the package maintainer's discretion. Thus the thing to do is to provide HTML. It would be nice to be able to ship, say, HTML and SGML, and then have a quick and easy way to generate other formats (PS/PDF for various paper sizes, at least) from the SGML, and anyone who creates the tools to do that will get a lot of goodwill. -- One does not see anything until one sees its beauty. -- O.W. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#352303: ITP: gsynaptics -- configuration tool for Synaptics touchpad driver of X
la, 2006-02-11 kello 13:30 +0900, Osamu Aoki kirjoitti: > GSynaptics is a configuration tool for Synaptics touchpad driver > of X server. Before you use this package, please read > /usr/share/doc/gsynaptics/README and configure X server properly. "Properly" is a bad word to use in this context, since the configuration in question seems to result in a potential security problem. From the xfree86-driver-synaptics README.Debian file: If you want to be able to change driver parameters without restarting the X server, enable the "SHMConfig" option in the X configuration file. You can then use the "synclient" program to query and modify driver parameters on the fly. SECURITY NOTE! This is not secure if you are in an untrusted multiuser environment. All local users can change the parameters at any time. I think it would be fair to add a similar note to the description of the gsynaptics package. Note that I'm not saying that this is a serious problem with the package: in many situations it does not matter if the touchpad settings can be changed by any local user. For example, on a laptop with only a single user account, or with many accounts but no way to log in via a network. These can be an acceptable risk for the ease of configuration. It is, however, important to notify the person installing the package about the issue. -- Even a bad picture is worth 500 words. --Droidy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#352535: ITP: gitmail -- Very simple graphical mail user agent for sending mail (GTK)
ma, 2006-02-13 kello 23:00 +0100, Adeodato Simó kirjoitti:
> * Adeodato Simó [Mon, 13 Feb 2006 22:58:24 +0100]:
>
> > And it may fall under the "too buggy that we refuse to support it"
>
> Ah, forgot to say that the code is, at least, full of malloc(FIXED_NUM),
> that afterwards get used without any check for errors.
As an example:
GList *readfile (char *file, GtkWidget *comboboxentry) {
char *homedir = (char*)malloc(1024);
strcpy (homedir, g_get_home_dir());
There are at least two big problems with this code:
1) It does not check that the malloc succeeds, resulting in a
segmentation fault on the next line if malloc fails. It would be better
to bail out with a clear error message to the user; it is arguably OK to
not try to do anything fancier to recover from the problem: if you can't
allocate even one kilobyte, it is questionable what you can do at all.
(GTK+ has ready-made functions for this.)
2) There is no guarantee that 1024 bytes is enough to make a copy of the
path to the home directory. In this case, it is pretty unlikely that the
problem ever occurs, but if it does, then you're screwed.
That example was the first I found. The code is indeed full of them.
>From the same function:
char *buffer = (char*) malloc (1);
int len;
len = read (fd, buffer, SSIZE_MAX);
Apart from the lack of checking whether malloc succeeds, SSIZE_MAX is
(much) greater than ten thousand, and any file bigger than about ten
kilobytes will cause this to happen. Files bigger than ten kilobytes are
pretty common. This particular function is now only being used to read
something that looks like config files, but for the sake of sanity,
security, and safety, it is not OK to assume they will always be less
than ten kilobytes.
I'd say that the code is not ready to be included in Debian. It needs a
very careful code review first.
While we do have some pretty crappy programs in Debian already, let's
try to avoid adding programs with known big problems, and now we know
about this one.
If the program does get reviewed, and all the problems that are found
get fixed, then I have no objection to the package.
--
The road is wide and the sky is tall, before I die I will see it
all.--H.A.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Recommending an image viewer
ti, 2006-02-14 kello 16:28 +0100, Henning Makholm kirjoitti: > Does anybody have a better idea than trying (in vain) to keep myself > informed about the supply of image viewers in unstable and adjust the > dependencies appropriately? Something similar to sensible-browser or such would sort of suggest itself. That is, a command (/usr/bin/sensible-image-viewer) that uses alternatives or some other mechanism to determine which image viewer to start. Image viewer packages would have to be modified to maintain the alternative, and I'm not sure if the effort is worth it. Would such a sensible-image-viewer command be useful for other packages than xcftools? -- Don't break the chain: send to 5 others on irc and send liw $1 or get bad luck -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#352912: general: Reduce network load using zip packaging and VFS
ke, 2006-02-15 kello 04:00 +0500, Victor Porton kirjoitti:
> Here is my plan how to reduce Debian servers load and users Debian packages
> download bandwidth:
>
> 1. Package in .zip (or a similar format) instead of .tar.{gz,bz2}
Picking a random package:
-rw-rw-r-- 1 liw liw 18113820 Mar 18 2005 emacs21_21.4a.orig.tar.gz
-rw-rw-r-- 1 liw liw 19544036 Feb 15 10:26 emacs21_21.4a.orig.zip
The .zip is almost 8% larger than the .tar.gz. This is, in fact, pretty
typical, because a .zip compresses each file separately and a .tar.gz
compresses all the files as one, so that similarities between files
reduce the total size.
(Once we use .tar.bz2, the sizes will be even smaller.)
> 2. Implement ZIP filesystem as Linux kernel module.
There is no need to do that in the kernel, of course.
> 3. Users could be then able to mount a .zip file from the Debian FTP server
> and compile a package directly from the server. This would reduce download
> I deem some about 50% compared with current downloading a source package
> for compilation, because in this scheme only used files from the source
> would be download (no downloading of documentation which is not needed for
> compilation of a package, etc.)
The documentation files are needed to build the .deb package, so it is
no good to not download them.
If there is a particular reason you have for wanting to build only
partial packages, or in fact to build them at all unless you're a
developer, please explain it. Since I can't think of any such reason
myself, I'm closing the bug, but that does not mean it can't be reopened
if you have a good reason.
--
You need fewer comments, if you choose your names carefully.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: documentation types
pe, 2006-02-17 kello 01:10 +0100, Javier Fernández-Sanguino Peña kirjoitti: > Docbook/XML or SGML conversion to HTML is easy. Proper PS / PDF generation is > not that easy (depends on toolchain and local configuration) and that's > what your average user typically asks for when handling large documents > (manny prefer printing bulky documents than reading them offline or online). As a hypothesis, I propose that many people prefer to print PS/PDF files rather than reading them from the screen because PS/PDF tend to be unpleasant to read from the screen. It doesn't, for example, reformat itself to the display/window/font size combination. HTML does that better. Anyway, I'm not opposed to providing a PDF version in a package, but I really, really hope we're not going to switch away from HTML as the primary format. -- Code is cheap to write. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
pe, 2006-02-17 kello 10:58 +0900, Miles Bader kirjoitti: > "Marc 'HE' Brockschmidt" <[EMAIL PROTECTED]> writes: > > actual topic of the discussion, just shut up. > > Oh get a life. It's perfectly relevant to talk about the qualities of > the languages involved. A comparative discussion about languages might be useful and productive. A discussion with arguments like "Efficient, perhaps, but _elegant_?!? HAhahahahah1hahah3$I17-e87"[1] is not such a discussion. The point of this thread has, at least in theory, been whether Python (in full or in part) should become an essential package so that various packaging scripts could be written in it. I suspect that all constructive arguments have been made already and that the consensus is "no, not now, maybe later when it's OK to make the set of essential packages bigger". In other words, status quo continues, the same one that Debian has had for a decade or so. Now can we please not perpetrate this thread anymore? [1] http://lists.debian.org/debian-devel/2006/02/msg00539.html -- Communication via acronyms is rfs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
la, 2006-02-18 kello 10:43 -0500, Michael Poole kirjoitti: > What's the purpose of an assembler without assembly code to use it on? It can be used, for example, to assemble code you write yourself. That is, after all, the primary purpose of programming tools: to help programmers develop programs. > Despite Anthony's claim, I see no packages that can use nasm out of > the box, which means it needs software not in main to perform its > intended use (which seems to be the objection to ndiswrapper). Anthony listed a number of packages that require nasm for building. That is a clear case of nasm being used by packages in main. Nasm and ndiswrapper are in not comparable in any way that makes it useful to argue that ndiswrapper should be kept in main. -- Fundamental truth #3: Communication is difficult. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Problems found by piuparts
In the past six months, I've filed about 260 bug reports based on what piuparts has found. About 40% of those have been fixed so far. Below is a summary of the common problems, hopefully the list will help everyone to find and especially avoid problems in their own packages. * The most common problem is when postinst creates a configuration file, log file, or some other kind of file, but postrm fails to remove it. * Use of ucf in postrm during a purge, without checking that ucf is installed. Since ucf is not an essential package, postrm during purge cannot rely on it. As it happens, I think it might be good to have ucf (or a subset of it) as an essential package, since this error happens a lot. * Dropping conffiles in a newer version of a package, and not removing it when the package is purged. For example, if the version in sarge has a conffile, but the version in etch does not, whoever upgrades from sarge to etch and then purges the package is left with the file still on the filesystem. Arguably dpkg should deal with this, but it doesn't, so maintainer scripts need to deal with it. * Not using debconf for prompting. There's still a few packages that haven't switched from "echo + read" to debconf. * Broken use of update-alternatives, which leads to alternatives not being removed properly with the package. For example, the name of the alternative is sometimes spelled differently in postinst and postrm. * Use of ">/dev/null 2>&1" in package maintainer scripts. This hides errors from the system administrator (or your friendly piuparts runner), and can make it quite annoying to debug what is really going on. While there probably are a few cases where hiding an error is OK, every time I've seen it so far, it has been in error. Typically it seems to be used to avoid cluttering the output with status messages or other such things during package installation. For example, adduser can be quite chatty. Using a --quiet option or at least only redirecting stdout, not stderr, to /dev/null are better choices. * Creating /usr/local/lib/foo in postinst, but not removing it in postrm. * Assumption that /usr/doc still exists. Or, in fact, creating /usr/doc. * Creating a temporary file, but then not removing it afterwards. * Not using invoke-rc.d to start services. These are the more or less common problems. There are more, of course, but they tend to unique. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems found by piuparts
I added a Cc to Manoj since I would like to hear his comment. Whoever responds may want to remove the Cc to avoid stuffing his inbox unnecessarily. su, 2006-02-19 kello 23:42 -0800, Steve Langasek kirjoitti: > On Mon, Feb 20, 2006 at 08:24:53AM +0200, Lars Wirzenius wrote: > > * Use of ucf in postrm during a purge, without checking that ucf > > is installed. Since ucf is not an essential package, postrm > > during purge cannot rely on it. As it happens, I think it might > > be good to have ucf (or a subset of it) as an essential package, > > since this error happens a lot. > > So assuming that we're stuck with the current implementation for a bit where > ucf is not part of essential, I do wonder if checking whether ucf is > installed is actually the correct thing to do in postrm purge. The state > prior to purge is defined as "config files"; the difference between config > files state and "purged" is whether there are still config files left on the > system. If the package can't actually succeed in removing its config files > because ucf is not installed, isn't it *correct* for the postrm purge > command to fail? I.e., I think it's more of a bug to allow dpkg to put the > package into "purged" state leaving orphaned config files behind than it is > for postrm purge to fail and leave the package in "config files" state. Hm. I don't use ucf on my own packages (yet), so my understanding is a bit hazy, but if I have understood correctly, the actual config file is removed with rm anyway, and ucf is needed on purge only to remove the config file also from ucf's history data. Thus, only running ucf if it's there should be the right thing. Manoj, could you comment on this? -- Yet another password: just say no. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems found by piuparts
to, 2006-02-23 kello 02:26 +1100, Anand Kumria kirjoitti: > On Mon, Feb 20, 2006 at 08:24:53AM +0200, Lars Wirzenius wrote: > > > > * Creating /usr/local/lib/foo in postinst, but not removing it > > in postrm. > > I don't think that is a problem at all; the administrator ought to feel > free to be able to put things in (say) /usr/local/lib/firmware and not > have to worry that a full purge / install of the package which happened > to create that directory will wipe out things there. I was referring, not entirely clearly, to Policy 9.1.2 "Site-specific programs": As mandated by the FHS, packages must not place any files in /usr/local, either by putting them in the file system archive to be unpacked by dpkg or by manipulating them in their maintainer scripts. However, the package may create empty directories below /usr/local so that the system administrator knows where to place site-specific files. These directories should be removed on package removal if they are empty. The package should not, indeed must not, remove anything else than the directories it creates, and those only if they are empty. Not removing the directories, however, results in cruft building up on the filesystem, which, admittedly, is not a big problem, but still something worth fixing, since it should be very easy. Incidentally, don't go removing the directories with "rmdir --parents", that's a good way of removing too much: if /usr/local/lib has only one subdirectory, and no files, it will be removed, too. -- If possible, use code, not comments. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems found by piuparts
pe, 2006-02-24 kello 18:27 -0300, Gustavo Franco kirjoitti: > What i thought in a first look to the Lars' list. I think that the > best thing would include piuparts as a infrastructural test (oficially > as a part of our archive code), or due to restrict admin time to do > that, opt for something like piuparts.debian.org as we have > lintian.d.o. Do you mean that the archive should automatically reject uploads that don't pass a piuparts check? I think that sounds like a nice idea, but we're not yet in a situation where it is feasible. For example, the reason piuparts testing fails may be due to a bug in an unrelated package. This needs to be dealt with manually, and that requires quite a bit of effort. For the time being, at least, I think it is better for Debian to let uploads run smoothly, and do piuparts testing separately. If we are to start doing checks on packages before accepting uploads, I think it would be best to start with some subset of lintian and linda errors. Lintian and linda are faster to run, anyway, and less risky, and less likely to hang. > I would be glad to help with a web interface to show the piuparts html > results in a organized way Something like piuparts-report.py? Anyway, I think it is more productive if package maintainers run piuparts themselves, and then people running piuparts centrally reporting bugs. The lintian.debian.org experience seems to be that having lots of info on the web is nice, but filing bug reports actually gets things fixed. As it happens, however, there is work going on in getting a centralized machine to run piuparts testing, and that machine will be used to publish logs and statistics. I haven't done that so far because the logs are big, and I don't have gigabytes of disk space and bandwidth to spend on them. > Since Lars already did the check (for i386 only, i think), I haven't tested the entire i386, either, only about half or so. The rest is waiting for their dependencies to be fixed, or for something to happen with regards to circular dependencies (which at the moment are likely to make piuparts testing fail). -- Boilerplate programming mean tools lack power. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems found by piuparts
ma, 2006-02-27 kello 18:39 +0100, Goswin von Brederlow kirjoitti: > I think it would be best for the buildd to run this and append the > result to the buildd log. I don't, because, as I said, piuparts tests often fail for reasons completely unrelated to the package itself, and there is no point in preventing an upload from happening. Also, it would put more burden on buildd maintainers and it's important to remove bottlenecks, not increase them. -- On a clear disk, you seek forever. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is there some guideline saying that native packages should be avoided?
ti, 2006-02-28 kello 19:39 +0200, Panu Kalliokoski kirjoitti: > I would like to ask whether there really is such a guideline, and if so, > which are the technical / political reasons that lead to it. There is a somewhat common feeling among Debian developers that Debian packaging should be separate from upstream sources, for various reasons. a) If there is a bug in the packaging, it can be fixed without uploading a new upstream source tarball. Assuming upstream version is 1.2, the first Debian version would be 1.2-1, and the fixed one would be 1.2-2. The .orig.tar.gz file would be the same for 1.2-1 and 1.2-2. b) Keeping upstream and packaging separate makes things easier when they no longer are maintained by the same person. Upstream doesn't have to maintain debian/* anymore, and the Debian package maintainer doesn't need to feed his changes to upstream and wait for them to be incorporated in a new release. c) Often, though obviously not always, the upstream developer isn't following Debian packaging policies and practicies to the extent a dedicated Debian developer would. Thus, if the package gets uploaded to Debian, its Debian packaging will differ from upstreams, leading to confusing and .diff.gz files that are hard to read, since they don't contain all the Debian packaging. d) It doesn't really make it harder to keep packaging files separate. It may require a step or two extra to the script that builds a release, but it should be easy enough to do that. -- Our technology is sadly insufficiently advanced. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: custom package error: dpkg -P tries to remove /opt
ma, 2006-03-06 kello 19:39 -0800, Mike Fogel kirjoitti: > However, I can't seem to figure out how to resolve this error: > > $ dpkg -i custom-package.deb > ... installation goes perfectly > $ dpkg -P custom-package > ... removal goes perfectly until this error/warning > dpkg - warning: while removing custom-package, unable to remove > directory `/opt': Device or resource busy - directory may be a mount point ? > > Well, yeah, /opt is a mount point, and it would definitely be a good > thing if it wasn't removed. But how can I tell dpkg that I don't want > it to try to remove /opt?? What seems to happen here is that your package contains /opt as part of the .deb, but nothing else on the system owns it. Thus, when you install your package, dpkg assigns ownership of /opt to your package, and when you remove the package, dpkg sees that only your package owns /opt, and thus tries to remove it. Since it is not removable, you get a warning. /opt is created by the base-files postinst script (see /var/lib/dpkg/info/base-files.postinst), instead of being included in the base-files package. I am not sure why, but that's how it works. I think you can just ignore the warning, even if it is a bit ugly. I don't know of a way to get dpkg not remove the directory. -- It's pointless to argue with someone with no soul. -- Skip Middleton -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about stable updates
to, 2006-03-09 kello 19:21 +0100, Amaya kirjoitti: > 1 - lobby (all of them) > 2 - get promises in exchange of votes That reminds me of something I meant to propose some time ago: someone with a bit of time on their hands could make a wiki page, DplPromises2006 say, and list all the promises of all the candidates. Then, during the next year, we can keep coming back to that page and check how well they keep their promises. -- Cameras don't shoot people. People shoot people. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about stable updates
pe, 2006-03-10 kello 21:49 +0100, Adrian von Bidder kirjoitti: > /me is trying to imagine the Debian project's members trying to agree on an > enemy... Open RC bugs. Go to http://bts.turmzimmer.net/details.php, pick one, hate it to death. Sleep well. -- C is the *wrong* language for your application. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about stable updates
pe, 2006-03-10 kello 20:31 -0300, Henrique de Moraes Holschuh kirjoitti: > On Fri, 10 Mar 2006, Lars Wirzenius wrote: > > pe, 2006-03-10 kello 21:49 +0100, Adrian von Bidder kirjoitti: > > > /me is trying to imagine the Debian project's members trying to agree on > > > an > > > enemy... > > > > Open RC bugs. Go to http://bts.turmzimmer.net/details.php, pick one, > > hate it to death. Sleep well. > > Can use that as a quote? It's brilliant! Sure. -- The most difficult thing in programming is to be simple and straightforward. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about stable updates
su, 2006-03-12 kello 12:20 +0100, Frank Küster kirjoitti: > Andreas Barth <[EMAIL PROTECTED]> wrote: > > > Actually, in case stockholm gets elected, > > Sorry, where's the Wiki page describing codenames for DPL candidates? db.debian.org lists them, though for clarity of discussion, it helps to not use IRC nicknames outside contexts where readers are expected to know them, or not only use nicknames at least. Planet GNOME, for example, lists both real names and nicknames, which is handy. -- i++; /* TODO: make this pre-increment - more efficient */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: question on hurd-i386 Debian architecture
su, 2006-03-12 kello 15:49 +0100, Peter Kourzanov kirjoitti: > Can anyone please explain why this architecture is named hurd-i386 > rather that i386-hurd? I guess it just happened to seem like a good name at the time. Why, is there a problem with the name? Does it matter? Debian architecture names are, after all, pretty much atomic and unparseable. -- I am an artist. Source code is my canvas, a programming language is my paint. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW queue backing up again -- ftpmasters, any explanation or comment?
ma, 2006-03-13 kello 08:57 +0100, Thijs Kinkhorst kirjoitti: > I don't think it's useful to second-guess what they're doing, so my > question to Nathanael: when did you post this question to them directly > and what was their answer? Is there a reason why the question should be made in private? I do think N.N. formulated the question in a needlessly accusatory tone, but I don't think -devel was the wrong place. Transparency and openness are good for the project. -- Mulla on halu häkätä ja mulla on siihen taito -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Regarding the NEW queue (Was: Re: NEW queue backing up again -- ftpmasters, any explanation or comment?)
ma, 2006-03-13 kello 14:59 +0100, Jeroen van Wolffelaar kirjoitti: > On Mon, Mar 13, 2006 at 12:20:38PM +0200, Lars Wirzenius wrote: > > Is there a reason why the question should be made in private? > > It seems as if only problems and annoyances end up on mailinglists, and > *not* to [EMAIL PROTECTED] The don't specifically need to be made private, but > I don't think it'd be too much to ask for questions to ftpmaster to be > mailed to the our published contact address? Certainly the question should be mailed to ftpmaster@ as well. I just don't see why it should be mailed there only, when it is an issue that affects the entire project. If there is a Cc to -devel, then ftpmaster can, with one reply, efficiently inform the entire project. -- We live in a duct tape society. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removal of svenl from the project
pe, 2006-03-17 kello 14:46 +1100, Brian May kirjoitti: > Would the next step be to ban Sven from participating in our public > mailing lists? With the understanding that we're now not talking about Sven Luther but a hypothetical highly abusive person, I wish to ask Brian the following question: do you think there are any circumstances under which Debian should be able to ban people from participating in our public mailing lists? -- Never underestimate the power of a small tactical Lisp interpreter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: scripts to download porn in Debian?
ti, 2005-01-25 kello 12:34 +0200, Kalle Kivimaa kirjoitti: > Ron Johnson <[EMAIL PROTECTED]> writes: > > The problem is things/websites/etc that "many" parents don't think > > are appropriate for their children. > > These parents are free to install whatever traffic blocker they feel > appropriate. Debian doesn't seem to contain one, though. Such a traffic blocker would, hopefully, be rather more useful for limiting access to the Internet than removing URLs from packages one by one. I don't know how if there is any free software for this purpose, however, since keeping an up-to-date database of safe/unsafe sites is a lot of work and it might need to be done commercially. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP: opencubicplayer -- Music file player
la, 2005-03-26 kello 21:35 -0700, Jeremy Nickurak kirjoitti: > On Sat, 2005-03-26 at 12:53 +0100, Gürkan Sengün wrote: > > Description : Music file player > > This is a port of the Open Cubic Player to Linux. > > . > > It would be nice if the description had some definition of what the > software does. Video player? Audio player? Without any previous exposure > to the "Open Cubic Player", I can only assume that it plays... well... > cubes. :) The short player does say "music file", so presumably it is audio. However: what kind of audio? which formats? For the ITP, but probably not for the description: it might also be good to justify why Debian needs yet another music player packaged. We have many of them already. If this one does something the others don't, then mentioning that would be good. Some of the answers were, I think, already given in this thread, but spelling them out to thick-headed people like me in the ITP bug report (the number of which I don't know) would be good.
Re: intend-to-implement: script to obtain Debian Source
su, 2005-03-27 kello 09:01 +0200, George Danchev kirjoitti: > I second suggestion given at #250202 and like to see "unpacked" and "patched" > targets to hit Policy 4.8. I hear that Adam Heath (doogie for those on IRC) has been working on a new source package format that will make tarball-within-tarball sources obsolete and has native support for multiple patches and cures for other ailments. If this works, and I suspect it will, then "unpack" and "patch" targets will also be obsolete. Personally, I think this will be a good thing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: intend-to-implement: script to obtain Debian Source
su, 2005-03-27 kello 07:49 -0300, Henrique de Moraes Holschuh kirjoitti: > On Sun, 27 Mar 2005, Lars Wirzenius wrote: > > I hear that Adam Heath (doogie for those on IRC) has been working on a > > new source package format that will make tarball-within-tarball sources > > But we will only be able to see it (nevermind USE it) when hell freezes > over, which must be at etch+2 or whatever. If the binary packages produced are compatible with sarge's dpkg, is there a reason why the new source package format couldn't be used in etch already? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpatch and patching debian/rules
to, 2005-03-31 kello 01:06 -0600, Peter Samuelson kirjoitti: > [martin f krafft] > > Parts of debian/rules are Ubuntu-specific (e.g. mv README.Debian > > README.Ubuntu) and we would love to have that removed. > > The DISTRIB thing can be implemented quite easily without include files > or anything. Just say: > > DISTRIB := $(shell something-that-prints-DEBIAN-or-UBUNTU) Maybe it would serve the interests of other derived distributions if we had a command like dpkg-distribution (cf. dpkg-architecture) that printed "debian" for the real Debian, "ubuntu" for Ubuntu, and so on? Implementation might be keyed on a file like /etc/debian_distribution, but the interface should be a command. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpatch and patching debian/rules
to, 2005-03-31 kello 10:31 +0200, Jan Nieuwenhuizen kirjoitti: > Sounds cool. > >$ sudo apt-get install lsb-release >$ lsb-release >bash: lsb-release: command not found >$ lsb_release >LSB Version:n/a > > Hmm. Is n/a an abbreviation for debiaN/unstAble? $ lsb_release -a LSB Version:n/a Distributor ID: Debian Description:Debian GNU/Linux Release:3.1 Codename: sarge $ lsb_release -is Debian $ Any package that uses it is going to have to build-depend on the lsb-release package, which has no dependencies (it is a bash shell script and bash is required, so no explicit dependency needed) and is 88 kilobytes installed. Not too onerous, I think. I now declare that the LSB is good for something. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpatch and patching debian/rules
to, 2005-03-31 kello 20:45 +, Michael Ablassmeier kirjoitti: > On 2005-03-31, Lars Wirzenius <[EMAIL PROTECTED]> wrote: > > Any package that uses it is going to have to build-depend on the > > lsb-release package, which has no dependencies (it is a bash shell > > script and bash is required, so no explicit dependency needed) and is 88 > > kilobytes installed. Not too onerous, I think. > > what about `/etc/issue' to get this kind of information? Given that the sysadmin can and does edit it as they wish, that is pretty useless. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpatch and patching debian/rules
to, 2005-03-31 kello 21:07 +, Michael Ablassmeier kirjoitti: > On 2005-03-31, Lars Wirzenius <[EMAIL PROTECTED]> wrote: > > Given that the sysadmin can and does edit it as they wish, that is > > pretty useless. > > yes, but this might happen to `/etc/lsb-release' too. That would be classified as the sysadmin intentionally breaking their system, then. /etc/issue is meant for the sysadmin to edit. It is free form text. /etc/lsb-release is not. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: anonymous dupload stopped working
ti, 2005-04-05 kello 13:12 -0400, Adam C Powell IV kirjoitti: > Interesting... I just installed and tried dput, and everything seems to > work fine. So dupload is broken. Data point: I used dupload to anonymous-ftp-master successfully last week. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: intend-to-implement: script to obtain Debian Source
ke, 2005-04-06 kello 19:31 +0200, Pierre THIERRY kirjoitti: > Scribit Steve Greenland dies 04/04/2005 hora 07:15: > > > - what problems do thsi random order could weed? > > Unnoted dependencies that just happen to be fulfilled due to a > > consistent (though arbitrary) application order. By applying in a > > different order each time, you should trigger an error fairly quickly. > > I don't find it very sane to be forced to deliberately trigger problems > on the user's system to find bugs. I assume the goal is to make it fail on the developer's system, on build daemons, whenever random developers unpack the package (to, for examples, fix bugs in it), and only at the last phase on the user's system. The point is to make it as likely as possible to make it break, if it breaks at all, so that when the user sees the package, it is already non-broken. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Detecting the installed MTA
to, 2005-04-07 kello 15:10 +0200, Søren Boll Overgaard kirjoitti: > During packaging, that is, during the installation of a package, I need to > determine which MTA is currently installed, since I need to set certain > permissions specific to my package, so that they match with those of the > currently running MTA. What happens if the sysadmin later replaces the MTA?
Bug#303986: ITP: soundconverter -- convert sound files to other formats
Package: wnpp Severity: wishlist Owner: Lars Wirzenius <[EMAIL PROTECTED]> * Package name: soundconverter Version : 0.7.1 Upstream Author : Gautier Portet * URL : http://soundconverter.berlios.de/ * License : GPL v2 Description : convert sound files to other formats A simple sound converter application for the GNOME environment. It reads anything the GStreamer library can read, and writes WAV, FLAC, MP3, and Ogg Vorbis files (MP3 only if the required module is installed, which isn't packaged for Debian). -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-686 Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lintian & linda
ma, 2005-04-11 kello 13:19 +0200, Emanuele Rocca kirjoitti: > It would be very nice to add these to linda's description. > This way, every user can decide to install linda rather than lintian if > they need these specific features. Given that the two tools have different sets of tests, even if many of them overlap, there is no point in not installing and using both. The fact that they have different tests is pretty obvious in that they are different programs, so I don't even feel there is a point in enumerating the tests in the descriptions, or anything. lintian *.changes && linda *.changes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#304330: ITP: iscsitarget -- iSCSI Enterprise Target
ke, 2005-04-13 kello 14:10 +1000, Hamish Moffatt kirjoitti: > On Tue, Apr 12, 2005 at 03:32:02PM +0200, Steinar H. Gunderson wrote: > > On Tue, Apr 12, 2005 at 02:33:49PM +0200, Philipp Hug wrote: > > > Description : iSCSI Enterprise Target > > > > > > An iSCSI Target implementation supporting 2.6 kernels, SMP, 64bit, > > > dynamic configuration, iSNS and more > > > > You might want to expand a few acronyms (I know what SCSI is, but what is > > iSCSI? What is iSNS?) and flesh out the long description a bit. What does > > this package do? What is it good for? What's in the word "enterprise", and > > why is the E and T capitalized? > > I think the target audience for this package will know what iSCSI is. > You might be right for iSNS though. I don't know. I have searched for software to solve a particular problem without knowing the right acronyms. Adding just a few words to explain iSCSI could make the difference between finding and not finding the right package. Something like "Interent protocol for networked storage", maybe adding "meant for using remote hard disks as if they were local"; someone who actually knows this stuff can fix the words to be right. (Similarly for the other acronyms and concepts.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Traps for rc bug fixing
ma, 2005-04-25 kello 23:40 +0200, Joerg Jaspert kirjoitti: > Its a tool where everything is written in one file, and then something > generates the debian/ out of it. Argh. Speaking as someone who looks at lots of different packages while fixing RC bugs, anything that is out of the ordinary is a snare, and will trip people up, or cause extra work. Having taken a very brief look at yada, I can already see that it is going to be unpleasant to work on packages using yada. Not that it is the only such innovation: lots of packages have traps for the unwary. For example, if the source code isn't unpacked after "dpkg-source -x", then there is an extra step before I can start working. Since there is no standard for what the step should be, I have to first figure it out. (We *really* need a new source file format that allows multiple patches to upstream source neatly.) If "debian/rules build" does the actual unpacking of upstream source every time, unconditionally, and overwrites any edits I may have done, I'm going to lose some work before I figure that out. If I have to edit debian/packages rather than debian/control, then it's yet another complication for me, even if it makes things simpler for the package maintainer. RC bug fixing becomes less efficient, and less fun, when instead of working on the bug, I must first map a mine field. Whenever I say "I", it also applies to the security team, of course, who are going to have to potentially fix any package in a stable release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PHP/WebApp policy/mailing list
su, 2005-05-01 kello 21:41 +0100, Neil McGovern kirjoitti: > [EMAIL PROTECTED] I keep thinking that it should be in plural: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian sarge is 3.2 or 4 ?
to, 2005-05-05 kello 15:52 +0200, Andrea Mennucc kirjoitti: > So why nobody did actually change the number then? Release numbers, like release code names, are up to the release managers to decide. Since neither is particularly important, there's really not much point in discussing them at length: if the release managers want 3.1, then 3.1 is what we get. Meanwhile, there are still 83 release critical bugs that affect sarge. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
asciidoc makes ugly man pags (was: cogito_0.10-1 available)
su, 2005-05-08 kello 22:15 -0600, Sebastian Kuzminsky kirjoitti: > The only lintian/linda complaints are from missing manpages. Some > upstream folks are working on translating the existing docs from .txt > to manpages (actually asciidoc), so it'll hopefully get cleaner soon > without me lifting a finger. :) I had a brief look at asciidoc. If its own manual page is produced with asciidoc, then I would suggest that its manual page formatting engine needs some serious fixing. The output has unnecessary empty lines, which look quite ugly, and is missing boldface and italics usage. See man(7) for a summary of what the custom for Linux manual pages is. The troff source for asciidoc(1) claims it was produced by db2man.xsl, but no such file exists on my filesystem after asciidoc has been installed. So far, docbook2x-man seems to produce the best manual page formatting, though it too isn't perfect. If asciidoc produces manual pages via an intermediate DocBook step, I suggest switching to docbook2x-man as the engine to take it from DB to troff. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
ma, 2005-05-09 kello 14:39 -0700, Thomas Bushnell BSG kirjoitti: > Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > > > You asked why the GNU linker, which does not need to be 'ls' and does > > not need to look at the list of files in any directory, scaled well > > with the size of the directory. That's the question I answered. > > How does ld determine that -latoheun will fail, other than by listing > the directory O(n)? How does ld find -lfoo, without searching through, > on average, half the entries? I may be completely wrong here, but as far as I understand, ld turns -lfoo into /usr/lib/libfoo.a and then uses that if it can find it. It might look into some other directories as well, and it might fill in foo into some other patterns than "lib%s.a", but basically that is it. It does not scan the /usr/lib directory, it merely looks up a filename it knows already. With modern filesystems, the kernel also does not need to read through the entires /usr/lib directory listing: modern filesystems user B-trees or other ways to speed up filename lookups. O(log n), that is, or even approximately O(1) if a good hash is used. I suspect this is what Daniel tried to say: that filename lookups aren't O(n) anymore. This means that the performance reason for keeping /usr/lib small is gone. This, of course, has no bearing on whether /usr/libexec should exist or not for other reasons. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
Thomas, please read http://www.nl.debian.org/doc/developers-reference/ch-resources.en.html#s-mailing-lists-rules about not sending Cc's unless people explicitly ask to be copied. (Mail-Followup-To is non-standard and badly supported, and also unnecessary. Any decent mail user agent can deal with the default case of not doing a Cc, without help from M-F-T. Ctrl-L in Evolution.) ma, 2005-05-09 kello 14:53 -0700, Thomas Bushnell BSG kirjoitti: > Which Linux filesystems have better than O(n) performance on open? I haven't studied all of them so I won't speak authoritatively. mke2fs(8) documents one. The option was just mentioned by Martin Dickopp earlier in this thread in the message archived at http://lists.debian.org/debian-devel/2005/05/msg00443.html . (As far as I care, this topic is dealt with. We can move on to other misunderstandings now.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: way to tell when a package makes it to testing?
ma, 2005-05-09 kello 14:56 -0700, Steve Langasek kirjoitti: > There is no log; there is only the daily output of britney, telling which > packages have been accepted in. There is, however, qa.debian.org, that lets you see at a glance the versions in stable, testing, and unstable. It requires polling, though; a way to get automatic notifications (without subscribing to a potentially high-volume mailing list and doing filtering) would be nice to have, one day, perhaps. I'm satisfied with qa.debian.org, though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
ke, 2005-06-08 kello 10:32 +0200, Marco d'Itri kirjoitti: > On Jun 08, Jesus Climent <[EMAIL PROTECTED]> wrote: > > > I do _not_ want a web server right after apt-get installing it, since > > everybody has to move the default page and create their own content. > _I_ do. > If I install a daemon, it's because I want it to use it (weird, isn't > it?). Installing packages in chroots, for example for installation/upgrade/removal testing, is a further reason to not start daemons automatically. On the other hand, Marco's position is also sensible. This suggests that a scheme where the sysadmin can choose for themselves is in order. A low-priority debconf question, perhaps. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Planet Debian and Akregator
to, 2005-06-09 kello 11:40 +0200, Pierre HABOUZIT kirjoitti: > AFAIK, it is a debianplanet bug since the source feeds it uses *are* > correctly escaped. I haven't bothered to investigate it often when the ampersand problem occurs, but on the couple of occasions I have, it has been a case of the ampersand being escaped only once, not twice. In RSS, or at least the versions of RSS I have read about (RSS being a mess of conflicting badly defined drafts of standards at best), there are two levels of encoding: the RSS level and the HTML level. First you create the HTML content, and at this point, you have to write "&" if you want an ampersand. Then you escape the HTML so that you can embed it into the RSS without having the HTML tags be interpreted by the RSS processors. At this point, the original "&" had been encoded as "&" and that now becomes becomes "&". "&" (what user sees) -> "&" (HTML code) -> "&" (HTML embedded in RSS). This is easily all very confusing, of course, and therefore easy to make mistakes in. I may well have made mistakes in my explanation: it's been a couple of years since I wrote my RSS generating code. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the dpkg maintainer
ma, 2005-06-13 kello 10:10 +0200, Peter Palfrader kirjoitti: > Historically we always wanted to be able to use all the source in the > archive with the tools available in stable. If that policy is still > true you would be able to use the new features by the time edge releases > with the new dpkg. That is in some 10 to 18 months :) Unless we update sarge with a new version of dpkg that can handle the new source format, of course. ;-) That is, however, probably a bad idea. dpkg it too critical a piece for a Debian system for us to muck about it more than we have to, in a stable release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: links to logs in /etc? (/etc/postgresql/7.4/main/log)
ma, 2005-06-13 kello 23:56 +0200, Olaf van der Spek kirjoitti: > On 6/13/05, Adam Heath <[EMAIL PROTECTED]> wrote: > > That's a stupid argument. > > It's not that stupid. > If other files shouldn't be there, the specs should explicitly state that. The Debian Policy does not, and cannot, have a rule for every case where some judgement is to be applied while making Debian packages. Such a document would be much too big and complicated to be useful. Therefore, we rely on package maintainers applying common sense to keep things working, sensible, and tidy. That said, the Debian Policy document does mandage use of the Filesystem Hierarchy Standard (FHS), which in turn describes /etc like this: "/etc contains configuration files and directories that are specific to the current system". This cannot reasonably be interpreted to mean anything than "configuration stuff only". When I say reasonably, I mean that a sharp lawer-like mind might interpret it in whatever way they wish, on a larch, but that is not useful for building an operating system. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question regarding "offensive" material
ke, 2005-06-15 kello 12:51 +0200, Ralf Hildebrandt kirjoitti: > I'm asking for guidance regarding this bug: > #313492: xscreensaver/GLSnake has sexually inappropriate imagery ... > 1) Is it a bug at all? >There's no technical problem in the program per se. It's just that >this one person may find it contains "sexually inappropriate imagery". > > 2) Which "Severity" is fitting (if it is considered a bug) > > 3) Is there any section in the Debian Policy that addresses these >social/psycholgical issues? I had a look, but could only find >issues related to freedom and licenses. I think the answers I would give are "yes", "minor or wishlist", and "no". I have no problems understanding that someone may be offended by even abstract references to sexual organs. Many people are quite sensitive to such things, whether it is sensible or not. On the other hand, there are more serious issues with screensavers, such as fears that certain types of quick animation can induce epileptic seizures, and more importantly that running a screensaver makes the computer use more electricity than necessary and is therefore bad for the environment. I therefore propose that we do the following: * Don't install any screensaver modules whatsoever, except one that shows a blank screen and turns off the monitor after a while. * All other modules go into a separate package with a warning that they are evil. * Work on getting suspend-to-disk (swsusp or whatever) working properly on as much hardware as possible and then make the default to put computers automatically to sleep (not just the screen) when they are idle (no significant cpu or network use). Obviously this needs to be configurable: wouldn't want a server go to sleep just because the network has been down for an hour. And no, I'm not joking. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Testing package installation, upgrading, and removal
ts ../foo_1.0-2_i386.deb SEE ALSO pbuilder(1) AUTHOR Lars Wirzenius ([EMAIL PROTECTED]). 2005-06-12 piuparts(1)
Re: Release-critical Bugreport for June 17, 2005
su, 2005-06-19 kello 11:28 +0200, Turbo Fredriksson kirjoitti: > > Package: roxen3 (debian/main) > > Maintainer: Turbo Fredriksson <[EMAIL PROTECTED]> > > 298934 [] [X] roxen3: contains non-free fonts > > In one of Debian's lists (have no idea which), I/we discussed this. It was > YEARS ago. > > The conclution was that the 'copyright' (or lackof - can't remember) was ok... > > Does anyone have a clue where to look or remember this discussion!? Use "site:lists.debian.org roxen3 font copyright" or something similar to search the list archives with google. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing package installation, upgrading, and removal
la, 2005-06-18 kello 22:53 -0400, Joey Hess kirjoitti: > I want to run a test that installs each package in woody in turn, > upgrades them to sarge, then to sid, then purges it, then looks for > /usr/doc and /usr/info stuff that is were produced during the package's > install or upgrade and not removed. An interesting use case, which I hadn't thought of. I'll have to come up with a way to do this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing package installation, upgrading, and removal
la, 2005-06-18 kello 22:53 -0400, Joey Hess kirjoitti: > I want to run a test that installs each package in woody in turn, > upgrades them to sarge, then to sid, then purges it, then looks for > /usr/doc and /usr/info stuff that is were produced during the package's > install or upgrade and not removed. I have now, I think, implemented something for this now. From the manual page for version 0.5: 3. An upgrade test between Debian releases. This test is enabled by using the -d option multiple times and disables the other two tests. It sets up the chroot with the first distribution named, then upgrades it to each successive one, and then remembers the directory tree state at the end. After this, it starts over with the chroot of the first distribution, installs the desired pack‐ ages (via apt-get), and does the successive upgrading (via apt-get dist-upgrade). Then, if package files (and not just package names) were given on the command line, it installs them. Finally, it reports problems against the state of the directory tree at the last distribution compared with the state without the packages having been installed. This test can be quite slow to execute. And the example: If you want to test that a package installs properly in the stable Debian release, then can be upgraded to the testing and unstable ver‐ sions, and then uninstalled without problems, you would give the fol‐ lowing command: piuparts -a -d stable -d testing -d unstable foo Is this what you want? It's fairly slow for now, but can be made faster (e.g., by saving tarballs of various phases for later reuse) if it otherwise does what is needed. The code is at http://liw.iki.fi/liw/download/piuparts-0.5.tar.gz (still no Debian package, sorry).
Re: Testing package installation, upgrading, and removal
ma, 2005-06-20 kello 16:47 +0100, Paul Brossier kirjoitti: > how about an optional debian/package.piuparts file that would contain > the syntax to make runtime tests? this would allow to check that > executables can be run, and possibly that their result is consistent. it > could even be used to detect memory leaks. I've been thinking about that kind of package testing as well, but haven't gotten very far with it. See my two web log entries about it: http://liw.iki.fi/liw/log/2005-05.html#20050507b http://liw.iki.fi/liw/log/2005-05.html#20050509c In other words, I don't think it should be tied to piuparts, but if suitable debian/rules targets are standardized on, piuparts could certainly run such checks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Testing package installation, upgrading, and removal
to, 2005-06-23 kello 03:28 -0400, Kevin Mark kirjoitti: > A simple question. You mention that you use apt-get in this new testing > environment. Would it be useful to allow an apt-get > workalike(dpkg/aptitude/wajig)? Yes, that needs to be done. I haven't had trouble with it yet, so I haven't bothered to do it -- this is the kind of finishing touch that I hope to leave to later while I concentrate on getting more important things. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#315808: ITP: cedar-backup2 -- Secure backup to CD-R and CD-RW media
First, this sounds like an interesting piece of software, and I'm happy to see it packaged. su, 2005-06-26 kello 01:51 -0500, Kenneth Pronovici kirjoitti: > Package: wnpp > Severity: wishlist > Owner: "Kenneth J. Pronovici" <[EMAIL PROTECTED]> > > * Package name: cedar-backup2 Why the 2 in package name? It is better to avoid embedded version numbers (even the major number) in package names if at all possible. (Instead, make the software upwards compatible.) > Description : Secure backup to CD-R and CD-RW media Why "secure"? The long description does not say anything that would justify the adjective, so it sounds like advertising, which package descriptions shouldn't be. Does the software encrypt the backups, for example? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#315808: ITP: cedar-backup2 -- Secure backup to CD-R and CD-RW media
su, 2005-06-26 kello 11:13 -0500, Kenneth Pronovici kirjoitti: > Perhaps you would prefer this? > >Description : local and remote backups to CD-R/CD-RW media > > It's probably more descriptive anyway. Yep, I think that's better. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#315808: ITP: cedar-backup2 -- Secure backup to CD-R and CD-RW media
su, 2005-06-26 kello 12:54 -0500, Ron Johnson kirjoitti: > > Don't forget to tell Rene Engelhard to rename OpenOffice.org2. > Hi, Ron. I once asked you to quote only the parts that are relevant when you respond to someone. I did it in private since that is usually the best and most effective first step. I'd now also like to ask you to only reply when you have something useful or constructive to add. You being a prick does not improve the state of Debian. I hope to see your cluon transplant has succeeded by the time I next recycle my plonkdb. Good luck. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
