- Arch-general - lists.archlinux.org

[arch-general] VBoxWebsrv has trouble exiting itself
by Jim Mi 21 Feb '16

21 Feb '16

Recently I found my system(Gnome+Nvidia+bumblebee) freezes sometimes during powering off, so I checked the systemsd log, and it shows that vboxwebsrv timed out(took about a minute to be killed). I disabled vboxwebsrv, everything seems okay now. Has anyone experienced this too ? If it were a bug, I think the developers should be informed.

1 0

[arch-general] archwiki (readline) Disabling control echo no longer working, and ~ not shown until 2nd char typed?
by David C. Rankin 20 Feb '16

20 Feb '16

All, Following https://wiki.archlinux.org/index.php/Readline I was attempting to disable control echo by adding 'set echo-control-characters off' to ~/.inputrc. After logging out/in there is no change to the '^C' echo after 'ctrl+c' is pressed to terminate the present command. I even tried adding it to /etc/inputrc. Same result. Is there something else needed with the current readline? Also in this process, I noticed when I type '~' (e.g. like ~/tmp) the '~' is not echoed until the 2nd character is pressed. This is confusing. I've looked at /etc/inputrc and do not see anything that appears to suppress echo of '~' (or I was too dumb to recognize it). What is preventing the '~' from being echoed when it is typed as the first character? How do I fix it so it always is shown? (I'm using default BASH as the shell) -- David C. Rankin, J.D.,P.E.

2 3

[arch-general] [SOLVED] Re: Update php 5.6 to 7.0.1 problems
by Maykel Franco 19 Feb '16

19 Feb '16

2016-01-27 12:21 GMT+01:00 Jameson <imntreal(a)gmail.com>: > On Tue, Jan 26, 2016, 3:37 PM Wolfgang Mader <Wolfgang_Mader(a)brain-frog.de> > wrote: > >> >> >> On 01/26/2016 09:31 PM, Maykel Franco wrote: >> > How to resolve this warning?? I have error with owncloud client try >> > connect user/password login... >> >> For you module error, check this page >> https://pierre-schmitz.com/php-7-on-arch-linux/ >> especially the paragraph "Configuration changes". As they are now build >> in, you can simply remove them from /etc/php/php.ini >> > > You should also take a look at a tool like pacdiff to help you manage > config changes that come with package updates. > >> I update the system with php7 with latest packages today and the owncloud client works perfectly!! Thanks for all.

1 0

[arch-general] Alternative init system proposal
by Ivan 16 Feb '16

16 Feb '16

Hello, I have a proposal for Arch Linux developers and by mailing on this list I would also appreciate feedback from non-developers that use Arch Linux. Note: I am not here to hate on the current status, nor to disapprove of current Arch choices. So, to get to the point... I would like to propose development and official support of an alternative init system and service manager. My main preference would be OpenRC + sysvinit. The combination of those two has shown to work surprisingly well even with the current Arch's binary packages which are compiled with systemd support/dependencies. There are OpenRC packages already in the AUR, as well as an unofficial repository called "openrc-eudev" that replaces udev with Gentoo's eudev. See http://systemd-free.org for more info. (Please disregard the hate on the website, I am not pro-systemd-hate) Now, I realize this is not the correct way to do this stuff, and if we want an alternative system, a lot of compiling might have to be done, Or is it possible to keep systemd support? 1. Udev... Well, there are two alternatives worth mentioning. The first is, obviously, Gentoo's eudev that works really well, and keeps udev compatibility. Another alternative worth mentioning is vdev (https://github.com/jcnelson/vdev) It is also maintained in the AUR. vdev is developed to be completely non-dependent on systemd and I think it might be a nice option to consider. Note that it is still under development. 2. Packaging... If current and furure builds are kept with systemd support, then there's only the option of including an OpenRC-compatible script in the same package, along with the systemd.service file, and then depending on what's used on the machine, install the according one (in most cases). Otherwise, new compilation will have to be done, and that brings up the issue of storage space, which, in the worst case - gets cut in half. I would need more feedback on this. 2.1. Repositories... core, extra, community and multilib would not need any -openrc offsprings. If we would build new packages, without systemd support, pacman would need code modifications to distinguish between the two - systemd and openrc. An idea is to modify the package naming scheme somehow, possibly -openrc and -systemd. 3. Support... The biggest drawback is definitely the support that goes on in ArchBBS, ArchWiki, Bugtracker and eventually #archlinux on freenode IRC. The ArchBBS and the IRC wouldn't be detriment(?) because they don't really have any *specific* support threads or sections. However, the ArchWiki would need a lot of rewriting/editing, but honestly, the community is big enough to handle it. As for the bugtracker, it might get a bit more bugs than usually :D To conclude, this is still a mere draft and a proposal. I realize that there are a lot more things to be discussed about this. So, please give me feedback on all of this and let's see what we can do about it and what it can develop into... Kind regards to the entire mailinglist, ~ parazyd

