Re: System spec.'s
On Wed, Sep 12, 2001 at 04:30:40PM -0700, Ralph Jennings wrote: likely work (unless they're broken). Ha. -- Jacob Kuntz http://www.lucidpark.net/
Re: Bug#112020: ITP: keychain -- An OpenSSH key manager
On Wed, Sep 12, 2001 at 07:08:32PM -0500, Cesar Mendoza wrote: On Wed, Sep 12, 2001 at 01:05:12PM +0200, Richard Atterer wrote: On Tue, Sep 11, 2001 at 03:00:44PM -0500, Cesar Mendoza wrote: What's really needed is a little work on ssh-agent so that - when ssh asks for a DSA passphrase, it also sends it to ssh-agent - ssh-agent can expire keys after some time of inactivity I know that but for now we have to work with what we have, don't you think? There's something about a long-running shell script with my secret keys in it that sends shivers down my spine. Not for any specific reason, it just sounds bad. This functionality should be worked into a patch for ssh-agent. Ask yourself, would you really use this on a security-sensitive box? -- Jacob Kuntz http://www.lucidpark.net/
Re: why dig ? I wanna use nslookup !
from the secret journal of Gerrit Pape ([EMAIL PROTECTED]): What makes you reacting so blind and childish? This is not the topic of this thread, just notice that there are debian people running djbdns - relaxed, bind-free. Not having real djbdns (+co) packages in debian is a pity. Closed-source software is even more of a pity. DJB's license (or lack there of) makes it impossible to distribute binaries that aren't compiled by DJB himself. You're free to run whatever you want on your machines, but don't expect everyone to follow your lead. I haven't been following this thread, but shouldn't it have ended or moved to another list as soon as someone said upstream? -- Jacob Kuntz Technology Director The Real Estate Company [EMAIL PROTECTED]
Re: why dig ? I wanna use nslookup !
from the secret journal of Gerrit Pape ([EMAIL PROTECTED]):
On Wed, May 02, 2001 at 04:02:33PM -0400, Jacob Kuntz wrote:
from the secret journal of Gerrit Pape ([EMAIL PROTECTED]):
What makes you reacting so blind and childish? This is not the topic of
this
thread, just notice that there are debian people running djbdns - relaxed,
bind-free. Not having real djbdns (+co) packages in debian is a pity.
Closed-source software is even more of a pity. DJB's license (or lack there
Uf, read the source, technical and library documentation at
http://cr.yp.to/djbdns.html
Closed may have been the wrong word. Non-free would have been more
accurate. You can study DJB's code all you want, but not your own binaries
or modified source.
I am willing to stop or move this thread if wrong facts are clarified.
I was referring the the parent thread, which was on the subject of nslookup
being depricated. Since this is not a debian issue, so much as a BIND issue,
it should be discussed on their lists, not ours.
I read somewhere (probably either oreilly's dns book or the bind admin
guide) that nslookup is an innacurate tool anyway, so I'm not the least bit
sorry to see it go. IIRC, nslookup tries to mimic the behavior of the
resolver libraries rather than using the libraries themselves.
{host,mx,ns,soa,zone,,txt} are each less typing anyway.
--
Jacob Kuntz
Technology Director
The Real Estate Company
[EMAIL PROTECTED]
Re: why dig ? I wanna use nslookup !
from the secret journal of Jacob Kuntz ([EMAIL PROTECTED]):
Closed may have been the wrong word. Non-free would have been more
accurate. You can study DJB's code all you want, but not your own binaries
^
distribute.
{host,mx,ns,soa,zone,,txt} are each less typing anyway.
Not that there's anything wrong with dig, I just prefer the simplifed syntax
and output format of the above util. Host, BTW is one binary that behaves
differenly based on it's name.
--
Jacob Kuntz
Technology Director
The Real Estate Company
[EMAIL PROTECTED]
Re: why dig ? I wanna use nslookup !
from the secret journal of John H. Robinson, IV ([EMAIL PROTECTED]): it says ``that a user would obtain by installing''SO this means: on (say) a Debian 2.1 system, if a user were to get the tarbal, and compile it against the default libs, as per the instructions, and install as per the instructions, the binary installation should match. this means the same locations, against the same libraries. this also means (to my reading) no after-market patches, for the binary package. I'm not sure if this has come up before, but since DJB likes to install in /var, wouldn't any Debian package fail the policy check? *geesh* [echoed by the crowed] -- Jacob Kuntz, who wants to high-5 jon for not apologizing for djb Technology Director The Real Estate Company [EMAIL PROTECTED]
Re: have apt use an rsync style tool ?
from the secret journal of Jean Charles ([EMAIL PROTECTED]): wouldn't it be great if you could just download what has changed on some package ? for exemple There was a HUGE flameware on this issue a few months ago. Check the archives and be sure you have something positive to add before you stir up the embers. -- Jacob Kuntz Technology Director The Real Estate Company [EMAIL PROTECTED]
Re: Creeping featuritis (was: Re: tar -I incompatibility)
from the secret journal of Sam Couter ([EMAIL PROTECTED]): No it's not. It does one thing (Advanced Package Management), and does it fairly well. Just because the thing it does is a complex task doesn't mean it's got creeping featuritis. If it tried to do more than just package management, that would be a different story. right, like if it tried to read mail or interpert lisp (which are the primary indicators of featuritis). -- jacob kuntz [EMAIL PROTECTED] underworld.net/~jake
Re: Potato packages
from the secret journal of Russell Coker ([EMAIL PROTECTED]): I am sure that there are lots of people who want to use some of these features but who don't want to track the unstable/testing releases of Debian to do so. Do we have a repository of packages to support such people? i believe this is why we *have* testing. -- jacob kuntz [EMAIL PROTECTED] underworld.net/~jake
Re: dueling banjos
from the secret journal of Buddha Buck ([EMAIL PROTECTED]): At 01:18 PM 12-26-2000 -0800, Ben Gertzfield wrote: Kim == Kim Richards [EMAIL PROTECTED] writes: Kim could you please mail me sheet music for dueling banjos This is about the third or fourth time we've gotten this request. Does anyone know why? :) (Here's an earlier one I found.) I just did a Google search on duelling banjos debian and came up with nothing -- just two hits to our archives from the dualling banjos thread that happened one of the previous times we got this strange request. has anyone tried asking the posters? -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] Strategery -- George W. Bush Lockbox -- Al Gore
Re: NSA's Secure Linux Distribution
from the secret journal of Brent Fulgham ([EMAIL PROTECTED]): No doubt most of you have seen the NSA's secure linux posting on Slashdot this morning. Looking at: http://www.nsa.gov/selinux/docs.html there appears to be several utilities that have been updated to provide enhanced security. Should we be merging these patches into Debian, assuming they appear to be compatible with our policy, etc.? unless we have a policy against security, it should be fine. :) it's all gpl. -- jacob kuntz [EMAIL PROTECTED] underworld.net/~jake
Re: NSA's Secure Linux Distribution
from the secret journal of Buddha Buck ([EMAIL PROTECTED]): unless we have a policy against security, it should be fine. :) it's all gpl. i posted that before i hit the download page. Security-enhanced Linux is not an attempt to correct any flaws that may currently exist in Linux. Instead, it is simply an example of how mandatory access controls that can confine the actions of any process, including a superuser process, can be added into Linux. The focus of this work has not been on system assurance or other security features such as security auditing, although these elements are also important for a secure system. In addition, while they provide 15 new or modified system utilities, they also provide 36 new system-calls, and require a custom kernel to handle the system. On their to-do list are the following items: Port the kernel patches to the latest 2.2 kernel Port the kernel patches to the 2.4.0 kernel Port the utility patches to the latest versions of the base utilities so I'm not even sure we -could- apply their patches, even if we wanted to. you have a point. but what about seperate packages for the modified ones, or even wrapper scripts like we do with dhcpd? that sounds somewhat ugly, adding quite a bit of bulk to the default install since even tar and procps get patched. -- jacob kuntz [EMAIL PROTECTED] underworld.net/~jake
Re: NSA's Secure Linux Distribution
from the secret journal of Britton ([EMAIL PROTECTED]): Pardon my paranoia, but even if it was worth making all the changes they are talking about (which are pretty extensive), I'd want to see anything coming from the NSA audited carefully before being included. Britton Kerin you're pardoned. i'm sure we're all a little wary of No Such Agency right now, with carnivore and all. but what fact are these fears based in? would the nsa really plop a backdoor in an opensource project, hoping it missed and accepted with the rest of the code? i doubt it. their whole (advertised) motive was to protect against the possibility of Trusted (AIX|Solaris|PalmOS|whatever closed os) going belly up. of course i plan on running this monster on a throwaway machine before i make form any real opinions. -- jacob kuntz [EMAIL PROTECTED] underworld.net/~jake
Re: Boost Windows Reliability!!!!!
from the secret journal of esoR ocsirF ([EMAIL PROTECTED]): A possability might be to have a signature key. This is not significantly different than the extra header idea but it would allow *any* MUA to work with it. Could be something like a GPG fingerprint or whatever. Just a thought. first thoughtungh. overhead./ -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] Strategery -- George W. Bush Lockbox -- Al Gore
Re: RFC: GUI tools for common Debian admin tasks
Frederic Peters ([EMAIL PROTECTED]) wrote: - debconf: dpkg-reconfigure users ? debconf is there to configure applications and I don't want to replace it at all. It is just not suited for some tasks agreed, but effort should be made to keep the interface consistent between GUI admin tools and the gtk interface to debconf. - linuxconf: Marco d'Itri sent a comment I agree with (excepted for the insecure part where I don't have enough knowledge to judge) someone also pointed out that linuxconf is geared to redhat systems, and would make use on a debian system ugly. -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: GUI tools for common Debian admin tasks
Daniel Burrows ([EMAIL PROTECTED]) wrote: Erm, how many 'newbies' are going to know what a class A vs class C network is, or what a gateway is, versus the number who'll freak out and run in terror? ok, now i hate seeing free apps/desktop systems that just copy windows, and i dislike even more the idea that windows is a good standard to follow, but i do have to disagree with you on this point. windows doesn't hide the gateway from you, it's there right under netmask. lots of newbies use windows. i'd go so far as to say many people reading this list probably started on windows. have any of us freaked out and ran away? as far as the network class thing, lets just make sure it's possible to have classless subnets, too. -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help on Debian Project - Need Me?
Ben Collins ([EMAIL PROTECTED]) wrote: Well, IMO, anything that goes on the Debian website better be created by free software. No offense, but if I start seeing Made with Macromedia or Designed with Photoshop on the website, there will be hell to pay :) There are several criteria for the website, unspoken, but surely everyone knows this: i don't have the source to the bios my system uses to boot, and i bet none of us have the source for the bios on the build machines. on the other hand, i don't much care for flash on the debian site. does mozilla support SMILE? that's syncronized multimedia event language, a W3 consortium stanard that tries to do much of what flash is capable of. not that the debian site NEEDS flash, but that's another debate. -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
David Starner ([EMAIL PROTECTED]) wrote: Well, some of us don't have that problem - most Americans have flat rate connections. i think he was referring to cost of storage, not cost of transfer. -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Simon Richter ([EMAIL PROTECTED]) wrote: The packages file is the smallest part of the downloads -- What about the debs? it may be small but it's probably the file that gets transfered the most, espically if you run unstable. -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netscape 4.75 in security.debian.org is broken
Christian Surchi ([EMAIL PROTECTED]) wrote: Package: communicator Version: 1:4.75-1 Severity: grave I've updated communicator from security.d.o's potato packages. I had to erase my preferences in ~/.netscape because it refused to save new settings and when launched it was always like the first time with box with license. I've lost cache, proxy, smart browsing, default page, fonts settings. I've lost all application section, netscape wants to see images with xv (all types, jpg, gif and png included). I set again correctly for jpg and gif, but no results with png. Plugin do not work, in application section I can't use it. I've lst all my settings for them. not to mention that text/plain is displayed with vim! -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Intent To Split: netbase
Marcus Brinkmann ([EMAIL PROTECTED]) wrote: We can put everything in /bin and make /sbin a link to /bin. This way the utilities the FHS liste can be found in /sbin, but there physical place is elsewhere. This does not violate the standard. (The Hurd has a symlink from /usr to /, this way everything is in /bin and /sbin, this doesn't violate the FHS either). i'm no expert on capabilites, but won't their addition null the need for sbin directories? i mean, you could have a uid that can bring up interfaces, but not halt the machine. or even, halt the machine but not alter partition tables. also, i don't know how comitted debian is to using capabilites. either way, 'insmod asbestos_underware'. -- jacob kuntz [EMAIL PROTECTED] [EMAIL PROTECTED] underworld.net/~jake
Re: Intent To Split: netbase
John Goerzen ([EMAIL PROTECTED]) wrote: There is no real reason that all must listen on port 25. while i can't imagine ever justifying having postfix AND exim installed on the same machine, your argument holds true for other things. for instance, it's not uncommon to see a machine that has apache running on 80 for modperl pages, with thttpd or aolserver on 8080 for static content. not to mention what will happen when we see TUX packaged. i guess this argument will have to be decided seperatly for each service that it comes up for. personally, i think the smtpd maintainers would be waisting there time, since you can't specify a port number in an email address. -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Intent To Split: netbase
Clint Adams ([EMAIL PROTECTED]) wrote: No real reason? Only one package can listen in on port 25, and Only one package can listen on port 25 of one IP. It is possible to have multiple packages listening on different ports or different IPs. hadn't thought of that. but once again, is there any benefit to that at all? will the efort required by the maintainers to get this working properly (including reading bug reports) ever balance against the tiny number of people that would use this feature? anyone that has a reason can certianly set this up themselves. -- Jacob Kuntz underworld.net/~jake [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: ITP: gnome-db
gnome-db is more intended to be a replacement for MS Access than for the windows registry. gconf is one of the may attempts to create a centralized configuration system for linux. Wichert Akkerman ([EMAIL PROTECTED]) wrote: Previously Dan White wrote: gnome-db (http://www.gnome.org/gnome-db) is a framework for creating database applications. It provides a common API with pluggable back ends to different database sources as well as various specialized widgets for handling many database tasks. It's also part of gnome office (http://www.gnome.org/gnome-office). This sounds a bit like gconf as well, have you compared them? Wichert. -- / Generally uninteresting signature - ignore at your convenience \ | [EMAIL PROTECTED]http://www.liacs.nl/~wichert/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D | -- (jacob kuntz)[EMAIL PROTECTED],underworld}.net [EMAIL PROTECTED] (megabite systems) think free speech, not free beer. (gnu foundataion)
Re: What's changed in su/bash? bash: fork: Resource temporarily unavailable
is somebody running main(for(;;){fork();})? :)
Oliver Elphick (olly@lfix.co.uk) wrote:
If I su, I then get the message bash: fork: Resource temporarily unavailable
on almost every command I try.
I found that `exec sh' let me do things. So it seems that something has
changed in the set-up of bash or su
--
Oliver Elphick[EMAIL PROTECTED]
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
Trust in the Lord with all your heart and lean not on
your own understanding; in all your ways acknowledge
him, and he will direct your paths. Proverbs 3:5,6
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
(jacob kuntz)[EMAIL PROTECTED],underworld}.net [EMAIL
PROTECTED]
(megabite systems) think free speech, not free beer. (gnu foundataion)
Re: Idea: Debian Developer Information Center
Jordi Mallach ([EMAIL PROTECTED]) wrote: Haha! Pleaase let's call it my.debian.org, *grin*. Now, something like this would be really useful. that's exactly the name i was going to suggest. has the author decided on a language to tame this beast in? if php, i'd love to help. -- (jacob kuntz)[EMAIL PROTECTED],underworld}.net [EMAIL PROTECTED] (megabite systems) think free speech, not free beer. (gnu foundataion)
Re: of bash and ...sbin/
Miles Bader ([EMAIL PROTECTED]) wrote: Jacob Kuntz [EMAIL PROTECTED] writes: i think this tread started with someone wanting the sbin directories in the normal user's path by default. i see your point that moving those binaries would break a lot of scripts. i don't think appending to the default path would break anything. anyone have a problem with that? Do you have a problem putting /sbin:/usr/sbin in your personal path? no, do you have a problem with a more sensible default? if not, then why do you think this isn't a more sensible default? -Miles -- Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come. --Nietzsche -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: of bash and ...sbin/
Steve Greenland ([EMAIL PROTECTED]) wrote: On 22-Mar-00, 15:59 (CST), Jacob Kuntz [EMAIL PROTECTED] wrote: i think this tread started with someone wanting the sbin directories in the normal user's path by default. i see your point that moving those binaries would break a lot of scripts. i don't think appending to the default path would break anything. anyone have a problem with that? We discussed (and argued and flamed and ...) that to death. The objection is mostly due to potential confusion (there are a lot more potential targets for command completion, and most of them are *not* what the user is looking for) and inertia, and the expectation that a user who finds value in use of traceroute or ifconfig or whatever is also a user who is capable of modifying their path. finnally! a valid argument! i submit. sg -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: of bash and ...sbin/
Chad Miller ([EMAIL PROTECTED]) wrote: I like that debian's bash package has different paths for users and the superuser, but it's caused me to question ideas behind the placement of some programs in 'sbin' directories. For instance, a program joeuser uses often is 'traceroute' (which is in /usr/sbin). Other (questionable) ones might be /usr/sbin/fbset or /usr/sbin/lpc . not to mention ifconfig! having these utils in the non-root path is hardly a security risk. if anything, this is just to keep down helpdesk calls like what does MAKEDEV do? personally, since many of these commands print out usefull, non-security-risking data, i don't see any good reason to keep em out. Which is wrong? Is it bash' assumption that only the superuser executes stuff in sbin, or that these programs should be in sbin? Essentially, by question boils down to To which packages should I apply a bug report -- bash or the others? This discussion might belong in debian-policy, depending on your answer. - chad ref'd... traceroute-nanog: /usr/sbin/traceroute lprng: /usr/sbin/lpc fbset: /usr/sbin/fbset -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: of bash and ...sbin/
Ben Collins ([EMAIL PROTECTED]) wrote: As policy states, things that pertain to system administration (and traceroute is for troubleshooting networks) is to be in /sbin or /usr/sbin. The difference between /sbin and /usr/sbin is that things that could be needed to rescue a broken system should be in /sbin (things like fsck). at the risk of reigniting a flame war, how is traceroute in a different catagory that ping? -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: of bash and ...sbin/
Chad Miller ([EMAIL PROTECTED]) wrote: OTOH, i would leave ifconfig in /sbin, as it _is_ about this system, and it doesn't provide (much) information that DNS doesn't, unless there's sysadminning to be done. (There's also a huge amount of inertia that it be in /sbin/ .) inertia aside, i use ifconfig to see if i'm dialup, and if my pcmcia card made it in. lots of programs will provide usefull information without being root. (Don't reply without including the below, to help kill this thread!) NOW, having said all of that, the Inertia says leave it be! argument is _very_ compelling, at least for the near term. For woody (or woody+1), moving is likely a Good thing. That's far off, though. Potato must ship. So, sorry to have brought it up, and IAN-even-ADD. I will file no bug reports, until $release+2 . - chad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- (jacob kuntz)[EMAIL PROTECTED],underworld}.net [EMAIL PROTECTED] (megabite systems) think free speech, not free beer. (gnu foundataion)
Re: of bash and ...sbin/
Robert Bihlmeyer ([EMAIL PROTECTED]) wrote: Dylan Paul Thurston [EMAIL PROTECTED] writes: On Wed, Mar 22, 2000 at 11:52:37AM -0500, Jacob Kuntz wrote: at the risk of reigniting a flame war, how is traceroute in a different catagory that ping? traceroute is deeper than ping. It exposes things that the casual user neither sees nor cares about. Ping only measures what everybody experiences anyway: how responsive is a particular host? and that changes something? one cannot assume that because someone is not logged in as root, they are a casual user. that mindset breaks with much of the way debian works. the install highly encourages you to create a normal user account. saying that traceroute is deeper than ping is like saying that ps is deeper than ls. and since when do we try to hide problems, in the network or otherwise? One has to draw a boundary, and on GNU systems it runs between ping and traceroute. Others do it differnently, AFAIR AIX has both in sbin. Or mtr, for that matter? That should go into sbin. I filed a wishlist item. that will only encourage people to run things as root. this is *not* a good idea. -- Robbe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- (jacob kuntz)[EMAIL PROTECTED],underworld}.net [EMAIL PROTECTED] (megabite systems) think free speech, not free beer. (gnu foundataion)
Re: of bash and ...sbin/
Craig Sanders ([EMAIL PROTECTED]) wrote: in short, add the sbin directories to your PATH and move on. hey, i no more want to participate in a flamewar than the next guy. :-) i think this tread started with someone wanting the sbin directories in the normal user's path by default. i see your point that moving those binaries would break a lot of scripts. i don't think appending to the default path would break anything. anyone have a problem with that? -- (jacob kuntz)[EMAIL PROTECTED],underworld}.net [EMAIL PROTECTED] (megabite systems) think free speech, not free beer. (gnu foundataion)
Re: Bug#60399: crashes on installation
Daniel Martin ([EMAIL PROTECTED]) wrote: I seem to remember once upon a time that man would crash and burn if one somehow had a corrupt index.bt file. Could it be that a partially completed install produces such a corrupt file (i.e. could it be that whatever mandb does in the background is rebuilding this, and being only half-way done means the resulting file seems corrupt), and that an existing but corrupt index file causes havoc? this would be unlikely. on all three of the machines i experienced this bug on, man-db had never been installed before. completely virgin systems. i tend to lean toward the idea that this is a kernel bug. i seem to remember something on kernel traffic (kt.linuxcare.com) about a very rare bug that rears it's ugly head with dpkg. can't find it now. then again, i guess that's about as likely as solar flares... anyone have any other guesses? -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: Bug#60753: mutt: /etc/Muttrc should not use colors
Hamish Moffatt ([EMAIL PROTECTED]) wrote:
Personally I can't stand Mutt's default colours (green on blue? ugh!)
but the default keybinds are fine. I have a .muttrc which I copy
around between all my accounts.
i bet most people do. probably a .bash{rc,_profile} and .joerc too. that's
why everything stores globals and per-user settings seperatly. i can't
believe anyone even suggested that the system wide defaults be changed to
suit one user's preferences. i'd have to say that the system Muttrc is
pretty damn ugly tho. my .muttrc changes only a few settings besides color.
--
(jacob kuntz)[EMAIL PROTECTED],underworld}.net [EMAIL
PROTECTED]
(megabite systems) think free speech, not free beer. (gnu foundataion)
Re: aptitude
Robert Ramiega ([EMAIL PROTECTED]) wrote: I must have missed it... Anyway it needs dpkg.h and i cant find it on my system... Searcher on Debian Web site can't find it either =o(( it's in dpkg-dev. -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: aptitude
Fabien Ninoles ([EMAIL PROTECTED]) wrote: On Sat, Mar 18, 2000 at 08:35:52PM +0100, Robert Ramiega wrote: On Wed, Mar 15, 2000 at 07:23:50AM -0500, Fabien Ninoles wrote: I tried to find it on download.stormix.com but failed It's in ftp://download.stormix.com:/storm/dists/rain/main/source/ I must have missed it... Anyway it needs dpkg.h and i cant find it on my system... Searcher on Debian Web site can't find it either =o(( dpkg.h is in the dpkg source, I think. Ian doesn't want to export the functionnalities of dpkg into a librarie since he couldn't change the interface then. my mistake! sorry for the confusion. -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: Bug#60399: crashes on installation
i experienced this bug on two seperate systems, both fresh installs of potato from the netboot test cd on cdimage.debian.org. one a k6/266 and the other a k6-2/350. i remember at least one other person reporting the same bug on this list the morning after i noticed it. ben, any way we could get dpkg-deb to print the signal that killed it's child? Ben Collins ([EMAIL PROTECTED]) wrote: On Fri, Mar 17, 2000 at 05:47:16PM +0200, Fabrizio Polacco wrote: [can anybody with knowledgs of the internals of dpkg/apt take a look at this?] Unpacking replacement man-db ... dpkg-deb: subprocess paste killed by signal (Broken pipe) dpkg: error processing /var/cache/apt/archives/man-db_2.3.14_i386.deb (--unpack): subprocess dpkg-deb --fsys-tarfile returned error exit status 2 Building manual page index in background. Errors were encountered while processing: /var/cache/apt/archives/man-db_2.3.14_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) This looks like a system problem. Looks like gzip is getting killed (the Broken Pipe). What kernel is this person running? -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: Bug#60399: crashes on installation
Ben Collins ([EMAIL PROTECTED]) wrote: try running: dpkg-deb --extract man.deb /tmp/tmpdir If that fails too, then add strace -o dpkg-deb.out to the start of that line and send me the dpkg-deb.out file. i don't have a 'broken' archive any longer, but i did try dpkg --fsystarfile (or whatever it was that was failing) and the tarball unrolled fine. -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: A progressive distribution
i have seen a lot of discussion about a distribution half way between stable and unstable. on the surface that sounds like exactly what we need, but at least one person pointed out that this is not the way to manage a project with hundreds of developers working against hundreds of seperate releases cycles. i wish i could remember who said that first, you really hit the nail on the head. the deadline-based release cycle may work great for commercial projects, but quite possibly not for projects like Debian. i think we need something a little more organic. try this hypothetical release method out: there are two trees. let's call them devel and production. debian saavy folks (maintainers) run devel. new packages are uploaded to devel where they are tested extensivly. when a package has been in devel for more than (for instance) two weeks, and it has no release critical and few important bugs, it graduates into production. the production branch should always work. a system could be put in place where you could always get an iso image of the production branch that is recent to within a few days. i imagine that we would need to get pools in place before we could even attempt this. this type of system could probably work along side of whatever else we decide to to about release cycles. -- (jacob kuntz)[EMAIL PROTECTED],underworld}.net [EMAIL PROTECTED] (megabite systems) think free speech, not free beer. (gnu foundataion)
Re: Danger Will Robinson! Danger!
Ari Makela ([EMAIL PROTECTED]) wrote: Filip Van Raemdonck writes: And if they have this new hardware, does it mean they should not be able to run Debian then? If that's the case, better start rewriting some documentation... What I ment was that it's quite easy to upgrade Slink to use 2.2 series kernel or newer XFree86. Neither it's difficult to change the kernel on the rescue floppy if the provided kernel does not support hardware. If, Samba, for example, is not new enough, it's not difficult to fetch the sources and compile it. Somehow, I fail to notice a major problem here. you obviously don't manage a large group of servers. one of the reasons a lot of people run linux these days is because you can build huge server farms without paying huge license fees. people like debian because it is so easy to manage. compiling the new samba because it offers functionality and stability you just can't get out of stock is neccicary. the same is true for debian's php, snmp, apache, and mysql packages. i imagine those are some of the most commonly installed packages today, and i had to build them for a dozen machines because stable was too far behind. -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: Danger Will Robinson! Danger!
Steve Greenland ([EMAIL PROTECTED]) wrote: Let's see, we're going to release potato (I *hope*) before kernel 2.4.0 is released, but we're outdated. Hmmm. Somehow, I just don't get it. what that means is that we've almost totally missed the 2.2 kernel. we're an entire release cycle behind. there's a plethora of hardware and features that we just flat out can't do with our 'stable' distribtion. people will be expecting to see the 2.4 kernel when we finally release potato. for a brief list of the things a stable installation debian can't do, see: http://www.kernelnotes.org/wonderful22.html Wonderfull world of 2.2 http://www.kernelnotes.org/whatsnew22.html What's new in 2.2 http://www.kernelnotes.org/change23.html2.3.x Changelog i don't really expect to see 2.4 in potato. i do however hope that it won't be another year before we see people giving out Debian 2.4 CDs at the LUG meetings. -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: Danger Will Robinson! Danger!
Alisdair McDiarmid ([EMAIL PROTECTED]) wrote: What's the point in providing a briefly tested package of 2.4.0 when, by the time potato is out and burnt onto CDs, 2.4.x (where x 0) will be available and people can compile their own kernel? The only reason for putting a 2.4.x kernel into potato is if you can easily put the infrastructure needed for 2.4.x into the Debian system. Supplying a pre-compiled kernel alone is pointless. i see your point but have a counterpoint ;) it is not unlikely for someone to be in a situation where they need a feature from a 2.4 series kernel to get a machine fully installed (network or storage device problems most likely). the only (easy) way for this user to continue is to install the pre2.4 image we will hopefully include and use that to complete the installation. of course they won't keep that kernel for long, but it will be enough to bootstrap. a friend of mine was in a similar situation with the slink cd. -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: Danger Will Robinson! Danger!
Hamish Moffatt ([EMAIL PROTECTED]) wrote: On Sat, Mar 11, 2000 at 04:06:01PM -0500, Jacob Kuntz wrote: our biggest handicap is that we're always a year behind everyone else. being a year behind is suicide in any industry. being a year behind in an industry Have you listened to yourself? Depends on what your aims are; if you want to be hip, cool, most popular etc then I guess 'new' is a higher priority than 'stable'. Otherwise, let's stick with the proven 2.2 series. aarrgghh. you are missing the point. what i'm trying to get across here is that we aren't keeping up with what's going on in the rest of the world. linux and other free software projects are rapidly becoming something very good. in order to facilitate and encourage this, we distribution coordinators need to pull not neccicarily the latest but certianly the greatest free software together in a usefull, functional way. the issue at hand here is not the kernel. the issue is the release practice. i think there should be an initiative to bring out stable releases more often. if we don't, it will be just another excuse to use commercial software. i don't think any of us want that. on the other hand, bringing out any software package prematurly will also discourage use of free software. i was really hoping the we could get past the knee-jerk reactionary comments like hell no, we won't put in an untested kernel and get on with here's how we could make more stable releases. i see no problem at all with waiting for 2.4.10 (or so) before shoving that in the users lap. just so long as we do get it in before it too is obsolete. Hamish -- Hamish Moffatt VK3SB. CCs of replies on mailing lists are welcome. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: Danger Will Robinson! Danger!
Stefan Ott ([EMAIL PROTECTED]) wrote: i still don't see why compiling a kernel on your own is a problem. i have never used a precompiled kernel, and i never had problems. well, if you want to stay on the topic of which kernel to include, there's something you must understand. there are numerous differences between different releases of the kernel and what they expect from the rest of the system. with 2.2, we needed to provide ipchains instead of ipfwctl. with 2.4, there will be certianly be some work involved with the migration to devfs. i believe there are some framebuffer and firewall changes that will have to be addressed. the kernel that we shipped with slink didn't boot on athlon at all. that made it very hard to install on a lot of computers. it's not so much what kernel we include but which one we can say we support. -- (jacob kuntz)[EMAIL PROTECTED],underworld}.net [EMAIL PROTECTED] (megabite systems) think free speech, not free beer. (gnu foundataion)
Re: Danger Will Robinson! Danger!
our biggest handicap is that we're always a year behind everyone else. being a year behind is suicide in any industry. being a year behind in an industry that moves as fast as open source software, is idiocy. our stable release is using 2.0.36. most people are afraid of our 'unstable' tree. you've seen all the threads about people trying to upgrade from slink to potato and having all sorts of problems. why do they do it? because slink is so far behind that it isn't usefull anymore. IMHO, leaving out 2.4 is a bad idea. there were problems with 2.0 - 2.2. there was an incompatible build of lsof, as well as some networking problems. i feel the same way about xf86 4.0 and apache 2.0. all of these releases are going to generate a lot of press, not to mention the fact that these are very usefull products. yeah, it will be a lot of work. building a good distribution *is* a lot of work. this thread brings up an interesting topic: how can we keep up? the debian project is huge. no one is going to contest that it could be difficult to pump out a stable release of this size every 3 months. or any interval for that matter. but something really does have to be done, or debian will fall into laughability. i think i have the beginning of a good idea. please flame/comment as you see fit. make a release every 3 months with an official cd image, fanfair on the website, the whole shebang. only include enough on the cd to do a basic install. only consider 'release critical' bugs release critical if they're against required base pacakges. the rest of the distribution would remain on the archive sites. with this pattern, we produce four releases per year. three interim releases (2.3, 2.4, 2.5) and one major release (3.0). in order to figure out what packages to include on the interim release, we probably should get statistics on what most people use. perhaps analize logs from the archive sites, and encourage more people to use popularity-contest.deb. what do you folks think? Ben Collins ([EMAIL PROTECTED]) wrote: On Sat, Mar 11, 2000 at 01:57:49PM -0500, SCOTT FENTON wrote: OK, Linus has just put out 2.3.51, the next patch will be a pre-2.4 one. To avoid the problems we've had with slink not being 2.2, I reccomend that, even if it's not the default, we include a 2.4 /binary/ in potato. You could even put a note in the potato release notes saying you don't reccomend putting it on, but please /please/ PLEASE put potato out with a 2.4, or even pre-2.4 binary. What problems have we have with slink not being 2.2? I don't see any. In fact, I protest profusely, since 2.4 will require a great deal of work to work out the pcmcia kinks. There is nothing wrong with 2.2. What I want is 2.2.15 in potato, nothing more. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- (jacob kuntz)[EMAIL PROTECTED],underworld}.net [EMAIL PROTECTED] (megabite systems) think free speech, not free beer. (gnu foundataion)
Re: Danger Will Robinson! Danger!
Marcus Brinkmann ([EMAIL PROTECTED]) wrote: On Sat, Mar 11, 2000 at 04:06:01PM -0500, Jacob Kuntz wrote: our biggest handicap is that we're always a year behind everyone else. being a year behind is suicide in any industry. The simple fact you are missing is that Debian is not an industry. Don't make the same mistakes as the industry. Making last minute changes and rushing in x.0 versions of critical software is just Plain Wrong. Especially the Linux kernels are often very unstable 'til x.12 or 14. i'm fully cogniscient of the fact that debian is not an industry. but it is used in the industry. i use it in the industry. i reccomend debian to all my clients and friends. debian is also representational of linux and free software. we have a responsibility to our ideals. Everytime a new version of the kernel is released the same story. Sigh. i don't really feel that this issue pertains specifically to the kernel, or X, or apache. it has much more to do with the fact that our release practice makes it impossible to have Good Software Now. we spend all of our time fixing bugs in our pre-packaged software while the upsteam folks make the software we packaged better. we end up with sub-standard software that installs very well. i believe we have a responsibility to our users and eachother to release more often. i'm asking for comments and ideas on how to make this work. yes, we do have to test the kernel. that's true of everything we package. but i don't want it to be another 12 months before debian ships with what the rest of the community considers a standard kernel. i want to use the new features of the kernel as soon as they are ready. i want provide fast, dynamic websites on SMP servers. i want to have a better looking desktop than the NT guys. i want to help prove that free software can do all of these things and that you don't have to be a huge corporation (or inflated IPO) to make it happen. Thanks, Marcus thankyou. -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- (jacob kuntz)[EMAIL PROTECTED],underworld}.net [EMAIL PROTECTED] (megabite systems) think free speech, not free beer. (gnu foundataion)
Re: better RSYNC mirroring , for .debs and others
you're quite right. why are we using rsync anyway? in it's current state it's a waste of resources except for block-oriented files like cdimages. wouldn't it make more sense to use something like mirror or wget untill debdiff matures? are mirror admins required to use rsync? another tought: would it be possible to impliment an alternative Packages.gz that works more like a database? ie, fixed length fields, etc? that would make rsync noticeably more effective. Tom Rothamel ([EMAIL PROTECTED]) wrote: 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.) -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: Packages to remove from frozen
isn't the problem here that the server is misrepresenting itself? a one bit difference may not make a less secure key, but it could quite possibly be an indication of some deception. i worry that altering the client to ignore this type of error will only open us up to attack, be it man-in-the-middle or otherwise. Ben Armstrong ([EMAIL PROTECTED]) wrote: On Thu, 9 Mar 2000, Junichi Uekawa wrote: Isn't it that to decrypt 1024 key takes double the amount of CPU time than decrypting 1023 key, as long as there is no other method than brute-force method of trying every combination. IMO It is a serious security issue, when the system is half as secure and one is not notified. And the person is trying to use a ssh. Where 'n' is a reasonable amount of time to crack a key using brute-force, doubling 'n' does not equate to doubling the security of your system. At the most, you have caused the cracker the minor annoyance of having to wait twice as long for a result. Conversely, if '2n' is an unreasonable amount of time to crack a key using brute-force, halving it to 'n' does not equate to halving the security of your system. In other words, I rely on my ssh keys being several orders of magnitude more difficult to crack than weaker crypto that is crackable in a reasonable amount of time by brute force. Whether the keys are 1023 bit or 1024 bit is irrelevant. Both accomplish this goal. Ben -- nSLUG http://www.nslug.ns.ca [EMAIL PROTECTED] Debian http://www.debian.org [EMAIL PROTECTED] [ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ] [ gpg key fingerprint = 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems) think free speech, not free beer.
Re: better RSYNC mirroring , for .debs and others
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. i like the idea of rsync modules, but the concept you project misses is that even a small addition or subtraction in the beginning of a file ruins rsync's speed bonus because it then has to send everything. take a look at tom's code. i think you'll find it interesting. Andrea Mennucc1 ([EMAIL PROTECTED]) wrote: hi everybody I have implemented a good idea for reducing download stress for everybody who is mirroring a lot of data using rsync, like, the people who are mirroring Debian GNU/Linux: currently, many Debian leaf mirrors are using rsync for mirroring from the main .debian.org hosts. rsync contains a wonderful algorithm to speedup downloads when mirroring files which have only minor differences; only problem is, this algorithm is ALMOST NEVER used when mirroring a debian repository ... indeed, whenever a new version of a package is entered in the debianrepository, this package has a different name: for this reason rsync does just a full download. Summarizing, rsync currently does some speedup only when it downloads Packages.gz files, or when it skips an already existing package. well, I have just implemented a simple way to use the algorithm even when downloading the .debs . here is a simple example suppose the current situation is $REMOTE::/pub/debian/dist/bin/dpkg_2.deb whereas locally we have /debian/dist/bin/dpkg_1.deb when rsync looks for a local version of /debian/dist/bin/dpkg_2.deb if there is none, then rsync does ls -t /debian/dist/bin/dpkg_* and looks for the most recent file it finds this way, rsync will use the file /debian/dist/bin/dpkg_1.deb to try to speedup the download of$REMOTE::/pub/debian/dist/bin/dpkg_2.deb (using its fabulous algorithm) BIG PRO: my new rsync is totally compatible with the old one Conclusion: this idea would make all debian mirror-people happier (specially if they mirror unstable; consider that, often, when a new version of a package is released, only small changes are made... sometimes, only the .postinst , or such, are really changed; this may , thou, masked by the compression, alas: but, see TODO) I attach two files: the first file is a diff, showing where, in the rsync 2.4.1 source code tree, I have done some modifications; the second is a .tgz of the all the new and modified files you need to build the new rsync: to build, first you need to download the source code (see rsync.samba.org/rsync/download.html) and then you unpack the file rsync.diffsrc.tgz in the tree code, and build. You may also get the compiled binary directly as ftp://tonelli.sns.it/pub/rsync/rsync and the new code alltogether in ftp://tonelli.sns.it/pub/rsync TODO: there are some potentially good ideas here: 1) the idea is to add modules to rsync: a gzip module, a deb module, and rpm module...; currently, modules just look for an older local version of the file; in a future version, any module would apply to a certain type of file, and create another file to pass to rsync so that this another file may probably lead to more speedup: e.g., the gzip module would unzip files before doing comparisons, and the deb module would unzip the data.tar.gz part of a package CONS: this would not be backward compatible, of course The idea is, a module may provide the following calls: find_alternative_version_MOD() receive_file_MOD() send_file_MOD() Currently, only find_alternative_version_deb() was implemented. If rsync uses only the find_alternative_version_MOD() calls, then it is backward compatible with the usual version: (in a sense , it is doing what the option --compare-dest already does, only in a smarter way) I have not currently implemented anyreceive_file_MOD() send_file_MOD() : these would need a change in the protocol: I hope that the rsync authors will give permission 1b) My idea (not sure) is that rsync may work if provided with named pipes instead of files: indeed, according to the technical report, it needs to read the local and remote files only once, and then, it writes the local file, without ever seeking backwards; then, the above modules would not need to actually use disk space and create temporary files. 2) for a faster apt-get downloading, it may be possible to do the same trick WHEN UPGRADING INSTALLED PACKAGES! Here is the idea: apt-get creates a local version of the package (using dpkg-repack) and do the rsync to get the remote version -- Andrea C. Mennucci, Scuola Normale Superiore, Pisa, Italy -- (jacob kuntz)[EMAIL PROTECTED] [EMAIL PROTECTED],underworld}.net (megabite systems
