- Arch-general - lists.archlinux.org

Re: [arch-general] help - Was: arch-general Digest, Vol 137, Issue 36
by Ralf Mardorf 26 Mar '16

26 Mar '16

On Sat, 26 Mar 2016 15:21:38 +0100, Emiel W wrote: >Yes, I did need that. Sorry for the spam and thanks for your response. >[snip] You're welcome. I send my reply to the list too, since a subscriber already feared a pet has need [1]. Several replies were send to the list only, so you need to wait for the next digest or visit the archive. Regards, Ralf [1] On Sat, 26 Mar 2016 15:17:45 +0100, a subscriber wrote: >[snip] >Other probable explanations: >[snip] >- "Help, I'm Emiel's cat and did't get fed this morning." >[snip]

1 0

Re: [arch-general] arch-general Digest, Vol 137, Issue 36
by Emiel W 26 Mar '16

26 Mar '16

Help On Mar 26, 2016 13:00, <arch-general-request(a)archlinux.org> wrote: > Send arch-general mailing list submissions to > arch-general(a)archlinux.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.archlinux.org/listinfo/arch-general > or, via email, send a message with subject or body 'help' to > arch-general-request(a)archlinux.org > > You can reach the person managing the list at > arch-general-owner(a)archlinux.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of arch-general digest..." > > > Today's Topics: > > 1. Re: [solved] virt-install conflicting files (Ralf Mardorf) > 2. Re: [pacman-dev] Please make the colourised output exactly > like that of "pacman-color" (Genes Lists) > 3. Re: [pacman-dev] Please make the colourised output exactly > like that of "pacman-color" (Maarten de Vries) > 4. Strange abs behaviour (Christian Rebischke) > 5. Re: Strange abs behaviour (Doug Newgard) > 6. Re: Strange abs behaviour (Levente Polyak) > 7. Re: Strange abs behaviour (Christian Rebischke) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 25 Mar 2016 13:11:00 +0100 > From: Ralf Mardorf <silver.bullet(a)zoho.com> > To: arch-general(a)archlinux.org > Subject: Re: [arch-general] [solved] virt-install conflicting files > Message-ID: <20160325131100.0ffbc9b0@utnubu> > Content-Type: text/plain; charset=US-ASCII > > On Fri, 25 Mar 2016 07:42:48 -0400, Eli Schwartz wrote: > >https://bbs.archlinux.org/viewtopic.php?id=210539 > > Thank you for the clarification Eli :). > > Regards, > Ralf > > > ------------------------------ > > Message: 2 > Date: Fri, 25 Mar 2016 08:32:38 -0400 > From: Genes Lists <lists(a)sapience.com> > To: General Discussion about Arch Linux <arch-general(a)archlinux.org> > Subject: Re: [arch-general] [pacman-dev] Please make the colourised > output exactly like that of "pacman-color" > Message-ID: <69bb0843-ce30-c990-d1d7-844fb0f846a2(a)sapience.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > On 03/24/2016 09:06 PM, Xavion wrote: > > Hi Allan, > > > > I have become old and grumpy since then! > >> > .. > > > Quick comment on color - it might be helpful to have a toggle to switch > from dark to light terminals. ls uses an environment variable to permit > changing the color map - that may be overkill - but a toggle for light > vs dark background might be nice. > > gene > > > ------------------------------ > > Message: 3 > Date: Fri, 25 Mar 2016 16:42:20 +0100 > From: Maarten de Vries <maarten(a)de-vri.es> > To: General Discussion about Arch Linux <arch-general(a)archlinux.org> > Subject: Re: [arch-general] [pacman-dev] Please make the colourised > output exactly like that of "pacman-color" > Message-ID: > < > CAPWpf%2BxYB2q4xCDb-uNqh1sqrFYZ1Caqqu393irzwNpjGpkDTA(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 25 March 2016 at 13:32, Genes Lists <lists(a)sapience.com> wrote: > > > On 03/24/2016 09:06 PM, Xavion wrote: > > > >> Hi Allan, > >> > >> I have become old and grumpy since then! > >> > >>> > >>> .. > > > > > > Quick comment on color - it might be helpful to have a toggle to switch > > from dark to light terminals. ls uses an environment variable to permit > > changing the color map - that may be overkill - but a toggle for light vs > > dark background might be nice. > > > > gene > > > > ?Shouldn't a terminal configuration use colors that are always readable on > the default background color anyway? Then, assuming that you're not > overwriting the background color, the only two colors you should avoid are > black and white. All the other colors should be fine. Instead of setting > the foreground color to black/white you should just use the default > foreground color, possibly bold. I assume this is already the case for > pacman. > > -- Maarten? > > > ------------------------------ > > Message: 4 > Date: Fri, 25 Mar 2016 18:17:17 +0100 > From: Christian Rebischke <Chris.Rebischke(a)archlinux.org> > To: arch-general(a)archlinux.org > Subject: [arch-general] Strange abs behaviour > Message-ID: <20160325171717.GA8917@motoko> > Content-Type: text/plain; charset="us-ascii" > > Hello, > I have strange abs behaviour maybe you have an idea for this issue: > > https://paste.archlinux.de/cJN/ > > I can catch every package via abs except virt-install. Do you have any idea > why? > > greetings > > chris >

