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

[arch-general] [Classroom] Git for Gits
by fsckd 19 Jul '16

19 Jul '16

Hello, If you are interested in starting with Git, there will soon be a class for beginners called "Git for Gits", taught by polyzen and meskarune, on Saturday, 16th July, at 16:00 UTC. It will be held in the IRC channel #archlinux-classroom on the freenode network. The class will cover the basics of creating and using a Git repository. Git is used by many FOSS projects to manage code. It is used extensively in Arch Linux, such as on the AUR. You can also use it to track dotfiles, configuration, blog posts, college essays, and any textual data (and even non-textual). The class is also a workshop where you will get a chance to play around with a Git repository. Please visit the following web page to sign up. You will need to make an SSH key. Directions are on the page: https://wiki.archlinux.org/index.php/Classroom/git_2016 polyzen is a lactose intolerant Linux Professional. He has been using Linux for about 5 years, and switched to Arch Linux over 3 years ago. meskarune is an artist, programmer, and sysadmin. She has contributed to FOSS for 16 years and been an Arch user for 9 years.

1 1

[arch-general] Pacman doesn't optionally require fakeroot
by Bennett Piater 18 Jul '16

18 Jul '16

Hi, I have a quick question. Makepkg, which is provided by pacman, doesn't work without fakeroot. Is there a reason why pacman doesnt opdep on it? Cheers, Bennett -- GPG fingerprint: 871F 1047 7DB3 DDED 5FC4 47B2 26C7 E577 EF96 7808

3 3

[arch-general] recent archlinux installation
by Jude DaShiell 17 Jul '16

17 Jul '16

I'm using lynx but am pretty sure this problem will happen no matter which browser I use. The browser when connecting to https::// type sites throws an ssl error because it can't get local issuer certificates. I have SSL_FILE in /etc/lynx.cfg pointed at /etc/ssl/certs/ca-certs.crt and I ran c_rehash on the system with no errors yet this situation continues. Is a package and/or configuration needed so these ssl errors may disappear? I had done archlinux installations earlier and never had this problem then. --

5 5

[arch-general] texinfo, a dependency for libidn and libtasn1
by Damjan Georgievski 17 Jul '16

17 Jul '16

Do libidn and libtasn1 really require texinfo? makes texinfo uninstallable, but I don't need docs on this system. Does any of the "requiires" of texinfo[1] actualy require it? shouldn't it be an opt-depend? [1] https://www.archlinux.org/packages/core/x86_64/texinfo/ -- damjan

1 0

[arch-general] [Archboot] Custom created Archboot ISO won't boot on qemu OVMF EFI
by Alive 4ever 17 Jul '16

17 Jul '16

Greetings Archboot Developers! (@tpowa) I am experimenting with manual Arch Boot creation. I created both x86_64 and i686 chroot with only base and archboot installed. I configured my locale by commenting 'en_US-UTF-8' line on /etc/locale.conf and launched 'locale-gen' to generate locale. Then I launched 'archboot-allinone.sh -t' on both chroot, which tooks a very long time. I moved the 'core-i686.tar' to x86_64 systemd-nspawn chroot. After that, I launched 'archboot-allinone.sh -g' which generates the images. I have successfully built the iso files, here are files generated from the build [code] # cd /var/local/x86_64_archboot/root # ls Archlinux-allinone-2016.07-dual.iso Archlinux-allinone-2016.07-x86_64-network.iso Archlinux-allinone-2016.07-dual-network.iso Archlinux-allinone-2016.07-x86_64-uefi.iso Archlinux-allinone-2016.07-dual-uefi-network.iso Archlinux-allinone-2016.07-x86_64-uefi-network.iso Archlinux-allinone-2016.07-i686.iso core-i686.tar Archlinux-allinone-2016.07-i686-network.iso core-x86_64.tar Archlinux-allinone-2016.07-x86_64.iso sha256sums.txt [/code] The non-uefi files boot fine with qemu-system-x86_64 bios mode (default mode). When I try to boot one of uefi iso, for example 'Archlinux-allinone-2016.07-x86_64-uefi-network.iso', using qemu-system-x86_64 with ovmf uefi firmware (-bios /usr/share/ovmf/ovmf_x86_64.bin), the qemu just refuses to boot. Launching EFI boot file directly on FS0:\EFI\grub\grubx64.efi comes up with 'error: unknown filesystem' and throws a rescue shell. 'lsmod' commands which should output all loaded modules throws 'unknown command'. I think grubx64.efi should be packed as standalone EFI image which contains all modules and grub.cfg loaded directly from memory. Launching EFI boot file FS0:\EFI\BOOT\BOOTX64.EFI throws 'Unsupported' error. Launching kernel directly from EFI shell is also unsupported. The default Arch Linux kernel as far as I know can be launched from EFI shell. Maybe this is because Archboot uses a non uefi stub kernel? Launching FS0:\EFI\BOOT\loader.efi just throw a menu 'EFI Default Loader' and 'Reboot Into Firmware Interface'. This bootloader is similar to systemd-boot loader, but it's not able to find the other boot entries because there is no files on FS0:\loader\entries. I did not make any modification to the archboot profiles. Is manual workaround needed to enable EFI booting on Archboot? Is it just bug on archboot-uefi-cd.sh script? Note: The system I used to create archboot image boots from legacy bios mode. Thanks.

