- Arch-general - lists.archlinux.org

[arch-general] Packaging: difference between "example documentation config" and "default config"
by Jakub Klinkovský 28 May '14

28 May '14

Hi all, there are two kinds of config files shipped with Arch packages: 1) "example documentation config" - by this I mean sample config files, intended for documentation purposes 2) "default config" - by this I mean configs containing sensible default values uncommented to provide basic functionality ootb One of the recognition signs is that in Arch, 2) configs are usually very short. Some examples of proper "default configs": /etc/ntp.conf /etc/pacman.conf and of "example documentation configs": /etc/dnsmasq.conf /etc/wpa_supplicant/wpa_supplicant.conf /etc/hostapd/* /usr/share/doc/lighttpd/config/* Now the problem is: should "example documentation configs" be installed in /etc/ or /usr/share/doc/<package>/ ? I'd vote for the latter, here is the reasoning: 1) Users will hardly overwrite files in /usr/share/doc/ so keeping "example documentation configs" there will ease maintenance of short and much clearer separate config files. 2) In the examples above, in all dnsmasq, wpa_supplicant and hostapd, the decision to keep the configs under /etc/ is made in PKGBUILD [1], [2], [3]. In case of wpa_supplicant, wpa_supplicant.conf(5) even indicates that the path to example config is "probably" /usr/share/doc/wpa_supplicant/. 3) Keeping "example documentation configs" with uncommented options under /etc/ might lead to unintended behaviour, meaning the default options might not be very sane. Specifically, /etc/wpa_supplicant/wpa_supplicant.conf has multiple network blocks uncommented, which, in conjunction with the recently introduced dhcpcd hook [4], may lead to wpa_supplicant being started without user's intervention and not failing due to the network blocks uncommented in wpa_supplicant.conf. 4) Considering the user-centric clause in the Arch Way [5], I don't think any default config file for the three packages is necessary as anybody using it will have to modify it. Creating the file instead of modifying some bloated sample should be easier, see point 1). Before I submit bug reports for the three packages (dnsmasq, wpa_supplicant, hostapd), I'd like to hear some more opinions about this. Thanks, -- jlk [1]: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=… [2]: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=… [3]: https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h… [4]: https://wiki.archlinux.org/index.php/Dhcpcd#10-wpa_supplicant [5]: https://wiki.archlinux.org/index.php/The_Arch_Way#User-centric

2 1

[arch-general] QEMU bug report
by Steven Honeyman 27 May '14

27 May '14

Sorry if this sounds a little rude, but could someone please actually read this bug report before it just gets closed? https://bugs.archlinux.org/task/40571 (it has already been flagged for closure - wrongly or without good reason) Thanks, Steven.

2 1

[arch-general] XULrunner optional dependencies
by Joren Van Onder 27 May '14

27 May '14

It might be a good idea to add the gstreamer0-* optional dependencies of Firefox as optional dependencies to XULrunner too. As it stands, a user who installs something like conkeror-git from the AUR never gets informed that HTML5 video/audio playback can be improved by installing these packages. -- Joren

1 0

[arch-general] systemd-run --user does not work
by Rodrigo Rivas 26 May '14

26 May '14

Hello, list! This is an issue that has been nagging me for a while, and I thought that it was something I did to my machine, until I tested it in another Arch installation, and it is all the same. The problem is when I run for example: $ systemd-run --user /usr/bin/ls Failed to create bus connection: No such file or directory I would expect it to run the command and save the output in the journal, just as the --system counterpart does. You could think that the systemd user daemon is not running properly, but: $ systemctl --user works perfectly. Moreover, if I create a user unit as ~/.config/systemd/user/test.service and start it with `systemctl --user start test` it works, too. I know that systemd user sessions are still a bit of experimental, but I don't see any reason why systemctl works and systemd-run does not. Is this a bug? Or am I missing something? -- Rodrigo

4 9

[arch-general] Setting dirty ratio
by Amal Roy 26 May '14

26 May '14

What is the recommended way to set dirty ratio and dirty background ratio on boot? I added those in /etc/sysctl.d/99-sysctl.conf fileand then added a systemd service to fork a process "sysctl --system" on startup and it didn't seem to work. The command "sysctl --system" run as root is successful in setting the custom options set in /etc/sysctl.d/99-sysctl.conf.

2 2

[arch-general] GNU IceCat should be in the official repos
by Richter Vania 25 May '14

25 May '14

With Mozilla Firefox implementing DRM in their source code, I think more users - even those who aren't strictly Free Software people - will move to GNU IceCat. I know that most IceCat users compile it themselves but I compiling it takes a lot of time and a binary package would help those people who don't want to use Mozilla Firefox but still want to keep their browser up-to-date. I know that Arch isn't particularly aligned politically but I see this matter as practical, many people are going to switch to GNU IceCat if the DRM is implemented.

7 6

Re: [arch-general] [arch-dev-public] [Draft] MariaDB 10.0 enters [extra]
by Genes Lists 24 May '14

24 May '14

On 05/17/2014 08:40 AM, Bartłomiej Piotrowski wrote: > Hi guys, > > New MariaDB is sitting in [testing] for a while now. It's temporarily This does trigger this warning in postfix's postmap program: postmap: /usr/lib/libmysqlclient.so.18: no version information available (required by postmap) Do you know if there is something I need to do on my end to make this go away? So far that's the only thing I've noticed in testing it. thanks. gene

1 1

[arch-general] [Proposal] add python 3 support for gvim in [extra]
by Thomas Dziedzic 22 May '14

22 May '14

Hey all, I would like to add progress to the bug "FS#34397 - [gvim] has --disable-python3interp" [0]. I feel like it's about time to start looking into supporting python 3 in gvim. After some research, it looks like it would be problematic to support both python versions compiled into the same vim version. That said, python2 seems to still be the primary target of most vim plugins. Though a lot of these plugins also support python 3 at the same time. Currently there is no obvious "right" answer to which python version we should support since python2 obviously has the most support, but on the other hand, we should support the latest version of python since that is where the future lies. This proposal is to keep the existing vim/gvim packages in [extra], but add a 3rd split version called gvim-python3 or just gvim-python which would provide the exact same features as gvim except with python 3 support instead of python 2. This would allow the community to start experimenting with python 3 support and start reporting any issues to upstream vim plugins. While allowing users that don't really want to live on the edge to still use gvim as they previously had been using it. Eventually I would like to replace gvim with the python 3 version and provide a gvim-python2 version so that the default becomes python 3 but we would still provide a python 2 version for people that still need it. After some more time, I would like to eventually drop gvim-python2 to the aur and only support the python 3 version. I still don't know when these switches will happen, but for now, I would like to take the first step. It also seems that there is a python 3 version of gvim available in the aur [1]. Hopefully this would allow more people to experiment with python 3 support by removing the need to compile it and have it in supported repos. What do yall think? [0] - https://bugs.archlinux.org/task/34397 [1] - https://aur.archlinux.org/packages/gvim-python/

6 5

[arch-general] Cantata gives error after Qt-5.3 upgrade
by Savyasachee Jha 21 May '14

21 May '14

After updating to qt 5.3 in [testing], I found that cantata does not start up. Upon running from the terminal, I get the error: $ cantata This application failed to start because it could not find or load the Qt platform plugin "xcb". Available platform plugins are: eglfs, kms, linuxfb, minimal, minimalegl, offscreen, xcb. Reinstalling the application may fix this problem. However, reinstalling did not fix the problem. Downgrading qt to the version 5.2.1 in [extra] did. I believe that recompiling "cantata" with qt 5.3 might be required? Thanks! -- Savyasachee Jha *"Aerodynamics is for people whodon't know how to build engines."*

4 9

[arch-general] virtualize a w8 ntfs partition and run w8 inside Arch
by arnaud gaboury 21 May '14

21 May '14

I dual boot Arch and w8 in EFI mode with rEFInd. Both Os are on the same ssd, with a ESP partition. Now I am looking to allow Arch users to run a virtualized version of the w8 already installed. The idea is to keep the dual boot option and allow the use of the installed w8 from Arch.I want to run within Arch a real "copy" of w8. In short, when changes are made or new apps are installed from w8 boot, I want to be sure these changes will be taken into account in the virtualized w8. It seems to me the QEMU arch wiki part [1] : Using any real partition as the single primary partition of a hard disk image will do what I am willing for. Am I right? If yes, is there any workaround to use the ESP partition of my ssd instead of creating a MBR like suggested in the WIKI ? Thank you for help and tips. [1]https://wiki.archlinux.org/index.php/QEMU

4 6