July 2016 - Arch-general - lists.archlinux.org

[arch-general] Announcing pacpak
by pelzflorian (Florian Pelz) 22 Feb '17

22 Feb '17

Hello, A specter is haunting the GNU/Linux ecosystem: the specter of per-user containerization. Software like Flatpak and Snappy promise fully sandboxed GNU/Linux application bundles (instead of merely launching an application with fewer privileges but without hiding the operating system, like Bubblewrap or Firejail do). Bundles ship with the version of their dependencies which they need. Dependencies are not force-upgraded with the operating system, but easily upgradable by the bundle creator. The same files in different bundles and versions are deduplicated to save space. Applications can be containerized once for all modern GNU/Linux operating systems. Unlike Docker, Flatpak works without root privileges. Flatpak allows you to run, say, a sandboxed and containerized copy of LibreOffice where opening an infected file can only cause harm to what the sandbox has access to, but not compromise the integrity of the system as a whole. Untrustworthy games can be isolated and run without fear of a system compromise. More generally, most GUI applications should probably be installed to and run from a Flatpak sandbox. This has major implications for traditional package managers. Pacman would be demoted to providing the base system on top of which Flatpak bundles downloaded from elsewhere are run (e.g. from gnome.org or from reallytheofficialwebsiteoflibreofficeipromise.com) However, I would prefer having a unified pacman-like interface for installing containerized and non-containerized applications. I believe a PKGBUILD is a good way to specify how to build an application for Flatpak as well. I do not want to lose the many packages from Arch and derivative distributions. tl;dr: Therefore I started writing a tool called pacpak which uses pacman to populate Flatpak application bundles. Its interface is meant to be similar to pacman’s. For example, in order to install gedit into a Flatpak application using a bundle of the gnome packages as a runtime, you install pacpak from the AUR and use: $ pacpak -S Base xterm You can run the resulting application like this: $ flatpak run $(hostname).app.xterm pacpak is still in its early alpha stages. I do not currently have the time to devote more than a day per week to its development. However, I’d like some feedback on the basic idea. I am also looking for a home for the project in the longer term, since I do not currently like to administer a bug tracker on my own rented server and dislike centralizing all free software development on GitHub or Sourceforge (I’d rather administer my own then). This will only be helpful once all the basic features are implemented of course. I would be glad if pacpak or a similar tool eventually becomes an official Arch project. Let me conclude by thanking those who develop Flatpak, those who package and maintain Flatpak for Arch and all the other Arch and free software developers we rely on. Regards, Florian Pelz

15 35

[arch-general] Libreoffice Google Drive not working
by Martin Zecher 15 Aug '16

15 Aug '16

When trying to access Google Drive under Libreoffice 5.1.4-1, I get "The specified device is invalid". This problem should be fixed since 5.1.3.2 according to https://bugs.documentfoundation.org/show_bug.cgi?id=98416 I think there may be a problem with Arch's compilation. -- Martin Usen DropBox <https://www.dropbox.com/referrals/NTIwODk0MDk> (2GB + *500MB bonus*) Taxi de lujo en Santiago a buen precio: Uber <https://www.uber.com/invite/1p48v> ($5.000 gratis) Cabify <http://www.cabify.cl/es/home>. Regístrense con el código MARTINZ5 ($5.000 gratis)

3 5

[arch-general] VirtualBox ALT-key problems (especially with Adobe programs)
by Klaus Doblmann M.A. 06 Aug '16

06 Aug '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I'm having troubles getting the ALT-key to work properly in VirtualBox as a modifier in applications like Photoshop for things like the clone tool, it isn't recognised as the ALT-key. (No discussions about my need for these proprietary apps please, there are valid reasons for my need for those, I'm not happy about it either). This has been a long-standing problem when using Linux as host systems and is related to aspects of the window management. In previous systems the culprit was that ALT+dragging left mouse button was set to move windows around in Linux, this interfered with the function of the ALT key in the virtual machines. Now using Arch (GNOME3) I have tried several things but haven't found a solution yet. Here's what I've tried: - - Use GNOME tinker tool to disable the window action-key (or assign the super key for that) - - Use GNOME tinker tool to switch the assignment of the ALT and Windows keys - - Tried several different settings in VirtualBox in regards to the capturing of mouse and/or keyboard None of these things - which used to provide a solution in the past) worked, but I have to admit I haven't used a virtual Windows system with Photoshop on a Linux host in probably five years so things might have changed quite a bit. Any pointers from this list? thanks, Klaus - -- Klaus Doblmann M.A. PGP: 43F89A1B -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJXgNiPAAoJEJArGOi/1wqdejsH/AtddpGWCLTEe+6XqgXji73P bCkTfhdKFqDGO0rRgov8j3I4cAMWm63IVrQDxVqvRoAxklPQrLSkaj/GKCCvbJ9T Dr3NEJldqhTMyrSB1ezm6qRCAI8D73lTika6EHmpOst3g+tLmfj+/O8XMlG88gMt Vam2a40MPTYhQWLAZxSkYg92pAk6n3bHrzMRSEu0n/PLJMNSDC27ajE6kMUap4oT QGXsubG8oUYpXvJcUeTBCfGE7c7eGocqZmCrjUJT2Z4SAV31oIsAxswz0Z/OV7pE /8tpwQK6lMNmh1FTjfzdcvzBntds9zGB5ElgYtRyEM94UmNipsE8IDwBiGM8M90= =JHCG -----END PGP SIGNATURE-----

