- Arch-general - lists.archlinux.org

[arch-general] Bochs need gdb-stub support, right?
by goodmenzy＠gmail.com 08 Sep '11

08 Sep '11

Hi, I think bochs should add --enable-gdb-stub option when configuring. I build the modified PKGBUILD, It works. The pkgbuild script is in the attachment. Kevin, Could you please adopt my adives?

3 3

Re: [arch-general] X fails to start after editing ~/.xinitrc
by Igor Mosyagin 07 Sep '11

07 Sep '11

Hello there. Would your system still fail with empty .xinitrc? (mv ~/.xinitrc ~/dangerous_xinitrc && touch ~/.xinitrc) You don't need ampersand for fonts rehashing. Is that line is only one you have in your .xinitrc? Do you have system xinitrc? (/etc/X11/xinit/xinitrc) Is it empty? Igor Mosyagin cellular: +79265279171 jabber: cramur(a)talk.mipt.ru skype: cr4mur > Date: Wed, 7 Sep 2011 03:54:37 +0000 (UTC) > From: "Juan R. de Silva" <juan.r.d.silva(a)gmail.com> > To: arch-general(a)archlinux.org > Subject: Re: [arch-general] X fails to start after editing ~/.xinitrc > Message-ID: <j46ptt$jt0$1(a)dough.gmane.org> > Content-Type: text/plain; charset=UTF-8 > > On Wed, 07 Sep 2011 04:45:49 +0200, Karol Blazewicz wrote: > >> On Wed, Sep 7, 2011 at 4:16 AM, Juan R. de Silva >> <juan.r.d.silva(a)gmail.com> wrote: >>> 3. In case net-tools package from core does not provide hostname any >>> more as well, what would be a solution then for one that would like to >>> use "terminus" fonts which by default installed into >>> /usr/share/fonts/local? >> >> I've never had any problems with Terminus being added to fontpath in >> .xinitrc but you can use xorg.conf for that too. > > To use xorg.conf I would need first to create one, since my system works > without it so far. Unless I really must to create it I would prefer to > leave things as their are for now. > >> If you have net-tools installed, you shouldn't be getting errors about >> hostname being missing. > > Yes, net-tools is installed. However the error is as I said. > >> hostname will be provided by inetutils, as was explained in the mailing >> list message I linked to. I'm currently running testing and I have no >> problems with X, hostname does its job (whatever that might be ;P), I'm >> using Terminus and have 'xset +fp /usr/share/fonts/local &; in my >> .xinirtc - all seems to work. > > You typed above: 'xset +fp /usr/share/fonts/local &; > > Is it a typo or you meant to say your .xinitrc has line like this? > > 'xset +fp /usr/share/fonts/local &' - with ampersand at the end > > If the last is true then it differs from my entry, which is > > 'xset +fp /usr/share/fonts/local' - without ampersand. > > Does it make sense to add it?.. > > >> When I downgrade to [core] (i.e. I'm not using [testing] anymore), >> things still work, so the current net-tools should be all you need. > > Here a snippet I found in 'man xset': > > [ fp rehash: > > The rehash argument resets the font path to its current value, > causing the server to reread the font databases in the current > font path. This is generally only used when adding new fonts > to a font directory (after running mkfontdir to recreate the > font database). ] > > I actually never run 'mkfontdir' after Terminus fonts were installed > since the Fonts Installation wiki page I referred to mentions that > executing 'mkfontscale' and then 'mkfontdir' is needed only for "older > applications that do not support fontconfig". > > Do you think this might be a problem? > >

4 6

[arch-general] X fails to start after editing ~/.xinitrc
by Juan R. de Silva 07 Sep '11

07 Sep '11

I have a new arch install with basic X environment added and successfully tested. Following instructions here https://wiki.archlinux.org/index.php/Fonts I installed "terminus" fonts, created ~/.xinitrc file and added to it the following lines as advised: xset +fp /usr/share/fonts/local xset fp rehash After this X fails to start with error: "/usr/bin/startx: Line 127: hostname: command not found" When ~/.xinitrc file deleted, X starts as before just fine. Could somebody help me to figure out what am I doing wrong, please?

