- Arch-general - lists.archlinux.org

Re: [arch-general] arch-general Digest, Vol 141, Issue 17
by ITwrx.org 12 Jul '16

12 Jul '16

On 07/11/2016 01:00 AM, arch-general-request(a)archlinux.org wrote: > On 07/11/2016 01:09 AM, Information Technology Works wrote: >> > Aren't snaps, flatpak and appimage missing the boat in a concerning >> > way? Shouldn't the Gnu+Linux ecosystem be focusing on automating the >> > package building/maintenance instead? A layer above distros' package >> > managers(pacman, apt, etc) that can build upstream from source without >> > human intervention. Maybe upstream would have to cooperate in some way? >> > Every distro would just have to write a plugin/config for themselves >> > that described how their packages should be built, then their package >> > manager can be used to install binaries like now. Distro devs could >> > develop the system and verify it's integrity/security or do distro >> > feature related work instead of packaging. This would address all the >> > problems that these app container based systems are trying to solve >> > while keeping dependency resolution, repos, etc. in tact. Is this >> > impossible/wrong for some reason? >> > > Hello, > > Work is being done in this area [1], but it?s not as fancy as you may > think. It?s mostly about upstream using a well-behaved build system. > Well-behaved software is easy to package anyway (just do `./configure > --prefix=/usr`, `make` and `make install`). When customization is > necessary or desired, pacman brings the needed versatility. > > Please note that ?build once, run anywhere? is not the only advantage of > Flatpak and not one pacpak addresses. To me, containerization mostly > provides added security by privilege revocation and separation of > privileges. > > Regards, > Florian Pelz > > [1] https://github.com/cgwalters/build-api Florian, thanks for the reply and link. Well behaved build systems and/or the link you sent is what i alluded to with my "cooperation from upstream" comment. It seems to me, upstream and distros should get together and agree on a set of standards. then all distros could auto-build their repos. Unless "build once, run everywhere" can be done in a way that's superior to repos and packages (i don't see how, but what do i know), it seems like the wrong approach and would be completely unecessary with all distros having near instant packages from upstream due to automation. I'm not necessarily opposed to the theoretical, potential security benefits of app containerization but minus the dependency compat layer, especially if automation of building is not so out of reach. Your package sounds interesting and good luck with it, i just thought i'd bring up these questions before we throw the baby out with the bath water. thanks, ITwrx

2 1

[arch-general] Mono package updates
by Phil Uithoven 11 Jul '16

11 Jul '16

Is there an issue with updating the mono package? The current 4.4 package that is in the repo was built on 3/28 and was way before 4.4 actually went stable. I’m not sure why an unstable build was used in the repo, but it caused issues and many users had to roll back to a 4.2 version package and put it on hold (me included). 4.4 then went stable on 6/8 as well as 4.4.1 stable on 6/21 but we still haven’t seen the package updated. http://www.mono-project.com/docs/about-mono/releases/ Can we have a mono update please?

2 2

Re: [arch-general] arch-general Digest, Vol 141, Issue 16
by Information Technology Works 11 Jul '16

11 Jul '16

