March 2017 - Arch-general - lists.archlinux.org

Re: [arch-general] Kaffeine video problem
by pete nikolic 12 Mar '17

12 Mar '17

Futher to the reported kaffeine problem it seems no video playback is working sound ok no video with the same reports help needed please . Pete .

3 4

[arch-general] Update to Linux 4.10.1-1 Broke Bind9 /etc/named.conf never reached on startup
by David C. Rankin 12 Mar '17

12 Mar '17

All, After update to Linux 4.10.1-1, Bind9 cannot connect to 127.0.0.1#953. This server has been flawless with Bind for 4 years. Now, for example attempting to sync zones: # rndc -V sync --clean create memory context create socket manager create task manager create task create logging context setting log tag creating log channel enabling log channel create parser get key decode base64 secret allocate data buffer sync post event using server 127.0.0.1 (127.0.0.1#953) create socket bind socket connect rndc: connect failed: 127.0.0.1#953: connection refused This began with the March 10 update. Now attempting to stop named results in a timeout: Mar 12 08:45:18 phoinix systemd[1]: Stopped Internet domain name server. Mar 12 08:45:18 phoinix systemd[1]: named.service: Unit entered failed state. Mar 12 08:45:18 phoinix systemd[1]: named.service: Failed with result 'timeout'. Attempting to start named, named never loads the zone files and never processes the libseccomp sandboxing active command during startup. Now, the total startup for named in the journal is: Mar 10 18:43:53 phoinix named[452]: starting BIND 9.11.0-P3 <id:4801fbc> Mar 10 18:43:53 phoinix named[452]: running on Linux x86_64 4.10.1-1-ARCH #1 SMP PREEMPT Sun Feb 26 21:08:53 UTC 2017 Mar 10 18:43:53 phoinix named[452]: built with '<snip stuff>' Mar 10 18:43:53 phoinix named[452]: running as: named -f -u named Mar 10 18:43:53 phoinix named[452]: ---------------------------------------------------- Mar 10 18:43:53 phoinix named[452]: BIND 9 is maintained by Internet Systems Consortium, Mar 10 18:43:53 phoinix named[452]: Inc. (ISC), a non-profit 501(c)(3) public-benefit Mar 10 18:43:53 phoinix named[452]: corporation. Support and training for BIND 9 are Mar 10 18:43:53 phoinix named[452]: available at https://www.isc.org/support Mar 10 18:43:53 phoinix named[452]: ---------------------------------------------------- Mar 10 18:43:53 phoinix named[452]: adjusted limit on open files from 4096 to 1048576 Mar 10 18:43:53 phoinix named[452]: found 4 CPUs, using 4 worker threads Mar 10 18:43:53 phoinix named[452]: using 3 UDP listeners per interface Mar 10 18:43:53 phoinix named[452]: using up to 4096 sockets Where normally, the startup should continue with, e.g.: Feb 21 14:15:38 phoinix named[442]: libseccomp sandboxing active Feb 21 14:15:38 phoinix named[442]: loading configuration from '/etc/named.conf' Feb 21 14:15:38 phoinix named[442]: reading built-in trusted keys from file '/etc/bind.keys' Feb 21 14:15:38 phoinix named[442]: initializing GeoIP Country (IPv4) (type 1) DB Feb 21 14:15:38 phoinix named[442]: GEO-106FREE 20170207 Build 1 Copy Feb 21 14:15:38 phoinix named[442]: initializing GeoIP Country (IPv6) (type 12) DB Feb 21 14:15:38 phoinix named[442]: GEO-106FREE 20170207 Build 1 C Feb 21 14:15:38 phoinix named[442]: GeoIP City (IPv4) (type 2) DB not available Feb 21 14:15:38 phoinix named[442]: GeoIP City (IPv4) (type 6) DB not available Feb 21 14:15:38 phoinix named[442]: GeoIP City (IPv6) (type 30) DB not available Feb 21 14:15:38 phoinix named[442]: GeoIP City (IPv6) (type 31) DB not available Feb 21 14:15:38 phoinix named[442]: GeoIP Region (type 3) DB not available Feb 21 14:15:38 phoinix named[442]: GeoIP Region (type 7) DB not available Feb 21 14:15:38 phoinix named[442]: GeoIP ISP (type 4) DB not available Feb 21 14:15:38 phoinix named[442]: GeoIP Org (type 5) DB not available Feb 21 14:15:38 phoinix named[442]: GeoIP AS (type 9) DB not available Feb 21 14:15:38 phoinix named[442]: GeoIP Domain (type 11) DB not available Feb 21 14:15:38 phoinix named[442]: GeoIP NetSpeed (type 10) DB not available Feb 21 14:15:38 phoinix named[442]: using default UDP/IPv4 port range: [32768, 60999] Feb 21 14:15:38 phoinix named[442]: using default UDP/IPv6 port range: [32768, 60999] Feb 21 14:15:38 phoinix named[442]: listening on IPv4 interface lo, 127.0.0.1#53 Feb 21 14:15:38 phoinix named[442]: listening on IPv4 interface enp0s10, 192.168.7.16#53 Feb 21 14:15:38 phoinix named[442]: generating session key for dynamic DNS Feb 21 14:15:38 phoinix named[442]: sizing zone task pool based on 5 zones Feb 21 14:15:38 phoinix named[442]: 'max-cache-size 90%' - setting to 7189MB (out of 7988MB) Feb 21 14:15:38 phoinix named[442]: set up managed keys zone for view _default, file 'managed-keys.bind' Feb 21 14:15:38 phoinix named[442]: automatic empty zone: 10.IN-ADDR.ARPA Feb 21 14:15:38 phoinix named[442]: automatic empty zone: 16.172.IN-ADDR.ARPA Feb 21 14:15:38 phoinix named[442]: automatic empty zone: 17.172.IN-ADDR.ARPA Feb 21 14:15:38 phoinix named[442]: automatic empty zone: 18.172.IN-ADDR.ARPA Feb 21 14:15:38 phoinix named[442]: automatic empty zone: 19.172.IN-ADDR.ARPA For some reason the 'libseccomp sandboxing active' command never issues and /etc/named.conf is never processed. I have not touched the configuration here in a "long long time..." Is this a kernel bug, a libseccomp bug, what? -- David C. Rankin, J.D.,P.E.