2 4

[arch-general] packagekit
by Myra Nelson 07 Sep '11

07 Sep '11

I'm running pacman4 rc1 and everything seems to be working fine. My question is, I'm not in a hurry or anything, it's just a question. When will packagekit etc be updated to work with pacman4? As I said, I currently have no problems and simply ignore them on updates. Myra -- Life's fun when your sick and psychotic!

1 0

[arch-general] [anikom15@gmail.com: odd compress command]
by Westley Martínez 06 Sep '11

06 Sep '11

I don't think my previous email went through. I apologize and disregard if it did. Here is the original message: ----- Forwarded message from Westley Martínez <anikom15(a)gmail.com> ----- Date: Sun, 4 Sep 2011 00:44:46 -0700 From: Westley Martínez <anikom15(a)gmail.com> To: arch-general(a)archlinux.org Subject: odd compress command User-Agent: Mutt/1.5.21 (2010-09-15) Hello, on my [Arch] system the compress program is actually a wrapper to gzip. This has caused a test to fail for Python <http://bugs.python.org/issue11340>. The bug is quite old but it is still relevant and I've been working on fixing it. I'd like to ask if anyone knows exactly why Arch's compress program outputs .gz files and not .Z files. I honestly could not find any information concerning its history or its rationale, and I come to this mailing-list as a last resort. Likewise, I think it would be appropriate to adopt the true compress program or not include a compress command at all, because, as you can see, problems have been created. ----- End forwarded message -----

3 4

[arch-general] pacman -Sl
by Joker-jar 05 Sep '11

05 Sep '11

Hello! I just made `pacman -Ql ...` analogue for don't installed packages. Enjoy ;) http://paste.org.ru/?h5cg9y

5 4

Re: [arch-general] [arch-dev-public] [signoff] dnsutils-9.8.1-1
by Thorsten Töpper 05 Sep '11

05 Sep '11

On Sun, 4 Sep 2011 12:52:21 +0300 Evangelos Foutras <evangelos(a)foutrelis.com> wrote: > On Sun, Sep 4, 2011 at 7:55 AM, Gaetan Bisson <bisson(a)archlinux.org> > wrote: > > Hi guys, > > > > A new dnsutils package lies in [testing]... again - an upstream > > update this time. No big changes, mostly bug fixes. For the curious: > > > > https://deepthought.isc.org/article/AA-00446/81/ > > > > Please test and signoff. > > Signoff x86_64. signoff i686 -- Jabber: atsutane(a)freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4

1 0

Re: [arch-general] [arch-dev-public] [signoff] diffutils-3.2-1
by Thorsten Töpper 05 Sep '11

05 Sep '11

On Mon, 05 Sep 2011 13:30:13 +1000 Allan McRae <allan(a)archlinux.org> wrote: > On 03/09/11 20:42, Evangelos Foutras wrote: > > On Sat, Sep 3, 2011 at 2:43 AM, Allan McRae<allan(a)archlinux.org> > > wrote: > >> Upstream update: > >> > >> > >> * Noteworthy changes in release 3.2 (2011-09-02) [stable] > >> > >> ** Changes in behavior > >> > >> --ignore-file-name-case now applies at the top level too. > >> For example, "diff dir inIt" might compare "dir/Init" to "inIt". > >> > >> ** New features > >> > >> diff and sdiff have a new option --ignore-trailing-space (-Z). > >> > >> ** Packaging > >> > >> The texinfo documentation no longer specifies "front-cover" or > >> "back-cover" texts, so that it may now be included in Debian's > >> "main" section. > >> > >> > >> Signoff both, > > > > Signoff x86_64. > > > > Anyone for i686? > > Allan signoff i686 -- Jabber: atsutane(a)freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4

1 0

