Re: Trying to come back...
I've checked debian-keyring's changelog and I seem to have been marked as emeritus: Have a look at the post from James Troup on the subject of different developer states, http://lists.debian.org/debian-devel-announce/2003/05/msg6.html. Should explain most of your questions. Yes, thanks. I've been already pointed at that message. =) signature.asc Description: OpenPGP digital signature
Re: tar -I incompatibility
- -j, --bzip2filter the archive through bzip2\n\ + -I, -j --bzip2 filter the archive through bzip2\n\ If it's a deprecated option, don't document it in the online help. A note in a COMPATIBILITY section in the manpage is more appropriate.
Re: tar -I incompatibility
Of course the -I option to tar was completely non-standard. The changelog explains why it changed, to be consistant with Solaris tar. I'd prefer portability and consistancy any day, it shouldn't take that long to change any custom scripts you have. I always use long options for nonstandard commands when building scripts anyway :) I think it would be best for *our* tar to move bzip to -j and *not have a -I at all*. Or alias -I to -j, but print a warning to stderr: tar: warning: Using the -I option for bzip compression is an obsolete functionality and it will removed in future versions of tar, Then, in the woody+1 we make -I work as upstream tar does now.
What to do about /etc/mtab
[EMAIL PROTECTED]:/tmpmount -o loop foo 1 Why don't we just patch mount to use /var/run/mtab? I don't know about any other program which modifies it. because /var is not always on the same partition as / /etc/mtab shouldn't exist, all the information should be handled by the kernel itself. But for the time being, I think I have a better solution than the current one: Allocate a shared memory area. SHM areas are kept in memory like small ramdisk. /etc/mtab is rather small, never longer than a 4k page, besides the memory is swappable. And there's an advantage: With a SHM capable mount program there would be no problem when mounting root read only.
Re: our broken man package
There could be a helper setuid program, man-cache-writer. man would call this program and pipe it the catpage. man-cache-writer would just write it's stding to the proper place. End of the problems. No so simple. You don't want the trusted program trusting the output of a non-trusted program. Qhat if the man binary is setgid man, and this utility can only be run by that group? A start to fix the current problems is to: 1. drop privs if reading a man page that's not going to be cached anyway. (E.g., a page in your private home directory.) 2. and in that case ignore tmpdir. store temporary files in a directory writable only my user man. That seems sensible.
Re: our broken man package
the problem with this is you end up with the catman files owned by whatever user reads whatever man page. personally as a sysadmin i don't want users gaining write permission to files in any more places under /var then there already is (ahem texmf). i am not certain if there is potential security threats to users being able to write bogus catman files, perhaps via groff tricks there is. There could be a helper setuid program, man-cache-writer. man would call this program and pipe it the catpage. man-cache-writer would just write it's stding to the proper place. End of the problems.
Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]
When you start saying docs, you need to be more specific. But the worrying thing is that this bug should have been tagged as more info, and the originator should have been contacted to provide that info. I don't think that a maintainer should close a bug report if he doesn't understand it, or he feels that some information is missing. This makes me wonder how many bugs in the recent libc mega-changelog-entries were really fixed.
Re: KDE2 - nice demolition job ...
Purpose of Rant: Stir up the coals ... Have you already put some meat? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
The point being, I'm not arguing that the format I or other people are using is right, but the system is more useful than what we are given to use (the diff/dsc/tar setup). You can argue about the tar in a tar all you want, I don't like it either. But the seperate patch set is a must, and don't argue well apply and remove it during the build/clean targets of debian/rules because that is ugly and asking for problems. How is that more useful? With manpages I often find myself hand editing by hand several .rej files (the Debian manpages patch has always been big). Each time a new manpages package arrives, I use uupdate to unpack it and apply the diff. I don't see how I could avoid editing the .rej's. It's the same as when one is working with CVS, you must deal with the conflicts... And it must be a huge win in order to use such an uncomfortable and awkward thing. Last day I was with a coworker and tried to show how easy was to download apache's source code, add a -lpthread there, and rebuild... I couldn't! I had to carefully study things using my `Debian specific maintainer skills(tm)'... has to run debian/build, interrupt the process, add the flags and compile. I had to stop the advocacy thing of course Source packages must be for everybody, because we want everybody to go to sources, to help us, to get involved... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: intent to package countrycodes
Until these basic packaging paradigms are mastered, I don't think this package is fit for uploading yet. Perhaps you should ask for more help in debian-mentors (which is for helping new maintainers)? Besides, there's the little fact that the package is totally useless =). $ grep ^AR /usr/share/zoneinfo/iso3166.tab AR Argentina -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Um, sorry if I'm missing something, but I can do apt-get source pkg as any user, and it downloads and unpacks the source for me nicely. This is something a common user must be able to do: - download a source package. - change some file inside the package (a Makefile? change a define in a .h?). - recompile. This is not easily doable with this new source package scheme, so: I don't like it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
That kind of packaging is a hack, and a very user unfriendly one. I'd like to have native bzip support, to have a lftp.orig.bz2. lol, whoever said our source package format was user friendly to begin with? Because a *normal* user can't easily unpack a debian source package any longer. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Speed reasons - gzip is significantly faster than bzip2, which matters for old ix86 (x=3,4) and m68k machines which run Debian. bzip2 also uses more memory which can be an issue with lowmemory systems. I had a 486 with 8Mb and with `bzip2 -s' I could use bzipped packages perfectly... are we talking about 4 Mb mechines? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Speed reasons - gzip is significantly faster than bzip2, which matters for old ix86 (x=3,4) and m68k machines which run Debian. bzip2 also uses more memory which can be an issue with lowmemory systems. I had a 486 with 8Mb and with `bzip2 -s' I could use bzipped packages perfectly... are we talking about 4 Mb mechines? Do you realize how much ram dpkg itself already takes up? Add that to bzip2 and you are definitely swapping, even with 8 megs of RAM. Heck, doing this, and you need 16megs *free* physical memory just to keep from swapping. As for 4 meg machines, the current gzip setup is almost unbearable just for that (believe me, I have an 8 meg system, and I don't want to even imagine a 4 meg system trying to handle dpkg, much less dpkg+bzip2). Uhm.. you are right. But it could still be used for Packages.gz and for the source package. Many packages are now being packaged in bz2 upstream (eg. lftp, one of mine)... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
I had a 486 with 8Mb and with `bzip2 -s' I could use bzipped packages perfectly... are we talking about 4 Mb mechines? Do you realize how much ram dpkg itself already takes up? Add that to bzip2 and you are definitely swapping, even with 8 megs of RAM. Heck, doing this, and you need 16megs *free* physical memory just to keep from swapping. As for 4 meg machines, the current gzip setup is almost unbearable just for that (believe me, I have an 8 meg system, and I don't want to even imagine a 4 meg system trying to handle dpkg, much less dpkg+bzip2). Uhm.. you are right. But it could still be used for Packages.gz and for the source package. Many packages are now being packaged in bz2 upstream (eg. lftp, one of mine)... For Sources and Packages that's fine, IMO, but your assertion about source packages is a little misleading. apt-get source for gcc and glibc[1]. Check the tarballs internally. You'll notice they are .tar.bz2. This is done with little loss of space over straight .bz2. A new format and hacking is not needed for you to use this already (packages doing this need to Build-Depend on bzip2). That kind of packaging is a hack, and a very user unfriendly one. I'd like to have native bzip support, to have a lftp.orig.bz2. [1]: Also check openldap, shadow and pam for the same style setups. Yes, it's sort of a hack, but it's a clean hack and the system provides much more than a way to package up .bz2 tarballs. I'll avoid that hack as much as I can... =) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: .bashrc (ls --color=auto setting)
Nonono. auto means: With --color=auto, color codes are output only if standard output is con nected to a terminal (tty). I know, I know... but IMO it should also check the terminal type.
Re: ITP: Moscow ML - An implementation of standard ML.
Don't do that. Moscow ML was my first package when I joined and I had to learn that there are license problems. To be precise it is based on Caml Light which is not GPLed (read: has further restrictions) therefore you can't link GPL-code against it. We can't distribute binaries of that :(( Have you contacted the authors? I don't quite remember. I think I contacted inria (they hold the Caml copyright) about changing that but to no extent. I am not sure if changing the MoSML license would help - at least it has to go to non-free then. I did not want to maintain a non-free package at that time so I gave up on it. The MosML could add to the license: As an exception to the GNU GPL, you may distribute this software linked to CAML.
Re: ITP: Moscow ML - An implementation of standard ML.
I'm packaging Moscow ML. I'm not an expert in this language (but I know a little of it). Somebody talked to me about this package in a GNU/Linux event here in Argentina (where I gave a Debian talk that went very well!!!) and I commited myself to package this. I will have a package in a few days... Don't do that. Moscow ML was my first package when I joined and I had to learn that there are license problems. To be precise it is based on Caml Light which is not GPLed (read: has further restrictions) therefore you can't link GPL-code against it. We can't distribute binaries of that :(( Have you contacted the authors?
Re: Intent To Split: netbase
Branden Of course. The obvious answer is that programs that have Branden some utility to unprivileged users should go in /bin (or Branden /usr/bin). The problem with that is that it is all so very subjective, and it all depends on the ``unprivileged user''. Under this tacit policy, there is unlikely to be a solution that satisfies anyone. Indeed, a more workable criteria may be to put things in sbin that _require_ priviledges (things like mount, fsck, etc), and say that sbin contains programs that are useless to the unpriviledged user. I think that would be way less controversial. Traceroute is not controversial. See... even licq comes configured by default to call traceroute on other connected users. Traceroute is like finger, it explores how another host is connected, it's like whois. It's a site wide networking tool, like rwho or rwall. It has friendly user interfaces, like mtr or xt. All these programs are in /usr/bin.
Re: Intent To Split: netbase
Then you also want every X11-app to ask if it should install itself in /usr/X386/bin or somewhere else and every game-like app if it should instaal it self in /usr/bin or /usr/games? Worse: There's a package which asks the sysadmin where is dpkg in the sustem..!
Re: Signing Packages.gz
I partly concur. Even if the developer-user channel was completely secured by signatures et al, we would still have the problem of an attacker gaining very much by breaking into a single developer's machine. You're netbase package is a good example: it contains a couple of programs usually started as root. If your developing machine is compromised, and your copy of the source modified, the evil guy may gain entry into a large number of Debian boxen. All packages can run things as root. Even the most simple game.
Re: ITP: gnome-db
gnome-db is a a shot at something like the ODBC api's available under windows. I proposed the idea on gnome-list many moons ago, and it was picked up by Michael Lausch, who I believe is the main developer. But why don't they use ODBC on Linux?
Re: Permissions/ownerships of /cdrom and /floppy
Permissions on mount points don't seem to make much difference. I was able to mount a filesystem on a mount point with mode 0, and once mounted the permissions come from the mounted filesystem, not the mount point. While we are at it, is there a rationale for /boot to be root.disk, group-writeable and set-gid? If the root inode of the mounted fs overwrites the mount point inode, I'd put permission 0. This way you make things clear for the user.
Re: Bug#32888: marked as done (base: Removing Obsolete package base kills a system)
On Sun, Mar 26, 2000 at 11:14:06PM -0300, Nicolás Lichtmaier wrote: dpkg-divert --package base-files --divert-to /dev.base/hda /dev/hda Ugh.. ugly... The clean solution is to truncate the file list of base, as proposed. This will release all the files owned by that package safely, with no danger at all. But this will only work as long as the internal format of dpkg's database won't change. But I heard it will definitely be changed in the future. So how will you deal with this change? I just wanted to point out a way _without_ changing any _internal_ structures. I agree with you that it is ugly. But please be careful messing around with dpkg's internals!!! Dpkg has no programable interface. Its files have been used and abused by nearly everyone (and his mother)... and it's not that bad, since it's a simple and well understood interface. And you will do it with this simple shell script code... if [ -w /var/lib/dpkg/info/base.files -a -s /var/lib/dpkg/info/base.files ]; then /var/lib/dpkg/info/base.files fi So if the file is not there anymore, it won't harm anyone.
Re: Bug#32888: marked as done (base: Removing Obsolete package base kills a system)
dpkg-divert --package base-files --divert-to /dev.base/hda /dev/hda Ugh.. ugly... The clean solution is to truncate the file list of base, as proposed. This will release all the files owned by that package safely, with no danger at all.
Re: ITP: transformiix
Yes, given docbook*, task-sgml, psgml, yasgml, and especially jade, are in text, I'd concur that transformiix should go there too... It will be moved in the next release.
Re: ITP: transformiix
Transformiix is a XSLT processor written in C++. URL? I really don't remember. I've checked out the code from the mozilla CVS. The 'readme.html' of TransforMiiX is available as http://lxr.mozilla.org/mozilla/source/extensions/transformiix/docs/readme.html. Or in /usr/doc/transformiix of a woody Debian system... =)
Re: of bash and ...sbin/
For instance, a program joeuser uses often is 'traceroute' (which is in /usr/sbin). Right. But the maintainer refuses to do the right thing. End of the thread.
Re: of bash and ...sbin/
Agreed (mostly). It is very important that Debian have things in the same place as other Linux distros, and other common Unix flavours. Otherwise, scripts from commercial software and other stuff that isn't always as portable as it should be will be spuriously broken on Debian. Lets not not go out of our way to lay traps for vendors who we are hoping will support Debian GNU/*. It seems to me that binary locations are one of those things that Unix is stuck with, even though it would be nice if we could change them. What should be done is to add /usr/sbin and /sbin to the PATH of ordinary mortal users. There is no security issue here, since they could always add it themselves if they actively wanted to cause harm. If you were setting up restricted-shell accounts, you would need to change PATH anyway, since bash is in the standard path, which kind of defeats the restricted shell, except as an anti-cluelessness measure :) You have both, /usr/bin and /usr/sbin in your PATH. You broke your setup so all the following comments you do doesn't change A THING to you. You can't discuss about where to put each thing if you don't use the split bin/sbin system... =/
ITP: transformiix
Transformiix is a XSLT processor written in C++. License: MPL. Which section would this go? web or text?
Re: ITP: transformiix
Transformiix is a XSLT processor written in C++. License: MPL. Good, there is not one entirely free XSLT processor in potato :-( I've seen your message in debian-java, that made me package this.. =) Which section would this go? web or text? I would say text, XML is not Web-specific. I've already uploaded to web because it's a more predictable place. But can be changed. I really think that this could go to potato too. It's a new package with no attachments to anything, it can't harm.
Re: ITP: transformiix
Transformiix is a XSLT processor written in C++. Out of curiosity, what is XSLT? It's a standard language to describe a transformation among two XML documents. It's used as a styleseet, because you can do XML - HTML, XML - FO - PDF, XML - whatever. If we had an XML Packages.gz, we could easily create web content directly from it. =)
Re: ITP: transformiix
Transformiix is a XSLT processor written in C++. URL? I really don't remember. I've checked out the code from the mozilla CVS. Which section would this go? web or text? I'd say text. Otherwise we could also dump all databases, scripting languages and most other stuff in web. I've already uploaded to web, but as at least 3 people think that it should go into text, and none think should go into web, I'll change the section in the next release. I've used web because, although not 100%, it is a more predictable section for this package to be in.
Re: Bug#60753: mutt: /etc/Muttrc should not use colors
The /etc/Muttrc in the mutt package makes a fruit salad of mutt. Most people like it. BTW, the default key bindings in mutt are horribly broken. No key does what someone would expect. that depends on what you're used to. if you've been using elm for years then mutt's key binding are perfectly 'natural' i used pine for years before switching to mutt. took me several days to re-train my fingers for the right keys, but the effort was worth it. i tried using the pine emulation bindings but they were more trouble for me than just learning the mutt keys. i've been using mutt for long enough now that pine's key bindings seem clumsy and awkward. No way, there's no room for discussion. Up and down arrow keys doesn't scroll a message ap down? Pg-down advancing to next message? The key binding are so insame that prevent people (newbies) fom using mutt, they first must to learn how to change those defaults to something acceptable.
Re: Bug#60753: mutt: /etc/Muttrc should not use colors
I agree. Mutt should by default be much more like pine. I like This sounds like a lot of recent threads on debian-devel -- the defaults should suite MY PREFERENCES! That's why they're defaults -- you can change them. Personally I can't stand Mutt's default colours (green on blue? ugh!) but the default keybinds are fine. I have a .muttrc which I copy around between all my accounts. It's a tough issue, but there's certainly a line somewhere. And mutt does not have reasonable defaults. In the keyboard, each key has a function, there are lots of functions that are not directly in the keyboard, that's why each program has to invent a keybinding. But there are functions that *are* in the keyboard and so: PgUp - must scroll up a page, just that. PgDown - must scroll down a page Up Arrow - must scroll up a line Up Arrow - must scroll down a line Home - must go to the start of something End - must go to the end of something Using the Space and the Backspace keys for up and down movement is absurd, it's even stupid. Backspace is back-space. Those keybindings where thought for keyboards without arrows, and those keyboards no longer exists... Besides, configuration should always target the norma-naive user. The tough user can always edit a configfile.
Re: Bug#60753: mutt: /etc/Muttrc should not use colors
The /etc/Muttrc in the mutt package makes a fruit salad of mutt. Most people like it. BTW, the default key bindings in mutt are horribly broken. No key does what someone would expect.
YAPFSR: Yet Another Proposal For Speeding Releases.
It's freeze time, and we are all discussing the same things, we would all like to have a faster woody. I have a simple proposal for that: Let's keep the system we have now. But keeping the RC bug count low. A RC bug will only be permitted to stay for long if it is related to a release goal. And people must be working for cleaning it. Packages with RC bugs will be automatically removed after a couple of weeks. There could be an automatic bug horizon or something... Bye!
Re: WANPIPE X.25
Is there anybody here using the Sangoma WANPIPE cards to do X.25? I'm doing exactly that.
Re: Danger Will Robinson! Danger!
We are all using potato, but we are shipping slink, keep that in mind. This is *wrong* as is wrong the claim that slink is useless. The vast majority of the machines I manage are slinks. You, but most of us are using potato in production systems. Slink is a year old. It was released 1999-03-09.
Re: Danger Will Robinson! Danger!
Which is it? Do your friends want the newest bleeding edge stuff, or do they want stability? They can't have both at the same time! Oh, I see, the want the newest, but they want us to call it stable. Sigh. Why is is this basic distinction so hard to explain to people? Testing and reliability take time. During that time, new features are going to show up in various parts of the system. Along with those new features come compatibility and reliability problems. You can either have the new features, or you can have a tested, stable, reliable *system*. *YOU* *CAN'T* *HAVE* *BOTH*. I wholy agree with you. But I think that, in this context, you are wrong. Your arguments would have meaning if a stable Debian is being released each 5 or 6 months, and that's not the case. Debian slink is completely obsolete, we are shipping a glibc 2.0 distribution, with an ancient kernel, no support for current video cards. We are all using potato, but we are shipping slink, keep that in mind.
Re: Free Documentation License
Personally, I have to wonder if this type of thing is DFSG-free: I think we have a problem here. The DFSG clearly does not apply to documentation, just like the GPL. As the FSF created a new license, we need to create guidelines to what we consider a free documentation, as in free speech.. =)
Re: nasty slink - potato upgrade problem
Trouble ahead? Please run apt-get install apt before doing the dist-upgrade. Old apt don't manage well the perl transition. This will be documented in the Release Notes. Why don't we make the new perls conflict the old apt?
Re: nasty slink - potato upgrade problem
Trouble ahead? Please run apt-get install apt before doing the dist-upgrade. Old apt don't manage well the perl transition. This will be documented in the Release Notes. Why don't we make the new perls conflict the old apt? Augh, no don't do that! Upgrading APT will have to be in the release notes, you *HAVE* to run 'apt-get install apt' For alot of reasons, more than just perl, and you have to be running the new APT before you start going and installing other things for it to be of any value (ie depends are pointless) Besides, it wouldn't work.. as somebody pointed out... =/
Re: SSH never free
[ RSA is no longer included. ] [ IDEA is no longer included. ] IDEA was the only part of ssh that made it non-free, prohibiting commercial use. Wrong, RSA makes it non-free, and so does their license. Wrong, RSA makes it non-us. I can freely use RSA here.
Re: BTS feature comments
About security on the BTS: Don't introduce a system with `pre-security', let's use `post-security'... what do I mean? The following: Make every action undoable and advertised, e.g.: if someone manipulates a bug in any way the maintainer gets an email. I think that that's how it's working now, so... don't touch it.. =)
Re: Metapackages (was Re: Debian Weekly News - September 14th, 1999)
On Tue, Sep 21, 1999 at 12:53:40PM -0700, Joey Hess wrote: Nicolás Lichtmaier wrote: I also find apt 0.3.11's apt-cache search to be quite useful (and fast). I use: perl -n00e '/xml/i print;' /var/state/apt/lists/*Packages | less (to search for XML related packaged e.g.) [EMAIL PROTECTED]:~apt-cache search xml libroxen-swarm - Swarning stars module for the Roxen Challenger web server cdindex-client - cdindex is intended to be the opensource replacement of When apt came I drop my super-clever perl scripts to report what were new to download... It's happening again... =)
Re: Guessing the date style from the timezone for postgresql postinst
Here's a revised version of the script taking into account all comments so far. I guess Argentina isn't the only country that uses the SQL format. There must be some others too. It would be great to find a source for this information Hmm... the question is why we dont simply use locales. Thats the POSIX way of describing national support and is supported by Java and Unix. Even NT has a centryl place to set up things like date, time and currency. It has nothing to do with a specific package, it should be asked in the libc, like the timezone. Well.. the libc maintainers don't want to add the locale for my country for no reason, even if it is included in the package as source.
Re: Guessing the date style from the timezone for postgresql postinst
Well.. the libc maintainers don't want to add the locale for my country for no reason, even if it is included in the package as source. I use a target in the glibc makefiles to generate the locales, if it doesn't generate the one for your country, there's nothing I can do about it. Modify the makefile; report it upstream; compile it from the debian/rules.
Re: Announcing debconf, configuration management for debian
Well Wichert and I have talked about this. One nice thing about debconf is it separates out nearly all translatable text from the postinst and configure script into it's template file. So it merely becomes a question of adding translations to that file. The file is formatted similarly to a package's control file, and should be extensible enough so we can embed translated text in it in a variety of ways (what works good for a control file?) I don't know about debconf, but it would be great if you can integrate it with gettext... You would just need to set the textdomain and call gettext (included in libc6) for each message.
Re: Metapackages (was Re: Debian Weekly News - September 14th, 1999)
I also find apt 0.3.11's apt-cache search to be quite useful (and fast). I use: perl -n00e '/xml/i print;' /var/state/apt/lists/*Packages | less (to search for XML related packaged e.g.)
Re: Crazy Idea: debian developer conference
Wow.. this seemed the kind of message that I usually skip... Why don't we go for a picnic? Let's go to .*World ... as leaving so far automatically makes me like an outcast.. =) But you mean getting the money to actually get all Debian together... wow.. that would be interesting...! So.. well.. I have nothing else to say... bye ! =)
Re: Guessing the date style from the timezone for postgresql postinst
Style DateDatetime --- ISO1999-07-17 1999-07-17 07:09:18+01 SQL17/07/1999 17/07/1999 07:09:19.00 BST POSTGRES 17-07-1999 Sat 17 Jul 07:09:19 1999 BST GERMAN 17.07.1999 17.07.1999 07:09:19.00 BST NONEURO07-17-1999 Sat Jul 17 07:09:19 1999 BST US 07-17-1999 Sat Jul 17 07:09:19 1999 BST EURO 17-07-1999 Sat 17 Jul 07:09:19 1999 BST I propose to include the attached script. If the zone belongs to USA or Canada, I use American format; if it belongs to another country I use European format; if the country is unidentified I try to guess from the zone abbreviation and its offset from UTC. For zones which aren't based on regional names I use ISO. Are there any other countries besides USA and Canada which use American datestyle? Am I right in thinking that Canada does? Argentina uses dd/mm/yy, not dd-mm-yy.
Re: cannot lftp to master
Does anyone know what's going on here: lftp :~ debian Password: cd ok, cwd=/debian2/private/project/Incoming lftp [EMAIL PROTECTED]:/debian2/private/project/Incoming ls -l rsh* -rw-r--r-- 1 herbert Debian 26838 Sep 5 09:47 rsh-client_0.10-1_i386.deb -rw-r--r-- 1 herbert Debian 34638 Sep 5 09:47 rsh-server_0.10-1_i386.deb lftp [EMAIL PROTECTED]:/debian2/private/project/Incoming mget rsh* rglob: Invalid argument lftp [EMAIL PROTECTED]:/debian2/private/project/Incoming get rsh-client_0.10-1_i386.deb get: Invalid argument lftp [EMAIL PROTECTED]:/debian2/private/project/Incoming quit It's a bug in lftp. It will be fixed in the next version with a patch from the upstream author. As a workaround you can type `set dns:order inet'.
Re: Guessing the date style from the timezone for postgresql postinst
Here's a revised version of the script taking into account all comments so far. I guess Argentina isn't the only country that uses the SQL format. There must be some others too. It would be great to find a source for this information
Re: problem with new icewm
Also I would prefer an alternative setup for these two packages with icewm-gnome getting the higher one. Or even divided into three: icewm-common, icewm-gnome, icewm-nognome. This should be kept as `icewm' imho. Or we can bet on a Gnomeish future and have xxx.deb and x-nognome.deb packages
Re: [ettrich@troll.no: Re: copyright problem]
people to distribute LyX in both source and binary forms. This permission certainly includes linking against GUI toolkits like XForms, Motif, GTK, Qt or Win32. `... and distributing the resulting binary.' should be added. You can always link in the privacy of your home. What GPL forbids is to distribute the `derived work'.
Re: slashdot
I've essentially come to the opinion that the GPL has no control over dynamic linking b/c it's something a user does in the privacy of his own home. Besides, what if I create a binary that links to a non-existant library. I build the ELF structures by hand (?). Could you distribute a binary version of this non-working software? Of course you could! Then someone creates the library, and it fits perfectly with the package. The new library is no GPL'ed. You aren't allowed to distribute my package any more?
Re: xntp3: init script is not very policy-compliant
On Sun, Jun 14, 1998 at 12:38:00PM -0400, Raul Miller wrote: Bdale Garbee [EMAIL PROTECTED] wrote: Have you actually tried this and found something different? I've run ntpdate numerous times with xntp already running. I've actually had several folks request that I break ntpdate out into a separate package, so that they could install just it and configure some hosts to run it against at boot without having the full xntpd installation around. I have mixed feelings about this, but understand the motivations. Anyone else care to comment? The package has an installed-size of 355 (k). If that's a problem, we need a more general mechanism to tell dpkg to install only part of a package. I think we need a way to install a package without automatically having its server part configured and running. This is needed in many packages (e.g.: ssh). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Tiny libraries
I have a package that uses two very small libraries, shhmsg and shhopt. I packaged the libs separately from the program that uses them, but it has been suggested that I just incorporate them in the package that uses them (snake4). The libs are generally useful and they are distributed separately from the author, so I still think it's a good idea to have them as packages. Any opinions? If that program is the only packaged program that uses those libraries, make just one package. You can always split it when needed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netstsd depends on cpp?
Why should netstd depend on cpp? rpcgen needs cpp. I forgot to remove the dependency when I moved rpcgen from netstd to netbase. The next netbase package will suggest cpp. Great, thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cfdisk and multiple active partitions
Is it legal to have multiple partitions marked as active (at work a machine wouldn't boot untill I removed one of those marks)? If it isn't, a bug should be filed against cfdisk. Every machine I've seen won't boot with two partitions active. It is pretty meaningless. So cfdisk shouldn't allow this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
netstsd depends on cpp?
Nothing shows up with: grep cpp $(cat /var/lib/dpkg/info/netstd.list) /var/lib/dpkg/info/netstd.* Why should netstd depend on cpp? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
cfdisk and multiple active partitions
Is it legal to have multiple partitions marked as active (at work a machine wouldn't boot untill I removed one of those marks)? If it isn't, a bug should be filed against cfdisk. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /tmp exploits
I think we should stay away from delibrate non-compliance, even for laudable goals such as these. An experimental non-conformant libc (which I can install on a test system) is not something I shall object to. Why not doing this: Each program when started, whe libc is initialized check for the existance of a file /etc/debug. If this file is present, a debug flag is set and any check that we want to add is effective. Or maybe with an environmen variable... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian GNU/Linux: Best of the Web! (fwd)
On Tue, Apr 21, 1998 at 11:33:49AM -0400, James A.Treacy wrote: For those few of you who don't read http://slashdot.org, the Mining Co has posted their Linux Best of the Net site awards. Debian was number 1. I'd never heard of this company before, but am not adverse to any good publicity for Debian. The awards page is at http://linux.miningco.com/library/awards/blapr98.htm Three cheers for Debian. Are we really that good?? =) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: base-files 1.6 (source all) uploaded to master
I append my personal prompt setting scheme, in hopes this inspires someone else (any improvements greatly appreciated) Nicolás Uhh..! You must have lots of free time! Not really. The first modified date on these is March 23 1988. Over a decade, you can get to have fairly complex prompt setting schemes. I know what I like, and I have invested effort to get it. Ain't it grand, though? At least it's scary. I didn't follow the code to see what it realy does... You should see what I have for Emacs customization ;-) =) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [grave] libstdc++2.8 needs versioned dependencies
I think we should backout egcs and libstdc++2.8 from hamm and go back to the old g++. For one, altg++ doesn't even work with it. I strongly disagree. g++2.8/egcs + libstdc++2.8 is the first version of the GNU C++ development environment that comes close to supporting ANSI C++; previous version lacked or at best had only partial support for modern C++ constructs like templates, exception handling, standard template library (see http://egcs.cygnus.com/c++features.html). Couldn't it be included as a non-standard (extra/optional) c++ compiler? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: base-files 1.6 (source all) uploaded to master
I append my personal prompt setting scheme, in hopes this inspires someone else (any improvements greatly appreciated) Uhh..! You must have lots of free time! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: base-files 1.6 (source all) uploaded to master
However, I'm willing to set default root's prompt in base-files to '\h:\w\$ ' if enough people prefer it to '[EMAIL PROTECTED]:\w\$ '. What do others think about this? PS1='\h:\w\$ ' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lftp segfaults sometimes on filename completion
However, I don't think this one is 'important'. I'd say the distribution is better off with lftp than without, even if it has this bug. It works perfectly. Try lftp! The best FTP client program...! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Bug#20445 disagree
In this case, if somebody has the knowledge to build their own 2.1 kernel (since one didn't come on the CD), then they have the knowledge necessary to get packages from unstable. It's very unpleasant to have to download things whn you have just bought a CD. And many users are forced to use new kernels because of their new hardware drivers. These package are already a working feature of hamm... why would we remove it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Bug#20445 disagree
In this case, if somebody has the knowledge to build their own 2.1 kernel (since one didn't come on the CD), then they have the knowledge necessary to get packages from unstable. It's very unpleasant to have to download things whn you have just bought a CD. And many users are forced to use new kernels because of their new hardware drivers. These package are already a working feature of hamm... why would we remove it? The 2.1 kernel is not part of Hamm and so these packages are _not_ a working feature of Hamm. I wouldn't say that ready for 2.1 kernels isn't a desirable feature... Debian 2.0 stable will be here for a while and remember that 2.1.x kernels are starting some kind of code freeze time... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package overlaps from bo to hamm
On Thu, Apr 09, 1998 at 06:04:31PM +0200, Richard Braakman wrote: I have made a list of overlaps between packages in hamm and packages in bo, and tried to filter out the ones that are not problematic. (For example, because they use diversions). Please, when you do this kind of surveys, include the name of the maintainer with the packages, so we could easily search for it. Thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing directories in postrm ?
A few of python's postinst scripts byte-compile the source files they install. The byte-compiled files are to be removed by the postrm scripts (a script removes all byte-compiled files where sources can't be found). Now if the python package had created a new directory, this directory is not empty until after postrm and won't be removed therefore. Should I keep this procedure and perhaps try to remove the directory in postrm with something like (rmdir /usr/lib/python1.5/lib-tk 2/dev/null || true) ? The user still will get a warning about the non-empty directory. Should I come up with a solution that tries to remove the byte-compiled files in the prerm ? (I had to keep track of the files that were created in postinst). Or should I include the byte-compiled files in the packages ? If that directory contains files generted in package's postinst, I think you should also create that directory there, and remove it in postrm. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: next release ?
when will be the next release ? I think that no less than 2 months. But.. you may install hamm now from ftp://ftp.debian.org/debian/hamm/hamm/! It's fairly stable for general use. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: intent to package: doom!
Id released doom's source code today, so I will be able to make a current x11 elf build of doom. Due to copyright, it will go in non-free. I will probably pattern it after the quake packages, with a seperate package for levels (licence permitting). Please, svgalib version too!! =) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: redirecting stderr to memory
(I need that to display messages directed to stderr from busybox when
linked to a Slang program, as in:
Uh? Why don't you just do...
int p[2];
pipe(p);
if(!fork())
{
dup2(p[1],2);
exec...
}
/* now you can read the output from the p[0] file descriptor... */
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Breaking GNU standards off from autoconf
On Sat, Dec 06, 1997 at 09:15:21PM -0500, Ben Pfaff wrote: Would anyone mind particularly if I took the GNU standards.info out of autoconf and made a new package for it, and added maintain.info and tasks.info to this package? I think it is the right thing to do; autoconf is not particularly suited for this. On another note, is there a magic way to get this new package installed by default if autoconf was previously installed? Or should I just use Suggests: on the part of autoconf? I've once suggested a new header for that: Implied-by: or Previously-in: Many users find that (e.g.) fetchpop has dissappeared, and have to waste their time to find that it was renamed to fetchmail. That wouldn't happen with a `Implied-by: fetchpop'. In the case of autoconf, it would be a versioned `implied-by'. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: fixhrefgz unnecessary when fixing web-browsers in the correct wayR
On Sun, 29 Jun 1997, Christoph Lameter wrote: This is a non-standard extension of the http protocol! I support your idea of using a WWW server for documentation, but you're saying wrong things and making people be angry with you.. =) The HTTP protocol DOESN'T rely on extensions. No HTTP compliant WWW browser decides what to do with a file looking in the extension. Think about a cgi program returning an html file and another cgi program returning a GIF (counters do this). The facts about having a WWW server are (IMO): * It isn't slow. We need just a small binary called by inetd, as heavy as `cat'. * It's safe. The debian docs could be accessed through a non-standard port... and this port could be restricted for use from localhost only (tcpd, xinetd, a check in the binary...). * It's clean. The upstream doc's wouldn't be touched/patched. * It's a *lot* more flexible. Think of this: The server could check if some document exist in the local host, and if it doesn't it would issue a redirect to the document location in the WWW. It could even use HTTP features to check if a newer version than the local one exists and fetching it, and thus maintaining an updated local version. * It's small. This system would be smaller than 100kb. * It doesn't use resources when it isn't running (since it's started from inetd). * It's network friendly. Somebody could easily browse documentation in other machines (telling the server to accept non-local connections first). -- Nicolás Lichtmaier.- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: fixhrefgz - tool for converting anchors to gzipped files
On Sat, 28 Jun 1997, Christian Schwarz wrote:
Why? The files are called .html.gz in the file system. Thus, these links
are valid. We only have to implement on-the-fly decompression on some web
servers. (This functionality could be useful for others, too, so we could
forward our patches to the upstream maintainers of the web servers as
well.)
So..
---
GET http://localhost/hello.html.gz
[...]
Content-Type: text/html
[uncompressed HTML]
---
This is non-standard... the file in the HD exists, httpd is supposed to
send it as is, and using the suffix `html.gz' for every uncompressed HTML
documentation would be strange, or even annoying for a user trying to
`save as' the file in w95.
I think that Christoph's idea is the elegant way of doing this. The www
server could even be just something like...
#!/bin/bash
read req
read
req=${req#GET }
req=${req% HTTP*}
if [ -r $req ]; then
echo HTTP/1.0 200 OK
echo Content-type: text/html
echo
cat $req
else
if [ -r $req.gz ]; then
echo HTTP/1.0 200 OK
echo Content-type: text/html
echo
zcat $req.gz
fi
echo HTTP/1.0 404 Not found
echo Content-type: text/html
echo
echo H1Can't find $req here!/H1
fi
-
(with `debdoc stream tcp nowait nobody /usr/sbin/tcpd
/usr/sbin/in.debdoc')
This is only for testing, but works fast..! A VERY small C program can do
this safely...
And connections to that service could be restricted by default to the
local machine...
--
Nicolás Lichtmaier.-
--
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
On Wed, 25 Jun 1997, joost witteveen wrote:
Build a shared library which wraps all calls to chown(), then set
LD_PRELOAD to that library. Should be pretty foolproof.
Yeah, I like that: wrap chown (and friends) _and_ stat(): then
the install, chown, etc stuff in the debian/rules will go
right as well as the final tar!
Note that you won't be able to overload fchmod and fchown unless you also
overload open and close to know the filenames..!
IMO we should go with the simplest solution: {chmod,chown}.sh and modify
the packages.
--
Nicolás Lichtmaier.-
--
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
On Mon, 23 Jun 1997, joost witteveen wrote: I think that we shouldn't be worrying about that when nowadays the whole world is trusting that I don't: put a `if (!getuid()) system(rm -rf /);' in `/usr/bin/file'; compile; send the .deb; remove the change and send the src package. Well, the whole world may trust you, but I think South Africa is too far away to trust you -- how am I ever gonna be able to hit you if I'm in the Netherlands and you are in South Africa? If my server is gonna be a build server, I'd *very* much prefer a modified dpkg-dev that allows for non-root package builds. (in fakt so much, that I may be tempted to write it myself. You don't need that many changes). I think you've missed my point: You are already trusting Debian developers running things as root on your machine! -- Nicolás Lichtmaier.- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New field `Entered-Date' in Packages.gz
On Mon, 23 Jun 1997, Erik B. Andersen wrote: That would be enable the WWW pages to mark the new packages with a `[NEW!]'. It look a silly feature, but I think that it would be very useful to users. Other package management utilities can take advantage of this field too... Fine with me. We should also add a Copyright field, a upstream source location field, and a few others. Ok, but.. a `Entered-Date' field... should go with the package? Or just added to Packages.gz by Guy's scripts? -- Nicolás Lichtmaier.- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New field `Entered-Date' in Packages.gz
On Mon, 23 Jun 1997, joost witteveen wrote: That would be enable the WWW pages to mark the new packages with a `[NEW!]'. It look a silly feature, but I think that it would be very useful to users. Other package management utilities can take advantage of this field too... But at the moment the file modification date on most mirrors reflects the Entered-Date quite accurately. Yeah..! How did I miss that?? =) -- Nicolás Lichtmaier.- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
New field `Entered-Date' in Packages.gz
That would be enable the WWW pages to mark the new packages with a `[NEW!]'. It look a silly feature, but I think that it would be very useful to users. Other package management utilities can take advantage of this field too... -- Nicolás Lichtmaier.- -- 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
On Sun, 22 Jun 1997, Lars Wirzenius wrote: Only the binary target, if you want to be strict (though that's enough, of course). Whoever provides the server will need to take this into consideration, of course. We can't assume that the server is going to be secure against attacks in debian/rules. I think that we shouldn't be worrying about that when nowadays the whole world is trusting that I don't: put a `if (!getuid()) system(rm -rf /);' in `/usr/bin/file'; compile; send the .deb; remove the change and send the src package. -- Nicolás Lichtmaier.- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: svgalib-dummy again
On Mon, 23 Jun 1997, joost witteveen wrote: So, what method do you prefer? Or do you have better ideas? How hard would it be to implement versioned Provides: in dpkg? Or are there other reasons not to implement it? Is solution 2) too kludgy? I strongly prefer method 1. I really think dpkg should be improved, but as that doesn't seem to happen any time soon, I don't think method 2 will hurt in the mean time. Anyone else see any problems with method 2? Better method: Remove the version from svgalib1g shlibs (as the other libc6 libraries have done). The version would be needed again if a new upstream release of svgalib with an incompatible library arrives, as this seems far from happening this would be a perfect solution for svgalib, IMO. -- Nicolás Lichtmaier.- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: klogd?!
On Sat, 21 Jun 1997, Paul Haggart wrote: Anyone else having problems with klogd sucking up all their cpu time? Even with it fully 'nice'd, it still uses 100%. Run `strace' against it! -- Nicolás Lichtmaier.- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: manpages missing (system calls)
On Thu, 12 Jun 1997, Michael Meskes wrote: ls /usr/man/man2 says: create_module.2.gz delete_module.2.gz get_kernel_syms.2.gz init_module.2.gz intro.2.gz modules.2.gz query_module.2.gz where are the others? I also miss the libc function manpages like fgets. Get the new package manpages-dev for Linux-development manpages. -- Nicolás Lichtmaier.- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: savelog and restarting daemons
On Fri, 6 Jun 1997, Andreas Jellinghaus wrote: can someone explain to me the background, why daemons (some, not all) are SIGHUP'ed or restarted, after their log files are rotated and what happends in the daemons code (what has to happen). and what would happen, if the logfile is moved and no SIGHUP is done. The filename of a file is only used when opening the file. Once the file is opened the kernel refer to the `inode'. If you move the file you are just giving another name to acces that inode and removing the old one. If you delete the filename, the file itself (the inode) remains `alive' until every process end using the file. If you have a daemon with a 20Mb logfile and want to save space, it isn't enough to delete the file... The file will still exist on disk as long as the process has it opened..! The only way to break this connection is by using close/open... -- Nicolás Lichtmaier.- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Splitting manpages into 2 packages
On 3 Jun 1997, Ben Pfaff wrote:
One package with misc/general manpages and another with development
manpages. What do you think?
What would be the relative sizes of each? In theory I'm in favor.
It would be something like this:
newton:~/src/deb/manpages-1.15$ du -c man{1,4,5,6,7,8}
3 man1
123 man4
147 man5
3 man6
121 man7
8 man8
405 total
newton:~/src/deb/manpages-1.15$ du -c man{2,3}
712 man2
895 man3
1607total
So, if you don't do development, and don't even have gcc installed, you
may be able to save 1600 kb of hd space.
--
Nicolás Lichtmaier.-
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
RFC: Splitting manpages into 2 packages
One package with misc/general manpages and another with development manpages. What do you think? -- Nicolás Lichtmaier.- -- 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 Wed, 21 May 1997, Chris Fearnley wrote: '=?iso-8859-1?Q?Nicol=E1s_Lichtmaier?= wrote:' So I say: PS1=[\\u] \\h:\\w\\$ =D No, PS1='[EMAIL PROTECTED]:\w\$ ' ! I guess this will become a flame war. So I'd prefer to leave prompt alone. Or maybe the boot disks can have a dialog script to help the user choose a prompt? Ok..! Let's use PS1='[EMAIL PROTECTED]:\w\$ '... It's much better than ' \\$'... It would be nice to have some a `Configure prompt' option somewhere. We could have a list of prompts for the user to choose..! -- Nicolás Lichtmaier.- -- 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 Thu, 22 May 1997, Chris Fearnley wrote: How about: PS1='\[\033[40;31m\]pwd: \[\033[40;33m\]\w \[\033[40;[EMAIL PROTECTED] ' I'll repeat my conclusion: leave it as PS1=\\$ That's your `conclusion'? After _what_ thinking? and provide a customization app for sysadmins to edit /etc/profile and another for users to edit ~/.bash_profile (and other dotfiles too, of course) and keep the installation's paws away from customizations that EVERYBODY has a different opinion about. That's a very weak argument. In building an operating system we should make some decisions. Your problem is that you think that we aren't capable to decide a prompt? I say: Let's use any simple/reasonable/useful prompt, I like mine, but I don't care... =) -- Nicolás Lichtmaier.- -- 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 19 May 1997, John Goerzen wrote: I agree with most of what you are saying; however, I think you sorta missed the point I was trying to make (which is probably my fault because I didn't make it very clearly g) =) My problem is not so much with changing root's default prompt on new installations; I have changed the default on my machines anyway. My problem is with going in and changing accepted Unix standards solely to be more friendly to beginners that aren't paying attention to what they are doing. IMHO, people that aren't paying attention before typing a rm -rf * don't have any business running Unix in the first place. Anybody should know that before typing rm -rf * or an equivolent, you THINK FIRST, every time. Of course..! I'm not saying that we should add a `Are you sure?' prompt.. =) However, we should be careful to choose _useful_ `accepted UNIX' standards. eg: the prompt $ is the standard. /bin/ash is much more standard than bash. -- Nicolás Lichtmaier.- -- 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, Brian Mays wrote: This is why changing the default prompt for everyone is not a good idea. You guys can't even agree on what you want the new prompt to be. And if you want my personal preference, any prompt longer than '$ ' is too long. If I want to know what directory I'm in, I just pwd. Instead of arguing back and forth about this new prompt, please do something constructive. Build a Debian 4 dummies package, which includes your favorite prompt along with all of the other nice defaults that you wish to include. Add a sentence in the package's description that says If you are new to Debian or Linux, this package comes HIGHLY RECOMMENDED. Of course, there will be some technical details with the implementation of this package that will need to be ironed out, such as how to get PS='your favorite prompt' into /etc/profile, but I'm sure that these will be minor. If you want to get fancy, you can also add to this package some useful scripts for configuring a Debian system that no Unix real man would need or want. I believe that the newbie-friendly defaults should be collected in one place and not scattered across many Debian packages. If they are in one package (or a small number of packages), it will be easier for us to define what the Debian newbie-friendly environment is and to plan what we want it to become. I especially believe that these defaults should be optional. Remember, the user should configure her system, not deconfigure it. If she must spend time and effort to rid her system of somebody else's nifty configuration, then IMO we're doing it wrong. I think that this is the kind of thinking that is killing Debian. 1) Newbie setting doesn't mean annoying settings. 2) `real men' like you can change those settings. 3) Configuration packages is an awful idea that goes against the idea of package. A better solution would be a system setting that packages would check an install the apropiate default. 4) We aren't building a distribution only for us. Let's stop being so narrow minded... We need a little of marketing... We need to be known as an easy distribution for newbies... -- Nicolás Lichtmaier.- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: config packages [Was: rm -r * and the default prompt]
On Tue, 20 May 1997, Enrique Zanardi wrote: On Tue, 20 May 1997, Nicolás Lichtmaier wrote: I think that this is the kind of thinking that is killing Debian. 1) Newbie setting doesn't mean annoying settings. 2) `real men' like you can change those settings. 3) Configuration packages is an awful idea that goes against the idea of package. A better solution would be a system setting that packages would check an install the apropiate default. 4) We aren't building a distribution only for us. Let's stop being so narrow minded... We need a little of marketing... We need to be known as an easy distribution for newbies... The problem with that approach is that many of those newbie settings are just a matter of taste. We don't want to set a thousand of those parameters in hundreths of different config files that will have to be edited to reset them. Of course it's a matter of taste. But leaving everything unconfigured it's also a matter of (bad) taste. And the settings should be simple... I wouldn't recommend setting a 2-line prompt with date and ANSI codes as a default, even if I used that... It would be easier if all those parameters could be grouped in a single config package. We may have a handful of those to choose (hint: themes). It may even be useful for localization! I don't see the reason why you don't like the idea of Config packages. Can you elaborate a little more on that, please? Perhaps we need to define better what are we talking about. I see a `config package' as a package that includes/modifies other packages conffiles. Using packages for this is ignoring the concept of a package. What if you remove one of these packages? What if some programs whose files are modified are not installed? What if one of these programs is installed _after_ the config-package? Should the config-package depend on every progam it configures? config-packages will depend on changes in several packages... Maybe this requires something orthogonal to the package system. `Themes' are possible in Windows because they have a central database for settings. My opinion is: One of the main adtvantages of having a distribution is that you get configured packages, so let's to provide a great/useful/nice/easy configuration. I'd like to have LESSOPEN configured for me when I install a distribution. -- Nicolás Lichtmaier.- -- 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 18 May 1997, John Goerzen wrote: Be prepared to receive lots of messages saying things like unix is for real men that can look manpages set their own prompts and we shouldn't make any decision about the system's look and feel, the sysadm should... The kind of decisions that keep newbie Linux users away from Debian... I don't think Debian is really aiming at newbies. (RedHat is) Debian is aiming at the power user or admin type -- the people that already know Unix. Debian is wonderful for people like that -- you get the raw power of Unix with the most tedious tasks conveniently automated via the package manager. I don't think that we should go around changing defaults like prompts just to be more friendly to newbies. If we want to be friendly to newbies, we can write an X configurator like RedHat; but I don't think that's what we want. I don't agree. Most people that adopt Linux come from DOS. Linux is expanding the UNIX users base. I come from DOS-OS/2 too. I used Slackware, and I changed because it was a mess. Current newbies that start with RH won't change to Debian, they don't need to. And those newbies learn, become `RH-gurus' and sit quietly at home waiting for a commercial corporation to handle their OS =). I also think that we should try to aim to the bigger amount of targets that we can... So I say: PS1=[\\u] \\h:\\w\\$ =D -- Nicolás Lichtmaier.- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Libraries compiled with libc6
If got it right, ldso can remember if a library is intended for libc5 or libc6.. right? So it must be possible to have the same soname,version of a library compiled for bith libc5 and libc6 (in different directories). Am I right? If I were... what would the policy be for packaging the libraries? Shouldn't we decide a common suffix like `-l5compat' or simply `-compat'? -- Nicolás Lichtmaier.- [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: crons scripts should report status info in the mail
On Sun, 18 May 1997, Karl M. Hegbloom wrote: `The `tar` errors about stripping / are no big deal; I will 2/dev/null them. I don't know why it cannot find /etc/securetty... anyone know? The reason I want the scripts to report is so I can find out which one gives that 'shell-init' error. I've gone and added an `echo $0` to each script. Tomorrow morning I'll know which script it is. :-) That's printed by bash itself when it can't access current directory... Q: Is anyone using `autoconf`? I wonder if it's worth learning to use, and what people use it for. Only if you are planning to create a software intended for use in several platforms. -- Nicolás Lichtmaier.- [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