3 5

Re: [arch-general] Arch Nim package
by Peter Munch-Ellingsen 10 Mar '17

10 Mar '17

Hi, the Nim package: https://www.archlinux.org/packages/community/x86_64/nim/ was marked out of date on 2016-10-24 but it's still not edited to reflect the new version of 0.16.2. Would anyone be so kind to adopt this package? If not could the package be dropped to AUR? Peter

5 5

[arch-general] hcidump is missing?
by Алексей Трофимов 09 Mar '17

09 Mar '17

I try to dump bluetooth traffic to find audio codecs my wireless headphones support -- http://askubuntu.com/questions/425333/how-to-make-aptx-capable-bluetooth-eq… But it looks like I have no hcidump installed. command-not-found says: hcidump may be found in the following packages: extra/bluez-utils 5.42-1 /usr/bin/hcidump I have `bluez-utils` installed. Checking https://www.archlinux.org/packages/extra/x86_64/bluez-utils/ I see that it provides `bluez-hcidump`, but no bluez-utils is file list? Was it renamed? Deprecated? What should I use then?

5 5

[arch-general] Firefox user data autofill doesn't work as before
by Peter Nabbefeld 09 Mar '17

09 Mar '17

Hello, before latest update, firefox filled my login credentials automatically into the appropriate fields. Now I've first to select the user in a dropdown list - how can I revert this behaviour? Kind regards Peter

7 16

[arch-general] How to "decorate" a package build?
by Peter Nabbefeld 09 Mar '17

09 Mar '17

Hello, is it possible to decorate a package build, i.e. set some prconditions (like exporting variables) and probably even change the build process (compile instead of copying just the binaries)? E.g., to modify the firefox package update to first compile with "--enable-alsa". Of course, I would have to create my own package in a private repository. The new PKGBUILD file would need to refer the original one, to get e.g. the package version number. However, the private package would always have the same version, so the official package change needs to be hooked to the generic private package: Official Package Changed --«Signal»--> Private Package Update --«Inherits»--> Official Package Update Kind regards P.

6 15

Re: [arch-general] [arch-dev-public] AUR ToS (aka making AUR user names public)
by Mauro Santos 08 Mar '17

08 Mar '17

