Re: dpkg memory usage
In article <[EMAIL PROTECTED]> you wrote: > ... > I also intend to change the format of the /var/lib/dpkg/info/*.list > database to make it faster to load, and I may change > /var/lib/dpkg/status too. (The resulting structures will still be > editable with emacs.) I've written a Regina REXX program to run some comparisons between the dpkg/status file and current Packages (+non-free, contrib, nonus) files. It currently shows which files need updating, misconfigured packages, shows a deb's paragraph from the Packages file. I think it would be useful to others. Would anyone like to have a look at it and give me some feedback? I have a few questions. Is the status file likely to change radically? Or the Packages format? Which program updates /var/lib/dpkg/available? I've been making a Packages file by catting together all the Packages files (non-free, ...) and putting the file in /tmp. Can I, as root, make the dpkg/available file from this catted file without screwing the package management up? Thanks. Rick -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Duplicate package names
I've combined the Packages files for main, contrib, non-free and non-us for a program I'm working on and there are about 10 duplicate package names. tcpquota is in contrib/admin & admin; xexec in contrib/misc and x11, for example. Is this because the different versions have different distribution definitions and both will stay around or is it just that some housekeeping needs to be done? I guess it doesn't matter if both will stick around because I'd have to allow for package name dupes to include the experimental Packages file anyhow. I've put the current version of the program up at http://www.tfn.net/~ricknie . I realize no one has any spare time right now, but I'd really appreciate it if someone familiar with Debian could have a look at it and tell me if it's worthwhile or if it just duplicates things that are already out there. It might be more useful to turn it into a program that just allows comparisons and searches of the file lists from the various Linux distributions. That's providing I can find them. Rick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Swap setup on Debian
On Tue, 28 Sep 1999, Staffan Hamala wrote: > I've noticed when installing Debian that the installer always shrinks > my swap partition to 128MB, so I have to do a swapoff;mkswap -v1 ..;swapon > manually afterwards. Also, the message that it has done this is easily As an aside to this, I use two 64MB swap partitions in my system so it will interleave the data between the two hd's. As far as I could tell, the installer can only setup one swap partition. The option to setup more than one swap partition and also possibly set their priority (to the same thing, in my case) at install time would be useful for me. Laters, Rick ([EMAIL PROTECTED]) http://rick.chillin.org "As long as you want to live, everywhere will become heaven. Isn't that right? Because you are still alive. The chance to achieve happiness, you can find it anywhere." Yui Ikari Neon Genesis Evangelion, "The End Of Evangelion"
Re: daemon configuration
On Sat, 2 Oct 1999, Colin Walters wrote: > On Sat, Oct 02, 1999 at 10:49:58AM -0700, David Bristel wrote: > > > > > Did you consider his point, though? Why would you install a service > > > if you don't want it to run? > > ones you want. A possible solution would be a "daemon" flag to go on a > > package, > > and after the install, the installed daemons are listed. This is just an > > idea, > > but that's another subject. > > This is basically what Red Hat does upon installation; it prompts you for > which > services to enable out of a list of installed daemons. Perhaps upon > installation > or a dist-upgrade, apt could list everything that had a "daemon" flag and > prompt > you to start it. That way we would avoid asking every time. I'm uncertain whether this is a good idea or not. I have helped many people install redhat linux and, frankly, the daemon enable screen confuses them. They don't know what all these things are or which ones they may need. If this gets implemented at least have an obvious "enable default daemons" button. I also agree that it would be useful to allow installing daemons without starting them. I am fond of Roxen Challenger, but I may also want Apache installed (on an alternate port) in case I decide to play around with it. It would be a waste of resources to run two http daemons on my machine when I only want to play with the second one occasionally. Installing, configuring, and then removing Apache every time is not satisfactory. Other than that I have not yet decided on the best solution for this. Personally, I just remove the symlink from my rc directory for each daemon I don't want started. However, I don't know how this is affected by package upgrades, etc, because I've just recently started using debian (unstable). Laters, Rick ([EMAIL PROTECTED]) http://rick.chillin.org "As long as you want to live, everywhere will become heaven. Isn't that right? Because you are still alive. The chance to achieve happiness, you can find it anywhere." Yui Ikari Neon Genesis Evangelion, "The End Of Evangelion"
Re: daemon configuration
On Sun, 3 Oct 1999, Michael Stone wrote: > On Sun, Oct 03, 1999 at 02:59:38AM -0400, Rick wrote: > > I'm uncertain whether this is a good idea or not. I have helped many > > people install redhat linux and, frankly, the daemon enable screen > > confuses them. They don't know what all these things are or which ones > > they may need. If this gets implemented at least have an obvious "enable > > default daemons" button. > > Think about this for a second. Why do we want to make it easy for people > to enable remote access to their system if they're unaware of what that > means? I agree with you, that was just an example. It could just as easily be a "disable all daemons" or perhaps "disable all network daemons". Laters, Rick ([EMAIL PROTECTED]) http://rick.chillin.org
RE: Packages should not Conflict on the basis of duplicate functionality
On Sun, 3 Oct 1999, Terry Katz wrote: > Why not implement a system similar to that in Irix ( and a few other sysv > style systems ), and use a 'chkconfig' type setup.. > > Irix implements it with a config directory (/etc/config), which contains > files with the same name as the init script or app, and contains a single > word .. 'on' or 'off' .. > > so, you can issue: > > chkconfig postgresql on > /etc/init.d/postgresql start > chkconfig postgresql off This is possibly a good idea. However, if you're gonna be doing this, why not just remove the symlink from /etc/rc2.d? When you want the daemon back recreate the symlink. I'm under the impression that package updates would recreate this link, so maybe that wouldn't work very well. > The modifications to add this to the distribution shouldn't be that > difficult .. the chkconfig (or whatever you want to call it) script can be > used to both test for and set the options.. > > chkconfig [ [on/off]] .. leave off the last parameter to check for the > status inside an init.d script and start based on that .. (leave off second > parameter to see a complete list of whats on/off) > > The initial change to add this to the init scripts could take a while > (although its simple to just add it to the beginning of the init scripts, > and just exit if the config is off), but once its implemented it would be a > nice tool.. no? (every now and again it would be nice to be able to > chkconfig gdm off, and/or chkconfig network off, etc...) How is "chkconfig network off" any better/easier than "/etc/init.d/network stop" (aside from the fact it won't get restarted when you reboot)? I thought that's what different runlevels were for, having different daemons started when you boot. Maybe I'm just thinking that mucking with /etc/rcS.d/ as easy enough, but I suppose a chkconfig would be easier for those less familiar with the init system. I don't like the idea of adding this check to each init script. Wouldn't it be better to add this check to /etc/init.d/rcS when it goes through the /etc/rcS.d/S??* scripts (since the chkconfig parameter has the same name as the init script minus the S??)? Laters, Rick ([EMAIL PROTECTED]) http://rick.chillin.org "As long as you want to live, everywhere will become heaven. Isn't that right? Because you are still alive. The chance to achieve happiness, you can find it anywhere." Yui Ikari Neon Genesis Evangelion, "The End Of Evangelion"
Re: Unstable release
On Mon, 4 Oct 1999, Daniel Burrows wrote: > On Mon, Oct 04, 1999 at 08:44:48PM +0200, Staffan Hämälä was heard to say: > > > I'm just curious about how other people succeed in installing the > > potato release. > > I do it with a fairly simple approach. I install the base Slink system, but > on the reboot (after setting a root password :) ) I edit /etc/apt/sources.list > and change all references to "stable" to "unstable". I then proceed as > before. This is exactly what I did and it worked perfectly. Although instead of editing /etc/apt/sources.list by hand I changed it from dselect during the install process. Laters, Rick ([EMAIL PROTECTED]) http://rick.chillin.org
Bug#2019: ftp.debian.org/debian/debian-0.93/ms-dos/xxxx/ has no files
A few days ago, all of the symlinks for the ms-dos file names disappeared from the package directories. Intentional? -- ...RickM...
Bug#2071: ftp.debian.org/debian/debian-0.93/Contents changes daily
The Contents (and Contents.gz) files at ftp.debian.org/debian/debian-0.93 change daily. On comparing the files from two days, the only difference was the line: (Last updated on Wed Dec 27 23:23:54 EST 1995) Is this intentional? It must be causing extra "mirroring" traffic every day. -- ...RickM...
dnrd sighup crash fix
Here is a fix for a crash on x86 when you send dnrd a
sighup. This problem shows up for sure on Slackware 7, but should happen
everywhere. I haven't tested it extensively, but if you check the original code
it becomes obvious why it needs to be changed. The only part that concerns me is
the use of the semaphore, but I think it's needed because it's used elsewhere.
This replaces a function in either main.c or master.c I can't remember
right now, this is not my development machine.
static int reset_master(void){
int i;
log_msg(LOG_NOTICE, "resetting master
DNS");
sem_wait(&dnrd_sem);
for (i = 0; i < dbc; i++)
{ free_dnsrec(dbv[i]);
}
if
(dbv) {
free(dbv); dbv =
0; }
dbc = 0; dbmax =
0;
sem_post(&dnrd_sem);
return
(0);}
maillist sick?
Are there problems with the mailing lists? devel-digest stopped coming 3 days ago. Other @home users say that mail has become unrealiable so I signed on from another address yesterday and haven't gotten a digest yet. debian-devel seems fine. And the debian-devel archive is a bit behind. The tag claims it was updated on March 28 but the last message sorted by date is March 11. Rick -- [EMAIL PROTECTED] http://loki.dhs.org/~rick
Re: How to get changelog file for a given _binary_ package?
Marc Haber wrote: > Hi, > > we use a number of backported potato packages and I am working on a > script that sends me e-mail when a new version of these packages > appears in woody. > > I would like to do this by periodically pulling the change logs for > all packages that we have backported from the Debian web page > (http://cgi.debian.org/cgi-bin/get-changelog?package=3D$package) and > then comparing the version number with the version number of our back > port. > > This doesn't work for multiple binary source packages - for example, > for libdb2-util, the URL given above returns "No such changelog file". Hi, lynx -dump http://packages.debian.org/libdb2-util might do what you want. Or add woody to sources.list and parse the Packages files locally. I think you'd also need to run the development APT at people.d.o/~jgg to tag woody so it isn't an install candidate. Rick --
ITP: worker - filemanager
Package: wnpp Severity: wishlist worker is a two-paned directory utility much like the Amiga's DirectoryOpus. License is GPL. Home page: http://www.boomerangsworld.de/worker Screenshots: http://www.boomerangsworld.de/worker/wscreenshots.php3
Bug#198314: RFA: rxsock, rexxtk
Package: wnpp Severity: normal rxsock[1] and rexxtk[2] need new maintainers. rxsock - Socket function library for Regina REXX rexxtk - Interface to Tcl/Tk for Regina REXX Rick -- [1] http://sourceforge.net/projects/rxsock/ [2] http://rexxtk.sourceforge.net/
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
Quoting Adam McKenna ([EMAIL PROTECTED]): > I suggest you take these suggestions to the TMDA worker's mailing list at > tmda.net, and file wishlist bugs against TMDA for each desired feature. This is an attempt to change the subject: The issue at hand is the cited maintenance (and acceptance) issues concerning the Debian package. If on the other hand the above was just a novel way to say "No" and dig in your heels, there are more direct (and concise) ways to do it, ja? -- Cheers, "The only good goth is a shoggoth" Rick Moen -- Alistair J.R. Young, in r.a.sf.w.r-j [EMAIL PROTECTED]
Re: Debian Installer Lenny Beta1
On Mar 17, 2008, at 1:04 PM, Otavio Salvador wrote: Please use the website instead since there you find the documentation, errada and everything else that you will need there: http://www.debian.org/devel/debian-installer/ The <[17 Mar 2008] Debian Installer lenny beta 1> link on that page leads to === Not Found The requested URL /devel/debian-installer/News/2008/20080317 was not found on this server. Apache Server at www.debian.org Port 80 === -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bugreport: kqemu results in kernel panic of the guest systems
Dear debian devs, I don't know how to input bug reports into bugzilla so I want to report a bug in Etch here: I am running Etch with this kernel: Linux funghi 2.6.18-4-686 #1 SMP Wed Feb 21 16:06:54 UTC 2007 i686 GNU/Linux I installed these packages: ii kqemu-common 1.3.0~pre9-12 Common files for the QEMU Accelerator module ii kqemu-modules-2.6-6862.6.18-4 QEMU Accelerator modules for Linux 2.6 on PPro/Celeron/PII/PIII/P4 ii kqemu-modules-2.6.18-4-686 2.6.18+1.3.0~pre9-4 QEMU Accelerator modules for Linux 2.6.18 on PPro/Celeron/PII/PIII/P4 ii qemu 0.8.2-4 fast processor emulator So, I tried with this command: qemu -m 256 -k de -net user -kernel-kqemu -cdrom /dev/hdc -hda -boot d to install a) Debian Sarge b) Debian Etch c) Slackware d) Sourcemage (each from the respective installer cds) but each booting from the install cds resulted in a kernel panic of the guest. Without "-kernel-kqemu" each tried install cd runs fine. Also the booting of the fully installed guest - after installing without kqemu - with "-kernel-kqemu" results in a kernel panic of the guest. But again without "-kernel-kqemu" booting the fully installed guest successes. I wanted to make a good bug report, so I also tried with kernel 2.6.18-4-486 and the respective kqemu-modules packages. The same failures as above occur with this kernel and kqemu modules, too. If you want to have more data I can give you. Thank you regards rpg_kernel ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I
On Mar 23, 2011, at 2:15 AM, Christian PERRIER wrote: I'm just not fond of "Australia/Sydney" presented as a choice, I'd rather have "New South-Wales". For what it's worth, the timezone database (as evidenced by, among other things, the output of the "tzselect" command) is organized mostly in terms of country/city rather than country/larger- geographical-area. Which is not to say that the larger geographical areas get completely short-shrift in the timezone database. Look at the directory structure under /usr/share/zoneinfo for example. As I understand it, the choice of a large city in the affected geographic area is practical in two ways: 1) Individual cities are fairly unlikely to be split into two or more timezones. Larger geographical units are more likely to be split than individual cities -- all depending on unpredictable future political squabbles. 2) Most people know what their nearest large city is. They may not know the fine distinctions of past and present political divisions as applied to timezones as applied to their present location. Just one point of view from somebody who occasionally lurks on the "tz" mailing list. Enjoy! Rick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/0ef9eef7-c2e0-4767-be44-846fed53d...@pobox.com
Re: Is vrms really still a Virtual Richard M. Stallman?
Quoting Florian Weimer ([EMAIL PROTECTED]): ["debian-legalint":] > I don't think this is a good idea. "non-free" doesn't mean "illegal". So, "dfsg-lint", maybe. -- Cheers, * Contributing Editor, Linux Gazette * Rick Moen -*- See the Linux Gazette in its new home: -*- [EMAIL PROTECTED] <http://linuxgazette.net/>
Re: Users, groups, rights and apache please advice
Quoting Brian May ([EMAIL PROTECTED]): > On Thu, Oct 09, 2003 at 05:01:31PM +0200, Thomas -Balu- Walter wrote: > > IIRC maximum number is limited to 32 groups for a single user. Just in > > case you are going to add more :) > > What happens if you exceed this limit? We encountered this at $FIRM, a lamentable proprietary software concern that was formerly a fairly decent Linux hardware company. The 32-user limit was at the time embedded in both the 2.4.x kernel series and in glibc. Attempts to assign group memberships beyond that number just don't work. I know that it was being removed from the 2.5.41 kernel code, last year, in anticipation of its removal from glibc. I don't know if the glibc people caught up with that, or not. Note: There are complications for NFS and NIS if group size gets big. (One might argue that POSIX ACLs are a better solution?) -- Cheers, * Contributing Editor, Linux Gazette * Rick Moen -*- See the Linux Gazette in its new home: -*- [EMAIL PROTECTED] <http://linuxgazette.net/>
RFA: sbuild -- Tool for building Debian binary packages from Debian sources
Missing X-Debbugs-CC? - Forwarded message from Rick Younie <[EMAIL PROTECTED]> - From: Rick Younie <[EMAIL PROTECTED]> Date: Mon, 28 Apr 2003 21:00:39 -0700 To: Debian Bug Tracking System <[EMAIL PROTECTED]> Subject: RFA: sbuild -- Tool for building Debian binary packages from Debian sources Package: wnpp Version: unavailable; reported 2003-04-28 Severity: normal I request an adopter for the sbuild package. The package description is: sbuild is part of a suite of programs -- consisting of wanna-build, buildd and sbuild -- written by Roman Hodek and used by most architectures to build binary packages from source packages. buildd schedules work from information it gets from wanna-build; sbuild does the grunt-work. . sbuild can do its work in chroots so both stable and unstable environments can be used on the same machine. Useful for, say, building the latest unstable packages against stable library versions. And by keeping only essential and build-essential in the chroots, you can find the correct build dependencies for a package. I don't have time maintain sbuild properly; it deserves better. The adopter should be a developer to check out the sbuilds on the various buildd machines for improvements (they all vary a bit) and should have decent bandwidth to fix the chroot building. There are a debootstrap scripts for that at http://buildd.debian.org/buildd.chroot (for woody) http://buildd.debian.org/buildd.chroot.sarge (for sarge and sid) It's probably time to make sbuild strictly a user tool and forget about compatibility with buildd as it's too much of a headache. Only a couple of us were using it with buildd anyhow. Rick -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux def 2.4.20 #1 SMP Tue Jan 28 22:05:38 PST 2003 i686 Locale: LANG=en_US, LC_CTYPE=en_US - End forwarded message -
mac parts?
Mike Shuey has donated a Mac Quadra 950 that's been pumping out packages for a few months as bruno.fmepnet.org for the m68 port. He has (most of) a similar machine that he can hook up next to it that still needs a few gig narrow SCSI disk and matched sets of 30-pin ram. If someone can loan some parts to the cause it will speed up the process. Mike's email is [EMAIL PROTECTED] One of the m68k build daemons is awaiting a new connection, another has chronic connectivity problems and a third is going offline soon so this machine will likely be needed. Rick --
Re: NNTP gateway to Debian lists
[EMAIL PROTECTED] wrote: > > I don't like mailing lists at all so I'm looking for a way to read the > debian lists using Slrn. Leafnode does not support mailing lists, so I'm > forced to use an Internet NNTP server for this. My provider does not feed > linux.debian.* so I can't use that server. I searched on GoogleGroups and > the Debian lists archive but could not find any useful server either. Only > sunsite.dk, which sucks. I miss a /LOT/ of articles. Last I heard the usenet group is unidirectional mail -> news and was a little flakey at that. Making it bidirectional would invite all the noise/spam problems that you get with usenet. You can read the groups on lists.debian.org with a browser. Or mutt threads mail well. Or if you're running your own news server (cnews is simple to set up) you can use one of the mail-to-news programs and take advantage of the news system's expire and newsreader's threading. "apt-cache search news mail gateway" shows some of those if you're running unstable (for the multiword search). apt backports to stable cleanly if you're running stable. HTH, Rick --
Re: NNTP gateway to Debian lists
Marco d'Itri wrote: > > >Last I heard the usenet group is unidirectional mail -> news > >and was a little flakey at that. > I seen no problem in the gating process. Please explain what's wrong. Yeah, cheap shot. It's been a long while since I've looked at this. > And yes, messages of morons who mail long base 64 encoded files to > mailing lists cannot be gated. I wonder what the sentiment is among developers for using some Debian dollars to hire a hit-man. I think if a couple spammers were popped, word would get around. This may be a little extreme though and some kind of technical solution might be better. Rick --
Re: Some thoughts about problems within Debian
Fabian Fagerholm wrote: > > I agree. After all, it's voluntary to volunteer. > But it should be very clear what is expected of you, and what you are > willing to contribute. At the moment, much is expected, but the > willingness can only be observed afterwards, day by day. > > Recent discussions on this and other lists are showing signs of the > debian (and possibly the free software) community wanting to change the > way development is done. Where before we had chaos and charismatic > people hacking away into the night, we now have people striving for > orderly development of mature systems. It is time not only to become > hackers of code, but also hackers of project management, hackers of > quality assurance and hackers of user interfaces. > > But fresh ideas require new participants - only it has become so much > more difficult to get involved. Not only do you have to possess almost > cs major skills to keep up, the debian project is so large that it is > very difficult for a prospect maintainer to grasp the whole picture and > find her own place. I sense countless lurkers reading this list and > others, trying to get a glimpse of what debian is all about, and if it's > something to get involved in. I count myself as one of them. > > Think of it as getting a job at a very large company. What if you knew > nothing of the people working around you, nothing of the internal > structure of the company, nothing of what you are expected to do? There > are many able programmers and would-be-maintainers that cannot find a > place to start. > ... Great post. I hope you do find your place to start and don't get discouraged and move on to something else. I too feel there are many trying to find a way to contribute. I don't think there's any shortcut. You have to find something bite-sized that interests you -- be it boot-floppies, translation, porting.. -- find the appropriate list and look for a place to help. The internal structure you talk about...well, there isn't any. It's all little bits that fit together pretty well, mostly. Rick --
Re: Some thoughts about problems within Debian
Hi, I may have misinterpreted your earlier message. www.debian.org/devel is probably is a good place to start. http://nm.debian.org/nmlist.php for those who have managed to figure out the basics. The New Maintainer's Guide is very well written and baby-steps you through making your first package. Fabian Fagerholm wrote: > > I appreciate the frank attitude. I guess finding the right place to > start is often more of a coincidence and random trying than a conscious > decision. Maybe the best instruction to people wanting to help is "pick > a random integer and call it $bug. Go to http://bugs.debian.org/$bug and http://base.debian.net and http://standard.debian.net have been mentioned. w.d.o/devel has other links. Fix a bug & send in the diff. It's not a simple process and you'll no doubt get it wrong the first time. There are lists and IRC channels for help -- new-maint, #debian-devel if you're in the NM process. > see if you found something you can help with. If so, do it. If > neccessary, educate yourself by reading documentation. Repeat." > > > The internal structure you talk about...well, there isn't any. > > It's all little bits that fit together pretty well, mostly. > > I guess it all becomes clear at some point. I still maintain that it > could be presented in a more understandable way, however. I don't look on this as a barrier to entry as much as a sort of minimal aptitude test...figuring out where (some of) the pieces fit and where you can contribute. My earlier reply was more about those who have done their homework and jumped through the hoops and still sit. The current NM process seems to filter mainly for patience. (Or did; I've only recently rejoined the list.) I've misrepresented you no doubt by my selective quoting. Sorry about that. But if you don't think the current documentation and links are easy enough to find, how about putting together something that makes it clearer, maybe with the help of some of the guys on new-maint? Once you join Debian you'll forget how hard it was to get started like the rest of us and spend your time on things that interest you more. Rick --
Re: please rebuild gtkmathview 0.3.0-4 on hppa, m68k and arm
Stefano Zacchiroli wrote: > Package gtkmathview (version: 0.3.0-4) hasn't been rebuilt on hppa since > Wed 13 March and on m68k since Wed 27 March, could someone please > trigger the rebuilt of it on these archs? On m68k it's waiting on gmetadom. It's easier to see what's going on at bruno.fmepnet.org. Rick -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the Debian Pure Blends Team
Quoting Daniel Dickinson (csh...@brucetelecom.com): > On Fri, 20 Mar 2009 14:40:24 +0100 (CET) > Andreas Tille wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Hello, > > > > as you might have noticed the effort formerly known as Custom > > Debian Distributions was renamed to Debian Pure Blends (see > > [1] for the reasons). This process is now regarded as finished. > > > > The Alioth project was moved to > > > > http://alioth.debian.org/projects/debian-blends > > This link reports 'Invalid Project' Correct link appears to be: http://alioth.debian.org/projects/blends/ -- Cheers, Crypto lets someone say "Hi! I absolutely definitely have Rick Moena name somewhat like the name of a large familiar r...@linuxmafia.com organization, and I'd like to steal your data!" and lots McQ! (4x80) of users will say "OK, fine, whatever."-- John Levine signature.asc Description: Digital signature
Proposal for stage-1 boot loader for use with SecureBoot [Re: [Long] UEFI support]
The fundamental problem we must solve is allowing the *user* to securely choose which OS she wants to install. Whether that OS follows thru and verifies all its parts is between the user and the person or group who provided the OS (could be the user, herself, of course!) We need a "stage-1" boot loader, signed by somebody trusted (FSF? SFLC?) with a key that will be recognized by the SecureBoot BIOS. This is an un-changable binary blob, so it can't be GPL (is this a problem?) but at least we can publish the source code, and anybody who wants to can verify that the blob is the result of compiling that source code. Whoever did the original signing can publish signed updated blobs in the future if changes become necessary or desirable. Hopefully, the limited functionality in the original version will be enough to get the job done so changes will be infrequent to non- existent. The stage-1 boot loader blob has the following functionality: 1) It can ask the user to enter a password, which it hashes into a the private half of a cryptographic signing key. Without the user's password, the private half of the key is unknowable. The public half of the key is, of course, freely available and should be cached in some kind of write-once/read-many memory if such is available (You can buy USB keys with a physical write-enable switch. Would something like that be good for this application? Does the UEFI API have a way of stashing such a thing along with its keys?) 2) It can keep a cache of (location, description, signature) triplets for stage-2 bootloaders in some place where it can be retrieved without further user intervention. Would the boot block be a good place? The cache will be publicly readable -- and writable -- so it needs to be signed by the private part of the user's key, and verifiable with the public part of that key. 3) When it's loaded by the UEFI bios, it reads the cache and verifies the signature using the public part of the user's key. Based on keyboard input (or lack thereof, after a short timeout) it picks one entry from the cache and loads that stage-2 boot loader, verifies its signature, and pass control to it. 4) Other things the user can do if she has access to the keyboard before the time-out expires: a) Request a menu of, and choose one of, the available stage-2 boot loaders, taken from the description part of the cached triplets. b) Designate one from the above menu as the "default" for future boots if the timeout expires. c) Request to add a new entry to the stage-2 boot loaders cache, providing the location and description. It then requests and verifies the user's password and uses it to compute the signature of the new stage-2, then sign and write the modified cache. d) Request deletion of a cache entry. It then requests and verifies the user's password and uses it to sign and write the modified cache. e) Request to change her password, providing the old password as verification of her right to do so. f) Request to chain-load another stage-1 boot loader from removable media. This program would need to be signed with one of the keys known to the SecureBoot BIOS, or, if not, have explicit permission to be loaded from the user at the keyboard. This is the rat-hole we provide for installation of new OS's. Would this work? What have I missed? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/38b1a676-40d9-4c0d-9dbb-6b50b533e...@pobox.com
A modest proposal [Re: CD1 without a network mirror isn't sufficient to install a full desktop environment]
On Sep 10, 2012, at 11:08 AM, Karsten Merker wrote: I do not think that making the default desktop environment dependent on the type of the installation medium would be a good idea; that would cause much confusion IMHO. This was discussed years ago, but (with some trepidation) I'd like to bring it up again... Why can't the user be allowed to choose the desktop environment she prefers (if any) at "tasksel" time? If there is not any "preferred" DE, there's no need to clutter up CD-1 with packages that apply to only a single DE -- CD-1 would only need to provide a basic environment and could be kept small; maybe almost as small as the netinst CD. If it makes sense to provide a separate CD for Gnome, KDE, xfce/ lxde... then let that be CD-2a (Gnome), CD-2b (KDE), CD-2c (xfce/ lxde)... but without the basic install stuff (it's already on CD-1), leaving more space for the DEs to grow into... Just a thought... Rick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/97d3e332-ff53-4e7d-98f4-5b6ab60d2...@pobox.com
Re: Needed input from Australian users and developers:; choosing timezones for Australia in D-I
On Mar 23, 2011, at 1:42 PM, Joey Hess wrote: Rick Thomas wrote: For what it's worth, the timezone database (as evidenced by, among other things, the output of the "tzselect" command) is organized mostly in terms of country/city rather than country/larger- geographical-area. This is also largely misunderstood, as often two cities with different entries in the database observe identical time zone rules today. In some cases they only differed for a week a century ago. I would not consider the TZ database or tzselect anything resembling a useful UI, although it is an interesting exercise in completism. -- see shy jo, still in his own timezone! In that case, whatever d-i does for UI, it needs to warn folks that it may be necessary to do a "dpkg-reconfigure tzdata" after the install, if they care about getting the details exactly right of that week in 2006 when Australia hosted the Commonwealth Games. Call us crazy if you like, but some of us do care. Rick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4397de66-4e61-4f91-a081-7cf296917...@pobox.com
Re: /opt/ again (was Re: FreeBSD-like approach for Debian? [was: ...])
"In article <[EMAIL PROTECTED]> you wrote:" > > You're also almost as good as stating that one cannot > backup /etc, toss in a spare drive, do the install off a local > NFS/FTP mount (less than 2 hours by a long shot) throw /etc > back in (no need for a tape even, whatta concept!) and then get > the rest of the data from there in under 2 hours. I'm digging through my newsspool & dejanews for an answer to this and can't find it. If the docs mention it I can't find it. Can you help? You mention a local NFS mount for installing. I'm doing some practice installs from scratch as practice for a local (Vancouver) installfest next weekend and the install procedure mentions NFS as an option for installing the base system. Is it possible to NFS mount ftp.debian.org for this? Or is the option only there for mounting local file systems? If it's possible to remotely mount, could you tell the incantation? I must have tried pretty much every one except the right one. Thanks. Rick -- [EMAIL PROTECTED] [EMAIL PROTECTED] http://vcn.bc.ca/~rick
Re: IMPORTANT: Do live Debian images have a future?
I'm a user and a tester, not a dev, and I know nothing (and don't want to know anything) about the personal politics between Debian developers. So that's all I'll say on that subject. To Steve's original point: First, a big THANK YOU! to Steve for taking this job on. I, for one, an grateful. I use Debian a lot, but I'm only an occasional user of the Debian Live images. But when I need them, I need them. And when I need them, I want them to just work. If having them there and working when I need them means I have to add them to my list of things to test and report on, I'm willing to make that investment. Please add me to your "testers" list. Thank you, Rick PS: On a related topic: What I think would be really cool, would be Debian Live images for some of the ARM architectures. Something I could dd to a USB stick and boot right away when I get a new box in for testing. Even cooler would be the ability to use that self-same live image to install Debian after the testing phase was over. > On 27 June 2017 at 00:08, Steve McIntyre wrote: > >> [ Note the cross-posting... ] >> >> >> If our live images are going to be good enough to meet the standards >> that Debian users deserve and expect, we need *consistent*, >> *sustained* involvement from a lot more people. Please tell me if >> you're going to help. If we don't see a radical improvement soon, I'll >> simply disable building live images altogether to remove the false >> promises they're making. >> >> [1] https://get.debian.org/images/release/current-live/amd64/iso >> -hybrid/#issues >> >> -- >> Steve McIntyre, Cambridge, UK. >> st...@einval.com >> "...In the UNIX world, people tend to interpret `non-technical user' >> as meaning someone who's only ever written one device driver." -- Daniel >> Pead >> > >
Re: IMPORTANT: Do live Debian images have a future?
On Jul 3, 2017, at 8:53 AM, Steve McIntyre wrote: > arm64 > live images are on my todo list already for the buster cycle. Great! Will they work with RaspberryPi-3? Rick
Re: Anyone using stretch/buster/sid on ARMv4t ?
How do I know if a machine is ARMv4t? I have a sheevaplug and a couple of openrd machines (one “client”, the other “ultimate”) that are still doing useful work. Are they v4t? Thanks, Rick > On Nov 5, 2017, at 1:32 PM, Adrian Bunk wrote: > > Hi, > > for the armel port in buster the question of raising the baseline came up. > > 20 years ago you could go into a shop and buy a mobile phone > with a CPU supported by the armel port in stretch. > > Roger Shimizu is doing a great job on ARMv5 hardware and I've seen bug > reports from users on ARMv5 hardware in stretch, so it is clear that > ARMv5 should stay supported (and of course also ARMv6 and ARMv7). > > But while it was mentioned that there exists ARMv4t hardware that works > with current mainline kernels [1], it is not clear whether there are any > actual users left - and without users we might not even notice if the > port is broken on the baseline. > > If anyone is running stretch, buster or sid on ARMv4t hardware, > then please let us know what device and kernel you are using > and whether you intend to use buster. > > cu > Adrian > > [1] https://lists.debian.org/debian-arm/2017/08/msg00046.html > > -- > > "Is there not promise of rain?" Ling Tan asked suddenly out >of the darkness. There had been need of rain for many days. > "Only a promise," Lao Er said. > Pearl S. Buck - Dragon Seed >
Re: Anyone using stretch/buster/sid on ARMv4t ?
> On Nov 7, 2017, at 3:27 AM, Christian Seiler wrote: > > Hi, > > Am 2017-11-07 11:49, schrieb Rick Thomas: >> How do I know if a machine is ARMv4t? I have a sheevaplug and a >> couple of openrd machines (one “client”, the other “ultimate”) that >> are still doing useful work. Are they v4t? > > cat /proc/cpuinfo should do the trick. It might not show the 't' > after the 4, but it should definitely show whether it's an ARMv4 > or not. (And Debian's armel doesn't support any non-'t' ARMv4 > CPUs, so if it's ARMv4 and running Debian's armel port, it's > ARMv4t.) Thanks! It looks like my machines are all 5TE — or maybe v5l ?? In any case, not v4t. > rbthomas@client:~$ cat /proc/cpuinfo > processor : 0 > model name: Feroceon 88FR131 rev 1 (v5l) > BogoMIPS : 1191.93 > Features : swp half thumb fastmult edsp > CPU implementer : 0x56 > CPU architecture: 5TE > CPU variant : 0x2 > CPU part : 0x131 > CPU revision : 1 > > Hardware : Marvell Kirkwood (Flattened Device Tree) > Revision : > Serial: All three show the same output. Enjoy! Rick
Re: Vale, Ian Murdock (1973-04-28 ??? 2015-12-28)
Bradley M. Kuhn published an eloquent and elegaic 'Requiem for Ian Murdock' on his blog at http://ebb.org/bkuhn/blog/2015/12/30/ian-murdock.html. As it is CC BY-SA 3.0 US licensed, I'm posting it here. Requiem for Ian Murdock Wednesday 30 December 2015 by Bradley M. Kuhn I first met Ian Murdock gathered around a table at some bar, somewhere, after some conference in the late 1990s. Progeny Linux Systems's founding was soon to be announced, and Ian had invited a group from the Debian BoF along to hear about “something interesting”; the post-BoF meetup was actually a briefing on his plans for Progeny. Many of the details (such as which conference and where on the planet it was), I've forgotten, but I've never forgotten Ian gathering us around, bending my ear to hear in the loud bar, and getting one of my first insider scoops on something big that was about to happen in Free Software. Ian was truly famous in my world; I felt like I'd won the jackpot of meeting a rock star. More recently, I gave a keynote at DebConf this year[1] and talked about how long I've used Debian and how much it has meant to me. I've since then talked with many people about how the Debian community is rapidly becoming a unicorn among Free Software projects — one of the last true community-driven, non-commercial projects. A culture like that needs a huge group to rise to fruition, and there are no specific actions that can ensure creation of a multi-generational project like Debian. But, there are lots of ways to make the wrong decisions early. As near as I can tell, Ian artfully avoided the project-ending mistakes; he made the early decisions right. Ian cared about Free Software and wanted to make something useful for the community. He teamed up with (for a time in Debian's earliest history[2]) the FSF to help Debian in its non-profit connections and roots. And, when the time came, he did what all great leaders do: he stepped aside and let a democratic structure form.[3] He paved the way for the creation of Debian's strong Constitutional and democratic governance. Debian has had many great leaders in its long history, but Ian was (effectively) the first DPL, and he _chose_ not to be a BDFL. The Free Software community remains relatively young. Thus, loss of our community members jar us in the manner that uniquely unsettles the young. In other words, anyone we lose now, as we've lost Ian this week, has died too young. It's a cliché to say, but I say anyway that we should remind ourselves to engage with those around us every day, and to welcome new people gladly. When Ian invited me around that table, I was truly nobody: he'd never met me before — indeed no one in the Free Software community knew who I was then. Yet, the mere fact that I stayed late at a conference to attend the Debian BoF was enough for him — enough for him to even invite me to hear the secret plans of his new company. Ian's trust — his welcoming nature — remains for me unforgettable. I hope to watch that nature flourish in our community for the remainder of all our lives. [1] http://ebb.org/blog/2015/aug/17/debian/ [2] https://www.debian.org/doc/manuals/project-history/ch-intro.en.html#s1.1 [3] http://www.linuxplanet.com/linuxplanet/editorials/4959/1 RM note: Brad also invites comment at https://identi.ca/bkuhn/note/EXXzcb0hT6Ob43gOcYaQYA