5 4

[arch-general] Strange abs behaviour
by Christian Rebischke 25 Mar '16

25 Mar '16

Hello, I have strange abs behaviour maybe you have an idea for this issue: https://paste.archlinux.de/cJN/ I can catch every package via abs except virt-install. Do you have any idea why? greetings chris

3 3

Re: [arch-general] [pacman-dev] Please make the colourised output exactly like that of "pacman-color"
by Genes Lists 25 Mar '16

25 Mar '16

On 03/24/2016 09:06 PM, Xavion wrote: > Hi Allan, > > I have become old and grumpy since then! >> .. Quick comment on color - it might be helpful to have a toggle to switch from dark to light terminals. ls uses an environment variable to permit changing the color map - that may be overkill - but a toggle for light vs dark background might be nice. gene

2 1

[arch-general] virt-install conflicting files
by Ralf Mardorf 25 Mar '16

25 Mar '16

Updating from virt-install 1.3.2-3 to 1.3.2-4 didn't work. Several files owned by no package cause a conflict. Since I never build anything virt related myself and Arch always was up-to-date, there must have been an issue with an update, that didn't removed those files. Who might be the culprit, pacman? Or virt-install from community? I didn't report a bug, since assumed the culprit is virt-install, than likely an old package version and maybe the culprit is something else. The issue is solved, but I still don't know the cause for the issue: $ pacman -Qo /usr/share/virt-manager/virtcli/__init__.pyc error: No package owns /usr/share/virt-manager/virtcli/__init__.pyc $ ls -l /usr/share/virt-manager/virtcli/__init__.pyc -rw-r--r-- 1 root root 189 Oct 5 16:50 /usr/share/virt-manager/virtcli/__init__.pyc $ sudo pacman -S virt-install virt-manager [snip] Packages (2) virt-install-1.3.2-4 virt-manager-1.3.2-4 [snip] error: failed to commit transaction (conflicting files) virt-install: /usr/share/virt-manager/virtcli/__init__.pyc exists in filesystem [snip] Errors occurred, no packages were upgraded. $ sudo pacman -Q virt-install virt-manager virt-install 1.3.2-3 virt-manager 1.3.2-3 $ sudo rm -r /usr/share/virt-manager/ $ sudo pacman -S virt-install virt-manager [snip] warning: could not get file information for usr/share/virt-manager/ [snip] $ sudo pacman -S virt-install virt-manager warning: virt-install-1.3.2-4 is up to date -- reinstalling warning: virt-manager-1.3.2-4 is up to date -- reinstalling [snip] Packages (2) virt-install-1.3.2-4 virt-manager-1.3.2-4 [snip, no warning, no error] Regards, Ralf

2 2

[arch-general] Fwd: Welcome to the "arch-general" mailing list
by Anna Ivanova 25 Mar '16

