Arch Linux

Added a bug entry for output issues, as a reminder and collector.

We were getting too much done on closing out all the bugs here, so I put a few makepkg ones on that are worth a look. If we don't fix them all in time for 3.0 release, it is probably fine, but we can at least take a look at them; some of them could be quite simple fixes.

I added Total Download Size feature request because it can be implemented along with other output fixes/changes.

Added two "requires testing" bugs - if anyone has the capability, please test them.

you should replace mkinitrd.conf with mkinitcpio.conf in the pacman3.conf.

I added my segfault error to this page.

My notebook broke down, i've revisited the documentation, looks fine so far, just found some things, like words were missing... overall, the documentation seems to be complete.

Will get it back form the service tomorrow, so i can send mails again (writing from work).

I lately had problems with the cvs version at downloading packages. I compiled the version in cvs of last sunday, and pacman calculated everything, but did not download any package.

Hello,

What i think is annoying in pacman, if i hit STRG+C to cancel a installation, pacman tries all mirrors for all packages while i hold STRG+C pressed.

Is there no way to get pacman exiting? I mean, usually wget should return some exit code telling it hasn't been a download error.

It looks like wget returns 1 on failure, but 130 on C-c, can anyone verify this, I can't seem to find the C-c return code in the docs.

Just to clarify what was said above: You mean that when using wget, C-c cancels wget but not pacman, correct?

No proxy / no connection
WGET RETURN: 256
WGET SHIFT: 1 (8 bit)

CTRL + C
WGET RETURN: 2
WGET SHIFT: 0 (8 bit)

WGET SUCCESS
WGET RETURN: 0
WGET SHIFT: 0 (8 bit)

In spite of the 128 offset, this test actually confirms your output.

Tested: perlscript
Files: acl for success, OpenOffice for abort-tests
#!/usr/bin/perl

use strict;
use warnings;

my $x = system ("wget ftp://ftp.archlinux.org/0.8/os/x86_64/acl-2.2.39-1.pkg.tar.gz");

printf ("\n\n\nWGET RETURN: %d\n", $x);
printf ("WGET SHIFT: %d\n", $x >> 8);

my $x = system ("wget http://openoffice-chi.osuosl.org/stable/2.1.0/OOo_2.1.0_LinuxIntel_install_en-US.tar.gz");

printf ("\n\n\nWGET RETURN: %d\n", $x);
printf ("WGET SHIFT: %d\n", $x >> 8);

1;
__END__

Ahm, how do you call wget?

Too bad i can't checkout the CVS here, i now used a C program to check this, and wget also returned the same values due to the system command.

C-Code:
#include <stdio.h>
#include <stdlib.h>

int main() {
int x;
x = system ("wget ftp://ftp.archlinux.org/0.8/os/x86_64/acl-2.2.39-1.pkg.tar.gz&quot;);
printf ("\nWGET %d\n", x);
printf ("\nSHIFT %d\n", x >> 8);

x = system ("wget http://openoffice-chi.osuosl.org/stable/2.1.0/OOo_2.1.0_LinuxIntel_install_en-US.tar.gz&quot;);

printf ("\nWGET %d\n", x);
printf ("\nSHIFT %d\n", x >> 8);
}

Well, the biggest problem here is that we're not guaranteed to be using wget. What about 'snarf' or 'curl'?
Before adding something like this, I think we need a unified scheme for this detection.

Does it sound plausible to use XferCommand's return code, if 0, success, if 1, try another mirror, else, abort?

You're right, we should think about other downloaders, unless someone wants to implement a library for builtin downloading - but that would be like re-inventing the wheel.

It sounds plausible, indeed. I'll try tomorrow by specifying other downloaders in the programs than wget, to find out if it actually matches.
I've no idea how many there are, but a good start would be snarf and curl. I have always been looking for a downloader supressing the proxy connect messages, maybe that's my way to go :).

Attached the test results.

Overall, snarf, curl and wget seem to have the same exit code if strg+c was pressed. This might be due to strg+c rather being an interrupt than an exit handled by the program, that's why they don't have an exit code > 1 if the 8 bits are shifted.

They don't differ in downloaded successfully.
The only difference is the exit code handled by the program if no connection was available. Maybe it should be tested with more downloaders, but i think it's a good start overall.

Note:
The first output value always is the unshifted value, the 2nd the shifted one.

Georg - pacman3 supports proxies just fine. I will try to add some support for C-c'ing out of an Xfercommand, but I can't guarantee success. Perhaps the proper course of action is to just use pacman's normal downloading?

I guess I've found a bug.

# pacman3 -Su
:: Starting full system upgrade...
warning: psi: local (0.11beta4-1) is newer than extra (0.10-2)
resolving dependencies... done.
error: failed to prepare transaction (could not satisfy dependencies)
:: firefox-i18n requires firefox=2.0.0.2

# pacman3 -Ss firefox
current/firefox 2.0.0.2-1
Standalone web browser from mozilla.org
extra/firefox-i18n 2.0.0.2-1
Language packs for Firefox

The old pacman doesn't have this problem.

What version of the RC were you running? I believe we fixed this issue, as it came up earlier with another package. Try the most recent release and see if you can duplicate it.

You're right, I didn't have the latest version. It works now.

Two issues with the latest rc (2007.02.22):

if I execute -Syu and there are some updates available, when I press [y] after few minutes (not instantly) it just quits to the prompt, leaving pacman.lck in /tmp.

is this double notation:
warning: grub-0.97-2: ignoring package upgrade (0.97-7)
warning: grub-0.97-2: ignoring package upgrade (0.97-2 => 0.97-7)
needed?

I use pacman 3 from testing
The error is related to a fail in dependencies check when using -Rc option in removing packages.
Here follow the story:
Today I was doing a bit of room on my hd so I decided to uninstall gnome.
I was doing that step by step each time using -Rc option, at a certain point I removed control-center package and went on without error.
After that I tried to remove some other package, here follow the line but I think is trivial to know the package

pacman -Rc gnome-python gnome-vfs gnomesu gtksourceview gucharmap icon-naming-utils gnome-keyring gnome-mime-data

And I've got the following error message in loop (I had to press ctrl-c to sto it):
errore: impossibile trovare control-center nel database, sarà ignorato
Basically it say that was not possible to find control-center in the database and it will be ignored.

I guess pacman wanted to remove control-center because it depends on one of the above package.
Beside the loop problem, pacman continuously print out the message but does not goes on, I think that it is superfluous to print out this message.

Let me know if you need more info or test.

I use pacman 3.0.1-1 from testing repo. I see that it, when I try to remove a package, doesn't run pre_remove and post_remove function in .install file. I see that on compiz package ( from community repo ).
I think this issue is simply reproducible adding an echo() line on any .install file, recompiling such package , upgrade it and try to remove it.

If you want more information, I'm freely contactable on IRC or via e-mail.
Thanks

I fill a new bug report:
Pacman pkg version check fails (1.8b < 1.8)
http://bugs.archlinux.org/task/6834