27 59

[arch-general] Ksnapshots not work
by Maykel Franco 16 Feb '16

16 Feb '16

Hi, after update archlinux system, ksnapshot not work fine... Te key impr pet sys not work... Anybody with the same problem?

3 2

[arch-general] SourceForge now supports TLS, update source URLs
by Nicolas F. 16 Feb '16

16 Feb '16

Hi all, quick reminder that SourceForge was recently acquired and since then has enabled HTTPS on all of the site. Since some PKGBUILDs fetch their sources from SourceForge, it might be a good idea to switch them from using plain http:// to https://. While the certificate authority model is arguably broken when it comes to protecting against state-sponsored attacks, this will give some additional security to ensure that the sources packagers fetch and generate the hash sums from are actually the sources the project releases, and not a malicious man-in-the-middle response by some third party. Finding the affected packages should be as simple as running the following in the ABS root: for f in $(egrep -r -l 'http://.*\.sourceforge\.net' *); do \ echo $(dirname $f); done | uniq I'm counting 937 affected packages here. Cheers

2 2

[arch-general] Error message with full disk encryption
by PeLo L 16 Feb '16

16 Feb '16

Hi, I've followed the arch wiki and deployed a full disk encrypted install. Everything works fine and am able to boot properly into the install. While trying to shutdown my system, systemd displays an error which says "systemd: stopped (with error) /dev/mapper/crypt-boot". 'crypt-boot' is the device mapper name for the encrypted boot partition. Could someone explain this. Do I need to be concerned of any data loss in the boot partition? - Solomon

7 13

[arch-general] Vulkan packages
by Eric Engeström 15 Feb '16

15 Feb '16

Hi all, With the release of Vulkan imminent, I thought I'd prepare some packages for Arch so that I can push them the minute it gets released :) I was thinking of splitting it into 4 packages: - `vulkan-loader` with everything you need to run an app compiled against Vulkan (/usr/lib/libvulkan.so*). This is what Vulkan-apps packages would `depend` on. - `vulkan-headers` with everything you need to build an app for Vulkan (/usr/include/vulkan/* & /usr/lib/pkgconfig/vulkan.pc) (depends on `-loader`) - `vulkan-sdk` with all the debugging and validation stuff from LunarG (/usr/bin/*, /usr/share/vulkan/*) (depends on `-headers` + `-loader`) - `vulkan-manpages` (self-explanatory :P) I've also made `-git` versions of all of those, except the `-sdk`: I can't make it clean enough for a PKGBUILD without heavy patching of upstream's build scripts (I'm hoping somebody fixes that soon enough, I don't have the patience to do it myself :P). Does this sound reasonable? Since those are all interconnected, should I make a single split package (like `mesa`), or separate packages? I've written them as separate packages for now, but they're all in `groups=('vulkan')` Note that Intel's open-source ICD is being merged into Mesa, and the CTS is merged into AOSP's dEQP, so there's no need to make new packages for them. I'm also ready to take on the responsibility of maintaining those packages. Should be implicit, but I thought I'd mention it, especially if they get moved to `community` :) Cheers, Eric Engeström

3 3

[arch-general] thunderbird proxy env. vars for socks
by Javier Vasquez 15 Feb '16

15 Feb '16

Hi, I'm familiar with proxy envirnoment variables such as (both lower and upper case versions): use_proxy soap_use_proxy http_proxy https_proxy ftp_proxy rsync_proxy no_proxy all_proxy Thunderbird at least pay attention to some of them, and honestly, before I haven't needed anything else. However, inside the company, I need to setup manually under TB: SOCKS Host: <...> Port: <...> As SOCKS v5. Where the socks host is the same as the other proxy hosts, but its socks port must be different than the rest. I don't use any DE, but I have some automation through bash+xinitrc which depends on how to set the env. vars, so that I only need to set on TB/FF "use system proxy settings". I've tried several possible env. vars (both lower and upper case) like: socks_proxy socks_server socks_version smtp_proxy="socks5://<proxy_host>:<port>" So far I haven't been able to get any possitive results. Does any one know how I might be able to set socks for TB through env. vars? Thanks, -- Javier

2 1

Re: [arch-general] Alternative init system proposal
by Maxwell Anselm 14 Feb '16

14 Feb '16

> Though I don't see how a repository officially trusted by > Manjaro is less trusted than the AUR. They are completely different. An unofficial repository of non-AUR packages is for installing binary packages that have no affiliation with Arch Linux. I think it's pretty obvious why that would not be an appropriate recommendation on the Arch Linux wiki. The AUR lets users view the PKGBUILD before installing and also to comment and vote in order to establish trust. This is why wiki articles cannot recommend AUR helpers, since they bypass these mechanisms. Max

2 1