25 Mar '16

---------- Forwarded message ---------- From: <arch-general-request(a)archlinux.org> Date: Fri, Mar 25, 2016 at 7:44 AM Subject: Welcome to the "arch-general" mailing list To: kalterfx(a)gmail.com Welcome to the arch-general(a)archlinux.org mailing list! To post to this list, send your message to: arch-general(a)archlinux.org General information about the mailing list is at: https://lists.archlinux.org/listinfo/arch-general If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: https://lists.archlinux.org/options/arch-general/kalterfx%40gmail.com You can also make such adjustments via email by sending a message to: arch-general-request(a)archlinux.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe without confirmation. It is: 12481632F! Normally, Mailman will remind you of your archlinux.org mailing list passwords once every month, although you can disable this if you prefer. This reminder will also include instructions on how to unsubscribe or change your account options. There is also a button on your options page that will email your current password to you. -- kalterfive

2 1

[arch-general] What is the current wiki-poliicy for re-writing contributions?
by David C. Rankin 25 Mar '16

25 Mar '16

Archdevs, What is the current policy for having wiki-contributions re-written? I have been a wiki-contributor for years, I've more than 28 years Unix/Linux experience, I am an attorney, a registered professional engineer, and I have spent years doing technical writing for NASA MOD and Space Flight Operations -- I know technical writing. Over the past year or so it seems like every wiki contribution made is re-written to the point that the immediacy of the needed information is lost, is replaced by a link, or the contribution is reworded in a bewildering manner. Under what criteria does this take place? It has gotten to the point where you just get tired of helping -- why bother? Under the current system, the pages are slowly becoming less-useful rather than more useful as more and more information is chopped out of pages or replaced by links to 3rd-party pages that may (or may not) be there tomorrow. When I first began using Arch in '09, the pages were written such that you could fully-complete whatever task the page addressed without bouncing around from page-to-page hunting for all the pieces of the puzzle. That is no longer the case. Don't get me wrong, the Arch-wiki pages are still by far the most useful of any distribution, but understanding the criteria under which this is taking place will help those willing to contribute determine whether to make a contribution or not. The goal being to keep the Arch-wiki, the very best that it can be. Thanks. -- David C. Rankin, J.D.,P.E.

13 12

[arch-general] startx on arch vm running on ESXI (when accessed via ssh - do I need a DM?)
by David C. Rankin 23 Mar '16

23 Mar '16

All, When I ended up with a hand-me-down supermicro server from a local ISP, I decided to try virtualizing all my hosts. The company I got this from recommended vmware ESXI as the hypervisor. It was a pleasant surprise to find that ESXI is a basic Linux system. (albeit a very limited and quirky setup). I've installed Arch as the first vm, assigning 8-cores and 16G of RAM. It is up and running fine. (it is installed on a raid1 array volume from a LSI controller which exists as a single datastore in esxi -- if that makes any difference) I am trying to setup fluxbox on arch so I can access the vm via rdesktop (or something similar) via a GUI on a as needed basis. I would rather not have a display manager running all the time, so I'm attempting to use the startx route. I've used the following to try and get this going: https://wiki.archlinux.org/index.php/Fluxbox https://wiki.archlinux.org/index.php/Xinitrc https://wiki.archlinux.org/index.php/xorg https://wiki.archlinux.org/index.php/Display_manager The configuration is good, but I'm stuck attempting to start X. X is refusing to start due to the fact I'm accessing Arch by ssh. When I try to start x, I receive the following error telling me that "Only console users are allowed": $ startx /usr/lib/xorg-server/Xorg.wrap: Only console users are allowed to run the X server xinit: giving up xinit: unable to connect to X server: Connection refused xinit: server error Couldn't get a file descriptor referring to the console I understand that it wants X only to be started from the actual physical console, but when I access the vm over ssh, I don't have one. (I am starting the vm, ssh'ed into esxi with 'vim-cmd vmsvc/power.on 1', so there is no console anywhere else) What would be the best solution? Have arch boot to the graphical target loading a display manager? ... or is there some way I can simply startx as needed so I don't leave the dm running all the time on the vm? Thanks for any help you can provide. -- David C. Rankin, J.D.,P.E.

