Bug in progresbar in pacman ??

I updated my x but the progresbar acted kinda weird. is this a bug ??
Targets: gkrellm-2.1.7-2 man-pages-1.56-1 pacman-2.3-4 pango-1.2.1-2
xfree86-4.3.0-2
Do you want to install/upgrade these packages? [Y/n]
:: Retrieving packages from current...
gkrellm-2.1.7-2.pkg.tar. [#################################] 100% | 545K
man-pages-1.56-1.pkg.tar [#################################] 100% | 1285K
pacman-2.3-4.pkg.tar.gz [#################################] 100% | 272K
pango-1.2.1-2.pkg.tar.gz [#################################] 100% | 299K
xfree86-4.3.0-2.pkg.tar. [######## ] 24% | 55910K
loading package data... done.

Yes, this is a very old known bug. You don't have to care: it has no impact at all.
Hey! Have a look at the bugtracker: it is nearly the birthday of this bug
I forgot it was existing until I upgraded xfree86 yesterday.
I've made a fix for it today.
It should be corrected soon. Stay tuned

Similar Messages

Pacman - his error messages - and clarity

first
[root@gateway ~]# pacman -Syu
:: Synchronizing package databases...
current [################] 100% 41K 12.7K/s 00:00:03
extra [################] 100% 164K 19.9K/s 00:00:08
Targets: abiword-2.0.12-1 dbh-1.0.20-1 doxygen-1.3.9.1-1 evolution-2.0.2-2
evolution-data-server-1.0.2-1 flac-1.1.1-1 gaim-1.0.1-1 gal-2.2.3-1
gdm-2.6.0.5-2 gimp-2.0.5-1 glib2-2.4.7-1 gmp-4.1.4-1
gnome-panel-2.8.1-1 heimdal-0.6.2-1 gnome-vfs-2.8.2-1 gqview-1.4.5-1
jack-audio-connection-kit-0.99.0-1 gst-plugins-0.8.5-1
gstreamer-0.8.7-1 gtk2-2.4.13-1 gtkhtml-3.2.3-1 imagemagick-6.1.1-1
imlib-1.9.15-1 iptables-1.2.11-3 libogg-1.1.2-1 libsoup-2.2.1-1
libtiff-3.6.1-4 libvorbis-1.1.0-1 man-pages-1.69-1 mozilla-1.7.3-1
mozilla-firefox-0.10.1-2 nautilus-2.8.1-1 perl-html-parser-3.36-1
reiserfsprogs-3.6.19-1
Total Package Size: 94.8 MB
Proceed with upgrade? [Y/n]
:: Retrieving packages from current...
abiword-2.0.12-1 [################] 100% 3683K 29.3K/s 00:02:05
doxygen-1.3.9.1-1 [################] 100% 1278K 23.1K/s 00:00:55
gaim-1.0.1-1 [################] 100% 3964K 27.2K/s 00:02:25
gimp-2.0.5-1 [################] 100% 10290K 25.7K/s 00:02:24
glib2-2.4.7-1 [################] 100% 1082K 25.8K/s 00:00:41
gmp-4.1.4-1 [################] 100% 240K 32.0K/s 00:00:07
gqview-1.4.5-1 [################] 100% 298K 25.1K/s 00:00:11
gtk2-2.4.13-1 [################] 100% 6229K 24.6K/s 00:04:13
imagemagick-6.1.1-1 [################] 100% 4317K 24.9K/s 00:02:53
imlib-1.9.15-1 [################] 100% 535K 36.3K/s 00:00:14
iptables-1.2.11-3 [################] 100% 243K 23.2K/s 00:00:10
libogg-1.1.2-1 [################] 100% 19K 14.6K/s 00:00:01
libtiff-3.6.1-4 [################] 100% 450K 23.6K/s 00:00:19
libvorbis-1.1.0-1 [################] 100% 451K 24.2K/s 00:00:18
man-pages-1.69-1 [################] 100% 3638K 28.5K/s 00:02:07
mozilla-firefox-0.10.1-2 [################] 100% 11678K 27.3K/s 00:02:52
reiserfsprogs-3.6.19-1 [################] 100% 441K 29.7K/s 00:00:14
:: Retrieving packages from extra...
dbh-1.0.20-1 [################] 100% 25K 7.9K/s 00:00:03
evolution-2.0.2-2 [################] 100% 10527K 15.9K/s 00:02:31
evolution-data-server-1. [################] 100% 1330K 12.0K/s 00:01:50
flac-1.1.1-1 [################] 100% 587K 20.6K/s 00:00:28
gal-2.2.3-1 [################] 100% 1326K 16.9K/s 00:01:18
gdm-2.6.0.5-2 [################] 100% 2805K 28.6K/s 00:01:38
gnome-panel-2.8.1-1 [################] 100% 2705K 24.5K/s 00:01:50
heimdal-0.6.2-1 [################] 100% 1297K 17.6K/s 00:01:13
gnome-vfs-2.8.2-1 [################] 100% 1479K 27.2K/s 00:00:54
jack-audio-connection-ki [################] 100% 186K 26.6K/s 00:00:07
gst-plugins-0.8.5-1 [################] 100% 1940K 19.0K/s 00:01:42
gstreamer-0.8.7-1 [################] 100% 1511K 21.9K/s 00:01:09
gtkhtml-3.2.3-1 [################] 100% 1246K 20.7K/s 00:01:00
libsoup-2.2.1-1 [################] 100% 222K 29.2K/s 00:00:07
mozilla-1.7.3-1 [################] 100% 16636K 25.8K/s 00:02:12
nautilus-2.8.1-1 [################] 100% 4109K 10.0K/s 00:02:35
perl-html-parser-3.36-1 [################] 100% 78K 24.1K/s 00:00:03
checking package integrity... done.
loading package data... done.
checking for file conflicts...
error: the following file conflicts were found:
heimdal: /usr/man/man8/rshd.8.gz: exists in filesystem
errors occurred, no packages were upgraded.
[root@gateway ~]# pacman -Ql /usr/man/man8/rshd.8.gz
Package "/usr/man/man8/rshd.8.gz" was not found.
[root@gateway ~]# pacman -Qo /usr/man/man8/rshd.8.gz
/usr/man/man8/rshd.8.gz is owned by netkit-rsh 0.17-2
[root@gateway ~]# pacman --version
.--. Pacman v2.9.2
/ _.-' .-. .-. .-. Copyright (C) 2002-2004 Judd Vinet <[email protected]>
'--' This program may be freely redistributed under
the terms of the GNU General Public License
[root@gateway ~]#
Little addon ... maybe pacman could say something about "overwriting" files...
if its intended to.. or should never ever happen... whatever.. maybe with msg's the pkg-distributer made himself (cuz at least he should know WHY of IF it should happen )
this could be achieved by putting info in the pgk that there will be files to overwrite... so the user still is able to say "oh no don't touch it!" if he doesn't want pac'y to do that...
like:
REWORKDESTINATION=" /usr/man/man8/rshd.8.gz /foo/bar"
REWORKMESSAGE="1. just cuz im funny... <split> 2. heavy bugs fixed"
[root@gateway ~]# pacman -S heimdal
Targets: heimdal-0.6.2-1
Total Package Size: 1.3 MB
Proceed with upgrade? [Y/n]
checking package integrity... done.
loading package data... done.
checking for file conflicts...
error: the following file conflicts were found:
heimdal: /usr/man/man8/rshd.8.gz: exists in filesystem
reworkinfo: Just cuz im funny...
do you want to overwrite? (YES/no) :_
so you could also -f pac'y and he simply overwrites exept things on the <b>HoldPkg !</b> (so you still feel save with some things )
secondly
it would be nice to make pacman capable to download/install pgk with given versions... but as far as i see there are a lot threats about that
thirdly
it would also be nice if a pkg you install could add things to the pacman.conf like NoUpgrade and HoldPkg. ... eg. updating cups ... it saves the configfiles.. yeah... but as .pacsave and cups is after restarting the deamons unuseable cuz it loads with the new ones ... the other way round would be nicer...
so if you install cups the first time the pkg it self writes into pacman.conf:
NoUpgrade /etc/cups/cupsd.conf /etc/cups/classes.conf /etc/cups/client.conf /etc/cups/mime.convs /etc/cups/mime.types /etc/cups/printes.conf
maybe with a update function like:
Syntax: update(file, method, string1, string2);
example:
update(pacman.conf,add,"NoUpdate NoUpgrade /etc/cups/cupsd.conf /etc/cups/classes.conf /etc/cups/client.conf /etc/cups/mime.convs /etc/cups/mime.types /etc/cups/printes.conf, )
and when you remove the pkg it does automatically:
update(pacman.conf, remove, "NoUpgrade /etc/cups/cupsd.conf /etc/cups/classes.conf /etc/cups/client.conf /etc/cups/mime.convs /etc/cups/mime.types /etc/cups/printes.conf", )
this could also work with a substitute-method so in pkg-updates you can also update pacman.
i think that would heavily increase the power of pacman - wich already is a realy mighty thing

I like 1 and 3.... very good ideas - especially number 1.. it'd be nice to have overwrite functionality in packages
about number 2 - this issue has been brought up ad nauseum.... Arch is considered by users and developers a "bleeding edge distro" - that is, Arch uses the newest packages, assuming they work. allowing users to manually grab a non-bleeding edge package, or even downgrade their packages is, for lack of a better phrase, against policy. If something is not functional in a given package, then Arch as a whole should be downgraded until the package is working. If a new version replaces the old with differing functionality, the packages should be installed side-by-side (as is the case with gtk1 & gtk2, imlib & imlib2, and many more).
In a bleeding edge distro, downgrading a package simply because a user "likes SomePackage 0.9 better than 1.0" is not worthwhile. Package management would become so much more difficult and require much more space.
If there is a problem with a package (i.e. "I upgraded to Blah 0.6.5 from 0.6.3 and it doesn't work now") then the problem is most likely on your system and should be fixed. Blame the developers, blame yourself, whatever... the fact of the matter is you need to expect this sort of thing with Arch...

What's New in Pacman 2.6.2?

I am always curious about new releases and wonder if the freezing/segmentation fault bug was fixed in Pacman 2.6.2? This seemed to be a bit of a silent update, seeing as the past two versions of pacman were described on the news portion of the main page. Maybe throwing a changelog of sorts on the www.archlinux.org/pacman page would help those who are always curious about whats improving on our favourite distro. If curiosity killed the cat, then I'd be dead a long time ago, heh.
Kritoke

Good suggestion. Done!
VERSION DESCRIPTION
2.6.2 - Fixed a memory cleanup bug
- Aurelien's patch:
- bug #159 implemented (for -S and -R)
- fixed a bug with pacman -Sg (pacman was browsing only one
db to get groups)
- fixed a bug with list_merge()
- fixed some MLK (in dumppkg() and with "-Qi --orphans")
- now "pacman -Sg" only displays groups (without content)
whereas "pacman -Sg target1 target2" displays groups
target1 and target2 with content

Pacman-color(-testing) needs to depend on "pacman=${pkgver}"?

Hey,
So I've been thinking about this for some time now and I'd be interested in hearing other people's opinions about this. So my package pacman-color-testing currently depends on "pacman=${pkgver}" - meaning it requires the same version of pacman as the package itself - but the thing is: does it really need to?
I imagine keeping the pacman dependency in a single major version wouldn't produce any problems, eg. the current pacman-color(-testing) of 3.4.x would require this: depends=('pacman>=3.4' 'pacman<3.5'). This would also make updating easier.
At least the pacman change log here doesn't really show any "behavior compromising" changes between bug fix releases for pacman-color(-testing): http://projects.archlinux.org/pacman.git/tree/NEWS
But then what's other people's stance on this?
Last edited by algorythm (2011-03-08 15:53:21)

I assume you don't mean "sure, why wouldn't pacman-color* need to depend on "pacman=${pkgver}"" .
Last edited by algorythm (2011-03-09 14:05:12)

Pacman "Unknow" package

Hey, today i have updated my system (pacman -Syu ) , and i recieved like 5 updates about xorg components. After the update i noted that if i enter "pacman -Qm" i got an output with the packages that are not found on official repositories (normally this packages are from AUR), this is the output:
archey3 20110303-1
elementary-gtk-theme 2.1-5
elementary-icons 2.6-3
gtk-engine-equinox 1.30.2-2
gtk-engine-murrine-git 20110302-1
oblogout 0.2-7
splashy-full 0.3.13-7
splashy-themes 0.4-1
tintwizard 0.3.4-2
xorg-res-utils 1.0.3-3
I've installed all of this packages from AUR except for one, the last one "xorg-res-utils" that is not found on official repositories or AUR, is safely to remove this packages? or maybe is just a temporal server error? Because is not on offical or AUR repositories
Thanks for your time

SS4 wrote:
That package is [21:09:04] $ pacman Repository : extra Name : xorg-res-utils Version : 1.0.3-3 URL Licences : custom Groups : xorg Provides : None Depends On : libxaw Optional Deps : None Conflicts With : None Replaces : None Download Size : 59.16 K Installed Size : 200.00 K Packager Architecture : x86_64 Build Date MD5 Sum Description The whole point in extra, perhaps it's a bug
-Si xorg-res-utils

: http://xorg.freedesktop.org/

: Eric Belanger <[email protected]>

: Sat 25 Apr 2009 02:45:23 BST
: 65f53eea87fb4829323a1d29e86a1a9c
: X.Org X11 resource utilities
is that the package is not in extra.

Makepkg would be better if ...

Well, I may be puting my foot in my mouth as I am far from being an expert at packaging.
makepkg would be better if rather than directly call build() to compile and package, the process would be separated in
2 distincts functions: compile() and package(). compile() would be called as the normal user, and package() would be called in fakeroot environment.
An other possible change (which I am more hesitant) would be to automatically call CVS and or SVN (etc.) to get source code BEFORE unpacking the archives.
-Why have compile() and package() as distinct function?
-Because some programs need to combine different archives (libraries), and require to copy files around (.h and .a or .so files) in the src directory before compiling. Now, this make the copied files be own by root because of fakeroot. When you rebuild, you get errors because you have not the right to overwrite the copied files, moreover, to erase src, you have to become root. Running compile() as normal user, and package() in fakeroot environment more closely follows what a packager would do without makepkg.
-Ok, why do you want to have makepkg get source code by revision-control software by itself rather than write it yourself?
-Well, my problem is linked to the previous. You cannot svn checkout over a directory that contains the libraries, but you can svn checkout, then decompress libraries over in the same directory. Now, source files (in which I have tar libraries) are decompress before SVN checkout, which make it impossible to have libraries decompress over SVN checkout. But if makepkg was to get source itself, it could get source, and THEN, decompress sources (libraries) that would sit nicely in the source directories, making it less necessary to copy files around
-If we use compile() and package(), then you could simply copy the libraries manually in compile without problems, no?
-indeed, not ideal, but yes it should work fine.

The first point is indeed more interesting, and besides there is already a patch for it:
http://git.neptune-one.net/pacman?a=com … 3c6960269c
It didn't get much interest when it was first submitted, but it will be looked at again.
The second one looks less interesting and with a more limited usage.
But if you care, you should put it as a feature request on bugs.archlinux.org rather (pacman section).
It's of course even better if there is a patch included also

RawTherapee Locks Up After Opening "About"

RawTherapee: If I open "About" from "Preferences", there is no way to close "About". The Preferences panel becomes unresponsive. I cannot "Quit" the program. I need to get its PID and kill it.

joncr wrote:RawTherapee: If I open "About" from "Preferences", there is no way to close "About". The Preferences panel becomes unresponsive. I cannot "Quit" the program. I need to get its PID and kill it.
Cannot reproduce in wmii.
Before filing your bug report, make sure you can still reproduce the bug after updating with "pacman -Syu". Then in your bug report, make sure you provide information about what desktop environment or window manager you use.

Pacman: Possible bug with readonly filesystems

Background info
I have the following partitions on my desktop:
/boot
/home
/opt
/usr
/usr/local
/var
/var/local
Now, I normally have /, /home and /var mounted read-write and /boot, /opt, /usr, /usr/local and /var/local mounted read-only (if I crash the box, it reduces the potential for data corruption). I have a script that I manually call to mount the read-only partitions read-write, and return then to read-only again (called remountsys). If I want to install/remove/upgrade/etc packages, I run remountsys to set partitions read-write, then pacman, then remountsys to set partitions read-only.
The problem
If I forget (through my own stupidity) to remount the partitions read-write and run, say "pacman -Rs mplayer", obviously it cannot remove mplayer and churns out lots of "read only filesystem" errors, as it should. However, it still removes mplayer from /var/lib/pacman/local, so pacman no longer things mplayer is installed, but the files are still on the system. Another "pacman -Rs mplayer" obviously doesn't do anything because it doesn't think it's installed, and trying to reinstall mplayer doesn't work because of conflicting files. I tried a "pacman -Sf", but it does not always work (I can't remember the specifics, but I believe it failed when symlinks were involved). I basically have to manually remove any files left on the system, which can be a real pest.
My thoughts
Shouldn't pacman have error checking, basically to make sure that the package was uninstalled before it removes it from /var/lib/pacman/local? Does this count as a bug, and thus belong in the bug tracker? I realise this can all be solved by me not being quite so forgetful (or paranoid about my data), but I still consider this to be a flaw in pacman.
Disclaimer: mplayer is just an example that sprang to mind because I'm using it just now. This applies to all packages.

chrismortimore wrote:However, it still removes mplayer from /var/lib/pacman/local, so pacman no longer things mplayer is installed, but the files are still on the system.
I don't think this qualifies as a bug, simply because it's already a pacman feature:
usage: pacman {-R --remove} [options] <package>
options:
<snip>
-k, --dbonly only remove database entry, do not remove files
Offhand, I can't think of a situation where I would use it, but presmably it's there for a reason.
chrismortimore wrote:Shouldn't pacman have error checking, basically to make sure that the package was uninstalled before it removes it from /var/lib/pacman/local?
Sounds reasonable - unless, of course, the -k flag above is used. Post a feature request.

Bug after pacman -Syu

Since a few days, I have been having issues with my 4 year old Arch desktop, including lockups while X is running, hangs in shutdown process with my screen filling with lines I could only get glimpses of, and, lately, a simple "pacman -Syu" would cause my computer to become unresponsive.
Today I decided to try and create a new arch installation with the latest media available (2011.08.19 x86_64). With my fresh system, I can already see that at least one of my issues has not gone away. In a tty as root, pacman -Syu proceeded to upgrade my system, readily downloaded the packages and installed them, but, at the end of the process, here is what got printed on my screen (copied from /var/log/messages.log) :
Mar 9 21:32:32 localhost kernel: [ 590.574960] CPU 1
Mar 9 21:32:32 localhost kernel: [ 590.574993] Modules linked in: nvidia(P) dvb_pll cx22702 cx88_dvb videobuf_dvb cx88_vp3054_i2c dvb_core snd_hda_codec_analog rc_winfast cx8802 cx8800 cx88xx ir_lirc_codec lirc_dev tveeprom btcx_risc ir_mce_kbd_decoder videobuf_dma_sg i2c_algo_bit ir_sony_decoder videobuf_core ir_jvc_decoder v4l2_common videodev ir_rc6_decoder ir_rc5_decoder v4l2_compat_ioctl32 media snd_hda_intel snd_hda_codec snd_hwdep snd_pcm ir_nec_decoder rc_core firewire_ohci firewire_core psmouse intel_agp crc_itu_t snd_page_alloc i2c_i801 intel_gtt pcspkr serio_raw i2c_core snd_timer iTCO_wdt snd iTCO_vendor_support soundcore floppy joydev evdev asus_atk0110 processor button sky2 skge ext4 crc16 jbd2 mbcache sr_mod cdrom hid_logitech_dj usbhid hid pata_jmicron sd_mod ata_piix pata_acpi ahci libahci libata uhci_hcd scsi_mod ehci_hcd usbcore usb_common
Mar 9 21:32:32 localhost kernel: [ 590.576608]
Mar 9 21:32:32 localhost kernel: [ 590.576608] Pid: 825, comm: ldconfig Tainted: P O 3.2.9-1-ARCH #1 System manufacturer System Product Name/P5B-Deluxe
Mar 9 21:32:32 localhost kernel: [ 590.576608] RIP: 0010:[<ffffffff8117f3a3>] [<ffffffff8117f3a3>] __d_alloc+0x123/0x180
Mar 9 21:32:32 localhost kernel: [ 590.576608] RSP: 0018:ffff88017791dc48 EFLAGS: 00010202
Mar 9 21:32:32 localhost kernel: [ 590.576608] RAX: ffff880166d7f8d0 RBX: ffff880166d7f840 RCX: 0000000000000000
Mar 9 21:32:32 localhost kernel: [ 590.576608] RDX: 0000000000000002 RSI: ffff8801725f901e RDI: ffff880166d7f840
Mar 9 21:32:32 localhost kernel: [ 590.576608] RBP: ffff88017791dc68 R08: 2222222222222222 R09: 2222222222222222
Mar 9 21:32:32 localhost kernel: [ 590.576608] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88017791de58
Mar 9 21:32:32 localhost kernel: [ 590.576608] R13: ffff880166d7f878 R14: 0000880178beec00 R15: 0000000000000022
Mar 9 21:32:32 localhost kernel: [ 590.576608] FS: 00000000016fc880(0063) GS:ffff88017fc80000(0000) knlGS:0000000000000000
Mar 9 21:32:32 localhost kernel: [ 590.576608] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Mar 9 21:32:32 localhost kernel: [ 590.576608] CR2: 0000000000410000 CR3: 00000001771bc000 CR4: 00000000000006e0
Mar 9 21:32:32 localhost kernel: [ 590.576608] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Mar 9 21:32:32 localhost kernel: [ 590.576608] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Mar 9 21:32:32 localhost kernel: [ 590.576608] Process ldconfig (pid: 825, threadinfo ffff88017791c000, task ffff88017745e3c0)
Mar 9 21:32:32 localhost kernel: [ 590.576608] ffff880170197cc0 ffff8801701c6b70 ffff88017791de48 ffff88017791de48
Mar 9 21:32:32 localhost kernel: [ 590.576608] ffff88017791dc98 ffffffff8117f6f5 ffff88017791ddd8 0000000000000000
Mar 9 21:32:32 localhost kernel: [ 590.576608] ffff8801701c6b70 ffff88017791de48 ffff88017791dcd8 ffffffff811729dd
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff8117f6f5>] d_alloc+0x25/0x90
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff811729dd>] d_alloc_and_lookup+0x2d/0x90
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff8117faf5>] ? d_lookup+0x35/0x60
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff81173abf>] __lookup_hash.part.20+0xbf/0xe0
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff81173dac>] ? inode_permission+0x4c/0x110
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff81175be0>] lookup_hash+0x50/0x60
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff81176e9f>] do_last+0x46f/0x970
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff811774b2>] path_openat+0xd2/0x3c0
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff81177823>] ? user_path_at_empty+0x63/0xa0
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff811778c2>] do_filp_open+0x42/0xa0
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff81183fcc>] ? alloc_fd+0xec/0x140
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff81166a97>] do_sys_open+0xf7/0x1d0
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff81166b90>] sys_open+0x20/0x30
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff8145dd42>] system_call_fastpath+0x16/0x1b
Mar 9 21:32:32 localhost kernel: [ 590.576608] RSP <ffff88017791dc48>
Mar 9 21:32:32 localhost kernel: [ 590.583014] ---[ end trace c87e3f6f4ea02d0c ]---
This time my computer did not become unresponsive, but the output presented above does look alike what I could catch before I reinstalled my system (althoug maybe I have seen RIP instead of RSP in the line before the last one). I have no clue what is going. I am not enclined to think this is hardware related as I have a Chakra install and a Windows7 install that work fine.
I did look at the bug reports and searched the forums but could not see anything that seems remotely related to what I am facing. Apologies in advance if I missed something.
I would be happy to have anyone's insight about my issue.
Cheers

Thank you both for your answers (that I did not see until today).
To litemotiv : a 7-hour memcheck did not raise any error. I am not sure how to report such a bug, though.
To falconindy : here are the lines above the one I gave previously. I do not see anything useful but I would be pleased to be enlightened
Mar 9 21:22:48 localhost kernel: [ 5.122692] cx88[0]/2: cx2388x based DVB/ATSC card
Mar 9 21:22:48 localhost kernel: [ 5.122694] cx8802_alloc_frontends() allocating 1 frontend(s)
Mar 9 21:22:48 localhost kernel: [ 5.198183] DVB: registering new adapter (cx88[0])
Mar 9 21:22:48 localhost kernel: [ 5.198185] DVB: registering adapter 0 frontend 0 (Conexant CX22702 DVB-T)...
Mar 9 21:22:48 localhost kernel: [ 5.249916] nvidia 0000:04:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Mar 9 21:22:48 localhost kernel: [ 5.249929] vgaarb: device changed decodes: PCI:0000:04:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
Mar 9 21:22:48 localhost kernel: [ 5.250025] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 295.20 Mon Feb 6 21:07:30 PST 2012
Mar 9 21:22:48 localhost kernel: [ 5.760798] EXT4-fs (sdc5): re-mounted. Opts: (null)
Mar 9 21:22:48 localhost kernel: [ 5.762311] EXT4-fs (sda3): mounting ext2 file system using the ext4 subsystem
Mar 9 21:22:48 localhost kernel: [ 5.769319] EXT4-fs (sda3): mounted filesystem without journal. Opts: (null)
Mar 9 21:22:48 localhost kernel: [ 5.872575] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
Mar 9 21:22:48 localhost kernel: [ 5.890238] Adding 1052220k swap on /dev/sdc1. Priority:-1 extents:1 across:1052220k
Mar 9 21:22:48 localhost kernel: [ 6.620511] skge 0000:05:04.0: eth0: enabling interface
Mar 9 21:22:48 localhost dhcpcd[429]: eth0: sending IPv6 Router Solicitation
Mar 9 21:22:48 localhost dhcpcd[429]: eth0: broadcasting for a lease
Mar 9 21:22:52 localhost dhcpcd[429]: eth0: sending IPv6 Router Solicitation
Mar 9 21:22:56 localhost dhcpcd[429]: eth0: sending IPv6 Router Solicitation
Mar 9 21:23:00 localhost dhcpcd[429]: eth0: sending IPv6 Router Solicitation
Mar 9 21:23:00 localhost dhcpcd[429]: eth0: no IPv6 Routers available
Mar 9 21:24:12 localhost dhcpcd[527]: version 5.5.4 starting
Mar 9 21:24:12 localhost kernel: [ 90.916689] sky2 0000:02:00.0: eth1: enabling interface
Mar 9 21:24:12 localhost kernel: [ 90.917040] ADDRCONF(NETDEV_UP): eth1: link is not ready
Mar 9 21:24:12 localhost dhcpcd[527]: eth1: waiting for carrier
Mar 9 21:24:14 localhost dhcpcd[527]: eth1: carrier acquired
Mar 9 21:24:14 localhost kernel: [ 92.783714] sky2 0000:02:00.0: eth1: Link is up at 100 Mbps, full duplex, flow control rx
Mar 9 21:24:14 localhost kernel: [ 92.784028] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
Mar 9 21:24:14 localhost dhcpcd[527]: eth1: sending IPv6 Router Solicitation
Mar 9 21:24:14 localhost dhcpcd[527]: eth1: rebinding lease of 192.168.0.2
Mar 9 21:24:14 localhost dhcpcd[527]: eth1: acknowledged 192.168.0.2 from 192.168.0.254
Mar 9 21:24:14 localhost dhcpcd[527]: eth1: checking for 192.168.0.2
Mar 9 21:24:18 localhost dhcpcd[527]: eth1: sending IPv6 Router Solicitation
Mar 9 21:24:19 localhost dhcpcd[527]: eth1: leased 192.168.0.2 for 864000 seconds
Mar 9 21:24:19 localhost dhcpcd[527]: forked to background, child pid 559
Mar 9 21:24:22 localhost dhcpcd[559]: eth1: sending IPv6 Router Solicitation
Mar 9 21:24:26 localhost dhcpcd[559]: eth1: sending IPv6 Router Solicitation
Mar 9 21:24:26 localhost dhcpcd[559]: eth1: no IPv6 Routers available
Mar 9 21:30:16 localhost dbus[494]: [system] Reloaded configuration
Mar 9 21:30:16 localhost dbus[494]: [system] Reloaded configuration
Mar 9 21:32:32 localhost kernel: [ 590.574960] CPU 1
Mar 9 21:32:32 localhost kernel: [ 590.574993] Modules linked in: nvidia(P) dvb_pll cx22702 cx88_dvb videobuf_dvb cx88_vp3054_i2c dvb_core snd_hda_codec_analog rc_winfast cx8802 cx8800 cx88xx ir_lirc_codec lirc_dev tveeprom btcx_risc ir_mce_kbd_decoder videobuf_dma_sg i2c_algo_bit ir_sony_decoder videobuf_core ir_jvc_decoder v4l2_common videodev ir_rc6_decoder ir_rc5_decoder v4l2_compat_ioctl32 media snd_hda_intel snd_hda_codec snd_hwdep snd_pcm ir_nec_decoder rc_core firewire_ohci firewire_core psmouse intel_agp crc_itu_t snd_page_alloc i2c_i801 intel_gtt pcspkr serio_raw i2c_core snd_timer iTCO_wdt snd iTCO_vendor_support soundcore floppy joydev evdev asus_atk0110 processor button sky2 skge ext4 crc16 jbd2 mbcache sr_mod cdrom hid_logitech_dj usbhid hid pata_jmicron sd_mod ata_piix pata_acpi ahci libahci libata uhci_hcd scsi_mod ehci_hcd usbcore usb_common
Mar 9 21:32:32 localhost kernel: [ 590.576608]
Mar 9 21:32:32 localhost kernel: [ 590.576608] Pid: 825, comm: ldconfig Tainted: P O 3.2.9-1-ARCH #1 System manufacturer System Product Name/P5B-Deluxe
Mar 9 21:32:32 localhost kernel: [ 590.576608] RIP: 0010:[<ffffffff8117f3a3>] [<ffffffff8117f3a3>] __d_alloc+0x123/0x180
Mar 9 21:32:32 localhost kernel: [ 590.576608] RSP: 0018:ffff88017791dc48 EFLAGS: 00010202
Mar 9 21:32:32 localhost kernel: [ 590.576608] RAX: ffff880166d7f8d0 RBX: ffff880166d7f840 RCX: 0000000000000000
Mar 9 21:32:32 localhost kernel: [ 590.576608] RDX: 0000000000000002 RSI: ffff8801725f901e RDI: ffff880166d7f840
Mar 9 21:32:32 localhost kernel: [ 590.576608] RBP: ffff88017791dc68 R08: 2222222222222222 R09: 2222222222222222
Mar 9 21:32:32 localhost kernel: [ 590.576608] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88017791de58
Mar 9 21:32:32 localhost kernel: [ 590.576608] R13: ffff880166d7f878 R14: 0000880178beec00 R15: 0000000000000022
Mar 9 21:32:32 localhost kernel: [ 590.576608] FS: 00000000016fc880(0063) GS:ffff88017fc80000(0000) knlGS:0000000000000000
Mar 9 21:32:32 localhost kernel: [ 590.576608] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Mar 9 21:32:32 localhost kernel: [ 590.576608] CR2: 0000000000410000 CR3: 00000001771bc000 CR4: 00000000000006e0
Mar 9 21:32:32 localhost kernel: [ 590.576608] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Mar 9 21:32:32 localhost kernel: [ 590.576608] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Mar 9 21:32:32 localhost kernel: [ 590.576608] Process ldconfig (pid: 825, threadinfo ffff88017791c000, task ffff88017745e3c0)
Mar 9 21:32:32 localhost kernel: [ 590.576608] ffff880170197cc0 ffff8801701c6b70 ffff88017791de48 ffff88017791de48
Mar 9 21:32:32 localhost kernel: [ 590.576608] ffff88017791dc98 ffffffff8117f6f5 ffff88017791ddd8 0000000000000000
Mar 9 21:32:32 localhost kernel: [ 590.576608] ffff8801701c6b70 ffff88017791de48 ffff88017791dcd8 ffffffff811729dd
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff8117f6f5>] d_alloc+0x25/0x90
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff811729dd>] d_alloc_and_lookup+0x2d/0x90
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff8117faf5>] ? d_lookup+0x35/0x60
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff81173abf>] __lookup_hash.part.20+0xbf/0xe0
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff81173dac>] ? inode_permission+0x4c/0x110
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff81175be0>] lookup_hash+0x50/0x60
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff81176e9f>] do_last+0x46f/0x970
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff811774b2>] path_openat+0xd2/0x3c0
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff81177823>] ? user_path_at_empty+0x63/0xa0
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff811778c2>] do_filp_open+0x42/0xa0
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff81183fcc>] ? alloc_fd+0xec/0x140
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff81166a97>] do_sys_open+0xf7/0x1d0
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff81166b90>] sys_open+0x20/0x30
Mar 9 21:32:32 localhost kernel: [ 590.576608] [<ffffffff8145dd42>] system_call_fastpath+0x16/0x1b
Mar 9 21:32:32 localhost kernel: [ 590.576608] RSP <ffff88017791dc48>
Mar 9 21:32:32 localhost kernel: [ 590.583014] ---[ end trace c87e3f6f4ea02d0c ]---
Mar 9 22:00:08 localhost -- MARK --
My / is on /dev/sdc5, ext3 filesystem. I formated this partition when I reinstalled my system on March 8th.
Should I try and run a fsck.ext3 on this partition to see if anything is wrong ? What about the "Mar 9 21:22:48 localhost kernel: [ 5.760798] EXT4-fs (sdc5): re-mounted. Opts: (null)" line ? Is it normal t is mentionned EXT4-fs while the filesystem on this partition is ext3 ?
Thanks
Last edited by Mc_Lenet (2012-03-21 19:39:28)

Pacman TotalDownload bug?

Hi,
I have the TotalDownload option set in pacman.conf.
If i install something with more than 1 package, then the first package always seems to show 100% rather than the percentage of the total files.
e.g.
:: Retrieving packages from core...
hdparm-8.9-1-i686 48.0K 75.4K/s 00:00:01 [#####################] 100%
module-init-tools-3... 341.9K 70.9K/s 00:00:05 [#####################] 1%
kernel26-2.6.26.2-1... 25.3M 114.9K/s 00:03:46 [#####################] 82%
Is this a bug?
Kane

I can replicate intermittently. Can you please file a bug report?
Edit: Just so I remember my replication...
> pacman -S bc bzflag
bc-1.06-5-i686 95.0K 38.7K/s 00:00:02 [#####################] 100%
bzflag-2.0.12-1-i686 365.0K 57.7K/s 00:03:11 [---------------------] 3%

Pacman bug or?

Heya..
I download muffin-git from aur, and then edit the recipe to contain , replaces, provides and conflicts=("${_pkgname}") which is muffin.
Even so, when doing makepkg -si, say, pacman doesn't resolve correctly, and exits with files already exists. If I remove muffin, it works obviously.
It's a bit odd, but I don't know if my system is for some reason borked in the db, or if someone can replicate (this particular package).
I cannot replicate the issue with other packages, only this one.
EDIT: and before the foaming mouth appear.. yes I am perfectly sure it is just me not understanding the resolving tree path here.. but just want someone with a helpful feedback on it. ,x
Last edited by solar (2014-01-15 05:23:15)

Did you read the pacman manual ?
man pacman wrote:
ewaller$@$odin ~ 1007 %man pacman | tail -30 | head -4
BUGS
Bugs? You must be kidding, there are no bugs in this software. But if we happen to be wrong,
send us an email with as much detail as possible to [email protected]
ewaller$@$odin ~ 1008 %
Perhaps if you were to share your PKGBUILD...
Edit: Moving to AUR issues, Discussion and PKGBUILD requests
Last edited by ewaller (2014-01-15 05:39:21)

"pacman -Qu" bug?

hi all,
bugs site is down, so i'm writing this here.
when running
# pacman -Qu
lyx 1.6.3-1
sqlite3 3.6.16-1
subversion 1.6.4-1
tzdata 2009k-1
but
# pacman -Su
:: Starting full system upgrade...
resolving dependencies...
looking for inter-conflicts...
Targets (4): lyx-1.6.4-1 [10.35 MB] sqlite3-3.6.17-1 [0.40 MB] subversion-1.6.5-1 [6.86 MB] tzdata-2009l-1 [0.56 MB]
Total Download Size: 18.17 MB
Total Installed Size: 73.98 MB
note that the first versions are the old ones.
bug or feature?
vlad

nah, has nothing to do with mirrors. upgrading works. i noticed this earlier.
btw, i liked the former behaviour more. "pacman -Qu" showed the same as "pacman -Su" but without the installation prompt.
so you see what you'd get.

Pacman or package bug with codecs-20061022-1

I have noticed that every time I do a pacman -Syu, pacman insists on upgrading the package codecs-20061022-1 from extra/multimedia. Now, I have no idea whether this is a local issue or a bug. Just wondering if anyone has this issue. My search on the forums and in the bug reports gave nothing.
Cheers.

Outputs are:
/var/lib/pacman/local/codecs-20060611-1/desc:%VERSION%
/var/lib/pacman/local/codecs-20060611-1/desc-20060611-1
/var/lib/pacman/local/codecs-20061022-1/desc:%VERSION%
/var/lib/pacman/local/codecs-20061022-1/desc-20061022-1
and:
%VERSION%
20061022-1
Cheers.

Pacman proxy bug?

Hi,
Well, my ISP is kind of funny you know. FTP traffic is quite slow about 40kB/s, unless you put it through a HTTP proxy. Apart from that, my ISP has a transparent proxy on port 80 (you can't walk around it unfortunately). Additionally it filters everything on the common proxy ports like 8080. So, it doesn't metter what proxy you specify, everything goes throu theirs.
Since most of the downloads in pacman are done from ftp, I decided to proxy the traffic. I've put
ProxyServer = w3cache.fordon.intelink.pl:8080
Note: this is the real address of my ISPs transparent proxy.
Updating pacage listings works just fine:
[root@wintermute:~/] pacman -Syu
:: Synchronizing package databases...
testing [----------------------------------------------------------------] 100% 5K 355.5K/s 00:00:00
current [----------------------------------------------------------------] 100% 47K 158.8K/s 00:00:00
extra [----------------------------------------------------------------] 100% 222K 48.5K/s 00:00:04
unstable [----------------------------------------------------------------] 100% 3K 233.1K/s 00:00:00
But when I try to download packages, only the first one gets downloaded, the rest return errors.
pacman -Sw xfce4
:: group xfce4:
gtk-xfce-engine libxfce4mcs libxfce4util libxfcegui4 xfcalendar xfce-mcs-manager xfce-mcs-plugins xfce-utils
xfce4-appfinder xfce4-icon-theme xfce4-iconbox xfce4-mixer xfce4-panel xfce4-session xfce4-systray xfce4-toys
xfce4-trigger-launcher xfdesktop xffm xfprint xfwm4 xfwm4-themes
Install whole content? [Y/n] y
Targets: gtk-xfce-engine-2.2.8-1 libxfce4util-4.2.3.2-1 libxfce4mcs-4.2.3-1 libxfcegui4-4.2.3-1 xfcalendar-4.2.3-1
xfce-mcs-manager-4.2.3-1 xfce-mcs-plugins-4.2.3-1 xfce-utils-4.2.3-1 xfce4-appfinder-4.2.3-1 xfce4-icon-theme-4.2.3-1
xfce4-iconbox-4.2.3-1 xfce4-panel-4.2.3-1 xfce4-mixer-4.2.3-1 xfce4-session-4.2.3-1 xfce4-systray-4.2.3-1
xfce4-toys-4.2.3-1 xfce4-trigger-launcher-4.2.3-1 xfdesktop-4.2.3-1 xffm-4.2.3-1 xfprint-4.2.3-1 xfwm4-4.2.3.2-1
xfwm4-themes-4.2.3-1
Total Package Size: 14.6 MB
Proceed with download? [Y/n] y
:: Retrieving packages from extra...
gtk-xfce-engine-2.2.8-1 [----------------------------------------------------------------] 100% 25K 10.3K/s 00:00:02
failed downloading ftp://ftp.archlinux.org/extra/os/i686/libxfce4util-4.2.3.2-1.pkg.tar.gz from ftp.archlinux.org: (null)
failed downloading ftp://ftp.archlinux.org/extra/os/i686/libxfce4mcs-4.2.3-1.pkg.tar.gz from ftp.archlinux.org: (null)
failed downloading ftp://ftp.archlinux.org/extra/os/i686/libxfcegui4-4.2.3-1.pkg.tar.gz from ftp.archlinux.org: (null)
failed downloading ftp://ftp.archlinux.org/extra/os/i686/xfcalendar-4.2.3-1.pkg.tar.gz from ftp.archlinux.org: (null)
failed downloading ftp://ftp.archlinux.org/extra/os/i686/xfce-mcs-manager-4.2.3-1.pkg.tar.gz from ftp.archlinux.org: (null)
failed downloading ftp://ftp.archlinux.org/extra/os/i686/xfce-mcs-plugins-4.2.3-1.pkg.tar.gz from ftp.archlinux.org: (null)
failed downloading ftp://ftp.archlinux.org/extra/os/i686/xfce-utils-4.2.3-1.pkg.tar.gz from ftp.archlinux.org: (null)
failed downloading ftp://ftp.archlinux.org/extra/os/i686/xfce4-appfinder-4.2.3-1.pkg.tar.gz from ftp.archlinux.org: (null)
failed downloading ftp://ftp.archlinux.org/extra/os/i686/xfce4-icon-theme-4.2.3-1.pkg.tar.gz from ftp.archlinux.org: (null)
failed downloading ftp://ftp.archlinux.org/extra/os/i686/xfce4-iconbox-4.2.3-1.pkg.tar.gz from ftp.archlinux.org: (null)
failed downloading ftp://ftp.archlinux.org/extra/os/i686/xfce4-panel-4.2.3-1.pkg.tar.gz from ftp.archlinux.org: (null)
failed downloading ftp://ftp.archlinux.org/extra/os/i686/xfce4-mixer-4.2.3-1.pkg.tar.gz from ftp.archlinux.org: (null)
failed downloading ftp://ftp.archlinux.org/extra/os/i686/xfce4-session-4.2.3-1.pkg.tar.gz from ftp.archlinux.org: (null)
failed downloading ftp://ftp.archlinux.org/extra/os/i686/xfce4-systray-4.2.3-1.pkg.tar.gz from ftp.archlinux.org: (null)
failed downloading ftp://ftp.archlinux.org/extra/os/i686/xfce4-toys-4.2.3-1.pkg.tar.gz from ftp.archlinux.org: (null)
failed downloading ftp://ftp.archlinux.org/extra/os/i686/xfce4-trigger-launcher-4.2.3-1.pkg.tar.gz from ftp.archlinux.org: (null)
failed downloading ftp://ftp.archlinux.org/extra/os/i686/xfdesktop-4.2.3-1.pkg.tar.gz from ftp.archlinux.org: (null)
failed downloading ftp://ftp.archlinux.org/extra/os/i686/xffm-4.2.3-1.pkg.tar.gz from ftp.archlinux.org: (null)
failed downloading ftp://ftp.archlinux.org/extra/os/i686/xfprint-4.2.3-1.pkg.tar.gz from ftp.archlinux.org: (null)
failed downloading ftp://ftp.archlinux.org/extra/os/i686/xfwm4-4.2.3.2-1.pkg.tar.gz from ftp.archlinux.org: (null)
failed downloading ftp://ftp.archlinux.org/extra/os/i686/xfwm4-themes-4.2.3-1.pkg.tar.gz from ftp.archlinux.org: (null)
This happens regardles of what I put in pacman.conf. I tried with the public w3cache proxy of one of our Universities:
ProxyServer = w3cache.icm.edu.pl:8080
Same results. I didn't expect anything to change, since my ISP's transparent proxy would pick this connection instead (my queries never really get to w3cache.icm.edu.pl since they are answered by w3cache.fordon.intelink.pl instead).
I can download using pacman's built-in downloader without problems when no ProxyServer is set. But then, the transfers are really slow
Finally, I got it working using
XferCommand = /usr/bin/wget --passive-ftp --proxy=on -c -O %o %u
With this, it works great. No problems with the same proxies or anything. But the output sucks and is really hard to read.
However, I can live with wget, I'd rather pacman not to have bugs, so I thought I'd let you know.

I can replicate intermittently. Can you please file a bug report?
Edit: Just so I remember my replication...
> pacman -S bc bzflag
bc-1.06-5-i686 95.0K 38.7K/s 00:00:02 [#####################] 100%
bzflag-2.0.12-1-i686 365.0K 57.7K/s 00:03:11 [---------------------] 3%

[solved] Why is it possible to report bugs for pacman 3.5.4?

I thought we mustn't report bugs for outdated packages. What is the use case here?
Last edited by karol (2012-01-21 21:19:51)

I thought the deal was "you can use whatever version you want, as long as it's the latest one" :-)

Bug in progresbar in pacman ??

Similar Messages

Maybe you are looking for