4 5

Re: [arch-general] [arch-dev-public] libvpx moved to testing - dropping avidemux?
by nfnty 31 Jul '16

31 Jul '16

On 2016-07-31 10:19, Andreas Radke wrote: > The libvpx rebuilt packages have been moved to testing. Old avidemux > won't compile against it. A major update is pending for a long > time. Eric isn't around it seems already for a few months. > > Is there any Dev or TU wanting to take care of it? > > If not we should drop it to AUR. > > -Andy > I've tried contacting Eric multiple times regarding Avidemux. Opened a bug report [1] which got closed by Doug for apparently not being the proper place to report such things. Got an updated build over on github [2]. //nfnty [1] https://bugs.archlinux.org/task/48991 [2] https://github.com/nfnty/pkgbuilds/tree/master/avidemux/avidemux

1 0

[arch-general] community/go-tools godoc
by David N Murray 29 Jul '16

29 Jul '16

Greetings, I think I have two problems. The first is a simple packaging question. I have been using Go (community/go and go-tools, version 2:1.6.3-1 is currently installed and appears to be the latest package available) for a few years. Tonight I get this: $ godoc bash: godoc: command not found I usually start godoc for docs on the installed go packages I have in my project (godoc -http=:6060 &), so I know I used to have it, but it's been a few weeks since I tried to use it (2:1.6.3-1 was released 21-Jul and I upgraded shortly thereafter). $ locate godoc /usr/src/bin/godoc So, my initial question is what happened to godoc? I expected it in /usr/bin (same place that go, gofmt, etc. are installed). It seems to have disappeared: $ pacman -Ql go-tools | grep godoc $ pacman -Qo godoc error: failed to find 'godoc' in PATH: No such file or directory $ pacman -Ql -p /var/cache/pacman/pkg/go-tools-2:1.6.2-2-x86_64.pkg.tar.xz | grep godoc go-tools /usr/bin/godoc Did it get dropped, inadvertantly? I looked around the packages and it doesn't look like it got moved. My second question is regarding /usr/src/bin. I don't recall ever seeing that directory before and I don't have it on the other 2 arch boxen I built. Did I screw something up along the way? All the binaries in there are dated 25-Oct-2015. I'm using this godoc for the time being, but I can't tell which version it got packaged with (probably doesn't matter). TIA, Dave

2 1

Re: [arch-general] [arch-dev-public] signoffs are dead
by Kyle Terrien 26 Jul '16

26 Jul '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I am replying to arch-general because arch-dev-public is closed to most users. On Tue, 28 Jun 2016 08:09:41 -1000 Gaetan Bisson <bisson(a)archlinux.org> wrote: > Dear all, > > For a while now packages in [testing] have gotten little to no > signoffs and I've been moving mine to [core] after a week without > feedback. I suspect many of you have been doing this too. Here's the > signoff reports over the last ten days: > > - June 19: 0 signoffs > - June 20: 6 from me, 4 from anthraxx > - June 21: 0 > - June 22: 5 from me > - June 23: 2 from demize > - June 24: 1 from me > - June 25: 0 > - June 26: 1 from me > - June 27: 3 from me, 1 from eworm > - June 28: 3 from heftig, 2 from arojas > > So I've decided to shorten the wait in [testing] to 48 hours. Many > updates to [core] packages include security fixes and they have better > move sooner rather than later. We used to be able to gather enough > signoffs to move these within a day or two, and that's what I intend > to do with or without signoffs. > > Any comment, and especially any other idea to fix this situation, is > welcome. > > Cheers. First, I am an Arch user (for 3 years now) not an Arch dev, and I realize I have no right to tell anyone how to run the distribution. What follows is just my personal recommendation based on working software QA professionally. With that said, I think eliminating signoffs is a bad idea. Signoffs ensure some form of quality control. A signoff is an explicit approval from someone that the package is satisfactory to his/her standards. A potential signee has a completely different perspective than the packager and a different way of verifying that the packager's package is correct. This sort of approval process catches errors that would otherwise escape the packager's notice. Simply waiting a period of time without hearing complaints is not equivalent to explicit approval from others. I have personally experienced several breakages in the past several months--more than usual. A few were big enough that simply running 'foo - --version' should have revealed a problem (i.e. linking problems). A signoff process would have very likely caught these problems. IMHO, the correct thing to do is remind other developers of the signoff policy. (And the above post to arch-dev-general certainly does just that.) Encouraging another set of eyes to look at someone's work and say, "This looks good to me," is a very good thing and does wonders in terms of quality control. If getting security fixes pushed out is a concern, then getting the security related fixes signed off should be prioritized. (Maybe by putting in a flag that automatically triggers a mail to arch-dev-public) Respectfully yours, - --Kyle Terrien -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXczI6AAoJEN5rMzXPJBsQASIP+gLGiQbQVrg/mNVDacXaHuEK 8H3QQz9amQMwgQXq8Mh17HWfbiQMQMWD48O9CBP+fUyWLVPOxs6g4H/aXFiIm4G+ Qw6/vWfgQaGjY60nLJ7D8/NVq9PwXSPEYF1cA8/6D7JtuotwXxCFENiNR9Qki7Un 3QCXRI6Z/KKGcpBvpIsa++qDeZuXnSTy00ZJO5EFYxTi+AUBEyffHX/bS2IUCOkC tUWxtoVIix4buD32/tCnPz19wku9MylddYBzNuB1qCD1NG6XLsxmn8WiHGeoiy+E uFwjxPgDx0MaldNNJzubC2LQD/osdTDTTPwDf2M0c802FI+pHxlj/Dk9imz86NFA 9xPH8WJ1cfiVTue0BkRJXlR2eI0VIPSqAbpcDCfzCwYbrFuFoqwszpET03PtF/Y4 5tfZHLODiFpDc9Whu5o4ejzf4p/eMUN3xmwUp+8cguFcSmjBSPvYvRbgI8puiPRm Al5xYxnrmghEf9R5fIRUWoHlsGNNMrmd1MKquJ6i1+Dkf0pmUK4t58G3crWjFb7+ laMUKYRmH+LwYhxvET562E8EM8QYYtow+PietZssC7ZhjGa1sG70FahQWCijmIj6 TdpfCiNgmQ8AF4C4JXhzZvONtdYzUeNSgiv/FkA9T4n9Xje/ZCUhyM+inaqmA/5A ComaWc2SjeM8gTBfdPQa =E42/ -----END PGP SIGNATURE-----

6 5

[arch-general] Removal of the Dasher package
by Germano Corrêa 26 Jul '16

26 Jul '16

Hello! I don't know if I'm in the right mailing list, so sorry if I'm in the wrong place... I need to install the package Dasher, and I realized it's not anymore in the official repositories (it was in extra and it was removed this year). I don't know if I didn't searched right, because I found nothing about this removal. Does anyone knows why? Of course I can download the source code and build it by myself, and that's what I'm doing. But I just wanted to know why they removed. Thanks, and sorry for anything...

4 4

Re: [arch-general] [arch-dev-public] signoffs are dead
by Genes Lists 26 Jul '16

26 Jul '16

On Sat, 2016-07-02 at 09:16 +1000, Allan McRae wrote: > > This sounds like the Fedora policy where packages have to surpass a > certain karma level to move into the main repositories. I'm not sure > who gets to vote for that though. > > A I would suggest allowing any Arch user vote yay or nay (with comments) - I believe this is what fedora did - only requirement was to be a registered user of the website. I don't imagine significantly more information will be obtained beyond the issues raised now in the mail list and forum. However, it does have the advantage of putting it in a single place for the packager. gene

3 2

[arch-general] New TeXLive 2016 packages in [testing]
by Rémy Oudompheng 24 Jul '16

24 Jul '16

Hello, I have published new TeXLive packages for the 2016 release in [testing]. The structure of the packages has been left unchanged (e.g. no introduction of pacman hooks). Feel free to test them and notify me of any problem or weirdness. Cheers, Rémy.

1 1

[arch-general] Discussion about optional dependencies from arch-dev-public
by Óscar García Amor 19 Jul '16

19 Jul '16

Hi. I write my two cents here cause I cannot post in arch-dev-public. The main problem of add "qt5-x11extras" as dependency is that it add a lot of more dependencies. Take note that virtualbox can run as server and, in this case, you not need to install the gui. You can run it in a machine without X. Maybe the solution is split it in two packages, virtualbox (for gui) an virtualbox-server. What you think? Greetings. -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me

3 3