dpkg-http and proxy cache
i have squid cache
i have dpkg-http
there was a time, when it worked. i could do [U]pdate in dselect, and he
used the version of Packages.gz in the Cache.
i can check that he uses the cache, because if i stop the cache, he fails.
i can check, that the cache caches the file with Netscape.
but i do not know, why dpkg-http doesn't take the cached version !
this is my /var/lib/dpkg/methods/http/vars:
+ SNIP
$ENV{ftp_proxy} = 'http://localhost:3128/';
$proxy_ftp = 1;
$ENV{http_proxy} = 'http://localhost:3128/';
@site = ( 'ftp://ftp.de.debian.org/pub/debian/',
'ftp://nonus.debian.org/pub/debian-non-US/' );
$distribs{'ftp://ftp.de.debian.org/pub/debian/'}="dists/hamm/main/binary-i386
dists/hamm/non-free/binary-i386 dists/hamm/contrib/binary-i386";
$distribs{'ftp://nonus.debian.org/pub/debian-non-US/'}="hamm/binary-i386";
$use_authorization_basic = 0;
$auth_user = "";
$auth_passwd = "";
$dldir = "debian";
1;
+ SNAP
dpkg-http 0.14
dpkg1.4.0.22
my system is quite updated hamm 2.0 with i386
byebye
Erik
--
EMAIL: [EMAIL PROTECTED]
[EMAIL PROTECTED] o `QQ'_
IRC: erikyyy/ __8
WWW: http://wwwcip.rus.uni-stuttgart.de/~inf24628/ ' `
http://tick.informatik.uni-stuttgart.de/~thieleek/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
consistency check
hm. after updating some packages i found out that old directories still exist. (the older packages didn't clean themselves the right way) should there be a possibility to do something like dpkg --overall-consistency-check to check the whole system ? e.g. every package that has a checkscript gets this checkscript executed. this way some kernel packages could check, that the user doesn't install the wrong include files by hand, because he thinks, debian is wrong, and he is right instead (asm,scsi,linux, you know the problem...) emacs packages could warn you that you still didn't erase the old directories. of course all files that are in the package could be checked. (e.g. did the user remove /bin/sh ?) etc. i am always not sure, wether my system is OK. :) sometimes it might be useful to do a new installation (no update) only because then much of the old unneeded rubbish is gone. byebye Erik -- EMAIL: [EMAIL PROTECTED] [EMAIL PROTECTED] o `QQ'_ IRC: erikyyy/ __8 WWW: http://wwwcip.rus.uni-stuttgart.de/~inf24628/ ' ` http://tick.informatik.uni-stuttgart.de/~thieleek/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 21164 must be fixed before 2.0.34 comes out!
On Sat, 25 Apr 1998, Herbert Xu wrote: > In article <[EMAIL PROTECTED]> you wrote: > > bug 21164 does not seem to be a bug in the libc. > > it is instead a kernel bug. > > FWIW, I just tried it on my Debian 2.0 2.0.32 machine: what means FWIW ? > $ ./yyys > Killed this shows, that you have the bug installed on your system :-) -- EMAIL: [EMAIL PROTECTED] [EMAIL PROTECTED] o `QQ'_ IRC: erikyyy/ __8 WWW: http://wwwcip.rus.uni-stuttgart.de/~inf24628/ ' ` http://tick.informatik.uni-stuttgart.de/~thieleek/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
21164 must be fixed before 2.0.34 comes out!
bug 21164 does not seem to be a bug in the libc. it is instead a kernel bug. ( new information can be found at http://www.debian.org/Bugs/db/21/21164.html unfortunately the bug tracking system is slow, so you won't see my message yet. basically the new message sais the following: ) i first tried it on debian 1.3.1 with libc5 and 2.0.33. the bug appeared. then i tried it on debian 2.0 with libc6 and 2.0.33. the bug appeared. then someone else tried it on 2.1.?? and the bug was GONE ! this seems to mean, that there is a bad bug in 2.0.33. i do not know, who i shall send some email. i hope one of you knows the right person to fix the problem. if the bug won't be fixed in 2.0.34, you will not be able to do realtime threads in 2.0.34. byebye Erik -- EMAIL: [EMAIL PROTECTED] [EMAIL PROTECTED] o `QQ'_ IRC: erikyyy/ __8 WWW: http://wwwcip.rus.uni-stuttgart.de/~inf24628/ ' ` http://tick.informatik.uni-stuttgart.de/~thieleek/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: signals and atomicity
On Thu, 23 Apr 1998, Roman Hodek wrote:
>
> > if you implement "interruptible" system calls this way: 1. UNBLOCK
> > SIGNAL 2. SYSTEM CALL 3. BLOCK SIGNAL it may happen that the signal
> > handler is called just after unblocking the signal but before the
> > call. this way no EINTR happens, the signal is lost and (2) is stuck
> > in the system call.
> >
> > because of this, i have to do a siglongjmp() in the signal handler.
> > now it isn't anymore possible that signals get lost. BUT ! i do not
> > know the return value of the system call, if it was interrupted.
> > remember, after the call , the signal is blocked again. now, if the
> > call succeeded, but still before the BLOCK SIGNAL command, if now
> > again a signal is received, siglongjmp jumps away, and the fact,
> > that the system call succeeded is just lost.
>
> You can solve it this way (at least I hope... :-) :
>
> static int timeout;
>
> static void alarm_handler(int sig) {
> timeout = 1;
> }
>
> int wait_or_timeout (int *status) {
> struct sigaction act;
> int wait_retval;
>
> timeout = 0;
>
> sigaction(SIGALRM, 0, &act);
> act.sa_handler = alarm_handler;
> act.sa_flags &= ~SA_RESTART;
> sigaction(SIGALRM, &act, 0);
> alarm(1);
> wait_retval = wait(status);
> alarm(0);
> /* ... */
> }
>
> If 'timeout' is set at the end, SIGALRM was delivered before the
> alarm(0). On the other hand, wait_retval is -EINTR if and only if the
> system call itself has been interrupted. So you can distinguish
> between the cases "system call interrupted" and "signal arrived, but
> somewhere around the syscall".
>
no. this is no solution, because:
once you activate the signal with sigaction, the sender might send a
signal, and this one will be lost.
so the thing that i wanted (i wanted that NO signal gets lost) does not
work.
the problem cannot be solved without using siglongjmp().
i am sure, the problem cannot be solved with this library+operating
system :-(
(or does anyone know some assembler hacks ?)
byebye
Erik
--
EMAIL: [EMAIL PROTECTED]
[EMAIL PROTECTED] o `QQ'_
IRC: erikyyy/ __8
WWW: http://wwwcip.rus.uni-stuttgart.de/~inf24628/ ' `
http://tick.informatik.uni-stuttgart.de/~thieleek/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: signals and atomicity
On Thu, 23 Apr 1998, Herbert Xu wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > On Sat, 18 Apr 1998, Herbert Xu wrote:
> >> This should work:
> >>
> >> static int wait_or_timeout_retval = -1;
> >>
> >> static void alarm_handler(int sig) {
> >>errno = ETIMEDOUT;
> >> }
> >>
> >> int wait_or_timeout (int *status) {
> >>struct sigaction act;
> >>
> >>wait_or_timeout_retval = -1;
> >>
> >>sigaction(SIGALRM, 0, &act);
> >>act.sa_handler = alarm_handler;
> >>act.sa_flags &= ~SA_RESTART;
> >>sigaction(SIGALRM, &act, 0);
> >>alarm(1);
> >>wait_or_timeout_retval = wait(status);
> >>alarm(0);
> >>return wait_or_timeout_retval;
> >> }
>
> > i do not think, this works.
>
> > alarm() calls setitimer(). setitimer() modifies "errno".
> > so, setting errno inside the signal handler does not work, i think.
>
> That's easy to fix. Just store ETIMEDOUT in some other variable that is
> reset at the start of wait_or_timeout and store the result in errno if wait
> fails with EINTR.
this way you can fix the problem. but my initial problem was different:
2 processes. if (1) does a specific call (probably raising a signal), B's
next interruptible (whatever this means) system call must be interrupted.
the fact that (1) raised the signal mustn't get lost.
if you implement "interruptible" system calls this way:
1. UNBLOCK SIGNAL
2. SYSTEM CALL
3. BLOCK SIGNAL
it may happen that the signal handler is called just after unblocking the
signal but before the call. this way no EINTR happens, the signal is lost
and (2) is stuck in the system call.
because of this, i have to do a siglongjmp() in the signal handler.
now it isn't anymore possible that signals get lost. BUT ! i do not know
the return value of the system call, if it was interrupted.
remember, after the call , the signal is blocked again. now, if the call
succeeded, but still before the BLOCK SIGNAL command, if now again a
signal is received, siglongjmp jumps away, and the fact, that the system
call succeeded is just lost.
i am looking for an atomic way for a process to interrupt another
processes next system call, __that is marked as interruptible (whatever
this means)__. the interrupt __mustn't get lost__. afterwards i must
always know, wether the system call succeeded, or not.
i find no way of doing it. this is why i said "the whole system is
shi." i am sorry about this sentence, but i was in a very bad mood,
because for weeks i try to solve this thing and i do not succeed.
byebye
Erik
--
EMAIL: [EMAIL PROTECTED]
[EMAIL PROTECTED] o `QQ'_
IRC: erikyyy/ __8
WWW: http://wwwcip.rus.uni-stuttgart.de/~inf24628/ ' `
http://tick.informatik.uni-stuttgart.de/~thieleek/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Blender 3D
http://www.neogeo.nl/blender.html binary doesn't work with debian hamm, because: [EMAIL PROTECTED]:~/b/blenderLinux_1.30 > ldd blender libMesaGLU.so.2 => not found libMesaGL.so.2 => not found libXmu.so.6 => /usr/lib/libc5-compat/libXmu.so.6 (0x4000b000) libXext.so.6 => /usr/lib/libc5-compat/libXext.so.6 (0x4001d000) libX11.so.6 => /usr/lib/libc5-compat/libX11.so.6 (0x40028000) libjpeg.so.6 => not found libm.so.5 => /lib/libm.so.5 (0x400c6000) libdl.so.1 => /lib/libdl.so.1 (0x400cf000) libc.so.5 => /lib/libc.so.5 (0x400d2000) libXt.so.6 => /usr/lib/libc5-compat/libXt.so.6 (0x4019) libSM.so.6 => /usr/lib/libc5-compat/libSM.so.6 (0x401d2000) libICE.so.6 => /usr/lib/libc5-compat/libICE.so.6 (0x401db000) [EMAIL PROTECTED]:~/b/blenderLinux_1.30 > ok, some libraries are not found. so i do [EMAIL PROTECTED]:~/b/blenderLinux_1.30 > export LD_LIBRARY_PATH=/usr/X11R6/lib [EMAIL PROTECTED]:~/b/blenderLinux_1.30 > ldd ./blender libMesaGLU.so.2 => /usr/X11R6/lib/libMesaGLU.so.2 (0x4000b000) libMesaGL.so.2 => /usr/X11R6/lib/libMesaGL.so.2 (0x40029000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x4013f000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40151000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4015d000) libjpeg.so.6 => not found libm.so.5 => /lib/libm.so.5 (0x4020) libdl.so.1 => /lib/libdl.so.1 (0x40209000) !! libc.so.5 => /lib/libc.so.5 (0x4020c000) !! libc.so.6 => /lib/libc.so.6 (0x402ca000) ld-linux.so.2 => /lib/ld-linux.so.2 (0x4036d000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40379000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x403c1000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x403ca000) i do not know, what i should do to run this program... same problem with another binary: http://rulhmpc38.leidenuniv.nl/private/multitrack/multitrack.html [EMAIL PROTECTED]:~/b/multitrack-2.1 > ldd ./multitrack libvga.so.1 => /usr/lib/libvga.so.1 (0x4000b000) libvgagl.so.1 => /usr/lib/libvgagl.so.1 (0x4000e000) libX11.so.6 => /usr/lib/libc5-compat/libX11.so.6 (0x40011000) libm.so.5 => /lib/libm.so.5 (0x400af000) !!libc.so.5 => /lib/libc.so.5 (0x400b8000) !!libc.so.6 => /lib/libc.so.6 (0x40176000) ld-linux.so.2 => /lib/ld-linux.so.2 (0x40219000) this one even loads both libcs at the same time, without any LD_* environment variables. what to do? byebye Erik -- EMAIL: [EMAIL PROTECTED] [EMAIL PROTECTED] o `QQ'_ IRC: erikyyy/ __8 WWW: http://wwwcip.rus.uni-stuttgart.de/~inf24628/ ' ` http://tick.informatik.uni-stuttgart.de/~thieleek/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: signals and atomicity
On Sat, 18 Apr 1998, Herbert Xu wrote:
> In article <[EMAIL PROTECTED]> you wrote:
>
> > if the signal occurs after the wait system call, but before the result of
> > the system call is stored in "wait_or_timeout_retval", the fact, that
> > the system call succeeded is lost.
>
> > this is (1) a bug in apache and (2) a problem of me that i want to solve.
> > i thought others would have solved it, but this is obviously not true :-(
>
> This should work:
>
> static int wait_or_timeout_retval = -1;
>
> static void alarm_handler(int sig) {
> errno = ETIMEDOUT;
> }
>
> int wait_or_timeout (int *status) {
> struct sigaction act;
>
> wait_or_timeout_retval = -1;
>
> sigaction(SIGALRM, 0, &act);
> act.sa_handler = alarm_handler;
> act.sa_flags &= ~SA_RESTART;
> sigaction(SIGALRM, &act, 0);
> alarm(1);
> wait_or_timeout_retval = wait(status);
> alarm(0);
> return wait_or_timeout_retval;
> }
i do not think, this works.
alarm() calls setitimer(). setitimer() modifies "errno".
so, setting errno inside the signal handler does not work, i think.
i think the whole system is shit. it cannot work this way.
there is no single way to solve this problem with linux :-( i am very
unhappy.
again, this is what i want:
thread A: calls signalthread_B. must return IMMEDIATELY.
thread B: IF it just is inside a system call, this call must return EINTR.
IF not, the NEXT system call that is marked as INTERRUPTIBLE
(however this works) must return EINTR.
what is this good for ?
well. threads communicate through message queues. but B will not receive
the message from A, if he is stuck in a system call.
so A calls signalthread_B, if it is possible, that B ever gets locked in
system calls. of course, ONLY system calls marked as INTERRUPTIBLE may
return EINTR. (otherwise one would have to check the return code of EVERY
system call.
it is extremly important, that signalthread_B doesn't get lost, i.e. B
just doesn't get the EINTR.
byebye
Erik
--
EMAIL: [EMAIL PROTECTED]
[EMAIL PROTECTED] o `QQ'_
IRC: erikyyy/ __8
WWW: http://wwwcip.rus.uni-stuttgart.de/~inf24628/ ' `
http://tick.informatik.uni-stuttgart.de/~thieleek/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
realtime lock bug in linuxthreads
hi i found a quite important and "grave" bug , but due to some problems i do not understand, the bug reporting system said it is a "boring" report. please read #21164. it shows how to lock down the whole system with just a few system calls. anyway, these system calls have nothing to do with locking the system, so this is a bug! it makes it quite impossible to use realtime threads in linux. (works only as root user) byebye erik -- EMAIL: [EMAIL PROTECTED] [EMAIL PROTECTED] o `QQ'_ IRC: erikyyy/ __8 WWW: http://wwwcip.rus.uni-stuttgart.de/~inf24628/ ' ` http://tick.informatik.uni-stuttgart.de/~thieleek/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
signals and atomicity
hi, i found the following code in apache web server code.
if the signal occurs after the wait system call, but before the result of
the system call is stored in "wait_or_timeout_retval", the fact, that
the system call succeeded is lost.
this is (1) a bug in apache and (2) a problem of me that i want to solve.
i thought others would have solved it, but this is obviously not true :-(
now perhaps it is not interesting, wether the wait call succeeded, because
you can start it again. but what about a call to "read()" ? i MUST know,
wether it worked or wether it was interrupted by a signal!
byebye
Erik
o snap
static JMP_BUF wait_timeout_buf; static int wait_or_timeout_retval = -1;
static void longjmp_out_of_alarm (int sig) {
siglongjmp (wait_timeout_buf, 1);
}
int wait_or_timeout (int *status) {
wait_or_timeout_retval = -1;
if (sigsetjmp(wait_timeout_buf, 1) != 0) {
errno = ETIMEDOUT;
return wait_or_timeout_retval;
}
signal (SIGALRM, longjmp_out_of_alarm);
alarm(1);
wait_or_timeout_retval = wait(status);
alarm(0);
return wait_or_timeout_retval;
}
o--- snip
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
