- Arch-general - lists.archlinux.org

Re: [arch-general] arch-general Digest, Vol 110, Issue 1
by Mark E. Lee 02 Dec '13

02 Dec '13

-- Mark E. Lee <mark(a)markelee.com> On Sun, 2013-12-01 at 17:14 -0500, arch-general-request(a)archlinux.org wrote: > On 30/11/2013 17:54, Mark E. Lee wrote: > > pool[2129]: segfault at 8 ip 00007fbddb60b1b5 sp 00007fbd87ffec40 > error > > 4 in libglib-2.0.so.0.3800.2[7fbddb5a8000+fe000] > > A one line error log is a bit short don't you think? Why don't you > give > us more context? Have you searched the web? I found at least one old > issue that could give a clue about what's happening. > > You should provide those informations right away. We shouldn't have to > ask for this. > > Tim Salutations, That's the only error I got and it didn't appear upon reboot. It didn't have any discernible effect on the system. I also searched for the issue on the web and didn't find any information (the word "pool" is a very common word). Thanks for the response though. Regards, Mark

1 0

[arch-general] changing default target to multi-user when no X - any benefit?
by David C. Rankin 02 Dec '13

02 Dec '13

Guys, After fresh install and rebuild of an Arch server with systemd, would it make any difference to change the systemd default target to multi-user? There is no X, so I'm not sure what difference, if any, it would make, or if it is simply semantics at that point. Looking, all I have under systemd/system is multi-user.target.wants and getty.target.wants. Does having the systemd default target set to graphical in this case do anything that wouldn't be done if the default were changed to multi-user? Here it just looks like the old case where you have 'id:5:initdefault:' in inittab, but no X, so the system just looks for some gui displaymanager to load, doesn't find it, and drops to console. The wiki [[Systemd#Change_current_target]] discussed changing the default, but does not explain what is being done besides changing a symlink to /etc/systemd/system/default.target. Being new to systemd on Arch, I just want to make sure I am not biting myself by leaving the default as graphical when in fact I'm just booting into multi-user. What say the experts? -- David C. Rankin, J.D.,P.E.

2 2

[arch-general] Sorting by subject makes Evolution crash
by Ralf Mardorf 29 Nov '13

29 Nov '13

Hi :) Evolution crashes if I sort mails by subject. I got the obligatory reply at the Evolution mailing list, that usually other users get, when having an issue with Evolution. "It should be the fault of the distro", in my case Arch Linux. I don't think so, however, can anybody sort mails by subject with an up to date Arch Linux install? Reporting the bug to upstream seems to be useless. Perhaps something is broken for Arch or my Arch install only. Regards, Ralf -------- Forwarded Message -------- From: Ralf Mardorf <ralf.mardorf(a)alice-dsl.net> To: evolution-list(a)gnome.org Subject: Sorting by subject makes Evolution crash - Was: [Evolution] "Reply to Sender" does same thing as "Reply to All" Date: Fri, 29 Nov 2013 16:05:15 +0100 Mailer: Evolution 3.10.2 On Fri, 2013-11-29 at 08:05 -0500, Adam Tauno Williams wrote: > On Fri, 2013-11-29 at 13:37 +0100, Ralf Mardorf wrote: > > On Fri, 2013-11-29 at 13:21 +0100, Andre Klapper wrote: > > > On Fri, 2013-11-29 at 12:46 +0100, Ralf Mardorf wrote: > > > > However, Evolution does change it's behaviour with each upgrade to > > > > current stable versions of it's dependencies from upstream > > > Either stop spreading FUD, or be way more exact. > > The issues do change, > > Of course they change; releases done to include changes. > > > at the moment it's annoying for me that Evolution > > crashes when I try to sort by subject. > > Something in your distributions is *seriously* broken. That is not > Evolution. I have not seen Evolution crash for a very long time; and I > *use* it every single day for 8+ hours. > > > I'm serious and not trolling. What distro does provide a stable > > Evolution? > > openSUSE. At least it is entirely stable for me, on my hardware. > > > It's in the mail header, but FWIW, the version is 3.10.2 on a 64-bit up > > to date Arch Linux, IOW every dependency should be the current stable > > release from upstream. I don't remember when the issue started, but it > > seems to be one of the issues that appeared after upgrading other > > software, IOW seemingly something from the dependency chain. > > Of course, everything of significance is built on a dependency chain. > It is a problem when people believe it is OK to just willy-nilly upgrade > random parts of that chain. That component W is a stable release does > not mean that X, Y, and Z will run using it without issue; X, Y, and Z > may need to be updated to reflect changes in W. Or at least QC needs to > occur. > > Anyway, again, 3.8.x was stable for me, and 3.10.x is stable for me. I > sort, and search, and read, and send... all day long. Neither Arch Linux nor I do willy-nilly upgrade something, but I will forward this to Arch general mailing list. I'm using Linux only for more then 10 years. Suse isn't an option for my needs. Regards, Ralf

4 5

[arch-general] vsftpd build option --- why not support tcp_wrappers?
by Yi Zheng 28 Nov '13

