Re: Annoyances of aptitude
On Sat, Oct 04, 2003 at 10:59:09AM +1000, Brian May wrote: > On Fri, Oct 03, 2003 at 08:20:33PM +0200, Sebastian Kapfer wrote: > > A minor issue that plagues me as a Sid user is the "broken packages" > > display. When I install foo that breaks package bar by conflicts of > > dependencies of dependencies (you get the idea), aptitude tells me that > > there are broken packages. That's nice to know, but it would be even > > better if aptitude could display a _list_ of these packages in the "g" > > view (I mean the summary that appears just before committing the changes). > > With the current release, I have to browse through the packages and hope > > to stumble on the broken ones. > > I find the following painful in aptitude: > > I select package a to install. It suddenly says package x is broken. > Mostly in aptitude when I see a broken package, I highlight it, hit the + key, and it either works or it's really broken (i.e., something's missing). What aptitude *does* do that bugs me is sometimes packages I install with dpkg -i (such as kernels/modules) will be automagically selected for removal, if I'm not careful to reselect them.
Re: On package description quality
On Sun, Oct 05, 2003 at 02:25:57PM +, debacle wrote: > Hi, > > sometimes I read package descriptions I'm not happy with. > E.g. the description starts: "Foobar is a GTK+ application, > that enables blah..." where foobar is a user application, > not mainly for GTK+ programmers. Of course, the user > doesn't/shouldn't care about GTK+ - and if, there's the > dependencies listed anyway. I remember, that we have some > guidelines on package description, where you can read about > this basics, but I cannot remember the URI. Could someone > help me, so that I can cite this guideline when filing a bug > against such packages? > > Cheers, > -- > W. Borgert <[EMAIL PROTECTED]> > I disagree. GUI apps in Linux are so wildly disparate that knowing the basic architecture is pretty important for me to decide whether or not I want it.
Re: On package description quality
On Sun, Oct 05, 2003 at 05:03:54PM +0200, Mathieu Roy wrote: > Tom <[EMAIL PROTECTED]> a tapot? : > > > I disagree. GUI apps in Linux are so wildly disparate that knowing the > > basic architecture is pretty important for me to decide whether or not I > > want it. > > What a normal user care about is the purpose and features of software, > not the libraries (toolkit) used to build this software. > This is true. However, as Microsoft and Apple seem to believe, it's not a nutty idea to believe that people care about how fonts look, clipboard operations work, and what the keyboard shortcut for File|Save is. Call me nutty for buying into this. Whether or not an app is GTK1, GTK2, Tcl/Tk, or QT3 makes a big difference to this. So yes, the library doesn't matter, but the core feature set is kinda relevant. Maybe you could find another way to describe it.
Re: Which packages will hold up the release?
On Thu, Oct 09, 2003 at 11:37:22PM -0700, Ross Boylan wrote: > There are some mathematical tools that might be useful in working with > some of these issues (I know them from models of social networks). When you have a hammer everything looks like a nail. Since I do SQL for a living I'd put all the data in a SQL database and use a technique called a "parts-explosion table" (see SQL For Smarties by Joe Celko). It helps you express recursive relationships in SQL. It helps when parts contain parts contain parts contain parts... and you need to know all possible parts affected by a part. For datasets the size of the package database it'd be a piece of cake with PostGres.
Re: A case study of a new user turned off debian
On Mon, Nov 03, 2003 at 04:57:34PM -0500, Greg Stark wrote: > All I want to do is give up on this new version and go to an earlier version, > most likely the version I had installed five minutes ago. Downgrading to > testing would probably require a whole new set of libraries and more work. I keep snapshots of my system states and debs as I upgrade. It's not perfect, but it's easy to roll back massive fuckups immediately, and at least possible to roll back one-or-two packages from a couple weeks ago. (Really complex changes like the recent gnome upgrade still get confusing, though).
What's the deal with NMUs? [was Re: Are you still there?]
On Tue, Nov 04, 2003 at 07:17:12PM -0500, Alex Pennace wrote: > A well meaning NMU to unstable can be helpful in the interim. > Naturally, submit a bug to describe the NMU; a diff is useful. If I > notice any problems I'll work with the uploader while the package is > still in unstable. I'm confused by the concept of NMU: can anybody just arbitrarily upload a new version of a package? I have a feeling that are some controls but it seems pretty wild and wooly, and subject to abuse. The whole openness of the bug tracking system and package system seems particularly vulnerable to persons with malicious and subversive intent. Has anybody ever "attacked" the Debian process? Are there specific controls in place to prevent "attacks", or has it just never come up?
monstrous arse [Re: Bug#219163: ITP: synaptic-touchpad -- Synaptics TouchPad driver for XFree86]
On Sat, Nov 08, 2003 at 02:52:09PM -0500, Branden Robinson wrote: > G. Branden Robinson| It just seems to me that you are > Debian GNU/Linux | willfully entering an arse-kicking > [EMAIL PROTECTED] | contest with a monstrous entity > http://people.debian.org/~branden/ | that has sixteen legs and no arse. Okay, googling for "monstrous entity" and "sixteen legs" shows that this quote is a .SIG that has been passed around a few times, but I can't find the original quote or any context to explain it. Is Debian the monstrous entity or the wilful enterer? Am I the arse?
Re: debian-installer beta 1
On Mon, Nov 10, 2003 at 02:31:55PM +1100, Martin Michlmayr wrote: > * Graham Wilson <[EMAIL PROTECTED]> [2003-11-09 21:17]: > > > >We are pleased to announce the first beta release of > > > debian-installer, the >new installation system for sarge. > > > > > > We want screenshots! > > > > Seconded! > > Try that damn installer and see for yourself. ;-) And report bugs. Can you point me to the ISO? I tried burning the sarge netinst twice but was never successful at installing Debian with it.
Re: Is vrms really still a Virtual Richard M. Stallman?
On Mon, Nov 17, 2003 at 02:14:53PM +1100, Andrew Lau wrote: > Hey everyone, > > I don't know whether to file a bug report or just laugh my head off. > > [EMAIL PROTECTED]:~% vrms > Non-free packages installed on espresso > > > doc-linux-nonfree-textLinux HOWTOs in ASCII format (non-free) > doc-rfc-std Standard RFCs > > Now we all know Richard M. Stallman's position on the GFDL, but I find > it extremely ironic that his virtual persona in Debian now discriminates > against his packages which uses a license his real self would approve. > > So is vrms now up for a name change before the real RMS decides to sue > us for misrepresenting him! = ) > > vbranden? > vdlegal? > > Nominations are now open. I was kind of happy when I saw the Ian or somebody (the original guy) suggest spinning off non-free. Nothing better than redfining a problem not to exist.
Re: Programming first steps.
On Mon, Nov 17, 2003 at 12:15:45PM +0100, Wouter Verhelst wrote: > Op zo 16-11-2003, om 16:44 schreef Chad Walstrom: > > On Sun, Nov 16, 2003 at 08:45:51PM +0800, David Palmer wrote: > > > I thought that I might make a beginning at learning. I've searched > > > the web, found information that goes beyond the definition of > > > plethora, so I thought that I'd ask here. > > > > C is useful, stable, has a huge following. C++ is useful, changing, and > > has a huge following. You will most likely find people who know C than > > C++, and you will often find C++ programmers who write mostly C style > > code within C++. > > > > Perl and Python have different histories. Perl was an evolutionary > > language whose origin was to replace sed and awk. Python was written as > > a full-fledged programming language and benefits from this consistency. > > (Can you tell which one I prefer?) Perl has its usefulness, but I often > > hear of complaints over maintability when it is use in large projects. > > You won't find that in Python. > > I have one grudge against python, though: its mandated indentation looks > very ugly and unstructured to me. Kinda reminds me of COBOL (and boy, do > I have nightmares of having to write COBOL code at school) > > wrt a good beginner's language, I wouldn't start with C or C++. They're > both great languages, but if you've never done any programming before, > they might be, uh, "confusing". I'd suggest finding some programming > language with at least some decent string handling, bounds checking, and > an intended audience of beginners. FreePascal is, I think, a good > candidate. I think the hardest thing about learning a new language is the Libraries. Variables, method calls, operators, scope are somewhat dicey to learn but you can pick it up in just about any language, once you learn the syntax. But to get a good education you need system libraries that do sophisticated things with strings and files and other nice things. That's why when I was learning I enjoyed Visual Basic so much: the system libraries were relatively easier (and also less powerful) than other languages. Microsoft's .NET class libaries are pretty easy to learn; they're slightly less idiomatic than Java even though they pretty much imitate them. In Linux, I like GTK/GLIB programming in C. The libs are pretty straightforward and complete.
Re: How to find all reverse depends of a package?
On Mon, Nov 17, 2003 at 06:33:52PM -0500, Nathanael Nerode wrote: > Without, that is, installing every package in Debian. > > I'm curious, for instance, as to why emacs20 hasn't managed to be removed > yet. Presumably something depends on it. But I can't figure out what. > aptitude or deborphan
Re: Tabs v.s. spaces (was Re: Programming first steps.)
On Mon, Nov 17, 2003 at 05:21:23PM -0800, Steve Lamb wrote:
> H. S. Teoh wrote:
> >On Mon, Nov 17, 2003 at 11:47:34AM -0600, Chad Walstrom wrote:
> >[snip]
>
> >>I have a love-hate relationship with the significant whitespace.
>
> >I have a hate-hate relationship with it. I much prefer free-style syntax
> >where the programmer is allowed to use his best judgment on how to indent
> >the code. Of course, in less-than-ideal projects, or projects with
> >less-then-ideal programmers, this could result in a mess, but I'm speaking
> >of personal preference here.
>
> Problem is that in languages which allow "free-style syntax" you're not
> allowed free-style syntax at all. You're required to match }'s with {'s
> (or the local language equivolents) and end all lines with ; (except for
> some cases when you don't have to). This is still a restriction of the
> same order, just with different characters and rules.
>
> Oddly enough ever since picking up Python a few years back I've never
> once felt constrained by its significant whitespace. I felt a profound
Significant whitespace? Shudder, that brings back crusty old memories
of Fortran. I have great fondness for fortran because of the wonderful
mathematical algorithms in LinPack, but I have no fondness for
significant whitespace.
> relief, however, when dealing with other people's code becuase it looked
> and behaved just like mine. There is enough freedom in the rules that a
> programmer doesn't have to worry about the end of the screen yet there is
> enough sensible structure to make the code readable. I mean, let's get
> down to it
>
> if foo {
> bar;
> } else {
> baz;
> }
>
> if foo
> {
> bar;
> }
> else
> {
> baz;
> }
>
> if foo {
> bar;
> }
> else {
> baz;
> }
>
> if you remove the points of contention between those three you're left
> with...
>
> if foo
> bar
> else
> baz
>
> ...which is a colon away from legal Python syntax. :P
>
> --
> Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
>PGP Key: 8B6E99C5 | main connection to the switchboard of
>souls.
> ---+-
Re: Tabs v.s. spaces (was Re: Programming first steps.)
On Mon, Nov 17, 2003 at 05:53:54PM -0800, Steve Lamb wrote: > Tom wrote: > >Significant whitespace? Shudder, that brings back crusty old memories > >of Fortran. I have great fondness for fortran because of the wonderful > >mathematical algorithms in LinPack, but I have no fondness for > >significant whitespace. > > And? Does Fortran's rules map to Pythons? I often find that people > who grouse about the whitespace are people who have never touched Python. > > Myself included before I touched Python. I can say this. I spent more > time grousing about it in a few months than it has ever impacted my coding > style in the years since. > > Have you touched Python? No. I should have said that in my post. Do whitespace mistakes cause compile time errors? The frustrating thing about fortran was variable names that started with C could be interpreted as comments not indented correctly, which would just cause that line to be skipped. Integer literals not indented correctly could be interpreted as line numbers and would really cause havoc with computed gotos. I.e., they were as super-frustrating to debug as misspelled variable names in a declaration-less language, or the types of bizarre situtations you get into in C when you start overwriting memory. If whitespace mistakes are always caught at compile-time, then I probably wouldn't care about them either. So I'm not bashing python; having never used it: I'm bashing languages where syntatic mistakes are not caught at compile-time. I have no idea if Python is in that category or not.
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 04:33:16PM +0800, Cameron Patrick wrote: > On Tue, Nov 18, 2003 at 09:10:53AM +0100, Wouter Verhelst wrote: > > | > Please actually try to code something in Python before commenting on its > use > | > of spaces. It is unlike the times of Fortran: in Fortran spaces are used > to > | > make programs easy to read by machines; in Python spaces are used to make > | > programs easy to read by human. > | > | then why are they significant? > > So that anything that attempts to parse the program, be it human or > Python, can tell when nested blocks begin and end? > > FWIW it seems that most people who have actually /used/ Python quite > like the significant whitespace thing, even if the idea makes them a bit > squeamish at first. It's OT but I can't resist one more post: Now that I've seen the code it's obviously semantically identical to braces and semicolons -- so I'd have no problem with them. I've been looking for good MSAccess-ish app in Linux; now that Rekall is GPL I'll be learning Python. It does seem VB-ish in its emphasis on simplicity (and especially the no-semicolons thing); minus VB's block-closing statements. I basically have no problems with it.
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 11:04:48AM -0800, Steve Lamb wrote: > H. S. Teoh wrote: > >Yeah, 'whitespace' about sums up the value of it. Except to Python > >programmers, of course. :-P :-P > > Quite the contrary. First off generally flames are from the > uninformed. Since in most cases the evils of whitespace are spouted off > by > those who have never once touched Python it is generally they who are > flaming and not those who have actually used it. > > Secondly clearly they are deriving some worth from it. I mean you did > post 12 messages to this thread. More than me, in fact. > > Finally I am still waiting for an answer to my two questions posed to > you. > > 1: Have you ever used Python? > > 2: Provide an example of such free-style coding that you speak highly of. I have two serious examples and one light-hearted one: Serious #1: *It looks like multi-line method invocations require parenthesis to be indented at the paren level. Sometimes that's useful, but often I like to pack arguments tighter than that and indent only once on subsequent lines: myreallylongmethodname(bar, bar, bar, bar, bar, baz, baz, baz); myreallylongmethodname(bar, bar, bar, bar, bar, baz, baz, baz); Serious #2: Multiple statements per line in diagnostic code and error flow control. The operant value in both these cases is some code is relatively unimportant to the main flow of the program and doesn't warrant gobs of space. "Real" code should be indented like Python, but if everything is "proper", "important" code gets lost in a bunch of scaffolding. Obiviously high equality code should be simple, but sometimes other values weigh slightly higher than writing perfect code, and flexibility is useful. Light-hearted: Sometimes I just feel like writing crappy multi-line, write-only code because it's not intended to change the world, and I want to see it all on the screen at once. Many real-world tasks are like this. No need to respond to these points, I can kind of predict the answers... > > -- > Steve C. Lamb | I'm your priest, I'm your shrink, I'm your >PGP Key: 8B6E99C5 | main connection to the switchboard of >souls. > ---+-
Build-depends for Rekall?
This seems on topic for the list's stated purpose: "Discussion about technical development topics." I'm trying to build rekall from rekallrevealed.org. It seems like it's going to have lots of build dependencies. If anyone has ever built it on debian, or can provide a probable list of build-depends I'll need, I'd appreciate it. I've already done an "apt-get build-depends kcontrol". I haven't made any special effort to get postgres or mysql build-depends on my system. (I intend to use it with the xbase driver for tiny personal databases). Thanks
Re: Debian Enterprise - a Custom Debian Distribution
On Mon, Dec 01, 2003 at 03:31:29PM -0500, David B Harris wrote: > (Why does money always need to get involved?) I think people start burnin' cars and shit if they don't have something to do all day. > Okay, that sort of turned into a rant :) I do apologise, but I'd > desperately like to help dispell the stigma that's associated with > anything non-Red Hat. I'm actually surprised more companies aren't trying to leverage the power of 1000 self-organized free developers. I wonder if there would be a backlash if a Lindows did $1 billion revenue...
Re: XML files referencing DTDs via HTTP
On Tue, Dec 02, 2003 at 07:48:04AM +1100, Brian May wrote: > On Mon, Dec 01, 2003 at 01:51:31AM -0800, Tom wrote: > > That's true. It can be any string. The fact that it just happens to > > look like an HTTP url and DTD is actually at that URL is not part of the > > standard, AFAIK. > > Errr, we are not getting confused?? > > "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; [ > Perhaps you were thinking of the PubidLiteral? You're right. I was thinking of the URLs used in XML namespaces. On an orthogonal note, while DocBook is a good schema, the other more business-oriented schemas EBXML, Rosetta, HRXML, the Business reporting schemas, and all that stuff, are lousy. "Here, kid, here's 50,000 entities. Have fun."
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 02, 2003 at 10:08:03AM +0100, Andreas Metzler wrote: > > Apparently nobody knew it was comparable to ptrace, it looked like a > simple bugfix and not like a local root exploit. > Well, I just downloaded 2.4.23 from kernel.org and installed it. [obGrumble] I never got hit by any of the Microsoft exploits either but I hated the upgrade treadmill [end]. Of course this is the 1st one in Linux for me and I'm willing to give y'all the benefit of the doubt 10 or 11 times :-) Was this problem a deviation from well-established security practices or is a new thing? Could somebody explain it in a nutshell?
Re: Revival of the signed debs discussion
On Tue, Dec 02, 2003 at 11:07:53AM +0100, Andreas Barth wrote: > * Joey Hess ([EMAIL PROTECTED]) [031202 02:55]: > > Goswin von Brederlow wrote: > > > What can we do with deb signatures? > > > > > > For our current problem, the integrity of the debian archive being > > > questioned, the procedure would be easy and available to every user: > > > > > > 1. get any clean Debian keyring (or just the key signing the keyring) > > > 2. verify the latest Debian keyring > > > 3. verify that each deb was signed by a DD and the signature fits What precautions are taken that the DD actually signed it with the DD's private key? After all this compromise was due to a DD's machine being compromised. I don't think you can audit every DD's workstation to make sure the keys are well managed. Set aside the possibility that the DD herself is actually the attacker. You have to have an answer for these remote possibilities. (Things tend to get maximally bad). > > > The canoical attack against signed debs in this situation is to find a > > signed deb on snapshot.debian.net that contains a known security hole. > > To avoid this attack, it is necessary that the filename of the deb or > the version of the package is also signed.
Re: Revival of the signed debs discussion
On Tue, Dec 02, 2003 at 01:17:58PM +0100, Goswin von Brederlow wrote: > Tom <[EMAIL PROTECTED]> writes: > > What precautions are taken that the DD actually signed it with the DD's > > private key? > > Set aside the possibility that the DD herself is actually the attacker. > > You never can. But once the compromise or the DD is found out it would > be easy to scan the archive for possible compromised packages audit > the sources and rebuild the binaries. Thanks for the frankness; I was asking the question pointedly. But if you fix the problem after it occurs, the damage is done. Closed source companies have ways of dealing with social engineering aspects (people wear badges; secure sources on isolated networks, security guards, threats of firing people, smart cards for SSH/VPN). I worked at Microsoft for 3 years and did some work with the security guys. The main branch of NT is about 70gb. They have a policy that any code has to be on encyrpted file system. If your laptop gets stolen with NT code on it, you get fired. If you leave your laptop in your car or check it on your airplane, you get fired.) The point of my question is: what can open source do that is comprable? It seems especially relevant considering the other thread about establishing Enterprise Debian. My nagging is just to provoke thought in the community. I don't have any answers.
Re: Revival of the signed debs discussion
On Tue, Dec 02, 2003 at 02:20:43PM +0100, Goswin von Brederlow wrote: > There is no security as strong as many people reading the source over > and over. You can't hack their brains to skip over the backdoor code > and you can only obfuscate a backdoor so much. Allright, allright, I'll cry uncle. /me standing way over here on the outside sure is noticing a lot of ruckus for something that isn't a problem :-)
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 02, 2003 at 11:06:44PM +0800, Isaac To wrote: > rather far from changing anything in the kernel memory. Andreas is > definitely right that the hole doesn't look like that it is that dangerous. It messed up your life for a couple weeks. Jesus, it's not the end of the world, but that's the way Microsoft (used to | still) thinks. If it wasn't a big deal we wouldn't be talking about it. It shut down servers. It's dangerous enough.
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 02, 2003 at 08:51:50PM +0100, Andreas Rottmann wrote: > Tom <[EMAIL PROTECTED]> writes: > > > On Tue, Dec 02, 2003 at 11:06:44PM +0800, Isaac To wrote: > >> rather far from changing anything in the kernel memory. Andreas is > >> definitely right that the hole doesn't look like that it is that dangerous. > > > [snip] > > > > If it wasn't a big deal we wouldn't be talking about it. It shut down > > servers. It's dangerous enough. > > > Note the "looks like". I read all the words but took a completely different meaning :-) I'm from the South, we have different speech patterns... "the hole doesn't look like that it is that dangerous" means something different than the hole doesn't look like that it is dangerous" in my ears ... "that" is diminuitve in my dialect if you don't put emphasis on it :-)
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 02, 2003 at 11:46:45PM +, Geoff Richards wrote: > > South of where? USA. North Carolina. Not South Carolina. Remember that. Redhat is in North Carolina. I always wonder if those mascara-wearing Cure-listening long-haired Linux skater punks ever get into trouble out in those Redneck bars. There's poofter places around but it's kind of hard to avoid trouble indefinitely. I learned you need to wear big shit-kicking boots and they ignore you. If you're openly "superior", trouble always follows. You got klansmen, constructions, crackheads, iterant workers, and marines. SC is worse. Tennessee is worse still. And North Florida they'll leave your ass in the swamp. > As far as security goes, we have to take 'dangerous' to mean > exactly that, diminutive or not. But if it didn't look like > a vulnerability then we can't blame anyone for missing it. Yeah, it was purely a misreading on what he said, no need to pile on *that* guy. But blame or not if a real showstopper gets out in future, it's not good!
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 10:54:24AM +1000, Andrew Pollock wrote: > On Wed, Dec 03, 2003 at 11:17:19AM +1100, Russell Coker wrote: > > The only way to have avoided this kernel vulnerability from day-0 of > discovery/fix release would have been to be constantly upgrading to > pre-release kernels. > > I'm starting to sound like I'm trolling for closed-source development models > or something, which is not the case, Smartcards would have avoided the Debian compromise: merely having a compromised DD box would have prevented bad guy from getting on the box. It's all about layers of defense. I think the DD's should seriously think about requiring smartcards. It would have prevented the proxmiate cause of our recent troubles.
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 12:20:59AM -0800, Don Armstrong wrote: > On Tue, 02 Dec 2003, Tom wrote: > > Yes but the attacker did not "steal" the DD's computer. He rooted it > > remotely. > > So the machine is rooted remotely, the DD logs into a debian box even > using our new fangled smart cards, and the attacker still can control > the connection. Not while the smart card isn't inserted. > > In this particular intrusion vector, the use of a smart card merely > means that the attacker has to trojan the ssh binary on the > compromised machine and use it to run a command that opens a shell > under the DD's uid on a non-privledged port, thus circumventing the > smart card in its entirety. I don't understand this objection, but it seems valid. Could you explain? > > If you log into a machine from a compromised machine using any means I > can forsee today, the attacker can always control the account of the > machine logged into, because the attacker effectively become the user > of the machine. > Yes, I always warned my employer that all I have to do is own your machine before you plug in your smart card, leave a logic bomb to do something while you're connected, wait for you to hang up and then report back. But it's all layers, layers, layers. More layers = better, none is a panacea. Have you ever used smartcards? I think that the more layers the better.
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 01:03:16AM -0800, Don Armstrong wrote: > [NB: I wanted to take this OT discussion off [EMAIL PROTECTED] and into > private > mail, but your e-mail address was munged in some sort of anti-spam > measure, and not trivially un-mungeable. Please consider providing > information on how to demunge it in some X- header, or not using > munging at all.] Heh. That's my actual email address. Fooled ya. > Well, the DD can't log in without the smart card, so that's clearly a > prerequisite. You leave it unplugged until you need it, do your thing, then unplug it. Sure, I could still infect your toolchain so you unwittingly upload trojaned stuff. But the fact is in this *actual* compromise the password was stolen and the hacker worked later at his leisure: smartcards would have prevented this *actual* incident (but of course doesn't prohibit other ways of attack). If something could have prevented something that actually happened, I say go for it.
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 01:16:39AM -0800, Tom wrote: > > If something could have prevented something that actually happened, I > say go for it. Oh, one last thing: each DD should pay for the device him/her self and should be required to fly to meet wherever they can pick them up. Why do you assume somebody has to pay for everything? What's wrong with bearing some of the costs yourself? This is a big deal.
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 12:06:33PM +0100, Artur R. Czechowski wrote: > > What is a "RSA token"? > Device used in some internet banks. You have a device, which has only > chipset, digital pad with on/off switch and display, all embedded in small > case. Authentication is made using C/R algorithm: you receive a number > from system, enter it into token, chipset signs it using stored RSA key, you > get a number from display and use is as a password. Yeah, these are good: they're cheap and I think it would have been effective at preventing this particular incident. That's an excellent idea.
Re: Backport of the integer overflow in the brk system call
On Wed, Dec 03, 2003 at 12:10:28PM +0100, Wouter Verhelst wrote: > > Are you going to pay for all those smartcards plus their readers? > Including any smartcards for possible future DD's? > > If not, I suggest we forget about this, as it won't be feasible. I don't think the USB models cost that much (maybe $50-$100 ea. in bulk). My badge at Microsoft was my smart card. The devs themselves could pay part of the cost, with perhaps partial donations from a corporate sponsor. I think even a college student could find $50 for this. The other guys suggestion about RSA tokens was better. I think they are probably only $15-$25, because they don't connect to your PC. Anyway, feel free to forget about it. It was just a suggestion.
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Thu, Dec 04, 2003 at 12:20:57AM +1100, Hamish Moffatt wrote: > > How about including your full name somewhere in your posts too then? > I find it a bit off-putting to discuss security with someone who's > obscuring their identity. Ha Ha Ha what a joke. I don't want to be googled for all eternity. Let me tell you a story about a job I had one time: I worked for a guy (in his basement -- don't ask) who bought your personal credit card data and other publicly available information. He would pay about $10,000 or $15,000 for lists of ~100,000-200,000 people's data. My job was to datamine it under criteria like: Give me all the people who make between $50,000-$80,000 /yr, own a boat, live within 15 miles of certain area, and used their Visa more than 10 times on the boat within the last 6 months. We'd rank order the data, apply the filter, and maybe get 10,000 good names, which he would sell for about $140,000 to a home alarm company, who would then call you during dinner. [1] Another job I had was for a drug testing company. My job was to write the report processing system which would say "You Person X have Tested Positive for Drugs A, B, and C and you are fucked." At one point in 1994 I had 40,000 people's drug test results on my 486SX-50. Just for grins I did a group by query, grouping drug frequency by a company's SIC industry code, and sorting in descending order. The most frequent people to test positive for drugs are construction workers, marijuana and cocaine. The next most frequent are school employees (probably bus drivers) testing positive for alcohol. Everything else was kind of evenly distributed. And you wonder why I am concerned with my identity!!! [1] I finally told the guy to go pound sand. I said: "You'd be more useful to society if you just grow corn or something." Doing that type of work made me want to slit my wrists.
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 08:45:49AM -0600, Steve Langasek wrote: > > Share the crack. In my experience kids in college and right out tend to freak out over the thought of having to spend a few dollars of disposable income, because they don't have any :-) Hey, laugh if you want, most organizations have dues, it's not unprecedented in human history :-)
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Wed, Dec 03, 2003 at 09:06:07AM -0600, Graham Wilson wrote: > > So you've aided telemarketers and worked for Microsoft? Is your last > name Darkness, middle name Prince of? Satan fell because he wanted to know. So do I. I'm a contrarian. I believe the opposite of whatever I'm confronted with at the moment. Evil is when you look around your life and say: "man, I gotta get some new friends." :-)
Re: OT: Smartcards and Physical Security
On Wed, Dec 03, 2003 at 09:26:15AM -0600, Manoj Srivastava wrote: > Guess what the median age of a Debian developer is. Don't know, don't care. > Volunteer organization have dues? Yes, I don't know what planet you're from, but on this planet the Rotarians, Kiwanas, Civitans, Knights of Columbus, United Way, Red Cross, Freemasons, NAACP, and Jerry's Kids all collect money from their members. You still feeling superior?
Re: OT: Smartcards and Physical Security
On Wed, Dec 03, 2003 at 09:28:30AM -0600, Manoj Srivastava wrote: > Sender: Tom Ballard <[EMAIL PROTECTED]> Yeah, somebody else pointed that out. It's bullshit that mutt was doing that to me. My /etc/email-addresses: # This is /etc/email-addresses. It is part of the exim package # # This file contains email addresses to use for outgoing mail. Any local # part not in here will be qualified by the system domain as normal. # # It should contain lines of the form: # #user: [EMAIL PROTECTED] #otheruser: [EMAIL PROTECTED] tom: Tom <[EMAIL PROTECTED]> So I thought I was covered, and my .muttrc never showed it. I fixed it. Like I said, I never thought I'd have to lie to Linux, but there you are.
Re: OT: Smartcards and Physical Security [Was: Re: Backport of the integer overflow in the brk system call]
On Tue, Dec 02, 2003 at 05:34:05PM -0800, Don Armstrong wrote: > On Tue, 02 Dec 2003, Tom wrote: > > I think the DD's should seriously think about requiring smartcards. > > It would have prevented the proxmiate cause of our recent troubles. > > Smartcards are not a magical panacea either. The problems associated No, they're not. Security is all about layers of defense. > with them aren't too terribly different from those associated with > keys or other forms of physical security, notably, that they can be > stolen, or the output from them duplicated. Refer to the ongoing saga > between DirectTV and satelite pirates for a trivially applicable > example. Yes but the attacker did not "steal" the DD's computer. He rooted it remotely. It is true that a shitty smartcard which is only dumb storage for a private key is no better than storing your keys on an USB keyring. Good smartcards never transfer the key off the card. The smart card can be compromised itself true. Repeat: Security is about layers of defense. Multiple things have to be compromised. > > From my perspective, Smartcards do little to raise the bar. They > merely move the bar sideways. You're wrong. They're better.
Re: OT: Smartcards and Physical Security
On Wed, Dec 03, 2003 at 09:24:07AM -0600, Manoj Srivastava wrote: > Heh. Your grasp of the practicality of the situation is > slipping. Not only do these guys donate a fairly expensive chunk of > billable hours and expertise, they must pay to be able to volunteer? Sure, if you care about security.
Re: OT: Smartcards and Physical Security
On Wed, Dec 03, 2003 at 11:14:29PM +0100, Wouter Verhelst wrote: > > Let me reiterate. You want to set up something with the Debian Project's > machines so that I have to pay for the privilege of contributing? > > Thanks, but no thanks. Volunteers don't work that way. > No sweat, that's totally cool. In other circumstances and for other ends, some groups of people *might* feel compelled to sacrifice. But that's probably not even necessary here. I was just being clever. It's not like it's an absolute requirement, anyway. One day they will tear down the internet, sequence everybody's DNA, and rebuild it proper. Then we'll chill :-)
Re: OT: Smartcards and Physical Security
On Thu, Dec 04, 2003 at 11:43:21AM -0600, Manoj Srivastava wrote:
> Snippy, aren't we? Usually it is better to have basic logic
> straight before you try for a mistaken sense of haughtiness.
My logic is correct; apparently my understanding of the goals of the
Debian project is not. I always thought it was first and foremost for
the devs themselves ("we don't care if anybody uses it but us"). Under
that reasoning, I'd think you'd *want* to spend money to have the best
for yourselves. The second and lesser reason is as a benefit for
society -- thus the comparision to the orgs you say are not like Debian
at all.
But primarily I would have thought you'd really want to have the best
environment in the world. I'm not saying you don't want that, I just
didn't realize $30 would be a showstopper, especially since as you say
you are already contributing so much.
But that's just me.
>
> Let me see if I can point out the logical flaws in words with
> few syllables.
Um, yeah. Take a bath.
Re: Backport of the integer overflow in the brk system call
On Thu, Dec 04, 2003 at 02:23:54PM -0500, Matt Zimmerman wrote: > On Tue, Dec 02, 2003 at 05:19:22PM -0800, Tom wrote: > You must be joking. If the developer's system is compromised, and he logs > into another system after that time, that system can be easily compromised > also. Yes, but the reason it would have been efficiacious in this *particular* instance is the hacker sniffed the password, and then logged on to Debian's servers later at his leisure from a different PC. With a smartcard, he would have had to done it *on* the Dev's infected PC *while* the smartcard was plugged in. In theory the smartcard would not be plugged in all the time, thus diminishing the attack surface.
Re: Backport of the integer overflow in the brk system call
On Thu, Dec 04, 2003 at 06:13:49PM -0500, Matt Zimmerman wrote: > > Not really; he just has to set things up ahead of time. This is like > claiming the attacker has to be present in order to sniff your password from > a telnet session (he doesn't; he just has to have been around at any time > before then in order to set up a sniffer). That's totally true. It's not the way this attack happened though. All I know is it's a layer and experts say layered defense is best. I still think it would discourage the cracker. A lot of the "open a netcat over the exposed pipe" tricks wouldn't work iff the smartcard auth stack wasn't compromised -- the netcat couldn't get auth'd, and the server wouldn't buy it. The problem now is a pipe is a pipe. Just rambling... I'm sure there's tons of holes in what I just said.
Re: OT: Smartcards and Physical Security
Let me start by saying I basically understand your last point: it's not worth it because it won't work. On Fri, Dec 05, 2003 at 04:01:42AM -0600, Manoj Srivastava wrote: > who follow secire processes. Blowing 40k collectively is unlikely to > buy us much security. Like I said, it may be that it would be wasted money. But you are switcing arguments here. Originally you were bristling at the suggestion that you spend your own money. Now you seem to be okay with that, but saying it would be wasteful because you basically don't trust smartcards. I don't trust them either, but they are a layer. Of course, they may be an absolutely useless layer, but they may not. I think this is your true objection (to smartcards at all) and not to the suggestion of having your spend your own money to improve the project. And that's an acceptable belief (although it *may* not be correct). But if you want to explore other, free ways to improve Debian's security process (such as auditing one another's machines or some other way I can't think of), that's a good thing. The point is: a failure occured. Don't let it happen again. > > >> Let me see if I can point out the logical flaws in words with few > >> syllables. > > Take a bath? take a _bath_? What are we, back in grade school now? You're not seriously talking about taking pot shots are you? Tit for tat. But I withdraw the remark, I was thinking of the traditional image of the long-stringy-haired Unix hacker such as RMS. I was picturing RMS -- I didn't mean anything else. :-)
Re: The term "Custom Debian Distribution" (Was Re: [custom] The term "flavor" and encouraging work on Debian)
On Fri, Dec 05, 2003 at 11:36:20AM -0400, Ben Armstrong wrote: > Then that discussion needs to be resolved so that a solution can be made > that is in Debian main. It's useful to try to clarify the terms so people can speak the same language, but as soon as you categorize anything somebody's going to come out with something which fits in multiple categories. Anything which isn't just a subset of Debian will ultimately just be a distraction, in which case the # of "flavors" is the cardinality of the power set of packages. :-)
Re: OT: Smartcards and Physical Security
On Sat, Dec 06, 2003 at 01:51:23AM -0600, Manoj Srivastava wrote: > > Drop the imperatives, and we shall get along a lot better. > Better still, roll up your sleeves and make it happen, and > you'll earn my respect, and my support. How about "fuck up again and watch your good thing go away" (hint I ain't it) > I was merely dumbfounded at the _quality_ of pot shots you > were taking. Heh. I've had to tell people at work to go home and take a fucking bath: you stink. Manoj, your words are powerless.
Re: OT: Smartcards and Physical Security
On Sat, Dec 06, 2003 at 11:13:05AM -0600, Manoj Srivastava wrote: > And then again I question your judgement. What, pray, is this > good thing that is going to go away? "Hey hey I saved the world today Everybody*s happy now The bad things gone away And everybody*s happy now The good thing*s here to stay Please let it, please let it" I'm not being evasive, this is the answer to your question: You'll know it when it's gone.
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 09, 2003 at 11:45:58PM +1100, Russell Coker wrote: > > As for acting like a Jackass, the Johnny Knoxville and his colleagues are > very > talented entertainers who work hard. I wouldn't compare them to you in any > way. Oh, I dunno. I got *your* attention. But chill the hell out. I'm disengaging. My point (such as it is) is accomplished. Nothing but technical matters from me from here on. Save the bitching for next time.
Re: Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Tue, Dec 09, 2003 at 02:06:48PM +0100, Moritz Moeller-Herrmann wrote: > freedesktop entry features > debian menu file features > > Therefore you can do a lossless transition from .desktop to menu, but not > the other way around. It makes sense to use the .desktop standard. I know what you mean, but don't you mean "lossless transition from menu to .desktop" ? .desktop is the one that has more features, so a transition from .desktop to menu would lose. It's trivial but I might not understand the issues if its the opposite.
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 09, 2003 at 01:12:13AM +, Colin Watson wrote: > . Could you please try > to keep debian-devel posts to well-thought-out [1] technical content, Sure. I'd also ask everyone to keep their anti-American, anti-Bush SIGs and random comments out of both lists. I have acted like a jackass on purpose -- to give you a taste of what it feels like to put up with incessant opinions which you find illogical. How about a cease-fire on both sides of the idological debate? But I decided to cut down on the opinion posts; these are just reverberations from people catching up.
Bug#284978: general: libgmp segfaults on generating 48402688-bit random number
Thomas Womack <[EMAIL PROTECTED]> writes: Do you have libgmp2-dev or libgmp3-dev installed? I have libgmp2, libgmp3 4.0.1-3 and libgmp3-dev 4.0.1-3, so you're using later versions of all the relevant packages (indeed, since you're on amd64, on entirely different hardware) and the bug is still there. I've also reported it to [EMAIL PROTECTED] on general principle, though have heard nothing from them yet. I've just checked that this wasn't a stupid problem to do with missing mpz_init() commands; if you insert mpz_init(A); mpz_init(B); mpz_init(C); before the first mpz_urandomb() call, it still segfaults in the same place. Tom
Re: Bug#353277: ndiswrapper in main
On Mon, 27 Feb 2006 14:48:51 -0800 Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: > Stephen Gran <[EMAIL PROTECTED]> writes: > > > Well parroted. Since I can see you don't understand the difference > > between main and contrib, I will point you to it. Please see 2.2.1 and > > 2.2.2 in policy. If you diff the first set of bullet points that lay > > out criteria for main and contrib, you'll see that the only differnece > > is that packages in main : > > "must not require a package outside of main for compilation or execution > > (thus, the package must not declare a "Depends", "Recommends", or > > "Build-Depends" relationship on a non-main package)" > > This is not a complete list. It may not require a package outside of > main for compilation or execution. One consequence of that, is that > it must not Depend on such packages. But this is not the *only* > consequence, it is merely the one being spelled out. > > It is certainly not true that a package in contrib can be moved to > main just be removing the package dependencies. The further question > is: can it be run without the non-free software? > > I still am not sure, having not yet received a complete answer to the > factual questions I raised. (Adam gave recently a partial answer, but > I'm still not clear on the facts to which he was alluding.) > > > Do you see a Depends, Recommends, or Build-Depends on non-free or > > contrib software somewhere in the ndiswrapper source or binary packages? > > I don't. So why is there an argument for changing it? Since there is > > no foundation in policy, do the benefits or technical merits (of which > > exactly none have been presented) outweigh ignoring a rather clear > > statement from policy? > > The question is not whether there is such a dependency declared; the > question is whether the software is useful without the use of non-free > software. > > At first blush, it looks as if the only purpose of the software is to > run NDIS drivers. So the question is: are all NDIS drivers non-free > software? (Actually, the question is slightly more complex, so please > see the previous message in which I gave a more full version of that > question.) I am not a DD, so maybe my opinion is idiotic. But: the thing is free, it allows people to use non-free drivers, but it is entirerly up to the user to use those drivers. I don't know, but for me this discussion is pointless. Does ndiswrapper require non-free packages? no. if the user decides to use non-free drivers, then it's his choice, not debian's, so what. and no, I don't care much, because i do not use ndiswrapper, but this is starting to get silly. > Thomas > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming Debian Releases
On Sun, 25 May 1997, Mark Baker wrote: > In article <[EMAIL PROTECTED]>, > Tom Lees <[EMAIL PROTECTED]> writes: > > >> the other solution is to have a small utility that stores these values, > >> can change them and gives the values to the scripts. > > > > The third solution, which I prefer is a utility which modifies the > > variables within the scripts - it's faster, it is more "backwards > > compatible" with sysadmins from other Unices, and generally it's nicer > > (less dependant on the cfgtool at boot-time). > > And if you're not very careful it does silly things if the scripts have been > modified significantly. So you do something like:- BLAH=something # configtool=yes Then, if someone modifies the scripts, they make sure that that particular line is still there, or remove the "configtool=yes" if they don't want it. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On Sun, 25 May 1997, Christian Hudon wrote: > --5mCyUwZo2JvN/JJP > Content-Type: text/plain; charset=us-ascii > > On May 24, Tom Lees wrote > > > > The third solution, which I prefer is a utility which modifies the > > variables within the scripts - it's faster, it is more "backwards > > compatible" with sysadmins from other Unices, and generally it's nicer > > (less dependant on the cfgtool at boot-time). > > And it changes the conffiles, which means that the user will still get > bugged with "Conffile changed, overwrite with package's version or keeps > yours?" questions from dpkg, which is exactly what we want to avoid with > cfgtool. There are ways to avoid this. For example, modify dpkg not to include any line with "config=yes" in it in the md5sum of certain files. So, for example:- #!/bin/sh # the blah script BLAH=yes# config=yes If this becomes:- #!/bin/sh # the blah script BLAH=no # config=yes It still gets excluded from the md5sum, but if someone changes it, like:- #!/bin/sh # the blah script BLAH=no Then dpkg gets a different md5sum, and prompts, because it is included this time. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Where is the mysql package?
On Mon, 26 May 1997 [EMAIL PROTECTED] wrote: > > > Yep. How about a verbose mode that tells you when you connect, or if it > > > cant, says so, and then when its done, prints xxx bytes downloaded in yyy > > > seconds, at foo kb/s. > > > > > > something like: > > > $ snarf -v http://linuxos.org/index.html > > > connected to linuxos.org:80 > > > getting file... > > > got 63K in 45 seconds at 1.4K/s > > > $ > > So how about it, huh? =) Snarf is one cool proggie. wget can do this. It sounds like snarf is similar to this. Sample output:- debian:~$ wget -v http://localhost/debian.html --11:59:33-- http://localhost:80/debian.html => `debian.html' Connecting to localhost:80... connected! HTTP request sent, fetching headers... done. Length: 2,778 [text/html] 0K -> .. 11:59:34 (452.15 KB/s) - `debian.html' saved [2778/2778] -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: kernel header files : problems (yes, again)
On Wed, 28 May 1997, Andreas Jellinghaus wrote: > also get this directory. but only linux/ and asm/ shoud override > /usr/include, not net/ (because : net/ is buggy !). what shall i do ? > ok, i know how to fix this, but with the next libc or kernel header > update i will have to fix it again... any good solution ? Put something like this in debian/rules:- mkdir kinclude ln -s /usr/src/linux/include/linux kinclude/linux ln -s /usr/src/linux/include/asm kinclude/asm Then compile with -Ikinclude -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Policy for arch specs
On Thu, 29 May 1997, Christian Schwarz wrote: > Hi folks! > > As I'm working on a new Policy I'm handling the request to include a > policy for "correct architecture spec strings". However, I've discovered > _several_ threads here on debian-devel without any (obvious) results. > > Is it correct, that we are currently working on ports to the following > platforms (the abbrevs should be the ones that dpkg is using in the file > names): > i386 > alpha > arm > m68k > powerpc > sparc > Are these correct (i.e. not ppc) and is this list complete? > > Next step: GNU's "configure" utility. I thought that we had agreed on > using > i386-unknown-linux > (and similar for the other architectures), but then I had just discovered > that GCC uses > /usr/lib/gcc-lib/i486-linux/2.7.2.1/ > ^^ > > (first it says "i486" instead of "i386", second it ommits the "unknown"). No, i486-linux is the alias we should use. Latest configure tools will convert this to i486-pc-linux-gnu! But, all programs should install using the alias, not the full name. Dpkg calls it "i386", but the autoconf string should be i486. In general, the alias given to configure should be xxx-linux. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking over e2fsprogs ?
On Wed, 28 May 1997, Yann Dirson wrote: > > Has anybody postulated to take over maintainance of the package ? If > not, I'm a volunteer... Please let me know. If you do take it, please try to get the e2compr patches into it. I have requested that I take it to do this work on it. However, e2compr-ised patches are only available against 1.06 - they will need some converting. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dcfgtool and clones
On Mon, 26 May 1997, David Frey wrote:
> Hello everybody,
>
> On Sat, May 24 1997 11:40 +0200 Andreas Jellinghaus writes:
> > there are three tools : cfgtool (lars wirzenius), nod (winfried
> > truemper), dcfgtool (mine). and someone is working on a _real_ tool (all
> > three have flaws, and if this way we will get a tool with all good
> > features).
>
> With somebody, you meant eventually me, since I asked at the Linux-Kongress
> in Wuerzbuerg whether I may upload a dcfgtool clone.
> But whether it's a ``real'' tool, is not so sure... . Don't hold your breath.
>
> > as you can see, it's a small text database. so it has nothing, absolutly
> > nothing to do with deity - that's a GUI.
> agreed.
We are planning on expanding the scope of deity to include a few more
features than "just a GUI" after the initial release though. Including
getting a decent library set together for other developers to use. Making
the config-tool part of this would seem pretty logical.
> > then we should :
> > a) choose _one_ cfgtool (the current one have big flaws. the new one
> > will not have them).
> > b) change policy to _not_ allow config information in /etc scripts
I really don't like this, and I think several others don't either.
> > c) change policy to _not_ allow additional debian uniq config files to
> > fix b). only the textdb should be used.
Definitely. But we have to remain backwards-compatible, so we must be able
to *read*, e.g. /etc/mailname, to be able to convert to the db.
> > d) think about getting rid of some config files only used by shell
> > scripts, and use the textdb instead.
> yes.
>
> Lars Wirzenius <[EMAIL PROTECTED]> said:
> > Assuming the syntax is simple, and there's no need for complexity, a
> > hand-written parser can be lightning fast, and all the time is spent
> > in starting the program, and reading the file.
> Mine is currently a lex parser and a yacc scanner.
Do you do any hashing? I usually use gperf to generate a hashing function
for the main keywords. This really does give some nice speed improvements.
However, if the format is even simpler than this (no keywords, just
"variable assignments", and comments), it would be faster to use a yacc
parser, and write your own (simpler) lexer. The regular-expression
capability of lex does hit the performance slightly unless you really need
it. GNU flex doesn't suffer from this problem nearly as much as the
original lex did, though - it was severely slow.
> Tom Lees <[EMAIL PROTECTED]> said:
> > I know all this. But when will it be finished? What about beta
> > versions? Is there a mailing list (other than debian-admintool)?
>
> Finished in about a week (beta version).
Great! Are you planning on uploading it to experimental or unstable? I
would suggest you upload it to experimental, as it has the possibility to
severely corrupt people's systems. OTOH, you could also put it in your
home on master, as a pre-beta to check if everyone likes it.
> Mailing list other than debian-admintool: no
Maybe we should start *using* debian-admintool then :)
> Tom Lees <[EMAIL PROTECTED]> said:
> > It would be really cool if we upgraded the packaging system to handle
> > configuration integrally (so we can do configuration _BEFORE_ an
> > installation, etc.).
> Yes. But the tricky part is how to rewrite all the /etc/hosts, /etc/networks,
> /etc/uucp/{sys,dial,port,config}, /etc/fstab, /etc/slip.dip etc. files.
> I don't have an idea.
How about we do it like apache does its modules? (This might get tricky,
as I'm not sure all developers can program). So the config tool loads all
the modules (using libdl), and then it can use special functions in these
modules to handle these file-formats. OTOH, there aren't that many files
with non-generic syntax... maybe we could simply include separate parsers
for each of these.
> > Deity definitely _IS_ the right place for this -
> > a GUI to do the configuration with, at the same time as packaging
> > control!
> I'd prefer a back-end and deity would be the frontend.
The way I envisaged it was that Deity would get all the configuration
info, and then pass it on to the back-end after it had all the info.
I think the cfgtool should probably be available as a shared lib so that
deity can also read stuff etc., without too much of a slowdown from
execing another prog.
> Jason Gunthorpe <[EMAIL PROTECTED]> said:
> > To allow a GUI to present a usefull view of the config file
> > information about each field would have to be known. A short
> > description, it's content type, possible range information, etc.
>
> You can store a comme
Re: Unresolved Critical Bugs
On 27 May 1997, Sven Rudolph wrote: > Christian Schwarz <[EMAIL PROTECTED]> writes: > > > Anyways, e2fsprogs seams to have a lot of open bugs. Is this package > > actively maintained? > > Probably not. Last maintainer is Michael Nonweiler <[EMAIL PROTECTED]>, > but he is looking for a new maintainer for e2fsprogs. Seeing as I am maintaining e2compr, I'll take it, and merge the packages as appropriate. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: time stops on latest kernels
On 27 May 1997, Rob Browning wrote: > Is anyone else running the latest unstable kernels on a uniprocessor? > I have noticed that with many of the recent kernels (including > 2.1.40), time appears to be stopped. With these kernels, on my > machine clock never returns anything but zero, and things like > procmeter never register anything for cpu usage. > > I know that 2.1.26 doesn't have this problem, but I'm not sure where > it was introduced. I have a suspicion that it's related to the new > multiprocessor code... I'm running:- Linux debian 2.1.36 #56 Sat Apr 26 15:44:22 BST 1997 i486 unknown And everything is working... -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
On Thu, 29 May 1997, Paul Bame wrote: > = > Should this CVS repository be mandatory, i.e. does every Debian > = > package have to be there? > > A brief word of warning... (I tried CVS on dpkg a while back) > > The natural CVS model is to name the directory for the package, > for example .../dpkg/ and relegate the version numbers to tags. > At least one package (dpkg) uses its directory name in such a way > that when the directory is .../dpkg/ the build fails, while it > works when the directory is a versioned one, .../dpkg-1.2.3/. This has been fixed now, since 1.4.0.9 (it was in my original automakizing patch, it now using the debian changelog to determine version). -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On 30 May 1997, Kai Henningsen wrote: > [EMAIL PROTECTED] (Tom Lees) wrote on 27.05.97 in <[EMAIL PROTECTED]>: > > > There are ways to avoid this. For example, modify dpkg not to include any > > line with "config=yes" in it in the md5sum of certain files. > > This is a troll, right? Wrong. > Or maybe you have forgotten how conffiles are actually handled: > > (old=original install, new=this install, current=possibly edited version) > > If old md5 = new md5, ignore new file (package unchanged) > If old md5 = current md5, install new file (conffile was not edited) > otherwise, prompt (both changed) > > Your change would mean that in case 2, dpkg would have to figure out how > to put the variables from the old script into the new one. But, for a package which adds config info, the new md5 != the old md5. Therefore, it would ask! And for a package where old includes config lines, the pkgtool would be rerun to update info which was config=yes. Locally modified lines wouldn't be config=yes, so the md5 would be different. Therefore, unless the sysadmin forgets to modify "config=yes" (put a banner to remind them), it works. So:- non-cfgtool md5 != cfgtoolized md5: old md5 != new md5. local file not modified: update anyway to use new cfgtool version. local file modified: cfgtool md5 == cfgtool md5: old md5=new md5 local file "not modified" (enough) - install new THEN, update from cfg database. See, it does work. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: GOAL: Consistent Keyboard Configuration
On Mon, 26 May 1997, Christian Schwarz wrote: > On Mon, 26 May 1997, Jim Pick wrote: > > > I agree 100% with what Ian says. (Let's do it) > > Me too! (I didn't know that such a simple solution is possible :-) > > So what about the other keys? I suggest that all character keys, symbols, > etc. should produce the character that's printed on the key (this sounds > reasonable, doesn't it :-) > Then I have a "special ALT" key on my german kbd, that's label "Alt Gr". > In DOS/Win95 it behaves like pressing Ctrl-Alt together. It's useful to > get some "alt-alt keys" (for example, I have "=", "0", and, "}" on one > key). I think the behaviour should be the same in Debian. Yep. We need to make sure that the AltGr key on most European keyboards does something (and even on UK keyboards... it produces a IBM line-drawing char IIRC). This involves adding a "modifier" to the keymap (at least for std console). > Other keys: > > - "End": Should jump to the end of the line/document, depending on where > it's used, for example, jumps to end of line in "readline", but end of > document in "less". Ok? > - "Home": Opposite of "End". Fine > What about the second "cursor block" at the right? It would be nice if one > could switch between the function keys (left, right, etc.) and the digits > (0, 1, etc.) with the "Num Lock" key. Is this possible? (The current > behaviour is to produce digits all the time, no matter if "Num Lock" is > set.) This works at the console (with uk.map). > Then I have a "Print" key, "Scroll-Lock", and "Pause". All three keys > don't have an effect in my X configuration--on the console "Scroll-Lock" > starts/stops terminal output, just like "C-S and C-Q". Is there any useful > meaning for "Print" and "Pause" in Linux? Ctrl+Pause (=Break) should do one of those kernel dumps IMHO. Or produce SIGINT, whatever... > Does someone have any other special keys on his keyboard that we should > define? (We'll just do it if the keyboard layout is widely used.) Ctrl+PrintScreen (=SysRq) should do a kernel info thing. What about W95 keys (3 of them)? Define as F20 or something? -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: packages.debian.org & qmail (was Re: Using CVS for package development)
On Fri, 30 May 1997, Philip Hands wrote: > What were you trying to achieve ? --- it might be simpler than you think. > > I just discovered that most of my alias handling under qmail was drivel, and > could be dome much more simply. > > > If someone wants to spend some time on a simple mailer hack, you can > > make this work. > > If you want mail to, for instance: > > [EMAIL PROTECTED] IIRC you can also alias an entire domain (packages.debian.org) to one user (how lists.debian.org is currently done). So [EMAIL PROTECTED] gets translated to, say bruce-packages-rsync. Then, ~bruce/.qmail-packages will execute a script to process it, or you can have .qmail-packages files for each pkg if you are worried about speed. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On 7 Jun 1997, Kai Henningsen wrote:
> > > Or maybe you have forgotten how conffiles are actually handled:
> > >
> > > (old=original install, new=this install, current=possibly edited version)
> > >
> > > If old md5 = new md5, ignore new file (package unchanged)
> > > If old md5 = current md5, install new file (conffile was not edited)
> >
> > > otherwise, prompt (both changed)
> > >
> > > Your change would mean that in case 2, dpkg would have to figure out how
> > > to put the variables from the old script into the new one.
OK. I didn't make this clear. The point of the config-tool is to do this.
The file is not modified locally per s.e., just written locally in a
different way to the packaged version, because the config db is changed.
To clear it up: for a script which holds values which are really housed in
the configuration database, each line which is simply a copy of config db
information has a special key on it ("# nomd5sum" or something) which
tells dpkg not to include that line in its config-file md5sum. The config
db tool has the job of updating the values "on demand", from the config
database, replacing the values in the script. Therefore, when a file gets
upgraded, even if it is replaced with "standard defaults" from the
package, the postinst calls the config tool telling it to copy the
appropriate values into the file.
We could have something like this in the postinst:-
if [ -f /sbin/debian-configtool ]; then
debian-configtool --import /default - --update-file /etc/my.script < No, it doesn't. You forget that there are three md5 sums / file versions
> involved, not two - *even though you quote me explaining it*!
Well, I already wrote a simple system that works like this in perl - and a
modified version of md5sum which can do this.
--
Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/
PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6
finger [EMAIL PROTECTED] for public key (also available on keyservers)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: points on future installation disks development
On 9 Jun 1997, Sven Rudolph wrote: > My ideas on boot-floppies' future: > > - rewrite dinstall in C - reasons: > - runtime improvements > - don't run fdisk -l that often > - todo: make a libsfdisk from sfdisk > - more complex datastructures (avoid using sed often) > - more complex input masks and consistent user interface > - network configuration: everything in one screen Can we add at some point a BOOTP/DHCP option to the network configuration, to do it all automagically? This would be nice. > - selecting base directory in one screen > - use : > - ncurses and libdialog (from FreeBSD), or ncurses may have licensing problems. > - slang (ncurses shouldn't be needed then, slang is said to have > a curses emulation), or Well, SLang does have a distinct set of programming advantages. However, we'll need a libslang-pic package in this case. Yes, it does have a curses emulation, but it's much better to use it in native mode. > - turbovision (licence OK?), or > - something else (suggestions welcome) > - easier i18n (see below) > > - new features > - installation via serial terminal Hmmm... nice idea. How about installation over a network, i.e. system boots up, BOOTPs (or whatever) for IP info, then SysAdmin can telnet in from a workstation to set it up. > - for blind users > - for automated testing Impressive. Are we going to do this ever? > - use lilo in order to drive the serial line early (or modify syslinux ?) > (what about GRUB ?) Modifying SysLinux is a nice option. Although I do have TASM, and so can modify the sources, does anyone know how well NASM (which we have in the distribution, I notice) can handle these files? > - an extra command-mode installation ? i.e. SysAdmin sticks a special-custom disk into a workstation, and comes back later, and it is running a fully installed Debian? A lot of people have expressed interest in this. > - installing base via ftp and smbfs (and from tape ?) SMBFS is just another FS, easy enough to do. Also, we should add in NCPFS (from NetWare server) there, probably. I had a thought about FTP and - we could use wget. This would also enable us to use HTTP. The version on my system is 88K, but I'm sure this can be reduced if we kick out some of the functionality (like all the intelligent stuff). > - mouse support ? (gpm, or derived from gpm) Have a look at kmouse if you want an alternative to gpm. So far, this is looking really good, but it doesn't yet support the variety of mice that gpm does. I have some patches to make it run on 2.1 kernels, which I will be sending to the author pretty soon. However, gpm is only 33K, plus libgpm at 109K (required for both gpm or kmouse) would take up around 140K. > - i18n plan > - i18n for C files: use GNUish standard method ? (is this gettext ?) Yes, this is gettext. > - i18n for shell scripts (swapsetup) (is there a good way for doing this) > or rewrite them in C Use the "gettext" command-line utility. Unfortunately, there seems to be no documentation for it, but it is pretty simple to use. The gettext command-line utility is, however, 17K, which could make it worth rewriting nearly everything in C. > - i18n for busybox (is it worth the work and disk space ?) Some of the more major parts of busybox (like ls) may be worth i18n. However, I wouldn't do all of it. > - try to keep i18n and localization separated > - how many locale data sets will fit on floppy root.bin ? Autodetection of a CD-ROM can happen very early in the boot process, then at least we can put all of the locale data sets in, e.g. /l10n on the CD-ROM. > - bigger root.bin for loadlin booting This may be a problem for low-memory systems, though. > - for floppies: make extra locale file that can be copied to Rescue Disk Or, seeing as at least one of the floppies is a DOS disk, why not create "locale data packs". Each one would have the appropriate locale and translation info for one locale, and this could be copied onto that DOS disk. > - assign versions to original and translated text in order to keep > them in sync (and automatically find out when they aren't) GetText can pretty much work this out itself, actually. > > - localization > - translate text files Which text files do we actually have ATM? > - translations for the i18n'ed parts > - minors > - better 'make bootable': MBR isn't that self-explaining I think we ought to also at least have the option of not using MBR. I for one don't like it, and use LILO instead. Others I know use OS/2 Boot Manager. We should also have an option to install all the appropriate LoadLin stuff into a DOS partition, and set it up properly. >
Re: Some ideas about the text db
On Sun, 8 Jun 1997, David Frey wrote: > Hi Tom, Hi. > > Basically, we first have a "/default" directory, which every package > > imports its default settings into. > > > > User configuration is put under "/config", which means that the system > > will first look under /config, then /default when a variable is requested. > > I don't see the advantage of this scheme. Please explain why it is > favorable to have 2 configuration trees. > > If you wan't to have 2 trees, a better and easier approach is to have > (standard Unix-way) a $HOME/.config/... and a /etc/config/... tree. OK, a lot of people got confused on this one. I meant user as separate from maintainer of the package. i.e. local sysadmin. The point is so that defaults can easily be changed without affecting locally set-up stuff. > But the question is, whether you want to use the configuration database > for all and everything (-> each user wants his/her own copy) > or just for system-related entries (one global /etc/config is enough). I think all and everything, but that's my opinion. Most people seem to think minimalist is better, but even then, a global /etc/config would still benefit from this scheme. The main advantages of all and everything are:- * SysAdmin can install multiple "themes", and user may select separately from sysadmin. * User defaults may be updated, but global defaults will also be updated - using .fvwmrc, etc., where it is the global file _OR_ the local file which gets processed will be worked around cleanly. * The database is much more extensible (much like the menu package). IMHO, the config database should extend the system in the same way the menu package does - i.e.:- * It is not compulsory (but probably priority Important) * It is customizable by the user * Still fully backward-compatible - no "proprietary code" in programs (and more importantly scripts), unless they are special Debian programs, e.g. dpkg (not scripts). -- Tom Lees <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
I found the Xemacs problem!
I installed the new 3.1 binary (not support) package. It still coredumped on me - XFree 3.2-1. Then I upgraded libc5 - 5.4.17-1 to 5.4.23-1. It now works perfectly. I looks like its pretty dependent on a specific version on libc. Tom Lees <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Status of Debian Policy
>>>>> "ghughes" == ghughes <[EMAIL PROTECTED]> writes: ghughes> [1 ] On Jun 22, Bruce Perens ghughes> wrote >> Lynx can browse files directly, and can execute CGI scripts >> directly. ghughes> True. However, it can't handle gzipped pages, and ghughes> hacking it to do so seems a) special case (because Ermm... on my system it can. lynx 2.7-1 (self compiled). netscape also handles it very well. I can't say about others because I haven't tried them. ghughes> chimera, w3, netscape and all the others still don't) and ghughes> b) outside of its domain of relevance. As well, it ghughes> (rightly) looks for references of the form ghughes> `foo/bar.html', when it would have to look for ghughes> `foo/bar.html.gz' and do the unzipping. ghughes> In contrast, info browsers have been handling compressed ghughes> files for what feels like eternity to this young'un ;-). ghughes> You can configure a web server (almost any web server, if ghughes> I remember correctly) to dynamically unzip the pages as ghughes> they come down the line, however, and this seems more in ghughes> line with what one expects a web server to do. If HTML ghughes> is to be used in any form, a minimal web server would ghughes> also be important, if only for this aspect. Apache apparently also lets you dynamically gzip them down the line. (The browser has to send the right headers tho). ghughes> As far as *which* window manager, this is something else ^^ You mean web server? ghughes> entirely. WN is nice, but requires slightly nonstandard ghughes> update files, and Apache is occasionally too big but ghughes> certainly capable (although I have never really ghughes> understood this, having run it on every Linux machine ghughes> since my 386SX). Lynx without a webserver will work. But for netscape, etc., we should consider adding one. ghughes> Boa might be a possibility, if it could be told how to ghughes> transfer gzipped files; I have positive experiences with ghughes> it, but I don't know whether this is something it can do ghughes> by default. -- Graham Hughes <[EMAIL PROTECTED]> I haven't tried Boa, but NCSA and CERN looked OK to me. -- Tom Lees <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Hamm: Retracting request for chos to be standard
>>>>> "Christoph" == Christoph Lameter <[EMAIL PROTECTED]> writes: Christoph> Lilo 2.0 has the ability to display a file before the Christoph> prompt and also the ability to boot something with a Christoph> single keystroke. If someone could update the lilo Christoph> package and provide a decent configuration then lilo Christoph> could also offer a nice menu on boot up so that newbies Christoph> are no longer irritated. I'll have a look at this. Christoph> Maybe lilo could also replace syslinux for the Christoph> bootdisks?? As someone else already said, this would be a bad idea, since the advantage of syslinux is its DOS support. -- Tom Lees <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Status of Debian Policy
>>>>> "Rob" == Rob Browning <[EMAIL PROTECTED]> writes: Rob> Ricardas Cepas <[EMAIL PROTECTED]> writes: >> As of current documentation, you can search only current .html >> file. This is not very usefull. Lynx ( on non-gzipped docs) is >> much slower then info ( on gzipped). Rob> Oh, right I forgot to add "recursive" to my previous comment Rob> about searching. To revise: any documentation tool that Rob> doesn't support incremental, recursive, and regular Rob> expression searches is not acceptable IMO. As far as I know, Rob> that leaves out most html browsers at the moment. In fact, AFAIK the only "browser" which supports all these is Emacs/Xemacs w3-mode. Tom Lees <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt. pgpamauuqqxou.pgp Description: PGP signature
Re: Hamm: Retracting request for chos to be standard
>>>>> "Erik" == Erik B Andersen <[EMAIL PROTECTED]> writes: >> >>>>> "Christoph" == Christoph Lameter <[EMAIL PROTECTED]> writes: Christoph> Lilo 2.0 has the ability to display a file before the Christoph> prompt and also the ability to boot something with a Christoph> single keystroke. If someone could update the lilo Christoph> package and provide a decent configuration then lilo Christoph> could also offer a nice menu on boot up so that newbies Christoph> are no longer irritated. >> >> I'll have a look at this. >> Christoph> Maybe lilo could also replace syslinux for the Christoph> bootdisks?? >> >> As someone else already said, this would be a bad idea, since the advantage >> of syslinux is its DOS support. >> Erik> My wife likes chos because it offers a nice simple and friendly Erik> and obvious like Windoze type of menu that lets her use the arrow Erik> keys to move a color menu bar onto the (unmentionable OS) selection Erik> a press enter. This is very easy, and requires no domestic fighting. Yes, I liked that feature of chos when I looked at it. Erik> I took a quick glance at the lilo 2.0 user's manual last night and Erik> I wasn't convinced that the "message" feature was going to be a Erik> nice simple and friendly and obvious like Windoze type of replacement. Erik> chos is much better than booting Linux using loadlin from a certain Erik> unmentionable OS, (which is how I used to not freak out my wife). Erik> If the "message" feature of lilo 2.0 can make lilo as Erik> friendly as chos, fine, I will use it. I doubt I will be making a No, it certainly won't do that. :( Erik> switch really soon though. How hard would it be to hack bzImage Erik> support into chos? That is the only real problem with chos, right? Well, I have pretty specific requirements (which meant I had been using lilo 17 until lately when 20 came out) - I need the feature which can "hide" one DOS partition when you select another. Erik> Are there any other features lacking from it that make it unusable Erik> by Debian? I can certainly attest to the fact that this is one Erik> piece of software that passes the wife test! I also believe that it can't/won't load its second-stage loader from the second hard drive (i.e. BIOS drive 0x81). This really should be a simple fix, however. -- Tom Lees <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Experiences with compiling Debian
>>>>> "joost" == joost witteveen <[EMAIL PROTECTED]> writes: >> On Mon, 23 Jun 1997, joost witteveen wrote: >> >> > (in fakt so much, that I may be tempted to write it myself. You >> > don't need that many changes). >> >> Well, you need to write your own version of make that looks for any attempt >> to run chmod, chown etc, and then fakes all the ownership and modes in the >> resulting tar. joost> No, what I had in mind is changing chmod, chown and frends, joost> and make them log the intended permissions in a file joost> (specified somewhere in a environment variable), and then joost> changing tar to look for that file (agian in that environment joost> variable), and ajust the permissions/ownerships joost> in the tar file according to that "permissons file". >> I'm not sure whether it's possible in general even then, what if >> the package tries to set the ownership of a file from within >> another shell script or a perl script; how can you intercept that >> so it works properly? If you really want to do this, LD_PRELOAD=/some/where/debian-perm.so from dpkg-buildpackage. joost> Well, if you do it with perl, OK that wouldn't work, but how many joost> packages use perl in their build process to set permissions on files? majordomo for one. But we can add a perl module to do it properly, or hack the perl-scripts to work better (or not be used). This is not that difficult for majordomo anyway. joost> I'm sure not very many. Actually I think most (97%) packages joost> would build joost> OK with what I had in mind. >> With a few minor changes in the way packages are made---having >> tars all made >> as any user, and chowns done after the package is installed, >> either in the postinst or by dpkg first (the former would have the >> advantage of >> running on >> existing systems)---we could build as non-root. joost> Well that would be a lot of changes: many postinst's would need to joost> be changed. No, the file permissions are set in the tar-file from the list generated from the special versions of chmod. A tar-file can be made as any user, you just need a tar which can understand how to put the right permissions in the tar file. -- Tom Lees <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Documentation Policy
>>>>> "Philippe" == Philippe Troin <[EMAIL PROTECTED]> writes: Philippe> On Mon, 23 Jun 1997 20:13:13 +0200 Christian Schwarz Philippe> ([EMAIL PROTECTED]) wrote: >> Option 3: We ship .texi files and produce HTML and/or info files on >> demand (in the postinst script). Philippe> I like this idea a lot. I *hate* having to fetch the source package Philippe> to produce a postscript output... I add my support for this too, but remember texi2html can be quite slow at processing large texinfo documents, and it doesn't produce any kind of indication that it's doing anything. texinfo, on the other hand, is much faster. -- Tom Lees <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> http://www.lpsg.demon.co.uk/ PGP Key: finger [EMAIL PROTECTED], http://www.lpsg.demon.co.uk/pgpkey.txt. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#15484: cvs in bo is still vulnerable
On Sat, Nov 29, 1997 at 10:02:00PM +0100, Martin Schulze wrote: > Package: cvs > Version: bo version > Severity: grave > > Hmbf, > > the version of cvs in bo is still vulnerable to the pserver bug. I'm > sorry, but at the moment I can't provide a bugtraq or cert message, > but there was one. > > Tom Lees told me: > > The cvs in bo is vulnerable. The cvs in hamm is not. > This hole was fixed in upstream release 1.9.10. > > If you want a version for bo which is not vulnerable, report it as a > bug (add a header "Severity: grave"). > > which I'm hereby doing. Can we please have an upload to bo-fixed. This means putting a new version (1.9.10 vs 1.9) into bo. Should I do this? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Libc5 compile machine?
I know there is a machine which I can compile for libc5 on somewhere.
a) Where is it?
b) Can I have an account on it?
I need to compile+upload a new cvs for bo.
Please encrypt any passwords, etc., using my PGP key:-
Type Bits/KeyIDDate User ID
pub 1024/87D4D065 1996/08/26 Tom Lees <[EMAIL PROTECTED]>
Tom Lees <[EMAIL PROTECTED]>
-BEGIN PGP PUBLIC KEY BLOCK-
Version: 2.6.3i
mQCNAzIhaYYAAAEEALkn2+O0pJeXmKltfRrqE1c3WrKZLO7IPvhEpxXXe4/+GPp1
I84AvoKRZ4EiWJF35a1TI8JQWd4y+cE1alug64woCnh0J2MKnEQg+5Il3iib8f5I
H9ygsLK3a9V7X8nG7iNw7tHJ71Z4ZQkhGnbG/jOpRETZMeuSIf152HGH1NBlAAUT
tB9Ub20gTGVlcyA8dG9tQGxwc2cuZGVtb24uY28udWs+iQCVAwUQMiFph/152HGH
1NBlAQF+DAQAtV8FljUGroCkWRGUpA1u5S7FNv+it9ZxTzP/3qKdTd6mjT/mu1AU
tCq9HbucS4qbJ1i2IPCTkxxTngViJDhrSAym95KRF94As5qIWKskEZTLQXSWc9Hf
YlLg1c3dAb7leM1ZN7oUaFtlUrr+Rub7PyNjRJzzIF36R7f8EusThxe0GVRvbSBM
ZWVzIDx0b21AZGViaWFuLm9yZz6JAJUDBRAzhK+v/XnYcYfU0GUBASuIBACpJSov
S8e9O3ZC1nXtPcEtGQeKCt1oTezzfJSXv5KI5nNbryt5fWGBgN6nrfyhsJuUmHIW
IJHjSCLjZDjiL/oUa0KkYqn4BLphUPwn9XYx2IXCijaEsCgJNiU5NgcXiLcYG1ga
HX2vMafjCrvgG5kqTpxfC1t/PjqXkK2bUObZfw==
=CaUy
-END PGP PUBLIC KEY BLOCK-
Thanks.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
ever heard of ftwalk?
dear debian-developers, i've written a freeware package, an awk-like script programming language. it was originally developed for file tree search/maintenance applications, so i called it "ftwalk". a more awk-like mode also exists, called "hawk". it has a rich type system, scads of built-in functions, etc. it does pretty much everything perl does, except of course it doesn't have millions of users or their libraries. it can be used interactively, like a super-calculator. it comes with full on-line doc, and there is a huge postscript file that you can print out. i even have an o'reilly-like pocket guide. it has been ported to several unix systems (linux, irix, solaris, ultrix, aix). the problem is: nobody has heard of ftwalk, nobody uses it, and i've grown weary of trying to do it all myself. but i still think it's too good to just walk away from, so please take a look at it. let me know what you think. and if you have any interest in helping to work on it, i'm game for at least one more release. please take a look at: http://www.contex.com/ftwalk thanks. you can write me back at [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
On 12 May 1997, Manoj Srivastava wrote:
> >> say that if the source is well behaved (that is, it is a tar file
> >> that unpacks into *some* directory other than ., compressed or
>
> Kai> You seem to think a tar that unpacks into "." is a problem. I
> Kai> still fail to see why.
>
> Kai> Just unpack into a temporary subdirectory.
>
> I was just thinking of the problem of determining which case
> it was ...
>
> Suppose I hace A.tar.gz and B.tar.gz, and I need to apply a
> diff to them to get the debianised source. In each case, I unpack
> into ./temp.
>
> Case 1: I get ./temp/A/{1,2,3}, in the second case I get
> ./temp/{4,5}. In case 1 I should cd into ./temp/A before applying
> the diff, in the second case I have to cd into ./temp and apply the
> patch.
>
> At first glance, it may be difficult to determine whether
> currently we are facing case one or two.
>
> There may be an easy solution that is not obvious to me.
Write our own "safe" scripting language. Not difficult, and really rather
useful. So, eg:-
Unpack A.tar.gz in /A
Patch A.diff in /A
Unpack B.tar.gz in /
Patch B.diff in /
This would be very nice IMHO.
--
Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/
PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6
finger [EMAIL PROTECTED] for full public key (also available on keyservers)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: compiling with gettext
On Tue, 13 May 1997, Susan G. Kleinmann wrote: > I have been trying for some time to solve Bug #8882 against the 'sp' > package, which says that in order to make it buildable under glibc, > I need to call libintl as well as libnls in order to accommodate glibc, > and to define LINUX_TYPES_H for glibc. I made those changes and could > no longer get the program to compile. After a while I realized that > the changes were unrelated to my inability to compile the program; which > I tested by going back to the original sources and trying recompilation > without the fixes. Sure enough, I got the same error messages: > > 1. First there's a complaint about an undefined dgettext in > lib/MessageTable.cxx. I think I bludgeoned this one by inserting the > line > #include "/usr/share/gettext/intl/libgettext.h" > in the top of that file. This means you compiled with libc6 headers but didn't link with libc6. Linking with libc6 will fix the above, and fully gettextizing the sources will fix it for libc5. > 2. When I then recompile the program I get the message: > MessageTable.cxx:102: parse error before `const' > MessageTable.cxx:103: parse error before `const' > MessageTable.cxx:104: parse error before `while' > MessageTable.cxx:105: parse error before `while' > > where the four lines in question are: > extern char *dgettext(const char *, const char *); > extern char *gettext(const char *); > extern char *textdomain(const char *); > extern char *bindtextdomain(const char *, const char *); The problem is that gettext, etc., are being recognized by the preprocessor! You don't need these, you should #include the appropriate libintl.h instead. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
On Sun, 11 May 1997, Joey Hess wrote: > Lars Wirzenius: > > They might not understand enough about shell scripts (or Perl, or > > whatever the script is written in) and whatever tools the script uses > > to make an informed decision of whether the script is safe. With the > > current scheme, they only have to trust gzip, tar, patch, and chmod, > > And all of debian/rules. And debmake or anoy other programs called by it. > They are planning on building this package, right? IMHO this is where we ought to be looking to improve our source packaging system. At least we should allow building as a non-root user as soon as possible (using the new GNU tar). -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug system `followup' messages
On 12 May 1997, Manoj Srivastava wrote: > Hi, > > I think, from the volume of discussion on bugs-dist, that most > developers have signed up on that list (and I at least follow it > quite diligently). I would rather not clutter up debian-devel with > that traffic (if we send all reports to debian-devel, please arrange > to have the debian-bugs* list stopped, since they will be largely > useless). I agree. However, I have cut back on following debian-bugs-dist, as I don't have the time at the moment, and I consider debian-devel more important. I suspect other people may do this as well. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
On Sun, 11 May 1997, Joey Hess wrote: > Kai Henningsen: > > Remember: no shell scripts in the source packages that are needed for > > unpacking. It's just too dangerous. > > I don't understand why this is more dangerous than debian/rules. Why? You don't get to review it before it's run. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Sending closed bug notices to interested parties.
On Sun, 11 May 1997, Chris Walker wrote: > Further to the announcement from Ian Jackson about the creation of a > mailing list for closed bugs > > There may be circumstances when I wish to know if a bug has been closed, > but am not the person who reported the bug (eg I want to know when the > CVS/inetd.conf bug is fixed so I can feel safe upgrading). Bad example. Upgrading is what causes that bug to happen :( > Would some mechanism of saying "when this bug is closed notify me as > well" eg by sending a specially formulated e-mail, or perhaps some web > interface. This might be useful, as in general I probably don't want to > see all bug report closures. Maybe a "watch" feature, where you can tell the bug system what you want to see about a bug report (if you have ever used CVS watches, you will know what I'm talking about). -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#8794: wrong arch declaration in dpkg.
On Sun, 11 May 1997, Ian Jackson wrote: > > The good definition of powerpc processors is 'powerpc', not 'ppc'. > > Was this issue settled ? This will be hard to change later, so it's > important to get it right quickly. I believe it was. > > --- archtable Thu Feb 27 21:53:23 1997 > > +++ archtable.new Wed Apr 16 16:22:49 1997 > > @@ -21,4 +21,4 @@ > > alpha alpha alpha > > m68k m68km68k > > armarm arm > > -ppcppc ppc > > +powerpcpowerpc powerpc This is already in dpkg 1.4.0.15. But it should also have:- ppc powerpc powerpc -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
On Sun, 11 May 1997, Jim Pick wrote: > > You might want to unpack a source package for other reasons than > > to build it -- e.g., I've sometimes searched for documentation. A > > non-programmer might want to do this so that they can typeset the > > documentation in LaTeX, instead of printing out the LaTeX2HTML'd > > version. > > The srcpostinst thing was just a trial baloon - I don't think it > went over very well. So I'll drop that idea. But if we go with > a source package file format that is the same basic thing as > what a .deb file is, we can always add it later (if needed). > I think it's better to unpack the upstream sources in the > debian/rules makefile anyways (using any tool available on the > system). I'd oppose having a specialized script file for > unpacking them, since it's unnecessary -- you can already do > that from the debian/rules makefile. This would be better - someone can overlook the debian/rules file first. > As I said before, I'm quite interested in having a source package > that automatically unpacks the upstream sources and patches itself > for the purposes of debugging -- and also can be set to automatically > build too. This is the equivalent of a "make world". But nobody's This would be difficult. I always thought that make world was simpler than this, though - what does is do exactly? (I haven't used any of the *BSD distributions). > saying that the system administrator can't have the option of > just "installing" the source, without running any scripts. This > should probably be the default behaviour. Maybe we should limit our support to only certain formats instead of needing scripts to unpack it - the dpkg end of this could get messy with pipes or temp. files. I propose we support zip and the various tar formats only. > Before I was advocating the use of a separate "sdpkg" program to > install source packages, but it could probably be done with > just "dpkg". > > ie. > > dpkg -i jdk_1.0.2-7.sdeb > > Since the extension is .sdeb, dpkg would know that it was a source > package, and just put it in the appropriate place. Maybe > /var/lib/dpkg/source/jdk_1.0.2-7 possibly? Since the package > has dependencies (to .upsdeb's for upstream source, and .deb's for > binaries needed to build it), those would also need to be installed too. This should probably be /usr/src/debian. Then we could have a nice set of Makefiles installed to let us do a "make world" style system. (If I understand "make world" properly). -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#9242: dpkg: dpkg could be smart about Changes information
On Sun, 11 May 1997, Ian Jackson wrote: > > It would be useful if the kind of information sent to the debian-changes > > mailing list were integrated into dpkg. For available updated packages, a > > user > > could use information about the number and Urgency: of each intervening > > update. > > Also useful would be access to the developer's comments on each upgrade. > > I can see why this would be useful. However, there is the problem of > transferring all of this data to the user's system. > > The more information we try to provide the user with the more they > will have to download for each package that they choose not to install > or upgrade. > > In this particular case, I'm unconvinced that supplying the user with > the whole change history of a package is a reasonable thing to > attempt. IMHO, a parser for the "Last week's uploads into i386" files regularly posted to debian-(devel-)changes would be ideal. Then you create another mailing list to house these announcements only, and make dpkg remove the old info when the package is upgraded. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Proposal: New source format (was Re: [Fwd: Re: dpkg question])
On Sun, 11 May 1997, Jim Pick wrote: > The point I was trying to make was that having dependencies on > binary packages would be really, really nice. This gets more complicated. To allow for cross-compiling or bootstrapping, some packages need to be compilable using the Source from another package, so eg:- SrcPackage: xmp Depends: awe-drv | src.awe > > > Klee favours having a simple .sdeb and no upstream .upsdeb's. I think > > > we need to debate this some more. > > > > Well, my mind's decided. Bandwidth costs, cross-Atlantic especially, > > and the trivial inconvenience of having three files instead of one > > is very well worth it in real money. > > I basically agree with this. But I'm going to keep an open mind, until I > see more debate. I totally agree. RPM's way _is_ broken. > > > I think you missed the point -- this system enables a single source > > > tree. > > > > The current system can be a single tree as well (put all source > > packages in one directory, and do a loop with "dpkg-source -x", > > and "dpkg-buildpackage -rsudo -uc -us"), but both systems are > > pretty far from the BSD source tree, I think. > > Unfortunately, with the current state of the source tree, this doesn't > really work. It's way too easy to build source packages that > don't unpack with dpkg-source -x. I've seen way too many packages > for my liking that won't build out of the box. Many of them > depend on specialized environments that only exist on the > original maintainers machines. IMHO this is where we need the possibility of dependencies on Source or Binary packages. Also a standardized "build lab" (build-i386.debian.org, etc.) being enforced would be a really nice way of ensuring a self-consistent distribution. But I'm not sure if we have the resources to do that. > > But that's beside my point -- there's so much other work to > > do at the moment that I don't think big changes the source > > packaging format at this point will improve things. > > There's always too much to do... :-) We should be planning this for Debian 2.0. The release of that will have lots of nice new features (deity for one). > > > Actually, I think the scheme I proposed is actually very incremental, > > > > It would change all source package file formats, and all tools > > relevant to source packaging, and would require our developers > > to learn to deal with a third source packaging format. A bit > > too much of an increment for me. :-) > > I agree that the current source packaging system works, but it is broken > in many ways. So we're going to have to fix it sooner or later. Preferably sooner. It would be really nice if deity could handle *source* packages :>. But its getting designed pretty quickly, and might not be flexible enough by the time the new source stuff gets done. > If we wait until later, there's going to be even more of an installed > base of tools and packages that are going to need to be changed. So my > personal preference is to spend some time up front to get our act > in order. Right now, this ranks #2 on my list of things Debian has to > fix -- dselect/diety is #1. dselect/deity and this are basically part of the same overall problem - the packaging and distribution system needs a bit of an overhaul. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Imminent Checker upgrade release
On 12 May 1997, Ben Pfaff wrote: > (I actually had to install an extra hard drive in order to build this > package. It takes over 200MB of hard disk space to build--is that a > record?) No, IIRC the just the XFree86 sources take ~250MB :> -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: compiling with gettext
On Wed, 14 May 1997, Susan G. Kleinmann wrote: > Yesterday I reported that I was no longer able to compile the package 'sp'. > Santiago Vila and Tom Lees both kindly offered suggestions, but both of > these still leave sp in an uncompilable state. > > Santiago pointed out that the problem might be intrinsic to the > existing gettext-0.26, and suggested I wait til gettext-0.28 becomes > available. This might be a very long time, since gettext-0.26 came out > in December. > > Tom pointed out that my include line: > > > #include "/usr/share/gettext/intl/libgettext.h" > referred to libc6 headers, which must surely have caused a problem since No, that is the GNU gettext generic header, that is right. What I said was, you were trying to link against libc6 but you compiled against libc5. > I was linking with libc5. So I changed this to > #include "/usr/include/libintl.h". > But this produces the same result as if I had no include line at all: You need to make sure you are linking the libintl.h file into the right directory, and including the right file (-I../intl, etc.). > ../lib/libsp.a(MessageTable.o): In function > `GettextMessageTable::GettextMessageTable(void)': > MessageTable.o(.text+0x35): undefined reference to `bindtextdomain' > ../lib/libsp.a(MessageTable.o): In function > `GettextMessageTable::getText(MessageFragment const &, String &) const': > MessageTable.o(.text+0x69): undefined reference to `dgettext' Also, you need to link with -l../intl/intl.a. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Pbs with locale and fonts
On Wed, 14 May 1997, Mathieu Guillaume wrote: > I've encountered two little problems in hamm. > First one shows while using dselect. I have the following message several > times: > [perl i18n stuff removed] Basically, you need to set LC_ALL, as well/instead of LANG. > Second thing is the fonts: > > [15:39:24] root> /usr/bin/setfont lat1-16.psf > Bad input file size > > >From what I could see, setfont and the fonts I use come from the same > package (or were updated at the same time) since they have the same date. > Too bad they don't seem to be compatible... No idea on that one. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dpkg verify mode for security?
On Thu, 15 May 1997, Chris Fearnley wrote: > 'Amos Shapira wrote:' > > > >I was asking over Linux-ISP about doing cleanup after breakins and got > >many "use tripwire" answers, and one which says that RPM has a verify > >mode which checks for files which were changed since they were > >installed. Can the dpkg maintainers consider adding such a feature > >for Debian? > > What does the rpm verify give you? As far as I can tell it gives a > false sense of security. Nothing more. The rpm database is easily > hacked once root access is attained. > > Tripwire or something similar is the only viable option. If the maintainers PGP-sign the verification data, they should be OK (providing that you keep your PGP keyring on read-only media, like a Debian CD-ROM). I'm presuming the best way to go is to have PGP-signed md5sums. Another alternative is to keep a copy of the md5sums on read-only media (CD-ROM springs to mind), and check against that. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Problems with the current source packaging scheme
On Mon, 12 May 1997, Lars Wirzenius wrote: > At least the following have been pointed out as problems with > the current (source) packaging scheme. I'm not commenting > on what the proper solution to each problem is, and I wish > no-one else would, either, just so that we could, for once, > avoid the Debian-typical design-by-mail-flood. :) > > I _do_ ask everyone to add things to the list (via private mail > to me -- I'll summarize -- or on this list). Or point out non-problems, > of course. > > * .orig.tar.gz gets separated from .dsc and .diff.gz, and may get lost > > * upstream sources not preserved bit-for-bit; need to be repackage, which > can destroy upstream digital signatures, and makes it more difficult to > check that .orig.tar.gz and upstream sources are the same > > * no automated way to check .orig.tar.gz files against upstream distribution > (located on well known web sites), or upstream digital signature, if any > > * no way to automatically retrieve the upstream source package, or its > updates OK, similar to these three - no option to retrieve the upstream source from a closer mirror (or CD-ROM!). For example, I have a *very* local mirror of the GNU sources, and a couple of CD-ROMS of them, so it would be handy if I could download everything else. > * no dependencies for source packages I'd like to add here that we need two types of dependencies - on *source* packages, and on *binary* packages. And some others:- * No "dpkg-ftp/dselect" type thing for getting/installing sources * No standard location to install sources (/usr/src structure should probably be made policy) * No provision for building multiple binary packages from one source installation easily (i.e. VPATH builds). An example of this is, say I have the binutils source in /usr/src/debian/binutils-2.8, and I want to build binutils for m68k in ~/binutils-m68k, and for i486 in ~/binutils-i386. This is currently possible for the configure script and the upstream Makefiles for the most part, just not for the debian bits and pieces. * No easy provision for an essentially binary-only package, e.g. quake, where upstream source aren't provided - the source pkg is almost identical to the binary pkg - they should be in the same package probably. Another example - in my file-rc package, the debian/rules file does not do *anything* for build, and for binary, just copies stuff into the right place. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: libc6 migration -- xlib
On Mon, 19 May 1997, Mark W. Eichin wrote: > Is there a web page or other document that explains what our strategy > for libc6 is? I'm not talking about random comments on the list, I > mean something nailed down that I can refer to... > > In particular, I've got a few issues to work out. > 1) libgdbm -- libc6 includes libdb, and therefore gdbm is > supposed to be unnecessary. If this is true, it needs to be written > down, so I can point people at it -- otherwise, I need a strategy for > renaming the package (since there needs to be a libgdbm.so for libc5 > and a seperate one for libc6... the former isn't changing, obviously; > how do we change the latter so that "-lgdbm" still works for users > building against it? [since db can't read gdbm files, that *will* > continue to happen.]) The general policy is that libc5 stuff should go in /usr/i486-linuxlibc1/lib. So that's where you put all the stuff compiled against libc5. > 2) X -- a full release of X requires tk41-dev to build > XF86Setup (it uses the static lib, so the end-user doesn't need it.) > But tk41-dev probably won't be available for libc6 until I release X. > Ooops :-) I can hand-release xlib6-dev by itself, (into experimental, > perhaps?) so that someone can build the tk packages... or I can build > that particular lib by hand until then (but then would still have to > leave X in experimental unless I took over the package, eww.) And > what *do* I name things? I'd guess that xlib6 is untouched, the > version built with libc6 gets called xlib6-libc6 (eww), I release an No. xlib6 should be for libc6 (more long-term solution). Then create an xlib6-libc5. How we handle the dependencies for this, I don't know. Fix for all packages which require libc5 still, and recompile those which can work with libc6 would be the best idea. > alt-xlib6-dev that replaces and provides xlib6-dev (which alt-libc5 > doesn't?) and then xlib6-dev can be the new version? Am I missing > anything? No, alt-xlib6-dev should _NOT_ conflict/replace/provide xlib6-dev. It should install into /usr/i486-linuxlibc1/..., or something (maybe /usr/X11R6/i486-linuxlibc1), and it should co-exist with xlib6-dev. ld.so can work out which to use. > 3) can I drop the a.out-only "dlltools" package now? :-) No. It is needed to build a.out versions of, e.g. svgalib. Some older binary-only programs only come in a.out format (Doom, for example) :(. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: rm -r * and the default prompt
On Mon, 19 May 1997, Christoph Lameter wrote: > >Anybody should know that before typing "rm -rf *" or an equivolent, > >you THINK FIRST, every time. > > The problem does not arise when you type rm the first time but after you > have some confidence and you think you know what you are doing. > > Everybody knows what you should think first. But who does after getting > used to it? Generally, after installing any system, I add this to ~/.profile for root:- alias rm="/bin/rm -i" This pretty much stops me from doing anything stupid - especially by a typo, like mistyping rm /etc/*~ as rm /etc/*... I did that once :(. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: config packages [Was: rm -r * and the default prompt]
On Tue, 20 May 1997, Enrique Zanardi wrote: > On Tue, 20 May 1997, Nicol=E1s Lichtmaier wrote: > > > I think that this is the kind of thinking that is killing Debian. > >=20 > > 1) Newbie setting doesn't mean annoying settings. > > 2) `real men' like you can change those settings. > > 3) Configuration packages is an awful idea that goes against the idea of > > package. A better solution would be a system setting that packages would > > check an install the apropiate default. > > 4) We aren't building a distribution only for us. > >=20 > > Let's stop being so narrow minded... We need a little of marketing... We > > need to be known as an easy distribution for newbies... > > The problem with that approach is that many of those "newbie" settings > are just a matter of taste. We don't want to set a thousand of those > parameters in hundreths of different config files that will have to be=20 > edited to reset them. Not if we can use a config database to do most of the mindless changing of defaults. > It would be easier if all those parameters could be grouped in a > single config package. We may have a handful of those to choose > (hint: "themes"). It may even be useful for localization! ^^ NOO We should _NOT_ use this name. I hate it (and its probably trademarked as well). But I don't have a better suggestion :( However, good point. I don't like the idea of a package doing this, though. I think the best idea will possibly be to get a proper global configuration interface sorted out (dcfgtool, anyone?), and then you could do something like:- /theme1/bash/ps1"\\h:\\w\\$ " /config/bash/ps1not set /default/bash/ps1 "\\$ " Then, set "theme" to "theme1", and you will have your prompt as "\\h:\\w\\$ ". Set it to "none", and you get the default. Set the variable "/config/bash/ps1", and it won't be affected by changing the "theme". Nice idea, maybe we should add a scheme like this (implementation etc.) to the objectives for hamm. > I don't see the reason why you don't like the idea of Config packages. > Can you elaborate a little more on that, please? It just seems wrong to me (like having a "dummy" package which contains no files, but has dependencies). It's not clean. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On Mon, 19 May 1997, Brian C. White wrote:
> Hamm
>
I think its been agreed that this will be called "Debian 2.0", so why not
add this here.
> * All packages are in the new package format.
Possibly a new source package format may be created, so we should resolve
this before putting too much effort into converting twice.
> * All base packages are compiled with libc6.
Should be all pkgs in the main distrib really.
> * Fix packages currently depending on 'libc5-dev'.
> * Officially supports {i386,m68k,alpha,sparc} architectures (mips,ppc?).
> * No more dependencies on obsolete virtual packages (X11R6, elf-x11r6libs,
> ...).
> * No a.out executables anymore.
> * Much improved dpkg/dselect.
> - Move config information from install scripts to "cfgtool" (???)
I'm having a look at ways of doing this. It would be really cool to
integrate this into deity.
> - Some sort of package-grouping mechanism for dselect
> - New run-level layout (???) [12]
> - No bug reports older than 9 months at release time
And another one:-
* Official Debian logo to be chosen
Footnotes 1, 4, 5, and 7 can be removed AFAIK.
--
Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/
PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6
finger [EMAIL PROTECTED] for full public key (also available on keyservers)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
On Sat, 24 May 1997, Andreas Jellinghaus wrote: > > > - Move config information from install scripts to "cfgtool" (???) > > > > I'm having a look at ways of doing this. It would be really cool to > > integrate this into deity. > > there are three tools : cfgtool (lars wirzenius), nod (winfried > truemper), dcfgtool (mine). and someone is working on a _real_ tool (all > three have flaws, and if this way we will get a tool with all good > features). I know all this. But when will it be finished? What about beta versions? Is there a mailing list (other than debian-admintool)? > what they do : > currently many scripts in /etc hold config values. this is a bad thing. > one solution is to write these variables in other text files, and use > the source command in the shell script to read them. this is not a good > way IMO. > > the other solution is to have a small utility that stores these values, > can change them and gives the values to the scripts. The third solution, which I prefer is a utility which modifies the variables within the scripts - it's faster, it is more "backwards compatible" with sysadmins from other Unices, and generally it's nicer (less dependant on the cfgtool at boot-time). > as you can see, it's a small text database. so it has nothing, absolutly > nothing to do with deity - that's a GUI. OK, I should refrase what I wrote. It would be really cool if we upgraded the packaging system to handle configuration integrally (so we can do configuration _BEFORE_ an installation, etc.). Deity definitely _IS_ the right place for this - a GUI to do the configuration with, at the same time as packaging control! > i will wait till the new tool is released, than we can remove all other > tools (at least my will get removed - there is no reason to keep it.) I wrote a perl script to do this (mainly as an exercise in perl, which I am learning). If anyone wants it, I could happily package and upload it into experimental. > then we should : > a) choose _one_ cfgtool (the current one have big flaws. the new one > will not have them). > b) change policy to _not_ allow config information in /etc scripts > c) change policy to _not_ allow additional debian uniq config files to > fix b). only the textdb should be used. > d) think about getting rid of some config files only used by shell > scripts, and use the textdb instead. > > > Footnotes 1, 4, 5, and 7 can be removed AFAIK. > > what about footnote 10 (cu* devices) ? debian 1.3 has no call out > devices ! (*evil grin*) True, this has been done in the package, but not everyone may have removed their /dev/cua* files from previous installations. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: runlevels [was Re: Upcoming Debian Releases]
On 23 May 1997, Milan Zamazal wrote: > I know nothing about runlevel standards, just my opinions: Same here. > >>>>> "AK" == Alexander Koch <[EMAIL PROTECTED]> writes: > > AK: level 1 is without net, 2 is with it all (imo including nfs > AK: and the like) and 3 is xdm, 6 was shutdown or halt or > AK: whatsoever. at least that i remember from some german > AK: distribution. > > I'm no big sysadmin but I think we can use all 1 to 4 levels. One > free runlevel could be enough (in actually, if *I* need some > modifications, I make them by modifying existing runlevels not > creating new ones). > > AK: default runlevel is 2 so why should nfs start with 3? > > I'd like something similar to: > 1: single user > 2: multiuser with minimal networking, probably without offering services > 3: full networking (NFS, xfs, anonymous ftp, ...) > 4: xdm? (yes, it is common on Slackware and RedHat to start xdm >according to runlevel, but maybe Debian /etc/X11/config concept is >better) No, we don't need xdm in runlevel 4. A better solution would be this (but it is more difficult, requires multiple inetd.conf files):- 2: multiuser, minimal networking, no networking daemons (including inetd). 3: multiuser, "client" networking (rpc.ugidd, ident, etc.) 4: multiuser, "server" networking (ftp, http, finger, etc.) > 5: empty for making special local runlevel? Yes, good idea. > So if I want to do something without being too used from outer world, > I can switch to level 2 (and I can still telnet or ftp somewhere). > > AK: if 3 gets xdm, perhaps gpm should be disabled and the like? > > Remark: gpm should be disabled only when it doesn't work as a > repeater. It doesn't need to be disabled, it just saves memory. It will detect when X starts up, and give up its own handling of the mouse. Only PS/2 mouse devices used cause a major problem with this (single-open only), but they don't do that any more IIRC. > BTW, I don't like RedHat concept of empty level *4*. When I upgraded > HW on some RedHat machine, I lowered default level from 5 to 4 in > expection it will disable just xdm. Then I spent an hour looking for > explanation, why many services don't start after changing HW. After I > explored runlevel 4 was empty, I was far from being polite... Agreed. I think a better way than doing runlevels directly in packages, though, may be to set a package startup script's "type" - minnet, netclient, netserver, misc, etc. Then, define runlevels to include certain "types" of script. Just an idea (very difficult to implement with symlinks for /etc/rc?.d), what does anyone else think? -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Splitting debian-user (was Re: DO NOT UPGRADE TO POTATO...)
> But if we create _debian-user-unstable_, the _debian-user_ readers > would miss (would they care?) the discussions -- some of them > interesting -- about changes, and might therefore be less well > prepared to handle the upgrade to potato when it becomes stable. > > So I obviously can't make up my mind; I think we should let the > _debian-user_ population decide: would you like to split the group? I don't think it's a good idea to split them up. Many issues discussed in debian-user apply to both stable and unstable, not to mention Linux in general. I like the idea of reading one list and being able to beneift from the experiences of people running both distributions. Occasionally when I want to know more about the "bleeding edge", I'll subscribe to debian-devel for a while and see what's going on. Tom
Re: better RSYNC mirroring , for .debs and others
On 9 Mar 2000 12:56:29 -0500, Jacob Kuntz wrote: > tom rothamel is working on a project called debdiff that works towards the > same goal. please read his announcment thread, which is archived at > http://www.debian.org/Lists-Archives/debian-devel-0002/msg00391.htm. The code associated with this is now available at <http://onegeek.org/~tom/software/ddiff/>, for what it's worth. I do happen to think that rsync is an inefficent solution to archive mirroring, however, as it seems it would need to scan and checksum a huge number of files every time it runs. Probably a better way would be to have dinstall[1] generate a list of changes it makes to the archive, and have people mirroring the archive use those lists to figure out what needs to be downloaded. This would also have the benefit of making it easy to ensure that archive mirrors are always in a consistent state. (ie, Packages.gz is updated after new packages have been downloaded, but before old packages are deleted.) [1] At least, I think that's it. I'm not really sure how things work on the Debian end... I probably won't know for sure until hell freezes over^W^W^Wnew-maintainer reopens. -- Tom Rothamel - http://onegeek.org/~tom/ -- Using GNU/Linux The Moon is Waxing Crescent (16% of Full)
