From GNUtoo at no-log.org Tue May 1 00:36:58 2018 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Tue, 1 May 2018 02:36:58 +0200 Subject: [Dev] Rework of the ARM installation guide In-Reply-To: <5AE79B03.7050905@gmail.com> References: <20180430145347.37c0c50b@second-laptop.localdomain> <5AE79B03.7050905@gmail.com> Message-ID: <20180501023427.46daa565@second-laptop.localdomain> On Mon, 30 Apr 2018 23:38:59 +0100 Josh Branning wrote: > > This can be done because we now have > > tarball installer releases. > > That is awesome! Was pushing for this! A* Yes, this is great as it makes it way easier to install, and it's also signed, so it fixes a security issue along the way. > Is it just the rootfs or u-boot too? Just a generic rootfs, which makes things easier. > ... If u-boot also, is it just all the u-boot packages installed? I > don't quite comprehend. u-boot is device specific, but you can easily (and transparently) chroot in the unpacked rootfs with arch-chroot from an x86 parabola installation thanks to binfmt-qemu-static, so it's easy to install the bootloader with pacman -S Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From bill-auger at peers.community Tue May 1 07:07:20 2018 From: bill-auger at peers.community (bill-auger) Date: Tue, 01 May 2018 03:07:20 -0400 Subject: [Dev] Rework of the ARM installation guide In-Reply-To: <20180501002838.63cbdcb3@second-laptop.localdomain> References: <20180430145347.37c0c50b@second-laptop.localdomain> <98832134e3d57fbde3fe7295da0483f6b518df92.camel@peers.community> <20180501002838.63cbdcb3@second-laptop.localdomain> Message-ID: On Tue, 2018-05-01 at 00:28 +0200, Denis 'GNUtoo' Carikli wrote: > Why was this approach taken? Is it because there is often only one > storage device (a microSD) which cannot act as an installer/live > system and the system being installed at the same time? i can not say for certain but i assume that is one reason - also it is surely much simpler to clone the image in one command and be done with it - i think wase of use was the prime concern[1] - but there is nothing preventing one from manually partitioning and doing a chroot install the hard way if that is desired for more advanced users but still, you keep using the word "installer" - what you are describing is not an installer - it sounds like what you are describing is a bootable "live" environment - that is not the same as an installer - an installer is a standalone executable or set of scripts that install the system automatically without typing any commands manually - you could have such an installer with or without any live bootable system - the parabola ARM image does not have an installer [1]: https://labs.parabola.nu/issues/1627 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From andreas at grapentin.org Tue May 1 08:48:59 2018 From: andreas at grapentin.org (Andreas Grapentin) Date: Tue, 1 May 2018 10:48:59 +0200 Subject: [Dev] Orphan Pcr package [riscv64-linux-gnu-linux-libre-api-headers] marked out-of-date In-Reply-To: <20180429001352.9751.39103@proton.parabola.nu> References: <20180429001352.9751.39103@proton.parabola.nu> Message-ID: <20180501084859.GA11294@parabola-pocket.localdomain> The riscv64-linux-gnu-* prefixed packages should probably be removed from pcr. They have served their purpose and are now obsolete. Best, -A On Sun, Apr 29, 2018 at 12:13:52AM -0000, Parabola Website Notification wrote: > megver83 at parabola.nu wants to notify you that the following packages may be out-of-date: > > > * riscv64-linux-gnu-linux-libre-api-headers 4.15_gnu-1 [pcr] (any): https://parabolagnulinux.org/packages/pcr/any/riscv64-linux-gnu-linux-libre-api-headers/ > > > The user provided the following additional text: > > Version 4.16 is the latest stable generation and 4.15 reached its EOL > > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev -- ------------------------------------------------------------------------------ my GPG Public Key: https://files.grapentin.org/.gpg/public.key ------------------------------------------------------------------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From andreas at grapentin.org Tue May 1 08:55:22 2018 From: andreas at grapentin.org (Andreas Grapentin) Date: Tue, 1 May 2018 10:55:22 +0200 Subject: [Dev] Rework of the ARM installation guide In-Reply-To: References: <20180430145347.37c0c50b@second-laptop.localdomain> <98832134e3d57fbde3fe7295da0483f6b518df92.camel@peers.community> <20180501002838.63cbdcb3@second-laptop.localdomain> Message-ID: <20180501085522.GB11294@parabola-pocket.localdomain> fwiw, using qemu-user-static it is possible to pacstrap an arm image directly, so the general installation instructions apply 1) partition sdcard 2) pacstrap to sdcard 3) chroot and configure 4) insert and boot Best -A On Tue, May 01, 2018 at 03:07:20AM -0400, bill-auger wrote: > On Tue, 2018-05-01 at 00:28 +0200, Denis 'GNUtoo' Carikli wrote: > > Why was this approach taken? Is it because there is often only one > > storage device (a microSD) which cannot act as an installer/live > > system and the system being installed at the same time? > > i can not say for certain but i assume that is one reason - also it is > surely much simpler to clone the image in one command and be done with > it - i think wase of use was the prime concern[1] - but there is > nothing preventing one from manually partitioning and doing a chroot > install the hard way if that is desired for more advanced users > > but still, you keep using the word "installer" - what you are > describing is not an installer - it sounds like what you are describing > is a bootable "live" environment - that is not the same as an installer > - an installer is a standalone executable or set of scripts that > install the system automatically without typing any commands manually - > you could have such an installer with or without any live bootable > system - the parabola ARM image does not have an installer > > > [1]: https://labs.parabola.nu/issues/1627 > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev -- ------------------------------------------------------------------------------ my GPG Public Key: https://files.grapentin.org/.gpg/public.key ------------------------------------------------------------------------------ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From lukeshu at lukeshu.com Tue May 1 17:57:41 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Tue, 01 May 2018 13:57:41 -0400 Subject: [Dev] dbscripts 20180501 / winston.parabola.nu upgrade In-Reply-To: <87wowpfkq9.wl-lukeshu@lukeshu.com> References: <87y3hcgign.wl-lukeshu@lukeshu.com> <87wowpfkq9.wl-lukeshu@lukeshu.com> Message-ID: <87tvrrfecq.wl-lukeshu@lukeshu.com> I've rolled out version 20180501 of Parabola dbscripts. This is a bugfix release for a bug introduced in 20180425. Changes from 20180429.1 to 20180501: - db-import-pkg: Fix a variable mis-reference (pkgpool->ARCHPKGPOOL) that was introduced in v20180425. This had the result that when Arch Linux released a new version of a package, rather than being updated in our repos, it was removed. This did not affect importing packages from ALARM or Arch Linux 32. On winston.parabola.nu, I have - Upgraded the package On Sun, 29 Apr 2018 23:15:26 -0400, Luke Shumaker wrote: > I have > bumped step 5 ahead of steps 3 & 4 because it entails better logging, > which is very helpful in working through issue #1770 > . ... > I do not believe that issue #1770 is related to the changes made in > step 1, but I am not sure of that. I was wrong, it was directly caused by a mistake in the main commit implementing step 1. -- Happy hacking, ~ Luke Shumaker From megver83 at hyperbola.info Tue May 1 20:16:16 2018 From: megver83 at hyperbola.info (Megver83) Date: Tue, 1 May 2018 17:16:16 -0300 Subject: [Dev] Rework of the ARM installation guide In-Reply-To: <20180501085522.GB11294@parabola-pocket.localdomain> References: <20180430145347.37c0c50b@second-laptop.localdomain> <98832134e3d57fbde3fe7295da0483f6b518df92.camel@peers.community> <20180501002838.63cbdcb3@second-laptop.localdomain> <20180501085522.GB11294@parabola-pocket.localdomain> Message-ID: <8b84644a-58b9-8c11-a345-405ea572e4be@hyperbola.info> El 01/05/18 a las 05:55, Andreas Grapentin escribi?: > > fwiw, using qemu-user-static it is possible to pacstrap an arm image > directly, so the general installation instructions apply > > 1) partition sdcard > 2) pacstrap to sdcard > 3) chroot and configure > 4) insert and boot > > Best > -A > What a smart hack! I agree with this installation method. It's better than making ARM rootfs tarballs IMO, and idk why no one else thought on this (this could be even done from an x86 install ISO). Could you add an entry about this in the ARM installation guide, plz? -- ~Megver83 SIP: megver83 at sip.linphone.org XMPP: megver83 at jabjab.de Tox: megver83 at toxme.io GPG: 0x227CA7C556B2BA78 GNUSocial: @megver82 at quitter.cl Diaspora*: megver83 at diasp.org Matrix: @Megver83:matrix.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 520 bytes Desc: OpenPGP digital signature URL: From bill-auger at peers.community Tue May 1 20:17:08 2018 From: bill-auger at peers.community (bill-auger) Date: Tue, 01 May 2018 16:17:08 -0400 Subject: [Dev] Rework of the ARM installation guide In-Reply-To: <8b84644a-58b9-8c11-a345-405ea572e4be@hyperbola.info> References: <20180430145347.37c0c50b@second-laptop.localdomain> <98832134e3d57fbde3fe7295da0483f6b518df92.camel@peers.community> <20180501002838.63cbdcb3@second-laptop.localdomain> <20180501085522.GB11294@parabola-pocket.localdomain> <8b84644a-58b9-8c11-a345-405ea572e4be@hyperbola.info> Message-ID: isnt that just the typical way of doing it? wasnt that exactly how it was done before the tarball was released? as i understand, the reason for the tarball was to make it even easier than the chroot install - so that one could simple dd and boot it -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From megver83 at hyperbola.info Tue May 1 21:20:39 2018 From: megver83 at hyperbola.info (Megver83) Date: Tue, 1 May 2018 18:20:39 -0300 Subject: [Dev] Rework of the ARM installation guide In-Reply-To: References: <20180430145347.37c0c50b@second-laptop.localdomain> <98832134e3d57fbde3fe7295da0483f6b518df92.camel@peers.community> <20180501002838.63cbdcb3@second-laptop.localdomain> <20180501085522.GB11294@parabola-pocket.localdomain> <8b84644a-58b9-8c11-a345-405ea572e4be@hyperbola.info> Message-ID: El 01/05/18 a las 17:17, bill-auger escribi?: > isnt that just the typical way of doing it? wasnt that exactly how it > was done before the tarball was released? as i understand, the reason > for the tarball was to make it even easier than the chroot install - so > that one could simple dd and boot it > > > > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev > Yea, we did that way, but without qemu, which gave some errors -- ~Megver83 SIP: megver83 at sip.linphone.org XMPP: megver83 at jabjab.de Tox: megver83 at toxme.io GPG: 0x227CA7C556B2BA78 GNUSocial: @megver82 at quitter.cl Diaspora*: megver83 at diasp.org Matrix: @Megver83:matrix.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 520 bytes Desc: OpenPGP digital signature URL: From GNUtoo at no-log.org Tue May 1 21:38:02 2018 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Tue, 1 May 2018 23:38:02 +0200 Subject: [Dev] Rework of the ARM installation guide In-Reply-To: <20180501085522.GB11294@parabola-pocket.localdomain> References: <20180430145347.37c0c50b@second-laptop.localdomain> <98832134e3d57fbde3fe7295da0483f6b518df92.camel@peers.community> <20180501002838.63cbdcb3@second-laptop.localdomain> <20180501085522.GB11294@parabola-pocket.localdomain> Message-ID: <20180501233802.43087704@second-laptop.localdomain> On Tue, 1 May 2018 10:55:22 +0200 Andreas Grapentin wrote: > fwiw, using qemu-user-static it is possible to pacstrap an arm image > directly, so the general installation instructions apply > > 1) partition sdcard > 2) pacstrap to sdcard > 3) chroot and configure > 4) insert and boot I'm now merging both as only the second step has to differ. Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From lovell.joshyyy at gmail.com Tue May 1 21:58:33 2018 From: lovell.joshyyy at gmail.com (Josh Branning) Date: Tue, 1 May 2018 22:58:33 +0100 Subject: [Dev] Rework of the ARM installation guide In-Reply-To: References: <20180430145347.37c0c50b@second-laptop.localdomain> <98832134e3d57fbde3fe7295da0483f6b518df92.camel@peers.community> <20180501002838.63cbdcb3@second-laptop.localdomain> <20180501085522.GB11294@parabola-pocket.localdomain> <8b84644a-58b9-8c11-a345-405ea572e4be@hyperbola.info> Message-ID: <5AE8E309.2010701@gmail.com> +1 this was the primary reason I wanted a tarball. The main difficulty is you have to have a parabola machine or a machine with pacstrap in order to install on ARM, rather than a machine with just dd or the like. As much as I like parabola and hope everyone installs, 'normal' people who use other distros, or use a different distro as their main driver, who wish to install on ARM, perhaps just to test or whatever, may find it easier if they can just copy the contents of an archive to sd and boot. On 01/05/18 21:17, bill-auger wrote: > isnt that just the typical way of doing it? wasnt that exactly how it > was done before the tarball was released? as i understand, the reason > for the tarball was to make it even easier than the chroot install - so > that one could simple dd and boot it > > > > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev > From lovell.joshyyy at gmail.com Tue May 1 23:38:02 2018 From: lovell.joshyyy at gmail.com (Josh Branning) Date: Wed, 2 May 2018 00:38:02 +0100 Subject: [Dev] Rework of the ARM installation guide In-Reply-To: References: <20180430145347.37c0c50b@second-laptop.localdomain> <98832134e3d57fbde3fe7295da0483f6b518df92.camel@peers.community> <20180501002838.63cbdcb3@second-laptop.localdomain> <20180501085522.GB11294@parabola-pocket.localdomain> <8b84644a-58b9-8c11-a345-405ea572e4be@hyperbola.info> Message-ID: <5AE8FA5A.1040609@gmail.com> For instance something like this, but maybe a bit better written? #!/bin/bash #fill in these variables uboot_package_name="uboot4extlinux-a10-olinuxino-lime" drive="/dev/mmcblk0" ext_partition="/dev/mmcblk0p1" #script starts here mkdir workdir cd workdir wget --content-disposition "https://www.parabola.nu/packages/libre/armv7h/${uboot_package_name}/download/" tar -xf uboot4extlinux-* cp -a -n boot "${ext_partition}" chmod +x ./.INSTALL source ./.INSTALL echo "N" | flash_uboot | while read -r line; do if [ "$(echo $line | cut -c 1-4)" == "# dd" ]; then $(echo $line | cut -c 3- | sed -e 's/\/boot/boot/g' | sed -e "s|\/dev\/mmcblk0|${drive}|g"); fi; done On 01/05/18 21:17, bill-auger wrote: > isnt that just the typical way of doing it? wasnt that exactly how it > was done before the tarball was released? as i understand, the reason > for the tarball was to make it even easier than the chroot install - so > that one could simple dd and boot it > > > > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev > From lovell.joshyyy at gmail.com Tue May 1 23:52:53 2018 From: lovell.joshyyy at gmail.com (Josh Branning) Date: Wed, 2 May 2018 00:52:53 +0100 Subject: [Dev] Rework of the ARM installation guide In-Reply-To: <5AE8FA5A.1040609@gmail.com> References: <20180430145347.37c0c50b@second-laptop.localdomain> <98832134e3d57fbde3fe7295da0483f6b518df92.camel@peers.community> <20180501002838.63cbdcb3@second-laptop.localdomain> <20180501085522.GB11294@parabola-pocket.localdomain> <8b84644a-58b9-8c11-a345-405ea572e4be@hyperbola.info> <5AE8FA5A.1040609@gmail.com> Message-ID: <5AE8FDD5.2010609@gmail.com> ... better written could mean adding a function to the .INSTALL files perhaps. I'll be quiet now. On 02/05/18 00:38, Josh Branning wrote: > For instance something like this, but maybe a bit better written? > > #!/bin/bash > #fill in these variables > uboot_package_name="uboot4extlinux-a10-olinuxino-lime" > drive="/dev/mmcblk0" > ext_partition="/dev/mmcblk0p1" > > #script starts here > mkdir workdir > cd workdir > wget --content-disposition > "https://www.parabola.nu/packages/libre/armv7h/${uboot_package_name}/download/" > > tar -xf uboot4extlinux-* > cp -a -n boot "${ext_partition}" > chmod +x ./.INSTALL > source ./.INSTALL > echo "N" | flash_uboot | while read -r line; do if [ "$(echo $line | cut > -c 1-4)" == "# dd" ]; then $(echo $line | cut -c 3- | sed -e > 's/\/boot/boot/g' | sed -e "s|\/dev\/mmcblk0|${drive}|g"); fi; done > > > On 01/05/18 21:17, bill-auger wrote: >> isnt that just the typical way of doing it? wasnt that exactly how it >> was done before the tarball was released? as i understand, the reason >> for the tarball was to make it even easier than the chroot install - so >> that one could simple dd and boot it >> >> >> >> _______________________________________________ >> Dev mailing list >> Dev at lists.parabola.nu >> https://lists.parabola.nu/mailman/listinfo/dev >> > From nobody at parabola.nu Wed May 2 02:49:17 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 02 May 2018 02:49:17 -0000 Subject: [Dev] Orphan Libre package [iceweasel] marked out-of-date Message-ID: <20180502024917.1370.14402@proton.parabola.nu> eliotreyna at cock.email wants to notify you that the following packages may be out-of-date: * iceweasel 1:59.0.2-3 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/iceweasel/ * iceweasel 1:59.0.2-3 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/iceweasel/ The user provided the following additional text: Please update the Iceweasel to the version 59.0.3, according to the Firefox source code. The following bugfix solves a SyntaxError that can affect the browsing experience. See >> https://bugzilla.mozilla.org/show_bug.cgi?id=1452619 Please note that the bugfix highlights that only affects to Windows build. However, it can affect in an hypotethic case that Iceweasel could be cross-compiled for Windows plattform. Thanks. From nobody at parabola.nu Wed May 2 02:50:23 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 02 May 2018 02:50:23 -0000 Subject: [Dev] Orphan Libre package [iceweasel-l10n-es-ar] marked out-of-date Message-ID: <20180502025023.1368.11898@proton.parabola.nu> eliotreyna at cock.email wants to notify you that the following packages may be out-of-date: * iceweasel-l10n-ach 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ach/ * iceweasel-l10n-af 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-af/ * iceweasel-l10n-an 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-an/ * iceweasel-l10n-ar 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ar/ * iceweasel-l10n-as 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-as/ * iceweasel-l10n-ast 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ast/ * iceweasel-l10n-az 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-az/ * iceweasel-l10n-be 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-be/ * iceweasel-l10n-bg 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-bg/ * iceweasel-l10n-bn-bd 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-bn-bd/ * iceweasel-l10n-bn-in 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-bn-in/ * iceweasel-l10n-br 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-br/ * iceweasel-l10n-bs 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-bs/ * iceweasel-l10n-ca 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ca/ * iceweasel-l10n-cak 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-cak/ * iceweasel-l10n-cs 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-cs/ * iceweasel-l10n-cy 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-cy/ * iceweasel-l10n-da 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-da/ * iceweasel-l10n-de 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-de/ * iceweasel-l10n-dsb 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-dsb/ * iceweasel-l10n-el 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-el/ * iceweasel-l10n-en-gb 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-en-gb/ * iceweasel-l10n-en-us 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-en-us/ * iceweasel-l10n-en-za 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-en-za/ * iceweasel-l10n-eo 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-eo/ * iceweasel-l10n-es-ar 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-es-ar/ * iceweasel-l10n-es-cl 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-es-cl/ * iceweasel-l10n-es-es 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-es-es/ * iceweasel-l10n-es-mx 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-es-mx/ * iceweasel-l10n-et 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-et/ * iceweasel-l10n-eu 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-eu/ * iceweasel-l10n-fa 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-fa/ * iceweasel-l10n-ff 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ff/ * iceweasel-l10n-fi 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-fi/ * iceweasel-l10n-fr 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-fr/ * iceweasel-l10n-fy-nl 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-fy-nl/ * iceweasel-l10n-ga-ie 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ga-ie/ * iceweasel-l10n-gd 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-gd/ * iceweasel-l10n-gl 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-gl/ * iceweasel-l10n-gn 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-gn/ * iceweasel-l10n-gu-in 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-gu-in/ * iceweasel-l10n-he 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-he/ * iceweasel-l10n-hi-in 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-hi-in/ * iceweasel-l10n-hr 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-hr/ * iceweasel-l10n-hsb 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-hsb/ * iceweasel-l10n-hu 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-hu/ * iceweasel-l10n-hy-am 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-hy-am/ * iceweasel-l10n-ia 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ia/ * iceweasel-l10n-id 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-id/ * iceweasel-l10n-is 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-is/ * iceweasel-l10n-it 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-it/ * iceweasel-l10n-ja 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ja/ * iceweasel-l10n-ka 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ka/ * iceweasel-l10n-kab 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-kab/ * iceweasel-l10n-kk 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-kk/ * iceweasel-l10n-km 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-km/ * iceweasel-l10n-kn 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-kn/ * iceweasel-l10n-ko 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ko/ * iceweasel-l10n-lij 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-lij/ * iceweasel-l10n-lt 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-lt/ * iceweasel-l10n-lv 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-lv/ * iceweasel-l10n-mai 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-mai/ * iceweasel-l10n-mk 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-mk/ * iceweasel-l10n-ml 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ml/ * iceweasel-l10n-mr 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-mr/ * iceweasel-l10n-ms 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ms/ * iceweasel-l10n-my 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-my/ * iceweasel-l10n-nb-no 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-nb-no/ * iceweasel-l10n-ne-np 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ne-np/ * iceweasel-l10n-nl 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-nl/ * iceweasel-l10n-nn-no 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-nn-no/ * iceweasel-l10n-or 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-or/ * iceweasel-l10n-pa-in 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-pa-in/ * iceweasel-l10n-pl 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-pl/ * iceweasel-l10n-pt-br 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-pt-br/ * iceweasel-l10n-pt-pt 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-pt-pt/ * iceweasel-l10n-rm 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-rm/ * iceweasel-l10n-ro 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ro/ * iceweasel-l10n-ru 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ru/ * iceweasel-l10n-si 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-si/ * iceweasel-l10n-sk 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-sk/ * iceweasel-l10n-sl 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-sl/ * iceweasel-l10n-son 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-son/ * iceweasel-l10n-sq 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-sq/ * iceweasel-l10n-sr 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-sr/ * iceweasel-l10n-sv-se 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-sv-se/ * iceweasel-l10n-ta 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ta/ * iceweasel-l10n-te 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-te/ * iceweasel-l10n-th 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-th/ * iceweasel-l10n-tr 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-tr/ * iceweasel-l10n-uk 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-uk/ * iceweasel-l10n-ur 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-ur/ * iceweasel-l10n-uz 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-uz/ * iceweasel-l10n-vi 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-vi/ * iceweasel-l10n-xh 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-xh/ * iceweasel-l10n-zh-cn 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-zh-cn/ * iceweasel-l10n-zh-tw 1:59.0.2-1 [libre] (any): https://parabolagnulinux.org/packages/libre/any/iceweasel-l10n-zh-tw/ The user provided the following additional text: Please update the Iceweasel language pack to the version 59.0.3, according to the Firefox source code. The following bugfix solves a SyntaxError that can affect the browsing experience. See >> https://bugzilla.mozilla.org/show_bug.cgi?id=1452619 Please note that the bugfix highlights that only affects to Windows build. However, it can affect in an hypotethic case that Iceweasel could be cross-compiled for Windows plattform. Thanks. From lukeshu at lukeshu.com Wed May 2 16:00:04 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Wed, 02 May 2018 12:00:04 -0400 Subject: [Dev] dbscripts 20180502 / winston.parabola.nu upgrade In-Reply-To: <87y3hcgign.wl-lukeshu@lukeshu.com> References: <87y3hcgign.wl-lukeshu@lukeshu.com> Message-ID: <87o9hyf3p7.wl-lukeshu@lukeshu.com> I've rolled out version 20180502 of Parabola dbscripts. Changes from 20180501 to 20180502: - db-import-archlinux-any-to-ours: * Delete this program - db-import-pkg: * Preserve file permissions when copying .db files in to place * Don't change repo-remove's output * Log full output from `repo-add` * Miscellaneous tidy-up - db-import-*: * Merge the 'ARCHREPOS' and 'ARCHARCHES' config items in to 'ARCHTAGS'. * Merge the 'mirror' and 'mirrorpath' config items in to 'ARCHMIRROR'. On winston.parabola.nu, I have - run: sudo pacman -Syu --ignore={linux-libre-lts,python-pyspf} The big item here is that this completes the umask change introduced in 20180429, in preparation for adjusting the user permissions on the repos (step 3 of my plan for improving dbscripts). [X] 1. Split archlinux -> {packages,community} [X] 2. Add config.local.* files [-] 3. Set up the `repo` group [eta: 2018-05-04] [ ] 4. Set DBSCRIPTS_CONFIG [eta: 2018-05-04] [X] 5. Use systemd timers [ ] 6. Use db-update [eta: 2018-05-05] [ ] 7. Migrate humans off of repo@ [eta: no sooner than 2018-05-11] [ ] 8. Migrate robots off of repo@ [eta: no sooner than 2018-05-18] The fact that the umask changed introduced in 20180429 didn't "stick" means that I need to wait a bit longer before performing step 3, delaying the entire schedule a bit. Sometime soon I'll be posting a report of files with funny ownership/permissions that we need to figure out why they are that way (Chesterton's fence). -- Happy hacking, ~ Luke Shumaker From lukeshu at lukeshu.com Wed May 2 17:50:38 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Wed, 02 May 2018 13:50:38 -0400 Subject: [Dev] dbscripts 20180502 / winston.parabola.nu upgrade In-Reply-To: <87o9hyf3p7.wl-lukeshu@lukeshu.com> References: <87y3hcgign.wl-lukeshu@lukeshu.com> <87o9hyf3p7.wl-lukeshu@lukeshu.com> Message-ID: <87lgd2eykx.wl-lukeshu@lukeshu.com> On Wed, 02 May 2018 12:00:04 -0400, Luke Shumaker wrote: > - db-import-pkg: > * Preserve file permissions when copying .db files in to place ... > The big item here is that this completes the umask change introduced > in 20180429, in preparation for adjusting the user permissions on the > repos (step 3 of my plan for improving dbscripts). > > [X] 1. Split archlinux -> {packages,community} > [X] 2. Add config.local.* files > [-] 3. Set up the `repo` group [eta: 2018-05-04] > [ ] 4. Set DBSCRIPTS_CONFIG [eta: 2018-05-04] > [X] 5. Use systemd timers > [ ] 6. Use db-update [eta: 2018-05-05] > [ ] 7. Migrate humans off of repo@ [eta: no sooner than 2018-05-11] > [ ] 8. Migrate robots off of repo@ [eta: no sooner than 2018-05-18] > > The fact that the umask changed introduced in 20180429 didn't "stick" > means that I need to wait a bit longer before performing step 3, > delaying the entire schedule a bit. So, it still didn't take. I think maybe #6 will get bumped ahead of #3? I had thought that #3 would be very simple. -- Happy hacking, ~ Luke Shumaker From lukeshu at lukeshu.com Thu May 3 03:18:47 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Wed, 02 May 2018 23:18:47 -0400 Subject: [Dev] dbscripts 20180502 / winston.parabola.nu upgrade In-Reply-To: <87lgd2eykx.wl-lukeshu@lukeshu.com> References: <87y3hcgign.wl-lukeshu@lukeshu.com> <87o9hyf3p7.wl-lukeshu@lukeshu.com> <87lgd2eykx.wl-lukeshu@lukeshu.com> Message-ID: <87k1slfmug.wl-lukeshu@lukeshu.com> On Wed, 02 May 2018 13:50:38 -0400, Luke Shumaker wrote: > > On Wed, 02 May 2018 12:00:04 -0400, > Luke Shumaker wrote: > > - db-import-pkg: > > * Preserve file permissions when copying .db files in to place > ... > > The big item here is that this completes the umask change introduced > > in 20180429, in preparation for adjusting the user permissions on the > > repos (step 3 of my plan for improving dbscripts). > > > > [X] 1. Split archlinux -> {packages,community} > > [X] 2. Add config.local.* files > > [-] 3. Set up the `repo` group [eta: 2018-05-04] > > [ ] 4. Set DBSCRIPTS_CONFIG [eta: 2018-05-04] > > [X] 5. Use systemd timers > > [ ] 6. Use db-update [eta: 2018-05-05] > > [ ] 7. Migrate humans off of repo@ [eta: no sooner than 2018-05-11] > > [ ] 8. Migrate robots off of repo@ [eta: no sooner than 2018-05-18] > > > > The fact that the umask changed introduced in 20180429 didn't "stick" > > means that I need to wait a bit longer before performing step 3, > > delaying the entire schedule a bit. > > So, it still didn't take. > > I think maybe #6 will get bumped ahead of #3? > I had thought that #3 would be very simple. I said I'd forget about it for a while and move on to #6, but I'm apparently bad at forgetting about things I say I will. So I ended up tearing my hair out figuring out what was going on. It turned out that repo-add sets `umask 022`, disregarding what we do... so how does db-functions work!? Somehow, in my thickheaded-ness, I missed db-functions:set_repo_permissions(). So I'm not entirely sure what the point of setting `umask 002` is, since I'm pretty sure that the .db files are the only files modified in a place where it would affect anything. So... I guess this means that I either need to load db-functions in db-import-pkg (to call set_repo_permissions), or I can wait for step #6 and get it for free. -- Happy hacking, ~ Luke Shumaker From GNUtoo at no-log.org Fri May 4 07:59:23 2018 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Fri, 4 May 2018 09:59:23 +0200 Subject: [Dev] Rework of the ARM installation guide In-Reply-To: <5AE8FDD5.2010609@gmail.com> References: <20180430145347.37c0c50b@second-laptop.localdomain> <98832134e3d57fbde3fe7295da0483f6b518df92.camel@peers.community> <20180501002838.63cbdcb3@second-laptop.localdomain> <20180501085522.GB11294@parabola-pocket.localdomain> <8b84644a-58b9-8c11-a345-405ea572e4be@hyperbola.info> <5AE8FA5A.1040609@gmail.com> <5AE8FDD5.2010609@gmail.com> Message-ID: <20180504095923.1daed682@second-laptop.localdomain> On Wed, 2 May 2018 00:52:53 +0100 Josh Branning wrote: > ... better written could mean adding a function to the .INSTALL files > perhaps. This would be much better as it would handle better the installation from another distributions like Trisquel and will have the signatures checked. Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From GNUtoo at no-log.org Fri May 4 07:56:57 2018 From: GNUtoo at no-log.org (Denis 'GNUtoo' Carikli) Date: Fri, 4 May 2018 09:56:57 +0200 Subject: [Dev] Rework of the ARM installation guide In-Reply-To: <5AE8FA5A.1040609@gmail.com> References: <20180430145347.37c0c50b@second-laptop.localdomain> <98832134e3d57fbde3fe7295da0483f6b518df92.camel@peers.community> <20180501002838.63cbdcb3@second-laptop.localdomain> <20180501085522.GB11294@parabola-pocket.localdomain> <8b84644a-58b9-8c11-a345-405ea572e4be@hyperbola.info> <5AE8FA5A.1040609@gmail.com> Message-ID: <20180504095657.620f735c@second-laptop.localdomain> On Wed, 2 May 2018 00:38:02 +0100 Josh Branning wrote: > For instance something like this, but maybe a bit better written? > > #!/bin/bash > #fill in these variables > uboot_package_name="uboot4extlinux-a10-olinuxino-lime" > drive="/dev/mmcblk0" > ext_partition="/dev/mmcblk0p1" > > #script starts here > mkdir workdir > cd workdir > wget --content-disposition > "https://www.parabola.nu/packages/libre/armv7h/${uboot_package_name}/download/" > tar -xf uboot4extlinux-* > cp -a -n boot "${ext_partition}" > chmod +x ./.INSTALL > source ./.INSTALL > echo "N" | flash_uboot | while read -r line; do if [ "$(echo $line | > cut -c 1-4)" == "# dd" ]; then $(echo $line | cut -c 3- | sed -e > 's/\/boot/boot/g' | sed -e "s|\/dev\/mmcblk0|${drive}|g"); fi; done The issue here is that no signatures have been verified. In order to verify signatures and be able to easily add support for other host distributions such as Trisquel (which doesn't have pacman but does have chroot), I think it's better to do that with chroot / arch-chroot and pacman -S uboot4extlinux-a10-olinuxino-lime Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From lukeshu at lukeshu.com Sat May 5 15:35:53 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Sat, 05 May 2018 11:35:53 -0400 Subject: [Dev] dbscripts 20180505 / winston.parabola.nu upgrade In-Reply-To: <87y3hcgign.wl-lukeshu@lukeshu.com> References: <87y3hcgign.wl-lukeshu@lukeshu.com> Message-ID: <87h8nmf73a.wl-lukeshu@lukeshu.com> I've rolled out version 20180505 of Parabola dbscripts. Changes from 20180502.2 to 20180505: - default config: * Set TMPDIR=/srv/repo/tmp - db-import-*.conf: * Include the path to repo directories in the mirror URL, like ARCHMIRROR='rsync://archlinux.mirror.pkern.at/archlinux/$repo/os/$arch' - db-import-pkg: * Use `join` instead of `repo-remove` to apply the blacklist. This should speed things up, and start us on a path where we can use db-{move,update,remove} to modify the repos. * Try a bit harder to get .db file permissions right. * Do more work in a fresh scratch directory instead of in the repos directly, or in a dirty scratch directory. On winston.parabola.nu, I have - run: sudo pacman -Syu --ignore={linux-libre-lts,python-pyspf} These changes both toward both step #3 and #6 in my plan for improving dbscripts. [X] 1. Split archlinux -> {packages,community} [X] 2. Add config.local.* files [-] 3. Set up the `repo` group [eta: 2018-05-07] [ ] 4. Set DBSCRIPTS_CONFIG [eta: 2018-05-07] [X] 5. Use systemd timers [-] 6. Use db-{move,update,remove} [eta: ???] [ ] 7. Migrate humans off of repo@ [eta: no sooner than 2018-05-11] [ ] 8. Migrate robots off of repo@ [eta: no sooner than 2018-05-18] My last estimate said that step #3 and #4 would be done today. Hopefully tomorrow the new db-import-pkg will have resolved many of the anomalies, and we can get the rest resolved manually, and go forward with step #3 on Monday. Step #6 is blocked because it needs db-move, which is currently broken . So I'm not sure what the timeline is on that now. Maybe give up on step #6 for this sprint. Steps #7 and #8 depend on #3 and #4, but we can get away with doing them without #6. So I'm not adjusting my estimates on them. -- Happy hacking, ~ Luke Shumaker From megver83 at hyperbola.info Sat May 5 20:52:12 2018 From: megver83 at hyperbola.info (Megver83) Date: Sat, 5 May 2018 17:52:12 -0300 Subject: [Dev] Orphan Pcr package [riscv64-linux-gnu-linux-libre-api-headers] marked out-of-date In-Reply-To: <20180501084859.GA11294@parabola-pocket.localdomain> References: <20180429001352.9751.39103@proton.parabola.nu> <20180501084859.GA11294@parabola-pocket.localdomain> Message-ID: <22ecaaba-c9fd-7f00-0ae0-6bcb09e0a7c6@hyperbola.info> El 01/05/18 a las 05:48, Andreas Grapentin escribi?: > > The riscv64-linux-gnu-* prefixed packages should probably be removed > from pcr. They have served their purpose and are now obsolete. > > Best, > -A > I think that cross-compilers (for testing/porting purposes, not as makedepends of a [pcr] or [libre] pkg) should go to [cross]. I've recently cleaned it (there were many outdated and unused cross-compilers) The base PKGBUILDs for toolchains are at the abslibre.git named cross-{gcc,binutils,newlib} -- ~Megver83 SIP: megver83 at sip.linphone.org XMPP: megver83 at jabjab.de Tox: megver83 at toxme.io GPG: 0x227CA7C556B2BA78 GNUSocial: @megver82 at quitter.cl Diaspora*: megver83 at diasp.org Matrix: @Megver83:matrix.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 520 bytes Desc: OpenPGP digital signature URL: From nobody at parabola.nu Sun May 6 14:42:50 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Sun, 06 May 2018 14:42:50 -0000 Subject: [Dev] Orphan Kernels package [linux-libre-lts-xtreme] marked out-of-date Message-ID: <20180506144250.1368.27496@proton.parabola.nu> odg at riseup.net wants to notify you that the following packages may be out-of-date: The user provided the following additional text: Is there a reason this isn't on the 4.14.x series yet, like linux-libre-lts? If there is, sorry, ignore this :) From megver83 at hyperbola.info Mon May 7 14:05:34 2018 From: megver83 at hyperbola.info (Megver83) Date: Mon, 7 May 2018 11:05:34 -0300 Subject: [Dev] Orphan Kernels package [linux-libre-lts-xtreme] marked out-of-date In-Reply-To: <20180506144250.1368.27496@proton.parabola.nu> References: <20180506144250.1368.27496@proton.parabola.nu> Message-ID: <4c05540c-c17d-d1a1-66b1-6de2fcc10b64@hyperbola.info> El 06/05/18 a las 11:42, Parabola Website Notification escribi?: > odg at riseup.net wants to notify you that the following packages may be out-of-date: > > > > > The user provided the following additional text: > > Is there a reason this isn't on the 4.14.x series yet, like linux-libre-lts? > If there is, sorry, ignore this :) > Simply because the knock patch is not for 4.14. Plus, 4.9 is still maintained. -- ~Megver83 SIP: megver83 at sip.linphone.org XMPP: megver83 at jabjab.de Tox: megver83 at toxme.io GPG: 0x227CA7C556B2BA78 GNUSocial: @megver82 at quitter.cl Diaspora*: megver83 at diasp.org Matrix: @Megver83:matrix.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 520 bytes Desc: OpenPGP digital signature URL: From nospam at curso.re Mon May 7 21:43:01 2018 From: nospam at curso.re (Stefano M.) Date: Mon, 07 May 2018 22:43:01 +0100 Subject: [Dev] Fail to update gksu & libgksu due to unknown trust signature Message-ID: <87fu33ta56.fsf@example.com> Hello, I have recently started to hit the followint problem when running pacman -Syu error: libgksu: signature from "bill-auger " is unknown trust :: File /var/cache/pacman/pkg/libgksu-2.0.12-8.parabola1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] I tried to refresh my gpg keys and run pacman-key -u to no avail. pacman-key -l shows the following pub rsa2048 2016-11-30 [SCEA] [expires: 2018-12-01] 3954A7AB837D0EA9CFA9798925DB7D9B5A8D4B40 uid [ full ] bill-auger uid [ full ] bill-auger uid [ full ] bill-auger uid [ full ] [jpeg image of size 6017] sub rsa2048 2016-11-30 [SEA] [expires: 2018-12-01] So I'm a bit confused. Any pointers are appreciated. Thanks! From bill-auger at peers.community Mon May 7 22:06:04 2018 From: bill-auger at peers.community (bill-auger) Date: Mon, 7 May 2018 18:06:04 -0400 Subject: [Dev] Fail to update gksu & libgksu due to unknown trust signature In-Reply-To: <87fu33ta56.fsf@example.com> References: <87fu33ta56.fsf@example.com> Message-ID: you probably just need to run this one command $ sudo pacman-key --refresh-keys if that does not work, run the commands in section #1 on this wiki page: https://wiki.parabola.nu/Parabola_Keyring -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lukeshu at lukeshu.com Tue May 8 01:02:26 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Mon, 07 May 2018 21:02:26 -0400 Subject: [Dev] dbscripts 20180507.1 / winston.parabola.nu upgrade In-Reply-To: <87y3hcgign.wl-lukeshu@lukeshu.com> References: <87y3hcgign.wl-lukeshu@lukeshu.com> Message-ID: <87a7tbez8d.wl-lukeshu@lukeshu.com> I've rolled out version 20180507.1 of Parabola dbscripts. This announcement describes both 20180507 and 20180507.1. Version 20180507 was *almost* merely a minor bugfix release over 20170505. Fixes from 20180505 to 20180507: - config: * export TMPDIR (otherwise it is ignored in most cases) - db-import-archlinux{32,arm}.conf: * fix default values for ARCHMIRROR - db-import-pkg: * fix symlinks used for running repo-add * fix the pool name used in a user message Actual changes from 20180505 to 20180507: - db-import-pkg: * make it an error (instead of a warning) if we can't find a package file (intended to help catch the bugs fixed above) However, it turns out that that final change means that we started catching bugs that have "always" had. Version 20180507.1 then proceeds to fix those. Changes from 20180507 to 20180507.1: - db-import-pkg: * Rewrite the algorithm used to look up the pkgpool to use for a package when importing from archlinux{32,arm}. On winston.parabola.nu, I have - Restored 'any' and 'i686' files in the [community] and [packages] pools from a 2018-05-04 backup, to fix breakage caused by db-cleanup running while the repos were otherwise broken because of 20180505's db-import-pkg. - run: sudo pacman -Syu --ignore={linux-libre-lts,python-pyspf} - run: sudo systemctl restart db-import at archlinux{32,arm}.service At this point, I think I should not touch anything for a few days, to make sure that everything is running smoothly. I appologize for the breakage this caused this weekend. -- Happy hacking, ~ Luke Shumaker From megver83 at hyperbola.info Tue May 8 18:57:54 2018 From: megver83 at hyperbola.info (Megver83) Date: Tue, 8 May 2018 15:57:54 -0300 Subject: [Dev] [RFC] [nonsystemd] repository, packages built without systemd support Message-ID: Hi all, I just created a new (experimental) repository named [nonsystemd] (the folder at /srv/repo/main seems to be there since 2015 so I decided to use it) and my idea was to do the same as [nonprism], but applied to systemd. So, as in [nonprism] we build packages without support for nonfree or privacy-dangerous services/protocols, [nonsystemd] packages would have packages built without systemd support (so we don't have to create -nosystemd packages). I thought also on creating your-initfreedom or sth. like that, which conflicts with systemd and its friends: netctl, libsystemd, libsystemd-standalone, systemd-kcm, python-systemd, nss-{resolv,systemd}, etc. (we can add the list on blacklist.git too) As of now, [nonsystemd] has a version of mkinitcpio taken from Artix. I don't think it's necessary to put "$pkgdesc, without systemd support" in the PKGBUILDs since the repository name says everything. -- ~Megver83 SIP: megver83 at sip.linphone.org XMPP: megver83 at jabjab.de Tox: megver83 at toxme.io GPG: 0x227CA7C556B2BA78 GNUSocial: @megver82 at quitter.cl Diaspora*: megver83 at diasp.org Matrix: @Megver83:matrix.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 520 bytes Desc: OpenPGP digital signature URL: From bill-auger at peers.community Tue May 8 19:12:04 2018 From: bill-auger at peers.community (bill-auger) Date: Tue, 8 May 2018 15:12:04 -0400 Subject: [Dev] [RFC] [nonsystemd] repository, packages built without systemd support In-Reply-To: References: Message-ID: you would know best how problematic is may be to keep all these "foo-openrc" alternatives around - the one thing i would add is that the other "your-whatever" meta packages off replacements for the essential things that they remove - in the case of your-initfreedom that would currently need to be everything that is now a *-openrc packages - but would that not make it problematic to add other inits or replace openrc entirely? - "anti-systemd" is not the same as "init freedom" - for freedom you need to be able to move freely - this sounds like locking in either systemd or openrc with no room for anything else i like the idea of trying shepherd for example - but how would that fit into this scheme? - if all non-systemd inits were lumped together then there still need to be a slew of *-openrc and *-shepherd packages analogous to their *-system counterparts - so maybe not much is gained by this practically speaking -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From megver83 at hyperbola.info Tue May 8 19:29:54 2018 From: megver83 at hyperbola.info (Megver83) Date: Tue, 8 May 2018 16:29:54 -0300 Subject: [Dev] [RFC] [nonsystemd] repository, packages built without systemd support In-Reply-To: References: Message-ID: <0253a21e-7775-4d8c-35da-25510f829bb6@hyperbola.info> El 08/05/18 a las 16:12, bill-auger escribi?: > you would know best how problematic is may be to keep all these > "foo-openrc" alternatives around - the one thing i would add is that the > other "your-whatever" meta packages off replacements for the essential > things that they remove - in the case of your-initfreedom that would > currently need to be everything that is now a *-openrc packages - but > would that not make it problematic to add other inits or replace openrc > entirely? - "anti-systemd" is not the same as "init freedom" - for > freedom you need to be able to move freely - this sounds like locking in > either systemd or openrc with no room for anything else Let's clarify things: If anyone doesn't want systemd on its system, he/she is free to remove it *completely*. Period. Current Parabola OpenRC users have to use eudev-systemd and libeudev-systemd so packages built for systemd can run. And any user is free to enable or disable [nonsystemd] repo. Second, your-initfreedom won't remove core packages. I mean, it for some reason there's a very important package that cannot have a nonsystemd version and has a hard-depend on systemd (which, afaik, there aren't), of course I will not put it there. Not having systemd does not mean breaking your system to make it disappear. > > i like the idea of trying shepherd for example - but how would that fit > into this scheme? - if all non-systemd inits were lumped together then > there still need to be a slew of *-openrc and *-shepherd packages > analogous to their *-system counterparts - so maybe not much is gained > by this practically speaking > Seems that you did not understand my proposal. The idea of this fully-optional repo (I say this to avoid confusions) is that the ones who which to use packages built without support for systemd (mainly OpenRC and/or Runit users I imagine) can install them if they want. Some packages even run systemctl and related stuff in their pacman install scripts, sth. that's annoying for non-systemd users. And the last but not the least: OpenRC, Runit, new inits (like Shepherd) and initscripts *will keep on [PCR]*. [nonsystemd] is just, as I said, like [nonprism]: not mandatory for anything and non-critical -- ~Megver83 SIP: megver83 at sip.linphone.org XMPP: megver83 at jabjab.de Tox: megver83 at toxme.io GPG: 0x227CA7C556B2BA78 GNUSocial: @megver82 at quitter.cl Diaspora*: megver83 at diasp.org Matrix: @Megver83:matrix.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 520 bytes Desc: OpenPGP digital signature URL: From bill-auger at peers.community Tue May 8 22:01:44 2018 From: bill-auger at peers.community (bill-auger) Date: Tue, 8 May 2018 18:01:44 -0400 Subject: [Dev] [RFC] [nonsystemd] repository, packages built without systemd support In-Reply-To: <0253a21e-7775-4d8c-35da-25510f829bb6@hyperbola.info> References: <0253a21e-7775-4d8c-35da-25510f829bb6@hyperbola.info> Message-ID: <0cd4dedf-4d68-e6a4-bcea-463afd932115@peers.community> yes - im sure i am misunderstanding so the [notsystemd] repo would allow access to all of the replacements for things that depend on systemd - like all of the *-openrc packages so what would actually happen when you install 'your-initfreedom'? - will it remove systemd and all of it's dependents? if so, then what would the user have for an init system? would it automatically install openrc? - if not, then that is a very dangerous package to install - if yes, then would one need to remove 'your-initfreedom' on order to install a different init system that is neither openrc nor systemd? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From megver83 at hyperbola.info Wed May 9 01:49:29 2018 From: megver83 at hyperbola.info (Megver83) Date: Tue, 8 May 2018 22:49:29 -0300 Subject: [Dev] [RFC] [nonsystemd] repository, packages built without systemd support In-Reply-To: <0cd4dedf-4d68-e6a4-bcea-463afd932115@peers.community> References: <0253a21e-7775-4d8c-35da-25510f829bb6@hyperbola.info> <0cd4dedf-4d68-e6a4-bcea-463afd932115@peers.community> Message-ID: El 08/05/18 a las 19:01, bill-auger escribi?: > yes - im sure i am misunderstanding > > so the [notsystemd] repo would allow access to all of the replacements > for things that depend on systemd - like all of the *-openrc packages I must first point out that *-openrc packages are init scripts. [nonsystemd] would not offer initscripts, but rebuilt packages without systemd support. For example, mkinitcpio: Repository : core Name : mkinitcpio Version : 24-2 Description : Modular initramfs image creation utility Architecture : any URL : https://projects.archlinux.org/mkinitcpio.git/ Licenses : GPL Groups : None Provides : None Depends On : awk mkinitcpio-busybox>=1.19.4-2 kmod util-linux>=2.23 libarchive coreutils bash findutils grep filesystem>=2011.10-1 gzip systemd This is the one we all use, but this is nonsystemd's: Repository : nonsystemd Name : mkinitcpio Version : 24-2.nosystemd1 Description : Modular initramfs image creation utility Architecture : any URL : https://projects.archlinux.org/mkinitcpio.git/ Licenses : GPL Groups : None Provides : None Depends On : awk mkinitcpio-busybox>=1.19.4-2 kmod util-linux>=2.23 libarchive coreutils bash findutils grep filesystem>=2011.10-1 gzip eudev Exactly the same one as [core], but without systemd as a dependency but eudev. It is also patched with Artix's nosystemd.patch[0] > > so what would actually happen when you install 'your-initfreedom'? - > will it remove systemd and all of it's dependents? if so, then what > would the user have for an init system? would it automatically install > openrc? - if not, then that is a very dangerous package to install - if > yes, then would one need to remove 'your-initfreedom' on order to > install a different init system that is neither openrc nor systemd? > your-initfreedom would remove systemd and its counterparts, yes, *but* in the post_install() and post_upgrade() there would be a warning saying that you need to install an init provider (As of now, OpenRC/Runit). Installing such package is equivalent to removing systemd without installing anything else, this is why it is intended to be (optionally) installed during or after the migration from systemd to another init, otherwise the system will not boot. I think that with the warning is enough, 'cause I really doubt someone would be too distracted to ignore such thing. Anyways I can write a wiki page explaining this with more detail, the procedure of installation and precautions to be taken. [0] https://github.com/artix-linux/packages/blob/master/mkinitcpio/repos/core-any/nosystemd.patch -- ~Megver83 SIP: megver83 at sip.linphone.org XMPP: megver83 at jabjab.de Tox: megver83 at toxme.io GPG: 0x227CA7C556B2BA78 GNUSocial: @megver82 at quitter.cl Diaspora*: megver83 at diasp.org Matrix: @Megver83:matrix.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 520 bytes Desc: OpenPGP digital signature URL: From megver83 at hyperbola.info Wed May 9 17:40:58 2018 From: megver83 at hyperbola.info (Megver83) Date: Wed, 9 May 2018 14:40:58 -0300 Subject: [Dev] [RFC] [nonsystemd] repository, packages built without systemd support In-Reply-To: References: <0253a21e-7775-4d8c-35da-25510f829bb6@hyperbola.info> <0cd4dedf-4d68-e6a4-bcea-463afd932115@peers.community> Message-ID: El 08/05/18 a las 22:49, Megver83 escribi?: > your-initfreedom would remove systemd and its counterparts, yes, *but* > in the post_install() and post_upgrade() there would be a warning saying > that you need to install an init provider (As of now, OpenRC/Runit). Well, after creating the blacklist I realized that your-initfreedom should (and does) not remove systemd and libsystemd because eudev-systemd and libeudev-systemd are listed as replacements, so your-initfreedom thinks those packages have the corresponding provides=() and conflicts=() variables. -- ~Megver83 SIP: megver83 at sip.linphone.org XMPP: megver83 at jabjab.de Tox: megver83 at toxme.io GPG: 0x227CA7C556B2BA78 GNUSocial: @megver82 at quitter.cl Diaspora*: megver83 at diasp.org Matrix: @Megver83:matrix.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 520 bytes Desc: OpenPGP digital signature URL: From bill-auger at peers.community Wed May 9 20:04:40 2018 From: bill-auger at peers.community (bill-auger) Date: Wed, 9 May 2018 16:04:40 -0400 Subject: [Dev] [RFC] [nonsystemd] repository, packages built without systemd support In-Reply-To: References: <0253a21e-7775-4d8c-35da-25510f829bb6@hyperbola.info> <0cd4dedf-4d68-e6a4-bcea-463afd932115@peers.community> Message-ID: <1fa511c2-ea76-8d83-49a7-1cbf6f1502c8@peers.community> i dont know how difficult this idea may be, but it seems like the logical user-friendly thing to do would be to have a separate package for each init system, including a new one with only systemd - each of which as a provider of 'your-init-freedom'; and base would depend on any one of those providers 'init-systemd' provides('your-init-freedom') depends('systemd-sysvcompat') conflicts('init-openrc' 'init-runit' 'init-shepherd') 'init-openrc' provides('your-init-freedom') depends(whatever 'base-openrc' depends now) conflicts('init-systemd' 'init-runit' 'init-shepherd') 'init-runit' provides('your-init-freedom') depends('runit') conflicts('init-systemd' 'init-openrc' 'init-shepherd') 'init-shepherd' provides('your-init-freedom') depends('shepherd') conflicts('init-systemd' 'init-openrc' 'init-runit') as it is now, 'base' depends on 'systemd' and any other init package would need to remove 'systemd' so instead there is base-openrc that removes 'base' - but that seems very tacky to be removing 'base' or anything from it for any reason - it is most sensible to have only one 'base' package that allows for optional components # pacstrap /mnt 'base' There are 4 providers of 'your-init-freedom'. Please select one: 1) 'init-systemd' 2) 'init-openrc' 3) 'init-runit 4) 'init-shepherd') i dont know if a new repo is really need for this but i dont know why there is a separate repo for kernels either - maybe this is suggesting a similar schema -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From megver83 at hyperbola.info Thu May 10 00:42:19 2018 From: megver83 at hyperbola.info (Megver83) Date: Wed, 9 May 2018 21:42:19 -0300 Subject: [Dev] [RFC] [nonsystemd] repository, packages built without systemd support In-Reply-To: <1fa511c2-ea76-8d83-49a7-1cbf6f1502c8@peers.community> References: <0253a21e-7775-4d8c-35da-25510f829bb6@hyperbola.info> <0cd4dedf-4d68-e6a4-bcea-463afd932115@peers.community> <1fa511c2-ea76-8d83-49a7-1cbf6f1502c8@peers.community> Message-ID: El 09/05/18 a las 17:04, bill-auger escribi?: > i dont know how difficult this idea may be, but it seems like the > logical user-friendly thing to do would be to have a separate package > for each init system, including a new one with only systemd - each of > which as a provider of 'your-init-freedom'; and base would depend on any > one of those providers > > 'init-systemd' provides('your-init-freedom') > depends('systemd-sysvcompat') > conflicts('init-openrc' 'init-runit' 'init-shepherd') > 'init-openrc' provides('your-init-freedom') > depends(whatever 'base-openrc' depends now) > conflicts('init-systemd' 'init-runit' 'init-shepherd') > 'init-runit' provides('your-init-freedom') > depends('runit') > conflicts('init-systemd' 'init-openrc' 'init-shepherd') > 'init-shepherd' provides('your-init-freedom') > depends('shepherd') > conflicts('init-systemd' 'init-openrc' 'init-runit') > > as it is now, 'base' depends on 'systemd' and any other init package > would need to remove 'systemd' so instead there is base-openrc that > removes 'base' - but that seems very tacky to be removing 'base' or > anything from it for any reason - it is most sensible to have only one > 'base' package that allows for optional components > > # pacstrap /mnt 'base' > There are 4 providers of 'your-init-freedom'. Please select one: > 1) 'init-systemd' > 2) 'init-openrc' > 3) 'init-runit > 4) 'init-shepherd') > > i dont know if a new repo is really need for this but i dont know why > there is a separate repo for kernels either - maybe this is suggesting a > similar schema > I did something similar. For example, openrc-init and runit-init provides=(init) so they conflict since they provide the same thing (/sbin/init). OpenRC can work with Runit, so when installing openrc (which depends on init) then you are asked whether to install openrc-init or runit-init -- ~Megver83 SIP: megver83 at sip.linphone.org XMPP: megver83 at jabjab.de Tox: megver83 at toxme.io GPG: 0x227CA7C556B2BA78 GNUSocial: @megver82 at quitter.cl Diaspora*: megver83 at diasp.org Matrix: @Megver83:matrix.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 520 bytes Desc: OpenPGP digital signature URL: From lukeshu at lukeshu.com Sat May 12 03:37:14 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Fri, 11 May 2018 23:37:14 -0400 Subject: [Dev] Funny file permissions on repo Message-ID: <8736yxfst1.wl-lukeshu@lukeshu.com> Hi all, I'm trying to set up real privilege-separation on repo.parabola.nu, so I'm auditing repo for files with funny permissions. After resolving a few files that I know what needs to be done, and how they got that way, there are still a few files that my script catches as having funny permissions: ==> Files with funny ownership: (expecting repo:users or lukeshu:users) 1 -rw-r--r-- 1 root root 5922 Oct 18 2017 /srv/repo/main/iso-beta/systemd-cli-2017.10.17/pkglist.i686.txt 2 -rw-r--r-- 1 root root 5948 Oct 18 2017 /srv/repo/main/iso-beta/systemd-cli-2017.10.17/pkglist.x86_64.txt 3 -rw-r--r-- 1 root root 6833 Nov 15 00:00 /srv/repo/main/iso-beta/systemd-cli-2017.11.15/pkglist.i686.txt 4 -rw-r--r-- 1 root root 19214 Nov 1 2017 /srv/repo/main/iso-beta/systemd-lxde-2017.10.30/pkglist.x86_64.txt 5 -rw-r--r-- 1 root root 19181 Nov 6 2017 /srv/repo/main/iso-beta/systemd-lxde-2017.11.05/pkglist.i686.txt 6 -rw-r--r-- 1 root root 19245 Nov 6 2017 /srv/repo/main/iso-beta/systemd-lxde-2017.11.05/pkglist.x86_64.txt 7 -rw-r--r-- 1 root root 19264 Nov 15 00:00 /srv/repo/main/iso-beta/systemd-lxde-2017.11.15/pkglist.i686.txt 8 lrwxrwxrwx 1 root users 51 May 1 11:08 /srv/repo/main/iso/arm/LATEST/pkglist.armv7.txt -> /srv/repo/main/iso/arm/2018-02-06/pkglist.armv7.txt 9 -rw-r--r-- 1 root users 0 May 1 08:41 /srv/repo/main/iso/openrc-cli-2017.09.30/pkglist.armv7.txt 10 -rw-r--r-- 1 root root 7247 Sep 30 2017 /srv/repo/main/iso/openrc-cli-2017.09.30/pkglist.i686.txt 11 -rw-r--r-- 1 root root 7310 Sep 30 2017 /srv/repo/main/iso/openrc-cli-2017.09.30/pkglist.x86_64.txt 12 -rw-r--r-- 1 root root 19757 Nov 5 2017 /srv/repo/main/iso/openrc-lxde-2017.11.05/pkglist.i686.txt 13 -rw-r--r-- 1 root root 19821 Nov 5 2017 /srv/repo/main/iso/openrc-lxde-2017.11.05/pkglist.x86_64.txt ==> Non-DB Files with funny perms: (expecting 0644) 1 -rw------- 1 repo users 31948 Nov 6 2017 /srv/repo/main/iso/openrc-cli-2017.09.30/parabola-openrc-2017.09.30-dual.iso.torrent 2 -rw------- 1 repo users 39165 Nov 6 2017 /srv/repo/main/iso/openrc-lxde-2017.11.05/parabola-openrc-lxde-2017.11.05-dual.iso.torrent 3 -rw------- 1 repo users 14417920 Mar 19 20:14 /srv/repo/main/other/kodi-libre/.kodi-libre-17.6-Krypton.tar.gz.9zxQwS 4 -rwxr-xr-x 1 repo users 175 Oct 1 2017 /srv/repo/main/other/kodi-libre/addons/krypton/makesums.sh I obviously know what I expect the permissions to be, but I don't want to go ahead and change them without knowing why they are the way they are (Chesterton's fence and all; I don't want to break anyone's workflows). So, major topics: - What's up with ISOs? What's up with them being owned by root? Why are a few .torrent files unreadable? It causes the URLs to return 403 Forbidden, like https://repo.parabola.nu/iso/openrc-cli-2017.09.30/parabola-openrc-2017.09.30-dual.iso.torrent - What's up with kodi-libre? Why does it look like we're running a plugin server? Can we move that to a different domain? -- Happy hacking, ~ Luke Shumaker From bill-auger at peers.community Sat May 12 15:06:12 2018 From: bill-auger at peers.community (bill-auger) Date: Sat, 12 May 2018 11:06:12 -0400 Subject: [Dev] Funny file permissions on repo In-Reply-To: <8736yxfst1.wl-lukeshu@lukeshu.com> References: <8736yxfst1.wl-lukeshu@lukeshu.com> Message-ID: On 05/11/2018 11:37 PM, Luke Shumaker wrote: > - What's up with ISOs? What's up with them being owned by root? i can answer to the pkglist.*.txt files - none of the files you mentioned are ISOs - they are all the package list text files - i copied those directly from the inside of the ISOs with the `mc` program - nearly all files inside the ISOs are owned by root; so i guess mc preserves the perms megver made the openrc torrents - maybe he remembers making them - i seem to remember there is an automated script somewhere for that - i think he used that to create them - all of the current ISO are due to be replaced soon - i will try to mind the permissions on everything with the next batch i just transfered the package lists to the repo user and set the torrent files to 644 - i dont know what the kodi files are - i left them be -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From megver83 at hyperbola.info Sat May 12 17:08:01 2018 From: megver83 at hyperbola.info (Megver83) Date: Sat, 12 May 2018 14:08:01 -0300 Subject: [Dev] Funny file permissions on repo In-Reply-To: References: <8736yxfst1.wl-lukeshu@lukeshu.com> Message-ID: El 12/05/18 a las 12:06, bill-auger escribi?: > On 05/11/2018 11:37 PM, Luke Shumaker wrote: >> - What's up with ISOs? What's up with them being owned by root? > > i can answer to the pkglist.*.txt files - none of the files you > mentioned are ISOs - they are all the package list text files - i copied > those directly from the inside of the ISOs with the `mc` program - > nearly all files inside the ISOs are owned by root; so i guess mc > preserves the perms > > megver made the openrc torrents - maybe he remembers making them - i > seem to remember there is an automated script somewhere for that - i > think he used that to create them - all of the current ISO are due to be > replaced soon - i will try to mind the permissions on everything with > the next batch > > i just transfered the package lists to the repo user and set the torrent > files to 644 - i dont know what the kodi files are - i left them be > Didn't know there was an script for creating torrents, in fact those do not work. Where is such script? I'd like to know. Btw, I might upgrade the OpenRC ISOs this month or next, because I want to first add enough [nonsystemd] packages to announce this new repo on the news plus its inclusion in the new OpenRC ISOs. -- ~Megver83 SIP: megver83 at sip.linphone.org XMPP: megver83 at jabjab.de Tox: megver83 at toxme.io GPG: 0x227CA7C556B2BA78 GNUSocial: @megver82 at quitter.cl Diaspora*: megver83 at diasp.org Matrix: @Megver83:matrix.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 520 bytes Desc: OpenPGP digital signature URL: From bill-auger at peers.community Sat May 12 21:10:37 2018 From: bill-auger at peers.community (bill-auger) Date: Sat, 12 May 2018 17:10:37 -0400 Subject: [Dev] Funny file permissions on repo In-Reply-To: References: <8736yxfst1.wl-lukeshu@lukeshu.com> Message-ID: On 05/12/2018 01:08 PM, Megver83 wrote: > Didn't know there was an script for creating torrents, in fact those do > not work. Where is such script? I'd like to know. i think i was remembering seeing this wiki article: https://wiki.parabola.nu/Hacking:isos#What.27s_on_parabola-archiso.3F where it says: createtorrent - torrent creation script, ran by make torrent that page is marked as "old-wiki" and the current parabolaiso has no "torrent" rule in the makefile - i looked also in the 'archiso.git' repo in the 'obsolete' section and i looked at the 'archiso-git' package on the AUR but i could not find that fabled 'createtorrent' script -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From nobody at parabola.nu Sun May 13 17:39:59 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Sun, 13 May 2018 17:39:59 -0000 Subject: [Dev] Orphan Libre package [retroarch] marked out-of-date Message-ID: <20180513173959.1369.86401@proton.parabola.nu> christianity at posteo.net wants to notify you that the following packages may be out-of-date: * retroarch 1.7.0-2.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/retroarch/ * retroarch 1.7.0-2.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/retroarch/ * retroarch 1.7.0-2.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/retroarch/ The user provided the following additional text: Arch on version 1.7.3-1. From bill-auger at peers.community Sun May 13 22:17:01 2018 From: bill-auger at peers.community (bill-auger) Date: Sun, 13 May 2018 18:17:01 -0400 Subject: [Dev] duplicate 'unarchiver' packages Message-ID: <0a0a4f84-bfd0-f72f-cfd5-96af700bb5b7@peers.community> the parabola package 'unar' may not longer be necessary as it seems arch has begun packaging the same program under the name 'unarchiver' so there is now the same program available in two different repos under different names - this is not critical but the current situation is very confusing how it got to be this way - can anyone sort out how to handle this the 'unar' package is listed in the blacklist as replacing the 'unrar' package - but those are not the same software - that would explain the different name but that would not be considered to be a replacement but a completely unrelated alternative - i would really like to see the blacklist data be as informative and helpful as possible - this particular example is more confusing than helpful - the blacklist descriptions should all read something like: "the parabola version of this program was liberated in the following ways ...." in which case the parabola package lives in [libre] and usually has the same name as the non-free package - or else it should read: "parabola did not liberate this package but the following alternative is recommended instead ...." with the alternative package having a different name and noted only in the description but not in the metadata column #2 as the definitive liberated replacement secondly, the PKGBUILD for 'unar' has it replacing the 'unarchiver' which was presumably in the AUR when this was added - but that would not explain the different name because it is exactly the same program - it furthermore is not modified in any significant way from the upstream so therefore does not belong in [libre] but instead in [PCR] this is issue #1769 https://labs.parabola.nu/issues/1769 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From megver83 at hyperbola.info Mon May 14 03:52:31 2018 From: megver83 at hyperbola.info (Megver83) Date: Sun, 13 May 2018 23:52:31 -0400 Subject: [Dev] duplicate 'unarchiver' packages In-Reply-To: <0a0a4f84-bfd0-f72f-cfd5-96af700bb5b7@peers.community> References: <0a0a4f84-bfd0-f72f-cfd5-96af700bb5b7@peers.community> Message-ID: El 13/05/18 a las 18:17, bill-auger escribi?: > the parabola package 'unar' may not longer be necessary as it seems arch > has begun packaging the same program under the name 'unarchiver' so > there is now the same program available in two different repos under > different names - this is not critical but the current situation is very > confusing how it got to be this way - can anyone sort out how to handle this > > the 'unar' package is listed in the blacklist as replacing the 'unrar' > package - but those are not the same software - that would explain the > different name but that would not be considered to be a replacement but > a completely unrelated alternative - i would really like to see the > blacklist data be as informative and helpful as possible - this > particular example is more confusing than helpful - the blacklist > descriptions should all read something like: "the parabola version of > this program was liberated in the following ways ...." in which case the > parabola package lives in [libre] and usually has the same name as the > non-free package - or else it should read: "parabola did not liberate > this package but the following alternative is recommended instead ...." > with the alternative package having a different name and noted only in > the description but not in the metadata column #2 as the definitive > liberated replacement > > secondly, the PKGBUILD for 'unar' has it replacing the 'unarchiver' > which was presumably in the AUR when this was added - but that would not > explain the different name because it is exactly the same program - it > furthermore is not modified in any significant way from the upstream so > therefore does not belong in [libre] but instead in [PCR] > > > this is issue #1769 https://labs.parabola.nu/issues/1769 > > > > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev > since both unarchiver and unar provide the same binaries, then unar should be dropped -- ~Megver83 SIP: megver83 at sip.linphone.org XMPP: megver83 at jabjab.de Tox: megver83 at toxme.io GPG: 0x227CA7C556B2BA78 GNUSocial: @megver82 at quitter.cl Diaspora*: megver83 at diasp.org Matrix: @Megver83:matrix.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 520 bytes Desc: OpenPGP digital signature URL: From freemor at freemor.ca Mon May 14 10:55:37 2018 From: freemor at freemor.ca (Freemor) Date: Mon, 14 May 2018 07:55:37 -0300 Subject: [Dev] duplicate 'unarchiver' packages In-Reply-To: References: <0a0a4f84-bfd0-f72f-cfd5-96af700bb5b7@peers.community> Message-ID: <20180514105537.GC30065@freemor.ca> On Sun, May 13, 2018 at 11:52:31PM -0400, Megver83 wrote: > El 13/05/18 a las 18:17, bill-auger escribi?: > since both unarchiver and unar provide the same binaries, then unar > should be dropped > > -- > ~Megver83 > > SIP: megver83 at sip.linphone.org > XMPP: megver83 at jabjab.de > Tox: megver83 at toxme.io > GPG: 0x227CA7C556B2BA78 > GNUSocial: @megver82 at quitter.cl > Diaspora*: megver83 at diasp.org > Matrix: @Megver83:matrix.org > I'd like to propose an "unar is replaced by unarchiver" type package so that users will get moved over to to current binary instead of being stranded on unar and unaware of the change over. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From bill-auger at peers.community Mon May 14 13:32:03 2018 From: bill-auger at peers.community (bill-auger) Date: Mon, 14 May 2018 09:32:03 -0400 Subject: [Dev] duplicate 'unarchiver' packages In-Reply-To: <20180514105537.GC30065@freemor.ca> References: <0a0a4f84-bfd0-f72f-cfd5-96af700bb5b7@peers.community> <20180514105537.GC30065@freemor.ca> Message-ID: On Sun, May 13, 2018 at 11:52:31PM -0400, Megver83 wrote: > since both unarchiver and unar provide the same binaries, then unar > should be dropped On Mon, 2018-05-14 at 07:55 -0300, Freemor wrote: > I'd like to propose an "unar is replaced by unarchiver" yes these are both obvious solutions - i really posted this to see if anyone could explain the confused situation it is currently in * why the 'unar' package is not already named 'unarchiver' * why the 'unar' package replaces('unrar') but that is an entirely different software * why the 'unar' package is in [libre] and not [pcr] although it is not modified from the upstream if no one knows how it got that way, can we at least agree that all 3 of those points are incorrect procedure -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From megver83 at hyperbola.info Mon May 14 16:00:01 2018 From: megver83 at hyperbola.info (Megver83) Date: Mon, 14 May 2018 12:00:01 -0400 Subject: [Dev] duplicate 'unarchiver' packages In-Reply-To: References: <0a0a4f84-bfd0-f72f-cfd5-96af700bb5b7@peers.community> <20180514105537.GC30065@freemor.ca> Message-ID: El 14/05/18 a las 09:32, bill-auger escribi?: > On Mon, 2018-05-14 at 07:55 -0300, Freemor wrote: >> I'd like to propose an "unar is replaced by unarchiver" > How can we achieve that? we can't build an external package to do such things like a manjaro-system thing, we just have to post a new in the feed saying this > yes these are both obvious solutions - i really posted this to see if anyone > could explain the confused situation it is currently in > > * why the 'unar' package is not already named 'unarchiver' I also wondered that > * why the 'unar' package replaces('unrar') but that is an entirely different > software maybe someone confused "alternative" with "replacement" > * why the 'unar' package is in [libre] and not [pcr] although it is not modified > from the upstream > wasn't it at [pcr] at first? > if no one knows how it got that way, can we at least agree that all 3 of those > points are incorrect procedure > yes, that's right. Unless (regarding point 1) the package unarchiver was added after adding unar in Parabola, which would explain the conflicts array. No matter unar's history, I think we should remove it and write about this in the news so that users know what happened. -- ~Megver83 SIP: megver83 at sip.linphone.org XMPP: megver83 at jabjab.de Tox: megver83 at toxme.io GPG: 0x227CA7C556B2BA78 GNUSocial: @megver82 at quitter.cl Diaspora*: megver83 at diasp.org Matrix: @Megver83:matrix.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 520 bytes Desc: OpenPGP digital signature URL: From megver83 at hyperbola.info Mon May 14 16:01:12 2018 From: megver83 at hyperbola.info (Megver83) Date: Mon, 14 May 2018 12:01:12 -0400 Subject: [Dev] duplicate 'unarchiver' packages In-Reply-To: References: <0a0a4f84-bfd0-f72f-cfd5-96af700bb5b7@peers.community> <20180514105537.GC30065@freemor.ca> Message-ID: El 14/05/18 a las 12:00, Megver83 escribi?: > yes, that's right. Unless (regarding point 1) the package unarchiver was > added after adding unar in Parabola, which would explain the conflicts > array. I mean, added to AUR after Parabola added it to its repos -- ~Megver83 SIP: megver83 at sip.linphone.org XMPP: megver83 at jabjab.de Tox: megver83 at toxme.io GPG: 0x227CA7C556B2BA78 GNUSocial: @megver82 at quitter.cl Diaspora*: megver83 at diasp.org Matrix: @Megver83:matrix.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 520 bytes Desc: OpenPGP digital signature URL: From bill-auger at peers.community Mon May 14 16:55:00 2018 From: bill-auger at peers.community (bill-auger) Date: Mon, 14 May 2018 12:55:00 -0400 Subject: [Dev] duplicate 'unarchiver' packages In-Reply-To: References: <0a0a4f84-bfd0-f72f-cfd5-96af700bb5b7@peers.community> <20180514105537.GC30065@freemor.ca> Message-ID: On Mon, 2018-05-14 at 12:00 -0400, Megver83 wrote: > I think we should remove it and write > about this in the news so that users know what happened. yes and change column #2 of the the blacklist entry for 'unrar' unrar:unar:fsf:unrar:[nonfree][FIXME:description] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From fauno at endefensadelsl.org Mon May 14 16:58:14 2018 From: fauno at endefensadelsl.org (fauno) Date: Mon, 14 May 2018 13:58:14 -0300 Subject: [Dev] duplicate 'unarchiver' packages In-Reply-To: References: <0a0a4f84-bfd0-f72f-cfd5-96af700bb5b7@peers.community> <20180514105537.GC30065@freemor.ca> Message-ID: <87h8na5g49.fsf@endefensadelsl.org> bill-auger writes: > On Sun, May 13, 2018 at 11:52:31PM -0400, Megver83 wrote: >> since both unarchiver and unar provide the same binaries, then unar >> should be dropped > > On Mon, 2018-05-14 at 07:55 -0300, Freemor wrote: >> I'd like to propose an "unar is replaced by unarchiver" > > yes these are both obvious solutions - i really posted this to see if anyone > could explain the confused situation it is currently in > > * why the 'unar' package is not already named 'unarchiver' i don't remember why, i think because unarchiver is the osx gui and unar the cli program? > * why the 'unar' package replaces('unrar') but that is an entirely different > software > * why the 'unar' package is in [libre] and not [pcr] although it is not modified > from the upstream because it was deemed a replacement for unrar, although it isn't a drop-in replacement and i'm still baffled at why after so many years free software projects keep using unrar instead of supporting unar (or maybe they do and i don't use them?) there should be a discussion about this on the list archive (or in our irc logs) but if it were to be dropped in favor of arch's package, please check the blacklist and your-freedom include a replaces/conflicts with unrar so when people migrated the package is offered for removal, like our unar package did. -- :> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 617 bytes Desc: not available URL: From fauno at endefensadelsl.org Mon May 14 18:24:10 2018 From: fauno at endefensadelsl.org (fauno) Date: Mon, 14 May 2018 15:24:10 -0300 Subject: [Dev] parabola news at diaspora Message-ID: <87efie5c51.fsf@endefensadelsl.org> https://diaspora.com.ar/people/a748ef80e63c0134231700145e5c073c a friend is automatically mirroring parabola.nu's rss into diaspora, it's an automatic process but they won't be able to reply to comments, so if someone wants to take over, please let me know and i'll put you in contact. -- D -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 617 bytes Desc: not available URL: From bill-auger at peers.community Mon May 14 18:42:22 2018 From: bill-auger at peers.community (bill-auger) Date: Mon, 14 May 2018 14:42:22 -0400 Subject: [Dev] parabola news at diaspora In-Reply-To: <87efie5c51.fsf@endefensadelsl.org> References: <87efie5c51.fsf@endefensadelsl.org> Message-ID: <26650ca6141f6a47b23a89110abda56d819f83cd.camel@peers.community> on a related topic - i mentioned this on IRC a few weeks ago the "gnu planet" feed aggregator resumed operations recently after some hiatus - i noticed that they were relaying the trisquel news feed so i wrote to the admin and mentioned the parabola news feed and it was promptly added - so parabola news is also being relayed on gnu planet now http://planet.gnu.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From ranisalt at protonmail.com Tue May 15 03:23:02 2018 From: ranisalt at protonmail.com (Ranieri Althoff) Date: Mon, 14 May 2018 23:23:02 -0400 Subject: [Dev] Running Parabola mirror alongside Arch mirror Message-ID: Hello, I maintain an Arch Linux mirror and I would also like to set up a Parabola mirror alongside. I see that the community, extra and core repos are mostly the same packages for the same named repos from Arch Linux, save for a few outdated packages on some of them. Also, the Parabola mirror is taking much space, and while I have space to spare, I would like to avoid as much as possible. Is there any already documented way to run both mirrors sharing packages? As the pool of packages is currently set up I can't just link between Arch Linux community/core/extra to Parabola's mirror as it is just a bunch of symlinks. Also worth giving a shot is that the same server has an Arch Linux ARM mirror set and I see they can too share packages. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nobody at parabola.nu Tue May 15 04:07:08 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Tue, 15 May 2018 04:07:08 -0000 Subject: [Dev] Orphan Pcr package [mednaffe] marked out-of-date Message-ID: <20180515040708.1368.19368@proton.parabola.nu> aether at disroot.org wants to notify you that the following packages may be out-of-date: * mednaffe 0.8.6-1 [pcr] (i686): https://parabolagnulinux.org/packages/pcr/i686/mednaffe/ * mednaffe 0.8.6-1 [pcr] (x86_64): https://parabolagnulinux.org/packages/pcr/x86_64/mednaffe/ * mednaffe-gtk2 0.8.6-1 [pcr] (i686): https://parabolagnulinux.org/packages/pcr/i686/mednaffe-gtk2/ * mednaffe-gtk2 0.8.6-1 [pcr] (x86_64): https://parabolagnulinux.org/packages/pcr/x86_64/mednaffe-gtk2/ The user provided the following additional text: This package needs be updated to the latest released version (0.8.7) otherwise it is incompatible with latest mednafen version. (1.21.3-1) From lukeshu at lukeshu.com Tue May 15 14:49:01 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Tue, 15 May 2018 10:49:01 -0400 Subject: [Dev] Running Parabola mirror alongside Arch mirror In-Reply-To: References: Message-ID: <87in7pdleq.wl-lukeshu@lukeshu.com> On Mon, 14 May 2018 23:23:02 -0400, Ranieri Althoff wrote: > Hello, I maintain an Arch Linux mirror and I would also like to set up a Parabola mirror alongside. I see that the community, extra > and core repos are mostly the same packages for the same named repos from Arch Linux, save for a few outdated packages on > some of them. Also, the Parabola mirror is taking much space, and while I have space to spare, I would like to avoid as much as > possible. > > Is there any already documented way to run both mirrors sharing packages? As the pool of packages is currently set up I can't > just link between Arch Linux community/core/extra to Parabola's mirror as it is just a bunch of symlinks. The following directories are good candidates to be shared between Arch and Parabola mirrors: - /pool/packages - /pool/community - /sources/packages - /sources/community The Parabola version of those direcories is in theory a strict subset of the Arch version, though with different ftpdir-cleanup/db-cleanup schedules, I suppose that could drift (especially as lag with Arch Linux32 causes us to hang on to old arch=(any) packages for longer than Arch does). What I would suggest doing is hardlinking the files from the Arch copy to the Parabola copy between the rsync for each: # normal archlinux rsync goes here archmirror=/path/to/archlinux paramirror=/path/to/parabola for d in {pool,sources}/{packages/community}; do ln -f -t "$paramirror/$d" -- "$archmirror/$d"/* done # normal parabola rsync goes here > Also worth giving a shot is that the same server has an Arch Linux ARM mirror set and I see they can too share packages. That one's a little tricker, because Arch Linux ARM doesn't use pools. Parabola's /pool/alarm pulls from several different directories from Arch Linux ARM. But again, *every* file there should able to be shared with the Arch Linux ARM mirror. -- Happy hacking, ~ Luke Shumaker From nobody at parabola.nu Wed May 16 01:47:53 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Wed, 16 May 2018 01:47:53 -0000 Subject: [Dev] Orphan Pcr package [mkinitcpio-openswap] marked out-of-date Message-ID: <20180516014753.1370.93975@proton.parabola.nu> contact at andrewrobbins.info wants to notify you that the following packages may be out-of-date: * mkinitcpio-openswap 0.1.0-1 [pcr] (any): https://parabolagnulinux.org/packages/pcr/any/mkinitcpio-openswap/ The user provided the following additional text: This package is out of date with upstream: https://aur.archlinux.org/packages/mkinitcpio-openswap/ From megver83 at hyperbola.info Wed May 16 20:04:15 2018 From: megver83 at hyperbola.info (Megver83) Date: Wed, 16 May 2018 16:04:15 -0400 Subject: [Dev] Blacklist and autobuilder Message-ID: Hi all. I've working on some things regarding the blacklist, and I've encountered a few problems, thought on solutions, and wanted to discuss some topics, so I will summarize everything in this mail. 1) Autobuilder Something strange happens to it. I just pushed some changes to the blacklists, and now your-privacy and your-freedom_emu have the same conflicts=() as your-freedom and the PKGBUILDs pushed to the abslibre by the autobuilder have incorrect checksums, except your-freedom. lukeshu, could you look at this? 2) New script to get deprecated packages I created this script https://git.parabola.nu/blacklist.git/tree/find-deprecated-pkgs So anyone can get deprecated packages that are still in our blacklists (read the script for more info) and remove them. I used it for commit https://git.parabola.nu/blacklist.git/commit/?id=c914523aa7fb48abea19f391bf5ebf3a2486fb69 and works well 3) Uboot packages We block Arch ARM's uboot packages https://git.parabola.nu/blacklist.git/tree/blacklist.txt#n701 However, is it necessary? I mean, they are in the [alarm] which is a particular repo from Arch ARM that we don't sync. Plus, some packages like vboot-utils, which are at [alarm], not in the blacklist and in [libre]. So then why uboot? In summary (regarding this point), we should not blacklist [alarm] packages if we don't sync it. However, I think we can consider syncing it, because there are some useful packages there, like fake-hwclock, vboot-utils (which is ultra outdated in [libre]), some xf86-video drivers, etc. If we don't, the second option would be to, in some way, move the useful packages to [libre] (maybe using a whitelist instead of a blacklist is a better idea in this case). And in the last case, which is probably what we do now, manually build those packages ourselves and upload them to [libre]. -- ~Megver83 SIP: megver83 at sip.linphone.org XMPP: megver83 at jabjab.de Tox: megver83 at toxme.io GPG: 0x227CA7C556B2BA78 GNUSocial: @megver82 at quitter.cl Diaspora*: megver83 at diasp.org Matrix: @Megver83:matrix.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 520 bytes Desc: OpenPGP digital signature URL: From ebrasca at librepanther.com Thu May 17 23:03:25 2018 From: ebrasca at librepanther.com (Bruno Cichon) Date: Fri, 18 May 2018 01:03:25 +0200 Subject: [Dev] [RFC] [nonsystemd] repository, packages built without systemd support In-Reply-To: <1fa511c2-ea76-8d83-49a7-1cbf6f1502c8@peers.community> (bill-auger@peers.community's message of "Wed, 9 May 2018 16:04:40 -0400") References: <0253a21e-7775-4d8c-35da-25510f829bb6@hyperbola.info> <0cd4dedf-4d68-e6a4-bcea-463afd932115@peers.community> <1fa511c2-ea76-8d83-49a7-1cbf6f1502c8@peers.community> Message-ID: <87h8n5opfm.fsf@librepanther.com> I like to have 1 base and ask for init system. bill-auger writes: > i dont know how difficult this idea may be, but it seems like the > logical user-friendly thing to do would be to have a separate package > for each init system, including a new one with only systemd - each of > which as a provider of 'your-init-freedom'; and base would depend on any > one of those providers > > 'init-systemd' provides('your-init-freedom') > depends('systemd-sysvcompat') > conflicts('init-openrc' 'init-runit' 'init-shepherd') > 'init-openrc' provides('your-init-freedom') > depends(whatever 'base-openrc' depends now) > conflicts('init-systemd' 'init-runit' 'init-shepherd') > 'init-runit' provides('your-init-freedom') > depends('runit') > conflicts('init-systemd' 'init-openrc' 'init-shepherd') > 'init-shepherd' provides('your-init-freedom') > depends('shepherd') > conflicts('init-systemd' 'init-openrc' 'init-runit') > > as it is now, 'base' depends on 'systemd' and any other init package > would need to remove 'systemd' so instead there is base-openrc that > removes 'base' - but that seems very tacky to be removing 'base' or > anything from it for any reason - it is most sensible to have only one > 'base' package that allows for optional components > > # pacstrap /mnt 'base' > There are 4 providers of 'your-init-freedom'. Please select one: > 1) 'init-systemd' > 2) 'init-openrc' > 3) 'init-runit > 4) 'init-shepherd') > > i dont know if a new repo is really need for this but i dont know why > there is a separate repo for kernels either - maybe this is suggesting a > similar schema > > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev From nobody at parabola.nu Sun May 20 20:03:30 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Sun, 20 May 2018 20:03:30 -0000 Subject: [Dev] Orphan Libre package [linux-libre] marked out-of-date Message-ID: <20180520200330.1368.36967@proton.parabola.nu> clayton at craftyguy.net wants to notify you that the following packages may be out-of-date: * linux-libre 4.16.8_gnu-1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/linux-libre/ * linux-libre 4.16.8_gnu-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre/ * linux-libre 4.16.8_gnu-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre/ * linux-libre-docs 4.16.8_gnu-1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/linux-libre-docs/ * linux-libre-docs 4.16.8_gnu-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre-docs/ * linux-libre-docs 4.16.8_gnu-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-docs/ * linux-libre-headers 4.16.8_gnu-1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/linux-libre-headers/ * linux-libre-headers 4.16.8_gnu-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre-headers/ * linux-libre-headers 4.16.8_gnu-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-headers/ The user provided the following additional text: 4.16.9 on kernel.org (I think 4.16.10 might be imminent too) From lukeshu at lukeshu.com Mon May 21 03:11:14 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Sun, 20 May 2018 23:11:14 -0400 Subject: [Dev] libretools 20180520 release announcement Message-ID: <8736ylem99.wl-lukeshu@lukeshu.com> I just released libretools 20180520 to [libre] and pushed the source tarball to . This is a bugfix/compatibility release. Changes from 20180428 to 20180520: - libremakepkg: * Chown /build in the chroot to 'builduser' (instead of chmod 1777), in order to work with pacman-git commit d8717a6a9666ec80c8645d190d6f9c7ab73084ac makepkg and later. * Insert an entry for 'builduser' in /etc/shadow (rather than just /etc/passwd) in the chroot, in order to to work with sudo 1.8.23. -- Happy hacking, ~ Luke Shumaker From nobody at parabola.nu Mon May 21 15:48:46 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Mon, 21 May 2018 15:48:46 -0000 Subject: [Dev] Orphan Libre package [mesa] marked out-of-date Message-ID: <20180521154846.1371.36952@proton.parabola.nu> clayton at craftyguy.net wants to notify you that the following packages may be out-of-date: * mesa 18.0.3-4.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/mesa/ * mesa 18.0.3-4.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/mesa/ The user provided the following additional text: Mesa 18.1 released: https://www.mesa3d.org/relnotes/18.1.0.html From megver83 at hyperbola.info Tue May 22 02:33:41 2018 From: megver83 at hyperbola.info (Megver83) Date: Mon, 21 May 2018 22:33:41 -0400 Subject: [Dev] Orphan Libre package [linux-libre] marked out-of-date In-Reply-To: <20180520200330.1368.36967@proton.parabola.nu> References: <20180520200330.1368.36967@proton.parabola.nu> Message-ID: <1f242e30-4c66-b95d-54e2-fbe68ce453b4@hyperbola.info> El 20/05/18 a las 16:03, Parabola Website Notification escribi?: > 4.16.9 on kernel.org (I think 4.16.10 might be imminent too) We don't care about what's on kernel.org, since out kernels are the deblobbed ones from linux-libre.fsfla.org. Anyways, I upgraded it for all its arch'es -- ~Megver83 SIP: megver83 at sip.linphone.org XMPP: megver83 at jabjab.de Tox: megver83 at toxme.io GPG: 0x227CA7C556B2BA78 GNUSocial: @megver82 at quitter.cl Diaspora*: megver83 at diasp.org Matrix: @Megver83:matrix.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 520 bytes Desc: OpenPGP digital signature URL: From nobody at parabola.nu Thu May 24 03:59:22 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Thu, 24 May 2018 03:59:22 -0000 Subject: [Dev] Orphan Libre package [linux-libre] marked out-of-date Message-ID: <20180524035922.1368.49579@proton.parabola.nu> clayton at craftyguy.net wants to notify you that the following packages may be out-of-date: * linux-libre 4.16.9_gnu-1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/linux-libre/ * linux-libre 4.16.9_gnu-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre/ * linux-libre 4.16.9_gnu-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre/ * linux-libre-docs 4.16.9_gnu-1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/linux-libre-docs/ * linux-libre-docs 4.16.9_gnu-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre-docs/ * linux-libre-docs 4.16.9_gnu-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-docs/ * linux-libre-headers 4.16.9_gnu-1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/linux-libre-headers/ * linux-libre-headers 4.16.9_gnu-1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/linux-libre-headers/ * linux-libre-headers 4.16.9_gnu-1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/linux-libre-headers/ The user provided the following additional text: 4.16.11 is on kernel.org From nobody at parabola.nu Sat May 26 01:44:23 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Sat, 26 May 2018 01:44:23 -0000 Subject: [Dev] Orphan Libre package [vim] marked out-of-date Message-ID: <20180526014423.1368.99269@proton.parabola.nu> clayton at craftyguy.net wants to notify you that the following packages may be out-of-date: * gvim 8.0.1436-1.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/gvim/ * gvim 8.0.1838-1.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/gvim/ * gvim 8.0.1838-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/gvim/ * vim 8.0.1436-1.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/vim/ * vim 8.0.1838-1.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/vim/ * vim 8.0.1838-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/vim/ * vim-runtime 8.0.1436-1.parabola1 [libre] (armv7h): https://parabolagnulinux.org/packages/libre/armv7h/vim-runtime/ * vim-runtime 8.0.1838-1.parabola1 [libre] (i686): https://parabolagnulinux.org/packages/libre/i686/vim-runtime/ * vim-runtime 8.0.1838-1.parabola1 [libre] (x86_64): https://parabolagnulinux.org/packages/libre/x86_64/vim-runtime/ The user provided the following additional text: vim 8.1 is in Arch stable repo From nobody at parabola.nu Sat May 26 13:48:55 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Sat, 26 May 2018 13:48:55 -0000 Subject: [Dev] Orphan Pcr package [icedove-enigmail] marked out-of-date Message-ID: <20180526134855.1370.25274@proton.parabola.nu> joinlaw at cock.li wants to notify you that the following packages may be out-of-date: * icedove-enigmail 1.9.9-1 [pcr] (any): https://parabolagnulinux.org/packages/pcr/any/icedove-enigmail/ The user provided the following additional text: The latest version is 2.0.5 for enigmail From joinlaw at cock.li Sun May 27 14:36:19 2018 From: joinlaw at cock.li (joinlaw) Date: Sun, 27 May 2018 17:36:19 +0300 Subject: [Dev] Consolekit2 In-Reply-To: References: Message-ID: <924cf9ee-6865-38eb-56c8-f927a886b5d4@cock.li> An HTML attachment was scrubbed... URL: From joinlaw at cock.li Sun May 27 14:40:34 2018 From: joinlaw at cock.li (joinlaw) Date: Sun, 27 May 2018 17:40:34 +0300 Subject: [Dev] Consolekit2 In-Reply-To: <924cf9ee-6865-38eb-56c8-f927a886b5d4@cock.li> References: <924cf9ee-6865-38eb-56c8-f927a886b5d4@cock.li> Message-ID: sorry for sending html icedove de(fault). On 05/27/18 17:36, joinlaw wrote: > > hi > > why parabola replaces consolekit with elogind > instead of Consolekit2 https://github.com/ConsoleKit2/ConsoleKit2 > i know guix is using elogind but what is gentoo using. > > elogind seems bloated replaces consolekit & pm-utils > so what the benfit for elogind over Consolekit2. > > all the best > joinlaw > > > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev From dikasetyaprayogi at gmail.com Sun May 27 16:08:02 2018 From: dikasetyaprayogi at gmail.com (Dika SP) Date: Sun, 27 May 2018 23:08:02 +0700 Subject: [Dev] Qupzilla contains nonprivacy search engine eg:google Message-ID: pcr/qupzilla1 1.8.9-1 Cross-platform Qt Webkit browser Its from pcr, maybe the dev forgot to remove it or something seems no blacksit info has been registered yet -------------- next part -------------- An HTML attachment was scrubbed... URL: From dikasetyaprayogi at gmail.com Sun May 27 16:19:16 2018 From: dikasetyaprayogi at gmail.com (Dika SP) Date: Sun, 27 May 2018 23:19:16 +0700 Subject: [Dev] same blacklist txt ? In-Reply-To: References: Message-ID: your-freedom your-freedom_emu your-privacy all version 20180516-1 just wondering across package and found that these three packages contains the same exact blacklist.txt and same conflit depedencies so whats the point ? are they will be merged ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From megver83 at hyperbola.info Sun May 27 22:17:58 2018 From: megver83 at hyperbola.info (Megver83) Date: Sun, 27 May 2018 18:17:58 -0400 Subject: [Dev] Consolekit2 In-Reply-To: <924cf9ee-6865-38eb-56c8-f927a886b5d4@cock.li> References: <924cf9ee-6865-38eb-56c8-f927a886b5d4@cock.li> Message-ID: El 27/05/18 a las 10:36, joinlaw escribi?: > > hi > > why parabola replaces consolekit with elogind > instead of Consolekit2 https://github.com/ConsoleKit2/ConsoleKit2 > i know guix is using elogind but what is gentoo using. > > elogind seems bloated replaces consolekit & pm-utils > so what the benfit for elogind over Consolekit2. > > all the best > joinlaw > > > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev > I'd suggest to first read and then ask. https://wiki.parabola.nu/OpenRC#The_system_can.27t_shutdown_correctly "Since /sbin/init was replaced with openrc-init, shutdown was replaced with openrc-shutdown, Consolekit doesn't work correctly and you need to use elogind instead" And elogind is not bloated, it's extracted from systemd-logind, yes, but it does it job, without going further. -- ~Megver83 SIP: megver83 at sip.linphone.org XMPP: megver83 at jabjab.de Tox: megver83 at toxme.io GPG: 0x227CA7C556B2BA78 GNUSocial: @megver82 at quitter.cl Diaspora*: megver83 at diasp.org Matrix: @Megver83:matrix.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 520 bytes Desc: OpenPGP digital signature URL: From megver83 at hyperbola.info Sun May 27 22:19:31 2018 From: megver83 at hyperbola.info (Megver83) Date: Sun, 27 May 2018 18:19:31 -0400 Subject: [Dev] same blacklist txt ? In-Reply-To: References: Message-ID: El 27/05/18 a las 12:19, Dika SP escribi?: > your-freedom > your-freedom_emu > your-privacy > all version 20180516-1 > > just wondering across package and found that these three packages > contains the same exact blacklist.txt and same conflit depedencies > > so whats the point ? are they will be merged ? > > > > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev > it is because of a bug from our automatic build system, which I described here -> https://lists.parabola.nu/pipermail/dev/2018-May/006731.html -- ~Megver83 SIP: megver83 at sip.linphone.org XMPP: megver83 at jabjab.de Tox: megver83 at toxme.io GPG: 0x227CA7C556B2BA78 GNUSocial: @megver82 at quitter.cl Diaspora*: megver83 at diasp.org Matrix: @Megver83:matrix.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 520 bytes Desc: OpenPGP digital signature URL: From megver83 at hyperbola.info Sun May 27 22:31:39 2018 From: megver83 at hyperbola.info (Megver83) Date: Sun, 27 May 2018 18:31:39 -0400 Subject: [Dev] same blacklist txt ? In-Reply-To: References: Message-ID: <468c47cc-71f3-e78d-47ff-e33152fc367c@hyperbola.info> El 27/05/18 a las 18:19, Megver83 escribi?: > El 27/05/18 a las 12:19, Dika SP escribi?: >> your-freedom >> your-freedom_emu >> your-privacy >> all version 20180516-1 >> >> just wondering across package and found that these three packages >> contains the same exact blacklist.txt and same conflit depedencies >> >> so whats the point ? are they will be merged ? >> >> >> >> _______________________________________________ >> Dev mailing list >> Dev at lists.parabola.nu >> https://lists.parabola.nu/mailman/listinfo/dev >> > it is because of a bug from our automatic build system, which I > described here -> > https://lists.parabola.nu/pipermail/dev/2018-May/006731.html > just rebuilt them -- ~Megver83 SIP: megver83 at sip.linphone.org XMPP: megver83 at jabjab.de Tox: megver83 at toxme.io GPG: 0x227CA7C556B2BA78 GNUSocial: @megver82 at quitter.cl Diaspora*: megver83 at diasp.org Matrix: @Megver83:matrix.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 520 bytes Desc: OpenPGP digital signature URL: From nobody at parabola.nu Mon May 28 22:15:45 2018 From: nobody at parabola.nu (Parabola Website Notification) Date: Mon, 28 May 2018 22:15:45 -0000 Subject: [Dev] Orphan Pcr package [gajim-plugin-omemo] marked out-of-date Message-ID: <20180528221545.1368.35828@proton.parabola.nu> fauno at parabola.nu wants to notify you that the following packages may be out-of-date: * gajim-plugin-omemo 2.5.8-1 [pcr] (any): https://parabolagnulinux.org/packages/pcr/any/gajim-plugin-omemo/ The user provided the following additional text: 2.5.13 is out! https://dev.gajim.org/gajim/gajim-plugins/blob/master/omemo/manifest.ini From lukeshu at lukeshu.com Tue May 29 01:14:58 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Mon, 28 May 2018 21:14:58 -0400 Subject: [Dev] SSE2 safe assumption on i686? Message-ID: <877ennfejx.wl-lukeshu@lukeshu.com> Hi all, I think I'm turning on SSE2 in CFLAGS for the libre/glib2-static package (CFLAGS+=" -msse2 -mfpmath=sse"). SSE2 was an extension to i686 introduced with the Pentium 4 in 2001 (i686 itself was introduced with the Pentium Pro in 1995, which came between the Pentium 1 and 2). SSE2 is guaranteed to be there on all x86_64 processors. Is this a thing that we're OK doing? Or do we want to support i686 processors without SSE2? The decision to continue i686 support was based largely on the number of i686 devices supported by LibreBoot; I don't believe LibreBoot supports any devices with pre-SSE2 processors. I would not be surprised if many packages already require SSE2 on i686 (via inline assembly or intrinsics or somesuch; after ./configure discovers that SSE2 is supported on the local processor). -- Happy hacking, ~ Luke Shumaker From freemor at freemor.ca Tue May 29 10:54:57 2018 From: freemor at freemor.ca (Freemor) Date: Tue, 29 May 2018 07:54:57 -0300 Subject: [Dev] SSE2 safe assumption on i686? In-Reply-To: <877ennfejx.wl-lukeshu@lukeshu.com> References: <877ennfejx.wl-lukeshu@lukeshu.com> Message-ID: <20180529105456.GP2831@freemor.ca> On Mon, May 28, 2018 at 09:14:58PM -0400, Luke Shumaker wrote: > Hi all, > > I think I'm turning on SSE2 in CFLAGS for the libre/glib2-static > package (CFLAGS+=" -msse2 -mfpmath=sse"). > > SSE2 was an extension to i686 introduced with the Pentium 4 in 2001 > (i686 itself was introduced with the Pentium Pro in 1995, which came > between the Pentium 1 and 2). > > SSE2 is guaranteed to be there on all x86_64 processors. > > Is this a thing that we're OK doing? Or do we want to support i686 > processors without SSE2? The decision to continue i686 support was > based largely on the number of i686 devices supported by LibreBoot; I > don't believe LibreBoot supports any devices with pre-SSE2 processors. > I would not be surprised if many packages already require SSE2 on i686 > (via inline assembly or intrinsics or somesuch; after ./configure > discovers that SSE2 is supported on the local processor). > > -- > Happy hacking, > ~ Luke Shumaker > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev Your reasoning seems sound to me. There are other projects devoted to supporting old/ancient hardware, tho perhaps not as freedom respecting as Parabola. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From bill-auger at peers.community Tue May 29 11:49:40 2018 From: bill-auger at peers.community (bill-auger) Date: Tue, 29 May 2018 07:49:40 -0400 Subject: [Dev] SSE2 safe assumption on i686? In-Reply-To: <20180529105456.GP2831@freemor.ca> References: <877ennfejx.wl-lukeshu@lukeshu.com> <20180529105456.GP2831@freemor.ca> Message-ID: <6b44a5a9f179e1aba48eaf1759eece080f57e0e2.camel@peers.community> the deciding factor o/c would be whatever archlinux32 is doing with the core packages - theres no point in asking the question if they are not dedicated to that goal when is the last time anyone has pulled the P2 down from the attic and tried booting parabola - is anyone sure that is even still possible? also, one arch dev is working on a port to 486 that could presumably cover everything else that parabola could conceivably run on ConnochaetOS still supports the full i686 class so there is still a libre harbour for those machines even if parabola can no longer support them -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From joinlaw at cock.li Tue May 29 14:14:04 2018 From: joinlaw at cock.li (joinlaw) Date: Tue, 29 May 2018 17:14:04 +0300 Subject: [Dev] Consolekit2 In-Reply-To: References: <924cf9ee-6865-38eb-56c8-f927a886b5d4@cock.li> Message-ID: <02857971-6926-422f-a45e-df438d402ab1@cock.li> hi again! i did ask gentoo users in #gentoo about consolekit2 and they tell me that is that default session/login manager for gentoo and they did says that openrc-init & openrc-shutdown is not the default setup for openrc but arch derivatives chose to that option to set it up that way. is that set up taken from manjaro or arch-openrc or parabola dev's chose that setup. Maybe you can make patched version of consolekit2 to work with your setup but as they tell me the upstream consolekit2 work with gentoo without changes. even if elogind is the default can you put consolekit2 in the repo or support it. happy hacking! joinlaw -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From lukeshu at lukeshu.com Tue May 29 18:54:42 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Tue, 29 May 2018 14:54:42 -0400 Subject: [Dev] I made an ASCII/Unicode logo thing Message-ID: <876036fg25.wl-lukeshu@lukeshu.com> I made a thing: _,, _ _, ,##' ,##; _, ,##' ,##' ,#####; _,;#',##' ,##' ,#######' _,#**^' ` ,######### .-^` `######### ?????? ? ? ######## ? ? ?????? ???? ?????? ?????? ????? ? ?????? ??? ??? ? ? ;###### ????? ? ? ? ? ? ? ? ? ? ? ? ? ??? ??? ? ? ;####* ? ? ? ? ? ? ? ? ? ? ? ? ? ??? ??? ??? ####' ? ?????? ? ?????? ?????? ????? ? ?????? Linux-libre ;### ,##' ## #' / ' I took the logo from the one I made for Archey3 https://github.com/lclarkmichalek/archey3/pull/40 If I re-did the logo to squeeze the logo down to 15 cols, then it would fit in a standard 80x24 terminal, and be suitable for a MOTD banner thing. Oh, but the default Linux console doesn't seem to like the quadrant blocks that I used to squeeze "GNU" down. I wonder if fiddling with vconsole.conf:FONT_UNIMAP would fix it. I thought about using quadrant blocks to get the "pixels" on "Parabola" a bit smaller, but since quadrants aren't square, it ended up looking funny when I started. -- Happy hacking, ~ Luke Shumaker From bill-auger at peers.community Tue May 29 21:35:40 2018 From: bill-auger at peers.community (bill-auger) Date: Tue, 29 May 2018 17:35:40 -0400 Subject: [Dev] I made an ASCII/Unicode logo thing In-Reply-To: <876036fg25.wl-lukeshu@lukeshu.com> References: <876036fg25.wl-lukeshu@lukeshu.com> Message-ID: ok this surely no coincidence today - you must have seen the one ive been putting on the live ISOs? - that one is derrived from mkinitcpio-paralogo and kept within 80 cols for the sake of compatibility $ curl https://git.parabola.nu/parabolaiso.git/plain/configs/profile/root-image/ etc/motd?h=refactor your parabola is just superb - some combination of the two of them may be just the thing -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From lukeshu at lukeshu.com Tue May 29 21:50:03 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Tue, 29 May 2018 17:50:03 -0400 Subject: [Dev] I made an ASCII/Unicode logo thing In-Reply-To: References: <876036fg25.wl-lukeshu@lukeshu.com> Message-ID: <874liqf7xw.wl-lukeshu@lukeshu.com> On Tue, 29 May 2018 17:35:40 -0400, bill-auger wrote: > > ok this surely no coincidence today - you must have seen the one ive been > putting on the live ISOs? - that one is derrived from mkinitcpio-paralogo and > kept within 80 cols for the sake of compatibility I saw the one you put in /etc/motd in the 'filesystem' package :) > $ curl https://git.parabola.nu/parabolaiso.git/plain/configs/profile/root-image/ > etc/motd?h=refactor > > your parabola is just superb - some combination of the two of them may be just > the thing Thank you :) -- Happy hacking, ~ Luke Shumaker From bill-auger at peers.community Tue May 29 23:56:06 2018 From: bill-auger at peers.community (bill-auger) Date: Tue, 29 May 2018 19:56:06 -0400 Subject: [Dev] I made an ASCII/Unicode logo thing In-Reply-To: <874liqf7xw.wl-lukeshu@lukeshu.com> References: <876036fg25.wl-lukeshu@lukeshu.com> <874liqf7xw.wl-lukeshu@lukeshu.com> Message-ID: yes that one is on some of the ISOs - heres a combination i managed to squeeze into 80 cols $ curl https://git.parabola.nu/parabolaiso.git/plain/configs/profile/root- image/etc/motd-80col?h=refactor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From lukeshu at lukeshu.com Wed May 30 19:15:10 2018 From: lukeshu at lukeshu.com (Luke Shumaker) Date: Wed, 30 May 2018 15:15:10 -0400 Subject: [Dev] libretools 20180530 release announcement Message-ID: <871sdtez0h.wl-lukeshu@lukeshu.com> I just released libretools 20180530 to [libre] and pushed the source tarball to . This is mostly a bugfix/compatibility release for pacman 5.1 upgrade. Most of the changes should be invisible. Visible changes from 20180520 to 20180530: - libremakepkg: * If PKGDEST or similar is set, don't create a symlink from package file in the PKGDEST directory to the current directory. This reflects the change in plain makepkg. - librefetch: * Adjust how we set options=() in the PKGBUILD. See librefetch(8) if you are interested. * Fix it printing bogus warnings related to backup=() https://labs.parabola.nu/issues/1186 -- Happy hacking, ~ Luke Shumaker From brainblasted at disroot.org Wed May 30 23:29:55 2018 From: brainblasted at disroot.org (Christopher Davis) Date: Wed, 30 May 2018 19:29:55 -0400 Subject: [Dev] GNOME Software, archlinux-appstream-data, and Flatpak Message-ID: <1527722995.25892.0@disroot.org> Hello dev at lists.parabola.nu, My name is Christopher Davis, and I contribute to various GNOME projects in different ways. Most of the GNOME stack is present in Parabola, with one major omission: GNOME Software. The reason provided on the blacklist is "depends on nonfree archlinux-appstream-data". A little more than a month ago I reached out to the people working on Arch Linux regarding how to generate something for Parabola. I was directed to the HOWTO file in https://sources.archlinux.org/other/packages/archlinux-appstream-data/, which provides a detailed guide to creating the data needed by appstream and GNOME Software. With this, theoretically we could put GNOME Software back in the repos. bill-auger pointed out another issue, though. Flatpak is a way to distribute and run software in a consistent, sandboxed environment. I personally do not see Flatpak as a freedom issue, but there is apparently discussion about removing all third-party package managers from Parabola, like pip and npm. I would like to note that Flatpak is blank by default unlike pip and npm. There is no central repo, and it is entirely possible to use Flatpak without proprietary software. Similar to Pacman, Flatpak only uses the repos you provide. If you provide none it has none, and if you provide repos with only libre software it will use that. I know Purism is would like to have such a repo for the Librem 5 and PureOS. GNOME Software uses Flatpak and the system package manager. As of now, it is the only GUI that handles Flatpak bundles. As someone working on GNOME projects, Flatpak is very important to my workflow, and GNOME Software is useful for managing system applications. I would be interested in getting input here, and trying to get it back into the repository. Regards, Christopher Davis -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill-auger at peers.community Thu May 31 00:46:48 2018 From: bill-auger at peers.community (bill-auger) Date: Wed, 30 May 2018 20:46:48 -0400 Subject: [Dev] GNOME Software, archlinux-appstream-data, and Flatpak In-Reply-To: <1527722995.25892.0@disroot.org> References: <1527722995.25892.0@disroot.org> Message-ID: <4dfafd40cb23dc00c758e5bde1cd31ec07791458.camel@peers.community> im not sure exactly what this feature request implies; but third-party package managers pose a special challenge to the FSDG guidelines - so i suggested this needs some discussion as a staring point for discussion i will note this open issue[1] that exemplifies one extreme end of the spectrum by suggesting that perpahs parabola should blacklist if not patch all third-party package managers such as pip, rubygems, npm assuming this is deemed to be FSDG-compliant, how much work would need to be done to make this happen? as i remember this would require at the very least some work creating an appstream data package On Wed, 2018-05-30 at 19:29 -0400, Christopher Davis wrote: > GNOME Software uses Flatpak and the system package manager. this next statement is perhaps nit-picking, but that wording is too pretentious not to be made clear - i dont imagine the gnome people would agree with it as worded - until the day comes when gnome releases it's very own distro, then gnome would have no grounds to define the "system package manager" - in the context of a distro, the 'gnome software' program and gnome itself are third- party software - 'flatpack' is yet another unrelated third-party software that the 'gnome software' program makes use of for it's own purposes, which should be entirely orthogonal to anything that "the system" is concerned with - in other words, if this program is capable of installing software without using pacman and installing it to the same system locations as pacman might install that same software, then this program should be blacklisted for that reason alone, because it leads to system instability - i had to mention that because i have seen pip do this, and it is a real mess to cleanup [1]: https://labs.parabola.nu/issues/1035 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From bill-auger at peers.community Thu May 31 02:19:37 2018 From: bill-auger at peers.community (bill-auger) Date: Wed, 30 May 2018 22:19:37 -0400 Subject: [Dev] Qupzilla contains nonprivacy search engine eg:google In-Reply-To: References: Message-ID: nothing in [pcr] should be on the blacklist - all packages in [pcr] have been added intentionally by a parabola dev because arch does not package them - libre replacements for existing arch packages are entered in the blacklist and are placed in the [libre] repo in this case, 'qupzilla1' is a replacement for the arch 'qupzilla' so you are correct that it should also be on the blacklist - i immediately saw an issue when i tried it that it has a checkbox to allow loading of the flash player plugin - i think the liberation of this program was not fully completed and that is probably why it is not listed yet - but in that case it should now be in [libre-testing] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From bill-auger at peers.community Thu May 31 02:25:36 2018 From: bill-auger at peers.community (bill-auger) Date: Wed, 30 May 2018 22:25:36 -0400 Subject: [Dev] Consolekit2 In-Reply-To: <02857971-6926-422f-a45e-df438d402ab1@cock.li> References: <924cf9ee-6865-38eb-56c8-f927a886b5d4@cock.li> <02857971-6926-422f-a45e-df438d402ab1@cock.li> Message-ID: <16976a8e7c221a970fdcff3828a8fb0b1ee9c23c.camel@peers.community> it may help to open a packaging request for this on the parabola bug tracker https://labs.parabola.nu/projects/issue-tracker/issues?set_filter=1&tracker_id=7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: From freemor at freemor.ca Thu May 31 10:37:50 2018 From: freemor at freemor.ca (Freemor) Date: Thu, 31 May 2018 07:37:50 -0300 Subject: [Dev] GNOME Software, archlinux-appstream-data, and Flatpak In-Reply-To: <4dfafd40cb23dc00c758e5bde1cd31ec07791458.camel@peers.community> References: <1527722995.25892.0@disroot.org> <4dfafd40cb23dc00c758e5bde1cd31ec07791458.camel@peers.community> Message-ID: <20180531103750.GS2831@freemor.ca> On Wed, May 30, 2018 at 08:46:48PM -0400, bill-auger wrote: > On Wed, 2018-05-30 at 19:29 -0400, Christopher Davis wrote: > > GNOME Software uses Flatpak and the system package manager. > > this next statement is perhaps nit-picking, but that wording is too pretentious > not to be made clear - i dont imagine the gnome people would agree with it as > worded - until the day comes when gnome releases it's very own distro, then > gnome would have no grounds to define the "system package manager" - in the > context of a distro, the 'gnome software' program and gnome itself are third- > party software - 'flatpack' is yet another unrelated third-party software that > the 'gnome software' program makes use of for it's own purposes, which should be > entirely orthogonal to anything that "the system" is concerned with - in other > words, if this program is capable of installing software without using pacman > and installing it to the same system locations as pacman might install that same > software, then this program should be blacklisted for that reason alone, because > it leads to system instability - i had to mention that because i have seen pip > do this, and it is a real mess to cleanup > > > [1]: https://labs.parabola.nu/issues/1035 I share Bill-augers concerns about a foreign package format and package manager that uses that format with regards to making the system unstable. npm has recently had issues with malware, pip can and does make a confusing mess, as bill-auger mentioned. Etc. Even if flatpacks get installed to a users home dir there can be confusing support issues as the user could now be running conflicting versions of various software and all too often the request for help is "thing Z is broken, help" and it may not come out until well into trying to support then that "oh, yea.. I installed Z, D and F via flatpak". On top of user support requests there would be the maintenance burden. Maintaining a flatpack blacklist, the appstream, etc. I can appreciate that some users desire a GUI based package manager. But pacman is really quite easy to use if people take the time to learn. So I fail to see the advantage of adding this and mostly see the many downsides both to people developing/maintaining Parabola and to users of Parabola and those that support them. If Gnome software can act as a GUI the pacman without the foreign flatpak support, then I'm all for that. But adding another headache for maintainers and supporters and another avenue for new comers to shoot themselves in the foot I think we can all do without. Also is it just me or is it hard to get useful detailed info on flatpak. I've spent time on flatpak.org and have yet to find good technical documentation. Even their "under the hood" section of their docs is way short of technical details. Wikipedia's entry is similarly scant on details. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From brainblasted at disroot.org Thu May 31 17:52:32 2018 From: brainblasted at disroot.org (Christopher Davis) Date: Thu, 31 May 2018 13:52:32 -0400 Subject: [Dev] GNOME Software, archlinux-appstream-data, and Flatpak In-Reply-To: <20180531103750.GS2831@freemor.ca> References: <1527722995.25892.0@disroot.org> <4dfafd40cb23dc00c758e5bde1cd31ec07791458.camel@peers.community> <20180531103750.GS2831@freemor.ca> Message-ID: <1527789152.25892.2@disroot.org> On Thu, May 31, 2018 at 6:37 AM, Freemor wrote: > Even if flatpacks get installed to a users home dir there can be > confusing > support issues as the user could now be running conflicting versions > of various > software Flatpaks are installed in a sandboxed environment. If you have two of the same application installed your system will gracefully handle it without conflicts, allowing you to use both. It is not pip-style where it overwrites files on the system, and does not break anything on the system. Flatpaks are a tool for both developing apps and distributing apps. To simplfy. Flatpak uses packages called SDKs to handle dependencies. These SDKs are installed to flatpak-managed directories. When writing an application developers have what is called a "Flatpak manifest" which tells Flatpak what SDKs the application relies on. When you export a Flatpak and install it, Flatpak pulls the SDKs needed if they are not already installed, then installs the app - without overwriting anything on the system. In contrast to bundled solutions like AppImage, the dependecies can be updated seperate from the application itself. Effectively, the way Flatpak handles things allows for there to be no significant difference between the environment the developer uses and the environments that users use, as the application is running on the same set of dependencies across all distributions. This allows users on Debian stable, for example, to install applications with dependencies or dependency versions their distro doesn't ship as long as they have flatpak, and all without conflicting or interfering with system dependencies. > So I fail to see the advantage of adding this and mostly see the > many downsides both to people developing/maintaining Parabola and to > users of Parabola and those that support them. From a developer perspective, Flatpak is incredibly useful. GNOME CI tasks generate flatpak artifacts. This means that if I want to test an unstable build or a merge request, I simply download the artifacts and run the flatpak side-by-side with the distro's version of the application. [1] is an example of this in action. As a user, it for the most part, prevents developers from telling me something could be wrong with my system, as most bugs will be repoducable since they run on the same base. [2] is an example of a bug that occurs on all Flatpak installs regardless of system fonts. [1]: https://gitlab.gnome.org/GNOME/nautilus/issues/322 [2]: https://gitlab.gnome.org/World/fractal/issues/224 Below is a quote of a message I sent in reply to bill-auger, as I forgot to reply all. > Unlike pip, GNOME Software uses pacman for installing system-level > packages. It does not go around it, so it will not cause conflicts > with pacman because it is basically a frontend to pacman. Pacman > knows all non-flatpak software installed through GNOME Software, and > GNOME Software knows all software installed through pacman. > > As for Flatpak, that issue is also avoided. Software installed via > Flatpak is handled through Flatpak-specific directories, with no > conflict occurring with system-level files. > This means you can run a stable release and a development flatpak on > the same system without issues. > > This means there is no pip-style cleanup of directories necessary. If > you install something not a flatpak through GNOME Software and then > uninstall through pacman -R, there > would be zero issue. If you install a flatpak and the same system > app, you can run both, and unisntalling either will not affect the > other in any way. Thus, no instability is caused > by having the ability to support flatpak. > > > how much work would need to be > done to make this happen? as i remember this would require at the > very least > some work creating an appstream data package > > The HOWTO file in the link[1] in my initial message goes over the > process for creating this data. > > [1]: > https://sources.archlinux.org/other/packages/archlinux-appstream-data/ On Thu, May 31, 2018 at 6:37 AM, Freemor wrote: > On Wed, May 30, 2018 at 08:46:48PM -0400, bill-auger wrote: >> On Wed, 2018-05-30 at 19:29 -0400, Christopher Davis wrote: >> > GNOME Software uses Flatpak and the system package manager. >> >> this next statement is perhaps nit-picking, but that wording is too >> pretentious >> not to be made clear - i dont imagine the gnome people would agree >> with it as >> worded - until the day comes when gnome releases it's very own >> distro, then >> gnome would have no grounds to define the "system package manager" >> - in the >> context of a distro, the 'gnome software' program and gnome itself >> are third- >> party software - 'flatpack' is yet another unrelated third-party >> software that >> the 'gnome software' program makes use of for it's own purposes, >> which should be >> entirely orthogonal to anything that "the system" is concerned with >> - in other >> words, if this program is capable of installing software without >> using pacman >> and installing it to the same system locations as pacman might >> install that same >> software, then this program should be blacklisted for that reason >> alone, because >> it leads to system instability - i had to mention that because i >> have seen pip >> do this, and it is a real mess to cleanup >> >> >> [1]: https://labs.parabola.nu/issues/1035 > > I share Bill-augers concerns about a foreign package format and > package manager > that uses that format with regards to making the system unstable. npm > has > recently had issues with malware, pip can and does make a confusing > mess, as > bill-auger mentioned. Etc. > > Even if flatpacks get installed to a users home dir there can be > confusing > support issues as the user could now be running conflicting versions > of various > software and all too often the request for help is "thing Z is > broken, help" > and it may not come out until well into trying to support then that > "oh, yea.. > I installed Z, D and F via flatpak". On top of user support requests > there > would be the maintenance burden. Maintaining a flatpack blacklist, > the appstream, > etc. > > > I can appreciate that some users desire a GUI based package manager. > But pacman > is really quite easy to use if people take the time to learn. So I > fail to see > the advantage of adding this and mostly see the many downsides both > to people > developing/maintaining Parabola and to users of Parabola and those > that support > them. > > If Gnome software can act as a GUI the pacman without the foreign > flatpak > support, then I'm all for that. But adding another headache for > maintainers and > supporters and another avenue for new comers to shoot themselves in > the foot I > think we can all do without. > > Also is it just me or is it hard to get useful detailed info on > flatpak. I've > spent time on flatpak.org and have yet to find good technical > documentation. > Even their "under the hood" section of their docs is way short of > technical > details. Wikipedia's entry is similarly scant on details. > > > _______________________________________________ > Dev mailing list > Dev at lists.parabola.nu > https://lists.parabola.nu/mailman/listinfo/dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From freemor at freemor.ca Thu May 31 18:47:55 2018 From: freemor at freemor.ca (Freemor) Date: Thu, 31 May 2018 15:47:55 -0300 Subject: [Dev] GNOME Software, archlinux-appstream-data, and Flatpak In-Reply-To: <1527789152.25892.2@disroot.org> References: <1527722995.25892.0@disroot.org> <4dfafd40cb23dc00c758e5bde1cd31ec07791458.camel@peers.community> <20180531103750.GS2831@freemor.ca> <1527789152.25892.2@disroot.org> Message-ID: <20180531184755.GT2831@freemor.ca> On Thu, May 31, 2018 at 01:52:32PM -0400, Christopher Davis wrote: > Flatpaks are installed in a sandboxed environment. If you have two > of the same application installed your system will gracefully handle > it without conflicts, allowing you to use both. It is not pip-style > where it overwrites files on the system, > and does not break anything on the system. Sandboxed how? Saying a thing is sandboxed tell me little what is the exact technical means of doing this. So you're saying that if a flatpak pulls in ICU V+1 verses what is currently in parabola That will not cause pacman installed applications that require ICU v-parabola-current to cack and die because of a dependency mismatch. If so Cool, How? Are flatpak applications launched in some way where their $PATH is different from the systems. is it easy to tell a flatpak installed app from a pacman installed app. I.E. when a less experienced user shows up on IRC complaining that Xyz doesn't work will it be easy to tell if it is flatpak Xyz or pacman Xyz? I've been around Linux since the days of tarballs and dependency hell. I am suspicious of new package managers that promise to be all sunshine and roses. If you can direct me to detailed technical documentation. Such as an RFC or equivalent. I'll be more then happy to put in the time to study it and learn. It may go a long way to answering the above questions. So far all the documentation I find smells more of marketing talk ("Trust us it's great.. It's like X but with the safety of Y.." type talk). I want to know where things get stored? the hardlinks that were briefly mentioned being created in the "under the hood section" Are those hard links in system Dirs? if someone installs pacman "thing" and then installs flatpak "thing" how does the system know which to run or does one overwrite the other. Etc. I'm also a big time minimalist. I only launch X grudgingly So if I have one perfectly good package manager, There has to be a really clear reason for me to think its a good idea to add another. I totally get that for you it is a fantastic development aid. Cool, great. But it is also exactly the type of thing that new adopters use to shot themselves in the foot. And thus should only be added cautiously. I should also note that I an not (yet) and Parabola maintainer or Developer. I have no official say in this to add/not to add. But I do spend many hours helping folks in IRC (well not compared to bill-auger but that guy is a machine! :) ). And, lacking detailed technical specifications, my mind naturally goes to all the things that could go wrong. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From brainblasted at disroot.org Thu May 31 19:10:45 2018 From: brainblasted at disroot.org (Christopher Davis) Date: Thu, 31 May 2018 15:10:45 -0400 Subject: [Dev] GNOME Software, archlinux-appstream-data, and Flatpak In-Reply-To: <20180531184755.GT2831@freemor.ca> References: <1527722995.25892.0@disroot.org> <4dfafd40cb23dc00c758e5bde1cd31ec07791458.camel@peers.community> <20180531103750.GS2831@freemor.ca> <1527789152.25892.2@disroot.org> <20180531184755.GT2831@freemor.ca> Message-ID: <1527793845.26845.0@disroot.org> https://docs.flatpak.org/en/latest/basic-concepts.html#sandboxes and https://docs.flatpak.org/en/latest/sandbox-permissions-reference.html are two references regarding Flatpak's sandboxing. > So you're saying that if a flatpak pulls in ICU V+1 verses what is > currently in > parabola That will not cause pacman installed applications that > require ICU > v-parabola-current to cack and die because of a dependency mismatch. > If so > Cool, How? Are flatpak applications launched in some way where their > $PATH is different from the systems. Yes. The flatpak ICU will not interfere with system apps that require ICU. So an ICU update within the flatpak env will not cause issues with non-flatpak applications. I am not sure about the technical details regarding how flatpak manages $PATH as a consumer of flatpak, so I will try to get some information out of their IRC channel. > I.E. when a less experienced user shows up on IRC complaining that > Xyz doesn't work will it be easy to tell if it is flatpak Xyz or > pacman Xyz? GNOME Software does tell users where software is installed from. If the application is installed using the Flatpak CLI, the user probably knows that they installed it from Flatpak. > if someone installs pacman "thing" and then installs flatpak "thing" > how does the system know which to run or does one overwrite the > other. Etc. The flatpak will not overwrite anything. I can install Nautilus and Nautilus (Dev), have .desktop files for both, and the .desktop files will correctly correspond to the right install. Flatpaks aren't run with commands like system apps. Instead of running `$ foo`, it would be `$ flatpak run tld.domain.foo`. I will get more technical information to present regarding how sandboxing works. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brainblasted at disroot.org Thu May 31 19:27:28 2018 From: brainblasted at disroot.org (Christopher Davis) Date: Thu, 31 May 2018 15:27:28 -0400 Subject: [Dev] GNOME Software, archlinux-appstream-data, and Flatpak In-Reply-To: <1527793845.26845.0@disroot.org> References: <1527722995.25892.0@disroot.org> <4dfafd40cb23dc00c758e5bde1cd31ec07791458.camel@peers.community> <20180531103750.GS2831@freemor.ca> <1527789152.25892.2@disroot.org> <20180531184755.GT2831@freemor.ca> <1527793845.26845.0@disroot.org> Message-ID: <1527794848.26845.1@disroot.org> https://github.com/flatpak/flatpak/wiki/Sandbox is a detailed look into Flatpak's sandboxing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From freemor at freemor.ca Thu May 31 19:41:32 2018 From: freemor at freemor.ca (Freemor) Date: Thu, 31 May 2018 16:41:32 -0300 Subject: [Dev] GNOME Software, archlinux-appstream-data, and Flatpak In-Reply-To: <1527793845.26845.0@disroot.org> References: <1527722995.25892.0@disroot.org> <4dfafd40cb23dc00c758e5bde1cd31ec07791458.camel@peers.community> <20180531103750.GS2831@freemor.ca> <1527789152.25892.2@disroot.org> <20180531184755.GT2831@freemor.ca> <1527793845.26845.0@disroot.org> Message-ID: <20180531194113.GU2831@freemor.ca> On Thu, May 31, 2018 at 03:10:45PM -0400, Christopher Davis wrote: > https://docs.flatpak.org/en/latest/basic-concepts.html#sandboxes and > https://docs.flatpak.org/en/latest/sandbox-permissions-reference.html The bad Cert doesn't fill me with confidence. But that aside Those just re-itterate the party line https://github.com/flatpak/flatpak/wiki/Sandbox https://github.com/flatpak/flatpak/wiki/Filesystem And other links on that wiki have the kind of info I'm looking for and may be of interest to Devs/Maintainers > with commands like system apps. Instead of running `$ foo`, it would > be `$ flatpak run tld.domain.foo`. Good to know and explains a bit of my confusion. Clearly this is a very DE type thing and I live on the CLI > > I will get more technical information to present regarding how > sandboxing works. After reading the above from the github wiki many of my "I'll make a mess" fears are alleyed. I can still see ways thing can go wrong but those would mostly be either pilot error or people not understand the sandbox things which don't effect system stability. Guess the big issue left is keeping it (the list of available flatpaks) libre. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From freemor at freemor.ca Thu May 31 19:50:14 2018 From: freemor at freemor.ca (Freemor) Date: Thu, 31 May 2018 16:50:14 -0300 Subject: [Dev] GNOME Software, archlinux-appstream-data, and Flatpak In-Reply-To: <1527793845.26845.0@disroot.org> References: <1527722995.25892.0@disroot.org> <4dfafd40cb23dc00c758e5bde1cd31ec07791458.camel@peers.community> <20180531103750.GS2831@freemor.ca> <1527789152.25892.2@disroot.org> <20180531184755.GT2831@freemor.ca> <1527793845.26845.0@disroot.org> Message-ID: <20180531195014.GV2831@freemor.ca> Hmmm.. Does being trivial to install non-freedom respecting stuff make this a non-starter? https://flathub.org/home Would supporting flatpak install count as recommending non-free software? Like linking to addons.mozilla.org does. Is it even possible to create a "your-freedom" style flatpack? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From brainblasted at disroot.org Thu May 31 19:59:49 2018 From: brainblasted at disroot.org (Christopher Davis) Date: Thu, 31 May 2018 15:59:49 -0400 Subject: [Dev] GNOME Software, archlinux-appstream-data, and Flatpak In-Reply-To: <20180531195014.GV2831@freemor.ca> References: <1527722995.25892.0@disroot.org> <4dfafd40cb23dc00c758e5bde1cd31ec07791458.camel@peers.community> <20180531103750.GS2831@freemor.ca> <1527789152.25892.2@disroot.org> <20180531184755.GT2831@freemor.ca> <1527793845.26845.0@disroot.org> <20180531195014.GV2831@freemor.ca> Message-ID: <1527796789.26845.2@disroot.org> Flathub is not a central repository like npm, but rather one flatpak repo. It works similar to pacman in that flatpak only uses the repos provided. While it would be hard to create a your-freedom style flatpak, there could be a completely free flatpak repo to use instead of flathub. Purism is interested in getting one of these set up for PureOS, and I've mentioned the idea of splitting Flathub's nonfree apps off from the free apps so an FSDG-compliant distro could use Flathub in the #flatpak channel on freenode. Parabola could also set up a repo or work with one of the mentioned parties to address the situation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brainblasted at disroot.org Thu May 31 20:01:43 2018 From: brainblasted at disroot.org (Christopher Davis) Date: Thu, 31 May 2018 16:01:43 -0400 Subject: [Dev] GNOME Software, archlinux-appstream-data, and Flatpak In-Reply-To: <1527796789.26845.2@disroot.org> References: <1527722995.25892.0@disroot.org> <4dfafd40cb23dc00c758e5bde1cd31ec07791458.camel@peers.community> <20180531103750.GS2831@freemor.ca> <1527789152.25892.2@disroot.org> <20180531184755.GT2831@freemor.ca> <1527793845.26845.0@disroot.org> <20180531195014.GV2831@freemor.ca> <1527796789.26845.2@disroot.org> Message-ID: <1527796903.26845.3@disroot.org> Another option could be a flatpak-level patch that blocks nonfree flatpaks from being installed, as flatpaks include license information with them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From freemor at freemor.ca Thu May 31 20:09:43 2018 From: freemor at freemor.ca (Freemor) Date: Thu, 31 May 2018 17:09:43 -0300 Subject: [Dev] GNOME Software, archlinux-appstream-data, and Flatpak In-Reply-To: <1527796789.26845.2@disroot.org> References: <1527722995.25892.0@disroot.org> <4dfafd40cb23dc00c758e5bde1cd31ec07791458.camel@peers.community> <20180531103750.GS2831@freemor.ca> <1527789152.25892.2@disroot.org> <20180531184755.GT2831@freemor.ca> <1527793845.26845.0@disroot.org> <20180531195014.GV2831@freemor.ca> <1527796789.26845.2@disroot.org> Message-ID: <20180531200943.GW2831@freemor.ca> On Thu, May 31, 2018 at 03:59:49PM -0400, Christopher Davis wrote: > Flathub is not a central repository like npm, but rather one flatpak > repo. It works similar to pacman in that flatpak only uses the repos > provided. While it would be hard to create a your-freedom style > flatpak, there could be a completely free flatpak repo to use > instead of flathub. Purism is interested in getting one of these set > up for PureOS, > and I've mentioned the idea of splitting Flathub's nonfree apps off > from the free apps > so an FSDG-compliant distro could use Flathub in the #flatpak > channel on freenode. > > Parabola could also set up a repo or work with one of the mentioned > parties to address the situation. That was not my confusion but rather the ease with which some could got to flathub, download steam or skype, and blow their freedom. Figuring it must be ok. because 1. super easy to do, and 2. Parabola supports flatpaks so this is intended right? The licensing patch idea sounds interesting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From brainblasted at disroot.org Thu May 31 20:12:38 2018 From: brainblasted at disroot.org (Christopher Davis) Date: Thu, 31 May 2018 16:12:38 -0400 Subject: [Dev] GNOME Software, archlinux-appstream-data, and Flatpak In-Reply-To: <20180531200943.GW2831@freemor.ca> References: <1527722995.25892.0@disroot.org> <4dfafd40cb23dc00c758e5bde1cd31ec07791458.camel@peers.community> <20180531103750.GS2831@freemor.ca> <1527789152.25892.2@disroot.org> <20180531184755.GT2831@freemor.ca> <1527793845.26845.0@disroot.org> <20180531195014.GV2831@freemor.ca> <1527796789.26845.2@disroot.org> <20180531200943.GW2831@freemor.ca> Message-ID: <1527797558.26845.4@disroot.org> Could someone not go and grab a package tarball that isn't within the blacklist (or has a changed pkgname) and install it with pacman -U? From my understanding, the issue would come in actively supporting such things. -------------- next part -------------- An HTML attachment was scrubbed... URL: From freemor at freemor.ca Thu May 31 20:17:54 2018 From: freemor at freemor.ca (Freemor) Date: Thu, 31 May 2018 17:17:54 -0300 Subject: [Dev] GNOME Software, archlinux-appstream-data, and Flatpak In-Reply-To: <1527797558.26845.4@disroot.org> References: <1527722995.25892.0@disroot.org> <4dfafd40cb23dc00c758e5bde1cd31ec07791458.camel@peers.community> <20180531103750.GS2831@freemor.ca> <1527789152.25892.2@disroot.org> <20180531184755.GT2831@freemor.ca> <1527793845.26845.0@disroot.org> <20180531195014.GV2831@freemor.ca> <1527796789.26845.2@disroot.org> <20180531200943.GW2831@freemor.ca> <1527797558.26845.4@disroot.org> Message-ID: <20180531201754.GX2831@freemor.ca> On Thu, May 31, 2018 at 04:12:38PM -0400, Christopher Davis wrote: > Could someone not go and grab a package tarball that isn't within > the blacklist (or has a changed pkgname) and install it with pacman > -U? From my understanding, the issue would come in actively > supporting such things. The flatpak download and click a much simpler interaction then the pacman example. As to your second point I am unsure.. Thus my post with all the questions. N.B. /me is going to stop posting for a while now to give other people a chance to catch up. For a low volume list we've created quite a flood. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: