September 2011 - Arch-general - lists.archlinux.org

[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

[arch-general] Error updating related to pygobject, pygobject-devel, Python, and Python2
by Myra Nelson 03 Sep '11

03 Sep '11

It would seem I have something misconfigured on my machine. I haven't noticed anything on the mailing list or on the Arch news about this, checked the bug tracker and followed the links to the Python mailing list, and I'm still a little confused. Below is an example of what I get back from pacman -Sy and pacman -Su, the rest is in a pastebin at http://pastebin.com/3dBxsGvE. myra@gandalf ../repos/extra-x86_64]:pacsu (equivalent to pacman -Su) :: Starting full system upgrade... warning: pacman: local (4.0.0rc1-1) is newer than core (3.5.4-4) :: Replace pygobject with extra/python2-gobject2? [Y/n] y :: Replace pygobject with extra/python2-gtkhtml2? [Y/n] y :: Replace pygobject with extra/python2-gtkspell? [Y/n] y :: Replace pygobject with extra/python2-httplib2? [Y/n] y :: Replace pygobject with extra/python2-libgnome? [Y/n] y :: Replace pygobject with extra/python2-nose? [Y/n] y :: Replace pygobject with extra/python2-numpy? [Y/n] y :: Replace pygobject with extra/python2-pip? [Y/n] y :: Replace pygobject with extra/python2-pyopenssl? [Y/n] y :: Replace pygobject with extra/python2-pyqt? [Y/n] y --- adnauseum resolving dependencies... looking for inter-conflicts... error: unresolvable package conflicts detected error: failed to prepare transaction (conflicting dependencies) :: python2-nose and python-nose are in conflict The adnauseum got 1455 line of repetition through pygobject and pygobject-devel. Based on the Python mailing list referenced in FS25747 on the bug tracker, I'm not sure what to do next. You'll notice in the pastebin I stopped hitting the Y and just pressed enter (yes I really did that). No problems prior to today, but it seems as though I've borked something up. Any suggestions would be appreciated. Myra -- Life's fun when your sick and psychotic!

2 2

[arch-general] Down doesn't stick
by Jorge Almeida 02 Sep '11

02 Sep '11

Two days ago I did a one week -due general upgrading. After rebooting, the "Down" key changed its usual behavior: keeping the key pressed should keep producing Down events (I use it sometimes to scroll a google page without the mouse, or to move down across a text editing page). Now, it only sends one event. If I want to scroll down two lines I have to press twice. The Up key still has the usual behavior. I checked with xev that events are not being sent (i.e., they are not just being ignored). I suspected a keyboard hw probem, and so I used xmodmap to map another key (AltGr, right next to the space bar) to be another Down. It worked well yesterday, but today, after booting, new and old key have both the same strange behavior. I have no idea what package may be causing this... Jorge Almeida

5 11

[arch-general] [signoff] linux-3.0.4-1
by Tobias Powalowski 02 Sep '11

02 Sep '11

Latest kernel is in testing, please signoff for both arches greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa(a)archlinux.org

4 5

[arch-general] emacs-color-theme: please use a snapshot
by XeCycle 02 Sep '11

02 Sep '11

Hope I'm not disturbing~ But I don't know whether this worth a bug report. The package `emacs-color-theme' uses the stable release, released in 2006. In 2007, there's a commit fixing a bug (for me, the bug causes conflict with Gnus), but the upstream didn't release a new version since then. So I would suggest on using a snapshot version --- I fixed that bug myself. Following is more about that bug and how I fixed it: Function `replace-in-string' is provided in XEmacs but not GNU Emacs, so the author of color-theme defined his own. Yes, he checks whether the function exists. Gnus also defined one, but the name is `mm-replace-in-string'. Gnus checks whether `replace-in-string' is present, and if it does, the `mm-' is just an alias to that. All right, Eh? But the author of color-theme defined the function different from XEmacs did. So Gnus was confused, then it complained about something like "wrong number of arguments" when using it --- for example, when EasyPG is trying to verify a PGP/MIME signature. I fixed that by renaming the defun in color-theme.el to `color-theme-replace-in-string', by adding a sed line in the build() function before the compilation. -- Carl Lei (XeCycle) Department of Physics, Shanghai Jiao Tong University OpenPGP public key: 7795E591 Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591

3 2