Pacman

Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.
Tasklist

FS#6316 - Pacman 3 release bugcatcher

Attached to Project: Pacman
Opened by Dan McGee (toofishes) - Thursday, 01 February 2007, 00:28 GMT
Last edited by Aaron Griffin (phrakture) - Thursday, 17 May 2007, 07:02 GMT
Task Type Bug Report
Category General
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture All
Severity High
Priority High
Reported Version 2.9.8
Due in Version Undecided
Due Date 2007-03-01
Percent Complete 100%
Votes 0
Private No

Details

Bug collector for Pacman 3 release.

Non-bug issues to hopefully resolve:
DONE - Clean up documentation - make sure man pages are updated
DONE - Add translation guide
DONE - Clean up NEWS file
DONE - Add repo-remove script
DONE - Clean up README file
DONE - Fix gensync/updatesync
DONE - Fix up translations
DONE - Review documentation

PENDING - devtools and gerolde repo scripts (can hold for a bit)

DEFERRED - libalpm Doxygen man pages - todo, may have to wait until 3.1...
Closed by  Aaron Griffin (phrakture)
Thursday, 17 May 2007, 07:02 GMT
Reason for closing:  None
Additional comments about closing:  Just closing this, as it was a pre-release bugcatcher and we've already released
Comment by Aaron Griffin (phrakture) - Thursday, 08 February 2007, 16:03 GMT
Added a bug entry for output issues, as a reminder and collector.
Comment by Dan McGee (toofishes) - Friday, 09 February 2007, 18:31 GMT
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.
Comment by Roman Kyrylych (Romashka) - Friday, 09 February 2007, 23:27 GMT
I added Total Download Size feature request because it can be implemented along with other output fixes/changes.
Comment by Aaron Griffin (phrakture) - Monday, 12 February 2007, 09:21 GMT
Added two "requires testing" bugs - if anyone has the capability, please test them.
Comment by Björn Martensen (baze) - Wednesday, 14 February 2007, 15:27 GMT
you should replace mkinitrd.conf with mkinitcpio.conf in the pacman3.conf.
Comment by Jeff Mickey (codemac) - Wednesday, 14 February 2007, 22:59 GMT
I added my segfault error to this page.
Comment by Georg Grabler (STiAT) - Thursday, 15 February 2007, 10:50 GMT
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.

Comment by Georg Grabler (STiAT) - Thursday, 15 February 2007, 16:20 GMT
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.
Comment by Aaron Griffin (phrakture) - Thursday, 15 February 2007, 16:25 GMT
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?
Comment by Georg Grabler (STiAT) - Monday, 19 February 2007, 16:47 GMT
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__
Comment by Georg Grabler (STiAT) - Monday, 19 February 2007, 16:56 GMT
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";);
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";);

printf ("\nWGET %d\n", x);
printf ("\nSHIFT %d\n", x >> 8);
}
Comment by Aaron Griffin (phrakture) - Monday, 19 February 2007, 17:21 GMT
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?
Comment by Georg Grabler (STiAT) - Monday, 19 February 2007, 23:31 GMT
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 :).
Comment by Georg Grabler (STiAT) - Tuesday, 20 February 2007, 08:06 GMT
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.
Comment by Aaron Griffin (phrakture) - Tuesday, 20 February 2007, 17:43 GMT
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?
Comment by Jaroslaw Swierczynski (swiergot) - Sunday, 25 February 2007, 14:23 GMT
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.
Comment by Dan McGee (toofishes) - Sunday, 25 February 2007, 16:39 GMT
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.
Comment by Jaroslaw Swierczynski (swiergot) - Sunday, 25 February 2007, 17:09 GMT
You're right, I didn't have the latest version. It works now.
Comment by Łukasz Fibinger (lucke) - Sunday, 04 March 2007, 14:03 GMT
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?


Comment by Roberto Braga (Bobonov) - Wednesday, 28 March 2007, 13:41 GMT
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.



Comment by DaNiMoTh (DaNiMoTh) - Wednesday, 04 April 2007, 14:50 GMT
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
Comment by Darío A. (darzephyr) - Saturday, 07 April 2007, 18:28 GMT
I fill a new bug report:
Pacman pkg version check fails (1.8b < 1.8)
http://bugs.archlinux.org/task/6834

Loading...