RFC: Deb 2.0 testing process
Hello everyone, The testers are starting to think about how to organized the 2.0 testing effort. One idea that the testers seemed to like is to create a checklist for checking each package. Before we just checked to see if the packages installed and if the entire system seemed to work correctly. This time we plan on being a bit more thurough, but it will require a bit of help from the developers. What I would like to do is keep a list of checklist for all the packages in a format similar to the packages.gz file. I'd like to create the initial checklist from what the maintainers advice. I don't expect it to be complicated, e.g. Package: xbiff (assuming there is a package for this single binary) Checklist: - by default it checks the users mailbox - switches display, geometry, file, update, volume, bg, fg, rv, and shape work This list can be added to by anyone. What I'd like to ask for now is any comments on this. Please do NOT send any checklist at this time. After a few weeks, I'll post a request for the list, and inform everyone of the final decision. Thanks, Brandon ----- Brandon Mitchell <[EMAIL PROTECTED]> "We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds" Phone: (757) 221-4847 --Linus Trovalds -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Future security problem (was Re: be careful with Replaces, please)
> > Greg Stark writes: > > > We've got be be a little more careful with the Replaces header. I just > > > installed the libc6 version of comerr, and dpkg helpfully deinstalled > > > e2fsprogs. I can see a security problem with this. Lets jump ahead several months when we have deity working. A user points deity to several sites, some providing a bunch of debs that they have created but don't want to be part of the main distribution. Now they upload a new package, call it libc6- that replaces all kinds of packages, and whatever else they want to do. Most of you will dismiss this as "they deserved what they got" at this point, but I think we should start worrying about these possibilities. How about prompting the user before deleting a package because it was replaced (of course we need to think about non-interactive installations too). I'd also be interested in some kind of verification, so I can accept all packages put together by some maintainer, and the maintainers on the debian keyring, but no one else. We have time to think about this, but the sooner the better in my opinion. Thanks, Brandon - Brandon Mitchell <[EMAIL PROTECTED]> "We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds" Phone: (757) 221-4847 --Linus Trovalds -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Future security problem (was Re: be careful with Replaces, please)
On Mon, 1 Dec 1997, Marcelo E. Magallon wrote: > Am I the only one seeing a bit of a problem here? (Or am I missing > something I should know?) That is, PGP is non-US. To be able to put PGP > in the main distribution, the master FTP site has to be moved off the US. > I don't have a problem with that, as I don't live in the US, but I > understand this can be quite an annoyance for many people. We can make it optional. Or just make a version of pgp that always succeeds and prints a warning that it really isn't pgp and that the package has not been checked. The idea is to allow those that can and want to be more secure that ability. Brandon - Brandon Mitchell <[EMAIL PROTECTED]> "We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds" Phone: (757) 221-4847 --Linus Torvalds -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Deb 2.0 testing process
On 5 Dec 1997, Karl M. Hegbloom wrote: > Well, I guess just a checklist outlining things from the policy guide > is what I had in mind. Like whether it follows the FSSTND or FHS, > there's a copyright statement, compressed man page, menu file with > the dwww link and a menu item for X (with semi mandatory icon) if > appropriate. Ok, I see what you mean now. I was thinking of putting things like this into a generic checklist for all packages. > Hmm. You seem to be suggesting that the package maintianer submit a > checklist for other testers to use? To ensure that it works > elswhere, not just on the build machine. For that, the standard > checklist, then package specific ones I suppose. Yes, the package maintainer submits the initial checklist since they should know the most about each package. Then the maintainer, testers, or anyone for that matter, has the option of adding to the checklist. The reasoning behind this is to make sure the package works on fresh installs, upgraded installs, and doesn't have any problems when other packages are installed. A few examples: - nedit maintainer mentions nc but the tester gets netcat. - config on a fresh install is different that an upgrade, like the X11 library problem we had a while back. - rplayer may work fine on maintainers system if they have the latest bash, but the tester may have an older version and have problems with netscape. These are all old problems that theoretically could be caught with testing. The idea being, what works on a maintainers system may not work everywhere. For the initial list, I'll probably have them all sent to me. But once we get into the swing of things, I'll ask that they submit them to the testing group so if a tester has an addition to the list, it's easy to start a discussion. Also I may not maintain this forever, and I don't feel like asking for an account on master for the checklist maintainer. > I'll watch and see what some more experienced people have to say. I'm hoping to get more opinions before I start doing this. Fixing any problems now is much easier than if we wait until half of the maintainers have already submitted list. Thanks for your comments, Brandon - Brandon Mitchell <[EMAIL PROTECTED]> "We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds" Phone: (757) 221-4847 --Linus Torvalds -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: random numbers
On Sat, 6 Dec 1997, G John Lapeyre wrote: > What are the considerations for choosing a system random number > generator? What if debian were the first unix to have a good random > number generator ? (is there another?) At least I should upload GPL'd > versions of the good generators (there is not much code) for people that > need them . First, does it pass a basic statistical analysis? e.g. mean, standard deviation, probability of individual number all correct, no patterns, and probably a bunch of other things I never learned about. I'm working on a final for a course that spent a large amount of time on a random generator. What were you testing? How long it took to generate a bunch of numbers? I had a hard time figuring out what you meant by worse performance. Brandon - Brandon Mitchell <[EMAIL PROTECTED]> "We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds" Phone: (757) 221-4847 --Linus Torvalds -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: pentium specific packages
On Sun, 7 Dec 1997, Adrian Bridgett wrote: > Now that ecgs has ben officially released, maybe it's time to think (again) > about pentium/pro/K6/... specific packages. I think it would be good to have > a section i586 which would contain pentium specific packages. I don't know > how this conflict with the current dpkg* tools (such as dselect). I know > that we could release packages like gzip-i586 (provides gzip). However this > is far from an ideal solution. How about a binary-pent directory with symlinks back to binary-i386 until a package is uploaded. Then we need to tell dselect(ftp) to get the packages from binary-pent instead of binary-i386. Is there an easy way to do this? (Also, if pentium clones also work with the ecgs compiled packages, maybe i586 is better than pent.) Thanks, Brandon - Brandon Mitchell <[EMAIL PROTECTED]> "We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds" Phone: (757) 221-4847 --Linus Torvalds -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: pentium specific packages
On Sun, 7 Dec 1997, Andreas Jellinghaus wrote: > > How about a binary-pent directory with symlinks back to binary-i386 until > > a package is uploaded. Then we need to tell dselect(ftp) to get the > > packages from binary-pent instead of binary-i386. Is there an easy way to > > do this? (Also, if pentium clones also work with the ecgs compiled > > packages, maybe i586 is better than pent.) > > please : no symlinks to something. > we have good tools (dselect, dftp), that can take care of the directory > structures. symlinks only make everything bigger and confuse people. > symlinks are convinient, but using dselect, dftp, deity or some other > tool can be more convinient. and all these can or could work without symlinks, > as the file location is listed in the Package file. Andreas, Can you compare: debian/dists/unstable/hamm/binary/admin/ debian/dists/unstable/hamm/binary-all/admin/ and explain how we should get rid of the symlinks in binary (which is itself a symlink to i386)? I'm basically proposing another platform which is backward compatable. Therefore, make the directory for the platform, and while we don't have a package of the new type, use the old type. However, I still haven't heard about the possibility of getting dselect's ftp to look at binary-pent or at the compatability of pentium clones. If we put everything in the same directory with different provides, etc, I feel like things will get really confusing, and defeating the purpose of having different directories for different architectures. Brandon - Brandon Mitchell <[EMAIL PROTECTED]> "We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds" Phone: (757) 221-4847 --Linus Torvalds -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: pentium specific packages
On Mon, 8 Dec 1997, Adrian Bridgett wrote: > On Sun, Dec 07, 1997 at 06:20:27PM -0600, Marcelo E. Magallon wrote: > > > it's the obvious way... create another architecture tree, binary-i586 > > (gosh, that going to hit hard on the mirror eventually. Time to get yet > > another harddisk for the Debian mirror ;) It's just a minor (I hope) > > modification to dpkg: > > I agree with Andreas that symlinks are unnecessary. We really need a way of > keeping the control file the same (apart from Architecture:) and telling > dpkg to take packages from the binary-i586 directory if they exist. I don't > know the internals of dpkg/dselect/deity at all - how workable is this? Adrian, could you respond to my follow up to Andreas's post: http://www.debian.org/Lists-Archives/debian-devel-9712/msg00354.html I feel I made myself a little clearer on the symlink idea in this post. The problem with yours is that you are suggesting a fairly large overhaul of dselect's ftp method (dpkg doesn't do the ftping), when it could be a simple 1 line change from binary-i386 to binary-i586. I admit the symlink solution is ugly, but it requires the smallest development time (considering the ammount of time we need to spend on libc6, this is a good thing) and has the smallest effects on the end user (from the choices I've seen at least). A good time to do this right will be with deity, but that will be a while. And the conversion from what I'm suggesting now to a deity way will probably be painless, remove the symlinks, point deity to binary-i586 first and have binary-i386 as the second choice. Thanks, Brandon - Brandon Mitchell <[EMAIL PROTECTED]> "We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds" Phone: (757) 221-4847 --Linus Torvalds -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Checklist request (was: RFC: Deb 2.0 testing process)
[ the orig. message is avail at: http://www.debian.org/Lists-Archives/debian-devel-9711/msg01597.html ] Hi everyone, I haven't heard many responses about the checklist, so I think it's time to get started. I'd like to do this in several phases: I. Get a few required packages for comments so everyone knows what's going on. II. Get all required packages. III. Get all important packages. IV. Get all standard packages. V. Get all optional and extra packages. Now, to start with I., I'd like to pick a few packages and ask the maintainers to post what they think would be a good checklist for their package. There are no wrong answers, just what you think you and a tester should do to verify your package is working correctly. The idea being "what works for a maintainer may not work on a testers system for some reason or another". What I'd like to try to get is a good balance between simplicity and thoroughness. For example, with the diff package: Package: diff - cmp works on identical and different binary or text files - diff works on files, directories, normal or 2 column - sdiff correctly merges two files - diff3 correctly compares 3 files Diff is probably one of the easier packages. There weren't many programs, and there isn't too much to test for each program (although I'd be interested to see what changes the maintainer of this package will make). At this time, I'd like to ask for the maintainers of the following packages to post a list (I'm just trying to get several important packages here): adduser, diff, dpkg, grep, gzip, hostname, login, mount, passwd, tar. Also, if anyone wants to go through the packaging manual, I'd like to create some checklist for groups of packages. E.g. a web server checklist. Also a checklist that applies to all packages should be made (e.g. almost all files should be readable by everyone and in locations required by the standard). The first entry of a web server will then say it should pass the general web server checklist. Thanks, Brandon - Brandon Mitchell <[EMAIL PROTECTED]> "We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds" Phone: (757) 221-4847 --Linus Torvalds -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Debian needs guinea pigs
Do you have a little spare time? Do you have some extra hard drive space? Do you enjoy being the first to try something new? Do you want to be on a low volume mailing list (compared to debian-user)? Do you want to help debian become the most popular linux distribution? Do you want women to adore you? (ok, maybe we can't do this) If you answered yes to zero or more of the above, you're a perfect candidate to join the Debian Testing Group! We're looking for a few good guinea pigs in preparation of the Debian 2.0 release. Basically, we install as many times as possible (although one is more than enough), making sure all the programs work. If you are interested in joining, send me a short message detailing what you can do, and in a few days, you'll be added to our mailing list. New users are welcome! I've included a more detailed description of our testing process below to give you an idea of how this works. Brandon - Brandon Mitchell <[EMAIL PROTECTED]> "We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds" Phone: (757) 221-4847 --Linus Torvalds DEBIAN TESTING GROUP PROCESS The following document summarizes the methods used by the Debian Testing Group. Testing is primarily focused around the time when the distribution is "Frozen" before a release, but test reports are welcomed at any time either before the freeze or after it. All reports should be posted to: "debian-testing@lists.debian.org", while all bugs should be reported according to: "http://www.debian.org/Bugs";. I. Upgrade Install Testing The first type of testing to occur during this period is upgrade testing. The tester should attempt to point dselect from an older installation to a Debian mirror. Any error messages during the installation should be reported along with any work-arounds. Once the upgrade is complete, as many individual packages should be tested as possible (see section III). II. Base Install Testing The second type of testing involves an installation from scratch. This will usually involve creating the rescue, root, and base disk (or any of the other options, including the zero floppy install). Once this is complete, the tester should attempt to install any desired packages and then test as many individual packages as possible (see section III). III. Individual Package Testing A list of packages and their checklist will be kept in one large file. This should be kept at "http://bhmit1.home.ml.org/deb/checklist.html";. If you find a package that fails an item in the checklist, please report it as a bug. Once you have verified that all test have passed, you can report the package as being tested. If you are only able to test some of the items in the checklist, you may report this too, but specify what you have tested. The checklist will initially be created by the maintainer. However, anyone is free to add to or modify a checklist by sending e-mail to the testers mailing list or "[EMAIL PROTECTED]". Note that there will also be a checklist for all packages, and a checklist for groups of packages. If the package belongs to a group, this will be an item in it's list. During a testing period, a list of untested packages will periodically be posted to the testing list. Copies will also be sent to debian-devel (less frequently) so that any developers can assist in the testing process. IV. Testing Report Comments are placed in [ ]. This report is an example only. Report Information: Name: Brandon Mitchell <[EMAIL PROTECTED]> Date: December 8, 1997 Target: 2.0 (ftp.debian.org) Source: 1.3 [ or base install / package testing ] Method: dselect - ftp [ or base disk, zero floppy ] Machine Information: [ note, I'm trying not post unimportant info. ] Platform: Pentium 90 Memory: 16 Megs Cd rom: ide SCSI: aha152x Network: ne2000 Modem:33.6 Hayes compat Sound:SB 16 Video:Stealth 64 (1 meg) General Installation Notes / Error List: [ not needed for package only reports. ] Libc5-libc6 HOWTO worked without a problem. Successful Package List: bash sendmail pine pico Failed Packages List (bug reports filed for below packages): [ again note, this is fictional. ] apsfilter failed install, caught in infinite loop bc option -l failed wuftp did not limit after 10 connections -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Checklist request (was: RFC: Deb 2.0 testing process)
On Wed, 10 Dec 1997, Philip Hands wrote: > > For example, with the diff package: > > > > Package: diff > > - cmp works on identical and different binary or text files > > - diff works on files, directories, normal or 2 column > > - sdiff correctly merges two files > > - diff3 correctly compares 3 files > > It seems a shame to have to ask people to do this sort of thing. > > It strikes me that one should be able to come up with a script that does a > test of this sort in not much more that the time required to write the list > (in > this simple case at least ;-) This is the second time I've heard this, and it is a valid point. The reason I don't fully back it is a tester using their own test may catch some case the package designer never thought of. How about this, a maintainer can make a script, called /usr/doc//testme.sh. It can run any test the maintainer wants to do. In the checklist, the maintainer writes that the script is available, and test for the below things... This way, the testers can add their own things to the checklist even if the maintainer disagrees. This aproach favors more testing than less, since if a maintainer disagrees with a test, it's still in the checklist, and if they want a test not in the list (should be rare if ever), they can put it in their script. Testers will be encouraged to make any modifications to the given script (but not required), and then use their own script. > Another thing is that the tests or checklists that are written, should be > testing for problems that have actually occured in the past. Just because something works in the past doesn't mean it won't fail in the future. It would be nice if we can catch some bugs that haven't happened yet. The bash bugs come to mind (with netscape not running any helper apps). Comments? Brandon -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Checklist request (was: RFC: Deb 2.0 testing process)
On Thu, 11 Dec 1997, Adam P. Harris wrote: > "Philip" == Philip Hands <[EMAIL PROTECTED]> writes: > > It seems a shame to have to ask people to do this sort of thing. > > Yes! Maybe even against policy? [Followups on this to debian-policy, > please.] We are asking, not requiring. If you don't want to make a checklist, the testers _will_, but understand we don't know how half of these packages work, and this also means less time for testing. Why are you against testing packages? If we don't catch it now, a poor user down the road will. They claim Debian is a piece of junk, and move on to a better distribution like Red Hat. > I applaud the ambitiousness of making test suites for debian core > packages, but I wonder whether Debian developers should focus the > packaging and installation system rather than trying to fix all the > bugs in GNU, etc. In other words, I think the test suite should > focus, at least at the outset, on implementing the policy and making > sure that installation and upgrades go smoothly. We already test installs and upgrades. If you'd like to know what we do in more detail, read an earlier post "Debian needs guinea pigs" that I sent here and to deb-user. It is focused on what the user sees with a fairly default setup, so if we have time, I'll suggest some /bin/sh -> /bin/ash testing. > [BTW, I'm not trying to criticize the current state of hamm, I know > the freeze is a ways off and there's a lot of instability going on.] But given my schedule over the next month, any freeze will be too soon. Brandon - Brandon Mitchell <[EMAIL PROTECTED]> "We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds" Phone: (757) 221-4847 --Linus Torvalds -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Checklist request (was: RFC: Deb 2.0 testing process)
On Thu, 11 Dec 1997, Ian Jackson wrote: > Philip Hands: > > It seems a shame to have to ask people to do this sort of thing. > > > > It strikes me that one should be able to come up with a script that > > does a test of this sort in not much more that the time required to > > write the list (in this simple case at least ;-) > > > > I really think we should encourage people to do this where possible. > > I agree. These tests should be shipped with the package source (not > in the .deb file, since most users won't want them). Requiring the testers to download the package and the source is a bad things IMO. Also, when I'm trying a new package, I think it might be nice to see what it can do by trying the test script. These scripts should be small, using files already on the system if possible (or from /usr/doc//examples). Finally, the maintainer doesn't have to include the script, it's just something extra they want to do. > These scripts could be written by package maintainers, or by the > testing group and submitted as bugs. If it gets to the point that the testers are making testing scripts, we'll probably send it to the maintainer if they are interested, but keep it on a web site for faster distribution among ourselves. Waiting for a package to be uploaded for a test script during a frozen period may make this process painfully long. Brandon - Brandon Mitchell <[EMAIL PROTECTED]> "We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds" Phone: (757) 221-4847 --Linus Torvalds -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#15859: libc6 in stable is horribly broken
Question: Would it possible to make a (not altdev): debian/dists/unstable/main/binary-i386/oldlibs/libc5-dev_5.4.33-7.deb that conflicts with libc6-dev? And would this solve everyones problem? I'm just wondering if the libc5 in this directory doesn't have problems with the utmp. Thanks, Brandon ----- Brandon Mitchell <[EMAIL PROTECTED]> "We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds" Phone: (757) 221-4847 --Linus Torvalds -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: hamm base disks?
On Tue, 30 Dec 1997, Simon's Mailing List Account wrote: > does anybody have hamm base disks that need to be tested? > or do we still need to use the bo ones and then upgrade the base packages? The testing group is waiting for Sven to put them together, and I haven't heard any estimates. BTW, are you in the Debian Testing Group (I don't have my list of active members here)? If not, you sound like a perfect candidate. Let me know if you are interested. Brandon -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Locked out of Root after attemting to change shells
On Thu, 8 Jan 1998, [EMAIL PROTECTED] wrote: > To whom it may concern: > > I recently installed Debian Linux 1.3 on my computer, and while I > was trying to change my login shell for root the other day with chsh, > I accidently typed in an incorrect path to the shell I wanted. Being > root, I was not restricted in the path choice that I made, so now > every time I log on as root, I get an error message that says > 'shell not found' and I am promptly logged off the system. Is there > any way to correct this problem short of reinstalling everything > again? I would greatly appreciate any help you could provide. I think you can get su to work, but you may have to tell it what program to run instead of the login shell. HTH, Brandon -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Dumping core: root vs. normal user
On 15 Apr 1998, Eloy A. Paris wrote:
> an easy one: why when root runs a program that faults core is not
> dumped but when a normal user runs the same program a core is dumped?
[EMAIL PROTECTED](p5):cs315# cat core-test.c
void main(void)
{
* (char *) 0 = 0;
}
[EMAIL PROTECTED](p5):cs315# gcc core-test.c -o core-test
[EMAIL PROTECTED](p5):cs315# ./core-test
Segmentation fault (core dumped)
[EMAIL PROTECTED](p5):cs315# whoami
root
[EMAIL PROTECTED](p5):cs315# ulimit -c
unlimited
I'd check the ulimit,
Brandon
-----
Brandon Mitchell <[EMAIL PROTECTED]> "We all know linux is great... it
PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds"
Phone: (757) 221-4847 --Linus Torvalds
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dumping core: root vs. normal user
On 15 Apr 1998, Eloy A. Paris wrote: > Nope, ulimit -c also outputs "unlimited". What about the output of "set > -o", how does yours look like? allexport off braceexpand on errexit off hashall on histexpand on keyword off monitor on noclobber off noexec off noglob off notify off nounset off onecmd off physicaloff privileged off verbose off xtrace off history on ignoreeof on interactive-commentson posix off emacs on vi off Also, note that I haven't updated my system in quite a while. Let me know what other packages could do this: ii libc6 2.0.7pre1-1The GNU C library version 2 (run-time files) ii bash2.01-5 The GNU Bourne Again SHell Brandon - Brandon Mitchell <[EMAIL PROTECTED]> "We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds" Phone: (757) 221-4847 --Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Colored Shell
On Thu, 16 Apr 1998, Pat Quick wrote: > I have had Linux on my machine before (Slackware) and had a shell that > had different colors assigned by file type. It was pretty nice. I > cannot find the shell that does this in the newest version of Debian. > Any suggestions. Help on changing shells at login would be appreciated > as well (I am a little rusty). Before I answer the question, two request. First, debian-user is the correct list for these types of questions. Second, try to hit enter every 75 characters or so since your mail program doesn't seem to do this for you. (I'm not flaming you, they are the kind of things you learn by trial and error.) To get the color ls, put: alias ls='ls --color=auto' in your .bashrc and .bash_profile or in the /etc/profile. To change your shell, use chsh. HTH, Brandon - Brandon Mitchell <[EMAIL PROTECTED]> "We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds" Phone: (757) 221-4847 --Linus Torvalds -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problem with dselect and the "dists" hierarchy
On 2 Jun 1998, Manoj Srivastava wrote: > Shell scripts should generally be mechanically transformable > to Perl, and I have had a look at this one, though not trivial, it is > certainly eminently doable. The question is, should we be doing it at > this late stage in the game? Well, if it is broken and a user will need it, yes (when I looked at the first message, this appeared to be the case). As to how to fix it, I'll leave that to someone else's decision, but I'd suggest the method that is least likely to break and cause further problems (i.e. a complete rewrite may result in bugs that don't show up until after release, but we may be able to change it with a simple search and replace of the offending directory names). Comments? Brandon - Brandon Mitchell <[EMAIL PROTECTED]> "We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds" Phone: (757) 596-5550 --Linus Torvalds Debian Testing Group status: http://bhmit1.home.ml.org/deb/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with the undead (zombies)
On Fri, 5 Jun 1998, Stephen Carpenter wrote: > This turned out to be almost trivial...simply a few mods, instead of servicing > requests after connect, it fork()s and lets the child service that connection > while the parent loops and waits fo rthe next connect. [I think I changed > 10 lines of code total] > > This SEEMS to work fine (I havn't really given it a good test -YET) > except when I connect and then disconnect...the child exists > (via _exit(0)) after the client disconnects. The problem is that the > child then become a zombie. > > [ how do I get rid of zombies? ] See wait(2). Brandon - Brandon Mitchell <[EMAIL PROTECTED]> "We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds" Phone: (757) 596-5550 --Linus Torvalds Debian Testing Group status: http://bhmit1.home.ml.org/deb/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Hamm install on laptop
On Fri, 5 Jun 1998, Steve Tonnesen wrote: > I'm getting unresolved symbol errors when cardmgr tries to insmod the > 3c589_cs module for my 3Com PCMCIA ethernet card. Is this a problem with > the boot disks, and/or is there a solution for this? The laptop is an AST > Ascentia J series, and the card is a 3C589C. This was just reported a while ago on debian-testing by [EMAIL PROTECTED], I don't know if he had a solution, but he filed a bug report and the boot disks maintainers follow the list and therefore well aware of the problem. Check on 2.0.7 due in incoming next week. Brandon - Brandon Mitchell <[EMAIL PROTECTED]> "We all know linux is great... it PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds" Phone: (757) 596-5550 --Linus Torvalds Debian Testing Group status: http://bhmit1.home.ml.org/deb/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems with the undead (zombies)
On Sun, 7 Jun 1998 [EMAIL PROTECTED] wrote:
> > To fix your zombie problem you should IGNORE sigchld or arrange for wait
> > to be called (but not in the signal handler)
>
> ahh not call wait() in the signal handler...I was just now about to tackle
> this problem...hmm unfortunatly im not sure where other than the signal
> handler to call wait...hmm
> maybe ignore is better solution..ill try it
More incentive to do it in a signal handler, tested code:
void sig_handler (int i) {
if (i == SIGCHLD) { /* signal based reaper */
while (wait3(NULL, WNOHANG, 0) > 0);
}
}
Placing a wait someone else may cause your program to hang until a child
dies. But note that if you have a select or some other kernel call, you
will exit from that call with some kind of error code (it took me a while
to realize this, never stopped using perror since then).
> ok...according to my book it is ignored by default? I don't understand
> why these zombies are made then?
> maybe I will just add a wait to main loop so it will just perform cleanup
> eveytime a new connection is made?
You can get info back from your child from the wait or somewhere. So the
kernel keeps your undead child around until you run the wait or die
yourself. When you die, apparently init, the parent of all, will get rid
of the zombies.
HTH,
Brandon
-
Brandon Mitchell <[EMAIL PROTECTED]> "We all know linux is great... it
PGP: finger -l [EMAIL PROTECTED] does infinite loops in 5 seconds"
Phone: (757) 596-5550 --Linus Torvalds
Debian Testing Group status: http://bhmit1.home.ml.org/deb/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.0.16
On Wed, 10 Jun 1998, Jason Gunthorpe wrote:
> APT 0.0.16 is available for both bo and hamm. Please let me know if there
> are any bugs that got missed, I'm getting very few bug reports these days.
Just grabbed it after doing a dselect update and select with apt 15. Went
back to dselect for an update and found:
/usr/lib/dpkg//methods/apt/update: line 3: 11448 Segmentation fault
(core dumped) apt-get update
update available list script returned error exit status 139.
Press RETURN to continue.
I will attach a core file and my status file in a seperate message Jason
Brandon
--+--
Brandon Mitchell <[EMAIL PROTECTED]> | Debian Testing Group Status
PGP Key: finger -l [EMAIL PROTECTED] | http://bhmit1.home.ml.org/deb/
Dijkstra probably hates me (Linus Torvalds, in kernel/sched.c)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Something is corrupting `wtmp/utmp' again.
On 14 Jun 1998, Karl M. Hegbloom wrote:
> Any idea what's causing this? I think it *might* be pppd, but I'm
> not sure.
>
> `C-u M-! last'
> p*** [EMAIL PROTECTED]|*@ [EMAIL PROTECTED]Sun Jun 14 12:42
> still logged in
> karlheg ttyp5:0.0 Sun Jun 14 11:37 still logged in
xterm. The testers spent a while on this. The X maintainer is having a
hard time with this size package. See:
http://master.debian.org/~branden/xsf.html
HTH,
Brandon
--+--
Brandon Mitchell <[EMAIL PROTECTED]> | Debian Testing Group Status
PGP Key: finger -l [EMAIL PROTECTED] | http://bhmit1.home.ml.org/deb/
Dijkstra probably hates me (Linus Torvalds, in kernel/sched.c)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FIX FOR HAMM: timezone problem
On Tue, 16 Jun 1998, Dale Scheetz wrote:
> On Mon, 15 Jun 1998, John Goerzen wrote:
>
> > Investigating the matter revealed that /etc/timezone said
> > US/Central. running /usr/sbin/tzconfig and setting it to
> > SystemV/CST6CDT fixed the problem.
> I'm sorry to disapoint you, but US/Central is a perfectly valid timezone.
> It is only intended for those parts of the central US where Daylight
> Savings Time is not practiced. You will notice that there are equivalet
> settings for the other timezones as well.
In tzconfig, it prompts you for your geographic area. Just about everyone
I can think of will select US if they are in the US. But if what you are
saying is correct, non of those settings are for people with Daylight
Savings Time. There should be an alternative list under the US section
that is for people with Daylight Savings Time.
Brandon
--+--
Brandon Mitchell <[EMAIL PROTECTED]> | Debian Testing Group Status
PGP Key: finger -l [EMAIL PROTECTED] | http://bhmit1.home.ml.org/deb/
Dijkstra probably hates me (Linus Torvalds, in kernel/sched.c)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FIX FOR HAMM: timezone problem
On Tue, 16 Jun 1998, Nathan E Norman wrote: > On Tue, 16 Jun 1998, Brandon Mitchell wrote: > > : On Tue, 16 Jun 1998, Dale Scheetz wrote: > : > : > I'm sorry to disapoint you, but US/Central is a perfectly valid timezone. > : > It is only intended for those parts of the central US where Daylight > : > Savings Time is not practiced. You will notice that there are equivalet > : > settings for the other timezones as well. > : > : In tzconfig, it prompts you for your geographic area. Just about everyone > : I can think of will select US if they are in the US. But if what you are > : saying is correct, none of those settings are for people with Daylight > : Savings Time. There should be an alternative list under the US section > : that is for people with Daylight Savings Time. > > Sorry, but I think "US/Central" works as advertised. > > kepler:~ $ cat /etc/timezone > US/Central > kepler:~ $ date > Tue Jun 16 09:29:29 CDT 1998 > > I know this said "CST" when we weren't on DST. Furthermore, it > shouldn't say "CDT" if "It is only intended for those parts of the > central US where Daylight Savings Time is not practiced." Don't be sorry, it means that Dale said it backwards, which makes things much easier. Just say if you don't use DST, pick from these shortened abreviations. I was hoping for this, which is why I qualified myself with a "if what you are saying is correct" line. Thanks, Brandon --+-- Brandon Mitchell <[EMAIL PROTECTED]> | Debian Testing Group Status PGP Key: finger -l [EMAIL PROTECTED] | http://bhmit1.home.ml.org/deb/ Dijkstra probably hates me (Linus Torvalds, in kernel/sched.c) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More corrupted utmp/wtmp
On Fri, 19 Jun 1998, Troy Hanson wrote:
> >: $ last
> >: ;* *.*5 192.168.5.51 Wed Dec 31 21:26 still logged in
> >:
> >: wtmp begins Tue Jun 16 08:45:00 1998
> >Do you have ssh installed? (or anything else from non-US) ... I seem to
> >recall some troubles with the libc5 version of ssh ...
> yes, ssh is installed on both machines. I will try rebuilding it... I
> will post the results of the trial. :)
I'm pretty sure this is the fault of xterm. After a logout, it does this.
Do an ldd on ssh before rebuilding.
Brandon
--+--
Brandon Mitchell <[EMAIL PROTECTED]> | Debian Testing Group Status
PGP Key: finger -l [EMAIL PROTECTED] | http://bhmit1.home.ml.org/deb/
Dijkstra probably hates me (Linus Torvalds, in kernel/sched.c)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More corrupted utmp/wtmp
On 22 Jun 1998 [EMAIL PROTECTED] wrote: > Brandon Mitchell <[EMAIL PROTECTED]> wrote: > > > I'm pretty sure this is the fault of xterm. After a logout, it does this. > > Do an ldd on ssh before rebuilding. [ Note that this was my stupidity since the user said they weren't running an xterm, but now on to another thing... ] > Uhhmmm... I don't really know whose fault is this. This weekend I did > a fresh install (using Enrique's 2nd 2.0.7 boot floppies pre-release) > and installed a minimum X system > (xbase+xserver+fonts+xcontrib+fvwm95). > > I haven't seen the utmp/wtmp corruption at any time... I've got xbase 3.3.2.1-1. Try to open an xterm, check the output of last, all should be ok: bhmit1 ttypahobbes:11.0 Mon Jun 22 13:21 still logged in Now, exit the xterm: p*** [EMAIL PROTECTED],*@ [EMAIL PROTECTED]Mon Jun 22 13:21 still logged in bhmit1 ttypahobbes:11.0 Mon Jun 22 13:21 still logged in This may have been fixed by the latest libc6 (according to the x maintainers web page), but I'm waiting for the version number debate to end before up(down)grading. Can you verify this on a fresh install? Brandon --+-- Brandon Mitchell <[EMAIL PROTECTED]> | Debian Testing Group Status PGP Key: finger -l [EMAIL PROTECTED] | http://bhmit1.home.ml.org/deb/ Dijkstra probably hates me (Linus Torvalds, in kernel/sched.c) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: location of 2.0.7 boot disks
On 23 Jun 1998, Douglas Bates wrote:
> I don't see the 2.0.7 boot disks for an i386 system on
> master.debian.org yet. Could someone please remind me where to get
> them from Enrique's computer? I don't seem to have that message any
> more.
I believe it is in:
ftp://molec2.dfis.ull.es/pub/debian-spanish/boot-floppies/
but I can't get a connection to verify it right now.
HTH,
Brandon
--+--
Brandon Mitchell <[EMAIL PROTECTED]> | Debian Testing Group Status
PGP Key: finger -l [EMAIL PROTECTED] | http://bhmit1.home.ml.org/deb/
Dijkstra probably hates me (Linus Torvalds, in kernel/sched.c)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gdselect alpha 3
On Fri, 16 Oct 1998, Michael Stone wrote: > > Michael> Perhaps an incremental approach is good: a good gui for the > > Michael> existing product in this release, other features in other > > Michael> releases. Maybe apt will be better, but we haven't seen it > > Michael> yet (referring to the UI). Apt's been in development for a > > Michael> long time, maybe some friendly competition will help. And > > Michael> why can't we have multiple UI's to the package management > > Michael> system? This is linux: one size doesn't fit all. There was a feature on slashdot a while ago saying that projects that sit around and talk constantly never do anything. Ones that have someone just put up some code for the public to critique seem to be the fastest and the best. The code has been put up, now its our turn to suggest how it can be fixed/improved, not complain that it shouldn't be there at all. > I didn't mean to argue that gdselect should necessarily ship now; by > release I meant "this release of gdselect." What I was trying to answer > was an attitude that seemed to be saying "we shouldn't do anything about > dselect until we have a solution that not only provides a decent gui, > but also everything else." (Which I took to mean automatic package > dselection, superpackages, seamless x/tty transition, and everything > else that apt is supposed to provide.) Some people just want a gui, and > I think it's reasonable to provide it. It's not fair to compare gdselect > with what apt is supposed to be, if for no other reason than that > they're not trying to acheive the same goals. Perhaps this can encourage the apt maintainers to finalize how the different ui's interface with their libraries in a universal way. Since all they have had is the CLI, there may be some work to finish for this. > BTW, since I don't see how gdselect could be used on initial > installation anyway, I don't think it would hurt to leave it off the > cd's and make it available for download later. We can call it a beta or > whatever, but those who want it could still use it. I think sid is the place for this. When you are ready, you can move it to the current unstable. Brandon P.S. just looking at the screen shots, I think this is a really good thing. Bravo. --+-- Brandon Mitchell <[EMAIL PROTECTED]> | Debian Testing Group Status PGP Key: finger -l [EMAIL PROTECTED] | http://bhmit1.home.ml.org/deb/ Dijkstra probably hates me (Linus Torvalds, in kernel/sched.c)
Re: Logo license update?
On Mon, 18 Jan 1999 [EMAIL PROTECTED] wrote: > The Debian logo license is expired. Is there a plan to update it or > automatically roll it over again? Why not change it to a constantly rolling over license. The way I understand it, we have this license to prevent bad things from being done with the logo, and want to be able to add appropriate restrictions. So we say the licence you read is valid for 30 days from when you read it. I.e. if we change it, you have 30 days to comply. If you plan on having a lot of inventory with our logo, just check the license online and know that you have at least 30 days to sell your inventory. Just a thought from an uninformed user, Brandon +--- ---+ | Brandon Mitchell * [EMAIL PROTECTED] * http://bhmit1.home.ml.org/ | | The above is a completely random sequence of bits, any relation to | | an actual message is purely accidental. |
Re: Debian v2.1 ("Slink") Deep Freeze
On Tue, 19 Jan 1999, Wichert Akkerman wrote: > > xbase 30852 X packages do not upgrade automatically due to > > name change. > > xdm 29360 xdm: Stopped X without warning/asking > > xlib6 31610 xlib6: requires gcc but declares no dependency > > (dpkg --print-gnu-build-architecture?) > > xserver-common29166 xserver-common: should depend or at least > > recommend properly ver'd xlib6g > > Branden has a release candidate for X ready somewhere, and I urge > everyone to test that! The site is: http://master.debian.org/~branden/xfree86/ or in apt: deb http://master.debian.org/%7Ebranden xfree86/ These are considered experimental, but I'm sure he welcomes all testers. HTH, Brandon +--- ---+ | Brandon Mitchell * [EMAIL PROTECTED] * http://bhmit1.home.ml.org/ | | The above is a completely random sequence of bits, any relation to | | an actual message is purely accidental. |
Re: Debian v2.1 ("Slink") Deep Freeze
On Tue, 19 Jan 1999, Santiago Vila wrote: > On Tue, 19 Jan 1999, Brandon Mitchell wrote: > > > On Tue, 19 Jan 1999, Wichert Akkerman wrote: > > > > > Branden has a release candidate for X ready somewhere, and I urge > > > everyone to test that! > > > > The site is: > > http://master.debian.org/~branden/xfree86/ > > Mmm, what about the needed compatibility packages? > Will you have some time for this? > > I think it is absolutely essential for the success of Debian 2.1 that > nobody will automagically lose functionality in the upgrade process. Done in experimental changes file: * xbase is now a pseudo-package used to smooth upgrades from hamm or earlier systems * what was the new xbase is now xfree86-common HTH, Brandon +--- ---+ | Brandon Mitchell * [EMAIL PROTECTED] * http://bhmit1.home.ml.org/ | | The above is a completely random sequence of bits, any relation to | | an actual message is purely accidental. |
Re: Debian Weekly News - 12 to 18 Jan 1999
On 20 Jan 1999, Achim Oppelt wrote: > Just one minor criticism: > > > * For all those interested in XFree 3.3.3, Ben Gertzfield [15]posted > >that the Debian JP group has made their own 3.3.3 packages. They > >can be found at [16]ftp.debian.or.jp. Your mileage may vary, but > >it may be something to try before pulling you hair out when the > >binaries from the XFree group give you problems. > > The name of the product is XFree86 (even though it is no longer i86 > specific). And the name of the group of people creating it is The Xfree86 > Project, Inc. While such points certainly don't matter in informal > discussions on mailing lists, I think that it would be a good idea to get > the terms right in a more or less official newsletter. Woops, sorry, that was my bad. And I was debating whether to call it X or XFree. I'll be more careful next time. Thanks, Brandon +--- ---+ | Brandon Mitchell * [EMAIL PROTECTED] * http://bhmit1.home.ml.org/ | | The above is a completely random sequence of bits, any relation to | | an actual message is purely accidental. |
Proposal: increasing mirror security
After seeing some trojan horses being spread and Martin trying to make sure xisp can be verified as secure on the debian-user list, I started thinking of how to secure our mirrors. The thought I had was to make pgp signatures of the package files and save them as Packages.pgp. This will not interfear with the current package files, therefore we are still backwards compatable. Then apt could check for a pgp file and verify it for the user. If it fails, it could just warn the user and ask to continue. This would require: a) gnu's version of pgp to work (so that we don't request non-free software to get the free software) and the bad part b) someone to be at the console when generating packages files to type the pgp password. Note that a trojan horse can only be added by a trusted user (i.e. the package maintainer or an ftp site maintainer) unless the upstream source compromised. Thoughts? Brandon +--- ---+ | Brandon Mitchell * [EMAIL PROTECTED] * http://bhmit1.home.ml.org/ | | The above is a completely random sequence of bits, any relation to | | an actual message is purely accidental. |
Re: Proposal: increasing mirror security
[ hope you don't mind me cc'ing the list, but I think I didn't detail an important point. ] On Mon, 25 Jan 1999, Vincent Murphy wrote: > i would favour another field in the .deb package format which contains a > signature, which can be used by apt or whatever to verify that it is > genuine. however, i understand that modifying the package format isn't a > viable solution where backward-compatability is a priority. Ok, there could be a package by package basis. I was going for the simpler pgp signature of the entire Packages file itself. Since the packages file contains md5sums, there is a decent check on package by package basis already in apt. Thanks for seeing this, Brandon +--- ---+ | Brandon Mitchell * [EMAIL PROTECTED] * http://bhmit1.home.ml.org/ | | The above is a completely random sequence of bits, any relation to | | an actual message is purely accidental. |
Re: Proposal: increasing mirror security
On Mon, 25 Jan 1999, Lalo Martins wrote: > Sounds good, as long as I can shut it off :-) Also, it should > use the keyring in developers-keyring or one that comes with > apt, otherwise the point is moot (anyone who can upload a .deb > with a trojan can upload a Packages.pgp with a signature) The only person that can upload a Packages.pgp file is the mirror maintainer. The explination is below. > > This would require: a) gnu's version of pgp to work (so that we > > don't request non-free software to get the free software) > > Here we go again. This would have the problem of requiring all > developers to switch to gpg. I definately messed up this point, the only thing that is signed is the _packages file_, not the individual packages. The only person with gpg is the mirror maintainer. Actaully, as long as gpg is compatable with pgp, that doesn't even matter and the apt user simply picks what they want to install. > > and the bad part b) someone to be at the console when > > generating packages files to type the pgp password. > > Huh? You don't need the passphrase to verify signatures. Not verify, create. The pgp signature is for the packages file, not the developers packages themselves. This just means the process of moving files from incoming to the tree needs to have a person at the console because after the file is moved and the Packages and Packages.gz file are created, the Packages file needs a pgp signature stored in Packages.pgp. A less secure version would be to have the Packages.pgp file generated automatically. Sorry about the confusion, Brandon +--- ---+ | Brandon Mitchell * [EMAIL PROTECTED] * http://bhmit1.home.ml.org/ | | The above is a completely random sequence of bits, any relation to | | an actual message is purely accidental. |
Re: Proposal: increasing mirror security
On Mon, 25 Jan 1999, Wichert Akkerman wrote: > If people really want to be able to verify package integrity we might as > well go the whole way. Ian Jackson posted (1.5 years ago I think) a > proposal that would secure the complete stage from building a package to > distribution on the mirrors. > > You might want to look that up in the list archives. I found what looks like the thread in reference on Feb 97: http://www.debian.org/Lists-Archives/debian-devel-9702/threads.html However, 1) half the month (and thead) is missing, and 2) it seems to detail getting the package into the mirror with little concern once it's there. I have a bit of faith in pgp signing the packages and uploading them. I'm a bit more concerned once it's there since users don't see these pgp signatures. If the package.gz file was signed, we would be pretty good, but apt and dselect can't handle that kind of change. So I'm proposing the file be signed but the signature being kept in a separate file. For the mirror maintainers, this involves: pgp -sab Packages mv Packages.asc Packages.pgp # or maybe we don't need this Thanks, Brandon +--- ---+ | Brandon Mitchell * [EMAIL PROTECTED] * http://bhmit1.home.ml.org/ | | The above is a completely random sequence of bits, any relation to | | an actual message is purely accidental. |
Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86
About the xfonts problem. I haven't been following close enough to pardon my ignorance on the subject. What if we make the pseudo xbase package conflict with xfnt* packages < version x (a versioned conflict)? How will dselect handle this, will it upgrade the fonts to the new name? If it works, this would seem to be a solution that everyone can live with. Comments are welcome, Brandon +--- ---+ | Brandon Mitchell * [EMAIL PROTECTED] * http://bhmit1.home.ml.org/ | | The above is a completely random sequence of bits, any relation to | | an actual message is purely accidental. |
Re: cron has gone to UTC time?
On Fri, 29 Jan 1999, Joey Hess wrote: > Craig Sanders wrote: > > i've noticed this behaviour in the past, when xntp gets upgraded in the > > same dselect run as cron or sysklogd. > > I doubt this is it because I've experienced the problem on 2 machines; > neither runs xntpd or any other time synchronization program. Hit me as well. I noticed when my computer asked why I was up so late and it was only dinner time. Johnie, what happened? I don't see anything in a quick skim of the change logs, nor do I see anything on the bug list. Thanks, Brandon +--- ---+ | Brandon Mitchell * [EMAIL PROTECTED] * http://www.resnet.wm.edu/~bhmit1 | | The above is a completely random sequence of bits, any relation to an | | actual message is purely accidental. |
Re: Corel Setup Design Proposal
On Sat, 8 May 1999, Oliver Elphick wrote: > Brandon Mitchell wrote: > >On Fri, 7 May 1999, Andreas Jellinghaus wrote: > > > >> pretty easy: every recent graphic card is pci or agp, so it's detected > as > >> pci device and listed in the /proc file... > > > >>From what I understand, this would only give you the video card. The > >other half (and the more painful part in my opinion) is the monitor. Is > >there some way to auto-detect a monitor, or is this a lowest common > >denominator problem (i.e. small resolution and refresh)? > > Would it be in any way feasible to ask the user to put in his manufacturer's > floppy and get the necessary data out of that? The format must be known, > because every manufacturer must supply data for the Windows registry. For Corel, maybe. For Debian, I doubt it. It would severly limit the number of monitors supported (I have 4 around here, no disks, and no M$ to be seen). Simple resolution, vsync and hsync work for me. When I don't know, a conservative guess would work. I believe Red Hat does this. Options? Brandon +--- ---+ | Brandon Mitchell [EMAIL PROTECTED] http://bmitch.dhis.org/ ICQ 30631197 | | Throughout history, UNIX systems have regularly been broken into, beaten, | | brutalized, corrupted, commandeered, compromised, and illegally fscked. | |-- UNIX System Administration Handbook |
Re: install report for Debian 2.1 and some comments on installation profiles
On 9 May 1999, Adam Di Carlo wrote: > [Talking about tasks and profile from boot-floppies] > > >>>>> "brandon" == Brandon Mitchell <[EMAIL PROTECTED]> writes: > brandon> I'd personally like to see a way to easily add a profile via > brandon> dpkg -get-selections and make for a cookie cutter install > brandon> (think large labs). [ woah, this is an old thread, but a good one to bring back. ] > Eh... I don't see this as a good idea. I personally would rather see > all the "tasks" made into "metapackages" (packages which are basically > just a bunch of dependancies, and some info in /usr/doc/). Ok, my first reaction is that this is a quick and easy hack with a better solution that we are missing. I can't convince myself of that the more I think of it. These tasks need to be tightly integrated with the packages and some how compatable with what we have. Unless someone has a better idea, abusing the packaging system seeems to be the best solution. > Then you can maintain your tasks and profiles all the time. > > Also, tasks would be task- metapackages, depending on actual > Debian packages. Profiles would be profile- > metapacakges, depend on just the tasks. I'd also propose a new section for tasks, so that they are easy for users to find and for the package installer to separate out if necessary. > Voila. Elegant, uses the existing packaging system (i.e., no need to > skip the select step in dselect), simple, and, really, it has little > to do with the boot-floppies at all. Although, the existing GUI could > be changed a bit so it just installs these metapackages, rather than > the actual packages themselves. Furthermore, users who are upgrading > or whatever can take advantage of tasks and profiles, rather than just > those who are using the boot-floppies. Yes, the next frontend to apt (gnome-apt?) should handle the tasks specially. They should be able to hit a customize button for each task which can take you to a dependency resolution screen. This way if the task depends on a web server or apache, it defaults to apache, and the customize screen for that task will show all web servers. Then provide another customize button to handle all packages (what we have now). > Another nice benefit to my scheme is that each task/profile can be > maintained independantly by different Debian developers. In fact, I > volunteer to take over the SGML environment task if we do move to this > scheme. Agreed, distributing the work into small chuncks is better and one reason debian has done so well. > So -- lets have a little discussion period, and then decide, and > perhaps start looking for volunteers. We need to jump on this quick > so we can have it in place for freeze time, whenever that is. It probably isn't difficult to convert the old tasks into packages and put them up on an apt-able site. Then those who want to test can go right ahead. It's about time I became a maintainer so I can put my package where my mouth is. Graduation and a move are soon, I'll start after that's over. Brandon +--- ---+ | Brandon Mitchell [EMAIL PROTECTED] http://bmitch.dhis.org/ ICQ 30631197 | | Throughout history, UNIX systems have regularly been broken into, beaten, | | brutalized, corrupted, commandeered, compromised, and illegally fscked. | |-- UNIX System Administration Handbook |
Re: time to rewrite dpkg
Hi Aaron, I would be interested in seeing your design. It may clear up some concerns as to why you are picking your language (which seems to have generated quite a discussion). More importantly, you may receive suggestions as to ways to improve the design. If you are lucky, you may even have a few volunteers to help with the coding or specific parts. I guess I'm just a big fan of getting the design right since the resulting code of a bad design is much more difficult to fix than bad code with a good design. Bravo for volunteering to code this yourself, I hope to do the same one day. Brandon +--- ---+ | Brandon Mitchell [EMAIL PROTECTED] http://bmitch.dhis.org/ ICQ 30631197 | | Throughout history, UNIX systems have regularly been broken into, beaten, | | brutalized, corrupted, commandeered, compromised, and illegally fscked. | |-- UNIX System Administration Handbook |
Re: mass-installing Debian
On Tue, 25 May 1999, Michel Kaempf wrote: > On Mon, May 24, 1999, Goswin Brederlow wrote: > > Wouldn't it be nice if dpkg would tell you what exactly has changed > > between the packages config file and what the difference to your > > config is? > > > > I allways wonder what has changed, since I normally haven't changed > > those files dpkg askes me about. > > Everything already exists in dpkg to perform this comparison : when > dpkg prompts me for a config file replacement, I type `Z' to get a > shell, and I use `diff package.conf package.conf.dpkg-new' to find > out the differences between the two files... > > I think that making this step automatical would make a dpkg session > too verbose and too prompting. It doesn't have to be automatic, just available. There are 5 options now, 2 for yes, 2 for no, and one apparently for a shell (forgot about that one). Just add one more for a diff. Easy and useful. Brandon Brandon Mitchell [EMAIL PROTECTED] -- http://bmitch.dhis.org/ ICQ: 30631197