On 07/10/2016 10:36 AM, arch-general-request(a)archlinux.org wrote: > Send arch-general mailing list submissions to > arch-general(a)archlinux.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.archlinux.org/listinfo/arch-general > or, via email, send a message with subject or body 'help' to > arch-general-request(a)archlinux.org > > You can reach the person managing the list at > arch-general-owner(a)archlinux.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of arch-general digest..." > > > Today's Topics: > > 1. Re: Announcing pacpak (pelzflorian (Florian Pelz)) > 2. Re: Announcing pacpak (pelzflorian (Florian Pelz)) > 3. Re: Announcing pacpak (Mauro Santos) > 4. Re: Announcing pacpak (Jelle van der Waa) > 5. Re: Announcing pacpak (Levente Polyak) > 6. Re: Announcing pacpak (pelzflorian (Florian Pelz)) > 7. Re: Announcing pacpak (pelzflorian (Florian Pelz)) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 10 Jul 2016 14:18:00 +0200 > From: "pelzflorian (Florian Pelz)" <pelzflorian(a)pelzflorian.de> > To: arch-general(a)archlinux.org > Subject: Re: [arch-general] Announcing pacpak > Message-ID: <d3d5da50-9819-16f7-fe4a-daf922af799e(a)pelzflorian.de> > Content-Type: text/plain; charset=utf-8 > > Hello, > > On 07/10/2016 12:52 PM, Bennett Piater wrote: >> Are you planning to address the catastrophy that ensues when 5000 >> different versions of important libraries are installed at the same >> time, most of which will always be 5 critical security updates behind? >> > The intention is that, once implemented, `pacpak -Syu` or maybe `pacpak > -Su` will install a current version of all apps and runtimes. Old > versions of apps and app runtimes that are not used by any app could be > cleaned by `pacpak -Sc` or a similar command (or automatically?); I?m > not yet sure what the best interface is. > > Note that there is a trade-off between memory consumption and the time > it takes to update a container. ostree (which is used by Flatpak) > compresses all runtimes and apps for about half the hard disk memory > consumption. This greatly increases the time it takes to update a > container. This may need to be addressed in ostree in the future. > >> I am very cynical about this container trend... :/ >> > The advantage of using pacman for Flatpak is that even pure Flatpak > users may still be interested in Arch packages, so Arch packages remain > just as relevant and everything stays mostly the same for those using > pure pacman. > > Regards, > Florian Pelz > > > ------------------------------ > > Message: 2 > Date: Sun, 10 Jul 2016 14:18:24 +0200 > From: "pelzflorian (Florian Pelz)" <pelzflorian(a)pelzflorian.de> > To: arch-general(a)archlinux.org > Subject: Re: [arch-general] Announcing pacpak > Message-ID: <985a680c-a132-862d-215c-8b8fc601e6b6(a)pelzflorian.de> > Content-Type: text/plain; charset=utf-8 > > Hello, > > On 07/10/2016 01:59 PM, LoneVVolf wrote: >> My personal preference though is for AL community to treat flatpak >> similar as derivative distros. >> >> something like : flatpak is unsupported on Arch linux, ask the flatpak >> creator(s) for help. > Hm? If there is not that much desire to support Flatpak ?officially? as > an Arch project, then I probably will end up setting up a mailing list > and bug tracker on my server sometime in the coming weeks. > > Regards, > Florian Pelz > > > ------------------------------ > > Message: 3 > Date: Sun, 10 Jul 2016 14:22:07 +0100 > From: Mauro Santos <registo.mailling(a)gmail.com> > To: arch-general(a)archlinux.org > Subject: Re: [arch-general] Announcing pacpak > Message-ID: <83961152-99e0-b19a-c363-08526ee33e28(a)gmail.com> > Content-Type: text/plain; charset=utf-8 > > On 10-07-2016 13:18, pelzflorian (Florian Pelz) wrote: >> Hello, >> >> On 07/10/2016 01:59 PM, LoneVVolf wrote: >>> My personal preference though is for AL community to treat flatpak >>> similar as derivative distros. >>> >>> something like : flatpak is unsupported on Arch linux, ask the flatpak >>> creator(s) for help. >> Hm? If there is not that much desire to support Flatpak ?officially? as >> an Arch project, then I probably will end up setting up a mailing list >> and bug tracker on my server sometime in the coming weeks. >> >> Regards, >> Florian Pelz >> > Personally I'd rather keep using the good old packages _but_ it would be > nice to have an official tool to manage/run/create flatpak packages, > this just to make sure that in case one needs to use a flatpak package > nothing will screw up the filesystem and cause more trouble than it's worth. > > However a big fat warning should be present somewhere that bugs/problems > with flatpak packages are the sole responsibility of upstream/the > creator as I suspect bugs and problems will be the norm. > Aren't snaps, flatpak and appimage missing the boat in a concerning way? Shouldn't the Gnu+Linux ecosystem be focusing on automating the package building/maintenance instead? A layer above distros' package managers(pacman, apt, etc) that can build upstream from source without human intervention. Maybe upstream would have to cooperate in some way? Every distro would just have to write a plugin/config for themselves that described how their packages should be built, then their package manager can be used to install binaries like now. Distro devs could develop the system and verify it's integrity/security or do distro feature related work instead of packaging. This would address all the problems that these app container based systems are trying to solve while keeping dependency resolution, repos, etc. in tact. Is this impossible/wrong for some reason?

2 1

[arch-general] Warning! Upgrading QupZilla to 2.x might cause loss of data
by Ralf Mardorf 10 Jul '16

10 Jul '16

Hi, to get back the history run $ mv .config/qupzilla/profiles/default/browsedata-backup(1).db .config/qupzilla/profiles/default/browsedata.db but this doesn't restore speed dial. Perhaps it also does not restore other data. I opened an issue: https://github.com/QupZilla/qupzilla/issues/2026 Regards, Ralf

1 2

Re: [arch-general] arch-chroot
by Jude DaShiell 08 Jul '16

08 Jul '16