6 6

[arch-general] Adding new disks > 2T to system that boots with grub, can GPT be used for new disks?
by David C. Rankin 21 Mar '16

21 Mar '16

All, I'm confused by the partitioning wiki (https://wiki.archlinux.org/index.php/Partitioning) It says: If using GRUB legacy as the bootloader, one must use MBR What about adding disks to this system? Must they be partitioned MBR or can I use GPT on the additional disks. (I haven't used GPT before, so this has me stumped). Current setup is Arch booting from grub (grub2) on 1T raid1 mdadm array. I have a pair of 3T drives I want to add to the system. (as a 3T raid1 mdadm array). I want to use the entire disk in a single partition which is why I want to partition the disks GPT (leaving 100M unpartitioned at the end). Can I use GPT on the new disks, or am I stuck with MBR? -- David C. Rankin, J.D.,P.E.

3 4

[arch-general] Why does newly created raid1 array not have /dev/disk/by-uuid entry?
by David C. Rankin 21 Mar '16

21 Mar '16

All, I created GPT partitions on a pair of new 3T drives configured in raid1 as md4 on my system, e.g.: # cat /proc/mdstat Personalities : [raid1] md4 : active raid1 sdd[1] sdc[0] 2930135488 blocks super 1.2 [2/2] [UU] [=>...................] resync = 5.3% (157758400/2930135488) finish=235.0min speed=196538K/sec bitmap: 21/22 pages [84KB], 65536KB chunk md0 : active raid1 sdb5[1] sda5[0] 511680 blocks super 1.2 [2/2] [UU] md2 : active raid1 sda7[0] sdb7[1] 921030656 blocks super 1.2 [2/2] [UU] bitmap: 0/7 pages [0KB], 65536KB chunk md1 : active raid1 sdb6[1] sda6[0] 52396032 blocks super 1.2 [2/2] [UU] md3 : active raid1 sda8[0] sdb8[1] 2115584 blocks super 1.2 [2/2] [UU] unused devices: <none> Then 'mdadm --detail --scan' finds the UUID for the array, e.g.: # mdadm --detail --scan ARRAY /dev/md3 metadata=1.2 name=archiso:3 UUID=8b37af66:b34403aa:fa4ce6f1:5eb4b7c8 ARRAY /dev/md1 metadata=1.2 name=archiso:1 UUID=62b42a42:c8b4eed1:295864d2:f815b367 ARRAY /dev/md2 metadata=1.2 name=archiso:2 UUID=73a0a0b5:fa3629e1:7c1a7c87:23044fc8 ARRAY /dev/md0 metadata=1.2 name=archiso:0 UUID=04940526:cfa6af2b:72c234e2:a987a858 ARRAY /dev/md4 metadata=1.2 name=valkyrie:4 UUID=6e520607:f152d8b9:dd2a3bec:5f9dc875 I updated /etc/mdadm.conf with that information and was then going to do the same for /etc/fstab. Before doing so, I thought I would confirm the UUID in /dev/disk/by-uuid, # l /dev/disk/by-uuid/ lrwxrwxrwx 1 root root 9 Mar 19 16:41 3c0d11b5-c637-4def-a6e0-f48a4a17e71a -> ../../md0 lrwxrwxrwx 1 root root 9 Mar 19 16:41 402a70c8-b51b-41a0-aa88-3aa37c8dd6fd -> ../../md2 lrwxrwxrwx 1 root root 9 Mar 19 16:41 515ef9dc-769f-4548-9a08-3a92fa83d86b -> ../../md1 lrwxrwxrwx 1 root root 9 Mar 19 16:41 8920ca3f-f253-4011-9c9e-a6be513527e0 -> ../../md3 Huh? No UUID for /dev/md4? Does it just not show up until the next boot? What gives? -- David C. Rankin, J.D.,P.E.

1 1