Bug#749546: general: No trackpad on Toshiba CB35 Chromebook Debian Jessie
Package: general Severity: important Trackpad does not work on a Toshiba Chromebook cb35 on Debian Jessie. Tried the script at: pastebin.com/2GQnyMLT (via: blogs.fsfe.org/the_unconventional/2014/04/20/acer-c720-chromebook-debian-gnu-linux/ ) with no success. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140527220052.3049.25873.reportbug@horus
Bug#931296: general: Camera flash drive mount does not show up on desktop
Package: general Severity: important Tags: a11y Dear Maintainer, * What led up to the situation? Plugging in camera in Buster does not show flash storage on desktop as it did in previous versions with Xfce DE. * What exactly did you do (or not do) that was effective (or ineffective)?Tried to turn on the display of icons for drives, but it was already on. All other drives show up as expected * What was the outcome of this action? * What outcome did you expect instead? -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe Wreschnig <[EMAIL PROTECTED]> writes: > We need to decide what statutes if any this program could violate if > distributed, and if the risks of alienating/denying that portion of > users (in this case, people under 18/21 in various countries Debian > is currently "ok" in) are worth it. Agreed. If Debian were seen to be distributing pornography, I think it could cause untold damage to our reputation, and much more potential legal problems than e.g. non-US ever did. > The feeling I get from the thread so far is that most developers don't > consider this pornography, and so okay to distribute to minors. Or > alternately, if it is, then we don't care about blocking distribution of > Debian to people in the affected countries because they have bigger > problems. Fine, then I have no problem including it, though I will > lament the continual archive bloat for Yet Another System Monitor. FWIW, I don't think this should be included in Debian, either. I don't like pornography, I don't think we should be distributing pornography (even if it's cartoons), and we already have enough far too many system monitors. To be honest, I'd rather more time was spent on better integrating and fixing the packages we have got, rather than trying to package absolutely every piece of free software out there. I don't see a lot of value in packaging peoples "my first shell script" or minor variations on common programs. I'd like for the bar for new packages to be set rather higher than it is at the moment, and if it doesn't add any value over existing equivalents or have much general use it doesn't get in. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFBrlf7VcFcaSW/uEgRAmiqAJ4632iCtiEC/Irgn1MGfO1f83TxggCfWap5 OjdYaFeLz9yFVTHT4hVkeh8= =565C -END PGP SIGNATURE-
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activitymonitor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen Frost <[EMAIL PROTECTED]> writes: > * John Goerzen ([EMAIL PROTECTED]) wrote: >> On Thu, Dec 02, 2004 at 12:28:20PM -0200, Fernanda Giroleti Weiden wrote: >> > "It is also the type of discussion that deterred me >> > from becoming involved in Debian for some time." >> > >> > http://lists.debian.org/debian-women/2004/12/msg00011.html >> >> If our goal is to advance the cause of a Free operating system, then why >> should we be including, in our OPERATING SYSTEM, images that serve no >> useful purpose, and instead alienate millions or billions of people >> worldwide? How does this advance our stated priorities: our users and >> Free Software? Does anyone seriously think that we are being a >> disservice to users because we don't have porn integrated into the >> operating system? Does anyone seriously think that including these >> particular images would be such an overwhelming benefit? > I agree with this and is why I was suggesting that someone draft up some > language which outlines, for the benefit of our users, things they're > not likely to find in Debian. I suppose that might end up being too > difficult but I think it'd be good to have some criteria for packages to > pass in order to be accepted which includes issues like these and is > clear enough that our users understand it. I also agree with this, and think your proposal would be very useful. I don't think the package in question furthers our production of a free software operating system in any way. - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFBr0JWVcFcaSW/uEgRAi2lAKDZNlt6CfOWTFZXMnWpop9gfRnK5QCfQFlI 3KQbk8/OFAqErnx9IR4pz9Q= =Cyqa -END PGP SIGNATURE-
Re: charsets in debian/control
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Barth <[EMAIL PROTECTED]> writes: > Though I agree on your last statement (and please, remember, I'm from > germany where non-ASCII-characters are also in common use), I still > consider that UTF-8-not-ASCII has not finally reached ok, but it's on > the way to it (and I consider this a good thing). I've been using Debian with UTF-8 only locales for over 12 months now. I now consider it fine for general use, with respect to terminal and application support. Unlike a couple of years ago, most things work perfectly. The only things I've currently found lacking are - - No UTF-8 console keymaps - - Some broken libraries e.g. GTK+ 1.2 [obsolete] - - I can't paste UTF-8 into emacs (perhaps a problem in my .emacs) I think going to UTF-8 as the default locale charmap for all locales is a feasable goal for etch, as is recoding everything to UTF-8 (where it makes sense). Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFBtOj6VcFcaSW/uEgRAohjAKCNnbfpRayVrKwAd7NmfeYtntYVEgCgnPGQ 0rVgxXmc4jjBkBe+p+or9X4= =f7lE -END PGP SIGNATURE-
Re: dselect survey
Miles Bader <[EMAIL PROTECTED]> wrote: > The current aptitude, by contrast, seems both powerful and elegant: it > rarely gets in my way, deals well with problem situations, and offers > powerful features should I want them (aptitude of years past could also > be kinda cranky though). The last time I used aptitude (about six months ago, from Testing), I found it difficult to specify how I wanted dependencies (including recommends and suggests) to be satisfied. I like that fact that when I select a package in dselect which has several ways of satisfying its dependencies, dselect lets me choose what gets installed. Just because a package depends on a web server doesn't mean I want apache installed. While aptitude does tell you what it's going to install, and gives you an opportunity to change it, I couldn't get it to give me a list of acceptable alternatives. I am willing to accept that this might just be down to my own stupidity though. Roger (Sorry if I've broken the thread; I'm reading the web archive.)
Re: Bug#287839: ITP: mxml -- small XML parsing library
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eduardo Marcel Macan <[EMAIL PROTECTED]> writes: > Sorry, I quoted the upstream description, I have a preliminary package > ready and it will be uploaded as soon as I make it clean. If you would like someone to check it, I would be happy to review it. > The upstream author provides only a static version of the library, > so I'm having to check lots of things I never had to deal with in > order to do it right (It seems I'll have to take care of sonames and > the like myself and that's something I'd prefer to avoid, but > anyway...) If upstream do not version it, it may cause future problems if you do Debian-specific soname versioning (consider what happens if upstream enable versioning in 6 months). If you require shared libraries, I'm sure Mike Sweet would consider adding support (have you asked?). Otherwise, perhaps static only would be safest for now. > I know the basics of XML and don't really have any experience using > XML libraries myself, I'm packaging it because zynaddsubfx uses it > to implement an "xml-like" instrument definition, and zyn is one of > my main interests. It looks quite cool. > I think that I'd be a better "comaintainer" of this package than the > only one responsible. The ITP seems to have attracted attention, I > won't mind if someone offers his help to maintain, or even adopt > it. Really :) I would certainly be interested. I may even be able to get libgimpprint using it (instead of the customised form we have embedded currently). I also have uses for it in other projects, where libxml2 is not suitable. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFB2XCjVcFcaSW/uEgRAt5gAKDfl/4eqq7UZtHusSU1XnCBHzquTwCgoR/j /G1/zzwxq1PfIfOqw+5zA2Y= =cOMo -END PGP SIGNATURE-
Re: Bug#297233: ITP: wmansied -- An ANSI/ASCII editor.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 "Nelson A. de Oliveira" <[EMAIL PROTECTED]> writes: > WMAnsiEd is an ANSI editor with functions like line drawing, ellipse, > box, etc., written in Qt. All IBM ANSI and ASCII characters are "ANSI" is pretty meaningless as a "standard", since ANSI standardised many different things. Perhaps you mean it implements ISO-6429 (ECMA-48) SGR control sequences, or maybe something entirely different? Either way, it would help if you were much more specific. (This applies equally to the other ITP.) Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCI4z3VcFcaSW/uEgRArPXAJwJbg6I4N13wcQs6z1tlH86YfWcFACfaCDa MMcd8DXdCXZgoI9b1ZlUCf0= =I6+Y -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-sig support wanted?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Hasler <[EMAIL PROTECTED]> writes: > Marc Haber writes: >> So, most of the DD's do not care about security at all. > > I think that DD's do not use dpkg-sig and debsigs because they believe them > to be hard to use and not supported by the infrastructure or by policy. ACK. I certainly care about security, and I'll sign my packages just as soon as debsign supports it. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDhZtKVcFcaSW/uEgRAp4CAJ93sOae+cyRL9KsTgrIYkme1vHjOwCfXZ4N zmom+bKRm2tMU16IklDxSNk= =seoz -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Goswin von Brederlow <[EMAIL PROTECTED]> writes: > If you NEED to do a manual binNMU it is probably best to use sbuild > (the cvs, not deb) Which sbuild CVS repo? I'll be happy to merge the changes into the official sbuild package (buildd-tools CVS). BTW, are there any good reasons why the autobuilders don't use the packaged version anywat? The differences are minimal. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDhZ3LVcFcaSW/uEgRAqRsAKCKTXgSESNH5ROAiJcdAXyP7yJDOQCbB/+R ox+N2hrCGqlwJIv5V5q6+9I= =Eu1o -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Banck <[EMAIL PROTECTED]> writes: > On Thu, Nov 24, 2005 at 11:02:36AM +0000, Roger Leigh wrote: >> Goswin von Brederlow <[EMAIL PROTECTED]> writes: >> >> > If you NEED to do a manual binNMU it is probably best to use sbuild >> > (the cvs, not deb) >> >> Which sbuild CVS repo? > > It is a SVN repo now, the one used by the buildd infrastructure. Thanks, I'm going through the changes now. >> BTW, are there any good reasons why the autobuilders don't use the >> packaged version anywat? The differences are minimal. > > Last time I looked the changes seemed to be pretty big, but merging is > of course a mid-term goal. I started merging the changes tonight, and I'll try to get through some more tomorrow. Some of the changes appear to be dysfunctional, so I'm testing as I go along. http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/sbuild/sbuild?cvsroot=buildd-tools Once the current SVN changes are merged, I'll reindent the source to match the 4 col SVN intentation, re-diff it and manually merge any outstanding changes. Once we are done, I'll see if we can push back the changes we've made to make it more user-friendly. Is there a mailing list for "upstream" to send patches to? Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDiP9yVcFcaSW/uEgRAlSXAJ9bUT/uehFKNIoyAo4Ymdo3GXYpMwCghfym sqnm3uGVMnZ302nkmJiaUlQ= =Uw5X -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wouter Verhelst <[EMAIL PROTECTED]> writes: > On Thu, Nov 24, 2005 at 06:51:24PM +0100, Goswin von Brederlow wrote: >> Last year the aim was to get the buildd sbuild and debian sbuild back >> in sync and it pains me to see Ryan silently diferting it further and >> further instead of aiding that goal. > > That's one way to look at it. > > The other way would be to say that Ryan has recently been actively > working on improving the code in the wanna-build SVN, and that the > people maintaining the sbuild package in Debian (Roger?) haven't been > paying too much attention to their upstream, likely because they didn't > see the link on buildd.debian.org--a link which I, admittedly, had > missed out on at first too, because it used to point to > cvs.linux-m68k.org. There is indeed still a wanna-build CVS repository > over there, but it's been effectively unmaintained for as long as I can > remember. This is very true. I wasn't aware of the SVN repository until it was mentioned in this thread. Over the weekend, I have merged almost all the SVN changes: http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/sbuild/sbuild?cvsroot=buildd-tools http://lists.alioth.debian.org/pipermail/buildd-tools-devel/2005-November/000388.html As you mentioned, due to cvs.linux-m68k.org being unmaintained for years, the code in the Debian package (maintained by Rick Younie, now group maintained by Francesco Paolo Lovergine, Michael Banck and I), and the code used by the buildds has diverged over the years. Even after the above merge the diff is still around 1000 lines, which I hope we can reduce much further if we can merge the changes both ways to reduce the differences as much as possible. Perl being Perl, so far all the merging has been by hand, and going through the remaining huge diff by hand will take some time. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDi48wVcFcaSW/uEgRAgf2AJ9OeKLykTblYCu9nhVatvBm2lRfeQCgsrpM D6zpcMr6kY7X+WetUgTjo1Q= =Rv3N -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Burrows <[EMAIL PROTECTED]> writes: > The attached text is a first draft of a proposed extension to the > Description field to explicitly handle bulleted lists. That's quite a complex document for something I believe should be quite simple. When I use Emacs, it can reflow text (M-q) by looking at the indentation level of the following lines. It can even cope with bullets, outdents, indents, etc. If a frontend display routine could handle that, that would solve the problem generically, and would handle any level of indentation required. Specifically regarding bullets: We now have UTF-8 encoded control files, so why not simply use the UCS bullet character (U+2022)? Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFDng9YVcFcaSW/uEgRApKxAKCVYU3MScc4m28D7wEuUHzRG2hRgACfaYIn m0MyBHEJLb5GGqmzOigDuis= =79Bc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal/Request for Comments: Formally extending package Descriptions to handle bulleted lists.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Burrows <[EMAIL PROTECTED]> writes: > On Tue, Dec 13, 2005 at 12:01:52AM +0000, Roger Leigh <[EMAIL PROTECTED]> was > heard to say: >> Daniel Burrows <[EMAIL PROTECTED]> writes: >> >> > The attached text is a first draft of a proposed extension to the >> > Description field to explicitly handle bulleted lists. >> >> That's quite a complex document for something I believe should be >> quite simple. >> >> When I use Emacs, it can reflow text (M-q) by looking at the >> indentation level of the following lines. It can even cope with >> bullets, outdents, indents, etc. If a frontend display routine could >> handle that, that would solve the problem generically, and would >> handle any level of indentation required. > > The heart of the document describes how to do this in a simple and > precise way. The first section explains some reasons that it's useful > to recognize bulleted lists, while the last couple sections have > implementation notes and analysis of the impact on current frontends > and Descriptions. Sure. This was not meant to be overly critical. It's just that Emacs has already solved the problem, and can even cope with the case of a bullet appearing as the first character of a paragraph line. You could just copy that algorithm. >> Specifically regarding bullets: We now have UTF-8 encoded control >> files, so why not simply use the UCS bullet character (U+2022)? > > It might make sense to recognize the Unicode bullet character, > but forcing people to use it is not a good idea for several reasons, > with backwards-compatibility being a major one. ACK. - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFDnh1JVcFcaSW/uEgRAlMzAKDqO6WNkjnc3n57AmLucFVGWjp9EwCfQTWg K9wkKPDWKwTCmbj1+X0nc9o= =IroD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] (Marco d'Itri) writes: > On Dec 18, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > >> I have yet to hear any strong reason why we should _not_ implement >> /run. >> I do not count "It's ugly!" as a strong reason. > It's not needed (since we have /dev/shm/), so it's harmful. It is certainly needed. How strongly can I put this? /dev/shm is for *shared memory*, not for random junk. /dev/shm is for POSIX shared memory and semaphores created with sem_open() and shm_open(). We don't want random breakage because people put files in there. /dev/shm is reserved. Because of this, it's *actively harmful* for /dev/shm to be used by initscripts, or indeed anything except the glibc POSIX shm_*() and sem_() implementation. Where was it ever written down that any package could use /dev/shm? They can't. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDpWtzVcFcaSW/uEgRAoRHAKC4QgBqoiKBTnYa9/mA6ufn7BZhTACfRA1A /jJqmirucyfZUY+BiJXFJRg= =qC5b -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Dec 18, Roger Leigh <[EMAIL PROTECTED]> wrote:
>
>> How strongly can I put this? /dev/shm is for *shared memory*, not for
>> random junk. /dev/shm is for POSIX shared memory and semaphores
> /dev/shm is a tmpfs which happens to be used by POSIX SHM. I have not
> seen yet a good reason why it should not be used by other users too.
There could be a naming conflict. The entire namespace is reserved
for SHM, right? That means if someone does a
"int shm = shm_open("/foobar", O_CREAY, 0600)"
and some thoughtless prat already put something by than name there,
they are completely stuffed.
They should use a tmpfs mounted somewhere else.
Here's a sample program to demonstrate:
#include
#include
#include
#include
#include
#include
#include
#include
int
main (void)
{
int fd = shm_open("/foobar", O_CREAT, 0600);
if (fd < 0)
{
fprintf(stderr, "ERROR: %s\n", strerror(errno));
exit(1);
}
fprintf(stderr, "SUCCESS\n");
exit(0);
}
>> created with sem_open() and shm_open(). We don't want random breakage
>> because people put files in there. /dev/shm is reserved.
> Actually people have been putting files there for a while, even in
> packages in a stable release. Can you point us to some examples of the
> random breakage you suggest has happened?
It hasn't happened, but POSIX shm will inevitably take time to gain
users. That doesn't mean abusing it is a good idea in the meantime.
>> Where was it ever written down that any package could use /dev/shm?
>> They can't.
> Oops. They already do.
Correct, but does that make it OK? I find it disgustingly bad
practice, and now we have /run, they can move to using that. /run is
a good idea for this reason alone, because it will correct this abuse.
I fail to see why anyone can consider abuse of an unrelated subsystem
"because it's there" is good engineering practice. Any package
abusing /dev/shm is deserving of an RC bug.
Regards,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>
iD8DBQFDpZ2cVcFcaSW/uEgRApREAJ9tyP3j5T8nXJEUyq/2yidKjxIlfgCgkMAr
iOv0KKusOB1opxHOmcGzRUQ=
=8W5l
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] (Marco d'Itri) writes: > On Dec 18, Joe Smith <[EMAIL PROTECTED]> wrote: > >> 1. POSIX (or at least SuS v3) does not gaurentee the existence of /dev/shm, >> or that if it does exist, that it can be be read as a block device, or that >> if it can, it has a file system on it. >> 2. Neither does FHS. >> 3. The Linux 2.6 device list states that as of now, if /dev/shm exists it >> should have a tmpfs filesystem. But makes no guarentees that it exists, or >> that it will remain a filesystem > Debian guarantees that it exists on debian systems. But what about the future, and what about it being specifically for POSIX-SHM? >> 1. It exists only on Linux-based OS's >> 2. There is no gaurentee that it will continue to be there at all >> 3. There is no guareteee that it will remain a filesystem in the future >> even if it is there. >> 4. There is no gaurentee that it exists at all. > These points apply to the proposed tmpfs-based /run as well. /run doesn't especially /need/ to be a tmpfs fs does it? It could equally be on the root fs, or a symlink to somewhere else. The important thing is that is exists and is standardised; it's then up to the local admin how he wants it to behave. Now that it's in sysvinit, the first criterion is satisfied, and hopefully in the fullness of time the second will also, if and when it's added to the FHS. >> 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. On the contrary, he made several good points, which you would do well to fully consider before dismissing them out of hand. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDpbu5VcFcaSW/uEgRAgByAKDE6wLZXsUQnEJYsDNw60m7wy+huACfVckj M1jpWNCF2SrYm1QQniyEckg= =x/ht -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] (Marco d'Itri) writes: [no need to CC me; I'm subscribed to the list] > On Dec 18, Roger Leigh <[EMAIL PROTECTED]> wrote: > >> > Debian guarantees that it exists on debian systems. >> But what about the future, and what about it being specifically for >> POSIX-SHM? > Tell us... Do you have reasons to believe that we will be forced to > remove /dev/shm/ in the future? Yes. Being an implementation detail of POSIX-SHM, the kernel or libc are free to change the POSIX-SHM implementation at any time, so there are no guarantees. As Christoph mentioned, there is no requirement for it to be user visible; it's not mandated by any standard. As long as shm_open(3) et. al. continue to work, any change could be made without breaking backwards compatibility. This is independent of it being inappropriate to use for non-SHM uses. >> /run doesn't especially /need/ to be a tmpfs fs does it? It could > The current proposal does. Only if you want a read-only root. If you don't, you could create /run on the root filesystem, or symlink it to /var/run. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDpq4MVcFcaSW/uEgRApOcAKCrCNtGKhJfbpAkk7zzF4htyCFbmQCgzoCf dJdXsvgDyA7b+r6bQj44OZM= =nYK8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please test the new sysvinit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] (Thomas Hood) writes: > So, has anyone tested the new packages? Yes. It works just fine on my system (powerpc, current unstable), and I'll do some more testing later. I also uploaded the powerpc packages to experimental, if anyone wants to test them. I did file a bug about tmpfs size limits (#344001), but this is really a wishlist item. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDpq7vVcFcaSW/uEgRArdlAJwNMWMCNln85pgzyn1Kq721nd5fsQCg6qf0 80I/xIAZpYaxtcW3K5Y4IeA= =MpSd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] (Marco d'Itri) writes: > On Dec 19, Gabor Gombas <[EMAIL PROTECTED]> wrote: > >> If in the future glibc decides to choose some other implementation >> for shm_open(), then it has no reason to stay. > But it has no reason to go away either, since there are many other uses > too for a tmpfs. There are many uses for an ext3fs, but that doesn't mean we only have one ext3 filesystem. What exactly is your reasoning here? - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDpsHvVcFcaSW/uEgRAnluAJ0WyacE//0kdGWFXl5DFQbW1/UXSQCg4Esk C32DoJ4AGfP1FmnPDqDfePs= =gqVX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] (Marco d'Itri) writes: > On Dec 19, Roger Leigh <[EMAIL PROTECTED]> wrote: > >> >> If in the future glibc decides to choose some other implementation >> >> for shm_open(), then it has no reason to stay. >> > But it has no reason to go away either, since there are many other uses >> > too for a tmpfs. >> There are many uses for an ext3fs, but that doesn't mean we only have >> one ext3 filesystem. What exactly is your reasoning here? > That tmpfs will not be removed from the kernel just because shm_open() > will switch to a different implementation. Of course. But if that happened there would be no reason to keep /dev/shm mounted; you would need to use an alternate location. - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDpwgzVcFcaSW/uEgRAqwyAJ9YqGshjfse9RYlNuxti7iz3p15qQCfROXn RskcNKCR5yffZlelQTPyJeU= =JEPf -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] (Marco d'Itri) writes: > On Dec 19, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: > >> > > 1. It exists only on Linux-based OS's >> > > 2. There is no gaurentee that it will continue to be there at all >> > > 3. There is no guareteee that it will remain a filesystem in the future >> > > even if it is there. >> > > 4. There is no gaurentee that it exists at all. >> > These points apply to the proposed tmpfs-based /run as well. >> /run would have no other special function, so it is much more future-proof >> than using /dev/shm for stuff it was not created for. > You keep saying this, but fail to provide any arguments except > handwaving. I provided you with a functional program code sample that demonstrates how shm_open interacts with the filesystem. Did you try it? [link with -lrt, BTW] With this example, it's trivial to trigger namespace conflicts and break shm_open(). "mkdir /dev/shm/foobar", for example, or create a symbolic link. These fail outright. If a regular file was opened, it would be ftruncated, zeroed and corrupted beyond repair. Depending on who alters it last, this will 1) Cause POSIX-SHM using applications to fail with SIGBUS as the backing store is removed. 2) Cause POSIX-SHM using applications to segfault or misbehave as their data gets changed behind their back. 3) Cause the program abusing /dev/shm to fail as its datafiles are trashed and/or unlinked behind their back. Namespace conflicts aren't pretty. Sure, you can call it "handwaving", but to me it's something that's going to break at some point in the future. I can't believe you are condoning that, especially when the fix is so simple. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDpwqNVcFcaSW/uEgRAq4fAJ0Q1k15xDzEaAOXo86sZ9TCSwHingCfaQUV OPeVLczGK4GqyxXWJTw5YUU= =vadq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] (Marco d'Itri) writes: > On Dec 19, Roger Leigh <[EMAIL PROTECTED]> wrote: > >> With this example, it's trivial to trigger namespace conflicts and >> break shm_open(). "mkdir /dev/shm/foobar", for example, or create a >> symbolic link. These fail outright. If a regular file was opened, it > And so would two programs using the same name for a SHM object (well, > they would share it, as it's designed to be). Yes. You would however be cooperating, and using O_CREAT|O_EXCL and unlinking at the appropriate times so as to avoid any trouble. > The real lesson in this is that object names should be choosed > carefully. That's correct, but you should still not be using the namespace for non-SHM activities. - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDpxmCVcFcaSW/uEgRAgU5AJ0TnZc1ljigaWcDg4tOBnc19aVliQCfeGZw qhipCtZj2sARpU8FyketWo8= =wzMr -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs. /lib/run
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Hood <[EMAIL PROTECTED]> writes: > Any other defenders of /lib/run? Of /run? I prefer /run. It certainly doesn't belong in /lib (IMO). - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDpyceVcFcaSW/uEgRAhI0AKDdTi2N0xT//1jAerLRE2x/BXy6ogCg35wP 58H/gghiCj/KUwan63x7Vsg= =wCE3 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /run vs /var/run
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gabor Gombas <[EMAIL PROTECTED]> writes: > On Tue, Dec 20, 2005 at 03:59:04AM +1000, Anthony Towns wrote: > >> That is, pretty much everything that runs as a daemon, and that might >> have otherwise used /var in general. > > That's why I'd like to have a check for /run (or /lib/run or whatever) > being empty at the end of the boot process, and complain if it isn't > (possibly also remounting it r/o so abusers break noisily). Wouldn't that break mtab, or will that be moved under /var at the end of booting? - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDp8nsVcFcaSW/uEgRAiVYAJ9DQKlSDJuj7FH6rgnrS03h0WB1wQCg9jDu pEkrsn4KB9POn1/XlnM/KrQ= =4RAQ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lars Wirzenius <[EMAIL PROTECTED]> writes: > Automated testing of program functionality > == > > Automatic testing needs to happen in various contexts: > > * When the package has been built, but before it is uploaded. > This is similar to testing with lintian, linda, and piuparts. > The difference from build-time tests is that the tests are > run when the package is installed onto a system (possibly a > chroot or a virtual system). 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. This is a very quick method to create and destroy a test environment (on my system, 2 seconds to create and 5 to destroy). This is quite a low overhead compared with the alternatives (untarring a tarfile, or copying a filesystem, or running cdebootstrap), and the low cleanup overhead is also advantageous. I also hope to add support for Xen on top of LVM snapshots as well. I'm just waiting for Xen to work on powerpc so I can actually use it. If anyone is interested who would like this, please get in touch. sbuild is also partially integrated with sbuild (the Debian package), though I haven't added session handling for LVM snapshots yet. Once tests become standardised with a debian/rules target, it would be fairly simple to add this to sbuild. [schroot has received some minor criticism for being written in C using GLib/GObject. I have however spent the last week converting it to C++, and I'm just finishing that up now.] Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDqS5QVcFcaSW/uEgRAvZUAKCcIgh8QL33CEJO24/A9669KkvF6ACgpYdC 2s5xPCXcfUkYNZZIRCFY2so= =huA9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lars Wirzenius <[EMAIL PROTECTED]> writes: > ke, 2005-12-21 kello 10:28 +0000, 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? Yes. You would create a separate logical volume (LV) for each distribution you want to support, set them up with debootstrap. Once done, you add a configuration stanza like this: [sid] type=lvm-snapshot description=Debian sid snapshot priority=3 groups=root,sbuild root-groups=root,sbuild device=/dev/hda_vg/sid_chroot mount-options=-o atime,sync,user_xattr lvm-snapshot-options=--size 2G run-setup-scripts=true run-session-scripts=true I plan to add support for tar(.gz|.bz2) and zip files as well once I've finished the C++ conversion (the other alternatives are currently directories and any mountable block device), then when combined with sbuild, you'll have a system almost but not quite entirely unlike pbuilder. It's all nicely modular, so adding a new chroot type is trivial. The other advantage is that it uses PAM in a similar manner to sudo, so you can grant certain users access to root privs (root-groups) in the chroots, which allows them to install/upgrade/remove packages in the chroots. Obviously this is quite simple to abuse if you know what you're doing, so you would only grant it to folks you could trust. When it supports Xen, you could also grant root privs to folks you /don't/ trust, since they would be entirely self-contained. >> 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). 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. > 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. OK. - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDqWRvVcFcaSW/uEgRAqbKAJ9Oy4S1TT8FaHq7aZVzX7CJhpsoNQCfRZo0 3kX9PCMU7X/FZf9a8tSbLkA= =RcKK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Thoughts on Debian quality, including automated testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Moritz Muehlenhoff <[EMAIL PROTECTED]> writes: > 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". You have to send a patch for all NMUs in any case. A simple "NMU at will" tag should be sufficient. However, a distribution-wide (or priority-based for base/standard/optional/extra) policy would be simpler to understand and make use of. The fact of being group-maintained /should/ make it simpler for third-party changes to get into a package anyway (since there are more maintainers to review and commit changes). This should lessen the need for 0-day NMUs. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDsvy4VcFcaSW/uEgRAk2gAKDbPSpXV24YPwaw/9XddKgEqHg5QACeJsej U7ZmuZIANqprG2Up0ufM0lA= =dBBq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dependencies on makedev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adam Heath <[EMAIL PROTECTED]> writes: > On Thu, 29 Dec 2005, Marco d'Itri wrote: > >> On Dec 29, Adam Heath <[EMAIL PROTECTED]> wrote: >> > How does persistance of the permission model work? Can I do chown/chmod on > the dynamic files in /dev, and have them remain the next time? Even if a > device node changes it's name? Or do I have to edit some alternative > database? You edit or add to the udev rules. These are usually used to set policy for whole categories of devices, but you can of course fine tune it, or replace all the standard rules with your own. The default gives you all the standard names, as with a static /dev. (I personally switched it to the devfs-style rules.) > I've been running 2.6 for a while now. Lots of our servers do(all > our xen machines). We've had no use for any dynamic device > anything; in fact, I'd much prefer to not have anything dynamic on a > server; stable names is all I want The names are stable, but the devices are created dynamically. The only exceptions are hotplug events which may not always occur/complete in the same order. This will not be an issue for a server where you are not e.g. constantly plugging and unplugging lots of USB storage devices. I've been running udev on all my systems for some time now without any problems at all. The fact that the available devices nodes actually matches your hardware is quite useful. Even if you never use udev yourself (though I would recommend at least trying it), Marco's proposal does make sense: even if you never use it, we do need to allow for the eventual removal of makedev on systems using udev--when all the device nodes are already created, it's no longer useful; this will not preclude it being installed by hand on systems with a static /dev. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDtIeWVcFcaSW/uEgRAtjLAJ9HLHtBHVHgIdPGOSrh8hcAYlcjNQCgz7TV LPOXYQIlPZXVt++UMCFoY1c= =6GLm -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITK: debmake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Osamu Aoki <[EMAIL PROTECTED]> writes: > As I see in debian-reference: > --- > A.3.2 debmake > > debmake, a precursor to debhelper, is a more coarse-grained debian/rules > assistant. It includes two main programs: deb-make, which can be used to > help a maintainer convert a regular (non-Debian) source archive into a > Debian source package; and debstd, which incorporates in one big shot > the same sort of automated functions that one finds in debhelper. > > The consensus is that debmake is now deprecated in favor of debhelper. > However, it's not a bug to use debmake. > --- > I should remove last sentence from all translations. It might be better changing it to "It is a bug to use debmake in new packages. New packages using debmake will be rejected from the archive." Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDtsxbVcFcaSW/uEgRAoLGAJ4iZtJfgiRcuV/wzqaC6go4bkRJwgCaA9um mV/qa9VilIdltIBicJvgbDo= =fPPV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to Increase Contributions from Volunteers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Manoj Srivastava <[EMAIL PROTECTED]> writes: > On Wed, 4 Jan 2006 11:39:55 +0100, Andreas Schuldei <[EMAIL PROTECTED]> said: >> Please realize that there is a difference between people who want to >> *contribute* above average and *people* below average. > > I am not sure I want "below average" contributions, if you are > talking about quality. If you are talking about dilettantes, heck, > the can contribute via patches sent to the BTS. Recognition should be > commensurate with the effort spent; tyros and dilettantes get less > recognition than people who are committed to the project and do the > heavy lifting. In the case of someone who attaches a patch to a bug report, I think getting a mention in the Debian (or upstream) ChangeLog is sufficient. I generally also even mention bug submitters in the Debian changelog, as a way of thanking them for the time they took to identify and investigate a bug. I treat both fellow developers and non-developers the same in this respect. Realistically, what more can we do? Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDu/NXVcFcaSW/uEgRArPmAJ98YU6OyI/WHxNfFuJswUKCwsXV9ACg2Z4+ DLP/W55IKPS97xf2DM1eRgs= =RZDz -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#345977: ITP: polld -- Polling demon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michal Čihař <[EMAIL PROTECTED]> writes: > This demon periodically opens devices (files) listed in configuration. > Main reason is to force rescanning of partitions on usb devices while > using udev. What is the problem this is trying to solve? If the partition table is being changed, the tool that changed it should issue a BLKRRPART ioctl, like fdisk does for example (see ). Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDvAOjVcFcaSW/uEgRArDAAJ9vUxE3TWr+iIkn4TvCD7GtTt5PiACghFoJ W1FS6fucsy+nqJrq/bcwHxI= =xf+6 -END PGP SIGNATURE-
Re: Cooperating With Canonical Employees
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Nusinow <[EMAIL PROTECTED]> writes: > The way to collaborate well with Canonical employees or MOTU remains the > exact same as it does for collaborating with anyone else inside or outside > of Debian. Establish a good working relationship with them on a personal > level by asking questions, soliciting advice politely, and rolling up your > sleeves and getting some work done. No disagreements here. One problem I do see is that many (most?) Ubuntu packages do not have a maintainer; big packages like X are probably an exception. When I check my own I see that each upload has been by a different person almost every time, which makes it difficult to firstly know who I should contact, and secondly I have doubts about their familiarity with the package if there's no one who really cares for it. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDwm+dVcFcaSW/uEgRAqEfAJ0c1TUFN5Jg20ANL5Yh88LRuW914gCggXt3 XVGuABHtgTSCwPVGUgTpB8k= =Ya5y -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: D8915
Other than 48 D8915 monitors that I have in stock...any other Hp or SUN 21" monitors needed ? Please reply. Thanks, Roger Nova Star
Re: Need for launchpad
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Meredith <[EMAIL PROTECTED]> writes: > I can definately understand some DD's views here - they seem to get > nothing from ubuntu - have to wade through patches or whatever to try > and find the useful stuff - have to do all this work to get all the > stuff from ubuntu, because whatever ubuntu dev is doing things isn't > contributing back to debian. This definately happens. There's no doubt > about it. > > But, also - and I've had this experience myself - there are some DD's > who just plain and simple dont want the stuff from ubuntu. I've had a > couple of times where I've had an issue with a package - and realised > it was a problem in debian and upstream too. Usually - I've contacted > both upstream and the DD via Email about this - and have had various > responses - for example, for one package - I sent about 7 emails over > the space of a month, emailed upstream, tried to contact the DD on IRC > - many a thing - but well - no response - and I've tried a couple of > times with different issues to contact that developer regarding those > issues - but have never had any awknowledgement, reply etc etc. > > I eventually gave up trying contacting that maintainer - and just > carried on with the work in ubuntu - and worked with upstream. It's > people like that that are spoiling it, as I've had experiences with > other DD's who've been very helpful indeed. This is definitely a problem, and it's not limited to Ubuntu maintainers being ignored. Some Debian developers are completely non-responsive to everybody, including users and fellow developers. Being a volunteer project, a delay is understandable, but a month is not. When a maintainer is unresponsive/uncooperative, they are falling short of their duties as a package maintainer, and I think that we do need a better mechanism for dealing with it, not least a way to notify the project about it in the first instance. We do have the Technical Committee, but this is mainly focussed upon technical issues, and it's not widely known outside Debian. Perhaps its role could be widened, or an alternative committee created to deal with it. [...] > when one side isnt willing to work (I'm not on about projects as a > whole - I'm on about individual people/maintainers) then it spoils > the whole thing. Agreed. I think Debian has gone past the size where non-responsive maintainers can be coped with. They cause huge delays in big transitions, because they hold up all dependent packages while others do their work for them, and unmaintained and buggy packages lower the quality of the distribution. I don't know if you read my other mail, but I do find it hard to cooperate with Ubuntu for my own package, because each time it has been uploaded to Ubuntu it was done my a different person, so I don't know who I should be cooperating /with/. For large and important packages, this isn't a problem, but for others it's difficult. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDxlNGVcFcaSW/uEgRAsA6AJ9xh6FeipzRZBhymxNXQZyXzHmr/wCg4BgQ ruJGjBikSN1Z1ABaMvoaT7o= =6kXc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about lesbians
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bartosz Fenski aka fEnIo <[EMAIL PROTECTED]> writes: > On Sat, Jan 14, 2006 at 03:00:40PM +, Andrew Suffield wrote: >> Since this sort of thing is apparently okay nowadays, and I know >> that a lot of you like looking at lesbians, I'd like to share this >> with you: >> >> http://www.flickr.com/photos/[EMAIL PROTECTED]/81351129/in/photostream/ >> >> [And for the sarcasm-impaired: debian-devel-announce is for Debian >> development, not anything that you (or any other group of people) >> happen to be interested in. Don't post irrelevant stuff here. It would >> be a real shame if the list had to be moderated because people can't >> exercise good judgement. Anything sent here should be of interest to >> an overwhelming majority of Debian developers, *at least* - if you're >> using phrases like "for those who care about X", it belongs somewhere >> else, like X-announce.] > > I got you sarcasm, but I still think that messages posted to > debian-devel-announce should be more official. Agreed. Andrew, do you understand just how inappropriate and offensive your mail was? Nothing justifies abuse of our lists like that. d-d-a is a widely-read list both inside and outside the project, and you have done harm to our reputation. If you can't see why what you did was wrong, you are doing the project a disservice by continuing to be a developer. You certainly are not doing the project any favours by representing us in this manner. If you still can't take the hint, I'll be more blunt: this isn't the first crass stunt you've pulled by any means, and you are now right at the limits of many peoples tolerance. Pull another one again, I may be forced to file a request for your expulsion. That might happen for this one yet. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDySmFVcFcaSW/uEgRAgxOAJsFmgXl1t/Yg1ZZFf/mHkD81ic7sgCfTTDo 24iLqEi5gPMZcpoTLmF4Aes= =WU5k -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about lesbians
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Bird <[EMAIL PROTECTED]> writes: > On Sat, 2006-01-14 at 08:40, Roger Leigh wrote: >> Andrew, do you understand just how inappropriate and offensive your >> mail was? Nothing justifies abuse of our lists like that. d-d-a is a >> widely-read list both inside and outside the project, and you have >> done harm to our reputation. > > There was nothing offensive about Andrew's message. It is offensive to many people, myself included. But mainly it's offtopic for that list (as well as all other Debian lists). That's why I said "inappropriate". That list is widely read my many people outside the project, including many corporations. As a result, it is damaging to the reputation and good standing of the project, as well as being an abuse of the project's public announcement lists. >> If you still can't take the hint, I'll be more blunt: this isn't the >> first crass stunt you've pulled by any means, and you are now right at >> the limits of many peoples tolerance. Pull another one again, I may >> be forced to file a request for your expulsion. That might happen for >> this one yet. > > If your message is merely a troll, I would respectfully ask you > please to expell yourself. I was perfectly serious. This is merely the latest in a number of things Mr Suffield has done which are detrimental to the project in a number of ways. Some of these are not a matter of public record, so you would be unaware of them. It is not this one incident which is resulting in this, but rather several years of incidents of varying severity, some rather worse than this. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDyTn7VcFcaSW/uEgRAmr4AKC+Ae4LHYa09e7J532EO0z7wJFx3QCgmhgR a65URkYUORv6LCvvfYRY/TU= =tZSc -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about lesbians
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Suffield <[EMAIL PROTECTED]> writes: > On Sat, Jan 14, 2006 at 05:51:03PM +0000, Roger Leigh wrote: >> >> If you still can't take the hint, I'll be more blunt: this isn't the >> >> first crass stunt you've pulled by any means, and you are now right at >> >> the limits of many peoples tolerance. Pull another one again, I may >> >> be forced to file a request for your expulsion. That might happen for >> >> this one yet. >> I was perfectly serious. This is merely the latest in a number of >> things Mr Suffield has done which are detrimental to the project in a >> number of ways. Some of these are not a matter of public record, so >> you would be unaware of them. > > I hope you realise that if I were the litigious type, you would be > receiving a court summons in the next day or two (it's lies, btw, for > those of you watching - I hope nobody bought that 'secret offenses' > noise, it's like the PATRIOT act or something). The events are a recorded in the debian-private archives, which I am not permitted to reveal here. I have at no point stated anything which is untrue, and any Debian developer who wishes to verify it may look at the August 2005 archives (debian-private.200508.gz on master:~debian/archive/debian-private is the worst to date). That is not disclosable on this list. None of this is personal, but your unacceptable behaviour past and present has consequences which affect both other developers, and the project as a whole. You have been treading a very fine line since the above incident, since which I had hoped you would improve, so I hope you understand just how close to the limit you are. If you do reply, please do so in -private. - -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/> iD8DBQFDyYgQVcFcaSW/uEgRArW/AKCdqaH3mo7BEiarOOWyCPw5MU1M8gCfe34V pP6DnpmwdTcaflkTDul5DwQ= =EPLH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Better communication between projects
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Samuelson <[EMAIL PROTECTED]> writes:
> [Sami Haahtinen]
>> like 'dpkg --show-primary-contact ' That way we could even
>> add a separate field Preferred-Contact: (or something alike) that
>> could override the maintainer and modifier.
>
> "Preferred contact" is *exactly* what the Maintainer field means.
> [Well, and the co-maintainers ("Uploaders") field, as a supplement.]
>
> Debian people who have a problem with downstream changing the
> Maintainer field need to get over themselves and think about whether
> debian/changelog gives them all the credit they are owed. (It
> certainly does, unless it's been abridged.)
Completely agreed. While I don't object to occasional mails from
Ubuntu users, I don't generally have a proper Ubuntu contact (or list)
to point them to. This would help a lot there, as well as preventing
the problem in the first place.
Another related problem I noticed the other day is that the Ubuntu
change history is lost when merging new packages from Debian unstable,
which makes it next to impossible for me to find out who last changed
it on the Ubuntu side. This is because any changes to the Ubuntu
changelog are discarded, rather than being merged back into the Debian
changelog (though I can appreciate this is not an easy problem to
solve in an automated fashion).
Regards,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gutenprint.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>
iD8DBQFDykj3VcFcaSW/uEgRAgpmAJ46JgOU0QUZvaJVxUysEsnbswHtQwCcCiXj
D5q30j4oQpTi/sqrrQLm5vM=
=WOh2
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux and memory leak
gustavo halperin <[EMAIL PROTECTED]> writes: > My problem is that the memory (ram and swap) is always grow, my ram is > 775MB and the swap is 1.5GB. After > approximate 20 days the situation of the memory is that all the ram is > in use and approximate half of the swap is also > in use. In this situation all is work very sloowlyyy. > I'm using the next applications: Mozilla, Acroread, xpdf, gv, > gnu-emacs, xfig mplayer and some epplets of Enlightenment and nothing > more. This question is more appropriate on debian-user. Please post any followups there. Check with top and ps to see memory usage; this should show any memory hogs. (Acroread is a likely candidate.) Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. pgp4cGwrkH6V8.pgp Description: PGP signature
Re: Amendment to GR on GFDL, and the changes to the Social Contract
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Marco d'Itri) writes: > >> On Feb 09, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: >> >>> Has anyone come forward and said "I was deceived by GR 2004-03"? I > >> Yes, multiple people did. HTH. > > Who? I can't recall any. Can you provide pointers? There was a rather heated debate at the time, I recall. > What did they say in response to questions like "did you read the > changes?" As someone who carefully read and then voted for the changes, I was rather taken aback by the (unforeseen, by myself and many others) implications of the changes. I wouldn't go so far as to call it "deception", however; the text of the changes was quite clear. After considering it carefully, I would still have voted the same way, and hence I voted to keep the changes in the second vote. Several folks seem to wish to re-ignite the debate of whether or not the changes were "editorial" or not. Whether it was or was not, it's now over and done with. This GR is a separate, albeit related, issue. I'm still not entirely convinced that all documentation needs the same set of freedoms as programs. But the intersection of the freedoms we require of "documentation", and the freedoms we require of "programs" gives us a very large common set of freedoms, with just one or two considerations which might be specific to one or the other. Given the huge problems of defining what is and is not "documentation" or "programs", I'm still of the opinion that we should require and uphold the same set of freedoms of both, which obviously includes the ability to modify without restrictions on what is modifiable. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. pgpy63fdHZ39f.pgp Description: PGP signature
Re: documentation types
Hendrik Sattler <[EMAIL PROTECTED]> writes: > Am Freitag, 10. Februar 2006 12:36 schrieb Daniel Leidert: >> Am Freitag, den 10.02.2006, 12:09 +0100 schrieb Hendrik Sattler: >> > 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? >> >> Why don't you move it into -doc packages, which is IMHO more common >> practice? You could make a -doc-html, -doc-ps and -doc-pdf, which all >> provide -doc and then let the -dev package recommend or suggest the -doc >> package. So the user can choose the format he prefers. > > For one file? > Another alternative, maybe: include only the .sgml file and > Suggests: docbook-utils If would be nice if doc-base could handle registration of SGML/XML documentation, and then generate the docs in the formats of your choice. Is the docbook toolchain is yet robust enough to be able to do that? Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. pgp7q1sfJN1no.pgp Description: PGP signature
Re: Amendment to GR on GFDL, and the changes to the Social Contract
Henning Glawe <[EMAIL PROTECTED]> writes: > On Fri, Feb 10, 2006 at 07:58:52PM -0500, Glenn Maynard wrote: >> This really just isn't a problem that needs fixing. Once in a while, you get >> confused or desperate people on d-legal trying to argue "we allow license >> texts to be unmodifiable, so this invariant ode to my cat should be allowed, >> too!", but you can't stop those stupid arguments by changing the DFSG. You >> just end up replacing one dumb argument with another, equally dumb argument, >> and complicate the guidelines in the process. > > just one thought: we have programs in main, where derived works are > only allowed as original source+patches (TeX comes to my mind...) > couldn't it be basically the same thing with GFDL documents? if > there is an invariant section with an 'ode to my cat', why can't we > add a section to the document telling the 'ode to my cat' is bloody > stupid. this would be in some sense equivalent to a patch, only the > interpreter is not the computer but the human brain (which is the > target architecture for documentation anyways). It's not equivalent. A patch /changes/ the original to give you something new, whereas adding additional material merely /extends/; it's not hard to see long-term maintenance problems with this. See the debian-vote archives for more detail. -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. pgpc7QsssbZjC.pgp Description: PGP signature
Re: Honesty in Debian (was Re: Amendment to GR on GFDL, and the changes to the Social Contract
Xavier Roche <[EMAIL PROTECTED]> writes: > On Mon, 13 Feb 2006, Sven Luther wrote: >> Nope, but i think those who try to hide the issue of non-free material in >> main, by insisting that it is not software > > Fonts or documentations are not softwares, for god's sake! They aren't? There are several definitions for the meaning of "software". One is "not hardware", i.e. any pattern of bits, and another is "executable programs". Personally, I subscribe to the "any pattern of bits" definition, which is its original meaning, though the latter form has come into common use. Bottom line: the meaning of "software" is ambiguous. > But I still consider documentation different than softwares, and > don't see any major problem regarding the FDL. I can see some differences myself, but the real questions are: - how do we tell the difference between "software" and "documentation"? (i.e. how can we define which is which in a clear-cut manner?) - How does "documentation" differ from "software" by way of the freedoms we require of it? The first is not at all obvious. Most of our documentation is actually in the form of programs, in either or both of the document source and the final readable form. For the second, I remain to be convinced that "documentation" is less deserving of freedom than "software". Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. pgpSdLtCOaaF8.pgp Description: PGP signature
New sbuild release 0.38
Hi folks, sbuild 0.38 has been released; the changelog follows at the end of this message. It's tagged in CVS as sbuild_0_38, and has been uploaded to experimental. It is also available at http://people.debian.org/~rleigh/sbuild-0.38/ If you are a user of sbuild, it would be greatly appreciated if you could test this release. It has already had a good bit of testing, but if there are any corner-case regressions that have been missed, it would be great to catch them before it is uploaded to unstable. I'm also posting this to -devel, to bring everyone up-to-date on the current state of sbuild following on from the thread in November (starting at http://lists.debian.org/debian-devel/2005/11/msg01368.html). Version 0.37, released on the 31 Jan 2006, was an almost-complete merge with upstream; the list of changes is also attached below. This fixed a number of long-standing bugs, as well as removing a number of incompatibilities with upstream (it should now be possible to use the packaged sbuild on a buildd, for example). The next step is merging all of our bugfixes with upstream. These patches are available at https://alioth.debian.org/tracker/index.php?group_id=30471&atid=411184 Version 0.38 fixes a number of bugs, as well as introducing a number of larger changes, the most important being - full sudo access is no longer required on the host system; access to the chroot and host system is now provided through a simple API to make chroot use uniform throughout sbuild. - schroot session management is integrated. This means that you can build using any chroot type supported by schroot(1), including LVM snapshots, files (zip, tar(.gz|.bz2) in a manner similar to pbuilder), as well as normal chroots. This is selected with $chroot_mode="schroot" in /etc/sbuild.conf.local. The only user-visible change should be more verbose log messages; this will probably need to be made configurable. Regards, Roger sbuild (0.38) experimental; urgency=low * Full sudo access is no longer mandatory when using the schroot chroot_mode (Closes: #287669, #331506). * schroot session management is now fully implemented and completely functional. * sbuild: - Move schroot metadata parsing to a separate function, get_schroot_info(). Parse both "Location" (for backwards-compatibility) and "Mount Location". - Move path and APT setup into a separate function, setup_options(). - Remove check_dpkg_version(). This has not been necessary since the release of potato (Debian 2.2), which had a dpkg version 1.6.14. - When $chroot_mode == "schroot", clear %main::dist_order and %main::dist_locations using an empty array, rather than undef. - New functions get_command(), run_command(), get_apt_command() and run_apt_command() to run a command inside or outside the build chroot under the specified user, or run apt inside or outside the chroot (depending on the chroot_mode), respectively. - New function exec_command(). This is the same as run_command(), but runs the command with exec rather than system(). - New functions log_command() to log a command being run, get_command_internal() and get_apt_command_internal() to get a command string without logging it; these are used by get_command(), run_command, exec_command(), get_apt_command() and run_apt_command(), which do log the command being run. Commands are logged in for all chroot modes. - get_apt_command() and run_apt_command() take an additional parameter, the command to run (apt-get or apt-cache). - get_apt_command() and run_apt_command() take an additional parameter, the user to run as, because not all commands need (or should) run as root. - Use new commands for running commands inside and outside chroots: + Signing options for dpkg-buildpackage are double-quoted rather than single-quoted (because the main command is single-quoted). + All commands run in a pipeline are obtained with get_command() or get_apt_command(). + All other commands are run with run_command(), exec_command() or run_apt_command(). + check_space() only requires root access in the chroot. - Add schroot session management. Sessions are created, run and removed automatically. The current session is stored in $main::schroot_session. setup_options is called once per build, in order to set up the session options. - Add missing newline to log message. * sbuild.1: - Update outdated information. - Correct macro usage and reindent. - Correct command-line summary (Closes: #311589). * sbuild-setup.7: New manpage. This describes how to set up a chroot (Closes: #311363). * avg-pkg-build-time.1: Clean up. * update-sourcedeps.1: Clean up. * sbuild.conf: $schroot_options defaults to "-q" to match the
conffile purging and maintainer scripts
Until last month, dpkg "forgot" about conffiles which were removed or moved on package upgrade. As a consequence, maintainers had to remember to purge these conffiles "by hand" in the package postrm script. 1) sarge -> etch upgrades - In order to handle upgrades from sarge correctly, maintainers will still have to manually remove conffiles in their maintainer scripts until at least etch+1 by my reckoning. Is this correct? 2) dpkg cruft - In addition to the conffiles, there may also be $conffile.dpkg-old, $conffile.dpkg-new and $conffile.dpkg-dist (and other?) files as well. Should these be purged along with their conffile? Who bears the responsibility for purging these? Does the new dpkg handle this? (It didn't seem to when I tried it.) Should it? Should maintainer scripts remove these in addition to the conffile itself? Currently, most maintainer scripts do not, with some removing perhaps .dpkg-old only. This is inconsistent, and it would be nice to have some guidelines or recommendations about how maintainers should handle conffile cleanup, so that maintainer scripts could do it more reliably and uniformly. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. pgptdpkIsdG6D.pgp Description: PGP signature
Re: conffile purging and maintainer scripts
Thomas Hood <[EMAIL PROTECTED]> writes:
> Roger Leigh wrote:
>> Until last month, dpkg "forgot" about conffiles which were removed or
>> moved on package upgrade. As a consequence, maintainers had to
>> remember to purge these conffiles "by hand" in the package postrm
>> script.
>
> I just want to highlight the word "these" above in order to reduce the
> possibility of confusion.
>
> Postrms should not delete files that are currently conffiles of the package.
> dpkg takes care of deleting such files at the right time.
>
> If a file /etc/foo was formerly a conffile of the package but no
> longer is so then /etc/foo should be dealt with in the preinst or
> postinst. ("Dealing with it" has to take into account both the old
> and the new behavior of dpkg with respect to disappearing conffiles.
> I speak vaguely here because I haven't looked into the new
> behavior.) If it isn't dealt with there then it might be
> appropriate to delete it in the postrm, but not if there is reason
> to suspect that some other package is now using /etc/foo.
How about this as a start?
This should be "safe" in that it won't remove a conffile if another
package (or itself) takes ownership of it. It also handles removal of
the dpkg cruft, but I'm not sure that's always appropriate, since dpkg
should handle it, at least for the new dpkg behaviour; this only
caters for the old.
Call in a postrm like this:
rm_conffile("/etc/my/conffile")
# Remove a conffile which has been forgotten by dpkg
# If the file does not exist, or is owned by any package, do not remove it.
rm_conffile() {
CONFFILE="$1"
if [ -f "$CONFFILE" ]; then
if dpkg -S "$CONFFILE" >/dev/null 2>&1; then
:
else
rm -f "$CONFFILE"
rm -f "${CONFFILE}.dpkg-old"
rm -f "${CONFFILE}.dpkg-new"
rm -f "${CONFFILE}.dpkg-dist"
fi
fi
}
Regards,
Roger
--
Roger Leigh
Printing on GNU/Linux? http://gutenprint.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
pgp9Yl1PKaetr.pgp
Description: PGP signature
Re: conffile purging and maintainer scripts
Roger Leigh <[EMAIL PROTECTED]> writes:
> Thomas Hood <[EMAIL PROTECTED]> writes:
>
>> Roger Leigh wrote:
>>> Until last month, dpkg "forgot" about conffiles which were removed or
>>> moved on package upgrade. As a consequence, maintainers had to
>>> remember to purge these conffiles "by hand" in the package postrm
>>> script.
>>
>> I just want to highlight the word "these" above in order to reduce the
>> possibility of confusion.
>>
>> Postrms should not delete files that are currently conffiles of the package.
>> dpkg takes care of deleting such files at the right time.
>>
>> If a file /etc/foo was formerly a conffile of the package but no
>> longer is so then /etc/foo should be dealt with in the preinst or
>> postinst. ("Dealing with it" has to take into account both the old
>> and the new behavior of dpkg with respect to disappearing conffiles.
>> I speak vaguely here because I haven't looked into the new
>> behavior.) If it isn't dealt with there then it might be
>> appropriate to delete it in the postrm, but not if there is reason
>> to suspect that some other package is now using /etc/foo.
>
> How about this as a start?
>
> This should be "safe" in that it won't remove a conffile if another
> package (or itself) takes ownership of it. It also handles removal of
> the dpkg cruft, but I'm not sure that's always appropriate, since dpkg
> should handle it, at least for the new dpkg behaviour; this only
> caters for the old.
>
> Call in a postrm like this:
> rm_conffile("/etc/my/conffile")
This updated version should cater for both the old and new behaviour.
Any comments?
# Remove a conffile which has been forgotten by dpkg
# If the file does not exist, or is owned by any package, do not remove it.
rm_conffile() {
CONFFILE="$1"
if [ -f "$CONFFILE" ]; then
local delete="false"
local fpkg=""
local pkg=""
if fpkg=$(dpkg -S "$CONFFILE" 2>/dev/null); then
# Don't delete, but check which package it came from.
pkg=$(echo $fpkg | sed -e 's/\(^[[:print:]][[:print:]]*\):
.*$/\1/')
if [ "$pkg" = "$PACKAGE" ]; then
delete="true"
fi
else
rm -f "$CONFFILE"
delete="true"
fi
# Remove dpkg cruft
if [ "$delete" = "true" ]; then
rm -f "${CONFFILE}.dpkg-old"
rm -f "${CONFFILE}.dpkg-new"
rm -f "${CONFFILE}.dpkg-dist"
fi
fi
}
--
Roger Leigh
Printing on GNU/Linux? http://gutenprint.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
pgp32Zg90vQhE.pgp
Description: PGP signature
Re: Ubuntu Patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott James Remnant <[EMAIL PROTECTED]> writes: > Many Debian developers have been asking for a simple way to see the > current difference between their package and the equivalent in Ubuntu, > if any. > > http://people.ubuntu.com/~scott/patches/ That's super, thanks! One suggestion: if any Ubuntu patches were CC'd to the Debian maintainer, or filed in the BTS, they would get applied quicker. I've now put your gimp-print changes back into my packages, but I would have been happy to do this last October when they were originally created. This should also lower your packaging overheads, since you won't have to re-patch for every new Debian revision. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCP2azVcFcaSW/uEgRAoB2AKDKbHf5NL7u6xosMP0PCQZiewjK9gCeMbNw CoHYhHhHSamZ5elzEGxCM1g= =w8Do -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Policy for devfs support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Is there a project-wide policy for support for devfs (and devfs-style, e.g. udev devfs.rules) device naming? I'm asking because of obstruction (from upstream) regarding the application of a simple patch to allow yaboot to support it: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300950 If there was a definite policy of supporting it (or not), this would be easier. As it stands, the tool is not properly functional on devfs systems. Since we should aim to support a well-integrated system, I'm not happy that folks can deliberately obstruct furthering the integration of the system. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCRWL8VcFcaSW/uEgRAuTuAKCNIMJm4FenZfpjih37UOmZRNbaYwCeI6lh Hhv608yjEuM1oTRieRBZF10= =+pee -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Policy for devfs support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] (Marco d'Itri) writes: > On Mar 26, Roger Leigh <[EMAIL PROTECTED]> wrote: > >> I'm asking because of obstruction (from upstream) regarding the >> application of a simple patch to allow yaboot to support it: >> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300950 > The yaboot maintainer has been resisting for years all kinds of sensible > changes (like #233810), so I'm not really surprised. Is there anything that could be done about this? I don't think that it's acceptable for the package maintainer to ignore the report for 13 months, even if they dislike it. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCR9o4VcFcaSW/uEgRArrVAJ9xsxLVdpk74g9LsXQMTGH634n3QgCfW3W6 w1txn5QDAi0u+ysrvP7x3hs= =Qpne -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why do we still have this on the distribution?
Martin Schulze wrote: > FWIW: This would mean to remove all of Mozilla and friends, since they > don't receive any security support upstream, and neither the maintainer > or the security team are in a position to backport all fixes and correcte > all stuff in the older versions. (upstream does only support the most > recent version, which will be different about one month after the sarge > release). Upstream promised and provided security support for Mozilla 1.0, 1.4 and 1.7 for a period of 1 year after release. However, none of the updates for 1.0 made it into Woody. Roger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to output Unicode?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vladimir Panteleev <[EMAIL PROTECTED]> writes: > Simplified problem statement: make a program that outputs the MS-DOS > ASCII table to the console (0x32 - 0x255, without control characters). comp.os.linux.development.apps would be a more appropriate place to ask this sort of question. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCXFDpVcFcaSW/uEgRAlT9AJ9uYKsPbtBKv+rWODgQvE+34v4z4wCfW+/s PgmlkufY2MpgcE3oHtQLTug= =Gy7k -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#304521: ITP: wanna-build -- Database management for package (re-)compilation/status control
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesus Climent <[EMAIL PROTECTED]> writes: > * Package name: wanna-build > Version : 2005.04.13 > Upstream Author : FTP Archives -- <[EMAIL PROTECTED]> > * URL : deb http://db.debian.org/ debian-admin/ If you haven't already, you might like to pick up the manpages I wrote from here: http://people.debian.org/~rleigh/buildd/ I posted this to the buildd-disc list quite some time ago, but they were never committed. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCXX0wVcFcaSW/uEgRAqYOAJ9e4yF0CxOVuMovzI9v5QB9sIJnagCfdXMZ 4YUiYx8gTLk/LPA9fm8Fcb8= =nE2r -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian sarge is 3.2 or 4 ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrea Mennucc <[EMAIL PROTECTED]> writes: > Jaldhar H. Vyas wrote: >> On Fri, 6 May 2005, Marc Haber wrote: >> >> >>>Their fault for releasing a book about unreleased software which is >>>bound to be outdated the day that sarge will actually release. >> >> >> Uh-uh and when will that day be? And don't give me any of that "when it >> is ready" nonsense. The release version number was ready a long time ago. >> The problem isn't a concern for quality, it is people like you and Andrea >> who don't follow process, > > me, I do my part of the work in Debian and nobody ever contacted me > regarding the choice of the number No-one contacted me, either. But that's OK, since it wasn't my choice. I really couldn't care less what the number was, in any case. FWIW, I've noticed that "3.1" is already used in quite a lot of documentation and on websites with articles relating to Debian. It was announced quite some time ago, and so it would be rather inconsiderate [gross understatement] to change it at this late stage. Have you considered the huge impact of changing the version number? It's to no-one's advantage to do this. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCfQ8sVcFcaSW/uEgRAnVKAJ9w0BGmEqX1G09ki0wYhUlomeWIewCgpkLR /DXbURBIm2niQSIYeDp1cEI= =R/6k -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /usr/lib vs /usr/libexec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Waitz <[EMAIL PROTECTED]> writes: > hoi :) > > On Mon, May 09, 2005 at 03:45:32PM +1000, Russell Coker wrote: >> Should we change some of these to /usr/libexec? > > well, it would be against the FHS, I think. > > The BSDs use libexec but I don't really see a good reason why it exists. The only reason we don't have it is because of petty bickering and politics between the FHS folks (several years ago). There were few technical objections to it on the FHS list, but it was dropped for non-technical reasons. Given that the FHS is supposed to codify existing practice, it should be in there on that count alone. Every libexec-using package in Debian has been reconfigured not to use it; upstreams do use it, and I'd like to use it myself. I'd personally be very glad to have it, and would support using it in Debian. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCgRvZVcFcaSW/uEgRAlcpAJ920/c0RktK+9FjORJNfNEushYhsgCg7H8h tJo3qJd/a4eyOnGGHOXjdwc= =7Ppv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RES: /usr/lib vs /usr/libexec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernd Eckenfels <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]> you wrote: >> I do believe you've missed the point. Splitting /usr from / helps in >> a teeny percentage of cases, and most of the cases where it "helps" >> that have been mentioned here, it actually doesn't. Yet, splitting >> /usr/lib, which is grotesquely huge and hard to deal with, is treated >> as an impossible thing, needing a great level of proof before it can >> be considered. This is very foolish. > > Thats why we need proof that it helps. Nobody has provided any numbers, > here. IMHO the performance benefits are a red herring. For myself at least, the general increase in tidiness would be far more beneficial. > You missed the point. It is not about getting rid of directories it is about > creating a new one. Not really; it's already in common use. However, all packages committing the sin of using it have to be specially patched or configured to remove the taint. - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCik77VcFcaSW/uEgRAgySAJ45AQx5BOfCZsQOeJi6vOzDrFNHqgCeLOxs 9suFJefavjQNSlcxG5HXj28= =eNR8 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RES: /usr/lib vs /usr/libexec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Russ Allbery <[EMAIL PROTECTED]> writes: > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > >> I do believe you've missed the point. Splitting /usr from / helps in a >> teeny percentage of cases, and most of the cases where it "helps" that >> have been mentioned here, it actually doesn't. Yet, splitting /usr/lib, >> which is grotesquely huge and hard to deal with, is treated as an >> impossible thing, needing a great level of proof before it can be >> considered. This is very foolish. > > The difference being that Debian has already split /usr from / and > therefore is only paying the marginal cost of maintaining it, whereas > Debian has not split /usr/lib from /usr/libexec and would have to pay the > (far larger) initial cost of moving everything around. Not really, since in many cases libexec was /already the default/. In these cases we are deliberately diverging from upstream, and so we would be removing extra patches and customisations from our diffs. Additionally, the migration is not difficult, and can be done over an extended period. It's not like I want a flag day when we must all convert, I just want the option of using it. The only reason we don't have it is FHS infighting, otherwise we would have been using it eight years ago. I don't consider that a good reason to ignore it. > I think it's quite reasonable for that far larger initial cost to require > substantial justification, far more justification than is required for > preserving a property that Debian has already paid the cost to establish > and is just maintaining. We've paid the price by shoving every bit of uncategorised junk into one big festering sore: /usr/lib. Making it a little tidier by categorising some of its contents slightly differently is not a bad thing. - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCilCxVcFcaSW/uEgRAhC/AJ4gdjPtblrEzDRYZiydvm4hoiPtVACg8zSW SGl0MKKQNHEHjNXhd5BrptQ= =xMFl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian as living system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Suffield <[EMAIL PROTECTED]> writes: > On Wed, May 18, 2005 at 03:46:33PM +0200, Rapha?l Pinson wrote: >> I agree that the previous mail was not very easy to read, nor written in a >> great english. But I don't think that being fluent in english should be a >> requirement to be treated nicely on a development list... > > I *could* have simply ignored him. That would have been much better; please do so in the future. If you don't have anything worthwhile to contribute, silence is preferable. - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCi5TXVcFcaSW/uEgRArdxAJ9O8LGLBAaUnHKDxhwIhSE5Z42quwCgxgCG JYs1EZMm5UY/AGLe26SFqm8= =1195 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian as living system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adam Heath <[EMAIL PROTECTED]> writes: > On Wed, 18 May 2005, Roger Leigh wrote: > >> Andrew Suffield <[EMAIL PROTECTED]> writes: >> >> > On Wed, May 18, 2005 at 03:46:33PM +0200, Rapha?l Pinson wrote: >> >> I agree that the previous mail was not very easy to read, nor written in a >> >> great english. But I don't think that being fluent in english should be a >> >> requirement to be treated nicely on a development list... >> > >> > I *could* have simply ignored him. >> >> That would have been much better; please do so in the future. If you >> don't have anything worthwhile to contribute, silence is preferable. > > This applies to the original poster as well. And how else are they going to > know that what they want to discuss is worthless, after they've already done > it, unless we tell them? There are ways of telling people things without being unduly offensive. debian-devel has acquired a reputation for being rather unfriendly and intimidating place, but there's no need to perpetuate that. Politeness doesn't take much more effort than being rude. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCi8gXVcFcaSW/uEgRArfUAKCVFKmTIeowAj+72lu3fHcneXY9DQCfRSvb JuIArGKWP6quQnR5Dq2nepo= =jwdV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release update: minor delay; no non-RC fixes; upgrade reports
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
"Roberto C. Sanchez" <[EMAIL PROTECTED]> writes:
> On Mon, May 30, 2005 at 12:59:26PM +0200, Adrian Bunk wrote:
>>
>> Finding these issues is one of the prices for freezing testing
>> instead of unstable [1].
>
> CMIIW, but isn't unstable a place where architectures can be out of
> sync? To get into a testing, a package has to pass the cooling off
> period with no >important bugs and must be in sync on all
> architectures. Correct? Freezing unstable doesn't make much sense
> if it means lots of extra work just to sync up package versions
> across architectures. The only that would work is to require that
> packages successfully build on all architectures *prior* to being
> admitted to the archive.
I think this misses the point. Consider a package present in both
testing and unstable, and later it has an RC bug filed against it,
which is subsequently fixed by an upload to unstable. The bug is
closed, but it's still present in testing. There's currently no way
to automatically and easily find these bugs. Thus there may be many
RC bugs in testing of which there is no trace in the BTS.
After testing freezes, we need a way of saying ("we need fixes x, y
and z from unstable to fix these unfixed RC bugs in testing").
This is at least how I understand what Adrian is saying. It's
something I hadn't considered before, and certainly deserves serious
consideration.
The BTS does not currently support this. For example, if I upload a
fix to unstable, I have to manually reopen it and tag it sarge.
Regards,
Roger
- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFCmywlVcFcaSW/uEgRAvJsAJ9x3vHEHtjfVaqUz5R5w7od0AhD6ACfZa8+
BIn4zRHMM93rPL00ZLAPPJU=
=w+hP
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release update: minor delay; no non-RC fixes; upgrade reports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 sean finney <[EMAIL PROTECTED]> writes: > hi, > > On Mon, May 30, 2005 at 04:07:50PM +0100, Roger Leigh wrote: >> The BTS does not currently support this. For example, if I upload a >> fix to unstable, I have to manually reopen it and tag it sarge. > > or, you could always not close it in your changelog, and update the > bug accordingly. That's still requiring /manual intervention/, and lying about the true state of the bug to the BTS. Ideally the BTS should understand that the bug was closed by a particular version of the package (the one which had Closes: in it), and the bug is still present in earlier versions (perhaps it should also have the ability to record the version the bug appeared in as well). The BTS should be able to know that a bug is closed in testing automatically, rather than me sending messages to [EMAIL PROTECTED]; I must have sent at least 30 the past week alone. - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCm0c7VcFcaSW/uEgRAid/AKDY9g7nBmt5Uas75qEDn3DV8W/SqwCfS38s iGxStFkbWJMun6u82VMn67c= =twfh -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Goerzen <[EMAIL PROTECTED]> writes: > On Wed, Jun 01, 2005 at 11:47:46AM -0700, Matt Zimmerman wrote: >> Ubuntu developers already participate in team maintenance in Debian, and >> this works well, but in the traditional Debian maintainer model, there are >> just too many obstacles for this kind of direct participation. > > I think it is high time we revisit the traditional Debian maintainer > model. We have been aware of its weaknesses for years, and are most > biting in the areas of nonresponsive maintainers. I think we should > devote some thought to declaring a permanent bug-squashing party and > relaxing the rules for NMUs (for instance, let them happen for any > documented bug of any severity so long as they are uploaded to the 5-day > delayed queue and patches are posted to the BTS at the time of the > upload). One small step down that road, anyway. I agree strongly with this. However, it's only fair to post the patch to the BTS to give the maintainer a chance to respond before uploading at all. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCnjMTVcFcaSW/uEgRAhyMAKCKdXAJD6hU/dOZEsotvPGwPhA8dACcDn9Q R8x8kDEjZcqdRrPVOORRcTg= =qZgi -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matt Zimmerman <[EMAIL PROTECTED]> writes: > On Thu, Jun 02, 2005 at 09:17:46AM +0200, Andreas Tille wrote: > >> In your first mail you wrote about "mass-mail Debian maintainers" in the >> second mail you turned my request to file wishlist bug reports against >> single packages into "mass-filing bugs in the BTS". > > If all of the patches were to be filed in the BTS, automation would be the > only feasible way to do it. It has been said that it is too much of a > burden for Debian maintainers to process the patches, and Ubuntu currently > has a miniscule number of developers compared to Debian. Given the length of time it takes to make and test a change to a package, it doesn't take much effort to run 'diff -urN' and fire a mail at the Debian maintainer or run reportbug. We're talking minutes for each diff. Just as an example, there have been a number of patches to my gimp-print package made by ubuntu over the last year, mostly trivial. If they had been filed as wishlist bugs, they would have been reviewed, applied and uploaded within a week (or whenever I next intended to uploaded), rather than being sat on for eight months. Digging through the ubuntu patch collection to find them shouldn't have been necessary. Martin Pitt did mail me the last changes he made: they were applied an uploaded within two days. My point is simply that I personally would like to see ubuntu patches filed directly as wishlist bugs against my packages, and wouldn't consider it mass bug filing (they are mostly separate issues, to be dealt with separately). The worst I can do is disagree with the change and close it, but the norm would be reviewing and applying the patch ASAP. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCn10VVcFcaSW/uEgRAhyvAJ9DVu1VX1i/5xzlA440mlyIEnuhhACgw5lv DUuzJG3DkrgM0y2G1Jstdkk= =5hno -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux / Debian / Ubuntu
On Tue, 31 May 2005 21:37:28 -0700, Stephen Birch <[EMAIL PROTECTED]> wrote: > Darren Salt([EMAIL PROTECTED])@2005-05-31 21:49: > > For those who've missed the first three broadcasts today, there's one more > > at > > 01:05 GMT; also see http://news.bbc.co.uk/2/hi/technology/1478157.stm>. > > Why on earth does the BBC force its listeners to all hit its servers > at the same time. Doesn't make sense at all, why not ogg the program > up and put it on its servers so the audience can listen when they > want. Huh? You can listen to the programme any time you like. (Admittedly you're restricted to RealPlayer or Windows Media Player, but at least there are cross-platform players available for RealPlayer.) > Okay, so I know the answer. The BBC is still coming to grips with the > idea that "boradcasting" is dead. The tech generation wants to time > and space shift programming to a convenient time/location. You can do exactly that. The vast majority of the BBC's radio output is available to listen to whenever you want, up to a week after broadcast, and has been for some time. Roger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> writes: > Feel free to add some new items or add (hopefully new) information to the > ones I list below: [Transition to UTF-8 locales] - - The locale codeset should be UTF-8 for all new installs by default. - - Existing installations should be unaffected, but it might be nice to offer to generate the equivalent UTF-8 locales for the locales in use. - - When UTF-8 is the default locale, it shouldn't need a .UTF-8 suffix, e.g. en_GB will be UTF-8, and en_GB.ISO-8859-1 will be Latin-1 (the opposite way round to the current situation which creates en_GB.UTF-8 and en_GB [Latin-1]). This change has (as far as I can tell) been done already by most major commercial distributions (e.g. SuSE, RedHat). The actual mechanics of the transition should be fairly straightforward, since UTF-8 locales are already supported, this is simply switching the defaults in the locales package. This won't affect existing installs, so breakage should be none to minimal. At a later point, we should also look into recoding our documentation into UTF-8. While reviewing RC bugs for sarge, I found that the DocBook toolchain is quite broken WRT text encoding support. It doesn't put the encoding in the generated HTML, which nowadays is not acceptable. See gnupg-doc for examples. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCpf8qVcFcaSW/uEgRArXjAKDdfCkwr+mPzTrZ868BLhseYZBrBACgrlsF p131Thi/tFD6l21V0ttqMqs= =u6JO -END PGP SIGNATURE-
Re: And now for something completely different... etch!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frans Pop <[EMAIL PROTECTED]> writes: > On Tuesday 07 June 2005 22:10, Roger Leigh wrote: >> - When UTF-8 is the default locale, it shouldn't need a .UTF-8 >> suffix, e.g. en_GB will be UTF-8, and en_GB.ISO-8859-1 will be Latin-1 >> (the opposite way round to the current situation which creates >> en_GB.UTF-8 and en_GB [Latin-1]). >> >> [...] >> This won't affect existing installs, so breakage should be none to >> minimal. > > This looks to be a contradiction. > If you make UTF-8 default and remove the suffix for UTF-8 usage, won't > existing installs that have LANG=en_GB in their /etc/environment be very > much affected? Existing installs are already configured with debconf. Their /etc/locale.gen will not be touched. If you do dpkg-reconfigure locales, then users could have the locale switch to UTF-8 if they so choose. The system should then carry on working like normal, except for the fact that they are now using the UCS. There is potential for breakage if they have any software that does not behave correctly in a UTF-8 locale. IMO we should treat such packages as being seriously buggy, and get them fixed or removed. Nowadays, there should be few pieces of software that break this way, and there is really no excuse for it. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCpgtjVcFcaSW/uEgRAjhTAJ9M88ZCAnn0y8Jiu72o/FjXzhZygQCeNCj3 3VI05CfJlqFl04kWuH9QxAk= =Dp6t -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tollef Fog Heen <[EMAIL PROTECTED]> writes: > * Roger Leigh > > | - When UTF-8 is the default locale, it shouldn't need a .UTF-8 suffix, > | e.g. en_GB will be UTF-8, and en_GB.ISO-8859-1 will be Latin-1 (the > | opposite way round to the current situation which creates > | en_GB.UTF-8 and en_GB [Latin-1]). > > Eh? You can't change that around just like that, it will break in the > cases where people ssh in from machines with latin1 locales for > instance (and use the PassEnv feature of newer SSHs). IMHO if you want features like that to work, you should be fully qualifying your locale. en_GB on its own has always meant "British English", in whatever locale the system administrator set as the default, and the same applies to all unqualified locales. Sure, ssh might not work, but it /never has/, except by coincidence where two systems had the same locale setup. I've used UTF-8 default locales for several years now, i.e. [/etc/locale.gen] en_GB UTF-8 > To me, it looks like you can't ever change the charset of a locale > once it is created. I don't agree. For the last three years, I've created them the "new way", in contradiction to the default. Nowhere is it defined what the existing unqualified locale names mean, save in the defaults, so there are no guarantees here: they could have been set to /anything/. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCphGCVcFcaSW/uEgRAhrWAJ9A7bJUUvPXhFBMwy5t8AYCWOiJFQCg9fs1 N6b7o4vasTzKoJBAVOVgLUY= =hMs9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frans Pop <[EMAIL PROTECTED]> writes: > On Tuesday 07 June 2005 23:02, Roger Leigh wrote: >> Existing installs are already configured with debconf. Their >> /etc/locale.gen will not be touched. >> >> If you do dpkg-reconfigure locales, then users could have the locale >> switch to UTF-8 if they so choose. > > AFAIK locales are automatically regenerated when the locales package is > upgraded, so this _would_ effect every existing install directly on > upgrade to the new release. locale-gen is run, but /etc/locale.gen is not necessarily altered. If you don't change it, it will regenerate the same locales you already have. - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCphJnVcFcaSW/uEgRAo2hAJ48AnTc2UPfaT8maeMOYuBV1rPT2wCcDAEk tVJEz0PvV79FVZ9tPsqQZv0= =AUNx -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] (Marco d'Itri) writes: > On Jun 08, Josselin Mouette <[EMAIL PROTECTED]> wrote: > >> As we have hundreds of broken packages assuming e.g. that the filenames >> on disk are encoded in the current locale's character set, the only way >> to make them interact properly with other applications is to set a >> UTF8-locale. > Wrong. The problem is packages which need to interact with text files, > mail and usenet messages generated by broken software, and for which > assuming UTF-8 would be totally wrong. This is completely orthogonal to making UTF-8 the default locale codeset. The transition will in no way affect your need to use an old-fashioned 8-bit locale codeset if you need to do that. I fully expect that many people will do exactly this for years to come, and the changing of the *default* will not prevent this. Please bear in mind that this is a change we need to make, which most of the major commercial distributions did over a year ago, if not before. Have you tried installing a recent SuSE or RedHat to check this? When I checked late last year, all locales were UTF-8 by default. We should have done this long before sarge was released. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCp1AlVcFcaSW/uEgRAs6GAJ4vMt+LVtRtt1xkLtLVF+vNWJQgVACgiZkb 6rnIalPBufuLiu0gi+2LjNI= =BSIL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Colin Watson <[EMAIL PROTECTED]> writes: > On Tue, Jun 07, 2005 at 10:28:37PM +0100, Roger Leigh wrote: >> Tollef Fog Heen <[EMAIL PROTECTED]> writes: >> > Eh? You can't change that around just like that, it will break in the >> > cases where people ssh in from machines with latin1 locales for >> > instance (and use the PassEnv feature of newer SSHs). >> >> IMHO if you want features like that to work, you should be fully >> qualifying your locale. > > en_GB.ISO-8859-1 doesn't exist unless you go to the effort of defining > it yourself - it's not in /usr/share/i18n/SUPPORTED. (Yes, in this case > there happens to be an ISO-8859-15 equivalent, but that's not the case > everywhere.) > > I'm fairly sure I remember glibc upstream vowing never to change the > meaning of existing locales. Certainly this post from a locale hacker > well-known in these parts comes to mind: > > http://lists.debian.org/debian-i18n/2004/10/msg00075.html I see. If it needs to be kept that way for backwards-compatibility, that's fair enough. It's interesting that they chose "eo_EO UTF-8" and "eo_EO.ISO-8859-3 ISO-9959-3" as the locale names, though! (If it's a new locale, I guess there are no problems with that.) > /usr/share/i18n/SUPPORTED is a little more than "the defaults", I think. > It's at least standard across systems that use glibc (in that you may > get additional entries, but you won't get different entries). This makes > up sufficiently many systems to make me pay attention. I took the list to mean the set of locale/codeset combinations supported by the C library locale data, and assumed it was my choice to name them as I saw fit. I do worry that in 5 years time we will hate the fact that we *must* qualify our locale with ".UTF-8" despite the fact it is the default. I already find it really annoying, hence the reason I renamed them. That said, I'd still like UTF-8 to become the default, whatever the locale naming scheme we have to use. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCp1SYVcFcaSW/uEgRAuFEAJ0YVLctuf0aCNjLR0GncDgtCyjJJwCg8C8b +UXXHesnbtDmdHHJ8qM+Lcc= =rrjD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] (Marco d'Itri) writes: > On Jun 08, Roger Leigh <[EMAIL PROTECTED]> wrote: > >> > Wrong. The problem is packages which need to interact with text files, >> > mail and usenet messages generated by broken software, and for which >> > assuming UTF-8 would be totally wrong. >> This is completely orthogonal to making UTF-8 the default locale >> codeset. > No, it's not because most applications do not allow setting a different > "default charset". Please could you re-read what I wrote? What you are saying does not follow from that. By default locale charset, I'm referring to the defaults in the locales package, which are used to generate /etc/locale.gen. If you don't want UTF-8 locales, choose the alternatives at this point. End of problem. If you chose both UTF-8 and old locales, there's also the system default in /etc/environment, which you set to whatever you want. In addition if you don't want this systemwide default, you just choose a different locale, or override it in your .bashrc or with gdm or wherever. Where's the difficulty in that? >> Please bear in mind that this is a change we need to make, which most >> of the major commercial distributions did over a year ago, if not >> before. > This hardly makes it a "need". GNU/Linux has been slowly moving to UCS since the late '90s. We are now well past the point where it's mostly usable and ready for proper use. Debian is well behind the times here. As something to ponder: with all current gcc's in Debian, UTF-8 and UCS-4 are used as the internal narrow and wide string literal encoding in all binaries, independent of the C source encoding. See http://groups-beta.google.com/group/comp.lang.c.moderated/browse_thread/thread/b421c9ec1894f818/a688cf269948db80#a688cf269948db80 for an example. > Unsurprisingly, looks you live in a country where anything else than > US-ASCII was rarely used in the past. ISO-8859-1 actually. But this is not really topical. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCp2MPVcFcaSW/uEgRAlmfAKCbH0iNvjcmYzKXWh0bx20/ckQ18wCdHWgx ouiUnSYJUM9x4ggBFhDhFr8= =GfSG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: And now for something completely different... etch!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adrian von Bidder <[EMAIL PROTECTED]> writes: > On Tuesday 07 June 2005 23.32, Roger Leigh wrote: >> Frans Pop <[EMAIL PROTECTED]> writes: >> > On Tuesday 07 June 2005 23:02, Roger Leigh wrote: >> >> Existing installs are already configured with debconf. Their >> >> /etc/locale.gen will not be touched. >> >> >> >> If you do dpkg-reconfigure locales, then users could have the locale >> >> switch to UTF-8 if they so choose. >> > >> > AFAIK locales are automatically regenerated when the locales package is >> > upgraded, so this _would_ effect every existing install directly on >> > upgrade to the new release. >> >> locale-gen is run, but /etc/locale.gen is not necessarily altered. If >> you don't change it, it will regenerate the same locales you already >> have. > > But 'the same locale I already have' would probably mean 'the locale with > the name of the locale I previously had' which has now suddenly changed its > behaviour. This would be safe, since the locale codeset is part of the name. When the current locale selections are merged with i18n/SUPPORTED, it wouldn't change anything behind your back. But this is probably the wrong approach, as others have said. I've since made a patch, and filed this as bug #312927. I'd appreciate any comments. It's a trivial and (I hope!) non-controversial change. It certainly won't affect the choices of or the behaviour of the available locales; it rather just recommends that UTF-8 locales be used unless the user has a good reason not to. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCqgNnVcFcaSW/uEgRAjXFAKCL4YoHDw9OI4mhs/LnQ9pjZK0ucACbB4Ch vFjugEqBcVCNMlTVoMRV4cU= =usOo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Planning a libglade to libglade2 transition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Garrett <[EMAIL PROTECTED]> writes: > Martin Michlmayr <[EMAIL PROTECTED]> wrote: >> * Matthew Garrett <[EMAIL PROTECTED]> [2005-06-14 13:48]: >>> libglade2 is the GTK2 version of libglade, so it would have to be a >>> GTK->GTK2 transition. >> >> And how hard is that? It seems that tons of stuff in the archive >> still requires GTK1. It would be great to move them all to GTK2. > > For anything that uses custom widgets, it's miserable. That's true, but for the majority of code, which just uses existing GtkObjects, conversion is no much more involved than search-and-replace. Plus, if you don't bother with the full conversion, there's quite a lot of compatibility functions to make things easier. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCrytBVcFcaSW/uEgRAtOBAKC1cCdHlURo2sHbfiTpeUEc86fjjQCggWF1 Rx7pIQ/SWJxfoVteGFQwrRM= =mXbT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Planning a libglade to libglade2 transition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Tille <[EMAIL PROTECTED]> writes: > On Tue, 14 Jun 2005, Roger Leigh wrote: > >> That's true, but for the majority of code, which just uses existing >> GtkObjects, conversion is no much more involved than >> search-and-replace. Plus, if you don't bother with the full >> conversion, there's quite a lot of compatibility functions to make >> things easier. > I would be very thankful for links to aprorpiate search-and-replace > expressions or compatibility functions. Once I was searching for > this kind of stuff I failed. I don't have any links I'm afraid. I only learnt GTK+ 2.0, and never used 1.2. I did the work with nothing more than both API references. It's a while back, but it was basically: gtk_object_* -> g_object_* (except for gtk_object_destroy) gtk_signal_* -> g_signal_* and the same applies to all the casts: GTK_OBJECT -> G_OBJECT That was about 80% of all the changes, but note that this is not strictly required: all these have compatibility wrappers. The rest of the changes were a little more involved (IIRC the object property API is different), but in most cases it was simply a matter of finding an appropriate equivalent and doing a little reworking. YMMV, since it depends on exactly what GTK+ features the code uses. If you like, I can take a look at it and suggest what needs doing. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCr1WhVcFcaSW/uEgRAhD9AJ9LYY0WwIa74V6RSZrvDUb9UlYemwCg3XmX FO6RZJoFlagNXZOOZ9JvprM= =bQKG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
schroot: a replacement for dchroot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks, Over the last week or so, after wanting features that dchroot didn't provide, I've written a replacement: schroot. This is mostly command-line compatible with dchroot, but provides additional functionality, such as su/sudo-like behaviour: - - access restricted by group - - ability to switch user id - - passwordless root for authorised groups - - tighter security checks than dchroot - - PAM authentication and authorisation - - Full logging of chroot operations It was mainly written as a replacement for sudo in sbuild, but has more general uses than that. If you have chroots, and currently use dchroot, you might like to give schroot a try. If there are any security and/or PAM experts here, I would be grateful if you could spare a few minutes to check the code. I'm pretty sure it's fine, but it's the first PAM-based program I've written, and there may be subtleties I've missed. http://people.debian.org/~rleigh/schroot/ (packages and original source) I won't upload this as a standalone package yet, in case the sbuild maintainers would like it as part of sbuild CVS and packaging. Comments welcome! Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCta79VcFcaSW/uEgRAlBCAJ9FWuujVVc+kPWLc8APrz2TdnUYBgCg4tER FV1lHOGUUBc6i7vqVuaU4Ic= =AHI4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#315104: ITP: schroot -- Execute commands in a chroot environment
Package: wnpp Severity: wishlist Owner: Roger Leigh <[EMAIL PROTECTED]> * Package name: schroot Version : 0.1.0 Upstream Author : Roger Leigh <[EMAIL PROTECTED]> * URL : http://people.debian.org/~rleigh/schroot/ * License : GPL Description : Execute commands in a chroot environment schroot allows users to execute commands or interactive shells in different chroots. Any number of named chroots may be created, and access permissions given to each, including root access for normal users, on a per-group basis. Additionally, schroot can switch to a different user in the chroot, using PAM for authentication and authorisation. All operations are logged for security. . schroot shares most of its options with dchroot, but offers vastly more functionality. The above URL is temporary. It should shortly be moved from a local Arch repository to buildd-tools CVS on Alioth. sbuild will use it in the future to allow a "true-chroot" mode for apt-get/dpkg. Regards, Roger -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12 Locale: LANG=en_GB.UTF8, LC_CTYPE=en_GB.UTF8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#315104: ITP: schroot -- Execute commands in a chroot environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roger Leigh <[EMAIL PROTECTED]> writes: > Upstream Author : Roger Leigh <[EMAIL PROTECTED]> > * URL : http://people.debian.org/~rleigh/schroot/ > * License : GPL > The above URL is temporary. It should shortly be moved from a local > Arch repository to buildd-tools CVS on Alioth. sbuild will use it > in the future to allow a "true-chroot" mode for apt-get/dpkg. schroot is maintained by the Debian buildd-tools project. It was downloaded from :pserver:[EMAIL PROTECTED]:/cvsroot/buildd-tools (module "schroot"). Full instructions are available here: https://alioth.debian.org/scm/?group_id=30471 Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCuFxNVcFcaSW/uEgRAr8IAKDKr/giJSzpC1BrvF1hWyK+hu8mdgCgphwV /z3kMNyz9bhgmBdGWyfA3jc= =1HiT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Lintian tar error outdated?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 E: schroot source: source-tar-is-posix-tar schroot_0.1.1.orig.tar.gz N: N: The source tar archive of this package is made with tar --posix. This N: tar format is actually not understood by woody's tar. N: N: Some automake 1.7 and 1.8 versions in Debian had this wrong tar option N: for a short time, re-autobuilding should solve this. Please see N: http://lists.debian.org/debian-devel/2004/debian-devel-200404/msg01376 N: .html and N: http://lists.debian.org/debian-devel/2004/debian-devel-200404/msg01586 N: .html for more details. I've been deliberately using POSIX PAX tar format for quite a while now (over a year) using automake's "tar-pax" feature, and a custom-patched automake prior to that. It's required for long pathnames, a real problem with Doxygen, for example. Now sarge has been released, is it OK to use newer tar formats? Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCuGt7VcFcaSW/uEgRAtdhAKD0Cw+nQhNT0dOQv89mErXReGzo/QCdG7BO tkHdy8bb/GQ9tsWo6FLZKM8= =lfYf -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Debian Printing] Formation of a Printing Group
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks, Printing under GNU/Linux has always been complex, and although it works quite well nowadays, it's still difficult and error-prone. Debian has a large number of interdependent printing packages, and generally a unique maintainer for each. We could probably improve on this. This mail is just to test the water to see if there is any interest in forming a printing group for coordination between all of the various printing packages. Due to the numerous ways of setting up a working printing system, bugs in one package are often in interdependent packages, and this would ease coordination. It's often the case that you don't know enough about the internals of another component to properly debug and fix your package. If we were all aware of the bugs in related components, this would speed up getting things fixed, and hopefully make all our lives easier. It would also be an opportunity for getting some group maintenance of key packages. I will be happy to have a co-maintainer for gimp-print, but because it requires knowledge of several other systems (cups, ijs, foomatic, gimp, gs etc.), it would be best if another printing maintainer took it up initially. If we could use e.g. [EMAIL PROTECTED], this could be used as a place for all printing bug reports to be forwarded to, as well as user questions, coordination, etc. Any thoughts or comments? [I've only included the major printing subsystems and drivers in the mail. Please CC any other maintainers you feel might be interested.] Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCvwvoVcFcaSW/uEgRAmwaAJ9KHOkPZTDcA7wSwxQViNkB1j3gwACghSI3 FP0hIc+X8XbIDCKRFFGwUPc= =4H2S -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Olaf van der Spek <[EMAIL PROTECTED]> writes: > On 6/27/05, John H. Robinson, IV <[EMAIL PROTECTED]> wrote: >> (and thusly /usr/bin) between architectures. You can with /usr/share, as >> it is architecture independent. > > I guess the tools aren't capable of this, but AFAIK you could just do > (manually) something like /usr/i386/bin and /usr/ppc/bin The whole cpu-manfr-opsys triplet would be better. - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCwGJMVcFcaSW/uEgRAriMAJ0YU6TtmeRW+qkRqOQLtz6kK/19+QCgpzjk pXJqACsbJaQT4vq+1mvBy9w= =wA6L -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#315903: ITP: evilfinder -- proves that any given subject is evil
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miles Bader <[EMAIL PROTECTED]> writes: > Glenn Maynard <[EMAIL PROTECTED]> writes: >> It's a novelty joke program. If that's a "great utility" in your view, >> then I find your opinion hard to take seriously ... > > So is debian "business apps only" now? No, but it doesn't hurt to exercise restraint before packaging every tiny utility out there. Debian is already too big. - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCwYloVcFcaSW/uEgRAtu2AJ9ggnKi4fwNI5DLo/U5MobLQ3AFfACePJof 83UQYv2A+ChNFvT15o2q7CI= =aZCh -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
New gimp-print packages in experimental
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks, gimp-print (renamed to gutenprint) is near its 5.0 release. I've uploaded a prerelease to experimental, which is also available here: http://people.debian.org/~rleigh/gutenprint/experimental/4.3.99+cvs20050702-1/ It integrates with a number of other packages, and so I would be grateful if the respective maintainers could test it before it enters unstable. General upgrade testing would also be appreciated. - - cupsys, tested with an Epson Stylus C60 - - ijsgutenprint, tested with an Epson Stylus C60 - - foomatic data needs testing - - gs-esp and gs-gpl need to remove the STP patch, which is no longer supported. Once gutenprint enters unstable, they will no longer build from source otherwise. - - gimp (gimp-print) needs testing after the current FTBFS bug has been fixed (#316538). - - cinepaint needs updating to use and build depend upon libgutenprintui-dev. - - apsfilterconfig can no longer provide the stp driver "4) gimp-print (stp driver [DEPRECATED - use ijs]; version 4.2.x)" which will be removed from gs. In addition to these specific packages, any other packages which depend indirectly on libgimpprint, ijsgimpprint, the foomatic data or other gimp-print features should be converted and tested to work with 5.0.0. I would be very grateful for anyone who has time to build and install the packages, and report any upgrade failures. Any regressions in print quality, colour reproduction, usability, integration with other packages etc. will also be very helpful. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCxqOQVcFcaSW/uEgRArK7AKDnk1tHHJsmAa9aHAoDd8PRK//xwgCfcy+T ZcSuPTycXKkJbpEk4jqQra0= =fqQH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian Printing] Formation of a Printing Group
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rob Taylor <[EMAIL PROTECTED]> writes: > On Mon, 2005-06-27 at 11:27 +0900, Kenshi Muto wrote: >> At Sun, 26 Jun 2005 21:11:22 +0100, >> Roger Leigh wrote: >> > This mail is just to test the water to see if there is any interest in >> > forming a printing group for coordination between all of the various >> > printing packages. >> Oh, Masayuki who maintains gs packages and I had thought same idea. >> It's very nice to have a place to collaborate together. > > I'd certainly be interested in joining in on the printing love-fest. Super. I've requested the creation of debian-printing (#316646). If anyone has anything else to add to the bug, please submit it. Thanks, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCytcwVcFcaSW/uEgRAtcMAJ9gMXLu2UqbkjxfkTNG6vUcYwntUgCg4az3 8nKpY8aCXmE1wxB/tsw8dMU= =N1hZ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian Printing] Formation of a Printing Group
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> writes: > On Tue, 05 Jul 2005, Roger Leigh wrote: >> Rob Taylor <[EMAIL PROTECTED]> writes: >> > On Mon, 2005-06-27 at 11:27 +0900, Kenshi Muto wrote: >> >> At Sun, 26 Jun 2005 21:11:22 +0100, >> >> Roger Leigh wrote: >> >> > This mail is just to test the water to see if there is any interest in >> >> > forming a printing group for coordination between all of the various >> >> > printing packages. >> >> Oh, Masayuki who maintains gs packages and I had thought same idea. >> >> It's very nice to have a place to collaborate together. >> > >> > I'd certainly be interested in joining in on the printing love-fest. >> >> Super. >> >> I've requested the creation of debian-printing (#316646). If anyone >> has anything else to add to the bug, please submit it. > > Just be sure to drop us a note when the ML get created, I am all for it, xpp > and hplip/hpijs will join the printing group. The list was created today, so it's open for subscription. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GCC version change / C++ ABI change
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adrian von Bidder <[EMAIL PROTECTED]> writes: > On Monday 04 July 2005 11.51, Horms wrote: >> I am not sure about 3.4's ability to compile 2.4.27, but >> it seems unlikely to me that all of the gcc versions you mention above >> will be omitted from etch. > > I'm quite confident that the release team and/or gcc maintainers will agree > that 'is needed to compile 2.4 kernels' is a big enough reason to keep some > gcc version around if Debian gets to the point to decide which old gcc > versions should be shipped or dropped. We even have GCC 2.7.2 in unstable (gcc272). Does anyone actually use this anymore, or could it be removed for etch? - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFC0tQSVcFcaSW/uEgRAltwAJ445XH8bW9IzVFPbbcJs3bY8MaUXgCfa6Ap LKHHf7hJox+kn8w3Ds5bOI4= =LvYy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
John Goerzen <[EMAIL PROTECTED]> writes: > On Fri, Jul 28, 2006 at 07:22:11PM +0200, Marco d'Itri wrote: >> On Jul 28, Gustavo Franco <[EMAIL PROTECTED]> wrote: >> >> > Debian stopped innovating? >> Yes. This should be obvious to people who joined the project before 2000. > > I'm one, and it's not obvious to me. > > Some things that have been done since I joined debian: > [...] > > Some of these are quite recent. Agreed. However, I do feel that some package maintainers are not exercising enough thought about how their packages can better integrate with the Debian system as a whole, as well as other related packages. As an example, there are many packages not registering their documentation with doc-base, and doc-base itself could do with some work on better supporting documentation formats other than HTML. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please sign and encrypt your mail. pgpZBwI0wqfmj.pgp Description: PGP signature
Re: Why does Ubuntu have all the ideas?
[EMAIL PROTECTED] (Marco d'Itri) writes: > On Jul 28, John Goerzen <[EMAIL PROTECTED]> wrote: > >> * xen integration > Everybody that matters is doing this. > BTW, where is this integration visible? > Do we have a VM provisioning system? Just for the record, once xen is both integrated into the kernel.org kernel and running on powerpc, I will be adding "xen" as a new backend type to schroot, so a xen instance may be created from e.g. an LVM snapshot. This will also have a nice side-effect in providing dchroot and dchroot-dsa with transparent access to xen hosts, so you could e.g. use it for package building and allow individual users root access to individual xen hosts. [I need the powerpc support so I can run a Xen system; if anyone else wanted to take up the challenge, it could be done much sooner.] Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please sign and encrypt your mail. pgpGrQpmgvi9j.pgp Description: PGP signature
Re: Successful and unsuccessful Debian development tools
Frank Küster <[EMAIL PROTECTED]> writes: > Eduard Bloch <[EMAIL PROTECTED]> wrote: > >> #include >> * Marco d'Itri [Tue, Aug 01 2006, 09:53:21AM]: >>> On Aug 01, David Nusinow <[EMAIL PROTECTED]> wrote: >>> >>> > Also, pbuilder and debootstrap are considered absolutely critical for >>> > serious work. >>> That's a bold statement. >> >> Are you serious? (SCNR ;-) >> >> No, debootstrap is an important toy but but pbuilder is hyped too much. > > I think maintainers should really build and test their packages in > clean sid chroots. It's not important Whether these are set up with > debootstrap or any other method, and whether the handling is done > with pbuilder, manually or with other tools. But it should be done, > and since these are the only tools for the purpose I know of, and > people don't like to do all by hand, I think they are in fact very > important. There is also sbuild (which may be used with or without schroot to manage the chroot). I prefer it to pbuilder, but I may be a little biased ;-) -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please sign and encrypt your mail. pgpf7yeY9M6tH.pgp Description: PGP signature
Re: Successful and unsuccessful Debian development tools
Christian Aichinger <[EMAIL PROTECTED]> writes: > On Tue, Aug 01, 2006 at 10:24:32AM +, Reinhard Tartler wrote: >> The sbuild package in debian however adds more features, like >> schroot support. With this, it can use schroot to create >> temporary, clean chroots from tarballs, block devices, create lvm >> snapshots on the fly and so on. I read Roger, that even xen >> support is planned. Xen support is planned, but not for the immediate future. I'm waiting on its inclusion in the kernel, and a working powerpc32 port. So it's more of a medium- to long-term goal, unless there are any Xen fanatics who step up to do it sooner :) >> schroot is another very very useful tool. It gives me more or less >> instant access to clean chroots on lvm snapshots for experimenting, >> building, developing and testing. > > When I didn't know schroot could do this I wrote a script to do that > myself: > http://greek0.net/lvmchroot/lvmchroot_0.5-1.dsc > > It's geared towards creating and maintaining chroots on LVM logical > volumes, creating snapshots as needed. It also takes care of > creating the initial chroots on LVs, it can automatically upgrade > them, etc. > > Plus they're better documented (IMHO) as schroot, for which I > couldn't find any useful docs. A complete copy of the docs is here: https://alioth.debian.org/docman/?group_id=30471 I agree they aren't the most user-friendly in the world; some additional explanatory material would help a great deal. I think schroot has a slightly different focus, which would account for the differences. schroot focuses on allowing user access to, and maintainence of chroots. It plays no part in the initial chroot creation, or performing stuff like keeping them up-to-date. It delegates this to other tools, like debootstrap and the sbuild chroot tools (in /usr/share/sbuild). lvmchroot, on the other hand, assists with initial chroot setup, and snapshot creation but doesn't handle the chroot(2) stuff to allow user access. As a result, I think the two tools could complement each other nicely. I would be very happy to add additional helper scripts to schroot, and merge missing features. One thing we don't currently do is allow the user to specify the LVM snapshot name; it gets a UUID. Having this as an option would be nice. Some of the sbuild scripts could also be merged with lvmchroot, such as buildd.chroot. > If the schroot maintainers agree we could try to merge my stuff into > schroot. That would be really cool. We are part of the buildd-tools project on Alioth: https://alioth.debian.org/projects/buildd-tools/ so subscribing to the list would be a good first step. The current SVN is at svn://svn.debian.org/svn/buildd-tools/trunk/schroot Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please sign and encrypt your mail. pgpvazcFrBsYK.pgp Description: PGP signature
Re: cdrtools
Norbert Preining <[EMAIL PROTECTED]> writes: > On Mon, 07 Aug 2006, Joerg Schilling wrote: >> Debian must either be able to clean itself from people who use Debian >> for such campaigns against OSS authors, or Debian needs to be called >> a higly suspect and non-free project. > > You troll around on debian-devel, you troll around on lkml, you seem to > be more intelligent, wise, knowledgable, fluent in licenses, all-mighty > than *ALL* *OTHER*: > - linux kernel developers (quite a lot) > - debian developers (quite a lot) > > Do you really believe this yourself?!?! If yes, go for a therapist, > please, I would even pay the first hour! Please keep non-constructive messages and flaming off debian-devel (and the same applies to you, Joerg Schilling). Take this off debian-devel to private mail or to a more appropriate list. Thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please sign and encrypt your mail. pgpz3KUkA410Q.pgp Description: PGP signature
Status of inetd for etch
This post is about some issues with the various inetd packages in etch (and unstable). This is a case where I think some coordination between all the packages or some inetd package policy would make them all generally more usable. The currently available inetd packages, and a summary of their state: +-+- Package | IPv6 support| Source quality / comments +-+- inetutils-inetd | tcp = tcp4 and tcp6 | OK, but upstream quiet | | micro-inetd | Partial | Not a proper inetd replacement | | netkit-inetd| No, and it will be | Terrible. It won't even build | difficult to add| from the .orig.tar.gz, and the | | tarball is a mess. IMO, should be | | removed from Debian. | | 102 outstanding bugs. | | openbsd-inetd | tcp=TCP4, tcp4, | OK. Bug in reload (#382404). | tcp6, tcp46 | Bug in restart (#376716). | | | | rlinetd | Yes | Not a drop-in replacement. | | superd | No | Unmaintained. Candidate for | | removal? | | xinetd | tcp4, tcp6 | Good, but not currently a drop-in | | inetd replacement (but could be | | configured to do so). +-+- Outstanding issues -- * There is no inetd virtual package, so multiple daemons may be installed, all using the same configuration file. Is this a use case we really want to support? Are there really setups running multiple inetds for a good reason? Having a virtual "internet-super-server" package or similar with appropriate dependencies would make them rather more interchangeable, as for e.g. mail-transport-agent. * There is no common init script name. Same problems as above. * netbase only depends on two inetd packages (openbsd-inetd and netkit-inetd; a virtual depends plus a default would be nicer. * netkit-inetd - No upstream. - Last maintainer upload was 22 months ago. The last three uploads were NMUs. - It doesn't build from the original source. - The original source is a horrible mess, with code duplication (the source tree has a duplicate copy embedded within itself), and i386 ELF object code and binaries code in the tree. - The C source itself is not very nice. - Is this really fit to keep in Debian? It might be better to remove it entirely given its terrible state. * openbsd-inetd is the only drop-in replacement at this time - The other packages have different init script names or need some work on the package dependencies (e.g. inetutils-inetd). xinetd is in the same situation, but also needs some work on update-inetd before it will be suitable as a replacement. * IPv6 transition - Should individual packages be made to listen on both tcp4 and tcp6 sockets, or should this be done by the inetd itself, or even update-inetd? - Some inetds automatically listen on v6, whereas others need it explicitly enabling. What should "tcp" vs "tcp4" vs "tcp6" (and the same for udp) imply? - Some general policy would be useful here to make the behaviour consistent and to make IPv6 support as painless as possible for users. * Upgrade from sarge and earlier The inetd daemon installed by default: etch: openbsd-inetd | netkit-inetd sarge: netkit-inetd woody: netkit-inetd (netkit-base, split from netbase) potato: (in netbase) slink: (in netbase) Users upgrading from woody or sarge to etch will not be switched to openbsd-inetd, whereas new installs will use it by default. Removing netkit-inetd from the netbase depends should permit this, but a complete removal would perhaps be the best option. While it's probably too late to fix up update-inetd and all the inetd integration issues for etch, fixing the netbase dependency and eliminating netkit-inetd is doable. Any thoughts or comments? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpz6IH7fTgCn.pgp Description: PGP signature
Re: Status of inetd for etch
[EMAIL PROTECTED] (Marco d'Itri) writes: > On Aug 10, Roger Leigh <[EMAIL PROTECTED]> wrote: > >> installed, all using the same configuration file. Is this a use >> case we really want to support? Are there really setups running >> multiple inetds for a good reason? Having a virtual > A good reason usually is using features not available in a single > package (especially inetd vs. inetd). > It's not hard to manage anyway, my scheme allowed this. We don't allow multiple mail-transport-agents, even though they have different features. Do we have a real, demonstrable, use-case for permitting multiple inetds? To me, it seems rather more manageable to have just one, particularly because they all generally use the same configuration file. If this is something only one or two people with specialised needs do, they can surely sort it out by themselves, as they would if they had a specialised mail setup. >> * netkit-inetd > I agree that it should be removed from the distribution, or at least > replaced by openbsd-inetd as the default inetd. In that case, would it be possible for a netbase upload changing Depends: openbsd-inetd | netkit-inetd to Depends: openbsd-inetd or even Depends: internet-super-server | openbsd-inetd to allow for a future virtual package? openbsd-inetd could implement the virtual package right now, and the other inetds can fix up their dependencies after. >> - The other packages have different init script names or need some >> work on the package dependencies (e.g. inetutils-inetd). xinetd >> is in the same situation, but also needs some work on update-inetd >> before it will be suitable as a replacement. > ITYM "lots of work". Perhaps it simply needs approaching in a different way. Rather than a hugely complex update-inetd, why not have each inetd provide one which works for them (with a common implementation for the traditional format)? On removal, they can (if using a file other than /etc/inetd.conf) dump their configuration there to allow migration between inetd packages and do the opposite on install. >> * IPv6 transition >> - Should individual packages be made to listen on both tcp4 and tcp6 >> sockets, or should this be done by the inetd itself, or even >> update-inetd? > Only individual packages know if they support IPv6. So what are you proposing as the solution here? Should each package call update-inetd twice, for both v4 and v6? (Assuming they support both.) >> - Some inetds automatically listen on v6, whereas others need it > I call them "broken". I believe that administrators do not expect that > services are exposed to IPv6 connections unless they are configured this > way in inetd.conf. Why? All the other major daemons listen on both by default, and I do expect inetd services to do the same where possible. Most of the services are already protected by TCP wrappers, so you would need to explicitly add [::] to /etc/hosts.allow to get an IPv6 connection. >> Users upgrading from woody or sarge to etch will not be switched to >> openbsd-inetd, whereas new installs will use it by default. > Did you actually test this? I checked that new etch installs install openbsd-inetd. Upgrades won't be switched because the netbase dependency is already satisfied by netkit-inetd. In consequence, I think that netkit-inetd needs to be removed from the netbase depends. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpNtO2ZtFtHF.pgp Description: PGP signature
Re: Status of inetd for etch
[EMAIL PROTECTED] (Marco d'Itri) writes: >> It would be good to get rid of inetd from the basic install at all. Those > No, it would not. UNIX systems are supposed to have an inetd installed. I see no reason why *Debian* systems should have an inetd installed unless there is another package installed requiring its services. This can be handled through package dependencies. If the admin wants to add their own services (i.e. not installed by a dependency), they can just install it by hand. If there is nothing using inetd, it's just bloat in the base install. While it's probably best to leave it installed by default for etch, I think fixing up all inetd-using packages to have proper dependencies, and then removing the dependency from netbase would be a worthy goal for etch+1. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpihiMtpAfU3.pgp Description: PGP signature
Re: Status of inetd for etch
Roger Leigh <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Marco d'Itri) writes: > >>> It would be good to get rid of inetd from the basic install at all. Those >> No, it would not. UNIX systems are supposed to have an inetd installed. > > I see no reason why *Debian* systems should have an inetd installed > unless there is another package installed requiring its services. > This can be handled through package dependencies. If the admin wants > to add their own services (i.e. not installed by a dependency), they > can just install it by hand. > > If there is nothing using inetd, it's just bloat in the base install. > > While it's probably best to leave it installed by default for etch, I > think fixing up all inetd-using packages to have proper dependencies, > and then removing the dependency from netbase would be a worthy goal > for etch+1. Just for the record, this is the list of affected packages: afbackup amanda-client amanda-server apt-proxy asp atftpd bidentd biff binkd bitlbee bootp bozohttpd cfingerd csync2 cupsys-bsd cvs cyrus-imapd cyrus-pop3d dbskkd-cdb dhcp efingerd exim fakepop fam ffingerd fingerd firebird2-classic-server fspd ftpd ftpd-ssl gidentd gnats gtalk gwhois heimdal-kdc heimdal-servers heimdal-servers-x hotway ident2 ifcico ipopd isdnvboxserver kerberos4kth-servers kerberos4kth-servers-x kftgtd krb5-ftpd krb5-kdc krb5-rsh-server krb5-telnetd ktalkd leafnode lukemftpd mailutils-comsatd mailutils-imap4d mailutils-pop3d masqmail midentd mooix ndtpd netkit-inetd nntp node noffle nsca nullidentd oftpd oidentd openbsd-inetd p10cfgd pawserv pidentd popa3d poppassd postfix proftpd proftpd-common pure-ftpd-common qpopper qpopper-drac remctl-server remstats-servers rlinetd rsh-redone-server rsh-server rstatd rusersd rwalld samba sendfile sendmail-base sidentd skksearch slidentd smail smtpd sn solid-pop3d sslwrap statd swat talkd teapop teapop-ldap teapop-mysql teapop-pgsql telnetd telnetd-ssl tftpd tftpd-hpa uucp uw-imapd vsftpd wipl-client-inetd wu-ftpd xfingerd xtel xtell zmailer -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpGWc6RE2f1M.pgp Description: PGP signature
Update: status of inetd
Hi folks, Following the last thread on the subject, several things have happened: 1) All packages depending on netkit-inetd have had their dependencies replaced with a netkit dependency. 2) netkit now only depends upon openbsd-inetd, so netkit-inetd is now no longer used by either new installs or upgrades from sarge. 3) netkit-inetd (netkit-base) is now ready for removal from unstable (see #383960). I'd like to propose the following as the next step. I was going to leave this until after etch, but further consideration made me realise it needs doing before, otherwise etch->etch+1 upgrades will break (or it will have to wait until etch+2, and that's too long). What I'd like to propose is this: 1) Split out update-inetd from netbase into a new "inetd" package. See http://people.debian.org/~rleigh/inetd_1.tar.gz http://people.debian.org/~rleigh/inetd_1.dsc as an example of what I'd like to do (Md should probably be the maintainer here, since it is derived from netbase). This - provides a single package for all update-inetd-using packages to depend upon - provides a default inetd dependency, so all packages wanting an inetd just need to depend on it, rather than hardcoding the default inetd in every package. - inetd-providing packages need to Provide internet-super-server - it doesn't depend on netbase, to prevent a circular dependency, but will post-etch. 2) netkit needs to drop the files moved into the inetd package above, and Depend on inetd. This will - ensure update-inetd is present by default so sarge->etch upgrades will work. - can be dropped post-etch. 3) All update-inetd users need to depend on inetd instead of/in addition to netbase. The complete list is: afbackup amanda-client amanda-server apt-proxy asp atftpd bidentd biff binkd bitlbee bootp bozohttpd cfingerd csync2 cupsys-bsd cvs cyrus-imapd cyrus-pop3d dbskkd-cdb dhcp efingerd exim fakepop fam ffingerd fingerd firebird2-classic-server fspd ftpd ftpd-ssl gidentd gnats gtalk gwhois heimdal-kdc heimdal-servers heimdal-servers-x hotway ident2 ifcico ipopd isdnvboxserver kerberos4kth-servers kerberos4kth-servers-x kftgtd krb5-ftpd krb5-kdc krb5-rsh-server krb5-telnetd ktalkd leafnode ltsp-server lukemftpd mailutils-comsatd mailutils-imap4d mailutils-pop3d masqmail micro-httpd midentd mooix ndtpd netkit-inetd nntp node noffle nsca nullidentd oftpd oidentd openbsd-inetd p10cfgd pawserv pidentd popa3d poppassd postfix proftpd proftpd-common pure-ftpd-common qpopper qpopper-drac remctl-server remstats-servers rlinetd rsh-redone-server rsh-server rstatd rusersd rwalld samba sendfile sendmail-base sidentd skksearch slidentd smail smtpd sn solid-pop3d sslwrap statd swat talkd teapop teapop-ldap teapop-mysql teapop-pgsql telnetd telnetd-ssl tftpd tftpd-hpa uucp uw-imapd vsftpd wipl-client-inetd wu-ftpd xfingerd xtel xtell zmailer Once steps 1 and 2 above are compete, I'd like to mass-file bugs against all these packages, and then if neccessary NMU the dependency change a few weeks later, so we can ensure everything is fixed before etch is released. Any comments? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpPcgd8qHBvh.pgp Description: PGP signature
Policy regarding virtual packages
Hi folks, Following some discussion with Marco d'Itri about inetd, I'd like to put forward some more general thoughts on virtual package handling for some comments. Currently, virtual packages (such as mail-transport-agent) cannot be specified by themselves. They can only be used in combination with a non-virtual package which provides the default implementation. For example: Depends: exim4 | postfix | mail-transport-agent or Depends: exim4 | mail-transport-agent This means that 1) Each package depending on a virtual package must specify a real package 2) There is no central policy defining which package is the default implmentation--each package could specify a different default 3) Changing the default is a lot of work--every reverse dependency must be updated. For the case of mail-transport-agent, this could be simply solved by the creation of a mail-transport-agent-default package. This would be an empty package, doing nothing but providing this dependency: Depends: exim4 | mail-transport-agent All packages wanting to depend on mail-transport-agent need only have Depends: mail-transport-agent-default When exim4 becomes exim5, or some other MTA, only the mail-transport-agent-default package would need updating. For the new inet-superserver virtual package, there are potentially over 120 packages which would need to add Depends: openbsd-inetd | inet-superserver However, I feel that this is too many places to hardcode the openbsd-inetd default (Marco d'Itri does not believe this is worth the effort, but I personally think that it will potentially prevent a lot of future effort). Here, I think a means of specifying a distribution-wide default is much better than requiring each package to separately specify it. For this case, I would like to create an inetd-default (or inet-superserver-default) package, which would simply be Depends: openbsd-inetd | inet-superserver and all inetd-requiring packages would just use Depends: inetd-default See http://people.debian.org/~rleigh/inetd-default_1.tar.gz and http://people.debian.org/~rleigh/inetd-default_1.dsc There are some other useful side-effects: Custom Debian Distributions can easily change the -default package to customise the distribution defaults. Example: Scott Remnant recently blogged on -planet about the "upstart" init/cron/inetd replacement being developed in Ubuntu. This would replace openbsd-inetd, and with this scheme would require a one-line change to a single package. Other CDDs might want to use other inetds, e.g. xinetd, or a "null" inetd which does nothing. For MTAs, other distributions might want to switch from exim4 to a more lightweight MTA (or even a "null" MTA for minimal systems). This system would allow that to be simply and easily configured. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpBR1bpc8cZY.pgp Description: PGP signature
Re: Buildd maintenance for dummies
Luk Claes <[EMAIL PROTECTED]> writes: Hi Luk, > I recently took over the buildd maintenance of signy.farm.ftbfs.de, a mips > buildd for experimental, sarge-backports, sarge-volatile and non-free > (whitlisted packages). I actually started in helping with the buildd > maintenance of odin.farm.ftbfs.de which is a similar buildd for sparc. > > As newbie I made some stupid mistakes... I hereby want to announce a > wiki page to make sure newbies in buildd maintenance don't make this > mistakes again :-) It sounds like a great idea. Also, feel free to note them down in a new README under svn+ssh://svn.debian.org/svn/buildd-tools/trunk/buildd and I'll turn them into a nice manpage at some point. I'm about halfway through packaging it, though I'm bogged down with other commitments right at the present. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpNET28lyNIB.pgp Description: PGP signature
Re: stale lock files
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Write the pid and host to the lock file. When you detect a lock and > the lock is on the local host then check the pid is still valid. If > not the lock is stale. If the lock is from a remote host there is > little you can do but ask. Why not use fcntl/lockf byte region locking on the entire file? It gets released as soon as the process terminates, so there are no issues with stale locks, and it works over NFS. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpQtKy2HntyJ.pgp Description: PGP signature
Re: stale lock files
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > Roger Leigh <[EMAIL PROTECTED]> writes: > >> Goswin von Brederlow <[EMAIL PROTECTED]> writes: >> >>> Write the pid and host to the lock file. When you detect a lock and >>> the lock is on the local host then check the pid is still valid. If >>> not the lock is stale. If the lock is from a remote host there is >>> little you can do but ask. >> >> Why not use fcntl/lockf byte region locking on the entire file? It >> gets released as soon as the process terminates, so there are no >> issues with stale locks, and it works over NFS. > NFS isn't everything. Of course, but you get that extra feature "for free". Why would that be a be something to avoid? Proper advisory file locking, as opposed to opening and writing out pidfiles, is more reliable for both local and distributed locking, avoiding all the issues with stale lock release (there are none--it's entirely automatic on fd close or process exit) and PIDs being reused on the local system and/or duplicated on a distributed system (there's no PID to care about, since the fcntl lock F_WRLCK is simply associated with an open file descriptor, and the kernel handles everything, including deadlocks). -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpkqXZQI6Oie.pgp Description: PGP signature
