Re: [arch-general] pacman seems to leak ftp connections
On Wed, 18 Aug 2010 14:21:01 +1000
Allan McRae al...@archlinux.org wrote:
On 18/08/10 12:07, Alexander Duscheleit wrote:
Hi,
since I upgraded to pacman 3.4.0 I notice a strange behavior in the
way pacman integrates with my local mirror server. First, pacman
opens a new ftp connection for every download, which spams the logs
a lot. Second, pacman doesn't seem to close those connections
either at all, or at least not in a timely fashion. This results in
pacman not being able to download more than a hand full of packages
before my ftp won't let it connect anymore. The server-log says:
Aug 18 00:42:38 titan proftpd[4666]:
titan.huntemann.uni-oldenburg.de - MaxInstances (30) reached, new
connection denied
over and over while pacman switches to the next mirror for every
download.
The pacman frontend clyde exhibits the same behavior, so I suspect
the culprit is somewhere in libalpm. Pacman prior to 3.4.0 did not
show this behavior and all downloads worked fine.
This bug has been reported: http://bugs.archlinux.org/task/20371
Great, seems I should remember to actually set the right project in
FS :(
However, no-one appears to have investigated whether this was
libarchive's fault or libalpm's.
How would I best go about researching this? I have all the components
right here, and it's easy enough to trigger, but I have no experience
whatsoever in debugging libraries or C code in general.
I could try and set up a chroot to bisect pacman /
lib{fetch,archive,alpm} but I have no clue how good or bad random
pacman versions interact with the rest of the system.
Re: [arch-general] Empathy on Arch?
On 18/08/10 00:00, Ng Oon-Ee wrote: On Tue, 2010-08-17 at 21:31 +0100, Magnus Therning wrote: On 17/08/10 16:33, Rafael Beraldo wrote: 2010/8/17 Magnus Therning mag...@therning.org Yes, got gabble installed. Using the settings that work in pidgin, still it's stuck on something; not connecting, not throbbing the top-right indicator-thingie... nothing. Out of curiosity, are you on 32bit or 64bit? I'm sorry for the top posting in the last e-mail. Anyway, I'm on a 64bit system. No worries :-) So am I, on all my systems. Now I have connection to GTalk from home, but no luck at work, which is the place I could really use it since we have a combination of internal IM/chat servers, Jabber, Office Communicator (SIP), IRC. :-( /M Any particular reason not to use Pidgin? It handles all those. In fact libpurple is so good that Empathy uses it for a few protocols it can't handle... None really. It's what I use at the moment. However, empathy (especially telepathy) seems to be the future(tm) and it handles both audio and video for protocols that can do that. That latter bit makes me want to switch on my personal systems, and if possible I like to keep my work systems as similar to my home systems as possible. /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe signature.asc Description: OpenPGP digital signature
Re: [arch-general] pacman seems to leak ftp connections
How would I best go about researching this? I have all the components
right here, and it's easy enough to trigger, but I have no experience
whatsoever in debugging libraries or C code in general.
I could try and set up a chroot to bisect pacman /
lib{fetch,archive,alpm} but I have no clue how good or bad random
pacman versions interact with the rest of the system.
What I did to replicate this was create a chroot ie
sudo mkdir -p archtest/var/lib/pacman
and then test with a large group something like this
sudo pacman -Sy gnome --cachedir
$(pwd)/archtest/var/cache/pacman/pkg/ -r ./archtest/
if you need to download again you can just purge chroot cachedir.
after that I'm not sure how best to debug libfetch possibly using
netstat, lsof and strace?
Re: [arch-general] [arch-dev-public] Large packages in repositories
On 17.08.2010 16:28, Thomas Bächler wrote: Am 17.08.2010 16:12, schrieb Dan McGee: tl;dr: I think we need some standards with these huge packages, and people need to be a lot more cognizant as to how big they are. We have lost more than one mirror due to complaints over needed space and stuff like this doesn't help. If a mirror cannot cope with a few GB, then it should be dropped anyway. Our repos will get bigger, one way or the other. I share this opinion. The Arch repos are hardly large and even if we added 50 GB to them they would still wouldn't be that large. I know comparisons with other distributions are probably not a good idea on this list but it does help to get a general understanding of where we stand and what large really means. Debian - 428GB (http://www.debian.org/mirror/size) Fedora - 653GB (http://download.fedora.redhat.com/pub/DIRECTORY_SIZES.txt) Ubuntu - 421GB (https://wiki.ubuntu.com/Mirrors) openSUSE - 500GB+ (http://en.opensuse.org/openSUSE:Mirror_infrastructure) Thankfully, we don't keep around old releases of packages or isos. Our mirrors will never have to cope with the amount of data that other distributions make them cope with. I think since they are already mirroring 2TB+ worth of data from other distros, they can easily squeeze in 50GB of Arch, or more. I'd really like to resolve this problem in the course of this discussion since it has been brought up every time big packages are pending (mostly games). Personally, I think we don't need a policy or anything on this. Something very odd would have to happen for our repos to grow too much for our mirrors to handle. This is Arch, let's keep it simple and unbureaucratic. I'm not saying let's throw all that big shit into there but if there are potential packages that would improve the user experience, their size should not be the determining factor to their inclusion. -- Sven-Hendrik
Re: [arch-general] [arch-dev-public] Dovecot 2.0.0 in testing
On Wed, 2010-08-18 at 07:12 +0200, Andreas Radke wrote: Am Wed, 18 Aug 2010 07:16:16 +0800 schrieb Ng Oon-Ee ngoo...@gmail.com: On Tue, 2010-08-17 at 19:44 +0200, Andreas Radke wrote: Dovecot 2.0.0 has been released and it's in our testing repo (it has been build against core/extra only). The configuration files are completely split up now! Everybody please read the post.install msg carefully! Test the new pkg and give suggestions if anything needs to be improved. I should move soon to extra. I got it running locally here. PS: I had to disable IPv6 listen option to make it start properly. -Andy Should we put configuration in /etc/dovecot/local.conf then? Because of the IPv6 setting? I don't think so. That setting depends on your network configuration. It's up to the user to decide how you want to configure your network. The solution is quiet easy. It could be put on our wiki page anyways if you want. -Andy Sorry for the unclear question, I'm asking from the user's perspective whether it would make sense to keep all my configuration in local.conf. Previously I just edited dovecot.conf directly (when it didn't belong to the dovecot package), but now that would result in YAPF (yet another pacnew file). As it is, for my local dovecot I need to disable ssl, which would also give a pacnew for /etc/dovecot/conf.d/10-ssl.conf Can I also request that the !include_try /etc/dovecot/local.conf be uncommented in the package? Better to put into the bug tracker?
Re: [arch-general] [PATCH 28/48] Use bash-style conditionals when setting up the hardware clock.
Am 2010-06-30 23:47, schrieb Victor Lowther:
Trying to stick with POSIX syntax only just slows things down.
---
rc.sysinit | 27 +++
1 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit
index 29adeca..f3e60b7 100755
--- a/rc.sysinit
+++ b/rc.sysinit
@@ -44,27 +44,22 @@ fi
HWCLOCK_PARAMS=--hctosys
case $HARDWARECLOCK in
-UTC) $HWCLOCK_PARAMS --utc;;
-localtime) HWCLOCK_PARAMS=$HWCLOCK_PARAMS --localtime;;
+UTC) HWCLOCK_PARAMS+= --utc;;
+localtime) HWCLOCK_PARAMS+= --localtime;;
*) HWCLOCK_PARAMS=;;
esac
-if [ -n $HWCLOCK_PARAMS ]; then
+if [[ $HWCLOCK_PARAMS ]]; then
# enable rtc access
- /sbin/modprobe -q rtc-cmos
- # some custom kernels use rtc/genrtc, try to load those too
- /sbin/modprobe -q rtc
- /sbin/modprobe -q genrtc
+ /sbin/modprobe -q -a rtc-cmos rtc genrtc
# If devtmpfs is used, the required RTC device already exists now
# Otherwise, create whatever device is available
- if [ ! -c /dev/rtc -a ! -c /dev/rtc0 ]; then
- if [ -f /sys/class/rtc/rtc0/dev ]; then
- IFS=: read -r major minor /sys/class/rtc/rtc0/dev
- /bin/mknod /dev/rtc0 c $major $minor
- elif [ -f /sys/class/misc/rtc/dev ]; then
- IFS=: read -r major minor /sys/class/misc/rtc/dev
- /bin/mknod /dev/rtc c $major $minor
- fi
+ if ! [[ -c /dev/rtc || -c /dev/rtc0 ]]; then
+for dev in /sys/class/rtc/rtc0/dev /sys/class/misc/rtc/dev; do
+[[ -e $dev ]] || continue
+ IFS=: read -r major minor $dev
+ /bin/mknod /dev/rtc c $major $minor
+ done
fi
Actually this doesn't do the same. What about the following?
if ! [[ -c /dev/rtc || -c /dev/rtc0 ]]; then
for dev in /sys/class/rtc/rtc0 /sys/class/misc/rtc; do
[[ -e $dev/dev ]] || continue
IFS=: read -r major minor $dev/dev
/bin/mknod /dev/${dev##*/} c $major $minor
done
fi
Re: [arch-general] pacman seems to leak ftp connections
On Wed, 18 Aug 2010 00:06:44 -0700
mike rosset schizoi...@gmail.com wrote:
How would I best go about researching this? I have all the
components right here, and it's easy enough to trigger, but I have
no experience whatsoever in debugging libraries or C code in
general.
I could try and set up a chroot to bisect pacman /
lib{fetch,archive,alpm} but I have no clue how good or bad random
pacman versions interact with the rest of the system.
What I did to replicate this was create a chroot ie
sudo mkdir -p archtest/var/lib/pacman
and then test with a large group something like this
sudo pacman -Sy gnome --cachedir
$(pwd)/archtest/var/cache/pacman/pkg/ -r ./archtest/
if you need to download again you can just purge chroot cachedir.
after that I'm not sure how best to debug libfetch possibly using
netstat, lsof and strace?
After playing around i a throwaway-chroot, the problem seems to be
libfetch =2.30. I just modified the PKGBUILD to different versions
(without replacing or rebuilding pacman at all).
Libfetch 2.26 fetches files without a problem, 2.30+ fails after
downloading 5 files while MaxInstances in proftpd is set to 8. If I set
MaxInstances to 3, downloading fails outright (also only for 2.30+), so
something there seems to consume 3 connections before actually
downloading something at all.
I'd try to break it down further, but NetBSDs CVS server isn't talking
to me at the moment.
Re: [arch-general] pacman seems to leak ftp connections
After playing around i a throwaway-chroot, the problem seems to be libfetch =2.30. I just modified the PKGBUILD to different versions (without replacing or rebuilding pacman at all). Libfetch 2.26 fetches files without a problem, 2.30+ fails after downloading 5 files while MaxInstances in proftpd is set to 8. If I set MaxInstances to 3, downloading fails outright (also only for 2.30+), so something there seems to consume 3 connections before actually downloading something at all. I'd try to break it down further, but NetBSDs CVS server isn't talking to me at the moment. Ok maybe upate the bug with these results, so they have more information.
Re: [arch-general] [arch-dev-public] Large packages in repositories
On Wed, 18 Aug 2010 09:19:09 +0200, Sven-Hendrik Haase s...@lutzhaase.com wrote: On 17.08.2010 16:28, Thomas Bächler wrote: Am 17.08.2010 16:12, schrieb Dan McGee: tl;dr: I think we need some standards with these huge packages, and people need to be a lot more cognizant as to how big they are. We have lost more than one mirror due to complaints over needed space and stuff like this doesn't help. If a mirror cannot cope with a few GB, then it should be dropped anyway. Our repos will get bigger, one way or the other. I share this opinion. The Arch repos are hardly large and even if we added 50 GB to them they would still wouldn't be that large. I know comparisons with other distributions are probably not a good idea on this list but it does help to get a general understanding of where we stand and what large really means. Debian - 428GB (http://www.debian.org/mirror/size) Fedora - 653GB (http://download.fedora.redhat.com/pub/DIRECTORY_SIZES.txt) Ubuntu - 421GB (https://wiki.ubuntu.com/Mirrors) openSUSE - 500GB+ (http://en.opensuse.org/openSUSE:Mirror_infrastructure) Thankfully, we don't keep around old releases of packages or isos. Our mirrors will never have to cope with the amount of data that other distributions make them cope with. I think since they are already mirroring 2TB+ worth of data from other distros, they can easily squeeze in 50GB of Arch, or more. I'd really like to resolve this problem in the course of this discussion since it has been brought up every time big packages are pending (mostly games). Personally, I think we don't need a policy or anything on this. Something very odd would have to happen for our repos to grow too much for our mirrors to handle. This is Arch, let's keep it simple and unbureaucratic. I'm not saying let's throw all that big shit into there but if there are potential packages that would improve the user experience, their size should not be the determining factor to their inclusion. -- Sven-Hendrik You need to keep in mind that's its not just the disk space that might cause problems here but traffic and especially bandwidth are. E.g. the our mainserver has about 10mbit/d bandwidth including mirroring, website etc.. -- Pierre Schmitz, https://users.archlinux.de/~pierre
Re: [arch-general] pacman seems to leak ftp connections
Excerpts from Alexander Duscheleit's message of 2010-08-18 04:07:23 +0200: Hi, since I upgraded to pacman 3.4.0 I notice a strange behavior in the way pacman integrates with my local mirror server. First, pacman opens a new ftp connection for every download, which spams the logs a lot. Second, pacman doesn't seem to close those connections either at all, or at least not in a timely fashion. This results in pacman not being able to download more than a hand full of packages before my ftp won't let it connect anymore. The server-log says: Aug 18 00:42:38 titan proftpd[4666]: titan.huntemann.uni-oldenburg.de - MaxInstances (30) reached, new connection denied over and over while pacman switches to the next mirror for every download. The pacman frontend clyde exhibits the same behavior, so I suspect the culprit is somewhere in libalpm. Pacman prior to 3.4.0 did not show this behavior and all downloads worked fine. Greetings, Alex Hmm, this could be the reason for the behavior I experience recently. Every time I update a couple of packages it fails to download all of them. If I try again and again it works. I thought it was due to improperly synced mirrors, but it happens far too frequently. Just now it downloaded 4 packages. In the subsequent run four more, and so on. -- Philipp -- Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen. Bertolt Brecht, Der gute Mensch von Sezuan
Re: [arch-general] pacman seems to leak ftp connections
On Wed, 18 Aug 2010 00:54:26 -0700 Mike Rosset schizoi...@gmail.com wrote: After playing around i a throwaway-chroot, the problem seems to be libfetch =2.30. I just modified the PKGBUILD to different versions (without replacing or rebuilding pacman at all). Libfetch 2.26 fetches files without a problem, 2.30+ fails after downloading 5 files while MaxInstances in proftpd is set to 8. If I set MaxInstances to 3, downloading fails outright (also only for 2.30+), so something there seems to consume 3 connections before actually downloading something at all. I'd try to break it down further, but NetBSDs CVS server isn't talking to me at the moment. Ok maybe upate the bug with these results, so they have more information. I've updated the bug-report with the above text as well as my results of a bisection of libfetch. Looking at the patch, the change in libfetch seems sensible and I suspect that something higher up the chain is calling it in a wrong way. As far as I can tell, it is possible, that pacman never called libfetch in The Right Way (TM), but this only got exposed, after libfetch stopped closing connections unconditionally. Let's hope that some of my stumbling around is actually helpfull :)
Re: [arch-general] [arch-dev-public] Large packages in repositories
On 18 August 2010 16:37, Pierre Schmitz pie...@archlinux.de wrote: On Wed, 18 Aug 2010 09:19:09 +0200, Sven-Hendrik Haase s...@lutzhaase.com wrote: On 17.08.2010 16:28, Thomas Bächler wrote: Am 17.08.2010 16:12, schrieb Dan McGee: tl;dr: I think we need some standards with these huge packages, and people need to be a lot more cognizant as to how big they are. We have lost more than one mirror due to complaints over needed space and stuff like this doesn't help. If a mirror cannot cope with a few GB, then it should be dropped anyway. Our repos will get bigger, one way or the other. I share this opinion. The Arch repos are hardly large and even if we added 50 GB to them they would still wouldn't be that large. I know comparisons with other distributions are probably not a good idea on this list but it does help to get a general understanding of where we stand and what large really means. Debian - 428GB (http://www.debian.org/mirror/size) Fedora - 653GB (http://download.fedora.redhat.com/pub/DIRECTORY_SIZES.txt) Ubuntu - 421GB (https://wiki.ubuntu.com/Mirrors) openSUSE - 500GB+ (http://en.opensuse.org/openSUSE:Mirror_infrastructure) Thankfully, we don't keep around old releases of packages or isos. Our mirrors will never have to cope with the amount of data that other distributions make them cope with. I think since they are already mirroring 2TB+ worth of data from other distros, they can easily squeeze in 50GB of Arch, or more. I'd really like to resolve this problem in the course of this discussion since it has been brought up every time big packages are pending (mostly games). Personally, I think we don't need a policy or anything on this. Something very odd would have to happen for our repos to grow too much for our mirrors to handle. This is Arch, let's keep it simple and unbureaucratic. I'm not saying let's throw all that big shit into there but if there are potential packages that would improve the user experience, their size should not be the determining factor to their inclusion. -- Sven-Hendrik You need to keep in mind that's its not just the disk space that might cause problems here but traffic and especially bandwidth are. E.g. the our mainserver has about 10mbit/d bandwidth including mirroring, website etc.. And it all comes down to paying the bills to better cope with the load. So the final authority on this can only be those who handle the financial matters. Other than that, size is not an issue. Big distros have good funding, so size is really not an issue. -- GPG/PGP ID: B42DDCAD
Re: [arch-general] [arch-dev-public] Large packages in repositories
On 18 August 2010 16:37, Pierre Schmitzpie...@archlinux.de wrote: [...] -- Sven-Hendrik You need to keep in mind that's its not just the disk space that might cause problems here but traffic and especially bandwidth are. E.g. the our mainserver has about 10mbit/d bandwidth including mirroring, website etc.. One important issue which hasn't been raised is the fact that the bigger the package the longer it takes to sync than 1 package. Today's sync for me took 53 minutes the previous highest time i can remember is about 20 minutes and that was with the recent push of KDE 4.5 beta? into testing. I'm lucky in that I don't suffer any issues yet, but I can imagine that for other with smaller mirrors with lower bandwidth during this period everything else on the server is slowed because of this 1 instance of rsync. Not only that, but some of us have contracts to abide by which restrict the use of long-running processes beyond reasonable use so while multiple syncs can be done as a work-around it'd be nice to at least discuss some sort of policy here, even if it's just that a notification should be done on arch-mirrors when exceptionally large packages are about to go into the repos. I'm aware this is a one-off but a few years ago I'd be saying the same thing large games being a one-off.
Re: [arch-general] Some problems with a dell mini
On 18 August 2010 19:25, Andrea Crotti andrea.crott...@gmail.com wrote: Alexander Duscheleit ji...@archlinux.us writes: direct rendering is always Yes these days, because mesa includes a software render which makes you CPU do all the work. try: glxinfo | grep ^OpenGL here's what I get on my Intel Laptop: OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Intel(R) 945GM GEM 20100328 2010Q1 x86/MMX/SSE2 OpenGL version string: 1.4 Mesa 7.8.2 and here's what you SHOULDN'T get (from a VM with cirrus-vga): ji...@edultsp:~$ glxinfo | grep direct direct rendering: Yes ji...@edultsp:~$ glxinfo | grep OpenGL OpenGL vendor string: Mesa Project OpenGL renderer string: Software Rasterizer OpenGL version string: 2.1 Mesa 7.7.1 OpenGL shading language version string: 1.20 (Note, that it still supports direct rendering, but uses the Software Rasterizer.) So then yes it doesn't work as expected. Following the guide online in theory it should work also with hal and dbus running (with intel-dri). Maybe I'll try a xorg.conf to see if it works or not, if anyone has one working with 3D for a dell mini it would be great... Thanks I got a hold of the AspireOne. Plugged in my Arch-on-a-Stick and BAM! 3D is DEAD. Or, dying. I'm giving up on this as a regression of intel/mesa, because some months ago this same netbook played UrbanTerror on Ubuntu Netbook Remix. I can't test it on that again, because I see that the owner has rerwritten the disk with Windows 7. God bless the Linux Intel GFX developers. -- GPG/PGP ID: B42DDCAD
Re: [arch-general] [arch-dev-public] kde 4.5.0
It's good to see finally 4.5 will hit extra :) 1) Sometimes, when I change settings in 'systemsettings' (forgot which ones, have to investigate again), kwin and/or plasma-desktop freeze and I cannot do anything but move the mouse or switch to VT. 2) dolphin segfaults. A lot. All the time. It's annoying. 3) I don't understand why, but starting xbindkeys with KDE's autostart is broken: When I want to use qdbus or dolphin from xbindkeys, nothing happens. When I kill and launch it again later, everything seems to work. However if the problems reported by Thomas persist I would wait to 4.5.1 before upgrading - looking for smooth transition. On the composite issue I have a workaround thats works pretty good. I'm one of those people experiencing artifacts problems with Catalyst 10.7-3 on an ATI Readeon 5750HD. For some time it was a habit to just push twice alt+shift+f12 after login but now that's gone. After searching for a fix to this issue I found a commandline hack to automatically disable and enable composite in the KDE forums: $ qdbus org.kde.kwin /KWin org.kde.KWin.toggleCompositing qdbus org.kde.kwin /KWin org.kde.KWin.toggleCompositing So the trick was to put that in a script in ~/bin and tell KDE to run it on every start-up (a cleaner way to implement this will be welcomed). Another optimization I'm using since a week or so without *any* problems (with composite and KWin working at their best) is launching plasma-desktop with the --graphicssytem raster argument. This solved the exasperating low speed when performing ceratin tasks with plasmoids on the desktop (like rotating folder view plasmoids and so on). It works very nice with Yakuake too. /usr/share/autostart/plasma-desktop.desktop should look like this (only showing relevant part): [Desktop Entry] Exec=plasma-desktop --graphicssystem raster Credits goes to a video on YT and the folks at Chakra forum.
Re: [arch-general] Some problems with a dell mini
Ray Rashif schivmeis...@gmail.com writes: I got a hold of the AspireOne. Plugged in my Arch-on-a-Stick and BAM! 3D is DEAD. Or, dying. I'm giving up on this as a regression of intel/mesa, because some months ago this same netbook played UrbanTerror on Ubuntu Netbook Remix. I can't test it on that again, because I see that the owner has rerwritten the disk with Windows 7. God bless the Linux Intel GFX developers. -- GPG/PGP ID: B42DDCAD I found this page which describes exactly my machine http://en.gentoo-wiki.com/wiki/Dell_Inspiron_Mini_10_(1010)#Audio now I'm compiling the psb driver, reading from what they say I should reach an amazing resolution (I thought 1024x800 was the max) and maybe the 3d will work :)
Re: [arch-general] Some problems with a dell mini
Andrea Crotti andrea.crott...@gmail.com writes: Ray Rashif schivmeis...@gmail.com writes: I got a hold of the AspireOne. Plugged in my Arch-on-a-Stick and BAM! 3D is DEAD. Or, dying. I'm giving up on this as a regression of intel/mesa, because some months ago this same netbook played UrbanTerror on Ubuntu Netbook Remix. I can't test it on that again, because I see that the owner has rerwritten the disk with Windows 7. God bless the Linux Intel GFX developers. -- GPG/PGP ID: B42DDCAD I found this page which describes exactly my machine http://en.gentoo-wiki.com/wiki/Dell_Inspiron_Mini_10_(1010)#Audio now I'm compiling the psb driver, reading from what they say I should reach an amazing resolution (I thought 1024x800 was the max) and maybe the 3d will work :) Ok great, now after modprobe psb the framebuffer goes to an amazing resolution (the native I guess). But starting X is veryy bad still, maybe I have to tell to Xorg to load the psb driver...
Re: [arch-general] Some problems with a dell mini
Andrea Crotti andrea.crott...@gmail.com writes: Ok great, now after modprobe psb the framebuffer goes to an amazing resolution (the native I guess). But starting X is veryy bad still, maybe I have to tell to Xorg to load the psb driver... Very exciting we're almost there, I added this to xorg.conf --8---cut here---start-8--- Section Device Identifier Card0 Driver psb Option AccelMethod EXA Option DRI on #Option IgnoreACPI yes Option MigrationHeuristic greedy VendorName Intel Corporation BoardName System Controller Hub (SCH Poulsbo) Graphics Controller BusID PCI:0:2:0 EndSection --8---cut here---end---8--- And now I get a strange 1024x576, but at least it became usable again.ò Now I try to set explicitly the resolutions so let's see if it'll finally work.
Re: [arch-general] Some problems with a dell mini
Not done yet, even adding the right modes to the xorg.conf I can always only see the 1024x576 from xrandr. But another bad news, some kernel errors (I guess conflicts between psb and reiserfs) don't let me start networkmanager anymore, which is a bad thing...
Re: [arch-general] [signoff] kernel26 2.6.35.2-1
On 08/14/2010 04:46 PM, Tobias Powalowski wrote: Latest kernel is in testing, please signoff for both arches. greetings tpowa Tobias, I updated the box that 2.6.34.3 fails to boot do to dmraid problems (http://bugs.archlinux.org/task/20499) to 2.6.35.2-1 and the box boots with dmraid just fine. However, there is a problem with udev. During boot, the box hangs at udev start for a good 2 minutes. The display on the screen is: Waiting for Udev events to be processed: The corresponding dmesg failure is: Adding 1951860k swap on /dev/mapper/nvidia_baaccajap8. Priority:-1 extents:1 across:1951860k forcedeth :00:0a.0: irq 45 for MSI/MSI-X NET: Registered protocol family 10 lo: Disabled Privacy Extensions f71882fg: Found f71882fg chip at 0xa00, revision 32 f71882fg f71882fg.2560: Fan: 1 is in duty-cycle mode f71882fg f71882fg.2560: Fan: 2 is in duty-cycle mode f71882fg f71882fg.2560: Fan: 3 is in duty-cycle mode f71882fg f71882fg.2560: Fan: 4 is in duty-cycle mode eth0: no IPv6 routers present INFO: task modprobe:1642 blocked for more than 120 seconds. echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. modprobe D 0 1642 1640 0x 880226d2ba28 0082 88022fca 8802 00014f40 00014f40 880226d2bfd8 880226d2bfd8 880226d2bfd8 8802276dbe70 880226d2bfd8 00014f40 Call Trace: [a01c3ba5] usb_kill_urb+0x85/0xc0 [usbcore] [810717c0] ? autoremove_wake_function+0x0/0x40 [a01f6831] usbhid_init_reports+0xb1/0x120 [usbhid] [a01f6d53] usbhid_start+0x4b3/0x5a0 [usbhid] [a02bf6d8] hid_device_probe+0x98/0xe0 [hid] [812875ba] ? driver_sysfs_add+0x5a/0x90 [81287896] driver_probe_device+0x96/0x1c0 [81287a60] ? __device_attach+0x0/0x60 [81287aab] __device_attach+0x4b/0x60 [81286474] bus_for_each_drv+0x64/0x90 [8128772f] device_attach+0x8f/0xb0 [81286ee5] bus_probe_device+0x25/0x40 [81284c2f] device_add+0x4ff/0x5e0 [a02bf0a7] hid_add_device+0x87/0x1b0 [hid] [a01f44b9] usbhid_probe+0x329/0x500 [usbhid] [a01c8a2b] usb_probe_interface+0xfb/0x1f0 [usbcore] [81287896] driver_probe_device+0x96/0x1c0 [81287a5b] __driver_attach+0x9b/0xa0 [812879c0] ? __driver_attach+0x0/0xa0 [812867ce] bus_for_each_dev+0x5e/0x90 [81287559] driver_attach+0x19/0x20 [81287067] bus_add_driver+0xc7/0x2e0 [81287cd1] driver_register+0x71/0x140 [a01c76f8] usb_register_driver+0xb8/0x170 [usbcore] [a0116000] ? hid_init+0x0/0xd1 [usbhid] [a0116093] hid_init+0x93/0xd1 [usbhid] [81002149] do_one_initcall+0x39/0x1a0 [8108cdeb] sys_init_module+0xbb/0x200 [81009e82] system_call_fastpath+0x16/0x1b I know it fails because after the boot process completes, I get errors like: 12:59 nirvana:~/arch/pkg/parnell Broadcast message from nut (Wed Aug 18 12:59:54 2010): UPS archangel_...@archangel.3111skyline.com is unavailable So something is wrong. What do you want me to do? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] [signoff] kernel26 2.6.35.2-1
On 08/18/2010 01:24 PM, David C. Rankin wrote: Call Trace: [a01c3ba5] usb_kill_urb+0x85/0xc0 [usbcore] [810717c0] ? autoremove_wake_function+0x0/0x40 [a01f6831] usbhid_init_reports+0xb1/0x120 [usbhid] Tobias, I'm sure you know, but 'usbhid' is the network-ups-tools driver. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com
Re: [arch-general] [signoff] kernel26 2.6.35.2-1
Am Mittwoch 18 August 2010 schrieb David C. Rankin: On 08/18/2010 01:24 PM, David C. Rankin wrote: Call Trace: [a01c3ba5] usb_kill_urb+0x85/0xc0 [usbcore] [810717c0] ? autoremove_wake_function+0x0/0x40 [a01f6831] usbhid_init_reports+0xb1/0x120 [usbhid] Tobias, I'm sure you know, but 'usbhid' is the network-ups-tools driver. usbhid is for usb input devices, like keyboard mouse and such. -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
Re: [arch-general] [arch-dev-public] Mailman 2.1.13-2 in testing
following http://bugs.archlinux.org/task/20481 I removed the dependency on apache. -Andy
Re: [arch-general] commitpkg script than handle better splitted package
On Tue, Aug 17, 2010 at 5:12 AM, Laurent Carlier lordhea...@gmail.com wrote: Le lundi 16 août 2010 17:30:54, vous avez écrit : Le lundi 16 août 2010 17:24:29, vous avez écrit : Le lundi 16 août 2010 14:10:10, Dan McGee a écrit : Patches are a lot more likely to get looked at by any of us. And yes, this should probably be more than one patch. http://projects.archlinux.org/devtools.git/ Hre are the patches (5), i hope i've not introduce bug while merging my changes to the git repo :-p 0001-Moved-file-s-sending-to-the-staging-dir-to-the-funct.patch 0002-Doesn-t-manage-monolithic-and-splitted-packages-the-.patch 0003-Detect-if-arch-is-redefined-in-the-package-function-.patch 0004-Now-manage-if-arch-is-redefined-and-not-in-default-a.patch 0005-Manage-redefintion-of-pkgver-and-pkgver-in-the-packa.patch patches are available here: http://pkgbuild.com/~lcarlier/ Regards, Rebased the patches, and add another patch: 0006-Remove-useless-number-from-continue.patch Pierre, is this something you can review since you have taken the lead on devtools/dbscripts? -Dan
Re: [arch-general] Referencing $srcdir in PKGBUILD?
Am 17.08.2010 13:52, schrieb Ray Rashif:
On 17 August 2010 19:32, Philipp Überbacher hollun...@lavabit.com wrote:
Excerpts from Loui Chang's message of 2010-08-17 13:14:44 +0200:
On Tue 17 Aug 2010 13:01 +0200, Philipp Überbacher wrote:
Excerpts from Loui Chang's message of 2010-08-17 12:35:41 +0200:
On Tue 17 Aug 2010 12:09 +0200, Heiko Baums wrote:
Am Tue, 17 Aug 2010 19:15:34 +1000
schrieb Allan McRae al...@archlinux.org:
grep your files in your package for $srcdir (the actual value...).
If it is not in a config file or RPATH or the like, you can probably
ignore it.
I'm not quite sure if this is not a bug in makepkg, because I
have this problem with almost all of my packages in AUR since the latest
update to pacman 3.4.0. I never got this message before and I haven't
changed such elementary parts of the packages. And if I'm right this
problem appears with almost every package which I install from AUR.
But I need to watch it more narrowly.
You'll get that with any package that contains debugging symbols.
So it isn't about the usual 'cd $srcdir/${pkgname}-${pkgver}' ?
No, it's about build directories being referenced in the finished
package, not the PKGBUILD.
Oh.. I assumed it was some random annoyance and ignored it. I've seen it
a number of times already.
So 'grep -R $somedistinctpartofthepathtoPKGBUILDS $pkg' should find the
offending file? And then some nasty patching to fix it?
It's not much of a big deal, and there's rarely need for any nasty
patching. It serves as a reminder to check for accidental inclusion
of build paths in important runtime/system files, which often is an
upstream build issue or user-specific mistake. Cases where this can be
ignored and is usually the most prevalent is, for example,
documentation-related files.
Just run this from the makepkg build dir:
grep -R $(pwd)/src pkg/
--
GPG/PGP ID: B42DDCAD
Hello,
thank you for this enlightning thread. Now I understand why (nearly) all of
my emacs packages show this error message.
If you byte-compile an .el-file, emacs writes something like
;;; Compiled by haa...@frege on Thu Aug 19 00:35:21 2010
;;; from file
/home/haawda/paketierung/maintained_by_me/auctex-cvs/src/auctex-build/preview/prv-emacs.el
;;; in Emacs version 24.0.50.1
;;; with all optimizations.
to the beginning of the .elc-file. Well, all this is harmless, because it is
just a comment,
but it is annoying . Does someone know how this can be avoided?
Regards Stefan
[arch-general] gnome-keyring and ssh without login manager
On a newly-set-up promiscuous USB system, I've chosen to skip a DE, and ultimately also forewent a login manager. Normally, I'd be happy with an askpass client, but I've noticed that I cannot do without nm-applet on this installation, and consequently have ended up with gnome-keyring installed alongside as well. So I thought, hey, I could make use of that thing, like I make use of kwallet with ksshaskpass on a KDE system. Unfortunately, after some headache-inducing trial-and-errors, it occurs to me as if this is fat hope. The technical background is as follows: 1) Openbox WM only + pcmanfm for desktop management 2) X is autostarted on bootup via su/inittab 3) nm-applet autoconnects to my desired WiFi without any kind of prompting (though it did ask for a password to set up a new key the first time) 4) gnome-keyring does not appear to be running post-startup (so we can assume nm-applet calls it on demand only) I do know that at least one similar issue with regards to having a login manager, realtime, is worked around by having the following in /etc/pam.d/su: session requiredpam_limits.so So I tried something akin to that with the gnome_keyring.so stuff, to no avail. Any chance? You tell me. -- GPG/PGP ID: B42DDCAD
Re: [arch-general] [PATCH 28/48] Use bash-style conditionals when setting up the hardware clock.
I am missing the difference. Diff please?
Sent from my Nexus One
On Aug 18, 2010 2:41 AM, Kurt J. Bosch kjb-temp-2...@alpenjodel.de
wrote:
Am 2010-06-30 23:47, schrieb Victor Lowther:
Trying to stick with POSIX syntax only just slows things down.
---
rc.sysinit | 27 +++
1 files changed, 11 insertions(+), 16 deletions(-)
diff --git a/rc.sysinit b/rc.sysinit
index 29adeca..f3e60b7 100755
--- a/rc.sysinit
+++ b/rc.sysinit
@@ -44,27 +44,22 @@ fi
HWCLOCK_PARAMS=--hctosys
case $HARDWARECLOCK in
- UTC) $HWCLOCK_PARAMS --utc;;
- localtime) HWCLOCK_PARAMS=$HWCLOCK_PARAMS --localtime;;
+ UTC) HWCLOCK_PARAMS+= --utc;;
+ localtime) HWCLOCK_PARAMS+= --localtime;;
*) HWCLOCK_PARAMS=;;
esac
-if [ -n $HWCLOCK_PARAMS ]; then
+if [[ $HWCLOCK_PARAMS ]]; then
# enable rtc access
- /sbin/modprobe -q rtc-cmos
- # some custom kernels use rtc/genrtc, try to load those too
- /sbin/modprobe -q rtc
- /sbin/modprobe -q genrtc
+ /sbin/modprobe -q -a rtc-cmos rtc genrtc
# If devtmpfs is used, the required RTC device already exists now
# Otherwise, create whatever device is available
- if [ ! -c /dev/rtc -a ! -c /dev/rtc0 ]; then
- if [ -f /sys/class/rtc/rtc0/dev ]; then
- IFS=: read -r major minor /sys/class/rtc/rtc0/dev
- /bin/mknod /dev/rtc0 c $major $minor
- elif [ -f /sys/class/misc/rtc/dev ]; then
- IFS=: read -r major minor /sys/class/misc/rtc/dev
- /bin/mknod /dev/rtc c $major $minor
- fi
+ if ! [[ -c /dev/rtc || -c /dev/rtc0 ]]; then
+ for dev in /sys/class/rtc/rtc0/dev /sys/class/misc/rtc/dev; do
+ [[ -e $dev ]] || continue
+ IFS=: read -r major minor $dev
+ /bin/mknod /dev/rtc c $major $minor
+ done
fi
Actually this doesn't do the same. What about the following?
if ! [[ -c /dev/rtc || -c /dev/rtc0 ]]; then
for dev in /sys/class/rtc/rtc0 /sys/class/misc/rtc; do
[[ -e $dev/dev ]] || continue
IFS=: read -r major minor $dev/dev
/bin/mknod /dev/${dev##*/} c $major $minor
done
fi
Re: [arch-general] [PATCH 28/48] Use bash-style conditionals when setting up the hardware clock.
On 19/08/10 14:23, Victor Lowther wrote:
I am missing the difference. Diff please?
Yours:
+ /bin/mknod /dev/rtc c $major $minor
His:
/bin/mknod /dev/${dev##*/} c $major $minor
Yours creates /dev/rtc and his creates /dev/rtc and /dev/rtc0
Allan
Re: [arch-general] [PATCH 28/48] Use bash-style conditionals when setting up the hardware clock.
On Thu, Aug 19, 2010 at 02:34:50PM +1000, Allan McRae wrote:
On 19/08/10 14:23, Victor Lowther wrote:
I am missing the difference. Diff please?
Yours:
+ /bin/mknod /dev/rtc c $major $minor
His:
/bin/mknod /dev/${dev##*/} c $major $minor
Yours creates /dev/rtc and his creates /dev/rtc and /dev/rtc0
Allan
Couldn't we avoid all this by just flipping a switch in the kernel?
CONFIG_RTC_DRV_CMOS=y
If it's compiled into the kernel, udev picks it up and creates the /dev
nodes for us.
d