[arch-general] How big really is the MBR?
by Eric Griffith 03 Sep '11

03 Sep '11

Whats up guys, Was planning on re-install Arch on my laptop, started writing a couple scripts to handle the usual things I do. One of the NEW things im going to be trying is grub2. Now, the Grub2 wiki says to run dd if=/dev/zero of=/dev/sda bs=440 count=1 to wipe out grub-legacy from the MBR. And since the Arch-devs removed "No Bootloader" as an option in the AIF, you can't follow the "during installation" instructions for Grub2. Here's my problem, just by sheer luck was I roaming the web today, and noticed a few other threads (in various forums for various distros / blogs) and they all had a similar command to run if youre grub-legacy was screwed and you needed to write over it. The only issue, and the reason for this email? They had different commands. Not completly different, but different enough that raised an eyebrow. In dd if=/dev/zero of=/dev/sda bs=440 count=1 They had various numbers for bs=, some 440, some 446, some 506, and some 512. Normally I would've just shrugged and followed the wiki, but notice on one said that if you zero out too far, you wipe out hte partition table...which I wouldn't enjoy haha. So can anyone confirm that the command above, from the wiki, is correct? And that it IS 440, and not something different. I'd hate to pick the wrong one and zero out my partition table, or not completly zero out grub-legacy and run into a whole different set of problems. Thanks!

4 3

[arch-general] Unreachable system and general ARP weirdness
by swh 03 Sep '11

03 Sep '11

Beginning a few months ago, two of the systems on my LAN, a desktop and a laptop, have periodically become mutually uncommunicative. I believe it started occurring when I did a massive -Syu on the laptop, installing six months worth of updates for the laptop at once and effectively upgrading 1/2 of the installed packages... but I'm not positive. The issue still occurs regularly with both systems running 3.0.x kernels. The issue typically occurs after the desktop has been up for a few days, but on rare occasion it's present when the desktop boots. When the issue does occur, other systems on the LAN are able to reach both systems as per normal. It's a simple switched network, and both systems have manually-assigned static IPs. I've done a fair bit of testing with tshark and have determined that the issue presents itself as such: The laptop is able to reach the desktop, with ICMP echo requests and nmap scans going through just fine. However, a response is never received by the laptop. When running tshark on the laptop and sending traffic from the desktop, an oddity occurs. Although the laptop's static IP is 192.168.0.3 (and this is explicitly present as an argument to ping, nmap, etc.) the desktop is actually sending out an ARP broadcast, attempting to get the MAC of an IP in the Philippines - far outside the LAN's 192.168.0.0/24 range. What makes this doubly odd is that I've manually added a correct entry into the desktop's ARP cache for the laptop's IP (via arp -s), yet it's apparently ignored and the bogus ARP broadcasts continue. Interestingly, the arping utility is able to broadcast for the correct IP's MAC, and does receive a reply from the laptop - but the issue persists for everything except arping. If I put an unused IP (e.g. 192.168.0.32) along with the laptop's MAC into the desktop's ARP cache and ping that new address, predictably the ICMP echo requests do get to the laptop, but of course aren't acknowledged as the laptop isn't using that IP. Actually moving the laptop to another IP results in the systems being able to reach each other normally, but the bizarre ARP broadcasts persist when attempting to reach the laptop's old IP, 192.168.0.3. A further observation I made (which simply added to the confusion): An Arch VM, running with bridged networking on the desktop, is perfectly capable of reaching the laptop - I can SSH in without issue. Yet nothing (aside from arping) is even able to get a reply from the laptop when run from a shell on the desktop. Because the VM works, I've essentially ruled out any sort of hardware or driver issue. The part where I'm stuck is... what's below the ARP cache? I have no idea why "ping 192.168.0.3" doesn't work when there is an explicitly-placed entry for the IP in the ARP cache, and how an explicitly-specified IP can turn into an ARP broadcast for a completely different IP (in the Philippines, no less) just baffles me. Any help is appreciated.

2 2