Re: [arch-general] Parallels 7 Tools
On Wednesday 04 Apr 2012 21:07:03 Joshua Poehls wrote: Wow. I'm afraid that's way out of my league. :\ Not wanting to state the obvious, but it looks like it's going to be painful to get Arch working smoothly with Parallels. Have you considered using VirtualBox instead? Support is excellent, and you can probably export the VM from Parallels into VirtualBox without too much hassle. Paul
Re: [arch-general] Parallels 7 Tools
Yeah. I thought of that, just didn't want to if I didn't have to. I think I'll do that though. VirtualBox here I come. Thanks, -- Joshua Poehls On Apr 5, 2012, at 3:19 AM, Paul Gideon Dann pdgid...@gmail.com wrote: On Wednesday 04 Apr 2012 21:07:03 Joshua Poehls wrote: Wow. I'm afraid that's way out of my league. :\ Not wanting to state the obvious, but it looks like it's going to be painful to get Arch working smoothly with Parallels. Have you considered using VirtualBox instead? Support is excellent, and you can probably export the VM from Parallels into VirtualBox without too much hassle. Paul
[arch-general] avahi problem
Hey There, I've installed an Arch Linux server in our office for serving files over the network via Bonjour/avahi. All computers are connected to an ADSL modem via wireless. Only the server is connected via LAN. When I start the server, I can ping it: --- CMD OUTPUT --- $ ping office.local PING office.local (192.168.1.107): 56 data bytes 64 bytes from 192.168.1.107: icmp_seq=0 ttl=64 time=1.080 ms 64 bytes from 192.168.1.107: icmp_seq=1 ttl=64 time=1.671 ms 64 bytes from 192.168.1.107: icmp_seq=2 ttl=64 time=0.979 ms ^C --- office.local ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.979/1.243/1.671/0.305 ms $ ping 192.168.1.107 PING 192.168.1.107 (192.168.1.107): 56 data bytes 64 bytes from 192.168.1.107: icmp_seq=0 ttl=64 time=1.194 ms 64 bytes from 192.168.1.107: icmp_seq=1 ttl=64 time=1.229 ms ^C --- 192.168.1.107 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.194/1.212/1.229/0.017 ms After a few minutes however I can't ping it using the .local address: *$ ping office.local* *ping: cannot resolve office.local: Unknown host* $ ping 192.168.1.107 PING 192.168.1.107 (192.168.1.107): 56 data bytes 64 bytes from 192.168.1.107: icmp_seq=0 ttl=64 time=1.375 ms 64 bytes from 192.168.1.107: icmp_seq=1 ttl=64 time=1.562 ms ^C --- 192.168.1.107 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.375/1.469/1.562/0.094 ms --- CMD OUTPUT --- If I restart avahi-daemon, we can ping office.local for another few minutes. Any ideas? --- Quis custodiet ipsos custodes?
Re: [arch-general] avahi problem
Have you configured your /etc/nsswitch.conf (server side) as suggested on https://wiki.archlinux.org/index.php/Avahi#Hostname_resolution ? 2012/4/5, Alper Kanat tu...@raptiye.org: Hey There, I've installed an Arch Linux server in our office for serving files over the network via Bonjour/avahi. All computers are connected to an ADSL modem via wireless. Only the server is connected via LAN. When I start the server, I can ping it: --- CMD OUTPUT --- $ ping office.local PING office.local (192.168.1.107): 56 data bytes 64 bytes from 192.168.1.107: icmp_seq=0 ttl=64 time=1.080 ms 64 bytes from 192.168.1.107: icmp_seq=1 ttl=64 time=1.671 ms 64 bytes from 192.168.1.107: icmp_seq=2 ttl=64 time=0.979 ms ^C --- office.local ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.979/1.243/1.671/0.305 ms $ ping 192.168.1.107 PING 192.168.1.107 (192.168.1.107): 56 data bytes 64 bytes from 192.168.1.107: icmp_seq=0 ttl=64 time=1.194 ms 64 bytes from 192.168.1.107: icmp_seq=1 ttl=64 time=1.229 ms ^C --- 192.168.1.107 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.194/1.212/1.229/0.017 ms After a few minutes however I can't ping it using the .local address: *$ ping office.local* *ping: cannot resolve office.local: Unknown host* $ ping 192.168.1.107 PING 192.168.1.107 (192.168.1.107): 56 data bytes 64 bytes from 192.168.1.107: icmp_seq=0 ttl=64 time=1.375 ms 64 bytes from 192.168.1.107: icmp_seq=1 ttl=64 time=1.562 ms ^C --- 192.168.1.107 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.375/1.469/1.562/0.094 ms --- CMD OUTPUT --- If I restart avahi-daemon, we can ping office.local for another few minutes. Any ideas? --- Quis custodiet ipsos custodes?
Re: [arch-general] avahi problem
I did. However I found out that there's not much difference in the case of host resolution. When hosts line is like the following: $ cat /etc/nsswitch.conf | grep hosts hosts: files dns I can ping office.local from other machines on the network. If I change that line like this: hosts: files mdns4_minimal dns mdns4 then I realized that host resolution is a little bit more slower. Connecting via SSH takes 3-4 seconds longer. Even if I change the line like this, office.local becomes inaccessible after a few minutes. I tried enabling avahi-dnsconfd which also made no difference. --- Quis custodiet ipsos custodes? On Thu, Apr 5, 2012 at 14:32, Jochen Maes (Gcool) gcool...@gmail.comwrote: Have you configured your /etc/nsswitch.conf (server side) as suggested on https://wiki.archlinux.org/index.php/Avahi#Hostname_resolution ? 2012/4/5, Alper Kanat tu...@raptiye.org: Hey There, I've installed an Arch Linux server in our office for serving files over the network via Bonjour/avahi. All computers are connected to an ADSL modem via wireless. Only the server is connected via LAN. When I start the server, I can ping it: --- CMD OUTPUT --- $ ping office.local PING office.local (192.168.1.107): 56 data bytes 64 bytes from 192.168.1.107: icmp_seq=0 ttl=64 time=1.080 ms 64 bytes from 192.168.1.107: icmp_seq=1 ttl=64 time=1.671 ms 64 bytes from 192.168.1.107: icmp_seq=2 ttl=64 time=0.979 ms ^C --- office.local ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.979/1.243/1.671/0.305 ms $ ping 192.168.1.107 PING 192.168.1.107 (192.168.1.107): 56 data bytes 64 bytes from 192.168.1.107: icmp_seq=0 ttl=64 time=1.194 ms 64 bytes from 192.168.1.107: icmp_seq=1 ttl=64 time=1.229 ms ^C --- 192.168.1.107 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.194/1.212/1.229/0.017 ms After a few minutes however I can't ping it using the .local address: *$ ping office.local* *ping: cannot resolve office.local: Unknown host* $ ping 192.168.1.107 PING 192.168.1.107 (192.168.1.107): 56 data bytes 64 bytes from 192.168.1.107: icmp_seq=0 ttl=64 time=1.375 ms 64 bytes from 192.168.1.107: icmp_seq=1 ttl=64 time=1.562 ms ^C --- 192.168.1.107 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.375/1.469/1.562/0.094 ms --- CMD OUTPUT --- If I restart avahi-daemon, we can ping office.local for another few minutes. Any ideas? --- Quis custodiet ipsos custodes?
Re: [arch-general] avahi problem
Are you running a firewall on the Arch box (or elsewhere in the network) through which the avahi traffic has to pass? As I understand it (various similar issues found through Google), you need to explicitly allow mulitcast DNS traffic (udp 5353) for this feature to work. 2012/4/5, Alper Kanat tu...@raptiye.org: I did. However I found out that there's not much difference in the case of host resolution. When hosts line is like the following: $ cat /etc/nsswitch.conf | grep hosts hosts: files dns I can ping office.local from other machines on the network. If I change that line like this: hosts: files mdns4_minimal dns mdns4 then I realized that host resolution is a little bit more slower. Connecting via SSH takes 3-4 seconds longer. Even if I change the line like this, office.local becomes inaccessible after a few minutes. I tried enabling avahi-dnsconfd which also made no difference. --- Quis custodiet ipsos custodes? On Thu, Apr 5, 2012 at 14:32, Jochen Maes (Gcool) gcool...@gmail.comwrote: Have you configured your /etc/nsswitch.conf (server side) as suggested on https://wiki.archlinux.org/index.php/Avahi#Hostname_resolution ? 2012/4/5, Alper Kanat tu...@raptiye.org: Hey There, I've installed an Arch Linux server in our office for serving files over the network via Bonjour/avahi. All computers are connected to an ADSL modem via wireless. Only the server is connected via LAN. When I start the server, I can ping it: --- CMD OUTPUT --- $ ping office.local PING office.local (192.168.1.107): 56 data bytes 64 bytes from 192.168.1.107: icmp_seq=0 ttl=64 time=1.080 ms 64 bytes from 192.168.1.107: icmp_seq=1 ttl=64 time=1.671 ms 64 bytes from 192.168.1.107: icmp_seq=2 ttl=64 time=0.979 ms ^C --- office.local ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.979/1.243/1.671/0.305 ms $ ping 192.168.1.107 PING 192.168.1.107 (192.168.1.107): 56 data bytes 64 bytes from 192.168.1.107: icmp_seq=0 ttl=64 time=1.194 ms 64 bytes from 192.168.1.107: icmp_seq=1 ttl=64 time=1.229 ms ^C --- 192.168.1.107 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.194/1.212/1.229/0.017 ms After a few minutes however I can't ping it using the .local address: *$ ping office.local* *ping: cannot resolve office.local: Unknown host* $ ping 192.168.1.107 PING 192.168.1.107 (192.168.1.107): 56 data bytes 64 bytes from 192.168.1.107: icmp_seq=0 ttl=64 time=1.375 ms 64 bytes from 192.168.1.107: icmp_seq=1 ttl=64 time=1.562 ms ^C --- 192.168.1.107 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 1.375/1.469/1.562/0.094 ms --- CMD OUTPUT --- If I restart avahi-daemon, we can ping office.local for another few minutes. Any ideas? --- Quis custodiet ipsos custodes?
Re: [arch-general] avahi problem
The firewall on our modem is disabled. Afaik default Arch Linux installations doesn't come up with firewall enabled. I don't have a firewall on my Mac either. So I believe this has nothing to do with the firewall. Thank you for your interest btw. --- Quis custodiet ipsos custodes? On Thu, Apr 5, 2012 at 15:05, Jochen Maes (Gcool) gcool...@gmail.comwrote: Are you running a firewall on the Arch box (or elsewhere in the network) through which the avahi traffic has to pass? As I understand it (various similar issues found through Google), you need to explicitly allow mulitcast DNS traffic (udp 5353) for this feature to work.
Re: [arch-general] [signoff] linux-3.2.14-1
Am 04.04.2012 08:59, schrieb Tobias Powalowski: Hi guys, please signoff 3.2.14 series for both arches. package is not in testing, please grab it from here: http://dev.archlinux.org/~tpowa/linux/ This will move to [core] directly, because 3.3.1 is in [testing]. greetings tpowa bump anyone? -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: OpenPGP digital signature
Re: [arch-general] Installing in VirtualBox - Screen goes black during installation
to, 2012-04-05 kello 07:41 -0500, Joshua Poehls kirjoitti: I started installing Arch in VirtualBox this morning but twice now the screen goes black at some point during (or right after) the package download step and never comes back. Well Linux in general has a powersaving or screensaving feature don't know the exact meaning/use of it, but anyway in console, if you don't touch the keyboard for a while the screen will blank itself. Pressing any key will wake it up again. Don't know if this is the thing you are experiencing... signature.asc Description: This is a digitally signed message part
Re: [arch-general] Installing in VirtualBox - Screen goes black during installation
Doh. I think that was it. Thank you... -- Joshua Poehls On Thu, Apr 5, 2012 at 7:45 AM, Jesse Juhani Jaara jesse.ja...@gmail.comwrote: to, 2012-04-05 kello 07:41 -0500, Joshua Poehls kirjoitti: I started installing Arch in VirtualBox this morning but twice now the screen goes black at some point during (or right after) the package download step and never comes back. Well Linux in general has a powersaving or screensaving feature don't know the exact meaning/use of it, but anyway in console, if you don't touch the keyboard for a while the screen will blank itself. Pressing any key will wake it up again. Don't know if this is the thing you are experiencing...
Re: [arch-general] USB mounted into wrong directory
It would appear that on Apr 4, Tom Gundersen did say:
On Apr 4, 2012 11:14 AM, David pixelsh...@gmail.com wrote:
Uh, is there any way to revert to old mapping?
I do not like the new one.
You'd have to check with udisks. My guess is that while reverting might
work for the time being /media is going away in the future as the old
implementation had issues (namespace and privacy in particular). If you
have concerns about the new approach I suggest raising them sooner rather
than later, before things become hard to change.
Pardon me for jumping in here, but you just reminded me that I read
somewhere that /media is going away. Can't say that THAT in it self bothers
me, since I don't use it. But I've been not allowing anything to auto-mount
usb devices for so long now that I've forgotten what (if anything) I had to do
to prevent it in Arch {or for that mater any of the other Linux that I
multi-boot...} My method of dealing with usb sticks/drives etc, is that if
root hasn't found the time to set up a custom fstab entry based on either
LABEL=UniquePartitionName for approved usb drives, or /dev/disk/by-id for
approved usb sticks, then only by getting root to proactively do something
about it do I want the durned thing mounted at all. My fstab method allows
for custom mount points where the user simply issues a mount mountpoint
and/or umount mountpoint command to access the approved device. I usually
do this from mc where the alt+enter binding will paste the mountpoint
dirname to the command line...
Anyway my only concern with the changes that are driving the demise of
media is that I'm hoping they won't result in automatic reactivation of auto
mounting tools that I don't want, don't use, don't understand, and mostly
don't remember how to disable...
Do you know if I'm going to have to go there again???
--
| ~^~ ~^~
| ? ? Joe (theWordy) Philbrook
| ^J(tWdy)P
|\___/ jtw...@ttlc.net
Re: [arch-general] Parallels 7 Tools
I have tried several times to get the Parallels tools to install in Arch and was never successful. I run Arch through Virtual Box and it's very smooth. Squall
[arch-general] Any way to revert chroot to gcc46?
Guys, Is there any way to revert my chroot for building back to gcc46 immediately prior to this last gcc47 update? Obvious reasons - bug fixes required due to new gcc47 C11 C11++ extension implementation, etc..., but I would like to continue building until the bugs are fixed. Is there a reasonable way to do that absent having to set up and point the chroot pacman.conf at a hand-built repo with just the gcc46 files in it? -- David C. Rankin, J.D.,P.E.
Re: [arch-general] Any way to revert chroot to gcc46?
On 04/05/2012 03:36 PM, David C. Rankin wrote: Guys, Is there any way to revert my chroot for building back to gcc46 immediately prior to this last gcc47 update? Obvious reasons - bug fixes required due to new gcc47 C11 C11++ extension implementation, etc..., but I would like to continue building until the bugs are fixed. Is there a reasonable way to do that absent having to set up and point the chroot pacman.conf at a hand-built repo with just the gcc46 files in it? copy the gcc binary/pkgbuilt files to chroot/root/repo repo-add gccwhatever* chroot chroot/root pacman -S gccwhatever exit
Re: [arch-general] Any way to revert chroot to gcc46?
On 04/05/2012 03:43 PM, Baho Utot wrote: copy the gcc binary/pkgbuilt files to chroot/root/repo repo-add gccwhatever* chroot chroot/root pacman -S gccwhatever exit Thanks Baho, I'll have to play with it a bit. I don't really see how that fits in with the mkarchroot setup (probably does, I just don't see it). The build on gcc 4.7 is coming along. Strangely, a bunch of the errors are during the package() part of the build with libtool relink: errors like: libtool: relink: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib/crti.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/crtbeginS.o .libs/gwenview_dummy.o -Wl,-rpath -Wl,/opt/trinity/lib -Wl,-rpath -Wl,/opt/tqt3/lib -L/build/src/gwenview/src/gvcore/.libs -L/opt/trinity/lib -L/opt/tqt3/lib -L/usr/lib/mysql -L/usr/X11R6/lib64 -L/build/pkg/opt/trinity/lib -ltdeinit_gwenview -L/usr/lib -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib -lgwenviewcore -ltdeprint -lkmediaplayer -ljpeg -lexiv2 -lkipi -lkio -ltdeui -ltdecore -L/build/pkg/usr/lib -lkutils -L/build/pkg/opt/tqt3/lib -ltqt-mt -lpq -lmysqlclient -lXrender -lXrandr -lXcursor -lXinerama -lXft -lfreetype -lfontconfig -ldl -lpng -lz -lXext -lX11 -lSM -lICE -ltqt -lpthread -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0 -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/crtendS.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib/crtn.o -O2 -march=x86-64 -mtune=generic -O2 -Wl,--no-undefined -Wl,--allow-shlib-undefined -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z -Wl,relro -Wl,--hash-style=gnu -Wl,-soname -Wl,gwenview.so -o .libs/gwenview.so /usr/bin/ld: cannot find -ltdeinit_gwenview collect2: error: ld returned 1 exit status libtool: install: error: relink `gwenview.la' with the above command before installing it make[3]: *** [install-tdeinitLTLIBRARIES] Error 1 Still trying to figure out why we are 'relinking' during 'package()'... -- David C. Rankin, J.D.,P.E.
