- Arch-general - lists.archlinux.org

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

[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