Re: New LILO for >1024 cylinders in potato, PLEASE!
On Fri, Mar 10, 2000 at 10:46:44AM -0800, Ben Gertzfield wrote: > According to lwn.net, there is a new version of LILO just released > that finally, finally adds an option to fix the horrid, dreaded > LI problem on hard drives with >1024 cylinders. > > http://www.lwn.net/2000/0309/a/lilo.html > > Can this make it into potato? :) > > Ben > > -- > Brought to you by the letters Y and M and the number 5. > "You have my pills!" > Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ I think this is almost a necessary, unfortunatly what if there are unexpected bugs in it? the >1024 thing is great, but what if there is a fatal bug that we dont notice imidiatly ... I think this should go in, but should have extensive testing first, in a short time if possible. Erik Bernhardson [EMAIL PROTECTED] -- It is better to remain silent and be considered a fool, than to speak and remove all doubt. -- Mark Twain pgphVlmqrx5pT.pgp Description: PGP signature
Re: Danger Will Robinson! Danger!
On Wed, Mar 15, 2000 at 12:46:39AM +0200, Ari Makela wrote:
> John Lapeyre writes:
>
> >Maybe you find it easy. But you are relatively elite in debian
> > knowledge.
>
> I'm not a beginner. I even earn my living as an unix
> administrator. But I'm certainly not a unix guru.
>
> >I got a notebook two months ago. The video, sound, and pcmcia are
> > not supported by slink.
>
> Are these really a big problem? During the summer same happened to me and
> what I did was following:
>
> I installed Slink. I went to a local xfree86-mirror and got SVGA
> xserver version 3.3.5 which supports NM2200 chip. I dropped it in
> place of the distributed. Yes, that's a wrong way of doing things but
> it has always worked for me. I didn't know about http://www.debian.org/%7evincent/ > at the time (BTW: this is a
> problem, people don't know about these unofficial updates).
>
> Sound support for esssolo-1 came when I compiled 2.2-kernel. There
> are instructions what needs to be updated on Debian web site.
>
> PCMCIA is not needed for installation and it can be compiled later. It
> doesn't have to work at first.
Ever installed on an older laptop? I spent 3 days trying to install on my
laptop because it didn't have a CDROM, so i had to get base off of the
network(and i know that i could put it all on floppies, but i have a really
hard time finding 1 good one to boot off of, and I know i'm not alone).
>
> I feel that anyone who tinkers with GNU/Linux - or with any unix or
> unix clone - should be able to do above things if documentation is
> available. Documentation in one place instead of several web pages
> which are hard to find. I've not seen such a document. Is it that I
> haven't found it or is it non-existent? If latter is true I could
> write some kind raw version if others agree with me on this.
>
> >Maybe people who can't do that are lazy and stupid and don't
> >deserve Debian.
>
> And you say you don't use sarcasm? :)
>
> >People can't ship stable Debian on new machines, but they can ship
> > RH and SuSE.
>
> I agree that many users cannot replace the kernel on the rescue disk
> like I did. One needs some knowledge and also a Linux system which
> most people don't have. But it's not so hard that it might sound,
> either. It's enough that it works on one system, it doesn't have to
> result a system where every device works.
>
> I feel Athlon is the most important problem. As far as I remember
> this is the only case where it has been impossible to install Debian
> on an Intel system if we don't count very exotic hardware.
>
> > (I don't want to attack with the sarcasm, just to make a strong point).
>
> It seems that I am not able to write what I think so I try again:
>
> I don't deny that there are problems for some users but in most cases
> "stable is too old" problems can be solved relatively easily. This
> could be made easier for inexperienced people if two things would be
> done:
>
> - if it would be easier to find the unofficial updates for
> xfree and Gnome.
> - as simple and short documenation as possible where it is
> told how Debian is updated.
>
> If the development cycle were faster there might not be enough time to
> test enough. That's what I'm afraid of. The pool system might be a
> solution.
>
> --
> #!/usr/bin/perl -w -- # Ari Makela, [EMAIL PROTECTED],
> http://www.iki.fi/hauva/
> use strict;my $s='I am just a poor bear with a startling lack of brain.';my
> $t=
> crypt($s,substr($s,0,2));$t=~y#IEK65c4qx AR#J o srtahuet#;$t=~s/hot/not/;my
> @v=split(//,$t);push(@v,split(//,reverse('rekcah lreP')));foreach(@v){print;}
Erik Bernhardson
[EMAIL PROTECTED]
--
It is better to remain silent and be considered a fool, than to speak and
remove all doubt.
-- Mark Twain
pgpazI9KfX4xJ.pgp
Description: PGP signature
Re: Bug#60399: crashes on installation
On Sat, Mar 18, 2000 at 01:12:28PM +1100, Brian May wrote: > >>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes: > > Brian> I will try it on another 2.2.14 system ASAP. > > It worked, as such, it might be a bug specific to Linux 2.2.13. I doubt it, because i installed on a machine ... and i booted from 2.3.49 to do the final parts of the install, and man-db failed in the same way.. along with some other program, a text mail program, but i forget which. > -- > Brian May <[EMAIL PROTECTED]> > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- Erik Bernhardson [EMAIL PROTECTED] -- It is better to remain silent and be considered a fool, than to speak and remove all doubt. -- Mark Twain pgpLUZvckeN6m.pgp Description: PGP signature
Re: Novell: NDS eDirectory for Linux
On Tue, Mar 21, 2000 at 09:59:49AM +0100, Andreas Tille wrote: > On Tue, 21 Mar 2000, Lauri Tischler wrote: > > > Load NLDAP.NLM on one of your Netware servers. > > I did just that and wrote some WEB-applications with php3 to get phone and > > mailinggrop information from NDS. > Please excuse my ignorance about LDAP. I really don't know how it works > and how can I profit from it. > > My intention is to enable normal Novell users access to linux boxes > without triggering my /etc/passwd with the Novell user accounts. I > hope that there is any simple possibility for Netware users to get > a login on some (one to three) Linux boxes with their Novell password > and home directory on the NCPFS mounted Novell volume. This would > save my time to install NIS and adding and removing users on my > Linux boxes. > > May be I'm dreaming of something which is not possible, yet. > > Kind regards > >Andreas. Well, i know that you can get usernames/passwords through ldap using a pam module .. libpam-ldap probably. So if you can get the users names and passwords over this ldap interface then it should be completely possible As for the file mounting, i'm not sure ... i know there is stuff in the kernel for it, but i've never used it (and like samba it probably needs some help from userland applications). Erik Bernhardson [EMAIL PROTECTED] -- It is better to remain silent and be considered a fool, than to speak and remove all doubt. -- Mark Twain pgp0Z1Lc3pXJH.pgp Description: PGP signature
Re: System sees only 65M of memory
On Wed, Aug 30, 2000 at 05:56:52PM -0600, Art Edwards wrote: > I just purchased two Athalon-based systems, each with 768M of ram. > However, under debian (potato runnin kernel 2.2.17) the OS sees only 65 > M of memory. I have tried to use the append command > > mem=768M > > but it still sees only 65 M? > > Does anyone have any ideas? > > > -- > Arthur H. Edwards > 712 Valencia Dr. NE > Abq. NM 87108 > > (505) 256-0834 > I haven't tried on my athlon, but i've heard that grub will autodetect your ram correctly, and pass the info to the kernel. Still doesn't help with the fact that mem= isn't working for you, but its a start :) Erik Bernhardson [EMAIL PROTECTED] -- It is better to remain silent and be considered a fool, than to speak and remove all doubt. -- Abraham Lincoln pgpHlRlsYNMgQ.pgp Description: PGP signature
KDE2 - nice demolition job ...
Hi, I just can't keep my mouth shut about this any longer and the unnecassary divisions (read demolitions) of KDE packages are the last straw: I've been tracking the development of KDE2 for months and running it quite successfully using "unofficial" debs (cheers to the folks at kde.tdyc for bucking authority!) ... it was fine and coming along very nicely. Was. And all it took was a week or so in the hands of a ridiculously complicated and politically petty beuracracy like this and being subjected to an absurdly complex re-packaging scheme to completely destroy a perfectly useful desktop. First kdm goes, next update strange browser crashes commence, next update the whole desktop is TOTALLY USELESS and no longer even works for ANYTHING! On top of which it is now slated for an unknown eternity in unstable ... well, now that its broken I guess that's where it belongs. Nice job. I think this is a pretty blatant example of the obvious failings of an aging and inflexible beuracratic empire that cares more for its protocols and levels of "authority" (these things are oh so important, "not trivial matters" at all ...) than making a good distribution anymore. Debian has become an elitist club and it angers me because it is potentially the finest OS available - but I am losing faith in that potential ever being met. And that is very sad. I realize that this does not apply to many Debian developers - but if the general attitude and atmosphere does not change here Debian will drift into obscurity and forfiet the contributions that many talented people would gladly have donated to the cause. The general disdain of "newbies" and atmosphere of thinly veiled contempt (RTFM! ... uh, right; what manual?) combined with an inflexible hierarchical beuracracy are dragging this project into the mud right when it should be taking off with the rest of the linux world. But no, Debian is spending its time arguing about minutia and complaining about how there is too much to be done while keeping "outsiders" waiting for months to even recieve acknowledgement of reciept of application to voluteer (Oh, Yes, You too can help with the Debian Project - just jump through these thirty complicated hoops and apply to be a "developer" and wait around for a year or so and then if we think you're cool ... garbage, why bother?). I'm sorry, being a "Debian developer" does not make one inherently superior to other developers or persons that just use software, nor does it make one's opinions about Debian development more valid - the end user is the one that knows the most about what a piece of software needs to be able to do. And without and end user your software is not superior, it is just useless bits taking up storage. Arrogance and conceit are the signs of decay. And they certainly _not_ conducive to enthusiastic community participation and the resulting high quality software, which was the whole point of the free software movement and the creation of the Debian Project - or was it? Think about it. And try not to prove my point with condescending flames - its not attractive. -- Erik Winn -- Never underestimate. Period. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: KDE2 - nice demolition job ...
On Mon, 11 Sep 2000, erik wrote: > On Tue, 12 Sep 2000, you wrote: > > > You _do_ realize that the same guy who packaged it for kde.tdyc _is_ the > > same guy who is packaging it for Debian proper? > > Yep, I do -and it worked great before he had to repackage it. You could > have simply copied them from tdyc and had done with it. > > > > > That's not true at all. So far, I'm in the new maintainer queue, and have > > a number of offers from sponsors to upload packages whenever they are > > ready. If you want to package something, at this point, yes, you should > > get into the queue, but finding a sponsor isn't very hard. > > Didn't work for me. > > > and finally c) you really come off whiny. If you don't like the manual, > > I'm sorry if honest criticism sounds "whiny" to you. > > > help write a better one. If you don't like the way Debian deals with new > > users, help change it, by setting an example. > > I have written some - in fact I sat down and wrote a whole system to help > organize and automatically produce a documentation UI specfically for > debian packages; it was summarily dismissed without, as far as I can tell, > anyone even looking at it. > > > another happy Debian user, > > Seth > > Actually, I am too - otherwise it certainly wouldn't be worth it to > subject myself to this inevitable barrage ... :} > > Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: KDE2 - nice demolition job ...
On Tue, 12 Sep 2000, you wrote: > uhh, FYI...the same person who did the package on kde.tdyc.com is the > same and only person doing the packaging for Debian. The fact that > I finally had time to work on the *MANY* requests to break down the > packages and the fact that KDE *IS* beta shouldn't cause anyone to > start pointing fingers at anyone else. Ivan, I want to apologize to you personally - I fully realize that you are doing the work on KDE and ( as I mentioned before) I think you are doing a great job. I have been running KDE from the other site and believe me this was not targeted at you - if anything quite the opposite. The point was that overbearing regulations had prevented a smooth (and easy) integration of KDE. > It's kinda funny that I have not seen any bug reports (on the kde.tdyc.com > mailing lists nor on the Debian BTS) about your problems. The current Actually, the broken update happened about 20 minutes before said rant - the other bugs I chalked up to beta. xerrors is about 50K and I have not really figured out what is relevant yet - although I suspect the new non-ssl linking scheme ... BTW, the rant has been a long time coming - this just keyed it. Purpose of Rant: Stir up the coals ... Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: KDE2 - nice demolition job ...
On Tue, 12 Sep 2000, Seth Cohn wrote: > > BTW, the rant has been a long time coming - this just keyed it. > > > > Purpose of Rant: Stir up the coals ... > > Hey erik, grow up. Debian has enough flamewars without you stirring the > coals intentionally. Yes, it does - I still think the points were worth bringing up. Sorry if they aren't important to you; if you're not interested don't waste your time. And, um, about growing up ... chances are pretty good I'm older than you :). > Seth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: KDE2 - nice demolition job ...
On Tue, 12 Sep 2000, you wrote: > > FYI and to anyone else reading. The direction I have gone with the > packaging of KDE for Debian has not changed since day 1. I have focused > on conforming to Debian policy (which I have mostly done already) and > making the user base happy (breaking down of the packages) which is what > I am focusing on now. > > I have had over the period of time that I hosted these packages on > kde.tdyc.com > had a crapload of broken packages. The ol' "it work's here" factor seems > to work just as well today as it did back then. Until upstream settles down > a bit and the source of problems focus's more on how I put them together we > will still see bugs like the ones you see. > > You should see the list of porting issues I'm dealing with...up until now > the KDE2 stuff hasn't been looked at beyond i386 and powerpc (for woody) and > it shows. :) So I'm doing alot of work with that. > > Not once has any other Debian developer told me what to do (at least not > since Branden told me to fix kdm from breaking xdm like almost 2 years ago). > The extent that any other person has done have been requests...and I treat > them as I do requests I get from folks like yourself. Point taken. I retract my critique of this instance - it just looked like that was what was happening. > > the other bugs I chalked up to beta. xerrors is about 50K and I have not > > really figured out what is relevant yet - although I suspect the new > > non-ssl linking scheme ... > > This is a possiblity...I haven't tested this whole thing alot. But, since > your using woody, you are a beta tester and thus are my guinnee pig! muhaha I have it on two (other) machines - one has not yet been updated from the first beta4 debs. I'll see if I can get anything more specific for you. I hac to leave during the upgrade and missed the errors. There is also a depends conflict between kdelibs3 (-dev?) and kdeutils-dev that means you must force the selection in dselect (hits an endless depends loop). Also, qt2.2-dev causes a dselection of mesag-glide and friends that leads to the driver for voodoo cards; this is very difficult to get out of (you must mark the Utah 3D library) and if the glide/voodoo driver gets installed on a non-voodoo machine its kind of messy ... Specifics on linking I will try to look into - I actually have KDE sources on hand so I may try the build with your debian/rules and see if anything sticks out. > Well, I thank you for the high blood pressure and the doctors >visit. :) Sorry about all the racket - I just really had to get it off my chest, and, hey, its good for the circulation ;-]. Erik PS. I have offered to help with KDE before and the offer still stands. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: KDE2 - nice demolition job ...
On Wed, 13 Sep 2000, you wrote: Thank you for a cool response - I was really hoping that would eventually happen. I realize I stirred up a hornets nest; I did it intentionally because otherwise nobody seems to notice and I think that at least some of what I originally wrote (goading aside) is important. You happened to pick out probably the most practically important one with the issue of the protocols for accepting new voluteers. There are some other points in there that are more abstract political points that don't have simple answers - but they are the sort of thing that really won't change at all if they remain hidden; perceptions are not always apparent to the percieved. I have been watching people turn and be turned away for quite awhile now and I really thought it was worth a little trouble to point it out. I _like_ the debian project - why else put myself up for attack to point out an embarressing fact? Really much easier to just go to bed ... < very valid points (alpha etc.) excerpted> > To go on and on about the organisation of Debian and its shortcomings (in > your opinion) benefits no one and alienates those who may want to listen > to your ideas otherwise. I always think it's a shame when things digress > to the level that this exchange has taken. If possible, can you (and > everyone angered by the original message) take a deep breath and > relax? I, for one, would like to hear some rational ideas for solutions > for the problems that you've encountered. Perhaps, then, we can learn > what we can, implement what we think will work, throw out what we think > won't, and put this behind us so we can get some more work done. Exactly. This is in fact the purpose of voicing opinions in an open forum. Personally, I would like to make one proposal - I hope other people will have others but an obvious practical problem is the process of accepting volunteers; its clearly a bottleneck: a. Assign more people to process applications - kind of self-explanatory. b. Establish at least two teirs of contribution - people who are interested in helping with less technical aspects need not be subjected to the same screening process as package maintainers. So if, for example somebody says "hey, could I help with paperwork or the website or something ?" they can be easily accepted to work on something. Voluteering should not be a full time job. c. (optimally) Rewrite the pages that explain how to apply and give a clearer and more complete description of tasks available and what level of expertise each requires. d. (optimally) simplify the protocols for applying. Maybe we can start a constructive discussion now. > I'm sorry that the new maintainer process is such a headache. While I > have nothing at all to do with NM (none whatsoever), I will offer an > apology for any hassles that you've encountered while in the process. It > can be a mind-numbing experience, from what I hear, and one that's been > the point of endless arguments and flame wars in the past. On behalf of others ( and myself) I thank you for the kind words too - but really lets hope this gets something moving :). > > > I have written some - in fact I sat down and wrote a whole system to help > > > organize and automatically produce a documentation UI specfically for > > > debian packages; it was summarily dismissed without, as far as I can tell, > > > anyone even looking at it. > > I'd be interested in looking at it. Honestly, this is the first I've > heard of such an effort. hmmm, er, shit, well i hope this doesn't look like a pr scam now ... but, anyway you can grab a .deb from unilinux.sourceforge.net; just go in the anonymous ftp, there is a package called ddoc-0.4.2_all_.deb (i think)... newer than the release ... its in development and right now it thinks it depends on deb-make _and_ debhelper ... mumble, mumble ... better go to bed now ... Erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Linux Progress Patch for Debian available!
On Sun, Dec 31, 2000 at 09:16:33PM +0100, Bernd Eckenfels wrote: > On Sun, Dec 31, 2000 at 09:12:44PM +0100, Raphael Bossek wrote: > > for all of you looking for a graphical start screen, this is the right > > patch. I've modified it a little bit > > so more init scripts are supported and a additional patch against the > > latest linux-2.4.0-test12 is part of > > this tarball too! > > AFAIK there is a problem with this patch since some of the copyright > messages of the drivers are not displayed anymore. since some of them > require the Copyright announcement, this is a violation of the license. As > far as I know that was the reason for not putting that patch into the > kernel, long ago. That patch has the ability for startup scripts to display messages to the screen (for such things as "Initializing network", "Initializing Sound", etc. I dont see why the same thing couldn't be used by the kernel drivers. > > Greetings > Bernd > -- > (OO) -- [EMAIL PROTECTED] -- > ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ > o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE > (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- Erik Bernhardson [EMAIL PROTECTED] -- It is better to remain silent and be considered a fool, than to speak and remove all doubt. -- Abraham Lincoln pgpoO7aGdA06t.pgp Description: PGP signature
Re: bugs + rant + constructive criticism (long)
On Tue, Jan 02, 2001 at 08:53:23AM +0100, Bernd Eckenfels wrote: > On Mon, Jan 01, 2001 at 11:06:18PM -0800, Erik Hollensbe wrote: > > And why are packages being REMOVED (lib-pg-perl for example) when I dist > > upgrade? > > Because thats what dist- stands for. If you dont want to remove conflicting > or sperseeded packages, then dont use dist-upgrade but upgrade. > > > apt-get and it's kin need more simple getopt-style flags that allow > > overriding of certain things, mainly conflicts. Also, an option to > > actually view what's being upgraded before you download 250 packages that > > are only going to break your system would be nice as well. > > you mean -u? > > i use "apt-get -ufm". > > But I agree whith you, that essential packages like perl should be checked a > bit more before they shoot you in the foot, but those days are gone! since > they wont pass unstable->testing anymore. So, just dont run 'sid' but woody > and you are fine. This worries me a little. With testing now in, it seems that packages will only get 1% of the testing they used to before going into a "semi-stable" set of packages. Personaly i think that if your competent enough to fix your own system, you should consider following sid to help in the testing. So many people are using testing instead of sid i'm just a little afraid its not going to get much testing at all. > > Greetings > Bernd > -- > (OO) -- [EMAIL PROTECTED] -- > ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ > o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE > (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- Erik Bernhardson [EMAIL PROTECTED] -- It is better to remain silent and be considered a fool, than to speak and remove all doubt. -- Abraham Lincoln pgpKCdBeDeTWn.pgp Description: PGP signature
Re: What is wrong with kde2.1 and unstable ?
On Sat, Jan 06, 2001 at 03:27:18PM -0700, Ivan E. Moore II wrote: > On Sat, Jan 06, 2001 at 03:46:54PM +0100, Michael Meding wrote: > > Hi all, > > > > as of three days ago, every attempt to do a dist-upgrade tries to uninstall > > almost every kde package. What is wrong there. > > > > Maybe the package maintainer knows ? > > no clue...I don't use apt to upgrade. :) Your not alone tho, there is a > existing bug report on this (#81365)...so any help you can give me to track > down what's going on would be appreciated. On all the boxes I have access > to I use dselect to manage my package list so I do know that dselect can > handle > whatever is going on. > > Ivan > It has to do with the task packages. if you remove the following: task-kdegames task-kdegraphics task-kdepim task-kdetoys task-kdeutils task-koffice it upgrades just fine. I'm not sure what exactly the depend on that cant be installed, that blocks everything else, but at least its a start. > -- > > Ivan E. Moore II > [EMAIL PROTECTED] > http://snowcrash.tdyc.com > GPG KeyID=90BCE0DD > GPG Fingerprint=F2FC 69FD 0DA0 4FB8 225E 27B6 7645 8141 90BC E0DD > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > -- Erik Bernhardson [EMAIL PROTECTED] -- It is better to remain silent and be considered a fool, than to speak and remove all doubt. -- Abraham Lincoln pgp4mh3SDl2nc.pgp Description: PGP signature
Re: better /etc/init.d/network
On Sun, May 16, 1999 at 10:15:48PM +0200, Massimo Dal Zotto wrote: > Hi, > > I have written a generic network interface management command, net, which > can be used to start/stop/show/configure network interfaces, and a smarter > replacement for the /etc/init.d/network script. > > The net command makes use of configuration files stored in /etc/network/ > which contain the various interface options. For example my eth0 is: > > # /etc/network/eth0 > IPADDR=192.168.0.1 > NETMASK=255.255.255.0 > NETWORK=192.168.0.0 > BROADCAST=192.168.0.255 > GATEWAY=192.168.0.1 > Howabout instead of having eth0, eth1, etc. have like home, work, etc. the files could then have an extra section, called DEVICE or something, that would be eth0, eth1, etc. It could also have multiple DEVICE sections, so that it would setup all the adapters related to that network. This would be most usefull on laptops, but usefull on desktop machines too. I know some people take their desktop machines arround with them every once in awhile(I take mine to the local LUG every other month or so). You could then add the ability to do like, net start home eth0, to start individual parts of your home network, while net stop eth0 would still disable eth0. > > The advantage is that you can now start/stop specific interfaces with simple > commands using predefined configs, while the old script could only be used > to start the entire network and couldn't stop or restart it or part of it. > > The new /etc/init.d/network script just calls the /usr/sbin/net command, > which does all the real work, with the proper args, just start or stop, and > all the configuration options are now stored as separate config files. > > The package can be installed over an slink system because the preinst script > can convert automatically the old network file to the new eth0 config. > > The package is available at the following location: > > http://www.cs.unitn.it/~dz/debian/net_1.0-1_all.deb > > Please have a look and see if it can added to the main debian distribution. > > -- > Massimo Dal Zotto Overall it sounds pretty good to me, something just a little better, to make things just a little easier. Erik Bernhardson [EMAIL PROTECTED] --- "[T]he last thing I want to do is spread fear, uncertainty and doubt in [the users'] minds." - Don Jones, Microsoft's Y2K Product Manager pgpUKZrgmaOeR.pgp Description: PGP signature
Re: evan leibovitch and the LPI certification tests
On Tue, May 18, 1999 at 07:24:40PM -0700, Aaron Van Couwenberghe wrote: > Ever tried mass-installing Debian? It's simply impossible -- complete, new > debian installations take at least two hours of babysitting. > > This makes debian a product VA is incapable of marketing. > > Of course, there are ways around this, like imaging drives and whatnot. But, > as someone else mentioned, it costs them money, and they have the right to > expend those resources, or not, as they choose. > > -- > ..Aaron Van Couwenberghe... [EMAIL PROTECTED] [EMAIL PROTECTED] > Berlin: http://www.berlin-consortium.org > Debian GNU/Linux: http://www.debian.org > > "...Nothing astonishes men so much as common sense and plain dealing..." > -- Ralph Waldo Emerson Well, actualy i have semi-mass installed machines...I did 30 or so machines, all i really had to do was put all the packages i wanted to install into a single dir that i nfs mounted(from the base system). i dpkg -i'd those with a program i wrote that parsed the output of dpkg, and gave the answers i specified. Now, i admit this wasn't the best way to mass install, because it did take me 10-20 minutes to get the base system installed, so this is probably too long for a company like VA, but it should be entirely possible to mass install debian, if debian would put some work twords it. Erik Bernhardson [EMAIL PROTECTED] -- "[T]he last thing I want to do is spread fear, uncertainty and doubt in [the users'] minds." - Don Jones, Microsoft's Y2K Product Manager pgp4NlrWDetnw.pgp Description: PGP signature
Some more pressure on maintainers (was: Drop testing)
Clemens Schwaighofer <[EMAIL PROTECTED]>: > On 10/25/2004 12:44 AM, Eduard Bloch wrote: > | - all the packages are out of date? Well, though luck, this is what the > | whole issue is about. We need to release faster. Faster releases are > | only feasible if enough developers are motivated. They are motivated > | if Unstable is blocked and they must care about the release instead > | of working on stuff that makes "more fun". > > fast releases with removing testing? I think you go the wrong way. > > Faster release with having something between stable and testing. > > Snapshot! > > Every half a year you make a snapshot of testing, so you have a kind of > stable release. Perhaps not 100% stable like stable, but at least not so > horrible outdated. > In addition, every package that have RC bugs should be excluded from this snapshot. IMO this would encourage maintainers to fix RC bugs asap, especially if other packages depend on theirs. ;-) Another point is the short delay of 10 days. In the last "build panic" end of august many packages wait over 10 days in build queue and enter immediatelly testing after they were build without some test period in unstable. IMO it would be better to start a wait of 20 days in unstable, if the package _reaches_ unstable. A longer delay can result in a cleaner testing. More radical is to prevent new uploads or transition of the new version into testing, if there are RC bugs open and new upload doesn't solve at least one. (to detect this, "Closes: #" must in changelog) It would encourage maintainers to fix at least one RC bug, if they would have new verion uploaded. > Seriously, most people I know run testing on their boxes. Why? It is > quite stable (Actually extremly stable compared to other "final release > distros") and very up to date. > ACK. In my understanding, testing should be everytime in shape to release a snapshot at any time. For development and broken packages we have experimental and unstable. Regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * * Linux-Info-Tag in Dresden, am 30. Oktober 2004 * Info: http://www.linux-info-tag.de * pgpfCedTpwRiJ.pgp Description: signature
Re: RFS: kmenc15 - An advanced Qt/KDE MEncoder frontend.
Oded Shimon <[EMAIL PROTECTED]>: > On Wednesday 27 October 2004 05:23, Daniel Burrows wrote: > OK, either I am misreading, or you just prooved me right: > > * free packages which require [..] packages which are not in our archive at > > all for compilation or execution > > My program == free program > MPlayer == package which is not in the Debian archives at all. > > According to that, MPlayer doesn't need to be in the Debian archives for my > program to be in contrib!... > If your program depends on MPlayer, it must go into non-free. If your program depends on a program in non-free, it must go into contrib. But MPlayer isn't even in non-free. Regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * * Linux-Info-Tag in Dresden, am 30. Oktober 2004 * Info: http://www.linux-info-tag.de * pgp19J0gKEjHK.pgp Description: signature
Re: Bug#283578: ITP: hot-babe -- erotic graphical system activity monitor
Fernanda Giroleti Weiden wrote: Em Qui, 2004-12-02 Ãs 05:45, Manoj Srivastava escreveu: First of all, it's a sexist package, sure. Putting a program on Debian in which you have pictures of nude women is VERY agressive to the most women. Yes, it's agressive to me. As already written in -women, this is the point which saddens me the most in this thread. I'm really disappointed by seeing most contributors just not realize why this package, as proposed, is likely to hurt the feelings of several women (probably not all, I don't know) as well as, indirectly or not, some men. Packages can hurt feelings, yes. vi hurts mine. The bible hurts other peoples. purity-off also hurt a lot of peoples feelings. Can't please everyone. There are over 15k packages in debian. Some of them surely hurt the sensibilities of a lot of people. Get over it. I have had to. Packages can hurts feelings? It's your big conclusion about it? Don't matters for you the obvious detail about gender equality? requiring gender equality is obviosly pretty damn sexist. Are you thinking to choose to be catholic is the same choice I did when I was born? not very relevant but pretty much yes. can you change it? erik
Re: debconf temlate encoding
Hi Osamu! Osamu Aoki <[EMAIL PROTECTED]>: > On Sat, Nov 13, 2004 at 07:27:31PM +0200, Erik Schanze wrote: > > Package: ipmasq > > Severity: wishlist > > tags: l10n, patch > > Thanks but I have question. > > "MIME-Version: 1.0\n" > -"Content-Type: text/plain; charset=ISO-8859-15\n" > +"Content-Type: text/plain; charset=UTF-8\n" > "Content-Transfer-Encoding: 8bit\n" > +"X-Generator: KBabel 1.3.1\n" > +"Plural-Forms: nplurals=2; plural=(n != 1);\n" > > Are we moving to UTF-8 for sarge? > AFAIK most parts (especially deconf) are UTF-8 ready, so lets do this also for debconf templates. > Is there any guideline for which encoding to use for po files for > debconf. > I have read on a Debian web-site (or posting?) about using UTF-8 on every new (or updated) template, but sorry, I have no URL or "official statement" for you. Generally it's a good idea to do i18n with UTF-8. > Hmmm since installer uses UTF-8, maybe we should use UTF-8. But > then do I have to change old po files? Probably not but I am too lazy > to investigate :-) > I think we should convert every template at its next change. Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB *
Re: debconf temlate encoding
Christian Perrier <[EMAIL PROTECTED]>: > Erik Schanze <[EMAIL PROTECTED]> > > Osamu Aoki <[EMAIL PROTECTED]>: > (CC'ing -i18n) > Please set me on CC in this list. > > > Are we moving to UTF-8 for sarge? > > > > > AFAIK most parts (especially deconf) are UTF-8 ready, so lets do this > > also for debconf templates. > > Yes. > Oh, I mean "translations of debconf templates". > ... > Do not make confusion between templates and the PO files which > generate them. > Yes, sorry for that. Regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB *
Please make Moria free (was: Moria, as in the Author of)
Hi all! Clint Adams <[EMAIL PROTECTED]>: > > Do you think moria still has a place in Debian? Or do you gather it > > might be better removed? > > A better question is whether Mr. Koeneke is willing to relicense his > code under a free software license so that moria and angband and > derivatives can finally be free. > That would be nice and increase the chance that anybody adopt the Debian package, I think. Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * * Linux-Info-Tag in Dresden, am 29. Oktober 2005 * Info: http://www.linux-info-tag.de * pgpKPH07Pvk2S.pgp Description: PGP signature
Re: Bug#297121: ITP: wmail -- WindowMaker docklet watching your inbox
Ludovic Rousseau <[EMAIL PROTECTED]>: > Le Sunday 27 February 2005 à 10:08:02, Julien Danjou a écrit: > > Package: wnpp > > Severity: wishlist > > Owner: Julien Danjou <[EMAIL PROTECTED]> > > > > * Package name: wmail > > Version : 2.0 > > Upstream Author : Sven Geisenhainer <[EMAIL PROTECTED]> > > * URL : http://dockapps.org/file.php/id/70 > > * License : Seems specific, but free and probably GPL-compatible > > Description : WindowMaker docklet watching your inbox > > > > > > wmail is a Window Maker docklet watching your inbox, which is either a > > ordinary mbox or a directory conforming to qmails Maildir format. It > > provides a nice little GUI displaying some useful pieces of information > > about your inbox (as many other nice wm-apps doing nearly the same > > thing...). Per default it uses the $MAIL environment-variable to locate > > the inbox you are using, other mailing mechanisms like POP or IMAP are > > not supported - use a tool like fetchmail to retrieve POP- or IMAP-based > > mail. > > What are the differences with wmbiff [1]? > Or wmmail? Package: wmmail Priority: optional Section: mail Installed-Size: 472 Maintainer: Chris Waters <[EMAIL PROTECTED]> Architecture: i386 Version: 0.64-12 Depends: libc6 (>= 2.3.2.ds1-4), libx11-6 | xlibs (>> 4.1.0), libxext6 | xlibs (>> 4.1.0), libxpm4 | xlibs (>> 4.1.0), libxt6 | xlibs (>> 4.1.0), base-files (>= 2.0.3) Recommends: mail-reader Suggests: wmaker Filename: pool/main/w/wmmail/wmmail_0.64-12_i386.deb Size: 122954 MD5sum: dbc7c4fc78fd144c36f5953218054c75 Description: A mail notification program designed for WindowMaker There's nothing in the program that makes it require WindowMaker, except maybe the look. It's much like xbiff, and was derived from asmail 0.50. Now includes support for a variety of mailboxes, including mbox, MH, maildir, POP3 and IMAP. A few pixmaps and sounds are included with the package. Freundlich grüßend, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * * Linux-Info-Tag in Dresden, am 29. Oktober 2005 * Info: http://www.linux-info-tag.de * pgpeeBhbHTsdn.pgp Description: PGP signature
Re: Key management using a USB key
Hi Sean! sean finney <[EMAIL PROTECTED]>: > On Mon, Mar 14, 2005 at 09:30:54AM +0100, Matthias Urlichs wrote: > > > o gpg-agent support in the same manner as ssh-agent would be neat. I > > > understand that this requires gnupg 2.0 though. > > > > While gpg-agent is built from the gnupg 2.0 sources (a development > > snapshot of which is currently sitting in the NEW queue ...), the agent > > itself is perfectly useable with gnupg 1.2. > > then i'm wondering why someone hasn't packaged it already :) > Your fingers lie on a bloody wound. ;-) There was ITP #187548 for newpg, but was closed last summer. Please reopen it and make a package for newpg to make KMail-Users happy. see: Bug #280175 If you have not enough time, would you sponsor such package? Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * * Linux-Info-Tag in Dresden, am 29. Oktober 2005 * Info: http://www.linux-info-tag.de * pgpzLYL0Ym2sL.pgp Description: PGP signature
Re: dc and bc in Important?
On Jun 28, Carey Evans wrote > [EMAIL PROTECTED] (Erik B. Andersen) writes: > > [snip] > > > For most math, expr works just fine. Of course, expr is limited > > to integer math, but it works and is portable. > > Actually, for integer math, bash or ksh works quite well. > > bash$ a=41 > bash$ let a+=1 > bash$ echo $a > 42 > > -- > Carey Evans <*> [EMAIL PROTECTED] > iThis is correct, but has the unfortunate side effect of not being portable, since not all /bin/sh happin to be bash. If you want to allow the program to run on non-Linux machines, or machines running ash, etc. then expr is the most portable way. If you don't care about using bash-isms, which is often the case for Debian, then what you describe above is much easier. -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian Policy based on the wrong technical assumptions
On Jun 29, Fernando wrote > > I fear the Documentation Policy is being based on the wrong technical > assumptions. > > The fact is that what slows down HTML in an old system is not a web server or > the cgi converters. It is the browser! > [-stuff snipped-] > > Thanks, > Fernando. > > Elvis (the vi clone) reads man pages and html, and formats them and displays them in color (unless you don't want that). In the latest beta version, which I havn't packaged up, it even will browse the web (the stable version only reads local files). -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Twin v3.1.5
Hi folks, Twin, the cross-platform windows emulator and development libs, has recently had version v3.1.5 released. I have been planning on packing it up, but now that this release is finally out, I find that I am absolutely swamped at my work! If anybody wants to pack it up for Debian, please feel free. See http://www.willows.com for details. -Erik -- Erik B. Andersen Web:http://www.inconnect.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two thougts about testing
Hi Joerg! Joerg Friedrich <[EMAIL PROTECTED]>: > reading larger parts of the recent threads triggered by the > 'Vancouver proposal' brought me to write this mail. > > Over the last two years testing became more and more a second > (almost) stable distribution instead of being a preparation area for the > next release. Now there is even security support it is not a officially > supported release. > > Nevertheless I believe that testing is a good idea. But it suffers from > some problems. > > 1. The number of packages >Debian never stopped growing, and there are packages which are >unmaintained but they are still in the archive. >Hey, if noone is willing to maintain a package, wait a grace period >(30 days) and remove it from unstable and testing. If somone needs >it, he could step forward and maintain it. > Where are orphaned packages without bugs or only minor or normal bugs, they should be hold in testing. If RC-bugs remain unfixed for a period, I agree with removing, but this is common practice, I think. Perhaps somethimes too slow. ;-) Perhaps wnpp websites could be improved to show a ranking list of packages which will be removed soon and why. A Section "Removal Candidates" in DWN could be also helpful. > 2. Unstable to testing migration is one way >Packages migrate to testing automaticly, but removal requires manual >action. >I noticed that some developers work hard to get a package or a >specific version into testing, but if a new (rc) bug occurs after the >migration, nothing happens. >At least optional and extra packages should be removed automaticly if >a new rc bug emerges. >E.g. if noone claims to fix the bug, an extra package should be >removed from testing after one, an optional after two weeks. And also >all packages which depend on the buggy one. > I fully agree. I had already suggested similar idea before. http://lists.debian.org/debian-devel/2004/10/msg01565.html Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * * Linux-Info-Tag in Dresden, am 29. Oktober 2005 * Info: http://www.linux-info-tag.de * pgpbhBuCaHKrR.pgp Description: PGP signature
Re: Vancouver meeting - clarifications
Pierre THIERRY <[EMAIL PROTECTED]>: > Scribit Bas Zoetekouw dies 15/03/2005 hora 10:37: > > I find it a bit hard to believe that Debian isn't able to support 11 > > architectures while for example FreeBSD and NetBSD seem to manage > > fine. > > - FreeBSD: 6 ports, 12646 packages > - Debian: 11 ports, 9157 packages (sarge) [17593 in sid] > - NetBSD: 55 ports, 5300 packages > Be carefully with NetBSD and "Ports". They call every variation of a cpu architecture a "Port". You should look at http://www.netbsd.org/Ports/#ports-by-cpu . This is what Debian call "Ports". So they have 17 ports. Kindly regards, Erik -- www.ErikSchanze.de * DSA key ID 30825345 Bitte keine HTML-Mails! * Maillimit: 100 kB DSL Komplett von GMX +++ Supergünstig und stressfrei einsteigen! AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
links to logs in /etc? (/etc/postgresql/7.4/main/log)
why is there a link to logs in /etc? /etc/postgresql/7.4/main/log is a link to /var/log/postgresql/postgresql-7.4-main.log /etc is supposed to be for configuration files that are static, the link to log violates both (yes, it's only a link so it doesn't change but points to a file that changes and is definetely not a configuration file). is this a bug? Or is this somehow valid? btw I am not sure which package is this part of, can't find it using dpkg -S, not even when I dpkg -L all postgresql packages I have installed (I guess it was created by postinst sript or something like that). erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: links to logs in /etc? (/etc/postgresql/7.4/main/log)
Oliver Elphick wrote: On Sun, 2005-06-12 at 16:25 -0700, Erik Steffl wrote: why is there a link to logs in /etc? /etc/postgresql/7.4/main/log is a link to /var/log/postgresql/postgresql-7.4-main.log /etc is supposed to be for configuration files that are static, the link to log violates both (yes, it's only a link so it doesn't change but points to a file that changes and is definetely not a configuration file). is this a bug? Or is this somehow valid? Policy says that conffiles should be in /etc, or, if that is not feasible, that there should be a link to /etc. (Policy 10.7.2) Policy also states that packages must conform to the FHS. The FHS states that site-specific configuration files should be in /etc and that binaries should not be. It also says that log files should usually be under /var/log. It is not stated that other types of file must not be put in /etc, still less that there should be no links to such files. By analogy with 10.7.2, it seems reasonable to allow a link if it is not feasible to do without it. isn't the reasonable interpretation of FHS that only what is supposed to be in a particular directory is supposed to be there, i.e. that ONL:Y static config files should be in /etc tree? Reading FHS it seems the only reasonable interpretation, otherwise one could claim to be FHS compliant while having junk file all over the place. I mean regardless of details of interpretation - is there any rationale for link to log to be in /etc? If there's none it simply shouldn't be there, IMO (otherwise you guys (I'm not a dd) are creating a mess of a system with unneccessary illogical links/files all over the place). btw I am not sure which package is this part of, can't find it using dpkg -S, not even when I dpkg -L all postgresql packages I have installed (I guess it was created by postinst sript or something like that). The name indicates that it is created by postgresql-common (/usr/bin/pg_createcluster) in relation to a database whose server is postgresql-7.4 it's a bit off topic but could you please explain how does the name /etc/postgresql/7.4/main/log indicate it was created by postgresql-common (as opposed to any other postgrsql-* packages, e.g. postgresql-7.4 seems like a good candidate as well)? What does /usr/bin/pg_createcluster have to do with anything? OK, so I looked at it and the script actually creates that link (/etc/postgresql/7.4/main/log), seems pretty evil. Any ideas why would anybody do it? erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: links to logs in /etc? (/etc/postgresql/7.4/main/log)
Bernd Eckenfels wrote: In article <[EMAIL PROTECTED]> you wrote: That said, the Debian Policy document does mandage use of the Filesystem Hierarchy Standard (FHS), which in turn describes /etc like this: "/etc contains configuration files and directories that are specific to the current system". This cannot reasonably be interpreted to mean anything than "configuration stuff only". When I say reasonably, I mean that a sharp lawer-like mind might interpret it in whatever way they wish, on a larch, but that is not useful for building an operating system. Not that I like it, but a link in etc to the log direcoty is as good as a config gile containing "logdir=". Only that the former is easier to use. And since debian does place a lot of (alternative) links in etc it is a well accepted config method. However I am not sure if it is used that way in the package. ok, that's gotta be invalid argument since this could be argued for ANY file so you would end up with links to EVERYTHING in /etc, so that program would know where to find libraries, binaries, images, web pages (hey! we need a way to store URLs in filesystem) etc. I guess you were joking... erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396834: ITP: nfsen -- web frontend to nfdump netflow tools
Package: wnpp Severity: wishlist Owner: Erik Wenzel <[EMAIL PROTECTED]> * Package name: nfsen Version : 1.2.4 Upstream Author : Peter Haag, <[EMAIL PROTECTED]> * URL : http://nfsen.sf.net/ * License : (BSD) Programming Lang: (Perl, PHP) Description : web frontend to nfdump netflow tools allows to keep all the convenient advantages of the command line using nfdump directly and gives you also a graphical overview over your netflow data. * Display your netflow data from many sources: Flows, Packets and Bytes. * Easily navigate through the netflow data. * Process the netflow data within the specified time span. * Create history as well as continuous profiles. * Write your own plug-ins to process and disply netflow data on a regular interval. Homepage: http://nfsen.sf.net/ -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
drupal orphaned?
is drupal debian package effectively orphaned? It is already two major upgrades (more than a year) behind upstream (and upstream recommends to upgrade from one version to next so the upgrades to current might get complicated). there are bugs asking for new version (one about a year old for previous version, one I filed few weeks ago for the just released 4.7), so far the only response from maintainer is that he has no time. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=307821 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365709 is it time for /opt/drupal-4.7.0? erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: drupal orphaned?
Christoph Berg wrote: Re: Erik Steffl 2006-05-21 <[EMAIL PROTECTED]> is drupal debian package effectively orphaned? It is already two major upgrades (more than a year) behind upstream (and upstream recommends to upgrade from one version to next so the upgrades to current might get complicated). No, please have a look at http://packages.qa.debian.org/d/drupal.html. what exactly I would be looking for? I know that drupal has a formal maintainer. However no work has been done on drupal for a long time and it's already two versions behind upstream (more than a year behind). So it seems like it's de facto orphaned - I was just asking whether anybody knows more (there's not much response from maintainer, see bugs for drupal package, specifically the ones that ask for new versions - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=307821 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365709). ? erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: drupal orphaned?
Martin Samuelsson wrote: Erik Steffl @ 2006-05-24 (Wednesday), 09:28 (-0700) Christoph Berg wrote: No, please have a look at http://packages.qa.debian.org/d/drupal.html. what exactly I would be looking for? I know that drupal has a formal maintainer. However no work has been done on drupal for a long time and it's already two versions behind upstream (more than a year behind). So it seems like it's de facto orphaned - The web link above states that the latest maintainer upload was made 2006-04-18. That's roughly a month ago, which isn't really "a long time" ago. The web page in question also lists several other uploads. the package is two versions and more than a year behind upstream. Which will make it pretty hard to upgrade because upstream provides support for upgrades from version to next version, not across two versions. These are pretty major upgrades so... as far as I can tell last significant change of drupal package was 2005-01-09 which was 4.4.2 to 4.5.1 upgrade - drupal 4.5.1 was released 2004/12/1 (http://drupal.org/drupal-4.5.1) so that was pretty good but that was the end of it (minor security updates since then, new versions ignored) I was just asking whether anybody knows more (there's not much response from maintainer, see bugs for drupal package, specifically the ones that ask for new versions - In #307821 the maintainer answers all factual questions asked, and invites people to help with the packaging. Maybe you should start with helping the maintainer instead of trying to remove him from his position. Regardless of who's the maintainer, someone needs to do the work. remove him from position??? I'm just trying to figure out whether it makes sense to use debian package or whether I should just install drupal myself. I am not a debian developer and don't think I can be useful packaging drupal. Note that there are already some offers to help in the bugs... since there are no recent responses to wishlist bugs that are asking for new versions of drupal into debian so I thought I'd ask here - perhaps somebody is working on something... (I also asked on debian-user, no responses there) erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
removed start links are back after upgrade
Hello! As I understand, deleting start links with 'update-rc.d -f apache remove' is the Debian way of removing start calls for services at boot time. After every package upgrade of e. g. apache, I must call this command again, because start links were be installed again. Is it the normal behaviour? If yes, I think that should be handled better. update-rc.d should remember, which services are disabled and should disable it after every upgrade. Or is there any other way to prevent starting such services at boot time persistently? I'd like to file a bug, but I'm not sure against which package. General or sysv-rc + dpkg? Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * * Linux-Info-Tag in Dresden, am 29. Oktober 2005 * Info: http://www.linux-info-tag.de * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removed start links are back after upgrade
Hi Michal! Michal Politowski <[EMAIL PROTECTED]>: > On Wed, 12 Jan 2005 09:41:34 +0100, Erik Schanze wrote: > > As I understand, deleting start links with 'update-rc.d -f apache remove' > > is the Debian way of removing start calls for services at boot time. > > No. Generally update-rc.d is a tool for maintainer scripts not for the > admin to use. > > Its manpage says explicitly: >If any files /etc/rcrunlevel.d/[SK]??name already exist >then update-rc.d does nothing. This is so that the system >administrator can rearrange the links, provided that they leave >at least one link remaining, without having their configuration >overwritten. > Thank you for pointing it. I missed this part of the man page, sorry. > PS. this is a topic for debian-user not debian-devel > Right, but I asked for a package for bug reporting. Sorry again for the noise. Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * * Linux-Info-Tag in Dresden, am 29. Oktober 2005 * Info: http://www.linux-info-tag.de * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: removed start links are back after upgrade
Will Lowe <[EMAIL PROTECTED]>: > Given that this comes up so often, is there a reason not to add an > option to update-rc.d that does this? The problem here is that > "remove" sounds like "disable this". > > I'm thinking have "update-rc.d -f foo disable" do the same thing as > "update-rc.d -f foo remove && update-rc.d foo stop stop 0", and > clearly document this in the manual page, so that sysadmins can do > what they think they're doing when they use "remove". > A very good idea, but Bug #67095 is unfortunately tagged "wontfix". He suggested using sysv-rc-conf, but then I have to install additional packages libcurses-perl, libcurses-ui-perl and libterm-readkey-perl which I didn't used before. That's not my understanding of "one task, one tool". Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * * Linux-Info-Tag in Dresden, am 29. Oktober 2005 * Info: http://www.linux-info-tag.de * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pre-RFA] Intending to drop twenty-some packages
Dirk Eddelbuettel <[EMAIL PROTECTED]>: > * Miscellaneous > - afio (2 open bugs, active upstream, pretty straightforward) I like afio for my compressed backups and use it very often. I'd like to take over maintainership for it, if no otherone has already asked for. Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * * Linux-Info-Tag in Dresden, am 29. Oktober 2005 * Info: http://www.linux-info-tag.de * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building ncurses...a couple of questions...
For the list of terminals, I would appreciate vt200 (i.e., vt220) in the list too. I work at a place where vt220s are all over the place, and using a real termcap for a vt220 is much better than using the vt100 termcap. -- ++ | Erik Talvola [EMAIL PROTECTED] [EMAIL PROTECTED] | | PRC Public Sector Inc. 415-281-4671 FAX: 415-281-4686 | || | "Don't mistake lack of talent for genius." | ++
Re: Embedded Debian (was: compaq iPaq)
Quoting Ben Armstrong <[EMAIL PROTECTED]>: > sort of configuration at compile-time would be a useful. Is busybox used > anywhere else in Debian? It's curious that busybox isn't packaged > separately. For woody, we are creating a new section of the Debian archive for the debian-installer (new name for the boot floppies). BusyBox will be a stand-alone package in that section (actually, there are two busybox packages -- busybox and busybox-static, which is statically linked with everything turned on for rescuing your system when it is hosed). To build .debs of busybox, grab the source (either from CVS on opensource.lineo.com, or from released tarballs) just run 'dpkg-buildpackage' and it'll build. Next week as we start ramping up for woody, the new archive section will probably be showing up on mirrors and busybox .debs will be there. The source code in the boot floppies CVS tree is out of date, since we froze it quite a while ago, and has a number of bugs (none release critical, but some a bit annoying) that are fixed in the latest and greatest... -Erik -- Erik B. Andersen Web:http://www.xmission.com/~andersen/ email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons--
Re: [debian-installer] microdpkg
On Sun Aug 20, 2000 at 09:25:14PM -0700, Joey Hess wrote: > > I think that just like dpkg, it should be split into two programs: > microdpkg-deb to handles the low-level unpacking of packages, and > microdpkg, to do dependency checking, and so on. Maybe this will turn > out not to make sense; some space might be saved if the two were > combined. On the other hand, Erik Anderson might want to put > microdpkg-deb in busybox -- Erik? > I'm very open to the idea, after we agree on how to approach it. Maybe I'm missing something though (I almost certainly am), but do we really need a 'microdpkg-deb'? Wouldn't just 'microdpkg' be enough? When we go to install the base system, we really just want to unpack the .debs and drop them into place. For this to take place we can do something like the following: #!/bin/sh # Lame 5 minute micro-dpkg shell script... # Erik Andersen <[EMAIL PROTECTED]> if [ -z "$1" ]; then echo "usage: udpkg packagename.deb" exit 1; fi; FOO=`basename $1` PACKAGE=`echo $FOO | sed -e "s/_.*//g"` ROOT=/ DPKG_INFO_DIR=/var/lib/dpkg/info/ #For debugging only DPKG_INFO_DIR=/tmp/fff/info ROOT=/tmp/fff mkdir -p $DPKG_INFO_DIR ar -p $1 data.tar.gz | zcat | (cd $ROOT ; \ tar -xvf - > $DPKG_INFO_DIR/$PACKAGE.list) ar -p $1 control.tar.gz | zcat | (cd $DPKG_INFO_DIR ; \ tar -xf - ) if [ -f $DPKG_INFO_DIR/postinst ] ; then mv $DPKG_INFO_DIR/postinst $DPKG_INFO_DIR/$PACKAGE.postinst fi if [ -f $DPKG_INFO_DIR/postrm ] ; then mv $DPKG_INFO_DIR/postrm $DPKG_INFO_DIR/$PACKAGE.postrm fi if [ -f $DPKG_INFO_DIR/preinst ] ; then mv $DPKG_INFO_DIR/preinst $DPKG_INFO_DIR/$PACKAGE.preinst fi if [ -f $DPKG_INFO_DIR/prerm ] ; then mv $DPKG_INFO_DIR/prerm $DPKG_INFO_DIR/$PACKAGE.prerm fi if [ -f $DPKG_INFO_DIR/md5sums ] ; then mv $DPKG_INFO_DIR/md5sums $DPKG_INFO_DIR/$PACKAGE.md5sums fi if [ -f $DPKG_INFO_DIR/control ] ; then mv $DPKG_INFO_DIR/control $DPKG_INFO_DIR/$PACKAGE.control fi exit 0; If we really wanted to be cool, we could even use parse the control file, check the depends and the md5sums and such. I suspect doing that is overkill though. -Erik -- Erik B. Andersen email: [EMAIL PROTECTED] --This message was written using 73% post-consumer electrons--
Re: Boost Windows Reliability!!!!!
Daniel Stone wrote: > > > On Fri, Dec 22, 2000 at 01:06:53AM +0100, Robert van der Meulen wrote: > > > Quoting Bas Zoetekouw ([EMAIL PROTECTED]): > > > > > Now you can boost the reliability of ordinary Windows 3.x, 95 and 98 > > > > > to > > > > > nearly the level of Windows NT or 2000, Microsoft's professional and > > > > > industrial > > > > > version of Windows. > > > > Hmm, the debian lists get quite a lot of spam lately. Is there anything > > > > that can be done about this? > > > Close debian-devel for posting by non-subscribers, ask for volunteers who > > > would like to 'moderate' debian-devel, and have them look at the rejected > > > messages and accept them if on-topic. > > > Every mailing list i know has these functions, I was also wondering why we > > > weren't using such a system ;) > > > > Every mailing list software might have these functions, but none of the > > open project mailing lists that I know of do this. linux-kernel, gcc, > > glibc, openldap. > > > > There's a very good reason for this. Not the least of which is the effort > > in keeping it up. Secondly, not all developers use the same email > > accounts. I, for example, have three email accounts from which I post to > > Debian-devel. > > Solution: Pick one you like, stick to it, even if it means having > forwarders, having to SSH in, faking senders, whatever. anot her solution is the one I've seen svlug.org using: you can subscribe without email being sent to you (they use mailman, IIRC). So you can subscribe all your addresses and sent email to list from all of them but receive email from list only in one account. erik
Re: looking for replacement for run (because of critical bug in
Marc Haber wrote: > > Hi, > > I am maintainer for run and console-log, and waiting for NM to > complete. Unfortunately, run has a nasty bug that causes console-log > to hang which in turn may prevent a clean shutdown. Upstream doesn't > maintain run any more (and I shouldn't have packaged it in the first > place), and isn't interested in fixing that bug. I don't have the > expertise to fix this one as it is buried deep inside interprocess > communication and vanishes under the debugger and when debugging > outputs are included, and asking for help on debian-devel multiple > times didn't show a helper. > > I am now seriously thinking of having run pulled from the project > since its quality surely isn't up to Debian's standards. > > To keep console-log, I need a program that can daemonize a "normal" > program, i.e. put it in the background, maintain a pid file unter > /var/run and optionally restart the program when it dies. Is something > that can do this in Debian at the moment, or is there maybe somebody > who can help in debugging run? what about that start-stop-daemon or something like that used to start and stop daemons and various services, check the /etc/init.d scripts what/how they use, I do not have debian handy at the moment but I think it might do what you want. erik
Need to clone machines efficiently - help?
Hi Folks, I have just started working with a group here in Portland that is taking in old machines and recycling them - putting linux on as the OS (of course ;}). See http://www.freegeek.org for more. Its a non-profit all volunteer thing; and actually one of the people has posted to one of these lists before ... but, apparently things kinda (lamely, IMO) drifted toward a mandrake system -- I think I can turn that around with a little help; I am putting in some good time there and I think that when the realities of maintaining and upgrading rpm systems hits they may change their minds. Here is the first obstacle - not really a big one, but I spent all day digging around and couldn't really find any tools for this one: we want to be able to clone the machines easily over the local net. Mandrake has a tricky boot floppy that asks only for the eth0 config and then runs a bunch of perl to do the rest of the install non-interactively. I haven't started reading the scripts yet (that's plan B), instead I was hoping that someone had come up with something similar for debian. We are looking at hundreds of boxes already and its really just begun. This is really not a huge task - it would just make a nice splash over here if we could come up with something ... I would greatly appreciate recieving help/ideas/advice on this - Note however that I am not actually subscribed to the list at present (sorry, just too much at the moment ) so you can reply to me personally if you like. Thanks very much in advance! I hope we can get this to happen. Erik Winn
Re: Need to clone machines efficiently - help?
Hi Aaron, Thanks very much for the pointer - I'm reading the docs for it and it looks very promising. Might even be worth building a couple of debs from it ... no promises on that right now though :). Happy "whicheveryouprefer"! Erik Winn On Monday 25 December 2000 01:08, Aaron Lehmann wrote: > > On Mon, Dec 25, 2000 at 12:15:50AM -0800, Erik Winn wrote: > > Here is the first obstacle - not really a big one, but I spent all day > > digging around and couldn't really find any tools for this one: we want > > to be able to clone the machines easily over the local net. > > boot floppy that asks only for the eth0 config and t > > While I was at VA, I worked with SystemImager, which is available at > http://systemimager.org. It might be what you're looking for. It > requires the hardware to be basically identical across machines. Once > you set up the server, which is a significant task, cloning the master > client onto the other clients is a cinch, involving putting the > automatically-generated floppy disk into the disk drive and turning on > the computer. > > I wrote a setup guide for SystemImager a few months ago. > Unfortunately, I seem to have lost it :-(. Content-Type: application/pgp-signature; charset="us-ascii"; name="Attachment: 1" Content-Transfer-Encoding: 7bit Content-Description:
bugs + rant + constructive criticism (long)
Sorry for the crosspost, but I wanted to get this to those involved as such. Hopefully my tone won't sway you, if you read on I think you'll understand why. First, I regard debian as the 'best' linux distro out there. I recommend it to everyone. However, around the time of the potato release, things in woody especially started falling to shit, mainly in stupid QC that could have been easily prevented. Some packages refuse to install, and of course, break apt in the process. Right now, I'm *hopefully* going to be able to repair a totally hosed server that failed an apt-get because MAN AND GROFF failed to install properly, ending the upgrade process and therefore stopping the install of all the perl/debian-perl packages except the binary, rendering apt practically useless. No doubt the failure of man and groff has to do with the problem that i've been having with many other packages, which I will detail below. Please, please, please, please... Checking your shell scripts for SYNTAX ERRORS is not a bad idea before you submit it to the package repository! You have no idea how many times, that I have helped people in #debian on OPN fix shell script errors for packages like mysql-server, which, could have easily rendered a semi-production system completely dead (hopefully they compile from source, but that's not the point, is it?) simply because someone forgot a bracket or used the wrong 'set' parameters in their script. Other issues with apt in general - there is no OBVIOUS way (short of reading the APT/DPKG perl classes) to force certain flags. For instance - install package 'realplayer', then, upgrade your copy of xfree86-server or xfree86-common, and watch them fail as it tries to write to a file in /etc/X11. I don't think I need to go into detail about how much stuff like this pisses off the average user. rpm anyone? (no, apt-get -f install does not work, so don't even bother) And why are packages being REMOVED (lib-pg-perl for example) when I dist upgrade? apt-get and it's kin need more simple getopt-style flags that allow overriding of certain things, mainly conflicts. Also, an option to actually view what's being upgraded before you download 250 packages that are only going to break your system would be nice as well. I dunno - I was using debian back when hamm was released, and I have never seen such an utter mess of incompatibilities and stupid human error even in the worst mess of unstable upgrades (which happens, and is understandable). Almost all of this is due to a significant lack of adequate testing by package maintainers. My apologies for anyone I offended. -- Erik Hollensbe <[EMAIL PROTECTED]> Programmer, Powells Internet Division "I respect a man who lets me know where he stands, even if he is wrong." - Malcolm X
Re: bugs + rant + constructive criticism (long)
The reason that I haven't responded to this yet is simply because I knew it would go way off course onto a thread like this. Personally, anything I would put into 'production' would have all of it's servers running from-source compiled versions of the daemons it serves. Nothing against any of you debian contributors, but there is too much at risk, stable or unstable, from using a self-upgrading packaging format. I could go on with more reasons, but it'd be pointless. The server in question is a hobby server, that I run at home and TO TEST unstable. Unstable, while being unstable, should still install. I think of 'unstable' as 'untested packages', not 'untested package management'. Frankly anyone who can't dpkg -r/dpkg -i before they commit a package is someone that I would not want workign with me, much less handling my systems. Whether or not this is a free system is beyond the point. Packaging on a preset system is not rocket science, it's just a glorious mishmash of perl scripts and shell scripts. And I would have never written the mail in the first place if I had felt that it was my system config that was causing the problem. I have been running almost vanilla unstable to the T since potato was unstable on this system, and *NEVER* had install issues like this on it. The breaking of man and groff are inexcusable at best, and with dpkg's dependency on perl, perl should be coming with those modules as well as dpkg, with dpkg providing upgrades. Regardless, I do appreciate those that took the time to actually help solve my issues, but, none of them worked, of course, because apt and dpkg depend on perl modules, those of which did not get installed. As any perl hacker would know, no module == no execution. Tonight I'm going to try and track the packages that contain this information, and install them as needed. My general point (which most of you missed), was that I was using unstable. Not woody, not sid, unstable. I ran the dist-upgrade shortly after finding out about the testing<->unstable merge, so I was somewhat prepared for the worst, but nothing like this. I was also rather irate about the fact that a single failed package install causes the apt-get process to halt completely -- it should only avoid interdependent packages with the broken ones. Last I checked there were very few things that depend on man/manpages to run. (man and groff being the only things that come to mind) However, I can't even reconfigure, simply because the important packages never made it to the configure stage. This system is nigh unto hosed until I'm able to manually unpack the right packages with the proper perl modules and copy them to the proper spots, to fullfill these dependencies manually. Package management should have guarded against this, or at least provided me with an out (or at worst, checked itself and warned me). I have, in other less major cases had to run apt-get sometimes up to 4 times to finish the install process because of a single broken package that keeps appearing in random spots in the list -- this is something I should never have to do. I should be able to run it once, have it install all POSSIBLE packages, and then have it report a list of packages which were unavailable to install. IIRC, This was the way that older versions of apt worked, but I may be incorrect. I'm sorry to sound so arrogant when it comes to this, but I just can't believe there aren't mroe safeguards built into the package system that prevent stuff like this from happening. -- Erik Hollensbe <[EMAIL PROTECTED]> Programmer, Powells Internet Division "I respect a man who lets me know where he stands, even if he is wrong." - Malcolm X On Thu, 4 Jan 2001, Craig Sanders wrote: > On Wed, Jan 03, 2001 at 06:16:17AM -0800, Jim Lynch wrote: > > If you want to advocate the use of unstable software, please be my > > guest... but not on #debian. it changes daily, and can potentially > > break every day, potentially disasterously. So -no-. It's NOT > > appropriate to tell people to run servers on unstable software. > > if i ever happen to be on #debian and someone has a problem where the > best solution is to upgrade to unstable (either a full dist-upgrade or > just selected packages) then i certainly will recommend exactly that. > > it is *always* appropriate to provide a good solution to a problem - > whether it accords with your opinion or not. > > > > On the other hand... if you want to -pay- me to take the support load > > for a limited period of time, I'll open the door, for a limited period > > of time. I'm a volunteer there, you already know what a volunteer is > > if you have anything at all to do with debian. > > there's no need to be so pompous and pretentious. you're just another > volunteer, not the Thought Police. > > craig > > -- > craig sanders > > >
Re: bugs + rant + constructive criticism (long)
THANK YOU. Finally, an answer that I can use. I will look into contributing towards this package. -- Erik Hollensbe <[EMAIL PROTECTED]> Programmer, Powells Internet Division "I respect a man who lets me know where he stands, even if he is wrong." - Malcolm X On Thu, 4 Jan 2001, Matt Zimmerman wrote: > On Mon, Jan 01, 2001 at 11:06:18PM -0800, Erik Hollensbe wrote: > > > apt-get and it's kin need more simple getopt-style flags that allow > > overriding of certain things, mainly conflicts. Also, an option to > > actually view what's being upgraded before you download 250 packages that > > are only going to break your system would be nice as well. > > I assume you already are using apt-get's -u/--show-upgraded flag. Beyond > that, > check out apt-listchanges, in the package of the same name. Currently, you > need to download the .deb's first, but even if there is a breakage, you would > have ended up downloading them eventually anyway. Eventually, apt-listchanges > will be able to show changelogs before downloading any packages. > >
Re: Bug#81397: [authorization] fails silently for normal users, cannot start server
(this is not directed specifically at anyone) I don't quite get this... This list is moderated. Is it not too much for the moderator to moderate these postings and/or the user instead of drawing hte hounds just because one guy things a bug should be in a different spot? Some logical discussion, or perhaps some without the interspersement of flames, would be a fresh change. I have a hard time finding the logic in wasting your time complaing about how your time is being wasted. What does this solve? -- Erik Hollensbe <[EMAIL PROTECTED]> Programmer, Powells Internet Division "I respect a man who lets me know where he stands, even if he is wrong." - Malcolm X On Sat, 6 Jan 2001, Josip Rodin wrote: > On Sat, Jan 06, 2001 at 08:56:41PM +0200, Eray Ozkural wrote: > > > You have the gall to quote private email on a public list, and > > > expect people to accord you any attention whatsoever? Have you ever > > > heard of nettiquette? > > > > There is nothing personal in my reply and neither in quoted text and > ~~ > Um, there is. The thing that caused you to say "Great kiss ass" to hmh. > > > What happens is that I've got a real-world problem but I am being told of > > the complex-es of the maintainer of that package. > > > > Then, the guys who like him come in and tell me things that do not interest > > me at all... Are you guys on crack? > > Oh, of course. It's just you who is not, isn't it obvious? :> > >
Call for Linux Developers
Hello, I have the distinct pleasure of being in the position to add two developers with strong linux (preferably Debian/GNU) and/or C/C++ experience. Some understanding of at least one of these areas will also be helpful: * embedded architectures * driver writing * video/audio processing, recording, playback, etc. * graphical, web-based, and text/curses style user interfaces Additionally, we need someone local to Portland, Oregon that can be here on site ah, would tomorrow be ok? The pay isn't great, and the hours for the month will be long, but its a great opportunity to work on an open source project for a cool device with some really good people and has potential to lead to more generous compensations in future; should we succeed, there will be a second and more capable version of the device produced as well. The contract offered is $2400 for one month; I would like to bring in two people as soon as possible. Please feel free to respond to me directly via email, come into the office at the address listed below tomorrow, or call me at the corresponding number. Thanks very much, Erik Winn Project Leader [EMAIL PROTECTED] Redcellx Software 333 SW 5th Avenue, Suite 100 Portland OR, 97204 TEL: (503) 295-9680
Call for Qt GUI developer
Hello, A couple of weeks ago I posted with some considerable pleasure an announcement asking for developers for a multi-media project based in Portland, Oregon. See: http://lists.debian.org/debian-devel/2003/debian-devel-200305/msg02155.html I received a few responses of interest and have filled one role but am now in a position to fill the other (Qt GUI development) and must admit, to my embarrassment, that the drive with the contact info has died and was not backed up ... If you responded at that time and are still interested and available, please reply to me or you may call me directly at the Redcellx offices: (503) 295-9680 Thanks very much for your time. -- Respectfully, Erik Winn Development 503 880 2591
Re: Should MUA only Recommend mail-transfer-agent?
Artur R. Czechowski wrote:
On Tue, Aug 05, 2003 at 08:00:03PM +0200, Bernd Eckenfels wrote:
There are enough SMTP/POP3 MUAs which do not need any MTA infrastructure on
the local host, whatsoever.
But there are some important packages which depends on MTA directly, like:
at, cron, debconf, logrotate, mailx.
I can imagine a workstation without those packages but it is, IMO,
mutilated box.
...
it's strange for MUA to require MTA, lot of them support IMAP (for
viewing email) and SMTP (for sending email), both of which can be on
remote servers. So why MTA on local box?
Yes, there are other reasons to have MTA on box (non related to MUA)
but that's irrelevant.
erik
Re: Bug#202869: Should MUA only Recommend mail-transfer-agent?
Hans Fugal wrote: * Andreas Jellinghaus [Wed, 6 Aug 2003 at 00:27 +0200] mutt can do many nice things without /usr/sbin/sendmail. a dependency is set if something is always required, a recommends if is required for the common use, and a suggestion is used if it improved the functionality. so depending on mail-transport-agent is wrong, the recommendation is fine. Mutt can read mail without an MTA, but cannot send mail without one. it does not have to be on the same machine erik
Re: Debian should not modify the kernels!
Martin Michlmayr wrote: * martin f krafft <[EMAIL PROTECTED]> [2003-09-21 14:44]: What you distribute as 2.4.22 is not 2.4.22. So what? Most packages in Debian devate from upstream in one way or another. That's the added value we provide. I'm happy that Herbert carefully selects what to backport and I appreciate this effort. (Also note that Red Hat modify the upstream kernel and libc in a quite drastic way; in fact, their kernel is much more modified than ours). yeah, officer, he was speeding too... if I get kernel 2.4.22 as a debian package I expect kernel 2.4.22 as a debian package, not something else... any debian specific changes should result in kernel name change, that's what's expected in kernel world (when I get ac kernel I get 2.4.22-ac3) kernel is quite different from other packages - it is fairly often that people who get kernel source want to patch the kernel... I might not care that packageX is not vanilla packageX because it is VERY unlikely for me to even get the source for that package - the kernel is quite often customized (=recompiled locally). erik
Re: Please participate in popularity-contest
Hi Petter, Petter Reinholdtsen <[EMAIL PROTECTED]>: > Please help the install team and others get a better view on the use > of packages in Debian. To do this, install the popularity-contest > package and say yes to participate. > Perhaps more will participate if you zip the report, to reduce traffic. It's requested in bug 149425 for years. At least for modem users popcon traffic is significant. And yes, I have only a low bandwidth modem line and run popcon, but others don't do so. Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * * Linux-Info-Tag in Dresden, am 29. Oktober 2005 * Info: http://www.linux-info-tag.de * pgpAISbm2qojw.pgp Description: PGP signature
status of jackd? (bug #318098)
yes it's unstable but still, what's the status of jackd? Currently it's pretty much uninstallable (i.e. lot of packages would have to be removed to install jackd). Considering that jackd is required (or at least very useful for) by almost all major audio apps this is fairly bad - any ideas when this is going to be fixed? relevant bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=318098 mini rant: what's the point in breaking important packages in unstable for significant periods (e.g. the bug above was filed 2005/07/13)? Isn't experimental more appropriate for stuff like this? Same for udev (requiring linux kernel 2.6.12 which wasn't available for debian) etc. At least explanation and status update would help (the bug does have a vague ETA but no explanation). Unstable is pretty much the only debian version usable for desktop (in general, I guess somebody could use stable for desktop) because desktop software (X, browsers, kde and gnome etc.) and HW support develops/changes too fast for stable to be able to keep up. erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: status of jackd? (bug #318098)
Nigel Jones wrote: On 09/08/05, Erik Steffl <[EMAIL PROTECTED]> wrote: mini rant: what's the point in breaking important packages in unstable for significant periods (e.g. the bug above was filed 2005/07/13)? Isn't experimental more appropriate for stuff like this? Same for udev (requiring linux kernel 2.6.12 which wasn't available for debian) etc. At least explanation and status update would help (the bug does have a vague ETA but no explanation). Unstable is pretty much the only debian version usable for desktop (in general, I guess somebody I would _NEVER_ recommend someone install Debian Unstable as a desktop... Testing, yes, Stable even more so. could use stable for desktop) because desktop software (X, browsers, kde and gnome etc.) and HW support develops/changes too fast for stable to be able to keep up. But the point of Stable, is that it is not effected by ABI Transitions except between major releases. Stable is as good for Desktops as it is for servers. If someone however dearly wants Stable with updated hardware, it is possible to pin apt stable sources, yet allow testing/unstable kernel/x/wm/* packages in. The comment of yours could also be put in way that: your "HW support changes too fast" will relate just as easy to networking, but if they invent 100gbit/s network cards for mainstream release in 2 hours time, the stable hardware support is out dated, (btw, purposely far-fetched). If the admin wishes to use that hardware, by all means he/she can go and apt-get that kernel that supports it, if he/she wishes... My main point is, what your saying applies to 99% of users, so in general are you saying Debian should just have a version called "Unstable", ok it would mean quicker security updates, no freezes, madhouse updates, mass package breakage during transitions... but overall, that would be really great for a Desktop or a server right? Sorry if any of the details are incorrect, but I do not like the idea of Desktop computers running unstable, esp in the world of what seems to be, mostly, Windows users. Only exception, developers/maintainers that work in those areas and have to test constantly, and are prepared to... servers versus desktops: - the software for servers is a lot more stable (year old apache is great, year old mozilla is useless), - on servers you don't need HW support for latest gizmos (year old disk, network card etc. are OK, year old video card is showing its age) - servers are usually supposed to be running all the time, mostly specific set of packages that you already tested, upgrades are costly (e.g. testing that all the home grown perl scripts work with new perl version etc.) all in all, if you offer a distro that is several years old it's not suitable for _general_ desktop use (I'm sure it would be OK for _some_ dektop users), regardless of how much you dislike people running unstable. Frankly I don't understand why so many debian developers live in denial... For desktop usage you need _new_ software - pretty much all the desktop sofrware is under heavy development and is going from proof of concept to something actually usable (mozilla, gnome, kde, open office, games, support for new HW etc.). and pinning is ridiculous, if I wanted to maintain my distro I'd go withslackware or some other hand-off distro and keep my add ons in /opt/package-version. Testing is evenmroe ridiculous, it breaks for longer periods of time and I'm nto sure about security fixes (it didn't use to get them in timely fasion, maybe that was fixed in the meantime). All in all debian should somehow solve the age issue - either release more often or put more effort in keeping unstabl working (and it's working very well, I've been using it for several years without major problems and even minor problems are fairly rare, I guess it's just a little bit of attitude change) Now that there's experimental isn't that a good playing ground? I was under impression that experimental is for stuff that potentially breaks something, and unstable is for release candidates... erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: status of jackd? (bug #318098)
David Nusinow wrote: On Tue, Aug 09, 2005 at 01:01:16AM -0700, Erik Steffl wrote: mini rant: what's the point in breaking important packages in unstable for significant periods (e.g. the bug above was filed 2005/07/13)? Isn't experimental more appropriate for stuff like this? Same for udev (requiring linux kernel 2.6.12 which wasn't available for debian) etc. At least explanation and status update would help (the bug does have a vague ETA but no explanation). Unstable is pretty much the only debian version usable for desktop (in general, I guess somebody could use stable for desktop) because desktop software (X, browsers, kde and gnome etc.) and HW support develops/changes too fast for stable to be able to keep up. Where would you like us to do our work? This is exactly what unstable is errr... where would YOU like to work? In intentionally broken unstable becuase "it's just unstable"? You surprise me. *for*. It lets us break things while they're in development in order to push the distro as a whole forward. No one says that you have to be running isn't that what experimental is for? the s00p3r 133t newest version of everything on your system at all times. no but I want to. Because non-1337 stuff is usally several years old (not at the moment but it's getting old fast) and not suitable for desktop usage (in general) Testing should be a good compromise for your needs anyway. well, the fixes take forever to get to testing plus not sure about security (apparently there's some effort to fix this as was mentioned in another message in this thread: http://secure-testing.alioth.debian.org/) so while testing seems like a good idea in general it doesn't seem to be very appealing in its current incarnation... (I started to use testing but gave up) erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: status of jackd? (bug #318098)
David Nusinow wrote: On Tue, Aug 09, 2005 at 10:45:16PM +0200, Kurt Roeckx wrote: On Tue, Aug 09, 2005 at 10:28:58AM -0400, David Nusinow wrote: Where would you like us to do our work? This is exactly what unstable is *for*. It lets us break things while they're in development in order to push the distro as a whole forward. No, that's what experimental is for. If you upload something to unstable, it should be ready to migrate to testing in a short period. And it would be best that you could "prove" that it's ready to go to testing before you upload it to unstable. This doesn't really work that way in reality, because you're just pushing things up yet another level. At some point non-developers will use experimental the way they use unstable now. Let's give a concrete example that I have some experience with: X.org. I uploaded it to unstable with the best of my own knowledge that it was ready to ship. It turned out not to be, breaking things due to port issues and a mistaken belief that it would have to deal with the C++ transition. I broke a hell of a lot of things with that upload that I didn't know I would break. I had unofficial packages that I advertised on planet debian well beforehand, and I got a lot of testing out of them (got a few important bug fixes in the first upload to unstable as a result) and I *still* broke a lot of things when I uploaded to unstable. And I *still* haven't been able to upload a completely fixed package that can migrate to testing (waiting on arm now...). It's been over a month that I've been working on that. The point is, things break and we need a place to break them. Whether you name it unstable or experimental makes no real difference. well, sometime bugs get all the way to stable, no software is without bugs. What I was talking about is that 'unstable' is pretty much only usable desktop so it shouldn't be broken on purpose. Or the release cycle should be <1 year. Or something. Maybe the solution for (desktop) users is to use some actively maintained sort of unstable meant for end users - e.g. ubuntu. BTW I think it makes a lot of sense to use experimental for most of the initial testing and only release to unstable when it looks like the package is a release candidate. Yes, some problems might only be uncovered in unstable but that's what the unstable is for:-) Summary of my point: given the imporance of unstable the attitude "who cares, it's only unstable" doesn't seem to make sense (see the jackd problem (bug #318098), jackd which is crucial for audio processing is uninstallable for several weeks and it's not even explained what's going on). erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: status of jackd? (bug #318098)
Steve Langasek wrote: On Tue, Aug 09, 2005 at 04:23:55PM -0700, Erik Steffl wrote: well, sometime bugs get all the way to stable, no software is without bugs. What I was talking about is that 'unstable' is pretty much only usable desktop Clearly not, or you wouldn't find it necessary to complain about the fact that you currently find it unusable. come on, don't pretend you don't understand (also, I didn't say I find it unusable, I am mostly trying to figure out what's going on with jackd). clarification: unstable is _closest_ to usable desktop out of what debian offers. and it would be really nice if developers wouldn't break it unneccessarily, like jackd seems to be doing right now. I am not complaining about occasional problems (like e.g. x.org upgrade) or really huge efforts like c++ abi change (I think jackd problem is not part of that but I might be mistaken). Unstable is, first and foremost, the staging ground for the next stable release. If users find it usable for their purposes, more power to them. If not, fixing unstable for them should not take precedence over the actual development processes; those users should be using something else instead, or learning how to coexist with development shake-ups while running unstable. well, if it's staging ground for the next stable release care should be taken for it to be stable enough to be usable, right? I mean if you cannot install jack then how are you going to develop software that needs jack? Obviously _some_ problems are pretty much impossible to avoid (e..g c++ abi change) but I was talking about the attitude towards _unneccessary_ problems, which is what jackd seems like. I won't try to suggest here what that other something should be, because I cannot fathom what sort of a desktop user *needs* cutting-edge software. The constantly shifting sand dunes of unstable are precisely what I *wouldn't* look for in a desktop environment that I actually plan to use for productivity. err firefox? thunderbird? open office? hotplug? new kernels with new drivers? new kde or gnome? all of these are under constant development and stable usually has versions that are very outdated (or are not there at all). there's a LOT of functionality for desktops that gets developed in two or three years it usually takes to release new debian stable. Do you really need examples of HUGE improvements of desktop related software in last two years? Or HW support? Yes, right at _this_ moment stable is pretty new but in few years it will be obsolete in many aspects again. So please don't argue that unstable is fresh _now_. erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: status of jackd? (bug #318098)
Arjan Oosting wrote: Op di, 09-08-2005 te 16:23 -0700, schreef Erik Steffl: BTW I think it makes a lot of sense to use experimental for most of the initial testing That is wat unstable is for. well, what is experimental for then? And what would you offer to desktop users? and only release to unstable when it looks like the package is a release candidate. That is testing, it should be possible to release testing anytime as the next stable. You're complaining that testing is too old, and unstable unstable, but no, here's what I was saying: unstable: mostly OK, think it would be useful if people took it a bit more seriously, i.e. not breaking it for extended periods of time without a good reason and if they break it at least explain what's going on (see jackd bug #318098) testing: bugs take forever to get fixed so overall it's worse than stable. Security was a huge problem, might be getting better (saw the link about the effort but don't know what the status is) stable: too old, most of the time, not suitable for desktop (in general) it takes some time to fix bugs and make sure a package is in a releasable state, so yeah the software in testing might be a little bit old, but that can't be helped. Moving development from unstable to testing won't fix this, then unstable gets 'old' and we are back were we started. what are you talking about? Nobody was suggesting anything like that. I was merely saying that for lot of desktop users unstable is the only sort of acceptable option so people might want to take it seriously, like not breaking it for extended periods of time with the attitude "it's just unstable". If developers needs to try something crazy then there's experimental, as far as I can tell. erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: status of jackd? (bug #318098)
Josh Metzler wrote: On Tuesday 09 August 2005 06:56 pm, Erik Steffl wrote: well, the fixes take forever to get to testing That is because they need to go through testing and bug fixes in unstable. well, what does it matter? The bugs take forevr to fix so testing is not really usable... so while testing seems like a good idea in general it doesn't seem to be very appealing in its current incarnation... (I started to use testing but gave up) What you are asking for is to have experimental be what unstable is now, and unstable be what testing is now. If the gcc transition were going on in no I don't. experimental right now, rather than unstable, unstable would go without updates to gcc, X, etc. etc. for months, just as testing is right now. which is not what I was pointining out in my mini-rant and I already explicitly stated that I don't see how to avoid problems during big upgrades like that. As long as it's announced and visible it's OK (after all that IS what unstable is for). I think if you got what you are asking for, you would switch to using experimental. Like you, I enjoy using and testing the latest versions of everything, so I also run unstable on my desktop. But to do that, you need to be willing to suffer the occasional breakage and pay close attention to everything that is going on with Debian. repeat: note that I am not complaining about c++ abi changes etc., that can't be avoided, I think. I was specifically talking about _unneccessary_ problems that get weeks to fix for unknown reasons like jackd bug #318098 (perhaps there is a good reason for it, don't know). what I was suggesting is doing experiments in experimental, put release candidates into unstable, which is what seems to be current policy anyway. I also wish the "it's unstable, deal with it" was banned because it's used as a blank excuse for number of otherwise inexcusable problems that can be easily avoided. That's why I'm trying to persuade people that unstable is the only viable alternative for number of desktop users (well,so far I have only proven that that number is at least one:-) erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: status of jackd? (bug #318098)
Gustavo Noronha Silva wrote: Em Ter, 2005-08-09 às 19:17 -0700, Erik Steffl escreveu: That is wat unstable is for. well, what is experimental for then? And what would you offer to desktop users? Stop that. That's how our release process works; using unstable (maybe even testing, for that matter) for "common-user" desktops is broken. We need faster releases or a Debian Desktop CDD which provides a more desktop-friendly system, perhaps tracking testing and freezing differently from the usual stable. well, OK but _now_ the best option is unstable. All I was saying that IMO developers would help a lot by not using "it's just unstable" as an excuse to break it (or sort of break it, like jackd does). I was not asking for unstable to magically become release quality. You're trying to fix the wrong problem, go fix real bugs. ? I can't fix bugs like the one in subject of this email or udev requiring newer kernel than is available in debian etc. (which is the kind of bugs I was talking about, I wasn't complaining about unstable in general, it's actually amazingly stable) ... That, of course, when we're not busy handling unhelpful "ideas" or complaints from people who do not really understand what's going on. How many times more this same discussion is going to happen? why do you assume I don't know how debian release process works? Been reading debian-devel and debian-users for few years now... Note that I wasn't asking to change the development process, simply to acknowledge that unstable is very useful to users and treat it as such, unless you come up with something else that's recent enough (more frequent releases, actually usable testing or something else). and I guess it will be repeated until debian (i.e. debian developers) comes up with a solution. Perhpas the fact that this is being repeated over and over means that it should be addressed? (well, maybe ubuntu or other debian unstable based distro is the answer) erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: status of jackd? (bug #318098)
Wouter Verhelst wrote: On Tue, Aug 09, 2005 at 03:56:21PM -0700, Erik Steffl wrote: ... No. Summarizing the above, experimental is there for people to break on purpose, while unstable is there for people to break by accident. Since that's all I was saying! Don't break it intentionally and say "it's only unstable, deal with it". a lot of changes are happening right now, a lot of accidents happen as well -- which results in an overall reduction in quality of the system. and note that I explicitly wrote that I am not complaining about c++ abi changes or X.org transition (well, seems like jackd is somehow related to c++ abi even though it's not c++ lib itself) There's nothing we can do to fix that -- other than by expelling everyone who ever makes even the slightest mistake. But I don't like the sound of that... me neither but asking about an eta for fix and an explanation what's going on seems reasonable... the s00p3r 133t newest version of everything on your system at all times. no but I want to. Because non-1337 stuff is usally several years old (not at the moment but it's getting old fast) and not suitable for desktop usage (in general) I hear that argument a lot, and it makes me wonder. If three-year-old software is not suitable for desktop usage in general, then what did you do three years ago? Use pen and paper? vi:-) ok, I don't remember the dates exactly but during last few years (I think withing last three): - I got ati 9800pro (not sure if anything in unstable is needed, I use ati driver, I think I needed X 4 and kernel 2.6.x but maybe not) - iPod (firewire, hfs+) - according to docs hfs+ support was very experimental until fairly recently, I think I needed unstable kernel for firewire too - SATA disk - at a time needed bleeding edge kernel with patches from jeff Garzik to make it work, new kernel (third party) also required new binutils (the ones in unstable) - usb support (mass storage: camera, nokia ngage) - don't think it worked very well in stable but not sure about that - firefox, thunderbird are a lot better than what was available three years ago (I think mozilla just started to be usable at that time), I also want java to work, javascript to work, latest plugins available, css to work etc. - openoffice (previously staroffice) - only became usable recently (well, maybe some found it usable before but opne way or another it improved a LOT), MS import improved a lot (don't import many MS files but I didn't have any problems during last maybe a year while before that the import wasn't that good), etc. - IM clients are broken fairly often (i.e. probably at least once during the period of three years) by protocol changes so you need the latest ones - kde and gnome are both fairly immature so having a new version is usually very useful - performance, functionality etc. (this includes lot of stuff that comes with these - nautilus, koffice, konqueror etc. most of which only became usable during last maybe one or two years) - alsa - only became stable recently - jackd - very useful for audio - rosegarden4 and several other major audio apps, essentially I couldn't even do anythign interesting with audio two or three years ago (between alsa not working very well, lack of preemptive kernel and lack of apps, not saying you couldn't do anything with audio but compared to what you can do now it's almost nothing:-) the list goes on and on. Actually it's pretty amazing how fast the opensource software development is and how many apps were created or improved over the last few years. erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pbuilder status update
Hello Junichi! Junichi Uekawa Junichi Uekawa <[EMAIL PROTECTED]>: > pbuilder is doing as usual; it's now switched over to > cdebootstrap and cdebootstrap has been working fine. > Not for me. I maintain my own small mirror by apt-move together with apt-zip because I own a small modem line, but can download elsewhere. It wasn't able to use this mirror with pbuilder+cdebootstrap because cdebootstrap will see Release.gpg and Packages.gpg files, that I haven't generated (no need to do so yet). Is there any way to switch this off in cdebootstrap? Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * * Linux-Info-Tag in Dresden, am 29. Oktober 2005 * Info: http://www.linux-info-tag.de * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
There are buildlogs for amd64 packages?
Hi, there can I find the build log for dvgrab_1.7-1 on amd64? http://buildd.debian.org/ doesn't list amd64 at all and http://amd64.ftbfs.de/ has only 1.8-1 and higher. Because amd64 is listed on http://packages.debian.org/ build logs should also be (easyly) available for packages of this architecture. Regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * * Linux-Info-Tag in Dresden, am 29. Oktober 2005 * Info: http://www.linux-info-tag.de * pgp7rxhBfXUBN.pgp Description: PGP signature
Re: Determining a .deb's intended Debian Version
Hi, Christopher Crammond Christopher Crammond <[EMAIL PROTECTED]>: > Suppose you have a repository stuffed full of binary packages, in > this case Debian Packages. If you were unlucky enough to have them > in a rather un-organized fashion, I was just wondering if the package > file itself would provide said information to allow me to write a > program to sort them out. > You are looking for apt-move. Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * COMTEC in Dresden, 09. - 11. November 2005 * Info: http://www.messe-comtec.de/ * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Configuration Packaging System
Anders Kaseorg and I created a system of CDBS modules (which we've tentatively packaged as the config-package-dev package) for creating Debian configuration packages. I'm designing a hosting service at Penn State which involves configuring a big pile of Debian machines (https://weblion.psu.edu/trac/weblion/wiki/WebLionHosting ). I was midway through inventing/accumulating something very similar when I discovered your framework, and I now plan to use it for almost all our config packages. Bravo! Please count my vote toward polishing dpkg's divert behavior, adding config hooks, or whatever the best solution turns out to be for officially supporting config packages. This is too useful a feature to leave teetering on the edge of acceptance! Erik Rose Core Developer and General Incorrigible The WebLion Group Pennsylvania State University -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#408393: ITP: libxml-rss-feed-perl -- XML:RSS:Feed perl module for Persistant XML RSS Encapsulation
Package: wnpp Severity: wishlist Owner: Erik Vetters <[EMAIL PROTECTED]> * Package name: libxml-rss-feed-perl Version : 2.212 Upstream Author : Jeff Bisbee <[EMAIL PROTECTED]> * URL : http://search.cpan.org/~jbisbee/XML-RSS-Feed-2.212/ * License : Perl (Artistic) and GPL Programming Lang: Perl Description : XML:RSS:Feed perl module for Persistant XML RSS Encapsulation I wanne see this package in Debian, you can really do cool stuff with XML:RSS::Feed. Specially when you wanne watch multiple RSS Resources. I already have working package ... Greetings Erik -- System Information: Debian Release: 4.0 / APT prefers feisty-updates APT policy: (500, 'feisty-updates'), (500, 'feisty-security'), (500, 'feisty-backports'), (500, 'feisty') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.20-5-generic Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reasons for recommends and suggests
Manoj Srivastava wrote: On Sat, 19 May 2007 13:17:45 +0200, Hendrik Sattler <[EMAIL PROTECTED]> said: Am Samstag 19 Mai 2007 07:14 schrieb Manoj Srivastava: If you do not wish to educate yourself on the details, perhaps you should be heeding the directions given to you by the maintainer? Perhaps. But first, but not all packages are actually strict about that That would be a bug, then. If you can identify such packages, could you please file bug reports? and I do not want to bloat my installation Well, for non-buggy packages, what you have is an issue of trusting the maintainers judgement. In that case, you also have to trust that the maintainer comes up with a correct, and properly formulated explanation in under one line; which correctly emphasizes the importance of the dependency relationship. Since you don't trust the maintainers judgement in the first place, I think the lack of space is likely to lead to a situation that you'll make an equal number of incrorrect decisions dues to lack of information, incorrectly interpreted information, and other misunderstanding. maintainer did not decide that dependency is in order but chose recommend/suggest instead - of course I want to know why so that I can figure out whether I am in the minority that does not want the package installed - it might be useless or even have unwanted effects on my usage of the package (or on my system). the idea that if you are in the minority you already know it is broken, you cannot know that until you know, at least aproximately, what does the recommending package use recommended package for. the issue of trusting the maintainer is irrelevant, I trust the maintainer but I want enough information to be able to collapse the wave function of probably (recommended packages) and possibly (suggestions). ... Unless you are a $Deity, or have conducted an extensive analysis, this is a matter of judgement. By putting things as recommends, the maintainer is saying, yes, it is a good thing to install these packages together. exactly. In other words it means that the maintainer is saying that in some cases you might not want the recommended package installed. you keep describing this from maintainer's perspective, imagine yourself at hands of other expert that you trust - auto-mechanic, doctor, teacher etc. You never asked question and always did what they recommneded without question, even in cases you KNEW they do not know details of your specific situation? erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#513575: ITP: fswebcam -- Tiny and flexible webcam program
Hi Luca, Luca Niccoli Luca Niccoli : > 2009/1/30 Julien Cristau : > > how many of those do we need? why this one in particular? > > I've been looking in Debian for a command line tool that takes > pictures from a USB video capture device that doesn't support MJPEG, > and couldn't find one (besides mplayer - but in a really hackish > way); fswebcam does (it accepts input in a number of formats). > > If I missed a tool with these features, please give me some > pointers... > What about dvgrab? Not sure if it works for you, give it a try. Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * - Linux-Info-Tag in Dresden auch 2009 wieder * Info: http://www.linux-info-tag.de/* -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Thoughts about the bug tracking system
Hi Carl, "Carl Fürstenberg" <[EMAIL PROTECTED]>: > The major problem with the current system, is that it requires that > the reporter has access to a mail server, if they want to use the > more easier variant by using reportbug script. their other > alternative is to send an email from their webmail (I assume that > they don't have access to an smtp server, and are prohibited to use > one by them self by port 25 blocking) using a complicated syntax to > be able to send "correct" reports. > You could use reportbug and save the report into a text file rather sending a mail. Then you could cut'n'paste the text into your webmailer message field. No need to learn any syntax. Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * - Linux-Info-Tag in Dresden, 3. November 2007 * Info: http://www.linux-info-tag.de/*
Re: pbuilder build with passing -sa option
Hi Piotr, "Piotr Roszatycki" <[EMAIL PROTECTED]>: > sudo pbuilder build --debbuildopts="-sa" *.dsc use: sudo pbuilder build --debbuildopts "-sa" *.dsc Kindly regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * - Linux-Info-Tag in Dresden, 3. November 2007 * Info: http://www.linux-info-tag.de/* -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A case study of a new user turned off debian
Daniel Jacobowitz wrote:
On Mon, Nov 03, 2003 at 03:05:56PM -0500, Greg Stark wrote:
...
What would be really neat would be if aptitude or perhaps even apt checked for
earlier versions of the package in the pool and offered them as options if the
current one fails to configure.
No, really. This is what stable and testing releases are for.
if Greg's friend was installing a server it might have been a good
idea to use stable (I definitely wouldn't recommend testing)
erik
Re: A case study of a new user turned off debian
Steve Greenland wrote: On 03-Nov-03, 14:21 (CST), Erik Steffl <[EMAIL PROTECTED]> wrote: Oh, not this crap again. Or perhaps you're contending that I've not gotten anything done at work in the last two years using my "useless" Debian stable desktop. Hint: there's more to "useful" than running the latest version of everything. Particularly for a sys admin, who I'd expect to be heavily command line oriented, and who doesn't need the latest 3-d games or dvd player[1]. Okay, I am running Adrian Bunk's backport of Galeon/Mozilla (thanks, Adrian). But that's it. Oh, not this crap again. Or perhaps you're contending that what is usefull for you is usefull for everybody. Hint: there's more to "useful" than old version of software in early stages of development. Lot of desktop oriented apps are changing fast and older version are fairly poor (functionality, stability etc.) - open office, mozilla (and other browsers), kde, gnome etc. Lot of new HW has a better chance to be (better) supported on newer system (are new kernels available for stable?) erik
Re: GNU within the name
Mathieu Roy wrote: ... When I'm told that a system is running GNU/whatever, I expect first to find there GNU coreutils, GNU bash, GNU Emacs, GNU Compiler Collection, gzip, GNU awk,GNU make, the GNU Debugger, GNU sysutils, GNU tar, GNUpg, GNU grep, GNU mailutils, GNU ncurses, GNU readline, GNU shellutils, GNU wget... you can install these on pretty much any system... is my gaming machine running gnu/win xp? or did we use gnu/solaris at -xxx-? this GNU narcissism is pretty annoying... where's the freedom RSM is promoting? the software is released under GPL and that's it. Nowhere in the GPL it says you have to call your project GNU/something. erik
Re: Next reboot script execution framework
Jérôme Warnier wrote: Le dim 03/10/2004 à 19:26, David Goodenough a écrit : On Sunday 03 October 2004 16:54, Jérôme Warnier wrote: Is there a framework for executing once a script at next reboot in Debian (Sarge|Sid)? Any idea of a "clean" way to do it? Thanks One comment, it is rather "Not the Linux Way(TM)" to expect reboots. Only things like changing the kernel should need a reboot. Well, let me explain then: I'm working on a customized Debian distro, and on a replication engine (Replicator) for machines. I would like some things to happen next time the machine is powered on, because the people who install it would like to have to wait the less possible. I imagined that we would finish the installation (probably unattended) and the system would reboot at the end (because 1/ there *is* probably a newer kernel, and for whatever reason, 2/ GDM does not start automatically after being installed). I would like the system to do things in the background at next reboot, like running prelink, scrollkeeper-rebuilddb, updatedb, ... You get the idea... no. if there is a new kernel then reboot is neccessary. the services can be simply started. Rebooting machine because you need to start gdm is weird to the extreme. I mean do you reboot your machine to start vi? grep? ls? erik
Re: Wanted BTS feature: subscription to individual bug reports
Anand Kumria <[EMAIL PROTECTED]>: > On Tue, 12 Oct 2004 13:37:37 +0400, Nikita V. Youshchenko wrote: > > I can't find a way to track more-or-less easilly all bugs in BTS that I am > > somewhat involved into. > > > > If by 'involved' you mean submitted, then this might be useful: > > http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED]> > I assume he mean also bugs on wich he had supplied additional information. This feature would be very nice. Regards, Erik -- www.ErikSchanze.de * Bitte keine HTML-E-Mails! No HTML mails, please! Limit: 100 kB * * Linux-Info-Tag in Dresden, am 30. Oktober 2004 * Info: http://www.linux-info-tag.de *
Re: debian-installer status 2002-11-22
On Fri Nov 22, 2002 at 04:07:01PM +0100, Tollef Fog Heen wrote: > and PowerPC. Bdale started on ia64 last night. I've played around > with getting it up and running on BSD, but no luck so far, busybox > seems to be fairly Linux-centric. It is not a high priority, but if > somebody picks it up, it would be good. Busybox devel (which I really should get packaged up) has the infrastructure needed to support multiple OSs... I don't plan to do the porting myself, since my plate is pretty full at the moment, but I can can certainly help to guide those wishing to do the port... -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons--
updating of /etc/rc?.d
I was wondering how possible it would be to considering adding to the policy that a single runlevel's symlinks be left out of updating from packages. After running an update of 200+ packages or so, all the rc?.d directories are re-polluted with symlinks i've destroyed. This is a big problem on my workstation, where I may only want mysqld up for a few hours while I check something, for example. Thanks, -- Erik Hollensbe <[EMAIL PROTECTED]> Programmer, Powells Internet Division "You can't depend on your eyes when your imagination is out of focus." - Mark Twain
Re: updating of /etc/rc?.d
On Mon, Apr 23, 2001 at 11:09:18PM -0800, Ethan Benson wrote: > if you leave at least one symlink in at least one runlevel, even if > its a K link in runlevel 0 or 6 update-rc.d will refuse to add any new > links. policy requires the use of update-rc.d so packages can't add > any links so long as you leave at least one. if you find a package > that does otherwise thats a bug. spectacular! thank you very much. -- Erik Hollensbe <[EMAIL PROTECTED]> Programmer, Powells Internet Division "You can't depend on your eyes when your imagination is out of focus." - Mark Twain
openGL problems: how is it supposed to work?
I have DRI and openGL (mesa) working, but I have few strange problems. xscreensaver: openGL demo hacsk are running in software mode when run by xscreensaver but run accelerated when run from xterm. xscreensaver openGL demo hacks run in window mode (when run from xterm, accelerated), how do I make them fullscreen? setenv MESA_GLX_FX fullscreen does not help... is libglide3 still used for implementation of openGL? when I remove libglide3 the openGL stops working (in HW accelerated mode). ldd `which glxinfo` does not show libglide to be used but strace reveals it opens it - is it based on which module is used (I guess only tdfx uses glide)? my system: 3dfx voodoo 3 debian unstable, kernel 2.4.5 ii libglide3 2001.01.26-1.1 Graphics library for 3Dfx Voodoo based cards ii libglide3-dev 2001.01.26-1.1 development files for libglide3 ii xlibmesa3 4.1.0-2XFree86 version of Mesa 3D graphics library ii xserver-common 4.1.0-2files and utilities common to all X servers any pointers to more detialed info? TIA erik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: openGL problems: how is it supposed to work?
"Marcelo E. Magallon" wrote: > > >> Erik Steffl <[EMAIL PROTECTED]> writes: > > > xscreensaver: openGL demo hacsk are running in software mode when run > > by xscreensaver but run accelerated when run from xterm. > > IIRC, this is a xscreensaver FAQ (alas! I'm not sure) yes it was. didn't occur to me it could be a well known problem (I thought that GL would be used using default settings), just in case anybody else has the same problem here's the relevant part of FAQ: - quote from xscreensaver FAQ start Try editing your .xscreensaver file and changing the memoryLimit setting to 0. Version 3.33 introduced the memoryLimit option as a precautionary limit to prevent runaway memory use if one of the display modes happened to be buggy; it prevents any program launched by xscreensaver from allocating more than that much memory. It defaults to 50M, which is a lot. However, apparently certain OpenGL libraries (notably nVidia) do something strange that makes them appear to allocate more than 128M of memory for every OpenGL program! Consequently, those programs die on startup because they aren't able to allocate memory. - quote from xscreensaver FAQ end I have voodoo III and X 4.x and doing the above fixed the problem. > > is libglide3 still used for implementation of openGL? when I remove > > libglide3 the openGL stops working (in HW accelerated mode). > > libglide3 is used by the 3dfx DRI driver. > > > ldd `which glxinfo` does not show libglide to be used but strace > > reveals it opens it - is it based on which module is used (I guess only > > tdfx uses glide)? > > the 3dfx driver dlopen's it itself. that's what I thought, I just wanted to have it more official:-) thanks a lot! erik
xconsole eats up memory
I noticed that xconsole eats up a lot of ram:
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
4725 root 14 -10 105M 13M 11244 S < 0.0 11.2 2208m XFree86
10873 erik 10 0 18224 11M 5800 S 0.0 9.4 0:27
communicator-sm
4753 root 9 0 8564 4112 3804 S 0.0 3.2 0:17 xconsole
there are several bugs filed (and merged) but not resolved (few years
old!). Is there any workaround? Any similar program that would work
correctly (not eating up RAM)?
TIA
erik
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]
usb driver and probe function (is never called)
I realize that this is not strictly debian-devel question but it is
related to both debian and development so while I don't expect big
discussion I would appreciate RT _specify_which_one_ FM.
so far I have read the relevant parts of Linux device drivers, 2nd
edition (O'Reilly), the info about usb in linux/Documentation, parts of
some other linux kernel & setup books.
I am trying to make the USB work on my debian unstable system, using
kernel 2.4.14 and it just doesn't work. the specific problem is that the
function 'probe' (specified when registering driver) is NEVER called and
therefore driver doesn't manage any usb devices. as far as I can tell
the system is set up correctly, see below for modules, kernel settings
etc.
so far I have tried the sample usb driver from linux device driver,
2nd edition (o'reilly) and personal jukebox (www.pjbox.com) drivers,
both behave in exactly the same way - I get a message in syslog that the
driver was registered and that's it, the message from probe function is
never printed and the driver doesn't work (cat says No such device)
the sample drivers are available from:
http://examples.oreilly.com/linuxdrive2/
the pjb-100 drivers are available from various places (I have tried
few, official ones from compaq, various drivers included with personal
jukebox managers (they are all same or almost the same), none of them
work even though I have reports that the driver works with 2.4.14), this
is one of the places where the driver can be downloaded:
http://www.kolumbus.fi/toni.tammisalo/pjbsdk-3.1.3.tar.gz
-
cpqpjb (personal jukebox driver), system setup is below
-
I checked how the cpqpjb works, added some debug messages and here's
what I have found:
the following structure is used to register the driver using
usb_register (&pjb_driver):
static struct usb_driver pjb_driver = {
name: "cpqpjb",
probe: pjb_probe,
disconnect: pjb_disconnect,
};
so I guess that the pjb_probe should be called by kernel but it's
never called, there is:
printk(KERN_INFO "pjb_probe: looking for devices\n");
statement right in the beginning of the function but I never see it in
syslog (I see other messages from cpqpjb printed using the same
function & KERN_INFO).
this is what happens when I try to open the /dev/cpqpjb for reading:
pjb_open sets the static (on file level) variable static_pjb_state as
file->private_data.
pjb_read gets the above mentioned file (I guess it's the same one,
otherwise it all wouldn't make any sense), casts file->private_data to
pjb (pjb = (struct pjb_state *) file->private_data;) and checks for
pjb->device, which is unfortunately 0, so -ENODEV is returned (and cat
/dev/cpqpjb prints out the No such device message)
[=static_pjb_state->device is 0]
the static_pjb_state should have been set by pjb_probe, but pjb_probe
is never called!
this is where I hit the wall, who is supposed to call pjb_probe (well,
kernel, but how exactly)? what are possible reasons it wasn't called?
any ideas? I checked the usb.c briefly and it looks like it should have
been called but it's not...
settings & messages
here are my kernel config settings related to usb:
jojda:/usr/src/linux# grep -i usb ./.config | grep -v '^#'
CONFIG_USB=m
CONFIG_USB_DEBUG=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_UHCI=m
CONFIG_USB_AUDIO=m
CONFIG_USB_ACM=m
CONFIG_USB_PRINTER=m
CONFIG_USB_HID=m
CONFIG_USB_HIDDEV=y
CONFIG_USB_DC2XX=m
CONFIG_USB_SCANNER=m
CONFIG_USB_SERIAL=m
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_VISOR=m
these are my system settings:
debian unstable
jojda:~>uname -a
Linux jojda 2.4.14 #1 Fri Nov 23 16:28:37 PST 2001 i686 unknown
jojda:~>grep cpqpjb /etc/modules.conf
### update-modules: start processing /etc/modutils/erik.cpqpjb
alias char-major-10-176 cpqpjb
### update-modules: end processing /etc/modutils/erik.cpqpjb
jojda:~>ls -l /dev/cpqpjb
crw-rw-rw-1 root root 10, 176 Dec 20 04:43 /dev/cpqpjb
jojda:/home/erik# lsmod | egrep '(usb)|(cpqpjb)'
cpqpjb 2688 0
usb-uhci 20932 0 (unused)
usbcore50848 1 [cpqpjb usb-uhci]
jojda:/home/erik# lspci|grep -i usb
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16)
00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16)
jojda:~>mount | grep usb
usb on /proc/bus/usb type usbdevfs (rw,noexec,nosuid,nodev)
running cat /dev/cpqpjb and watching the syslog (I enabled PJB_DEBUG
in currently used driver, which is btw the one from Toni Tammisalo's
page, see the link above):
jojda:/home/erik# date;cat /dev/c
Re: usb driver and probe function (is never called)
Mark Brown wrote: > > On Mon, Dec 24, 2001 at 04:32:08AM -0800, Erik Steffl wrote: > > > any ideas? TIA > > If the device isn't showing up in lsusb and so on you've got bigger > problems than finding a driver for it. Until you can get the system to > talk to it as a generic USB device (just showing up in the "what USB > devices are there" output) a driver is going to have a hard time doing > anything useful with it. that makes sense, that's probably why probe is never called (the system doesn't know about device so it doesn't see a need to call probe). however, I have no idea what to do - I followed all the steps from the docs I've found, none of them talk about this particular sitation. am I missing some module? some alias in /etc/modules.conf? some device file in /dev? I have: jojda:/home/erik# lsmod |grep usb usb-uhci 20932 0 (unused) usbcore50848 1 [cpqpjb usb-uhci] in /etc/modules.conf: alias char-major-10-176 cpqpjb I am quite sure I need uhci since that's what lspci says: jojda:/home/erik# lspci|grep -i usb 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) 00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 16) I don't even know where to start looking... is it possible that usb-uhci just doesn't work and that I need the alternative uhci support (JE)? erik
Re: usb driver and probe function (is never called)
Ulrich Eckhardt wrote: > > On Monday 24 December 2001 13:32, Erik Steffl wrote: > > I am trying to make the USB work on my debian unstable system, using > > kernel 2.4.14 and it just doesn't work. the specific problem is that the > > function 'probe' (specified when registering driver) is NEVER called and > > therefore driver doesn't manage any usb devices. as far as I can tell > > the system is set up correctly, see below for modules, kernel settings > > etc. > > > have you also printk-mined another usb-driver ? I remember a bit from hacking > the pegasus-driver. There you had to register the usb-driver with a set of > vendor/device-IDs so the usb-core could find the proper driver without asking > _every_ driver to handle the device. However, that was with 2.2.18 or so. > > > so far I have tried the sample usb driver from linux device driver, > > 2nd edition (o'reilly) and personal jukebox (www.pjbox.com) drivers, > > both behave in exactly the same way - I get a message in syslog that the > > driver was registered and that's it, the message from probe function is > > never printed and the driver doesn't work (cat says No such device) > > > If it is available on paper, it isn't up to date, especially not with > 2.4.something :-) > > > > > Dec 22 01:46:55 localhost kernel: hub.c: port 1 connection change > > Dec 22 01:46:55 localhost kernel: hub.c: port 1, portstatus 301, change > > 1, 1.5 Mb/s > > Dec 22 01:46:55 localhost kernel: hub.c: port 1, portstatus 300, change > > 0, 1.5 Mb/s > > > I use USB but have neither 'portstatus' nor 'connection change' in my kernel > logs. On thing I would ask you to do is to try eg a mouse that is known to > work or something like that. Just to see that it is the driver, not the setup. at this point I am quite sure it's the setup, the driver is confirmed to work with 2.4.14 (cpqpjb) and the usbsample (from the book) is for 2.4 too (not sure if for 2.4.14). what should usb syslog messages look like? 2.4.14 has support for both old and new drivers (old have 2-parameter probe, new ones have 3 parameter probe function) I also tried to plug in mouse (logitech mouse man, wireless, optical) but still got the same messages, no attempt to load driver (I don't have driver for mouse though, I'll probably try that as next step (even though I think the problem is that kernel does not look for ANY drivers, the existence of drivers seem to be irrelevant). > > lsusb (usbview show the same info) output: > > > > Bus 002 Device 001: ID : Virtual Hub > [snip] > > Bus 001 Device 001: ID : Virtual Hub > [snap] > EOF ? Whether your device is handled by any driver or not, it should appear > in here! Try another device and see if that gives you anything. well, yes, that's all there is, there are no further usb related messages in syslog. obviously it doesn't even try to look for device drivers even though it should, I have looked (briefly) at the code of usb_register and some other functions in usb.c - whenever new device is connected it should look at the modules and run probe function (that was registered) but for some reason it does not happen on my system. I haven't put any extra debug info into usb.c yet... is uhci or altarnative uhci better (for 2.4.14)? I though both should work... is there any documentation about setting up usb devices for linux? so far I haven't found any that would list any step that I missed. are any other modules besides usbcore and usb-uhci meeded fpr uusb support (aside from actual device drivers for particular devices)? is it possible it's hw problem? it works to certain extend, I get at least some messages when I plug in/unplug devices so it's not completely disconnected but is it possible that there's some other hw problem? erik
Re: usb driver and probe function (is never called)
On Mon, Dec 24, 2001 at 04:32:08AM -0800, Erik Steffl wrote: > I realize that this is not strictly debian-devel question but it is > related to both debian and development so while I don't expect big > discussion I would appreciate RT _specify_which_one_ FM. The appropriate list for USB problems is linux-usb-users@lists.sourceforge.net . You need to have the hotplug package installed for proper USB support. > so far I have read the relevant parts of Linux device drivers, 2nd > edition (O'Reilly), the info about usb in linux/Documentation, parts of > some other linux kernel & setup books. > > I am trying to make the USB work on my debian unstable system, using > kernel 2.4.14 and it just doesn't work. the specific problem is that the > function 'probe' (specified when registering driver) is NEVER called and > therefore driver doesn't manage any usb devices. as far as I can tell > the system is set up correctly, see below for modules, kernel settings > etc. Please try 2.4.17, there have been quite some USB updates in 2.4.15 and 2.4.17. > so far I have tried the sample usb driver from linux device driver, > 2nd edition (o'reilly) and personal jukebox (www.pjbox.com) drivers, > both behave in exactly the same way - I get a message in syslog that the > driver was registered and that's it, the message from probe function is > never printed and the driver doesn't work (cat says No such device) Try a device with a known-good driver first. A mouse, for example. > > settings & messages > > > here are my kernel config settings related to usb: > > jojda:/usr/src/linux# grep -i usb ./.config | grep -v '^#' > CONFIG_USB=m > CONFIG_USB_DEBUG=y > CONFIG_USB_DEVICEFS=y > CONFIG_USB_UHCI=m Also select "CONFIG_USB_UHCI_ALT=m". Quite a lot of USB problems with UHCI hardware can be solved by using "the other" UHCI driver. Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/
Re: visual c
> "Ing. Luis Chávez Romo" wrote: > > I am tired of been a windows user. Let me know if there is an easy way > to move > an aplication developed in visual c to linux. it depends on libraries used, if the libraries are not available for linux than it might be quite hard. Another option is to have not entirely native application and use wine (kinda ugly but it might help the transition). erik
Re: visual c
Francois Gouget wrote: > > On Fri, 28 Dec 2001, Erik Steffl wrote: > > > > "Ing. Luis Chávez Romo" wrote: > > > > > > I am tired of been a windows user. Let me know if there is an easy way > > > to move > > > an aplication developed in visual c to linux. > > > > it depends on libraries used, if the libraries are not available for > > linux than it might be quite hard. > > > > Another option is to have not entirely native application and use wine > > (kinda ugly but it might help the transition). > >Unless your application only uses the C library, your only solution > to port it to Linux is to use either Wine, then you run the .exe using > Wine, or Winelib, i.e. recompiling it against the Wine libraries. >The Winelib way requires a bit more work, but will allow you to also > call Unix APIs (may allow for a better integration) and to progressively > migrate your application to a more portable API (although the transition > may not be easy, porting to a new API never is). > > To learn more about Wine see the WineHQ web site: > >http://www.winehq.com/ there is also a number of other libraries (for GUI), I don't think you have to use ms libs, you can use e.g. wxwindows, qt etc..., also, if the application doesn't have complicated gui the porting might be fairly easy... (it also depends on how well the app is designed, if the gui is farily independent of back-end it's much easier to port it). erik
Re: visual c
Francois Gouget wrote: > > On Sat, 29 Dec 2001, Erik Steffl wrote: > [...] > > there is also a number of other libraries (for GUI), I don't think you > > have to use ms libs, you can use e.g. wxwindows, qt etc..., also, if the > > application doesn't have complicated gui the porting might be fairly > > easy... (it also depends on how well the app is designed, if the gui is > > farily independent of back-end it's much easier to port it). > >Without knowing anything about his application it's hard to say, but > it is easy to end up using MS specific things when coding on Windows. > And it's not just about the GUI: it's also about ReadFileEx, > CreateMutex, CreateProcess, registry APIs, ACL management, asynchronous > file operations, COM/DCOM, ... I guess generally speaking you're right, unless the program was written with portability in mind (and wizard were avoided) it probably doesn't really resemble c++ much... erik
Re: Cross-platform XML editor
Douglas Bates wrote: ... > $ ./xeena.sh > using java in [/usr/lib/jdk1.1] > Unable to initialize threads: cannot find class java/lang/Thread > Could not create Java VM you probably need to set CLASSPATH environmental variable erik
Re: serious bug. Evolution and Microsoft mentality.
Jonathan Walther wrote: > > Subject: > > I tried evolution tonight. It is impressive work. I wanted to import > my 62 mbox mailboxes and 6 maildirs. Well, for whatever reason, it > didn't let me import my maildirs. And the interface for importing > mailboxes is painful for 62 different mailboxes. So I looked at how to > do it "by hand", as any nice Unix application will easily allow one to > do. > > It turns out to be fairly easy. Find a mail folder of the same type as > the one you want to copy over, duplicate it with its new name, then > symlink your original mbox to Foldername/mbox. It even has a nice > function to convert my mboxes to maildirs, although new mailboxse are > unfortunately not created in maildir format. I started evolution up, > my folders were seen, I was happy. Then I exited. > > What happened? My symlink was erased! Gone! A new mbox file had been > created from the contents of the original. This was bad enough, but it > was a file of different size, indicating that QP (Quoted Printable) encoding > had been redone, which is the cause of the GnuPG compatibility bug. So > first evolution screwed me by making it so new mails going into the old > mailbox won't be seen from evolution, but then it redoes the emails, > causing GnuPG signatures to yield bogus "bad" matches! > > I hope that Evolution won't fall into the grave and anti-Unix error of > assuming it is the only mail handling software on the system, nor that > it can possibly know about all the mail software that is or might be in > use on a system. > > Hopefully the symlink-being-erased bug will be fixed soon. I think > overall Evolution has made great strides and become a great program. > I look forward to further evaluating it when this issue is fixed. IMO the good solution for this kind of problems is to use IMAP. don't trust MUAs to work with files. (of course, Evolution should play nice with symlinks) erik
Re: serious bug. Evolution and Microsoft mentality.
[EMAIL PROTECTED] wrote: > > Zitiere Erik Steffl <[EMAIL PROTECTED]>: > > [1935 lines uselessly quoted] > > > > IMO the good solution for this kind of problems is to use IMAP. > > don't trust MUAs to work with files. > > IMO IMAP is still a PITA, AFAIK the only well and out of the box > interoperating > combination of MUA and IMAPd is pine together with uw-imapd which is about as > configurable as your sunglasses. With other Linux combinations you'll have to uw-imap is a good choice for beginner (you only need to apt-get install it), while it's true that it cannot be configured much (and the configuration is compile-time) it already provides much better functionality then file based mail storage (no file access conflicts, access to email over network (supports ssl), access to other stuff) as far as MUAs go I think the new ones have fairly good support for IMAP (mutt (could be better), netscape, evolution etc.) [I use netscape and mutt mostly] > go fiddling with Prefix&|View = INBOX. | INBOX* | INBOX.% | INBOX etc. > > IMO nothing for newbies. I only have experience with cyrus (with sieve) and it's quite a hell, it provides almost no feedback, docs are all over the place etc. works well but very unpleasant to handle. also,the version in debian is extremely old. erik
Re: serious bug. Evolution and Microsoft mentality.
Tomas Pospisek's Mail Lists wrote: > > On Wed, 9 Jan 2002, Mark Brown wrote: > > > On Wed, Jan 09, 2002 at 02:36:01PM +0100, [EMAIL PROTECTED] wrote: > > > > > IMO IMAP is still a PITA, AFAIK the only well and out of the box > > > interoperating combination of MUA and IMAPd is pine together with > > > uw-imapd which is about as configurable as your sunglasses. With other > > > Linux combinations you'll have to go fiddling with Prefix&|View = > > > INBOX. | INBOX* | INBOX.% | INBOX etc. > > > > Most things (certainly mutt and kmail, I can't think of anything else I > > tried that gave me problems) interoperate quite happily with both UW > > IMAP and Courier IMAP. I can't think off-hand of a client that wouldn't > > play with UW IMAP. > > I have yet to find out how to be able to see my inbox as well as all its > subfolders (that's how it's set up on cyrus) from home. I am not sure if uw-imap supports anything else but mbox format by default and with mbox you cannot have folders that contain message and subfolders (it's one or another). so there's no such thing as inbox and its subfolders. if you're using maildir and it doesn't work properly then I don't know, haven't tried uw-imap with maildir... erik
Re: serious bug. Evolution and Microsoft mentality.
Tomas Pospisek's Mail Lists wrote: > > On Thu, 10 Jan 2002, Erik Steffl wrote: > > > Tomas Pospisek's Mail Lists wrote: > > > > > > On Wed, 9 Jan 2002, Mark Brown wrote: > > > > > > > On Wed, Jan 09, 2002 at 02:36:01PM +0100, [EMAIL PROTECTED] wrote: > > > > > > > > > IMO IMAP is still a PITA, AFAIK the only well and out of the box > > > > > interoperating combination of MUA and IMAPd is pine together with > > > > > uw-imapd which is about as configurable as your sunglasses. With other > > > > > Linux combinations you'll have to go fiddling with Prefix&|View = > > > > > INBOX. | INBOX* | INBOX.% | INBOX etc. > > > > > > > > Most things (certainly mutt and kmail, I can't think of anything else I > > > > tried that gave me problems) interoperate quite happily with both UW > > > > IMAP and Courier IMAP. I can't think off-hand of a client that wouldn't > > > > play with UW IMAP. > > > > > > I have yet to find out how to be able to see my inbox as well as all its > > > subfolders (that's how it's set up on cyrus) from home. > > > > I am not sure if uw-imap supports anything else but mbox format by > ^^^ > > Um a bit further down in my original posting I wrote: > > * ... yes, the problem is namespacing and that allthough there's a > * standard it seems that either client (pine) or server cyrus 1.5.x from > ^ that puzzled me a bit but since you put your comment right under uw-imap comment I thought you are refering to uw-imap at that point. > * debian seem to be unable to get things straight between them. > > > default and with mbox you cannot have folders that contain message and > > subfolders (it's one or another). so there's no such thing as inbox and > > its subfolders. > > > > if you're using maildir and it doesn't work properly then I don't > > know, haven't tried uw-imap with maildir... > > for cyrus INBOX seems to be the root directory. Incoming mail ends up in > INBOX. Subdirs are created within INBOX. > > It might be that I didn't get cyrus the config right but AFAIK it's the > default setup. But IMHO one should not be required to dig RFCs in depth to > be able to use a mailclient. yes, for cyrus that's the way to go, all the email is in INBOX (which is user.username). you can put other stuff besides email in the root directory so the incoming personal email is all in INBOX, at least I think that's the rationale. I don't like it much either (since I only have email) but that's how it is. when/if you add e.g. NNTP or shared folders support you'll be OK with INBOX being there:-) erik
Re: Anybody want to adopt cdrecord?
On Wed Apr 03, 2002 at 03:52:10PM +0200, Eduard Bloch wrote: > #include > Adam Byrtek wrote on Wed Apr 03, 2002 um 09:12:02AM: > > > #131325: cdrecord: crashes on 2.2.20 > > > > It *has* to be fixed before Woody! In fact I'm still using old (1.9-1) > > cdrecord because of this bug... > > Yes, it has. > > Erik: What about that patch for cdrecord, needed to not to depend on the > running kernel? Why cannot we have to versions, cdrecord-2.4.x and > cdrecord-2.4.x? I have not had the time to work in it, so on March 21st I put cdrtools up for adoption. David Downey agreed to take over, but it has been 2 weeks since then and he hasn't yet bothered to upload a new package yet. Since he hasn't done that yet, I guess I'm still the nominal maintainer. As such, if someone else that _is_ willing to do that job and wants to take over As for the 2.4.x vs 2.2.x stuff, it would be easy to make a patch to test the mmap behavior at runtime and then do the right thing. I havn't had the time to write such a patch, but that would take care of the problem once and for all. Setting compile bahavior based on the kernel running on the compiling box is just lame, but thats what cdrecord does -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anybody want to adopt cdrecord?
On Wed Apr 03, 2002 at 10:03:24AM -0800, David D.W. Downey wrote: > Looks like it doesn't matter anymore. I've been removed as the new > maitnainer by erik due to the 2 week delay. > > Once again, I apologize for the delay on the package but it couldn't be > helped. Hopefully I can assist on some other package. Sorry about that. The package needed some immediate attention. If I'd had the time, I'd have done it myself... As is Wish it could have been otherwise, -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
