UPDATE MANAGER pack failure
No se ha podido inicializar la información de los paquetes Ha ocurrido un problema imposible de corregir cuando se inicializaba la información de los paquetes. Por favor, informe de ésto como un fallo en el paquete «update-manager» e incluya el siguiente mensaje de error: 'W:Duplicate sources.list entry http://archive.canonical.com hardy/partner Packages (/var/lib/apt/lists/archive.canonical.com_ubuntu_dists_hardy_partner_binary-i386_Packages), E:Problem parsing dependency Depends, E:Ocurrió un error mientras se procesaba btnx (NewVersion1), E:Problem with MergeList /var/lib/apt/lists/repoubuntusoftware.info_dists_harty_all_binary-i386_Packages, E:No se pudieron analizar o abrir las listas de paquetes o el archivo de estado.'
Re: UPDATE MANAGER pack failure
Aditional information: Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='lin$ uname output: Linux sgae-laptop 2.6.24-19-generic #1 SMP Fri Jul 11 23:41:49 UT$ Machine Type: i486-pc-linux-gnu Bash Version: 3.2 Patch Level: 39 Release Status: release El 13 de octubre de 2008 10:44, Jose Manuel <[EMAIL PROTECTED]> escribió: > No se ha podido inicializar la información de los paquetes > > Ha ocurrido un problema imposible de corregir cuando se inicializaba la > información de los paquetes. > > Por favor, informe de ésto como un fallo en el paquete «update-manager» e > incluya el siguiente mensaje de error: > > 'W:Duplicate sources.list entry http://archive.canonical.com hardy/partner > Packages > (/var/lib/apt/lists/archive.canonical.com_ubuntu_dists_hardy_partner_binary-i386_Packages), > > E:Problem parsing dependency Depends, > E:Ocurrió un error mientras se procesaba btnx (NewVersion1), > E:Problem with MergeList > /var/lib/apt/lists/repoubuntusoftware.info_dists_harty_all_binary-i386_Packages, > > E:No se pudieron analizar o abrir las listas de paquetes o el archivo de > estado.' >
Re: "wait" bug, now or ever?
On Sat, Oct 11, 2008 at 07:29:05PM -0600, Bob Proulx wrote: > Larry Clapp wrote: > > He asserts "The wait command waits until a program has *completely* > > finished", or words to that effect. > > That is specious reasoning at best. Agree. > > Basically he says he's seen where a program does some redirection, > > exits, and the file isn't done yet: > > > > some_program > some_file > > # some_file isn't finished yet! > > wait > > # Now it's done! > > I rarely state things in absolutes and it makes me uncomfortable to > do so but let me say that this is just plain wrong. That isn't what > is happening. There is no basis for it. This might as well be fear > of stepping on a sidewalk crack or skipping the number 13 or > knocking on wood. This reads more of superstition and not of any > actual causality. Agree. > > I have not cornered him on the exact circumstances in which he's > > seen this behavior, but I certainly never have -- > > I think I can shed some light on this behavior. I am sure that he > is misinterpreting NFS filesystem buffering and its lack of cache > coherency. This type of problem is common in NFS environments. But > it has nothing to do with the above example. It occurs when > accessing files from different hosts using different filesystem > buffer caches. People accidentally trip into this problem very > often when using ssh/rsh or job queue systems or anything that > coordinates processes on different machines that access the same > files. This is a very common problem. I feel confident that this > is the root of the superstition and that workarounds for it are > being applied inappropriately in other contexts. > > Search the web for nfs cache coherency and specifically > close-to-open cache consistency and you should find much discussion > of the problems. See specifically the Linux NFS FAQ. I'll look into that, but ... > > Here are my thoughts on this behavior, most likely first: > > > > - I tend to think he had some code at one point that he didn't > > completely understand (or had forgotten some details of) that > > was running stuff in background and he didn't realize it, and he > > experienced this problem, and the "wait" fixed it, so he's > > scattered "waits" around his scripts ever since. > > I am sure you are correct here. I am sure that this person used to > work in an NFS environment across multiple machines and ran into NFS > cache coherency issues. I am confident this guess is very likely. ... even assuming cache coherency problems, I don't see how the extra "wait" would have fixed the problem. On the other hand, as I said, I've not nailed down the exact circumstances; I'd suspect he saw this problem at the command line, not in a script. Just the extra time of typing "wait" might solve the problem, leading to misguided belief in waiting unnecessarily. In any case, the exact *cause* of the superstition doesn't matter (though I definitely appreciate the pointer to NFS problems), I just wanted to poll the bash community whether anyone had seen a bug like this anywhere. > Good luck! > > Bob Thanks, Bob! -- Larry
Re: UPDATE MANAGER pack failure
Jose Manuel wrote: > No se ha podido inicializar la información de los paquetes > > Ha ocurrido un problema imposible de corregir cuando se inicializaba la > información de los paquetes. Pardon me for my reply in English but my Spanish is not intelligible. You have reached the GNU Bash mailing list. GNU Bash is the command shell of the GNU Operating System. You can learn more about GNU Bash here: http://www.gnu.org/software/bash/ GNU Bash is part of the GNU Operating System. You can learn more about the GNU Project here: http://www.gnu.org/ But you are asking about Ubuntu's package management system. I am sorry but this is the wrong mailing list. We do not know anything about Ubuntu's package management system. We are unable to help you here. > Por favor, informe de ésto como un fallo en el paquete «update-manager» e > incluya el siguiente mensaje de error: > ... > E:Problem parsing dependency Depends, > E:Ocurrió un error mientras se procesaba btnx (NewVersion1), > E:Problem with MergeList > /var/lib/apt/lists/repoubuntusoftware.info_dists_harty_all_binary-i386_Packages, > > E:No se pudieron analizar o abrir las listas de paquetes o el archivo de > estado.' Since you are using Ubuntu then the Ubuntu users mailing lists would be a better source of information. http://www.ubuntu.com/support/communitysupport http://www.ubuntu.com/support/community/mailinglists Bob
Re: UPDATE MANAGER pack failure
Thank you for your kind reply. I will try the links you mention. Very truly yours, José Manuel Gómez Agost 2008/10/13 Bob Proulx <[EMAIL PROTECTED]> > Jose Manuel wrote: > > No se ha podido inicializar la información de los paquetes > > > > Ha ocurrido un problema imposible de corregir cuando se inicializaba la > > información de los paquetes. > > Pardon me for my reply in English but my Spanish is not intelligible. > > You have reached the GNU Bash mailing list. GNU Bash is the command > shell of the GNU Operating System. You can learn more about GNU > Bash here: > > http://www.gnu.org/software/bash/ > > GNU Bash is part of the GNU Operating System. You can learn more > about the GNU Project here: > > http://www.gnu.org/ > > But you are asking about Ubuntu's package management system. I am > sorry but this is the wrong mailing list. We do not know anything > about Ubuntu's package management system. We are unable to help you > here. > > > Por favor, informe de ésto como un fallo en el paquete «update-manager» e > > incluya el siguiente mensaje de error: > > ... > > E:Problem parsing dependency Depends, > > E:Ocurrió un error mientras se procesaba btnx (NewVersion1), > > E:Problem with MergeList > > > /var/lib/apt/lists/repoubuntusoftware.info_dists_harty_all_binary-i386_Packages, > > > > E:No se pudieron analizar o abrir las listas de paquetes o el archivo de > > estado.' > > Since you are using Ubuntu then the Ubuntu users mailing lists would > be a better source of information. > > http://www.ubuntu.com/support/communitysupport > > http://www.ubuntu.com/support/community/mailinglists > > Bob >
'bash -c' does not execute 'trap ... EXIT' command when last command is an external command
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall uname output: Linux fips 2.6.24-1-amd64 #1 SMP Sat May 10 09:28:10 UTC 2008 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 3.2 Patch Level: 39 Release Status: release Description: 'bash -c' does not execute a 'trap ... EXIT' command when the last command is an external command. Repeat-By: bash -c ' trap "echo EXIT" EXIT /bin/true ' does not produce any output (should write "EXIT"). If an additional newline is included after "/bin/true" the example works. The reason seems to be that bash uses exec() for the last command instead of fork() and exec(). smime.p7s Description: S/MIME cryptographic signature
Re: defualt directory problem for non-login session
Thank you very much. It worked. :)) On Tue, Oct 7, 2008 at 9:05 AM, Andreas Schwab <[EMAIL PROTECTED]> wrote: > s_vijay65 <[EMAIL PROTECTED]> writes: > > > I am invoking bash as non-login shell i.e. using execvp() from my > > application, but when the bash returns prompt the defualt directory is > /dev. > > I want $HOME should be my defualt directory after login to bash. > > You need to change to that directory in the caller, before executing the > shell. > > Andreas. > > -- > Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] > SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany > PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different." > -- Regards Vijay S.
