Re: Future releases of Debian
On Thu, Jul 24, 2003 at 01:42:25PM +1000, Anthony Towns wrote: On Wed, Jul 23, 2003 at 06:17:25PM -0400, Matt Zimmerman wrote: Where I come from, cheap hardware is old hardware, and old hardware has much better support in Linux (and Debian) than new hardware. Where I come from, old hardware is unreliable hardware. This would really only apply to disks, which have moving parts and small tolerances. When was the last time you had a motherboard, or CPU, or network card, or a video card die because it was too old? This stuff isn't exactly perishable. It lasts long beyond its obsolescence in most cases. It's great that Debian works fine for you, but that doesn't mean everyone else can just do the exact same things you do and be as satisfied. Different circumstances, and different goals, and all that. Yep. It just means that you can't expect me to work in order to satisfy other people's needs when I don't share them. Is there any chance we can accept that Debian does have a vast range of problems (like unpredictable release schedules, a lack of security updates for testing, and a lack of currency in unstable for a fair number of packages including X), and work on fixing them rather than having to continually argue about why they're necessary to fix and why we shouldn't just sweep them under the rug and hope no one notices? Of course we can accept that Debian has a range of problems. However, complaining about them and trying to get other people to work harder, well, doesn't work. For example, you keep mentioning security updates for testing because you want me to do extra work so that you can have something you want, even though I already have more than enough to do. This isn't likely to have the desired effect. On the other hand, I'm interested in hearing your thoughts on how to release Debian more often. -- - mdz
Re: update-alternatives priorities for editors
Georg Neis wrote: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=121303 Elvis as the standard editor (priority 120) is not very convenient. Imagine a newbie thrown into elvis, and he will be lost, and cannot quit:( This bugreport says that the elvis package (a vi clone) uses a too high priority for the 'editor'-alternative (or for all alternatives?). Which changes do you propose? As I read the original bug report and apply my own spin onto it I see the original poster was concerned that a user invoking /usr/bin/editor is probably not wanting either of the traditional vi or emacs editors. They are probably a user that wants a simpler to use editor. Perhaps something more like 'nano' or 'ee' than like either vi or emacs. (Note that emacs does not supply an alternative for /usr/bin/editor.) I personally would not have had either elvis or vim supply an alternative for /usr/bin/editor. But elvis is only one of the bunch. The vim program also supplies itself as an alternative for /usr/bin/editor. Changing elvis I do not believe addresses that concern in any way unless vim is also coordinated in this action. I think there is much room for a judgement call to be made here. I am not sure what a good list of basic newbie editors would be appropriate for someone that invokes editor. Perhaps out of that list a good priority list for the alternatives could be proposed. As far as elvis being an alternative for /usr/bin/vi I think the current value is fine and I would not change it. I personally don't like the present defaults for /usr/bin/vi. But so much water has passed under the bridge that changing it now would be problematic. Bob pgppzwbiy25dc.pgp Description: PGP signature
Re: Future releases of Debian
Matt Zimmerman wrote: Anthony Towns wrote: Where I come from, old hardware is unreliable hardware. This would really only apply to disks, which have moving parts and small tolerances. When was the last time you had a motherboard, or CPU, or network card, or a video card die because it was too old? This stuff isn't exactly perishable. It lasts long beyond its obsolescence in most cases. About a year ago a venerable GeForce 256 of mine had a D/A failure causing bad video output. I neglected to recycle it and left it on the workbench. About six months ago a newer video card had the fan on it die. I was able to salvage the fan from the first and fix the second with it. Just two weeks ago another newer video card fan died. Wish I had a source for those thin pci card fans... Two cases of moving part death with a fan. One case of silicon death which was also probably a moving part if you count electromigration as the most likely cause of death there. It is not so much a question of old hardware as it is a question of being able to easily replace the hardware if there is a problem with it. I can opportunistically make use of older hardware. But I can reliably buy something new for when I need it to work. Bob pgpVCOWVeEa2g.pgp Description: PGP signature
[OT] Re: Future releases of Debian
On Fri, Jul 25, 2003 at 12:02:09AM -0600, Bob Proulx wrote: Just two weeks ago another newer video card fan died. Wish I had a source for those thin pci card fans... my school got a bunch of geforce cards with fans. all the fans died, killing all the cards. now one of the criteria the math/CS department has for buying cards is that they not have fans. -- 01CB B175 70D8 2E39 CA13 AEA6 3A2B 2219 31CD 5381 The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. check out www.fastmail.fm. fast mail, free or cheap. web + IMAP.
Re: May packages rm -rf subdirectories of /etc/ ?
On 24 Jul 2003 09:46:24 +0200, Thomas Hood [EMAIL PROTECTED] said: On Thu, 2003-07-24 at 08:47, Andreas Metzler wrote: It really sucks to handle this if you want/need to get rid of it (if it is unmodified) not only on purge but on upgrades. - You'll need if [ $1 = configure ] \ dpkg --compare-versions $2 le-nl 1.2.3 \ [ -e /etc/foo ] \ [ `md5sum /etc/foo | cut -d\ -f1` = 6bea09fbb18e4676012105fa5fc726c6 ] then echo Removing orphaned unmodified configfile /etc/foo 12 rm /etc/foo fi In a discussion that followed from this thread off-list, some people agreed that the administrator should be asked what he or she wants to do with an obsolete conffile. The conffile should not be deleted silently because other packages may be using the file. Then the other package would be in violation of policy, since until this version, the confile in question belonged to this package, and this package alone. Policy states what needs be done if packages want to share conffiles. Therefore it should be perfectly acceptable for dpkg to delete the conffile, since no other policy compliant package could be using it. manoj -- Bershere's Formula for Failure: There are only two kinds of people who fail: those who listen to nobody... and those who listen to everybody. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: May packages rm -rf subdirectories of /etc/ ?
On 24 Jul 2003 14:07:35 +0200, Thomas Hood [EMAIL PROTECTED] said: On Thu, 2003-07-24 at 13:46, Stephen Frost wrote: I see this as totally bogus. Either the conffile is shared or it isn't. If it's shared then the packages involved know this Package foo which eliminates /etc/foo.conf doesn't know that there is not some other package, bar, which Depends on foo and uses /etc/foo.conf . That's the problem. See 108587 for additional discussion. This is an impossible situation, and would place an unreasonable burden on packages that wish to remove conffiles. What needs to happen is the maintainer of such package needs to look at the reverse depends on his package, and inform the maintianers of all dependent packages that the conffile is going away. The depending packages can either do an versioned dependency on an older version of the package (which contains the conffile), or create their own, new, conffile. After all, we are all in this project together, are we not, and we can indeed communicate with each other without having dpkg or policy mediate for us? manoj -- The countdown had stalled at 'T' minus 69 seconds when Desiree, the first female ape to go up in space, winked at me slyly and pouted her thick, rubbery lips unmistakably -- the first of many such advances during what would prove to be the longest, and most memorable, space voyage of my career. Winning sentence, 1985 Bulwer-Lytton bad fiction contest. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: May packages rm -rf subdirectories of /etc/ ?
On 24 Jul 2003 15:06:59 +0200, Thomas Hood [EMAIL PROTECTED] said: On Thu, 2003-07-24 at 14:53, Stephen Frost wrote: * Thomas Hood ([EMAIL PROTECTED]) wrote: Package foo which eliminates /etc/foo.conf doesn't know that there is not some other package, bar, which Depends on foo and uses /etc/foo.conf . That's the problem. See #108587 for additional discussion. The maintainer should really know. The maintainer is more likely to know than the user in many cases. I think it would be worthwhile for policy to be modified to require notification when a sharing of this kind happens. I know that I'd expect someone to tell me if they're using a conffile from my package. If this were required in policy, then there ought to be an easy way to comply. Umm. apt allows you to determine reverse depends. From there there is an easy hop to sending email to ask the develoeprsa in question; or to exaimine a package to look at its conffiles. Perhaps that could be made to work, but it would be complex, and dpkg is already beyond the capacity of Debian to maintain properly. Developers can somehow re learn the arcane art of actually communicating with each other, as a work around. manoj -- HOORAY, Ronald!! Now YOU can marry LINDA RONSTADT too!! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Bug#201878: ITP: salonify -- Easy, configurable, compliant, and accessible web-based image gallery system
On Fri, 18 Jul 2003 10:02:05 -0500 (CDT), Adam Heath [EMAIL PROTECTED] said: How many image gallery programs do we really need in debian? Just one, the one I may package next week, Y'all can then delete all the ones you have. manoj -- You got to be very careful if you don't know where you're going, because you might not get there. Yogi Berra Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Multi-level symlinks for default kernel
Hi, On Tue, 22 Jul 2003 16:29:59 -0700, Mike Fedyk [EMAIL PROTECTED] said: Hi, I am wondering if anyone else is having the same problems I am with debian keeping the vmlinuz symlink in /. I have several systems where /boot is the only filesystem accessable by the boot loader because of software raid, or possibly lvm (haven't done this yet, but thinking about it). I regularly build my own kernels with make-kpkg, so I changed it to put the vmlinuz symlink in /boot, and changed my menu.lst file in grub to use this symlink to boot from. From man kernel-img.conf: link_in_boot Set to Yes if you want the symbolic link to the kernel image, namely, vmlinuz in /boot rather than the default /. The old, and very confusing, name image_in_boot is deprecated, since it is the symbolic link that is usually being relocated. Defaults to No. manoj -- The truth you speak has no past and no future. It is, and that's all it needs to be. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Future releases of Debian
Hi, Marco d'Itri wrote:
You keep using this flame excuse
I remember the last time this was discussed, and I believe that ESPECIALLY
when emotions tend to run high, the words we use make a difference.
We can't find a good solution to this problem, if indeed there is one, if
all we have is two rows of people on different sides of a long table,
shouting at each other.
to conveniently ignore the real question
... which others have already answered the same way I'd have.
Why say/write the same thing twice?
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
This is so cool I've to go to the bathroom.
-- Calvin
Re: Future releases of Debian
Hi, Bob Proulx wrote:
One case of silicon death
which was also probably a moving part if you count electromigration as the
most likely cause of death there.
If you do that, then _all_ deaths are the fault of moving parts...
a statement which sounds rather non-useful.
Computers run by smoke, not by electrons, anyway.
Proof: The computer dies when the smoke escapes.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
I will make you shorter by the head.
-- Elizabeth I
GPU fans (was: Re: Future releases of Debian)
On Fri, Jul 25, 2003 at 12:02:09AM -0600, Bob Proulx wrote: | I was able to salvage the fan from the first and fix the | second with it. Just two weeks ago another newer video card fan | died. Wish I had a source for those thin pci card fans... There's a computer shop near me that sells them, but since you probably don't live in Perth, Australia that is unlikely to help you. I have three Nvidia video cards that came with fans - 2 TNT2s and a Geforce 4 - in various computers. The TNT2 fans died after a few months and the cards have been running fine for close to two years (?) with the fans removed. I removed the fan on the Geforce 4 to keep the noise level down and it too seems to work fine. Cameron.
Re: Bug#201023: dosemu: purging doesmu wipes out all user data
On 21 Jul 2003 11:44:35 +0200, Thomas Hood [EMAIL PROTECTED] said: Actually we need to notice one more type of file than Emile did in http://marc.theaimsgroup.com/?l=debian-develm=105822874604492w=2 , namely, configuration files that aren't conffiles. Making the distinction above we have: 1. dpkg -L 2a. original conffiles 2b. modified conffiles 3. configuration files that aren't conffiles, in /var/lib/ Why is this not a serious bug in these packages? 4. log output, cached compiled versions of conffiles, etc. 5. user data created using the package Here is my suggestion for how purge should be handled. Purge would delete #1 through #4 _and_ everything in /var/lib/pckg/. User data created using the package must then not be stored in /var/lib/pckg/ but somewhere else, e.g., in someone's home directory. Dosemu, for example, could store the not-to-be-purged DOS image in user dosemu's home dir. umm, no. Postgres should certainly not try and store the database under /home; since the DB can grow huge. manoj -- The liberty of the press is not confined to newspapers and periodicals. It necessarily embraces pamphlets and leafletsThe press in its historical connotation comprehends every sort of publication which affords a vehicle of information and opinion. Lowell v. City of Griffin, 303 U.S. 444, 452 (1938), quoted by Mike Godwin in comp.org.eff.talk Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: May packages rm -rf subdirectories of /etc/ ?
On Fri, 2003-07-25 at 07:59, Manoj Srivastava wrote: Umm. apt allows you to determine reverse depends. From there there is an easy hop to sending email to ask the develoeprsa in question; or to exaimine a package to look at its conffiles. This doesn't solve the problem of the dependent package being broken by the removal of the conffile upon which it has been depending. A _new_ version of the dependent package may have been released to the archive, but this is not the version that the victim has installed on his computer. Nick Phillips made a good point, however, when he said that conffiles are no different from other files in this respect. If bar depends on foo, then bar might be broken if _any_ file is removed from foo. Yet we do not do anything special when foo version 2.0 lacks an ordinary file that was contained in foo version 1.0. So we should not do anything special for conffiles either but (as Manoj Srivastava says) we should rely on communication among maintainers to avoid problems. Conffiles are different in one respect, which that is that they can be locally modified. When a conffile is to be overwritten and it has been modified, the user is asked for permission and the old version is backed up as *.dpkg-old. So when a conffile is to be deleted and it has been modified, the user should be asked for permission and the file renamed to *.dpkg-old (or *.dpkg-orphaned). Agree? -- Thomas
Re: Future releases of Debian
Quoting David Nusinow [EMAIL PROTECTED]: On Thu, Jul 24, 2003 at 10:35:01PM +0200, J?r?me Marant wrote: Quoting Bernhard R. Link [EMAIL PROTECTED]: But my point was the new debian-installed is not going to look like the current Mandrake 9.1 nor RedHat 9.0 (I've recently installed), at least for sarge. Perhaps for now, but that doesn't mean it has to stay that way. The modularity of the system will definitely allow for different frontends, and the fact that people are going to be more willing to work on d-i means that it will more than likely accumulate improvements over time. You can't say that about boot-floppies. I, for one, hope that the aim is to eventually have a very friendly installer. Even the most knowledgable people will appreciate hardware detection. Who knows ... -- Jérôme Marant
Re: Bug#201023: dosemu: purging doesmu wipes out all user data
Re: 1. dpkg -L 2. conffiles belonging to the package 3. configuration files other than conffiles belonging to the package 4. package's log output, cached compiled versions of conffiles, etc. 5. user data created using the package On Fri, 2003-07-25 at 09:01, Manoj Srivastava wrote: Here is my suggestion for how purge should be handled. Purge would delete #1 through #4 _and_ everything in /var/lib/pckg/. User data created using the package [#5] must then not be stored in /var/lib/pckg/ but somewhere else, e.g., in someone's home directory. Dosemu, for example, could store the not-to-be-purged DOS image in user dosemu's home dir. umm, no. Postgres should certainly not try and store the database under /home; since the DB can grow huge. It would be awfully convenient if packages could do a rm -rf /var/lib/pckg/ on purge, but we know this deletes things in some cases that should not be deleted. So I am proposing that rm -rf /var/lib/pckg/ always be permitted, and that any data that is not to be deleted on purge be stored elsewhere. I don't say where else it _should_ be stored. Perhaps postgres data could be stored in another subdirectory of /var/lib/, e.g., /var/lib/postgres-data/ . That understood, is the proposal sound? -- Thomas
Fwd: Incomplete upload found in Debian upload queue
[Please Cc me on replying, I'm not on the list] Nothing better than waking up and finding 40 new mails in your inbox. Including at least 30 times the attached message. I am certainly not the uploader of these files. There is no 0.80-2 version of this package and if it would be an NMU, surely the version number was wrong. But I prefer not to ignore this message. If possible I'd like to know where this upload came from. Why does katie delete the files instead of moving them to REJECT like it normally does? And is there any way to still get some clue about who did this? (Btw, why a time in American time zones in the message? Isn't GMT/UTC the Internet standard? And why is this message deleted before the average European wakes up?) Wilmer van der Gaast. Begin forwarded message: From: Archive Administrator [EMAIL PROTECTED] Date: vri jul 25, 2003 09:31:59 Europe/Amsterdam To: [EMAIL PROTECTED] Subject: Incomplete upload found in Debian upload queue Probably you are the uploader of the following file(s) in the Debian upload queue directory: bitlbee_0.80-2.diff.gz bitlbee_0.80-2.dsc This looks like an upload, but a .changes file is missing, so the job cannot be processed. If no .changes file arrives within 15:37:50, the files will be deleted. If you didn't upload those files, please just ignore this message. Greetings, Your Debian queue daemon -- + .''`. - -- ---+ + - -- --- - --+ | lintux : :' : lintux.cx | | OSS Programmer www.niode.nl | | at `. `~' debian.org | | www.lintux.cx www.algoritme.nl | +--- -- - ` ---+ +-- - --- -- - + PGP.sig Description: PGP signature
Re: unicode
On Wednesday 30 October 2002 14:11, Sergey V. Spiridonov wrote: Is Debian aims to be unicode compatible system? IANADD - but I guess the answer definitely is yes. But it's not a very urgent task. If yes, then should I mail a bug report against packages which are not able to handle unicode? If you manage to test for the right things next time, yes :-) You might also ask on the i18n lists if you suspect a problem. I think in most cases this would be a minor (or at most normal) bug. Submitting a patch will in most cases help more in getting it fixed quickly than a raised severity does. cheers -- vbi -- get my gpg key here: http://fortytwo.ch/gpg/92082481 pgp5bejBpe4Un.pgp Description: signature
Re: Incomplete upload found in Debian upload queue
Oops, I did a reread now. Forgot about UploadQueue completely, I always upload with scp anyway. :-) I found the packages, but I cannot download them. Could someone from the debadmin group on auric please send me the .diff.gz file? [EMAIL PROTECTED]:/home/katie/UploadQueue$ zcat /home/katie/UploadQueue/bitlbee_0.80-2.diff.gz zcat: /home/katie/UploadQueue/bitlbee_0.80-2.diff.gz: Permission denied I can't do it. :-( I can understand that the ftpd can't read it, but why can't even a trusted Debian Developer reach those files? Wilmer van der Gaast. On vrijdag, jul 25, 2003, at 10:12 Europe/Amsterdam, Wilmer van der Gaast wrote: (Btw, why a time in American time zones in the message? Isn't GMT/UTC the Internet standard? And why is this message deleted before the average European wakes up?) Sorry for this Anti-Americanism. ;-) Wilmer van der Gaast. -- + .''`. - -- ---+ + - -- --- - --+ | lintux : :' : lintux.cx | | OSS Programmer www.niode.nl | | at `. `~' debian.org | | www.lintux.cx www.algoritme.nl | +--- -- - ` ---+ +-- - --- -- - + PGP.sig Description: PGP signature
Re: update-alternatives priorities for editors
On Thu, Jul 24, 2003 at 11:00:56PM -0600, Bob Proulx wrote: Georg Neis wrote: This bugreport says that the elvis package (a vi clone) uses a too high priority for the 'editor'-alternative (or for all alternatives?). Which changes do you propose? As I read the original bug report and apply my own spin onto it I see the original poster was concerned that a user invoking /usr/bin/editor is probably not wanting either of the traditional vi or emacs editors. They are probably a user that wants a simpler to use editor. Perhaps something more like 'nano' or 'ee' than like either vi or emacs. (Note that emacs does not supply an alternative for /usr/bin/editor.) I personally would not have had either elvis or vim supply an alternative for /usr/bin/editor. /usr/bin/editor is not only something invoked directly. It's also invoked by programs as the default editor. And, if vim is the only editor installed on the system, it had better be the default editor for such programs! (I set $EDITOR for my ordinary user anyway, granted, but not for root, which uses editor for such things as visudo.) I don't mind lowering the priority of vi clones, or whatever; but please don't try to get them removed from the editor alternative. It's quite sufficient to have higher-priority editors installed by default. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: unicode
On Jul 25, 2003 at 09:38, Adrian 'Dagurashibanipal' von Bidder praised the llamas by saying: Content-Description: signed data On Wednesday 30 October 2002 14:11, Sergey V. Spiridonov wrote: Is Debian aims to be unicode compatible system? IANADD - but I guess the answer definitely is yes. But it's not a very urgent task. If yes, then should I mail a bug report against packages which are not able to handle unicode? If you manage to test for the right things next time, yes :-) You might also ask on the i18n lists if you suspect a problem. I think in most cases this would be a minor (or at most normal) bug. Submitting a patch will in most cases help more in getting it fixed quickly than a raised severity does. cheers -- vbi Probably the biggest unicode problem I have noticed is with man and/or less where it can't display dashes correctly. At least it doesn't seem to work out of the box. -- David Pashley [EMAIL PROTECTED] pgpEdYXqG1nKo.pgp Description: PGP signature
Re: update-alternatives priorities for editors
Am 25.07.03 um 09:21:47 schrieb Colin Watson: /usr/bin/editor is not only something invoked directly. It's also invoked by programs as the default editor. Shouldn't that be sensible-editor? Bye, Mike -- |=| Michael Piefel |=| Humboldt-Universität zu Berlin |=| Tel. (+49 30) 2093 3831
Re: unicode
Am 25.07.03 um 10:04:26 schrieb David Pashley: Probably the biggest unicode problem I have noticed is with man and/or less where it can't display dashes correctly. At least it doesn't seem to work out of the box. What's a dash? Sorry, but you have to be more specific here. There's the minus sign (usually introducing options) and the hyphen (for hyphenation). If the latter cannot be shown, it might also be a deficiency of the font you use. Bye, Mike -- |=| Michael Piefel |=| Humboldt-Universität zu Berlin |=| Tel. (+49 30) 2093 3831
Re: unicode
On Friday 25 July 2003 11:04, David Pashley wrote: Probably the biggest unicode problem I have noticed is with man and/or less where it can't display dashes correctly. At least it doesn't seem to work out of the box. Fully ACK [EMAIL PROTECTED]:~$ cat ~/bin/man PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin LC_CTYPE=de_CH `basename $0` $@ [EMAIL PROTECTED]:~$ this is my standard wrapper for quite a few programs which can't deal with unicde. In particular this is man, many gtk1/gnome1 programs, xawtv But in general, things tend to work reasonably well, and get ever better. The man (really: groff) issue is known, but AFAICT the fix is really, really difficult since groff just doesn't know anything about encodings, and the man page sources are in a variety of encodings. groff 2 is supposed to fix these problems, but I've got no idea when it is supposed to come. cheers -- vbi -- featured link: http://fortytwo.ch/gpg/subkeys pgp40MHUddAvy.pgp Description: signature
Re: Bug#201023: dosemu: purging doesmu wipes out all user data
On 25 Jul 2003 09:32:09 +0200, Thomas Hood [EMAIL PROTECTED] said: Re: 1. dpkg -L 2. conffiles belonging to the package 3. configuration files other than conffiles belonging to the package 4. package's log output, cached compiled versions of conffiles, etc. 5. user data created using the package On Fri, 2003-07-25 at 09:01, Manoj Srivastava wrote: Here is my suggestion for how purge should be handled. Purge would delete #1 through #4 _and_ everything in /var/lib/pckg/. User data created using the package [#5] must then not be stored in /var/lib/pckg/ but somewhere else, e.g., in someone's home directory. Dosemu, for example, could store the not-to-be-purged DOS image in user dosemu's home dir. umm, no. Postgres should certainly not try and store the database under /home; since the DB can grow huge. It would be awfully convenient if packages could do a rm -rf /var/lib/pckg/ on purge, but we know this deletes things in some cases that should not be deleted. So I am proposing that rm -rf /var/lib/pckg/ always be permitted, and that any data that is not to be deleted on purge be stored elsewhere. I don't say where else it _should_ be stored. Perhaps postgres data could be stored in another subdirectory of /var/lib/, e.g., /var/lib/postgres-data/ . That understood, is the proposal sound? Not really. Why do we need this overly micromanaging rule in policy? As long as it understood that user data is not to be deleted, why can't I put user data in /var/lib/pkg/ if I so desire, as long as I take care to not rm -rf that dir? If you don't want files in category 5 to be deleted as a matter of policy, fine, then say so. Creating braod rules that have a secondary effect of doing what you want accomplished, but also restrict other scenarios, is bad. No package should be forced to create a second directory somewhere. manoj -- It is not best to swap horses while crossing the river. Abraham Lincoln Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: update-alternatives priorities for editors
On Fri, Jul 25, 2003 at 11:05:25AM +0200, Michael Piefel wrote: Am 25.07.03 um 09:21:47 schrieb Colin Watson: /usr/bin/editor is not only something invoked directly. It's also invoked by programs as the default editor. Shouldn't that be sensible-editor? Which calls editor if $VISUAL and $EDITOR aren't set, yes. -- Colin Watson [EMAIL PROTECTED]
Re: Future releases of Debian
Moin Matthias! Matthias Urlichs schrieb am Friday, den 25. July 2003: You keep using this flame excuse I remember the last time this was discussed, and I believe that ESPECIALLY when emotions tend to run high, the words we use make a difference. There were no emotion. I just listed facts; please analyze the current situation with (di|bf) development before you claim anything different. We can't find a good solution to this problem, if indeed there is one, if all we have is two rows of people on different sides of a long table, shouting at each other. Exactly. If you had nothing productive to add to the discussion, why do you participate then? to conveniently ignore the real question ... which others have already answered the same way I'd have. And got the same request for reality check as answer! MfG, Eduard. -- Alfie AAARGH, bin ich deppert!
Re: unicode
On Fri, Jul 25, 2003 at 10:04:26AM +0100, David Pashley wrote: Probably the biggest unicode problem I have noticed is with man and/or less where it can't display dashes correctly. At least it doesn't seem to work out of the box. In groff \- is a dash, - is a hyphen. People need to use the right one. If you have other problems let me know, since I'm not aware of any in unstable right now. -- Colin Watson [EMAIL PROTECTED]
Re: May packages rm -rf subdirectories of /etc/ ?
On 25 Jul 2003 09:20:20 +0200, Thomas Hood [EMAIL PROTECTED] said: Conffiles are different in one respect, which that is that they can be locally modified. When a conffile is to be overwritten and it has been modified, the user is asked for permission and the old version is backed up as *.dpkg-old. So when a conffile is to be deleted and it has been modified, the user should be asked for permission and the file renamed to *.dpkg-old (or *.dpkg-orphaned). Agree? No. Since this scenario only happens when the conffile is going to be ignored anyway, why do I want to have an locally modified version lying around by default? manoj -- The problem with this country is that there is no death penalty for incompetence. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: update-alternatives priorities for editors
On Fri, 25 Jul 2003 09:21:47 +0100, Colin Watson [EMAIL PROTECTED] said: /usr/bin/editor is not only something invoked directly. It's also invoked by programs as the default editor. And, if vim is the only editor installed on the system, it had better be the default editor for such programs! Is that not an argument for emacs also providing /usr/bin/editor alternatives, since emacs may be the sole editor on the system? manoj -- If truth is beauty, how come no one has their hair done in the library? Lily Tomlin Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: unicode
On Friday 25 July 2003 11:10, Michael Piefel wrote: Am 25.07.03 um 10:04:26 schrieb David Pashley: Probably the biggest unicode problem I have noticed is with man and/or less where it can't display dashes correctly. At least it doesn't seem to work out of the box. What's a dash? Sorry, but you have to be more specific here. There's the minus sign (usually introducing options) and the hyphen (for hyphenation). If the latter cannot be shown, it might also be a deficiency of the font you use. Hmmm. This is really funny. Look at http://fortytwo.ch/~avbidder/man-page.png. But when I copy-paste into kmail, it comes right, with all '-' (both hyphens and minus) - exactly as if I start man with LC_CTYPE=de_CH (as I usually do it). Also, this doesn't happen with all manpages. What I don't really get: I use the same font for almost everything (lucidatypewriter), definitely so for the mail composer and the konsole. So while the fact that copy-pasting it 'solves' the problem hints at a font problem, I copy and paste between windows that use the same font... confused greetings -- vbi (for another unicode issue: http://fortytwo.ch/~avbidder/konsole-unicode-bug.png) -- Could this mail be a fake? (Answer: No! - http://fortytwo.ch/gpg/intro) pgpGn9nCQsZqB.pgp Description: signature
Re: update-alternatives priorities for editors
Michael Piefel [EMAIL PROTECTED] wrote: Am 25.07.03 um 09:21:47 schrieb Colin Watson: /usr/bin/editor is not only something invoked directly. It's also invoked by programs as the default editor. Shouldn't that be sensible-editor? No. see policy. sensible-editor is just for programs for which it is very hard to adapt a program to make use of the EDITOR or PAGER variables cu andreas
Re: unicode
On Fri, Jul 25, 2003 at 11:20:27AM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: The man (really: groff) issue is known, but AFAICT the fix is really, really difficult since groff just doesn't know anything about encodings, and the man page sources are in a variety of encodings. groff 2 is supposed to fix these problems, but I've got no idea when it is supposed to come. Nor does upstream, AFAIK. :-) From: Werner LEMBERG [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Groff] groff version 2 Date: Tue, 22 Jul 2003 13:44:44 +0200 (CEST) groff based on Unicode internally will be called version 2.0. This was not the question :-) Do you have a pre version of groff 2.0 ? N :-) -- Colin Watson [EMAIL PROTECTED]
Re: surfraw ultimatum
On Tue, Jul 22, 2003 at 11:12:44PM -0500, Thomas Smith wrote: Hi, On Tuesday, July 22, 2003, at 07:03 PM, Adam Borowski wrote: religiousasbestos longjohns Just don't *dare* to let anyone remove /usr/bin/google or I'll kill you, your dog and your friend's uncle's son's ex-roommate's girlfriend's aunt's pet hamster. /asbestos/religious OK, how about we change the surfraw rhyme to accept similar command line arguments to the rhyme-the-package rhyme and register them as alternatives, with rhyme-the-package higher on the list? Note that I have not yet downloaded rhyme-the-package to see how well this will work... Hi Thomas, I have no problem with this (as the maintainer of rhyme (the package). I don't even necessarily need rhyme (the package) to have a higher priority. I'm not 100% convinced that alternatives is the Right Way though (even though I'll implement that if it's what we agree on in the end). How about this for a suggestion? rhyme (the package) keeps the rhyme binary. surfraw renames the rhyme binary to (say) surfrhyme or something. I arrange for rhyme the package to prominently display some notice to the effect of This rhyme command supplants the rhyme command in surfraw. If you want the surfraw rhyme command then use the new name of 'surfrhyme'. Obviously the language needs to be cleaned up and thought about, as does the command name. There are problems with this approach as well though, obviously. It still doesn't address the namespace pollution though. There are a lot more very generic commands there. Still, both are solutions that I'm happy to implement as long as surfraw starts being maintained actively again. As regards the alioth project goes. Well done and thank you for getting this up and running. If you post again when it's properly running, I'll check out the CVS and might submit a few patches. Be aware that you don't always get a confirmation mail from alioth to say the project has been started...sometimes it just appears :) Have a look to see what projects your account on alioth are registered as being associated with, it might already be there :) I think that, since they have similar functions, this strategy should work... if there's some other program that wants to use W then that's less likely, but this should work for now. Considering the number of people interested in surfraw, you most likely already received a complete set of patches. Heh, you underestimate the laziness of people in general. go for it, man. hehe, well, not necessarily laziness. I did take an hour or so to have a look at the surfraw package a few days ago and started to fix some trivial stuff. I was loath to do much before the question of where the commands were going was settled though. As I said earlier, once you have the package in publicly available CVS, I'll more then likely grab it and submit patches properly. Cheers, Stephen pgponZN0e69lH.pgp Description: PGP signature
Re: Future releases of Debian
* Jérôme Marant [EMAIL PROTECTED] [030724 22:35]: But my point was the new debian-installed is not going to look like the current Mandrake 9.1 nor RedHat 9.0 (I've recently installed), at least for sarge. And my point was, that userfriendlyness and looking like Mandrake are orthogonal aspects. As the princible user-interaction of the bootfloppies is one of the most userfriendly around, I'd be very supprised, if debian-installer did not look similar. After all it's about making things more user-friendly, not less. And fancy graphics are not easy, fancy graphics beeing as usable as something without graphics is even harder. Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Re: Future releases of Debian
On Thu, Jul 24, 2003 at 12:34:29PM -0600, Jamin W. Collins wrote: me too! any package that doesn't build on m68k or arm is broken and needs to be fixed, even if it works on x86 by chance! So, are you volunteering to help those of us without access to either of the above architectures with bugs found in our packages? I'm not saying that all architectures shouldn't be supported equally. I just don't have access to either of the above architectures to correct problems found in my packages. actually i don't because i have no access to any arch except x86 and alpha. but that is only true for non-DDs like me and (i presume) you, DDs have access to all those architectures. cu robert pgpZltHXVd16H.pgp Description: PGP signature
Re: Future releases of Debian
On Thu, Jul 24, 2003 at 01:37:18PM -0500, John Hasler wrote: Robert Lemmen writes: any package that doesn't build on m68k or arm is broken and needs to be fixed, even if it works on x86 by chance! Even when it fails to build due to compiler errors or buggy libraries? in that case it's the compiler or library that's buggy (as you said) and needs to be fixed. no reason to abandon the arch cu robert pgp8bDN9e88Qf.pgp Description: PGP signature
Re: Future releases of Debian
On Fri, Jul 25, 2003 at 12:17:37PM +0200, Robert Lemmen wrote: actually i don't because i have no access to any arch except x86 and alpha. but that is only true for non-DDs like me and (i presume) you, DDs have access to all those architectures. Although even with access to machines depending on the application there may be varying amounts of hassle actually using them to test things. -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: update-alternatives priorities for editors
On Fri, Jul 25, 2003 at 04:22:42AM -0500, Manoj Srivastava wrote: On Fri, 25 Jul 2003 09:21:47 +0100, Colin Watson [EMAIL PROTECTED] said: /usr/bin/editor is not only something invoked directly. It's also invoked by programs as the default editor. And, if vim is the only editor installed on the system, it had better be the default editor for such programs! Is that not an argument for emacs also providing /usr/bin/editor alternatives, since emacs may be the sole editor on the system? Yes, I see no reason why emacs (or emacsclient or whatever - I don't use it myself) shouldn't provide an editor alternative. -- Colin Watson [EMAIL PROTECTED]
Re: unicode
On Fri, Jul 25, 2003 at 11:43:15AM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: On Friday 25 July 2003 11:10, Michael Piefel wrote: What's a dash? Sorry, but you have to be more specific here. There's the minus sign (usually introducing options) and the hyphen (for hyphenation). If the latter cannot be shown, it might also be a deficiency of the font you use. Hmmm. This is really funny. Look at http://fortytwo.ch/~avbidder/man-page.png. What versions of man-db and groff are installed, and what pager (and version of same) are you using? -- Colin Watson [EMAIL PROTECTED]
debian-devel@lists.debian.org
http://fysjy.vicp.net/bbs
Re: Why back-porting patches to stable instead of releasing a new package.
On Wed, Jul 23, 2003 at 09:13:18PM +0200, Adrian Bunk wrote: Debian stable is horribly outdated but I'm not aware of any severe bugs. Could you provide some examples of severe bugs in Debian 3.0? Bind9, as provided in woody, keeps on falling to its knees for unknown reasons. A strace might help, but so far i have not been able to either keep bind9 runing form more than a week nor find the cause of the poissoning which kills the daemon (thus my inability of filling a bug report). data -- Jesus Climent | Unix SysAdm | Helsinki, Finland | pumuki.hispalinux.es GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 -- Registered Linux user #66350 proudly using Debian Sid Linux 2.4.21 Where are you going, Starfish and Friends? --Chad (Charlie's Angels)
Re: Future releases of Debian
Quoting Bernhard R. Link [EMAIL PROTECTED]: And my point was, that userfriendlyness and looking like Mandrake are orthogonal aspects. As the princible user-interaction of the bootfloppies is one of the most userfriendly around, I'd be very supprised, if debian-installer did not look similar. After all it's about making things more user-friendly, not less. And fancy graphics are not easy, fancy graphics beeing as usable as something without graphics is even harder. Userfirendliness means necessarily hiding technical details IMO, without dealing with graphical aspects. I think that D-i hasn't reach that state. You can find d-i screenshots there: http://people.debian.org/~sjogren -- Jérôme Marant
Re: update-alternatives priorities for editors
Am 25.07.03 um 11:38:33 schrieb Andreas Metzler: No. see policy. sensible-editor is just for programs for which it is very hard to adapt a program to make use of the EDITOR or PAGER variables Okay, so when somebody is not able to set their EDITOR variable, isn't it quite safe to assume that they are not the people who are satisfied with vi as their editor? In summary: Someone said vi should be an alternative for editor, because /usr/bin/editor is called from other programs; that suggested you can't use vi then from there. Which isn't true, just set EDITOR. On my system, /usr/bin/editor can be a dangling symlink, it never gets called. Bye, Mike -- |=| Michael Piefel |=| Humboldt-Universität zu Berlin |=| Tel. (+49 30) 2093 3831
Re: unicode
Am 25.07.03 um 11:43:15 schrieb Adrian 'Dagurashibanipal' von Bidder: Hmmm. This is really funny. Look at http://fortytwo.ch/~avbidder/man-page.png. Good you mention it. File a bug against gnupg. It uses '-' in its manpage where it should use '\-'. What I don't really get: I use the same font for almost everything (lucidatypewriter), definitely so for the mail composer and the konsole. So while the fact that copy-pasting it 'solves' the problem hints at a font problem, I copy and paste between windows that use the same font... Whatever your konsole and your kmail is doing with it... As far as I can see, there's no lucidatypewriter ISO-10646 font, but I don't have all the packages installed. Bye, Mike -- |=| Michael Piefel |=| Humboldt-Universität zu Berlin |=| Tel. (+49 30) 2093 3831
Re: update-alternatives priorities for editors
On Fri, Jul 25, 2003 at 01:43:52PM +0200, Michael Piefel wrote: Okay, so when somebody is not able to set their EDITOR variable, isn't it quite safe to assume that they are not the people who are satisfied with vi as their editor? It could also be that they are people who only ever uses vi and therefore have no other editors installed on their systems. Completely excluding vi from the alternatives for editor isn't desparately helpful. It may be wise to prefer other editors but that's a different matter. -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: Future releases of Debian
On Jul 25, Robert Lemmen [EMAIL PROTECTED] wrote: in that case it's the compiler or library that's buggy (as you said) and needs to be fixed. no reason to abandon the arch As some of us are patiently trying to explain, the problem is that often there are not enough resources to quickly diagnose and/or fix these bugs. -- ciao, | Marco | [999 sfAmW6Pe85ers] pgpP1e9Dg00ia.pgp Description: PGP signature
Re: Future releases of Debian
On Jul 24, Steve Langasek [EMAIL PROTECTED] wrote: This does not excuse broken, ugly x86isms in packages. The vast majority of portability problems are NOT confined to a single oddball architecture; they may manifest in different ways, but the bugs are usually there on multiple architectures at once. If you don't directly Really? The experience I had with my own packages is very different: the bugs which keep them outside of testing for weeks are not in the programs code, but are caused by broken toolchains or other broken packages they depend on. -- ciao, | Marco | [1000 faz3ENDvYsyio] pgpYCMbJBwssM.pgp Description: PGP signature
Re: Why back-porting patches to stable instead of releasing a new package.
On Jul 25, Jesus Climent [EMAIL PROTECTED] wrote: Bind9, as provided in woody, keeps on falling to its knees for unknown reasons. A strace might help, but so far i have not been able to either keep BIND 9 in woody is old and buggy, that's all. Ask upstream about this version and they will tell you to upgrade. bind9 runing form more than a week nor find the cause of the poissoning which kills the daemon (thus my inability of filling a bug report). Don't waste your time, as the bug as probably been fixed in 9.2.2. -- ciao, | Marco | [1001 diqeRlZB5IRZ.]
Opteron donation?
This month's sourceforge spam says: AMD Quad Opteron System on Compile Farm - Are you curious how your latest code runs on a 4-way 64bit Opteron system? Now you can find out using the latest addition to Sourceforge.net's compile Farm. AMD has been kind enough to provide SF.net hardware for the community to use. Running SuSE Linux Enterprise Server 8 this new system is now available for you to use. Enjoy! The SF.net team would like to give a big thank you to AMD for their support. To find out more about the compile farm: http://sourceforge.net/docman/display_doc.php?docid=762group_id=1 Back in April, AMD told us that they could not give us a machine: http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01174.html Perhaps the situation has changed, and we should ping them again? -- - mdz
Re: Future releases of Debian
On Fri, Jul 25, 2003 at 12:02:09AM -0600, Bob Proulx wrote: Matt Zimmerman wrote: tolerances. When was the last time you had a motherboard, or CPU, or network card, or a video card die because it was too old? This stuff isn't exactly perishable. It lasts long beyond its obsolescence in most cases. About a year ago a venerable GeForce 256 of mine had a D/A failure causing bad video output. I neglected to recycle it and left it on the workbench. About six months ago a newer video card had the fan on it die. I was able to salvage the fan from the first and fix the second with it. Just two weeks ago another newer video card fan died. Wish I had a source for those thin pci card fans... Not a single one of my video cards has a fan on it. :-) -- - mdz
Re: Opteron donation?
* Matt Zimmerman [EMAIL PROTECTED] [2003-07-25 08:27]: Back in April, AMD told us that they could not give us a machine: http://lists.debian.org/debian-devel/2003/debian-devel-200304/msg01174.html Perhaps the situation has changed, and we should ping them again? Digital Network UK and FMS Computer have kindly agreed to donate machines to Debian. -- Martin Michlmayr [EMAIL PROTECTED]
Re: Future releases of Debian
* Jérôme Marant [EMAIL PROTECTED] [030725 13:03]: Userfirendliness means necessarily hiding technical details IMO, without dealing with graphical aspects. Taken this statement directly it's user-unfriendly in both the sense of newbie-unfriendly and experienced-unfriendly. (A newbie might like it, but he will still suffer from it). It's newbie-friendly if an user, if an user can use with without the need to understand unnecassary things. And ecspecially without the need to understand what is unnecassary. The main difficulty is that no developer can know before, what will be necesary. Both a system presenting a utter mess of uneeded things and technical terms and a system only saying Installation successful or Installation failed are two ends of user-unfriendly behaviour. While the first can be at least cured with a good documentation, the last is simply frustrating. Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Re: Why back-porting patches to stable instead of releasing a new package.
On Fri, Jul 25, 2003 at 01:44:39PM +0200, Marco d'Itri wrote: On Jul 25, Jesus Climent [EMAIL PROTECTED] wrote: Bind9, as provided in woody, keeps on falling to its knees for unknown reasons. A strace might help, but so far i have not been able to either keep BIND 9 in woody is old and buggy, that's all. Ask upstream about this version and they will tell you to upgrade. Which probes what I was trying to say: By taking so long from release to release (NO ofense to anyone) we provide old and buggy software (in some cases) which only gets security fixes, but then the fame of Debian being rock solid might not be true in all its senses. The proposal of releasing more often (with or without the proposal of splitting base+the_rest) gets stronger on my mind. d-i guys, keep the great work! data -- Jesus Climent | Unix SysAdm | Helsinki, Finland | pumuki.hispalinux.es GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 -- Registered Linux user #66350 proudly using Debian Sid Linux 2.4.21 There's nothing that can't be done. --McManus (The usual suspects)
Re: Opteron donation?
Martin Michlmayr - Debian Project Leader wrote: Digital Network UK and FMS Computer have kindly agreed to donate machines to Debian. This is great news. Discussions on opteron port will be done in -devel? (especially problems like /lib+/lib64 vs /lib+/lib32, upgrading problems from i386 to opteron without-breaking-anything, and more)
Re: Bug#201023: dosemu: purging doesmu wipes out all user data
On Fri, 2003-07-25 at 11:19, Manoj Srivastava wrote: Not really. Why do we need this overly micromanaging rule in policy? As long as it understood that user data is not to be deleted, why can't I put user data in /var/lib/pkg/ if I so desire, as long as I take care to not rm -rf that dir? That's fine. The original complaint [1] was that dosemu purged user data. At some stage it was suggested [2] that packages should not delete entire directories indiscriminately. I replied [3] that packages be allowed to delete at least /var/lib/pkg/ . You are right that we should not _require_ any package to delete its /var/lib/pkg/ . What I am more concerned about is configuration file directories. A lot of packages delete /etc/ trees on purge. Earlier I was thinking that Debian should have a policy forbidding that, but now think that existing policy may be sufficient. Under current policy, a package can delete /etc/foo only if no other package uses /etc/foo to store configuration files. If another package does use /etc/foo to store configuration files then deleting those files would violate 10.7.3 and 10.7.4 . [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=nobug=201023 [2] http://marc.theaimsgroup.com/?l=debian-develm=105827881413400w=2 http://marc.theaimsgroup.com/?l=debian-develm=105833979508949w=2 [3] http://marc.theaimsgroup.com/?l=debian-develm=105878073004572w=2 -- Thomas
Re: unicode
On Fri, 2003-07-25 at 11:20, Colin Watson wrote: On Fri, Jul 25, 2003 at 10:04:26AM +0100, David Pashley wrote: Probably the biggest unicode problem I have noticed is with man and/or less where it can't display dashes correctly. At least it doesn't seem to work out of the box. In groff \- is a dash, - is a hyphen. People need to use the right one. If you have other problems let me know, since I'm not aware of any in unstable right now. In unicode, there are at least these: ASCII hyphen- (0x2D) hyphen (0x2010) non-breaking hyphen (0x2011) subtraction sign (0x2212) en dash (0x2013) em dash (0x2014) horizontal bar (0x2015) -- Thomas
Re: Opteron donation?
On Friday 25 July 2003 14:44, Xavier Roche wrote: This is great news. Discussions on opteron port will be done in -devel? (especially problems like /lib+/lib64 vs /lib+/lib32, upgrading problems from i386 to opteron without-breaking-anything, and more) No, there is another list for these issues. You can find the archives at http://lists.debian.org/debian-x86-64/, some older messages are at http://lists.alioth.debian.org/pipermail/debian-x86-64-devel/. Arnd
Re: May packages rm -rf subdirectories of /etc/ ?
On Fri, 2003-07-25 at 11:21, Manoj Srivastava wrote: On 25 Jul 2003 09:20:20 +0200, Thomas Hood [EMAIL PROTECTED] said: Conffiles are different in one respect, which that is that they can be locally modified. When a conffile is to be overwritten and it has been modified, the user is asked for permission and the old version is backed up as *.dpkg-old. So when a conffile is to be deleted and it has been modified, the user should be asked for permission and the file renamed to *.dpkg-old (or *.dpkg-orphaned). Agree? No. Since this scenario only happens when the conffile is going to be ignored anyway, why do I want to have an locally modified version lying around by default? If the conffile is unmodified it is removed. If it has been modified then the default option (of the two presented to the user) would be to rename the file. If you are asking why there should be a backup, then notice that the same question can be asked about any backup file. Perhaps you are thinking that no backup is needed because foo no longer lists foo.conf as a conffile. But it is quite easy to imagine circumstances in which the admin might want to look in the old conffile. Perhaps he will need the values in it when he uses foo's fancy new debconf-driven configuration scheme. :) So why rename the file at all? Because the *.dpkg-old suffix will deactivate the file if it is in a run-parts directory and will generally make it clear that the file is no longer in use. -- Thomas Hood
Re: What's the character encoding of manpages?
On Thu, 24 Jul 2003 15:13:13 +0100, Colin Watson [EMAIL PROTECTED] claimed: [...] See groff_char(7). Technically it's Latin-1, but this is planned to change to UTF-8 for groff 2.0 (no schedule yet); groff_char(7) advises sticking to ASCII, and I agree. You can get everything in Latin-1 using named characters anyway without having to worry about encoding. [...] 0xA0 is the Latin-1 non-breaking space. Bug #199422 notes that this doesn't work in current groff. I'm not sure whether this is actually a groff bug or not, and need to check with upstream. I suggest using '\ ' instead anyway, though. [...] Using .nf and .fi would probably be more sensible than large numbers of.br requests. (Feel free to pass on this comment.) Thanks a lot. That's exactly what I needed to know. I updated/submitted the bugs to the sf.net bug tracking system. -- ai pgpuwCAGDAnYe.pgp Description: PGP signature
ITA: yadex -- WAD file editor for doom-style WADs
retitle 201391 ITA: yadex -- WAD file editor for doom-style WADs stop Hi, I'd like to maintain yadex, which I'm using quite often, for debian. Anyway it was about time for me to do something for debian, so adopting an existing package should be the right way to start. I've packaged it, changed changelog, and closed the remaining bug (#138072). I've read the debian policy manual, the developer's reference, the social contract, and the DFSG. Next step seems to look for a sponsor, so if anyone is interested i'm clean and don't eat much ;-) If i'm doing something wrong, please forgive me, i'm trying to figure out how to do, using the debian-mentors ml archives. Wagner Frederic -- --- Unix - where you can throw the manual on the keyboard and get a command
Re: Bug#108587: May packages rm -rf subdirectories of /etc/ ?
On Thu, Jul 24, 2003 at 02:07:35PM +0200, Thomas Hood wrote: On Thu, 2003-07-24 at 13:46, Stephen Frost wrote: I see this as totally bogus. Either the conffile is shared or it isn't. If it's shared then the packages involved know this Package foo which eliminates /etc/foo.conf doesn't know that there is not some other package, bar, which Depends on foo and uses /etc/foo.conf . From policy: If two or more packages use the same configuration file and it is reasonable for both to be installed at the same time, one of these packages must be defined as _owner_ of the configuration file, i.e., it will be the package which handles that file as a configuration file. Other packages that use the configuration file must depend on the owning package if they require the configuration file to operate. If the other package will use the configuration file if present, but is capable of operating without it, no dependency need be declared. If they don't know, then the maintainers of the packages need to, you know, exchange emails. If a package stops providing a config file that another package depends on, it needs to use a Conflicts: line, or change its name, or otherwise break the dependency, just as it would for any other feature change that breaks other packages. If the other package isn't in Debian, well, tough luck; test first, roll out later. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpx2qRwzn1Og.pgp Description: PGP signature
Re: Future releases of Debian
Bernhard R. Link [EMAIL PROTECTED] writes: Taken this statement directly it's user-unfriendly in both the sense of newbie-unfriendly and experienced-unfriendly. (A newbie might like it, but he will still suffer from it). There is a widespread tendency to consider newbie to mean a refugee from MS or some other eye-candy system. A true newbie would be one who has never used a computer before. To such a person, a CLI is much more intuitive than any GUI. Regards, Bob -- _ |_) _ |_Robert D. Hilliard[EMAIL PROTECTED] |_) (_) |_) 1294 S.W. Seagull Way [EMAIL PROTECTED] Palm City, FL 34990 USA GPG Key ID: 390D6559
Re: unicode
On Fri, Jul 25, 2003 at 03:12:29PM +0200, Thomas Hood wrote: On Fri, 2003-07-25 at 11:20, Colin Watson wrote: In groff \- is a dash, - is a hyphen. People need to use the right one. If you have other problems let me know, since I'm not aware of any in unstable right now. In unicode, there are at least these: ASCII hyphen- (0x2D) hyphen ??? (0x2010) non-breaking hyphen (0x2011) subtraction sign??? (0x2212) en dash ??? (0x2013) em dash ??? (0x2014) horizontal bar ??? (0x2015) A Debian-specific patch maps '\-' to 0x2D for the man and mdoc macro sets. For the others, see groff_char(7) and /usr/share/groff/current/font/devutf8/*. -- Colin Watson [EMAIL PROTECTED]
Re: proposal: per-user temporary directories on by default?
(Sorry for the dup, Dwayne, meant to send this to the list.) On 24-Jul-03, 17:56 (CDT), Dwayne C. Litzenberger [EMAIL PROTECTED] wrote: On Thu, Jul 24, 2003 at 02:50:05PM -0500, Steve Greenland wrote: Please don't. Is there *any* reason why defaulting TMPDIR=/tmp/username is inferior to TMPDIR=/tmp? Systems with large numbers of users (and normally use, for example /home/u/username), and filesystem which doesn't like large numbers of entries quickly might have performance problems. In which case, having all the files in /tmp is likely to be worse. Look, we're talking about defaults here. Defaults are not suitable for all situations, but simply the best average choice. Very large (and very small) systems will always have to make adjustments to suit their particular needs. It's part of the deal of running a large system. But for the majority of Debian users, we should pick the best option and not bother them about it. Or, for all I care, we can default to /tmp/u/username. Just don't bother me about it. And then there's the issue of making *really sure* that /tmp/username always exists and has the correct permissions, Please follow along. We're talking about automating this in a PAM, which would create the directory and set TMPDIR. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: May packages rm -rf subdirectories of /etc/ ?
Manoj Srivastava [EMAIL PROTECTED] writes: Umm. apt allows you to determine reverse depends. From there there is an easy hop to sending email to ask the develoeprsa in question; or to exaimine a package to look at its conffiles. Slightly off-topic, is there any tool to easily determine reverse build-depends? Regards, Bob -- _ |_) _ |_Robert D. Hilliard[EMAIL PROTECTED] |_) (_) |_) 1294 S.W. Seagull Way [EMAIL PROTECTED] Palm City, FL 34990 USA GPG Key ID: 390D6559
debian-devel@lists.debian.org
.Nethttp://www.joyasp.net
Re: Future releases of Debian
Jérôme Marant wrote: Userfirendliness means necessarily hiding technical details IMO, without dealing with graphical aspects. I think that D-i hasn't reach that state. It seems you're not aware of the SkoleLinux distribution. SkoleLinux has taken the current d-i, made very few changes, and pumped the debconf priority level up to high. The result is an installer that asks 3 questions and then installs a complete Debian subdistribution with no further prompting. -- see shy jo pgpUWx7JqO0zZ.pgp Description: PGP signature
Re: Future releases of Debian
Bernhard R. Link wrote: Both a system presenting a utter mess of uneeded things and technical terms and a system only saying Installation successful or Installation failed are two ends of user-unfriendly behaviour. While the first can be at least cured with a good documentation, the last is simply frustrating. Luckily d-i falls in neither of these camps, since there are some smart people working on it. For example, if it is running at a high priority level, skipping most user interaction, and something fails, it falls back to a lower priority level, giving the user a chance to manually correct whatever it was that broke. I think you'd better use your time by learning about and contributing to d-i, rather than writing uninformed, generic commentary. -- see shy jo pgpkufquKatBR.pgp Description: PGP signature
Re: unicode
#include hallo.h * Michael Piefel [Fri, Jul 25 2003, 01:51:33PM]: What I don't really get: I use the same font for almost everything (lucidatypewriter), definitely so for the mail composer and the konsole. So while the fact that copy-pasting it 'solves' the problem hints at a font problem, I copy and paste between windows that use the same font... Whatever your konsole and your kmail is doing with it... As far as I can see, there's no lucidatypewriter ISO-10646 font, but I don't have all the packages installed. At least in XFree86 4.3.0, it seems to be provided by standard xfonts-(75|100)dpi packages. MfG, Eduard. -- jjFux Wenn's beim (verdammt guten) Gefühl bei galon bleibt, schicke ich opera morgen in Rente LordYago jjFux: Fällt Opera unter den Generationenvertrag? ;-)
Re: unicode
On Friday 25 July 2003 12:21, Colin Watson wrote: On Fri, Jul 25, 2003 at 11:43:15AM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: On Friday 25 July 2003 11:10, Michael Piefel wrote: What's a dash? Sorry, but you have to be more specific here. There's the minus sign (usually introducing options) and the hyphen (for hyphenation). If the latter cannot be shown, it might also be a deficiency of the font you use. Hmmm. This is really funny. Look at http://fortytwo.ch/~avbidder/man-page.png. What versions of man-db and groff are installed, and what pager (and version of same) are you using? The latest, afaict (excluding experimental) ii man-db 2.4.1-10 The on-line manual pager ii groff-base 1.18.1-9 GNU troff text-formatting system (base syste ii less 381-2 A file pager program, similar to more(1) ii konsole3.1.1-1KDE X terminal emulator LC_CTYPE=en_US.UTF-8 I'd be willing to try some experimental pkgs if you can point me to a source (and as long it doesn't involve updating more essential things) Sometimes all '-' characters (don't know how if they're hyphens or minus or em-dashes) are affected, and sometimes only few of them (only hyphens or so). cheers -- vbi -- featured link: http://fortytwo.ch/smtp pgpalKqCc0nDc.pgp Description: signature
Re: Future releases of Debian
On Thu, Jul 24, 2003 at 07:16:14PM +0200, Marco d'Itri wrote: On Jul 24, Matthias Urlichs [EMAIL PROTECTED] wrote: If nobody volunteeers to make the crap ready, Umm, using that word puts your mail firmly into the flame category, especially for readers who actually care about Debian supporting these architectures. So what? You keep using this flame excuse to conveniently ignore the real question: why should reasonably working packages (or even the whole distribution!) be penalized because nobody has enough time or interest to fix toy architectures? Could you give examples of your nobody has enough time or interest to fix toy architectures? If the latest gcc or glibc or any other important package has a problem on one architecture that is sometimes non-trivial to fix, but doesn't indicate noone would be interested in this architecture. ciao, | Marco | [987 sp7FmbP1wiu6Q] cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
Re: unicode
On Friday 25 July 2003 13:51, Michael Piefel wrote: Am 25.07.03 um 11:43:15 schrieb Adrian 'Dagurashibanipal' von Bidder: Hmmm. This is really funny. Look at http://fortytwo.ch/~avbidder/man-page.png. Good you mention it. File a bug against gnupg. It uses '-' in its manpage where it should use '\-'. Ok. I'll point to your message as I can't really say anything about it... see, there's no lucidatypewriter ISO-10646 font, but I don't have all the packages installed. I have -bh-lucidatypewriter-medium-r-normal-sans-*-*-*-*-m-*-iso-10646-1 with '36 names match' in xfontsel. Not sure how to find which package contains that font. Greetings -- vbi -- featured link: http://www.pool.ntp.org pgpZbFLtjwC2X.pgp Description: signature
Re: Future releases of Debian
On Thu, Jul 24, 2003 at 02:23:30PM -0600, Jamin W. Collins wrote: Now you're assuming that I have access to the Debian machines. TMK, these machines are *not* public access machines, but instead are accessible to full DDs only. This excludes all new maintainer applicants, myself included. The DAM discussion is a different discussion, no need to restart it in this thread. There are at least two ways how you can get an account on a machine in such a situation: - ask the Debian admins for a guest account on a machine of this architecture - ask on the Debian list for this architecture whether someone can give you an account on a machine of this architecture Jamin W. Collins cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
Re: Future releases of Debian
On Fri, Jul 25, 2003 at 04:25:57PM +0100, Scott James Remnant wrote: On Thu, 2003-07-24 at 19:34, Jamin W. Collins wrote: So, are you volunteering to help those of us without access to either of the above architectures with bugs found in our packages? I'm not saying that all architectures shouldn't be supported equally. I just don't have access to either of the above architectures to correct problems found in my packages. Strange, the rest of us Debian Developers have access to all of these strange platforms ... http://raw.no/debian/machines.html By the rest of us Debian Developers I assume you mean *full* Debian Developers (those of you with DD accounts). Perhaps you haven't read the rest of this thread. I'm not a *full* DD and thus don't have access to all the resources a *full* DD has. As I've inferred elsewhere this is one of the problems with keeping NMs in queue waiting on one approval for several months (and potentially years). If your package has a bug affecting arm, login to debussy and fix it. If your package has a bug affecting mips, login to casals and fix it. If your package has a bug affecting m68k, login to kullervo and fix it. Would be happy to. Unfortunately, I can't, don't have an account. If you're going to claim that you don't have the knowledge to investigate and fix difficult problems, perhaps you should reconsider whether you are able to maintain your packages? I never claimed I didn't have the knowledge to fix it. I stated I don't have access to the architecture. Lacking access to a resource does not mean one lacks the knowledge of how to preform tasks on/with the resource. Who is sick of this I don't have an m68k box to fix my bug excuse. That's cool, because I'm a little sick of the assumptions that someone has access to resources because they maintain X package. Not everyone listed on http://www.debian.org/devel/people is a full Debian Developer. As such, not all of them have access to the resources available to full Debian Developers, or even the rights of them. Yet, we are expected to function as one and are berated by some DDs when we state we don't have access to some resources. -- Jamin W. Collins This is the typical unix way of doing things: you string together lots of very specific tools to accomplish larger tasks. -- Vineet Kumar
Re: Future releases of Debian
On Thu, 2003-07-24 at 19:34, Jamin W. Collins wrote: On Thu, Jul 24, 2003 at 08:25:16PM +0200, Robert Lemmen wrote: On Thu, Jul 24, 2003 at 08:39:11PM +0300, Halil Demirezen wrote: Are we in dilemma on should we support arch that are not used widely? or We should support all architectures what i prefer is the second one. me too! any package that doesn't build on m68k or arm is broken and needs to be fixed, even if it works on x86 by chance! So, are you volunteering to help those of us without access to either of the above architectures with bugs found in our packages? I'm not saying that all architectures shouldn't be supported equally. I just don't have access to either of the above architectures to correct problems found in my packages. Strange, the rest of us Debian Developers have access to all of these strange platforms ... http://raw.no/debian/machines.html If your package has a bug affecting arm, login to debussy and fix it. If your package has a bug affecting mips, login to casals and fix it. If your package has a bug affecting m68k, login to kullervo and fix it. If you're going to claim that you don't have the knowledge to investigate and fix difficult problems, perhaps you should reconsider whether you are able to maintain your packages? I'm sure the box admins will happily set up a chroot wrapper for d-i work if you ask them nicely. Scott -- Who is sick of this I don't have an m68k box to fix my bug excuse. signature.asc Description: This is a digitally signed message part
Re: Future releases of Debian
On Fri, Jul 25, 2003 at 05:31:36PM +0200, Adrian Bunk wrote: On Thu, Jul 24, 2003 at 02:23:30PM -0600, Jamin W. Collins wrote: Now you're assuming that I have access to the Debian machines. TMK, these machines are *not* public access machines, but instead are accessible to full DDs only. This excludes all new maintainer applicants, myself included. The DAM discussion is a different discussion, no need to restart it in this thread. I didn't attempt to restart it, I simply point out a flaw in the argument provided. There are at least two ways how you can get an account on a machine in such a situation: - ask the Debian admins for a guest account on a machine of this architecture I was not aware that this was an option. Is this documented somewhere as an option to NMs or others? I for one never considered it because TMK it was restricted to full DDs only. If this is not the case, documentation to that effect could be very helpful. -- Jamin W. Collins Remember, root always has a loaded gun. Don't run around with it unless you absolutely need it. -- Vineet Kumar
[custom] Some issues for custom debian distributions
As discussed during debcamp in Oslo, all the groups/projects making debian based custom distributions should join together to find common solutions to the common problems. This is a start, with a few of the issues that Skolelinux had and solved. - Automatic installation Using the new debian-installer and a few hooks to get the partitioning we want and the packages we want installed into the hard drive. I'm fairly satisfied with this solution. - Installing the list of package we want Using meta-packages (ie packages consisting only of dependencies) to install the packages we want. Used hooks in base-config to get them installed during first time installation. Not too happy about the meta-package approach, as it is fragile and break easily if some dependency is unavailable. - Preconfigure the packages we install Using two different approaches: (1) Load answers into the debconf database before the packages are installed using some home-make scripts, and (2) rewrite/replace configuration files using cfengine at the end of the installation if the package is unable to configure what we want using debconf. I'm fairly satisfied with this solution, but am not sure if the method used to feed the debconf database is the best available. I believe the best option would be to extend all the packages we use to make it possible to configure everything we need using debconf answers. - Automatic X configuration Using home-brewed script filling the debconf database, and then call dexconf from the xfree86 package to generate the configuration file. The HW detection info is fetched from various packages (discover, kudzu, detect, etc). - CD building Using a heavily patched version of debian-cd to create the CDs. Most of the patches is to include the d-i boot floppies. This should now be possible with the standard version of debian-cd, but no one in Skolelinux have taken the time to update our copy of the scripts. - Configure default language for all users Using a custom script to rewrite config files to modify the default language/locale. - Making simpler KDE menus Working on a system to make simple menus and change the menu depending on the users group membership. There are probably others, but this should be a good starting point. Are these issues common to other custom distros? How did you solve the problem?
Re: Future releases of Debian
On Thu, 2003-07-24 at 21:23, Jamin W. Collins wrote: Now you're assuming that I have access to the Debian machines. TMK, these machines are *not* public access machines, but instead are accessible to full DDs only. This excludes all new maintainer applicants, myself included. Ask the admin for a guest account because you want to do some bug fixing work. It's bound to help your NM application get processed faster than sitting around and whining that you can't get anything done. Scott signature.asc Description: This is a digitally signed message part
Re: Future releases of Debian
On Fri, 2003-07-25 at 16:40, Jamin W. Collins wrote: On Fri, Jul 25, 2003 at 04:25:57PM +0100, Scott James Remnant wrote: On Thu, 2003-07-24 at 19:34, Jamin W. Collins wrote: So, are you volunteering to help those of us without access to either of the above architectures with bugs found in our packages? I'm not saying that all architectures shouldn't be supported equally. I just don't have access to either of the above architectures to correct problems found in my packages. Strange, the rest of us Debian Developers have access to all of these strange platforms ... http://raw.no/debian/machines.html By the rest of us Debian Developers I assume you mean *full* Debian Developers (those of you with DD accounts). Perhaps you haven't read the rest of this thread. I'm not a *full* DD and thus don't have access to all the resources a *full* DD has. As I've inferred elsewhere this is one of the problems with keeping NMs in queue waiting on one approval for several months (and potentially years). Incorrect. You have access to the full resources, just not automatically. You can maintain packages as easily as a full developer can, you just need a sponsor to upload it for you. You can get accounts on these machines, you just need to ask first. You appear to be suffering from a lack of initiative. If your package has a bug affecting arm, login to debussy and fix it. If your package has a bug affecting mips, login to casals and fix it. If your package has a bug affecting m68k, login to kullervo and fix it. Would be happy to. Unfortunately, I can't, don't have an account. Ask for one then. Sheesh, with this defeatist attitude how do you ever expect to become a D-D? Who is sick of this I don't have an m68k box to fix my bug excuse. That's cool, because I'm a little sick of the assumptions that someone has access to resources because they maintain X package. Not everyone listed on http://www.debian.org/devel/people is a full Debian Developer. As such, not all of them have access to the resources available to full Debian Developers, or even the rights of them. Yet, we are expected to function as one and are berated by some DDs when we state we don't have access to some resources. I think other answers in this thread speak for themselves. If you've not even tried asking for an account to fix some bugs, then you're obviously not that interested fixing them. Scott signature.asc Description: This is a digitally signed message part
Re: update-alternatives priorities for editors
Colin Watson wrote: On Fri, Jul 25, 2003 at 11:05:25AM +0200, Michael Piefel wrote: Am 25.07.03 um 09:21:47 schrieb Colin Watson: /usr/bin/editor is not only something invoked directly. It's also invoked by programs as the default editor. Shouldn't that be sensible-editor? Which calls editor if $VISUAL and $EDITOR aren't set, yes. Interesting that if sensible-editor fails to find $VISUAL, $EDITOR, 'editor' that it tries 'ae' and then 'vi'. I could find no reference to /usr/bin/ae in the package contents of any Debian package. Does it exist? (I remember it being an 'ee' type of program.) In the current distribution it should probably call 'nano' as the first fallback. I will file a minor bug in a little bit about it. Bob pgpRd02Rr7C5d.pgp Description: PGP signature
Re: update-alternatives priorities for editors
Colin Watson wrote: Bob Proulx wrote: I personally would not have had either elvis or vim supply an alternative for /usr/bin/editor. I don't mind lowering the priority of vi clones, or whatever; but please don't try to get them removed from the editor alternative. It's quite sufficient to have higher-priority editors installed by default. Just to clarify, I am not advocating a change here. What I meant was that I would not have done it that way myself had I been doing it when it was originally done. But having been done so long ago it should probably stay like it is. Like many things, once broken it must always be broken or something else breaks. Bob pgpTCKL3drhvp.pgp Description: PGP signature
Re: gnupg - old bugs
On Thu, Jul 24, 2003 at 04:03:21PM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: On Wednesday 23 July 2003 22:44, Branden Robinson wrote: Please send these individual pieces of commentary/feedback to the bugs themselves as well. I'll do it in those cases where my commentary is not just a summary of the information already present in the bug - in some cases 'this doesn't happen anymore, can we close it' was already added and the bug is still open and not tagged woody - I don't see what adding this comment again serves... I agree. What you just proposed is exactly what I was asking for. Thanks! -- G. Branden Robinson| Reality is what refuses to go away Debian GNU/Linux | when I stop believing in it. [EMAIL PROTECTED] | -- Philip K. Dick http://people.debian.org/~branden/ | pgpzo95Mt0Vy0.pgp Description: PGP signature
Re: Future releases of Debian
On Jul 25, Adrian Bunk [EMAIL PROTECTED] wrote: Could you give examples of your nobody has enough time or interest to fix toy architectures? I already gave many in this thread. -- ciao, | Marco | [1008 afu6BxGoAAolg]
Re: [custom] Some issues for custom debian distributions
* Petter Reinholdtsen - Preconfigure the packages we install Using two different approaches: (1) Load answers into the debconf database before the packages are installed using some home-make scripts, and (2) rewrite/replace configuration files using cfengine at the end of the installation if the package is unable to configure what we want using debconf. I'm fairly satisfied with this solution, but am not sure if the method used to feed the debconf database is the best available. I believe the best option would be to extend all the packages we use to make it possible to configure everything we need using debconf answers. God, No! There's far too many Debconf questions being asked by various Debian packages already, IMNSHO. If something like this should be implemented, I'd like to see these questions only be asked at reconfigure time, or not asked at all. That way Skulelinux could preseed the Debconf database and get the package working the way you want, while I can install Debian without going nuts about all the questions I'm asked. However, the best solution I can think of right now would be to implement diversion support for conffiles in dpkg, so you could create a 'skolelinux-config' package which contained (or generated) configuration files attuned to Skulelinux, where necessary. -- Tore Anderson
Re: update-alternatives priorities for editors
On Fri, Jul 25, 2003 at 10:11:05AM -0600, Bob Proulx wrote: Colin Watson wrote: On Fri, Jul 25, 2003 at 11:05:25AM +0200, Michael Piefel wrote: Shouldn't that be sensible-editor? Which calls editor if $VISUAL and $EDITOR aren't set, yes. Interesting that if sensible-editor fails to find $VISUAL, $EDITOR, 'editor' that it tries 'ae' and then 'vi'. I could find no reference to /usr/bin/ae in the package contents of any Debian package. Does it exist? (I remember it being an 'ee' type of program.) It used to exist, but was removed back in 2001; see bug #110678. In the current distribution it should probably call 'nano' as the first fallback. That's exactly what the version in testing and unstable does. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Future releases of Debian
On Fri, Jul 25, 2003 at 09:45:01AM -0600, Jamin W. Collins wrote: ... There are at least two ways how you can get an account on a machine in such a situation: - ask the Debian admins for a guest account on a machine of this architecture I was not aware that this was an option. Is this documented somewhere as an option to NMs or others? I for one never considered it because TMK it was restricted to full DDs only. If this is not the case, documentation to that effect could be very helpful. I don't know whether it's documented somewhere. All I know is that it worked in the past and it's worth trying it. Jamin W. Collins cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
Re: Future releases of Debian
Discussing via emails seems to get hard again... * Joey Hess [EMAIL PROTECTED] [030725 16:37]: Bernhard R. Link wrote: Both a system presenting a utter mess of uneeded things and technical terms and a system only saying Installation successful or Installation failed are two ends of user-unfriendly behaviour. While the first can be at least cured with a good documentation, the last is simply frustrating. Luckily d-i falls in neither of these camps, Did I ever said it was? since there are some smart people working on it. Did I ever doubt this? I think you'd better use your time by learning about and contributing to d-i, rather than writing uninformed, generic commentary. Thanks. If I'm discussing a generic topic (what is userfriendly), I'll use generic commentary. And contributing to the debian-installer can by no why done in the time of writing few e-mails. (I don't want count the hours and days I could have used for something reasonable, in whose I waited for build chroot's to be made, bochs or plex86 to be started on 200 Mhz machines. In whoose I negatively investigated if a genfat (including syslinux) was writteable in readonable time to get around the root-problem, in which looked for hardware to test d-i, looked if I could get a 2.4 or any form of devfs compiling nicely for 2 sparc10 I could reserve for this purpose, the time I used to get some SGI Indies, coping with the weak-symbol-problem there, trying build debug-version of tip22, just to realize that one of the bioses is broken. And all those nasty things one needs many time to work around without any chance to get anything commitable...) Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Re: Future releases of Debian
On Fri, Jul 25, 2003 at 06:46:16PM +0200, Adrian Bunk wrote: On Fri, Jul 25, 2003 at 09:45:01AM -0600, Jamin W. Collins wrote: ... There are at least two ways how you can get an account on a machine in such a situation: - ask the Debian admins for a guest account on a machine of this architecture I was not aware that this was an option. Is this documented somewhere as an option to NMs or others? I for one never considered it because TMK it was restricted to full DDs only. If this is not the case, documentation to that effect could be very helpful. I don't know whether it's documented somewhere. All I know is that it worked in the past and it's worth trying it. It's certainly worth trying, and I'll keep it in mind. However, the information I did find on it lead me to believe it would be pointless to request access to these machines since they were for Debian Developers only, and they would get access (more or less automatically) because they were a Debian Developer. -- Jamin W. Collins This is the typical unix way of doing things: you string together lots of very specific tools to accomplish larger tasks. -- Vineet Kumar
Re: update-alternatives priorities for editors
Manoj Srivastava [EMAIL PROTECTED] writes: On Fri, 25 Jul 2003 09:21:47 +0100, Colin Watson [EMAIL PROTECTED] said: /usr/bin/editor is not only something invoked directly. It's also invoked by programs as the default editor. And, if vim is the only editor installed on the system, it had better be the default editor for such programs! Is that not an argument for emacs also providing /usr/bin/editor alternatives, since emacs may be the sole editor on the system? It might just not be very useful by default since Emacs usually takes quite some time to startup, and therefore people prefer to use emacsclient if they really set $EDITOR to something emacsish. OTOH, for emacsclient to work, you actually need some code in your .emacs, like (add-hook 'after-init-hook 'server-start) P.S.: Tip of the day (add-hook 'server-done-hook (lambda () (shell-command screen -r -X select `cat ~/tmp/emacsclient-caller`))) -- CYa, Mario
Re: Future releases of Debian
Hi, Eduard Bloch wrote:
There were no emotion. I just listed facts;
Sorry, but using the word crap crosses the line between fact and emotion.
We can't find a good solution to this problem, if indeed there is one,
if all we have is two rows of people on different sides of a long table,
shouting at each other.
Exactly. If you had nothing productive to add to the discussion, why do
you participate then?
If you think that cautioning people not to use loaded language is
unproductive to you, then ... well, all I am going to say is that
I disagree. Rather strongly, in fact.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
You shall reach the pinnacle of success because of your total lack of ethics.
Re: unicode
On Fri, Jul 25, 2003 at 05:19:24PM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: On Friday 25 July 2003 12:21, Colin Watson wrote: On Fri, Jul 25, 2003 at 11:43:15AM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: Hmmm. This is really funny. Look at http://fortytwo.ch/~avbidder/man-page.png. What versions of man-db and groff are installed, and what pager (and version of same) are you using? The latest, afaict (excluding experimental) ii man-db 2.4.1-10 The on-line manual pager ii groff-base 1.18.1-9 GNU troff text-formatting system (base syste ii less 381-2 A file pager program, similar to more(1) ii konsole3.1.1-1KDE X terminal emulator Oh, konsole? No idea, as I don't use KDE. I saw your mentions of font problems elsewhere in this thread. Have you tried, say, uxterm with a known-good UTF-8 font? I use '-misc-fixed-medium-r-normal--15-140-75-75-c-*-iso10646-1' on my work machine. Have you seen bug #191985? Sometimes all '-' characters (don't know how if they're hyphens or minus or em-dashes) are affected, and sometimes only few of them (only hyphens or so). That's going to depend on the man page. I'm sure that if you look at the man page source you'll find that - is affected while \- isn't. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Future releases of Debian
On Fri, Jul 25, 2003 at 09:40:44AM -0600, Jamin W. Collins wrote: On Fri, Jul 25, 2003 at 04:25:57PM +0100, Scott James Remnant wrote: On Thu, 2003-07-24 at 19:34, Jamin W. Collins wrote: If your package has a bug affecting arm, login to debussy and fix it. If your package has a bug affecting mips, login to casals and fix it. If your package has a bug affecting m68k, login to kullervo and fix it. Would be happy to. Unfortunately, I can't, don't have an account. Have you tried asking for one from the admins? Have you tried asking debian-devel for a system to work on? I've not seen any request for an account to work with that hasn't been quickly answered by 3-4 offers. Hell, I've got a sparc32, sparc64, PPC (oldworld Mac), and mipsel system lying around I'd be willing to plug in if somebody needed them. It wouldn't be any trouble to get a serial console and X10 power switch on any of them for D-I testing even. The reason I havn't offered them for general Debian machines is that there are already (generally better) machines available on better connections. - Nick Lopez [EMAIL PROTECTED] kimo_sabe on FreeNode -- Randomly selected signature -- Everything in the world can be divided into things you can lick, and things you shouldn't lick.
Re: Future releases of Debian
Nick Lopez [EMAIL PROTECTED] writes: The reason I havn't offered them for general Debian machines is that there are already (generally better) machines available on better connections. Last I checked, there weren't any public mips or mipsel machines. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: surfraw ultimatum
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, The surfraw project is up on alioth now. I'm not very experienced with CVS (i've only really used Subversion, and that not very extensively---do we want to use svn.debian.org instead of CVS? or does it interoperate? or just stick to cvs?), so could someone else do the initial import? I've so far added Stephen and Christian to the project, I don't know Adam or David's handles on Alioth. What are they? Have a nice day! - -thomas p.s. sorry for the huge CC: list, hopefully soon we can just discuss on mailing lists---one is automagically created for surfraw right? Wheee. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/IWaQ/xuE/qyrqB4RAsclAKCIs7QcDEIqSe8tg6YZj6XGZwe28wCgktZH hD8VskGbprbzUPZ/IFJvCTw= =k14m -END PGP SIGNATURE-
Re: Future releases of Debian
On Fri, Jul 25, 2003 at 01:37:15PM -0400, Aaron M. Ucko wrote: The reason I havn't offered them for general Debian machines is that there are already (generally better) machines available on better connections. Last I checked, there weren't any public mips or mipsel machines. You checked too long ago. Casals.debian.org is an SGI Indigo2, MIPS R4000 CPU. Williams.debian.org and vaughan.debian.org will be MIPSel boxes, as soon as Sun ships them to me, I get them online, and the sysadmin team gets them configured. Supposedly I'll have the boxes within a week or so. noah
Re: Future releases of Debian
You checked too long ago. Casals.debian.org is an SGI Indigo2, MIPS R4000 CPU. Williams.debian.org and vaughan.debian.org will be MIPSel boxes, as soon as Sun ships them to me, I get them online, and the sysadmin team gets them configured. Supposedly I'll have the boxes within a week or so. I do not know whether there is, but, what about making a architecture archive for debian package managers to use, test, update their packages on them? for example. let parisc.debian.org be a machine where on it a Debian runs (parisc arch) or sparc64.debian.org which is a sparc64 architecture sincerely.. pgpU1TFJmkKpD.pgp Description: PGP signature
Re: [custom] Some issues for custom debian distributions
On Fri, 25 Jul 2003 18:28:27 +0200 Tore Anderson [EMAIL PROTECTED] wrote: * Petter Reinholdtsen - Preconfigure the packages we install I believe the best option would be to extend all the packages we use to make it possible to configure everything we need using debconf answers. God, No! There's far too many Debconf questions being asked by various Debian packages already, IMNSHO. If something like this should be implemented, I'd like to see these questions only be asked at reconfigure time, or not asked at all. That way Skulelinux could preseed the Debconf database and get the package working the way you want, while I can install Debian without going nuts about all the questions I'm asked. If is debconf used 'the right way' (tm) it is only a blessing. The only thing maintainers should do is assign the right priority to a question (Well and of course take care that all changes to configuration files are preserved). That way people that want automation or just like questions get what they want and people that want to rewrite configuration files just set a high priority and get a nice and quite apt-get update/install. grts Tim
Re: Future releases of Debian
I do not know whether there is, but, what about making a architecture archive for debian package managers to use, test, update their packages maintainers.. pgpc9w36PWV3K.pgp Description: PGP signature
Re: Future releases of Debian
Scott James Remnant [EMAIL PROTECTED] writes: If your package has a bug affecting arm, login to debussy and fix it. If your package has a bug affecting mips, login to casals and fix it. If your package has a bug affecting m68k, login to kullervo and fix it. Have I missed something? I can't just log in and install packages on those machines, right? Multi media programs would also be a pain to debug this way and even single non-text media programs could be a pain. And it is my experience that next to pure toolchain-problems it is this kind of programs having most porting problems. -- Peter Makholm |One thing you do is prevent good software from [EMAIL PROTECTED] | being written. Who can afford to do professional http://hacking.dk | work for nothing? | -- Bill Gates
