Re: devfsd permissions and makedev permissions coordination
On Sun, Sep 10, 2000 at 09:56:30PM +0200, Marco d'Itri wrote: On Sep 10, Tom Lees [EMAIL PROTECTED] wrote: Terminal devices [1]root.tty 0666 This is obviously wrong, ttys must have 620 permissions (or 600 if you don't want people talk(1)ing to you, but I think the default should be to allow it). It's a huge security hole because with a ioctl you can inject commands into shells not owned by you. For ttys owned by a shell that's true, but it's set up by login(1), not MAKEDEV (or devfsd). For other ttys (vcs, not serial etc.), the current behaviour of MAKEDEV is to create them root.root 0666. Serial devices are created root.dialout 0660. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: maintainers in Cambridge, UK?
On Sat, Sep 09, 2000 at 10:35:21AM +0100, Philip Blundell wrote: Are there any maintainers in Cambridge who would be willing to sign my GPG key? You might be better off sending this to the debian-uk list, [EMAIL PROTECTED] But I think most people there also read -devel. There are a number of developers in Cambridge; usually more during term time. I will be there this term on 30th Sept, and would be happy to sign your key, if you don't find anyone beforehand. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
devfsd permissions and makedev permissions coordination
Hi there. I'm the current Debian devfsd maintainer. As you may or may not know, the current devfsd package parses the /sbin/MAKEDEV script in its build procedure to generate a standard list of permissions for devices (one of the main functions of devfsd is to control the permissions of the automatically generated devices in /dev). Anyway, this is somewhat inconvenient; it produces a large file and requires a couple of hacks to the current devfsd (since the old device filenames and the new devfs names are different, I needed to add symlink following code), although I've emailed the upstream maintainer about integrating these hacks. So, I think a better way to proceed would be to unify the device permissions between makedev and devfsd, probably by creating a new part of debian-policy on the ownership and mode of devices in the system. I'm not really sure what would be practical here; ideally the devfs-based system and the non-devfs-based system would act identically. However, devfs gives the sysadmin and the packagers a lot more power over permissions. For example, we can set the group specifically for ide-cd devices to cdrom for example (since the real filename is .../cd, not just /dev/hdc or something). The policy needn't be too specific; I think statements like hard disks should be owned root.disk, mode 0660 are specific enough. Here's a rough draft list based on the devices in my system and the first few lines of /sbin/MAKEDEV: Hard disks, disk partitions, ramdisks root.disk 0660 CD-ROM devices root.cdrom 0660 Floppy devices root.floppy 0660 Tape devicesroot.tape 0660 Terminal devices [1]root.tty 0666 /dev/consoleroot.tty 0622 Sound devices root.audio 0660 V4L devices[2], /dev/3dfx, /dev/agpgart root.video 0660 lp (parallel line printer) devices root.lp 0660 /dev/kmem, /dev/mem, /dev/port root.kmem 0640 Special devices (/dev/zero, /dev/null, /dev/full) root.root 0666 Various sockets and pipes (/dev/log etc.) root.root 0666 /dev/psaux root.root 0660 /dev/urandom, /dev/random root.root 0444 OBviously this list is nothing like complete; I'd appreciate some help completing it, then I will make a policy draft for it. [1] Virtual consoles (ttyxx), pseudo-ttys, serial devices [2] Curiously includes radio-receiver devices (group video not audio) [forgive me (but please say so) if this belongs on debian-policy; I'm a bit ignorant about the exact function of that list and don't read it myself] -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: apt-move problem
On Sat, Sep 09, 2000 at 03:00:56PM +1100, Brian May wrote:
Paul == Paul Slootman [EMAIL PROTECTED] writes:
Paul Please check the BTS for apt-move, this is discussed
Paul externsively. Apparently it's a (for me non-obvious) bug in
Paul bash.
Why not change the ( and ) to { and } respectively?
At least this way, it will work with potato...
...and as far as I can tell it is a bit inconsistent anyway - some
functions are defined with ( and ), while others are defined with {
and }.
You can change it to { ( and ) newline }; this will work with exactly the
same functionality (I think; I tested against zsh which executes functions
with ( and ) properly).
...or does this have a different meaning?
AFAIK it causes ther function to execute in a subshell (or at least variables
are all local etc.)
--
Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#66084: lvm: 0.8i - 0.8final migration
On Fri, Aug 18, 2000 at 05:05:46AM -0500, Peter Samuelson wrote: Untested. (Come to think of it, instead of LD_PRELOAD you should use rpath, which is considered harmful but I think is justified here.) Yes, package size doubles, but you must not be worried about size since you currently statically link against liblvm. The main issue here is that it's not currently possible to dual-boot 2.2 and 2.4 kernels with lvm, so migration may be difficult for many people. There is a backport of the 2.4 version of LVM to 2.2, which I have successfully run on a production system for a while now at work, so hopefully yhis system won't be necessary... however, this does still leave a big problem: how to handle the upgrade from 0.8i to 0.8final. If you are currently using LVM 0.8i, then upgrade to 0.8final, LVM will stop working unless you also recompile your kernel. I thought I could maybe make an lvm-0.8i_0.8i-... package or something similar, which Replaces: lvm ( 0.8final), and is Recommended by the new lvm 0.8final. So... what I need to know is this: What exactly is the behaviour of apt when upgrading a package. How can I make it so that if you upgrade from the LVM 0.8i pkg to the 0.8final pkg, you get a compatibility package installed by apt or dselect or dpkg, but if you install the package fresh, that doesn't happen. Or should I put some sort of warning in the preinst? The ideal situation would be to have 0.8final the standard version for both 2.2 and 2.4 kernels, with a 0.8i compatibility package, IMHO. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
ITP: lirc, devfsd
I have packaged LIRC and will upload it later today or tomorrow if noone objects. LIRC is Linux Infra-red Remote Control support, see http://fsinfo.cs.uni-sb.de/~columbus/lirc/index.html Similarly, I have packaged devfsd (http://www.atnf.csiro.au/~rgooch/linux/). This one still needs a couple of problems ironing out first. -- Tom [EMAIL PROTECTED] Captain's Log, star date 21:34.5...
Re: 5 days till Bug Horizon
On Wed, Mar 22, 2000 at 08:43:08AM -0500, Ben Collins wrote: Package: cvs (debian/main). Maintainer: Tom Lees [EMAIL PROTECTED] 59543 cvs: cvs-makerepos does not exist Isn't this just cvs init? I think this is supposed to be a script that creates the repos that you listed in the configuration (debconf). Doesn't appear to eexitist even in the source. It does exist, but I forgot to include it in the package in 1.10.7-4. I'll remove references to it from the documentation for now. 59909 cvs: cvs segfaults when commiting a dir This seems to be unreproducable and there has been no response from the submitter so I'm going to downgrade this to normal. -- Tom [EMAIL PROTECTED] Nasrudin called at a large house to collect for charity. The servant said My master is out. Nasrudin replied, Tell your master that next time he goes out, he should not leave his face at the window. Someone might steal it.
Re: Single architecture on -announce lists
On Sat, Mar 18, 2000 at 05:30:41PM +0100, Paul Seelig wrote: Currently i've subscribed to devel-changes on another mail account which only serves for sorting out the relevant (at least for me) parts. These are sorted out using procmail (which is not supported by my usual mail server) and are forwarded this way to my usual mail account, dropping the rest (IMHO the major part) into the bit bucket. Could you possibly post/email me your procmail recipes to do this? -- Tom [EMAIL PROTECTED] Keep a diary and one day it'll keep you. -- Mae West
Re: off-topic! Anonymous CVS access?
On Tue, Jan 19, 1999 at 11:56:16PM -0600, Oleg Krivosheev wrote:
Hi, All
can someone tell me how to setup anonymous read-only
access to CVS tree via pserver in slink?
Of course with minimum security problems...
thanks a lot in advance
Read the CVS info file, look under Admin files, then one of either
readers or writers.
Basically, you want to do the following:-
1. Put a file passwd in $CVSROOT/CVSROOT/,
containing a line like this:-
anonymous:tLE75Q0w/AnU2
The password is anonymous. Generate it like this:-
echo 'main(){printf(%s\n,crypt(password,tL));}'t.c; \
gcc -o t t.c -lcrypt; ./t; rm t t.c
NB, replace tL with two random characters, and password with your desired
password.
2. Then, put a file readers containing:-
anonymous
Alternatively, create an empty file writers (possibly more secure...).
Then, make sure you have the repository exported (run cvsconfig as
root), and pserver enabled.
More info is available in the CVS documentation.
--
Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/
PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkeys.asc.
Re: slink_cd v 1.02
On Fri, Jan 15, 1999 at 11:56:09AM +, Steve McIntyre wrote: One thing you _will_ need to do to use the symlink-farm is use a patched mkhybrid that flattens things as it makes the ISO images. I've separated this patch out of a larger one by Tom Lees [EMAIL PROTECTED] and the images I'm writing _right now_ are using this stuff. Grab the source and patch or the i386 binary from the above location. The rest of this patch is the bootable stuff, right? Could you send me the patch you made, so I can distribute the two features separately. Thanks. Anyway, I now have the ability to test my CD-images back, so I should be able to get the bootable stuff sorted fairly soon. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkeys.asc. pgpuktIu6u2Xz.pgp Description: PGP signature
Re: 1FA: problem still in hamm disks
On Fri, Oct 16, 1998 at 12:34:09PM -0700, Ben Gertzfield wrote: Brent == Brent Fulgham [EMAIL PROTECTED] writes: Brent I'd like to chime in -- It's a real annoyance that the base Brent disks don't set up lilo to let you boot into multiple Brent operating systems. Couldn't it ask if you want to Brent dual-boot with windows, or whatever, and generate an Brent appropriate lilo.conf file? Sure. How about you write the script to do so? While I'm at it, *PLEASE* drop the dependency of lilo on mbr. I don't want a new mbr eg if I want to install LILO to use on a floppy ONLY (I use GRUB on my HD). Change it to Recommends. mbr being a high priority and/or essential (can't remember if it is) should be enough. Brent This is an area where RedHat has a significant lead over Brent us. One of the guys I work with is a huge RedHat fan Brent because he can just pop a RH CD into the drive, windows Brent will autorun it, and RedHat install starts. It sets up Brent almost everything for the user. If RH has released this code under the GPL, then why don't we borrow it for our use? I know that it's as simple as having an 'autorun' directory on the CD image. IIRC there is an autorun.cfg or similar too. Brent I know we support far more configurations, etc. etc. etc., Brent but for the average Joe New-User this is a large hurdle. I'm sure Enrique is always happy to accept code to do so. :) Just out of interest, how does the autorun bit work? You can't just run loadlin straight from Windoze. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkeys.asc.
Re: (WARNING) xfree86 3.3.2.3a-2 (source all i386) uploaded to master
On Fri, Oct 16, 1998 at 02:02:21PM -0400, Branden Robinson wrote: On Fri, Oct 16, 1998 at 10:25:57AM -0700, Ben Gertzfield wrote: Branden Robinson [EMAIL PROTECTED] writes: W: xext: shlib-without-dependency-information usr/X11R6/lib/modules/xf86Jstk.so I have always gotten this error. I don't know how to fix it, but it doesn't seem to hurt anyone. Well, this isn't a shared library that's going to be linked to, so there should be a way to override lintian's behavior. Oh, I get it. The complaint's not about the file itself, but the absence of mention in a shlibs file. Okay. Well, yeah, that should be overridden. The only thing that uses those modules is the X server. If you ask me, lintian should ignore files like this outside standard library directories (/lib, /usr/lib, /usr/X11R6/lib). They are almost always modules, eg netscape plugins, etc. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkeys.asc.
Re: gdselect alpha 3
On Thu, Oct 15, 1998 at 05:52:59PM -0600, Jason Gunthorpe wrote: Hmm, I think this is my first comment on this.. On Thu, 15 Oct 1998, Tom Lees wrote: On Wed, Oct 14, 1998 at 02:29:04PM -0700, Joey Hess wrote: Are there any plans to merge this with apt? Seems gdselect has the frontend, and apt has the backend. Well, I could do with some apt in-built dependency handling :) There isnt time before the freeze, and AFAIK there are no plans now (which means there are no plans now). I think this idea of 'lets quickly do something fast' is ill concieved and is ultimately going to hurt our image. I've looked at the latest version, it looks rather pretty, it's slightly more functional than dselect but that's about it.. It doesn't support any of the more sophisticated things that people are clamoring for, and it requires X, GTK and a wack of ram. But, it does answer an immediate need... dselect is now too unwieldy to use with the number of packages we have... apt is not ready. Compare it with the package pre-selections in hamm. They were quick and dirty, but they worked, and I believe they helped a lot of users in installation (they were useful last time I used them). The only idea is not lets quickly do something fast. I started playing around with a simple package browser about a month ago... that's where the base came from. Converting it into a fully-blown package selector is what I decided to do. The fact that it doesn't use the APT library only makes things worse as now it could have big bugs in odd places! ^^ Probably does have... but then APT isnt perfect either. I think the point is APT has had much more debugging, this hasn't. I agree, but I needed something to get it up off the ground quickly. It could now almost certainly be ported to libapt very quickly, whereas writing it to libapt in the first place would have been harder, especially considering I already had the basics done a while ago. Only problem is, apt is in C++, this is in C... So compile your code as C++, it's not hard, change the gcc call to g++ and rename the source files. Then you have to fix up a couple casts and some other things and presto, it's C++. You don't need to use gtk-- or anything else like that. Oh. In that case, I will redirect my efforts to this. Everything else is done, and I'm adding more UI features. In alpha3? Quick IRC survey shows that it locked one persons machine hard, takes huge amounts of ram+time and has randomly segfaulted for another... AFAIK, UI features aren't what cause these - its my q+d package lib. The UI features are very quick, IMHO cleanly coded, and I thought them out a lot. I also need to run it through a malloc debugger soon to check out some possible memory leaks/boundary probs. I belive Adam Heath has been investigating porting gdselect to libapt, perhaps you should talk to him. OK, good idea (he's CCd)... Adam, how far have you got? Maybe we should collaborate on this. I believe its probably not much effort to port to libapt - the main problem is the dependency screen bit. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkeys.asc.
Re: gdselect alpha 3
On Fri, Oct 16, 1998 at 09:48:18AM -0400, Peter S Galbraith wrote: Manoj Srivastava wrote: Hi, Michael == Michael Stone [EMAIL PROTECTED] writes: Michael Quoting Jason Gunthorpe ([EMAIL PROTECTED]): I think this idea of 'lets quickly do something fast' is ill concieved an d is ultimately going to hurt our image. I've looked at the latest version, it looks rather pretty, it's slightly more functional than dselect but that's about it.. It doesn't support any of the more sophisticated things that people are clamoring for, and it requires X, GTK and a wack of ram. Michael But it answers the people who think dselect is ugly and Michael unintuitive and want something that runs under X. A quick and dirty answers is not really a good thing, don't you think? Competition is fine, let it get time to mature. The idea is simple: no new code after freeze. let this new system vie with apt at the next release. Since when have we considered scrapping quality just because people want something that ``looks pretty''? manoj If it's rather pretty and slightly more functional than dselect but that's about it... then include it! Please! What I need from dselect is more screen space, more pixels, a less crampled selection environment. It takes forver to navigate through dselect because of the sheer number of packages. It seems that gdselect would help a lot in this respect (I use 1600x1200 on X). So... shall I release it using my pkg code (takes lots of memory, blah, blah, blah, but it works, and its written), or apt's class system? I now think its too silly to try to include it in the slink freeze; I will upload it to unstable after the freeze has happenned. However, making a note of it on the Debian web pages might not be such a bad idea. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkeys.asc.
Re: gdselect alpha 3
On Wed, Oct 14, 1998 at 02:29:04PM -0700, Joey Hess wrote: Are there any plans to merge this with apt? Seems gdselect has the frontend, and apt has the backend. Well, I could do with some apt in-built dependency handling :) There isnt time before the freeze, and AFAIK there are no plans now (which means there are no plans now). Only problem is, apt is in C++, this is in C... ATM, I'm struggling with getting dependencies with virtual packages and or (i.e. a | b | c, d) working (any chance of some help?). Everything else is done, and I'm adding more UI features. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkeys.asc.
gdselect alpha 3
I released alpha 3 to http://www.lpsg.demon.co.uk/gdselect/ today. The next release will have all features present. This is primarily a last testing phase. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkeys.asc.
Re: GTK Dselect - ALPHA 1
On Sun, Oct 04, 1998 at 11:34:55AM -0400, Brian Almeida wrote: On Sun, Oct 04, 1998 at 12:44:36PM +0100, Tom Lees wrote: 1.1. I am using the libgtk1.1 1.1.2-2 and libgtk1.1-dev 1.1.12-2 packages With the default setup: -- Script started on Sun Oct 4 11:30:52 1998 make[1]: Entering directory `/home/balmeida/gdselect/gtk' gcc -g -Wall -Werror -I/home/balmeida/gdselect/include -I/usr/X11R6/include -I/usr/lib/glib/include -c main.c -o main.o gcc -g -Wall -Werror -I/home/balmeida/gdselect/include -I/usr/X11R6/include -I/usr/lib/glib/include -c tree.c -o tree.o cc1: warnings being treated as errors tree.c: In function `populate_tree': tree.c:57: warning: implicit declaration of function `gtk_ctree_remove' Change the gtk_ctree_insert to gtk_ctree_insert_node. Likewise for gtk_ctree_remove to gtk_ctree_remove_node. Reason: I was using gtk 1.1.1, 1.1.2 changed this. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkeys.asc.
gdselect alpha 2
alpha 2 is released at http://www.lpsg.demon.co.uk/gdselect/ -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkeys.asc.
Re: GTK Dselect - ALPHA 1
On Thu, Oct 08, 1998 at 08:55:55PM +0200, Martin Schulze wrote: Tom Lees wrote: Wow, it looks nice. However I wonder why you changed the ordering of the two main windows. Gtk's panels don't size properly by default (i.e. on maximise) otherwise - the list of packages gets tiny, but the description/dependencies far too big. I did have it the other way originally. PS: I also wonder if one may express wishlists. Sure. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkeys.asc.
Re: what's after slink
On Mon, Oct 05, 1998 at 10:06:51AM -0700, Kenneth Scharf wrote: The hitchhikers guide!!! I love it!!! BTW that was Mavin (the paranoid android not the martin). Don't forget Slarty Barfast (I know I spelled that one wrong). And Trillian. And Agrajag. etc. etc. etc. I think this is the best idea!!! -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkeys.asc.
Re: GTK Dselect - ALPHA 1
On Sun, Oct 04, 1998 at 12:14:40AM -0400, Brian Almeida wrote: On Sat, Oct 03, 1998 at 11:41:14PM +0100, Tom Lees wrote: Just a small tar.gz. Not many features are implemented at the moment - notably, it doesnt update the status file, and it doesnt lock the status area, but I'm releasing it for testing of the rest of it. To compile, cd gdselect, and run make. The binary is in gtk/gdselect. One question: the core size is rather large as it stands - is it worth reducing this by using an apt-style cache file in your opinion? (i.e. will people with low-memory, probably less than 24MB, run this?) Tell me what you think of the interface. The buttons at the bottom are meant to change the status. The actual installation is the Install/Apply menu option. Ummm...waht version of GTK+ do we compiel it with? 1.06 or 1.1.*? 1.1. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkeys.asc.
GTK Dselect - ALPHA 1
Just a small tar.gz. Not many features are implemented at the moment - notably, it doesnt update the status file, and it doesnt lock the status area, but I'm releasing it for testing of the rest of it. To compile, cd gdselect, and run make. The binary is in gtk/gdselect. One question: the core size is rather large as it stands - is it worth reducing this by using an apt-style cache file in your opinion? (i.e. will people with low-memory, probably less than 24MB, run this?) Tell me what you think of the interface. The buttons at the bottom are meant to change the status. The actual installation is the Install/Apply menu option. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkeys.asc. gdselect-alpha1.tar.gz Description: GNU Zip compressed data
Libc5 compile machine?
I know there is a machine which I can compile for libc5 on somewhere. a) Where is it? b) Can I have an account on it? I need to compile+upload a new cvs for bo. Please encrypt any passwords, etc., using my PGP key:- Type Bits/KeyIDDate User ID pub 1024/87D4D065 1996/08/26 Tom Lees [EMAIL PROTECTED] Tom Lees [EMAIL PROTECTED] -BEGIN PGP PUBLIC KEY BLOCK- Version: 2.6.3i mQCNAzIhaYYAAAEEALkn2+O0pJeXmKltfRrqE1c3WrKZLO7IPvhEpxXXe4/+GPp1 I84AvoKRZ4EiWJF35a1TI8JQWd4y+cE1alug64woCnh0J2MKnEQg+5Il3iib8f5I H9ygsLK3a9V7X8nG7iNw7tHJ71Z4ZQkhGnbG/jOpRETZMeuSIf152HGH1NBlAAUT tB9Ub20gTGVlcyA8dG9tQGxwc2cuZGVtb24uY28udWs+iQCVAwUQMiFph/152HGH 1NBlAQF+DAQAtV8FljUGroCkWRGUpA1u5S7FNv+it9ZxTzP/3qKdTd6mjT/mu1AU tCq9HbucS4qbJ1i2IPCTkxxTngViJDhrSAym95KRF94As5qIWKskEZTLQXSWc9Hf YlLg1c3dAb7leM1ZN7oUaFtlUrr+Rub7PyNjRJzzIF36R7f8EusThxe0GVRvbSBM ZWVzIDx0b21AZGViaWFuLm9yZz6JAJUDBRAzhK+v/XnYcYfU0GUBASuIBACpJSov S8e9O3ZC1nXtPcEtGQeKCt1oTezzfJSXv5KI5nNbryt5fWGBgN6nrfyhsJuUmHIW IJHjSCLjZDjiL/oUa0KkYqn4BLphUPwn9XYx2IXCijaEsCgJNiU5NgcXiLcYG1ga HX2vMafjCrvgG5kqTpxfC1t/PjqXkK2bUObZfw== =CaUy -END PGP PUBLIC KEY BLOCK- Thanks. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#15484: cvs in bo is still vulnerable
On Sat, Nov 29, 1997 at 10:02:00PM +0100, Martin Schulze wrote: Package: cvs Version: bo version Severity: grave Hmbf, the version of cvs in bo is still vulnerable to the pserver bug. I'm sorry, but at the moment I can't provide a bugtraq or cert message, but there was one. Tom Lees told me: The cvs in bo is vulnerable. The cvs in hamm is not. This hole was fixed in upstream release 1.9.10. If you want a version for bo which is not vulnerable, report it as a bug (add a header Severity: grave). which I'm hereby doing. Can we please have an upload to bo-fixed. This means putting a new version (1.9.10 vs 1.9) into bo. Should I do this? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Hamm: Retracting request for chos to be standard
Erik == Erik B Andersen [EMAIL PROTECTED] writes: Christoph == Christoph Lameter [EMAIL PROTECTED] writes: Christoph Lilo 2.0 has the ability to display a file before the Christoph prompt and also the ability to boot something with a Christoph single keystroke. If someone could update the lilo Christoph package and provide a decent configuration then lilo Christoph could also offer a nice menu on boot up so that newbies Christoph are no longer irritated. I'll have a look at this. Christoph Maybe lilo could also replace syslinux for the Christoph bootdisks?? As someone else already said, this would be a bad idea, since the advantage of syslinux is its DOS support. Erik My wife likes chos because it offers a nice simple and friendly Erik and obvious like Windoze type of menu that lets her use the arrow Erik keys to move a color menu bar onto the (unmentionable OS) selection Erik a press enter. This is very easy, and requires no domestic fighting. Yes, I liked that feature of chos when I looked at it. Erik I took a quick glance at the lilo 2.0 user's manual last night and Erik I wasn't convinced that the message feature was going to be a Erik nice simple and friendly and obvious like Windoze type of replacement. Erik chos is much better than booting Linux using loadlin from a certain Erik unmentionable OS, (which is how I used to not freak out my wife). Erik If the message feature of lilo 2.0 can make lilo as Erik friendly as chos, fine, I will use it. I doubt I will be making a No, it certainly won't do that. :( Erik switch really soon though. How hard would it be to hack bzImage Erik support into chos? That is the only real problem with chos, right? Well, I have pretty specific requirements (which meant I had been using lilo 17 until lately when 20 came out) - I need the feature which can hide one DOS partition when you select another. Erik Are there any other features lacking from it that make it unusable Erik by Debian? I can certainly attest to the fact that this is one Erik piece of software that passes the wife test! I also believe that it can't/won't load its second-stage loader from the second hard drive (i.e. BIOS drive 0x81). This really should be a simple fix, however. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
joost == joost witteveen [EMAIL PROTECTED] writes: On Mon, 23 Jun 1997, joost witteveen wrote: (in fakt so much, that I may be tempted to write it myself. You don't need that many changes). Well, you need to write your own version of make that looks for any attempt to run chmod, chown etc, and then fakes all the ownership and modes in the resulting tar. joost No, what I had in mind is changing chmod, chown and frends, joost and make them log the intended permissions in a file joost (specified somewhere in a environment variable), and then joost changing tar to look for that file (agian in that environment joost variable), and ajust the permissions/ownerships joost in the tar file according to that permissons file. I'm not sure whether it's possible in general even then, what if the package tries to set the ownership of a file from within another shell script or a perl script; how can you intercept that so it works properly? If you really want to do this, LD_PRELOAD=/some/where/debian-perm.so from dpkg-buildpackage. joost Well, if you do it with perl, OK that wouldn't work, but how many joost packages use perl in their build process to set permissions on files? majordomo for one. But we can add a perl module to do it properly, or hack the perl-scripts to work better (or not be used). This is not that difficult for majordomo anyway. joost I'm sure not very many. Actually I think most (97%) packages joost would build joost OK with what I had in mind. With a few minor changes in the way packages are made---having tars all made as any user, and chowns done after the package is installed, either in the postinst or by dpkg first (the former would have the advantage of running on existing systems)---we could build as non-root. joost Well that would be a lot of changes: many postinst's would need to joost be changed. No, the file permissions are set in the tar-file from the list generated from the special versions of chmod. A tar-file can be made as any user, you just need a tar which can understand how to put the right permissions in the tar file. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
Philippe == Philippe Troin [EMAIL PROTECTED] writes: Philippe On Mon, 23 Jun 1997 20:13:13 +0200 Christian Schwarz Philippe ([EMAIL PROTECTED]) wrote: Option 3: We ship .texi files and produce HTML and/or info files on demand (in the postinst script). Philippe I like this idea a lot. I *hate* having to fetch the source package Philippe to produce a postscript output... I add my support for this too, but remember texi2html can be quite slow at processing large texinfo documents, and it doesn't produce any kind of indication that it's doing anything. texinfo, on the other hand, is much faster. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Status of Debian Policy
Rob == Rob Browning [EMAIL PROTECTED] writes: Rob Ricardas Cepas [EMAIL PROTECTED] writes: As of current documentation, you can search only current .html file. This is not very usefull. Lynx ( on non-gzipped docs) is much slower then info ( on gzipped). Rob Oh, right I forgot to add recursive to my previous comment Rob about searching. To revise: any documentation tool that Rob doesn't support incremental, recursive, and regular Rob expression searches is not acceptable IMO. As far as I know, Rob that leaves out most html browsers at the moment. In fact, AFAIK the only browser which supports all these is Emacs/Xemacs w3-mode. Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt. pgpamauuqqxou.pgp Description: PGP signature
Re: Status of Debian Policy
ghughes == ghughes [EMAIL PROTECTED] writes: ghughes [1 text/plain; us-ascii (7bit)] On Jun 22, Bruce Perens ghughes wrote Lynx can browse files directly, and can execute CGI scripts directly. ghughes True. However, it can't handle gzipped pages, and ghughes hacking it to do so seems a) special case (because Ermm... on my system it can. lynx 2.7-1 (self compiled). netscape also handles it very well. I can't say about others because I haven't tried them. ghughes chimera, w3, netscape and all the others still don't) and ghughes b) outside of its domain of relevance. As well, it ghughes (rightly) looks for references of the form ghughes `foo/bar.html', when it would have to look for ghughes `foo/bar.html.gz' and do the unzipping. ghughes In contrast, info browsers have been handling compressed ghughes files for what feels like eternity to this young'un ;-). ghughes You can configure a web server (almost any web server, if ghughes I remember correctly) to dynamically unzip the pages as ghughes they come down the line, however, and this seems more in ghughes line with what one expects a web server to do. If HTML ghughes is to be used in any form, a minimal web server would ghughes also be important, if only for this aspect. Apache apparently also lets you dynamically gzip them down the line. (The browser has to send the right headers tho). ghughes As far as *which* window manager, this is something else ^^ You mean web server? ghughes entirely. WN is nice, but requires slightly nonstandard ghughes update files, and Apache is occasionally too big but ghughes certainly capable (although I have never really ghughes understood this, having run it on every Linux machine ghughes since my 386SX). Lynx without a webserver will work. But for netscape, etc., we should consider adding one. ghughes Boa might be a possibility, if it could be told how to ghughes transfer gzipped files; I have positive experiences with ghughes it, but I don't know whether this is something it can do ghughes by default. -- Graham Hughes [EMAIL PROTECTED] I haven't tried Boa, but NCSA and CERN looked OK to me. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Hamm: Retracting request for chos to be standard
Christoph == Christoph Lameter [EMAIL PROTECTED] writes: Christoph Lilo 2.0 has the ability to display a file before the Christoph prompt and also the ability to boot something with a Christoph single keystroke. If someone could update the lilo Christoph package and provide a decent configuration then lilo Christoph could also offer a nice menu on boot up so that newbies Christoph are no longer irritated. I'll have a look at this. Christoph Maybe lilo could also replace syslinux for the Christoph bootdisks?? As someone else already said, this would be a bad idea, since the advantage of syslinux is its DOS support. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
I found the Xemacs problem!
I installed the new 3.1 binary (not support) package. It still coredumped on me - XFree 3.2-1. Then I upgraded libc5 - 5.4.17-1 to 5.4.23-1. It now works perfectly. I looks like its pretty dependent on a specific version on libc. Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: points on future installation disks development
On 9 Jun 1997, Sven Rudolph wrote: My ideas on boot-floppies' future: - rewrite dinstall in C - reasons: - runtime improvements - don't run fdisk -l that often - todo: make a libsfdisk from sfdisk - more complex datastructures (avoid using sed often) - more complex input masks and consistent user interface - network configuration: everything in one screen Can we add at some point a BOOTP/DHCP option to the network configuration, to do it all automagically? This would be nice. - selecting base directory in one screen - use : - ncurses and libdialog (from FreeBSD), or ncurses may have licensing problems. - slang (ncurses shouldn't be needed then, slang is said to have a curses emulation), or Well, SLang does have a distinct set of programming advantages. However, we'll need a libslang-pic package in this case. Yes, it does have a curses emulation, but it's much better to use it in native mode. - turbovision (licence OK?), or - something else (suggestions welcome) - easier i18n (see below) - new features - installation via serial terminal Hmmm... nice idea. How about installation over a network, i.e. system boots up, BOOTPs (or whatever) for IP info, then SysAdmin can telnet in from a workstation to set it up. - for blind users - for automated testing Impressive. Are we going to do this ever? - use lilo in order to drive the serial line early (or modify syslinux ?) (what about GRUB ?) Modifying SysLinux is a nice option. Although I do have TASM, and so can modify the sources, does anyone know how well NASM (which we have in the distribution, I notice) can handle these files? - an extra command-mode installation ? i.e. SysAdmin sticks a special-custom disk into a workstation, and comes back later, and it is running a fully installed Debian? A lot of people have expressed interest in this. - installing base via ftp and smbfs (and from tape ?) SMBFS is just another FS, easy enough to do. Also, we should add in NCPFS (from NetWare server) there, probably. I had a thought about FTP and - we could use wget. This would also enable us to use HTTP. The version on my system is 88K, but I'm sure this can be reduced if we kick out some of the functionality (like all the intelligent stuff). - mouse support ? (gpm, or derived from gpm) Have a look at kmouse if you want an alternative to gpm. So far, this is looking really good, but it doesn't yet support the variety of mice that gpm does. I have some patches to make it run on 2.1 kernels, which I will be sending to the author pretty soon. However, gpm is only 33K, plus libgpm at 109K (required for both gpm or kmouse) would take up around 140K. - i18n plan - i18n for C files: use GNUish standard method ? (is this gettext ?) Yes, this is gettext. - i18n for shell scripts (swapsetup) (is there a good way for doing this) or rewrite them in C Use the gettext command-line utility. Unfortunately, there seems to be no documentation for it, but it is pretty simple to use. The gettext command-line utility is, however, 17K, which could make it worth rewriting nearly everything in C. - i18n for busybox (is it worth the work and disk space ?) Some of the more major parts of busybox (like ls) may be worth i18n. However, I wouldn't do all of it. - try to keep i18n and localization separated - how many locale data sets will fit on floppy root.bin ? Autodetection of a CD-ROM can happen very early in the boot process, then at least we can put all of the locale data sets in, e.g. /l10n on the CD-ROM. - bigger root.bin for loadlin booting This may be a problem for low-memory systems, though. - for floppies: make extra locale file that can be copied to Rescue Disk Or, seeing as at least one of the floppies is a DOS disk, why not create locale data packs. Each one would have the appropriate locale and translation info for one locale, and this could be copied onto that DOS disk. - assign versions to original and translated text in order to keep them in sync (and automatically find out when they aren't) GetText can pretty much work this out itself, actually. - localization - translate text files Which text files do we actually have ATM? - translations for the i18n'ed parts - minors - better 'make bootable': MBR isn't that self-explaining I think we ought to also at least have the option of not using MBR. I for one don't like it, and use LILO instead. Others I know use OS/2 Boot Manager. We should also have an option to install all the appropriate LoadLin stuff into a DOS partition, and set it up properly. Related topic: I expect to have much less time for Debian for the remainder of this year. So I definitely need help here; especially for the UI part. I will be willing to help. -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger
Re: Some ideas about the text db
On Sun, 8 Jun 1997, David Frey wrote: Hi Tom, Hi. Basically, we first have a /default directory, which every package imports its default settings into. User configuration is put under /config, which means that the system will first look under /config, then /default when a variable is requested. I don't see the advantage of this scheme. Please explain why it is favorable to have 2 configuration trees. If you wan't to have 2 trees, a better and easier approach is to have (standard Unix-way) a $HOME/.config/... and a /etc/config/... tree. OK, a lot of people got confused on this one. I meant user as separate from maintainer of the package. i.e. local sysadmin. The point is so that defaults can easily be changed without affecting locally set-up stuff. But the question is, whether you want to use the configuration database for all and everything (- each user wants his/her own copy) or just for system-related entries (one global /etc/config is enough). I think all and everything, but that's my opinion. Most people seem to think minimalist is better, but even then, a global /etc/config would still benefit from this scheme. The main advantages of all and everything are:- * SysAdmin can install multiple themes, and user may select separately from sysadmin. * User defaults may be updated, but global defaults will also be updated - using .fvwmrc, etc., where it is the global file _OR_ the local file which gets processed will be worked around cleanly. * The database is much more extensible (much like the menu package). IMHO, the config database should extend the system in the same way the menu package does - i.e.:- * It is not compulsory (but probably priority Important) * It is customizable by the user * Still fully backward-compatible - no proprietary code in programs (and more importantly scripts), unless they are special Debian programs, e.g. dpkg (not scripts). -- Tom Lees [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On 7 Jun 1997, Kai Henningsen wrote: Or maybe you have forgotten how conffiles are actually handled: (old=original install, new=this install, current=possibly edited version) If old md5 = new md5, ignore new file (package unchanged) If old md5 = current md5, install new file (conffile was not edited) otherwise, prompt (both changed) Your change would mean that in case 2, dpkg would have to figure out how to put the variables from the old script into the new one. OK. I didn't make this clear. The point of the config-tool is to do this. The file is not modified locally per s.e., just written locally in a different way to the packaged version, because the config db is changed. To clear it up: for a script which holds values which are really housed in the configuration database, each line which is simply a copy of config db information has a special key on it (# nomd5sum or something) which tells dpkg not to include that line in its config-file md5sum. The config db tool has the job of updating the values on demand, from the config database, replacing the values in the script. Therefore, when a file gets upgraded, even if it is replaced with standard defaults from the package, the postinst calls the config tool telling it to copy the appropriate values into the file. We could have something like this in the postinst:- if [ -f /sbin/debian-configtool ]; then debian-configtool --import /default - --update-file /etc/my.script EOF mypkg/some_info=yes EOF fi Then /etc/my.script looks like:- #!/bin/sh SOME_VARIABLE=yes # configtool=yes (See my post to debian-admintool about the significance of /default). The point of making dpkg ignore config-tool lines is that they are not supposed to be modified separately from the config database locally. No, it doesn't. You forget that there are three md5 sums / file versions involved, not two - *even though you quote me explaining it*! Well, I already wrote a simple system that works like this in perl - and a modified version of md5sum which can do this. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On 30 May 1997, Kai Henningsen wrote: [EMAIL PROTECTED] (Tom Lees) wrote on 27.05.97 in [EMAIL PROTECTED]: There are ways to avoid this. For example, modify dpkg not to include any line with config=yes in it in the md5sum of certain files. This is a troll, right? Wrong. Or maybe you have forgotten how conffiles are actually handled: (old=original install, new=this install, current=possibly edited version) If old md5 = new md5, ignore new file (package unchanged) If old md5 = current md5, install new file (conffile was not edited) otherwise, prompt (both changed) Your change would mean that in case 2, dpkg would have to figure out how to put the variables from the old script into the new one. But, for a package which adds config info, the new md5 != the old md5. Therefore, it would ask! And for a package where old includes config lines, the pkgtool would be rerun to update info which was config=yes. Locally modified lines wouldn't be config=yes, so the md5 would be different. Therefore, unless the sysadmin forgets to modify config=yes (put a banner to remind them), it works. So:- non-cfgtool md5 != cfgtoolized md5: old md5 != new md5. local file not modified: update anyway to use new cfgtool version. local file modified: cfgtool md5 == cfgtool md5: old md5=new md5 local file not modified (enough) - install new THEN, update from cfg database. See, it does work. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: GOAL: Consistent Keyboard Configuration
On Mon, 26 May 1997, Christian Schwarz wrote: On Mon, 26 May 1997, Jim Pick wrote: I agree 100% with what Ian says. (Let's do it) Me too! (I didn't know that such a simple solution is possible :-) So what about the other keys? I suggest that all character keys, symbols, etc. should produce the character that's printed on the key (this sounds reasonable, doesn't it :-) Then I have a special ALT key on my german kbd, that's label Alt Gr. In DOS/Win95 it behaves like pressing Ctrl-Alt together. It's useful to get some alt-alt keys (for example, I have =, 0, and, } on one key). I think the behaviour should be the same in Debian. Yep. We need to make sure that the AltGr key on most European keyboards does something (and even on UK keyboards... it produces a IBM line-drawing char IIRC). This involves adding a modifier to the keymap (at least for std console). Other keys: - End: Should jump to the end of the line/document, depending on where it's used, for example, jumps to end of line in readline, but end of document in less. Ok? - Home: Opposite of End. Fine What about the second cursor block at the right? It would be nice if one could switch between the function keys (left, right, etc.) and the digits (0, 1, etc.) with the Num Lock key. Is this possible? (The current behaviour is to produce digits all the time, no matter if Num Lock is set.) This works at the console (with uk.map). Then I have a Print key, Scroll-Lock, and Pause. All three keys don't have an effect in my X configuration--on the console Scroll-Lock starts/stops terminal output, just like C-S and C-Q. Is there any useful meaning for Print and Pause in Linux? Ctrl+Pause (=Break) should do one of those kernel dumps IMHO. Or produce SIGINT, whatever... Does someone have any other special keys on his keyboard that we should define? (We'll just do it if the keyboard layout is widely used.) Ctrl+PrintScreen (=SysRq) should do a kernel info thing. What about W95 keys (3 of them)? Define as F20 or something? -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: packages.debian.org qmail (was Re: Using CVS for package development)
On Fri, 30 May 1997, Philip Hands wrote: What were you trying to achieve ? --- it might be simpler than you think. I just discovered that most of my alias handling under qmail was drivel, and could be dome much more simply. If someone wants to spend some time on a simple mailer hack, you can make this work. If you want mail to, for instance: [EMAIL PROTECTED] IIRC you can also alias an entire domain (packages.debian.org) to one user (how lists.debian.org is currently done). So [EMAIL PROTECTED] gets translated to, say bruce-packages-rsync. Then, ~bruce/.qmail-packages will execute a script to process it, or you can have .qmail-packages files for each pkg if you are worried about speed. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Where is the mysql package?
On Mon, 26 May 1997 [EMAIL PROTECTED] wrote: Yep. How about a verbose mode that tells you when you connect, or if it cant, says so, and then when its done, prints xxx bytes downloaded in yyy seconds, at foo kb/s. something like: $ snarf -v http://linuxos.org/index.html connected to linuxos.org:80 getting file... got 63K in 45 seconds at 1.4K/s $ So how about it, huh? =) Snarf is one cool proggie. wget can do this. It sounds like snarf is similar to this. Sample output:- debian:~$ wget -v http://localhost/debian.html --11:59:33-- http://localhost:80/debian.html = `debian.html' Connecting to localhost:80... connected! HTTP request sent, fetching headers... done. Length: 2,778 [text/html] 0K - .. 11:59:34 (452.15 KB/s) - `debian.html' saved [2778/2778] -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: kernel header files : problems (yes, again)
On Wed, 28 May 1997, Andreas Jellinghaus wrote: also get this directory. but only linux/ and asm/ shoud override /usr/include, not net/ (because : net/ is buggy !). what shall i do ? ok, i know how to fix this, but with the next libc or kernel header update i will have to fix it again... any good solution ? Put something like this in debian/rules:- mkdir kinclude ln -s /usr/src/linux/include/linux kinclude/linux ln -s /usr/src/linux/include/asm kinclude/asm Then compile with -Ikinclude -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Policy for arch specs
On Thu, 29 May 1997, Christian Schwarz wrote: Hi folks! As I'm working on a new Policy I'm handling the request to include a policy for correct architecture spec strings. However, I've discovered _several_ threads here on debian-devel without any (obvious) results. Is it correct, that we are currently working on ports to the following platforms (the abbrevs should be the ones that dpkg is using in the file names): i386 alpha arm m68k powerpc sparc Are these correct (i.e. not ppc) and is this list complete? Next step: GNU's configure utility. I thought that we had agreed on using i386-unknown-linux (and similar for the other architectures), but then I had just discovered that GCC uses /usr/lib/gcc-lib/i486-linux/2.7.2.1/ ^^ (first it says i486 instead of i386, second it ommits the unknown). No, i486-linux is the alias we should use. Latest configure tools will convert this to i486-pc-linux-gnu! But, all programs should install using the alias, not the full name. Dpkg calls it i386, but the autoconf string should be i486. In general, the alias given to configure should be xxx-linux. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking over e2fsprogs ?
On Wed, 28 May 1997, Yann Dirson wrote: Has anybody postulated to take over maintainance of the package ? If not, I'm a volunteer... Please let me know. If you do take it, please try to get the e2compr patches into it. I have requested that I take it to do this work on it. However, e2compr-ised patches are only available against 1.06 - they will need some converting. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dcfgtool and clones
On Mon, 26 May 1997, David Frey wrote:
Hello everybody,
On Sat, May 24 1997 11:40 +0200 Andreas Jellinghaus writes:
there are three tools : cfgtool (lars wirzenius), nod (winfried
truemper), dcfgtool (mine). and someone is working on a _real_ tool (all
three have flaws, and if this way we will get a tool with all good
features).
With somebody, you meant eventually me, since I asked at the Linux-Kongress
in Wuerzbuerg whether I may upload a dcfgtool clone.
But whether it's a ``real'' tool, is not so sure... . Don't hold your breath.
as you can see, it's a small text database. so it has nothing, absolutly
nothing to do with deity - that's a GUI.
agreed.
We are planning on expanding the scope of deity to include a few more
features than just a GUI after the initial release though. Including
getting a decent library set together for other developers to use. Making
the config-tool part of this would seem pretty logical.
then we should :
a) choose _one_ cfgtool (the current one have big flaws. the new one
will not have them).
b) change policy to _not_ allow config information in /etc scripts
I really don't like this, and I think several others don't either.
c) change policy to _not_ allow additional debian uniq config files to
fix b). only the textdb should be used.
Definitely. But we have to remain backwards-compatible, so we must be able
to *read*, e.g. /etc/mailname, to be able to convert to the db.
d) think about getting rid of some config files only used by shell
scripts, and use the textdb instead.
yes.
Lars Wirzenius [EMAIL PROTECTED] said:
Assuming the syntax is simple, and there's no need for complexity, a
hand-written parser can be lightning fast, and all the time is spent
in starting the program, and reading the file.
Mine is currently a lex parser and a yacc scanner.
Do you do any hashing? I usually use gperf to generate a hashing function
for the main keywords. This really does give some nice speed improvements.
However, if the format is even simpler than this (no keywords, just
variable assignments, and comments), it would be faster to use a yacc
parser, and write your own (simpler) lexer. The regular-expression
capability of lex does hit the performance slightly unless you really need
it. GNU flex doesn't suffer from this problem nearly as much as the
original lex did, though - it was severely slow.
Tom Lees [EMAIL PROTECTED] said:
I know all this. But when will it be finished? What about beta
versions? Is there a mailing list (other than debian-admintool)?
Finished in about a week (beta version).
Great! Are you planning on uploading it to experimental or unstable? I
would suggest you upload it to experimental, as it has the possibility to
severely corrupt people's systems. OTOH, you could also put it in your
home on master, as a pre-beta to check if everyone likes it.
Mailing list other than debian-admintool: no
Maybe we should start *using* debian-admintool then :)
Tom Lees [EMAIL PROTECTED] said:
It would be really cool if we upgraded the packaging system to handle
configuration integrally (so we can do configuration _BEFORE_ an
installation, etc.).
Yes. But the tricky part is how to rewrite all the /etc/hosts, /etc/networks,
/etc/uucp/{sys,dial,port,config}, /etc/fstab, /etc/slip.dip etc. files.
I don't have an idea.
How about we do it like apache does its modules? (This might get tricky,
as I'm not sure all developers can program). So the config tool loads all
the modules (using libdl), and then it can use special functions in these
modules to handle these file-formats. OTOH, there aren't that many files
with non-generic syntax... maybe we could simply include separate parsers
for each of these.
Deity definitely _IS_ the right place for this -
a GUI to do the configuration with, at the same time as packaging
control!
I'd prefer a back-end and deity would be the frontend.
The way I envisaged it was that Deity would get all the configuration
info, and then pass it on to the back-end after it had all the info.
I think the cfgtool should probably be available as a shared lib so that
deity can also read stuff etc., without too much of a slowdown from
execing another prog.
Jason Gunthorpe [EMAIL PROTECTED] said:
To allow a GUI to present a usefull view of the config file
information about each field would have to be known. A short
description, it's content type, possible range information, etc.
You can store a comment (a la dcfgtool), but the other things are not here.
dtxtdb knows about booleans, ints, floats and strings. That's it.
I suggest another two types (although they are really special cases) - IP
address, and FQDN. The regular expressions to handle these really are too
long for something that will be in common use.
My one (in perl) can handle perl expressions to validate types... and IIRC
there is a libperl you can link with to do this. OTOH, we could use GNU
Re: Unresolved Critical Bugs
On 27 May 1997, Sven Rudolph wrote: Christian Schwarz [EMAIL PROTECTED] writes: Anyways, e2fsprogs seams to have a lot of open bugs. Is this package actively maintained? Probably not. Last maintainer is Michael Nonweiler [EMAIL PROTECTED], but he is looking for a new maintainer for e2fsprogs. Seeing as I am maintaining e2compr, I'll take it, and merge the packages as appropriate. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: time stops on latest kernels
On 27 May 1997, Rob Browning wrote: Is anyone else running the latest unstable kernels on a uniprocessor? I have noticed that with many of the recent kernels (including 2.1.40), time appears to be stopped. With these kernels, on my machine clock never returns anything but zero, and things like procmeter never register anything for cpu usage. I know that 2.1.26 doesn't have this problem, but I'm not sure where it was introduced. I have a suspicion that it's related to the new multiprocessor code... I'm running:- Linux debian 2.1.36 #56 Sat Apr 26 15:44:22 BST 1997 i486 unknown And everything is working... -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
On Thu, 29 May 1997, Paul Bame wrote: = Should this CVS repository be mandatory, i.e. does every Debian = package have to be there? A brief word of warning... (I tried CVS on dpkg a while back) The natural CVS model is to name the directory for the package, for example .../dpkg/ and relegate the version numbers to tags. At least one package (dpkg) uses its directory name in such a way that when the directory is .../dpkg/ the build fails, while it works when the directory is a versioned one, .../dpkg-1.2.3/. This has been fixed now, since 1.4.0.9 (it was in my original automakizing patch, it now using the debian changelog to determine version). -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On Sun, 25 May 1997, Mark Baker wrote: In article [EMAIL PROTECTED], Tom Lees [EMAIL PROTECTED] writes: the other solution is to have a small utility that stores these values, can change them and gives the values to the scripts. The third solution, which I prefer is a utility which modifies the variables within the scripts - it's faster, it is more backwards compatible with sysadmins from other Unices, and generally it's nicer (less dependant on the cfgtool at boot-time). And if you're not very careful it does silly things if the scripts have been modified significantly. So you do something like:- BLAH=something # configtool=yes Then, if someone modifies the scripts, they make sure that that particular line is still there, or remove the configtool=yes if they don't want it. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On Sun, 25 May 1997, Christian Hudon wrote: --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii On May 24, Tom Lees wrote The third solution, which I prefer is a utility which modifies the variables within the scripts - it's faster, it is more backwards compatible with sysadmins from other Unices, and generally it's nicer (less dependant on the cfgtool at boot-time). And it changes the conffiles, which means that the user will still get bugged with Conffile changed, overwrite with package's version or keeps yours? questions from dpkg, which is exactly what we want to avoid with cfgtool. There are ways to avoid this. For example, modify dpkg not to include any line with config=yes in it in the md5sum of certain files. So, for example:- #!/bin/sh # the blah script some code BLAH=yes# config=yes If this becomes:- #!/bin/sh # the blah script some code BLAH=no # config=yes It still gets excluded from the md5sum, but if someone changes it, like:- #!/bin/sh # the blah script some code BLAH=no Then dpkg gets a different md5sum, and prompts, because it is included this time. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: runlevels [was Re: Upcoming Debian Releases]
On 23 May 1997, Milan Zamazal wrote: I know nothing about runlevel standards, just my opinions: Same here. AK == Alexander Koch [EMAIL PROTECTED] writes: AK: level 1 is without net, 2 is with it all (imo including nfs AK: and the like) and 3 is xdm, 6 was shutdown or halt or AK: whatsoever. at least that i remember from some german AK: distribution. I'm no big sysadmin but I think we can use all 1 to 4 levels. One free runlevel could be enough (in actually, if *I* need some modifications, I make them by modifying existing runlevels not creating new ones). AK: default runlevel is 2 so why should nfs start with 3? I'd like something similar to: 1: single user 2: multiuser with minimal networking, probably without offering services 3: full networking (NFS, xfs, anonymous ftp, ...) 4: xdm? (yes, it is common on Slackware and RedHat to start xdm according to runlevel, but maybe Debian /etc/X11/config concept is better) No, we don't need xdm in runlevel 4. A better solution would be this (but it is more difficult, requires multiple inetd.conf files):- 2: multiuser, minimal networking, no networking daemons (including inetd). 3: multiuser, client networking (rpc.ugidd, ident, etc.) 4: multiuser, server networking (ftp, http, finger, etc.) 5: empty for making special local runlevel? Yes, good idea. So if I want to do something without being too used from outer world, I can switch to level 2 (and I can still telnet or ftp somewhere). AK: if 3 gets xdm, perhaps gpm should be disabled and the like? Remark: gpm should be disabled only when it doesn't work as a repeater. It doesn't need to be disabled, it just saves memory. It will detect when X starts up, and give up its own handling of the mouse. Only PS/2 mouse devices used cause a major problem with this (single-open only), but they don't do that any more IIRC. BTW, I don't like RedHat concept of empty level *4*. When I upgraded HW on some RedHat machine, I lowered default level from 5 to 4 in expection it will disable just xdm. Then I spent an hour looking for explanation, why many services don't start after changing HW. After I explored runlevel 4 was empty, I was far from being polite... Agreed. I think a better way than doing runlevels directly in packages, though, may be to set a package startup script's type - minnet, netclient, netserver, misc, etc. Then, define runlevels to include certain types of script. Just an idea (very difficult to implement with symlinks for /etc/rc?.d), what does anyone else think? -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On Sat, 24 May 1997, Andreas Jellinghaus wrote: - Move config information from install scripts to cfgtool (???) I'm having a look at ways of doing this. It would be really cool to integrate this into deity. there are three tools : cfgtool (lars wirzenius), nod (winfried truemper), dcfgtool (mine). and someone is working on a _real_ tool (all three have flaws, and if this way we will get a tool with all good features). I know all this. But when will it be finished? What about beta versions? Is there a mailing list (other than debian-admintool)? what they do : currently many scripts in /etc hold config values. this is a bad thing. one solution is to write these variables in other text files, and use the source command in the shell script to read them. this is not a good way IMO. the other solution is to have a small utility that stores these values, can change them and gives the values to the scripts. The third solution, which I prefer is a utility which modifies the variables within the scripts - it's faster, it is more backwards compatible with sysadmins from other Unices, and generally it's nicer (less dependant on the cfgtool at boot-time). as you can see, it's a small text database. so it has nothing, absolutly nothing to do with deity - that's a GUI. OK, I should refrase what I wrote. It would be really cool if we upgraded the packaging system to handle configuration integrally (so we can do configuration _BEFORE_ an installation, etc.). Deity definitely _IS_ the right place for this - a GUI to do the configuration with, at the same time as packaging control! i will wait till the new tool is released, than we can remove all other tools (at least my will get removed - there is no reason to keep it.) I wrote a perl script to do this (mainly as an exercise in perl, which I am learning). If anyone wants it, I could happily package and upload it into experimental. then we should : a) choose _one_ cfgtool (the current one have big flaws. the new one will not have them). b) change policy to _not_ allow config information in /etc scripts c) change policy to _not_ allow additional debian uniq config files to fix b). only the textdb should be used. d) think about getting rid of some config files only used by shell scripts, and use the textdb instead. Footnotes 1, 4, 5, and 7 can be removed AFAIK. what about footnote 10 (cu* devices) ? debian 1.3 has no call out devices ! (*evil grin*) True, this has been done in the package, but not everyone may have removed their /dev/cua* files from previous installations. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On Mon, 19 May 1997, Brian C. White wrote:
Hamm
I think its been agreed that this will be called Debian 2.0, so why not
add this here.
* All packages are in the new package format.
Possibly a new source package format may be created, so we should resolve
this before putting too much effort into converting twice.
* All base packages are compiled with libc6.
Should be all pkgs in the main distrib really.
* Fix packages currently depending on 'libc5-dev'.
* Officially supports {i386,m68k,alpha,sparc} architectures (mips,ppc?).
* No more dependencies on obsolete virtual packages (X11R6, elf-x11r6libs,
...).
* No a.out executables anymore.
* Much improved dpkg/dselect.
- Move config information from install scripts to cfgtool (???)
I'm having a look at ways of doing this. It would be really cool to
integrate this into deity.
- Some sort of package-grouping mechanism for dselect
- New run-level layout (???) [12]
- No bug reports older than 9 months at release time
And another one:-
* Official Debian logo to be chosen
Footnotes 1, 4, 5, and 7 can be removed AFAIK.
--
Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/
PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6
finger [EMAIL PROTECTED] for full public key (also available on keyservers)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
On Mon, 19 May 1997, Christoph Lameter wrote: Anybody should know that before typing rm -rf * or an equivolent, you THINK FIRST, every time. The problem does not arise when you type rm the first time but after you have some confidence and you think you know what you are doing. Everybody knows what you should think first. But who does after getting used to it? Generally, after installing any system, I add this to ~/.profile for root:- alias rm=/bin/rm -i This pretty much stops me from doing anything stupid - especially by a typo, like mistyping rm /etc/*~ as rm /etc/*... I did that once :(. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 migration -- xlib
On Mon, 19 May 1997, Mark W. Eichin wrote: Is there a web page or other document that explains what our strategy for libc6 is? I'm not talking about random comments on the list, I mean something nailed down that I can refer to... In particular, I've got a few issues to work out. 1) libgdbm -- libc6 includes libdb, and therefore gdbm is supposed to be unnecessary. If this is true, it needs to be written down, so I can point people at it -- otherwise, I need a strategy for renaming the package (since there needs to be a libgdbm.so for libc5 and a seperate one for libc6... the former isn't changing, obviously; how do we change the latter so that -lgdbm still works for users building against it? [since db can't read gdbm files, that *will* continue to happen.]) The general policy is that libc5 stuff should go in /usr/i486-linuxlibc1/lib. So that's where you put all the stuff compiled against libc5. 2) X -- a full release of X requires tk41-dev to build XF86Setup (it uses the static lib, so the end-user doesn't need it.) But tk41-dev probably won't be available for libc6 until I release X. Ooops :-) I can hand-release xlib6-dev by itself, (into experimental, perhaps?) so that someone can build the tk packages... or I can build that particular lib by hand until then (but then would still have to leave X in experimental unless I took over the package, eww.) And what *do* I name things? I'd guess that xlib6 is untouched, the version built with libc6 gets called xlib6-libc6 (eww), I release an No. xlib6 should be for libc6 (more long-term solution). Then create an xlib6-libc5. How we handle the dependencies for this, I don't know. Fix for all packages which require libc5 still, and recompile those which can work with libc6 would be the best idea. alt-xlib6-dev that replaces and provides xlib6-dev (which alt-libc5 doesn't?) and then xlib6-dev can be the new version? Am I missing anything? No, alt-xlib6-dev should _NOT_ conflict/replace/provide xlib6-dev. It should install into /usr/i486-linuxlibc1/..., or something (maybe /usr/X11R6/i486-linuxlibc1), and it should co-exist with xlib6-dev. ld.so can work out which to use. 3) can I drop the a.out-only dlltools package now? :-) No. It is needed to build a.out versions of, e.g. svgalib. Some older binary-only programs only come in a.out format (Doom, for example) :(. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Problems with the current source packaging scheme
On Mon, 12 May 1997, Lars Wirzenius wrote: At least the following have been pointed out as problems with the current (source) packaging scheme. I'm not commenting on what the proper solution to each problem is, and I wish no-one else would, either, just so that we could, for once, avoid the Debian-typical design-by-mail-flood. :) I _do_ ask everyone to add things to the list (via private mail to me -- I'll summarize -- or on this list). Or point out non-problems, of course. * .orig.tar.gz gets separated from .dsc and .diff.gz, and may get lost * upstream sources not preserved bit-for-bit; need to be repackage, which can destroy upstream digital signatures, and makes it more difficult to check that .orig.tar.gz and upstream sources are the same * no automated way to check .orig.tar.gz files against upstream distribution (located on well known web sites), or upstream digital signature, if any * no way to automatically retrieve the upstream source package, or its updates OK, similar to these three - no option to retrieve the upstream source from a closer mirror (or CD-ROM!). For example, I have a *very* local mirror of the GNU sources, and a couple of CD-ROMS of them, so it would be handy if I could download everything else. * no dependencies for source packages I'd like to add here that we need two types of dependencies - on *source* packages, and on *binary* packages. And some others:- * No dpkg-ftp/dselect type thing for getting/installing sources * No standard location to install sources (/usr/src structure should probably be made policy) * No provision for building multiple binary packages from one source installation easily (i.e. VPATH builds). An example of this is, say I have the binutils source in /usr/src/debian/binutils-2.8, and I want to build binutils for m68k in ~/binutils-m68k, and for i486 in ~/binutils-i386. This is currently possible for the configure script and the upstream Makefiles for the most part, just not for the debian bits and pieces. * No easy provision for an essentially binary-only package, e.g. quake, where upstream source aren't provided - the source pkg is almost identical to the binary pkg - they should be in the same package probably. Another example - in my file-rc package, the debian/rules file does not do *anything* for build, and for binary, just copies stuff into the right place. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dpkg verify mode for security?
On Thu, 15 May 1997, Chris Fearnley wrote: 'Amos Shapira wrote:' I was asking over Linux-ISP about doing cleanup after breakins and got many use tripwire answers, and one which says that RPM has a verify mode which checks for files which were changed since they were installed. Can the dpkg maintainers consider adding such a feature for Debian? What does the rpm verify give you? As far as I can tell it gives a false sense of security. Nothing more. The rpm database is easily hacked once root access is attained. Tripwire or something similar is the only viable option. If the maintainers PGP-sign the verification data, they should be OK (providing that you keep your PGP keyring on read-only media, like a Debian CD-ROM). I'm presuming the best way to go is to have PGP-signed md5sums. Another alternative is to keep a copy of the md5sums on read-only media (CD-ROM springs to mind), and check against that. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Pbs with locale and fonts
On Wed, 14 May 1997, Mathieu Guillaume wrote: I've encountered two little problems in hamm. First one shows while using dselect. I have the following message several times: [perl i18n stuff removed] Basically, you need to set LC_ALL, as well/instead of LANG. Second thing is the fonts: [15:39:24] root /usr/bin/setfont lat1-16.psf Bad input file size From what I could see, setfont and the fonts I use come from the same package (or were updated at the same time) since they have the same date. Too bad they don't seem to be compatible... No idea on that one. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: compiling with gettext
On Wed, 14 May 1997, Susan G. Kleinmann wrote: Yesterday I reported that I was no longer able to compile the package 'sp'. Santiago Vila and Tom Lees both kindly offered suggestions, but both of these still leave sp in an uncompilable state. Santiago pointed out that the problem might be intrinsic to the existing gettext-0.26, and suggested I wait til gettext-0.28 becomes available. This might be a very long time, since gettext-0.26 came out in December. Tom pointed out that my include line: #include /usr/share/gettext/intl/libgettext.h referred to libc6 headers, which must surely have caused a problem since No, that is the GNU gettext generic header, that is right. What I said was, you were trying to link against libc6 but you compiled against libc5. I was linking with libc5. So I changed this to #include /usr/include/libintl.h. But this produces the same result as if I had no include line at all: You need to make sure you are linking the libintl.h file into the right directory, and including the right file (-I../intl, etc.). ../lib/libsp.a(MessageTable.o): In function `GettextMessageTable::GettextMessageTable(void)': MessageTable.o(.text+0x35): undefined reference to `bindtextdomain' ../lib/libsp.a(MessageTable.o): In function `GettextMessageTable::getText(MessageFragment const , Stringchar ) const': MessageTable.o(.text+0x69): undefined reference to `dgettext' Also, you need to link with -l../intl/intl.a. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
On 12 May 1997, Manoj Srivastava wrote:
say that if the source is well behaved (that is, it is a tar file
that unpacks into *some* directory other than ., compressed or
Kai You seem to think a tar that unpacks into . is a problem. I
Kai still fail to see why.
Kai Just unpack into a temporary subdirectory.
I was just thinking of the problem of determining which case
it was ...
Suppose I hace A.tar.gz and B.tar.gz, and I need to apply a
diff to them to get the debianised source. In each case, I unpack
into ./temp.
Case 1: I get ./temp/A/{1,2,3}, in the second case I get
./temp/{4,5}. In case 1 I should cd into ./temp/A before applying
the diff, in the second case I have to cd into ./temp and apply the
patch.
At first glance, it may be difficult to determine whether
currently we are facing case one or two.
There may be an easy solution that is not obvious to me.
Write our own safe scripting language. Not difficult, and really rather
useful. So, eg:-
Unpack A.tar.gz in /A
Patch A.diff in /A
Unpack B.tar.gz in /
Patch B.diff in /
This would be very nice IMHO.
--
Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/
PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6
finger [EMAIL PROTECTED] for full public key (also available on keyservers)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: compiling with gettext
On Tue, 13 May 1997, Susan G. Kleinmann wrote: I have been trying for some time to solve Bug #8882 against the 'sp' package, which says that in order to make it buildable under glibc, I need to call libintl as well as libnls in order to accommodate glibc, and to define LINUX_TYPES_H for glibc. I made those changes and could no longer get the program to compile. After a while I realized that the changes were unrelated to my inability to compile the program; which I tested by going back to the original sources and trying recompilation without the fixes. Sure enough, I got the same error messages: 1. First there's a complaint about an undefined dgettext in lib/MessageTable.cxx. I think I bludgeoned this one by inserting the line #include /usr/share/gettext/intl/libgettext.h in the top of that file. This means you compiled with libc6 headers but didn't link with libc6. Linking with libc6 will fix the above, and fully gettextizing the sources will fix it for libc5. 2. When I then recompile the program I get the message: MessageTable.cxx:102: parse error before `const' MessageTable.cxx:103: parse error before `const' MessageTable.cxx:104: parse error before `while' MessageTable.cxx:105: parse error before `while' where the four lines in question are: extern char *dgettext(const char *, const char *); extern char *gettext(const char *); extern char *textdomain(const char *); extern char *bindtextdomain(const char *, const char *); The problem is that gettext, etc., are being recognized by the preprocessor! You don't need these, you should #include the appropriate libintl.h instead. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
On Sun, 11 May 1997, Joey Hess wrote: Lars Wirzenius: They might not understand enough about shell scripts (or Perl, or whatever the script is written in) and whatever tools the script uses to make an informed decision of whether the script is safe. With the current scheme, they only have to trust gzip, tar, patch, and chmod, And all of debian/rules. And debmake or anoy other programs called by it. They are planning on building this package, right? IMHO this is where we ought to be looking to improve our source packaging system. At least we should allow building as a non-root user as soon as possible (using the new GNU tar). -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug system `followup' messages
On 12 May 1997, Manoj Srivastava wrote: Hi, I think, from the volume of discussion on bugs-dist, that most developers have signed up on that list (and I at least follow it quite diligently). I would rather not clutter up debian-devel with that traffic (if we send all reports to debian-devel, please arrange to have the debian-bugs* list stopped, since they will be largely useless). I agree. However, I have cut back on following debian-bugs-dist, as I don't have the time at the moment, and I consider debian-devel more important. I suspect other people may do this as well. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
On Sun, 11 May 1997, Joey Hess wrote: Kai Henningsen: Remember: no shell scripts in the source packages that are needed for unpacking. It's just too dangerous. I don't understand why this is more dangerous than debian/rules. Why? You don't get to review it before it's run. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Sending closed bug notices to interested parties.
On Sun, 11 May 1997, Chris Walker wrote: Further to the announcement from Ian Jackson about the creation of a mailing list for closed bugs There may be circumstances when I wish to know if a bug has been closed, but am not the person who reported the bug (eg I want to know when the CVS/inetd.conf bug is fixed so I can feel safe upgrading). Bad example. Upgrading is what causes that bug to happen :( Would some mechanism of saying when this bug is closed notify me as well eg by sending a specially formulated e-mail, or perhaps some web interface. This might be useful, as in general I probably don't want to see all bug report closures. Maybe a watch feature, where you can tell the bug system what you want to see about a bug report (if you have ever used CVS watches, you will know what I'm talking about). -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#8794: wrong arch declaration in dpkg.
On Sun, 11 May 1997, Ian Jackson wrote: The good definition of powerpc processors is 'powerpc', not 'ppc'. Was this issue settled ? This will be hard to change later, so it's important to get it right quickly. I believe it was. --- archtable Thu Feb 27 21:53:23 1997 +++ archtable.new Wed Apr 16 16:22:49 1997 @@ -21,4 +21,4 @@ alpha alpha alpha m68k m68km68k armarm arm -ppcppc ppc +powerpcpowerpc powerpc This is already in dpkg 1.4.0.15. But it should also have:- ppc powerpc powerpc -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
On Sun, 11 May 1997, Jim Pick wrote: You might want to unpack a source package for other reasons than to build it -- e.g., I've sometimes searched for documentation. A non-programmer might want to do this so that they can typeset the documentation in LaTeX, instead of printing out the LaTeX2HTML'd version. The srcpostinst thing was just a trial baloon - I don't think it went over very well. So I'll drop that idea. But if we go with a source package file format that is the same basic thing as what a .deb file is, we can always add it later (if needed). I think it's better to unpack the upstream sources in the debian/rules makefile anyways (using any tool available on the system). I'd oppose having a specialized script file for unpacking them, since it's unnecessary -- you can already do that from the debian/rules makefile. This would be better - someone can overlook the debian/rules file first. As I said before, I'm quite interested in having a source package that automatically unpacks the upstream sources and patches itself for the purposes of debugging -- and also can be set to automatically build too. This is the equivalent of a make world. But nobody's This would be difficult. I always thought that make world was simpler than this, though - what does is do exactly? (I haven't used any of the *BSD distributions). saying that the system administrator can't have the option of just installing the source, without running any scripts. This should probably be the default behaviour. Maybe we should limit our support to only certain formats instead of needing scripts to unpack it - the dpkg end of this could get messy with pipes or temp. files. I propose we support zip and the various tar formats only. Before I was advocating the use of a separate sdpkg program to install source packages, but it could probably be done with just dpkg. ie. dpkg -i jdk_1.0.2-7.sdeb Since the extension is .sdeb, dpkg would know that it was a source package, and just put it in the appropriate place. Maybe /var/lib/dpkg/source/jdk_1.0.2-7 possibly? Since the package has dependencies (to .upsdeb's for upstream source, and .deb's for binaries needed to build it), those would also need to be installed too. This should probably be /usr/src/debian. Then we could have a nice set of Makefiles installed to let us do a make world style system. (If I understand make world properly). -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#9242: dpkg: dpkg could be smart about Changes information
On Sun, 11 May 1997, Ian Jackson wrote: It would be useful if the kind of information sent to the debian-changes mailing list were integrated into dpkg. For available updated packages, a user could use information about the number and Urgency: of each intervening update. Also useful would be access to the developer's comments on each upgrade. I can see why this would be useful. However, there is the problem of transferring all of this data to the user's system. The more information we try to provide the user with the more they will have to download for each package that they choose not to install or upgrade. In this particular case, I'm unconvinced that supplying the user with the whole change history of a package is a reasonable thing to attempt. IMHO, a parser for the Last week's uploads into i386 files regularly posted to debian-(devel-)changes would be ideal. Then you create another mailing list to house these announcements only, and make dpkg remove the old info when the package is upgraded. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
On Sun, 11 May 1997, Jim Pick wrote: The point I was trying to make was that having dependencies on binary packages would be really, really nice. This gets more complicated. To allow for cross-compiling or bootstrapping, some packages need to be compilable using the Source from another package, so eg:- SrcPackage: xmp Depends: awe-drv | src.awe Klee favours having a simple .sdeb and no upstream .upsdeb's. I think we need to debate this some more. Well, my mind's decided. Bandwidth costs, cross-Atlantic especially, and the trivial inconvenience of having three files instead of one is very well worth it in real money. I basically agree with this. But I'm going to keep an open mind, until I see more debate. I totally agree. RPM's way _is_ broken. I think you missed the point -- this system enables a single source tree. The current system can be a single tree as well (put all source packages in one directory, and do a loop with dpkg-source -x, and dpkg-buildpackage -rsudo -uc -us), but both systems are pretty far from the BSD source tree, I think. Unfortunately, with the current state of the source tree, this doesn't really work. It's way too easy to build source packages that don't unpack with dpkg-source -x. I've seen way too many packages for my liking that won't build out of the box. Many of them depend on specialized environments that only exist on the original maintainers machines. IMHO this is where we need the possibility of dependencies on Source or Binary packages. Also a standardized build lab (build-i386.debian.org, etc.) being enforced would be a really nice way of ensuring a self-consistent distribution. But I'm not sure if we have the resources to do that. But that's beside my point -- there's so much other work to do at the moment that I don't think big changes the source packaging format at this point will improve things. There's always too much to do... :-) We should be planning this for Debian 2.0. The release of that will have lots of nice new features (deity for one). Actually, I think the scheme I proposed is actually very incremental, It would change all source package file formats, and all tools relevant to source packaging, and would require our developers to learn to deal with a third source packaging format. A bit too much of an increment for me. :-) I agree that the current source packaging system works, but it is broken in many ways. So we're going to have to fix it sooner or later. Preferably sooner. It would be really nice if deity could handle *source* packages :. But its getting designed pretty quickly, and might not be flexible enough by the time the new source stuff gets done. If we wait until later, there's going to be even more of an installed base of tools and packages that are going to need to be changed. So my personal preference is to spend some time up front to get our act in order. Right now, this ranks #2 on my list of things Debian has to fix -- dselect/diety is #1. dselect/deity and this are basically part of the same overall problem - the packaging and distribution system needs a bit of an overhaul. -- Tom Lees [EMAIL PROTECTED]http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
