Re: RFC: GUI tools for common Debian admin tasks
On Tue, 5 Sep 2000, Frederic Peters wrote: > don't have tested yet. It would be a good idea to avoid duplicated work. So why not linuxconf? AFAIK it's the most powerful conftool around and there's *even* a .deb version of it. Further on it's pretty trivial to write modules for it and once done you can interface to the conftool through the command line, the web, textinterface, x-interface, ... So, yes, why reinvent the wheel, if there are allready n^x conftools around with a new one popping up monthly (webmin, COAS, linuxconf, debconf, yast, ..., ..., ...) ? It's not going to make anything easier. *t Tomas Pospisek SourcePole - Linux & Open Source Solutions Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: 081 330 77 11 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
ITP: xxdiff
On Sun, 10 Sep 2000, Tommi Virtanen wrote: > Package: wnpp > Severity: wishlist I intend to package it. This is my first task in order to become Debian developer... *t Tomas Pospisek SourcePole - Linux & Open Source Solutions Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NMUers: STOP BEING STUPID
On Tue, 24 Apr 2001, Richard Braakman wrote: > Oh, I didn't mean _only_ sending the diff. It was an addendum > to Shaleh's suggestion. The idea is to send the diff, then have > someone else look at it, and then do the NMU. You could just drop the NMUed package into some public space (http://my.home/nmued_package.deb) for the proposed review. That way it'd be even easier for the reviewer to check, extracting the diff'd be trivial, one could even use interdiff to see the differences between NMU and the last official version. *t Tomas Pospisek SourcePole - Linux & Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: auditd as logrotate replacement?
Hi Arthur and discussion round, On Wed, 25 Apr 2001, Arthur Korn wrote: > So, basically, since auditd does feature encryption, it does not > have any chance to be the default for log rotation, even if it > was a lot better than logrotate? What giant pile of crap. But what you could do is a virtual package that depends either on logrotate or auditd. That way the user *has* to install a logrotater but can choose between the two options. Or am I missing sth? *t Tomas Pospisek SourcePole - Linux & Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: Lightweight Web browsers
Jerome wrote: > Listen, I've packaged it in order to make available in debs for > people willing to test it. Now, don't blame me about those gnome > dependencies since [...] > Please note that did not ITPed it since I'm not sure people except > from me are interested in such a browser. And It does not seem to make > you very happy. Unless people are interested to see it in debian > I won't upload it. Please if you think it's useful do upload it. I've seen one person that'd like to have it, but you won't know about the user's not on devel... And please do not get annoyed by people that have mental barriers to be responsible for them selves and the (dependent) stuff hey download. *t Tomas P.
Re: searching for Tomas Pospisek [Mailer-Daemon@master.debian.org: Mail delivery failed: returning message to sender]
OK, thanks a lot, I'll take care of that, I hadn't realized, that my email address was wrong. I'll correct that ASAP. *t Tomas Pospisek SourcePole - Linux & Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: support for older distributions
On Tue, 8 May 2001, Russell Coker wrote: > But if someone is willing to back-port a package, and to maintain it > (fixing any bugs that may be reported against it), then why not make > room on the archives for it? Would there be any problem to just set up your own Debian-style site with BTS and apt-able archive, where people can contribute if they want and where you can semi-automatical merge in upstream (here Debian) updates (mostly critical bugs and security updates)? *t Tomas Pospisek SourcePole - Linux & Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: isync vs mailsync
On 4 Sep 2001, Brian May wrote: [...] > MAILSYNC Has been in use here for 9 months without a flaw... > > PROS: [...] > - can delete deleted messages (not tested). ...this feature works here. > - can create and delete folders (not tested). Dito. [...] > CONS: > > - upstream author seems to be really anti-maildir, although maildir > patches have been included in Debian version. Just to clarify: you're talking about Mark Crispin the author of the UW-suite, which includes c-client, a mail-access library. The upstream author of mailsync is Tim Culver, who's not oposed to any such things :-) On a sidenote: I have been submerged (which nearly periodically happens in fact) by professional work the last two weeks so sorry you haven't got any reply from me yet to your reports (thanks!). The same is true for the upstream author. He's been looking for people who'd maintain (integrate patches, extend it etc.) mailsync. So if you, or anybody who's interested, wants to work on mailsync, add features, remove bugs or help maintaining the Debian packge - you are more then wellcome. *t Tomas Pospisek SourcePole - Linux & Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: step by step HOWTO switch debian installation into utf-8
Btw: > http://melkor.dnp.fmph.uniba.sk/~garabik/debian-utf8/HOWTO Does not serve any pages to me - it's pingable though. If you've got problems with that server you could put the HOWTO on the debian servers or if that's a problem I'd gladly put it up at our site. *t Tomas Pospisek SourcePole - Linux & Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: 2.4 bootdisk for testing?
Make sure you have ECN disabled on those bootdisks otherwise some people will be finding out that to their surprise they are not able to download their packages via the network. See the recent ECN thread. *t Tomas Pospisek SourcePole - Linux & Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: sysctl should disable ECN by default
On Wed, 5 Sep 2001, Guillaume Morin wrote: > Dans un message du 05 sep à 14:37, Florian Weimer écrivait : > > From a technical behavior, throwing away packets with unknown protocol > > flags is perfectly acceptable in any case and even reasonable in some > > environments. > > I would not call reasonable dropping packets carrying bits of a protocol > rated as Proposed Standard by IETF. The question is only if devices should be programmed in order to know the future and it's potential proposed stadards by the IETF. Mind you I don't know if the devices in question (websites, routers etc. droping ECN packets) *are* violating a standard that was current at *their* time. The routers in particular I think *are* wrong, since they are making decisions based on bits that at that time were reserved. But tell me, in case there's an IMAP client that has some problems with the IMAP protocol. Should a Debian box by default *refuse* to talk to it or should the default be to try to talk to it (provided that it can)? With ECN set, Debian's default is to plain *refuse* to talk to all equipment which, for whatever reason has problems with ECN. *t Tomas Pospisek SourcePole - Linux & Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: sysctl should disable ECN by default
On Wed, 5 Sep 2001, Eric Van Buggenhaut wrote: > On Sun, Sep 02, 2001 at 12:56:18AM +0200, Tomas Pospisek wrote: > > > > It's not only *sites* that do not work with ECN. It's also *routers*. That > > means if you have *one* router between you and your destination, that does > > not > > support ECN, then you'll get *very* strange behaveour like hanging TCP > > connections that somehow get halfway through but do hang never the less > > while > > ping works. Please check my bugreport #110862. And amongst the broken > > equipment > > are f.ex. (older?) Zyxel ISDN routers which are *very* popular. > > FYI, > >Zyxel 681 SDSL-Router breaks ECN by stripping 0x80 (ECN Cwnd Reduced) but > not 0x40 (ECN Echo) (TOS bits) on all SYN >packets. This is the last official firmware. A beta firmware is available > internally which fixes this issue: (ZyXEL >firmware v2.50(T.05)b6 | 03/28/2001) So it's not only old routers. It's also new ones. Zyxel didn't get it. But until this day Debian didn't get it either. Whoever owns a Zyxel router that has this bug will be into troubles with Debian unless s/he's a netwoking nerd that knows about ECN. Go figure. And while we're at it - if you happen to stumble accross a firmware-fix for the Zyxel Prestige 2864i please point me to it. Because untill I fix that, one of our customers will be runing a broken network. *t Tomas Pospisek SourcePole - Linux & Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: reopening ECN bugreport/netbase
On Wed, 5 Sep 2001, Tomas Pospisek wrote: > So *please* can we add something like: > > if ! grep /proc/sys/net/ipv4/tcp_ecn /etc/sysctl.conf >/dev/null; > then echo sys/net/ipv4/tcp_ecn=0 >> /etc/sysctl.conf > fi > > to the kernel-image-2.4.x postinst. Which of course will set up people who are stil runing potato, have a 2.4 kernel and *do* want/need ECN, since it will *silently* disable ECN. So since netbase does not want to be the proper place, a better fix/workaround (I'm sincerely trying hard not to be ironic!) would be to use debconf with a default value of "0" and to inform/ask the user about it when installing a new kernel. *t Tomas Pospisek SourcePole - Linux & Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: sysctl should disable ECN by default
On Wed, 5 Sep 2001, Guillaume Morin wrote: > Dans un message du 05 sep à 17:30, T.Pospisek's MailLists écrivait : > > The question is only if devices should be programmed in order to know > > the future and it's potential proposed stadards by the IETF. Mind you I > > don't know if the devices in question (websites, routers etc. droping ECN > > packets) *are* violating a standard that was current at *their* time. The > > routers in particular I think *are* wrong, since they are making decisions > > based on bits that at that time were reserved. > > It is not a good debate. Devices can be upgraded. Net admins should do > their job. You will not be able to upgrade a Zyxel Prestige 2864i. And a lot of other old equipment. > > With ECN set, Debian's default is to plain *refuse* to talk to all > > equipment which, for whatever reason has problems with ECN. > > Debian default does not refuse to talk, it is the broken > routers/firewalls which do. Yes - it does. By knowingly setting a flag which is known (!) to cause trouble. > Should we stop progress because admins do not their job. I do not think > so. There is no one taking your right away to: echo 1 > /proc/sys/net/ipv4/tcp_ecn and march ahead on the edge of progress. It's another thing though to set this flag on default and leave the user in the dark why wondering why suddenly connectivity has ceased. Which is what Debian does. *t Tomas Pospisek SourcePole - Linux & Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: sysctl should disable ECN by default
On Wed, 5 Sep 2001, Steve Langasek wrote: > On Wed, 5 Sep 2001, T.Pospisek's MailLists wrote: > > > On Wed, 5 Sep 2001, Guillaume Morin wrote: > > > > Dans un message du 05 sep à 14:37, Florian Weimer écrivait : > > > > From a technical behavior, throwing away packets with unknown protocol > > > > flags is perfectly acceptable in any case and even reasonable in some > > > > environments. > > > > I would not call reasonable dropping packets carrying bits of a protocol > > > rated as Proposed Standard by IETF. > > > The question is only if devices should be programmed in order to know > > the future and it's potential proposed stadards by the IETF. Mind you I > > don't know if the devices in question (websites, routers etc. droping ECN > > packets) *are* violating a standard that was current at *their* time. The > > routers in particular I think *are* wrong, since they are making decisions > > based on bits that at that time were reserved. > > The devices in question *are* violating the standards that existed at the time > they were created. The bits that they're fiddling with are *reserved*. That > means "don't touch". They were in violation of the TCP/IP protocol from day > one, it's just that it's only now that the IETF is making use of those bits, > /as is their right/, that the problem with this equipment has come to light. That's what I was saying wasn't I? > > But tell me, in case there's an IMAP client that has some problems with > > the IMAP protocol. Should a Debian box by default *refuse* to talk > > to it or should the default be to try to talk to it (provided that it > > can)? > > Are you joking? If someone filed a bug against my package saying I should > make changes to it to accomodate a broken client (equivalent: my IMAP server > sends back a valid IMAP response and this causes the client to segfault), I > would immediately close the bug with a smile and a have-a-nice-day. Good for you. And the people that *need* a working server as in "it forks for *me*" will move on and ignore you. That's your choice. It's the choice Debian is making now. But if care about the real world you will see that the philosophy of most software isn't "I'm right have-a-nice-day" but let's have "something that works". Check the kernel. Check IMAP servers (that's why I was choosing this example), check well whatever, many things try to cooperate with broken stuff. > Anyone using such broken software should do the right thing, which is one of: > > a) get a different IMAP client If you have the choice. Which is an open question. > b) get an upgrade/fix for the IMAP client so that it's no longer broken. If there is one. Which still is an open question. > c) sue the vendor for selling a product under false pretenses, with the > goal of achieving either a) or b) above. Do *you* do that for all the things that don't work as they should? And even if, why should you force others to behave similary? > The same applies to these POS Zylex routers. There's no reason that Debian > should be covering their asses when they refuse to provide firmware upgrades > to their customers in a timely manner, especially when everyone else on the > Internet has been ready to go with ECN for some time now. There are a *lot* of places that are not reachable. "Everyone else" doesn't reflect any reality. But the question is if it's worth it for Debian to keep this anal "I am right" position, just because of a flag, whose existence aparently doesn't hurt people who're runing 2.2.x, which is *by default* disabled upstream (take a second and ask yourself, why could this be?). What's certain is, that it's going to hurt a lot of people. Maybe a quote from the kernel docu can help: > Note that, on the Internet, there are many broken firewalls which > refuse connections from ECN-enabled machines, and it may be a while > before these firewalls are fixed. Until then, to access a site behind > such a firewall (some of which are major sites, at the time of this > writing) you will have to disable this option, either by saying N now > or by using the sysctl. > > If in doubt, say N. Obviously, Debian is not in doubt about it's own users and knows better. *t PS: Since you're Cc:ing me in addition to the list, you maybe need an extra copy as well. Tomas Pospisek SourcePole - Linux & Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: reopening ECN bugreport/netbase
On Wed, 5 Sep 2001, Eric Van Buggenhaut wrote: > Routers aren't forced to support ECN (although it's in their interest) but > they > aren't allowed to drop ECN-flagged TCP packets. > > If you can't access a site, *they* need to fix their buggy router to be > ECN-tolerant. If they don't do so, they're violating RFC 793. Well possibly you can just send a site that doesn't support ECN to where the light don't shine. But if *your* (as in your universities, your lan's, your workplace, your client's etc.) router is broken then what? Then you can not ignore it. But they can ignore *you*! And there is equipment that *can not* be fixed (check the thread why not). And so what do you expect a user (possibly a newby!!! mind you, there are newbies that start with Debian) with a 2.4 Debian kernel to do? To start debuging the network to find out what the hell is wrong? To look around and think gee, all the machines around me are working *only mine* not. What would *you* think at that moment? I would maybe think that the networking card is broken. So you are telling me you want to send (your!) Debian users runing around expecting them to go debug whatever place they might find themselves at that moment? Or do you expect to change the world to change at your will just because Debian has decided to set a flag which is *off* by default? *t Tomas Pospisek SourcePole - Linux & Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: sysctl should disable ECN by default
On Wed, 5 Sep 2001, Steve Langasek wrote:
> > Do *you* do that for all the things that don't work as they should?
>
> Yes, quite frankly. Personally, I use only Free Software and software
> that runs on top of Free OSes. Professionally, I work for an ISP, and
> we expect our vendors to live up to the promises they make.
If that's the case then shouldn't we disable all those kernel
compatibility hacks by default? Don't tell me your machine is clean, and
all those components are 100% protocol compliant.
Btw. since you are connected through alternet which servers you through
*Cisco* routers:
tpo2:/home/tpo/# traceroute www.netexpress.net
traceroute to shamu.netexpress.net (206.65.64.2), 30 hops max, 40 byte
packets
[...]
12 netexpress-gw.customer.ALTER.NET (157.130.101.102) 187 ms 173 ms 187 ms
13 shamu.netexpress.net (206.65.64.2) 174 ms 189 ms 170 ms
tpo2:/home/tpo/# xprobe 157.130.101.102
[...]
FINAL:[ Cisco IOS 11.x-12.x ]
please live up to your claim and sue Cisco for their bloody CiscoPPP which
in the "early days" wouldn't allow you to connect a standard PPP device to
it, will you?
> At least this way, users who have broken routers will find out about the
> problem early, can easily disable the ECN behavior if they need to, and
> can set about finding a solution to the real problem.
[...]
> Professionally, I work for an ISP, and we expect
Yup. So did I. And that's why I was able to find out in the first place.
But let's see how "easy" that is. Please take an average Debian user. Give
it a machine that run's a 2.4 kernel behind an ECN-broken router and see
how long it takes for him to figure out what's wrong.
Or in other words, please take the same default install of Debian with a
2.4 kernel and then do this:
# find / -exec grep -i "ECN" \{\} \;
And tell me how many pointers to ECN you'll find. Easy?
> In addition, ECN provides some significant advantages for users who aren't
> afflicted with Zylex routers.
Why is it that you are mixing up Zyxel and Zylex. Let me guess: you don't
have ISDN around. Now let me tell you that possibly Zyxel is the biggest
SOHO ISDN router vendor in Europe. So what? At least it's a nice exercise
for the users isn't it? It gives them deep insight into networking. So in
the end you are doing a favour to everybody, right? Where is the
semi-professional network admin that hasn't wished his whole life through
to be able to spend two days debuging a newly arived Debian box that *as
only machine* in the whole LAN isn't able to route out?
> I don't dispute that there are many cases where software authors are willing
> to accomodate broken client / server behavior, whether their goal is market
> share or mind share. I just disagree that authors/maintainers have any
> *obligation* to accomodate software or hardware which is not
> standards-conformant.
>
> The solutions proposed to date all seem to be either contrary to policy, or
> contrary to the wishes of the maintainers of the affected packages. Under
> such circumstances, I don't see where there's cause for questioning the
> maintainers' decisions.
You are right. A package maintainer - even if it's a fundamental package
as dpkg or the kernel or whatever can go and screw his users. It's up to
him. I wouldn't go as far as saying that this is precisely happening here,
at least not consciously because I doubt anybody who's pro ECN in the
kernel has had to debug a situtation such as described above.
But you can sure tell from my enthusiasm, and I'm no networking idiot,
that I *do* feel strong about it and that's exactly because I had fun
lately with it and I don't think it's necessary for everybody who happens
to have the bad luck to find itself in the same position to forcibly
repeat that lovely experience. And you can be certain that if the
situation stays as it is, I will not be the last one.
But tell me *one* thing:
Why is it so hard to change a few lines and have the default be
set to *off* and let whoever feels like it enable it?
?!?!
*t
Tomas Pospisek
SourcePole - Linux & Open Source Solutions
http://sourcepole.ch
Elestastrasse 18, 7310 Bad Ragaz, Switzerland
Tel: +41 (81) 330 77 11
Re: reopening ECN bugreport/netbase
On Wed, 5 Sep 2001, Remco van de Meent wrote: > But anyway - I agree that Debian should not be too conservative with > regard to new networking technologies, so disabling ECN by default is > not something I'd like to see happen. Give the user some short > explanation and let him make the decision himself, I'd say. OK. How exactly should this be worded: "ECN is a routing protocol. Some equipment doesn't support ECN yet. Switching it on can break your networking and it will make some internet sites unreachable. If you want to disable ECN then select "No". Do you want to enable ECN: "Yes" "No"" And the default will be on "Yes". Would you say "Yes"? Or how exaclty do you want to phrase this to let the user make an informed decison? Moreover, what about bootfloppies. In case there will be bootfloppies, do you want to bother the user with such questions? Or do you want to have two versions of the kernel - one for the bootfloppies and one for the "maintree"? And what is *exactly* the problem of displaying: "ECN Disabled - Edit /etc/network/options to enable it" in the bootmessages and let the user switch it on if he wants? *t Tomas Pospisek SourcePole - Linux & Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: sysctl should disable ECN by default
On Thu, 6 Sep 2001, Alex Pennace wrote: > On Wed, Sep 05, 2001 at 02:37:06PM +0200, Florian Weimer wrote: > > Russell Coker <[EMAIL PROTECTED]> writes: > > > > > Why should the default configuration be changed to account for the > > > diminishing number of broken routers on the net? > > > > From a technical behavior, throwing away packets with unknown protocol > > flags is perfectly acceptable in any case and even reasonable in some > > environments. > > No, such bastardization of TCP/IP, while already rampant, has no place > on the Internet. While at the same time not properly functioning IMAP clients, browsers that are unable to correctly interpret HTML, SMB Machines that spew broadcasts, RIP being propagated who knows where, routes flapping etc. etc. has a place? No - you are right we have to sweep the place with a steel broom. And whoever behaves not in exact accordance with an RFC will immediately be exterminated by the Debian Intifada. Amen, *t Tomas Pospisek SourcePole - Linux & Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: Student Looking for A Final Year Project
Add versioning to debian packet management. Something like: # apt-get install package # # damn it broke my server again!! # apt-get rewind package *t Tomas Pospisek SourcePole - Linux & Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: proposal for an Apache (web server) task force
On Thu, 13 Sep 2001, Ardo van Rangelrooij wrote: > I would like to propose to form an Apache (web server) task force to > maintain the Apache packages currently maintained by Johnie Ingram > (netgod) (and potentially related packages if the need arises). The > current state of Apache and the recent need to fix at least some of the > outstanding bugs led me to the conclusion a more active maintenance of > these packages is needed. I agree. I can't remember the last time I did a "apt-get install apache" an I still had a running webserver. I would think this is mostly due to the maintainer having too much work on his hands and so not being able to finetune the upgrade process. Apache is a very popular package and so IMHO it would be good if it'd be in a perfect shape. *t Tomas Pospisek SourcePole - Linux & Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: proposal for an Apache (web server) task force
On Thu, 13 Sep 2001, Ardo van Rangelrooij wrote: > T.Pospisek's MailLists ([EMAIL PROTECTED]) wrote: > > On Thu, 13 Sep 2001, Ardo van Rangelrooij wrote: > > > > > I would like to propose to form an Apache (web server) task force to > > > maintain the Apache packages currently maintained by Johnie Ingram > > > (netgod) (and potentially related packages if the need arises). The > > > current state of Apache and the recent need to fix at least some of the > > > outstanding bugs led me to the conclusion a more active maintenance of > > > these packages is needed. > > > > I agree. I can't remember the last time I did a "apt-get install apache" > > an I still had a running webserver. I would think this is mostly due to > > the maintainer having too much work on his hands and so not being able to > > finetune the upgrade process. > > > > Apache is a very popular package and so IMHO it would be good if it'd be > > in a perfect shape. > > So I can count you in as a volunteer? As much as I'd like to - no, I've got too much on my hands with other stuff. But be sure that I'll send in the occassional patch or improvement suggestion. *t Tomas Pospisek SourcePole - Linux & Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11
Re: Supermount
On Mon, 15 Apr 2002, David Findlay wrote: > Well can the debconf for automount please make it easy to configure it that > way? The default config doesn't do anything like it, and the documentation is > not clear on setting it up. Everyone runs around saying they want to make > Debian easy for the new users, but nobody ever seems to want to do anything > about it. Go ahead, implement it, you are part of "Everybody" too. > Thanks, You're very wellcome. *t Tomas Pospisek SourcePole - Linux & Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
