New author/maintainer for pinfo needed
Hi, I've so far maintained the package pinfo, an alternative info-file viewer. The last release has been some time ago and there are also some open bug reports. I've talked with the author about the package and he decided that he has no longer time to work on this package. Therefor the program needs a new author to be viable in the future. Ideally the new author is also a debian developer or in the new maintainer queue and would take the package over. If nobody is interested in becoming the author of pinfo, I'm going to orphan the package in a week. Christian -- Debian Developer (http://www.debian.org) 1024D/B7CEC7E8 44BD 1F9E A997 3BE2 A44F 96A4 1C98 EEF3 B7CE C7E8 pgphZQOcX31R1.pgp Description: PGP signature
Re: recovery status update
Hi James, first let me thank you for your good work so far on the recovery of the debian machines. I just wanted to add one note: On [05/12/03 1:51], James Troup wrote: > Use the anonymous upload queue on ftp-master. I believe you want to > use something like "dupload --to anonymous-ftp-master foo.changes" for > dupload and "dput ftp-master foo.changes" for, err, dput. But I don't > use either of these programs and haven't tested that. The default configuration of dput was changed in the past to use the anonymous upload-queues. Only if people really want to use scp/rsync (like I do when testing new releases), it's necessary to specify the host. Otherwise it's enough if people use "dput foo.changes", if they haven't modified the default configuration (except for username. ;-) Christian -- Debian Developer (http://www.debian.org) 1024D/B7CEC7E8 44BD 1F9E A997 3BE2 A44F 96A4 1C98 EEF3 B7CE C7E8 pgpU4h5ObJ9DG.pgp Description: PGP signature
Bug#171237: ITP: tinycdb -- a package for creating and reading constant databases
Package: wnpp Version: unavailable; reported 2002-11-30 Severity: wishlist * Package name: tinycdb Version : 0.73 Upstream Author : Michael J. Tokarev <[EMAIL PROTECTED]> * URL : ftp://ftp.corpit.ru/pub/tinycdb * License : Public Domain [1] Description : a package for creating and reading constant databases tinycdb is a small, fast and reliable utility set and subroutine library for creating and reading constant databases. The database structure is tuned for fast reading: . - Successful lookups take normally just two disk accesses. - Unsuccessful lookups take only one disk access. - Small disk space and memory size requirements; a database uses 2048 bytes for the header and 24 bytes per record, plus the space for keys and data. - Maximum database size is 4GB; individual record size is not otherwise limited. - Portable file format. - Fast creation of new databases. - No locking, updates are atomical. . tinycdb implements almost all API as found in cdb-0.75 written by D.J. Bernstein, so it should be source-compatible. It also implements the query interface as found in earlier versions of cdb (0.6x) and freecdb. It also contains some enhancements, like allowing to check existance of a record in a yet-to-be-created cdb database file. . This package contains both the utility to manipulate constant databases and the development files. [1] This is the complete license text for it: |You can do whatever you like with this package. The code is placed |at the public domain. | |This package is distributed in a hope it will be useful, but |WITHOUT ANY WARRANTY; without even the implied warranty of |MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Both, the upstream author and I believe that this contains no legal problem and is acceptable as DSFG-free license. If there's any problem with the license, please inform me about the problem and a suggested change. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux salem 2.4.20-rc2 #1 Sun Nov 17 10:28:49 CET 2002 i586 Locale: LANG=POSIX, [EMAIL PROTECTED] -- Free yourself from negative influence. Negative thoughts are the old habits that gnaw at the roots of the soul. Moses Shongo, (Seneca)
Bug#129025: general: exim crash with sig11 while getservbyname
reassign 129025 exim thanks On 13/01/02, [EMAIL PROTECTED] wrote: > Package: general > Version: 20020113 > Severity: important You are reporting a problem with the mail server software exim and so this bug should reported against the package exim and not general. > in exim-3.33/src/transports/smtp.c, line 1889: > > struct servent *smtp_service = getservbyname(ob->service, "tcp"); > > does a crash with signal 11 on my installation, i dunno but /etc/services > seems correct and if i use the following, it works: Seems? Do you have such an entry in /etc/services? |smtp25/tcp mail Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgppZrCNZYONP.pgp Description: PGP signature
Re: An alarming trend (no it's not flaimbait.)
So, that's hopefully my last post for quite a long time. On 26/12/01, David D. W. Downey wrote: > * Pierfrancesco Caci ([EMAIL PROTECTED]) wrote: > > 1) learn how to properly format a mail message (i.e. fold at 75th > >column) > Quit pickin at the measly stuff and pay attention to the content of > his words. Laying the bear trap here only gets you laughs from the > other hunters. Wrong. If you want people to read a mail and follow the content, then you have to proper format it, so that's it's easy to read it. Did you ever read some books or newspapers and noticed the format that they are using? With your argumentation we can remove all those formatting and prints books and newspapers on a large paper roll and read it. > > 2) learn how to package a deb and adopt whichever package you think > >you're better at maintaining than the original maintainer > Pointing out a failure in a system doesn't mean one has the ability > to do what you are asking. It simply means he found a failure. In Not directly. He found a situation that he think it's flawed and which needs to be changed. But without either having enough people interested to take care of it, it won't change until he steps forward and starts working on changing it. > this instance, his becoming a maintainer does nothing to solve the > problem he's point at other than for that single package. Pushing Wrong, he can then help with other packages, make NMU's if the maintainer gave him permission or track MIA developers done and then orphan their package and let Debian QA take care of them. > someone off into this section only further proves the point that > debian's starting to potentially fall apart since you completely > prove that you either failed to hear or desired not to hear what > his content. And you seem to ignore that this is _volunteer_ _based_. Debian Developers will work on those issues that they are interested in and not the things you want to see them working on. If you want to see Developers working on some issue, either start paying them for doing the work, convince enough to work on the issue or start the work on your own. The BTS will happily accept your mails and debian-qa will be interested to hear about MIA developers which you tracked down and which agree to orphan their packages or aren't reachable in any way. > "Why are you listing all that crap bub?" Probably what a few of you > are asking. Only to show my experience with different distros, > linux, and where I feel I gain my credence for my vote for Brian's > comments. And then you are not able to use your experience to create solutions to help debian but to also start lenghty discussions here? Thanks for showing me that at least a part of our user base seems to have changed and see Debian as company which they pay for and which they can force into working on certain issues. > Debian is a solid distro to me. It's got heart, strength of > charactor both in it's member software, and it's member users and > developers. It's withstood 99% of the "Let's add every feature we > can lay our hands on cause that'll show we know what we're doing!" > crowd. It's solidly built, loved, and protected over by a loyal > group of users. This is more than I can say for the majority of the > distributions out there. So why are you then not contributing something back to the Debian project if you quite like it that much? > Folks, our user base (non official developers and general users > alike) deserve to be listened to when they say something. Listening is one thing, but doing something is much better and at least people like you who according to their own description have enough experience and knowledge, should think about spending some time on helping and improving debian by working on it instead of starting lenghty discussions and complaining loud. > Why? Simply because of issues with Debian, be it the installer of > old, the lack of certain support, all different reasons. But one And you aren't able to work on the installer or even just clearly describe the people working on it which parts need to be improved in your opinion and why? Lack of certain support? Try to write exact descriptions what kind of support you are lacking and then talk with the maintainers who are responsible for it about adding it or helping them add it. > *doesn't* happen to debian. If each maintainer is watching his or > her upstream, updates with their source when it's released, and if > the upstream is *not* providing the updates like they should, either Pardon? You want to give us a exact defintion for "updates like they should"? There's no way to define that and sometimes upstream authors also disappear simply because they have a lack of time. > announce to the BTS that the source is cold, or attempt to Why should one do that? If the package is still working fine and contained no bugs, there's in my opinion no need to do this. And if the package is too buggy, it's easier to contact the
Re: An alarming trend (no it's not flaimbait.) (fwd)
Damn, I didn't want to post here anymore, but looks like I need to add some points. :-( On 26/12/01, Brian Wolfe wrote: > Heh, I was not aware that a non-developer could subscribe to d-d. Looking at http://lists.debian.org and reading the list description would have told you that before. > On Wed, Dec 26, 2001 at 08:41:54AM +, David Graham wrote: > > > Nice bait I'll bite, but if you want to read it you'll have to > > subscribe... It's not fair to throw the rock and hide the hand > > 1) learn how to properly format a mail message (i.e. fold at 75th > >column) > Oops. Darnit, how to do this automaticly with vi? By reading the documentation or hasn't vi some documentation? Look around for textwidth and wrapmargin. > > 2) learn how to package a deb and adopt whichever package you think > >you're better at maintaining than the original maintainer > Read up on packaging, attempted applying diffs from debian , > sucessfully I might add. But as for creating new packages... I haven't had a > lot of time to try it. ;-P Mind you this has been in the last 2 years... Aehm, if you already successfully applied the diffs to a source package, then it's not difficult to build a new debian package from that source. And it's enough if new developers start by taking over old packages that they daily use and which have been orphaned. > > 3) if the package is dead upstream, fork it and maintain it > >yourself. Most free software licences allow it. > Anyone care to donate a time machine to me? I know this sounds routine > and a lot like an escapeism but. I honestly do not have to time to > maintain > my own GPLd software, run a company, advocate Linux smartly, make nice with > the family, maintain a 5,000 sq ft warehouse, maintain my sanity, and have > a life. Adding package maintenance would be just a little more, but i'd like > to regain at least ONE of the seven days of the week for myself before delving > into somethign as complex as properly packaging a program for debian. Well, taking over the upstream for a software is quite difficult since you need to know the source well and be a good programmer. But maintaining a debian package doesn't require that much time and knowledge. So if you find enough time to send loud complaintments to this list and then discuss them, it would be better to stop sending those complaints but instead spend the time by sending in an ITA or ITO for some debian package and help improving debian. > I can say this though, if Debian were to address the issues I have > brought up in a realistic manner, I would be willing to toss my personal time > into the project once I have some available, as well as possibly some idle > company employee time once I can afford it. Who is Debian? This is a _volunteer_ _based_ _organization_ so everyone is spending the time on the tasks he's interested it. And even you won't be able to force anyone to address the issues who posted, until either he has enough interested and time to take care of some or you pay some of our developers to take care of this issues. Or maybe you even find it enough time to take care of them yourself and contribute that way to Debian. Christian P.S.: I'm aware that some parts of this mail maybe seen as a bait for flames, but that's not the intention. I'm just writing my own opinion and statements about this and will now switch back to silence and disappear in an unseens shadow. :-( -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp8mdY3hNyKU.pgp Description: PGP signature
Re: Bug#125904: ITP: fungetty, a fun new getty for Linux framebuffers
On 25/12/01, Ben Pfaff wrote: > Ben Armstrong <[EMAIL PROTECTED]> writes: > > On Thu, Dec 20, 2001 at 02:36:52AM -0800, Ben Pfaff wrote: > > > If so, then maybe you should have a look at fungetty, a > > > replacement for the standard Linux getty that can display > > > full-color graphics above the login prompt. I hacked this up > > > over the last week or so, and it seems to work pretty well. It > > > can display many kinds of PNG files above the login prompt. > > > There are some bugs and limitations, but nothing unreasonable. > > How does this differ from fbgetty? > fbgetty doesn't actually implement its `image' command for the > issue file. At least, AFAICT. And why then don't you hack on fbgetty and add the necessary code? You could then send me a patch which I forward to the upstream author. So far he hasn't been biting me and I think he would at least take a close look at your patch and maybe completely or partial incorporate it. Upstream had to first fix some terminal issues which showed up and the broken secure exec functionality to get fbgetty working fine again. The next release after the current one, which I'm testing right now, will be 0.2.x and the new feature of actually implementing the image command would be at least in my opinion a nice feature. So Ben, if you are interested to hack on fbgetty to get the image functionality implemented for the next release, just mail me privately. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpQPvnZw6DlB.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-26 Roberto Suarez Soto wrote: > On Sep/26/2001, Christian Kurz wrote: > > > I think that maybe he refers to the fact that, for example, you may > > > have formatted your ext2 partitions so they are incompatible with 2.0.x > > Well, I once heared about this, but never read an explanation what > > exactly causes the differences in the ext2 partitions created while > > running a 2.0.x kernel and why they have been introduced. > The features are documented in mke2fs(8), under "-O" (or it seems, for > what I've seen). They don't seem to be too useful (unless I'm missing > something), but anyway they are there. Thanks for the pointer, which explains the features and partly reasons for them. If someone has a pointer to an even more detailed or longer explanation, please mail me. > > Well, iptables is only available for kernel 2.4.x, but with kernel 2.2.x > > you can still build a firewall with ipchains or ipfwadm if you still use > Yes, but it's not the same building a firewall with 2.4.x and building > a firewall with 2.2.x or 2.0.x. There are a few things that you can do only > with 2.4, not with lower versions. Stateful firewalling, for example. Well, you may have not the full features available but you can build with all version a firewall and have at least filtering per ip or port available. So compared to the situation with bind, by using cp,rsync or some other tool for keeping the config files in sync, this would still be possible. If mount -bind is used for creating the chroot this would not be possible and it would be like needing kernel 2.4.x for building a firewall. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpf6TNPq43Ox.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-26 Riku Voipio wrote: > On Tue, Sep 25, 2001 at 04:34:31PM +0200, Christian Kurz wrote: > > On 01-09-25 Steve Greenland wrote: > > > I am so tired of hearing things like this. Nobody is forcing anyone to > > > do anything. We already "force" them to use 2.2 instead of still using > > > 2.0. You want the functionality, you use the right tools. You want to > > Were exactly do we force them? Which debian packages do not work well > > with a 2.0.x kernel? > apt-cache search usb > for example. Which package exactly do you mean? I don't see any package in that list which would force you to use a kernel 2.4.x. Also do you really want to compare hardware for the usb port with a daemon that you run on a server? > > > stick with 2.2, then *you* deal with the issues. The maintainers have > > That's a nice attitude, which will lead to the situation that > > people, especially administrators, will move away from debian to either > > other distributions, a bsd flavour or other free operating systems. > Forcing new users to deal with historic burden is not an answer. Pardon? New users are absolutely not forced to deal with historic burden. I'm just proposing that any script or debian package which offers to create a bind chroot should not depend on new kernel specific stuff like mount -bind. > I really can't understand your problem with limiting chroot bind9 > feature to kernels with --bind mounts support. They still can run bind9 > perfectly, although less securely. So, you want to either force every admin running bind9 to either upgrade to kernel 2.4.x or have a less secure system? That's like I stated before a good approach if you want to have people move to some other distribution or free operating system, but not to have people use debian anymore. > If 2.2 kernel users want chrooted bind, they > a) have already done it - no extra work So let's forget those users and ignore that they maybe also happy about having a debian package set up a chroot for them? > b) upgrade to 2.4 - sheez, that was hard... Which is not always an option. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpRrzThslsXy.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-25 Henrique de Moraes Holschuh wrote: > On Tue, 25 Sep 2001, Christian Kurz wrote: > > On 01-09-24 Henrique de Moraes Holschuh wrote: > > > On Mon, 24 Sep 2001, Christian Kurz wrote: > > > > Hm, that doesn't make much sense too me. I think the best thing would be > > > > to have /etc/bind inside $CHROOT and having no symlink. > > > And scratch the second-most important feature of Debian (the first one > > > being > > > the DFSG)? Do Not Move Config Files Out Of /etc. Ever. If you need it > > > elsewhere, at least leave a symbolic link in place. > > But having a link from either the config-files in /etc/bind to $CHROOT > > or in the other direction, could be in my opinion a security risk. In my > Oh, how so? I think you know how the method of how to break out of a chroot. Having some symlink inside the chroot would in my opinion make this task easier then it normally is. But feel free to prove me wrong. > > and would instead suggestion to modify the documents stating that all > > config files should be in /etc to make a exception for $CHROOT. > > NEVER. This is not some low-grade distribution where you can go around > scattering configuration files all over the filesystem. I will fight tooth > and nail against such an atrocity. > Well, then we have to find some other way like cp, rsync, or something else to keep one copy of the files in /etc and one in $CHROOT/etc. Using mount --bind is like I stated before, no option. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp65GidExMe7.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-25 Roberto Suarez Soto wrote: > On Sep/25/2001, Christian Kurz wrote: > > Were exactly do we force them? Which debian packages do not work well > > with a 2.0.x kernel? > I think that maybe he refers to the fact that, for example, you may > have formatted your ext2 partitions so they are incompatible with 2.0.x Well, I once heared about this, but never read an explanation what exactly causes the differences in the ext2 partitions created while running a 2.0.x kernel and why they have been introduced. > kernels. Or to the lot of programs (iptables and related, for example) that > only work with 2.4.x. Well, iptables is only available for kernel 2.4.x, but with kernel 2.2.x you can still build a firewall with ipchains or ipfwadm if you still use a 2.0.x kernel. So if you want to build a firewall you are not forced to kernel 2.4.x. The decision which kernel and software to use is still left to the administrator. > > That's a nice attitude, which will lead to the situation that > > people, especially administrators, will move away from debian to either > > other distributions, a bsd flavour or other free operating systems. > Have you tried any *BSD? I would prefer any Debian to them if I had to Yes, I worked quite some time with FreeBSD and also took a short look at NetBSD. (I hadn't time to install OpenBSD for testing purposes.) > seriously take charge of one :-) (but again, that's only my opinion; and I'm Well, I wouldn't agree with you, but that's an other discussion which doesn't belong on this list. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpBfNW5Anj13.pgp Description: PGP signature
Re: what happened to the dput package?
On 01-09-25 Sean 'Shaleh' Perry wrote: > > No, dput doesn't depend on ssh, it only suggest it like rsync. But it > > depends on GnuPG now, therefor the change. > why the depends on gpg? Because the default behaviour of dput is to check the signatures on the .dsc and the .changes file. So it won't be useful without GnuPG in the default behaviour except you select to ignore the signature check. Christian -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Ben Franklin
Re: what happened to the dput package?
On 01-09-25 Sean 'Shaleh' Perry wrote: > On 25-Sep-2001 Steve M. Robbins wrote: > > On Tue, Sep 25, 2001 at 02:10:22PM +0100, Andrew Suffield wrote: > >> On Tue, Sep 25, 2001 at 02:07:36PM +0200, Jochen Voss wrote: > >> > there used to be a package called "dput", > >> > but now I cannot find it anymore. For example > >> > visiting > >> > > >> > http://packages.debian.org/dput > >> > > >> > shows the message "No responses to your query" > >> > and aptitude lists it as an obsolete package. > >> > What happened to this package? Was it renamed? > >> > Or did a do something wrong? > >> > >> It's moving to non-us, but is (was?) NEW, pending an overrides update. > > > > Really? Why? > > it likely wants to depend on ssh. No, dput doesn't depend on ssh, it only suggest it like rsync. But it depends on GnuPG now, therefor the change. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpTwlDB8c7eP.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-25 Martin F Krafft wrote: > also sprach Christian Kurz (on Mon, 24 Sep 2001 10:59:13PM +0200): > > Hm, that doesn't make much sense too me. I think the best thing would be > > to have /etc/bind inside $CHROOT and having no symlink. > except if you want to enable the usual /etc/bind/ editing of > conf-files, which would make administering the chroot no different > than administering the non-chrooted bind. Wouldn't that also be possible by using cp -axp to sync the two copies of the config files? Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpZWdtildXMW.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-25 Steve Greenland wrote: > On 25-Sep-01, 03:12 (CDT), Christian Kurz <[EMAIL PROTECTED]> wrote: > > > > As I wrote in two emails before, this isn't a solution, since this > > forces an administrator to use kernel 2.4.x instead of maybe still using > > 2.2.x. > > I am so tired of hearing things like this. Nobody is forcing anyone to > do anything. We already "force" them to use 2.2 instead of still using > 2.0. You want the functionality, you use the right tools. You want to Were exactly do we force them? Which debian packages do not work well with a 2.0.x kernel? > stick with 2.2, then *you* deal with the issues. The maintainers have That's a nice attitude, which will lead to the situation that people, especially administrators, will move away from debian to either other distributions, a bsd flavour or other free operating systems. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpAWaw71repF.pgp Description: PGP signature
Re: what happened to the dput package?
On 01-09-25 Jochen Voss wrote: > there used to be a package called "dput", > but now I cannot find it anymore. For example > visiting > > http://packages.debian.org/dput > > shows the message "No responses to your query" > and aptitude lists it as an obsolete package. > What happened to this package? Was it renamed? > Or did a do something wrong? No, you did absolutely nothing wrong. Due to the new dependency on GnuPG of dput, it had to be removed from ftp.debian.org and reuploaded to non-us.debian.org. But after uploading it to non-us.debian.org there's still some action from the ftp masters needed to make it available again. This hasn't happened so far. I can make a temporary second upload of the current package version to people.debian.org. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpWBIeg4rDmI.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-25 Wichert Akkerman wrote: > Previously Henrique de Moraes Holschuh wrote: > > And scratch the second-most important feature of Debian (the first one being > > the DFSG)? Do Not Move Config Files Out Of /etc. Ever. If you need it > > elsewhere, at least leave a symbolic link in place. > bind mounts. As I wrote in two emails before, this isn't a solution, since this forces an administrator to use kernel 2.4.x instead of maybe still using 2.2.x. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpjbyKDuFjJj.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-24 Henrique de Moraes Holschuh wrote: > On Mon, 24 Sep 2001, Christian Kurz wrote: > > Hm, that doesn't make much sense too me. I think the best thing would be > > to have /etc/bind inside $CHROOT and having no symlink. > And scratch the second-most important feature of Debian (the first one being > the DFSG)? Do Not Move Config Files Out Of /etc. Ever. If you need it > elsewhere, at least leave a symbolic link in place. But having a link from either the config-files in /etc/bind to $CHROOT or in the other direction, could be in my opinion a security risk. In my opinion there should be absolutely no link from $CHROOT to any file outside the chroot. So instead of creating a $CHROOT that contains everything without any link to the outside you want to decrease the security by having links from outside to inside? I don't agree with that and would instead suggestion to modify the documents stating that all config files should be in /etc to make a exception for $CHROOT. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgphj8SPASqTg.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-24 Martin F Krafft wrote: > also sprach Christian Kurz (on Mon, 24 Sep 2001 10:31:54AM +0200): > > So you want to force everyone who is interested in running this chroot > > to use a kernel 2.4.x at least? That's in my opinion a not acceptable > > solution, since the decision which kernel is used, should never be > > depending on a chroot-setup, but on the decision of the system > > administrator. So this script should work with kernel 2.2.x and 2.4.x so > > that everyone can use it with the kernel version he likes to use. > > okay, you do have a point. it's not too difficult to make bind > chrooted without remounting /etc/bind - one way would be to store Thanks, that would be in my opinion the best option, since that way every administrator can use the kernel version he wants. > $CHROOT/etc/bind in the chroot, and then have a symlink from the real > /etc/bind to the chroot one. Hm, that doesn't make much sense too me. I think the best thing would be to have /etc/bind inside $CHROOT and having no symlink. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgprw63g9mhDj.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-24 Marco d'Itri wrote: > On Sep 24, Christian Kurz <[EMAIL PROTECTED]> wrote: > > >So you want to force everyone who is interested in running this chroot > >to use a kernel 2.4.x at least? That's in my opinion a not acceptable > Yes, since managing a chroot environment without bind mounts is way It maybe harder, but that's not a good reason to force system administrator to run a kernel 2.4.x for having the bind debian package chrooted. The reason which kernel version is used on a server should always belong to the admin and should never be imposed by some software. > harder and IMO cannot easily/correctly be done by a package. Why not? What do you think makes that part so difficult? Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpMGY9yuKZcn.pgp Description: PGP signature
Re: bind9-chroot (was: questions on ITP)
On 01-09-23 Martin F Krafft wrote: > complicated for i did not know about the mount --bind option. sure, > this only works with 2.4.x, but if any chroot changes to bind9 are > going public, then this will be bundled with a 2.4.x kernel-image, > right? will testing be 2.4.x? So you want to force everyone who is interested in running this chroot to use a kernel 2.4.x at least? That's in my opinion a not acceptable solution, since the decision which kernel is used, should never be depending on a chroot-setup, but on the decision of the system administrator. So this script should work with kernel 2.2.x and 2.4.x so that everyone can use it with the kernel version he likes to use. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp1wgch2tmtZ.pgp Description: PGP signature
Re: gpg and trustdb very slow
On 01-09-18 Joey Hess wrote: > It'd be nice if someone would look at optimizing it sometime; the > behavior I see with strace is absurd, and could easily be done with no > syscalls, at least, by just reading the whole trustdb into memory. I know that the Werner revamped the whole keyring code about 1 or two weeks ago. I just tried the --list-keys with my private and the debian keyring specified in the options file and I didn't took more then 5 minutes for me. (AMD K6-200). So I don't think if anyone would really want to optimize the code more, he should look at the current cvs code. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpKkCna6h751.pgp Description: PGP signature
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On 01-09-06 Nick Phillips wrote: > On Thu, Sep 06, 2001 at 07:47:26PM +0200, Christian Kurz wrote: > > > > upstream packages because they are not part of a package? The > > > > translation of the error messages and other messages of a program belong > > > > to the package of it. > > > That depends on whether you're distributing one package or thousands. > > Why do make this dependant on the number of packages? I think that using > > some count like you do, is a bad thing. > Because if you're only distributing one package or small group of packages > (say, KDE), then your focus is making the translations available for all the So you want to compare packages from an upstream with packages created by either someone or a team for a distribution? > people who use that package, whether or not the particular distribution > they got it from has infrastructure to support translations. Hence it makes > sense to put the translations in the package in that case. > If on the other hand you are one of those distributions, distributing > all sorts of packages, some of which have upstream translations, some of > which don't, some of whose maintainers are able and willing to spend time > on translations, some of whose maintainers aren't, then it doesn't make > sense to set yourselves up in such a way (translations always living in > packages) that translations will only be available when the maintainer > does work on them. Which creates the situation, that packages in debian will on the one hand be different then the one you can get from the upstream and on the other hand it's a violation of our social-contract: | software will be widely distributed and used. We will feed back | bug-fixes, improvements, user requests, etc. to the "upstream" authors | of software included in our system. So if we correct wrong translation or create a new translation, then we shall send it to the upstream and inform them. With your suggestion above, this will only happen, if either the translator is doing this task also or if the maintainer is taking care of the translation. In all other cases, where the maintainer is not taking care of the translation, we'll have a nice violation of that statement. And since the maintainer is the contact to the upstream and responsible for the debian package, he shall be involved in the translation. Splitting translation out of upstream packages is in my opinion a bad thing and should never be done. > > > But if we want to be, and are, able to easily add extra translations, or > > > override poor-quality upstream translations (all without causing hassles > > > for > > > maintainers), then why not? > > Because for example I would prefer to be informed if any of my packages > > has a bad upstream translation and some has better one for me. Then I > > can forward and discuss it with the upstream and he can include it maybe > > in the official upstream sources. That way we wouldn't only improve the > > translation for people using debian, but also for people who are using > > some other free operating system and the upstream package. > Fine, no-one is saying that you shouldn't be able to arrange to be notified > when a particular package has a translation made available. And how do you propose to integration this notifications? According to your statement, everyone can update the translation without having to hassle with me and that's the point which makes me sad. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpDbHwSPjryI.pgp Description: PGP signature
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On 01-09-06 Nick Phillips wrote: > On Thu, Sep 06, 2001 at 01:08:25PM +0200, Christian Kurz wrote: > > On 01-09-05 Nick Phillips wrote: > > > The translation of any part of a package, be it the text of error > > > messages, > > So, shall we now remove all .po files and other translation from > > upstream packages because they are not part of a package? The > > translation of the error messages and other messages of a program belong > > to the package of it. > That depends on whether you're distributing one package or thousands. Why do make this dependant on the number of packages? I think that using some count like you do, is a bad thing. > If upstream includes translations, then we don't have to worry about the > maintainer managing inclusion of whichever languages people happen to write > translations for. > But if we want to be, and are, able to easily add extra translations, or > override poor-quality upstream translations (all without causing hassles for > maintainers), then why not? Because for example I would prefer to be informed if any of my packages has a bad upstream translation and some has better one for me. Then I can forward and discuss it with the upstream and he can include it maybe in the official upstream sources. That way we wouldn't only improve the translation for people using debian, but also for people who are using some other free operating system and the upstream package. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpobuT4Njd53.pgp Description: PGP signature
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On 01-09-05 Nick Phillips wrote: > The translation of any part of a package, be it the text of error messages, So, shall we now remove all .po files and other translation from upstream packages because they are not part of a package? The translation of the error messages and other messages of a program belong to the package of it. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpNVcw3nJbiu.pgp Description: PGP signature
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On 01-09-04 Wouter Verhelst wrote: > On Tue, 4 Sep 2001, Michael Bramer wrote: > > Maybe I have on next WE more time and I can improve the server and > > make this notification mail configable per package and someone can > > remove his packages from the notification process. > You didn't already? > Jeez... In the US, this is illegal... and isn't gluck located in the > states? Would you telling me which part of this emails make them exactly illegal? They maybe annoying for some people, but they are not illegal in my opion. [1] Christian [1] No, I'm not a lawyer. P.S.: If you already call this e-Mails illegal, did you started lawsuits against all other us-based senders of mails to you, which you consider illegal? -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp2W4MEEMiiZ.pgp Description: PGP signature
Re: ddts: notification about pt_BR-translation of the hello-debhelper description
On 01-09-04 Nick Phillips wrote: > On Tue, Sep 04, 2001 at 09:06:04PM +0200, Michael Bramer wrote: > I don't expect most maintainers to be able or inclined to keep track of > a shedload of different translations, and those who are that keen should May I ask if you are aware about the ongoing translation of the debconf templates via the bts? If yes, would you mind explaining what's the difference between keeping track of thsoe translation/bugreports and keeping track of the package translation via a simple ddts mail? Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpK9nBMBbLu1.pgp Description: PGP signature
Re: CUPS
On 01-09-03 Michael Meskes wrote: > On Mon, Sep 03, 2001 at 11:16:31AM -0500, Dimitri Maziuk wrote: > > Probably because you're supposed to use a gooey web browser to add > > a printer... a bit much for a postinst script. > Not exactly. The way I read the docs you can use lpadmin from the > commandline to add a printer. In fact it works for the default deskjet ppd. Well, that's also a possible method for adding a printer. Do you get any error messages then on the console or in the logfiles beneath /var/log/cups? > > WTF is cupsomatic-ppd anyway? Go to http://localhost:631, add _a_ > > printer (say, call it foobar), get a PPD for your printer and copy > > it to /etc/cups/ppd/foobar.ppd. You can then use web frontend to > > configure things, duplex printing, watermark etc. Works for me. > But that's a hack and not a real configuration option. Hm, do you need the cupsomatic-ppd because there's no other ppd file in the cups package for your printer available? Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpy7cgCc0Ckz.pgp Description: PGP signature
Re: CUPS
On 01-09-02 Michael Meskes wrote: > I wanted to install DeskJet_670C-cdj670.ppd or DeskJet_670C-pcl3.ppd from > cupsomatic-ppd but just got a > > lpadmin: add-printer failed: The requested resource was not found on this > server. Would you mind telling us which version of cups you have installed? You didn't include that information. > Anyway, there does not seem to be much documentation and the web interface > on port 631 gives some error messages resp. tells me that the resource is > not available. Under the following URL http://localhost:631/documentation.html is a lot of documentation about Cups, especially also an administrator and an user manual. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp3Nq16vm7lh.pgp Description: PGP signature
Re: RFC: Signed packages and translations
On 01-09-01 Simon Richter wrote:
> On Sat, 1 Sep 2001, Christian Kurz wrote:
> > > not be ascii armored since this would only introduce transmission overhead
> > > and gain nothing. The file name for this file is constructed from the
> > Why does it gain nothing? What about problems during transmission? The
> > ascii armor output which is protected by a crc checksum would help
> > notice such a transmission problem.
> dpkg already has a mechanism for finding packages that have been corrupted
> by transferring them in ASCII mode. I mean, the .tar.gz is already binary,
Since which day does dpkg download packages in ascci-mode from a url?
Are you sure that you are not mixing up dpkg and apt-get? dpkg has as
far as I know no mechanismen to detected corrupted packages and therefor
having an ascii-armored signatures, with a crc checksum to detect
transmission errors will be helpful.
> so why should the file following it be ASCII?
Because there are situations where you don't use a tool that checks if
the transmission was fine. You should not only find a solution for the
specific case, that a tool downloads the packages from a server and
already checks if the transmission was fine, but also for situations
where such a tool is not provided.
> > > If the original filename is no more than sizeof(ar_name)-2 bytes
> > > long, ".s" is appended to it. If it is longer, the part of the
> > > file name before the
> > .s? Another new extension? If you want to achive confusion for our users
> > and developers, that's a possible way to go. If you really don't want to
> > use ascii armor, then the extension should be .sig or if you use
> > ascii-armor then .asc.
> The problem here is the filename length limit. I would have gone for
> ".sig" otherwise. Besides, you will only see those if you look at .deb
> files directly.
And that will never happen? I'm tempted to say that there are cases
where you have to look into the .deb directly or extract it via ar/tar.
And the people will be confused in those cases, if they notice a file
called .s, because that's an unusual extension.
> > > - Modify the autobuilders and existing developer scripts
> > > ("debsign") so that they call dpkg-deb to sign the packages
> > > additionally to signing the .changes file.
> > Sign packages build by an auto-builder?
> Of course. katie needs to verify that they were indeed created by an
> "official" autobuilder.
How do you want to handle the issue with the passphrase in a secure way?
How do you want to ensure that the key is safely placed on the
autobuilder and how do you want to ensure that only trusted people have
access to the autobuilder and especially this key? Placing a key on an
auto-builder with script that contains the passphrase to sign all
packages, is hazardous.
Christian
--
Debian Developer (http://www.debian.org)
1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853
pgp0eljz1vprX.pgp
Description: PGP signature
Re: RFC: Signed packages and translations
On 01-09-01 Martijn van Oosterhout wrote: > Can you store multiple signitures in the same file? Yes, that possible by using the OpenPGP format. You'll either need to use one-pass-signature packets, like GnuPG does by default, or the cleartext signed format. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpAhcfhcu5Nb.pgp Description: PGP signature
Re: FWD: Popularity-contest submission doesn't go through to apenwarr-survey@klecker.debain.org
On 01-04-30 Matthijs Melchior wrote: > Christian Kurz wrote: > > On 01-04-29 Joey Hess wrote: > > > Anyone have a clue? > > > Received: from myhostname.my.isp.com ([EMAIL PROTECTED] [127.0.0.1]) > > > by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with > > > +ESMTP id f3QDlYZ2018784 > > > for <[EMAIL PROTECTED]>; Thu, 26 Apr 2001 07:47:34 > > > +-0600 > > Suddenly here the email is address to [EMAIL PROTECTED] > > while in the previous line: > > > Received: (from [EMAIL PROTECTED]) > > > by myhostname.my.isp.com (8.12.0.Beta7/8.12.0.Beta7/Debian > > > +8.12.0.Beta7-1) id f3QDkJuS015600 > > > for [EMAIL PROTECTED]; Thu, 26 Apr 2001 07:46:19 -0600 > > Here it's addressed to [EMAIL PROTECTED] So I would assume > > that something on myhostname.my.isp.com is rewriting the email > > @debian.org to @klecker.debian.org. And I don't think that this > > localpart apenwarr-survey is available in the sub-domain > > klecker.debian.org but instead in the domain debian.org. So I would > > suggest that the configuration of this mail-server myhostname.my.isp.com > > will be checked to see why suddenly the rcpt-to changes. > > Please look at the following: > $ host -v -t MX -A debian.org > Query about debian.org for record types MX > Found 1 address for debian.org > Checking debian.org address 198.186.203.20 > !!! debian.org address 198.186.203.20 maps to klecker.debian.org > $ host -v -A http.us.debian.org [...] > So, mail to debian.org is the same as mail to klecker.debian.org No! This is absolutely wrong. The output just shows that the MX (Mail-Exchange) for the domain debian.org is klecker.debian.org. This has absolutely nothing to do with the email-address under the domain @debian.org. Never assume from an MX output something about the mail-address and local-parts in a domain and/or it's subdomains. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpCoX7U7Qe36.pgp Description: PGP signature
Re: FWD: Popularity-contest submission doesn't go through to apenwarr-survey@klecker.debain.org
On 01-04-29 Joey Hess wrote: > Anyone have a clue? > > Received: from myhostname.my.isp.com ([EMAIL PROTECTED] [127.0.0.1]) > by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with > +ESMTP id f3QDlYZ2018784 > for <[EMAIL PROTECTED]>; Thu, 26 Apr 2001 07:47:34 > +-0600 Suddenly here the email is address to [EMAIL PROTECTED] while in the previous line: > Received: (from [EMAIL PROTECTED]) > by myhostname.my.isp.com (8.12.0.Beta7/8.12.0.Beta7/Debian > +8.12.0.Beta7-1) id f3QDkJuS015600 > for [EMAIL PROTECTED]; Thu, 26 Apr 2001 07:46:19 -0600 Here it's addressed to [EMAIL PROTECTED] So I would assume that something on myhostname.my.isp.com is rewriting the email @debian.org to @klecker.debian.org. And I don't think that this localpart apenwarr-survey is available in the sub-domain klecker.debian.org but instead in the domain debian.org. So I would suggest that the configuration of this mail-server myhostname.my.isp.com will be checked to see why suddenly the rcpt-to changes. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpb9gkna3qRy.pgp Description: PGP signature
Re: Lightweight Web browsers
On 01-04-27 Jérôme Marant wrote: > Christian Kurz <[EMAIL PROTECTED]> writes: > > > > So come on people, let's install all 6000 packages, because maybe we > > could use them once. > > > Listen, I've packaged it in order to make available in debs for > people willing to test it. Now, don't blame me about those gnome > dependencies since I'm not upstream. APT is ment to show you > packages to be installed and does not force you to install. He, I didn't blame you or anyone else for this, I just used some sarcasm around your statement about disk space. > And apologies for not mentioning Gnome ... (since it seemed to > bother you) Not only me. It's just that the Gnome Libaries install a bunch of packages and also need quite some disk-space. Therefor I and I think some other people too would like to know before if the software depends on that bunch of libraries or not. > > Well, I just try to keep my system as clean as possible, which includes > > for me that I also check the installed libraries. And every time I try > > one of those gnome apps, I'm astonished about the big bunch of libraries > > that I have to install. Therefor I would prefer applications that just > > depend on the GTK Libraries and not the Gnome-Libraries. Therefor I > > would prefer it to know in advance if an ITP'ed software could become > > interesting for me or not. > Please note that did not ITPed it since I'm not sure people except > from me are interested in such a browser. And It does not seem to make > you very happy. Unless people are interested to see it in debian > I won't upload it. Sorry, I forgot that when I wrote my statement. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpc4qKV4tspW.pgp Description: PGP signature
Re: Lightweight Web browsers
On 01-04-27 Jérôme Marant wrote: > Christian Kurz <[EMAIL PROTECTED]> writes: > > May I ask why you don't mention that this is a web browser for Gnome? > > This information would be helpful for people that look for a lightweight > > HTML browser, but don't want to install Gnome. For those people this > > browser will not be a alternative, since it pulls in the whole bunch of > > gnome libs. :( > I mainly focused on low memory consumption, and Encompass meet this > requirement. Since maybe it wasn't obvious. I quite like to see software and especially a web browser that doesn't use much memory. > Then, mentioning Gnome usually make people think that the Gnome > Desktop Environment is required to run the browser which is not the > case. Well, I think that's a wrong assumption that people make, but you can't change it. So maybe it should have been worded "mentioned the dependency on the gnome libs". > And unless you have disk space restrictions, I don't see the problem > with installing gnome libs since these are shared between a growing > number of applications. > (Political reasons for not installing Gnome are not good reasons) So come on people, let's install all 6000 packages, because maybe we could use them once. Well, I just try to keep my system as clean as possible, which includes for me that I also check the installed libraries. And every time I try one of those gnome apps, I'm astonished about the big bunch of libraries that I have to install. Therefor I would prefer applications that just depend on the GTK Libraries and not the Gnome-Libraries. Therefor I would prefer it to know in advance if an ITP'ed software could become interesting for me or not. Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpyWb9Ik8b2E.pgp Description: PGP signature
Re: Lightweight Web browsers
On 01-04-26 Jérôme Marant wrote: > However, I found a simple HTML browser called Encompass > that takes far less memory than those I mentioned. Of course, > it does not have all the feature these browsers can offer > but it does handle HTML pretty well. I've build debs you can > find there: May I ask why you don't mention that this is a web browser for Gnome? This information would be helpful for people that look for a lightweight HTML browser, but don't want to install Gnome. For those people this browser will not be a alternative, since it pulls in the whole bunch of gnome libs. :( Christian -- Debian Developer (http://www.debian.org) 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpPOddeUQNTn.pgp Description: PGP signature
Re: (open)ssh-2.3.0p1 when??
On 01-01-07 Brian Frederick Kimball wrote: > Damian M Gryski wrote: > > On Sun, 07 Jan 2001, Svante Signell wrote: > > > Is openssh ever going to be upgraded? Latest unstable version is > > > 2.2.0p1-1.1 from September? while the latest OpenBSD release is now > > > 2.3.0p1! Maybe the package also should change name from ssh to openssh. > > > >openssh 2.3.0p1 was installed into unstable (sid) on Dec 30. Huh? Where did you got this information? There was only an upload to non-us on Dec 30. > Just uploaded or actually installed? It didn't show up on > non-us.debian.org until today (Jan 7th). I think the package should show up soon on non-us. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853
Re: lilo.conf
On 01-01-06 Matt Zimmerman wrote: > On Sat, Jan 06, 2001 at 05:40:53PM +0100, Christian Kurz wrote: > > On 01-01-06 Matt Zimmerman wrote: > > > On Sat, Jan 06, 2001 at 01:58:48PM +0100, Cosimo Alfarano wrote: > > > > On Sat, Jan 06, 2001 at 01:33:57PM +0100, Peter Makholm wrote: > > > > > Don't assume devfs! A lot of us uses it, but before our standard > > > > > kernel uses it our lilo package shouldn't assume it unless it is very > > > > > sure that it will work. > > > > > > > > He shouldn't assume it even if debian standard kernel package uses it. > > > > A lot of users don't use them (both std kernel and devfs). > > > > > Especially since devfs support is still considered experimental. > > > > Hm, it's not marked as experimental in kernel 2.4.0, but as work in > > progress. So support for it would be really good. > mizar:[~/src/linux/2.4.0/linux] egrep 'VERSION|LEVEL' Makefile | head -3 > VERSION = 2 > PATCHLEVEL = 4 > SUBLEVEL = 0 > mizar:[~/src/linux/2.4.0/linux] grep -B 1 ^CONFIG_DEVFS_FS > Documentation/Configure.help > /dev file system support (EXPERIMENTAL) > CONFIG_DEVFS_FS > mizar:[~/src/linux/2.4.0/linux] grep ' CONFIG_DEVFS_FS ' fs/Config.in > dep_bool '/dev file system support (EXPERIMENTAL)' CONFIG_DEVFS_FS > $CONFIG_EXPERIMENTAL > It will only show up if CONFIG_EXPERIMENTAL is defined. Hm, did you bother to read the explanation of devfs? There you find a statement, that is "work in progress" and so I wouldn't consider it experimental anymore. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpSdxtwDxNdz.pgp Description: PGP signature
Re: lilo.conf
On 01-01-06 Matt Zimmerman wrote: > On Sat, Jan 06, 2001 at 01:58:48PM +0100, Cosimo Alfarano wrote: > > On Sat, Jan 06, 2001 at 01:33:57PM +0100, Peter Makholm wrote: > > > Don't assume devfs! A lot of us uses it, but before our standard > > > kernel uses it our lilo package shouldn't assume it unless it is very > > > sure that it will work. > > > > He shouldn't assume it even if debian standard kernel package uses it. > > A lot of users don't use them (both std kernel and devfs). > Especially since devfs support is still considered experimental. Hm, it's not marked as experimental in kernel 2.4.0, but as work in progress. So support for it would be really good. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpE1qLPfiAvx.pgp Description: PGP signature
Re: Upcoming Events in Germany
On 01-01-06 Goswin Brederlow wrote: > > " " == Martin Schulze <[EMAIL PROTECTED]> writes: > > July 5-8 LinuxTag 2001, Stuttgart http://www.linuxtag.org/ > > http://www.infodrom.ffis.de/Debian/events/LinuxTag2001/ > Already planed to be there. I will be there any way, but I have to work out some other things before. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpQ1JrRxlart.pgp Description: PGP signature
Re: Anybody seen Loic Prylli lately?
On 01-01-04 Chuan-kai Lin wrote: > Does anyone know where Loic has been lately (i.e., for the past two years > or so)? AFAIK his last package upload was in November 1998, and the mail > I sent him about whether he needs help with mailx has generated no reply. > Since mailx is important, if the maintainer is indeed MIA, somebody should > take over this package and jove. I would volunteer for mailx in the > unlikely event that nobody else wants that package. If you would have looked into unstable first, you would have noticed that jove has been taken over by Cord Beermann, an upcoming new maintainer and I had once a contact with Loic to talk with him about his jove package. Now I'm waiting for his answer about mailx, so please wait some time more, so that I be able to get an answer from him. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853
Re: List of packages that could be dropped
On 00-12-28 Wichert Akkerman wrote: > Previously Christian Kurz wrote: > > |dpkg-scriptlib -- dpkg-perl and dpkg-python (142 days old) > > > > Is any package using functions of dpkg-perl or dpkg-python? If yes, I > > think someone should take care of this packages and the bugs that are in > > them. If not, could we move this packages from our distribution to > > experimental until they are fixed and a new maintainer for them has been > > found? > tetex depends on dpkg-perl. Hm, could this be the scripts written in sh-syntax. If I remember correctly, they are just doing some file-test and linking. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpJb9CsGL9L5.pgp Description: PGP signature
Re: List of packages that could be dropped
On 00-12-27 Jonathan McDowell wrote: > On Tue, Dec 26, 2000 at 06:59:16PM -0500, Ben Collins wrote: > > On Tue, Dec 26, 2000 at 03:22:21PM +0100, Christian Kurz wrote: > > > > > > |silo (195 days old) > > > > > > Has this package been removed from unstable and if yes, why? It's > > > currently still listed in the wnpp but I could find it which apt-cache > > > search silo. > > You can only remove this if you want sparc to be unbootable, which I > > hope is not your intention. > Um, I was going to adopt this until I saw: > silo (0.9.9-1) unstable; urgency=low > * New upstream > * Took over silo's packaging > -- Erick Kinnee <[EMAIL PROTECTED]> Mon, 4 Sep 2000 10:54:23 -0500 > Which I assumed meant Erick had done so? Well, if this is really true, then he should have closed the WNPP bug against silo a long time ago already. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp3Vw46FI7BV.pgp Description: PGP signature
Re: List of packages that could be dropped
On 00-12-26 Ben Collins wrote: > On Tue, Dec 26, 2000 at 03:22:21PM +0100, Christian Kurz wrote: > > > > |silo (195 days old) > > > > Has this package been removed from unstable and if yes, why? It's > > currently still listed in the wnpp but I could find it which apt-cache > > search silo. > You can only remove this if you want sparc to be unbootable, which I > hope is not your intention. If it's so important why is still marked as orphaned in wnpp? Or has already some taken over maintainership and just forgotten that there exists the WNPP? Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp2Ry7P82p50.pgp Description: PGP signature
Re: looking for replacement for run (because of critical bug in
On 00-12-26 Matt Zimmerman wrote: > On Tue, Dec 26, 2000 at 12:26:10PM +0100, Christian Kurz wrote: > > On 00-12-25 Matt Zimmerman wrote: > > > It would be nice if less included a feature to close and reopen the > > > current > > > file. Then this would not be necessary. > > > > Well, this is a feature that tail on FreeBSD has. If you start it with > > -F, it will tail you the current file like our tail -f. But if know the > > logfile will be rotated, it will notice this and reopen the new current > > one and tail this one. This is a feature that I really miss in GNU tail. > It sounds pretty easy to implement; just stat() and compare the inode number. > Is this how the FreeBSD tail does it? Why not write a patch for GNU tail? I'm not sure how FreeBSD tail handle this exactly, as I didn't look at it's code till now. But after having read the Mail from Ethan I think about patching tail to have an option -F which combines --follow=name and --retry. :) Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpFL4vjQnvNg.pgp Description: PGP signature
Re: looking for replacement for run (because of critical bug in
On 00-12-26 Ethan Benson wrote:
> On Tue, Dec 26, 2000 at 12:26:10PM +0100, Christian Kurz wrote:
> >
> > Well, this is a feature that tail on FreeBSD has. If you start it with
> > -F, it will tail you the current file like our tail -f. But if know the
> > logfile will be rotated, it will notice this and reopen the new current
> > one and tail this one. This is a feature that I really miss in GNU tail.
> in fact GNU tail does have this feature, its just done a bit
> differently:
> tail --follow=name --retry /var/log/messages
> ive been using this for ages without any problems, works quite nicely
> with log rotation, tail just outputs a message saying the file has
> been replaced, and follows the new one.
Well, as I'm a bit lazy in typing always this long option names, I just
wrote a patch to support -F and --follow-forever that do the same. As
the patch is very small, I will just attach it to this mail. (Yes, I
will seperately send it to the BTS.)
Ciao
Christian
--
Debian Developer and Quality Assurance Team Member
1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853
Binary files textutils-2.0.old/src/.tail.c.swp and
textutils-2.0/src/.tail.c.swp differ
diff -uNr textutils-2.0.old/src/tail.c textutils-2.0/src/tail.c
--- textutils-2.0.old/src/tail.cThu Aug 5 16:38:02 1999
+++ textutils-2.0/src/tail.cTue Dec 26 17:33:25 2000
@@ -187,6 +187,7 @@
{"allow-missing", no_argument, NULL, CHAR_MAX + 1},
{"bytes", required_argument, NULL, 'c'},
{"follow", optional_argument, NULL, 'f'},
+ {"follow-forever", optional_argument, NULL, 'F'},
{"lines", required_argument, NULL, 'n'},
{"max-unchanged-stats", required_argument, NULL, CHAR_MAX + 2},
{"max-consecutive-size-changes", required_argument, NULL, CHAR_MAX + 3},
@@ -1311,7 +1312,7 @@
count_lines = 1;
forever = from_start = print_headers = 0;
- while ((c = getopt_long (argc, argv, "c:n:f::qs:v", long_options, NULL))
+ while ((c = getopt_long (argc, argv, "c:n:f:F::qs:v", long_options, NULL))
!= -1)
{
switch (c)
@@ -1357,6 +1358,11 @@
follow_mode = XARGMATCH ("--follow", optarg,
follow_mode_string, follow_mode_map);
break;
+
+ case 'F':
+ forever = 1;
+ follow_mode = Follow_name;
+ reopen_inaccessible_files =1;
case CHAR_MAX + 1:
reopen_inaccessible_files = 1;
pgpjEdviCRNa3.pgp
Description: PGP signature
Re: looking for replacement for run (because of critical bug in
On 00-12-26 Andreas Fuchs wrote: > Today, Christian Kurz <[EMAIL PROTECTED]> wrote: > > Well, this is a feature that tail on FreeBSD has. If you start it with > > -F, it will tail you the current file like our tail -f. But if know the > > logfile will be rotated, it will notice this and reopen the new current > > one and tail this one. This is a feature that I really miss in GNU tail. > Uh, is this what you mean? > $ echo bar > /tmp/foo > $ tail -f /tmp/foo & (sleep 1; echo baz >> /tmp/foo; > sleep 1; echo qux > /tmp/foo) > bar[time passes] > baz[time passes] > ==> /tmp/foo: file truncated <== No, because you truncate the file here and that shouldn't happen. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpl4AsasGZgg.pgp Description: PGP signature
List of packages that could be dropped
Hi, we currently have a really huge list of packages that are orphaned and so I looked at them to see if we can drop some of them. Here are some suggestion and my comments. Any comment from you is appreciated: |ppd-gs (1 year and 357 days old) Do we really need this package still for users of alladin ghostscript or is it not needed anymore? |tcp4u (1 year and 81 days old) [Package libtcp4u3] Is this package still useful or can we drop it? |cthugha (1 year and 31 days old) Is this package really used by someone or useful for anything? The description is not very helpful in finding this out. |silo (195 days old) Has this package been removed from unstable and if yes, why? It's currently still listed in the wnpp but I could find it which apt-cache search silo. |dip (1 year and 81 days old) Fabrizio, has this package really been taken over? If yes, could you please close the wnpp-bug for it? Thanks. |libmikmod (214 days old) Is any architecture still using libmikmod1 or could we drop this part of the libmikmod package? |rel (1 year and 41 days old) Is this package used by anyone or can we just drop it? |mhash (235 days old) Has this package been dropped from unstable? If yes, can we close the wnpp-bug about it? |guavac (2 years and 53 days old) Can we please drop this package from our distribution as even upstream orphaned this package? |malaga (210 days old) Has this package been dropped? If yes, why and could be please close then the bug about it against wnpp? |admesh (349 days old) Has this package any good purpose or could it be dropped? |dpkg-scriptlib -- dpkg-perl and dpkg-python (142 days old) Is any package using functions of dpkg-perl or dpkg-python? If yes, I think someone should take care of this packages and the bugs that are in them. If not, could we move this packages from our distribution to experimental until they are fixed and a new maintainer for them has been found? |fnlib (104 days old) Has this package been removed from our distribution? is enlightenment not using it anymore? Or has it just be renamed? If the first is true, can we close the wnpp bug for it or if the last is true, can then someone please rename the bug in wnpp for it? |xipmsg (74 days old) Is this piece of software really used this days, where we have, ICQ,AIM,Jabber and other instant messenger tools? Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpkAkyvCViB5.pgp Description: PGP signature
Re: looking for replacement for run (because of critical bug in
On 00-12-25 Matt Zimmerman wrote: > On Mon, Dec 25, 2000 at 01:29:44PM +, Marc Haber wrote: > > On Sat, 23 Dec 2000 15:41:54 -0500, Matt Zimmerman <[EMAIL PROTECTED]> > > wrote: > > >However, I would say that if the program dies so frequently that it needs a > > >wrapper like this, it should probably be fixed. > > > > console-log uses less syslog which dies every time the user types "Q". > > And it needs to die if the log has been rotated. > It would be nice if less included a feature to close and reopen the current > file. Then this would not be necessary. Well, this is a feature that tail on FreeBSD has. If you start it with -F, it will tail you the current file like our tail -f. But if know the logfile will be rotated, it will notice this and reopen the new current one and tail this one. This is a feature that I really miss in GNU tail. Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpTPZeKJ9TrV.pgp Description: PGP signature
Re: Scsh (Was: Re: My orphaned packages.)
On 00-09-12 Daniel Kobras wrote: > On 11 Sep 2000, Karl M. Hegbloom wrote: > > > "Daniel" == Daniel Kobras <[EMAIL PROTECTED]> writes: > > > > Daniel> On 10 Sep 2000, Karl M. Hegbloom wrote: > > >> `scsh' ought to be taken over by someone who actually uses it. I've > > >> not even looked at it in over a year. > > > > Daniel> If nobody objects I'd like to do this together with Martin > > Daniel> Gasbichler who wrote a fair part of scsh 0.6. But me > > Daniel> having just applied for Debian maintainership this will > > Daniel> take some time... > > > > I also have an adoption offer from Georg Bauer (Cc'd), who I > > responded to on the attached message, telling him that if he contacts > > the new maintainer team and has a working `scsh' package, he can have > > it. > > > > Since you are teaming with Martin Gasbichler, and since Martin is a > > co-author of Scsh, I'd say that puts you two in as most qualified to > > handle the package. (Daniel? Please forward this mail to Martin.) > > > > Perhaps the three of you could team? What do you all think? > Sounds good to me. Martin is on vacation for a couple of days but I'm sure > we can work out a scheme everyone's confident with as soon as he's > back. The big problem IMHO however being that neither of us is registered > as a developer so far. I'd be happy to work on debs for a recent version > of scsh but we'd really need some maintainer to adopt the package until my > appliance gets through. You don't need a package maintainer to adopt the package for getting a new package uploaded. A sponsor for you and Martin would be enough to upload the package to the archive. Do you already are in the NM-Queue (nm.debian.org)? Ciao Christian -- Ein "Nein" ausgesprochen mit der tiefsten Überzeugung ist besser und größer als ein "Ja" um zu gefallen oder noch schlimmer, um Schwierigkeiten zu umgehen. -- Mahatma Gandhi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I propose gazillion packages (LONG)
On 00-08-17 Juhapekka Tolvanen wrote: > AIDE: > http://www.cs.tut.fi/~rammer/aide.html |[EMAIL PROTECTED] apt-cache show aide |Package: aide |Version: 0.7-6 |[...] |Maintainer: Mike Markley <[EMAIL PROTECTED]> > boxes: > http://www6.informatik.uni-erlangen.de/~tsjensen/boxes/ |[EMAIL PROTECTED] apt-cache show boxes |Package: boxes |Version: 1.0.1-1 |[...] |Maintainer: KELEMEN Peter <[EMAIL PROTECTED]> > QuickList: > http://www.quicklist.org/ |[EMAIL PROTECTED] apt-cache show quicklist |Package: quicklist |Version: 0.8.6-2 |[...] |Maintainer: Bradley Bell <[EMAIL PROTECTED]> > Artistic Style: > > http://astyle.sourceforge.net/ |[EMAIL PROTECTED] apt-cache show astyle |Package: astyle |Version: 1.11.6-1 |[...] |Maintainer: Sean 'Shaleh' Perry <[EMAIL PROTECTED]> > deroff: > http://www.moria.de/~michael/deroff/ |[EMAIL PROTECTED] apt-cache show deroff |Package: deroff |Version: 1.1-2 |[...] |Maintainer: David Frey <[EMAIL PROTECTED]> > mp3_check: > http://mp3check.sourceforge.net/ |[EMAIL PROTECTED] apt-cache show mp3check |Package: mp3check |Version: 1.97-1 |[...] |Maintainer: Norbert Tretkowski <[EMAIL PROTECTED]> So, may I suggest that in the future you first check which software is already packaged for debian? Ciao Christian -- Debian Developer and Quality Assurance Team Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgp3Pg7FzA5FF.pgp Description: PGP signature
Re: ITP John the ripper
On 00-03-26 Matt Zimmerman wrote: > On Sat, Mar 25, 2000 at 03:39:24PM +0100, Christian Kurz wrote: > > as jsut discussed on debian-devel, I would like to package John the > > Ripper. If someone already has done or is working on it, please mail me, > > then I will stop packing it. Otherwise I will try to upload this package > > till friday next week to woody. > I briefly looked into packaging this a while ago, and I couldn't find a > license > in the distribution. Are you aware of a license for this program, or have you > contacted the upstream author? After talking with the upstream author, this program has now been packaged for debian is available on master in incoming. Ciao Shorty -- Debian Developer and Quality Assurance Committee Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpjFlyBK8R4l.pgp Description: PGP signature
Re: ITP John the ripper
On 00-03-26 Josip Rodin wrote: > On Sun, Mar 26, 2000 at 11:15:20AM -0500, Matt Zimmerman wrote: > > > as jsut discussed on debian-devel, I would like to package John the > > > Ripper. If someone already has done or is working on it, please mail me, > > > then I will stop packing it. Otherwise I will try to upload this package > > > till friday next week to woody. > > > > I briefly looked into packaging this a while ago, and I couldn't find a > > license > > in the distribution. Are you aware of a license for this program, or have > > you > > contacted the upstream author? > A friend of mine asked Solar Designer, and he said it's GPL or something... Well, I asked him to add a note to the package which describes the license of the package. Hopefully I can convince him to do so, so that I or somebody else are able to package it. Ciao Christian -- Debian Developer and Quality Assurance Committee Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpTzLlSmhIAw.pgp Description: PGP signature
ITP John the ripper
Hi, as jsut discussed on debian-devel, I would like to package John the Ripper. If someone already has done or is working on it, please mail me, then I will stop packing it. Otherwise I will try to upload this package till friday next week to woody. Ciao Christian -- Debian Developer and Quality Assurance Committee Member 1024/26CC7853 31E6 A8CA 68FC 284F 7D16 63EC A9E6 67FF 26CC 7853 pgpTYeO90YH8l.pgp Description: PGP signature
Re: ITO penguineyes and bvi
On 99-09-23 Stijn de Bekker wrote: > On Tue, Sep 21 1999, Christian Kurz wrote: > > I intent to orphan bvi and penguineyes. I will orphan bvi, because I > > don't use it much anymore and penugineyes will get orphaned, because I > > gave gnome I try, but I don't like it much and so I want to remove it, > > which makes packaging penguineyes a bit hard. If somebody wants to take > > one of the packages over, feel free to do so. > I'll take over the bvi package. Remco van de Meent has already offered > to sponsor as I'm no official maintainer yet. Okay, it's yours. Ciao Christian -- ******** * Christian Kurz Debian Developer/QA-Team * * Use Debian - a free Operating System * pgprMVzlURAiQ.pgp Description: PGP signature
ITO penguineyes and bvi
Hi, I intent to orphan bvi and penguineyes. I will orphan bvi, because I don't use it much anymore and penugineyes will get orphaned, because I gave gnome I try, but I don't like it much and so I want to remove it, which makes packaging penguineyes a bit hard. If somebody wants to take one of the packages over, feel free to do so. Ciao Christian -- **** * Christian Kurz Debian Developer/QA-Team * * Use Debian - a free Operating System *
Request for Packaging
Hi, here are some collected request for programms, which should IMHO be packaged for Debian: 8<-8< CUT HERE 8<-8< What's bjorb? Overview Bjorb is secure TCP relay software. Bjorb provides to you secure end-to-end connection over insecure network such as Internet. Highlights * Bjorb relays all 'static port' based TCP communications with SSL protocol. Such as SMTP, POP3, NNTP, HTTP, TELNET. Not FTP. * Bjorb can make a usual telnet server behave like SSL telnet. License Bjorb itself is free software. You can use, modify, and redistribute for non-commerical and commerical purpose in most case. Read COPYRIGHT file for more details. Bjorb uses SSLeay library. 8<-8< CUT HERE 8<-8< PGP Moose / by Greg Rose <[EMAIL PROTECTED]> The aim of this software is to monitor the news postings of moderators of USENET newsgroups, and to automatically cancel forged messages purporting to be approved. This can be extended to the approvals of individual users to automatically cancel messages that appear without having been authorised by the user. This has (obviously) been prompted by the recent spammings and other events. This software and protocol is designed around cryptographic signatures. The protocol is designed to allow the use of different signature techniques. This implemention assumes the use of PGP signatures, but can be easily modified to use others, such as the Digital Signature Standard. PGP was chosen for its widespread availability around the world. PGP, the crux of the cryptographic software, was written by Phil Zimmermann <[EMAIL PROTECTED]>, who otherwise has nothing to do with this. The cryptographic framework was written by Greg Rose <[EMAIL PROTECTED]>, as were the INN news system hooks. http://people.qualcomm.com/ggr/PGPMoose.tar.Z ftp://ftp.dinoex.sub.de/pub/approved/PGPMoose.tar.Z 8<-8< CUT HERE 8<-8< Dejasearch A frontend to DejaNews (http://www.dejanews.com/), the popular Usenet archive and search engine. It will submit a search for you to DejaNews, then retrieve and consolidate all search results into one single HTML file, sorted in newsgroup, subject and date (reverse) order. http://homemade.hypermart.net/dejasearch/dejasearch12.tar.gz http://homemade.virtualave.net/dejasearch/dejasearch12.tar.gz 8<-8< CUT HERE 8<-8< mkmf makefile editor (revision 4.11) ftp://ftp.uni-koeln.de/util/mkmf.tar.gz 8<-8< CUT HERE 8<-8< Cheers Christian -- * Christian Kurz Debian Developer * * Use Debian - a free Operating System for your PC *
Re: request to kill nag messages
Christian Meder <[EMAIL PROTECTED]> wrote: > On Thu, May 20, 1999 at 11:48:25AM +0200, Christian Kurz wrote: > > Christian Meder <[EMAIL PROTECTED]> wrote: > > > Example: I've got an open old bug report that flying > > > (a X11 pool game) doesn't support 16/24 bit displays. The upstream > > > > This would speak for making the mechanismen configurable. Would this be > > a solution? > Making which mechanism configurable ? The bug system ? The nag messages ? > Could you expand what you are aiming at ? I meant the nag-messages about which we are talking here. Would be a solution to make it configurable if you want to get those or not? Cheers Christian -- **** * Christian Kurz Debian Developer * * Use Debian - a free Operating System for your PC *
Re: request to kill nag messages
Christian Meder <[EMAIL PROTECTED]> wrote: > On Wed, May 19, 1999 at 09:24:19PM +0200, Christian Kurz wrote: > > Well what is the problem with this? I don't see any offence in getting a > > message that says that I (the maintainer) has still open bug over a > > certain age. I think this is a good reminder for the maintainers as you > > may forget to fix bugs. Take a look at the ppp-package and how many open > > bugs there have been. The maintainer hadn't fixed them and so I helped > > him. (Sorry Phil, but this is a good example and No, I don't want to > > praise me with this). Or have you taken a look at the list on > > http://master.debian.org/~ajt/bugsbyage.txt? Have you seen how many open > > old bugs we got? How do you think we get this fixed without reminding > > the developers of their open bugs? > I think you miss the point. Nobody's arguing that we shouldn't keep a > public list of open old bugs. For interested developers it makes > sense to do some qa after checking such a list. ACK > The point is that the diligent maintainer is well aware of his/her > open old bug reports and usually has some valid reasons to leave the > bug report open. Then why doesn't he place a message in the BTS saying why it isn't possible to fix the bug? So that people lookin throught the BTS see, if they can help to fix the bug or if this isn't possible? > Example: I've got an open old bug report that flying > (a X11 pool game) doesn't support 16/24 bit displays. The upstream This would speak for making the mechanismen configurable. Would this be a solution? Cheers Christian -- * Christian Kurz Debian Developer * * Use Debian - a free Operating System for your PC *
Re: request to kill nag messages
[DONT SEND ME A CC!] Dale Scheetz <[EMAIL PROTECTED]> wrote: > On Wed, 19 May 1999, Christian Kurz wrote: > > [You don't need to send me an extra Cc as I read the lists on which I > > write. Thanks!] > > > > Dale Scheetz <[EMAIL PROTECTED]> wrote: > > > On Wed, 19 May 1999, Christian Kurz wrote: > > > > > > Branden Robinson <[EMAIL PROTECTED]> wrote: > > > > > On Tue, May 18, 1999 at 03:32:20PM -0400, [EMAIL PROTECTED] wrote: > > > > > > > > > > > > > > I'm not the only one to be annoyed at the nag messages that are > > > > > > > sent out. > > > > > > > Can the script please be disabled. There are better ways to find > > > > > > > out bugs > > > > > > > you have open. Long-standing bugs are likely to be less > > > > > > > important than > > > > > > > recent bugs too. > > > > > > > > > > > > > > > > > > > I would rather see the old bugs closed. An old bug is still a bug. > > > > > > > > > > > > Don't like the messages, help close the bugs. > > > > > > > > > Wrong. Brian White is no longer the release manager, so he has no > > > > > special > > > > > privilege to send mails like this. > > > > > > > > Oh, does somebody need a special privilege to tell us which general bugs > > > > are too old and need to be resolved? I don't think so. > > > > > No one needs to take on that job, as the BTS already reports all open bugs > > > twice a week to every developer. > > > > Are you sure? I don't know that this is done by the BTS and have never > > heard about this? > Here is a sample of the beggining of what I normally get on Tuesdays: > -begin paste- > Date: Tue, 4 May 1999 16:29:46 -0500 > From: Debian Bug Tracking System <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Unanswered problem reports by maintainer and package > Resent-Date: 4 May 1999 21:30:06 - > Resent-From: [EMAIL PROTECTED] > Resent-cc: recipient list not shown: ; > The following problem reports have not yet been marked as `taken up' by a > message to [EMAIL PROTECTED] or or `forwarded' by a > message to [EMAIL PROTECTED] > ---end paste-- > Note that this is a subscription list, so you must request placement on > this "automated" report generator. Hm, this looks for me like you use a cronjob to fetch your bugreports. Or where is this described? > On Friday the report is ordered differently, and can be grepped for your > name to separate out your own bugs from all the rest. Hm, sound interesting. > You can also request limited reports on your own. Send the word help in > the body of a message to [EMAIL PROTECTED] and you will get a list > of all the commands that the request server responds to. Among them are > requests for indexes by package, or by maintainer. You can then take these > indexes and request the actual bug report itself. Oh so you need to set this up on your own? There's only one point which I'm missing: How many maintainers use this? Is this used by nearly every maintainer or only some? I think we need a mechanismen, which is configurable, which automatically tells you after some time which bugs are open and need to be closed. So you are automatically subsribed to these messages, but you can stop it if you want. > > > If this was simply a report to the list, once in a while, like the > > > "critical bugs that need to be fixed" list, there would be no problem. > > > Instead this mail is generated automatically and sent to every developer > > > with an open bug report over a certain age. > > > > Well what is the problem with this? I don't see any offence in getting a > > message that says that I (the maintainer) has still open bug over a > > certain age. I think this is a good reminder for the maintainers as you > The problem is that I can not request that the messages stop, like I can > with this list, and the other BTS lists. Even aggressive, and angry > requests have met with rejection. This is, by definition, unwanted spam. So why don't we contact Brian and ask him about making this configurable? Has anyone contacted him yet about this? If not, I will write him a mail at the weekend. > > may forget to fix bugs. Take a look at the ppp-package and how many open > > bugs there have been.
Re: request to kill nag messages
Brian Almeida <[EMAIL PROTECTED]> wrote: > On Wed, May 19, 1999 at 09:28:33PM +0200, Christian Kurz wrote: > > So where's the problem with getting an reminder about your old open > > bugs, which you need to fix? > I don't NEED a reminder about my bugs. There should be an option to TURN THE > BLOODY > THING OFF. OK, this would be a good point. Making it configurable if you want to get those messages or not. But in general I don't think that should be turned off. Cheers Christian -- **** * Christian Kurz Debian Developer * * Use Debian - a free Operating System for your PC *
Re: request to kill nag messages
Brian Almeida <[EMAIL PROTECTED]> wrote: > On Wed, May 19, 1999 at 04:45:11PM +0200, Christian Kurz wrote: > > And what do you propose should be done with bugs that are so old? Still > > let them stay open and look somewhere else? No, that isn't a solution. > > The solution is to contact the developer and ask them about the bugs and > > try to track the problem down and fix the bug. This has nothing do to > > with spamming instead these are person, which are interested in > > improving th quality of the distribution. > Considering the X bug list, I'm sure branden got a quite large mailing > from 'Nag' about old bugs - yet from what I understand, he can't > possibly go through that list until some modifications are done to the > BTS. Hm, in the list from NAG are the URLs which lead to the page with the bugreport on it. So what modifications need to be done for making these messages usable? > 'Nag' also goes to developers personally, not only to -devel. So where's the problem with getting an reminder about your old open bugs, which you need to fix? Cheers Christian -- * Christian Kurz Debian Developer * * Use Debian - a free Operating System for your PC *
Re: request to kill nag messages
[You don't need to send me an extra Cc as I read the lists on which I write. Thanks!] Dale Scheetz <[EMAIL PROTECTED]> wrote: > On Wed, 19 May 1999, Christian Kurz wrote: > > Branden Robinson <[EMAIL PROTECTED]> wrote: > > > On Tue, May 18, 1999 at 03:32:20PM -0400, [EMAIL PROTECTED] wrote: > > > > > > > > > > I'm not the only one to be annoyed at the nag messages that are sent > > > > > out. > > > > > Can the script please be disabled. There are better ways to find out > > > > > bugs > > > > > you have open. Long-standing bugs are likely to be less important > > > > > than > > > > > recent bugs too. > > > > > > > > > > > > > I would rather see the old bugs closed. An old bug is still a bug. > > > > > > > > Don't like the messages, help close the bugs. > > > > > Wrong. Brian White is no longer the release manager, so he has no special > > > privilege to send mails like this. > > > > Oh, does somebody need a special privilege to tell us which general bugs > > are too old and need to be resolved? I don't think so. > No one needs to take on that job, as the BTS already reports all open bugs > twice a week to every developer. Are you sure? I don't know that this is done by the BTS and have never heard about this? > If this was simply a report to the list, once in a while, like the > "critical bugs that need to be fixed" list, there would be no problem. > Instead this mail is generated automatically and sent to every developer > with an open bug report over a certain age. Well what is the problem with this? I don't see any offence in getting a message that says that I (the maintainer) has still open bug over a certain age. I think this is a good reminder for the maintainers as you may forget to fix bugs. Take a look at the ppp-package and how many open bugs there have been. The maintainer hadn't fixed them and so I helped him. (Sorry Phil, but this is a good example and No, I don't want to praise me with this). Or have you taken a look at the list on http://master.debian.org/~ajt/bugsbyage.txt? Have you seen how many open old bugs we got? How do you think we get this fixed without reminding the developers of their open bugs? > > > This is no different from some "helpful" developer spamming people who, > > > say, have had bugs open for over a year. Such people have (rightly) come > > > under fire in the past. > > > > And what do you propose should be done with bugs that are so old? Still > > let them stay open and look somewhere else? No, that isn't a solution. > > The solution is to contact the developer and ask them about the bugs and > > try to track the problem down and fix the bug. This has nothing do to > > with spamming instead these are person, which are interested in > > improving th quality of the distribution. > > > This is not a "person" asking a developer to fix a bug. This is an > automated system that spits out messages with NO content of use to the > developer, and adds nothing but bulk to the already functional system. Where has the message no content? It tells you which bugs are very old and haven't been fixed, so you can take a look at them and fix them. And the point that this is an automated system doing this is IMHO no cause to treat them like spam. It's has been automated as a normal person can't to this on her own. > This _is_ spam, and nothing more. Please be aware that any message with > the word "Nag" in the subject is always deleted and never read when sent > to me, so if you really want to contact me don't use that word ;-) Well, that's you problem, but better would be a kill on the From-Line instead of the Subject. > You aren't really suggesting that any "well meaning" person is correct to > set up an automated system for notifying developers about important issue here>, then you should not complain when some dodo sends > you, and the list, critical information about how to get rich quick. He is > only trying to be informative... Well, I don't like spam as it has nothing to do with my work or my hobby. But these messages are there for informing me, that I have open bugs and that I need to fix them. So it's a reminder for me as developer. Or how should we remind developer of their old bugs? Go by hand through the BTS and sort them out? Are you sure that every developer knows which open bugs he has and how old they are? I'm not and since the messages are not send every day or every week or every month but instead after a certain amount of time, more than 4 months, I don't treat them like spam. Cheers Christian -- * Christian Kurz Debian Developer * * Use Debian - a free Operating System for your PC *
Re: request to kill nag messages
Branden Robinson <[EMAIL PROTECTED]> wrote: > On Tue, May 18, 1999 at 03:32:20PM -0400, [EMAIL PROTECTED] wrote: > > > > > > I'm not the only one to be annoyed at the nag messages that are sent out. > > > Can the script please be disabled. There are better ways to find out bugs > > > you have open. Long-standing bugs are likely to be less important than > > > recent bugs too. > > > > > > > I would rather see the old bugs closed. An old bug is still a bug. > > > > Don't like the messages, help close the bugs. > Wrong. Brian White is no longer the release manager, so he has no special > privilege to send mails like this. Oh, does somebody need a special privilege to tell us which general bugs are too old and need to be resolved? I don't think so. > This is no different from some "helpful" developer spamming people who, > say, have had bugs open for over a year. Such people have (rightly) come > under fire in the past. And what do you propose should be done with bugs that are so old? Still let them stay open and look somewhere else? No, that isn't a solution. The solution is to contact the developer and ask them about the bugs and try to track the problem down and fix the bug. This has nothing do to with spamming instead these are person, which are interested in improving th quality of the distribution. Cheers Christian -- * Christian Kurz Debian Developer * * Use Debian - a free Operating System for your PC *
Re: request to kill nag messages
Adrian Bridgett <[EMAIL PROTECTED]> wrote: > I'm not the only one to be annoyed at the nag messages that are sent out. > Can the script please be disabled. There are better ways to find out bugs > you have open. Long-standing bugs are likely to be less important than > recent bugs too. No, these bugs are also important and need to be resolved as every bug. The decision which bugs are important does not depend on the age. And the nag-messages to this list has come, as the bugs are general bugs and there's no developer for them. Every developer can fix those bugs and so it's a good to sent this message to the list. Cheers Christian -- **** * Christian Kurz Debian Developer * * Use Debian - a free Operating System for your PC *