On 05-03-2017 13:35, Lukas Fleischer wrote: > Hi, > > I was recently contacted by a Polish researcher asking for a list of AUR > account names. I did not expect this to be controversial but a couple of > Trusted Users raised concerns on IRC, so I decided to move this to the > public mailing list and discuss the whole topic in generality. I would > like to head more opinions but please read the whole email and give it a > second thought before simply bringing up the usual privacy arguments > mentioned below. > > My original questions was: Are we fine with sharing the list of AUR > accounts names (only user names, no real names or email addresses) with > a researcher that seems trustworthy and agrees to not share the data in > any form other than the resulting anonymized statistics? > > In this particular case, we are talking about Dorota Celinska [1] from > the University of Warsaw, Faculty of Economic Sciences [2], see [3] for > a list of her publications and [4] for a summary of her research project > funded recently by the Polish National Science Centre. She needs the > list of user names to perform a segmentation analysis, including users > which were active on the older AUR releases both do not show any > activity on AUR 4. She would also like to use the user names as > identifiers to establish connections with other platforms, such as > GitHub. > > The next question is: Would it make sense to even make this data > publicly available? Would it make sense to extend our RPC interface such > that one can search for users names? GitHub, for example, already > provides such an interface [5]. Let me quickly summarize some arguments > for this idea which came up on IRC: > > * User names are mostly identifiers. It is questionable whether they > can/should be considered personal/private information. Maybe this can > only be answered by a lawyer, though. > > * The user names of all accounts with any kind of public activity, like > uploading a package, filing a request, writing a comment, are public > already. > > * After logging into the aurweb interface, you can already check whether > an account with a given user name exists because the account details > page URIs have the form https://aur.archlinux.org/account/$username. > This means that for any platform providing a list of user names (such > as GitHub), you can "establish connections" with the AUR already. > > Now the arguments against: > > * Principle of data economy: We should not share any kind of information > we do not need to share. > > * Sharing user names lowers the threshold for sharing other information > which is considered more confidential. > > * Users can (and should) already use crawlers to fetch the user names. > For example, the user names of all package maintainers and comment > authors appear on the package details pages. The names of all users > filing package requests appear in the mailing list archives etc. > > * We do not have ToS so we better not share anything. > > I, personally, find the second last argument a very weak one. Telling > users to build crawlers scraping an brute-forcing our HTML pages makes > life difficult for both them and us. What do you think? > > On the other side of the coin, the last argument is a very good one and > it brings me to my last point. Independently of the outcome of this > discussion, I think we should add some ToS that users need to agree upon > when registering. It should contain information on liability and on > privacy. Is anybody willing to write a draft? Do we need the support of > a lawyer here? > > Thank you for your time and have a nice Sunday! > > Regards, > Lukas > > [1] http://coin.wne.uw.edu.pl/dcelinska/en/ > [2] https://www.wne.uw.edu.pl/index.php/en/ > [3] http://coin.wne.uw.edu.pl/dcelinska/en/pages/publications.html > [4] https://ncn.gov.pl/sites/default/files/listy-rankingowe/2016-03-15/streszcz… > [5] https://developer.github.com/v3/users/ > I'd say err on the caution side and don't share, even though the usernames are public and easy to find by scraping them from the website/mailing list/etc, handing the whole database of usernames in a silver platter is a whole different story, which is what is being asked. Is there any community/website that provides a full list of registered usernames on request? There is also the question of how useful that data would be, without any other data such as email the username list is useless, you have no guarantee that user foo on github is the same person as user foo on the AUR/Wiki/Forum or user foo somewhere else. In this case I'd also have to agree that sharing usernames lowers the threshold for sharing other information. It also doesn't fit with their stated research goals, only github and projects associated with scraping data from github are mentioned, why would they want to throw the AUR usernames in the mix? -- Mauro Santos

14 38

[arch-general] Linux LTS 4.4 continued or 4.9 coming soon?
by Pablo Roberto Lezaeta Reyes 08 Mar '17

08 Mar '17

>>I'm going to move to 4.9-lts branch pretty soon... Dont forget to take care of FS#51455 since for this is why I cant go beyond LTS for now, and if you go to 4.9 I could get lock out or word, I cant update the kernel in a rolling release distro. -- *Pablo Lezaeta*

5 4

[arch-general] Firefox 52 Audio broken
by jjgaris 07 Mar '17

07 Mar '17

Since the update to firefox 52 the audio support has been broken. This seems to be because pulse audio is now a dependency by default in firefox. However firefox can still be build with ALSA support. Without getting into any dicussion about issues about pulseaudio itself, I believe it should be possible to use firefox on arch without being forces to use pulse audio. I am certainly not the only one to have banned this package from my boxes. And having more choices is certainly a good thing. Not sure this is the right place but I would like to ask to change back to the old defaults (ALSA). With the old defaults, the user can choose to use pulse audio (or JACK) or stay with plain ALSA support.

13 25

[arch-general] [arch-dev-public] AUR ToS (aka making AUR user names public)
by fnodeuser 07 Mar '17

07 Mar '17

test

3 3