Re: long list of give away or orphaned packages
>On a related note, games. Games are important. Please please please dont >reject someone who wants to package up a game. Thats one of the things I >like about debian, it has so many games. I first got mirrormagic working >under debian... And I hope to see abuse.svga working again too now that >he sources are available. Games are the best and easiest way to have your >first "real" package, and its the most exciting (for a new developer >anyways ;)) And, right on cue... Hi! I subscribed a few days ago, (and have been somewhat overwhelmed by the quantity of mail on this list; is there a digestified version?) and would like to propose that I package up Inform, Frotz, and some of the associated games. Some background: In the '80s, Infocom produced a lot of excellent adventure games, and they published them all in portable, completely architecture-independant 'story files'. When you bought the game, you got an interpreter and a story file, (although you normally didn't know that). Since then, various people have decyphered the story file format and produced a compiler (Inform) to generate these files, and interpreters (Frotz being one) to play them. If we had Frotz, it would be simple to package up a large(ish) number of the games available. I suspect a lot of the games would have to go in contrib, as they don't have their Inform source with them, and Inform itself would have to be non-free, 'cause it has restrictions on profit-making. I think Frotz could go in the main distribution, but I'll have to check on that... Oops, no: "Frotz is freeware: It may be used and distributed freely provided no commercial profit is involved. (c) 1995, 1996 Stefan Jokisch." So, is anyone else working on any of this already? Good/bad idea? How should I go about approaching the authors to ask them to change the licences for these programs (if I should, if fact, do that)? Thanks, --Charles Briscoe-Smith PGP key fingerprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 White pages entry, including PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: deleting binary soft link on ftp sites
Guy Maor <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] writes: > >> In anticipation of Debian being released (publically)for platforms >> other than ix86 it would be a good idea to phase out the use of >> the binary -> binary-i386 link on the ftp sites as this could >> cause confusion. Is there anything that actually uses this link? > >Very old versions of dselect use it. It's meant for backwards >compatibility. Are these the same versions which have problems with Packages files with epochs in them? If so, might removing these links help avoid problems, by forcing them to install the latest dpkg by hand? --Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- 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
Tom Lees <[EMAIL PROTECTED]> wrote: >Ctrl+PrintScreen (=SysRq) should do a kernel info thing. Have you heard of the GGI project? One of the things they have is a SAK (secure attention key), which is guaranteed to kill all processes running on the current VC. The key they're using at the moment for SAK is SysRq. (The idea is so that you can kill hung X servers and so on, and be sure that you've got a real login prompt, not a spoof.) While GGI isn't in the 'real' kernel yet, and probably won't be ready for a while, it might not be a good idea to assign some other meaning to the key it'll be using... >What about W95 keys (3 of them)? Define as F20 or something? I heard it suggested that someone should get some keytops printed with little penguins and then sell pairs of them to Linux users with Win 95 keyboards... ;-) --Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- 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
=?iso-8859-1?Q?Nicol=E1s_Lichtmaier?= <[EMAIL PROTECTED]> wrote: > One package with misc/general manpages and another with development >manpages. What do you think? I think that (at least) the "undocumented.?" pages should go in a separate package, or even back into the man-db package. I don't have manpages installed (because they're big), so whenever man regenerates its database, I get warnings about bad symlinks from any packages which use "undocumented". --Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Proposed new virtual package: zcode-interpreter (long)
Hi all, I've been putting together a few packages of Z-code stuff, following my previous posting, and want to use a virtual package, `zcode-interpreter'... I'd like to put the appropriate man-page before you all for approval. (It describes the use of the virtual package, among other things.) I haven't got a master account yet, so I can't upload them, but the packages are at ftp://pcsw104b.ukc.ac.uk/pub/cpb4/> in case anyone wants them. Thanks, --Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 UPDATE-ZCODE(1) Debian GNU/Linux UPDATE-ZCODE(1) NAME update-zcode - install or remove Z-code interpreters or story files SYNOPSIS update-zcode -add -interpreter -type type command [argu- ment...] update-zcode -remove -interpreter command update-zcode -add -storyfile storyfile gametitle update-zcode -remove -storyfile storyfile DESCRIPTION update-zcode is used to change the system's idea of what Z- code interpreters or Z-code story files are available. The list of available Z-code interpreters is used by zcode- interpreter(1) to pick a suitable interpreter for the current environment. The list of installed story files is used to generate menu entries for currently available games. If update-zcode is invoked with access permissions suffi- cient to modify the system-wide configuration files, then the modifications will be performed on a system-wide basis. Otherwise, the modifications will only affect the current user, and will update configuration files in the user's home directory. If is the caller's responsibility to call update-menus(1L) where appropriate, to ensure that changes to the installed Z-code story files are correctly reflected in the menu sys- tem. OPTIONS -add -interpreter Record that a new interpreter is available for use. The keyword given as the type argument specifies the environment this interpreter will run in; currently, this must be either x11 or text. When the interpreter is invoked, the command line will be formed from the command and arguments, with the name of the story file to execute appended. -remove -interpreter Record that an interpreter is no longer available on the system. The command given should be identical to the command (but without the arguments) used to ini- tially record the availability of the interpreter. -add -storyfile Record that storyfile is available for use. The gametitle given will be used to generate a menu entry for this game. -remove -storyfile Record that storyfile is no longer available on the system. The storyfile given should be identical to the storyfile used to initially record the availability of the story file. INTERPRETERS When an interpreter is invoked with a non-absolute story file name, it should search for the file in the current directory, and then along the path given in the environment variable ZCODE_PATH. (To support existing interpreters, zcode-interpreter will place the same path information in the environment variable INFOCOM_PATH.) zcode-interpreter will add the standard directories (see the section ``FILES'') to the Z-code path, so it is not necessary for interpreters to search these in addition to ZCODE_PATH. Each package containing a Z-code interpreter should o after installation, call update-zcode -add -inter- preter ... o before removal, call update-zcode -remove -interpreter ... o have the interpreter configured to search for story files along ZCODE_PATH if the story file is otherwise not found. (If ZCODE_PATH is not searched, it should search INFOCOM_PATH instead.) o provide the virtual package zcode-interpreter, and o depend on zcode-support (the package containing the actual zcode-interpreter(1) command.) STORY FILES Each package containing a Z-code game should o after installation, call update-zcode -add -storyfile ... o before removal, call update-zcode -remove -storyfile ... o place the story fileinthedirectory /usr/lib/games/zcode, o depend on zcode-interpreter. FILES $HOME/.zcode-support/ Contains per-user configuration files. /etc/zcode-support/ Contains system-wide configuration files.
Re: Status of Debian Policy
[EMAIL PROTECTED] (Fernando) wrote: >Author: name and email of main upstream author (copyright holder) >License: code describing license type >Original-Site: site/URL at which the package is originally stored Yes. >We could even go further and specify the type of non-free license. >Common types are: >[...] >Shyware: free use and redistribution of binaries, sources not available > because author considers them still alpha. > >I don't think there are many more types. The precise terms should be available >in the "copyright" file, but since most packages would fall in one of >the previous categories, it would be really useful to have that shown >in a concise way before installing a package. There are also programs that fit this 'shyware' definition, but where the author doesn't consider the source code to be 'unfit' -- they just want to keep source to themselves. This usually seems to be for 'artistic' reasons... (justified or not...) I've come across this sort of license quite a lot recently, while trying to package up some of the adventure games from ftp.gmd.de -- the author doesn't give out source because he doesn't want you to be able to 'cheat' easily. For these games, porting is not an issue, because they are run using an interpreter, and the interpreter source is available. Bugs are handled by the upstream author, and in any case are not usually serious, by which I mean they don't usually affect anything other than the game player's enjoyment. If they crash the machine, it's the interpreter's fault, not the game's. I'm not saying that anyone -should- keep their source secret (quite the opposite), but it does happen. --Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Package priorities and dependencies.
Santiago Vila Doncel <[EMAIL PROTECTED]> wrote: >I think libraries should not need priorities (or they need them much less >than ordinary program packages). So if they have more or less priority, I >really don't mind. Go ahead. I have a suggestion for libraries: most users don't want or need to know about shared libraries when installing and upgrading their system, or when adding an app etc. There should be a flag, similar to "Essential: yes" -- perhaps "Internal: yes", which would be noticed by dselect. The user could then ask dselect to 'hide' all internal packages. This would mean that they wouldn't clutter up the dselect packages list, they would be selected -quietly- when a depending package is selected (not forcing a trip to the dependencies screen), and they might even be automatically marked for removal whenever no more packages depend on them. Of course, there must be a way to switch off this behaviour and make all packages visible, just as it's possible to override dependencies. If you think about it, there's really no reason to select a shared library package by hand; if you want a binary that uses it, it'll depend on it; if you want to build against it, you install the -dev package (which depends on it). The only time you really want to select it by hand is when another package had faulty dependencies, or when you're installing a non .deb'ed binary. What do you think? --Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
GNU stow
Hi, I hope no-one minds that I've gone ahead and dome this without asking first... I've packaged GNU stow 1.3.2. This may not sound useful, it being another package management system, but I find it pretty useful to manage my /usr/local directory, so there it is. It's at ftp://pcsw104b.ukc.ac.uk/pub/cpb4/>, and I will upload it as and when. Incidentally, there's a package there called 'curses', and I just realised it might get confused with the UNIX curses (which it has nothing to do with). I will rename it. Finally, I'm looking at GSPreview (similar to ghostview) and UPS (the graphical debugger) with a view to packaging them. Anyone else working on these already? --Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
Santiago Vila Doncel <[EMAIL PROTECTED]> wrote: >On Mon, 16 Jun 1997, Brian C. White wrote: > >> August 31, 1997 All packages depending on libc4 or libc5 will be removed. > >This is too much strong. I would suggest to make their associated bug >(the one saying "it's still libc5") "almost-critical" instead. How about this: Have the policy dictate that no packages may be compiled against libc4/5, and then move any packages that don't comply with the policy to 'contrib'. I believe that one of the reasons for having 'contrib' is to contain packages that we -could- distribute, but which don't fully comply with Debian policy? Simply to get the package back into the main distribution might be enough incentive to get packages rebuilt against libc6. Any obscure packages that missed getting rebuilt would end up under contrib. In fact, just moving libc4 and 5 to contrib would force any depending packages to go in contrib, too, without having to change policy. --Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Proposal to package propsel
I just saw this on c.o.l.a. and want to package it: Title: propsel Version:27-Nov-1997 Entered-date: 27-Nov-1997 Description:propsel is for people who work with more than a single X11 display on their desk. It allows one to paste into a xterm on one display the contents of the selection of another display. Keywords: selection, X11, multi Author: [EMAIL PROTECTED] (Amit Margalit) Maintained-by: [EMAIL PROTECTED] (Amit Margalit) Primary-site: ftp://hishome.net/pub/propsel/ Alternate-site: N/A Original-site: N/A Platforms: gcc, X11R5. Copying-policy: GPL Any objections? Thanks, -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal to package propsel
Steve Dunham <[EMAIL PROTECTED]> wrote: >You might want to take a look at x2x also. It passes selections and >allows you to use one mouse and keyboard with both displays. > > ftp://gatekeeper.dec.com/pub/DEC/SRC/x2x/x2x-1.26.tar.gz Thank you! That is one NEAT program. At first glance, I thought it subsumed the functionality of propsel, but I think there's room for both in the distribution. Expect packages soon! -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: `COAS'
Behan Webster <[EMAIL PROTECTED]> wrote: >[Anon wrote:] >> Perhaps Diety should become a part of that? > >*sigh*... not diety, Deity. > ^^ Diety, of course, meaning "of or like a diet". In the same vein as "boxy". At least, that's what I think every time someone spells it like that. :-) -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: gated
In article <[EMAIL PROTECTED]>, Sten Anderson <[EMAIL PROTECTED]> wrote: >Craig Sanders <[EMAIL PROTECTED]> writes: >> >> - download the gated sources (using wget or lwp-request or snarf or an >>ftp script) > >Very bad idea. Some of us are behind a firewall that makes it >difficult to use standard ftp tools. Invoking ftp from an >installer script would only cause trouble. It should instead be done >like the nescape installer package where the software is downloaded >manually to a tmp dir. But there should be nothing wrong with providing for an -optional- automated download? Perhaps try to do the download if the script doesn't find a copy already downloaded? -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Can I stay current using source packages instead of binaries?
In article <[EMAIL PROTECTED]>, Brian K Servis <[EMAIL PROTECTED]> wrote: > >This is a VERY interesting concept. I would think that this could >even be applied to the binaries. Since much of the changes are to >text based config files or the Debian control files. I envision a >patch based upgrade for the Debian revision updates. Just update the >files that have actually changed, and then update the dpkg status >files to reflect the upgrade. Of course if there is a binary update >then that would be included in the update package. This would be a >huge savings for those of us who live off of dpkg-ftp over a dialup >connection. Has this been discussed on debian-devel? I think someone suggested it. Was it Jim Pick? ISTR the idea was to use an rsync-like algorithm to generate the binary patches. -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proxy server policy [was Re: gated]
In article <[EMAIL PROTECTED]>, Jason Gunthorpe <[EMAIL PROTECTED]> wrote: > >Well, http is pretty simple, it's either authenticated or unauthenticated >HTTP proxy protocol. There should be a way to specifiy for which hosts it >applies to.. You could also do HTTP over socks4/5 but that's a bit silly. > >FTP is difficult, there is at least: > ftp over http > ftp over [EMAIL PROTECTED] > ftp over site > ftp over ?? [I forget this one] > ftp over NAT (passive) > ftp over socks4 and socks5 > >Many of those have authenticated versions as well and all should have a >way to specify which addresses apply. We have an ftp cache here which seems to be accessed differently from any of these (unless I misunderstood you). You ftp to the cache, login anonymously, and cd to a particular directory. So to get to ftp.debian.org: ftp ftpcache login: ftp password: cd /sites/ftp.debian.org/pub/debian ls ...and so on. I'm not sure that you can ever have a scheme that will work for -all- the wierd and wonderful proxies, caches and firewalls out there. (This cache is something that was knocked up locally, I think. It's integrated with the HENSA mirrors, but fetches updates to individual files on demand, too.) -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: [PGP]: can someone in NYC sign me?
In article <[EMAIL PROTECTED]>, Alex Yukhimets <[EMAIL PROTECTED]> wrote: >Just one question to the "public": is it OK to take a floppy with his >public key, sign it without his phisical presence and than e-mail >him the signed file back (encripted with his key)? Make sure you see some physical identification (driver's licence, passport or similar). If you know who the person in front of you is, and he gives you a key, you can check it's his by looking at the ID on the key and checking the ID's signature. Once you've signed it, there's no reason to encrypt the result. You could upload it to a keyserver yourself, in fact. Actually, encrypting the signed key might be a good idea, because it'll ensure that the signed key won't be released to the world unless the holder of the secret key wants that to happen. (I -think- I've understood the issues correctly. Tell me if I'm wrong, people!) Also, I'm pretty sure there's a section in the PGP manual about how to organise meetings to sign the keys of people you haven't met. That's more authoritative than me. -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: [PGP]: can someone in NYC sign me?
In article <[EMAIL PROTECTED]>, Alex Yukhimets <[EMAIL PROTECTED]> wrote: >Just one question to the "public": is it OK to take a floppy with his >public key, sign it without his phisical presence and than e-mail >him the signed file back (encripted with his key)? Make sure you see some physical identification (driver's licence, passport or similar). If you know who the person in front of you is, and he gives you a key, you can check it's his by looking at the ID on the key and checking the ID's signature. Once you've signed it, there's no reason to encrypt the result. You could upload it to a keyserver yourself, in fact. Actually, encrypting the signed key might be a good idea, because it'll ensure that the signed key won't be released to the world unless the holder of the secret key wants that to happen. (I -think- I've understood the issues correctly. Tell me if I'm wrong, people!) Also, I'm pretty sure there's a section in the PGP manual about how to organise meetings to sign the keys of people you haven't met. That's more authoritative than me. -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proxy server policy [was Re: gated]
Jason Gunthorpe <[EMAIL PROTECTED]> wrote: >On 10 Dec 1997, Charles Briscoe-Smith wrote: >> ...and so on. I'm not sure that you can ever have a scheme that will work >> for -all- the wierd and wonderful proxies, caches and firewalls out there. >> >> (This cache is something that was knocked up locally, I think. It's >> integrated with the HENSA mirrors, but fetches updates to individual >> files on demand, too.) > >Yes, this is most unusual. If it was created locally I would suggest you >use something more 'normal' for instance: [...] Knocked up locally, but not by me, I'm afraid. And since it now certainly has hundreds (or maybe thousands) of users, I suspect it would be impractical to change it now... My point was simply that there are sure to be many different proxy configurations, so you can't hope to support all of them out of the box. It might well be possible to support all the popular ones, but there ought to be a way of customising for strange setups like ours. -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proxy server policy [was Re: gated]
Jason Gunthorpe <[EMAIL PROTECTED]> wrote: >On 10 Dec 1997, Charles Briscoe-Smith wrote: >> ...and so on. I'm not sure that you can ever have a scheme that will work >> for -all- the wierd and wonderful proxies, caches and firewalls out there. >> >> (This cache is something that was knocked up locally, I think. It's >> integrated with the HENSA mirrors, but fetches updates to individual >> files on demand, too.) > >Yes, this is most unusual. If it was created locally I would suggest you >use something more 'normal' for instance: [...] Knocked up locally, but not by me, I'm afraid. And since it now certainly has hundreds (or maybe thousands) of users, I suspect it would be impractical to change it now... My point was simply that there are sure to be many different proxy configurations, so you can't hope to support all of them out of the box. It might well be possible to support all the popular ones, but there ought to be a way of customising for strange setups like ours. -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
[From debian-doc] C-A-D entry in inittab
In article <[EMAIL PROTECTED]>, Enrique Zanardi <[EMAIL PROTECTED]> wrote: >On Wed, 10 Dec 1997, Thalia L. Hooker wrote: > >> I wonder if it is a good thing to tell users that they can also use >> ctrl-alt-del to also shutdown their system? Suppose the user doesn't >> remember whether they set up their system for C+A+D. It seems that they >> would do more harm to their system by trying C+A+D if the event they had >> not set this option. Alternatively, is there a way that users could tell >> whether they have set this option? If so, then you could perhaps mention it >> in this section. > >It's defined in /etc/inittab . >In a "default" Debian installation it looks like this: > >[...] ># What to do when CTRL-ALT-DEL is pressed. >ca:12345:ctrlaltdel:/sbin/shutdown -t1 -h now >[...] According to /usr/doc/sysvinit/examples/inittab on my system, it's actually: ca:12345:ctrlaltdel:/sbin/shutdown -t1 -r now ^ But I've changed the -r to -h as well... Should this perhaps be the default, together with an echo 'Press CTRL-ALT-DEL again to reboot.' at the end of the shutdown script? Doing this means you can shut down easily, without having to remember to turn it off quickly after the reboot starts, but before the machine comes back up again. -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: package pre-selections tool
In article <[EMAIL PROTECTED]>, Steve Dunham <[EMAIL PROTECTED]> wrote: [...] >Finally, it installs all the selected packages without asking the user >20 times in a row if they prefer XV (or which dictionary they prefer). [...] >(The dictionary issue isn't as important since fewer people install >English, German and French dictionaries.) (But even if you only install one dictionary, it'll still ask you a question.) The other wordlist package maintainers and I have been discussing this for a while now. We're going to move over to using update-alternatives for Debian 2.1 -- it's really too far into the freeze now to do it for 2.0. For now, all the wordlist packages are being updated to use some slightly more intelligent scripts. When people upgrade bo -> hamm, they will get asked which dictionary they want to be the default, but after that, all further upgrades should be questionless. If you want to have a script install these packages without questions, (let's say you want to make wenglish the default dictionary) first make the symlink /etc/dictionary -> /usr/dict/english, then install the package. Just make sure you unpack the package containing the file /etc/dictionary points to before any of the other dictionaries get configured, though, otherwise the 'broken' symlink will be moved out of the way! Hope this helps, -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: elvis package
In article <[EMAIL PROTECTED]> you write: >On Fri, 17 Apr 1998, Martin Schulze wrote: > >> This might look confusing but the situation is different as >> the author of vile is aware of the unfreeness and distributes >> new parts under the GPL. >> >> "the bulk of vile _cannot_ be covered by the GPL due to murky origins and >> previous copyrights. however, the code that i have written (and i suspect >> this is true of contributions made by others as well) was written to be >> published, and to be shared with others. please respect this. see the top >> of main.c for the restrictions put on the original MicroEMACS code upon >> which vile was based." [...] > >I am not a license expert, but from the GPL I understand that if you make >modifications to a program and you put the modifications under GPL, you >have to put the entire program under GPL, no matter what the original >license was. If the license of the original program doesn't allow this, >you get an undistributable program. > >Can any license expert comment on this? I'm not a licence expert either, but I have seen lots of discussion about the effects of various licences both here and on usenet. ;-) I'm pretty sure that a program must be either entirely GPLed, or contain no GPLed parts. The only way around this would be to separate the GPLed and non-GPLable code into separate programs with a well-defined, documented interface, and even then it would likely still be controvercial. The whole point of the GPL is to ensure that you can't integrate non-GPLed parts into GPLed programs or vice-versa. There was some discussion about a related issue on gnu.misc.discuss when the NPL was being drafted. RMS wanted a clause in the NPL to allow NPLed code to be converted to GPLed. This didn't materialise, thus it's now illegal to incorporate GPLed code into Mozilla and distribute the result. -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package moxa radius
In article <[EMAIL PROTECTED]> igor wrote: > >I intend to package up Moxa radius, a fully-featured radius server package. >It has some of the features that are not available in any of freely available >radius's that debian contains, such as proxy support. I found it accidentally >on the net, and at that point it had no license at all. I contacted the >authers, and convinced them Free Software is The Way (tm). This is a first >one for me, so I am very proud of myself ;-). You can find it at >ftp.moxa.com/drivers/cn2000/radius.2.2.tar.Z . I am not sure if that one has >a new license yet, but here it is: > >/* = > * Copyright (c) 1998 Moxa Technologies Corp, LTD. All rights reserved. [...] > * 3. All advertising materials mentioning features or use of this > *software must display the following acknowledgment: > *"This product includes software developed by the Moxa Technologies > *Corp, LTD. for use in the Moxa RADIUS Server (http://www.moxa.com/)." Urk! It's the Obnoxious BSD Advertising Clause, back to haunt us. Including the OBSDAC would make Moxa non-free. Please educate them about that, too, and suggest they use an XFree86-like licence rather than this BSD-like one. Thanks, -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package moxa radius
In message <[EMAIL PROTECTED]>, Igor Grobman writes: >> In article <[EMAIL PROTECTED]> igor wrote: > >a new license yet, but here it is: >> > >> >/* = >> > * Copyright (c) 1998 Moxa Technologies Corp, LTD. All rights reserved. >> [...] >> > * 3. All advertising materials mentioning features or use of this >> > *software must display the following acknowledgment: >> > *"This product includes software developed by the Moxa Technologies >> > *Corp, LTD. for use in the Moxa RADIUS Server (http://www.moxa.com/)." >> >> Urk! It's the Obnoxious BSD Advertising Clause, back to haunt us. >> >> Including the OBSDAC would make Moxa non-free. Please educate them ^ My mistake; I didn't reread the DFSG before posting. Sorry for the FUD. >> about that, too, and suggest they use an XFree86-like licence rather >> than this BSD-like one. > >I don't understand. We haven't declared all BSD software non-free yet, have >we? How come moxa doesn't fit the bill. It has the exact same clause. I >seem to remember a long discussion on -devel, but didn't we conclude that this > >BSD clause doesn't make software non-free? > >Anyway, could you explain to me how this advertising clause is so harmful? I don't remember any prior discussion of this on debian-devel -- so it was probably before I joined Debian... For the full rant, you should probably read RMS's recent article in gnu.misc.discuss; subject "What's Wrong with the BSD License", message-id <[EMAIL PROTECTED]> The gist is this: most of the "obnoxious" advertising clauses in BSD-ish software specify a different sentence which must be mentioned on advertising mentioning the software. This means that if I build a distribution with lots of BSD software in it, there are likely to be a lot of different sentences I must include on my advertisements (or I must restrict myself as to how many features I mention in any one advertisement, so as to reduce the number of sentences I must include). RMS says he counted 75 different sentences in one of the BSD distributions. I've just looked over the DFSG again, and I can't see any restriction against using an Obnoxious BSD Advertising Clause, so its presence does not make the software non-free. Sorry for spreading FUD. However, I think if you can, you should try to get the licence changed to be more XFree86-ish and less BSD-ish, and thus help prevent the problem spreading. -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: elvis package
In message <[EMAIL PROTECTED]>, Raul Miller writes: >Charles Briscoe-Smith <[EMAIL PROTECTED]> wrote: >> I'm pretty sure that a program must be either entirely GPLed, >> or contain no GPLed parts. > >More precisely, the non-gpled parts must not have terms which prevent >compliance with the gpled parts. Before they are incorporated into the GPLed program, yes, but not afterwards. Please read the "viral clause" of the GPL, clause 2(b): You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. Note "this Licence", not "a licence which does not have terms which prevent compliance with this Licence". Thus, as I read it, to be distributable, any program must be either GPLed in its entirety, or contain no GPLed parts. I'm not a law professional, though, and I don't know how compilation copyright interacts with this. Compilation copyright may justify your position; it might be the case that the licensing of the whole can be different from the licensing of its parts. -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Intent to package libggi-dynamic
(I mentioned this before, but at the end of another thread which you probably didn't read...) I intend to package libggi-dynamic, a 2d graphics library which provides a common front-end for doing 2d drawing via KGI, svgalib, xlib, aalib and others, or several at once. -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On adding size info to Packages files [very long]
In message <[EMAIL PROTECTED]>, Brederlow writes: > >Would that already be a correct Packages file or would dpkg and >similar scream about wrong entries? Could old dpkg's handle the new >entries? It seems to work for me. Any entries that are not recognised are ignored or passed through unchanged. >Theres another possibility: >Normal users wont backup their System, repartition differently and >restore the backup (at least not often). Also they wont move >directories around and link them often. We could thus trimm the du >tree down to what the current system reflects. In case the user does I don't think this will gain much... It's probably easier to separate the size information from the packages file; after all, it isn't needed either during normal operation or when removing packages, only when you're installing new packages. The rest of the time it needn't be kept locally. -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On adding size info to Packages files [very long]
Manoj Srivastava writes: >I think we should look at the possibility of not including the > information in either the Packages file nor the available file. The > Du files hsould be separately kept on the archives, and they maybe > compressed with gzip (bzip2?); and downloaded and kept in > /var/lib/dpkg/DU.gz or something on the users machine; and they need > only be downloaded if required by the user. Keeping this information > separate makes using this optional. > >I see no technical advantage encoding this in Packages files > and available file. Hmm... $ for x in main contrib non-free; do > gzip -cd Packages.hamm.$x.du.gz \ > | sed -n '/^Package:/p;/^Du:/,/^$/p' \ > | gzip -9n > Sizes.hamm.$x.gz > done $ gzip -l Sizes.hamm.*.gz compressed uncompr. ratio uncompressed_name 105201795450 86.7% Sizes.hamm.contrib 66294402982 83.5% Sizes.hamm.main 11446 63766 82.0% Sizes.hamm.non-free 182941 1262198 85.5% (totals) $ gzip -cd Sizes.hamm.main.gz | head -15 Package: 2utf Du: 3 etc 1usr 111 usr/bin 1usr/doc 8usr/doc/2utf 25 usr/doc/2utf/examples 1usr/man 5usr/man/man1 1var 12 var/lib Package: 3dchess Du: 1 usr 1usr/doc Looks reasonable... In practice, this information is only going to be used while installing packages, and 180K isn't much anyway. We could save far more space by compressing the available, available-old, status and status-old files (2.5Mb on my system). >We have conflicting data here. Mrvn says that the total du > data is only 76k. Charles says that the data is about 400k (which is > way more in line with my off the cuff calculations). The 400K was for normal hamm Packages files with additional Du data added to it. That makes my numbers far closer to Mrvn's. Also, weren't Mrvn's figures were for main only? >I am inclined to believe the 400k figures. I would, for > scalability reasons, advocate that we re run our scripts on a _ful__ > i386 mirror (which I do not have at the moment -- ran out of space). I generated my data from unix.hensa.ac.uk's mirror. >I also would strongly advocate *NOT* stuffing this data into > the Packages or the Available files, but keeping this apart on the > archive and when downloaded on the users disk. I'm now with you on this one. Given the sizes involved, I don't think we even need to go to the trouble of generating the "top N levels" versions. Using this would make it difficult to take symlinks into account. -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to fix a broken postrm in upcoming releases
On Fri, May 15, 1998 at 02:20:45PM +0100, I wrote:
> I posted some skeleton p{re,ost}{inst,rm} scripts to debian-mentors (or
> was it debian-doc?) a few weeks ago; I'll post them again if you like.
> I think they do a pretty good job of outlining all the possibilities you
> can code for, but in a more easily digestible form than the packaging
> manual's description.
Okay, I've been asked for them. I have made some updates since last
they were posted...
--
Note that most of the activities of your maintainer scripts need not
be conditionalised on the script's parameters. You probably won't need
these skeleton scripts unless you're doing something tricky.
Some general points relevant to writing all maintainer scripts:
- Trap all errors.
- Don't generate any unnecessary output.
- Return an exit status of zero if you succeed, non-zero if you fail.
- Be idempotent: make sure nothing bad will happen if the script is
called twice where it would usually be called once.
- Remember the standard input and output may be redirected (e.g. into
pipes) for logging purposes.
Prompting should whenever possible be confined to the case when the
postinst script is called with the argument "configure":
- If you have a vitally important message to show the system administrator
(NOT the end user) the postinst should display it, then wait for return
to be pressed.
- Prompt the user only for the minimum possible information.
- Never prompt for the same information twice, unless the information
has been purged since last collected.
- If you prompt for a password, do full-screen interaction, or the like,
use /dev/tty for these things, not standard input/output.
The POSIX shell `:' command is used in the skeleton scripts to comment
out example commands which are only needed in some packages, and to
indicate where your commands could go.
Generally, try to confine most activities to the postinst and prerm
scripts. Be careful if you put anything unusual in the preinst or postrm,
because the package's dependencies may not be installed when they are run.
Lastly, note that, in dpkg-speak, an 'upgrade' may be to any version of
the same package, even the same version or a previous version. Thus,
the 'upgrade' cases of the scripts are used even when reinstalling a
package over the top of the same version of itself, or when downgrading.
--
#! /bin/sh
# preinst.skeleton
# Skeleton maintainer script showing all the possible cases.
# Written by Charles Briscoe-Smith, March-June 1998. Public Domain.
# Abort if any command returns an error value
set -e
# This script is called before this version of this package is installed.
# When this script is called, the package's files have not been unpacked
# yet.
case "$1" in
install)
# About to install this package.
:
# Add a diversion. This is one of the few things which may be done
# before installing any files from the package.
: dpkg-divert --package foo --add --rename \
: --divert /usr/bin/other.real /usr/bin/other
# There are two sub-cases:
if test "${2+set}" = set; then
# The configuration files from version $2 of this package are
# still on the system.
:
else
# There is no existing configuration; install from scratch.
:
fi ;;
upgrade)
# About to upgrade this package from version $2 TO THIS VERSION.
# "prerm upgrade" has already been called for the old version of
# this package.
:
;;
abort-upgrade)
# Back out of an attempt to upgrade this package FROM THIS VERSION to
# version $2. Undo the effects of "postrm upgrade $2".
:
;;
*) echo "$0: didn't understand being called with \`$1'" 1>&2
exit 0;;
esac
exit 0
--------------
#! /bin/sh
# postinst.skeleton
# Skeleton maintainer script showing all the possible cases.
# Written by Charles Briscoe-Smith, March-June 1998. Public Domain.
# Abort if any command returns an error value
set -e
# This script is called as the last step of the installation of the
# package. All the package's files are in place, dpkg has already done
# its automatic conffile handling, and all the packages we depend of
# are already fully installed and configured.
# The following idempotent stuff doesn't generally need protecting
# against being run in the abort-* cases.
# Install info files into the dir file
: install-info --quiet --section "section pattern" "Section Title" \
: --description="Name of the document" /usr/info/foo.info
# Create stub directories under /usr/local
: if test ! -d /usr/local/lib/foo;
Bug#142235: O: x2x -- Link two X displays together, simulating a multiheaded display
Package: x2x Version: 1.27-6 I no longer have the time or the inclination to maintain x2x. I've just fixed a quick imake bug and orphaned it. A previous NMU'er has helpfully debhelperised the package for you. -- Charles Briscoe-Smith Hacking Free Software for fun and profit "When you do things right, people won't be sure you've done anything at all." -- God, Futurama ep. 3ACV20, "Godfellas" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with javalex
Hamish Moffatt <[EMAIL PROTECTED]> wrote: >On Sat, Jun 13, 1998 at 12:03:34AM +0200, Martin Schulze wrote: >> I'd like to receive some help. The program gets called with the >> following command >> >> /usr/bin/java JavaLex.Main $* >> >> The main problem is that there is no JavaLex.Main file. It is not >> included in the .tar.gz nor in the .diff.gz file and it isn't >> generated when the program gets compiled. > >The class name is "Main", which would be in Main.class, part of >package JavaLex. /usr/bin/javalex adds /usr/lib/javalex to the >classpath, and /usr/lib/javalex has Main.class, which should work. > >Still, I can't get it to work. Main.class should be installed as /usr/lib/javalex/JavaLex/Main.class because, for each CLASSPATH component, the JVM looks in CLASSPATHCOMPONENT/PACKAGENAME/CLASSNAME.class and in this case, CLASSPATHCOMPONENT = /usr/lib/javalex PACKAGENAME = JavaLex CLASSNAME = Main >I think removing it would be best. To project/orphaned? Probably best. It also includes a non-free bug-fixed version of Sun's BitSet class (search for "NON-COMMERCIAL" in Main.java), so it shouldn't be in the main distribution anyhow. I'll file a bug to that effect, if there isn't one already. BTW, I'm working on a Java->C compiler. If I ever get it done, it might produce a better/more reliable result when compiling tools like this... which then also wouldn't reply on a JVM. I might wind up using JLex and CUP in my compiler anyway; in that case, I could take over maintanence of the javalex package. (Due to Sun's lawyers, JavaLex is now called JLex instead. See http://www.cs.princeton.edu/~appel/modern/java/JLex/>) -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Including non-PIC code in a shared library?
Hi,
I finally got packages of libGGI built and uploaded. I was quite pleased
to find that the generic debian/rules that I've been using for the last
9 months really -does- work correctly for multiple binary packages.
I always thought it would, but never had a multi-binary package to try
it on. ;-)
But, to the point. LibGGI has various display "targets", each
of which is kept in a separate *.so file under /usr/lib/ggi/.
The problem is that the "xf86dga" target contains code linked in from
/usr/X11R6/lib/libXxfs86{dga,vm}.a. This code in compiled non-PIC, and
lintian complains about it; that's why the xf86dga target is missing in
the current release, ICYWW.
I asked about this on ggi-devel, and the responses I got indicated that
it probably wasn't a problem, because there would only ever be one
libGGI program running the xf86dga target at once on a given machine
(not true for multi-headed machines) and that if multiple copies were
run, the kernel would simply load multiple copies of the code. I'm a
little worried that mixing PIC and non-PIC code might do some other harm.
Does it? Or will it just make this "shared" object unsharable?
Thanks,
--
Charles Briscoe-Smith
White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4>
PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Including non-PIC code in a shared library?
In article <[EMAIL PROTECTED]> you write: >Everything I've ever heard suggests that the GGI people are correct---it >will merely be unshareable because the pages all get "dirtied" doing fixups >on the absolute addresses. Thanks! I'll include the xf86dga target in the next release, then. -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Does anyone use virtual-dev? (was Re: updated vs. bdflush -- which is better?)
In article <[EMAIL PROTECTED]>, Avery Pennarun <[EMAIL PROTECTED]> wrote: >Pavel Machek recently extended the bdflush package to efficiently handle >hard disk spindown for power saving mode. I played with the changes, and it >seems to work really well. Some time ago, I made a package called "virtual-dev", which was supposed to help keep the hard disk spun down. (It works by putting /dev on a ramdisk.) More recent kernels, however, seem to be pretty good at avoiding accessing the disk without any outside help, so "virtual-dev" seems to be redundant already -- with things like the enhanced bdflush Avery mentions, I would expect it to become even more so. So I'd like to ask: does anyone actually use virtual-dev? If not, I'll ask that it be removed from the archive. -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
What's a suitable terminal type for xvt?
Some time ago, xterm's terminal emulation changed, and the "xterm" terminfo entry changed with it. Since xvt implements the emulation associated with the old version of xterm, I changed its terminal type to "xterm-old". Of course, this means that, when logging in to other kinds of machines, the terminal type isn't recognised. However, I noticed recently that xterm now uses "xterm-debian" as its terminal type (because of a complaint from a colleague that it wasn't recognised by any other machines!), and that "xterm-old" seems to be the same as "xterm". Is this true? When was this changed back? Should I change xvt back to "xterm"? Are there plans to muck about with this again in the future that I should know about? Thanks, -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
Re: What's a suitable terminal type for xvt?
Branden Robinson <[EMAIL PROTECTED]> wrote: >On Sun, Oct 04, 1998 at 03:33:27PM +0100, Charles Briscoe-Smith wrote: >>[what's happening with the xterm terminal types?] > >Please read /usr/doc/xbase/README.Debian and see ><http://master.debian.org/~branden/xsf.html>. Of course, I should've looked there first. Thanks. I've changed xvt's terminal type back to "xterm". -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
Intent to package: GramoFile
I just rediscovered GramoFile, which was announced on c.o.l.a. a while ago. It's a program for filtering the sound from a gramophone record to make it suitable for recording onto a CD. I've packaged it, and will upload it shortly unless I hear otherwise. -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
Uploaded new package: yada
looks for "Document:" tags within the doc-base field, splits up individual doc-base files, and calls install-docs for them each separately. * Bomb out if we see an unrecognised field in debian/packages. * "yada install -script" added (equivalent to "-bin -unstripped") to ease installing of binaries without having them automatically stripped. * Yada now elides some otherwise useless junk from debian/rules if (a) there are no build-depends or build-conflicts, or (b) there are no packages specific to particular architectures. * More error checking in the compression and symlink clean-up phases, and fixed a nasty bug therein which would corrupt any symlink with "../../" in its target string, such as "undocumented" symlinks from X11 manpage directories. * New command "yada yada", which copies or updates the yada script in your debian/ directory, and creates a skeleton debian/packages for you if you don't have one already. * Made a start writing some man pages. * Miscellaneous bug fixes. Yada's goals: - Be declarative, where possible, not imperative - Provide a way to bypass anything that yada does automatically For the future: - Support init.d scripts directly. - Integrate nicely with suidmanager. - Don't require yada installed in the package's debian/ directory. - Allow "make"-style commands in executable fields. - Rework package description handling. - Work out whether the constrained form of yada's generated copyright files is actually a Good Thing or not. - Generate rules files which don't need yada at all, either installed or in debian/. - Maybe generate rules files which use debhelper. - I'm going off the idea of "yada install". It doesn't really fit in with the rest of yada. I'll try to some up with a declarative syntax to describe file installation. - My reading Debian policy is that the files listed in 'conffiles' must be exactly every file under /etc/. If this is right, there should be no reason for 'conffiles' not to be automatically generated, with no further input. Urgh. I really ought to get on with my work now... Thanks for reading, -- Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