2 4

[arch-general] chromeos chroagh buildinfo failure
by message 14 Jul '16

14 Jul '16

Readers, A bug using chroagh has been posted. Is there another way to use arch via chroot in a chromebook, ideally to replace the ubuntu installation? (https://github.com/drinkcat/chroagh/issues/121) chronos@localhost ~/Downloads/drinkcat-chroagh-18cc180 $ sudo sh -e installer/main.sh -r arch -t xfce WARNING: Your rootfs is writable. Signed boot verification cannot be enabled. If this is a surprise to you, you should do a full system recovery via USB. Installing arch-x86_64 chroot to /usr/local/chroots/arch Fetching repository packages list... Fetching core... ######################################################################## 100.0% Fetching community... ######################################################################## 100.0% Fetching extra... ######################################################################## 100.0% Downloading and extracting packages... Downloading and installing bash... ######################################################################## 100.0% tar: bash-4.3.046-1/depends: Not found in archive tar: Exiting with failure status due to previous errors tar: bash-4.3.046-1/depends: Not found in archive tar: Exiting with failure status due to previous errors Downloading and installing gawk... ######################################################################## 100.0% Downloading and installing grep... ######################################################################## 100.0% tar: .BUILDINFO: Cannot open: File exists tar: Exiting with failure status due to previous errors

1 0

[arch-general] mandb errors bad symlink or ROFF `.so' request??
by David C. Rankin 14 Jul '16

14 Jul '16

All, I have noticed the mandb becoming corrupt several times over the past month. It usually straightens itself out, but this is the 3rd time I've encountered this problem in the past 60 days or so. The symptoms are man being unable to find installed pages, e.g. $ apropos ssh ssh: nothing appropriate. $ man mandb mandb: nothing appropriate. $ find /usr/share/man/ -type f -name "mandb*" /usr/share/man/it/man8/mandb.8.gz /usr/share/man/es/man8/mandb.8.gz /usr/share/man/man8/mandb.8.gz $ man 8 mandb (works fine) # mandb -t mandb: warning: /usr/share/man/man3/pcredemo.3.gz: whatis parse for pcredemo(3) failed <snip> mandb: can't open /usr/share/man/man3/wayland-util.c.3: No such file or directory mandb: warning: /usr/share/man/man3/wl_abort.3.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man3/wayland-server.h.3: No such file or directory mandb: warning: /usr/share/man/man3/wl_client_add_resource.3.gz: bad symlink or ROFF `.so' request <snip several hundred more> mandb: warning: /usr/share/man/man8/saslauthd.8.gz: whatis parse for saslauthd(8) failed mandb: warning: can't update index cache /var/cache/man/index.db: No such file or directory mandb: warning: can't update index cache /var/cache/man/ru.KOI8-R/index.db: No such file or directory mandb: warning: can't update index cache /var/cache/man/id/index.db: No such file or directory mandb: warning: can't update index cache /var/cache/man/de/index.db: No such file or directory mandb: warning: /usr/share/man/jp/man1/cd-paranoia.1.gz: whatis parse for cd-paranoia(1) failed mandb: warning: can't update index cache /var/cache/man/jp/index.db: No such file or directory <snip ~30 more> Any idea what is causing the corruption? -- David C. Rankin, J.D.,P.E.

1 0

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