It turns out arch-chroot is okay after all but very probably the last release of base and the last release of alsa-utils both need to go back to the factory for repairs. First base is probably implicated because after the pacstrap command was run pacstrap /mnt base base-devel espeakup alsa-utils grub crda dialog ifplugd iw wpa_actiond wpa_supplicant <enter> the /var/run/lock directory had not been created in the /mnt space. Second when it got created the alsactl store command run in arch-chroot arch-chroot /mnt /usr/bin/bash <enter> produced no errors. However even producing no errors upon reboot into the new system no speech would speak and speaker-test or speakertest would not work. --

3 2

[arch-general] Unsubscribe - Was: arch-chroot
by Ralf Mardorf 07 Jul '16

07 Jul '16

On Wed, 6 Jul 2016 22:25:39 -0700, jordan via arch-general wrote: >Unsubscribe Hijacking a thread to unsubscribe is a shame. Every modern MUA provides mailing list features (e.g.Claws and Evolution), so you even don't need to take a look at list mail headers. For example, Claws: Menue "Message" > Mailing-List > Unsubscribe Apart from this, it's the same for _all_ mailman based mailing lists: List-Unsubscribe: <https://lists.archlinux.org/options/arch-general>, <mailto:arch-general-request@archlinux.org?subject=unsubscribe> ^^^^^^^ ^^^^^^^ List-Unsubscribe: <https://lists.ubuntu.com/mailman/options/ubuntu-studio-devel>, <mailto:ubuntu-studio-devel-request@lists.ubuntu.com?subject=unsubscribe> ^^^^^^^ ^^^^^^^ The address to post to the list arch-general(a)archlinux.org is _not_ the same as the one for requests arch-general-request(a)archlinux.org . ^^^^^^^^ ^^^^^^^^ The text "unsubscribe" belongs to the subject of a new mail and _not_ to the message's body of a hijacked thread. Regards, Ralf

1 0

[arch-general] time setting problem after installing.
by matthew dyer 07 Jul '16

07 Jul '16

Hi all, I just installed arch into a vertual machine dfor now as I do not have a bare boons system to install to at the moment. Any way I have a problem whare my system thinks I am in lundon uk and not in the us. I have tried running NTPD-QG but I am told that the command not found. I want the clock to show the correct local time and not have it showing 4 hours ahead of it self. Any ideas on how to fix this. I want to show it in .profile, but it just creates a new file instead of using the exhisting file. How can I change my time to the corect local time? Thanks. Matthew -- Sent from my Arch Linux VM

7 11

[arch-general] arch-chroot
by Jude DaShiell 07 Jul '16

07 Jul '16

I had been using it to install archlinux specifically talkingarchlinux. It mostly works ok until I do alsactl store and then I get a state lock error. As a result of this failure, I can finish up a talkingarch installation but on reboot, I have no speech on the system. Does a way exist I can clear this problem? The only reason I'm doing this is because the wifi network I had set up and working with netctl also died and I'm going to have to wipe the hard drive and reinstall talkingarch to clear this problem. --

4 3

[arch-general] Using libpqxx with clang
by Garmine 06 Jul '16

06 Jul '16

Hi, With the recent update of libc++ I wanted to continue compiling and testing a C++14 project with clang (and gcc), but unfortunately the libpqxx package is compiled for gcc - it is impossible* to use with clang at the moment. It used to properly work several months ago. I believe the recent update of libc++ introduced incompatibilities between the two compilers and it's libraries and that's why the above issue arose. Anyways, did anyone manage to compile libpqxx dependent code using clang++ 3.8 and libc++ 3.8? Or does anyone have an idea on how to fix the package while retaining compatibility with both compilers at the same time? * or am I missing something? Regards, Garmine

1 0

[arch-general] fail to export gpg private key
by arnaud gaboury 06 Jul '16

06 Jul '16

I have successfully created a gpg key pair on one of my computer. I would like to use the same pair on another computer, so the need to export. Here are the commands: $ gpg --output tth_pub.gpg --armor --export KeyID Results in -rw-rw-r-- 1 poisonivy poisonivy 1.7K Jul 6 13:34 tth_pub.gpg Fine. Now with private one: $ gpg --output tth_sec.gpg --armor --export-secret-key KeyID gpg: WARNING: nothing exported I have the tth_sec.pgp but with size of zero. What do I wrong? gpg-agent is running : 67:poisoni+ 23911 1 0 13:41 ? 00:00:00 gpg-agent --homedir /home/poisonivy/.config/gnupg --use-standard-socket --daemon gpg.conf ------------- no-greeting homedir ~/.config/gnupg use-agent default-key 92AB63D5 charset utf-8 utf8-strings armor keyserver pgp.mit.edu keyserver-options auto-key-retrieve gpg-agent.conf --------------------- homedir ~/.config/gnupg allow-preset-passphrase Thank you for help. -- google.com/+arnaudgabourygabx

3 3