- Arch-general - lists.archlinux.org

[arch-general] speakers don't turn off when headphones inserted
by Scott Weisman 03 Jun '09

03 Jun '09

Hello, I just obtained a Fujitsu P7120 notebook (a very nice model, by the way). Overall, I am getting this working with Arch just fine (although I would definitely appreciate pointers from anyone else who has installed Arch, especially as I have been using a desktop until now and haven't had the need to configure notebook-type features). One problem I am having that I don't know how to fix is that when I plug in headphones, the speakers don't turn off. Alsamixer shows that the headphones and speakers have separate controls, something I have never seen in a notebook before. While cool, I would really love to have this automatically toggle as expected. Does anyone have a suggestion? Thanks, Scott

5 4

Re: [arch-general] aiksaurus - build error - clean chroot
by Baho Utot 02 Jun '09

02 Jun '09

On Wed, 2009-06-03 at 08:41 +1000, Allan McRae wrote: > Baho Utot wrote: > > aiksaurus has 3 errors when building with gcc-4.4.0 > > > > I have attached a patch to fix. > > > > I am building packages in extra how should I report these problems. > > > > With a bug report or here? > > > > Better to use a bug report as attachements do not make it to this list... > > Allan > > > > Ok bug report filed

1 0

[arch-general] aiksaurus - build error - clean chroot
by Baho Utot 02 Jun '09

02 Jun '09

aiksaurus has 3 errors when building with gcc-4.4.0 I have attached a patch to fix. I am building packages in extra how should I report these problems. With a bug report or here?

2 1

[arch-general] Building in clean chroot
by Baho Utot 02 Jun '09

02 Jun '09

I keep getting these errors when building packages from extra Is there a way to "turn off" this or do I have to manually do this every time it rears its ugly head? Proceed with installation? [Y/n] checking package integrity... checking for file conflicts... error: failed to commit transaction (conflicting files) error: could not prepare transaction /usr/share/info/dir exists in both 'libksba' and 'libassuan' libksba: /usr/share/info/dir exists in filesystem libassuan: /usr/share/info/dir exists in filesystem Errors occurred, no packages were upgraded. Thanks

3 2

Re: [arch-general] [arch-dev-public] Vim plugins updated
by Henning Garus 02 Jun '09

02 Jun '09

On Sun, May 31, 2009 at 6:24 PM, Dan McGee <dpmcgee(a)gmail.com> wrote: > I just went though all the vim-* packages and updated them to the > latest versions, as well as changed their install location to match > the new vim layout. Please let me know if there are any problems with > the new packages. > > These should move to [extra] whenever vim leaves [testing]. > There are some other packages which use the old vim layout. In extra: cmake (/usr/share/vim/{syntax/cmake-syntax.vim,indent/cmake-indent.vim) mercurial (usr/share/vim/syntax/HGAnnotate.vim) clisp puts some files into /usr/share/vim/vimfiles/after/ which is still in my runtimepath with vim from testing. There are more packages in community, which will have to be changed when vim goes to extra: clewn icomplete pacman-contrib txt2tags vim-*

2 1

Re: [arch-general] SRCDEST="/path/to/folder"
by Baho Utot 01 Jun '09

01 Jun '09

On Sun, 2009-05-31 at 23:37 +1000, Allan McRae wrote: > Allan McRae wrote: > > Baho Utot wrote: > >> I am Building in a clean chroot according to the wiki > >> > >> The Chroot sub-directory is /home/Chroot/root > >> > >> I have set SRCDEST="/sources" in the makepkg in /home/Chroot/root/etc > >> and then > >> mkdir /home/Chroot/root/sources chmod 777 /home/Chroot/root/sources > >> > >> Is this correct to get makepkg to store the sources in that > >> sub-directory? > >> > >> It presently doesn't work for me or I did something wrong. > >> > >> Can anyone help? > >> > > > > As far as makepkg goes, it should store the sources in /sources. But > > my guess is makechrootpkg is moving the source files from there to the > > directory you launched it from. Have not actually looked at this though. > > Or an even better explanation (which also could be wrong), it puts them > in the rw portion of the union filesystem and that gets cleared. > > I think the message to take from this is that this setup will probably > not work... > > Allan > > Ok I'll have to fix my build script to do it

2 2

Re: [arch-general] [signoff] lvm2-2.02.47-1
by Eric Bélanger 31 May '09

31 May '09

On Sun, May 24, 2009 at 3:23 PM, Eric Bélanger <snowmaniscool(a)gmail.com> wrote: > Hi, > > lvm2-2.02.47-1 is in testing. Minor upstream updates (from 2.02.45). > Please test/signoff. > > Eric > > bump. Anyone? I believe only another dev use this so signoff from users would be good.

2 1

[arch-general] agg 2.5-2 i686 build error
by Baho Utot 31 May '09

31 May '09

Building in a clean chroot per wiki gcc version 4.4.0 20090505 (prerelease) (GCC) ==> Making package: agg 2.5-2 i686 (Sun May 31 12:35:08 UTC 2009) libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../include -I../../../include -I -march=athlon -O2 -pipe -fomit-frame-pointer -c agg_platform_support.cpp -fPIC -DPIC -o .libs/libaggplatformX11_la-agg_platform_support.o /bin/sh ../../../libtool --tag=CXX --mode=link g++ -I../../../include -I -march=athlon -O2 -pipe -fomit-frame-pointer -version-info 2:4:0 -L -o libaggplatformX11.la -rpath /usr/lib libaggplatformX11_la-agg_platform_support.lo -lX11 libtool: link: require no space between `-L' and `-o' make[3]: *** [libaggplatformX11.la] Error 1

2 3

[arch-general] SRCDEST="/path/to/folder"
by Baho Utot 31 May '09

31 May '09

I am Building in a clean chroot according to the wiki The Chroot sub-directory is /home/Chroot/root I have set SRCDEST="/sources" in the makepkg in /home/Chroot/root/etc and then mkdir /home/Chroot/root/sources chmod 777 /home/Chroot/root/sources Is this correct to get makepkg to store the sources in that sub-directory? It presently doesn't work for me or I did something wrong. Can anyone help?

2 2

[arch-general] Fix or not fix? install scriptlets with user handling.
by Gerardo Exequiel Pozzi 30 May '09

30 May '09

Hi, Many package manage user/groups in many differents ways. (no much problem here) Many do things like: @ when installed 1) check if not user foo exists then create it 2) check if not group foo exists then create it @when removed 1) remove the user foo (without check) 2) remove the group foo (without check) Because by default the option USERGROUPS_ENAB is set to yes, when user "foo" is removed also the group "foo" is removed, so the groupdel command will fail, then pacman show the message: "error: scriptlet failed to execute correctly". The solution is trivial, check with getent before remove, just like some packages do it before create the user. My question here, is there interest in resolving this? Currently I have the choice of those who fail (both extra and comunity). Do you send a report to everyone who fail to flyspray with the patch (low priority)? Also I can unify the user creation step, some .install check with "grep" and others with "getent". I prefer the proper getent method. The only package in [core] that have this issue is dbus-core [#1] and is actually reported. [#1] http://bugs.archlinux.org/task/14810 -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D

15 32