From: <zs...@fi...> - 2003-10-28 11:55:29
|
On Tue, 28 Oct 2003, Thomas Leonard wrote: > On Mon, Oct 27, 2003 at 11:45:08PM -0500, zs...@fi... wrote: > [ 0.1.17 ] > > However, to get it to work (on my Gentoo box), I had to edit the > > /etc/init.d/0install script to call sudo instead of su (as it was, it > > tried to log me in as zeroinst). > > Could you see what options would work with su? Not everyone has sudo. > > Maybe > > su zeroinst -s /bin/sh -c /usr/local/sbin/zero-install > > or something? No, same deal. On the other hand, su -c /usr/local/sbin/zero-install zeroinst works fine. > > Actually, after I'd written this much I tried to open > > /uri/0install/www-i1.informatik.rwth-aachen.de to see if it worked. > > No, that site is too out-of-date. There's a note at the bottom of the > install page warning about it... I expected an error message is all (I did see the note on the intsall page, but seeing as this isn't released software, I felt it my duty to do something wrong). > > Unfortunately, it has a habit of totally locking up my computer. > > It shouldn't affect any other processes. Once ZeroProgress has a cancel > button, that will help too. Absolutely nothing worked. Not even the X mouse pointer would move. The cursor stopped flashing. My music stopped playing. ctrl+alt+bkspace did naught. > > Also, I tried doing > > ls -l /uri/0install/zero-install.sourceforge.net/A<tab> > > which had the same effect (ls on that dir is fine, as is running Edit > > etc). > > Doesn't Ctrl-C (a couple of times) get out of it? It should time-out after > a while too. Part of the problem is that ls tries several times, and > zero-install isn't smart enough to realise that a request that failed one > second ago is probably going to fail again. No, as I said, it locked my computer. Note that at the time, ls wasn't the problem, it was zsh trying to expand the filename. Sorry if I wasn't clear enough. It also did it when accessing /uri/0install/rox.sf.net just now. > > Also: > > /usr/portage/x11-themes % > > /uri/0install/zero-install.sourceforge.net/apps/ZeroProgress/AppRun & > > [1] 4645 > > Starting ZeroProgress... > > [1] + segmentation fault > > /uri/0install/zero-install.sourceforge.net/apps/ZeroProgress/AppRun > > > > the second time I ran it, it worked fine though. > > Maybe some kind of intermittant failure? Could you have a look at the > daemon log? It seems to happen the first time I run any compiled program. I'm guessing it's an issue of cacheing.* Not being used to doing this kind of stuff, I'm not sure where Gentoo keeps it's daemon log, but it isn't /var/log/daemon.log, and /var/log/everything/current only has Oct 28 22:34:53 [zero-install] Fetching 'http://zero-install.sourceforge.net/.0inst-archives/2003-Jul-03-13-14-39-10.tgz' in the context. * I tried deleting /var/cache/zero-inst/zero-install.sourceforge.net/demo/hello_glib, which had done the same segfault the first time, succeed subsequently. But now it _always_ crashes when run as /uri/0install/zero-install.sourceforge.net/demo/hello_glib, but doesn't when run from /var/cache/... > IO errors mean that the zero-install helper didn't download the data. Look > in /var/log/daemon.log for hints (in future, ZeroProgress should explain > what happened). > > Also, make sure the helper (zero-install) is still running (maybe it > crashed, or you rebooted?). Yeah, that was the problem. I forgot to add 0install to my startup, so it wasn't running after I was locked out. -- Tristan. |