- Arch-general - lists.archlinux.org

[arch-general] Arch pkg user and group IDs?
by Hauke Fath 28 Nov '16

28 Nov '16

Hi, what are Arch's conventions for the numeric ranges of system (package) user and grop IDs? And can the range be limited? I am working up to switching a few dozen Debian clients to Arch. They have user homes on NFS, and authenticate through NIS. So far, nis distributes user and group IDs > 500, making anything lower a local / system ID. After installing Arch, I see % awk -F: '{ if ( $3 > 500 ) print }' < /etc/passwd systemd-journal-remote:x:999:999:systemd Journal Remote:/:/sbin/nologin systemd-journal-upload:x:998:998:systemd Journal Upload:/:/sbin/nologin systemd-coredump:x:997:997:systemd Core Dumper:/:/sbin/nologin % awk -F: '{ if ( $3 > 500 ) print }' < /etc/group systemd-journal-remote:x:999: systemd-journal-upload:x:998: systemd-coredump:x:997: lightdm:x:620: % which collide with NIS users.[1] My question: Do Arch packages come with hardcoded numerical user/group IDs? If not, is there a way to limit the numeric range of system IDs? I guess I would still have to reinstall the distribution. The alternative - a flag day to change NIS user and group IDs as well as on 4 TB file storage and local storage on 50 client machines - wouldn't be pretty. And I don't really have the time, either. Cheerio, hauke [1] lightdm appears to be a pathological case: It hardcodes both name and ID of its user and group, and installation plows on witjout flagging an error even after failing to register the user ID. -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344

4 17

Re: [arch-general] unreadable characters login screen after install
by niya levi 28 Nov '16

28 Nov '16

> hi everyone > after an install following the wiki installation guide and rebooting > the login screen shows unreadable characters, > the char displays as rectangular and square blocks, > locale.conf is set to LANG=en_GB.UTF-8 > vconsole.conf is set to KEYMAP=uk > i also tried adding a FONT= line to vconsole.conf while chrooted the but > no joy after rebooting, > the installation screen was fine. > any ideas ? > ---- On Sat, 26 Nov 2016 17:08:06 +0100 Ralf Mardorf<silver.bullet at zoho.com > <https://lists.archlinux.org/listinfo/arch-general>> wrote ---- > > Which login screen? > > > > A display manager's greeter? If so, xorg.conf or display manager settings might solve the issue. > > Oops, I was confusing keyboard with fonts. Not xorg.conf, but much likely the display manager configuration provides to chose a font. > > > > > Or tty? > > sorry i mean the login at the console, it a file server without xorg, display manger etc. shadrock

3 3

Re: [arch-general] [arch-dev-public] Moving arduino into [community] important notes
by Oon-Ee Ng 28 Nov '16

28 Nov '16

On Mon, Nov 28, 2016 at 3:26 PM, Antonio Rojas <arojas(a)archlinux.org> wrote: > > I thought AUR packages were unsupported. Sure, it is nice to give them a > higher version number when they are moved to the official repos to allow > for a smooth upgrade, but that shouldn't be an enforced rule IMO. And > removing epoch is a reasonable enough reason not to do it. There's a difference between unsupported and (un?)intentionally leaving all users' packages frozen at an old (eventually broken) version because epoch was removed, for some indeterminate period of time. Of course, the question about whether epoch should have been used in the AUR is a separate one (I think it's done mainly to help AUR helpers work). But once that's been done I don't see any good reason to remove it.

1 0

Re: [arch-general] unreadable characters login screen after install
by niya levi 28 Nov '16

28 Nov '16