28 Nov '13

Hi, Piotrowski, Do you think it is necessary to add native tcp_wrappers support for VSFTPD? I do not use xinetd, and want restrict FTP accessing by IP. I have checked the current PKGBUILD script, and found currently no tcp_wrappers support available. Do you agree with me ? >From here, https://security.appspot.com/vsftpd/FAQ.txt Q) Help! Does vsftpd support IP-based access control? A1) Yes. vsftpd can integrate with tcp_wrappers (if built with this support). It is enabled with the setting "tcp_wrappers=YES". A2) Yes. vsftpd can be run from xinetd, which supports tcp_wrappers integration.

2 1

[arch-general] dmraid package - continued upstream or to move to mdraid?
by David C. Rankin 26 Nov '13

26 Nov '13

All, tpowa, As of approximately 8-12 months ago, I was under the impression that upstream dmraid would not continue and that dmraid functionality would move into mdraid. (maybe that was just an arch plan?) Early in the discussion on this list it was noted that not all existing dmraid chipset support was included in the mdraid package. <quote> On Tue, Mar 19, 2013 at 2:40 PM, David C. Rankin <drankinatty(a)suddenlinkmail.com> wrote: > Is there planned support for existing nvidia based dmraid arrays in Arch, I can only speak for myself, but to the best of my knowledge no Arch devs use dmraid, and upstream appears to be dead. Based on that I'd say the best choice would be to move away from dmraid if you can. <snip> -t </quote> I am at the point where I need to rebuild an arch server and must decide whether to continue with dmraid or move to mdraid. Looking at the current dmraid package 10/30/13 by tpowa (https://www.archlinux.org/packages/core/i686/dmraid/) dmraid is still in core. The redhat list makes no reference to dmraid not continuing, so I'm a bit confused about the earlier discussion. At this point is there any information to suggest that dmraid will go away? Also, anyone have negative experience with dmraid and grub2 or dmraid and systemd? -- David C. Rankin, J.D.,P.E.

2 2

[arch-general] GDB does not work, sometimes
by Rodrigo Rivas 25 Nov '13

25 Nov '13

Hi! I'm having a very weird problem with gdb. I hadn't used the debugger for some time, so I'm not sure for how long it has been broken... The problem is that the debugged program does not stop in any breakpoing, exception, signal... nothing. Just as if it weren't being debugged. First I thought that it was a problem with GDB and I was ready to submit a bug report, but then... I have gdb-7.6.1-1 and that has been in the repositories for several months. Surely someone noticed if it didn't work at all for so long! So I started investigating, but how to debug a broken debugger? Long story made short: * gdb fails even with the simplest program (`int main() {}`). I even disabled the start-up stcripts with "gdb -n", no difference. * it fails with programs compiled with both gcc and clang. * it does not fail if I debug as root. * it does not fail if I debug in a VT instead of a PTY. So it looks like some kind of permission issues. Maybe something related to the recent SELinux changes? Googling around I've found that setting /proc/sys/kernel/yama/ptrace-scope to 0 solves the issue. But it should not work this way: the idea of this key is that by default only the parent of a process can ptrace/debug it. And certainly, gdb is the parent of the processes it spawns (yes, I've checked it). Moreover, running "ptrace ls" works fine, so why not "gdb ls"? And what's the difference between a VT and a PTY? That I cannot understand. For now I can workaround with the "yama/ptrace-scope", but does anybody know what is happening? Best regards. -- Rodrigo

3 6

[arch-general] virtualbox CPU issue / upstream has fix
by Genes Lists 21 Nov '13

21 Nov '13

I am seeing the same problem as reported (and fixed in 4.3.3 [1] ) of 100% CPU with Virtualbox 4.3.2. Any chance of getting the fix in the arch testing repo? [1] https://www.virtualbox.org/ticket/12300 Thanks gene

2 1

[arch-general] arch rollback machine
by Lieven Moors 21 Nov '13

21 Nov '13

Hi, Does anyone know what is happening with Arch Rollback Machine? The server (arm.konnichi.com) has been unavailable for more than a week now, and I'm depending on it to keep an offline machine up to date... Greetings, lieven

13 19

[arch-general] Anyone has the skill to create a ArchLinux Logo render
by Brock.Zheng 18 Nov '13

18 Nov '13

Hi, I found a beautiful wallpaper in Unbuntu: http://www.linuxeden.com/upimg/allimg/131114/254-1311140Z412.jpg Anyone has the skill & art taste to render the Arch version? any interesting & comments? -- Brock Zheng <goodmenzy(a)gmail.com> 郑祎 Software Enginner

8 14

[arch-general] Initramfs fallback render
by Ismael Bouya 17 Nov '13

17 Nov '13

Hi all, I have always learnt that it was good practice (to use sudo instead of root su and), when we use sudo, to completely disable root login (by disabling his password). However when we need to boot into "fallback mode", initramfs asks for root password! Is there a standard/automated way to ask/permit another user via initramfs in Archlinux? If not, how do you deal with that usually? Thanks in advance for your response! Regards, -- Ismael

7 13