> On Sun, Nov 27, 2016 at 10:36:10AM +0000, niya levi via arch-general wrote: > >/> hi everyone />/> after an install following the wiki installation guide and rebooting />/> the login screen shows unreadable characters, />/> the char displays as rectangular and square blocks, />/> locale.conf is set to LANG=en_GB.UTF-8 />/> vconsole.conf is set to KEYMAP=uk />/> i also tried adding a FONT= line to vconsole.conf while chrooted the > but />/> no joy after rebooting, />/> the installation screen was fine. />/> any ideas ? />//>/> ---- On Sat, 26 Nov 2016 17:08:06 +0100 Ralf Mardorf<silver.bullet > at zoho.com />/> <https://lists.archlinux.org/listinfo/arch-general>> wrote ---- />/> > Which login screen? />/> > />/> > A display manager's greeter? If so, xorg.conf or display manager > settings might solve the issue. />/> />/> Oops, I was confusing keyboard with fonts. Not xorg.conf, but much > likely the display manager configuration provides to chose a font. />/> />/> > />/> > Or tty? />/> > />/sorry i mean the login at the console, />//>/it a file server without xorg, display manger etc. />//>/shadrock / > Did you customize /etc/locale.gen and ran locale-gen? > > Cheers, > -- > Leonid Isaev yes in locale.gen i uncommented the following and ran locale-gen en_US.UTF-8 en_GB.UTF-8 locale.conf has lang=en_GB.UTF-8 vconsole.conf has KEYMAP=uk when booting it gets past the grub stage it print booting linux then loading ramdisk then the whatever follows displays unreadable block character. shadrock

2 1

[arch-general] unreadable characters login screen after install
by niya levi 26 Nov '16

26 Nov '16

hi everyone after an install following the wiki installation guide and rebooting the login screen shows unreadable characters, the char displays as rectangular and square blocks, locale.conf is set to LANG=en_GB.UTF-8 vconsole.conf is set to KEYMAP=uk i also tried adding a FONT= line to vconsole.conf while chrooted the but no joy after rebooting, the installation screen was fine. any ideas ?

3 2

[arch-general] valgrind - memory exclusion files on the fritz?
by David C. Rankin 25 Nov '16

25 Nov '16

All, valgrind is reporting an additional allocation and free along with and additional 1M of memory used. Below, 11 bytes should be allocated and freed. Instead valgrind reports 1035 bytes. (it's worse if you use strdup). For example: #include <stdio.h> #include <stdlib.h> #include <string.h> enum { MAXC = 16 }; int main (void) { char buf[] = "0123456789"; size_t len = strlen (buf); char *s = NULL; s = malloc (len + 1); snprintf (s, len + 1, "%s", buf); printf (" s : %s\n", s); free (s); return 0; } The report from valgrind: valgrind ./bin/valgrindchk ==3917== Memcheck, a memory error detector ==3917== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==3917== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info ==3917== Command: ./bin/valgrindchk ==3917== s : 0123456789 ==3917== ==3917== HEAP SUMMARY: ==3917== in use at exit: 0 bytes in 0 blocks ==3917== total heap usage: 2 allocs, 2 frees, 1,035 bytes allocated ==3917== ==3917== All heap blocks were freed -- no leaks are possible ==3917== ==3917== For counts of detected and suppressed errors, rerun with: -v ==3917== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) Anybody else experience this problem? Anybody got a fix? I don't find anything valgrind related with a cursory search, did a patch get missed with the latest build? -- David C. Rankin, J.D.,P.E.

2 6

[arch-general] Permanent job in Tokyo, Japan
by James Tobin 24 Nov '16

24 Nov '16

Hello, I’m working with an employer that is looking to hire someone to fulfil a permanent DevOps-type position at their office in Tokyo. Japanese language is not required; only English. Consequently I had hoped that some members of this mailing list may like to discuss further; off-list. I can be reached using "JamesBTobin (at) Gmail (dot) Com". Kind regards, James

1 0

[arch-general] snapcraft.io IMO gets across the message that snaps are appropriate for Arch Linux
by Ralf Mardorf 24 Nov '16

24 Nov '16

Hi, after taking a brief look into building a yaml and following Ubuntu's Snapcraft mailing list, I don't have a good opinion of it. It at least is nothing I would recommend for usage with Arch Linux on i686 and x86_64 servers and desktop computers, not only because it requires an Ubuntu kernel patch [1], but because it IMO is completely against the rolling release approach and beyond that IMO broken in many ways. The first sentence on http://snapcraft.io/ is "Package any app for every Linux desktop, server, cloud or device, and deliver updates directly" and the first logo beside the Ubuntu logo is Arch Linux. My opinion is, that it would be better, if the Arch Linux logo would be removed from http://snapcraft.io/ , because I guess it gets across a wrong message. Regards, Ralf [1] https://wiki.archlinux.org/index.php/Snapd#Installation Disclaimer I only want to inform about it, in case Arch Linux developers aren't aware of it. I will not argue against, if Arch developers don't care and/or disagree with my opinion. IOW I will not discuss it, the intention is only to inform of it. ;) -- Death of ROXTerm https://sourceforge.net/p/roxterm/discussion/422638/thread/60da6975/

7 19

[arch-general] Nvidia backlight control - acpi_video0/brightness changes - display doesn't?
by David C. Rankin 20 Nov '16

20 Nov '16

All, Laptop: HP 8760w, Quadro 3000M, nvidia-340xx packages. The driver works perfectly (no errors in Xorg.0.log), but I have no way to control the screen brightness. I've followed the suggestions in: https://wiki.archlinux.org/index.php/NVIDIA/Tips_and_tricks but I still have no backlight control. Using the laptop function keys, the values in /sys/class/backlight/acpi_video0/brightness are properly set, e.g. $ cat /sys/class/backlight/acpi_video0/brightness 8 (now tap the [func][F9], brightness lower, twice) $ cat /sys/class/backlight/acpi_video0/brightness 6 (actual_brightness value tracks brightness) $ cat /sys/class/backlight/acpi_video0/max_brightness 20 This works with OR without /etc/X11/xorg.conf.d/20-nvidia.conf: Option "RegistryDwords" "EnableBrightnessControl=1" Does anyone have any suggestions on anything else to try before I start loading the aur nvidia-bl or nvidiabl packages? I don't mind adding more software, but if there are a few more tweaks to try before going that route, I would like to try them first. Anybody get backlight working with a similar model laptop? -- David C. Rankin, J.D.,P.E.

5 14

[arch-general] Does LTS package really not fit to Rolling Release model and Arch Philosophy?
by Ken OKABE 19 Nov '16

19 Nov '16

Arch-wiki suggests: https://wiki.archlinux.org/index.php/System_maintenance#Install_the_linux-l… >Tips and tricks The following tips are generally not required, but certain users may find them useful. >Install the linux-lts package The linux-lts package is an alternative Arch kernel package, and is available in the core repository. This particular kernel version has long-term support (LTS) from upstream, including security fixes and some feature backports. It is useful if you prefer the stability of less-frequent kernel updates or if you want a fallback kernel in case a new kernel version causes problems. and some guy told me >The LTS kernel is strictly speaking not in line with the "Arch philosophy" (if you use that term to describe the rolling release nature of Arch) - but it is also not a "typical" piece of software, for two reasons: >It is the kernel, i.e. the core building block of what makes this operating system work. It is crucial to make sure it works correctly, so in case of an issue, having the possibility to go back to an LTS release (or forward to a non-LTS release) is in the interest of many users. >It is mostly not affected by dependency issues arising from version mismatches (like soname bumps) - you can plug in any kernel you want without any major issues (except maybe hardware support). >The second point also allows it to be packed in a rolling release distribution like Arch without causing trouble for maintainers. Maintaining an old user-space tool (i.e. backporting fixes, ensuring library version compatibility, ... well, see Debian) is incompatible with Arch Linux. How hard or problematic to maintain a LTS package, for instance, KDE Plasma LTS edition package on Arch rolling-release-model? https://www.kde.org/announcements/plasma-5.8.0.php >Tuesday, 4 October 2016. Today KDE releases its first Long Term Support edition of its flagship desktop software, Plasma. This marks the point where the developers and designers are happy to recommend Plasma for the widest possible audience be they enterprise or non-techy home users. What kind of scenario in the real world to be problematic to maintain KDE Plasma LTS line as separated packages from non-LTS?

7 10